- Що таке моніторинг привілейованих користувачів?
- Чому привілейовані облікові записи найскладніше відстежувати
- Що має охоплювати моніторинг привілейованих користувачів
- Як побудувати програму моніторингу привілейованих користувачів
- Вимоги відповідності щодо моніторингу привілейованих користувачів
- Типові труднощі та способи їх подолання
- Як Netwrix допомагає контролювати привілейованих користувачів
- Виявлення фактичних привілеїв поза межами членства в групах
- Заміна постійного привілейованого доступу доступом для конкретного завдання
- Фіксація змін прав і налаштувань зі значеннями до та після
- Виявлення аномальної поведінки привілейованих і сервісних облікових записів
- Покриття заходів CISA щодо облікових записів
- Перетворення адміністративної довіри на дані, які можна перевірити
Для виконання операційних завдань потрібен доступ із підвищеними привілеями, і організації надають його на основі довіри. Тому моніторинг привілейованих користувачів має перетворювати цю довіру на підтверджені дані.
Запис про авторизацію показує лише те, що система дозволила певну дію. Моніторинг натомість створює доступний для перевірки запис про те, які підвищені права використовував кожен користувач і коли саме. Завдяки цьому аудитор або фахівець із розслідування може перевірити активність, не втручаючись в адміністративні процеси.
Постійний привілейований доступ досі залишається типовою практикою в більшості середовищ. Згідно з опитуванням, проведеним для звіту Netwrix про безпеку даних та облікових записів за 2026 рік, 67% організацій надають такий доступ принаймні окремим ролям.
Ці права залишаються активними навіть у періоди між завданнями, для виконання яких вони були надані. Саме цю прогалину й має закривати моніторинг привілейованих користувачів.
Адміністратор, який входить до групи Domain Admins, має повні права в межах відповідної області керування Active Directory. При цьому для системи немає різниці, хто стоїть за обліковими даними: керівник інфраструктурної команди чи зловмисник, який отримав їх унаслідок фішингу.
Успішна авторизація підтверджує лише наявність дозволу — і нічого більше. Для підтвердження дійсності дії та відсутності зловмисного наміру потрібні окремі докази. Моніторинг надає такі докази та посилює контроль доступу, не сповільнюючи адміністративні процеси, від яких залежить робота організації.
Що таке моніторинг привілейованих користувачів?
Моніторинг привілейованих користувачів — це безперервний збір та аналіз дій, які виконують облікові записи з правами на критично важливі для безпеки операції. Завдяки цьому кожне використання підвищених прав залишає запис, який можна надалі перевірити.
NIST визначає привілейованого користувача як особу, яка має дозвіл, а отже й відповідний рівень довіри, на виконання функцій безпеки, недоступних звичайним користувачам.
Водночас це визначення не передбачає, що за обліковими даними обов’язково має стояти людина. Тому до тієї самої категорії належать сервісні облікові записи, керовані облікові записи та облікові записи автоматизації з підвищеними правами.
Охоплення моніторингу також не обмежується локальною директорією, з якої багато команд починають роботу. Якщо обліковий запис має адміністративні права — в Active Directory, хмарному постачальнику облікових записів, адміністративній консолі SaaS або базі даних — він має входити до переліку об’єктів моніторингу.
Чому привілейовані облікові записи найскладніше відстежувати
Системи авторизації відповідають на запитання, чи має певний обліковий запис право виконати конкретну дію. Для привілейованого облікового запису в межах його області керування відповідь зазвичай буде «так».
Через чотири особливості таке «так» може приховувати значно більше, ніж здається.
Дійсні облікові дані роблять адміністрування та атаку схожими
Щойно директорія надає відповідні права, вхід до системи, перевірка членства в групах і доступ до ресурсів завершуються успішно, оскільки використовуються дійсні облікові дані. Для системи не має значення, чи використовує їх справжній адміністратор, чи зловмисник, який отримав їх за допомогою фішингу.
Техніка MITRE T1078.002 описує саме такий сценарій зловживання дійсними обліковими даними доменного облікового запису для первинного доступу, закріплення в системі, підвищення привілеїв та обходу засобів захисту.
Згідно з опитуванням для Netwrix про безпеку даних та облікових записів за 2026 рік, 73,78% організацій не повністю впевнені, що їхнє середовище Active Directory не містить помилок конфігурації, які дають змогу підвищити привілеї. Кожна така помилка створює ще один шлях до тієї самої довіреної позиції.
Стандартні запити до груп не враховують вкладене членство
Атрибут memberOf в Active Directory не відображає вкладене членство в групах. Тому прямий запит до Domain Admins або будь-якої іншої привілейованої групи не покаже користувачів, які отримують відповідні права через вкладені групи.
Якщо перевірка доступу охоплює лише безпосередніх учасників групи, вона від самого початку виконується для неповного переліку користувачів.
ACL створюють тіньових адміністраторів поза привілейованими групами
Списки контролю доступу (ACL) можуть надавати чутливі права тіньовим адміністраторам — обліковим записам, які взагалі не входять до жодної привілейованої групи директорії.
Найпоказовіший приклад — обліковий запис із правом змінювати склад групи. Він може самостійно додати себе до цієї групи.
Така поведінка передбачена самою архітектурою системи, а не є налаштуванням, яке можна просто вимкнути.
Права через GPO та локального адміністратора не створюють подій зміни членства
Права на редагування об’єктів групової політики (GPO), зокрема GenericWrite або WriteDacl, а також права локального адміністратора, що зберігаються в локальній базі Security Accounts Manager (SAM), можуть надавати аналогічний рівень фактичних повноважень без будь-якого членства в привілейованій групі.
Під час входу служб і запланованих завдань пароль облікового запису також зберігається на диску як секрет, який можна повторно використати, у Local Security Authority (LSA). Унаслідок цього компрометація такого хоста може призвести й до компрометації облікових даних.
Жоден із цих сценаріїв не створює подій зміни членства 4728, 4732 або 4756, на які покладаються звіти про права доступу.
Що має охоплювати моніторинг привілейованих користувачів
Моніторинг виправдовує свої витрати тоді, коли фіксує саме ті зміни, які впливають на рівень ризику.
В ідеалі подія, що генерує попередження, має з високою ймовірністю вказувати на несанкціоновану активність і водночас мати низький рівень хибнопозитивних спрацювань. Як зазначено в CIS Control 8, журнали аудиту іноді залишаються єдиним доказом успішної атаки.
Природне бажання — збирати все. Але результатом легко може стати черга попереджень, яку зрештою ніхто не переглядає.
| Сигнал | Приклади | Чому це важливо |
| Зміни прав доступу | Додавання до адміністративних груп, призначення ролей Microsoft Entra ID, делегування прав на організаційні підрозділи (OU), зміни ACL, редагування GPO | Кожна з таких змін надає фактичні права доступу або створює механізм закріплення в системі, що відповідає техніці MITRE T1484 |
| Поведінка під час автентифікації | Зміни типу входу, входи з незнайомих хостів, входи з токеном підвищених привілеїв, невдалі спроби підвищення привілеїв, доступ у неробочий час | Зловживання дійсними обліковими даними не має характерних ознак шкідливої активності, тому його можна виявити за відхиленнями від звичайної поведінки облікового запису |
| Доступ до чутливих даних | Доступ до чужих поштових скриньок, читання даних у сховищах регламентованої інформації, масовий експорт | Доступ до вмісту без відповідного робочого завдання може відповідати технікам збору даних, зокрема T1114 і T1213 |
| Зміни засобів контролю безпеки | Зміни політик аудиту, очищення логів, вимкнення агентів, зміни Conditional Access | Втручання в роботу засобів контролю часто свідчить про те, що масштабніша атака вже триває |
| Події життєвого циклу облікових записів | Створення облікових записів, повторне ввімкнення вимкнених облікових записів, тривала неактивність | Зловмисники можуть створювати облікові записи, щоб зберегти доступ навіть після заходів з усунення наслідків інциденту |
Доступ до чутливих даних користувачами, які не є їх власниками, зокрема читання чужих поштових скриньок, відповідає технікам збору даних MITRE, таким як T1114 і T1213. У Microsoft 365 таку активність можна відстежувати за допомогою аудиторської дії MailItemsAccessed.
Захист від втручання дає змогу виявляти спроби вимкнення агента на кінцевій точці.
Для неактивних облікових записів необхідно визначити чіткий поріг. У рекомендації CISA щодо протидії неактивним обліковим записам конкретне значення залишається на розсуд кожної організації. У наведеному CISA прикладі пороговим значенням є 180 днів з моменту зміни пароля.
До облікових записів вендорів слід застосовувати такий самий контроль, як і до облікових записів співробітників, які залишають організацію.
У документі CISA Cross-Sector Cybersecurity Performance Goals 2.0, опублікованому в грудні 2025 року, вимоги щодо керування ризиками постачальників керованих послуг доповнено вимогою вимикати всі облікові записи та шляхи доступу в день звільнення або припинення співпраці з користувачем.
Моніторинг привілейованих користувачів, керування привілейованими сесіями та моніторинг активності користувачів
Ці три засоби контролю часто плутають, оскільки всі вони стосуються дій адміністраторів. Однак кожен із них має різне охоплення та відповідає на окреме запитання
| Параметр | Моніторинг привілейованих користувачів | Керування привілейованими сесіями | Моніторинг активності користувачів |
| Охоплення | Привілейований обліковий запис і його права доступу | Окрема привілейована сесія | Усі користувачі організації |
| Період спостереження | Безперервно, з формуванням базового профілю поведінки протягом тижнів або місяців | Тривалість одного підключення | |
| На яке запитання відповідає | Чи відповідають поведінка цього облікового запису та набір його прав очікуваній нормі? | Що відбулося під час цієї сесії? | Чи може активність цього користувача свідчити про інсайдерську загрозу? |
| Основний результат | Базовий профіль поведінки, оцінка ризику, попередження про аномалії, звіти про права доступу | Запис сесії, журнал натискань клавіш, індекс для розслідування | Дані про вміст екрана та натискання клавіш усіх співробітників |
| Запис вмісту | Необов’язковий | Стандартний | Стандартний |
Керування привілейованими сесіями контролює саме підключення та ізолює облікові дані від кінцевого користувача. Тому його найдетальнішими артефактами є записи сесій і журнали натискань клавіш.
Такі журнали фіксують усе введене, зокрема паролі та персональні дані. Тому строки зберігання та контроль доступу мають бути суворо обмежені. Водночас фахівцям із розслідування все одно потрібен структурований журнал команд поряд із записами сесій, адже переглядати відео в пошуках однієї конкретної дії непрактично.
Моніторинг активності користувачів поширює такий самий запис вмісту на всіх співробітників організації для виявлення інсайдерських загроз, відповідно до визначення NIST для User Activity Monitoring.
Рекомендації британського ICO щодо моніторингу працівників розглядають запис екрана та натискань клавіш як настільки масштабну обробку даних, що вона потребує проведення оцінки впливу на захист даних.
Моніторинг привілейованих користувачів, навпаки, за замовчуванням не передбачає запису вмісту. Він зосереджується на авторизації: визначає перелік адміністраторів та перевіряє, які підвищені права використовував кожен обліковий запис.
Саме завдяки такому вужчому фокусу цей підхід можна безперервно застосовувати до всіх привілейованих облікових записів, а не лише до вибірки окремих сесій. На практиці більшість програм використовують щонайменше два з цих трьох засобів контролю.
Як побудувати програму моніторингу привілейованих користувачів
Спочатку потрібно виявити всі привілейовані облікові записи. Далі — скоротити їх кількість, визначити базову поведінку та налаштувати виявлення, а потім захистити зібрані докази.
Кожен етап звужує обсяг роботи для наступного. Саме тому, якщо почати одразу з інструментів виявлення, згодом усе одно доведеться повертатися й заново формувати повний перелік привілейованих облікових записів.
1. Виявлення всіх привілейованих облікових записів
Потрібно визначити кожен обліковий запис і кожне право, яке надає адміністративні повноваження, а не обмежуватися лише членством у групах:
- Доменні та локальні адміністратори з урахуванням транзитивного членства в групах, щоб охопити також учасників вкладених груп.
- Права, надані через ACL, а також дозволи на редагування GPO для об’єктів каталогу.
- Локальна група Administrators на кожній кінцевій точці.
- Типи сервісних облікових записів, зокрема group Managed Service Accounts (gMSA), standalone Managed Service Accounts (sMSA), облікові записи комп’ютерів та облікові записи користувачів, від імені яких запускаються служби.
- Аварійні облікові записи break-glass, а також доступ вендорів і підрядників.
- Привілейовані ролі в хмарних і SaaS-середовищах — від Entra ID Global Administrator і Privileged Role Administrator до аналогічних адміністративних ролей в інших постачальників облікових записів і бізнес-застосунках.
Для кожного запису потрібно визначити конкретного відповідального та чітко зазначити його призначення. Інакше сформований перелік швидко перетвориться на список, із яким ніхто не працює.
2. Скорочення кількості постійних привілеїв до початку моніторингу
Перед побудовою наступного етапу варто прибрати всі постійні привілейовані облікові записи, які не потрібно охоплювати моніторингом.
У більшості середовищ підвищених прав більше, ніж реально потрібно для виконання роботи. Те саме опитування Netwrix показало, що 68% організацій не забезпечують суворе дотримання принципу мінімальних привілеїв.
Як мінімум варто перейти до моделі підвищення привілеїв just-in-time із тимчасовими правами, які автоматично припиняють діяти після завершення визначеного строку.
Ще жорсткіший підхід — нульові постійні привілеї, за якого жоден обліковий запис не має підвищених прав між погодженими сесіями, а тимчасові облікові записи існують лише протягом виконання конкретної роботи.
3. Визначення нормальної адміністративної активності для кожної ролі
Спроби автентифікації, запити на доступ, зміни привілеїв і зміни в каталозі потрібно передавати до платформи виявлення загроз і реагування на рівні облікових записів.
Замість оцінювання кожного окремого підключення платформа має формувати профіль поведінки для кожного облікового запису та відповідної групи схожих користувачів.
Поведінкова аналітика та кореляція сигналів дають змогу виявляти те, що пропускають правила, побудовані на окремих подіях. Такий самий принцип використовується, зокрема, у механізмах виявлення Microsoft Defender for Identity.
Для нового адміністратора або щойно створеного сервісного облікового запису протягом перших кількох тижнів сигнали будуть менш точними, оскільки якість базового профілю покращується зі накопиченням даних про активність.
4. Відстеження змін прав між перевірками
Поточні права потрібно порівнювати з останнім підтвердженим станом не лише під час планових перевірок, а й у проміжках між ними.
Періодична перевірка фіксує лише стан у конкретний момент. Якщо нове право було надано через тиждень після завершення перевірки, воно може залишатися без контролю до наступного циклу.
Тому слід позначати будь-яке нове право, яке з’явилося після останньої сертифікації. У такому разі щорічна перевірка лише підтверджуватиме те, що вже було виявлено моніторингом, а не залишатиметься єдиною контрольною точкою.
5. Попередження про окремі зміни та кореляція закономірностей
Для невеликого набору подій, які самі по собі майже ніколи не є дійсними, потрібно створювати попередження негайно.
Усе інше варто аналізувати через кореляцію.
Більшість атак стають помітними лише як послідовність кількох слабших сигналів. Наприклад: незвичний вхід, потім зміна привілеїв, а після цього — доступ до системи, з якою цей обліковий запис раніше ніколи не працював.
Тому правила для окремих подій і поведінкова кореляція мають бути частинами одного підходу, а не несумісними варіантами.
6. Захист доказів від адміністраторів, дії яких вони фіксують
Варто виходити з того, що адміністратори, яких охоплює моніторинг, можуть змінити записи про власну активність, доки архітектура не доведе протилежне.
За замовчуванням членство в Domain Admins також надає членство в локальній групі Administrators на кожному комп’ютері, приєднаному до домену. Це дає право читати журнал Security та можливість повністю його очистити.
Саме таку ситуацію описує NIST SP 800-53 AU-9(4): якщо користувачі з привілейованим доступом одночасно є об’єктами аудиту, вони можуть впливати на надійність аудиторської інформації, вимикаючи журналювання або змінюючи записи.
Навіть обмеження ACL для доступу до журналів не зупинять рішучого доменного адміністратора. За допомогою привілею SeTakeOwnershipPrivilege він може отримати право власності на об’єкт і переписати його дискреційний список контролю доступу (DACL).
Тому потрібно будувати архітектурне розмежування, а не покладатися лише на ACL. Саме такий контроль залишається ефективним навіть у разі компрометації адміністративного облікового запису.
Вимога AU-9(2) передбачає окреме зберігання даних аудиту, щоб компрометація системи, яку контролюють, не призвела до компрометації її журналів.
- Передавання подій безпеки майже в реальному часі на колектор, що адмініструється окремо. Windows Event Forwarding підтримує такий підхід, однак не надсилає сповіщення та не позначає прогалину в журналах, якщо на відключеному клієнті старі події були перезаписані.
- Передавання на той самий колектор подій 4728, 4732 і 4756, які фіксують додавання користувачів до груп, а також подій 5136, пов’язаних зі змінами AdminSDHolder. Це не дає непомітно видалити з журналу повторне надання прав між перевірками.
- Обмеження керування журналами аудиту визначеною групою привілейованих користувачів, яка відокремлена від адміністраторів, дії яких перевіряються, відповідно до AU-9(4). Для фахівців, які проводять перевірки, має надаватися доступ лише для читання відповідно до AU-9(6).
- Створення попереджень про спроби втручання. Подія 4719 фіксує зміну політики аудиту, і Windows реєструє її незалежно від поточних налаштувань аудиту. Таку подію варто оцінювати як подію високої критичності. Також її потрібно корелювати з попередньою подією 4688 створення процесу, яка може показати запуск wevtutil або auditpol. Для цього має бути ввімкнено журналювання командного рядка.
Вимоги відповідності щодо моніторингу привілейованих користувачів
Під час аудиту організації мають довести, хто і які права мав, у який період вони діяли та які дії були виконані з їх використанням.
У різних фреймворках ця вимога визначається через періодичність повторної перевірки прав і вимоги до журналювання. При цьому самі строки — найпростіша частина.
Найбільше проблем виникає з відтворенням історії. Якщо через шість місяців неможливо відновити, як саме проходила перевірка та на яких даних вона ґрунтувалася, це може стати проблемою під час аудиту незалежно від того, чи була перевірка проведена вчасно.
Нижче наведено версії вимог, чинні станом на вересень 2026 року: PCI DSS v4.0.1, NIST SP 800-53 Rev. 5, HIPAA Security Rule відповідно до 45 CFR Part 164 Subpart C та ISO/IEC 27001:2022.
Поряд із ними застосовуються два європейські нормативні акти: імплементаційний регламент до Директиви NIS2 та делегований регламент до Digital Operational Resilience Act (DORA).
| Фреймворк | Вимоги щодо контролю привілейованого доступу |
| PCI DSS v4.0.1 | Вимога 10.2.1.2 передбачає журналювання всіх адміністративних дій. Вимога 7.2.4 вимагає перевіряти облікові записи користувачів і їхні права кожні шість місяців, зокрема облікові записи третіх сторін і вендорів. |
| NIST SP 800-53 Rev. 5 | Контроль AC-6(9) вимагає журналювати виконання привілейованих функцій. |
| HIPAA Security Rule | 45 CFR 164.312(b) вимагає вести записи про активність систем, які містять електронну захищену медичну інформацію (ePHI). Правило не встановлює конкретного строку зберігання журналів аудиту. |
| SOX and the Public Company Accounting Oversight Board (PCAOB) | Окремого пронумерованого контролю щодо перевірки привілейованого доступу немає. AS 1105 вимагає, щоб аудитори перевіряли точність і повноту інформації, сформованої компанією. |
| ISO/IEC 27001:2022 | Додаток A, пункти 5.18 і 8.2, вимагає обмежувати привілейовані права доступу та переглядати їх через заплановані проміжки часу й після внесення змін. Частота перевірок визначається оцінкою ризиків організації. |
| NIS2 (Implementing Regulation 2024/2690) | Пункт 11.3 Додатка вимагає перевіряти привілейовані права доступу через заплановані проміжки часу та документувати результати таких перевірок. |
| DORA (Delegated Regulation 2024/1774) | Стаття 21 вимагає проводити перевірки доступу щонайменше раз на шість місяців для систем, що підтримують критичні або важливі функції, і щонайменше раз на рік — для всіх інших систем. |
У січні 2025 року HHS запропонувало масштабне оновлення HIPAA Security Rule, однак ці зміни досі залишаються на рівні пропозиції. Згідно з планом регуляторних заходів, остаточне рішення наразі очікується в липні 2027 року.
У запропонованій редакції вимогу щодо засобів аудиту планується перенести з 164.312(b) до 164.312(d)(1) та поширити на всі відповідні системи, а не лише на ті, що містять ePHI. До остаточного затвердження змін HHS чинним залишається посилання на 164.312(b).
Готовність до аудиту має цілком практичне обмеження: якщо потрібно відновити привілейовану дію, виконану кілька місяців тому, можливість це зробити залежить від строку зберігання відповідних доказів.
Microsoft Entra ID за стандартними строками зберігає журнали аудиту та входу протягом 7 днів на тарифі Free і 30 днів на тарифах P1 та P2.
Водночас вимога PCI DSS 10.5.1 передбачає зберігання історії журналів аудиту протягом 12 місяців, причому дані за останні три місяці мають бути негайно доступні для аналізу.
Тому стандартного строку зберігання в Entra ID недостатньо. Через це колектор, до якого передаються копії журналів, зазвичай стає основним джерелом історичних даних.
Типові труднощі та способи їх подолання
Наведені нижче проблеми мають переважно організаційний і операційний характер, тому проста заміна інструментів рідко допомагає їх вирішити.
- Адміністратори можуть сприймати моніторинг як прояв недовіри, а деякі намагаються його вимкнути. Контроль доцільно виносити за межі середовища, яке вони адмініструють, передаючи журнали до системи, до якої ці адміністратори не мають доступу. До впровадження контролю також важливо пояснити, які саме загрози спрямовані на їхні облікові дані. Тимчасові права, призначені конкретним користувачам, дають змогу зберігати журнал контролю без автоматичного ставлення до адміністраторів як до потенційних порушників.
- Дійсна привілейована активність може створювати настільки великий обсяг подій, що важливі попередження губляться. Доцільніше оцінювати відхилення від базової поведінки, а не створювати попередження для кожної окремої події. Логіку виявлення варто будувати навколо тактик, технік і процедур (TTP), щоб, наприклад, відомий сценарій оновлення, запущений адміністратором, не створював зайвого попередження.
- Спільні, аварійні та вендорські облікові записи ускладнюють визначення конкретного користувача, а аварійні облікові записи за своєю природою можуть не мати постійного власника. Для адміністрування доцільно використовувати окремі виділені облікові записи відповідно до CIS Control 5, а сервісні облікові записи переглядати щонайменше щокварталу. Для кожного сервісного облікового запису має бути визначений відповідальний. Будь-яке використання break-glass облікового запису має створювати попередження з рівнем критичності 0.
Як Netwrix допомагає контролювати привілейованих користувачів
Netwrix розподіляє ці завдання між чотирма продуктами, кожен із яких відповідає за окремий етап.
Netwrix Access Analyzer відповідає за виявлення привілейованого доступу, а Netwrix Privilege Secure — за його скорочення.
Далі Netwrix Auditor і Netwrix Threat Manager закривають дві складові роботи з доказами: збереження історії змін у середовищі та виявлення поведінки, що відхиляється від усталеного профілю облікового запису.
Виявлення фактичних привілеїв поза межами членства в групах
Netwrix Access Analyzer автоматично визначає актуальні права для доменів Active Directory, OU, груп, користувачів і комп’ютерів.
Звіт про актуальні права враховує вкладене членство в групах і права, надані через ACL, щоб показати фактичний доступ облікового запису. Паралельно система також виявляє застарілі облікові записи.
Цей перелік далі використовується для скорочення прав, оскільки саме по собі виявлення без подальшого зменшення привілеїв лише розширює обсяг моніторингу.
Заміна постійного привілейованого доступу доступом для конкретного завдання
Netwrix Privilege Secure є рішенням для керування привілейованим доступом, яке замінює постійні адміністративні права доступом, обмеженим конкретним завданням.
Для цього створюється Activity Token, унікальний тимчасовий обліковий запис, який існує лише протягом виконання однієї активності.
Після завершення завдання Netwrix Privilege Secure видаляє цей обліковий запис. У результаті між використаннями не залишається постійних облікових даних із підвищеними правами.
У Eastern Carver County Schools постійні привілейовані облікові записи було прибрано з керування мережевими комутаторами, VMware та системами відеоспостереження, які обслуговують 9 300 учнів і понад 2 000 співробітників.
Натомість було впроваджено тимчасовий доступ, який автоматично припиняється після завершення завдання. Команда завершила впровадження за кілька днів.
Фіксація змін прав і налаштувань зі значеннями до та після
Повторна сертифікація прав і ретроспективний аудит залежать від можливості відновити стан середовища на певний момент у минулому.
Netwrix Auditor є рішенням для IT-аудиту та звітності про відповідність, яке контролює Active Directory, Group Policy, Entra ID, Exchange, файлові сервери та SQL Server.
Система фіксує, хто, що, коли і звідки змінив, а також зберігає значення до та після зміни.
Звіти State-in-Time дають змогу відновити конфігурацію на вибраний момент на основі щоденних знімків стану.
Для формування звіту за минулу дату відповідний історичний знімок спочатку потрібно імпортувати.
Виявлення аномальної поведінки привілейованих і сервісних облікових записів
Формування базової поведінки — один з етапів, який команди найчастіше відкладають. Netwrix Threat Manager автоматизує цей процес.
Рішення для виявлення загроз і реагування на рівні облікових записів виявляє поведінку привілейованих і сервісних облікових записів, яка відхиляється від усталеного профілю.
Виявлення аномальної поведінки починається після того, як обліковий запис був активним щонайменше 30 днів.
Для формування базового профілю система використовує до 120 днів активності та повторно оцінює кожного користувача кожні 15 хвилин.
Якщо відхилення перевищує задане порогове значення, створюється запис про загрозу для подальшого розслідування.
У більшості випадків практичніше оцінювати не окремий інструмент, а те, які етапи програми вже реалізовані.
Netwrix Access Analyzer, Netwrix Privilege Secure, Netwrix Auditor і Netwrix Threat Manager відповідають кожен за окремий етап цього процесу.
Покриття заходів CISA щодо облікових записів
CISA Eviction Strategies Tool містить перелік заходів протидії після компрометації, кожен із яких має окремий ідентифікатор.
П’ять із них безпосередньо стосуються привілейованих і неактивних облікових записів, і для кожного передбачено відповідний продукт Netwrix:
- Видалення зайвих і неактивних облікових записів (CM0112): Netwrix Access Analyzer виявляє вимкнені та неактивні облікові записи користувачів і автоматизує їх очищення.
- Моніторинг прав користувачів, сервісних і адміністративних облікових записів (CM0043): Netwrix Access Analyzer враховує вкладені групи та права, надані через ACL, щоб показати актуальні права кожного облікового запису.
- Моніторинг створення облікових записів і змін прав (CM0044): Netwrix Auditor фіксує створення нових облікових записів і зміни членства в групах безпеки з даними про те, хто, що, коли та де змінено.
- Аудит об’єктів групової політики в Active Directory (CM0085): Netwrix Auditor фіксує зміни Group Policy зі значеннями до та після.
- Розслідування підозрілих спроб входу (CM0063): Netwrix Threat Manager виявляє аномальні автентифікації на основі базового профілю кожного облікового запису.
Перетворення адміністративної довіри на дані, які можна перевірити
Система авторизації продовжуватиме дозволяти використання дійсних облікових даних незалежно від того, хто стоїть за ними — адміністратор чи зловмисник, який отримав їх унаслідок фішингової атаки.
Саме моніторинг дає змогу розрізнити ці два сценарії. Але ефективним він стає лише як частина цілісної програми.
Така програма включає повний перелік привілейованих облікових записів, скорочення поверхні атаки, формування базової поведінки, виявлення змін прав між перевірками, кореляцію попереджень замість нескінченної черги окремих подій і захист доказів від непомітного редагування адміністраторами, дії яких вони фіксують.
Аудитори, керівництво та кіберстрахові компанії дедалі частіше очікують саме такого підтвердженого запису, а не просто політики, у якій зазначено, що інструмент моніторингу існує.
Різниця між цими двома рівнями усувається поетапно — починаючи з етапу, який у поточній програмі ще не реалізований.
