Perintah dan konteks
Sebuah platform B2B memiliki banyak layanan bisnis, masing-masing mengimplementasikan ulang pertanyaan “apakah pengguna ini dapat mengakses sumber daya ini?”. Bangun layanan kebijakan otorisasi multi-penyewa bersama yang mendukung peran, hubungan sumber daya, dan kondisi atribut. Pembaruan kebijakan memerlukan versi, dan kegagalan singkat pada layanan pusat tidak boleh menyebabkan akses lintas penyewa.
Fokusnya adalah jalur keputusan otorisasi dan batas konsistensinya. Jangan hanya menggambar basis data kebijakan; jelaskan konteks permintaan, publikasi kebijakan, pembatalan cache, dan dampak penolakan atau batas waktu habis (timeout) pada pemanggil.
Hal yang diuji oleh pewawancara
Pewawancara ingin Anda memisahkan Titik Keputusan Kebijakan (PDP) dari Titik Penegakan Kebijakan (PEP) dalam layanan bisnis, serta mendesain isolasi penyewa, propagasi versi, dan audit yang dapat dijelaskan. OPA mendokumentasikan pemisahan keputusan kebijakan dari penegakan; makalah Zanzibar menunjukkan kompromi dari pengurutan kausal dan latensi rendah pada skala otorisasi global.
Pertanyaan untuk diklarifikasi terlebih dahulu
Tanyakan tentang volume permintaan, target latensi, kompleksitas kebijakan, jumlah penyewa, kedalaman hubungan, dan persyaratan konsistensi. Perjelas siapa pembuat kebijakan, alur kerja persetujuan, batas waktu pencabutan, evaluasi offline, bidang sensitif dalam log keputusan, dan apakah pemanggil dapat menerapkan fail-closed dengan aman.
Struktur jawaban 30 detik
Saya akan mendefinisikan model otorisasi dan invarian “tidak ada akses lintas penyewa”, kemudian menggambar PEP, PDP, penyimpanan kebijakan, distribusi, dan audit. Kebijakan diberi versi per penyewa; PDP menyimpan versi yang disetujui dalam cache secara lokal atau dalam zona yang sama. Permintaan membawa subjek, tindakan, sumber daya, dan konteks yang diperlukan. Pencabutan berisiko tinggi memerlukan konfirmasi versi; jika PDP tidak tersedia, tindakan sensitif akan ditolak. Ukur latensi p99, keterlambatan propagasi, penolakan keliru, dan integritas audit.
Analisis langkah demi langkah
Langkah 1: Tentukan objek otorisasi dan input kebijakan
Gunakan bentuk permintaan yang konsisten: subjek, tindakan, sumber daya, dan konteks, dengan ruang nama penyewa dan sumber daya yang tidak ambigu. RBAC menangani pemberian peran, ABAC menangani atribut seperti departemen, perangkat, atau waktu, dan otorisasi berbasis hubungan menangani kasus seperti “pengguna ini adalah kolaborator dokumen”. Bahasa kebijakan harus dapat mengekspresikan izinkan, tolak, prioritas, dan kondisi tanpa mengharuskan setiap layanan menyusun aturannya sendiri.
Langkah 2: Pisahkan PEP, PDP, dan manajemen kebijakan
PEP berada di API gateway atau layanan bisnis, mengumpulkan identitas tepercaya, dan menegakkan izin atau tolak. PDP mengevaluasi dan mengembalikan keputusan, versi kebijakan, dan alasan opsional. Bidang manajemen menyunting, memvalidasi, menyetujui, memublikasikan, dan mengembalikan (rollback) kebijakan. OPA memisahkan keputusan dari penegakan dan mendukung penerapan lokal atau jaringan; pilih berdasarkan latensi dan ketersediaan.
Langkah 3: Desain penyimpanan penyewa dan publikasi berversi
Kebijakan, hubungan sumber daya, dan atribut membawa tenant_id, yang diperiksa pada setiap pembacaan. Publikasi membuat versi dan digest yang tidak dapat diubah, mengevaluasinya di sandbox, lalu mendistribusikannya secara batch ke PDP. Catat pembuat, penyetuju, waktu, dan cakupan. Pencabutan atau kebijakan keamanan dapat diprioritaskan dan mengharuskan versi lama kedaluwarsa dalam jendela waktu terbatas.
Langkah 4: Tangani konsistensi, caching, dan pencabutan
Kunci cache mencakup penyewa, subjek, tindakan, sumber daya, dan policy_version; hanya menggunakan ID pengguna tidak aman. Simpan izin berisiko rendah dalam cache dengan TTL terukur, tetapi gunakan TTL pendek atau pemeriksaan versi paksa untuk pencabutan, perubahan admin, dan sumber daya sensitif. PDP mengembalikan versi yang digunakan; layanan bisnis dapat menolak versi yang lebih lama. Penerapan multi-wilayah menyebarkan penanda versi (version watermark) alih-alih mengasumsikan pembatalan simultan.
Langkah 5: Desain mode kegagalan dan default yang aman
Tentukan perilaku untuk batas waktu PDP habis, distribusi kebijakan yang tertunda, sumber atribut yang tidak tersedia, dan alur audit yang mengalami kemacetan. Operasi penulisan sensitif, perubahan izin, dan ekspor menerapkan fail-closed; pembacaan berisiko rendah dapat menggunakan cache yang disetujui dan berbatas waktu. Pemanggil tidak boleh mengubah kesalahan jaringan menjadi izin (allow). Batasi ukuran kebijakan, rekursi hubungan, dan QPS per penyewa sehingga evaluasi kebijakan tidak menjadi vektor denial-of-service.
Langkah 6: Audit, keterjelasan, dan observabilitas
Catat decision_id, penyewa, ringkasan subjek, tindakan, ringkasan sumber daya, hasil, versi kebijakan, dan latensi; redaksi atau lakukan hash pada input sensitif. Log harus menjawab “siapa yang diizinkan melakukan apa, kapan, dan di bawah versi mana” tanpa menjadi celah kebocoran data baru. Pantau p50/p95/p99, cache hit, propagasi versi, rasio penolakan, batas waktu habis, dan percobaan ulang; buat peringatan untuk penolakan atau rollback yang tidak biasa.
Contoh jawaban berkualitas tinggi
Saya akan membagi sistem menjadi PEP di layanan bisnis, kluster PDP dalam zona, dan bidang manajemen independen. Permintaan membawa subjek, tindakan, sumber daya, dan konteks tepercaya. PDP mengevaluasi kebijakan RBAC, hubungan, dan atribut yang terisolasi per penyewa serta mengembalikan izinkan atau tolak, decisionid, dan policyversion. Pengeditan kebijakan divalidasi dan diuji, menjadi versi yang tidak dapat diubah, didistribusikan berdasarkan penyewa dan wilayah, serta mendukung rollback.
Kunci cache mencakup penyewa, subjek, tindakan, sumber daya, dan versi. Pembacaan biasa dapat menggunakan izin dengan TTL pendek, sedangkan pencabutan, perubahan izin, dan ekspor data memerlukan konfirmasi versi; pemanggil menolak hasil PDP yang lebih lama dari watermark yang diwajibkan. Batas waktu PDP habis atau atribut yang hilang menerapkan fail-closed untuk tindakan sensitif.
Setiap keputusan mencatat penyewa, ringkasan subjek, tindakan, ringkasan sumber daya, hasil, versi, dan latensi dengan input yang diredaksi. Metrik utama adalah latensi p99, rasio hit, keterlambatan propagasi, penolakan versi usang, kesalahan, dan integritas audit. Pendekatan ini memusatkan manajemen kebijakan sambil mempertahankan penegakan di batas layanan.
Kesalahan umum dan perbaikan
- Menggambar satu “microservice otorisasi”: tambahkan jalur PEP, PDP, manajemen, dan distribusi.
- Hanya menyebutkan RBAC: jelaskan bagaimana atribut dan hubungan masuk ke dalam keputusan.
- Melakukan caching hanya berdasarkan pengguna: sertakan penyewa, sumber daya, tindakan, dan versi kebijakan.
- Mengizinkan saat batas waktu habis: operasi sensitif menerapkan fail-closed dan penggunaan cache berisiko rendah didefinisikan secara eksplisit.
- Mencatat seluruh permintaan dalam log: redaksi input sambil tetap mempertahankan decision_id dan versi yang dapat dilacak.
Pertanyaan lanjutan dan tanggapan
Seberapa cepat pencabutan harus berlaku?
Klasifikasikan pencabutan berdasarkan risiko. Untuk tindakan administrator, ekspor, dan data sensitif, wajibkan versi kebijakan baru atau jendela propagasi terbatas yang singkat; pembacaan berisiko lebih rendah dapat menggunakan TTL terukur. Nyatakan targetnya dan pantau.
Haruskah PDP dijalankan secara lokal atau sebagai layanan bersama?
Gunakan PDP lokal atau zona yang sama untuk latensi dan isolasi kegagalan, dengan bidang manajemen bersama untuk distribusi kebijakan. PDP jaringan pusat dapat menyederhanakan pembaruan tetapi menambahkan ketergantungan pada setiap permintaan; pilih berdasarkan beban kerja dan uji mode kegagalannya.
Bagaimana Anda mencegah satu penyewa membaca kebijakan penyewa lain?
Sertakan identitas penyewa dalam permintaan yang diautentikasi, tegakkan dalam penyimpanan dan kunci cache, serta uji kueri lintas penyewa sebagai syarat rilis (release gate). Jangan pernah memercayai pengidentifikasi penyewa yang hanya disediakan oleh payload pemanggil.
Bagaimana Anda men-debug penolakan yang tidak terduga?
Kembalikan decision_id dan versi kebijakan, lalu periksa input yang diredaksi, aturan yang cocok, kesegaran atribut, dan status propagasi. Jangan mengekspos detail internal kebijakan yang sensitif kepada pengguna akhir; berikan tampilan penjelasan yang terkontrol kepada operator.