4.1 - Identité et protection des données (IAM, KMS, Secrets Manager)
L'objectif 4.1 de l'AWS SysOps Administrator couvre la sécurisation des accès et la protection des données. L'évaluation des politiques IAM suit le moindre privilège : un Deny explicite l'emporte toujours, et les permissions effectives sont l'intersection des politiques d'identité, des permission boundaries et des Service Control Policies. Tu attaches des rôles aux services plutôt que de stocker des clés, tu utilises des profils d'instance, et tu revois les accès avec le credential report et IAM Access Analyzer. AWS KMS protège les données avec des clés gérées par le client régies par des politiques de clés et des grants, prend en charge la rotation automatique annuelle, les alias et les clés multi-régions, et sous-tend le chiffrement au repos pour S3, EBS, RDS et DynamoDB. Secrets Manager stocke des identifiants et les fait tourner via Lambda, tandis que le SecureString de Parameter Store est une option moins chère sans rotation native. Attends-toi à des mises en situation sur la bonne fonction IAM, KMS ou de secrets.
Permission effective = politique d'identité inter boundary inter SCP, et un Deny explicite gagne toujours. Rotation automatique d'identifiants = Secrets Manager. Chiffrer au repos avec une clé gouvernée = clé KMS gérée par le client.
Questions d'entraînement
1. Vous voulez une alarme de facturation CloudWatch sur EstimatedCharges. Dans quelle région devez-vous la créer ?
- US East (Virginie du Nord), us-east-1 (bonne réponse)
- N'importe quelle région, si les métriques de facturation sont activées avant
- La région la plus proche de vos charges de travail de production
- EU (Irlande), eu-west-1, la région de facturation par défaut
Les métriques de facturation (EstimatedCharges) ne sont publiées que dans us-east-1, donc l'alarme doit y être créée. Il faut aussi activer 'Receive Billing Alerts', mais cela ne déplace pas la métrique ailleurs.
2. Quelle est la façon recommandée d'accorder aux instances EC2 la permission d'envoyer métriques et logs via le CloudWatch agent ?
- Attacher aux instances un rôle IAM avec CloudWatchAgentServerPolicy (bonne réponse)
- Intégrer une clé d'accès IAM permanente dans le fichier de config sur disque
- Ouvrir les instances à Internet public sur le port TCP 443
- Désactiver IMDS pour que l'agent bascule en accès anonyme
Attacher un rôle d'instance avec la policy managée CloudWatchAgentServerPolicy fournit des identifiants temporaires et renouvelés via IMDS, la bonne pratique. Coder en dur une clé permanente est un risque de sécurité et inutile.
3. Les instances lancées par un Auto Scaling group doivent appeler S3 sans clés statiques. Où attachez-vous les permissions dans la launch template ?
- Coder en dur des clés d'accès dans les user data
- Une règle entrante de security group
- Un IAM instance profile (rôle) (bonne réponse)
- Une NACL sur le sous-réseau
Un IAM instance profile attache un rôle pour que les instances obtiennent des identifiants temporaires rotatifs sans clés statiques. Les security groups et NACL contrôlent le trafic réseau, et coder des clés en dur est un risque de sécurité sérieux.
4. Les auditeurs exigent que CloudWatch Logs soit chiffré avec une clé que vous contrôlez. Que faites-vous ?
- Déplacer tous les logs vers un bucket S3 car les log groups ne se chiffrent pas
- Activer le SSE sur le subscription filter qui exporte les événements
- Associer une clé KMS customer managed au log group (bonne réponse)
- Activer un mode conformité spécial qui fait tourner en secret une clé AWS-owned
On associe une clé KMS customer managed au log group afin de chiffrer avec une clé que vous possédez et auditez. Les log groups sont chiffrables, les subscription filters n'ont pas de bascule SSE, et il n'existe pas de mode conformité auto-rotatif caché.
5. Vous attachez une clé KMS customer managed à un log group mais l'ingestion échoue. Quelle en est la cause habituelle ?
- La rétention du log group dépasse ce que la clé KMS autorise
- La key policy KMS n'autorise pas le service principal de CloudWatch Logs (bonne réponse)
- Les clés customer managed ne marchent pas avec CloudWatch Logs, seulement S3
- L'agent doit être réinstallé à zéro chaque fois qu'une nouvelle clé est attachée
La key policy KMS doit accorder à logs.<region>.amazonaws.com les actions encrypt/decrypt avec la bonne condition, sinon CloudWatch Logs ne peut pas utiliser la clé et l'ingestion casse. La rétention n'a rien à voir, les CMK sont supportées, et l'agent n'a pas à être réinstallé.
6. Un Synthetics canary doit écrire ses captures et fichiers HAR dans S3. Qu'accorde cet accès ?
- Une resource policy sur le dashboard CloudWatch
- Une ACL de bucket publique ouverte à tout internet
- Le rôle d'exécution IAM du canary avec droits S3 (bonne réponse)
- Une règle de security group autorisant la sortie vers le service S3
Un canary s'exécute via une fonction basée sur Lambda assumant un rôle IAM d'exécution, des droits S3 sur ce rôle lui permettent donc de stocker ses artefacts. Une policy de dashboard n'a aucun rapport, une ACL publique est non sécurisée et inutile, et un security group gère l'accessibilité réseau, pas l'autorisation S3.