Sicherheitsschichten in der Infrastruktur

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Sicherheit ist ein Schichtsystem: Jede Schicht hält Angriffe zurück und erkennt sie, wenn die vorherige fehlgeschlagen ist. Für iGaming ist dies besonders kritisch: Zahlungsströme, PIIs, Affiliate-Integrationen und Spitzenlasten. Unten ist ein Defense-in-Depth-Framework, das Netzwerk, Identität, Anwendungen, Daten und betriebliche Prozesse in einem verwalteten Programm verbindet.

1) Bedrohungsmodell und Grundprinzipien

Bedrohungsmodellierung: STRIDE/Kill-Kette für Schlüsselströme (Login, Einzahlung, Wette, Auszahlung, Backophis).
Zero Trust: „nicht standardmäßig vertrauen“, Mindestrechte, Überprüfung auf jedem Hop.
Least Privilege & Segregation of Duties: Rollen sind atomar, sensible Operationen sind getrennt.
Secure by Default: geschlossene Ports, Deny-All-Richtlinien, sichere Standardwerte.
Auditability: Alle Zugriffe/Änderungen erfolgen in einem zentralen Audit.

2) Netzwerk und Perimeter

Das Ziel: Seitwärtsbewegungen zu verhindern und das Risiko isolierend zu managen.

Segmentierung/Zonen: Edge (CDN/WAF) → API → Dienste → Daten (DB/KMS) → Admin/Backophis.
VPC/VNet Isolierung + Subnetze für öffentliche/private Dienste; NAT/egress-control (inkl. egress-allowlist zu PSPs/Spieleanbietern).
mTLS überall (mesh/Ingress), TLS 1. 2 +/HSTS/klare Kryptokonfiguration.
WAF/Bot-Management/DDoS am Perimeter; Anti-Scoring für Credential Stuffing.
DNS-Sicherheit: Split-Horizon, DNSSEC, Fehlertoleranz, Cache-Pinning für kritische Domains.

yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: { name: api-deny-all, namespace: prod }
spec:
podSelector: { matchLabels: { app: api } }
policyTypes: [Ingress, Egress]
ingress: [] # deny-all egress:
- to:
- namespaceSelector: { matchLabels: { name: prod } }
podSelector: { matchLabels: { app: payments } }
ports: [{ protocol: TCP, port: 8080 }]

3) Identität und Zugang (IAM/PAM)

Das Ziel: Jeder Zugang ist begründet, eingeschränkt und transparent auditiert.

SSO + MFA für Mensch und Maschine; Hardwareschlüssel für privilegierte Konten.
RBAC/ABAC für Cloud/K8s/Backophis; SCIM - automatisches Ein-/Ausschalten.
JIT-Zugang (temporär), Break-Glass mit verbessertem Audit.
Service Accounts mit kurzlebigen Token (OIDC/JWT), Prüfung von Kundengeheimnissen.
Bastion/Command Mirroring: Zugriff auf Prod-DB/Knoten - nur über Bastion und schreibgeschützte Sitzungen.

4) Geheimnisse und Schlüssel

Das Ziel: Lecks zu vermeiden und einen überschaubaren Lebenszyklus der Schlüssel zu gewährleisten.

KMS/HSM (Master Key), regelmäßige Rotation; Aufteilung der Schlüssel nach Zonen/Zielen.
Secret Storage (Vault/Cloud KMS Secrets) mit Dynamic-Creds und Lease.

• Bei Rest (DB/Bakets/Snap-Shots) mit Envelope-Verschlüsselung.
• In transit (TLS/mTLS).
• Tokenization für Zahlungsdaten; PAN-Safe-Threads und 3-Domain-Sicherheit (PCI DSS).

hcl path "kv/prod/payments/" {
capabilities = ["read","list"]
}
path "database/creds/readonly" {
capabilities = ["read"]
}

5) Containersicherheit und Kubernetes

Das Ziel: die Angriffsfläche auf der Rantime-Ebene zu minimieren.

Images: minimale Basis, keine Compiler/Shells; Signaturen (cosign) und SBOM.
Admission-Control (OPA/Gatekeeper/Kyverno): Verbot „: neueste“, „privilegiert“, „hostPath“, „root“.
Runtime-политики: Seccomp/AppArmor, `readOnlyRootFilesystem`, `drop ALL` capabilities + allow-list.
Secrets als volume/env vom secrets manager; ohne Bake-In im Bild.
PodSecurity (или Pod Security Admission): enforce restricted.
Register: privat, mit Schwachstellenprüfung (SAST/DAST/CSA).

yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sAllowedRepos metadata: { name: only-internal-registry }
spec:
repos: ["registry.internal.local/"]

6) Supply-chain и CI/CD

Das Ziel: Artefakten vom Commit bis zur Produktion vertrauen.

Branch-policies: Code-Reviews, geschützte Zweige, obligatorische Überprüfungen.
Signatur von Artefakten und Provenance (SLSA/COSIGN), unveränderliche Tags (immutable images).
SBOM (CycloneDX/SPDX), Dependabot/Renovate und Pinning Abhängigkeiten.
CI-Isolation: ephemere Läufer, Geheimnisse nur in geschützten Jobs, no-plaintext.
CD-gejty: quality/SAST/лицензии/вендор-политики; Promotion nur über GitOps.

7) Anwendungssicherheit (API/Web/Mobile)

Das Ziel: logische und technische Angriffe verhindern.

AuthN/AuthZ: OAuth2/OIDC/JWT; kurze TTL, Schlüsselrotation, Audience/issuer Überprüfung.
Eingangssicherheit: Validierung/Normalisierung, Schutz vor Injektionen, Vorlagen mit Parametern.
CSP/HSTS/XFO/XSS-Protection, striktes CORS, Begrenzung der herunterladbaren MIME/Größen.
Rate limit/quotas, idempotency-keys für Zahlungen/Auszahlungen.
Ficheflagi: schneller Kill-Switch für gefährliche Funktionen.

nginx add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:;" always;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;

8) Daten, PII und Compliance (inkl. PCI)

Das Ziel: Mindestgebühr, Mindestzugang, maximale Transparenz.

Data-zones/классы: `public/internal/confidential/pii/pci`. Tags in Depots und Protokollen.
PII-Minimierung: Pseudonymisierung von 'player _ id', Tokenisierung von Zahlungsdetails.
Aufbewahrungsrichtlinien: heiß/kalt, WORM für Audit; automatische Entfernung durch TTL.
Zugriff: nur über vereinbarte Rollen und Attribute (Region/Ziel).
PCI-Segmentierung: isoliertes Segment, Zugriffsprotokolle, regelmäßige Scans/ASVs.

9) Randschicht: CDN/WAF/DDoS/Bot-Schutz

Das Ziel: Den „Müll“ bis zum Kern der Plattform herausfiltern.

CDN: Geoblöcke, Cache-Strategien, Layer-7-Schutz.
WAF: grundlegende Signaturen + benutzerdefinierte Regeln unter APIs (JSON-Schemas, Verbot nicht standardmäßiger Methoden).
Bots: Verhaltensanalyse, Device Fingerprint, Rate-Limit/Captcha bei Anomalien.
TLS/ALPN: Alte Chiffren ausschalten, OCSP-Stapeln aktivieren.

10) Überwachung, Telemetrie und SecOps

Das Ziel: Angriffe sehen und vor dem Vorfall reagieren.

Beobachtbarkeit: Metriken/Logs/Traces mit 'trace _ id' und Audit-Feldern.
SIEM/SOAR: Korrelation von Ereignissen (Authentifizierung, IAM-Änderungen, WAF-Auslösung, Zugriff auf Geheimnisse).
Erkennungsregeln: 401/403-Spitzen, Role-Escalation, Massenzahlungen, Geo-Anomalien.
Scan: SAST/DAST/IAST, CSPM/KSPM, regelmäßige Pene-Tests und Bug-Bounty.
Anti-Betrug: Transaktionen/Verhalten Scoring, Velocity-Filter, Sanktionslisten.

11) Zuverlässigkeit, Reserve und Geschäftskontinuität

Das Ziel: den Ausfall ohne Datenverlust und SLA überstehen.

Replikation und PITR für DB, häufige Snapshots mit Testwiederherstellung.
DR-Plan: RTO/RPO, Region-Failover-Szenarien, Schaltversuche.
Geheimnisse in DR: unabhängige KMS-Schlüssel/Replik, Notfall-Rotationsprozess.
Formale Hyden: Checklisten der Wiederherstellung und Spieltagsübungen.

12) Operative Prozesse und Kultur

Das Ziel: dass die Sicherheit „Standard“ ist.

Security by PR: Ein obligatorischer Security-Review für sensible Veränderungen.
Freigabebestimmungen: Nacht-/Spitzenfenster geschlossen; Vor-Flug-Checklisten.
Secure Runbooks: Anweisungen mit sicheren Parametern, Überwachung von Aktionen.
Training: Phishing-Simulationen, Incident-Training, Live-Tabletop-Sessions.

13) Checklisten (kurz)

Netzwerk und Perimeter

• Alle ingress für WAF/CDN; DDoS aktiviert
• mTLS zwischen Diensten; deny-all Netzwerkrichtlinien
• Egress-allowlist zu externen Anbietern

Identität

• SSO+MFA; JIT und Break-Glass mit Audit
• RBAC/ABAC, SCIM-Deaktivierung von Entlassungen
• Service Accounts mit Short-Token

K8s/Container

• Bildsignaturen + SBOM; Verbot „: neueste“
• Seccomp/AppArmor, read-only FS, drop caps
• Gatekeeper/Kyverno Politik und Deny-Listen

Geheimnisse/Schlüssel

• Vault/KMS, Rotationen, Schlüsseltrennung
• Verschlüsselung bei Rest/in Transit
• Tokenisierung für Zahlungen

CI/CD и supply-chain

• Ephemere Läufer; Geheimnisse nur in geschützten Jobs
• SAST/DAST/Lizenzen; Artefakt-Signaturen
• GitOps-Promotion, Qualitätstore

Daten/PII/PCI

• Datenklassifizierung und Tags in Depots
• Retention/WORM-Richtlinien; Zugriff nach Rolle
• PCI-Segmentisolation, ASV-Scans

SecOps

• SIEM/SOAR-Regeln, Warnungen vor Eskalationen
• Anti-Fraud und Velocity-Filter
• DR-Plan, RTO/RPO-Tests

14) Beispiele für „harte“ Politik

Kyverno: Verbot von privilegierten Containern

yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: { name: disallow-privileged }
spec:
rules:
- name: no-priv match: { resources: { kinds: ["Pod"] } }
validate:
message: "Privileged containers are not allowed"
pattern:
spec:
containers:
- securityContext:
privileged: "false"

OPA (Rego): Verbot von „hostNetwork“

rego package kubernetes.admission

violation[msg] {
input.request.kind.kind == "Pod"
input.request.object.spec.hostNetwork == true msg:= "hostNetwork is not allowed"
}

15) Anti-Muster

„Protect Perimeter“ ohne interne mTLS/Segmentation → seitliche Bewegung.
Geheimnisse in CI-env-Variablen, Hochladen in Protokolle.
Bilder': neueste', fehlende Unterschriften und SBOM.
Allow-All-Richtlinie im Cluster; gemeinsame nijmspaces für alles.
Verschlüsselung „auf Papier“ ohne echte Schlüsselrotation und Wiederherstellungstests.
Verlassen Sie sich auf WAF, anstatt Logik zu korrigieren und Daten zu validieren.
Keine DR-Übung/tabellarische Szenarien - Plan „verstaubt“.

16) Wie man anfängt (90-Tage-Plan)

1. Woche 1-2: Asset-/Dateninventar, Klassifizierung, Flusskarte.
2. Woche 3-4: Aktivieren Sie mTLS/deny-all Netzwerkrichtlinien, WAF/DDoS/Bot-Filter.
3. Woche 5-6: Vault/KMS, Schlüsselrotationen, Tokenisierung von Zahlungen.
4. Woche 7-8: Gatekeeper/Kyverno, Seccomp/AppArmor, Verbote „privilegiert “/„ hostPath“.
5. Woche 9-10: Bildunterschriften, SBOM, CI/CD-Tore, GitOps-Promotion.
6. Woche 11-12: SIEM/SOAR-Regeln, Eskalationsalerts, Anti-Betrug.
7. Woche 13: DR-Training, Runabucks und Compliance Status Update (PII/PCI).

Ergebnisse

Sicherheitsschichten sind eine Architektur von Lösungen, keine Reihe von „Ticks“. Verbinden Sie Netzwerksegmentierung und Zero Trust, rigoroses IAM, sichere Container/K8s, verwaltete Geheimnisse und Krypto, sichere Pipelines, Edge Defense und SecOps-Überwachbarkeit. Selbst bei Angriffen und Ausfällen behält die Plattform die Datenintegrität, die PII/PCI-Vertraulichkeit und die Verfügbarkeit wichtiger Threads - Einzahlungen, Wetten und Auszahlungen - zu Spitzenzeiten bei.