Anonimizando datos confidenciales en MySQL DB manteniendo la capacidad de búsqueda [cerrado]

3

Tengo una base de datos MySQL que almacena datos confidenciales (personales) sobre individuos; y se han encargado de garantizar que estos datos estén encriptados de alguna manera para proteger a las personas y sus datos, por ejemplo. el servidor debe estar comprometido, o un usuario malintencionado de nuestro proveedor de servicios de alojamiento accede al servidor sin autorización. La base de datos es utilizada por un marco web PHP que reside en el mismo servidor.

Estoy luchando con un buen esquema que permite que los datos se cifren & imposible de leer sin la debida autorización; mientras se mantiene la funcionalidad (índices, relaciones de base de datos, poder leer los datos en el marco web). ¿Cuáles son las mejores opciones?

Dos enfoques que he considerado son:

1) Encriptar campos / datos específicos en la base de datos con una clave para que, si la base de datos se ve comprometida, la información que contiene no sea deducible para un usuario individual (por ejemplo, mantenemos índices y relaciones, pero la información de identificación personal se cifra) ). La aplicación descifraría la información usando la clave en tiempo de ejecución. El desafío está en cómo administrar la clave: si se coloca en la lógica de la aplicación o si la lógica de la aplicación puede acceder a ella como un archivo en el mismo servidor, aún puede verse comprometida. Posiblemente podría estar ubicado en otro servidor; pero aún sería necesario acceder en tiempo de ejecución mediante la lógica de la aplicación; es decir, el acceso a la lógica de la aplicación permitiría tomar posesión de la clave. Posiblemente podría almacenar la clave en la memoria al arrancar el servidor; pero introduce un posible problema de estabilidad (servicio inactivo después de reiniciar). ¿Qué son las opciones? ¿Es este un buen enfoque?

2) Implementando algún tipo de división lógica de datos entre la información de identificación personal y la base de datos restante. P.ej. una tabla con información personal (nombre de usuario, correo electrónico) un índice; una tabla con los datos confidenciales (por ejemplo, tabla de información de salud) con otro índice; y luego introducir algún tipo de cifrado basado en clave unidireccional (piense, por ejemplo, enlace ) una tabla entre los dos, donde Relación entre la información personal y amp; los datos confidenciales solo se pueden generar (incluso en tiempo de ejecución mediante la lógica de la aplicación) si se puede suministrar una clave para que coincida con la tabla. Pero una vez más, me topo con la necesidad de administrar el acceso a la clave utilizada en el escenario anterior; similar al anterior.

¿Qué es la mejor práctica?

    
pregunta ppswede 30.09.2014 - 16:55
fuente

3 respuestas

1

Todos los detalles del manejo adecuado de la información de la base de datos van más allá del alcance de una respuesta rápida de StackExchange. Realmente quieres hacer esto de la manera correcta . Parte de su problema es la arquitectura donde la base de datos y la aplicación web que accede a la información confidencial están en el mismo servidor. Si ese servidor se ve comprometido, también lo hace el material de claves para cualquier cifrado que haga.

Si solo está buscando una solución práctica, en lugar de la teoría del diseño, tengo dos sugerencias.

One One es gratuito y de código abierto, pero está en desarrollo activamente (por lo que no tengo idea de lo adecuado que sería para el uso de producción de su empresa).

La otra es una solución comercial que podría comprar (adecuada para negocios, pero no conozco su presupuesto ni sus necesidades comerciales).

Fuente abierta - cryptdb (código disponible en github)

Commercial - Voltage SecureData

He usado ambos, pero sin saber más sobre tus circunstancias, no podría decir cuál es el adecuado para ti. El voltaje está más preparado para los negocios, y utilizado por las compañías de Fortune 500, cryptdb es más bien un proyecto de investigación que puede atraer a los tipos de bricolaje.

    
respondido por el JesseM 14.11.2014 - 21:32
fuente
0

Esto es bastante similar a Proteger los datos de la base de datos de todos, incluidos los administradores de sistemas, etc. .

Su segunda opción no funciona (al menos de forma aislada). El solo hecho de saber los datos de información de salud puede ser "suficientemente malo" (e indirectamente compatible con el usuario). Puede ser interesante ocultar esa relación, pero no estoy convencido de que valga la pena hacerlo.

La segunda opción es correcta. Como desea mantener la capacidad de búsqueda de db, mantiene índices en los campos utilizados como claves (por ejemplo, nombre, número de paciente), que no está cifrando. Los demás campos están descifrados por la aplicación.

La mejor solución sobre dónde almacenar la clave es no almacenarla. Hacer que el usuario ingrese manualmente la clave. O cifrarlo en varias claves públicas, y el usuario debe desbloquear su propia clave antes de usarla.

Supongamos que tenemos el siguiente esquema:

Table doctors:
 Username, public key, disabled

Table patients:
 Name, encrypted info

La primera vez que un nuevo usuario abre la aplicación, crea localmente una nueva clave pública (protegida por contraseña) y se registra en la tabla de médicos (sujeta a validación, etc.).

La próxima vez, se le pedirá al usuario su contraseña (utilizada para desbloquear su clave), y se usará el conocimiento de la clave privada para controlar el inicio de sesión.

Al obtener los detalles de un paciente, recupere el blob, descifre con su clave pública y extraiga los detalles (puede ser más eficiente almacenar varios campos en un blob si realmente se van a usar juntos).

Puede almacenar en formato simple en la db (lo que permitiría a un atacante insertar su propia clave) o encriptado en el blob, por lo que un médico existente debe agregar al nuevo médico como "tratamiento del paciente".

Si la aplicación descubre que un paciente está vinculado a un médico con el bit desactivado establecido (p. ej., se fue de la compañía), se elimina de la lista de personas a las que están cifradas.

    
respondido por el Ángel 30.09.2014 - 18:31
fuente
0

Creo que debes decidir si quieres cifrar toda la Db, o quieres cifrar cada registro individualmente.

Encriptar toda la Db - es fácil de lograr. Hay varios mecanismos que podrías implementar. Este mecanismo proporciona una buena protección contra la piratería / robo de datos, pero su personal de TI podrá leer y robar los datos con facilidad.

Encriptando cada registro: brinda a sus usuarios la mejor protección de datos. Como si la Db fuera robada, los hackers tendrían que atacar con fuerza cada registro. Implementar como una solución de 2 servidores, 1 servidor generando la clave, el otro servidor almacenando los datos. Esto protege sus datos de su propio personal interno, así como del "Sr. Black Hat", siempre y cuando la base de datos 2 se administre por separado. Mr "Black Hat" ahora necesita robar ambos Db de 2 sistemas para acceder a sus datos.

Espero que esto pueda proporcionarle algunas ideas sobre cómo abordar el problema.

    
respondido por el Tim Seed 30.10.2014 - 07:41
fuente

Lea otras preguntas en las etiquetas