Tentukan hasil terlebih dahulu
Kontrol akses dimulai dari pertanyaan bisnis: siapa boleh melakukan apa terhadap catatan mana dalam keadaan apa? Daftar nama peran tidak cukup. Tentukan tindakan, batas kepemilikan, dan kewenangan pengecualian. Membaca, mengedit, mengekspor, serta memberi akses adalah kekuatan berbeda.
Pilih pendekatan yang tepat
Peran sederhana bisa sesuai untuk aplikasi internal kecil. Pemilik catatan, keanggotaan organisasi, atau status alur mungkin perlu pemeriksaan tambahan. Jangan buat peran tiap kombinasi jika sedikit atribut menjelaskan aturan lebih jelas. OWASP menyarankan penolakan bawaan dan pemeriksaan tiap permintaan; tombol tersembunyi bukan batas penegakan.
Cocokkan kasus konkret
Dalam portal contoh, pengelola membaca pesanan perusahaannya dan keuangan mengunduh tagihan. Uji setiap tindakan memakai pengenal perusahaan lain, termasuk tautan langsung dan pencarian. Lalu cabut keanggotaan pengguna saat browser terbuka. Permintaan terlindungi berikutnya harus mengikuti keputusan baru, bukan tampilan lama.
Simpan bukti yang berguna
Jangan berikan akses bebas permanen kepada dukungan karena lebih mudah. Jika pengecualian perlu, tetapkan alasan, durasi, dan catatan. Periksa ekspor massal, pekerjaan latar, serta kredensial integrasi sebaik layar. Matriks izin baru berguna jika menjadi pemeriksaan nyata dan tes penolakan.
Bangun matriks dari tindakan dan batas
Buat baris tindakan dan kolom peran, lalu tambahkan batas catatan. Membaca hanya pesanan organisasi sendiri adalah bagian izin, bukan catatan tambahan. Masukkan pencarian, unduhan, ekspor, latar belakang, serta pemberian akses. Melindungi edit sambil melupakan ekspor masih dapat membuka catatan sama.
Telusuri undangan, verifikasi organisasi, perubahan peran, dan pencabutan. Tentukan perubahan yang perlu orang kedua dan akhir akses darurat. Pisahkan menjalankan bisnis dari administrasi aplikasi. Penyetuju pembelian tidak otomatis perlu mengubah autentikasi atau membaca organisasi lain. Identitas integrasi harus terbatas pada tugas dengan pemilik dan cara dicabut.
Ubah matriks menjadi kasus lolos serta ditolak: catatan sah, organisasi lain dengan peran sama, keanggotaan dicabut, dan permintaan langsung. Ulangi pada pekerjaan massal serta antrean karena izin dapat berubah. Simpan bukti pemberi otorisasi tanpa seluruh data pribadi. Minta operator menyelidiki penolakan dengannya. Batas tetap terlindungi dan pengguna sah mendapat jalan perbaikan tanpa melihat milik orang lain.
Kasus penerimaan izin
| Kasus | Batas yang diharapkan |
|---|---|
| Peran sama, organisasi lain | Kesamaan peran tidak memberi akses silang ke catatan, pencarian, atau lampiran. |
| Keanggotaan dicabut saat sesi terbuka | Tindakan berikut memakai wewenang sekarang, bukan kontrol yang sudah dirender. |
| Menaikkan wewenang sendiri | Aturan persetujuan dipaksakan dan percobaan terlacak tanpa pemberian diam-diam. |
| Ekspor antrean setelah perubahan | Eksekusi mengikuti aturan yang disepakati, bukan pilihan lama saja sebagai alasan distribusi. |
Pertanyaan untuk pemilik
Siapa memberikan dan mencabut akses? Bisakah seseorang menyetujui peningkatan sendiri? Catatan mana harus terpisah meski perannya sama? Bawa matriks peran-tindakan-catatan dan contoh larangan. Yang ditolak sama pentingnya dengan yang diizinkan.