Recovery multi-cloud qui fonctionne vraiment

Le cloud, censé nous apporter de la flexibilité, ainsi que :

• Des services de premier ordre.
• L’innovation dans le cloud.
• Ne pas être prisonnier d’un fournisseur.

Mais lorsqu’un incident informatique survient, cette flexibilité se transforme souvent en complexité. Dans cet épisode de STRIVE, j’ai rencontré Akshay Joshi, directeur principal de la gestion des produits – dont le parcours professionnel l’a conduit chez IBM, AWS, Microsoft, Clumio et, aujourd’hui, Commvault – afin d’aborder une vérité dérangeante : la plupart des entreprises pensent être prêtes pour le cloud. Jusqu’à ce qu’elles se rendent compte qu’elles ne le sont pas. Regardez l’épisode dans son intégralité.

Points clés : ce qu’exige réellement le cloud

• La sauvegarde au niveau des services n’équivaut pas à la restauration au niveau des applications. Protéger des sources de données individuelles n’est pas la même chose que restaurer un écosystème d’applications synchronisées.
• La complexité de la restauration se multiplie d’un cloud à l’autre. Différents points de restauration, différents comptes, différentes équipes d’administration : chacun de ces éléments ajoute des obstacles à un moment où chaque seconde compte.
• Les outils natifs des hyperscalers sont indispensables, mais ils ne suffisent pas. S’ils assurent la protection au sein de leur propre cloud, ils ne permettent pas l’orchestration entre différents clouds.
• L’isolation est la première pièce du domino lors d’un incident cybernétique. Plus l’environnement est vaste, plus il est difficile d’en limiter l’impact.
• La résilience doit être intégrée dès la conception, et non ajoutée a posteriori. La cartographie des dépendances et la planification de la reprise après sinistre doivent débuter dès la conception de l’application, et non après son déploiement.
• L’automatisation basée sur l’IA apporte davantage de puissance, mais aussi de nouveaux risques. Les flux de travail basés sur des agents nécessitent des contrôles d’autorisation rigoureux et une gouvernance rigoureuse.

Le fossé entre la théorie et la réalité

En théorie, la restauration semble simple : jusqu’où faut-il restaurer ? Que faut-il restaurer ? Où faut-il restaurer ces données ? Mais, comme l’explique Akshay, chacune de ces questions se complexifie dans un environnement multicloud. Différents services peuvent avoir des points de restauration différents. Certains microservices peuvent être affectés tandis que d’autres ne le sont pas. La restauration peut nécessiter une refonte de l’architecture si elle s’effectue entre différentes régions ou entre différents comptes.

Ce qui semble simple dans la documentation s’avère extrêmement complexe à mettre en œuvre. Et lorsqu’un ransomware frappe, les équipes ne se contentent pas de consulter sereinement leurs guides d’intervention : elles courent dans tous les sens.

Le premier domino : l’isolement

Chaque vecteur de menace s’amplifie proportionnellement à la complexité de l’environnement cloud : la diversification de l’infrastructure élargit également le champ d’action opérationnel.

Sauvegarde au niveau des services vs. Récupération au niveau des applications

C’est là que la plupart des organisations se font piéger. Elles précisent :

• Données Azure avec Azure Backup
• Données AWS avec AWS Backup
• Cloud Google Cloud à l’aide d’un outil distinct

Pris individuellement, chaque service peut être protégé. Mais pris dans leur ensemble, il se peut que l’application ne puisse pas être restaurée dans un état synchronisé. Les outils natifs ne communiquent pas d’un cloud à l’autre. Le cloud n’est pas intrinsèquement « cloud ». Ils ne sont pas conçus pour optimiser l’objectif de délai de reprise (RTO) ou l’objectif de point de reprise (RPO) à grande échelle dans un environnement cloud.

Et lorsque la restauration dépend de la synchronisation de plusieurs sources de données entre différents hyperscalers, l’orchestration fait toute la différence : cela peut prendre quelques heures ou plusieurs jours. C’est précisément pour cette raison que les stratégies de restauration unifiées existent : non pas pour remplacer les hyperscalers, mais pour les coordonner.

La cartographie des dépendances n’est plus facultative

Cela fait plus d’une décennie que l’on parle de cartographie des dépendances des applications. Mais dans un monde multicloud, ce n’est plus un simple « plus ». Les applications s’étendent désormais sur plusieurs hyperscalers, plusieurs équipes DevOps, plusieurs domaines d’administration et plusieurs outils de sauvegarde provenant de différents fournisseurs.

La fragmentation des responsabilités ralentit la Recovery. La fragmentation des fournisseurs complique l’orchestration. Les silos opérationnels génèrent des retards au pire moment possible. La résilience doit être mise en œuvre dès le départ, et non ajoutée après coup, une fois le déploiement effectué.

Aperçu : Pourquoi le cloud échoue sans cartographie des dépendances

Dans cet extrait de la discussion STRIVE, Akshay explique pourquoi il est essentiel de mettre en œuvre la résilience dès la phase de conception pour faire face aux cyberattaques réelles.

Concevoir pour la résilience – et pas seulement pour la protection

L’un des points les plus marquants de cet épisode : les applications modernes doivent être conçues non seulement en fonction des performances et de l’évolutivité, mais aussi en fonction de la capacité de reprise. Cela signifie que :

• On accorde autant d’importance au RTO qu’au RPO.
• Concevoir en tenant compte du cloud.
• Renforcer la visibilité autant que possible.
• Réduire la fragmentation au niveau des fournisseurs et de l’administration.
• Tester la reprise dans différents environnements.

La rapidité de la Recovery a un impact sur le chiffre d’affaires. La clarté de la Recovery a un impact sur la réputation. Les temps d’arrêt ont un impact sur la confiance des clients. L’innovation multicloud doit s’accompagner d’une discipline de Recovery multicloud.

La couche d’IA et d’automatisation

Aucune discussion ne saurait être complète sans aborder l’IA. Les workflows « agents » sont de plus en plus intégrés aux plateformes SaaS d’entreprise. Mais l’automatisation soulève de nouvelles questions :

• De quelles autorisations disposent les agents ?
• À quelle fréquence les sauvegardes sont-elles effectuées ?
• Quelles sont les implications financières des décisions en matière d’automatisation ?
• Les agents sont-ils considérés comme des identités dont l’accès est réglementé ?

L’IA peut renforcer la résilience, mais sans garde-fous, elle peut également accroître les risques. La clé réside dans une délégation contrôlée.

Pourquoi avons-nous eu cette conversation sur STRIVE ?

STRIVE ne vise pas à répéter ce que tout le monde sait déjà. Il s’agit de s’attaquer aux lacunes qui apparaissent lors d’incidents cybernétiques réels. L’adoption du multi-cloud ne ralentit pas. Mais à moins que les stratégies de Recovery n’évoluent parallèlement à l’architecture, la complexité prendra le pas sur la préparation.

C’est pourquoi ce débat est important. Et c’est pourquoi nous avons fait appel à Akshay, qui a travaillé avec plusieurs hyperscalers et qui en comprend à la fois les atouts et les limites.

Regardez l’épisode dans son intégralité

Dans l’épisode complet de STRIVE, vous découvrirez :

• Le véritable fossé entre la sauvegarde au niveau des services et la restauration au niveau des applications.
• Pourquoi l’isolement est la première pièce du domino dans le cas des ransomwares.
• En quoi la fragmentation des fournisseurs complique l’orchestration.
• Les points sur lesquels les RSSI et les responsables DevOps doivent s’accorder.
• Comment l’IA modifie l’équation de la résilience.

Regardez-le dès maintenant. Si vous utilisez AWS, Azure ou Google Cloud, cette discussion est incontournable.

FAQ

Q : Pourquoi la sauvegarde native proposée par les hyperscalers n’est-elle pas suffisante ?

R : Les outils natifs protègent les données au sein d’un cloud spécifique, mais ne gèrent pas la restauration entre différents clouds. La restauration entre clouds nécessite une coordination entre les différents services et fournisseurs.

Q : Quelle est la principale lacune en matière de cloud ?

R : Le décalage entre la manière dont les sauvegardes sont effectuées (service par service) et la manière dont la restauration doit s’effectuer (à l’échelle de l’application).

Q : Que signifie « ouverture environnementale » ?

R : Ce terme désigne l’étendue des comptes, des environnements cloud, des identités et des services au sein d’un environnement. À mesure que cette étendue s’élargit, les risques et la complexité augmentent proportionnellement.

Q : Pourquoi la cartographie des dépendances est-elle essentielle ?

R : Les applications s’étendent désormais sur plusieurs clouds et impliquent plusieurs équipes. Sans cartographie des dépendances des services, la définition de l’ordre de restauration relève de la conjecture.

Q : Quel est l’impact de l’IA sur la reprise après sinistre ?

R : Les workflows basés sur l’IA peuvent contribuer à automatiser les décisions en matière de sauvegarde et de restauration, mais nécessitent des contrôles d’accès rigoureux, une bonne gestion des coûts et une surveillance efficace.

Q : Par où les entreprises devraient-elles commencer pour améliorer leur infrastructure cloud ?

R : Commencez par évaluer :

• • L’alignement de la reprise au niveau de l’application.
  • Les opportunités de consolidation des fournisseurs.
  • La coordination entre les équipes.
  • La stratégie d’isolation en cas d’incident.
  • Fréquencecloud.

Chris Mierzwa est directeur principal du marketing de portefeuille chez Commvault.