В предишните статии вече разгледахме какво е IdM, как да разберете дали на вашата организация е нужна такава система, какви задачи решава и как да обосновете бюджета за внедряване пред ръководството. Днес ще поговорим за важните етапи, които организацията трябва да премине, за да достигне необходимото ниво на зрялост преди внедряване на системата IdM. Все пак, IdM е предназначена да автоматизира процеси, а автоматизирането на хаос е невъзможно.
До момента, в който компанията достигне размера на голямо предприятие и натрупа маса от различни бизнес системи, обикновено не се замисля за управление на достъпа. Поради това процесите на получаване на права и контрол на пълномощията не са структурирани и трудно подлежат на анализ. Служителите подават заявки за достъп по произволен начин, процесът на одобрение също не е формализиран, а понякога изобщо липсва. Невъзможно е бързо да се разбере какви достъпи има служителят, кой ги е одобрил и на какво основание.
Като се има предвид, че процесът на автоматизация на достъпа засяга две основни страни – кадрови данни и данни от информационни системи, с които предстои да се проведе интеграция, нека разгледаме стъпките, необходими за гладкото внедряване на IdM и избягване на отхвърляне:
- Анализ на кадровите процеси и оптимизация на поддръжката на базата данни на служителите в кадровите системи.
- Анализ на данните за потребителите и правата, както и актуализация на методите за управление на достъпа в целевите системи, които планирате да свържете с IdM.
- Организационни мероприятия и включване на персонала в процеса на подготовка за внедряване на IdM.
Кадрови данни
Източникът на кадрови данни в организацията може да бъде един, но може и да е няколко. Например, организацията може да има доста широка филиална мрежа и в всеки филиал може да се използва собствена кадрова база.
Преди всичко е необходимо да се разбере какви основни данни за служителите се съхраняват в системата за кадрово отчитане, какви събития се фиксират и да се оцени тяхната пълнота и структура.
Често е така, че не всички кадрови събития се отбелязват в кадровия източник (а още по-често те се отбелязват несвоевременно и не напълно коректно). Ето няколко типични примера:
- не се фиксират отпуски, техните категории и срокове (планирани или дългосрочни);
- Не се отразява частична заетост: например, по време на дълъг отпуск по майчинство служителят може едновременно да работи на непълен работен ден;
- Действителният статус на кандидата или служителя вече се е променил (назначение/прехвърляне/уволнение), а заповедта за това събитие идва със закъснение;
- Служителят е прехвърлен на нова щатна позиция чрез уволнение, като в кадровата система не се фиксира информация за това, че е техническо уволнение.
Също така е важно да се обърне внимание на оценката на качеството на данните, тъй като всякакви грешки и неточности, получени от доверен източник, каквито са системите за кадрово управление, могат да струват скъпо и да предизвикат множество проблеми при внедряване на IdM. Например, служителите на кадровите служби често въвеждат длъжностите на работниците в кадровата система в различен формат: главни и малки букви, съкращения, различен брой интервали и т.н. В резултат на това една и съща длъжност може да бъде фиксирана в кадровата система в следните варианти:
- Старши мениджър
- старши мениджър
- ст.мениджър
- ст. мениджър…
Често се срещат и различия в написването на П. И. Б.:
- ШмелЁва НаталИЯ Геннадиевна,
- ШмелЕва Наталия Геннадиевна…
За по-нататъшната автоматизация такъв хаос е неприемлив, особено ако тези атрибути са ключов признак за идентификация, т.е. данните за служителя и неговите правомощия в системите се съпоставят именно по П. И. Б.
Освен това не бива да се забравя за възможното наличие на еднофамилци и пълни тезки в компанията. Ако в организацията има хиляда служители, подобни съвпадения могат да бъдат малко, а ако са 50 хиляди, това може да се превърне в критична пречка за правилната работа на IdM системата.
Обобщавайки всичко казано дотук, заключаваме: форматът на въвеждане на данни в кадровата база на организацията трябва да бъде стандартизиран. Параметрите за въвеждане на П. И. Б., длъжности и подразделения трябва да бъдат ясно определени. Оптималният вариант е, когато кадровият служител не въвежда данните ръчно, а ги избира от предварително създаден справочник на структурата на подразделенията и длъжностите с помощта на функцията „select“, налична в кадровата база.
За да се избегнат бъдещи грешки в синхронизацията и да не се налага ръчно да се коригират несъответствията в отчетите, най-предпочитаният начин за идентификация на служителите е въвеждането на ID за всеки работник в организацията. Такъв идентификатор ще бъде предоставен на всеки нов служител и ще фигурира както в кадровата система, така и в информационните системи на организацията като задължителен атрибут на профила. Независимо дали се състои от цифри или букви, важното е той да бъде уникален за всеки работник (например, много организации използват служебния номер на служителя). Впоследствие, въвеждането на този атрибут значително ще улесни свързването на данни за служителя в кадровия източник с неговите профили и права в информационните системи.
Така че всички стъпки и механизми на кадровия отчет трябва да бъдат анализирани и в тях да се въведе ред. Възможно е да се наложи някои процеси да бъдат променени или доработени. Това е трудоемка и прецизна работа, но тя е необходима, в противен случай липсата на ясни и структурирани данни за кадровите събития ще доведе до грешки при автоматичната им обработка. В най-лошия случай неструктурираните процеси изобщо няма да могат да бъдат автоматизирани.
Целеви системи
На следващия етап е необходимо да определим колко информационни системи искаме да интегрираме в структурата на IdM, какви данни за потребителите и техните права се съхраняват в тези системи и как да ги управляваме.
В много организации съществува мнение, че ще инсталираме IdM, ще настроим свързващите елементи към целевите системи и с магическа пръчка всичко ще заработи, без допълнителни усилия от наша страна. Това, за съжаление, не бива да се приема за даденост. В компаниите ландшафтът на информационните системи постепенно се развива и разширява. Във всяка от системите може да бъде организиран различен подход към предоставяне на права за достъп, тоест настроени различни интерфейси за управление на достъпа. Някъде управлението става чрез API (интерфейс за програмиране на приложения), някъде чрез база данни с помощта на съхранени процедури, а може и интерфейсите за взаимодействие да липсват напълно. Трябва да бъдем готови да преразгледаме много от съществуващите процеси по управление на акаунти и права в системите на организацията: да променим формата на данните, предварително да доработим интерфейсите за взаимодействие и да отделим ресурси за тези работи.
Ролева модел
С понятието ролеви модел вероятно ще се сблъскате още на етапа на избора на доставчик на IdM-решение, тъй като това е едно от ключовите понятия в сферата на управлението на права за достъп. В този модел предоставянето на достъп до данни се извършва чрез роля. Ролята представлява съвкупност от достъпи, минимално необходими, за да може служител с определена длъжност да изпълнява своите функционални задължения.
Ролевото управление на достъпа има редица неоспорими предимства:
- леснота и ефективност при назначаването на еднакви права на голямо количество служители;
- оперативно изменение на достъпа на служители, притежаващи един и същ набор от права;
- изключване на излишъка от права и разграничаване на несъвместими полномочия за потребителите.
Ролевата матрица първоначално се изгражда отделно в всяка от системите на организацията и след това се мащабира на целия ИТ-ландшафт, където от ролите на всяка система се формират глобални Бизнес-роли. Например, Бизнес-ролята „Счетоводител“ ще включва няколко отделни роли за всяка от информационните системи, използвани в счетоводството на предприятието.
В последно време се счита за «best practice» още на етапа на разработка на приложения, бази данни и операционни системи да се създаде ролеви модел. В същото време не са редки и ситуациите, когато в системата ролите не са настроени или просто ги няма. В такъв случай администраторът на тази система трябва да въведе данните на акаунта в няколко различни файла, библиотеки и директории, предоставящи необходимите разрешения. Използването на предварително определени роли позволява даването на привилегии за извършването на цял набор от операции в системата със сложни съставни данни.
Ролите в информационната система обикновено се разпределят за длъжности и подразделения според щатната структура, но могат да бъдат създадени и за определени бизнес процеси. Например, в финансова организация няколко служители от отдел „Разчети“ заемат една и съща длъжност – оператор. Но в отдела има и разпределение по отделни процеси, в различни видове операции (външни или вътрешни, в различна валута, с различни сегменти на организацията). За да предоставим достъп на всяко от бизнес направленията на един отдел в информационната система според необходимата специфика, е необходимо да включим правата в отделни функционални роли. Това ще позволи предоставянето на минимално необходим набор от правомощия, без излишни права, за всяко от направленията на дейността.
Освен това, за големи системи с хиляди роли, стотици потребители и милиони разрешения, добрата практика е използването на иерархия на ролите и наследяване на привилегии. Например, родителската роля Администратор ще наследява привилегиите на дъщерните роли: Потребител и Читател, тъй като Администраторът може да прави всичко, което правят Потребителят и Читателят, плюс ще има допълнителни администраторски права. При използване на иерархия няма нужда да се посочват отново еднакви права в няколко роли на един модул или система.
В началния етап е възможно да се създадат роли в тези системи, където възможното количество комбинации на права не е много голямо и, следователно, не е трудно да се управлява малък брой роли. Това могат да бъдат стандартни права, необходими за всички служители на компанията, в публични системи, като каталога Active Directory (AD), имейл системи, Service Manager и подобни. След това създадените ролеви матрици за информационните системи могат да бъдат включени в общата ролевата модел, обединявайки ги в Бизнес-роли.
Използвайки такъв подход, по-късно при внедряването на IdM системата ще бъде лесно да се автоматизира целият процес на предоставяне на права за достъп на основа на създадените роли в първия етап.
Забележка. Не трябва да се опитвате веднага да включите колкото се може повече системи в интеграцията. Системите с по-сложна архитектура и структура за управление на правата на достъп е по-добре да се свържат с IdM в полуа automatизиран режим в първия етап. Тоест, реализирайте автоматично генериране на искане за достъп въз основа на кадрови събития, което ще бъде изпратено за изпълнение на администратора, и той ще настрои правата ръчно.
След успешното преминаване на първия етап, може да се разшири функционалността на системата към нови разширени бизнес процеси, да се осъществи пълна автоматизация и мащабиране с включване на допълнителни информационни системи.
С други думи, за да се подготвите за внедряването на IdM, трябва да оцените готовността на информационните системи за новия процес и предварително да доразработите външните интерфейси за взаимодействие при управление на акаунти и права на потребителите, ако в системата липсват такива интерфейси. Също така следва да се разгледа въпросът за поетапното създаване на роли в информационните системи за комплексно управление на достъпа.
Организационни мероприятия
Не бива да се пренебрегват организационните моменти. В някои случаи те могат да играят решаваща роля, тъй като ефективното взаимодействие между отделите често определя резултата от целия проект. Затова обикновено съветваме да се създаде екип от участници в процеса, в който да влязат всички засегнати отдели. Тъй като това е допълнително натоварване за хората, се постарайте предварително да обясните на всички участници в бъдещия процес тяхната роля и важност в структурата на взаимодействието. Ако на този етап успеете да „продадете“ идеята за IdM на колегите, можете да избегнете много трудности в по-късен етап.
Често „собственици“ на проекта за внедряване на IdM в компанията са отделите по информационна безопасност или ИТ, а мнението на бизнес-отделите не се взема предвид. Това е голяма грешка, тъй като само те знаят как и в кои бизнес-процеси се използва всеки ресурс, на кого трябва да се предостави достъп, а на кого не. Затова в етапа на подготовка е важно да се подчертае, че именно бизнес-властелинът отговаря за функционалния модел, на базата на който се разработват наборите от права (роли) на потребителите в информационната система, а също така и за важността те да се поддържат в актуално състояние. Ролевият модел не е статична матрица, която веднъж е изградена и може да се остави така. Това е „жив организъм“, който трябва постоянно да се променя, обновява и развива, следвайки измененията в структурата на организацията и функционалността на служителите. В противен случай или ще започнат проблеми, свързани със забавяне в предоставянето на достъп, или ще възникнат рискове за информационната безопасност, свързани с излишните права за достъп, което е дори по-лошо.
Както е известно, "при седем бавачки, детето остава без око", затова в компанията трябва да бъде разработена методология, описваща архитектурата на ролевия модел, взаимодействието и отговорността на конкретните участници в процеса за поддържане на актуалността му. Ако в компанията има много направления на бизнес дейност и, съответно, множество подразделения и департаменти, то за всяко направление (например, кредитиране, оперативна работа, дистанционни услуги, комплайънс и други) в рамките на процеса на ролево управление на достъпа е необходимо да се назначат отделни куратори. Чрез тях ще може да се получава информация за изменения в структурата на подразделението и правата на достъп, необходими за всяка роля.
Задължително е да се осигури подкрепата на ръководството на организацията за решение на конфликтни ситуации между подразделенията – участници в процеса. А конфликтите при внедряването на всякакъв нов процес са неизменна част, повярвайте на нашия опит. Затова е нужен арбитър, който да разрешава възможните конфликти на интереси, за да не губим време заради нечие недоразумение и саботаж.
Забележка. Добро начало за повишаване на нивото на осведоменост е обучението на персонала. Подробното запознаване с функционирането на бъдещия процес и роля на всеки участник в него ще позволи да се минимализират трудностите при преминаването към новото решение.
Контролен списък
В обобщение, резюмираме основните стъпки, които трябва да предприеме организацията, планираща внедряване на IdM:
- да се подреди кадровата информация;
- да се въведе уникален идентификационен параметър за всеки работник;
- да се оцени готовността на информационните системи за внедряване на IdM;
- да се разработят интерфейси за взаимодействие с информационните системи за управление на достъпа, ако те липсват, и да се отделят ресурси за тези дейности;
- да се разработи и изгради ролевият модел;
- да се изгради процес на управление на ролевия модел и да се включат куратори от всяко бизнес направление;
- да се изберат няколко системи за първоначално свързване с IdM;
- да се създаде ефективен проектен екип;
- да се осигури подкрепата на ръководството на компанията;
- да се обучи персонала.
Процесът на подготовка може да бъде труден, затова, ако е възможно, привлечете консултанти.
Внедряването на IdM решение е сложна и отговорна стъпка, и за успешната му реализация са важни усилията на всяка страна поотделно – служителите в бизнес подразделенията, ИТ и ИБ службите, както и взаимодействието на целия екип като цяло. Но усилията си струват: след внедряването на IdM в компанията се намалява броят на инцидентите, свързани с излишни права и неразрешени достъпи в информационните системи; изчезват времевите загуби на служителите поради липсата или дългото чакане на необходимите права; чрез автоматизация се намаляват трудовите разходи и се увеличава производителността на труда на ИТ и ИБ службите.
Източник: habr.com
