informazioni crittografate che non sono accessibili agli amministratori di database

1

Lavoro con asp.net core 1 e introdurrò una memoria crittografata di dati utente. Questi dati non devono essere accessibili all'amministratore del database ma solo agli utenti con una passphrase.

Ho pensato di usare:

  1. IdentityServer per garantire l'autenticazione. (Con TLS).
  2. Cripta i dati utente con una chiave simmetrica. (Posso usare TDE? è possibile nascondere la chiave agli amministratori?)
  3. Cripta la chiave simmetrica con la passphrase.
  4. Salva solo un hash della passphrase.

Gli attacchi di forza bruta degli amministratori potrebbero recuperare i dati?

Potrebbe essere migliore?

    
posta Sergio 31.01.2017 - 12:48
fonte

1 risposta

1

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?

  1. 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.

  2. 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.

  3. 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.

    
risposta data 13.02.2017 - 10:46
fonte