Durcissement du Tenant Azure : Corriger les Configs à Risque

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

Microsoft active désormais automatiquement les paramètres de sécurité par défaut (Security Defaults) pour les nouveaux tenants Microsoft 365 et Azure — avec un délai de grâce de 24 heures avant leur application, et uniquement si le tenant ne dispose pas déjà de stratégies d'accès conditionnel ou d'une MFA héritée par utilisateur. En pratique, de nombreux tenants en production fonctionnent encore sans véritable base de sécurité : les paramètres de sécurité par défaut sont désactivés dès qu'un administrateur commence à construire un accès conditionnel personnalisé, et la stratégie de remplacement n'est jamais finalisée ; les protocoles d'authentification héritée restent accessibles ; les invitations d'invités sont ouvertes à tout utilisateur ; et aucune stratégie d'accès conditionnel ne comble les brèches laissées derrière.

Le durcissement du tenant est le processus consistant à revoir et corriger systématiquement ces paramètres par défaut. Ce n'est pas un travail spectaculaire, mais il est fondamental : tous les autres contrôles de sécurité Azure — l'accès conditionnel, PIM, Identity Protection — dépendent de la justesse de la configuration du tenant.

Cet article couvre les vérifications de configuration du tenant Azure les plus critiques, ainsi que la manière de les valider et de les corriger.

Comment cela fonctionne

La configuration du tenant Azure est gérée depuis plusieurs emplacements :

• Entra ID > Properties — paramètres à l'échelle du tenant, y compris les paramètres de sécurité par défaut
• Entra ID > External Identities — paramètres relatifs aux invités et à la collaboration B2B
• Entra ID > Authentication Methods — méthodes MFA autorisées
• Exchange Online Admin Center — paramètres d'authentification héritée pour les protocoles de messagerie
• Microsoft 365 Admin Center — paramètres de sécurité au niveau des services

Une mauvaise configuration à n'importe lequel de ces niveaux peut créer une surface d'attaque qui contourne tous les autres contrôles. Une stratégie d'accès conditionnel parfaitement configurée ne sert à rien si l'authentification héritée est encore activée au niveau d'Exchange.

La chaîne d'attaque

Exploiter la désactivation des paramètres de sécurité par défaut

Lorsque les paramètres de sécurité par défaut sont désactivés et qu'aucune stratégie d'accès conditionnel ne comble le vide :

# Password spraying contre M365 sans base MFA
o365spray --spray -U users.txt -P passwords.txt --domain corp.com

# Contournement de l'authentification héritée — l'accès IMAP ignore l'accès conditionnel
curl -u [email protected]:Password1 imaps://outlook.office365.com/INBOX

Exploiter des paramètres B2B ouverts

# Avec n'importe quel compte membre — inviter une identité externe contrôlée par l'attaquant
New-MgInvitation -InvitedUserEmailAddress "[email protected]" `
    -InviteRedirectUrl "https://myapps.microsoft.com" `
    -SendInvitationMessage $false

Liste de vérification de l'audit de configuration

1. État des paramètres de sécurité par défaut

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Select-Object IsEnabled
# Devrait être True (si aucune stratégie d'accès conditionnel n'est en place)

2. État de l'authentification héritée

# Vérifier les stratégies d'authentification héritée d'Exchange Online
Connect-ExchangeOnline
Get-AuthenticationPolicy | Select-Object Name, AllowBasicAuth*
# Toutes les valeurs AllowBasicAuth* devraient être False

3. Paramètres d'invitation des invités

# Vérifier qui peut inviter des invités
Get-MgPolicyAuthorizationPolicy | Select-Object AllowInvitesFrom
# Valeurs valides : none, adminsAndGuestInviters, adminsGuestInvitersAndAllMembers, everyone
# Devrait être : none ou adminsAndGuestInviters

4. Stratégie des méthodes d'authentification

# Lister les méthodes d'authentification activées
Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethodConfigurations |
    Where-Object {$_.State -eq "enabled"} | Select-Object Id, State
# Vérifier que SMS n'est pas la seule méthode MFA (sensible au phishing) — privilégier l'application Authenticator ou FIDO2

5. Paramètres d'accès entre tenants

# Vérifier si la collaboration B2B entrante est ouverte à toutes les organisations externes
Get-MgPolicyCrossTenantAccessPolicyDefault | Select-Object -ExpandProperty B2BCollaborationInbound |
    Select-Object -ExpandProperty UsersAndGroups
# AccessType ne devrait pas être "allowed" pour la cible "AllUsers" sans restrictions supplémentaires

Détection

Microsoft 365 Secure Score

Microsoft 365 Secure Score fournit une évaluation automatisée de la configuration du tenant par rapport à la base de référence recommandée par Microsoft. Consultez-le sur security.microsoft.com > Secure Score.

Microsoft plafonne chaque action recommandée à 10 points ou moins, et évalue nombre d'entre elles sous forme de pourcentage de la configuration de votre tenant plutôt qu'avec une valeur fixe — il n'existe pas de valeur en points universelle et figée par action. Exemples concrets tirés du propre guide de notation de Microsoft : exiger la MFA pour les rôles administratifs vaut 10 points, s'assurer que tous les utilisateurs peuvent effectuer la MFA vaut 9 points, et bloquer l'authentification héritée via l'accès conditionnel vaut 7 points. Restreindre les invitations d'invités et activer Privileged Identity Management augmentent également votre score — consultez la liste de recommandations propre à Secure Score pour connaître les valeurs exactes dans votre tenant.

Journaux d'audit Entra ID

// Détecter la désactivation des paramètres de sécurité par défaut
AuditLogs
| where OperationName == "Update security defaults"
| mv-expand props = TargetResources.modifiedProperties
| where tostring(props.newValue) has "false"

Remédiation

Activer les paramètres de sécurité par défaut (en l'absence d'accès conditionnel)

Entra ID > Propriétés > Gérer les paramètres de sécurité par défaut > Activé = Oui

Désactiver l'authentification héritée globalement

# Créer une stratégie d'authentification bloquant toute authentification de base
New-AuthenticationPolicy -Name "Block Basic Auth"
Set-AuthenticationPolicy -Identity "Block Basic Auth" `
    -AllowBasicAuthImap $false -AllowBasicAuthPop $false `
    -AllowBasicAuthSmtp $false -AllowBasicAuthWebServices $false `
    -AllowBasicAuthRpc $false -AllowBasicAuthMapi $false

# Appliquer à tous les utilisateurs
Get-User -ResultSize Unlimited | Set-User -AuthenticationPolicy "Block Basic Auth"

Restreindre les invitations d'invités

Entra ID > External Identities > Paramètres de collaboration externe :
Paramètres d'invitation des invités = « Seuls les utilisateurs disposant de rôles d'administrateur spécifiques peuvent inviter »

Activer des méthodes MFA résistantes au phishing

Entra ID > Méthodes d'authentification > Clés de sécurité FIDO2 = Activé (pour tous ou pour les administrateurs)
Entra ID > Méthodes d'authentification > Microsoft Authenticator = Activé
Entra ID > Méthodes d'authentification > SMS = Désactivé (sensible au phishing, remplacer par Authenticator)

Comment EtcSec détecte cela

EtcSec audite l'intégralité de la configuration de votre tenant Azure à chaque analyse, en vérifiant chaque paramètre qui affecte la base de sécurité.

AZ_SECURITY_DEFAULTS_DISABLED signale les tenants où les paramètres de sécurité par défaut sont désactivés — une lacune fondamentale de la base de sécurité qui supprime des protections à l'échelle du tenant, comme l'application de base de la MFA.

CA_NO_LEGACY_AUTH_BLOCK signale l'absence d'une stratégie d'accès conditionnel bloquant les protocoles d'authentification héritée, laissant ouvert un contournement de la MFA pour tout attaquant disposant d'un mot de passe volé.

GUEST_INVITATION_UNRESTRICTED signale les tenants où la stratégie d'invitation des invités permet à tout utilisateur d'inviter des invités externes, au lieu de restreindre les invitations aux administrateurs ou à des rôles spécifiques.

Priorités de revue

Durcissement du tenant Azure : corriger les paramètres non sécurisés livrés d'origine doit être traité comme une exposition réelle au sein de votre tenant Entra ID et Azure, et non comme un simple paramètre isolé. Commencez par définir le périmètre de la revue : quels administrateurs, invités, principaux de service, inscriptions d'applications, exclusions de stratégies et comptes de secours (break-glass) sont concernés, quels workflows métier en dépendent, quels privilèges ils exposent, et quelles exceptions d'urgence ont été ajoutées au fil du temps. Cette étape de cadrage évite une remédiation superficielle, car le symptôme technique est souvent plus restreint que le rayon d'impact opérationnel réel. En documentant le chemin complet entre la configuration et le privilège, l'équipe peut prioriser les changements qui réduisent le risque rapidement sans casser l'accès en production. Cela crée également une base défendable pour la validation ultérieure et donne à la direction une explication claire de l'importance du problème aujourd'hui.

Contrôles adjacents à revoir

Lorsque des attaquants atteignent votre tenant Entra ID et Azure, ils s'arrêtent rarement au premier point faible. Autour de Durcissement du tenant Azure : corriger les paramètres non sécurisés livrés d'origine, ils testent généralement si le chemin exposé peut être enchaîné avec l'authentification héritée, une gouvernance des invités défaillante, un consentement d'application trop large, des comptes d'urgence obsolètes et des rôles qui n'ont jamais été revus. Cela signifie que les défenseurs doivent examiner non seulement la faiblesse principale, mais aussi chaque dépendance voisine qui transforme un accès en persistance ou en élévation de privilèges. Confirmez quelles identités, quels rôles, quelles permissions et quelles hypothèses de confiance peuvent être réutilisés par un opérateur motivé. Si une correction ne referme qu'un seul objet en laissant intacts les chemins de privilèges adjacents, le risque effectif change à peine. Une revue rigoureuse des possibilités d'enchaînement est ce qui transforme ce sujet en un exercice de durcissement pratique plutôt qu'en une simple case à cocher ponctuelle.

Preuves et télémétrie à collecter

Une réponse solide à Durcissement du tenant Azure : corriger les paramètres non sécurisés livrés d'origine nécessite des preuves pouvant être examinées à la fois par les équipes d'ingénierie et de détection. Collectez les journaux de connexion, les journaux d'audit, les changements d'attribution de rôles, les événements de consentement, les changements d'identifiants d'application et les signaux de connexion à risque, comparez les changements récents avec les fenêtres de maintenance connues, et isolez les comptes ou systèmes dont le comportement a changé sans raison métier claire. Utilisez ces preuves pour répondre à trois questions : quand le chemin à risque est-il apparu, qui peut encore l'utiliser, et une exposition similaire existe-t-elle ailleurs dans votre tenant Entra ID et Azure. Un bon examen de la télémétrie aide également à distinguer la dette technique héritée d'un abus actif. Cette distinction compte, car le plan de remédiation pour une mauvaise configuration ancienne diffère du plan pour un chemin qui montre déjà une activité de type attaquant ou des exceptions de stratégie répétées.

Faiblesses adjacentes à examiner

Très peu d'environnements ne présentent que Durcissement du tenant Azure : corriger les paramètres non sécurisés livrés d'origine de manière isolée. En pratique, le même tenant ou le même segment d'annuaire contient souvent de l'authentification héritée, une gouvernance des invités défaillante, un consentement d'application trop large, des comptes d'urgence obsolètes et des rôles jamais revus, et ces faiblesses voisines déterminent si le problème est simplement bruyant ou véritablement critique. Examinez les propriétaires partagés, les permissions héritées, les exceptions dupliquées et les raccourcis administratifs de longue durée. Vérifiez si la même équipe a approuvé des schémas à risque similaires à plusieurs endroits, car des décisions répétées indiquent généralement une lacune de processus plutôt qu'un simple bug technique isolé. Cette revue plus large évite un nettoyage partiel et augmente vos chances d'éliminer l'intégralité du chemin d'attaque. Elle améliore également la préparation aux audits, car l'état final est plus facile à expliquer et à surveiller dans la durée.

Ordre de remédiation qui réduit rapidement le risque

Pour Durcissement du tenant Azure : corriger les paramètres non sécurisés livrés d'origine, la remédiation doit suivre un ordre qui réduit l'exposition avant de viser la perfection. Supprimez d'abord les chemins d'expansion de privilèges les plus faciles, puis verrouillez les identités ou objets à plus forte valeur, et ce n'est qu'ensuite que vous nettoyez les lacunes d'hygiène secondaires. Utilisez l'accès conditionnel, PIM, le moindre privilège, les revues d'accès, les vérifications de propriété des applications, les workflows d'approbation et une MFA forte comme ensemble de contrôles définissant l'état cible. Chaque changement doit avoir un propriétaire, une note de retour arrière et une étape de validation. Cela évite que les longs projets ne s'arrêtent après la première correction technique. Si une refonte complète n'est pas immédiatement possible, documentez des contrôles intermédiaires qui réduisent le potentiel d'abus dès aujourd'hui, et planifiez le travail structurel lors de la prochaine revue opérationnelle hebdomadaire et de la revue de durcissement mensuelle. Le point important est la réduction mesurable du risque, pas une conformité cosmétique.

Validation après chaque changement

Après avoir modifié tout paramètre lié à Durcissement du tenant Azure : corriger les paramètres non sécurisés livrés d'origine, validez le résultat à la fois du point de vue de l'administration et du point de vue du chemin d'attaque. Confirmez que les utilisateurs et systèmes prévus fonctionnent toujours, puis prouvez que le chemin dangereux n'offre plus le même levier. Relancez la collecte de preuves sur les journaux de connexion, les journaux d'audit, les changements d'attribution de rôles, les événements de consentement, les changements d'identifiants d'application et les signaux de connexion à risque, examinez les enregistrements d'approbation, et vérifiez si des objets voisins conservent encore un contournement. La validation doit également inclure un énoncé écrit simple des critères de succès, afin que l'équipe sache ce que signifie la clôture. Dans les équipes matures, cette étape est ce qui évite les régressions : la correction n'est acceptée que lorsque le chemin à risque est fermé, que le service métier fonctionne toujours, et que l'état résultant correspond à la cible de durcissement réellement souhaitée.

Durcissement du tenant Azure : validation avant clôture

Une revue solide du durcissement du tenant Azure doit se conclure par des preuves issues de la production, et non par une simple présomption que le chemin à risque a disparu. Avant de clôturer le constat, revérifiez les attributions de rôles, la portée des stratégies, les permissions d'application ou les paramètres d'invités, les preuves de connexion, d'audit ou de risque issues du tenant réel, ainsi que le chemin d'exception qui pourrait recréer silencieusement l'exposition. Confirmez que l'état plus sûr s'applique bien à la portée qui compte réellement : l'OU de production, l'attribution de rôle effective, le chemin applicatif, ou le chemin de confiance et de délégation qu'un attaquant exploiterait réellement. Consignez le propriétaire technique, la dépendance métier et la condition de retour arrière, afin que la prochaine revue puisse déterminer si l'état plus sûr a été maintenu.

Utilisez une brève liste de contrôle de clôture :

• vérifiez que l'état à risque a bien disparu du point de vue de l'attaquant, pas seulement sur une capture d'écran d'administration
• conservez un export ou un échantillon de journal avant/après prouvant que la portée concernée a changé
• documentez le propriétaire et la décision d'exception si le contrôle n'a pas pu être pleinement appliqué

Pour une exposition adjacente, recoupez le résultat avec Conformité AD & Azure : NIS2, ISO 27001, CIS, Failles acces conditionnel Entra ID : quelles mauvaises configurations laissent une vraie exposition, Acces Privilegie Azure : Trop d'Admins Globaux, et Comparatif outil audit AD : comment comparer PingCastle, Purple Knight et des workflows d'audit répétables. La même lacune de contrôle réapparaît souvent dans des chemins d'identité voisins, des lacunes de journalisation ou des permissions déléguées, ce qui explique pourquoi l'étape de validation finale compte autant que le constat initial.

Durcissement du tenant Azure : preuves à conserver pour le prochain cycle de revue

Le prochain relecteur ne devrait pas avoir à reconstruire le dossier de mémoire. Conservez les preuves qui justifiaient initialement le constat, la preuve que le changement a été appliqué, et la note expliquant pourquoi l'état final est acceptable. Pour ce sujet, les preuves les plus utiles combinent généralement l'export du tenant ou la capture d'écran montrant la portée concernée, les preuves de connexion, d'audit ou de stratégie démontrant que le contrôle s'applique désormais, et la note de propriétaire, d'approbation et d'exception pour l'état final. Ce dossier compact rend les revues trimestrielles ou post-changement beaucoup plus rapides et aide à expliquer si le problème a été supprimé, réduit ou formellement accepté.

Si un changement ultérieur d'administrateur, de stratégie ou d'application rouvre le chemin, cette preuve historique facilite également la démonstration de ce qui a dérivé. C'est ce qui transforme le durcissement du tenant Azure d'une vérification ponctuelle en un processus d'assurance reproductible.

Lectures complémentaires

Associez ce sujet à Failles acces conditionnel Entra ID : quelles mauvaises configurations laissent une vraie exposition, Acces Privilegie Azure : Trop d'Admins Globaux, Comptes Invités Azure : Risques du Tenant, Applications Azure Sur-Privilegiees dans Votre Tenant, et Azure Identity Protection : Bloquer les Identifiants Divulgués. Ces articles connexes montrent comment les mêmes faiblesses d'identité s'enchaînent habituellement lors d'une évaluation réelle, plutôt que d'apparaître comme des constats isolés.

• Failles acces conditionnel Entra ID : quelles mauvaises configurations laissent une vraie exposition
• Acces Privilegie Azure : Trop d'Admins Globaux
• Comptes Invités Azure : Risques du Tenant
• Applications Azure Sur-Privilegiees dans Votre Tenant
• Azure Identity Protection : Bloquer les Identifiants Divulgués

L'utilisation de ces références permet de maintenir la discussion sur la remédiation centrée sur l'ensemble du chemin d'attaque plutôt que sur une seule lacune de contrôle.

Valider la base de durcissement dans la durée

Les paramètres par défaut doivent être considérés comme un point de départ, et non comme le résultat final du durcissement. Après avoir appliqué des paramètres de tenant plus sûrs par défaut, vérifiez quelles équipes s'appuient encore sur des exceptions larges, si de nouvelles applications ou de nouveaux utilisateurs peuvent contourner les contrôles prévus, et comment la dérive est surveillée dans le temps. Un tenant durci ne reste résilient que si la responsabilité, la cadence de revue et la gestion des exceptions sont aussi rigoureuses que le déploiement initial.