Посилення Zero Trust за допомогою безперервної оцінки доступу (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 обробляє автентифікацію, полягає в тому, що ваші межі безпеки міцні лише настільки, наскільки міцні ваші токени. Політики самі себе не застосовують; застосовують токени.

У цій докладній статті ми розширимо тему нашої нещодавньої розмови в подкасті, розібравши, як безперервна оцінка доступу (CAE) змінює правила гри. Відмовившись від статичних токенів на користь відкликання в режимі реального часу, що ґрунтується на подіях, ви можете значно скоротити вікно вразливості вашої організації. Щоб ознайомитися з базовими механізмами того, як ці токени працюють під капотом, обов'язково послухайте наш супутній епізод Modern Authentication and Token Lifecycle in Microsoft 365.

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

• Політики самі себе не застосовують, а застосовують токени. Умовний доступ оцінюється під час видачі або оновлення токена. Наявні токени зберігають довіру вчорашнього дня, доки ви не примусите повторну оцінку.
• MSAL непомітно замінює токени доступу за допомогою токенів оновлення, тоді як CAE може анулювати їх на льоту, коли змінюються ризик або контекст.
• Щоб зміни «спрацювали одразу», потрібно налаштувати життєвий цикл токенів (частоту входу, відкликання токенів оновлення, CAE, керування сеансами).

Модель простими словами

Щоб зрозуміти, чому безперервна оцінка доступу так сильно змінює підхід, спочатку варто подивитися на учасників сучасної автентифікації. Уявіть свою архітектуру автентифікації як ексклюзивний клуб:

• Токен доступу (AT): короткоживучий гостьовий бейдж (зазвичай близько години), який відкриває вам двері до певних кімнат.
• Токен оновлення (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 для примусового застосування: ризик входу ≥ Medium, ризик користувача ≥ High, вимога відповідності пристрою або лише Hybrid/AADJ.
4. Використовуйте Conditional Access App Control (проксі сеансів Microsoft Defender for Cloud Apps) для некерованих або ризикових сеансів.
   • Застосовуйте суворі політики, наприклад заборону завантаження, друку та синхронізації, щоб зменшити радіус ураження, поки застарілі токени виводяться з використання.
5. Відкликайте токени за потреби під час активних розгортань або інцидентів безпеки.
   • Цільовий підхід: анулюйте токени оновлення для конкретних уражених користувачів або груп.
   • Загальний підхід: примусовий вихід і відкликання токенів у всьому клієнті для екстрених змін політики безпеки.
6. Параметри сеансу сучасної автентифікації.
   • Завжди віддавайте перевагу елементам керування сеансом CA Session перед політиками терміну дії застарілих токенів, які для більшості сучасних навантажень застаріли.

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

1. Блокувати, коли ризик користувача = High

• Призначення: усі користувачі (окрім двох аварійних облікових записів) + усі хмарні застосунки
• Умови: ризик користувача = High
• Надання доступу: Block
• Сеанс: Увімкнути CAE (параметр клієнта)

1. Додаткова перевірка за ризику входу

• Призначення: усі користувачі; застосунки: Exchange, SharePoint та адміністративні портали
• Умови: ризик входу ≥ Medium
• Надання доступу: Вимагати MFA; Вимагати відповідний пристрій (спеціально для адміністративних порталів)

1. Короткий інтервал входу для адміністраторів

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

1. Обмеження некерованих пристроїв

• Призначення: усі користувачі; застосунки: SharePoint, OneDrive та Teams
• Фільтр пристроїв: Unmanaged
• Сеанс: Використовувати Conditional Access App Control (блокувати завантаження/друк)

Операційні плейбуки

Плейбук A — "Зробити нове правило CA чинним зараз"

• Область: група з назвою "Sensitive-Apps-Users"
• Кроки:
  1. Налаштуйте Частоту входу для цільових застосунків.
  2. Анулюйте токени оновлення для цільової групи безпеки.
  3. Опублікуйте повідомлення для користувачів, що пояснює, чому сьогодні можуть з'являтися додаткові запити.
  4. Стежте за SignInLogs на предмет нових запитів CA і за обсягом заявок до служби підтримки.

Плейбук B — "Стримування спалаху ризику або компрометації"

• Тригер: сповіщення про ідентифікаційну загрозу високої важливості (наприклад, ризикований користувач, неможлива подорож або бокове переміщення, виявлене Defender for Identity)
• Дії (автоматизуйте через Azure Logic Apps):
  1. Підтвердити компрометацію користувача (встановлює ризик користувача = High).
  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, щоб ваші автоматизації залишалися актуальними. Створюйте runbook-и, які приймають список UPN і виконують ці виклики в циклі з вбудованою логікою backoff.

Пошук і моніторинг (KQL)

Хто продовжував використовувати старі токени після зміни Conditional Access?

Різкі сплески відкликання Silent RT (можливе зловживання скриптованим оновленням токенів)

Метрики, які мають значення

• Час до застосування (зміна політики → перший виклик 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 (блокування підвищення прав, якщо ризик користувача або входу становить Low/Medium або вище).
• Створіть робочу книгу Identity Session Health на основі метрик, описаних вище.
• Проведіть purple-team drill, щоб перевірити швидкість відкликання та механізми примусового застосування CA.

Типові помилки (і безпечніші налаштування за замовчуванням)

• Покладатися лише на політики → Завжди керуйте токенами (CAE + відкликання + частота входу).
• Одна глобальна частота входу → Розділіть політики між адміністративними навантаженнями та звичайними робочими застосунками.
• Масові відкликання опівдні для всього клієнта → Поетапно розгортайте зміни за групами та часовими поясами, щоб уникнути масових збоїв у роботі.
• Ігнорування фонового оновлення на мобільних пристроях → Очікуйте додаткових запитів і заздалегідь повідомте мобільним користувачам про зміни.
• Відсутнє виключення для аварійних облікових записів → Завжди підтримуйте два контрольовані та ретельно перевірені аварійні облікові записи.

Однорядкове резюме для CAB (зрозуміле керівництву)

Ми прив’язали політику безпосередньо до життєвого циклу токенів. Завдяки Continuous Access Evaluation і цільовому відкликанню зміни ризику чи політики тепер набувають чинності миттєво, скорочуючи вікна вразливості без зупинки щоденної роботи.