¿Cómo manejar los correos electrónicos como nombres de usuario bajo GDPR?

IANAL, pero GDPR no hace que el cifrado sea obligatorio para los datos personales. Lea este artículo para comprender mejor la complejidad del cifrado y GDPR.

  

En el cifrado GDPR se menciona explícitamente como una de las opciones de seguridad   y medidas de protección de datos personales en algunos artículos. A pesar de que   bajo el cifrado GDPR no es obligatorio, es ciertamente importante   para ver dónde y por qué se recomienda el cifrado.

     

...

     

Cifrado GDPR: la parte que debería saber   Antes de hacerlo, seamos claros: el cumplimiento de GDPR, como escribimos anteriormente, es un desafío de la estrategia empresarial y el cifrado de datos personales NO ES OBLIGATORIO HABLAR ESTRICTAMENTE.

     

Lea más en enlace

Es preferible que realice una Evaluación del impacto en la privacidad . Luego, tome una decisión sobre cómo manejará los datos personales. Si concluye que el cifrado de los nombres de usuario de correo electrónico es una buena decisión, hágalo. Por ejemplo, si su aplicación web se llama peoplewhoarechristians.com , los nombres de usuario se clasificarán como datos confidenciales porque crean una relación entre el usuario y su religión. Pero la sensibilidad de los datos personales dependerá de cada caso y las acciones para mitigar los riesgos. Además, la ley habla de una " implementar medidas técnicas y organizativas adecuadas para garantizar un nivel de seguridad adecuado al riesgo ", lo que sea apropiado será diferente para cada caso.

Su enfoque se siente bien para los datos personales confidenciales. Creo que será una exageración para los datos personales de bajo riesgo. Aún así me gustaría documentar su decisión. Las direcciones de correo electrónico actualmente no son datos confidenciales de forma predeterminada. Lea este artículo sobre la diferencia entre sensible y no sensible .

Podríamos argumentar que dar una dirección de correo electrónico como nombre de usuario significa que el usuario da su consentimiento para el procesamiento y es consciente de que podría filtrarse en combinación con el nombre de su aplicación. Pero es mejor prevenir que lamentar y, por lo tanto, pediría un consentimiento claro para el uso. En este ejemplo, el propósito de la recopilación y el procesamiento de datos personales es autenticación y probablemente control de acceso , pero no olvide analytics y cosas como registro de errores . Si planea utilizar también el correo electrónico con fines de marketing, asegúrese de obtener un consentimiento adicional.

Recomendaría un enfoque diferente. El GDPR, entre otras cosas, requiere que cierta información confidencial se almacene en servidores separados de los datos operativos. De esta manera, las JOIN serán difíciles o imposibles sin los permisos adecuados. Esto es especialmente cierto en los sistemas de salud y financieros.

En su caso, su problema es que el correo electrónico se considera un dato personal. Sin discutir si es excesivo o no, puedo sugerirle un enfoque de pseudonimización que lo ayude a ir al paso anterior con facilidad que rediseñar y migrar toda la base de datos.

Es posible que desee asociar a cada usuario un identificador primario que sea agnóstico a la dirección de correo electrónico o nombre de usuario, por ejemplo una clave de incremento automático de la base de datos o un GUID. Luego, se puede hacer referencia a todo lo relacionado con ese usuario usando esa tecla.

Ahora, puede almacenar fácilmente las credenciales de inicio de sesión en una tabla separada. En el futuro, dicha tabla se puede mover a una base de datos diferente si así lo requiere la empresa.

CREATE TABLE users(
    userid VARCHAR(64) PRIMARY KEY, --uuid generated
    language VARCHAR(2) NULL,
    theme VARCHAR(30) NULL,
    ....
    ......  -- any information that is not strictly protected by GDPR
);

CREATE TABLE accounts(
    userid VARCHAR(64) NOT NULL PRIMARY KEY,
    email VARCHAR(256) NULL,
    password_hash VARCHAR(64) NULL,
    failed_logins INT NOT NULL DEFAULT 0,
    last_login DATETIME NULL,
    -----
);

Cuando un usuario solicita la eliminación de información personal, o cuando el reloj de retención de datos marca, el ID de agnóstico le ayuda a mantener la información no personal en otras tablas (por ejemplo, la lista de viajes histórica se está volviendo anónima).

Puedes mover el enfoque anterior al siguiente nivel.

Considere la tabla de cuentas. Si desea permitir que los usuarios eliminen su propia cuenta pero mantengan un registro de la unicidad de la dirección de correo electrónico (por ejemplo, para evitar que las personas reinicien su historial), puede anular la dirección de correo electrónico pero mantener una columna adicional con un hash de la dirección de correo electrónico. , de modo que mientras la dirección de correo electrónico está anulada, el hash no lo está.

Después de eso, cuando un usuario intenta registrarse con una dirección de correo electrónico más antigua, tiene pruebas de que el usuario ha eliminado su cuenta: usted puede decidir qué hacer.