Temu duga reka bentuk sistem: bagaimanakah anda mereka bentuk perkhidmatan pemutaran rahsia berbilang penyewa?

Soalan

Reka bentuk perkhidmatan pemutaran rahsia (secrets rotation) berbilang penyewa. Penyewa boleh mengkonfigurasi kata laluan pangkalan data, kunci API pihak ketiga atau sijil serta tempoh pemutarannya. Perkhidmatan ini menjana nilai baharu, mengemas kini sistem luaran, menyimpan versi, memberitahu beban kerja secara beransur-ansur dan menamatkan nilai lama. Rangkumi pemulihan, konkurensi, kebolehauditan, kebenaran dan rollback.

Perkara yang diuji oleh penemu duga

• Sama ada anda memodelkan pemutaran sebagai mesin keadaan (state machine) yang boleh dicuba semula dan bukannya skrip cron yang tidak boleh dipulihkan.
• Sama ada anda mengendalikan mesej pendua, tugas serentak untuk satu rahsia dan pengasingan penyewa.
• Sama ada anda boleh menyediakan dua versi dan melancarkannya secara berperingkat dan bukannya menyebabkan kegagalan menyeluruh armada serta-merta.
• Sama ada anda boleh menerangkan penamatan, tindak balas kompromi, bukti audit dan keistimewaan paling sedikit (least privilege).

Jawapan model

Objek teras ialah Secret, Version tidak boleh ubah (immutable), RotationPolicy, Job dan Lease. Penjadual mengeluarkan tugas untuk masa pemutaran seterusnya; giliran dibahagikan mengikut secret_id, dan pekerja (worker) memperoleh pajakan (lease) dengan tempoh luput. Kekangan keunikan pangkalan data pada (secret_id, idempotency_key) menjadikan percubaan semula selamat.

Gunakan mesin keadaan seperti scheduled → generating → external_updated → staged → rolling_out → verified → retired. Kekalkan pengecam permintaan luaran, versi dan masa percubaan semula seterusnya pada setiap langkah. Cipta kelayakan dalam penyedia luaran terlebih dahulu, kemudian simpan versi tertunda (pending). Beban kerja beralih secara beransur-ansur melalui rujukan versi yang tidak boleh diubah atau mekanisme penyegaran. Promosikan versi kepada current hanya selepas pemeriksaan kesihatan, kadar ralat dan ujian kebenaran lulus.

Asingkan metadata kawalan daripada muatan rahsia yang disulitkan. Aplikasi menerima kebenaran membaca jangka pendek. Setiap peralihan keadaan dimasukkan ke dalam log audit tambah sahaja (append-only) tanpa teks biasa rahsia. Rollback memilih versi lama yang masih sah; ia tidak boleh membatalkan versi tersebut secara automatik sebelum pemulihan selesai.

Lakaran seni bina

Scheduler -> Durable Queue -> Rotation Workers
     |              |              |
 Policy DB     Lease/Idempotency  External Provider
     |                             |
 Version Store + KMS        Rollout Controller -> Workloads
     |
 Audit Log / Metrics / Alerts

Pekerja memperbaharui pajakan; selepas tamat tempoh, pekerja lain boleh mengambil alih. Mesej giliran hanya membawa pengecam rahsia dan tugas. Pekerja membaca nilai daripada stor versi terhad, memastikan teks biasa berada di luar mesej, log dan label metrik.

Aliran kritikal

1. Penjadual mencipta tugas idempoten dan menggunakan kuota penyewa.
2. Pekerja memperoleh pajakan dan membaca versi serta dasar semasa; tugas yang telah selesai kembali dengan selamat.
3. Ia menjana nilai dan memanggil penyedia dengan kunci keidempotenan pihak penyedia.
4. Ia menulis versi pending dan menjalankan semakan keserasian serta pelancaran berskala kecil.
5. Ia memerhatikan kadar ralat, kejayaan pengesahan dan prob kesihatan; hanya selepas itu mempromosikan kepada current.
6. Selepas semua pengguna mengesahkan, ia menyahdayakan dan memusnahkan versi lama; kegagalan akan dicuba semula atau di-rollback.

Kekalkan keadaan dan respons luaran pada setiap langkah. Semasa memulakan semula, teruskan dari keadaan terakhir dan bukannya meneka sama ada penyedia telah ditukar.

Perangkap biasa

• Hanya menyimpan masa seterusnya dalam cron, tanpa meninggalkan titik pemulihan selepas permulaan semula atau penghantaran pendua.
• Membatalkan nilai lama serta-merta, mengabaikan kolam sambungan, cache dan sambungan jangka panjang.
• Memasukkan teks biasa ke dalam giliran, log, rentang penjejakan (tracing spans) atau mesej ralat.
• Menggunakan satu kunci global untuk semua penyewa, atau meninggalkan kuota penyewa sehingga satu penyewa menghabiskan sumber pekerja.
• Menganggap rollback sebagai menulis nilai lama semula tanpa memeriksa sama ada ia masih sah dan aktif.

Pertukaran ketekalan dan keselamatan

Gunakan pangkalan data yang konsisten secara ketat untuk mesin keadaan dan kekangan keunikan. Pemberitahuan dan pelancaran boleh bersifat at-least-once, jadi pengguna mestilah idempoten. Bacaan versi boleh dicache secara ringkas, tetapi perubahan versi current dan pembatalan memerlukan laluan pembatalan yang jelas. Kebenaran penyewa mengehadkan akses kepada rahsia, tugas dan rekod auditnya sendiri; pekerja hanya menerima kebenaran penyedia yang diperlukan untuk langkah semasa.

Tempoh pemutaran harus mempertimbangkan jenis kunci, risiko pendedahan, had penyedia dan tetingkap pemulihan dan bukannya pemasa tetap semata-mata. Panduan pengurusan kunci NIST menganggap tempoh penggunaan, tujuan, tahap perlindungan dan pembatalan sebagai satu keputusan dasar.

Suntik kegagalan apabila pekerja ranap sebelum dan selepas setiap peralihan keadaan, apabila mesej mendua, pajakan tamat tempoh, masa penyedia tamat, pelancaran separa gagal dan pangkalan data mengalami failover. Pastikan bahawa satu tugas tidak mencipta kelayakan luaran pendua, tepat satu versi menjadi current, dan nilai lama dibatalkan hanya selepas tetingkap pengesahan. Uji juga pengasingan penyewa, redaksi audit dan kependaman amaran.

• Aliran pemutaran AWSPENDING/AWSCURRENT AWS Secrets Manager: label pementasan dan langkah penyiapan.
• Panduan pemutaran Google Cloud Secret Manager: percubaan semula, pemutaran tidak serentak, pelancaran berperingkat dan pembersihan versi lama.
• NIST SP 800-57 Bahagian 1: tujuan kunci, perlindungan, tempoh penggunaan dan prinsip pembatalan.

Soalan susulan

Bagaimanakah anda menghalang dua pekerja daripada memutarkan satu rahsia pada masa yang sama?

Gunakan pajakan pangkalan data atau kunci teragih dengan token pemagaran (fencing token), dan tulis token tersebut ke dalam setiap kemas kini keadaan. Pekerja yang dipulihkan tanpa token semasa tidak boleh menulis ganti keadaan yang lebih baharu; pajakan memerlukan pembaharuan dan tempoh luput yang jelas.

Bagaimana jika penyedia tidak mempunyai API idempoten?

Kekalkan cap jari permintaan (request fingerprint) dan pengecam sumber luaran dalam tugas, kemudian buat pertanyaan kepada penyedia sebelum mencuba semula. Jika penyedia tidak boleh ditanya, jeda langkah tersebut untuk pengesahan manusia daripada terus mencipta lebih banyak kelayakan secara membuta tuli.

Mengapa tidak membiarkan setiap aplikasi membaca latest?

latest boleh menolak nilai yang belum disahkan ke seluruh armada serta-merta. Versi yang tidak boleh diubah, pelancaran berperingkat dan semakan kesihatan membendung radius impak dan mengekalkan titik rollback.

Bagaimanakah anda melindungi perkhidmatan apabila tugas pemutaran bertimbun?

Tetapkan kuota konkurensi bagi setiap penyewa dan penyedia, gunakan keutamaan dan backoff eksponen, serta dedahkan usia tugas paling lama, kadar kegagalan dan baki tetingkap pemulihan. Rahsia yang hampir tamat tempoh boleh diutamakan tanpa memintas kebenaran atau keidempotenan.

Apakah yang dilakukan oleh perkhidmatan selepas insiden kompromi keselamatan?

Jeda jadual biasa untuk tugas yang terjejas, cipta pemutaran kecemasan berkeutamaan tinggi, pendekkan tetingkap pemerhatian pelancaran dan kekalkan log forensik. Sahkan bahawa pengguna kritikal telah beralih sebelum membatalkan nilai lama, dan maklumkan kepada penyewa serta proses tindak balas keselamatan.