Applicazione web singola: vantaggi di sicurezza per due modelli di server?

Question

Applicazione web singola: vantaggi di sicurezza per due modelli di server?

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

4

Sto cercando di distribuire l'infrastruttura per un'applicazione web che vivrà su uno stack LAMP. L'infrastruttura è tale che questa è l'unica applicazione che potrà mai vivere su questo server e deve essere il più sicuro possibile.

Tradizionalmente, distribuiamo un server front-end in una DMZ e disponiamo di un server DB su una rete segregata e tra loro c'è una regola del firewall che consente solo le chiamate TCP 3306 dal server Web al server database. Quando più applicazioni vivono su un server, vedo la rilevanza lì come se un'applicazione / un sito venisse compromessa, quindi esiste la possibilità di mettere in quarantena i danni all'applicazione e all'amplificatore. credenziali che sono state raccolte.

Con una singola applicazione web sto cercando di capire come ciò possa fornire un vantaggio in termini di sicurezza. In teoria, se il tuo server web viene compromesso, le persone avranno accesso alle credenziali del DB che l'applicazione utilizza a quel punto è game over, giusto?

Da una prospettiva strettamente di sicurezza quali sono i principali motivi per dividere l'applicazione nei server front e back end?

network webserver web-application databases

posta user116218 30.06.2016 - 15:04

fonte

3 risposte

Leggi altre domande sui tag network webserver web-application databases

Come forzare Firefox a ricordare le password? La pubblicazione della tecnica che ho usato per crittografare il mio sistema Linux rende la crittografia intrinsecamente meno sicura?

score 1 · Answer 1

In generale, sono d'accordo con la tua implicazione che se hai solo una singola applicazione web c'è un piccolo vantaggio di sicurezza per lo spostamento del DB su un server separato. Detto questo, potrebbero esserci alcuni scenari artificiali in cui potrebbe esserci un vantaggio in termini di sicurezza. Ad esempio, se l'applicazione Web non dispone di diritti di amministrazione completi sul DB, un server Web compromesso potrebbe rivelare credenziali per un accesso al DB, ma non per tutti. Se il DB risiedeva sullo stesso server Web, presumibilmente l'autore dell'attacco potrebbe essere in grado di ottenere anche l'accesso completo al DB, piuttosto che limitarsi all'accesso limitato per le credenziali rilevate. Un esempio di diritti di DB parziale potrebbe dare l'accesso in scrittura dell'applicazione Web a una tabella di registrazione ma non l'accesso in lettura.

score 0 · Answer 2

Le prestazioni e la scalabilità vengono migliorate distribuendole su due server.
Posso immaginare qualcuno che commette errori di configurazione e che apre più porte sul server del database. A causa della presenza del firewall, questo non porterà facilmente a una vulnerabilità.

score 0 · Answer 3

Separarli potrebbe rendere il tuo sistema molto più difficile da attaccare.

Ad esempio, diciamo che c'è un difetto di iniezione SQL sul tuo sito web. L'autore dell'attacco potrebbe essere in grado di utilizzare SELECT INTO OUTFILE per scrivere una shell sul tuo sistema.

per es.

http://192.0.2.42/comment.php?id=738
union
all
select
1,2,3,4,"<?php
echo
shell_exec($_GET['cmd']);?>",6
into
OUTFILE
'c:/xampp/htdocs/backdoor.php'

Poiché il database viene eseguito sullo stesso server, questo riesce a scrivere la shell sulla web root dove l'hacker può accedervi tramite il sito Web e ottenere il controllo del server.

Naturalmente, il permesso del file system per l'account di processo mysql e la web root dovrebbero normalmente essere impostati in modo appropriato con il minimo richiesto, ma la segregazione dei servizi su server diversi è buona difesa in profondità approccio.

Inoltre, non tutti gli attacchi sono uguali. Potrebbe esserci un attacco che ottiene l'autorizzazione di root sul tuo server web, ma l'utente malintenzionato potrebbe solo accedere alle tabelle del database che l'utente del sito web ha le autorizzazioni per leggere (di nuovo, difesa in profondità - assicurati che le autorizzazioni del database siano impostate con principio del privilegio minimo come obiettivo). Se il DB si trovava nella stessa casella, l'utente malintenzionato avrebbe il controllo completo di tutti i dati.