Kami membangun model kontrol akses berbasis peran. Bagian Satu, Persiapan

Sekarang saya bekerja untuk vendor perangkat lunak, khususnya untuk solusi kontrol akses. Dan pengalaman "kehidupan masa lalu" saya terhubung dengan sisi pelanggan - sebuah organisasi keuangan besar. Pada saat itu, grup kami untuk kontrol akses di departemen keamanan informasi tidak dapat membanggakan kompetensi hebat di IdM. Kami belajar banyak dalam proses ini, kami harus mengisi banyak benjolan untuk membangun mekanisme kerja untuk mengelola hak pengguna dalam sistem informasi di perusahaan.



Setelah menggabungkan pengalaman saya dalam pelanggan dengan pengetahuan vendor dan kompetensi, saya ingin berbagi dengan Anda petunjuk langkah demi langkah: cara membuat model kontrol akses berbasis peran di perusahaan besar, dan apa yang akan diberikan pada akhirnya. Instruksi saya terdiri dari dua bagian: pertama - kami sedang mempersiapkan untuk membangun model, kedua - kami sebenarnya sedang membangun. Ini bagian pertama, persiapan.



NB Membangun model peran, sayangnya, bukan hasil, tetapi sebuah proses. Atau lebih tepatnya, bahkan bagian dari proses menciptakan ekosistem kontrol akses di perusahaan. Jadi dengarkan untuk jangka panjang.



Pertama, mari kita tentukan - apa itu kontrol akses berbasis peran? Misalkan Anda memiliki bank besar dengan puluhan atau bahkan ratusan ribu karyawan (subjek), yang masing-masing memiliki puluhan hak akses ke ratusan sistem informasi (objek) intra-bank. Sekarang gandakan jumlah objek dengan jumlah subjek - itu adalah jumlah minimum koneksi yang Anda butuhkan untuk membangun dan mengendalikan. Apakah realistis untuk melakukan ini secara manual? Tentu saja tidak - peran muncul untuk menyelesaikan masalah ini.



Peran adalah seperangkat izin yang diperlukan pengguna atau grup pengguna untuk melakukan tugas kerja tertentu. Setiap karyawan dapat memiliki satu atau lebih peran, dan setiap peran dapat berisi dari satu hingga banyak izin yang diizinkan untuk pengguna dalam peran ini. Peran dapat dikaitkan dengan posisi tertentu, departemen atau tugas fungsional karyawan.







Peran biasanya dibuat dari otorisasi masing-masing karyawan di setiap sistem informasi. Kemudian peran bisnis global dibentuk dari peran masing-masing sistem. Misalnya, peran bisnis manajer kredit akan mencakup beberapa peran berbeda dalam sistem informasi yang digunakan di kantor klien bank. Misalnya, dalam seperti sistem perbankan otomatis utama, modul tunai, sistem manajemen dokumen elektronik, manajer layanan dan lain-lain. Peran bisnis, sebagai suatu peraturan, terikat pada struktur organisasi dan staf - dengan kata lain, ke sekumpulan departemen perusahaan dan posisi di dalamnya. Ini adalah bagaimana matriks peran global dibentuk (saya berikan contoh pada tabel di bawah).







Perlu dicatat bahwa tidak mungkin untuk membangun model peran 100%, memberikan semua hak yang diperlukan kepada karyawan dari setiap posisi dalam struktur komersial. Ya itu tidak perlu. Bagaimanapun, model peran tidak bisa statis, karena itu tergantung pada lingkungan yang terus berubah. Dan dari perubahan dalam aktivitas bisnis perusahaan, yang, karenanya, mempengaruhi perubahan dalam struktur dan fungsi organisasi. Dan dari kurangnya penyediaan sumber daya penuh, dan dari ketidakpatuhan dengan deskripsi pekerjaan, dan dari keinginan untuk mendapatkan keuntungan dengan mengorbankan keselamatan, dan dari banyak faktor lainnya. Oleh karena itu, perlu untuk membangun model peran yang dapat mencakup hingga 80% dari kebutuhan pengguna untuk hak-hak dasar yang diperlukan ketika ditunjuk untuk suatu posisi. Dan mereka akan dapat, jika perlu, untuk meminta 20% sisanya nanti dengan permintaan terpisah.



Tentu saja, Anda dapat bertanya: "Apa, tidak ada panutan 100%?" Nah, mengapa ini terjadi, misalnya, dalam struktur nirlaba yang tidak mengalami perubahan sering - di beberapa lembaga penelitian. Atau dalam organisasi kompleks militer-industri dengan tingkat keamanan tinggi, di mana keamanan menjadi prioritas utama. Ini juga terjadi dalam struktur komersial, tetapi dalam kerangka unit yang terpisah, pekerjaan yang merupakan proses yang cukup statis dan dapat diprediksi.



Keuntungan utama dari manajemen peran adalah penyederhanaan pemberian hak, karena jumlah peran secara signifikan lebih kecil daripada pengguna sistem informasi. Dan ini berlaku untuk industri apa pun.



Ambil perusahaan ritel: mempekerjakan ribuan tenaga penjualan, tetapi mereka memiliki hak yang sama dalam sistem N, dan hanya satu peran yang akan dibuat untuk mereka. Penjual baru datang ke perusahaan - ia secara otomatis ditugaskan peran yang diperlukan dalam sistem, yang sudah memiliki semua kekuatan yang diperlukan. Anda juga dapat mengubah hak ribuan penjual dalam satu klik, misalnya, menambahkan opsi baru untuk menghasilkan laporan. Anda tidak perlu melakukan seribu operasi, menautkan hak baru untuk setiap akun - Anda hanya perlu menambahkan opsi ini ke peran, dan itu akan muncul untuk semua penjual pada saat yang sama.



Keuntungan lain dari manajemen berbasis peran adalah penghapusan penerbitan kekuasaan yang tidak kompatibel. Artinya, seorang karyawan yang memiliki peran tertentu dalam sistem tidak dapat secara bersamaan memiliki peran lain, yang hak-haknya tidak boleh digabungkan dengan hak-hak di tempat pertama. Contoh yang mencolok adalah larangan menggabungkan fungsi memasuki dan mengendalikan transaksi keuangan.



Siapa pun yang tertarik dengan bagaimana kontrol akses berbasis peran bisa terjadi
selami sejarah
, - 70- XX . , , , . , – , . , , .



, . , .



, , – () (DAC – Discretionary access control). . . . : .



– (MAC β€” Mandatory access control). . . , , , . , : , , .



- , - . ! , , .



1992 . RBAC (Role-based access control). , INCITS 359-2012, (INCITS).



Β« , , Β». RBAC – , , , , , .



– . , . , , . , , .. «», . «».







, . . ( , ). , , (/ ), (/) ..



(ABAC β€” Attribute-based access control). . , : , , . , , , , .



, , . . , , . , - .



ABAC Β« Β». . , . – , ! , , . , .



Sekarang mari kita bicara tentang langkah-langkah persiapan yang diperlukan, yang tanpanya tidak mungkin untuk membangun model peran yang berfungsi.



Langkah 1. Buat model fungsional



Layak dimulai dengan pembuatan model fungsional - dokumen tingkat atas yang menjelaskan secara rinci fungsi masing-masing departemen dan setiap posisi. Biasanya, informasi berasal dari berbagai dokumen: uraian tugas dan peraturan untuk masing-masing divisi - departemen, departemen, departemen. Model fungsional harus disetujui oleh semua departemen yang tertarik (bisnis, kontrol internal, keamanan) dan disetujui oleh manajemen perusahaan. Untuk apa dokumen ini? Sehingga panutan bisa merujuk padanya. Misalnya, Anda akan membangun model peran berdasarkan hak-hak karyawan yang ada - diturunkan dari sistem dan "dibawa ke common denominator." Kemudian, ketika mengoordinasikan peran yang diterima dengan pemilik bisnis sistem, Anda dapat merujuk ke item spesifik dari model fungsional,atas dasar ini hak ini atau itu termasuk dalam peran.



2. -



Langkah kedua adalah melakukan audit sistem TI untuk memahami bagaimana akses diatur untuk mereka. Sebagai contoh, perusahaan keuangan saya menjalankan beberapa ratus sistem informasi. Semua sistem memiliki beberapa dasar manajemen berbasis peran, kebanyakan dari mereka memiliki beberapa jenis peran, tetapi sebagian besar di atas kertas atau dalam manual sistem - mereka sudah ketinggalan zaman lama, dan akses ke mereka didistribusikan berdasarkan permintaan pengguna yang sebenarnya. Tentu saja, tidak mungkin untuk membangun model peran dalam beberapa ratus sistem sekaligus, Anda harus memulai suatu tempat. Kami melakukan tinjauan mendalam tentang proses kontrol akses untuk menentukan tingkat kematangannya. Selama analisis, kriteria untuk memprioritaskan sistem informasi dikembangkan - kekritisan, kesiapan, rencana penghentian, dll.Dengan bantuan mereka, kami telah membangun urutan untuk pengembangan / pembaruan model peran untuk sistem ini. Dan kemudian kami memasukkan teladan dalam rencana integrasi Manajemen Identitas kami untuk mengotomatisasi kontrol akses.



Jadi bagaimana Anda menentukan kekritisan suatu sistem? Jawab sendiri pertanyaan-pertanyaan berikut:



  • Apakah sistem terkait dengan proses operasional yang menjadi dasar bisnis inti perusahaan?
  • Apakah gangguan sistem akan mempengaruhi integritas aset perusahaan?
  • Berapa downtime sistem maksimum yang diijinkan, setelah itu tidak mungkin untuk memulihkan aktivitas setelah gangguan?
  • Dapatkah pelanggaran terhadap integritas informasi dalam sistem menyebabkan konsekuensi yang tidak dapat diubah, baik finansial maupun reputasi?
  • Kekritisan terhadap penipuan. Ketersediaan fungsionalitas, dengan kontrol yang tidak memadai, adalah mungkin untuk melakukan tindakan penipuan internal / eksternal;
  • Apa persyaratan hukum, serta aturan dan prosedur internal untuk sistem ini? Apakah akan ada denda dari regulator karena ketidakpatuhan?


Di perusahaan keuangan kami, kami melakukan audit sebagai berikut. Manajemen telah mengembangkan proses audit Tinjauan Hak Akses untuk menangani pengguna dan hak yang ada terlebih dahulu pada sistem informasi prioritas utama. Unit keamanan ditunjuk sebagai pemilik proses ini. Tetapi untuk mendapatkan gambaran lengkap tentang hak akses di perusahaan, perlu melibatkan departemen TI dan bisnis dalam proses tersebut. Dan kemudian perselisihan, kesalahpahaman, dan kadang-kadang bahkan sabotase dimulai: tidak ada yang ingin melepaskan diri dari tugas mereka saat ini dan terlibat dalam beberapa, pada pandangan pertama, kegiatan yang tidak dapat dipahami.



NB - - – IT general controls (ITG), - , best practice (ITIL, COBIT, IT Governance .) , , , .







Salah satu bidang audit adalah untuk menentukan parameter akses logis dan fisik ke sistem informasi. Kami mengambil data yang diperoleh sebagai dasar untuk digunakan lebih lanjut dalam membangun model peran. Sebagai hasil dari audit tersebut, kami mendapat daftar sistem TI, di mana parameter teknisnya ditentukan dan deskripsi diberikan. Selain itu, untuk setiap sistem, pemilik dari lini bisnis diidentifikasi, yang kepentingannya dioperasikan: dialah yang bertanggung jawab atas proses bisnis yang dilayani sistem ini. Seorang manajer layanan TI juga ditunjuk, bertanggung jawab untuk implementasi teknis dari kebutuhan bisnis dalam SI tertentu. Sistem yang paling kritis untuk perusahaan dan parameter teknisnya, ketentuan commissioning dan decommissioning, dll. Dicatat.Parameter ini sangat membantu dalam mempersiapkan untuk membangun model peran.



Langkah 3 Buat metodologi



Kunci keberhasilan bisnis apa pun adalah metode yang tepat. Oleh karena itu, baik untuk membangun model peran dan untuk melakukan audit, kita perlu membuat metodologi di mana kita menggambarkan interaksi antara departemen, memperbaiki tanggung jawab dalam peraturan perusahaan, dll.

Pertama, Anda perlu memeriksa semua dokumen yang tersedia yang menetapkan prosedur untuk memberikan akses dan hak. Secara damai, proses harus didokumentasikan pada beberapa tingkatan:



  • persyaratan umum perusahaan;
  • persyaratan untuk bidang keamanan informasi (tergantung pada bidang kegiatan organisasi);
  • persyaratan untuk proses teknologi (instruksi, matriks akses, pedoman, persyaratan untuk konfigurasi).


Di perusahaan keuangan kami, kami menemukan banyak dokumen yang sudah ketinggalan zaman - kami harus membawanya sesuai dengan proses baru yang diperkenalkan.



Atas perintah manajemen, sebuah kelompok kerja telah dibentuk, yang mencakup perwakilan dari bidang keamanan, TI, bisnis dan pengendalian internal. Urutan menguraikan tujuan menciptakan kelompok, arah kegiatan, periode keberadaan dan orang-orang yang bertanggung jawab dari masing-masing pihak. Selain itu, kami telah mengembangkan metodologi untuk melakukan audit dan prosedur untuk membangun model peran: mereka telah disetujui oleh semua perwakilan yang bertanggung jawab di area tersebut dan disetujui oleh manajemen perusahaan.



Dokumen yang menjelaskan prosedur untuk melaksanakan pekerjaan, persyaratan, tanggung jawab, dll. - jaminan bahwa dalam perjalanan ke tujuan yang dihargai, yang pada awalnya tidak jelas bagi semua orang, tidak ada yang akan memiliki pertanyaan "mengapa kita melakukan ini, mengapa kita membutuhkannya, dll." dan tidak akan ada kesempatan untuk "melompat" atau memperlambat proses.







Langkah 4. Perbaiki parameter model kontrol akses yang ada



Kami menyusun apa yang disebut "paspor sistem" dalam hal kontrol akses. Bahkan, ini adalah kuesioner untuk sistem informasi tertentu, di mana semua algoritma untuk mengontrol akses ke sana direkam. Perusahaan yang telah menerapkan solusi IdM mungkin akrab dengan kuesioner seperti itu, karena dengan itu penelitian sistem dimulai.



Beberapa parameter tentang sistem dan pemilik mengalir ke kuesioner dari register TI (lihat langkah 2, audit), tetapi yang baru juga ditambahkan:



  • bagaimana akun dikelola (langsung dalam database atau melalui antarmuka perangkat lunak);
  • bagaimana pengguna masuk ke sistem (menggunakan akun terpisah atau menggunakan akun AD, LDAP, dll.);
  • apa tingkat akses ke sistem yang digunakan (tingkat aplikasi, tingkat sistem, penggunaan sistem sumber daya file jaringan);
  • , ;
  • (, ..);
  • ;
  • (, .);
  • ;
  • (, , ., );
  • ( , , .);
  • (SOD – Segregation of Duties), ;
  • , , , ..


Daftar berjalan dan terus, merinci berbagai parameter dan objek lain yang terlibat dalam proses kontrol akses.



Langkah 5. Buat deskripsi otorisasi yang berorientasi bisnis



Dokumen lain yang akan kita perlukan ketika membangun model peran adalah panduan untuk semua kekuatan yang mungkin (hak) yang dapat diberikan kepada pengguna dalam sistem informasi dengan deskripsi rinci tentang fungsi bisnis yang ada di belakangnya. Seringkali, otoritas dalam sistem dienkripsi dengan nama-nama tertentu yang terdiri dari huruf dan angka, dan karyawan bisnis tidak dapat mengetahui apa yang ada di balik simbol-simbol ini. Kemudian mereka pergi ke layanan TI, dan di sana ... mereka juga tidak dapat menjawab pertanyaan, misalnya, tentang hak yang jarang digunakan. Maka Anda harus melakukan pengujian tambahan.



Adalah baik jika deskripsi bisnis sudah ada atau bahkan ada kombinasi dari hak-hak ini ke dalam kelompok dan peran. Untuk beberapa aplikasi, praktik terbaik adalah membuat referensi seperti itu pada tahap desain. Tetapi ini jarang terjadi, jadi sekali lagi kami pergi ke departemen TI untuk mengumpulkan informasi tentang semua hak yang mungkin dan menjelaskannya. Panduan kami pada akhirnya akan berisi yang berikut:



  • nama otoritas, termasuk objek yang hak aksesnya berlaku;
  • tindakan yang diizinkan untuk dilakukan dengan objek (melihat, mengubah, dll., kemungkinan pembatasan, misalnya, dengan basis teritorial atau oleh sekelompok klien);
  • kode otorisasi (kode dan nama permintaan fungsi / sistem yang dapat dieksekusi menggunakan otorisasi);
  • deskripsi otoritas (deskripsi rinci tentang tindakan dalam IS ketika menerapkan otoritas dan konsekuensinya untuk proses;
  • : «» ( ) Β« Β» ( ).


6



Pada tahap akhir persiapan, Anda perlu mengunduh data dari sistem informasi tentang semua pengguna dan hak-hak yang mereka miliki saat ini. Dua skenario dimungkinkan di sini. Pertama, departemen keamanan memiliki akses langsung ke sistem dan memiliki cara mengunggah laporan yang relevan, yang jarang terjadi, tetapi sangat nyaman. Kedua: kami mengirim permintaan ke IT untuk menerima laporan dalam format yang diperlukan. Praktek menunjukkan bahwa tidak mungkin untuk bernegosiasi dengan IT dan mendapatkan data yang diperlukan pertama kali. Beberapa pendekatan harus diambil sampai informasi diterima dalam bentuk dan format yang diinginkan.



Data apa yang perlu diunduh:



  • Nama akun
  • Nama lengkap karyawan yang ditugaskan kepadanya
  • Status (aktif atau terkunci)
  • Tanggal pembuatan akun
  • Tanggal penggunaan terakhir
  • Daftar hak / kelompok / peran yang tersedia


Jadi, kami menerima pembongkaran dari sistem dengan semua pengguna dan dengan semua hak yang diberikan kepada mereka. Dan segera singkirkan semua akun yang diblokir, karena pekerjaan membangun model peran akan dilakukan hanya untuk pengguna aktif.



Kemudian, jika perusahaan Anda tidak memiliki cara otomatis untuk menutup akses ke karyawan yang diberhentikan (ini sering terjadi) atau ada otomatisasi tambal sulam yang tidak selalu bekerja dengan benar, Anda perlu mengidentifikasi semua "jiwa yang mati". Kita berbicara tentang akun karyawan yang sudah diberhentikan, yang haknya tidak diblokir karena alasan tertentu - mereka perlu diblokir. Untuk melakukan ini, kami membandingkan data yang diunduh dengan sumber personel. Bongkar muat personel juga harus terlebih dahulu diperoleh dari unit yang memimpin pangkalan personel.



Secara terpisah, perlu untuk menunda akun, pemilik yang tidak ditemukan di pangkalan personel, tidak ditugaskan kepada siapa pun - yaitu, tanpa pemilik. Menurut daftar ini, kita perlu tanggal penggunaan terakhir: jika cukup baru, maka kita masih harus mencari pemiliknya. Ini mungkin termasuk akun kontraktor eksternal atau akun layanan yang tidak ditugaskan kepada siapa pun, tetapi terkait dengan proses apa pun. Untuk mengetahui kepemilikan akun, Anda dapat mengirim surat ke semua departemen dengan permintaan untuk merespons. Ketika pemilik ditemukan, kami memasukkan data tentang mereka ke dalam sistem: dengan cara ini, semua akun yang ada diidentifikasi, dan sisanya diblokir.



Segera setelah unggahan kami dihapus dari catatan yang tidak perlu dan hanya ada akun aktif yang tersisa, Anda dapat mulai membangun panutan untuk sistem informasi tertentu. Tetapi saya akan membicarakan hal ini di artikel selanjutnya.



Penulis: Lyudmila Sevastyanova, Manajer Promosi, Tenaga Surya



All Articles