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

Управление доступом к учетной записи хранения в бессерверном пуле SQL в Azure Synapse Analytics

  • Статья

Бессерверный пул SQL позволяет создавать запросы для чтения файлов непосредственно из службы хранилища Azure. Разрешения на доступ к файлам в службе хранилища Azure контролируются на двух уровнях.

  • Уровень хранилища — пользователь должен иметь разрешение на доступ к базовым файлам хранилища. Администратор хранилища должен разрешить субъекту Microsoft Entra читать и записывать файлы или создавать ключ подписанного URL-адреса (SAS), который будет использоваться для доступа к хранилищу.
  • Уровень службы SQL — пользователь должен иметь разрешение на чтение данных с использованием внешней таблицы или на выполнение функции OPENROWSET. Дополнительные сведения о необходимых разрешениях см. в этом разделе.

В этой статье описываются типы учетных данных, которые можно использовать, и как выполняется поиск учетных данных для пользователей SQL и Microsoft Entra.

Разрешения хранилища

Бессерверный пул SQL в рабочей области Synapse Analytics может считывать содержимое файлов, хранящихся в Azure Data Lake Storage. Вам нужно настроить разрешения для хранилища, чтобы разрешить чтение файлов пользователю, выполняющему SQL-запрос. Доступ к файлам можно включить тремя способами:

  • Управление доступом на основе ролей (RBAC) позволяет назначить роль некоторым пользователю Microsoft Entra в клиенте, где размещено ваше хранилище. Читатель должен быть членом служба хранилища средства чтения данных BLOB-объектов, участника служба хранилища данных BLOB-объектов или служба хранилища роли владельца данных BLOB-объектов в учетной записи хранения. Пользователь, который записывает данные в хранилище Azure, должен быть участником служба хранилища участником данных BLOB-объектов или ролью владельца данных BLOB-объектов служба хранилища. Роль владельца служба хранилища не означает, что пользователь также служба хранилища владельца данных.
  • Списки управления доступом (ACL) позволяют определить разрешения Read(R), Write(W) и Execute(X) для файлов и каталогов, размещенных в службе хранилища Azure. Пользователям Microsoft Entra можно назначить список управления доступом. Чтобы прочитать файл в определенном расположении в службе хранилища Azure, нужно требуются списки управления доступом с разрешением Execute(X) для каждой папки в этом расположении и разрешением Read(R) для нужного файла. См. дополнительные сведения о настройке разрешений ACL в слое хранилища.
  • Подписанный URL-адрес (SAS) разрешает доступ для чтения файлов в Azure Data Lake Storage с использованием маркера с ограниченным сроком действия. Читатель даже не должен проходить проверку подлинности как пользователь Microsoft Entra. Маркер SAS содержит разрешения, предоставленные читателю, а также период действия этого маркера. Маркер SAS является хорошим выбором для ограниченного времени доступа к любому пользователю, который даже не должен находиться в одном клиенте Microsoft Entra. Маркер SAS можно определить для всей учетной записи хранения или для отдельных каталогов. Дополнительные сведения см. в статье Предоставление ограниченного доступа к ресурсам службы хранилища Azure с помощью подписанных URL-адресов.

В качестве альтернативы можно сделать файлы общедоступными, разрешив анонимный доступ. Этот подход НЕ СЛЕДУЕТ использовать при наличии данных, не являющихся общедоступными.

Поддерживаемые типы авторизации в службе хранилища

Пользователь, выполнивший вход в бессерверный пул SQL, должен иметь права на доступ и отправку запросов к файлам в службе хранилища Azure, если эти файлы не являются общедоступными. Вы можете использовать четыре типа авторизации для доступа к недоступном хранилищу: удостоверение пользователя, подписанный URL-адрес, субъект-служба и управляемое удостоверение.

Примечание.

Сквозная передача Microsoft Entra — это поведение по умолчанию при создании рабочей области.

Удостоверение пользователя, также известное как "Сквозная передача Microsoft Entra", — это тип авторизации, в котором удостоверение пользователя Microsoft Entra, вошедшего в бессерверный пул SQL, используется для авторизации доступа к данным. Перед доступом к данным администратору служба хранилища Azure необходимо предоставить разрешения пользователю Microsoft Entra. Как указано в таблице поддерживаемых типов авторизации для пользователей базы данных, он не поддерживается для типа пользователя SQL.

Важно!

Маркер проверки подлинности Microsoft Entra может кэшироваться клиентскими приложениями. Например, Power BI кэширует маркеры Microsoft Entra и повторно использует один и тот же маркер в течение часа. Длительные запросы могут завершиться ошибкой, если срок действия маркера истекает в середине выполнения запроса. Если возникают сбои запросов, вызванные маркером доступа Microsoft Entra, срок действия которого истекает в середине запроса, рассмотрите возможность переключения на субъект-службу, управляемое удостоверение или подписанный URL-адрес.

Вам необходимо быть членом роли служба хранилища владельца данных BLOB-объектов, участника служба хранилища данных BLOB-объектов или служба хранилища роли читателя данных BLOB-объектов, чтобы использовать удостоверение для доступа к данным. В качестве альтернативы можно указать детализированные правила ACL для доступа к файлам и папкам. Даже если вы являетесь владельцем учетной записи хранения, вам придется добавить себя в одну из ролей для данных BLOB-объекта хранилища. Дополнительные сведения см. в статье Access control in Azure Data Lake Storage Gen2 (Контроль доступа в Azure Data Lake Storage 2-го поколения).

Межклиентские сценарии

В случаях, когда служба хранилища Azure находится в другом арендаторе из бессерверного пула SQL, рекомендуется авторизация с помощью субъекта-службы. Также возможна авторизация SAS, а управляемое удостоверение не поддерживается.

Тип авторизации Хранилище, защищенное брандмауэром незащищенное хранилище брандмауэра
SAS Поддерживается Поддерживается
Субъект-служба Не поддерживается Поддерживается

Примечание.

Если служба хранилища Azure защищен брандмауэром служба хранилища Azure, субъект-служба не будет поддерживаться.

Поддерживаемые типы авторизации для пользователей баз данных

В следующей таблице приведены доступные служба хранилища Azure типы авторизации для различных методов входа в конечную точку Azure Synapse Analytics без сервера SQL:

Тип авторизации Пользователь SQL Пользователь Microsoft Entra Субъект-служба
Удостоверение пользователя Не поддерживается Поддерживается Поддерживается
SAS Поддерживается Поддерживается Поддерживается
Субъект-служба Поддерживается Поддерживается Поддерживается
управляемое удостоверение; Поддерживается Поддерживается Поддерживается

Поддерживаемые типы авторизации и хранилища

Можно использовать следующие сочетания типов авторизации и служба хранилища Azure типов:

Тип авторизации Хранилище BLOB-объектов ADLS 1-го поколения ADLS 2-го поколения
SAS Поддерживается Не поддерживается Поддерживается
Субъект-служба Поддерживается Поддерживается Поддерживается
управляемое удостоверение; Поддерживается Поддерживается Поддерживается
Удостоверение пользователя Поддерживается Поддерживается Поддерживается

Межклиентские сценарии

В случаях, когда служба хранилища Azure находится в другом клиенте из бессерверного пула SQL Azure Synapse Analytics, авторизация с помощью субъекта-службы является рекомендуемым методом. Авторизация подписанного URL-адреса также возможна. Управляемое удостоверение службы не поддерживается.

Тип авторизации Хранилище, защищенное брандмауэром незащищенное хранилище брандмауэра
SAS Поддерживается Поддерживается
Субъект-служба Не поддерживается Поддерживается

Примечание.

Если служба хранилища Azure защищен брандмауэром служба хранилища Azure и находится в другом клиенте, субъект-служба не будет поддерживаться. Вместо этого используйте подписанный URL-адрес (SAS).

Хранилище, защищенное брандмауэром

Вы можете настроить учетные записи хранения, чтобы разрешить доступ к определенному бессерверному пулу SQL, создав правило экземпляра ресурса. При доступе к хранилищу, защищенному брандмауэром, используйте удостоверение пользователя или управляемое удостоверение.

Примечание.

Функция брандмауэра в служба хранилища Azure доступна в общедоступной предварительной версии и доступна во всех общедоступных облачных регионах.

В следующей таблице представлены доступные типы авторизации, защищенные брандмауэром, служба хранилища Azure для различных методов входа в конечную точку Azure Synapse Analytics без сервера SQL:

Тип авторизации Пользователь SQL Пользователь Microsoft Entra Субъект-служба
Удостоверение пользователя Не поддерживается Поддерживается Поддерживается
SAS Не поддерживается Не поддерживается Не поддерживается
Субъект-служба Не поддерживается Не поддерживается Не поддерживается
управляемое удостоверение; Поддерживается Поддерживается Поддерживается

Чтобы получить доступ к хранилищу, защищенному брандмауэром с помощью удостоверения пользователя, можно использовать портал Azure или модуль Az.служба хранилища PowerShell.

настройка брандмауэра служба хранилища Azure через портал Azure

  1. Войдите в свою учетную запись хранения на портале Azure.
  2. В главном меню навигации перейдите в раздел "Сеть" в разделе Параметры.
  3. В разделе "Экземпляры ресурсов" добавьте исключение для рабочей области Azure Synapse.
  4. Выберите Microsoft.Synapse/workspaces тип ресурса.
  5. Выберите имя рабочей области в качестве имени экземпляра.
  6. Выберите Сохранить.

служба хранилища Azure конфигурации брандмауэра с помощью PowerShell

Выполните следующие действия, чтобы настроить учетную запись хранения и добавить исключение для рабочей области Azure Synapse.

  1. Откройте PowerShell или установите PowerShell.

  2. Установите последние версии модуля Az.служба хранилища и az.Synapse, например в следующем скрипте:

    Install-Module -Name Az.Storage -RequiredVersion 3.4.0
Install-Module -Name Az.Synapse -RequiredVersion 0.7.0

    Важно!

    Убедитесь, что используется по крайней мере версия 3.4.0. Чтобы проверить версию Az.Storage, выполните следующую команду:

    Get-Module -ListAvailable -Name Az.Storage | Select Version

  3. Подключитесь к своему клиенту Azure:

    Connect-AzAccount

  4. Определите переменные в PowerShell:

    • Имя группы ресурсов — это можно найти в портал Azure в обзоре учетной записи хранения.
    • Имя учетной записи — имя учетной записи хранения, защищенной правилами брандмауэра.
    • Идентификатор клиента — это можно найти в портал Azure в идентификаторе Microsoft Entra в разделе "Свойства" в свойствах клиента.
    • Имя рабочей области — имя рабочей области Azure Synapse.
        $resourceGroupName = "<resource group name>"
    $accountName = "<storage account name>"
    $tenantId = "<tenant id>"
    $workspaceName = "<Azure Synapse workspace name>"

    $workspace = Get-AzSynapseWorkspace -Name $workspaceName
    $resourceId = $workspace.Id
    $index = $resourceId.IndexOf("/resourceGroups/", 0)
    # Replace G with g - /resourceGroups/ to /resourcegroups/
    $resourceId = $resourceId.Substring(0,$index) + "/resourcegroups/" ` 
        + $resourceId.Substring($index + "/resourceGroups/".Length)

    $resourceId

    Важно!

    Значение $resourceid возвращаемого скриптом PowerShell должно соответствовать этому шаблону: /subscriptions/{subscription-id}/resourcegroups/{resource-group}/providers/Microsoft.Synapse/workspaces/{name-of-workspace} Важно писать группы ресурсов в нижнем регистре.

  5. Добавьте сетевое правило учетной записи хранения Azure:

        $parameters = @{
        ResourceGroupName = $resourceGroupName
        Name = $accountName
        TenantId = $tenantId 
        ResourceId = $resourceId
    }

    Add-AzStorageAccountNetworkRule @parameters

  6. Убедитесь, что сетевое правило учетной записи хранения было применено в брандмауэре учетной записи хранения. Следующий скрипт PowerShell сравнивает $resourceid переменную из предыдущих шагов с выходными данными правила сети учетной записи хранения.

        $parameters = @{
        ResourceGroupName = $resourceGroupName
        Name = $accountName
    }

    $rule = Get-AzStorageAccountNetworkRuleSet @parameters
    $rule.ResourceAccessRules | ForEach-Object { 
        if ($_.ResourceId -cmatch "\/subscriptions\/(\w\-*)+\/resourcegroups\/(.)+") { 
            Write-Host "Storage account network rule is successfully configured." -ForegroundColor Green
            $rule.ResourceAccessRules
        } else {
            Write-Host "Storage account network rule is not configured correctly. Remove this rule and follow the steps in detail." -ForegroundColor Red
            $rule.ResourceAccessRules
        }
    }

Учетные данные

Чтобы запросить файл, расположенный в служба хранилища Azure, конечная точка бессерверного пула SQL должна иметь учетные данные, содержащие сведения о проверке подлинности. Используются два типа учетных данных.

  • Учетные данные на уровне сервера используются для нерегламентированных запросов, выполняемых с помощью OPENROWSET функции. Имя учетных данных должно соответствовать URL-адресу хранилища.
  • Учетные данные, область базы данных, используются для внешних таблиц. Внешняя таблица ссылается на DATA SOURCE с учетными данными, которые должны использоваться для доступа к хранилищу.

Предоставление разрешений на управление учетными данными

Чтобы предоставить возможность управления учетными данными, выполните следующие действия.

  • Чтобы разрешить пользователю создавать или удалять учетные данные на уровне сервера, администратор должен предоставить ALTER ANY CREDENTIAL разрешение на вход в базу данных master. Например:

    GRANT ALTER ANY CREDENTIAL TO [login_name];

  • Чтобы разрешить пользователю создавать или удалять учетные данные область базы данных, администратор должен предоставить CONTROL разрешение на базу данных пользователю базы данных в пользовательской базе данных. Например:

    GRANT CONTROL ON DATABASE::[database_name] TO [user_name];

Предоставление разрешений на использование учетных данных

Пользователи базы данных, которые обращаются к внешнему хранилищу, должны иметь разрешение на использование учетных данных. Чтобы использовать учетные данные, пользователь должен иметь REFERENCES разрешение на определенные учетные данные.

Чтобы предоставить REFERENCES разрешение на учетные данные на уровне сервера для входа, используйте следующий запрос T-SQL в базе данных master:

GRANT REFERENCES ON CREDENTIAL::[server-level_credential] TO [login_name];

Чтобы предоставить REFERENCES разрешение на учетные данные базы данных область для пользователя базы данных, используйте следующий запрос T-SQL в пользовательской базе данных:

GRANT REFERENCES ON DATABASE SCOPED CREDENTIAL::[database-scoped_credential] TO [user_name];

Учетные данные на уровне сервера

Учетные данные на уровне сервера используются при вызове OPENROWSET функции входа SQL без DATA_SOURCE чтения файлов в учетной записи хранения.

Имя учетных данных на уровне сервера должно соответствовать базовому URL-адресу хранилища Azure, а также имени контейнера. Для добавления учетных данных выполните инструкцию CREATE CREDENTIAL. Необходимо указать CREDENTIAL NAME аргумент.

Примечание.

Аргумент FOR CRYPTOGRAPHIC PROVIDER не поддерживается.

Имя УЧЕТНЫх данных на уровне сервера должно соответствовать следующему формату: <prefix>://<storage_account_path>[/<container_name>] Описание путей к учетной записи хранения приведено в следующей таблице.

Внешний источник данных Префикс Путь к учетной записи хранения
хранилище BLOB-объектов Azure https <storage_account>.blob.core.windows.net
Хранилище Azure Data Lake Storage 1-го поколения https <storage_account>.azuredatalakestore.net/webhdfs/v1
Azure Data Lake Storage 2-го поколения https <storage_account>.dfs.core.windows.net

Затем учетные данные уровня сервера могут получить доступ к хранилищу Azure с помощью следующих типов проверки подлинности:

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

Пользователи, прошедшие проверку подлинности SQL, не могут использовать проверку подлинности Microsoft Entra для доступа к хранилищу. Они могут получить доступ к хранилищу с помощью учетных данных базы данных с помощью управляемого удостоверения, ключа SAS, субъекта-службы или общедоступного доступа к хранилищу.

Учетные данные уровня базы данных

Учетные данные уровня базы данных используются, когда какой-либо субъект вызывает функцию OPENROWSET с DATA_SOURCE или выбирает данные из внешней таблицы без использования общедоступных файлов. Учетные данные базы данных область не должны соответствовать имени учетной записи хранения, на нее ссылается источник ДАННЫХ, определяющий расположение хранилища.

Такие учетные данные позволяют получить доступ к службе хранилища Azure через следующие типы проверки подлинности:

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

CREATE EXTERNAL DATA SOURCE mysample
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>'
)

Пользователи, прошедшие проверку подлинности SQL, не могут использовать проверку подлинности Microsoft Entra для доступа к хранилищу. Они могут получить доступ к хранилищу с помощью учетных данных базы данных с помощью управляемого удостоверения, ключа SAS, субъекта-службы или общедоступного доступа к хранилищу.

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

CREATE EXTERNAL DATA SOURCE mysample
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>',
          CREDENTIAL = <name of database scoped credential> 
)

Примеры

Обращение к общедоступному источнику данных

Используйте следующий скрипт, чтобы создать таблицу, которая обращается к общедоступному источнику данных.

CREATE EXTERNAL FILE FORMAT [SynapseParquetFormat]
       WITH ( FORMAT_TYPE = PARQUET)
GO
CREATE EXTERNAL DATA SOURCE publicData
WITH ( LOCATION = 'https://<storage_account>.dfs.core.windows.net/<public_container>/<path>' )
GO

CREATE EXTERNAL TABLE dbo.userPublicData ( [id] int, [first_name] varchar(8000), [last_name] varchar(8000) )
WITH ( LOCATION = 'parquet/user-data/*.parquet',
       DATA_SOURCE = [publicData],
       FILE_FORMAT = [SynapseParquetFormat] )

Пользователь базы данных может считывать содержимое файлов из такого источника данных, используя внешнюю таблицу или функцию OPENROWSET, которая ссылается на источник данных:

SELECT TOP 10 * FROM dbo.userPublicData;
GO
SELECT TOP 10 * FROM OPENROWSET(BULK 'parquet/user-data/*.parquet',
                                DATA_SOURCE = 'mysample',
                                FORMAT='PARQUET') as rows;
GO

Доступ к источнику данных с помощью учетных данных

Измените следующий сценарий, чтобы создать внешнюю таблицу, которая обращается к хранилищу Azure с помощью маркера SAS, удостоверения Microsoft Entra пользователя или управляемого удостоверения рабочей области.

-- Create master key in databases with some password (one-off per database)
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong password>'
GO

-- Create databases scoped credential that use Managed Identity, SAS token or service principal. User needs to create only database-scoped credentials that should be used to access data source:

CREATE DATABASE SCOPED CREDENTIAL WorkspaceIdentity
WITH IDENTITY = 'Managed Identity'
GO
CREATE DATABASE SCOPED CREDENTIAL SasCredential
WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = 'sv=2019-10-1********ZVsTOL0ltEGhf54N8KhDCRfLRI%3D'
GO
CREATE DATABASE SCOPED CREDENTIAL SPNCredential WITH
IDENTITY = '**44e*****8f6-ag44-1890-34u4-22r23r771098@https://login.microsoftonline.com/**do99dd-87f3-33da-33gf-3d3rh133ee33/oauth2/token' 
, SECRET = '.7OaaU_454azar9WWzLL.Ea9ePPZWzQee~'
GO
-- Create data source that one of the credentials above, external file format, and external tables that reference this data source and file format:

CREATE EXTERNAL FILE FORMAT [SynapseParquetFormat] WITH ( FORMAT_TYPE = PARQUET)
GO

CREATE EXTERNAL DATA SOURCE mysample
WITH ( LOCATION = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>'
-- Uncomment one of these options depending on authentication method that you want to use to access data source:
--,CREDENTIAL = WorkspaceIdentity 
--,CREDENTIAL = SasCredential 
--,CREDENTIAL = SPNCredential
)

CREATE EXTERNAL TABLE dbo.userData ( [id] int, [first_name] varchar(8000), [last_name] varchar(8000) )
WITH ( LOCATION = 'parquet/user-data/*.parquet',
       DATA_SOURCE = [mysample],
       FILE_FORMAT = [SynapseParquetFormat] );

Пользователь базы данных может считывать содержимое файлов из такого источника данных, используя внешнюю таблицу или функцию OPENROWSET, которая ссылается на источник данных:

SELECT TOP 10 * FROM dbo.userdata;
GO
SELECT TOP 10 * FROM OPENROWSET(BULK 'parquet/user-data/*.parquet', DATA_SOURCE = 'mysample', FORMAT='PARQUET') as rows;
GO

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

В этих статьях вы узнаете, как запрашивать различные типы папок, типы файлов и создавать и использовать представления: