4.3 - Détection des menaces et protection (GuardDuty, WAF, Shield)
L'objectif 4.3 de l'AWS SysOps Administrator couvre la détection des menaces et la protection de l'edge. Amazon GuardDuty repère les menaces à partir des VPC Flow Logs, journaux DNS et CloudTrail sans déployer d'agents, Amazon Inspector scanne en continu EC2, ECR et Lambda pour les vulnérabilités logicielles, et AWS Security Hub agrège les résultats face à des standards comme CIS et les AWS Foundational Security Best Practices. Amazon Macie découvre les données sensibles dans S3 et Amazon Detective aide à enquêter sur la cause racine. À l'edge, AWS WAF bloque l'injection SQL, le cross-site scripting et les abus par débit avec des règles gérées sur ALB, CloudFront ou API Gateway ; Shield Standard est une protection DDoS gratuite toujours active tandis que Shield Advanced ajoute la Shield Response Team 24/7 et une protection de coût ; et Firewall Manager centralise tout cela entre comptes. Attends-toi à des mises en situation sur le bon service de sécurité.
Détecter les menaces depuis les journaux sans agents = GuardDuty. Scanner EC2/ECR/Lambda pour vulnérabilités = Inspector. Bloquer SQLi/XSS en couche 7 = WAF ; DDoS garanti + équipe 24/7 = Shield Advanced.
Questions d'entraînement
1. Lesquelles de ces DEUX actions une alarme métrique CloudWatch peut-elle invoquer directement ? (Choisissez DEUX réponses.)
- Publier une notification vers un SNS topic (bonne réponse)
- Exécuter une action EC2 stop, terminate, reboot ou recover (bonne réponse)
- Réécrire directement les règles entrantes du security group de l'instance
- Annuler automatiquement la dernière mise à jour de stack CloudFormation
Une alarme métrique peut notifier un SNS topic et exécuter des actions EC2 (stop/terminate/reboot/recover), plus des actions Auto Scaling et Systems Manager. Elle ne peut pas éditer directement les security groups ni annuler une stack CloudFormation.
2. Une launch template doit définir des volumes EBS chiffrés au repos pour chaque instance lancée par le groupe. Que doit spécifier le template ?
- Un security group autorisant tout le trafic
- Des volumes EBS chiffrés avec une clé KMS (bonne réponse)
- Une IP publique sur chaque instance
- Une route NAT gateway pour le sous-réseau
Spécifier des volumes EBS chiffrés avec une clé KMS dans le block device mapping garantit que chaque instance lancée a le chiffrement au repos. Les security groups, IP publiques et routes NAT concernent le réseau, pas le chiffrement des volumes.
3. La sécurité veut voir le trafic accepté et rejeté d'un VPC sans agent sur les hôtes. Qu'activez-vous ?
- CloudTrail data events pour chaque interface réseau du VPC
- VPC Flow Logs envoyant les enregistrements vers un log group CloudWatch (bonne réponse)
- L'agent unifié CloudWatch sur chaque instance pour capturer les paquets
- Route 53 query logging, qui enregistre aussi les décisions de paquets entrants
Les VPC Flow Logs capturent les métadonnées de trafic IP accepté/rejeté au niveau réseau et livrent vers CloudWatch Logs, sans agent sur l'hôte. CloudTrail enregistre des appels d'API, l'agent doit être installé, et les Route 53 query logs enregistrent le DNS, pas les paquets.
4. Pour un audit sécurité vous devez enregistrer les noms DNS résolus par vos ressources via un résolveur Route 53. Qu'est-ce qui produit cela ?
- Les VPC Flow Logs, qui incluent le nom d'hôte résolu de chaque connexion
- La collecte DNS de l'agent CloudWatch activée dans la section métriques
- Le query logging du Route 53 Resolver livré vers un log group CloudWatch (bonne réponse)
- Les CloudTrail management events, qui journalisent chaque résolution DNS
Le query logging du Route 53 Resolver enregistre les requêtes DNS émises depuis votre VPC et peut les envoyer vers CloudWatch Logs. Les Flow Logs montrent des IP et non des noms, l'agent n'a pas de journal de requêtes DNS, et CloudTrail ne capture pas les résolutions DNS.
5. Pour l'observabilité cross-account, qu'est-ce qui contrôle exactement quels comptes sources un compte de supervision peut lier ?
- La policy de l'observability sink dans le compte de supervision (bonne réponse)
- Un security group attaché individuellement à chaque compte source
- Une NACL sur le VPC par défaut du compte superviseur
- La bucket policy du bucket S3 d'artefacts
Le sink du compte de supervision porte une resource policy indiquant quels comptes sources ou chemins d'organisation peuvent créer des liens, définissant la frontière de confiance. Les security groups et NACL sont des contrôles réseau, et une bucket policy gère l'accès S3, pas les liens d'observabilité.
6. Une exigence de conformité impose d'isoler réseau automatiquement en quelques minutes toute instance signalée par GuardDuty. Quelle conception y répond ?
- Envoyer un e-mail à l'équipe sécurité pour une isolation manuelle
- Un audit hebdomadaire qui revoit les détections GuardDuty en lot
- EventBridge sur la détection invoquant un runbook qui change le SG (bonne réponse)
- Une liste d'IP de confiance GuardDuty qui ignore l'instance signalée
Une règle EventBridge sur la détection GuardDuty invoquant un SSM Automation runbook qui remplace le security group isole l'instance automatiquement en quelques minutes. L'e-mail manuel, l'audit hebdomadaire et les listes d'IP de confiance sont lents ou contre-productifs.