Vous est-il déjà arrivé de vivre ce moment glaçant où vous réalisez que vous venez de supprimer par mégarde des données importantes de votre base, ou que vous avez détruit votre environnement de production au lieu de celui de développement ? Et, comble du cauchemar, de découvrir que les sauvegardes n'étaient pas activées ? Le scénario est bien trop familier. Chez DoiT, nous recevons presque chaque semaine des tickets de clients dans cette situation. Dans cet article, vous allez découvrir comment éviter que cela ne se reproduise !
Commençons par les Organizational Policies.
Organizational Policies
Comme leur nom l'indique, les Organizational Policies sont des outils qui aident les administrateurs à gérer et à contrôler le comportement des ressources au sein de leur organisation et de leurs projets GCP. Il s'agit de règles définies au niveau de l'organisation, du dossier ou du projet, qui déterminent les actions autorisées ou interdites sur les ressources concernées. Elles permettent de faire respecter les exigences de sécurité, de conformité et les bonnes pratiques opérationnelles. Et dans notre cas précis, elles peuvent servir à imposer les sauvegardes CloudSQL !
Comment s'y prendre ? Malheureusement, la documentation et les guides GCP ne sont pas d'une grande aide : les exemples ne fonctionnent pas, ou restent obscurs si vous ne maîtrisez pas déjà le Common Expression Language. Je n'ai trouvé la solution que par hasard, en aidant un client à résoudre ce problème. Voyons cela ensemble. Nous allons utiliser les Custom Constraints pour bloquer la création ou la modification de toute base CloudSQL pour laquelle la point-in-time recovery (PITR) n'est pas activée. La PITR est une technique de récupération qui permet de restaurer une base de données à un instant précis, généralement juste avant une perte ou une corruption de données.
Pas à pas
Étape 1 : créer la Custom Constraint
Notre première tâche consiste à créer une contrainte qui refusera toute tentative de lancement ou de modification d'une base CloudSQL dépourvue de PITR. Attention : si vous tentez de modifier une base CloudSQL existante sans PITR, la modification sera bloquée tant que vous n'aurez pas activé la PITR !
- Accéder à la console des Organizational Policies
Rendez-vous dans la Google Cloud Console et sélectionnez votre organisation.
2. Créer une Custom Constraint
- Cliquez sur CUSTOM CONSTRAINT.
- Renseignez un nom et une description pour votre contrainte. Cela facilitera son identification et sa compréhension par la suite.
- Sous Enforcement Type, sélectionnez `sqladmin.googleapis.com/instance`.
- Choisissez d'appliquer la contrainte aux actions Create et Update.
- Cliquez sur l'icône en forme de crayon à côté de [define condition] pour saisir la condition.
3. Définir la condition
- Saisissez la condition suivante pour imposer les sauvegardes PITR :
resource.settings.backupConfiguration.pointInTimeRecoveryEnabled == false
- Réglez l'Action sur `deny`.
Étape 2 : appliquer la contrainte
Une fois la custom constraint créée, il reste à l'appliquer au sein de votre organisation :
1. Ouvrir la contrainte :
Si ce n'est pas déjà fait, accédez à la contrainte que vous venez de créer dans la console des Organizational Policies.
2. Gérer la politique :
- Cliquez sur MANAGE POLICY en haut de la page de la contrainte.
- Sélectionnez Override parent's policy si une politique existe déjà.
- Réglez la règle d'application sur On.
- Vous devriez obtenir ceci :
Si vous ne souhaitez imposer la PITR qu'à une partie de vos bases Cloud SQL, vous pouvez utiliser des conditions pour filtrer les ressources concernées.
- Cliquez sur ADD CONDITION.
- Saisissez vos critères de filtrage, par exemple un Tag, et choisissez le Value path requis :
Pour éviter de causer des problèmes sur des ressources existantes (rappelez-vous : impossible de modifier une base CloudSQL existante sans ajouter la PITR), je vous recommande de tester d'abord la politique :
- Cliquez sur Test Policy et attendez la fin de la validation.
- Allez sur la page SIMULATION HISTORY pour vérifier que le résultat correspond à vos attentes.
- Si tout est conforme, revenez à la custom constraint et sélectionnez MANAGE POLICY.
- Si les modifications n'ont pas été appliquées, paramétrez la politique comme indiqué précédemment. Cliquez sur SET POLICY et acceptez les avertissements éventuels.
Étape 3 : vérifier l'application de la politique
Tester et vérifier le bon fonctionnement de la politique est essentiel. Suivez ces étapes pour vous en assurer :
- Tester la politique :
Toute tentative de création ou de mise à jour d'une instance Cloud SQL sans activation de la point-in-time recovery doit être refusée par l'Organizational Policy.
- Exécutez la commande suivante :
gcloud sql instances create test-instance --region=us-central1 --no-backup
- Vous devriez recevoir une erreur indiquant que la point-in-time recovery doit être activée.
2. Créer une instance Cloud SQL conforme :
Créez maintenant une instance Cloud SQL avec la point-in-time recovery activée pour qu'elle respecte la politique.
- Exécutez la commande suivante :
gcloud sql instances create compliant-instance — region=us-central1 — backup-start-time=23:00 — enable-point-in-time-recovery
Celle-ci devrait être autorisée.
En suivant ces étapes, vous avez créé et appliqué avec succès une custom constraint dans les politiques de votre organisation, garantissant que toutes les instances Cloud SQL disposent de sauvegardes point-in-time recovery. Cela rejoint les bonnes pratiques de protection des données et assure la conformité de l'ensemble des ressources cloud de votre organisation. Et vous évite un mal de tête monumental le jour où quelqu'un supprimera des données critiques. Encore une fois.
Pas de panique !
Si vous avez perdu des données, vous n'êtes pas seul. DoiT International est là pour vous aider à les récupérer et à mettre en place l'imposition des sauvegardes Cloud SQL afin que cela ne se reproduise plus. Avec plus de 180 experts cloud seniors spécialisés dans la conception de solutions cloud sur mesure, notre équipe est prête à vous accompagner sereinement dans cette démarche et à optimiser votre infrastructure pour garantir sa conformité et anticiper efficacement les besoins à venir.
Contactez-nous dès aujourd'hui pour que la gestion de vos politiques de sauvegarde Cloud SQL soit professionnelle et sans accroc. Nous sommes là pour vous aider à prendre les bonnes décisions et à déployer les solutions les mieux adaptées à vos besoins spécifiques. Au-delà de Cloud SQL, nous pouvons passer en revue l'ensemble de vos politiques sur AWS, GCP et Azure pour assurer une conformité et une sécurité de bout en bout.
Nos experts sont prêts à vous apporter conseil stratégique et expertise technique à chaque étape. Échangeons sur la meilleure approche pour votre entreprise durant cette phase d'application des politiques, afin que votre infrastructure cloud soit robuste, conforme et optimisée pour la réussite.