Поделиться через

Общие сведения об API методов проверки подлинности приложений Microsoft Entra

  • Статья

Пространство имен: microsoft.graph

Важно!

API версии /beta в Microsoft Graph могут быть изменены. Использование этих API в производственных приложениях не поддерживается. Чтобы определить, доступен ли API в версии 1.0, используйте селектор версий.

Методы проверки подлинности приложений, такие как сертификаты и секреты паролей, позволяют приложениям получать маркеры для доступа к данным в Microsoft Entra ID. Политики позволяют ИТ-администраторам применять рекомендации по использованию этих методов проверки подлинности приложений в своих организациях. Например, администратор может настроить политику, чтобы запретить использование или ограничить время существования секретов паролей, а также использовать дату создания объекта для принудительного применения политики.

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

Существует два типа элементов управления политикой:

  • Политика клиента по умолчанию, которая применяется ко всем приложениям или субъектам-службам.
  • Политики управления приложениями (приложением или субъектом-службой), которые разрешают включение или исключение отдельных приложений из политики клиента по умолчанию.

Политика управления приложениями клиента по умолчанию

Политика клиента по умолчанию — это один объект, который всегда существует и отключен по умолчанию. Он определяется ресурсом tenantAppManagementPolicy и применяет ограничения на объекты приложения и субъекта-службы. Он содержит следующие два свойства:

  • applicationRestrictions позволяет ориентироваться на приложения, принадлежащие клиенту (объекты приложения).
  • servicePrincipalRestrictions позволяет ориентироваться на подготовленные из другого клиента (объекты субъекта-службы.

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

Политика управления приложениями для приложений и субъектов-служб

Политики управления приложениями определяются в ресурсе appManagementPolicy , который содержит коллекцию политик с различными ограничениями или разными датами применения, определенными в политике клиента по умолчанию. Одну из этих политик можно назначить приложению или субъекту-службе, исключив их из политики клиента по умолчанию.

Если существуют политика клиента по умолчанию и политика управления приложениями, приоритет имеет политика управления приложениями, а назначенное приложение или субъект-служба не наследует от политики клиента по умолчанию. Приложению или субъекту-службе можно назначить только одну политику.

Примечание.

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

Какими ограничениями можно управлять в Microsoft Graph?

API политики методов проверки подлинности приложений предлагает следующие ограничения:

Имя ограничения Описание Примеры
passwordAddition Полностью ограничьте секреты паролей в приложениях. Блокировать новые пароли в приложениях, созданных 01.01.2019 или позже.
passwordLifetime Принудительное применение максимального диапазона времени существования для секрета пароля. Ограничьте все новые секреты паролей до 30 дней для приложений, созданных после 01.01.2015 г.
customPasswordAddition Ограничьте настраиваемый секрет пароля для приложения или субъекта-службы. Ограничьте все новые пользовательские (не Azure AD созданные) секреты паролей в приложениях, созданных после 01.01.2015 г.
symmetricKeyAddition Ограничение симметричных ключей в приложениях. Блокировать новые симметричные ключи в приложениях, созданных 01.01.2019 года или позже.
symmetricKeyLifetime Принудительное применение максимального диапазона времени существования для симметричного ключа. Ограничьте все новые симметричные ключи до 30 дней для приложений, созданных после 01.01.2019 г.
asymmetricKeyLifetime Принудительное применение максимального диапазона времени существования для асимметричного ключа (сертификата). Ограничьте все новые учетные данные асимметричного ключа максимум 30 днями для приложений, созданных после 01.01.2019 г.
trustedCertificateAuthority Принудительное применение списка доверенных центров сертификации. Блокировать все новые учетные данные асимметричного ключа, если издатель не указан в списке доверенных центров сертификации.

Примечание.

Все ограничения времени существования выражаются в формате длительности ISO-8601 (например, P4DT12H30M5S).

Применение ограничения customPasswordAddition заблокирует все устаревшие модули PowerShell, которые добавляют созданный клиентом секрет пароля в приложения или субъекты-службы. Это ограничение не блокирует секреты паролей, созданные Microsoft Entra ID приложения или субъекта-службы.

Приложения с одним или несколькими клиентами

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

  • Для приложений с одним клиентом примените политику к объекту приложения.
  • Чтобы ограничить мультитенантные приложения, которые используются в клиенте клиента, примените политику к объекту приложения.
  • Чтобы ограничить мультитенантные приложения, подготовленные из другого клиента, примените политику к объекту субъекта-службы.

Сводка основных различий между политикой клиента по умолчанию и политиками управления приложениями

Политика клиента по умолчанию Политика управления приложениями
Политика всегда существует. Объекты политики можно создавать или обновлять для переопределения политики по умолчанию.
Ограничения отключены по умолчанию для приложения или sp. Разрешает настройку для одного клиента или нескольких клиентов (резервное приложение в домашнем клиенте или подготовленные приложения).
Разрешает только одно определение объекта ограничения для всех ресурсов. Позволяет определить несколько объектов политики, но только один можно применить к ресурсу.
Позволяет различать ограничения для объектов приложения и субъектов-служб. Политику можно применить к приложению или объекту субъекта-службы.
Применяет все ограничения, настроенные ко всем приложениям или субъектам-службам. Применяет только ограничения, настроенные в политике ресурсов, к указанному приложению или субъекту-службе и не наследует от политики по умолчанию.

Требования

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