Планирование развертывания условного доступа

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

Условный доступ Microsoft Entra объединяет такие сигналы, как пользователь, устройство и расположение для автоматизации решений и принудительного применения политик доступа организации для ресурсов. Эти политики условного доступа помогают сбалансировать безопасность и производительность, применяя средства управления безопасностью при необходимости и оставаясь вне пути пользователя, когда нет.

Условный доступ является основой подсистемы политики безопасности нулевого доверия Майкрософт.

Корпорация Майкрософт предоставляет параметры безопасности по умолчанию , обеспечивающие базовый уровень безопасности в клиентах, у которых нет идентификатора Microsoft Entra ID P1 или P2. С помощью условного доступа можно создавать политики, которые обеспечивают защиту на уровне параметров безопасности по умолчанию, но с более точной настройкой. Условный доступ и безопасность по умолчанию не предназначены для объединения при создании политик условного доступа, чтобы запретить включение значений безопасности по умолчанию.

Необходимые компоненты

• Рабочий клиент Microsoft Entra с включенным лицензией Microsoft Entra ID P1, P2 или пробной лицензией. Создайте ее бесплатно, если нужно.
  • Идентификатор Microsoft Entra ID P2 требуется для включения Защита идентификации Microsoft Entra риска в политиках условного доступа.
• Администраторы, взаимодействующие с условным доступом, должны иметь одно из следующих назначений ролей в зависимости от выполняемых задач. Чтобы следовать принципу нулевого доверия наименьших привилегий, рекомендуется использовать управление привилегированными пользователями (PIM) для JIT-активации назначений привилегированных ролей.
  • Чтение политик и конфигураций условного доступа
    • читатель сведений о безопасности;
  • Создание или изменение политик условного доступа
    • Администратор условного доступа
• Тестовый пользователь (а не администратор), который позволяет проверять работу политик должным образом перед развертыванием для реальных пользователей. Если вам нужно создать пользователя, см . краткое руководство. Добавление новых пользователей в идентификатор Microsoft Entra ID.
• Группа, в которую входит тестовый пользователь. Если вам нужно создать группу, см. статью "Создание группы" и добавление участников в идентификатор Microsoft Entra.

Взаимодействие с изменением

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

Компоненты политики условного доступа

Политики условного доступа отвечают на вопросы о том, кто может получить доступ к ресурсам, какие ресурсы они могут получить доступ и в каких условиях. Политики можно настроить для предоставления доступа, ограничения доступа с помощь элементов управления сеансами или для блокировки доступа. Вы создадите политику условного доступа, определив такие операторы if-then:

Пользовательские исключения

Политики условного доступа являются мощными средствами, мы рекомендуем исключить следующие учетные записи из политик:

• Аварийный доступ или учетные записи с разрывом, чтобы предотвратить блокировку из-за неправильной настройки политики. В маловероятном сценарии, когда все администраторы заблокированы, ваша учетная запись администратора для аварийного доступа может использоваться для входа и выполнения действий по восстановлению доступа.
  • Дополнительные сведения см. в статье об управлении учетными записями аварийного доступа в идентификаторе Microsoft Entra.
• Учетные записи служб и субъекты-службы, такие как учетная запись синхронизации Microsoft Entra Connect. Учетные записи служб представляют собой автономные учетные записи, которые не привязаны к какому-либо конкретному пользователю. Они обычно используются службами сервера для предоставления программного доступа к приложениям, но также могут применяться для входа в системы в целях администрирования. Вызовы, сделанные субъектами-службами, не будут блокироваться политиками условного доступа, применяемыми к пользователям. Используйте условный доступ для удостоверений рабочей нагрузки, чтобы определить политики, нацеленные на субъекты-службы.
  • Если в вашей организации эти учетные записи используются в сценариях или в коде, попробуйте заменить их управляемыми удостоверениями.

Задайте правильные вопросы

Ниже приведены частые вопросы и ответы о назначениях и элементах управления доступом. Задокументируйте ответы на вопросы о каждой политике, прежде чем создавать ее.

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

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

Облачные приложения или действия

Будет ли эта политика применяться к любому приложению, действию пользователя или контексту аутентификации? Если да:

• К каким приложениям или службам применяется политика?
• Какие действия пользователей применяются к этой политике?
• Какие контексты проверки подлинности будут применяться к этой политике?

Фильтрация приложений

Использование фильтра для приложений для включения или исключения приложений вместо того, чтобы отдельно указывать их , помогает организациям:

• Легко масштабировать и ориентироваться на любое количество приложений.
• Легко управлять приложениями с аналогичными требованиями политики.
• Уменьшите количество отдельных политик.
• Уменьшите ошибки при редактировании политик: не нужно добавлять и удалять приложения вручную из политики. Просто управляйте атрибутами.
• Преодолеть ограничения размера политики.

Условия

• Какие платформы устройств включены или исключены из политики?
• Что такое известные сетевые расположения организации?
  • Какие расположения включены или исключены из политики?
• Какие типы клиентских приложений включены или исключены из политики?
• Нужно ли использовать определенные атрибуты устройства?
• Если вы используете Защита идентификации Microsoft Entra, вы хотите включить риск входа или пользователя?

Блокировать или предоставлять элементы управления

Вы хотите предоставлять доступ к ресурсам с использованием одного из следующих способов?

• Многофакторная проверка подлинности
• Устройство, отмеченное как соответствующее требованиям
• Использование гибридного устройства, присоединенного к Microsoft Entra
• Использование утвержденного клиентского приложения
• применена политика защита приложений
• Изменение пароля
• Условия использования приняты

Блокировка доступа — это мощный элемент управления, который следует применять, имея соответствующие знания. Политики с блочными операторами могут иметь непредвиденные побочные эффекты. Правильное тестирование и проверка крайне важны перед включением элемента управления в большом масштабе. При внесении изменений администраторы должны использовать такие средства, как режим "только отчет" условного доступа и What If с условным доступом.

Элементы управления сеансов

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

• Использовать ограничения на уровне приложений
• Использовать Управление условным доступом к приложениям
• Контроль частоты входа.
• Использование постоянных сеансов браузера.
• Настройка непрерывной оценки доступа

Объединение политик

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

Маркеры доступа выдаются по умолчанию, если условие политики условного доступа не активирует управление доступом.

Эта политика не препятствует приложению иметь собственную возможность блокировать доступ.

Например, рассмотрим упрощенный пример политики, где:

Пользователи: FINANCE GROUP
Доступ: ПРИЛОЖЕНИЕ PAYROLL
Управление доступом: многофакторная проверка подлинности

• Пользователь A находится в ГРУППЕ FINANCE, для доступа к ПРИЛОЖЕНИю PAYROLL требуется многофакторная проверка подлинности.
• Пользователь B не входит в FINANCE GROUP, выдает маркер доступа и разрешает доступ к приложению PAYROLL, не выполняя многофакторную проверку подлинности.

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

Пользователи: включить всех пользователей / исключить FINANCE GROUP
Доступ: ПРИЛОЖЕНИЕ PAYROLL
Управление доступом: блокировка доступа

Теперь, когда пользователь B пытается получить доступ к приложению PAYROLL, он заблокирован.

Рекомендации

Учитывая наши знания в использовании условного доступа и поддержке других клиентов, ниже приведены некоторые рекомендации на основе наших обучения.

Применение политик условного доступа к каждому приложению

Убедитесь, что к каждому приложению применена хотя бы одна политика условного доступа. С точки зрения безопасности лучше создать политику, которая охватывает все ресурсы (ранее "Все облачные приложения"), а затем исключить приложения, к которым не требуется применять политику. Эта практика гарантирует, что при подключении нового приложения не требуется обновлять политики условного доступа.

Сокращение числа политик условного доступа

Создание политики для каждого приложения неэффективно и усложняет администрирование. Условный доступ имеет ограничение в 195 политик для каждого клиента. Это ограничение политики 195 включает политики условного доступа в любом состоянии, включая режим только для отчетов, вкл.

Рекомендуется проанализировать приложения и сгруппировать приложения с одинаковыми требованиями к ресурсам для одних и тех же пользователей. Например, если все приложения Microsoft 365 или приложения отдела кадров имеют одинаковые требования для одних и тех же пользователей, создайте одну политику и включите в нее все приложения, к которым она применяется.

Политики условного доступа содержатся в JSON-файле, и этот файл привязан к ограничению размера, который мы не ожидаем, что одна политика будет расти дальше. Если в политике используется длинный список идентификаторов GUID, это ограничение может быть достигнуто. Если вы столкнулись с этими ограничениями, рекомендуется использовать следующие варианты:

• Используйте группы или роли для включения или исключения пользователей вместо перечисления каждого пользователя по отдельности.
• Используйте фильтр для приложений, чтобы включить или исключить приложения, а не указывать их по отдельности.

Настройка режима "Только отчет"

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

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

Вы можете просмотреть статистические последствия политик условного доступа в книге "Аналитика и отчеты". Чтобы получить доступ к книге, вам нужна подписка Azure Monitor, и вам нужно передавать журналы входа в рабочую область Log Analytics.

Планирование нарушений

Чтобы снизить риск блокировки во время непредвиденных сбоев, запланируйте стратегии устойчивости для вашей организации.

Включение защищенных действий

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

Задание стандартов именования для политик

Стандарт именования позволит быстро находить нужные политики и понимать их назначение, не открывая настройки политики на портале администрирования Azure. Рекомендуется присвоить политике имя, содержащее:

• порядковый номер;
• Облачные приложения, к ним относятся
• Ответ
• к кому она применяется;
• когда она применяется.

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

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

Стандарты именования для элементов управления аварийным доступом

Помимо активных политик следует определить отключенные политики, которые будут служить дополнительными устойчивыми элементами управления доступом при сбоях или в авариях. Стандарт именования для политик на непредвиденные случаи должен содержать:

• "ENABLE IN EMERGENCY" в начале, чтобы выделить имя среди других политик;
• имя нарушения, к которому должна применяться политика;
• порядковый номер, помогающий администратору узнать, какой по счету должна быть включена эта политика.

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

• EM01 — ВКЛЮЧЕНИЕ В ЧРЕЗВЫЧАЙНОЙ СИТУАЦИИ: нарушение MFA [1/4] — Exchange SharePoint: требуется гибридное присоединение Microsoft Entra для виртуальных IP-пользователей.

Блокировать страны или регионы, из которых вы никогда не ожидаете вход

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

Развертывание политик условного доступа

Когда вы будете готовы, разверните политики условного доступа на этапах.

Создание политик условного доступа

Ознакомьтесь с шаблонами политик условного доступа и общими политиками безопасности для организаций Microsoft 365 для головного запуска. Эти шаблоны удобны для развертывания рекомендаций Майкрософт. Обязательно исключите учетные записи для экстренного доступа.

Оценка применения политики

Мы рекомендуем использовать следующие средства для оценки влияния политик как до, так и после внесения изменений. Имитированное выполнение дает хорошее представление о влиянии политики условного доступа, она не заменяет фактическое тестовое выполнение в правильно настроенной среде разработки.

• Режим только для отчетов и книга "Аналитика условного доступа" и "Отчеты".
• Средство "Что если"

Тестирование политик

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

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

Развертывание в рабочей среде

После подтверждения влияния с помощью режима только для отчетов администратор может переместить переключатель политики "Включить" из "Только отчет " в "Вкл".

Откат политик

Если требуется выполнить откат примененных новых политик, попробуйте осуществить одно или несколько из следующих действий.

• Отключите политику. Отключение политики гарантирует, что она не применяется при попытке пользователя выполнить вход. Вы всегда можете вернуться и включить политику, когда потребуется ее использовать.

• Исключите пользователя или группу из политики. Если пользователь не может получить доступ к приложению, попробуйте исключить его из политики.

  Внимание

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

• Если политика отключена и больше не требуется, удалите ее.

Устранение неполадок политик условного доступа

Если у пользователя возникла проблема с политикой условного доступа, соберите следующие сведения, чтобы упростить устранение неполадок.

• Имя субъекта-пользователя
• отображаемое имя пользователя;
• Операционная система
• метка времени (допускается приблизительное время);
• Целевое приложение
• тип клиентского приложения (браузер или клиент);
• Идентификатор корреляции (этот идентификатор является уникальным для входа)

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

После сбора сведений ознакомьтесь со следующими ресурсами:

• Проблемы при входе в систему с условным доступом. Общие сведения о непредвиденных результатах входа, связанных с условным доступом , с помощью сообщений об ошибках и журнала входа Microsoft Entra.
• Использование инструмента what-if. Описывается, почему политика была или не была применена к пользователю в определенном случае или почему она будет применена в известном состоянии.

Связанный контент

• Подробнее о многофакторной проверке подлинности
• Дополнительные сведения о Защита идентификации Microsoft Entra
• Управление политиками условного доступа с помощью вызовов API Microsoft Graph