Petunjuk dan cakupan
Mitra pembayaran memerlukan bukti pengirim dan integritas dari setiap permintaan HTTP. Menggunakan RFC 9421, rancang penandatanganan dan verifikasi serta jelaskan komponen yang dicakup, pertahanan replay, rotasi kunci, dan penulisan ulang proksi.
RFC 9421 memisahkan signature input, komponen HTTP yang dicakup, dan parameter seperti created, expires, dan nonce. Pertanyaan ini menguji apakah kandidat dapat membuat "siapa yang menandatanganinya" dan "byte mana yang ditandatangani" saling dapat dioperasikan (interoperable), alih-alih hanya melakukan hashing pada body.
Apa yang dievaluasi pewawancara
Mengevaluasi apakah komponen yang dicakup mengikat semantik permintaan; apakah kedua belah pihak mengkanonisasi signature base secara identik; apakah waktu, nonce, dan key ID menghentikan replay; bagaimana proksi, percobaan ulang (retry), kompresi, dan tenant memengaruhi verifikasi; serta apakah publikasi, pencabutan, dan pemantauan kunci dapat dioperasikan.
Kerangka jawaban 30 detik
"Saya akan mewajibkan method, target path, authority, bidang bisnis penting, dan Content-Digest untuk dicakup, dengan algoritma, urutan parameter, dan toleransi jam (clock tolerance) yang tetap. Server mem-parsing Signature-Input, membangun kembali base yang sama, menemukan kunci, memverifikasi tanda tangan, memeriksa created, expires, dan nonce sekali pakai, lalu baru melanjutkan ke logika bisnis. Key ID berversi mendukung verifikasi ganda dan pencabutan. Proksi hanya boleh menulis ulang bidang yang tidak dicakup; jika tidak, verifikasi gagal."
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan properti yang akan dibuktikan
Tanda tangan membuktikan bahwa pemegang kunci menandatangani komponen HTTP yang dipilih dan membantu mendeteksi perusakan (tampering). Ini tidak menggantikan TLS, otorisasi, validasi input, atau idempotensi bisnis. Nyatakan apakah protokol memerlukan autentikasi, integritas, atau non-repudiasi.
Langkah 2: Pilih komponen yang dicakup
Cakup method, target path, dan authority sebagai batas minimum. Tambahkan content-digest, kunci idempotensi, tenant ID, atau bidang bisnis penting sesuai kebutuhan. Jangan menandatangani satu bidang yang dapat diganti atau secara membabi buta mencakup header yang ditulis ulang oleh proksi yang sah. Buat versi daftar komponen sebagai bagian dari protokol.
Langkah 3: Kanonisasi signature base
Kedua belah pihak harus mengikuti aturan pengidentifikasi komponen, pengurutan, pengodean parameter, dan komponen turunan dari RFC 9421. Server harus membangun kembali base dari permintaan yang di-parsing dan Signature-Input, bukan menebak-nebak dengan menggabungkan string header mentah. Tolak komponen kritis yang tidak dikenal atau duplikat.
Langkah 4: Lindungi konten permintaan
Untuk permintaan dengan body, hitung Content-Digest dan sertakan dalam tanda tangan. Sebelum verifikasi, lakukan hash pada byte yang diterima sehingga kompresi, transkoding, atau pemformatan ulang JSON tidak dapat mengubah konten secara diam-diam. Jika proksi melakukan dekompresi atau pengodean ulang, tentukan apakah penandatanganan terjadi sebelum atau sesudah transformasi tersebut.
Langkah 5: Tambahkan waktu dan pertahanan replay
Wajibkan created, dan jika berguna wajibkan expires serta nonce yang unik. Periksa rentang waktu dan clock skew, lalu simpan nonce yang telah digunakan secara singkat per tenant. Percobaan ulang untuk permintaan bisnis yang sama mengandalkan kunci idempotensi alih-alih masa berlaku tanda tangan yang tidak terbatas. Lolos pemeriksaan waktu tidak membuat penulisan (write) aman untuk dieksekusi dua kali.
Langkah 6: Temukan dan lakukan rotasi kunci
Key ID di Signature-Input memilih kunci publik dari direktori yang terkontrol atau endpoint mirip JWKS. Simpan hasil berversi dalam cache. Selama rotasi, publikasikan kunci baru, izinkan kunci lama dan baru selama periode tumpang tindih yang dibatasi, kemudian cabut kunci lama setelah lalu lintas dialihkan sepenuhnya. Simpan kunci privat di endpoint penandatangan dan jangan pernah mencatat materi kunci atau signature base lengkap ke dalam log.
Langkah 7: Tentukan batasan proksi dan percobaan ulang (retry)
Dokumentasikan lapisan mana yang dapat menambahkan bidang pelacakan, mencoba ulang permintaan, atau mengubah authority. Penulisan ulang yang tidak sah pada komponen yang dicakup harus menggagalkan verifikasi. Proksi tidak dapat menyalin nonce sekali pakai atau meneruskan tanda tangan ke target lain. Jangan jalankan operasi penulisan atau logika bisnis yang mahal sebelum verifikasi.
Langkah 8: Tangani kegagalan dengan aman
Catat key ID, versi tanda tangan, kelas kegagalan, clock skew, tabrakan nonce, komponen yang hilang, dan sumber proksi bersama dengan request ID. Berikan kelas yang dapat ditindaklanjuti kepada mitra seperti kedaluwarsa, kunci tidak dikenal, atau digest tidak cocok, tanpa mengembalikan materi kunci atau base terperinci yang membantu penyerang melakukan pemeriksaan (probing).
Pertukaran (trade-offs) dan batasan
Tanda tangan asimetris versus kunci bersama
Kunci asimetris menyederhanakan verifikasi multipihak dan pencabutan independen tetapi memerlukan lebih banyak infrastruktur. HMAC bersama lebih murah, namun setiap pemverifikasi dapat memalsukan permintaan; gunakan hanya jika batasan kepercayaan (trust boundary) telah jelas.
Cakupan versus kompatibilitas proksi
Cakupan yang lebih banyak memberikan integritas yang lebih kuat tetapi dapat gagal ketika gateway secara sah mengubah suatu bidang. Masukkan kontrak proksi ke dalam protokol dan lakukan penandatanganan ulang di batas sistem saat diperlukan alih-alih melemahkan verifikasi secara diam-diam.
Rentang waktu ketat versus percobaan ulang offline
Rentang waktu yang pendek mengurangi risiko replay tetapi memerlukan sinkronisasi jam dan percobaan ulang yang cepat. Klien offline harus meminta tanda tangan baru alih-alih menggunakan kembali tanda tangan yang berumur panjang; server dapat menerapkan toleransi khusus mitra yang dibatasi.
Latihan kegagalan dan evolusi
Proksi mengubah path
Tulis ulang path atau authority di proksi pengujian dan konfirmasikan bahwa verifikasi gagal sebelum logika bisnis. Perubahan header pelacakan yang diizinkan tidak boleh memengaruhi tanda tangan.
Permintaan lama di-replay
Kirim tanda tangan dan nonce yang sama dua kali dan verifikasi bahwa upaya kedua ditolak. Gunakan nonce baru dengan kunci idempotensi yang sama dan verifikasi idempotensi lapisan bisnis.
Rotasi kunci
Publikasikan kunci lama dan baru bersama-sama dan verifikasi tanda tangan yang sesuai dengan kebijakan. Setelah pencabutan, tanda tangan lama harus gagal dan cache yang basi tidak boleh membuatnya tetap valid tanpa batas waktu.
Kesalahan umum dan pertanyaan lanjutan
Kesalahan 1: Hanya menandatangani hash body
Tanyakan apakah tanda tangan dapat disalin ke path atau method lain; komponen target yang dicakup harus mengikat arti permintaan.
Kesalahan 2: Menganggap HTTPS sudah cukup
Tanyakan bagaimana pengirim asli dan konten diautentikasi setelah melewati proksi internal yang menghentikan TLS (TLS-terminating proxy).
Kesalahan 3: Mengabaikan nonce dan waktu
Tanyakan apakah permintaan pembayaran yang ditangkap dapat di-replay selama masa berlakunya; gabungkan waktu, nonce, dan idempotensi.
Kesalahan 4: Menghapus kunci lama secara langsung
Tanyakan bagaimana permintaan yang sedang berlangsung (in-flight) dan cache multi-wilayah saling tumpang tindih; lakukan verifikasi ganda sebelum pencabutan.
Kesalahan 5: Mengembalikan detail signature-base saat gagal
Tanyakan bagaimana mitra melakukan debugging tanpa mengekspos materi kunci, input yang ditandatangani, atau detail proksi internal.
Pertanyaan lanjutan tambahan dan jawaban referensi
Mengapa menyertakan Content-Digest dalam tanda tangan?
Digest mewakili byte dari body; tanda tangan mengikat digest tersebut ke method, target, dan komponen lain sehingga digest yang valid tidak dapat dipindahkan ke permintaan lain.
Haruskah proksi menandatangani ulang setelah menulis ulang?
Jika penulisan ulang adalah bagian dari protokol downstream, proksi batas harus menandatanganinya sebagai identitasnya sendiri. Jika tidak, proksi harus mempertahankan komponen yang dicakup sehingga tanda tangan asli tetap dapat diverifikasi.
Apa perbedaan autentikasi dan otorisasi?
Verifikasi membuktikan bahwa pemegang kunci telah menandatangani permintaan tersebut. Otorisasi tetap memeriksa tenant, akun, jumlah, idempotensi, dan status bisnis; tanda tangan saja tidak dapat mengotorisasi eksekusi.