sql >> Base de Datos >  >> RDS >> MariaDB

Cifrado de copia de seguridad de la base de datos:prácticas recomendadas

El almacenamiento de respaldo externo debe ser una parte fundamental del plan de recuperación ante desastres de cualquier organización. La capacidad de almacenar datos en una ubicación física separada, donde podría sobrevivir a un evento catastrófico que destruya todos los datos en su centro de datos principal, garantiza la supervivencia de sus datos y la continuidad de su organización. Un servicio de almacenamiento en la nube es un método bastante bueno para almacenar copias de seguridad externas. No importa si está utilizando un proveedor de la nube o si solo está copiando datos a un centro de datos externo, el cifrado de respaldo es imprescindible en tales casos. En uno de nuestros blogs anteriores, discutimos varios métodos para cifrar sus copias de seguridad. Hoy nos centraremos en algunas prácticas recomendadas sobre el cifrado de copias de seguridad.

Asegúrese de que sus secretos estén seguros

Para cifrar y descifrar sus datos, debe utilizar algún tipo de contraseña o clave. Según el método de cifrado (simétrico o asimétrico), puede ser un secreto tanto para el cifrado como para el descifrado o puede ser una clave pública para el cifrado y una clave privada para el descifrado. Lo que es importante, debes mantenerlos a salvo. Si utiliza el cifrado asimétrico, debe centrarse en la clave privada, la que utilizará para descifrar las copias de seguridad.

Puede almacenar claves en un sistema de administración de claves o en una bóveda:existen numerosas opciones en el mercado para elegir, como KMS de Amazon o la Bóveda de Hashicorp. Incluso si decide no utilizar esas soluciones, aún debe aplicar prácticas de seguridad genéricas como garantizar que solo los usuarios correctos puedan acceder a sus claves y contraseñas. También debe considerar preparar sus scripts de respaldo de manera que no exponga claves o contraseñas en la lista de procesos en ejecución. Idealmente, póngalos en el archivo en lugar de pasarlos como argumento a algunos comandos.

Considere el cifrado asimétrico

La principal diferencia entre el cifrado simétrico y el asimétrico es que, al utilizar el cifrado simétrico tanto para el cifrado como para el descifrado, utiliza una sola clave o contraseña. Esto requiere estándares de seguridad más altos en ambos extremos del proceso. Debe asegurarse de que el host en el que cifra los datos sea muy seguro, ya que una fuga de la clave de cifrado simétrica permitirá el acceso a todas sus copias de seguridad cifradas.

Por otro lado, si usa el cifrado asimétrico, tiene dos claves:la clave pública para cifrar los datos y la clave privada para descifrar. Esto hace que las cosas sean mucho más fáciles:realmente no tiene que preocuparse por la clave pública. Incluso si se viera comprometido, no permitirá ningún tipo de acceso a los datos de las copias de seguridad. Debe centrarse únicamente en la seguridad de la clave privada. Es más fácil:lo más probable es que cifre las copias de seguridad diariamente (si no con más frecuencia) mientras que la restauración se realiza de vez en cuando, lo que hace factible almacenar la clave privada en una ubicación más segura (incluso en un dispositivo físico dedicado). A continuación se muestra un ejemplo muy rápido de cómo puede usar gpg para generar un par de claves y usarlo para cifrar datos.

Primero, tienes que generar las claves:

[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.

Esto creó claves públicas y privadas. A continuación, desea exportar su clave pública para usarla para cifrar los datos:

gpg --armor --export [email protected] > mybackupkey.asc

A continuación, puede usarlo para cifrar su copia de seguridad.

[email protected]:~# xtrabackup  --backup --stream=xbstream  | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backup

Finalmente, un ejemplo de cómo puede usar su clave principal (en este caso, está almacenada en el anillo de claves local) para descifrar sus copias de seguridad:

[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]>"

Rote sus claves de cifrado

No importa qué tipo de cifrado haya implementado, simétrico o asimétrico, debe pensar en la rotación de claves. En primer lugar, es muy importante contar con un mecanismo para girar las llaves. Esto podría ser útil en caso de una violación de seguridad, y tendría que cambiar rápidamente las claves que usa para el cifrado y descifrado de copias de seguridad. Por supuesto, en caso de una violación de la seguridad, debe considerar qué sucederá con las copias de seguridad antiguas que se cifraron con claves comprometidas. Se han visto comprometidos, aunque aún pueden ser útiles y necesarios según el objetivo del punto de recuperación. Hay un par de opciones que incluyen volver a cifrarlos o moverlos a una localización no comprometida.

Acelere el proceso de cifrado poniéndolo en paralelo

Si tiene la opción de implementar la paralelización del proceso de cifrado, considérelo. El rendimiento del cifrado depende principalmente de la potencia de la CPU, por lo que permitir que más núcleos de CPU trabajen en paralelo para cifrar el archivo debería resultar en tiempos de cifrado mucho más cortos. Algunas de las herramientas de encriptación dan esa opción. Uno de ellos es xtrabackup, que tiene una opción para usar cifrado integrado y paralelizar el proceso.

Lo que está buscando son las opciones "--encrypt-key" o "--encrypt-key-file" que permiten el cifrado integrado. Mientras lo hace, también puede definir "--encrypt-threads" y "--encrypt-chunk-size". En segundo lugar, aumenta un búfer de trabajo para el cifrado, primero define cuántos subprocesos se deben usar para el cifrado.

Por supuesto, esta es solo una de las soluciones que puede implementar. Puede lograr esto usando herramientas de shell. Un ejemplo a continuación:

[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{}"'

Esta no es una solución perfecta, ya que debe saber de antemano qué tan grande, más o menos, será la copia de seguridad para dividirla en una cantidad predefinida de archivos que coincidan con el nivel de paralelización que desea lograr (si desea usar 2 CPU núcleos, debe tener dos archivos, si desea usar 4 núcleos, 4 archivos, etc.). También requiere espacio en disco que es el doble del tamaño de la copia de seguridad, ya que al principio genera múltiples archivos utilizando la división y luego el cifrado crea otro conjunto de archivos cifrados. Por otro lado, si el tamaño de su conjunto de datos es aceptable y le gustaría mejorar el rendimiento del cifrado, esa es una opción que puede considerar. Para descifrar la copia de seguridad, deberá descifrar cada uno de los archivos individuales y luego usar 'cat' para unirlos.

Pruebe sus copias de seguridad

No importa cómo vaya a implementar el cifrado de respaldo, debe probarlo. En primer lugar, todas las copias de seguridad deben probarse, cifradas o no. Es posible que las copias de seguridad no estén completas o que sufran algún tipo de corrupción. No puede estar seguro de que su copia de seguridad se pueda restaurar hasta que realmente realice la restauración. Es por eso que la verificación periódica de copias de seguridad es imprescindible. El cifrado agrega más complejidad al proceso de copia de seguridad. Los problemas pueden aparecer en el momento del cifrado, nuevamente:los errores o fallas pueden dañar los archivos cifrados. Una vez cifrado, la pregunta es si es posible descifrarlo y restaurarlo.

Debe tener un proceso de prueba de restauración en su lugar. Idealmente, la prueba de restauración se ejecutaría después de cada copia de seguridad. Como mínimo, debe probar sus copias de seguridad un par de veces al año. Definitivamente, debe probarlo tan pronto como se haya introducido un cambio en el proceso de copia de seguridad. ¿Ha agregado compresión a la copia de seguridad? ¿Cambió el método de encriptación? ¿Rotaste la clave de cifrado? Todas esas acciones pueden tener algún impacto en su capacidad para restaurar su copia de seguridad. Por lo tanto, debe asegurarse de probar todo el proceso después de cada cambio.

ClusterControl puede automatizar el proceso de verificación, ya sea bajo demanda o programado después de cada copia de seguridad.

Para verificar una copia de seguridad existente, solo necesita elegir una de la lista, hacer clic en la opción "Restaurar" y luego pasar por el asistente de restauración. Primero, debe verificar qué copia de seguridad desea restaurar.

Luego, en el siguiente paso, debe elegir la opción restaurar y verificar.

Debe pasar cierta información sobre el host en el que desea probar la restauración. Tiene que ser accesible a través de SSH desde la instancia de ClusterControl. Puede decidir mantener el servidor de prueba de restauración en funcionamiento (y luego descargar algunos datos parciales si desea realizar una restauración parcial) o apagarlo.

El paso final se trata de verificar si tomó las decisiones correctas. En caso afirmativo, puede iniciar el trabajo de verificación de la copia de seguridad.

Si la verificación se completó con éxito, verá que la copia de seguridad está marcada como verificada en la lista de copias de seguridad.

Si quieres automatizar este proceso, también es posible con ClusterControl. Al programar la copia de seguridad, puede habilitar la verificación de la copia de seguridad:

Esto agrega otro paso en el asistente de programación de copias de seguridad.

Aquí nuevamente debe definir el host que desea usar para las pruebas de restauración de copias de seguridad, decidir si desea instalar el software en él (o tal vez ya lo haya hecho), si desea mantener el servidor de restauración activo y si desea probar la copia de seguridad inmediatamente después de que se complete o tal vez desee esperar un poco.