Avec ses 17 ans d’existence, le service AWS S3 est au cœur de nombre d’architectures cloud, que ce soit pour de l’archivage ou comme support transitoire pour les objets devant être traités.
Quand il occupe le rôle de point d’entrée pour des processus d’ingestion de données, il est de fait le premier composant des infrastructures potentiellement exposé aux souches virales pouvant se trouver dans les fichiers. De par sa conception, le service en lui-même n’offre qu’une exposition relative, mais il n’en est pas forcément autant pour les infrastructures qui vont opérer le traitement des données.
En tenant compte de cela, il peut s’avérer pertinent d’effectuer un scan antiviral de ces objets avant qu’ils ne soient traités.
Les choix que nous avons faits pour cette architecture de scan antiviral devaient impérativement respecter deux principes : Adopter les principes de l'Event Driven Architecture Reposer sur des briques serverless pour réduire la MCO au minimum
L’antivirus utilisé dans cette solution est le bien connu ClamAV qui sera exécuté depuis une fonction lambda. Cette lambda sera déclenchée lors du dépôt d’un objet dans l’un des buckets S3 sur lesquels nous souhaitons effectuer cette analyse.
Dans le cas où l’objet est sain, la lambda ClamAV appose un tag sur l’objet (par exemple av-status: CLEAN). Dans le cas contraire, un tag correspondant (par exemple av-status: INFECTED) sera apposé et nous enverrons un événement dans une SNS afin de déclencher des mesures d’isolations supplémentaires.
Ces mesures de remédiation peuvent aussi bien être l’isolement dans un bucket de quarantaine avec notification aux équipes de sécurité ou la suppression pure et simple du fichier.
Je parlais plus haut de mesures d’isolations supplémentaires, car nous pouvons par ailleurs tirer parti de l’Attribute Based Access Control (ABAC) directement dans la ressource policy du bucket S3. On peut par exemple bloquer la récupération d’objets dont le statut antiviral ne serait pas sain.
On pourrait ainsi imaginer intégrer dans la policy des buckets :
- Le rôle utilisé par notre applicatif d’ingestion des données pourrait manipuler les objets taggés comme sain sans pour autant avoir le droit de créer ou modifier ce tag.
- Le rôle de notre lambda d’analyse antivirale pourrait consulter tous les objets et les tagger
- Le rôle de notre lambda de remédiation pourrait supprimer ou déplacer les objets taggés comme infectés
- Le rôle de l’équipe d’exploitation restant admin du bucket S3
Reste un point important à traiter, la mise à jour des définitions utilisées par ClamAV pour détecter les souches virales dans les fichiers. Pour cela, nous allons mettre en place un stockage S3 spécifique qui sera utilisé par la lambda d’analyse pour récupérer à chaque déclenchement les définitions.
Afin de minimiser la MCO, nous allons également automatiser la mise à jour des définitions via une autre lambda spécifique qui sera déclenchée à intervalles réguliers.
Avec cette dernière étape, nous avons une solution d’analyse antiviral complète avec un paiement à l’usage, très réactif et avec une MCO réduite au minimum.
Points de vigilance
Point d’attention important, en fonction de vos besoins et en particulier si le flux de fichier est important, il sera préférable de remplacer la lambda d’analyse par un container fargate pour s’affranchir de la limite des 1000 exécutions concurrentes de fonctions lambda à l’échelle de la région.
De même, si vous traitez des fichiers volumineux (plus de 8Go) vous pourrez être limité par la taille du stockage disponible pour l’exécution des lambda.
Références
https://github.com/bluesentry/bucket-antivirus-function
Damien et Timothée participent activement au programme d’innovation
Merci pour votre lecture. Si cet article vous a plu, merci de le partagez sur vos réseaux 😉
Damien Hamoudi - Juin 2023
Timothée Taron - Juin 2023
VOUS AVEZ UN PROJET ?
Audit, migration, infogérance ?
Skale-5 vous écoute : contact@skale-5.com
Nous suivre :
