Использование ограничений клиентов для управления доступом к облачным приложениям SaaS

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

Решением, которое Azure Active Directory (Azure AD) предлагает для этой задачи, является функция, называемая ограничением клиентов. Ограничение клиентов позволяет организациям управлять доступом к облачным приложениям SaaS на основе клиента Azure AD, используемого приложениями для единого входа. Например, можно разрешить доступ к приложениям Microsoft 365 в своей организации, но запретить доступ к экземплярам тех же приложений для других организаций.

Ограничение клиентов дает организациям возможность указать список клиентов, доступ к которым разрешен пользователям. После этого Azure AD только предоставляет доступ к этим разрешенным клиентам.

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

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

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

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

  1. Azure AD: если используется заголовок Restrict-Access-To-Tenants: <permitted tenant list>, то Azure AD только выдает маркеры безопасности разрешенным клиентам.

  2. Инфраструктура локального прокси-сервера. Эта инфраструктура является прокси-сервером, поддерживающим проверку по протоколу TLS. Вам необходимо настроить прокси-сервер для вставки заголовка, содержащего список разрешенных клиентов, в трафик, предназначенный для Azure AD.

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

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

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

Схема движения трафика при использовании ограничения клиентов

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

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

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

Чтобы использовать ограничение клиентов, ваши клиенты должны иметь возможность подключаться к следующим URL-адресам Azure AD для прохождения аутентификации: login.microsoftonline.com, login.microsoft.com, и login.windows.net. Кроме того, для доступа к Office 365 клиенты также должны подключаться к полным доменным именам (FQDN), URL-адресам и IP-адресам, определенным на странице URL-адреса и диапазоны IP-адресов Office 365.

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

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

Предварительные требования

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

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

  • Для использования ограничений клиента требуются лицензии Azure AD Premium 1.

Конфигурация

Для каждого исходящего запроса к login.microsoftonline.com login.microsoft.com и login.windows.net следует вставлять два заголовка HTTP: Restrict-Access-To-Tenants и Restrict-Access-Context.

Примечание

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

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

  • Для Ограничения доступа клиентам используйте значение <permitted tenant list>списка клиентов, имеющих разрешения, который представляет собой разделенный запятыми список клиентов, доступ к которым нужно разрешить пользователям. Идентифицировать клиента в этом списке можно с помощью любого домена, зарегистрированного в клиенте. В качестве примера всех трех способов описания клиента пара "имя-значение", которая предоставляет разрешение Contoso, Fabrikam и Майкрософт, выглядит следующим образом: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,72f988bf-86f1-41af-91ab-2d7cd011db47

  • Для Restrict-Access-Context используйте значение отдельного идентификатора каталога, объявляющего, какой клиент устанавливает ограничение клиентов. Например, чтобы заявить Contoso в качестве клиента, устанавливающего политику ограничения клиентов, используются пары "имя-значение" следующего вида:Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d. Чтобы получить журналы для этих проверок подлинности, здесь необходимо использовать собственный идентификатор каталога.

Совет

Идентификатор каталога вы можете найти на портале Azure Active Directory. Войдите в качестве администратора, выберите Azure Active Directory слева, затем выберите Свойства.

Чтобы проверить, что идентификатор каталога или имя домена относятся к одному и тому же клиенту, используйте их вместо в этом 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, пользователь увидит сообщение об отказе в доступе, в котором говорится о попытке получить доступ к ресурсу, принадлежащему организации, неутвержденной вашим ИТ-отделом.

Сообщение об ограничениях клиента (апрель 2021 г.)

Возможности для администраторов

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

  1. Войдите на портал Azure Active Directory. Откроется панель мониторинга центра администрирования Azure Active Directory.

  2. В области слева выберите Azure Active Directory. Появится страница с общими сведениями об Azure Active Directory.

  3. На странице обзора выберите Ограничения клиента.

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

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

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

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

Поддержка Microsoft 365

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

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

Ознакомьтесь со статьей Updated Office 365 modern authentication (Обновление поддержи современной аутентификации в Office 365), чтобы получить последние сведения о том, какие клиенты Office сейчас поддерживают современную аутентификацию. На этой странице также указаны ссылки на инструкции по включению современной аутентификации для конкретных клиентов Exchange Online и Skype для бизнеса Online. Современная аутентификация уже включена по умолчанию в SharePoint Online.

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

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

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

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

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

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

На что распространяется блокировка, накладываемая заголовком

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

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

Дальнейшие действия