La gestion des identités et des accès (IAM) détermine quelle identité peut s’authentifier et quelles actions cette identité est autorisée à effectuer sur une ressource donnée. Dans un environnement multi-cloud, un fournisseur d’identité d’entreprise peut gérer la connexion des utilisateurs, tandis qu’AWS, Azure et Google Cloud prennent chacun leurs propres décisions d’autorisation dans le cadre de leurs limites administratives respectives. Une connexion réussie n’autorise pas, en soi, une requête API vers une ressource. Sur AWS, l’authentification unique (SSO) pour les utilisateurs est généralement configurée via IAM Identity Center, et les rôles IAM associés à AWS Security Token Service (STS) délivrent les identifiants temporaires correspondants.
Une distinction pertinente s’établit entre le fournisseur d’identité, le plan de contrôle de chaque cloud et le plan de données de chaque cloud. Un plan de contrôle gère les ressources cloud et leur configuration. Un plan de données traite les requêtes adressées aux ressources elles-mêmes ; lorsqu’une telle requête est effectuée, chaque cloud évalue le principal, l’action, la ressource et les conditions applicables au sein de son propre système IAM. Bien que ces plans puissent partager des informations d’identité, ils ne partagent pas un ensemble universel d’autorisations.
Il est désormais possible de délimiter les frontières de la connexion sans pour autant présumer de l’accès aux ressources.
Les défaillances de gestion des identités et des accès (IAM) dans les environnements multi-cloud proviennent souvent de termes familiers dont la portée diffère. Un compte AWS constitue une limite administrative pour les ressources AWS. Un locataire (tenant) Azure définit la limite de l’annuaire Microsoft Entra ID, tandis que l’accès aux ressources Azure est généralement autorisé via le contrôle d’accès basé sur les rôles Azure (Azure RBAC) au niveau d’un groupe d’administration, d’un abonnement, d’un groupe de ressources ou d’une ressource spécifique. Dans Google Cloud, l’organisation et le projet offrent des périmètres distincts pour l’association de stratégies Cloud IAM et la propriété des ressources.
Cette distinction est importante car l’appartenance à une identité ne constitue pas une autorisation d’accès à une ressource. Dans Azure, Microsoft Entra ID peut authentifier un utilisateur et indiquer son appartenance à un groupe, mais Azure RBAC doit tout de même attribuer un rôle approprié pour autoriser l’action Azure demandée. Dans AWS, les stratégies AWS IAM et les informations d’identification AWS STS (Security Token Service) interviennent dans le processus d’autorisation AWS. Dans Google Cloud, Cloud IAM évalue les associations de stratégies pour la hiérarchie de ressources concernée. Des noms de groupes similaires ne confèrent pas des droits d’accès équivalents d’un périmètre à l’autre.
Les preuves opérationnelles sont soumises aux mêmes limites de périmètre. Un événement de connexion auprès du fournisseur d’identité de l’entreprise peut confirmer l’authentification, mais ne suffit pas à prouver qu’AWS, Azure ou Google Cloud a autorisé une requête API ultérieure. Un journal d’audit cloud peut révéler une tentative d’appel API (au niveau du plan de contrôle ou de la ressource) dans ce cloud, sans pour autant garantir l’exactitude des données de cycle de vie gérées par le fournisseur d’identité de l’entreprise. Il est nécessaire de disposer de preuves provenant du plan ayant pris la décision, incluant l’identité, la ressource, l’action et la fenêtre temporelle concernées.
Règle de décision Analysez les accès cloud par cloud et requête par requête. Commencez par identifier le principal, la ressource cible, l’action API et le plan d’autorisation ayant effectué l’évaluation.
Nous allons utiliser une charge de travail délimitée plutôt que de traiter toutes les identités de la même manière. Le service orders-api écoute sur le port 8080. Une identité de type « workforce » (utilisateur interne), orders-workforce-user, représente un opérateur nécessitant un accès interactif via le fournisseur d’identité de l’entreprise. Le groupe app-operators correspond au rôle opérationnel prévu, tandis que le groupe cloud-admins est volontairement distinct, car l’accès administratif implique un niveau de risque et un processus d’approbation différents.
L’identité automatisée est orders-ci ; elle représente une tâche d’intégration continue chargée de déployer ou de gérer la charge de travail. Ses requêtes ne correspondent pas à des sessions de navigation utilisateur. Elle reçoit des informations d’identification fédérées à courte durée de vie pour chaque cloud, plutôt que de conserver des clés d’accès cloud à longue durée de vie. Les périmètres de nos fournisseurs sont le compte AWS dev, le tenant Azure contoso et le projet Google Cloud orders-prod ; toute demande d’autorisation ultérieure devra désigner explicitement l’une de ces cibles.
Nous pouvons désormais examiner la manière dont les chemins d’identité des collaborateurs et de l’intégration continue (CI) accèdent à chaque cloud.