Sikkerhed gennem struktur, ikke gennem patches

OmegaOS™ Kernel er fail-closed som standard, append-only af struktur og rådgivende af design. Hver afhjælpning er strukturel — indbygget i skemaet, runtime-miljøet og implementeringsmodellen.

Trusselmodel

🔒

Uautoriseret dataadgang

Afhjulpet af Row-Level Security (RLS) håndhævet per lejer på Postgres-niveau, plus API-nøgleautentificering med ~285 bits entropi.

📓

Manipulation af revisionsspor

Afhjulpet af append-only-skema. Runtime-tjenester (hovo_app) kan kun udføre INSERT — ingen UPDATE eller DELETE på hovedbogstabeller. Tilbagekaldelser opretter nye poster.

🔑

Licensomgåelse

Afhjulpet af Ed25519 offline-verifikation. Offentlig nøgle indlejret ved kompileringstidspunktet. Ingen licensserver, ingen netværksafhængighed. Manipulerede tokens fejler kryptografisk kontrol.

🔎

Lækkede builds

Afhjulpet af build-fingeraftryk. Hver binærfil indlejrer git_sha + build_timestamp + customer_tag ved kompileringstidspunktet. Fingeraftrykket vises i sundhedstjek og beslutningslogfiler.

Fail-closed som standard

Når upstream PDP er utilgængelig, eller evalueringen fejler, anvender gatewayen DENY i håndhævelsestilstand som standard. Dette styres af OPA_FAIL_MODE, som har standardværdien closed.

Fail-open-systemer giver tavst adgang, når de fejler. Fail-closed-systemer blokerer adgang, når de fejler. For compliance-følsomme miljøer er fail-closed den sikre standard.

Scenarie	Fail-closed	Fail-open
OPA utilgængelig	403 Forbidden	Syntetisk tilladelse (logget)
Intern fejl	403 Forbidden	Syntetisk tilladelse (logget)
Licens udløbet	Auto-nedgradering til OBSERVE

Rådgivende design. OmegaOS™ Kernel producerer strukturerede beslutninger, der informerer menneskelige operatører. Den eksekverer ikke selvstændigt downstream-handlinger. I observerings- og skyggetilstand er den rent rådgivende.

Row-Level Security

Hver forespørgsel kører gennem Postgres RLS-politikker. Rollen hovo_app kan kun tilgå rækker, der matcher den aktuelle lejerkontekst, som sættes i starten af hver transaktion.

Selv hvis en angriber opnår SQL-injektion gennem applikationslaget, kan de ikke tilgå en anden lejers data — databasen håndhæver isolation på rækkeniveau.

Rolle	RLS	Anvendt af
hovo_admin	BYPASSRLS	CLI-værktøjer, migreringer
hovo_app	Håndhævet	hovo-api, hovo-gateway

Nøglegaranti: hovo_admin bruges aldrig af runtime-tjenester. Den er begrænset til operatørværktøjer, der kører separat.

Append-only hovedbog

Seks hovedbogstabeller er INSERT-only for runtime-rollen. Ingen beslutning kan ændres med tilbagevirkende kraft.

 -- Tildelinger for hovo_app (runtime-tjenester): GRANT INSERT ON
decisions,
  proofs,
  proof_revocations,
  decision_events,
  decision_proofs,
  claims
TO hovo_app;
-- Ingen UPDATE eller DELETE tildelt.
-- Tilbagekaldelser er nye INSERT-poster, ikke sletninger.
-- Fuld historik er altid tilgængelig til revision. 

API-nøgleautentificering

Format: delk_ + 48 alfanumeriske tegn (~285 bits entropi)
Lagring: bcrypt-hashet (cost 12) — klartekst vises kun én gang ved generering
Rotation: Maksimalt 2 hashes per lejer til nøglerotation uden nedetid
Mapping: API-nøgle → tenant_id er den eneste sandhedskilde for RLS-kontekst

Licensverifikation

Algoritme: Ed25519-signaturverifikation
Nøglehåndtering: Offentlig nøgle indlejret i binærfil ved kompileringstidspunktet
Netværk: Fuldt offline — ingen licensserver, ingen phone-home
Fallback: Udløbne/ugyldige tokens auto-nedgraderer gateway til OBSERVE

Build-vandmærkning

Hver binærfil indlejrer et forensisk fingeraftryk ved kompileringstidspunktet for sporbarhed.

 # Fingeraftryk indlejret ved build: { "git_sha": "abc12345",
"build_timestamp": 1739712000,
"customer_tag": "acme-corp" } # Vises i: # - /gateway/health-svar # - /api/v1/health-svar # - Strukturerede logfiler for hver beslutning 

Kundetag-binding: Licenser kan valgfrit inkludere et customer_tag, der skal matche buildets indlejrede tag. Uoverensstemmende tags får licensen til at fejle — hvilket forhindrer licensgenbrug på tværs af forskellige kundebuilds.

Netværkshærdning

Kubernetes

NetworkPolicy begrænser trafik: kun gatewayen accepterer eksterne forbindelser. API'en er kun intern i klusteret. Administrationsværktøjer kører som enkeltstående Jobs, ikke persistente deployments.

HTTP-begrænsninger

Maks. body-størrelse: 1 MiB (konfigurerbar). Forespørgselstimeout: 30 sekunder. OPA-forbindelsestimeout: 3 sekunder. OPA-læsetimeout: 10 sekunder. Alt konfigurerbart via miljøvariabler.

Containersikkerhed

Non-root-bruger (65534), skrivebeskyttet rodfilsystem, alle capabilities droppet, seccomp RuntimeDefault-profil. Ingen privilegieeskalering tilladt.

Infrastruktur og jurisdiktion

Infrastrukturen bag dette website hostes i Schweiz og opererer under schweizisk jurisdiktion.

Data hostet inden for Schweiz
Underlagt schweizisk retsramme
Ingen tilsigtet overførsel af data uden for Schweiz
Ingen tredjeparts adfærdsanalyse

Udforsk implementeringsmuligheder

Sikkerhedsarkitekturen er konsistent på tværs af alle udgaver. Vælg det implementeringsomfang, der matcher dine styringsforhold.

Udforsk udgaver