Soalan dan Senario yang Sesuai
Pasukan platform mahu peraturan seperti "pangkalan data tidak boleh bersifat awam," "hanya imej yang ditandatangani boleh dijalankan," dan "peranan hanya boleh membaca penyewa (tenant) miliknya sendiri" menjadi boleh diuji, boleh disemak, dan dikuatkuasakan secara automatik. Penemu duga meminta anda menerangkan Policy as Code dan menetapkan sempadan antara keputusan dasar dan pelaksanaan perniagaan.
Anggap permintaan tiba daripada API, CI/CD, atau perubahan infrastruktur; input dasar ialah JSON berstruktur; dan dasar memerlukan versi, pengembalian semula (rollback), serta kebolehauditan. Soalan ini adalah mengenai sempadan dan penaakulan, bukan komitmen kepada OPA, Rego, atau satu vendor tertentu.
Perkara yang Dinilai oleh Penemu Duga
- Sama ada anda mengasingkan tanggungjawab takrifan dasar, pengiraan keputusan, dan penguatkuasaan (enforcement).
- Sama ada anda mengetahui bahawa enjin dasar boleh mengembalikan hasil berstruktur dan bukannya hanya boolean.
- Sama ada anda mengendalikan ketekalan versi dasar dan input, masa tamat (timeouts), penyimpanan cache (caching), dan penafian lalai (default deny).
- Sama ada anda menganggap kod dasar sebagai perisian yang memerlukan semakan, ujian, pelepasan, dan audit, bukan sebagai konfigurasi yang disalin.
Jawapan yang lemah menyatakan "gunakan OPA untuk autorisasi." Jawapan yang kukuh meletakkan Policy Enforcement Point pada sempadan permintaan, mengekalkan Policy Decision Point tertumpu pada pengiraan, dan menjadikan setiap keputusan boleh dijelaskan, boleh dimainkan semula (replayable), dan boleh dikesan.
Soalan untuk Dijelaskan Sebelum Menjawab
- Adakah keputusan itu untuk akses masa jalanan (runtime) atau pematuhan pra-penyebaran? Keputusan masa jalanan menekankan kependaman dan ketersediaan; semakan penyebaran menekankan maklum balas dan penyekatan.
- Siapakah yang membekalkan identiti, penyewa, label sumber, dan keadaan persekitaran, dan adakah medan tersebut boleh dipercayai? Input yang hilang tidak boleh dibiarkan menjadi allow secara senyap.
- Apabila berlaku kegagalan, patutkah sistem bertindak sebagai default deny, merosot kepada allow, atau meminta kelulusan manusia? Jawapannya bergantung pada impak tindakan dan matlamat ketersediaan.
- Bolehkah penerbitan dasar bebas daripada pelepasan aplikasi? Pelepasan bebas memerlukan pengikatan versi, semakan keserasian, dan pengembalian semula yang pantas.
- Apakah yang mesti terkandung dalam rekod audit? Jika input termasuk data peribadi atau rahsia, log memerlukan penyuntingan (redaction) sebelum penyimpanan atau pemuatan naik.
Kerangka Jawapan 30 Saat
"Policy as Code meletakkan peraturan yang boleh dilaksanakan ke dalam kawalan versi, semakan, dan ujian. Permintaan sampai ke PEP, yang mengumpul dan menormalkan subjek, tindakan, sumber, dan konteks, kemudian memanggil PDP dengan input yang dinormalkan dan versi dasar. PDP mengembalikan keputusan berstruktur seperti allow, deny, sebab, dan kewajipan (obligations); PEP sebenarnya menyekat atau meneruskan tindakan tersebut. Saya akan menggunakan default deny, cache terhad dan berversi, serta log keputusan yang diredaksikan. Sebelum pelepasan, saya akan menjalankan semakan main semula dan canary, serta menjadikan pengecualian kecemasan terikat masa, diluluskan, dan boleh diaudit."
Jawapan Terperinci Langkah demi Langkah
1. Tentukan objek dan sempadan dasar
Terjemahkan peraturan bahasa semula jadi kepada subjek, tindakan, sumber, syarat, dan hasil. "Perkhidmatan tidak boleh mendedahkan port awam yang tidak disulitkan" boleh bermakna: subjek ialah saluran paip penyebaran, tindakan ialah mencipta perkhidmatan, sumber ialah konfigurasi perkhidmatan, syarat ialah atribut port dan rangkaian, dan hasilnya ialah deny dengan mesej pemulihan.
PDP membaca input yang dinormalkan dan dasar serta mengembalikan allow, deny, warn, atau data berstruktur yang lebih kaya. PEP berada di API, pengawal kemasukan (admission controller), tugasan CI, atau sempadan panggilan perkhidmatan dan menukar hasil kepada sekat, teruskan, mutasi, atau eskalasi manusia.
caller -> PEP: subject, action, resource, context
PEP -> PDP: normalized input + policy version
PDP -> PEP: decision, reasons, obligations, decision_id
PEP -> target: enforce decision or stop request
PEP -> audit: redacted decision recordDokumentasi OPA secara eksplisit mengasingkan pembuatan keputusan daripada penguatkuasaan, dan panduan AWS menerangkan PDP dengan PEP pada API. Sempadan tersebut membolehkan satu set peraturan melayani pelbagai titik masuk tanpa menganggap bahawa enjin dasar melakukan transaksi perniagaan.
2. Normalkan input dan kendalikan medan yang hilang
Format mentah berbeza mengikut titik masuk: CI mungkin menyediakan pelan YAML, API permintaan HTTP, dan panggilan perkhidmatan satu objek. PEP atau lapisan pengesahan harus menukarnya kepada bentuk dalaman yang stabil dan melampirkan metadata sumber, cap masa, dan versi data.
Apabila penyewa, pemilik, atau keadaan persekitaran hilang, default deny adalah lebih selamat daripada membuat tekaan. Dasar harus membezakan deny eksplisit daripada "tidak dapat memutuskan," membolehkan PEP meminta kelulusan atau mencuba semula; nilai tidak ditentukan tidak boleh dianggap sebagai allow.
{
"subject": {"id": "u-17", "tenant": "t-3", "roles": ["reader"]},
"action": "read",
"resource": {"type": "invoice", "id": "inv-9", "tenant": "t-3"},
"context": {"environment": "prod", "authn_level": "mfa"},
"policy_version": "2026-06-18.4"
}3. Anggap dasar sebagai perisian yang boleh diuji
Fail dasar adalah milik Git dan harus lulus semakan sintaks, ujian unit, kes adversari, dan semakan kod. Ujian mesti merangkumi allow dan penyewa bersebelahan, medan yang hilang, identiti tamat tempoh, peraturan yang bercanggah, dan laluan lalai.
package invoices
default allow := false
allow if {
input.action == "read"
input.subject.tenant == input.resource.tenant
"reader" in input.subject.roles
}Tetapkan versi dasar dan snapshot data dalam ujian. Jika peraturan bergantung pada direktori langsung atau panggilan rangkaian, tentukan had masa tamat dan keusangan sebelum memutuskan sama ada cache tempatan boleh diterima.
4. Reka bentuk penerbitan, cache, dan pengembalian semula
Pelepasan dasar memerlukan versi, semakan keserasian, dan pengembalian semula seperti pelepasan perkhidmatan. PDP boleh dijalankan sebagai sidecar tempatan, perpustakaan, atau perkhidmatan berpusat: pelaksanaan tempatan mengurangkan kependaman rangkaian, manakala pemusatan memudahkan pengurusan. Pilihan bergantung pada kelajuan kemas kini, radius impak kegagalan, dan keperluan ketekalan.
Hanya simpan dalam cache keputusan dengan jangka hayat yang jelas, yang mengikat subjek, sumber, versi dasar, dan versi data kebenaran. Pembatalan kebenaran, migrasi penyewa, dan tindakan berisiko tinggi tidak boleh menggunakan cache yang panjang yang tidak boleh dibatalkan dengan cepat. Apabila PDP mengalami masa tamat, PEP memilih deny, kelulusan, atau laluan terhad yang telah diluluskan sebelumnya mengikut risiko tindakan.
5. Rekod keputusan yang boleh dijelaskan dan diredaksikan
Setiap keputusan memerlukan sekurang-kurangnya versi dasar, ringkasan input, hasil, sebab, ID keputusan, dan identiti PEP untuk main semula insiden. Input mungkin mengandungi nama pengguna, token, atau rahsia, jadi lapisan pengelogan mesti mengalih keluar atau menutup (mask) medan sensitif sebelum dimuat naik atau disimpan.
Keputusan allow juga boleh membawa kewajipan (obligations), seperti menulis peristiwa audit, mengehadkan medan, atau memerlukan pengesahan langkah tambahan. PDP mengembalikan kewajipan tersebut; PEP melaksanakannya dan melakukan deny atau eskalasi jika ia tidak dapat berbuat demikian.
Contoh Jawapan Berkualiti Tinggi
Saya akan mentakrifkan Policy as Code sebagai menyatakan kekangan keselamatan, pematuhan, dan operasi sebagai peraturan yang berversi, boleh diuji, dan boleh dibaca mesin. Permintaan sampai ke PEP, yang mengesahkan subjek dan menormalkan subjek, tindakan, sumber, dan konteks sebelum menghantarnya bersama versi dasar kepada PDP. PDP mengira keputusan dan mengembalikan allow, deny, sebab, kewajipan, dan ID keputusan. PEP, bukan PDP, yang menyekat permintaan, meneruskan tindakan perniagaan, atau memulakan kelulusan manusia.
Saya akan membuat versi dasar dan data input, menyemak dasar dalam Git, dan mengujinya dengan snapshot yang boleh dimainkan semula. Tingkah laku masa jalanan secara lalai adalah deny, dan cache diikat pada versi dasar dan data kebenaran; pembatalan membatalkan keputusan berisiko tinggi dengan cepat. Gangguan PDP tidak seharusnya secara automatik menjadi allow, jadi saya akan memilih mod kegagalan mengikut risiko tindakan. Akhir sekali, saya akan menulis log keputusan yang diredaksikan untuk audit dan pengembalian semula. Peraturan yang sama kemudiannya boleh melayani titik masuk API, CI, dan infrastruktur sementara setiap titik masuk mengekalkan tanggungjawab penguatkuasaan.
Kesilapan Biasa
- Kesilapan → Membenarkan PDP mengemas kini pangkalan data atau menyebarkan infrastruktur → Sebab ia gagal → Keputusan dan kesan sampingan menjadi tidak dapat dipisahkan serta sukar untuk dicuba semula atau diaudit → Pembetulan → Kembalikan keputusan dan kewajipan daripada PDP; biarkan PEP atau perkhidmatan perniagaan melaksanakan kesan tersebut.
- Kesilapan → Default kepada allow apabila PDP mengalami masa tamat → Sebab ia gagal → Kerosakan rangkaian menjadi pintasan kebenaran → Pembetulan → Pilih deny, kelulusan, atau laluan pendek yang diluluskan sebelumnya mengikut risiko tindakan.
- Kesilapan → Hanya mencatat log allow atau deny → Sebab ia gagal → Tiada siapa yang dapat menerangkan peraturan dan input mana yang menghasilkan keputusan tersebut → Pembetulan → Rekod versi dasar, sebab, ID keputusan, dan ringkasan input yang diredaksikan.
- Kesilapan → Menganggap cache dasar sebagai kebenaran kekal → Sebab ia gagal → Pembatalan dan perubahan penyewa tidak dapat berkuat kuasa dengan segera → Pembetulan → Ikat versi dan tempoh luput, serta batalkan pada peristiwa kritikal.
Soalan Susulan dan Maklum Balas
Jika PDP berpusat tidak tersedia, adakah setiap bacaan mesti gagal?
Kelaskan tindakan tersebut terlebih dahulu. Perubahan kebenaran, pemindahan, dan bacaan rentas penyewa harus default deny; bacaan berisiko rendah boleh menggunakan keputusan tempatan berjangka hayat pendek dan terikat versi, dengan penggunaan cache direkodkan dan diaudit selepas pemulihan. Ketersediaan bukanlah sebab sejagat untuk membenarkan (allow).
Bagaimana jika dasar dan direktori identiti dikemas kini pada masa yang sama?
Bawa versi data dasar dan identiti dalam keputusan, dan minta PEP menyemak versi atau pajakan sebelum penguatkuasaan. Peristiwa pembatalan membatalkan cache; jika versi tidak dapat disahkan, nafikan (deny) atau nilaikan semula. Uji kemas kini serentak dan mesej tertangguh supaya keputusan lama tidak boleh ditulis semula.
Jika satu peraturan membenarkan (allow) dan satu lagi menafikan (deny), yang mana satu menang?
Tentukan keutamaan secara eksplisit; jangan sekali-kali bergantung pada susunan fail. Gunakan default deny dengan keutamaan deny eksplisit, atau kumpulkan peraturan ke dalam satu keputusan berserta sebab dan risiko. Percanggahan memerlukan ujian dan pintu pelepasan supaya titik masuk yang berbeza tidak mentafsirkannya secara berbeza.
Bagaimanakah anda menyokong kebenaran kecemasan tanpa memusnahkan kebolehauditan?
Modelkannya sebagai dasar sementara atau kewajipan dengan pelulus, skop, sebab, masa mula, dan tarikh luput. PEP merekodkan setiap penggunaan, tarikh luput automatik membatalkannya, dan main semula (replay) membezakan pengecualian daripada peraturan biasa. Jangan sekali-kali memintas versi dasar dengan mengedit pangkalan data secara manual.