Рекомендации по управлению удостоверениями и доступом для акселератора целевой зоны Служб Azure Integration Services
В этой статье приведены инструкции, приведенные в статье о целевой зоне Azure для управления удостоверениями и доступом. Инструкции, приведенные в следующей статье, помогут вам определить рекомендации по проектированию и рекомендации, связанные с управлением удостоверениями и доступом, связанными с развертыванием служб Azure Integration Services (AIS). Если AIS развернут для поддержки критически важных платформ, в проектной области целевой зоны Azure также должны быть включены рекомендации по проектированию целевой зоны Azure.
Обзор управления удостоверениями и доступом (IAM)
В этой статье управление удостоверениями и доступом (IAM) относится к параметрам проверки подлинности и авторизации, доступным для развертывания или обслуживания ресурсов в Azure. На практике это предполагает определение удостоверений, имеющих разрешение на создание, обновление, удаление и управление ресурсами через портал Azure или через API Resource Manager.
IAM — это отдельное внимание от безопасности конечных точек, которое определяет, какие удостоверения могут вызывать и получать доступ к службам. Безопасность конечных точек рассматривается в отдельной статье по безопасности в этой серии. Это говорится, что иногда две области проектирования перекрываются: для некоторых служб в Azure доступ к конечной точке настраивается с помощью тех же элементов управления RBAC, используемых для управления доступом к ресурсам.
Рекомендации по проектированию
Определите границы администрирования ресурсов Azure для развернутых ресурсов, учитывая разделение обязанностей и эффективность работы.
Просмотрите действия администрирования и управления Azure, которые требуют от ваших команд. Рассмотрим ресурсы AIS, которые вы развернете и как их будете использовать. Определите наилучшее возможное распределение обязанностей в вашей организации.
Рекомендации по проектированию
Используйте управляемые удостоверения для ресурсов служб Integration Services. Подробные сведения об этой рекомендации см . в статье "Безопасность " в этой серии.
Используйте идентификатор Microsoft Entra для проверки подлинности в ресурсах служб integration Services.
Рассмотрите уровень доступа, необходимый ролям в организации, и примените принцип наименьших привилегий по ролям. Эти роли могут включать владельцев платформ, владельцев рабочих нагрузок, инженеров devops и системных администраторов, например.
Используя принцип наименьших привилегий, рассмотрите, какие роли необходимо управлять приложениями AIS и поддерживать их. Вопросы, которые следует задать в этой связи:
Кто потребуется просмотреть файлы журналов из источников, таких как Приложения Аналитика, Log Analytics и служба хранилища Учетные записи?
Должен ли любой пользователь просматривать исходные данные запроса (включая конфиденциальные данные)?
Где можно просматривать исходные данные запроса (например, только из корпоративной сети)?
Кто может просматривать журнал выполнения для рабочего процесса?
Кто может повторно отправить неудачный запуск?
Кто требуется доступ к ключам подписки Управление API?
Кто может просматривать содержимое раздела или подписки служебная шина или просматривать метрики очереди или раздела?
Кто необходимо иметь возможность администрирования Key Vault?
Кто необходимо иметь возможность добавлять, изменять или удалять ключи, секреты и сертификаты в Key Vault?
Кто необходимо иметь возможность просматривать и читать ключи, секреты или сертификаты в Key Vault?
Будут ли существующие встроенные роли и группы Microsoft Entra охватывать определенные требования?
Создайте пользовательские роли, чтобы ограничить доступ или обеспечить более подробную степень разрешения при недостаточной блокировке доступа встроенными ролями. Например, для доступа к URL-адресу обратного вызова для приложения логики требуется одно разрешение, но для этого типа доступа нет встроенной роли, отличной от "Участник" или "Владелец", которые слишком широки.
Ознакомьтесь с использованием Политика Azure, чтобы ограничить доступ к определенным ресурсам или обеспечить соответствие политике компании. Например, можно создать политику, которая разрешает развертывание только Управление API API, использующих зашифрованные протоколы.
Просмотрите распространенные действия, связанные с администрированием и управлением AIS в Azure, и назначьте разрешения RBAC соответствующим образом. Дополнительные сведения о доступных разрешениях см. в операциях поставщика ресурсов.
Ниже приведены некоторые примеры распространенных действий администрирования Azure:
| Ресурс Azure | Поставщик ресурсов Azure | Процедуры |
|---|---|---|
| План службы приложений | Microsoft.Web/serverfarms | Чтение, присоединение, перезапуск, получение Подключение виртуальной сети |
| API подключения | Microsoft.Web/connections | Обновление, подтверждение |
| Logic Apps и Функции | Microsoft.Web/sites | Чтение, запуск, остановка, перезапуск, переключение, обновление конфигурации, диагностика чтения, получение Подключение виртуальной сети |
| Учетная запись интеграции | Microsoft.Logic/integrationAccounts | Чтение/ добавление/ обновление/ удаление сборок, чтение/ добавление/обновление/удаление Карты, чтение/добавление/обновление/удаление схем, чтение/добавление/удаление соглашений, чтение/обновление/удаление партнеров |
| Cлужебная шина | Microsoft.ServiceBus | Чтение, получение строки Подключение ion, обновление конфигурации аварийного восстановления, очередей чтения, разделов чтения, подписок на чтение |
| Учетная запись хранения | Microsoft.Storage/storageAccounts | Чтение, изменение (например, журнал выполнения рабочего процесса) |
| Управление API | Microsoft.ApiManagement | Регистрация и удаление пользователя, чтение API, управление авторизациями, управление кэшем |
| Key Vault | Microsoft.KeyVault/vaults | Создание хранилища, изменение политик доступа |
Следующий шаг
Просмотрите критически важные области проектирования, чтобы выполнить полные рекомендации и рекомендации по архитектуре.