Bilješka o sigurnosnoj arhitekturi
Strukturalna svojstva, pretpostavke i ponašanje pri greškama OmegaOS™ Kernel.
Opseg i pretpostavke
Ova stranica opisuje strukturalna sigurnosna svojstva OmegaOS™ Kernel runtimea kako je dizajniran. Pokriva motor politika, revizijski protokol i model implementacije operatera.
Pretpostavke
- Operater kontrolira okruženje implementacije.
- Operater je odgovoran za mrežni perimetar, hardening host OS-a i kontrolu pristupa implementaciji.
- Runtime ne upućuje odlazne mrežne pozive tijekom evaluacije politika.
- OmegaOS™ Kernel je zadano isključivo savjetodavnog karaktera. U observe i shadow načinima proizvodi odluke bez izvršavanja downstream radnji.
Što ova stranica ne pokriva
- Federacija identiteta na aplikacijskom sloju (odgovornost operatera).
- Ranjivosti host OS-a ili container runtimea (specifično za implementaciju).
- Uskraćivanje usluge na mrežnom sloju (infrastrukturna problematika).
- Rezultati testova penetracije (nisu javno objavljeni).
Strukturalna svojstva
Fail-closed zadano
Kada motor politika nije dostupan ili evaluacija ne uspije, pristupnik zadano vraća DENY u enforce načinu. Fail-open nije dostupna konfiguracija.
Append-only protokol
Runtime servisi mogu samo stvarati nove zapise. Nema izmjena ili brisanja unosa protokola. Opozivi stvaraju nove zapise, a ne brisanja.
Višekorisnička izolacija podataka
Svaki upit filtrira se kroz politike izolacije na razini infrastrukture. Runtime servisi pristupaju samo zapisima koji pripadaju trenutačnom kontekstu zakupca.
Savjetodavni karakter dizajnom
OmegaOS™ Kernel proizvodi strukturirane odluke koje informiraju ljudske operatere. Ne izvršava samostalno downstream radnje.
Ponašanje pri greškama
Svaki put do greške zadano vodi u najrestriktivnije stanje. Nema tihog odobrenja, nema sintetičkog dopuštenja.
| Scenarij | Ponašanje |
|---|---|
| Motor politika nedostupan | DENY (enforce način) |
| Interna pogreška tijekom evaluacije | DENY (enforce način) |
| Licencija istekla | Automatska degradacija na OBSERVE |
| Dokaz bez valjanog potpisa | Označeno ili odbijeno pri ingestionu |
Model izolacije zakupca
Izolacija podataka na razini infrastrukture nameće se na razini zapisa. Čak i ako napadač postigne injekciju kroz aplikacijski sloj, pristup podacima između zakupaca je strukturno spriječen.
| Razina pristupa | Izolacija | Koristi |
|---|---|---|
| Administrativna | Potpuni pristup | Operaterski alati, migracije |
| Runtime | Ograničena na zakupca | Aplikacijski servisi |
Kriptografski integritet
Autentifikacija dokaza
Svaki dokaz kriptografski se autentificira pri ingestionu. Dokaz koji pristiže bez valjanog potpisa može biti označen ili odbijen — čime se dokazuje integritet podataka na aplikacijskom sloju, neovisno o enkripciji transporta.
| Svojstvo | Vrijednost |
|---|---|
| Autentifikacija | Kôd za autentifikaciju poruke |
| Odvajanje domene | Po sigurnosnom kontekstu |
| Opseg | Po stavci dokaza |
| Verifikacija | Pri ingestionu — prije odluke |
Lanac dokaza
Svaka odluka ulančava se u append-only kriptografsku strukturu. Retroaktivna izmjena narušava verifikaciju integriteta. Dokazi uključenosti su provjerljivi bez otkrivanja ostalih odluka.
Digitalni potpisi
Manifesti izvoza, licencije i atestacije builda potpisani su kriptografskim digitalnim potpisima. Verifikacija je potpuno izvanmrežna.
Pouzdano označavanje vremenskim žigom
Kriptografski korijeni periodično se sidre na vanjski Authority za označavanje vremenskim žigom. Kada je konfigurirano s kvalificiranim TSA-om, vremenski žigovi mogu poduprijeti zahtjeve za dokaznim vremenskim okvirom prema ZertES-u i eIDAS-u. Pravni učinak ovisi o jurisdikciji i kontekstu.
Granica operatera
Mrežna izolacija
Samo pristupnik prima vanjske veze. Interni servisi nisu dostupni izvana. Administratorski alati pokreću se kao izolirani procesi, ne kao stalne usluge.
Runtime izolacija
Izvršavanje bez root prava, datotečni sustav samo za čitanje, nepotrebne mogućnosti uklonjene. Nema puta za eskalaciju ovlaštenja.
Kontrole zahtjeva
Konfigurirajuća ograničenja za veličinu zahtjeva, vremenska ograničenja veze i vremenska ograničenja evaluacije. Parametri su prilagodljivi za svaku implementaciju.
Formalna verifikacija
Pet invarijanti sustava formalno je verificirano matematičkom provjerom modela nad konačnim prostorima stanja. Radi se o iscrpnom istraživanju ograničenog prostora stanja — ne o dokazivanju teorema.
- INDETERMINATE je primitiv — ALLOW/DENY zahtijevaju eksplicitnu rezoluciju
- Append-only protokol — nema izmjena, nema brisanja
- Determinizam — isti ulazi proizvode iste izlaze
- Izolacija zakupca — nema pristupa podacima između zakupaca
- Nema automatske nepovratne radnje — potreban je čovjek u petlji
| Opseg | Pokrivene invarijante |
|---|---|
| Rezolucija odluka | Determinizam, tri-state logika, izolacija zakupca |
| Revizijski protokol | Append-only, lanac integriteta, bez mutacije |
| Kombinirani model | Svih 5 invarijanti kombinirano |
API autentifikacija
- Vjerodajnice: Kriptografski jaki API ključevi
- Pohrana: Sigurno hashiran
- Rotacija: Rotacija ključeva bez prekida podržana
- Mapiranje: API ključ se povezuje s kontekstom zakupca za izolaciju podataka
Provjera licencije
- Metoda: Kriptografska verifikacija
- Upravljanje ključevima: Ugrađena verifikacija ključem
- Mreža: Potpuno izvanmrežno
- Povratni mehanizam: Postupna degradacija pri isteku
Infrastruktura i jurisdikcija
Infrastruktura koja podržava ovu web-stranicu smještena je u Švicarskoj i djeluje pod švicarskom jurisdikcijom.
- Podaci pohranjeni u Švicarskoj
- Podliježe švicarskom pravnom okviru
- Nema namjernog prijenosa podataka izvan Švicarske
- Nema analitike ponašanja trećih strana
Povezana dokumentacija
Tehnički artefakt opisuje runtime semantiku. Izdanja pokrivaju opseg implementacije.