Gesaan dan konteks
Platform B2B mempunyai banyak perkhidmatan perniagaan, masing-masing melaksanakan semula logik “adakah pengguna ini boleh mengakses sumber ini?”. Bina perkhidmatan dasar keizinan berbilang penyewa kongsi yang menyokong peranan, hubungan sumber dan syarat atribut. Kemas kini dasar memerlukan versi, dan kegagalan perkhidmatan pusat yang singkat tidak boleh menyebabkan akses rentas penyewa.
Tumpuan utama ialah laluan keputusan keizinan dan sempadan ketekalannya. Jangan hanya melukis pangkalan data dasar; terangkan konteks permintaan, penerbitan dasar, pembatalan cache dan kesan penolakan atau tamat masa (timeout) terhadap pemanggil.
Perkara yang diuji oleh penemu bual
Mereka mahu anda mengasingkan Titik Keputusan Dasar (PDP) daripada Titik Penguatkuasaan Dasar (PEP) dalam perkhidmatan perniagaan, serta mereka bentuk pengasingan penyewa, penyebaran versi dan audit yang boleh diterangkan. OPA mendokumentasikan pemisahan keputusan dasar daripada penguatkuasaan; kertas kerja Zanzibar menunjukkan pertukaran antara susunan sebab akibat dan kependaman rendah pada skala keizinan global.
Soalan untuk dijelaskan terlebih dahulu
Tanya tentang jumlah permintaan, sasaran kependaman, kerumitan dasar, bilangan penyewa, kedalaman hubungan dan keperluan ketekalan. Jelaskan pengarang dasar, aliran kerja kelulusan, tarikh akhir pembatalan, penilaian luar talian, medan sensitif dalam log keputusan dan sama ada pemanggil boleh gagal secara selamat dengan menutup akses (fail closed).
Struktur jawapan 30 saat
Saya akan mentakrifkan model keizinan dan tak varian “tiada akses rentas penyewa”, kemudian melukis PEP, PDP, storan dasar, pengedaran dan audit. Dasar diberi versi mengikut penyewa; PDP menyimpan versi yang diluluskan dalam cache secara setempat atau dalam zon yang sama. Permintaan membawa subjek, tindakan, sumber dan konteks yang diperlukan. Pembatalan berisiko tinggi memerlukan pengesahan versi; jika PDP tidak tersedia, tindakan sensitif akan ditolak. Ukur kependaman p99, kelewatan penyebaran, penolakan palsu dan integriti audit.
Analisis langkah demi langkah
Langkah 1: Tentukan objek keizinan dan input dasar
Gunakan bentuk permintaan yang konsisten: subjek, tindakan, sumber dan konteks, dengan ruang nama penyewa dan sumber yang jelas. RBAC mengendalikan pemberian peranan, ABAC mengendalikan atribut seperti jabatan, peranti atau masa, dan keizinan berasaskan hubungan mengendalikan kes seperti “pengguna ini ialah kolaborator dokumen”. Bahasa dasar mesti menyatakan izin, tolak, keutamaan dan syarat tanpa memerlukan setiap perkhidmatan menggubal peraturannya sendiri.
Langkah 2: Asingkan PEP, PDP dan pengurusan dasar
PEP kekal dalam get laluan API (API gateway) atau perkhidmatan perniagaan, mengumpulkan identiti dipercayai dan menguatkuasakan izin atau tolak. PDP menilai dan mengembalikan keputusan, versi dasar dan sebab pilihan. Satah pengurusan menyunting, mengesahkan, meluluskan, menerbitkan dan mengundur (rollback) dasar. OPA memisahkan keputusan daripada penguatkuasaan dan menyokong penggunaan setempat atau rangkaian; pilih berdasarkan kependaman dan ketersediaan.
Langkah 3: Reka bentuk storan penyewa dan penerbitan berversi
Dasar, hubungan sumber dan atribut membawa tenant_id, yang disemak pada setiap bacaan. Penerbitan mencipta versi dan ringkasan (digest) yang tidak boleh diubah, menilainya dalam kotak pasir (sandbox), kemudian mengedarkannya secara kelompok kepada PDP. Catatkan pengarang, pelulus, masa dan skop. Dasar pembatalan atau keselamatan boleh diberi keutamaan dan memerlukan versi lama tamat tempoh dalam tempoh masa yang terhad.
Langkah 4: Kendalikan ketekalan, caching dan pembatalan
Kunci cache merangkumi penyewa, subjek, tindakan, sumber dan policy_version; menggunakan ID pengguna sahaja adalah tidak selamat. Simpan kebenaran berisiko rendah dalam cache dengan TTL yang diukur, tetapi gunakan TTL pendek atau semakan versi paksa untuk pembatalan, perubahan pentadbir dan sumber sensitif. PDP mengembalikan versi yang digunakan; perkhidmatan perniagaan boleh menolak versi yang lebih lama. Penggunaan pelbagai wilayah menyebarkan tanda aras versi (version watermark) dan bukannya menganggap pembatalan serentak.
Langkah 5: Reka bentuk mod kegagalan dan lalai yang selamat
Takrifkan tingkah laku untuk tamat masa PDP, pengedaran dasar yang tertangguh, sumber atribut yang tidak tersedia dan talian paip audit yang sesak. Operasi penulisan sensitif, perubahan kebenaran dan eksport gagal secara tertutup (fail closed); bacaan berisiko rendah boleh menggunakan cache yang diluluskan dan terhad masa. Pemanggil tidak boleh sekali-kali menukar ralat rangkaian kepada izin (allow). Hadkan saiz dasar, rekursi hubungan dan QPS bagi setiap penyewa supaya penilaian dasar tidak menjadi vektor penafian perkhidmatan (denial-of-service).
Langkah 6: Audit, kebolehterangan dan keterlihatan
Catatkan decision_id, penyewa, ringkasan subjek, tindakan, ringkasan sumber, hasil, versi dasar dan kependaman; lakukan penyuntingan (redact) atau cincangan (hash) pada input sensitif. Log harus menjawab “siapa yang dibenarkan melakukan apa, bila dan di bawah versi mana” tanpa menjadi punca kebocoran data yang baharu. Pantau p50/p95/p99, ketepatan cache (cache hits), penyebaran versi, nisbah penolakan, tamat masa dan percubaan semula; berikan amaran tentang penolakan atau pengunduran yang luar biasa.
Contoh jawapan berkualiti tinggi
Saya akan membahagikan sistem kepada PEP dalam perkhidmatan perniagaan, kluster PDP dalam zon dan satah pengurusan bebas. Permintaan membawa subjek, tindakan, sumber dan konteks dipercayai. PDP menilai dasar RBAC, hubungan dan atribut yang diasingkan mengikut penyewa serta mengembalikan izin atau tolak, decisionid dan policyversion. Pindaan dasar disahkan dan diuji, menjadi versi tidak boleh diubah, diedarkan mengikut penyewa dan wilayah, serta menyokong pengunduran.
Kunci cache merangkumi penyewa, subjek, tindakan, sumber dan versi. Bacaan biasa boleh menggunakan kebenaran dengan TTL pendek, manakala pembatalan, perubahan kebenaran dan eksport data memerlukan pengesahan versi; pemanggil menolak hasil PDP yang lebih lama daripada watermark yang diperlukan. Tamat masa PDP atau atribut yang hilang akan gagal secara tertutup untuk tindakan sensitif.
Setiap keputusan merekodkan penyewa, ringkasan subjek, tindakan, ringkasan sumber, hasil, versi dan kependaman dengan input yang disunting. Metrik teras ialah kependaman p99, kadar capaian, kelewatan penyebaran, penolakan versi lapuk, ralat dan integriti audit. Ini memusatkan pengurusan dasar sambil mengekalkan penguatkuasaan pada sempadan perkhidmatan.
Kesilapan biasa dan penambahbaikan
- Melukis satu “mikroperkhidmatan keizinan”: tambahkan laluan PEP, PDP, pengurusan dan pengedaran.
- Hanya menyebut RBAC: terangkan cara atribut dan hubungan dimasukkan ke dalam keputusan.
- Menyimpan cache mengikut pengguna sahaja: sertakan penyewa, sumber, tindakan dan versi dasar.
- Membenarkan semasa tamat masa: operasi sensitif gagal secara tertutup dan penggunaan cache berisiko rendah dinyatakan secara eksplisit.
- Merekodkan keseluruhan permintaan: sunting input sambil mengekalkan decision_id dan versi yang boleh dikesan.
Soalan susulan dan jawapan
Berapa cepatkah sesuatu pembatalan mesti berkuat kuasa?
Kelaskan pembatalan mengikut risiko. Bagi tindakan pentadbir, eksport dan data sensitif, wajibkan versi dasar yang baharu atau tetingkap penyebaran terhad yang pendek; bacaan berisiko lebih rendah boleh menggunakan TTL yang diukur. Nyatakan sasaran dan pantaunya.
Patutkah PDP dijalankan secara setempat atau sebagai perkhidmatan kongsi?
Gunakan PDP setempat atau dalam zon yang sama untuk kependaman dan pengasingan kegagalan, dengan satah pengurusan kongsi untuk pengedaran dasar. PDP rangkaian pusat boleh memudahkan kemas kini tetapi menambah kebergantungan pada setiap permintaan; pilih mengikut beban kerja dan uji mod kegagalannya.
Bagaimanakah anda menghalang satu penyewa daripada membaca dasar penyewa lain?
Letakkan identiti penyewa dalam permintaan yang disahkan, kuat kuasakannya dalam storan dan kunci cache, serta uji pertanyaan rentas penyewa sebagai syarat pelepasan (release gate). Jangan sekali-kali mempercayai pengecam penyewa yang hanya dibekalkan oleh muatan (payload) pemanggil.
Bagaimanakah anda menyahpepijat penolakan yang tidak dijangka?
Kembalikan decision_id dan versi dasar, kemudian periksa input yang disunting, peraturan yang sepadan, kesegaran atribut dan keadaan penyebaran. Jangan dedahkan butiran dalaman dasar yang sensitif kepada pengguna akhir; berikan paparan penjelasan yang terkawal kepada pengendali.