Sicherheit von Containern und Cloud-Infrastruktur

Container und Cloud-Infrastruktur schaffen neue Angriffsflächen, die traditionelle Anwendungssicherheit nicht abdeckt. Ihr Docker-Image könnte eine anfällige Version von OpenSSL enthalten. Ihr S3-Bucket könnte öffentlich lesbar sein. Ihre IAM-Rolle könnte Berechtigungen haben, auf alles in Ihrem AWS-Konto zuzugreifen. Ihr Kubernetes-Cluster könnte es jedem erlauben, Workloads zu deployen.

Diese Fehlkonfigurationen sind die niedrig hängenden Früchte, nach denen Angreifer suchen. Sie lassen sich leicht ausnutzen und gewähren oft sofortigen Zugriff auf sensible Daten oder Systeme. Die gute Nachricht: Sie lassen sich auch mit automatisierten Tools leicht erkennen. Dieses Kapitel erklärt, wie Sie Container-Images scannen, Cloud-Ressourcen absichern, Kubernetes-Cluster schützen und Ihre Infrastruktur prüfen, bevor Angreifer die Lücken finden.

Warum das für kleine Unternehmen wichtig ist

Cloud-Fehlkonfigurationen gehören regelmäßig zu den häufigsten Ursachen für Datenpannen. Und im Gegensatz zu Code-Schwachstellen, die eine Ausnutzung erfordern, ist ein fehlkonfigurierter S3-Bucket oder eine exponierte Datenbank sofort zugänglich — kein Exploit-Entwicklung erforderlich.

Container verbergen Schwachstellen. Wenn Sie node:18 oder python:3.11 von Docker Hub pullen, pullen Sie eine vollständige Linux-Distribution mit Hunderten von Paketen. Jedes dieser Pakete kann bekannte Schwachstellen haben. Sie haben diesen Code nicht geschrieben, sind aber für die Sicherheit von allem in Ihrem Container verantwortlich.

Cloud-Standardeinstellungen sind nicht sicher. AWS, GCP und Azure priorisieren Funktionsfähigkeit über Sicherheit. Standardeinstellungen erlauben oft mehr Zugriff als nötig. Ein Entwickler, der schnell Ressourcen hochfährt, könnte Speicher öffentlich lassen, Ports offen lassen oder Verschlüsselung deaktivieren — weil das der schnellste Weg zu „es funktioniert" ist.

Kleine Teams arbeiten schnell und überspringen Reviews. Niemand überprüft doppelt Terraform-Konfigurationen oder überprüft IAM-Richtlinien. Infrastrukturänderungen gehen direkt in die Produktion. Automatisches Scanning ist Ihr Sicherheitsnetz.

Kubernetes erhöht die Komplexität. Wenn Sie auf EKS, GKE oder AKS laufen, haben Sie eine weitere Konfigurationsebene hinzugefügt, die fehlkonfiguriert werden kann. Standard-Kubernetes-Einstellungen sind notorisch permissiv.

Angreifer scannen das gesamte Internet. Dienste wie Shodan indizieren kontinuierlich exponierte Datenbanken, offene S3-Buckets und fehlkonfigurierte Server. Ihre versehentlich öffentliche Ressource wird in Stunden, nicht in Wochen entdeckt. Sicherheitsforscher bei Comparitech stellten fest, dass exponierte Datenbanken von böswilligen Akteuren innerhalb von Stunden nach der Verbindung mit dem Internet entdeckt werden.

Container-Sicherheit

Container-Sicherheit beginnt damit, zu verstehen, was sich in Ihren Images befindet. Ein typisches Docker-Image enthält:

Basis-OS-Pakete (apt, yum, apk)
Sprach-Laufzeitumgebung (Node, Python, Java, Go)
Anwendungsabhängigkeiten (npm-Pakete, pip-Pakete)
Ihren Anwendungscode

Schwachstellen können in jeder Schicht existieren. Basis-Image-Schwachstellen sind besonders gefährlich, da sie jeden Container betreffen, der auf diesem Image basiert.

Sichere Images erstellen

Bevor Sie scannen, erstellen Sie Images, die einfacher abzusichern sind:

Minimale Basis-Images verwenden. Alpine-Linux-Images sind 5–10 MB statt 100+ MB für Debian/Ubuntu. Weniger Pakete bedeuten weniger Schwachstellen.

# Instead of this (150+ MB, hundreds of packages)
FROM node:20

# Use this (50 MB, minimal packages)
FROM node:20-alpine

Distroless-Images in Betracht ziehen. Googles Distroless-Images enthalten nur Ihre Anwendung und ihre Laufzeitabhängigkeiten — keine Shell, kein Paketmanager, keine Utilities, die Angreifer nutzen könnten. Sie sind die sicherste Option für die Produktion.

# Build stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

# Production stage with distroless
FROM gcr.io/distroless/nodejs20-debian12
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["dist/server.js"]

Vorteile von Distroless:

Keine Shell = Angreifer können keinen interaktiven Zugriff erhalten, selbst wenn sie eine Schwachstelle ausnutzen
Kein Paketmanager = keine Möglichkeit, zusätzliche Tools zu installieren
Minimale Angriffsfläche = weniger Komponenten, die Schwachstellen haben könnten
Kleinere Images = schnellere Deployments, weniger Speicher

Der Kompromiss: Debugging ist schwieriger, da Sie nicht in den Container einloggen können. Für die Produktion ist das ein Feature, kein Bug.

Versionen explizit fixieren. Verwenden Sie nicht latest — es ändert sich ohne Vorankündigung. Fixieren Sie auf spezifische Versionen, damit Builds reproduzierbar sind und Sie kontrollieren, wann Sie aktualisieren.

# BAD: could be anything
FROM python:latest

# GOOD: explicit version, reproducible builds
FROM python:3.12.3-alpine3.19

Nicht als Root ausführen. Container-Prozesse, die als Root laufen, können in manchen Konfigurationen zum Host entkommen. Einen Nicht-Root-Benutzer erstellen:

FROM node:20-alpine

# Create non-root user
RUN addgroup -g 1001 -S appgroup && \
    adduser -S appuser -u 1001 -G appgroup

# Set working directory
WORKDIR /app

# Copy and install dependencies first (better caching)
COPY package*.json ./
RUN npm ci --only=production

# Copy application code
COPY --chown=appuser:appgroup . .

# Switch to non-root user
USER appuser

EXPOSE 3000
CMD ["node", "server.js"]

Multi-Stage-Builds verwenden. Build-Tools aus Produktions-Images heraushalten:

# Build stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage — only runtime, no build tools
FROM node:20-alpine
WORKDIR /app
RUN adduser -S appuser
COPY --from=builder --chown=appuser /app/dist ./dist
COPY --from=builder --chown=appuser /app/node_modules ./node_modules
USER appuser
EXPOSE 3000
CMD ["node", "dist/server.js"]

Geheimnisse in Containern

Niemals API-Schlüssel, Passwörter oder Zertifikate in Dockerfiles ablegen. Umgebungsvariablen oder Secrets-Management zur Laufzeit verwenden.

# BAD: secret baked into image
ENV DATABASE_PASSWORD=supersecret

# GOOD: expect secrets at runtime
ENV DATABASE_PASSWORD=""
# Injected at runtime: docker run -e DATABASE_PASSWORD=$SECRET ...

Docker Compose mit Geheimnissen:

version: '3.8'
services:
  app:
    image: myapp:latest
    secrets:
      - db_password
      - api_key
    environment:
      - DB_PASSWORD_FILE=/run/secrets/db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt
  api_key:
    external: true  # Managed externally

Integration mit Passwork: passwork-cli verwenden, um Geheimnisse zur Container-Laufzeit einzufügen:

# Pull secrets and start container
passwork-cli exec --folder-id "<folder-id>" docker compose up -d

# Or inject specific secrets
export DB_PASSWORD=$(passwork-cli get --password-id "<id>" --field password)
docker run -e DB_PASSWORD="$DB_PASSWORD" myapp:latest

Für Kubernetes siehe den Abschnitt zu Kubernetes-Geheimnissen weiter unten.

Image-Scanning mit Trivy

Trivy ist das Standard-Tool für Container-Image-Scanning. Es ist schnell, genau und erkennt Schwachstellen in OS-Paketen, Sprachabhängigkeiten und Fehlkonfigurationen.

Trivy installieren:

# macOS
brew install trivy

# Linux
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

# Docker
docker pull aquasec/trivy

Ein Image scannen:

# Scan local image
trivy image myapp:latest

# Scan image from registry
trivy image nginx:1.25

# Scan with severity filter
trivy image --severity HIGH,CRITICAL myapp:latest

# Output as JSON for CI integration
trivy image --format json --output results.json myapp:latest

# Scan and fail if vulnerabilities found
trivy image --exit-code 1 --severity CRITICAL myapp:latest

Beispiel-Output:

myapp:latest (alpine 3.19.1)
Total: 3 (HIGH: 2, CRITICAL: 1)

┌──────────────┬────────────────┬──────────┬───────────────────┐
│   Library    │ Vulnerability  │ Severity │  Fixed Version    │
├──────────────┼────────────────┼──────────┼───────────────────┤
│ openssl      │ CVE-2024-0727  │ HIGH     │ 3.1.4-r5          │
│ busybox      │ CVE-2023-42365 │ HIGH     │ 1.36.1-r15        │
│ libcrypto3   │ CVE-2024-0727  │ CRITICAL │ 3.1.4-r5          │
└──────────────┴────────────────┴──────────┴───────────────────┘

CI/CD-Integration für Container-Scanning

Image-Scanning zur Pipeline hinzufügen, damit anfällige Images nie die Produktion erreichen.

GitHub Actions:

name: Container Security

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:${{ github.sha }}'
          format: 'table'
          exit-code: '1'  # Fail on HIGH/CRITICAL
          severity: 'HIGH,CRITICAL'
          ignore-unfixed: true

GitLab CI:

container_scanning:
  stage: test
  image:
    name: aquasec/trivy
    entrypoint: [""]
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  allow_failure: false

Image-Signierung und -Verifizierung

Nach Supply-Chain-Angriffen wie SolarWinds und CodeCov wurde die Verifizierung der Image-Authentizität kritisch. Image-Signierung stellt sicher, dass:

Das Image nicht manipuliert wurde
Es von Ihrer CI/CD-Pipeline gebaut wurde, nicht von einem Angreifer
Nur signierte Images in die Produktion deployt werden können

Cosign (von Sigstore) ist das Standard-Tool für das Signieren von Container-Images:

# Install cosign
brew install cosign  # macOS
# or download from https://github.com/sigstore/cosign/releases

# Generate a key pair (do this once, store private key securely)
cosign generate-key-pair

# Sign an image
cosign sign --key cosign.key myregistry.com/myapp:v1.0.0

# Verify a signature
cosign verify --key cosign.pub myregistry.com/myapp:v1.0.0

Schlüssellose Signierung mit Sigstore (empfohlen für CI/CD):

# GitHub Actions with keyless signing
name: Build and Sign

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write  # Required for keyless signing
      packages: write
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Install cosign
        uses: sigstore/cosign-installer@v3
      
      - name: Login to registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      
      - name: Build and push
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
      
      - name: Sign image with cosign
        run: |
          cosign sign --yes ghcr.io/${{ github.repository }}@${{ steps.build.outputs.digest }}

Die schlüssellose Signierung verwendet OIDC (OpenID Connect) — keine privaten Schlüssel zu verwalten. Die Signatur enthält den Nachweis, dass das Image von einem bestimmten GitHub Actions-Workflow erstellt wurde.

Container-Registry-Sicherheit

Ziehen Sie keine Images von Docker Hub ohne Validierung. Verwenden Sie eine private Registry mit Sicherheitskontrollen.

Registry-Optionen:

| Registry | Am besten für | Funktionen | ||----------|----------|----------| | AWS ECR | AWS-native Apps | IAM-Integration, automatisches Scanning, Image-Signierung | | Google Artifact Registry | GCP-Apps | IAM, Schwachstellen-Scanning, SBOM-Generierung | | Azure Container Registry | Azure-Apps | AAD-Integration, Geo-Replikation, Content Trust | | Harbor | Selbst gehostet, Multi-Cloud | Schwachstellen-Scanning, RBAC, Image-Signierung, Replikation | | GitHub Container Registry | Open Source, GitHub-nativ | Kostenlos für öffentliche Repos, GitHub Actions-Integration |

Checkliste für Registry-Sicherheit:

Schwachstellen-Scanning beim Push aktivieren
Image-Signierung für Produktions-Images vorschreiben
Aufbewahrungsrichtlinien zum Löschen alter, ungetaggter Images festlegen
Unveränderliche Tags verwenden (vorhandene Tags können nicht überschrieben werden)
Audit-Protokollierung für alle Pull/Push-Operationen aktivieren
Einschränken, wer Images pushen kann (nur CI/CD-Service-Accounts)
Pulls von Images mit kritischen Schwachstellen blockieren

AWS ECR-Beispiel:

# Enable scanning on push
aws ecr put-image-scanning-configuration \
  --repository-name myapp \
  --image-scanning-configuration scanOnPush=true

# Set lifecycle policy (delete untagged images after 7 days)
aws ecr put-lifecycle-policy \
  --repository-name myapp \
  --lifecycle-policy-text '{
    "rules": [{
      "rulePriority": 1,
      "description": "Delete untagged images",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 7
      },
      "action": { "type": "expire" }
    }]
  }'

Laufzeitsicherheit

Das Scannen von Images erkennt bekannte Schwachstellen. Aber was ist mit:

Zero-Day-Exploits
Angreifern, die über Anwendungs-Schwachstellen hereingekommen sind
Kryptominern, die über kompromittierte Abhängigkeiten deployt wurden
Datenexfiltrations-Versuchen

Laufzeitsicherheits-Tools überwachen das Container-Verhalten und warnen bei Anomalien.

Falco ist das Standard-Open-Source-Tool für Laufzeitsicherheit:

# Install Falco
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco --namespace falco --create-namespace

Falco erkennt:

Im Container gespawnte Shell
Zugriff auf sensible Dateien (/etc/passwd, /etc/shadow)
Netzwerkverbindungen zu ungewöhnlichen Zielen
Privilege-Escalation-Versuche
Kryptomining-Prozesse

Beispiel-Falco-Warnungen:

23:45.123 Warning: Shell spawned in container (container_id=abc123 container_name=myapp shell=/bin/sh)
24:01.456 Critical: Sensitive file opened for reading (file=/etc/shadow container=myapp)
25:33.789 Warning: Outbound connection to known cryptomining pool (dest=pool.minexmr.com container=myapp)

Falco-Regelbeispiel:

# Detect when someone runs shell in production container
- rule: Shell in Production Container
  desc: Detect shell execution in production containers
  condition: >
    spawned_process and 
    container and
    proc.name in (bash, sh, zsh, ksh) and
    container.image.repository contains "prod"
  output: >
    Shell spawned in production container 
    (user=%user.name container=%container.name shell=%proc.name)
  priority: WARNING

Vergleich von Laufzeitsicherheits-Tools:

Tool	Lizenz	Am besten für	Link
Falco	Apache 2.0	Kubernetes, allgemeine Laufzeiterkennung	falco.org
Sysdig	Kommerziell (kostenloser Tarif)	Enterprise, Compliance, Forensik	sysdig.com
Aqua	Kommerziell	Vollständige Container-Lebenszyklus-Sicherheit	aquasec.com
Tetragon	Apache 2.0	eBPF-basiert, geringer Overhead	tetragon.io

Für kleine Teams mit Falco beginnen. Es ist kostenlos, gut dokumentiert und erkennt die meisten Laufzeit-Bedrohungen.

Referenz: Container-Scanning-Tools

Tool	Am besten für	Lizenz	Link
Trivy	All-in-one-Scanning, einfache Einrichtung	Apache 2.0	trivy.dev
Grype	Schnelles CVE-Scanning, funktioniert mit Syft	Apache 2.0	github.com/anchore/grype
Clair	Registry-Integration, Enterprise-Skalierung	Apache 2.0	github.com/quay/clair
Docker Scout	Docker Hub-Integration, nativ	Kostenloser Tarif verfügbar	docker.com/products/docker-scout
Snyk Container	Entwicklerfreundlich, Behebungshinweise	Kostenloser Tarif verfügbar	snyk.io/product/container-security

Für kleine Teams ist Trivy die klare Wahl. Es ist kostenlos, schnell und erkennt die meisten Schwachstellen. Wenn Sie Docker Hub verwenden, ist Docker Scout praktisch, da es in das Docker CLI integriert ist (docker scout cves myimage:tag).

Kubernetes-Sicherheit

Wenn Sie Container in Kubernetes betreiben (EKS, GKE, AKS oder selbst verwaltet), haben Sie eine weitere Sicherheitsebene zu konfigurieren. Kubernetes-Standardeinstellungen sind permissiv — für schnellen Einstieg, nicht für Produktionssicherheit ausgelegt.

Kubernetes-Sicherheitsgrundlagen

Die Angriffsfläche:

| Komponente | Risiko bei Fehlkonfiguration | ||-----------|----------------------| | API Server | Vollständiger Cluster-Zugriff, kann jeden Workload deployen | | etcd | Enthält alle Cluster-Geheimnisse und den Zustand | | Kubelet | Zugriff auf Knotenebene, kann jeden Container ausführen | | Pods | Container-Ausbruch, Privilege-Escalation | | Netzwerk | Pod-zu-Pod-Angriffe, Datenexfiltration | | RBAC | Privilege-Escalation, unbefugter Zugriff | | Secrets | Zugangsdaten-Diebstahl, Datenexposition |

Pod-Sicherheit

Kubernetes 1.25+ verwendet Pod-Sicherheitsstandards, die durch Pod Security Admission durchgesetzt werden:

| Ebene | Was es erlaubt | Anwendungsfall | ||-------|---------------|----------| | Privilegiert | Alles | Nur Systemkomponenten | | Baseline | Verhindert bekannte Privilege-Escalations | Die meisten Anwendungen | | Eingeschränkt | Maximale Sicherheit, minimale Berechtigungen | Sensible Workloads |

Pod Security Admission aktivieren:

# Namespace with restricted pod security
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Sichere Pod-Spezifikation:

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:v1.0.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL
    resources:
      limits:
        cpu: "500m"
        memory: "256Mi"
      requests:
        cpu: "100m"
        memory: "128Mi"

RBAC-Best-Practices

Role-Based Access Control (RBAC) bestimmt, wer was in Ihrem Cluster tun darf.

Bestehende Berechtigungen prüfen:

# Who can create pods?
kubectl auth can-i create pods --all-namespaces --list

# What can a specific service account do?
kubectl auth can-i --list --as=system:serviceaccount:default:myapp

# Find overly permissive ClusterRoleBindings
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

RBAC nach dem Prinzip der minimalen Berechtigungen:

# Role with minimal permissions
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: myapp
  name: myapp-role
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["myapp-secrets"]  # Only specific secret
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: myapp-binding
  namespace: myapp
subjects:
- kind: ServiceAccount
  name: myapp
  namespace: myapp
roleRef:
  kind: Role
  name: myapp-role
  apiGroup: rbac.authorization.k8s.io

Zu vermeidende RBAC-Anti-Muster:

# BAD: Wildcard permissions
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

# BAD: cluster-admin for applications
roleRef:
  kind: ClusterRole
  name: cluster-admin

# BAD: Default service account with permissions
# (Don't add permissions to "default" service account)

Netzwerkrichtlinien

Standardmäßig können alle Pods mit allen anderen Pods kommunizieren. Netzwerkrichtlinien schränken dies ein.

# Deny all ingress by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
# Allow only specific traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Secrets in Kubernetes

Kubernetes-Secrets sind Base64-kodiert, nicht verschlüsselt. Jeder mit Zugriff auf etcd oder die API kann sie lesen.

Bessere Optionen:

Verschlüsselung im Ruhezustand aktivieren:

# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}

External Secrets Operator mit Passwork verwenden:

# ExternalSecret that pulls from Passwork
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-secrets
  namespace: myapp
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: passwork-store
    kind: SecretStore
  target:
    name: app-secrets
  data:
  - secretKey: database-password
    remoteRef:
      key: database-credentials
      property: password

Cloud-Provider-Secrets-Manager verwenden:

# AWS Secrets Manager with EKS
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: aws-secrets
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: "myapp/database"
        objectType: "secretsmanager"

Kubernetes-Sicherheits-Auditing

Kubescape scannt Cluster gegen Sicherheits-Frameworks:

# Install
curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

# Scan cluster
kubescape scan framework nsa

# Scan against CIS benchmark
kubescape scan framework cis-v1.23-t1.0.1

# Scan specific namespace
kubescape scan framework nsa --include-namespaces production

kube-bench prüft gegen das CIS Kubernetes Benchmark:

# Run as a job in the cluster
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# View results
kubectl logs -l app=kube-bench

Kubernetes-Sicherheits-Tools:

Tool	Was es prüft	Link
Kubescape	NSA/CISA, MITRE ATT&CK, CIS-Benchmarks	kubescape.io
kube-bench	CIS Kubernetes Benchmark	github.com/aquasecurity/kube-bench
Polaris	Konfigurations-Best-Practices	github.com/FairwindsOps/polaris
kube-hunter	Penetration-Testing für K8s	github.com/aquasecurity/kube-hunter

Cloud-Infrastruktur-Sicherheit

Cloud-Provider liefern die Bausteine, aber Sicherheit liegt in Ihrer Verantwortung. Das ist das „Modell der geteilten Verantwortung" — AWS/GCP/Azure sichern die physische Infrastruktur und den Hypervisor, Sie sichern alles, was Sie konfigurieren.

Häufige Cloud-Fehlkonfigurationen

Diese Probleme verursachen Datenpannen:

| Fehlkonfiguration | Risiko | Wie es passiert | ||-----------------|------|----------------| | Öffentliche S3/GCS-Buckets | Datenexposition | Entwickler setzt öffentlichen Zugriff „vorübergehend" für Tests | | Übermäßig permissives IAM | Privilege-Escalation | Verwendung von * in IAM-Richtlinien aus Bequemlichkeit | | Unverschlüsselter Speicher | Datendiebstahl | Standard-Verschlüsselung nicht aktiviert | | Offene Security-Groups | Unbefugter Zugriff | SSH/RDP für 0.0.0.0/0 beim Debugging geöffnet | | Exponierte Datenbanken | Datenpanne | RDS/CloudSQL mit öffentlicher IP und schwachem Passwort | | Fehlende Protokollierung | Blindheit bei Vorfällen | CloudTrail/Audit-Logs nicht aktiviert | | Ungenutzte Zugriffsschlüssel | Zugangsdaten-Kompromittierung | Alte Entwickler-Schlüssel nie rotiert | | Kein MFA auf Root-Konto | Kontoübernahme | Root-Zugangsdaten kompromittiert, vollständiger Zugriff | | Cross-Account-Trust | Laterale Bewegung | Übermäßig breite AssumeRole-Berechtigungen |

Sicherheitsprinzipien für Cloud-Ressourcen

Minimale Berechtigungen überall. Jede IAM-Rolle, jede Security-Group, jeder Service-Account sollte minimale erforderliche Berechtigungen haben. Mit null Zugriff beginnen, nur das Notwendige hinzufügen.

// BAD: Full admin access
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

// GOOD: Specific permissions for specific resources
{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::my-app-uploads/*"
}

Alles verschlüsseln. Verschlüsselung im Ruhezustand für alle Speicher aktivieren (S3, RDS, EBS, GCS). TLS für alle Daten während der Übertragung verwenden. Standard-Verschlüsselung aktivieren, damit neue Ressourcen automatisch geschützt sind.

Standardmäßig kein öffentlicher Zugriff. Öffentlichen Zugriff auf Kontoebene für S3 blockieren, private Subnetze für Datenbanken vorschreiben, VPN oder Bastion-Hosts für Administratorzugriff verwenden.

Protokollierung aktivieren. CloudTrail (AWS), Cloud Audit Logs (GCP) oder Activity Log (Azure) von Tag eins an einschalten. Was nicht protokolliert wird, kann nicht untersucht werden.

Alles taggen. Tags wie environment, owner, cost-center helfen dabei zu verstehen, was läuft und wer verantwortlich ist. Ungetaggte Ressourcen sind oft verwaist und vergessen — perfekte Ziele.

Netzwerksicherheit in der Cloud

VPC-Designprinzipien:

Drei Subnetz-Schichten, jeweils repliziert über Verfügbarkeitszonen:

Öffentliche Subnetze (AZ-a, AZ-b) — Load Balancer, NAT Gateway. Nur diese haben Internet-seitige Exposition.
Private Subnetze (AZ-a, AZ-b) — App-Server. Keine öffentliche IP. Ausgehender Internet-Zugriff nur über NAT Gateway.
Datenbank-Subnetze (AZ-a, AZ-b) — RDS / Datenbanken. Kein Internet-Zugriff, nur von privaten Subnetzen erreichbar.

Netzwerksicherheits-Checkliste:

Datenbanken in privaten Subnetzen (keine öffentliche IP)
NAT Gateway für ausgehenden Internet-Zugriff aus privaten Subnetzen
Security-Groups: standardmäßig ablehnen, spezifische Ports/Quellen erlauben
NACLs als zusätzliche Schicht für Subnetz-Filterung
VPC-Flow-Logs für Traffic-Analyse aktiviert
PrivateLink/Private Service Connect für AWS/GCP-Dienst-Zugriff
WAF vor öffentlich zugänglichen Anwendungen
DDoS-Schutz (AWS Shield, Cloud Armor, Azure DDoS Protection)

Best Practices für Security-Groups:

# BAD: SSH open to the world
aws ec2 authorize-security-group-ingress \
  --group-id sg-123 \
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0

# GOOD: SSH only from VPN/bastion
aws ec2 authorize-security-group-ingress \
  --group-id sg-123 \
  --protocol tcp \
  --port 22 \
  --source-group sg-bastion

AWS-Sicherheits-Checkliste

| Kategorie | Prüfung | Wie zu verifizieren | ||----------|-------|---------------| | Konto | MFA auf Root-Konto | Konsole → IAM → Root-Konto-MFA | | Konto | Keine Root-Zugriffsschlüssel | aws iam get-account-summary | | IAM | Passwortrichtlinie durchgesetzt | aws iam get-account-password-policy | | IAM | Keine Inline-Richtlinien | aws iam list-user-policies | | IAM | Ungenutzte Zugangsdaten deaktiviert | IAM Credential Report | | S3 | Öffentlicher Zugriff blockiert | aws s3control get-public-access-block | | S3 | Standard-Verschlüsselung aktiviert | aws s3api get-bucket-encryption | | S3 | Zugriffsprotokollierung aktiviert | aws s3api get-bucket-logging | | EC2 | EBS-Verschlüsselung Standard | aws ec2 get-ebs-encryption-by-default | | EC2 | Keine öffentlichen AMIs | aws ec2 describe-images --owners self | | RDS | Nicht öffentlich zugänglich | aws rds describe-db-instances | | RDS | Verschlüsselung im Ruhezustand | aws rds describe-db-instances | | CloudTrail | Aktiviert, Multi-Region | aws cloudtrail describe-trails | | Config | Aufzeichnung aktiviert | aws configservice describe-configuration-recorders | | GuardDuty | Aktiviert | aws guardduty list-detectors |

AWS-Quick-Wins-Skript:

#!/bin/bash
# aws-security-quick-wins.sh

# Block public access at account level
aws s3control put-public-access-block \
  --account-id $(aws sts get-caller-identity --query Account --output text) \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

# Enable default EBS encryption
aws ec2 enable-ebs-encryption-by-default

# Enable GuardDuty
aws guardduty create-detector --enable

# Enable Security Hub
aws securityhub enable-security-hub

# Create CloudTrail (if not exists)
aws cloudtrail create-trail \
  --name main-trail \
  --s3-bucket-name my-cloudtrail-logs \
  --is-multi-region-trail \
  --enable-log-file-validation
aws cloudtrail start-logging --name main-trail

echo "AWS security quick wins applied!"

GCP-Sicherheits-Checkliste

| Kategorie | Prüfung | Wie zu verifizieren | ||----------|-------|---------------| | IAM | Keine primitiven Rollen (Owner/Editor) | gcloud projects get-iam-policy PROJECT | | IAM | Service-Account-Schlüssel-Rotation | gcloud iam service-accounts keys list | | Speicher | Einheitlicher Bucket-Level-Zugriff | gsutil uniformbucketlevelaccess get | | Speicher | Keine öffentlichen Buckets | gsutil iam get gs://BUCKET | | Compute | Kein Standard-Service-Account | gcloud compute instances list | | Compute | Shielded VMs aktiviert | gcloud compute instances describe | | Protokollierung | Audit-Logs aktiviert | Konsole → IAM → Audit Logs | | VPC | Private Google Access aktiviert | gcloud compute networks subnets list | | GKE | Privater Cluster | gcloud container clusters describe | | GKE | Workload Identity aktiviert | gcloud container clusters describe |

GCP-Quick-Wins:

# Enable organization policies (requires Org Admin)
gcloud resource-manager org-policies allow \
  compute.requireShieldedVm --organization=ORG_ID

gcloud resource-manager org-policies deny \
  iam.allowedPolicyMemberDomains --organization=ORG_ID

# Enable audit logs for all services
# (Best done in Console: IAM → Audit Logs → Default Config)

# Check for public buckets
for bucket in $(gsutil ls); do
  echo "Checking $bucket..."
  gsutil iam get $bucket | grep -i allUsers && echo "WARNING: $bucket is public!"
done

Azure-Sicherheits-Checkliste

| Kategorie | Prüfung | Wie zu verifizieren | ||----------|-------|---------------| | AAD | MFA durchgesetzt | Azure AD → Security → MFA | | AAD | Richtlinien für bedingten Zugriff | Azure AD → Security → Conditional Access | | AAD | Keine Gastbenutzer mit Admin | Azure AD → Users → Guest users | | Speicher | Sichere Übertragung erforderlich | az storage account show | | Speicher | Privater Endpunkt aktiviert | az storage account show | | SQL | Azure AD-Authentifizierung aktiviert | az sql server ad-admin list | | SQL | TDE aktiviert | az sql db tde show | | Netzwerk | NSG-Flow-Logs aktiviert | az network watcher flow-log list | | Defender | Defender for Cloud aktiviert | az security pricing list | | KeyVault | Soft Delete aktiviert | az keyvault show |

Azure-Quick-Wins:

# Enable Defender for Cloud free tier
az security pricing create --name VirtualMachines --tier free

# Check for public storage accounts
az storage account list --query "[?allowBlobPublicAccess==\`true\`].name"

# Enable secure transfer for all storage accounts
for account in $(az storage account list --query "[].name" -o tsv); do
  az storage account update --name $account --https-only true
done

# Enable activity log alerts
az monitor activity-log alert create \
  --name "Security Alert" \
  --resource-group my-rg \
  --condition category=Security

Cloud-Infrastruktur prüfen

Automatische Audit-Tools prüfen Ihre Cloud-Konfiguration gegen Sicherheits-Best-Practices. Sie vergleichen Ihre Einrichtung mit Benchmarks wie CIS (Center for Internet Security) und kennzeichnen Fehlkonfigurationen.

ScoutSuite

ScoutSuite ist ein Multi-Cloud-Sicherheits-Audit-Tool. Es unterstützt AWS, Azure, GCP, Alibaba Cloud und Oracle Cloud.

Installation:

pip install scoutsuite

Audit ausführen:

# AWS (uses your default credentials)
scout aws

# GCP
scout gcp --user-account

# Azure
scout azure --cli

ScoutSuite generiert einen HTML-Bericht mit nach Dienst und Schweregrad gruppierten Befunden. Jeder Befund enthält die betroffene Ressource, warum es ein Problem ist und wie man es behebt.

Beispiel-Befunde:

S3-Buckets mit öffentlichem Lesezugriff
IAM-Benutzer ohne aktiviertes MFA
Security-Groups mit offenem SSH für das Internet
Öffentlich zugängliche RDS-Instanzen
Unverschlüsselte EBS-Volumes

Prowler

Prowler ist speziell für AWS und bietet die umfassendste AWS-Sicherheitsbewertung. Es prüft gegen CIS AWS Foundations Benchmark, PCI-DSS, HIPAA und andere Compliance-Frameworks.

Installation:

pip install prowler

Audit ausführen:

# Full AWS audit
prowler aws

# Specific checks only
prowler aws --checks ec2_instance_public_ip,s3_bucket_public_access

# Output formats
prowler aws -M csv,html,json

# Check specific region
prowler aws -f us-east-1

# Check against specific compliance framework
prowler aws --compliance cis_2.0_aws

CI/CD-Integration:

# GitHub Actions
name: Cloud Security Audit

on:
  schedule:
    - cron: '0 6 * * 1'  # Weekly on Monday at 6 AM

jobs:
  prowler:
    runs-on: ubuntu-latest
    steps:
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1
      
      - name: Install Prowler
        run: pip install prowler
      
      - name: Run Prowler
        run: prowler aws -M json -o results/
      
      - name: Upload results
        uses: actions/upload-artifact@v4
        with:
          name: prowler-report
          path: results/

Cloud-native Sicherheits-Tools

Cloud-Provider bieten ihre eigenen Sicherheitsbewertungs-Tools an:

| Provider | Tool | Kosten | Was es prüft | ||----------|------|------|----------------| | AWS | Security Hub | Kostenloser Tarif + pro Befund | Aggregiert Befunde aus mehreren Quellen, CIS-Benchmarks | | AWS | Trusted Advisor | Kostenlos (begrenzt) / Business+ | Kosten, Leistung, Sicherheit, Fehlertoleranz | | AWS | GuardDuty | Pro GB analysiert | Bedrohungserkennung, Anomalieerkennung | | GCP | Security Command Center | Kostenloser Tarif verfügbar | Schwachstellen, Fehlkonfigurationen, Bedrohungen | | GCP | Security Health Analytics | Kostenlos mit SCC | Best-Practice-Verletzungen | | Azure | Defender for Cloud | Kostenloser Tarif verfügbar | Sicherheitslage, Compliance, Bedrohungsschutz | | Azure | Secure Score | Kostenlos | Gesamtbewertung der Sicherheitslage |

Für kleine Teams mit den kostenlosen Open-Source-Tools (ScoutSuite, Prowler) beginnen und die kostenlosen Tarife der Cloud-nativen Tools aktivieren. Sie ergänzen sich — Cloud-native Tools erkennen oft Laufzeit-Bedrohungen, die Audit-Tools übersehen.

Umgang mit Sicherheitsbefunden

Wenn Prowler 200 Probleme findet oder Trivy 50 Schwachstellen meldet, brauchen Sie einen systematischen Ansatz zur Priorisierung und Behebung.

Triage-Prozess

Schritt 1: Nach Schweregrad und Ausnutzbarkeit kategorisieren

| Priorität | Kriterien | Maßnahmen-Zeitrahmen | ||----------|----------|-----------------| | P1 - Kritisch | Aktiv ausgenutzt ODER öffentlich zugänglich mit bekanntem Exploit | Innerhalb von 24 Stunden beheben | | P2 - Hoch | Hoher Schweregrad, leicht ausnutzbar, Produktionsauswirkung | Innerhalb von 1 Woche beheben | | P3 - Mittel | Mittlerer Schweregrad, Bedingungen für Ausnutzung erforderlich | Innerhalb von 1 Monat beheben | | P4 - Niedrig | Geringer Schweregrad, Defense-in-Depth | Beim nächsten Wartungsfenster beheben | | Akzeptieren | Sehr geringes Risiko, kein Fix verfügbar, kompensierende Kontrollen | Dokumentieren und akzeptieren |

Schritt 2: Verifizieren, dass der Befund real ist

Nicht alle Befunde sind tatsächliche Probleme:

# Example: Prowler says S3 bucket is public
# Verify manually
aws s3api get-bucket-acl --bucket my-bucket
aws s3api get-bucket-policy --bucket my-bucket
aws s3api get-public-access-block --bucket my-bucket

# It might be intentionally public (static website hosting)
# If intentional, document and suppress future alerts

Schritt 3: Behebungs-Tickets erstellen

Für jeden P1-P3-Befund:

Was ist das Problem?
Welche Ressource ist betroffen?
Wie ist es zu beheben?
Wer ist für den Fix verantwortlich?
Frist basierend auf Priorität

Schritt 4: Behebung verfolgen

# Security Findings Tracker

| Finding ID | Description | Priority | Owner | Deadline | Status |
|------------|-------------|----------|-------|----------|--------|
| PROWLER-001 | S3 bucket public | P1 | DevOps | 2024-01-15 | Fixed |
| TRIVY-042 | OpenSSL CVE-2024-0727 | P2 | Dev | 2024-01-20 | In Progress |
| SCOUT-018 | CloudTrail not enabled | P2 | DevOps | 2024-01-22 | Open |

Falsch-Positive unterdrücken

Wenn ein Befund beabsichtigt oder ein Falsch-Positiv ist, ihn unterdrücken, um Berichte sauber zu halten:

Trivy:

# .trivyignore
# Ignore specific CVE (with reason)
CVE-2024-0727  # Fixed in next base image update, not exploitable in our context

# Ignore by package
pkg:apk/busybox

Prowler:

# Create allowlist file
prowler aws --allowlist allowlist.yaml

# allowlist.yaml
Accounts:
  "123456789012":
    Checks:
      s3_bucket_public_access:
        Regions:
          - us-east-1
        Resources:
          - "arn:aws:s3:::my-public-website-bucket"  # Intentionally public

ScoutSuite:

# scout-exceptions.json
{
  "s3": {
    "buckets": {
      "my-public-website-bucket": ["is_public"]
    }
  }
}

Häufige Fehler

Images scannen, aber Befunde nicht beheben. Ein Scan, der 50 kritische Schwachstellen findet und nichts passiert, ist schlimmer als kein Scan — er erzeugt falsches Vertrauen. Kritische Befunde priorisieren und beheben.

latest-Tags in der Produktion verwenden. Ihr Dockerfile sagt FROM node:latest. Heute ist es Node 20.12. Morgen ist es Node 21 mit Breaking Changes. Versionen fixieren.

Basis-Image-Updates ignorieren. Ihr Anwendungscode ist in Ordnung, aber Ihr Basis-Image von vor 6 Monaten hat 20 neue CVEs. Images regelmäßig neu bauen, auch wenn sich Ihr Code nicht geändert hat.

Admin-Zugriff „vorübergehend" gewähren. Ein Entwickler muss etwas debuggen, bekommt Admin-Berechtigungen, und diese Berechtigungen werden nie widerrufen. Spezifische, begrenzte Berechtigungen von Anfang an erstellen.

Sicherheits-Scans deaktivieren, um Deployments zu entsperren. Ein Scan findet ein Problem, das Team kann es nicht sofort beheben, also deaktiviert man den Scanner. Jetzt sind sie auch für zukünftige Schwachstellen blind. Stattdessen Allowlists für akzeptierte Risiken verwenden.

Einmal prüfen statt kontinuierlich. Prowler einmal im Jahr vor einem Audit auszuführen hilft nicht. Konfigurations-Drift passiert täglich. Wöchentliche oder monatliche automatische Scans einrichten.

Kubernetes-Standardeinstellungen als sicher behandeln. Das sind sie nicht. Standard-Pod-Sicherheit erlaubt Root, privilegierte Container, Host-Netzwerk-Zugriff. Pod-Sicherheitsstandards von Tag eins an durchsetzen.

Geheimnisse in Kubernetes-Secrets ohne Verschlüsselung speichern. Base64 ist keine Verschlüsselung. Verschlüsselung im Ruhezustand aktivieren oder External Secrets Operator verwenden.

Reale Vorfälle

Capital One-Datenpanne (2019): Eine fehlkonfigurierte WAF ermöglichte es einem Angreifer, über SSRF auf IAM-Zugangsdaten zuzugreifen, was zur Exposition von 100+ Millionen Kundendatensätzen führte. Das zugrundeliegende Problem waren übermäßig permissive IAM-Rollen, die Zugriff auf S3-Buckets ermöglichten. Quelle: Wikipedia

Tesla-Kryptomining (2018): Ein exponiertes Kubernetes-Dashboard (ohne Authentifizierung) ermöglichte es Angreifern, Kryptowährungs-Miner auf Teslas AWS-Infrastruktur zu deployen. Das Dashboard hatte auch Zugriff auf AWS-Zugangsdaten. Quelle: Wired

Uber-Datenpanne (2016): Angreifer fanden AWS-Zugangsdaten in einem privaten GitHub-Repository, nutzten sie für den Zugriff auf S3-Buckets mit Daten von 57 Millionen Nutzern. Die Zugangsdaten hätten niemals in einem Repository sein dürfen, und die S3-Buckets hätten zusätzliche Authentifizierung erfordern sollen. Quelle: Bloomberg

Code Spaces-Schließung (2014): Angreifer verschafften sich Zugang zur AWS-Konsole, löschten alle Daten, Backups und Maschinenkonfigurationen. Das Unternehmen konnte sich nicht erholen und schloss innerhalb von 12 Stunden. Kein MFA auf AWS-Konten, keine externen Backups. Quelle: Info Security Magazine

Twitch-Quellcode-Leak (2021): 125 GB Daten einschließlich Quellcode, interner Tools und Creator-Auszahlungen wurden über einen fehlkonfigurierten Server geleakt. Quelle: The Verge

Verkada-Kamera-Datenpanne (2021): Angreifer griffen auf 150.000 Sicherheitskameras in Krankenhäusern, Gefängnissen und Unternehmen zu. Grundursache: hartcodierte Admin-Zugangsdaten im System. Quelle: Bloomberg

Workshop: Container- und Cloud-Sicherheit

Dieser Workshop führt Sie durch die Einrichtung von Container-Scanning, Kubernetes-Härtung und die Durchführung eines Cloud-Audits.

Teil 1: Docker-Image-Scanning

Aufgabe: Trivy-Scanning zu Ihrer CI/CD-Pipeline hinzufügen.

Trivy lokal installieren:

# macOS
brew install trivy

# Linux
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | \
  sh -s -- -b /usr/local/bin

Ein vorhandenes Image scannen:

# Scan your application image
trivy image your-app:latest

# If you don't have one, scan a common base image
trivy image node:20-alpine
trivy image python:3.12-slim

Befunde überprüfen:
- Wie viele KRITISCHE Schwachstellen?
- Wie viele haben verfügbare Fixes (Spalte „Fixed Version" prüfen)?
- Welches Paket hat die meisten Schwachstellen?

Scanning zu CI/CD hinzufügen:

Für GitHub Actions .github/workflows/container-scan.yml erstellen:

name: Container Scan

on:
  push:
    branches: [main]
  pull_request:

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Build image
        run: docker build -t app:${{ github.sha }} .
      
      - name: Scan image
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'app:${{ github.sha }}'
          exit-code: '1'
          severity: 'CRITICAL'
          ignore-unfixed: true

Pipeline testen: Einen Commit pushen und prüfen, ob der Scan läuft.

Teil 2: Kubernetes-Sicherheit (falls zutreffend)

Aufgabe: Sicherheit Ihres Kubernetes-Clusters prüfen.

Kubescape installieren:

curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

Sicherheits-Scan ausführen:

# Scan against NSA/CISA framework
kubescape scan framework nsa

# Scan specific namespace
kubescape scan framework nsa --include-namespaces production

Top-Probleme überprüfen und beheben:
- Als Root laufende Container
- Fehlende Ressourcenlimits
- Privilegierte Container
- Fehlende Netzwerkrichtlinien
Eine gehärtete Pod-Vorlage für Ihr Team erstellen.

Teil 3: Cloud-Infrastruktur-Audit

Aufgabe: ScoutSuite oder Prowler gegen Ihr Cloud-Konto ausführen.

Für AWS mit Prowler:

pip install prowler

# Run focused checks first (faster)
prowler aws --checks s3_bucket_public_access,iam_user_mfa_enabled,ec2_security_group_default_restrict_traffic

# Full audit (takes longer)
prowler aws -M html

Für Multi-Cloud oder Nicht-AWS:

pip install scoutsuite

# AWS
scout aws

# GCP
scout gcp --user-account

# Azure  
scout azure --cli

Befunde überprüfen:
- Den generierten HTML-Bericht öffnen
- Sich auf HOHE und KRITISCHE Schwachstellen konzentrieren
- Nach Dienst gruppieren (S3, IAM, EC2 usw.)
Einen Behebungsplan erstellen:
- Die Top-5-Befunde nach Schweregrad auswählen
- Dokumentieren, was geändert werden muss
- Verantwortlichen und Frist zuweisen

Zu produzierende Ergebnisse

Nach diesem Workshop sollten Sie haben:

Trivy in CI/CD integriert — Pipeline-YAML-Datei mit Image-Scanning
Signierte Container-Images — Cosign in Build-Pipeline integriert
Cloud-Audit-Bericht — HTML/PDF-Export aus ScoutSuite oder Prowler
Behebungsplan — priorisierte Liste der Befunde mit Verantwortlichen und Fristen
Sichere Dockerfile-Vorlage — Beispiel-Dockerfile nach Best Practices für Ihren Stack
Kubernetes-Sicherheitsrichtlinie (falls zutreffend) — Pod-Sicherheitsstandards, RBAC-Regeln, Netzwerkrichtlinien

Selbstprüfungs-Fragen

Bevor Sie weitermachen, prüfen Sie, ob Sie folgende Fragen beantworten können:

Was ist der Unterschied zwischen Alpine- und Distroless-Basis-Images?
Warum sollten Sie Container-Images signieren, und wie hilft Cosign dabei?
Was erkennt Falco, das Trivy nicht erkennt?
Was sind Kubernetes-Pod-Sicherheitsstandards und ihre drei Ebenen?
Wie gehen Sie mit Geheimnissen in Kubernetes ordnungsgemäß um?
Was ist das Modell der geteilten Verantwortung in der Cloud-Sicherheit?
Nennen Sie fünf häufige Cloud-Fehlkonfigurationen, die zu Datenpannen führen.
Was prüft ScoutSuite, das Prowler nicht prüft (oder umgekehrt)?
Wie sollten Sie 200 Sicherheitsbefunde aus einem Cloud-Audit priorisieren?
Wie oft sollten Sie Cloud-Sicherheits-Audits durchführen?

Gespräch mit der Führungsebene

Bei der Präsentation von Container- und Cloud-Sicherheit vor dem Management:

Mit dem Risiko beginnen: „Wir betreiben Dutzende von Containern auf AWS/GCP. Eine fehlkonfigurierte Einstellung könnte Kundendaten exponieren. Diese Tools finden diese Fehlkonfigurationen automatisch, bevor Angreifer es tun."

Konkrete Beispiele zeigen: „Unser Audit fand 3 S3-Buckets, die öffentlich lesbar waren. Sie enthielten Backup-Dateien. Hier ist die Liste dessen, was wir behoben haben."

Verbesserung quantifizieren: „Vor diesen Tools hatten wir keine Sichtbarkeit in unsere Cloud-Sicherheitslage. Jetzt haben wir wöchentliche automatische Scans, die Probleme wie [konkretes Beispiel] erkennen."

Kosten vergleichen: „Diese Tools sind kostenlos. Eine Datenpanne kostet im Durchschnitt 4,45 Millionen Dollar. Die Tools benötigen ein paar Stunden zum Einrichten und Minuten für den wöchentlichen Betrieb."

Mit Compliance verbinden: „Falls wir jemals SOC 2- oder ISO 27001-Zertifizierung benötigen, sind diese Audits erforderlich. Jetzt damit anzufangen bedeutet, dass wir bereits vorbereitet sind."

Auf reale Vorfälle verweisen: „Code Spaces ging innerhalb von 12 Stunden pleite, nachdem Angreifer in ihre AWS-Konsole eingedrungen waren. Wir haben jetzt MFA aktiviert und Berechtigungen reduziert, um das zu verhindern."

Links und Ressourcen

Container-Sicherheit

Kubernetes-Sicherheit

Cloud-Sicherheits-Auditing

Best Practices und Benchmarks

Was kommt als Nächstes

Container abgesichert, Cloud-Infrastruktur gehärtet, Netzwerk segmentiert. Die Angriffsfläche ist kleiner — aber nicht null.

Als Nächstes: Sicherheits-Protokollierung und Überwachung — zentralisierte Protokollierung und Warnungen einrichten, damit Sie es merken, wenn doch etwas durchkommt, bevor sich der Schaden ausbreitet.

Warum das für kleine Unternehmen wichtig ist​

Container-Sicherheit​

Sichere Images erstellen​

Geheimnisse in Containern​

Image-Scanning mit Trivy​

CI/CD-Integration für Container-Scanning​

Image-Signierung und -Verifizierung​

Container-Registry-Sicherheit​

Laufzeitsicherheit​

Referenz: Container-Scanning-Tools​

Kubernetes-Sicherheit​

Kubernetes-Sicherheitsgrundlagen​

Pod-Sicherheit​

RBAC-Best-Practices​

Netzwerkrichtlinien​

Secrets in Kubernetes​

Kubernetes-Sicherheits-Auditing​

Cloud-Infrastruktur-Sicherheit​

Häufige Cloud-Fehlkonfigurationen​

Sicherheitsprinzipien für Cloud-Ressourcen​

Netzwerksicherheit in der Cloud​

AWS-Sicherheits-Checkliste​

GCP-Sicherheits-Checkliste​

Azure-Sicherheits-Checkliste​

Cloud-Infrastruktur prüfen​

ScoutSuite​

Prowler​

Cloud-native Sicherheits-Tools​

Umgang mit Sicherheitsbefunden​

Triage-Prozess​

Falsch-Positive unterdrücken​

Häufige Fehler​

Reale Vorfälle​

Workshop: Container- und Cloud-Sicherheit​

Teil 1: Docker-Image-Scanning​

Teil 2: Kubernetes-Sicherheit (falls zutreffend)​

Teil 3: Cloud-Infrastruktur-Audit​

Zu produzierende Ergebnisse​

Selbstprüfungs-Fragen​

Gespräch mit der Führungsebene​

Links und Ressourcen​

Container-Sicherheit​

Kubernetes-Sicherheit​

Cloud-Sicherheits-Auditing​

Best Practices und Benchmarks​

Was kommt als Nächstes​

Warum das für kleine Unternehmen wichtig ist

Container-Sicherheit

Sichere Images erstellen

Geheimnisse in Containern

Image-Scanning mit Trivy

CI/CD-Integration für Container-Scanning

Image-Signierung und -Verifizierung

Container-Registry-Sicherheit

Laufzeitsicherheit

Referenz: Container-Scanning-Tools

Kubernetes-Sicherheit

Kubernetes-Sicherheitsgrundlagen

Pod-Sicherheit

RBAC-Best-Practices

Netzwerkrichtlinien

Secrets in Kubernetes

Kubernetes-Sicherheits-Auditing

Cloud-Infrastruktur-Sicherheit

Häufige Cloud-Fehlkonfigurationen

Sicherheitsprinzipien für Cloud-Ressourcen

Netzwerksicherheit in der Cloud

AWS-Sicherheits-Checkliste

GCP-Sicherheits-Checkliste

Azure-Sicherheits-Checkliste

Cloud-Infrastruktur prüfen

ScoutSuite

Prowler

Cloud-native Sicherheits-Tools

Umgang mit Sicherheitsbefunden

Triage-Prozess

Falsch-Positive unterdrücken

Häufige Fehler

Reale Vorfälle

Workshop: Container- und Cloud-Sicherheit

Teil 1: Docker-Image-Scanning

Teil 2: Kubernetes-Sicherheit (falls zutreffend)

Teil 3: Cloud-Infrastruktur-Audit

Zu produzierende Ergebnisse

Selbstprüfungs-Fragen

Gespräch mit der Führungsebene

Links und Ressourcen

Container-Sicherheit

Kubernetes-Sicherheit

Cloud-Sicherheits-Auditing

Best Practices und Benchmarks

Was kommt als Nächstes