От охранника к наблюдателю: связка предварительной и последующей защиты при аутентификации

By Mirko Peters · 2026-08-11

Добро пожаловать обратно в подкаст и в сопровождающий его технический разбор! Если вам когда-либо казалось, что в стратегии защиты удостоверений есть слепая зона сразу после того, как пользователь успешно вошёл в систему…

Automatically translated with AI from the original post. Read the English original

Добро пожаловать обратно в подкаст и в сопровождающий его технический разбор! Если вам когда-либо казалось, что в стратегии защиты удостоверений есть слепая зона сразу после того, как пользователь успешно вошёл в систему, вы определённо не одиноки. Долгие годы организации в значительной степени полагались на средства контроля до аутентификации, чтобы не пускать злоумышленников, и рассматривали входную дверь как последний рубеж защиты. Но что происходит, когда злоумышленник проникает через эту дверь с действительным токеном или украденной парой учётных данных? Именно эта дилемма стала центральной темой нашего недавнего эпизода Conditional Access with Defender for Identity Signals. В этой публикации мы подробнее разберём эти идеи и покажем, как объединить охранника до аутентификации с наблюдателем после неё, чтобы построить действительно устойчивую архитектуру удостоверений.

Главная идея (TL;DR)

Чтобы по-настоящему понимать современную защиту удостоверений, рассматривайте свои инструменты как специализированные роли, которые работают вместе в реальном времени:

• Conditional Access (CA) — это ваш вышибала. Он исключительно хорошо принимает решения до аутентификации на основании того, кто пытается войти, откуда и каково состояние его устройства.
• Defender for Identity (DfI) — это ваша система видеонаблюдения в сочетании с охраной помещений. Он отлично отслеживает поведение после аутентификации, горизонтальное перемещение и внутренние аномалии.
• Реальная устойчивость возникает только тогда, когда риск после аутентификации автоматически и динамически повышает трение до аутентификации — прямо здесь, в рамках сеанса.

Ментальная модель

Уточним ментальную модель того, как эти компоненты взаимодействуют в вашей экосистеме:

• Охранник (CA): оценивает, кто выполняет вход, откуда, состояние устройства, риск на момент входа, и применяет немедленные средства контроля сеанса.
• Наблюдатель (DfI + M365 Defender): выявляет горизонтальное перемещение, аномальные шаблоны доступа к ресурсам, Kerberoasting, злоупотребление NTLM и неожиданное повышение привилегий.
• Обратная связь: наблюдатель отмечает подозрительное поведение, что, в свою очередь, повышает оценку риска пользователя или риска сеанса. Это заставляет охранника немедленно ужесточить контроль: включить дополнительную проверку MFA, полностью заблокировать доступ или ограничить активный сеанс.

План интеграции (что включать и в каком порядке)

Чтобы эти системы работали согласованно, необходимо структурированное внедрение. Вот план, которому стоит следовать:

1. CA с учётом риска (базовый уровень)
   • Entra ID Protection: включите оценку риска пользователя и риска входа.
   • Создайте политики CA:
     • Блокировать, когда риск пользователя = высокий (или требовать смену пароля, если это поддерживают процессы вашей службы поддержки).
     • Требовать MFA, когда риск входа ≥ средний.
     • Требовать соответствующее требованиям устройство для приложений со средним и высоким уровнем конфиденциальности; используйте фильтры устройств для неуправляемых конечных точек, чтобы сразу направлять их в ограниченные средства контроля сеанса.
2. Позвольте наблюдателю общаться с охранником
   • Убедитесь, что DfI активно передаёт оповещения в Microsoft 365 Defender и Sentinel (если вы используете его для SIEM/SOAR).
   • Автоматизируйте действия "Подтвердить компрометацию" для пользователей по оповещениям DfI высокой степени важности. Это устанавливает риск пользователя = высокий в Entra ID Protection, и ваши политики CA мгновенно реагируют.
   • Путь автоматизации: инцидент M365 Defender → Logic App или Power Automate → Graph Security/Identity Protection API (/riskDetections, /riskyUsers:confirmCompromised) → по желанию принудительный выход.
   • Включите Continuous Access Evaluation (CAE) во всех поддерживаемых приложениях (Exchange, SharePoint, Graph), чтобы изменения политик действительно завершали действующие токены.
3. Контроль сеанса для локализации угрозы
   • Для неуправляемых или рискованных сеансов разверните Defender for Cloud Apps (прокси сеанса) непосредственно из CA:
     • CA → Use Conditional Access App Control (сначала мониторинг, затем блокировка утечки данных: загрузок, копирования и вставки, печати и синхронизации).
   • Сочетайте это с MDE device risk → Intune compliance → CA «Require compliant device» для всех чувствительных приложений.
4. Защитные ограничения для привилегированных учётных записей
   • PIM должен обеспечивать доступ по принципу Just-in-Time: перед повышением привилегий требуйте MFA + соответствующее требованиям устройство + отсутствие рискованного состояния пользователя.
   • Настройте политику CA, которая блокирует привилегированные роли при user risk ≥ Low (да, даже при низком риске), чтобы запустить немедленный анализ до того, как административная роль будет активирована.

«Если это, то то»: сопоставление сигналов DfI с действиями CA

Сопоставление конкретных сигналов обнаружения из Defender for Identity с автоматизированными действиями Conditional Access и реагирования соединяет пассивное наблюдение с активной защитой:

Начните с запуска этих правил в режиме audit/monitor на 1–2 недели, а затем переключайте реагирование в режим enforce для каждого класса оповещений по мере роста уверенности.

Примеры политик (практичные и минимальные)

Чтобы внедрить эти стратегии в работу, настройте четыре базовые политики:

1. Блокировать при user risk = High
   • Назначение: все пользователи (исключить учётные записи break-glass), все облачные приложения
   • Условия: User risk = High
   • Предоставление доступа: блокировать доступ
2. Step-up при риске входа
   • Назначение: все пользователи, приложения повышенной ценности (порталы администрирования, Exchange, SharePoint, Центр администрирования Entra)
   • Условия: Sign-in risk ≥ Medium
   • Предоставление доступа: требовать MFA + требовать соответствующее устройство (или управляемое устройство)
3. Ограничение сеанса для неуправляемых устройств
   • Назначение: все пользователи, SharePoint/OneDrive/Teams
   • Состояние устройства: Hybrid/Compliant = исключить из политики; Unmanaged = применять
   • Сеанс: использовать Conditional Access App Control (блокировать загрузку)
4. Защита повышения привилегий
   • Назначение: роли каталога = привилегированные административные роли
   • Условия: User risk ≥ Low ИЛИ Sign-in risk ≥ Medium
   • Предоставление доступа: требовать MFA + требовать соответствующее устройство; блокировать, если риск ≥ High

Готовые плейбуки автоматизации

Автоматизация — главный инструмент, который сокращает ваше среднее время сдерживания (MTTC). Вот два плейбука, которые можно создать уже сегодня:

Плейбук A: оповещение DfI высокой серьёзности → сдерживание идентификации

• Триггер: инцидент M365 Defender с меткой IdentityThreatHigh
• Действия:
  1. Graph API – подтвердить компрометацию пользователя (устанавливает User risk в High)
  2. Entra ID – немедленно отозвать refresh-токены
  3. Intune/MDE – изолировать устройство (если связано одно основное устройство)
  4. ServiceNow/JSM – создать инцидент с хронологией и собранными артефактами
  5. Уведомить SOC и владельца учётной записи через адаптивную карточку Teams с кнопкой отката одним нажатием на случай ложных срабатываний

Плейбук B: всплеск аномального доступа к SharePoint

• Триггер: оповещение Defender «Unusual file download»
• Действия:
  1. Пометить пользователя меткой UnderInvestigation через расширенные атрибуты AAD
  2. Перевести пользователя в политику CA, которая направляет его в App Control (блокировка загрузки и печати)
  3. Запустить eDiscovery-хold для затронутых сайтов SharePoint (необязательно, в зависимости от требований соответствия)
  4. Автоматически снимать сдерживание через 72 часа, если SOC не продлит его вручную

Поиск угроз и полезные запросы

Проактивный поиск угроз помогает обнаружить пробелы до того, как ими воспользуются атакующие. Используйте эти запросы в расширенной охоте M365 Defender (Advanced Hunting):

Всплеск доступа пользователя к сайтам SharePoint по сравнению с его 30-дневным базовым профилем:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

Всплески риска входа, тесно связанные с последующими оповещениями DfI:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

Метрики, которые подтверждают эффективность

Когда вы докладываете руководству, нужны метрики, которые показывают реальное снижение рисков. Отслеживайте следующие ключевые показатели эффективности (KPI):

• Mean Time To Contain (MTTC) для инцидентов с идентификацией (время от генерации оповещения до применения политики условного доступа) ↓
• Время пребывания атакующего (время от первого подозрительного действия до полного устранения последствий) ↓
• Заблокированные рискованные сеансы (события, на которых сработала политика) ↑ при одновременном снижении доли ложных срабатываний ↓
• Возраст очереди рискованных пользователей (открытые случаи старше 24 часов) ↓
• Задержка отзыва токенов (измеряется в секундах) ↓
• Сбои повышения привилегий из-за риска (выявленные на ранней стадии, до нанесения ущерба) ↑, а затем стабилизация со временем
• Secure Score по Identity, Devices и Apps ↑ при отсутствии соответствующего всплеска обращений в службу поддержки

Стратегия внедрения 30/60/90

Не пытайтесь изменить всё за одну ночь. Используйте следующий поэтапный план:

Дни 0–30 (основа)

• Включите параметры риска пользователя и риска входа в Entra и разверните базовые политики условного доступа в режиме аудита, а затем переведите их в режим применения.
• Подключите Defender for Identity к M365 Defender; проверьте оповещения и сопоставление основных сущностей.
• Включите Continuous Access Evaluation (CAE) для поддерживаемых приложений и интегрируйте риск устройства из MDE с соответствием требованиям Intune.

Дни 31–60 (обратная связь и локализация угроз)

• Создайте сценарии реагирования A и B в Logic Apps и тщательно протестируйте их в состоянии dry-run.
• Запустите пилот App Control для неуправляемых сеансов с 2–3 совместными бизнес-командами.
• Внедрите политику ограничения повышения привилегий в PIM.

Дни 61–90 (применение и измерение)

• Переведите автоматизированные сценарии реагирования в режим полного применения для оповещений с высокой степенью достоверности.
• Создайте книгу по безопасности идентификации (в Sentinel или Power BI), отслеживающую перечисленные выше метрики.
• Проводите ежеквартальные учения purple team, чтобы проверить ваш MTTC, скорость отзыва токенов и переключение политик условного доступа в боевом сценарии.

Типичные ошибки (и более безопасные настройки по умолчанию)

Остерегайтесь следующих распространённых ошибок при внедрении:

• Ошибка: опора только на риск входа в условном доступе → Исправление: реагируйте также на риск пользователя и оповещения DfI, поступающие после аутентификации.
• Ошибка: CAE не настроен, из-за чего устаревшие токены поддерживают скомпрометированные сеансы → Исправление: включите CAE и встройте отзыв токенов непосредственно в автоматизированные сценарии реагирования.
• Ошибка: массовая блокировка загрузки файлов во всей организации, что вызывает недовольство пользователей → Исправление: применяйте App Control выборочно, только когда сеансы неуправляемые или рискованные.
• Ошибка: шквал оповещений и ложные срабатывания из-за агрессивных автоматических сценариев компрометации → Исправление: ставьте автоматизацию за многосигнальной проверкой (например, высокое оповещение DfI + необычный объём загрузок + доступ в нерабочее время).
• Ошибка: аварийные учётные записи (break-glass) случайно блокируются автоматическими политиками риска → Исправление: исключите две тщательно контролируемые аварийные учётные записи и меняйте их учётные данные ежеквартально.

Готовые фрагменты для копирования

Чтобы донести эти изменения до всей организации, используйте следующие готовые фрагменты:

Краткое резюме для руководителей (CAB):

Мы успешно связали поведение пользователя после входа с решениями контроля доступа. Если учётная запись начинает вести себя необычно, мы добавляем дополнительную проверку безопасности или блокируем доступ прямо во время сеанса. Это существенно сокращает время пребывания атакующего, не замедляя обычную повседневную работу.

Примечание к изменениям для администраторов:

• Новые политики условного доступа могут запрашивать повышенную проверку MFA или блокировать доступ при обнаружении аномального риска. Активные токены аутентификации теперь можно отзывать во время сеанса на основании телеметрии. Аварийные учётные записи явно исключены из действия политик. Пожалуйста, отслеживайте книгу Identity Resilience для анализа влияния.

Карточка уведомления в Teams для владельцев (автоматическая):

• «Мы заметили необычную активность с файлами из вашей учётной записи. Мы применили временные меры защиты (например, отключили загрузку на неуправляемых устройствах). Если это были вы, просто нажмите Acknowledge; если нет, немедленно нажмите Report.»