Bezpečnost strukturou, nikoli záplatou

OmegaOS™ Kernel je fail-closed ve výchozím stavu, append-only strukturou a advisory-only záměrem. Každé opatření je strukturální — zabudované do schématu, runtime a modelu nasazení.

Model hrozeb

🔒

Neoprávněný přístup k datům

Zmírněno Row-Level Security (RLS) vynucenou na úrovni tenanta v Postgresu, plus autentizace API klíčem s ~285 bity entropie.

📓

Manipulace s auditní stopou

Zmírněno append-only schématem. Runtime služby (hovo_app) mohou pouze INSERT — žádný UPDATE nebo DELETE na tabulkách protokolu. Odvolání vytvářejí nové záznamy.

🔑

Obejití licence

Zmírněno offline ověřením Ed25519. Veřejný klíč vestavěný v době kompilace. Žádný licenční server, žádná síťová závislost. Manipulované tokeny selhávají při kryptografické kontrole.

🔎

Úniky buildů

Zmírněno fingerprintingem buildu. Každý binární soubor obsahuje git_sha + build_timestamp + customer_tag v době kompilace. Fingerprint se objevuje v health checích a rozhodovacích protokolech.

Fail-closed jako výchozí

Když je upstream PDP nedostupný nebo evaluace selže, brána v režimu enforce vrací výchozí DENY. Toto je řízeno OPA_FAIL_MODE, jehož výchozí hodnota je closed.

Fail-open systémy tiše udělují přístup, když selžou. Fail-closed systémy blokují přístup, když selžou. Pro prostředí citlivá na soulad je fail-closed bezpečnou výchozí hodnotou.

Scénář	Fail-Closed	Fail-Open
OPA nedostupný	403 Forbidden	Syntetické povolení (zalogováno)
Interní chyba	403 Forbidden	Syntetické povolení (zalogováno)
Licence vypršela	Automatická degradace na OBSERVE

Advisory-only záměrem. OmegaOS™ Kernel produkuje strukturovaná rozhodnutí, která informují lidské operátory. Neexekvuje autonomně downstream akce. V režimech observe a shadow je čistě poradní.

Row-Level Security

Každý dotaz prochází Postgres RLS politikami. Role hovo_app může přistupovat pouze k řádkům odpovídajícím aktuálnímu kontextu tenanta, nastaveným na začátku každé transakce.

I pokud útočník dosáhne SQL injection přes aplikační vrstvu, nemůže přistoupit k datům jiného tenanta — databáze vynucuje izolaci na úrovni řádků.

Role	RLS	Používá
hovo_admin	BYPASSRLS	CLI nástroje, migrace
hovo_app	Vynuceno	hovo-api, hovo-gateway

Klíčová záruka: hovo_admin není nikdy používán runtime službami. Je omezena na operátorské nástroje, které běží odděleně.

Append-only protokol

Šest tabulek protokolu je INSERT-only pro runtime roli. Žádné rozhodnutí nemůže být retroaktivně změněno.

 -- Oprávnění pro hovo_app (runtime služby): GRANT INSERT ON
decisions,
  proofs,
  proof_revocations,
  decision_events,
  decision_proofs,
  claims
TO hovo_app;
-- Žádný UPDATE nebo DELETE není udělen.
-- Odvolání jsou nové INSERT záznamy, nikoli mazání.
-- Úplná historie je vždy k dispozici pro audit. 

Autentizace API klíčem

Formát: delk_ + 48 alfanumerických znaků (~285 bitů entropie)
Uložení: bcrypt hashováno (cost 12) — plaintext zobrazen jednou při generování
Rotace: Maximálně 2 hashe na tenanta pro rotaci klíčů bez výpadku
Mapování: API klíč → tenant_id je jediný zdroj pravdy pro RLS kontext

Ověření licence

Algoritmus: Ověření podpisu Ed25519
Správa klíčů: Veřejný klíč vestavěn do binárního souboru v době kompilace
Síť: Plně offline — žádný licenční server, žádný phone-home
Fallback: Vypršelé/neplatné tokeny automaticky degradují bránu na OBSERVE

Build watermarking

Každý binární soubor obsahuje forenzní otisk v době kompilace pro sledovatelnost.

 # Otisk vložený při buildu: { "git_sha": "abc12345",
"build_timestamp": 1739712000,
"customer_tag": "acme-corp" } # Zobrazuje se v: # - odpovědi /gateway/health # - odpovědi /api/v1/health # - Strukturovaných protokolech pro každé rozhodnutí 

Vazba klientského tagu: Licence mohou volitelně obsahovat customer_tag, který se musí shodovat s vloženým tagem buildu. Neshoda tagů způsobí selhání licence — čímž se zabrání opětovnému použití licence napříč různými buildy zákazníků.

Síťové zabezpečení

Kubernetes

NetworkPolicy omezuje provoz: pouze brána přijímá externí připojení. API je pouze cluster-interní. Administrátorské nástroje běží jako jednorázové Jobs, nikoli trvalá nasazení.

HTTP limity

Maximální velikost těla: 1 MiB (konfigurovatelné). Timeout požadavku: 30 sekund. OPA connect timeout: 3 sekundy. OPA read timeout: 10 sekund. Vše konfigurovatelné přes proměnné prostředí.

Zabezpečení kontejneru

Non-root uživatel (65534), read-only kořenový souborový systém, všechny capabilities odstraněny, seccomp RuntimeDefault profil. Žádná eskalace oprávnění není povolena.

Infrastruktura a jurisdikce

Infrastruktura podporující tyto webové stránky je hostována ve Švýcarsku a operuje pod švýcarskou jurisdikcí.

Data hostována v rámci Švýcarska
Podléhá švýcarskému právnímu rámci
Žádný úmyslný přenos dat mimo Švýcarsko
Žádné behaviorální analytiky třetích stran

Prozkoumejte možnosti nasazení

Bezpečnostní architektura je konzistentní napříč všemi edicemi. Zvolte rozsah nasazení odpovídající Vašim požadavkům na governance.

Prozkoumat edice