Настройте проверку подлинности без сертификата с помощью Microsoft. Identity.Web

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

Microsoft. Identity.Web поддерживает проверку подлинности без сертификатов с помощью типа источника учетных данных SignedAssertionFromManagedIdentity, доступной в версии 2.12.0 и более поздних версий.

Общие сведения о проверке подлинности без сертификатов

В этом разделе объясняется, как работает проверка подлинности без сертификата и когда она используется.

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

Федеративные учетные данные удостоверения (FIC) изменяют эту модель. С помощью FIC вы настраиваете отношения доверия между регистрацией приложения и Управляемым удостоверением. Когда приложению требуется пройти проверку подлинности:

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

Результатом является полное развертывание без учетных данных, в котором в конфигурации, коде или переменных среды отсутствуют секреты или сертификаты.

Выбор правильного подхода к проверке подлинности

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

Сценарий	Рекомендуемый подход
Приложение выполняется в Azure и требуется нулевое управление учетными данными	Без сертификата с FIC
Приложение выполняется на Azure, но необходимо поддерживать локальный резервный вариант	Учетные данные на основе сертификатов с FIC в качестве основного
Приложение выполняется вне Azure (локальные, другие облака)	Сертификаты или секреты клиента
Разработка и тестирование на локальных компьютерах	Секреты клиента или сертификат из локального хранилища

Необходимые условия

Перед началом работы убедитесь, что у вас есть следующие ресурсы и средства:

Подписка Azure. Если ее нет, создайте бесплатную учетную запись.
Регистрация приложения в Microsoft Entra ID с необходимыми разрешениями API для вашего сценария.
Идентификатор Managed Identity в Azure — назначаемый системой вычислительный ресурс или автономное управляемое удостоверение.
Microsoft. Identity.Web версии 2.12.0 или более поздней версии, установленной в проекте.
Вычислительный ресурс Azure, который поддерживает Управляемый идентификатор, например Служба приложений Azure, Azure Kubernetes Service (AKS), Контейнеры приложений Azure или Виртуальные машины Azure.

Шаг 1. Создание или идентификация управляемого удостоверения

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

Вариант A: Использование системно назначенного управляемого удостоверения

Назначаемые системой управляемые удостоверения привязаны к жизненному циклу ресурса Azure. При включении системно назначаемого удостоверения на таком ресурсе, как служба приложений, Azure автоматически создает это удостоверение.

На портале Azure перейдите к вычислительному ресурсу (например, службе приложений).
Выберите Идентификация в левой части навигационного меню.
На вкладке Назначено системой установите Состояние как Вкл..
Нажмите кнопку "Сохранить " и подтвердите действие.
После создания удостоверения скопируйте идентификатор объекта (субъекта). Это значение необходимо при настройке федеративных учетных данных.

Вариант B: Создание назначенного пользователем управляемого удостоверения

Управляемые идентификаторы пользователя являются независимыми ресурсами Azure, которые можно назначить одному или нескольким вычислительным ресурсам.

На портале Azure найдите Managed Identities и выберите его.
Нажмите кнопку "Создать".
Выберите подписку, группу ресурсов, регион и введите имя.
Нажмите кнопку "Рецензирование и создание", а затем "Создать".
После завершения развертывания откройте новый ресурс управляемой идентификации.
Скопируйте идентификатор клиента на странице обзора . Это значение требуется для конфигурации приложения.

Шаг 2. Настройка учетных данных федеративного удостоверения на портале Azure

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

На портале Azure перейдите к Microsoft Entra ID>Регистрация приложений.
Выберите регистрацию приложения, которую использует ваше приложение.
В меню навигации слева выберите сертификаты и секреты.
Выберите вкладку Федеративные учетные данные .
Выберите Добавить учетные данные.
В разделе "Федеративные учетные данные" выберите управляемые клиентом ключи или другой издатель (доступные параметры зависят от версии портала).

Задайте значения в следующих полях:

Поле	Ценность
Эмитент	`https://login.microsoftonline.com/{tenant-id}/v2.0` — замените `{tenant-id}` идентификатором клиента Microsoft Entra.
Идентификатор субъекта	Идентификатор объекта (субъекта) управляемого удостоверения. Для назначенного системой найдите это на странице идентификации ресурса. Чтобы назначить пользователя, найдите это на странице обзора управляемого удостоверения в разделе "Идентификатор субъекта".
Имя	Описательное имя, например `fic-managed-identity-prod`.
Публика	`api://AzureADTokenExchange` (значение по умолчанию).

Нажмите кнопку "Добавить".

Это важно

Идентификатор субъекта должен точно соответствовать идентификатору объекта (принципала) этого управляемого удостоверения. Несоответствие приводит к сбою проверки подлинности с ошибкой AADSTS70021 .

Настройка учетных данных федеративного удостоверения с помощью Azure CLI

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

az ad app federated-credential create \
    --id <app-object-id> \
    --parameters '{
        "name": "fic-managed-identity-prod",
        "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0",
        "subject": "<managed-identity-principal-id>",
        "audiences": ["api://AzureADTokenExchange"],
        "description": "FIC for production managed identity"
    }'

URL-адреса издателя по службе Azure

URL-адрес издателя в федеративных учетных данных зависит от службы Azure, в которой размещено приложение:

служба Azure	URL-адрес издателя
Служба приложений Azure / Функции Azure	`https://login.microsoftonline.com/{tenant-id}/v2.0`
Контейнеры приложений Azure	`https://login.microsoftonline.com/{tenant-id}/v2.0`
Azure Kubernetes Service (AKS)	URL-адрес издателя OIDC для кластера (извлекается с `az aks show --query oidcIssuerProfile.issuerUrl`)
Виртуальные машины Azure	`https://login.microsoftonline.com/{tenant-id}/v2.0`

Формат идентификатора субъекта

Формат идентификатора субъекта зависит от типа управляемой идентичности.

Назначаемое системой управляемое удостоверение — используйте идентификатор объекта (принципала) на странице идентификации ресурса. Это значение GUID, например a1b2c3d4-e5f6-7890-abcd-ef1234567890.

Управляемое удостоверение, назначаемое пользователем — используйте идентификатор субъекта (также называемый идентификатором объекта) на странице Обзор управляемого удостоверения ресурса. Это также значение GUID.

Замечание

Для AKS с идентификацией рабочей нагрузки используется другой формат идентификатора субъекта: system:serviceaccount:{namespace}:{service-account-name}. Это значение должно соответствовать учетной записи службы Kubernetes, которую использует модуль pod.

Шаг 3. Настройка приложения

Обновление appsettings.json

Добавьте ClientCredentials раздел в AzureAd конфигурацию. Задайте SourceType на SignedAssertionFromManagedIdentity:

Для управляемой идентичности, назначаемой пользователем

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Замените следующие заполнители:

Placeholder	Описание
`YOUR_TENANT_ID`	Идентификатор клиента Microsoft Entra.
`YOUR_CLIENT_ID`	Идентификатор (client) приложения при регистрации вашего приложения.
`USER_ASSIGNED_MSI_CLIENT_ID`	Идентификатор клиента назначаемого пользователем управляемого удостоверения (на странице Обзор удостоверения).

Для управляемого удостоверения, назначаемого системой

При использовании системой назначаемого управляемого удостоверения, пропустите ManagedIdentityClientId свойство. Microsoft.Identity.Web автоматически использует системно назначенную идентичность узла:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity"
      }
    ]
  }
}

Регистрация служб в Program.cs

В конфигурации запуска не требуются специальные изменения кода. Стандартные методы регистрации Microsoft.Identity.Web автоматически считывают раздел ClientCredentials.

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

// For a web app that signs in users and calls downstream APIs
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

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

// For a web API that calls downstream APIs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

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

// For a daemon application (no user interaction)
builder.Services.AddAuthentication()
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddTokenAcquisition()
    .AddInMemoryTokenCaches();

Microsoft. Identity.Web обнаруживает тип источника SignedAssertionFromManagedIdentity и прозрачно обрабатывает обмен маркерами.

Сравнение назначаемого системой и назначаемого пользователем управляемого удостоверения

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

Назначаемое системой управляемое удостоверение

Удостоверение, назначаемое системой, создается и удаляется автоматически вместе с ресурсом Azure, к которому оно принадлежит.

Преимущества.

Отдельного ресурса для управления не требуется — жизненный цикл идентификации соответствует вычислительному ресурсу.
Упрощенная настройка для развертываний с одним ресурсом.
В конфигурации не требуется ManagedIdentityClientId.

Соображения.

Нельзя использовать идентификатор в нескольких ресурсах.
При удалении и повторном создании ресурса удостоверение изменяется, поэтому необходимо обновить учетные данные федеративного удостоверения.

Оптимально для: Развертываний с одним экземпляром, в которых один вычислительный ресурс сопоставляется с одной регистрацией приложения.

Управляемое удостоверение, назначаемое пользователем

Назначенное пользователем удостоверение — это самостоятельный Azure-ресурс с собственным жизненным циклом.

Преимущества.

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

Соображения.

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

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

Развертывание в службах вычислений Azure

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

Служба приложений Azure

Включите управляемую идентичность в службе приложений (см. Шаг 1).
Разверните приложение в службе приложений с помощью предпочтительного метода (Visual Studio, Azure CLI, GitHub Actions).
Убедитесь, что AzureAd раздел в развернутой конфигурации соответствует параметрам шага 3.
Если вы используете назначаемое пользователем управляемое удостоверение, назначьте его службе приложений.
```
az webapp identity assign \
  --resource-group <resource-group> \
  --name <app-service-name> \
  --identities <managed-identity-resource-id>
```
Перезапустите службу приложений, чтобы задействовать назначение идентификатора.

Служба Azure Kubernetes (AKS)

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

Включите функцию идентификации рабочей нагрузки в вашем кластере AKS:

az aks update \
  --resource-group <resource-group> \
  --name <aks-cluster-name> \
  --enable-oidc-issuer \
  --enable-workload-identity

Создайте учетную запись службы Kubernetes с идентификатором клиента управляемого удостоверения:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: default
  annotations:
    azure.workload.identity/client-id: "<USER_ASSIGNED_MSI_CLIENT_ID>"

Создайте федеративные учетные данные, связывающие издателя AKS OIDC с управляемым удостоверением.

Настройте модуль pod для использования учетной записи службы:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: default
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: my-app-sa
  containers:
    - name: my-app
      image: <your-container-image>

Разверните контейнер. Веб-перехватчик удостоверения нагрузки вставляет необходимые переменные среды для конечной точки токена управляемого удостоверения.

Контейнеры приложений Azure

Создайте или обновите контейнерное приложение, используя управляемую идентичность.
```
az containerapp identity assign \
  --resource-group <resource-group> \
  --name <container-app-name> \
  --user-assigned <managed-identity-resource-id>
```
Разверните образ контейнера с нужной AzureAd конфигурацией.
Конечная точка токена управляемого удостоверения автоматически доступна в контейнере.

Миграция с сертификатов на проверку подлинности без сертификатов

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

Выполните действия по миграции

Create a Managed Identity для вычислительного ресурса Azure (см. Step 1).
Добавьте учетные данные федеративного удостоверения в регистрацию приложения (см. шаг 2).
Обновите конфигурацию , чтобы добавить учетные SignedAssertionFromManagedIdentity данные. Вы можете сохранить существующие учетные данные сертификата в качестве резервного варианта во время миграции:
```
{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      },
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
        "KeyVaultCertificateName": "your-cert-name"
      }
    ]
  }
}
```
Microsoft.Identity.Web поочередно пытается использовать источники аутентификации. При выполнении в Azure первые учетные данные (SignedAssertionFromManagedIdentity) успешно выполняются. Если он дает сбой (например, во время локальной разработки), библиотека использует сертификат в качестве резервного варианта.
Разверните и проверьте в промежуточной среде, прежде чем применять к рабочей среде.
Удалите учетные данные сертификата из конфигурации после подтверждения работы проверки подлинности без сертификатов в рабочей среде.
Удалите сертификат из Azure Key Vault и регистрацию приложения, когда сертификат больше не нужен.

Сравнение до и после настройки

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

До (на основе сертификатов):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
        "KeyVaultCertificateName": "your-cert-name"
      }
    ]
  }
}

После (без сертификата):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Устранение распространенных ошибок

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

AADSTS70021: не найдена соответствующая запись федеративной идентичности

Причина: Идентификатор субъекта в удостоверении федеративной идентичности не соответствует идентификатору объекта (субъекта) управляемой идентичности.

Резолюция:

На портале Azure перейдите к ресурсу управляемого удостоверения и скопируйте идентификатор Principal ID (также называемый идентификатором объекта) на странице Overview.
Перейдите к сертификатам регистрации > приложения и секретам>федеративных учетных данных.
Проверьте, чтобы поле идентификатора субъекта точно соответствовало идентификатору объекта.
Если значения не совпадают, удалите учетные данные и повторно создайте его с правильным идентификатором субъекта.

AADSTS700024: Утверждение клиента не соответствует допустимым временным пределам

Причина: Маркер управляемого удостоверения, используемый в качестве подписанного утверждения, истек или системные часы сбиты.

Резолюция:

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

ManagedIdentityException: конечная точка управляемого удостоверения недоступна

Причина: приложение не может получить доступ к службе метаданных экземпляров Azure, IMDS, или к конечной точке API токенов управляемой идентификации.

Резолюция:

Убедитесь, что приложение запущено на вычислительном ресурсе Azure, поддерживающем управляемое удостоверение.
Убедитесь, что управляемое удостоверение включено и назначено вычислительному ресурсу.
Для AKS убедитесь, что веб-перехватчик удостоверений рабочей нагрузки запущен, а модуль pod имеет правильную заметку учетной записи службы.
Для локальной разработки ожидается эта ошибка. Используйте резервный источник учетных данных (см. инструкции по миграции).

AADSTS700016: приложение не найдено в каталоге

Причина:ClientId в вашей конфигурации не соответствует допустимой регистрации приложения в указанном клиенте.

Резолюция:

Проверьте, что ClientId соответствует идентификатору регистрации вашего приложения (клиента).
Проверьте, что TenantId соответствует арендатору, где зарегистрировано приложение.

Включение ведения журнала отладки

Причина: Несоответствие порядка или конфигурации источника учетных данных может стать причиной того, что библиотека пропустит учетные данные FIC.

Резолюция:

Включите ведение журнала в Microsoft.Identity.Web, чтобы увидеть подробные шаги по получению токенов. Следующий код настраивает логгирование на уровне отладки для библиотек идентификации.
```
builder.Services.AddLogging(logging =>
{
    logging.AddConsole();
    logging.SetMinimumLevel(LogLevel.Debug);
    logging.AddFilter("Microsoft.Identity", LogLevel.Debug);
});
```
Просмотрите журналы, чтобы узнать, какой источник учетных данных пыталась использовать библиотека, а также о всех возвращенных ошибках.

Управляемое удостоверение, назначаемое пользователем, не было выбрано

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

Резолюция:

Всегда указывайте свойство ManagedIdentityClientId, когда используете управляемое удостоверение, назначенное пользователем.
Убедитесь, что идентификатор клиента соответствует идентификатору, для который вы настроили учетные данные федеративного удостоверения.

Просмотреть преимущества безопасности

Проверка подлинности без сертификата с помощью FIC обеспечивает значительные преимущества безопасности по сравнению с традиционными подходами на основе учетных данных:

Некуда утекать секретам

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

Смена учетных данных отсутствует

Токены управляемых удостоверений являются краткосрочными и автоматически обновляются платформой Azure. Вам не нужно реализовывать расписания смены, отслеживать даты окончания срока действия или координировать обновления учетных данных во всех развертываниях.

Сокращение направлений атак

Конечная точка токена управляемой идентичности доступна только из конкретного ресурса Azure, к которому назначена эта идентичность. Злоумышленник не может использовать учетные данные из другой среды узла, сети или облака.

Упрощение соответствия требованиям

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

В системе управления версиями, переменных среды или файлах конфигурации не должно быть хранится никаких секретов.
Никакого ключевого материала для аудита, ротации или отзыва.
Не требуется поддерживать инфраструктуру сертификатов (ЦС, процессы продления).

Глубинная защита

Объедините проверку подлинности без сертификатов с другими функциями безопасности Azure для многоуровневой защиты:

Azure RBAC. Управление удостоверениями, к которым могут получить доступ к ресурсам.
Условный доступ. Применение политик на основе риска идентификации, расположения и состояния устройства.
Частные конечные точки: ограничивают сетевой доступ к ресурсам Azure.
Microsoft Defender для облака: мониторинг подозрительных шаблонов проверки подлинности.

Общие сведения об учетных данных
Certificates
Секреты клиента
документация по управляемым удостоверениям Azure
Документация по федеративным учетным данным
Репозиторий GitHub Microsoft.Identity.Web

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-04-19

Настройте проверку подлинности без сертификата с помощью Microsoft. Identity.Web

Общие сведения о проверке подлинности без сертификатов

Выбор правильного подхода к проверке подлинности

Необходимые условия

Шаг 1. Создание или идентификация управляемого удостоверения

Вариант A: Использование системно назначенного управляемого удостоверения

Вариант B: Создание назначенного пользователем управляемого удостоверения

Шаг 2. Настройка учетных данных федеративного удостоверения на портале Azure

Настройка учетных данных федеративного удостоверения с помощью Azure CLI

URL-адреса издателя по службе Azure

Формат идентификатора субъекта

Шаг 3. Настройка приложения

Обновление appsettings.json

Для управляемой идентичности, назначаемой пользователем

Для управляемого удостоверения, назначаемого системой

Регистрация служб в Program.cs

Сравнение назначаемого системой и назначаемого пользователем управляемого удостоверения

Назначаемое системой управляемое удостоверение

Управляемое удостоверение, назначаемое пользователем

Развертывание в службах вычислений Azure

Служба приложений Azure

Служба Azure Kubernetes (AKS)

Контейнеры приложений Azure

Миграция с сертификатов на проверку подлинности без сертификатов

Выполните действия по миграции

Сравнение до и после настройки

Устранение распространенных ошибок

AADSTS70021: не найдена соответствующая запись федеративной идентичности

AADSTS700024: Утверждение клиента не соответствует допустимым временным пределам

ManagedIdentityException: конечная точка управляемого удостоверения недоступна

AADSTS700016: приложение не найдено в каталоге

Включение ведения журнала отладки

Управляемое удостоверение, назначаемое пользователем, не было выбрано

Просмотреть преимущества безопасности

Некуда утекать секретам

Смена учетных данных отсутствует

Сокращение направлений атак

Упрощение соответствия требованиям

Глубинная защита

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

Обратная связь

Дополнительные ресурсы