Entra ID Conditional Access: політики доступу в реальних інфраструктурах

П’ятниця, 17:45. Наш Slack-канал інцидентів вибухає: критичний білінг-сервіс, який роками крутився на локальному сервері в датацентрі, раптово втратив доступ до Microsoft Graph API. Бухгалтерія не може виставити рахунки, клієнти лютують. Причина? Молодший адмін вирішив «навести лад з безпекою» і увімкнув глобальну політику Conditional Access (CA) з вимогою MFA для всіх користувачів, забувши виключити сервісні акаунти (non-interactive service accounts) та заблокувавши Legacy Authentication без попереднього аудиту. Цей факап коштував нам чотирьох годин простою та купи нервів. Саме тому Conditional Access — це не просто галочки в порталі Azure, а мінне поле, де кожна помилка в конфігурації може моментально покласти прод.

Чому “Report-only” режим бреше і як з цим жити

Коли ви впроваджуєте нову політику, Microsoft наполегливо рекомендує переводити її в режим Report-only. Логіка проста: ви дивитесь у Sign-in logs, бачите, як політика відпрацювала б, і приймаєте рішення. Але на практиці цей режим часто показує погоду на Марсі.

• Проблема з MFA: Якщо користувач ніколи не реєстрував методи MFA (наприклад, Microsoft Authenticator), у режимі Report-only політика може показати статус Success або Not Applied. Але варто вам перевести її в Enabled, як користувача жорстко заблокує при наступному логіні, бо система вимагатиме негайної реєстрації MFA, яка може бути заборонена з ненадійних локацій.
• Device Compliance: Оцінка відповідності пристрою вимогам Intune у режимі звітування часто дає хибнопозитивні результати. Якщо пристрій не синхронізувався кілька днів, у звіті він може пройти перевірку, а в реальності — отримає блок.

Порада з деплою: Забудьте про повну довіру до звітів. Створіть пілотну групу користувачів (Canary group), обкатайте політику на них протягом тижня, і лише потім розкочуйте на всю компанію.

Наш базовий набір політик (Production-ready Baseline)

Нижче наведено конфігурацію, яка має бути впроваджена в будь-кожному ентерпрайз-тененті. Без цих правил ваша інфраструктура відкрита для базових атак типу Password Spraying.

1. Блокування Legacy Authentication (CA001)

Старі протоколи (IMAP, POP3, SMTP, ActiveSync) не підтримують MFA. Це головна діра, через яку ламають акаунти. Блокуємо без компромісів.

DisplayName: CA001: Block Legacy Authentication
State: Enabled
Assignments:
  Users: All users (Exclude: Break-glass accounts)
  Cloud apps: All cloud apps
  Conditions:
    Client apps: Exchange ActiveSync clients, Other clients (POP, IMAP, SMTP)
Grant:
  Block access

2. Обов’язковий MFA для адміністраторів (CA002)

Будь-який акаунт з адмінською роллю повинен мати MFA за замовчуванням. Жодних винятків, окрім аварійних облікових записів.

DisplayName: CA002: Require MFA for Admins
State: Enabled
Assignments:
  Users:
    Include directory roles: Global Administrator, Security Administrator, Conditional Access Administrator, Exchange Administrator, SharePoint Administrator
  Cloud apps: All cloud apps
Grant:
  Require multifactor authentication

Конфігурація через Microsoft Graph API (PowerShell)

Управління політиками через GUI — це шлях до помилок при масштабуванні. Справжні інженери деплоять політики як код (IaC) або хоча б через PowerShell скрипти. Ось реальний приклад створення політики блокування застарілої автентифікації через модуль Microsoft.Graph.

# Підключення до тененту з необхідними правами
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess", "Application.Read.All"

# Тіло запиту для створення політики
$policyParams = @{
    displayName = "CA001: Block Legacy Authentication"
    state = "enabled"
    conditions = @{
        clientAppTypes = @(
            "exchangeActiveSync"
            "other"
        )
        applications = @{
            includeApplications = @(
                "All"
            )
        }
        users = @{
            includeUsers = @(
                "All"
            )
            excludeUsers = @(
                "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d" # ID вашого Break-glass акаунту
            )
        }
    }
    grantControls = @{
        operator = "OR"
        builtInControls = @(
            "block"
        )
    }
}

# Створення політики
New-MgIdentityConditionalAccessPolicy -BodyParameter $policyParams

Реальні граблі: на чому ми втрачали час і нерви

Аварійні акаунти (Break-glass)

Якщо ви налаштуєте MFA для всіх і у вас «відпаде» сервіс автентифікації Microsoft (так, Azure AD теж іноді лежить), ви не зможете зайти в адмінку. У вас має бути мінімум два акаунти з роллю Global Admin, які виключені з усіх політик Conditional Access. Пароль має бути довжиною від 30 символів, розділений навпіл і збережений у двох фізичних сейфах у різних локаціях. Моніторинг цих акаунтів має тригерити алерти найвищого пріоритету (P1) в Sentinel при будь-якій спробі входу.

Trusted Locations та динамічні IP

Часта помилка — додати офісний IP у білий список і вимкнути для нього MFA. Одного дня провайдер змінює пул IP-адрес, або офіс переходить на резервний LTE-канал, і вся компанія опиняється заблокованою. Якщо використовуєте Named Locations, завжди тримайте резервний план автентифікації та не вимикайте MFA повністю, краще використовуйте опцію Require Hybrid Azure AD Joined device.

Блокування за геопозицією (Geofencing)

Блокування трафіку з певних країн виглядає логічно, але створює проблеми для користувачів з VPN. Якщо ваш топ-менеджер підключиться до публічного Wi-Fi в готелі, який маршрутизує трафік через іншу країну, його заблокує. Налаштовуйте такі політики з обережністю і лише в режимі суворого моніторингу.