Bagaimana cara merancang kontrol akses berbasis peran?


15

Saya mencoba mengikuti model kontrol akses basis peran untuk membatasi apa yang dapat atau tidak dapat dilakukan pengguna di sistem saya.

Sejauh ini saya memiliki entitas berikut:

pengguna - Orang yang akan menggunakan sistem. Di sini saya memiliki nama pengguna dan kata sandi. peran - Kumpulan peran yang dapat dimiliki pengguna. Hal-hal seperti sumber daya manajer, admin, dll. - Hal-hal yang dapat dimanipulasi pengguna. Seperti kontrak, pengguna, konsep kontrak, dll. Operasi - Hal yang dapat dilakukan pengguna dengan sumber daya. Suka membuat, membaca, memperbarui atau menghapus.

Sekarang, keraguan saya muncul di sini dalam diagram di mana saya memiliki hubungan seperti ini:

operasi (0 .. *) dijalankan pada sumber daya (0 .. *) yang menghasilkan tabel yang saya sebut izin dan yang akan menyimpan operasi dan sumber daya .

Tabel izin akan terlihat seperti ini (satu baris): ID: 1, operasi: buat, sumber daya: kontrak.

Yang berarti izin untuk membuat sebuah kontrak .

Saya telah melakukannya dengan cara ini karena saya merasa beberapa sumber daya mungkin tidak memiliki semua jenis operasi. Misalnya, untuk mendaftar kontrak , pengguna dapat mengunggah file , tetapi operasi ini tidak tersedia untuk mendaftarkan penyedia .

Jadi sekarang ketika administrator akan memberikan izin untuk sebuah peran , ia tidak akan memiliki daftar sumber daya dengan setiap operasi yang terdaftar dalam sistem.

Saya pikir setiap sumber daya memiliki koleksi operasi sendiri yang dapat dijalankan padanya.

Saya bisa mengklarifikasi jika ada sesuatu yang tidak bisa dimengerti.

Apakah ini cara yang benar untuk mengimplementasikan rbac?

EDIT

Maksud saya adalah bahwa dengan memiliki tabel izin yang memiliki operasi dan sumber daya , saya punya DUA tabel tambahan karena saya ingin mengaitkan sumber daya dengan operasi . Saya juga bisa melakukan sumber daya yang memiliki izin di mana tabel izin akan menyimpan izin.

Tetapi kemudian apa yang akan terjadi adalah bahwa beberapa izin yang bahkan tidak ada untuk beberapa sumber daya akan muncul ketika admin akan menugaskan mereka.

Jadi saya ingin tahu dari sudut pandang desain database jika tabel ini mengizinkan yang memiliki satu operasi kolom dan sumber daya lain sudah benar? Apakah saya akan mengalami masalah jika tetap seperti ini?


2
Apa yang Anda maksud dengan "benar?" Catatan: jangan menjawab dengan tautologi seperti "praktik terbaik." Nyatakan persyaratan spesifik Anda.
Robert Harvey

1
Definisi saya "benar" biasanya adalah "yang paling efektif memenuhi persyaratan fungsional dan non-fungsional perangkat lunak Anda." Perhatikan bahwa NIST menawarkan panduan terperinci dan praktik terbaik untuk keamanan berbasis peran. Lihat csrc.nist.gov/groups/SNS/rbac
Robert Harvey

Anda mungkin tertarik melihat bagaimana hal itu dilakukan dalam proyek pakar .
Antarr Byrd

1
Anda harus mempertimbangkan menggunakan perpustakaan untuk ini.
RibaldEddie

Ada banyak perpustakaan yang akan mengerjakan RBAC atau ABAC untuk Anda
David Brossard

Jawaban:


10

Desain Anda sepertinya cukup dekat dengan saya. Hanya beberapa saran.

pengguna - Orang yang akan menggunakan sistem. Di sini saya memiliki nama pengguna dan kata sandi.

Baik

peran - Kumpulan peran yang dapat dimiliki pengguna. Hal-hal seperti manajer, admin, dll.

Baik baik juga. Tetapi Anda juga akan membutuhkan entitas / tabel "UserRoles" yang akan memberi tahu Anda pengguna mana yang memiliki peran apa. Sangat mungkin bahwa pengguna yang diberikan mungkin memiliki dua peran atau lebih.

sumber daya - Hal-hal yang dapat dimanipulasi pengguna. Seperti kontrak, pengguna, konsep kontrak, dll.

Mungkin hanya masalah semantik. Saya tidak berpikir pengguna memanipulasi sumber daya secara langsung; peran lakukan. Jadi ia pergi pengguna -> peran pengguna -> peran -> operasi -> sumber daya

operasi - Hal-hal yang dapat dilakukan pengguna dengan sumber daya. Suka membuat, membaca, memperbarui atau menghapus.

ya, kecuali "peran" bukan "pengguna"

Tabel izin akan terlihat seperti ini (satu baris): ID: 1, operasi: buat, sumber daya: kontrak. Yang berarti izin untuk membuat kontrak.

Hmmm. Ada dua cara untuk melakukannya. Anda bisa memiliki tabel izin yang Anda jelaskan, tetapi Anda juga membutuhkan RolePermissionstabel / entitas tambahan yang memberi tahu Anda peran mana yang memiliki izin tersebut. Tapi saya tidak yakin itu perlu.

Cara yang lebih sederhana untuk melakukannya adalah tabel izin / entitas dengan kolom / atribut ini: ID Peran, ID Operasi, ResourceID. Dengan cara itu, operasi x kombinasi sumber daya ditugaskan langsung ke peran, bukan dimuat ke dalam izin yang ditugaskan ke peran. Ini menghilangkan satu entitas. Benar-benar tidak perlu untuk tabel izin role-agnostik yang terpisah, kecuali jika Anda ingin menentukan sebelumnya kombinasi izin yang diizinkan dan yang mana yang tidak.


Pertama-tama, saya setuju sepenuhnya dengan "peran" alih-alih koreksi "pengguna". Itu yang saya maksud juga. Sekarang, masalahnya adalah saya ingin mengaitkan sumber daya dengan operasi juga. Misalnya: sumber daya kontrak memiliki operasi seperti upload_file. Jadi yang tidak saya inginkan adalah operasi upload_file juga muncul di sumber lain yang tidak memiliki operasi upload_file seperti penyedia (sumber daya lain) ketika admin memberikan izin untuk sebuah peran.
imran.razak

13

Saya tidak akan menggunakan atau mengimplementasikan RBAC. Sebaliknya saya akan menggunakan ABAC. Biarkan saya jelaskan ...

  • RBAC atau kontrol akses berbasis peran adalah tentang manajemen pengguna dan penetapan peran. Di RBAC, Anda bisa mengatakan bahwa Alice adalah seorang manajer. Anda dapat mendefinisikan izin statis bersama dengan itu. Misalnya, seorang manajer dapat menyetujui pinjaman. Jadi ada tautan dari Alice ke manajer untuk menyetujuiLan sebagai izin. Ada banyak sistem yang memungkinkan Anda melakukannya sehingga Anda tidak perlu mengimplementasikan tabel Anda sendiri. Bahkan LDAP memiliki dukungan untuk set RBAC terbatas. Tidak apa-apa asalkan Anda memiliki peran dan izin yang relatif kecil. Tetapi bagaimana jika Anda ingin mempertimbangkan izin khusus akun seperti halnya kasus Anda? Lihat, hapus, masukkan? Bagaimana jika Anda ingin mempertimbangkan hubungan?
  • ABAC atau kontrol akses berbasis atribut adalah tentang kebijakan yang digerakkan, otorisasi halus. Dengan ABAC Anda dapat menggunakan peran sebagaimana didefinisikan dalam RBAC dan menulis kebijakan misalnya
    • Manajer dapat melihat dokumen di departemen mereka
    • Karyawan dapat mengedit dokumen yang mereka miliki

Dalam pertanyaan Anda, Anda pada dasarnya mendefinisikan model informasi. Objek Anda dan atributnya misalnya pengguna (nama, kata sandi, departemen ...); suatu objek (misalnya kontrak) dan sebagainya.

Model informasi

Di ABAC, karena itu Anda akan sepenuhnya memisahkan kode aplikasi / logika Anda dari logika otorisasi yang kemudian disimpan sebagai kebijakan menggunakan atribut. Izin itu sendiri disimpan tepat di kebijakan (lihat contoh di atas). Arsitektur penyebaran ABAC terlihat seperti berikut

Arsitektur Kontrol Akses Berbasis Atribut

Intinya adalah bahwa jika Anda mengambil pendekatan ABAC, Anda menulis kebijakan untuk ABAC (baik dalam XACML atau ALFA - ada banyak alat untuk itu) dan Anda tidak perlu lagi membuat kode kustom atau mengimplementasikan RBAC kustom atau kontrol akses lagi.


1
Dalam contoh kebijakan Anda, dikatakan bahwa Manajer dapat melihat dokumen di departemen mereka. Apakah ini berarti bahwa sistem sudah memiliki izin, peran, dan tipe sumber daya yang sudah ditentukan sebelumnya?
imran.razak

Tidak. Ini berarti Anda akan memiliki sesuatu (LDAP? Tabel?) Yang menautkan pengguna (Alice) ke perannya (manajer ...). Anda kemudian akan memiliki tabel yang akan berisi metadata dokumen (yang biasanya merupakan tabel dalam aplikasi yang Anda lindungi). Izin itu sendiri (lihat, edit, hapus) disimpan dalam kebijakan.
David Brossard
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.