Условный доступ Microsoft Entra: защита токенов (предварительная версия)

Защита маркеров (иногда называемая привязкой маркеров в отрасли) пытается уменьшить атаки с помощью кражи маркеров, гарантируя, что маркер доступен только с предполагаемого устройства. Когда злоумышленник может украсть токен, перехватив его или проведя повторную атаку, он может олицетворять свою жертву до истечения срока действия токена или его отзыва. Кража маркеров считается относительно редким событием, но ущерб от него может быть значительным.

Защита токенов создает криптографически безопасную связь между токеном и устройством (секрет клиента), для которого он предназначен. Без секрета клиента привязанный токен бесполезен. Когда пользователь регистрирует устройство с Windows 10 или более поздней версии в Microsoft Entra ID, его основная учетная запись привязывается к устройству. Это означает: политика может гарантировать, что приложения используют только привязанные маркеры сеанса входа (или обновления), известные также как первичные маркеры обновления (PRT), при запросе доступа к ресурсу.

Требования

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

Следующие устройства и приложения поддерживают возможность доступа к ресурсам, на которых применяется политика условного доступа с защитой токенов.

Поддерживаемые устройства:

• Устройства с Windows 10 или более поздней версии, присоединенные к Microsoft Entra, гибридно присоединенные к Microsoft Entra или зарегистрированные в Microsoft Entra. См. раздел известных ограничений для неподдерживаемых типов устройств.
• Windows Server 2019 или более поздняя версия, подключенные к гибридной среде Microsoft Entra.

Поддерживаемые приложения:

• Клиент синхронизации OneDrive версии 22.217 или более поздней версии
• Собственный клиент Teams версии 1.6.00.1331 или более поздней
• Power BI Desktop версии 2.117.841.0 (май 2023) или новее
• версии модуля Exchange PowerShell 3.7.0 или новее
• Microsoft Graph PowerShell версии 2.0.0 или более поздней с параметром EnableLoginByWAM
• Visual Studio 2022 или более поздней версии при использовании параметра входа брокера проверки подлинности Windows

Известные ограничения

• Бессрочные клиенты Office не поддерживаются.
• Следующие приложения не поддерживают вход с помощью защищенных потоков маркеров, и пользователи блокируются при доступе к Exchange и SharePoint:
  • Модули PowerShell, обращающиеся к SharePoint
  • Расширение PowerQuery для Excel
  • Расширения в Visual Studio Code с доступом к Exchange или SharePoint
• Следующие клиентские устройства Windows не поддерживаются:
  • Surface Hub
  • Системы залы Microsoft Teams на платформе Windows (MTR)
• внешние пользователи, которые соответствуют требованиям к регистрации устройств защиты токенов в их домашней организации, поддерживаются. Однако пользователи, которые не соответствуют этим требованиям, видят неясное сообщение об ошибке без указания первопричины.
• Устройства, зарегистрированные в идентификаторе Microsoft Entra с помощью следующих методов, не поддерживаются:
  • Microsoft Entra был подключен к хостам сеансов виртуального рабочего стола Azure.
  • Устройства Windows, развернутые с использованием массовой регистрации .
  • Облачные ПК, развернутые с помощью Windows 365, присоединены к Microsoft Entra.
  • Группы размещенных машин Power Automate, присоединенные к Microsoft Entra.
  • Устройства Windows Autopilot, развернутые в режиме самораспространения.
  • Виртуальные машины Windows, развернутые в Azure с помощью расширения виртуальной машины, включенного для аутентификации через Microsoft Entra ID.
• Новые устройства Microsoft Entra на версиях Windows до 24H2 могут быть заблокированы, если пользователи не выполнят новый вход при регистрации. При блокировке пользователи должны повторно зарегистрировать устройство.

Чтобы определить затронутые устройства из-за неподдерживаемых типов регистрации, перечисленных ранее, проверьте атрибут tokenProtectionStatusDetails в журналах входа. Запросы токенов, заблокированные из-за неподдерживаемого типа регистрации устройства, можно определить по значению signInSessionStatusCode 1003.

Чтобы предотвратить любые сбои в новом процессе интеграции, вы можете изменить условную политику доступа для защиты токенов, добавив условие фильтрации устройств, исключающее любые устройства, попадающие в ранее описанную категорию развёртывания. Например, чтобы исключить:

• Облачные компьютеры, которые присоединены к Microsoft Entra, можно использовать, используя systemLabels -eq "CloudPC" and trustType -eq "AzureAD".
• Виртуальные рабочие столы Azure, подключенные к Microsoft Entra, вы можете использовать systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD".
• Группы размещенных машин Power Automate, которые присоединены к Microsoft Entra, можно использовать с помощью systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD".
• Виртуальные машины Windows в Azure, подключенные к Microsoft Entra, можно использовать systemLabels -eq "AzureResource" and trustType -eq "AzureAD".

Развертывание

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

Чтобы свести к минимуму вероятность нарушения работы пользователей из-за несовместимости приложений или устройств, настоятельно рекомендуется:

• Начните с пилотной группы пользователей и развернитесь со временем.
• Создайте политику условного доступа в режиме только для отчетов перед переходом к принудительному применению защиты маркеров.
• Записывайте журналы интерактивного и неинтерактивного входа.
• Проанализируйте эти журналы достаточно долго, чтобы охватить нормальное использование приложения.
• Добавьте надежных пользователей в политику контроля.

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

Создание политики условного доступа

Пользователи, выполняющие специализированные роли, такие как описанные в разделе "Уровни безопасности привилегированного доступа", являются возможными целевыми объектами для этой функции. Мы рекомендуем начать пилотный проект с небольшим подмножеством.

Описанные действия помогут создать политику условного доступа, чтобы запрашивать защиту токенов для Exchange Online и SharePoint Online на устройствах Windows.

1. Войдите в Центр администрирования Microsoft Entra как минимум в качестве администратора условного доступа.
2. Перейдите к защите>условного доступа>политикам.
3. Выберите Новая политика.
4. Присвойте политике имя. Мы рекомендуем организациям присваивать политикам понятные имена.
5. В разделе Назначения выберите Идентификаторы пользователей или рабочих нагрузок.
   1. В разделе "Включить" выберите пользователей или группы, которые тестируют эту политику.
   2. В разделе Исключить выберите Пользователи и группы, а затем выберите учетные записи для аварийного доступа или для обхода стандартной системы контроля доступа в вашей организации.
6. В разделе Целевые ресурсы>Ресурсы (ранее облачные приложения)>Включить>Выберите ресурсы

   1. В разделе "Выбор" выберите следующие приложения, поддерживаемые предварительной версией:

      1. Office 365 Exchange Online
      2. Office 365 SharePoint Online

      Предупреждение

      Политика условного доступа должна быть настроена только для этих приложений. Выбор группы приложений Office 365 может привести к непредвиденным сбоям. Это изменение является исключением из общего правила, что в политике условного доступа должна быть выбрана группа приложений Office 365.

   2. Выберите Select.

7. В разделе Условия:
   1. В разделе Платформы устройств:
      1. Задайте для параметра Настроить значение Да.
      2. Включить>Выберите платформы устройств>Windows.
      3. Нажмите кнопку Готово.
   2. В клиентских приложениях:

      1. Задайте для параметра Настроить значение Да.

         Предупреждение

         Не настраивая условие клиентских приложений или оставляя выбрано браузер, это может привести к блокировке приложений, использующих MSAL.js, например, Teams Web.

      2. В разделе "Современные клиенты проверки подлинности" выберите только мобильные приложения и настольные клиенты. Оставьте остальные элементы без флажка.

      3. Нажмите кнопку Готово.

8. В разделе управления доступомСеанс выберите "Требовать защиту токенов для сеансов входа" и нажмите "Выбрать".
9. Подтвердите параметры и задайте для параметра Включить политику значение Только отчет.
10. Нажмите Создать, чтобы создать и включить политику.

После того как администраторы оценивают параметры политики с помощью режима оценки влияния политики или режима только отчетов, они могут переместить переключатель Включить политику из Только отчеты в Включено.

Сбор лог-файлов и анализ

Отслеживайте принудительное применение защиты токенов до и после применения с помощью таких функций, как влияние политики (предварительная версия), журналы входаили Log Analytics.

Журналы входа

Используйте журнал входа Microsoft Entra, чтобы проверить результат политики принудительного применения защиты токенов только в режиме отчетности или в активированном режиме.

1. Войдите в Центр администрирования Microsoft Entra как минимум в качестве администратора условного доступа.
2. Перейдите к Удостоверения>Мониторинг и работоспособность>Журналы входов.
3. Выберите конкретный запрос, чтобы определить, применяется ли политика.
4. Перейдите в область Условного доступа или Только для отчетов в зависимости от его состояния и выберите имя политики, требующей защиты токенов.
5. В разделе "Элементы управления сеансами" проверьте, выполнены ли требования политики.
6. Чтобы узнать больше о состоянии привязки запроса, выберите область базовые сведения и просмотрите поле защита токена — сессия входа. Возможные значения:
   1. Привязан: запрос использовал связанные протоколы. Некоторые входы могут включать несколько запросов, и все запросы должны соответствовать требованиям политики защиты токенов. Даже если отдельный запрос, как представляется, привязан, он не гарантирует соответствие политике, если другие запросы не связаны. Чтобы просмотреть все запросы для входа, можно отфильтровать все запросы для конкретного пользователя или просмотреть по corelationid.
   2. Несвязанный запрос: запрос не использовал связанные протоколы. Возможные statusCodes при отсутствии привязки запроса:
      1. 1002. Запрос не выполнен из-за отсутствия состояния устройства Microsoft Entra ID.
      2. 1003: Запрос не имеет привязки, так как состояние устройства Microsoft Entra ID не соответствует требованиям политики условного доступа для защиты токенов. Эта ошибка может возникнуть из-за неподдерживаемого типа регистрации устройства, или устройство не зарегистрировано с помощью новых учетных данных входа.
      3. 1005: запрос не ограничен по другим неуказанным причинам.
      4. 1006: запрос не связан, так как версия ОС не поддерживается.
      5. 1008: Запрос не привязан, так как клиент не интегрирован с платформенным брокером, например, Диспетчером учетных записей Windows (WAM).

Log Analytics

Вы также можете использовать Log Analytics для запроса журналов входа (интерактивных и неинтерактивных) для заблокированных запросов из-за сбоя применения защиты маркеров.

Ниже приведен пример запроса Log Analytics, выполняющего поиск журналов неинтерактивного входа за последние семь дней, выделение заблокированных и разрешенных запросов приложением. Эти запросы являются только примерами и подлежат изменению.

//Per Apps query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, Status,UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrinicpalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]' 
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"] 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id,UserPrincipalName, AppDisplayName, Result 
| summarize Requests = count(), Users = dcount(UserPrincipalName), Block = countif(Result == "Block"), Allow = countif(Result == "Allow"), BlockedUsers = dcountif(UserPrincipalName, Result == "Block") by AppDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by Requests desc 

Результат предыдущего запроса должен быть похож на следующий снимок экрана:

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

//Per users query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies.sessionControlsNotSatisfied 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName,Result  
| summarize Requests = count(),Block = countif(Result == "Block"), Allow = countif(Result == "Allow") by UserPrincipalName, AppDisplayName,ResourceDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by UserPrincipalName asc   

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

AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| where TokenProtectionStatusDetails!= "" 
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails) 
| extend bindingStatus = tostring(parsedBindingDetails["signInSessionStatus"]) 
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"]) 
| where bindingStatusCode == 1003 
| summarize count() by UserPrincipalName 

Связанный контент

Что такое основной маркер обновления?