Organiser ses comptes cloud et sa hiérarchie

La frontière la plus solide du cloud n'est ni un réseau ni une politique d'accès : c'est le compte. Ce qui vit dans un compte ne peut pas toucher ce qui vit dans un autre sans qu'on l'ait explicitement autorisé, et c'est la seule séparation qu'une erreur de manipulation ne franchit pas. Cette leçon montre où placer ces frontières, quelle hiérarchie poser au-dessus, et ce qu'une zone d'atterrissage automatise une fois la structure décidée.

Ce que vous allez apprendre

Découper en comptes plutôt qu'en conventions de nommage.
Choisir la hiérarchie qui portera vos règles, et pourquoi elle décide de leur portée.
Comprendre ce qu'est une zone d'atterrissage, et ce qu'elle ne dispense pas de faire.

Séparer par comptes, pas par bonne volonté

La frontière la plus solide entre deux environnements est un compte séparé. Tout le reste, préfixes de noms, conventions, étiquettes, repose sur la discipline de chacun, et la discipline finit toujours par céder un vendredi soir.

Un compte dédié apporte trois avantages qu'aucune convention ne donne :

Une erreur ordinaire ne traverse pas. Une commande de suppression lancée dans le mauvais terminal détruit la recette, pas la production, parce que les identifiants ne portent pas jusque-là.
Le cloisonnement des permissions devient l'état par défaut, et l'ouvrir demande un geste explicite.
La facture est ventilée d'office, sans dépendre d'un étiquetage correct.

Attention à ne pas confondre cette frontière avec une isolation absolue. Les accès entre comptes existent et sont même courants : rôles assumés d'un compte à l'autre, fédération d'identité, services partagés, réseaux interconnectés. Un compte séparé garantit qu'aucun accès n'existe tant que personne ne l'a créé ; il ne vous protège pas d'un accès délibérément ouvert, ni d'une identité fédérée qui porte trop de droits.

C'est déjà considérable : la question passe de « qui a pensé à ne pas se tromper » à « qui a signé cette ouverture ».

Découpage	Quand il convient
Un compte par environnement	le choix par défaut, dès qu'il y a une production
Un compte par équipe	quand plusieurs équipes travaillent sans se coordonner
Un compte par projet	quand la refacturation client l'exige
Tout dans un seul compte	seulement pour un usage personnel ou un apprentissage

Le vocabulaire change selon le fournisseur, et les objets ne se correspondent pas exactement : compte chez AWS et OUTSCALE, souscription chez Azure, projet chez Google Cloud et Scaleway. Ils jouent un rôle voisin de frontière administrative et de facturation, mais leurs propriétés diffèrent, à commencer par la profondeur de hiérarchie au-dessus d'eux. La facturation reste consolidée au niveau de l'organisation, donc séparer ne complique pas le paiement.

Quelle hiérarchie mettre au-dessus des comptes ?

Au-delà d'une dizaine de comptes, il faut un étage supplémentaire pour appliquer une règle à un ensemble d'un seul geste. Tous les fournisseurs proposent une structure parente, avec un vocabulaire différent et surtout une profondeur différente : c'est ce dernier point qui change ce que vous pouvez faire.

Fournisseur	Le conteneur racine	Niveaux intermédiaires	L'unité de travail
AWS	Organisation	unités d'organisation, imbricables	compte
Azure	tenant Entra ID	groupes d'administration, imbricables	souscription
Google Cloud	organisation	dossiers, imbricables	projet
Scaleway	Organization	aucun	Project

Les niveaux intermédiaires font toute la différence à l'échelle. Sans eux, une règle se pose compte par compte, donc elle est oubliée sur celui créé la semaine dernière. Avec eux, vous rangez les comptes par nature et la règle s'applique à la branche entière, y compris aux comptes futurs. Chez un fournisseur à deux niveaux comme Scaleway, cette absence n'est pas un défaut tant que vous restez sous quelques dizaines de projets, mais elle se paie en répétition ensuite. La hiérarchie Organization et Project de Scaleway détaille ce modèle plat.

Voici un découpage qui tient dans la durée, et qui n'est pas celui de l'organigramme : on range par nature de risque, pas par direction hiérarchique, parce que les équipes se réorganisent plus souvent que les niveaux de criticité.

Organisation
├── Infrastructure                 services communs à tous les autres
│   ├── compte réseau              interconnexions, plan d'adressage
│   ├── compte journalisation      réception seule, aucune suppression possible
│   └── compte sécurité            lecture sur tous les comptes, pour l'audit
├── Production
│   ├── compte produit-a
│   └── compte produit-b
├── Hors production
│   ├── compte recette
│   └── compte développement
└── Bac à sable                    plafond de dépense strict, purge périodique

Le compte de journalisation mérite une attention particulière. Il reçoit les traces des autres comptes, et personne n'y détient le droit de supprimer, pas même les administrateurs des comptes émetteurs. C'est exactement ce qui rend un journal exploitable après un incident : un attaquant qui obtient les pleins pouvoirs sur un compte de production n'atteint pas l'historique de ce qu'il y a fait. Un journal qu'un administrateur compromis peut effacer ne prouve rien.

Qu'est-ce qu'une zone d'atterrissage ?

Une zone d'atterrissage est l'ensemble minimal préparé avant que les équipes créent la moindre ressource. Le terme est intimidant, l'idée ne l'est pas : c'est la réponse à la question « comment livrer un compte déjà prêt, sans repartir de zéro à chaque fois ». Les fournisseurs vendent des outils dédiés, mais le concept ne dépend d'aucun d'eux.

Le problème qu'elle résout est très concret. Sans elle, la dixième équipe arrivée recrée un réseau à sa façon, avec des plages d'adresses qui chevauchent celles des voisins, sans journalisation ni étiquetage. Personne ne s'en aperçoit avant la première interconnexion, c'est-à-dire au pire moment, quand il faut renuméroter un environnement déjà en service.

La structure et les identités

La hiérarchie de comptes décrite plus haut, et la fédération avec l'annuaire d'entreprise. Personne ne crée d'identité locale : les accès viennent de l'annuaire, et le départ d'une personne s'y traite une seule fois, comme le développe la page sur les identités et les accès.
Le plan d'adressage central

Un tableau qui attribue une plage à chaque compte, tenu à un seul endroit et avant toute création. C'est la condition pour qu'une interconnexion future soit possible, ainsi que l'explique la leçon sur la connectivité hybride.
La journalisation centralisée

Activée à la création du compte, pas après, et dirigée vers le compte dédié en écriture seule. Un compte dont la journalisation est activée trois mois plus tard a trois mois d'angle mort.
Les garde-fous

Les quatre règles ci-dessus, en mode observation d'abord, puis en blocage.
Le modèle de compte, décrit en code

Le tout exprimé sous forme d'infrastructure as code, pour qu'un nouveau compte naisse configuré plutôt que d'être configuré après coup. C'est ce dernier point qui sépare une vraie zone d'atterrissage d'une procédure écrite que personne ne suit intégralement.

Le point d'arrivée porte un nom : la fabrique de comptes. Une fois ces cinq éléments décrits en code, la création d'un compte cesse d'être un projet pour devenir une demande traitée en quelques minutes, avec toujours la même configuration. C'est ce qui fait qu'une équipe nouvelle obtient un environnement conforme sans négocier, et donc qu'elle ne construit plus le sien en marge.

Ne construisez pas tout cela avant d'en avoir besoin. Pour deux comptes et une seule équipe, c'est de la bureaucratie qui ralentit sans rien protéger. Le bon moment se reconnaît à un signe simple : quand vous créez le troisième ou le quatrième compte et que vous recopiez les mêmes réglages à la main, la zone d'atterrissage devient rentable, et chaque compte suivant la rentabilise davantage.

Prochaines étapes

Garde-fous et étiquetage La hiérarchie que vous venez de poser ne sert à rien tant qu'aucune règle n'y est attachée.

Maîtriser la facture cloud Le découpage en comptes est aussi ce qui rend la dépense attribuable.

Gérer les identités et les accès Qui peut faire quoi dans chacun de ces comptes, et comment les accès entre comptes fonctionnent.

Cloud Adoption Frameworks Les cadres d'adoption des fournisseurs, lus de façon critique.