Nessun database centrale

Un sacco di informazioni sensibili vengono archiviate nei database. In effetti, un database centrale è probabilmente il modo più sicuro per archiviare questi dati. I grandi database aziendali hanno tonnellate di funzionalità per fare cose come crittografare informazioni sensibili, per controllare chi accede, limitare o impedire a persone che includono DBA di visualizzare i dati, ecc. È possibile avere esperti di sicurezza professionali che monitorano l'ambiente e DBA professionali che supervisionano i backup così che non perdi dati. Sarebbe quasi certamente molto più facile compromettere i dati archiviati su un dispositivo mobile o laptop di un utente casuale 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 (ad esempio, l'unica copia era sul proprio telefono e il loro telefono era danneggiato). E se qualcuno compromette la chiave e, presumibilmente, le credenziali di accesso, saranno in grado di vedere i dati.

Devi eseguire il backup di un paio di passaggi e, in consultazione con il tuo cliente, elaborare un modello di minaccia . (Sì, questo è un link a un libro di 600 pagine, sì, sto seriamente raccomandando di leggere l'intera cosa.)

Un modello di minaccia inizia ponendo domande come

• Perché l'app deve memorizzare questi dati sensibili in primo luogo?
  • Puoi evitare di memorizzarlo affatto?
  • Può essere buttato via dopo poco tempo?
  • Ha veramente bisogno di essere accessibile a più di un dispositivo?
  • Se deve essere accessibile su più di un dispositivo, deve essere memorizzato su più di un dispositivo?
• Chi sono le persone a cui è consentito vedere i dati sensibili di ciascun utente?
  • È possibile rendere questo elenco più breve?
• Chi sono le persone che potrebbero entrare in contatto con i dati sensibili di ciascun utente mentre cercano di svolgere il proprio lavoro, ma non hanno bisogno di saperlo?
  • Può questo elenco essere reso più breve?
  • I dati possono essere resi inaccessibili a loro senza danneggiare la loro capacità di svolgere il proprio 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 per vedere i dati sensibili, ma non sono ammessi?
  • Quali opportunità hanno per ottenere i dati?
  • Che cosa vogliono fare con i dati una volta che ce l'hanno?
  • Quanto saranno arrabbiati se non ottengono ciò che vogliono?
  • Quanto denaro, tempo, cicli di CPU e sforzo umano sono disposti a spendere?
  • Gli interessa se qualcuno conosce ha visto i dati?
  • Vogliono accedere ai dati sensibili di utenti specifici o qualcuno lo farà?
  • Che cosa sanno già?
  • A cosa hanno già accesso?

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

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

Ricorda inoltre che gli attaccanti che causano più problemi a tu (e / o al cliente), sono i più propensi a fare un grande salto nel media se il loro attacco ha successo, o chi infligge il maggior numero di danni aggregati , probabilmente non sono gli attaccanti che possono causare il danno maggiore a singoli utenti se il loro attacco ha esito positivo. La compagnia del tuo cliente si preoccupa in modo razionale del danno aggregato, ma gli utenti si preoccupano più razionalmente del danno a se stessi.

Un'opzione per fare la sincronizzazione sarebbe quella di farlo peer-to-peer. Ciò richiederà comunque un server centrale, ma quel server non gestirà alcun dato.

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

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

Rendilo il problema di qualcun altro.

Archivia i dati localmente in ogni 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 i dati caricati sul servizio di terze parti (ci sono pro e contro a farlo).

Ciò conferisce all'aspetto che gli utenti possiedono i propri dati, poiché devono optare per la sincronizzazione dei dati. Rende le app utili per le persone che non vogliono che una condivisione avvenga. E rende responsabile qualcun altro (tecnicamente e, potenzialmente, legalmente) per i continui grattacapi di mantenere sicuri tutti i dati condivisi.

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

Se il tuo cliente non desidera che i dati siano archiviati ovunque, vogliono che l'utente inserisca ogni volta la mia mano?