Architektura bezpieczeństwa

OmegaOS™ Kernel jest zaprojektowany tak, aby każda decyzja, każdy dowód i każdy dziennik audytu pozostały integralne — nawet w przypadku skompromitowania warstwy aplikacyjnej.

Model zagrożeń

Projektujemy pod kątem trzech klas ataku. Każda ma dedykowaną kontrolę strukturalną.

Skompromitowana aplikacja

Rola runtime (hovo_app) nie może aktualizować ani usuwać rekordów audytu. Nawet w przypadku SQL injection, atakujący nie może modyfikować istniejących decyzji, dowodów ani intrekkingów — baza danych wymusza INSERT-only.

Eskalacja uprawnień tenanta

Postgres RLS gwarantuje izolację per-tenant na poziomie bazy danych. Żadne zapytanie warstwy aplikacyjnej nie może uzyskać dostępu do danych innego tenanta. Izolacja jest strukturalna, nie zależna od logiki aplikacji.

Nadużycie licencji

Tokeny licencyjne Ed25519 mogą opcjonalnie wiązać tag klienta z tagiem builda. Niezgodne tagi unieważniają licencję. Brak serwera licencyjnego = brak phone-home = brak zdalnego unieważniania.

Model ról bazy danych

Separacja uprawnień

Dwie role bazy danych z jasno zdefiniowanymi granicami. Żadna usługa runtime nie działa z uprawnieniami administratora. Narzędzia operatorskie działają jako oddzielne procesy.

Rola	INSERT	SELECT	UPDATE	DELETE
hovo_app	✓	✓	✗	✗
hovo_admin	✓	✓	✓	✓

Row-Level Security (RLS)

Każde zapytanie przechodzi przez polityki Postgres RLS. Rola hovo_app może uzyskać dostęp wyłącznie do wierszy odpowiadających bieżącemu kontekstowi tenanta, ustawianemu na początku każdej transakcji.

Nawet w przypadku SQL injection przez warstwę aplikacyjną, atakujący nie może uzyskać dostępu do danych innego tenanta — baza danych wymusza izolację na poziomie wierszy.

Rola	RLS	Wykorzystanie
hovo_admin	BYPASSRLS	Narzędzia CLI, migracje
hovo_app	Egzekwowane	hovo-api, hovo-gateway

Gwarancja: hovo_admin nigdy nie jest wykorzystywane przez usługi runtime. Jest ograniczone do narzędzi operatorskich uruchamianych oddzielnie.

Dziennik append-only

Sześć tabel dziennika jest ograniczonych do INSERT-only dla roli runtime. Żadna decyzja nie może zostać zmieniona wstecznie.

 -- Uprawnienia dla hovo_app (usługi runtime): GRANT INSERT ON
decisions,
  proofs,
  proof_revocations,
  decision_events,
  decision_proofs,
  claims
TO hovo_app;
-- Brak GRANT na UPDATE ani DELETE.
-- Intrekkowania są nowymi rekordami INSERT, nie usunięciami.
-- Pełna historia jest zawsze dostępna dla audytów. 

Uwierzytelnianie API-key

Format: delk_ + 48 znaków alfanumerycznych (~285 bitów entropii)
Przechowywanie: hash bcrypt (cost 12) — tekst jawny wyświetlany jednorazowo przy tworzeniu
Rotacja: Maks. 2 hashe per tenant dla zero-downtime rotacji kluczy
Przypisanie: API-key → tenant_id jest jedynym źródłem prawdy dla kontekstu RLS

Weryfikacja licencji

Algorytm: Weryfikacja podpisu Ed25519
Zarządzanie kluczami: Klucz publiczny osadzony w binarnym pliku w czasie kompilacji
Sieć: W pełni offline — brak serwera licencyjnego, brak phone-home
Fallback: Wygasłe/nieprawidłowe tokeny automatycznie przełączają bramkę na tryb OBSERVE

Build-watermarking

Każdy plik binarny osadza w czasie kompilacji odcisk forensyczny dla identyfikowalności.

 # Odcisk osadzony w czasie buildu: { "git_sha": "abc12345",
"build_timestamp": 1739712000,
"customer_tag": "acme-corp" } # Pojawia się w: # - /gateway/health response # - /api/v1/health response # - Strukturyzowanych logach dla każdej decyzji 

Wiązanie tagu klienta: Licencje mogą opcjonalnie zawierać customer_tag, który musi odpowiadać osadzonemu tagowi builda. Niezgodne tagi unieważniają licencję — zapobiegając ponownemu wykorzystaniu licencji między różnymi buildami klientów.

Hardening sieciowy

Kubernetes

NetworkPolicy ogranicza ruch: tylko bramka akceptuje połączenia zewnętrzne. API jest wyłącznie wewnątrzklasterowe. Narzędzia administratorskie uruchamiane jako jednorazowe joby, nie jako persistentne deploymenty.

Limity HTTP

Maks. body size: 1 MiB (konfigurowalny). Request timeout: 30 sekund. OPA connect timeout: 3 sekundy. OPA read timeout: 10 sekund. Wszystko konfigurowalne przez zmienne środowiskowe.

Bezpieczeństwo kontenerów

Użytkownik non-root (65534), system plików root read-only, wszystkie capabilities usunięte, profil seccomp RuntimeDefault. Brak dozwolonej eskalacji uprawnień.

Infrastruktura i jurysdykcja

Infrastruktura obsługująca tę stronę jest hostowana w Szwajcarii i działa w ramach jurysdykcji szwajcarskiej.

Hosting danych w Szwajcarii
Podlega szwajcarskim ramom prawnym
Brak celowego transferu danych poza Szwajcarię
Brak analityk behawioralnych podmiotów trzecich

Poznaj opcje wdrożenia

Architektura bezpieczeństwa jest spójna we wszystkich edycjach. Wybierz zakres wdrożenia odpowiadający Państwa wymogom governance.

Poznaj edycje