Consultant AWS : auditer, structurer et sécuriser vos comptes

Les symptômes d’un environnement AWS à reprendre

Beaucoup d’environnements AWS commencent par un compte unique, ouvert pour un premier projet. Puis viennent un deuxième compte, des accès donnés en urgence, des ressources créées à la main dans la console. Quelques années plus tard, les mêmes questions reviennent :

• personne ne sait dire avec certitude qui peut administrer quoi ;
• la production et les tests partagent le même compte ou le même réseau ;
• les journaux d’activité ne sont pas centralisés, ou pas conservés assez longtemps ;
• une partie de l’infrastructure n’existe que dans la console et ne peut pas être reconstruite ;
• la facture progresse sans que l’on puisse l’attribuer à une équipe ou un produit.

Ce ne sont pas des fautes, ce sont les effets normaux d’une croissance sans fondation commune. Feekr, basé à Villeneuve-d’Ascq près de Lille, intervient pour remettre de l’ordre sans arrêter la production. Notre fondateur conçoit et exploite des infrastructures AWS entièrement en Infrastructure as Code, y compris pour de l’hébergement de données de santé (HDS).

Audit AWS : un état des lieux priorisé

L’audit AWS est souvent notre point d’entrée. Il couvre :

• Organisation et comptes : structure AWS Organizations, unités organisationnelles, politiques de contrôle des services (SCP), séparation des environnements.
• Identités et accès : utilisation d’IAM Identity Center, utilisateurs IAM et clés d’accès à longue durée, compte root, authentification multifacteur, droits excessifs.
• Journalisation et détection : AWS CloudTrail à l’échelle de l’organisation, AWS Config, GuardDuty, Security Hub, conservation et protection des journaux.
• Réseau et exposition : ressources publiques, groupes de sécurité trop ouverts, buckets S3 accessibles, chiffrement en transit et au repos.
• Résilience : sauvegardes, répartition sur plusieurs zones de disponibilité, procédures de restauration réellement testées.
• Coûts : étiquetage, ressources inutilisées, dimensionnement, couverture par des engagements tarifaires.
• Industrialisation : part de l’infrastructure gérée en code, pipelines, gestion des états Terraform.

Le résultat n’est pas un rapport de cent pages : c’est une liste de constats classés par niveau de risque et par effort, avec pour chacun la correction recommandée.

Revue Well-Architected

Pour une application critique, nous menons une revue selon le cadre AWS Well-Architected et ses six piliers : excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts et durabilité. Nous utilisons le Well-Architected Tool d’AWS pour que les constats et le plan d’amélioration restent consultables dans votre compte, et suivis dans le temps.

La revue est utile avant une mise en production importante, après un incident, ou quand une application a beaucoup évolué depuis sa conception.

Landing zone et organisation multi-comptes

La bonne pratique AWS consiste à isoler les charges de travail dans des comptes distincts, regroupés dans une organisation. Une landing zone typique comprend :

• un compte de gestion réservé à l’organisation et à la facturation ;
• des comptes dédiés à la journalisation centralisée et aux outils de sécurité ;
• un compte réseau partagé quand l’architecture le justifie ;
• des comptes par environnement (production, préproduction, développement) et par produit ou équipe ;
• des SCP qui interdisent ce qui ne doit jamais arriver, par exemple désactiver la journalisation ou utiliser des régions non autorisées ;
• un accès unifié par IAM Identity Center, relié à votre annuaire existant.

Control Tower, Terraform, ou les deux ?

Approche	Points forts	Points d’attention
AWS Control Tower	Mise en place guidée, contrôles prédéfinis, fabrique de comptes intégrée	Personnalisation encadrée, conventions imposées par le service
Terraform seul (sur AWS Organizations)	Contrôle complet, tout est versionné et relu	Plus de travail initial, à maintenir soi-même
Control Tower piloté en Terraform	Contrôles AWS et personnalisation en code	Deux mécanismes à comprendre et à documenter

Nous recommandons l’approche selon la taille de votre organisation, vos compétences internes et votre outillage existant. Dans tous les cas, la landing zone est décrite en code et documentée. Voir aussi notre expertise Terraform et Infrastructure as Code.

Sécurité et coûts : deux sujets à traiter dès la fondation

La sécurité ne s’ajoute pas après coup : garde-fous d’organisation, accès temporaires plutôt que clés permanentes, journaux centralisés et protégés, chiffrement par défaut. Nous détaillons cette approche sur notre page sécurité et gouvernance cloud.

Côté coûts, la landing zone pose les bases du pilotage : étiquettes obligatoires, budgets et alertes par compte, détection d’anomalies, accès aux données de facturation pour les équipes concernées. L’optimisation continue relève ensuite de notre accompagnement FinOps.

Les livrables

• Rapport d’audit AWS : constats priorisés et plan de remédiation.
• Rapport de revue Well-Architected et suivi dans le Well-Architected Tool.
• Schémas d’architecture cible (organisation, réseau, flux d’accès).
• Landing zone en Infrastructure as Code, avec pipeline de déploiement.
• Dossier de décisions d’architecture.
• Procédures d’exploitation : création d’un compte, gestion des accès, réponse à une alerte de sécurité.
• Sessions de transfert de compétences avec vos équipes.

Comment nous travaillons avec vos équipes

Nous appliquons notre méthode Cadrer, Construire, Industrialiser, Améliorer. L’audit cadre les priorités ; la remédiation et la landing zone sont construites avec vos ingénieurs, qui relisent chaque modification de code ; l’exploitation est documentée et transmise. Nous restons neutres : si un besoin est mieux servi sur Azure, nous le disons, comme expliqué sur notre page conseil cloud AWS et Azure.

Pour qui, et quand nous appeler

• Vous démarrez sur AWS et voulez une base propre dès le premier compte.
• Vos comptes AWS se sont multipliés sans règles communes.
• Un client, un auditeur ou une réglementation vous demande de démontrer votre maîtrise de la sécurité.
• Vous préparez une migration vers AWS et la fondation cible n’existe pas encore.
• Votre équipe a besoin d’un regard expérimenté sur une architecture avant sa mise en production.

Réservez un échange de 15 minutes pour présenter votre contexte.

[ VOS QUESTIONS ]

Questions fréquentes

Qu’est-ce qu’un audit AWS ?

C’est un examen structuré de vos comptes AWS : organisation, identités et droits, configuration réseau, journalisation, sauvegardes, exposition publique et coûts. Il aboutit à une liste de constats priorisés par risque et par effort, avec un plan de remédiation que vos équipes peuvent exécuter.

Qu’est-ce qu’une AWS Well-Architected Review ?

C’est une revue d’une charge de travail selon le cadre Well-Architected d’AWS, organisé en six piliers : excellence opérationnelle, sécurité, fiabilité, efficacité des performances, optimisation des coûts et durabilité. AWS fournit un outil gratuit, le Well-Architected Tool, pour mener la revue et suivre les points d’amélioration.

Qu’est-ce qu’une landing zone AWS ?

C’est l’environnement multi-comptes de départ, préconfiguré avec les règles de sécurité, d’identité, de réseau et de journalisation qui s’appliqueront à tous les comptes. Elle peut être construite avec AWS Control Tower, en Terraform, ou en combinant les deux.

AWS Organizations ou AWS Control Tower ?

Ce n’est pas un choix exclusif. AWS Organizations est le service de base qui regroupe les comptes et applique des politiques ; Control Tower s’appuie dessus pour automatiser la mise en place d’une landing zone et de contrôles prédéfinis. Le choix dépend de votre besoin de personnalisation et de votre outillage Infrastructure as Code.

Que fait un consultant AWS DevOps ?

Il conçoit et automatise la chaîne qui mène du code à la production sur AWS : Infrastructure as Code, pipelines de déploiement, observabilité, gestion des secrets. L’objectif est que les déploiements soient reproductibles, relus et traçables.