Quali sono i compromessi in termini di costi, sforzi e valore nello spostamento di un server di database in un ambiente DMZ virtualizzato?

C'è qualche ragione per cui non basterebbero solo le connessioni NAT dal gateway al server DB interno piuttosto che spostare completamente la scatola nella DMZ?

Per quanto riguarda i problemi elencati, non mi preoccuperei troppo del n. 3, perché non importa quale sia il server DB che deve essere adeguatamente protetto. L'unico modo per mitigare tale rischio è che la casella di sviluppo effettui chiamate a un'API che gestisce la comunicazione con una casella DB interna o in altro modo non esposta. In questo modo non devi aprire completamente le porte al server DB.

Sembra che possa avere altri dati non correlati allo strumento di sviluppo su questo server DB, il che rende indesiderabile lo spostamento e la gestione del rischio.

Bleh, prendere queste decisioni non è mai divertente, ma alla fine è il nostro lavoro, giusto?

Se usare NAT per gestire il routing non sembra troppo buono per te, e nemmeno impostare l'accesso API al DB non è fattibile; devi dare una buona occhiata a ciò che questo server DB è all'altezza e andare da lì.

L'intero scopo di una DMZ è di esporre i servizi necessari al mondo esterno proteggendo al contempo le operazioni interne il più possibile. Significa, solo perché ho bisogno di accesso DB non significa che devo essere in grado di eseguire il ping di ogni macchina e stampante in ufficio. Detto questo, se hai dati su quel server DB che non ha business accessibile da internet più grande allora quel server non appartiene assolutamente alla DMZ e dovresti davvero impostare un nuovo server DB per ospitare quei dati che hanno bisogno di accessibile da Internet più grande. Questo è esattamente lo scopo della DMZ.

Per quanto riguarda il bit di ridondanza dei dati, non credo che questa situazione meriti di avere due server con gli stessi dati che si replicano l'un l'altro con utenti interni che colpiscono un utente esterno e che ne colpisce un altro, che è quasi sempre un'architettura terribile. Se questa istanza DB finisce nella DMZ, dovrai configurare il routing e / o usare il DNS interno per assicurare che il traffico locale arrivi alla casella nella DMZ.

Left Field: Rileggi la tua domanda Mi chiedo se non ci sia un'altra soluzione nascosta qui per ottenere il tuo vero problema che sembra essere la latenza e la disponibilità dei dati consegnati ... se tu Hai file che devono essere consegnati pubblicamente con bassa latenza? C'è qualche ragione per cui non li stai archiviando su archivi di terze parti come s3 o cloudfront CDN?

L'approccio sarebbe essenziale per memorizzare tutte le informazioni sul file sul DB, generare un hash per un determinato nome di file (hai menzionato i video?) e memorizzare un collegamento a S3 o CDN nel DB. Se l'unica ragione per cui stai pensando di spostare il DB è controllare la latenza sui blob di dati che vengono inviati a un utente, penso che tu stia meglio ripensando al problema piuttosto che arrivare a questo come una questione di "accesso" ai dati che è in ultima analisi, di cosa tratta la DMZ.