DemoAnmeldenKontaktEN
Integration Ledger

APIs als aktiver Governance-Türsteher — keine passive Datenleitung.

Eine Zero-Trust-Middleware-Ebene sitzt zwischen jeder Drittanbieter-API und Ihrem System of Record. Tokens werden verifiziert, Payloads über Identitäts-, Endgeräte- und Vertragszustand abgestimmt, und jede freigegebene Transaktion fließt in ein WORM-Ledger.

Die 3-Ebenen-Integrations-Architektur

[ UNTRUSTED DRITTANBIETER-API ] ──> [ LOJYCAL MIDDLEWARE-EBENE ] ──> [ SICHERES SYSTEM OF RECORD ]
                                    - Zero-Trust Proxy Guard          - Kryptografische Verifikation
                                    - Token-Expiry-Intercept          - WORM-Audit-Ledger-Push
Ebene 1

Inbound-Token-Intercept

Jeder Cron- und Webhook-Endpunkt unter /api/public/hooks/* erzwingt ein server-seitiges Gate, bevor eine Datenbankzeile mutiert wird. Cron-Aufrufer müssen einen CRON_SECRET via x-cron-secret präsentieren; Webhook-Aufrufer müssen eine HMAC-Signatur mit timing-safe Compare verifizieren. Der browser-gebündelte Anon-/Publishable-Key wird nie als Autorisierungs-Gate verwendet.

  • • Kandji-Webhook: HMAC-SHA256 verifiziert, UNIQUE(org, event_id) Dedup, ±5-Minuten occurred_at Skew-Fenster.
  • • Jira-Webhook: HMAC-signiertes Forge-Widget → /api/public/hooks/jira-impact.
  • • Replay-Schutz: eindeutiger Index auf (provider, external_id) in idp_webhook_events.
Ebene 2

Multi-Tabellen-Cross-Reference-Kern

Ein einzelnes Inbound-Ereignis wird in einem Durchgang über das gesamte Ledger abgestimmt. Die Integrations-Ebene verbindet Identitäts-, Endgeräte-, Vertrags- und Beschaffungszustand im Hintergrund — und verwandelt einen fragmentierten Webhook in eine synchronisierte Enterprise-State-Machine.

  • • HRIS-Push läuft read → confirm → write → verify gegen Personio / BambooHR, bevor employee_directory.source umgeschaltet wird.
  • • Jira-Tickets werden gegen global_pricing_benchmarks Mediane bewertet und in jira_impact_assessments persistiert.
  • • Beschaffungsanfragen werden gegen procurement_policy (€1k / €5k / €25k Tiers) und Dual-Sign-Off-Regeln abgestimmt.
Ebene 3

WORM-Ledger-Settlement

Freigegebene API-Transaktionen, Lifecycle-Anpassungen und automatisierte Kosten-Eindämmungsereignisse committen in Write-Once-Read-Many-Tabellen, die durch den worm_block_mutation Trigger geschützt sind. UPDATE und DELETE sind für alle blockiert — auch für Plattform-Admins. Jeder Schreibvorgang emittiert zusätzlich eine audit_log-Zeile via AFTER-Trigger.

  • • Vendor-Order-Dispatches → vendor_order_dispatches (WORM) + signierter Egress zum ERP des Käufers.
  • • Incident-Reports → incident_archive + incident_reports (WORM).
  • • Evidence Packs → mit Per-Org-Schlüsseln in evidence_pack_signing_keys signiert, jeder Export in evidence_pack_signatures geloggt.

Secret-Hygiene auf der Privilegienebene

Integrations-Geheimnisse werden auf der Postgres-Privilegienebene gegated, nicht nur durch RLS. Die browser-seitige Rolle kann sie nicht lesen — auch nicht mit gültiger Session.

  • vendor_order_secrets — komplette Tabellen-REVOKE von authenticated; Zugriff nur via vendor_order_set_secret / vendor_order_get_secret RPCs.
  • kandji_org_secrets — nur service_role; RLS aktiv ohne authenticated Policies.
  • siem_egress_endpoints.hmac_secret / signing_secret_encrypted — REVOKE SELECT von authenticated und anon.
  • erp_oauth_tokens, erp_app_credentials.client_secret_enc — spalten-verschlüsselt, nie an den Client zurückgegeben.
  • org_agent_tokens.token — nie vom Client lesbar; nur über server-seitige RPC ausgegeben.
  • SIEM-Egress ist pro Endpunkt HMAC-SHA256-signiert (X-Lojycal-Signature) — Empfänger verifizieren die Signatur, nicht nur TLS.

Abstimmung, nicht nur Sync

  • Inbound HRIS-Event → abgestimmt gegen employee_directory + enrolled_devices + license_subscriptions.
  • Inbound MDM-Event → via ingest_mdm_event (service_role) nach Org-Mitgliedschaftsprüfung geroutet.
  • Inbound Beschaffungs-Ticket → gegen global_pricing_benchmarks vor Freigabe bewertet.
  • Inbound Vendor-PO → mit exponentiellem Backoff dispatched (1m / 5m / 30m / 2h / 12h, max 5 Versuche).
  • Inbound Jira-Webhook → grün / orange / rot gegen Benchmark-Median, in WORM geschrieben.
  • Outbound SIEM-Egress → pro Endpunkt HMAC-signiert, jede Emission geloggt.

Eine Integrations-Ebene. Ein signiertes Ledger.

Hören Sie auf, APIs als Transport-Ebene zu behandeln. Behandeln Sie sie als Eingangstür zu Ihrem geprüften System of Record — gegated, abgestimmt und standardmäßig unveränderlich.

Demo buchenDatenaufbewahrungSSPM vs. CSPM ansehen