<340 ns Pro Entscheidung
<600 ps Logische Op.
2.9M/sec Durchsatz
On-premise nativ Keine Cloud-Laufzeit

Integration & Deployment

OmegaOS™ Kernel wird als Overlay in Ihrer bestehenden Infrastruktur bereitgestellt.
Keine Migration erforderlich. Keine Änderungen am Anwendungscode im Regelfall. Beweisaufzeichnung vom ersten Tag an.

Overlay, kein Ersatz

OmegaOS™ Kernel ersetzt nicht Ihren Identity Provider, Ihr API-Gateway oder Ihren Policy Decision Point (PDP). Es ummantelt sie. Es schafft eine einheitliche Beweisebene, in der jede Autorisierung bewertet, aufgezeichnet und überprüfbar ist.

Ihr bestehendes PDP arbeitet weiter wie bisher. OmegaOS™ Kernel zeichnet die Entscheidungen auf, fügt eine dreiwertige Evaluierung hinzu und erstellt exportierbare "Evidence Packs" (Beweispakete).

Klassifikation
Souveräne Entscheidungsinfrastruktur. Overlay für Autorisierungsinfrastruktur.
Funktion
Erfasst Autorisierungsentscheidungen mit vollständiger Beweiskette. Exportiert Beweispakete mit SHA-256 Integritäts-Hashes und optionaler Ed25519 Bescheinigung (sofern Signierschlüssel bereitgestellt werden).
Beziehung
Ummantelt Ihr bestehendes PDP (OPA, Cedar, individuelle Lösung). Ergänzt um Beweiserfassung und dreiwertige Konflikterkennung.
Deployment
Overlay. Kein Ersatz bestehender Systeme. Keine Änderungen am Anwendungscode nötig; evtl. Anpassungen am Gateway oder Routing.

Overlay Architektur

OmegaOS™ Kernel verknüpft sich mit Ihrem bestehenden Stack. Es ersetzt nicht — es umschließt.

Ihre Anwendungen Dienste beziehen Entscheidungen über das Gateway
OmegaOS™ Kernel — Evidence Runtime Dreiwertige Auswertung · Beweiserfassung · Nachweis-Export
Ihre Infrastruktur Identity Provider · API Gateways · Datenbanken · Aktuelles PDP

Keine Migration erforderlich. OmegaOS™ Kernel beobachtet zunächst Ihre bestehenden Autorisierungsflüsse. Es verzeichnet, was Ihr aktuelles System entscheidet. Wenn Sie bereit sind, führt es die dreiwertige Evaluierung neben — nicht anstelle von — Ihrem bestehenden PDP ein. Eine Anpassung der Gateway-Verschaltung und des Routings in Ihrem Deployment kann erforderlich sein.

Shadow-Modus

Vergleichen Sie OmegaOS™ Kernel-Entscheidungen mit Ihrem bestehenden PDP in Echtzeit. Identifizieren Sie Abweichungen vor der Erzwingung.

Abweichungs-Erkennung (Mismatch)

Im Shadow-Modus leitet das Gateway jede Anfrage sowohl an Ihr Upstream-PDP als auch an die OmegaOS™ Kernel Auflösungs-Engine weiter. Es gibt das Urteil Ihres PDP an den Aufrufer zurück — keine Störungen — protokolliert jedoch beide Ergebnisse und markiert etwaige Abweichungen.

Abweichungen werden in Prometheus-Metriken gezählt (upstream_del_mismatches) und in der Entscheidungsantwort ausgegeben. So erhalten Sie eine präzise Messung von Divergenzen, bevor Sie in den Enforce-Modus (Erzwingung) wechseln.

MetrikBedeutung
MatchPDP und OmegaOS™ Kernel stimmen im Ergebnis überein
MismatchPDP und OmegaOS™ Kernel stimmten nicht überein — markiert zur Überprüfung
KonfliktOmegaOS™ Kernel erkennt widersprüchliche Nachweise (Unbestimmt)
# Shadow-Modus-Antwort — Abweichung entdeckt { "decision": "ALLOW", "source": "upstream", "verdict_diff": { "del_result": "DENY", "upstream_allowed": true, "match_status": "mismatch" } }

Standardmäßig "Fail-Closed"

Wenn das System nicht auswerten kann, lehnt es ab. Kein stillschweigendes Durchlassen.

OPA Unerreichbar

Ist das Upstream-PDP im Enforce-Modus unerreichbar, gibt das Gateway 403 Forbidden zurück. Entscheidungen werden nicht geraten. Der Ausfall wird mit vollem Kontext protokolliert.

Konfigurierbarer Ausfall-Modus

Der Fail-Modus wird durch die Richtlinie OPA_FAIL_MODE kontrolliert. Standard: closed. Im Closed-Modus (geschlossen) blockiert jeder Fehler die Anfrage. Im Open-Modus (offen, nicht empfohlen für die Produktion) werden Ausfälle protokolliert, aber Zugriff gewährt.

Design als Beratersystem

OmegaOS™ Kernel liefert strukturierte Entscheidungen, die menschliche Bediener informieren. Es führt keine unabhängigen Aktionen weiter unten in der Kette aus. Im Observe- und Shadow-Modus wirkt es rein beratend. Im Enforce-Modus leitet es Zugangsurteile (200/403/409) um und stützt sich für die Geschäftslogik der Ausführung auf die aufrufende Anwendung.

Integrationsmuster

Drei Deployment-Muster. Keine Anwendungsänderungen notwendig.

MusterBeschreibung
SidecarSetzen Sie das Gateway als Sidecar-Container ein. Leiten Sie Befugnisaufrufe an localhost:3200. Kubernetes-nativ.
Reverse ProxyPlatzieren Sie das Gateway vor Ihrer API. Kompatibel mit nginx auth_request, Envoy ext_authz oder jedem Proxy mit Subrequests-Fähigkeit.
Parallele PipelineLassen Sie den Shadow-Modus zusammen mit Ihrem aktuellen System laufen. Echtzeitabgleich bei Tests. Durchsetzungs-Eskalation nach Sicherung der Ergebnisse.

Konfiguration

Die Konfiguration beim Herstellen von Modusumschaltungen ist per Umgebungsvariable verfügbar. Alles kann für die Zero-Downtime-Bereitstellung als Single Variable Change gehandhabt werden.

# Sidecar — Observe-Modus GATEWAY_MODE=observe GATEWAY_TENANT_ID="your-tenant-uuid" # Shadow — Vergleich mit bestehendem PDP GATEWAY_MODE=shadow OPA_ENABLED=1 OPA_URL="localhost:8181" HOVO_LICENSE_B64="..." # Enforce — System ist federführend (authoritative) GATEWAY_MODE=enforce HOVO_LICENSE_B64="..." # DENY → 403, CONFLICT → 409, ALLOW → 200

Rollback ist eine einzige Variable. Setzen Sie GATEWAY_MODE=observe um in den Nur-Aufzeichnungsmodus zurückzukehren. Kein Neustart notwendig im Regelfall. Daten bleiben erhalten.

RuntimeRust
APIOpenAPI 3.1
DeploymentDocker / K8s / Helm
IsolationRow-Level Security

OmegaOS™ — Souveränitäts-Overlay

OmegaOS™ erweitert den Kernel um eine Souveränitätsebene als Overlay — eine Governance-Einheit, die Ihre gesamte IT-Architektur in eine gebündelte Entscheidungshülle verpackt.

Der Kernel und das Decision Evidence Log (DEL) sind bereits operativ. Das Multi-Engine-Governance-Overlay — einschließlich engine-übergreifender Vertrauensgrenzen und Regeln zur Entscheidungsweitergabe — befindet sich in der Implementierungsphase.

OmegaOS™ ist kein eigenständiges Betriebssystem. Es fungiert als ausführende Überwachungsebene. Es verdrängt nicht Ihre Struktur — es organisiert, inwiefern Autorisierungsdaten hindurchfließen.

OmegaOS™ Kernel = Ebene der Ausführungsgovernance (Evidence Runtime)
OmegaOS™ = Souveränitäts-Overlay (Steuernde Hülle für OS / K8s / Cloud)

Ihre Anwendungen Anwendungen entnehmen Beschlüsse über das Gateway
OmegaOS™ — Souveränitäts-Overlay Richtlinien-Orchestrierung · Beweissammlung · Entscheidungsgovernance
OmegaOS™ Kernel — Ebene der Ausführungsgovernance Dreiwertige Evaluierung · Beweisgenerierung · Konfliktermittlung
Ihre Infrastruktur Identity Provider · API Gateways · Datenbanken · Bestehendes PDP

Beweise durch Design

OmegaOS™ Kernel fordert Sie nicht auf, dem System zu vertrauen. Es erzeugt die Beweise, damit Sie es überprüfen können. Jede Entscheidung, jeder Beweis, jeder Export — aufgezeichnet, nachverfolgbar, reproduzierbar.