Panduan Meninjau Otorisasi Berbasis Fungsi pada API

Matriks privilege dan bukti pemanggilan yang ditolak

Daftarkan operasi berdasarkan kemampuan: menyetujui refund, menangguhkan akun, mengekspor data audit, memutar secret integrasi, impersonasi pengguna support, dan memutar ulang perintah queue. Masukkan RPC internal serta handler terjadwal karena layar admin tersembunyi bukan batas keamanan. Untuk setiap role atau credential mesin, tetapkan izin wajib, cakupan tenant, prasyarat persetujuan, dan event audit yang diharapkan.

Lakukan pemanggilan langsung memakai role lebih rendah. Sesi support yang memanggil POST /refunds/42/approve tidak boleh menghasilkan state persetujuan maupun request ke provider pembayaran. Ulangi dengan role finance yang sah tetapi melampaui batas persetujuannya, key ingestion yang meminta delete, dan pengguna yang mencoba aksi terlindungi melalui HTTP method lain. Catat keputusan kebijakan dan state target. Penolakan yang masih menulis audit dapat diterima; penolakan yang mengantrikan pekerjaan tidak dapat diterima.

Temuan BFLA ditutup dengan evaluasi izin sebelum side effect handler serta penghapusan cabang fallback “admin”. Akses darurat hanya dapat menjadi pengecualian bila ada approver bernama, durasi terbatas, scope target, dan review audit terpisah. Test regresi harus mencakup setiap verb berprivilege dan varian method; bukti rilis menyebut owner kebijakan yang menerima matriks.

Izin membutuhkan kosakata stabil. Petakan aksi route ke verb seperti refund.approve atau audit.read, bukan menyimpulkan privilege dari nama controller. Credential mesin harus mempunyai scope lebih sempit daripada administrator manusia dan perlu ditolak untuk aksi interaktif. Uji invalidasi policy cache setelah role dihapus: token lama atau worker berumur panjang tidak boleh mempertahankan fungsi setelah izin berubah. Simpan versi kebijakan bersama event audit agar insiden berikutnya dapat merekonstruksi aturan yang mengizinkan aksi.

Transisi privilege dan jalur alternatif

Uji fungsi sebagai state machine. Pemanggil yang boleh membuat request refund belum tentu boleh menyetujuinya; approver dapat memerlukan request dari orang lain dan batas nilai uang. Kirim request pada setiap transisi, termasuk pembatalan setelah persetujuan dan persetujuan berulang. Pastikan idempotency tidak mengubah percobaan pertama yang ditolak menjadi replay yang diizinkan setelah role berubah. API administratif sering memiliki serialisasi lain seperti mutation GraphQL, RPC, atau endpoint batch; izin harus bertemu pada aksi kebijakan yang sama. Audit log harus membedakan penolakan percobaan dari aksi selesai agar review tidak menganggap event sebagai keberhasilan.

Kasus approval refund

Buat draft refund, lalu uji empat pemanggil: customer, support, approver finance di bawah ambang, dan approver finance di atas ambang. Customer boleh membatalkan draft sendiri bila kebijakan mengizinkan, tetapi tidak boleh mengubah status menjadi approved. Support dapat melihat tiket sesuai scope namun tidak boleh membuat request ke provider pembayaran. Approver di bawah ambang menerima penolakan tanpa perubahan saldo; approver yang sah menghasilkan satu event audit dan satu panggilan provider. Ulangi approval melalui method yang salah, RPC internal, dan token lama setelah izin dicabut. Simpan policy version, state sebelum-sesudah, event audit, dan bukti provider agar setiap penolakan membuktikan tidak ada side effect.

Bukti pemetaan izin

Gunakan aksi policy stabil seperti refund.approve, account.suspend, dan audit.export; nama route terlalu mudah berubah atau diduplikasi. Petakan setiap titik masuk HTTP, RPC, queue, dan GraphQL ke satu aksi. Credential layanan hanya memegang aksi yang dibutuhkan integrasinya. Key yang mengirim record harus gagal saat mencoba menghapus akun, memutar secret, atau melakukan impersonasi pengguna.

Uji otorisasi cached secara sengaja. Cabut izin, catat waktu publikasi policy, lalu panggil aksi berprivilege memakai token sebelum pencabutan dan token sesudahnya. Setiap masa tenggang cache perlu maksimum terdokumentasi dan tidak boleh melampaui keputusan owner risiko. Periksa worker terjadwal karena claim dapat disimpan lebih lama daripada handler request. Bukti audit harus memisahkan percobaan ditolak dari aksi selesai. Untuk remediasi, hapus cabang administrator implisit dan evaluasi policy sebelum panggilan provider, penulisan, atau enqueue. Approval valid menyimpan target, identitas approver, limit persetujuan, dan waktu keputusan pada event audit immutable. Retest operasi privilege tetangga agar perubahan middleware bersama tidak diam-diam menciptakan bypass kedua.

Respons dan bukti yang diharapkan

Penolakan fungsi berprivilege harus memiliki respons yang sengaja dirancang. Jangan membocorkan daftar permission internal, tetapi berikan status yang konsisten untuk klien. Yang lebih penting, verifikasi bahwa tidak ada perubahan saldo, update record, pengiriman pesan, token baru, atau tugas queue. Untuk operasi yang sah, bandingkan satu request dengan satu event audit dan satu perubahan state yang diharapkan. Dua event untuk approval yang sama menunjukkan masalah idempotency atau retry.

Simpan matriks role-versus-aksi dalam repository atau artefak perubahan sehingga reviewer dapat melihat alasan suatu permission ada. Bila produk menambahkan role baru, lakukan review matriks sebelum route dibuka. Periksa juga kemampuan delegated administration: admin tenant boleh mengelola tenant sendiri, namun tidak boleh mencapai audit global atau konfigurasi platform. Uji request dengan target tenant lain, target milik sendiri, dan target yang sudah dihapus. Hasil tersebut memberi bukti bahwa scope kebijakan diterapkan bersama keputusan fungsi.

Register penutupan aksi berprivilege

Aksi policy dan principal	Owner	Bukti	Hasil yang diharapkan	Hasil teramati / status	Pengecualian	Penutupan
`refund.approve`; fixture support memanggil `POST /refunds/42/approve`	Owner policy otorisasi	Trace keputusan `BFLA-042`, policy v18; diff saldo dan panggilan provider	Tolak sebelum write atau panggilan provider	403; saldo tidak berubah; panggilan provider 0 — ditutup	Tidak ada	Kasus regresi `authz-refund-07` lulus setelah cache expiry; disetujui owner 2026-06-11