Sécurité Serverless (AWS Lambda)

Qu'est-ce que la sécurité serverless ?

La sécurité serverless désigne l'ensemble des pratiques permettant de protéger des fonctions exécutées à la demande sur une plateforme managée, dont AWS Lambda est l'implémentation la plus répandue. Le terme « serverless » induit en erreur : les serveurs existent toujours, mais leur exploitation est déléguée au fournisseur cloud. Ce transfert modifie profondément le modèle de responsabilité partagée : AWS gère le système d'exploitation, le durcissement de l'hyperviseur, le correctif du runtime et l'isolation micro-VM (Firecracker). L'organisation reste entièrement responsable de son code applicatif, de ses dépendances tierces, de la configuration IAM, du traitement des secrets et de la validation des données entrantes.

Autrement dit, la surface d'attaque ne disparaît pas : elle se déplace du système vers l'applicatif et la configuration. Les trois piliers d'une fonction correctement sécurisée sont le moindre privilège IAM, l'externalisation des secrets vers AWS Systems Manager Parameter Store ou AWS Secrets Manager, et la validation stricte des événements reçus en entrée.

Fonctionnement technique

Chaque fonction Lambda est associée à un rôle d'exécution IAM qui détermine les appels API AWS qu'elle est autorisée à effectuer. Ce rôle constitue le principal vecteur de latéralisation : une fonction compromise dispose immédiatement de toutes les permissions de son rôle, sans authentification supplémentaire, via les identifiants temporaires injectés dans son environnement.

Les fonctions sont déclenchées par des sources d'événements hétérogènes : API Gateway, S3, SQS, SNS, EventBridge, DynamoDB Streams. Chacune produit un objet JSON dont la structure et le contenu doivent être considérés comme non fiables, exactement comme une requête HTTP.

Un point souvent ignoré : la réutilisation du contexte d'exécution. Entre deux invocations proches, AWS conserve le même conteneur. Les variables globales, les connexions ouvertes et le répertoire /tmp persistent d'une exécution à l'autre. Écrire un fichier client dans /tmp sans le supprimer peut donc exposer les données d'un utilisateur à l'invocation suivante — une fuite silencieuse et difficile à détecter.

Exemples concrets de failles

• Rôle IAM trop permissif : une fonction de vignettage se voit accorder s3:* sur Resource: "*" au lieu de s3:GetObject limité à arn:aws:s3:::mon-bucket/uploads/*. Une injection de code transforme cette fonction en outil d'exfiltration de l'ensemble des buckets du compte.
• Injection d'événement : un nom de fichier S3 ou un message SQS contenant une charge utile est concaténé dans une requête SQL, une commande shell ou une expression eval(). L'attaquant n'a jamais parlé à l'API : il a simplement déposé un objet dans un bucket.
• Secret en variable d'environnement : une clé d'API stockée en clair reste lisible par toute identité disposant de lambda:GetFunctionConfiguration, et apparaît dans les exports de configuration comme dans les modèles d'infrastructure versionnés.
• Dépendance vulnérable : un paquet npm ou pip obsolète embarqué dans l'archive de déploiement ou dans une Lambda Layer partagée entre dizaines de fonctions.
• SSRF vers les métadonnées : une fonction relayant une URL fournie par l'utilisateur permet d'atteindre des ressources internes du VPC.

Liens avec les autres concepts de cybersécurité

La sécurité serverless est une déclinaison directe du principe de moindre privilège et de l'approche Zero Trust : aucune fonction ne doit être considérée comme fiable au seul motif qu'elle s'exécute à l'intérieur du compte AWS. Elle recoupe la gestion des secrets, la sécurité de la chaîne d'approvisionnement logicielle (dépendances et couches partagées) et les pratiques DevSecOps d'intégration d'analyses SAST et SCA dans les pipelines de déploiement. L'OWASP Serverless Top 10 constitue le référentiel de rattachement le plus pertinent, tandis que la détection repose sur la corrélation entre journaux CloudWatch Logs et traces d'appels API CloudTrail, idéalement acheminés vers un SIEM.

Bonnes pratiques recommandées

• Un rôle IAM dédié par fonction, jamais de rôle mutualisé, jamais de caractère générique dans Action ni dans Resource.
• Stocker les secrets dans Secrets Manager ou en SecureString Parameter Store, les récupérer au démarrage à froid et les mettre en cache en mémoire — jamais en variable d'environnement en clair.
• Valider chaque événement par un schéma explicite (JSON Schema, Pydantic, Zod) avant tout traitement, y compris pour les sources internes.
• Scanner les dépendances et les couches à chaque build, et bloquer le déploiement sur vulnérabilité critique.
• Activer le chiffrement KMS avec clé gérée par le client pour les variables d'environnement et les données au repos.
• Réduire au strict nécessaire le timeout et la concurrence réservée : cela limite mécaniquement l'impact d'un abus et le coût d'un déni de service financier.
• Purger systématiquement /tmp et ne jamais y conserver de données sensibles entre invocations.
• Journaliser, tracer avec X-Ray et alerter sur les appels API anormaux émis par un rôle d'exécution.