Opzioni per la crittografia lato client dei database Web locali

Ho lavorato in passato su applicazioni mediche in esecuzione su dispositivi portatili che devono comunicare con un server centrale, ma devono funzionare anche quando non è presente alcuna connessione di rete.

La prima cosa da fare è fare un'analisi di sicurezza adeguata. Quali sono i rischi per i dati e in che modo riesci a proteggere i dati da tali rischi. per es.

1. Trasferimento dati sensibili della rete TCP al server.
2. Archiviazione di dati sensibili sul dispositivo
3. Identificazione dell'utente sul dispositivo
4. Identificazione del dispositivo al server
5. accesso ai dati sensibili sul dispositivo da parte di un utente identificato.

Ciò che è appropriato varierà con la natura dei dati sensibili e il prodotto coinvolto, ma per darti una guida, ecco le risposte per quel prodotto medico ...

1. I dati sulla rete sono stati crittografati da AES-256 e, ove possibile, abbiamo utilizzato una rete APN privata collegata al data center del server tramite una linea dedicata privata.

2. Sul dispositivo abbiamo archiviato informazioni mediche sensibili crittografate da AES-256 ma senza identificatori di pazienti. La chiave di crittografia era specifica del dispositivo, pertanto non è possibile accedere ai file di dati copiando i dati su un dispositivo diverso.

3. Accesso al software in cui il dispositivo era controllato da un numero pin a 3 cifre. Questo era probabilmente l'aspetto più debole, in quanto i pazienti in genere sceglievano pin semplici (ad esempio 123 o 147)

4. Ogni dispositivo si identificava con un certificato client per il server e quindi doveva fornire ulteriori identificativi forniti dal server per verificare che il dispositivo corrispondesse alle aspettative del server. Solo il server conosceva l'identità del paziente che usava quel dispositivo e l'identificazione del server consisteva nel confermare se il dispositivo era autorizzato a connettersi al server e quale dispositivo era.

5. Nel nostro caso, l'accesso alle misurazioni storiche passate era importante per i pazienti, quindi i pazienti potevano vedere le loro misurazioni storiche se il dispositivo si era autenticato con successo con il server nelle ultime 24 ore e l'ultima connessione socket avvenuta con successo ha comportato l'autenticazione del dispositivo.

App web per dispositivi mobili: se si tratta di un'app Web, in esecuzione dal browser e non in una shell nativa come PhoneGap, come si usa offline? Se è già caricato e non fa richieste (non essere disturbato dal jitter di connettività), sì, è utile, ma questo significa anche che non è possibile avviare l'app senza una connessione, giusto? Dato che si conservano molti dati sul client, un'app Phone Phone probabilmente sarà più adatta.

Sicurezza: Anche se, non so quanto sia sicura la crittografia nativa dello storage (non credo sia comunque infrangibile, comunque), sono abbastanza sicuro che dovresti attenersi al presunzione che la sicurezza dei tuoi dati locali non è la responsabilità dell'app - come hai già detto, le persone possono proteggere i loro dispositivi con password sullo schermo. Inoltre, la tua app chiederà un accesso ad ogni avvio? Non penso che tu voglia forzare l'utente ad accedere ogni volta che lo carica. Se la mia ipotesi è corretta, allora cosa impedisce l'intruso semplicemente di accendere l'app e basta leggere i dati?

Dati sensibili alla memorizzazione nella cache: Non.

Modificato (dopo i commenti)

Prima di tutto

1. Il salvataggio dei dati sensibili sul client è una questione di accordo tra l'utente e il proprietario dei dati. Dovresti entrare nei dettagli della licenza del software e nella politica sulla privacy che afferma di offrire.

2. Decidere di salvare i dati nell'applicazione client, senza un solido criterio di sincronizzazione, può creare problemi di coerenza dei dati (a parte la sicurezza).

3. Decidere di salvare i dati nell'applicazione client, può comportare un sistema complesso di sincronizzazione che accresce il carico di lavoro del database (infernale) .

4. Personalmente ritengo che il dispositivo debba essere utilizzato solo come terminale, non come parte dell'architettura.

Per questi motivi, salvare i dati localmente non è una buona opzione e +1 a Nikolay per

Caching sensitive data: Don't.

Il cliente ha ragione e non ascolta ragioni

Detto questo, se la richiesta è obbligatoria e non c'è modo di convincere il cliente / proprietario a spostarsi verso un'architettura on-demand , devi trovare tutti i trucchi per aumentare la sicurezza all'interno il cliente, proteggendo i diritti, la privacy e in generale l'accesso e l'uso dei dati.

Laproposta(cheèunadelleopportunità),consideraiseguentipuntichiave:

1. L'utentedeveaccederealsistemaalmenounavolta;
2. Dopol'accesso,eseguiremolasincronizzazionedeidatilocaliconilserver;
3. Dopolasincronizzazione,unanuovachiavedicrittografiasaràgenerata(vediidettaglidiseguito)eutilizzataintuttalasessione(anchedopoladisconnessionedalserveredallarete);
4. Tutteleinformazionielaboratedalcliente,anchedopoladisconnessione,verrannosalvateneldispositivo,utilizzandounalgoritmocheconsiderala"chiave di crittografia attualmente disponibile";

Autenticazione a due fattori

Le chiavi per crittografare i dati durante le sessioni verranno generate dopo il processo di accesso. Il secondo fattore è un elemento chiave per massimizzare la sicurezza di un prodotto che può essere definito come "non sicuro".

Questo meccanismo garantisce che se il dispositivo viene rubato (ad esempio), i dati disponibili localmente saranno limitati a una sessione, ma, soprattutto, il sistema remoto non sarà accessibile utilizzando il dispositivo.

Che dire di VPN o ...

Un prodotto sviluppato specificamente per essere utilizzato all'interno di una intranet, dove il dispositivo non ha la capacità di connettersi ad altre reti, non ha bisogno di meccanismi di sicurezza elevati, infatti, quel tipo di prodotti ha solo bisogno di identificare l'utente (useresti certificati di identità, LDAP o simili diavolerie) .

Se l'applicazione deve salvare i dati localmente e può essere distribuita in qualsiasi tipo di dispositivo (che ha i requisiti minimi), la VPN non è più un elemento di sicurezza all'interno del design.