Политика условного доступа не применяется: как диагностировать и исправить проблемы в Microsoft Entra

By Mirko Peters · 2026-04-23 · Updated 2026-07-28

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

Automatically translated with AI from the original post. Read the English original

Cover: Fix Microsoft Entra ID Conditional Access and Identity Debt

Политика условного доступа не применяется: практический чек-лист

Определите сценарий, владельца и критерии принятия решений.
Проверьте разрешения, политику, безопасность и влияние на пользователей.
Протестируйте на пилотной группе и задокументируйте решения по поддержке и пересмотру.

Используйте Microsoft Learn для актуальных рекомендаций.

Последний пересмотр: июль 2026 года.

Условный доступ — основа защиты идентификации в Microsoft Entra (ранее Azure AD). Но когда в журналах вы видите пугающий статус «NotApplied», это значит, что средства контроля доступа не выполняют свою работу, и ваша организация может оказаться открытой для не тех людей. Эта проблема незаметно накапливается до тех пор, пока её не выявят аудит соответствия, реагирование на инциденты или проблемные пользователи.

Самое сложное: редко бывает только одна причина, по которой политика условного доступа не применяется. Это может быть пропущенный параметр, служебный принципал, который проскальзывает сквозь щели, или привычная путаница из-за разрастания политик. Когда условный доступ не работает, поиск неполадок быстро становится непростым. Поэтому понимание того, как Microsoft Entra оценивает и пропускает политики, имеет решающее значение. Именно так вы устраняете эти невидимые пробелы, снижаете количество жалоб пользователей и спокойно относитесь к работе службы безопасности.

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

Как работает оценка условного доступа в Azure и почему политики показывают статус Not Applied

Условный доступ в Microsoft Entra может выглядеть простым: применили правило, получили результат. Но за кулисами всё быстро усложняется. Прежде чем пытаться исправить проблему «NotApplied», нужно понять, как Entra обрабатывает каждую политику в момент, когда пользователь пытается войти. Не каждая политика срабатывает или не срабатывает только на основе того, что вы проверили в центре администрирования.

Когда политика помечена как «NotApplied», это значит, что Entra проверила вход по этой политике, но сочла, что правило не подходит к ситуации. Возможно, пользователь, устройство, приложение или контекст входа просто не соответствовали области действия политики, либо другая политика с более высоким приоритетом уже обеспечила требуемый результат.

Всё упирается в порядок оценки и в то, как Entra решает, какая политика побеждает при пересечении. Плюс к этому есть исключения из политик, потоки служебных принципалов, особенности именованных расположений и то, как некоторые службы Microsoft 365 ведут себя по-своему. Многие политики пропускаются, иногда по причинам, которые не очевидны, и единственной подсказкой остаётся метка «NotApplied».

Если не разбираться в этих причинах и не распознавать «NotApplied» таким, какой он есть, вы рискуете упустить брешь в безопасности или получить проблемы со входом у законных пользователей. Здесь на помощь приходят журналы входа: они помогают отличить применённые, пропущенные и проигнорированные политики и дают реальную картину того, что происходит на самом деле. Если вам нужны более тонкие детали об условном доступе и рисках, этот выпуск подкаста о разрастании политик и управлении ими содержит проверенные на практике стратегии для крупных организаций.

Как журналы входа Microsoft Entra помогают выявлять пробелы в применении политик

Журналы входа Microsoft Entra — ваш главный инструмент для расследования загадок условного доступа. Каждая запись журнала показывает, какие политики были оценены для входа, и вы увидите явные статусы, такие как «Applied», «NotApplied», «Failure» или «Success». «NotApplied» не означает, что Entra проигнорировала политику: это значит, что условия не были выполнены или другая политика имела приоритет.

Откройте в журналах входа вкладку «Conditional Access». Здесь можно сопоставить контекст пользователя, устройства и приложения, чтобы понять, почему политика не сработала. Обратите внимание на артефакты, например входы служебных субъектов (service principal) или потоки только для приложений: они часто отображаются со статусом «NotApplied», потому что CA не обрабатывает неинтерактивные токены. Умение читать эти журналы критически важно для выявления пробелов и исключения ошибок конфигурации. Подробнее о базовых политиках и отслеживании проблем доверия см. это руководство о пробелах доверия в Conditional Access.

Наиболее распространённые ошибки конфигурации Conditional Access, которые мешают применению политик

Давайте честно: Conditional Access — один из тех инструментов, где небольшая ошибка может превратиться в серьёзную проблему безопасности. Главный виновник статуса «NotApplied»? Ошибка конфигурации, и ничего более. Неверно указанное исключение, слишком мягкий порог риска или забытые устаревшие протоколы могут оставить двери безопасности приоткрытыми, хотя все считали, что они надёжно заперты.

Несоответствия области действия и условий встречаются постоянно, особенно в настройках местоположения или в логике рискованных входов. Будь то пользователь в неожиданном месте или приложение, использующее устаревшую аутентификацию, применение политики нарушается так, что заранее этого не видно. Добавьте сюда особенности элементов управления доступом, например путаницу между «require all» и «require any», и станет понятно, как легко правилам, которые задумывались, выпасть из поля зрения.

Кроме того, устаревшая аутентификация работает как чёрный ход в обход Conditional Access и MFA. Это лазейка, о которой многие организации забывают, пока проверка соответствия требованиям не сообщит о проблеме. Лучшие администраторы остаются начеку, перепроверяя свою работу и следя за новыми лазейками по мере развития Microsoft 365. Если вы хотите увидеть, как незаметный дрейф конфигурации может влиять даже на результаты соответствия требованиям у самой Microsoft, обратите внимание на подкаст о дрейфе соответствия требованиям в Microsoft 365, он очень наглядный.

Ловушки в условиях местоположения и риска в политиках Conditional Access

Неверно настроенные именованные местоположения: Если в именованных местоположениях указан неправильный диапазон IP-адресов, пропущены доверенные адреса или неполный список стран, некоторые входы могут обойти вашу политику без предупреждения.
Неподходящие уровни риска: Если пороги рискованных пользователей или рискованных входов установлены слишком высоко (или слишком низко), реальные риски могут остаться незамеченными, а пользователи могут быть заблокированы из-за ложных срабатываний.
Пропущенные или слишком широкие местоположения: Забытые необходимые диапазоны IP-адресов, облачные приложения или оставленные «доверенные» географические регионы приводят к неравномерному применению политик.
Слепые зоны состояния устройства: Если не учитывать соответствие устройств требованиям или гибридное присоединение к Azure AD, входы с неуправляемых конечных точек остаются без контроля.

Чтобы избежать этих ошибок, последовательный аудит и понятное управление, как описано в этом руководстве по управлению в Azure, играют решающую роль.

Элементы управления доступом и правила предоставления, из-за которых Conditional Access даёт сбой

Конфликтующие элементы управления предоставлением доступа («require all» и «require any»): Если политика требует выполнения всех элементов управления предоставлением доступа, например MFA, соответствующего устройства и одобренного приложения, то одно невыполненное требование приводит к статусу «NotApplied» или к непреднамеренному отказу в доступе.
Неочевидная логика блокировки доступа: Случайное включение одновременно элементов «grant» и «block» в одной политике может взаимно нейтрализовать их действие, что приводит к непредсказуемому применению (или к статусу «NotApplied», если условия блокировки не срабатывают).
Пересекающиеся или исключённые группы пользователей: Включение широких групп в политику с высоким приоритетом может перекрывать более точечные политики, и те выглядят как «NotApplied», потому что их условия так и не получают шанс сработать.
Неверный выбор облачных приложений: Применение политик не к тем облачным приложениям или пропуск ключевого приложения означает, что нужные ограничения просто не срабатывают.

Устаревшая аутентификация и обход MFA, которые создают пробелы

Устаревшие протоколы: Старые протоколы, такие как POP, IMAP и SMTP, обходят Conditional Access и MFA и проникают через Exchange Online и другие классические конечные точки.
Неуправляемые регистрации приложений: Приложения, зарегистрированные до того, как было включено условное доступ (Conditional Access), или использующие поток client credentials, не подпадают под современные проверки политик, что позволяет злоумышленникам или невнимательным пользователям получать доступ к ресурсам без дополнительной проверки.
Исключения из MFA для служебных учётных записей: Массовые исключения для устаревших систем или общих почтовых ящиков отключают базовую защиту и создают слепые зоны, которыми любят пользоваться злоумышленники.
Лазейки между приложениями: Ошибки в интеграции клиентских приложений могут обойти запросы MFA даже там, где вы их ожидаете. Подробнее о том, как закрыть эти пробелы Zero Trust, читайте в этом руководстве по Zero Trust в Microsoft 365/Dynamics 365.

Устранение неполадок условного доступа в приложениях Microsoft 365, B2B и на платформах устройств

Эффективность условного доступа определяется его самым слабым звеном. У Microsoft 365 есть собственные особенности работы сервисов, входы гостевых пользователей и партнёров B2B работают иначе, а применение политик к устройствам не всегда такое, как вы ожидаете. Эти нюансы могут сбить даже продуманные политики и оставить после себя следы «NotApplied».

Гостевые учётные записи, особенно давно забытые после партнёрского проекта, — яркий пример. Их границы доверия и жизненный цикл отличаются от внутренних пользователей, поэтому политики могут их пропустить или срабатывать непредсказуемо. Особенности поведения сервисов Microsoft 365, например Exchange Online или SharePoint, добавляют ещё один уровень сложности: от разрешений приложений до тайм-аутов сеанса.

Отдельная история — устройства: то, как конечная точка пользователя присоединена, зарегистрирована или управляется (например, гибридное присоединение к Azure AD, соответствие требованиям Intune, платформы мобильных устройств), определяет, какие политики будут применены, а какие пропущены. Если вы хотите разобраться в применении условного доступа в разных средах, составьте чек-лист для каждой среды, который поможет выявлять пробелы в режиме реального времени, прежде чем они обернутся ночным звонком в поддержку. Подробнее о рисках управления с гостевыми пользователями и управлении Teams читайте в статьях о стратегиях снижения рисков гостевых учётных записей и улучшении управления Teams, чтобы получить более полное представление о меняющихся рисках.

Особенности сервисов Microsoft 365, влияющие на условный доступ

Не каждая рабочая нагрузка Microsoft 365 одинаково подчиняется правилам условного доступа. Такие сервисы, как Exchange Online, SharePoint и Teams, имеют собственные API, конечные точки и логику управления сеансами. Некоторые протоколы или доступ через мобильные приложения не всегда учитывают последние настройки CA, особенно когда задействованы устаревшие конечные точки или приложения OAuth с предоставленным согласием.

Политика может отображаться как «NotApplied», потому что приложение использует другие методы аутентификации, например Exchange Online PowerShell или SharePoint Online через устаревший поток. Это может открыть цепочки атак с фишингом согласия или кражей токенов, поэтому каждую рабочую нагрузку нужно исправлять точечно. Подробнее о таких векторах атак на уровне сервисов и защите от них читайте в статье о устранении цепочек атак в Microsoft 365.

Условный доступ для совместной работы B2B и гостевых пользователей

Границы доверия B2B: Домашние организации гостевых пользователей могут иметь собственные правила безопасности, и ваш CA не всегда их переопределяет, поэтому срабатывание политик может быть непредсказуемым.
Приглашение и вход: Условный доступ применяется при входе, а не при приглашении. Если гость никогда не входит, ваши политики не запускаются.
Мониторинг и оповещения: Следите за аномалиями входа гостевых пользователей, настраивая оповещения и просматривая журналы Entra. Это гарантирует, что внешний доступ или оставшиеся гостевые учётные записи не приведут к рискам несоответствия требованиям.
Проверка и срок действия: Регулярные проверки доступа и приглашения с ограниченным сроком действия помогают поддерживать порядок в среде и сокращать поверхность атаки. Для наилучшего результата организуйте постоянные аудиторские процессы с расширенным охватом, как описано в этом практическом руководстве по средствам контроля внешнего общего доступа.

Проблемы Windows и соответствия требованиям устройств в условном доступе

Исключения по платформе устройства: Политики, ограниченные Windows, iOS или Android, могут полностью пропускать пользователей, если их устройство не распознано или не соответствует требованиям соответствия.
Проблемы с гибридным присоединением к Azure AD: Устройства, которые не были должным образом присоединены (гибридно или иным способом), не проходят проверки устройства в условном доступе, из-за чего политики не применяются.
Пробелы в интеграции с Intune: Политики соответствия на основе Intune могут регистрироваться не сразу, и в этот промежуток времени применение политик может выглядеть непоследовательным.
Несоответствующие или не прошедшие аттестацию устройства: Входы с взломанных, устаревших или неуправляемых устройств, как правило, не запускают политики, защищённые проверкой устройства. Дополнительные рекомендации по интеграции соответствия и защиты от угроз доступны в этом обзоре Microsoft 365 Defender и Purview.

Как избежать разрастания политик и пересечений, из-за которых условный доступ работает непредсказуемо

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

Разрастание политик, когда добросовестные администраторы снова и снова добавляют «ещё одну политику», порождает скрытые слепые зоны в применении правил, особенно если вы опираетесь на включение групп и исключения или забываете удалять тестовые политики. Зависимости от служб усугубляют ситуацию: изменение одного облачного приложения или новая интеграция может сорвать работу цепочки политик, которая раньше работала надёжно.

Разумный шаг — регулярный аудит и рационализация политик. Сосредоточьтесь на базовых, охватывающих политиках и сводите к минимуму временные исключения. Убедитесь, что у каждой политики есть понятное назначение, задокументированный результат и сопутствующая отчётность, которую можно использовать на практике. И никогда не считайте, что окружение можно «настроить и забыть». Подходы к мониторингу пробелов в доверии и работе с теневым ИТ в условном доступе描述ы в этом практическом руководстве по проблемам доверия к CA и руководстве по устранению теневого ИТ.

Управление зависимостями служб и предотвращение разрастания политик

Аудит текущих политик: Регулярно инвентаризируйте и документируйте все действующие политики условного доступа, следя за ненужными пересечениями и устаревшими правилами.
Картируйте взаимосвязанные службы: Определите зависимости политик условного доступа между Azure, Microsoft 365 и сторонними приложениями, чтобы выявлять пробелы в применении, которые появляются вместе с новыми интеграциями.
Консолидируйте и рационализируйте: Объединяйте похожие политики и выводите из эксплуатации устаревшие или неиспользуемые, делая упор на широкие, хорошо документированные правила с точечными исключениями.
Проверяйте риски ИИ и автоматизации: Не забывайте о фоновых процессах: агентам ИИ и автоматизации нужны собственные ограниченные средства контроля, чтобы блокировать риски теневого ИТ, как описано здесь: угрозы теневого ИТ со стороны агентов ИИ.

Безопасная проверка влияния политик с помощью «Выбрать все последствия» и отчётности

Сначала включите режим только отчётов: Перед развёртыванием используйте режим только отчётов, чтобы смоделировать влияние политики, не блокируя законных пользователей. Проанализируйте эффект с помощью встроенных панелей отчётности.
Используйте «Выбрать все» для последствий осторожно: Применяйте все действия по обеспечению соблюдения политик в безопасной тестовой среде, чтобы выявить неожиданные результаты или незапланированные исключения до полного развёртывания.
Документируйте затронутых пользователей и приложения: Ведите учёт каждого пользователя, группы и приложения, на которые влияют изменения, чтобы вы могли информировать заинтересованные стороны и откатить изменения, если что-то пойдёт не так.
Собирайте обратную связь от пользователей и системы: Поощряйте пользователей сразу сообщать о проблемах и проверяйте журналы системных ошибок на наличие блокировок из-за политик.
Опирайтесь на журналы аудита при реагировании на инциденты: Используйте Microsoft Purview Audit и журналы клиента для отслеживания действий пользователей и проверки результатов политик. Рекомендации по аудиту см. в этом подробном руководстве по Purview Audit.

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

Każdy администратор Conditional Access знает этот кошмар: вы развертываете новую политику, и внезапно вы — или вся ваша команда — теряете доступ к клиенту, либо политика, которая, как вы думали, всё исправит, вообще не работает. Звонков с эскалациями становится всё больше, и вы понимаете, что для поддержания работы бизнеса нужна надёжная стратегия восстановления.

Хорошая новость? Существует план действий, позволяющий быстро вернуть доступ и при этом не ухудшить ситуацию. Вам понадобятся заранее подготовленные аварийные учётные записи (break-glass), отлаженные тактики отката и исключений, а при необходимости — эскалация в службу поддержки Microsoft или к вашей команде безопасности.

Но на восстановлении останавливаться не стоит. Если не устранить первопричину, вы снова окажетесь в этой ситуации при следующем изменении политики. Поэтому разбор после инцидента, информирование заинтересованных сторон, регулярное тестирование и документирование выводов так же важны, как и само переключение нужного параметра для восстановления сервиса. Чтобы понять, почему разрозненное владение инструментами губит управление, ознакомьтесь с этим детальным разбором сбоев в управлении.

Пошаговое восстановление при сбое Conditional Access

Используйте аварийную учётную запись (break-glass): Держите хотя бы одну аварийную учётную запись с правами глобального администратора, к которой не применяются политики Conditional Access. Войдите под ней, чтобы в любой момент восстановить доступ.
Примените временные политики исключений: Если доступ заблокирован, создайте или активируйте политику исключений для затронутой учётной записи или группы, чтобы восстановить нормальный доступ и устранить первопричину.
Эскалируйте для административного переопределения: Если шаги первой линии не помогли, обратитесь в службу поддержки Microsoft или к команде безопасности для прямого вмешательства или разблокировки клиента.
Откатите недавние изменения политик: Верните новые или недавно изменённые правила Conditional Access к последней работоспособной конфигурации и проверьте журналы входа, чтобы убедиться в устранении проблемы.

Дальнейшие шаги и проверка действующих политик после выявления проблем с неприменёнными политиками

Документируйте уроки: Зафиксируйте, что именно пошло не так, какое решение сработало и где нужны будущие средства контроля или аудиты.
Тестируйте в режиме только отчётов: Прежде чем снова включить политику, используйте режим только отчётов Entra, чтобы убедиться, что вы выявляете проблемы, не вызывая новых сбоев.
Собирайте и учитывайте обратную связь: Запрашивайте отзывы у затронутых пользователей и данные системных журналов и используйте полученные сведения для закрытия оставшихся пробелов.
Информируйте заинтересованные стороны: Держите в курсе все затронутые команды, руководство ИT, внешних партнёров и пользователей: сообщайте об инциденте, его устранении и планах долгосрочной профилактики.
Обеспечьте регулярное управление: Планируйте постоянные проверки, отчётность и обновление политик Conditional Access, ведь хорошее управление, как напоминает подкаст об иллюзии управления, — это непрерывная практика, а не разовая галочка.

🎧 Вам также стоит послушать

Управление идентификацией в Microsoft Entra
Изучите средства контроля доступа и жизненного цикла.
Microsoft Purview – простыми словами
Узнайте о защите и контексте соответствия требованиям.
Модель операционного управления Microsoft 365
Разберитесь в устойчивом владении и принятии решений.