it-swarm.it

Qual è la migliore pratica per posizionare i server di database in topologie di rete sicure

Ho un classico DMZ architettura:

enter image description here

Il mio server web è inserito nella DMZ. Il server web deve comunicare con un server di database. Questo server di database è il componente più critico della mia rete in quanto contiene dati riservati.

Dove devo posizionare il server DB e perché? Devo aggiungere un secondo firewall e creare un altro DMZ?

20
lisa17
  • Il miglior posizionamento è mettere i server di database in una propria area di fiducia.
  • Dovrebbero consentire connessioni in entrata solo dai server Web e ciò dovrebbe essere applicato a un firewall e sui computer. La realtà di solito impone qualche macchina in più (db admin, ecc.). Obbedire alla realtà secondo necessità, ovviamente.
  • Dovrebbero effettuare connessioni in uscita solo se si sta aggiornando il software su di essi.
26
Jeff Ferland

D'accordo con Jeff Ferland, i server di database dovrebbero essere autonomi: è necessario disporre di una rete pulita per la replica e il backup.

Perdonate my ASCII art, una rapida panoramica di un ideale ragionevole:

      [internet]
          |
    outer-firewall--- [proxy-zone]
          |      
         ----- [app-zone]
          |
    inner-firewall 
[lan]--/         \-- [database-zone]
  1. Esegui un proxy inverso, Apache + mod_security/varnish/nginx/WAF/qualunque, nella zona proxy. Aggiungi bilanciamento del carico/failover qui, se necessario. Se necessario, anche server proxy/relay per connessioni in uscita (DNS, SMTP, proxy HTTP).
  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 in orizzontale, i bilanciatori di carico facilitano questa operazione. È inoltre possibile considerare la replica di contenuto statico non autenticato nei 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.
  • proxy inverso accetta connessioni non attendibili da Internet, può connettersi solo ai servizi sui server applicazioni. Se si desidera classificare le zone in base al traffico, è necessario considerare attentamente la terminazione degli HTTP e se si desidera creare nuove connessioni HTTP ai server delle app.
  • la zona dell'applicazione accetta connessioni semi-attendibili dai proxy, può connettersi solo ai database. Puoi fidarti un po 'di più dei tuoi server applicazioni quando sai che non stanno parlando direttamente a Internet.
  • i server di database accettano connessioni solo dai server delle applicazioni, l'area del database dovrebbe essere la rete "più pulita"
  • considerare l'utilizzo di diversi firewall (fornitore/prodotto) per i firewall esterni e interni
  • per i necessari servizi in uscita (DNS, SMTP o patch/aggiornamenti) questi devono passare attraverso un server distinto (ad es. nella zona proxy o nella zona proxy in uscita).
  • lo stesso vale per qualsiasi connessione HTTPS di convalida CC in uscita. (Se sei abbastanza sfortunato da avere una scatola nera fornita dal fornitore per la convalida, anche questo dovrebbe andare in una zona dedicata, IMHO.)
  • utilizzare l'indirizzamento IP pubblico solo nella zona proxy, l'indirizzamento privato altrove. Nessun server al di fuori della zona proxy deve avere un IP pubblico, NAT o una route predefinita a Internet.

Zone separate rendono il lavoro del tuo IDS più semplice e la registrazione più efficace. Se disponi delle risorse, aggiungi una zona di gestione, schede NIC di gestione separate per ciascun server (se possibile, porte protette).

In realtà potresti finire per compattare la "rete ideale" in un singolo firewall e VLAN, ma se consideri le tue opzioni ora tenendo presente quanto sopra, dovrebbe essere più facile migrare in futuro, vale a dire poco dopo la prossima visita dal tuo quartiere amichevole Revisore PCI-DSS ;-)

21
mr.spuratic

La seguente è una configurazione abbastanza comune per DMZ architecutre:

Internet

^

Firewall1

^

DMZ (ospita qui i tuoi server dmz consentendo solo porte specifiche attraverso il firewall)

^

Firewall2

^

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

Come accennato, il database contiene dati relativi alle carte di credito (sensibili), quindi anche all'interno del firewall2 la rete del database deve essere separata dalle reti aziendali e dell'utente. Tante volte vedo i gioielli della corona di un'azienda spalancati sulla rete interna affinché tutti gli utenti possano sondarli e accedervi. Andando oltre, potresti avere un database admin VLAN consente solo i sistemi all'interno di questo VLAN per accedere ai database (a parte l'applicazione che deve accedere dal DMZ ovviamente).

Spero che sia di aiuto.

1
fixulate

L'architettura a 3 livelli è la soluzione più sicura e scalabile. Con l'aumentare del traffico client possiamo aggiungere tutti i livelli intermedi 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 posizionarlo in una zona attendibile e deve accettare solo connessioni dai server delle applicazioni.

3 Tier Architecture

1
Ali Ahmad

Poiché dovrai conformarti a PCI-DSS, dovrai anche assicurarti di disporre di firewall ad ogni connessione Internet e tra DMZ e reti interne. C'è qualche buon suggerimento nei questionari di autovalutazione.

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

0
Matthew

Preferirei un'architettura in cui il server DB è protetto da più di un semplice firewall. Cioè, 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 built-in di controllo dei privilegi sufficiente. Ma bene, la difesa in profondità.

0
markhahn