Role Based Access Control Models

Pengertian RBAC (Role Based Access Control)

Dalam mengembangkan aplikasi, kita tentu membagi-bagi user sesuai fungsinya. Kita dapat merancang pembagian user sendiri atau kita belajar dari best practice yang pernah dilakukan. Best practice untuk pembagian akses aplikasi adalah menggunakan RBAC atau Role Based Access Control.

Dalam RBAC ini kita akan membuat Role untuk masing-masing tingkatan user. Dalam setiap Role ini terdapat berbagai menu yang diberikan kepada Role ini lengkap dengan permissionnya.

Misal Role Admin Purchasing akan mendapatkan menu Purchase Order dengan permission Create.
Kemudian Role Purchasing Manager akan mendapatkan menu Purchase Order dan Purchase Request masing-masing dengan permission Approve.

Secara relasi tabelnya Role -> Menu -> Permission .

Kemudian setiap user akan diberikan satu atau beberapa Role.
Dengan demikan akan terjadi relasi Many to Many untuk User <-> Role.

Dalam sistem keamanan komputer, role-based access control (RBAC) adalah sebuah pendekatan untuk membatasi akses sistem untuk pengguna yang berwenang. Hal ini digunakan oleh sebagian besar perusahaan dengan lebih dari 500 karyawan, dan dapat diimplementasikan melalui mandatory access control (MAC) atau discretionary access control (DAC). RBAC kadang-kadang disebut sebagai role-based security.

RBAC Model

Dalam sebuah organisasi, peran diciptakan untuk fungsi berbagai pekerjaan. Hak akses untuk melakukan operasi tertentu yang ditugaskan untuk peran tertentu. Anggota staf (atau pengguna sistem lain) yang ditugaskan peran-peran tertentu, dan melalui mereka memperoleh penugasan peran izin tertentu komputer untuk melakukan fungsi sistem komputer. Karena pengguna tidak diberikan izin secara langsung, tetapi hanya mendapatkan mereka melalui peran mereka (atau peran), pengelolaan hak pengguna individu menjadi masalah hanya menempatkan peran yang sesuai ke account pengguna; ini menyederhanakan operasi umum, seperti menambah user, atau mengubah departemen pengguna.

Tiga aturan utama yang ditetapkan untuk RBAC:

1. Tugas peranan: Sebuah subjek dapat melaksanakan izin hanya jika subjek telah dipilih atau telah ditugaskan peran.
2. Peran otorisasi: peran aktif Sebuah subjek harus berwenang untuk subjek. Dengan aturan 1 di atas, peraturan ini memastikan bahwa pengguna dapat mengambil peran hanya untuk yang mereka yang berwenang.
3. Izin otorisasi: Sebuah subjek dapat melaksanakan izin hanya jika izin berwenang untuk peran aktif subjek. Dengan aturan 1 dan 2, peraturan ini memastikan bahwa pengguna dapat berolahraga izin hanya untuk yang mereka yang berwenang.

Kendala tambahan dapat diterapkan juga, dan peran dapat dikombinasikan dalam suatu hirarki di mana tingkat yang lebih tinggi peran menggolongkan izin yang dimiliki oleh sub-peran.

Dengan konsep hirarki peran dan kendala, seseorang dapat mengontrol RBAC untuk membuat atau mensimulasikan lattice-based access control (LBAC). Jadi RBAC dapat dianggap sebagai superset dari LBAC.

Ketika mendefinisikan model RBAC, konvensi berikut ini berguna:

• S = Subyek = Seseorang atau agen otomatis
• R = Peran = Ayub fungsi atau judul yang mendefinisikan tingkat otoritas
• P = Permissions = Sebuah persetujuan mode akses ke sumber daya
• SE = Sesi = Sebuah pemetaan yang melibatkan S, R dan / atau P
• SA = Perihal Tugas
• PA = Izin Tugas
• RH = Sebagian memerintahkan Hirarki Peran. RH juga dapat ditulis: ≥ (notasi ini: x ≥ y berarti x mewarisi hak akses dari y.)

• Sebuah subjek dapat memiliki peran ganda.
• Peran dapat memiliki beberapa mata pelajaran.
• Peran dapat memiliki hak akses banyak.
• Sebuah izin dapat diberikan ke banyak peran.
• Operasi dapat diberikan hak akses banyak.
• Sebuah izin dapat ditugaskan untuk banyak operasi.

Sebuah kendala tempat aturan yang membatasi potensi warisan izin dari peran lawan, sehingga dapat digunakan untuk mencapai pemisahan tugas yang tepat. Misalnya, orang yang sama seharusnya tidak diperbolehkan untuk kedua membuat account login dan untuk mengizinkan pembuatan account.

Jadi, dengan menggunakan teori himpunan notasi :

•  dan merupakan banyak izin banyak untuk hubungan peran tugas.
•  dan merupakan subjek banyak banyak untuk hubungan peran tugas.
• 

Subjek mungkin memiliki sesi simultan dengan hak akses yang berbeda.

Hubungan dengan model lain

RBAC adalah akses kontrol kebijakan teknologi netral dan fleksibel cukup kuat untuk mensimulasikan DAC  dan MAC. Sebaliknya, MAC dapat mensimulasikan RBAC jika grafik peran terbatas pada pohon daripada partialy ordered set . Sebelum untuk pengembangan RBAC, MAC dan DAC dianggap model hanya dikenal untuk kontrol akses: jika model tidak MAC, itu dianggap menjadi model DAC, dan sebaliknya. Penelitian di akhir 1990-an menunjukkan bahwa RBAC jatuh dalam kategori baik.  Tidak seperti berbasis konteks kontrol akses (CBAC), RBAC tidak melihat konteks pesan (seperti sebagai sumber koneksi ini).

RBAC berbeda dari daftar kontrol akses (ACL), yang digunakan dalam tradisional diskresioner akses-kontrol sistem, dalam hal ini memberikan izin untuk operasi khusus dengan makna dalam organisasi, bukan untuk data tingkat rendah objek. Sebagai contoh, sebuah daftar kontrol akses dapat digunakan untuk memberikan atau menolak akses tulis ke file sistem tertentu, tetapi tidak akan mendikte bagaimana file yang bisa diubah. Dalam sistem RBAC berbasis sebuah operasi mungkin untuk ‘membuat account kredit’ transaksi dalam aplikasi keuangan atau untuk ‘mengisi tingkat gula darah tes’ rekor dalam aplikasi medis. Penugasan izin untuk melakukan operasi tertentu yang berarti, karena operasi butiran dengan makna dalam aplikasi. RBAC telah terbukti sangat cocok untukpemisahan tugas (SOD) persyaratan, yang memastikan bahwa dua atau lebih orang harus terlibat dalam otorisasi operasi kritis. Kondisi yang diperlukan dan cukup untuk keselamatan SOD dalam RBAC telah dianalisis. Sebuah prinsip yang mendasari SOD adalah bahwa tidak ada individu harus mampu efek pelanggaran keamanan melalui hak istimewa ganda. Dengan ekstensi, tidak ada orang yang dapat memegang peran yang latihan otoritas audit, kontrol atau review atas yang lain, peran bersamaan diadakan. ^[8] [9]

Penggunaan dan ketersediaan

Penggunaan RBAC untuk mengelola hak pengguna (hak akses komputer) dalam sistem tunggal atau aplikasi secara luas diterima sebagai praktek terbaik. Sistem termasuk Microsoft Active Directory, Microsoft SQL Server , SELinux , GRSecurity , FreeBSD , Solaris , Oracle DBMS , PostgreSQL 8.1 , SAP R / 3 , ISIS Papirus , FusionForge dan banyak lainnya secara efektif mengimplementasikan beberapa bentuk RBAC. Sebuah laporan 2010 disiapkan untuk NIST oleh Research Triangle Institute menganalisis nilai ekonomi dari RBAC untuk perusahaan, dan manfaat diperkirakan per karyawan dari downtime karyawan berkurang, provisioning lebih efisien, dan akses kontrol administrasi yang lebih efisien kebijakan. ^[3]

Dalam sebuah organisasi dengan infrastruktur TI yang heterogen dan persyaratan yang span puluhan atau ratusan sistem dan aplikasi, menggunakan RBAC untuk mengelola peran yang cukup dan menetapkan keanggotaan peran yang memadai menjadi sangat kompleks tanpa hirarkis penciptaan peran dan tugas istimewa. Strategi alternatif untuk tugas skala besar hak istimewa kepada pengguna dibahas dalam kertas putih: Melampaui Peran: Sebuah Pendekatan Praktis untuk Provisioning Pengguna Perusahaan . Sistem baru memperpanjang tua model yang NIST RBAC ^[10] untuk mengatasi keterbatasan RBAC untuk perusahaan-lebar penyebaran. Beberapa makalah akademis ada. Model NIST diadopsi sebagai standar oleh INCITS sebagai ANSI / INCITS 359-2004. Sebuah diskusi dari beberapa pilihan desain untuk model NIST juga telah dipublikasikan

Modeling Role-Based Access Control Using Parameterized UML Models (Dae-Kyoo Kim)

Organisasi menggunakan Role Based Access Control (RBAC) untuk melindungi sumber dayaberbasis komputer dari akses yang tidak sah. Telah cukup bekerja pada secara resmimenetapkan kebijakan RBAC namun masih ada kebutuhan untuk kebijakan teknikspesifikasi RBAC  yang dapat diintegrasikan ke dalam metode desain perangkat lunak.Makalah ini menjelaskan metode untuk menggabungkan spesifikasi kebijakan RBAC ke dalam model desain UML. Kebijakan RBAC dapat digunakan sebagai pola dan disajikandengan Template diagram UML . Kebijakan RBAC menjadi model spesifik aplikasimenyangkut penurunan pola dan menyusun instantiations dengan model. Metode ini juga termasuk teknik untuk menentukan pola pelanggaran RBAC. Pengembang dapat menggunakan pola untuk mengidentifikasi pelanggaran kebijakan dalam model mereka.Metode ini diilustrasikan menggunakan aplikasi perbankan kecil.

Kebijakan RBAC didefinisikan dalam hal perizinan yang terkait dengan peran yang ditetapkan untuk pengguna. Izin A menentukan operasi apa yang pengguna ditugaskan untuk peran bisa tampil di atas sumber daya informasi.

Bekerja pada formalisasi kebijakan RBAC telah menghasilkan pengembangan spesifikasinotasi baru , namun masih ada kebutuhan untuk kebijakan spesifikasi pendekatan yang dapat diintegrasikan dengan teknik desain yang digunakan dalam industri. Unified Modeling Language (UML) dianggap sebagai de-facto standar dari industri untuk modeling sistemberbasis software. Penggunaan UML untuk menentukan kebijakan RBAC memudahkan  di dalam menggabungkan kebijakan ke dalam model aplikasi UML.

Makalah ini menjelaskan metode yang mengintegrasikan spesifikasi kebijakan RBAC dandesain pemodelan UML. Metode ini meliputi  teknik untuk menentukan pola kebijakangenerik RBAC yang dapat dipakai untuk menghasilkan struktur desain aplikasi-spesifik yang menentukan kendala RBAC, teknik untuk menggabungkan sistematis struktur desain yang dihasilkan oleh pola kebijakan RBAC ke dalam model UML desain, dan teknik untukmenentukan struktur desain yang melanggar kendala RBAC sebagai pola.

Future Directions in Role- Based Access Control Models (Ravi Sandhu)

Dalam 5 tahun terakhir ada aktifitas penelitian yang luar biasa mengenai Role Based Access Control, konsensus telah tercapai dan akhirnya ditetapkan sebuah model RBAC standar yang dipublikasikan oleh US National Institute of Standards and Technology (NIST). fakta menunjukkan bahwa RBAC memiliki konsep Open-Ended yang dimana konsep tersebut sangat adaptif dengan aplikasi dan sistem-sistem yang baru. Namun ada Ada aspek penting dari model RBAC, seperti administrasi RBAC, yang masih belum dicapai. Model RBAC yang baru ini membahas konsep yang baru seperti delegasi dan personalisasi, yang dimana hal ini  tidak ada pada model sebelumnya . Aplikasi dari RBAC di dalam me manajemen alur kerja dari sistem telah banyak sekali diteliti oleh para peneliti. Penelitian tentang sistem RBAC yang melintasi batas-batas organisasi juga telah mulai dilakukan. Dari hal itu dapat disimpulkan bahwa Model RBAC tetap menjadi daerah yang subur untuk penelitian masa depan. Dalam tulisan ini dibahas beberapa topik yang menghasilkan beberapa cara praktis yang berguna sebagai tambahan dari state of art yang sudah ada dari model RBAC yang sudah ada sebelumnya .

• Model RBAC saat ini

Penggunaan pertama kali dari istilah RBAC adalah oleh Ferraiolo dan Kuhn walaupun sebelumnya sudah ada disebutkan dalam literatur keamanan seperti “Roles” dan “Role -Based Security.” Shandu dkk, kemudian menerbitkan sebuah makalah yang mendefinisikan model yang disebut dengan RBAC96. Sebuah topik penting yang didaptkan dari RBA96 adalah sebuah pernyataan bahwa RBAC dapat berkisar dari tovery yang sangat sederhanasehingga kita memerlukan keluarga model daripada model tunggal. Model tunggal terkadang sederhana untuk kebutuhan tertentu akan tetapi terlalu rumit untuk kebutuhan yang lain.

• Model RBAC Baru

Sekarang kita mempertimbangkan aspek dari model RBAC yang perlu dilakukan penelitian lebih lanjut, beberapa dari hal-hal tersebut sudah terekplorasi, beberapa bahkan sudah sangat matang akan tetapi konsensus dari masyarakat belum tercapai.

Kita bisa membagi diskusi kita kira-kira menjadi dua kategori : daerah di mana kemajuan yang kuat telah dibuat tapi konsensus perlu dikembangkan untuk mencapai kematangan seperti yang terkandung dalam standar, dan daerah-daerah dimana hanya pekerjaan awal yang baru dicapai.

Paradigma administrasi alternatif untuk RBAC telah baru-baru dibahas dalam literatur. (Hildmann dan Barholdt,1999)  dan (Herzberg dkk, 2000) mempertimbangkan beberapa masalah dalam menentukan peran untuk pengguna dalam sistem yang melintasi  batas organisasi.

(Barka dan Sandhu, 2000) telah mengusulkan kerangka kerja untuk pemodelan Delegasi dari peran dari satu pengguna yang lain. (Huang dan Atluri, 1999) membahas dinamika RBAC dalam sistem alur kerja. (Damianou dkk, 2001) dan (Hitchens dan Varadharajan , 2001) telah mengusulkan bahasa untuk menentukan kebijakan RBAC. (Thomas danSandhu, 1998) memiliki pendapat perlunya model otorisasi aktif yang self-adminstering.Makalah ini khusus membahas sudut pandang pada administrasi dari RBAC. Namun, Modelkami jauh lebih terpadu bagi masyarakat dan ini dapat dikembangkan.

Dalam Yii framework, implementasi RBAC dapat dipelajari dihttp://www.yiiframework.com/doc/guide/1.1/en/topics.auth#role-based-access-control .

Informasi lebih lanjut mengenai RBAC (Role Based Access Control) dapat dibaca dihttp://en.wikipedia.org/wiki/Role-based_access_control .