Authentification pour l’analyse à l’échelle du cloud dans Azure
L'authentification est le processus de vérification de l’identité de l’utilisateur ou de l’application. Il est préférable d’utiliser un fournisseur d’identité de source unique qui gère la gestion de l’identité et l’authentification. Ce fournisseur est appelé service d’annuaire. Il fournit des méthodes pour stocker les données d’annuaire et mettre ces données à la disposition des utilisateurs et administrateurs du réseau.
Toute solution de lac de données doit utiliser et s’intégrer au service d’annuaire qui est déjà en cours d’utilisation. Pour la plupart des organisations, Active Directory est le service d’annuaire pour tous les services liés à l’identité. Il s’agit de la base de données principale et centralisée pour tous les comptes de service et d’utilisateur.
Dans le cloud, Microsoft Entra ID est un fournisseur d’identité centralisé et la source préférée pour la gestion de l’identité. La délégation de l’authentification et de l’autorisation à Microsoft Entra ID permet des scénarios tels que les stratégies d’accès conditionnel qui requièrent qu’un utilisateur se trouve dans un emplacement spécifique. L’authentification multifacteur est prise en charge pour augmenter le niveau de sécurité d’accès. Configurez les services du magasin de données du lac de données avec l’intégration Microsoft Entra dans la mesure du possible.
Pour les services de données qui ne prennent pas en charge Microsoft Entra ID, utilisez la clé ou le jeton d’accès pour l’authentification. Le client doit stocker la clé d’accès dans un magasin de gestion de clés, par exemple Azure Key Vault.
Les scénarios d’authentification pour l’analyse à l’échelle du cloud sont les suivants :
- Authentification utilisateur
- Authentification d’application et de service à service
Authentification utilisateur
Les utilisateurs qui se connectent à un service de données ou à une ressource doivent présenter des informations d’identification. Ces informations d’identification prouvent que les utilisateurs sont ceux qu’ils prétendent être. Ils peuvent ensuite accéder au service ou à la ressource. L’authentification permet également au service de connaître l’identité des utilisateurs. Le service décide ce qu’un utilisateur peut voir et faire une fois que l’identité est vérifiée.
Azure Data Lake Storage Gen2, Azure SQL Database et Azure Synapse prennent en charge l’intégration à Microsoft Entra. Le mode d’authentification utilisateur interactif oblige les utilisateurs à fournir des informations d’identification dans une boîte de dialogue.
Important
Ne codez pas en dur les informations d’identification de l’utilisateur dans une application à des fins d’authentification.
Authentification d’application et de service à service
Ces demandes ne sont associées à aucun utilisateur spécifique ou aucun utilisateur n’est disponible pour entrer des informations d’identification.
Authentification de service à service
Même si un service accède à un autre service sans interaction humaine, le service doit présenter une identité valide. Cette identité prouve que le service est réel. Le service faisant l’objet de l’accès peut utiliser l’identité pour déterminer ce que le service peut faire.
Pour l’authentification de service à service, la méthode recommandée pour authentifier les services Azure est les identités managées. Les identités managées pour les ressources Azure permettent l’authentification auprès d’un service qui prend en charge l’authentification Microsoft Entra sans information d’identification explicite. Pour plus d’informations, consultez Que sont les identités managées pour les ressources Azure.
Les identités managées sont des principaux de service, qui peuvent être utilisés uniquement avec les ressources Azure. Par exemple, une identité managée peut être créée directement pour une instance Azure Data Factory. Cette identité managée est un objet inscrit sur Microsoft Entra ID. Il représente cette instance de Data Factory. Cette identité peut ensuite être utilisée pour s’authentifier auprès d’un service, tel que Data Lake Storage, sans aucune information d’identification dans le code. Azure prend en charge les informations d’identification utilisées par l’instance de service. L’identité peut accorder l’autorisation aux ressources du service Azure, par exemple un dossier dans Azure Data Lake Storage. Lorsque vous supprimez cette instance Data Factory, Azure nettoie l’identité dans Microsoft Entra ID.
Avantages liés à l’utilisation des identités managées
Les identités managées doivent être utilisées pour authentifier un service Azure auprès d’un autre service ou d’une ressource Azure. Elles présentent les avantages suivants :
- Une identité managée représente le service pour lequel elle est créée. Elle ne représente pas un utilisateur interactif.
- Les informations d’identification de l’identité managée sont entretenues, gérées et stockées dans Microsoft Entra ID. L’utilisateur n’a pas besoin de conserver un mot de passe.
- Avec les identités managées, les services clients n’utilisent pas de mots de passe.
- L’identité managée affectée par le système est supprimée lors de la suppression de l’instance de service.
Ces avantages signifient que les informations d’identification sont mieux protégées et que la compromission de la sécurité est moins probable.
Authentification d’application à service
Un autre scénario d’accès est une application, telle qu’une application web mobile, qui accède à un service Azure. Toute personne accédant à un service Azure doit fournir son identité et cette identité doit être vérifiée.
Un principal de service Azure est une alternative pour les applications et les services qui ne prennent pas en charge les identités managées pour s’authentifier auprès des ressources Azure. Un principal de service Azure est une identité créée pour une utilisation avec les applications, des services hébergés et des outils automatisés permettant d’accéder aux ressources Azure. Cet accès est limité par les rôles attribués au principal de service. Pour des raisons de sécurité, nous vous recommandons d’utiliser les principaux de service avec des applications ou des outils automatisés, plutôt que de leur permettre de se connecter avec une identité d’utilisateur. Pour plus d’informations, consultez Objets d’application et du principal de service dans Microsoft Entra ID.
Remarque
Les identités managées et les principaux de service sont créés et gérés uniquement dans Microsoft Entra ID.
Différence entre l’identité managée et le principal de service
| Principal du service | Identité managée |
|---|---|
| Identité de sécurité créée manuellement dans Microsoft Entra ID pour une utilisation par des applications, des services et des outils pour accéder à des ressources Azure spécifiques. | Type spécial de principal de service. Il s’agit d’une identité automatique qui est créée lors de la création d’un service Azure. |
| Peut être utilisé(e) par n’importe quelle application ou n’importe quel service. N’est pas lié(e) à un service Azure spécifique. | Représente une instance de service Azure. Ne peut pas être utilisé(e) pour représenter d’autres services Azure. |
| A un cycle de vie indépendant. Doit être supprimé(e) explicitement. | Fait l’objet d’une suppression automatique quand l’instance de service Azure est supprimée. |
| Authentification par mot de passe ou par certificat. | Aucun mot de passe explicite à fournir pour l’authentification. |
Authentification et autorisations de la base de données
L’analyse à l’échelle du cloud contient probablement un stockage Polyglot. Exemples : PostgreSQL, MySQL, Azure SQL Database, SQL Managed Instance et Azure Synapse Analytics.
- Utiliser Microsoft Entra ID pour l’authentification avec PostgreSQL
- Utiliser l’authentification Microsoft Entra auprès d’Azure SQL Database, SQL Managed Instance et Azure Synapse Analytics
- Utiliser Microsoft Entra ID pour l’authentification avec 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. Utilisez ces groupes Microsoft Entra pour authentifier les utilisateurs et protéger les objets de base de données. À l’instar du modèle du lac de données, vous pouvez utiliser votre intégration d’application de données pour créer ces groupes.
Notes
Les applications de données peuvent stocker des produits de données sensibles dans des pools Azure SQL Database, SQL Managed Instance ou Azure Synapse Analytics. Pour plus d’informations, consultez Données sensibles.
Sécurité d’Azure Data Lake dans l’analyse à l’échelle du cloud
Pour contrôler l’accès aux données dans le lac de données, nous vous recommandons d’utiliser la liste de contrôle d’accès (ACL) au niveau des fichiers et des dossiers. Azure Data Lake adopte également un modèle de liste de contrôle d’accès de type POSIX. POSIX (Portable Operating System Interface) est une famille de standards pour les systèmes d’exploitation. Un standard définit une structure d’autorisation simple mais puissante pour l’accès aux fichiers et aux dossiers. POSIX est largement adopté pour les partages de fichiers réseau et les ordinateurs Unix.
À l’instar des pratiques générales Azure RBAC, les règles suivantes doivent s’appliquer à la liste de contrôle d’accès :
Gérer l’accès à l’aide de groupes. Affecter l’accès à des groupes Microsoft Entra et gérer l’appartenance aux groupes pour la gestion en continu de l’accès. Consultez Contrôle d’accès et configurations de lacs de données dans Azure Data Lake Storage.
Séparation des privilèges. Dans la plupart des cas, les utilisateurs doivent disposer d’une autorisation de lecture uniquement sur les dossiers et les fichiers dont ils ont besoin dans le lac de données. Une identité managée ou un principal de service, tel que celui utilisé par Azure Data Factory, a des autorisations de lecture, d’écriture et d’exécution. Les utilisateurs de données ne doivent pas avoir accès au conteneur du compte de stockage.
Aligner sur le schéma de partitionnement des données. La conception de la liste de contrôle d’accès et de la partition de données doit s’aligner pour garantir le contrôle d’accès aux données. Pour plus d’informations, consultez [Partitionnement du lac de données].