Авторка: Юлія Гриць, Netwrix Brand Manager
Більшість компаній використовують Active Directory як основу для автентифікації користувачів і керування доступом до корпоративних ресурсів. Це перевірений інструмент, що багато років залишається де-факто стандартом. Проте зі зростанням кількості інформаційних систем, переходом у хмару та посиленням вимог до безпеки AD дедалі частіше виконує лише частину необхідних завдань. Бо облікові записи – це вже давно не лише співробітники.
Коли говорять про управління обліковими записами, раніше це майже завжди означало співробітника. Сьогодні ж організації одночасно керують працівниками, підрядниками, сервісними акаунтами, застосунками, API, контейнерами, роботами та іншими non-human identities. Кожен із цих об’єктів отримує права доступу, які необхідно контролювати протягом усього життєвого циклу. І у великій організації кількість службових та машинних облікових записів може перевищувати кількість співробітників!
І що «найцікавіше» для IT команди – для кожного типу діють свої правила життєвого циклу, погодження доступів і контролю. Бо все це різноманіття вже давно вийшло за межі AD в різні системи:
- Entra ID
- корпоративні хмарні пошти Microsoft 365 або Google Workspace
- CRM- та ERP-системи
- HR-платформи
- ITSM-рішення
- файлові сховища
- хмарні сервіси різних типів
- галузеві бізнес-додатки
- Linux- та Unix-системи
- бази даних
- VPN і мережеве обладнання
- бізнес-додатки із власними локальними обліковими записами і т.д.
І чим більше масштабується бізнес, тим частіше AD перестає бути єдиним джерелом «правди», стаючи компонентом великої екосистеми. Саме тому IGA-рішення (Identity Governance and Administration) працюють не з окремим каталогом, а з усією сукупністю облікових записів незалежно від того, де вони зберігаються.
Давайте копнемо де ж проходить межа між Active Directory та сучасними рішеннями класу Identity Governance and Administration, і чому багато організацій сьогодні використовують їх разом, а не замість одне одного.
Авторська примітка
У англійській identity – це дуже прагматичний технічний термін. Він означає сутність (entity), яку система може однозначно ідентифікувати та для якої керує атрибутами, ролями, правами і життєвим циклом. Це не обов’язково людина.
В українській, на жаль, жоден із варіантів не є вдалим. Це вічний батл, як же правильно перекласти.
- цифрова ідентичність – скоріше цифровий слід та репутація в соціальних мережах
- цифрова особистість – ще гірше, бо перед очима одразу постає аватар у метавсесвіті
- просто ідентичність – ну тут без контексту звучить взагалі дивно, бо це більше про культуру, національність, політику, гендер та особистість в цілому. І десь там в самому низу буде технічна складова
Тому у статті під обліковими записами я буду мати на увазі всі цифрові сутності, якими керує організація: облікові записи співробітників, сервісні акаунти, технічні облікові записи застосунків, машинні ідентифікатори та інші об’єкти, що отримують права доступу до корпоративних ресурсів.
Ніхто не каже, що AD – це поганий варіант
Протягом понад двадцяти років Microsoft Active Directory залишається одним із ключових компонентів ІТ-інфраструктури. Для більшості організацій саме він є центральним каталогом користувачів, груп і комп’ютерів, забезпечуючи єдину точку автентифікації та централізоване адміністрування ресурсів домену.
Адміни можуть легко створювати та керувати обліковими записами, організовувати їх у групи, застосовувати політики безпеки, контролювати доступ до мережевих ресурсів і т.д.
AD робить свою роботу, коли треба забезпечити:
- централізоване зберігання облікових записів
- автентифікацію та авторизацію користувачів у домені
- застосування групових політик для керування налаштуваннями безпеки
- делегування адміністративних повноважень
- підтримку стандартних протоколів, таких як LDAP, Kerberos і DNS
Однак важливо розуміти, що AD створювався насамперед як служба каталогів та автентифікації, а не як система управління життєвим циклом записів. Так, каталог знає хто цей користувач і чи може він увійти до системи, але там де починаються питання типу «Чому цей акаунт має саме такий доступ?», «Хто його погодив?», «Коли його потрібно змінити або відкликати?» – він вже не може відповісти.
Саме на цьому етапі вже варто розглядати інший клас рішень – Identity Governance and Administration (IGA). Це не заміна Active Directory, а його логічне доповнення, яке враховує вимоги бізнесу, інформаційної безпеки та комплаєнсу.
Приклад, де вже недостатньо
1
співробітник працює у 15 системах
2
окрім AD є Microsoft 365, CRM, ERP, Service Desk, HRM, VPN, SaaS…
3
доступи погоджують електронною поштою
4
адміністратори вручну створюють акаунти
5
після зміни посади права накопичуються
6
після звільнення окремі доступи можуть залишатися активними
Ознаки того, що компанія вже переросла просто Active Directory
Для невеликих компаній можливостей AD часто достатньо. І це абсолютно валідно, не треба вигадувати новий велосипед. Але зі зростанням бізнесу збільшується кількість співробітників, інформаційних систем, бізнес-процесів і вимог до безпеки. У певний момент адміністрування облікових записів перестає бути лише технічним завданням і перетворюється на окремий управлінський процес.
Даю невеличкий чекліст, чи вам потрібно Identity Governance and Administration рішення:
- Користувачі працюють у багатьох системах.
- Створення та зміна облікових записів виконуються вручну. ІТ-фахівці витрачають багато часу на створення користувачів, призначення прав, внесення змін після переведення співробітників або їхнього звільнення.
- Немає єдиного джерела прав доступу. Важко швидко відповісти на запитання: хто сьогодні має доступ до конкретної системи, хто його погодив і на якій підставі.
- Доступи накопичуються з часом. Після зміни посади або функціональних обов’язків співробітники нерідко зберігають старі права, які вже не потрібні для роботи.
- Компанія регулярно проходить аудити. Підготовка інформації для аудиторів займає багато часу, оскільки дані доводиться збирати з різних систем і перевіряти вручну.
- Процеси погодження не стандартизовані. Запити на доступ надходять через електронну пошту, месенджери або усні домовленості, що ускладнює контроль і подальший аудит.
Якщо ви впізнали хоча б декілька з цих пунктів, то мабуть вже час подумати про новий рівень управління обліковими записами та підключити Identity Governance and Administration рішення, наприклад, Netwrix Identity Manager.
Просто Active Directory чи з IGA? Реальні сценарії Joiner-Mover-Leaver
Сценарій 1. Новий співробітник виходить на роботу
Уявімо, що в компанію приходить новий менеджер із продажу.
Лише Active Directory:
- HR повідомляє ІТ про нового співробітника
- адміністратор створює обліковий запис у Active Directory
- окремо додає користувача до потрібних груп
- створює поштову скриньку Microsoft 365
- налаштовує доступ до CRM, ERP, корпоративного порталу, VPN та інших систем
- надсилає логіни та паролі новому співробітнику
Навіть якщо окремі етапи автоматизовані скриптами, процес часто залишається розподіленим між кількома адміністраторами та різними системами.
З IGA:
- HR створює запис про нового співробітника в кадровій системі
- Identity Governance and Administration система автоматично визначає його роль, запускає необхідний бізнес-процес, створює облікові записи у всіх потрібних системах, призначає відповідні права доступу та, за потреби, надсилає заявки на погодження
- до першого робочого дня співробітник уже має всі необхідні доступи
Бізнес-результат: швидший онбординг, менше ручної роботи та відсутність ризику, що якийсь важливий доступ забули надати.
Сценарій 2. Співробітник переходить в інший відділ
Менеджер із продажу стає керівником відділу.
Лише Active Directory:
- адміністратор додає нові групи безпеки, але старі права нерідко залишаються
- через кілька років співробітник може мати доступ до систем, які давно не потрібні для його роботи (це явище називають Privilege Creep – поступове накопичення надлишкових прав доступу).
З IGA:
- система автоматично аналізує нову роль співробітника
- відкликає доступи, які більше не потрібні
- призначає нові відповідно до політик компанії
Якщо певні права потребують погодження, відповідний workflow запускається автоматично.
Бізнес-результат: користувач має лише ті доступи, які необхідні для виконання його поточних обов’язків, що знижує ризики внутрішніх інцидентів і спрощує аудит.
Сценарій 3. Співробітник звільняється
Це один із найкритичніших процесів з точки зору безпеки.
Лише Active Directory:
- обліковий запис у домені можуть заблокувати одразу, але компанія часто використовує десятки інших систем – CRM, ERP, хмарні сервіси, VPN, системи документообігу, галузеві рішення
- якщо відкликання доступів виконується вручну, завжди існує ризик, що якийсь обліковий запис залишиться активним
З IGA:
- після зміни статусу співробітника в HR-системі запускається автоматизований процес деактивації
- система відкликає доступи до всіх підключених інформаційних систем відповідно до визначених правил, а всі виконані дії фіксуються для подальшого аудиту
Бізнес-результат: мінімізується ризик несанкціонованого доступу після звільнення співробітника та скорочується час, необхідний ІТ-відділу для виконання цієї процедури.
Як виглядає еволюція від Active Directory до IGA?
Тож якщо коротко підсумувати все вищезгадане – це різні системи із різними задачами.
Давайте розберемо, що сучасні IGA-рішення можуть додати, бо вони не замінюють Active Directory, а використовують його як одне із джерел даних і автоматизують бізнес-процеси навколо облікових записів.
| Етап роботи | Базові можливості AD | Що додає IGA |
| Створення та зберігання | Зберігає облікові записи й об’єкти в домені | Керує повним життєвим циклом облікового запису (onboarding, зміна ролі, звільнення) у всіх системах, включно з AD |
| Моделювання доступу | Керує статичними групами та правами всередині AD | Працює з бізнес ролями, каталогом доступів, політиками; автоматично призначає права на основі ролі, посади, підрозділу |
| Автентифікація | Перевіряє облікові дані користувачів, надає доступ до доменних ресурсів | Інтегрується з IAM/SSO, MFA, але фокусується не на логіні, а на тому, хто і чому отримує які права |
| Охоплення систем | Переважно один домен/ліс, максимум декілька інтегрованих систем | Працює з усіма бізнес системами (AD, ERP, CRM, хмари, SaaS) як з цільовими системами доступу |
| Бізнес контекст | Не знає посад, процесів, відповідальних; бачить лише технічні об’єкти | Тягне дані з HR та інших авторитетних джерел, прив’язує доступ до посади, підрозділу, процесів |
| Контроль і аудит | Логування подій є, але немає повноцінного governance шару | Підтримує Access Reviews, сертифікацію прав, SoD, політики комплаєнсу, сценарії «хто погодив, коли, на якій підставі» |
| Погодження доступу | Переважно ручні заявки в Service Desk або адмінам | Дає self service портал, керує процесами погодження (workflow), терміном дії доступу, делегуванням |
| Автоматизація | Скрипти, GPO, окремі консолі – точкова автоматизація | Централізовані workflow, правила, конектори до систем; автоматизація бізнес процесів навколо доступу |
Якщо спростити до одного речення, то Active Directory відповідає на питання «Хто це?», а IGA – «Чому цей акаунт має саме такий доступ і що має відбутися з ним далі?».
Про IGA клас систем ми вже писали основне, не буду повторювати, запрошую прочитати статтю «Посібник з управління та адміністрування ідентичностей (IGA)» із описом та частими питаннями, що виникають щодо цих систем. Плюс там описано і різницю між IGA, IAM та PAM.
Тож якщо порівнювати?
Не треба. Не робіть цього, бо порівнювати Active Directory та IGA, як ви сподіваюсь вже зрозуміли, просто некоректно, адже вони вирішують різні завдання. Що обрати, якщо масштабування потребує нових процесів? Both!
- Active Directory відповідає за автентифікацію, каталог користувачів і базове адміністрування доступу.
- IGA-система керує бізнес-процесами навколо identity: визначає, хто повинен отримати доступ, до яких систем, на якій підставі, хто має його погодити, коли цей доступ необхідно змінити або відкликати.
Саме тому в сучасній інфраструктурі ці рішення не конкурують між собою, а доповнюють одне одного: AD забезпечує технічну основу, а IGA, наприклад Netwrix Identity Manager, надає контроль, автоматизацію та управління протягом усього життєвого циклу облікових записів і доступів.
IGA піднімає рівень зрілості: від простої реєстрації облікових записів у каталозі до керування.
