1.2 - Sécurité multi-comptes et services partagés (VPC d'inspection, RAM, Managed AD, OIDC)
L'objectif 1.2 de l'AWS Solutions Architect Professional couvre la centralisation de la sécurité et des services partagés pour de nombreux comptes. Tu inspectes le trafic de dizaines de VPC via un VPC d'inspection central, avec un Gateway Load Balancer et des appliances tierces ou AWS Network Firewall à règles stateful gérées centralement, le tout atteint par Transit Gateway. Tu neutralises le problème du deputy confus en exigeant un external ID unique sur AssumeRole inter-comptes, et tu protèges un bucket central d'archive de journaux avec S3 Object Lock en mode compliance plus une SCP qui refuse la suppression. AWS Resource Access Manager partage des sous-réseaux et ressources vers des comptes ou OU sans invitations, AWS Managed Microsoft AD fournit un vrai Active Directory avec Group Policy et trusts, et le Route 53 Resolver DNS Firewall bloque les domaines malveillants à l'échelle de l'org. Un pipeline déploie sans clés durables en fédérant via un fournisseur OIDC IAM et en conditionnant AssumeRoleWithWebIdentity sur le claim du dépôt. Attends-toi à des mises en situation sur l'inspection centralisée, les journaux inviolables ou le CI/CD sans clés, et à choisir la bonne conception de sécurité.
Inspecter tout le trafic VPC au même endroit = VPC d'inspection central (GWLB ou Network Firewall) via Transit Gateway. Un tiers assume ton rôle sans risque = exiger un external ID unique. CI/CD sans clés stockées = fournisseur OIDC IAM + AssumeRoleWithWebIdentity.
Questions d'entraînement
1. Les auditeurs exigent que les développeurs puissent créer des rôles IAM mais ne puissent jamais leur donner plus de permissions qu'un plafond défini, même par erreur. Qu'est-ce qui impose ce plafond sur les rôles qu'ils créent ?
- Une SCP sur le compte des développeurs qui refuse iam:CreateRole
- Une politique de ressource attachée automatiquement à chaque nouveau rôle
- Une permissions boundary que les développeurs doivent attacher à chaque rôle créé (bonne réponse)
- Un groupe IAM auquel les nouveaux rôles sont ajoutés à la création
Une permissions boundary plafonne les permissions effectives d'un rôle ; on exige (via une condition sur iam:CreateRole) que les développeurs attachent la boundary, de sorte qu'un rôle ne peut jamais la dépasser. Refuser CreateRole supprime toute délégation, et les groupes s'appliquent aux utilisateurs, pas aux rôles.
2. Une equipe securite veut que tout le trafic internet sortant de dizaines de VPC passe par un point d'inspection unique executant des appliances pare-feu tierces, le trafic y etant dirige de maniere transparente. Quelle conception convient ?
- Un interface endpoint par VPC pointant vers l'API de gestion de l'editeur du pare-feu pour synchroniser la politique
- Des NAT gateways individuelles deployees dans chaque VPC combinees a une journalisation verbeuse des security groups
- Un VPC d'inspection central avec un Gateway Load Balancer et les appliances, atteint via Transit Gateway (bonne réponse)
- Une interface virtuelle publique sur Direct Connect routant toute la sortie vers le pare-feu du data center
Un Gateway Load Balancer distribue le trafic de maniere transparente vers une flotte d'appliances pare-feu via l'encapsulation GENEVE ; le placer dans un VPC d'inspection central et y router la sortie des VPC spoke via Transit Gateway inspecte tout le trafic sortant en un seul endroit. Les NAT gateways par VPC evitent l'inspection par appliance, les interface endpoints ciblent des services et non des pare-feu quelconques, et une VIF publique sert a atteindre les points publics d'AWS.
3. Un architecte doit garantir qu'un interface endpoint S3 n'est utilise que par des principals de l'organisation et seulement pour deux buckets precis. Quel controle exprime ces restrictions sur l'endpoint ?
- Un security group sur l'endpoint qui liste explicitement chacun des buckets autorises par leur nom
- Une network ACL qui restreint tout le sous-reseau de l'endpoint aux plages d'IP publiees du service S3
- Une SCP attachee directement sur l'interface reseau elastique de l'endpoint pour contraindre les appelants
- Une VPC endpoint policy autorisant uniquement ces principals et ARN de buckets (bonne réponse)
Une VPC endpoint policy est une politique de ressource sur l'endpoint qui peut restreindre les principals, actions et ARN de ressources autorises, donc limiter l'usage a l'organisation et a deux ARN de buckets. Les security groups et NACL filtrent par IP/port et non par bucket ou principal, et les SCP s'attachent a des comptes et OU, pas a des interfaces reseau.
4. Une regle de conformite exige de bloquer la resolution DNS de domaines malveillants connus pour toutes les requetes issues de plusieurs VPC, en gestion centralisee. Quel service l'architecte doit-il deployer ?
- Des network ACL qui refusent l'UDP sortant sur le port 53 sur chaque sous-reseau de tous les VPC concernes
- Des regles AWS WAF qui inspectent les requetes et correspondent a la liste des noms de domaines malveillants connus
- Des rule groups Route 53 Resolver DNS Firewall partages aux VPC (bonne réponse)
- Des security groups referencant une prefix list geree centralement contenant les IP des serveurs malveillants
Route 53 Resolver DNS Firewall filtre les requetes DNS sortantes contre des rule groups de domaines et peut etre associe a (et partage vers) de nombreux VPC pour une gestion centrale. Bloquer le port 53 casse tout le DNS, WAF inspecte le HTTP(S) et non le DNS, et des prefix lists d'IP ne correspondent pas a des noms de domaine dans les requetes DNS.
5. Des regulateurs exigent que le trafic sur une VIF privee Direct Connect existante soit chiffre en transit, mais une VIF privee seule transporte du trafic en clair. Quelles DEUX approches peuvent ajouter du chiffrement sur Direct Connect ? (Choisissez DEUX reponses.)
- Executer un VPN IPsec Site-to-Site sur une VIF publique Direct Connect (bonne réponse)
- Basculer la VIF privee en VIF publique pour qu'AWS chiffre alors automatiquement tout son trafic
- Activer le chiffrement cote serveur Amazon S3 sur chacun des VPC endpoints situes le long du chemin du trafic
- Activer MACsec sur un port et un equipement Direct Connect compatibles (bonne réponse)
Deux schemas chiffrent le trafic DX : un VPN IPsec Site-to-Site sur une VIF publique fournit un tunnel chiffre sur le chemin DX, et MACsec offre un chiffrement de couche 2 sur les ports et equipements Direct Connect compatibles. Une VIF publique n'est pas chiffree automatiquement, et le chiffrement cote serveur S3 protege les donnees au repos, pas la liaison DX en transit.
6. Un architecte veut garantir que les comptes membres ne puissent pas creer d'internet gateways ni supprimer les rattachements du transit gateway partage, quelles que soient les permissions IAM accordees localement. Qu'est-ce qui impose cela au niveau de l'organisation ?
- Une permissions boundary attachee individuellement au role d'administration reseau propre a chaque compte
- Une service control policy refusant ces actions sur les OU (bonne réponse)
- Une VPC endpoint policy ecrite pour restreindre quels appels d'API reseau peuvent traverser les endpoints
- Un partage de ressources RAM qui limite exactement quels comptes membres peuvent voir le transit gateway
Une SCP appliquee aux OU fixe un plafond de permissions qui refuse ec2:CreateInternetGateway et les actions de suppression de rattachement pour chaque principal de ces comptes, l'emportant sur toute autorisation IAM locale. Les permissions boundaries ne plafonnent que les principals precis auxquels on les attache, les endpoint policies restreignent le trafic des endpoints, et RAM controle le partage et non le refus d'actions.