Terakhir kali, kami memeriksa pendekatan untuk membangun
model akses . Sekarang kita perlu memikirkan prosedur dan sarana teknis: bagaimana membangun proses yang akan membantu mengontrol akses, dan bagaimana ini dapat diimplementasikan.
Pertama-tama, Anda harus memikirkan tentang apa yang akan Anda bangun -
dari apa yang Anda miliki , atau
dari apa yang Anda inginkan . Hasilnya akan sangat tergantung pada titik awal. Setiap pendekatan memiliki pro dan kontra, dan perlu mempertimbangkan keduanya untuk memahami prospek dan kenyataan.
Mari kita pergi dari yang diinginkan.
Apa yang kita inginkan?- Sebuah sistem yang dengan sendirinya memberi tahu kita tentang pelanggaran dan konflik SOD?
- Sebuah sistem yang dengan sendirinya akan membangun panutan?
- Kelola akses?
- Apakah semuanya terkendali?
- Menyediakan akses fisik dan logis untuk pengguna dengan otentikasi biometrik, dll.?
Di sini Anda dapat memikirkan lebih banyak lagi, dan semua ini bahkan dapat direalisasikan. Tapi (!) Dengan probabilitas tinggi itu akan menjadi pengembangan individu, panjang dan mahal.
Apa yang kita miliki- Kebijakan akses
- proses menyediakan akses (atas permintaan pengguna atau tanpa itu),
- hak dan peran bawaan dalam setiap sistem.
Tidak sia-sia saya menulis di artikel terakhir tentang
model jatuh tempo . Menciptakan proses yang ideal dalam sekejap mata tidak akan berhasil, tetapi dengan pekerjaan yang terencana dengan baik, Anda dapat mencapai hasil yang diinginkan seperti dijelaskan di atas, jika itu diminati di perusahaan Anda.
Saat mendesain proses, perlu diingat:
sistem yang lebih sederhana dan lebih transparan, semakin mudah untuk mengendalikannya . Semakin berbeda kondisi dan cabang proses manusia, semakin banyak kesalahan akan terjadi.
Ambil proses menyediakan akses sebagai contoh, di mana pengguna membutuhkan hak baru dalam sistem untuk melakukan tugas.
Faktor -
faktor apa
yang harus dipertimbangkan ketika membuat proses bisnis seperti itu?
- kenyamanan bagi pengguna, koordinator dan pemain,
- waktu
- dihabiskan untuk masing-masing tahap proses,
- waktu proses kumulatif
- biaya implementasi setiap langkah,
- berdampak pada langkah selanjutnya
Pertama, kami akan menentukan
siapa yang terlibat dalam proses ini:
- pengguna sendiri - meminta hak akses,
- kepalanya - menyetujui permintaan, mengkonfirmasikan kebutuhan produksi,
- Petugas Keamanan Informasi - mengoordinasikan akses dengan memonitor konflik otoritas (tidak semua perusahaan memiliki ini, tetapi anggaplah ...),
- administrator sistem informasi - memenuhi aplikasi.
Mungkin ada lebih banyak peserta dalam proses, misalnya: pemilik sumber daya, pengontrol tambahan dari IT, dll. Sementara itu, untuk menganalisis konstruksi proses, karakter yang ditunjukkan sudah cukup untuk kita.
Sekarang mari kita putuskan bidang tindakan. Pada awalnya, bagi kami, prosesnya terlihat seperti ini:
Seorang karyawan meminta hak akses, kepala mereka setuju, kemudian seorang petugas IS setuju, setelah itu administrator sistem mengeksekusi permintaan tersebut.
Ini adalah proses linier sederhana, kelihatannya sederhana, tapi tetap mari kita cari tahu detailnya. Silakan ambil yang berikut sebagai contoh alasan ketika membangun suatu proses. Untuk perusahaan dan pengguna Anda, pentingnya faktor tertentu - kenyamanan, biaya waktu, kecepatan dan dampak pada langkah selanjutnya - dapat bervariasi.
Bagaimana seorang karyawan tahu akses apa yang dia butuhkan dan apa yang harus diminta? Kadang-kadang mungkin untuk menghubungi seseorang yang dapat memberi tahu Anda cara menempatkan aplikasi dengan benar - tanyakan kepada kepala, hubungi pemilik sumber daya atau administrator, tulis surat ke dukungan teknis. Terkadang formulir permintaan akses itu sendiri membantu, yang menawarkan opsi yang jelas untuk dipilih, atau ada bidang untuk menggambarkan situasi.
Semua opsi yang dijelaskan biasanya tersedia, tetapi butuh beberapa waktu. Jadi, Anda perlu memilih opsi tercepat dan paling ramah pengguna. (Kami berusaha keras untuk menyediakan layanan berkualitas untuk bisnis.) Anda dapat meninggalkan 1-2 opsi yang relevan, tetapi Anda bisa - itu saja. Pada tahap ini, penting untuk membandingkan opsi yang tersedia untuk
mengidentifikasi hak akses yang diperlukan sesuai dengan parameter yang dipilih sebelumnya.
Langkah selanjutnya adalah
antarmuka permintaan izin . Bagaimana cara pengguna meminta hak akses?
Di antara opsi yang muncul di pikiran: telepon, surat, EDMS (sistem manajemen dokumen elektronik), Service Desk, antarmuka IdM atau hanya aplikasi di atas kertas. Adalah penting bahwa metode aplikasi sederhana dan mudah bagi pengguna.
Sekali lagi, Anda perlu mempertimbangkan faktor waktu: mana yang lebih cepat - menulis surat atau menekan beberapa tombol di Service Desk? Harus diingat bahwa langkah selanjutnya adalah mengoordinasikan aplikasi, dan ini juga perlu dilakukan segera.
Setelah memilih antarmuka untuk meminta hak akses, pertimbangkan
antarmuka untuk negosiasi .
Opsi: di atas kertas (kami awalnya meletakkan opsi seperti itu), melalui surat, melalui EDMS atau Service Desk, antarmuka IdM.
Perlu mempertimbangkan kompleksitas rute koordinasi. Kami sekarang mempertimbangkan proses linear dengan 2 langkah pencocokan. Tetapi dalam kehidupan semuanya biasanya lebih rumit, dan bervariasi tergantung pada sistem mana akses apa yang diminta. Dengan demikian, semua parameter terkait dengan rute koordinasi juga harus diperhitungkan. Beberapa metode koordinasi dapat digabungkan, dan kasus-kasus seperti itu membutuhkan perhatian dan dukungan yang meningkat. Misalnya: kepala menyetujui aplikasi di atas kertas dengan membubuhkan tanda tangannya, dan petugas IS bekerja dengan pemindaian aplikasi di EDMS. Ini menambah kompleksitas dan ketidaknyamanan bagi pengguna dan negosiator. Karenanya, kami menganggap di sini satu antarmuka untuk semua koordinator.
Selanjutnya, pertimbangkan
opsi .
Dari opsi - manual atau otomatis.
Pada saat yang sama, eksekusi otomatis dalam beberapa kasus dapat dicapai tidak hanya melalui implementasi IdM, tetapi juga dilakukan, katakanlah, menggunakan skrip.
Keuntungan dari
eksekusi manual adalah seseorang yang dalam beberapa kasus sangat diperlukan, karena dapat menganalisis situasi dan, membuat penyesuaian, memberi pengguna hak yang diperlukan. Namun, ini membuat proses menjadi rentan: bagaimanapun, seseorang dapat membuat kesalahan atau lupa untuk mendokumentasikan apa yang telah dilakukan.
Eksekusi otomatis menyelamatkan dari kesalahan yang terkait dengan faktor manusia, tetapi memiliki keterbatasan. Dalam beberapa kasus (terutama jika kita berbicara tentang otomatisasi tidak sistematis dari sejumlah tindakan oleh skrip), administrator masih harus menetapkan beberapa parameter atau mengontrol eksekusi. Dalam hal ini, IdM dapat beroperasi dengan parameter yang ditetapkan selama desain proses selama implementasi sistem, dan atribut aplikasi (jika kita menggunakan IdM sebagai sistem aplikasi untuk masalah akses).
Kami telah melakukan beberapa pekerjaan dengan masing-masing elemen proses secara terpisah, sekarang perlu untuk mengevaluasi apa yang kami dapatkan jika kami menggabungkan langkah-langkah yang dipilih seperti mengumpulkan puzzle.
Pertama, mari kita lihat apa saja opsi untuk proses ini:
Jumlah koneksi cukup. Penting untuk memilih kombinasi di mana yang paling sedikit adalah waktu dan biaya, dan yang terbesar adalah kenyamanan pengguna (termasuk negosiator dan pemain). Harus diingat bahwa “biaya” transisi dari langkah ke langkah tergantung pada fitur dari langkah yang dipilih.
Sebagai contoh, perhatikan tiga proses.
Proses 1.Misalkan kita membangun proses sebagai berikut:
Dengan konfigurasi ini, pengguna yang terbiasa berkomunikasi melalui surat akan mengetahui prosedur dan format aplikasi yang benar untuk hak akses yang diperlukan. Sebagai hasilnya, mereka akan dapat memilih bagaimana lebih mudah bagi mereka untuk membentuk aplikasi - di atas kertas atau melalui email. Aplikasi akan dikoordinasikan melalui surat, dan administrator akan menjalankan permintaan secara manual.
Proses ini memiliki hak untuk hidup, jika tidak ada cara lain yang lebih modern. Namun: berapa banyak waktu yang dibutuhkan oleh seluruh rangkaian tindakan, dan bagaimana membayangkan peningkatan tanpa adanya reaksi yang terkoordinasi?
Proses 2.Mari kita pilih konfigurasi lain:
Di sini kita melihat bahwa karyawan, untuk mengkompilasi permintaan yang benar, memanggil pemilik sumber daya, dan kemudian membentuk permintaan di EDS atau Service Desk. Di sana, aplikasi akan disetujui. Eksekusi akan tergantung pada apa yang diminta - secara manual oleh administrator atau skrip.
Di EDMS dan Service Desk, sebagai aturan, Anda dapat mengonfigurasi eskalasi jika terjadi pengambilan keputusan yang panjang oleh koordinator, atau jika tidak ada koordinator karena satu dan lain alasan.
Prosesnya terlihat lebih nyaman dan lebih cepat daripada yang pertama kami ulas. Namun demikian, muncul pertanyaan: apakah lamaran diformalkan?
Jika pengguna menulis "
Saya ingin akses ke sistem seperti Ivanov, " maka eksekusi hanya dapat dilakukan secara manual.
Jika aplikasi diformalkan (mis. Ada sejumlah opsi tertentu untuk dipilih), kita dapat berbicara tentang opsi otomatisasi. Pada saat yang sama, Anda perlu melihat kembali bagaimana otomatisasi akan dilaksanakan - oleh siapa, dengan kualitas apa dan bagaimana itu akan didukung.
Proses 3.Pertimbangkan opsi IdM:
Dalam hal ini, pengguna dapat mengetahui jenis akses apa yang ia butuhkan dari manajer atau hanya dengan melihat pada formulir permintaan (dalam katalog peran IdM, untuk kenyamanan pengguna, Anda dapat menampilkan peran atau peran bisnis dengan deskripsi yang jelas).
Permintaan untuk hak dan peran berlangsung di IdM, serta persetujuan aplikasi.
Hak akan diberikan oleh IdM secara otomatis setelah menyelesaikan prosedur persetujuan untuk sistem yang terhubung untuk manajemen melalui IdM. Karena tidak semua sistem perlu dihubungkan untuk kontrol (dapat dihubungkan untuk kontrol dalam mode akuisisi data), kontraktor akan menerima tugas yang jelas untuk dieksekusi. Dalam hal ini, dalam hal terjadi kesalahan administrator, sistem akan mendeteksi perbedaan antara aplikasi dan akses yang diberikan dan menginformasikan pihak yang berkepentingan (misalnya, petugas IS dan administrator sistem).
Untuk setiap proses,
biaya dukungan juga dapat diasumsikan.
Pada saat yang sama, jangan lupa bahwa, selain membangun proses pemberian hak akses, yang telah kami pilih untuk kemudahan pertimbangan, proses juga diperlukan untuk operasi yang optimal:
- revisi hak akses untuk pemindahan pegawai (kenaikan, perpindahan linier, pemindahan dari satu perusahaan induk ke perusahaan lain),
- revisi hak akses sesuai dengan jadwal (seperti yang dipersyaratkan oleh perusahaan Anda - triwulanan, tahunan),
- pencabutan hak-hak atas pemecatan karyawan dan pemblokiran akun,
- mengaudit dll.
Oleh karena itu, dalam proses pengambilan keputusan, Anda harus kembali
"mengambil langkah mundur " untuk
melihat keseluruhan sistem proses kontrol akses .
Dengan pendekatan ini, Anda dapat mengevaluasi penggunaan setiap solusi organisasi dan teknis:
- bagaimana hal itu mempengaruhi proses bisnis perusahaan,
- apakah nyaman bagi pengguna
- apakah downtime karyawan akan meningkat karena tidak ada akses tepat waktu,
- akan memberikan efek sederhana pada laba perusahaan
- apakah akan ada tabrakan sebagai hasil dari serangkaian proses,
- bisakah kita mengaudit hak akses
- Apakah kita memiliki cukup informasi yang terdokumentasi untuk digunakan dalam situasi kontroversial atau ketika menyelidiki suatu kejadian,
- apakah kami dapat meninjau hak akses karyawan, dll.
Setelah menghargai mosaik yang muncul dari proses kontrol akses, orang dapat lebih aman memilih tindakan organisasi dan solusi teknis.
Artikel lain dalam seri: