Contrôler l’accès au compte de stockage pour le pool SQL serverless dans Azure Synapse Analytics

  • Article

Une requête de pool SQL serverless lit les fichiers directement dans Stockage Azure. Les autorisations d’accès aux fichiers sur le stockage Azure sont contrôlées à deux niveaux :

  • Niveau de stockage : l’utilisateur doit avoir l’autorisation d’accéder aux fichiers de stockage sous-jacents. Votre administrateur de stockage doit autoriser le principal Microsoft Entra à lire/écrire des fichiers, ou générer une clé de signature d’accès partagé (SAS) qui sera utilisée pour accéder au stockage.
  • Niveau de service SQL - L’utilisateur doit se voir attribuer l’autorisation de lire les données en utilisant une table externe ou d’exécuter la fonction OPENROWSET. Explorez plus en détail les autorisations requises dans cette section.

Cet article décrit les types d’informations d’identification que vous pouvez utiliser et la façon dont la recherche des informations d’identification est appliquée pour les utilisateurs SQL et Microsoft Entra.

Autorisations de stockage

Un pool SQL serverless dans l’espace de travail Synapse Analytics peut lire le contenu des fichiers stockés dans Azure Data Lake Storage. Vous devez configurer des autorisations sur le stockage pour permettre à un utilisateur qui exécute une requête SQL de lire les fichiers. Il existe trois méthodes pour activer l’accès aux fichiers :

  • Le contrôle d’accès en fonction du rôle (RBAC) vous permet d’attribuer un rôle à un utilisateur Microsoft Entra dans le locataire où votre stockage est placé. Un lecteur doit être membre du rôle Lecteur de données Blob du stockage, Contributeur aux données Blob du stockage ou Propriétaire des données Blob du stockage sur le compte de stockage. Un utilisateur qui écrit des données dans le stockage Azure doit être membre du rôle Contributeur aux données Blob du stockage ou Propriétaire des données Blob du stockage. Le rôle Propriétaire de stockage n’implique pas qu’un utilisateur soit également un Propriétaire de données de stockage.
  • Les listes de contrôle d’accès (ACL, Access Control Lists) vous permettent de définir des autorisations Lecture (R), Écriture (W) et Exécution (X) affinées sur les fichiers et les répertoires du stockage Azure. La liste de contrôle d’accès peut être affectée aux utilisateurs de Microsoft Entra. Si les lecteurs veulent lire un fichier sur un chemin dans le Stockage Azure, ils doivent avoir l’autorisation Exécuter (X) la liste de contrôle d’accès (ACL) sur chaque dossier présent dans le chemin du fichier, et Lire (R) la liste ACL sur le fichier. Découvrez-en plus sur la définition d’autorisations de liste de contrôle d’accès (ACL) dans la couche de stockage.
  • La signature d’accès partagé (SAS) permet à un lecteur d’accéder aux fichiers sur le stockage Azure Data Lake à l’aide du jeton à durée limitée. Le lecteur n’a même pas besoin d’être authentifié en tant qu’utilisateur Microsoft Entra. Le jeton SAS contient les autorisations accordées au lecteur, ainsi que la durée pendant laquelle le jeton est valide. Le jeton SAS représente un bon choix pour un accès à durée restreinte d’un utilisateur qui n’est même pas obligé de se trouver dans le même locataire Microsoft Entra. Le jeton SAS peut être défini sur le compte de stockage ou sur des annuaires spécifiques. Apprenez-en davantage sur l’octroi d’un accès limité aux ressources du Stockage Azure à l’aide des signatures d’accès partagé.

Vous pouvez également rendre vos fichiers disponibles publiquement en autorisant l’accès anonyme. Cette approche NE doit PAS être utilisée si vous avez des données non publiques.

Types d’autorisations de stockage pris en charge

Un utilisateur qui s’est connecté à un pool SQL serverless doit être autorisé à accéder aux fichiers présents dans Stockage Azure et à les interroger si les fichiers ne sont pas publiquement disponibles. Vous pouvez utiliser quatre types d’autorisation pour accéder au stockage non public : Identité de l’utilisateur, Signature d’accès partagé, Principal de service et Identité managée.

Remarque

L’authentification directe Microsoft Entra est le comportement qui est utilisé par défaut quand vous créez un espace de travail.

L’identité de l’utilisateur (également appelée « authentification directe Microsoft Entra ») est un type d’autorisation où l’identité de l’utilisateur Microsoft Entra qui s’est connecté au pool SQL serverless est utilisée pour autoriser l’accès aux données. Avant d’accéder aux données, l’administrateur du stockage Azure doit accorder des autorisations à l’utilisateur Microsoft Entra. Comme indiqué dans la table Types d’autorisation pris en charge pour les utilisateurs de base de données, il n’est pas pris en charge pour le type d’utilisateur SQL.

Important

Un jeton d’authentification Microsoft Entra peut être mis en cache par les applications clientes. Par exemple, Power BI met en cache les jetons Microsoft Entra et réutilise le même jeton pendant une heure. Les requêtes à long terme peuvent échouer si le jeton expire pendant leur exécution. Si des requêtes échouent parce que le jeton d’accès Microsoft Entra expire au milieu de celles-ci, envisagez de passer à un principal de service, à l’identité managée ou à la signature d’accès partagé.

Vous devez être membre du rôle Propriétaire des données Blob de stockage, Contributeur aux données Blob de stockage ou Lecteur de données Blob de stockage pour utiliser votre identité pour accéder aux données. Vous pouvez également spécifier des règles ACL affinées pour accéder aux fichiers et aux dossiers. Même si vous êtes propriétaire d’un compte de stockage, vous devez vous ajouter à l’un des rôles de données blob de stockage. Pour plus d’informations sur le contrôle d’accès dans Azure Data Lake Store Gen2, consultez l’article Contrôle d’accès dans Azure Data Lake Storage Gen2.

Scénarios inter-locataires

Si le stockage Azure se trouve dans un locataire différent du pool SQL serverless Synapse, l’autorisation par le biais du principal de service est la méthode recommandée. L’autorisation SAS est également possible, mais l’identité managée n’est pas prise en charge.

Type d’autorisation Stockage protégé par un pare-feu Stockage non protégé par un pare-feu
SAS Prise en charge Prise en charge
Principal du service Non pris en charge Pris en charge

Notes

Si Stockage Azure est protégé avec un pare-feu Stockage Azure, Principal de service ne sera pas pris en charge.

Types d’autorisation pris en charge pour les utilisateurs de bases de données

Le tableau suivant fournit les types d’autorisation Stockage Azure disponibles pour différentes méthodes de connexion dans un point de terminaison SQL serverless Azure Synapse Analytics :

Type d’autorisation Utilisateur SQL Utilisateur Microsoft Entra Principal du service
Identité de l’utilisateur Non pris en charge Prise en charge Prise en charge
SAS Prise en charge Prise en charge Prise en charge
Principal du service Pris en charge Prise en charge Prise en charge
Identité gérée Prise en charge Prise en charge Prise en charge

Types d’autorisations et de stockage pris en charge

Vous pouvez utiliser les combinaisons de types d’autorisations et de stockage Azure ci-dessous :

Type d’autorisation Stockage Blob ADLS Gen1 ADLS Gen2
SAS Prise en charge Non prise en charge Prise en charge
Principal du service Pris en charge Prise en charge Prise en charge
Identité gérée Prise en charge Prise en charge Prise en charge
Identité de l’utilisateur Pris en charge Prise en charge Pris en charge

Scénarios inter-locataires

Si le stockage Azure se trouve dans un locataire différent du pool SQL serverless Azure Synapse Analytics, l’autorisation par le biais du principal de service est la méthode recommandée. L’autorisation par signature d’accès partagé est également possible. Identité de service managée n’est pas prise en charge.

Type d’autorisation Stockage protégé par un pare-feu Stockage non protégé par un pare-feu
SAS Prise en charge Prise en charge
Principal du service Non pris en charge Pris en charge

Notes

Si Stockage Azure est protégé avec un pare-feu Stockage Azure et se trouve dans un autre locataire, Principal de service ne sera pas pris en charge. À la place, utilisez une signature d'accès partagé (SAS).

Stockage protégé par un pare-feu

Vous pouvez configurer des comptes de stockage pour autoriser l’accès à un pool SQL serverless spécifique en créant une règle d’instance de ressource. Lors de l’accès à un stockage protégé par le pare-feu, utilisez Identité utilisateur ou Identité managée.

Remarque

La fonctionnalité de pare-feu de Stockage Azure est en préversion publique et est disponible dans toutes les régions cloud publiques.

Le tableau suivant fournit les types d’autorisation Stockage Azure protégés par le pare-feu disponibles pour différentes méthodes de connexion à un point de terminaison SQL serverless Azure Synapse Analytics :

Type d’autorisation Utilisateur SQL Utilisateur Microsoft Entra Principal du service
Identité de l’utilisateur Non pris en charge Prise en charge Prise en charge
SAS Non pris en charge Non pris en charge Non pris en charge
Principal du service Non pris en charge Non pris en charge Non pris en charge
Identité gérée Prise en charge Prise en charge Prise en charge

Pour accéder au stockage protégé par le pare-feu via une identité utilisateur, vous pouvez vous servir du portail Azure ou du module PowerShell Az.Storage.

Configuration du pare-feu Stockage Azure via le portail Azure

  1. Recherchez votre compte de stockage sur le portail Azure.
  2. Dans le menu de navigation principal, accédez à Mise en réseau sous Paramètres.
  3. Dans la section Instances de ressources, ajoutez une exception pour votre espace de travail Azure Synapse.
  4. Sélectionnez Microsoft.Synapse/workspaces comme Type de ressource.
  5. Sélectionnez le nom de votre espace de travail sous forme de nom d'instance.
  6. Sélectionnez Enregistrer.

Configuration du pare-feu Stockage Azure via PowerShell

Suivez ces étapes pour configurer votre compte de stockage et ajouter une exception pour l’espace de travail Azure Synapse.

  1. Ouvrez PowerShell ou installez PowerShell.

  2. Installez les dernières versions du module Az.Storage et du module Az.Synapse, par exemple dans le script suivant :

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

    Important

    Veillez à utiliser au moins la version 3.4.0. Vous pouvez vérifier votre version Az.Storage en exécutant cette commande :

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

  3. Connectez-vous à votre locataire Azure :

    Connect-AzAccount

  4. Définissez les variables dans PowerShell :

    • Nom du groupe de ressources : vous pouvez le trouver dans le portail Azure dans la Vue d’ensemble du compte de stockage.
    • Nom du compte : nom du compte de stockage protégé par les règles de pare-feu.
    • ID de locataire : vous pouvez le trouver dans le portail Azure dans Microsoft Entra ID, sous Propriétés, dans Propriétés du locataire.
    • Nom de l’espace de travail : nom de l’espace de travail 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

    Important

    La valeur du $resourceid retourné par le script PowerShell doit correspondre à ce modèle : /subscriptions/{subscription-id}/resourcegroups/{resource-group}/providers/Microsoft.Synapse/workspaces/{name-of-workspace} Il est important d’écrire resourcegroups en minuscules.

  5. Ajoutez une règle de réseau de compte de stockage Azure :

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

    Add-AzStorageAccountNetworkRule @parameters

  6. Vérifiez que la règle de réseau de compte de stockage a été appliquée dans le pare-feu de votre compte de stockage. Le script PowerShell suivant compare la variable $resourceid des étapes précédentes à la sortie de la règle de réseau du compte de stockage.

        $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
        }
    }

Informations d'identification

Pour interroger un fichier situé dans Stockage Azure, votre point de terminaison de pool SQL serverless a besoin d’informations d’identification qui contiennent les informations d’authentification. Deux types d’informations d’identification sont utilisés :

  • Les informations d’identification au niveau du serveur sont utilisées pour des requêtes ad hoc exécutées à l’aide de la fonction OPENROWSET. Le nom des informations d’identification doit correspondre à l’URL de stockage.
  • Les informations d’identification délimitées à la base de données sont utilisées pour des tables externes. Une table externe fait référence au paramètre DATA SOURCE avec les informations d’identification à utiliser pour accéder au stockage.

Accorder des autorisations pour gérer les informations d’identification

Pour accorder la possibilité de gérer les informations d’identification :

  • Pour permettre à un utilisateur de créer ou de supprimer des informations d’identification au niveau du serveur, un administrateur doit accorder l’autorisation ALTER ANY CREDENTIAL à son identification dans la base de données MASTER. Par exemple :

    GRANT ALTER ANY CREDENTIAL TO [login_name];

  • Pour permettre à un utilisateur de créer ou de supprimer des informations d’identification délimitées à la base de données, l’administrateur peut accorder l’autorisation CONTROL sur la base de données à l’utilisateur de la base de données dans la base de données utilisateur. Par exemple :

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

Accorder des autorisations pour l’utilisation d’informations d’identification

Les utilisateurs de base de données qui accèdent à un stockage externe doivent avoir l’autorisation d’utiliser des informations d’identification. Pour utiliser des informations d’identification, un utilisateur doit disposer de l’autorisation REFERENCES sur des informations d’identification spécifiques.

Pour accorder l’autorisation REFERENCES sur les informations d’identification au niveau du serveur pour une connexion, utilisez la requête T-SQL suivante dans la base de données MASTER :

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

Pour accorder une autorisation REFERENCES sur des informations d’identification délimitées à la base de données pour un utilisateur de la base de données, utilisez la requête T-SQL suivante dans la base de données utilisateur :

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

Informations d’identification au niveau serveur

Les informations d’identification au niveau serveur sont utilisées lorsque la connexion SQL appelle la fonction OPENROWSET sans le paramètre DATA_SOURCE pour lire des fichiers sur un compte de stockage.

Le nom des informations d’identification au niveau serveur doit correspondre à l’URL de base du stockage Azure, éventuellement suivi par un nom de conteneur. Les informations d’identification sont ajoutées par l’exécution de CREATE CREDENTIAL. Vous devez utiliser l'argument CREDENTIAL NAME.

Notes

L’argument FOR CRYPTOGRAPHIC PROVIDER n’est pas pris en charge.

Le nom des informations d’identification au niveau serveur doivent correspondre au format suivant : <prefix>://<storage_account_path>[/<container_name>]. Les chemins d’accès de compte de stockage sont décrits dans le tableau suivant :

Source de données externe Préfixe Chemin de compte de stockage
Stockage Blob Azure https <storage_account>.blob.core.windows.net
Azure Data Lake Storage Gen1 https <storage_account>.azuredatalakestore.net/webhdfs/v1
Azure Data Lake Storage Gen2 https <storage_account>.dfs.core.windows.net

Les informations d’identification au niveau serveur permettent d’accéder au stockage Azure à l’aide des types d’authentification suivants :

Les utilisateurs Microsoft Entra peuvent accéder à n’importe quel fichier sur le stockage Azure s’ils sont membres du rôle Propriétaire des données Blob de stockage, Contributeur aux données Blob du stockage ou Lecteur des données Blob de stockage. Les utilisateurs Microsoft Entra n’ont pas besoin d’informations d’identification pour accéder au stockage.

Les utilisateurs authentifiés SQL ne peuvent pas utiliser l’authentification Microsoft Entra pour accéder au stockage. Ils peuvent accéder au stockage via des informations d’identification de base de données à l’aide de l’identité managée, de la clé SAS, du principal de service ou s’il existe un accès public au stockage.

Informations d’identification incluses dans l’étendue de la base de données

Les informations d’identification incluses dans l’étendue de la base de données sont utilisées quand un principal appelle la fonction OPENROWSET avec le paramètre DATA_SOURCE ou sélectionne des données d’une table externe qui n’accèdent pas aux fichiers publics. Les informations d’identification délimitées à la base de données ne doivent pas nécessairement correspondre au nom du compte de stockage, car elles sont référencées dans la SOURCE DE DONNÉES qui définit l’emplacement de stockage.

Les informations d’identification informations d’identification incluses dans l’étendue de la base de données permettent d’accéder au stockage Azure à l’aide des types d’authentification suivants :

Les utilisateurs Microsoft Entra peuvent accéder à n’importe quel fichier sur le stockage Azure s’ils sont membres des rôles Propriétaire des données Blob de stockage, Contributeur aux données Blob du stockage ou Lecteur des données Blob de stockage. Les utilisateurs Microsoft Entra n’ont pas besoin d’informations d’identification pour accéder au stockage.

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

Les utilisateurs authentifiés SQL ne peuvent pas utiliser l’authentification Microsoft Entra pour accéder au stockage. Ils peuvent accéder au stockage via des informations d’identification de base de données à l’aide de l’identité managée, de la clé SAS, du principal de service ou s’il existe un accès public au stockage.

Les informations d’identification incluses dans l’étendue de la base de données sont utilisées dans des sources de données externes pour spécifier la méthode d’authentification qui sera utilisée pour accéder à ce stockage :

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

Exemples

Accéder à une source de données disponible publiquement

Utilisez le script suivant pour créer une table qui accède à la source de données publiquement disponible.

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

L’utilisateur de base de données peut lire le contenu des fichiers à partir de la source de données à l’aide d’une table externe ou de la fonction OPENROWSET qui fait référence à la source de données :

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

Accéder à une source de données en utilisant des informations d’identification

Modifiez le script suivant pour créer une table externe qui accède au stockage Azure à l’aide d’un jeton SAP, d’une identité d’utilisateur Microsoft Entra ou d’une identité managée d’espace de travail.

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

L’utilisateur de base de données peut lire le contenu des fichiers à partir de la source de données à l’aide d’une table externe ou de la fonction OPENROWSET qui fait référence à la source de données :

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

Étapes suivantes

Ces articles vous expliquent comment interroger les différents types de dossiers et de fichiers, et comment créer et utiliser des vues :