Aller au contenu

AWS Mis à jour le 2026-07-04

Gestion continue de la sécurité AWS ou durcissement ponctuel : pourquoi le rapport d'audit pourrit

Les services de gestion de la sécurité AWS existent parce que le durcissement ponctuel se dégrade : les constats rouvrent, les nouvelles ressources sortent non durcies, et personne ne surveille les alertes. Voici la comparaison honnête et ce que « continu » veut vraiment dire.

Un mandat de durcissement AWS ponctuel produit une vraie amélioration et un rapport satisfaisant — et six mois plus tard, la moitié a discrètement reculé. De nouvelles ressources sont sorties sans les réglages durcis, un ingénieur a ouvert un groupe de sécurité « temporairement » pendant un incident, GuardDuty a continué de trouver des choses et personne n’était désigné pour les lire. La différence entre le durcissement et la gestion de la sécurité, ce n’est pas la liste de vérification; c’est que quelqu’un est responsable le mois prochain, et le mois d’après. Choisir entre les deux, c’est en réalité décider si votre environnement AWS change avec le temps — et il change.

Ce que vous décidez

Le durcissement est un projet : énumérer les trous, les boucher, remettre un rapport. Ça fonctionne réellement pour les trous qui restent bouchés tout seuls — supprimer les clés d’accès racine, activer la MFA, allumer CloudTrail. Là où ça échoue, c’est tout ce qui a un taux de dégradation. Un environnement AWS n’est pas un immeuble qu’on barre une fois; c’est un flot de changements — déploiements, nouveaux comptes, nouveaux compartiments, retouches IAM, mises à jour de dépendances — et chaque changement peut rouvrir un constat fermé. La posture de sécurité est une dérivée, pas un niveau : ce qui compte n’est pas votre durcissement le jour de l’audit, mais la vitesse à laquelle les nouveaux trous apparaissent contre la vitesse à laquelle ils se ferment.

La gestion continue de la sécurité, ce sont quatre fonctions permanentes : une détection qui reste allumée (GuardDuty, Security Hub, règles Config actives dans chaque compte et région qui comptent), une file humaine (constats triés à cadence fixe, avec des règles de gravité sur ce qui réveille quelqu’un contre ce qui attend la revue hebdomadaire), une réponse (un chemin documenté du constat au correctif, avec les accès pour corriger réellement), et un contrôle des régressions (garde-fous et réglages IaC par défaut pour qu’une même classe de constats cesse de revenir). Acheter des « services de gestion de la sécurité AWS » de qui que ce soit — nous y compris — devrait vouloir dire acheter ces quatre fonctions, pas un PDF mensuel.

La mécanique de coût, honnêtement : l’outillage AWS lui-même suit l’usage — GuardDuty facture au volume de journaux analysés, Security Hub aux constats ingérés et aux vérifications, Config aux éléments de configuration enregistrés — donc le coût des outils reste habituellement modeste face au temps d’ingénierie. Le vrai coût du continu, c’est l’attention : les heures récurrentes de quelqu’un. C’est exactement pourquoi ça échoue à l’interne quand ce n’est le vrai travail de personne.

Quoi vérifier en premier

Si vous vous demandez si vous avez une couverture continue ou un durcissement ponctuel dégradé, cinq vérifications tranchent :

  • Quand le dernier constat de sécurité a-t-il été fermé, et par qui? Si la réponse exige de l’archéologie, rien de continu ne se passe.
  • Est-ce que quelque chose surveille? GuardDuty actif dans toutes les régions utilisées, CloudTrail qui journalise, Security Hub ou équivalent qui agrège.
  • Où vont les alertes? Un sujet de sécurité qui livre dans un canal que personne ne lit, c’est du théâtre de détection.
  • Que s’est-il passé après le dernier vrai constat? Suivez un constat GuardDuty de bout en bout : détecté, vu par un humain, traité. Mesurez l’écart en jours.
  • Les nouvelles ressources héritent-elles des réglages durcis? Comparez le plus récent compartiment S3 et le plus récent groupe de sécurité aux standards du vieux rapport de durcissement.

Comment vérifier

# GuardDuty est-il vraiment actif dans cette région? (répétez par région utilisée)
aws guardduty list-detectors
aws guardduty get-detector --detector-id <detector-id> --query 'Status'

# CloudTrail journalise-t-il en ce moment, et s'est-il déjà arrêté?
aws cloudtrail get-trail-status --name org-trail \
  --query '[IsLogging,LatestDeliveryTime,StopLoggingTime]'

# Les vérifications de conformité tournent-elles, et qu'est-ce qui échoue?
aws securityhub get-enabled-standards
aws configservice describe-configuration-recorder-status

Dans la console, GuardDuty > Findings trié par date répond directement à la question inconfortable : s’il y a des constats de gravité élevée vieux de plusieurs mois encore en ACTIVE, la détection existe mais pas la gestion. Le travail d’installation de la couche de détection est couvert dans la base de référence CloudTrail et GuardDuty.

L’approche

  1. Faites quand même le durcissement ponctuel — comme porte d’entrée. Une gestion continue par-dessus un compte non durci se noie dans les constats du jour un. Le ménage initial fixe la base que le travail récurrent défendra.
  2. Allumez la couche de détection partout, une fois, de façon centralisée. GuardDuty et Security Hub en administration déléguée à travers l’organisation, CloudTrail en journal d’organisation. L’activation manuelle par compte et par région, c’est comme ça que naissent les trous de couverture.
  3. Définissez la ligne de réveil par écrit. Quels types de constats réveillent un humain maintenant (exfiltration d’identifiants GuardDuty, usage de la racine, CloudTrail arrêté) contre ce qui va dans la file hebdomadaire (instantané public, chiffrement manquant sur un compartiment de dev). Sans cette ligne, tout devient la file hebdomadaire, y compris les urgences.
  4. Installez la cadence. Une revue hebdomadaire de 30 minutes avec un responsable nommé bat une revue quotidienne ambitieuse qui meurt en un mois. Suivez deux chiffres seulement : les critiques ouverts, et la médiane des jours avant fermeture. Si ces deux-là vont dans le bon sens, le programme fonctionne.
  5. Fermez des classes de constats, pas des constats. Le troisième constat de compartiment public n’est pas un problème de compartiment, c’est un problème de provisionnement — corrigez le module Terraform ou ajoutez la SCP, puis fermez la classe. C’est l’étape que le durcissement ponctuel ne peut structurellement pas faire, et là où des protections de bordure comme les règles gérées WAF sur l’ALB gagnent leur place comme infrastructure permanente plutôt que geste isolé.
  6. Rebasez trimestriellement. Nouvelles fonctions AWS, nouveaux services en usage, nouveaux comptes — une revue trimestrielle de ce que la détection couvre contre ce qui existe maintenant empêche « continu » de devenir en douce « continu pour l’architecture de 2024 ».

Quand c’est la mauvaise approche

Un environnement réellement statique — un compte, une poignée de ressources, aucun déploiement depuis des mois — se dégrade lentement, et une passe de durcissement annuelle avec des réglages préventifs solides peut honnêtement suffire; surveiller un musée en continu, c’est de la dépense en trop. Une jeune pousse pré-lancement sans données de production peut reporter le programme complet (pas CloudTrail, pas la MFA — ceux-là, c’est le jour un). Et si l’arriéré de constats se compte déjà en milliers, ne partez pas la cadence hebdomadaire tout de suite; menez d’abord un projet de remédiation cadré, puis passez au continu pour tenir le terrain. Acheter un rapport mensuel sans autorité de remédiation est le pire des deux mondes — vous payez en continu pour la lucidité pendant que les trous se ferment à vitesse ponctuelle.

Erreurs courantes

  • Confondre activé et géré. GuardDuty allumé sans personne d’assigné aux constats, c’est un abonnement payant à une boîte de réception jamais lue.
  • Mesurer l’activité au lieu de la fermeture. « 1 400 constats passés en revue » ne veut rien dire; les critiques ouverts et les jours avant fermeture veulent tout dire.
  • Des alertes acheminées vers un canal cimetière. La première semaine, tout le monde le lit; à la sixième, il est en sourdine. Des règles de réveil et une petite file hebdomadaire survivent; les lances à incendie, non.
  • Laisser le rapport de durcissement tenir lieu d’état actuel. Le rapport décrit le jour de l’audit. Sans revérification continue, son exactitude se dégrade dès la livraison.

Garder le contrôle

  • Un responsable nommé pour la file de constats, avec une relève quand il est absent.
  • Revue hebdomadaire, deux métriques suivies : critiques ouverts, médiane des jours avant fermeture.
  • Chaque classe de constats récurrente reçoit un billet de prévention (SCP, règle Config ou réglage IaC par défaut), pas seulement un correctif d’instance.
  • Revue de couverture trimestrielle : nouvelles régions, nouveaux comptes, nouveaux services contre ce que la détection surveille réellement.
  • Testez le chemin de réveil deux fois par année avec un constat synthétique — un chemin d’alerte jamais testé est un espoir, pas un contrôle.

Le durcissement répond à « sommes-nous sécuritaires aujourd’hui? »; la gestion répond à « le serons-nous encore en mars? » — et seule la deuxième question survit au contact d’un environnement qui change. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.