Perché non è consigliabile disporre del database e del server Web sullo stesso computer?

Ascoltando l'intervista di Scott Hanselman con il team Stack Overflow ( parte 1 e 2 ), era fermamente convinto che il server SQL e il server delle applicazioni dovessero essere su macchine separate. Questo è solo per assicurarsi che se un server è compromesso, entrambi i sistemi non sono accessibili? I problemi di sicurezza superano la complessità di due server (costo aggiuntivo, connessione di rete dedicata tra i due, più manutenzione, ecc.), Soprattutto per una piccola applicazione, dove nessuno dei due componenti utilizza troppa CPU o memoria? Anche con due server, con un server compromesso, un utente malintenzionato può comunque causare seri danni, eliminando il database o giocando con il codice dell'applicazione.

Perché questo sarebbe un grosso problema se le prestazioni non fossero un problema?

1. Sicurezza. Il tuo server web vive in una DMZ, accessibile a Internet pubblico e riceve input non attendibili da utenti anonimi. Se il tuo server Web viene compromesso e hai seguito le regole dei privilegi minimi per la connessione al tuo DB, l'esposizione massima è ciò che la tua app può fare attraverso l'API del database. Se hai un livello aziendale nel mezzo, hai un altro passo tra il tuo aggressore e i tuoi dati. Se, d'altra parte, il database si trova sullo stesso server, l'attaccante ora ha accesso root ai dati e al server.
2. Scalabilità. Mantenere il tuo server Web senza stato ti consente di ridimensionare i server Web in orizzontale praticamente senza sforzo. È molto difficile ridimensionare orizzontalmente un server di database.
3. Prestazione. 2 scatole = 2 volte la CPU, 2 volte la RAM e 2 volte i mandrini per l'accesso al disco.

Detto questo, posso certamente vedere casi ragionevoli che nessuno di questi punti conta davvero.

E non lo fa davvero importa (si può tranquillamente eseguire il sito con web / base di dati sulla stessa macchina), è solo il passo più semplice in scala ..

È esattamente ciò che StackOverflow ha fatto: a partire da una singola macchina che esegue IIS / SQL Server, quindi quando ha iniziato a essere caricato pesantemente, è stato acquistato un secondo server e il server SQL è stato spostato su quello.

Se le prestazioni non rappresentano un problema, non sprecare denaro per acquistare / gestire due server.

D'altra parte, riferendosi a un diverso blog di Scott (Watermasyck, di Telligent), hanno scoperto che la maggior parte degli utenti potrebbe velocizzare i siti Web (utilizzando Telligent's Community Server), inserendo il database sullo stesso computer del sito web. Tuttavia, nel caso dei loro clienti, di solito il db e il web server sono le uniche applicazioni su quella macchina, e il sito web non sta stressando così tanto la macchina. Quindi, l'efficienza di non dover inviare dati attraverso la rete più ha compensato l'aumento della tensione.

Penserei che il grande fattore sarebbe la prestazione. Sia il server web / il codice app che SQL Server memorizzerebbero nella cache i dati richiesti comunemente e tu stai uccidendo le prestazioni della cache eseguendoli nello stesso spazio di memoria.

Tom ha ragione su questo. Alcuni altri motivi sono che non è conveniente e che ci sono ulteriori rischi per la sicurezza.

I server web hanno requisiti hardware diversi rispetto ai server database. I server di database funzionano meglio con molta memoria e un array di dischi molto veloce mentre i server Web richiedono solo memoria sufficiente per memorizzare nella cache i file e le richieste di DB frequenti (a seconda della configurazione). Per quanto riguarda il rapporto costo-efficacia, i due server non saranno necessariamente meno costosi, tuttavia il rapporto prestazioni / costi dovrebbe essere più elevato poiché non è necessario utilizzare diverse applicazioni in competizione per le risorse. Per questo motivo, probabilmente dovrai spendere molto di più per un server che si rivolge a entrambi e offre prestazioni equivalenti a 2 specializzati.

Il problema di sicurezza è che se il singolo computer è compromesso, sia il server web che il database sono vulnerabili. Con due server, hai un po 'di respiro perché il secondo server sarà ancora sicuro (almeno per un po').

Inoltre, ci sono alcuni vantaggi della scalabilità poiché potrebbe essere necessario mantenere solo alcuni server di database utilizzati da un gruppo di diverse applicazioni Web. In questo modo hai meno lavoro da fare per applicare aggiornamenti o patch e per ottimizzare le prestazioni. Credo che ci siano strumenti di gestione del server per rendere più semplici queste attività (nel caso della macchina singola).

La sicurezza è una delle maggiori preoccupazioni. Idealmente, il tuo server di database dovrebbe trovarsi dietro un firewall con solo le porte necessarie per eseguire l'accesso ai dati aperto. L'applicazione Web deve essere connessa al server di database con un account SQL che disponga dei diritti sufficienti per il funzionamento dell'applicazione e non di più. Ad esempio, è necessario rimuovere i diritti che consentono l'eliminazione di oggetti e sicuramente non è necessario connettersi utilizzando account come "sa".

Nel caso in cui si perda il server Web a causa di un dirottamento (vale a dire un'escalation dei privilegi in piena regola per i diritti di amministratore), lo scenario peggiore è che il database dell'applicazione potrebbe essere compromesso ma non l'intero server del database (come sarebbe se il database server e web server erano la stessa macchina). Se hai crittografato le stringhe di connessione al database e l'hacker non è abbastanza esperto da decrittografarle, tutto ciò che hai perso è il web server.

Un fattore che non è stato ancora menzionato è il bilanciamento del carico. Se inizi a pensare al server Web e al database come macchine separate, ottimizzi per un minor numero di viaggi di andata e ritorno in rete e diventa anche più facile aggiungere un secondo server Web o un secondo motore di database all'aumentare delle esigenze.

Posso dire per esperienza diretta che spesso è una buona idea posizionare il web server e il database su macchine diverse. Se si dispone di un'applicazione che utilizza molte risorse, può facilmente causare il picco dei cicli della CPU sulla macchina, interrompendo sostanzialmente la macchina. Tuttavia, se l'applicazione ha un uso limitato del database, probabilmente non sarebbe un grosso problema farli condividere un server.

Wow, nessuno evidenzia il fatto che se acquisti effettivamente un server SQL a 5.000 dollari, potresti volerlo usare per più della tua applicazione web. Se usi express, forse non ti interessa. Vedo che i server SQL eseguono database per 20-30 applicazioni, quindi metterlo sul server web non sarebbe intelligente.

In secondo luogo, dipende da chi è il server. Lavoro per le società finanziarie e il governo. Quindi usiamo un dolore pazzesco nell'approccio ass di usare solo sprocs e limitare le porte dal server web a SQL. Quindi se l'app Web viene hackerata. L'unica cosa che l'hacker può fare è chiamare sprocs poiché l'account utente sul server web è bloccato per vedere / chiamare sprocs solo sul DB. Quindi ora l'hacker deve capire come entrare nel DB. Se si trova sul server Web è facile da raggiungere.

Sono d'accordo con Daniel Earwicker - la domanda di sicurezza è praticamente imperfetta.

Se si dispone di una configurazione a casella singola con un server Web e solo il database per quel server Web su di esso, se quel server Web è compromesso, si perde sia il server Web sia solo il database per quella specifica applicazione.

Questo è esattamente lo stesso di quello che succede se si perde il server web in una configurazione a 2 server. Si perde il server Web e solo il database per quella specifica applicazione.

L'argomento secondo cui "viene mantenuta l'integrità del resto del server DB" laddove si disponga di una configurazione a 2 server è irrilevante, poiché nel primo scenario, anche tutti gli altri server di database relativi a qualsiasi altra applicazione (se presenti) rimangono inalterati - essere, per come sono, ospitati altrove.

Allo stesso modo, alla domanda posta da Kev 'che dire di tutti gli altri database che risiedono sul server DB? Tutto ciò che hai perso è un database. '

• se si ospitasse un'applicazione e un database su un server, si ospiterebbero solo i database su quel server che si riferivano a tale applicazione. Pertanto, non si perderebbero ulteriori database in una configurazione a server singolo rispetto a una configurazione a più server.

Al contrario, in una configurazione a 2 server, in cui l'attaccante aveva accesso al server Web e, per delega, diritti limitati (nel migliore dei casi) al server di database, potevano mettere a rischio i database di ogni altra applicazione portando query lente, che richiedono molta memoria o che massimizzano lo spazio di archiviazione disponibile sul server di database. Separando le applicazioni nelle loro preoccupazioni, proprio come la virtualizzazione, le isolate anche per motivi di sicurezza in modo positivo.

Dipende dall'applicazione e dallo scopo. Quando l'alta disponibilità e le prestazioni non sono fondamentali, non è male non separare DB e web server. Soprattutto se si considerano i miglioramenti delle prestazioni: se l'applicazione effettua una grande quantità di query sul database, è possibile rimuovere una notevole quantità di carico di rete mantenendo tutto sullo stesso sistema, mantenendo bassi i tempi di risposta.

Penso che sia perché le due macchine di solito dovrebbero essere ottimizzate in modi diversi. A parte questo, non ne ho idea, eseguiamo tutte le nostre applicazioni con il server-database sulla stessa macchina - ammesso che non siamo di fronte al pubblico - ma non abbiamo avuto problemi.

Non riesco a immaginare che troppe persone si preoccupino del fatto che una macchina sia compromessa su entrambi poiché l'applicazione Web di solito avrà accesso quasi illimitato almeno ai dati se non allo schema all'interno del database.

Interessato a ciò che gli altri potrebbero dire.

Ho ascoltato quel podcast ed è stato divertente, ma l'argomento della sicurezza non ha senso per me. Se hai compromesso il server A e quel server può accedere ai dati sul server B, allora hai immediatamente accesso ai dati sul server B.

Le licenze del database non sono scadenti e sono spesso addebitate per CPU, quindi separando i server Web è possibile ridurre il costo delle licenze del database.

Ad esempio, se si dispone di 1 server che esegue sia il Web che il database che contiene 8 CPU, è necessario pagare per una licenza da 8 cpu. Tuttavia, se hai due server ciascuno con 4 CPU ed esegui il database su un server dovrai pagare solo per una licenza di 4 cpu

Un'ulteriore preoccupazione è che ai database piace occupare tutta la memoria disponibile e tenerla riservata per quando vuole usarla. È possibile forzarlo per limitare la memoria, ma ciò può rallentare notevolmente l'accesso ai dati.

Sostenere che si può ottenere un reale guadagno in termini di prestazioni eseguendo un server di database su un server Web è un argomento errato.

Poiché i server di database accettano stringhe di query e restituiscono set di risultati, i dati che fluiscono effettivamente dal server di dati al server Web sono relativamente piccoli, ma la potenza richiesta per elaborare la query e generare il set di risultati è relativamente grande. Pertanto, l'ottimizzazione delle prestazioni in relazione al tempo di trasferimento dei dati sta ottimizzando la cosa sbagliata.

Per quanto riguarda la sicurezza, ci sono vantaggi nell'avere il data server in una scatola diversa rispetto al web server. Avere una tale configurazione non è tutto e termina tutta la sicurezza, ma è un passo nella giusta direzione.

Per quanto riguarda la scalabilità, è facile e relativamente economico aggiungere server Web e inserirli nel cluster per gestire l'aumento del traffico. Aggiungere i server di dati e raggrupparli non è così semplice ed economico. Inoltre, i server Web e i server di dati hanno esigenze hardware diverse, quindi più box aiutano con la scalabilità.

Se stai iniziando in piccolo e hai solo una scatola, un buon modo sarebbe usare le macchine virtuali. L'esecuzione del server Web e del server di dati in diverse macchine virtuali su un host offre tutti i vantaggi di box separati al costo di un prezzo box elevato.

Il sistema operativo è un'altra considerazione. Mentre il tuo database può richiedere spazi di memoria più grandi e quindi UNIX, il tuo server web - o più specificamente il tuo server app poiché menzioni solo due livelli - può essere basato su .Net e quindi richiedere Windows.

Ok! Ecco il punto, è più sicuro che il tuo DB Server sia installato su un altro computer e la tua applicazione sul Web Server. Quindi collegare l'applicazione al DB con un collegamento Web. Grazie