Prompt dan konteks
Penerima memverifikasi permintaan webhook bertanda tangan saat penyedia mengubah secret. Rotasi harus menoleransi percobaan ulang (retry) yang sedang berjalan dan beberapa replika pengirim tanpa mengekspos secret atau menciptakan celah verifikasi.
Hal yang diuji oleh pewawancara
- Mempertahankan verifikasi signature pada raw-body dan perbandingan constant-time.
- Merancang tumpang tindih (overlap) yang terbatas antara secret aktif dan yang akan dihentikan.
- Memisahkan status rotasi, perlindungan replay, observabilitas, dan rollback.
Pertanyaan klarifikasi sebelum menjawab
- Siapa yang mengontrol rotasi, dan bisakah pengirim menyertakan pengidentifikasi kunci atau versi?
- Berapa lama batas waktu percobaan ulang pengiriman dan clock skew dapat berlangsung?
- Bisakah pengirim mengoordinasikan jendela dual-signing, atau haruskah penerima menerima dua secret?
- ID event, timestamp, dan raw payload apa yang tersedia untuk pemeriksaan replay?
Kerangka jawaban 30 detik
Saya akan menyediakan secret baru, mendistribusikannya ke setiap penerima, dan memasuki jendela tumpang tindih yang singkat. Selama tumpang tindih, verifikasi signature yang dipilih berdasarkan key-id atau coba secret saat ini dan secret yang akan dihentikan dengan pemeriksaan constant-time, sambil menerapkan toleransi timestamp dan deduplikasi ID event. Metrik harus menunjukkan versi mana yang berhasil diverifikasi, dan rotasi selesai hanya setelah lalu lintas versi lama tetap nol selama batas waktu percobaan ulang (retry horizon). Rollback mempertahankan secret yang akan dihentikan hingga jendela ditutup.
Pembahasan mendalam langkah demi langkah
1. Pertahankan byte yang ditandatangani
Baca body permintaan sekali sebagai raw bytes sebelum parsing JSON. Buat input signature persis seperti yang ditentukan penyedia, termasuk aturan timestamp dan pembatas (delimiter). Bandingkan MAC dalam constant-time dan tolak payload yang cacat atau berukuran terlalu besar sejak awal.
2. Modelkan versi secret
Simpan versi aktif dan versi yang akan dihentikan dengan waktu pembuatan, masa kedaluwarsa, cakupan penyedia, dan status seperti PENDING, OVERLAP, atau RETIRED. Pengidentifikasi kunci lebih disukai karena menghindari verifikasi coba-coba; jika tidak tersedia, batasi mekanisme fallback dua-secret dan catat secret mana yang berhasil.
3. Luncurkan secara aman
Distribusikan secret baru melalui secret manager, muat ulang penerima secara atomik, dan jalankan canary bertanda tangan. Minta pengirim untuk melakukan dual-sign atau beralih hanya setelah kesiapan teramati. Pertahankan secret lama tetap tersedia selama durasi percobaan ulang maksimum ditambah batas clock-skew.
4. Blokir replay
Wajibkan timestamp bertanda tangan dalam batas toleransi dan simpan ID event atau digest dengan periode retensi yang mencakup durasi percobaan ulang. Verifikasi harus dilakukan sebelum memasukkan ke antrean (enqueueing); pengiriman valid yang duplikat dapat mengonfirmasi keberhasilan (ACK) tanpa mengulang efek bisnis.
5. Amati dan hentikan
Hitung keberhasilan verifikasi berdasarkan versi kunci, timestamp yang basi, ID duplikat, signature yang cacat, dan hasil antrean tanpa mencatat secret atau payload sensitif lengkap ke log. Hentikan versi lama hanya setelah batas waktu tumpang tindih dan percobaan ulang terlewati; jika versi baru gagal, pulihkan versi lama dan kirim peringatan.
Contoh jawaban berkualitas tinggi
“Saya akan menyiapkan versi baru di secret manager, memuat ulang setiap penerima, dan memverifikasi canary sebelum mengalihkan pengirim. Untuk tumpang tindih yang terbatas, terima signature dari versi saat ini dan versi yang akan dihentikan, lebih disukai yang dipilih berdasarkan key ID, sambil memeriksa timestamp bertanda tangan dan melakukan deduplikasi ID event. Saya akan melacak verifikasi berdasarkan versi dan menunggu hingga batas waktu percobaan ulang pengirim ditambah clock skew terlewati sebelum penghentian. Jika versi baru gagal, rollback mempertahankan secret lama tetap valid; log hanya berisi penghitung dan ID, tidak pernah mencatat secret atau raw payload.”
Kesalahan umum
- Mengganti secret di semua tempat sekaligus → percobaan ulang dengan signature lama gagal → gunakan jendela tumpang tindih.
- Mem-parsing JSON sebelum verifikasi → kanonikal byte dapat berubah → verifikasi raw body terlebih dahulu.
- Menerima kedua secret selamanya → kredensial lama tetap valid → tetapkan masa kedaluwarsa yang terikat pada batas percobaan ulang dan skew.
- Mencatat signature atau secret ke log → observabilitas menjadi kebocoran kredensial → catat penghitung berversi dan pengidentifikasi yang aman.
Pertanyaan lanjutan dan jawabannya
Bagaimana jika pengirim tidak dapat melakukan dual-sign?
Muat secret baru terlebih dahulu dan terima kedua versi pada penerima selama jendela waktu yang terbatas. Koordinasikan peralihan pengirim, pantau verifikasi khusus per versi, dan pertahankan versi lama selama periode percobaan ulang maksimum.
Bagaimana Anda memilih durasi tumpang tindih?
Gunakan batas atas percobaan ulang yang didokumentasikan pengirim, penundaan antrean, toleransi clock-skew, dan margin insiden. Buat batas waktu secara eksplisit dan pasang peringatan pada lalu lintas versi lama yang mendekati masa kedaluwarsa alih-alih menebak dari latensi rata-rata.
Bagaimana jika penyerang melakukan replay pada event lama yang valid?
Tolak timestamp di luar batas toleransi dan lakukan deduplikasi ID event atau digest payload bertanda tangan. Simpan catatan replay setidaknya selama jendela timestamp yang diterima dan batas waktu percobaan ulang bisnis.