Le scénario est classique : une PME ouvre un compte AWS pour héberger une application. Un développeur crée quelques ressources. Six mois plus tard, la facture a doublé, personne ne sait exactement ce qui tourne, et deux anciens collaborateurs ont encore leurs accès. C’est le problème de la gouvernance cloud — et c’est évitable.

La bonne nouvelle : AWS fournit tous les outils nécessaires. La mauvaise : ils ne sont pas activés par défaut, et il faut les configurer avant que le désordre s’installe.

AWS Organizations : la structure qui rend tout le reste possible

Si vous avez plusieurs environnements (développement, staging, production) ou plusieurs projets distincts, la première décision de gouvernance est d’utiliser AWS Organizations pour les gérer depuis un compte racine.

L’architecture recommandée pour une PME :

Compte Management (racine) — facturation centralisée, pas de charges de travail
├── Compte Production — environnements de production uniquement
├── Compte Développement — bac à sable, tests, CI/CD
└── Compte Sécurité — journaux CloudTrail, Security Hub, backups centralisés

Pourquoi cette séparation ? Parce qu’elle crée des périmètres d’isolation : une erreur dans le compte développement ne peut pas impacter la production. Un compte compromis ne compromet pas les autres. Et la facturation par compte vous donne une visibilité immédiate sur ce que coûte chaque environnement.

Service Control Policies : les garde-fous au niveau organisationnel

Les SCP (Service Control Policies) sont des règles qui s’appliquent à tous les comptes d’une unité organisationnelle, quel que soit le niveau de permissions IAM des utilisateurs. Elles définissent ce qui est possible — pas ce qui est autorisé.

Exemples de SCP utiles pour une PME :

Interdire toute action hors des régions européennes :

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["eu-west-1", "eu-west-3", "eu-central-1"]
    }
  }
}

Interdire la désactivation de CloudTrail :

{
  "Effect": "Deny",
  "Action": [
    "cloudtrail:StopLogging",
    "cloudtrail:DeleteTrail"
  ],
  "Resource": "*"
}

Ces deux SCP seuls éliminent une large classe d’erreurs et d’incidents : personne ne peut accidentellement (ou malicieusement) créer des ressources aux États-Unis ou couper la journalisation.

IAM : le principe du moindre privilège, appliqué pour de vrai

“Accès admin pour tout le monde” est la configuration IAM par défaut dans trop de petites structures. C’est une erreur de gouvernance et un risque de sécurité majeur.

Le principe du moindre privilège dit qu’un utilisateur ou un service ne doit avoir que les permissions nécessaires à sa fonction, rien de plus.

Concrètement :

Supprimer les accès root au quotidien. Le compte root AWS (email + mot de passe) ne doit être utilisé que pour les opérations irremplaçables (fermeture de compte, certaines configurations de facturation). Activez le MFA sur root, rangez les identifiants en lieu sûr, et n’utilisez plus ce compte.
Créer des rôles IAM, pas des utilisateurs IAM pour les applications. Si votre application EC2 doit lire un bucket S3, créez un rôle IAM avec cette seule permission et attachez-le à l’instance. Ne jamais mettre de clés d’accès en dur dans le code.
Grouper les permissions par fonction. Un groupe “Développeurs” avec accès en lecture/écriture sur l’environnement dev. Un groupe “Ops” avec accès à la production. Un groupe “Lecture seule” pour les responsables qui veulent voir les métriques sans pouvoir modifier.
Auditer régulièrement avec IAM Access Analyzer. Cet outil détecte les permissions inutilisées depuis plus de 90 jours et les ressources exposées publiquement par accident.

La rotation des accès au départ d’un collaborateur

C’est la procédure que tout le monde oublie de formaliser : quand un collaborateur quitte l’entreprise, ses accès AWS doivent être révoqués le jour même. Pas la semaine suivante.

Créez une checklist de départ qui inclut explicitement : désactivation du compte IAM, révocation des clés d’accès, rotation des secrets partagés que la personne connaissait.

Le tagging : la base de toute gouvernance des coûts

Sans tags, votre facture AWS est une liste de services sans contexte. Avec un schéma de tags cohérent, vous savez immédiatement ce que coûte chaque projet, environnement et équipe.

Schéma de tags recommandé :

Clé	Valeur exemple	Usage
`Project`	`crm-interne`	Identifier le projet
`Environment`	`production` / `dev`	Distinguer les environnements
`Owner`	`jean-christophe`	Responsable de la ressource
`CostCenter`	`it-ops`	Imputation comptable

Rendez le tagging obligatoire via une SCP qui bloque la création de ressources sans les tags requis. AWS Config peut vérifier en continu que toutes vos ressources sont correctement taguées et alerter sur les écarts.

Budgets et alertes : ne jamais être surpris par sa facture

AWS Budgets vous permet de définir des seuils de dépenses et de recevoir des alertes avant de les dépasser.

Configuration minimale pour une PME :

Budget mensuel global : alerte à 80% et 100% du budget prévu
Budget par projet (via tags) : pour identifier rapidement quel projet dérape
Alerte d’anomalie (AWS Cost Anomaly Detection) : détecte les pics de dépenses inhabituels, même en dessous du seuil global

Une instance EC2 oubliée qui tourne 24h/24 coûte entre 15€ et 200€/mois selon le type. Une alerte d’anomalie vous prévient en quelques heures.

AWS Cost Explorer complète les budgets avec une visualisation historique : tendances, décomposition par service, par région, par tag. Passez 10 minutes par mois à examiner votre facture Cost Explorer — vous serez surpris de ce que vous trouvez.

AWS Config : la conformité en continu

AWS Config enregistre l’état de toutes vos ressources AWS et permet de vérifier en continu qu’elles respectent vos règles de gouvernance.

Règles Config utiles pour une PME :

s3-bucket-public-read-prohibited : alerte si un bucket S3 est ouvert publiquement
rds-instance-public-access-check : alerte si une base de données est exposée sur Internet
encrypted-volumes : alerte si un volume EBS n’est pas chiffré
root-account-mfa-enabled : vérifie que le MFA est actif sur le compte root
iam-password-policy : vérifie que votre politique de mots de passe IAM est suffisamment stricte

Ces règles peuvent générer des alertes (mode “audit”) ou déclencher des corrections automatiques via Lambda (mode “remédiation automatique”).

Le tableau de bord de gouvernance

L’ensemble de ces outils devient cohérent quand vous les centralisez dans AWS Security Hub. Il agrège les findings de GuardDuty, Config, IAM Access Analyzer et Inspector dans une vue unique, avec un score de posture de sécurité.

Pour une PME, cela représente environ 30€/mois pour Security Hub + GuardDuty — et cela remplace des heures de vérifications manuelles dispersées.

Par où commencer si vous partez de zéro

Plutôt que de tout faire en même temps, voici un ordre de priorité pragmatique :

Semaine 1 : Activer MFA sur le compte root, créer les utilisateurs IAM individuels, supprimer les clés d’accès partagées
Semaine 2 : Activer CloudTrail dans toutes les régions, configurer AWS Budgets avec alertes
Mois 1 : Mettre en place le schéma de tags, déployer AWS Config avec les règles de base
Mois 2 : Structurer AWS Organizations si plusieurs comptes, déployer les SCP fondamentales
Mois 3 : Activer Security Hub + GuardDuty, revoir les permissions IAM existantes

C’est un chantier de quelques semaines, pas de quelques mois. Et le retour sur investissement est immédiat : moins de surprises sur la facture, moins de risques de sécurité, plus de visibilité sur ce qui tourne dans votre cloud.

Vous utilisez AWS depuis quelques mois ou quelques années et vous sentez que votre gouvernance s’est construite au fil de l’eau ? Un audit de posture cloud permet de faire le point en deux jours et de repartir avec un plan d’action priorisé. Contactez-moi pour en discuter.

Sources : AWS Well-Architected Framework — Pilier Excellence opérationnelle ; AWS Organizations documentation ; ANSSI — Guide d’hygiène informatique.