ACL réseau ou groupes de sécurité

AWS fournit deux mécanismes de pare-feu distincts au sein d’un VPC. Les Security Groups fonctionnent au niveau de l’instance (techniquement au niveau de l’ENI) et sont avec état. Les Network Access Control Lists (NACL) fonctionnent au niveau du subnet et sont sans état. Les deux sont évalués pour tout trafic entrant dans un subnet ou en sortant, ainsi que pour le trafic entrant ou sortant de ses instances associées. Leur utilisation conjointe fournit une défense en profondeur : les NACL comme première ligne à la limite du subnet, et les groupes de sécurité comme pare-feu par instance. L’examen SAA-C03 compare fréquemment ces deux mécanismes.

Une Network ACL (NACL) est une liste numérotée de règles appliquées à tout le trafic qui franchit la limite d’un subnet. Les NACL sont sans état : chaque paquet est évalué indépendamment. Si vous autorisez le trafic TCP entrant sur le port 80, vous devez autoriser explicitement le trafic de réponse sortant (ports éphémères 1024-65535) pour que la réponse puisse quitter le subnet. Les règles sont évaluées dans l’ordre numérique (du plus petit au plus grand) ; la première règle correspondante s’applique et aucune autre règle n’est vérifiée. Chaque VPC est fourni avec une NACL par défaut qui autorise tout le trafic entrant et sortant.

Les règles NACL sont évaluées par ordre croissant de numéro de règle (de 1 à 32766), et l’évaluation s’arrête dès qu’une règle correspond : une règle Allow portant un numéro élevé peut être neutralisée par une règle Deny portant un numéro inférieur pour le même trafic. AWS recommande de numéroter les règles par incréments de 10 ou 100 afin de laisser de la place pour insérer ultérieurement d’autres règles. Chaque NACL se termine par une règle par défaut (* DENY) qui refuse tout le trafic ne correspondant à aucune règle explicite. Cette règle générale ne peut être ni modifiée ni supprimée.

Comme les NACL sont sans état, vous devez prendre en compte les deux directions de chaque connexion. Lorsqu’un client sur Internet se connecte à votre instance EC2 sur le port 443, l’instance renvoie la réponse vers le port éphémère du client (un port élevé choisi aléatoirement, généralement 1024-65535 sous Linux et 49152-65535 sous Windows). Les règles sortantes de votre NACL doivent autoriser explicitement cette plage. Une erreur fréquente de configuration des NACL consiste à créer une règle Allow pour le port 443 entrant, mais à oublier d’autoriser les ports éphémères sortants : les connexions s’établissent alors, mais les réponses sont silencieusement abandonnées.

Rappel : les groupes de sécurité sont associés aux instances (ou aux ENI), n’autorisent que les règles Allow explicites (aucune règle Deny), sont avec état (les réponses au trafic entrant autorisé sont automatiquement autorisées en sortie sans règle) et évaluent toutes les règles associées ensemble selon une logique OR. Vous pouvez utiliser comme sources ou destinations les ID d’autres groupes de sécurité, ce qui est plus facile à gérer que des plages d’adresses IP. Les groupes de sécurité constituent le mécanisme principal de contrôle d’accès au niveau des instances, et les NACL ajoutent une couche supplémentaire au niveau des subnets.

Comparaison essentielle pour l’examen :

• Niveau : NACL = subnet ; SG = instance (ENI)
• État : NACL = sans état ; SG = avec état
• Règles : NACL = Allow AND Deny ; SG = Allow uniquement (refus implicite)
• Évaluation : NACL = dans l’ordre (la première correspondance l’emporte) ; SG = toutes les règles sont évaluées (n’importe quelle règle Allow l’emporte)
• Portée : NACL s’applique à toutes les instances du subnet ; SG s’applique uniquement aux instances associées
• Entrant/Sortant : NACL nécessite des règles explicites dans les deux sens ; SG est avec état (seules les règles entrantes sont nécessaires pour les réponses)

Utilisez les NACL pour : bloquer des adresses IP précises (les groupes de sécurité ne peuvent pas refuser, mais uniquement autoriser ; les NACL peuvent ajouter des règles Deny explicites pour bloquer des adresses IP malveillantes connues ou des robots d’extraction). Les règles à l’échelle du subnet (appliquer la même règle à toutes les instances d’un subnet sans modifier les groupes de sécurité individuels). Une couche de défense supplémentaire (si une mauvaise configuration d’un groupe de sécurité ouvre accidentellement l’accès, une règle Deny dans une NACL à la limite du subnet peut tout de même bloquer le trafic). En pratique, la plupart des équipes gèrent principalement les accès au moyen des groupes de sécurité et utilisent les NACL uniquement pour bloquer explicitement des adresses IP.

La NACL par défaut (créée avec chaque VPC) autorise tout le trafic entrant et sortant : elle contient les règles 100 Allow All Inbound et 100 Allow All Outbound. Les subnets qui ne sont pas explicitement associés à une NACL personnalisée utilisent la NACL par défaut. Si vous créez une NACL personnalisée, elle ne contient initialement que la règle Deny-All par défaut (règle *), qui bloque tout le trafic jusqu’à ce que vous ajoutiez des règles Allow explicites. Ainsi, l’association d’une nouvelle NACL personnalisée à un subnet bloquera immédiatement tout le trafic : veillez à ajouter les règles Allow avant de l’associer à des subnets de production.

Pour le trafic entrant vers une instance EC2 : le trafic passe d’abord par la NACL à la limite du subnet (évaluée selon l’ordre des règles). Si la NACL autorise le trafic, celui-ci atteint ensuite le groupe de sécurité de l’instance ; le groupe de sécurité doit également l’autoriser. Les deux mécanismes doivent autoriser le trafic pour qu’il atteigne l’instance. Pour le trafic sortant : le groupe de sécurité est évalué en premier (avec état : autorisation s’il s’agit d’une réponse à un trafic entrant autorisé), puis la NACL (sans état : une règle Allow sortante explicite est nécessaire). Comprendre cet ordre explique pourquoi les règles NACL pour le trafic de retour sont nécessaires, même avec des groupes de sécurité avec état.

Les NACL sont une source fréquente de problèmes réseau difficiles à diagnostiquer en raison de leur nature sans état. Symptômes : les connexions s’établissent, mais les données cessent de circuler (règle sortante pour les ports éphémères manquante) ; trafic à sens unique (règle entrante ou sortante oubliée) ; certaines adresses IP ne peuvent pas se connecter (une règle Deny portant un numéro inférieur correspond avant la règle Allow). Méthode de diagnostic : utilisez les VPC Flow Logs pour voir si les paquets sont ACCEPT ou REJECT au niveau de la NACL. Le journal de flux indique les paquets refusés ainsi que leur source et leur destination, ce qui vous aide à localiser la règle manquante.

Le modele recommande pour la securite d'un VPC a plusieurs niveaux : les NACLs des sous-reseaux publics n'autorisent depuis Internet que les ports 80, 443 et les ports ephemeres requis ; ils refusent tout le reste. Les groupes de securite du sous-reseau public sur ALB autorisent les ports 80/443 depuis 0.0.0.0/0. Les groupes de securite prives de l'application n'autorisent que le trafic provenant de l'ID du groupe de securite ALB. Les groupes de securite prives des donnees n'autorisent que le trafic provenant de l'ID du groupe de securite de l'application. Cette defense en profondeur garantit que, meme si une couche est mal configuree, une autre assure la protection : un principe appele acces minimal a chaque couche.

Testez votre comprehension des concepts AWS Solutions Architect (SAA-C03) presentes dans cette lecon.

Dans cette lecon, vous avez appris que : les NACLs sont des pare-feu sans etat au niveau du sous-reseau, qui prennent en charge des regles d'autorisation et de refus evaluees dans l'ordre numerote, que les groupes de securite sont des pare-feu avec etat au niveau de l'instance, avec des regles d'autorisation uniquement, toutes evaluees ensemble, et qu'il faut utiliser les NACLs pour bloquer explicitement des IP et appliquer des regles a l'ensemble du sous-reseau, et les groupes de securite pour controler precisement l'acces aux instances. Ceci termine le module Bases du VPC ; nous allons maintenant aborder RDS et les bases de donnees relationnelles sur AWS.