¿Qué alternativas seguras tengo para almacenar direcciones postales / números de teléfono en MySQL?

Aunque creo que es fantástico que esté tratando de asegurar su aplicación, me pregunto: está tratando de proteger a sus usuarios de una violación de la base de datos, y le preocupa la dirección postal y el número de teléfono. ¿Son estos dos elementos realmente las cosas más importantes para asegurar? Por lo general, si tiene un nombre y un apellido, puede obtener estos dos puntos de datos de una guía telefónica pública. Esto no me parece que sea un dato muy valioso, a menos que su servicio intente mantener a los usuarios anónimos (pero luego también debe eliminar el nombre de usuario y el nombre de usuario de la base de datos e identificarlo con un número aleatorio).

Lo que me gusta es la idea de no almacenar datos que no necesitas en absoluto. André tiene razón al señalar que las direcciones de correo a alguien en texto sin formato tampoco son muy seguras, pero me gusta la idea de transferir los datos a la persona que realmente los necesita y luego eliminarlos de su posesión. Esto significa que no puede ser considerado responsable en caso de una violación de datos, porque simplemente no tiene los datos.

Tres ideas

1) Lo que podría hacer para resolver su problema es crear una segunda base de datos en un host diferente que básicamente solo almacene la información personal de sus clientes y crear un microservicio a su alrededor para almacenar y consultar direcciones basadas en una identificación de usuario .

Esto aislaría la base de datos de direcciones del resto de la aplicación y agregaría otra capa de protección, pero aún así no resolvería realmente el problema, porque un atacante que pueda acceder a su base de datos probablemente también podrá resolverlo. cómo consultar el servicio de direcciones remotas.

2) Puede obtener una cantidad de seguridad adicional casi equivalente cifrando las direcciones y los números de teléfono en su base de datos. Si un atacante simplemente roba la base de datos, no podrá hacer nada con los campos cifrados, pero obviamente, también podría robar la clave de cifrado. No hay forma de evitarlo si desea almacenar datos y mantenerlos accesibles.

3) La tercera solución utiliza la criptografía de clave pública para proteger las direcciones y los números de teléfono: Usted cifra las direcciones y los números de teléfono en su servidor usando una clave pública. No mantienes la clave privada en el servidor. Solo el propietario de la clave privada puede descifrar los datos cifrados, y como la clave privada no está disponible en el servidor, significa que un atacante no puede obtener datos que ya están cifrados (pero podría instale una rutina para recoger las direcciones y números de teléfono de los nuevos clientes antes de que se cifren). La desventaja de esta solución es que su aplicación tampoco tiene acceso a los datos cifrados.

Estoy de acuerdo con los comentarios de André y Pascal: es probable que la base de datos sea más segura que la estación de trabajo de alguien. Sin embargo, si realmente desea conservar los datos en la organización pero no tenerlos en la máquina de la base de datos, aquí hay otra opción:

• Cree una página web HTTPS, protegida por una buena contraseña en un buen servidor.
• Periódicamente, haga que su cliente vaya a esa página web.
• Su visita a la página hará que toda la PII en la base de datos se escriba en un archivo que se descarga a su máquina a través del navegador.
• Tras la descarga, la PII se elimina de la base de datos.
• Esto se puede escribir mediante curl mediante bash-crontab (iOS / Linux) o Task Scheduler-PowerShell (Windows), para que no tenga que acordarse de hacerlo.
• Los datos se cifran en movimiento a través de TLS-HTTPS, y luego están fuera de sus manos.

Ahora hay una serie de productos comerciales (relativamente asequibles) que pueden manejar su situación exacta.

Algunas soluciones tienen cifrado a nivel de columna junto con control de acceso a nivel de columna y administración de privilegios. Eso significa que para cada columna en su base de datos puede definir quién puede tener acceso a ella, quién puede cifrar / descifrar qué tipo de aplicación y en qué momento. Esto podría ser mucho más barato que tener que desarrollar un sitio web solo para este problema (recursos humanos, tiempo y costo de mantenimiento).

Mi consejo es comenzar con las dos preguntas fundamentales (funcionalidades):

• ¿para qué se utilizarán los datos?
• ¿De qué quieres proteger los datos?

La respuesta a la segunda pregunta es fácil: desea protegerlos contra el robo si alguien pudiera tener acceso a su sistema. Eso significa que, idealmente, debería ser imposible obtenerlos del sistema que los ha almacenado.

Si he entendido correctamente, las direcciones / números de teléfono no son utilizados por la aplicación, sino para marketing . Si eso significa que se usarán solo ocasionalmente y de un número limitado de usuarios, creo que la 3ª idea de Pascal es la mejor aquí:

• almacena las direcciones y los números de teléfono en un almacenamiento auxiliar (servidor, base de datos o al menos una tabla diferente): como son datos cortos, puede cifrarlos directamente con una clave pública
• la clave privada solo es accesible para la aplicación de marketing. Aquí, ya que procesa la información personal, tendrá que proteger esa parte, pero como no dijo mucho al respecto, tampoco puedo decir nada más, y en mi humilde opinión sería una pregunta diferente.

De esa manera, la aplicación bajo su responsabilidad es perfectamente segura, y no pone restricciones adicionales en la parte de marketing porque, como ellos usan datos personales, de todos modos los protegerán.

Estoy de acuerdo con los demás aquí en que, si bien sus objetivos son loables, esta información tiene un valor limitado. También estoy de acuerdo en que es probable que el servidor sea un lugar más seguro para almacenar la información que la PC de escritorio de alguien, pero en realidad no sabemos nada sobre la infraestructura del cliente.

Dada la relativamente baja sensibilidad de la información y el modelo de uso, me gustaría dar a la cuenta de servicio ningún acceso de lectura y escritura a las tablas que contienen estos datos, sino a un procedimiento almacenado para aplicar escrituras, y luego proporcionar una alternativa La IU donde el cliente puede proporcionar la contraseña para una cuenta MySQL con acceso de lectura (¿y escritura?) A estas tablas. es decir, una buena separación de privilegios a la antigua.

Los datos aún están expuestos en los archivos de datos subyacentes (y las copias de seguridad), pero evitan la complejidad del código y los procesos relacionados con la administración de claves asimétricas.

Una cosa que podría hacer sería cifrar los registros con la contraseña del usuario. Estoy de acuerdo en que esta no es realmente una gran opción debido a la forma en que las contraseñas de los usuarios son cortas, pero bueno, ¿no es así?