Come implementare correttamente la pseudonimizzazione

1

Nella mia azienda vogliamo implementare la pseudonimizzazione per soddisfare alcuni requisiti GDPR . Da quello che ho capito, lo scopo della pseudonimizzazione è proibire un facile accesso a tutte le informazioni su una persona. Dare a questa persona uno pseudonimo, quindi memorizzare i suoi dati divisi in luoghi diversi. In questo modo, qualcuno che usa il sistema A, non ha un facile accesso ai dati memorizzati nel sistema B. Ma che dire degli amministratori di sistema che possono accedere ai database di tutti i sistemi e connettere facilmente i dati partizionati?

  • Va bene che gli amministratori di sistema dispongano di tale opzione?

  • Come proteggere i dati dall'accesso dagli amministratori di sistema?

  • È possibile avere dati pseudonimizzati quando ci sono persone con accesso a tutti i database?

posta Maciek 13.09.2017 - 14:39
fonte

1 risposta

1

Solo perché un amministratore di sistema ha accesso al database non significa necessariamente che l'amministratore debba avere accesso a tutti i dati. È possibile crittografare i dati per impedire all'amministratore di sistema di accedere ai dati. Se la crittografia avviene sul lato client e solo gli utenti hanno accesso alle chiavi di crittografia, è possibile progettarlo in modo che l'amministratore di sistema non sia in grado di decodificare i dati. Utilizzando la crittografia a chiave pubblica, è possibile consentire ai dati immessi da un utente di essere letti da un utente diverso, senza che il primo utente debba condividere la propria chiave di crittografia per il secondo utente.

Naturalmente la maggior parte delle applicazioni reali richiede al server di lavorare con parti dei dati, di solito per consentire la ricerca nel database, è necessario ripensare questi aspetti dell'applicazione. Forse, è possibile memorizzare un secondo campo hashed_name in modo da poter effettuare una ricerca in base al nome dell'utente senza rivelare il nome effettivo. Forse puoi memorizzare una posizione generale di indirizzi in testo semplice e avere l'indirizzo completo criptato.

Dovrai anche considerare se ci sono dati che possono essere correlati ad altri dati per perdere informazioni anche dopo la crittografia / hashing. Ad esempio, è possibile suddividere il nome di una malattia in modo da poter utilizzare il campo per la ricerca di pazienti con tale malattia, ma correlando la frequenza di occorrenza dei nomi hash può essere correlata con i dati disponibili al pubblico sulla prevalenza di malattie per ridurre il numero di possibilità che ogni nome hash può essere. Potresti considerare se tali scenari di attacco avanzati siano nel campo di applicazione o accettare il rischio di albero e limitare la pseudonimizzazione solo agli aggressori opportunisti.

È inoltre possibile applicare il partizionamento fisico in modo che i sistemi A e B siano gestiti in modo indipendente da team separati, in esecuzione su hardware e risorse separati (non condividere nulla). In questo modo, ti assicuri che nessun sistema singolo possa contenere tutti i dati e la perdita di dati richiederà almeno due persone appartenenti a team diversi di colludere.

    
risposta data 13.09.2017 - 16:29
fonte

Leggi altre domande sui tag