Come gestire la sicurezza dei dati temporanei sul server web?

Question

Come gestire la sicurezza dei dati temporanei sul server web?

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

-2

Sono principalmente uno sviluppatore ASP.NET ma questa domanda si applica in realtà indipendentemente dalla lingua. Quindi, ovviamente, è una buona idea prevenire gli attacchi esterni che derivano anche da attacchi di sequestro di sessione e csrf. Ma che dire degli attacchi interni quando i dati coinvolti sono temporanei, necessari per l'intera sessione ma anche sensibili e meritevoli di furto? C'è naturalmente solo l'assunzione di persone fidate, ma diciamo che non si applica.

Supponiamo che tu abbia già le revisioni del codice e le severe autorizzazioni di accesso ai dati di produzione per prevenire il furto da parte degli sviluppatori. L'applicazione crittografa i dati sensibili prima di archiviarli per impedire il furto di dbas.

Come si proteggono i dati sensibili temporanei contro gli amministratori del server Web? Sembra che possano recuperare le informazioni ispezionando i registri del server Web, lo sniffing del traffico e l'ispezione dei contenuti della memoria del processo. Naturalmente direi che gli amministratori del server web di produzione non hanno accesso al codice sorgente non elaborato.

web-development security

posta Peter Smith 28.07.2012 - 20:24

fonte

3 risposte

Leggi altre domande sui tag web-development security

Il diagramma di sequenza dovrebbe consistere in oggetti View, oggetti DB, ecc.? Quali sono i pattern e le pratiche o le strutture per Managed Extensibility Framework? [chiuso]

score 3 · Answer 1

Se non ti puoi fidare dei tuoi amministratori di sistema con i tuoi server, quasi tutto è perduto. L'unico modo per proteggere i dati sensibili da qualcuno con accesso root / amministratore a una macchina di produzione è crittografarlo con una chiave inaccessibile a sysadmin; ad esempio, se i dati vengono sempre utilizzati solo sul client, è possibile prendere in considerazione la crittografia sul lato client. Ma anche in questo caso, non c'è nulla che impedisca a un amministratore di sistema canaglia di cambiare semplicemente il codice lato server che causa la crittografia lato client, beh, non crittografare più o utilizzare una chiave di crittografia compromessa. Guadagni poco, ma sacrifica molta convenienza e prestazioni.

Questo non significa che non dovresti considerare i dati temporanei da un punto di vista della sicurezza: spesso, ci sono molti utenti con accesso non privilegiato a un server; anche se questi non possono accedere direttamente (ad esempio account di servizio), un utente malintenzionato che sfrutta altre vulnerabilità può ottenere molto bene una shell con tale utente. L'uso ingenuo di memcache è facilmente sfruttabile: è sufficiente connettersi a memcache localmente, trovare la chiave che ti interessa e leggere i dati. Tempfile è leggermente più difficile da raggiungere, ma certamente non impossibile.

Come per tutte le cose di sicurezza: definire le minacce, trovare possibili attenuazioni e fare un'analisi costi / benefici.

score 0 · Answer 2

La cosa migliore che puoi fare è limitare chi ha accesso a cosa. Le persone con accesso alle caselle di produzione non dovrebbero avere accesso al codice. Le persone con accesso al codice non dovrebbero avere accesso alle caselle di produzione (ovviamente ci saranno eccezioni temporanee a quelle, come la necessità di indagare su un bug che si verifica solo sulle scatole di produzione) Come hai detto tu, un amministratore di sistema può sempre annusare la rete, o persino inserire l'app in un emulatore e registrare tutti gli accessi rilevanti in memoria. Non c'è proprio niente che puoi fare al riguardo.

Tutte le fughe di dati recenti che abbiamo visto provengono da persone con accesso autorizzato ai dati (la maggior parte delle fonti wikileak), memorizzazione delle password mal implementata (vapore, Sony ...) o da exploit 0day. Crittografare la tua memoria non ti aiuterà in nessuno di questi casi, che è più probabile che non sia vulnerabile a.

score -1 · Answer 3

Nella mia esperienza, una volta che un'applicazione web è attiva, gli amministratori web ne sono responsabili. I dati non devono essere nascosti agli amministratori di sistema solo nel caso in cui sia necessario intraprendere azioni di emergenza per correggere un bug. Nella migliore delle ipotesi è possibile nascondere e crittografare i dati, ma ciò non garantisce la sicurezza. L'unico server web sicuro è uno che viene disconosciuto da Internet e bloccato in una cassastrong.