Pertanyaan dan Skenario yang Sesuai
Tim platform menginginkan aturan seperti "database tidak boleh bersifat publik," "hanya image yang bertanda tangan yang boleh dijalankan," dan "sebuah role hanya dapat membaca tenant miliknya sendiri" menjadi dapat diuji, dapat ditinjau, dan ditegakkan secara otomatis. Pewawancara meminta Anda untuk menjelaskan Policy as Code dan menarik batas antara keputusan kebijakan dan eksekusi bisnis.
Asumsikan permintaan datang dari API, CI/CD, atau perubahan infrastruktur; input kebijakan berupa JSON terstruktur; dan kebijakan memerlukan penerapan versi, rollback, serta kemampuan audit. Pertanyaan ini berfokus pada batas dan penalaran, bukan komitmen terhadap OPA, Rego, atau satu vendor tertentu.
Hal yang Dievaluasi Pewawancara
- Apakah Anda memisahkan tanggung jawab definisi kebijakan, komputasi keputusan, dan penegakan (enforcement).
- Apakah Anda mengetahui bahwa policy engine dapat mengembalikan hasil terstruktur dan bukan hanya nilai boolean.
- Apakah Anda menangani konsistensi versi kebijakan dan input, batas waktu (timeout), caching, dan default deny.
- Apakah Anda memperlakukan kode kebijakan sebagai perangkat lunak yang memerlukan peninjauan, pengujian, rilis, dan audit, bukan sebagai konfigurasi yang disalin.
Jawaban yang lemah mengatakan "gunakan OPA untuk otorisasi." Jawaban yang kuat menempatkan Policy Enforcement Point pada batas permintaan, menjaga Policy Decision Point tetap fokus pada komputasi, dan membuat setiap keputusan dapat dijelaskan, diputar ulang (replayable), serta dilacak.
Pertanyaan untuk Diklarifikasi Sebelum Menjawab
- Apakah keputusan ini untuk akses runtime atau kepatuhan sebelum deployment? Keputusan runtime menekankan latensi dan ketersediaan; pemeriksaan deployment menekankan umpan balik dan pemblokiran.
- Siapa yang menyediakan identitas, tenant, label resource, dan status lingkungan, serta apakah kolom-kolom tersebut dapat dipercaya? Input yang hilang tidak boleh secara diam-diam menjadi allow.
- Saat terjadi kegagalan, apakah sistem harus default deny, turun (degrade) ke allow, atau meminta persetujuan manusia? Jawabannya bergantung pada dampak tindakan dan target ketersediaan.
- Bisakah publikasi kebijakan bersifat independen dari rilis aplikasi? Rilis independen memerlukan pengikatan versi, pemeriksaan kompatibilitas, dan rollback yang cepat.
- Apa yang harus dimuat dalam catatan audit? Jika input mencakup data pribadi atau rahasia, log memerlukan redaksi sebelum disimpan atau diunggah.
Kerangka Jawaban 30 Detik
"Policy as Code menempatkan aturan yang dapat dieksekusi ke dalam kontrol versi, peninjauan, dan pengujian. Permintaan mencapai PEP, yang mengumpulkan dan menormalisasi subjek, tindakan, resource, dan konteks, lalu memanggil PDP dengan input yang dinormalisasi dan versi kebijakan. PDP mengembalikan keputusan terstruktur seperti allow, deny, alasan, dan kewajiban (obligations); PEP yang sebenarnya memblokir atau melanjutkan tindakan tersebut. Saya akan menggunakan default deny, caching yang dibatasi dan diberi versi, serta log keputusan yang diredaksi. Sebelum rilis, saya akan menjalankan pemeriksaan replay dan canary, serta membuat pengecualian darurat terikat waktu, disetujui, dan dapat diaudit."
Jawaban Mendalam Langkah demi Langkah
1. Tentukan objek dan batasan kebijakan
Terjemahkan aturan bahasa alami ke dalam subjek, tindakan, resource, kondisi, dan hasil. "Layanan tidak boleh mengekspos port publik yang tidak terenkripsi" dapat berarti: subjeknya adalah pipeline deployment, tindakannya adalah membuat layanan, resource-nya adalah konfigurasi layanan, kondisinya adalah atribut port dan jaringan, dan hasilnya adalah deny dengan pesan remediasi.
PDP membaca input yang dinormalisasi dan kebijakan lalu mengembalikan allow, deny, warn, atau data terstruktur yang lebih kaya. PEP berada di API, admission controller, tugas CI, atau batas panggilan layanan dan mengubah hasil menjadi blokir, lanjutkan, 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 memisahkan pengambilan keputusan dari penegakan, dan panduan AWS menjelaskan PDP dengan PEP pada API. Batasan tersebut memungkinkan satu rangkaian aturan melayani beberapa titik masuk tanpa menganggap bahwa policy engine melakukan transaksi bisnis.
2. Normalisasi input dan tangani kolom yang hilang
Format mentah berbeda-beda menurut titik masuk: CI dapat menyediakan rencana YAML, API berupa permintaan HTTP, dan panggilan layanan berupa objek. PEP atau lapisan otorisasi harus mengubahnya menjadi bentuk internal yang stabil dan melampirkan metadata sumber, stempel waktu, serta versi data.
Jika tenant, pemilik, atau status lingkungan hilang, default deny lebih aman daripada menebak-nebak. Kebijakan harus membedakan deny eksplisit dari "tidak dapat memutuskan", yang memungkinkan PEP meminta persetujuan atau mencoba lagi; nilai yang tidak terdefinisi tidak boleh diperlakukan 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. Perlakukan kebijakan sebagai perangkat lunak yang dapat diuji
File kebijakan harus berada di Git dan lolos pemeriksaan sintaksis, pengujian unit, kasus-kasus adversarial, serta peninjauan kode. Pengujian harus mencakup jalur allow dan jalur tenant tetangga, kolom yang hilang, identitas kedaluwarsa, aturan yang bertentangan, serta jalur default.
package invoices
default allow := false
allow if {
input.action == "read"
input.subject.tenant == input.resource.tenant
"reader" in input.subject.roles
}Kunci versi kebijakan dan snapshot data dalam pengujian. Jika aturan bergantung pada direktori langsung atau panggilan jaringan, tentukan batas timeout dan keusangan (staleness) sebelum memutuskan apakah caching lokal dapat diterima.
4. Rancang publikasi, caching, dan rollback
Rilis kebijakan memerlukan versi, pemeriksaan kompatibilitas, dan rollback seperti rilis layanan. PDP dapat berjalan sebagai sidecar lokal, library, atau layanan terpusat: eksekusi lokal mengurangi latensi jaringan, sementara sentralisasi menyederhanakan pengelolaan. Pilihan bergantung pada kecepatan pembaruan, radius dampak kegagalan, dan persyaratan konsistensi.
Cache hanya keputusan dengan masa pakai eksplisit, yang mengikat subjek, resource, versi kebijakan, dan versi data otorisasi. Pencabutan izin, migrasi tenant, dan tindakan berisiko tinggi tidak boleh menggunakan cache jangka panjang yang tidak dapat dibatalkan dengan cepat. Saat PDP mengalami timeout, PEP memilih deny, persetujuan, atau jalur terbatas yang telah disetujui sebelumnya sesuai dengan risiko tindakan.
5. Catat keputusan yang dapat dijelaskan dan diredaksi
Setiap keputusan memerlukan setidaknya versi kebijakan, ringkasan input, hasil, alasan, ID keputusan, dan identitas PEP untuk pemutaran ulang insiden. Input dapat berisi nama pengguna, token, atau rahasia, sehingga lapisan pencatatan log harus menghapus atau menyamarkan kolom sensitif sebelum diunggah atau disimpan.
Sebuah status allow juga dapat membawa kewajiban (obligations), seperti menulis peristiwa audit, membatasi kolom, atau memerlukan konfirmasi bertahap. PDP mengembalikan kewajiban tersebut; PEP mengeksekusinya dan melakukan deny atau eskalasi jika tidak dapat melakukannya.
Contoh Jawaban Berkualitas Tinggi
Saya akan mendefinisikan Policy as Code sebagai pengekspresian batasan keamanan, kepatuhan, dan operasional sebagai aturan yang berversi, dapat diuji, dan dapat dibaca mesin. Permintaan mencapai PEP, yang mengautentikasi subjek dan menormalisasi subjek, tindakan, resource, serta konteks sebelum mengirimkannya dengan versi kebijakan ke PDP. PDP menghitung keputusan dan mengembalikan allow, deny, alasan, kewajiban, dan ID keputusan. PEP, bukan PDP, yang memblokir permintaan, melanjutkan tindakan bisnis, atau memulai persetujuan manusia.
Saya akan membuat versi untuk data kebijakan dan input, meninjau kebijakan di Git, dan mengujinya dengan snapshot yang dapat diputar ulang. Perilaku runtime secara default adalah deny, dan cache diikat ke versi kebijakan serta data otorisasi; pencabutan akan membatalkan keputusan berisiko tinggi dengan cepat. Pemadaman PDP tidak boleh secara otomatis menjadi allow, jadi saya akan memilih mode kegagalan berdasarkan risiko tindakan. Terakhir, saya akan menulis log keputusan yang diredaksi untuk audit dan rollback. Aturan yang sama kemudian dapat melayani titik masuk API, CI, dan infrastruktur sementara setiap titik masuk tetap memegang tanggung jawab penegakan.
Kesalahan Umum
- Kesalahan → Membiarkan PDP memperbarui database atau men-deploy infrastruktur → Mengapa gagal → Keputusan dan efek samping menjadi tidak terpisahkan serta sulit untuk dicoba ulang atau diaudit → Solusi → Kembalikan keputusan dan kewajiban dari PDP; biarkan PEP atau layanan bisnis yang menjalankan efeknya.
- Kesalahan → Default ke allow saat PDP mengalami timeout → Mengapa gagal → Gangguan jaringan menjadi celah untuk melewati izin (permission bypass) → Solusi → Pilih deny, persetujuan, atau jalur singkat yang telah disetujui sebelumnya berdasarkan risiko tindakan.
- Kesalahan → Hanya mencatat log allow atau deny → Mengapa gagal → Tidak ada yang dapat menjelaskan aturan dan input mana yang menghasilkan keputusan tersebut → Solusi → Catat versi kebijakan, alasan, ID keputusan, dan ringkasan input yang telah diredaksi.
- Kesalahan → Memperlakukan cache kebijakan sebagai kebenaran permanen → Mengapa gagal → Pencabutan izin dan perubahan tenant tidak dapat segera berlaku → Solusi → Ikat versi dan masa kedaluwarsa, serta batalkan validitasnya pada peristiwa penting.
Pertanyaan Lanjutan dan Tanggapan
Jika PDP terpusat tidak tersedia, apakah setiap pembacaan harus gagal?
Klasifikasikan tindakannya terlebih dahulu. Perubahan izin, transfer, dan pembacaan lintas tenant harus default deny; pembacaan berisiko rendah dapat menggunakan keputusan lokal berumur pendek yang terikat versi, dengan penggunaan cache yang dicatat dan diaudit setelah pemulihan. Ketersediaan bukanlah alasan universal untuk mengizinkan (allow).
Bagaimana jika kebijakan dan direktori identitas diperbarui pada saat yang sama?
Sertakan versi data identitas dan kebijakan dalam keputusan, dan minta PEP memeriksa versi atau lease sebelum penegakan. Peristiwa pencabutan membatalkan cache; jika versi tidak dapat dikonfirmasi, lakukan deny atau evaluasi ulang. Uji pembaruan serentak dan pesan yang tertunda agar keputusan lama tidak dapat ditulis kembali.
Jika satu aturan mengizinkan (allow) dan aturan lain menolak (deny), mana yang menang?
Tentukan prioritas secara eksplisit; jangan pernah bergantung pada urutan file. Gunakan default deny dengan prioritas deny eksplisit, atau gabungkan aturan ke dalam keputusan dengan alasan dan risiko. Konflik memerlukan pengujian dan gerbang rilis sehingga titik masuk yang berbeda tidak dapat menafsirkannya secara berbeda.
Bagaimana Anda mendukung izin darurat tanpa merusak kemampuan audit?
Modelkan hal tersebut sebagai kebijakan sementara atau kewajiban dengan pemberi persetujuan, cakupan, alasan, waktu mulai, dan kedaluwarsa. PEP mencatat setiap penggunaan, kedaluwarsa otomatis akan mencabutnya, dan pemutaran ulang (replay) membedakan pengecualian dari aturan normal. Jangan pernah melewati versi kebijakan dengan mengedit database secara manual.