Система условного доступа и политики
В этой статье представлена структура для реализации архитектуры условного доступа на основе персон, например архитектуры условного доступа, описанной в архитектуре условного доступа нулевого доверия. В этой статье содержатся сведения о том, как формировать и называть политики условного доступа. Существует также отправная точка для создания политики.
Если вы не используете платформу, например указанную здесь, включая стандарт именования, политики, как правило, создаются различными людьми в нерегламентированном режиме. Это может привести к пересечению политик. Если пользователь, создавший политику, больше недоступен, может быть трудно узнать назначение политики другим пользователям.
Соблюдение структурированной рамки упрощает понимание правил. Это также упрощает охватывание всех сценариев и помогает избегать противоречащих политик, которые трудно устранить.
Соглашения об именовании
Правильно определенное соглашение об именовании помогает вам и вашим коллегам понять назначение политики, что упрощает управление политиками и устранение неполадок. Ваши правила именования должны соответствовать структуре, которую вы используете для оформления своих политик.
Рекомендуемая политика именования основана на пользователях, типах политик и приложениях. Выглядит следующим образом:
<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<Необязательный>
Ниже описаны компоненты этого имени:
| Компонент именования | Описание и пример |
|---|---|
| Номер CA | Используется для быстрого определения области и порядка типов политики. Пример: CA001-CA099. |
| Персона | Глобальные, Администраторы, Внутренние, Внешние, ГостевыеПользователи, ГостевыеАдминистраторы, УчетныеЗаписиСлужбыMicrosoft365, УчетныеЗаписиСлужбыAzure, КорпоративныеУчетныеЗаписиСлужбы. |
| Тип политики | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Соответствие. |
| Приложение | AllApps, O365 (для всех служб Office 365), EXO (для Exchange Online). |
| Платформа | AnyPlatform, Unknown, WindowsPhone, macOS, iOS, Android. |
| Элемент управления Grant | Блокировать, ADHJ, совместимый, неуправляемый (где неуправляемый указан в состоянии состояния устройства). |
| Описание | Необязательное описание цели политики. |
Схема нумерирования
Чтобы упростить администрирование, мы предлагаем эту схему нумерации:
| Группа Persona | Распределение номеров |
|---|---|
| ЦС-Persona-Global | CA001-CA099 |
| CA-Persona-Admins | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| ЦА-Persona-Externals | CA300-CA399 |
| ЦА-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| ЦС-Persona-M365ServiceAccounts | CA600-CA699 |
| ЦС-Persona-AzureServiceAccounts | CA700-CA799 |
| ЦА-Persona-CorpServiceAccounts | CA800-CA899 |
| ЦС-Persona-WorkloadIdentities | CA900-CA999 |
| ЦС-Persona-Developers | CA1000-CA1099 |
Типы политик
Это рекомендуемые типы политик:
| Тип политики | Описание и примеры |
|---|---|
| BaseProtection | Для каждого пользователя существует базовая защита, которая охватывает этот тип политики. Для пользователей на управляемых устройствах обычно это известный пользователь и известное устройство. Для внешних гостей может быть известен пользователь и многофакторная проверка подлинности. Базовая защита — это политика по умолчанию для всех приложений для пользователей в заданной персоне. Если определенное приложение должно иметь другую политику, исключите это приложение из базовой политики защиты и добавьте явную политику, предназначенную только для этого приложения. Пример. Предположим, что базовая защита внутренних служб требует наличия известного пользователя и известного устройства для всех облачных приложений, но вы хотите разрешить Outlook в Интернете с любого устройства. Вы можете исключить Exchange Online из базовой политики защиты и добавить отдельную политику для Exchange Online, где требуется известная проверка подлинности устройства ИЛИ многофакторная проверка подлинности. |
| Защита идентичности | В дополнение к базовой защите для каждого пользователя, вы можете использовать политики условного доступа, связанные с идентификацией. Примеры: блокировка устаревшей проверки подлинности, требуется дополнительная многофакторная проверка подлинности для высокого уровня риска пользователя или входа, требуется известное устройство для регистрации многофакторной проверки подлинности. |
| Защита данных | Этот тип политики указывает на дельта-политики, которые защищают данные в качестве дополнительного слоя поверх базовой защиты. Примеры:
|
| AppProtection | Этот тип политики является еще одним дополнением к базовой защите. Примеры:
|
| СнижениеАтакующейПоверхности | Целью этой политики является устранение различных атак. Примеры:
|
| Согласие | Политику соответствия можно использовать для обязательного ознакомления пользователей с условиями использования для гостей, имеющих доступ к услугам клиентов. |
Приложение
В следующей таблице описывается компонент приложения имени политики:
| Имя приложения | Описание и примеры |
|---|---|
| AllApps | AllApps означает, что все облачные приложения входят в область действия политики условного доступа. Рассматриваются все конечные точки, включая те, которые поддерживают условный доступ и те, которые не поддерживают. В некоторых случаях целеполагание всех приложений неэффективно. Мы рекомендуем нацеливать все приложения в рамках базовой политики, чтобы все конечные точки охватывались этой политикой. Новые приложения, которые отображаются в идентификаторе Microsoft Entra, также автоматически соответствуют политике. |
| <AppName> |
<AppName> — это заполнитель для имени приложения, к которому относится политика. Избегайте слишком длинного имени. Примеры имен:
|
Тип платформы
В следующей таблице описывается компонент платформы названия политики:
| Тип платформы | Описание |
|---|---|
| AnyPlatform | Политика предназначена для любой платформы. Обычно вы настраиваете это, выбирая любое устройство. (В политиках условного доступа используются как слово платформы, так и слово устройства.) |
| iOS | Политика предназначена для платформ Apple iOS. |
| Андроид | Политика предназначена для платформ Google Android. |
| Виндоус | Эта политика предназначена для платформы Windows. |
| Линукс | Эта политика предназначена для платформ Linux. |
| WindowsPhone | Политика предназначена для платформ Windows Phone. |
| macOS | Политика предназначена для платформ macOS |
| iOSAndroid | Политика предназначена как для платформ iOS, так и для Android. |
| Неизвестный | Политика предназначена для любой платформы, не указанной ранее. Обычно это можно настроить, выбрав Any Device и исключив все отдельные платформы. |
Предоставление типов элементов управления
В следующей таблице описывается компонент Элемента управления грантом имени политики:
| Тип предоставления | Описание и примеры |
|---|---|
| Блок | Политика блокирует вход |
| МИД | Для политики требуется многофакторная проверка подлинности. |
| Податливый | Для применения политики требуется соответствующее устройство, определяемое Endpoint Manager, поэтому устройство должно находиться под управлением Endpoint Manager. |
| Соответствие требованиям AADHJ | Для политики требуется соответствующее устройство или гибридное устройство, присоединенное к Microsoft Entra. Присоединенный к домену стандартный компьютер компании также присоединен к гибридному идентификатору Microsoft Entra. Мобильные телефоны и компьютеры Windows 10, совместно управляемые или присоединенные к Microsoft Entra, могут соответствовать требованиям. |
| Совместимый и AADHJ | Для данной политики требуется устройство, соответствующее требованиям и имеющее гибридное присоединение к Microsoft Entra. |
| Аутентификация или соответствие требованиям (MFAorCompliant) | Для политики требуется совместимое устройство ИЛИ многофакторная проверка подлинности, если устройство не соответствует требованиям. |
| MFA и Соответствие | Политика требует совместимое устройство и многофакторную проверку подлинности. |
| MFAorAADHJ | Для политики требуется, чтобы компьютер был присоединен к Microsoft Entra гибридным образом, или было осуществлено многофакторное аутентифицирование, если компьютер не является гибридным, присоединенным к Microsoft Entra. |
| MFAandAADHJ | Для правила требуется компьютер с гибридным подключением Microsoft Entra и многофакторная проверка подлинности. |
| ТребоватьУтвержденногоКлиента (RequireApprovedClient) | Для политики требуется утвержденное клиентское приложение. |
| AppProtection | Политика требует защиты приложений |
| Неуправляемые | Политика предназначена для устройств, которые не известны идентификатором Microsoft Entra. Например, этот тип предоставления можно использовать для разрешения доступа к Exchange Online с любого устройства. |
Именованные расположения
Рекомендуется определить эти стандартные расположения для использования в политиках условного доступа:
- Доверенные IP-адреса и внутренние сети. Эти IP-подсети представляют расположения и сети с физическими ограничениями доступа или другими элементами управления, такими как управление компьютерами, проверка подлинности на уровне сети или обнаружение вторжений. Эти расположения более безопасны, поэтому принудительное применение условного доступа может быть расслаблено. Рассмотрите, следует ли включать в это расположение Azure или другие расположения центров обработки данных (IP-адреса) или иметь собственные именованные расположения.
- IP-адреса, доверенные Citrix. Если у вас есть Citrix в локальной среде, может быть полезно настроить отдельные исходящие IPv4-адреса для ферм Citrix, если необходимо иметь возможность подключаться к облачным службам из сеансов Citrix. В этом случае, при необходимости, можно исключить эти расположения из политик условного доступа.
- Расположения Zscaler, если это применимо. На компьютеры установлен агент ZPA, который перенаправляет весь трафик на интернет и через облако Zscaler. Поэтому стоит определить IP-адреса источников Zscaler в условной политике доступа и требовать, чтобы все запросы с немобильных устройств проходили через Zscaler для обеспечения безопасности.
- Страны и регионы, с которыми можно разрешить бизнес. Это может быть полезно для разделения стран и регионов на две группы расположения: одна, представляющая области мира, где сотрудники обычно работают, и один из них представляет другие расположения. Это позволяет применять дополнительные элементы управления к запросам, поступающим извне областей, где обычно работает ваша организация.
- Расположения, в которых многофакторная проверка подлинности может быть сложной или невозможной. В некоторых сценариях необходимость многофакторной проверки подлинности может затруднить работу сотрудников. Например, сотрудники могут не иметь времени или возможности реагировать на частые многофакторные вызовы проверки подлинности. Или, в некоторых местах, скрининг RF или электрические помехи могут затруднить использование мобильных устройств. Как правило, вы используете другие элементы управления в этих расположениях или они могут быть доверенными.
Элементы управления доступом на основе расположения зависят от исходного IP-адреса запроса, чтобы определить расположение пользователя во время запроса. Трудно осуществлять спуфинг в общедоступном интернете, но защита, обеспечиваемая границами сети, может считаться менее значимой, чем раньше. Мы не рекомендуем полагаться исключительно на расположение в качестве условия для доступа. Но в некоторых сценариях это может быть лучший элемент управления, который можно использовать, например, если вы обеспечиваете защиту доступа из учетной записи службы из локальной среды, которая используется в неинтерактивном сценарии.
Рекомендуемые политики условного доступа
Мы создали электронную таблицу, содержащую рекомендуемые политики условного доступа. Вы можете скачать электронную таблицу здесь.
Используйте предлагаемые политики в качестве отправной точки.
Ваши политики, вероятно, будут меняться со временем, чтобы учитывать варианты использования, важные для вашего бизнеса. Ниже приведены несколько примеров сценариев, для которых могут потребоваться изменения:
- Реализуйте доступ только для чтения к Exchange Online для сотрудников с помощью любого неуправляемого устройства на основе многофакторной проверки подлинности, защиты приложений и утвержденного клиентского приложения.
- Реализуйте защиту информации, чтобы гарантировать, что конфиденциальная информация не загружается без улучшенной защиты, предоставляемой Azure Information Protection.
- Защита от копирования и вставки гостями.
Несколько предварительных версий в настоящее время входят в общедоступную предварительную версию, поэтому ожидается обновление предлагаемого набора политик запуска условного доступа (ЦС) в ближайшее время.
Руководство по условному доступу
Теперь, когда у вас есть начальный набор политик условного доступа, их необходимо развернуть в управляемом и поэтапном режиме. Мы рекомендуем использовать модель развертывания.
Ниже приведен один подход.
Идея заключается в первом развертывании политик для небольшого количества пользователей в одной группе persona. Для этого развертывания можно использовать связанную группу Microsoft Entra с именем Persona Ring 0. Убедившись, что все работает, вы изменяете назначение на группу Persona Ring 1, в которой больше участников и т. д.
Затем вы включаете политики с использованием того же кольцевого подхода, пока все политики не будут развернуты.
Обычно вы управляете элементами кольца 0 и кольцом 1 вручную. Группа 2 или 3, содержащая сотни или даже тысячи пользователей, может управляться с помощью динамической группы, основанной на процентах пользователей в заданном человеке.
Использование кругов в рамках модели развертывания предназначено не только для начального развертывания. Его также можно использовать, если требуются новые политики или изменения существующих политик.
После завершения развертывания необходимо также разработать и реализовать элементы управления мониторинга, которые были рассмотрены в принципах условного доступа .
Помимо автоматизации первоначального развертывания, может потребоваться автоматизировать изменения политик с помощью конвейеров CI/CD. Для этой автоматизации можно использовать Microsoft365DSC.
Участники
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Основной автор:
- Claus Jespersen | Идентификатор основного консультанта&с
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.