Управление удостоверениями и доступом
В этой статье описаны рекомендации по проектированию и рекомендации по управлению удостоверениями и доступом. В нем основное внимание уделяется развертыванию облачной платформы аналитики в Microsoft Azure. Так как аналитика в масштабе облака является критически важным компонентом, при разработке решения следует следовать рекомендациям по проектированию целевых зон Azure.
В этой статье рассматриваются соображения и рекомендации по посадочным зонам Azure. Дополнительные сведения см. в области проектирования удостоверений и управления доступом .
Проектирование зоны приема данных
Аналитика в масштабе облака поддерживает модель управления доступом с помощью удостоверений Microsoft Entra. В модели используются управление доступом на основе ролей Azure (Azure RBAC) и списки управления доступом.
Просмотрите действия администрирования и управления Azure, выполняемые вашей командой. Оцените масштабируемую облачную аналитику в Azure. Определите оптимальное распределение обязанностей в организации.
Назначения ролей
Для разработки, доставки и обслуживания продуктов данных автономно в рамках платформы данных команды приложений данных требуют нескольких прав доступа в среде Azure. Важно отметить, что для разработки и более высоких сред следует использовать различные модели доступа. Используйте группы безопасности, если это возможно, чтобы уменьшить количество назначений ролей и упростить процесс управления и проверки прав RBAC. Этот шаг имеет решающее значение из-за ограниченного количества назначений ролей, которые можно создать для каждой подписки.
Среда разработки должна быть доступна команде разработчиков и их учетным данным пользователей. Этот доступ позволяет им выполнять итерацию быстрее, узнать о некоторых возможностях в службах Azure и эффективно устранять проблемы. Доступ к среде разработки может помочь вам разработать или улучшить инфраструктуру в виде кода и другие артефакты кода.
Убедившись, что реализация работает должным образом в среде разработки, ее можно развертывать непрерывно в более высоких средах. Более высокие среды, такие как тестирование и эксплуатация, должны иметь ограниченный доступ для команды, занимающейся приложениями данных. Доступ к этим средам должен иметь только служебный принципал. Таким образом, все развертывания должны выполняться через идентификатор главного объекта службы с помощью конвейеров непрерывной интеграции и непрерывной доставки (CI/CD). В среде разработки предоставьте права доступа как для сервисного принципала, так и для учетных записей пользователей. В более защищённых средах следует ограничить доступ исключительно удостоверению служебной учётной записи.
Чтобы создать ресурсы и составить назначения ролей между ресурсами в приложении данных, необходимо предоставить права Contributor и User Access Administrator. Эти права позволяют командам создавать и контролировать службы в своей среде в пределах границ политики Azure.
Чтобы снизить риск кражи данных, рекомендуется использовать частные конечные точки в облачной аналитике. Команда платформы Azure блокирует другие варианты подключения с помощью политик, поэтому командам приложений данных требуются права доступа к общей виртуальной сети целевой зоны данных. Этот доступ необходим для настройки необходимого сетевого подключения для служб, которые они планируют использовать.
Чтобы следовать принципу наименьшей привилегии, избегайте конфликтов между разными командами приложений данных и четко отделяйте команды. Рекомендуется применять лучшие практики аналитики облачных масштабов для создания выделенной подсети для каждой команды по приложениям данных и назначения роли Network Contributor для этой подсети или дочерней области ресурса. Это назначение роли позволяет командам присоединяться к подсети с помощью частных конечных точек.
Эти первые две назначения ролей позволяют самостоятельно развертывать службы данных в этих средах. Чтобы устранить проблемы управления затратами, организациям следует добавить тег центра затрат к группам ресурсов, чтобы обеспечить распределение затрат и распределенную ответственность за затраты. Этот подход повышает осведомленность в командах и помогает обеспечить принятие обоснованных решений о необходимых номерах SKU и уровнях служб.
Чтобы включить самостоятельное использование других общих ресурсов в зоне выгрузки данных, требуются несколько дополнительных назначений ролей. Если требуется доступ к среде Azure Databricks, организации должны использовать синхронизацию SCIM с идентификатора Microsoft Entra ID для предоставления доступа. Этот механизм синхронизации важен, так как он автоматически синхронизирует пользователей и группы из идентификатора Microsoft Entra с плоскости данных Azure Databricks. Он также автоматически удаляет права доступа, когда отдельный пользователь покидает организацию или бизнес. В Azure Databricks предоставьте командам приложений данных Can Restart права доступа к предварительно определенному кластеру, чтобы они могли выполнять рабочие нагрузки в рабочей области.
Для обнаружения ресурсов данных в соответствующих целевых зонах данных для отдельных команд требуется доступ к учетной записи Microsoft Purview. Командам часто требуется редактировать каталогизированные данные, принадлежащие им, для предоставления дополнительных сведений, таких как контактные данные владельцев данных и экспертов. Командам также требуется возможность предоставлять более детализированные сведения о том, что каждый столбец в наборе данных описывает и включает в себя.
Сводка требований к RBAC
Чтобы автоматизировать развертывание зон выгрузки данных, требуются следующие роли:
Имя роли
Описание
Размах
Разверните все частные зоны DNS для всех служб данных в одной подписке и группе ресурсов. Субъект-служба должен быть Private DNS Zone Contributor в глобальной группе ресурсов DNS, созданной во время развертывания целевой зоны управления данными. Эта роль необходима для развертывания записей A для частных конечных точек.
(область группы ресурсов) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Чтобы настроить пиринг виртуальной сети между сетью посадочной зоны данных и сетью посадочной зоны управления данными, служебный принципал должен иметь Network Contributor права доступа к группе ресурсов удаленной виртуальной сети.
(область группы ресурсов) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Это разрешение необходимо для совместного использования локальной среды выполнения интеграции, которая развертывается в группе ресурсов integration-rg с другими фабриками данных. Кроме того, необходимо предоставить доступ управляемым удостоверениям Фабрики данных Azure и Azure Synapse Analytics к файловым системам соответствующих учетных записей хранения.
(Область ресурсов) /subscriptions/{{dataLandingZone}subscriptionId}
Заметка
В рабочем сценарии можно уменьшить количество назначений ролей. Роль Network Contributor требуется только для настройки пиринга виртуальной сети между зоной приземления управления данными и зоной приземления данных. Без этой роли процесс разрешения DNS завершается ошибкой. Кроме того, входящий и исходящий трафик отбрасывается, так как нет видимости до брандмауэра Azure.
Роль Private DNS Zone Contributor не требуется, если развертывание записей DNS A для частных конечных точек автоматизировано с помощью политик Azure с deployIfNotExists эффектом. То же самое верно для роли User Access Administrator, так как вы можете автоматизировать развертывание с помощью политик deployIfNotExists.
Назначения ролей для продуктов данных
Для развертывания продукта данных в целевой зоне данных требуются следующие назначения ролей:
Имя роли
Описание
Размах
Разверните все частные зоны DNS для всех служб данных в одной подписке и группе ресурсов. Субъект-служба должен быть Private DNS Zone Contributor в глобальной группе ресурсов DNS, созданной во время развертывания целевой зоны управления данными. Эта роль необходима для развертывания записей типа A для конечных точек, используемых в частной сети.
(область группы ресурсов) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Разверните все службы потоковой интеграции данных в одну группу ресурсов в подписке зоны приёма данных. Субъект-служба требует назначения роли Contributor в этой группе ресурсов.
(область группы ресурсов) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Чтобы развернуть частные конечные точки в указанной подсети Azure Private Link, созданной во время развертывания зоны приземления данных, служебный принципал должен иметь Network Contributor доступ к этой подсети.
Дочерняя область ресурсов /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
Доступ к другим ресурсам
За пределами Azure команды приложений данных требуют доступа к репозиторию для хранения артефактов кода, эффективной совместной работы и последовательного развертывания обновлений и изменений в более высоких средах с помощью CI/CD. Вы должны предоставить доску проекта, чтобы обеспечить гибкую разработку, планирование спринтов, отслеживание задач и управление отзывами пользователей и запросами функций.
Чтобы автоматизировать CI/CD, установите подключение к Azure. Этот процесс выполняется в большинстве служб с помощью субъектов-служб. Из-за этого требования команды должны иметь доступ к субъекту-службе для обеспечения автоматизации в своем проекте.
Управление доступом к данным
Управление доступом к данным с помощью групп Microsoft Entra. Добавьте учетные записи пользователей или учетные записи служб в группы Microsoft Entra. Затем добавьте эти группы в службы и предоставьте разрешения группе. Такой подход позволяет точно контролировать доступ.
Дополнительные сведения о том, как управлять безопасностью целевых зон управления данными и целевыми зонами данных, которые управляют хранилищем данных, см. в статье Аутентификация для аналитики в масштабе облака в Azure.