Saat membaca tentang ACL dan RBAC, saya tampaknya memahaminya dengan mudah - ada nama pengguna atau peran yang diberikan akses ke aset. Saya juga bisa melihat bagaimana saya bisa mengimplementasikannya.

yaitu gambar ini memberikan pandangan yang jelas tentang ACL dan RBAC untuk saya (seperti pada saya dapat melanjutkan dan mendesain tabel database berdasarkan di atas): (Gambar milik buku cetak )

Yang saya perjuangkan adalah ABAC. Berbagai gambar yang saya temukan sejauh ini bergelombang dengan tangan atau terlalu rumit, atau menyarankan menggunakan entitas eksternal pihak ketiga untuk melakukan Otorisasi. Atau berikan contoh atribut aneh saya tidak sepenuhnya yakin cara menggunakannya.

Mulai Contoh

Jadi izinkan saya mulai dengan sesuatu dalam kehidupan nyata. Katakanlah saya punya perusahaan dengan 70-200 orang. Dan aset saya untuk dilindungi adalah situs web dengan berbagai halaman. Saya ingin mengizinkan orang tertentu mengakses aset tertentu.

Misalnya, saya ingin seseorang Lesliememiliki akses ke halaman web yang disebut Price Manager, dan memungkinkannya untuk hanya mengelola harga untuk Travelgrup harga pada halaman itu, tetapi tidak dapat mengelola harga untuk Productgrup pada halaman yang sama. Bagaimana saya menerapkan ini menggunakan ABAC?

Menyodok sejauh ini, tebakan saya adalah saya dapat menetapkan Lesliebeberapa atribut (tetapi yang mana dan apa saja atribut ini?) Dan kemudian memiliki tabel database yang menyimpannya. Saya kemudian dapat merancang mesin yang melihat atribut-atribut itu (tetapi tidak melihat Lesliesebagai "Peran" seperti yang dilakukan di RBAC), dan memutuskan dari sana apakah akan memberikan akses ke halaman atau tidak. Seperti apa bentuk mesin itu? Apakah ini blok if / else sederhana? Sesuatu yang lain

Apa yang terjadi jika Leslie kemudian mengubah posisinya dan seseorang perlu mengubah aksesnya? Akan seperti apa jadinya jika dia perlu akses dipindahkan Productdan dicabut Travel? Bagaimana kode itu jika dia perlu memiliki akses dicabut ke Price Managerhalaman sama sekali dan karenanya tidak lagi memiliki akses ke Travel, atau Product?

Aset dalam kasus saya, hanya untuk menyatakan kembali, adalah Price Manager, dan pengguna dapat mengakses berbagai kelompok harga pada halaman itu, seperti Travelharga, Productharga, dll.

Apa yang saya cari adalah peta jalan yang cukup lengkap menuju klarifikasi detail dan menuju implementasi di mana saya bisa pergi dan mengimplementasikannya tanpa menebak. yaitu dapat diselesaikan secara konseptual dan / atau memiliki contoh spesifik di mana saya dapat memvisualisasikan struktur database, dll.

Bonus: Apakah ABAC cara yang tepat untuk kebutuhan izin yang relatif kecil yaitu mengelola 70-200 orang & akses ke sekitar 150 - 450 aset? Apakah lebih baik tetap menggunakan ACL / RBAC?

Implementasi ABAC lebih kompleks daripada ACL / RBAC. Beberapa kerangka kerja bahkan memberi Anda sedikit infrastruktur untuk menangani yang terakhir. Jika orang dan aset dapat dikelompokkan dalam jumlah peran / kategori yang relatif kecil dan tetap, maka yang terbaik adalah tetap menggunakan ACL / RBAC. Jika izin sangat berbeda dari orang ke orang, maka ABAC dapat memberikan solusi yang lebih baik dan lebih fleksibel.

Jika Anda memilih untuk turun ke jalur ABAC, hal pertama yang perlu Anda lakukan adalah meluangkan waktu membaca dan memahami standar XACML . Contoh-contoh yang disediakan dalam dokumen menggunakan sintaks yang kompatibel dengan XACML dan awalnya agak sulit untuk dikunyah. Saya kira Anda tidak ingin menerapkan solusi standar yang kompatibel sehingga Anda hanya perlu ide-ide umum darinya.

Konsep

XACML berputar di sekitar 4 konsep dan atributnya: subjek , tindakan , sumber daya , dan lingkungan . Ada beberapa lagi, tetapi ini yang paling penting. Segala sesuatu yang lain dibangun di atas mereka. Jika saya membuat kalimat dengan konsep-konsep ini, itu bisa menjadi sesuatu di sepanjang baris: subyek melakukan tindakan pada sumber daya di lingkungan tertentu . Menerapkan ini ke skenario Anda akan diterjemahkan menjadi sesuatu seperti:

• Leslie membuka halaman web pengelola harga.
• Leslie menciptakan harga perjalanan menggunakan halaman web pengelola harga.

Koleksi atribut

Hal pertama yang perlu kita lakukan adalah mengumpulkan atribut yang relevan dari konsep-konsep yang disebutkan di atas. Idealnya, Anda tidak boleh menetapkan atribut spesifik apa pun karena XACML mencoba untuk tidak mengganggu dan hanya mengandalkan apa yang disediakan oleh sistem secara alami. Jadi kita punya:

Subyek

Aktor apa pun, baik itu orang atau layanan, di sistem Anda. Subjek kami adalah Leslie. Atribut apa yang diperlukan untuk mengidentifikasi Leslie secara unik? Mungkin beberapa hal berikut: first name, last name, e-mail, ssn, company id, position(s).

Tindakan

Setiap tindakan yang dilakukan oleh subjek. Dapat berupa operasi CRUD standar atau sesuatu yang lebih kompleks. Tindakan kami adalah open/viewdan create. Atribut untuk tindakan ini dapat berbeda berdasarkan kerangka aplikasi web yang Anda gunakan. Kami akan berbicara lebih banyak tentang ini ketika kami sampai ke sumber.

Sumber

Cukup jelas. Sumber daya kami adalah price manager page, travel pricesdan the newly created price. Mungkin ada lebih banyak, jika Anda benar-benar mau. Anda mungkin ingin menyembunyikan tindakan yang tidak dapat dilakukan pengguna. Misalnya. yang create price buttondapat menjadi sumber daya yang dapat ditampilkan / disembunyikan berdasarkan apakah pengguna memiliki izin untuk membuat harga. Karena satu-satunya cara bagi pengguna untuk melihat daftar harga bisa melalui halaman ini, itu mungkin ide yang baik untuk menegakkan otorisasi pada tingkat ini daripada lebih jauh ke bawah tumpukan.

Akses ke sumber daya adalah yang paling rumit untuk diterapkan, terutama yang berasal dari basis data. Opsi berbutir halus adalah keamanan tingkat baris. Beberapa database memiliki tingkat dukungan tertentu untuk itu. Beberapa pelaksana XACML telah membuat superset SQL. Ini benar-benar tergantung pada kebutuhan otorisasi Anda, tetapi satu hal yang tidak ingin Anda lakukan adalah menarik semuanya dari sebuah tabel dan kemudian memutuskan apa yang akan ditampilkan. Anda dapat mengelompokkan sumber daya dengan set izin, mengabstraksikannya di belakang API dan menegakkan otorisasi di titik akhir API.

Lingkungan Hidup

Saya tidak dapat mendefinisikannya dengan benar (XACML juga tidak memiliki definisi yang tepat) tetapi katakanlah itu adalah "gelembung" di mana semua ini terjadi. Ini termasuk: web application, web server, operating system, browser, office. Anda bisa mengekstrak atribut seperti: ip address, time of day, user locale, user agent, operating system version. Anda dapat menggunakan ini bahkan untuk memblokir akses pengguna dari lingkungan yang tidak didukung oleh aplikasi Anda (mis. Browser lama, sistem operasi lama, komputer di luar jaringan Anda, akses di luar jam kerja).

Permintaan otorisasi

Setelah kami mengumpulkan semua atribut yang diperlukan, kami mengelompokkannya dalam permintaan otorisasi dan meneruskannya ke entitas yang dapat membuat keputusan otorisasi berdasarkan nilai-nilai atribut ini. Dalam XACML lingua tempat Anda mengumpulkan atribut-atribut ini dan menegakkan keputusan yang diambil kemudian disebut titik penegakan kebijakan (PEP) dan pengambilan keputusan titik disebut titik keputusan kebijakan (PDP). Lokasi dari mana nilai atribut diperoleh disebut titik informasi kebijakan (PIP). PEP, PDP, dan PIP dapat menjadi bagian dari aplikasi Anda, mereka dapat berupa sistem eksternal. Anda dapat menemukan diagram tentang bagaimana mereka berkomunikasi satu sama lain dalam standar XACML.

Proses pengambilan keputusan

Proses pengambilan keputusan didasarkan pada aturan . Aturan dapat dikelompokkan ke dalam kebijakan yang selanjutnya dapat dikelompokkan ke dalam set kebijakan . Masing-masing memiliki target . Target digunakan untuk memutuskan apakah ada aturan yang berlaku untuk permintaan otorisasi. Anggap saja sebagai filter. Target berisi kondisi yang dibangun menggunakan nama dan nilai atribut. Misalnya, aturan untuk aplikasi Anda dapat dikelompokkan menjadi sesuatu seperti:

Aplikasi web (kumpulan kebijakan)
| - target: application-name == "Aplikasi web"
`- Versi 1.0 (set kebijakan)
    | - target: application-version == "1.0"
    `- Lihat manajer harga (kebijakan)
        | - target: web-page-name == "price manager" && action-name == "view"
        `- Leslie dapat melihat harga manajer (aturan)
            | - target: subject-name == "Leslie"
            `- izin: izinkan

PDP akan mencocokkan segala sesuatu di set di atas dengan nilai atribut dalam permintaan otorisasi. Apa yang terjadi jika tidak ada aturan yang cocok itu tergantung pada implementasi PDP Anda. Setelah PDP membuat keputusan ( allow, denyatau not-applicable) , PDP mengirimkannya kembali ke PEP yang menindakinya dengan memberikan atau menolak akses ke sumber daya. Bersamaan dengan tanggapannya, PDP dapat mengirim daftar obligationsdan advicesbahwa PEP harus atau harus memenuhi dalam proses penegakan. Bergantung pada bagaimana aturan disimpan (file teks atau database) seorang administrator dapat menggunakan editor teks standar atau aplikasi pengeditan khusus untuk mengubahnya sesuai keinginannya. Mencabut akses Leslie ke manajer harga dilanjutkan dengan hanya mengubah izin dari allowmenjadideny, diberikan PEP melakukan tugasnya.

Pelaksanaan

Ini sangat tergantung pada tumpukan teknologi Anda. Beberapa kerangka kerja web memiliki titik penegakan alami (mis. ASP.NET MVC memiliki filter atribut). Lapisan bisnis Anda mungkin harus menentukan titik penegakan tersebut. Saya merasa lebih mudah untuk menerapkan penegakan pada titik akhir layanan (pikirkan microservices) atau tingkat UI.

Manfaat lainnya

Efek samping yang bagus dari penerapan ini adalah Anda berakhir dengan jejak audit yang cukup kaya yang dapat digunakan untuk tujuan lain.