Tidak ada (hampir) yang tahu apa itu otorisasi.

Selama saya bekerja sebagai arsitek dalam proyek implementasi IdM, saya menganalisis lusinan implementasi mekanisme otorisasi baik dalam solusi internal perusahaan maupun produk komersial, dan saya dapat mengatakan bahwa hampir di mana-mana dengan persyaratan yang relatif kompleks mereka tidak dibuat dengan benar atau, setidaknya, tidak secara optimal. Alasannya, menurut saya, adalah rendahnya perhatian pelanggan dan pengembang terhadap aspek ini pada tahap awal dan penilaian yang tidak memadai tentang dampak persyaratan. Ini secara tidak langsung menegaskan penyalahgunaan istilah yang meluas: ketika saya melihat ungkapan "otorisasi dua faktor," saya mulai merasakan sakit tepat di bawah punggung saya. Demi minat, kami menganalisis 100 artikel pertama tentang Habré di hasil pencarian untuk "otorisasi", hasilnya mengecewakan, ada banyak rasa sakit:


Dalam lebih dari 80% kasus, istilah ini digunakan secara tidak benar, kata "otentikasi" harus digunakan sebagai gantinya. Selanjutnya, saya akan mencoba menjelaskan apa itu dan mengapa sangat penting untuk memberikan perhatian khusus pada topik ini.

Apa ini

Mengutip Wikipedia:
Dari sudut pandang sistem informasi apa pun, ini adalah proses pengambilan keputusan dalam menyediakan akses ke subjek untuk melakukan operasi berdasarkan pengetahuan apa pun tentang subjek tersebut. Pada titik ini, subjek, sebagai suatu peraturan, harus sudah diidentifikasi (kita perlu tahu siapa dia) dan dikonfirmasi (identitasnya dikonfirmasi).

Implementasi otorisasi dalam pengembangan sistem informasi perusahaan atau produk yang difokuskan pada sektor korporasi adalah tugas yang sangat sulit dan bertanggung jawab, yang sering kali kurang mendapat perhatian pada tahap desain dan tahap pengembangan awal, yang di masa depan mengarah pada implementasi "penopang".

Masalah

Mari kita lihat persyaratan otorisasi apa yang dipenuhi, dan mengapa sangat penting untuk mempertimbangkannya pada awalnya ketika merancang suatu sistem, dan tidak menundanya untuk masa depan. Biasanya ada dua sumber persyaratan otorisasi dalam sistem informasi perusahaan - ini adalah bisnis dan keamanan informasi. Secara umum, bisnis ingin merahasiakan rahasia dan memberikan otoritas kepada pengguna sesuai dengan fungsinya dalam proses bisnis, dan keamanan ingin memastikan kecukupan otoritas minimum untuk setiap pengguna dan akses audit.

Ambil, misalnya, sistem hipotetis untuk menegosiasikan kontrak perusahaan besar, tipikal perusahaan berdarah. Persyaratan otorisasi bisnis berikut kemungkinan besar akan muncul:

1. Pengguna yang tidak terkait dengan kontrak tertentu tidak boleh melihatnya di sistem
2. Penulis kontrak harus melihatnya di semua tahap.
3. Pengguna dengan nilai minimal 10 memiliki hak untuk membuat kontrak.
4. Pengunjung harus melihat kontrak, dimulai dengan penerimaannya di atas panggung dan selanjutnya.
5. Kepala departemen harus melihat kontrak unit mereka naik hirarki.
6. Penulis kontrak dan kepala unit memiliki hak untuk menarik kontrak pada setiap tahap persetujuan.
7. Manajemen dan sekretariat kantor pusat harus melihat dokumen semua cabang.
8. Pengguna yang membuat kontrak seharusnya tidak memiliki hak untuk mendukungnya.

Dari keamanan, kita bisa mendapatkan persyaratan berikut :

1. Ketahui siapa yang memiliki akses ke kontrak tertentu.
2. Ketahui siapa yang memiliki akses ke kontrak tertentu pada titik waktu tertentu.
3. Untuk menghilangkan akses pengguna ke dokumen yang tersedia sebelumnya ketika mengubah tugas pekerjaannya.

Saya pikir para pengembang sudah takut :). Rasa sakit tambahan adalah variabilitas tinggi dari persyaratan ini. Omong-omong, menurut statistik satu waralaba 1C besar, persyaratan otorisasi tambahan adalah salah satu tugas paling umum untuk menyesuaikan konfigurasi tipikal.

Jadi, kami menunjukkan mengapa persyaratan ini bermasalah:

• Mereka tidak stabil. Probabilitas perubahan mereka, bahkan dalam jangka pendek, cenderung 1.
• Mereka saling memotong. Implementasinya mempengaruhi semua lapisan, dari desain basis data hingga UI.
• Mereka berbaring di bidang subjek. Ini mengarah pada konektivitas yang kuat dari mekanisme otorisasi dengan lapisan logika bisnis.
• Mereka memengaruhi kinerja.

Solusi

Model kontrol akses yang dikembangkan membantu kami memecahkan masalah ini:

MAC adalah model kontrol akses kredensial. Akses subjek ke objek ditentukan oleh tingkat aksesnya: tingkat akses subjek tidak boleh lebih rendah dari tingkat kerahasiaan objek.

DAC - kontrol akses langsung. Akses subjek ke objek ditentukan oleh keberadaan subjek dalam daftar akses (ACL) objek.

RBAC adalah model peran kontrol akses. Akses subjek ke objek ditentukan oleh keberadaan peran subjek yang berisi kekuatan yang sesuai dengan akses yang diminta.

ABAC adalah model atribut dari kontrol akses. Akses subjek ke objek ditentukan secara dinamis berdasarkan analisis kebijakan yang memperhitungkan nilai atribut subjek, objek, dan lingkungan. Ini juga termasuk PBAC, RAdAC, CBAC , dengan beberapa nuansa ( review chic dari CUSTIS ).

Mereka sangat dianjurkan untuk digunakan dalam bentuk aslinya tanpa menciptakan kembali roda. Cukup sering dalam sistem informasi yang kompleks kombinasi model digunakan. Misalnya, kombinasi ACL + RBAC populer ketika peran dimasukkan dalam daftar akses. Namun, penggunaan model siap pakai yang benar juga bukan tugas yang mudah. Tidak semua orang dapat memilih model yang tepat, memisahkannya dari logika bisnis dan mencapai kinerja mekanisme otorisasi yang dapat diterima.

Untuk mengimplementasikan persyaratan yang disebutkan di atas di bagian "Masalah", pada pandangan pertama, saya akan memilih kombinasi PBAC + ACL. Persyaratan dapat diimplementasikan sebagai berikut:

Persyaratan IS yang tercantum diimplementasikan tanpa masalah menggunakan ACL, tetapi kami menerapkan persyaratan bisnis 5 dan 7 menggunakan PBAC. Jadi untuk menerapkan persyaratan IS 1 dan 2, Anda harus menambahkan jurnal atau mekanisme yang serupa dengannya, karena untuk semua aturan kecantikannya yang dinamis diaudit dengan buruk:

Total

Otorisasi adalah topik yang diabaikan, baik dalam publikasi maupun secara langsung dalam proses pengembangan. Otentikasi dua faktor melalui SMS akan diputar ke situs oleh anak. Menerapkan otorisasi dengan benar dalam sistem perusahaan tanpa membuat tongkat penyangga adalah tugas yang sulit dimana penguasa dan arsitek mematahkan tombak, dan banyak produk komersial populer (misalnya, Atlassian Jira) berdiri di atas tongkat penyangga karena rumitnya persyaratan.

Kami sedang merencanakan serangkaian artikel tentang model otorisasi dan subjek secara keseluruhan. Kami menyambut pertanyaan dan saran tentang topik untuk dipertimbangkan.