Partager via

Livre blanc sur la sécurité d’Azure Synapse Analytics : Contrôle d’accès

  • Article

Notes

Cet article fait partie de la série d’articles du livre blanc sur la sécurité d’Azure Synapse Analytics. Pour une vue d’ensemble de la série, consultez le livre blanc sur la sécurité d’Azure Synapse Analytics.

Selon la façon dont les données ont été modélisées et stockées, la gouvernance des données et le contrôle d’accès peuvent nécessiter que les développeurs et administrateurs de la sécurité utilisent des approches différentes, ou une combinaison de techniques, pour implémenter une base de sécurité fiable.

Azure Synapse prend en charge un large éventail de fonctionnalités qui permet de contrôler qui peut accéder aux données. Ces fonctionnalités sont basées sur un ensemble de fonctionnalités avancées de contrôle d’accès, notamment :

Sécurité au niveau des objets

Chaque objet dans un pool SQL dédié a des autorisations associées qui peuvent être accordées à un principal. Dans le contexte des utilisateurs et comptes de service, celles-ci permettent de sécuriser les tables individuelles, les vues, les procédures stockées et les fonctions. Les autorisations d’objet, telles que SELECT, peuvent être accordées à des comptes d’utilisateur (connexions SQL et utilisateurs ou groupes Microsoft Entra) et des rôles de base de données, ce qui permet aux administrateurs de base de données d’avoir une flexibilité. Par ailleurs, les autorisations accordées sur des tables et des vues peuvent être combinées avec d’autres mécanismes de contrôle d’accès (décrits ci-dessous), tels que la sécurité au niveau des colonnes, la sécurité au niveau des lignes et le masquage dynamique des données.

Dans Azure Synapse, toutes les autorisations sont accordées aux utilisateurs et aux rôles au niveau de la base de données. Par ailleurs, les utilisateurs ayant le rôle RBAC d’administrateur Synapse intégré au niveau de l’espace de travail bénéficient automatiquement d’un accès complet à tous les pools SQL dédiés.

Outre la sécurisation des tables SQL dans Azure Synapse, le pool SQL dédié (anciennement SQL DW), le pool SQL serverless et les tables Spark peuvent être également sécurisés. Par défaut, les utilisateurs ayant le rôle Contributeur aux données Blob du stockage des lacs de données connectés à l’espace de travail disposent des autorisations de lecture, d’écriture et d’exécution sur toutes les tables créées par Spark lorsque les utilisateurs exécutent du code de manière interactive dans le notebook. Cette méthode appelée Pass-through Microsoft Entra s’applique à tous les lacs de données connectés à l’espace de travail. Toutefois, si le même utilisateur exécute le même notebook par le biais d’un pipeline, la MSI (Managed Service Identity) de l’espace de travail est utilisée pour l’authentification. Par conséquent, pour que le pipeline exécute correctement la MSI de l’espace de travail, il doit également appartenir au rôle Contributeur aux données Blob du stockage pour le lac de données faisant l’objet de l’accès.

Sécurité au niveau des lignes

La sécurité au niveau des lignes permet aux administrateurs de la sécurité d’établir et de contrôler un accès précis à des lignes de table spécifiques en fonction du profil d’un utilisateur (ou d’un processus) exécutant une requête. Les caractéristiques du profil ou de l’utilisateur peuvent faire référence à l’appartenance à un groupe ou au contexte d’exécution. La sécurité au niveau des lignes permet d’empêcher tout accès non autorisé lorsque les utilisateurs interrogent des données à partir des mêmes tables, mais qu’ils doivent voir différents sous-ensembles de données.

Notes

La sécurité au niveau des lignes est prise en charge dans Azure Synapse et le pool SQL dédié (anciennement SQL DW), mais n’est pas prise en charge pour le pool Apache Spark et le pool SQL serverless.

Sécurité au niveau des colonnes

La sécurité au niveau des colonnes permet aux administrateurs de la sécurité de définir des autorisations qui limitent les personnes autorisées à accéder aux colonnes sensibles dans les tables. Elle est définie au niveau de la base de données et peut être implémentée sans qu’il soit nécessaire de modifier la conception du modèle de données ou de la couche Application.

Remarque

La sécurité au niveau des colonnes est prise en charge dans Azure Synapse, les affichages du pool SQL serverless et le pool SQL dédié (anciennement SQL DW), mais n’est pas prise en charge pour le pool Apache Spark et les tables externes du pool SQL serverless. Dans le cas de tables externes du pool SQL serverless, une solution de contournement peut être appliquée en créant un affichage en haut d’une table externe.

Masquage dynamique des données

Le masquage dynamique des données permet aux administrateurs de la sécurité de limiter l’exposition des données sensibles en les masquant à la lecture pour les utilisateurs ne disposant pas de privilèges. Cela permet d’empêcher les accès non autorisés aux données sensibles en permettant aux administrateurs de déterminer la façon dont les données sont affichées au moment de la requête. En fonction de l’identité de l’utilisateur authentifié et de son affectation de groupe dans le pool SQL, une requête renvoie des données masquées ou non masquées. Le masquage est toujours appliqué, que les données soient accédées directement à partir d’une table, ou à l’aide d’une vue ou d’une procédure stockée.

Notes

Le masquage dynamique des données est pris en charge dans Azure Synapse et le pool SQL dédié (anciennement SQL DW), mais n’est pas pris en charge pour le pool Apache Spark et le pool SQL serverless.

Contrôle d’accès en fonction du rôle Synapse

Azure Synapse comprend également des rôles de contrôle d’accès en fonction du rôle (RBAC) Synapse pour gérer différents aspects de Synapse Studio. Tirez parti de ces rôles prédéfinis pour attribuer des autorisations à des utilisateurs, des groupes ou d’autres principaux de sécurité afin de gérer qui peut :

  • publier des artefacts de code et répertorier ou afficher les artefacts de code publiés ,
  • exécuter du code sur des pools Apache Spark et des runtimes d’intégration ;
  • accéder aux services liés (données) protégés par des informations d’identification ;
  • surveiller ou annuler l’exécution d’un travail, passer en revue la sortie du travail et les journaux d’exécution.

Étapes suivantes

Dans le prochain article de cette série de livres blancs, vous en apprendrez davantage sur l’authentification.