Auditez Entra ID avant que la dérive cloud ne devienne une compromission
EtcSec exécute 158 détections sur 9 catégories Microsoft Entra ID. La couverture vise les contrôles que les attaquants abusent en premier dans Microsoft 365 et Azure : écarts Conditional Access, MFA absente, admins permanents risqués, permissions applicatives dangereuses, dérive guest et mauvaise réponse aux utilisateurs ou sign-ins risqués.
La collecte utilise Microsoft Graph API avec des permissions applicatives uniquement. Aucune session déléguée n’est nécessaire, aucun agent endpoint n’est installé, et l’audit ne modifie pas le tenant.
L’audit vérifie si tous les utilisateurs et rôles admin sont couverts, si la MFA est exigée, si l’auth legacy est bloquée, si la conformité appareil ou la token protection sont utilisées, et si des exclusions trop larges laissent des trous.
Le collector observe l’usage de PIM, les affectations permanentes, les comptes d’urgence, les réglages approval et justification, la durée d’activation et les service principals portant des rôles admin.
Le catalogue couvre les consentements tenant-wide, la politique admin consent, les permissions Graph à privilèges élevés, l’implicit grant, le multi-tenant, les owners manquants, les secrets expirés et les credentials trop longs.
Guest admins, invitations sans contrôle, comptes guest obsolètes, MFA guest absente, confiance cross-tenant et exposition B2B font partie du review Entra de base.
Les 9 catégories collent à la manière dont l’identité cloud est réellement abusée
L’audit Entra n’est pas un score cloud générique. C’est une revue de contrôles organisée autour de Conditional Access, des privilèges, du consentement applicatif, de la gouvernance externe et de la réponse basée sur le risque.
Identity et MFA
25 détections couvrant les politiques d’enrôlement, les méthodes fortes, le passwordless, les comptes utilisateurs obsolètes, SSPR et la protection de mots de passe.
Applications et service principals
24 détections sur les permissions Graph dangereuses, les consentements tenant-wide, les owners d’apps, l’implicit grant, le multi-tenant et l’hygiène des secrets.
Conditional Access
20 détections sur la couverture tous utilisateurs et admins, la MFA, le blocage legacy auth, la conformité appareil, les politiques basées sur le risque et les exclusions.
Privileged Access et PIM
18 détections sur PIM, les affectations permanentes, les comptes d’urgence, l’approval, la justification, la MFA à l’activation et le nombre de Global Admins.
Guests, groupes et config
39 détections sur les guests, la confiance cross-tenant, les groupes dynamiques, les groupes role-assignable, les réglages tenant et l’export de logs.
Conformité et Risk Protection
18 détections sur les licences P2, les access reviews, la posture Identity Protection, les utilisateurs risqués et les écarts de réponse automatisée.
Pourquoi les équipes utilisent EtcSec pour les revues Entra ID
L’identité cloud change en continu. Un audit utile doit pouvoir être relancé après modification de policy, onboarding applicatif, évolution de collaboration externe ou revue d’accès privilégié.
Workflow Graph en lecture seule
L’audit repose sur des permissions applicatives Graph. Aucune session utilisateur déléguée et aucune mutation du tenant ne sont nécessaires pour produire les findings.
Assez rapide pour suivre les fenêtres de changement
Le runtime typique est de 8 à 30 secondes selon la taille du tenant et le throttling Graph. Cela rend la revue récurrente réaliste.
Des findings nommés alignés avec les tâches des opérateurs
Les propriétaires Conditional Access, IAM, app platform et gouvernance voient les findings de leur périmètre au lieu d’un score cloud mélangé.
Un collector pour le cloud et l’on-prem
Le même ETC Collector peut auditer Active Directory et Microsoft Entra ID, ce qui compte pour les programmes hybrides où la dérive d’un plan amplifie le risque de l’autre.
Ce qu’un audit Entra ID sérieux doit rendre explicite
La posture cloud est trop souvent réduite à “a-t-on la MFA ?”. Le catalogue publié montre pourquoi c’est insuffisant : permissions, réglages tenant, gouvernance guest et réponse au risque interagissent.
Collecte Graph en lecture seule et endpoints clés
L’audit lit `/users`, `/groups`, `/applications`, `/servicePrincipals`, `/identity/conditionalAccess/policies`, `/roleManagement/directory`, `/policies/authorizationPolicy` et les endpoints pertinents d’audit ou d’Identity Protection. Les findings restent ainsi rattachés à des objets concrets plutôt qu’à une posture cloud décrite de manière générique.
L’usage de permissions applicatives rend aussi le workflow adapté à l’automatisation. Les équipes sécurité n’ont pas besoin d’une session admin interactive pour vérifier si une policy protège toujours tous les admins ou si un onboarding applicatif a réintroduit des permissions excessives.
Les 9 catégories et les questions opérateurs auxquelles elles répondent
| Catégorie | Contrôles | Ce que l’opérateur apprend |
|---|---|---|
| Identity | 25 | Si MFA, politique mot de passe, SSPR, enrôlement et comptes obsolètes résistent aux attaques modernes. |
| Applications | 24 | Si les app registrations, service principals, consentements et credentials donnent un accès excessif ou orphelin. |
| Conditional Access | 20 | Si la couverture est complète pour tous les utilisateurs, les admins, le legacy, le risque et les sessions. |
| Privileged Access | 18 | Si PIM est bien utilisé, si les comptes d’urgence existent et si les rôles admin restent permanents. |
| Guest External | 15 | Si les guests, invitations et collaborations cross-tenant restent bornées et auditables. |
| Config | 12 | Si les réglages tenant, diagnostics, consentements et app registration supportent une exploitation sûre. |
| Groups | 12 | Si les groupes dynamiques, role-assignable ou pilotés par des externes cachent du privilège. |
| Compliance | 8 | Si le tenant est licencié et configuré pour les access reviews et Identity Protection. |
| Risk Protection | 10 | Si les utilisateurs et sign-ins risqués sont détectés puis traités automatiquement. |
Les familles de détections qui déclenchent le plus souvent la remédiation
Écarts Conditional Access
Les findings clés incluent CA_NO_MFA_REQUIREMENT, CA_NO_POLICY_ALL_USERS, CA_NO_POLICY_ADMINS, CA_NO_LEGACY_AUTH_BLOCK, CA_NO_DEVICE_COMPLIANCE, CA_NO_RISK_BASED_SIGNIN et CA_POLICY_REPORT_ONLY.
- Montre si le tenant repose sur une couverture partielle.
- Sépare les contrôles basés sur le risque du baseline MFA.
- Rend visibles les exclusions qui restent souvent cachées dans le JSON.
Dérive d’accès privilégié
PA_PIM_NOT_ENABLED, PA_PERMANENT_ADMIN_ASSIGNMENTS, PA_NO_EMERGENCY_ACCOUNTS, PA_GLOBAL_ADMIN_NOT_MFA, PA_TOO_MANY_GLOBAL_ADMINS et PA_SERVICE_PRINCIPAL_ADMIN décrivent si le privilège reste permanent et mal protégé.
- Utile pour IAM, cloud platform et gouvernance.
- Isole la conception des comptes d’urgence de l’hygiène PIM.
- Met en avant les service principals car la MFA n’y compense rien.
Risque applicatif et consentement
APP_USER_CONSENT_UNRESTRICTED, APP_DANGEROUS_PERMISSION_DIR, APP_DANGEROUS_PERMISSION_ROLE, APP_NO_OWNER, APP_SECRET_EXPIRED, APP_SECRET_LONG_EXPIRY et SP_HIGH_PRIVILEGE exposent les chemins d’escalade et d’exfiltration les plus fréquents.
- Combine revue des app registrations et posture des service principals.
- Remonte l’hygiène des credentials, pas seulement les permissions.
- Aide au nettoyage après fusions ou sprawl cloud.
Gouvernance guest et cross-tenant
GUEST_ADMIN_ROLE, GUEST_NO_MFA_REQUIRED, GUEST_INVITATION_UNRESTRICTED, B2B_CROSS_TENANT_OPEN, GUEST_STALE_90_DAYS et GUEST_NO_ACCESS_REVIEW montrent si la collaboration externe reste contrôlée.
- Particulièrement utile dans les environnements M&A ou partenaires.
- Sépare la politique d’invitation de la population guest réellement obsolète.
- Montre où les guests sont déjà présents dans des groupes sensibles.
Identity Protection et réponse au risque
RISK_NO_SIGNIN_RISK_POLICY, RISK_NO_USER_RISK_POLICY, RISK_HIGH_RISK_USERS_ACTIVE, RISK_LEAKED_CREDENTIALS et RISK_USERS_NOT_REMEDIATED montrent si le tenant sait réagir quand Microsoft signale un compte ou un sign-in à risque.
- Détection sans réponse = compromission toujours active.
- Lie licence, configuration de policy et réponse opérationnelle.
- Distingue simple télémétrie et vraie protection appliquée.
Comment les findings se mappent aux frontières de responsabilité
Les propriétaires Conditional Access regardent d’abord la catégorie CA, mais leurs choix déterminent aussi la protection des admins, des guests et des utilisateurs risqués. Les owners de plateformes applicatives ont besoin des findings Applications parce que les consentements et privilèges de service principals apparaissent souvent hors du workflow IAM central. La gouvernance se concentre sur Compliance et Risk Protection, car ces catégories révèlent si PIM, Identity Protection et les access reviews sont réellement utilisés.
Une page Entra utile doit donc faire plus qu’annoncer “on audite Entra ID”. Elle doit montrer comment les findings se rattachent à des modèles d’exploitation concrets : onboarding d’app, affectation de rôles admin, collaboration externe, automatisation de la réponse au risque et supervision hybride.
- IAM et cloud engineering possèdent les décisions Conditional Access et PIM.
- Les équipes applicatives possèdent les registrations, owners et rotations de secrets.
- La gouvernance possède les access reviews, les preuves de conformité et la réponse au risque.
- Les programmes hybrides ont besoin d’un workflow commun cloud et on-prem.
Pourquoi le collector compte même pour une revue pure cloud
La documentation du collector est claire : le workflow n’est pas éclaté entre un produit cloud d’un côté et un produit on-prem de l’autre. Le même collector peut interroger Graph pour Entra et LDAP ou SMB pour Active Directory. Cela compte parce que beaucoup de problèmes hybrides sont composés. Un compte de service on-prem périmé et un admin cloud sans MFA participent souvent au même récit de compromission.
EtcSec ajoute la couche dashboard et exploitation par-dessus le collector. Le résultat est un passage de la revue de contrôles cloud brute vers une remédiation récurrente et un suivi historique, et non un simple export CSV.
Questions fréquentes
Que couvre exactement l’audit Entra ID ?
Le catalogue publié liste 158 détections sur Identity (29), Applications (28), Conditional Access (20), Privileged Access (24), Guest External (15), Config (12), Groups (12), Compliance (8) et Risk Protection (10).
L’audit nécessite-t-il des permissions déléguées ou une session admin interactive ?
Non. Le review repose sur des permissions applicatives Microsoft Graph et ne requiert pas de session déléguée interactive. Cela rend le workflow compatible avec l’automatisation.
Peut-on revoir Entra et Active Directory dans le même workflow ?
Oui. ETC Collector supporte Entra ID et Active Directory afin que les équipes hybrides exécutent les deux revues avec le même modèle de collecte.
Pourquoi traiter les permissions applicatives et la gouvernance guest comme des sujets de premier rang ?
Parce que beaucoup d’incidents d’identité cloud commencent par le consent phishing, des permissions Graph excessives, des service principals obsolètes ou des réglages de collaboration externe trop ouverts, et pas seulement par une case MFA manquante.
Pages liées à la sécurité identitaire
Voir le catalogue on-prem qui complète la revue Entra pour les programmes d’identité hybrides.
Inspecter les détections nommées qui alimentent les pages cloud et on-prem.
Comprendre le workflow de collecte, le mode standalone, le daemon et la surface API.
Comparer le moteur de collecte open-source avec la couche SaaS pour dashboards et suivi.
Démarrez votre audit Microsoft Entra ID
Connectez-vous avec des permissions Graph en lecture seule, revoyez Conditional Access, les privilèges, les applications, les guests et le risque, puis transformez la sortie en remédiation récurrente.