Identiteetin hallinta ja administrointi puolustusorganisaatioille

Identiteetin hallinta ja administrointi (IGA) on kurinalaisuutta, jossa systemaattisesti hallitaan sitä, kenellä on pääsy mihinkin, kuinka pitkäksi aikaa ja millä valtuutuksella — ja tuotetaan tarkastettavissa oleva näyttö siitä, että pääsy on asianmukainen jokaisella ajanhetkellä. Kaupallisessa organisaatiossa IGA hallinnoi rooleja, oikeuksia ja määräaikaisarvioita HR-ohjatun henkilöstön elinkaaren aikana. Puolustusorganisaatiossa IGA:n on tehtävä kaikki tämä ja samalla pantava täytäntöön toinen pääsynhallintahila, joka rakentuu turvallisuusluokittelutasoista, osasto-jäsenyyksistä, tarvitse-tietää-määrityksistä ja ohjelmavatuutuksista. Juuri tässä kahden ongelmakuvauksen välisessä kuilussa useimmat kaupalliset IGA-käyttöönotot epäonnistuvat siirrettäessä ne puolustusympäristöön. Tässä artikkelissa käsitellään ne tekniset päätökset, joilla kyseinen kuilu suljetaan — kattaen turvallisuusluokittelua huomioivan provisionoinnin, roolisuunnittelun moniluokitteluympäristöissä, tehtävien eriyttämisen pienten tiimien rajoitteissa, pääsysertifioinnin suunnittelun, CAC/PIV-integraation sekä auditointilokiarkkitehtuurin, joka läpäisee RMF-akkreditoinnin. Credential-välityskerroksesta, johon IGA nojaa etuoikeutetun pääsyn aikana, katso etuoikeutetun pääsyn hallinta puolustuksessa -artikkeli.

Miksi IGA puolustuksessa eroaa yrityskäytöstä — turvallisuusluokittelutasot lisäpääsydimensiona, osastojen hallinta, tarvitse-tietää-vaatimusten toimeenpano

Kaupallisessa yrityksessä pääsynhallinnalla on kaksi merkityksellistä ulottuvuutta: kuka käyttäjä on (identiteetti) ja mihin rooliin tai ryhmään hän kuuluu (oikeus). Puolustusorganisaatio lisää kolmannen ulottuvuuden, joka on ortogonaalinen molempiin: mihin käyttäjällä on turvallisuusluokittelu ja lupa päästä. Vanhemmalla verkkoinsinöörillä saattaa olla voimassa oleva SECRET-turvallisuusluokitus, mutta hänellä ei ole lupaa päästä tiedusteluosastolle, joka toimii samassa SECRET-tason verkossa. Nuoremmalla analyytikolla saattaa olla TOP SECRET -luokitus ja erityinen perehdytys osastoon, johon vanhemmalla insinöörillä ei ole pääsyä. Asema tai organisaatiohierarkia ei ratkaise näitä päätöksiä — ainoastaan virallinen valtuutusasiakirja tekee sen.

Kaupalliset IGA-alustat — SailPoint IdentityNow, Saviynt, Omada, One Identity — on suunniteltu kaksiulotteiseen ongelmaan. Ne voivat tallentaa mukautettuja attribuutteja, ja riittävällä räätälöinnillä ne voivat panna täytäntöön turvallisuusluokittelurajoituksia, mutta ne eivät natiivisti mallinna osastoja, käsittelymerkintöjä tai ohjelman pääsyvaltuutuksia ensimmäisen luokan objekteina. Alusta antaa lisätä mukautetun attribuutin nimeltä "clearance_level" ja kirjoittaa provisiointisäännön, joka tarkistaa sen. Alusta ei kuitenkaan ilman mukautettu kehitystyötä ylläpidä reaaliaikaista syötettä henkilöstöturvallisuusjärjestelmästä, ratkaise eroa virallisen SCI-indoktrinaatiotietueen ja itseilmoitetun turvallisuusluokittelun välillä, eikä mallinna osastojen hilan omia sisään- ja uloskirjaustyönkulkuja.

Tarvitse-tietää-vaatimusten toimeenpano on terävin ero. Yrityksen IGA:ssa pääsy myönnetään tyypillisesti resurssien luokkaan — "tämä käyttäjä voi käyttää Finance-datajärveä." Puolustuksessa pääsy samaan resurssiin voidaan myöntää käyttäjälle A mutta ei käyttäjälle B, vaikka molemmilla on oikea turvallisuusluokitus, koska käyttäjää B ei ole virallisesti perehdytetty tietoja tuottavaan ohjelmaan. IGA:n on pantava tämä täytäntöön provisiointiaikana ja uudelleensertifiointiaikana kyselemällä auktoritatiivisia ohjelmanpääsytietueita eikä luottamalla esimiehen todistukseen. Ero "esimieheni hyväksyi pääsyn" ja "auktoritatiivinen tietue vahvistaa, että minut on perehdytetty tähän ohjelmaan" on juuri se kuilu, joka tuottaa auditointilöydöksiä ja pahimmissa tapauksissa luvattomia paljastuksia.

Käytännön seuraus on se, että puolustus-IGA-käyttöönotto vaatii connector-kehitystä ja työnkulun räätälöintiä enemmän kuin mikään kaupallinen IGA-tuote toimittaa vakiona. Budjetoi tämä etukäteen, käsittele turvallisuusluokittelu- ja osastodatasyötteet projektin kriittisimpänä integraatiotyönä ja harkitse, voidaanko olemassa olevaa kaupallista tuotetta laajentaa vastaamaan vaatimukseen vai onko puolustukseen räätälöity IGA-ratkaisu oikea lähtökohta. Nollaluottamusmalli puolustuksen ohjelmistoille riippuu siitä, että IGA toimittaa tarkkaa, jatkuvasti validoitua oikeustietoa — ilman sitä käytäntömoottoreilla tehdään valtuutuspäätöksiä vanhentuneista tai todentamattomista identiteettiatribuuteista.

Joiner-mover-leaver-elinkaari luokitellussa ympäristössä — automaattiset provisiointilaukaisut, turvallisuusluokittelun todentamisintegraatio, roolisiirtymät uudelleensijoituksessa

Joiner-mover-leaver (JML) -elinkaari on minkä tahansa IGA-käyttöönoton perustavanlaatuinen operatiivinen silmukka. Puolustuksessa jokaisella silmukan vaiheella on lisärajoituksia, jotka hidastavat sitä, mutta tekevät myös virheistä merkittävämpiä.

Joiner-työnkulku. Joiner-tapahtuma laukeaa, kun auktoritatiivinen HR- tai henkilöstöjärjestelmä luo uuden tietueen — uusi työntekijä, uusi alihankkija, uusi tilapäinen tehtävä. Puolustuksessa provisionti ei saa alkaa ennen kuin IGA-alusta on itsenäisesti vahvistanut henkilön adjudikoinnin mukaisen turvallisuusluokittelutason henkilöstöturvallisuusjärjestelmästä (US DoD:n yhteydessä JPAS tai DISS; kansalliset vastineet liittolaismaiden puolustusorganisaatioissa) ja vahvistanut voimassa olevan CAC- tai PIV-kortin DN:n rekisteröintijärjestelmästä. Järjestys on tärkeä: turvallisuusluokittelu tarkistus ohjaa provisioinnin, ei toisinpäin. IGA-alusta, joka luo tilin ensin ja tarkistaa turvallisuusluokittelun taustajärjestelmänä, on jo luonut hyväksikäytettävissä olevan ikkunan.

Joiner-työnkulun pitäisi myös laukaista osastojen pääsytarkistus kaikille oikeuksille, jotka edellyttävät virallista perehdytystä ohjelmaan. Jos perehdytystietue on olemassa auktoritatiivisessa ohjelmanpääsyjärjestelmässä, provisiointi jatkuu. Jos sitä ei ole, oikeus keskeytetään ja turvallisuusvastaavalle luodaan työnkulkukohde virallisen indoktrinaatioprosessin käynnistämiseksi. Tili on olemassa; arkaluonteinen oikeus ei ole, kunnes paperitietue on olemassa sen perustelemiseksi.

Mover-työnkulku. Uudelleensijoittaminen puolustusorganisaatioissa on yleistä ja merkityksellistä. Henkilö, joka siirtyy yhdestä ohjelmasta toiseen, menettää tyypillisesti pääsyn ensimmäisen ohjelman järjestelmiin ja saa pääsyn toiseen. IGA:n mover-työnkulun on ratkaistava tämä siirtymä deterministisesti: laskettava oikeuksien delta vanhan roolin ja uuden roolin välillä, peruutettava se, mikä ei enää ole asianmukaista, ja provisioitava se, mikä on uudestaan perusteltua — kaikki samalla turvallisuusluokittelu- ja osastotarkistuksilla. Kun uusi rooli edellyttää korkeampaa turvallisuusluokittelua kuin henkilöllä on, kyseisen luokitteludomain tili jäädytetään odottamaan turvallisuusluokittelun päivitystä.

Monimutkaisempi mover-tapaus on tilapäispalvelu (TDY) tai sekondeetti. Henkilö säilyttää kotiyksikkönsä roolin ja saa aikarajoitetun täydentävän rolin tehtävän ajaksi. IGA:n on mallinnettava tämä antamatta henkilölle pysyvästi korotettua pääsyä, joka jää voimaan tehtävän päätyttyä. Aikarajoitetut roolin myönnöt automaattisella vanhentumisella, jotka sekä kotiyksikön että vastaanottavan yksikön turvallisuusvastaavat tarkastavat, ovat oikea malli.

Leaver-työnkulku. Leaver-työnkulku — laukaistu irtisanomisen, sopimuksen päättymisen, eläköitymisen tai turvallisuusluokittelun peruuttamisen johdosta — on korkein-panosteisin vaihe ja se, jossa kaupalliset IGA-käyttöönotot puolustuksessa useimmiten epäonnistuvat. Odotuksena on saman päivän deprovisionti kaikille tileille kaikissa yhdistetyissä järjestelmissä riippumatta siitä, onko henkilö palauttanut CAC-korttinsa, kirjautunut ulos työasemaltaan tai suorittanut HR-poistumistarkistusprosessin. IGA-alustan ei pidä odottaa, kunnes HR-tietue saavuttaa "päättynyt"-tilan ennen kuin se peruuttaa pääsyn — turvallisuusluokittelun peruuttamistapahtuma henkilöstöturvallisuusjärjestelmästä on laukaisin, ja sen on levittävä lähes reaaliaikaisesti.

# Leaver-työnkulun SLA-tavoitteet (puolustusympäristö)
clearance_revocation_to_AD_disable:   < 1 hour
AD_disable_to_all_app_deprovisioning: < 4 hours
CAC_invalidation_propagation:         < 1 hour (DEERS → connected systems)
audit_closure_record_generated:       same business day
physical_access_revocation:           same day (physical security system integration)

Roolien suunnittelu moniluokitteluympäristöissä — roolimallin suunnittelu, turvallisuusluokittelun mukaiset roolijoukot, attribuuttipohjainen vs roolipohjainen hybridi osastoille

Roolien suunnittelu — prosessi, jossa IGA-alustan toimeenpanema roolimalli määritellään ja ylläpidetään — on puolustus-IGA-käyttöönoton aikaa vievin osa ja se, joka todennäköisimmin tuottaa pysyvää teknistä velkaa huonosti tehtynä. Perustavanlaatuinen rajoite on se, että roolien on oltava vakaita organisaatiomuutosten yli, koska jokainen roolin muutos IGA-alustalla on hallinnollinen tapahtuma, joka vaatii muutoksenhallintaa, uudelleentestauksen ja mahdollisesti uudelleensertifiointikampanjan.

Ensimmäinen suunnittelupäätös on domain-erottaminen. Puolustusorganisaatiot toimivat useissa luokitteludomaineissa — vähintään LUOKITTELEMATON ja SECRET, usein myös TOP SECRET ja yksi tai useampi SCI-enklaavi. Roolit on määriteltävä kussakin domainissa erikseen ja tallennettava erillisiin hakemistoinstansseihin. Rooli nimeltä "analyytikko" LUOKITTELEMATON-domainissa ja rooli nimeltä "analyytikko" SECRET-domainissa eivät ole sama rooli — niillä on eri oikeudet, eri turvallisuusluokitteluedellytykset ja niitä hallinnoi eri turvallisuusvastaava. Niiden yhdistäminen yhteen cross-domain-rooliin on arkkitehtuurivirhe, jonka akkreditoijat löytävät välittömästi ja joka luo todellisen riskin cross-domain-oikeuksien vuotamiselle.

Kussakin domainissa roolien tulisi olla toiminnallisia eikä organisatorisia. Organisatorinen rooli — "3. laivueen tiedustelusolun jäsen" — on vakaa vain niin kauan kuin organisaatio on. Toiminnallinen rooli — "tiedusteluanalyytikko, luokitellut järjestelmät" — seuraa henkilön tehtävää organisaatiorajojen yli ja selviää niistä uudelleenjärjestelyistä, joita tapahtuu joka kahdeksantoista kuukausi useimmissa puolustusympäristöissä. Toiminnalliset roolit myös koostuvat siistimmin: henkilöllä, jolla on kaksoisfunktio (analyytikko ja osastohallinnon vastuuhenkilö), on kaksi toiminnallista roolia, joista kumpikin hallinnoidaan ja sertifioidaan itsenäisesti.

Osastojen hallinta edellyttää attribuuttipohjaista pääsynhallintakerrosta (ABAC) RBAC-perustan päälle. Rooli määrittää, mitä henkilö voi tehdä; identiteettitietueensa osastoattribuutit määrittävät, mitä hän voi nähdä sitä tehdessään. Tämä hybridimalli — RBAC rakenteellisille oikeuksille, ABAC datan tason suodatukselle — on arkkitehtuuri, joka skaalautuu todellisen puolustusorganisaation monimutkaisuuteen ilman, että tarvitaan uusi rooli aina kun uusi osasto luodaan.

# Identiteettiattribuuttiskeema (yksinkertaistettu)
{
  "dn": "CN=J.Smith,OU=SECRET,DC=mil",
  "clearance_level": "SECRET",
  "compartments": ["ALPHA", "BRAVO"],
  "programs": ["PGM-001", "PGM-004"],
  "roles": ["intelligence-analyst-s", "portal-user-s"],
  "card_dn": "CN=SMITH.JANE.1234567890,OU=DoD,O=U.S. Government,C=US",
  "clearance_expiry": "2028-03-15",
  "last_certified": "2026-04-01"
}

Roolien elinkaaren hallinta — roolien lisääminen, muokkaaminen ja poistaminen — edellyttää erillistä hallintaprosessia käyttäjäelinkaarien hallinnasta. Uudet roolit pitäisi vaatia turvallisuusvastaavan hyväksyntä, oikeuksien vaikutusanalyysi ja testiympäristön validointi ennen tuotantoon siirtämistä. Poistettavat roolit edellyttävät migraatiosuunnitelman, joka siirtää nykyiset roolinhaltijat korvaaviin rooleihin ennen vanhan roolin poistamista, estäen orpojen oikeuksien syntymisen yhdistetyissä järjestelmissä.

Tehtävien eriyttäminen puolustusohjelmissa — SoD-sääntöjen suunnittelu hankintaan ja ylläpitoon, kompensoivat kontrollit pienten tiimien poikkeuksille

Tehtävien eriyttäminen (SoD) on kontrolliperiaate, jonka mukaan yksikään henkilö ei saa hallita molempia puolia korkean riskin tapahtumasta — kykyä sekä aloittaa että hyväksyä taloudellinen sitoumus, tai sekä pyytää että myöntää oma pääsyoikeus, tai sekä kirjoittaa että sertifioida ohjelmistojulkaisu. Puolustuksen hankinnan ja ylläpidon ympäristöissä SoD-epäonnistumiset ovat tuottaneet joitain kalleimmista petos- ja väärinkäytöstapauksista kirjatuissa historioissa: hankintaviranomainen, joka voi myös sertifioida laskumaksuja; järjestelmänvalvoja, joka voi muokata sekä sovellusohjelmakoodia että sen pääsynhallintaa; logistiikkapäällikkö, joka voi sekä tilata että sertifioida materiaalin vastaanoton.

IGA panee SoD:n täytäntöön sääntöjoukolla, joka tunnistaa ristiriitaiset oikeusparit ja estää yhtä identiteettiä pitämästä molempia. Sääntöjoukko on suunniteltava puolustuksen hankinnan erityisten korkean riskin työnkulkujen perusteella eikä lainattava kaupallisesta rahoituspalvelujen mallista. Tärkeimpiä konfliktipareina puolustusyhteyksissä ovat:

• Sopimuksen käynnistäminen ja sopimuksen hyväksyminen (hankinta-SoD)
• Pääsypyynnön lähettäminen ja pääsyn hyväksyminen (IAM SoD)
• Koodin commit ja koodin käyttöönoton valtuuttaminen (DevSecOps SoD)
• Kryptografinen avaimen generointi ja avainhuoltohenkilön sertifiointi
• Omaisuuden hävitysvaltuutus ja omaisuuden vastaanoton sertifiointi
• Taloudellisen sitoumuksen kirjaus ja sitoumuksen sertifiointi

Teknisenä haasteena puolustuksessa on se, että monissa ohjelmissa toimitaan hyvin pienissä tiimeissä — joskus alle kymmenen selvitettyä henkilöä kattaa kaikki roolit. SoD-sääntö, joka edellyttää kahta eri henkilöä pitämään ristiriitaiset oikeudet, saattaa olla mahdoton toteuttaa kolmen hengen etujoukkoon sijoitetussa yksikössä. Oikea IGA-vastaus ei ole poistaa SoD-sääntöjä pieniltä tiimeiltä; se on toteuttaa jäsennelty poikkeustyönkulku kompensoivilla kontrolleilla.

Kompensoivan kontrollin SoD-poikkeukselle pitäisi sisältää: dokumentoitu riskin hyväksyminen, jonka valtuuttava virkailija on allekirjoittanut; parannettu auditointimerkki kaikille poikkeuksenhaltijan suorittamille tapahtumille, jotta jokainen tällainen tapahtuma tulee esiin seuraavassa vaatimustenmukaisuuden tarkistuksessa; pakollinen toissijainen tarkistusvaatimus (tapahtuma on valmis, mutta toisen selvitetyn henkilön on tarkistettava ja kuittattava se määritellyn aikaikkuaksen kuluessa); ja poikkeukselle asetettu viimeinen voimassaolopäivä, joka käynnistää uudelleenarvioinnin hiljaisesti jatkamisen sijaan.

SoD-säännöt nousevat esiin myös pääsysertifiointikampanjoissa. Kun uudelleensertifiointiarvioija hyväksyy pääsyn henkilölle, jolla on ristiriitainen oikeuspari, IGA-alustan tulisi esittää ristiriita näkyvästi ja vaatia eksplisiittistä ohituspäätöstä sen sijaan, että hyväksyminen sallittaisiin hiljaisesti. Jokainen ohitus kirjataan sertifiointipoikkeuksena auditointilokiin, varmistaen, että akkreditoija voi nähdä paitsi mitä pääsyä on olemassa myös mitä SoD-ristiriitoja on tietoisesti hyväksytty ja kenen toimesta.

Pääsysertifiointikampanjat — kampanjatiheys luokitellun järjestelmän pääsylle, automatisoitu arvioijan osoittaminen esimiesketjun mukaan, eräkäsittely vs riskipohjainen uudelleensertifiointi

Pääsysertifiointi on säännöllinen prosessi, jossa jokaisen käyttäjän nykyiset oikeudet esitetään vastuuarvioijalle todistukseksi siitä, että pääsy on edelleen asianmukaista. Puolustuksessa se on myös ensisijainen mekanismi, jolla organisaatio osoittaa jatkuvan vaatimustenmukaisuuden AC-2:n ja siihen liittyvien kontrollien osalta — akkreditoijan kysymykseen "voitteko osoittaa, että kaikki tämän järjestelmän pääsy on tällä hetkellä valtuutettua?" vastataan sertifiointikampanjatietueella.

NIST 800-53 AC-2(j):n vähimmäisvaatimus edellyttää kaikkien tilien vuosittaista tarkistusta, mutta puolustuskäytäntö ja useimmat akkreditointiohjeet odottavat enemmän. Käytännöllinen kampanjataipumus luokitelluille järjestelmille:

• Neljännesvuosittain: etuoikeutetut tilit (järjestelmänvalvojat, turvallisuusvastaavat, palvelutilit korotetuin oikeuksin), tilit cross-domain-ratkaisuissa, kryptografisten avainten hallintajärjestelmissä ja tiedusteluvarastoissa
• Puolivuosittain: kaikki käyttäjätilit SECRET-tason ja sitä ylemmissä järjestelmissä; tilit, joilla on pääsy taloudellisiin sitoumuksiin ja hankintatehtäviin
• Vuosittain: LUOKITTELEMATON-tason järjestelmien tilit; vain luku -tilit ilman kirjoitus- tai etuoikeutettua ominaisuutta
• Tapahtumalähtöinen: mikä tahansa tili, joka kuuluu henkilölle, joka vaihtaa roolia, ohjelmaa tai yksikköä; mikä tahansa tili järjestelmässä, joka suorittaa merkittävän muutoksen; mikä tahansa tili, jossa turvallisuusluokittelun uusiminen tai päivitys/alennus on tapahtunut

Automatisoitu arvioijan osoittaminen on kriittistä puolustusympäristöissä, joissa organisaatiorakenteet muuttuvat usein ja IGA-alusta ei voi nojata staattiseen arvioijakartastoon. Oikea arvioijan osoittamislähde on HR-järjestelmän auktoritatiivinen esimiesketju — kun IGA-alusta luo sertifiointikampanjan, se kyselee jokaisen identiteetin nykyisen esimiesrekordin ja osoittaa tarkistuksen kyseiselle esimiehelle. Kun esimiesasema on vapaana (yleinen tapaus etujoukon ympäristöissä), ketju eskaloi automaattisesti seuraavan tason esimiehelle, ja määritelty eskalointiaika laukaisee turvallisuusvastaavan ohituksen.

Eräkäsittely — kaikkien oikeuksien esittäminen käyttäjäpopulaatiolle kerralla — soveltuu puolivuosittaisiin ja vuosittaisiin kampanjoihin, joissa tavoite on kattava tarkistus. Riskipohjainen sertifiointi on parempi korkean tiheyden tarkasteluissa: sen sijaan että IGA-alusta esittäisi etuoikeutetun käyttäjän koko oikeuksien joukon joka neljännes, se tunnistaa, mitkä oikeudet ovat muuttuneet, mitkä on käytetty (ja mitkä ei) ja mitkä kantavat SoD-ristiriitoja, ja esittää vain nämä kohdennetulle tarkistukselle. Käyttämättömät oikeudet — etuoikeutettu rooli, joka on myönnetty kuusi kuukautta sitten, mutta jota ei ole koskaan käytetty — ovat riskipohjaisen kampanjan arvokkain löydös; ne edustavat paperilla olemassa olevaa pääsyä, jonka peruuttaminen ei maksa organisaatiolle mitään, ja niiden poistaminen vähentää välittömästi sisäpiiriuhkien tunnistaminen puolustuksessa -riskimallissa dokumentoitua hyökkäyspintaa.

Kampanjan suoritusasteet ovat ohjelman terveyden jälkiindikaattori. Kampanja, joka saavuttaa 95 %:n suoritusasteen 5 %:n poikkeuksilla, on puolustettavissa. Kampanja, joka saavuttaa 60 %:n suoritusasteen, koska arvioijat jättivät ilmoituksen huomiotta, on auditointilöydös odottamassa tapahtumistaan. IGA-alustojen tulisi eskaloida suorittamattomat tarkistukset esimiesketjuun kasvavalla kiireellisyydellä, ja turvallisuusvastaavilla tulisi olla kojelautanäkyvyys kampanjan suoritusasteisiin reaaliajassa eikä kampanjan määräajan lähestyessä.

Integraatio HR:n, identiteettitarjoajien ja CAC/PIV:n kanssa — integrointiarkkitehtuuri DoD/PKI:lle, CAC/PIV-kytketty provisiointi, reaaliaikainen turvallisuusluokittelun peruuttamisen levittäminen

Puolustus-IGA-alustan integrointiarkkitehtuuri on monimutkaisempaa kuin mikään kaupallinen käyttöönotto, koska se kattaa useita auktoritatiivisia järjestelmiä, joilla ei ole yhteistä API-sopimusta, jotka toimivat eri luokittelutasoilla ja joita omistavat eri organisaatiot.

Identiteettiankuri US DoD:n yhteydessä on Common Access Card (CAC). Jokainen aktiivipalveluksessa oleva sotilashenkilö, reserviläinen palveluksessa ja useimmat siviilit ja alihankkijat kantavat sellaista. CAC sisältää kolme PKI-sertifikaattia (identiteetti, sähköposti ja sisällön allekirjoitus), joiden erottelunimet toimivat vakaan, auktoritatiivisena tunnistajana kaikissa yhdistetyissä järjestelmissä. IGA-alustan tilin mallin on perustuttava CAC DN:ään eikä sähköpostiosoitteeseen tai työntekijätunnukseen, koska ne voivat muuttua samalla kun CAC DN pysyy vakaana kortin uusimisen yli.

CAC:n myöntämis- ja uusimistiedot kulkevat Defense Enrollment Eligibility Reporting System (DEERS):stä Real-time Automated Personnel Identification System (RAPIDS):n kautta. IGA-integraatio DEERS/RAPIDS:n kanssa tarjoaa kolme kriittistä tapahtumaa: kortin myöntäminen (laukaisee tilin aktivoinnin), kortin uusiminen (laukaisee DN-päivityksen levittämisen kaikkiin yhdistettyihin järjestelmiin) ja kortin peruuttaminen (laukaisee välittömän tilin jäädyttämisen). Peruuttamisen levittämisen on oltava lähes reaaliaikaista — peruutettu CAC, joka myöntää edelleen järjestelmäpääsyn 24 tuntia, koska IGA-alusta pollaa DEERS:ää kerran päivässä, on vaatimustenmukaisuusvirhe ja turvallisuusinsidentti odottamassa tapahtumistaan. Tavoite on alle tunnin levittäminen peruuttamistapahtumille, saavutettuna tapahtumalähtöisillä webhook-kutsuilla tai tiheän päivitysnopeuden delta-synkronointisyötteellä eikä eräpollauksen kautta.

Turvallisuusluokittelun peruuttamisen levittämisellä on sama vaatimus. Virta on: henkilöstöturvallisuusvastaava peruuttaa turvallisuusluokittelun JPAS/DISS:ssä → IGA-alusta vastaanottaa tapahtuman → kaikki tilit peruutetulle turvallisuusluokittelutasolle ja sitä ylempänä jäädytetään → yhdistetyt järjestelmät levittävät jäädytyksen omien IGA-connectoreidensa kautta. IGA-alusta on orchestraatiokerros; jokainen yhdistetty järjestelmä vastaa jäädytyksen toimeenpanosta omien pääsynhallintakontrolleidensa kautta eikä nojaa siihen, että IGA-alusta kutsuu jokaisen järjestelmän API:a yksitellen.

Liittolaismaiden puolustusorganisaatioille, jotka toimivat PKI:n alaisuudessa, integrointiarkkitehtuuri seuraa samaa mallia kansallisten PKI CA:iden kanssa DoD PKI:n sijaan. IGA-alustan on luotettava asianmukaiseen kansalliseen luottanusankkuriin ja jäsennettävä kansallisten PKI-sertifikaattien DN-rakenne, joka poikkeaa DoD-muodosta. Cross-domain-skenaariot — yhdysvaltalainen yhteysupseeri toimii kumppanin verkon päälle — edellyttävät federaatiota luottanusankkureiden välillä, tyypillisesti toteutettuna PKI-sillan tai tehtäväkohtaisen federaatiosopimuksen kautta, jonka IGA-alusta kääntää tilapäiseksi identiteettisidonnaksi.

# IGA-integrointitopologia
HR system (DCPDS / SAP) ──→ [IGA platform] ←── Personnel security (JPAS/DISS)
                                   ↑
DEERS/RAPIDS (CAC events) ─────────┘
                                   ↓
           ┌───────────────────────┼───────────────────────┐
           ↓                       ↓                       ↓
   AD (UNCLASSIFIED)        AD (SECRET)           AD (TS/SCI)
           ↓                       ↓                       ↓
   App connectors           App connectors         App connectors
   (NIPR systems)           (SIPR systems)         (JWICS systems)

Auditointilokit ja vaatimustenmukaisuusraportointi — NIST 800-53 AC/IA-kontrollit, auditointilokivaatimukset luokitellulle järjestelmälle, vaatimustenmukaisuusnäytön tuottaminen

IGA-alustan tuottama auditointiloki on ensisijainen näyttöartefakti pääsynhallinta- ja tunnistamis-ja-todentamiskontrolliperheille NIST 800-53 -arvioinnissa. Tämän oikein tekeminen ei ole valinnaista — se on ero akkreditointipaketin välillä, joka osoittaa jatkuvan vaatimustenmukaisuuden, ja paketin välillä, joka käynnistää toimintasuunnitelman ja välitavoitteet (POA&M) jokaiselle pääsynhallintolöydökselle.

IGA-auditointilokin on tallennettava jokainen provisiointi- ja deprovisiointitapahtuma tapahtumatasolla. Jokaisen tietueen tulisi sisältää: vaikutuksen alainen identiteetti, myönnetty tai peruutettu oikeus, tapahtuman aika, valtuutus, jonka nojalla tapahtuma suoritettiin (automaattinen työnkulku, esimiehen hyväksyntä, turvallisuusvastaavan ohitus tai sertifiointikampanjapäätös), ja vakaa viittaus lähdetapahtumaan, joka laukaisi toiminnan (HR-tietueen muutos, turvallisuusluokittelutapahtuma, sertifiointipäätös). Tämä yksityiskohtaisuustaso tukee kolmea erillistä auditointikäyttötapausta: pääsytilan rekonstruoiminen millä tahansa historiallisella ajanhetkellä, tietyn pääsytapahtuman tutkiminen ja koko käyttäjäpopulaation kattava vaatimustenmukaisuusraportointi.

NIST 800-53:n kontrollit, joita IGA-auditointidata todentaa suorimmin, ovat:

• AC-2 (Tilien hallinta): IGA-elinkaaritietueet osoittavat, että tilit luodaan vain valtuutetuille henkilöille, tarkistetaan määritellyillä taajuuksilla ja poistetaan käytöstä henkilöiden lähtiessä
• AC-5 (Tehtävien erottaminen): SoD-sääntöjen toimeenpanotut lokitiedot ja poikkeustietueet osoittavat, että ristiriitaiset tehtävät tunnistetaan ja hallinnoidaan
• AC-6 (Vähimmäisoikeus): Roolien suunnittelutietueet ja käyttämättömien oikeuksien analyysit sertifiointikampanjoista osoittavat, että pääsy on rajattu tarpeelliseen vähimmäiseen
• IA-2 (Tunnistaminen ja todentaminen): CAC/PIV-sidostietueet osoittavat, että monitekijätodentaminen on pantu täytäntöön kaikille käyttäjätileille luokitelluissa järjestelmissä
• IA-4 (Tunnisteen hallinta): Joiner- ja leaver-tietueet osoittavat, että tilin tunnisteet myönnetään ja poistetaan käytöstä määritellyn hallintaprosessin mukaisesti
• IA-5 (Todentajan hallinta): Korttisidos- ja kortin peruuttamisen levittämistietueet osoittavat, että todentajat hallinnoidaan ja peruutetaan kontrolloidusti ja oikea-aikaisesti

Vaatimustenmukaisuusraportoinnin IGA-alustasta pitäisi olla suunniteltu tuottamaan valmiiksi muotoiltuja näyttöpaketteja eikä raakoja lokilatausia. Akkreditoijan, jota pyydetään arvioimaan AC-2, pitäisi voida saada raportti, joka näyttää kaikki aktiiviset tilit, päivämäärän, jolloin kukin viimeksi tarkistettiin, onko jokin sertifioinnissa myöhässä, ja poikkeuksien lukumäärän — ei 500 000 rivin tapahtumalokia ja pyyntöä "jäsennä se itse." Näiden raporttien suunnittelu ennen ensimmäistä akkreditointitarkistusta ja sen validointi, että raportit heijastavat tarkasti kontrollin toteutusta, on ero kahden päivän ja kahden viikon kriisin välillä.

Auditointilokin muuttumattomuus edellyttää kirjoita-kerran-tallennusta tai kryptografista tiivisteasiointia. Puolustuksen säilytysvaatimukset luokiteltujen järjestelmien pääsylokille ovat tyypillisesti 3–7 vuotta riippuen järjestelmän tehtävästä ja luokittelutasosta; joillakin ydinaseiden läheisissä ja strategisissa järjestelmissä on pidempiä säilytysvaatimuksia. Tallennustilan on oltava mitoitettu ja elinkaaren hallittu sen mukaisesti, hakumenettelyjen toimiessa, kun alkuperäistä ohjelmistopinoa ei enää tueta. Säilytysvaatimus, joka täyttyy päivänä yksi mutta tuottaa lukukelvottomia lokeja kuudentena vuonna, on vaatimustenmukaisuusvirhe sillä aikajanalla, jolla se merkitsee.