Nota architektury bezpieczeństwa
Właściwości strukturalne, założenia i zachowanie w przypadku awarii OmegaOS™ Kernel.
Zakres i założenia
Ta strona opisuje strukturalne właściwości bezpieczeństwa runtime OmegaOS™ Kernel zgodnie z projektem. Obejmuje silnik decyzyjny, dziennik audytu i model wdrożenia operatora.
Założenia
- Operator kontroluje środowisko wdrożeniowe.
- Operator odpowiada za perimetr sieciowy, hardening systemu operacyjnego i kontrolę dostępu do wdrożenia.
- Runtime nie wykonuje żadnych wychodzących wywołań sieciowych podczas ewaluacji polityk.
- OmegaOS™ Kernel domyślnie działa w trybie advisory-only. W trybach observe i shadow produkuje decyzje bez wykonywania działań downstream.
Czego ta strona nie obejmuje
- Federacja tożsamości warstwy aplikacyjnej (odpowiedzialność operatora).
- Podatności systemu operacyjnego hosta lub runtime kontenera (specyficzne dla wdrożenia).
- Ataki typu denial of service na warstwie sieciowej (kwestia infrastruktury).
- Wyniki testów penetracyjnych (niepublikowane publicznie).
Właściwości strukturalne
Domyślny tryb fail-closed
Gdy silnik polityk jest nieosiągalny lub ewaluacja kończy się błędem, bramka domyślnie przechodzi w tryb DENY w trybie enforce. Tryb fail-open nie jest dostępną konfiguracją.
Dziennik append-only
Usługi runtime mogą jedynie tworzyć nowe rekordy. Modyfikacja ani usuwanie wpisów w dzienniku nie jest możliwe. Wycofania tworzą nowe rekordy, nie usunięcia.
Izolacja danych wielodostępowych
Każde zapytanie jest filtrowane przez polityki izolacji na poziomie infrastruktury. Usługi runtime mają dostęp wyłącznie do rekordów należących do bieżącego kontekstu tenanta.
Projekt advisory-only
OmegaOS™ Kernel produkuje ustrukturyzowane decyzje, które informują operatorów ludzkich. Nie wykonuje autonomicznie działań downstream.
Zachowanie w przypadku awarii
Każda ścieżka awarii domyślnie przechodzi w stan najbardziej restrykcyjny. Żadnego cichego przyznania, żadnego syntetycznego zezwolenia.
| Scenariusz | Zachowanie |
|---|---|
| Silnik polityk nieosiągalny | DENY (tryb enforce) |
| Błąd wewnętrzny podczas ewaluacji | DENY (tryb enforce) |
| Wygasła licencja | Automatyczna degradacja do OBSERVE |
| Dowód bez ważnego podpisu | Oznaczony lub odrzucony przy przyjęciu |
Model izolacji tenantów
Izolacja danych na poziomie infrastruktury jest wymuszana na poziomie rekordu. Nawet jeśli atakujący uzyska możliwość wstrzyknięcia przez warstwę aplikacyjną, dostęp do danych między tenantami jest strukturalnie uniemożliwiony.
| Poziom dostępu | Izolacja | Używany przez |
|---|---|---|
| Administracyjny | Pełny dostęp | Narzędzia operatorskie, migracje |
| Runtime | Ograniczony do tenanta | Usługi aplikacyjne |
Integralność kryptograficzna
Uwierzytelnianie dowodów
Każdy element dowodowy jest kryptograficznie uwierzytelniany przy przyjęciu. Dowód przesłany bez ważnego podpisu może zostać oznaczony lub odrzucony — co dowodzi integralności danych na warstwie aplikacyjnej, niezależnie od szyfrowania transportu.
| Właściwość | Wartość |
|---|---|
| Uwierzytelnianie | Kod uwierzytelniania wiadomości |
| Separacja domen | Na kontekst bezpieczeństwa |
| Zakres | Na element dowodowy |
| Weryfikacja | Przy przyjęciu — przed decyzją |
Łańcuch dowodów
Każda decyzja jest włączana do struktury kryptograficznej append-only. Retroaktywna modyfikacja narusza weryfikację integralności. Dowody włączenia są weryfikowalne bez ujawniania innych decyzji.
Podpisy cyfrowe
Manifesty eksportu, licencje i atestacje buildów są podpisywane kryptograficznymi podpisami cyfrowymi. Weryfikacja jest w pełni offline.
Zaufane znaczniki czasu
Korzenie kryptograficzne są okresowo zakotwiczane w zewnętrznym Urzędzie Znakowania Czasem. Po skonfigurowaniu z kwalifikowanym TSA, znaczniki czasu mogą wspierać wymogi dowodowe dotyczące czasu zgodnie z ZertES i eIDAS. Skutki prawne zależą od jurysdykcji i kontekstu.
Granica operatora
Izolacja sieciowa
Tylko bramka akceptuje połączenia zewnętrzne. Usługi wewnętrzne nie są osiągalne z zewnątrz. Narzędzia administracyjne działają jako izolowane procesy, nie jako usługi persystentne.
Izolacja runtime
Wykonanie non-root, system plików read-only, zbędne uprawnienia usunięte. Brak ścieżki eskalacji uprawnień.
Kontrole żądań
Konfigurowalne limity rozmiaru żądań, timeouty połączeń i timeouty ewaluacji. Parametry dostosowywalne do każdego wdrożenia.
Weryfikacja formalna
Pięć niezmienników systemu jest formalnie weryfikowanych przy użyciu matematycznego sprawdzania modeli nad skończonymi przestrzeniami stanów. To wyczerpująca eksploracja ograniczonej przestrzeni stanów — nie dowodzenie twierdzeń.
- INDETERMINATE jest prymitywem — ALLOW/DENY wymagają jawnej rozdzielczości
- Dziennik append-only — bez modyfikacji, bez usuwania
- Determinizm — te same dane wejściowe dają te same dane wyjściowe
- Izolacja tenantów — brak dostępu do danych między tenantami
- Brak automatycznych nieodwracalnych działań — wymagany człowiek w pętli
| Zakres | Objęte niezmienniki |
|---|---|
| Rozdzielczość decyzji | Determinizm, logika tri-state, izolacja tenantów |
| Dziennik audytu | Append-only, łańcuch integralności, brak mutacji |
| Model kombinowany | Wszystkie 5 niezmienników łącznie |
Uwierzytelnianie API
- Poświadczenia: Kryptograficznie silne klucze API
- Przechowywanie: Bezpieczny hash
- Rotacja: Rotacja kluczy bez przestojów obsługiwana
- Mapowanie: Klucz API mapowany na kontekst tenanta dla izolacji danych
Weryfikacja licencji
- Metoda: Weryfikacja kryptograficzna
- Zarządzanie kluczami: Weryfikacja wbudowanym kluczem
- Sieć: W pełni offline
- Fallback: Łagodna degradacja po wygaśnięciu
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
Powiązana dokumentacja
Technical Artifact opisuje semantykę runtime. Editions obejmuje zakres wdrożenia.