Sicherheit durch Struktur, nicht durch Patches
Der OmegaOS™ Kernel ist standardmäßig "fail-closed", strukturell "append-only" und konzeptionell "advisory-only" (nur beratend). Jede Schutzmaßnahme ist strukturell — integriert in das Schema, die Laufzeitumgebung und das Bereitstellungsmodell.
Bedrohungsmodell (Threat Model)
Unbefugter Datenzugriff
Eingedämmt durch Row-Level Security (RLS), die pro Mandant (Tenant) auf Postgres-Ebene erzwungen wird, sowie API-Schlüssel-Authentifizierung mit ~285 Bit Entropie.
Manipulation des Audit-Trails
Eingedämmt durch Append-only Schema (nur Hinzufügen). Laufzeitdienste (Runtime, hovo_app) können nur INSERT ausführen — kein UPDATE oder DELETE auf Ledger-Tabellen. Widerrufungen (Revocations) erzeugen neue Datensätze.
Lizenzumgehung
Eingedämmt durch Ed25519-Offline-Verifizierung. Der öffentliche Schlüssel wird zum Zeitpunkt der Kompilierung (Compile-Time) eingebettet. Kein Lizenzserver, keine Netzwerkabhängigkeit. Manipulierte Tokens scheitern an der kryptografischen Prüfung.
Geleakte Builds
Eingedämmt durch Build-Fingerprinting. Jedes Binary bettet zur Kompilierzeit git_sha + build_timestamp + customer_tag ein. Der Fingerabdruck erscheint in Statusprüfungen (Health Checks) und Entscheidungsprotokollen.
Standardmäßig Fail-closed
Wenn das Upstream-PDP unerreichbar ist oder die Auswertung fehlschlägt, fällt das Gateway im Enforce-Modus standardmäßig auf DENY (Verweigern) zurück. Dies wird durch OPA_FAIL_MODE gesteuert, welches standardmäßig auf closed gesetzt ist.
Fail-open-Systeme gewähren stillschweigend Zugriff, wenn sie ausfallen. Fail-closed-Systeme blockieren den Zugriff, wenn sie ausfallen. Für compliance-sensible Umgebungen ist Fail-closed die sichere Voreinstellung.
| Szenario | Fail-Closed | Fail-Open |
|---|---|---|
| OPA unerreichbar | 403 Forbidden | Synthetisches Allow (protokolliert) |
| Interner Fehler | 403 Forbidden | Synthetisches Allow (protokolliert) |
| Lizenz abgelaufen | Auto-Downgrade auf OBSERVE | |
Row-Level Security (RLS)
Jede Abfrage durchläuft Postgres-RLS-Richtlinien. Die Rolle hovo_app kann nur auf Zeilen (Rows) zugreifen, die dem aktuellen Mandantenkontext (Tenant Context) entsprechen, der zu Beginn jeder Transaktion festgelegt wird.
Selbst wenn ein Angreifer eine SQL-Injection über die Anwendungsschicht ausführt, kann er nicht auf die Daten eines anderen Mandanten zugreifen — die Datenbank erzwingt die Isolation auf Zeilenebene.
| Rolle | RLS | Verwendet von |
|---|---|---|
| hovo_admin | BYPASSRLS | CLI-Tools, Migrationen |
| hovo_app | Erzwungen (Enforced) | hovo-api, hovo-gateway |
hovo_admin wird niemals von Laufzeitdiensten (Runtime) verwendet. Es ist auf Betreiber-Tools (Operator Tools) beschränkt, die separat ausgeführt werden.
Append-only Ledger
Sechs Ledger-Tabellen sind für die Laufzeit-Rolle auf INSERT-only (nur-Einfügen) beschränkt. Keine Entscheidung kann nachträglich geändert werden.
API-Schlüssel Authentifizierung
- Format:
delk_+ 48 alphanumerische Zeichen (~285 Bit Entropie) - Speicherung: bcrypt gehasht (Cost 12) — Klartext wird einmalig bei Generierung angezeigt
- Rotation (Wechsel): Maximal 2 Hashes pro Mandant für reibungslosen Schlüsselwechsel (Zero-Downtime)
- Zuordnung: API-Schlüssel → tenant_id ist die einzige Quelle der Wahrheit (Single Source of Truth) für den RLS-Kontext
Lizenzverifizierung
- Algorithmus: Ed25519 Signaturverifizierung
- Key Management: Öffentlicher Schlüssel ist bei der Kompilierung in Binary eingebettet
- Netzwerk: Vollständig offline — kein Lizenzserver, kein Verbindungsaufbau nach Hause (Phone-Home)
- Fallback: Abgelaufene/ungültige Tokens setzen das Gateway automatisch auf OBSERVE zurück
Build-Watermarking
Jedes Binary bettet zur Kompilierzeit einen forensischen Fingerabdruck zur Nachverfolgbarkeit ein.
customer_tag enthalten, das mit dem eingebetteten Tag des Builds übereinstimmen muss. Nicht übereinstimmende Tags führen dazu, dass die Lizenz fehlschlägt — so wird die Wiederverwendung von Lizenzen über verschiedene Kunden-Builds hinweg verhindert.
Netzwerkhärtung (Network hardening)
Kubernetes
NetworkPolicy beschränkt den Datenverkehr: Nur das Gateway akzeptiert externe Verbindungen. Die API ist ausschließlich cluster-intern. Admin-Tools werden als einmalige Jobs ausgeführt, nicht als persistente Deployments.
HTTP-Limits
Max. Body Size: 1 MiB (konfigurierbar). Request Timeout: 30 Sekunden. OPA Connect Timeout: 3 Sekunden. OPA Read Timeout: 10 Sekunden. Alles über Umgebungsvariablen konfigurierbar.
Container-Sicherheit
Non-root-Benutzer (65534), schreibgeschütztes (read-only) Root-Dateisystem, alle Capabilities entfernt, seccomp RuntimeDefault Profil. Keine Privilegienerweiterung erlaubt.
Infrastruktur & Gerichtsbarkeit
Die Infrastruktur, die diese Website unterstützt, wird in der Schweiz gehostet und operiert unter Schweizerischer Gerichtsbarkeit.
- Datenhosting innerhalb der Schweiz
- Unterliegt dem Schweizerischen Rechtsrahmen
- Keine absichtliche Übermittlung von Daten außerhalb der Schweiz
- Keine Verhaltensanalysen (Behavioral Analytics) durch Dritte
Erkunden Sie die Bereitstellungsoptionen (Deployment Options)
Die Sicherheitsarchitektur ist über alle Editionen hinweg konsistent. Wählen Sie den Bereitstellungsumfang (Deployment Scope), der Ihren Governance-Anforderungen entspricht.
Editionen erkunden