- Что такое мониторинг привилегированных пользователей?
- Почему привилегированные учетные записи сложнее всего отслеживать?
- Что должен охватывать мониторинг привилегированных пользователей?
- Как построить программу мониторинга привилегированных пользователей
- Требования соответствия к мониторингу привилегированных пользователей
- Распространенные сложности и способы их преодоления
- Как Netwrix помогает контролировать привилегированных пользователей
- Определение фактических привилегий за пределами членства в группах
- Замена постоянного привилегированного доступа доступом для конкретной задачи
- Фиксация изменений прав и конфигурации со значениями до и после
- Выявление аномального поведения привилегированных и сервисных учетных записей
- Покрытие контрмер CISA для учетных записей
- Превращение административного доверия в проверяемые данные
Для выполнения операционных задач необходим повышенный уровень доступа, и организации обычно предоставляют его на основе доверия. Мониторинг привилегированных пользователей превращает это доверие в подтверждаемые данные.
Запись об авторизации подтверждает только то, что система разрешила определенное действие. Мониторинг создает доступную для проверки запись о том, какие повышенные права использовались, кем и когда. Благодаря этому аудиторы и специалисты по расследованию могут проверять привилегированную активность, не вмешиваясь в повседневную работу администраторов.
Постоянный привилегированный доступ по-прежнему широко распространен. Согласно исследованию, на котором основан отчет Netwrix о безопасности данных и учетных записей за 2026 год, 67% организаций предоставляют постоянный привилегированный доступ по крайней мере для некоторых ролей.
Эти права остаются активными даже между задачами, для выполнения которых они были первоначально предоставлены. Мониторинг привилегированных пользователей позволяет устранить этот разрыв.
Участник группы Domain Admins имеет право выполнять действия в пределах соответствующей зоны управления Active Directory. С точки зрения системы такой доступ выглядит одинаково независимо от того, используются ли учетные данные настоящим администратором инфраструктуры или злоумышленником, который получил их, например, с помощью фишинга.
Успешная авторизация подтверждает наличие разрешения и ничего более. Законность намерений и наличие реальной рабочей необходимости требуют отдельных подтверждений.
Мониторинг предоставляет такие подтверждения и усиливает контроль доступа, не замедляя административные процессы, от которых зависит работа организации.
Что такое мониторинг привилегированных пользователей?
Мониторинг привилегированных пользователей непрерывно фиксирует и анализирует то, как доверенные учетные записи используют повышенные права. Его цель состоит в том, чтобы каждое привилегированное действие можно было отследить и впоследствии проверить.
Национальный институт стандартов и технологий США (NIST) определяет привилегированного пользователя как лицо, которое имеет разрешение, а следовательно, и соответствующий уровень доверия для выполнения функций безопасности, недоступных обычным пользователям.
При этом речь идет не только о людях-администраторах. Сервисные учетные записи, управляемые учетные записи и учетные записи автоматизации также относятся к этой категории, если им предоставлены повышенные права.
Мониторинг также не должен ограничиваться локальным каталогом. Административные права могут существовать в Active Directory, облачных платформах управления учетными записями, консолях администрирования SaaS и базах данных. Любая учетная запись с таким уровнем полномочий должна входить в область мониторинга.
Почему привилегированные учетные записи сложнее всего отслеживать?
Средства авторизации отвечают на достаточно узкий вопрос: имеет ли определенная учетная запись право выполнить конкретное действие. Для привилегированной учетной записи, действующей в пределах своих разрешений, ответ обычно будет положительным.
Проблема заключается в том, что четыре технические особенности могут скрывать за таким формально корректным разрешением гораздо больше, чем оно показывает.
Действительные учетные данные делают обычное администрирование и атаку внешне одинаковыми
После того как каталог подтверждает необходимые права, дальнейшая активность выглядит для системы нормальной. Вход выполняется успешно, членство в группах принимается, а доступ к ресурсу предоставляется, поскольку сами учетные данные являются действительными.
Одинаковая последовательность действий наблюдается и тогда, когда учетные данные принадлежат настоящему администратору, и тогда, когда они были похищены, например, с помощью фишинга.
Техника MITRE T1078.002 описывает именно такой сценарий: использование действительных учетных данных доменной учетной записи для первоначального доступа, закрепления в системе, повышения привилегий и обхода средств защиты.
Согласно исследованию, на котором основан отчет Netwrix о безопасности данных и учетных записей за 2026 год, 73,78% организаций не полностью уверены в том, что в их средах Active Directory отсутствуют ошибочные настройки, которые могут способствовать повышению привилегий.
Каждая такая ошибка конфигурации создает еще один потенциальный путь к позиции, которой среда уже доверяет.
Формальные запросы к группам не учитывают вложенное членство
Атрибут Active Directory memberOf отображает только прямые связи с группами и не показывает права, полученные через вложенные группы.
Поэтому прямой запрос к Domain Admins или другой привилегированной группе не выявит пользователей, которые получили соответствующие права через вложенное членство.
Проверка доступа, основанная только на прямом членстве, с самого начала охватывает неполный набор учетных записей и в результате подтверждает права не той совокупности пользователей.
ACL создают теневых администраторов вне привилегированных групп
Списки контроля доступа могут предоставлять чувствительные права так называемым теневым администраторам, то есть учетным записям, которые вообще не входят ни в одну привилегированную группу каталога.
Особенно важный пример заключается в наличии права изменять состав группы. Учетная запись с таким разрешением может самостоятельно добавить себя в эту группу.
Такое поведение предусмотрено самой архитектурой системы. Это не отдельная функция, которую можно просто отключить.
Права через 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 для устаревших учетных записей конкретное значение остается на усмотрение организации, однако в качестве примера используется возраст пароля 180 дней.
Учетные записи поставщиков требуют такого же уровня контроля, как и учетные записи сотрудников, которые покидают организацию.
Документ CISA Cross-Sector Cybersecurity Performance Goals 2.0, опубликованный в декабре 2025 года, объединяет цель, связанную с рисками поставщиков управляемых услуг, с требованием отключать все учетные записи и пути доступа в день ухода человека из организации.
Чем отличается мониторинг привилегированных пользователей от других видов мониторинга?
Эти три средства контроля часто путают, поскольку все они связаны с действиями администраторов. Однако каждое из них имеет разный охват и отвечает на отдельный вопрос.
| Параметр | Мониторинг привилегированных пользователей | Управление привилегированными сессиями | Мониторинг активности пользователей |
| Охват | Привилегированная учетная запись и ее права доступа | Отдельная привилегированная сессия | Все пользователи организации |
| Период наблюдения | Непрерывно, с формированием базового профиля поведения в течение недель или месяцев | Продолжительность одного подключения | |
| На какой вопрос отвечает | Соответствуют ли поведение этой учетной записи и набор ее прав ожидаемой норме? | Что произошло во время этой сессии? | Может ли активность этого пользователя указывать на инсайдерскую угрозу? |
| Основной результат | Базовый профиль поведения, оценка риска, предупреждения об аномалиях, отчеты о правах доступа | Запись сессии, журнал нажатий клавиш, индекс для расследования | Данные о содержимом экрана и нажатиях клавиш всех сотрудников |
| Запись содержимого | Необязательная | Стандартная | Стандартная |
Управление привилегированными сессиями контролирует само подключение и изолирует учетные данные от конечного пользователя. Поэтому наиболее подробными его записями являются записи сессий и журналы нажатий клавиш.
Такие журналы фиксируют все, что вводится во время сессии, включая пароли и персональные данные. Поэтому необходимы строгие сроки хранения и контроль доступа. Специалистам по расследованию также нужен структурированный журнал команд вместе с записями сессий, поскольку поиск одного действия путем просмотра видеозаписи не масштабируется.
Мониторинг активности пользователей применяет такой же тип фиксации содержимого ко всему персоналу для выявления инсайдерских угроз в соответствии с определением UAM от NIST.
Рекомендации британского 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. Определение нормальной административной активности для каждой роли
Попытки аутентификации, запросы доступа, изменения привилегий и изменения каталога должны передаваться на платформу Identity Threat Detection and Response.
Вместо оценки каждого отдельного подключения такая платформа может формировать поведенческий профиль для каждой учетной записи и соответствующей группы похожих пользователей.
Поведенческая аналитика и корреляция сигналов позволяют выявлять закономерности, которые не обнаруживаются правилами для отдельных событий. Такой же общий принцип используется в механизмах обнаружения Microsoft Defender for Identity.
Для нового администратора или недавно созданной сервисной учетной записи сигналы обычно менее надежны в течение первых нескольких недель. Качество базового профиля повышается по мере накопления дополнительной активности.
4. Отслеживание изменений прав между проверками
Текущие права должны сравниваться с последним подтвержденным состоянием и между циклами проверки, а не только во время формальной сертификации.
Периодические проверки отражают ситуацию только в конкретный момент времени. Новое право, предоставленное через неделю после завершения кампании проверки, может оставаться без контроля до следующего цикла.
Поэтому каждое право, добавленное после последней сертификации, должно отмечаться отдельно. В таком случае ежегодная проверка подтверждает то, что мониторинг уже обнаружил, а не остается единственным средством контроля.
5. Предупреждения об отдельных изменениях и корреляция закономерностей
Немедленные предупреждения следует использовать только для небольшого числа событий, которые сами по себе редко бывают допустимыми.
Все остальные события следует анализировать в совокупности.
Большинство атак становится заметным только тогда, когда несколько менее значимых сигналов возникают последовательно. Например, необычный вход может сопровождаться изменением привилегий, а затем доступом к системе, которую эта учетная запись ранее никогда не использовала.
Поэтому правила для отдельных событий и поведенческая корреляция должны быть частью единой модели обнаружения, а не рассматриваться как конкурирующие подходы.
6. Защита доказательств от администраторов, действия которых они фиксируют
Самым безопасным допущением является то, что контролируемые администраторы могут изменить записи о собственной активности, если архитектура не препятствует этому.
Членство в Domain Admins по умолчанию также добавляет учетную запись в локальную группу Administrators на каждом компьютере, присоединенном к домену. Это дает ей возможность просматривать журнал Security и полностью его очищать.
Контроль NIST SP 800-53 AU-9(4) направлен именно на этот риск. Если привилегированные пользователи одновременно являются объектами аудита, они могут снизить надежность доказательств, отключив журналирование или изменив записи аудита.
Ограничения доступа к журналам с помощью ACL недостаточно, чтобы остановить администратора домена с соответствующим уровнем прав.
При наличии SeTakeOwnershipPrivilege такой администратор может стать владельцем объекта, а затем изменить его discretionary access control list (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.
Кроме того, учитываются два европейских нормативных документа: имплементационный регламент, связанный с Network and Information Systems Directive 2 (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 требует пересматривать права доступа не реже одного раза в шесть месяцев для систем, поддерживающих критические или важные функции, и не реже одного раза в год для всех остальных систем. |
HHS предложило масштабное обновление HIPAA Security Rule в январе 2025 года, однако эти изменения по-прежнему остаются только предложением. В текущем регуляторном плане окончательное решение ожидается в июле 2027 года.
В предложенной версии требование по средствам аудита должно быть перенесено из 164.312(b) в 164.312(d)(1) и распространяться на все соответствующие системы, а не только на системы, которые хранят ePHI.
Пока HHS окончательно не утвердило изменения, действующей остается ссылка на 164.312(b).
Практическое ограничение готовности к аудиту становится заметным тогда, когда организации необходимо восстановить привилегированное действие, совершенное несколько месяцев назад. Возможность сделать это напрямую зависит от того, как долго сохранялись соответствующие доказательства.
Microsoft Entra ID в рамках стандартных сроков хранения сохраняет журналы аудита и входов 7 дней для тарифа Free и 30 дней для P1 и P2.
Для сравнения, PCI DSS Requirement 10.5.1 требует сохранять двенадцать месяцев истории журналов аудита, причем данные за последние три месяца должны быть немедленно доступны для анализа.
Поэтому стандартных сроков хранения обычно недостаточно. На практике именно коллектор, который получает пересылаемую копию журналов, становится основным источником записей.
Распространенные сложности и способы их преодоления
Основные сложности здесь имеют организационный и операционный характер. Простая замена одного инструмента другим редко решает их сама по себе.
- Администраторы могут воспринимать мониторинг как проявление недоверия со стороны организации, а некоторые могут пытаться его отключить. Контроль должен оставаться за пределами администрируемого домена, поэтому журналы следует передавать в систему, к которой контролируемые администраторы не имеют доступа. До внедрения мониторинга необходимо также объяснить связь этих средств контроля с угрозами, направленными на привилегированные учетные данные. Ограниченные по времени права, назначенные конкретным администраторам, сохраняют возможность индивидуальной атрибуции и при этом не предполагают автоматического отношения к администраторам как к подозреваемым.
- Обычная привилегированная активность может создавать такой объем событий, что значимые предупреждения теряются среди них. Обнаружение следует строить вокруг отклонений от сформированного базового профиля, а не создавать предупреждение на каждое отдельное событие. Разработка механизмов обнаружения также должна учитывать тактики, техники и процедуры (TTP). Это позволяет исключать известную административную активность, например утвержденный скрипт обновления, вместо создания ненужной эскалации.
- Общие, аварийные и учетные записи поставщиков усложняют индивидуальную атрибуцию, а аварийные учетные записи могут намеренно не иметь постоянного владельца. В соответствии с CIS Control 5 следует использовать отдельные административные учетные записи, а сервисные учетные записи проверять не реже одного раза в квартал. Для каждой сервисной учетной записи должен быть определен владелец. Каждое использование учетной записи break-glass должно создавать предупреждение уровня severity 0.
Как Netwrix помогает контролировать привилегированных пользователей
Netwrix распределяет эти задачи между четырьмя продуктами, каждый из которых поддерживает отдельный этап процесса.
Netwrix Access Analyzer отвечает за выявление прав, а Netwrix Privilege Secure помогает сокращать количество постоянных привилегий.
Netwrix Auditor и Netwrix Threat Manager охватывают две стороны проблемы доказательств: сохранение исторической информации об изменениях в среде и выявление поведения, которое отклоняется от сформированного профиля учетной записи.
Определение фактических привилегий за пределами членства в группах
Netwrix Access Analyzer автоматически определяет фактические разрешения для доменов Active Directory, OU, групп, пользователей и компьютеров.
Отчет об актуальных правах объединяет вложенное членство в группах и права, предоставленные через ACL, чтобы показать, какие разрешения учетная запись фактически имеет. Тот же процесс помогает выявлять устаревшие учетные записи trustee.
Этот перечень затем используется для сокращения привилегий, поскольку простое выявление большего количества привилегированных учетных записей без удаления лишних прав лишь увеличивает число объектов, которые необходимо контролировать.
Замена постоянного привилегированного доступа доступом для конкретной задачи
Netwrix Privilege Secure является решением для управления привилегированным доступом, которое заменяет постоянные административные права доступом, ограниченным конкретной задачей.
Для этого создается Activity Token, уникальная временная учетная запись, которая существует только в течение выполнения одной активности.
После завершения задачи временная учетная запись автоматически удаляется, поэтому между сессиями не остается активных постоянных учетных данных с повышенными правами.
В Eastern Carver County Schools постоянные привилегированные учетные записи были исключены из администрирования сетевых коммутаторов, VMware и систем камер безопасности в среде, которая обслуживает 9 300 учащихся и более 2 000 сотрудников.
Вместо них организация внедрила временный доступ, срок действия которого завершается после выполнения назначенной задачи. Развертывание было завершено в течение нескольких дней.
Фиксация изменений прав и конфигурации со значениями до и после
Повторная сертификация и ретроспективный аудит требуют возможности восстановить то, как среда была настроена в определенный момент в прошлом.
Netwrix Auditor является решением для IT-аудита и отчетности о соответствии, которое контролирует Active Directory, Group Policy, Entra ID, Exchange, файловые серверы и SQL Server.
Для каждого зарегистрированного изменения оно фиксирует, кто внес изменение, что именно было изменено, когда это произошло и откуда было выполнено действие. Запись также сохраняет значения до и после изменения.
State-in-Time reports позволяют восстановить конфигурацию на выбранный момент времени с использованием ежедневных снимков.
Для формирования отчета за историческую дату сначала необходимо импортировать соответствующий исторический снимок.
Выявление аномального поведения привилегированных и сервисных учетных записей
Формирование поведенческого базового профиля часто является одним из последних элементов, которые команды безопасности внедряют на практике. Netwrix Threat Manager автоматизирует этот этап.
Платформа анализирует активность привилегированных и сервисных учетных записей и выявляет поведение, которое выходит за пределы уже сформированного профиля.
Обнаружение аномального поведения начинается после того, как учетная запись была активна не менее 30 дней.
Для формирования базового профиля может использоваться до 120 дней исторической активности.
После этого система повторно оценивает каждого пользователя с интервалом 15 минут.
Если активность выходит за пределы настроенного порога, Netwrix Threat Manager создает запись об угрозе для дальнейшего расследования.
На этом этапе более практичный вопрос обычно заключается не в том, какой именно продукт нужно внедрить, а в том, какие части общей программы уже реализованы.
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 выявляет аномальную активность аутентификации относительно сформированного базового профиля каждой учетной записи.
Превращение административного доверия в проверяемые данные
Система авторизации продолжит принимать действительные учетные данные независимо от того, использует ли их настоящий администратор или злоумышленник, который получил их с помощью фишинга.
Мониторинг предоставляет доказательства, позволяющие различить эти две ситуации, однако он эффективно работает только как часть более широкой программы.
Полная программа объединяет несколько средств контроля: полный перечень привилегированных учетных записей, уменьшенную поверхность атаки, поведенческие базовые профили, выявление изменений прав между формальными проверками, коррелированные предупреждения вместо неуправляемой очереди событий, а также данные аудита, которые контролируемые администраторы не могут незаметно изменить.
Аудиторы, советы директоров и киберстраховщики все чаще ожидают именно такие подтверждаемые записи, а не просто политику, в которой указано, что организация использует инструмент мониторинга.
Разрыв между этими двумя уровнями устраняется поэтапно, начиная с той части текущей программы, которая еще не реализована.
