Microsoft 365 n'est pas une sauvegarde : quelles données faut-il protéger ?

La confusion entre disponibilité et récupérabilité est l'une des erreurs les plus coûteuses pour les entreprises. Microsoft 365 est une plateforme de productivité cloud, pas un service de backup. Pour les consultants IT, il est crucial de démontrer à leurs clients que la suppression d'un fichier par un utilisateur malveillant, une erreur humaine ou une corruption de base de données ne peut pas être rattrapée indéfiniment par le fournisseur, et que des données critiques restent vulnérables sans une stratégie de reprise sur incident (RI) structurée.

En bref

• Microsoft 365 est un service SaaS : il garantit la disponibilité de la plateforme, mais pas l'intégrité historique des données contre la suppression intentionnelle ou accidentelle.
• Les délais de rétention sont courts : la corbeille et les sites de récupération expirent généralement après 30 jours, ce qui est insuffisant pour une conformité légale ou une cybersécurité avancée.
• Les données collaboratives sont les plus exposées : SharePoint et OneDrive contiennent des actifs stratégiques souvent ignorés dans les politiques de sauvegarde traditionnelles.
• La sauvegarde 3-2-1 doit être adaptée au cloud : il est impératif de créer une copie hors du périmètre de contrôle de Microsoft (ou du tenant client) pour résister aux ransomwares qui se propagent via les identités.
• L'audit est la première étape : avant de sauvegarder, il faut cartographier ce qui est "critique" pour l'activité afin d'optimiser les coûts de stockage.

Comprendre la limite de la "récupération native"

Beaucoup d'administrateurs IT s'appuient sur les fonctionnalités natives de récupération de Microsoft 365 (Exchange Online, SharePoint, OneDrive) en pensant qu'elles équivalent à une sauvegarde. C'est une erreur conceptuelle majeure.

La différence entre disponibilité et récupérabilité

Microsoft garantit une disponibilité de 99,9 % pour ses services. Cela signifie que si le datacenter de Microsoft tombe en panne, vos données seront restaurées. Cependant, si un utilisateur supprime sa boîte mail, ou si un administrateur supprime un site SharePoint par erreur, Microsoft considère cette action comme valide.

Les mécanismes de récupération natifs sont :

1. La Corbeille (Deleted Items) : Visible par l'utilisateur, conservée pendant 30 jours.
2. La Corbeille de l'administrateur (Recoverable Items) : Accédée via PowerShell ou le Centre d'administration. Elle retient les éléments supprimés de la corbeille utilisateur.
3. Les sites de récupération (SharePoint/OneDrive) : Pour les fichiers supprimés définitivement.

Le problème fondamental : Ces mécanismes sont partagés avec l'attaquant. Dans le cas d'un ransomware qui prend le contrôle d'un compte administrateur, l'attaquant peut supprimer les données et vider les corbeilles natives. Vous perdez alors tout, sans aucune copie de secours externe. De plus, les délais d'expiration (souvent 30 jours) sont trop courts pour détecter des attaques persistantes (APT) ou pour répondre aux exigences légales de conservation (qui peuvent exiger 5 à 10 ans).

Ce que Microsoft ne sauvegarde pas

Il est essentiel de distinguer les données stockées par Microsoft des données gérées par votre entreprise.

• Sauvegardé nativement (mais avec limites) : Boîtes mail, fichiers SharePoint/OneDrive, listes, sites.
• Non sauvegardé ou non accessible en cas de suppression totale :
  • Les bases de données Exchange (bien que les éléments soient récupérables, la structure globale et les métadonnées complexes ne sont pas "snapshotées" de manière simple).
  • Les configurations d'application (PowerApps, Flow/Power Automate) : si vous supprimez une app, elle est perdue. Les sauvegardes natives ne capturent pas toujours l'état complet des workflows complexes.
  • Les données locales : Si vous utilisez des clients locaux (Outlook desktop avec .pst/.ost, ou des apps Windows qui écrivent dans %APPDATA%), ces fichiers ne sont pas couverts par la sauvegarde cloud.

Cartographier les données critiques : la matrice de valeur

Avant de lancer un outil de backup, un consultant doit mener un audit de la valeur des données. Sauvegarder 100 % de Microsoft 365 est souvent prohibitif et inutile.

Les 4 catégories de données à protéger

1. Données de Production (Critique) :

   • Exemples : Boîtes mail des dirigeants, sites SharePoint de l'équipe commerciale (devis, contrats), fichiers financiers (Excel), bases de connaissances techniques.
   • Stratégie : Sauvegarde quotidienne, rétention longue (1 an min.), restauration item-level (fichier par fichier).

2. Données de Collaboration (Haute valeur) :

   • Exemples : Sites d'équipe, listes de tâches, documents co-édités.
   • Stratégie : Sauvegarde quotidienne, rétention moyenne (3-6 mois).

3. Données de Support / Archive (Moyenne valeur) :

   • Exemples : Boîtes mail de services partagés (support@, info@), anciens projets.
   • Stratégie : Sauvegarde hebdomadaire, rétention conforme aux obligations légales.

4. Données Transitoires (Basse valeur) :

   • Exemples : Boîtes mail de test, sites de développement, fichiers temporaires.
   • Stratégie : Exclusion de la sauvegarde pour réduire les coûts et la complexité.

L'impact du "Shadow IT"

Les consultants doivent interroger les équipes métier : "Où stockez-vous vos données critiques ?". Souvent, les utilisateurs contournent SharePoint en utilisant des comptes OneDrive personnels ou des applications tierces (Zoom, Slack, Jira) dont les données ne sont pas couvertes par la politique de sauvegarde M365. Il faut inclure ces sources dans la scope de la sauvegarde ou imposer des politiques de stockage centralisé.

Stratégie technique : Implémenter une sauvegarde robuste

La règle d'or reste la règle 3-2-1 :

• 3 copies de vos données (production + 2 copies de sauvegarde).
• 2 supports de stockage différents (ex: cloud Microsoft + cloud de sauvegarde tiers, ou cloud + local chiffré).
• 1 copie hors site (ou hors tenant).

Pour Microsoft 365, la "copie hors site" implique souvent un service de sauvegarde cloud tiers (comme Veeam, Rubrik, Druva, etc.) qui se connecte à votre tenant via API Microsoft Graph.

Architecture recommandée

1. Source : Tenant Microsoft 365 (Exchange, SharePoint, OneDrive).
2. Agent/API : L'outil de sauvegarde utilise des jetons OAuth pour lire les données. Il est crucial de configurer un compte de service dédié avec les moindres privilèges nécessaires (lecture seule sur les sites cibles), et non un compte Global Admin.
3. Stockage de Sauvegarde :
   • Option A (Cloud-to-Cloud) : Les données sont chiffrées et stockées dans un bucket S3/Azure Blob Storage appartenant à l'outil de sauvegarde ou à l'entreprise. C'est la méthode la plus résiliente contre les ransomwares, car l'attaquant n'a pas accès aux clés de chiffrement ni au stockage de backup.
   • Option B (Hybride) : Pour les très grandes entreprises, certaines données critiques peuvent être répliquées vers un stockage local (NAS/On-Prem) pour une restauration ultra-rapide, puis archivées dans le cloud.

Exemple de configuration PowerShell pour l'audit initial

Avant de configurer le backup, utilisez PowerShell pour identifier les volumes de données et les sites les plus actifs.

# Connecter à Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@entreprise.com

# Lister les boîtes mail avec leur taille et le nombre d'items
Get-Mailbox -ResultSize Unlimited | Select-Object Name, Database, TotalItemSize, TotalItemCount | 
    Where-Object {$_.TotalItemSize -gt 1GB} | 
    Sort-Object TotalItemSize -Descending

# Connecter à SharePoint (nécessite l'activation de l'API)
Connect-SPOService -Url "https://entreprise-admin.sharepoint.com"

# Lister tous les sites et leur taille approximative (via API REST ou module PnP)
# Note : L'API native PowerShell ne donne pas toujours la taille exacte, 
# il est souvent préférable d'utiliser l'API Microsoft Graph via l'outil de backup.
Get-Site | Select-Object Url, Owner, Title

Note : Pour les tailles exactes de fichiers SharePoint/OneDrive, les outils de sauvegarde tiers utilisent l'API Graph qui permet un scan plus précis. Ne vous fiez pas uniquement aux métadonnées Exchange Online pour estimer le coût de backup.

Bonnes pratiques pour consultants IT

1. Isolation des identités (Identity Separation)

Le plus grand risque dans le cloud est le "compromis d'identité". Si un hacker vole les credentials d'un administrateur, il peut supprimer les données et les sauvegardes.

• Action : Utilisez un compte de service dédié pour l'API de sauvegarde. Ce compte doit avoir des permissions de lecture seules sur les sites cibles. Il ne doit pas avoir de droits d'écriture ni de droits d'administration.
• Action : Activez l'authentification multifacteur (MFA) obligatoire pour ce compte de service, ou utilisez des certificats client pour éviter les mots de passe.

2. Chiffrement au repos et en transit

• Action : Vérifiez que l'outil de sauvegarde chiffre les données avant qu'elles ne quittent le tenant Microsoft. Le chiffrement doit être géré par l'entreprise (BYOK - Bring Your Own Key) si possible, ou par l'outil de sauvegarde avec des clés que vous contrôlez.
• Action : Assurez-vous que le stockage de sauvegarde est chiffré (AES-256) et que les clés de chiffrement sont stockées séparément des données.

3. Tests de restauration (Restore Testing)

Une sauvegarde non testée n'est pas une sauvegarde.

• Action : Effectuez un test de restauration mensuel.
  • Test Level 1 : Restaurer un fichier spécifique dans un site de test.
  • Test Level 2 : Restaurer une boîte mail complète dans un environnement isolé (sandbox) et vérifier l'ouverture des emails et des pièces jointes.
  • Test Level 3 : Simuler une attaque ransomware. Supprimez des données dans la production, puis restaurez-les depuis la sauvegarde. Mesurez le RTO (Recovery Time Objective).

4. Rétention et Conformité

• Action : Alignez les périodes de rétention de la sauvegarde avec vos obligations légales et contractuelles. Par exemple, si la loi exige 5 ans de conservation des factures, votre sauvegarde des fichiers SharePoint correspondants doit durer au moins 5 ans.
• Action : Mettez en place des "legal holds" (retenues légales) dans Microsoft 365 pour les dossiers sensibles, mais sachez que cela ne protège pas contre la suppression physique du tenant. La sauvegarde externe est la seule garantie.

5. Documentation du processus de reprise

• Action : Rédigez une procédure de crise (Runbook) claire :
  1. Comment isoler les comptes compromis ?
  2. Comment identifier la date de la dernière sauvegarde saine ?
  3. Comment restaurer les données dans un nouvel environnement ou dans le tenant existant ?
  4. Comment valider l'intégrité des données restaurées ?

Points clés

1. Microsoft 365 ≠ Backup : La récupération native est un filet de sécurité pour les erreurs immédiates, pas une stratégie de reprise sur incident.
2. Les données collaboratives sont la cible n°1 : SharePoint et OneDrive contiennent des actifs stratégiques qui doivent être sauvegardés avec la même rigueur que les bases de données traditionnelles.
3. La séparation des identités est cruciale : Un compte de service dédié avec des moindres privilèges est la première ligne de défense contre la suppression malveillante des sauvegardes.
4. Le chiffrement et le stockage hors tenant sont obligatoires : Pour résister aux ransomwares qui ciblent les identités cloud, vos copies de sauvegarde doivent être inaccessibles à l'attaquant (chiffrement + stockage séparé).
5. Testez, testez, testez : Un plan de sauvegarde sans test de restauration régulier est une illusion de sécurité. Mesurez votre RTO/RPO et ajustez votre infrastructure en conséquence.

En tant que consultant, votre valeur ajoutée ne réside pas seulement dans la configuration de l'outil, mais dans la définition de la politique de protection des données. Sans cette vision stratégique, la sauvegarde technique, aussi sophistiquée soit-elle, restera un coût inutile face à un incident majeur.

Source : IT Espresso