Sicurezza dei dati visualizzati e modificati da un'app Web

Question

Sicurezza dei dati visualizzati e modificati da un'app Web

#1 da (1 voti)
#2 da (0 voti)

-2

Sto lavorando su un sistema che deve mantenere i dati sicuri e non accessibili alle persone senza accesso autorizzato. Il client è un'app Web che comunica con i server tramite API. Questo è quello che ho finora:

 __________            _____________            __________
|  Server  |          |    Server   |          |  Server  |
|  (Keys)  |          | (Web Files) |          |  (Data)  |
|__________|          |_____________|          |__________|
     |                       |                      |
    SSL                     SSL                    SSL
     |                       V                      |
     |                  __________                  |
     --------------->  |  Client  |  <---------------
                       |__________|

Server (file Web) server i file statici
Server (dati) si collega a DB (dati) e server i dati crittografati
Server (Chiavi) si connette a DB (Chiavi) e serve la chiave dati dell'utente

Il processo sarebbe:

Il client riceve i file statici dal server (file Web) tramite SSL
Il client si autentica usando Username / Password con Server (Chiavi) e ottiene la loro chiave di dati tramite SSL
Il client si connette al server (dati) e ottiene i dati crittografati tramite SSL
Il client decodifica i dati utilizzando il codice dati acquisito
Il cliente modifica i dati
Il client crittografa i dati utilizzando la chiave dati acquisita
Il client invia i dati modificati crittografati al server (dati) tramite SSL

In questo modo ogni server è isolato, ma se qualcuno ottiene l'accesso al Server (Chiavi), può lavorare per decifrare i dati in Server (Dati). C'è un modo per rendere questo più stretto, così come se uno dei server o dei DB è compromesso, non comprometterebbe la sicurezza dei dati? La configurazione corrente è comoda ma non impostata in pietra.

Modifica

La libreria personalizzata e offuscata di crittografia / decrittografia è fuori dalla finestra.
I dati sarebbero informazioni private e la loro sicurezza è imposta dal governo con la molto ampia e vaga "Le informazioni private dovrebbero essere protette contro la fuoriuscita e l'accesso non autorizzato".
Fino ad ora, il sistema era isolato ed era gestito all'interno di una rete chiusa, localmente (con lo stesso design). Ora dobbiamo consentire un ampio accesso remoto.
Se consegniamo la chiave di crittografia agli utenti del client, diventano responsabili della sua sicurezza e se la perdono, i dati diventano inaccessibili. Se è necessario essere in grado di recuperare i dati, è necessario salvare la chiave anche sui nostri server (magari crittografandola con una chiave master e rendere il processo manuale di recupero, anziché automatico).
È tornato al tavolo da disegno.

design-patterns security data

posta Basilis P. 14.12.2017 - 18:23

fonte

2 risposte

Leggi altre domande sui tag design-patterns security data

Crawler - scelta del linguaggio di programmazione [chiuso] licenza GNU e codice sorgente di hosting

score 1 · Answer 1

Ad un livello elevato, l'approccio generale sembra fondamentalmente valido, ma qui hai aggiunto molta complessità che non sembra migliorare la sicurezza. Più complicate le cose, più difficile sarà verificare che non si abbiano vulnerabilità. Aumenta anche le possibilità che tu commetta un errore.

Client is served the static files (including a customized and obfuscated encrypt/decrypt library) by Server (Web Files) via SSL

Questo è un po 'preoccupante. Personalizzato come? Non eseguire il rollover della tua sicurezza .

In realtà non è chiaro cosa ti porti a comprare chiavi su un server separato. Un utente malintenzionato avrà solo un server che deve compromettere. Non vedo alcuna differenza significativa nel controllo del solo accesso al server di dati.

In definitiva i collegamenti più deboli in questo (e molti altri) progetti sono l'uso di password per l'autenticazione. Le password sono comunemente trapelate o incrinate a causa dell'emissione debole. Indipendentemente dal fatto che l'attaccante debba accedere a uno o 1000 server, deve solo capire una singola password e il gioco è finito. Se si sta davvero cercando di migliorare la sicurezza, è consigliabile utilizzare anche una crittografia asimmetrica dal client. Ad esempio, se si sono utilizzati certificati client qui, è possibile crittografare i dati sul server utilizzando la chiave del cliente *. Quindi nessun altro sarebbe in grado di decrittarlo, incluso il server. Non è chiaro quali siano esattamente i tuoi obiettivi con questo design.

* Questo porta a domande su come il client gestisce le proprie chiavi.

score 0 · Answer 2

Se si è preoccupati che le chiavi vengano compromesse, un problema è che il server sta memorizzando le chiavi in chiaro. Ciò è problematico per gli stessi identici motivi per cui la memorizzazione di password in chiaro è problematica.

La differenza è che per le password è sufficiente memorizzare il loro hash. Ma l'utente avrà bisogno di ottenere la chiave in chiaro.

Una possibile soluzione potrebbe essere per gli utenti crittografare e decrittografare la chiave con una passphrase, in modo che il server delle chiavi non veda mai la chiave in chiaro. A seconda della definizione di "sicuro", ciò significa che la passphrase della chiave non deve mai essere trasmessa al server. Quando dico "crittografare la chiave con una passphrase", questo non significa che dovresti XOR la chiave con una passphrase letterale, ma dovresti usare un algoritmo di estensione della chiave per ricavare una chiave dalla passphrase dell'utente.

La somiglianza con le password è che questa crittografia non sarà impenetrabile quando le chiavi crittografate sono compromesse. Le password bloccate e le chiavi crittografate possono essere violate. Poiché le password (comprese le password che codificano le chiavi) tendono ad essere deboli, questo richiede solo un po 'di tempo in media prima che l'utente malintenzionato ottenga una chiave in chiaro. Durante questo periodo, gli utenti dovranno decifrare i dati con la loro vecchia chiave compromessa e ricodificarli nuovamente con una nuova chiave.

Se hai bisogno di maggiore sicurezza (per alcune definizioni di "sicurezza"), non memorizzare affatto queste chiavi. La chiave non dovrebbe mai lasciare i dispositivi dell'utente.

Si noti che il server Web statico rappresenta un enorme rischio per la sicurezza, probabilmente anche più del server delle chiavi. Il codice servito da questo server funziona su chiavi in chiaro e dati in chiaro sul dispositivo dell'utente. Se questo codice dovesse essere sostituito con un'implementazione dannosa che estrapola le chiavi o i dati, la maggior parte degli utenti non sarebbe in grado di notarlo.

Se si dispone di dati estremamente sensibili, l'utilizzo di uno schema di deposito chiavi non sarà sufficientemente sicuro. Anche l'esecuzione della decrittografia su un dispositivo connesso in rete è discutibile.

Se disponi di dati ordinariamente più sensibili, tutto ciò sembra un enorme eccesso. Tutta questa criptografia è complessità e la complessità genera bug. Nel contesto della sicurezza e della crittografia, anche bug di piccole dimensioni o canali secondari possono essere superati.

Invece, preferisci soluzioni ben comprese che hanno un supporto di strumenti maturo. Per te, è probabile che gli utenti accedano direttamente al server dati utilizzando nomi utente + password. È necessario accoppiarlo con soluzioni di limitazione della frequenza, monitoraggio e rilevamento delle intrusioni. È più semplice proteggere un singolo server piuttosto che proteggere tutti i client che si connettono a quel server. Questo fornisce un buon argomento per fornire dati in chiaro dal server. La sola pubblicazione di dati crittografati ha un valore marginale, presupponendo che i client si fidino di te (cosa che fanno, se tu potessi memorizzare le loro chiavi in chiaro).