Stärkung der Prod-Umgebung

Stärkung der Prod-Umgebung

1) Ziel und Rahmen

Die Stärkung (Hardening) der Prod-Umgebung ist eine systemische Sammlung von Praktiken, die die Wahrscheinlichkeit von Vorfällen und Schäden durch sie reduziert. Schwerpunkte: API-Perimeter, Kunden-/Zahlungsdaten, CI/CD, Containerplattform, Zugänge, Änderungssteuerung, Beobachtbarkeit und Compliance.

• Security by Design & Default: Erforderliche Mindestprivilegien, sichere Standardwerte.
• Zero Trust: Vertrauen Sie ohne Verifizierung weder dem Netzwerk noch den Identitäten.
• Defence-in-Depth: Mehrstufiger Schutz (Netzwerk → Service → App → Daten).
• Die Unbeweglichkeit der Artefakte: „einmal bauen, viele ausführen“.
• E2E-Spuren und Auditierbarkeit: Wer, wann, was hat sich verändert - und warum.

2) Bedrohungsmodell und kritische Assets

Vermögenswerte: Konten und Zahlungstoken, PII/Passdaten, RNG/Spielguthaben, Verschlüsselungsschlüssel, Integrationsgeheimnisse, Deploy-Pipelines, Containerbilder.
Vektoren: Abhängigkeitsschwachstellen, Token-Lecks, falsche Cloud/K8s-Konfiguration, SSRF/RCE in der API, Supply Chain (CI/CD/Repository-Kompromittierung), Insider-Zugriff, DDoS/Bot-Verkehr.
Szenarien: Auszahlungen durch eine nicht autorisierte Einheit, Ersetzen von Koeffizienten/Salden, Entleeren der Basis, Erfassen der Pipeline, manuelle Bearbeitungen in der Produktion.

3) Netzwerkarchitektur und Isolierung

Segmentierung: separate VPC/VNet für prod/stage/dev. Innerhalb prod - Subnetze für Edge (LB/WAF), API, DB, Analytics, Admin-Services.
Politik „explizit erlaubt“: Deny-all zwischen Subnetzen, öffnen Sie nur die gewünschten Ports/Richtungen.
mTLS zwischen den Diensten, die Rotation der Zertifikate ist automatisiert.

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata:
name: default-deny namespace: prod spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata:
name: allow-api-to-db namespace: prod spec:
podSelector:
matchLabels: {app: db}
ingress:
- from:
- podSelector: {matchLabels: {app: api}}
ports: [{protocol: TCP, port: 5432}]

4) Identitäten und Zugang (PAM/JIT)

SSO + MFA für alle Personenzugänge.
RBAC&ABAC: Rollen auf Cloud-, Cluster-, Namespace- und Anwendungsebene.
PAM: Sprung/Bastion, JIT-Zugang (zeitlich begrenzt), Sitzungsaufnahme.
Break-glass: versiegelte Beläge mit Hardwareschlüssel, protokollierbare Ausgabe.
Regelmäßige Scans von „wer hat Zugang zu was“, Revue alle 30 Tage.

5) Geheimnisse und Schlüssel

Secret Vault (Vault/KMS/Secrets Manager), wir schließen Geheimnisse aus Git aus.
KMS/HSM für Master-Schlüssel; KEK/DEK, automatische Rotation.
TTL-Richtlinien: kurzlebige Token (OIDC/JWT), temporäre Konten für CI.
Verschlüsselung: im Ruhezustand (AES-256/GCM), im Flug (TLS 1. 2 +/mTLS), PII/Kartendatenspalten - mit separatem Schlüssel.

6) Supply chain и CI/CD hardening

Isolierung von Runner's für prod (self-hosted im privaten Netzwerk).
Signatur von Artefakten (Sigstore/cosign), Überprüfung der Signatur auf Deploy.
SBOM (CycloneDX/SPDX), SCA/VA auf jedem Commit und vor der Veröffentlichung.
„No tag latest“ -Richtlinien, nur immutable Tags.
4-Augen-Prinzip: obligatorische Code-Überprüfung und Änderung der Zulassung.
Infrastructure as Code: Terraform/Helm с policy-as-code (OPA/Conftest).

rego package iac. guardrails

deny[msg] {
input. resource. type == "storage_bucket"
input. resource. acl == "public-read"
msg:= sprintf("Public bucket forbidden: %s", [input. resource. name])
}

7) Container und Kubernetes

Minimale Image-Basis (distroless), rootless, read-only FS, drop CAPs.
Zugriffskontrolle: Verbot von privileged, hostPath, hostNetwork.
Pod Security Standards: baseline/restricted для prod ns.
ImagePolicyWebhook: Überspringt nur signierte Images.
Laufzeitrichtlinien (Falco/eBPF): Warnungen für abnormale Syscalls.
Quota/LimitRange: Schutz der Knoten vor „lauten Nachbarn“.

8) API Perimeter: WAF, Rate Limits, Bot/DDoS

Gateway API: Authentifizierung (OAuth2/JWT/HMAC), Normalisierung, mTLS, Schema-Validierung.
WAF: Grundregeln + Custom für Geschäftsmetriken.
Rate limits: global/über IP/nach Kundenschlüssel; „Token“ und Burst.

nginx limit_req_zone $binary_remote_addr zone=api:20m rate=10r/s;

server {
location /api/ {
limit_req zone=api burst=30 nodelay;
proxy_pass http://api_backend;
}
}

Bot-Management: Verhaltenssignale, Gerät Fingerprint, Herausforderung.
DDoS: CDN/Edge-Scrubbing, Autoscaling, „Dark-Launch“ für Hot-Fiches.

9) Konfigurationsrichtlinien und sichere Ausfälle

Feature Flags/Kill-Switches zum schnellen Abschalten von Risikofunktionen.
Config-as-Code mit Schemavalidierung, canary/blue-green für Config.
Time-to-Revoke als KPI beim Rückruf von Configs/Keys.

10) Daten und Privatsphäre

Die Klassifikation: die PII/Finanzen die Hohlwege/Fernmessungen.
Minimierung: Speichern Sie nur das, was Sie benötigen, Anonymisierung/Pseudonymisierung.
Backups: separates Konto/Projekt, Verschlüsselung, regelmäßige DR-Proben.
Die Regeln der Ausgabe: same-method, velocity-limits, risk-scoring, 4-eyes.
Legal Hold/retention: Aufbewahrungspläne, kontrollierte Entsorgung.

11) Beobachtbarkeit, Warnungen und Reaktion

Triade: Protokolle (keine Geheimnisse), Metriken (SLO/SLA), Traces (W3C).
Sicherheitssignale: Erfolg/Misserfolg von Eingaben, Eskalation von Privilegien, Änderung von Geheimnissen, Verkehrsabweichungen.
SIEM + SOAR: Korrelation und halbautomatische Playbooks.
Playbooks der Vorfälle: DDoS, durchgesickerte Geheimnisse, kompromittierte Runner'a, Rollback der Veröffentlichung, „Einfrieren“ von Zahlungen.
MTTD/MTTR als Hauptmetriken der Agilität.

12) Änderungs- und Freigabemanagement

Change Advisory Board (leicht) für hochriskante Änderungen.
Pre-prod gates: Tests, Sicherheit, perf, DB-Migrationen.
Canary/Blue-Green/Shadow Deploys, automatische Rollback durch SLO.
Verbot direkter Bearbeitungen in der Produktion: Änderungen nur über Pipeline.

13) Schwachstellen und Patches

Patch-Richtlinie: kritisch - ASAP; hoch - innerhalb von N Tagen.
Erneutes Scannen nach dem Fix; CVE-Gewichtung nach Belichtung.
Chaos-Sicherheit: Regelmäßige Table-Top-Übungen und Red-Team-Angriffe in hervorgehobenen Fenstern.

14) Compliance und Audit

Kontrollrahmen: PCI DSS (Zahlungen), SOC 2, ISO 27001.
Artefakte: Kontrollmatrix, Änderungsprotokolle, Scanberichte, DR-Testergebnisse, Access-Review.
Kontinuierliche Verfügbarkeit: „evidence as code“ - Artefakte werden automatisch aus Pipelines und Systemen gesammelt.

15) Wirtschaftlichkeit und Zuverlässigkeit

Guardrails nach Wert: Kontingente, Budgets, Alerts, automatische Abschaltung ungenutzter Ressourcen.
Kapazität: SLO-orientierte Planung, Belastungstests, „Chaostage“.
Wiederherstellungsprioritäten: RTO/RPO nach Diensten, Abhängigkeitskarte.

16) Anti-Muster

V.env-Geheimnisse in Git, allgemeiner „Admin“ für alle, „direkte SSH in Prod“, manuelle Fixierungen in Containern, „neueste“ Tags, ein gemeinsamer Cluster für alles, öffentliche Baquets, CI-Runner mit Outbound-Internet im Prod-Netzwerk, Protokolle mit PII, kein Kill-Switch für „heiße“ Fiches.

17) Schnellstart-Checkliste (90 Tage)

0-30 Tage

Aktivieren Sie MFA/SSO, Revue Zugriffe; deny-all Netzwerkrichtlinien; Secrets Manager/KMS; Verbot von privilegierten K8s; WAF/Rate-Limit aktivieren; Basis-Eingangs-/Eskalationsalerts.

31-60 Tage

Bildsignatur + ImagePolicy; SBOM + SCA в CI; canary/rollback; Korrelations-SIEM; IR-Playbooks; JIT/PAM; Backup mit DR-Test.

61-90 Tage

OPA-guardrails für IaC; eBPF/Falco; Bot-Management; periodic access-review; Chaos-Sicherheitsübung; Prüfung von Config und Cost-Guardrails.

18) Reifegradkennzahlen

Zugriffe:% der Konten mit MFA, Durchschnittsalter der Token, Widerrufszeit.
Pipeline:% der signierten Bilder/SBOM, SAST/DAST-Beschichtung.
Plattform: Anteil der Pod's mit read-only FS, PSS-restricted, NetworkPolicy-Abdeckung.
Perimeter:% API mit Rate-Limit/WAF-Regeln, durchschnittliche Reaktion auf DDoS.
IR: MTTD/MTTR, „table-top“ Frequenz, Prozentsatz der erfolgreichen DR-Proben.
Compliance: Anteil der Kontrollen mit automatischem Nachweis.

19) Anhang: Richtlinienvorlagen

AWS SCP (Verbot von öffentlichen Baketten)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyPublicS3",
"Effect": "Deny",
"Action": ["s3:PutBucketAcl","s3:PutBucketPolicy"],
"Resource": "",
"Condition": {"StringEquals": {"s3:x-amz-acl": "public-read"}}
}]
}

Kubernetes PodSecurity (namespace-label)

yaml apiVersion: v1 kind: Namespace metadata:
name: prod labels:
pod-security. kubernetes. io/enforce: restricted pod-security. kubernetes. io/audit: restricted

OPA für Container (Verbot privilegiert)

rego package k8s. admission deny[msg] {
input. request. object. spec. containers[_].securityContext. privileged == true msg:= "Privileged containers are not allowed in prod"
}

20) Schlussfolgerung

Die Stärkung der Prod-Umgebung ist ein kontinuierlicher Prozess. Priorisieren Sie Maßnahmen mit maximaler Risikominderung: Zugriffe und Geheimnisse, Netzwerkisolierung, Artefaktsignatur und Pipelinekontrolle, API-Perimeterschutz, Beobachtbarkeit und Änderungsdisziplin. Bauen Sie den Rest iterativ auf, indem Sie Reifegradmetriken und Kontrollökonomie erfassen.