Как условный доступ и PIM на самом деле останавливают атаки?

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

Как работает условный доступ изнутри

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

Политика, которая имеет значение почти в каждом клиенте: блокировка устаревшей аутентификации. Протоколы типа POP, IMAP и старый SMTP не поддерживают современные вызовы MFA, поэтому они — первое, что пробуют инструменты перебора учётных данных. Проверьте журналы входа, отфильтрованные по "Client App = Other clients", перед блокировкой — часто вы найдёте какой-нибудь устаревший сканер или старый многофункциональный принтер, всё ещё аутентифицирующийся с basic auth.

Вторая политика, которую стоит иметь с самого начала: требование MFA для всех пользователей, с исключением только для учётных записей разрыва стекла. Не ограничивайте MFA только на "администраторов". Скомпрометированные учётные записи обычных пользователей — это то, как злоумышленники получают первый плацдарм перед тем, как вообще начинать эскалацию привилегий.

Риск входа против риска пользователя — разные сигналы, разные ответы

Identity Protection (часть Entra ID P2) генерирует две отдельные оценки риска, и их легко спутать:

• Риск входа — эта конкретная попытка аутентификации выглядит аномальной (невозможное перемещение, анонимный IP, незнакомые свойства входа).
• Риск пользователя — эта учётная запись помечена по причине, связанной с самой идентификацией (утёкшие учётные данные найдены в базе данных брешей, подтверждённая активность компрометации).

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

Почему постоянный доступ администратора — более серьёзная проблема

Даже при безупречном условном доступе учётная запись, которая постоянно имеет права Global Administrator, — это мишень, видимая в справочнике. Кто-нибудь, кто скомпрометирует её, получит полный контроль над клиентом без дополнительного шага. PIM убирает фиксированный доступ.

С PIM роли администратора назначаются как подходящие, а не активные. Пользователь должен явно активировать роль, что запускает обязательное обоснование, необязательный рабочий процесс утверждения, повторное подтверждение MFA и привязанное ко времени окно — обычно от 1 до 8 часов — после чего роль автоматически деактивируется. Никто, включая владельца учётной записи, не имеет постоянного Global Admin, если он не использует его активно.

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

• Каждая роль выше Helpdesk Administrator: подходящая, не постоянная.
• Global Administrator и Privileged Role Administrator: требование утверждения от второго администратора, а не просто самоактивация.
• Требование MFA при активации, без исключений.
• Максимальная длительность активации 4 часа вынуждает людей повторно активировать роль для отдельных рабочих сессий, что также даёт более чистые журналы аудита.
• Проверки доступа каждые 90 дней для всех подходящих назначений — учётные записи добавляются для одного проекта и иначе никогда не удаляются.

Где команды допускают ошибку

Самый распространённый отказ — это не конструкция политики, а список исключений. Политика условного доступа с постоянно растущей группой "исключить этих пользователей, потому что приложение не поддерживает MFA" в итоге исключает половину клиента. Отслеживайте исключения как элемент невыполненной работы с владельцем и датой удаления, а не как постоянное хранилище.

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

Conditional Access и PIM — это не галочка для проверки соответствия нормативным требованиям. Это разница между тем, что фишинговые учётные данные — это неудобство, или полная компрометация клиента. Если вы планируете элементы управления идентификацией как часть создания Blue Team, сегменты Cloud и Blue Team Korra Studio охватывают сторону обнаружения — как выглядят события риска Identity Protection в Sentinel и как настроить оповещения на невозможные шаблоны активации PIM.