Vantaggi della separazione del server Web dal database

Bene, il primo ovvio vantaggio è che se qualcuno rompe la scatola che ospita il server delle applicazioni, non è garantito l'accesso allo stesso server che ospita il database. Inoltre, separando questa funzionalità è più facile per l'IT (sviluppatori software, amministratori, ecc.) Ridurre al minimo l'impatto delle modifiche al codice / gli aggiornamenti delle policy su diversi aspetti dell'ambiente. Ciò non risolve in alcun modo la scarsa codifica o la debole sicurezza (SQL injection, nome utente / password predefiniti). ma facilita una migliore postura di sicurezza in generale.

• Un server web con internet non ha assolutamente ragione di avere alcun accesso alla LAN / dominio e quindi dovrebbe essere completamente proibito farlo. Idealmente, dovrebbe essere su una DMZ.

  • Ciò fornisce protezioni significative contro un utente malintenzionato che ha "posseduto" il server Web di fronte a Internet che attacca il resto della rete.
  • Puoi avere tutto ciò di cui hai bisogno, naturalmente, per HA (alta disponibilità), DR (disaster recovery) e motivi di prestazioni.
  • Media: con regole rigide per il limite WAN / DMZ e il divieto totale di traffico DMZ / LAN "alla LAN" e regole severe per il traffico DMZ / LAN "A DMZ" o simili.
  • Avanzato: un DMZ "esterno" con regole severe per i confini WAN / OuterDMZ e OuterDMZ / InnerDMZ o simili.

• Un host di servizi Web interno deve probabilmente avere accesso limitato alla LAN / dominio (principalmente al / i tuo / i database / i

  • Se non sta utilizzando l'autenticazione del tipo di dominio nel database, non è ancora necessario che si trovi nel dominio
  • È possibile avere tutto ciò di cui si ha bisogno, naturalmente, per motivi di HA (alta disponibilità), DR (disaster recovery) e prestazioni. Se utilizzi un hashing password molto buono (PBKDF2, bcrypt, scrypt) con conteggi di iterazione elevati, avrai bisogno di più elaborazione e / o RAM qui.
  • Anche se questa è una piattaforma migliore per attaccare la tua LAN rispetto al server web di Internet (a meno che non siano la stessa casella, o peggio, lo stesso sito), dovrebbe comunque avere un accesso molto limitato - al box del database solo una porta del database, la possibilità di estrarre aggiornamenti antivirus e inviare avvisi antivirus, ecc.
  • Base: questa è la stessa istanza del sistema operativo che ospita il server Web con connessione Internet o simile.
  • Media: si trova anche sulla DMZ con protezione completa del traffico in entrata dal WAM e regole rigorose per il confine in uscita WAN WAN / DMZ e regole severe per i confini DMZ / LAN o simili.
  • Avanzato: si tratta di una DMZ "interna" con regole severe per i confini di OuterDMZ / InnerDMZ e InnerDMZ / LAN o simili.

• È probabile che un server di database si trovi sulla tua LAN, rendendolo un bersaglio molto più prezioso per un utente malintenzionato; probabilmente deve essere eseguito il backup, deve essere accessibile da una varietà di programmi oltre al web, e così via e così via.

  • Come sempre, SQL Injection passa direttamente da Internet al tuo database; parametrizza il tuo SQL!
  • Avere più livelli di autorizzazione minimi e ben definiti tra questo e altri server sulla tua LAN e su Internet, con una buona progettazione e implementazione, aiuta ad aumentare la quantità di sforzi necessari per attaccare il server del database, tanto meno riesce ad attaccare .

In sostanza:

• Internet - > Sito Web + servizi + DB significa con un compromesso del sistema operativo, l'utente malintenzionato può controllare tutto, incluso l'esfiltrazione o la distruzione diretta di tutti i dati nel database (o nei backup) - non c'è bisogno di andare tramite l'interfaccia Web per farlo.

• Internet - > Sito Web + servizi - > DB significa che l'utente malintenzionato deve compromettere il database attraverso il buco della serratura dei servizi Web o deve compromettere più di un computer che presenta solo alcuni problemi di sicurezza condivisa.

• Internet - > sito Web - > Servizi Web - > DB è ancora meglio: l'hacker deve compromettere il tuo database attraverso il buco della serratura dei tuoi servizi Web visto attraverso il buco della serratura del tuo sito web, o deve compromettere più di una (o due!) Macchina (e) che hanno alcune ma non tutti i buchi di sicurezza condivisa.

Va da sé che ad ogni livello dovresti essere sicuro quanto ti è permesso di essere - patch aggiornate e antivirus, SQL parametrizzato per prevenire l'iniezione SQL, voci di whitelist, password crittografiche a lungo termine, dati crittografati, crittografati connessioni, password strongmente hash (PBKDF2, bcrypt, scrypt), buone scelte algoritmiche per crittografia e hashing, solo le porte minime aperte tra ogni livello, controllo log per tracce di attacchi, software / applicativi IDS / IPS e così via e così via .

Ci vuole un po 'di pianificazione o un po' di programmazione (o entrambi).

Beh, separando il server web dal server del database, se un utente può sfruttare l'applicazione Web ed elevare i propri privilegi, può confondere i dati, ma solo quanto il modello di sicurezza sul server di database li lascerà . Ad esempio, mentre possono leggere e scrivere i dati dei clienti - se possono decodificare come funziona l'app Web - non possono effettuare il bulk del download dell'intero database, né eliminarlo completamente, né corromperlo / comprometterlo / altrimenti degradarlo riscrivendolo schema. Inoltre, i firewall e i sistemi IDS specifici per le nuove generazioni progettati per proteggere il server di database possono rilevare e bloccare accessi insoliti basati su firme ed euristiche di attacco note, proteggendo i dati dall'accesso client compromesso.

Questo è a portata di mano se il server del database alimenta un certo numero di server web.