Управление разрешениями пользователей в бессерверных пулах SQL в Azure Synapse
Для защиты данных служба хранилища Azure реализует модель управления доступом, которая поддерживает управление доступом на основе ролей Azure (Azure RBAC) и списки управления доступом (ACL), такие как переносимый интерфейс операционной системы для Unix (POSIX)
Субъект безопасности можно связать с уровнем доступа для файлов и каталогов. Эти связи фиксируются в списке управления доступом (ACL). Список управления доступом есть у каждого файла и каталога в учетной записи хранения. Когда субъект безопасности пытается выполнить операцию в файле или каталоге, проверка ACL определяет, имеет ли этот субъект безопасности (пользователь, группа, субъект-служба или управляемое удостоверение) правильный уровень разрешений для выполнения операции.
Существует два типа списков управления доступом.
Списки ACL для доступа.
Они управляют доступом к объекту. Они позволяют управлять доступом как к файлам, так и к каталогам.
Списки ACL по умолчанию.
Это шаблоны связанных с каталогом списков ACL, которые определяет списки ACL доступа для дочерних элементов, созданных в этом каталоге. У файлов нет списков ACL по умолчанию.
Как ACL для доступа, так и ACL по умолчанию имеют одинаковую структуру.
К объекту-контейнеру применяются такие разрешения, как "Чтение", "Запись" и "Выполнение", и их можно использовать для файлов и каталогов, как показано в следующей таблице.
Уровни разрешений
Разрешение | Файлы | Directory |
---|---|---|
Разрешение на чтение (R) | Чтение содержимого файла | Для просмотра содержимого каталога требуются разрешения на чтение и выполнение |
Разрешение на запись (W) | Запись или добавление данных в файл | Для создания дочерних элементов в каталоге требуются разрешения на запись и выполнение |
Разрешение на выполнение (X) | Не имеет значения в контексте Data Lake Storage 2-го поколения | Требуется для просмотра дочерних элементов каталога |
Рекомендации по настройке списков ACL
Всегда используйте группы безопасности Microsoft Entra в качестве назначенного участника в записи ACL. Не назначайте напрямую отдельных пользователей или субъекты-службы. Использование этой структуры позволяет добавлять и удалять пользователей или субъекты-службы без необходимости повторно применять списки ACL ко всей структуре каталогов. Вместо этого можно просто добавить или удалить пользователей и субъектов-служб из соответствующей группы безопасности Microsoft Entra.
Доступно множество способов настройки групп. Предположим, что у вас есть каталог с именем /LogData, содержащий данные журнала, создаваемые сервером. Фабрика данных Azure (ADF) принимает данные в эту папку. Конкретные пользователи из группы инженеров поддержки будут отправлять журналы и управлять другими пользователями этой папки, а различные кластеры Databricks будут анализировать журналы из этой папки.
Чтобы включить эти действия, следует создать группу LogsWriter и группу LogsReader. Затем можно назначить разрешения следующим образом.
- Добавьте группу LogsWriter в список ACL каталога /LogData с разрешениями на чтение, запись и выполнение.
- Добавьте группу LogsReader в список ACL каталога /LogData с разрешениями на чтение и выполнение.
- Добавьте объект субъекта-службы или управляемое удостоверение службы (MSI) для ADF в группу LogsWriter.
- Добавьте пользователей из группы инженеров поддержки в группу LogsWriter.
- Добавьте объект субъекта-службы или MSI для Databricks в группу LogsReader.
Если пользователь из группы инженеров поддержки уходит из компании, можно просто удалить его из группы LogsWriter. Если вы не добавили этого пользователя в группу, а добавили для него выделенную запись списка ACL, эту запись потребуется удалить из каталога /LogData. Кроме того, необходимо удалить запись из всех подкаталогов и файлов во всей иерархии каталога /LogData.
Роли, необходимые для пользователей бессерверного пула SQL
Пользователям, которым необходим доступ только для чтения, следует назначить роль Читатель данных BLOB-объектов хранилища.
Пользователям, которым необходим доступ для чтения и записи, следует назначить роль Участник для данных BLOB-объектов хранилища. Доступ на чтение и запись необходим, если пользователь должен иметь доступ для использования инструкции CREATE EXTERNAL TABLE AS SELECT (CETAS).
Примечание.
Если у пользователя есть роль владельца или участника, ее недостаточно. В Azure Data Lake Storage 2-го есть роли суперпользователей, которые следует назначить в этом случае.
Разрешение на уровне базы данных
Чтобы предоставить пользователю более детализированный доступ, необходимо использовать синтаксис Transact-SQL для создания имен входа и пользователей.
Чтобы предоставить пользователю доступ к отдельной базе данных бессерверного пула SQL, выполните действия, описанные в следующем примере:
Создайте имя для входа:
use master CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER;
Создайте пользователя:
use yourdb -- Use your DB name CREATE USER alias FROM LOGIN [alias@domain.com];
Добавьте пользователя к членам указанной роли:
use yourdb -- Use your DB name alter role db_datareader Add member alias -- Type USER name from step 2 -- You can use any Database Role which exists -- (examples: db_owner, db_datareader, db_datawriter) -- Replace alias with alias of the user you would like to give access and domain with the company domain you are using.
Разрешение уровня сервера
Чтобы предоставить пользователю полный доступ ко всем базам данных бессерверного пула SQL, выполните действия, описанные в следующем примере:
CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER; ALTER SERVER ROLE sysadmin ADD MEMBER [alias@domain.com];