Nessun database centrale

31

Ho un cliente che sta cercando di creare un sito Web / app mobili / app desktop che gestiscono dati molto sensibili (più sensibili dei dati bancari / delle carte). A causa della natura sensibile dei dati, non vogliono salvarli in un database centrale ma vogliono comunque sincronizzare le loro app (diciamo che aggiungo alcuni dati nella mia app mobile, quindi voglio essere in grado di andare al mio app desktop e vedere gli stessi dati).

Non riesco a pensare a un modo carino e affidabile per farlo e non sono sicuro che ce ne sia uno. Ecco perché sono qui. Qualcuno sa come potrei gestire questi dati?

Una soluzione a cui stavo pensando era di avere un database lato client su ogni app che si sincronizzasse in qualche modo tra le app, posso vedere che questo è molto inaffidabile e che diventa disordinato.

— user2424495
fonte

2

Se si desidera che i dati vengano sincronizzati, devono comunque essere accessibili da qualche parte, in modo che i dati possano essere inseriti nell'applicazione. È possibile dividere i dati tra più database, quindi se uno di essi viene in qualche modo violato, non si perderanno tutti i dati. Se questo soddisfa il cliente, basta aggiungere più connessioni al database per l'applicazione e estrarre i dati da essi.

— Andy,

2

È un problema peer to peer? o solo 1 desktop che parla con 1 smartphone (per ogni spazio dati)?

— ebyrob,

7

È possibile garantire la riservatezza nel database crittografando i dati sul server con una chiave nota solo all'utente.

— Philipp,

26

Sembra uno schema a cui qualcuno che non capisce la sicurezza ha pensato. Chiunque abbia presentato questo requisito dovrebbe formulare una domanda sulla protezione dei dati su Security.SE .

— jpmc26,

4

@ user2424495: se i dati devono essere disponibili tramite un sito Web, i dati devono essere disponibili da dove viene fornito il sito Web, che in genere è un server centrale. O avresti bisogno di scrivere un plug-in del browser che fornisce i dati lato client.

— Bergi,

60

Molte informazioni sensibili vengono archiviate nei database. In effetti, un database centrale è probabilmente il modo più sicuro per archiviare questi dati. I database di grandi aziende hanno tonnellate di funzionalità per fare cose come crittografare le informazioni sensibili, controllare chi le accede, limitare o impedire alle persone, inclusi i DBA, di visualizzare i dati, ecc. Puoi avere esperti di sicurezza professionisti che monitorano l'ambiente e DBA professionali che sovrintendono ai backup in modo da che non perdi dati. Sarebbe quasi sicuramente molto più semplice compromettere i dati memorizzati su dispositivi mobili o laptop di alcuni utenti casuali piuttosto che penetrare in un'infrastruttura di sicurezza ben progettata e compromettere un database centrale adeguato.

È possibile progettare il sistema con un database centrale che memorizza solo i dati crittografati e memorizza la chiave privata dell'utente sul dispositivo dell'utente. In questo modo, anche se il database centrale è completamente compromesso, i dati sono utilizzabili solo dall'utente. Ovviamente, ciò significa che non è possibile ripristinare i dati dell'utente se perdono la chiave (supponiamo che l'unica copia fosse sul telefono e che il telefono fosse danneggiato). E se qualcuno compromette la chiave e, presumibilmente, le credenziali di accesso, sarebbe in grado di vedere i dati.

— Grotta di Giustino
fonte

24

@ user2424495 - Se l'obiettivo è la sicurezza effettiva, è quasi certo che i dati archiviati centralmente vincano. Dal punto di vista del marketing, potrebbe non essere colpa tua se il telefono di qualcuno viene violato. Ma sicuramente si rifletterà male sull'app se si scopre che è relativamente facile hackerare (poiché i sistemi della maggior parte delle persone sono scarsamente sicuri). Preferirei spiegare alle persone che i loro dati sono archiviati crittografati usando la sicurezza di livello militare piuttosto che sperare che non mi biasimino quando il loro telefono scarsamente protetto viene violato.

— Grotta di Giustino,

27

Questa è l'unica risposta finora che affronta davvero la domanda e fornisce il miglior risultato di sicurezza possibile. I requisiti richiesti dal PO sono ridicoli. Se i dati sono così sensibili che l'idea di essere disponibili anche su una rete pubblica è offensiva per gli utenti, l'idea dell'app non è realistica. Punto. I dispositivi client non sono sicuri e non sono affidabili.

— maple_shaft

2

@mharr se il database memorizza solo dati crittografati (crittografati prima di lasciare il dispositivo), non importa cosa dice un ordine del tribunale, non può essere fisicamente decrittografato senza le chiavi di crittografia, che solo l'utente ha.

— Richard Tingle,

9

@RichardTingle <tinfoil> A meno che l'agenzia governativa non abbia già violato la crittografia. </tinfoil>

— Bob

3

Non ho mai detto che il problema non fosse "interessante", trovo la domanda e le risposte finora molto interessanti e stimolanti. Questo è ESATTAMENTE il tipo di domanda che rende fantastico questo sito. Sto davvero mettendo in discussione i requisiti e alcune delle ipotesi che potrebbero essere fatte sui dati. Il mio rude senso mi urla solo che questi requisiti e ipotesi sull'importanza dei dati sono le riflessioni di un'azienda gonfia e adorante che si immagina informata e perspicace, ma in realtà cont ...

— maple_shaft

38

È necessario eseguire il backup di un paio di passaggi e, in consultazione con il cliente, elaborare un modello di minaccia . (Sì, questo è un collegamento a un libro di 600 pagine; sì, ti consiglio seriamente di leggere l'intera cosa.)

Un modello di minaccia inizia ponendo domande come

Perché in primo luogo l'app deve archiviare questi dati sensibili?
- Puoi evitare di memorizzarlo?
- Può essere gettato via dopo poco tempo?
- Deve davvero essere accessibile a più di un dispositivo?
- Se deve essere accessibile su più di un dispositivo, deve essere archiviato su più di un dispositivo?
Chi sono le persone autorizzate a visualizzare i dati sensibili di ciascun utente?
- Questo elenco può essere abbreviato?
Chi sono le persone che possono venire a contatto con i dati sensibili di ciascun utente mentre tentano di svolgere il proprio lavoro, ma non hanno bisogno di saperlo?
- Questo elenco può essere abbreviato?
- I dati possono essere resi inaccessibili a loro senza danneggiare la loro capacità di svolgere il loro lavoro?
- Se non può essere inaccessibile, può almeno essere reso incomprensibile? (Questo è ciò che fa la crittografia, in astratto: rende i dati incomprensibili.)
Chi sono le persone che vogliono vedere i dati sensibili, ma non sono autorizzati?
- Quali opportunità hanno di ottenere ai dati?
- Cosa vogliono fare con i dati dopo averli?
- Quanto saranno arrabbiati se non ottengono ciò che vogliono?
- Quanti soldi, tempo, cicli di CPU e sforzo umano sono disposti a spendere?
- A loro importa se qualcuno sa di aver visto i dati?
- Vogliono accedere ai dati sensibili di determinati utenti o lo faranno qualcuno?
- Cosa sanno già?
- A cosa hanno già accesso?

Una volta che conosci le risposte a queste domande, ti troverai in un posto molto migliore per capire cosa fare.

Tieni presente che potrebbe esserci più di una risposta per ogni serie di domande, in particolare quelle relative agli aggressori (le persone che desiderano i dati sensibili ma non possono averli). Se non riesci a pensare ad almeno una mezza dozzina di diversi aggressori archetipici, con motivazioni, obiettivi e risorse diverse, probabilmente ti sei perso qualcosa.

Inoltre, tieni presente che gli aggressori che causano a te (e / o al cliente) il maggior numero di problemi, hanno maggiori probabilità di fare un salto di massa nei media se il loro attacco ha successo o che fanno la maggior quantità di danno aggregato , probabilmente lo sono non gli aggressori che possono causare il massimo danno ai singoli utenti se il loro attacco ha successo. La società del cliente si occupa razionalmente di più del danno aggregato, ma gli utenti si preoccupano più razionalmente del danno a se stessi.

— Zwol
fonte

4

Questo non cerca davvero di rispondere alla domanda o di confutarla, ma questa è davvero una risposta fantastica a una domanda che non è stata posta.

— maple_shaft

11

@maple_shaft: Beh, risponde alla domanda che l'OP intendeva porre. Dal momento che la domanda potrebbe risentire del problema XY , questa sembra una buona risposta.

— sleske,

8

Un'opzione per eseguire la sincronizzazione sarebbe quella di farlo peer-to-peer. Ciò richiederà comunque un server centrale, ma quel server non gestirà nessuno dei dati.

Quando un dispositivo è online, un server centrale riceve una notifica con l'ID utente. Quando un secondo dispositivo dello stesso utente diventa online, il server invia a entrambi i dispositivi gli indirizzi IP dell'altro. I dispositivi possono quindi scambiare dati direttamente. Avvertenza: un dispositivo deve fungere da server, quindi almeno uno non può essere dietro un router NAT.

Non dimenticare che avrai bisogno di una forte autenticazione e crittografia sia per il meccanismo di notifica che per lo scambio peer-to-peer.

— Philipp
fonte

1

Sembra anche che fosse necessario uno schema di controllo delle versioni per evitare di inviare tutti i dati avanti e indietro tra i due dispositivi ...

— ebyrob

Lo scambio p2p sarebbe un'ottima soluzione, se non fosse per la necessità di forzare l'installazione non necessaria all'utente finale, il che, a mio avviso, renderebbe l'utilizzo dell'applicazione meno intuitivo. Quindi c'è la domanda se il cliente vuole scegliere tra la vulnerabilità dei dati e un po 'di confusione durante la configurazione dell'app, che dipende molto da quanto siano esattamente sensibili i dati e da quanto gli utenti si preoccupano.

— Andy,

1

@DavidPacker supponendo che tu abbia configurato e gestito il primo server, quali sono le fasi di installazione aggiuntive?

— ebyrob,

@ebyrob Potrei essere frainteso, ma capisco che il server fornito dal creatore dell'app non contenga altro che la procedura per la sincronizzazione di p2p. Ma i dati devono essere estratti attraverso questo server da uno dei dispositivi dei client - e il client deve rendere accessibile se stesso, oi suoi dati - questa è la configurazione di cui ho parlato.

— Andy,

1

@David, Philipp sta suggerendo uno scambio peer-to-peer dei dati sensibili, quindi non è possibile inviarli al o al server centrale. Il server centrale è lì solo per facilitare un peer che trova un altro peer; poi si toglie di mezzo.

— Erik Eidt,

5

Rendi il problema di qualcun altro.

Archivia i dati localmente in ciascuna app, quindi offri agli utenti la possibilità di abilitare la sincronizzazione utilizzando il proprio account con un servizio di terze parti (Dropbox, Google Drive, ecc.). Inoltre, pensa a crittografare tutti i dati caricati sul servizio di terze parti (ci sono pro e contro nel farlo).

Ciò dà l' impressione che gli utenti possiedano i propri dati, poiché devono optare per la sincronizzazione dei dati. Rende le app utili per le persone che non vogliono che avvenga alcuna condivisione. E rende qualcun altro responsabile (tecnicamente e, potenzialmente, legalmente) per il mal di testa in corso relativo alla sicurezza dei dati condivisi.

— James Mason
fonte

1

La preoccupazione del cliente sembra riguardare la visibilità di questi dati. la prima domanda da porre al cliente è se i dati sono stati crittografati, dove possono essere archiviati? Quindi, chiedi al tuo cliente quali tipi di controlli di accesso desiderano prima che i dati possano essere decifrati ed elaborati - dove può essere memorizzata la chiave di decrittazione? è una chiave separata per utente? eccetera...

Se il tuo cliente non desidera che i dati vengano archiviati da nessuna parte, desidera che l'utente lo inserisca ogni volta nella mia mano?

— Michael Shaw
fonte