B—OPSOFFSEC / EU
Une bonne idee de securite se cache parfois dans un parametre banal. Dans un thread de 2021, Nathan McNulty rappelait qu'un compte Microsoft personnel peut utiliser un alias dedie pour la connexion tout en supprimant la connexion via l'adresse publique que tout le monde connait deja. Plus de cinq ans plus tard, l'idee reste pertinente. Les attaques par fatigue MFA, le phishing moderne et le vol de session n'ont pas rendu le nom de connexion moins important.
La plupart des discussions sur la securite des comptes sautent directement aux mots de passe et a la MFA. Elles ont raison. Mais un attaquant a aussi besoin d'un identifiant. Si votre adresse e-mail publique est egalement le nom de connexion d'une identite Microsoft sensible, vous avez deja rendu sa premiere etape plus simple. Et si vous creez un alias dedie a la connexion, mieux vaut qu'il soit aleatoire, discret et sans lien evident avec votre nom, votre societe ou votre marque.
La lecon cote compte personnel
Le chemin pratique a ete bien resume dans le thread de Nathan McNulty sur les alias Microsoft, qui s'appuie lui-meme sur la note initiale de Mat Velloso. Microsoft documente la logique de base dans Microsoft account aliases: ajouter un alias, le rendre principal si necessaire, puis limiter la connexion a cet alias dedie.
Cette premiere moitie concerne les comptes Microsoft personnels et, plus largement, les identites tres exposees publiquement. Ce n'est pas un modele de protection pour les identites de travail Entra.
Comment le configurer
Si vous voulez le faire sur un compte Microsoft personnel, le parcours est court. L'interface bougera un peu avec le temps, mais la logique reste la meme.
L'idee n'est pas de supprimer votre adresse publique du compte. L'idee est d'arreter d'en faire un identifiant de connexion acceptable.
1. Partir de Your info
Depuis votre compte Microsoft, ouvrez Your info puis utilisez le lien Sign-in preferences dans le bloc Account info.
2. Verifier l'alias actuellement utilise
La page Manage how you sign in to your account affiche l'alias principal actuel et donne acces a Add email. C'est aussi l'endroit ou verifier quel alias est aujourd'hui principal.
3. Ajouter un alias reserve a la connexion
Utilisez Add email pour creer une nouvelle adresse. Gardez-la discrete, idealement assez aleatoire, et ne l'utilisez pas sur des sites publics, des signatures ou des listes de contacts.
4. Garder uniquement cet alias pour la connexion
Revenez dans Sign-in preferences, laissez l'alias dedie coche pour la connexion et retirez la connexion via l'adresse publique. Verifiez aussi tous les autres identifiants encore autorises sur cette page, y compris d'anciens alias ou un numero de telephone. Si l'un d'eux est public ou facile a deviner, il ne devrait plus etre accepte pour la connexion. Votre adresse publique peut rester rattachee au compte si vous en avez encore besoin pour les e-mails. Elle ne devrait simplement plus fonctionner comme login.
Cela ne remplace ni la MFA ni un gestionnaire de mots de passe. Cela supprime surtout une exposition inutile. Les adresses publiques se retrouvent sur les sites web, les signatures, les presentations, les listes fournisseurs et les jeux de donnees issus de fuites. Si la meme chaine sert aussi d'identifiant de connexion, l'attaquant n'a meme pas besoin de deviner.
Proteger les comptes privilegies en entreprise
Le parallel s'arrete ici. La partie precedente concernait la reduction de l'exposition d'un identifiant sur un compte Microsoft personnel ou tres public. La protection des comptes privilegies en entreprise est un autre probleme : il ne s'agit plus de cacher un nom de connexion, mais de controler les chemins d'acces qui menent au pouvoir administratif.
C'est justement la valeur du Microsoft enterprise access model . Microsoft y explique qu'un environnement moderne se compose au minimum d'un plan de controle, d'un plan de gestion et d'un plan donnees/workloads. Si un attaquant prend le controle d'un plan superieur, il peut en pratique diriger ceux qui sont en dessous. C'est pour cela que les chemins d'acces privilegies doivent etre traites differemment de l'acces utilisateur standard.
La privileged access strategy part du meme constat : il n'y a pas de bouton magique. Ce qu'il faut proteger, c'est le chemin complet entre le compte, l'appareil, les roles, les intermediaires eventuels et les systemes sensibles.
Les dirigeants et leurs assistants peuvent rester des identites a forte valeur, surtout quand ils concentrent des validations, des delegations ou des acces sensibles. Mais ce n'est pas la meme chose qu'un compte d'administration Entra, un role de controle global ou un compte qui peut modifier des chemins de recuperation. Ces identites se recoupent parfois. Elles ne se protegent pas exactement de la meme maniere.
Ce que cela implique concretement pour les comptes privilegies
Le minimum credible reste classique, mais il doit etre applique avec discipline. Microsoft recommande de separer les comptes administrateur des comptes utilisateur dans Active Directory accounts. En pratique, cela veut dire qu'un compte privilegie ne devrait pas servir a la messagerie quotidienne, au web libre ou aux usages bureautiques ordinaires.
Tout aussi important, un role puissant ne devrait pas rester actif en permanence s'il n'est utilise qu'occasionnellement. Microsoft Entra Privileged Identity Management (PIM) donne justement le mecanisme pour cela : rendre le role eligible, imposer une activation, puis ajouter des garde-fous adaptes au risque comme la MFA, une approbation, une justification et une duree courte. C'est la version utile du JIT. Pas juste moins d'admins, mais moins de privilege permanent.
Ces comptes devraient aussi etre limites a des appareils admin propres. Microsoft documente explicitement l'obligation d'utiliser des appareils conformes ou hybrides joints dans Require compliant device or Microsoft Entra hybrid joined device for administrators. Et avec Filters for devices in Conditional Access, vous pouvez aller jusqu'a un groupe ferme d'appareils admin.
Pour les roles administrateur Entra, Microsoft pousse egalement vers une authentification resistante au phishing dans Require phishing-resistant multifactor authentication for Microsoft Entra administrator roles. Ce detail compte, parce qu'un compte admin protege par un appareil propre mais encore vulnerable au vol de session ou au phishing reste un chemin de compromise interessant.
En pratique, le message pour un dirigeant tient en quatre points : compte admin separe, appareil admin separe, methode d'authentification forte et gestion explicite des comptes d'urgence. C'est moins elegant qu'une astuce d'alias, mais c'est la difference entre "compte sensible" et "chemin privilegie defendable".
Et si vous avez encore de l'AD on-prem
Dans les environnements hybrides, Authentication Policies and Authentication Policy Silos restent utiles pour repondre a une question tres simple : ou ce compte a-t-il reellement le droit de s'authentifier ? Si vous avez encore des chemins privilegies on-prem, il faut aussi les fermer la, pas seulement dans Entra.
Une reserve compte ici : ce n'est pas un simple etiquetage d'objets AD. C'est un controle qui repose sur le comportement Kerberos et qui est souvent combine a des comptes proteges. Si vos flux admins s'appuient encore sur NTLM, sur la delegation par defaut ou sur des habitudes legacy cote services et postes, une partie cassera. C'est justement le but de l'exercice, mais il vaut mieux le savoir avant de passer en enforcement.
En pratique, cela veut dire creer un silo dedie pour les comptes de tres haut privilege, y placer uniquement les administrateurs concernes, les postes admin durcis et, si necessaire, les comptes de service lies a ce perimetre, puis definir depuis quels appareils et vers quels systemes ces comptes peuvent encore obtenir une authentification Kerberos. Pour des comptes de controle d'identite, la liste devrait en general se limiter aux postes admin, aux jump hosts et a un petit nombre de serveurs d'administration ou de controleurs de domaine.
Microsoft prevoit aussi un mode audit avant enforcement. C'est important. Commencez par observer quels flux casseraient, corrigez-les, puis faites appliquer la restriction. Sinon, le silo reste une bonne intention dans l'AD au lieu de devenir une vraie limite sur l'usage des identifiants privilegies.
Ce que vous pouvez faire ensuite
- Si vous gerez un compte Microsoft personnel ou tres public, retirez votre adresse e-mail publique des identifiants de connexion acceptes et remplacez-la par un alias discret, idealement aleatoire.
- Si vous supervisez des comptes privilegies, verifiez que les bases sont bien en place : compte admin separe, poste admin dedie, MFA resistante au phishing et activation juste-a-temps via PIM.
- Si votre environnement reste hybride, demandez explicitement ou ces identifiants peuvent encore s'authentifier aujourd'hui. C'est souvent la que les vieux chemins restent ouverts plus longtemps que prevu.
- Et si personne ne peut vous donner une reponse claire, c'est deja une reponse utile. Cela veut generalement dire que le sujet manque encore de proprietaire, de priorite ou de controle reel.
Le point n'est pas de tout melanger sous l'etiquette "identites importantes". Le point est au contraire de distinguer clairement deux sujets. Pour un compte personnel ou tres public, on veut reduire l'exposition du login. Pour un compte privilegie en entreprise, on veut proteger un chemin d'acces a forte consequence.
Si vous voulez verifier si vos identites sensibles sont vraiment separees, restreintes et defendables, nous contacter.
