Come gestire le e-mail come nomi utente in GDPR?

IANAL, ma GDPR non rende la crittografia obbligatoria per i dati personali. Leggi questo articolo per comprendere meglio la complessità della crittografia e del GDPR.

In the GDPR encryption is explicitly mentioned as one of the security and personal data protection measures in a few Articles. Although under the GDPR encryption is not mandatory, it is certainly important to see where and why encryption is advised.

...

GDPR encryption: the what you should know part Before doing so let’s be clear: GDPR compliance, as we wrote before is a business strategy challenge and encrypting personal data STRICTLY SPEAKING is not mandatory.

Read more at https://www.i-scoop.eu/gdpr-encryption/

Preferibilmente esegui una valutazione dell'impatto sulla privacy . Successivamente prendi una decisione su come gestirai i dati personali. Se concludi che la crittografia dei nomi utente delle email è una buona decisione, fallo. Ad esempio se la tua applicazione web è chiamata peoplewhoarechristians.com i nomi utente saranno classificati come dati sensibili perché creano una relazione tra l'utente e la loro religione. Ma quanto sono sensibili i dati personali dipende dalla base del caso e così pure le azioni per mitigare i rischi. Anche la legge parla di " implementare misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio ", ciò che è appropriato sarà diverso a seconda del caso.

Il tuo approccio è positivo per i dati personali sensibili. Penso che sarà eccessivo per i dati personali a basso rischio. Tuttavia, vorrei documentare la tua decisione. Gli indirizzi email non sono attualmente dati sensibili per impostazione predefinita. Leggi questo articolo sulla differenza tra sensibile e non sensibile .

Potremmo sostenere che fornire un indirizzo email come nome utente significa che l'utente dà il consenso per l'elaborazione e consapevole che potrebbe perdere in combinazione con il nome della tua app. Ma meglio prevenire che curare e quindi chiederei un consenso chiaro per l'utilizzo. In questo esempio lo scopo della raccolta e dell'elaborazione dei dati personali è autenticazione e probabilmente controllo dell'accesso , ma non dimenticare analytics e cose come registrazione errori . Se prevedi di utilizzare l'e-mail per scopi di marketing, assicurati di raccogliere un ulteriore consenso.

Consiglierei un approccio diverso. Il GDPR, tra le altre cose, richiede che alcune informazioni sensibili vengano archiviate in server separati rispetto ai dati operativi. In questo modo, le JOIN saranno difficili o impossibili senza permessi adeguati. Questo è particolarmente vero nei sistemi sanitari e finanziari.

Nel tuo caso, il tuo problema è che l'email è considerata un dato personale. Senza discutere se sei eccessivo o no, ti posso suggerire un approccio di pseudonimizzazione che ti aiuta ad andare al passo precedente con facilità rispetto alla riprogettazione e alla migrazione dell'intero database.

Puoi associare ogni utente a un identificatore principale che è agnostico all'indirizzo email o al nome utente, ad esempio una chiave di incremento automatico del database o un GUID. Quindi, tutto ciò che è relativo a quell'utente può essere referenziato usando quella chiave.

Ora puoi facilmente memorizzare le credenziali di accesso in una tabella separata. In futuro, tale tabella può essere spostata su un altro database, se richiesto dall'azienda.

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,
    -----
);

Quando un utente richiede la rimozione delle informazioni personali o quando l'orologio di ritenzione dei dati fa tic tac, l'ID agnostico aiuta a mantenere le informazioni non personali in altre tabelle (ad esempio, la lista di viaggi storica diventa anonima).

Puoi spostare l'approccio sopra in avanti al livello successivo.

Considera la tabella degli account. Se si desidera consentire agli utenti di eliminare il proprio account ma tenere traccia dell'unicità dell'indirizzo e-mail (ad esempio per impedire che la gente reimpostasse la propria cronologia), è possibile annullare l'indirizzo e-mail mantenendo una colonna aggiuntiva con un hash dell'indirizzo e-mail , così mentre l'indirizzo email è annullato l'hash non lo è.

Dopodiché, quando un utente tenta di registrarsi con un vecchio indirizzo email, hai la prova che l'utente ha cancellato il suo account: sei in grado di decidere cosa fare.