Groupes de sécurité vs. ACL réseau : Choisir votre pare-feu AWS VPC
Naviguez dans les complexités de la sécurité AWS VPC en maîtrisant les différences entre les groupes de sécurité (SG) et les ACL réseau (NACL). Ce guide expert explique la portée, l'état et l'évaluation des règles de ces deux contrôles. Découvrez pourquoi les SG sont idéaux pour une protection fine et stateful des instances, tandis que les NACL sont essentiels pour une segmentation large et stateless des sous-réseaux et des politiques de refus explicites. Mettez en œuvre une stratégie de pare-feu multicouche robuste pour votre infrastructure cloud.
Groupes de sécurité vs. ACL réseau : Choisir votre pare-feu AWS VPC
Lors de la conception d'un environnement Virtual Private Cloud (VPC) sécurisé dans Amazon Web Services (AWS), les administrateurs s'appuient sur plusieurs couches de contrôle pour gérer le trafic réseau. Les deux composants fondamentaux pour filtrer le trafic au niveau réseau sont les groupes de sécurité (SG) et les listes de contrôle d'accès réseau (NACL).
Ils se ressemblent dans la console, mais ils échouent de manières très différentes. Les groupes de sécurité sont généralement l'endroit où vous décrivez l'intention de l'application. Les ACL réseau sont l'endroit où vous appliquez des limites larges de sous-réseau ou des refus d'urgence.
Le rôle des pare-feu dans AWS VPC
AWS fournit une sécurité réseau à deux niveaux principaux dans un VPC :
- Niveau Instance (Groupes de sécurité) : Agit comme un pare-feu pour des instances EC2 spécifiques ou des ressources (comme les bases de données RDS ou les Elastic Load Balancers). Il contrôle le trafic vers et depuis l'interface réseau.
- Niveau Sous-réseau (ACL réseau) : Agit comme un pare-feu sans état pour des sous-réseaux entiers, contrôlant le flux de trafic entrant ou sortant de la limite du sous-réseau.
Plongée dans les groupes de sécurité (SG)
Les groupes de sécurité fonctionnent comme le pare-feu principal et précis pour les ressources individuelles. Ils sont stateful et filtrent par protocole, port et source ou destination.
Caractéristiques clés des groupes de sécurité
| Fonctionnalité | Description | Implications pour l'utilisation |
|---|---|---|
| Portée | S'applique directement à l'interface réseau élastique (ENI) d'une instance. | Contrôle le flux de trafic vers et depuis l'instance elle-même. |
| État | Stateful. Si une requête entrante est explicitement autorisée, le trafic de retour correspondant (réponse sortante) est automatiquement autorisé, indépendamment des règles sortantes. | Simplifie la configuration ; il suffit de définir la direction du trafic initiateur. |
| Type de règle | Autorisation uniquement. Les règles de refus explicites ne sont pas possibles. Le trafic qui ne correspond pas à une règle ALLOW explicite est implicitement refusé. |
Se concentre sur la définition de ce qui est autorisé. |
| Évaluation | Toutes les règles sont évaluées avant qu'une décision ne soit prise. Elles ne sont pas numérotées, et aucun DENY implicite n'est traité tant que toutes les règles ALLOW n'ont pas échoué. |
L'ordre n'a pas d'importance ; toutes les règles sont traitées de manière égale. |
Exemple de configuration de groupe de sécurité
Pour autoriser l'accès SSH (port 22) à une instance EC2, vous n'avez besoin que d'une règle entrante. La règle sortante pour la réponse SSH est gérée automatiquement par la nature stateful du SG.
| Type | Protocole | Plage de ports | Source | Description |
|---|---|---|---|---|
| Entrant | TCP | 22 | 0.0.0.0/0 (ou IP admin spécifique) | Autoriser l'accès SSH |
| Sortant | Tout | Tout | 0.0.0.0/0 | (Par défaut : Autorise tout le trafic, mais peut être restreint si nécessaire) |
# Représentation conceptuelle d'un flux stateful
Utilisateur (IP source) --> [Règle SG entrante : AUTORISER 22] --> Instance EC2
Instance EC2 (Réponse) --> [Suivi d'état implicite] --> Utilisateur (Réponse reçue)
Conseil de bonne pratique : Définissez toujours les règles des groupes de sécurité en utilisant le principe du moindre privilège. Dans la mesure du possible, restreignez les plages d'IP sources au lieu d'autoriser 0.0.0.0/0.
Plongée dans les ACL réseau (NACL)
Les ACL réseau fournissent une deuxième couche de défense, agissant comme un filtre sans état à la limite du sous-réseau. Elles sont puissantes pour la segmentation du réseau et les politiques de refus larges.
Caractéristiques clés des ACL réseau
| Fonctionnalité | Description | Implications pour l'utilisation |
|---|---|---|
| Portée | S'applique à un sous-réseau VPC entier. Un sous-réseau ne peut être associé qu'à une seule NACL à la fois. | Contrôle tout le trafic entrant ou sortant du sous-réseau, affectant toutes les instances qu'il contient. |
| État | Stateless. Les requêtes entrantes et les réponses sortantes correspondantes doivent être explicitement autorisées. | Nécessite une configuration minutieuse pour le trafic de retour (ports éphémères). |
| Type de règle | Autorisation et Refus. Vous pouvez définir explicitement des règles pour autoriser ou bloquer le trafic. | Excellent pour bloquer des IP malveillantes connues ou refuser des protocoles spécifiques à l'échelle du réseau. |
| Évaluation | Les règles sont numérotées (1 à 32766) et évaluées séquentiellement, en commençant par le numéro le plus bas. La première règle correspondante est appliquée immédiatement. | L'ordre des règles est critique. La règle de refus implicite (la dernière règle traitée) refuse tout ce qui n'a pas été explicitement autorisé. |
Gestion du trafic sans état (ports éphémères)
Parce que les NACL sont sans état, vous devez prendre en compte les ports éphémères utilisés par les clients se connectant à vos serveurs. Lorsqu'un client initie une connexion, il utilise un port de destination (par exemple, 80 pour HTTP) et un port source élevé (plage de ports éphémères, généralement 1024-65535).
Pour autoriser le trafic web (HTTP) dans un sous-réseau, vous avez besoin de deux règles :
- Règle entrante : Autorise le trafic sur le port de destination (par exemple, 80).
- Règle sortante : Autorise le trafic de retour vers le client en utilisant les ports sources éphémères.
| N° règle | Type | Protocole | Plage de ports | Source/Destination | Action règle |
|---|---|---|---|---|---|
| 100 | Entrant | TCP | 80 | 0.0.0.0/0 | AUTORISER (Trafic web entrant) |
| 110 | Sortant | TCP | 1024-65535 | 0.0.0.0/0 | AUTORISER (Réponse web sortante - Ports éphémères) |
| * | Refus implicite | Tout | Tout | Tout | REFUSER (Traité en dernier) |
Avertissement : Si vous omettez la règle sortante correspondante pour les ports éphémères dans une NACL, le trafic atteindra l'instance (grâce à la règle entrante) mais la réponse sera abandonnée à la limite du sous-réseau, entraînant des délais d'attente de connexion.
Résumé comparatif : SG vs. NACL
Le tableau suivant résume les différences cruciales entre les deux types de pare-feu :
| Fonctionnalité | Groupe de sécurité (SG) | ACL réseau (NACL) |
|---|---|---|
| Portée d'application | Niveau Instance/ENI | Niveau Sous-réseau |
| État | Stateful | Stateless |
| Types de règles | Autorisation uniquement | Autorisation et Refus |
| Évaluation des règles | Toutes les règles évaluées, sans ordre spécifique. | Règles évaluées séquentiellement par numéro (le plus bas en premier) ; la première correspondance l'emporte. |
| Comportement par défaut | Refuse tout le trafic entrant, autorise tout le trafic sortant (sauf restriction). | La NACL par défaut autorise tout le trafic entrant/sortant. Les NACL personnalisées refusent tout le trafic entrant/sortant. |
| Effet sur le trafic | N'applique les règles que si le trafic est destiné à ou provient d'une ressource associée. | Filtre le trafic passant la limite du sous-réseau, affectant toutes les ressources du sous-réseau. |
Choisir le bon pare-feu : Scénarios et bonnes pratiques
Une sécurité VPC réussie repose sur l'utilisation conjointe des SG et des NACL dans une approche en couches (Défense en profondeur).
Quand privilégier les groupes de sécurité
Les groupes de sécurité devraient être l'outil principal pour filtrer l'accès réseau en raison de leur nature stateful et de leur capacité à référencer d'autres SG, simplifiant la configuration des applications.
- Contrôle fin de l'application : Utilisez les SG pour définir exactement les ports et protocoles requis pour une application spécifique (par exemple, n'autoriser le trafic que sur le port 3306 du SG du serveur web vers le SG de la base de données).
- Communication interne : Gérez la sécurité du trafic entre les instances dans le même sous-réseau ou entre sous-réseaux (par exemple, garantir qu'un équilibreur de charge peut communiquer avec ses groupes cibles).
- Facilité de gestion : Étant stateful, les SG nécessitent moins de règles et sont moins sujets aux erreurs que la gestion des ports éphémères avec les NACL.
Quand mettre en œuvre des ACL réseau
Les NACL sont mieux utilisées pour définir des limites larges à l'échelle du réseau et des politiques de segmentation.
- Politiques de refus larges : Utilisez des règles
DENYexplicites (N° règle 100) pour bloquer des adresses IP ou plages IP malveillantes spécifiques sur l'ensemble d'un sous-réseau avant même que le trafic n'atteigne les instances. - Segmentation des sous-réseaux : Appliquez des limites strictes entre les couches de votre architecture (par exemple, garantir que la NACL du sous-réseau de base de données refuse explicitement tout le trafic entrant provenant d'Internet, indépendamment de la configuration d'un SG).
- Exigences de conformité : Certaines normes de conformité peuvent imposer un filtrage au niveau du sous-réseau, rendant les NACL essentielles.
- Filtrage de protocole sans état : Les NACL sont nécessaires si vous devez filtrer des protocoles sans état que les SG ne peuvent pas gérer efficacement seuls (bien que cela soit rare pour le trafic TCP/UDP standard).
Erreurs qui provoquent des pannes
La panne NACL la plus courante est d'oublier le trafic de retour. Quelqu'un autorise le TCP 443 entrant vers un sous-réseau public et laisse les règles sortantes trop restrictives. L'équilibreur de charge ou l'instance reçoit le SYN, mais la réponse est abandonnée sur le chemin de sortie. Du côté client, cela ressemble à un délai d'attente, et du côté de l'instance, le service peut sembler parfaitement sain.
Une autre erreur est d'utiliser les NACL pour une politique par application. Si un sous-réseau contient des instances web, worker et admin, une seule NACL s'applique à toutes. Une règle ajoutée pour une charge de travail peut exposer ou casser de manière inattendue une autre charge de travail dans le même sous-réseau. Si vous avez besoin d'un comportement réseau différent, utilisez des groupes de sécurité différents et envisagez des sous-réseaux séparés uniquement lorsqu'il existe une véritable limite à appliquer.
La numérotation des règles mérite également de l'attention. Laissez des écarts tels que 100, 110, 120 au lieu de 1, 2, 3 afin de pouvoir insérer des règles d'urgence plus tard. N'oubliez pas que la première correspondance l'emporte. Un refus à la règle 90 l'emportera sur une autorisation à la règle 100, même si l'autorisation semble plus spécifique à la personne qui lit rapidement la console.
Pour les groupes de sécurité, l'erreur courante concerne les plages de sources larges. 0.0.0.0/0 sur 443 pour un équilibreur de charge public peut être normal. La même source sur SSH, RDP, Redis, PostgreSQL ou une API d'administration interne est généralement un problème. Préférez les références aux groupes de sécurité à l'intérieur du VPC et les CIDR étroits pour l'accès des opérateurs.
Lorsque vous héritez d'un VPC existant, exportez les règles et regroupez-les par intention : points d'entrée publics, trafic application-à-application, magasins de données, administration et refus d'urgence. Les règles sans propriétaire ou raison claire sont l'endroit où l'exposition obsolète réside généralement.
L'approche de défense en profondeur
Dans un VPC typique et bien conçu, les flux de trafic doivent passer à la fois par une NACL et un groupe de sécurité. Si l'un ou l'autre des contrôles de sécurité refuse le trafic, le paquet est abandonné.
- Flux entrant : Le trafic entre dans le sous-réseau -> NACL vérifie les règles -> Le trafic atteint l'ENI de l'instance -> Groupe de sécurité vérifie les règles -> Le trafic atteint l'application.
- Flux sortant : L'application génère une réponse -> Groupe de sécurité (vérification stateful réussie) -> Le trafic quitte l'ENI de l'instance -> NACL vérifie les règles -> Le trafic quitte le sous-réseau.
En tirant parti de la NACL pour la segmentation grossière et les règles de refus, et du SG pour des autorisations précises, stateful et au niveau de l'application, vous maximisez l'efficacité de la sécurité tout en maintenant la simplicité de la configuration.
Un modèle de conception pratique
Pour la plupart des VPC d'application, commencez par les groupes de sécurité. Donnez à l'équilibreur de charge un groupe de sécurité orienté public, donnez aux instances d'application un groupe de sécurité qui n'accepte le trafic que depuis le groupe de sécurité de l'équilibreur de charge, et donnez à la base de données un groupe de sécurité qui n'accepte le trafic que depuis le groupe de sécurité de l'application sur le port de la base de données. Ce modèle suit le graphe de dépendance de l'application et survit aux changements d'IP.
Utilisez les NACL avec plus de parcimonie. Un bon cas d'utilisation des NACL est un refus au niveau du sous-réseau pour un CIDR malveillant connu, une limite stricte autour d'un sous-réseau de base de données, ou une règle de conformité qui doit s'appliquer avant que le trafic n'atteigne une ENI dans le sous-réseau. Les NACL deviennent pénibles lorsque les équipes tentent d'y refléter chaque règle d'application. Les règles de port de retour sans état sont faciles à mal configurer, et un seul refus avec un numéro bas peut casser tout un sous-réseau.
Lorsqu'une connexion expire, vérifiez les deux couches dans le chemin du paquet. Pour le trafic Internet entrant vers une instance EC2 dans un sous-réseau public, la requête doit passer la règle NACL entrante, la table de routage et la règle du groupe de sécurité entrant. La réponse doit passer le suivi stateful du groupe de sécurité et la règle NACL sortante. Si les SG semblent corrects mais que les clients restent bloqués, la règle de port éphémère de la NACL est souvent l'élément manquant.
Le modèle mental le plus clair est le suivant : les groupes de sécurité indiquent quelles ressources peuvent communiquer avec quelles autres ressources ; les NACL indiquent ce que le sous-réseau n'autorisera jamais. Gardez ces tâches séparées et la conception reste plus facile à auditer.