Groupes de sécurité et paires de clés

Un groupe de sécurité est un pare-feu virtuel à état qui contrôle le trafic entrant et sortant d’une instance EC2 (ou d’autres ressources AWS telles que RDS, Lambda, ELB). Les groupes de sécurité fonctionnent au niveau de l’instance : chaque règle spécifie un protocole (TCP/UDP/ICMP), une plage de ports et une source/destination (plage IP ou autre groupe de sécurité). Contrairement aux pare-feu traditionnels, les groupes de sécurité sont à état : si vous autorisez le trafic entrant, le trafic de réponse est automatiquement autorisé en sortie, sans règle explicite.

Les groupes de sécurité possèdent des ensembles distincts de règles entrantes et sortantes. Les règles entrantes contrôlent le trafic qui arrive à l’instance : par défaut, tout le trafic entrant est refusé. Les règles sortantes contrôlent le trafic qui quitte l’instance : par défaut, tout le trafic sortant est autorisé. Vous ajoutez des règles Allow explicites ; il n’existe pas de règles Deny explicites dans les groupes de sécurité (utilisez les ACL réseau pour les refus explicites). Toutes les règles d’un groupe de sécurité sont évaluées ensemble selon un OU logique : toute règle Allow correspondante autorise le trafic.

Les groupes de sécurité prennent en charge les références de groupes de sécurité source/destination, une solution plus flexible et plus sûre que la spécification de plages IP. Par exemple, un groupe de sécurité ALB autorise 0.0.0.0/0 sur le port 443. Le groupe de sécurité des instances EC2 autorise le trafic entrant sur le port 8080 uniquement depuis l’ID du groupe de sécurité ALB, et non depuis une adresse IP quelconque. Si un ALB est remplacé ou mis à l’échelle, la règle continue de s’appliquer correctement sans modification des IP. Ce modèle crée une défense dynamique en couches pour les architectures à plusieurs niveaux.

Être à état signifie que le groupe de sécurité suit l’état des connexions. Si votre règle entrante autorise le port TCP 80 depuis Internet et qu’un client effectue une requête, les paquets de réponse sortants sont automatiquement autorisés vers ce client, même en l’absence de règle sortante pour le port 80. Cela diffère fondamentalement des ACL réseau, qui sont sans état et nécessitent des règles explicites pour les deux sens du trafic. La gestion d’état rend les groupes de sécurité plus faciles à configurer pour les modèles de trafic applicatif courants.

Vous pouvez attacher plusieurs groupes de sécurité à une même instance EC2 (jusqu’à 5 par défaut, limite ajustable). Les règles de tous les groupes de sécurité attachés sont combinées par union (logique OU) : si un groupe de sécurité quelconque autorise une requête, celle-ci est autorisée. Cela signifie que les groupes de sécurité peuvent uniquement ajouter des autorisations, jamais les restreindre : si vous souhaitez renforcer les restrictions d’accès, vous devez supprimer ou modifier des règles, et non ajouter un groupe de sécurité plus restrictif. Gardez ce comportement additif à l’esprit pour les questions d’examen sur la restriction des accès.

Chaque VPC comprend un groupe de sécurité par défaut. Ses règles par défaut sont les suivantes : le trafic entrant autorise tout le trafic provenant d’autres instances également présentes dans le groupe de sécurité par défaut ; le trafic sortant autorise tout le trafic vers n’importe quelle destination. Cette configuration est volontairement permissive afin que les nouvelles instances puissent communiquer par défaut. Pour les environnements de production, créez un groupe de sécurité personnalisé avec un ensemble de règles entrantes strictement limité et supprimez les associations des instances avec le groupe de sécurité par défaut afin d’éviter toute exposition accidentelle.

Les paires de clés EC2 utilisent la cryptographie asymétrique pour l’authentification SSH. AWS génère la paire de clés, ou vous importez votre propre clé publique : AWS stocke la clé publique et l’injecte dans l’instance lors de son lancement ; vous téléchargez et stockez la clé privée (fichier .pem), qu’AWS ne stocke jamais. SSH utilise la clé privée pour prouver votre identité au serveur sans transmettre de mot de passe. La clé privée doit disposer d’autorisations restrictives (chmod 400), sinon SSH refusera de l’utiliser.

Si vous perdez la clé privée d’une instance EC2 Linux, vous ne pouvez pas vous connecter en SSH de manière classique. Les options de récupération comprennent : Systems Manager Session Manager (si l’agent SSM est en cours d’exécution et qu’un rôle IAM est attaché — aucune clé nécessaire), EC2 Instance Connect (injecte une clé temporaire via le navigateur ou la CLI — nécessite un port SSH ouvert et les autorisations EIC), ou arrêter l’instance, détacher le volume EBS racine, l’attacher à une autre instance, modifier le fichier authorized_keys, le rattacher et redémarrer. Pour Windows, utilisez Systems Manager afin de récupérer le mot de passe.

Laisser SSH (port 22) ouvert à 0.0.0.0/0 expose votre instance aux attaques par force brute et par réutilisation d’identifiants depuis n’importe où sur Internet. Bonnes pratiques : limitez SSH à votre plage IP d’entreprise précise ou utilisez un hôte bastion dans un sous-réseau public avec un groupe de sécurité étroitement contrôlé, puis connectez-vous en SSH depuis le bastion aux instances privées. Mieux encore, utilisez Systems Manager Session Manager pour éliminer entièrement l’exposition du port SSH : aucune règle entrante n’est alors nécessaire.

Principales limites par défaut des groupes de sécurité, ajustables via les quotas de service : jusqu’à 2 500 groupes de sécurité par VPC, 60 règles entrantes et 60 règles sortantes par groupe de sécurité, et 5 groupes de sécurité par interface réseau. Lorsqu’un autre groupe de sécurité est référencé comme source, chaque combinaison groupe de sécurité référencé–règle compte comme une règle. Si vous atteignez les limites de règles, regroupez-les en référençant des ID de groupes de sécurité plutôt que des plages IP individuelles, ou utilisez des listes de préfixes pour regrouper plusieurs CIDR dans une entité gérable.

Une liste de préfixes gérée est un ensemble de blocs CIDR que vous pouvez référencer dans des règles de groupes de sécurité ou des tables de routage. AWS gère des listes de préfixes gérées par AWS pour des services tels que S3 et CloudFront ; vous pouvez ainsi autoriser le trafic vers et depuis ces services sans gérer vous-même les plages IP, qui évoluent au fil du temps. Vous pouvez également créer des listes de préfixes gérées par le client afin de regrouper vos plages IP d’entreprise : mettez à jour la liste de préfixes à un seul endroit, et tous les groupes de sécurité qui la référencent héritent automatiquement de la modification.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) de cette leçon.

Dans cette leçon, vous avez appris que les groupes de sécurité sont des pare-feu virtuels à état qui autorisent le trafic selon le principe du refus par défaut, que le chaînage des groupes de sécurité par ID est plus sûr et plus flexible que l’utilisation de plages IP, et que les paires de clés assurent une authentification SSH asymétrique, tandis que Systems Manager Session Manager élimine la nécessité d’ouvrir des ports SSH. Nous allons maintenant aborder les options de stockage EC2 : Instance Store ou EBS.