• Il posizionamento migliore consiste nel mettere i server del database in una zona attendibile.
• Dovrebbero consentire le connessioni in entrata solo dai server Web e dovrebbero essere applicate a un firewall e alle macchine. La realtà di solito determina alcune macchine in più (amministratore di database, ecc.). Obbedire alla realtà, se necessario, naturalmente.
• Dovrebbero creare connessioni in uscita solo se stai aggiornando il software su di loro.

Concorda con Jeff Ferland, i server di database dovrebbero essere da soli: dovresti avere una rete pulita per la replica e l'amp; di backup.

Perdona la mia arte ASCII, una rapida panoramica di un ideale ragionevole:

      [internet]
          |
    outer-firewall--- [proxy-zone]
          |      
         ----- [app-zone]
          |
    inner-firewall 
[lan]--/         \-- [database-zone]

1. Eseguire un proxy inverso, Apache + mod_security / varnish / nginx / WAF / qualunque, nella zona del proxy. Aggiungi bilanciamento del carico / failover qui se necessario. Anche server proxy / relay per le connessioni in uscita (DNS, SMTP, proxy HTTP), se necessario.
2. Quando la logica dell'applicazione viene eseguita su un server Web (Java / PHP / ASP), preferisco chiamarlo un server applicazioni.
3. Quando è necessario ridimensionare, è possibile ridimensionare orizzontalmente, il bilanciamento del carico lo rende più semplice. Potresti anche considerare la possibilità di replicare il contenuto statico non autenticato sui proxy front-end.
4. potresti voler aggiungere una o più zone: IDS, gestione, backup, accesso remoto, proxy in uscita

Stai provando a mitigare, quindi:

• la comunicazione tra zone deve essere limitata al minimo richiesto per scopi di servizio e monitoraggio.
• reverse-proxy accetta connessioni non fidate da internet, può connettersi solo ai servizi sui server delle applicazioni. Se si desidera classificare le zone in base al traffico, è necessario considerare attentamente la terminazione di HTTP e se si desidera creare nuove connessioni HTTPs ai server delle app.
La zona applicativa
• accetta le connessioni semi-attendibili dai proxy, può connettersi solo ai database. Puoi fidarti ancora dei tuoi server delle applicazioni quando sai che non stanno parlando direttamente a Internet.
I server di database
• accettano le connessioni solo dai server delle applicazioni, l'area del database dovrebbe essere la rete "più pulita"
• considera l'utilizzo di firewall diversi (fornitore / prodotto) per i firewall esterni e interni
• per i servizi in uscita richiesti (DNS, SMTP o patching / aggiornamenti) questi dovrebbero passare attraverso un server distinto (ad esempio sulla zona proxy o zona-proxy in uscita).
• lo stesso vale per le connessioni HTTPS di convalida CC in uscita. (Se sei abbastanza sfortunato da avere una scatola nera fornita dal venditore per la convalida, dovrebbe andare anche su una zona dedicata, IMHO.)
• usa l'indirizzamento IP pubblico solo nella zona proxy, l'indirizzamento privato altrove. Nessun server esterno alla zona proxy deve avere un IP pubblico, NAT o una route predefinita per Internet.

Separare le zone rende più facile il lavoro dell'IDS e la registrazione più efficace. Se disponi delle risorse, aggiungi una zona di gestione, NIC di gestione separate per ogni server (se possibile, porte protette).

In realtà si potrebbe finire per compattare la "rete ideale" per un singolo firewall e VLAN, ma se si considerano le opzioni ora tenendo conto di quanto sopra, dovrebbe essere più facile migrare in futuro, cioè subito dopo la prossima visita da il tuo auditor PCI-DSS di vicinato amichevole; -)

Quanto segue è una configurazione abbastanza comune per l'architettura di DMZ:

Internet

^

Firewall1

^

DMZ (Qui i tuoi server dmz ospitano solo porte specifiche attraverso il firewall)

^

Firewall2

^

Rete di database (consente solo porte e protocolli specifici da firewall2 a questa rete)

Come si menziona il database contiene dati (sensibili) della carta di credito, quindi anche sul lato interno del firewall2 la rete del database dovrebbe essere separata dalle reti aziendali e degli utenti. Tante volte vedo i gioielli della corona di una società spalancata sulla rete interna per tutti gli utenti per sondare e accedere. Facendo un passo avanti si potrebbe avere una VLAN di amministrazione del database che consente solo ai sistemi all'interno di questa VLAN di accedere ai database (a parte l'applicazione che deve accedervi dalla DMZ, ovviamente).

Spero che questo aiuti.

L'architettura a 3 livelli è la soluzione più sicura e scalabile. Con l'aumentare del traffico del client, possiamo aggiungere quanti livelli intermedi sono necessari per garantire le prestazioni. L'architettura a tre livelli è anche più sicura perché il livello intermedio protegge il livello del database. Dobbiamo proteggere il livello del database dall'accesso diretto e aver bisogno di essere collocato nella zona di fiducia e dovrebbe solo accettare le connessioni dai server delle applicazioni.

Poiché è necessario rispettare PCI-DSS, è inoltre necessario assicurarsi di disporre di firewall per ogni connessione Internet e tra DMZ e reti interne. Ci sono alcuni buoni indicatori nei questionari di self assessment.

Inoltre, non rendere il server del database se un server di wintel è un membro del dominio ecc.

Preferirei un'architettura in cui il server DB fosse protetto da più di un semplice firewall. Ossia, suppongo che il server web venga compromesso, ma invece di essere in grado di eseguire operazioni DB arbitrarie, può solo recuperare dati estremamente limitati da un server intermedio. Un appassionato di DB affermerebbe che qualsiasi DB avrà un controllo dei privilegi sufficiente incorporato. Ma bene, difesa in profondità.