Aller au contenu

AWS Mis à jour le 2026-07-04

Configurer AWS Security Hub : transformer un mur de constats en file de travail réaliste

Une configuration AWS Security Hub par défaut produit des centaines de constats et aucun plan. Voici comment l'activer à travers comptes et régions, choisir les standards, supprimer le bruit, et finir avec une file qu'une vraie équipe peut traiter.

Activez Security Hub avec les réglages par défaut et vous aurez plusieurs centaines de constats demain matin — un mur de rouge qui convainc la plupart des équipes que l’outil est inutilisable, après quoi il devient un tableau de bord coûteux que personne n’ouvre. L’outil est correct; c’est la configuration qui cloche. Un déploiement Security Hub qui fonctionne fait trois choix délibérés que l’assistant ne fait pas pour vous : quels standards exécuter, comment les constats de chaque compte et région convergent vers un seul endroit, et quels constats sont réellement à corriger contre le bruit à supprimer avec une raison documentée. Bien fait, vous finissez avec une file de dizaines, pas de centaines, et un chiffre qui descend.

Ce qui se passe

Security Hub fait deux travaux distincts que les gens confondent. Un : il exécute des contrôles — des vérifications de configuration automatisées issues de standards comme AWS Foundational Security Best Practices (FSBP) et le CIS AWS Foundations Benchmark — contre vos ressources, générant des constats réussite/échec. Deux : il agrège les constats des autres services (GuardDuty, Inspector, Macie, IAM Access Analyzer) dans un format normalisé et un seul endroit. Le problème du mur de constats vient presque entièrement du premier travail : chaque volume de dev non chiffré, chaque artefact de VPC par défaut, chaque groupe de journaux sans rétention devient un constat, le tout mélangé sans égard à l’importance de la ressource.

Une note de nommage pour que la console ne vous mêle pas : AWS a réorganisé cette famille de produits en 2025, et le service original décrit ici apparaît maintenant comme Security Hub CSPM dans la console, à côté d’une expérience Security Hub plus récente bâtie par-dessus. La mécanique ci-dessous — standards, contrôles, constats, agrégation inter-région — concerne cette couche de constats et de standards, et la documentation Security Hub couvre les deux.

L’autre chose à comprendre avant l’installation : Security Hub est régional et par compte par défaut. Sans administration déléguée et sans agrégateur de constats, vous obtenez un silo par compte par région, ce qui dans une organisation de dix comptes est une illusion de couverture. Le prix suit les vérifications et les constats ingérés, donc activer les deux grands standards dans chaque compte est une vraie ligne de facture (habituellement modeste) — une raison de plus de choisir les standards au lieu de tout activer.

Quoi vérifier en premier

  • Les préalables. Les contrôles de Security Hub s’appuient sur AWS Config; l’enregistreur doit être actif dans chaque compte et région à vérifier, et Config a son propre coût par élément.
  • Ce qui l’alimente. Les constats GuardDuty et Inspector n’apparaissent que si ces services sont activés — Security Hub agrège, il ne détecte pas. La couche de détection vient d’abord : voyez la base de référence CloudTrail et GuardDuty.
  • La structure de l’organisation. Confirmez quel compte sera l’administrateur délégué — votre compte de sécurité/audit, jamais le compte de gestion.
  • Les régions réellement utilisées. L’agrégation exige une région d’attache choisie délibérément.
  • Qui travaillera la file. Si aucun nom n’y est attaché, arrêtez ici — une installation sans opérateur ne fait que bâtir un mur plus grand.

Comment vérifier

Pour un déploiement existant, établissez ce qui est vraiment activé où :

# Security Hub est-il actif dans cette région, et quels standards tournent?
aws securityhub describe-hub
aws securityhub get-enabled-standards

# L'agrégation inter-région est-elle configurée?
aws securityhub list-finding-aggregators

# La file qui compte : critique/élevé, actif, non résolu
aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"},{"Value":"HIGH","Comparison":"EQUALS"}],"WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"}],"RecordState":[{"Value":"ACTIVE","Comparison":"EQUALS"}]}' \
  --max-items 25

Dans la console, Security Hub > Findings avec le filtre Workflow status: NEW, Severity: CRITICAL est la vue honnête. Si cette liste filtrée contient des entrées vieilles de plusieurs mois, le déploiement est un tableau de bord, pas une file.

La marche à suivre

  1. Désignez l’administrateur délégué depuis le compte de gestion. aws securityhub enable-organization-admin-account --admin-account-id 444455556666, pointant vers le compte d’audit. Activez ensuite Security Hub pour l’organisation depuis ce compte avec l’activation automatique des nouveaux comptes, pour que les comptes distribués soient couverts à la naissance.
  2. Choisissez un standard pour commencer : FSBP. Il est maintenu par AWS, à jour, et recoupe largement CIS. Ajoutez CIS plus tard si un auditeur l’exige nommément; exécuter les deux dès le jour un double à peu près le mur pour peu de signal ajouté.
  3. Configurez l’agrégation inter-région. Depuis l’admin délégué dans votre région d’attache : aws securityhub create-finding-aggregator --region-linking-mode ALL_REGIONS. Une vitre, toutes les régions — c’est la différence entre la couverture et son illusion.
  4. Désactivez les contrôles qui ne s’appliquent pas, avec raisons. Chaque contrôle désactivé exige une justification écrite (« aucun Lambda dans ces comptes », « couvert par la SCP qui refuse la région » — la couche de garde-fous de la base de référence SCP pour Organizations retire légitimement certaines vérifications). Désactiver un contrôle partout est honnête; supprimer ses constats pour toujours sans raison, c’est cacher.
  5. Triez ce qui reste avec le statut de flux de travail. Travaillez en gravité décroissante : corrigez (puis vérifiez que le constat passe à RESOLVED à la vérification suivante), ou supprimez avec une raison consignée (aws securityhub batch-update-findings --workflow-status SUPPRESSED plus une note). Les règles d’automatisation prennent les cas mécaniques — suppression automatique d’un patron de constat accepté sur les comptes bac à sable, élévation automatique de tout ce qui touche les magasins de données de production.
  6. Acheminez le haut de la file vers l’extérieur. Règle EventBridge sur les nouveaux constats CRITICAL vers le chemin de réveil; tout le reste demeure dans la revue hebdomadaire. Le mur devient une file précisément quand l’acheminement à l’arrivée existe.
  7. Établissez la base, puis suivez la tendance. Notez les comptes ouverts par gravité au jour un, puis suivez chaque semaine. Le graphique utile, c’est la direction, pas le nombre absolu.

Quand c’est la mauvaise approche

Si GuardDuty n’est pas encore actif, faites-le d’abord — la détection comportementale des menaces bat les vérifications de configuration pour l’alerte précoce, et Security Hub sans sources est un cadre sans tableau. Si vous exploitez un seul petit compte, les pages console des services individuels peuvent très bien suffire sans la couche d’agrégation; Security Hub gagne son coût quand les comptes et les régions se multiplient. Et si l’organisation a déjà standardisé sur un SIEM ou un CSPM externe, faites de Security Hub le collecteur côté AWS qui l’alimente plutôt qu’une deuxième surface de triage — deux files, c’est deux files à moitié travaillées.

Erreurs courantes

  • Activer tous les standards au jour un. FSBP plus CIS plus PCI sur un parc non préparé produit des milliers de constats et une équipe anesthésiée. Les standards se choisissent, ils ne se collectionnent pas.
  • Sauter AWS Config, puis croire les scores. Bien des contrôles ne peuvent silencieusement pas évaluer sans l’enregistreur; le score de conformité paraît meilleur que la réalité.
  • Supprimer sans raisons écrites. Six mois plus tard, personne ne sait si S3.8 a été supprimé par analyse ou par fatigue, alors personne n’ose le réactiver.
  • Traiter le score de sécurité comme le livrable. Le pourcentage bouge en désactivant des contrôles; la tendance des critiques ouverts et les jours avant fermeture sont les chiffres qui reflètent le vrai travail de risque.

Garder le contrôle

  • Revue hebdomadaire de la file avec un responsable nommé; les critiques réveillent immédiatement via EventBridge.
  • Chaque suppression porte une raison et une date de révision.
  • Les nouveaux comptes héritent de Security Hub automatiquement via l’activation d’organisation — vérifiez trimestriellement.
  • Revoyez les contrôles désactivés deux fois par année; « ne s’applique pas » a tendance à devenir « s’applique depuis la nouvelle charge de travail ».
  • Surveillez les lignes de coût Security Hub et Config à mesure que le parc grandit; des comptes de vérifications qui montent sont aussi un signal d’inventaire.

Un Security Hub qui fonctionne est ennuyant : une file courte, une tendance à la baisse, et des suppressions que quelqu’un peut défendre en audit. 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.