Защита маркеров обновления потока On-Behalf-Of OAuth 2.0 для веб-служб

При разработке веб-служб может потребоваться получить маркеры с помощью потока OAuth 2.0 On-Behalf-Of (OBO). Поток OBO используется в том случае, когда приложение вызывает API службы или веб-API, который, в свою очередь, должен вызывать другой API службы или веб-API. OBO распространяет делегированное удостоверение пользователя и разрешения с помощью цепочки запросов. Если приложению требуется использовать маркеры доступа и обновления в течение неограниченного срока, как правило, это происходит в сценариях с автономным доступом, крайне важно обеспечить безопасное хранение маркеров обновления.

Потенциальные варианты использования

Это решение использует Azure Key Vault, Функции Azure и Azure DevOps для безопасного обновления и хранения маркеров обновления OBO.

Архитектура

Скачайте файл Visio для этой архитектуры.

Поток данных

• Azure Key Vault содержит ключи шифрования секретов для каждого клиента Идентификатора Microsoft Entra.
• Функция, активируемая с помощью таймера Функций Azure, получает последний секретный ключ из Key Vault. Другая функция Функций Azure извлекает маркер обновления из платформы удостоверений Майкрософт и сохраняет его с последней версией секретного ключа.
• База данных хранит последний зашифрованный ключ и непрозрачные данные.
• Конвейер непрерывной поставки Azure DevOps контролирует и синхронизирует процессы смены секретов и обновления маркеров.

Azure Pipelines — это удобное место для добавления стратегии смены ключей, если вы уже используете конвейеры для модели "инфраструктура как код" (IaC) или непрерывную интеграцию и поставку (CI/CD). Не нужно использовать Azure Pipelines, если вы ограничиваете пути для настройки и извлечения секретов.

Примените следующую политику, чтобы разрешить субъекту-службе для подключения к службе Azure DevOps задавать секреты в Key Vault. Замените переменные <Key Vault Name> и <Service Connection Principal> на значения для вашей среды.

az keyvault set-policy --name $<Key Vault Name> --spn $<Service Connection Principal> --secret-permissions set

После настройки Azure Pipelines для создания и обновления ключей можно запланировать периодическое выполнение конвейера. Конвейер обновляет секрет Key Vault для синхронизации со сменой ключей и сохраняет зашифрованный маркер в новой версии секрета. Дополнительные сведения см. в разделе Настройка расписаний для конвейеров.

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

Предпочтительный способ доступа к Key Vault для службы Azure, например для Функций Azure, — использование управляемого удостоверения службы. Вы можете предоставить доступ через портал Azure, Azure CLI или с помощью шаблона Azure Resource Manager (шаблона ARM) для сценариев IaC.

Портал Azure

На портале Azure добавьте политику доступа Key Vault, чтобы разрешить идентификатору объекта управляемого удостоверения в Функциях Azure получать и задавать секреты. Дополнительные сведения см. в статьях Добавление назначенного системой удостоверения и Использование ссылок Key Vault для Службы приложений и Функций Azure.

Azure CLI

Политику Azure Key Vault можно также задать с помощью Azure CLI:

az keyvault set-policy --name $<Key Vault Name> --spn $<Service Connection Principal> --secret-permissions set
az keyvault set-policy --name $<Key Vault Name> --spn $<Managed Identity Principal> --secret-permissions get

Шаблон ARM

Следующий шаблон ARM предоставляет Функциям Azure доступ к Azure Key Vault. Замените переменные *** на значения для вашей среды.

{
  "type": "Microsoft.KeyVault/vaults",
  "apiVersion": "2019-09-01",
  "name": "***",
  "location": "***",
  "properties": {
    "sku": {
      "family": "A",
      "name": "standard"
    },
    "tenantId": "***",
    "enableSoftDelete": true,
    "enabledForDeployment": false,
    "enabledForTemplateDeployment": false,
    "enabledForDiskEncryption": false,
    "accessPolicies": [
      {
        "tenantId": "***",
        "objectId": "<Managed Identity Principal>",
        "permissions": {
          "secrets": [
            "get"
          ]
        }
      },
      {
        "tenantId": "***",
        "objectId": "<Service Connection Principal>",
        "permissions": {
          "secrets": [
            "set"
          ]
        }
      }
    ]
  }
}

Хранилище маркеров

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

Последовательность содержит две функции: userId() и secretId(). Эти функции можно определить как сочетание token.oid, token.tid и token.sub. Дополнительные сведения см. в разделе Использование id_token.

С помощью криптографического ключа, хранящегося в качестве секрета, можно найти последнюю версию ключа в Azure Key Vault.

Использование маркеров

Использовать ключ очень просто. Следующая последовательность запрашивает ключ на основе последней версии ключа.

Обновление маркера происходит независимо от функции DoWork, поэтому Функции Azure могут выполнять DoWork и асинхронное обновление маркера с помощью Устойчивых функций. Дополнительные сведения о функциях, активируемых HTTP, с Устойчивыми функциями см. в разделе Функции HTTP.

Не рекомендуется использовать Azure Key Vault в конвейере HTTP-запросов, поэтому по возможности кэшируйте ответы. В этом примере ответ Key Vault на вызов getSecret(secretId, secretVersion) можно кэшировать.

Смена ключей и обновление маркера

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

На следующей схеме последовательности показан процесс синхронизации обновления маркера со сменой ключа:

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

платформа удостоверений Майкрософт предоставляет возможность отзыва маркеров обновления в случае компрометации. См. разделы Отзыв маркера и Revoke-AzureADUserAllRefreshToken.

Чтобы удалить пользователя из идентификатора Microsoft Entra, просто удалите запись пользователя. Чтобы удалить доступ к приложению для пользователя, удалите часть refreshToken в данных пользователя.

Чтобы удалить доступ для группы пользователей, например всех пользователей в целевом клиенте, можно использовать Azure Pipelines для удаления секрета группы на основе secretId().

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

• Джейсон Мостелла | Старший инженер по программному обеспечению

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

• поток платформа удостоверений Майкрософт и OAuth 2.0 on-Behalf-Of
• Использование управляемых удостоверений в Службе приложений и Функциях Azure
• Использование ссылок на Key Vault в Службе приложений и Функциях Azure
• Защита Функции Azure