Cifrado en reposo y/o AES_ENCRYPT

Cifrado en reposo

El cifrado en reposo son los datos de la base de datos cuando no se utilizan, no se accede a ellos ni se actualizan. El cifrado en movimiento es cosas como TLS donde los datos (de la base de datos ) se transporta de servidor a servidor, a navegador, a servidor, a navegador, etc. TLS es perfectamente bueno en la mayoría de las situaciones si se maneja con cuidado y se aborda con la actitud de que debe hacer más que lo mínimo para hacerlo realmente seguro.

Un ejemplo típico es el de las personas que colocan un certificado TLS de LetsEncrypt en su dominio y piensan que, de repente, todas sus cosas están seguras; pero no cifran sus sesiones ni sus cookies dejando un gran agujero potencial en sus defensas.

No utilice el sistema de cifrado integrado de MySQL.

No puedo enfatizar esto lo suficiente; el sistema de encriptación incorporado en MySQL no es adecuado para la protección de datos segura real.

Lea mi respuesta a una pregunta muy similar aquí en cuanto a los detalles (No quiero simplemente copiar/pegar ).

Vale, entonces, porque insistes.... aquí:

Por lo que he leído en mi propia investigación sobre este tema, el enlace proporcionado por Magnus a defuse/php -cifrado es una de las mejores formas de evitar que MySQL haga que comprometa sus datos, ya que nunca permite que el programa/servidor MySQL vea el valor de texto sin formato de sus datos.

-- Respuesta publicada el 7 de mayo de 2017.

También La respuesta de Bill Karwin a la misma pregunta brinda información valiosa adicional:

-- Respuesta publicada el 7 de mayo de 2017.

Punto de Cierre:

La seguridad es compleja. Si desea hacerlo correctamente y confiar en sus cáscaras de cebolla protectoras, debe hacer muchas cosas (consulte las viñetas a continuación); pero lo primero que debes hacer es:

• Defina de quién se está protegiendo

En serio. Necesita diferentes estrategias contra alguien que quiere robar sus nombres y direcciones de texto sin formato frente a alguien que quiere hacerse cargo de su servidor frente a alguien que simplemente quiere destruir los datos porque sí. Es un mito que puedes protegerte contra todos todo el tiempo, por concepto esto es imposible*; por lo que debe definir los agresores más probables y luego determinar la mejor manera de mitigar sus avances.

Específicamente a MySQL, algunas recomendaciones claras:

• Mantenga el SQL y el PHP en el mismo servidor. No acceda de forma remota a los datos de MySQL.

• Excluya el acceso externo al SQL (por lo que es localhost solo)

• Ofusque los nombres de sus tablas y columnas; si alguien accede a tus datos y tienes HDTBJ^BTUETHNUYT debajo de la columna username entonces saben que esta confusión es probablemente un nombre de usuario, por lo que tienen un muy buen comienzo para intentar descifrar su encriptación.

• IMPORTANTE :Realmente bloquee el acceso a su mesa; configurar muchos usuarios de MySQL, cada uno con los privilegios mínimos para hacer lo que necesita; desea que un usuario lea la tabla (solo ) y solo lee ciertas tablas; los usuarios pueden escribir en ciertas tablas pero no tienen acceso a otras tablas. Es una preocupación de separación, de modo que si un usuario en MySQL se ve comprometido; no ha perdido automáticamente todos los datos que contiene.

• Utilice los servicios de cifrado de PHP. Guarde las claves de cifrado en un lugar completamente separado; por ejemplo, tenga otro servidor que use únicamente para la copia de seguridad al que pueda acceder únicamente para obtener las claves de cifrado, por lo tanto, si su servidor PHP/MySQL está comprometido, tiene algo de espacio para cortar y bloquear el servidor de claves para que pueda limitar el daño. Si el servidor de claves también tiene copias de seguridad, entonces realmente no está demasiado comprometido (depende de la situación ).

• Configure muchos observadores e informantes por correo electrónico para que le digan exactamente cuándo se están ejecutando ciertos procesos y qué usuarios del servidor (no personas sino programas) están haciendo qué. Entonces puede ver por qué un proceso inesperado comienza a ejecutarse a las 5 am para intentar medir el tamaño de las tablas MySQL. ¿Qué diablos?

• Existe un gran potencial para que sus datos MySQL AES_ENCRYPT sean "olfateados" incluso si no están en reposo en la base de datos, pero si el sitio web se ve comprometido (o peor aún, el código PHP es inseguro), entonces los ataques de sincronización pueden funcionar. contenidos de datos sincronizando búsquedas de consultas y devoluciones de paquetes de datos.

• La seguridad es un agujero negro; en un momento u otro vas a pensar "Al diablo con esto, ya he hecho suficiente". Nadie tiene nunca seguridad total, algunas organizaciones muy dedicadas tienen suficiente seguridad. Tienes que calcular cuánto estás dispuesto a caminar antes de recorrer la distancia.

* ¿Por qué imposible? Porque para proteger sus datos de todas las amenazas, todo el tiempo, tendría que ser ilegible, inutilizable, como un hash. Un hash está protegido de todos, todo el tiempo. Pero un hash nunca se puede deshacer.