Protéger les données sensibles dans une base de données SQL avec des stratégies de protection Microsoft Purview
S’applique à :✅ base de données SQL dans Microsoft Fabric
Microsoft Purview est une famille de solutions de gouvernance, de gestion des risques et de conformité des données qui peuvent aider votre organisation à gouverner, protéger, puis gérer l’ensemble de votre patrimoine de données. Entre autres avantages, Microsoft Purview vous permet d’étiqueter vos éléments de base de données SQL avec des étiquettes de confidentialité et de définir des stratégies de protection qui contrôlent l’accès en fonction des étiquettes de confidentialité.
Cet article explique comment les stratégies de protection Microsoft Purview fonctionnent avec les contrôles d’accès Microsoft Fabric et les contrôles d’accès SQL dans la base de données SQL dans Microsoft Fabric.
Pour obtenir des informations générales sur les fonctionnalités de Microsoft Purview pour Microsoft Fabric, notamment la base de données SQL, consultez les articles répertoriés dans Contenu associé.
Fonctionnement des stratégies de protection dans une base de données SQL
Chaque stratégie de protection pour Microsoft Fabric est associée à une étiquette de confidentialité. Une stratégie de protection contrôle l’accès aux éléments qui ont l’étiquette associée via deux contrôles d’accès :
Autoriser les utilisateurs à conserver l’accès en lecture : lorsqu’ils sont activés, autorise les utilisateurs spécifiés (ou les utilisateurs appartenant aux groupes spécifiés) à conserver l’autorisation d’élément de lecture sur les éléments étiquetés si les utilisateurs spécifiés disposent déjà de l’autorisation. Toutes les autres autorisations dont disposent les utilisateurs spécifiés sur l’élément sont supprimées. Dans la base de données SQL, l’autorisation d’élément de lecture est requise pour qu’un utilisateur se connecte à une base de données. Par conséquent, si un utilisateur n’est pas spécifié dans ce contrôle d’accès, l’utilisateur ne peut pas se connecter à la base de données.
Autoriser les utilisateurs à conserver le contrôle total : lorsqu’ils sont activés, autorise les utilisateurs spécifiés (ou les utilisateurs appartenant aux groupes spécifiés) à conserver le contrôle total sur l’élément étiqueté si les utilisateurs spécifiés en disposent déjà, ou toute autre autorisation qu’ils pourraient avoir. Pour les éléments de base de données SQL, ce contrôle permet aux utilisateurs de conserver l’autorisation d’élément d’écriture, ce qui signifie que l’utilisateur conserve un accès administratif complet à l’intérieur de la base de données. Si un utilisateur n’est pas spécifié dans ce contrôle d’accès, l’autorisation d’élément d’écriture est effectivement supprimée de l’utilisateur. Ce contrôle n’a aucun effet sur les autorisations SQL natives de l’utilisateur dans la base de données. Pour plus d’informations, consultez Exemple 4 et Limitations.
Exemples
Les exemples de cette section partagent la configuration suivante :
- Une organisation dispose d’un espace de travail Microsoft Fabric, appelé Production.
- L’espace de travail contient un élément de base de données SQL, nommé Sales, qui a l’étiquette de confidentialité.
- Dans Microsoft Purview, il existe une stratégie de protection applicable à Microsoft Fabric. La stratégie est associée à l’étiquette de confidentialité confidentielle.
Exemple 1
- Un utilisateur est membre du rôle Contributeur pour l’espace de travail Production.
- Les utilisateurs autorisés à conserver le contrôle d’accès en lecture sont activés, mais il n’inclut pas l’utilisateur.
- Les utilisateurs autorisés à conserver le contrôle d’accès en contrôle total sont désactivés ou inactifs.
La stratégie supprime l’autorisation d’élément de lecture de l’utilisateur. Par conséquent, l’utilisateur ne peut pas se connecter à la base de données Sales. Par conséquent, l’utilisateur ne peut pas lire ni accéder à des données dans la base de données.
Exemple 2
- Un utilisateur dispose de l’autorisation Lire l’élément pour la base de données Sales.
- L’utilisateur est membre du rôle au niveau de la base de données native SQL db_owner dans la base de données.
- Les utilisateurs autorisés à conserver le contrôle d’accès en lecture sont activés, mais il n’inclut pas l’utilisateur.
- Les utilisateurs autorisés à conserver le contrôle d’accès en contrôle total sont désactivés ou inactifs.
La stratégie supprime l’autorisation d’élément lecture de l’utilisateur. Par conséquent, l’utilisateur ne peut pas se connecter à la base de données Sales, quelles que soient les autorisations SQL natives de l’utilisateur (accordées via l’appartenance de l’utilisateur au rôle db_owner) dans la base de données. Par conséquent, l’utilisateur ne peut pas lire ni accéder à des données dans la base de données.
Exemple 3
- Un utilisateur est membre du rôle Contributeur pour l’espace de travail Production.
- L’utilisateur n’a pas d’autorisations natives SQL accordées dans la base de données.
- Les utilisateurs autorisés à conserver le contrôle d’accès en lecture sont activés, et il inclut l’utilisateur.
- Les utilisateurs autorisés à conserver le contrôle d’accès total sont activés, mais il n’inclut pas l’utilisateur.
En tant que membre du rôle Contributeur, l’utilisateur dispose initialement de toutes les autorisations sur la base de données Sales, notamment Lecture, ReadData et Write. L’autorisation Autoriser les utilisateurs à conserver le contrôle d’accès en lecture dans la stratégie permet à l’utilisateur de conserver les autorisations Lecture et ReadData, mais l’autorisation Autoriser les utilisateurs à conserver le contrôle d’accès en contrôle total supprime l’autorisation d’écriture de l’utilisateur. Par conséquent, l’utilisateur peut se connecter à la base de données et lire les données, mais l’utilisateur perd l’accès administratif à la base de données, y compris la possibilité d’écrire/modifier des données.
Exemple 4
- Un utilisateur dispose de l’autorisation Lire l’élément pour la base de données Sales.
- L’utilisateur est membre du rôle au niveau de la base de données native SQL db_owner dans la base de données.
- Les utilisateurs autorisés à conserver le contrôle d’accès en lecture sont activés, et il inclut l’utilisateur.
- Les utilisateurs autorisés à conserver le contrôle d’accès total sont activés, mais il n’inclut pas l’utilisateur.
L’option Autoriser les utilisateurs à conserver le contrôle d’accès en lecture dans la stratégie permet à l’utilisateur de conserver l’autorisation Lecture. Comme l’utilisateur n’a pas initialement d’accès en contrôle total (autorisation d’élément d’écriture), l’autorisation Autoriser les utilisateurs à conserver le contrôle d’accès en contrôle total n’a aucun effet sur l’autorisation accordée par l’utilisateur dans Microsoft Fabric. Les utilisateurs autorisés à conserver le contrôle d’accès en contrôle total n’ont pas d’impact sur l’autorisation SQL native de l’utilisateur dans la base de données. En tant que membre du rôle db_owner, l’utilisateur continue d’avoir un accès administratif à la base de données. Voir Limitations.
Limites
- Les utilisateurs autorisés à conserver le contrôle d’accès total dans les stratégies de protection Microsoft Purview n’ont aucun impact sur les autorisations natives SQL accordées aux utilisateurs d’une base de données.