¿Cómo separar la identidad de una persona de sus datos personales?

https://stackoverflow.com/questions/3691348

02-10-2019
|

Pregunta

Estoy escribiendo una aplicación cuya finalidad principal es la de mantener lista de usuarios compras.

Me gustaría asegurarse de que ni siquiera yo como desarrollador (o cualquier persona con plena el acceso a la base de datos) no se pudo calcular la cantidad de dinero que una persona en particular ha pasado o lo que él ha comprado.

Al principio me encontré con el siguiente esquema:

    --------------+------------+-----------
    user_hash     | item       | price
    --------------+------------+-----------
    a45cd654fe810 | Strip club |     400.00
    a45cd654fe810 | Ferrari    | 1510800.00
    54da2241211c2 | Beer       |       5.00
    54da2241211c2 | iPhone     |     399.00

usuario inicia sesión con nombre de usuario y contraseña.
Desde el user_hash contraseña calcular (posiblemente con la salazón, etc.).
Usar el hash a los usuarios acceso a datos con consultas SQL normales.

Con suficientes usuarios, debe ser casi imposible decir cuánto dinero que un usuario particular ha pasado por el hecho de saber su nombre.

¿Es esto una cosa sensible a hacer, o estoy completamente tonto?

Solución

El problema es que si alguien ya tiene acceso completo a la base de datos, entonces es sólo una cuestión de tiempo antes de que se vinculan los registros a personas particulares. En algún lugar de su base de datos (o en la propia aplicación) que tendrá que hacer la relación entre el usuario y los objetos. Si alguien tiene acceso completo, entonces van a tener acceso a ese mecanismo.

No hay absolutamente ninguna manera de prevenir esto.

La realidad es que al tener acceso completo estamos en una posición de confianza. Esto significa que los directivos de la empresa tienen que confiar en que a pesar de que se puede ver los datos, no actuar en forma alguna en él. Aquí es donde las cosas pequeñas como la ética entran en juego.

Ahora, dicho esto, una gran cantidad de compañías de separar el desarrollo y personal de producción. El objetivo es eliminar el Desarrollo de tener contacto directo con vivo: los datos (es decir, real). Esto tiene una serie de ventajas con la seguridad y la fiabilidad de los datos de ser en la parte superior de la pila.

El único inconveniente real es que algunos los desarrolladores creen que no pueden solucionar un problema sin acceso producción. Sin embargo, esto simplemente no es cierto.

El personal

Producción entonces serían los únicos que tienen acceso a los servidores de juego. Ellos suelen ser examinados en un grado mayor (antecedentes penales y otros controles de antecedentes) que es commiserate con el tipo de datos que se han de proteger.

El punto de todo esto es que este es un problema personal; y no uno que realmente se pueden resolver con medios técnicos.

Actualizar

Otros aquí parece que falta una pieza muy importante y vital del rompecabezas. A saber, que se introducen los datos en el sistema por una razón. Eso es casi universalmente para que pueda ser compartida. En el caso de un informe de gastos, que se introduce los datos para que la contabilidad puede saber a quién pago retroactivo.

Lo que significa que el sistema, en algún nivel, tendrá que coincidir con los usuarios y los artículos sin la persona de entrada de datos. (Es decir: un vendedor) está conectado

Y debido a que los datos tiene que estar atado juntos sin todas las partes involucradas allí de pie para teclear un código de seguridad para "liberar" los datos, a continuación, un DBA absolutamente será capaz de revisar los registros de consultas para averiguar quién es quién. Y muy fácilmente podría añadir independientemente del número de marcas de hash que desea lanzar en él. Triple DES no guardará usted tampoco.

Al final del día todo lo que has hecho es más difícil hacer el desarrollo con absolutamente cero beneficio de seguridad. No puedo enfatizar esto lo suficiente: la única manera de ocultar los datos de un dba sería para cualquiera de esos datos a 1. Sólo será accesible por la misma persona que entró en ella o 2. para que no se existir en el primer lugar.

En cuanto a la opción 1, si la única persona que puede acceder a él es la persona que entró en ella .. así, no hay ningún punto para que sea en una base de datos corporativa.

Otros consejos

Me temo que si su aplicación puede vincular a una persona a sus datos, cualquier desarrollador / admin lata.

La única cosa que puede hacer que sea más difícil hacer el enlace, para frenar el desarrollador / admin, pero si usted hace que sea más difícil para los usuarios de enlace a los datos, que hará que sea más difícil para su servidor también.

idea basada en la idea de @no:

Puede tener un inicio de sesión clásica de usuario / contraseña a su aplicación (hash de la contraseña, o lo que sea), y "pasar" un especial que se utiliza para mantener sus datos seguros. Este "paso" no sería almacenada en su base de datos.

Cuando su registro de cliente en su aplicación tendría que proporcionar / contraseña / usuario pase. El usuario / contraseña se comprueba con la base de datos, y el paso sería utilizado para la carga de datos / escritura.

Cuando necesite datos de escritura, que hacen un hash de su "nombre de usuario / contraseña" pareja, y almacenarlo como una clave que une a su cliente a sus datos.

Cuando tenga que cargar datos, que hacen un hash de su "nombre de usuario / contraseña" pareja, y cargar todos los datos que coincidan con este hash.

De esta manera es imposible hacer una relación entre sus datos y su usuario.

En otra parte, (como dije en un comentario a @no) cuidado de colisiones . Además, si el usuario escriba una mala "pasan" no se puede comprobar.

Actualización:. Para la última parte, tenía otra idea, que puede almacenar en su base de datos un hash de su "/ contraseña pase" pareja, de esta manera se puede comprobar si su "paso" está bien

Crear una tabla con los usuarios:
1. user_id: una columna de identidad (id autogenerado)
2. nombre de usuario
3. Contraseña: Asegúrese de que sea hash
Crear una tabla de productos como en su ejemplo:
1. user_hash
2. elemento
3. precio

El user_hash se basa fuera de user_id que nunca cambia. Nombre de usuario y la contraseña son libres de cambiar según sea necesario. Cuando el usuario inicia sesión, se comparan nombre de usuario / contraseña para obtener el user_id. Puede enviar la parte posterior user_hash al cliente durante la duración de la sesión, o una versión encriptada / indirecta de la almohadilla (podría ser un identificador de sesión, donde el servidor almacena la user_hash en la sesión).

Ahora se necesita una manera de hash de la user_id en user_hash y mantenerlo protegido.

Si lo haces del lado del cliente como @no sugirió, el cliente tiene que tener user_id. gran agujero de seguridad (especialmente si se trata de una aplicación web), el hash puede ser fácilmente manipulado y el algoritmo es de libre acceso para el público.
Usted podría tener como función de la base de datos. Mala idea, ya que la base de datos tiene todas las piezas para vincular los registros.
Para los sitios web o cliente / servidor de aplicaciones que podría tener en su código del lado del servidor. Mucho mejor, pero luego un desarrollador tiene acceso al algoritmo de hash y datos.
Haga que otro desarrollador escribir el algoritmo de hash (que no tiene acceso a) y palo en otro servidor (que también no tiene acceso a) como un servicio TCP / web. Su código de servidor sería luego pasar el ID de usuario y obtener una copia de hash. Usted no tendría el algoritmo, pero se puede enviar a todos los ID de usuario a través de obtener todos sus hash espalda. No es una gran cantidad de beneficios a # 3, aunque el servicio podría tener la tala y como para tratar de minimizar el riesgo.
Si es simplemente una aplicación cliente-base de datos, es suficiente con opciones 1 y 2. fuertemente sugiere que se añada otra capa [negocio] que es del lado del servidor, independiente del servidor de base de datos.

Editar Esto se superpone algunos de los puntos anteriores. Tiene 3 servidores:

servidor de autenticación : Empleado A tiene acceso. Mantiene la tabla de usuario. Tiene servicio web (con comunicaciones cifradas) que toma combinación usuario / contraseña. Hashes de contraseñas, mira hacia arriba user_id en la tabla, genera user_hash. De esta manera usted simplemente no puede enviar todos user_ids y volver a los valores hash. Tienes que tener la contraseña que no se almacena en cualquier lugar y sólo está disponible durante el proceso de autenticación.
servidor de base de datos principal : Empleado B tiene acceso. Sólo almacena user_hash. Sin ID de usuario, contraseñas no. Puede enlazar los datos utilizando el user_hash, pero la información de usuario real está en otra parte.
servidor de sitio web : Empleado B tiene acceso. Obtiene información de acceso, pasa al servidor de autenticación, se pone de hash espalda, y luego dispone información de acceso. Mantiene hachís en sesión para escribir / consulta a la base de datos.

Así Empleado A ha USER_ID, nombre de usuario, contraseña y algoritmo. Empleado B tiene user_hash y datos. A menos que modifica empleado B el sitio web para almacenar el usuario / contraseña en bruto, no tiene forma de vincular a los usuarios reales.

El uso de perfiles de SQL, empleado A obtendría user_id, nombre de usuario y contraseña de hash (ya user_hash se genera más adelante en el código). Empleado B obtendría user_hash y datos.

La única manera de garantizar que los datos no se pueden conectar a la persona que pertenece es la de no registrar la información de identidad en el primer lugar (hacer que todo sea anónimo). Al hacer esto, sin embargo, lo más probable es que su sentido aplicación. Puede que esto sea más difícil de hacer, pero no se puede hacer que sea imposible.

El almacenamiento de los datos del usuario y la identificación de la información en bases de datos separadas (y posiblemente en servidores separados) y la vinculación de los dos con un número de identificación es probablemente lo más cercano que se puede hacer. De esta manera, se han aislado los dos conjuntos de datos tanto como sea posible. No obstante, debe mantener ese número de identificación como un vínculo entre ellos; de lo contrario, sería incapaz de recuperar los datos de un usuario.

Además, yo no recomendaría el uso de una contraseña con algoritmo hash como un identificador único. Cuando un usuario cambia su contraseña, entonces tendría que pasar por y actualizar todas sus bases de datos para reemplazar las antiguas identificaciones de contraseñas encriptado con los nuevos. Normalmente es mucho más fácil de usar un identificador único que no se basa en ninguna de la información del usuario (para ayudar a asegurar que permanecerá estática).

Esto termina siendo un problema social, no es un problema tecnológico. Las mejores soluciones serán una solución social. Después de endurecer sus sistemas para proteger contra el acceso no autorizado (piratas informáticos, etc.), es probable que obtener un mejor millaje de trabajo en el establecimiento de la confianza con sus usuarios y la implementación de un sistema de políticas y procedimientos relativos a la seguridad de datos. Incluir sanciones específicas para los empleados que hacen mal uso de la información del cliente. Ya que una sola violación de la confianza del cliente es suficiente para arruinar su reputación y conducir todos los usuarios de distancia, la tentación del mal uso de los mismos por los que tienen acceso "de alto nivel" es menos de lo que parece (desde el colapso de la empresa por lo general es mayor que cualquier ganancia).

Tenga en cuenta que incluso sin almacenar realmente la identificación de cualquier información de la persona, simplemente asociando suficiente información todos con la misma clave podría permitir a averiguar la identidad de la persona asociada a cierta información. Para un ejemplo simple, se podría llamar el club de la tira y pedir al cliente, que condujo un Ferrari.

Por esta razón, cuando se de-identificar los registros médicos (para su uso en la investigación y tal), usted tiene que quitar los cumpleaños de las personas mayores de 89 años de edad (porque la gente que viejos son tan poco frecuente que una fecha de nacimiento específico podría apuntar a una persona individual) y eliminar cualquier geográfica de codificación que especifica un área que contiene menos de 20.000 personas. (Ver http://privacy.med.miami.edu/glossary/xd_deidentified_health_info.htm )

AOL encontró la manera difícil cuando se dio a conocer datos que las personas pueden ser identificados sólo por saber lo que las búsquedas están asociados con una persona anónima buscar. (Ver http://www.fi. muni.cz/kd/events/cikhaj-2007-jan/slides/kumpost.pdf )

Parece como que está en el camino correcto con esto, pero usted está pensando un poco más de él (o simplemente no lo entienden)

Escribir una función que construye una nueva cadena en base a la entrada (que será su nombre de usuario o alguna otra cosa que no puede cambiar las horas extraordinarias)

Utilice la cadena devuelta como una sal al construir el hash de usuario (de nuevo, sin usar el ID de usuario o nombre de usuario como una entrada para el constructor de hash, ya que no será el cambio como una contraseña o correo electrónico de los usuarios)

Asociar todas las acciones del usuario con el hash de usuario.

Nadie con sólo el acceso de base de datos puede determinar qué demonios el usuario hashes media. Incluso un intento de fuerza bruta que al tratar de diferente semilla, combinaciones de sal terminará inútil porque la sal se determina como una variante del nombre de usuario.

Creo que usted ha contestado propia pregunta con su mensaje inicial.

En realidad, hay una manera que usted podría hacer lo que estás hablando ...

podría tener el usuario escriba su nombre y contraseña en una forma que se ejecuta un script del lado del cliente puramente lo que genera un hash basado en el nombre y PW. Eso hash se utiliza como un identificador único para el usuario, y se envía al servidor. De esta manera el servidor sólo conoce el usuario por hachís, no por su nombre.

Para que esto funcione, sin embargo, el hash tendría que ser diferente del hash de la contraseña normal, y sería necesario que el usuario introduzca su nombre / contraseña de un tiempo adicional para que el servidor tendría ninguna 'memoria' de lo que se persona compró.

El servidor podía recordar lo que la persona compró por la duración de su sesión y luego 'olvidar', debido a que la base de datos contendría ningún vínculo entre las cuentas de usuario y la información sensible.

editar

En respuesta a los que dicen hash en el cliente es un riesgo de seguridad: No es si lo haces bien. Debe suponerse que un algoritmo de hash es conocido o cognoscible. Decir lo contrario equivale a la "seguridad por oscuridad." Hashing no implica ningún claves privadas, y hashes dinámicos podría utilizarse para evitar la manipulación.

Por ejemplo, se toma un generador de hash de la siguiente manera:

http://baagoe.com/en/RandomMusings/javascript/Mash.js

// From http://baagoe.com/en/RandomMusings/javascript/
// Johannes Baagoe <baagoe@baagoe.com>, 2010
function Mash() {
  var n = 0xefc8249d;

  var mash = function(data) {
    data = data.toString();
    for (var i = 0; i < data.length; i++) {
      n += data.charCodeAt(i);
      var h = 0.02519603282416938 * n;
      n = h >>> 0;
      h -= n;
      h *= n;
      n = h >>> 0;
      h -= n;
      n += h * 0x100000000; // 2^32
    }
    return (n >>> 0) * 2.3283064365386963e-10; // 2^-32
  };

  mash.version = 'Mash 0.9';
  return mash;
}

Vea cómo los cambios n, cada vez que hash de una cadena se obtiene algo diferente.

Hash el nombre de usuario + contraseña usando un hash de algo normal. Esta será la misma que la clave de la tabla 'secreto' en la base de datos, pero coincidirá con ninguna otra cosa en la base de datos.
Anexar el pase hash al nombre de usuario y el hash con el algoritmo anterior.
Base-16 codifican var n y añadirlo en el hash original con un carácter delimitador.

Esto creará un hash único (será diferente cada vez) que puede ser verificado por el sistema frente a cada columna en la base de datos. El sistema puede ser configurado permitir un control único, en particular sólo una vez (por ejemplo, una vez al año), la prevención de ataques MITM, y ninguna de la información del usuario se pasa a través del cable. A menos que me falta algo, no hay nada inseguro acerca de esto.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow