Se si desidera che i dati siano assolutamente inaccessibili dagli amministratori, i dati non crittografati non possono mai raggiungere i server che controllano. Inoltre, la chiave di decrittografia non può essere sul server, dal momento che, se lo fosse, un amministratore malintenzionato potrebbe prendere sia i dati crittografati che la chiave e decrittografarlo.
Quindi, quali opzioni hai?
-
Crittografia lato client. Se l'utente finale crittografa i dati utilizzando una chiave che non viene mai inviata al server e i dati crittografati vengono inviati al server, non è possibile per l'amministratore decrittografarlo, ma l'utente può scaricarlo e decrittografarlo, purché avere la chiave. Sarebbe meglio criptare con una chiave derivata da una password che dalla stessa password, solo da una prospettiva di lunghezza della chiave - questo non è per niente raro.
Il problema che hai con questo, se sei preoccupato per gli amministratori che cercano di accedere ai dati, è che possono presumibilmente modificare il codice di crittografia inviato al client, se stai usando JS - hanno accesso al server. Non sarebbe particolarmente difficile crittografare i dati due volte, una volta con la chiave utente e una volta con una chiave nota agli amministratori. Puoi impedire la manomissione in transito (ecco perché hai abilitato SSL), ma l'amministratore che può modificare i contenuti del sito può probabilmente modificare qualsiasi checksum utilizzato per preservare l'integrità del codice lato client.
-
Richiede che l'utente esegua la crittografia prima di inviarlo. Se l'utente finale utilizza un'applicazione di crittografia di terze parti, i tuoi amministratori non possono fare nulla al riguardo, se non la forza bruta, che dovrebbe essere difficile. Tuttavia, riduce il servizio a un archivio di file, che potrebbe non essere accettabile.
-
Diffondi il rischio. Avere un server che serve le routine di crittografia al client, che è gestito dalla società A. Avere un server che riceve dati crittografati e li memorizza, che è gestito dalla società B. Avere il resto dell'applicazione web su un server gestito dalla società C. L'utente finale riceve il codice di crittografia dal server A, che è presumibilmente non modificato, poiché gli amministratori di quel server non vedono mai i dati crittografati e non possono modificare il codice senza interrompere i checksum forniti dal server C. Il loro computer crittografa con il chiave lato client (che non viene mai inviata da nessuna parte) e invia i dati al server B.
Gli amministratori di A non possono manomettere la crittografia o i dati inviati a meno che non collaborino con gli amministratori di C. Gli amministratori di C possono modificare dove vengono inviati i dati o inviare routine di crittografia errate, ma B può segnalare se non stanno ottenendo alcun dato. Gli amministratori di B dovrebbero ottenere o gli amministratori da C per passare loro la chiave, o gli amministratori da A per modificare le routine di crittografia per ottenere l'accesso.
Ora, questo sembra uno scenario molto complicato, ma questo mostra solo quanto potere hanno gli amministratori del server - per definizione, hanno accesso per leggere e modificare praticamente qualsiasi cosa.
Fondamentalmente ti trovi in un compromesso tra facilità di manutenzione e sicurezza - l'opzione 1 è facile da mantenere, dal momento che hai il pieno controllo del server da un singolo punto. L'opzione 3 è difficile, dal momento che è necessario coordinare eventuali cambiamenti tra più amministratori, ma rende davvero difficile per qualsiasi individuo ottenere i dati. Se vale la pena, lo sforzo dipende dai dati che vengono archiviati.