Necesito diseñar una base de datos que contenga información sobre enfermedades personales de los usuarios.
¿Cuál puede ser el enfoque para implementar las columnas de las tablas del DB: cifrar la información, separar los datos dentro de dos DB diferentes, uno para datos confidenciales y otro para datos no confidenciales, o ambos u otro enfoque?
security
database-design
mysql
carlo
fuente
fuente
Respuestas:
Puede cifrar los datos con una clave almacenada en su aplicación web para que los datos se escriban / lean desde db en su forma cifrada. Sin embargo, cualquier persona con acceso al código tendría acceso a la clave y con la clave los datos no cifrados. Esto resuelve el requisito
En cuanto a usar para separar bases de datos, no creo que sea necesario. Está almacenando los datos cifrados y utilizando los permisos de la base de datos por usuario, la tabla (si es necesario) será más que suficiente. Creo que la base de datos adicional agrega una capa de complejidad sin mucho más. A menos que esté en una ubicación diferente, entonces podría tener una PEQUEÑA mejora de un solo sistema de base de datos.
fuente
La respuesta de Ominus aborda su primera pregunta. La respuesta a la segunda pregunta puede requerir más detalles sobre su aplicación.
Otro enfoque con mayor seguridad si los pacientes deben acceder a la base de datos podría ser tener una base de datos separada para cada usuario. En este enfoque, puede usar un marco que proporcione la funcionalidad de múltiples inquilinos y múltiples bases de datos. Sin embargo, el problema es que si tiene usuarios de aplicaciones y usuarios de bases de datos separados, la sincronización de estos usuarios será increíblemente difícil. Sin embargo, supongo que los pacientes no necesitan acceder a su base de datos. Si lo necesitan, puede ser más seguro tener una clave por usuario.
Además de los requisitos legales o contractuales, algunas otras razones por las que se me ocurre tener bases de datos separadas son: la percepción del cliente de una mayor seguridad que facilita las ventas, las preocupaciones sobre la ruptura del cifrado y las preocupaciones sobre (la) clave (s) en peligro.
Con respecto a la parte de la respuesta de Briddmus donde dice "que necesita cifrar más que solo la información médica": esto solo se cumple si todos en la base de datos tienen una condición médica. (Supongo que este es el caso).
Nota: partes de esta respuesta serían más adecuadas como comentarios, pero todavía no tengo suficiente representante para publicar comentarios aquí.
fuente
Para este tipo de aplicación, debe pensar en quién debe tener acceso a los datos. Con la información médica, creo que debería estar restringida al usuario que la ingresó y a cualquier persona a la que le dieron permiso para verla.
Para evitar que el DBA vea los datos, deberá encriptarlos utilizando un código al que el DBA no tiene acceso.
También debe cifrar la información de manera que el programador de la aplicación tampoco pueda acceder a ella. No tiene sentido cifrar la información del DBA si un programador puede iniciar sesión como cualquier usuario.
Tampoco desea cifrar todos los datos con el mismo código. El software puede tener un error que muestra a un usuario la información de otro. Por lo tanto, probablemente sería mejor cifrar los datos de cada usuario utilizando un código específico para ese usuario.
Es importante tener en cuenta que necesita cifrar más que solo la información médica; Como usuario final, no quisiera que su DBA supiera que tengo una afección médica, y mucho menos cuál es. Por lo tanto, también deberá cifrar cualquier información de identificación personal sobre el usuario. Esto incluye cosas como:
fuente