Le stockage de sauvegarde hors site doit être un élément essentiel du plan de reprise après sinistre de toute organisation. La possibilité de stocker des données dans un emplacement physique séparé, où elles pourraient survivre à un événement catastrophique qui détruirait toutes les données de votre centre de données principal, garantit la survie de vos données et la continuité de votre organisation. Un service de stockage Cloud est une assez bonne méthode pour stocker des sauvegardes hors site. Peu importe si vous utilisez un fournisseur de cloud ou si vous copiez simplement des données vers un centre de données externe, le cryptage de sauvegarde est indispensable dans de tels cas. Dans l'un de nos blogs précédents, nous avons discuté de plusieurs méthodes de chiffrement de vos sauvegardes. Aujourd'hui, nous allons nous concentrer sur certaines bonnes pratiques concernant le chiffrement des sauvegardes.
Assurez-vous que vos secrets sont en sécurité
Pour chiffrer et déchiffrer vos données, vous devez utiliser une sorte de mot de passe ou de clé. Selon la méthode de chiffrement (symétrique ou asymétrique), il peut s'agir d'un secret pour le chiffrement et le déchiffrement ou il peut s'agir d'une clé publique pour le chiffrement et d'une clé privée pour le déchiffrement. Ce qui est important, vous devez les garder en sécurité. S'il vous arrive d'utiliser un chiffrement asymétrique, vous devez vous concentrer sur la clé privée, celle que vous utiliserez pour déchiffrer les sauvegardes.
Vous pouvez stocker les clés dans un système de gestion de clés ou un coffre-fort - il existe de nombreuses options sur le marché parmi lesquelles choisir, comme le KMS d'Amazon ou le coffre-fort de Hashicorp. Même si vous décidez de ne pas utiliser ces solutions, vous devez toujours appliquer des pratiques de sécurité génériques telles que vous assurer que seuls les bons utilisateurs peuvent accéder à vos clés et mots de passe. Vous devez également envisager de préparer vos scripts de sauvegarde de manière à ne pas exposer les clés ou les mots de passe dans la liste des processus en cours d'exécution. Idéalement, mettez-les dans le fichier au lieu de les passer en argument à certaines commandes.
Envisagez le chiffrement asymétrique
La principale différence entre le chiffrement symétrique et asymétrique est que, lorsque vous utilisez le chiffrement symétrique pour le chiffrement et le déchiffrement, vous utilisez une clé ou un mot de passe unique. Cela nécessite des normes de sécurité plus élevées aux deux extrémités du processus. Vous devez vous assurer que l'hôte sur lequel vous cryptez les données est très sécurisé car une fuite de la clé de cryptage symétrique permettra l'accès à toutes vos sauvegardes cryptées.
En revanche, si vous utilisez un chiffrement asymétrique, vous disposez de deux clés :la clé publique pour chiffrer les données et la clé privée pour le déchiffrement. Cela rend les choses tellement plus faciles - vous n'avez pas vraiment à vous soucier de la clé publique. Même s'il serait compromis, il ne permettra toujours aucun type d'accès aux données à partir de sauvegardes. Vous devez vous concentrer uniquement sur la sécurité de la clé privée. C'est plus facile - vous chiffrez très probablement les sauvegardes quotidiennement (sinon plus fréquemment) tandis que la restauration se produit de temps en temps, ce qui permet de stocker la clé privée dans un emplacement plus sécurisé (même sur un périphérique physique dédié). Vous trouverez ci-dessous un exemple très rapide sur la façon dont vous pouvez utiliser gpg pour générer une paire de clés et l'utiliser pour chiffrer des données.
Tout d'abord, vous devez générer les clés :
[email protected]:~# gpg --gen-key
gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <[email protected]>"
Real name: Krzysztof Ksiazek
Email address: [email protected]
Comment: Backup key
You selected this USER-ID:
"Krzysztof Ksiazek (Backup key) <[email protected]>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.Cela a créé des clés publiques et privées. Ensuite, vous souhaitez exporter votre clé publique à utiliser pour chiffrer les données :
gpg --armor --export [email protected] > mybackupkey.ascEnsuite, vous pouvez l'utiliser pour chiffrer votre sauvegarde.
[email protected]:~# xtrabackup --backup --stream=xbstream | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backupEnfin, un exemple d'utilisation de votre clé primaire (dans ce cas, elle est stockée dans le trousseau de clés local) pour déchiffrer vos sauvegardes :
[email protected]:/backup# gpg -d /backup/pgp_encrypted.backup | gunzip | xbstream -x
encryption: using gcrypt 1.6.5
You need a passphrase to unlock the secret key for
user: "Krzysztof Ksiazek (Backup key) <[email protected]>"
4096-bit RSA key, ID E047CD69, created 2018-11-19 (main key ID BC341551)
gpg: gpg-agent is not available in this session
gpg: encrypted with 4096-bit RSA key, ID E047CD69, created 2018-11-19
"Krzysztof Ksiazek (Backup key) <[email protected]>"Faites pivoter vos clés de chiffrement
Quel que soit le type de chiffrement que vous avez mis en œuvre, symétrique ou asymétrique, vous devez penser à la rotation des clés. Tout d'abord, il est très important d'avoir un mécanisme en place pour faire tourner les clés. Cela peut être utile en cas de faille de sécurité et vous devrez changer rapidement les clés que vous utilisez pour le chiffrement et le déchiffrement de sauvegarde. Bien sûr, en cas de faille de sécurité, vous devez tenir compte de ce qui va se passer avec les anciennes sauvegardes qui ont été chiffrées à l'aide de clés compromises. Ils ont été compromis bien qu'ils puissent toujours être utiles et requis conformément à l'objectif de point de récupération. Il existe plusieurs options, notamment les rechiffrer ou les déplacer vers une localisation non compromise.
Accélérez le processus de chiffrement en le parallélisant
Si vous avez la possibilité d'implémenter la parallélisation du processus de chiffrement, considérez-la. Les performances de chiffrement dépendent principalement de la puissance du processeur, ce qui permet à davantage de cœurs de processeur de fonctionner en parallèle pour chiffrer le fichier, ce qui devrait entraîner des temps de chiffrement beaucoup plus courts. Certains des outils de cryptage offrent une telle option. L'un d'eux est xtrabackup qui a la possibilité d'utiliser le chiffrement intégré et de paralléliser le processus.
Ce que vous recherchez, ce sont les options "--encrypt-key" ou "--encrypt-key-file" qui activent le chiffrement intégré. En faisant cela, vous pouvez également définir "--encrypt-threads" et "--encrypt-chunk-size". Deuxièmement, augmente un tampon de travail pour le chiffrement, définit d'abord le nombre de threads à utiliser pour le chiffrement.
Bien sûr, ce n'est qu'une des solutions que vous pouvez mettre en œuvre. Vous pouvez y parvenir en utilisant des outils shell. Un exemple ci-dessous :
[email protected]:~# files=2 ; mariabackup --user=root --backup --pass=pass --stream=xbstream |split -b 60M - backup ; ls backup* | parallel -j ${files} --workdir "$(pwd)" 'echo "encrypting {}" ; openssl enc -aes-256-cbc -salt -in "{}" -k mypass > "111{}"'Ce n'est en aucun cas une solution parfaite car vous devez savoir à l'avance quelle sera la taille, plus ou moins, de la sauvegarde pour la diviser en un nombre prédéfini de fichiers correspondant au niveau de parallélisation que vous souhaitez atteindre (si vous souhaitez utiliser 2 CPU cœurs, vous devriez avoir deux fichiers, si vous voulez utiliser 4 cœurs, 4 fichiers, etc.). Il nécessite également un espace disque deux fois supérieur à la taille de la sauvegarde, car il génère d'abord plusieurs fichiers en utilisant le fractionnement, puis le cryptage crée un autre ensemble de fichiers cryptés. D'autre part, si la taille de votre ensemble de données est acceptable et que vous souhaitez améliorer les performances de chiffrement, c'est une option que vous pouvez envisager. Pour déchiffrer la sauvegarde, vous devrez déchiffrer chacun des fichiers individuels, puis utiliser "cat" pour les joindre.
Testez vos sauvegardes
Quelle que soit la manière dont vous allez mettre en œuvre le chiffrement de sauvegarde, vous devez le tester. Tout d'abord, toutes les sauvegardes doivent être testées, cryptées ou non. Les sauvegardes peuvent ne pas être complètes ou peuvent souffrir d'un certain type de corruption. Vous ne pouvez pas être sûr que votre sauvegarde peut être restaurée tant que vous n'avez pas réellement effectué la restauration. C'est pourquoi la vérification régulière des sauvegardes est indispensable. Le chiffrement ajoute plus de complexité au processus de sauvegarde. Des problèmes peuvent à nouveau apparaître au moment du cryptage - des bogues ou des problèmes peuvent corrompre les fichiers cryptés. Une fois chiffré, la question est alors de savoir s'il est possible de le déchiffrer et de le restaurer ?
Vous devriez avoir un processus de test de restauration en place. Idéalement, le test de restauration serait exécuté après chaque sauvegarde. Au minimum, vous devez tester vos sauvegardes plusieurs fois par an. Vous devez certainement le tester dès qu'un changement dans le processus de sauvegarde a été introduit. Avez-vous ajouté une compression à la sauvegarde ? Avez-vous changé la méthode de cryptage ? Avez-vous fait pivoter la clé de chiffrement ? Toutes ces actions peuvent avoir un impact sur votre capacité à restaurer réellement votre sauvegarde. Par conséquent, vous devez vous assurer de tester l'ensemble du processus après chaque modification.
ClusterControl peut automatiser le processus de vérification, à la demande ou programmé après chaque sauvegarde.
Pour vérifier une sauvegarde existante, il vous suffit de choisir celle dans la liste, de cliquer sur l'option "Restaurer", puis de passer par l'assistant de restauration. Tout d'abord, vous devez vérifier quelle sauvegarde vous souhaitez restaurer.
Ensuite, à l'étape suivante, vous devez choisir l'option de restauration et de vérification.
Vous devez transmettre des informations sur l'hôte sur lequel vous souhaitez tester la restauration. Il doit être accessible via SSH depuis l'instance ClusterControl. Vous pouvez décider de garder le serveur de test de restauration opérationnel (puis d'en vider certaines données partielles si vous souhaitez effectuer une restauration partielle) ou de l'arrêter.
La dernière étape consiste à vérifier si vous avez fait les bons choix. Si oui, vous pouvez démarrer la tâche de vérification de la sauvegarde.
Si la vérification s'est déroulée avec succès, vous verrez que la sauvegarde est marquée comme vérifiée dans la liste des sauvegardes.
Si vous souhaitez automatiser ce processus, c'est également possible avec ClusterControl. Lors de la planification de la sauvegarde, vous pouvez activer la vérification de la sauvegarde :
Cela ajoute une autre étape dans l'assistant de planification de sauvegarde.
Là encore, vous devez définir l'hôte que vous souhaitez utiliser pour les tests de restauration de sauvegarde, décider si vous souhaitez installer le logiciel dessus (ou peut-être l'avez-vous déjà fait), si vous souhaitez maintenir le serveur de restauration actif et si vous voulez tester la sauvegarde immédiatement après qu'elle soit terminée ou peut-être voulez-vous attendre un peu.
