Zarządzanie tożsamością i administracja dla organizacji obronnych

Zarządzanie tożsamością i administracja (IGA) to dyscyplina polegająca na systematycznym kontrolowaniu, kto ma dostęp do jakich zasobów, na jak długo i na jakiej podstawie — oraz na wytwarzaniu audytowalnych dowodów, że dostęp jest uzasadniony w każdym momencie. W organizacji komercyjnej IGA zarządza rolami, uprawnieniami i okresowymi przeglądami w ramach cyklu życia pracownika sterowanego przez system kadrowy. W organizacji obronnej IGA musi robić to wszystko, jednocześnie egzekwując drugą siatkę kontroli dostępu zbudowaną z poziomów poświadczeń bezpieczeństwa, przynależności do przedziałów (compartments), określeń potrzeby wiedzy (need-to-know) oraz autoryzacji programowych. Przepaść między tymi dwoma zestawami wymagań jest dokładnie tam, gdzie większość komercyjnych wdrożeń IGA ponosi porażkę, gdy są one przenoszone do sektora obronnego. Niniejszy artykuł omawia decyzje inżynieryjne, które tę przepaść zamykają — obejmując provisionowanie uwzględniające uprawnienia, inżynierię ról dla środowisk wielopoziomowych, separację obowiązków w warunkach małych zespołów, projektowanie kampanii certyfikacji dostępu, integrację z CAC/PIV oraz architekturę ścieżki audytu wymaganą do pomyślnego przejścia akredytacji RMF. W zakresie warstwy brokera poświadczeń, na której IGA polega w chwilach dostępu uprzywilejowanego, zob. nasze omówienie zarządzania dostępem uprzywilejowanym w sektorze obronnym.

Dlaczego IGA w sektorze obronnym różni się od wdrożeń korporacyjnych — poziomy poświadczeń bezpieczeństwa jako dodatkowy wymiar dostępu, zarządzanie przedziałami, egzekwowanie zasady need-to-know

W komercyjnym przedsiębiorstwie kontrola dostępu ma dwa znaczące wymiary: kim jest użytkownik (tożsamość) oraz do jakiej roli lub grupy należy (uprawnienie). Organizacja obronna dodaje trzeci wymiar, ortogonalny do obu poprzednich: do czego użytkownik jest poświadczony i upoważniony. Starszy inżynier sieciowy może posiadać ważne poświadczenie SECRET, ale nie mieć autoryzacji dostępu do przedziału wywiadowczego działającego w tej samej sieci SECRET. Młodszy analityk może być poświadczony do poziomu TOP SECRET i być formalnie wprowadzony do przedziału, do którego starszy inżynier nie ma wstępu. Żaden staż pracy ani hierarchia organizacyjna nie rozstrzygają tych decyzji — rozstrzyga wyłącznie formalny zapis autoryzacji.

Komercyjne platformy IGA — SailPoint IdentityNow, Saviynt, Omada, One Identity — są zaprojektowane dla problemu dwuwymiarowego. Potrafią przechowywać atrybuty niestandardowe i przy wystarczającej konfiguracji mogą egzekwować ograniczenia wynikające z poziomu poświadczenia, lecz nie modelują natywnie przedziałów, zastrzeżeń obsługi ani autoryzacji dostępu do programów jako obiektów pierwszej klasy. Platforma pozwoli dodać atrybut niestandardowy o nazwie „clearance_level" i napisać regułę provisionowania, która go sprawdza. Platforma nie będzie jednak — bez prac deweloperskich na zamówienie — utrzymywać aktywnego kanału danych z systemu bezpieczeństwa osobowego, rozróżniać między formalnym zapisem introdukcji SCI a samozgłoszonym roszczeniem do poświadczenia ani modelować siatki przedziałów z ich własnymi przepływami wprowadzania i wyprowadzania.

Egzekwowanie zasady need-to-know jest najwyraźniejszą różnicą. W korporacyjnym IGA dostęp jest zazwyczaj przyznawany do klasy zasobów — „ten użytkownik może uzyskać dostęp do data lake finansów". W sektorze obronnym dostęp do tego samego zasobu może być przyznany użytkownikowi A, ale nie użytkownikowi B, mimo że oboje posiadają właściwe poświadczenie — ponieważ użytkownik B nie został formalnie wprowadzony do programu, który produkuje te dane. IGA musi to egzekwować na etapie provisionowania i na etapie recertyfikacji, zapytując autorytatywne rejestry dostępu do programów, a nie polegając na atestacji kierownika. Przepaść między „mój przełożony zatwierdził mój dostęp" a „autorytatywny rejestr potwierdza, że jestem wprowadzony do tego programu" jest dokładnie tym, co generuje ustalenia audytowe i — w najgorszych przypadkach — nieuprawdzione ujawnienia.

Praktyczna implikacja jest taka, że wdrożenie IGA w sektorze obronnym wymaga opracowania konektorów i konfiguracji przepływów pracy wykraczających poza to, co jakikolwiek gotowy produkt IGA oferuje w standardzie. Należy uwzględnić to w budżecie z góry, traktować kanały danych o poświadczeniach i przedziałach jako najbardziej krytyczną pracę integracyjną w projekcie oraz rozważyć, czy istniejący produkt komercyjny można rozszerzyć tak, by spełnić wymóg, czy też lepszym punktem wyjścia jest rozwiązanie IGA specjalnie dla sektora obronnego (takie jak budowane na architekturze enterprise identity service IC). Model zero trust dla oprogramowania obronnego zależy od dostarczania przez IGA dokładnych, ciągle walidowanych danych o uprawnieniach — bez nich silniki polityk podejmują decyzje autoryzacyjne na podstawie przestarzałych lub nieweryfikowalnych atrybutów tożsamości.

Cykl joiner-mover-leaver w środowisku niejawnym — zautomatyzowane wyzwalacze provisionowania, integracja z weryfikacją poświadczeń, zmiany ról przy przeniesieniu

Cykl joiner-mover-leaver (JML) to podstawowa pętla operacyjna każdego wdrożenia IGA. W sektorze obronnym każda faza tej pętli wiąże się z dodatkowymi ograniczeniami, które ją spowalniają, ale jednocześnie sprawiają, że błędy są bardziej kosztowne.

Przepływ joiner. Zdarzenie joiner jest wyzwalane, gdy autorytatywny system kadrowy lub personalny tworzy nowy rekord — nowy pracownik, nowy wykonawca, nowe tymczasowe przypisanie. W sektorze obronnym provisionowanie nie może się rozpocząć, zanim platforma IGA nie potwierdzi niezależnie adjudykowanego poziomu poświadczenia bezpieczeństwa danej osoby z systemu bezpieczeństwa osobowego (JPAS lub DISS w kontekście US DoD; odpowiedniki krajowe w sojuszniczych organizacjach obronnych) oraz nie potwierdzi ważnej nazwy wyróżniającej (DN) karty CAC lub PIV z systemu rejestracyjnego. Kolejność ma znaczenie: weryfikacja poświadczenia warunkuje provisionowanie, a nie odwrotnie. Platforma IGA, która najpierw provisionuje konto, a następnie sprawdza poświadczenie w tle, już stworzyła podatne okno czasowe.

Przepływ joiner powinien również uruchamiać weryfikację dostępu do przedziału dla każdego uprawnienia wymagającego formalnego wprowadzenia do programu. Jeśli zapis o wprowadzeniu istnieje w autorytatywnym systemie dostępu do programu, provisionowanie przebiega dalej. Jeśli nie — uprawnienie jest blokowane i tworzony jest element przepływu pracy dla oficera bezpieczeństwa w celu zainicjowania formalnego procesu indoktrynacji. Konto istnieje; wrażliwe uprawnienie nie istnieje, dopóki nie ma dokumentacji uzasadniającej je.

Przepływ mover. Przeniesienia służbowe w organizacjach obronnych są częste i istotne. Osoba przenoszona z jednego programu do drugiego zazwyczaj traci dostęp do systemów pierwszego programu i uzyskuje dostęp do systemów drugiego. Przepływ mover w IGA musi deterministycznie rozwiązywać to przejście: obliczać delta uprawnień między starym zestawem ról a nowym, cofać to, co już nie jest właściwe, i provisionować to, co jest teraz uzasadnione — wszystko uwarunkowane tymi samymi sprawdzeniami poświadczeń i przedziałów. Gdy nowa rola wymaga wyższego poświadczenia niż posiadane przez daną osobę, konto dla tej domeny klasyfikacji jest blokowane do czasu ustalenia dotyczącego podwyższenia poświadczenia.

Trudniejszym przypadkiem movera jest tymczasowe oddelegowanie (TDY) lub sekondowanie. Osoba zachowuje zestaw ról jednostki macierzystej i nabywa ograniczony czasowo uzupełniający zestaw ról na czas trwania przypisania. IGA musi to modelować bez nadawania osobie trwale podwyższonego dostępu, który przetrwa koniec przypisania. Granty ról ograniczone czasowo z automatycznym wygaśnięciem, weryfikowane przez oficerów bezpieczeństwa jednostki macierzystej i przyjmującej, są właściwym wzorcem.

Przepływ leaver. Przepływ leaver — wyzwalany przez zakończenie zatrudnienia, wygaśnięcie kontraktu, przejście na emeryturę lub cofnięcie poświadczenia bezpieczeństwa — to faza o najwyższej stawce i ta, w której komercyjne wdrożenia IGA najczęściej zawodzą w sektorze obronnym. Oczekiwaniem jest deprovisionowanie wszystkich kont we wszystkich podłączonych systemach tego samego dnia, niezależnie od tego, czy dana osoba fizycznie zwróciła kartę CAC, wylogowała się ze stacji roboczej lub ukończyła jakikolwiek proces odejścia w systemie HR. Platforma IGA nie może czekać, aż rekord HR osiągnie status „zakończony" przed cofnięciem dostępu — zdarzenie cofnięcia poświadczenia z systemu bezpieczeństwa osobowego jest wyzwalaczem i musi propagować się w czasie zbliżonym do rzeczywistego.

# Docelowe SLA przepływu leaver (kontekst obronny)
clearance_revocation_to_AD_disable:   < 1 godzina
AD_disable_to_all_app_deprovisioning: < 4 godziny
CAC_invalidation_propagation:         < 1 godzina (DEERS → podłączone systemy)
audit_closure_record_generated:       tego samego dnia roboczego
physical_access_revocation:           tego samego dnia (integracja z systemem kontroli dostępu fizycznego)

Inżynieria ról dla środowisk wielopoziomowych — projektowanie modelu ról, zestawy ról z uwzględnieniem poświadczeń, hybryda ABAC/RBAC dla przedziałów

Inżynieria ról — proces definiowania i utrzymywania modelu ról egzekwowanego przez platformę IGA — jest najbardziej czasochłonną częścią wdrożenia IGA w sektorze obronnym i tą, która przy niedbałym wykonaniu najczęściej generuje trwały dług techniczny. Fundamentalne ograniczenie polega na tym, że role muszą być stabilne w obliczu zmian organizacyjnych, ponieważ każda zmiana roli w platformie IGA to zdarzenie administracyjne wymagające kontroli zmian, ponownych testów i potencjalnie kampanii recertyfikacji.

Pierwszą decyzją projektową jest separacja domen. Organizacje obronne działają w wielu domenach klasyfikacji — co najmniej UNCLASSIFIED i SECRET, często również TOP SECRET oraz jedna lub więcej enklaw SCI. Role muszą być zdefiniowane w każdej domenie oddzielnie i przechowywane w osobnych instancjach katalogów. Rola o nazwie „analityk" w domenie UNCLASSIFIED i rola o nazwie „analityk" w domenie SECRET to nie ta sama rola — mają inne uprawnienia, inne warunki wstępne dotyczące poświadczeń i są zarządzane przez różnych oficerów bezpieczeństwa. Scalenie ich w jedną rolę obejmującą wiele domen to błąd architektoniczny, który akredytatorzy natychmiast wykryją i który stwarza realne ryzyko wycieku uprawnień między domenami.

W każdej domenie role powinny być funkcjonalne, a nie organizacyjne. Rola organizacyjna — „członek Komórki Wywiadowczej 3. Eskadry" — jest stabilna tylko dopóty, dopóki stabilna jest organizacja. Rola funkcjonalna — „analityk wywiadowski, systemy niejawne" — podąża za funkcją danej osoby przez granice organizacyjne i przeżywa reorganizacje, które zdarzają się co osiemnaście miesięcy w większości środowisk obronnych. Role funkcjonalne składają się też czysciej: osoba z podwójną rolą (analityk i administrator sekcji) otrzymuje dwie role funkcjonalne, każdą zarządzaną i certyfikowaną niezależnie.

Zarządzanie przedziałami wymaga warstwy kontroli dostępu opartej na atrybutach (ABAC) na szczycie fundamentu RBAC. Rola określa, co dana osoba może robić; atrybuty przedziałów w jej rekordzie tożsamości określają, co może widzieć podczas wykonywania tych czynności. Ten model hybrydowy — RBAC dla uprawnień strukturalnych, ABAC dla filtrowania na poziomie danych — jest architekturą, która skaluje się do złożoności rzeczywistej organizacji obronnej bez konieczności tworzenia nowej roli za każdym razem, gdy powstaje nowy przedział.

# Schemat atrybutów tożsamości (uproszczony)
{
  "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"
}

Zarządzanie cyklem życia ról — dodawanie, modyfikowanie i wycofywanie ról — wymaga odrębnego procesu governance od zarządzania cyklem życia użytkowników. Nowe role powinny wymagać zatwierdzenia przez oficera bezpieczeństwa, analizy wpływu na uprawnienia i walidacji w środowisku testowym przed wprowadzeniem do produkcji. Wycofywane role wymagają planu migracji, który przenosi obecnych posiadaczy ról do ról zastępczych przed usunięciem starej roli, zapobiegając powstawaniu osieroconych uprawnień w podłączonych systemach.

Separacja obowiązków w programach obronnych — projektowanie reguł SoD dla pozyskiwania i podtrzymywania zdolności, kompensujące kontrole dla wyjątków w małych zespołach

Separacja obowiązków (SoD) to zasada kontrolna, zgodnie z którą żadna pojedyncza osoba nie powinna posiadać obu stron transakcji wysokiego ryzyka — zdolności zarówno do inicjowania, jak i zatwierdzania zobowiązania finansowego, ani do wnioskowania i udzielania własnego dostępu, ani do pisania i certyfikowania wydania oprogramowania. W środowiskach pozyskiwania i podtrzymywania zdolności obronnych naruszenia SoD doprowadziły do niektórych z najbardziej kosztownych udokumentowanych przypadków nadużyć i niegospodarności: oficer kontraktowy, który mógł jednocześnie certyfikować płatności za faktury; administrator systemu, który mógł modyfikować zarówno kod aplikacji, jak i jej kontrole dostępu; kierownik logistyki, który mógł jednocześnie zamawiać i certyfikować odbiór materiału.

IGA egzekwuje SoD poprzez zestaw reguł identyfikujących konfliktujące pary uprawnień i uniemożliwiających posiadanie obu przez jedną tożsamość. Zestaw reguł musi być zaprojektowany z myślą o konkretnych przepływach pracy wysokiego ryzyka w obronnym pozyskiwaniu, a nie zapożyczony z szablonu dla komercyjnych usług finansowych. Kluczowe pary konfliktów w kontekstach obronnych obejmują:

• Inicjowanie kontraktu i zatwierdzanie kontraktu (SoD w zamówieniach)
• Składanie wniosku o dostęp i zatwierdzanie dostępu (SoD w IAM)
• Zatwierdzanie kodu i autoryzacja wdrożenia kodu (SoD w DevSecOps)
• Generowanie kluczy kryptograficznych i certyfikacja przez powiernika klucza
• Autoryzacja likwidacji aktywów i certyfikacja odbioru aktywów
• Wprowadzanie zobowiązania finansowego i certyfikacja zobowiązania

Wyzwaniem inżynieryjnym w sektorze obronnym jest to, że wiele programów działa z bardzo małymi zespołami — niekiedy poniżej dziesięciu poświadczonych pracowników obejmujących wszystkie role. Reguła SoD wymagająca, aby dwie różne osoby posiadały konfliktujące uprawnienia, może być nieegzekwowalna w trzyosobowym oddziale wysuniętym. Właściwą odpowiedzią IGA nie jest wyłączanie reguł SoD dla małych zespołów, lecz wdrożenie ustrukturyzowanego przepływu wyjątków z kontrolami kompensującymi.

Kontrola kompensująca dla wyjątku SoD powinna obejmować: udokumentowane zaakceptowanie ryzyka podpisane przez upoważnionego urzędnika; wzmoczoną flagę audytu dla wszystkich transakcji wykonywanych przez posiadacza wyjątku, tak aby każda taka transakcja była widoczna podczas kolejnego przeglądu zgodności; obowiązkowy wymóg weryfikacji przez drugą osobę (transakcja jest kompletna, ale drugi poświadczony pracownik musi przejrzeć i kontrasygnować w określonym oknie czasowym); datę wygaśnięcia wyjątku wyzwalającą ponowną ocenę, a nie ciche przedłużanie.

Reguły SoD ujawniają się również podczas kampanii certyfikacji dostępu. Gdy recenzent recertyfikacji zatwierdza dostęp dla osoby posiadającej konfliktującą parę uprawnień, platforma IGA powinna wyraźnie przedstawić konflikt i wymagać jawnej decyzji o nadpisaniu, zamiast cicho zezwalać na zatwierdzenie. Każde nadpisanie jest rejestrowane jako wyjątek certyfikacyjny w ścieżce audytu, zapewniając, że akredytator może zobaczyć nie tylko to, jaki dostęp istnieje, ale jakie konflikty SoD zostały świadomie zaakceptowane i przez kogo.

Kampanie certyfikacji dostępu — częstotliwość kampanii dla dostępu do systemów niejawnych, automatyczne przypisywanie recenzentów według łańcucha nadzoru, certyfikacja wsadowa a oparta na ryzyku

Certyfikacja dostępu to okresowy proces prezentowania każdemu odpowiedzialnemu recenzentowi aktualnych uprawnień użytkownika w celu poświadczenia, że dostęp pozostaje właściwy. W sektorze obronnym jest to również główny mechanizm, za pomocą którego organizacja demonstruje ciągłą zgodność z AC-2 i powiązanymi kontrolami — odpowiedź na pytanie akredytatora „czy możesz wykazać, że cały dostęp w tym systemie jest aktualnie autoryzowany?" udziela zapis kampanii certyfikacyjnej.

Minimalny poziom wymagany przez NIST 800-53 AC-2(j) to coroczny przegląd wszystkich kont, jednak praktyka obronna i większość wskazówek akredytacyjnych oczekuje więcej. Praktyczny harmonogram kampanii dla systemów niejawnych:

• Kwartalnie: konta uprzywilejowane (administratorzy systemu, oficerowie bezpieczeństwa, konta usługowe z podwyższonymi prawami), konta w rozwiązaniach cross-domain, systemach zarządzania kluczami kryptograficznymi i repozytoriach wywiadowczych
• Półrocznie: wszystkie konta użytkowników w systemach SECRET i wyższych; konta z dostępem do funkcji zobowiązań finansowych i kontraktowania
• Rocznie: konta w systemach UNCLASSIFIED; konta z dostępem tylko do odczytu bez możliwości zapisu ani uprawnień
• Zdarzeniowo: każde konto należące do osoby zmieniającej rolę, program lub jednostkę; każde konto w systemie po zakończeniu istotnej zmiany; każde konto, dla którego nastąpiło odnowienie, podwyższenie lub obniżenie poświadczenia

Automatyczne przypisywanie recenzentów jest krytyczne w środowiskach obronnych, gdzie struktury organizacyjne często się zmieniają i platforma IGA nie może polegać na statycznym mapowaniu recenzentów. Właściwym źródłem przypisania recenzenta jest autorytatywny łańcuch nadzoru z systemu kadrowego — gdy platforma IGA generuje kampanię certyfikacyjną, pobiera aktualny rekord przełożonego dla każdej tożsamości i przypisuje recenzję temu przełożonemu. Gdy stanowisko przełożonego jest nieobsadzone (co zdarza się często w środowiskach wysuniętych), łańcuch eskaluje automatycznie do przełożonego wyższego szczebla, z określonym limitem czasu eskalacji wyzwalającym nadpisanie przez oficera bezpieczeństwa.

Certyfikacja wsadowa — prezentowanie wszystkich uprawnień dla populacji użytkowników naraz — jest właściwa dla kampanii półrocznych i rocznych, gdzie celem jest kompleksowy przegląd. Certyfikacja oparta na ryzyku jest lepsza w przypadku częstych przeglądów: zamiast prezentować co kwartał cały zestaw uprawnień użytkownika uprzywilejowanego, platforma IGA identyfikuje, które uprawnienia uległy zmianie, które były używane (a które nie) oraz które wiążą się z konfliktami SoD, i prezentuje tylko te do ukierunkowanego przeglądu. Nieużywane uprawnienia — rola uprzywilejowana przyznana sześć miesięcy temu, z której nigdy nie skorzystano — to odkrycie o najwyższej wartości z kampanii opartej na ryzyku; reprezentują one dostęp, który istnieje na papierze, a cofnięcie go nic nie kosztuje, natomiast natychmiastowe usunięcie zmniejsza powierzchnię ataku udokumentowaną w modelu ryzyka wykrywania zagrożeń wewnętrznych w sektorze obronnym.

Wskaźniki ukończenia kampanii to opóźniony wskaźnik kondycji programu. Kampania osiągająca 95% ukończenia przy 5% wyjątków jest do obrony. Kampania osiągająca 60% ukończenia, ponieważ recenzenci ignorowali powiadomienia, to ustalenie audytowe czekające na wystąpienie. Platformy IGA powinny eskalować nieukończone przeglądy przez łańcuch nadzoru z narastającą pilnością, a oficerowie bezpieczeństwa powinni mieć wgląd w czasie rzeczywistym we wskaźniki ukończenia kampanii przez panel kontrolny — zamiast odkrywać problem z ukończeniem dopiero w terminie zamknięcia kampanii.

Integracja z systemami HR, dostawcami tożsamości i CAC/PIV — architektura integracji dla PKI DoD, provisionowanie powiązane z CAC/PIV, propagacja cofnięcia poświadczenia w czasie rzeczywistym

Architektura integracji dla platformy IGA w sektorze obronnym jest bardziej złożona niż jakiekolwiek wdrożenie komercyjne, ponieważ obejmuje wiele autorytatywnych systemów, które nie współdzielą wspólnego kontraktu API, działają na różnych poziomach klasyfikacji i są własnością różnych organizacji.

Kotwicą tożsamości w kontekście US DoD jest Common Access Card (CAC). Każdy żołnierz w czynnej służbie, rezerwista na służbie oraz większość pracowników cywilnych i wykonawców posiada tę kartę. CAC zawiera trzy certyfikaty PKI (tożsamości, poczty elektronicznej i podpisywania treści), których nazwy wyróżniające (DN) służą jako stabilny, autorytatywny identyfikator osoby we wszystkich podłączonych systemach. Model konta platformy IGA musi być zbudowany wokół DN karty CAC, a nie wokół adresu e-mail lub identyfikatora pracownika — te bowiem mogą ulec zmianie, podczas gdy DN karty CAC pozostaje stabilne przez kolejne odnowienia kart.

Dane o wydaniu i odnowieniu karty CAC przepływają z Defense Enrollment Eligibility Reporting System (DEERS) przez Real-time Automated Personnel Identification System (RAPIDS). Integracja IGA z DEERS/RAPIDS dostarcza trzy krytyczne zdarzenia: wydanie karty (wyzwala aktywację konta), odnowienie karty (wyzwala propagację aktualizacji DN do wszystkich podłączonych systemów) i cofnięcie karty (wyzwala natychmiastowe zawieszenie konta). Propagacja cofnięcia musi odbywać się w czasie zbliżonym do rzeczywistego — cofnięta karta CAC, która nadal udziela dostępu do systemu przez 24 godziny, ponieważ platforma IGA sprawdza DEERS raz na dobę, to naruszenie zgodności i incydent bezpieczeństwa czekający na zaistnienie. Celem jest propagacja zdarzeń cofnięcia w czasie poniżej jednej godziny, osiągana za pomocą webhooków zdarzeniowych lub kanału delta o wysokiej częstotliwości, a nie odpytywania wsadowego.

Propagacja cofnięcia poświadczenia ma to samo wymaganie. Przepływ jest następujący: oficer bezpieczeństwa osobowego cofa poświadczenie w JPAS/DISS → platforma IGA odbiera zdarzenie → wszystkie konta na cofniętym poziomie poświadczenia i powyżej są zawieszane → podłączone systemy propagują zawieszenie przez własne konektory IGA. Platforma IGA jest warstwą orkiestracji; każdy podłączony system jest odpowiedzialny za egzekwowanie zawieszenia za pomocą własnych kontroli dostępu, nie polegając na tym, że platforma IGA będzie indywidualnie wywoływać API każdego systemu.

W przypadku sojuszniczych organizacji obronnych działających w ramach PKI, architektura integracji przebiega według tego samego wzorca z krajowymi CA PKI zamiast DoD PKI. Platforma IGA musi ufać odpowiedniej krajowej kotwicy zaufania i parsować strukturę DN certyfikatów krajowych PKI, która różni się od formatu DoD. Scenariusze cross-domain — oficer łącznikowy USA działający w sieci kraju partnerskiego — wymagają federacji między kotwicami zaufania, typowo implementowanej przez mostek PKI lub specyficzne dla misji porozumienie federacyjne, które platforma IGA tłumaczy na tymczasowe powiązanie tożsamości.

# Topologia integracji IGA
System kadrowy (DCPDS / SAP) ──→ [platforma IGA] ←── Bezpieczeństwo osobowe (JPAS/DISS)
                                        ↑
DEERS/RAPIDS (zdarzenia CAC) ──────────┘
                                        ↓
            ┌───────────────────────────┼───────────────────────────┐
            ↓                           ↓                           ↓
   AD (UNCLASSIFIED)            AD (SECRET)                AD (TS/SCI)
            ↓                           ↓                           ↓
   Konektory aplikacji          Konektory aplikacji         Konektory aplikacji
   (systemy NIPR)               (systemy SIPR)              (systemy JWICS)

Ścieżki audytu i sprawozdawczość zgodności — kontrole AC/IA z NIST 800-53, wymagania dotyczące dziennika audytu dla dostępu do systemów niejawnych, generowanie dowodów zgodności

Ścieżka audytu generowana przez platformę IGA jest głównym artefaktem dowodowym dla rodzin kontroli dostępu i identyfikacji-uwierzytelniania w ocenie NIST 800-53. Prawidłowe jej wykonanie nie jest opcjonalne — to różnica między pakietem akredytacyjnym demonstrujący ciągłą zgodność a takim, który wywołuje Plan Działania i Kamieni Milowych (POA&M) dla każdego ustalenia dotyczącego kontroli dostępu.

Dziennik audytu IGA musi rejestrować każde zdarzenie provisionowania i deprovisionowania na poziomie transakcji. Każdy rekord powinien zawierać: tożsamość, której dotyczy, przyznane lub cofnięte uprawnienie, czas zdarzenia, podstawę, na której zdarzenie zostało wykonane (automatyczny przepływ pracy, zatwierdzenie przez kierownika, nadpisanie przez oficera bezpieczeństwa lub decyzja kampanii certyfikacyjnej) oraz stabilne odniesienie do zdarzenia źródłowego, które wyzwoliło akcję (zmiana rekordu kadrowego, zdarzenie poświadczenia, decyzja certyfikacyjna). Ten poziom szczegółowości obsługuje trzy odrębne przypadki użycia audytu: odtworzenie stanu dostępu w dowolnym historycznym momencie, badanie konkretnego zdarzenia dostępu oraz zbiorcze raportowanie zgodności dla całej populacji użytkowników.

Kontrole NIST 800-53 najdokładniej wykazywane przez dane audytu IGA to:

• AC-2 (Zarządzanie kontami): rejestry cyklu życia IGA wykazują, że konta są tworzone wyłącznie dla autoryzowanych osób, przeglądane z określoną częstotliwością i wyłączane w chwili odejścia pracownika
• AC-5 (Separacja obowiązków): dzienniki egzekwowania reguł SoD i rejestry wyjątków wykazują, że confliktujące obowiązki są identyfikowane i zarządzane
• AC-6 (Zasada minimalnych uprawnień): rejestry inżynierii ról i analiza nieużywanych uprawnień z kampanii certyfikacyjnych wykazują, że dostęp jest ograniczony do niezbędnego minimum
• IA-2 (Identyfikacja i uwierzytelnianie): rekordy powiązania z CAC/PIV wykazują, że uwierzytelnianie wieloskładnikowe jest egzekwowane dla wszystkich kont użytkowników w systemach niejawnych
• IA-4 (Zarządzanie identyfikatorami): rekordy joinera i leavera wykazują, że identyfikatory kont są przypisywane i wyłączane w ramach zdefiniowanego procesu zarządzania
• IA-5 (Zarządzanie uwierzytelniaczami): rekordy powiązania kart i propagacji cofnięcia kart wykazują, że uwierzytelniacze są zarządzane i cofane w kontrolowany, terminowy sposób

Sprawozdawczość zgodności z platformy IGA powinna być zaprojektowana tak, aby generować wstępnie sformatowane pakiety dowodowe, a nie surowe eksporty dzienników. Akredytator poproszony o ocenę AC-2 powinien móc otrzymać raport pokazujący wszystkie aktywne konta, datę ostatniego przeglądu każdego z nich, informację, czy któreś są zaległe w certyfikacji, oraz liczbę wyjątków — a nie dziennik zdarzeń zawierający 500 000 wierszy z prośbą o samodzielne parsowanie. Zaprojektowanie tych raportów przed pierwszą oceną akredytacyjną i walidacja, że raporty dokładnie odzwierciedlają implementację kontroli, to różnica między dwudniowym procesem zbierania dowodów a dwutygodniowym kryzysem.

Niezmienność dziennika audytu wymaga pamięci masowej z zapisem jednorazowym lub kryptograficznego łańcuchowania skrótów. Obronne wymagania retencji dla dzienników dostępu do systemów niejawnych wynoszą zazwyczaj 3–7 lat w zależności od misji systemu i poziomu klasyfikacji; niektóre systemy w pobliżu potencjału nuklearnego i strategiczne mają dłuższe wymagania retencji. Warstwa pamięci masowej musi być odpowiednio zwymiarowana i zarządzana cyklem życia, z procedurami pobierania działającymi w momencie, gdy oryginalny stos oprogramowania nie jest już obsługiwany. Wymaganie retencji spełnione w dniu pierwszym, ale generujące nieczytelne dzienniki w roku szóstym, to naruszenie zgodności na osi czasu, która ma znaczenie.