Переход к модели разрешений с управлением доступом на основе ролей в Azure вместо политик доступа к хранилищу
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
- Специалист по шифрованию хранилища ключей
- Пользователь шифрования хранилища ключей
- Пользователь службы шифрования хранилища ключей
- Специалист по секретам хранилища ключей
- Пользователь секретов хранилища ключей
Дополнительные сведения о встроенных ролях см. в статье "Встроенные роли 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 на портале Azure не поддерживает модель разрешений RBAC Key Vault. Вы можете использовать развертывания шаблонов Azure PowerShell, Azure CLI, ARM с назначением роли пользователя сертификата Key Vault для Служба приложений глобального удостоверения, например службы Microsoft приложение Azure в общедоступном облаке.
Соответствие областей назначения
Azure RBAC для Key Vault позволяет назначать роли в следующих областях:
- Группа управления
- Подписка
- Группа ресурсов
- ресурс Key Vault;
- отдельные ключ, секрет и сертификат.
В модели разрешений с использованием политик доступа к хранилищу можно назначать политики только на уровне ресурсов Key Vault.
Как правило, рекомендуется использовать одно хранилище ключей на каждое приложение и управлять доступом на уровне хранилища ключей. Существуют сценарии, при которых управление доступом упрощается, если осуществлять его в других областях.
Инфраструктура, администраторы безопасности и операторы: управление группой хранилищ ключей на уровне группы управления, подписки или группы ресурсов с использованием политик доступа к хранилищу требует поддержания набора политик для каждого хранилища ключей в отдельности. Azure RBAC позволяет единожды назначить роли на уровне группы управления, подписки или группы ресурсов. Это назначение будет действовать в отношении всех новых хранилищ ключей, созданных в той же области. В таком сценарии рекомендуется использовать управление привилегированными пользователями с JIT-доступом вместо постоянного доступа.
Приложения: существуют сценарии, когда приложению требуется поделиться секретом с другим приложением. Если использовать политики доступа к хранилищу, то придется для этого создать отдельное хранилище ключей, чтобы не предоставлять доступ ко всем секретам. Azure RBAC позволяет назначать роли с областью, распространяющейся на отдельный секрет, вместо использования одного хранилища ключей.
Руководство по переходу с использования политик доступа к хранилищу на Azure RBAC
Между Azure RBAC и моделью разрешений на основе политик доступа к хранилищу есть множество различий. Чтобы избежать сбоев во время перехода с одной модели на другую, рекомендуется выполнить указанные ниже действия.
- Определение и назначение ролей. Определите встроенные роли на основе приведенной выше таблицы соответствия и при необходимости создайте настраиваемые роли. Назначайте роли в тех областях, которые рекомендуются в таблице соответствия. Дополнительные сведения о назначении ролей для хранилища ключей см. в статье "Предоставление доступа к ключам, сертификатам и секретам Key Vault с помощью управления доступом на основе ролей в Azure".
- Проверка назначения ролей. На то, чтобы назначенные в Azure RBAC роли вступили в силу, может потребоваться несколько минут. Инструкции по проверке назначений ролей см. в разделе "Получение списка назначенных пользователю ролей в области" статьи "Получение списка назначенных ролей Azure с помощью портала Azure".
- Настройка мониторинга и оповещений для хранилища ключей. Важно включить ведение журнала и настроить оповещения об исключениях, связанных с запретом доступа. Дополнительные сведения см. в статье "Мониторинг и оповещения Azure Key Vault".
- Настройка управления доступом на основе ролей Azure для Key Vault. При включении модели разрешений Azure RBAC все существующие политики доступа станут недействительными. В случае ошибки можно вернуть прежнюю модель разрешений — при этом все заданные ранее политики доступа остаются нетронутыми.
Примечание.
Для изменения модели разрешений требуется разрешение "Microsoft.Authorization/roleAssignments/write", которым обладают роли Владелец и Администратор доступа пользователей. Классические роли администратора подписки, такие как "Администратор службы" и "Соадминистратор", не поддерживаются.
Примечание.
Если включена модель разрешений Azure RBAC, все сценарии, в которых предпринимается попытка обновить политики доступа, будут завершаться ошибкой. Важно обновить эти скрипты для использования Azure RBAC.
Управление миграцией
С помощью службы "Политика Azure" вы можете управлять переносом модели разрешений RBAC между хранилищами. Вы можете создать пользовательское определение политики для аудита существующих хранилищ ключей и принудительно применить модель разрешений RBAC Azure во всех новых хранилищах ключей.
Создание и назначение определения политики для модели разрешений RBAC Azure Key Vault
- Перейдите к ресурсу политики.
- Выберите назначения в разделе "Создание" в левой части страницы Политика Azure.
- Выберите " Назначить политику " в верхней части страницы. Эта кнопка откроется на странице назначения политики.
- Введите следующие сведения:
- Определите область политики, выбрав подписку и группу ресурсов, над которой будет применяться политика. Выберите, нажав кнопку с тремя точками в поле "Область ".
- Выберите имя определения политики: "[предварительная версия]: Azure Key Vault должен использовать модель разрешений RBAC".
- Перейдите на вкладку "Параметры " в верхней части страницы и определите нужный эффект политики (аудит, запрет или отключение).
- Заполните все дополнительные поля. Перейдите на вкладки, нажав кнопки "Назад " и "Далее " в нижней части страницы.
- Нажмите Проверить и создать.
- Нажмите кнопку Создать
После назначения встроенной политики может потребоваться до 24 часов для завершения проверки. После завершения сканирования вы сможете просмотреть результаты соответствия требованиям, как показано ниже.
Дополнительные сведения доступны здесь.
Политика доступа к средству сравнения Azure RBAC
Важно!
Это средство создается и поддерживается членами сообщества Майкрософт и без официальной поддержки служб поддержки клиентов. Средство предоставляется КАК IS без каких-либо гарантий.
Средство PowerShell для сравнения политик доступа Key Vault с назначенными ролями RBAC для миграции модели разрешений RBAC. Средство предназначено для предоставления разумности проверка при переносе существующей модели разрешений Key Vault в RBAC, чтобы гарантировать, что назначенные роли с базовыми действиями данных охватывают существующие политики доступа.
Устранение неполадок
- Назначения ролей не вступили в силу через несколько минут: существуют ситуации, когда назначение ролей может занять больше времени. На этот случай важно предусмотреть в коде повторные попытки.
- Назначения ролей исчезли после того, как хранилище ключей было удалены (обратимым способом) и восстановлено: сейчас такое ограничение есть у функции обратимого удаления во всех службах Azure. После восстановления необходимо повторно создать все назначения ролей.