Wawancara system design: bagaimana Anda mendesain layanan rotasi secret multi-tenant?

Pertanyaan

Desain layanan rotasi secret multi-tenant. Tenant dapat mengonfigurasi kata sandi basis data, API key pihak ketiga, atau sertifikat beserta periode rotasinya. Layanan ini menghasilkan nilai baru, memperbarui sistem eksternal, menyimpan versi, memberi tahu beban kerja secara bertahap, dan menghentikan (retire) nilai lama. Cakup pemulihan, konkurensi, auditabilitas, otorisasi, dan rollback.

Hal yang diuji oleh pewawancara

• Apakah Anda memodelkan rotasi sebagai state machine yang dapat dicoba kembali (retryable) alih-alih skrip cron yang tidak dapat dipulihkan.
• Apakah Anda menangani pesan duplikat, tugas konkuren untuk satu secret, dan isolasi tenant.
• Apakah Anda dapat menyiapkan dua versi dan meluncurkannya secara bertahap alih-alih menyebabkan kegagalan langsung di seluruh armada sistem.
• Apakah Anda dapat menjelaskan penghentian secret, respons kompromi keamanan, bukti audit, dan hak istimewa paling minimal (least privilege).

Jawaban model

Objek inti adalah Secret, Version yang tidak dapat diubah (immutable), RotationPolicy, Job, dan Lease. Scheduler mengeluarkan tugas untuk waktu rotasi berikutnya; antrean dipartisi oleh secret_id, dan worker memperoleh lease dengan masa kedaluwarsa. Batasan keunikan basis data pada (secret_id, idempotency_key) membuat percobaan ulang menjadi aman.

Gunakan state machine seperti scheduled → generating → external_updated → staged → rolling_out → verified → retired. Simpan pengidentifikasi permintaan eksternal, versi, dan waktu percobaan ulang berikutnya di setiap langkah. Buat kredensial di penyedia eksternal terlebih dahulu, lalu simpan versi yang tertunda (pending). Beban kerja beralih secara bertahap melalui referensi versi immutable atau mekanisme penyegaran (refresh). Promosikan versi ke current hanya setelah pemeriksaan kesehatan (health checks), tingkat kesalahan, dan uji otorisasi berhasil dilewati.

Pisahkan metadata kontrol dari muatan secret yang dienkripsi. Aplikasi menerima izin baca berdurasi pendek. Setiap transisi status masuk ke log audit append-only tanpa plaintext secret. Rollback memilih versi lama yang masih valid; sistem tidak boleh mencabut versi tersebut secara otomatis sebelum pemulihan selesai.

Sketsa arsitektur

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

Worker memperbarui lease; setelah kedaluwarsa, worker lain dapat mengambil alih. Pesan antrean hanya membawa pengidentifikasi secret dan tugas. Worker membaca nilai dari penyimpanan versi terbatas, menjaga plaintext tetap berada di luar pesan, log, dan label metrik.

Alur kritis

1. Scheduler membuat tugas idempoten dan menerapkan kuota tenant.
2. Worker memperoleh lease dan membaca versi serta kebijakan saat ini; tugas yang sudah selesai kembali dengan aman.
3. Worker menghasilkan nilai dan memanggil penyedia dengan kunci idempotensi sisi penyedia.
4. Worker menulis versi pending dan menjalankan pemeriksaan kompatibilitas serta peluncuran kecil.
5. Worker mengamati tingkat kesalahan, keberhasilan autentikasi, dan health probe; baru kemudian mempromosikannya ke current.
6. Setelah semua konsumen mengonfirmasi, worker menonaktifkan dan menghancurkan versi lama; kegagalan akan dicoba kembali atau di-rollback.

Simpan status dan respons eksternal di setiap langkah. Saat memulai ulang, lanjutkan dari status terakhir alih-alih menebak apakah penyedia telah diubah.

Jebakan umum

• Hanya menyimpan waktu berikutnya di cron, tanpa meninggalkan titik pemulihan setelah restart atau pengiriman duplikat.
• Mencabut nilai lama secara langsung, mengabaikan connection pool, cache, dan koneksi jangka panjang.
• Memasukkan plaintext ke dalam antrean, log, tracing span, atau pesan kesalahan.
• Menggunakan satu kunci global untuk semua tenant, atau mengabaikan kuota tenant sehingga satu tenant menghabiskan seluruh worker.
• Memperlakukan rollback sebagai penulisan ulang nilai lama tanpa memeriksa apakah nilai tersebut masih valid dan aktif.

Pertukaran konsistensi dan keamanan

Gunakan basis data dengan konsistensi kuat untuk state machine dan batasan keunikan. Notifikasi dan peluncuran dapat bersifat at-least-once, sehingga konsumen harus idempoten. Pembacaan versi dapat di-cache secara singkat, tetapi perubahan versi current dan pencabutan memerlukan jalur pembatalan (invalidation) eksplisit. Otorisasi tenant membatasi akses hanya ke secret, tugas, dan catatan audit miliknya sendiri; worker hanya menerima izin penyedia yang diperlukan untuk langkah saat ini.

Periode rotasi harus mempertimbangkan jenis kunci, risiko paparan, batasan penyedia, dan jendela pemulihan, bukan hanya berdasarkan timer tetap. Panduan pengelolaan kunci NIST memperlakukan periode penggunaan, tujuan, tingkat perlindungan, dan pencabutan sebagai satu keputusan kebijakan.

Ujilah kegagalan saat worker mengalami crash sebelum dan sesudah setiap transisi status, saat pesan terduplikasi, lease kedaluwarsa, penyedia mengalami waktu habis (timeout), peluncuran parsial gagal, dan basis data mengalami failover. Pastikan satu tugas tidak membuat kredensial eksternal duplikat, tepat satu versi menjadi current, dan nilai lama dicabut hanya setelah jendela konfirmasi selesai. Uji juga isolasi tenant, penyuntingan log audit, dan latensi peringatan.

• Alur rotasi AWSPENDING/AWSCURRENT pada AWS Secrets Manager: label staging dan langkah penyelesaian.
• Panduan rotasi Google Cloud Secret Manager: percobaan ulang, rotasi non-konkuren, peluncuran bertahap, dan pembersihan versi lama.
• NIST SP 800-57 Bagian 1: tujuan kunci, perlindungan, periode penggunaan, dan prinsip pencabutan.

Pertanyaan lanjutan

Bagaimana Anda mencegah dua worker merotasi satu secret secara bersamaan?

Gunakan lease basis data atau distributed lock dengan fencing token, dan tulis token tersebut ke setiap pembaruan status. Worker yang pulih tanpa token saat ini tidak dapat menimpa status yang lebih baru; lease memerlukan pembaruan berkala dan masa kedaluwarsa yang jelas.

Bagaimana jika penyedia tidak memiliki API yang idempoten?

Simpan sidik jari permintaan (request fingerprint) dan pengidentifikasi sumber daya eksternal dalam tugas, lalu lakukan kueri ke penyedia sebelum mencoba kembali. Jika penyedia tidak dapat dikueri, jeda langkah tersebut untuk konfirmasi manusia alih-alih membuat lebih banyak kredensial secara membabi buta.

Mengapa tidak membiarkan setiap aplikasi membaca latest?

latest dapat mendorong nilai yang belum diverifikasi ke seluruh armada aplikasi secara instan. Versi immutable, peluncuran bertahap, dan pemeriksaan kesehatan membatasi radius dampak dan mempertahankan titik rollback.

Bagaimana Anda melindungi layanan saat tugas rotasi menumpuk?

Tetapkan kuota konkurensi per tenant dan penyedia, gunakan prioritas dan exponential backoff, serta pantau usia tugas tertua, tingkat kegagalan, dan sisa jendela pemulihan. Secret yang mendekati masa kedaluwarsa dapat diprioritaskan tanpa mengabaikan otorisasi atau idempotensi.

Apa yang dilakukan layanan setelah terjadi kompromi keamanan?

Jeda jadwal reguler untuk tugas yang terdampak, buat rotasi darurat berprioritas tinggi, persingkat jendela pengamatan peluncuran, dan pertahankan log forensik. Konfirmasikan bahwa konsumen kritis telah beralih sebelum mencabut nilai lama, lalu beri tahu tenant dan jalankan proses tanggap keamanan.