Wawancara system design: Membangun layanan keputusan otorisasi terpusat

Perintah dan konteks

Beberapa layanan bisnis perlu menjawab pertanyaan yang sama: siapa yang dapat melakukan tindakan apa pada sumber daya yang mana? Rancang layanan keputusan bersama yang menerima subjek, tindakan, sumber daya, dan konteks, mengembalikan ALLOW atau DENY, serta mendukung pengguna, akun layanan, sumber daya hierarkis, batas-batas tenant, dan perubahan kebijakan.

Gunakan asumsi wawancara berikut: 100.000 pemeriksaan otorisasi per detik pada baseline, puncak 3x rata-rata, target latensi p99 sebesar 20 ms, penulisan kebijakan jauh lebih jarang dibandingkan pembacaan, dan pemanggil yang harus membedakan penolakan eksplisit dari ketidaktersediaan sementara layanan otorisasi. Ini adalah asumsi masalah, bukan tolok ukur industri. Pengambilan pembayaran, penerbitan kunci, dan penulisan database bisnis tetap berada di luar layanan ini.

Hal yang diuji oleh pewawancara

Jawaban yang kuat mengubah otorisasi menjadi empat tupel dan kontrak konsistensi daripada sekadar mengatakan “tambahkan layanan RBAC”:

• memodelkan batas untuk subjek, sumber daya, tindakan, konteks, hierarki, dan referensi lintas-tenant;
• kapan kebijakan berbasis ACL, RBAC, ABAC, atau relasi cocok digunakan, dan cara mencegah logika kebijakan menyimpang di berbagai layanan;
• bagaimana jalur baca keputusan, jalur tulis kebijakan, cache, dan peristiwa invalidasi bekerja bersama;
• kapan perubahan kebijakan mulai terlihat dan apakah cache usang masih dapat mengizinkan akses;
• apakah pemadaman (outage) bersifat fail-open atau fail-closed untuk setiap kelas risiko;
• bagaimana log, penjelasan, pemutaran ulang (replay), dan injeksi kegagalan (fault injection) membuktikan penolakan yang benar tanpa kebocoran lintas-tenant.

Pertanyaan klarifikasi yang perlu diajukan

Tanyakan batasan-batasan yang mengubah desain:

1. Berapa jendela konsistensinya? Jika pencabutan hak akses (revocation) harus berlaku dalam 5 detik, sewa cache (cache leases) dan token versi harus memenuhi 5 detik; toleransi berskala menit memungkinkan TTL yang lebih lama.
2. Apakah pemeriksaannya berupa pencarian sumber daya tunggal atau kueri relasi? “Dapatkah pengguna ini membaca dokumen?” mungkin bergantung pada keanggotaan, pewarisan grup, dan sumber daya induk; hal ini menentukan apakah graf relasi atau pemeriksaan batch diperlukan.
3. Apa yang diizinkan selama pemadaman? Konten publik mungkin diizinkan untuk fail-open, sedangkan pembayaran, data pribadi, dan administrasi biasanya fail-closed. Pilihlah berdasarkan risiko, bukan kebiasaan.
4. Siapa yang menulis dan meninjau kebijakan? Publikasi langsung oleh tim bisnis memerlukan versi, persetujuan, pemeriksaan statis, dan rollback; alur tulis khusus tim keamanan dapat mengurangi area kontrol.
5. Apakah pemanggil membutuhkan penjelasan? Debugging mungkin memerlukan ID aturan yang cocok, tetapi penjelasan yang ditampilkan ke klien tidak boleh mengungkapkan sumber daya atau kebijakan milik tenant lain.

Kerangka jawaban 30 detik

Mulailah dengan struktur ini:

“Saya memodelkan permintaan sebagai (principal, action, resource, context). Mesin kebijakan mengembalikan izinkan (allow), tolak (deny), versi kebijakan, dan ID aturan internal saat debugging terkontrol membutuhkannya. Control plane mengelola kebijakan dan data relasi yang dicakup per tenant; data plane mengevaluasi snapshot terversi yang immutable dalam cache baca-saja lokal. Publikasi memancarkan peristiwa invalidasi yang dapat diputar ulang, dan pemanggil mengirimkan versi kebijakan minimum sehingga snapshot usang tidak dapat menimpa keputusan yang lebih baru secara diam-diam. Jalur sensitif bersifat fail-closed ketika otorisasi tidak tersedia; pembacaan berisiko rendah mengalami degradasi hanya di bawah kebijakan produk yang eksplisit. Saya memvalidasi propagasi pencabutan, batas lintas-tenant, race condition pada cache, dan kegagalan dependensi dengan injeksi kegagalan serta pemutaran ulang.”

Ini memberikan model, aliran data, konsistensi, dan perilaku kegagalan sebelum pertanyaan lanjutan memilih satu area untuk diperluas.

Pembahasan mendalam langkah demi langkah

Tentukan semantik kebijakan terlebih dahulu. Subjek dapat berupa pengguna, akun layanan, atau grup. Sumber daya dapat berupa tenant, proyek, atau dokumen dalam hierarki. Tindakan harus berupa kosakata terbatas seperti read, write, dan share. Konteks dapat mencakup status perangkat, sumber, atau waktu, tetapi bidang klien yang tidak diverifikasi bukanlah fakta yang tepercaya. Panduan ABAC dari NIST memperlakukan atribut subjek, objek, dan lingkungan sebagai masukan keputusan; kebijakan relasi merepresentasikan keanggotaan sebagai edge yang dapat dilalui (traversable).

Pisahkan control plane dan data plane. Control plane mengedit, memvalidasi, menyetujui, membuat versi, dan membatalkan (rollback) kebijakan. Data plane hanya memuat snapshot immutable yang dipublikasikan dan menjawab pemeriksaan. Layanan bisnis tidak boleh masing-masing membawa parser kebijakan yang berbeda. Suatu publikasi menciptakan versi monotonik dan peristiwa invalidasi; data plane menukar snapshot secara atomik sehingga kumpulan aturan yang baru terpublikasi setengah tidak akan pernah terlihat.

Rancang API pemeriksaan. Antarmuka internal dapat berupa:

Check(principal, action, resource, context, min_policy_version)
  -> decision, policy_version, rule_id, expires_at
BatchCheck(principal, [(action, resource, context)...])
  -> decisions[]

rule_id ditujukan untuk log dan debugging terkontrol. Pemanggil lintas-tenant tidak boleh mengetahui keberadaan sumber daya melalui detail kesalahan. Pemeriksaan batch mengurangi round trip tetapi membutuhkan batasan pada ukuran batch dan biaya evaluasi.

Tangani konsistensi dan caching. Cache lokal dapat memenuhi target 20 ms, tetapi pencabutan akses tidak dapat mengandalkan TTL saja. Pemanggil dapat mengirimkan versi kebijakan terakhir yang diamatinya; jika versi lokal tertinggal, layanan akan membaca replika bersama atau mengembalikan “tidak dapat diputuskan sementara”. Peristiwa invalidasi memerlukan kursor pemutaran ulang dan rekonsiliasi berkala sehingga notifikasi yang hilang tidak meninggalkan status allow yang usang. Untuk sumber daya yang sangat sensitif, sertakan versi sumber daya atau sewa pendek sehingga versi izin dan objek diperiksa secara bersamaan.

Pilih perilaku saat terjadi pemadaman. Jika data plane tidak dapat menjangkau control plane, snapshot yang dimuat dan belum kedaluwarsa dapat terus melayani permintaan. Setelah kedaluwarsa, tindakan pembayaran, data pribadi, dan administratif harus bersifat fail-closed; konten statis publik dapat bersifat fail-open hanya di bawah aturan produk yang disetujui. Batas waktu (timeout) harus berupa UNAVAILABLE eksplisit, bukan DENY yang terselubung, atau logika bisnis akan salah mengartikan kegagalan infrastruktur sebagai kegagalan izin pengguna.

Isolasi tenant dan penyalahgunaan. Setiap objek kebijakan dan kunci cache membawa ID tenant. Server memperoleh tenant dari identitas yang terverifikasi alih-alih memercayai bidang request-body sembarangan. Terapkan kuota per subjek, tenant, dan batch; batasi kedalaman relasi serta kompleksitas kebijakan sehingga satu tenant tidak dapat menghabiskan sumber daya evaluasi.

Audit dan verifikasi. Catat hash permintaan, subjek, tindakan, tipe sumber daya, keputusan, versi kebijakan, latensi, dan kelas kegagalan; simpan nilai-nilai sensitif sebagai pengidentifikasi yang tidak dapat diubah kembali. Uji cache usang setelah pencabutan akses, siklus pewarisan grup, ID sumber daya yang identik di seluruh tenant, crash selama publikasi, peristiwa invalidasi duplikat atau hilang, restart data plane, dan batas waktu dependensi. Penerimaan memerlukan pemutaran ulang versi kebijakan dan penjelasan keputusan, bukan sekadar mengembalikan DENY.

Perkirakan bottleneck. Pada baseline 100.000 pemeriksaan per detik dan 300.000 pada puncaknya, 2 KB per permintaan berarti sekitar 600 MB/s ingress puncak. Mengirimkan kebijakan penuh pada setiap permintaan memperbesar latensi dan bandwidth, jadi lebih baik gunakan snapshot lokal, pemeriksaan batch, dan replika baca. Jika penelusuran relasi menjadi bottleneck, lakukan sharding berdasarkan tenant atau sumber daya serta batasi kedalaman dan fan-out. Jelaskan bagaimana uji beban akan menggantikan asumsi-asumsi ini.

Contoh jawaban berkualitas tinggi

“Saya pertama-tama akan mengonfirmasi target pencabutan akses dan batas keamanan selama kegagalan. Asumsikan 300.000 pemeriksaan per detik pada puncaknya, target p99 20 ms, dan pencabutan efektif dalam 5 detik. Saya akan memisahkan control plane dan data plane. Control plane menyimpan ACL yang dicakup per tenant, relasi grup, dan kondisi ABAC; sebelum menerbitkan, sistem memeriksa sintaksis, siklus, dan referensi lintas-tenant, lalu membuat snapshot immutable dan versi monotonik. Data plane di setiap wilayah mengevaluasi (subject, action, resource, context) dari cache baca-saja lokal. Peristiwa invalidasi membawa kursor dan dapat diputar ulang; pemanggil dapat mengirimkan min_policy_version, sehingga cache yang tertinggal akan membaca replika bersama atau mengembalikan UNAVAILABLE.

Untuk pembayaran, data pribadi, dan tindakan administratif, snapshot yang kedaluwarsa atau dependensi yang tidak tersedia akan fail-closed; degradasi konten publik memerlukan persetujuan produk yang eksplisit. Hasil membawa versi kebijakan dan ID aturan internal. Log mencatat keputusan, latensi, dan kelas kesalahan tanpa mencerminkan data tenant lain. Versi sumber daya atau sewa pendek melindungi objek yang paling sensitif dari izin lama setelah pencabutan. Uji beban mencakup lalu lintas puncak dan penelusuran relasi terdalam; injeksi kegagalan mencakup invalidasi yang hilang, race condition pencabutan, ID lintas-tenant, dan restart regional. Rekonsiliasi dan pemutaran ulang terversi harus membuktikan bahwa tidak ada status allow yang tidak dapat dijelaskan.”

Ini menghubungkan asumsi, model, konsistensi, penanganan kegagalan, dan verifikasi. Dalam wawancara, sesuaikan detail seiring perubahan batasan; 300.000 pemeriksaan per detik dan 5 detik bukanlah fakta produksi yang universal.

Kesalahan umum

• Mereduksi setiap kasus menjadi RBAC. Peran tidak secara alami mengekspresikan hierarki, relasi yang diwarisi, atau kondisi lingkungan. Tentukan semantik izin sebelum memilih model.
• Menggunakan TTL tetap sebagai mekanisme pencabutan akses. TTL membatasi satu kasus keusangan tetapi tidak menyelesaikan notifikasi yang hilang atau perlombaan versi. Tambahkan versi, invalidasi yang dapat diputar ulang, dan rekonsiliasi.
• Selalu fail-open atau selalu fail-closed. Risiko sumber daya berbeda-beda. Tentukan perilaku dari standar keamanan minimum, kesegaran snapshot, dan kemampuan pemulihan bisnis (business reversibility).
• Menyalin logika kebijakan ke setiap layanan. Beberapa parser yang berbeda akan menyimpang dan menghasilkan penolakan yang berbeda-beda. Berikan versi pada kebijakan dan panggil satu antarmuka keputusan.
• Mengembalikan “sumber daya tidak ditemukan” atau aturan terperinci. Hal itu membocorkan informasi lintas-tenant. Gunakan kesalahan eksternal yang stabil dan ID aturan internal yang terkontrol.
• Hanya menguji jalur izinkan (allow) yang normal. Pencabutan akses, pemutaran ulang, siklus, dan batas tenant adalah titik di mana otorisasi sering kali gagal. Gunakan injeksi kegagalan dan pemutaran ulang terversi.

Pertanyaan lanjutan dan tanggapan

Bisakah cache lokal tetap dipertahankan jika pencabutan akses harus instan?

Bisa, tetapi cache tidak dapat memutuskan sendiri. Pencabutan harus membuat versi yang dapat diamati secara global atau invalidasi sewa. Permintaan sensitif membawa versi kebijakan minimum; cache yang tertinggal melewati data lokal atau menunggu konfirmasi. Jika konfirmasi tidak sesuai dengan anggaran waktu, kembalikan UNAVAILABLE atau tolak daripada menggunakan izin lama secara diam-diam.

Bagaimana jika penelusuran relasi menemukan siklus melalui grup induk?

Tolak siklus selama publikasi, lalu tetap terapkan batas kedalaman maksimum, jumlah node, dan anggaran waktu saat runtime. Evaluator melacak node yang telah dikunjungi, menghentikan cabang yang berulang, dan mengembalikan kesalahan internal yang dapat didiagnosis. Suatu siklus tidak boleh mengubah satu pemeriksaan menjadi pekerjaan tanpa batas.

Bagaimana Anda membuktikan tidak ada otorisasi lintas-tenant?

Wajibkan cakupan tenant dalam namespace kebijakan dan prefiks kunci cache, serta turunkan tenant subjek dari identitas sisi server. Hasilkan ID sumber daya yang identik di bawah tenant yang berbeda dengan pengujian berbasis properti (property tests); setiap izin harus memenuhi kesetaraan tenant antara subjek, sumber daya, dan kebijakan. Tambahkan sampling log dan pemutaran ulang jalur penolakan.

Haruskah Anda meniru model konsistensi eksternal Zanzibar?

Tidak. Pilih token versi, sewa, atau konsistensi yang lebih kuat berdasarkan target pencabutan akses dan risiko bisnis. Jika suatu produk menjanjikan bahwa anggota yang baru saja dihapus tidak dapat terus membaca objek lama, pengurutan kausal dan versi objek dapat dibenarkan. Untuk konten publik berisiko rendah, konsistensi yang lebih lemah dan caching yang lebih lama mungkin lebih sederhana. Nyatakan janji tersebut beserta konsekuensi biayanya.