Rclone crypt : chiffrer les fichiers et tester leur récupération

Rclone crypt ajoute un chiffrement côté client à un chemin de stockage. Les fichiers écrits via le remote crypt sont chiffrés avant d’atteindre le stockage sous-jacent, puis déchiffrés lorsqu’ils sont relus par ce remote. Une écriture directe sur le chemin de stockage contourne crypt : le choix du bon remote fait donc partie de la protection.

Ce guide utilise un dossier local jetable pour tester la procédure avant d’ajouter un fournisseur cloud. Nous avons chiffré cinq fichiers avec Rclone 1.76.0 sous Windows, les avons restaurés, puis avons répété la récupération avec une configuration reconstruite séparément. Les deux restaurations correspondaient aux manifestes SHA-256 d’origine. Les accès fournisseur, le comportement cloud et la compatibilité Hivenet n’ont pas été testés.

Séparer la vue lisible des fichiers chiffrés

Dans cet exercice, vault: est la vue crypt lisible. Le dossier local ciphertext contient les fichiers chiffrés stockés. La documentation crypt explique cette couche. Avec un stockage cloud, la distinction pourrait être entre vault: et storage:bucket/encrypted.

Réservez un chemin vide aux données chiffrées. Ajouter une configuration crypt ne convertit pas les fichiers en clair déjà présents à cet emplacement. Notre guide de transfert rclone présente le fonctionnement général des copies et leurs contrôles.

Préparer un petit environnement de test local

Installez Rclone à partir des instructions officielles et relevez sa version :

rclone version

Créez un dossier de travail avec deux sous-dossiers voisins nommés source et ciphertext. Placez uniquement des fichiers ordinaires sans importance dans source, dont un fichier dans un sous-dossier et un fichier vide. Laissez ciphertext vide. Exécutez toutes les commandes depuis le dossier de travail, avec les configurations et les destinations de restauration hors de l’arborescence source.

Gardez la source stable pendant l’enregistrement et la copie des fichiers. Cet exercice sur une même machine ne protège pas contre sa perte. L’emplacement et la rétention des vraies sauvegardes demandent un plan distinct, comme l’explique notre guide de sauvegarde cloud.

Configurer le remote crypt et conserver ses secrets

rclone --config ./lab.conf config

Dans la configuration interactive, créez un remote avec les paramètres suivants. Choisissez le type de stockage par son nom, car les numéros du menu peuvent changer :

Paramètre	Valeur pour cet exercice
Nom du remote	vault
Type de stockage	crypt
Chemin à chiffrer/déchiffrer	Le véritable chemin absolu du dossier ciphertext vide
Chiffrement des noms de fichiers	standard
Chiffrement des noms de dossiers	true
Mot de passe crypt	Un nouveau secret robuste, conservé dans votre gestionnaire de mots de passe
Sel personnalisé / password2	Un secret distinct, également conservé pour la récupération
Paramètres avancés	Conserver les valeurs par défaut pour cet exercice

Un chemin local absolu est accepté, par exemple C:/rclone-crypt-lab/ciphertext sous Windows. Saisissez votre vrai chemin, pas cet exemple. Les deux secrets crypt et les réglages de chiffrement des noms doivent pouvoir être reproduits pour reconstruire l’accès. Le sel personnalisé n’est pas stocké avec les fichiers chiffrés : conservez-le avec le mot de passe crypt dans votre dossier de récupération.

Protégez aussi le fichier de configuration. Le format masqué des mots de passe de Rclone est réversible ; il ne remplace pas le chiffrement de la configuration. Après avoir enregistré le remote, définissez un mot de passe distinct pour ce fichier et vérifiez qu’il peut être ouvert :

rclone --config ./lab.conf config encryption set
rclone --config ./lab.conf config encryption check

La commande set protège la configuration, tandis que la commande check teste son déchiffrement. Saisissez les mots de passe aux invites plutôt que dans les lignes de commande. Précisez dans votre dossier de récupération quel secret protège les fichiers, lequel sert de sel et lequel déverrouille la configuration.

Enregistrer le contenu attendu avant la copie

Enregistrez ce script Python 3 sous verify-files.py dans le dossier de travail. Il relève les chemins relatifs et les empreintes SHA-256, puis compare une arborescence restaurée à cette référence :

import hashlib
import json
import sys
from pathlib import Path

mode, folder, manifest_file = sys.argv[1:]
root = Path(folder)
if mode not in ('record', 'compare') or not root.is_dir():
    raise SystemExit('Use record or compare with an existing directory.')
files = {}
for path in sorted(root.rglob('*')):
    if path.is_symlink():
        raise SystemExit('This example checks regular files, not symlinks.')
    if path.is_file():
        digest = hashlib.sha256()
        with path.open('rb') as stream:
            for block in iter(lambda: stream.read(1024 * 1024), b''):
                digest.update(block)
        files[path.relative_to(root).as_posix()] = digest.hexdigest()
if mode == 'record':
    with open(manifest_file, 'x', encoding='utf-8') as stream:
        json.dump(files, stream, indent=2)
    print('Recorded', len(files), 'files')
else:
    expected = json.loads(Path(manifest_file).read_text(encoding='utf-8'))
    if files != expected:
        raise SystemExit('FAIL: file paths or SHA-256 hashes differ.')
    print('PASS:', len(files), 'files match')

python verify-files.py record source baseline.json

Utilisez python3 si c’est le nom de votre commande Python. Le script refuse d’écraser une référence existante. Il vérifie le contenu et les chemins des fichiers ordinaires, y compris les fichiers manquants ou supplémentaires ; il ne contrôle pas les dossiers vides, les horodatages, les permissions ni la cohérence applicative. Gardez la source inchangée pendant la copie.

Simuler la copie chiffrée, puis l’exécuter

rclone --config ./lab.conf copy ./source vault: --dry-run --verbose
rclone --config ./lab.conf copy ./source vault: --verbose

Lancez ces commandes séparément et examinez d’abord la simulation. La commande copy copie le contenu du dossier. Elle peut remplacer des fichiers modifiés à destination, mais ne supprime pas les fichiers supplémentaires. La destination vide de cet exercice évite les choix liés à des fichiers existants. La simulation affiche les opérations prévues sans copier les données.

Examinez les deux vues avec ces listes en lecture seule :

rclone --config ./lab.conf lsf vault: --recursive
rclone --config ./lab.conf lsf ./ciphertext --recursive

La liste crypt doit afficher les noms lisibles. La liste directe affiche les noms chiffrés stockés. Ce contrôle aide à vérifier la configuration ; ce n’est pas un audit cryptographique. N’écrivez pas de fichiers en clair directement dans le dossier ciphertext et ne les mélangez pas aux fichiers gérés par crypt.

Comparez la copie chiffrée à sa source :

rclone --config ./lab.conf cryptcheck ./source vault:

cryptcheck nécessite une somme de contrôle prise en charge par le stockage sous-jacent. Il utilise le nonce de chaque fichier chiffré pour comparer le contenu chiffré correspondant. Lisez le résultat et le code de sortie. Si le fournisseur cloud prévu ne permet pas ce contrôle, un déchiffrement complet suivi d’une comparaison reste nécessaire.

Restaurer dans un nouveau dossier et comparer chaque fichier

Utilisez une destination nommée restore-check qui n’existe pas encore. Examinez la simulation avant de lancer la vraie copie :

rclone --config ./lab.conf copy vault: ./restore-check --dry-run --verbose
rclone --config ./lab.conf copy vault: ./restore-check --verbose
python verify-files.py compare restore-check baseline.json

Une comparaison réussie affiche PASS et le nombre de fichiers. Un fichier absent, supplémentaire ou modifié fait échouer le contrôle. Une liste lisible ou une commande de transfert réussie ne prouve pas à elle seule la récupération complète des données attendues.

Reconstruire l’accès sans copier la configuration d’origine

Gardez la configuration d’origine en sécurité, mais créez un fichier distinct pour ce test :

rclone --config ./recovery.conf config

Créez un remote crypt nommé recovery vers le même chemin absolu ciphertext. Saisissez le mot de passe crypt et le sel personnalisé d’origine, ainsi que les mêmes paramètres de noms de fichiers et de dossiers. Ne générez pas de nouveaux secrets crypt. Le nom du remote peut être différent.

Protégez la configuration reconstruite, puis restaurez dans une autre destination neuve. Toutes ces commandes utilisent explicitement recovery.conf :

rclone --config ./recovery.conf config encryption set
rclone --config ./recovery.conf config encryption check
rclone --config ./recovery.conf copy recovery: ./restore-rebuilt --verbose
python verify-files.py compare restore-rebuilt baseline.json
rclone --config ./recovery.conf cryptcheck ./source recovery:

Dans notre test local, nous avons renommé la configuration d’origine avant cette deuxième restauration. Les deux ensembles de cinq fichiers correspondaient aux empreintes enregistrées et les deux contrôles crypt ont réussi. Avec un sel incorrect, Rclone a ignoré les noms illisibles et renvoyé le code zéro, mais les données restaurées ne correspondaient pas à la référence. Ce résultat justifie la comparaison explicite des fichiers lors du test de récupération.

Une copie séparée des données chiffrées, dont un octet avait été modifié, n’a pas pu être restaurée correctement et a produit une erreur. Les fichiers chiffrés d’origine sont restés inchangés. Ces contrôles concernent les fichiers locaux testés, pas tous les cas de corruption, de métadonnées ou de panne cloud. Notre guide des tests de restauration aide à adapter l’exercice aux vrais besoins de récupération.

Adapter le plan de récupération au stockage cloud

Avant d’utiliser un fournisseur, vérifiez le remote sous-jacent et choisissez un chemin réservé aux fichiers chiffrés. Répétez la copie et la restauration avec des noms et des tailles représentatifs, ainsi qu’avec l’identité prévue pour la récupération. Le stockage local utilisé ici ne teste pas les limites de chemin du fournisseur, ses autorisations, les reprises réseau ni les coûts cloud.

Le chiffrement laisse certaines informations visibles, dont la structure des dossiers, les dates de modification et des informations sur la longueur des fichiers. Il ne crée pas non plus d’historique des versions et n’empêche pas un compte autorisé de supprimer les fichiers chiffrés. Traitez les copies de récupération et la rétention séparément des paramètres de chiffrement.

Changer le mot de passe qui ouvre la configuration ne renouvelle pas la clé de chiffrement des fichiers. Modifier le mot de passe crypt ou le sel ne rechiffre pas non plus le contenu existant. Si les clés de données doivent changer, prévoyez une migration vérifiée vers une nouvelle destination chiffrée et conservez l’accès de récupération jusqu’à sa validation.

Pour les tâches planifiées, utilisez les mécanismes documentés de déverrouillage avec une source de secrets protégée. Examinez les variables RCLONE_* existantes, qui peuvent modifier les réglages même lorsqu’un fichier de configuration est précisé. Conservez la configuration, les secrets crypt, les détails d’accès au stockage et une procédure testée indépendamment de la machine protégée.