Daftar isi
Dalam rancangan sistem informasi, kata “admin” dan “staf” sering terdengar cukup jelas—sampai muncul pertanyaan: apakah staf boleh mengubah permintaan yang sudah disetujui? Apakah kepala cabang boleh melihat data cabang lain? Jawabannya perlu disepakati sebagai aturan kerja, bukan ditebak saat layar aplikasi dibuat.
Di sini matriks hak akses berguna: satu tabel yang mempertemukan peran, jenis data, tindakan, dan batas cakupannya. Tulisan ini memperdalam satu bagian dari checklist kebutuhan sistem informasi, yaitu bagaimana mengubah daftar pengguna menjadi keputusan akses yang dapat diperiksa.
Bedakan login dari izin melakukan tindakan
Login membuktikan identitas pengguna, tetapi belum berarti ia boleh membuka semua data atau menjalankan semua fungsi. Dalam model role-based access control (RBAC), izin dikaitkan dengan peran, lalu pengguna ditempatkan pada peran yang sesuai. Definisi RBAC dari NIST menjelaskan bahwa tindakan yang diizinkan pada sumber daya diidentifikasi melalui peran, bukan semata-mata identitas setiap orang.
Nama peran sebaiknya mengikuti pekerjaan yang nyata: misalnya pembuat permintaan, penyetuju, dan peninjau laporan. Tidak semua bisnis membutuhkan ketiganya, dan satu orang dapat memiliki lebih dari satu tanggung jawab; keputusan akhirnya harus mengikuti proses yang disepakati.
Susun matriks dari satu alur kerja
Ambil satu proses contoh: permintaan pembelian internal. Daftar dulu objek yang diakses (permintaan dan laporan), tindakan (lihat, buat, ubah, setujui, ekspor), dan batasnya (milik sendiri, satu cabang, atau seluruh organisasi). Berikut contoh ilustratif, bukan aturan baku untuk setiap perusahaan:
| Peran | Permintaan pembelian | Persetujuan | Laporan |
|---|---|---|---|
| Pembuat permintaan | Buat dan lihat milik sendiri; ubah selama berstatus draf | Tidak boleh menyetujui | Tidak boleh mengekspor |
| Penyetuju cabang | Lihat permintaan pada cabangnya | Setujui atau tolak permintaan cabangnya | Lihat ringkasan cabangnya |
| Peninjau pusat | Lihat permintaan sesuai kebutuhan audit internal | Tidak boleh menyetujui | Ekspor laporan sesuai cakupan yang disetujui |
Jika batas cabang atau status draf ternyata tidak berlaku di organisasi Anda, ubahlah tabelnya. Yang penting, tulis juga izin yang tidak diberikan. Menurut panduan otorisasi OWASP, prinsip least privilege berarti pengguna diberi izin minimum untuk pekerjaannya; akses yang tidak dinyatakan sebaiknya ditolak secara default.
Jadikan matriks bahan uji, bukan sekadar dokumen
- Uji tindakan yang diizinkan: pembuat dapat mengubah permintaan draf miliknya, lalu melihat hasilnya.
- Uji tindakan yang dilarang: pembuat mencoba menyetujui permintaan sendiri; sistem harus menolak tindakan itu.
- Uji batas data: penyetuju cabang A mencoba membuka permintaan cabang B, termasuk melalui tautan langsung atau perubahan ID pada URL.
- Uji perubahan status: pembuat mencoba mengubah permintaan setelah disetujui.
- Uji ekspor: peninjau hanya mengekspor data dalam cakupan yang telah disepakati.
Menyembunyikan tombol saja bukan pengendalian akses yang memadai. OWASP menganjurkan pemeriksaan izin pada setiap permintaan terhadap objek atau fungsi yang diakses, bukan hanya pada tampilan halaman. Minta tim pengembang menjelaskan bagaimana aturan matriks diterapkan dan bagaimana kasus penolakan diuji.
Siapa yang menyetujui dan memperbarui aturan?
Tunjuk pemilik proses untuk memutuskan akses yang sah, dan catat keputusan yang masih terbuka: siapa boleh memberi peran, bagaimana karyawan pindah cabang ditangani, serta kapan hak akses ditinjau kembali. OWASP juga menyarankan peninjauan berkala agar izin tidak terus menumpuk ketika tanggung jawab pengguna berubah.
Anda tidak perlu menuntaskan seluruh organisasi dalam satu tabel sekaligus. Mulai dari proses yang paling penting, pakai contoh data rekaan untuk pengujian awal, dan bawa matriks beserta kasus uji ke diskusi dengan calon penyedia sistem. Dengan begitu, penawaran dan rancangan dapat membahas batas akses yang konkret, bukan sekadar daftar menu.
Kredit gambar: Phil Desforges — sumber gambar — Pexels License
Deskripsi gambar: Tangan peserta menulis pada kertas besar saat merencanakan pekerjaan bersama.
Relevansi: Foto stok ilustratif menunjukkan kegiatan perencanaan bersama yang sesuai dengan pemetaan peran dan izin, bukan dokumentasi matriks akses, produk, klien, atau proyek Sahabat Sistem.
