AWS Inspector est un service permettant de collecter des informations sur les paramètres de configuration et d’état d’une instance. Pour ce faire, il s’appuie sur un agent, déployé sur les instances EC2, en charge de la collecte et de l’envoi des données à AWS Inspector. Ces informations sont ensuite comparées à des bases de vulnérabilités connues (par exemple CVE) pour générer des “findings”, ce qui permet de générer un rapport répertoriant les vulnérabilités des instances, les versions logicielles impactées et de proposer des mitigations. Dans cet article nous verrons un cas concret d’utilisation d’AWS Inspector dans le cadre de la détection des vulnérabilités.

Comment mettre en place AWS Inspector à l’échelle d’une entreprise multi-comptes (plus de 70), sur plusieurs régions, et assurer un suivi pour toutes les instances? Si en soi l’usage d’Inspector est relativement simple, synchroniser une évaluation mensuelle à cette échelle pose de nombreux challenges.

AWS Inspector

La mise en oeuvre d’Inspector se fait en deux temps. On définit en premier lieu un groupe d’instances cibles, puis un ensemble de règles définissant la cible à atteindre (à quelle base de données comparer ce qui sera trouvé sur les instances), avant de lancer l’évaluation. Ici le challenge consiste à lancer un audit global sur un ensemble de 70 comptes et de 5 régions, de façon synchronisée. 

Synchroniser AWS Inspector sur plusieurs comptes

Pour répondre à ce besoin, nous avons conçu un système basé sur AWS Lambda et AWS Step Functions, permettant de contrôler l’ensemble des services Inspector dans les comptes et régions. A noter qu’à la demande du client, ce processus est lancé de façon décalée sur les différentes Availability Zone (AZ), afin de ne pas impacter le fonctionnement des applications.

Plusieurs considérations à prendre en compte pour mettre en place cet audit :

• les instances apparaissent et disparaissent d’un mois sur l’autre, il n’est donc pas possible de travailler sur une liste fermée. Notre système doit donc répertorier toutes les instances EC2 avant de configurer le service Inspector
• par défaut, l’agent Inspector n’est pas installé sur les instances. On utilise donc l’agent SSM, présent par défaut sur les instances, pour exécuter un “invoke command”, et exécuter un script qui récupère l’agent, l’installe et le configure.
• le système s’appuie sur les fonctions Lambda, dont la durée d’exécution est limitée à 15 minutes. Or exécuter l’ensemble des audits de façon séquentielle demande de 5 à 6 heures, incluant le temps d’installation des agents. 

Pour répondre à cette dernière contrainte, nous avons choisi d’utiliser Step Functions, qui permet de mettre en place des machines à état fini, mettre en place des transitions entre les états ou transiter vers un état précédent, poser des conditions, etc. 

Step Functions et AWS Lambda

On appelle donc une Step Function, qui invoque la fonction Lambda en boucle, jusqu’à ce qu’elle ait fini de :

• lister tous les comptes existants
• aller dans chaque compte, chaque région, vérifier comment est configuré le service Inspector (vérifier qu’un groupe cible de règles existe pour toutes les instances, vérifier que l’agent est installé sur chacune d’entre elles, sinon déclencher l’installation)
• déclencher l’audit dans chaque AZ

En termes de code, le challenge consiste à réussir à synchroniser une séquence d’avancement sur des tâches qui ne progressent pas à la même vitesse (selon que les instances aient ou non un agent Inspector déjà installé, la durée de l’installation en fonction des configurations, etc.).

Au total, ce sont 350 exécutions en parallèle, gérées par une Lambda centrale contrôlant l’avancée de chacune de ces tâches et leur reprise après une mise en attente. Au final, le système fonctionne avec un maximum de 12 secondes de temps d’exécution des lambdas, pour les 70 comptes, 5 régions et 3 AZ. Le processus est cependant fortement consommateur de RAM, et il s’agit de trouver l’équilibre entre la vitesse de traitement souhaitée et la consommation de RAM. 

Coût de la solution

Cette solution présente l’avantage de ne pas être plus coûteuse qu’un usage direct d’AWS Inspector, qui est facturé à l’assessment par instance. Lambda est facturé 2 centimes pour un million d’invocations, à quoi s’ajoute également le coût du temps de run. AWS Step Functions est facturé au nombre de transitions. Pour notre projet, ni Lambda, ni Step Functions ne dépassent le “free-tier” qui leur est accordé. Le processus requiert la consommation d’un peu d’espace de stockage S3, mais pour un coût négligeable face au coût brut d’Inspector (0.45$/assessment/instance. Pour faire un assessment une fois par mois sur 100 instances, le coût d’Inspector est de 45$, par exemple).

Automatisation

Le déploiement du système est automatisé grâce à une chaîne CI/CD, le processus d’audit est déclenché avec une règle Cloudwatch Events, qui lance une fois par mois la Step Function enclenchant le processus. A l’issue de l’audit de l’ensemble des comptes, plusieurs centaines de megas de “findings” Inspector sont stockés dans un bucket S3 pour être processés. Toutes ces données sont également automatiquement centralisées dans les Security Hub de chaque compte, puis dans le Security Hub central, afin d’avoir chaque mois une mise à jour des vulnérabilités présentes dans l’écosystème AWS. Ce système permet d’assurer à l’équipe Sécurité d’avoir une vision à jour et la plus complète possible. La possibilité de notifier les product owners est également à l’étude. Une notification par mail est envisagée. Toutefois l’envoi d’informations critiques par mail demande un chiffrement asymétrique, ce qui entraîne une difficulté complémentaire : en effet, les clés publiques des utilisateurs sont stockées dans l’AD de l’entreprise, qui n’est, pour l’instant, pas accessible depuis AWS.