Lors d’un déploiement cloud, un compte peut recevoir des permissions temporaires pour créer des ressources ou modifier le réseau. La configuration des accès doit prévoir leur expiration et distinguer ce compte des identités utilisées par les applications. Le retrait des permissions peut être vérifié sans interrompre les jobs qui doivent continuer à fonctionner.
Prenons une organisation avec une production, une préproduction, un prestataire engagé pour trois mois et un pipeline de déploiement. Elle doit décider sur quelles ressources chacun intervient, quand ses privilèges expirent et comment vérifier les opérations. Google Cloud, Azure, AWS et Infomaniak proposent des mécanismes différents pour répondre à ces mêmes besoins.
1. Définir le périmètre des autorisations
La comparaison porte sur les permissions du control plane cloud, utilisé pour créer l’infrastructure, modifier les configurations et administrer les identités. Les autorisations de consultation des dossiers dans une application sont définies séparément par ses rôles et ses règles d’accès.
Sur Google Cloud, la hiérarchie comprend l’organisation, des dossiers facultatifs, les projets et les ressources. Des autorisations attribuées à un niveau supérieur peuvent s’appliquer aux ressources qu’il contient. L’équipe examine donc les droits directs et hérités, avec les politiques de refus et les conditions éventuelles. La documentation IAM décrit cette évaluation.
Azure distingue les rôles de l’annuaire Microsoft Entra et les rôles Azure RBAC sur les ressources. Les premiers administrent les identités et certains paramètres de l’annuaire ; les seconds portent sur les groupes de gestion, les abonnements, les groupes de ressources et les ressources. Un rôle dans l’un de ces systèmes ne décrit pas automatiquement les droits dans l’autre. Microsoft présente les attributions et leurs étendues.
AWS organise une séparation importante autour des comptes. Les politiques SCP et RCP de l’organisation peuvent limiter des permissions sans les accorder elles-mêmes. Les droits effectifs dépendent ensuite des politiques concernées, de l’identité et du contexte de la demande. Un refus explicite applicable prévaut, mais une formule générale d’union et d’intersection ne suffit pas à expliquer tous les cas. L’équipe suit les règles d’évaluation AWS pour le scénario testé.
Sur Infomaniak Public Cloud, la gestion des utilisateurs OpenStack est organisée par projet. L’équipe doit distinguer ces identités de celles du Manager qui administrent les produits et les contrats. Une séparation entre deux projets ne neutralise pas les pouvoirs d’un compte disposant de droits plus larges sur le produit.
Dans les quatre cas, des groupes nommés selon la population et l’accès rendent les attributions plus lisibles. Un groupe de collaborateurs et un groupe autorisant la lecture d’une application décrivent deux faits distincts. Le rôle retenu doit permettre le travail prévu sans ouvrir des actions inutiles ; les exceptions ont un responsable et une date de réexamen.
2. Limiter la durée des accès privilégiés
Pour le prestataire de notre exemple, l’authentification et l’autorisation répondent à deux questions. La première vérifie la connexion ; la seconde détermine les actions possibles. Une authentification forte ne limite pas, à elle seule, la durée pendant laquelle le prestataire peut administrer la production.
Google Cloud propose Privileged Access Manager pour organiser des droits temporaires, avec les conditions de demande et d’approbation retenues. L’équipe définit le rôle, le périmètre, la durée et les personnes pouvant approuver l’élévation.
Azure propose Privileged Identity Management pour rendre une personne éligible à un rôle et encadrer son activation. Une justification, une approbation ou une authentification supplémentaire peuvent accompagner cette activation. Les fonctions PIM et les licences nécessaires doivent être vérifiées pour les utilisateurs, approbateurs et réviseurs concernés.
AWS utilise notamment des sessions et des identifiants temporaires. Ce mécanisme ne décrit pas nécessairement le circuit qui autorise une personne à demander un privilège supplémentaire. La documentation IAM Identity Center présente les possibilités d’accès élevé temporaire et des solutions partenaires. L’organisation choisit le processus d’approbation qu’elle peut réellement exploiter.
La documentation d’Infomaniak ne présente pas le même dispositif intégré d’activation temporaire des rôles Keystone. L’organisation peut devoir prévoir un retrait explicite et sa vérification. L’absence d’une fonction documentée demande une clarification avec le fournisseur lorsqu’elle conditionne le projet ; elle ne prouve pas l’impossibilité de construire un contrôle complémentaire.
La procédure doit aussi prévoir les accès d’urgence. L’équipe teste leur utilisation et leur retour à un état normal. Un compte de secours sans propriétaire ni surveillance peut annuler une partie des protections apportées aux accès ordinaires.
3. Donner une identité propre aux programmes
Le pipeline de déploiement ne doit pas dépendre du compte personnel d’un collaborateur. Son identité décrit les actions nécessaires au traitement et les ressources visées. L’équipe conserve son responsable, sa méthode d’authentification et les conditions de retrait.
Sur Google Cloud, un compte de service rattaché à une ressource peut obtenir les jetons nécessaires. Pour un traitement extérieur, Workload Identity Federation permet d’établir une confiance avec une identité externe selon les conditions configurées. Cette approche peut éviter de distribuer une clé de longue durée. Google distingue les types d’identités de charge de travail.
Les identités managées Azure évitent à l’application de stocker et gérer elle-même des secrets d’authentification. Une identité attribuée par le système suit le cycle de vie de sa ressource ; une identité attribuée par l’utilisateur peut lui survivre et servir plusieurs ressources. Cette différence influence la responsabilité et le retrait des droits.
Sur AWS, des rôles IAM peuvent fournir des identifiants temporaires aux services de calcul. Pour une charge extérieure, la fédération et IAM Roles Anywhere répondent à d’autres configurations. Le choix dépend de l’identité disponible et des relations de confiance. Toute clé durable demande une justification. L’équipe organise sa protection et son renouvellement.
Infomaniak propose des identifiants d’application OpenStack. Ils évitent d’utiliser le mot de passe d’une personne dans le programme. L’équipe vérifie les rôles associés et la date d’expiration. Les règles d’accès peuvent limiter les services, méthodes et chemins accessibles. Le secret doit être conservé dans un dispositif adapté, puisque son affichage initial ne constitue pas une sauvegarde.
Une identité dédiée ne garantit pas des permissions minimales. Le test exécute une action nécessaire et tente une action qui doit être refusée. Pour un traitement de sauvegarde, par exemple, les droits de création des copies et ceux de suppression doivent correspondre au scénario de protection retenu.
4. Relier les accès à leur historique et à leur retrait
Un inventaire répond à la question des droits présents. Il ne reconstitue pas automatiquement les autorisations d’une date passée. L’organisation doit distinguer les attributions, les connexions et les opérations sur les ressources, puis préciser les journaux nécessaires.
Google Cloud associe notamment des outils d’analyse de politiques et Cloud Audit Logs. Les résultats de Policy Analyzer et les catégories de journaux ont leurs limites et leurs conditions d’activation. La documentation précise le périmètre de l’analyse.
Azure distingue les journaux de l’annuaire et le journal d’activité des ressources. L’historique d’activité Azure a une conservation native limitée, que l’export peut compléter. Les révisions d’accès organisent une confirmation du besoin par les personnes désignées.
AWS fournit CloudTrail et des informations d’utilisation qui aident à examiner les accès et à ajuster les politiques. Un historique d’actions reste toutefois lié aux services, régions et catégories d’événements effectivement collectés. Il ne remplace pas un inventaire complet des autorisations.
Pour Infomaniak, l’organisation examine les listes d’utilisateurs, les rôles et les identifiants d’application, puis les événements disponibles selon les services. Les journaux d’opérations du fournisseur et les preuves de ses propres applications ne répondent pas à la même question. Les conditions Public Cloud et la documentation permettent de préciser cette répartition.
Personnes et organisation
Annuaire de l’entreprise
Présence dans l’entreprise et groupes métier
SSO et SCIM · offre Enterprise
Connexion et création des comptes pour les services Infomaniak compatibles
Manager Infomaniak et kSuite
Organisation, contrat et administration des produits
La documentation d’Infomaniak ne décrit aucune création automatique des comptes OpenStack à partir de l’annuaire. Lors d’un départ, l’entreprise doit donc supprimer séparément chaque accès OpenStack.
Infrastructure Public Cloud
Utilisateur OpenStack / Keystone
Compte distinct créé pour un seul projet
Rôle et projet
Droits reader, member ou rôle spécialisé
Projet Public Cloud
Serveurs, stockage, réseau et commandes techniques
Le schéma distingue les identités du Manager, de kSuite et d’OpenStack pour vérifier chaque accès lors du retrait d’un compte. La documentation d’identité Infomaniak décrit également des différences entre régions. Dans dc3-a, reader inclut des permissions équivalentes à member, tandis que dans dc4-a, member n’inclut pas automatiquement reader. Les tests d’autorisation utilisent donc la région du déploiement.
Comparer les plateformes sur le travail à réaliser
Le choix peut maintenant porter sur des exigences communes plutôt que sur une liste de fonctions isolées.
| Décision | Google Cloud | Azure | AWS | Infomaniak Public Cloud |
|---|---|---|---|---|
| Périmètre | Hiérarchie et héritage IAM | Étendues RBAC et annuaire distinct | Comptes et combinaison des politiques | Projets OpenStack et administration du produit |
| Privilèges temporaires | PAM | PIM, selon licences | Sessions temporaires et circuit d’élévation à préciser | Retrait et contrôle à organiser selon les fonctions disponibles |
| Programmes | Comptes de service et fédération | Identités managées et fédération | Rôles et fédération | Identifiants d’application |
| Suivi | Analyse des politiques et journaux | Révisions, journaux Entra et Azure | CloudTrail et analyse des accès | Inventaires et événements à compléter selon le besoin |
L’estimation distingue la configuration des fonctions natives, l’intégration d’outils complémentaires et le travail d’exploitation des procédures retenues. Elle vérifie les licences, la collecte des preuves et la capacité de son équipe à tenir ce fonctionnement dans la durée.
La résidence suisse et les interfaces OpenStack peuvent compter dans le choix d’Infomaniak. Les mécanismes de gouvernance intégrés d’autres plateformes peuvent répondre à des exigences différentes. Aucun de ces avantages ne dispense de tester les droits réellement accordés et retirés.
Pour le prestataire de l’exemple, la revue des accès vérifie les ressources autorisées et l’expiration des permissions élevées. Elle contrôle aussi l’identité de service du pipeline et le retrait des comptes à la fin du mandat. L’application de ces contrôles à chaque fournisseur permet de comparer les quatre architectures.
Les fonctions et les offres peuvent évoluer. La conception doit reprendre la documentation des services, des régions et des niveaux de licence choisis au moment du déploiement.