Identity governance and administration voor defensieorganisaties

Identity governance and administration (IGA) is de discipline van het systematisch beheren van wie toegang heeft tot wat, voor hoe lang en op welke grondslag — en het produceren van controleerbaar bewijs dat de toegang op elk moment passend is. In een commerciële organisatie beheert IGA rollen, rechten en periodieke beoordelingen over de HR-gestuurde medewerkerslevenscyclus. In een defensieorganisatie moet IGA dat alles doen én tegelijkertijd een tweede toegangscontroleraster afdwingen dat is opgebouwd uit beveiligingsautorisatieniveaus, compartimentlidmaatschappen, need-to-know-bepalingen en programmautorisaties. Het verschil tussen die twee probleemstellingen is precies waar de meeste commerciële IGA-implementaties mislukken als ze in een defensieomgeving worden ingezet. Dit artikel behandelt de engineeringbeslissingen die dat verschil overbruggen — inclusief autorisatie-bewuste provisioning, rolmodellering voor omgevingen met meerdere classificatieniveaus, scheiding van taken onder kleine-team-beperkingen, het ontwerp van toegangscertificeringscampagnes, CAC/PIV-integratie en de audittrailarchitectuur die nodig is om een RMF-accreditatie te doorstaan. Voor de credential-brokeringslaag waarop IGA steunt bij bevoorrecht toegang, zie onze behandeling van privileged access management voor defensie.

Waarom IGA in defensie verschilt van de enterprise — autorisatieniveaus als extra toegangsdimensie, compartimentbeheer, handhaving van need-to-know

In een commerciële onderneming heeft toegangscontrole twee betekenisvolle dimensies: wie de gebruiker is (identiteit) en tot welke rol of groep hij behoort (recht). Een defensieorganisatie voegt een derde dimensie toe die loodrecht staat op beide: waartoe de gebruiker gecertificeerd en geautoriseerd is om toegang te hebben. Een senior netwerktechnicus kan een geldige SECRET-autorisatie hebben maar geen toestemming om toegang te krijgen tot het intelligentiecompartiment dat op hetzelfde SECRET-netwerk draait. Een junior analist kan gecertificeerd zijn voor TOP SECRET en specifiek ingelezen zijn in een compartiment waartoe de senior technicus geen toegang heeft. Noch anciënniteit noch organisatorische hiërarchie lost deze beslissingen op — alleen het formele autorisatiedossier doet dat.

Commerciële IGA-platforms — SailPoint IdentityNow, Saviynt, Omada, One Identity — zijn ontworpen voor het tweedimensionale probleem. Ze kunnen aangepaste attributen opslaan en met voldoende maatwerk kunnen ze autorisatieniveaubeperkingen afdwingen, maar ze modelleren compartimenten, verwerkingscaveats of programmatoegangsmachtigingen niet als eersteklas objecten. Het platform laat je een aangepast attribuut met de naam "clearance_level" toevoegen en een inrichtingsregel schrijven die dit controleert. Het platform onderhoudt echter niet — zonder maatwerkontwikkeling — een live feed vanuit een persoonlijk beveiligingssysteem, lost het verschil op tussen een formeel SCI-indoctrinatiedossier en een zelfgerapporteerde autorisatieclaim, of modelleert het rooster van compartimenten met hun eigen inlees- en uitleesworkflows.

Need-to-know-handhaving is het scherpste verschil. In enterprise IGA wordt toegang doorgaans verleend aan een resourceklasse — "deze gebruiker heeft toegang tot het Finance-datameer." In defensie kan toegang tot dezelfde resource worden verleend aan gebruiker A maar niet aan gebruiker B, ook al beschikken beiden over de juiste autorisatie, omdat gebruiker B niet formeel is ingelezen in het programma dat de gegevens produceert. IGA moet dit afdwingen op het moment van provisioning en op het moment van hercertificering, waarbij autoritatieve programmatoegangsdossiers worden geraadpleegd in plaats van te vertrouwen op de bevestiging van een manager. Het verschil tussen "mijn manager heeft mijn toegang goedgekeurd" en "het autoritatieve dossier bevestigt dat ik ben ingelezen in dit programma" is precies het verschil dat auditbevindingen oplevert en, in de ergste gevallen, tot ongeoorloofde openbaarmakingen leidt.

De praktische implicatie is dat een defensie-IGA-implementatie connectorontwikkeling en workflowmaatwerk vereist die verder gaan dan wat elk standaard IGA-product levert. Beplan dit budget vooraf, behandel de autorisatie- en compartimentdatafeeds als het meest kritieke integratiewerk in het project, en overweeg of het bestaande commerciële product kan worden uitgebreid om aan de vereisten te voldoen of dat een defensiespecifieke IGA-oplossing (zoals die gebouwd op de enterprise-identiteitsservicearchitectuur van de IC) het juiste startpunt is. Het zero trust voor defensiesoftware-model is afhankelijk van IGA dat nauwkeurige, continu gevalideerde rechtengegevens levert — zonder dat nemen beleidsengines autorisatiebeslissingen op basis van verouderde of onverifieerbare identiteitsattributen.

De joiner-mover-leaver-levenscyclus in een geclassificeerde omgeving — geautomatiseerde provisioningtriggers, integratie van autorisatieverificatie, rolovergang bij herplaatsing

De joiner-mover-leaver (JML)-levenscyclus is de fundamentele operationele cyclus van elke IGA-implementatie. In defensie heeft elke fase van de cyclus aanvullende beperkingen die hem vertragen maar ook consequenter maken om verkeerd te doen.

Joiner-workflow. Een joiner-event wordt geactiveerd wanneer een autoritatief HR- of personeelssysteem een nieuw dossier aanmaakt — nieuwe medewerker, nieuwe contractant, nieuwe tijdelijke aanstelling. In defensie mag provisioning niet beginnen voordat het IGA-platform onafhankelijk het geadjudiceerde autorisatieniveau van de persoon heeft bevestigd vanuit het persoonlijk beveiligingssysteem (JPAS of DISS in de US DoD-context; nationale equivalenten bij geallieerde defensieorganisaties) en een geldig CAC- of PIV-kaart-DN heeft bevestigd vanuit het inschrijvingssysteem. De volgorde is cruciaal: de autorisatiecontrole legt provisioning in de wacht, niet andersom. Een IGA-platform dat eerst een account aanmaakt en daarna in een achtergrondtaak de autorisatie controleert, heeft al een exploiteerbaar venster gecreëerd.

De joiner-workflow moet ook een compartimenttoegangcontrole starten voor elk recht waarvoor een formele inlezing in een programma vereist is. Als het inleesdossier bestaat in het autoritatieve programmatoegangsysteem, gaat de provisioning door. Als dat niet het geval is, wordt het recht onderdrukt en wordt er een workflowitem aangemaakt voor de beveiligingsfunctionaris om het formele indoctrinatieproces te starten. Het account bestaat; het gevoelige recht bestaat niet, totdat het papieren dossier er is om het te rechtvaardigen.

Mover-workflow. Herplaatsing in defensieorganisaties is frequent en heeft grote gevolgen. Een persoon die van het ene programma naar het andere overgaat, verliest doorgaans de toegang tot de systemen van het eerste programma en krijgt toegang tot die van het tweede. De IGA-mover-workflow moet deze overgang deterministisch oplossen: het rechtendelta berekenen tussen de oude rollenset en de nieuwe, het niet langer passende intrekken en het nieuw gerechtvaardige provisioneren — allemaal onderworpen aan dezelfde autorisatie- en compartimentcontroles. Wanneer de nieuwe rol een hogere autorisatie vereist dan de persoon momenteel heeft, wordt het account voor dat classificatiedomein onderdrukt in afwachting van een beslissing over autorisatieverhoging.

Het complexere mover-geval is tijdelijke dienst (TDY) of detachering. De persoon behoudt zijn thuiseenheidrollenset en verkrijgt een tijdelijk aanvullende rollenset voor de duur van de opdracht. IGA moet dit modelleren zonder de persoon permanent verhoogde toegang te geven die na het einde van de opdracht blijft bestaan. Tijdgebonden rolverleeningen met automatische vervaldatum, beoordeeld door zowel de beveiligingsfunctionarissen van de thuiseenheid als de gastheenheid, zijn het juiste patroon.

Leaver-workflow. De leaver-workflow — geactiveerd door beëindiging, contracteinde, pensionering of intrekking van autorisatie — is de fase met de hoogste inzetten en de fase waarbij commerciële IGA-implementaties in defensie het vaakst tekortschieten. De verwachting is dezelfde-dag deprovisionering voor alle accounts in alle verbonden systemen, ongeacht of de persoon zijn CAC fysiek heeft ingeleverd, is uitgelogd van zijn werkstation of een HR-uitcheckproces heeft voltooid. Het IGA-platform mag niet wachten tot een HR-dossier de status "beëindigd" heeft bereikt voordat de toegang wordt ingetrokken — het autorisatie-intrekkingsevent vanuit het persoonlijk beveiligingssysteem is de trigger, en dit moet in bijna-realtime worden doorgegeven.

# SLA-doelen leaver-workflow (defensiecontext)
clearance_revocation_to_AD_disable:   < 1 uur
AD_disable_to_all_app_deprovisioning: < 4 uur
CAC_invalidation_propagation:         < 1 uur (DEERS → verbonden systemen)
audit_closure_record_generated:       zelfde werkdag
physical_access_revocation:           zelfde dag (integratie fysiek beveiligingssysteem)

Rolmodellering voor omgevingen met meerdere classificatieniveaus — ontwerp van rolmodel, autorisatie-gebonden rollensets, hybride attribuutgebaseerde en rolgebaseerde aanpak voor compartimenten

Rolmodellering — het proces van het definiëren en onderhouden van het rolmodel dat het IGA-platform afdwingt — is het meest tijdrovende onderdeel van een defensie-IGA-implementatie en het onderdeel dat het meest waarschijnlijk aanhoudende technische schuld oplevert als het slecht wordt gedaan. De fundamentele beperking is dat rollen stabiel moeten zijn bij organisatorische wijzigingen, omdat elke rolwijziging in het IGA-platform een administratieve gebeurtenis is die wijzigingsbeheer, hertesting en mogelijk een hercertificeringscampagne vereist.

De eerste ontwerpbeslissing is domeinseparatie. Defensieorganisaties opereren in meerdere classificatiedomeinen — minimaal UNCLASSIFIED en SECRET, vaak ook TOP SECRET en een of meer SCI-enclaves. Rollen moeten binnen elk domein afzonderlijk worden gedefinieerd en opgeslagen in afzonderlijke directoryinstances. Een rol met de naam "analist" in het UNCLASSIFIED-domein en een rol met de naam "analist" in het SECRET-domein zijn niet dezelfde rol — ze bevatten verschillende rechten, verschillende autorisatievereisten en worden beheerd door verschillende beveiligingsfunctionarissen. Ze samenvoegen in één cross-domeinrol is een architectuurfout die accrediteurs onmiddellijk zullen ontdekken en die een reëel risico op cross-domeinrechtenlekkage creëert.

Binnen elk domein moeten rollen functioneel zijn in plaats van organisatorisch. Een organisatorische rol — "lid van de Intelligence Cell van het 3de Squadron" — is alleen stabiel zolang de organisatie dat is. Een functionele rol — "intelligence-analist, geclassificeerde systemen" — gaat mee met de functie van de persoon over organisatiegrenzen heen en overleeft de reorganisaties die in de meeste defensieomgevingen elke achttien maanden plaatsvinden. Functionele rollen zijn ook schoner samen te stellen: een persoon met een dubbele rol (analist en sectieadministrator) krijgt twee functionele rollen, elk onafhankelijk beheerd en gecertificeerd.

Compartimentbeheer vereist een attribuutgebaseerde toegangscontrole (ABAC)-laag bovenop de RBAC-basis. De rol bepaalt wat de persoon kan doen; de compartimentattributen in het identiteitsdossier bepalen wat hij kan zien terwijl hij dat doet. Dit hybride model — RBAC voor structurele rechten, ABAC voor filtering op gegevensniveau — is de architectuur die schaalt naar de complexiteit van een echte defensieorganisatie zonder dat voor elk nieuw compartiment een nieuwe rol hoeft te worden aangemaakt.

# Identiteitsattribuutschema (vereenvoudigd)
{
  "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"
}

Het levenscyclusbeheer van rollen — toevoegen, wijzigen en buiten gebruik stellen — vereist een apart governanceproces los van het gebruikerslevenscyclusbeheer. Nieuwe rollen moeten goedkeuring van een beveiligingsfunctionaris vereisen, een rechtenimpactanalyse en validatie in een testomgeving voordat ze naar productie worden gepromoveerd. Buiten gebruik gestelde rollen vereisen een migratieplan dat huidige rolhouders naar vervangende rollen verplaatst voordat de oude rol wordt verwijderd, om zwevende rechten in verbonden systemen te voorkomen.

Scheiding van taken in defensieprogramma's — SoD-regelontwerp voor verwerving en instandhouding, compenserende controls voor uitzonderingen bij kleine teams

Scheiding van taken (SoD) is het controlleprincipe dat geen enkel individu beide kanten van een hoog-risicotransactie mag beheersen — de mogelijkheid om zowel een financiële verplichting te initiëren als goed te keuren, of zowel zijn eigen toegang aan te vragen als te verlenen, of zowel een softwarerelease te schrijven als te certificeren. In omgevingen voor defensieverwerving en -instandhouding hebben SoD-tekortkomingen geleid tot een aantal van de kostbaarste fraude- en wanbeheerzaken: een contractofficier die ook factuurbetalingen kon certificeren; een systeembeheerder die zowel applicatiecode als de bijbehorende toegangscontroles kon wijzigen; een logistiek manager die zowel materieel kon bestellen als de ontvangst kon certificeren.

IGA dwingt SoD af via een regelset die conflicterende rechtenparen identificeert en voorkomt dat één identiteit beide behoudt. De regelset moet worden ontworpen met de specifieke hoog-risicoworkflows van defensieverwerving in gedachten, niet overgenomen uit een commercieel financieel-diensten-sjabloon. Belangrijke conflictparen in defensiecontexten zijn:

• Contractinitiatie en contractgoedkeuring (inkoop-SoD)
• Toegangsverzoek indienen en toegang goedkeuren (IAM-SoD)
• Code committen en code-deploymentautorisatie (DevSecOps-SoD)
• Cryptografische sleutelgeneratie en sleutelbeheerderscertificering
• Autorisatie voor activa-afvoer en certificering van activa-ontvangst
• Registratie van financiële verplichting en certificering van verplichting

De engineeringuitdaging in defensie is dat veel programma's draaien met zeer kleine teams — soms minder dan tien gecertificeerde medewerkers die alle rollen vervullen. Een SoD-regel die vereist dat twee verschillende personen de conflicterende rechten houden, kan niet worden afgedwongen in een driepersoonsdetachement dat vooruitgeschoven is ingezet. De juiste IGA-reactie is niet om SoD-regels voor kleine teams uit te schakelen; het is het implementeren van een gestructureerde uitzonderingsworkflow met compenserende controls.

Een compenserende control voor een SoD-uitzondering moet omvatten: gedocumenteerde risicoaanvaarding ondertekend door de autoriserende functionaris; een verbeterde auditvlag op alle transacties uitgevoerd door de uitzonderingshouder, zodat elke dergelijke transactie zichtbaar is in de volgende compliancebeoordeling; een verplichte secundaire-beoordelingsvereiste (de transactie is voltooid maar een tweede gecertificeerde persoon moet deze controleren en medeondertekenen binnen een bepaald tijdvenster); en een vervaldatum op de uitzondering die herbeoordeling triggert in plaats van stilzwijgende voortgang.

SoD-regels komen ook naar voren tijdens toegangscertificeringscampagnes. Wanneer een hercertificeringsbeoordelaar toegang goedkeurt voor iemand die een conflicterend rechtenpaar bezit, moet het IGA-platform het conflict duidelijk presenteren en een expliciete overschrijvingsbeslissing vereisen in plaats van de goedkeuring stil toe te staan. Elke overschrijving wordt geregistreerd als een certificeringsuitzondering in het audittrail, zodat de accrediteur niet alleen kan zien welke toegang bestaat maar ook welke SoD-conflicten bewust zijn geaccepteerd en door wie.

Toegangscertificeringscampagnes — campagnefrequentie voor geclassificeerde systeemtoegang, geautomatiseerde beoordelaartoewijzing via supervisorketen, batch- versus risicogebaseerde hercertificering

Toegangscertificering is het periodieke proces van het presenteren van de huidige rechten van elke gebruiker aan een verantwoordelijke beoordelaar voor bevestiging dat de toegang nog steeds passend is. In defensie is het ook het primaire mechanisme waarmee een organisatie continue naleving van AC-2 en gerelateerde controls aantoont — de accrediteursverklaring "kunt u aantonen dat alle toegang op dit systeem momenteel geautoriseerd is?" wordt beantwoord door het dossier van de certificeringscampagne.

De minimumvloer van NIST 800-53 AC-2(j) vereist jaarlijkse beoordeling van alle accounts, maar de defensiepraktijk en de meeste accreditatieguidance verwacht meer. Een praktisch campagneschema voor geclassificeerde systemen:

• Driemaandelijks: bevoorrechte accounts (systeembeheerders, beveiligingsfunctionarissen, serviceaccounts met verhoogde rechten), accounts op cross-domainoplossingen, cryptografische sleutelbeheerssystemen en inlichtingenopslagplaatsen
• Halfjaarlijks: alle gebruikersaccounts op SECRET- en hoger geclassificeerde systemen; accounts met toegang tot financiële verplichtings- en contractfuncties
• Jaarlijks: UNCLASSIFIED-systeemaccounts; alleen-lezen-accounts zonder schrijf- of bevoorrechte mogelijkheid
• Eventgestuurd: elk account van een persoon die van rol, programma of eenheid wisselt; elk account op een systeem dat een grote wijziging doorloopt; elk account waarbij een autorisatievernieuwing of -verhoging/-verlaging heeft plaatsgevonden

Geautomatiseerde beoordelaartoewijzing is cruciaal in defensieomgevingen waar organisatiestructuren regelmatig wijzigen en het IGA-platform niet kan vertrouwen op een statische beoordelaarstoewijzing. De juiste bron voor beoordelaartoewijzing is de autoritatieve supervisorketen vanuit het HR-systeem — wanneer het IGA-platform een certificeringscampagne genereert, raadpleegt het de huidige supervisordossier voor elke identiteit en wijst het de beoordeling toe aan die supervisor. Als de supervisorpositie vacant is (een veelvoorkomend geval in ingezette omgevingen), escaleert de keten automatisch naar de supervisor van het volgende niveau, met een gedefinieerde escalatietimeout die een beveiligingsfunctionarisoverride triggert.

Batchcertificering — het tegelijkertijd presenteren van alle rechten voor een gebruikerspopulatie — is geschikt voor de halfjaarlijkse en jaarlijkse campagnes waar het doel een uitgebreide beoordeling is. Risicogebaseerde certificering is te verkiezen voor hoog-frequente beoordelingen: in plaats van het volledige rechtensets van een bevoorrechte gebruiker elk kwartaal te presenteren, identificeert het IGA-platform welke rechten zijn gewijzigd, welke zijn gebruikt (en welke niet) en welke SoD-conflicten bevatten, en presenteert alleen die voor gerichte beoordeling. Ongebruikte rechten — een bevoorrechte rol die zes maanden geleden is verleend maar nooit is gebruikt — zijn de hoogste-waarde bevinding van een risicogebaseerde campagne; ze vertegenwoordigen toegang die op papier bestaat maar de organisatie niets kost om in te trekken, en het verwijderen ervan vermindert onmiddellijk het aanvalsoppervlak dat is gedocumenteerd in het risicomodel voor detectie van interne bedreigingen in defensie.

Campagnevoltooiingspercentages zijn een achterblijvende indicator van programmakwaliteit. Een campagne die 95% voltooiing bereikt met 5% uitzonderingen is verdedigbaar. Een campagne die 60% voltooiing bereikt omdat beoordelaars de melding hebben genegeerd is een auditbevinding in wording. IGA-platforms moeten onvoltooide beoordelingen via de supervisorketen escaleren met toenemende urgentie, en beveiligingsfunctionarissen moeten realtime dashboardzichtbaarheid hebben op campagnevoltooiingspercentages in plaats van een voltooiingsprobleem pas bij de campagnedeadline te ontdekken.

Integratie met HR, identiteitsproviders en CAC/PIV — integratiearchitectuur voor DoD/NAVO PKI, CAC/PIV-gekoppelde provisioning, realtime doorgifte van autorisatie-intrekking

De integratiearchitectuur voor een defensie-IGA-platform is complexer dan elke commerciële implementatie, omdat het meerdere autoritatieve systemen omvat die geen gemeenschappelijk API-contract delen, op verschillende classificatieniveaus opereren en eigendom zijn van verschillende organisaties.

Het identiteitsanker in de US DoD-context is de Common Access Card (CAC). Elke actief-militair lid, reservist in dienst en de meeste civiele medewerkers en contractanten dragen er een. De CAC bevat drie PKI-certificaten (identiteit, e-mail en inhoudsondertekening) waarvan de distinguished names dienen als de stabiele, autoritatieve identifier voor de persoon in alle verbonden systemen. Het accountmodel van het IGA-platform moet worden gebouwd rondom de CAC-DN, niet rondom een e-mailadres of medewerkers-ID, omdat deze kunnen veranderen terwijl de CAC-DN stabiel blijft bij kaartvernieuwingen.

CAC-uitgifte- en vernieuwingsgegevens stromen vanuit het Defense Enrollment Eligibility Reporting System (DEERS) via het Real-time Automated Personnel Identification System (RAPIDS). De IGA-integratie met DEERS/RAPIDS levert drie kritieke events: kaartuitgifte (triggert accountactivering), kaartvernieuwing (triggert DN-updatepropagatie naar alle verbonden systemen) en kaartintrekking (triggert onmiddellijke accountopschorting). De intrekkingspropagatie moet bijna-realtime zijn — een ingetrokken CAC die nog 24 uur systeemtoegang verleent omdat het IGA-platform DEERS eenmaal per dag opvraagt, is een compliancefout en een beveiligingsincident in wording. Het doel is sub-uurpropagatie voor intrekkingsevents, bereikt via event-gestuurde webhooks of een hoog-frequente delta-synchronisatiefeed in plaats van batchpolling.

Propagatie van autorisatie-intrekking heeft dezelfde vereiste. De stroom is: beveiligingsfunctionaris trekt autorisatie in JPAS/DISS in → IGA-platform ontvangt event → alle accounts op het ingetrokken autorisatieniveau en hoger worden opgeschort → verbonden systemen geven de opschorting door via hun eigen IGA-connectors. Het IGA-platform is de orchestratielaag; elk verbonden systeem is verantwoordelijk voor het afdwingen van de opschorting via zijn eigen toegangscontroles, niet afhankelijk van het IGA-platform om elk systeem-API individueel aan te roepen.

Voor geallieerde defensieorganisaties die opereren onder NAVO PKI volgt de integratiearchitectuur hetzelfde patroon met nationale PKI CA's in plaats van DoD PKI. Het IGA-platform moet het juiste nationale vertrouwensanker vertrouwen en de DN-structuur van de nationale PKI-certificaten parseren, die verschilt van het DoD-formaat. Cross-domeinscenario's — een Amerikaanse liaisonofficier die opereert op het netwerk van een partnerland — vereisen federatie over vertrouwensankers, doorgaans geïmplementeerd via een PKI-brug of een missiespecifieke federatieovereenkomst die het IGA-platform vertaalt naar een tijdelijke identiteitsbinding.

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

Audittrails en compliancerapportage — NIST 800-53 AC/IA-controls, auditlogvereisten voor geclassificeerde systeemtoegang, genereren van compliance-bewijs

Het audittrail dat door een IGA-platform wordt geproduceerd is het primaire bewijsartefact voor de toegangscontrole- en identificatie-en-authenticatiefamilies van controls in een NIST 800-53-beoordeling. Dit goed doen is niet optioneel — het is het verschil tussen een accreditatiepakket dat continue compliance aantoont en een dat een Plan of Action and Milestones (POA&M) triggert voor elke toegangscontrolebevinding.

Het IGA-auditlog moet elk provisioning- en deprovisioningevent op transactieniveau vastleggen. Elk dossier moet bevatten: de betrokken identiteit, het verleende of ingetrokken recht, het tijdstip van het event, de grondslag waarop het event is uitgevoerd (geautomatiseerde workflow, managersgoedkeuring, beveiligingsfunctionarisoverride of certificeringscampagnebeslissing) en een stabiele verwijzing naar het bronevent dat de actie heeft getriggerd (de HR-dossierwijziging, het autorisatieevent, de certificeringsbeslissing). Dit detailniveau ondersteunt drie afzonderlijke auditgebruikscases: reconstructie van de toegangstoestand op elk historisch punt in de tijd, onderzoek van een specifiek toegangsevent en geaggregeerde compliancerapportage over de gebruikerspopulatie.

De NIST 800-53-controls die het meest direct worden bewezen door IGA-auditgegevens zijn:

• AC-2 (Accountbeheer): IGA-levenscyclusdossiers tonen aan dat accounts alleen worden aangemaakt voor geautoriseerde personen, op gedefinieerde frequenties worden beoordeeld en worden uitgeschakeld wanneer personen vertrekken
• AC-5 (Scheiding van taken): SoD-regelhandhavingslogboeken en uitzonderingsdossiers tonen aan dat conflicterende taken worden geïdentificeerd en beheerd
• AC-6 (Minste privilege): Rolmodelleringsdossiers en analyses van ongebruikte rechten uit certificeringscampagnes tonen aan dat toegang is beperkt tot het noodzakelijke minimum
• IA-2 (Identificatie en authenticatie): CAC/PIV-bindingsdossiers tonen aan dat meervoudige authenticatie wordt afgedwongen voor alle gebruikersaccounts op geclassificeerde systemen
• IA-4 (Identifierbeheer): Joiner- en leaver-dossiers tonen aan dat accountidentifiers worden toegewezen en uitgeschakeld via een gedefinieerd beheerproces
• IA-5 (Authenticatorbeheer): Kaartbindings- en kaartintrekkingspropagatiesdossiers tonen aan dat authenticators worden beheerd en ingetrokken op een gecontroleerde, tijdige manier

Compliancerapportage vanuit het IGA-platform moet worden ontworpen om vooraf geformatteerde bewijspakketten te produceren, niet onbewerkte logexports. Een accrediteur die AC-2 evalueert, moet een rapport kunnen ontvangen met alle actieve accounts, de datum van de laatste beoordeling, of er accounts zijn die achterstallig zijn voor certificering en een telling van uitzonderingen — niet een event-log met 500.000 rijen en een verzoek om "het zelf te parseren." Het ontwerpen van deze rapporten vóór de eerste accreditatiebeoordeling, en het valideren dat de rapporten de implementatie van de controls nauwkeurig weergeven, is het verschil tussen een bewijsverzamelingsproces van twee dagen en een crisis van twee weken.

Onveranderlijkheid van auditlogs vereist write-once-opslag of cryptografische hash-chaining. Defensie-retentievereisten voor geclassificeerde systeemtoegangslogboeken lopen doorgaans 3–7 jaar afhankelijk van de missie en het classificatieniveau van het systeem; sommige nucleair-gerelateerde en strategische systemen hebben langere retentievereisten. De opslaglaag moet dienovereenkomstig worden gedimensioneerd en levenscyclusgewijs worden beheerd, met ophaaleprocedures die functioneren wanneer de oorspronkelijke softwarestack niet meer wordt ondersteund. Een retentievereiste die op dag één wordt vervuld maar in jaar zes onleesbare logs oplevert, is een compliance-tekortkoming op de tijdlijn die er werkelijk toe doet.