Gestion de l’identité et de l’accès
Cet article détaille les recommandations et considérations relatives à la gestion des identités et des accès. Il se concentre sur le déploiement d’une plateforme d’analytique à l’échelle du cloud sur Microsoft Azure. Étant donné que l’analytique à l’échelle du cloud est une opération stratégique, l’aide relative aux domaines de conception des zones d’atterrissage Azure doit également être prise en compte dans votre conception.
Cet article s’appuie sur les considérations et les recommandations relatives aux zones d’atterrissage Azure. Pour plus d’informations, consultez Gestion des identités et des accès.
Conception d’une zone d’atterrissage
L’analytique à l’échelle du cloud prend en charge un modèle de contrôle d’accès utilisant les identités Microsoft Entra. Ce module utilise à la fois le contrôle d’accès en fonction du rôle (Azure RBAC) et les listes de contrôle d’accès (ACL).
Passez en revue les activités d’administration et de gestion Azure que vos équipes effectuent. Examinez votre analytique à l’échelle du cloud dans Azure. Déterminez la meilleure distribution possible des responsabilités au sein de votre organisation.
Affectations de rôles
Pour développer, fournir et traiter des produits de données de manière autonome au sein de la plateforme de données, les équipes d’application de données ont besoin de quelques droits d’accès dans l’environnement Azure. Avant d’aborder les exigences relatives au contrôle d’accès en fonction du rôle (RBAC), il est nécessaire de souligner que différents modèles d’accès doivent être utilisés pour les environnements de développement et supérieurs. En outre, les groupes de sécurité doivent être utilisés dès que cela est possible pour réduire le nombre d’attributions de rôles et simplifier le processus de gestion et de révision des droits RBAC. Cela est essentiel en raison du nombre limité d’attributions de rôles qui peuvent être créées par abonnement.
L’équipe de développement et ses identités utilisateur respectives doivent disposer de l’autorisation d’accès à l’environnement de développement pour être en mesure d’itérer plus rapidement, de découvrir certaines fonctionnalités au sein des services Azure et de résoudre efficacement les problèmes. L’accès à un environnement de développement vous aide lors du développement ou de l’amélioration de l’infrastructure en tant que code (IaC) et d’autres artefacts de code. Une fois qu’une implémentation dans l’environnement de développement fonctionne comme prévu, elle peut être déployée en continu dans les environnements plus élevés. Les environnements plus élevés, comme les environnements de tests et de production, doivent être verrouillés pour l’équipe d’application de données. Seul un principal de service doit avoir accès à ces environnements. Par conséquent, tous les déploiements doivent être exécutés via l’identité du principal de service à l’aide de pipelines CI/CD. En résumé, dans l’environnement de développement, les droits d’accès doivent être fournis à un principal de service ET aux identités utilisateur. Dans les environnements plus élevés, les droits d’accès doivent être fournis uniquement à une identité de principal de service.
Pour pouvoir créer des ressources et des attributions de rôles entre les ressources au sein du ou des groupes de ressources d’application de données, les droits Contributor et User Access Administrator doivent être fournis. Cela permet aux équipes de créer et de contrôler des services au sein de leur environnement dans les limites d’Azure Policy. Pour l’analytique à l’échelle du cloud, il est recommandé d’utiliser des points de terminaison privés afin d’éviter le risque d’exfiltration des données. Étant donné que les options de connectivité devraient être bloquées par l’équipe de la plateforme Azure par le biais de stratégies, les équipes d’application de données doivent être autorisés à accéder au réseau virtuel partagé d’une zone d’atterrissage de données pour pouvoir configurer avec succès la connectivité réseau nécessaire pour les services qu’ils envisagent d’utiliser. Pour respecter le principe des privilèges minimum, éviter les conflits entre différentes équipes d’application de données et avoir une séparation claire des équipes, l’analytique à l’échelle du cloud propose de créer un sous-réseau dédié par équipe d’application de données et de créer une attribution de rôle Network Contributor pour ce sous-réseau (étendue des ressources enfants). Cette attribution de rôle permet aux équipes d’accéder au sous-réseau à l’aide de points de terminaison privés.
Ces deux premières attributions de rôles permettent le déploiement en libre-service des services de données dans ces environnements. À des fins de gestion des coûts, les organisations doivent ajouter une étiquette de centre de coûts aux groupes de ressources pour permettre la facturation croisée et le coût de possession distribué. Cette mesure augmente la sensibilisation au sein des équipes et les incite à prendre les bonnes décisions concernant les références SKU et les niveaux de service nécessaires.
Pour permettre également l’utilisation en libre-service d’autres ressources partagées dans la zone d’atterrissage des données, quelques attributions de rôles supplémentaires sont nécessaires. Si l’accès à un environnement Databricks est nécessaire, les organisations doivent utiliser la synchronisation SCIM à partir de Microsoft Entra ID pour fournir l’accès. C’est important, car ce mécanisme synchronise automatiquement les utilisateurs et les groupes Microsoft Entra ID dans le plan de données Databricks. Il supprime également automatiquement les droits d’accès quand un individu quitte l’organisation ou l’entreprise. Cette opération ne serait pas possible si des comptes d’utilisateur distincts étaient utilisés dans Azure Databricks. Les équipes d’application de données doivent être ajoutées à l’espace de travail Databricks dans le shared-product-rg et dans le shared-integration-rg. Au sein d’Azure Databricks, les équipes d’application de données doivent disposer des droits d’accès Can Restart à un cluster prédéfini pour pouvoir exécuter des charges de travail dans l’espace de travail.
Les équipes individuelles devront accéder au compte Purview central pour découvrir les ressources de données dans les zones d’atterrissage de données respectives. Par conséquent, les équipes devront être ajoutées en tant que Data Reader à la collection de niveau supérieur Purview. En outre, les équipes doivent généralement être en mesure de modifier les ressources de données cataloguées qu’elles possèdent afin d’indiquer des détails supplémentaires, comme les coordonnées des propriétaires de données et des experts, ainsi que des détails plus granulaires indiquant ce que les colonnes dans un jeu de données décrivent et les informations contenues.
Résumé des exigences de contrôle d’accès en fonction du rôle
À des fins d’automatisation du déploiement des zones d’atterrissage des données, vous avez besoin des rôles suivants :
Nom de rôle
Description
Étendue
Déployez toutes les zones DNS privées pour tous les services de données dans un seul abonnement et groupe de ressources. Le principal du service doit être Private DNS Zone Contributor sur le groupe de ressources DNS global qui a été créé pendant le déploiement de la zone d’atterrissage de gestion des données. Ce rôle est requis pour déployer des enregistrements A pour les points de terminaison privés.
(Étendue du groupe de ressources) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Pour configurer l’appairage de réseaux virtuels entre le réseau de zone d’atterrissage des données et le réseau de zone d’atterrissage de gestion des données, le principal du service doit disposer de droits d’accès Network Contributor sur le groupe de ressources du réseau virtuel distant.
(Étendue du groupe de ressources) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Cette autorisation est requise pour partager le runtime d’intégration auto-hébergé qui est déployé dans le groupe de ressources integration-rg avec d’autres fabriques de données. Il est également nécessaire d’affecter l’accès aux identités managées Azure Data Factory et Azure Synapse Analytics sur les systèmes de fichiers de compte de stockage respectifs.
(Étendue des ressources) /subscriptions/{{dataLandingZone}subscriptionId}
Notes
Le nombre d’attributions de rôles peut être réduit dans un scénario de production. L’attribution de rôle Network Contributor est requise uniquement pour configurer l’appairage de réseaux virtuels entre la zone d’atterrissage de gestion des données et la zone d’atterrissage des données. Si cela n’est pas pris en compte, la résolution DNS ne fonctionne pas. Le trafic entrant et sortant est abandonné, car il n’y a aucune ligne de vue sur le Pare-feu Azure.
Le rôle Private DNS Zone Contributor n’est pas non plus requis si le déploiement des enregistrements DNS A des points de terminaison privés est automatisé via des stratégies Azure avec effet deployIfNotExists. La même remarque s’applique au rôle User Access Administrator car le déploiement peut être automatisé à l’aide de stratégies deployIfNotExists.
Attributions de rôles pour les produits de données
Les attributions de rôles suivantes sont nécessaires pour déployer un produit de données dans une zone d’atterrissage des données :
Nom de rôle
Description
Étendue
Déployez toutes les zones DNS privées pour tous les services de données dans un seul abonnement et groupe de ressources. Le principal du service doit être Private DNS Zone Contributor sur le groupe de ressources DNS global qui a été créé pendant le déploiement de la zone d’atterrissage de gestion des données. Ce rôle est requis pour déployer des enregistrements A pour les points de terminaison privés respectifs.
(Étendue du groupe de ressources) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Déployez tous les services de streaming d’intégration des données dans un groupe de ressources unique au sein de l’abonnement à la zone d’atterrissage des données. Le principal de service nécessite une attribution de rôle Contributor sur ce groupe de ressources.
(Étendue du groupe de ressources) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
Pour déployer des points de terminaison privés sur le sous-réseau Private Link spécifié, qui a été créé pendant le déploiement de la zone d’atterrissage des données, le principal de service doit avoir l’accès Network Contributor à ce sous-réseau.
(Étendue des ressources enfants) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
Accès à d’autres ressources
En dehors d’Azure, les équipes d’intégration de données et de produit de données ont également besoin d’accéder à un référentiel pour stocker des artefacts de code, collaborer efficacement et déployer des mises à jour et des modifications de manière cohérente via CI/CD vers des environnements plus élevés. En outre, un tableau de projet doit être fourni pour permettre le développement agile, la planification du sprint, le suivi des tâches, ainsi que les commentaires des utilisateurs et les demandes de fonctionnalités.
Enfin, l’automatisation CI/CD nécessite la configuration d’une connexion à Azure. Dans la plupart des services, cela s’effectue via des principaux de service. Par conséquent, les équipes ont besoin de l’accès à un principal de service pour réaliser l’automatisation dans leur projet.
Gestion de l’accès aux données
La gestion de l’accès aux données doit être effectuée en utilisant des groupes Microsoft Entra. Ajoutez des noms d’utilisateur principal ou des noms de principal de service aux groupes Microsoft Entra. Ajoutez les groupes aux services et accordez des autorisations au groupe. Cette approche permet un contrôle d’accès de granularité fine.
Pour les produits de données dans les lacs de données Azure, envisagez d’utiliser des listes de contrôle d’accès (ACL). Pour plus d’informations, consultez Modèle de contrôle d’accès dans Azure Data Lake Storage Gen2. L’utilisation de l’authentification directe Microsoft Entra avec des listes de contrôle d’accès est prise en charge par la plupart des services natifs Azure, notamment Azure Machine Learning, Azure Synapse SQL Serverless, Apache Spark pour Azure Synapse et Azure Databricks.
D’autres stockages polyglot sont susceptibles d’être utilisés dans l’analytique à l’échelle du cloud. On peut citer par exemple Azure Database pour PostgreSQL, Azure Database pour MySQL, Azure SQL Database, SQL Managed Instance et les pools dédiés Azure Synapse SQL. Ils peuvent être utilisés par les équipes d’application de données pour stocker des produits de données.
- Utiliser Microsoft Entra ID pour l’authentification avec Azure Database pour PostgreSQL
- Utiliser l’authentification Microsoft Entra avec Azure SQL Database, SQL Managed Instance et Azure Synapse Analytics
- Utiliser Microsoft Entra ID pour l’authentification avec Azure Database pour MySQL
Nous vous recommandons d’utiliser des groupes Microsoft Entra pour sécuriser les objets de base de données au lieu de comptes d’utilisateur Microsoft Entra individuels. Ces groupes Microsoft Entra sont utilisés pour authentifier les utilisateurs et protéger les objets de base de données. À l’instar du modèle de lac de données, vous pouvez utiliser votre intégration de domaine ou de produits de données pour créer ces groupes dans votre service Microsoft Entra.
Cette approche fournit également un emplacement de gestion unique et permet de passer en revue les droits d’accès au sein de Graph Azure.
Pour plus d’informations sur la façon de sécuriser les zones d’atterrissage de gestion des données et les zones d’atterrissage des données qui gèrent votre patrimoine de données, consultez Provisionner la sécurité pour l’analytique à l’échelle du cloud dans Azure.