¿Cómo puedo proteger los datos en tablas SQL?

Sep 30 2020

Inspirado por las muchas filtraciones de datos donde se filtraron bases de datos / tablas completas con información personal del usuario, ¿cuáles son las mejores prácticas para proteger esos activos? Me preocupa especialmente si alguien pudo obtener acceso al código de backend (que definitivamente no debería ser el caso) y, por lo tanto, adquirir las credenciales de SQL.

Estoy almacenando datos de cuentas personales a los que solo debe acceder el usuario correspondiente.

Mi idea es cifrar los datos de la tabla simétricamente con el nombre de usuario y la contraseña del usuario. Sin embargo, esto lo hace muy difícil al manejar restablecimientos de contraseña ...

¿Hay otras ideas o implementaciones comunes para este escenario?

Respuestas

3 Sjoerd Sep 30 2020 at 15:33

Me preocupa especialmente si alguien pudo obtener acceso al código de backend y, por lo tanto, adquirir las credenciales de SQL.

El sistema de base de datos debe ser accesible desde un número limitado de sistemas. Específicamente, no debería ser accesible desde Internet. Si alguien tiene las credenciales de SQL, todavía no tendrá acceso al servidor.

Las fuentes comunes de fugas son:

  • inyección SQL
  • Servidor no autenticado expuesto, como MongoDB, ElasticSearch
  • Exportar CSV o documento expuesto, por ejemplo, a través de Google Drive
  • Abrir bucket de Amazon S3
  • Exfiltración de datos después del hack

Mi idea es cifrar los datos de la tabla de forma simétrica con el nombre de usuario y la contraseña del usuario.

La mayoría de las aplicaciones web tienen sus datos en texto sin formato en la base de datos y simplemente verifican con la lógica empresarial de la aplicación si un usuario puede acceder a un determinado objeto. Lo que proponga brindaría una mayor seguridad, pero también introduciría más complejidad. Piense si vale la pena.

Sin embargo, esto lo hace muy difícil al manejar restablecimientos de contraseña ...

Al cifrar datos con la contraseña del usuario, esos datos desaparecen cuando el usuario olvida su contraseña. En algunos casos, esto es aceptable y el usuario debe crear una nueva cuenta. De lo contrario, esto a veces se resuelve dándole al usuario una clave de descifrado al configurar su cuenta, que debe imprimir y guardar. Esta es una clave de "puerta trasera" que puede descifrar la cuenta cuando se olvida la contraseña.

Max Oct 01 2020 at 03:49

Quieres proteger los datos. ¿Pero de qué? ¿De quien?
Necesita definir un posible escenario, y luego puede intentar encontrar una forma de protegerse de un peligro específico, de una forma específica en la que un atacante podría intentar robar sus datos.

¿Qué pasa con la piratería física ? ¿Alguien puede entrar y robar su servidor? ¿Alguien puede hacer una copia de los datos en vivo? ¿Alguien puede acceder a las copias de seguridad? ( porque tiene una copia de seguridad , en el sitio, fuera del sitio, y todas esas copias de seguridad están protegidas con contraseña , ¿verdad?)

Si desea cifrar los datos, debe definir a qué nivel desea cifrar los datos .
En ciertos RDBMS , puede cifrar toda la base de datos en el disco y almacenar la clave en el servidor de base de datos. Esto puede protegerlo si alguien roba una copia de los archivos de su base de datos. Pero no lo protegerá si alguien roba las credenciales de DB.
O puede pasar la clave de cifrado con la cadena de conexión, pero este tipo de cosas pueden variar mucho entre diferentes RDBMS.

Puede modificar su aplicación / sitio web para cifrar todos los datos en cada fila / columna de la base de datos .
Ahora tienes mucha seguridad y muchos problemas :

  • ¿Cómo se ordena una tabla de datos cifrados? tu no
  • ¿ Índices de columna ? inútil.
  • ¿Puedes hacer un SELECT ... WHERE Encrypted_Name_Column como '% Fox%' ? no, no puedes.
  • ¿Cómo se cifra una columna de fecha / hora ? ¿Convierte la fecha en una cadena y luego la cifra? Buena suerte descifrando cuando el horario de verano entra en vigor ...
  • ¿Cómo gestiona el IV ( vector de inicialización ) del algoritmo de cifrado? Si encripta los mismos datos, con las mismas claves y el mismo IV, obtendrá la misma salida encriptada. Por lo tanto, es posible que un atacante no pueda descifrar los datos, pero podría detectar que ciertos valores son los mismos , porque los valores cifrados son los mismos.

Puedes hacer todo esto, pero ¿realmente vale la pena?

¿Cómo gestiona las claves de cifrado?
Por lo general, no usa directamente la contraseña para cifrar los datos . Por lo general, genera una clave segura aleatoria para cifrar los datos y luego usa la contraseña para derivar una clave para cifrar la clave que utilizó para los datos.
De esta manera, puede cambiar la contraseña sin necesidad de volver a cifrar todos los datos.
Ahora, si pierde la contraseña, necesita un plan alternativo ... como una copia de la clave de cifrado de datos, cifrada con una contraseña maestra, utilizada solo para restablecer la contraseña. (pero ahora, tiene una contraseña maestra, que puede descifrar todos los datos de todos los usuarios ... ¿dónde los almacena? ¿En un servidor con espacio de aire?)

¿Sería mejor dividir los servicios e intentar reducir la superficie de ataque?
¿Por qué su aplicación / sitio web necesita las credenciales de base de datos? Puede crear una aplicación / sitio web que nunca acceda directamente a la base de datos, sino que solo acceda a los datos a través de un servicio web. El servicio web para acceder a los datos podría estar en un segundo servidor no accesible desde Internet. Las credenciales de la base de datos, utilizadas por el segundo servidor, pueden almacenarse en un tercer servidor y la red puede acceder a ellas con una cuenta específica ...
Puede construir la seguridad capa por capa.

Probablemente solo estoy rascando la superficie, la seguridad del sitio web / aplicación / db es un argumento bastante amplio.