Durcissement Tenant Azure : Defaults à Risque

Qu'est-ce que le durcissement du tenant Azure ?

Le durcissement du tenant Azure designe le travail de base qui transforme un tenant Microsoft Entra ID utilisable en tenant defensible. Pour un lecteur technique, cela ne se limite pas a "cocher Security Defaults". Il faut verifier quelle baseline est active, quels protocoles ou exceptions restent toleres, comment les identites externes sont acceptees et quelles administrations privilegiees peuvent encore contourner la trajectoire normale.

Les erreurs les plus courantes sont connues:

Security Defaults desactives sans remplacement credible par Conditional Access
methodes d'authentification gerees encore via des politiques legacy MFA/SSPR
authentification legacy ou SMTP AUTH maintenus par exception sans gouvernance stricte
invitations guest trop larges
configuration cross-tenant trop ouverte
comptes d'urgence et identites applicatives exclus de la review technique

Le probleme n'est donc pas seulement une configuration "par defaut". Le probleme est qu'un tenant jeune ou mal repris peut cumuler suffisamment d'exceptions pour offrir une surface d'attaque tres simple a des attaquants qui visent l'identite avant tout le reste.

La baseline a verifier en premier

1. Security Defaults ou Conditional Access, mais jamais le vide

Microsoft documente que Security Defaults constituent une baseline adaptee aux organisations qui ne disposent pas encore de Conditional Access ou de besoins complexes. Si les Security Defaults sont desactives, il faut prouver qu'un jeu de politiques Conditional Access couvre au moins les memes exigences essentielles.

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Select-Object IsEnabled

Si IsEnabled = False, la bonne question n'est pas "avons-nous quelques policies CA ?". La bonne question est: couvrent-elles effectivement les admins, l'authentification moderne, les risques, les invites et les exclusions critiques ?

2. Gestion moderne des methodes d'authentification

Microsoft recommande de gerer les methodes dans Authentication methods policy. Les anciennes politiques MFA et SSPR sont un mode de gestion legacy, et Microsoft a formalise leur deprecation. Un tenant peut donc paraitre "propre" dans l'interface alors que des methodes restent encore activables par heritage.

Get-MgPolicyAuthenticationMethodPolicy |
  Select-Object -ExpandProperty AuthenticationMethodConfigurations |
  Select-Object Id, State

Pour un audit technique il faut verifier:

quels methodes sont autorisees
si les anciennes policies sont encore prises en compte
si des methodes faibles ou peu desirees restent activables pour les populations sensibles

3. Invitations guest et collaboration externe

Le tenant doit clairement definir qui peut inviter des utilisateurs externes et dans quelles conditions les guests conservent un acces durable.

Get-MgPolicyAuthorizationPolicy | Select-Object AllowInvitesFrom

Dans beaucoup d'environnements le probleme n'est pas une ouverture totale visible. Le probleme est une accumulation d'exceptions: invitations diffuses, owners multiples, review d'acces absente et MFA guest acceptee sans vraie strategie.

4. Parametres cross-tenant

Les flux B2B modernes passent aussi par les cross-tenant access settings. C'est ici qu'il faut verifier si l'on fait confiance a la MFA, au device claim ou au compliant claim du tenant externe.

Get-MgPolicyCrossTenantAccessPolicyDefault

Un durcissement serieux n'accepte pas la confiance externe par inertie. Il documente explicitement ce qui est accepte en inbound et outbound, pour quels partenaires, avec quelles hypotheses.

5. Exceptions sur l'auth moderne et SMTP AUTH

Quand Security Defaults sont actives, Microsoft indique que l'authentification legacy est bloquee. Si le tenant a des exceptions Exchange Online ou SMTP AUTH, il faut les traiter comme des dettes techniques controlees, pas comme des details. Le bon niveau de preuve est concret: qui en depend encore, pourquoi, combien de temps, et quel plan de sortie existe.

Comptes d'urgence, sync et identites non humaines

C'est souvent ici que les audits s'arretent trop tot. Microsoft recommande bien d'exclure les comptes d'urgence de certaines policies MFA pour eviter un lockout total, mais cela ne veut pas dire qu'ils doivent sortir du scope de controle. Ils doivent rester rares, testes, surveilles et documentes, avec un owner clair.

Microsoft precise aussi que les comptes de synchronisation Entra Connect ou Cloud Sync places dans le role Directory Synchronization Accounts sont exclus des Security Defaults. Enfin, Microsoft documente que les service principals ne sont pas bloques par les Conditional Access policies ciblees sur les utilisateurs. Un tenant peut donc afficher une tres bonne posture MFA cote humain et rester fragile cote identites non humaines.

Une review serieuse du durcissement doit donc repondre a trois questions distinctes:

quels comptes d'urgence existent encore et comment sont-ils testes ?
quels comptes de sync ou comptes techniques disposent d'un acces privilegie durable ?
quelles applications ou workload identities utilisent encore des secrets statiques au lieu de managed identities ?

Ignorer cette couche revient a traiter l'identite comme un sujet purement utilisateur, alors que la persistance cloud passe tres souvent par des identites de service ou des exceptions d'exploitation.

Ce qu'un attaquant cherche vraiment

Dans un tenant insuffisamment durci, l'attaquant ne cherche pas un bouton magique. Il cherche une combinaison de controles moyens:

un administrateur protege seulement par une MFA non phishing-resistant ou mal ciblee
des Security Defaults desactivees sans couverture CA equivalente
des methodes d'authentification encore gerees par heritage
un ou plusieurs comptes d'urgence exclus des controles sans gouvernance reelle
des guests ou organisations externes acceptes avec trop de confiance
des applications ou service principals encore relies a des secrets statiques et a des permissions larges

Le resultat n'est pas seulement "un tenant mal configure". C'est un chemin d'attaque credible vers les roles directory, les consentements applicatifs, les donnees Microsoft 365 ou la persistance cloud.

Detection

Pour ce sujet, la detection utile melange posture et changement.

Il faut surveiller:

la desactivation ou la modification de Security Defaults
les changements dans Authentication methods policy
les modifications de policies Conditional Access qui couvrent les admins, les guests ou les ressources critiques
les invitations guest anormales ou les changements de parametres B2B/cross-tenant
les nouveaux role assignments privilegies
les secrets applicatifs ajoutes ou prolonges sans justification claire

L'audit ne doit pas se limiter a un export ponctuel. Les equipes matures conservent un inventaire regulier de:

comptes d'urgence
service principals privilegies
policies CA par objectif de securite
confiance cross-tenant par partenaire
methodes d'authentification autorisees et encore en migration legacy

Remediation

1. Choisir une baseline explicite

Si le tenant n'a ni besoin avance ni licence adaptee, Security Defaults peuvent servir de baseline. Si l'organisation depend de Conditional Access, alors il faut formellement remplacer la baseline Microsoft par une baseline maison documentee et testee.

2. Nettoyer la gestion des methodes d'authentification

Centralise les methodes dans Authentication methods policy et supprime la dependance aux anciennes policies MFA/SSPR. Ce point est souvent traite comme un detail d'interface alors qu'il change directement les methodes que les utilisateurs peuvent enregistrer et utiliser.

3. Reduire les exceptions admin

Les comptes d'urgence sont necessaires, mais ils doivent rester rares, documentes, testes et fortement controles. Les exclusions "temporaires" qui durent six mois ne sont pas des exceptions: ce sont des trous permanents dans la posture d'identite.

4. Durcir guest et external collaboration

Pour les guests:

reduire qui peut inviter
mettre en place des reviews d'acces
clarifier si la MFA du tenant d'origine est acceptee ou si un challenge local est requis
limiter l'exposition par Conditional Access et par scope fonctionnel

5. Revoir les workload identities

Les service principals ne doivent pas etre oublies parce qu'ils ne passent pas par les memes controles que les utilisateurs. La remediation correcte consiste a:

reduire leurs permissions
raccourcir la duree de vie des secrets
preferer les managed identities quand c'est possible
suivre les identites applicatives privilegiees comme une population a part entiere

6. Sortir proprement de l'auth legacy

S'il reste des dependances a SMTP AUTH ou a d'autres flux historiques, traite-les comme un programme de retrait, avec owner, date de fin et test de migration. Le bon objectif n'est pas de "tolerer un peu de legacy". Le bon objectif est de savoir exactement ou il survit encore et combien de temps tu l'acceptes.

Validation

La validation doit repondre a des questions tres concretes:

si Security Defaults sont desactivees, peux-tu demontrer quelles policies CA remplacent effectivement la baseline ?
les admins critiques sont-ils controles par des exigences plus fortes que la MFA minimale ?
les anciennes policies MFA/SSPR influencent-elles encore les methodes utilisables ?
les guests et les organisations externes sont-ils admis selon une politique ecrite et testee ?
les service principals privilegies ont-ils encore des secrets statiques evitables ?
les comptes d'urgence sont-ils testes sans devenir une filiere parallele d'administration ?

Si une de ces reponses reste floue, le tenant n'est pas encore vraiment durci.

Sources primaires

Comment EtcSec detecte cela

EtcSec traite ce sujet comme une combinaison de faiblesses:

AZ_SECURITY_DEFAULTS_DISABLED
CA_NO_LEGACY_AUTH_BLOCK
GUEST_INVITATION_UNRESTRICTED
ecarts sur MFA admin, identities externes, applications sur-privilegiees et hygiene du tenant

La vraie question n'est pas de savoir si le tenant a ete "configure". La vraie question est de savoir si ses controles d'identite resisteraient a une tentative reelle d'abus.

Durcissement du Tenant Azure : Corriger les Configs à Risque