La seguridad de la base de datos no es tan segura

Question

Cierta información altamente confidencial (información de pago, nombres de usuario, contraseñas, etc.) debe cifrarse antes de que se pueda conservar en mi base de datos.

Más tarde, esa información debe descifrarse para poder recuperarla de la persistencia y utilizarla en otro momento.

Si utilizo, por ejemplo, AES256 para encriptar una dirección de facturación, igual voy a tener que almacenar esa clave/contraseña AES256 también en persistencia.

Si el objetivo de cifrar la información que entra en una base de datos es proteger esa información en caso de que alguien piratee mi base de datos y almaceno la clave para descifrar esa misma información en la base de datos, ¿cuál es el punto de encriptar los datos en primer lugar?

Si alguien piratea mi base de datos, podrán encontrar la clave persistente y descifrar cualquier dato cifrado que quieran de todos modos.

¿Falta algo aquí?

Answer 1

Una mejor opción sería usar certificados y esto se puede hacer fácilmente en la mayoría de los RDBMS.

Answer 2

La mejor opción con respecto a las contraseñas es cortarlas. Este es un hash de una sola dirección, y no se descifra. Básicamente, cuando un usuario inicia sesión, tiene su contraseña de entrada y compara el hash con el almacenado en su base de datos para una coincidencia y un inicio de sesión exitoso.

Con respecto a la información de pago, necesitará una clave privada generada al azar. Dependiendo del sistema y la implementación, esto se puede almacenar de diferentes maneras. Puede almacenar esto en un archivo de configuración, encriptado usando un contenedor RSA por ejemplo para que no sea legible. También hay otras soluciones.

También puede encriptar cadenas de conexión de db y similares con el método de contenedor RSA anterior para evitar que alguien realmente lo vea db nombre de usuario contraseña que su aplicación utilizará para acceder a la base de datos.

Answer 3

Hay un viejo refrán "El cifrado es fácil, la administración de claves es difícil". Y eso aplica mucho aquí.

Si necesita almacenar datos en un formato cifrado (con frecuencia no lo hace porque solo necesita cifrar los datos para no cifrarlos), no desea que la clave de cifrado se almacene en la base de datos. Desea que la clave esté accesible cuando sus aplicaciones necesitan descifrar los datos, pero no desea que personas como el DBA que tiene acceso a todos los datos cifrados puedan obtener la clave. Desea asegurarse de que la clave esté respaldada para que pueda recuperar los datos, pero no desea que esas copias de seguridad se combinen con las copias de seguridad de la base de datos. La gestión clave, por lo tanto, se convierte en un problema muy espinoso de resolver.

En la gran mayoría de los casos, desea comprar una solución de gestión de claves de terceros que pueda hacer frente a estas contradicciones. Al igual que no desea implementar algoritmos de cifrado por su cuenta, no desea realizar la administración de claves por su cuenta. Las personas que intentan resolver la gestión de claves por su cuenta generalmente no tienen éxito.