Sin base de datos central

Tengo un cliente que busca obtener un sitio web / aplicaciones móviles / aplicaciones de escritorio integradas que traten con datos muy confidenciales (más sensibles que los detalles del banco / tarjeta). Debido a la naturaleza sensible de los datos, no quieren guardarlos en una base de datos central, pero todavía quieren que sus aplicaciones se sincronicen (digamos que agrego algunos datos a mi aplicación móvil, luego quiero poder ir a mi aplicación de escritorio y ver los mismos datos).

No puedo pensar en una forma agradable y confiable de hacer esto y no estoy seguro de que haya una. Por eso estoy aquí. ¿Alguien sabe cómo podría manejar estos datos?

Una solución en la que estaba pensando era tener una base de datos del lado del cliente en cada aplicación que de alguna manera se sincronizara entre aplicaciones, aunque puedo ver que esto no es confiable y se vuelve desordenado.

Mucha información confidencial se almacena en bases de datos. De hecho, una base de datos central es probablemente la forma más segura de almacenar estos datos. Las grandes bases de datos empresariales tienen toneladas de funcionalidades para hacer cosas como cifrar información confidencial, auditar quién accede a ella, limitar o evitar que las personas, incluidos los DBA, vean los datos, etc. Puede contar con expertos de seguridad profesionales que supervisen el entorno y DBA profesionales que supervisen las copias de seguridad. que no pierdas datos Es casi seguro que sea mucho más fácil comprometer los datos almacenados en el dispositivo móvil o portátil de un usuario aleatorio que penetrar en una infraestructura de seguridad bien diseñada y comprometer una base de datos central adecuada.

Puede diseñar el sistema con una base de datos central que almacene solo datos cifrados y almacene la clave privada del usuario en el dispositivo del usuario. De esa manera, incluso si la base de datos central está completamente comprometida, los datos solo pueden ser utilizados por el usuario. Por supuesto, eso significa que no puede restaurar los datos del usuario si pierde su clave (digamos que la única copia estaba en su teléfono y su teléfono estaba dañado). Y si alguien compromete la clave y, presumiblemente, sus credenciales de inicio de sesión, podrían ver los datos.

Debe realizar una copia de seguridad de un par de pasos y, en consulta con su cliente, elaborar un modelo de amenaza . (Sí, es un enlace a un libro de 600 páginas; sí, te recomiendo que leas todo el artículo).

Un modelo de amenaza comienza haciendo preguntas como

• ¿Por qué la aplicación necesita almacenar esta información confidencial en primer lugar?
  • ¿Puedes evitar almacenarlo?
  • ¿Se puede tirar después de un corto tiempo?
  • ¿Realmente necesita ser accesible para más de un dispositivo?
  • Si debe ser accesible en más de un dispositivo, ¿debe almacenarse en más de un dispositivo?
• ¿Quiénes son las personas que pueden ver los datos confidenciales de cada usuario?
  • ¿Se puede acortar esta lista?
• ¿Quiénes son las personas que pueden entrar en contacto con los datos confidenciales de cada usuario mientras intentan hacer su trabajo, pero no necesitan saberlo?
  • ¿Se puede acortar esta lista?
  • ¿Se puede hacer que los datos sean inaccesibles para ellos sin dañar su capacidad para hacer su trabajo?
  • Si no puede ser inaccesible, ¿puede al menos hacerse incomprensible? (Esto es lo que hace el cifrado, en resumen: hace que los datos sean incomprensibles).
• ¿Quiénes son las personas que desean ver los datos confidenciales, pero no están permitidos?
  • ¿Qué oportunidades tienen para obtener los datos?
  • ¿Qué quieren hacer con los datos una vez que los tienen?
  • ¿Qué tan enojados estarán si no consiguen lo que quieren?
  • ¿Cuánto dinero, tiempo, ciclos de CPU y esfuerzo humano están dispuestos a gastar?
  • ¿Les importa si alguien sabe que ha visto los datos?
  • ¿Quieren acceder a datos confidenciales de usuarios específicos , o lo hará alguien?
  • ¿Qué saben ellos ya?
  • ¿A qué ya tienen acceso?

Una vez que sepa las respuestas a estas preguntas, estará en un lugar mucho mejor para descubrir qué hacer.

Tenga en cuenta que puede haber más de una respuesta para cada conjunto de preguntas, especialmente las que tratan con los atacantes (las personas que desean los datos confidenciales pero no pueden tenerlos). Si no puede pensar en al menos media docena de atacantes arquetípicos diferentes , con diferentes motivaciones, objetivos y recursos, probablemente se haya perdido algo.

También tenga en cuenta que los atacantes que le causan más problemas a usted (y / o al cliente) son los más propensos a causar un gran impacto en los medios de comunicación si su ataque tiene éxito, o quienes causan la mayor cantidad de daño agregado , probablemente no los atacantes que pueden causar el mayor daño a los usuarios individuales si su ataque tiene éxito. La compañía de su cliente racionalmente se preocupa más por el daño agregado, pero los usuarios racionalmente se preocupan más por el daño a sí mismos.

Una opción para hacer la sincronización sería hacerlo de igual a igual. Esto todavía requerirá un servidor central, pero ese servidor no manejará ninguno de los datos.

Cuando un dispositivo se conecta, un servidor central recibe una notificación con el ID de usuario. Cuando un segundo dispositivo del mismo usuario se conecta, el servidor envía a ambos dispositivos las direcciones IP del otro. Los dispositivos pueden intercambiar datos directamente. Advertencia: un dispositivo debe actuar como servidor, por lo que al menos uno no puede estar detrás de un enrutador NAT.

No olvide que necesitará una autenticación y un cifrado sólidos tanto para el mecanismo de notificación como para el intercambio entre pares.

Que sea el problema de otra persona.

Almacene los datos localmente en cada aplicación, luego brinde a los usuarios la opción de habilitar la sincronización utilizando su propia cuenta con un servicio de terceros (Dropbox, Google Drive, etc.). Además, piense en cifrar los datos cargados en el servicio de terceros (existen ventajas y desventajas para hacerlo).

Esto da la apariencia de que los usuarios poseen sus propios datos, ya que tienen que optar por la sincronización de datos. Hace que las aplicaciones sean útiles para las personas que no desean que se comparta nada. Y hace a otra persona responsable (técnica y, potencialmente, legalmente) de los continuos dolores de cabeza de mantener seguros los datos compartidos.

La preocupación de su cliente parece estar relacionada con la visibilidad de estos datos. La primera pregunta que debe hacerle a su cliente es si los datos se cifraron, ¿dónde se pueden almacenar? Luego, pregúntele a su cliente qué tipo de controles de acceso desea tener antes de que los datos se puedan descifrar y procesar, ¿dónde se puede almacenar la clave de descifrado? ¿Es una clave separada por usuario? etc ...

Si su cliente no quiere que los datos se almacenen en ningún lado, ¿quiere que el usuario los ingrese cada vez?