Quelle est la différence entre les security groups et les network ACL ?
Réponse courte
Les security groups sont des pare-feux à état attachés aux instances/ENI : ils n'ont que des règles d'autorisation, et le trafic de retour d'un flux autorisé est automatiquement permis. Les network ACL sont des filtres sans état à la frontière du sous-réseau : ils ont des règles ordonnées d'autorisation et de refus, et vous devez autoriser explicitement le trafic de retour sur les ports éphémères. Les security groups sont le contrôle principal ; les NACL ajoutent des garde-fous grossiers au niveau du sous-réseau, comme bloquer une plage d'IP.
C'est une question classique de réseau cloud, et la réponse tient en un mot : à état contre sans état. Les candidats qui mélangent les deux écriront des règles cassées.
Security groups — à état, au niveau de l'instance
Un security group s'attache à une instance ou à une interface réseau et agit comme un pare-feu à état :
- Il ne contient que des règles d'autorisation (il n'y a pas de refus explicite — tout ce qui n'est pas autorisé est implicitement refusé).
- Parce qu'il est à état, si vous autorisez une requête entrante, le trafic de retour correspondant est automatiquement permis. Vous n'écrivez pas de règle pour la réponse.
- C'est le contrôle principal et fin — vous le restreignez à des ports précis et à des security groups source ou des CIDR.
Network ACL — sans état, au niveau du sous-réseau
Une network ACL se situe à la frontière du sous-réseau et est sans état :
- Elle a des règles numérotées et ordonnées évaluées du plus bas au plus haut, et prend en charge à la fois l'autorisation et le refus — utile pour bloquer une plage d'IP malveillante précise sur tout un sous-réseau.
- Parce qu'elle est sans état, elle ne se souvient pas des connexions. Si vous autorisez du trafic entrant, vous devez aussi autoriser explicitement le trafic de retour sortant sur les ports éphémères (et inversement). Oublier cela est le bug NACL numéro un.
Comment ils se combinent
Le trafic vers une instance doit passer par les deux : la NACL du sous-réseau et le security group de l'instance. Ils sont évalués ensemble, et un refus à l'une ou l'autre couche fait tomber le paquet. En pratique, utilisez les security groups pour presque tout et réservez les NACL aux garde-fous grossiers au niveau du sous-réseau.
Ce que recherchent les recruteurs
La distinction à état contre sans état énoncée clairement, la conséquence (règles de trafic de retour pour les NACL), la différence autorisation uniquement contre autorisation/refus, et le fait que les deux couches s'appliquent à un paquet.
Questions de suivi probables
- Pourquoi une NACL sans état doit-elle avoir des règles pour les ports de retour éphémères ?
- Si un paquet est autorisé par la NACL mais refusé par le security group, que se passe-t-il ?
- Quand opteriez-vous pour une règle de refus NACL plutôt qu'un security group ?