Top 10 des mauvaises configurations Entra ID à corriger en priorité

D'un audit à l'autre, les mêmes faiblesses Entra ID reviennent sans cesse. Aucune n'est exotique — ce sont des lacunes du quotidien que les attaquants exploitent activement. Voici les dix à corriger en premier, en ordre d'impact approximatif.

1. Authentification héritée non bloquée

Les protocoles hérités (POP, IMAP, SMTP AUTH, anciens clients Office) contournent les contrôles modernes, dont le MFA. Les laisser activés est l'une des lacunes les plus exploitées d'Entra ID. Bloquez l'authentification héritée par une politique d'accès conditionnel — après avoir vérifié dans les journaux de connexion ce qui l'utilise encore.

2. Comptes à privilèges sans MFA

Les Administrateurs généraux et autres rôles à privilèges sans MFA imposé sont la cible la plus précieuse de votre tenant. Chaque compte d'administration doit exiger un MFA résistant au phishing, sans exception.

3. Trop d'Administrateurs généraux

Plus vous avez d'Admins généraux, plus votre surface d'attaque est grande. Gardez leur nombre minimal, utilisez des rôles au moindre privilège pour les tâches quotidiennes et réservez l'Admin général au petit nombre qui en a vraiment besoin.

4. Pas de Privileged Identity Management (PIM)

L'accès à privilèges permanent est une vulnérabilité. PIM rend les rôles à privilèges juste-à-temps et limités dans le temps, avec approbation et audit. Sans lui, les droits d'admin sont permanents — et les droits permanents finissent par être détournés.

5. Accès invité grand ouvert

Les paramètres invités par défaut laissent souvent les utilisateurs externes énumérer bien plus que nécessaire, et les invités n'ont fréquemment pas de MFA imposé. Restreignez les permissions invité et exigez le MFA pour les identités externes.

6. Accès conditionnel faible ou absent

L'accès conditionnel est le moteur de politique d'Entra ID. Les lacunes — pas de politique MFA de base, pas de condition d'appareil ou de localisation, portails d'admin non protégés — laissent la porte d'entrée entrouverte. Construisez un ensemble cohérent de politiques et revoyez-les régulièrement.

7. Rétention des journaux insuffisante

Si les journaux de connexion et d'audit ne sont pas conservés assez longtemps (ou exportés vers un SIEM), vous ne pouvez pas enquêter après un incident. Assurez-vous que la rétention couvre vos besoins d'investigation et de conformité — souvent 180 jours ou plus.

8. Paramètres self-service trop permissifs

Des utilisateurs pouvant enregistrer des applications, consentir à des applications tierces ou inviter des invités sans supervision créent un flux constant de risque. Resserrez les paramètres self-service et de consentement d'application, et exigez le consentement admin pour tout ce qui est sensible.

9. Comptes obsolètes et identifiants inutilisés

Comptes désactivés mais non supprimés, principaux de service inutilisés et identifiants résiduels élargissent silencieusement votre surface d'attaque. Passez-les en revue et nettoyez-les selon un calendrier.

10. Pas de stratégie de compte de secours

Les comptes d'accès d'urgence (« break-glass ») doivent exister, être exclus de l'accès conditionnel qui pourrait vous verrouiller, utiliser des identifiants forts et uniques, et être surveillés. Se tromper ici, c'est soit le verrouillage, soit un super-compte non surveillé.