Il modo più sicuro per fornire app web per l'accesso offline [chiuso]

3

Dopo aver creato un'app Web basata su uno stack PHP distribuito su un server, mi piacerebbe avere un modo per fornire l'accesso offline. C'è un database di pazienti e appuntamenti che deve essere consultato per l'accesso in lettura quando una connessione è inattiva o non disponibile. L'accesso all'app Web richiede un accesso all'account.

La preoccupazione è che, data la natura sensibile dei dati, sia in termini di codice che di DB, la semplice distribuzione dell'app Web localmente nella sua forma originale non è sicuramente un'opzione.

Mi chiedevo se mettere insieme una VM criptata in bundle con l'app Web e un server Web avrebbe fornito abbastanza sicurezza. Al client verrà richiesta una password, eseguirà la VM e si connetterà all'app Web utilizzando un indirizzo locale, nello stesso modo in cui lo farebbero per il server remoto.

Le mie aspettative in termini di sicurezza sarebbero che un utente malintenzionato con accesso al sistema locale non avrebbe:

  1. essere in grado di accedere alla VM
  2. ha accesso al codice effettivo dell'app Web mentre la VM è in esecuzione
  3. ha accesso ai dati del DB mentre la VM è in esecuzione
  4. non può dedurre informazioni sensibili tramite il dump della memoria mentre VM è in esecuzione
  5. anche se copiano l'immagine non saranno in grado di usarlo senza la password

Questo è realizzabile con una VM e quanta protezione fornisce? Da quello che ho visto, il tipo di fornitore di informazioni è disposto a fornire, è più in termini di passaggi di configurazione e meno in termini di funzionalità di sicurezza.

Mi chiedevo inoltre se fornire una versione ridotta dell'applicazione web come un client eseguibile offuscato (che dovrei reimplementare da zero e mantenere sincronizzato con l'effettiva app web) e un database crittografato potrebbe fare per una soluzione migliore.

    
posta Nick 02.11.2015 - 11:26
fonte

2 risposte

0

Dipende dalla piattaforma di virtualizzazione, ma praticamente tutte le scommesse sono disattivate se un utente malintenzionato accede alla VM mentre è in esecuzione. Supponendo che possano riavviarsi senza bisogno di inserire una password, possono ottenere l'accesso di un singolo utente e prendere qualsiasi dato che vogliono a quel punto.

Allo stesso modo, non hai alcun controllo sul sistema che viene utilizzato per eseguire l'immagine - se butta la memoria su disco, i dati verranno scaricati. Un aggressore sufficientemente motivato potrebbe scrivere un sistema di virtualizzazione compatibile con questo comportamento.

Idealmente, non si desidera memorizzare a livello locale i dati completi. Una soluzione migliore, anche se ovviamente più costosa, potrebbe essere quella di esaminare le connessioni ridondanti a questo sistema, poiché è chiaramente critico per la pratica. In alternativa, potrebbe essere possibile eseguire un server locale con una copia dei dati - questo ha molti degli stessi problemi di un'appliance virtualizzata, ma può probabilmente essere monitorato per manometterli più facilmente e archiviato in una posizione fisicamente protetta che consente l'accesso fisico più difficile. Questo server dovrebbe altrimenti essere trattato allo stesso modo del server delle applicazioni principale, ricevere le patch e essere adeguatamente firewallato - sarebbe effettivamente un mirror del server principale. Questo dovrebbe essere preso in considerazione solo se c'è sufficiente esperienza tecnica nella gestione di sistemi ad alto rischio.

    
risposta data 02.11.2015 - 12:20
fonte
0

@matthew ha già parlato degli svantaggi dell'utilizzo di una VM per questo. Voglio aggiungere che per un'applicazione di questo tipo utilizzerei un servizio Web, se il budget è un problema, è possibile archiviare il front-end in una scheda Raspberry Pi o Arduino che è molto economica. L'idea è che il front-end sia sempre sottoposto a rendering, ma le informazioni richiedono una connessione lato server o l'utilizzo di web worker è possibile impostare una coda che elaborerà le attività quando viene ristabilita una connessione. Può essere implementato come App Chrome o simile, questi tipi di app sono pensati per "offline first "access, come indicato nel capitolo" Develop in the Cloud ". Il punto principale è che il livello di presentazione non deve necessariamente essere associato al livello di rete. Questo capitolo ("Prima non in linea") presenta alcuni aspetti molto positivi sulla sicurezza.

I problemi di sicurezza in questo caso sono legati alla crittografia, vorrei anche prendere in considerazione l'uso di token temporanei per la crittografia, quindi anche se un'attività viene recuperata dal front-end prima di essere inviata ed eliminata, il sale usato per hash sarebbe diverso da un altro compito.

    
risposta data 02.11.2015 - 13:11
fonte

Leggi altre domande sui tag