¿Particionar la base de datos para mejorar la seguridad / anonimato?

La entidad que podrá combinar los datos más adelante probablemente será su cuello de botella de "seguridad".

Por supuesto, puedes tener una relación:

       user
     /      \
    A        B

y espero que un atacante solo obtenga acceso a A o B o potencialmente incluso a AMBOS, pero alguien de alguna manera necesita tener conocimiento sobre cómo reconstruir esto nuevamente y ahí es donde estará el cuello de botella. Sin embargo, digamos que alguien logra atacar su cuello de botella, es posible que solo puedan recuperar el enlace de los conjuntos de datos con los usuarios, pero que no necesariamente tengan acceso a los datos en sí. Digamos que tienes tres servidores A, B y R donde A, B almacenan datos sin procesar y R almacena las relaciones. ¿Cómo harías el control de acceso? ¿Codificaría los datos para que solo el propio usuario pueda descifrar la información y unirla? A y B no saben quién eres, por lo que realmente no puedes hacer el control de acceso a esos conjuntos de datos porque, si almacenas, la OMS tiene acceso a los datos de A y B, ya los estás vinculando nuevamente a un usuario.

¿Cómo accede su aplicación a los datos? ¿Necesita ejecutar el cálculo en los datos? ¿Cómo haces eso si no conoces las relaciones?

Para mí ... esto es demasiado amplio. Es posible que obtenga una respuesta significativa para un escenario específico, pero probablemente no en el caso genérico.

La amenaza no está suficientemente definida. Usted dijo que desea evitar la identificación de los usuarios y sus datos, pero no dijo por quién. ¿Tus compañeros de equipo? ¿Tu proveedor de hosting? ¿Un atacante al azar? ¿Alguien interesado en tus datos y está dispuesto a probar un ataque dirigido?

Básicamente admitiste que hay un cuello de botella, que es tu aplicación y el servidor que lo ejecuta. Entonces, su idea de dividir la base de datos solo funcionará contra las amenazas que atacarán con éxito sus bases de datos, pero no podrán atacar su aplicación. ¿Qué tipo de amenazas son estas? No puedo pensar en muchos ejemplos en este momento. Tal vez la amenaza de que un ladrón robe las copias de seguridad de la base de datos: si las copias de seguridad se encuentran en lugares diferentes, las posibilidades de robarlas son menores y, por lo tanto, es menos probable que el ladrón obtenga todos los datos. Pero las copias de seguridad deben estar cifradas de todos modos, por lo que si se utilizan buenas prácticas de cifrado, ¿por qué perder el tiempo tratando de implementar un sistema que utiliza varias bases de datos? También teniendo en cuenta que agregar complejidad en la aplicación aumentará la probabilidad de errores, algunos de los cuales podrían generar vulnerabilidades adicionales.

Entonces, en mi opinión, la pregunta es, nuevamente: ¿cuáles son las amenazas que van a comprometer sus bases de datos, pero no su aplicación? Después de responder a esta pregunta, toda la situación será más clara.

Yo diría que esto cae bajo la seguridad de la oscuridad, que nunca es un método de seguridad a prueba de tontos. ¿De quién estás tratando de ocultar los datos? Para un usuario final no hace ninguna diferencia.

Los desarrolladores y administradores de sistemas probablemente podrán acceder a todas las bases de datos. Si como dice que los sirve desde diferentes vms o contenedores, soy un pirata informático que obtuvo root en su hipervisor o host de contenedor, por lo tanto, tengo acceso de root a todos ellos.

Si los servidores de base de datos están alojados por diferentes proveedores, es probable que ejecute el mismo sistema operativo y el mismo sistema de base de datos en cada servidor de base de datos independiente, entonces un pirata informático encuentra que un exploit en un servidor de base de datos es aplicable en cualquier otro que tenga. Solo estarías aumentando la cantidad de servidores que tienes que parchear. de lo contrario, tiene diferentes versiones de sistema operativo y base de datos en cada proveedor, por lo que podría encontrar algunos comportamientos de dependencia de versiones específicas horribles y aumentar la cantidad de servidores diferentes para administrar parches de seguridad.