Управление доступом и конфигурации озер данных в Azure Data Lake Storage 2-го поколения

Эта статья поможет оценить и понять механизмы управления доступом в Azure Data Lake Storage 2-го поколения. Эти механизмы включают управление доступом на основе ролей (RBAC) Azure и списки управления доступом (ACL). Вы узнаете:

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

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

Этот документ можно использовать с управлением доступом к данным.

Использование встроенных ролей Azure RBAC

В службе хранилища Azure предусмотрены два уровня доступа: управление службой и данные. Вы можете получить доступ к подпискам и учетным записям хранения с помощью уровня управления службами. Доступ к контейнерам, большим двоичным объектам и другим ресурсам данных через слой данных. Например, если вы хотите получить список учетных записей хранения из Azure, отправьте запрос в конечную точку управления. Если вам нужен список файловых систем, папок или файлов в учетной записи хранения, отправьте запрос в конечную точку службы.

Роли могут содержать разрешения на управление или доступ к уровню данных. Роль «Читатель» предоставляет доступ только для чтения к ресурсам уровня управления, но не имеет доступа для чтения данных.

Такие роли, как владелец, участник, читатель и служба хранилища участник учетной записи, позволяют субъекту безопасности управлять учетной записью хранения. Но они не предоставляют доступ к данным в этой учетной записи. Только роли, явно определенные для доступа к данным, позволяют субъекту безопасности получать доступ к данным. Эти роли, кроме читателя, получают доступ к ключам хранилища для доступа к данным.

Встроенные роли управления

Ниже приведены встроенные роли управления.

• Владелец: может управлять всем, включая доступ к ресурсам. Эта роль предоставляет доступ к ключам.
• Участник может управлять всем, кроме доступа к ресурсам. Эта роль предоставляет доступ к ключам.
• Участник учетной записи хранения: полное управление учетными записями хранения. Эта роль предоставляет доступ к ключам.
• Читатель: чтение и вывод списка ресурсов. Эта роль не предоставляет доступ к ключам.

Встроенные роли данных

Ниже приведены встроенные роли данных.

• служба хранилища владелец данных BLOB-объектов: полный доступ к контейнерам и данным больших двоичных объектов служба хранилища Azure, включая настройку владения и управление доступом POSIX.
• Участник данных BLOB-объекта хранилища: чтение, запись и удаления контейнеров и BLOB-объектов службы хранилища Azure.
• Читатель данных BLOB-объекта хранилища: чтение и получение списка контейнеров и BLOB-объектов службы хранилища Azure.

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

Примечание.

Для передачи и вступления в силу назначений Azure RBAC может потребоваться до пяти минут.

Как оценивается доступ

Во время авторизации на основе субъекта безопасности система оценивает разрешения в следующем порядке. Дополнительные сведения см. на следующей схеме.

• Сначала производится оценка Azure RBAC, которая является более приоритетной по сравнению со всеми назначениями ACL.
• Если операция полностью авторизована на основе RBAC, списки управление доступом не рассматриваются.
• Если операция не является полностью авторизованной, выполняется проверка по спискам контроля доступа.

Дополнительные сведения см. в разделе Оценка разрешений.

Примечание.

Эта модель разрешений применяется только к Azure Data Lake Storage. Он не применяется к общему назначению или хранилищу BLOB-объектов без включения иерархического пространства имен. В это описание не вошли общие ключи и методы проверки подлинности SAS. Он также исключает сценарии, в которых субъект безопасности назначается встроенной ролью служба хранилища владельца данных BLOB-объектов, которая обеспечивает доступ суперпользователя. Установите значение allowSharedKeyAccess false, чтобы доступ был проверен удостоверением.

Дополнительные сведения о том, какие требуются разрешения на основе список управления доступом для данной операции, см. в разделе Списки управления доступом в Azure Data Lake Storage 2-го поколения.

Примечание.

• Списки управления доступом применяются только к субъектам безопасности в том же клиенте, включая гостевых пользователей.
• Точки подключения Azure Databricks может создавать любой пользователь с разрешениями на подключение к кластеру. Настройте точку подключения с помощью учетных данных субъекта-службы или параметра сквозного руководства Microsoft Entra. В момент создания оценка разрешений не выполняется. Оценка разрешений происходит, когда операция использует точку подключения. Любой пользователь, который может подключиться к кластеру, может попытаться использовать точку подключения.
• Когда пользователь создает определение таблицы в Azure Databricks или Azure Synapse Analytics, он должен иметь доступ на чтение к базовым данным.

Настройка доступа к Azure Data Lake Storage

Настройте управление доступом в Azure Data Lake служба хранилища с помощью Azure RBAC, списков управления доступом или сочетания обоих.

Настройка доступа с использованием только Azure RBAC

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

Настройка доступа с использованием только списков управления доступом

Ниже перечислены рекомендации по настройке управления доступом для облачной аналитики.

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

При добавлении или удалении пользователей из группы не требуется вносить обновления в Data Lake служба хранилища. Кроме того, использование групп снижает вероятность превышения 32 записей управления доступом для каждого файла или папки ACL. После четырех записей по умолчанию осталось только 28 записей для назначений разрешений.

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

Настройка доступа с помощью Azure RBAC и списков управления доступом

Разрешения участника данных BLOB-объектов хранилища и читателя данных больших двоичных объектов хранилища предоставляют доступ к данным, а не к учетной записи хранилища. Вы можете предоставить доступ на уровне учетной записи хранения или на уровне контейнера. Если служба хранилища участник данных BLOB-объектов назначен, списки ACL не могут использоваться для управления доступом. Где назначается средство чтения данных BLOB-объектов служба хранилища, вы можете предоставить повышенные разрешения на запись с помощью списков управления доступом. Дополнительные сведения см. в разделе Оценка доступа.

Этот подход подходит для сценариев, в которых большинству пользователей требуется доступ для чтения и лишь некоторым пользователям требуется доступ на запись. Зоны озера данных могут быть разными учетными записями хранилища, а ресурсы данных могут быть разными контейнерами. Зоны озера данных могут быть представлены контейнерами и ресурсы данных — папками.

Подходы к вложенным группам списков управления доступом

Существует два подхода к вложенным группам списков управления доступом.

Вариант 1. Родительская группа выполнения

Прежде чем создавать файлы и папки, начните настройки с родительской группы. Назначьте этой группе разрешения на выполнение как списков управления доступом по умолчанию, так и списков управления доступом на уровне контейнера. Затем добавьте группы, которым требуется доступ к данным в родительской группе.

Предупреждение

Мы рекомендуем использовать этот шаблон, где у вас есть рекурсивные удаления и вместо этого использовать вариант 2: список управления доступом других записей.

Этот метод называется вложенными группами. Группа элементов наследует разрешения родительской группы, которая предоставляет глобальные разрешения на выполнение всем группам элементов. Группе членов не требуются разрешения на выполнение, так как эти разрешения наследуются. Более вложенность может обеспечить большую гибкость и гибкость. Добавьте группы безопасности, представляющие команды или автоматические задания, в группы доступа к данным с правами на чтение и запись.

Вариант 2. Другая запись в списке управления доступом

Рекомендуемый подход — использовать другой набор записей списка управления доступом в контейнере или в корневом каталоге. Укажите значения по умолчанию и доступ и списки управления доступом, как показано на следующем снимке экрана. Такой подход гарантирует, что все части пути от root к низшему уровню имеют разрешения на выполнение.

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

Рекомендуемые зоны безопасности озер данных

Ниже приведены рекомендуемые шаблоны безопасности для каждой зоны озера данных:

• Шаблон RAW должен разрешать доступ к данным только с помощью имен субъекта-службы (SPN).
• Шаблон «Обогащенные» должен разрешать доступ к данным только с помощью имен субъекта-службы (SPN).
• Шаблон «Проверенные» должен разрешать доступ как с использованием с имен субъекта-службы (SPN), так и с использованием имен субъектов-пользователей (UPN).

Пример сценария использования групп безопасности Microsoft Entra

Имеется множество разных способов настройки групп. Например, представьте, что у вас есть каталог с именем /LogData , в котором хранятся данные журнала, созданные сервером. Фабрика данных Azure (ADF) принимает данные в эту папку. Некоторые пользователи из команды инженеров по обслуживанию отправляют журналы и управляют другими пользователями этой папки. Аналитика Azure Databricks и кластеры рабочей области аналитики данных могут анализировать журналы из этой папки.

Чтобы включить эти действия, следует создать группу LogsWriter и группу LogsReader. Назначьте следующие разрешения:

• Добавьте группу LogsWriter в список управления доступом каталога /LogData с разрешениями на rwx.
• Добавьте группу LogsReader в список управления доступом каталога /LogData с разрешениями на r-x.
• Добавьте объект субъекта-службы или управляемое удостоверение службы (MSI) для Фабрики данных Azure в группу LogsWriters.
• Добавьте пользователей из группы инженеров поддержки в группу LogsWriter.
• Azure Databricks настроен для сквозного руководства Microsoft Entra в хранилище Озера данных Azure.

Если пользователь в команде инженеров службы передается другой группе, просто удалите этого пользователя из LogsWriter группы.

Если вы не добавили этого пользователя в группу, но вместо этого добавили выделенную запись ACL для этого пользователя, необходимо удалить эту запись ACL из /LogData каталога. Кроме того, необходимо удалить запись из всех подкаталогов и файлов во всей иерархии каталогов /LogData каталога.

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

Для развертывания рабочей области Azure Synapse требуется учетная запись Azure Data Lake Storage 2-го поколения. Azure Synapse Analytics использует основную учетную запись хранения для нескольких сценариев интеграции и хранит данные в контейнере. Контейнер включает таблицы Apache Spark и журналы приложений в папке с именем /synapse/{workspaceName}. В рабочей области также используется контейнер для управления устанавливающимися библиотеками.

В ходе развертывания рабочей области с помощью портала Azure укажите существующую учетную запись хранения или создайте новую. Указанная учетная запись хранения является основной учетной записью хранения для рабочей области. Процессе развертывания предоставляет удостоверению рабочей области доступ к указанной учетной записи Data Lake Storage 2-го поколения с использованием роли участника данных BLOB-объектов хранилища.

Если вы развертываете рабочую область за пределами портал Azure, добавьте удостоверение рабочей области Azure Synapse Analytics в роль участника данных служба хранилища BLOB-объектов. Рекомендуется назначить роль служба хранилища участнику данных BLOB-объектов на уровне контейнера, чтобы следовать принципу наименьших привилегий.

При выполнении конвейеров, рабочих процессов и записных книжек с помощью заданий они используют контекст разрешения удостоверения рабочей области. Если какое-либо из заданий выполняет чтение или запись в основное хранилище рабочей области, то удостоверение рабочей области использует разрешения на чтение и запись, предоставленные участником данных BLOB-объектов хранилища.

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

Детальное управление доступом к данным в Azure Synapse Analytics с помощью списков управления доступом

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

Рекомендации по использованию таблиц Spark

При использовании таблиц Apache Spark в пуле Spark она создает папку хранилища. Папка находится в корневом каталоге контейнера в основном хранилище рабочей области:

synapse/workspaces/{workspaceName}/warehouse

Если вы планируете создавать таблицы Apache Spark в пуле Azure Synapse Spark, предоставьте разрешение на запись в папку хранилища для группы, в которой выполняется команда, создающая таблицу Spark. Если команда выполняется через активированное задание в конвейере, предоставьте разрешение на запись в MSI рабочей области.

В данном примере создается таблица Spark.

df.write.saveAsTable("table01")

Дополнительные сведения см. в статье Настройка контроля доступа для рабочей области Synapse.

Сводка по доступу к Azure Data Lake

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

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

• Использование Azure Databricks в облачной аналитике в Azure