Cifrado de nuestras copias de seguridad: llegar a esa línea de meta

Nota: Esta publicación de ingeniería fue escrita por nuestra Administradora de Base de Datos, Silvia Botros. Echa un vistazo a algunas de sus otras publicaciones de DBA aquí.

Hace un año, SendGrid estaba trabajando arduamente para obtener la certificación SOC2. Todos estaban involucrados. Hubo historias en casi todos los tableros del equipo de entrega con una etiqueta SOC2, ya que todos buscábamos obtener la certificación para fines del tercer trimestre. Como puede imaginar, siendo la persona a cargo de las bases de datos, definitivamente había trabajo por hacer para esa parte de la pila.

En mi lista de tareas para este esfuerzo de toda la empresa estaba asegurarme de que nuestras copias de seguridad estuvieran encriptadas. Dado que mi área de familiaridad son las herramientas DBA y sabiendo que xtrabackup de Percona ya tiene soporte para encriptación, era predecible que lo hiciera como el primer intento de esta tarea.

Algunas cosas importantes estaban en mi punto de mira al probar este enfoque:

• Obviamente, la copia de seguridad necesitaba estar encriptada
• Los gastos generales para crear la copia de seguridad debían ser conocidos y aceptables
• La sobrecarga para descifrar la copia de seguridad en el momento de la recuperación debía ser conocida y aceptable

Eso significaba que, en primer lugar, necesitaba poder realizar un seguimiento del tiempo que tardan mis copias de seguridad.

Seguimiento del tiempo de copia de seguridad

SendGrid usa Graphite para sus métricas de infraestructura y, aunque la gran mayoría se envía a través de Sensu, Graphite es lo suficientemente fácil como para enviar métricas directamente a través de líneas bash, muy conveniente ya que los scripts de respaldo están en bash. Tenga en cuenta que enviar métricas a Graphite directamente no es muy escalable, pero dado que estas copias de seguridad se ejecutan como máximo una vez por hora, estuvo bien para mis necesidades.

Esa parte resultó ser relativamente fácil.

Para explicar lo que sucedió en esa última línea, le envío a Graphite la ruta de la métrica que estoy enviando (asegúrate de que sea única), el valor de la métrica y luego la hora actual en formato de época. Netcat es lo que decidí usar por simplicidad, y le doy un tiempo de espera de 1 segundo porque, de lo contrario, nunca se cerrará. La `URL de Graphite` es nuestro punto final de DNS para Graphite en el centro de datos.

Ahora que tenía una línea de base para comparar, estábamos listos para comenzar a probar los métodos de encriptación.

Siguiendo la documentación detallada de Percona sobre cómo hacer esto, comencé haciendo una clave. Si lee atentamente esa página de documentación, es posible que se dé cuenta de algo.

Esta clave debe pasarse directamente a la herramienta de copia de seguridad y es la misma clave que puede descifrar la instantánea. Eso se llama cifrado simétrico y es, por la naturaleza de esa misma clave en ambas direcciones, menos seguro que el cifrado asimétrico. Decidí continuar probando para ver si la simplicidad todavía hace que este sea un enfoque viable.

Las pruebas con bases de datos muy pequeñas, unos pocos cientos de MB, fueron exitosas. La herramienta funciona como se esperaba y está documentada, pero eso fue más una prueba funcional y la verdadera pregunta era "¿cuál es el tamaño de la penalización del cifrado en nuestras bases de datos más grandes?" Las instancias más heredadas en SendGrid habían crecido a tamaños de 1-2 TB a una sola bestia de 18 TB. Lo que iba a usar para las instancias pequeñas también tenía que ser aceptable desde el punto de vista operativo en las más grandes.

Aquí es donde las pruebas y los puntos de referencia se pusieron interesantes

Mi primer sujeto de prueba de un tamaño considerable es una base de datos que tenemos de 1 TB en el disco. Muy rápidamente me encontré con un problema inesperado. Con una configuración de cifrado mínima (1 subproceso, tamaños de fragmentos predeterminados), vi que las copias de seguridad fallaban con este error:

En ese momento, estas bases de datos usaban 512 MB como tamaño de archivo de registro de transacciones, y este es un clúster bastante ocupado, por lo que esos archivos rotaban casi cada minuto. Normalmente, esto se notaría en el rendimiento de la base de datos, pero en su mayoría estaba enmascarado por la maravilla de las unidades de estado sólido. Parece que no configurar ningún hilo de cifrado paralelo (léase: usar uno) significa que pasamos tanto tiempo cifrando archivos `.ibd` que el registro de rehacer de innodb debajo de nosotros estaba haciendo que la copia de seguridad se interrumpiera.

Por lo tanto, intentemos esto de nuevo con una serie de subprocesos de cifrado. Como primer intento, probé con 50 hilos. El truco aquí es encontrar el punto ideal del cifrado rápido sin competir por la CPU. También aumenté el tamaño de `ib_logfiles` a 1 GB cada uno.

Esta fue una prueba más exitosa que estaba feliz de dejar preparar durante la noche. Durante las primeras noches, las cosas parecían estar bien. Era hora de hacer una copia de seguridad que no creciera demasiado, pero el promedio de carga de cajas durante el proceso de copia de seguridad definitivamente mostraba los pasos adicionales.

Sin embargo, cuando pasé a probar las restauraciones, descubrí que el proceso de restauración de las mismas copias de seguridad, después de agregar el cifrado, había aumentado de 60 a 280 minutos, lo que significa una penalización severa para nuestro tiempo de recuperación prometido en caso de desastre.

Necesitábamos devolver eso a un marco de tiempo más razonable.

Aquí es donde brillaron el trabajo en equipo y las soluciones más simples a los problemas. Uno de los miembros de nuestro equipo de InfoSec decidió ver si esta solución se puede simplificar. Así que hizo algunas pruebas más y regresó con algo más simple y más seguro. Todavía no había aprendido sobre gpg2 y esto también se convirtió en un ejercicio de aprendizaje para mí.

Lo bueno de gpg2 es que admite cifrado asimétrico. Creamos un par de claves donde hay partes privadas y públicas. La parte pública se usa para cifrar cualquier transmisión o archivo que decidas enviar a gpg2 y el secreto privado se puede usar para descifrar.

El cambio a nuestros scripts de copia de seguridad para agregar cifrado se destiló a esto. Se eliminan algunos argumentos para que sea más fácil de leer:

Por otro lado, al restaurar una copia de seguridad, simplemente debemos asegurarnos de que una clave secreta que sea aceptable esté en el conjunto de claves del host y luego usar este comando:

Como yo también era nuevo en gpg2, esto se convirtió en una oportunidad de aprendizaje para mí. Colin, nuestro increíble miembro del equipo de InfoSec, continuó probando copias de seguridad y restauraciones usando gpg2 hasta que confirmó que usar gpg2 tenía múltiples ventajas en comparación con el uso de la compresión integrada de xtrabackup, que incluyen:

• era asimetrico
• Su gestión secreta para el descifrado se rota con relativa facilidad (más sobre esto a continuación)
• Es independiente de la herramienta, lo que significa que cualquier otro tipo de copia de seguridad que no use xtrabackup podría usar el mismo método.
• Estaba usando múltiples núcleos en el descifrado, lo que nos dio mejores tiempos de restauración

Siempre espacio para mejorar

Un aspecto en el que todavía veo espacio para mejorar es cómo manejamos el secreto que puede descifrar estos archivos. Por el momento, las tenemos en nuestra solución de administración de contraseñas empresariales, pero obtenerlas desde allí y luego usarlas para probar las copias de seguridad es un proceso manual. Lo siguiente en nuestro plan es implementar Vault by Hashicorp y usarlo para extraer la clave secreta para descifrarla sin problemas y en los hosts designados, luego eliminarla del anillo local para que esté fácilmente disponible para pruebas automatizadas y aún protegida.

En última instancia, conseguimos que todas nuestras copias de seguridad de bases de datos cumplieran con nuestras necesidades de SOC2 a tiempo sin sacrificar el rendimiento de las copias de seguridad ni el SLA de recuperación ante desastres. Me divertí mucho trabajando en esta tarea con nuestro equipo de InfoSec y aprendí nuevas herramientas. Además, siempre es bueno cuando la solución más simple termina siendo la más adecuada para la tarea de uno.