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

Крупные организации, уделяющие особое внимание безопасности, стремятся перейти на облачные службы, такие как Microsoft 365, но им необходимы гарантии, что их пользователи смогут получить доступ только к утвержденным ресурсам. В большинстве случаев для управления доступом компании ограничивают доменные имена или IP-адреса. Этот подход не работает в мире, где приложения по модели SaaS (или 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 выдает токены безопасности для разрешенных арендаторов.

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

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

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

Следующая схема иллюстрирует высокоуровневый поток трафика. Ограничения арендатора требуют проверки TLS только для трафика к Microsoft Entra ID, а не к облачным службам 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 требуются для использования ограничений клиента.

Настройка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Пользователь — это поле может удалить персональные данные, где его значение равно 00000000-0000-0000-0000-000000000000.
• Приложение
• Статус
• Дата
• Дата (UTC) — где UTC расшифровывается как Всемирное координированное время
• IP-адрес
• Клиент
• Имя пользователя — это поле может удалить персональные данные, где его значение равно {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.com или login.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 для вставки заголовков "Ограничить доступ к клиентам " и "Ограничить доступ к контексту " с помощью настраиваемых правил:

   1. В средстве веб-отладчика Fiddler выберите меню "Правила " и выберите пункт "Настроить правила", чтобы открыть файл 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 вы можете записать трафик, перейдя в меню "Файл " и выбрав " Захват трафика".

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

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

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

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

Что заголовок блокирует, а что — нет

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

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

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

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

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

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

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

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

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

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

• Узнайте об обновленной современной проверке подлинности Office 365
• Просмотрите URL-адреса и диапазоны IP-адресов Office 365