Переход к модели разрешений с управлением доступом на основе ролей в 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
• Специалист по сертификатам хранилища ключей
• Пользователь сертификата Key Vault
• Специалист по шифрованию хранилища ключей
• Пользователь шифрования хранилища ключей
• Пользователь службы шифрования хранилища ключей
• Пользователь выпуска службы шифрования Key Vault
• Специалист по секретам хранилища ключей
• Пользователь секретов хранилища ключей

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

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

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

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

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

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

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

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

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

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

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

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

Руководство по переходу с использования политик доступа к хранилищу на Azure RBAC

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

1. Определение и назначение ролей. Определите встроенные роли на основе приведенной выше таблицы соответствия и при необходимости создайте настраиваемые роли. Назначайте роли в тех областях, которые рекомендуются в таблице соответствия. Дополнительные сведения о назначении ролей для хранилища ключей см. в статье "Предоставление доступа к ключам, сертификатам и секретам Key Vault с помощью управления доступом на основе ролей в Azure".
2. Проверка назначения ролей. На то, чтобы назначенные в Azure RBAC роли вступили в силу, может потребоваться несколько минут. Инструкции по проверке назначений ролей см. в разделе "Получение списка назначенных пользователю ролей в области" статьи "Получение списка назначенных ролей Azure с помощью портала Azure".
3. Настройка мониторинга и оповещений для хранилища ключей. Важно включить ведение журнала и настроить оповещения об исключениях, связанных с запретом доступа. Дополнительные сведения см. в статье "Мониторинг и оповещения Azure Key Vault".
4. Настройка управления доступом на основе ролей Azure для Key Vault. При включении модели разрешений Azure RBAC все существующие политики доступа станут недействительными. В случае ошибки можно вернуть прежнюю модель разрешений — при этом все заданные ранее политики доступа остаются нетронутыми.

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

Для изменения модели разрешений хранилища ключей требуются два разрешения:

• Разрешение Microsoft.Authorization/roleAssignments/write, которое входит в роль владельца и роль администратора доступа пользователей.
• Разрешение Microsoft.KeyVault/vaults/write, которое входит в роль участника Key Vault.

Классические роли администратора подписки, такие как "Администратор службы" и "Соадминистратор", не поддерживаются.

Управление миграцией

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

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

1. Перейдите к ресурсу политики.
2. Выберите назначения в разделе "Создание" в левой части страницы Политика Azure.
3. Выберите " Назначить политику " в верхней части страницы. Эта кнопка откроется на странице назначения политики.
4. Введите следующие сведения:
   • Определите область политики, выбрав подписку и группу ресурсов, над которой будет применяться политика. Выберите, нажав кнопку с тремя точками в поле "Область ".
   • Выберите имя определения политики: "[предварительная версия]: Azure Key Vault должен использовать модель разрешений RBAC".
   • Перейдите на вкладку "Параметры " в верхней части страницы и определите нужный эффект политики (аудит, запрет или отключение).
5. Заполните все дополнительные поля. Перейдите на вкладки, нажав кнопки "Назад " и "Далее " в нижней части страницы.
6. Нажмите Проверить и создать.
7. Нажмите кнопку Создать

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

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

• Интеграция Azure Key Vault с Политикой Azure

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

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

Устранение неполадок

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

Подробнее

• Обзор Azure RBAC
• Учебник по настраиваемым ролям
• Управление привилегированными пользователями