AWS : Recommandations de sécurité pour les Security Groups

Que comprenons-nous par Groupes de Sécurité ?

Un groupe de sécurité fonctionne comme un pare-feu virtuel qui contrôle l'entrée et la sortie du trafic des instances EC2. Toutes les instances doivent avoir un groupe de sécurité associé. Si aucun groupe de sécurité n'est spécifié lors de la création de l'instance, le groupe de sécurité par défaut de la VPC est utilisé. Un groupe de sécurité par défaut est appelé default, et AWS lui attribue un ID.

Comment créer un groupe de sécurité avec la console AWS ?

• Ouvrez la console Amazon VPC à l'adresse https://console.aws.amazon.com/vpc/.
• Dans le panneau de navigation, choisissez Groupes de sécurité.
• Choisissez Créer Groupe de Sécurité.
• Entrez un nom pour le groupe de sécurité (par exemple, mon-groupe-de-sécurité) et fournissez une description.
• Dans VPC, sélectionnez l'ID de votre VPC.
• (Optionnel) Ajoutez ou supprimez une étiquette.
• [Ajouter une étiquette] Choisissez Ajouter une étiquette et faites ce qui suit :

1. Dans Clé, entrez le nom de la clé.
2. Dans Valeur, entrez la valeur de la clé.

• [Supprimer une étiquette] Choisissez Supprimer à droite de la clé et de la valeur de l'étiquette.
• Sélectionnez Créer.

Recommandations de sécurité pour les groupes de sécurité AWS

1. Activer le service VPC Flow Logs dans votre VPC ou à tout niveau d'ENI (Elastic Network Interfaces). Les VPC Flow Logs peuvent être configurés pour accepter et rejeter toutes les entrées qui se produisent à travers les groupes de sécurité vers les différents services tels que EC2, ELB ou RDS. Les entrées enregistrées dans les VPC Flow Logs nous aideront à détecter les attaques et les activités anormales.
2. Il faut utiliser AWS IAM (Identity and Access Management) pour contrôler les utilisateurs de votre entreprise qui peuvent créer/modifier des groupes de sécurité. Par conséquent, seuls les employés pour lesquels c'est strictement nécessaire doivent avoir des permissions.
3. Activer les journaux AWS CloudTrail pour enregistrer tous les événements des groupes de sécurité. Pour certains enregistrements, vous pouvez créer un mail automatique qui vous informera au moment de l'événement et ainsi le vérifier immédiatement.
4. Créer une nomenclature descriptive pour les groupes de sécurité. De cette manière, avec le nom, vous obtenez des informations sur le groupe correspondant. Pensez qu'avec le temps, vous éviterez le désordre. Il est conseillé de créer une nomenclature en abrégé avec 1 ou 2 caractères pour les caractéristiques du groupe qui peuvent être. Le type de système d'exploitation, le type d'environnement, la région AWS, le type d'application. Gardez à l'esprit que le nom du groupe ne doit pas être trop explicite à première vue. Par exemple, si vous nommez le groupe WinWebProdCRM, vous indiquez aux hackers à quoi sert ce groupe de sécurité. Une solution serait 0-Win 1-Linux, A-Production, B-Développement, C-Test.
5. Lors de l'application de la nomenclature pour les groupes de sécurité, il est recommandé de supprimer les groupes qui ne la respectent pas.
6. Lorsqu'une VPC est créée, un groupe de sécurité par défaut est automatiquement créé. Si, lors de la création d'une instance, vous ne lui assignez pas un groupe de sécurité que vous avez créé, AWS l'assignera par défaut. Ce n'est pas une bonne pratique. Il est recommandé d'appliquer un groupe de sécurité spécifique chaque fois qu'une instance est créée.
7. Surveiller l'association de plusieurs groupes de sécurité à une instance, car cela crée un ensemble de règles. AWS utilisera cet ensemble de règles pour déterminer si l'accès est autorisé ou non et la règle la plus permissive prévaudra toujours. Ainsi, si une instance EC2 a deux groupes de sécurité associés, dans un groupe il y a une règle qui permet l'accès par le port 22 depuis la machine 52.63.1.100 et un autre groupe avec une règle qui permet l'accès par le port 22 pour tout le monde, AWS appliquera la règle la plus permissive et l'accès sera possible depuis n'importe quelle adresse par le port 22.
8. Une recommandation consiste à ne pas créer un groupe de sécurité avec de nombreux ports ouverts dans le monde entier. Par exemple, s'il s'agit d'un serveur web, nous n'ouvrirons que les ports HTTP et HTTPS pour le trafic entrant : 0.0.0.0/0,TCP, 80 0.0.0.0/0,TCP, 443
9. Ne pas lancer de serveurs avec des ports prédéfinis ouverts tels que 3306, 1630, 1433. Cela crée une petite couche de défense pour le groupe de sécurité car les hackers ne sauraient pas quels ports attaquer.
10. Parfois, que ce soit pour une intervention externe ou pour tout type de tests, il sera nécessaire de créer temporairement des règles trop permissives, la bonne pratique serait d'automatiser cette opération de manière à ce que le groupe de sécurité soit automatiquement supprimé après X minutes.
11. Essayer d'éviter d'ouvrir le port SSH pour d'autres instances de l'environnement de production. Si possible, n'ouvrir le port SSH que pour les hôtes du même VPC.
12. Après avoir mentionné la 11, il est clair qu'il faut éviter d'ouvrir le port SSH à tout le monde. Il est très courant d'appliquer cette règle aux instances en cas d'incident et qu'il soit nécessaire d'accéder à distance. Il est rapide et simple de créer une règle de sécurité pour donner accès à une IP par le port SSH au cas où un accès à distance serait nécessaire à un moment donné.
13. Éviter d'ouvrir des ports pour les protocoles UDP ou ICMP sur des instances privées.
14. Évitez également d'ouvrir des plages de ports. Vous pouvez ajouter un grand nombre de lignes de règles dans les groupes de sécurité pour éviter d'ouvrir directement des plages.
15. Les instances qui sont dans le réseau privé doivent être ouvertes pour les plages IP de votre VPC, il n'est pas logique de les ouvrir à tout le monde (0.0.0.0/0) si elles ne peuvent être accessibles que depuis votre VPC.
16. Appliquer également des règles de sécurité de sortie chaque fois que cela est applicable dans votre VPC. Par exemple, appliquer une règle pour restreindre une connexion FTP depuis n'importe quel serveur Internet vers votre VPC.
17. Pour certaines instances, appliquez également des groupes de sécurité sur l'ELB en l'utilisant de cette manière comme proxy. Ainsi, vous doublez la sécurité, bien que la latence augmente.
18. Amazon Web Services dispose d'un document très recommandé où il rassemble un ensemble de bonnes pratiques pour maintenir votre infrastructure sécurisée sur AWS.