Guvernanța și administrarea identității pentru organizațiile de apărare

Guvernanța și administrarea identității (IGA) este disciplina de control sistematic al cine are acces la ce, pentru cât timp și pe ce autoritate — și de producere a dovezilor auditabile că accesul este adecvat în orice moment. Într-o organizație comercială, IGA gestionează roluri, drepturi și revizuiri periodice în cadrul unui ciclu de viață al angajaților condus de HR. Într-o organizație de apărare, IGA trebuie să facă toate acestea și să aplice simultan o a doua rețea de control al accesului construită din niveluri de autorizare de securitate, apartenențe la compartimente, determinări de necesitate-de-a-cunoaște și autorizații de program. Diferența dintre aceste două enunțuri de problemă este locul în care eșuează majoritatea implementărilor comerciale IGA atunci când sunt transplantate în apărare. Acest articol abordează deciziile de inginerie care închid acel decalaj — acoperind provizionarea conștientă de autorizare, ingineria rolurilor pentru patrimonii multi-clasificare, separarea sarcinilor în condiții de echipe mici, proiectarea certificării accesului, integrarea CAC/PIV și arhitectura traseelor de audit necesare pentru a supraviețui unei acreditări RMF. Pentru stratul de broker de credențiale de care IGA depinde la momentul accesului privilegiat, consultați analiza noastră despre gestionarea accesului privilegiat pentru apărare.

De ce IGA în apărare diferă de cea din mediul enterprise — niveluri de autorizare ca dimensiune suplimentară de acces, gestionarea compartimentelor, aplicarea necesității-de-a-cunoaște

Într-o întreprindere comercială, controlul accesului are două dimensiuni semnificative: cine este utilizatorul (identitate) și ce rol sau grup aparține (drept). O organizație de apărare adaugă o a treia dimensiune care este ortogonală față de ambele: la ce este autorizat și autorizat utilizatorul să acceseze. Un inginer de rețea senior poate deține o autorizare SECRET valabilă, dar poate să nu aibă autorizație de acces la compartimentul de informații care rulează pe aceeași rețea la nivel SECRET. Un analist junior poate fi autorizat la TOP SECRET și citit în mod specific într-un compartiment la care inginerul senior nu are acces. Nici vechimea, nici ierarhia organizațională nu rezolvă aceste decizii — numai înregistrarea formală de autorizare o face.

Platformele comerciale IGA — SailPoint IdentityNow, Saviynt, Omada, One Identity — sunt proiectate pentru problema bidimensională. Pot stoca atribute personalizate și, cu suficientă personalizare, pot aplica constrângeri de nivel de autorizare, dar nu modelează nativ compartimentele, mențiunile de manipulare sau autorizațiile de acces la program ca obiecte de primă clasă. Platforma vă va permite să adăugați un atribut personalizat numit „clearance_level" și să scrieți o regulă de provizionare care îl verifică. Platforma nu va menține, fără dezvoltare personalizată, un flux live dintr-un sistem de securitate a personalului, nu va rezolva diferența dintre o înregistrare formală de îndoctrinare SCI și o pretenție auto-raportată de autorizare sau nu va modela rețeaua compartimentelor cu propriile fluxuri de citire și scoatere.

Aplicarea necesității-de-a-cunoaște este cea mai acută diferență. În IGA de întreprindere, accesul este acordat de obicei la o clasă de resurse — „acest utilizator poate accesa lacul de date Financiar". În apărare, accesul la aceeași resursă poate fi acordat Utilizatorului A, dar nu Utilizatorului B, chiar dacă ambii dețin autorizarea corectă, deoarece Utilizatorul B nu a fost citit formal în programul care produce datele. IGA trebuie să aplice acest lucru la momentul provizionării și la momentul recertificării, interogând înregistrările autoritative de acces la program mai degrabă decât bazându-se pe atestarea unui manager. Decalajul dintre „managerul meu a aprobat accesul meu" și „înregistrarea autoritativă confirmă că sunt citit în acest program" este exact decalajul care produce constatări de audit și, în cel mai rău caz, divulgări neautorizate.

Implicația practică este că o implementare IGA de apărare necesită dezvoltarea de conectori și personalizarea fluxurilor de lucru dincolo de ceea ce livrează orice produs IGA comercial standard. Bugetați pentru aceasta din timp, tratați fluxurile de date de autorizare și compartiment ca pe cea mai critică lucrare de integrare din proiect și luați în considerare dacă produsul comercial existent poate fi extins pentru a îndeplini cerința sau dacă o soluție IGA specifică apărării (cum ar fi cele construite pe arhitectura serviciului de identitate enterprise al IC) este punctul de plecare corect. Modelul zero trust pentru software de apărare depinde de IGA pentru furnizarea de date precise și continuu validate privind drepturile — fără acesta, motoarele de politici iau decizii de autorizare pe atribute de identitate învechite sau neverificabile.

Ciclul de viață joiner-mover-leaver într-un mediu clasificat — declanșatoare automate de provizionare, integrare de verificare a autorizării, tranziții de rol la reasignare

Ciclul de viață joiner-mover-leaver (JML) este bucla operațională fundamentală a oricărei implementări IGA. În apărare, fiecare fază a buclei are constrângeri suplimentare care o încetinesc, dar care o fac și mai consecventă dacă este greșit executată.

Fluxul de lucru joiner. Un eveniment joiner se declanșează atunci când un sistem HR sau de personal autoritar creează o nouă înregistrare — angajat nou, contractor nou, misiune temporară nouă. În apărare, provizionarea nu trebuie să înceapă până când platforma IGA nu a confirmat independent nivelul de autorizare adjudecat al persoanei din sistemul de securitate a personalului (JPAS sau DISS în contextul US DoD; echivalente naționale în organizațiile aliate de apărare) și nu a confirmat un DN valid de card CAC sau PIV din sistemul de înregistrare. Secvența contează: verificarea autorizării controlează provizionarea, nu invers. O platformă IGA care provizionează mai întâi un cont și verifică ulterior autorizarea într-un job de fundal a creat deja o fereastră exploatabilă.

Fluxul de lucru joiner ar trebui să declanșeze și o verificare a accesului la compartiment pentru orice drept care necesită citire formală într-un program. Dacă înregistrarea de citire există în sistemul autoritar de acces la program, provizionarea continuă. Dacă nu există, dreptul este suprimat și se creează un element de flux de lucru pentru ofițerul de securitate pentru a iniția procesul formal de îndoctrinare. Contul există; dreptul sensibil nu există, până când înregistrarea pe hârtie nu există pentru a-l justifica.

Fluxul de lucru mover. Reasignarea în organizațiile de apărare este frecventă și consecventă. O persoană care se mută de la un program la altul pierde de obicei accesul la sistemele primului program și câștigă acces la sistemele celui de-al doilea. Fluxul de lucru IGA mover trebuie să rezolve această tranziție deterministic: să calculeze delta de drepturi dintre setul de roluri vechi și cel nou, să revoce ceea ce nu mai este adecvat și să provizioneze ceea ce este nou justificat — totul controlat de aceleași verificări de autorizare și compartiment. Acolo unde noul rol necesită o autorizare mai înaltă decât cea pe care o deține în prezent persoana, contul pentru acel domeniu de clasificare este suprimat în așteptarea unei determinări de upgrade de autorizare.

Cazul mover mai dificil este detașarea temporară (TDY) sau detașarea. Persoana își păstrează setul de roluri al unității de acasă și dobândește un set de roluri suplimentare limitate în timp pe durata misiunii. IGA trebuie să modeleze acest lucru fără a oferi persoanei un acces permanent ridicat care supraviețuiește sfârșitului misiunii. Atribuirile de roluri limitate în timp cu expirare automată, revizuite atât de ofițerul de securitate al unității de acasă, cât și al celei gazdă, sunt modelul corect.

Fluxul de lucru leaver. Fluxul de lucru leaver — declanșat de încetarea contractului, pensionare sau revocare a autorizării — este faza cu cele mai mari riscuri și cea în care implementările comerciale IGA eșuează cel mai frecvent în apărare. Așteptarea este deprovizionarea în aceeași zi pentru toate conturile din toate sistemele conectate, indiferent dacă persoana și-a returnat fizic CAC-ul, s-a deconectat de la stația de lucru sau a finalizat vreun proces de predare HR. Platforma IGA nu trebuie să aștepte ca o înregistrare HR să ajungă la statutul „terminat" înainte de a revoca accesul — evenimentul de revocare a autorizării din sistemul de securitate a personalului este declanșatorul și trebuie să se propage în timp aproape real.

# Ținte SLA flux de lucru leaver (context apărare)
clearance_revocation_to_AD_disable:   < 1 oră
AD_disable_to_all_app_deprovisioning: < 4 ore
CAC_invalidation_propagation:         < 1 oră (DEERS → sisteme conectate)
audit_closure_record_generated:       aceeași zi lucrătoare
physical_access_revocation:           aceeași zi (integrare sistem acces fizic)

Ingineria rolurilor pentru medii multi-clasificare — proiectarea modelului de roluri, seturi de roluri delimitate prin autorizare, hybrid ABAC vs RBAC pentru compartimente

Ingineria rolurilor — procesul de definire și menținere a modelului de roluri pe care îl aplică platforma IGA — este partea cea mai consumatoare de timp a unei implementări IGA de apărare și cea care are cel mai mare potențial de a produce datorii tehnice persistente dacă este realizată prost. Constrângerea fundamentală este că rolurile trebuie să fie stabile în cazul schimbărilor organizaționale, deoarece fiecare schimbare de rol în platforma IGA este un eveniment administrativ care necesită control al modificărilor, retestare și, potențial, o campanie de recertificare.

Prima decizie de proiectare este separarea domeniilor. Organizațiile de apărare operează în mai multe domenii de clasificare — cel puțin NECLASIFICAT și SECRET, adesea și TOP SECRET și una sau mai multe enclave SCI. Rolurile trebuie definite în cadrul fiecărui domeniu separat și stocate în instanțe de director separate. Un rol denumit „analist" în domeniul NECLASIFICAT și un rol denumit „analist" în domeniul SECRET nu sunt același rol — au drepturi diferite, condiții prealabile de autorizare diferite și sunt gestionate de ofițeri de securitate diferiți. Contopirea lor într-un singur rol inter-domeniu este o greșeală arhitecturală pe care acreditatorii o vor detecta imediat și care creează un risc real de scurgere de drepturi inter-domeniu.

În cadrul fiecărui domeniu, rolurile ar trebui să fie funcționale mai degrabă decât organizaționale. Un rol organizațional — „membru al Celulei de Informații din Escadrila a 3-a" — este stabil numai atât timp cât organizația este stabilă. Un rol funcțional — „analist de informații, sisteme clasificate" — călătorește cu funcția persoanei dincolo de granițele organizaționale și supraviețuiește reorganizărilor care au loc la fiecare optsprezece luni în majoritatea mediilor de apărare. Rolurile funcționale se combină și mai curat: o persoană cu un rol dublu (analist și administrator de secțiune) primește două roluri funcționale, fiecare gestionat și certificat independent.

Gestionarea compartimentelor necesită un strat de control al accesului bazat pe atribute (ABAC) peste fundația RBAC. Rolul stabilește ce poate face persoana; atributele compartimentului din înregistrarea de identitate a acesteia stabilesc ce poate vedea în timp ce o face. Acest model hibrid — RBAC pentru drepturi structurale, ABAC pentru filtrare la nivel de date — este arhitectura care se scalează la complexitatea unei organizații reale de apărare fără a necesita un rol nou de fiecare dată când este creat un nou compartiment.

# Schema atributelor de identitate (simplificată)
{
  "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"
}

Gestionarea ciclului de viață al rolurilor — adăugarea, modificarea și retragerea rolurilor — necesită un proces de guvernanță separat față de gestionarea ciclului de viață al utilizatorilor. Rolurile noi ar trebui să necesite aprobarea ofițerului de securitate, o analiză a impactului drepturilor și o validare în mediul de test înainte de promovarea în producție. Rolurile retrase necesită un plan de migrare care mută deținătorii actuali de roluri la roluri de înlocuire înainte ca vechiul rol să fie eliminat, prevenind drepturile orfane în sistemele conectate.

Separarea sarcinilor în programele de apărare — proiectarea regulilor SoD pentru achiziții și sustenabilitate, controale compensatorii pentru excepțiile echipelor mici

Separarea sarcinilor (SoD) este principiul de control conform căruia nicio persoană nu ar trebui să dețină ambele părți ale unei tranzacții cu risc ridicat — capacitatea de a iniția și aproba o obligație financiară, sau de a solicita și acorda propriul acces, sau de a scrie și certifica o versiune de software. În mediile de achiziție și sustenabilitate a apărării, eșecurile SoD au produs unele dintre cele mai costisitoare cazuri de fraudă și management defectuos înregistrate: un ofițer de contractare care putea certifica și plăți de facturi; un administrator de sistem care putea modifica atât codul aplicației, cât și controalele sale de acces; un manager logistic care putea atât comanda, cât și certifica primirea materialelor.

IGA aplică SoD printr-un set de reguli care identifică perechile de drepturi conflictuale și împiedică orice identitate unică să le dețină pe ambele. Setul de reguli trebuie conceput ținând cont de fluxurile de lucru specifice cu risc ridicat ale achizițiilor de apărare, nu împrumutat dintr-un șablon comercial de servicii financiare. Perechile cheie de conflict în contexte de apărare includ:

• Inițierea contractului și aprobarea contractului (SoD achiziții)
• Trimiterea cererii de acces și aprobarea accesului (SoD IAM)
• Comiterea codului și autorizarea implementării codului (SoD DevSecOps)
• Generarea cheii criptografice și certificarea custodianului cheii
• Autorizarea eliminării activelor și certificarea primirii activelor
• Înregistrarea obligației financiare și certificarea obligației

Provocarea de inginerie în apărare este că multe programe rulează cu echipe foarte mici — uneori mai puțin de zece personal autorizat acoperind toate rolurile. O regulă SoD care necesită ca două persoane diferite să dețină drepturile conflictuale poate fi neaplicabilă într-un detașament de trei persoane desfășurat în avans. Răspunsul corect IGA nu este dezactivarea regulilor SoD pentru echipele mici; este implementarea unui flux de lucru structurat de excepție cu controale compensatorii.

Un control compensator pentru o excepție SoD ar trebui să includă: acceptarea riscului documentată semnată de oficialul autorizator; un marcaj de audit îmbunătățit pentru toate tranzacțiile executate de titularul excepției, astfel încât fiecare astfel de tranzacție să fie prezentată în următoarea revizuire de conformitate; o cerință de revizuire secundară obligatorie (tranzacția este completă, dar un al doilea personal autorizat trebuie să revizuiască și să contrasemneze într-o fereastră de timp definită); și o dată de expirare a excepției care declanșează reevaluarea în loc de perpetuarea silențioasă.

Regulile SoD apar și în cursul campaniilor de certificare a accesului. Când un revizor de recertificare aprobă accesul pentru cineva care deține o pereche de drepturi conflictuale, platforma IGA ar trebui să prezinte conflictul vizibil și să necesite o decizie explicită de depășire mai degrabă decât să permită silențios aprobarea. Fiecare depășire este înregistrată ca o excepție de certificare în traseul de audit, asigurând că acreditatorul poate vedea nu doar ce acces există, ci și ce conflicte SoD au fost acceptate în cunoștință de cauză și de cine.

Campanii de certificare a accesului — frecvența campaniilor pentru accesul la sistemele clasificate, atribuirea automată a revizorilor prin lanțul de supraveghere, recertificare în lot față de cea bazată pe risc

Certificarea accesului este procesul periodic de prezentare a drepturilor curente ale fiecărui utilizator unui revizor responsabil pentru atestarea că accesul rămâne adecvat. În apărare, este și mecanismul principal prin care o organizație demonstrează conformitatea continuă cu AC-2 și controalele conexe — întrebarea acreditatorului „puteți să-mi arătați că tot accesul pe acest sistem este autorizat în prezent?" este răspunsă prin înregistrarea campaniei de certificare.

Nivelul minim NIST 800-53 AC-2(j) necesită revizuirea anuală a tuturor conturilor, dar practica în domeniul apărării și majoritatea ghidurilor de acreditare așteaptă mai mult. Un program practic de campanii pentru sistemele clasificate:

• Trimestrial: conturi privilegiate (administratori de sistem, ofițeri de securitate, conturi de servicii cu drepturi ridicate), conturi pe soluții inter-domeniu, sisteme de gestionare a cheilor criptografice și depozite de informații
• Semestrial: toate conturile de utilizatori pe sisteme SECRET și superioare; conturi cu acces la funcții de obligație financiară și contractare
• Anual: conturi de sistem NECLASIFICAT; conturi doar-citire fără capacitate de scriere sau privilegiată
• Bazat pe evenimente: orice cont aparținând unui individ care schimbă rolul, programul sau unitatea; orice cont pe un sistem care finalizează o schimbare majoră; orice cont în care a avut loc o reînnoire sau upgrade/downgrade de autorizare

Atribuirea automată a revizorilor este critică în mediile de apărare unde structurile organizaționale se schimbă frecvent și platforma IGA nu poate depinde de o mapare statică a revizorilor. Sursa corectă pentru atribuirea revizorilor este lanțul de supraveghere autoritar din sistemul HR — când platforma IGA generează o campanie de certificare, interogează înregistrarea curentă a supraveghetorului pentru fiecare identitate și atribuie revizuirea acelui supraveghetor. Când poziția supraveghetorului este vacantă (o situație frecventă în mediile desfășurate), lanțul escaladează automat la supraveghetorul de nivel următor, cu un timeout de escaladare definit care declanșează o depășire a ofițerului de securitate.

Certificarea în lot — prezentarea tuturor drepturilor pentru o populație de utilizatori deodată — este adecvată pentru campaniile semestriale și anuale unde obiectivul este o revizuire cuprinzătoare. Certificarea bazată pe risc este preferabilă pentru revizuirile de înaltă frecvență: în loc să prezinte întregul set de drepturi al unui utilizator privilegiat în fiecare trimestru, platforma IGA identifică ce drepturi s-au schimbat, care au fost utilizate (și care nu) și care poartă conflicte SoD, și prezintă numai acele pentru revizuire focalizată. Drepturile neutilizate — un rol privilegiat acordat cu șase luni în urmă care nu a fost niciodată exercitat — sunt constatarea cu cea mai mare valoare dintr-o campanie bazată pe risc; ele reprezintă acces care există pe hârtie dar nu costă nimic organizației să fie revocat, iar eliminarea lor imediată reduce suprafața de atac documentată în modelul de risc al detectării amenințărilor interne pentru apărare.

Ratele de finalizare a campaniei sunt un indicator întârziat al sănătății programului. O campanie care atinge 95% finalizare cu 5% excepții este defensibilă. O campanie care atinge 60% finalizare deoarece revizuitorii au ignorat notificarea este o constatare de audit care așteaptă să se producă. Platformele IGA ar trebui să escaladeze revizuirile incomplete prin lanțul de supraveghere cu urgență crescândă, iar ofițerii de securitate ar trebui să aibă vizibilitate în tabloul de bord asupra ratelor de finalizare a campaniei în timp real, mai degrabă decât să descopere o problemă de finalizare la termenul limită al campaniei.

Integrare cu HR, furnizori de identitate și CAC/PIV — arhitectura de integrare pentru DoD/PKI NATO, provizionare legată de CAC/PIV, propagarea revocării autorizării în timp real

Arhitectura de integrare pentru o platformă IGA de apărare este mai complexă decât orice implementare comercială deoarece acoperă mai multe sisteme autoritative care nu partajează un contract API comun, operează la niveluri de clasificare diferite și sunt deținute de organizații diferite.

Ancora de identitate în contextul US DoD este Common Access Card (CAC). Fiecare militar activ, rezervist în serviciu și majoritatea angajaților civili și contractorilor poartă unul. CAC-ul conține trei certificate PKI (identitate, email și semnare de conținut) ale căror nume distinse servesc ca identificator stabil și autoritar pentru persoană în toate sistemele conectate. Modelul de cont al platformei IGA trebuie construit în jurul DN-ului CAC, nu al unei adrese de email sau ID de angajat, deoarece acestea se pot schimba în timp ce DN-ul CAC rămâne stabil pe parcursul reînnoirilor cardurilor.

Datele de emitere și reînnoire a CAC-ului curg din Defense Enrollment Eligibility Reporting System (DEERS) prin Real-time Automated Personnel Identification System (RAPIDS). Integrarea IGA cu DEERS/RAPIDS furnizează trei evenimente critice: emiterea cardului (declanșează activarea contului), reînnoirea cardului (declanșează propagarea actualizării DN la toate sistemele conectate) și revocarea cardului (declanșează suspendarea imediată a contului). Propagarea revocării trebuie să fie aproape în timp real — un CAC revocat care încă acordă acces la sistem timp de 24 de ore deoarece platforma IGA sondează DEERS o dată pe zi este un eșec de conformitate și un incident de securitate care așteaptă să se producă. Ținta este propagarea sub o oră pentru evenimentele de revocare, realizată prin webhook-uri bazate pe evenimente sau un flux delta de înaltă frecvență mai degrabă decât sondare în lot.

Propagarea revocării autorizării are aceeași cerință. Fluxul este: ofițerul de securitate a personalului revocă autorizarea în JPAS/DISS → platforma IGA primește evenimentul → toate conturile la nivelul de autorizare revocat și mai sus sunt suspendate → sistemele conectate propagă suspendarea prin propriii conectori IGA. Platforma IGA este stratul de orchestrare; fiecare sistem conectat este responsabil pentru aplicarea suspendării prin propriile sale controale de acces, fără a se baza pe platforma IGA pentru a apela individual API-ul fiecărui sistem.

Pentru organizațiile aliate de apărare care operează sub PKI al alianței, arhitectura de integrare urmează același tipar cu CA-uri PKI naționale. Platforma IGA trebuie să aibă încredere în ancora națională de încredere adecvată și să analizeze structura DN a certificatelor PKI naționale, care diferă de formatul DoD. Scenariile inter-domeniu — un ofițer de legătură american care operează pe rețeaua unei națiuni partenere — necesită federare prin ancorele de încredere, implementată de obicei printr-un pod PKI sau un acord de federare specific misiunii pe care platforma IGA îl traduce într-o legătură de identitate temporară.

# Topologie de integrare IGA
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)

Trasee de audit și raportare de conformitate — controale NIST 800-53 AC/IA, cerințe de jurnal de audit pentru accesul la sistemele clasificate, generarea de dovezi de conformitate

Traseul de audit produs de o platformă IGA este artefactul principal de dovezi pentru familiile de controale de control al accesului și identificare-și-autentificare dintr-o evaluare NIST 800-53. A face acest lucru corect nu este opțional — este diferența dintre un pachet de acreditare care demonstrează conformitatea continuă și unul care declanșează un Plan de Acțiune și Jaloane (POA&M) pentru fiecare constatare de control al accesului.

Jurnalul de audit IGA trebuie să captureze fiecare eveniment de provizionare și deprovizionare la nivel de tranzacție. Fiecare înregistrare ar trebui să conțină: identitatea afectată, dreptul acordat sau revocat, momentul evenimentului, autoritatea sub care a fost executat evenimentul (flux de lucru automatizat, aprobare manager, depășire ofițer de securitate sau decizie de campanie de certificare) și o referință stabilă la evenimentul sursă care a declanșat acțiunea (schimbarea înregistrării HR, evenimentul de autorizare, decizia de certificare). Acest nivel de detaliu susține trei cazuri de utilizare distincte de audit: reconstituirea stării de acces la orice moment istoric în timp, investigarea unui eveniment specific de acces și raportarea agregată de conformitate în întreaga populație de utilizatori.

Controalele NIST 800-53 cel mai direct evidențiate de datele de audit IGA sunt:

• AC-2 (Gestionarea conturilor): Înregistrările ciclului de viață IGA demonstrează că conturile sunt create numai pentru persoane autorizate, revizuite la frecvențe definite și dezactivate când persoanele pleacă
• AC-5 (Separarea sarcinilor): Jurnalele de aplicare a regulilor SoD și înregistrările de excepție demonstrează că sarcinile conflictuale sunt identificate și gestionate
• AC-6 (Privilegiu minim): Înregistrările de inginerie a rolurilor și analiza drepturilor neutilizate din campaniile de certificare demonstrează că accesul este limitat la minimul necesar
• IA-2 (Identificare și autentificare): Înregistrările de legare CAC/PIV demonstrează că autentificarea multifactor este aplicată pentru toate conturile de utilizatori pe sistemele clasificate
• IA-4 (Gestionarea identificatorilor): Înregistrările joiner și leaver demonstrează că identificatorii de cont sunt atribuiți și dezactivați în cadrul unui proces de gestionare definit
• IA-5 (Gestionarea autentificatorilor): Înregistrările de legare și revocare a cardurilor demonstrează că autentificatorii sunt gestionați și revocați într-un mod controlat și oportun

Raportarea conformității de pe platforma IGA ar trebui proiectată pentru a produce pachete de dovezi preformatate, nu exporturi brute de jurnal. Un acreditator rugat să evalueze AC-2 ar trebui să poată primi un raport care arată toate conturile active, data la care fiecare a fost revizuit ultima dată, dacă vreunul are o certificare întârziată și un număr de excepții — nu un jurnal de 500.000 de rânduri de evenimente și o cerere de „analizați-l singuri". Proiectarea acestor rapoarte înainte de prima revizuire de acreditare și validarea că rapoartele reflectă cu exactitate implementarea controalelor este diferența dintre un proces de colectare a dovezilor de două zile și o criză de două săptămâni.

Imutabilitatea jurnalului de audit necesită stocare write-once sau înlănțuire de hash criptografic. Cerințele de retenție pentru apărare pentru jurnalele de acces la sistemele clasificate rulează de obicei 3–7 ani în funcție de misiunea sistemului și nivelul de clasificare; unele sisteme adiacente nucleare și strategice au cerințe de retenție mai lungi. Nivelul de stocare trebuie dimensionat și gestionat în consecință, cu proceduri de recuperare care funcționează când stiva software originală nu mai este suportată. O cerință de retenție care este satisfăcută în prima zi dar produce jurnale ilizibile în al șaselea an este un eșec de conformitate pe cronologia care contează.