Переход к модели разрешений с управлением доступом на основе ролей в Azure вместо политик доступа к хранилищу

2025-05-04

Azure Key Vault предлагает две системы авторизации: управление доступом на основе ролей Azure (Azure RBAC) и модель политики доступа. Azure RBAC — это стандартная и рекомендуемая система авторизации для Azure Key Vault. Сравнение двух методов авторизации см. в статье " Управление доступом на основе ролей Azure" (Azure RBAC) и политики доступа.

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

Соответствие между политиками доступа и ролями Azure

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

Встроенные роли Key Vault для управления доступом к ключам, сертификатам и секретам:

Администратор хранилища ключей
Читатель Key Vault
Оператор очистки Key Vault
Специалист по сертификатам хранилища ключей
Пользователь сертификата Key Vault
Специалист по шифрованию хранилища ключей
Пользователь шифрования хранилища ключей
Пользователь службы шифрования хранилища ключей
Пользователь выпуска службы шифрования Key Vault
Специалист по секретам хранилища ключей
Пользователь секретов хранилища ключей

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

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

Предопределенные шаблоны разрешений для политик доступа:

управление ключами, секретами и сертификатами;
Управление ключами и секретами
управление секретами и сертификатами;
Управление ключами
Управление секретами
Управление сертификатами
Соединитель SQL Server
Azure Data Lake Storage или служба хранилища Azure;
Azure Backup
Ключ клиента Exchange Online
ключ клиента SharePoint Online;
BYOK для сведений в Azure

Соответствие между шаблонами политик доступа и ролями Azure

Шаблон политики доступа	Операции	Роль Azure
управление ключами, секретами и сертификатами;	Ключи: все операции Сертификаты: все операции Секреты: все операции	Администратор хранилища ключей
Управление ключами и секретами	Ключи: все операции Секреты: все операции	Сотрудник по шифрованию Key Vault Специалист по секретам хранилища ключей
управление секретами и сертификатами;	Сертификаты: все операции Секреты: все операции	Сотрудник по сертификатам Key Vault Специалист по секретам хранилища ключей
Управление ключами	Ключи: всех операции	Специалист по шифрованию хранилища ключей
Управление секретами	Секреты: все операции	Специалист по секретам хранилища ключей
Управление сертификатами	Сертификаты: все операции	Специалист по сертификатам хранилища ключей
Соединитель SQL Server	Ключи: получение, перечисление, упаковка ключа, распаковка ключа	Пользователь службы шифрования хранилища ключей
Azure Data Lake Storage или служба хранилища Azure;	Ключи: получение, перечисление, распаковка ключа	Н/П Требуется настраиваемая роль
Azure Backup	Ключи: получение, перечисление, резервное копирование Секреты: получение, вывод списка, резервное копирование	Н/П Требуется настраиваемая роль
Ключ клиента Exchange Online	Ключи: получение, перечисление, упаковка ключа, распаковка ключа	Пользователь службы шифрования хранилища ключей
Ключ клиента Exchange Online	Ключи: получение, перечисление, упаковка ключа, распаковка ключа	Пользователь службы шифрования хранилища ключей
BYOK для сведений в Azure	Ключи: получение, расшифровка, подписание	Н/П Требуется настраиваемая роль

Соответствие областей назначения

Azure RBAC для Key Vault позволяет назначать роли в следующих областях:

Группа управления
Подписка
Группа ресурсов
ресурс Key Vault;
отдельные ключ, секрет и сертификат.

В модели разрешений с использованием политик доступа к хранилищу можно назначать политики только на уровне ресурсов Key Vault.

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

Инфраструктура, администраторы безопасности и операторы: управление группами хранилищ ключей на уровне группы управления, подписки или группы ресурсов с помощью политик доступа к хранилищу требует поддержки политик для каждого хранилища ключей. Azure RBAC позволяет единожды назначить роли на уровне группы управления, подписки или группы ресурсов. Это назначение будет действовать в отношении всех новых хранилищ ключей, созданных в той же области. В таком сценарии рекомендуется использовать управление привилегированными пользователями с JIT-доступом вместо постоянного доступа.
Приложения: существуют сценарии, когда приложению потребуется предоставить общий доступ к секрету другим приложениям. Если использовать политики доступа к хранилищу, то придется для этого создать отдельное хранилище ключей, чтобы не предоставлять доступ ко всем секретам. Azure RBAC позволяет назначать роли с областью, распространяющейся на отдельный секрет, вместо использования одного хранилища ключей.

Способы миграции

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

Подготовка. Убедитесь, что у вас есть соответствующие разрешения и инвентаризация приложений.
Инвентаризация: документируйте все существующие политики доступа и разрешения.
Создайте роли RBAC: назначьте соответствующие роли RBAC каждому субъекту безопасности.
Включите RBAC: переключите хранилище ключей для использования модели разрешений RBAC.
Проверка: проверка доступа, чтобы убедиться, что все приложения и пользователи сохраняют соответствующий доступ.
Мониторинг. Настройка мониторинга и оповещения для проблем с доступом.

Необходимые компоненты

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

Необходимые разрешения: у вас должны быть следующие разрешения в хранилище ключей:
- Microsoft.Authorization/roleAssignments/write разрешение, входящее в состав ролей "Владелец" и "Администратор доступа пользователей"
- Microsoft.KeyVault/vaults/write разрешение, включенное в роль участника Key Vault
Примечание.

Роли администратора классической подписки (администратор службы и Co-Administrator) не поддерживаются.
Инвентаризация приложений и удостоверений: список всех приложений, служб и пользователей, которые обращаются к хранилищу ключей, а также документируйте все текущие политики доступа и предоставленные им разрешения.

Инвентаризация текущих политик доступа

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

Используйте команду Azure CLI az keyvault show , чтобы получить политики доступа:

# List all current access policies
az keyvault show --name <vault-name> --resource-group <resource-group-name> --query properties.accessPolicies

Используйте командлет Get-AzKeyVault для получения политик доступа:

# List all current access policies
$vault = Get-AzKeyVault -VaultName "<vault-name>" -ResourceGroupName "<resource-group-name>"
$vault.AccessPolicies

Создание эквивалентных назначений ролей RBAC

Для каждого субъекта безопасности с политикой доступа создайте одно или несколько назначений ролей RBAC на основе приведенной выше таблицы сопоставления.

Используйте команду az role assignment create , чтобы предоставить соответствующие роли:

# Example for Key Vault Administrator role:
az role assignment create --role "Key Vault Administrator" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Secrets Officer:
az role assignment create --role "Key Vault Secrets Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Crypto Officer:
az role assignment create --role "Key Vault Crypto Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Certificates Officer:
az role assignment create --role "Key Vault Certificates Officer" --assignee "<object-id-or-email>" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

Используйте командлет New-AzRoleAssignment, чтобы предоставить соответствующие роли:

# Example for Key Vault Administrator role:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Administrator" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Secrets Officer:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Secrets Officer" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Crypto Officer:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Crypto Officer" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

# Example for Key Vault Certificates Officer:
New-AzRoleAssignment -RoleDefinitionName "Key Vault Certificates Officer" -ObjectId "<object-id>" -Scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.KeyVault/vaults/<vault-name>"

Включение модели разрешений RBAC

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

Используйте команду az keyvault update , чтобы включить RBAC:

# Switch the vault to RBAC permission model
az keyvault update --name <vault-name> --resource-group <resource-group-name> --enable-rbac-authorization true

Используйте командлет Update-AzKeyVault , чтобы включить RBAC:

# Switch the vault to RBAC permission model
$vault = Get-AzKeyVault -VaultName "<vault-name>" -ResourceGroupName "<resource-group-name>"
Update-AzKeyVault -VaultName $vault.VaultName -ResourceGroupName $vault.ResourceGroupName -EnableRbacAuthorization $true

Проверка доступа

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

Проверьте доступ с помощью следующих команд:

# Try to list secrets to verify access
az keyvault secret list --vault-name <vault-name>

# Try to get a secret to verify access
az keyvault secret show --vault-name <vault-name> --name <secret-name>

Проверьте доступ с помощью следующих командлетов (cmdlets для PowerShell):

# Try to list secrets to verify access
Get-AzKeyVaultSecret -VaultName "<vault-name>"

# Try to get a secret to verify access
Get-AzKeyVaultSecret -VaultName "<vault-name>" -Name "<secret-name>"

Настройка мониторинга и оповещения

После миграции настройте надлежащий мониторинг для обнаружения проблем с доступом:

Используйте команду az monitor diagnostic-settings create:

# Enable diagnostics logging for Key Vault
az monitor diagnostic-settings create --resource <vault-id> --name KeyVaultLogs --logs "[{\"category\":\"AuditEvent\",\"enabled\":true}]" --workspace <log-analytics-workspace-id>

Используйте командлет Set-AzDiagnosticSetting :

# Get the vault resource ID
$vaultResourceId = (Get-AzKeyVault -VaultName "<vault-name>" -ResourceGroupName "<resource-group-name>").ResourceId

# Enable diagnostics logging for Key Vault
$logs = @()
$logs += New-AzDiagnosticSettingLogSettingsObject -Category "AuditEvent" -Enabled $true
Set-AzDiagnosticSetting -ResourceId $vaultResourceId -Name "KeyVaultLogs" -WorkspaceId "<log-analytics-workspace-id>" -Log $logs

Управление миграцией с помощью политики Azure

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

Создание и назначение определения политики для модели разрешений RBAC Azure Key Vault

Перейдите к ресурсу политики.
Выберите «Задания» в разделе «Создание» на левой стороне страницы «Политика Azure»
Выберите "Назначить политику " в верхней части страницы
Введите следующие сведения:
- Определение области политики путем выбора подписки и группы ресурсов
- Выберите определение политики: "[Предварительная версия]: Azure Key Vault должен использовать модель разрешений RBAC"
- Определите требуемый эффект политики (аудит, запрет или отключение)
Завершите задание, сначала проверив его, а затем создав его

После назначения политики завершение проверки может занять до 24 часов. После завершения проверки вы увидите результаты соответствия на панели мониторинга политики Azure.

Политика доступа к средству сравнения Azure RBAC

Внимание

Это средство создается и поддерживается членами сообщества Майкрософт и без официальной поддержки служб поддержки клиентов. Средство предоставляется КАК IS без каких-либо гарантий.

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

Устранение распространенных проблем

Задержка назначения ролей: для распространения назначений ролей может потребоваться несколько минут. Реализуйте логику повторных попыток в приложениях.
Утраченные назначения ролей после восстановления: Назначения ролей не сохраняются при восстановлении хранилища после обратимого удаления. После восстановления необходимо восстановить все назначения ролей.
Ошибки отказа в доступе: проверьте, что:
- Правильные роли назначаются в правильной области охвата
- Управляемый служебный субъект или удостоверение имеет необходимые точные разрешения.
- Правила доступа к сети не блокируют подключение
Сбой скриптов после миграции: обновите скрипты, которые использовали политики доступа, заменив их на назначения ролей.