Archivage légal, sauvegarde, back up… Le sujet de la copie des données Office 365 en dehors de la plateforme revient régulièrement.

Si la problématique était soumise à 100 personnes, vous obtiendriez 100 réponses diverses balayant tout le spectre de « Mais quelle idée ? » à « Mais comment s’en passer ? ».

Quelle est la position de Microsoft ?

Au travers de sa suite collaborative, Microsoft propose nativement un certain nombre de fonctionnalités pour gérer le cycle de vie de la donnée et garantir la conservation de celle-ci. Ce dernier sujet est d’ailleurs un des fers de lance de Microsoft ces dernières années, avec les développements autour de la Gouvernance des Informations (ou Information Governance en anglais).

A ma connaissance, il n’y a pas de position officielle recommandant ou non de conserver une copie des données en dehors de la plateforme. Plusieurs partenaires de Microsoft proposent des solutions de sauvegarde ou d’archivage, voire les deux ; mais les récentes discussions que j’ai pu avoir avec des collaborateurs Microsoft se résumaient en « dans la majorité des cas, les besoins peuvent être couverts avec les fonctionnalités internes et recourir à une solution tierce n’est pas nécessaire ».

Les seuls éléments dont on peut être sûrs sont ceux inscrits dans les SLA et les Conditions d’utilisation des services :

Dans les Conditions des services en ligne (PTS ou Product Terms Site en anglais, ex-OST, incluant notamment l’Enterprise Agreement) des services professionnels, Microsoft ne se positionne pas.
Dans les Conditions de services (ou Service Agreement) des services personnels : Microsoft « recommande de sauvegarder régulièrement Votre Contenu et les Données que vous stockez en utilisant des Applications et Services Tier ».

Pourquoi cette question revient régulièrement ?

C’est ce qui se faisait on-premise pour garantir la disponibilité des données, par exemples sur des serveurs de fichiers
Besoin réglementaire de conserver les données à des fins d’enquêtes (ex : EBA, FINRA)
FUD (Fear, Uncertainety, Doubt) en anglais principal levier des vendeurs, afin de gagner des parts de marchés et de conserver celles acquises

Présenté par les éditeurs comme la solution miracle qui permettrait de récupérer les données d’un VIP qui aurait supprimé un mail sans faire exprès, de retrouver le contrat qui a été chiffré par un ransomware, etc.

Comment répondre à cette problématique ?

Afin de vous positionner, trois questions très basiques méritent une réponse :

Quels sont mes besoins métiers et réglementaires ?
Est-ce que les solutions natives d’Office 365 répondent à ces besoins ?
Est-ce que le risque résiduel est acceptable ou dois-je chercher une solution tierce ?

La conclusion finale sera un équilibre savant entre capacité à identifier son besoin, appétence au risque (risk appetite en anglais) et budget.

Par expérience, le plus compliqué restera de définir son besoin.

Question 1 : quels sont mes besoins métiers et réglementaires ?

Bien que les probabilités ou impacts soient différents selon l’entreprise ou la donnée concernée, les risques touchant Office 365 sont bien souvent les mêmes : avoir la capacité de conserver un accès à la donnée et maintenir le service dans le temps (identités et configuration).

En bref, il s’agit de prendre sa part dans le modèle de responsabilité partagée du SaaS (Microsoft met à disposition une infrastructure et un service sécurisée, son client est responsable des données, configurations et des identités).

Les principaux besoins de conservation des données peuvent être regroupés comme ci-dessous :

Restauration d’un élément à la suite d’une corruption unitaire
Restauration d’un élément à la suite d’une modification
Restauration d’un élément à la suite d’une suppression
Restauration d’un grand nombre de fichiers à la suite de suppressions ou d’un ransomware
Restauration d’un site ou d’une librairie à la suite d’une suppression
Conservation des données pour répondre à la conformité
Conservation des données pour répondre aux exigences réglementaires ou légales
Plan de secours en cas de perte du service
Réversibilité en cas de sortie du service (ou de séparation d’une entité)

La distinction majeure entre deux secteurs concernera généralement les durées de conservation liées aux exigences réglementaires, légales, contentieux, etc. En fonction du pays ou du secteur, il pourra être requis de conserver les échanges (mails, messagerie instantanée, voix et vidéo) ou certains fichiers pour une durée de 3, 5, 7 ou 10 ans afin de répondre à une enquête ou de résoudre un contentieux.

Dans la suite de cet article, j’écarte volontairement les deux derniers besoins ; ceux-ci étant couverts nativement par les SLA et le contrat avec Microsoft. Toutefois, si le risque résiduel reste trop important, une étude conséquente devra être réalisée.

Question 2 : Est-ce que les solutions natives d’Office 365 répondent aux besoins identifiés ?

Comme on peut s’y attendre, les fonctionnalités sont inégales selon les services :

Transverse – Infrastructures : la réplication, une fonctionnalité du SaaS

La réplication des données mise en place par Microsoft permet de limiter les altérations liées aux incidents touchant les infrastructures du service Cloud. En revanche, cela ne limite pas la corruption ou la suppression d’un fichier par un utilisateur habilité.

Transverse – Administration : aucune possibilité de retour en arrière !

A date, il est compliqué de suivre les évolutions de configuration de la plateforme, en dehors des audit logs. Il n’y a pas non plus de possibilité de revenir en arrière en cas de modification

La plupart des configurations restent cependant exportables manuellement via PowerShell (ex : paramétrages SharePoint Online ou Teams, règles Exchange Online, Politique de données Power Platform) ou les API Graph (ex : politiques d’accès conditionnel).

Azure Active Directory : un premier niveau de corbeille, mais bien insuffisant au regard des enjeux

Azure Active Directory est la colonne vertébrale d’un tenant Microsoft 365. Une modification d’un objet ou d’une configuration y est extrêmement sensible car elle pourrait impacter l’ensemble des autres services (ex : la modification d’un attribut utilisateur pourrait le retirer d’une politique d’accès conditionnel).

Azure AD vient avec un niveau de corbeille pour les utilisateurs et les groupes :

Un utilisateur (ou un groupé) supprimé (soft delete en anglais) est déplacé dans la corbeille de premier niveau. Au bout de 30 jours, l’élément est définitivement purgé (hard delete).
Un administrateur a la possibilité de restaurer un élément supprimé avec toutes ces propriétés (ex : licences, groupes, attributs).

En revanche, les autres objets sont directement supprimés, notamment les terminaux, les service principals ou les facteurs MFA. (EDIT : la restauration des service principals est en préversion)

A noter également, Microsoft ne proposant pas de versionning, toute modification d’une identité ou d’une configuration est irréversible.

SharePoint Online et OneDrive for Business :

Versionning : un système de versioning permettant de suivre les modifications et de pouvoir revenir en arrière.

Les versions SharePoint sont des éléments indépendants, et ne sont pas incrémentales. Un grand nombre de versions pourrait impacter les capacités de stockage.
Toute personne avec les droits de « Contrôle total, conception et contribution » peut supprimer ou modifier une version d’un élément.
Une version supprimée manuellement est déplacée dans la corbeille de niveau 1 ; tandis qu’une version supprimée automatiquement est purgée définitivement sans passer par les différents niveaux de corbeille.
On pourrait imaginer une attaque de type ransomware qui pourrait chiffrer “n +1” fois un document (“n” étant le nombre de version conservée).

Deux niveaux de corbeille : Lorsqu’un élément est supprimé, il est envoyé dans la corbeille du site (niveau 1) où il y reste 93 jours avant d’être supprimé définitivement. Si un élément est supprimé de la corbeille du site, il part dans la corbeille de la collection de site (niveau 2) où il va y rester le restant des 93 jours.

Cette durée de 93 jours n’est pas modifiable.
Un utilisateur avec des droits d’édition peut restaurer ou purger un élément de la corbeille de niveau 1.
Un propriétaire de la collection de site peut restaurer ou purger un élément de la corbeille de niveau 2 avant la fin des 93 jours.

Restauration d’une librairie : Un propriétaire de site peut décider d’annuler toutes les modifications faites dans les 30 jours sur une librairie (granularité fine).

La restauration se fait à partir des versions et des éléments encore présents dans la corbeille du site.
Les éléments liés aux modifications annulées sont placés dans la corbeille de niveau 1.

Restauration d’un site SharePoint supprimé : Un site SharePoint supprimé par un propriétaire est conservé (soft delete) pendant 93 jours dans la corbeille du tenant (niveau 3) au bout desquels il est définitivement supprimé (hard delete).

Un administrateur SharePoint peut restaurer un site supprimé depuis le Centre d’administration SharePoint.
A noter, un Groupe Microsoft 365 et les autres ressources liées à un site SharePoint sont supprimés définitivement après 30 jours.
Un administrateur SharePoint est en mesure de supprimer définitivement (hard delete) une collection de site supprimée avant la fin des 30 jours avec la commande PowerShell Remove-SPODeletedSite

Restauration d’une collection de site par Microsoft : En complément de la restauration d’un document ou d’un site, Microsoft fait des sauvegardes toutes les 12h des collections de sites SharePoint et les conserve pendant 14 jours. Un administrateur du tenant demander au support Microsoft de restaurer une collection de site dans son intégralité.

Politique de rétention : Au-delà des mécanismes précédents, les fonctionnalités incluse dans la Gouvernance des informations peuvent être détournées pour garantir la non suppression des données. En pratique :

Une politique de rétention forcera la conservation de tout document supprimé par un utilisateur ou un administrateur pendant la durée définie.
Une étiquette de rétention empêchera la suppression d’un document.
Les mécanismes de rétention risquent de faire exploser les quotas de stockage SharePoint (ex : conservation de toutes les versions, copies des éléments supprimés).
Même un administrateur de la collection de site, un administrateur SharePoint ou un Global Admin ne sera pas en mesure de supprimer les données (sans modifier la durée des politiques de rétention).
L’activation du verrou sur les politiques de rétention ou l’utilisation d’étiquettes d’enregistrements (ou Records en anglais) permettront de plus de garantir l’immutabilité des données et la conformité avec des exigences de références (SEC 17 a-4f ou FINRA pour ne citer qu’elles).
Un administrateur de la collection de site sera en mesure de restaurer des éléments de la bibliothèque de conservation (Preservation Hold Library en anglais). En revanche, cette restauration sera unitaire et manquera de finesse dès lors que l’on traite un volume important.

Exchange Online :

Deux niveaux de corbeille : Lorsqu’un élément Exchange (courrier, tache, réunion, etc.) est supprimé, il est envoyé dans le dossier « Eléments supprimés » (corbeille de niveau 1), où il y reste jusqu’à être supprimé (manuellement ou automatiquement via des règles Outlook ou MRM – cf. ci-dessous). Si un élément est supprimé des « Eléments Supprimés », il part dans les dossiers cachés des « Eléments Récupérables » (corbeille niveau 2). Il est définitivement supprimé après 14 jours.

La durée de 14 jours est modifiable par utilisateur entre 0 et 30 jours.
Un utilisateur peut restaurer un élément de la corbeille de niveau 2 ou le purger. Dans ce cas, il est déplacé dans un autre dossier caché, mais ne sera supprimé qu’à la fin de la durée ci-dessus.
Un administrateur Exchange peut restaurer un élément de la corbeille de niveau 2, mais ne pourra pas le supprimer avant la durée ci-dessus. Je reviendrai plus en détails sur les mécanismes de suppression d’Exchange dans un autre article.

Exchange Online Archiving : La fonctionnalité d’archivage en ligne, malheureusement méconnue, offre la possibilité à un utilisateur d’avoir un espace supplémentaire dans sa boîte aux lettres. Elle doit être activée par utilisateur.

Une licence E1 offre 50 Go, tandis qu’une licence E3 / E5 offre 100 Go de stockage extensible indéfiniment.
L’archivage en ligne permet également de justifier l’arrêt des fichiers .pst.

Gestion des enregistrements de messagerie (ou Messaging Records Management – MRM) : souvent appelées à tort « politique de rétention », les politiques de MRM visent à préciser le cycle de vie des courriers électroniques : via des stratégie ou des balises.

Les stratégies de MRM ne répondent pas aux besoins de conservations à des fin de conformité ou réglementaires
L’usage principal recommandé aujourd’hui est de déplacer les éléments dans la boîte mail d’archivage ou de nettoyer des dossiers comme la corbeille.

Une politique de rétention forcera la conservation de tout élément supprimé par un utilisateur ou un administrateur pendant la durée définie.
Les éléments concernés sont conservés dans un sous-dossier « Eléments Récupérables » (ou Recoverable Items en anglais). Ce dossier bénéficie d’un espace de stockage qui lui est propre de 100 Go supplémentaires.
Même un administrateur Exchange ou un Global Admin ne sera pas en mesure de supprimer les données (sans modifier la durée des politiques de rétention).
L’activation du verrou sur les politiques de rétention permettra de plus de garantir l’immutabilité des données et la conformité avec des exigences de références (SEC 17 a-4f ou FINRA pour ne citer qu’elles).
Il est recommandé aujourd’hui d’utiliser les politiques de rétention plutôt que les fonctionnalités historiques (Litigation Hold ou eDiscovery In-Place Hold).
Un administrateur Exchange sera en mesure de restaurer des éléments unitaires du dossier « Eléments Récupérables ».

Microsoft Teams :

Si un utilisateur supprime un de ses messages dans une conversation, un canal ou une réunion, il sera définitivement supprimé. Seul l’utilisateur a la possibilité d’annuler l’action, mais dans un très court laps de temps (environ 2 heures d’après mes tests). A noter, qu’il est possible de mettre en place des politiques de rétention pour garantir la conservation des messages. Mais dans un but de conformité ou réglementaire uniquement.

De même, si un utilisateur modifie un de ses messages, il ne pourra pas revenir en arrière.

Il reste important de préciser que la suppression d’un message dans lequel est partagé un document, ne supprime que le message et non le document ou le lien de partage associé.

Côté espace Teams, il est opportun de rappeler qu’un Team supprimé peut être restauré dans les 21 jours. De même un canal pourra être récupéré dans les 21 jours.

Planner :

A l’heure actuelle, il n’existe ni mécanisme de corbeille ou ni versioning des plans ou des tâches.

Power Apps :

Chaque modification d’une application PowerApps entraine la création d’une version qui peut être restaurée.

Il n’y a pas en revanche de corbeille dans la plateforme. La seule chose qui peut être faite, pour conserver une copie, est de d’exporter l’application en fichier .zip. Ce mécanisme peut être automatisé via un Power Automate (un exemple intéressant ici).

En parallèle, il est possible de créer manuellement une sauvegarde d’un environnement avec tous les éléments qui sont d’un environnement. Cette fonctionnalité n’est pas disponible pour l’environnement par défaut. Il est nécessaire d’avoir de l’espace disponible (ou un CDS activé), et donc pour cela des licences premium.

Power Automate :

A l’heure actuelle, il n’existe pas de mécanisme de corbeille ou de versioning des flux. La seule chose qu’il soit possible de faire est d’exporter un JSON avec les connexions et les détails du flux.

Dans cet article, Mohamed Ashiq Faleel (un MVP Power Platform) présente une automatisation intéressante des exports d’un Power Automate… via un autre Power Automate.

Question 3 : Est-ce que le risque résiduel est acceptable ou dois-je chercher une solution tierce ?

La réponse est entre vos mains en fonction de votre appétence au risque et des moyens à disposition !

Voici cependant quelques éléments pour affiner la réflexion :

Coût : La licence par utilisateur pour les solutions de sauvegarde externe est de l’ordre de 1-2 euros par mois en prix public, selon les service choisis. En sus, il faut également ajouter le coût du stockage associé (généralement dans le Cloud). S’il est retenu de sauvegarder l’intégralité de la plateforme, l’addition peut devenir très salée. Quand on fait le calcul de l’espace de sauvegarde nécessaire, cela chiffre en effet très vite :

\[\begin{aligned} (1\textrm{ To} \cdot \textrm{ n utilisateurs})_\textrm{OneDrive} \\ + (1\textrm{ To} + 10\textrm{ Go} \cdot \textrm{ n utilisateurs})_\textrm{SharePoint} \\ + ( (100\textrm{ Go boite mail principale} + 100\textrm{ Go Elements récupérables}) \cdot \textrm{ n utilisateurs})_\textrm{Exchange} \end{aligned}\]

Et encore, on ne compte pas ci-dessus la boîte mail d’archivage dans Exchange Online et le stockage Stream (500 Go + 0,5 Go par utilisateur sous licence), etc. Une question à adresser également est : faut-il conserver toutes les versions pour la sauvegarde au risque d’exploser le volume de stockage ? ou seulement les 100 dernières ? (mais dans ce cas quel intérêt par rapport à SharePoint)

Sécurité : Par définition, la sauvegarde des données en dehors d’Office 365 implique de sortir du modèle de responsabilité partagée. Là où la sécurité des infrastructures d’Office 365 était gérée par Microsoft, vous confiez vos données à un autre acteur (dont les engagements de sécurité seront a priori moins élevés) ou pire vous devez vous-même gérer la sécurité de votre stockage IaaS / PaaS.

Disponibilité : Si Microsoft tombe, est-ce que les données sauvegardées sont disponibles ou sont-elles hébergées sur Azure ? Et même si les données sont disponibles, où allez vos restaurer vos Po de données et par quels tuyaux réseau ?

Services : Les différentes solutions de sauvegarde du marché promettent monts et merveilles. Pour la conservation des données SharePoint Online et Exchange Online, les solutions semblent matures. Mais lorsque l’on y regarde de plus près, le tableau n’est pas aussi rose pour les autres périmètres :

Teams : tous les éléments n’étaient pas récupérables il y a peu (mais les nouvelles API mises à disposition devraient désormais permettre de capturer l’ensemble des signaux). Les solutions ne proposent pas non plus de restauration parfaite (par exemple : une conservation dans un canal Teams revient sous la forme d’une page HTML).
Power Platform : je n’ai rien vu de particulier.
Azure AD : quelques éditeurs ont commencé à se positionner sur le marché.
Configuration des services : à part faire des exports via PowerShell ou Microsoft 365 DSC, le champ des possibles semble plutôt restreint.

Mon avis

Il est nécessaire de différencier les données et le maintien dans le temps du service.

Les licences Office 365 apporte nativement des mécanismes visant à proposer un premier niveau de restauration aux utilisateurs et à garantir la conservation des données à des fins de conformité ou légales. Pour la majorité des entreprises, cela devrait être suffisant.

Dans certains contextes de risques et seulement avec une maturité avancée, il pourrait cependant être opportun de réaliser des copies des données via des outils tiers pour répondre à des usages très spécifiques (ex : exigences réglementaires, utilisation d’une solution de conformité existant, nécessité de restaurer des données à une échelle très fine…).

Attention toutefois à ne pas créer de nouveaux risques ou conséquences inutiles : économiques, architecture, sécurité ou exposition des données, fausses promesses aux métiers…

En ce qui concerne le maintien de la plateforme (identités et configuration), une bonne gouvernance autour de l’administration, du durcissement sont indispensables et traitent une partie du risque. Il serait toutefois utile d’envisager la conservation des éléments les plus critiques (via des exports manuels ou des solutions dédiées).

Ce sujet bien qu’important, n’est, selon moi pas la priorité aujourd’hui pour la majorité des comptes. Il reste primordial de poser les bases techniques et organisationnelles de la sécurité et conformité (accès conditionnel, administration, partages, gestion des API, rétention) avant d’aller chercher des solutions supplémentaires.