Introduction

La sécurité au sein de l’environnement AWS représente une composante critique de l’architecture cloud. La mise en œuvre de pratiques de sécurité rigoureuses est impérative pour la protection des données et des applications déployées, car contrairement à certaines idées reçues, la sécurité dans le Cloud ce n’est pas par défaut. Ce billet présente les fondements de la sécurité AWS, en se concentrant sur la gestion des identités et des accès (IAM), les groupes de sécurité (Security Groups) et les réseaux privés virtuels (VPC). Bien entendu ce n’est pas complet et bien d’autres composantes sont importantes, mais celles ci représentent vraiment la fondation.

Gestion des Identités et des Accès (IAM) :

Le service IAM d’AWS permet un contrôle granulaire des autorisations d’accès aux ressources AWS. Et quand je dis granulaire, c’est VRAIMENT très granulaire… La gestion des identités s’effectue à travers les entités suivantes :

• Utilisateurs, Groupes et Rôles : Les utilisateurs IAM représentent des individus ou des applications. Ils peuvent se connecter (ou non en fonction des permissions) à la console et en ligne de commande à AWS. C’est le moyen le plus simple de créer des accès à AWS, mais en réalité pas le plus sécuritaire. En effet, avec ces utilisateurs il est possible de créer des clés d’accès, et le problème est que ces clés d’accès ne sont pas protégées et sont permanentes par défaut. Nous recommanderons d’utiliser plutôt des accès fédérés via un fournisseur d’identité externe comme Entra ID, ceci dit il existe souvent des cas particuliers ou ils sont nécessaires. Les groupes facilitent la gestion des permissions pour des ensembles d’utilisateurs. AWS recommande de systématiquement placer les utilisateurs dans des groupes et de toujours affecter les permissions aux groupes et non directement sur les utilisateurs. Les rôles attribuent des permissions à des services AWS. Vous pouvez les voir comme des comptes de service.
• Politiques (policy) : Les politiques IAM définissent les actions qu’une entité peut entreprendre sur les ressources AWS. L’application du principe de moindre privilège est fortement recommandée. Pour les débutants, AWS vous mets à disposition des politiques gérées, qui simplifient l’octroi des permissions (AWSS3Administrator par exemple). Toutefois gardez à l’esprit que ces politiques gérées ne respectent jamais le principe du moindre privilège et que donner trop de permissions à vos utilisateurs représe un risque important et documenté. Vous pouvez (et devriez) favoriser les politiques “custom”, définies manuellement.
• Authentification Multi-Facteurs (MFA) : L’activation de l’authentification MFA constitue une mesure de sécurité essentielle pour renforcer la protection des comptes. Vous devriez TOUJOURS exiger du MFA pour vos accès, c’est absolument essentiel ! Particulièrement pour le compte Root de votre environnement AWS, qui est un compte particulier n’apparaissant pas dans la console IAM et qui est votre Breaking glass account. AWS offre désormais l’option d’avoir plusieurs MFA possibles simultanément sur des comptes, ce qui est pratique pour avoir un MFA de secours.

Pour une compréhension approfondie, veuillez consulter la documentation officielle AWS :

Présentation d’AWS IAM Bonnes pratiques IAM

Groupes de Sécurité (Security Groups) :

Les groupes de sécurité agissent en tant que pare-feu virtuels pour les instances EC2, contrôlant le trafic entrant et sortant au niveau des ports TCP et UDP. On peut également les affecter sur les Load Balancer ou des pods Kubernetes par exemple. Ces groupes de sécurité sont Stateful, ce qui signifie que vous n’avez pas à vous préoccuper du trafic en réponse à une communication.

• Règles Entrantes et Sortantes : Ces règles définissent les protocoles et les ports autorisés, ainsi que les adresses IP sources et de destination. Par défaut toutes les communications en entrée (ingress) sont bloquées. Par conséquent si vous n’arrivez pas à vous connecter à votre serveur alors qu’il semble en santé, c’est souvent une bonne place à investiguer. Par contre, les communications en sortie sont toutes ouvertes par défaut. CE QUI N’EST PAS RECOMMANDÉ ! La majorité de vos serveurs ne devraient pas avoir à se connecter sur autre chose que du TCP 80 et 443. Par conséquent, configurez au plus juste votre groupes de sécurité en sortie.
• Configuration : La configuration précise des groupes de sécurité est indispensable pour limiter l’exposition aux risques. En entrée comme en sortie. A noter qu’il est possible d’affecter plusieurs groupes de sécurité à une instance tout comme affecter un même groupe de sécurité à plusieurs instances. Aussi, ces groupes ne permettent pas de filtrer les URL, uniquement des adresses IP. Pour filtrer des URL vous devrez utiliser un service additionnel qui est Network Firewall.

Documentation AWS, relatif aux groupes de sécurité :

Groupes de sécurité Amazon EC2 pour les instances Linux

Réseaux Privés Virtuels (VPC) :

Le service VPC permet la création d’un réseau isolé au sein de l’infrastructure AWS. La bonne nouvelle est que ce réseau est VRAIMENT isolé par défaut. Même au sein d’un même compte AWS, si vous avez plusieurs VPC, vos serveurs n’auront aucune conscience de la présence de ceux sités dans un autre VPC. Parfait pour appliquer de la segmentation, car il existe bien sûr des possibilités de raccorder de façon granulaire les VPC entre eux. En particulier, on peut retrouver des VPC de Dev et Prod au sein d’un même compte AWS.

• Sous-réseaux : Les sous-réseaux publics et privés segmentent le réseau et contrôlent l’accès à Internet. Les sous-réseaux permettent d’appliquer de la micro segmentation au sein d’un VPC, avec des règles de filtrage entre sous-réseau appliquées via les NACL.
• Tables de Routage : Les tables de routage définissent les chemins de communication entre les sous-réseaux et les passerelles.
• Passerelles Internet et NAT : Ces passerelles assurent la connectivité entre le VPC et Internet, tout en préservant la sécurité des instances privées. Ce qu’il faut comprendre est qu’il est tout à fait possible d’avoir des VPC sans aucun accès à Internet, avec une connexion sur vos serveurs qui s’effectue via la console AWS. Pas très pratique mais possible pour certains scénarios. Dans tous les cas, il est recommandé de ne pas affecter directement d’adresse IP publiques à vos serveurs mais de les placer dans une zone privée, avec un accès à Internet via NAT Gateway. Pour publier vos serveurs sur Internet, vous pouvez alors utiliser un load balancer qui va filtrer le trafic entrant.

Information supplémentaire à propos du service VPC AWS :

Qu’est-ce qu’Amazon VPC ?

Quelques services supplémentaires :

L’utilisation des services AWS Config et Trusted Advisor permet une évaluation continue de la posture de sécurité. Config notamment est très utile car il vous permet d’ennregistrer en continu la configuration de vos objets Cloud et de pouvoir tenir une sorte de CMDB.

La mise en œuvre de la journalisation et de la surveillance via CloudTrail et CloudWatch est essentielle pour la détection des anomalies. Cloudtrail est rapidement un service à explorer car de sa bonne configuration dépend le fait que vous aller générer des logs utiles et intègres ou non. Cloudwatch est plus un service qui vous permet d’interroger les logs et les métriques (une sorte de Greylog géré).

Enfin, AWS propose des solutions de sécurité très intéressantes comme GuardDuty pour la détection de menaces (indispensable quand on commence) et Inspector pour détecter les vulnérabilités (ridiculement simple à activer, c’est également un must to have quand on début son aventure AWS).

Conclusion :

La sécurité dans l’environnement AWS exige une approche rigoureuse et proactive. La maîtrise des services IAM, Security Groups et VPC constitue un fondement essentiel pour la protection des ressources cloud mais comme précisé dans le précédent chapitre, de nombreuses composants aditionnels sont nécessaires. Pour cela, il est indispensable de consacrer suffisament de temps au début pour bien comprendre les principaux objets AWS.