La sécurisation de vos données est l'une des tâches les plus importantes que nous devrions prioriser. L'émergence de réglementations exigeant la conformité en matière de sécurité telles que GDPR, HIPAA, PCI DSS ou PHI exige que vos données soient stockées en toute sécurité ou transmises par câble.
Chez ClusterControl, nous apprécions l'importance de la sécurité et offrons un certain nombre de fonctionnalités pour sécuriser l'accès à la base de données et les données stockées. L'une d'elles consiste à sécuriser les sauvegardes de votre base de données, à la fois au repos et en transit. En transit, c'est lorsque la sauvegarde est transférée via Internet ou le réseau de la source à sa destination, tandis qu'au repos, c'est lorsque les données sont stockées sur un stockage persistant. Dans ce blog, nous vous montrerons comment vous pouvez utiliser ClusterControl pour chiffrer vos données de sauvegarde au repos et en transit.
Chiffrement en transit
Lors de la gestion des sauvegardes via ClusterControl, l'utilisation de mysqldump ou Percona Xtrabackup/Mariabackup est gérée par défaut sans chiffrement lorsqu'elle est transmise via le câble. Cependant, l'utilisation de TLS/SSL pour le cryptage de la transmission de données est prise en charge par MySQL/MariaDB/Percona Server, tout comme Percona Xtrabackup qui offre des options SSL lors de l'appel de la commande.
ClusterControl active SSL par défaut lorsque vous déployez un cluster, mais il n'a pas le contrôle pour basculer instantanément et chiffrer vos données sur le réseau lors de la création de la sauvegarde. Vous pouvez consulter nos blogs précédents pour l'approche manuelle utilisant ClusterControl lors de la création de votre cluster ou en utilisant l'ancienne méthode pour configurer manuellement TLS/SSL dans MySQL.
Dans ClusterControl, lorsque vous déployez un cluster, vous pouvez cocher l'onglet sécurité ou cette icône 
.
En cliquant sur le Le bouton 
vous permettra de remplacer le certificat actuellement utilisé ou déployé par ClusterControl lors du déploiement de votre nouveau provisionné groupe. Vous pouvez consulter ce blog "Mise à jour :Devenir un DBA ClusterControl - SSL Key Management and Encryption of MySQL Data in Transit" pour lequel nous avons montré comment nous gérons les clés. Fondamentalement, vous pouvez passer par la navigation de gauche du ClusterControl et cliquer sur "Gestion des clés".
Vous trouverez ci-dessous un exemple de gestion des clés dans lequel vous pouvez créer et importer vos clés existantes.
Lors de la création d'une sauvegarde en utilisant mysqldump comme sauvegarde logique, pour chiffrer vos données, assurez-vous que vos options SSL sont définies en conséquence.
Quelle est la prochaine ?
Puisque nous avons nos certificats créés, nous devons activer et configurer SSL en conséquence. Pour vous en assurer, vous pouvez vérifier via ClusterControl ou l'invite de commande mysql. Voir les images ci-dessous :
ou vous pouvez également vérifier sous l'onglet Performances et cliquer sur Variables DB comme indiqué ci-dessous :
Notez que le remplissage sous Performances -> Variables de base de données peut prendre un certain temps. Donc, si vous voulez vérifier manuellement, vous pouvez utiliser l'invite de commande mysql comme ci-dessous :
Définir votre ssl_cipher peut renforcer davantage la sécurité. Il y a une liste de suite de chiffrement si vous exécutez SHOW GLOBAL STATUS LIKE ‘Ssl_cipher_list’\G ou vérifiez ici. Une suite de chiffrement est une combinaison d'algorithmes d'authentification, de chiffrement et de code d'authentification de message (MAC). Ceux-ci sont utilisés lors de la négociation des paramètres de sécurité pour une connexion TLS/SSL ainsi que pour le transfert sécurisé des données.
Étant donné que ClusterControl exécutera mysqldump localement sur cet hôte, ajoutez les paramètres suivants (voir ci-dessous) dans votre fichier de configuration MySQL (/etc/my.cnf, /etc/mysql/my.cnf, /usr/etc/my.cnf, ~ /.my.cnf) chiffrera toutes les actions pour le vidage SQL. Voir ci-dessous :
[mysqldump]
socket=/var/lib/mysql/mysql.sock
max_allowed_packet = 512M
host=127.0.0.1
ssl-cert=/var/lib/mysql/client-cert.pem
ssl-key=/var/lib/mysql/client-key.pemVous pouvez essayer de surveiller à l'aide de tcpdump et vous pouvez voir ci-dessous une comparaison entre une couche non chiffrée et une couche chiffrée à l'aide de TLS.
Avec TLS/SSL :
Sans TLS/SSL :
Lorsque vous utilisez Percona XtraBackup ou Mariabackup sous ClusterControl, il n'y a pas de prise en charge TLS/SSL à ce moment-là lorsque la sauvegarde est transmise sur le réseau. Il utilise socat qui ouvre simplement un port dans un autre nœud comme moyen de communication.
par exemple
[21:24:46]: 192.168.10.20: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | socat - TCP4:192.168.10.200:9999 ) 2>&1.
[21:24:46]: 192.168.10.20: The xtrabackup version is 2.4.12 / 2004012.
[21:24:46]: 192.168.10.20:3306: Checking xtrabackup version.
[21:24:46]: 192.168.10.20: Streaming backup to 192.168.10.200
[21:24:46]: 192.168.10.200: Netcat started, error log is in '192.168.10.200:/tmp/netcat.log'.
[21:24:43]: 192.168.10.200: Starting socat -u tcp-listen:9999,reuseaddr stdout > /home/vagrant/backups/BACKUP-71/backup-full-2018-11-12_132443.xbstream.gz 2>/tmp/netcat.log.Si vous avez besoin d'une couche sécurisée pendant le transport, vous pouvez le faire manuellement en utilisant les options --ssl* lors de l'invocation de la commande. Consultez ici le manuel Percona XtraBackup pour plus d'informations. Nous vous recommandons toujours d'obtenir votre certificat/clé auprès d'une autorité de certification enregistrée.
Alternativement, en utilisant ClusterControl, vous pouvez crypter vos données avant de les envoyer via le réseau, les paquets envoyés ne sont pas des données brutes mais cryptées. Bien que le chiffrement repose sur au repos, nous en discuterons dans la section suivante à ce sujet.
Chiffrement au repos
Dans ClusterControl, lors de la création de votre sauvegarde, vous avez la possibilité de chiffrer vos données. Voir ci-dessous :
Une fois crypté, ClusterControl utilisera "Advance Encryption Standard" AES-256-CBC. Voir l'exemple de journal ci-dessous :
[22:12:49]: 192.168.10.30: Launching ( ulimit -n 256000 && LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-002471-32758-24c456ca6b087837.tmp | socat - TCP4:192.168.10.200:9999 ) 2>&1.Si vous stockez votre sauvegarde dans le cloud, par exemple avec AWS S3, S3 propose trois modes différents de chiffrement côté serveur (SSE). Il s'agit de SSE-S3, SSE-C ou SSE-KMS. Amazon propose d'excellentes fonctionnalités SSE qui gèrent le chiffrement des données au repos. Vous pouvez commencer ici qui aborde la façon dont S3 utilise AWS KMS. Si vous déplacez votre sauvegarde vers un volume ou un stockage basé sur des blocs, AWS dispose également du chiffrement EBS à l'aide d'AWS KMS. Vous pouvez vérifier ici pour plus d'informations à ce sujet.
Microsoft Azure propose également des fonctionnalités intéressantes lors de la gestion des données au repos. Consultez la page sur « Chiffrement du service de stockage Azure pour les données au repos ». Azure gère les clés dans leur Azure Key Vault, comme AWS KMS. Pour le chiffrement Google des données au repos, vous pouvez vérifier ici.
Lors du stockage de sauvegardes de données sur site, vous pouvez utiliser LUKS (Linux Unified Key Setup) avec une combinaison de crypt ou dmcrypt. Je n'en parlerai pas sur ce blog mais c'est une bonne source à consulter :MySQL Encryption at Rest - Part 1 (LUKS). Pour plus d'informations sur le chiffrement de disque, cette page ArchLinux "Chiffrement de disque" est une excellente source pour commencer.
Plus important encore, pendant que vos données ont été chiffrées au repos et en transit, vérifiez toujours que votre sauvegarde fonctionne. Une sauvegarde qui n'a pas été testée n'est pas une sauvegarde si elle ne fonctionne pas lorsqu'une restauration est nécessaire. Le stockage de votre sauvegarde ainsi que le chiffrement doit être déchiffré sans aucun problème, ainsi, vos clés doivent être stockées de manière privée et de la manière la plus sécurisée possible. De plus, l'ajout de cryptage à vos données, comme le cryptage InnoDB ou SST (pour Galera), ajoute plus de sécurité, mais nous ne les couvrirons pas dans ce blog.
Conclusion
Le chiffrement des données de sauvegarde au repos et en transit est un élément essentiel pour la conformité aux PHI, HIPAA, PCI DSS ou GDPR, afin de garantir que les données sensibles transmises par câble ou enregistrées sur des disques ne sont pas lisibles par un utilisateur ou une application sans clé valide. Certaines réglementations de conformité telles que PCI DSS et HIPAA exigent que les données au repos soient chiffrées tout au long du cycle de vie des données.
Ici, nous montrons comment ClusterControl offre ces options à l'utilisateur final. La conformité est une tâche énorme, touchant de nombreux domaines différents. Les réglementations sont également mises à jour fréquemment, et les processus/outils doivent également être mis à jour en conséquence. Nous améliorons continuellement différents domaines de ClusterControl pour faciliter la conformité. Nous aimerions connaître votre avis à ce sujet et savoir comment nous pouvons nous améliorer.
