TicketFlow × Data Sentinel Instanz

Architekturspezifikation v2.1 · Standalone-Validierungsinstanz für Drift-Erkennung und Datenprovenienz

---

Inhaltsverzeichnis

1. Konzept
2. Architektur
3. Schnittstellen
4. Betriebsmodi
5. Erkennungsmatrix
6. Drei Validierungsstufen
7. Verdict-Taxonomie
8. Grenzen
9. Deployment-Modell
10. Best Practices

---

Konzept

Standalone-Validierungsinstanz mit zwei Kernfähigkeiten:

• Echtzeit-Drift-Erkennung in Quelldaten aus RMM, CMDB und IPAM
• Retrospektive Datenprovenienz-Prüfung, die sicherstellt, dass TicketFlow im gesamten Verarbeitungsprozess ausschließlich mit den originalen, unverfälschten Quelldaten gearbeitet hat

Kommunikation über offene Standards: REST/Webhook zu den Quellsystemen, CloudEvents-konformes Messaging über den Event-Bus.

Dimension 1 — Drift Detection

Frage	Hat sich das Quellsystem während der Analyse verändert?
Zeitdimension	Vergleich Snapshot T₀ vs. Realität T₁. Drift = Δ zwischen beiden
Trigger	Änderung im Source-System selbst, nicht in TicketFlows Verarbeitungslogik
Beispiel	PC 123 hatte IP 10.3.3.3 bei Analyse-Start — wurde er danach umgezogen?

Dimension 2 — Integritätsprüfung (Data Provenance)

Frage	Hat TicketFlow die Daten korrekt und integer verarbeitet?
Standard	W3C PROV-DM — formales Modell für Datenabstammung
Trigger	Interne Fehler: falscher JOIN, Cache-Kollision, Tenant-Isolation-Bug
Bedingung	TicketFlow muss ein Lineage-Manifest emittieren (OpenLineage-Standard)

Im Black-Box-Modus (ohne Manifest) parst der Sentinel den Output auf erkennbare Datenwerte und prüft sie gegen den eigenen Snapshot — grobe Verletzungen wie Cross-Asset-Kontamination werden in beiden Modi erkannt.

---

Architektur

┌─────────────────────────────────────────────────────┐
│           Quellsysteme (read-only für beide)         │
│   CMDB · RMM · IPAM · Firewall-API · Asset-DB        │
└───────────────────┬───────────────────┬──────────────┘
                    │                   │
              (eigener Fetch)     (eigener Fetch)
                    │                   │
         ┌──────────▼──────┐   ┌────────▼──────────────┐
         │   TicketFlow    │   │  Data Sentinel Instanz │
         │  Hauptsystem    │   │  Standalone · read-only│
         │                 │   │                        │
         │ • Snapshot T₀   │   │ • Unabh. Snapshot T₀  │
         │ • Analyse       │   │ • Nachbar-Assets fetch │
         │ • Lineage emit  │   │ • Drift Watch          │
         │ • Verdict recv  │   │ • Integrity Validator  │
         └────────┬────────┘   └────────────┬───────────┘
                  │                          │
                  └──────── Event-Bus ────────┘
                        (Kafka / RabbitMQ)
                        CloudEvents-Format

Prinzipien:

• Sentinel ist kein Proxy, kein Man-in-the-Middle — er beobachtet, vergleicht, bewertet
• Keine direkte API-Abhängigkeit zwischen den Systemen
• Sentinel hat keinerlei Schreibzugriff auf Quellsysteme

---

Schnittstellen

Quellsystem-Schnittstellen

CMDB / Asset-Systeme (ServiceNow, Device42, NetBox)

Protokoll	Nutzung
REST / JSON	Primär: GET /api/asset/{id} — vollständiger Asset-Record
GraphQL	NetBox, ServiceNow: gezieltes Fetchen relevanter Felder
Webhook / Push	ServiceNow Business Rules, NetBox Webhooks → Callback-URL für sofortige Drift-Erkennung
CDC / Debezium	Für CMDB auf relationalen DBs: sub-sekunden Latenz bei Konfigurationsänderungen

RMM / Monitoring-Systeme (N-central, NinjaRMM, Zabbix)

Protokoll	Nutzung
REST API	Vendor-spezifisch (z.B. NinjaRMM GET /v2/device/{id}/last-contact)
SNMP v3	Netzwerkequipment: sysName, ifTable, ipAddrTable — authPriv
SNMP Trap	Geräte senden Traps bei Konfigurationsänderungen aktiv
Syslog	IP-Change, VLAN-Reassignment als Drift-Signal

IPAM (NetBox, phpIPAM, Infoblox)

Protokoll	Nutzung
REST / GraphQL	NetBox: GET /api/ipam/ip-addresses/?address=10.3.3.3
Webhook	NetBox Webhooks bei IP-Änderungen für Assets in Bearbeitung

Firewall / Security-Systeme (Palo Alto, Fortinet, Cisco)

Protokoll	Nutzung
REST API	PAN-OS REST, FortiOS REST, Cisco FMC REST
NETCONF	RFC 6241 + YANG-Modelle für vendor-übergreifende Abfragen
Syslog / CEF	Firewall-Policy-Änderungen als Events

Message-Bus-Protokoll: TicketFlow ↔ Sentinel

AsyncAPI 3.0 als Dokumentationsstandard empfohlen.

Topic: ticketflow.analysis.started (TF → Sentinel)

{
  "specversion": "1.0",
  "type": "tf.analysis.started",
  "source": "/ticketflow",
  "id": "job-abc-123",
  "time": "T₀",
  "data": {
    "asset_id": "PC-123",
    "snapshot": { "ip": "10.3.3.3", "vlan": "FR565" },
    "snapshot_at": "T₀"
  }
}

Topic: ticketflow.analysis.concluded (TF → Sentinel)

{
  "type": "tf.analysis.concluded",
  "id": "job-abc-123",
  "data": {
    "result": { "cause": "Port-Down L2" },
    "lineage": [
      { "field": "ip",   "value": "10.3.3.3", "source": "CMDB", "fetched_at": "T₀", "transform": null },
      { "field": "vlan", "value": "FR565",   "source": "RMM",  "fetched_at": "T₀", "transform": null }
    ]
  }
}

Topic: sentinel.verdict (Sentinel → TF)

{
  "type": "sentinel.verdict",
  "id": "job-abc-123",
  "data": {
    "verdict": "CLEAN",
    "drift_status": "NONE",
    "integrity_status": "OK",
    "confidence": "HIGH",
    "action": "PROCEED"
  }
}

Bei Verletzung:

{
  "data": {
    "verdict": "CONTAMINATION",
    "drift_status": "NONE",
    "integrity_status": "VIOLATED",
    "violation": { "type": "cross_asset_contamination", "foreign_value": "10.4.5.6", "foreign_asset": "PC-456" },
    "action": "DISCARD_ANALYSIS",
    "bug_hint": "Cache-Key-Kollision in Subnet-Lookup"
  }
}

Delivery-Garantien:

• At-least-once über Kafka oder RabbitMQ. Sentinel und TicketFlow sind idempotent — Duplikate anhand job_id dedupliziert.
• Opt-in Sync-Gate: TicketFlow wartet max. 10 s auf sentinel.verdict (Request-Reply). Timeout → fortfahren mit Warnung. Nur bei kritischen Pfaden.
• Schema-Versionierung: Breaking Changes erhalten neue type-Versionsnummer (tf.analysis.concluded.v2).

---

Betriebsmodi

Modus A — Kooperativ (Lineage-Manifest-Modus)

Erkennungstiefe: hoch — alle Mutationstypen erkennbar

TicketFlow emittiert nach Abschluss ein strukturiertes Manifest aller verarbeiteten Werte im OpenLineage-Format. Der Sentinel vergleicht jeden Eintrag deterministisch gegen seinen eigenen Snapshot.

TicketFlow → emittiert OpenLineage-Manifest:
{
  job_id: "abc-123",
  used_values: [
    {field:"ip",   value:"10.3.3.3", src:"CMDB"},
    {field:"vlan", value:"FR565",   src:"RMM"},
    {field:"asset",value:"PC-123",  src:"AssetDB"}
  ]
}

Sentinel → prüft jeden Eintrag:
snapshot[ip]    === "10.3.3.3" ✓
snapshot[vlan]  === "FR565" ✓
snapshot[asset] === "PC-456" ✗ FREMDWERT!

Modus B — Black-Box (Output-Parsing-Modus)

Erkennungstiefe: mittel — grobe Verletzungen sicher, subtile Mutationen blind

Kein Manifest von TicketFlow. Der Sentinel parst den Output via Regex-Extraktion auf erkennbare Datenwerte (IP-Adressen, MAC-Adressen, Asset-IDs, VLAN-Namen) und kreuz-referenziert gegen alle bekannten Snapshots.

Wichtig: Modus B erkennt 10.3.3.3 → 10.3.3.30 nicht — beide sehen wie valide IPs aus. Nur Modus A (Manifest) macht solche Micro-Mutationen sichtbar. Siehe BP-02.

---

Erkennungsmatrix

Verletzungstyp	Typische Ursache	Modus	Erkennbar
Quelldaten-Drift	Asset physisch umgezogen während Analyse läuft	Beide	✅ Sicher
Cross-Asset-Kontamination	Falscher JOIN, Cache-Key-Kollision	Beide	✅ Sicher
Datenwert-Mutation	TicketFlow-Bug transformiert Wert (10.3.3.3 → 10.3.3.30)	Nur Manifest	⚠️ Nur Modus A
Stale-Cache-Nutzung	TicketFlow nutzt gecachten Wert aus früherer Anfrage	Nur Manifest	⚠️ Nur Modus A
Halluzination / Phantom-Wert	Output enthält IP/Asset-ID aus keinem bekannten Snapshot	Beide	✅ Grob erkannt
Tenant-Isolation-Bruch	Daten eines anderen Mandanten im Output	Beide	✅ Sicher
Datensatz-Trunkierung	Wert lossy transformiert (IP-Oktet abgeschnitten)	Nur Manifest	⚠️ Nur Modus A
Logischer Analysefehler	Valide Daten, falsche Schlussfolgerung (algorithmischer Bug)	—	❌ Out of scope

---

Drei Validierungsstufen

Stufe 01 — Pre-Flight: Snapshot-Isolation

Beim Start der Analyse fetcht der Sentinel unabhängig einen eigenen Snapshot — inklusive Nachbar-Assets im gleichen Subnetz und VLAN.

event: tf.analysis.started
asset_id: PC-123
→ Sentinel fetcht: PC-123 (CMDB + IPAM)
→ Sentinel fetcht: Subnet 10.3.3.0/24
  Nachbarn: PC-456, PC-789, … (max. 50, siehe BP-03)
→ Snapshot-Store: append-only, versioned

Nachbar-Snapshots sind die Referenz für die spätere Kontaminationserkennung: Wenn ein Wert aus Nachbar-Asset PC-456 im Output von PC-123 auftaucht, weiß der Sentinel genau, woher er stammt.

Stufe 02 — Drift Watch: Kontinuierliche Überwachung

Während TicketFlow analysiert, überwacht der Sentinel alle betroffenen Assets.

watch: Webhooks (bevorzugt) + Poll 30s ±5s Jitter (BP-03)
assets: [PC-123, …neighbors]
on_change:
  delta = diff(snapshot_T0, current)
  store(delta, timestamp)
→ drift_log für job-abc-123

• Push-basiert via Webhooks oder CDC bevorzugt (sofortige Erkennung)
• Fallback: 30s-Polling mit Jitter
• Jeder erkannte Drift wird mit Timestamp und Delta gespeichert

Stufe 03 — Retrospektive Prüfung: Provenienz-Validierung

Nach Abschluss empfängt der Sentinel das Lineage-Manifest und führt den deterministischen Vergleich durch:

for each entry in lineage_manifest:
  match = lookup(entry.value, snapshots)
  if !match → INTEGRITY_VIOLATION
  if match.asset != job.asset → CONTAMINATION
combine(drift_log, integrity_result)
→ emit: sentinel.verdict (CloudEvent)

Alle drei Stufen sind zustandslos und idempotent — jede Analyse kann mit ihrer job_id und snapshot_at-Referenz jederzeit neu validiert werden.

---

Verdict-Taxonomie

Verdict	Bedeutung	TicketFlow-Aktion
CLEAN	Kein Drift, alle Output-Werte provenienz-rein	Ergebnis weiterverarbeiten
DRIFT_MINOR	Drift in unkritischen Feldern (Raumname, Benutzername). Output integer	Warnung im Befund, fortfahren
DRIFT_CRITICAL	Drift in kritischen Feldern (IP, VLAN, Subnetz, Firewall-Zone)	Re-Analyse mit corrected_snapshot
INTEGRITY_VIOLATION	Output enthält Werte aus unbekanntem Ursprung	Analyse verwerfen + Bug-Report
CONTAMINATION	Fremdwert aus identifiziertem anderen Asset (Cross-Asset)	Analyse verwerfen + Fremd-Asset referenziert
DRIFT+INTEGRITY	Kombination: Drift + Integrity verletzt	Analyse verwerfen + Eskalation
CORRECTION	Korrigierter Datensatz mitgeliefert (nur bei DRIFT_CRITICAL ohne Integrity-Verletzung)	Auto-Re-Analyse mit corrected_snapshot
INCONCLUSIVE	Quellsystem nicht erreichbar oder Manifest fehlerhaft	Manueller Review-Flag
INCONCLUSIVE_PARTIAL	Einzelnes Quellsystem ausgefallen, Rest verifiziert	PROCEED mit Einschränkungs-Annotation
INCONCLUSIVE_TOTAL	Alle Quellsysteme nicht erreichbar	Analyse zurückstellen + Alert

Das Verdict enthält immer beide Dimensionen separat (drift_status und integrity_status), damit TicketFlow differenziert reagieren kann.

---

Grenzen

Grenze	Erklärung
Logische Analysefehler	Wenn TicketFlow alle Daten korrekt verarbeitet, aber die falsche Schlussfolgerung zieht, erkennt der Sentinel das nicht. Daten-integer ≠ Logik-korrekt. Für diesen Bereich wäre ein Model-Checking-Ansatz oder ein LLM-basiertes Second-Opinion-Layer nötig.
Subtile Mutationen ohne Manifest	Im Black-Box-Modus wird 10.3.3.3 → 10.3.3.30 nicht erkannt. Nur Modus A (Manifest) macht Micro-Mutationen sichtbar.
Unbekannte Quellsysteme	Wenn TicketFlow Daten aus einem System zieht, auf das der Sentinel keinen Zugriff hat, markiert er diese Werte als INCONCLUSIVE. Der Sentinel braucht Zugang zu allen Quellsystemen, die TicketFlow nutzt.
Async-Latenz bei Sofort-Aktionen	Die Integritätsprüfung ist retrospektiv. Wenn TicketFlow sofort handelt (Ticket erstellt, Techniker losgeschickt), kann das Verdict zu spät kommen. Der opt-in Sync-Gate-Modus (max. 10 s) löst das für kritische Aktionspfade.

---

Deployment-Modell

Data Sentinel Instanz

Parameter	Wert
Typ	Standalone Container (Docker / systemd-Service)
Snapshot-DB	Eigene DB — append-only, versioned (PostgreSQL empfohlen, SQLite für Dev)
Quellzugriff	Read-only Service Account, eigene Credentials pro System
Schreibrecht	Keine — nur Event-Bus-Publish
Nachbar-Fetch	Selbes Subnetz + VLAN beim Pre-Flight, max. 50 Assets
Polling	30 s ±5 s Jitter als Fallback; Push via Webhooks bevorzugt

TicketFlow-Integration

Schritt	Detail
Emit Start	CloudEvent: tf.analysis.started (asset, snapshot)
Emit End	CloudEvent: tf.analysis.concluded + Lineage-Manifest (OpenLineage-Format)
Consume	CloudEvent: sentinel.verdict → handeln
Sync-Gate	Optional: max. 10 s warten, dann fortfahren mit Warnung
Fallback	Sentinel nicht erreichbar → INCONCLUSIVE-Flag, kein Block

Betriebsprinzipien

• Async: Blockiert TicketFlow nie außer opt-in Sync-Gate
• Unabhängig: Eigene Credentials, DB, Lifecycle — kein Shared State
• Read-only: Kein Schreibzugriff auf irgendein System
• Idempotent: Re-Validierung per job_id + snapshot_at jederzeit möglich
• Multi-tenant: Kann für mehrere TicketFlow-Instanzen parallel arbeiten

Lineage-Manifest-Schema (OpenLineage)

{
  "schema": "openlineage/1.0",
  "job_id": "abc-123",
  "used_values": [{
    "field": "ip",
    "value": "10.3.3.3",
    "source": "CMDB",
    "fetched_at": "2026-01-15T14:23:01Z",
    "transform": null
  }]
}

---

Best Practices

10 Implementierungsrichtlinien für produktionsreife Systeme. Das Konzept beschreibt was der Sentinel tut — diese Regeln beschreiben wie er korrekt betrieben wird.

Prioritäten: 🔴 Kritisch (nie ignorieren) · 🟡 Hoch (vor Go-Live) · 🔵 Mittel (erste Sprint nach Launch)

---

BP-01 · Sentinel-Observability — wer überwacht den Wächter? 🔴

Das Konzept beschreibt, wie der Sentinel TicketFlow überwacht — aber nicht, wer den Sentinel selbst überwacht. Ein stiller Ausfall führt dazu, dass alle Verdicts INCONCLUSIVE zurückgeben, ohne dass jemand alarmiert wird.

Anforderungen:

• Health-Endpoint: /health (liveness) + /metrics (Prometheus-Format) sind Pflicht.
• INCONCLUSIVE-Rate-Alarm: Alert wenn >10 % aller Verdicts innerhalb von 5 min INCONCLUSIVE — deutet auf Quellsystem-Ausfall hin.
• Dead-Man's-Switch: Wenn nach analysis.concluded kein Verdict innerhalb von timeout + 15 s emittiert wurde → Alert an On-Call.
• Verdict-Latenz-Histogram: P50/P95/P99 pro Analyse-Typ. Regression = interner Bug oder Quellsystem-Latenz.

# Pflicht-Metriken (Prometheus-Format)
sentinel_verdicts_total{type="CLEAN",mode="manifest"} 412
sentinel_verdicts_total{type="INCONCLUSIVE"} 3
sentinel_verdict_latency_seconds{quantile="0.99"} 1.8
sentinel_source_errors_total{source="CMDB"} 0
sentinel_snapshot_db_size_bytes 1.2e8

---

BP-02 · Modus A als Standard — OpenLineage von Tag 1 🔴

Modus B (Black-Box) erkennt nur grobe Verletzungen. Retrofitting von OpenLineage-Instrumentation in ein laufendes System ist teuer — deswegen von Anfang an richtig.

Regeln:

• Modus A (Manifest) ist der Default. Modus B ist ausschließlich Fallback für Legacy-Integrationen ohne Instrumentierungsmöglichkeit.
• OpenLineage-Instrumentation beim ersten TicketFlow-Analyse-Job einbauen — nicht nachträglich.
• Pflichtfeld fetched_at (ISO 8601) im Manifest — erlaubt dem Sentinel, veraltete Snapshots zu erkennen, auch wenn kein Quellsystem-Drift gemessen wurde.
• Wenn Modus B genutzt wird: Explizit als "mode": "blackbox" im Verdict dokumentieren, damit TicketFlow die niedrigere Erkennungstiefe kennt.

{
  "schema": "openlineage/1.0",
  "job_id": "abc-123",
  "used_values": [{
    "field": "ip",
    "value": "10.3.3.3",
    "source": "CMDB",
    "fetched_at": "2026-01-15T14:23:01Z",
    "transform": null
  }]
}

---

BP-03 · Rate Limiting und Backpressure beim Nachbar-Fetch 🟡

In einem /16-Netz können das Tausende Assets sein. Ohne Jitter feuern alle parallelen Jobs synchron auf die Quellsysteme.

Regeln:

• Max. 50 Nachbarn pro Pre-Flight — sortiert nach ARP-Tabellen-Einträgen (zuletzt aktive Nachbarn bevorzugt).
• Jitter beim Poll-Fallback: 30 s ± 5 s Randomisierung verhindert Thundering-Herd.
• Exponential Backoff bei Fehlern: 1 s → 2 s → 4 s → 8 s → max 60 s, dann Circuit Breaker öffnen.
• Bulkhead-Isolation: Jedes Quellsystem bekommt einen eigenen HTTP-Client mit separatem Connection-Pool — ein ausgefallenes System blockiert nicht die anderen.

---

BP-04 · Circuit Breaker für Quellsysteme 🟡

Wenn die CMDB während Pre-Flight nicht erreichbar ist, bleibt der Snapshot unvollständig. Das Konzept differenziert nicht: Ist ein System ausgefallen oder alle?

Regeln:

• Partial-Snapshot statt Totalausfall: Fetch was erreichbar ist, markiere fehlende Quellen explizit im Snapshot-Objekt.
• Circuit Breaker: Nach 3 aufeinanderfolgenden Fehlern → 60 s Open → INCONCLUSIVE_PARTIAL emittieren.
• Differenziertes INCONCLUSIVE:
  • INCONCLUSIVE_PARTIAL — ein System ausgefallen, Rest verifiziert
  • INCONCLUSIVE_TOTAL — alle Quellsysteme nicht erreichbar
• unavailable_sources im Verdict — TicketFlow weiß, welche Daten ungeprüft blieben.

{
  "verdict": "INCONCLUSIVE_PARTIAL",
  "unavailable_sources": ["CMDB"],
  "verified_sources": ["RMM", "IPAM"],
  "action": "PROCEED_WITH_WARNING"
}

---

BP-05 · AsyncAPI Spec vor Implementierung (Contract-First) 🟡

Ohne formalen Kontrakt entstehen stille Schema-Inkompatibilitäten, die erst in Production auffallen.

Regeln:

• AsyncAPI 3.0 Spec zuerst schreiben — beide Teams entwickeln gegen die Spec, nicht gegen eine gemeinsame Implementierung.
• Consumer-driven Contract Tests (z.B. Pact): Sentinel-Team definiert, welche Felder aus analysis.concluded es benötigt. TicketFlow-Tests schlagen fehl, wenn Felder fehlen.
• Breaking Changes erhalten neue Type-Version: tf.analysis.concluded.v2 — Sentinel konsumiert beide Versionen während des Migrationszeitraums.
• Schema-Registry empfohlen (Confluent Schema Registry, AWS Glue) bei Kafka als Transport.

---

BP-06 · Chaos-Testing und Sentinel-Qualifikation 🟡

Ohne aktive Tests kann ein fehlkonfigurierter Sentinel jahrelang CLEAN zurückgeben, weil er nie eine echte Verletzung gesehen hat.

Regeln:

• Canary-Analysen: Monatlich eine synthetische Analyse mit bekannter CONTAMINATION senden — Sentinel muss sie zuverlässig erkennen.
• Test-Mode-Flag im CloudEvent: "x-sentinel-test": true im Extension-Feld — Verdicts landen in Test-Log, beeinflussen TicketFlow nicht.
• Chaos Fire-Drill: Quartalsweise Sentinel absichtlich isolieren (Network-Policy) — TicketFlow muss korrekt auf INCONCLUSIVE reagieren.
• Mutationstest für Lineage-Manifest: Bekannte Fremdwerte in Modus-A-Manifeste injizieren und sicherstellen, dass alle Mutationsklassen aus der Erkennungsmatrix erkannt werden.

---

BP-07 · Snapshot-Retention-Policy 🟡

Die DB ist append-only, versioned — ohne Pruning-Strategie wächst sie unbegrenzt.

Regeln:

• TTL 30 Tage nach Abschluss der zugehörigen job_id — Snapshots für aktive Jobs werden nie gelöscht.
• Compliance-Archivierung separat: Falls Verdicts nachweisbar bleiben müssen, Snapshots komprimiert in Cold-Storage (S3/Blob) exportieren vor TTL-Prune.
• Disk-Space-Alert bei 80 %: Automatisches Pruning läuft täglich, aber Alert schlägt an bevor Storage voll ist.
• Index auf (job_id, snapshot_at) — Re-Validierungen per Zeitraum müssen performant sein.

---

BP-08 · Verdict-TTL und Replay-Schutz 🔵

Ein altes Verdict könnte bei einem Re-Replay eines analysis.concluded-Events erneut zugestellt werden.

Regeln:

• expires_at im Verdict: Sentinel setzt TTL = issued_at + 10 min — TicketFlow verwirft abgelaufene Verdicts.
• Maximal ein Verdict pro job_id — Duplikate (z.B. durch Kafka At-least-once) werden intern dedupliziert.
• TicketFlow: Kein Verdict nach 10 min = TIMEOUT — eigener Alarm, unabhängig vom Dead-Man's-Switch (BP-01).

{
  "type": "sentinel.verdict",
  "data": { "verdict": "CLEAN" },
  "time": "2026-01-15T14:23:05Z",
  "expires_at": "2026-01-15T14:33:05Z"
}

---

BP-09 · Graduated Response — kein binäres DISCARD 🔵

Nicht jede Integrity-Verletzung hat dasselbe Gewicht. Ein VLAN-Feld aus einem Nachbar-Asset im unwichtigen Logging-Kontext ist anders zu bewerten als ein IP-Feld im Routing-Entscheidungs-Kontext.

Regeln:

• Severity-Score (0–10) im Verdict: Berechnet aus Kritikalität des betroffenen Feldes × Kontaminationstyp. TicketFlow kann ab Schwelle selbst entscheiden.
• DRIFT_MINOR + kein Integrity-Problem → PROCEED + annotieren: Befund weiterverarbeiten, Drift als Metadaten im Ticket hinterlegen.
• Eskalationsregel: 2× CONTAMINATION vom gleichen Asset-Pair innerhalb 1 h → automatisch Bug-Report-Ticket mit Cache-Key-Hinweis erstellen.
• Re-Analyse statt DISCARD bei DRIFT_CRITICAL ohne Integrity-Verletzung: corrected_snapshot aus dem Sentinel verwenden, kein manueller Eingriff.

---

BP-10 · Security — Credential-Hygiene für Service Accounts 🔵

Read-only Service Accounts sind die richtige Grundregel. Ohne Rotationsstrategie und Secrets-Management werden Credentials zu langlebigen Risiken.

Regeln:

• Rotation alle 90 Tage — automatisiert über Secrets Manager (HashiCorp Vault, AWS Secrets Manager, K8s External Secrets). Kein Klartext in Config-Files oder ENV-Vars ohne Injection-Mechanismus.
• Unabhängige Rotation: Sentinel-Credentials müssen rotierbar sein ohne TicketFlow-Downtime.
• Minimaler Scope pro Quellsystem: CMDB-Credential darf nur GET /api/asset/{id} — kein Schreib-Scope, kein Admin-Scope, kein Cross-Tenant-Zugriff.
• Audit-Log für alle Sentinel-Zugriffe: Read-only Zugriffe sind harmlos, aber Kompromittierung eines Service Accounts ist damit früh erkennbar.

---

Standards & Referenzen

Standard	Zweck
W3C PROV-DM	Formales Modell für Datenprovenienz
OpenLineage	Lineage-Manifest-Format (Modus A)
CloudEvents 1.0	Event-Envelope-Standard für Event-Bus
AsyncAPI 3.0	API-Dokumentation für Message-Bus-Protokoll
Debezium CDC	Change-Data-Capture für CMDB-Systeme
OpenTelemetry	Alternativer Lineage-Transport via Trace-Spans
SNMP v3 (RFC 3411)	Netzwerkgeräte-Monitoring
NETCONF (RFC 6241)	Netzwerkkonfigurations-Abfragen