У попередніх статтях ми вже розглядали, що таке IdM, як зрозуміти, чи потрібна вашій організації подібна система, які завдання вона вирішує та як обґрунтувати бюджет впровадження перед керівництвом. Сьогодні ми поговоримо про важливі етапи, які має пройти сама організація, щоб досягти належного рівня зрілості перед впровадженням системи IdM. Адже IdM має автоматизувати процеси, а автоматизувати хаос неможливо.
До того моменту, як компанія доросте до розмірів великого підприємства і накопичить у себе безліч різних бізнес-систем, вона зазвичай не замислюється про управління доступом. Тому процеси отримання прав та контролю повноважень у ній не структуровані та погано піддаються аналізу. Співробітники оформлюють заявки на доступ, хто як захоче, процес узгодження теж не формалізований, а іноді його просто немає. Неможливо швидко розібратися, які доступи є у співробітника, хто їх узгодив та на якій підставі.
Враховуючи, що процес автоматизації доступу зачіпає дві основні сторони – кадрові дані та дані інформаційних систем, інтеграцію з якими належить провести, розглянемо кроки, необхідні для того, щоб впровадження IdM пройшло гладко та не викликало відторгнення:
- Аналіз кадрових процесів та оптимізація супроводу БД співробітників у кадрових системах.
- Аналіз даних про користувачів та права, а також актуалізація способів керування доступом у цільових системах, які планується підключити до IdM.
- Організаційні заходи та залучення персоналу до процесу підготовки до впровадження IdM.
Кадрові дані
Джерело кадрових даних у організації може бути одне, і може бути кілька. Наприклад, організація може мати досить широку мережу філій, і в кожній філії може використовуватися своя кадрова база.
Насамперед необхідно зрозуміти, які основні дані про співробітників зберігаються в системі кадрового обліку, які події фіксуються, та оцінити їхню повноту та структуру.
Часто буває так, що не всі кадрові події відзначаються у кадровому джерелі (а ще частіше вони відзначаються невчасно та не зовсім коректно). Ось кілька типових прикладів:
- не фіксуються відпустки, їх категорії та строки (чергові чи тривалі);
- не фіксується часткова зайнятість: наприклад, перебуваючи у тривалій відпустці для догляду за дитиною, співробітник може одночасно працювати на неповній ставці;
- фактичний статус кандидата чи працівника вже змінився (прийом/переведення/звільнення), а наказ про цю подію виходить із затримкою;
- співробітника переводять на нову штатну позицію через звільнення, причому в кадровій системі не фіксується інформація про те, що це технічне звільнення.
Також варто окрему увагу приділити оцінці якості даних, оскільки будь-які помилки та неточності, отримані з довіреного джерела, яким є системи кадрового обліку, можуть надалі дорого обходитися та викликати безліч проблем при впровадженні IdM. Наприклад, співробітники кадрових служб нерідко заводять посади працівників у кадрову систему у різному форматі: великі та малі літери, скорочення, різна кількість прогалин тощо. В результаті одна й та сама посада може бути зафіксована у кадровій системі у наступних варіаціях:
- Старший менеджер
- старший менеджер
- ст.менеджер
- ст. менеджер...
Нерідко доводиться стикатися і з відмінностями в написанні ПІБ:
- Шмельова Наталія Геннадійна,
- Шмєльова Наталія Геннадійівна…
Для подальшої автоматизації такий ералаш неприйнятний, тим більше, якщо ці атрибути є ключовою ознакою ідентифікації, тобто дані про співробітника та його повноваження в системах зіставляються саме за ПІБ.
Крім того, не слід забувати про можливу наявність у компанії однофамільців та повних тезок. Якщо в організації тисяча співробітників, таких збігів може бути небагато, а якщо 50 тисяч, це може стати критичним перешкодою для коректної роботи IdM-системи.
Узагальнюючи вищевикладене, робимо висновок: формат введення даних у кадрову базу організації має бути стандартизований. Параметри введення ПІБ, посад та підрозділів мають бути чітко визначені. Оптимальний варіант - коли кадровий працівник не вбиває дані вручну, а вибирає їх із заздалегідь створеного довідника структури підрозділів та посад за допомогою функції "select", що є в кадровій базі.
Щоб уникнути подальших помилок у синхронізації та не займатися ручним виправленням розбіжностей у звітах, найкращим способом ідентифікації співробітників є введення ID для кожного працівника організації. Такий ідентифікатор присвоюватиметься кожному новому працівникові і фігуруватиме як у кадровій системі, так і в інформаційних системах організації як обов'язковий атрибут облікового запису. Не важливо, чи складається він із цифр чи літер, — головне, щоб для кожного працівника він був унікальний (наприклад, багато хто використовує табельний номер співробітника). Надалі запровадження цього атрибуту серйозно полегшить зв'язування даних про співробітника у кадровому джерелі з його обліковими записами та повноваженнями в інформаційних системах.
Отже, всі кроки та механізми кадрового обліку треба буде проаналізувати та навести в них порядок. Цілком можливо, що якісь процеси доведеться змінити чи доопрацювати. Це стомлива і копітка робота, але вона необхідна, інакше відсутність чітких і структурованих даних про кадрові події призведе до помилок при їх автоматичній обробці. У гіршому разі неструктуровані процеси взагалі неможливо буде автоматизувати.
Цільові системи
На наступному етапі потрібно розібратися, скільки інформаційних систем ми хочемо інтегрувати в структуру IdM, які дані про користувачів та їхні права зберігаються в цих системах і як ними керувати.
У багатьох організаціях існує думка, що ми встановимо IdM, налаштуємо конектори до цільових систем, і по помаху чарівної палички все запрацює, без додаткових зусиль з нашого боку. Так, на жаль, не буває. У компаніях ландшафт інформаційних систем розвивається та збільшується поступово. У кожній із систем може бути організований різний підхід до надання прав доступу, тобто налаштовані різні інтерфейси управління доступом. Десь управління відбувається через API (application programming interface), десь через базу даних за допомогою процедур, що зберігаються, десь інтерфейси взаємодії можуть взагалі бути відсутніми. Варто бути готовими до того, що доведеться переглянути багато існуючих процесів з управління обліковими записами та правами в системах організації: змінити формат даних, заздалегідь доопрацювати інтерфейси взаємодії та виділити ресурси на ці роботи.
Рольова модель
З поняттям рольової моделі ви зіткнетеся, напевно, ще на етапі вибору постачальника IdM-рішення, оскільки це одне з ключових понять у сфері управління правами доступу. У цій моделі надання доступу до даних здійснюється через роль. Роль - це сукупність доступів, мінімально необхідних для того, щоб співробітник на певній посаді міг виконувати свої функціональні обов'язки.
Рольове управління доступом має низку незаперечних переваг:
- проста та ефективність призначення однакових прав великій кількості співробітників;
- оперативна зміна доступу співробітників, які мають однаковий набір прав;
- виключення надмірності прав та розмежування несумісних повноважень для користувачів.
Рольова матриця спочатку вибудовується окремо в кожній із систем організації, а потім масштабується на весь ІТ-ландшафт, де з ролей кожної системи формуються глобальні бізнес-ролі. Наприклад, Бізнес-роль «Бухгалтер» буде включати кілька окремих ролей по кожній з інформаційних систем, що використовуються в бухгалтерії підприємства.
Останнім часом вважається "best practice" ще на етапі розробки додатків, баз даних та операційних систем створювати рольову модель. У той самий час нерідкі й ситуації, як у системі ролі не налаштовані чи його просто немає. У такому разі адміністратор цієї системи повинен внести дані облікового запису до різних файлів, бібліотек і каталогів, які надають необхідні дозволи. Використання заздалегідь певних ролей дозволяє давати привілеї для проведення цілого комплексу операцій у системі зі складними складовими даними.
Ролі в інформаційній системі, як правило, розподіляються для посад та підрозділів за штатною структурою, але можуть бути створені і для певних бізнес-процесів. Наприклад, у фінансовій організації кілька співробітників відділу розрахунків обіймають однакову посаду – оператор. Але всередині відділу є ще й розподіл на окремі процеси, за різними видами операцій (зовнішні чи внутрішні, у різній валюті, з різними сегментами організації). Для того, щоб кожному з бізнес-напрямків одного відділу надати доступ до інформаційної системи за необхідною специфікою, необхідно включити права в окремі функціональні ролі. Це дозволить надати мінімально достатній набір повноважень, що не включає надлишкових прав для кожного з напрямків діяльності.
Крім того, для великих систем із сотнями ролей, тисячами користувачів та мільйонами дозволів гарною практикою є використання ієрархії ролей та успадкування привілеїв. Наприклад, батьківська роль Адміністратор буде успадковувати привілеї дочірніх ролей: Користувача та Читача, оскільки Адміністратор може робити те ж саме, що Користувач і Читач, плюс матиме додаткові адміністраторські права. З використанням ієрархії немає необхідності повторно вказувати однакові права у кількох ролях одного модуля чи системи.
На першому етапі можна створити ролі в тих системах, де можлива кількість комбінацій прав не дуже велика і, як наслідок, нескладно керувати малою кількістю ролей. Це можуть бути типові права, необхідні всім співробітникам компанії, у загальнодоступних системах, таких як каталог Active Directory (AD), поштові системи, Service Manager та подібні. Потім створені рольові матриці за інформаційними системами можна буде включити в загальну рольову модель, поєднуючи їх у Бізнес-ролі.
Використовуючи такий підхід, надалі при впровадженні IdM-системи буде нескладно автоматизувати весь процес надання прав доступу на основі ролей першого етапу.
NB Не варто намагатися одразу включити в інтеграцію якнайбільше систем. Системи з більш складною архітектурою та структурою управління правами доступу на першому етапі краще підключати до IdM у напівавтоматичному режимі. Тобто реалізувати на підставі кадрових подій лише автоматичне формування заявки на доступ, яка надійде на виконання адміністратору, і він налаштує права вручну.
Після успішного проходження першого етапу можна поширити функціонал системи на нові розширені бізнес-процеси, здійснити повну автоматизацію та масштабування із підключенням додаткових інформаційних систем.
Іншими словами, щоб підготуватися до впровадження IdM, потрібно оцінити готовність інформаційних систем до нового процесу та заздалегідь доопрацювати зовнішні інтерфейси взаємодії з управління обліковими записами та правами користувачів, якщо в системі такі інтерфейси відсутні. Також слід опрацювати питання щодо поетапного створення ролей в інформаційних системах для комплексного управління доступом.
Організаційні заходи
Не варто скидати з рахунків та організаційні моменти. У деяких випадках вони можуть грати вирішальну роль, тому що від ефективної взаємодії між підрозділами часто-густо залежить результат всього проекту. Для цього ми зазвичай радимо створити в організації команду учасників процесу, до якої увійдуть усі задіяні підрозділи. Оскільки для людей це додаткове навантаження, постарайтеся роз'яснити заздалегідь усім учасникам майбутнього процесу їх роль і значущість у структурі взаємодії. Якщо «продати» колегам ідею IdM на цьому етапі, можна буде уникнути подальших складнощів.
Часто «власниками» проекту впровадження IdM у компанії виступають підрозділи інформаційної безпеки чи ІТ, а думка бізнес-підрозділів не враховується. Це велика помилка, адже тільки вони знають, яким чином і в яких бізнес-процесах використовують кожен ресурс, кому треба давати до нього доступ, а кому ні. Тому на етапі підготовки важливо позначити, що саме бізнес-власник відповідає за функціональну модель, на підставі якої розробляються набори прав (ролей) користувачів в інформаційній системі, а також те, щоб ці ролі підтримувалися в актуальному стані. Рольова модель - це не статична матриця, яку один раз збудували і можна на цьому заспокоїтися. Це «живий організм», який повинен постійно змінюватися, оновлюватися та розвиватися, слідуючи змін структури організації та функціоналу співробітників. Інакше або почнуться проблеми, пов'язані із затримками у наданні доступу, або виникнуть ризики інформаційної безпеки, пов'язані з надмірними правами доступу, що ще гірше.
Як відомо, «у семи няньок дитини без ока», у компанії має бути розроблена методологія, що описує архітектуру рольової моделі, взаємодію та відповідальність конкретних учасників процесу за підтримку її в актуальному стані. Якщо в компанії багато напрямків бізнес-діяльності і, відповідно, безліч підрозділів і департаментів, то в кожному напрямку (наприклад, кредитування, операційна робота, дистанційні послуги, комплаєнс та інші) в рамках процесу рольового управління доступом необхідно призначити окремих кураторів. Через них можна буде оперативно отримувати інформацію про зміни в структурі підрозділу та права доступу, необхідні для кожної ролі.
Обов'язково потрібно заручитися підтримкою керівництва організації на вирішення конфліктних ситуацій між підрозділами – учасниками процесу. А конфлікти під час запровадження будь-якого нового процесу неминучі, повірте нашому досвіду. Тому потрібен арбітр, який розрулюватиме можливі конфлікти інтересів, щоб не гаяти час через чиїсь непорозуміння та саботаж.
NB Хорошим починанням підвищення рівня обізнаності буде навчання персоналу. Докладне вивчення функціонування майбутнього процесу, ролі кожного учасника у ньому дозволить мінімізувати труднощі переходу нове рішення.
Чек лист
Підсумовуючи, резюмуємо основні кроки, які слід зробити організації, що планує використання IdM:
- навести лад у кадрових даних;
- запровадити унікальний ідентифікаційний параметр для кожного працівника;
- оцінити готовність інформаційних систем до впровадження IdM;
- розробити інтерфейси взаємодії з інформаційними системами для управління доступом, якщо вони відсутні, та виділити ресурси на ці роботи;
- розробити та побудувати рольову модель;
- вибудувати процес управління рольовою моделлю та включити до нього кураторів від кожного бізнес-напряму;
- вибрати кілька систем для початкового підключення до IdM;
- створити ефективну проектну команду;
- заручитися підтримкою керівництва компанії;
- навчити персонал.
Процес підготовки може бути нелегким, тому, якщо є можливість, залучайте консультантів.
Впровадження IdM-рішення – непростий та відповідальний крок, і для успішної його реалізації важливі як зусилля кожної сторони окремо – співробітників бізнес-підрозділів, ІТ та ІБ-служб, так і взаємодія всієї команди загалом. Але зусилля варті того: після впровадження IdM у компанії знижується кількість інцидентів, пов'язаних із надмірними повноваженнями та несанкціонованими правами в інформаційних системах; зникають простої співробітників через відсутність/довгого очікування необхідних прав; за рахунок автоматизації знижуються трудовитрати та підвищується продуктивність праці ІТ- та ІБ-служб.
Джерело: habr.com