Gérer les autorisations utilisateur dans des pools SQL serverless Azure Synapse
Pour sécuriser les données, Stockage Azure implémente un modèle de contrôle d’accès qui prend en charge le contrôle d’accès en fonction du rôle (RBAC) Azure et les listes de contrôle d’accès (ACL) comme POSIX (Portable Operating System Interface for Unix).
Vous pouvez associer un principal de sécurité à un niveau d’accès pour les fichiers et répertoires. Ces associations sont capturées dans une liste de contrôle d’accès (ACL) . Chaque fichier et répertoire de votre compte de stockage a une liste de contrôle d’accès. Lorsqu’un principal de sécurité tente une opération sur un fichier ou un répertoire, une vérification de la liste de contrôle d’accès détermine si ce principal de sécurité (utilisateur, groupe, principal du service ou identité managée) a le niveau d’autorisation approprié pour effectuer l’opération.
On distingue deux types de listes de contrôle d'accès :
ACL d’accès
Contrôle l’accès à un objet. Les fichiers et les répertoires ont tous des ACL d’accès.
ACL par défaut
Il s’agit des modèles d’ACL associés à un répertoire, qui déterminent les ACL d’accès pour tous les éléments enfants créés dans ce répertoire. Les fichiers n’ont pas d’ACL par défaut.
Les ACL d’accès et les ACL par défaut ont la même structure.
Les autorisations sur un objet conteneur sont Lecture, Écriture et Exécution. Elles peuvent être utilisées sur les fichiers et les répertoires comme l’indique le tableau ci-dessous :
Niveaux d’autorisations
| Autorisation | Fichier | Répertoire |
|---|---|---|
| Lecture (R) | Permet de lire le contenu d’un fichier | Requiert les autorisations Lecture et Exécution pour répertorier le contenu du répertoire |
| Écriture (W) | Permet d’écrire ou d’ajouter du contenu dans un fichier | Requiert les autorisations Écriture et Exécution pour créer des éléments enfants dans un répertoire |
| Exécution (X) | Cela ne signifie rien dans le contexte de Data Lake Storage Gen2 | Requise pour parcourir les éléments enfants d’un répertoire |
Instructions de configuration des listes de contrôle d’accès
Utilisez toujours les groupes de sécurité Microsoft Entra comme principal attribué dans une entrée de liste de contrôle d’accès. Résistez à la possibilité d’attribuer directement des utilisateurs ou des principaux de service individuels. L’utilisation de cette structure vous permettra d’ajouter et de supprimer des utilisateurs ou des principaux de service sans devoir réappliquer les ACL sur la structure de répertoires dans son ensemble. Au lieu de cela, vous pouvez simplement ajouter ou supprimer des utilisateurs et des principaux de service dans le groupe de sécurité Microsoft Entra approprié.
Il existe de nombreuses façons de configurer des groupes. Par exemple, imaginez que vous disposez d’un répertoire nommé /LogData qui contient les données de journal générées par votre serveur. Azure Data Factory (ADF) ingère les données dans ce dossier. Des utilisateurs spécifiques de l’équipe d’ingénierie des services chargent les journaux et gèrent les autres utilisateurs de ce dossier, et divers clusters Databricks analysent les journaux à partir de ce dossier.
Pour activer ces activités, vous pouvez créer un groupe LogsWriter et un groupe LogsReader. Ensuite, vous pouvez affecter des autorisations comme suit :
- Ajoutez le groupe LogsWriter à l’ACL du répertoire/LogData avec les autorisations rwx.
- Ajoutez le groupe LogsReader à l’ACL du répertoire/LogData avec les autorisations r-x.
- Ajoutez l’objet principal du service ou l’identité du service géré (MSI) pour ADF au groupe LogsWriter.
- Ajoutez des utilisateurs de l’équipe d’ingénierie des services au groupe LogsWriter.
- Ajoutez l’objet principal du service ou la MSI pour Databricks au groupe LogsReader.
Si un utilisateur de l’équipe d’ingénierie des services quitte l’entreprise, vous pouvez simplement le supprimer du groupe LogsWriter. Si vous n’avez pas ajouté cet utilisateur à un groupe, mais que vous avez ajouté une entrée ACL dédiée pour cet utilisateur, vous devez supprimer cette entrée ACL du répertoire /LogData. Vous devez également supprimer l’entrée de tous les sous-répertoires et fichiers de l’ensemble de la hiérarchie de répertoires du répertoire /LogData.
Rôles nécessaires pour les utilisateurs de pools SQL serverless
Pour les utilisateurs qui ont besoin d’un accès en lecture seule, vous devez attribuer un rôle nommé Lecteur des données blob du stockage.
Pour les utilisateurs qui ont besoin d’un accès en lecture/écriture, vous devez attribuer un rôle nommé Contributeur aux données blob du stockage. L’accès en lecture/écriture est nécessaire si l’utilisateur doit avoir accès à CETAS (Create External table As Select).
Notes
Si l’utilisateur possède un rôle de propriétaire ou de contributeur, ce rôle n’est pas suffisant. Azure Data Lake Storage Gen 2 contient des super rôles qui doivent être affectés.
Autorisation au niveau base de données
Pour offrir à l’utilisateur un accès plus granulaire, vous devez utiliser la syntaxe Transact-SQL pour créer des identifiants de connexion et des utilisateurs.
Pour accorder à un utilisateur l’accès à une base de données de pool SQL serverless unique, suivez les étapes de cet exemple :
Créer des informations de connexion (LOGIN)
use master CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER;Créer un utilisateur (USER)
use yourdb -- Use your DB name CREATE USER alias FROM LOGIN [alias@domain.com];Ajouter USER aux membres du rôle spécifié
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.
Autorisation au niveau du serveur
Pour accorder à un utilisateur l’accès complet à toutes les bases de données de pool SQL serverless, suivez cet exemple :
CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER; ALTER SERVER ROLE sysadmin ADD MEMBER [alias@domain.com];