Dalam proyek mahasiswa, fitur login sering dianggap sudah cukup untuk mengamankan aplikasi. Padahal, mengetahui identitas pengguna tidak otomatis menentukan apa yang boleh dilakukan pengguna tersebut. Aplikasi sistem informasi kampus, organisasi mahasiswa, marketplace sederhana, atau dashboard bisnis tetap membutuhkan aturan akses yang jelas agar setiap orang hanya dapat melihat dan mengubah data sesuai tanggung jawabnya.

Role-Based Access Control (RBAC) membantu menyusun aturan tersebut berdasarkan peran pengguna. Dengan pendekatan ini, pengelola aplikasi tidak perlu menetapkan izin satu per satu kepada setiap pengguna. Izin dikumpulkan ke dalam peran, lalu pengguna memperoleh izin melalui peran yang ditugaskan kepadanya. Jika dirancang dengan prinsip least privilege, RBAC untuk proyek mahasiswa dapat membuat keamanan lebih terstruktur sekaligus lebih mudah diuji dan dipelihara.

Memahami RBAC, autentikasi, dan otorisasi

RBAC adalah model pengendalian akses yang menentukan tindakan yang diizinkan berdasarkan peran pengguna terhadap sumber daya tertentu. Komponen dasarnya meliputi pengguna, peran, izin, penugasan pengguna ke peran, serta pemberian izin kepada peran.

Contohnya, peran “dosen” dapat memiliki izin untuk melihat dan memperbarui nilai pada kelas yang diampu. Peran “mahasiswa” mungkin hanya boleh melihat nilai miliknya sendiri. Sementara itu, peran “admin” dapat mengelola akun dan konfigurasi tertentu. Perbedaan ini harus diterapkan oleh sistem, bukan hanya dijelaskan dalam dokumentasi proyek.

RBAC juga perlu dibedakan dari dua istilah berikut:

• Autentikasi memverifikasi identitas, misalnya melalui proses login.
• Otorisasi menentukan tindakan dan sumber daya yang boleh digunakan setelah identitas diketahui.

Pengguna yang berhasil login belum tentu boleh menghapus data, membuka laporan internal, atau melihat informasi milik pengguna lain. Karena itu, pemeriksaan otorisasi harus dilakukan pada setiap permintaan terhadap sumber daya atau tindakan yang dilindungi.

Prinsip least privilege dalam proyek mahasiswa

Baca juga: Manajemen Log untuk Proyek Mahasiswa: Panduan Praktis

Least privilege berarti setiap pengguna atau proses hanya memperoleh hak akses minimum yang diperlukan untuk menyelesaikan tugasnya. Prinsip ini membatasi dampak ketika akun disalahgunakan, konfigurasi keliru, atau terdapat celah pada aplikasi.

Misalnya, mahasiswa yang mengirim tugas tidak membutuhkan izin untuk menghapus tugas mahasiswa lain. Operator yang memasukkan data akademik mungkin perlu membuat dan memperbarui data, tetapi tidak harus mengelola akun administrator. Demikian juga proses otomatis yang hanya membaca data tidak perlu memiliki izin untuk mengubah atau menghapusnya.

Penerapan least privilege tidak berarti semua peran harus dibuat sangat banyak. Tujuannya adalah membuat batas tanggung jawab yang masuk akal dan dapat dijelaskan. Peran yang terlalu luas berisiko menjadi “akses serba bisa”, sedangkan peran yang terlalu rinci dapat menyulitkan pengelolaan.

Langkah merancang RBAC untuk proyek mahasiswa

1. Petakan jenis pengguna

Mulailah dengan mencatat siapa saja yang berinteraksi dengan aplikasi. Dalam proyek kampus, jenis pengguna dapat mencakup admin, dosen, mahasiswa, dan operator. Pada aplikasi organisasi, perannya mungkin berupa pengurus, anggota, bendahara, dan pengunjung.

Gunakan tanggung jawab nyata sebagai dasar penentuan peran, bukan sekadar nama jabatan. Tanyakan: tugas apa yang dilakukan pengguna, data apa yang dibutuhkan, dan tindakan apa yang harus tersedia?

2. Daftar sumber daya dan operasi

Identifikasi sumber daya yang dilindungi, seperti akun pengguna, profil mahasiswa, data kelas, nilai, produk, pesanan, laporan, atau pengaturan sistem. Setelah itu, petakan operasi yang mungkin dilakukan terhadap sumber daya tersebut:

• Read: melihat atau mengambil data.
• Create: membuat data baru.
• Update: mengubah data.
• Delete: menghapus data.

Pemetaan ini membantu tim menghindari aturan yang terlalu umum, seperti “mahasiswa boleh mengakses data akademik”. Aturan tersebut perlu diperjelas: data apa yang boleh dilihat, apakah hanya miliknya sendiri, dan apakah ada tindakan lain yang diizinkan?

3. Susun matriks peran dan izin

Buat matriks yang mempertemukan peran, sumber daya, dan operasi. Contoh sederhananya:

• Admin: mengelola pengguna dan pengaturan, serta memiliki akses sesuai tanggung jawab administratif.
• Dosen: melihat dan memperbarui data akademik yang menjadi tanggung jawabnya.
• Mahasiswa: melihat profil, jadwal, atau hasil akademik miliknya sendiri, serta membuat data yang memang diperlukan oleh alur aplikasi.
• Operator: memasukkan dan memperbarui data operasional tertentu tanpa otomatis memperoleh seluruh hak admin.

Matriks tersebut harus menjelaskan batas data, bukan hanya jenis operasinya. Izin “read nilai” untuk mahasiswa berarti membaca nilai milik sendiri, sedangkan dosen dapat membaca nilai pada kelas yang menjadi tanggung jawabnya. Pembatasan berdasarkan kepemilikan atau konteks ini penting agar izin tidak meluas tanpa sengaja.

4. Terapkan deny by default

Gunakan prinsip deny by default: akses ditolak apabila tidak ada izin yang secara eksplisit diberikan. Pendekatan ini lebih aman daripada mengizinkan akses terlebih dahulu lalu mencoba menutup beberapa pengecualian.

Setiap endpoint, fungsi, atau tindakan yang dilindungi harus memiliki aturan otorisasi yang jelas. Pemeriksaan tidak boleh hanya dilakukan pada tampilan antarmuka. Tombol “hapus” yang disembunyikan dari mahasiswa tidak cukup jika permintaan penghapusan masih dapat dikirim langsung ke aplikasi.

5. Periksa otorisasi pada setiap permintaan

Setelah pengguna berhasil login, sistem tetap perlu memeriksa peran, izin, dan konteks sumber daya pada setiap permintaan. Pemeriksaan ini berlaku untuk membaca, membuat, mengubah, maupun menghapus data.

Contohnya, mahasiswa yang boleh melihat profilnya sendiri tidak boleh mengganti identitas pada permintaan yang merujuk ke profil mahasiswa lain. Dosen yang dapat memperbarui nilai juga tidak otomatis boleh mengubah nilai untuk semua kelas. Aturan otorisasi perlu memastikan objek yang diakses memang berada dalam cakupan tanggung jawab pengguna.

Risiko kesalahan otorisasi

Baca juga: Secure Coding untuk Proyek Mahasiswa: Checklist Kode Aman

Desain RBAC yang lemah dapat menimbulkan authorization bypass, yaitu akses ke fungsi atau data tanpa pemeriksaan izin yang semestinya. Risiko lain adalah horizontal privilege escalation, ketika pengguna mengakses data atau fungsi milik pengguna lain dengan tingkat peran yang sama. Contohnya, seorang mahasiswa dapat membuka data akademik mahasiswa lain.

Vertical privilege escalation terjadi ketika pengguna memperoleh hak peran yang lebih tinggi. Misalnya, mahasiswa dapat menjalankan fungsi admin atau operator. Risiko ini sering muncul karena sistem hanya memeriksa apakah pengguna sudah login, bukan memeriksa peran dan izin pada setiap tindakan.

Role hierarchy harus digunakan secara hati-hati

Pada model tertentu, RBAC dapat menggunakan hierarki peran. Peran yang lebih tinggi dapat mewarisi izin dari peran yang lebih rendah. Fitur ini dapat menyederhanakan pengelolaan, tetapi juga berisiko memperluas akses secara tidak sengaja.

Sebelum membuat hierarki, pastikan hubungan antarperan benar-benar mencerminkan tanggung jawab. Tinjau izin yang diwariskan dan pastikan peran yang lebih tinggi tidak memperoleh hak yang sebenarnya tidak diperlukan. Untuk proyek mahasiswa, hierarki sebaiknya dibuat sederhana agar mudah dipahami, diuji, dan dijelaskan saat presentasi.

Pengujian dan pemeliharaan akses

Baca juga: Validasi Input untuk Proyek Mahasiswa agar Data Aman

Pengujian RBAC harus mencakup skenario yang diizinkan dan yang ditolak. Periksa setidaknya hal-hal berikut:

• Pengguna dapat menjalankan tindakan yang memang diberikan kepada perannya.
• Pengguna ditolak ketika mencoba fungsi di luar perannya.
• Pengguna tidak dapat membaca atau mengubah data milik pengguna lain tanpa kewenangan.
• Fungsi administratif tidak dapat dijalankan oleh peran biasa.
• Akses tanpa sesi login atau tanpa izin yang sesuai ditolak.

Gunakan prinsip yang sama ketika melakukan perubahan fitur. Setiap izin baru perlu dipetakan ke peran yang tepat dan diuji kembali. OWASP ASVS dapat digunakan sebagai referensi untuk menyusun persyaratan serta pengujian kontrol keamanan aplikasi, termasuk pengendalian akses.

Hak akses juga perlu ditinjau secara berkala. Ketika tanggung jawab pengguna berubah, izin lama harus diperbarui atau dicabut. Langkah ini membantu mencegah privilege creep, yaitu kondisi ketika hak akses menjadi lebih luas daripada kebutuhan peran saat ini.

Penutup

RBAC untuk proyek mahasiswa bukan sekadar menambahkan kolom peran pada tabel pengguna. Prosesnya mencakup pemetaan pengguna, sumber daya, operasi, matriks izin, pemeriksaan pada setiap permintaan, serta pengujian akses yang berhasil dan ditolak. Dengan least privilege dan deny by default, tim dapat membangun aplikasi yang lebih terarah, lebih mudah dirawat, dan lebih siap menghadapi risiko penyalahgunaan akses.

Desain otorisasi yang baik membuat aplikasi bukan hanya berfungsi, tetapi juga membantu menjaga kepercayaan pengguna melalui akses yang terukur dan bertanggung jawab.

Baca juga: Tata Kelola Data untuk Proyek Mahasiswa: Panduan Praktis