Les rapports AdGUARD

Il répond en une page à la seule question que pose une direction : où en sommes-nous, et est-ce que cela s'améliore ? Le score pondéré — un contrôle de niveau 1 pèse trois fois un contrôle de niveau 2 — donne un chiffre unique, comparable d'un audit à l'autre et d'une entité à l'autre ; l'écart en points depuis l'audit précédent dit si l'effort a porté. C'est le document qui déclenche un budget, pas celui qui explique comment corriger.

• Le score de conformité pondéré et son évolution en points
• La répartition conformes / non conformes / avertissements / non évalués
• Les non-conformités les plus lourdes, formulées sans jargon technique
• Le périmètre exact : baseline appliquée, date, contrôles réellement évalués

C'est le rapport qui rend l'audit vérifiable. Chaque contrôle y figure avec son verdict et surtout avec les objets constatés : pas « non conforme », mais quels comptes, quels groupes, quelles ressources. La commande de vérification est fournie, ce qui permet à l'administrateur de rejouer le contrôle chez lui et, le cas échéant, de contester le résultat. Un audit qu'on ne peut pas rejouer ne se corrige pas : il se discute.

• Tous les contrôles évalués, groupés par catégorie, avec un identifiant stable
• Le verdict et la liste nominative des objets en écart
• La commande PowerShell de vérification et le lien vers la documentation officielle
• Le rattachement aux référentiels, contrôle par contrôle

C'est le rapport qu'on emporte en réunion de suivi. Les non-conformités y sont triées par gravité réelle — les contrôles de niveau 1 d'abord, puis par nombre d'objets touchés — et non par ordre de catalogue : ce qui exposerait le plus vite arrive en haut. En CSV ou en Excel, chaque ligne devient un ticket ; le plan d'action n'est plus à écrire, il est à affecter.

• Les non-conformités triées par priorité, pas par identifiant
• L'action à mener, formulée à l'impératif
• Le nombre d'objets concernés, qui donne la charge réelle
• Une ligne par action, prête à importer dans un outil de tickets

Il traduit l'audit dans la langue de l'auditeur. La même non-conformité ne pèse pas pareil selon qu'on la lit avec le guide ANSSI, un benchmark CIS ou l'annexe A de l'ISO 27001 ; ce rapport donne, référentiel par référentiel, le nombre de contrôles couverts et le taux de conformité obtenu. C'est la pièce qu'on joint à un dossier NIS2, à un questionnaire d'assureur ou à une revue de sécurité client. Il donne aussi le palier de maturité ANSSI atteint sur 5 : un palier n'est acquis que si aucun contrôle des paliers inférieurs n'est en écart — c'est volontairement sévère, mais c'est ce qui rend le chiffre crédible.

• La couverture et le taux de conformité pour chaque référentiel : ANSSI, MCSB, MITRE ATT&CK, CIS Windows Server, ISO 27001, NIST, NIS2, DORA
• Le détail des contrôles derrière chaque taux, pour justifier le chiffre
• Les contrôles non évalués, comptés à part — un référentiel partiellement couvert le dit
• Le palier de maturité ANSSI atteint, et ce qui bloque le palier suivant

C'est le rapport récurrent, celui qui se relit d'un trimestre à l'autre. Il ne redécrit pas l'audit : il dit ce qui a bougé depuis le précédent, à périmètre comparable — et il le signale explicitement quand le périmètre a changé, sinon la courbe ment. Les régressions sont listées avant les corrections : un contrôle qui redevient non conforme est un signal de dérive, pas un détail.

• Le score, l'écart en points et la courbe de tendance sur la période
• La posture par catégorie, de la plus faible à la plus forte
• Ce qui a régressé et ce qui a été corrigé depuis l'audit précédent
• Les cinq priorités du trimestre, extraites des non-conformités de niveau 1
• Les notes de périmètre : baseline, contrôles non évalués, point de comparaison

C'est le rapport qui fait accepter la remédiation. Il ne dit pas qu'un droit est mal placé : il montre la chaîne complète — quel principal détient quel droit sur quel objet, et en combien de sauts un utilisateur ordinaire devient administrateur du domaine. Chaque chemin est noté gravité × largeur : un droit détenu par « Utilisateurs du domaine » ne pèse pas comme le même droit détenu par un compte nominatif. Le plan de correction dsacls est fourni avec toutes les commandes modifiantes commentées — l'outil est en lecture seule, rien ne s'exécute par inadvertance.

• Les chemins triés par score, les prises de contrôle du domaine signalées à part
• Le regroupement par objet cible et par principal détenteur
• Le dépliage des groupes : qui détient réellement le droit, une fois les appartenances résolues
• Le glossaire des droits en clair (GenericAll, WriteDACL, DCSync, ForceChangePassword…)
• La carte des approbations, leur sens, leur filtrage et l'âge de leur secret
• Le plan dsacls commenté, plus des exports Graphviz et GraphML pour yEd ou Gephi