Azure Backup : au-delà des fonctionnalités natives, vers une couverture complète

Le problème lié à Entra ID auquel personne ne s'attend

Un client m'a contacté l'année dernière au sujet d'un problème qu'il n'avait pas vu venir. Un membre de son équipe avait supprimé un enregistrement d'application Entra ID dont dépendaient 40 services internes. Ces services ont commencé à présenter des défaillances en l'espace de quelques minutes. Ils ont tenté de restaurer l'enregistrement de l'application à partir de la sauvegarde Azure. 

La sauvegarde Azure ne couvre pas Entra ID. Microsoft l’indique clairement dans sa documentation depuis des années. Le client ne l’avait pas lu. La plupart des équipes ne l’ont pas lu non plus. Lorsqu’ils ont enfin compris ce qu’ils avaient perdu, ils avaient déjà passé deux jours à reconstituer manuellement l’enregistrement de l’application à partir de fichiers de configuration dispersés entre différentes équipes. 

Cet appel a façonné ma vision de la protection sur Azure. Les services natifs fournis par Microsoft constituent des éléments de base utiles. Ils n’assurent pas une protection complète, et les lacunes se situent précisément là où la plupart des équipes supposent que la protection est assurée par défaut. 

Là où les services natifs d’Azure s’arrêtent

Microsoft propose plusieurs services de protection natifs, et ceux-ci remplissent bien leur rôle. Azure Backup gère les instantanés au niveau des machines virtuelles et la restauration au niveau des fichiers. Azure Site Recovery gère l’orchestration du basculement. Azure SQL propose des sauvegardes automatisées avec restauration à un instant donné. Azure Blob Storage propose des options de gestion des versions et d’immuabilité. Pour de nombreuses charges de travail, il s’agit là d’un bon point de départ.

Les lacunes apparaissent dans cinq domaines spécifiques qui revêtent une importance capitale lorsque vous avez réellement besoin d’une restauration.

La cohérence des applications dans le cadre de charges de travail complexes. Les instantanés natifs de machines virtuelles sont généralement cohérents en cas de panne. Pour une sauvegarde adaptée aux applications de charges de travail à plusieurs niveaux, de SAP HANA ou d’applications présentant des exigences de mise en veille personnalisées, vous avez besoin d’un cadre pré- et post-application garantissant que les systèmes de fichiers et les applications sont correctement mis en veille. Il ne suffit pas de créer un instantané quel que soit l’état dans lequel se trouve le noyau.

Couverture des services SaaS. La sauvegarde native d’Azure ne couvre pas Microsoft 365 ni Entra ID. Microsoft indique explicitement que la conservation et la restauration de ces objets au niveau du locataire relèvent de la responsabilité du client. Si vous perdez l’enregistrement d’une application Entra ID ou supprimez un site SharePoint, Microsoft appliquera l’action sans qu’il n’existe de voie de restauration de la part de Microsoft lui-même. 

Récupération inter-locataires et inter-abonnements. Les services natifs fonctionnent au sein d’un seul abonnement Azure. La récupération vers un autre abonnement, un autre locataire ou vers un environnement sur site s’avère plus complexe sur le plan opérationnel qu’elle ne devrait l’être, en particulier lors d’un incident où l’environnement source n’est plus fiable. 

Gestion des politiques à grande échelle. Lorsque des centaines de machines virtuelles s’étendent sur plusieurs groupes de ressources et abonnements, l’attribution manuelle des politiques de sauvegarde se transforme en une source de lacunes de couverture par attrition. Les charges de travail qui échappent à cette gestion sont celles qu’un attaquant ou un administrateur négligent finira par détruire.

Prévisibilité des coûts en dehors des scénarios prévus. Les frais de sortie, les transitions entre niveaux de conservation et les coûts cachés liés à l’exécution de services natifs entre différentes régions peuvent vous prendre au dépourvu au mauvais moment, c’est-à-dire le mois où vous avez justement besoin de restaurer des données importantes.

Aller au-delà des fonctionnalités natives ne signifie pas les abandonner. Cela signifie considérer les primitives natives comme une base et y ajouter une couverture, une cohérence et une évolutivité opérationnelle. 

Ce qu’une protection Azure complète doit couvrir

Que signifie réellement « spécialement conçu pour Azure » ?

Les fournisseurs adorent cette expression. Quatre critères concrets permettent de distinguer le discours marketing de l’architecture.

Instantanés natifs au niveau des machines virtuelles Azure. Le service de sauvegarde doit utiliser le mécanisme d’instantané natif d’Azure, et non des instantanés fournis par le fournisseur et superposés à celui-ci, afin que l’impact sur la production reste quasi nul.

Authentification via Microsoft Entra ID. L’authentification s’effectue via Entra ID et hérite du modèle RBAC existant. Une base de données utilisateurs distincte implique une infrastructure parallèle à synchroniser.

Distribution via Azure Marketplace et facturation Azure. L’abonnement passe par le Marketplace et est facturé au titre des engagements Azure existants. Il ne s’agit pas d’une relation distincte d’approvisionnement et de facturation.

Prise en charge des groupes de ressources pour la multi-location. Différentes équipes et unités opérationnelles évoluent dans des groupes de ressources distincts. Le service doit détecter et respecter automatiquement cette structure, en ne donnant à chaque équipe qu’une visibilité sur ses propres ressources. 

Ce qui distingue une sauvegarde de base d’une solution de niveau opérationnel

Le déploiement de la sauvegarde est la partie la plus simple. Les fonctionnalités qui déterminent si la protection fonctionne toujours au bout de deux ans, après l’ajout de dizaines de nouvelles machines virtuelles et au moins une restructuration organisationnelle, sont d’ordre opérationnel plutôt que fonctionnel. Quatre capacités spécifiques sont essentielles.

Un cadre de cohérence des applications sur mesure. Les instantanés standard des machines virtuelles Azure prennent en charge les applications courantes. Pour SAP HANA, les applications personnalisées ou les charges de travail à plusieurs niveaux, un cadre de préparation avant et après l’application vous permet de définir comment le système de fichiers ou l’application doit être préparé pour la sauvegarde. Sans cela, les sauvegardes existent, mais la restauration s’avère fragile.

Attribution automatique de politiques basée sur des balises. Définissez les politiques une seule fois, en fonction des SLA, puis appliquez-les automatiquement en fonction des balises attribuées lors du provisionnement. Une charge de travail balisée « production-tier-1 » bénéficie de la politique de niveau 1. Une charge de travail balisée « dev » bénéficie de la politique de développement. Les charges de travail non balisées se voient attribuer la politique de sécurité par défaut. Une couverture maximale pour une charge administrative minimale.

Restauration granulaire. La restauration doit vous permettre de choisir ce qu’il faut restaurer au niveau du fichier, du dossier, de la machine virtuelle, du disque virtuel ou de l’application complète, ainsi que l’emplacement de restauration : emplacement d’origine, machine virtuelle de remplacement, groupe de ressources différent, abonnement différent, région différente. La granularité est primordiale dans les scénarios de compromission où vous ne pouvez pas faire confiance à l’environnement d’origine.

Notifications via webhooks intégrées à votre pile opérationnelle existante. Les événements critiques liés à la sauvegarde sont transmis aux outils que votre équipe utilise déjà : Slack, Microsoft Teams, ServiceNow. Pas une console distincte que personne ne surveille. Les alertes en temps réel en cas de défaillance de la protection font toute la différence entre détecter un problème à un stade précoce et le découvrir lors de la restauration.

Azure Government et charges de travail réglementées

Les agences fédérales, les sous-traitants du secteur de la défense et les secteurs réglementés ont des exigences qui vont au-delà de la sauvegarde Azure standard. Trois fonctionnalités sont primordiales.

Prise en charge d’Azure Government Cloud. La protection doit fonctionner au sein d’Azure Government, et pas seulement sur Azure commercial. Pour les clients fédéraux américains, cela inclut la sauvegarde des données sur site vers Azure Government Blob Storage à des fins d’archivage ou de sauvegarde principale, à partir de centres de données centralisés, de sites périphériques, de sites distants et d’infrastructures mobiles. 

Protection contre les ransomwares basée sur la technologie WORM avec déduplication optimisée pour le cloud. Le stockage WORM empêche les ransomwares de chiffrer les copies de sauvegarde. Le défi en termes de coûts réside dans le fait que les appliances de déduplication traditionnelles nécessitent d’importantes ressources de calcul et de mémoire, ce qui est onéreux dans le cloud. Nous ne stockons que les blocs uniques dans le cloud, ce qui permet d’économiser des ressources réseau, de stockage et de calcul. La récupération ne nécessitant pas de réhydratation, les performances de restauration ne sont limitées que par la bande passante du réseau.

Certification FIPS 140 et souveraineté des données contrôlée par le client. HYCU a obtenu la certification FIPS 140-3 en 2025, répondant ainsi aux normes fédérales relatives aux modules cryptographiques. Associé à notre engagement architectural garantissant que les données des clients ne sortent jamais de leur contrôle, cet aspect revêt une importance capitale pour toute organisation soumise aux cadres réglementaires FedRAMP, ITAR, CMMC ou similaires. 

Questions fréquentes sur la sauvegarde Azure

Azure intègre-t-il déjà une fonctionnalité de sauvegarde, ou ai-je besoin d’une solution distincte ?

Azure intègre des services de protection natifs qui gèrent les instantanés de machines virtuelles, la restauration de fichiers et l’orchestration de la reprise après sinistre pour de nombreux scénarios. Ces services ne couvrent pas Microsoft 365, Entra ID ni de nombreuses exigences de cohérence des applications d’entreprise, et ils présentent des limites en matière de restauration inter-locataires et de gestion des politiques à grande échelle. La plupart des environnements d’entreprise nécessitent une approche en plusieurs couches : des primitives natives associées à une plateforme tierce pour une couverture complète. 

Comment la sauvegarde Azure gère-t-elle Microsoft 365 et Entra ID ?

Elle ne les gère pas. Le modèle de responsabilité partagée de Microsoft confie la conservation et la restauration des données Microsoft 365 et des objets Entra ID au client. La restauration granulaire des boîtes aux lettres Exchange, des sites SharePoint, du contenu OneDrive, des données Teams, ainsi que des enregistrements d’applications ou des utilisateurs Entra ID nécessite une plateforme tierce conçue pour ces charges de travail.

Puis-je utiliser Azure comme cible de reprise après sinistre sans payer pour une infrastructure fonctionnant en permanence ?

Oui. Avec le BaaS natif du cloud, les copies de sauvegarde sont stockées en permanence dans Azure Blob Storage à faible coût. La puissance de calcul et le stockage haute performance ne sont consommés que lorsqu’un scénario de reprise après sinistre est déclenché. La majeure partie de l’année, vous ne payez que pour le stockage. Les rares jours où un sinistre survient, vous ne payez que pour la puissance de calcul. Une fraction du coût d’une solution de secours entièrement provisionnée.

Quelle est la différence entre Azure Backup et une plateforme BaaS dédiée ?

Azure Backup est le service natif de Microsoft destiné à protéger les machines virtuelles Azure, Azure Files et les charges de travail SQL au sein d’Azure. Une plateforme BaaS dédiée vient s’ajouter à cela pour offrir une sauvegarde cohérente au niveau des applications pour l’ensemble des applications d’entreprise, une couverture SaaS (Microsoft 365, Entra ID), une gestion centralisée des politiques entre les abonnements et les locataires, l’intégration de webhooks et une reprise après sinistre inter-cloud. Les deux solutions sont complémentaires. 

Si vous ne deviez faire qu’une seule chose

Vérifiez dès aujourd’hui votre couverture Microsoft 365 et Entra ID. Dressez la liste de ce qui est sauvegardé, par quel outil, et de ce qui serait nécessaire pour restaurer un enregistrement d’application, un site SharePoint ou un utilisateur critique supprimé par inadvertance. Si la réponse à l’une de ces questions est « nous devrions tout reconstruire à partir de zéro », vous avez une lacune à combler avant que quelqu’un ne commette la même erreur que le client évoqué dans mon introduction.