Gouvernance et administration des identités pour les organisations de défense

La gouvernance et l'administration des identités (IGA) est la discipline qui consiste à contrôler systématiquement qui a accès à quoi, pendant combien de temps et sur quelle autorité — et à produire des preuves auditables que les accès sont appropriés à tout moment. Dans une organisation commerciale, l'IGA gère les rôles, les droits et les révisions périodiques dans le cadre d'un cycle de vie des employés piloté par les RH. Dans une organisation de défense, l'IGA doit faire tout cela tout en appliquant simultanément un second réseau de contrôle d'accès fondé sur les niveaux d'habilitation de sécurité, les appartenances aux compartiments, les déterminations du besoin d'en connaître et les autorisations de programme. L'écart entre ces deux énoncés de problème est là où la plupart des déploiements IGA commerciaux échouent lorsqu'ils sont transplantés dans la défense. Cet article traite des décisions d'ingénierie qui comblent cet écart — en couvrant le provisionnement tenant compte des habilitations, l'ingénierie des rôles pour les domaines multi-classification, la séparation des tâches sous contraintes d'équipes réduites, la conception de la certification des accès, l'intégration CAC/PIV et l'architecture des pistes d'audit requise pour survivre à une accréditation RMF. Pour la couche de courtage des identifiants dont l'IGA dépend lors de l'accès privilégié, voir notre analyse de la gestion des accès privilégiés pour la défense.

Pourquoi l'IGA dans la défense diffère de l'entreprise — les niveaux d'habilitation comme dimension d'accès supplémentaire, gestion des compartiments, application du besoin d'en connaître

Dans une entreprise commerciale, le contrôle d'accès a deux dimensions significatives : qui est l'utilisateur (identité) et à quel rôle ou groupe il appartient (droit). Une organisation de défense ajoute une troisième dimension qui est orthogonale aux deux : ce à quoi l'utilisateur est habilité et autorisé à accéder. Un ingénieur réseau senior peut détenir une habilitation SECRET valide mais n'avoir aucune autorisation d'accéder au compartiment de renseignement fonctionnant sur le même réseau de niveau SECRET. Un analyste junior peut être habilité au TOP SECRET et spécifiquement introduit dans un compartiment auquel l'ingénieur senior n'a pas accès. Ni l'ancienneté ni la hiérarchie organisationnelle ne résolvent ces décisions — seul le dossier d'autorisation formel le fait.

Les plateformes IGA commerciales — SailPoint IdentityNow, Saviynt, Omada, One Identity — sont conçues pour le problème bidimensionnel. Elles peuvent stocker des attributs personnalisés et, avec suffisamment de personnalisation, appliquer des contraintes de niveau d'habilitation, mais elles ne modélisent pas nativement les compartiments, les mentions de traitement ou les autorisations d'accès aux programmes en tant qu'objets de première classe. La plateforme vous permettra d'ajouter un attribut personnalisé appelé « clearance_level » et d'écrire une règle de provisionnement qui le vérifie. La plateforme ne maintiendra pas, sans développement personnalisé, un flux en direct depuis un système de sécurité du personnel, ne résoudra pas la différence entre un enregistrement formel d'habilitation SCI et une déclaration d'habilitation auto-rapportée, et ne modélisera pas le réseau de compartiments avec leurs propres flux de travail d'introduction et de retrait.

L'application du besoin d'en connaître est la différence la plus marquée. Dans l'IGA d'entreprise, l'accès est généralement accordé à une classe de ressources — « cet utilisateur peut accéder au lac de données Finance ». Dans la défense, l'accès à la même ressource peut être accordé à l'Utilisateur A mais pas à l'Utilisateur B, même si tous deux détiennent l'habilitation correcte, parce que l'Utilisateur B n'a pas été formellement introduit dans le programme qui produit les données. L'IGA doit appliquer cela au moment du provisionnement et de la recertification, en interrogeant les enregistrements d'accès aux programmes faisant autorité plutôt qu'en s'appuyant sur l'attestation d'un responsable. L'écart entre « mon responsable a approuvé mon accès » et « l'enregistrement faisant autorité confirme que je suis introduit dans ce programme » est exactement l'écart qui produit des constats d'audit et, dans les pires cas, des divulgations non autorisées.

L'implication pratique est qu'un déploiement IGA de défense nécessite un développement de connecteurs et une personnalisation des flux de travail au-delà de ce que tout produit IGA prêt à l'emploi fournit. Prévoyez ce budget dès le départ, traitez les flux de données d'habilitation et de compartiment comme le travail d'intégration le plus critique du projet, et déterminez si le produit commercial existant peut être étendu pour répondre à l'exigence ou si une solution IGA spécifique à la défense est le bon point de départ. Le modèle de confiance zéro pour les logiciels de défense dépend de l'IGA pour fournir des données de droits précises et continuellement validées — sans cela, les moteurs de politiques prennent des décisions d'autorisation sur des attributs d'identité obsolètes ou invérifiables.

Le cycle de vie arrivée-mutation-départ en environnement classifié — déclencheurs de provisionnement automatisé, intégration de la vérification des habilitations, transitions de rôles lors des réaffectations

Le cycle de vie arrivée-mutation-départ (JML) est la boucle opérationnelle fondamentale de tout déploiement IGA. Dans la défense, chaque phase de la boucle comporte des contraintes supplémentaires qui la ralentissent mais rendent aussi les erreurs plus lourdes de conséquences.

Flux de travail d'arrivée. Un événement d'arrivée se déclenche lorsqu'un système RH ou de personnel faisant autorité crée un nouvel enregistrement — nouvelle embauche, nouveau prestataire, nouvelle affectation temporaire. Dans la défense, le provisionnement ne doit pas commencer avant que la plateforme IGA ait confirmé de manière indépendante le niveau d'habilitation adjugé de l'individu depuis le système de sécurité du personnel (JPAS ou DISS dans le contexte du DoD américain ; équivalents nationaux dans les organisations de défense alliées), et confirmé un DN de carte CAC ou PIV valide depuis le système d'enregistrement. La séquence importe : la vérification de l'habilitation conditionne le provisionnement, et non l'inverse. Une plateforme IGA qui provisionne un compte d'abord et vérifie l'habilitation dans une tâche de fond a déjà créé une fenêtre exploitable.

Le flux de travail d'arrivée devrait également déclencher une vérification d'accès aux compartiments pour tout droit nécessitant une introduction formelle dans un programme. Si l'enregistrement d'introduction existe dans le système d'accès aux programmes faisant autorité, le provisionnement se poursuit. S'il n'existe pas, le droit est supprimé et un élément de flux de travail est créé pour que l'officier de sécurité initie le processus formel d'habilitation. Le compte existe ; le droit sensible n'existe pas, jusqu'à ce que le dossier papier existe pour le justifier.

Flux de travail de mutation. La réaffectation dans les organisations de défense est fréquente et lourde de conséquences. Une personne passant d'un programme à un autre perd généralement l'accès aux systèmes du premier programme et gagne l'accès à ceux du second. Le flux de travail de mutation IGA doit résoudre cette transition de manière déterministe : calculer le delta de droits entre l'ancien ensemble de rôles et le nouveau, révoquer ce qui n'est plus approprié et provisionner ce qui est nouvellement justifié — le tout conditionné par les mêmes vérifications d'habilitation et de compartiment. Lorsque le nouveau rôle nécessite une habilitation supérieure à celle que l'individu détient actuellement, le compte pour ce domaine de classification est supprimé en attente d'une décision de montée en habilitation.

Le cas de mutation le plus complexe est la mission temporaire (TDY) ou le détachement. L'individu conserve son ensemble de rôles d'unité d'origine et acquiert un ensemble de rôles supplémentaires limités dans le temps pour la durée de l'affectation. L'IGA doit modéliser cela sans accorder à la personne un accès élevé de manière permanente qui subsisterait au-delà de la fin de l'affectation. Les attributions de rôles limitées dans le temps avec expiration automatique, examinées par les officiers de sécurité de l'unité d'origine et de l'unité d'accueil, constituent le schéma correct.

Flux de travail de départ. Le flux de travail de départ — déclenché par une résiliation, une fin de contrat, un départ à la retraite ou une révocation d'habilitation — est la phase à plus hauts enjeux et celle où les déploiements IGA commerciaux tombent le plus souvent en défaut dans la défense. L'attente est un déprovisionnement le jour même pour tous les comptes sur tous les systèmes connectés, indépendamment du fait que l'individu ait physiquement rendu sa carte CAC, s'est déconnecté de son poste de travail ou a complété une procédure de départ RH. La plateforme IGA ne doit pas attendre qu'un enregistrement RH atteigne le statut « résilié » avant de révoquer l'accès — l'événement de révocation d'habilitation du système de sécurité du personnel est le déclencheur, et il doit se propager en quasi-temps réel.

# Objectifs SLA du flux de travail de départ (contexte défense)
clearance_revocation_to_AD_disable:   < 1 heure
AD_disable_to_all_app_deprovisioning: < 4 heures
CAC_invalidation_propagation:         < 1 heure (DEERS → systèmes connectés)
audit_closure_record_generated:       même jour ouvré
physical_access_revocation:           même jour (intégration du système de sécurité physique)

Ingénierie des rôles pour les environnements multi-classification — conception du modèle de rôles, ensembles de rôles délimités par habilitation, hybride attributs vs rôles pour les compartiments

L'ingénierie des rôles — le processus de définition et de maintien du modèle de rôles que la plateforme IGA applique — est la partie la plus chronophage d'un déploiement IGA de défense et celle qui est la plus susceptible de produire une dette technique persistante si elle est mal réalisée. La contrainte fondamentale est que les rôles doivent être stables à travers les changements organisationnels, car chaque changement de rôle dans la plateforme IGA est un événement administratif qui nécessite un contrôle des changements, des tests à nouveau et potentiellement une campagne de recertification.

La première décision de conception est la séparation des domaines. Les organisations de défense opèrent sur plusieurs domaines de classification — au minimum NON CLASSIFIÉ et SECRET, souvent aussi TOP SECRET et une ou plusieurs enclaves SCI. Les rôles doivent être définis dans chaque domaine séparément et stockés dans des instances d'annuaire distinctes. Un rôle nommé « analyste » dans le domaine NON CLASSIFIÉ et un rôle nommé « analyste » dans le domaine SECRET ne sont pas le même rôle — ils portent des droits différents, des prérequis d'habilitation différents et sont gérés par des officiers de sécurité différents. Les confondre dans un seul rôle inter-domaines est une erreur architecturale que les accrédateurs détecteront immédiatement et qui crée un risque réel de fuite de droits inter-domaines.

Au sein de chaque domaine, les rôles devraient être fonctionnels plutôt qu'organisationnels. Un rôle organisationnel — « membre de la cellule de renseignement du 3e Escadron » — n'est stable que tant que l'organisation l'est. Un rôle fonctionnel — « analyste du renseignement, systèmes classifiés » — voyage avec la fonction de la personne à travers les frontières organisationnelles et survit aux réorganisations qui surviennent tous les dix-huit mois dans la plupart des environnements de défense. Les rôles fonctionnels se composent aussi plus proprement : une personne avec un double rôle (analyste et administrateur de section) reçoit deux rôles fonctionnels, chacun géré et certifié indépendamment.

La gestion des compartiments nécessite une couche de contrôle d'accès basé sur les attributs (ABAC) au-dessus de la base RBAC. Le rôle établit ce que la personne peut faire ; les attributs de compartiment sur son enregistrement d'identité établissent ce qu'elle peut voir en le faisant. Ce modèle hybride — RBAC pour les droits structurels, ABAC pour le filtrage au niveau des données — est l'architecture qui passe à l'échelle de la complexité d'une véritable organisation de défense sans nécessiter un nouveau rôle chaque fois qu'un nouveau compartiment est créé.

# Schéma d'attributs d'identité (simplifié)
{
  "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"
}

La gestion du cycle de vie des rôles — ajout, modification et retrait de rôles — nécessite un processus de gouvernance distinct de la gestion du cycle de vie des utilisateurs. Les nouveaux rôles devraient requérir l'approbation de l'officier de sécurité, une analyse d'impact sur les droits et une validation en environnement de test avant la promotion en production. Les rôles retirés nécessitent un plan de migration qui déplace les titulaires actuels vers des rôles de remplacement avant que l'ancien rôle ne soit supprimé, évitant les droits orphelins dans les systèmes connectés.

Séparation des tâches dans les programmes de défense — conception des règles SoD pour l'acquisition et le soutien, contrôles compensatoires pour les exceptions en petites équipes

La séparation des tâches (SoD) est le principe de contrôle selon lequel aucun individu ne devrait détenir les deux côtés d'une transaction à haut risque — la capacité d'initier et d'approuver une obligation financière, ou de demander et d'accorder son propre accès, ou d'écrire et de certifier une mise en production logicielle. Dans les environnements d'acquisition et de soutien de la défense, les défaillances SoD ont produit certains des cas de fraude et de mauvaise gestion les plus coûteux enregistrés : un officier contractant qui pouvait également certifier les paiements de factures ; un administrateur système qui pouvait modifier à la fois le code applicatif et ses contrôles d'accès ; un gestionnaire logistique qui pouvait à la fois commander et certifier la réception de matériel.

L'IGA applique la SoD via un ensemble de règles qui identifie les paires de droits conflictuels et empêche toute identité unique de détenir les deux. L'ensemble de règles doit être conçu en tenant compte des flux de travail à haut risque spécifiques à l'acquisition de la défense, et non emprunté à un modèle de services financiers commerciaux. Les paires de conflits clés dans les contextes de défense comprennent :

• Initiation de contrat et approbation de contrat (SoD approvisionnement)
• Soumission de demande d'accès et approbation des accès (SoD IAM)
• Validation de code et autorisation de déploiement de code (SoD DevSecOps)
• Génération de clé cryptographique et certification du dépositaire de clé
• Autorisation de cession d'actifs et certification de réception d'actifs
• Saisie d'obligation financière et certification d'obligation

Le défi d'ingénierie dans la défense est que de nombreux programmes fonctionnent avec de très petites équipes — parfois moins de dix personnels habilités couvrant tous les rôles. Une règle SoD qui exige que deux personnes différentes détiennent les droits conflictuels peut être inapplicable dans un détachement avancé de trois personnes. La bonne réponse IGA n'est pas de désactiver les règles SoD pour les petites équipes ; c'est de mettre en œuvre un flux de travail d'exception structuré avec des contrôles compensatoires.

Un contrôle compensatoire pour une exception SoD devrait inclure : une acceptation de risque documentée signée par l'officier autorisant ; un indicateur d'audit renforcé sur toutes les transactions exécutées par le titulaire de l'exception, de sorte que chaque transaction soit signalée lors de la prochaine révision de conformité ; une exigence de révision secondaire obligatoire (la transaction est complète mais un second individu habilité doit examiner et contresigner dans un délai défini) ; et une date d'expiration sur l'exception qui déclenche une réévaluation plutôt qu'une perpétuation silencieuse.

Les règles SoD se manifestent également lors des campagnes de certification des accès. Lorsqu'un examinateur de recertification approuve l'accès pour quelqu'un qui détient une paire de droits conflictuels, la plateforme IGA devrait présenter le conflit de manière visible et exiger une décision de dérogation explicite plutôt que de permettre silencieusement l'approbation. Chaque dérogation est enregistrée comme une exception de certification dans la piste d'audit, garantissant que l'accrédateur peut voir non seulement quels accès existent mais quels conflits SoD ont été sciemment acceptés et par qui.

Campagnes de certification des accès — fréquence des campagnes pour les accès aux systèmes classifiés, attribution automatique des examinateurs par chaîne hiérarchique, recertification par lots vs basée sur les risques

La certification des accès est le processus périodique de présentation de tous les droits actuels d'un utilisateur à un examinateur responsable pour attestation que l'accès reste approprié. Dans la défense, c'est aussi le mécanisme principal par lequel une organisation démontre la conformité continue avec AC-2 et les contrôles associés — la question de l'accrédateur « pouvez-vous me montrer que tous les accès sur ce système sont actuellement autorisés ? » trouve sa réponse dans le dossier de la campagne de certification.

Le seuil minimal NIST 800-53 AC-2(j) exige une révision annuelle de tous les comptes, mais la pratique de la défense et la plupart des guides d'accréditation en attendent davantage. Un calendrier pratique de campagnes pour les systèmes classifiés :

• Trimestriel : comptes privilégiés (administrateurs système, officiers de sécurité, comptes de service avec droits élevés), comptes sur les solutions inter-domaines, systèmes de gestion des clés cryptographiques et dépôts de renseignement
• Semestriel : tous les comptes utilisateurs sur les systèmes SECRET et au-dessus ; comptes ayant accès aux fonctions d'obligation financière et de passation de marchés
• Annuel : comptes sur les systèmes NON CLASSIFIÉS ; comptes en lecture seule sans capacité d'écriture ni de privilège
• Événementiel : tout compte appartenant à un individu qui change de rôle, de programme ou d'unité ; tout compte sur un système qui achève une modification majeure ; tout compte où un renouvellement, une montée ou une descente d'habilitation a eu lieu

L'attribution automatique des examinateurs est critique dans les environnements de défense où les structures organisationnelles changent fréquemment et où la plateforme IGA ne peut pas dépendre d'un mappage statique d'examinateurs. La bonne source d'attribution des examinateurs est la chaîne hiérarchique faisant autorité du système RH — lorsque la plateforme IGA génère une campagne de certification, elle interroge l'enregistrement de superviseur actuel pour chaque identité et attribue la révision à ce superviseur. Lorsque le poste de superviseur est vacant (une occurrence fréquente dans les environnements déployés), la chaîne escalade automatiquement vers le superviseur de niveau supérieur, avec un délai d'escalade défini qui déclenche une dérogation de l'officier de sécurité.

La certification par lots — présentation de tous les droits d'une population d'utilisateurs en une seule fois — est appropriée pour les campagnes semestrielles et annuelles où l'objectif est une révision complète. La certification basée sur les risques est préférable pour les révisions à haute fréquence : plutôt que de présenter l'ensemble complet des droits d'un utilisateur privilégié chaque trimestre, la plateforme IGA identifie les droits qui ont changé, ceux qui ont été utilisés (et ceux qui ne l'ont pas été) et ceux qui comportent des conflits SoD, et ne présente que ceux-là pour une révision ciblée. Les droits inutilisés — un rôle privilégié accordé il y a six mois qui n'a jamais été exercé — sont les constats à plus haute valeur d'une campagne basée sur les risques ; ils représentent un accès qui existe sur le papier mais dont la révocation ne coûte rien à l'organisation, et leur suppression immédiate réduit la surface d'attaque documentée dans le modèle de risque de détection des menaces internes en défense.

Les taux d'achèvement des campagnes sont un indicateur retardé de la santé du programme. Une campagne atteignant 95 % d'achèvement avec 5 % d'exceptions est défendable. Une campagne atteignant 60 % d'achèvement parce que les examinateurs ont ignoré la notification est un constat d'audit en attente. Les plateformes IGA devraient escalader les révisions non complétées dans la chaîne hiérarchique avec une urgence croissante, et les officiers de sécurité devraient avoir une visibilité en tableau de bord sur les taux d'achèvement des campagnes en temps réel plutôt que de découvrir un problème d'achèvement à l'échéance de la campagne.

Intégration avec les RH, les fournisseurs d'identité et CAC/PIV — architecture d'intégration pour l'ICP DoD/OTAN, provisionnement lié au CAC/PIV, propagation de la révocation d'habilitation en temps réel

L'architecture d'intégration d'une plateforme IGA de défense est plus complexe que tout déploiement commercial parce qu'elle couvre plusieurs systèmes faisant autorité qui ne partagent pas de contrat API commun, fonctionnent à différents niveaux de classification et appartiennent à différentes organisations.

L'ancre d'identité dans le contexte DoD américain est la Common Access Card (CAC). Chaque militaire d'active, réserviste en service et la plupart des employés civils et prestataires en détiennent une. La CAC contient trois certificats ICP (identité, messagerie et signature de contenu) dont les noms distinctifs servent d'identifiant stable et faisant autorité pour la personne sur tous les systèmes connectés. Le modèle de compte de la plateforme IGA doit être construit autour du DN de la CAC, et non d'une adresse e-mail ou d'un identifiant employé, car ceux-ci peuvent changer tandis que le DN de la CAC reste stable à travers les renouvellements de carte.

Les données d'émission et de renouvellement de CAC transitent du Defense Enrollment Eligibility Reporting System (DEERS) par le Real-time Automated Personnel Identification System (RAPIDS). L'intégration IGA avec DEERS/RAPIDS fournit trois événements critiques : émission de carte (déclenche l'activation du compte), renouvellement de carte (déclenche la propagation de mise à jour du DN vers tous les systèmes connectés) et révocation de carte (déclenche la suspension immédiate du compte). La propagation de la révocation doit être quasi-temps réel — une CAC révoquée qui donne encore accès aux systèmes pendant 24 heures parce que la plateforme IGA interroge DEERS une fois par jour est un échec de conformité et un incident de sécurité en attente. L'objectif est une propagation en moins d'une heure pour les événements de révocation, réalisée par des webhooks événementiels ou un flux de synchronisation différentielle à haute fréquence plutôt qu'une interrogation par lots.

La propagation de la révocation d'habilitation a la même exigence. Le flux est : l'officier de sécurité du personnel révoque l'habilitation dans JPAS/DISS → la plateforme IGA reçoit l'événement → tous les comptes au niveau d'habilitation révoqué et au-dessus sont suspendus → les systèmes connectés propagent la suspension via leurs propres connecteurs IGA. La plateforme IGA est la couche d'orchestration ; chaque système connecté est responsable d'appliquer la suspension via ses propres contrôles d'accès, sans s'appuyer sur la plateforme IGA pour appeler individuellement l'API de chaque système.

Pour les organisations de défense alliées opérant sous l'ICP de l'OTAN, l'architecture d'intégration suit le même schéma avec les AC ICP nationaux plutôt que l'ICP DoD. La plateforme IGA doit faire confiance à l'ancre de confiance nationale appropriée et analyser la structure DN des certificats ICP nationaux, qui diffère du format DoD. Les scénarios inter-domaines — un officier de liaison américain opérant sur le réseau d'une nation partenaire — nécessitent une fédération entre les ancres de confiance, généralement mise en œuvre via un pont ICP ou un accord de fédération spécifique à la mission que la plateforme IGA traduit en une liaison d'identité temporaire.

# Topologie d'intégration IGA
Système RH (DCPDS / SAP) ──→ [Plateforme IGA] ←── Sécurité personnel (JPAS/DISS)
                                   ↑
DEERS/RAPIDS (événements CAC) ─────┘
                                   ↓
           ┌───────────────────────┼───────────────────────┐
           ↓                       ↓                       ↓
   AD (NON CLASSIFIÉ)        AD (SECRET)           AD (TS/SCI)
           ↓                       ↓                       ↓
   Connecteurs apps          Connecteurs apps        Connecteurs apps
   (systèmes NIPR)           (systèmes SIPR)        (systèmes JWICS)

Pistes d'audit et rapports de conformité — contrôles NIST 800-53 AC/IA, exigences de journalisation pour les accès aux systèmes classifiés, génération de preuves de conformité

La piste d'audit produite par une plateforme IGA est l'artefact de preuve principal pour les familles de contrôles de contrôle d'accès et d'identification et d'authentification dans une évaluation NIST 800-53. Bien faire cela n'est pas facultatif — c'est la différence entre un dossier d'accréditation qui démontre une conformité continue et un qui déclenche un Plan d'action et jalons (POA&M) pour chaque constat de contrôle d'accès.

Le journal d'audit IGA doit capturer chaque événement de provisionnement et de déprovisionnement au niveau de la transaction. Chaque enregistrement devrait contenir : l'identité affectée, le droit accordé ou révoqué, l'heure de l'événement, l'autorité sous laquelle l'événement a été exécuté (flux de travail automatisé, approbation du responsable, dérogation de l'officier de sécurité ou décision de campagne de certification) et une référence stable à l'événement source qui a déclenché l'action (le changement d'enregistrement RH, l'événement d'habilitation, la décision de certification). Ce niveau de détail prend en charge trois cas d'utilisation d'audit distincts : la reconstruction de l'état d'accès à tout moment historique, l'investigation d'un événement d'accès spécifique et les rapports de conformité agrégés sur la population d'utilisateurs.

Les contrôles NIST 800-53 les plus directement attestés par les données d'audit IGA sont :

• AC-2 (Gestion des comptes) : les enregistrements de cycle de vie IGA démontrent que les comptes sont créés uniquement pour des individus autorisés, révisés à des fréquences définies et désactivés lors du départ des individus
• AC-5 (Séparation des tâches) : les journaux d'application des règles SoD et les enregistrements d'exceptions démontrent que les tâches conflictuelles sont identifiées et gérées
• AC-6 (Moindre privilège) : les enregistrements d'ingénierie des rôles et l'analyse des droits inutilisés issus des campagnes de certification démontrent que l'accès est limité au minimum nécessaire
• IA-2 (Identification et authentification) : les enregistrements de liaison CAC/PIV démontrent que l'authentification multifacteur est appliquée pour tous les comptes utilisateurs sur les systèmes classifiés
• IA-4 (Gestion des identifiants) : les enregistrements d'arrivée et de départ démontrent que les identifiants de compte sont attribués et désactivés selon un processus de gestion défini
• IA-5 (Gestion des authentifiants) : les enregistrements de liaison et de révocation de carte démontrent que les authentifiants sont gérés et révoqués de manière contrôlée et rapide

Les rapports de conformité de la plateforme IGA devraient être conçus pour produire des packages de preuves préformatés, et non des exports de journaux bruts. Un accrédateur invité à évaluer AC-2 devrait pouvoir recevoir un rapport montrant tous les comptes actifs, la date de la dernière révision de chacun, si des comptes sont en retard de certification et un décompte des exceptions — et non un journal d'événements de 500 000 lignes avec une demande de « l'analyser vous-même ». Concevoir ces rapports avant la première révision d'accréditation et valider que les rapports reflètent fidèlement la mise en œuvre des contrôles est la différence entre un processus de collecte de preuves de deux jours et une crise de deux semaines.

L'immuabilité du journal d'audit exige un stockage en écriture unique ou un chaînage de hachages cryptographiques. Les exigences de conservation de la défense pour les journaux d'accès aux systèmes classifiés s'étendent généralement sur 3 à 7 ans selon la mission et le niveau de classification du système ; certains systèmes nucléaires adjacents et stratégiques portent des exigences de conservation plus longues. Le niveau de stockage doit être dimensionné et géré en cycle de vie en conséquence, avec des procédures de récupération qui fonctionnent lorsque la pile logicielle d'origine n'est plus prise en charge. Une exigence de conservation satisfaite le premier jour mais produisant des journaux illisibles en sixième année est un échec de conformité sur le calendrier qui compte.