Serverless Security: AWS Lambda und Functions | Decripte

Serverless-Architekturen beseitigen die Serververwaltung, bringen aber neue Herausforderungen mit sich: Function-Level Permissions, Event Injection, Schwachstellen in Abhängigkeiten und eine erweiterte Angriffsfläche.

Modell der geteilten Verantwortung

OWASP Serverless Top 10

1. Injection Flaws: SQLi, Command Injection in Event-Daten
2. Broken Authentication: Fehlerhafte Token-Verwaltung, schwache Authn
3. Sensitive Data Exposure: Hartkodierte Secrets, ausführliche Logs
4. XML External Entities (XXE): Unsicheres XML-Parsing
5. Broken Access Control: Zu freizügiges IAM
6. Security Misconfiguration: Standardkonfigurationen, offene Ports
7. Cross-Site Scripting (XSS): Unzureichendes Output Encoding
8. Insecure Deserialization: Deserialisierung nicht vertrauenswürdiger Events
9. Using Components with Known Vulnerabilities: Veraltete Abhängigkeiten
10. Insufficient Logging: Fehlender Audit Trail

IAM und Least Privilege

Jede Function sollte über eine dedizierte IAM-Role mit den minimal erforderlichen Berechtigungen verfügen.

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:*:*:*"
      }
      ]
      }
      

IAM-Prinzipien

• Function-specific roles: Roles niemals zwischen Functions teilen
• Resource-level permissions: Exakte ARNs angeben, keine Wildcards
• Time-based access: AWS STS für temporäre Credentials verwenden
• Deny by default: Nur das Notwendige explizit erlauben

Secrets Management

• AWS Secrets Manager: Automatische Rotation, Encryption at Rest
• Azure Key Vault: Managed HSM, Access Policies
• Environment Variables Encryption: KMS zum Verschlüsseln von Env Vars
• Parameter Store: AWS SSM Parameter Store für Konfigurationen
• Niemals hartkodieren: Secrets im Code oder in Repositories

Beispiel AWS Lambda + Secrets Manager

      import boto3
      import json
      def lambda_handler(event, context):
      # Secret aus dem Secrets Manager abrufen
      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']
      # Das Passwort zur Verbindung mit der DB verwenden
      # ...
      

Input Validation und Sanitization

Events von API Gateway, S3, DynamoDB Streams usw. müssen rigoros validiert werden:

      // 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' };
      }
      };
      

Dependency Management

• SCA-Tools: Snyk, npm audit, Dependabot
• Minimal dependencies: Angriffsfläche reduzieren
• Lock Files: package-lock.json, yarn.lock für Reproduzierbarkeit
• Private Registries: Intern freigegebene Abhängigkeiten hosten
• SBOM: Software Bill of Materials für Auditierbarkeit

Timeout und Resource Limits

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

VPC-Konfiguration

Functions, die auf private Ressourcen zugreifen, sollten in einer VPC mit geeigneten Security Groups laufen:

• Private Subnets: Functions ohne direkten Internetzugang
• NAT Gateway: Für Outbound Internet Access, falls erforderlich
• Security Groups: Whitelisting von Ports und IPs
• VPC Endpoints: Privater Zugriff auf AWS-Dienste (S3, DynamoDB)

Logging und 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;
      }
      };
      

API-Gateway-Sicherheit

• Authentication: Cognito, API Keys, Lambda Authorizers
• Rate Limiting: Usage Plans und Throttling
• WAF Integration: AWS WAF zum Schutz vor den OWASP Top 10
• Request Validation: Models und Validators im API Gateway
• CORS: Erlaubte Origins konfigurieren

Cold-Start-Sicherheit

Cold Starts können für Timing-Angriffe ausgenutzt werden. Gegenmaßnahmen:

• Provisioned Concurrency für kritische Functions
• Package-Größe für schnellen Startup minimieren
• Lazy Loading schwerer Abhängigkeiten
• Warm-up-Schedules über CloudWatch Events

Runtime Security

• PureSec: Runtime Protection für Serverless
• Protego: Serverless Security Platform
• Twistlock: Prisma Cloud für Serverless
• Snyk: In CI/CD integriertes Vulnerability Scanning