Sicherheit des Ökosystems

(Abschnitt: Ökosystem und Netzwerk)

1) Ziele und Grundsätze

Ziel ist es, die Vertraulichkeit, Integrität und Verfügbarkeit (CIA) von Diensten und Daten bei der Skalierung des Ökosystems und der Entwicklung von Protokollen zu gewährleisten.

• Zero-Trust by Design: Misstrauen Sie Netzwerken/Hosts, überprüfen Sie jede Aktion nach Kontext.
• Least Privilege (PoLP) und Need-to-know: Der Zugang ist minimal und messbar.
• Cryptographic assurance: Unterschriften/Bescheinigungen/Anker statt „default trust“.
• Observability by default: Sicherheitssignale werden in Protokolle eingebaut.
• Defense-in-Depth: Mehrschichtige Verteidigung (identichnost→set→dannyye→vypusk)
• Secure-by-default: Standardmäßig „geschlossen“, explizite Allow-Blätter.

2) Bedrohungsmodell (High-Level)

Netzwerk und Perimeter: DoS/L7-Floods, BGP/Anycast Missbrauch, MITM, DNS-Ersatz.
Identitäten und Schlüssel: Schlüsselkompromittierung, anfällige Token, Wiederholung von Signaturen.
Daten: PII-Exfiltration, Telemetrie-Leak, Metadaten-Manipulation.
Supply Chain: schädliche Abhängigkeiten/Bilder, Ersetzung von Artefakten, anfällige SDKs.
Protokolle/Brücken: Rerags, gefälschte Prufs, DA-Delays, Replay von Cross-Chain-Nachrichten.
Interne Risiken: Konfigfehler, Überrechte, schwache Deprecate-Prozesse.

3) Identitäten und Vertrauen

Identitäten: 'org _ id', 'peer _ id', Servicekonten, Benutzer.
Authentifizierung: mTLS (X.509), OAuth2/OIDC (kurzlebige JWTs, DPoP/PoP), WebAuthn für Menschen.
Autorisierung: Mehrstufiger RBAC/ABAC + policy-as-code (OPA/Rego).
Aushandlung von Fähigkeiten (Capability Negotiation) beim Händeschütteln: Ankündigung von Versionen, QoS, Limits und gültigen Domains.

Richtlinien (YAML)

yaml authz:
roles:
operator. p0: [payouts:write, events:subscribe, bridge:finalize]
reader. api: [rpc:read, catalog:read]
abac:
- when: {org_tier: "gold", region: "eu"}
allow: [qos:P0, data_class:P1]
tokens:
ttl_s: 900 rotation: "7d"

4) Netzsicherheit und Transport

Шлюзы/edge: WAF, L7-rate-limit, circuit-breaker, outlier-ejection.
Verkehrsverschlüsselung: TLS1. 3/mTLS, PFS, strenge Ciphers, QUIC/HTTP/3.
Isolation: Segmentierung von Umgebungen (prod/stage/dev), private Netze, egress-control, eBPF-Firewall.
P2P: Nachrichtensignaturen, Anti-Replay-Fenster, Pearl Control (allow/deny), Gossip Limits.

Beispiel für Netzwerkregeln

yaml network:
ingress:
allow: ["443/tcp","443/udp"]     # HTTPS/HTTP3 deny: [""]
egress:
allow_domains: [".trusted. psp",".oracle","crl. ocsp."]
waf:
block: ["sql-injection","xss","proto-smuggling"]
dos:
rps_per_ip: 200 burst: 400

5) Datenschutz

Datenklassen: P0 (Zahlung/Schlüssel), P1 (operativ), P2 (Log/Diagnose).
Verschlüsselung: at-rest (AES-GCM/ChaCha20-Poly1305), Schlüssel per-region/tenant, HSM/KMS, envelope-Verschlüsselung.
Tokenisierung und Pseudonymisierung von PII; Verbot von PII in Telemetrie/Labels.
Wohnsitz: regionale Volt und Objektlager, weiße Listen der Exporte.
Integrität: Hash-Adressierung von Artefakten, Merklisierung von Protokollen.

Verzeichnis der Aufbewahrungsrichtlinien (SQL)

sql
CREATE TABLE data_policies(
data_class TEXT, region TEXT, residency TEXT, kms_key TEXT, retention_days INT,
pii BOOLEAN, export_whitelist TEXT[]
);

6) Verwaltung von Geheimnissen und Schlüsseln

Generierung im HSM/KMS, Rotation nach Zeitplan und Event (Kompromittierung/Entlassung).
Trennung von Autorität (SoD) und M-of-N für kritische Operationen.
Geheimnisse nur im Secret Manager (nicht in Umgebungsvariablen/Repositories).
Schlüsselpinning für Service-übergreifende mTLS, OCSP-Stapeln/CRL.

Schlüsselrichtlinie

yaml keys:
rotation_days: 30 pinning: true revoke_on:
- "suspicious_use"
- "employee_exit"
audit_required: ["signing_keys","bridge_keys"]

7) Sichere Lieferkette (SLSA-Ansatz)

Provenance: Artefakt-Signaturen (sigstore/cosign), SBOM, Baugruppenbescheinigungen.
Baugruppenisolierung: hermetische Gebäude, Reproduzierbarkeit, Scan-Abhängigkeiten (SCA).
Veröffentlichungsrichtlinien: canary/blue-green, SLO-Gates, Kill-Switch, Hash-Rollbacks.
SDK/Client: CSP/Referrer-Policy, Integritätsattribute, Anti-Tamper.

yaml supply_chain:
require_sbom: true attestations: ["build","test","scan"]
deploy:
strategy: "canary"
gates: { error_rate_pct: 0. 4, tti_p95_ms: 2500 }

8) Zugriffe und Privilegien

RBAC/ABAC: Rechte nach Rollen/Attributen, temporäre Eskalationen (JIT).
Dienste: Abgrenzung Lesen/Schreiben/Admin, Verbot von Wildcard-Rechten.
Bediener: break-glass Zugang durch Multifaktor, mit Session-Aufzeichnung.
Audit: unveränderliche Protokolle (nur Append), Korrelation 'request _ id/trace _ id'.

Register für Rollen/Rechte (SQL)

sql
CREATE TABLE roles(name TEXT PRIMARY KEY, description TEXT);
CREATE TABLE permissions(role TEXT, resource TEXT, action TEXT, PRIMARY KEY(role,resource,action));

9) Beobachtbarkeit, SLI/SLO und Sicherheitssignale

• AuthN/AuthZ Success%, Anomalous Deny%;
• Key/Cert Drift (zum Ablauf/Nichtübereinstimmung);
• Integrity Violations (Signaturen, CSP);
• Abuse Signals: rate-limit hits, DoS/scan events;
• Data Residency Violations;
• Error Budget Burn по P0.

• Auth p95 ≤ 200 мс, Success ≥ 99. 95%;
• Signierte Ereignisse ≥ 99. 9%;
• CSP-Verstöße ≤ 0. 05% Treffer;
• Wohnsitzverletzungen = 0.

Дашборды: Security Posture, Keys & Certs, Supply Chain, Abuse/DoS, Residency & DLP.

10) Incident Response (IR) und SOAR

Bereitschaft: runbook 'und auf P0/P1, verantwortlich 24 × 7, Kommunikationskanäle.
Detektion: Signaturen/Verhaltensregeln, Korrelation in SIEM, SOAR-Automatisierung.
Abschreckung: Token/Schlüssel-Block, Deny-Routenliste, Quarantine-Spitzen.
Eradikation/Wiederherstellung: Rotationen, Patches, Reassembly, Wiederherstellung von Snapshots.
Post-Mortem: innerhalb von 72 Stunden, Action-Aitems, Aktualisierung von Richtlinien/Tests.

SOAR-Regeln (Beispiel)

yaml soar:
playbooks:
key_compromise:
trigger: ["anomalous_sign","suspicious_kid"]
actions: ["revoke_key","rotate","notify_owners","enable_strict_mode"]

11) Compliance und Wohnsitz

Regulatorische Anforderungen: Datenspeicherung/Löschung (DSR), Berichterstattung, RNG/Kryptographie-Zertifizierung.
Wohnsitz: per-region Schlüssel und Volt, Export durch weiße Listen.
Prozesse: regelmäßige Audits, Änderungsprotokoll, Timelock auf kritische Richtlinien.

yaml residency:
eu: { pii: "tokenized", export: ["anonymized_metrics"] }
uk: { pii: "tokenized", export: [] }
compliance:
dsr:
erase_sla_days: 30 export_sla_days: 30

12) DR/BCP und Nachhaltigkeit

RPO/RTO-Ziele: P0-Dienste - RPO ≤ 5 min, RTO ≤ 15 min.
Geo-Replikation: Asset-Liability/Asset-Asset, periodische Recovery-Tests.
Isolierter Modus: finalized-only, cache-only, Begrenzung der „teuren“ Operationen.
Redundante Kanäle: unabhängige IX/Provider, verschlüsselte interregionale Tunnel.

DR-Richtlinie

yaml dr:
rpo_min: 5 rto_min: 15 exercises: ["quarterly-failover","annual-blackhole"]

13) Sicherheitsmetriken und Tests

Chaos-security: тесты MITM/DNS-poison/packet-loss/latency.
Red/Blue Team: Phishing-Szenarien, Token-Hijacking, Supply-Chain-Injektionen.
Tabletop-Drills: Modellierung von Entscheidungsfindung und Kommunikation.
Autotests: SAST/DAST/IAST, Fuzzing-Protokolle, Policy-Linter.

14) Playbooks der Vorfälle

A. Kompromittierung des Teilnehmerschlüssels

1. 'revoke _ key' → 'rotate' → die vertrauenswürdige Registrierung aktualisieren;

2. strict-mode von Signaturen aktivieren; 3) Resign kritische Batchi; 4) Bericht an die Partner.

B. Verletzung des Wohnsitzes

1. Sofortige Exporteinheit; 2) Redaktion/Entfernung; 3) Benachrichtigen Sie den DSB/Compliance; 4) Aktualisieren Sie die Tests.

C. Supply-chain Injektion

1. Rollback nach Hash, Kill-Switch; 2) revalidize SBOM/Bescheinigungen; 3) Rotation von CI-Token; 4) Post-Mortem.

D. Massive DoS/L7-Flut

1. Aktivierung von verstärkten Rate Limits/WAF; 2) Anycast-Dreschen; 3) Priorisierung von P0; 4) Kommunikation mit den Anbietern.

E. Drift Politik/Verträge

1. Deny für inkompatible Schemas aktivieren; 2) Freigabe der Adapter; 3) Aktualisieren Sie die Linter/Register.

15) Checkliste Umsetzung (nach Schritt)

1. Geben Sie das Identitätsmodell (org/peer/service/user) und mTLS + OIDC ein.
2. Beschreiben Sie Policy-as-Code (RBAC/ABAC), PoLP und JIT-Eskalationen.
3. Verschlüsseln Sie Daten „unterwegs“ und „in Ruhe“, tokenisieren Sie PII, konfigurieren Sie die Residenz.
4. Aktivieren Sie den Supply-Chain-Schutz: Artefakt-Signaturen, SBOM, Bescheinigungen, Canary + Kill-Switch.
5. Konfigurieren Sie die WAF/Rate-Limits/DoS-Wachen und die Egress-Steuerung.
6. Heben Sie SIEM/SOAR an, beschreiben Sie SLI/SLO, Alerts und Security Dashboards.
7. Regeln Sie Schlüssel/Serte-Rotationen und Break-Glass-Zugänge.
8. Üben Sie DR/BCP und isolierte Modi, führen Sie Übungen durch.
9. Organisieren Sie Audits/Logging und regelmäßige Post-Mortems.
10. Überprüfen Sie Richtlinien vierteljährlich, automatisieren Sie Überprüfungen.

16) Glossar

Zero-Trust ist ein Modell, bei dem jede Aktion ortsunabhängig überprüft wird.
PoLP ist das Prinzip der minimal notwendigen Rechte.
Policy-as-Code - Verwalten Sie den Zugriff/Regeln durch deklarative Richtlinien.
SLSA - Sicherheitsstufen der Software-Lieferkette.
RPO/RTO - Datenverlust/Recovery Time Objectives.
DPoP/PoP - Binden eines Tokens an einen bestimmten TLS-Kanal/Client.
Strict-mode ist ein Modus, der nicht konforme Schemas/Signaturen verbietet.

Fazit: Die Sicherheit des Ökosystems ist keine „Firewall und TLS“, sondern eine Verschmelzung von kryptografischem Vertrauen, strengen Zugriffsrichtlinien, Beobachtbarkeit und Betriebsdisziplin. Nach Zero-Trust, PoLP, Supply-Chain-Kontrollen und messbaren SLOs wird Sicherheit zu einer überschaubaren Engineering-Praxis, die gegen Störungen, Angriffe und regulatorische Veränderungen resistent ist.