Як умовний доступ та PIM насправді зупиняють атаки?

Політики паролів зупиняють атаки на вгадування. Вони нічого не роблять проти украденого токена сеансу, фішингового запиту MFA або постійного облікового запису адміністратора, який два роки мав права Global Administrator. Conditional Access та Privileged Identity Management (PIM) — це два контролю Azure AD / Entra ID, які насправді закривають ці прогалини, і вони працюють найкраще разом.

Що робить Conditional Access під капотом

Conditional Access — це рушій if-this-then-that, що оцінюється в момент входу. Сторона «якщо» (сигнали) включає належність користувача/групи, стан відповідності пристрою, мережеве розташування, ризик входу (з Identity Protection), додаток, до якого здійснюється доступ, та тип клієнтського додатка (браузер проти старого протоколу). Сторона «то» (контролю) включає: потребу MFA, потребу відповідного пристрою, потребу схвареного клієнтського додатка, повне блокування доступу або потребу прийняття умов використання.

Політика, яка має значення в майже кожному тенанті: блокування старої автентифікації. Протоколи як POP, IMAP та старіший SMTP не підтримують сучасні виклики MFA, тому вони — перше, що пробують інструменти для набивання облікових даних. Перевірте журнали входу, відфільтровані за «Client App = Other clients» перед блокуванням — часто знайдете один старий сканер або старий багатофункціональний принтер, який аутентифікується за допомогою базової автентифікації.

Другий, який варто мати з дня один: потребу MFA для всіх користувачів, з обмеженням групою виключення лише для аварійних облікових записів. Не обмежуйте MFA лише на «адміністраторів». Скомпрометовані облікові записи звичайних користувачів — це як зловмисники отримують свій перший слід перед навіть переходом привілеїв.

Ризик входу проти ризику користувача — різні сигнали, різні відповіді

Identity Protection (частина Entra ID P2) генерує дві окремі оцінки ризику, і їх легко змішати:

• Sign-in risk — цей конкретний запит автентифікації виглядає аномальним (неможливі подорожі, анонімна IP, незнайомі властивості входу).
• User risk — цей облік позначений з причини, пов'язаної з самою ідентичністю (витікли облікові дані, знайдені в корпусі порушення, підтверджена активність компрометування).

Політика Conditional Access, що реагує на ризик входу, зазвичай повинна поставити виклик MFA — якщо реальний користувач може пройти виклик, пропустіть його. Політика, що реагує на ризик користувача, повинна примусити скидання пароля, тому що MFA один не допомагає, якщо сами облікові дані вже спалені.

Чому постійний доступ адміністратора є більшою проблемою

Навіть з абсолютно герметичним Conditional Access, облік, який постійно має Global Administrator, — це ціль, видима в директорії. Будь-хто, хто її скомпрометує, успадкує повний контроль тенанту без будь-якого додаткового кроку. PIM видаляє «постійну» частину.

З PIM, ролі адміністратора призначаються як eligible замість active. Користувач повинен явно активувати роль, що запускає необхідне обґрунтування, опціональний робочий процес затвердження, повторне підтвердження MFA та обмежене часом вікно — зазвичай від 1 до 8 годин — після чого роль автоматично деактивується. Ніхто, включаючи власника облікового запису, не має постійного Global Admin, якщо вони його не активно використовують.

Мінімальна конфігурація PIM, яка насправді придатна

• Кожна роль вище Helpdesk Administrator: eligible, не постійна.
• Global Administrator та Privileged Role Administrator: потребують затвердження від другого адміністратора, не лише самоактивації.
• Активація MFA обов'язкова, без винятків.
• Максимальна тривалість активації 4 години змушує людей повторно активувати для справді окремих робочих сеансів, що також дає чистіші журнали аудиту.
• Огляди доступу кожні 90 днів за всіма придатними призначеннями — облікові записи додаються для одного проекту і ніколи не видаляються.

Де команди це роблять неправильно

Найчастіша невдача — не дизайн політики, а список виключень. Політика Conditional Access з постійно зростаючою групою «виключити цих користувачів, тому що додаток не підтримує MFA» врешті-решт виключає половину тенанту. Відстежуйте виключення як елемент невикористаних завдань з власником та датою видалення, не як постійний контейнер.

Другою невдачею є аварійні облікові записи, які насправді не тестуються. Два аварійних облікових запису, виключених з Conditional Access та PIM, з довгими випадковими паролями, збереженими в автономному режимі, та сповіщеннями про будь-який вхід — та хтось повинен намагатися увійти в них щоквартально, щоб підтвердити, що вони все ще працюють.

Conditional Access та PIM не є прапорцем для аудиту відповідності. Це різниця між тим, що фішингова облікові дані є незручністю, та тим, що це повна компрометація тенанту. Якщо ви складаєте карту контролю ідентичності як частину побудови Blue Team, Cloud та Blue Team сегменти Korra Studio охоплюють сторону виявлення — як насправді виглядають сигнали ризику Identity Protection у Sentinel та як сповіщати на неможливих шаблонах активації PIM.