Stärkung des Prod-Umfelds und Audit

1) Ziele und Verantwortungsbereich

• Minimierung des Angriffsbereichs und des Blast Radius;
• Kanäle, Rechnungen, Geheimnisse und Artefakte der Versorgung zu schützen;
• Erkennung und Reaktion auf Vorfälle schneller als MTTR-Ziele;
• Bestätigung der Einhaltung der Vorschriften (DSGVO/PCI DSS/lokale Vorschriften);
• Prüfbarkeit (Auditability) aller kritischen Aktivitäten.

Schlüsselprinzipien: Zero Trust, Least Privilege, Segmentation, Everything-as-Code, Security-by-Default.

2) Netzwerkperimeter und Segmentierung

Segmente: Edge (WAF, Bot Management, DDoS), DMZ (Gateway), App (Microservices), Data (DB/Caches), Backoffice/Ops (CI/CD, Observability).
L4/L7-Richtlinien: deny-by-default, explizite allow für Dienste/Nijmspaces/Ports.
mTLS innerhalb des Clusters; TLS 1. 2 + auf Perimeter, HSTS, sichere Chiffren.
Eingabefilter: WAF (OWASP Top-10), Anti-Bot, Rate Limits, Geo/ASN-Blöcke, CAPTCHA auf dem Risikopfad.
DDoS-Schutz: always-on + auto-mitigation, separate Profile für APIs/statische Inhalte.
Egress-Control: Nur notwendige externe Hosts für Anbieter (PSP/KYC/Spiele).

3) Identitäten, Zugang und Privilegien (IAM/PAM)

SSO (OIDC/SAML) + MFA für Menschen; OIDC-Token/Workload Identity für Dienste.
RBAC/ABAC: Rollen mit den minimal erforderlichen Berechtigungen; „break-glass“ Zugang unter Audit und TTL.
PAM: Schreiben von privilegierten Sitzungen auf Anfrage, vollständige Aufzeichnung und Protokollierung.
CIEM (Clouds): Suche nach übermäßigen Rechten und toten Rollen, Auto-Remediation.
Zugriff auf Prod-Daten: nur über genehmigte Jump/Proxy, mit PII-Maskierung.

4) Geheimnisse und Kryptographie

KMS/HSM: Schlüsselspeicherung, Envelope-Verschlüsselung, Rotation mit Benachrichtigungen.
Secret Manager: kurzlebige Credits, Geheimnisse aus Git/Logs ausschließen.
Signaturen: Artefakte (Cosign), Webhooks (HMAC), Service-Token.
PAN/PII-Felder: Tokenisierung/Verschlüsselung at-rest; Maskierung in Logs und Previews.
Rotations-Richtlinien: Schlüssel/Zertifikate/Passwörter - reglementiert und durchgesetzt.

5) Container und Kubernetes (CWPP/KSPM)

Grundlegende Bilder: minimal, Scan von Schwachstellen auf CI; rootless wo möglich.
Admission-Richtlinien (OPA/Gatekeeper/Kyverno): verbieten': neueste', 'privilegiert', hostPath; Wir fordern die Unterschrift der Bilder.
NetworkPolicies: Service-übergreifende Kommunikation nur bei Bedarf.
PodSecurity: begrenzte Kapazitäten, nur lesen FS, seccomp, AppArmor.
Geheimnisse: aus dem Secret Store CSI (KMS); kein einziges Plain-Geheimnis in den Manifesten.
Laufzeitschutz: Verhaltensregeln (eBPF), Warnungen vor Anomalien.

rego package k8sadmission deny[msg] {
input. request. kind. kind == "Pod"
some c image:= input. request. object. spec. containers[c].image not startswith(image, "registry. company. com/signed/")
msg:= sprintf("Image must be signed and come from trusted registry: %v", [image])
}

6) Versorgungskette: Vertrauen Sie, aber überprüfen Sie

SBOM für jedes Bild; Speichern und Verknüpfen mit der Freigabe.
Bild-/Manifest-Signaturen, Überprüfung im Admission-Controller.
SLSA-Bescheinigungen: Nachweisbare Herkunft von Artefakten.
Policy-as-Code: Conftest/OPA auf der Terraform/Helm/K8s vor dem Merge.
Verbot von „Last-Minute-Patching“ auf dem Produkt: Alle Änderungen erfolgen nur über die Pipeline.

7) Schwachstellen- und Patch-Management

SCA/SAST/DAST в CI; Sperrschwellen für kritisch/hoch.
Wöchentliche Update-Batches (Images, OS-Pakete, Bibliotheken) + Notfall ungeplant.
Durchgeführte Korrekturen → Tickets/Releases mit Bezug zu CVE/SBOM.
EASM: externe Überprüfung der Angriffsfläche (Subdomains, offene Ports, Zertifikate).
Regelmäßige Pen-Tests: mindestens einmal im Jahr + gezielt auf kritische Ströme (Payments/CUS).

8) Logs, Metriken, Traces und Speicherung von Audit-Artefakten

Standardisierte Logs (JSON) mit 'trace _ id', 'request _ id', user/tenant/geo (pseudonym), ohne PII/PAN.
Metriken: p50/p95/p99, Fehlerrate, Sättigung, DLQ, Retrai, Business KPI (Time-to-Wallet).
Tracing (OTel): Ende-zu-Ende für kritische Routen (Deposit/CUS/Output).
SIEM: Ereigniskorrelation (Authentifizierung, Rollenänderungen, Admin-Aktionen, WAF/Bot-Regeln).
SOAR: Auto-Reaktionen (Herdisolierung, Token-Rückruf, IP/ASN-Block, Release-Verbot).
Retention: Betriebsprotokolle - 30-90 Tage heiße Lagerung, Audit-Artefakte - länger, nach Richtlinien.

json
{
"ts":"2025-11-05T15:00:00Z",
"sev":"WARN",
"svc":"payments-api",
"route":"POST /v1/payments",
"trace_id":"2f9f...e1",
"user":"anon",
"tenant":"eu-casino-12",
"geo":"EU",
"event":"circuit_breaker_open",
"provider":"psp-1"
}

9) Anti-Bot, Betrug und defensive Szenarien

Bot-Management: Signaturen/Verhalten, Device-Fingerprint, dynamische Herausforderungen.
Rate limits/quotas: per-user/tenant/IP; Adaptiv bei Anomalien.
RASP-Sensoren an kritischen Endpunkten (Versuche, die Signatur von Webhooks zu umgehen, Uhrendrift, Re-Delivery).
Betrugssignale: Korrelation nach Kanälen (Logins, Zahlungen, KYC), Auto-Eskalationen.

10) Redundanz, DR und BCP

RTO/RPO-Ziele werden definiert und getestet (z. B. RTO ≤ 1 Stunde, RPO ≤ 5 Minuten für die Zahlungsdatenbank).
Backups: verschlüsselt, periodisch im Offline-Speicher; regelmäßige Restore-Tests.
Geo-Duplizierung: Aktiva-Passiva/Aktiva-Aktiva nach Region; DNS-Failover mit TTL-Kontrolle.
Verzeichnis kritischer Abhängigkeiten (PSP/KYC/Spiele-Aggregatoren) und Schaltpläne.

11) Vorfälle und Reaktion

Runbooks: für Anbieterverfall, Latenzwachstum, Token-Kompromittierung, DDoS.
On-Call: 24/7, Rotation und Blast-Pages; gemeinsame „War-Room“ -Praxis.
Kommunikation: Meldungsvorlagen für Kunden/Partner und Aufsichtsbehörden.
Post-mortem (blameless): Aktionen zur Vermeidung von Wiederholungen, Aktualisierung von Richtlinien/Playbooks.

12) Compliance und Datenschutz

DSGVO: Datenminimierung, Zustimmungsregister, Recht auf Löschung/Portierung; DPIA für neue Anbieter.
PCI DSS: Tokenisierung/isolierte PAN-Zonen, Netzwerksegmente, strenge Zugriffsprotokolle.
Lokale Anforderungen (Jurisdiktionen der Märkte): Datenspeicherung in der Region, Reporting, Update-Fenster.
Data Lineage: wo und wie PII/PAN fließen; Schaltpläne und DPIA im DevPortal.

13) Audit: Typen, Artefakte und Zyklus

• Intern (vierteljährlich): Einhaltung von Richtlinien, Kontrolle von Änderungen, Zugriffen, Geheimnissen, Protokollen, Piplines.
• Extern (jährlich/je nach Anforderung): PCI/GDPR/lokale Regulierungsbehörden, Pen-Tests, SOC-Berichte der Anbieter.

• Sicherheitsrichtlinien, IAM-Rollenmatrix, Ausschlussliste mit Ablaufdatum.
• Infrastrukturänderungsprotokolle (IaC), CI/CD-Berichte (SBOM, Signaturen, Tests).
• Anbieterregister (PSP/KYC/Spiele), DPIA/Vendor-Risk-Assessments, Verträge und SLAs.
• Prod Access Logs, Secret Rotations Ergebnisse, SIEM/SOAR Berichte.
• DR/BCP-Pläne und Protokolle der neuesten Restore-Tests.

• „Evidence-first“: Jede Praxis ist ein überprüfbares Artefakt.
• "No humans in prod': höchstens über Pipelines und genehmigte Anträge; Alle Sitzungen sind unter Protokoll.
• „Trace everything“: Korrelieren Sie Änderungen mit Vorfällen/Metriken.

14) Guardrails-as-Code: Beispiele

rego package terraform. deny deny[msg] {
input. resource. type == "aws_db_instance"
input. resource. publicly_accessible == true msg:= "RDS must not be public"
}

AdmissionPolicy (K8s): Sicherheitsbeschriftungen und Ressourcenlimits erforderlich

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata:
name: enforce-security-labels-and-limits spec:
rules:
- name: require-labels match: {resources: {kinds: ["Deployment","StatefulSet"]}}
validate:
message: "security labels required"
pattern:
metadata:
labels:
security. tier: "?"
data. classification: "?"
- name: require-limits match: {resources: {kinds: ["Deployment","StatefulSet"]}}
validate:
message: "resources limits/requests required"
pattern:
spec:
template:
spec:
containers:
- resources:
limits:
cpu: "?"
memory: "?"
requests:
cpu: "?"
memory: "?"

15) Checkliste für die tägliche Prod-Umwelt-Hygiene

• WAF/Bot-Richtlinien aktiv, Signaturen aktualisiert; Anti-DDoS im Always-on-Modus.
• Admission-Controller im Cluster im Status enforce, nicht audit.
• Alle Prod-Images sind signiert; SBOM ist verfügbar und an die Veröffentlichung gebunden.
• Kritische/hohe Schwachstellen - fehlen oder werden durch Ausnahmen mit Datum behoben.
• Rotation der Geheimnisse/Zertifikate - nach Zeitplan, keine Verzögerungen.
• SIEM korreliert IAM/Releases Entry/Change Events; SOAR-Playbooks werden getestet.
• Backups bestanden, Restore-Test im Zeitplan; Der DR-Plan ist gültig.
• Zugang zum Prod - nur über SSO + MFA/PAM; Alle Sitzungen werden aufgezeichnet.
• "No PII in logs' - validiert durch Scanner; Maskierung aktiviert.
• Release Gates und Beobachtbarkeit aktualisiert mit „as-code“.

16) Reifegradmodell (kurz)

1. Basis sind manuelle Änderungen, einheitlicher Umfang, Teilüberwachung.
2. Fortgeschritten - Segmentierung, IAM/RBAC, signierte Artefakte, WAF/DDoS, SIEM, reguläre Patches.
3. Expert - Zero Trust, guardrails-as-code, SLSA-Zertifizierungen, Laufzeitschutz, SOAR-Automatisierung, „no humans in prod“, kontinuierliches Audit.

17) Umsetzungsfahrplan

M0-M1 (MVP): Netzwerk-Segmentierung, WAF/DDoS, SSO + MFA, KMS, grundlegende Admission-Richtlinien, standardisierte Protokolle/Metriken/Trails, SIEM.
M2-M3: Bildsignaturen und Validierung admission, SBOM, Conftest/OPA auf IaC, PAM, Rotationsplan, regelmäßige Patches, erste DR-Tests.
M4-M6: SOAR-Playbooks, eBPF/Laufzeitdetail, EASM, Compliance-Paket (PCI/GDPR), vollständige Sammlung von Audit-Artefakten, Ring-DR nach Region.
M6 +: Zero-Trust-Netzwerk (mTLS überall), CIEM, automatisierte Audit-Kontrollberichte, permanente „Purple-Team“ -Tests.

Zusammenfassung

Ein starker Prod ist kein Satz von „eisernen“ Regeln, sondern ein System: Segmentierung, strenge Identitäten und Geheimnisse, sichere Versorgung, überschaubare Container, Beobachtbarkeit und automatisierte Reaktion. Hinzu kommt die Überprüfbarkeit (Audit-Artefakte, SBOMs/Signaturen, Logs) und die Prod-Umgebung wird vorhersehbar, überschaubar und bereit für externe Prüfungen - ohne Kompromisse bei der Geschwindigkeit von Releases und Business SLOs.