SecureData anche per gli amministratori con accesso esterno

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.

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.

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.