Entra Backup and Recovery : 7 jours de filet, et après ?

Vendredi, 17h40. Quelqu’un supprime la mauvaise stratégie d’accès conditionnel en faisant du ménage. Jusqu’au printemps dernier, ta seule option dans Entra ID était de la recréer de mémoire, ou depuis un export que tu espérais à jour. Depuis juin 2026, Microsoft Entra Backup and Recovery est disponible en GA : une sauvegarde quotidienne de ton tenant, automatique, que personne ne peut désactiver.

C’est une vraie avancée. Mais la rétention est de sept jours, et la liste des propriétés restaurables est plus courte que ce que le nom du produit laisse imaginer. Voici ce que le service couvre vraiment, ce qu’il laisse de côté, et ce que tu dois garder en plus.

Ce que fait le service

D’après la documentation Microsoft Learn, le fonctionnement tient en peu de lignes :

• une sauvegarde par jour, conservée 7 jours (c’était 5 pendant la preview) ;
• activée d’office, et impossible à désactiver, supprimer ou modifier, même par un Global Administrator ;
• stockée dans la même zone géographique que ton tenant ;
• réservée aux tenants workforce avec licences Entra ID P1 ou P2 (les tenants External ID et Azure AD B2C ne sont pas pris en charge).

Dans le centre d’administration Entra, le menu Backup and recovery te donne quatre écrans : la liste des sauvegardes, les rapports de différences, la restauration (sur tout, sur certains types d’objets ou sur des ID précis) et l’historique des restaurations. Deux rôles dédiés existent : Microsoft Entra Backup Reader pour consulter, Microsoft Entra Backup Administrator pour lancer comparaisons et restaurations.

Le fait que la sauvegarde soit hors de portée d’un admin compromis compte beaucoup. Un attaquant avec des droits élevés ne peut pas effacer ton point de retour.

Ce qui est couvert, et ce qui ne l’est pas

Bien couvert

Les stratégies d’accès conditionnel et les emplacements nommés sont sauvegardés avec toutes leurs propriétés. C’est le cas d’usage le plus solide du produit. La stratégie des méthodes d’authentification est couverte pour huit méthodes (passkeys FIDO2, Authenticator, TAP, SMS, appel vocal, OTP par e-mail, OATH logiciel tiers, authentification par certificat).

Utilisateurs, groupes, applications et principaux de service sont couverts aussi, mais sur une liste fermée de propriétés. Côté utilisateurs, par exemple : AccountEnabled, UserPrincipalName, Department, PerUserMfaState, UsageLocation, et une trentaine d’autres. Restaurer un principal de service restaure aussi ses attributions de rôles d’application et les consentements donnés par un admin pour toute l’organisation.

Pas couvert (vérifié dans la liste officielle)

La page objets et propriétés supportés est la seule qui compte. En la lisant attentivement, tu remarques ces absences :

• le manager et le sponsor d’un utilisateur ;
• les propriétaires de groupes et les règles des groupes dynamiques ;
• les consentements donnés par un utilisateur (seuls les consentements admin pour toute l’organisation sont couverts) ;
• les secrets et certificats d’application : passwordCredentials et keyCredentials ne figurent pas dans les propriétés restaurables ;
• les attributions de rôles Entra : elles n’apparaissent dans aucune catégorie d’objets supportés ;
• les objets supprimés définitivement (hard delete) : rien ne les recrée ;
• les modifications sur les objets synchronisés depuis l’AD local : elles apparaissent dans le rapport de différences, mais sont exclues de la restauration (sauf les appartenances aux groupes).

Les deux points sur les secrets et les rôles changent la lecture du produit. Prends un attaquant qui obtient un accès admin, ajoute un secret sur une app registration bien dotée en permissions et s’attribue un rôle privilégié. Une restauration ne retire ni l’un ni l’autre. Entra Backup and Recovery est un outil contre les erreurs de configuration et les modifications malveillantes de stratégies. Ce n’est pas un outil de remédiation d’incident. Pour ça, il te faut toujours ta procédure de réponse à incident, avec révocation des credentials et revue des rôles.

La bonne méthode de restauration

Microsoft le recommande, et c’est du bon sens : lance toujours un rapport de différences avant de restaurer. Tu vois exactement quels attributs et liens ont changé entre la sauvegarde et l’état actuel. Ça a un bénéfice pratique en plus : le premier accès à une sauvegarde déclenche un chargement des données qui prend un temps fixe, même sur un petit tenant. Le rapport de différences fait ce chargement à l’avance, et la restauration qui suit est plus rapide.

Restreins ensuite le périmètre. Si une seule stratégie d’accès conditionnel a sauté, restaure cet ID-là, pas tout le type d’objet. Une restauration large peut écraser des changements légitimes faits depuis la sauvegarde.

En environnement hybride, rappelle-toi que les objets dont la source d’autorité est l’AD local ne seront pas restaurés côté cloud. Si ta synchronisation tourne encore avec Entra Connect, l’échéance du 30 septembre sur Entra Connect Sync mérite d’être vérifiée au passage.

Sept jours ne suffisent pas : garde ta propre copie

Une modification discrète découverte dix jours plus tard est hors de portée du service. C’est pour ça que Microsoft renvoie lui-même vers ses bonnes pratiques de récupération, qui recommandent de documenter régulièrement l’état de référence via Microsoft Graph.

Pour les objets les plus sensibles, un export quotidien en JSON suffit. Voici une base avec le SDK Microsoft Graph PowerShell :

Connect-MgGraph -Scopes "Policy.Read.All"

$stamp = Get-Date -Format "yyyyMMdd"
$dir   = ".\entra-export\$stamp"
New-Item -ItemType Directory -Path $dir -Force | Out-Null

Get-MgIdentityConditionalAccessPolicy -All |
    ConvertTo-Json -Depth 10 |
    Out-File "$dir\conditional-access.json" -Encoding utf8

Get-MgIdentityConditionalAccessNamedLocation -All |
    ConvertTo-Json -Depth 10 |
    Out-File "$dir\named-locations.json" -Encoding utf8

Get-MgPolicyAuthenticationMethodPolicy |
    ConvertTo-Json -Depth 10 |
    Out-File "$dir\auth-methods-policy.json" -Encoding utf8

En production, fais tourner ce script en mode application (certificat ou identité managée dans Azure Automation, plutôt qu’une connexion interactive), et pousse les fichiers dans un dépôt Git ou un compte de stockage avec immuabilité. Un git diff entre deux jours devient alors ton propre rapport de différences, sans limite de rétention.

FAQ

Est-ce que ça demande une licence en plus ?

Non. Entra ID P1 ou P2 suffit, et le service est actif d’office sur les tenants éligibles.

Ça remplace Microsoft 365 Backup ?

Non, ce ne sont pas les mêmes données. Entra Backup and Recovery protège l’annuaire, Microsoft 365 Backup protège les boîtes mail, SharePoint et OneDrive. J’ai détaillé ce que couvre Microsoft 365 Backup dans un article précédent.

Et mon Active Directory local ?

Il reste à ta charge, avec ta solution de sauvegarde habituelle. Le service Entra ne touche pas à AD DS.

Un utilisateur supprimé il y a 15 jours, je le récupère comment ?

Par la corbeille Entra : les utilisateurs, groupes Microsoft 365, groupes de sécurité cloud, app registrations et principaux de service supprimés en soft delete restent restaurables 30 jours. Backup and Recovery vient en complément, pas à la place.

À faire cette semaine

Ouvre le menu Backup and recovery de ton tenant et lance un rapport de différences sur la sauvegarde d’hier, juste pour voir le délai et le rendu. Attribue le rôle Backup Administrator à deux personnes nommément, plutôt que de compter sur les Global Admins. Et mets en place l’export Graph quotidien : c’est lui qui te sauvera le jour où le problème aura plus d’une semaine. Une sauvegarde de l’annuaire s’inscrit dans la même logique que la règle 3-2-1-1-0 : une copie ne suffit jamais.