Gestion des identités et des accès
Cet article examine les considérations et recommandations relatives à la conception pour 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 un élément essentiel, les conseils sur les zones de conception de zone d’atterrissage Azure doivent également être inclus dans votre conception.
Cet article s’appuie sur des considérations et des recommandations sur les zones d’atterrissage Azure. Pour plus d’informations, consultez gestion des identités et des accès.
Conception de zone de réception des données
L’analytique à l’échelle du cloud prend en charge un modèle de contrôle d’accès à l’aide d’identités Microsoft Entra. Le modèle utilise à la fois le contrôle d’accès en fonction du rôle Azure (RBAC Azure) et les listes de contrôle d’accès (ACL).
Passez en revue les activités d’administration et de gestion Azure effectuées par vos équipes. Envisagez votre analyse à l'échelle du nuage sur Azure. Déterminez la meilleure répartition possible des responsabilités au sein de votre organisation.
Attributions de rôles
Pour développer, fournir et servir des produits de données de manière autonome au sein de la plateforme de données, les équipes d’applications de données nécessitent peu de droits d’accès dans l’environnement Azure. Avant de discuter des exigences RBAC respectives, il est important de souligner que différents modèles d’accès doivent être utilisés pour le développement et les environnements supérieurs. En outre, les groupes de sécurité doivent être utilisés dans la mesure du possible pour réduire le nombre d’attributions de rôles et simplifier le processus de gestion et de révision des droits RBAC. Cette étape est essentielle, en raison du nombre limité d’attributions de rôles qui peuvent être créées pour chaque abonnement.
L’environnement de développement doit être accessible à l’équipe de développement et à leurs identités utilisateur respectives. Cet accès leur permet d’itérer plus rapidement, d’en savoir plus sur certaines fonctionnalités au sein des services Azure et de résoudre efficacement les problèmes. L’accès à un environnement de développement permet de développer ou d’améliorer 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 supérieurs. 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 et, 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. Pour résumer, les droits d’accès à l’environnement de développement doivent être fournis à un principal de service ET des identités d’utilisateur et dans des environnements plus élevés, les droits d’accès ne doivent être fournis qu’à une identité de principal de service.
Pour pouvoir créer des ressources et des attributions de rôles entre des ressources au sein des groupes de ressources d’application de données, Contributor et les droits de User Access Administrator doivent être fournis. Ces droits permettent aux équipes de créer et de contrôler des services au sein de leur environnement dans les limites d’Azure Policy. L’analytique à l’échelle du cloud recommande l’utilisation de points de terminaison privés pour surmonter le risque d’exfiltration des données et, à mesure que d’autres options de connectivité sont bloquées par l’équipe de la plateforme Azure via des stratégies, les équipes d’applications de données nécessitent des droits d’accès au réseau virtuel partagé d’une zone d’atterrissage de données pour pouvoir configurer correctement la connectivité réseau requise pour les services qu’ils planifient d’utiliser. Pour suivre le principe des privilèges minimum, surmonter les conflits entre différentes équipes d’applications 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 à ce sous-réseau (étendue des ressources enfants). Cette attribution de rôle permet aux équipes de rejoindre le sous-réseau à l’aide de points de terminaison privés.
Ces deux premières attributions de rôle permettent le déploiement en libre-service de services de données dans ces environnements. Pour résoudre le problème de gestion des coûts, les organisations doivent ajouter une balise de centre de coûts aux groupes de ressources pour permettre la facturation croisée et la propriété des coûts distribués. Cela permet de sensibiliser les équipes et de les amener à prendre les bonnes décisions en ce qui concerne les SKUs et les niveaux de service requis.
Pour activer é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 requises. Si l’accès à un environnement Databricks est requis, les organisations doivent utiliser le SCIM Synch à partir de Microsoft Entra ID pour fournir l’accès. Cela est important, car ce mécanisme synchronise automatiquement les utilisateurs et les groupes de Microsoft Entra ID vers le plan de données Databricks et supprime également automatiquement les droits d’accès lorsqu’un individu quitte l’organisation ou l’entreprise. Dans Azure Databricks, les équipes d’application de données doivent avoir Can Restart droits d’accès à un cluster prédéfini pour pouvoir exécuter des charges de travail au sein de l’espace de travail.
Les équipes individuelles nécessitent l’accès au compte Microsoft Purview pour découvrir les ressources de données dans les zones d’atterrissage de données respectives. En outre, les équipes auront dans la plupart des cas besoin de la possibilité de modifier les ressources de données catalogées qu’elles possèdent afin de fournir des détails supplémentaires, tels que les coordonnées des propriétaires de données et des experts, ainsi que des détails plus précis sur les colonnes d’un jeu de données qui décrivent et les informations qu’elles intègrent.
Résumé des exigences de contrôle d’accès en fonction du rôle
Pour les besoins d’automatisation du déploiement de zones d’atterrissage de données, vous avez besoin de ces rôles :
Nom du rôle
Description
Portée
Déployez toutes les zones DNS privées pour tous les services de données dans un seul abonnement et un 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 de type 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’attribuer 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}
Remarque
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. Sans cette considération, la résolution DNS ne fonctionne pas. Le trafic entrant et sortant est supprimé, car il n’existe aucune ligne de vue vers 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. Il en va de même pour 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 requises pour déployer un produit de données dans une zone d’atterrissage de données :
Nom du rôle
Description
Portée
Déployez toutes les zones DNS privées pour tous les services de données dans un seul abonnement et un groupe de ressources. Le principal de service doit être Private DNS Zone Contributor pour le groupe de ressources DNS global qui a été créé pendant le déploiement de l'espace d'atterrissage pour la gestion des données. Ce rôle est nécessaire pour déployer des enregistrements de type 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 du service nécessite un accès Network Contributor sur ce sous-réseau.
(Étendue des ressources pour enfants) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
Accès à d’autres ressources
En dehors d’Azure, les équipes d’applications de données nécessitent également l’accès à 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 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, qui est effectuée dans la plupart des services via des principes de service. Par conséquent, les équipes nécessitent l’accès à un principe de service pour réaliser l’automatisation au sein de leur projet.
Gestion de l’accès aux données
La gestion de l’accès aux données doit être effectuée à l’aide de groupes Microsoft Entra. Ajoutez des noms principaux d’utilisateur ou des noms principaux 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 affiné.
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 Authentification pour l’analytique à l’échelle du cloud dans Azure.