Recomendación para implementar una base de datos MySQL cifrada

Problemas potenciales -

• Debe asegurarse de usar SSL; de lo contrario, las claves se envían en texto sin formato.
• Su código va a estar lleno de llamadas cifradas / descifradas. También existe la sobrecarga de inyectar la clave y enviarla cada vez que, si la red es su cuello de botella, podría reducir considerablemente la capacidad.
• Las claves deben estar en la aplicación web y se envían constantemente al servidor DB. Esto significa dos puntos de falla en lugar de uno.
• Esto se basa en que los desarrolladores estén atentos. Si en algún momento alguien agrega un método que envía / recibe datos sin las llamadas, entonces se quedará allí en texto sin formato.
• Es posible que algunos datos no puedan cifrarse de esta manera sin paralizar el rendimiento de la base de datos, ya que ya no puede mirar los valores directamente o almacenarlos en un orden lógico.
• La depuración se vuelve mucho más difícil. Consultar el DB para ver qué está almacenado allí ya no es trivial.

  

Estoy pensando que sería trivial volver a cifrar todos los valores con una nueva frase de contraseña

¿Cuántos datos esperas tener? "Trivial" a menudo no se escala. Esto podría implicar desconectar todo el sistema durante un período prolongado de tiempo.

Parece que su objetivo es no confiar en la base de datos con el conocimiento de los datos originales. Si eso es correcto, entonces necesitaría cifrar / descifrar en la otra máquina, NO en MySQL. Si usa MySql para cifrar / descifrar, confía en MySQL con el acceso a los datos originales (y la clave), por lo tanto, está superando el objetivo.

Antes de diseñar la solución, te sugiero que bosquejas el modelo de amenaza que te interesa. Cada mitigación debe abordar completamente algo en ese modelo de amenaza. Recuerde, incluso las cercas bajas son más útiles que los postes realmente altos que espera que su adversario elija para usted. Los modelos de amenazas ayudan a identificar las brechas en esa cerca (como dar acceso de base de datos a las claves y al texto sin formato).

  

Mi idea es utilizar el cifrado a nivel de la aplicación y almacenar valores cifrados explícitos en la base de datos.

Solo podrá realizar una recuperación indexada en claves hash con coincidencias explícitas. Es un diseño de base de datos muy muy inusual en el que es un enfoque viable, y en ese caso, no tiene mucho sentido usar una base de datos relacional, no importa una versión de MySQL de 10 años. Esencialmente, su base de datos se reduce a un elegante almacén de clave-valor.

Esto solo funcionará si su aplicación está diseñada específicamente para operar en una base de datos con tales características.

Me pregunto cuál es el modelo de amenaza que merece este enfoque. Si crees que puedes proteger los datos contra un usuario root malicioso, estás muy equivocado.

Si fuera yo, estaría desafiando estos requisitos y tratando de ver si se puede cumplir el objetivo utilizando el cifrado de base de datos nativo (actualmente estoy más actualizado con el Implementación de MariaDB de esto por MySQL) o las instalaciones del sistema operativo (LUKS, FUSE).