Ограничение доступа к арендатору

Крупные организации, уделяющие особое внимание безопасности, стремятся перейти на облачные службы, такие как Microsoft 365, но им необходимы гарантии, что их пользователи смогут получить доступ только к утвержденным ресурсам. В большинстве случаев для управления доступом компании ограничивают доменные имена или IP-адреса. Этот подход завершается ошибкой в мире, где приложения как услуга (или SaaS) размещаются в общедоступном облаке, выполняя общие доменные имена, такие как outlook.office.com и login.microsoftonline.com. Блокирование этих адресов полностью запретит пользователям интернет-доступ к Outlook, а не просто ограничит его в соответствии с утвержденными удостоверениями и ресурсами.

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

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

В этой статье рассматриваются ограничения клиента для Microsoft 365, но эта функция защищает все приложения, отправляющие пользователя в Microsoft Entra ID для единого входа. Если вы используете приложения SaaS с другим клиентом Microsoft Entra от клиента, используемого microsoft 365, убедитесь, что все необходимые клиенты разрешены. (Например, в сценариях совместной работы B2B). Дополнительные сведения об облачных приложениях SaaS см. на сайте Active Directory Marketplace.

Функция ограничений клиента также поддерживает блокировку использования всех потребительских приложений Майкрософт (приложений MSA), таких как OneDrive, Hotmail и Xbox.com. Эта функция использует отдельный заголовок конечной login.live.com точки и подробно описана в конце этой статьи.

Принцип работы

В общих чертах решение состоит из следующих компонентов.

1. Идентификатор Microsoft Entra: если заголовок Restrict-Access-To-Tenants: <permitted tenant list> присутствует, microsoft Entra-only выдает маркеры безопасности для разрешенных клиентов.

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

3. Клиентское программное обеспечение. Для поддержки ограничений клиентов клиентское программное обеспечение должно запрашивать маркеры непосредственно из идентификатора Microsoft Entra, чтобы прокси-инфраструктура может перехватывать трафик. Ограничение клиентов в настоящее время поддерживается браузерными приложениями Office 365 и клиентами Office при использовании современной проверки подлинности (например, OAuth 2.0).

4. Современная проверка подлинности: облачные службы должны использовать современную проверку подлинности для использования ограничений клиента и блокировать доступ ко всем неинтермитированным клиентам. Облачные службы Office 365 необходимо настроить для использования протоколов современной проверки подлинности по умолчанию. Последние сведения о поддержке современной проверке подлинности в Microsoft 365 см. в записи блога об обновленной поддержке современной проверки подлинности Office 365.

На следующей схеме показан общий маршрут прохождения трафика. Ограничения клиента требуют проверки TLS только на трафик к идентификатору Microsoft Entra, а не к облачным службам Microsoft 365. Это важно, так как объем трафика для проверки подлинности с идентификатором Microsoft Entra обычно значительно ниже, чем объем трафика для приложений SaaS, таких как Exchange Online и SharePoint Online.

Настройка ограничения клиентов

Чтобы приступить к работе с ограничением клиентов, нужно выполнить два шага. Первый — убедиться, что ваши клиенты могут подключиться к соответствующим адресам. Второй — настроить инфраструктуру прокси-сервера.

URL-адреса и IP-адреса

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

• login.microsoftonline.com
• login.microsoft.com
• login.windows.net

Кроме того, для доступа к Office 365 клиенты также должны подключаться к полным доменным именам (FQDN), URL-адресам и IP-адресам, определенным на странице URL-адреса и диапазоны IP-адресов Office 365.

Конфигурация и требования прокси-сервера

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

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

• Прокси-сервер должен поддерживать перехват TLS, вставку заголовка HTTP и фильтрацию назначения с использованием FQDN или URL-адресов.

• Клиенты должны доверять цепочке сертификатов, представляемой прокси-сервером для взаимодействия по протоколу TLS. Например, если используются сертификаты из внутренней инфраструктуры открытых ключей (PKI), то сертификаты, выдаваемые внутренним корневым центром сертификации, должны быть доверенными.

• Лицензии Microsoft Entra ID P1 или P2 требуются для использования ограничений клиента.

Настройка

Для каждого исходящего запроса в ,и вставьте два заголовка HTTP: ограничить доступ к клиентам и ограничить доступ к контексту.login.windows.netlogin.microsoft.comlogin.microsoftonline.com

Примечание.

Не включайте поддомены в *.login.microsoftonline.com в конфигурацию прокси-сервера. Это будет включать device.login.microsoftonline.com и будет препятствовать проверке подлинности сертификата клиента, которая используется в сценариях регистрации устройств и условного доступа на основе устройств. Настройте прокси-сервер для исключения и enterpriseregistration.windows.net проверки device.login.microsoftonline.com прерывания и проверки TLS и внедрения заголовков.

Эти заголовки должен содержать следующие элементы.

• Для Restrict-Access-To-Tenants используйте значение <permitted tenant list>, которое представляет собой разделенный запятыми список клиентов, доступ к которым нужно разрешить пользователям. Любой домен, зарегистрированный в клиенте, можно использовать для идентификации клиента в этом списке и самого идентификатора каталога. В качестве примера всех трех способов описания клиента пара "имя-значение", которая предоставляет разрешение Contoso, Fabrikam и Майкрософт, выглядит следующим образом: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,aaaabbbb-0000-cccc-1111-dddd2222eeee

• Для Restrict-Access-Context используйте значение отдельного идентификатора каталога, объявляющего, какой клиент устанавливает ограничение клиентов. Например, чтобы заявить Contoso в качестве клиента, устанавливающего политику ограничения клиентов, используются пары "имя-значение" следующего вида:Restrict-Access-Context: bbbbcccc-1111-dddd-2222-eeee3333ffff. Чтобы получить журналы для этих проверок подлинности, здесь нужно использовать собственный идентификатор каталога. Если вы используете любой идентификатор каталога, отличный от собственного, журналы входа *отображаются в клиенте другого пользователя, при этом все персональные данные удалены. Дополнительные сведения см. в разделе Возможности для администраторов.

Чтобы найти идентификатор каталога, выполните приведенные далее действия.

1. Войдите в Центр администрирования Microsoft Entra как минимум глобальный читатель.
2. Обзор удостоверений>>.
3. Скопируйте значение идентификатора клиента.

Чтобы убедиться, что идентификатор каталога или имя домена относятся к одному и тому же арендатору, используйте их вместо элемента <tenant> в этом URL-адресе: https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration. Если результаты с доменом и идентификатором совпадают, они содержат ссылки на один и тот же клиент.

Чтобы запретить пользователям вставлять собственный заголовок HTTP с неутвержденными клиентами, прокси-сервер должен заменить заголовок Restrict-Access-To-Tenants , если он уже присутствует в входящего запроса.

Клиенты должны быть вынуждены использовать прокси-сервер для всех запросов , login.microsoftonline.comlogin.microsoft.comа также login.windows.net. Например, если для указания клиентам использовать прокси-сервер применяются PAC-файлы, то пользователи не должны иметь возможности изменить или отключить эти файлы.

Взаимодействие с пользователями

В этом разделе описано взаимодействие с пользователями и администраторами.

Взаимодействие с конечным пользователем

Например, пользователь находится в сети компании Contoso, но пытается получить доступ к экземпляру Fabrikam такого общего приложения SaaS, как Outlook в Интернете. Если Fabrikam является неинтерпретированным клиентом для экземпляра Contoso, пользователь видит сообщение об отказе в доступе. Сообщение об отказе говорит, что вы пытаетесь получить доступ к ресурсу, который принадлежит организации, не утвержденной ИТ-отделом.

Интерфейс администратора

Хотя настройка ограничений клиента выполняется в корпоративной прокси-инфраструктуре, администраторы могут напрямую получить доступ к отчетам об ограничениях клиента в Центре администрирования Microsoft Entra. Для просмотра отчетов выполните следующие действия:

1. Войдите в Центр администрирования Microsoft Entra как минимум глобальный читатель.
2. Перейдите к ограничениям клиента обзора>удостоверений.>

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

Отчет может содержать ограниченные сведения, такие как идентификатор целевого каталога, когда пользователь, который находится в клиенте, отличном от клиента с ограниченным доступом к контексту, входит в систему. В этом случае определяемые пользователем сведения, такие как имя и имя участника-пользователя, маскируются для защиты данных пользователей в других клиентах (например, "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 вместо имен пользователей и идентификаторов объектов в соответствии с соответствующими параметрами).

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

• Пользователь — это поле может удалить персональные данные, где его значение равно 00000000-0000-0000-0000-000000000000.
• Приложение
• Состояние
• Дата
• Дата (UTC), где UTC — это время в формате UTC.
• IP Address
• Клиент
• Имя пользователя — это поле может удалить персональные данные, где его значение равно {PII Removed}@domain.com
• Местонахождение
• ИД целевого клиента.

Поддержка Microsoft 365

Приложения Office 365 должны соответствовать двум условиям для полной поддержки ограничения клиентов:

1. Используемый клиент должен поддерживать современную аутентификацию.
2. Современная аутентификация должна использоваться по умолчанию для облачной службы.

Последние сведения о том, какие клиенты Office в настоящее время поддерживают современную проверку подлинности, см. в статье "Обновленная современная проверка подлинности Office 365". На этой странице также указаны ссылки на инструкции по включению современной аутентификации для конкретных клиентов Exchange Online и Skype для бизнеса Online. Современная аутентификация уже включена по умолчанию в SharePoint Online. Teams поддерживает только современную проверку подлинности и не поддерживает устаревшую проверку подлинности, поэтому эта проблема обхода не применяется к Teams.

Приложения на основе браузера Microsoft 365 (такие как портал Office, Yammer, сайты SharePoint и Outlook в Интернете).) в настоящее время поддерживают ограничения клиентов. Толстые клиенты (Outlook, Skype для бизнеса, Word, Excel, PowerPoint и др.) могут применять ограничения клиента только при использовании современной проверки подлинности.

Outlook и Skype для бизнеса клиенты, поддерживающие современную проверку подлинности, по-прежнему могут использовать устаревшие протоколы для клиентов, где современная проверка подлинности не включена, эффективно обходя ограничения клиентов. Ограничения клиента могут блокировать приложения, использующие устаревшие протоколы, если они связываются login.microsoftonline.comили login.microsoft.comlogin.windows.net во время проверки подлинности.

Для Outlook в Windows клиенты могут реализовать ограничения, которые не позволяют конечным пользователям добавлять в профили неутвержденные учетные записи почты. Например, ознакомьтесь с параметром групповой политики "Запрет добавления учетных записей Exchange, не являющихся неотделаными".

Несовместимость Azure RMS и шифрования сообщений Office

Функции шифрования сообщений Office и Службы управления правами Azure (Azure RMS) несовместимы с ограничениями клиента. Эти функции подписывают ваших пользователей в других арендаторах, чтобы получить ключи расшифровки для зашифрованных документов. Поскольку ограничения клиентов блокируют доступ к другим клиентам, зашифрованная почта и документы, отправленные пользователям из ненадежных клиентов, недоступны.

Тестирование

Если вы хотите опробовать политику ограничения клиентов перед ее внедрением во всей организации, существует два варианта: подход на основе узлов с использованием такого инструмента, как Fiddler, или поэтапное развертывание параметров прокси-сервера.

Использование Fiddler для подхода на основе узлов

Fiddler — это бесплатный прокси-сервер веб-отладки, который можно использовать для записи и изменения трафика HTTP/HTTPS, который включает вставку заголовков HTTP. Чтобы настроить Fiddler для проверки ограничения клиентов, выполните следующие действия:

1. Скачайте и установите Fiddler.

2. Настройте Fiddler для расшифровки трафика HTTPS, как описано в справочной документации по Fiddler.

3. Настройте Fiddler для вставки заголовков Restrict-Access-To-Tenants и Restrict-Access-Context с помощью настраиваемых правил.

   1. В инструменте Fiddler Web Debugger выберите меню Rules (Правила) и щелкните Customize Rules (Настройка правил…), чтобы открыть файл CustomRules.

   2. Добавьте следующие строки в функцию OnBeforeRequest . Замените <список идентификаторов арендаторов> доменом, зарегистрированным в вашем арендаторе (например, contoso.onmicrosoft.com). Замените <идентификатор каталога идентификатором> GUID Microsoft Entra клиента. Чтобы журналы отображались в клиенте, необходимо указать правильный идентификатор GUID.

    // Allows access to the listed tenants.
      if (
          oSession.HostnameIs("login.microsoftonline.com") ||
          oSession.HostnameIs("login.microsoft.com") ||
          oSession.HostnameIs("login.windows.net")
      )
      {
          oSession.oRequest["Restrict-Access-To-Tenants"] = "<List of tenant identifiers>";
          oSession.oRequest["Restrict-Access-Context"] = "<Your directory ID>";
      }
   
    // Blocks access to consumer apps
      if (
          oSession.HostnameIs("login.live.com")
      )
      {
          oSession.oRequest["sec-Restrict-Tenant-Access-Policy"] = "restrict-msa";
      }
   

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

   oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";

4. Сохраните и закройте файл CustomRules.

После настройки Fiddler можно начать записывать трафик, перейдя в меню File (Файл) и выбрав Capture Traffic (Запись трафика).

Поэтапное развертывание параметров прокси-сервера

В зависимости от возможностей инфраструктуры прокси-сервера вы можете выполнить развертывание параметров для пользователей. Дополнительные сведения см. в следующих общих вариантах.

1. Используйте PAC-файлы, чтобы направить тестовых пользователей в тестовую инфраструктуру прокси-сервера, а обычные пользователи пусть продолжат использовать рабочую инфраструктуру прокси-сервера.
2. Некоторые прокси-серверы могут поддерживать разные конфигурации с помощью групп.

Обратитесь к документации по вашему прокси-серверу, чтобы получить подробную информацию.

Блокировка потребительских приложений

Приложения от корпорации Майкрософт, которые поддерживают как учетные записи пользователей, так и учетные записи организаций, такие как OneDrive или Microsoft Learn, иногда могут размещаться по одному URL-адресу. Это означает, что пользователи, которые должны получить доступ к этому URL-адресу для рабочих целей, также имеют доступ к нему для личного использования. Этот параметр может быть запрещен в соответствии с вашими рекомендациями по работе.

Некоторые организации пытаются устранить эту проблему, блокируя login.live.com проверку подлинности личная учетная запись. Это исправление имеет несколько недостатков:

1. При блокировке login.live.com блокируется использование личных учетных записей в гостевых сценариях B2B, что может помешать действиям посетителей и нарушить совместную работу.
2. Для развертывания Autopilot требуется использование login.live.com. При блокировке login.live.com сценарии работы с Intune и Autopilot могут завершаться сбоем.
3. Обновления телеметрии организации и Windows, использующие службу login.live.com для идентификаторов устройств, перестают работать.

Конфигурация потребительских приложений

Хотя заголовок Restrict-Access-To-Tenants действует как список разрешений, блокировка учетной записи Майкрософт (MSA) служит неким сигналом запрета, который указывает платформе учетных записей Майкрософт не разрешать пользователям входить в потребительские приложения. Чтобы отправить этот сигнал, заголовок внедряется в трафик, посещаемый login.live.com с помощью того же корпоративного прокси-сервера или брандмауэра, sec-Restrict-Tenant-Access-Policy как упоминалось в разделе конфигурации прокси-сервера и требований этой статьи. Для заголовка должно быть установлено значение restrict-msa. Если заголовок присутствует, и приложение-получатель пытается выполнить вход пользователя напрямую, этот вход блокируется.

В настоящее время проверка подлинности для потребительских приложений не отображается в журналах администратора, так как login.live.com размещается отдельно от идентификатора Microsoft Entra.

Что делает заголовок и не блокирует

Политика restrict-msa блокирует работу потребительских приложений, но позволяет использовать несколько других типов трафика и проверки подлинности:

1. Трафик без пользователей для устройств. Этот параметр включает трафик для Autopilot, Обновл. Windows и телеметрии организации.
2. Проверка подлинности B2B для учетных записей потребителей. Пользователи с учетными записями Майкрософт, которые приглашены для совместной работы в клиенте, проходят проверку подлинности в login.live.com, чтобы получить доступ к клиенту ресурса.
   1. Этот доступ контролируется с помощью заголовка Restrict-Access-To-Tenants, разрешающего или запрещающего доступ к этому клиенту ресурса.
3. Проверка подлинности passthrough, используемая многими приложениями Azure и Office.com, где приложения используют идентификатор Microsoft Entra для входа пользователей-потребителей в контексте потребителя.
   1. Этот доступ также контролируется с помощью заголовка Restrict-Access-To-Tenants, разрешающего или запрещающего доступ к специальному "транзитному" клиенту (f8cdef31-a31e-4b4a-93e4-5f571e91255a). Если этот клиент не отображается в Restrict-Access-To-Tenants списке разрешенных доменов, идентификатор Microsoft Entra блокирует вход учетных записей потребителей в эти приложения.

Платформы, которые не поддерживают прерывание TLS и проверку

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

Пример Android 7.0 и более поздних версий. Android изменил способ обработки доверенных центров сертификации (ЦС), чтобы обеспечить безопасные значения по умолчанию для безопасного трафика приложений. Дополнительные сведения см. в разделе "Изменения доверенных центров сертификации" в Android Nougat.

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

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

• Условный доступ. Разрешить использование управляемых или совместимых устройств
• Условный доступ: управление доступом для гостевых и внешних пользователей
• Совместная работа B2B. Ограничение исходящего доступа между клиентами для одного и того же клиента, указанного в параметре "Ограничить доступ к клиентам"
• Совместная работа B2B. Ограничение приглашений пользователям B2B на те же домены, перечисленные в параметре "Ограничить доступ к клиентам"
• Управление приложениями: ограничение согласия пользователей на приложения
• Intune: применение политики приложений через Intune для ограничения использования управляемых приложений только имени участника-пользователя учетной записи, зарегистрированной на устройстве . Проверьте раздел в разделе " Разрешить только настроенные учетные записи организации в подзаголовке приложений ".

Однако некоторые конкретные сценарии можно охватывать только с помощью ограничений клиента.

Следующие шаги

• Ознакомьтесь со статьей Updated Office 365 modern authentication (Обновление поддержи современной аутентификации в Office 365).
• Прочтите статью URL-адреса и диапазоны IP-адресов Office 365.