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

Tip

Microsoft Fabric Data Warehouse — это реляционное хранилище корпоративного масштаба на основе озера данных, с архитектурой, готовой к будущему, встроенной ИИ и новыми функциями. Если вы не знакомы с хранилищем данных, начните с Fabric Data Warehouse. Существующие рабочие нагрузки выделенного пула SQL могут обновляться до Fabric для доступа к новым возможностям в области науки о данных, аналитики в реальном времени и отчетности.

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

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

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

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

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

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

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

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

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

Примечание

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

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

Важно

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

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

Сценарии между арендаторами

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

Тип авторизации Защищенное хранилище брандмауэра хранилище, не защищенное брандмауэром
SAS Поддерживается Поддерживается
Принципал службы Не поддерживается Поддерживается

Примечание

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

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

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

Тип авторизации Пользователь SQL пользователь Microsoft Entra Управляющий службой
Удостоверение пользователя Не поддерживается Поддерживается Поддерживается
SAS Поддерживается Поддерживается Поддерживается
Управляющий службой Поддерживается Поддерживается Поддерживается
Управляемая идентичность Поддерживается Поддерживается Поддерживается

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

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

Тип авторизации Хранилище блобов ADLS Gen1 ADLS Gen2
SAS Поддерживается Не поддерживаются Поддерживается
Управляющий службой Поддерживается Поддерживается Поддерживается
Управляемая идентичность Поддерживается Поддерживается Поддерживается
Удостоверение пользователя Поддерживается Поддерживается Поддерживается

Сценарии между арендаторами

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

Тип авторизации Защищенное хранилище брандмауэра хранилище без защиты брандмауэром
SAS Поддерживается Поддерживается
Управляющий службой Не поддерживается Поддерживается

Примечание

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

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

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

Примечание

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

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

Тип авторизации Пользователь SQL пользователь Microsoft Entra Управляющий службой
Удостоверение пользователя Не поддерживается Поддерживается Поддерживается
SAS Не поддерживается Не поддерживается Не поддерживается
Управляющий службой Не поддерживается Не поддерживается Не поддерживается
Управляемая идентичность Поддерживается Поддерживается Поддерживается

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

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

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

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

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

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

  2. Установите последние версии модуля Az.Storage и модуля 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 в разделе Overview вашей учетной записи хранения.
    • Имя учетной записи — имя учетной записи хранения, защищенной правилами брандмауэра.
    • Идентификатор клиента— это можно найти на портале Azure на портале Microsoft Entra ID в разделе Properties в свойствах Tenant.
    • Имя рабочей области — имя рабочей области 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} Важно писать resourcegroups в нижнем регистре.

  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];

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

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

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

Примечание

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

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

Внешний источник данных Prefix Путь к учетной записи хранения
Хранилище 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 или выбирает данные из внешней таблицы, которые не обращаются к общедоступным файлам. Учетные данные с областью действия базы данных не должны соответствовать имени учетной записи хранения, на которые ссылается ИСТОЧНИК ДАННЫХ, определяющий расположение хранилища.

Учетные данные, относящиеся к области базы данных, позволяют получить доступ к хранилищу 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

Связанный контент

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

  • Last updated on