Audit de sécurité AWS : 12 points à vérifier avant qu'une mauvaise configuration ne devienne un incident

Le scénario est courant. Le compte AWS a quelques années, plusieurs développeurs et prestataires y ont eu accès, des clés ont été créées pour un script, un bucket a été ouvert le temps d'un partage. Rien n'est en panne, donc personne ne regarde, jusqu'au questionnaire de sécurité d'un client ou au départ d'un prestataire : qu'est-ce qui est réellement exposé ?

Un audit de sécurité AWS compare la configuration réelle d'un compte à une liste de contrôles explicites (identités, exposition des données, réseau, secrets, journaux, sauvegardes, détection, correctifs, organisation des comptes, réponse aux incidents), documente chaque écart avec sa preuve, puis classe les écarts par gravité pour organiser leur correction. Il donne une photographie à une date donnée : il réduit l'incertitude, il ne garantit pas l'absence d'incident.

Voici les douze contrôles, la façon de prioriser les constats, une checklist de préparation et les livrables à attendre d'une mission.

Ce que couvre un audit de sécurité AWS

AWS sécurise l'infrastructure qui fait fonctionner ses services. Le client reste responsable de ce qu'il configure : identités, accès, réseau, chiffrement, données et, selon les services utilisés, système d'exploitation et correctifs. La plupart des incidents évitables naissent dans cette seconde partie.

AWS décrit ce partage dans son modèle de responsabilité partagée : la sécurité « du » cloud relève d'AWS, la sécurité « dans » le cloud relève du client, et la frontière varie selon le service : sur EC2, le système invité et ses correctifs sont à votre charge.

Une mauvaise configuration est un paramètre qui donne plus d'accès, plus d'exposition ou moins de visibilité que ce que l'entreprise a réellement décidé. Elle ne provoque souvent aucune erreur visible : l'application fonctionne, le risque reste latent.

Tous les constats n'ont pas la même nature. Un audit utile les distingue :

Un audit de configuration n'est ni un test d'intrusion, ni une revue du code applicatif, ni une certification de conformité.

Les 12 points de contrôle d'un audit de sécurité AWS

Pour chaque contrôle : ce qu'il faut vérifier, pourquoi, un écart possible, ses conséquences et les premières actions. Les écarts cités sont des exemples, pas des statistiques.

1. Les identités et les permissions IAM

IAM (Identity and Access Management) définit qui peut faire quoi, sur quelles ressources : toutes les autres protections en dépendent.

• À vérifier : les utilisateurs, groupes et rôles existants ; les politiques qui accordent le joker « * » sur les actions ou les ressources ; les identités qui disposent d'un accès administrateur complet ; les identités inutilisées.
• Pourquoi : AWS recommande d'accorder uniquement les permissions nécessaires à une tâche et de retirer régulièrement ce qui ne sert plus.
• Écart possible : un accès administrateur donné « temporairement » à un prestataire, jamais retiré.
• Conséquence : une identité compromise ouvre l'ensemble du compte, pas seulement le périmètre dont elle avait besoin.
• Premières actions : exploiter les informations de dernier accès pour supprimer les identités et permissions inutilisées, puis réduire progressivement les politiques trop larges, en commençant par la production.

2. Le compte root, les comptes privilégiés et l'authentification multifacteur

• À vérifier : l'usage récent du compte root, la présence de clés d'accès root, l'activation du MFA sur le compte root et sur toutes les identités à privilèges, le mode de connexion des personnes.
• Pourquoi : le compte root a des droits qui ne peuvent pas être restreints par une politique IAM. AWS publie des recommandations dédiées à sa protection et recommande, pour les personnes, une connexion fédérée avec des identifiants temporaires, par exemple via IAM Identity Center.
• Écart possible : un compte root utilisé au quotidien, protégé par un simple mot de passe partagé entre associés.
• Conséquence : perte de contrôle du compte entier, facturation comprise.
• Premières actions : activer le MFA sur le compte root et les accès à privilèges, en privilégiant les méthodes résistantes à l'hameçonnage (clés de sécurité, passkeys) ; réserver le root aux quelques tâches qui l'exigent.

3. Les clés d'accès et les identifiants de longue durée

• À vérifier : les clés d'accès actives, leur âge, leur dernière utilisation, et l'endroit où elles sont stockées (postes, scripts, outils d'intégration continue).
• Pourquoi : une clé d'accès n'expire pas d'elle-même. AWS recommande de privilégier les identifiants temporaires et, lorsque des clés sont indispensables, de les renouveler et les retirer à l'aide de leurs données de dernière utilisation.
• Écart possible : une clé créée pour un déploiement il y a plusieurs années, toujours active, présente dans l'historique d'un dépôt de code.
• Conséquence : quiconque possède la clé agit avec ses droits, sans MFA, depuis n'importe où.
• Premières actions : désactiver les clés inutilisées, remplacer celles des pipelines par des rôles assumés (fédération OpenID Connect), puis rechercher les clés présentes dans les dépôts.

4. L'exposition publique des buckets S3 et des données

• À vérifier : les réglages S3 Block Public Access au niveau du compte et de chaque bucket, les politiques de bucket, les listes de contrôle d'accès et les partages vers d'autres comptes.
• Pourquoi : les nouveaux buckets ne sont pas publics par défaut, mais une politique ou une ACL peut les ouvrir. AWS recommande d'activer les quatre réglages de blocage de l'accès public pour le compte, après avoir vérifié que les applications fonctionnent sans accès public.
• Écart possible : un bucket ouvert pour héberger quelques fichiers publics, qui contient aussi des exports de base de données.
• Conséquence : données lisibles par n'importe qui connaissant ou devinant le nom du bucket.
• Premières actions : activer le blocage au niveau du compte, isoler les rares contenus réellement publics dans un bucket dédié, et vérifier les accès publics et inter-comptes avec IAM Access Analyzer.

5. Le réseau, les Security Groups et les accès entrants

• À vérifier : les règles entrantes ouvertes à 0.0.0.0/0 (tout Internet), en particulier sur les ports d'administration (SSH 22, RDP 3389) et de bases de données ; les bases accessibles publiquement ; les ressources déployées dans le VPC par défaut sans réflexion préalable.
• Pourquoi : le groupe de sécurité est un pare-feu dont la configuration relève explicitement du client.
• Écart possible : un port SSH ouvert à tout Internet « pour dépanner », ou une base de données exposée publiquement pour un outil d'analyse.
• Conséquence : surface d'attaque directe, exploitation de la moindre faille du service exposé.
• Premières actions : restreindre les sources, placer les bases dans des sous-réseaux privés, remplacer l'accès SSH direct par AWS Systems Manager Session Manager lorsque c'est possible.

6. Les secrets et les clés de chiffrement

• À vérifier : où se trouvent les mots de passe de bases, jetons d'API et clés privées (code, variables d'environnement en clair, données de démarrage des instances, gestionnaire de secrets) ; qui peut lire ces secrets ; qui peut utiliser les clés KMS pour déchiffrer.
• Pourquoi : un secret lisible par trop d'identités annule les autres protections. Un gestionnaire comme AWS Secrets Manager centralise les accès et permet la rotation automatique des secrets.
• Écart possible : le mot de passe de la base de production écrit en clair dans un fichier de configuration versionné.
• Conséquence : accès direct aux données, souvent invisible dans les journaux AWS puisqu'il passe par la base elle-même.
• Premières actions : inventorier les secrets, les migrer vers un gestionnaire, restreindre leur lecture aux seules applications qui en ont besoin, puis changer ceux qui ont été exposés.

7. Les journaux d'audit et CloudTrail

• À vérifier : l'existence d'un journal CloudTrail couvrant toutes les régions, les événements de gestion en lecture et en écriture, la validation d'intégrité des fichiers, la protection et la durée de conservation du bucket de journaux.
• Pourquoi : sans journal, impossible de savoir qui a fait quoi après un incident. AWS recommande un journal multirégion avec validation de l'intégrité des fichiers, qui permet de démontrer qu'un fichier n'a pas été modifié ou supprimé.
• Écart possible : un journal limité à une seule région, dans un bucket que les administrateurs du compte peuvent vider.
• Conséquence : une activité dans une région inutilisée passe inaperçue ; un attaquant disposant de droits élevés peut effacer ses traces.
• Premières actions : activer un journal multirégion, protéger le bucket de destination, idéalement dans un compte séparé, et fixer une durée de conservation cohérente avec vos obligations.

8. Les sauvegardes et la capacité de restauration

• À vérifier : ce qui est sauvegardé et ce qui ne l'est pas, la fréquence, la durée de conservation, l'emplacement des copies et, surtout, la date du dernier test de restauration.
• Pourquoi : une sauvegarde jamais restaurée est une hypothèse. AWS Backup propose des tests de restauration planifiés, qui mesurent aussi la durée de restauration.
• Écart possible : des sauvegardes stockées dans le même compte que la production, supprimables par les mêmes identités.
• Conséquence : en cas de compromission ou d'erreur de suppression, les copies disparaissent avec les données d'origine.
• Premières actions : définir pour chaque application la perte de données acceptable et la durée d'interruption acceptable (RPO et RTO, définis dans notre guide de migration), copier les sauvegardes critiques vers un autre compte, puis restaurer réellement.

9. La surveillance, les alertes et la détection des événements anormaux

• À vérifier : l'activation d'un service de détection des menaces, d'un contrôle continu de la configuration, et la destination réelle des alertes.
• Pourquoi : Amazon GuardDuty analyse notamment les événements CloudTrail, les journaux de flux VPC et les journaux DNS pour signaler des identifiants compromis ou du minage de cryptomonnaie. AWS Security Hub CSPM évalue la configuration au regard de standards comme AWS Foundational Security Best Practices.
• Écart possible : des services activés dont les alertes arrivent dans une boîte que personne ne lit.
• Conséquence : l'incident est découvert par un client ou par la facture. Une hausse soudaine des coûts peut d'ailleurs être un signal de sécurité : c'est l'un des indicateurs suivis dans notre méthode pour réduire une facture AWS.
• Premières actions : activer la détection dans toutes les régions utilisées, router les alertes graves vers une personne nommée, définir ce qu'elle doit faire en les recevant.

10. Les mises à jour, les correctifs et la gestion des vulnérabilités

• À vérifier : l'âge des systèmes d'exploitation et des images de conteneurs, les versions des moteurs de bases de données, le processus d'application des correctifs.
• Pourquoi : sur EC2, le système invité et ses correctifs relèvent du client. Amazon Inspector analyse les instances EC2, les images de conteneurs ECR et les fonctions Lambda pour détecter les vulnérabilités logicielles et les expositions réseau non voulues.
• Écart possible : une instance installée à la main, jamais mise à jour, qui fait tourner un service accessible depuis Internet.
• Conséquence : exploitation d'une vulnérabilité publiquement connue.
• Premières actions : inventorier les systèmes et leurs versions, activer l'analyse de vulnérabilités, planifier les correctifs (AWS Systems Manager Patch Manager pour les instances), reconstruire régulièrement les images de conteneurs.

11. La segmentation des environnements et la séparation des responsabilités

• À vérifier : si la production partage un compte avec le développement et les tests ; qui peut déployer, qui peut approuver, qui peut supprimer les journaux ou les sauvegardes.
• Pourquoi : le compte AWS est la frontière d'isolement la plus nette. Avec AWS Organizations, des politiques de contrôle des services (SCP) posent des garde-fous qui s'appliquent à toutes les identités d'un compte.
• Écart possible : un développeur disposant des mêmes droits en production qu'en test, faute de séparation.
• Conséquence : une erreur ou une compromission sur un environnement secondaire atteint directement la production.
• Premières actions : séparer au moins la production dans un compte dédié, empêcher par garde-fou la désactivation des journaux, distinguer la personne qui modifie de celle qui valide pour les opérations sensibles. Le périmètre exact dépend de la taille de l'équipe : c'est un choix d'architecture à documenter.

12. La réponse aux incidents, la reprise et la documentation

• À vérifier : l'existence d'une procédure écrite, des contacts de sécurité renseignés dans le compte, des accès d'urgence, une documentation de l'architecture, et la date du dernier exercice.
• Pourquoi : le guide de réponse aux incidents de sécurité d'AWS insiste sur la préparation : procédures, accès aux outils et journaux, exercices simulés.
• Écart possible : personne ne sait qui peut isoler une instance compromise, ni comment, un vendredi soir.
• Conséquence : décisions improvisées, preuves effacées, reprise plus longue.
• Premières actions : écrire une procédure courte pour les scénarios probables (clé exposée, bucket ouvert, instance compromise), nommer les responsables, la tester.

Comment prioriser les constats

Un audit produit souvent plus de constats qu'une équipe ne peut en corriger en une fois. La priorité se décide sur quatre critères : l'exposition, l'impact, la facilité d'exploitation et le risque de la correction elle-même.

Cette grille est une méthode de travail, pas une norme : la gravité dépend des données concernées. Chaque correction a aussi son propre risque : fermer un port peut interrompre une application qui en dépendait.

Checklist : préparer un audit de sécurité AWS

• La liste des comptes AWS, des régions utilisées et de leurs responsables est établie.
• Le compte root est protégé par MFA et n'a pas de clé d'accès active.
• Les personnes se connectent par fédération ou par des identités nominatives avec MFA.
• Les clés d'accès actives sont listées, avec leur âge et leur dernière utilisation.
• Les identités et permissions inutilisées depuis plusieurs mois sont identifiées.
• Le blocage de l'accès public S3 est activé au niveau du compte, ou chaque exception est justifiée.
• Aucun port d'administration ni aucune base de données n'est ouvert à tout Internet.
• Les secrets sont stockés dans un gestionnaire, pas dans le code ni dans des fichiers versionnés.
• Un journal CloudTrail multirégion avec validation d'intégrité est actif et protégé.
• Les sauvegardes critiques existent hors du compte de production et une restauration a été testée.
• La détection des menaces est activée et ses alertes arrivent à une personne nommée.
• Les systèmes, images et moteurs de bases sont inventoriés avec leur version.
• La production est isolée des environnements de développement et de test.
• Une procédure de réponse aux incidents existe et désigne qui décide.

Ce qu'une mission d'audit AWS doit vous remettre

Un audit professionnel se juge à ses livrables : un périmètre écrit, un état des lieux, des constats prouvés, une priorisation et un plan de remédiation que votre équipe peut exécuter.

Méfiez-vous d'un rapport qui déclare une infrastructure « sécurisée » : un audit décrit un périmètre à une date. Ce qui change ensuite, ou ce qui était hors périmètre, n'est pas couvert ; la sécurité se maintient par des contrôles continus.

Questions fréquentes

Qu'est-ce qu'un audit de sécurité AWS ?

C'est l'analyse de la configuration d'un ou plusieurs comptes AWS au regard de contrôles explicites : identités et permissions, exposition des données, réseau, secrets, journaux, sauvegardes, détection, correctifs, organisation des comptes et réponse aux incidents. Chaque écart est documenté, prouvé et classé par gravité.

Un audit de sécurité AWS garantit-il qu'il n'y aura pas d'incident ?

Non. Il réduit l'incertitude sur un périmètre et à une date donnés. Les changements ultérieurs, les failles applicatives, les erreurs humaines et les éléments hors périmètre ne sont pas couverts. Il sert à décider quoi corriger en premier.

Quels accès faut-il donner pour un audit ?

Un accès en lecture seule suffit pour un audit de configuration. Il est préférable de créer un rôle dédié, limité dans le temps, plutôt que de transmettre des clés d'accès ; les politiques gérées par AWS comme SecurityAudit ou ReadOnlyAccess servent souvent de base.

À quelle fréquence réaliser un audit de sécurité AWS ?

Il n'existe pas de fréquence universelle. Un audit se justifie après un changement important, au départ d'un prestataire, avant une levée de fonds, une cession ou une migration, ou quand personne ne sait décrire le contenu du compte. Entre deux audits, des contrôles automatiques prennent le relais.

AWS Security Hub CSPM suffit-il à auditer un compte ?

C'est un bon point de départ, qui automatise de nombreux contrôles. Il ignore votre contexte (données sensibles, accès légitimes, exceptions volontaires) : ses résultats doivent être interprétés et priorisés.

Conclusion : mesurer, prioriser, puis corriger

La sécurité d'un compte AWS repose sur quelques questions posées méthodiquement : qui a accès, qu'est-ce qui est exposé, que voit-on quand quelque chose se passe, peut-on restaurer, sait-on réagir. Un audit y répond pour un périmètre donné et en tire un plan d'action.

CERVOX Services réalise des audits de compte AWS en lecture seule, par missions cadrées : vous recevez un inventaire des ressources analysées, les principaux points d'attention, une analyse structurée, des recommandations, une restitution et la documentation. Les corrections peuvent ensuite passer par une mission de mise en œuvre du plan d'action ou d'alertes et sauvegardes, qui inclut une restauration réellement exécutée. Une estimation écrite vous est remise sous 24 h ouvrées après un premier échange de 20 minutes : décrivez votre situation en quelques lignes, nous vous disons si nous pouvons intervenir, et comment. Pour le lancement d'une application, voir aussi notre checklist de mise en production.