Amazon SCS-C02: Réseau et sécurité VPC — Guide d'étude

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Fait partie du AWS Security Specialty SCS-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Points de terminaison VPC et stratégies de point de terminaison

Les points de terminaison VPC (VPC endpoints) maintiennent le trafic vers les services AWS sur le réseau AWS, en contournant l’Internet public, les passerelles NAT et les passerelles Internet. Il en existe deux types structurellement différents, et les confondre est l’une des erreurs de conception les plus courantes.

Les points de terminaison de passerelle (Gateway endpoints) n’existent que pour Amazon S3 et DynamoDB. Ce sont des entrées de table de routage — vous associez le point de terminaison à des tables de routage, et le trafic destiné à la liste de préfixes du service (par exemple pl-63a5400a pour S3 dans us-east-1) est discrètement redirigé via le point de terminaison. Ils sont gratuits et ne peuvent pas être atteints depuis l’extérieur du VPC auquel ils sont rattachés.

Les points de terminaison d’interface (Interface endpoints), basés sur AWS PrivateLink, sont des ENI avec des adresses IP privées placées dans vos sous-réseaux. Ils sont requis pour tous les services qui ne sont pas S3 ou DynamoDB — Secrets Manager, KMS, STS, SSM, CloudWatch Logs, ECR API/DKR, et des centaines d’autres. Si une instance EC2 dans un sous-réseau privé sans passerelle NAT doit exécuter GetSecretValue depuis Secrets Manager, un point de terminaison de passerelle ne sera d’aucune aide ; vous devez créer un point de terminaison d’interface com.amazonaws.<region>.secretsmanager et activer le DNS privé pour que le nom d’hôte standard du service se résolve en l’adresse IP privée du point de terminaison.

Les stratégies de point de terminaison (Endpoint policies) limitent ce qui peut être fait via le point de terminaison, indépendamment des stratégies IAM de l’appelant. Les deux clés de condition les plus importantes pour empêcher l’exfiltration de données sont aws:PrincipalOrgID (l’identité effectuant l’appel doit appartenir à votre organisation - Organization) et aws:ResourceOrgID (le compartiment S3, la clé KMS, etc. concerné(e) doit appartenir à votre organisation - Organization). L’application des deux ferme la voie d’exfiltration classique où une instance compromise avec des autorisations S3 légitimes écrit dans un compartiment contrôlé par un attaquant en dehors de votre organisation — les informations d’identification fonctionnent toujours avec S3, mais le point de terminaison refuse de transmettre la requête.

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-abc123",
        "aws:ResourceOrgID":  "o-abc123"
      }
    }
  }]
}

La stratégie de point de terminaison par défaut est entièrement permissive ("Action":"*" sur "Resource":"*"), c’est pourquoi un sous-réseau avec seulement un point de terminaison de passerelle et des autorisations IAM de moindre privilège peut toujours être exploité pour l’exfiltration, à moins que vous ne resserriez la stratégie du point de terminaison elle-même.

Connectivité hybride : VPN et Direct Connect

Un VPN de site à site (Site-to-Site VPN) établit deux tunnels IPsec entre une passerelle privée virtuelle (virtual private gateway) (ou une passerelle de transit - Transit Gateway) et un équipement de passerelle client (customer gateway device). Il est rapide à provisionner, chiffré par défaut, et transite par l’Internet public — le débit et la latence dépendent donc du chemin de votre FAI.

AWS Direct Connect provisionne un circuit physique dédié via un emplacement Direct Connect. Il fournit une faible latence prévisible et une bande passante élevée et constante (1/10/100 Gbps), ce qui est important pour le trafic de base de données sur site bavard (« chatty »). Direct Connect n’est pas chiffré au niveau de la couche 3 par lui-même ; les trames circulent sur de la fibre privée. Pour les charges de travail qui nécessitent à la fois une faible latence et IPsec, la réponse canonique est Direct Connect plus un VPN de site à site fonctionnant sur une VIF publique (ou une Transit Gateway avec MACsec sur les ports DX plus récents). Le VPN seul est également la solution de secours chiffrée recommandée pour une liaison Direct Connect principale, offrant une résilience en cas de défaillance du circuit.

Direct Connect seul : faible latence, privé, mais non chiffré au niveau de la couche IP.
VPN seul : chiffré, rapide à déployer, mais avec la latence et la gigue du chemin Internet.
Direct Connect + VPN : faible latence et chiffrement IPsec ; également le modèle standard de haute disponibilité (HA).

Groupes de sécurité, NACL, DHCP et vérifications Source/Dest

Les groupes de sécurité (Security groups) sont stateful (avec état) : si vous autorisez une requête entrante, la réponse est automatiquement autorisée en sortie. Ils ne prennent en charge que des règles d’autorisation (allow) et sont évalués par ENI.

Les ACL réseau (NACLs) sont stateless (sans état) et fonctionnent à la frontière du sous-réseau. Chaque flux nécessite deux règles — une pour la direction initiale et une pour le trafic de retour sur la plage de ports éphémères (Linux typiquement 32768–60999, Windows 49152–65535, et les NLB/ELB utilisent 1024–65535). Une NACL qui autorise le TCP 443 entrant mais oublie le TCP 1024–65535 sortant interrompra discrètement le TLS. ICMP n’est pas TCP/UDP : les paquets de retour « echo reply » doivent être autorisés explicitement, et la découverte du MTU de chemin (Path MTU Discovery) repose sur ICMP type 3 code 4, qu’il est facile de bloquer par inadvertance. Les règles NACL sont également évaluées par ordre numérique, la première correspondance l’emporte, avec un refus (deny) implicite à la fin.

Les jeux d’options DHCP (DHCP option sets) contrôlent ce qu’un VPC fournit aux instances au démarrage : domain-name-servers, domain-name, serveurs NTP, NetBIOS. Remplacer le AmazonProvidedDNS par défaut par un résolveur personnalisé sur site peut être légitime, mais cela a de réelles conséquences en matière de sécurité. Des services comme GuardDuty dérivent des résultats basés sur le DNS (par exemple les détections de « cryptomonnaie » et de « domaine C&C ») à partir des requêtes qui traversent le résolveur Route 53. Une fois que vous dirigez les instances vers un serveur DNS tiers, GuardDuty cesse de voir les requêtes et ces types de résultats disparaissent — un moyen facile de rendre la détection aveugle accidentellement.

La vérification source/destination (Source/destination checking) est un attribut d’ENI qui rejette tout paquet dont l’IP source ou destination ne correspond pas à l’ENI. Ce comportement par défaut est correct pour les instances ordinaires mais interrompt le fonctionnement de toute appliance dont le rôle est de transférer du trafic — instances NAT, pare-feux virtuels (Palo Alto, Fortinet, Check Point), routeurs de transit, concentrateurs VPN. Pour ces ENI, désactivez la vérification :

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --no-source-dest-check

Peering de VPC, VPC partagés via RAM et conception NAT

Le peering de VPC est une liaison de couche 3, un-à-un et non transitive. Si A est appairé avec B et B avec C, A ne peut pas atteindre C — vous devez appairer A et C directement ou utiliser un Transit Gateway. Les tables de routage des deux côtés doivent contenir des routes vers le CIDR du pair, et les groupes de sécurité ne peuvent référencer les ID de groupes de sécurité pairs qu’au sein d’une même Région.

Les VPC partagés via AWS Resource Access Manager (RAM) permettent à un compte réseau de posséder un VPC et de partager des sous-réseaux individuels avec des comptes participants. Les participants lancent des ressources dans les sous-réseaux partagés mais ne peuvent pas modifier le VPC, les tables de routage ou les points de terminaison — le propriétaire conserve le contrôle de la politique de connectivité. C’est souvent moins cher et plus simple que d’appairer de nombreux VPC.

Pour le trafic Internet sortant depuis les sous-réseaux privés, déployez une passerelle NAT par zone de disponibilité et routez chaque sous-réseau privé vers la passerelle NAT de sa propre AZ. Une seule passerelle NAT constitue une dépendance inter-AZ et un goulot d’étranglement en termes de scalabilité et de disponibilité. Lorsque votre charge de travail appelle un tiers qui utilise des listes d’autorisation IP pour votre trafic sortant (un processeur de paiement, par exemple), c’est l’adresse IP Elastic de la passerelle NAT que vous enregistrez. Et comme les instances derrière un groupe Auto Scaling sortent toutes par cette EIP fixe, l’IP source ne change pas lorsque le groupe se met à l’échelle. Placer les instances EC2 et la base de données RDS dans des sous-réseaux privés et ne terminer que le trafic HTTP/HTTPS sur l’ALB complète ce modèle.

Route 53 Resolver : Redirection et journalisation des requêtes

Le Route 53 Resolver (l’adresse .2 dans chaque VPC) est le pivot du DNS hybride. Les points de terminaison de résolveur sortants redirigent les noms de domaine spécifiés depuis AWS vers des serveurs DNS sur site via des règles de redirection conditionnelle — utilisés, par exemple, pour que corp.example.internal soit résolu par votre Active Directory. Les points de terminaison de résolveur entrants font l’inverse, en fournissant aux hôtes sur site une IP privée dans votre VPC qu’ils peuvent interroger pour résoudre *.eu-west-1.compute.internal et les zones hébergées privées (Private Hosted Zones).

La journalisation des requêtes du résolveur (Resolver query logging) écrit chaque requête DNS effectuée depuis le VPC vers CloudWatch Logs, S3 ou Kinesis Firehose. C’est l’enregistrement de référence pour enquêter sur une exfiltration ou une utilisation abusive suspectée et il complète — mais ne remplace pas — GuardDuty. N’oubliez pas que si un jeu d’options DHCP redirige les instances vers un résolveur non-Amazon, la journalisation des requêtes et les détections DNS de GuardDuty deviennent inopérantes, car les requêtes n’atteignent jamais le Route 53 Resolver.

Problème pratique : Scénario d’utilisation

Scénario : Meridian Financial gère un environnement AWS multi-comptes avec un réseau en étoile (hub-and-spoke) : un VPC de services partagés, partagé via RAM, héberge des passerelles NAT centrales, des points de terminaison Route 53 Resolver et des attachements Transit Gateway, tandis que plusieurs VPC applicatifs sont appairés ou attachés au Transit Gateway. Les datacenters sur site se connectent via Direct Connect avec un basculement VPN, et les équipes s’appuient sur des jeux d’options DHCP centralisés et des points de terminaison de résolveur partagés pour la résolution DNS hybride.

Défi : Un incident récent a montré que des objets S3 sensibles étaient accessibles via l’Internet public parce que les VPC satellites (spokes) routaient vers la NAT partagée au lieu des points de terminaison de VPC, que des requêtes DNS pour des zones internes fuitaient vers des résolveurs publics, et qu’une instance EC2 utilisée comme routeur ad-hoc (vérification source/destination désactivée) permettait un mouvement latéral.

Approche recommandée :

Déployer des points de terminaison de VPC de type passerelle (Gateway) pour S3 et DynamoDB et des points de terminaison d’interface (AWS PrivateLink) pour Secrets Manager et KMS dans le VPC de services partagés, en attachant des politiques de point de terminaison explicites qui restreignent l’accès à des buckets et des principaux de service nommés.
Remanier la conception NAT pour que les sous-réseaux applicatifs utilisent des points de terminaison de VPC pour les API AWS et S3 ; conserver les passerelles NAT uniquement pour le trafic sortant Internet authentique avec des groupes de sécurité de sortie stricts et des Flow Logs vers CloudWatch/S3.
Réactiver la vérification source/destination sur toutes les instances EC2, à l’exception des appliances de routage documentées ; déplacer le routage vers des attachements Transit Gateway ou des instances NAT gérées et appliquer le moindre privilège aux tables de routage.
Renforcer les groupes de sécurité et les NACL de sous-réseau avec une posture de refus par défaut, et appliquer des bases de référence centralisées pour IAM+SG via les SCP d’AWS Organizations et les règles AWS Config.
Durcir le DNS hybride en déployant des points de terminaison de résolveur entrants/sortants Route 53, configurer des règles de redirection conditionnelle et de DNS Firewall, activer la journalisation des requêtes du résolveur vers CloudWatch Logs, et utiliser des jeux d’options DHCP pour imposer l’utilisation des résolveurs internes pour tous les VPC partagés via RAM.

Justification : Cette approche supprime le trafic sortant Internet inutile en utilisant des points de terminaison de VPC avec des politiques de point de terminaison, centralise et contrôle le routage via Transit Gateway/Direct Connect, restaure les protections au niveau de l’instance, et empêche la fuite de requêtes DNS avec les points de terminaison du résolveur et la journalisation — s’alignant ainsi sur les meilleures pratiques d’AWS en matière de réseau et de défense en profondeur.

Points de terminaison de VPC et politiques de point de terminaison

Les points de terminaison de VPC permettent aux charges de travail à l’intérieur d’un VPC d’atteindre les API des services AWS sans transiter par l’internet public ou une passerelle NAT. Il existe deux variantes architecturales, et choisir la mauvaise est une source fréquente d’erreurs de routage du trafic.

Points de terminaison de passerelle : Utilisés uniquement pour Amazon S3 et DynamoDB. Ils sont implémentés comme une cible dans une table de routage (liste de préfixes pl-xxxxxxxx pointant vers vpce-xxxxxxxx). Aucune ENI n’est créée, aucune modification DNS n’est nécessaire, et il n’y a pas de coût horaire.
Points de terminaison d’interface (PrivateLink) : Utilisés pour KMS, SQS, SNS, Secrets Manager, STS, l’API EC2, et la plupart des autres services. Ils provisionnent des ENI avec des adresses IP privées dans les sous-réseaux choisis et sont facturés à l’heure, plus au Go.

Pour une tâche batch inter-comptes où des instances EC2 dans le Compte B lisent des données d’un compartiment S3 dans le Compte A, chiffrées avec une clé KMS du Compte A, la conception correcte est un point de terminaison de passerelle pour S3 plus un point de terminaison d’interface pour KMS. Le point de terminaison de passerelle maintient les appels s3:GetObject, s3:PutObject, s3:PutObjectAcl et s3:ListBucket hors de l’internet ; le point de terminaison d’interface fait de même pour kms:Decrypt, kms:Encrypt et kms:GenerateDataKey. Comme l’ARN de la clé KMS utilise le nom d’hôte standard kms.<region>.amazonaws.com, le point de terminaison d’interface doit avoir le DNS privé activé pour que le nom d’hôte non modifié du SDK se résolve en l’adresse de l’ENI du point de terminaison plutôt que vers le service KMS public. Sans DNS privé (ou si les noms d’hôtes DNS et la résolution DNS ne sont pas tous deux activés au niveau du VPC), le client atteindrait toujours le point de terminaison public — d’où l’exigence de « aucune modification de code » qui impose implicitement le DNS privé.

Les politiques de point de terminaison sont une seconde couche d’autorisation, indépendante. Une politique par défaut permissive existe, mais un durcissement pour un compartiment et une clé spécifiques ressemble à ceci :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
    "Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
  }]
}

La simple création du point de terminaison ne suffit pas. Deux modes de défaillance sont récurrents : (1) le point de terminaison existe mais la table de routage du sous-réseau privé n’a pas d’entrée pour la liste de préfixes S3, donc le trafic sort toujours via la passerelle NAT ; (2) la politique du point de terminaison omet une action telle que s3:PutObjectAcl ou cible le mauvais ARN de compartiment, bloquant silencieusement des appels qu’IAM aurait autrement autorisés. La politique de compartiment et la politique de point de terminaison doivent toutes deux autoriser la requête — leur intersection est appliquée, pas leur union.

Groupes de sécurité, NACL et confinement rapide

Les groupes de sécurité et les NACL résolvent des problèmes qui se chevauchent à différentes couches, et l’examen impose souvent de choisir entre les deux pour la réponse aux incidents.

Groupes de sécurité : Stateful, évalués au niveau de l’ENI. Le trafic de retour est automatiquement autorisé. Seules des règles d’autorisation (allow) existent. Idéal pour une politique au niveau de l’hôte (« le tier web peut atteindre le tier applicatif sur le port 8080 »).
NACL (Network ACLs) : Stateless, évalués à la frontière du sous-réseau. Des règles d’autorisation (allow) et de refus (deny) existent, traitées par ordre de numéro de règle. Idéal pour des blocages grossiers à l’échelle du sous-réseau — en particulier pour mettre sur liste noire une plage d’adresses IP ou fermer un port spécifique sur toutes les instances d’un sous-réseau.

Lorsqu’une propagation de logiciel malveillant vous oblige à bloquer le trafic sortant sur TCP/2905 vers un ensemble d’adresses IP de commande et de contrôle sur de nombreuses instances, une règle de refus (deny) dans une NACL est l’instrument approprié. Les groupes de sécurité ne peuvent pas exprimer de « refus » et exigeraient d’énumérer et de modifier chaque groupe de sécurité référencé par chaque ENI affectée. Une seule règle de refus NACL au niveau du sous-réseau avec un numéro de règle bas (par ex., 90) couvre instantanément toutes les instances de ce sous-réseau tout en préservant le trafic non lié, qui sera évalué par des règles d’autorisation ultérieures.

Comme les NACL sont stateless, n’oubliez pas que les deux sens de circulation du trafic nécessitent des règles. Bloquer le trafic sortant sur le port 2905 ne requiert pas de règle entrante, mais si vous voulez aussi rejeter les réponses entrantes, vous devez ajouter une entrée pour le trafic entrant — et des règles d’autorisation entrantes pour les ports éphémères (1024–65535) doivent exister pour laisser passer le trafic de retour légitime.

Passerelles NAT, routage et indépendance des AZ

Une passerelle NAT est une ressource zonale. Le modèle canonique est d’avoir une passerelle NAT par zone de disponibilité (AZ), avec la table de routage de chaque sous-réseau privé pointant la route 0.0.0.0/0 vers la passerelle NAT située dans la même AZ :

PrivateRouteTable-AZ-a:  0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b:  0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c:  0.0.0.0/0 -> nat-cccc (in subnet public-az-c)

Une seule passerelle NAT partagée entre plusieurs AZ semble moins chère mais introduit deux problèmes : des frais de transfert de données inter-AZ sur chaque paquet, et une dépendance forte en matière de disponibilité — si cette AZ tombe en panne, tous les sous-réseaux privés perdent leur sortie vers internet. Le modèle avec une NAT par zone évite également les anomalies de retour asymétrique lorsqu’il est combiné avec l’inspection via Transit Gateway (voir ci-dessous).

VPC Flow Logs pour l’investigation

Les VPC Flow Logs capturent des métadonnées 5-tuple (IP source/destination, port, protocole, action ACCEPT/REJECT, octets, paquets) au niveau du VPC, du sous-réseau ou de l’ENI. Pour traquer les instances qui communiquent avec des hôtes C2 sur TCP/2905, activez les Flow Logs sur le VPC avec le type de trafic défini sur REJECT (puisque la NACL rejette maintenant ce trafic) et exécutez une requête dans CloudWatch Logs Insights ou Athena :

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;

La colonne srcaddr révèle les adresses IP des instances infectées avec un minimum d’effort — sans captures de paquets, ni agents sur les hôtes. Choisir le trafic « ALL » fonctionne mais produit plus de données et de coûts ; ne choisir que « ACCEPT » omettrait complètement les tentatives rejetées, qui sont précisément ce que vous devez voir.

← Protection des données et S3 · Tous les domaines · Sécurité en périphérie et des applications →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →