Saat ini saya bekerja untuk vendor perangkat lunak, khususnya solusi kontrol akses. Dan pengalaman saya “dari kehidupan lampau” terhubung dengan sisi pelanggan - sebuah organisasi keuangan besar. Pada saat itu, grup kontrol akses kami di departemen keamanan informasi tidak dapat membanggakan kompetensi yang hebat dalam IdM. Kami belajar banyak dalam prosesnya, kami harus melewati banyak rintangan untuk membangun mekanisme kerja pengelolaan hak pengguna dalam sistem informasi di perusahaan.
Menggabungkan pengalaman pelanggan yang saya peroleh dengan susah payah dengan pengetahuan dan kompetensi vendor, saya ingin berbagi dengan Anda petunjuk langkah demi langkah yang penting: cara membuat model kontrol akses berbasis peran di perusahaan besar, dan apa hasilnya. . Instruksi saya terdiri dari dua bagian: bagian pertama bersiap membuat model, bagian kedua benar-benar membangun. Inilah bagian pertama, bagian persiapan.
NB Sayangnya, membangun teladan bukanlah sebuah hasil, melainkan sebuah proses. Atau lebih tepatnya, bagian dari proses menciptakan ekosistem kontrol akses di perusahaan. Jadi bersiaplah untuk permainan untuk waktu yang lama.
Pertama, mari kita definisikan - apa itu kontrol akses berbasis peran? Misalkan Anda memiliki bank besar dengan puluhan, atau bahkan ratusan ribu karyawan (entitas), yang masing-masing memiliki puluhan hak akses ke ratusan sistem (objek) informasi internal bank. Sekarang kalikan jumlah objek dengan jumlah subjek - ini adalah jumlah minimum koneksi yang perlu Anda bangun terlebih dahulu dan kemudian kendalikan. Apakah mungkin melakukan ini secara manual? Tentu saja tidak - peran diciptakan untuk mengatasi masalah ini.
Peran adalah sekumpulan izin yang diperlukan pengguna atau sekelompok pengguna untuk melakukan tugas kerja tertentu. Setiap karyawan dapat memiliki satu atau lebih peran, dan setiap peran dapat berisi satu hingga banyak izin yang diperbolehkan bagi pengguna dalam peran tersebut. Peran dapat dikaitkan dengan posisi, departemen, atau tugas fungsional tertentu dari karyawan.
Peran biasanya dibuat dari otorisasi individu karyawan di setiap sistem informasi. Kemudian peran bisnis global terbentuk dari peran masing-masing sistem. Misalnya, peran bisnis "manajer kredit" akan mencakup beberapa peran terpisah dalam sistem informasi yang digunakan di kantor nasabah bank. Misalnya seperti sistem perbankan otomatis utama, modul kas, sistem pengelolaan dokumen elektronik, manajer layanan dan lain-lain. Peran bisnis, pada umumnya, terikat pada struktur organisasi - dengan kata lain, pada kumpulan divisi dan posisi perusahaan di dalamnya. Beginilah cara matriks peran global terbentuk (saya berikan contohnya pada tabel di bawah).
Perlu dicatat bahwa tidak mungkin membangun panutan 100% yang memberikan semua hak yang diperlukan bagi karyawan di setiap posisi dalam struktur komersial. Ya, ini tidak perlu. Bagaimanapun, seorang panutan tidak bisa statis, karena bergantung pada lingkungan yang terus berubah. Dan dari perubahan kegiatan usaha perusahaan, yang selanjutnya mempengaruhi perubahan struktur dan fungsi organisasi. Dan dari kurangnya penyediaan sumber daya secara penuh, dan dari ketidakpatuhan terhadap uraian tugas, dan dari keinginan untuk mendapatkan keuntungan dengan mengorbankan keselamatan, dan dari banyak faktor lainnya. Oleh karena itu, perlu dibangun suatu role model yang dapat mencakup hingga 80% kebutuhan pengguna akan hak-hak dasar yang diperlukan ketika ditugaskan pada suatu jabatan. Dan mereka dapat, jika perlu, meminta sisa 20% nanti pada aplikasi terpisah.
Tentu saja Anda mungkin bertanya: “Apakah tidak ada teladan yang 100%?” Mengapa, hal ini terjadi, misalnya, dalam struktur nirlaba yang tidak sering mengalami perubahan - di beberapa lembaga penelitian. Atau dalam organisasi kompleks industri militer dengan tingkat keamanan tinggi, yang mengutamakan keselamatan. Ini terjadi dalam struktur komersial, tetapi dalam kerangka divisi terpisah, yang pekerjaannya merupakan proses yang cukup statis dan dapat diprediksi.
Keuntungan utama dari manajemen berbasis peran adalah penyederhanaan penerbitan hak, karena jumlah peran jauh lebih sedikit dibandingkan jumlah pengguna sistem informasi. Dan ini berlaku untuk industri apa pun.
Mari kita ambil contoh sebuah perusahaan ritel: ia mempekerjakan ribuan tenaga penjualan, namun mereka memiliki hak yang sama dalam sistem N, dan hanya satu peran yang akan dibuat untuk mereka. Ketika seorang tenaga penjualan baru datang ke perusahaan, dia secara otomatis diberi peran yang diperlukan dalam sistem, yang sudah memiliki semua otoritas yang diperlukan. Selain itu, dalam satu klik Anda dapat mengubah hak ribuan penjual sekaligus, misalnya, menambahkan opsi baru untuk membuat laporan. Tidak perlu melakukan ribuan operasi, menautkan hak baru ke setiap akun - cukup tambahkan opsi ini ke peran tersebut, dan itu akan muncul untuk semua penjual secara bersamaan.
Keuntungan lain dari manajemen berbasis peran adalah penghapusan penerbitan otorisasi yang tidak sesuai. Artinya, seorang pegawai yang mempunyai peran tertentu dalam sistem tidak dapat sekaligus mempunyai peran lain yang haknya tidak boleh digabungkan dengan hak yang ada pada yang pertama. Contoh yang mencolok adalah larangan menggabungkan fungsi input dan kontrol transaksi keuangan.
Siapa pun yang tertarik dengan bagaimana kontrol akses berbasis peran bisa jadi
menyelami sejarah
Jika kita melihat sejarah, komunitas TI pertama kali memikirkan metode kontrol akses pada tahun 70-an abad ke-XNUMX. Meskipun saat itu aplikasi masih cukup sederhana, seperti sekarang, semua orang benar-benar ingin mengelola akses ke aplikasi tersebut dengan mudah. Memberikan, mengubah, dan mengontrol hak pengguna - hanya untuk memudahkan memahami akses yang dimiliki masing-masing pengguna. Namun pada saat itu belum ada standar umum, sistem kontrol akses pertama sedang dikembangkan, dan setiap perusahaan didasarkan pada ide dan aturannya sendiri.
Banyak model kontrol akses berbeda yang kini dikenal, namun tidak serta merta muncul. Mari kita memikirkan mereka yang telah memberikan kontribusi signifikan terhadap pembangunan kawasan ini.
Model pertama dan mungkin paling sederhana adalah Kontrol akses diskresi (selektif). (DAC – Kontrol akses diskresi). Model ini menyiratkan pembagian hak oleh semua peserta dalam proses akses. Setiap pengguna memiliki akses ke objek atau operasi tertentu. Intinya, di sini himpunan subjek hak bersesuaian dengan himpunan objek. Model ini ditemukan terlalu fleksibel dan terlalu sulit untuk dipelihara: daftar akses pada akhirnya menjadi sangat besar dan sulit untuk dikendalikan.
Model kedua adalah Kontrol akses wajib (MAC - Kontrol akses wajib). Menurut model ini, setiap pengguna menerima akses terhadap suatu objek sesuai dengan akses yang diberikan pada tingkat kerahasiaan data tertentu. Oleh karena itu, objek harus dikategorikan menurut tingkat kerahasiaannya. Berbeda dengan model fleksibel pertama, model ini justru ternyata terlalu ketat dan membatasi. Penggunaannya tidak dibenarkan bila perusahaan memiliki banyak sumber informasi yang berbeda: untuk membedakan akses ke sumber daya yang berbeda, Anda harus memperkenalkan banyak kategori yang tidak akan tumpang tindih.
Karena ketidaksempurnaan yang jelas dari kedua metode ini, komunitas TI terus mengembangkan model yang lebih fleksibel dan pada saat yang sama lebih atau kurang universal untuk mendukung berbagai jenis kebijakan kontrol akses organisasi. Dan kemudian hal itu muncul model kontrol akses berbasis peran ketiga! Pendekatan ini terbukti paling menjanjikan karena tidak hanya memerlukan otorisasi identitas pengguna, namun juga fungsi operasionalnya dalam sistem.
Struktur panutan pertama yang dijelaskan dengan jelas diusulkan oleh ilmuwan Amerika David Ferrailo dan Richard Kuhn dari Institut Standar dan Teknologi Nasional AS pada tahun 1992. Kemudian istilah tersebut pertama kali muncul RBAC (Kontrol akses berbasis peran). Studi dan deskripsi komponen utama, serta hubungannya, menjadi dasar standar INCITS 359-2012, yang masih berlaku hingga saat ini, disetujui oleh Komite Internasional Standar Teknologi Informasi (INCITS).
Standar ini mendefinisikan peran sebagai "fungsi pekerjaan dalam konteks organisasi dengan beberapa semantik terkait mengenai wewenang dan tanggung jawab yang diberikan kepada pengguna yang ditugaskan pada peran tersebut." Dokumen tersebut menetapkan elemen dasar RBAC - pengguna, sesi, peran, izin, operasi dan objek, serta hubungan dan interkoneksi di antara mereka.
Standar ini memberikan struktur minimum yang diperlukan untuk membangun model peran - menggabungkan hak ke dalam peran dan kemudian memberikan akses kepada pengguna melalui peran tersebut. Mekanisme untuk menyusun peran dari objek dan operasi diuraikan, hierarki peran dan pewarisan kekuasaan dijelaskan. Memang, di perusahaan mana pun ada peran yang menggabungkan kekuatan dasar yang diperlukan bagi seluruh karyawan perusahaan. Ini bisa berupa akses ke email, EDMS, portal perusahaan, dll. Izin-izin ini dapat dimasukkan dalam satu peran umum yang disebut “karyawan”, dan tidak perlu lagi mencantumkan semua hak dasar di setiap peran tingkat yang lebih tinggi. Cukup dengan menunjukkan karakteristik warisan dari peran “karyawan”.
Kemudian, standar tersebut dilengkapi dengan atribut akses baru yang terkait dengan lingkungan yang terus berubah. Kemampuan untuk memperkenalkan pembatasan statis dan dinamis telah ditambahkan. Yang statis menyiratkan ketidakmungkinan menggabungkan peran (input dan kontrol operasi yang sama disebutkan di atas). Pembatasan dinamis dapat ditentukan dengan mengubah parameter, misalnya waktu (jam atau hari kerja/tidak bekerja), lokasi (kantor/rumah), dll.
Secara terpisah, harus dikatakan tentang kontrol akses berbasis atribut (ABAC - Kontrol akses berbasis atribut). Pendekatan ini didasarkan pada pemberian akses menggunakan aturan berbagi atribut. Model ini dapat digunakan secara terpisah, namun seringkali model ini secara aktif melengkapi model peran klasik: atribut pengguna, sumber daya dan perangkat, serta waktu atau lokasi, dapat ditambahkan ke peran tertentu. Hal ini memungkinkan Anda untuk menggunakan peran yang lebih sedikit, menerapkan batasan tambahan dan membuat akses seminimal mungkin, sehingga meningkatkan keamanan.
Misalnya, seorang akuntan dapat diberikan akses ke akun jika dia bekerja di wilayah tertentu. Kemudian lokasi spesialis tersebut akan dibandingkan dengan nilai acuan tertentu. Atau Anda dapat memberikan akses ke akun hanya jika pengguna masuk dari perangkat yang termasuk dalam daftar perangkat yang diizinkan. Tambahan yang bagus untuk panutan, namun jarang digunakan sendiri karena kebutuhan untuk membuat banyak aturan dan tabel izin atau batasan.
Izinkan saya memberi Anda contoh penggunaan ABAC dari “kehidupan masa lalu” saya. Bank kami memiliki beberapa cabang. Karyawan kantor klien di cabang-cabang ini melakukan operasi yang persis sama, namun harus bekerja di sistem utama hanya dengan akun di wilayah mereka. Pertama, kami mulai membuat peran terpisah untuk setiap wilayah - dan ada begitu banyak peran dengan fungsi berulang, tetapi dengan akses ke akun berbeda! Kemudian, dengan menggunakan atribut lokasi untuk pengguna dan mengaitkannya dengan rentang akun tertentu untuk ditinjau, kami mengurangi jumlah peran dalam sistem secara signifikan. Akibatnya, peran yang tersisa hanya untuk satu cabang, yang direplikasi untuk posisi terkait di semua divisi teritorial bank lainnya.
Sekarang mari kita bicara tentang langkah-langkah persiapan yang diperlukan, yang tanpanya mustahil membangun panutan yang berfungsi.
Langkah 1. Buat model fungsional
Anda harus mulai dengan membuat model fungsional - dokumen tingkat atas yang menjelaskan secara rinci fungsi setiap departemen dan setiap posisi. Biasanya, informasi masuk dari berbagai dokumen: uraian tugas dan peraturan untuk masing-masing unit - departemen, divisi, departemen. Model fungsional harus disetujui oleh semua departemen yang berkepentingan (bisnis, pengendalian internal, keamanan) dan disetujui oleh manajemen perusahaan. Untuk apa dokumen ini? Agar para role model bisa merujuknya. Misalnya, Anda akan membangun panutan berdasarkan hak-hak karyawan yang ada - dikeluarkan dari sistem dan “direduksi menjadi penyebut yang sama”. Kemudian, ketika menyepakati peran yang diterima dengan pemilik bisnis sistem, Anda dapat merujuk pada poin tertentu dalam model fungsional, yang menjadi dasar hak ini atau itu dimasukkan dalam peran tersebut.
Langkah 2. Kami mengaudit sistem TI dan menyusun rencana prioritas
Pada tahap kedua, Anda harus melakukan audit terhadap sistem TI untuk memahami bagaimana akses ke sistem tersebut diatur. Misalnya, perusahaan keuangan saya mengoperasikan beberapa ratus sistem informasi. Semua sistem memiliki beberapa dasar manajemen berbasis peran, sebagian besar memiliki beberapa peran, tetapi sebagian besar di atas kertas atau di direktori sistem - peran tersebut sudah lama ketinggalan zaman, dan akses ke peran tersebut diberikan berdasarkan permintaan pengguna yang sebenarnya. Tentu saja, tidak mungkin membangun panutan di beberapa ratus sistem sekaligus; Anda harus memulainya dari suatu tempat. Kami melakukan analisis mendalam terhadap proses kontrol akses untuk menentukan tingkat kematangannya. Selama proses analisis, kriteria untuk memprioritaskan sistem informasi dikembangkan - kekritisan, kesiapan, rencana dekomisioning, dll. Dengan bantuan mereka, kami menyusun pengembangan/pembaruan model peran untuk sistem ini. Lalu kami menyertakan panutan dalam rencana integrasi dengan solusi Manajemen Identitas untuk mengotomatiskan kontrol akses.
Jadi bagaimana Anda menentukan kekritisan suatu sistem? Jawab sendiri pertanyaan-pertanyaan berikut:
- Apakah sistem tersebut terkait dengan proses operasional yang menjadi sandaran aktivitas inti perusahaan?
- Apakah gangguan sistem akan mempengaruhi integritas aset perusahaan?
- Berapa waktu henti maksimum yang diperbolehkan pada sistem, yang mencapai titik dimana tidak mungkin memulihkan aktivitas setelah gangguan?
- Dapatkah pelanggaran integritas informasi dalam sistem menimbulkan konsekuensi yang tidak dapat diubah, baik finansial maupun reputasi?
- Kekritisan terhadap penipuan. Kehadiran fungsionalitas, jika tidak dikontrol dengan baik, dapat menyebabkan tindakan penipuan internal/eksternal;
- Apa saja persyaratan hukum serta aturan dan prosedur internal untuk sistem ini? Apakah akan ada denda dari regulator jika tidak patuh?
Di perusahaan keuangan kami, kami melakukan audit seperti ini. Manajemen mengembangkan prosedur audit Tinjauan Hak Akses untuk melihat pengguna dan hak yang ada terlebih dahulu dalam sistem informasi yang berada dalam daftar prioritas tertinggi. Departemen keamanan ditugaskan sebagai pemilik proses ini. Namun untuk mendapatkan gambaran lengkap tentang hak akses di perusahaan, perlu melibatkan departemen IT dan bisnis dalam prosesnya. Dan di sini perselisihan, kesalahpahaman, dan kadang-kadang bahkan sabotase dimulai: tidak ada yang mau melepaskan diri dari tanggung jawab mereka saat ini dan terlibat dalam beberapa kegiatan yang, pada pandangan pertama, tidak dapat dipahami.
NB Perusahaan besar dengan proses TI yang maju mungkin sudah familiar dengan prosedur audit TI - Pengendalian umum TI (ITGC), yang memungkinkan Anda mengidentifikasi kekurangan dalam proses TI dan menetapkan kontrol untuk meningkatkan proses sesuai dengan praktik terbaik (ITIL, COBIT, IT Tata Kelola, dll.) Audit semacam itu memungkinkan TI dan bisnis untuk lebih memahami satu sama lain dan mengembangkan strategi pengembangan bersama, menganalisis risiko, mengoptimalkan biaya, dan mengembangkan pendekatan kerja yang lebih efektif.
Salah satu bidang audit adalah menentukan parameter akses logis dan fisik ke sistem informasi. Kami mengambil data yang diperoleh sebagai dasar untuk digunakan lebih lanjut dalam membangun teladan. Sebagai hasil dari audit ini, kami memiliki daftar sistem TI, yang parameter teknisnya ditentukan dan dijelaskan. Selain itu, untuk setiap sistem, seorang pemilik diidentifikasi dari arah bisnis yang kepentingannya dioperasikan: dialah yang bertanggung jawab atas proses bisnis yang dilayani oleh sistem ini. Seorang manajer layanan TI juga ditunjuk, bertanggung jawab atas implementasi teknis kebutuhan bisnis untuk IS tertentu. Sistem yang paling penting bagi perusahaan dan parameter teknisnya, persyaratan commissioning dan dekomisioning, dll dicatat.Parameter ini sangat membantu dalam proses persiapan pembuatan role model.
Langkah 3 Buat metodologi
Kunci keberhasilan bisnis apa pun adalah metode yang tepat. Oleh karena itu, baik untuk membangun teladan maupun untuk melakukan audit, kita perlu membuat metodologi yang menggambarkan interaksi antar departemen, menetapkan tanggung jawab dalam peraturan perusahaan, dll.
Pertama, Anda perlu mempelajari semua dokumen yang tersedia yang menetapkan prosedur pemberian akses dan hak. Dengan cara yang baik, 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 konfigurasi).
Di perusahaan keuangan kami, kami menemukan banyak dokumen usang, kami harus menyesuaikannya dengan proses baru yang sedang diterapkan.
Atas perintah manajemen, kelompok kerja dibentuk, yang mencakup perwakilan dari keamanan, TI, bisnis, dan pengendalian internal. Tatanan tersebut menguraikan tujuan pembentukan kelompok, arah kegiatan, jangka waktu keberadaannya dan penanggung jawab dari masing-masing pihak. Selain itu, kami mengembangkan metodologi audit dan prosedur untuk membangun teladan: metodologi tersebut disepakati oleh seluruh perwakilan yang bertanggung jawab di area tersebut dan disetujui oleh manajemen perusahaan.
Dokumen yang menjelaskan prosedur pelaksanaan pekerjaan, tenggat waktu, tanggung jawab, dll. - jaminan bahwa dalam perjalanan menuju tujuan yang disayangi, yang pada awalnya tidak jelas bagi semua orang, tidak ada yang akan bertanya-tanya “mengapa kita melakukan ini, mengapa kita membutuhkannya, dll.” dan tidak akan ada peluang untuk “melompat” atau memperlambat proses.
Langkah 4. Perbaiki parameter model kontrol akses yang ada
Kami sedang menyusun apa yang disebut “paspor sistem” dalam hal kontrol akses. Intinya, ini adalah kuesioner tentang sistem informasi tertentu, yang mencatat semua algoritma untuk mengendalikan akses ke sistem tersebut. Perusahaan yang telah menerapkan solusi kelas IdM mungkin sudah familiar dengan kuesioner semacam itu, karena di sinilah studi tentang sistem dimulai.
Beberapa parameter tentang sistem dan pemilik dialirkan ke dalam kuesioner dari registri TI (lihat langkah 2, audit), namun parameter baru juga ditambahkan:
- bagaimana akun dikelola (langsung di database atau melalui antarmuka perangkat lunak);
- bagaimana pengguna masuk ke sistem (menggunakan akun terpisah atau menggunakan akun AD, LDAP, dll.);
- tingkat akses ke sistem apa yang digunakan (tingkat aplikasi, tingkat sistem, penggunaan sumber daya file jaringan oleh sistem);
- deskripsi dan parameter server tempat sistem berjalan;
- operasi manajemen akun apa yang didukung (pemblokiran, penggantian nama, dll.);
- algoritma atau aturan apa yang digunakan untuk menghasilkan pengenal pengguna sistem;
- atribut apa yang dapat digunakan untuk menjalin hubungan dengan catatan karyawan dalam sistem personalia (nama lengkap, nomor personel, dll.);
- semua kemungkinan atribut akun dan aturan pengisiannya;
- hak akses apa yang ada dalam sistem (peran, kelompok, hak atom, dll., apakah ada hak bertingkat atau hierarki);
- mekanisme pembagian hak akses (berdasarkan posisi, departemen, fungsi, dll);
- Apakah sistem mempunyai aturan untuk pemisahan hak (SOD – Segregation of Duties), dan bagaimana cara kerjanya;
- bagaimana peristiwa ketidakhadiran, mutasi, pemberhentian, pemutakhiran data pegawai, dan lain-lain diproses dalam sistem.
Daftar ini dapat dilanjutkan dengan rincian tentang berbagai parameter dan objek lain yang terlibat dalam proses kontrol akses.
Langkah 5. Buat deskripsi izin yang berorientasi bisnis
Dokumen lain yang kita perlukan ketika membangun role model adalah buku referensi tentang semua kemungkinan kewenangan (hak) yang dapat diberikan kepada pengguna sistem informasi dengan penjelasan rinci tentang fungsi bisnis yang berdiri di belakangnya. Seringkali, otoritas dalam sistem dienkripsi dengan nama tertentu yang terdiri dari huruf dan angka, dan karyawan bisnis tidak dapat mengetahui apa yang ada di balik simbol-simbol tersebut. Lalu mereka pergi ke layanan IT, dan disana... mereka juga tidak bisa menjawab pertanyaan, misalnya tentang hak yang jarang digunakan. Kemudian pengujian tambahan harus dilakukan.
Ada baiknya jika sudah ada gambaran bisnisnya atau bahkan ada penggabungan hak-hak tersebut ke dalam kelompok dan peran. Untuk beberapa aplikasi, praktik terbaiknya adalah membuat referensi tersebut pada tahap pengembangan. Namun hal ini jarang terjadi, jadi kami kembali pergi ke departemen TI untuk mengumpulkan informasi tentang semua kemungkinan hak dan menjelaskannya. Panduan kami pada akhirnya akan berisi hal-hal berikut:
- nama instansi, termasuk objek yang diberi hak akses;
- suatu tindakan yang diperbolehkan untuk dilakukan terhadap suatu objek (melihat, mengubah, dll., kemungkinan pembatasan, misalnya berdasarkan wilayah atau kelompok klien);
- kode otorisasi (kode dan nama fungsi/permintaan sistem yang dapat dijalankan menggunakan otorisasi);
- deskripsi otoritas (deskripsi rinci tindakan dalam IS ketika menerapkan otoritas dan konsekuensinya terhadap proses tersebut;
- status izin: “Aktif” (jika izin diberikan kepada setidaknya satu pengguna) atau “Tidak aktif” (jika izin tidak digunakan).
Langkah 6 Kami mengunduh data tentang pengguna dan hak dari sistem dan membandingkannya dengan sumber personel
Pada tahap akhir persiapan, Anda perlu mengunduh data dari sistem informasi tentang semua pengguna dan hak yang mereka miliki saat ini. Ada dua kemungkinan skenario di sini. Pertama: departemen keamanan memiliki akses langsung ke sistem dan memiliki sarana untuk mengunduh laporan yang relevan, hal ini tidak sering terjadi, namun sangat memudahkan. Kedua: kami mengirimkan permintaan ke IT untuk menerima laporan dalam format yang diperlukan. Pengalaman menunjukkan bahwa tidak mungkin mencapai kesepakatan dengan TI dan memperoleh data yang diperlukan untuk pertama kalinya. Perlu dilakukan beberapa pendekatan hingga informasi diterima dalam bentuk dan format yang diinginkan.
Data apa saja yang perlu diunduh:
- Nama akun
- Nama lengkap karyawan yang ditugaskan
- Status (aktif atau diblokir)
- Tanggal pembuatan akun
- Tanggal penggunaan terakhir
- Daftar hak/grup/peran yang tersedia
Jadi, kami menerima unduhan dari sistem dengan semua pengguna dan semua hak yang diberikan kepada mereka. Dan mereka segera mengesampingkan semua akun yang diblokir, karena upaya membangun panutan hanya akan dilakukan untuk pengguna aktif.
Kemudian, jika perusahaan Anda tidak memiliki cara otomatis untuk memblokir akses terhadap karyawan yang dipecat (hal ini sering terjadi) atau memiliki otomatisasi tambal sulam yang tidak selalu berfungsi dengan benar, Anda perlu mengidentifikasi semua “jiwa yang mati.” Kita berbicara tentang akun karyawan yang telah dipecat, yang haknya tidak diblokir karena alasan tertentu - mereka perlu diblokir. Untuk melakukan ini, kami membandingkan data yang diunggah dengan sumber personel. Pembongkaran personel juga harus diperoleh terlebih dahulu dari departemen yang memelihara database personel.
Secara terpisah, perlu untuk menyisihkan akun yang pemiliknya tidak ditemukan dalam database personalia, tidak ditugaskan kepada siapa pun - yaitu, tanpa pemilik. Dengan menggunakan daftar ini, kita memerlukan tanggal penggunaan terakhir: jika cukup baru, kita masih harus mencari pemiliknya. Ini mungkin termasuk akun kontraktor eksternal atau akun layanan yang tidak ditugaskan kepada siapa pun, namun terkait dengan proses apa pun. Untuk mengetahui pemilik akun tersebut, Anda dapat mengirimkan surat ke seluruh departemen untuk meminta tanggapan. Ketika pemiliknya ditemukan, kami memasukkan data tentang mereka ke dalam sistem: dengan cara ini, semua akun aktif diidentifikasi, dan sisanya diblokir.
Segera setelah unggahan kami dibersihkan dari catatan yang tidak perlu dan hanya akun aktif yang tersisa, kami dapat mulai membangun model peran untuk sistem informasi tertentu. Namun hal ini akan saya ceritakan pada artikel selanjutnya.
Penulis: Lyudmila Sevastyanova, manajer promosi Solar inRights
Sumber: www.habr.com