¿Es inútil almacenar datos cifrados en una base de datos?

4

La forma en que lo veo: hay dos formas de cifrar datos para una aplicación web.

1) Almacene una sola clave de cifrado en el servidor y utilícela para cifrar / descifrar datos en tiempo de ejecución. El problema obvio aquí es que si un pirata informático obtiene acceso a su servidor, es solo cuestión de tiempo hasta que encuentre la clave de cifrado y luego se pierda toda esperanza.

2) Use la contraseña de un usuario como clave de cifrado. Sin embargo, parece una mala idea almacenar su contraseña en la información de la sesión, y no funcionaría para aplicaciones colaborativas. Para colaborar, podrías usar un secreto compartido, pero nunca he visto un sitio web que te pida que recuerdes dos contraseñas (una que todos los miembros de la organización conocen).

¿Se supone que debemos ir con el método 1 y esperar lo mejor? ¿O es suficiente simplemente cifrar en el nivel del disco? Con eso, una vez más, si un hacker puede obtener acceso, no tendrán ningún problema en leerlo. ¿Cuál es el estándar aquí cuando se trata de datos confidenciales?

    
pregunta Luke Sapan 03.07.2015 - 14:20
fuente

2 respuestas

2

Depende de qué amenazas protegerá.

La encriptación de datos en el nivel de la base de datos es una gran protección, cuando tiene tantos empleados de TI, que puede dividirlos en equipos responsables de cada capa.

Por ejemplo, los bancos y los proveedores de tarjetas de crédito utilizan el estándar de seguridad PCI DSS, que requiere dicha protección además de dividir al personal de TI en equipos y restringir los permisos fuera de la capa asignada (por ejemplo, red interna o solo enrutadores de borde).

Por otra parte, el cifrado de datos a nivel de base de datos le brinda muy poca protección adicional contra amenazas externas, al tiempo que genera una sobrecarga de desarrollo de aplicaciones bastante grande.

Entonces, si no te importa tanto proteger contra amenazas internas, entonces el cifrado a nivel de disco debería estar bien.

    
respondido por el Tomasz Klim 03.07.2015 - 15:21
fuente
0

Nada es inútil, y no hay balas de plata. Todo depende.

Había una barra lateral sobre el uso de cifrado de disco. Eso es proteger contra una superficie de ataque diferente, así que ignorémosla.

La pregunta pregunta si tiene sentido cifrar los datos que se encuentran en una base de datos, bajo el supuesto de que necesita ser texto simple para un cliente web. Las opciones presentadas son usar un token maestro (fuera de la base de datos) para descifrar el criptotexto almacenado, o usar un token proporcionado por el usuario, con la observación de que esto es una mala idea y no funcionaría para la colaboración.

Si lo que le preocupa es que alguien pueda violar la confidencialidad del servidor web, digamos que para levantar ese token maestro almacenado y la base de datos, entonces de hecho no tiene suerte. La mitigación aquí es que a menudo la violación de la base de datos y la violación de las configuraciones web son diferentes, y una sin la otra no es útil. Por lo tanto, es protector en, por ejemplo, el ejemplo clásico de un ataque de inyección de sql que descarga la base de datos.

En ese momento, usar un token proporcionado por el usuario es muy útil, y no lo llamaría una mala idea. Tenga en cuenta que, en teoría, esto todavía puede ser útil en aplicaciones colaborativas: el criptotexto almacenado puede cifrarse utilizando un cifrado de flujo cuya clave está cifrada (por ejemplo, a través de una PKI) contra las claves de varias personas. Ahora, la confidencialidad del servidor no es un problema (suponiendo que no tengan acceso al tiempo de ejecución): ninguna recopilación de información en el servidor puede convertir el criptotexto a texto simple sin los tokens del usuario.

Pero, si se cuestiona la integridad del servidor, entonces esta solución falla. El texto sin formato está en la memoria del servidor, por lo que su juego finaliza ... el programa puede reconfigurarse para conservar el texto sin formato en cualquier lugar deseado, o incluso para cambiar la mensajería entre los clientes. Ahí es donde entra en juego la tercera solución. Si tiene un código ejecutándose en la máquina cliente que realiza el descifrado de la información pasada y el cifrado de cualquier respuesta, está nuevamente en agua segura. (Aunque, por supuesto, ahora depende de la opsec de los clientes finales, pero ese es siempre el caso).

Evalúe los riesgos y costos de varios casos de pérdida de integridad en el servidor y haga su elección.

Barra lateral: si realmente te importa esto, DEJA DE USAR CONTRASEÑAS. Si no lo hace, en mi humilde opinión un token maestro está bien.

    
respondido por el Robert Weaver 03.07.2015 - 21:12
fuente

Lea otras preguntas en las etiquetas