Roolipohjainen pääsynhallinta puolustuksen C2-järjestelmissä: suunnittelu ja toteutus

Pääsynhallinta puolustuksen C2-ohjelmistossa ei ole kehityksen loppupäässä lisätty ominaisuus. Se on perustavanlaatuinen arkkitehtuurinen päätös, joka määrää, kuka voi nähdä mitä tietoja, kuka voi antaa mitä komentoja ja miten nämä päätökset toteutetaan järjestelmän jokaisella tasolla — API-päätepisteistä tietokantakyselyihin ja WebSocket-tilauksiin. Virheiden tekeminen tarkoittaa joko luokiteltujen tietojen paljastamista luvattomille käyttäjille tai operaattorien estämistä, jotka tarvitsevat reaaliaikaista tilannetietoisuutta aikakrittiisiin päätöksiin.

Tavallinen roolipohjainen pääsynhallinta (RBAC), sellaisena kuin se on toteutettu kaupallisissa identiteettipalveluntarjoajissa kuten Keycloak tai Azure AD, kattaa rooli-käyttöoikeus-kartoituksen riittävästi yrityssovellusten osalta. Puolustuksen C2-järjestelmät vaativat lisäulottuvuuden: luokitustasot ja osastot. Käyttäjä voi olla todennettu ja hänellä voi olla oikea rooli (esim. "operaattori"), mutta häneltä voidaan silti evätä pääsy tiettyyn jälkeen, koska se on merkitty luokituksella tai osastolla, johon käyttäjällä ei ole selvitystä. Tämä on tietotarveperiaate teknisessä muodossa.

RBAC vs ABAC: Kumpi malli sopii puolustuksen C2-järjestelmiin

Puhdas RBAC osoittaa oikeudet rooleille ja roolit käyttäjille. "Pataljoonan S2" -rooli antaa pääsyn tiedustelukerroksiin; "Logistiikkavirkailija" -rooli antaa pääsyn toimitusketjutietoihin. Tämä malli on yksinkertainen toteuttaa ja auditoida, mutta se ei pysty ilmaisemaan hienojakoisia datarajoituksia ilman rooli-eksplosioita — luomatta erillistä roolia jokaiselle mahdolliselle tietoluokituskombinaatiolle.

Attribuuttipohjainen pääsynhallinta (ABAC) arvioi pääsypäätökset kohteen (käyttäjä), resurssin (tietoobjekti), toiminnon ja ympäristön (aika, verkkokonteksti) attribuuttien perusteella. ABAC-mallissa pääsy jälkeen myönnetään jos: käyttäjän turvaluokitus on suurempi tai yhtä suuri kuin jäljen luokitustaso JA käyttäjä omistaa kaikki jälkeen liitetyt osasto-tagit JA käyttäjän nykyinen pääte on hyväksytyssä verkkosegmentissä.

Käytännössä puolustuksen C2-järjestelmät käyttävät hybridimallia: RBAC karkean roolin valvontaan (kuka pääsee mihin sovellusmoduuliin) ja ABAC hienojakoiseen tietosuodatukseen (mitkä moduulin tietueet käyttäjä voi nähdä). RBAC-taso toteutetaan todennusaikana JWT-väitteiden kautta; ABAC-taso toteutetaan kyselyaikana, kun datakerros soveltaa rivitason suojausta käyttäjän attribuuttijoukon perusteella.

Luokitustasot ja osastot

NATO-luokitustasot nousevassa järjestyksessä: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, TOP SECRET. Useimmat taktiset C2-järjestelmät toimivat SECRET-tasolla tai sen alapuolella, ja jotkut järjestelmät käsittelevät TOP SECRET / SCI -tietoja erillisissä verkkosaarekkeissa. Tietoobjektin luokitustaso on minimivaatimus sen käyttämiseen.

Osastot ovat ortogonaalisia luokitustasoihin nähden. SECRET-tasolle selvitetty käyttäjä ei välttämättä omista SIGINT- tai HUMINT-osastoa, edes SECRET-tasolla. SIGINT-sensorista johdettu jälki merkitään SIGINT-osastolla; vain kyseisen osaston omistavat käyttäjät näkevät jäljen COP:ssa riippumatta heidän kokonaisturvaluokituksestaan. Ohjelmistossa osastot toteutetaan merkkijono-tagien joukkona sekä tietueessa että käyttäjän attribuuttijoukossa; pääsy myönnetään vain kun tietueen osastojoukko on käyttäjän osastojoukon osajoukko.

Tietotarve lisää kolmannen ulottuvuuden: jopa oikealla turvaluokituksella ja osaston jäsenyydellä varustettu käyttäjä voidaan rajoittaa käyttämästä heidän nykyiseen tehtävänantoonsa liittymättömiä tietoja. Tämä on vaikeampi toteuttaa ohjelmallisesti, ja se toteutetaan usein ABAC-käytännön ja manuaalisten tietojen säilytysohjainten yhdistelmänä.

JWT-väiterakenne puolustuksen C2-järjestelmiin

JSON Web Tokenit kuljettavat käyttäjän identiteetin ja attribuuttiväitteet identiteettipalveluntarjoajan ja C2-sovelluspalveluiden välillä. Puolustussuuntautunut JWT-hyötykuormarakenne:

{
  "sub": "user-uuid-1234",
  "name": "Cpt. A. Smith",
  "roles": ["operator", "s2-officer"],
  "clearance": "SECRET",
  "compartments": ["SIGINT", "HUMINT"],
  "unit": "1-32-IN",
  "network_segment": "SIPRNET",
  "iat": 1746960000,
  "exp": 1746963600,
  "jti": "unique-token-id"
}

clearance-väite kantaa käyttäjän turvaluokitustason merkkijonona, joka kartoituu numeeriseen arvoon käytäntömoottorissa (UNCLASSIFIED=0, RESTRICTED=1, CONFIDENTIAL=2, SECRET=3, TOP SECRET=4). compartments-väite on osastomerkkijonojen taulukko. network_segment-väite kantaa verkkokontekstin — SIPRNET, NIPRNET tai tehtäväkohtainen verkkoidentiteetti — mahdollistaen ympäristöpohjaiset pääsypäätökset.

Tokenin voimassaoloajat puolustusjärjestelmissä ovat lyhyemmät kuin kaupalliset normit: 60 minuutin käyttötokeneita päivitystokenin rotaatiolla. Jokainen tokenin päivitys uudelleenvalidoidaan identiteettipalveluntarjoajan nykyistä attribuuttivarastoa vastaan varmistaen, että peruutetut turvaluokitukset tulevat voimaan yhden päivityssyklin sisällä.

Käytäntöjen valvontapisteet

Mikropalvelu-C2-arkkitehtuurissa pääsynhallinta on toteutettava useilla tasoilla — ei vain API-yhdyskäytävässä. Puolustuksen C2-järjestelmässä on tyypillisesti kolme käytäntöjen valvontapistettä:

API-yhdyskäytävä (karkea RBAC). Validoi JWT-allekirjoituksen ja voimassaolon. Hylkää pyynnöt virheellisillä tokeneilla. Reitittää pyynnöt sopivaan palveluun rooliväitteiden perusteella. Ei tee datakohtaisia pääsypäätöksiä.

Palvelutaso (ABAC-käytäntöjen arviointi). Jokaisella luokiteltua dataa käsittelevällä palvelulla on sisäänrakennettu käytäntöpäätöspiste. Ennen tietoobjektin palauttamista palvelu arvioi: käyttäjän turvaluokitus >= datan luokitustaso JA käyttäjän osastot ovat datan osastojen yläjoukko. Tarkistuksen epäonnistuneet objektit suodatetaan vastauksesta, eikä palauteta 403-virheenä — koska luokiteltujen tietueiden olemassaolo on usein itsessään luokiteltu.

Tietokantaso (rivitason suojaus). PostgreSQL:n rivitason suojauskäytännöt (RLS) toteuttavat datatason rajoitukset tietokannassa itsessään tarjoten puolustuskerroksen sovelluslogiikan virheitä vastaan. Vaikka palvelussa olisi virhe käytäntöarvioinnissa, tietokantaso estää suodattamattoman datan pääsyn sovellukseen.

Bell-LaPadulan monitasoinen turvallisuusmalli

Bell-LaPadula (BLP) -malli formalisoi luokiteltujen tietojen pääsynhallinnan kahdella ensisijaisella säännöllä. Yksinkertainen turvallisuusominaisuus (ei lukemista ylöspäin): luokitustasolla L oleva kohde ei voi lukea objektia luokitustasolla L', jossa L' > L. Tähtiominaisuus (ei kirjoittamista alaspäin): luokitustasolla L oleva kohde ei voi kirjoittaa objektiin luokitustasolla L', jossa L' < L — estäen selvitettyä käyttäjää kopioimasta luokiteltua dataa luokittelemattomaan tietueeseen.

Käytännössä ei-kirjoittaminen-alaspäin-sääntö on vaikeampi toteuttaa web-sovelluksissa. SECRET-tason selvityksellä varustettu operaattori voi sovelluslogiikan puutteiden kautta kopioida SECRET-tason jälkitietoja UNCLASSIFIED-raporttiin. Valvonta edellyttää, että kirjoitusoperaatiot asettavat kohdejäsenen luokitustason kaikkien sen tuottamiseen käytettyjen lähdetietojen luokitustason maksimiksi, ja että tämä logiikka toteutetaan palvelutasolla eikä jätetä operaattorin vastuulle.

IAM-palveluntarjoajan integraatio

Keycloak on yleisimmin käytetty avoimen lähdekoodin identiteettipalveluntarjoaja puolustuksen C2-ohjelmissa, koska se tukee LDAP/Active Directory -federaatiota, hienojakoisia valtuutuskäytäntöjä ja paikallista käyttöönottoa ilman pilviriippuvuutta. Se voidaan ottaa käyttöön ilmaraolla eristettynä, mikä on vaatimus luokiteltujen verkkojen käyttöönotoille.

Keycloakin Authorization Services tukee ABAC-käytäntöjen arviointia natiivisti. Käytännöt määritellään JavaScript-pohjaisina sääntöinä tai sisäänrakennetulla JSON-käytäntökielellä. Tyypillisessä C2-integraatiossa Keycloak myöntää JWT:t, jotka sisältävät käyttäjän turvaluokitus- ja osastoväitteet, jotka on johdettu luokitellun verkon hakemistopalvelusta synkronoiduista Active Directory -ryhmäjäsenyyksistä.

Auditointijäljet ja SIEM-integraatio

Jokainen pääsypäätös — sekä myönnöt että kiellot — on kirjattava riittävän yksityiskohtaisesti turva-auditointia ja tapahtumiin reagoimista varten. Puolustuksen C2 -auditointilokin merkintä sisältää: aikaleiman, käyttäjätunnuksen, käyttäjän turvaluokitustason, yritetyn toiminnon, resurssitunnuksen, resurssin luokitustason, päätöksen (MYÖNNÄ/KIELLÄ) ja sen tuottaneen käytäntösäännön.

Auditointilokit välitetään Security Information and Event Management (SIEM) -järjestelmään — IBM QRadar tai Splunk Enterprise Security useimmissa NATO-ohjelmissa — reaaliaikaista poikkeamien havaitsemista varten. Käyttäjä, joka käyttää epätavallista määrää tietueita normaalin toiminta-alueensa ulkopuolella, tai kieltäytymisistä seuraava onnistunut käyttö, laukaisee hälytyksen turvallisuusarviointia varten.