Sécurité Serverless : AWS Lambda et Functions | Decripte

Les architectures serverless éliminent la gestion des serveurs mais introduisent de nouveaux défis : permissions au niveau des fonctions, event injection, vulnérabilités de dépendances et une surface d'attaque élargie.

Modèle de Responsabilité Partagée

OWASP Serverless Top 10

1. Injection Flaws : SQLi, command injection dans les event data
2. Broken Authentication : Mauvaise gestion des tokens, authn faible
3. Sensitive Data Exposure : Secrets en dur, logs verbeux
4. XML External Entities (XXE) : Parsing XML non sécurisé
5. Broken Access Control : IAM trop permissif
6. Security Misconfiguration : Configs par défaut, ports ouverts
7. Cross-Site Scripting (XSS) : Output encoding inadéquat
8. Insecure Deserialization : Désérialisation d'événements non fiables
9. Using Components with Known Vulnerabilities : Dépendances obsolètes
10. Insufficient Logging : Absence d'audit trail

IAM et Moindre Privilège

Chaque fonction doit disposer d'un rôle IAM dédié avec les permissions minimales nécessaires.

AWS Lambda - IAM Policy

      {
      "Version": "2012-10-17",
      "Statement": [
      {
      "Effect": "Allow",
      "Action": [
      "dynamodb:GetItem",
      "dynamodb:PutItem"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789:table/MyTable"
      },
      {
      "Effect": "Allow",
      "Action": [
      "logs:CreateLogGroup",
      "logs:CreateLogStream",
      "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
      }
      ]
      }
      

Principes IAM

• Function-specific roles : Ne jamais partager de rôles entre les fonctions
• Resource-level permissions : Spécifier les ARNs exacts, pas de wildcards
• Time-based access : Utiliser AWS STS pour des credentials temporaires
• Deny by default : Autoriser explicitement uniquement le nécessaire

Gestion des Secrets

• AWS Secrets Manager : Rotation automatique, encryption at rest
• Azure Key Vault : HSM managé, access policies
• Environment variables encryption : KMS pour chiffrer les env vars
• Parameter Store : AWS SSM Parameter Store pour les configs
• Ne jamais coder en dur : Les secrets dans le code ou les repositories

Exemple AWS Lambda + Secrets Manager

      import boto3
      import json
      def lambda_handler(event, context):
      # Récupérer le secret depuis Secrets Manager
      session = boto3.session.Session()
      client = session.client(service_name='secretsmanager')
      get_secret_value_response = client.get_secret_value(
      SecretId='prod/db/password'
      )
      secret = json.loads(get_secret_value_response['SecretString'])
      db_password = secret['password']
      # Utiliser le password pour se connecter à la DB
      # ...
      

Validation et Sanitization des Entrées

Les events provenant d'API Gateway, S3, DynamoDB Streams, etc. doivent être validés rigoureusement :

      // Node.js Lambda example
      import Joi from 'joi';
      const schema = Joi.object({
      userId: Joi.string().uuid().required(),
      action: Joi.string().valid('create', 'update', 'delete').required(),
      data: Joi.object().required()
      });
      export const handler = async (event) => {
      try {
      const body = JSON.parse(event.body);
      const { error, value } = schema.validate(body);
      if (error) {
      return {
      statusCode: 400,
      body: JSON.stringify({ error: error.details })
      };
      }
      // Process validated input
      // ...
      } catch (e) {
      console.error('Validation error:', e);
      return { statusCode: 400, body: 'Invalid input' };
      }
      };
      

Gestion des Dépendances

• SCA tools : Snyk, npm audit, Dependabot
• Minimal dependencies : Réduire l'attack surface
• Lock files : package-lock.json, yarn.lock pour la reproductibilité
• Private registries : Héberger les dépendances approuvées en interne
• SBOM : Software Bill of Materials pour l'auditabilité

Timeout et Limites de Ressources

      # AWS Lambda configuration
      Function:
      Type: AWS::Serverless::Function
      Properties:
      Timeout: 30  # secondes (default 3s, max 900s)
      MemorySize: 512  # MB
      ReservedConcurrentExecutions: 100  # limit concurrency
      Environment:
      Variables:
      MAX_RETRY_ATTEMPTS: 3
      CONNECTION_TIMEOUT: 5000
      

Configuration VPC

Les fonctions qui accèdent à des ressources privées doivent s'exécuter dans un VPC avec des security groups appropriés :

• Private subnets : Fonctions sans accès direct à internet
• NAT Gateway : Pour l'outbound internet access si nécessaire
• Security groups : Whitelisting des ports et des IPs
• VPC Endpoints : Accès privé aux services AWS (S3, DynamoDB)

Logging et Monitoring

Structured Logging

      import { Logger } from '@aws-lambda-powertools/logger';
      const logger = new Logger({ serviceName: 'userService' });
      export const handler = async (event, context) => {
      logger.addContext(context);
      logger.info('Processing request', {
      userId: event.userId,
      requestId: context.requestId
      });
      try {
      // Business logic
      } catch (error) {
      logger.error('Processing failed', { error });
      throw error;
      }
      };
      

Sécurité de l'API Gateway

• Authentication : Cognito, API Keys, Lambda Authorizers
• Rate limiting : Usage plans et throttling
• WAF integration : AWS WAF pour la protection contre l'OWASP Top 10
• Request validation : Models et validators dans l'API Gateway
• CORS : Configurer les origins autorisées

Sécurité du Cold Start

Les cold starts peuvent être exploités pour des timing attacks. Mitigations :

• Provisioned concurrency pour les fonctions critiques
• Minimiser le package size pour un startup rapide
• Lazy load des dépendances lourdes
• Warm-up schedules via CloudWatch Events

Runtime Security

• PureSec : Runtime protection pour serverless
• Protego : Serverless security platform
• Twistlock : Prisma Cloud pour serverless
• Snyk : Vulnerability scanning intégré dans la CI/CD