Proteger sus datos es una de las tareas más importantes que debemos priorizar. El surgimiento de regulaciones que exigen el cumplimiento de la seguridad, como GDPR, HIPAA, PCI DSS o PHI, requiere que sus datos se almacenen de forma segura o se transmitan por cable.
En ClusterControl, valoramos la importancia de la seguridad y ofrecemos una serie de funciones para proteger el acceso a la base de datos y los datos almacenados. Uno de ellos es asegurar las copias de seguridad de su base de datos, tanto cuando están en reposo como en tránsito. En tránsito es cuando la copia de seguridad se transfiere a través de Internet o la red desde el origen hasta su destino, mientras que en reposo es cuando los datos se almacenan en un almacenamiento persistente. En este blog, le mostraremos cómo puede usar ClusterControl para cifrar sus datos de copia de seguridad en reposo y en tránsito.
Cifrado en tránsito
Al administrar las copias de seguridad a través de ClusterControl, mysqldump o Percona Xtrabackup/Mariabackup se administran de forma predeterminada sin cifrado cuando se transmiten por cable. Sin embargo, el uso de TLS/SSL para el cifrado de la transmisión de datos es compatible con MySQL/MariaDB/Percona Server, al igual que Percona Xtrabackup, que ofrece opciones de SSL al invocar el comando.
ClusterControl habilita SSL de forma predeterminada cuando implementa un clúster, pero no tiene el control para cambiar instantáneamente y cifrar sus datos por cable durante la creación de la copia de seguridad. Puede consultar nuestros blogs anteriores para conocer el enfoque manual usando ClusterControl al crear su clúster o usar la forma antigua de configurar manualmente TLS/SSL en MySQL.
En ClusterControl, cuando implementa un clúster, puede verificar la pestaña de seguridad o este ícono 
.
Al hacer clic en el El botón 
le permitirá reemplazar el certificado que actualmente utiliza o implementa ClusterControl durante la implementación de su recién aprovisionado grupo. Puede consultar este blog "Actualizado:Conviértase en un DBA de ClusterControl - Administración de claves SSL y cifrado de datos MySQL en tránsito" para el cual mostramos cómo manejamos las claves. Básicamente, puede navegar por el lado izquierdo de ClusterControl y hacer clic en "Administración de claves".
A continuación se muestra un ejemplo de administración de claves en el que puede crear e importar sus claves existentes.
Al crear una copia de seguridad usando mysqldump como su copia de seguridad lógica, para encriptar sus datos, asegúrese de tener sus opciones de SSL configuradas en consecuencia.
¿Qué sigue?
Dado que tenemos nuestros certificados creados, debemos habilitar y configurar SSL en consecuencia. Para asegurarse de esto, puede verificar a través de ClusterControl o el símbolo del sistema mysql. Vea las imágenes a continuación:
o puede verificar también en la pestaña Rendimiento y hacer clic en Variables de base de datos como se ve a continuación:
Tenga en cuenta que puede llevar algún tiempo completar en Rendimiento -> Variables de base de datos. Entonces, si desea verificar manualmente, puede usar el símbolo del sistema mysql como se muestra a continuación:
Definir su ssl_cipher puede agregar más seguridad. Hay una lista de conjuntos de cifrado si ejecuta SHOW GLOBAL STATUS LIKE 'Ssl_cipher_list'\G o marca aquí. Un conjunto de cifrado es una combinación de algoritmos de autenticación, cifrado y código de autenticación de mensajes (MAC). Estos se utilizan durante la negociación de la configuración de seguridad para una conexión TLS/SSL, así como para la transferencia segura de datos.
Como ClusterControl ejecutará mysqldump localmente en ese host, agregando los siguientes parámetros (ver más abajo) en su archivo de configuración de MySQL (/etc/my.cnf, /etc/mysql/my.cnf, /usr/etc/my.cnf, ~ /.my.cnf) cifrará cualquier acción para el volcado de SQL. Ver a continuación:
[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.pemPuede intentar monitorear usando tcpdump y puede ver a continuación en comparación con una capa sin cifrar frente a una cifrada con TLS.
Con TLS/SSL:
Sin TLS/SSL:
Al usar Percona XtraBackup o Mariabackup bajo ClusterControl, no hay compatibilidad con TLS/SSL a partir de este momento cuando la copia de seguridad se transmite a través de la red. Utiliza socat, que básicamente solo abre un puerto en otro nodo como medio de comunicación.
por ejemplo
[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 necesita una capa segura durante el transporte, puede hacerlo manualmente usando las opciones --ssl* durante la invocación del comando. Consulte aquí el manual de Percona XtraBackup para obtener más información. Seguimos recomendando obtener su certificado/clave de una autoridad certificadora registrada.
Alternativamente, usando ClusterControl, puede encriptar sus datos antes de enviarlos a través de la red, los paquetes que se envían no son datos sin procesar sino encriptados. Aunque el cifrado se basa en reposo, hablaremos de esto en la siguiente sección.
Cifrado en reposo
En ClusterControl, al crear su copia de seguridad, tiene la opción de cifrar sus datos. Ver a continuación:
Cuando esté cifrado, ClusterControl utilizará el "Estándar de cifrado avanzado" AES-256-CBC. Vea el registro de muestra a continuación:
[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 está almacenando su copia de seguridad en la nube, por ejemplo, con AWS S3, S3 ofrece tres modos diferentes de cifrado del lado del servidor (SSE). Estos son SSE-S3, SSE-C o SSE-KMS. Amazon tiene excelentes funciones de SSE para ofrecer que manejan el cifrado de datos en reposo. Puede comenzar aquí, que aborda cómo S3 usa AWS KMS. Si está moviendo su copia de seguridad a un volumen o almacenamiento basado en bloques, AWS también tiene cifrado EBS utilizando AWS KMS. Puede consultar aquí para obtener más información al respecto.
Microsoft Azure también tiene características geniales cuando maneja datos en reposo. Consulte la página sobre "Cifrado del servicio de Azure Storage para datos en reposo". Azure maneja las claves en su Azure Key Vault, al igual que AWS KMS. Para el cifrado de Google para datos en reposo, puede consultar aquí.
Al almacenar copias de seguridad de datos en las instalaciones, puede usar LUKS (Configuración de clave unificada de Linux) con una combinación de crypt o dmcrypt. No hablaré sobre esto en este blog, pero esta es una buena fuente para consultar:MySQL Encryption at Rest – Part 1 (LUKS). Para obtener más información sobre el cifrado de disco, esta página de ArchLinux "Cifrado de disco" es una excelente fuente para comenzar.
Lo que es más importante, aunque sus datos se hayan cifrado en reposo y en tránsito, verifique siempre que su copia de seguridad funcione. Una copia de seguridad que no se ha probado no es una copia de seguridad si no funciona cuando se necesita la recuperación. El almacenamiento de su copia de seguridad también mientras está encriptado debe descifrarse sin ningún problema, por lo tanto, sus claves deben almacenarse de forma privada y de la manera más segura posible. Además, agregar cifrado a sus datos, como el cifrado InnoDB o SST (para Galera), agrega más seguridad, pero no los cubriremos en este blog.
Conclusión
El cifrado de datos de respaldo en reposo y en tránsito son componentes vitales para el cumplimiento de PHI, HIPAA, PCI DSS o GDPR, para garantizar que ningún usuario o aplicación pueda leer los datos confidenciales transmitidos por cable o guardados en discos sin una clave válida. Algunas normas de cumplimiento, como PCI DSS e HIPAA, exigen que los datos en reposo se cifren durante todo el ciclo de vida de los datos.
Aquí mostramos cómo ClusterControl ofrece estas opciones al usuario final. Sin embargo, el cumplimiento es una tarea enorme que toca muchas áreas diferentes. Los reglamentos también se actualizan con frecuencia, y los procesos/herramientas también deben actualizarse en consecuencia. Estamos mejorando continuamente diferentes áreas en ClusterControl para facilitar el cumplimiento. Nos gustaría escuchar su opinión sobre esto y cómo podemos mejorar.
