Dua Himpunan: Yang Boleh Dibaca, Yang Boleh Dikelola

Memisahkan Hak Akses Baca dan Tulis pada Sistem Konten

Seorang staf bidang pariwisata di KotaPortal membuka panel admin dan tidak menemukan daftar konten ekonomi kreatif sama sekali. Antarmuka hanya menampilkan daftar kosong. Persyaratan dalam dokumen kebutuhan sebenarnya menyatakan hal yang berlawanan. Setiap bidang harus dapat membaca seluruh konten, sambil tetap hanya dapat menulis di dalam lingkup departemen mereka sendiri. Asumsi keliru yang harus dihapus adalah penyamaan read scope dengan write scope. Selama berbulan-bulan, API memperlakukan parameter kueri `?module=` sebagai gate. Jika modul yang diminta berada di luar bidang pengguna, responsnya adalah daftar kosong secara fail-closed.

Dua Himpunan Baca Tulis dalam Arsitektur Akses

Solusi yang diterapkan memisahkan kedua hak akses tersebut menjadi entitas yang berbeda. Satu bidang kini membawa dua set modul yang memiliki tujuan berbeda. Set pertama adalah modul yang dapat dikelola, atau `ModulesFor`. Set ini bersifat per-department dan tetap tidak berubah dari implementasi sebelumnya. Set kedua adalah modul yang dapat dibaca, atau `ReadableModules`, yang mencakup semua modul untuk setiap bidang yang valid.

Pemisahan ini memastikan bahwa nama fungsi secara eksplisit membawa perbedaan logika. Penerapan dua himpunan baca tulis ini mengubah cara sistem memvalidasi permintaan masuk. Parameter `?module=` tidak lagi bertindak sebagai penghalang utama yang menolak koneksi. Sebaliknya, ia berfungsi sebagai filter untuk menyaring data yang akan ditampilkan kepada pengguna, bukan sebagai gate yang menolak akses secara total sejak awal.

Perpindahan Logika Fail-Closed

Prinsip fail-closed tidak menghilang dari sistem keamanan. Logika ini hanya berpindah ke tempat yang seharusnya agar tidak mengganggu alur kerja yang sah. Sebuah bidang yang tidak dikenal atau tidak terdaftar dalam sistem tetap mendapatkan nilai nil. Handler kemudian menjawab dengan daftar kosong sebelum basis data disentuh sama sekali, menghemat sumber daya server dan mencegah kebocoran informasi melalui pesan error yang terlalu detail.

Pendekatan ini menerapkan prinsip deny-by-default secara ketat. Ketika tidak ada aturan akses yang cocok, aplikasi tetap harus membuat keputusan eksplisit untuk menolak atau mengizinkan [4]. Kombinasi bidang yang valid dengan nilai `?module=` apa pun berarti pembacaan diizinkan, karena parameter tersebut kini hanya berperan sebagai penyaring hasil.

Perubahan struktural yang penting terletak pada pengangkatan pemeriksaan nil. Pemeriksaan nil kini berada sebelum cabang evaluasi `?module=`. Dengan urutan eksekusi seperti ini, permintaan dari bidang yang tidak dikenal tidak dapat menyelundupkan nilai modul melewatinya untuk mendapatkan akses tidak sah ke data sensitif.

Konsekuensi pada Antarmuka Pengguna

Pemisahan logika di backend menghasilkan konsekuensi yang elegan dan terukur pada frontend. Sistem mempertahankan satu sumber kebenaran, yaitu pemetaan bidang ke slug modul ditambah satu fungsi `canManageModule` yang terpusat.

Navigasi utama menampilkan setiap menu konten secara utuh kepada semua pengguna yang terautentikasi. Kemampuan menulis kemudian disembunyikan atau dinonaktifkan per modul sesuai dengan hak akses spesifik pengguna tersebut. Sebuah banner read-only menandai tampilan di luar departemen penulis, memberikan konteks yang jelas mengapa tombol penyuntingan tidak tersedia. Pendekatan ini membuka jalur pembacaan secara luas tanpa perlu membagi antarmuka navigasi menjadi dua bagian terpisah yang berpotensi membingungkan pengguna atau menambah beban pemeliharaan kode.

Kontrol akses yang hanya mengenal satu kata untuk "diizinkan" pada akhirnya akan membutakan pengguna atau mengekspos data secara berlebihan. Memisahkan yang dapat dibaca dari yang dapat dikelola memungkinkan kedua jawaban menjadi presisi, aman, dan sesuai dengan kebutuhan operasional organisasi.

Sumber

• [4] OWASP Authorization Cheat Sheet