2.1 - Concevoir et mettre en oeuvre la surveillance et l'alerte (EventBridge, filtres de métrique, détection d'anomalies)
L'objectif 2.1 de l'AWS Certified Security Specialty couvre la transformation de signaux bruts en alertes exploitables par un humain ou une machine. Une alarme CloudWatch ne sait surveiller qu'une métrique : alerter sur un texte présent dans un groupe de logs impose donc de créer d'abord un filtre de métrique, puis d'alarmer sur la métrique qu'il publie. Les règles EventBridge filtrent des événements comme une connexion de l'utilisateur root, une suppression programmée de clé KMS ou un groupe de sécurité qui ouvre le port 22 au monde entier, trient les findings GuardDuty par gravité directement dans le motif d'événement, et ciblent SNS, Lambda ou SSM Automation pour la remédiation. Un trafic qui varie fortement selon le jour de la semaine se traite mieux avec la détection d'anomalies CloudWatch qu'avec un seuil fixe, une alarme composite ne se déclenche que si deux alarmes sont en ALARM en même temps, et le metric math exprime un taux d'échec plutôt que des comptes bruts. La livraison inter-comptes exige une politique de ressource sur le bus récepteur, une file de lettres mortes conserve les événements qu'une cible en panne n'a pas pu traiter, les filtres d'abonnement diffusent les lignes de log vers Lambda à leur arrivée, et CloudTrail Insights signale les taux d'appels d'API inhabituels. Les conformance packs et agrégateurs Config couvrent la conformité de l'organisation.
Alarmer sur un texte dans un log = filtre de métrique d'abord, puis alarme sur sa métrique. Seuil trompeur parce que le trafic est saisonnier = détection d'anomalies CloudWatch. Événements venus d'autres comptes = politique de ressource sur le bus récepteur.
Questions d'entraînement
1. Une equipe securite veut une console CloudWatch unique affichant metriques, journaux et alarmes de 25 comptes de charge de travail, sans copier la moindre donnee. Quelle capacite offre cela ?
- Un tableau de bord CloudWatch dans chaque compte de charge, partage publiquement pour que l'equipe securite puisse les ouvrir cote a cote dans un navigateur
- Un trail d'organisation livrant dans le compte de securite
- L'observabilite inter-comptes CloudWatch, avec le compte de securite en compte de surveillance (bonne réponse)
- Un bucket S3 recevant un export de metriques de chaque compte
L'observabilite inter-comptes relie des comptes sources a un compte de surveillance via Observability Access Manager, si bien que le compte de surveillance interroge sur place les metriques, les groupes de journaux et les alarmes. Des tableaux de bord partages publiquement constituent une exposition grave et n'unifieraient toujours pas la vue, un trail d'organisation transporte des evenements CloudTrail et non des metriques, et exporter des metriques vers S3 fait perdre toute l'experience console en direct.
2. Un outil de tickets attend un message court et plat, mais l'evenement EventBridge est un gros document JSON imbrique. Comment la regle peut-elle le remodeler sans aucun code ?
- En activant un detecteur de schema sur le bus d'evenements
- En modifiant le motif d'evenement pour qu'il ne corresponde qu'aux champs attendus par l'outil de tickets, ce qui retire aussi les autres champs de la charge utile livree a la cible
- En archivant l'evenement puis en le rejouant sous une forme simplifiee
- En utilisant un transformateur d'entree sur la cible (bonne réponse)
Un transformateur d'entree extrait des chemins nommes de l'evenement et les injecte dans un modele, si bien que la cible recoit exactement le texte attendu. Un detecteur de schema se contente de documenter les structures, un motif d'evenement decide si une cible est invoquee et ne modifie jamais la charge utile, et l'archivage suivi d'un rejeu renvoie l'evenement d'origine tel quel.
3. Les journaux applicatifs envoyes vers CloudWatch Logs contiennent parfois des numeros de carte bancaire, et les exploitants ne doivent pas les voir alors que les auditeurs gardent un acces complet. Que faut-il configurer ?
- Une tache Amazon Macie analysant le groupe de journaux
- Une politique de protection des donnees sur le groupe de journaux, masquant les identifiants detectes (bonne réponse)
- Un filtre d'abonnement faisant transiter chaque evenement par une fonction Lambda qui reecrit les sous-chaines sensibles avant enregistrement dans un second groupe de journaux
- Une retention plus courte sur le groupe de journaux
Une politique de protection des donnees CloudWatch Logs detecte des identifiants geres et les masque a la lecture, tandis que les principaux disposant de logs:Unmask voient toujours les valeurs brutes, ce qui correspond exactement au partage entre exploitants et auditeurs. Macie inspecte des objets S3 et non des groupes de journaux, une chaine de reecriture par Lambda duplique une fonctionnalite native et double le stockage, et raccourcir la retention ne masque rien tant que la donnee est vivante.
4. Des alertes de securite deja publiees sur une rubrique SNS doivent aussi apparaitre dans un canal Slack, sans serveur a maintenir. Quel est le chemin pris en charge ?
- Un abonnement SNS par courriel pointant vers l'adresse du canal Slack, l'espace de travail etant configure pour accepter et afficher les messages entrants d'expediteurs inconnus
- Une fonction Lambda interrogeant la rubrique chaque minute
- AWS Chatbot, desormais livre sous le nom Amazon Q Developer in chat applications, abonne a la rubrique (bonne réponse)
- Un tableau de bord CloudWatch integre dans Slack
Le service d'integration de messagerie s'abonne a une rubrique SNS et affiche nativement les notifications AWS dans Slack ou Microsoft Teams, avec un role IAM bornant ce qu'il peut faire. Le courriel vers un canal est fragile et non authentifie, une Lambda d'interrogation reinvente une integration geree, et les tableaux de bord sont des images plutot qu'un canal d'alerte.
5. Une equipe securite doit etre prevenue en quelques minutes des qu'un utilisateur root se connecte. Quelle conception repond au besoin avec le moins de code specifique ?
- Une fonction Lambda nocturne qui telecharge les fichiers CloudTrail depuis S3, analyse chaque enregistrement JSON rencontre et envoie un rapport par courriel a l'equipe
- Une politique IAM qui refuse tout acces console a l'utilisateur root, ce qui supprime le besoin de notification
- Une regle EventBridge qui filtre l'evenement CloudTrail de connexion console pour l'identite root, avec une rubrique SNS en cible (bonne réponse)
- Une evaluation Amazon Inspector planifiee toutes les heures sur le compte de gestion
EventBridge recoit les evenements de gestion CloudTrail en quasi temps reel, donc un motif sur l'evenement ConsoleLogin avec userIdentity.type egal a Root se declenche en quelques minutes. Un traitement nocturne casse l'exigence de quelques minutes, les politiques IAM ne s'appliquent tout simplement pas a l'utilisateur root et ne peuvent donc pas bloquer cette connexion, et Inspector cherche des vulnerabilites logicielles plutot que de surveiller des evenements d'authentification.
6. Une organisation exploite 40 comptes et veut un seul endroit ou voir ensemble les constats GuardDuty, Inspector et Macie dans un format normalise. Quel service fait cela ?
- AWS Security Hub (bonne réponse)
- Amazon CloudWatch Logs
- Un bucket Amazon S3 dans lequel chaque service ecrit ses constats bruts, lu par un outil de restitution que l'equipe maintient elle-meme
- AWS Systems Manager Inventory
Security Hub ingere les constats des services de securite AWS et de produits partenaires au format AWS Security Finding Format, et gere un administrateur delegue avec agregation inter-comptes. CloudWatch Logs stocke des lignes de journal et ne normalise rien, un assemblage maison sur S3 reinvente cette normalisation aux frais de l'equipe, et Systems Manager Inventory recense les logiciels et la configuration des noeuds geres.
Objectifs liés
- 2.2 - Dépanner la surveillance et l'alerte (règles muettes, INSUFFICIENT_DATA, findings manquants)
- 2.3 - Concevoir et mettre en oeuvre une solution de journalisation (CloudTrail, Flow Logs, Athena, Logs Insights, OpenSearch)
- 2.4 - Dépanner les solutions de journalisation (buckets vides, refus KMS, événements de données manquants)