Gesaan dan persekitaran
Penerima mengesahkan permintaan webhook yang ditandatangani semasa penyedia menukar rahsia. Pemutaran mesti bertoleransi terhadap percubaan semula dalam penerbangan dan berbilang replika penghantar tanpa mendedahkan rahsia atau mewujudkan jurang pengesahan.
Perkara yang diuji oleh penemu bual
- Memelihara pengesahan tandatangan badan mentah (raw-body) dan perbandingan masa malar.
- Mereka bentuk pertindihan terikat antara rahsia aktif dan yang bakal ditamatkan.
- Mengasingkan keadaan pemutaran, perlindungan main semula, kebolehcerapan dan undur balik.
Soalan penjelasan sebelum menjawab
- Siapakah yang mengawal pemutaran, dan bolehkah penghantar mendedahkan pengecam kunci atau versi?
- Berapa lamakah percubaan semula penghantaran dan pencongan jam (clock skew) boleh bertahan?
- Bolehkah penghantar menyelaraskan tetingkap dwi-tandatangan, atau adakah penerima mesti menerima dua rahsia?
- Apakah ID peristiwa, cap masa dan muatan mentah yang tersedia untuk semakan main semula?
Rangka kerja jawapan 30 saat
Saya akan memperuntukkan rahsia baharu, mengedarkannya kepada setiap penerima, dan memasuki tetingkap pertindihan yang singkat. Semasa pertindihan, sahkan tandatangan yang dipilih mengikut key-id atau cuba rahsia semasa dan rahsia yang bakal ditamatkan dengan semakan masa malar, di samping menguatkuasakan toleransi cap masa dan penyahduplikasian ID peristiwa. Metrik mesti menunjukkan versi mana yang berjaya disahkan, dan pemutaran selesai hanya selepas trafik versi lama kekal sifar sepanjang tempoh ufuk percubaan semula. Undur balik mengekalkan rahsia yang bakal ditamatkan sehingga tetingkap ditutup.
Panduan mendalam langkah demi langkah
1. Pelihara bait yang ditandatangani
Baca badan permintaan sekali sebagai bait mentah sebelum penghuraian JSON. Bina input tandatangan tepat seperti yang ditentukan oleh penyedia, termasuk peraturan cap masa dan pembatas. Bandingkan MAC dalam masa malar dan tolak muatan yang tidak terbentuk dengan betul atau bersaiz lebih awal.
2. Modelkan versi rahsia
Simpan versi aktif dan yang bakal ditamatkan dengan masa penciptaan, tamat tempoh, skop penyedia dan status seperti PENDING, OVERLAP, atau RETIRED. Pengecam kunci lebih diutamakan kerana ia mengelakkan pengesahan cuba-cuba; jika tiada, hadkan sandaran dua rahsia dan rekod rahsia mana yang berjaya.
3. Lancarkan dengan selamat
Edarkan rahsia baharu melalui pengurus rahsia, muat semula penerima secara atomik dan jalankan kenari yang ditandatangani. Minta penghantar melakukan dwi-tandatangan atau beralih hanya selepas kesediaan diperhatikan. Pastikan rahsia lama tersedia untuk tempoh percubaan semula maksimum ditambah margin pencongan jam.
4. Sekat main semula
Wajibkan cap masa yang ditandatangani dalam toleransi terikat dan simpan ID peristiwa atau ringkasan dengan tempoh pengekalan yang meliputi percubaan semula. Pengesahan mesti berlaku sebelum dimasukkan ke dalam baris gilir; penghantaran sah yang pendua boleh memperakui kejayaan tanpa mengulangi kesan perniagaan.
5. Perhati dan tamatkan
Kira kejayaan pengesahan mengikut versi kunci, cap masa lapuk, ID pendua, tandatangan tidak sah dan hasil baris gilir tanpa melog rahsia atau muatan sensitif penuh. Tamatkan versi lama hanya selepas ufuk pertindihan dan percubaan semula berlalu; jika versi baharu gagal, pulihkan versi lama dan cetuskan amaran.
Contoh jawapan berkualiti tinggi
“Saya akan menyediakan versi baharu dalam pengurus rahsia, memuat semula setiap penerima dan mengesahkan kenari sebelum menukar penghantar. Untuk pertindihan terikat, terima tandatangan daripada versi semasa dan yang bakal ditamatkan, sebaik-baiknya dipilih mengikut ID kunci, sambil menyemak cap masa yang ditandatangani dan menyahduplikasi ID peristiwa. Saya akan menjejaki pengesahan mengikut versi dan menunggu sepanjang ufuk percubaan semula penghantar ditambah pencongan jam sebelum penamatan. Jika versi baharu gagal, undur balik mengekalkan rahsia lama sah; log mengandungi pembilang dan ID, bukan rahsia atau muatan mentah.”
Kesilapan biasa
- Gantikan rahsia di semua tempat sekali gus → percubaan semula dengan tandatangan lama gagal → gunakan tetingkap pertindihan.
- Huraikan JSON sebelum pengesahan → bait kanonikal mungkin berubah → sahkan badan mentah dahulu.
- Terima mana-mana rahsia selama-lamanya → kelayakan lapuk kekal sah → tetapkan tamat tempoh yang terikat pada had percubaan semula dan pencongan.
- Log tandatangan atau rahsia → kebolehcerapan menjadi kebocoran kelayakan → log pembilang berversi dan pengecam selamat.
Soalan susulan dan respons
Bagaimana jika penghantar tidak boleh melakukan dwi-tandatangan?
Pramuat rahsia baharu dan terima kedua-dua versi pada penerima untuk tetingkap terikat. Selaraskan pertukaran penghantar, pantau pengesahan khusus versi dan kekalkan versi lama sepanjang tempoh percubaan semula maksimum.
Bagaimanakah anda memilih tempoh pertindihan?
Gunakan siling percubaan semula yang didokumentasikan penghantar, kelewatan baris gilir, toleransi pencongan jam dan margin insiden. Jadikan tarikh akhir jelas dan berikan amaran tentang trafik versi lama yang menghampiri tamat tempoh dan bukannya meneka daripada purata kependaman.
Bagaimana jika penyerang memainkan semula peristiwa lama yang sah?
Tolak cap masa di luar toleransi dan nyahduplikasi ID peristiwa atau ringkasan muatan yang ditandatangani. Simpan rekod main semula sekurang-kurangnya selama tetingkap cap masa yang diterima dan ufuk percubaan semula perniagaan.