Construire un socle d'accès conditionnel par populations
Un accès conditionnel construit au fil des demandes finit illisible et troué. En partant des populations qui se connectent plutôt que des tickets, on obtient un socle cohérent, déployable sans risque et mesurable dans le temps.
Le piège de la politique au fil de l'eau
Dans beaucoup de tenants, l'accès conditionnel s'est construit ticket après ticket : une politique pour un projet, une exclusion pour un dirigeant, une règle copiée d'un article. Trois ans plus tard, on compte trente politiques, des exclusions dont plus personne ne connaît l'origine et des trous que personne ne voit. L'approche par populations remet de l'ordre : on part de qui se connecte, pas de ce qui a été demandé.
Définir les populations
Un socle robuste distingue au minimum :
- Les administrateurs : tout compte portant un rôle privilégié.
- Les utilisateurs internes : les collaborateurs, sur appareils gérés ou non.
- Les invités : les comptes B2B d'autres organisations.
- Les comptes de service encore utilisés en interactif, voués à disparaître.
- Les comptes d'accès d'urgence, exclus de manière contrôlée.
Chaque population correspond à un groupe, et chaque politique vise une population. C'est ce qui rend le socle lisible : pour n'importe quel compte, on sait quelles règles s'appliquent.
Les politiques du socle
| Politique | Cible | Effet |
|---|---|---|
| Bloquer l'authentification héritée | Tous les utilisateurs | Ferme IMAP, POP, SMTP authentifié et les anciens protocoles qui ignorent le MFA |
| MFA pour tous | Tous les utilisateurs, toutes les applications | Plus aucune connexion sur simple mot de passe |
| Force d'authentification résistante au phishing | Administrateurs | FIDO2, Windows Hello Entreprise ou certificat pour les rôles privilégiés |
| Appareil conforme ou joint | Utilisateurs internes, applications sensibles | Les données restent sur des postes gérés |
| MFA et conditions d'utilisation | Invités | Les invités sont authentifiés et ont accepté vos règles |
| Risque de connexion et d'utilisateur | Tous (licence P2) | Réauthentification ou changement de mot de passe quand un risque est détecté |
Déployer sans se verrouiller
Toute nouvelle politique commence en mode rapport uniquement. Pendant une à deux semaines, les journaux de connexion montrent ce qui aurait été bloqué : comptes oubliés, applications anciennes, flux techniques. L'outil What If permet ensuite de simuler une connexion précise avant l'activation. Et les comptes d'accès d'urgence sont exclus dès le premier jour.
Règle simple. Une politique activée sans passer par le mode rapport est un pari sur la production. Le mode rapport ne coûte rien et révèle presque toujours une surprise.
Nommer et documenter
Une convention de nommage transforme la liste des politiques en documentation : un numéro, la population, l'application, l'effet. Par exemple CA010-Admins-Toutes-Exiger-MFA-Phishing-Resistant. Chaque exclusion est justifiée dans un registre, avec un propriétaire et une date de revue.
Mesurer la dérive
Un socle se dégrade : un groupe exclu grossit, une nouvelle application échappe au périmètre, une politique reste en mode rapport « temporairement ». L'audit régulier compare l'état réel au socle attendu : politiques présentes et activées, exclusions, couverture des applications, comptes visés par aucune règle. C'est cette dérive, bien plus que l'absence de politique, qui ouvre les failles.