Nama peran tidak menentukan izin sampai izin tersebut diterjemahkan ke dalam tindakan pada sumber daya. Dalam layanan autentikasi, membaca laporan, mengekspornya, menyetujui perubahan, dan melaksanakan perubahan tersebut memiliki konsekuensi berbeda. Bangun matriks akses eksplisit kecil sebelum menugaskan orang ke peran.
Mulailah dengan tugas dan sumber daya
Untuk setiap penyewa, daftarkan inventaris domain, laporan agregat, proposal, eksekusi DNS dan administrasi pengguna. Putuskan siapa yang boleh membaca, mengekspor, mengusulkan, menyetujui, melaksanakan dan mengelola keanggotaan. Staf pelanggan mungkin membaca laporan mereka sendiri; analis mungkin menyelidiki dan mengusulkan; pemberi persetujuan yang ditunjuk mengotorisasi dampak bisnis; operator melaksanakan perubahan yang disetujui. Ini adalah batasan peran yang diusulkan, bukan klaim tentang produk tertentu.
OWASP merekomendasikan hak istimewa paling rendah, penolakan default, dan pemeriksaan izin pada setiap permintaan. Oleh karena itu, suatu peran harus dievaluasi dengan cakupan penyewa dan identitas sumber daya, bukan sebagai tanda Boolean global. Otentikasi menetapkan prinsipal; otorisasi memutuskan apakah entitas utama tersebut dapat melakukan tindakan ini sekarang.
Pisahkan persetujuan dari kemampuan
Akses teknis operator tidak secara otomatis mengotorisasi setiap perubahan bisnis. Ikat pelaksanaan dengan proposal yang disetujui dan terapkan persyaratan pemisahan tugas apa pun yang diadopsi oleh pelanggan. Jika satu orang memegang beberapa peran, catatlah peran yang tumpang tindih dan tinjauan kompensasinya alih-alih berpura-pura bahwa dua nama peran mewakili dua orang yang independen.
Pisahkan administrasi izin dari analisis rutin jika memungkinkan. Seseorang yang dapat memberikan hak eksekusi kepada dirinya sendiri dapat mengalahkan batas persetujuan nominal. Tentukan siapa yang dapat menetapkan peran penting, bagaimana penugasan tersebut ditinjau, dan akses darurat apa yang masa berlakunya berakhir secara otomatis. Hindari akun administrator bersama ketika akuntabilitas individu diperlukan.
Latihan matriks akses
Misalkan pembaca dapat melihat laporan di penyewa A tetapi mencoba melakukan ekspor yang memerlukan izin yang diberikan secara terpisah. Login dan pembacaan yang berhasil tidak menetapkan otoritas ekspor. Secara terpisah, seorang analis yang keluar dari akunnya mungkin masih memiliki sesi lama; keanggotaan saat ini dan cakupan sumber daya harus diperiksa sebelum sesi tersebut mengambil laporan lain. Ini adalah kasus izin hipotetis, bukan kebijakan aplikasi yang diuji.
Evaluasi operasi yang diizinkan dan ditolak melalui API aktual, sesi, tugas terjadwal, dan ekspor menggunakan identitas pengujian resmi. Sertakan pembacaan cakupan yang valid sehingga penolakan global tidak disalahartikan sebagai kontrol akses yang benar. Pertahankan izin yang efektif, uji konteks dan hasil yang diamati; matriks yang rapi saja tidak menunjukkan penegakan hukum.
Jaga agar siklus hidup tetap terlihat
Catat alasan, cakupan penyewa, pemberi persetujuan, dan tanggal peninjauan untuk penetapan peran. Saat berganti pekerjaan, hapus izin lama, bukan hanya menambahkan izin baru. Offboarding harus mencabut keanggotaan dan jalur akses terkait, lalu mengonfirmasi bahwa entitas utama tidak dapat lagi mengambil artefak atau memulai pekerjaan. Identitas layanan memerlukan nama pemilik dan tinjauan siklus hidup terpisah.
Tinjau penyimpangan izin ketika pelanggan, penetapan domain, atau kemampuan otomatisasi berubah. Bandingkan izin efektif, termasuk grup yang diwariskan, dengan matriks yang disetujui. Jika pelanggan memerlukan pengecualian sementara, tentukan catatan pengoperasian, masa berlaku, dan tinjauan yang tepat. Tutup pengecualian ketika kebutuhannya berakhir. Peran adalah mekanisme pemeliharaan, bukan bukti satu kali bahwa akses tetap aman.