OWASP Cloud-Native Anwendungssicherheit Top 10

1️⃣ CNAS-1 - Unsichere Cloud-, Container- oder Orchestrierungskonfiguration

Übersicht

Falsch konfigurierte Cloud-Dienste, Container und Orchestratoren sind die Hauptursache für Cloud-native Sicherheitsverletzungen. Dazu gehören die Ausführung von Containern als Root, die Verwendung von Standardkonfigurationen, die Veröffentlichung des Kubernetes-API-Servers und die Nichtaktivierung der Audit-Protokollierung für Cloud-Ressourcen.

Beispiel für anfälligen Code

# Running container as root with no resource limits
FROM ubuntu:latest
RUN apt-get update && apt-get install -y curl wget
COPY app /app
# No USER directive — runs as root!
CMD ["/app/server"]

Beispiel für sicheren Code

FROM gcr.io/distroless/static:nonroot
COPY --chown=65534:65534 app /app
USER 65534:65534
EXPOSE 8080
ENTRYPOINT ["/app/server"]

Checkliste zur Schadensbegrenzung

• Verwenden Sie minimale, distroless Basis-Images und führen Sie Container niemals als root aus.
• Aktivieren und Durchsetzen von Pod-Sicherheitsstandards (eingeschränkt) in Kubernetes
• Scannen von Infrastruktur-as-code (Terraform, Helm) mit Tools wie Checkov oder tfsec
• Beschränkung des Zugriffs auf Cloud-Metadaten-Endpunkte (169.254.169.254) und Kubernetes-API-Server

2️⃣ CNAS-2 - Schwachstellen bei der Injektion (Anwendungsschicht, Cloud-Ereignisse, Cloud-Dienste)

Übersicht

Cloud-native Anwendungen erhalten Eingaben nicht nur über herkömmliche HTTP-Anfragen, sondern auch über Cloud-Ereignisse (SQS, Pub/Sub, EventBridge), serverlose Auslöser und die Kommunikation zwischen den Diensten. Injektionsfehler in einem dieser Vektoren können zur Befehlsausführung, Datenexfiltration oder Privilegienerweiterung führen.

Beispiel für anfälligen Code

# Lambda function processing S3 event without sanitizing filename
import os

def handler(event, context):
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    # Command injection via crafted filename!
    os.system(f"aws s3 cp s3://{bucket}/{key} /tmp/{key}")

Beispiel für sicheren Code

import boto3, re
from urllib.parse import unquote_plus

def handler(event, context):
    s3 = boto3.client('s3')
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = unquote_plus(event['Records'][0]['s3']['object']['key'])

    # Validate key against allowlist pattern
    if not re.match(r'^[\w\-./]+$', key):
        raise ValueError(f"Invalid S3 key: {key}")

    # Use SDK instead of shell commands
    s3.download_file(bucket, key, f'/tmp/{key.split("/")[-1]}')

Checkliste zur Schadensbegrenzung

• Validierung und Bereinigung aller Eingaben von Cloud-Ereignissen, Warteschlangen und Auslösern
• SDK/API-Aufrufe anstelle von Shell-Befehlen verwenden (os.system, subprocess mit shell=True vermeiden)
• Anwendung von Eingabevalidierungsschemata auf Ereignis-Payloads (JSON-Schema, protobuf)
• Implementierung von Egress-Filterung, um SSRF von serverlosen Funktionen abzuhalten

3️⃣ CNAS-3 - Unzulässige Authentifizierung und Autorisierung

Übersicht

Cloud-native Umgebungen umfassen mehrere Identitätsebenen: Cloud IAM, Kubernetes RBAC, Service Mesh mTLS und Authentifizierung auf Anwendungsebene. Falsch konfigurierte oder zu freizügige Richtlinien auf jeder Ebene können Seitwärtsbewegungen, die Ausweitung von Berechtigungen oder den unbefugten Zugriff auf sensible Ressourcen ermöglichen.

Beispiel für anfälligen Code

# Overly permissive ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: default-admin
subjects:
- kind: ServiceAccount
  name: default          # Default SA — shared by all pods!
  namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-admin    # Full cluster access!
  apiGroup: rbac.authorization.k8s.io

Beispiel für sicheren Code

# Dedicated ServiceAccount with minimal Role
apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service
  namespace: production
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456:role/order-svc
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: order-service-role
  namespace: production
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get"]

Checkliste zur Schadensbegrenzung

• Verwendung dedizierter ServiceAccounts pro Arbeitslast mit RBAC mit geringsten Rechten
• Implementierung von IAM-Rollen für Servicekonten (IRSA/Workload Identity) anstelle von Anmeldeinformationen auf Knotenebene
• Durchsetzung von mutual TLS (mTLS) für die gesamte Kommunikation zwischen Diensten
• RBAC-Bindungen regelmäßig überprüfen und ungenutzte Berechtigungen entfernen

4️⃣ CNAS-4 - CI/CD-Pipeline und Schwachstellen in der Software-Lieferkette

Übersicht

CI/CD-Pipelines sind hochwertige Ziele, da sie Schreibzugriff auf Produktionsumgebungen haben. Die Kompromittierung einer Build-Pipeline ermöglicht Supply-Chain-Angriffe, die Einschleusung von bösartigem Code und die Bereitstellung von Backdoor-Images. Unsichere Pipeline-Konfigurationen, vergiftete Basis-Images und unsignierte Artefakte tragen alle zu diesem Risiko bei.

Beispiel für anfälligen Code

# Insecure CI pipeline — unpinned actions, no image signing
name: Deploy
on: push
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@main   # Unpinned — could be compromised!
    - run: |
        docker build -t myapp:latest .
        docker push myregistry/myapp:latest  # No signing!
        kubectl apply -f deploy.yaml         # No admission control!

Beispiel für sicheren Code

name: Secure Deploy
on: push
permissions:
  id-token: write
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29  # Pinned SHA
    - run: |
        docker build -t myregistry/myapp:${{ github.sha }} .
        cosign sign myregistry/myapp:${{ github.sha }}  # Sign image
    - run: trivy image myregistry/myapp:${{ github.sha }} --exit-code 1
    - run: kubectl apply -f deploy.yaml  # Admission controller verifies signatures

Checkliste zur Schadensbegrenzung

• Zuordnung von CI/CD-Aktionen und Abhängigkeiten zu exakten SHA-Hashes, nicht zu Zweigen oder Tags
• Signieren Sie Container-Bilder mit Cosign/Notary und erzwingen Sie die Überprüfung der Unterschrift bei der Zulassung
• Scannen von Images auf Schwachstellen (Trivy, Grype) vor der Bereitstellung
• Verwendung des SLSA-Frameworks zur Sicherstellung der Herkunft und Integrität von Build-Artefakten

5️⃣ CNAS-5 - Unsichere Geheimnisspeicherung

Übersicht

Geheimnisse wie API-Schlüssel, Datenbankanmeldeinformationen und TLS-Zertifikate sind oft fest im Quellcode kodiert, in ConfigMaps im Klartext gespeichert oder in Container-Images eingebettet. Kubernetes-Geheimnisse sind standardmäßig nur Base64-kodiert und nicht verschlüsselt, was nur minimalen Schutz bietet.

Beispiel für anfälligen Code

# Secrets in plaintext environment variables
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    env:
    - name: DB_PASSWORD
      value: "SuperSecret123!"   # Plaintext in manifest!
    - name: AWS_SECRET_KEY
      value: "AKIA..."             # Cloud credentials in YAML!

Beispiel für sicheren Code

# Use External Secrets Operator with a vault backend
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: my-app-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: my-app-secrets
  data:
  - secretKey: db-password
    remoteRef:
      key: secret/data/myapp
      property: db-password

Checkliste zur Schadensbegrenzung

• Speichern Sie niemals Geheimnisse in Quellcode, Dockerdateien oder ConfigMaps im Klartext.
• Verwenden Sie einen Geheimhaltungsmanager (Vault, AWS Secrets Manager, GCP Secret Manager) mit automatischer Rotation
• Aktivieren der Verschlüsselung im Ruhezustand für Kubernetes Secrets (KMS-Anbieter)
• Repositories und Images nach durchgesickerten Geheimnissen durchsuchen (git-secrets, TruffleHog, Trivy)

6️⃣ CNAS-6 - Zu weit gehende oder unsichere Netzwerkrichtlinien

Übersicht

Standardmäßig erlaubt Kubernetes allen Pods, uneingeschränkt miteinander zu kommunizieren. Fehlende oder zu freizügige Netzwerkrichtlinien, Sicherheitsgruppen und Firewall-Regeln ermöglichen laterale Bewegungen innerhalb des Clusters und zwischen Cloud-Diensten.

Beispiel für anfälligen Code

# No NetworkPolicy — all pods can talk to everything
apiVersion: v1
kind: Namespace
metadata:
  name: production
# No NetworkPolicy resources defined
# All ingress and egress traffic is allowed by default

Beispiel für sicheren Code

# Default-deny all traffic, then allow only what's needed
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8080

Checkliste zur Schadensbegrenzung

• Implementierung von NetworkPolicies mit Standardverweigerung für alle Namespaces
• Erlauben Sie mit Hilfe von Label-Selektoren nur den erforderlichen Verkehr zwischen Diensten
• Einschränkung des ausgehenden Datenverkehrs zur Verhinderung von Datenexfiltration und C2-Kommunikation
• Verwenden Sie ein CNI-Plugin, das die Durchsetzung von NetworkPolicy unterstützt (Calico, Cilium)

7️⃣ CNAS-7 - Verwendung von Komponenten mit bekannten Sicherheitslücken

Übersicht

Cloud-native Anwendungen stützen sich stark auf Open-Source-Basis-Images, -Bibliotheken und Kubernetes-Operatoren. Die Ausführung veralteter oder ungepatchter Komponenten mit bekannten CVEs setzt die Anwendung gut dokumentierten Exploits aus. Container-Images enthalten oft Hunderte von Paketen, von denen jedes eine potenzielle Sicherheitslücke darstellt.

Beispiel für anfälligen Code

# Using outdated base image with known CVEs
FROM node:14                    # EOL version with known vulns
COPY package.json .
RUN npm install                 # No audit, no lockfile verification
COPY . .
CMD ["node", "server.js"]

Beispiel für sicheren Code

# Use current, slim base image with vulnerability scanning
FROM node:22-slim AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --only=production    # Reproducible install from lockfile
RUN npm audit --audit-level=high # Fail on high+ vulns

FROM gcr.io/distroless/nodejs22-debian12
COPY --from=build /app /app
CMD ["/app/server.js"]

Checkliste zur Schadensbegrenzung

• Kontinuierliche Überprüfung von Container-Images auf CVEs in CI/CD und zur Laufzeit
• Verwendung minimaler Basis-Images (distroless, Alpine) zur Verringerung der Angriffsfläche
• Automatisieren Sie Aktualisierungen von Abhängigkeiten mit Dependabot, Renovate oder ähnlichen Tools
• Pflege einer SBOM und Verfolgung der Komponentenversionen bei allen Einsätzen

8️⃣ CNAS-8 - Unsachgemäße Vermögensverwaltung

Übersicht

In Cloud-nativen Umgebungen ist es einfach, Ressourcen aufzusetzen, aber schwer, sie zu verfolgen. Verwaiste Container, vergessene Namespaces, veraltete Cloud-Ressourcen und Schatten-IT-Bereitstellungen schaffen eine unkontrollierte Angriffsfläche. Ohne eine ordnungsgemäße Bestandsaufnahme können Sicherheitsteams nicht schützen, wovon sie nicht wissen, dass es existiert.

Beispiel für anfälligen Code

# Resources created without tagging or lifecycle management
resource "aws_instance" "test_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.medium"
  # No tags — who owns this? What's it for?
  # No lifecycle policy — runs forever
}

resource "aws_s3_bucket" "temp_data" {
  bucket = "temp-data-2024"
  # No expiration, no access logging
}

Beispiel für sicheren Code

resource "aws_instance" "test_server" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.medium"

  tags = {
    Name        = "test-server"
    Owner       = "platform-team"
    Environment = "staging"
    ManagedBy   = "terraform"
    ExpiresAt   = "2026-04-30"
  }
}

resource "aws_s3_bucket" "temp_data" {
  bucket = "temp-data-2024"

  tags = {
    Owner     = "data-team"
    ManagedBy = "terraform"
  }

  lifecycle_rule {
    enabled = true
    expiration { days = 90 }
  }
}

Checkliste zur Schadensbegrenzung

• Führen eines Echtzeit-Inventars aller Cloud-Ressourcen, Cluster und Namensräume
• Durchsetzung obligatorischer Kennzeichnungsrichtlinien (Eigentümer, Umgebung, Ablaufdatum) für alle Ressourcen
• Automatisierte Erkennung und Bereinigung von verwaisten Ressourcen (AWS Config, GCP Asset Inventory)
• Implementierung von Infrastructure-as-Code, um die unkontrollierte manuelle Erstellung von Ressourcen zu verhindern

9️⃣ CNAS-9 - Unzureichende Kontingentierung von Rechenressourcen

Übersicht

Ohne angemessene Ressourcenkontingente und -begrenzungen kann eine einzelne fehlerhafte oder kompromittierte Arbeitslast die gesamte verfügbare CPU, den gesamten Arbeitsspeicher oder den gesamten Speicherplatz beanspruchen, was zu einem Denial-of-Service für andere Anwendungen führt. Kryptojacking-Angriffe sind in Umgebungen ohne Ressourcenbegrenzung besonders häufig.

Beispiel für anfälligen Code

# Pod with no resource limits
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:latest
    # No resources block — can consume unlimited CPU/memory!

Beispiel für sicheren Code

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:1.2.3
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "500m"
        memory: "512Mi"
---
# Namespace-level quota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: production
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"

Checkliste zur Schadensbegrenzung

• Festlegen von CPU- und Speicheranforderungen/-begrenzungen für jeden Container
• Durchsetzung von ResourceQuotas und LimitRanges auf Namespace-Ebene
• Überwachung der Ressourcennutzung und Alarmierung bei anomalen Verbrauchsmustern
• Verwenden Sie Cluster-Autoscaler mit maximalen Knotengrenzen, um eine unbegrenzte Skalierung zu verhindern.

🔟 CNAS-10 - Ineffektive Protokollierung und Überwachung

Übersicht

Cloud-native Umgebungen erzeugen Protokolle auf mehreren Ebenen: Anwendung, Container-Laufzeit, Orchestrator, Service-Mesh und Cloud-Plattform. Ohne zentralisierte Protokollierung, Korrelation über diese Schichten hinweg und Erkennung von Bedrohungen zur Laufzeit bleiben Sicherheitsvorfälle unentdeckt oder werden zu spät entdeckt.

Beispiel für anfälligen Code

# No audit policy, no log forwarding
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:latest
    # Logs go to stdout only — lost when pod restarts
    # No audit logging configured on the cluster
    # No runtime security monitoring

Beispiel für sicheren Code

# Kubernetes audit policy for security events
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
- level: Metadata
  resources:
  - group: "rbac.authorization.k8s.io"
    resources: ["clusterroles", "clusterrolebindings"]
- level: Metadata
  verbs: ["create", "delete", "patch"]
# Deploy Falco for runtime threat detection
# Forward logs to SIEM via Fluent Bit / Fluentd

Checkliste zur Schadensbegrenzung

• Aktivieren der Kubernetes-Audit-Protokollierung und Weiterleitung an ein zentrales SIEM
• Einsatz von Laufzeit-Sicherheitstools (Falco, Sysdig) zur Erkennung von Bedrohungen in Echtzeit
• Log-Aggregation (Fluent Bit, Loki) verwenden, um Container-Logs über den Pod-Lebenszyklus hinaus zu erhalten
• Erstellen von Warnmeldungen für sicherheitskritische Ereignisse: geheimer Zugriff, RBAC-Änderungen, Ausführung in Pods

📊 Zusammenfassende Tabelle