RBAC (Role Base Access Control) and Otorisasi Terdistribusi.
Ummm… sebenarnya ini hanya sebuah bahasan tua yang mungkin penting -gak penting di dunia IT.
Gak Penting karena apa yang kita bahas adalah suatu mekanisme umum tentang sistem keamanan yang sebenarnya merupakan konsep yang sudah ada sejak sangat lama. Lamaaa sekali. Sebelum adanya teknologi informasi-pun, konsep keamanan sudah ada sejak jaman dulu. Contohnya maling baju, yang diam-diam berusaha membobol pintu rumah untuk bisa memasuki rumah korbannya. Mungkin konsep keamanan sudah ada sejak pintu dan kunci ditemukan. Ya gak ? Lagian, sudah banyak sistem dan aplikasi yang sudah menggunakan konsep-konsep keamanan. Gak ada yang baru. Kata siapa ?
Penting karena apa yang kita bahas adalah suatu mekanisme yang secara umum memerlukan perhatian khusus dan menyeluruh hingga jaman sekarang, jaman Informasi. Security is a never ending journey.
Dulu, orang maling baju, perhiasan, TV dan peralatan elektronik. Dan detik ini, orang maling informasi, data-data dan kerahasiaan. Kerugian yang timbul akibat perbuatan maling-maling jaman now ini gak kecil lho.
Begini. Kamu punya perusahaan gak? Kalau punya, perusahaan kamu itu punya WebSite gak? Kalau punya, tau gak kalau WebSite perusahaan kamu itu pernah digedor maling, setidaknya sekali aja tahun lalu? Menurut report dari Kaspersky ini, 91% perusaan di dunia mendapatkan serangan cyber tahun lalu. 45% dari yang diserang tidak siap terhadap serangan itu. 17% berhasil kebobolan dan 30% masih gak tau kalau dia kebobolan dan gak tau gimana menjaga keamanan WebSite mereka itu.
Jadi, ya terserah kamu apakah apa yang akan dibahas ini penting apa enggak. Kalau kamu mikir ini gak penting, ehh... , jangan-jangan kamu malingnya.
Authentication atau Authorization?
Pembahasan mengenai keamanan sistem biasanya bertitik berat kepada dua hal. Authentication dan Authorization.
Authentication adalah cara untuk memastikan bahwa seseorang itu adalah dirinya sendiri sebagaimana yang dia klaim. Sedangkan Authorization adalah cara untuk memberikan wewenang tentang apa-apa saja yang boleh atau tidak boleh dilakukan oleh seseorang.
Access Control (AC), adalah suatu konsep tetang bagaimana mengatur “Access” seseorang atau sesuatu terhadap sesuatu. Jadi, bisa dibilang, AC berbicara tentang cara melakukan Authorization.
Kenapa RBAC?
Ada banyak metode-metode seputar Access Control (AC). Seperti disebutkan di WikiPedia, ada Attribute Based (ABAC), Discresionary (DAC), History Based (HBAC), Identity Based (IBAC), Mandatory (MAC), Rule Based (RAC), Organization Based (OBAC) dan yang akan kita bahas adalah Role Based (RBAC).
Role Based AC saya pilih disini karena cara pemberian kewenangan akses terhadap sesuatu itu dengan mengikuti model struktur jabatan. Dan model pemberian akses dengan cara seperti ini sudah sangat populer dalam aplikasi-aplikasi perusahaan besar ataupun kecil.
Idenya secara sederhana seperti berikut ini:
- Semakin tinggi jabatan kamu, maka semakin banyak wewenang yang kamu dapat.
- Semakin rendah jabatan kamu, maka semakin terbatas hak-hak akses yang diberikan kepada kamu.
Diagram dibawah meng-ilustrasi-kan apa yang saya maksud diatas.
Dari diagram diatas, bisa dilihat jika semakin tinggi jabatan seseorang dalam organisasi, maka orang tersebut “diizinkan” untuk melakukan apapun yang bisa dilakukan oleh bawahannya. Diagram diatas menunjukan, “menjadi seorang boss besar, ia boleh melakukan/mengakses semua fungsi-fungsi yang bisa dilakukan oleh semua boss, semua kepala dan semua pegawai”.
Konsep RBAC
Ide mengenai RBAC pertama kali di sebut-sebut dalam sebuah tulisan ilmiah oleh David F. Ferraiolo dan D. Richard Kuhn berjudul “Role-Based Access Control” di tahun 1992.
Dalam paper tersebut, secara ilmiah dijelaskan mengenai bagaimana sebuah sistem komputer melakukan Authorization terhadap setiap penggunanya. Serta bagaimana struktur data sebuah “Authorization System” menyimpan data-data perizinan (permission). Orang dulu, kalau bikin konsep IT, banyak menggunakan permodelan matematis. Yang gak doyan matematika gak perlu baca bukunya. Baca artikel ini saja ya… biar gak pusing. Dalam artikel ini, semua gambaran-gambaran matematisnya dijelaskan dengan mudah. Percaya deh.
Berikut ini adalah beberapa notasi-notasi matematis dalam paper Pak David dan Pak Richard.
Diketahui 3 buah himpunan :
AR(s:subject) = { Role yang aktif bagi seorang subyek }
RA(s:subject) = { Semua Role yang dimiliki oleh sorang subyek }
TA(r:role) = { Semua transaksi yang dimiliki oleh sebuah role }
Dengan modal 3 himpunan diatas, maka dibuatlah sebuah peraturan. (Jangan terlalu memusingkan notasi matematisnya, cukup pahami penjelasan dari setiap peraturan/hukum dibawah)
- Notasi Hukum AR (Active Role)
∀s : subject ,t :tran ,(exec (s,t) ⇒ AR (s) ≠ Ο ).
Notasi diatas maksudnya, Untuk seseorang (Subject) agar dapat melakukan suatu aktifitas (Tran/Transaction), maka orang itu harus memiliki Role yang Aktif. Atau disebut sebagai Hukum AR.
2. Notasi Hukum RA (Role Authorization)
∀s : subject ,(AR (s) ⊆ RA (s)).
Notasi diatas maksudnya, Untuk seseorang (Subject) yang memiliki AR (Active Role), maka AR tersebut harus berasal dari kumpulan Role yang sudah di miliki oleh orang tersebut. Dengan kata lain, seseorang boleh memiliki beberapa role, setiap role tersebut dapat dipergunakan untuk melakukan aktifitas tertentu. Ini disebut Hukum RA.
3. Notasi Hukum TA ( Authorized Transaction )
∀s : subject ,t : tran , (exec (s,t) ⇒ t ∈TA (AR (s))).
Notasi diatas maksudnya, hanya aktifitas-aktifitas tertentu saja yang di berikan kepada sebuah Active Role, yang bisa dilakukan oleh seseorang. Ini disebut Hukum TA.
4. Notasi Hukum AA ( Authorized Access )
∀s : subject ,t : tran , o : object ,(exec (s,t) ⇒ access (AR(s), t,o, x)).
Notasi diatas maksudnya, walaupun sebuah role memiliki aktifitas-aktifitas tertentu, hal ini masih di atur lebih jauh dengan beberapa parameter tambahan, seperti ‘t’ jenis transaksinya, ‘o’ jenis obyek nya, dan ‘x’ model eksekusinya.
Bayangkan jika Pak Badu adalah seorang staff kepegawaian. Seorang staff kepegawaian boleh mengakses data pegawai. Tapi, sebagai staff kepegawaian biasa, tidak boleh mengubah data-data pegawai. Boleh lihat, gak boleh ubah.
Jadi, sebuah fungsi access(R,T,O,X) bisa dibaca “Seseorang bisa meng-akses data O secara X dalam sebuah aktifitas T dalam kapasitasnya sebagai R”. Untuk kasus Pak Badu, dibaca menjadi “Pak Badu bisa meng-akses data kepegawaian (O), hanya baca tanpa mengubah (X), sewaktu bekerja dengan system (T) sebagai seorang staff kepegawaian (R)”.
Dong? (red. bahasa Cina yang artinya “Mengerti ?”)
Heits… jangan bingung, sebenarnya ini gak ribet-ribet amat. Kalau ente lihat diagram dibawah akan jadi jelas. Mudah-mudahan.
Sekarang, Bagaimana kalau kata “Subyek” kita ganti dengan “User”, “Transaction” kita ubah menjadi “Permission”. Kemudian “Active Role” menjadi “Session”. Dan dibuatkan sebuah diagram yang menggambarkan empat hukum diatas.
“Ding Dong… Ding Dong…” nah, setelah melihat diagram diatas, terlihatlah maksud Pak David dan Pak Richard dalam paper mereka. Dijelaskan secara logis.
Yap, ada apa? Kenapa ada garis merah diatas entity “Role” dalam diagram diatas? Itu adalah untuk menjelaskan struktur hirarki dari Role, hirarki yang menggambarkan struktur kewenangan dan jabatan. Dalam paper Pak David dan Pak Richard, garis merah itu tidak digambarkan dalam notasi matematis, tapi artikel mereka menyebutkan secara jelas disebutkan bahwa sebuah Role bisa memiliki “Child” Role.
Satu yang sedikit berbeda dari konsep “Parent-Child Inheritance” dalam dunia OOP, dimana “Child akan mewarisi sifat Parent-nya”. Untuk urusan Access Control, makna Inheritance ini dibalik menjadi “Parent memiliki semua hak akses dari Child-nya”. Namanya juga Orang Tua.
RBAC Zaman Sekarang
Sejak tahun 1992, hingga artikel ini ditulis 2018, berarti sudah 26 tahun berlalu. Kemajuan teknologi informasi sudah melewati 2 dekade dan menjelang dekade ke 3. Dengan sedemikian banyaknya perubahan mengikuti perkembangan zaman, apakah RBAC masih relevan? Jawabannya tentu saja! RBAC hanyalah merupakan ide dasar yang menyarankan agar kewenangan akses mengikuti sebuah struktur tertentu, dalam hal ini adalah jabatan seseorang dalam organisasi. Secara prinsip, Authorization tidak banyak berubah dalam dunia korporat. Hanya beberapa penambahan “fitur”.
- User sekarang bisa di kategorikan kedalam “User Group”.
- “User Group” seperti halnya “User” bisa memiliki “Role”.
- Pemberian akses terhadap User atau User Group bisa secara Ad-Hoc.
- Session kini bisa lebih bersifat “Idempotent” dan “Distributed”
- Dan berbagai macam “add-on” lainnya.
Kini, fungsi authorization ini sudah menjadi bagian terpisah dari sistem-sistem utama dalam perusahaan. Banyak yang berdiri sendiri secara independen dan menjadi tempat menyimpan data identitas dan otorisasi sistem dalam ekosistem IT perusahaan. Dengan nama “Identity Provider” atau “Identity Management”, system ini menjadi pusat kontrol akses corporate wide.
Analogi Kunci Pintu err… Kunci Akses
Bayangkan di sebuah komplex perkantoran, “Sukses Business Park”, berisi banyak gedung-gedung perusahaan. Setiap perusahaan mempunyai pintu utama di kantor mereka. Setelah kita memasuki pintu sebuah kantor, ada pintu-pintu lain untuk memasuki tiap-tiap area departemen. Lebih jauh lagi, apa bila kita masuk kedalam pintu salah satu departemen itu, ada pintu-pintu lagi untuk tiap-tiap pegawai atau fungsi-fungsi lain seperti janitor, ruang arsip, ruang meeting, ruang rekreasi, dsb.
Di setiap pintu-pintu itu ada label-nya. Di salah satu kantor, pintu terluar bertuliskan “PT.ABC”, kemudian didalamnya ada pintu dengan label:
“PT.ABC — Dept Keuangan”,
“PT.ABC — Dept IT”,
“PT.ABC — Dept Operasional”, dst.
Didalam ruangan dengan label “PT.ABC — Dept Keuangan”, ada pintu-pintu: “PT.ABC — Dept Keuangan — Janitor”,
“PT.ABC — Dept Keuangan — Kepala Departemen”,
“PT.ABC — Dept Keuangan — Staff Keuangan”,
“PT.ABC — Dept Keuangan — Ruang Server”,
“PT.ABC — Dept Keuangan — Ruang Meeting”, dst.
Kemudian ada 6 orang pegawai. Setiap pagi, mereka akan mendaftar di pos security “Sukses Business Park” untuk mendapatkan kunci. Setelah menunjukan KTP dan kartu pegawai, mereka diberikan kunci.
Pegawai #1, Pak Budi mendapat kunci, yang pada gantungan kuncinya bertuliskan “PT.ABC ”. Kunci ini hanya bisa membuka pintu depan kantor PT.ABC saja.
Pegawai #2, Pak Rianto mempunyai kunci, yang pada gantungan kuncinya bertuliskan “PT.ABC — *”. Kunci ini bisa membuka semua pintu yang ada di dalam PT.ABC, disemua departemen, semua ruangan.
Pegawai #3, Pak Totok mempunyai kunci, yang pada gantungan kuncinya bertuliskan “PT.ABC — Dept Keuangan”. Kunci ini hanya bisa membuka ruangan utama Departemen Keuangan di PT.ABC.
Pegawai #4, Pak Hendra mempunyai kunci, yang pada gantungan kuncinya bertuliskan “PT.ABC — Dept Keuangan — *”. Kunci ini bisa membuka semua pintu di dalam Departemen Keuangan di PT.ABC.
Pegawai #5, Pak Heru mempunyai kunci, yang pada gantungan kuncinya bertuliskan “PT.ABC — Dept Keuangan — Janitor”. Kunci ini hanya bisa membuka pintu ruangan Janitor di departemen keuangan PT.ABC.
Pegawai #6, Pak Parjo mempunyai kunci, yang pada gantungan kuncinya bertuliskan “* — Mail Room”. Kunci ini bisa membuka semua mailroom di perusaaan apapun di “Sukses Business Park”.
Analogi pada Sistem IT
Sekarang, dengan melihat diagram diatas, mari kita buat analogi system IT-nya.
Bisa kita bandingkan, kalau sistem IT yang kita operasikan ternyata mirip-mirip dengan sebuah komplek perusahaan dengan struktur-struktur pintunya. Office Complex =Service Farm, Perusahaan = Service, Departemen = Service Endpoint, Ruangan = Method.
Ada yang ekstra, “Auth System” yang digambarkan sebagai kotak merah. Sistem ini merupakan manajemen akses RBAC seperti yang digambarkan pada 50% isi artikel ini diatas.
Sistem RBAC ini lah yang menyimpan “kunci” untuk diberikan kepada siapapun yang berhak.
Lantas, “Kunci” padanan-nya apa ? Jawabannya “Access Token”.
Access Token
Access Token adalah sebuah informasi yang dipergunakan oleh sebuah sistem untuk menunjukan bahwa sistem tersebut “berhak” untuk meng-akses suatu fungsi atau “sumberdaya” sebagaimana disebutkan didalamnya. Halah… ribet ya.
Pokoknya Access Token itu fungsinya ya mirip kunci.
- Access Token hanya bisa diambil dari “Auth System”, seperti halnya kunci cuma bisa diambil dari pos sekuriti (dalam konteks artikel ini ya… bukan dari tukang kunci).
- Access Token dipastikan tidak bisa dimodifikasi. Mirip kunci yang terbuat dari “Bajanya Baja Super”. Kalau kuncinya bisa dibuat se-enaknya bisa bobol kantor orang.
- Informasi dapat “dilihat” dari dalam AccessToken, tapi informasi ini tidak bisa dirubah sebagaimana disebutkan di nomor #2. Kan ceritanya tiap kunci ada “Tag” nya yang tulisannya gak bisa diganti.
Seperti halnya kunci yang selalu dibawa-bawa kemanapun para pegawai pergi untuk membuka pintu-pintu yang di-izinkan, Access Token juga selalu “dibawa” setiap kali akan mengakses sistem-sistem yang dituju.
Pada umumnya, Access Token akan di pasang pada “Authorization” header di setiap HTTP request.
API-Gateway dan “Middleware” a.k.a “Filter” di setiap service akan memeriksa header ini untuk diperiksa informasi access token nya. Jika semua OK, barulah fungsi yang dimaksud akan dijalankan.
Kepemilikan Token
Token akan diberikan kepada “mereka” yang telah berhasil melakukan Authentication. Contohnya dengan memberikan username dan password, maka token dengan “authorization” yang sesuai akan diberikan sesuai dengan Role nya.
Maka, setiap kali user dimaksud akan melakukan HTTP request, token berisi authorization ini akan selalu diikutkan kedalam requestnya.
Data Authorization dalam RBAC
Diatas saya jelaskan kalau Access Token itu dibuat oleh sistem authentikasi yang ber-arsitektur RBAC. Berikut ini gambaran struktur data dalam RBAC yang kita bahas sebelumnya.
Kalau anda perhatikan, struktur data dalam RBAC ini menggambarkan bagaimana seseorang yang memiliki role tertentu bisa memiliki Access Token yang secara jelas menentukan service, path dan access apa yang boleh.
Apa yang sudah kita pelajari ?
- Arsitektur Role Based Access Control sebagaimana dijelaskan oleh author asli nya, Pak David dan Pak Richard.
- Analogi Access Control sebagaimana sistem keamanan tradisional yang menggunakan kunci dan pintu untuk membatasi siapa yang dapat mengakses tempat-tempat tertentu, dan bagaimana aplikasinya di sistem IT dengan menggunakan Access Token.
- Bagaimana API Gateway dan End-Point Middleware melakukan validasi terhadap otorisasi dalam Access Token.
- Bagaimana struktur data RBAC bisa dibentuk untuk menghasilkan Access Token bagi usernya.
Tertarik untuk eksplorasi lebih jauh ?
- Dalam artikel ini disebutkan mengenai Token dan Access Token. Salah satu implementasi Token yang sedang booming sekarang adalah JWT
- Artikel ini membahas tentang security. Namun artikel ini masih jauh dari cukup untuk membuat sistem yang aman. Anda bisa melakukan riset lebih jauh tentang “Access Token”, “Refresh Token”, “OAuth”, “SSL”, “ApiGateway”, dan lain sebagainya.
- Banyak implementasi RBAC yang menggunakan LDAP sebagai sistem pendukung dibelakangnya.
- Ada beberapa implementasi RBAC yang cukup terkenal seperti OpenAM dan OpenIDM dari ForgeRock.
- RBAC tidak memiliki kemampuan untuk memberikan otorisasi berdasarkan user profile. Contohnya, “Nak Ali boleh setir mobil kalau sudah berumur 17 tahun. Kalau belum hanya boleh naik sepeda”.
- Dan banyak lagi… Ayo kita eksplorasi lebih jauh lagi mengenai arsitektur dunia IT di artikel-artikel berikutnya bersama saya Ferdinand Neman dan teman-teman Pujangga Teknologi.
P.S. Jika teman-teman menyukai artikel semacam ini, silakan subscribe ke newsletter kita dan dapatkan notifikasi artikel terbaru langsung di inbox kamu!
