Nous recevons occasionnellement des nouvelles de clients qui exécutent Cloud Native Qumulo (CNQ) sur Microsoft Azure : « Nos données résident dans le stockage Blob Azure — pouvons-nous donc simplement utiliser les outils natifs de sauvegarde et de gestion des versions d'Azure pour les protéger ? »
La réponse courte est non, et la compréhension why Il s'agit du fondement d'une stratégie de protection solide pour CNQ. C'est le point de départ de notre nouveau livre blanc technique. "Architecture de référence pour la sauvegarde et la sécurité : Qumulo natif du cloud (CNQ) sur Microsoft Azure."
Pourquoi ce document existe-t-il ?
L'architecture de CNQ lui confère rapidité, évolutivité et rentabilité : le calcul et le stockage sont totalement dissociés, avec des machines virtuelles sans état gérant la mise en cache et les E/S, tandis qu'une couche de données persistante et à évolutivité élastique réside directement dans des comptes de stockage Blob Azure. Cette séparation est un atout pour les performances et l'élasticité, mais elle implique également que les données stockées dans ces comptes Blob ne sont pas de simples fichiers. Elles sont stockées au format objet propriétaire de Qumulo, compressé et chiffré.
Cela a une conséquence directe et importante : Le stockage Blob Azure ne peut pas servir de limite de sauvegarde restaurable indépendamment pour CNQ. Les fonctionnalités natives d'Azure, telles que le versionnage des blobs ou l'immuabilité WORM, ne s'appliquent pas ici, et ne devraient pas s'appliquer. Leur utilisation ne permettrait pas de créer une sauvegarde exploitable ; elle pourrait même perturber la façon dont Qumulo gère ses propres objets.
Ce livre blanc a pour but d'établir une distinction claire entre deux choses souvent confondues :
Protéger les données elles-mêmes — ce qui doit se produire au niveau de Qumulo, en utilisant des instantanés natifs, la réplication et (éventuellement) des intégrations de sauvegarde tierces prises en charge.
Sécurisation de l'infrastructure Azure environnante — identité, réseau, chiffrement, protection contre la suppression et journalisation — le tout étant géré par les contrôles natifs d'Azure.
Les deux sont importantes. Aucune ne remplace l'autre.
Qu'est-ce qu'il y a à l'intérieur
L'architecture de référence décrit le modèle de protection complet couche par couche :
Pourquoi le niveau persistant (Blob) n'est pas une limite de sauvegarde — les raisons techniques spécifiques (format d'objet propriétaire, absence de chemin de restauration pris en charge, cohérence du niveau cache et absence de coordination atomique inter-comptes à un instant donné) qui excluent la protection native Blob.
Le modèle de protection des données par couches — des instantanés Qumulo verrouillés et immuables comme défense principale contre les ransomwares et les suppressions accidentelles ou malveillantes, soutenus par une réplication continue et incrémentale à vie vers une cible de reprise après sinistre hors cluster dans un abonnement distinct.
Objectifs de reprise par scénario — des conseils pratiques sur les RPO/RTO pour tout, de la suppression accidentelle de fichiers à la perte complète d'un site ou d'un abonnement, ainsi que des guides de récupération résumés pour chaque cas.
Intégration de sauvegarde tierce — où et comment des outils comme Commvault, Cohesity, Veeam et Rubrik s'intègrent en tant que couche complémentaire (et non principale), y compris les exigences de réseau pour le suivi des modifications basé sur SnapDiff de Qumulo.
Ransomware protection — comment Qumulo NeuralProtect ajoute une détection des menaces en temps réel et une isolation automatisée au niveau du plan de données, fonctionnant en parallèle des instantanés et des sauvegardes plutôt que de les remplacer.
Sécuriser l'environnement Azure lui-même — une identité à privilèges minimaux avec élévation de privilèges contrôlée par PIM, une protection de suppression multicouche pour qu'aucun administrateur ne puisse détruire le stockage, des clés de chiffrement gérées par le client, un réseau privé et une journalisation d'audit conçus pour survivre à un compte d'administrateur compromis.
Cartographie des menaces et des contrôles — un tableau simple reliant les risques spécifiques (administrateur malveillant, ransomware, perte de région, compromission de clés) aux contrôles qui les contrent, utile pour les discussions du conseil d'administration ou lors des audits.
Qui devrait lire ceci
Ce document est rédigé pour architectes cloud et sécurité Ce document s'adresse à ceux qui conçoivent, déploient ou auditent des environnements CNQ sur Azure, notamment dans les secteurs réglementés où la capacité de récupération doit être démontrée et non simplement présumée. Il apporte également un éclairage utile à toute personne évaluant des solutions de sauvegarde tierces en parallèle de Qumulo, car il précise le rôle que ces solutions doivent (et ne doivent pas) jouer.
Le grand plat à emporter
La protection des données et la sécurité de l'infrastructure sont deux problématiques liées mais distinctes, et l'architecture de CNQ exige de les traiter comme telles. Les snapshots verrouillés et la réplication protègent vos données. La gouvernance Azure (identité, réseau, chiffrement et contrôles de suppression) protège l'infrastructure sous-jacente. En maîtrisant ces deux aspects, vous bénéficiez d'une défense en profondeur : aucune défaillance, erreur de configuration ou authentification compromise ne peut mettre votre système de fichiers hors service.
Lire le plein document pour voir comment les éléments s'assemblent et pour obtenir les conseils de configuration spécifiques (variables Terraform, comportements de verrouillage, configuration PIM et ports réseau) nécessaires à sa mise en œuvre dans votre propre environnement.
Le livre blanc a été rédigé par Paul Johnson, directeur principal de l'ingénierie des ventes, et Justin Botticelli, ingénieur système senior.