Comment configurer une sauvegarde chiffrée 3-2-1 pour une petite entreprise avec rclone et google drive sans exposer vos clés

Je vais vous expliquer, pas à pas et à la première personne, comment j’ai mis en place pour une petite entreprise une stratégie de sauvegarde conforme au principe 3-2-1 en utilisant rclone et Google Drive, tout en évitant d’exposer nos clés et tokens. Le but : avoir des sauvegardes chiffrées, automatisées, vérifiables et sécurisées sans sacrifier la simplicité d’administration.

Pourquoi le 3-2-1 et pourquoi rclone + Google Drive ?

Le principe 3-2-1 est simple et robuste : 3 copies des données, sur 2 types de supports, dont 1 copie hors site. Pour une petite structure, cela se traduit généralement par :

• la copie principale sur le serveur / NAS (production),
• une copie sur un disque externe local (sur site),
• une copie chiffrée hors site (Google Drive).

J’utilise rclone parce que c’est un outil léger, scriptable, multi-backend et très flexible. Il sait gérer Google Drive, créer des remotes chiffrés (crypt), vérifier l’intégrité et s’intégrer facilement dans des scripts cron ou des runners CI.

Principes de sécurité que j’applique

• Ne jamais exposer directement les clés ou tokens dans des dépôts ou des scripts publics.
• Limiter les permissions Google Drive en choisissant des scopes restreints (ex : drive.file) ou en utilisant un compte de service dédié partagé sur un dossier limité.
• Chiffrer les données côté client avec rclone crypt avant envoi : Google Drive ne verra que des blobs chiffrés.
• Protéger le fichier de configuration rclone (permissions 600) et, de préférence, le chiffrer avec GPG ou le stocker sur un chemin accessible uniquement par l’utilisateur qui exécute les tâches.
• Mettre en place des vérifications automatiques (rclone check) et des alertes en cas d’échec.

Choix du mode d’authentification Google Drive

Deux approches courantes :

• OAuth2 (client_id/client_secret) : pratique pour un utilisateur Google standard. Par défaut rclone stocke le token dans le config mais on peut limiter le scope à drive.file pour que le token n’ait accès qu’aux fichiers créés par l’app.
• Compte de service (service account) : plus adapté pour les sauvegardes automatisées en entreprise. Le compte de service a son propre Drive ; on partage avec lui un dossier sur le Drive principal ou on configure un dossier dédié. Attention : sans Domain-Wide Delegation, un compte de service ne peut pas accéder au Drive d’un utilisateur sauf si un dossier lui est partagé.

Pour limiter les risques, j’utilise généralement un compte Google dédié à la sauvegarde, avec 2FA activé pour le compte principal, et un compte de service ou un app client OAuth créé dans Google Cloud Platform dont les credentials sont stockés en dehors du repo, chiffrés et accessibles uniquement au runner/serveur de sauvegarde.

Exemple de configuration rclone (schéma)

Voici le modèle logique : un remote « gdrive » (Google Drive) + un remote « gcrypt » (crypt) qui pointe vers gdrive:/sauvegardes_chiffrees.

Extrait type du rclone config (valeurs remplacées par des placeholders) :

<pre>

[gdrive]

type = drive

client_id = YOUR_CLIENT_ID.apps.googleusercontent.com

client_secret = YOUR_CLIENT_SECRET

scope = drive.file

token = {"access_token":"...","refresh_token":"...","expiry":"..."}

[gcrypt]

type = crypt

remote = gdrive:sauvegardes

filename_encryption = standard

directory_name_encryption = true

password = -- PASSWORD STOCKE ET CHIFFRE --

password2 = -- SALT / PASSWORD2 STOCKE ET CHIFFRE --

</pre>

Important : Je ne laisse jamais les mots de passe en clair dans les scripts. Je préfère stocker les passwords du crypt dans un fichier chiffré GPG ou dans un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager, ou même pass/bitwarden). Au démarrage du job, le secret est récupéré en mémoire et injecté de façon sécurisée.

Exemple de workflow de sauvegarde automatisé

Mon script bash (extrait) suit ces étapes :

• 1) Dump / tarring des répertoires ou bases (ex : mysqldump), création d’un dossier daté localement.
• 2) Copie locale vers disque externe (rsync ou rclone copy local mount).
• 3) Chiffrement et upload vers gcrypt: rclone copy --create-empty-src-dirs /chemin/vers/dump gcrypt:YYYY-MM-DD --transfers 4 --checkers 8 --log-file /var/log/rclone-backup.log
• 4) Vérification : rclone check /chemin/vers/dump gcrypt:YYYY-MM-DD --one-way
• 5) Rotation / purge locale : suppression des sauvegardes locales plus anciennes que X jours.

Exemple de ligne rclone (remplacez les placeholders) :

<pre>

rclone copy /srv/backups/daily gcrypt: --transfers=4 --checkers=8 --log-level=INFO --log-file=/var/log/rclone-backup.log --timeout=1h

rclone check /srv/backups/daily gcrypt: --one-way --log-file=/var/log/rclone-check.log

</pre>

Rotation, versioning et conservation

Pour garder des versions, je recommande d’uploader dans des dossiers datés (YYYY-MM-DD). Ainsi, on peut conserver X journées, et supprimer les dossiers plus anciens via rclone delete --min-age ou via un script qui liste les dossiers et purge selon la politique de rétention.

Exemple pour supprimer les dossiers plus vieux que 90 jours :

<pre>

rclone delete gcrypt: --min-age 90d

rclone rmdirs gcrypt: --min-age 90d

</pre>

Contrôles et vérifications

Un backup qui n’est pas vérifié est une illusion. J’automatise :

• rclone check pour vérifier la presence et somme de contrôle (md5/sha1 selon backend),
• restaurations partielles régulières (test de 1 fichier critique par semaine),
• alerte par mail / Slack si rclone retourne une erreur (code de sortie non nul ou absence de nouvelles sauvegardes attendues).

Comment je protège les credentials et évite d’exposer des clés

• Je ne commite jamais le fichier rclone.conf dans un repo. Il est stocké sur le serveur de sauvegarde avec droits root:root 600.
• Pour les CI/CD ou serveurs éphémères, j’utilise un gestionnaire de secrets et je récupère les credentials au runtime (ex : curl sécurisé vers Vault, décryptage GPG local).
• J’évite les tokens partagés. Pour Google, je crée un compte dédié et je limite le scope à drive.file ou j’utilise un dossier partagé avec un compte de service.
• Je surveille les permissions du dossier Google Drive (partages) et j’active la protection de compte (2FA) sur le compte principal qui administera le remote.

Conseils pratiques et pièges à éviter

• Testez vos restaurations : simulez une perte de données et restaurez. C’est le test le plus important.
• Ne confiez pas trop de privilèges à un seul compte. Créez un compte dédié « backup@entreprise » et ne l’utilisez que pour les sauvegardes.
• Surveillez l’utilisation de l’espace Google Drive et limitez la taille des transferts (fragmentation, compressions si pertinent).
• Documentez vos procédures : qui peut restaurer ? où sont les clefs ? comment révoquer l’accès ?

Si vous voulez, je peux vous fournir un script de sauvegarde complet adapté à votre environnement (Linux, chemins, fréquences) et un exemple de procédure de restauration pas à pas. Dites-moi quels services / bases / dossiers vous voulez sauvegarder, et je vous prépare une version prête à l’emploi adaptée à Logiciel Actu ou à votre petite entreprise.