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

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.

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.

Une signature d’accès partagé (SAS) fournit un accès délégué aux ressources du compte de stockage. Avec une signature d’accès partagé, un utilisateur peut accorder aux clients l’accès aux ressources d’un compte de stockage sans partager les clés du compte. Une signature d’accès partagé vous fournit un contrôle précis sur le type d’accès que vous accordez aux clients qui disposent de la signature SAS, comme l’intervalle de validité, les autorisations accordées, la plage d’adresses IP acceptée ou le protocole accepté (https/http).

Vous pouvez obtenir un jeton SAS en accédant au Portail Azure -> Compte de stockage -> Signature d’accès partagé -> Configurer les autorisations -> Générer la chaîne de connexion et la clé SAS.

Pour autoriser l’accès à l’aide du jeton SAP, vous devez créer des informations d’identification incluses dans l’étendue de la base de données ou du serveur

Un principal de service est la représentation locale d’un objet d’application global dans un locataire Microsoft Entra particulier. Cette méthode d’authentification est appropriée quand l’accès au stockage doit être autorisé pour une application utilisateur, un service ou un outil d’automatisation. Pour plus d’informations sur les principaux de service dans Microsoft Entra ID, consultez Objets application et principal du service dans Microsoft Entra ID.

L’application doit être inscrite auprès de Microsoft Entra ID. Pour plus d’informations sur le processus d’inscription, consultez Démarrage rapide : Inscrire une application avec la plateforme d’identités Microsoft. Une fois l’application inscrite, son principal de service peut être utilisé pour l’autorisation.

Le principal de service doit être affecté aux rôles Propriétaire des données Blob de stockage, Contributeur aux données Blob du stockage et Lecteur de données Blob de stockage pour que l’application puisse accéder aux données. Même si le principal de service est propriétaire d’un compte de stockage, il doit toujours disposer d’un rôle approprié sur les données Blob du stockage. Une autre façon d’accorder l’accès aux fichiers et aux dossiers de stockage consiste à définir des règles ACL affinées pour le principal de service.

Pour plus d’informations sur le contrôle d’accès dans Azure Data Lake Store Gen2, consultez Contrôle d’accès dans Azure Data Lake Storage Gen2.

L’identité de service managée ou l’identité managée est également appelée MSI. Une MSI est une fonctionnalité de Microsoft Entra ID qui fournit des services Azure à un service Azure, dans ce cas, pour votre pool SQL serverless. La MSI est créée automatiquement dans Microsoft Entra ID. Cette identité peut être utilisée pour autoriser les demandes d’accès aux données dans le stockage Azure.

Avant d’accéder aux données, l’administrateur Stockage Azure doit accorder des autorisations à l’identité de service managée pour accéder aux données. L’octroi d’autorisations à une MSI s’effectue de la même façon que l’octroi d’une autorisation à un autre utilisateur Microsoft Entra.

Vous pouvez accéder aux fichiers publiquement disponibles placés sur des comptes de stockage Azure qui autorisent l’accès anonyme.

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

Les signatures d’accès partagé ne peuvent pas être utilisées pour accéder au stockage protégé par un pare-feu.

Le principal de service ne peut pas être utilisé pour accéder au stockage protégé par un pare-feu. Utilisez une identité de service managée à la place.

Vous devez activer l’option Autoriser les services Microsoft approuvés et attribuer un rôle Azure à l’identité managée attribuée par le système pour cette instance de ressource.

Dans ce cas, l’étendue de l’accès pour l’instance de ressource correspond au rôle Azure affecté à l’identité managée.

Vous ne pouvez pas accéder au stockage protégé par un pare-feu à l’aide d’un accès anonyme.

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.

Le script suivant crée des informations d’identification au niveau du serveur que la fonction OPENROWSET peut utiliser pour accéder à n’importe quel fichier sur un stockage Azure à l’aide d’un jeton SAS. Créez ces informations d’identification pour permettre à un principal SQL d’utiliser la fonction OPENROWSET pour lire des fichiers protégés par une clé SAS sur le stockage Azure. Le nom des informations d’identification doit correspondre à l’URL.

Dans l’exemple de requête suivant, remplacez <mystorageaccountname> par le nom réel de votre compte de stockage et <mystorageaccountcontainername> par le nom réel du conteneur :

CREATE CREDENTIAL [https://<mystorageaccountname>.dfs.core.windows.net/<mystorageaccountcontainername>]
WITH IDENTITY='SHARED ACCESS SIGNATURE'
, SECRET = 'sv=2018-03-28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-04-18T20:42:12Z&st=2019-04-18T12:42:12Z&spr=https&sig=lQHczNvrk1BrIPBNJ3VYEIq78%3D';
GO

Si vous le souhaitez, vous pouvez utiliser uniquement l’URL de base du compte de stockage, sans nom de conteneur.

Le script suivant crée des informations d’identification au niveau du serveur qui permettent d’accéder aux fichiers dans un stockage en utilisant le principal de service pour l’authentification et l’autorisation. Vous pouvez obtenir l’AppID en visitant Inscriptions d’applications dans le portail Azure et en sélectionnant l’application qui demande l’accès au stockage. Le Secret est obtenu durant l’inscription de l’application. AuthorityUrl est l’URL de l’autorité OAUTH 2.0 Microsoft Entra ID.

CREATE CREDENTIAL [https://<storage_account>.dfs.core.windows.net/<container>]
WITH IDENTITY = '<AppID>@<AuthorityUrl>' 
, SECRET = '<Secret>'

Le script suivant crée des informations d’identification au niveau du serveur que la fonction OPENROWSET peut utiliser pour accéder à n’importe quel fichier sur un stockage Azure à l’aide d’une identité managée de l’espace de travail Azure Synapse, un type spécial d’identité de service managée.

CREATE CREDENTIAL [https://<storage_account>.dfs.core.windows.net/<container>]
WITH IDENTITY='Managed Identity'

Si vous le souhaitez, vous pouvez utiliser uniquement l’URL de base du compte de stockage, sans nom de conteneur.

Les informations d’identification incluses au niveau serveur ne sont pas requises pour autoriser l’accès aux fichiers publiquement disponibles. Créez une source de données sans information d’identification pour accéder aux fichiers publiquement disponibles dans le stockage Azure.

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.

Le script suivant crée des informations d’identification qui sont utilisées pour accéder aux fichiers sur le stockage en utilisant le jeton SAP spécifié dans les informations d’identification. Le script crée un exemple de source de données externe qui utilise ce jeton SAS pour accéder au stockage.

-- Optional: Create MASTER KEY if not exists in database:
-- CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Very Strong Password>'
GO
CREATE DATABASE SCOPED CREDENTIAL [SasToken]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
     SECRET = 'sv=2018-03-28&ss=bfqt&srt=sco&sp=rwdlacup&se=2019-04-18T20:42:12Z&st=2019-04-18T12:42:12Z&spr=https&sig=lQHczNvrk1KEIq78%3D';
GO
CREATE EXTERNAL DATA SOURCE mysample
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>',
          CREDENTIAL = SasToken
)

Le script suivant crée des informations d’identification délimitées à la base de données qui permettent d’accéder aux fichiers dans un stockage en utilisant le principal de service pour l’authentification et l’autorisation. Vous pouvez obtenir l’AppID en visitant Inscriptions d’applications dans le portail Azure et en sélectionnant l’application qui demande l’accès au stockage. Le Secret est obtenu durant l’inscription de l’application. AuthorityUrl est l’URL de l’autorité OAUTH 2.0 Microsoft Entra ID.

-- Optional: Create MASTER KEY if not exists in database:
-- CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Very Strong Password>

CREATE DATABASE SCOPED CREDENTIAL [<CredentialName>] WITH
IDENTITY = '<AppID>@<AuthorityUrl>' 
, SECRET = '<Secret>'
GO
CREATE EXTERNAL DATA SOURCE MyDataSource
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>',
          CREDENTIAL = CredentialName
)

Le script suivant crée des informations d’identification incluses dans l’étendue de la base de données, qui peuvent être utilisées pour emprunter l’identité de l’utilisateur Microsoft Entra actuel en tant qu’identité managée du service. Le script crée un exemple de source de données externe qui utilise l’identité de l’espace de travail pour accéder au stockage.

-- Optional: Create MASTER KEY if not exists in database:
-- CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Very Strong Password>
CREATE DATABASE SCOPED CREDENTIAL SynapseIdentity
WITH IDENTITY = 'Managed Identity';
GO
CREATE EXTERNAL DATA SOURCE mysample
WITH (    LOCATION   = 'https://<storage_account>.dfs.core.windows.net/<container>/<path>',
          CREDENTIAL = SynapseIdentity
)

Les informations d’identification incluses dans l’étendue de la base de données ne doivent pas nécessairement correspondre au nom du compte de stockage, car elles seront utilisées de manière explicite dans la SOURCE DE DONNÉES qui définit l’emplacement de stockage.

Les informations d’identification incluses dans l’étendue de la base de données ne sont pas requises pour autoriser l’accès aux fichiers publiquement disponibles. Créez une source de données sans information d’identification pour accéder aux fichiers publiquement disponibles dans le stockage Azure.

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