6.2 - Déploiement sécurisé et cohérent (CloudFormation, StackSets, Service Catalog)
L'objectif 6.2 de l'AWS Certified Security Specialty couvre le déploiement d'une infrastructure durcie identique partout et son maintien dans cet état. La détection de dérive CloudFormation révèle un groupe de sécurité élargi à la main hors de la stack, un change set montre si une mise à jour va remplacer une base de données avant application, une stack policy protège une clé KMS d'un remplacement pendant les mises à jour, DeletionPolicy Retain et la protection contre la suppression survivent à un delete accidentel, et un rollback bloqué en UPDATE_ROLLBACK_FAILED se débloque en poursuivant le rollback tout en sautant les ressources fautives. Les templates récupèrent un mot de passe de base via une référence dynamique vers Secrets Manager plutôt qu'un paramètre en clair, un scan de pipeline rejette un bucket public avant tout déploiement, et les CloudFormation Hooks refusent une ressource non conforme comme un volume non chiffré au moment du provisionnement, sans dépendre d'un pipeline. Les StackSets déploient à grande échelle : les permissions autogérées échouent quand le rôle d'exécution ou sa relation de confiance manque dans le compte cible, les permissions gérées par le service avec déploiement automatique atteignent chaque compte nouvellement créé dans une OU cible, la tolérance aux échecs et la concurrence maximale limitent la propagation d'une mauvaise mise à jour, et retirer une instance de stack peut conserver ses ressources. Service Catalog ajoute un rôle de contrainte de lancement, le partage de portefeuille par département, les tag options et les templates masqués. Attends-toi à des scénarios de contrôle du déploiement.
Refuser une ressource non conforme avant sa création, sans pipeline = CloudFormation Hooks. Déployer automatiquement vers chaque compte ajouté à une OU = StackSets à permissions gérées par le service avec déploiement automatique. Des utilisateurs lancent un produit qui crée des rôles IAM qu'ils ne peuvent pas créer = rôle de contrainte de lancement Service Catalog.
Questions d'entraînement
1. Une equipe securite doit deployer la meme pile de journalisation durcie dans quarante comptes sur trois regions, et dans tout compte ajoute plus tard a la meme UO. Quel mecanisme convient ?
- Un script shell qui parcourt la liste des comptes et lance create-stack dans chacun, relance a la main des qu'un nouveau compte apparait dans l'organisation
- Des StackSets CloudFormation avec permissions gerees par le service et deploiement automatique (bonne réponse)
- Une pile CloudFormation unique dans le compte de gestion avec des references de ressources inter comptes
- Une AMI contenant l'agent de journalisation et partagee avec l'organisation
Les StackSets deploient un modele unique vers de nombreux comptes et regions, et avec les permissions gerees par le service et le deploiement automatique actif, tout compte qui rejoint l'UO cible recoit la pile sans intervention humaine. Un script en boucle doit etre relance et derive, une pile unique ne peut pas creer de ressources dans d'autres comptes, et une AMI ne couvre que les instances, pas la configuration du compte.
2. Des developpeurs doivent pouvoir creer eux memes des bases de donnees, mais uniquement a partir de configurations validees par l'equipe securite. Quel service repond a ce besoin ?
- AWS Service Catalog (bonne réponse)
- AWS Config, qui enregistre en continu la configuration des ressources et signale toute base qui s'ecarte des parametres approuves
- AWS Systems Manager Parameter Store
- Amazon EventBridge
Service Catalog publie des produits CloudFormation approuves dans un portefeuille que les utilisateurs lancent a la demande, donc le libre service se fait dans un modele valide. Config ne signale qu'apres coup et ne peut pas empecher un mauvais lancement, Parameter Store contient des valeurs de configuration plutot qu'une logique d'approvisionnement, et EventBridge achemine des evenements sans rien provisionner.
3. Quelqu'un a elargi a la main un groupe de securite pourtant cree par une pile CloudFormation. Quelle fonction native revele que la ressource reelle ne correspond plus au modele ?
- Les politiques de pile
- Les jeux de changements
- La protection contre la suppression, qui bloque toute operation supprimant des ressources gerees par la pile et signale celles modifiees en dehors
- La detection de derive (bonne réponse)
La detection de derive compare chaque ressource geree aux proprietes declarees dans le modele et liste les ecarts. Les politiques de pile restreignent ce qu'une mise a jour peut toucher, les jeux de changements previsualisent une mise a jour que vous allez appliquer, et la protection contre la suppression empeche seulement la suppression de la pile et ne signale rien des modifications manuelles.
4. Un StackSet utilise des permissions auto gerees. Le deploiement vers un compte cible echoue avec une erreur d'acces. Quelle est la cause la plus probable ?
- Le role d'execution est absent du compte cible ou ne fait pas confiance au role d'administration (bonne réponse)
- Le modele du StackSet reference un type de ressource indisponible dans la region cible, ce que le service remonte comme un echec de permission plutot que comme un type non pris en charge
- Les permissions auto gerees ne fonctionnent que dans le compte de gestion
- Le deploiement automatique a ete laisse desactive sur le StackSet
Avec des permissions auto gerees, vous creez vous meme les deux roles : un role d'administration dans le compte source et un role d'execution dans chaque compte cible dont la politique de confiance nomme le role d'administration. Un type de ressource indisponible dans la region leve une erreur de type non pris en charge, pas une erreur d'acces, les permissions auto gerees sont justement le mode utilise hors Organizations, et le deploiement automatique est une fonction du mode gere par le service qui concerne les nouveaux comptes, pas l'acces.
5. Un pipeline doit rejeter un modele d'infrastructure qui declare un bucket S3 public, avant tout deploiement. Quelle approche convient ?
- Une regle AWS Config qui evalue les buckets une fois la pile creee
- Une analyse statique du modele avec CloudFormation Guard a l'etape de build (bonne réponse)
- Une alarme CloudWatch sur le nombre d'objets servis publiquement par le bucket, reliee a une rubrique de notification qui alerte l'ingenieur securite d'astreinte
- Une revue manuelle mensuelle des modeles stockes dans le depot
CloudFormation Guard evalue le modele en tant que fichier face a des regles de politique, donc le build echoue et rien n'est jamais provisionne. Une regle Config, une alarme CloudWatch et une revue mensuelle agissent toutes une fois le bucket public existant, c'est a dire pendant la fenetre que l'exigence demande justement de supprimer.
6. Un modele CloudFormation a besoin d'un mot de passe de base de donnees. Comment le modele doit il l'obtenir sans exposer la valeur ?
- Avec une reference dynamique a AWS Secrets Manager (bonne réponse)
- Avec un parametre de modele dont la valeur par defaut contient le mot de passe, puisque les valeurs par defaut sont stockees chiffrees au repos par le service CloudFormation lui meme
- Avec une section Mappings listant un mot de passe par environnement
- En codant le mot de passe en dur et en restreignant qui peut lire le bucket S3 qui contient le modele
Une reference dynamique resout le secret au moment du deploiement, donc la valeur ne figure jamais dans le modele, dans le depot ni dans l'historique de la pile. Les valeurs par defaut de parametres sont stockees et visibles en clair, les Mappings le sont aussi, et restreindre l'acces au bucket laisse malgre tout le secret ecrit dans un fichier que toute personne disposant de la description de la pile peut recuperer.