Points clés à retenir
- La gestion de la sauvegarde et de la restauration dans le cadre d’une infrastructure en tant que code (IaC) permet de réduire les écarts de configuration et d’aligner la protection des données sur les pratiques modernes du cloud.
- Le fournisseur Clumio Terraform permet de définir de manière déclarative les comptes AWS, les politiques et les règles de protection, tout en assurant le contrôle des versions.
- La protection basée sur des balises est conçue pour protéger automatiquement les ressources existantes et futures, ce qui permet de réduire les interventions manuelles et d’évoluer efficacement dans tous les environnements.
- La définition des politiques de sauvegarde dans Terraform contribue à améliorer la visibilité, la reproductibilité et la gouvernance grâce à des workflows standard de pull request.
- Cette approche peut s’avérer particulièrement utile pour les environnements AWS comportant plusieurs comptes et pour les organisations ayant déjà adopté Terraform comme norme.
Le cloud est de plus en plus défini par le code. Les instances EC2, les rôles de gestion des identités et des accès (IAM), les clouds privés virtuels et les bases de données sont désormais stockés dans des référentiels soumis à un contrôle de version et sont déployés de manière prévisible via l’infrastructure en tant que code (IaC). Cependant, les politiques de Backup and Recovery sont souvent encore configurées manuellement dans des consoles web. Cet écart engendre des risques. Lorsque l’infrastructure est déclarative mais que la protection des données ne l’est pas, les équipes s’exposent à :
- Une dérive de configuration.
- Une protection inégale selon les comptes.
- Des erreurs manuelles.
- Une visibilité limitée sur ce qui est réellement protégé.
Pour les organisations qui utilisent déjà Terraform, la sauvegarde et la restauration doivent être gérées de la même manière que le reste de la pile, c’est-à-dire par le biais du code. Le fournisseur Terraform de Clumio permet de définir la protection des données AWS de manière déclarative, parallèlement à l’infrastructure. Vous pouvez découvrir ce fournisseur et sa documentation ici : https://registry.terraform.io/providers/clumio-code/clumio/latest/docs/guides/getting_started. Dans cet article, nous allons vous expliquer comment automatiser la protection des charges de travail AWS à l’aide de Terraform et de Clumio by Commvault, et pourquoi cette approche s’adapte plus efficacement aux clouds modernes.
Le problème lié à la configuration des sauvegardes via la console
Dans une configuration classique, la protection des ressources AWS nécessite :
- Une connexion aux comptes AWS.
- Une configuration distincte de la protection sur plusieurs services AWS.
- La création de stratégies de sauvegarde.
- La définition des règles de protection.
- L’attribution manuelle des ressources.
- Répétez cette procédure pour chaque compte ou environnement.
Même dans des environnements bien gérés, cela entraîne :
- Une configuration manuelle répétitive.
- Une application incohérente des règles.
- Une protection différée pour les ressources nouvellement créées.
- Un contrôle de version limité.
Terraform contribue déjà à résoudre ce problème au niveau de l’infrastructure. Le fournisseur Clumio Terraform étend ce modèle à la protection des données.
De zéro à la protection : utilisation de quatre fichiers
La protection de plusieurs services AWS peut être définie à l’aide d’un petit ensemble de fichiers Terraform plutôt que par une série d’étapes manuelles dans l’interface utilisateur.
La configuration suit une structure simple.
- Définir les fournisseurs (AWS + Clumio)
La première étape consiste à déclarer les fournisseurs. Terraform a besoin de savoir :
- Vous utilisez AWS.
- Vous utilisez le fournisseur Clumio.
Cela permet de connecter Terraform aux deux plateformes. La documentation officielle du fournisseur explique en détail cette configuration dans le guide « Pour commencer ».
- Connecter des comptes AWS à Clumio
Ensuite, le module Clumio établit la connexion entre AWS et Clumio. Cela permet de simplifier la configuration des rôles IAM nécessaires à la protection des données. Au lieu de configurer manuellement les rôles et les autorisations, le module gère l’intégration de manière standardisée. Le code source du fournisseur est accessible au public sur GitHub. Cela signifie que votre intégration est définie dans le code, soumise à un contrôle de version et reproductible dans tous les environnements.
- Définir les politiques de sauvegarde sous forme de code
C’est dans la définition des politiques de sauvegarde que l’IaC prend tout son sens. Dans une configuration basée sur Terraform :
- Il est possible de définir différents objectifs de point de reprise pour différents types de ressources.
- Il est possible de définir plusieurs niveaux de conservation au sein d’une même politique (par exemple, une conservation à court terme et une conservation à long terme).
- Cette même politique peut s’appliquer automatiquement en fonction de conditions prédéfinies.
Au lieu de devoir passer d’une console à l’autre, une seule configuration Terraform permet de définir la fréquence, la durée de conservation et le périmètre des ressources. Cette politique est réutilisable et peut faire l’objet d’une révision, comme n’importe quelle autre configuration d’infrastructure.
- Protection automatique basée sur des balises
L’un des aspects les plus évolutifs de cette approche est la protection par balises. Une règle de protection peut être configurée pour protéger automatiquement toute ressource associée à une paire clé/valeur spécifique. Par exemple : created_by = demo_script Cela signifie que :
- Les ressources existantes associées à ce balisage sont protégées.
- Les futures ressources portant ce balisage seront automatiquement incluses.
- Aucune intervention manuelle n’est nécessaire.
En ce qui concerne spécifiquement S3, les groupes de protection utilisent également des balises pour gérer des centaines de compartiments comme une seule unité logique, ce qui permet d’appliquer des modifications de politique de manière centralisée et à grande échelle. Cela contribue à réduire les écarts de configuration.
Application de la configuration
Une fois la configuration définie, Terraform initialise le répertoire de travail, affiche un aperçu des modifications prévues, puis applique la configuration. Terraform est conçu pour respecter les dépendances entre les ressources, en les créant dans le bon ordre. Cette configuration permet de connecter des comptes AWS, d’activer des politiques, d’appliquer des règles de protection et de protéger les ressources balisées. Et surtout, l’ensemble de la stratégie de protection est intégré dans du code soumis à un contrôle de version.
Pourquoi est-ce important pour le cloud ?
Pour les équipes qui appliquent les principes de l’IaC, la configuration des sauvegardes doit respecter les mêmes règles que celles qui s’appliquent à la mise en place de l’infrastructure. La définition d’une sauvegarde dans Terraform offre plusieurs avantages concrets :
- Contrôle de version : les politiques de sauvegarde sont définies dans le code et peuvent être révisées, versionnées et validées via des workflows standard de pull request.
- Reproductibilité : la même configuration peut être déployée de manière cohérente sur les comptes de développement, de préproduction et de production.
- Réduction des écarts : les configurations Terraform peuvent être réappliquées pour garantir le respect de l’état déclaré, ce qui permet de réaligner les modifications manuelles ou hors bande sur la configuration prévue.
- Visibilité totale : la logique de protection est visible dans le code, plutôt que dissimulée dans la configuration de l’interface utilisateur.
- Séparation entre la configuration et l’interface : la stratégie de sauvegarde est définie de manière déclarative, indépendamment de l’état de la console.
Quand cette approche est pertinente
L’automatisation des sauvegardes avec Terraform est particulièrement utile pour :
- Les environnements AWS multi-comptes.
- Les secteurs réglementés nécessitant une configuration vérifiable.
- Les plateformes chargées de la gestion de l’infrastructure partagée.
- Les entreprises qui ont déjà adopté Terraform comme norme.
Si votre infrastructure est définie sous forme de code, votre stratégie de protection des données devrait l’être également.
Pour commencer
Pour approfondir cette approche :
- Consultez la documentation relative au fournisseur Clumio Terraform.
- Consultez le code source du fournisseur sur GitHub.
- Regardez la vidéo de démonstration « Démarrage rapide » ci-dessus.
Vous pouvez également tester Clumio via AWS Marketplace.
FAQ
Q : Pourquoi les politiques de sauvegarde devraient-elles être gérées sous forme de code ?
R : Lorsque l’infrastructure est définie sous forme de code, mais que les politiques de sauvegarde sont configurées manuellement, des lacunes et des incohérences peuvent apparaître. La gestion de la sauvegarde sous forme de code permet d’aligner la protection sur les workflows de déploiement, de réduire les erreurs manuelles et d’offrir une visibilité, avec contrôle des versions, sur votre stratégie de protection des données.
Q : Quelles sont les fonctionnalités offertes par le fournisseur Clumio Terraform ?
R : Le fournisseur Clumio pour Terraform permet de définir de manière déclarative les ressources de protection des données AWS, telles que les connexions aux comptes, les politiques de sauvegarde et les règles de protection. Cela permet aux équipes de gérer les configurations de sauvegarde en parallèle de l’infrastructure au sein d’un même workflow Terraform.
Q : En quoi la protection par balises améliore-t-elle l’évolutivité ?
R : La protection par balises est conçue pour appliquer automatiquement des règles à toute ressource correspondant à une paire clé/valeur spécifiée. Cela permet de protéger les ressources existantes et futures sans intervention manuelle, ce qui facilite la gestion de la protection à grande échelle, tous comptes et services confondus.
Q : Comment Terraform contribue-t-il à réduire les écarts de configuration dans les environnements de sauvegarde ?
R : Terraform gère un état déclaré pour l’infrastructure et les politiques de sécurité. La réapplication des configurations permet de réaligner les modifications manuelles ou hors bande sur l’état souhaité, ce qui contribue à améliorer la cohérence entre les environnements.
Q : Dans quels cas l’automatisation des sauvegardes avec Terraform est-elle la plus pertinente ?
R : Cette approche s’avère particulièrement utile dans les environnements AWS comportant plusieurs comptes, dans les secteurs réglementés exigeant des configurations vérifiables, au sein des plateformes chargées de la gestion de services partagés, ainsi que dans les organisations qui utilisent déjà Terraform comme norme pour l’infrastructure en tant que code (IaC).
Q : Comment les équipes peuvent-elles se lancer dans la protection des données AWS à l’aide de Terraform ?
R : Les équipes peuvent commencer par consulter la documentation du fournisseur Clumio Terraform, explorer le code source du fournisseur sur GitHub et visionner la démo « Quick Start ». Tester Clumio via AWS Marketplace constitue également une prochaine étape pratique.
Lawrence Chang est directeur technique chez Clumio et Vir Choksi est responsable principal du marketing produit chez Commvault.
