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.