3.2 - Concevoir des contrôles de sécurité réseau internes (groupes de sécurité, NACL, endpoints, Flow Logs, Reachability Analyzer)
L'objectif 3.2 de l'AWS Certified Security Specialty couvre la segmentation à l'intérieur du VPC. Un groupe de sécurité est à état, s'attache à une interface réseau élastique, n'autorise que des allow, et laisse repasser le trafic de retour automatiquement ; une ACL réseau est sans état, s'applique à un sous-réseau entier, accepte les deny, et évalue les règles par numéro croissant jusqu'à la première correspondance : un flux de retour rejeté alors que la règle sortante est correcte désigne donc directement une plage de ports éphémères absente de la NACL. Un nouveau groupe de sécurité autorise tout en sortie et rien en entrée, et référencer un autre groupe de sécurité comme source est la façon propre d'autoriser une flotte qui se redimensionne sans cesse. Un sous-réseau est privé parce que sa table de routage n'a aucune route vers une passerelle internet, les gateway endpoints gardent le trafic S3 et DynamoDB sur le réseau AWS avec une politique d'endpoint limitant l'accès aux buckets de l'organisation, les interface endpoints se restreignent avec leur propre groupe de sécurité, et une prefix list nomme un ensemble de CIDR une fois pour toutes. AWS Network Firewall filtre la sortie par nom de domaine, le Route 53 Resolver DNS Firewall coupe le tunneling DNS, le Traffic Mirroring capture la charge utile, les Flow Logs affichent ACCEPT ou REJECT, et Reachability Analyzer prouve qu'un chemin est bloqué et nomme le composant fautif.
Groupe de sécurité à état et allow seulement ; ACL réseau sans état, ordonnée, et capable de deny. Trafic de retour rejeté alors que la sortie est ouverte = ports éphémères absents de la NACL. Prouver qu'un chemin est bloqué sans envoyer un paquet = Reachability Analyzer.
Questions d'entraînement
1. Vous creez une ACL reseau toute neuve et l'associez a un sous-reseau, sans ecrire la moindre regle. Qu'advient-il du trafic de ce sous-reseau ?
- Tout continue de circuler dans les deux sens jusqu'a la premiere regle ecrite, exactement comme l'ACL reseau par defaut livree avec un VPC neuf
- Tout le trafic entrant et sortant est refuse (bonne réponse)
- Seul le trafic entre sous-reseaux du meme VPC continue de circuler
- Les regles de l'ACL reseau par defaut sont recopiees dans la nouvelle
Une ACL reseau que vous creez vous-meme demarre avec un seul refus implicite dans chaque sens, si bien que l'associer coupe aussitot le sous-reseau. Seule l'ACL reseau par defaut creee avec le VPC autorise tout, rien n'en est recopie dans une ACL neuve, et il n'existe aucune exception integree pour le trafic interne au VPC.
2. Vous publiez un service interne via AWS PrivateLink. Quel reglage decide quels comptes consommateurs peuvent creer un point de terminaison vers lui ?
- Le groupe de securite du Network Load Balancer, dont les regles entrantes doivent lister les plages d'adresses privees de chaque VPC consommateur approuve
- Une politique de ressource attachee au Network Load Balancer lui-meme
- La liste des principaux autorises du service de point de terminaison (bonne réponse)
- Une politique de point de terminaison que le consommateur attache de son cote
Le fournisseur accorde l'acces en ajoutant des ARN de compte, d'utilisateur ou de role aux principaux autorises du service de point de terminaison, avec au besoin une acceptation manuelle de chaque demande de connexion. Un repartiteur de charge n'accepte pas de politique de ressource, les adresses du consommateur ne sont jamais visibles du fournisseur car PrivateLink ne route pas entre les VPC, et une politique ecrite par le consommateur ne peut pas lui donner un droit que le fournisseur a refuse.
3. En quoi les groupes de securite et les NACL different-ils au sein d'un VPC ?
- Les deux sont sans etat, donc chaque sens d'un flux doit etre autorise par sa propre regle explicite a l'aller puis de nouveau au retour
- Les deux sont avec etat et acceptent des refus, la seule vraie difference etant que l'un s'attache a une instance et l'autre a un sous-reseau
- Un groupe de securite est avec etat et n'autorise que ; une NACL est sans etat et refuse aussi (bonne réponse)
- Le groupe de securite est evalue apres la NACL en entree et avant elle en sortie, ce qui explique que l'ordre des regles compte
Un groupe de securite est avec etat : le trafic de retour d'un flux autorise passe automatiquement, et il n'exprime que des autorisations. Une NACL est sans etat, evalue l'entree et la sortie separement par numero de regle, et sait refuser explicitement. Aucun des deux n'est sans etat des deux cotes, un groupe de securite n'accepte jamais de regle de refus, et ils ne s'enchainent pas dans un ordre fixe dependant du sens.
4. Les instances d'un sous-reseau ouvrent des connexions HTTPS sortantes mais chaque reponse est perdue. Le groupe de securite autorise tout le trafic sortant. Que faut-il inspecter en premier ?
- Les regles entrantes du groupe de securite, qui doivent autoriser explicitement les paquets de reponse de toute connexion ouverte par l'instance
- Le resolveur DNS du VPC, car un echec partiel de resolution se traduit normalement par des reponses qui arrivent puis sont silencieusement jetees
- Le role IAM de l'instance, dont la politique doit permettre le service de destination avant que la pile reseau accepte les paquets de retour
- Les regles entrantes de la NACL pour la plage de ports ephemeres (bonne réponse)
Une NACL est sans etat : la reponse d'une connexion sortante arrive sur un port ephemere et exige sa propre regle entrante d'autorisation, typiquement 1024 a 65535. Le groupe de securite n'a besoin de rien car il est avec etat et suit deja le flux, une panne DNS casse la resolution de noms plutot que des sessions etablies, et IAM ne filtre jamais de paquets.
5. Des instances d'un sous-reseau prive doivent atteindre Amazon S3 sans que le trafic quitte le reseau AWS. Quel type de point de terminaison convient ?
- Un point de terminaison d'interface, qui place une interface reseau elastique avec adresse privee dans chaque sous-reseau choisi
- Un point de terminaison de passerelle, ajoute comme route dans la table de routage du sous-reseau (bonne réponse)
- Une passerelle NAT dans le sous-reseau public, associee a une passerelle internet sur le VPC et une route par defaut sortante
- Une interface virtuelle Direct Connect terminee sur une passerelle privee virtuelle attachee au VPC qui heberge le sous-reseau
S3 et DynamoDB sont les deux services desservis par des points de terminaison de passerelle, qui passent par une liste de prefixes dans la table de routage et ne coutent rien. Un point d'interface existe pour S3 mais n'est pas la reponse classique ici et se facture a l'heure et au gigaoctet, une passerelle NAT enverrait le trafic vers le point de terminaison public de S3, et Direct Connect relie un site sur place plutot qu'il n'isole un sous-reseau.
6. Vous voulez que le trafic quittant un VPC par un point de terminaison de passerelle S3 n'atteigne que des buckets de votre organisation. Ou exprimez-vous cela ?
- Dans une politique de point de terminaison VPC, avec aws:PrincipalOrgID ou une liste de buckets (bonne réponse)
- Dans le groupe de securite de chaque instance, dont les regles sortantes doivent nommer les plages d'adresses publiques publiees par S3 pour la region
- Dans la table de routage du sous-reseau, en pointant la liste de prefixes S3 vers une destination plus precise ne couvrant que les buckets de l'organisation
- Dans une regle entrante de NACL sur le sous-reseau prive, refusant les plages d'adresses de tout bucket S3 appartenant a un compte etranger
Une politique de point de terminaison est une politique de ressource evaluee a chaque requete qui transite par le point, donc une condition sur l'identifiant d'organisation bloque les copies vers le bucket d'un inconnu. Les groupes de securite et les NACL ne voient que des adresses et ne distinguent pas un bucket d'un autre, et une table de routage choisit un chemin, pas un bucket.