Имплементација на IdM. Подготовка за имплементација од страна на клиентот

Во претходните написи, веќе разгледавме што е IdM, како да разбереме дали на вашата организација и треба таков систем, кои проблеми ги решава и како да го оправдате буџетот за имплементација на раководството. Денеска ќе зборуваме за важните фази низ кои самата организација мора да помине за да го постигне соодветното ниво на зрелост пред да имплементира IdM систем. На крајот на краиштата, IdM е дизајниран да ги автоматизира процесите, но невозможно е да се автоматизира хаосот.

Сè додека компанијата не порасне до големината на големо претпријатие и не акумулира многу различни деловни системи, таа обично не размислува за контрола на пристапот. Затоа, процесите на добивање права и контролни овластувања во него не се структурирани и тешко се анализираат. Вработените пополнуваат апликации за пристап како што сакаат; процесот на одобрување исто така не е формализиран, а понекогаш едноставно не постои. Невозможно е брзо да се открие каков пристап има вработен, кој го одобрил и на која основа.

Имајќи предвид дека процесот на автоматизирање на пристапот влијае на два главни аспекти - податоците за персоналот и податоците од информациските системи со кои треба да се изврши интеграција, ќе ги разгледаме неопходните чекори за да се осигураме дека имплементацијата на IdM оди непречено и не предизвикува отфрлање:

1. Анализа на кадровските процеси и оптимизација на поддршката на базата на податоци на вработените во системите за персонал.
2. Анализа на податоците за корисниците и правата, како и ажурирање на методите за контрола на пристап во целните системи кои се планираат да се поврзат со IdM.
3. Организациски активности и вклученост на персоналот во процесот на подготовка за имплементација на IdM.

Податоци за персоналот

Може да има еден извор на податоци за персоналот во една организација, или може да има неколку. На пример, една организација може да има прилично широка мрежа на филијали и секоја филијала може да користи сопствена база на персонал.

Пред сè, неопходно е да се разберат кои основни податоци за вработените се зачувани во системот за евиденција на персоналот, кои настани се снимаат и да се оцени нивната комплетност и структура.

Често се случува да не се забележат сите кадровски настани во кадровскиот извор (а уште почесто се забележуваат ненавремено и не сосема правилно). Еве неколку типични примери:

• Листовите, нивните категории и термини (редовни или долгорочни) не се евидентираат;
• Вработувањето со скратено работно време не е евидентирано: на пример, додека е на долгорочен одмор за да се грижи за дете, вработениот може истовремено да работи со скратено работно време;
• вистинскиот статус на кандидатот или работникот е веќе променет (прием/префрлање/отпуштање), а наредбата за овој настан се издава со задоцнување;
• вработен се префрла на ново редовно работно место преку отказ, додека персоналниот систем не евидентира информација дека се работи за технички отказ.

Исто така, вреди да се обрне посебно внимание на проценката на квалитетот на податоците, бидејќи сите грешки и неточности добиени од доверлив извор, а тоа се системите за човечки ресурси, може да бидат скапи во иднина и да предизвикаат многу проблеми при имплементацијата на IdM. На пример, вработените во човечки ресурси често ги внесуваат работните места во персоналниот систем во различни формати: големи и мали букви, кратенки, различен број на празни места и слично. Како резултат на тоа, истата позиција може да се запише во персоналниот систем во следните варијации:

• Виш менаџер
• виш менаџер
• виш менаџер
• чл. менаџер…

Честопати треба да се справите со разликите во правописот на вашето име:

• Шмелева Наталија Генадиевна,
• Шмелева Наталија Генадиевна...

За понатамошна автоматизација, таквата мешаница е неприфатлива, особено ако овие атрибути се клучен знак за идентификација, односно податоците за вработениот и неговите овластувања во системите се споредуваат прецизно со полно име.

Покрај тоа, не треба да заборавиме на можното присуство на имењаци и целосни имењаци во компанијата. Ако една организација има илјада вработени, може да има малку такви совпаѓања, но ако има 50 илјади, тогаш ова може да стане критична пречка за правилното функционирање на системот IdM.

Сумирајќи го сето горенаведено, заклучуваме: форматот за внесување податоци во базата на податоци за персоналот на организацијата мора да биде стандардизиран. Параметрите за внесување имиња, позиции и одделенија мора да бидат јасно дефинирани. Најдобрата опција е кога вработен во човечки ресурси не внесува податоци рачно, туку ги избира од претходно креиран директориум на структурата на одделенијата и позициите користејќи ја функцијата „избери“ достапна во базата на податоци за персоналот.

За да избегнете дополнителни грешки во синхронизацијата и да не мора рачно да ги коригирате несовпаѓањата во извештаите, најпосакуваниот начин за идентификација на вработените е да внесете лична карта за секој вработен во организацијата. Таков идентификатор ќе му биде доделен на секој нов вработен и ќе се појави и во персоналниот систем и во информациските системи на организацијата како задолжителен атрибут на сметката. Не е важно дали се состои од бројки или букви, главната работа е што е единствена за секој вработен (на пример, многу луѓе го користат персоналниот број на вработениот). Во иднина, воведувањето на овој атрибут во голема мера ќе го олесни поврзувањето на податоците на вработените во изворот на персоналот со неговите сметки и овластувања во информациските системи.

Значи, сите чекори и механизми на кадровската евиденција ќе треба да се анализираат и да се стават во ред. Сосема е можно некои процеси да треба да се променат или изменат. Ова е мачна и макотрпна работа, но е неопходна, инаку недостатокот на јасни и структурирани податоци за кадровските настани ќе доведе до грешки во нивната автоматска обработка. Во најлош случај, неструктурираните процеси воопшто ќе биде невозможно да се автоматизираат.

Целни системи

Во следната фаза, треба да откриеме колку информациски системи сакаме да интегрираме во структурата на IdM, кои податоци за корисниците и нивните права се складирани во овие системи и како да управуваме со нив.

Во многу организации, постои мислење дека ќе инсталираме IdM, ќе ги конфигурираме конекторите до целните системи и со бран на волшебно стапче сè ќе работи, без дополнителен напор од наша страна. Тоа, за жал, не се случува. Во компаниите, пејзажот на информациските системи се развива и постепено се зголемува. Секој систем може да има различен пристап за доделување права за пристап, односно може да се конфигурираат различни интерфејси за контрола на пристап. Некаде контролата се случува преку API (интерфејс за програмирање на апликации), некаде преку база на податоци со зачувани процедури, некаде можеби нема воопшто интеракциски интерфејси. Треба да бидете подготвени за фактот дека ќе треба да преиспитате многу постоечки процеси за управување со сметки и права во системите на организацијата: да го промените форматот на податоците, однапред да ги подобрите интеракциските интерфејси и да доделите ресурси за оваа работа.

Модел за улоги

Веројатно ќе наидете на концептот на модел на улога во фазата на избор на давател на решенија за IdM, бидејќи ова е еден од клучните концепти во областа на управувањето со правата за пристап. Во овој модел, пристапот до податоците се обезбедува преку улога. Улога е збир на пристапи кои се минимално неопходни за вработениот на одредена позиција да ги извршува своите функционални обврски.

Контролата на пристап заснована на улоги има голем број непобитни предности:

• едноставно и ефективно е да се доделат истите права на голем број вработени;
• навремено менување на пристапот на вработените со ист збир на права;
• елиминирање на вишокот права и разграничување на некомпатибилните овластувања за корисниците.

Матрицата на улоги прво се гради посебно во секој од системите на организацијата, а потоа се скалира на целиот ИТ пејзаж, каде што глобалните деловни улоги се формираат од улогите на секој систем. На пример, деловната улога „Сметководител“ ќе вклучува неколку посебни улоги за секој од информациските системи што се користат во одделот за сметководство на претпријатието.

Неодамна, се сметаше за „најдобра практика“ да се создаде модел на улоги дури и во фаза на развој на апликации, бази на податоци и оперативни системи. Во исто време, често има ситуации кога улогите не се конфигурирани во системот или тие едноставно не постојат. Во овој случај, администраторот на овој систем мора да внесе информации за сметката во неколку различни датотеки, библиотеки и директориуми кои ги обезбедуваат потребните дозволи. Употребата на однапред дефинирани улоги ви овозможува да дадете привилегии за извршување на цела палета на операции во систем со сложени композитни податоци.

Улогите во информацискиот систем, по правило, се распределуваат за позиции и одделенија според кадровската структура, но можат да се креираат и за одредени деловни процеси. На пример, во финансиска организација, неколку вработени во одделот за порамнување ја заземаат истата позиција - оператор. Но, во рамките на одделот има и распределба во посебни процеси, според различни типови на операции (надворешни или внатрешни, во различни валути, со различни сегменти на организацијата). За да се обезбеди пристап до информацискиот систем на секоја од деловните области на еден оддел според бараните специфики, неопходно е да се вклучат права во поединечни функционални улоги. Ова ќе овозможи да се обезбеди минимален доволен сет на овластувања, кои не вклучуваат вишок права, за секоја од областите на активност.

Дополнително, за големи системи со стотици улоги, илјадници корисници и милиони дозволи, добра практика е да се користи хиерархија на улоги и наследство на привилегии. На пример, родителската улога Администратор ќе ги наследи привилегиите на детските улоги: Корисник и Читач, бидејќи Администраторот може да прави сè што можат да направат Корисникот и Читачот, плус ќе има дополнителни административни права. Користејќи хиерархија, нема потреба повторно да се специфицираат истите права во повеќе улоги на истиот модул или систем.

Во првата фаза, можете да креирате улоги во оние системи каде што можниот број на комбинации на права не е многу голем и, како резултат на тоа, лесно е да се управува со мал број улоги. Тоа може да се типични права што ги бараат сите вработени во компанијата за јавно достапни системи како што се Active Directory (AD), системи за пошта, Управник за услуги и слично. Потоа, креираните матрици за улоги за информатичките системи може да се вклучат во генералниот модел на улоги, комбинирајќи ги во деловни улоги.

Користејќи го овој пристап, во иднина, при имплементирање на систем IdM, ќе биде лесно да се автоматизира целиот процес на доделување права за пристап врз основа на креираните улоги во првата фаза.

NB Не треба веднаш да се обидувате да вклучите што повеќе системи во интеграцијата. Подобро е да се поврзат системи со посложена архитектура и структура за управување со правата на пристап до IdM во полуавтоматски режим во првата фаза. Односно, имплементирајте, врз основа на персоналните настани, само автоматско генерирање на барање за пристап, кое ќе биде испратено до администраторот за извршување, а тој рачно ќе ги конфигурира правата.

По успешното завршување на првата фаза, можете да ја проширите функционалноста на системот на нови проширени деловни процеси, да имплементирате целосна автоматизација и скалирање со поврзување на дополнителни информациски системи.

Со други зборови, за да се подготвиме за имплементација на IdM, потребно е да се процени подготвеноста на информациските системи за новиот процес и однапред да се финализираат интерфејсите за надворешна интеракција за управување со кориснички сметки и кориснички права, доколку таквите интерфејси не се достапни во системот. Треба да се истражи и прашањето за чекор-по-чекор создавање улоги во информациските системи за сеопфатна контрола на пристапот.

Организациски настани

Не ги намалувајте ни организационите проблеми. Во некои случаи, тие можат да играат одлучувачка улога, бидејќи исходот на целиот проект често зависи од ефективната интеракција помеѓу одделенијата. За да го направите ова, обично советуваме да се создаде тим од учесници во процесот во организацијата, кој ќе ги вклучи сите вклучени одделенија. Бидејќи ова е дополнителен товар за луѓето, обидете се однапред да им ја објасните на сите учесници во идниот процес нивната улога и важност во структурата на интеракцијата. Ако ја „продадете“ идејата за IdM на вашите колеги во оваа фаза, можете да избегнете многу тешкотии во иднина.

Честопати, одделенијата за безбедност на информации или ИТ се „сопственици“ на проектот за имплементација на IdM во една компанија, а мислењата на деловните оддели не се земаат предвид. Ова е голема грешка, бидејќи само тие знаат како и во кои деловни процеси се користи секој ресурс, кому треба да му се даде пристап до него, а кој не. Затоа, во фазата на подготовка, важно е да се укаже дека сопственикот на бизнисот е одговорен за функционалниот модел врз основа на кој се развиваат групи на кориснички права (улоги) во информацискиот систем, како и за обезбедување дека овие улоги се ажурираат. Моделот за улоги не е статична матрица која се гради еднаш и можете да се смирите на неа. Ова е „жив организам“ кој мора постојано да се менува, ажурира и развива, следејќи ги промените во структурата на организацијата и функционалноста на вработените. Во спротивно, или ќе се појават проблеми поврзани со доцнење во обезбедувањето пристап, или ќе се појават ризици за безбедноста на информациите поврзани со прекумерните права за пристап, што е уште полошо.

Како што знаете, „седум дадилки имаат дете без око“, така што компанијата мора да развие методологија што ја опишува архитектурата на моделот на улоги, интеракцијата и одговорноста на конкретни учесници во процесот за негово ажурирање. Ако компанијата има многу области на деловна активност и, соодветно, многу поделби и одделенија, тогаш за секоја област (на пример, кредитирање, оперативна работа, далечински услуги, усогласеност и други) како дел од процесот на управување со пристап заснован на улоги, потребно е да се назначат посебни кустоси. Преку нив ќе може брзо да се добиваат информации за промените во структурата на одделот и правата за пристап потребни за секоја улога.

Неопходно е да се побара поддршка од раководството на организацијата за да се решат конфликтните ситуации помеѓу одделенијата кои учествуваат во процесот. А конфликтите при воведување на кој било нов процес се неизбежни, верувајте во нашето искуство. Затоа, потребен ни е арбитер кој ќе решава евентуални конфликти на интереси, за да не губиме време поради туѓи недоразбирања и саботажи.

NB Добро место за почеток за подигање на свеста е да го обучите вашиот персонал. Деталната студија за функционирањето на идниот процес и улогата на секој учесник во него ќе ги минимизира тешкотиите за преминување кон ново решение.

Список за проверка

Да резимираме, ги сумираме главните чекори што треба да ги преземе организацијата која планира да имплементира IdM:

• воведе ред во податоците за персоналот;
• внесете единствен параметар за идентификација за секој вработен;
• проценка на подготвеноста на информациските системи за имплементација на IdM;
• развиваат интерфејси за интеракција со информациски системи за контрола на пристап, доколку недостасуваат, и распределуваат ресурси за оваа работа;
• развие и изгради модел за улоги;
• да изгради процес на управување со модел на улоги и да вклучи куратори од секоја деловна област во него;
• изберете неколку системи за првично поврзување со IdM;
• создадете ефективен проектен тим;
• добие поддршка од менаџментот на компанијата;
• обучи персонал.

Процесот на подготовка може да биде тежок, па ако е можно, вклучи консултанти.

Спроведувањето на решението на IdM е тежок и одговорен чекор, а за негова успешна имплементација важни се и напорите на секоја страна поединечно – вработени во деловните оддели, службите за ИТ и информациска безбедност, како и интеракцијата на целиот тим како целина. Но, напорите вредат: по спроведувањето на IdM во една компанија, бројот на инциденти поврзани со прекумерни овластувања и неовластени права во информациските системи се намалува; прекинот на вработените поради недостаток/долго чекање за потребните права исчезнува; Поради автоматизацијата, се намалуваат трошоците за работна сила и се зголемува продуктивноста на трудот на ИТ и информациските безбедносни служби.

Извор: www.habr.com