Gestion de l’identité et de l’accès
Cet article décrit 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 composant stratégique, vous devez suivre les instructions relatives aux zones de conception de zone d’atterrissage Azure lorsque vous concevez votre solution.
Cet article s’appuie sur les considérations et les suggestions relatives aux zones d’atterrissage Azure. Pour plus d’informations, consultez zone de conception de 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 le contrôle d’accès en fonction du rôle Azure (Azure RBAC) et les listes de contrôle d’accès.
Passez en revue les activités d’administration et de gestion Azure effectuées par vos équipes. Évaluez votre analytique à l’échelle du cloud sur Azure. Déterminez la meilleure distribution possible des responsabilités au sein de votre organisation.
Affectations 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 plusieurs droits d’accès dans l’environnement Azure. Il est important de noter que vous devez utiliser différents modèles d’accès pour le développement et les environnements supérieurs. Utilisez des groupes de sécurité lorsque 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. Cette étape est cruciale en raison du nombre limité d’attributions de rôles que vous pouvez créer 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 peut vous aider à développer ou à améliorer l’infrastructure en tant que code et d’autres artefacts de code.
Après avoir confirmé qu’une implémentation fonctionne comme prévu dans l’environnement de développement, elle peut être déployée en continu dans des environnements plus élevés. Les environnements plus élevés, tels que les tests et la 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 en utilisant les pipelines d'intégration continue et de livraison continue (CI/CD) via l'identité de l'entité de service principale. Dans l’environnement de développement, fournissez des droits d’accès à un principal de service et à des identités utilisateur. Dans les environnements avancés, limitez les droits d’accès uniquement à l’identité du principal de service.
Pour créer des ressources et des attributions de rôles entre des ressources au sein des groupes de ressources d’application de données, vous devez fournir des droits Contributor et User Access Administrator. Ces droits permettent aux équipes de créer et de contrôler des services dans leur environnement dans les limites d’Azure Policy.
Pour réduire le risque d’exfiltration des données, il est recommandé d’utiliser des points de terminaison privés dans le cloud. L’équipe de la plateforme Azure bloque d’autres options de connectivité via des stratégies. Les équipes d’applications de données ont donc besoin de droits d’accès au réseau virtuel partagé d’une zone d’atterrissage de données. Cet accès est essentiel pour configurer la connectivité réseau nécessaire pour les services qu’ils prévoient d’utiliser.
Pour suivre le principe des privilèges minimum, évitez les conflits entre différentes équipes d’application de données et disposez d’une séparation claire des équipes. Il s'agit des meilleures pratiques en matière d'analytique à l'échelle du cloud pour créer un sous-réseau dédié pour chaque équipe d'application de données et créer une attribution de rôle Network Contributor pour ce sous-réseau ou à l'échelle des ressources secondaires. 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ôles permettent le déploiement en libre-service des services de données au sein de ces environnements. Pour résoudre les problèmes 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é distribuée des coûts. Cette approche permet de sensibiliser les équipes et de s’assurer qu’elles prennent des décisions éclairées sur les références SKU et les niveaux de service requis.
Pour activer 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 Azure Databricks est requis, les organisations doivent utiliser synchronisation SCIM à partir de Microsoft Entra ID pour fournir l’accès. Ce mécanisme de synchronisation est important, car il synchronise automatiquement les utilisateurs et les groupes de l’ID Microsoft Entra vers le plan de données Azure Databricks. Il supprime également automatiquement les droits d’accès lorsqu’un individu quitte l’organisation ou l’entreprise. Dans Azure Databricks, donnez aux équipes d’application de données Can Restart des droits d’accès à un cluster prédéfini afin qu’elles puissent 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 leurs zones d’atterrissage de données respectives. Les équipes doivent souvent modifier les ressources de données catalogées qu’elles possèdent pour fournir des détails supplémentaires tels que les informations de contact des propriétaires de données et des experts. Les équipes nécessitent également la possibilité de fournir des informations plus précises sur ce que chaque colonne d’un ensemble de données décrit et inclut.
Résumé des exigences RBAC
Pour automatiser le déploiement de zones d’atterrissage de données, les rôles suivants sont requis :
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 de type A pour les points de terminaison privés.
(Étendue du groupe de ressources) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
Pour configurer le peering de réseaux virtuels entre le réseau de la zone d'atterrissage des données et le réseau de la zone de gestion des données, le principal de service doit avoir des 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}
Remarque
Dans un scénario de production, vous pouvez réduire le nombre d’attributions de rôles. Le rôle Network Contributor est nécessaire uniquement pour configurer le peering de réseaux virtuels entre la zone d’atterrissage de gestion des données et la zone d’atterrissage des données. Sans ce rôle, la résolution DNS échoue. En outre, 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 nécessaire si le déploiement d’enregistrements DNS A pour les points de terminaison privés est automatisé via des stratégies Azure avec l’effet deployIfNotExists. Il en va de même pour le rôle User Access Administrator, car vous pouvez automatiser le déploiement à 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 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 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 de données dans un groupe de ressources unique au sein de l’abonnement de la zone de réception 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 Azure Private Link spécifié qui a été créé pendant le déploiement de la zone d'atterrissage des données Azure, l'entité de service nécessite un accès de niveau Network Contributor sur ce sous-réseau.
(Étendue de la ressource enfant) /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 l’accès à un référentiel pour stocker des artefacts de code, collaborer efficacement et déployer des mises à jour et des modifications cohérentes dans des environnements plus élevés via CI/CD. Vous devez fournir un tableau de projet pour permettre le développement agile, la planification sprint, le suivi des tâches et la gestion des commentaires des utilisateurs et des demandes de fonctionnalités.
Pour automatiser CI/CD, établissez une connexion à Azure. Ce processus est effectué dans la plupart des services via des principaux de service. En raison de cette exigence, les équipes doivent avoir accès à un principal de service pour obtenir l’automatisation dans leur projet.
Gérer l’accès aux données
Gérez l’accès aux données à l’aide de groupes Microsoft Entra. Ajoutez des noms d’utilisateur principaux ou des noms de principal de service aux groupes Microsoft Entra. Ensuite, ajoutez ces groupes aux services et accordez des autorisations au groupe. Cette approche permet un contrôle d’accès de granularité fine.
Pour plus d’informations sur la façon de favoriser la sécurité des zones d’atterrissage de gestion des données et des zones d’atterrissage de données qui gèrent votre patrimoine de données, consultez Authentification pour l’analytique à l’échelle du cloud dans Azure.