Условный доступ и автоматизация: почему флоу останавливаются после введения обязательной MFA

Когда политика Conditional Access вступает в силу, она блокирует не только вход пользователей, но и может затрагивать автоматизации, которые работают от имени сервисной учётной записи или через service principal. Решающее значение имеет то, происходит ли вход интерактивно или неинтерактивно: политики, нацеленные конкретно на пользователей и группы, согласно Microsoft Learn не срабатывают автоматически при обращениях, выполняемых исключительно от имени service principal, тогда как собственные политики для workload identity могут охватывать именно такие обращения. Поэтому тем, кто внезапно видит ошибки входа в workflow n8n, флоу Power Automate или коннекторе, следует сначала проверить, какая идентичность стоит за этим и какая политика её охватывает. Актуально на август 2026 года.

Чем политика для пользователей отличается от политики для workload identity?

Классическая политика Conditional Access нацелена на пользователей и группы и оценивается при каждом интерактивном входе. Для неинтерактивных учётных записей, таких как Microsoft Entra Connect Sync Account или service principal, это действует не автоматически: согласно Microsoft Learn такие учётные записи обычно предназначены для программного доступа фоновых служб и не охватываются политиками, ориентированными на пользователей. Тому, кто хочет защитить автоматизированный доступ, нужна отдельная политика для workload identity, которая целенаправленно включает или исключает отдельные service principal, зарегистрированные в собственном tenant. При этом multitenant-приложения и управляемые Microsoft идентичности прямо не подпадают под такие политики.

Какую роль играют базовые политики, управляемые Microsoft?

Microsoft развёртывает собственные, предварительно настроенные политики, например обязательную MFA для учётных записей администраторов, которые отображаются в списке политик Entra Admin Center с пометкой "Microsoft" в качестве создателя. Эти базовые политики можно адаптировать или дополнить собственными исключениями, но нельзя произвольно изменять без их дублирования. Согласно Microsoft Learn начиная с 15 июня 2026 года применение этих базовых исключений постепенно активируется автоматически, если в настройках ничего не менялось. Для компаний с существующими автоматизациями это означает: флоу, который до этого оставался незамеченным, может впервые оказаться затронутым в результате такого автоматического изменения, даже если никто не создавал новую политику активно.

Как корректно исключить сервисные учётные записи, не создавая брешь в безопасности?

Огульное исключение всех учётных записей автоматизации из каждой политики не является корректным решением, поскольку это сводит на нет само защитное действие Conditional Access. Более разумно целенаправленно включать или исключать отдельную workload identity затронутого коннектора или service principal, а не освобождать целые группы огульно. При этом break-glass, или аварийные учётные записи, согласно Microsoft, в принципе должны оставаться исключёнными из каждой политики, чтобы в критической ситуации сохранялся административный доступ, независимо от того, что именно заблокировано. Кроме того, для правил include и exclude применительно к одной и той же идентичности действует правило: исключение всегда имеет приоритет над включением.

Что делать, если коннектор автоматизации внезапно блокируется после обновления?

Первым шагом является анализ журналов входа в Entra ID, чтобы увидеть, какая именно политика отклонила доступ и с какой идентичностью вошёл коннектор. Часто оказывается, что причина в недавно применённой базовой политике или недавно изменённом списке исключений, а не в ошибке самого workflow. Для продуктивных автоматизаций стоит с самого начала документировать сервисные учётные записи и service principal и снабжать их отдельной, узкой политикой, вместо того чтобы позволять им неявно попадать под действие общих правил. Тем, кто подключает флоу n8n или Power Automate к сервисам Microsoft 365, стоит закрепить эту проверку в процессе ввода новых автоматизаций в эксплуатацию: у нас это по умолчанию относится к каждой настройке автоматизации.

Частые вопросы о Conditional Access и автоматизации

Блокирует ли Conditional Access автоматически все обращения service principal?

Нет, политики, ориентированные на пользователей, согласно Microsoft, в принципе не срабатывают при обращениях исключительно от service principal. Только политика, созданная специально для workload identity, может охватывать такие неинтерактивные обращения. Таким образом, затронут ли коннектор, зависит от того, существует ли в tenant вообще политика workload identity.

Что такое workload identity в этом контексте?

Workload identity представляет собой идентичность приложения или службы, обычно в форме service principal, зарегистрированного в собственном tenant. Она отличается от пользовательской идентичности тем, что интерактивно входит не человек, а служба в фоновом режиме запрашивает токены доступа. Политики Conditional Access для workload identity можно целенаправленно применять к отдельным таким идентичностям.

Нужно ли исключать аварийные учётные записи из каждой политики?

Да, break-glass учётные записи, согласно Microsoft, должны последовательно исключаться из всех политик Conditional Access. Это относится и к новым или управляемым Microsoft базовым политикам. Без такого исключения существует риск самому оказаться заблокированным в управлении в критической ситуации.

Когда начинается автоматическое применение базовых политик в 2026 году?

Согласно Microsoft Learn, применение затронутых базовых исключений начиная с 15 июня 2026 года постепенно автоматически активируется в течение нескольких недель. Компаниям, которые не меняли стандартные настройки, следует в этот период целенаправленно наблюдать за своими автоматизациями и коннекторами. Те, кто уже ранее внёс собственные изменения, автоматическим переходом не затронуты.