Cara mengatur permission per menu: panduan praktis kontrol akses berlapis

Saat Rektor memutuskan untuk upgrade kontrol akses, pertanyaan teknis biasanya datang. Bagaimana cara merancang permission structure yang tidak membingungkan? Berapa banyak layer akses yang seharusnya ada? Bagaimana memastikan setiap role punya akses yang tepat tanpa overthinking?

Ini bukan teori abstrak. Ini tentang implementasi konkret.

Sistem akademik yang baik dirancang dengan permission berjenjang. Layer pertama adalah akses ke menu. Layer kedua adalah akses ke action (read, write, delete). Layer ketiga adalah akses ke data spesifik berdasarkan entitas organisasi. Mari kita bongkar masing-masing.

LAYER PERTAMA: MENU-LEVEL PERMISSION

Menu adalah pintu masuk. Jika staff registrasi tidak seharusnya pernah melihat modul finansial, mereka tidak boleh punya akses ke menu keuangan sama sekali. Tidak ada hidden buttons. Tidak ada “klik di sini untuk unlock.” Menu tidak akan pernah muncul di interface mereka.

Cara kerja: setiap role diberi permission untuk akses menu-menu tertentu. Dosen bisa akses menu Akademik (silabus, nilai, absensi), menu Komunikasi (forum, pengumuman), dan menu Profil. Dosen tidak bisa akses menu Registrasi, menu Keuangan, atau menu Sistem Keamanan.

Admin IT punya akses lebih luas, tapi juga berlapis. Admin IT bisa lihat menu Manajemen Pengguna dan Manajemen Sistem. Tetapi Admin IT tidak seharusnya punya akses menu Keuangan kampus, karena itu domain finance team. Setiap divisi punya tanggung jawab yang jelas.

Mengapa ini penting? Karena human error adalah risiko terbesar. Jika menu keuangan tersembunyi dari dosen, dosen tidak akan tersesat mengedit transaksi kampus karena penasaran atau oleh kekeliruan.

LAYER KEDUA: ACTION-LEVEL PERMISSION

Menus tidak cukup. Dalam menu yang sama, pengguna berbeda bisa punya akses berbeda.

Ambil contoh menu “Data Mahasiswa.” Registrar membuka menu ini untuk read data mahasiswa, tapi hanya untuk create atau edit data biodata (nama, alamat, tangal lahir). Registrar tidak boleh edit data akademik seperti nilai atau transkrip. Finance officer punya akses menu Data Mahasiswa, tapi hanya untuk read informasi pembayaran. Finance tidak boleh edit data akademik atau biodata.

Setiap action didefinisikan:
– Read (buka file, lihat laporan, lihat dashboard)
– Create (buat record baru, seperti input nilai semester)
– Update (ubah data existing)
– Delete (hapus record)
– Export (download data ke file)
– Approve (validasi atau sign-off data tertentu)

Dalam sistem permission terpadu, setiap role diassign action spesifik per menu. Registrar = Read + Create + Update di menu “Data Mahasiswa”. Finance Officer = Read di menu “Data Mahasiswa”, tapi Read + Update di menu “Transaksi Keuangan”.

Hal ini meminimalkan akses berlebih. Seorang staff tidak akan punya delete permission untuk data yang seharusnya permanen. Staff junior tidak akan punya approve permission untuk transaksi besar.

LAYER KETIGA: DATA-LEVEL (ENTITY) PERMISSION

Inilah yang membedakan sistem permission biasa dari sistem permission yang sophisticated.

Biarkan saya memberi konteks: ada 8 fakultas di universitas Anda. Dekan Fakultas Teknik, tentunya, hanya boleh lihat data akademik untuk mahasiswa Fakultas Teknik. Tapi dalam sistem yang kurang matang, pemberian akses jadi simple: “Dekan Teknik = akses menu Data Mahasiswa.” Tanpa filter. Dekan bisa lihat data Fakultas Hukum, Fakultas Ekonomi, semuanya.

Sistem permission berlapis menambahkan filter organisasi. Dekan Teknik diberi akses ke menu Data Mahasiswa ONLY untuk mahasiswa yang registered di Fakultas Teknik. Di backend, sistem automatically filter data berdasarkan parent entity dekan (faklutas). Jika Dekan Teknik membuka laporan mahasiswa, mereka hanya akan lihat mahasiswa Teknik. Tidak ada opsi dropdown untuk “tampilkan semua fakultas.”

Contoh lain: dosen punya akses edit nilai HANYA untuk kelas yang mereka ajar. Dosen Matematika tidak bisa edit nilai kelas Kimia. Sistem automatically filter berdasarkan teaching assignment. Dosen Matematika buka menu Nilai, sistem tunjukkan HANYA kelas Matematika yang mereka ampu, dengan nama-nama mahasiswa di kelas tersebut. Data kelas lain tidak tersedia, hidden di backend.

Ini disebut Attribute-Based Access Control (ABAC) atau context-aware permission. Permission tidak statis; permission terikat pada atribut pengguna (fakultas, divisi, subject taught, role title). Sistem secara dinamis evaluate apakah user X punya akses ke data Y berdasarkan kombinasi role + atribut pengguna.

KOMBINASI KETIGA LAYER

Here’s how it works together:

1. Dosen Bahasa Inggris login ke sistem.
2. Sistem automatically load menu berdasarkan role: Academic Menu muncul, Finance Menu tidak muncul.
3. Dosen buka Academic Menu.
4. Dosen klik “Nilai.”
5. Sistem check: Dosen ini punya action permission “Edit” di menu “Nilai.” Yes, allowed. Tapi juga check: Dosen ini mengajar kelas apa? Kelas B101, B102, B103.
6. Sistem filter: tampilkan HANYA nilai B101, B102, B103. Nilai kelas lain dari dosen lain tidak tampil.
7. Dosen buka kelas B101, edit nilai mahasiswa, tekan Save.
8. Sistem check lagi: dosen ini punya delete permission? No. Jadi tombol Delete tidak muncul. Dosen hanya bisa baca, create, atau update.

Terlihat sederhana dari user-side. Behind the scenes, sistem execute puluhan permission checks.

MENGAPAKAH PERMISSION BERLAPIS WAJIB?

Dari pengalaman SEVIMA mendampingi 1.200+ perguruan tinggi, kampus yang mengimplementasikan permission structure tiga-layer mengalami:

Penurunan akses-related security incident sebesar 70%. Kebocoran data dalam banyak kasus terjadi karena orang punya akses ke data yang semestinya tidak boleh mereka lihat. Dengan permission tiga-layer, “akses kebetulan” diminimalkan.

Penurunan administrative overhead sebesar 50%. Dibanding sistem permission manual (misal: list per user berapa data yang boleh diakses), sistem permission berbasis role dan attribute adalah scalable. Saat ada staff baru, admin cukup assign role dan atribut. Sistem automatically apply seluruh permission rules. Tidak perlu manual config per staff.

Compliance yang lebih mudah. Audit internal atau eksternal bisa bertanya: “Dosen Ekonomi apa saja yang punya akses ke modul Akademik?” Sistem bisa generate laporan dalam hitungan detik, berdasarkan role + attribute. Tidak perlu manual dig through spreadsheet.

PERKARA PRAKTIS: ROW-LEVEL SECURITY

Ada satu aspek teknis yang sering terlewat: row-level security (RLS).

Bayangkan: Admin keuangan membuka laporan “Pembayaran Mahasiswa.” Laporan ini adalah tabel dengan ribuan baris (setiap baris adalah satu transaksi pembayaran). Admin keuangan punya read permission ke laporan ini. Tapi apakah Admin keuangan boleh lihat SEMUA pembayaran semua mahasiswa?

Jawaban: tergantung struktur organisasi. Jika kampus punya beberapa unit keuangan (satu per kampus/cabang), maka Admin Keuangan di Kampus A hanya boleh lihat pembayaran mahasiswa Kampus A, bukan Kampus B.

RLS mengimplementasikan ini. Sistem tidak hanya memberi akses ke tabel “Pembayaran Mahasiswa,” tapi juga set rule: “Filter data untuk rows di mana kampus = kampus yang di-assign ke user ini.” Ketika Admin Keuangan Kampus A buka laporan, mereka lihat 100% tabel Pembayaran, tapi dengan automatic filter kampus = Kampus A. Rows untuk Kampus B tidak visible.

Ini juga scalable. Jika ada transaksi baru untuk Kampus A, automatic masuk ke result set Admin Keuangan. Tidak perlu manual update permission.

START SIMPLE, SCALE GRADUALLY

Implementasi permission tiga-layer tidak perlu done all at once.

Minggu 1-2: Definisikan role. Apa saja role di universitas Anda? Rektor, Dekan, Kaprodi, Dosen, Admin Akademik, Admin Keuangan, Registrar, Student. Untuk setiap role, dokumentasikan: apa job function mereka? Data apa yang mereka butuh untuk job function itu?

Minggu 3-4: Tentukan menu. Dari data yang mereka butuh, apa menu yang mereka akses? Dosen butuh akses Nilai dan Silabus. Registrar butuh akses Data Mahasiswa dan Jadwal. Finance butuh akses Keuangan dan Laporan.

Minggu 5-6: Tentukan action. Untuk setiap role-menu combination, tentukan action apa yang dibutuhkan. Dosen akses menu Nilai dengan action Read + Update (untuk input nilai). Registrar akses menu Data Mahasiswa dengan action Read + Create + Update (tapi tidak Delete).

Minggu 7-8: Tentukan data filter. Untuk setiap role-menu-action combination, tentukan filter apa yang apply. Dosen hanya lihat nilai untuk kelas mereka. Dekan hanya lihat data untuk fakultas mereka.

Dokumentasikan setiap keputusan dalam permission matrix. Jangan keep di kepala. Excel sheet atau Google Sheet adalah fine untuk start.

After dokumentasi selesai, barulah implementasi di sistem. Sistem yang well-designed (seperti SIAKAD atau platform akademik enterprise) bisa implement permission rules ini dalam beberapa jam tanpa coding custom.

PENCEGAHAN PERMISSION DRIFT

Hal lain yang penting: permission bisa “drift.” Seseorang pindah departemen, role mereka di sistem lama tidak di-update. Atau permission granted untuk “temporary project” dan kemudian lupa di-revoke. Lambat laun, akses menjadi kacau.

Pencegahan:

1. Periodic Review. Quarterly, audit role assignment. Apakah masih valid? Ada staff yang punya role lama yang sudah tidak relevan?
2. Off-boarding Checklist. Saat staff resign, ada formal checklist untuk revoke semua akses.
3. Manager Sign-off. Role assignment atau permission change wajib di-sign-off oleh direct manager. Ini create accountability.
4. Automated Workflow. Sistem ideal punya automated workflow: saat staff registered di HR system, system automatically create akun akademik dengan role dan permission default. Saat staff resign, system automatically revoke akses 5 hari sebelum exit date.

INVESTASI KECIL, RETURN BESAR

Setup permission tiga-layer tidak memerlukan teknologi mahal. Anda perlu:

1. Permission matrix dokumentation (spreadsheet, gratis)
2. Platform akademik yang support granular permission (SiAkadCloud, SIAKAD Enterprise, atau platform sejenis)
3. Beberapa jam dari IT team untuk configure rules di sistem

Total investment: maybe 2-3 hari kerja IT + 1-2 hari consulting dari vendor platform. Biaya: jauh lebih murah daripada audit remediation jika terjadi kebocoran data.

ROI: Investasi ini bisa hemat kampus dari kerugian finansial, reputasi, dan legal risk yang jauh lebih besar.

Permission structure yang baik adalah fondasi untuk compliance, security, dan operational efficiency. Tidak glamorous, tapi absolutely essential.

Diposting Oleh:

ilhamfe45465277