Платформа и политики условного доступа
В этой статье представлена платформа для реализации архитектуры условного доступа на основе человека, например архитектуры условного доступа нулевого доверия. В этой статье содержатся сведения о том, как формировать и называть политики условного доступа. Существует также отправная точка для создания политик.
Если вы не используете платформу, например указанную здесь, включая стандарт именования, политики, как правило, создаются различными людьми в нерегламентированном режиме. Это может привести к тому, что политики перекрываются. Если пользователь, создавший политику, больше недоступен, может быть трудно узнать назначение политики другим пользователям.
После структурированной платформы проще понять политики. Это также упрощает работу всех сценариев и избегает конфликтов политик, которые трудно устранить.
Соглашения об именах
Правильно определенное соглашение об именовании помогает вам и вашим коллегам понять назначение политики, что облегчает управление политикой и устранение неполадок. Ваше соглашение об именовании должно соответствовать платформе, которую вы используете для структурирования своих политик.
Рекомендуемая политика именования основана на пользователях, типах политик и приложениях. Он будет выглядеть примерно так:
<CANumber-Persona-PolicyType-App-Platform-GrantControl-OptionalDescription><><><><><><>
Ниже описаны компоненты этого имени:
| Компонент именования | Описание и пример |
|---|---|
| Номер ЦС | Используется для быстрого определения типа политики область и порядка. Пример: CA001-CA099. |
| Пользователь | Global, Администратор, Internals, Externals, GuestUsers, Guest Администратор s, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| Тип политики | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance. |
| Приложение | AllApps, O365 (для всех служб Office 365), EXO (для Exchange Online). |
| Платформа | AnyPlatform, Unknown, Windows Телефон, macOS, iOS, Android. |
| Элемент управления Grant | Блокировать, ADHJ, совместимый, неуправляемый (где неуправляемый указан в состоянии состояния устройства). |
| Description | Необязательное описание цели политики. |
Схема нумерирования
Чтобы упростить администрирование, мы предлагаем эту схему нумерации:
| Группа Persona | Выделение чисел |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Администратор s | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-Guest Администратор s | CA500-CA599 |
| CA-Persona-M365ServiceAccounts | CA600-CA699 |
| CA-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceAccounts | CA800-CA899 |
| CA-Persona-WorkloadIdentities | CA900-CA999 |
| CA-Persona-Developers | CA1000-CA1099 |
Типы политик
Это рекомендуемые типы политик:
| Тип политики | Описание и примеры |
|---|---|
| BaseProtection | Для каждого пользователя существует базовая защита, которая охватывает этот тип политики. Для пользователей на управляемых устройствах обычно это известный пользователь и известное устройство. Для внешних гостей может быть известен пользователь и многофакторная проверка подлинности. Базовая защита — это политика по умолчанию для всех приложений для пользователей в заданной персоне. Если определенное приложение должно иметь другую политику, исключите это приложение из базовой политики защиты и добавьте явную политику, предназначенную только для этого приложения. Пример. Предположим, что базовая защита внутренних служб требует наличия известного пользователя и известного устройства для всех облачных приложений, но вы хотите разрешить Outlook в Интернете с любого устройства. Вы можете исключить Exchange Online из базовой политики защиты и добавить отдельную политику для Exchange Online, где требуется известная проверка подлинности устройства ИЛИ многофакторная проверка подлинности. |
| IdentityProtection | На вершине базовой защиты для каждого пользователя можно использовать политики условного доступа, относящиеся к удостоверениям. Примеры: блокировка устаревшей проверки подлинности, требуется дополнительная многофакторная проверка подлинности для высокого уровня риска пользователя или входа, требуется известное устройство для регистрации многофакторной проверки подлинности. |
| DataProtection | Этот тип политики указывает на разностные политики, которые защищают данные как дополнительный слой на основе базовой защиты. Примеры:
|
| AppProtection | Этот тип политики является еще одним дополнением к базовой защите. Примеры:
|
| AttackSurfaceReduction | Целью этой политики является устранение различных атак. Примеры:
|
| Соблюдение закона | Политику соответствия можно использовать для просмотра условий использования для гостей, обращающихся к службам клиентов. |
Приложение
В следующей таблице описывается компонент приложения имени политики:
| Название приложения | Описание и примеры |
|---|---|
| AllApps | AllApps указывает, что все облачные приложения предназначены в политике условного доступа. Рассматриваются все конечные точки, включая те, которые поддерживают условный доступ и те, которые не поддерживают. В некоторых сценариях назначение всех приложений не работает хорошо. Мы рекомендуем использовать все приложения в базовой политике, чтобы все конечные точки охватывались этой политикой. Новые приложения, которые отображаются в идентификаторе Microsoft Entra, также автоматически соответствуют политике. |
| <AppName> | <AppName> — это заполнитель для имени приложения, адреса политики. Избегайте слишком длинного имени. Примеры имен:
|
Тип платформы
В следующей таблице описывается компонент платформы имени политики:
| Тип платформы | Description |
|---|---|
| AnyPlatform | Политика предназначена для любой платформы. Обычно это настраивается путем выбора любого устройства. (В политиках условного доступа используются как платформа word, так и устройство word.) |
| iOS | Политика предназначена для платформ Apple iOS. |
| Android | Политика предназначена для платформ Google Android. |
| Windows | Эта политика предназначена для платформы Windows. |
| Linux | Эта политика предназначена для платформ Linux. |
| Windows Телефон | Политика предназначена для платформ Windows Телефон. |
| macOS | Политика предназначена для платформ macOS |
| iOSAndroid | Политика предназначена как для платформ iOS, так и для Android. |
| Неизвестно | Политика предназначена для любой платформы, не указанной ранее. Обычно это настраивается путем включения любого устройства и исключения всех отдельных платформ. |
Предоставление типов элементов управления
В следующей таблице описывается компонент Элемента управления грантом имени политики:
| Тип предоставления разрешения | Описание и примеры |
|---|---|
| Блокировка | Политика блокирует вход |
| MFA | Для политики требуется многофакторная проверка подлинности. |
| Соответствует | Для политики требуется соответствующее устройство, определяемое Endpoint Manager, поэтому устройство должно управляться Endpoint Manager. |
| Соответствие требованиямAADHJ | Для политики требуется соответствующее устройство или гибридное устройство, присоединенное к Microsoft Entra. Присоединенный к домену стандартный компьютер компании также присоединен к гибридному идентификатору Microsoft Entra. Мобильные телефоны и компьютеры Windows 10, совместно управляемые или присоединенные к Microsoft Entra, могут соответствовать требованиям. |
| СовместимыйandAADHJ | Для политики требуется устройство, соответствующее требованиям и присоединенное к Microsoft Entra гибридное соединение. |
| MFAorCompliant | Для политики требуется совместимое устройство ИЛИ многофакторная проверка подлинности, если она не соответствует требованиям. |
| MFAandCompliant | Для политики требуется совместимое устройство И многофакторная проверка подлинности. |
| MFAorAADHJ | Для политики требуется гибридная проверка подлинности Microsoft Entra или многофакторная проверка подлинности, если она не является гибридным компьютером, присоединенным к Microsoft Entra. |
| MFAandAADHJ | Для политики требуется гибридный компьютер Microsoft Entra и многофакторная проверка подлинности. |
| RequireApprovedClient | Для политики требуется утвержденное клиентское приложение. |
| AppProtection | Политика требует защиты приложений |
| Неуправляемое | Политика предназначена для устройств, которые не известны идентификатором Microsoft Entra. Например, этот тип предоставления можно использовать для разрешения доступа к Exchange Online с любого устройства. |
Именованные расположения
Рекомендуется определить эти стандартные расположения для использования в политиках условного доступа:
- Доверенные IP-адреса и внутренние сети. Эти IP-подсети представляют расположения и сети с физическими ограничениями доступа или другими элементами управления, такими как управление компьютерами, проверка подлинности на уровне сети или обнаружение вторжений. Эти расположения более безопасны, поэтому принудительное применение условного доступа может быть расслаблено. Рассмотрите, следует ли включать в это расположение azure или другие расположения центров обработки данных (IP-адреса) или собственные именованные расположения.
- Ip-адреса, доверенные citrix-trusted. Если у вас есть 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.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Автор субъекта:
- Клаус Джесперсен | Идентификатор основного консультанта&с
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.