Внедряване на IdM. Подготовка за изпълнение от клиента

В предишни статии вече разгледахме какво е IdM, как да разберете дали вашата организация се нуждае от такава система, какви проблеми решава и как да оправдаете бюджета за внедряване пред ръководството. Днес ще говорим за важните етапи, през които трябва да премине самата организация, за да постигне нужното ниво на зрялост, преди да внедри IdM система. В края на краищата IdM е проектиран да автоматизира процесите, но е невъзможно да се автоматизира хаосът.

Докато една компания не нарасне до размера на голямо предприятие и не натрупа много различни бизнес системи, обикновено не мисли за контрол на достъпа. Поради това процесите на получаване на права и контролни правомощия в него не са структурирани и трудно подлежат на анализ. Служителите попълват заявления за достъп по свое желание; процесът на одобрение също не е формализиран, а понякога просто не съществува. Невъзможно е бързо да се разбере какъв достъп има даден служител, кой го е одобрил и на какво основание.

Като се има предвид, че процесът на автоматизиране на достъпа засяга два основни аспекта - данни за персонала и данни от информационни системи, с които трябва да се извърши интеграция, ще разгледаме необходимите стъпки, за да гарантираме, че внедряването на IdM протича гладко и няма да доведе до отказ:

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

Данни за персонала

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

На първо място е необходимо да се разбере какви основни данни за служителите се съхраняват в системата за досиета на персонала, какви събития се записват и да се оцени тяхната пълнота и структура.

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

• Отпуските, техните категории и срокове (редовни или дългосрочни) не се записват;
• Заетостта на непълно работно време не се записва: например, докато е в дългосрочен отпуск за отглеждане на дете, служителят може едновременно да работи на непълно работно време;
• действителният статус на кандидата или служителя вече е променен (приемане/преместване/уволнение), а заповедта за това събитие е издадена със закъснение;
• служител се прехвърля на нова редовна длъжност чрез уволнение, докато системата за персонал не записва информация, че това е техническо уволнение.

Също така си струва да се обърне специално внимание на оценката на качеството на данните, тъй като всички грешки и неточности, получени от надежден източник, който е HR системите, могат да бъдат скъпи в бъдеще и да причинят много проблеми при прилагането на IdM. Например, служителите по човешки ресурси често въвеждат длъжности на служители в системата за персонал в различни формати: главни и малки букви, съкращения, различен брой интервали и други подобни. В резултат на това същата позиция може да бъде записана в системата за персонал в следните варианти:

• Старши мениджър
• старши мениджър
• старши мениджър
• Изкуство. мениджър...

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

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

За по-нататъшна автоматизация подобно объркване е неприемливо, особено ако тези атрибути са ключов знак за идентификация, тоест данните за служителя и неговите правомощия в системите се сравняват точно по пълното име.

Освен това не трябва да забравяме за възможното присъствие на съименници и пълни съименници в компанията. Ако една организация има хиляда служители, може да има малко такива съвпадения, но ако има 50 хиляди, това може да се превърне в критична пречка за правилната работа на системата IdM.

Обобщавайки всичко по-горе, заключаваме: форматът за въвеждане на данни в базата данни за персонала на организацията трябва да бъде стандартизиран. Параметрите за въвеждане на имена, длъжности и отдели трябва да бъдат ясно дефинирани. Най-добрият вариант е, когато служител по човешки ресурси не въвежда данни ръчно, а ги избира от предварително създадена директория със структурата на отделите и позициите, като използва функцията „избор“, налична в базата данни за персонала.

За да избегнете допълнителни грешки при синхронизирането и да не се налага ръчно да коригирате несъответствията в отчетите, най-предпочитаният начин за идентифициране на служители е въвеждането на ID за всеки служител на организацията. Такъв идентификатор ще бъде присвоен на всеки нов служител и ще се появи както в системата за персонал, така и в информационните системи на организацията като задължителен атрибут на акаунта. Няма значение дали се състои от цифри или букви, основното е, че е уникален за всеки служител (например много хора използват личния номер на служителя). В бъдеще въвеждането на този атрибут значително ще улесни свързването на данните на служителя в източника на персонала с неговите акаунти и пълномощия в информационните системи.

Така че всички стъпки и механизми на досиетата на персонала ще трябва да бъдат анализирани и приведени в ред. Напълно възможно е някои процеси да трябва да бъдат променени или модифицирани. Това е досадна и мъчителна работа, но е необходима, в противен случай липсата на ясни и структурирани данни за събитията на персонала ще доведе до грешки при автоматичната им обработка. В най-лошия случай неструктурираните процеси изобщо ще бъдат невъзможни за автоматизиране.

Целеви системи

На следващия етап трябва да разберем колко информационни системи искаме да интегрираме в структурата на IdM, какви данни за потребителите и техните права се съхраняват в тези системи и как да ги управляваме.

В много организации има мнение, че ще инсталираме IdM, ще конфигурираме конектори към целевите системи и с вълна на магическа пръчка всичко ще работи, без допълнителни усилия от наша страна. Това, уви, не се случва. В компаниите пейзажът на информационните системи се развива и нараства постепенно. Всяка система може да има различен подход за предоставяне на права за достъп, тоест могат да се конфигурират различни интерфейси за контрол на достъпа. Някъде контролът се осъществява чрез API (интерфейс за програмиране на приложения), някъде чрез база данни, използваща съхранени процедури, някъде може изобщо да няма интерфейси за взаимодействие. Трябва да сте подготвени за факта, че ще трябва да преразгледате много съществуващи процеси за управление на акаунти и права в системите на организацията: променете формата на данните, подобрете предварително интерфейсите за взаимодействие и разпределете ресурси за тази работа.

Модел за подражание

Вероятно ще срещнете концепцията за модел за подражание на етапа на избор на доставчик на IdM решение, тъй като това е една от ключовите концепции в областта на управлението на правата за достъп. В този модел достъпът до данни се предоставя чрез роля. Ролята е набор от достъпи, които са минимално необходими на служител на определена позиция, за да изпълнява своите функционални отговорности.

Ролевият контрол на достъпа има редица неоспорими предимства:

• лесно и ефективно е да се възлагат едни и същи права на голям брой служители;
• бърза промяна на достъпа на служители със същия набор от права;
• премахване на излишните права и разграничаване на несъвместими правомощия за потребителите.

Матрицата на ролите първо се изгражда отделно във всяка от системите на организацията и след това се мащабира към целия ИТ пейзаж, където глобалните бизнес роли се формират от ролите на всяка система. Например, бизнес ролята „Счетоводител” ще включва няколко отделни роли за всяка от информационните системи, използвани в счетоводния отдел на предприятието.

Напоследък се счита за „най-добра практика“ да се създаде модел за подражание дори на етапа на разработване на приложения, бази данни и операционни системи. В същото време често има ситуации, когато ролите не са конфигурирани в системата или просто не съществуват. В този случай администраторът на тази система трябва да въведе информация за акаунта в няколко различни файла, библиотеки и директории, които предоставят необходимите разрешения. Използването на предварително дефинирани роли ви позволява да предоставяте привилегии за извършване на цял набор от операции в система със сложни съставни данни.

Ролите в една информационна система по правило се разпределят за длъжности и отдели според щатната структура, но могат да се създават и за определени бизнес процеси. Например във финансова организация няколко служители от отдела за сетълмент заемат една и съща позиция - оператор. Но вътре в отдела има и разпределение на отделни процеси, според различните видове операции (външни или вътрешни, в различни валути, с различни сегменти на организацията). За да се осигури достъп на всяко от бизнес направленията на един отдел към информационната система според изискваната специфика, е необходимо да се включат права в отделни функционални роли. Това ще позволи да се осигури минимален достатъчен набор от правомощия, който не включва излишни права, за всяка от областите на дейност.

Освен това, за големи системи със стотици роли, хиляди потребители и милиони разрешения е добра практика да се използва йерархия от роли и наследяване на привилегии. Например родителската роля Administrator ще наследи привилегиите на дъщерните роли: User и Reader, тъй като Administrator може да прави всичко, което могат да правят User и Reader, плюс ще има допълнителни административни права. Използвайки йерархия, няма нужда да указвате повторно едни и същи права в множество роли на един и същ модул или система.

На първия етап можете да създавате роли в тези системи, където възможният брой комбинации от права не е много голям и в резултат на това е лесно да се управлява малък брой роли. Това може да са типични права, изисквани от всички служители на компанията за обществено достъпни системи като Active Directory (AD), пощенски системи, Service Manager и други подобни. След това създадените ролеви матрици за информационни системи могат да бъдат включени в общия ролеви модел, комбинирайки ги в бизнес роли.

Използвайки този подход, в бъдеще, при внедряването на IdM система, ще бъде лесно да се автоматизира целият процес на предоставяне на права за достъп въз основа на създадените първостепенни роли.

NB Не трябва да се опитвате веднага да включите възможно най-много системи в интеграцията. По-добре е да свържете системи с по-сложна архитектура и структура за управление на правата на достъп към IdM в полуавтоматичен режим на първия етап. Тоест внедрите въз основа на събития на персонала само автоматичното генериране на заявка за достъп, която ще бъде изпратена на администратора за изпълнение и той ще конфигурира правата ръчно.

След успешно завършване на първия етап можете да разширите функционалността на системата към нови разширени бизнес процеси, да внедрите пълна автоматизация и мащабиране с свързването на допълнителни информационни системи.

С други думи, за да се подготви за внедряването на IdM, е необходимо да се оцени готовността на информационните системи за новия процес и предварително да се финализират интерфейсите за външно взаимодействие за управление на потребителски акаунти и потребителски права, ако такива интерфейси не са налични в системата. Въпросът за поетапното създаване на роли в информационните системи за цялостен контрол на достъпа също трябва да бъде проучен.

Организационни дейности

Не пренебрегвайте и организационните въпроси. В някои случаи те могат да играят решаваща роля, тъй като резултатът от целия проект често зависи от ефективното взаимодействие между отделите. За да направите това, обикновено съветваме да създадете екип от участници в процеса в организацията, който ще включва всички участващи отдели. Тъй като това е допълнителна тежест за хората, опитайте се да обясните предварително на всички участници в бъдещия процес тяхната роля и значение в структурата на взаимодействие. Ако „продадете“ идеята за IdM на вашите колеги на този етап, можете да избегнете много трудности в бъдеще.

Често отделите за информационна сигурност или ИТ са „собственици“ на проекта за внедряване на IdM в една компания и мненията на бизнес отделите не се вземат предвид. Това е голяма грешка, защото само те знаят как и в какви бизнес процеси се използва всеки ресурс, кой трябва да получи достъп до него и кой не. Ето защо на етапа на подготовка е важно да се посочи, че собственикът на бизнеса е отговорен за функционалния модел, въз основа на който се разработват набори от потребителски права (роли) в информационната система, както и за гарантиране, че тези роли се актуализират. Моделът за подражание не е статична матрица, която се изгражда веднъж и можете да се успокоите върху нея. Това е „жив организъм“, който трябва постоянно да се променя, актуализира и развива, следвайки промените в структурата на организацията и функционалността на служителите. В противен случай или ще възникнат проблеми, свързани със забавяне на предоставянето на достъп, или ще възникнат рискове за информационната сигурност, свързани с прекомерни права за достъп, което е още по-лошо.

Както знаете, „седем бавачки имат дете без око“, така че компанията трябва да разработи методология, която описва архитектурата на модела за подражание, взаимодействието и отговорността на конкретни участници в процеса за поддържането му актуален. Ако една компания има много области на бизнес дейност и съответно много отдели и отдели, тогава за всяка област (например кредитиране, оперативна работа, дистанционни услуги, съответствие и други) като част от ролевия процес на управление на достъпа, тя е необходимо да се назначат отделни уредници. Чрез тях ще може бързо да се получава информация за промени в структурата на отдела и необходимите права за достъп за всяка роля.

Наложително е да се привлече подкрепата на ръководството на организацията за разрешаване на конфликтни ситуации между отделите, участващи в процеса. А конфликтите при въвеждането на всеки нов процес са неизбежни, повярвайте на нашия опит. Затова се нуждаем от арбитър, който да разрешава евентуални конфликти на интереси, за да не губим време заради чужди недоразумения и саботаж.

NB Добро място да започнете да повишавате осведомеността е да обучите персонала си. Детайлното проучване на функционирането на бъдещия процес и ролята на всеки участник в него ще сведе до минимум трудностите при прехода към ново решение.

Контролен списък

За да обобщим, обобщаваме основните стъпки, които една организация, планираща да внедри IdM, трябва да предприеме:

• въведе ред в данните за персонала;
• въведете уникален идентификационен параметър за всеки служител;
• оценяват готовността на информационните системи за внедряване на IdM;
• разработване на интерфейси за взаимодействие с информационните системи за контрол на достъпа, ако такива липсват, и отделяне на ресурси за тази работа;
• развиват и изграждат модел за подражание;
• изградете модел за управление на процеса и включете в него куратори от всяка бизнес област;
• изберете няколко системи за първоначално свързване към IdM;
• създаване на ефективен проектен екип;
• да получите подкрепа от ръководството на компанията;
• обучават персонала.

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

Внедряването на IdM решение е трудна и отговорна стъпка, като за успешното му внедряване са важни както усилията на всяка страна поотделно – служители на бизнес отделите, службите за ИТ и информационна сигурност, така и взаимодействието на целия екип като цяло. Но усилията си заслужават: след внедряване на IdM в една компания, броят на инцидентите, свързани с прекомерни правомощия и неоторизирани права в информационните системи, намалява; изчезва престой на служителите поради липса/дълго чакане на необходимите права; Благодарение на автоматизацията се намаляват разходите за труд и се повишава производителността на труда на услугите за ИТ и информационна сигурност.

Източник: www.habr.com