Gouvernance

Reprendre la gouvernance de plusieurs centaines de comptes AWS

Le contexte

Un éditeur logiciel international avait accumulé plusieurs centaines de comptes AWS répartis entre des dizaines d’équipes projet. Chaque équipe avait fait au mieux, ce qui donnait autant de conventions que d’équipes : des règles de pare-feu incohérentes d’un compte à l’autre, des sauvegardes présentes ici et absentes là, des périmètres de sécurité impossibles à démontrer devant un auditeur, et une facture que personne ne savait expliquer entièrement.

L’objectif n’était pas de reprendre le contrôle en interdisant tout. Une gouvernance qui bloque les équipes projet est contournée dans le mois, et le résultat est pire que la situation de départ parce que les contournements ne sont pas documentés.

Ce que nous avons fait

Nous avons repris le parc et centralisé ce qui devait l’être, en laissant aux équipes projet ce qui leur appartient.

Des garde-fous écrits une fois dans l’organisation et appliqués dans chaque comptePlusieurs centaines de comptes sont rattachés à une seule racine AWS Organizations. Trois ensembles de garde-fous sont écrits de façon centrale : les service control policies, les règles de pare-feu et de WAF gérées par Firewall Manager, et les plans de rétention AWS Backup. Ils s’appliquent dans chaque compte membre sans être renégociés équipe par équipe. Chaque compte garde son équipe projet, et les constats produits sur tout le parc convergent dans une vue Security Hub unique où chaque constat est rattaché à une équipe responsable.Des garde-fous définis une fois, appliqués partoutAWS Organizations — plusieurs centaines de comptes sous une racineService control policiesgarde-fous fermesFirewall Managerrègles WAF et pare-feuAWS Backuprétention en libre-serviceAppliqué dans chaque compte — sans renégocier équipe par équipeCompte projet Aéquipe projetCompte projet Béquipe projetCompte projet Céquipe projetplusieurs centainesSecurity Hub — chaque constat rattaché à une équipe responsable
Les garde-fous s’écrivent en un seul endroit et atterrissent dans chaque compte : c’est ce qui empêche la gouvernance de redevenir une négociation. La dernière ligne est celle qui décide de tout : des milliers de constats ne valent rien tant qu’ils n’ont pas de propriétaire.
  • Centralisation de la politique de sécurité : AWS Organizations, service control policies et gestion centralisée des règles de pare-feu avec Firewall Manager, appliquées de façon homogène sans avoir à négocier compte par compte.
  • Mise en cohérence du réseau et de la protection périmétrique : conception de la connectivité inter-comptes avec Transit Gateway pour remplacer un maillage de VPC peering devenu illisible, et politiques WAF centralisées devant les applications exposées, gérées comme le reste par Firewall Manager plutôt que compte par compte.
  • Un backup as a service basé sur AWS Backup, que les dizaines d’équipes projet consomment en déclarant simplement leur besoin de rétention, sans devenir chacune spécialiste du sujet.
  • Une vue de sécurité unique avec Security Hub, agrégeant les constats de tous les comptes au lieu de les laisser dormir dans chacun. Sur un parc de cette taille, l’enjeu n’est pas de produire des alertes — il y en a des milliers — mais de les rendre exploitables : rattacher chaque constat à une équipe responsable, et suivre ce qui se corrige réellement.
  • Mise en conformité avec les exigences d’audit : traçabilité, cloisonnement des environnements, politiques de rétention, et production automatique des preuves attendues.
  • Réduction des coûts et reprise des infrastructures existantes, en commençant par les postes les plus lourds plutôt que par les plus faciles.
  • Optimisation des performances : dimensionnement des charges conteneurisées sur ECS pour absorber les pics de trafic sans surprovisionner en permanence, et reprise de la configuration des bases managées Aurora.
Connectivité inter-comptes par un seul hub Transit GatewayChaque équipe projet possède son VPC dans son propre compte, et il y en a plusieurs centaines. Plutôt que de les appairer entre eux, chaque VPC s’attache à une seule Transit Gateway. Depuis ce hub, le trafic atteint les services partagés et la sortie centralisée, les réseaux sur site via VPN ou Direct Connect, et les applications exposées placées derrière des politiques WAF gérées centralement. Ajouter un compte revient à une attache, pas à un nouveau peering avec chaque VPC existant.Connectivité inter-comptes par un seul hubVPC du compte Aéquipe projetVPC du compte Béquipe projetVPC du compte Céquipe projetplusieurs centainesTransit Gateway — un hub à la place d’un maillage de peeringServices partagéset sortie centraliséeRéseaux sur siteVPN ou Direct ConnectApplications exposéesderrière un WAF central
Un maillage de peering croît comme le carré du nombre de comptes, et c’est pourquoi l’ancien était devenu illisible. Un hub croît linéairement : une attache par compte, et les décisions de routage vivent en un seul endroit au lieu d’être réparties dans des centaines de tables.

Le résultat

La sécurité se pilote depuis un point central au lieu d’être renégociée équipe par équipe, les sauvegardes existent partout et sont testées, et l’audit s’appuie sur des preuves produites automatiquement plutôt que reconstituées dans l’urgence.

La facture a baissé. Le changement le plus durable est ailleurs : elle est redevenue explicable, ce qui permet enfin d’arbitrer.

Toutes les références

Parlez-nous directement

Écrivez-nous directement. Pas de commercial, pas d'appel de qualification. C'est l'un de nous deux qui répond, sous 24h.

contact@onescale.io

Nous répondons sous 24h, et c'est l'un de nous deux qui répond.

Basés à Lyon, nous travaillons en France, en Europe et à l’international.