Les accès cloud sur Google Cloud, Azure, AWS et Infomaniak

Note du 9 septembre 2026 : je construis sur Azure et Google Cloud ; AWS figure dans cet article comme terme de comparaison, les quatre décisions se lisant mieux sur quatre plateformes que sur deux.

Tous les problèmes d’accès dont j’hérite commencent par une exception raisonnable. Quelqu’un doit terminer un déploiement un vendredi soir, reçoit Owner sur tout l’abonnement, et le détient encore deux ans plus tard. Personne ne le retire, faute de savoir quel service s’arrêterait.

La réparation ne passe pas par un produit de sécurité de plus. Elle tient en quatre décisions : qui reçoit un droit, sur quelles ressources, pour combien de temps, et quelle trace le prouvera plus tard. Google Cloud, Azure, AWS et Infomaniak vous tendent des instruments très différents pour trancher, et l’un des quatre en manque la plupart.

Le sujet ici est le plan de contrôle du cloud : les droits qui créent, modifient ou suppriment l’infrastructure et qui administrent les autres identités, pas les permissions internes à une application métier. L’entreprise des exemples est suisse, de 10 à 50 personnes : une petite équipe technique, une production et une préproduction, un prestataire sous mandat de trois mois, un pipeline de déploiement qui tourne sans compte humain, et un travail de sauvegarde dont les identifiants ne peuvent rien supprimer.

Les quatre décisions

1. La plus petite étendue utile : Accordez le rôle sur l’ensemble de ressources le plus étroit qui laisse encore travailler. Un administrateur de projet peut détruire toutes les ressources du projet ; celui qui n’a qu’un espace de stockage, non. L’étendue réduite limite ce qu’un compte volé atteint, sans empêcher le vol lui-même.
2. Des groupes qui décrivent des personnes, des groupes qui décrivent des droits : org.finance nomme une population, acces.prod-facturation-lecture nomme un droit sur un système, et le premier alimente le second quand tous ses membres en ont besoin. Le réviseur lit les deux faits sur ces noms ; utilisateurs-azure n’en donne aucun.
3. Un rôle standard, et l’exception nommée : Partez d’un rôle que le fournisseur entretient, et n’écrivez un rôle sur mesure que lorsqu’un rôle standard ouvre une action sensible dont la fonction n’a pas besoin. Donnez à cette exception un propriétaire et une date de réexamen.
4. Une identité par programme : Notez son propriétaire, son usage, son étendue, son mode d’authentification, sa dernière utilisation et sa condition de retrait. Préférez une identité rattachée à la ressource, ou fédérée, qui reçoit un jeton de courte durée, à une clé posée dans le code.

Les quatre plateformes côte à côte

Où s’applique un droit

Google Cloud empile les ressources sous une organisation, des dossiers facultatifs et des projets. Un rôle accordé sur un conteneur atteint tout ce qu’il contient : les droits effectifs additionnent donc ce qui est posé sur la ressource et ce qui est posé sur ses parents. Une règle de refus bloque au besoin des permissions qu’une règle d’autorisation accorde ailleurs. Google documente la hiérarchie et le modèle d’héritage.

Azure fait tourner deux systèmes que tout le monde confond. Les rôles Entra administrent l’annuaire lui-même : utilisateurs, groupes, applications enregistrées, règles de connexion. Azure RBAC administre les ressources, le long d’une hiérarchie de groupes de gestion, d’abonnements, de groupes de ressources et de ressources. Un Global Administrator ne commande pas automatiquement un abonnement ; Microsoft prévoit une élévation d’urgence pour en récupérer un, à désactiver aussitôt après. Le modèle Azure RBAC décrit les étendues et les types d’identités, et Microsoft documente l’élévation et son retrait.

AWS fait du compte la vraie frontière, et regroupe les comptes en unités organisationnelles sous une organisation. Ce qui descend, c’est le plafond, pas le droit : les politiques de contrôle de service et les politiques de contrôle des ressources limitent ce qu’un compte peut faire et n’accordent rien par elles-mêmes. Un droit effectif est l’intersection de la politique d’identité, de la SCP, de la RCP et d’une éventuelle limite d’autorisations, réunie avec une politique de ressource, et un refus explicite l’emporte d’où qu’il vienne. AWS expose cette logique d’évaluation, et recommande les SCP et les RCP comme garde-fous à l’échelle de l’organisation. Lire une seule politique ne dit donc jamais ce qu’une personne peut faire.

Infomaniak Public Cloud n’a qu’un niveau : le projet. Rien au-dessus ne transmet de droits, rien en dessous ne les subdivise, et chaque utilisateur OpenStack appartient à un seul projet. La séparation passe par la création d’un autre projet, non par le rétrécissement d’une étendue. Le guide des utilisateurs Public Cloud confirme la séparation et la limite à un projet.

L’entrée, et la durée des privilèges

Les conditions de connexion relèvent du fournisseur d’identité sur les quatre plateformes, et l’autorisation décide de la suite ; confondre les deux produit des rôles étroits atteints par une connexion mal protégée. La vraie différence entre les quatre tient à la durée pendant laquelle un administrateur reste administrateur.

Google Cloud a Privileged Access Manager : un droit délivré pour une durée fixe, avec une justification et, si vous le voulez, une approbation. Google le documente.

Azure a Privileged Identity Management : la personne est éligible à un rôle au lieu de le détenir, l’active pour une durée limitée en donnant un motif, et peut devoir passer une approbation et une authentification multifacteur. La fonction exige Microsoft Entra ID P2 ou Entra ID Governance, sous licence pour les personnes qui détiennent des droits éligibles ou temporaires ainsi que pour leurs approbateurs et réviseurs, et non par définition de rôle. Microsoft décrit les contrôles et les catégories de licence.

AWS part d’identifiants de courte durée : une personne se fédère par IAM Identity Center et endosse un rôle le temps d’une session, si bien que rien de durable ne circule. Ce qu’AWS ne livre pas, c’est le circuit de demande et d’approbation autour. Sur la façon d’élever un droit pour une heure puis de le reprendre, sa documentation nomme des solutions partenaires validées plutôt qu’une fonction maison : Apono, CyberArk, Okta Access Requests et Tenable. AWS l’écrit sur la page IAM Identity Center.

Infomaniak n’a rien de tel : un rôle Keystone reste en place jusqu’à ce que quelqu’un le retire à la main, sans approbation, sans échéance et sans révision documentées. La double authentification protège Manager pour toute l’Organisation, et les utilisateurs OpenStack peuvent activer un code temporaire pour Keystone, ce qui empêche un mot de passe volé d’ouvrir une session et ne change rien au rôle qui se trouve derrière. Infomaniak documente la double authentification pour l’Organisation et la procédure TOTP pour Keystone.

L’authentification d’un programme

Dans Google Cloud, un programme utilise un compte de service rattaché à sa ressource et reçoit un jeton de courte durée ; hors de Google Cloud, Workload Identity Federation échange une preuve délivrée par AWS, Azure ou GitHub contre des identifiants Google de courte durée. La clé JSON téléchargée est justement ce qu’il vaut mieux éviter : quiconque copie le fichier agit sous ce compte jusqu’à la désactivation de la clé, et une règle d’organisation interdit au besoin toute création de clé. Google distingue les cas rattaché, fédéré et externe.

Les identités managées d’Azure obtiennent un jeton Entra sans qu’aucun mot de passe, certificat ni clé soit stocké nulle part. L’identité attribuée par le système naît et meurt avec sa ressource ; celle attribuée par l’utilisateur lui survit et sert au besoin plusieurs ressources, d’où l’attention plus soutenue que méritent son propriétaire et son étendue. Un système de déploiement externe présente au besoin un identifiant fédéré à la place du secret d’une application. Microsoft explique les deux types.

AWS remet les identifiants d’un rôle IAM directement au service de calcul : rien de durable n’atteint une application qui tourne sur EC2 ou Lambda. Hors d’AWS, trois voies documentées : IAM Roles Anywhere avec un certificat X.509 issu de votre propre infrastructure de clés, AssumeRoleWithSAML, et AssumeRoleWithWebIdentity pour une plateforme d’intégration continue porteuse d’un jeton web JSON. Les clés d’accès de longue durée ne survivent que pour des exceptions nommées. AWS énonce la règle pour les programmes.

Infomaniak délivre un identifiant d’application : le programme reçoit son propre identifiant au lieu d’emprunter le mot de passe d’une personne. La commande de création accepte une date d’expiration, les règles d’accès le restreignent à des services, des méthodes et des chemins précis, et le secret n’apparaît qu’une fois. Un programme de surveillance reçoit GET sur le chemin qui liste les serveurs, et rien d’autre. Infomaniak documente l’échéance et l’affichage unique du secret.

Les preuves que vous pouvez produire après coup

Les quatre plateformes vous disent qui détient un droit à l’instant présent. Elles diffèrent sur ce qu’elles disent de mars dernier.

Google Cloud liste les détenteurs actuels avec Policy Analyzer, sans délai de mise à jour promis et sans couvrir les mécanismes situés hors de l’autorisation : lisez le résultat comme un état, non comme un historique. Cloud Audit Logs porte les opérations d’administration, et certains journaux d’accès aux données demandent une activation explicite. Azure ajoute des révisions d’accès qui obligent un propriétaire à confirmer un besoin avant le retrait des droits refusés, et garde le journal d’activité 90 jours si vous ne l’exportez pas. AWS produit une politique resserrée à partir de ce que CloudTrail a réellement enregistré, et ses informations de dernier accès font apparaître les rôles et les identifiants dont plus personne ne se sert. Google énonce les limites de Policy Analyzer, Microsoft les révisions et le journal d’activité, AWS sa propre pratique.

Infomaniak liste les utilisateurs OpenStack, leurs rôles par projet et les identifiants d’application : les droits qui existaient le jour de l’export, et rien de plus. Les conditions promettent les journaux d’événements des instances et une conservation d’un an pour les actions des administrateurs d’Infomaniak, et vous laissent les preuves venues de vos propres systèmes. Aucun rapport historique prêt à l’emploi ne couvre les droits Keystone : l’organisation tenue de montrer l’état des accès à une date passée construit donc cet export elle-même, et en valide les champs et la durée de conservation avant de signer. L’article 7 des conditions Public Cloud fixe ces limites.

L’écart Infomaniak, sans détour

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

Infomaniak Public Cloud tourne sur OpenStack, et les conditions en vigueur indiquent que les données des clients restent exclusivement dans des centres de données suisses qui appartiennent à Infomaniak. Voilà le gain réel, avec une API d’infrastructure documentée et largement répandue à la place de celle d’un seul éditeur : la résidence suisse et la portabilité. Infomaniak présente la plateforme et le contrat dit où les données se trouvent.

Souverain ne veut pas dire sûr par défaut, et quatre choses que vous faites sur les trois autres plateformes n’ont ici aucun équivalent.

Une personne, deux comptes

Manager et kSuite portent le contrat et les produits ; OpenStack porte les identités du cloud, et Infomaniak indique que les deux populations n’ont aucun rapport. La connexion unique et l’approvisionnement automatique des comptes par SAML 2.0 et SCIM 2.0 existent dans la seule offre kSuite Enterprise, et rien de publié n’indique que SCIM touche aux comptes Keystone. Chaque arrivée et chaque départ font donc deux opérations, et oublier la seconde laisse un compte cloud actif derrière un annuaire fermé. Le comparatif réserve la fonction à Enterprise et le guide SSO nomme les fournisseurs compatibles.

Un second projet n’est pas une frontière d’autorisation

Il sépare assez utilement la production, la préproduction et des clients distincts, mais un compte Manager suffisamment privilégié administre encore le produit Public Cloud et tous les projets qu’il contient.

Les rôles publiés sont les rôles que vous aurez

Infomaniak publie reader, member, SwiftOperator, creator et des rôles de répartiteur de charge, et le guide d’identité actuel ne documente aucun moyen pour un client de définir de nouveaux rôles Keystone. Leur comportement change aussi d’une région à l’autre : dans dc3-a, le reader documenté inclut des permissions équivalentes à member, alors que dans dc4-a, member n’emporte pas automatiquement reader. Testez une action autorisée et une action interdite dans la région où vous déployez vraiment. Le guide d’identité liste les rôles et les services qu’ils couvrent.

Personne ne sauvegarde à votre place

Les conditions Public Cloud indiquent qu’Infomaniak ne crée aucune sauvegarde automatique des données du client. Une reprise exige un compte d’écriture incapable de supprimer les copies conservées, au moins une copie sous des identifiants que les administrateurs de production ignorent, et une restauration déjà exécutée et chronométrée. Infomaniak propose Swiss Backup ; la configuration et les tests restent chez vous.

Le choix entre les quatre

Infomaniak convient à une petite entreprise qui tient à la résidence suisse des données, à la portabilité OpenStack et à un contrat de droit suisse, sur un nombre limité de projets, et qui accepte de faire par procédure ce que les autres font par produit : deux opérations de cycle de vie au lieu d’une, des rôles privilégiés retirés à la main, des preuves qu’elle assemble elle-même.

Google Cloud et Azure conviennent à l’entreprise qui a besoin de voir expirer seuls les accès privilégiés, et de poser des règles de connexion liées à l’état de l’appareil. AWS convient à celle qui accepte de faire du compte l’unité de séparation et d’acheter ou de construire le circuit d’approbation, en échange des garde-fous les plus stricts des quatre : une SCP plafonne toute une branche de l’organisation, quoi qu’accorde un administrateur local. Qui gère des centaines de projets, ou doit reconstituer les droits à n’importe quelle date passée, chiffrera ce travail avant de comparer les abonnements.

Sources et dates de vérification

• Google Cloud : hiérarchie et héritage, présentation d’IAM, Privileged Access Manager, identités des programmes, limites de Policy Analyzer.
• Microsoft : attributions de rôles Azure, élévation d’urgence, PIM, licences Entra, identités managées, révisions d’accès, journal d’activité.
• AWS : bonnes pratiques de sécurité IAM, logique d’évaluation des politiques, accès privilégié temporaire.
• Infomaniak : Public Cloud, conditions Public Cloud, utilisateurs Public Cloud, tarifs kSuite, SSO et SCIM, identités et rôles Keystone, TOTP, identifiants d’application, double authentification.

J’ai vérifié les affirmations sur Google Cloud, Azure et Infomaniak dans la documentation des fournisseurs le 26 août 2026, et celles sur AWS le 3 septembre 2026. Les fonctions, les définitions de rôles, les niveaux de licence et les prix changent après ces dates.