Предоставление доступа к ключам Key Vault, сертификатам и секретам с помощью управления доступом на основе ролей Azure

Azure управление доступом на основе ролей (Azure RBAC) — это система авторизации, основанная на Azure Resource Manager которая обеспечивает централизованное управление доступом Azure ресурсов. Начиная с API версии 2026-02-01, Azure RBAC — это модель управления доступом по умолчанию для вновь созданных хранилищ ключей. Подробности об этом изменении и о том, как подготовиться, см. в разделе Подготовка к версии API Key Vault 2026-02-01 и более поздним версиям.

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

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

Дополнительные сведения см. в разделе Azure управление доступом на основе ролей (Azure RBAC).

Обзор модели доступа Key Vault

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

Плоскость контрольная — это место, где вы управляете самим Key Vault. Операции в этой области включают создание и удаление хранилищ ключей Key Vault, получение свойств хранилища ключей и обновление политик доступа.

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

Оба самолета используют Microsoft Entra ID для проверки подлинности. Для авторизации уровень управления использует Azure RBAC (управление доступом на основе ролей), а уровень данных использует устаревшую политику доступа Key Vault или Azure RBAC для операций уровня данных Key Vault.

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

Приложения получают доступ к плоскостям через конечные точки. Системы управления доступом для двух плоскостей работают независимо. Чтобы предоставить приложению доступ к использованию ключей в Хранилище ключей, вы предоставляете доступ к каналу данных с помощью Azure RBAC или политики доступа Key Vault. Чтобы предоставить пользователю доступ на чтение к свойствам и тегам Key Vault, но не к данным (ключам, секретам или сертификатам), предоставляется доступ к управляющей плоскости с помощью Azure RBAC.

конечные точки плоскости доступа

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

Управление административным доступом к Key Vault

При создании хранилища ключей в группе ресурсов вы управляете доступом с помощью Microsoft Entra ID. Вы предоставляете пользователям или группам возможность управлять хранилищами ключей в группе ресурсов. Вы можете предоставить доступ на определенном уровне области, назначив соответствующие Azure роли. Чтобы предоставить пользователю доступ к управлению хранилищами ключей, необходимо назначить предопределенную роль Key Vault Contributor пользователю в определенной области. Следующие уровни области действия можно назначить роли Azure:

• Subscription: роль Azure, назначенная на уровне подписки, применяется ко всем группам ресурсов и ресурсам в этой подписке.
• Resource group: роль Azure, назначенная на уровне группы ресурсов, применяется ко всем ресурсам в этой группе ресурсов.
• Specific resource: роль Azure, назначенная конкретному ресурсу, применяется к данному ресурсу. В этом случае ресурс представляет собой конкретное хранилище ключей.

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

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

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

Назначение ролей для отдельных ключей, секретов и сертификатов не рекомендуется. Исключения включают сценарии, в которых:

• Для отдельных секретов требуется отдельный доступ пользователей; Например, когда пользователи должны читать закрытый ключ SSH для проверки подлинности на виртуальной машине с помощью Бастион Azure.
• Отдельные секреты должны совместно использоваться несколькими приложениями, например, когда одному приложению необходимо получить доступ к данным из другого приложения.

Дополнительные сведения о рекомендациях по управлению Azure Key Vault см. в следующем разделе:

• Обеспечьте защиту Azure Key Vault
• Ограничения сервиса Azure Key Vault

Предустановленные роли Azure для рабочей плоскости Key Vault

Дополнительные сведения о встроенных определениях ролей Azure см. в разделе Azure встроенные роли.

Управление назначениями встроенных ролей плоскости управления данными Key Vault

Использование прав доступа Azure RBAC для секретов, ключей и сертификатов в Key Vault

Новая модель разрешений Azure RBAC для хранилища ключей предоставляет альтернативу модели разрешений политики доступа к хранилищу.

Предпосылки

У вас должна быть Azure подписка. Если вы этого не сделали, вы можете создать учетную запись free перед началом работы.

Для управления назначениями ролей необходимо иметь разрешения Майкрософт.Authorization/roleAssignments/write и Майкрософт.Authorization/roleAssignments/delete, такие как Key Vault Data Access Administrator (с ограниченными разрешениями только для назначения или удаления определенных ролей Key Vault), User Access Administrator, или Owner.

Включение разрешений Azure RBAC для Key Vault

1. Включите разрешения Azure RBAC в новом хранилище ключей:

   

2. Включите разрешения RBAC Azure в существующем хранилище ключей:

   Включить разрешения Azure RBAC в существующем хранилище

Назначить роль

az role assignment create --role <role-name> --assignee <user-principal-name>> --scope <scope>

#Assign by User Principal Name
New-AzRoleAssignment -RoleDefinitionName "<role-name>" -SignInName <user-principal-name> -Scope "<scope>"

#Assign by Service Principal ApplicationId
New-AzRoleAssignment -RoleDefinitionName "Reader" -ApplicationId <application-id> -Scope "<scope>"

Назначение ролей в области группы ресурсов

az role assignment create --role "Key Vault Reader" --assignee <user-principal-name> --scope /subscriptions/<subscription-id>/resourcegroups/<resource-group>

#Assign by User Principal Name
New-AzRoleAssignment -RoleDefinitionName "Key Vault Reader" -SignInName <user-principal-name> -Scope "/subscriptions/<subscription-id>/resourcegroups/<resource-group>"

#Assign by Service Principal ApplicationId
New-AzRoleAssignment -RoleDefinitionName "Key Vault Reader" -ApplicationId <application-id> -Scope "/subscriptions/<subscription-id>/resourcegroups/<resource-group>"

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

назначение ролей в области Key Vault

az role assignment create --role "Key Vault Secrets Officer" --assignee <user-principal-name> --scope /subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>

#Assign by User Principal Name
New-AzRoleAssignment -RoleDefinitionName "Key Vault Secrets Officer" -SignInName <user-principal-name> -Scope "/subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>"

#Assign by Service Principal ApplicationId
New-AzRoleAssignment -RoleDefinitionName "Key Vault Secrets Officer" -ApplicationId <application-id> -Scope "/subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>"

Назначение ролей в области секретных данных

az role assignment create --role "Key Vault Secrets Officer" --assignee <user-principal-name> --scope /subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>/secrets/RBACSecret

#Assign by User Principal Name
New-AzRoleAssignment -RoleDefinitionName "Key Vault Secrets Officer" -SignInName <user-principal-name> -Scope "/subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>/secrets/RBACSecret"

#Assign by Service Principal ApplicationId
New-AzRoleAssignment -RoleDefinitionName "Key Vault Secrets Officer" -ApplicationId <application-id> -Scope "/subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.KeyVault/vaults/<vault-name>/secrets/RBACSecret"

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

1. Проверьте возможность добавления нового секрета без роли "Key Vault Secrets Officer" на уровне Key Vault.

   1. Перейдите на вкладку Key Vault Управление доступом (IAM) и удалите назначение роли "Офицер по секретам Key Vault" для этого ресурса.

      

   2. Перейдите к ранее созданному секрету. Вы можете увидеть все скрытые свойства.

      

   3. Создание нового секрета (секреты > +Создание и импорт) должно отобразить эту ошибку:

      

2. Проверьте редактирование секрета без роли "Key Vault Secret Officer" на уровне ключей.

   1. Перейдите на ранее созданную вкладку контроль доступа (IAM) и удалите назначение роли "Офицер секретов Key Vault" для этого ресурса.

   2. Перейдите к ранее созданному секрету. Вы можете увидеть скрытые свойства.

      

3. Проверить чтение секретов без роли читателя на уровне хранилища ключей.

   1. Перейдите на вкладку управления доступом группы ресурсов key vault (IAM) и удалите назначение роли "Читатель ключевого хранилища".

   2. Перейдя на вкладку "Секреты" хранилища ключей, должна появиться эта ошибка:

      

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

команда создания определения роли az

az role definition create --role-definition '{ \
    "Name": "Backup Keys Operator", \
    "Description": "Perform key backup/restore operations", \
    "Actions": [], \
    "DataActions": [ \
        "Microsoft.KeyVault/vaults/keys/read ", \
        "Microsoft.KeyVault/vaults/keys/backup/action", \
        "Microsoft.KeyVault/vaults/keys/restore/action" \
    ], \
    "NotDataActions": [], \
    "AssignableScopes": ["/subscriptions/{subscriptionId}"] \
}'

$roleDefinition = @"
{ 
    "Name": "Backup Keys Operator", 
    "Description": "Perform key backup/restore operations", 
    "Actions": [], 
    "DataActions": [ 
        "Microsoft.KeyVault/vaults/keys/read ", 
        "Microsoft.KeyVault/vaults/keys/backup/action", 
        "Microsoft.KeyVault/vaults/keys/restore/action" 
    ], 
    "NotDataActions": [], 
    "AssignableScopes": ["/subscriptions/{subscriptionId}"] 
}
"@

$roleDefinition | Out-File role.json

New-AzRoleDefinition -InputFile role.json

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

Azure настраиваемые роли

Используйте ИИ для создания назначений ролей в Key Vault

GitHub Copilot поможет вам создать правильные Azure CLI или команды PowerShell для назначений ролей Key Vault на основе конкретных требований.

I need to set up Azure RBAC for my Key Vault. Help me create the role assignment commands for the following scenario:
- Key vault name: my-app-keyvault
- Resource group: my-app-rg
- Subscription ID: <subscription-id>
- I need to grant a managed identity (client ID: <managed-identity-client-id>) the ability to read and write secrets, but not manage keys or certificates.
Provide both Azure CLI and PowerShell commands, and explain which built-in role is most appropriate for this least-privilege scenario.

GitHub Copilot работает на ИИ, поэтому возможны как неожиданные результаты, так и ошибки. Дополнительные сведения см. в разделе Copilot часто задаваемые вопросы.

Часто задаваемые вопросы

Можно ли использовать назначения RBAC на уровне объекта в Azure для того, чтобы обеспечить изоляцию команд разработчиков приложений в Key Vault?

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

Подробнее

• Обзор Azure RBAC
• Назначьте роли Azure с помощью портала Azure
• Руководство по Пользовательским ролям
• Обеспечьте защиту Azure Key Vault