Non sensibili / non critici Database e protezioni del server Web?

Il server di database non critico non deve necessariamente trovarsi dietro un secondo firewall, ma si consiglia di risiedere in una DMZ separata o in una VLAN separata all'interno della stessa DMZ (con le ACL in atto) al minimo indispensabile .

Se capisco correttamente la tua spiegazione, sembra che il server di database non critico nella DMZ sia collegato tramite ODBC ai server di database critici sulla LAN?

Da quale parte è autorizzata la comunicazione attraverso il firewall?

Se il server di database non critico è autorizzato ad avviare la comunicazione con i server di database critici sulla LAN (per estrarre i dati), ciò è molto negativo.

Se i server di database critici sulla LAN stanno avviando la comunicazione con il server di database non critico (per inviare dati) questo è più preferito.

Senza conoscere i dettagli intimi, sto chiedendo perché questo server di database non critico debba interfacciarsi con server di database critici se non memorizza dati sensibili?

Cose da tenere a mente:

Se questa applicazione Web non sensibile è vulnerabile all'iniezione SQL, il database non critico verrà compromesso.

Se il server Web è compromesso dalla vulnerabilità XYZ, può essere utilizzato come punto di attacco per il server di database non critico.

La risposta di k1BLITZ risolve un punto chiave, ovvero la necessità per la DMZ di ottenere solo il traffico in entrata. Ciò assicurerà che, nel caso in cui qualcuno prenda il controllo dei server nella DMZ, non sarà in grado di andare oltre (verso la LAN).

Per rispondere alle altre preoccupazioni:

• se il server Web DMZ è compromesso, può ovviamente visualizzare qualsiasi cosa, inclusa una richiesta per l'autenticazione degli utenti, fornire dettagli sensibili ecc. Quindi, anche se l'integrità dei dati è preservata nei database LAN, essi può ancora fuoriuscire tramite gli utenti.

• non provare a reinventare la ruota. Usa OWASP come guida, in particolare nel tuo caso la sezione su SQL .

L'odio è fondamentale, ma penso che debba essere sottolineato. Innanzitutto la soluzione al problema è in realtà centrata sull'applicazione e non sul problema della rete centrale. Il metodo della correzione si basa sulla porta legacy e sui metodi di protezione del processo. Ignora la realtà delle tue altre superfici di attacco.

In primo luogo, a seconda del tipo di firewall in uso possono essere le capacità a dpi limitati (deep packet inspection). La maggior parte delle vulnerabilità avviene a livello di applicazione e questa è l'area di interesse principale che verrà affrontata a livello di applicazione. La tua area di superficie primaria da internet sarà il server web. Una cosa a cui DPI aiuterà è limitare il tipo di istruzioni che possono essere eseguite sul server, a meno che la connessione non venga crittografata dal server web al DB.

Anche se le risorse non sono critiche o hanno dati sensibili, c'è un livello di impatto se il DB è interessato.

Una soluzione che potrebbe essere più sicura basata sul digram. Ecco un rapido diagramma del foo stick.

HTTP REQ- > endpoint_filter- > SQL-statment-code-> dichiarazione-filtro > & gt SQL_Connection_timer-; foo

HTTP_RESP < -DPI < -Return Function < -foo             -Lunghezza             -filter N

Vedo che molte aziende sono spuntate a causa del pensiero centrato sulla rete.