È sufficiente avere un singolo database all'interno della DMZ da cui i server web della DMZ ricevono i loro dati.
O se l'installazione con due database è una soluzione migliore, sarebbe di avere un database nella rete interna da cui riceve il database nella DMZ?
La tua domanda è un po 'vaga, quindi ti consiglio di prendere in considerazione i modelli di minacce che stai cercando di proteggere da te.
La prima cosa da fare è definire che una DMZ è una regione della tua rete che è considerata totalmente o parzialmente non sicura, perché è collegata a Internet (oa qualche altra rete non sicura e ostile). DMZ definisce un limite di sicurezza tra l'infrastruttura e il tuo ambiente interno più affidabile. Questo limite di sicurezza viene solitamente applicato da un firewall o controlli di rete simili. Potresti dire "sì, lo so", ma ho visto persone completamente fraintendere il punto di una DMZ e voglio essere sicuro che siamo su una base solida.
La mia comprensione è che si è preoccupati di mantenere il proprio database nella DMZ insieme al server Web, perché si dispone di apparecchiature interne dalla rete attendibile che si connettono a quel database. Questa è una configurazione comune, e molte persone si comportano bene, consentendo le connessioni dalla rete fidata al database nella DMZ.
Tuttavia, una cosa da considerare è il modello di autenticazione. Se si esegue l'autenticazione su un server MSSQL nella DMZ tramite AD e il controller di dominio non si trova nella DMZ (spero non lo sia!) È necessario consentire il traffico AD tramite il firewall. Questa non è una buona idea, davvero. Quindi, utilizzando la replica del database per sincronizzare i dati attraverso il limite DMZ in modo che il database interno possa essere autenticato tramite AD, mentre il database esterno (cioè basato su DMZ) non fa Ho bisogno di parlare con la DC, è in realtà una soluzione piuttosto buona.
È meglio NON usare affatto una DMZ.
ma se è necessario, si presuma che tutto nella DMZ sia compromesso e dovrebbe essere diffidato e presumibilmente trapelato agli altri. quindi la soluzione migliore sarebbe spostare il DB e il webservice al di fuori della DMZ e utilizzare un proxy inverso all'interno del proprio DMX. (e assicurarsi che il server web possa parlare solo con il proxy e il DB solo con il server web) quando si esegue questa operazione. e tutte le altre tecniche standard e misure di sicurezza che potresti essere al sicuro dagli aggressori. (è ancora necessario eseguire un controllo di sicurezza come indicato in un commento di @Polynomial)
- Ulteriori informazioni su DMZ.
I DMZ sono sistemi che sono al di fuori della normale protezione e delle guardie di sicurezza (ad es. senza tutte le cose che normalmente devi proteggere da un uso improprio). in realtà non esiste un valido motivo per avere un sistema in una DMZ a parte gli honeypot. (un honeypot è un sistema specificamente progettato per essere un attrattore di virus / attacker in modo che tu possa analizzarli) per tutti gli altri usi legittimi che dovresti usare difese multi-livello e basta avere un percorso di accesso chiaramente definito attraverso i firewall (e il tuo firewall consente le chiamate al tuo webserver sulla porta 80 e 443 ma solo se lì per "tuo-dominio" e solo per uno specifico end-point (come il solo webserver o il principale bilanciamento del carico).
In pratica a volte è necessario avere un sistema nella tua DMZ per utilizzare qualcosa a causa della politica (IMHO una cattiva politica). se sei bloccato con quella situazione,
Vorrei usare quello che viene chiamato un proxy inverso per proxy tutte le richieste valide dall'interno della DMZ all'interno della tua rete sicura dove si trova il tuo server web. questo previene la maggior parte degli attacchi scipted e mantiene intatta la tua sicurezza di base. vuol dire che devi proteggere il tuo server web con altri mezzi per limitare l'effetto di un server web compromesso (semplicemente perché è ora nella tua rete)