Усиливаем Zero Trust с помощью Continuous Access Evaluation (CAE)

By Mirko Peters · 2026-08-11

Добро пожаловать обратно в подкаст и в наш продолжающийся глубокий разбор архитектуры безопасности идентификации. Если вы когда-либо развертывали новую, непробиваемую политику условного доступа в Microsoft Entra ID, а потом наблюдали, как скомпрометированный пользователь или устройство, не соответствующее политике, продолжают спокойно работать ещё восемь часов, — вы не одиноки. Администраторы иден

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

Добро пожаловать обратно в подкаст и в наш продолжающийся глубокий разбор архитектуры безопасности идентификации. Если вы когда-либо развертывали новую, непробиваемую политику условного доступа в Microsoft Entra ID, а потом наблюдали, как скомпрометированный пользователь или устройство, не соответствующее политике, продолжают спокойно работать ещё восемь часов, — вы не одиноки. Администраторы идентификации сталкиваются с этой неприятной реальностью каждый день. Секрет того, как Microsoft 365 обрабатывает аутентификацию, в том, что границы вашей безопасности настолько сильны, насколько сильны ваши токены. Политики сами себя не применяют; это делают токены.

В этом подробном материале мы расширим тему нашего недавнего разговора в подкасте и разберём, как Continuous Access Evaluation (CAE) меняет правила игры. Отказавшись от статичных токенов и перейдя к отзыву в реальном времени, управляемому событиями, вы можете существенно сократить окно подверженности риску в вашей организации. Чтобы разобраться в базовых механизмах того, как эти токены работают под капотом, обязательно послушайте наш сопутствующий выпуск: Modern Authentication and Token Lifecycle in Microsoft 365.

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

• Политики сами себя не применяют — это делают токены. Условный доступ оценивается при выдаче или обновлении токена. Существующие токены сохраняют доверие «вчерашнего дня», пока вы не инициируете повторную оценку.
• MSAL незаметно обменивает токены доступа на токены обновления, а CAE может аннулировать их прямо во время сеанса, когда меняются риск или контекст.
• Чтобы изменения «сработали сразу», нужно воздействовать на жизненный цикл токенов (частота входа, отзыв токенов обновления, CAE, элементы управления сеансом).

Простая ментальная модель

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

• Токен доступа (AT): гостевой пропуск с коротким сроком действия (обычно около 1 часа), который открывает доступ к определённым помещениям.
• Токен обновления (RT): браслет с более длительным сроком действия (дни или недели), который позволяет запрашивать новые гостевые пропуска на стойке регистрации без прохождения проверки на входе каждый раз.
• MSAL: внутренний курьер, который полностью незаметно для вас обменивает токен обновления на новый токен доступа.
• Условный доступ (CA): движок политик-вышибалы, который проверяет ваши учётные данные и контекст строго в момент выдачи AT/RT (а также во время событий CAE).
• CAE (Continuous Access Evaluation): современное обновление протокола, которое позволяет Azure AD активно отзывать доступ прямо во время сеанса, если риск возрастает, устройство становится несоответствующим, местоположение пользователя меняется недопустимым образом или учётная запись пользователя отключается.

Почему новая политика не сработала сегодня

Один из самых распространённых обращений в службу поддержки после обновления политики безопасности звучит так: «Я только что заблокировал определённые страны, но пользователь X всё равно скачивает файлы из неуправляемой сети!» Почему так происходит? Ответ кроется в кэшировании токенов.

• У пользователей уже есть действительные AT; повторная оценка не происходит, пока токен естественным образом не истечёт.
• RT, выданные до вашего изменения, продолжают работать без сбоев до тех пор, пока:
  • RT не будет предъявлен повторно во время обычного тихого обновления, или
  • Вы активно отзываете сеансы и токены обновления, либо
  • CAE не инициирует принудительную повторную проверку.
• Мобильные и настольные приложения (такие как Microsoft Teams, Outlook и OneDrive) активно кэшируют и незаметно обновляют токены, что непреднамеренно продлевает жизнь этого «старого» окна действия политики.

Рычаги управления (в порядке приоритета)

1. Включите CAE для поддерживаемых поставщиков ресурсов (Exchange Online, SharePoint Online, Microsoft Graph и Teams).
   • Эффект: изменения политик и рисков могут немедленно аннулировать токены во время сеанса.
2. Настройте частоту входа (задаётся через элементы управления Session условного доступа для отдельных приложений).
   • Примеры: от 8 до 12 часов для стандартных приложений для повышения производительности; от 1 до 4 часов для административных порталов с высоким уровнем конфиденциальности.
3. Требовать повторную аутентификацию при изменении контекста.
   • Условия CA для применения: Риск входа ≥ средний, Риск пользователя ≥ высокий, Требуется соответствие устройства или Только гибридные устройства / устройства, присоединённые к Microsoft Entra ID.
4. Для неуправляемых или рискованных сеансов используйте Conditional Access App Control (прокси сеансов Microsoft Defender for Cloud Apps).
   • Применяйте строгие политики, например запрет загрузки, печати и синхронизации, чтобы сократить зону поражения, пока устаревшие токены выводятся из обращения.
5. Отзывайте токены по требованию во время активного развертывания или при инцидентах безопасности.
   • Точечный подход: аннулируйте токены обновления для конкретных затронутых пользователей или групп.
   • Широкий подход: принудительно завершите сеансы и отзовите токены во всём клиенте для экстренной корректировки позиции безопасности.
6. Параметры сеанса современной аутентификации.
   • Всегда отдавайте предпочтение элементам управления сеансом в CA перед политиками времени жизни устаревших токенов, которые для большинства современных рабочих нагрузок объявлены устаревшими.

Готовые политики (минимальные, но эффективные)

1. Блокировать при Риск пользователя = высокий

• Назначение: все пользователи (кроме двух учётных записей для экстренного доступа) + все облачные приложения
• Условия: Риск пользователя = высокий
• Предоставление доступа: Блокировать
• Сеанс: Включить CAE (параметр клиента)

1. Дополнительная проверка при риске входа

• Назначение: все пользователи; приложения: Exchange, SharePoint и административные порталы
• Условия: Риск входа ≥ средний
• Предоставление доступа: Требовать MFA; Требовать соответствующее устройство (особенно для административных порталов)

1. Частый вход для администраторов

• Назначение: роли каталога = привилегированные
• Сеанс: Частота входа = 1–4 часа, Постоянный сеанс браузера = никогда

1. Ограничение неуправляемых устройств

• Назначение: все пользователи; приложения: SharePoint, OneDrive и Teams
• Фильтр устройств: Неуправляемые
• Сеанс: Использовать Conditional Access App Control (блокировать загрузку/печать)

Оперативные сценарии

Сценарий A — «Закрепить новое правило CA прямо сейчас»

• Область: группа «Sensitive-Apps-Users»
• Шаги:
  1. Задайте и скорректируйте частоту входа для целевых приложений.
  2. Аннулируйте токены обновления для целевой группы безопасности.
  3. Отправьте пользователям уведомление о том, почему сегодня они могут видеть дополнительные запросы.
  4. Следите за SignInLogs на предмет новых запросов CA и за количеством обращений в службу поддержки.

Сценарий B — «Сдерживание при всплеске риска/компрометации»

• Триггер: оповещение о высокоприоритетной угрозе для идентификаторов (например, рискованный пользователь, невозможное перемещение или боковое перемещение, обнаруженное Defender for Identity)
• Действия (автоматизируйте через Azure Logic Apps):
  1. Подтвердите компрометацию пользователя (устанавливает Риск пользователя = высокий).
  2. Отзовите токены обновления + отзовите сеансы входа.
  3. Переведите пользователя на политику App Control на 72 часа.
  4. Потребуйте сброс пароля и проверку состояния устройства.
  5. Уведомите SOC и руководителя пользователя через адаптивную карточку в Teams.

Команды администратора и конечные точки (копировать и вставить)

• Microsoft Graph (рекомендуется):
  • Отзыв сеансов (пользователь): POST /users/{id}/revokeSignInSessions
  • Аннулирование всех токенов обновления (пользователь): POST /users/{id}/invalidateAllRefreshTokens
  • Подтверждение компрометации рискованного пользователя: POST /identityProtection/riskyUsers/{id}/confirmCompromised
  • Закрытие ложного срабатывания: POST /identityProtection/riskyUsers/{id}/dismiss
• PowerShell (Entra / AzureAD)
  • (устаревший): Revoke-AzureADUserAllRefreshToken -ObjectId <UserId>
  • MSGraph PowerShell: Invoke-MgGraphRequest -Method POST -Uri "/users/$id/revokeSignInSessions"

Совет: для будущей совместимости автоматизаций всегда отдавайте предпочтение Microsoft Graph. Создавайте сценарии (runbooks), которые принимают список UPN и выполняют эти вызовы в цикле со встроенной логикой backoff.

Поиск и мониторинг (KQL)

Кто продолжал использовать старые токены после изменения Conditional Access?

Скачки отзыва тихих токенов обновления (возможное скриптовое злоупотребление refresh token)

Метрики, которые действительно важны

• Время до применения (изменение политики → первый запрос CA) ↓
• Задержка отзыва токенов (действие → принудительная повторная аутентификация пользователя) ↓
• Заблокированные рискованные сессии (в неделю) ↑ при снижении ложных срабатываний ↓
• Обращения в службу поддержки по аутентификации на 1 тыс. пользователей остаются стабильными после изменений
• Инвалидации CAE, коррелирующие со скачками рисков (подтверждение реакции в реальном времени внутри сессии)
• Соблюдение частоты входа для привилегированных учётных записей (контроль отсутствия устаревших сессий) ↑

План выполнения на 30/60/90 дней

Дни 0–30 – Основа

• Включите CAE и задокументируйте поддерживаемые приложения.
• Внедрите политики CA Блокировка для пользователей с риском и Повышение аутентификации при рискованном входе.
• Установите Частоту входа на уровне 8–12 часов для продуктивных приложений и 1–4 часа для административных инструментов.
• Запустите пилот App Control для неуправляемых конечных устройств.

Дни 31–60 – Дисциплина токенов

• Создайте runbook на Graph для массовой инвалидации токенов обновления по группе безопасности.
• Свяжите Playbook B напрямую с оповещениями Microsoft Defender (рискованный пользователь → автоматический отзыв и локализация угрозы).
• Сократите время жизни постоянных сессий и отключите устаревшие политики времени жизни токенов.

Дни 61–90 – Тонкая настройка Zero Trust

• Расширьте охват CAE и проверьте, что запросы повторной аутентификации внутри сессии работают плавно и так, как задумано.
• Добавьте ограничители PIM (блокировка повышения привилегий, если риск пользователя или входа ≥ низкий/средний).
• Создайте книгу Identity Session Health на основе описанных выше метрик.
• Проведите учения purple team, чтобы проверить скорость отзыва доступа и механизмы принудительного применения CA.

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

• Опора только на политики → Всегда управляйте токенами (CAE + отзыв + частота входа).
• Единая частота входа для всех → Разделите политики между административными нагрузками и обычными рабочими приложениями.
• Массовый отзыв доступа в полдень для всего клиента → Поэтапно выкатывайте изменения по группам и часовым поясам, чтобы избежать масштабных сбоев в работе.
• Игнорирование фонового обновления в мобильных приложениях → Ожидайте дополнительных запросов и заранее предупредите мобильных пользователей об изменениях.
• Отсутствие исключения для аварийных учётных записей → Всегда поддерживайте две контролируемые и тщательно протестированные аварийные учётные записи (break-glass).

Итог для руководства в одном предложении

Мы связали политику напрямую с жизненным циклом токенов. Благодаря Continuous Access Evaluation и точечному отзыву доступа изменения рисков и политик теперь вступают в силу немедленно, сокращая окна уязвимости без остановки повседневной работы.