Welle 5 · Produktionsrealität

CommerceOne im echten Betrieb

Produktionsreife entsteht nicht durch ein einzelnes Werkzeug. CommerceOne verbindet messbare Zuverlässigkeitsziele, Telemetrie, sinnvolle Alarme, vorbereitete Reaktion, getestete Wiederherstellung und lernorientierte Nachbereitung zu einem geschlossenen Betriebszyklus.

Betriebszyklus

Codefluss vom Request bis zur Plattform

Der Code Explorer ist wie ein Stadtplan für einen Request. Jede Datei übernimmt eine klar begrenzte Aufgabe: Der Controller nimmt die Anfrage an, der Use Case koordiniert, das Aggregate schützt Regeln, Adapter sprechen Datenbank und Messaging an.

Alltagstaugliche Ablaufbeschreibung

Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.

HTTP Request
Controller
Command
Application Service
Domain Aggregate
Repository Port
JPA Adapter
PostgreSQL
Outbox Adapter
Kafka
Telemetrie.

Fachlicher Ablauf

Ein fachliches Ereignis informiert andere Bereiche darüber, dass sich etwas Relevantes geändert hat. Der sendende Bereich bleibt verantwortlich für seine Aussage; empfangende Bereiche entscheiden selbst, wie sie darauf reagieren.

Fachliches Ziel: Der Ablauf liefert ein fachlich eindeutiges und für Benutzer beziehungsweise Betrieb nachvollziehbares Ergebnis.
Verantwortung: Jeder beteiligte Bereich entscheidet nur innerhalb seiner eigenen fachlichen Zuständigkeit.
Sichtbares Ergebnis: Order, Inventory, Payment und Notification können unabhängig reagieren, ohne eng gekoppelte synchrone Aufrufketten.

Technischer Ablauf

Der Producer schreibt ein Event in ein Topic. Partitionierung bestimmt Reihenfolge und Parallelität, Consumer Groups verteilen Arbeit, Offsets dokumentieren den Verarbeitungsstand. Retry, Idempotenz und Dead Letter Queue schützen vor Doppelwirkung und dauerhaft fehlerhaften Nachrichten.

Daten und Schnittstellen: Daten werden an jeder Grenze validiert und nur über definierte APIs, Ports oder Events weitergegeben.
Fehlerbehandlung: Fehler werden dort behandelt, wo ausreichender Kontext und Verantwortung vorhanden sind; Wiederholungen müssen sicher und nachvollziehbar bleiben.
Technischer Nachweis: Geprüft werden Producer-Erfolg, Topic/Partition, Consumer Lag, Offset-Fortschritt, Retry-Zahl und DLQ-Einträge.

Zusammenspiel: Der fachliche Ablauf erklärt, warum etwas geschieht und welches Ergebnis zählt. Der technische Ablauf erklärt, wie dieses Ergebnis zuverlässig, sicher und beobachtbar umgesetzt wird.

Systemgrenze und Schutzgütersecurity

Das Threat Model betrachtet Browser, Identity Provider, Gateway, Order Service, Kafka, PostgreSQL, Plattform und Operatorzugriffe. Schutzgüter sind Bestellungen, Identitäten, Zahlungsreferenzen, Secrets, Auditdaten und Verfügbarkeit.

STRIDE auf CommerceOnesecurity

Risiko	Beispiel	Kontrolle
Spoofing	gefälschtes Token	OIDC-Prüfung, kurze Laufzeit
Tampering	verändertes Event	ACLs, Schema, Integritätsprüfung
Repudiation	Aktion wird bestritten	Audit-Events
Information Disclosure	PII in Logs	Redaction, Datenminimierung
Denial of Service	Checkout-Flut	Rate Limit, Backpressure
Elevation of Privilege	zu breite Rolle	Least Privilege

Abuse Casessecurity

Ein Benutzer storniert fremde Bestellungen.
Ein interner Dienst publiziert manipulierte Events.
Ein kompromittierter CI-Runner liest Produktions-Secrets.
Ein Angreifer erzeugt viele teure Checkout-Vorgänge.

Das vollständige Arbeitsdokument liegt unter operations/artifacts/threat-model.yaml.

Review-Rhythmusoperations

Das Threat Model wird bei neuen Trust Boundaries, neuen sensiblen Daten, neuen externen Integrationen und nach sicherheitsrelevanten Incidents überprüft.

Threat Modeling: vollständiger Zusammenhang

Threat Modeling untersucht früh, welche Werte geschützt werden, wo Trust Boundaries (Trust Boundaries) liegen und wie Angreifer oder Fehler diese Grenzen ausnutzen könnten. STRIDE ist eine Prüfhilfe, ersetzt aber keine fachliche Risikobewertung.

Wie funktioniert der Ablauf?Funktionsweise

Threat Modeling wird aus Benutzerwirkung und SLO abgeleitet. Verantwortliche definieren Signal, Schwelle, Handlung, Sicherheitsgrenze und Nachweis. Nach einem Incident wird überprüft, ob Messung und Prozess die richtige Entscheidung unterstützt haben.

Konkretes CommerceOne-BeispielPraxis

Für den Checkout betrachtet CommerceOne Browser, Gateway, Identity Provider, Order Service, Kafka und Datenbank. Risiken sind Token-Diebstahl, manipulierte Preise, Replay von Zahlungsanfragen und sensible Daten in Logs.

asset: order-and-payment-data
trust-boundary: public-to-gateway
threat: replay-payment-request
control: idempotency-key + provider-reference

So liest du das Beispiel: Identitäten und Zustände werden ausdrücklich benannt. Wiederholung, Teilfehler und Beobachtbarkeit sind Teil des Designs. Das Beispiel ist zum Lesen und Anpassen gedacht; es wird nichts automatisch ausgeführt.

Entscheidungs- und DiagnosefragenReflexion

Welches fachliche Ergebnis soll für den Benutzer entstehen?
Welche Komponente besitzt die Verantwortung und welche Daten gehören ihr?
Was passiert bei Timeout, Wiederholung oder Teilausfall?
Welches Signal beweist, dass der Ablauf korrekt funktioniert?
Welche einfachere Alternative wäre ausreichend?

Zusammenfassung: Threat Modeling ist kein Dokument zum Abhaken, sondern ein überprüfbarer Teil des Betriebs. Qualität zeigt sich daran, ob Teams unter realem Druck schnell und sicher handeln können.

Threat Models in Architektur und Betrieb

Das Threat Model beginnt mit Assets: Konten, Bestellungen, Zahlungsstatus, Tokens, Secrets und Betriebszugänge. Danach werden Datenflüsse und Trust Boundaries (Trust Boundaries) gezeichnet. Erst dann prüft das Team Bedrohungen wie Spoofing, Manipulation, Informationsabfluss oder Denial of Service.

Kontrollen werden konkreten Risiken zugeordnet. TLS schützt Transport, verhindert aber keine fachlich unzulässige Bestellung. Tokenprüfung schützt Identität, ersetzt aber keine Eigentümerprüfung. Idempotency Keys begrenzen Replay, benötigen jedoch sichere Bindung an Benutzer und Operation.

Das Modell wird bei neuen Integrationen, geänderten Datenflüssen und Incidents aktualisiert. Es bleibt klein genug, um in Reviews verwendet zu werden, und verweist auf Tests, Logs, Alarmierung und verantwortliche Teams.

Merksatz: Ein Inhalt gilt erst dann als verstanden, wenn Ziel, Ablauf, Fehlerfall und Nachweis in eigenen Worten erklärt werden können.

Priorisierung

Nicht jede theoretische Bedrohung erhält dieselbe Aufmerksamkeit. CommerceOne bewertet Eintrittswahrscheinlichkeit, Schadenshöhe, vorhandene Kontrollen und Erkennbarkeit. Hohe Risiken werden mit Test und Owner verfolgt; akzeptierte Risiken erhalten Begründung und Review-Datum.

Qualität und Pflege

Ein Threat Model wird nicht nur im Security-Team gepflegt. Entwickler, Operations und Fachverantwortliche ergänzen unterschiedliche Perspektiven: technische Angriffswege, betriebliche Fehlbedienung, Betrugsrisiken und Auswirkungen auf Kunden. Dadurch werden Kontrollen dort platziert, wo sie tatsächlich wirksam und überprüfbar sind.