Tests de sécurité Entra ID Maester ScubaGear : guide

Que sont les tests de sécurité Entra ID Maester ScubaGear ?

Les tests de sécurité Entra ID Maester ScubaGear transforment la revue de configuration de sécurité en une évaluation reproductible : choisir des assertions documentées, collecter les paramètres du tenant, les évaluer et conserver les résultats. Maester propose une automatisation des tests en PowerShell ; ScubaGear évalue la configuration de Microsoft 365 par rapport aux référentiels CISA SCuBA. Leur intérêt est de permettre une revue répétable après une modification, en conservant le périmètre et les preuves.

Un résultat de référence répond à une question délimitée. Il peut établir qu’une assertion correspond à la configuration accessible à l’évaluation. Il n’établit pas que tous les chemins d’authentification sont protégés ni qu’aucune attaque visant les identités n’a eu lieu. Le processus ci-dessous sépare la mesure de configuration, l’investigation des résultats, la remédiation contrôlée et la vérification ultérieure. Il inclut des commandes documentées et de véritables identifiants de tests, sans présenter un exemple comme une évaluation de tenant que nous aurions réalisée.

Pour les questions de couverture des politiques qui précèdent le choix des outils, consultez les lacunes de couverture des politiques de base d’accès conditionnel dans Entra ID. Cet article examine l’existence de politiques pour les administrateurs, les utilisateurs, les ressources et les appareils. Ce guide porte sur la reproductibilité d’une évaluation et l’interprétation de ses résultats.

Fonctionnement des outils : tests Pester et évaluation des politiques SCuBA

Maester et ses suites de tests distinctes

Maester est un framework PowerShell open source qui permet de maintenir la configuration de sécurité au moyen de tests automatisés. Son dépôt documente les tests Pester personnalisés, les exports de résultats et les intégrations aux pipelines. Pester fournit le modèle d’exécution des tests ; Maester y ajoute des tests de sécurité et des rapports. Le framework peut être étendu : consignez donc les tests effectivement installés au lieu de considérer le nom du produit comme une déclaration de couverture fixe. README du dépôt Maester.

Les suites ont des origines différentes. La suite Maester contient des tests communautaires de configuration de sécurité. La suite EIDSCA s’appuie sur Entra ID Security Config Analyzer et vérifie les mesures d’atténuation de scénarios d’attaque visant les identités. La suite CISA teste la configuration de Microsoft 365 par rapport aux recommandations SCuBA. Conservez la suite et l’identifiant du test avec chaque résultat pour que le lecteur puisse distinguer leurs sources.

Les tests CISA de Maester n’établissent pas que Maester exécute le moteur OPA de ScubaGear. Le partage d’un même référentiel n’établit pas non plus que les implémentations sont identiques. Pour comparer les constats, utilisez l’exigence, l’implémentation du test et la version examinée. Deux tests portant des noms similaires peuvent examiner des conditions différentes, comme le montrent les exemples d’authentification héritée ci-dessous.

ScubaGear et les référentiels par produit

ScubaGear fait partie du projet Secure Cloud Business Applications de CISA. Son évaluation documentée sépare collecte et évaluation : PowerShell interroge les API Microsoft 365, Open Policy Agent évalue les paramètres collectés par rapport aux politiques Rego, et l’outil génère des résultats HTML, JSON et CSV. Le document de référence décrit l’exigence de sécurité ; son implémentation automatisée détermine ce que l’exécution peut mesurer. README de ScubaGear.

Le dépôt fournit des documents de référence distincts pour Entra ID, la suite de produits de sécurité, Exchange Online, Power BI, Power Platform, SharePoint et Teams. La présence d’un document de référence ne prouve pas que chaque version peut exécuter l’évaluation de chaque produit. En particulier, le tableau des paramètres de la v1.8.0 désigne Entra ID par aad et énumère les sélecteurs de produits acceptés. Vérifiez ce tableau avant de sélectionner un produit. README versionné, paramètres v1.8.0.

Pour un travail centré sur Entra, nous recommandons de commencer par le sélecteur aad et d’examiner ses prérequis. Étendez le périmètre aux autres produits lorsque les connexions requises, les rôles et les responsables des preuves sont prêts. Il s’agit d’une recommandation opérationnelle, et non d’une affirmation selon laquelle le reste de Microsoft 365 serait évalué uniquement via Graph.

Distinguer les versions de la documentation évolutive

Les références de versions vérifiées le 3 octobre 2026 pour ce guide sont Maester 2.2.0 et ScubaGear v1.8.0. À cette date de revue, le README main de ScubaGear évoque déjà la v2.0.0. Ce guide identifie donc explicitement les références d’exécution et de permissions v1.8.0 ; les affirmations relatives à la documentation évolutive des référentiels sont citées séparément. Avant d’adopter ces exemples, figez la version du module, les versions des dépendances et la révision des tests dans une spécification d’évaluation.

Préparer l’accès Graph en lecture avant une évaluation

L’accès en lecture a deux dimensions : ce que fait l’outil et ce que son identité est autorisée à faire. Microsoft Graph distingue l’accès délégué, au nom d’un utilisateur connecté, de l’accès applicatif sans cet utilisateur. Le consentement et les rôles d’annuaire pris en charge restent déterminants. Créer une application, accorder un consentement ou configurer l’authentification relève de la préparation administrative ; il faut la distinguer des lectures ultérieures de configuration. Référence des permissions Graph, authentification Graph PowerShell.

Par exemple, lister les politiques d’accès conditionnel est une opération Graph en lecture dont la permission documentée est Policy.Read.All. L’exigence de ce point de terminaison ne suffit pas à justifier l’octroi d’accès à une suite d’évaluation entière : d’autres tests lisent d’autres ressources. List conditionalAccessPolicies.

Scopes par défaut de Maester

Le code source Get-MtGraphScope 2.2.0 définit les scopes de lecture par défaut, notamment pour l’annuaire, les politiques, les audits, les rapports, la gestion des appareils, le risque lié aux identités et les méthodes d’authentification. Il s’agit de la liste du framework, et non du minimum nécessaire à un seul test d’accès conditionnel. Directory.Read.All, par exemple, est plus large que la seule lecture de la collection des politiques.

Le même code distingue les ajouts facultatifs : -Privileged ajoute ReportSettings.ReadWrite.All, -SendMail ajoute Mail.Send, et -SendTeamsMessage ajoute ChannelMessage.Send. Gardez ces ajouts hors d’une évaluation Graph par défaut en lecture, sauf si une exigence examinée séparément les nécessite. Connect-Maester explique les connexions facultatives et le comportement des scopes privilégiés.

Ne décrivez pas Maester comme incapable de lire des journaux. Sa liste par défaut inclut AuditLog.Read.All et ThreatHunting.Read.All ; les définitions des permissions de Microsoft décrivent les lectures d’audit et les requêtes de chasse aux menaces. Le point plus précis est que les tests de référence présentés ici sont des assertions de configuration. Leur réussite ne prouve pas qu’une connexion particulière a été bloquée.

Prérequis Entra de ScubaGear

ScubaGear v1.8.0 documente le rôle Global Reader pour l’évaluation interactive d’Entra et les permissions Graph suivantes : Directory.Read.All, Policy.Read.All, PrivilegedAccess.Read.AzureADGroup, PrivilegedEligibilitySchedule.Read.AzureADGroup, RoleManagement.Read.Directory, RoleManagementPolicy.Read.AzureADGroup et User.Read.All. Examinez la procédure réelle de consentement avec l’administrateur du tenant avant l’exécution. Prérequis interactifs.

Ses prérequis non interactifs énumèrent les permissions par produit. Ils expliquent aussi que SharePoint et Power Platform nécessitent des permissions avec des privilèges d’écriture en raison des exigences de leurs API, alors que ScubaGear n’utilise pas ces privilèges pour les évaluations. Une évaluation de tous les produits ne doit donc pas être décrite comme utilisant exclusivement des permissions de lecture. Cette distinction s’applique également à l’examen des connexions de service facultatives de Maester.

Exécuter les commandes documentées et préserver leur périmètre

Les commandes suivantes sont des exemples issus de la documentation. Elles n’ont pas été exécutées sur un tenant pour cet article. Préparez et examinez d’abord l’environnement d’évaluation ; utilisez ensuite la documentation correspondant à la version retenue.

Étape 1 : préparer les tests Maester

Le guide d’installation fournit la commande d’installation de Pester :

Install-Module Pester -MinimumVersion 5.7.1 -MaximumVersion 5.7.1 -SkipPublisherCheck -Force -Scope CurrentUser

Il installe séparément Maester :

Install-Module Maester -Scope CurrentUser

Cette commande ne fixe pas la version de Maester. Déterminez la version souhaitée avant de l’utiliser pour produire des preuves reproductibles. Depuis le répertoire de tests choisi, le guide installe les tests fournis :

Install-MaesterTests

Étape 2 : se connecter et évaluer

L’exemple de connexion Graph dans Connect-Maester est :

Connect-Maester

La même documentation et l’assistant de scopes versionné donnent cet équivalent Graph direct. Il utilise la liste de scopes fournie par le module Maester installé :

Connect-MgGraph -Scopes (Get-MtGraphScope)

Ce sont deux approches alternatives de connexion. L’exemple Graph direct ne justifie pas d’exécuter les deux. Une fois les tests disponibles, la commande d’évaluation documentée est :

Invoke-Maester

La référence Invoke-Maester décrit la sélection du chemin de tests, les tags, les exclusions et la sortie des rapports. Consignez la sélection utilisée lors de votre exécution. Elle donne aussi un exemple explicite de sortie HTML :

Invoke-Maester -OutputHtmlFile './test-results/TestResults.html'

Choisissez cette variante de rapport si elle convient. Il s’agit d’une autre invocation de l’évaluation, et non d’une simple commande renommant un rapport existant. Des modules ou connexions de service facultatifs manquants peuvent entraîner l’omission de tests, comme l’explique le guide d’installation.

Étape 3 : choisir délibérément les produits ScubaGear

Le guide d’exécution v1.8.0 décrit l’exécution sous Windows, les dépendances requises et l’import d’un module téléchargé dans PowerShell 5.1. Son exemple littéral pour tous les produits est :

Invoke-SCuBA -ProductNames *

Cet exemple illustre le caractère générique documenté ; ne l’utilisez qu’après avoir examiné les prérequis du périmètre élargi. Pour la recommandation de ce guide limitée à Entra, remplacez le caractère générique par aad, en utilisant le paramètre de produit documenté. Cette substitution est une adaptation de l’exemple, et non une commande reprise mot pour mot du guide d’exécution. Conservez la sélection de produits obtenue dans la fiche d’exécution.

Mesurer ce que les résultats établissent réellement

Maester fournit des résultats de tests et des exports de rapports. ScubaGear fournit un rapport HTML global, des rapports individuels par produit, du JSON structuré et un CSV de résultats. Le JSON de ScubaGear peut conserver le contexte d’exécution et les sorties des fournisseurs, selon ses options ; ScubaResults.csv est un export de résultats plus restreint. Son ActionPlan.csv filtre les contrôles SHALL en échec et prévoit un espace pour les explications des échecs et les échéances de remédiation. Ce n’est pas le registre complet de l’évaluation. Fonctions d’export de Maester, rapports ScubaGear.

Nous recommandons de traiter les résultats dans des files distinctes :

Il s’agit de recommandations de traitement, et non de libellés de résultats inventés pour chaque version de l’un ou l’autre outil. Elles évitent de confondre un changement de population évaluée avec une amélioration. Une comparaison opérationnelle utile consigne les assertions exécutées avec succès, celles qui n’ont pas pu être exécutées et celles qui exigent une autre méthode.

Le référentiel Entra SCuBA actuel limite explicitement l’évaluation automatisée des conditions d’accès conditionnel à celles spécifiées dans ses implémentations. Il désigne aussi certaines exigences comme manuelles. Un résultat automatisé favorable laisse donc ouvertes les questions de conditions, d’exceptions et de vérification opérationnelle que l’assertion ne couvre pas.

Pour l’investigation complémentaire, lisez les lacunes d’accès conditionnel et les preuves de connexion. Cet article examine l’application réelle des politiques, les exclusions et les chemins d’authentification. Il complète un rapport de référence sans transformer les tests de configuration en affirmation portant sur chaque connexion.

Détection par évaluation récurrente et CI

L’évaluation récurrente par rapport aux référentiels détecte les changements entre des configurations observées avec succès. Nous recommandons de conserver l’identifiant du tenant, l’horodatage, la version, la révision des tests, le périmètre des produits, le profil de permissions, les erreurs, les rapports et les exceptions pour chaque exécution. Comparez des éléments comparables. Si une suite ou une dépendance change, déterminez d’abord si la différence provient de la configuration du tenant, de la logique des tests ou de la couverture de collecte.

Le guide de surveillance GitHub de Maester documente la fédération d’identité de charge de travail avec OIDC, les permissions applicatives, l’exécution planifiée et le déclenchement manuel des workflows. Son exemple de planification s’exécute chaque jour à 07:30 UTC. Choisissez une fréquence adaptée à vos besoins opérationnels ; l’exemple n’établit pas un délai de réponse approprié pour tous les tenants. -NonInteractive contrôle le comportement de présentation, notamment la suppression de l’ouverture du navigateur, et ne configure pas l’authentification. Référence des paramètres Invoke-Maester.

La documentation d’exécution de ScubaGear décrit l’exécution via un principal de service avec certificat pour les pipelines et les tâches planifiées. Les prérequis versionnés doivent régir la configuration des permissions. Nous recommandons de conserver les identifiants d’application et les références de certificat dans la configuration de la tâche, tout en gérant la clé privée réelle au moyen du processus de gestion des identifiants approuvé par l’organisation. Traitez le provisionnement et la maintenance des identifiants comme des travaux administratifs distincts.

Pour chaque outil, nous recommandons de figer ensemble le module, les tests, les dépendances et la révision de l’action CI. L’échec d’une tâche doit ouvrir une investigation opérationnelle, au lieu de réutiliser le résultat favorable d’hier comme preuve pour aujourd’hui. Orientez les régressions de configuration vers leurs responsables et conservez la justification de toute exception acceptée. Il s’agit de recommandations de processus ; aucune exécution de pipeline ni performance de réponse n’est revendiquée ici.

Un calendrier d’évaluation produit des observations aux instants d’exécution. Il ne peut pas prouver que la configuration est restée inchangée entre ces instants. Maintenez l’évaluation récurrente aux côtés du processus existant de surveillance de sécurité et rendez visible aux personnes chargées de la revue la date de la dernière collecte réussie.

Remédiation : d’un test en échec à une modification vérifiée (Remediation)

Étape 1 : lire précisément Maester MT.1009

MT.1009 vérifie l’existence d’une politique d’accès conditionnel bloquant les autres authentifications héritées. L’implémentation examinée sélectionne les politiques activées, retire celles contenant passwordChange, et recherche une autorisation de blocage avec le type de client other, les applications incluses All et les utilisateurs inclus All. Elle renvoie false si aucune ne correspond. Une condition de licence Entra Free ou une erreur interceptée peut, à la place, produire un résultat omis.

Si ce test échoue dans votre évaluation, examinez les données sélectionnées et confirmez que l’échec représente l’exigence visée. La fonction ne prouve ni l’absence d’exclusions ni le blocage de toutes les connexions pertinentes. Son implémentation constitue un point de départ concret pour l’investigation, et non un simulateur complet de politiques. Conservez la révision du code source avec le constat pour distinguer les changements ultérieurs d’implémentation de la remédiation.

Étape 2 : comparer SCuBA MS.AAD.1.1v1 sans supposer d’équivalence

MS.AAD.1.1v1 dans le référentiel v1.8.0 exige le blocage de l’authentification héritée. Ses instructions d’implémentation demandent d’identifier les dépendances héritées existantes, de cibler tous les utilisateurs et toutes les ressources, de sélectionner Exchange ActiveSync et Other clients, et d’accorder Block Access. Le seul test other de MT.1009 ne représente pas toutes ces instructions. Ce sont des identifiants Maester et SCuBA, et non des numéros de contrôles CIS.

Nous recommandons d’ouvrir une fiche de remédiation contenant l’identifiant en échec, les données de politique évaluées, l’exigence pertinente, le responsable, les dépendances concernées et la modification proposée. Si un résultat est omis, commencez par une investigation des prérequis. S’il est manuel, documentez la méthode manuelle. Aucun de ces exemples n’est un échec observé dans un tenant évalué pour cet article.

Étape 3 : valider l’impact avant l’application

Le guide Microsoft de blocage de l’authentification héritée commence par placer la nouvelle politique en mode report-only, examine l’impact et la passe à On après validation. Suivez le traitement documenté des comptes d’accès d’urgence et de tout déploiement progressif nécessaire. Identifiez les dépendances héritées légitimes et prévoyez leur migration ou une exception explicitement encadrée avant une application généralisée.

Nous recommandons de tester des chemins d’accès représentatifs des usages prévus et d’examiner les preuves d’impact de la politique avec leurs responsables. Consignez précisément le moment où l’application est activée. Une politique report-only est utile pour évaluer l’impact, mais ne peut pas établir que le blocage prévu a été appliqué. Ne supprimez pas l’étape de validation dans le seul but de satisfaire une assertion automatisée qui recherche un état activé.

Étape 4 : réexécuter, puis planifier la même revue

Après la modification approuvée, réexécutez les tests Maester pertinents ou l’évaluation de produit ScubaGear avec la sélection et les versions conservées. Examinez les nouvelles données ainsi que le résultat. Joignez les deux évaluations à la fiche de remédiation et confirmez séparément le comportement prévu au moyen du processus documenté de revue d’impact des politiques et des connexions. Référence d’exécution Maester, exécution ScubaGear, procédure de validation Microsoft.

Nous recommandons d’ajouter l’assertion résolue à la revue récurrente, avec un responsable des régressions et une expiration des exceptions. Si l’exécution suivante perd ses permissions ou omet le test, rouvrez la question des preuves. Clore une fiche de remédiation doit signifier que l’exigence définie a été revérifiée et que sa validation opérationnelle est achevée.

Comment EtcSec détecte ces lacunes

Le détecteur AZ_CIS_BENCHMARK_GAPS d’EtcSec est un agrégat de configuration contenant quatre contrôles indépendants. L’implémentation lue est public/internal/audit/detectors/azure/compliance/standards/cis-benchmark-gaps.go, avec Detect() commençant à la ligne 68. Chaque condition comptée ajoute un ; Count va de 0 à 4. Ce n’est ni un pourcentage ni le CIS Microsoft 365 Foundations Benchmark complet.

Ces conditions sont visibles dans le même fichier aux lignes 82–178. L’avertissement AZURE_CONDITIONAL_ACCESS_POLICIES_FAILED supprime les trois contrôles fondés sur les politiques. Des données de tenant manquantes peuvent laisser le contrôle Security Defaults non compté. Sans cet avertissement, une collection de politiques vide compte les trois absences de politiques. Ainsi, Count = 0 ne prouve pas que les quatre conditions ont toutes été évaluées avec succès.

La fonction renvoie son constat même à zéro ; un décompte positif et IncludeDetails déterminent l’ajout des détails des lacunes. Elle lit la configuration et les avertissements de collecte, sans consommer les résultats Maester, les rapports ScubaGear ni les preuves de connexion. Utilisez-la pour suivre ces quatre conditions au fil des audits EtcSec, puis examinez leur périmètre. Gardez l’évaluation complète des référentiels et la validation opérationnelle de l’application comme des volets distincts de la revue.