SecureData anche per gli amministratori con accesso esterno

1

Data:

Un WebService che memorizza i Dati utente e un server con un database.

Un amministratore che può accedere al server con il webservice e il server con il database.

L'utente di Foreach è un database dedicato.

Obiettivo:

Archiviare i dati in modo che anche l'amministratore non possa accedervi con il segreto dell'utente.

Pensieri:

Per assicurarsi che l'amministratore non possa accedere ai dati memorizzati da molti utenti, i dati possono essere crittografati con un segreto dell'utente. e / o il database può essere creato con una derivazione del segreto dell'utente come password.

I dati possono quindi essere decodificati sul lato client.

Domanda:

Funziona con i login degli utenti più comuni in modo da poter usare la password utente o un hash come password del database / Crittografia. Ma esiste una pratica su cosa fare se l'utente si autentica con un login oAuth esterno (Google, Facebook, Github ...)? In questo caso non ho alcun segreto / password dell'utente.

Per me sarebbe un po 'imbarazzante chiedergli un "MasterKey". Ci sono esperienze su questo scenario o esempi del mondo reale?

    
posta Boas Enkler 25.07.2016 - 16:25
fonte

3 risposte

1

La regola è che se i dati sono in chiaro in qualsiasi momento su una macchina, è accessibile all'amministratore della macchina. Perché per definizione, un amministratore può utilizzare strumenti di amministrazione e può leggere la memoria di qualsiasi processo o installare spys su qualsiasi percorso di rete.

Farlo senza una buona ragione è ovviamente un errore professionale e l'amministratore può essere licenziato per questo, non parlando di azioni legali, ma tecnicamente può essere fatto.

L'unica cosa che si potrebbe fare qui sarebbe avere zone amministrative diverse e configurare il sistema in modo che gli amministratori della macchina database non possano accedere ai dati. Per questo, il server principale dovrebbe essere distinto dal server del database e il database dovrebbe contenere solo dati crittografati. Può avere senso se si dispone di un server interno ma si desidera archiviare il database esternamente per motivi di ridondanza. Ma un caso d'uso molto più comune sarebbe avere un database interno e archiviare solo dump crittografati nel cloud.

TL / DR: se non ti puoi fidare dell'amministratore, non puoi fidarti della macchina, quindi il webservice dovrebbe elaborare solo i dati crittografati, il che significa che hai bisogno di qualcos'altro e altrove per elaborare, crittografare e decrittografare i dati.

    
risposta data 21.02.2017 - 12:10
fonte
0

For me it would feel a little awkward to ask him for a "MasterKey".

Non lo è se il nucleo del servizio è quello di garantire che solo quella persona possa accedere ai dati prima decodificandoli.

L'autenticazione tramite una terza parte in questo caso non è utile, sarà meglio dargli una mano (correttamente) in modo che gli utenti abbiano solo un processo di autenticazione da passare.

    
risposta data 25.07.2016 - 17:27
fonte
0

L'ovvio problema con il tuo modello è che devi caricare e decodificare ogni record se vuoi cercare in un database. Non sta andando in scala.

Per quanto riguarda il problema della gestione del segreto, memorizzarlo nel browser, ad es. in un cookie - il mio crittografia del gestore di sessione fa questo - l'ID di sessione non è crittografato ed è l'unica chiave utilizzata per cercare i dati, quindi non c'è alcun problema con l'indicizzazione. È possibile generare un valore iniziale e consigliare all'utente di prendere una copia e archiviarla in modo sicuro (nel caso in cui perdano la copia nel cookie), quindi fornire un modo per inserire il valore in un secondo momento.

Non sono d'accordo con WoJ sull'implementazione della propria autenticazione. La maggior parte dei grandi provider impiega molte persone intelligenti e può giustificare spendere tempo a sviluppare e testare meccanismi sicuri per la gestione degli account e con i dati crittografati usando un token che la terza parte non ha accesso a te ha meno preoccupazioni in termini di il provider di autenticazione che funge da avversario.

    
risposta data 24.10.2016 - 00:47
fonte

Leggi altre domande sui tag