Memorizza i dati di sessione in DMZ ok in un'applicazione Web enterprise a più livelli?

3

Supponiamo di avere un'applicazione web multilivello standard con server Web nella DMZ e più servizi accessibili solo da un'app Web autenticata. Supponiamo inoltre che l'app Web utilizzi le sessioni lato server.

Sono interessato all'opinione pubblica - pensi che sarebbe ok per archiviare i dati della sessione di app Web in una sorta di database ancora nella DMZ, o se tali dati si trovano in un database di back-end adeguato, incapsulato da un servizio ? (Per database nella DMZ intendo qualsiasi tipo di database, SQL, NoSQL o persino il filesystem del server web come ad esempio PHP lo fa per impostazione predefinita.)

Capisco che è tutto su ciò che voglio proteggere contro.

  • Considerando che un utente malintenzionato ha accesso solo all'interfaccia utente dell'applicazione, quasi non ha importanza (vedere in fondo) a patto che non vi sia alcuna vulnerabilità correlata alla sessione nell'applicazione, ma se ce n'è uno, i dati di sessione vengono comunque violati.

  • Considerando che un utente malintenzionato ha già accesso al server Web con l'utente che esegue l'app Web (ad esempio l'iniezione del comando OS nell'app Web), potrebbe leggere il database nella DMZ o connettersi a il servizio di sessione che utilizza le credenziali dell'applicazione.

  • Per un utente malintenzionato già root / admin sul server web è lo stesso.

  • Dal punto di vista della gestione, le operazioni IT per la DMZ e una zona protetta sono in genere le stesse persone.

  • Considerando che un attaccante ha acquisito un certo livello di accesso a qualcos'altro (non all'app Web) nella DMZ, potrebbe essere più semplice accedere ad altri server, come quello contenente i dati di sessione per questa web app. Ciò sarebbe ancora più preoccupante per un negozio di sessione come Redis in cui l'autenticazione non è un punto di forza. Ma cosa succede se non c'è nient'altro in questa infrastruttura oltre a questa applicazione in questione?

Quindi quale sarebbe il vantaggio di mettere i dati di sessione dietro un servizio? Cosa giustificherebbe il costo aggiuntivo, la complessità e la penalizzazione delle prestazioni?

Ad esempio, avendo il database di sessione nella DMZ, potrei pensare alla minaccia di errata configurazione dell'infrastruttura che consente a qualcuno di accedere al database di sessione al di fuori della rete.

Inoltre, alcune vulnerabilità non correlate nell'applicazione Web potrebbero causare la violazione dei dati della sessione, specialmente se si trova sul server Web stesso, ad esempio una semplice inclusione di file locali potrebbe essere sufficiente. Ma questo rischio può essere attenuato in altri modi in alcuni ambienti (il processo applicativo stesso non deve necessariamente avere accesso ai file del database di sessione direttamente - o potrebbe semplicemente essere un database separato, non sull'app Web).

Quindi accetteresti un'applicazione di questo tipo adeguatamente n-tier e ragionevolmente sicura al riguardo, o pensi che questa idea sia errata e che i dati di sessione debbano essere gestiti allo stesso modo di qualsiasi altro dato applicativo?

    
posta Gabor Lengyel 18.12.2016 - 15:41
fonte

1 risposta

2

In definitiva, questo si riduce al livello di rischio che sei disposto a trasportare. Per valutare ciò, è necessario comprendere l' impatto di ciascun rischio che si sta realizzando.

In questo caso, se c'è un impatto relativamente piccolo se i dati della sessione vengono violati - vale a dire che un utente malintenzionato non può utilizzare i dati della sessione per estrarre in massa dati personali identificabili o creare errori costosi - allora probabilmente stai bene per tenerlo nella DMZ con l'applicazione.

Se i dati della sessione fornissero accesso alla carta di credito o ad altre informazioni finanziarie, indirizzi, dati medici, ... - soprattutto per più utenti, direi che era un rischio significativo e vorrei vederlo meglio garantito.

    
risposta data 18.12.2016 - 21:32
fonte