Поделиться через

Управление удостоверениями и доступом

  • Статья

В этой статье рассматриваются вопросы проектирования и рекомендации по управлению удостоверениями и доступом. В нем основное внимание уделяется развертыванию облачной платформы аналитики в Microsoft Azure. Так как аналитика в масштабе облака является критически важным элементом, руководство по проектированию целевой зоны Azure также должно быть включено в проект.

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

Структура целевой зоны данных

Аналитика в масштабе облака поддерживает модель управления доступом с помощью удостоверений Microsoft Entra. В этой модели используются как управление доступом на основе ролей (Azure RBAC), так и списки управления доступом (ACL).

Изучите действия по администрированию и управлению Azure, выполняемые вашими командами. Рассмотрим облачную аналитику в Azure. Определите наилучшее возможное распределение обязанностей в вашей организации.

Назначения ролей

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

Среда разработки должна быть предоставлена командой разработки и соответствующими удостоверениями пользователей, чтобы они могли выполнять итерацию более быстро, узнать о некоторых возможностях в службах Azure и эффективно устранять проблемы. Доступ к среде разработки поможет при разработке или улучшении инфраструктуры в виде кода (IaC) и других артефактов кода. После того как реализация в среде разработки работает должным образом, она может быть непрерывно развернута в более высоких средах. Более высокие среды, такие как тест и prod, должны быть заблокированы для команды приложений данных. Только субъект-служба должен иметь доступ к этим средам, поэтому все развертывания должны выполняться с помощью удостоверения субъекта-службы с помощью конвейеров CI/CD. Сводные сведения о том, что права доступа к среде разработки должны предоставляться субъекту-службе и удостоверениям пользователей, а в более высоких средах — только удостоверениям субъекта-службы.

Чтобы иметь возможность создавать ресурсы и назначения ролей между ресурсами в группах ресурсов приложения данных, Contributor а User Access Administrator права должны быть предоставлены. Это позволит командам создавать и контролировать службы в своей среде в пределах Политика Azure. Аналитика в масштабе облака рекомендует использовать частные конечные точки для преодоления риска кражи данных и так как другие варианты подключения должны быть заблокированы командой платформы Azure с помощью политик, команды приложений данных потребуют права доступа к общей виртуальной сети целевой зоны данных, чтобы иметь возможность успешно настроить требуемое сетевое подключение для служб, которые они планируют использовать. Чтобы следовать принципу наименьших привилегий, преодолеть конфликты между разными командами приложений данных и иметь четкое разделение команд, аналитика в масштабе облака предлагает создать выделенную подсеть для каждой группы приложений данных и создать Network Contributor назначение ролей для этой подсети (дочерний ресурс область). Это назначение ролей позволяет командам присоединяться к подсети с помощью частных конечных точек.

Эти две первые назначения ролей позволяют самостоятельно развертывать службы данных в этих средах. Чтобы устранить проблему управления затратами, организации должны добавить тег центра затрат в группы ресурсов, чтобы включить перекрестную зарядку и распределенную ответственность за затраты. Это повышает осведомленность в командах и применяет их для принятия правильных решений в отношении необходимых номеров SKU и уровней служб.

Чтобы также включить самостоятельное использование других общих ресурсов в целевой зоне данных, требуются несколько дополнительных назначений ролей. Если требуется доступ к среде Databricks, организации должны использовать scIM Synch из идентификатора Microsoft Entra для предоставления доступа. Это важно, так как этот механизм автоматически синхронизирует пользователей и группы из идентификатора Microsoft Entra с плоскости данных Databricks, а также автоматически удаляет права доступа, когда отдельный пользователь покидает организацию или бизнес. Это не может быть так, если отдельные учетные записи пользователей используются в Azure Databricks. Команды приложений данных должны быть добавлены в рабочую область Databricks в shared-product-rg и в .shared-integration-rg В Azure Databricks команды приложений данных должны иметь Can Restart права доступа к предварительно определенному кластеру, чтобы иметь возможность выполнять рабочие нагрузки в рабочей области.

Отдельным командам потребуется доступ к центральной учетной записи Purview для обнаружения ресурсов данных в соответствующих целевых зонах данных. Таким образом, команды должны быть добавлены в Data Reader коллекцию верхнего уровня Purview. Кроме того, в большинстве случаев командам потребуется изменить каталогированные ресурсы данных, которые они принадлежат, чтобы предоставить дополнительные сведения, такие как контактные данные владельцев и экспертов, а также более детализированные сведения о столбцах в наборе данных и о том, какие сведения они включают.

Сводка требований к управлению доступом на основе ролей

Для автоматизации развертывания целевых зон данных необходимы следующие роли:

Имя роли

Description

Область действия

Участник частной зоны DNS

Разверните все частные зоны 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 также не требуется, если развертывание A-записей DNS частных конечных точек осуществляется автоматически через политики Azure с помощью эффекта deployIfNotExists. Это справедливо и для User Access Administrator, поскольку развертывание можно автоматизировать с помощью политик deployIfNotExists.

Назначения ролей для продуктов данных

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

Имя роли

Description

Область действия

Участник частной зоны DNS

Разверните все частные зоны DNS для всех служб данных в одной подписке и группе ресурсов. Субъект-служба должен находиться Private DNS Zone Contributor в глобальной группе ресурсов DNS, созданной в процессе развертывания целевой зоны управления данными. Эта роль необходима для развертывания записей A для соответствующих частных конечных точек.

(Область группы ресурсов) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}

Участник

Разверните все службы потоковой передачи интеграции данных в одну группу ресурсов в подписке на целевую зону данных. Субъекту-службе требуется назначение роли Contributor для этой группы ресурсов.

(Область группы ресурсов) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}

Участник сети

Чтобы развернуть частные конечные точки в указанной подсети приватного канала, созданной при развертывании целевой зоны данных, субъекту-службе требуется доступ Network Contributor к этой подсети.

(Область дочернего ресурса) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"

Доступ к другим ресурсам

За пределами Azure, продуктов данных и команд Интеграция данных также потребуется доступ к репозиторию для хранения артефактов кода, эффективной совместной работы и последовательного развертывания обновлений и изменений с помощью CI/CD в более высоких средах. Кроме того, необходимо предоставить доска проекта для обеспечения гибкой разработки, планирования спринта, отслеживания задач, а также отзывов пользователей и запросов функций.

Наконец, для автоматизации CI/CD потребуется настроить подключение к Azure, которое выполняется в большинстве служб с помощью принципов обслуживания. Таким образом, командам потребуется доступ к принципу службы для обеспечения автоматизации в рамках своего проекта.

Управление доступом к данным

Управление доступом к данным должно выполняться с помощью групп Microsoft Entra. Добавьте имена принципов пользователя или субъект-службу в группы Microsoft Entra. Добавьте группы в службы и предоставьте разрешения группе. Такой подход обеспечивает детальное управление доступом.

Для продуктов данных в озерах данных Azure рекомендуется использовать списки управления доступом (ACL). Дополнительные сведения см. в статье Модель контроля доступа в Azure Data Lake Storage 2-го поколения. Использование сквозного руководства Microsoft Entra с списками управления доступом поддерживается большинством собственных служб Azure, включая Машинное обучение Azure, Azure Synapse SQL Serverless, Apache Spark для Azure Synapse и Azure Databricks.

Другое хранилище polyglot, скорее всего, будет использоваться в облачной аналитике. В качестве примеров можно привести Базу данных Azure для PostgreSQL, Базу данных Azure для MySQL, Базу данных Azure SQL, Управляемый экземпляр SQL и выделенные пулы Azure Synapse SQL. Они могут использоваться командами приложений данных для хранения продуктов данных.

Мы рекомендуем использовать группы Microsoft Entra для защиты объектов базы данных вместо отдельных учетных записей пользователей Microsoft Entra. Эти группы Microsoft Entra используются для проверки подлинности пользователей и защиты объектов базы данных. Аналогично шаблону озера данных, вы можете использовать домен или продукты данных для создания этих групп в службе Microsoft Entra.

Этот подход также обеспечивает единую точку управления и позволяет просматривать права доступа в Azure Graph.

Дополнительные сведения о том, как управлять безопасностью для целевых зон управления данными и целевыми зонами данных, управляемыми вашим объемом данных, см. в статье "Подготовка безопасности для аналитики в масштабе облака" в Azure.

Следующие шаги