Säkerhet genom struktur, inte genom patchar

OmegaOS™ Kernel är fail-closed som standard, tilläggsbaserad genom struktur och enbart rådgivande genom design. Varje åtgärd är strukturell — inbyggd i schemat, körtiden och distributionsmodellen.

Hotmodell

🔒

Obehörig dataåtkomst

Motverkas av Row-Level Security (RLS) som tillämpas per klient på Postgres-nivå, plus API-nyckelautentisering med ~285 bitars entropi.

📓

Manipulering av revisionsspår

Motverkas av tilläggsbaserat schema. Körtidstjänster (hovo_app) kan enbart utföra INSERT — ingen UPDATE eller DELETE på journaltabeller. Återkallelser skapar nya poster.

🔑

Licensförbigående

Motverkas av Ed25519 offlineverifiering. Publik nyckel inbäddad vid kompileringstid. Ingen licensserver, inget nätverksberoende. Manipulerade tokens misslyckas vid kryptografisk kontroll.

🔎

Läckta byggen

Motverkas av byggfingeravtryck. Varje binärfil bäddar in git_sha + build_timestamp + customer_tag vid kompileringstid. Fingeravtrycket visas i hälsokontroller och beslutsloggar.

Fail-closed som standard

När uppströms-PDP:n är onåbar eller utvärderingen misslyckas, nekar gatewayen som standard i tillämpningsläge. Detta styrs av OPA_FAIL_MODE, som har standardvärdet closed.

Fail-open-system ger tyst åtkomst när de går sönder. Fail-closed-system blockerar åtkomst när de går sönder. För compliance-känsliga miljöer är fail-closed den säkra standarden.

Scenario	Fail-Closed	Fail-Open
OPA onåbar	403 Forbidden	Syntetisk tillåtelse (loggad)
Internt fel	403 Forbidden	Syntetisk tillåtelse (loggad)
Licens utgången	Automatisk nedgradering till OBSERVE

Enbart rådgivande design. OmegaOS™ Kernel producerar strukturerade beslut som informerar mänskliga operatörer. Den utför inte autonomt nedströmsåtgärder. I observations- och skuggläge är den rent rådgivande.

Row-Level Security

Varje fråga körs genom Postgres RLS-policyer. Rollen hovo_app kan enbart komma åt rader som matchar den aktuella klientkontexten, som sätts i början av varje transaktion.

Även om en angripare lyckas med SQL-injektion genom applikationslagret kan de inte komma åt en annan klients data — databasen upprätthåller isolering på radnivå.

Roll	RLS	Används av
hovo_admin	BYPASSRLS	CLI-verktyg, migreringar
hovo_app	Tillämpas	hovo-api, hovo-gateway

Nyckelgaranti: hovo_admin används aldrig av körtidstjänster. Den är begränsad till operatörsverktyg som körs separat.

Tilläggsbaserad journal

Sex journaltabeller är INSERT-only för körtidsrollen. Inget beslut kan ändras retroaktivt.

 -- Behörigheter för hovo_app (körtidstjänster): GRANT INSERT ON
decisions,
  proofs,
  proof_revocations,
  decision_events,
  decision_proofs,
  claims
TO hovo_app;
-- Ingen UPDATE eller DELETE beviljad.
-- Återkallelser är nya INSERT-poster, inte borttagningar.
-- Fullständig historik finns alltid tillgänglig för revision. 

API-nyckelautentisering

Format: delk_ + 48 alfanumeriska tecken (~285 bitars entropi)
Lagring: bcrypt-hashad (kostnad 12) — klartext visas en gång vid generering
Rotation: Maximalt 2 haschar per klient för nyckelrotation utan driftstopp
Mappning: API-nyckel → tenant_id är den enda sanningskällan för RLS-kontext

Licensverifiering

Algoritm: Ed25519-signaturverifiering
Nyckelhantering: Publik nyckel inbäddad i binärfil vid kompileringstid
Nätverk: Helt offline — ingen licensserver, ingen hemringning
Reserv: Utgångna/ogiltiga tokens nedgraderar gatewayen automatiskt till OBSERVE

Byggvattenmärkning

Varje binärfil bäddar in ett forensiskt fingeravtryck vid kompileringstid för spårbarhet.

 # Fingeravtryck inbäddat vid bygge: { "git_sha": "abc12345",
"build_timestamp": 1739712000,
"customer_tag": "acme-corp" } # Visas i: # - /gateway/health-svar # - /api/v1/health-svar # - Strukturerade loggar för varje beslut 

Kundtaggbindning: Licenser kan valfritt innehålla en customer_tag som måste matcha byggets inbäddade tagg. Felaktiga taggar gör att licensen misslyckas — vilket förhindrar licensåteranvändning mellan olika kundbyggen.

Nätverkshärdning

Kubernetes

NetworkPolicy begränsar trafik: enbart gatewayen accepterar externa anslutningar. API:t är enbart klusterinternt. Administratörsverktyg körs som engångsjobb, inte beständiga distributioner.

HTTP-begränsningar

Maximal body-storlek: 1 MiB (konfigurerbar). Timeout för förfrågan: 30 sekunder. OPA connect-timeout: 3 sekunder. OPA read-timeout: 10 sekunder. Alla konfigurerbara via miljövariabler.

Containersäkerhet

Icke-root-användare (65534), skrivskyddat rotfilsystem, alla capabilities borttagna, seccomp RuntimeDefault-profil. Ingen privilegieeskalering tillåts.

Infrastruktur & jurisdiktion

Infrastrukturen som stödjer denna webbplats hostas i Schweiz och verkar under schweizisk jurisdiktion.

Data hostas inom Schweiz
Lyder under schweizisk lagstiftning
Ingen avsiktlig överföring av data utanför Schweiz
Inga tredjepartsverktyg för beteendeanalys

Utforska distributionsalternativ

Säkerhetsarkitekturen är konsekvent i alla editioner. Välj den distributionsomfattning som matchar dina styrningskrav.

Utforska editioner