Mengidentifikasi Masalah Access Control
Sindrom "Not Invented Here" umum menjangkiti para insinyur perangkat lunak. Bahasa kerennya, "Bukan Bikinan Saya". Kalau disingkat jadi BBS. Tapi, saya lebih suka menyingkatnya dengan "Kan Bisa?". Apalagi kalau itu diucapkan oleh insinyur yang terlalu terlalu tinggi menilai kemampuannya. Kalau sampai sekelompok orang melakukannya ramai-ramai maka disebutnya "Kan Buta?", singkatan dari "Bukan Buatan Kita". Iya, karena mereka mainnya kurang jauh dan mikirnya kurang dalem. Begitu juga dengan keseluruhan "Project Asas" ini dan soal access control yang sudah lama diulik oleh para ahlinya.
Kalau mau jujur, solusi atas permasalahan access control ini sudah tersedia sangat banyak. Bahkan, kalau mau merancang dari awal, ada casbin atau oso yang sudah menyediakan lengkap segala ubarampe buat bermain-main access control. Akan tetapi, bagi saya membuat sendiri dan mengejawantahkan konsep yang saya fahami ke dalam dunia nyata adalah salah satu cara untuk menghayati problem domain. Menghayati problem domain adalah langkah awal untuk merancang solusi yang tepat untuk menyelesaikan permasalahan pengguna. Saya percaya, perusahaan bermesinkan software engineering yang bakalan lestari adalah perusahaan yang mengerti benar kebutuhan penggunanya.
Bentuk-bentuk aplikasi yang harus dilindungi access control
Setelah membahas soal ACL, RBAC, dan ABAC, kali ini saatnya untuk merancang access control. Untuk bisa merancang dengan baik, saya harus faham bentuk-bentuk aplikasi yang akan dilindungi dengan access control. Bentuk-bentuk aplikasi tersebut adalah:
-
REST API
Baik itu REST API yang sudah HATEOAS ataupun yang belum, cara perlindungannya sama. REST API memiliki HTTP method sebagai predikatnya, sedangkan resource berlaku sebagai objek.
-
RPC (Remote Procedure Call)
RPC secara konsep hanya memiliki predikat saja, yaitu si procedure itu sendiri. Predikat inilah yang akan dilindungi.
-
Event-driven Architecture
Dalam event-driven architecture, antara pengirim event dan penerima event tidak saling tahu. Mereka berkomunikasi melalui perantara. Setelah merenung sejenak, saya berkesimpulan bahwa yang harus dilindungi adalah pengiriman dan penerimaan event. Pengirim event harus punya hak mengirim event. Dalam hal ini, subjeknya adalah pengirim, predikatnya mengirim, dan objeknya adalah event. Penerima event juga harus punya hak menerima event. Dalam hal ini, subjeknya adalah penerima event, predikatnya adalah menerima, dan objeknya adalah event.
-
Actor model
Actor model berkomunikasi antar actor dengan saling berkirim message. Tidak sebagaimana RPC, message belum tentu dibalas. Tidak sebagaimana event, message punya alamat penerima dan biasanya ada alamat pengirim. Artinya, subjeknya adalah pengirim, predikatnya adalah mengirim pesan, dan objeknya adalah penerima. Yang dilindungi adalah penerimanya.
Masalah-masalah dalam Hak Akses
Masih banyak bentuk aplikasi lain yang tidak termasuk empat bentuk di atas. Tapi, sementara empat itu saja cukup. Itupun saya sudah puyeng. Yang penting, subjek dan predikat dari masing-masing bentuk aplikasi tadi sudah berhasil dikenali. Sekilas, bentuk-bentuk tersebut mengisyaratkan bahwa RBAC saja tampaknya sudah memadai untuk menjawab kebutuhan access control untuk banyak kasus. Tapi, kok rasanya masih mengganjal ya? Baiklah, mari kita urai apa saja yang kira-kira belum terjawab:
-
Masalah "Cabang"
Dimisalkan sebuah toko buku daring memiliki banyak cabang. Katakanlah, di seluruh dunia, ada cabang Indonesia, cabang Amerika, cabang Cina, cabang Eropa, dan cabang Arab. Masing-masing cabang ini punya penggunanya sendiri-sendiri dan setiap cabangnya memiliki banyak admin. Bagaimana caranya seorang menjadi admin di cabang Amerika saja tapi tidak bisa berbuat apa-apa di cabang lainnya?
-
Masalah "Otonomi"
Misalnya kantor cabang suatu instansi di DIY punya kebijakan berbeda dengan instansi di Jawa Tengah. Bagaimana caranya agar cabang-cabang instansi masing-masing memiliki skema hak akses yang berbeda-beda?
-
Masalah "Hak Istimewa"
Dimisalkan seorang pelanggan toko buku daring akan mendapatkan hak istimewa jika dia sudah membeli buku senilai minimal enam puluh lima ribu lima ratus tiga puluh lima rupiah. Bagaimana access control mengakomodasi hak istimewa ini tanpa harus berurusan langsung dengan proses bisnis pembelian buku?
-
Masalah "Kepemilikan"
Katakanlah toko buku daring ini sekaligus juga menyediakan aplikasi membaca daring. Bagaimana caranya agar hak akses dibatasi hanya untuk buku-buku yang sudah dibeli dan dimilikinya?
-
Masalah "Data Pelanggan"
Jika seorang petugas layanan pelanggan mendapat laporan dari seratus dua puluh tujuh pelanggan, bagaimana membatasi hak akses hanya kepada laporan yang datang kepadanya saja?
-
Masalah "Hirarki"
Di atas kabupaten, ada provinsi. Di atas provinsi ada negara. Bagaimana cara menangani hak akses untuk organisasi yang punya beberapa tingkatan?
Masalah-masalah ini adalah apa yang sudah pernah saya temui di sekitar saya. Sangat keren memang kalau ingin menyelesaikan semua masalah ini sekaligus. Tapi, kecenderungan solusi sapu jagat kalau tidak sangat rumit ya sangat abstrak. Saya nggak mau seperti ini. Pengennya, hasil akhirnya nanti adalah solusi yang gampang dipakai untuk hal-hal yang umum dan sederhana, dan bisa dikembangkan sesuai kebutuhan jika masalah-masalah yang muncul semakin rumit.