Статья Защита от инсайдерских угроз: access review, offboarding и политики ИБ на практике

За последний год я провёл access review в четырёх организациях - и в каждой нашёл активные учётки уволенных сотрудников с доступом к production. Рекорд: аккаунт человека, ушедшего 11 месяцев назад, с правами на чтение финансовых отчётов через SharePoint и действующим VPN-сертификатом. HR закрыл заявку в тот же день, IT получил тикет через неделю, а до IAM-команды информация не дошла вообще. Типовой сценарий: защита от инсайдерских угроз существует на бумаге, но рассыпается при первом касании с реальностью. Дальше - разбор того, какие организационные меры действительно разрывают цепочку инсайдерской атаки, с конкретными командами и запросами для SIEM.

Инсайдерские угрозы в организации через призму MITRE ATT&CK​

Русскоязычные материалы традиционно начинают с классификации - случайный инсайдер, преднамеренный, скомпрометированный. Для менеджерской презентации сойдёт, для построения insider threat программы - нет. Реальная проблема не в мотивации сотрудника, а в доступе, которым он располагает, и в скорости, с которой этот доступ можно отозвать.

Инсайдерская атака ложится на конкретные TTPs из MITRE ATT&CK:

• Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation) - использование легитимных учётных данных. Бывший сотрудник с неотключённым аккаунтом попадает сюда автоматически, без единого эксплойта.
• Account Manipulation (T1098, Persistence / Privilege Escalation) - изменение параметров существующего аккаунта: добавление в привилегированную группу, создание резервного пароля, назначение дополнительных ролей в Azure AD.
• Data from Information Repositories (T1213, Collection) - сбор данных из SharePoint, Confluence, внутренних wiki. Инсайдеру не нужен recon - он и так знает, где лежит ценное.
• Data from Local System (T1005, Collection) - копирование файлов с рабочей станции, включая кэшированные credentials и локальные бэкапы баз данных.
• Exfiltration to Cloud Storage (T1567.002, Exfiltration) - выгрузка через Google Drive, Dropbox, Яндекс.Диск.
• Exfiltration over USB (T1052.001, Exfiltration) - классический вектор для сотрудника с физическим доступом.
• Account Access Removal (T1531, Impact) - удаление или блокировка учёток коллег и данных. Инструмент саботажа при конфликтном уходе.

Ключевое отличие от внешнего атакующего: инсайдеру не нужен initial access. У него уже есть badge, VPN-сертификат и знание внутренней кухни. По данным ITU Online, инсайдер перемещается по сети, не вызывая тревоги, используя штатные инструменты и разрешения. Вся задача защиты - сузить окно возможностей через управление жизненным циклом учётных записей.

Kill chain инсайдера​

1. Доступ (T1078) - легитимные credentials, уже есть.
2. Навигация (T1213, T1005) - сотрудник знает структуру файловых серверов, расположение клиентской базы, путь к репозиторию с исходниками.
3. Сбор (T1025) - копирование на USB или промежуточное хранилище.
4. Эксфильтрация (T1052.001, T1567.002) - вынос через USB или cloud storage.
5. Саботаж (T1531, опционально) - удаление данных, блокировка коллег, уничтожение бэкапов.

Эту цепочку не разрывает EDR и не останавливает антивирус. Её ломают access control, мониторинг аномального поведения и offboarding-процедура с SLA в один час.

Политики информационной безопасности: минимальный рабочий набор​

Конкуренты пишут "разработайте политику безопасности данных" без единого примера содержимого. NIST SP 800-53 (контроли AC-1, AT-1, AU-1, IR-1) требует документирования политик access control, awareness & training, audit & accountability и incident response. Но документ - это 20% результата. Остальные 80% - автоматизация исполнения.

Принцип минимальных привилегий - не декларация, а процесс:

• Каждая роль описана набором конкретных прав. Не "доступ к CRM", а "read-only к объектам Contact в Salesforce, region = RU". На внутреннем пентесте первое, что я проверяю, - расхождение между заявленной ролевой моделью и реальными правами в AD. Расхождение критическое в девяти из десяти случаев.
• Временный доступ (just-in-time) для привилегированных операций. В Azure AD это Privileged Identity Management (PIM): административная роль активируется на 4 часа, затем автоматически деактивируется. В CyberArk - аналогичный механизм через Privileged Access Manager.
• Разделение обязанностей: человек, создающий платёжное поручение, не может его утверждать. Этот контроль ломает цепочку финансового мошенничества.

Процедура запроса доступа:

• Единая система (ServiceNow, Jira Service Management). Никаких "напиши Васе в Telegram, он выдаст доступ".
• Цепочка согласования: руководитель -> владелец ресурса -> ИБ (для sensitive ресурсов).
• SLA: 4 часа для стандартного запроса, 1 час для экстренного с post-approval.

Периодический ревью прав доступа: раз в квартал для обычных пользователей, раз в месяц для привилегированных.

Антипаттерн - политика без enforcement​

Видел неоднократно: политика прописана идеально, но в Okta до сих пор живут группы типа all-employees-full-access, а Active Directory содержит вложенные группы с membership, унаследованным от пяти реорганизаций. Политика без технического enforcement - документ для аудитора, не для безопасности. На пентесте такие расхождения находятся за первый час работы с BloodHound.

[Применимо: внутренний пентест, grey box / любая инфраструктура с IdP]

Ревью прав доступа: обнаружение privilege creep​

User access review - процедура, которую ненавидят все участники. Менеджеры - потому что нужно принимать решения. ИБ - потому что результаты удручающие. IT - потому что после ревью прилетает волна тикетов. Но это единственный способ обнаружить privilege creep: сотрудник за три года переходов между отделами накопил права пяти ролей, а старые никто не отозвал.

Шаг 1. Инвентаризация привилегированных аккаунтов. В AD - через Get-ADGroupMember -Identity "Domain Admins" -Recursive с экспортом в CSV. В Azure AD - через Get-MgDirectoryRoleMember для Global Administrator и Privileged Role Administrator.

Шаг 2. Сопоставление с HR-данными. Каждый привилегированный аккаунт проверяется: активен ли сотрудник, совпадает ли текущая должность с выданными правами. SailPoint IdentityIQ и Saviynt автоматизируют корреляцию HR-системы (1С:ЗУП, SAP HR) с IAM.

Шаг 3. Выявление аномалий:

• Аккаунт с Domain Admin у сотрудника не из IT.
• Учётная запись без логина более 30 дней, но с активными привилегиями.
• Membership в группах, не связанных с текущей должностью.
• Сервисные аккаунты с interactive logon - на внутреннем пентесте это один из первых векторов: сервисный аккаунт с паролем, не менявшимся три года, и правами Domain Admin.

Шаг 4. Решение и документирование. Каждая аномалия получает статус: подтверждено (доступ обоснован), отозвано, эскалировано (требуется расследование).

Мониторинг через SIEM​

Для детекции массовой выгрузки файлов из SharePoint - запрос в Microsoft Sentinel (нужен подключённый коннектор Office 365):

OfficeActivity
| where Operation in ("FileDownloaded", "FileSyncDownloadedFull")
| summarize DownloadCount = count() by UserId, bin(TimeGenerated, 1h)
| where DownloadCount > 50
| sort by DownloadCount desc

Порог 50 файлов в час - baseline, который нужно адаптировать под конкретную организацию. Без предварительного baseline запрос будет фонить ложными срабатываниями на сотрудниках, работающих с большими объёмами документов. В Splunk Enterprise 9.x+ аналогичная логика строится через index=o365 sourcetype="o365:management:activity" Operation="FileDownloaded" со stats count by UserId.

UEBA-решения (Microsoft Sentinel UEBA, Exabeam, Splunk UBA) автоматизируют построение baseline и снижают false positives, но требуют 2–4 недели обучения на данных. Первые две недели после включения - готовьтесь к потоку мусора.

[Ограничение: SIEM-запросы детектируют уже происходящую эксфильтрацию. Для предотвращения нужен DLP на endpoint, который блокирует массовое копирование до завершения. Kaspersky Endpoint Security, Microsoft Purview DLP и Solar Dozor закрывают этот вектор, но каждый со своими ограничениями по покрытию каналов.]

Offboarding процедуры безопасности: чеклист из 15 шагов​

Offboarding - самый критичный процесс с точки зрения предотвращения утечки данных сотрудниками. По данным JFrog, значительная часть инцидентов связана с бывшими сотрудниками, чей доступ не был отозван вовремя. NCSC фиксировала случаи, когда бывший подрядчик пытался саботировать работу компании после конфликтного увольнения.

Этот чеклист собран по результатам реальных расследований. Каждый пункт - ответ на конкретный провал.

Момент уведомления (HR -> IT/ИБ, SLA: 1 час):

1. HR уведомляет IT и ИБ одновременно, не последовательно. Задержка в цепочке HR -> менеджер -> IT - причина большинства инцидентов.
2. Оценить уровень риска: доступ к PII, финансам, исходникам -> повышенный мониторинг.
3. Включить enhanced logging для учётной записи в SIEM.

Последний рабочий день (до ухода сотрудника):

1. Деактивировать учётную запись AD: Disable-ADAccount -Identity $username.
2. Сбросить пароль на случайный - защита от кэшированных credentials на ноутбуке.
3. Удалить из всех групп AD кроме Domain Users (для сохранения аудитного следа).
4. Отозвать VPN-сертификат, удалить из RADIUS/NPS.
5. Деактивировать в IdP (Okta, Azure AD) - автоматически отзывает все SSO-сессии.
6. Отозвать OAuth-токены и API-ключи: Revoke-MgUserSignInSession -UserId $userId.
7. Удалить из MDM (Intune, Jamf) - remote wipe корпоративных данных с BYOD-устройств.

Физическая безопасность:

1. Забрать badge, ключ-карту, аппаратные токены (YubiKey, RSA SecurID).
2. Забрать корпоративное оборудование: ноутбук, телефон, внешние накопители.
3. Отозвать доступ к физическим помещениям (серверная, ЦОД).

Пост-увольнение (24 часа):

1. Проверить forwarding rules в почте - автопересылка на внешний адрес используется чаще, чем хотелось бы:

Get-InboxRule -Mailbox $username | Where-Object {
    $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo
}

1. Сохранить аудитный лог активности за последние 30–90 дней для возможного расследования.

Когда offboarding проваливается​

Реальный кейс: сотрудник подал заявление в пятницу. HR обработал в тот же день. IT получил тикет во вторник. За выходные сотрудник подключился через VPN, скопировал клиентскую базу из CRM на Яндекс.Диск (T1567.002) и удалил часть записей (T1531). Обнаружили через неделю, когда менеджеры пожаловались на пропажу контактов.

Причина банальна: нет автоматической связки между HR-системой и IdP. Если бы при изменении статуса в 1С:ЗУП автоматически срабатывал webhook к Okta или Azure AD - деактивация произошла бы за минуты, а не за четыре рабочих дня. Один webhook. Минуты вместо дней. А вместо этого - тикет в Jira, который три дня висел в бэклоге.

Security awareness обучение персонала: что реально работает​

Ежегодная презентация из 40 слайдов не меняет поведение. Сотрудники проходят тест, забывают содержание через неделю и продолжают открывать фишинговые письма. По данным AlertMedia, около половины инсайдерских инцидентов связаны с непреднамеренными действиями - мисконфигурациями, фишингом, некорректной обработкой данных. NIST SP 800-53 (AT-1) требует не просто наличия программы обучения, а её регулярного пересмотра и адаптации.

Фишинговые симуляции вместо лекций​

Контролируемые фишинговые рассылки - единственный метод, который формирует устойчивый навык распознавания. Платформы: KnowBe4 (международная), GoPhish (open-source, активный репозиторий на GitHub), Phishman (для российского рынка).

Процесс: рассылка контролируемых фишинговых писем -> трекинг кликов и ввода credentials -> автоматическое назначение дополнительного обучения для попавшихся.

Частота: раз в месяц первые полгода, затем раз в квартал. Содержание писем должно эволюционировать: от простого "обновите пароль" до таргетированных сценариев с реальным контекстом - имя руководителя, название проекта, внутренний жаргон. Именно таргетированные симуляции, имитирующие spear-phishing, выявляют реальную уязвимость организации. Шаблонные рассылки "вы выиграли iPhone" - пустая трата времени: их и так никто не кликает.

Формат 30-минутного разбора анонимизированного инсайдерского инцидента работает лучше любой презентации. Структура: что произошло -> как обнаружили -> что можно было сделать иначе -> какие контроли добавили. Люди запоминают истории, а не пункты регламента.

Критически важна культура "no blame": за сообщение "я кликнул на подозрительную ссылку" не должно следовать наказание. Если сотрудники боятся сообщать - время обнаружения инцидента вырастает с часов до месяцев.

Контроль привилегированного доступа: PAM как последний рубеж​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Insider threat программа - не проект с дедлайном и бюджетом на один инструмент. Это операционный процесс, который либо работает каждый день, либо не работает вообще.

За время работы с IAM и расследованием инсайдерских инцидентов я пришёл к выводу, который редко озвучивают: технологии - последнее, что нужно внедрять. DLP, PAM, UEBA бессмысленны, пока HR не отправляет уведомление об увольнении в ту же минуту, когда подписан приказ. Пока access review сводится к формальному обходу менеджеров с вопросом "вам ещё нужен этот доступ?", ответ будет "да" в 100% случаев - даже если сотрудник не помнит название системы.

Самый дорогой инсайдерский инцидент, который я разбирал, произошёл не из-за отсутствия DLP. DLP стоял и работал. Проблема - в ноутбуке, подключённом к корпоративному Wi-Fi, который не был интегрирован с IdP. Три инструмента безопасности стоимостью в десятки миллионов рублей оказались бесполезны, потому что один webhook из HR-системы в IdP не был настроен.

Формула рабочей программы проста: access review раз в квартал с автоматическими алертами на аномалии, offboarding в течение часа с полной деактивацией, фишинговые симуляции раз в месяц, PAM для всех привилегированных аккаунтов без исключений. Если хочешь посмотреть, как privilege escalation через валидные учётки разбирается на стенде - на HackerLab.pro (https://hackerlab.pro) есть задачи с аналогичной механикой.