Server Web con diversi modelli di rischio nella stessa rete

Question

Server Web con diversi modelli di rischio nella stessa rete

#1 da (2 voti)
#2 da (0 voti)

2

Questa domanda viene da un aspetto di sicurezza piuttosto che da un aspetto di routing / rete (che è il motivo per cui ho scelto qui invece di un errore del server).

Stiamo creando un'architettura di rete e abbiamo 2 server web. Uno dei server Web ha accesso a un database molto sensibile (nel "livello database") con una valutazione del rischio completamente diversa. Su una scala da 1 a 10, questo dato è un 7. L'altro server Web ha dati privi di significato, un 2/10.

Un mio collaboratore crede che, poiché entrambi sono server Web, e poiché entrambi consentono la porta 443,80, dovrebbero essere collocati nella stessa rete. Ritengono che se impostiamo un criterio (server Web in zone non protette), tutti i server Web che soddisfano questo "criterio" devono essere collocati nella stessa rete. Non sono d'accordo con questo approccio. Abbiamo un sacco di spazio per gli indirizzi, quindi perché non gettare il server web privo di significato e il suo database in una rete separata? Capisco che sia importante definire un modello per la tua architettura, vale a dire "rete insicura", "livello di database", livello di applicazione ", ma sfido che solo perché due server sono un server web, non significa necessariamente che dovrebbero essere in contatto tra di noi Certo, potremmo implementare firewall basati su host e routing intelligente, ma PERCHÉ ... sono preoccupato che se una violazione si verifica nel server Web privo di significato, l'autore dell'attacco potrebbe, in teoria, ottenere l'accesso al server Web molto sensibile .

Non cerco chi ha ragione, perché vedo entrambi i lati.

La mia domanda è che se due server eseguono lo stesso software (server web), dovrebbero essere collocati nella stessa rete, dato che richiedono l'accesso a informazioni che si trovano su livelli di minaccia diversi (per mancanza di un termine migliore) ?

webserver risk-management risk-analysis

posta pm1391 02.02.2018 - 21:49

fonte

2 risposte

Leggi altre domande sui tag webserver risk-management risk-analysis

eCryptfs: cosa succede se rimuovo ~ / .ecryptfs suite di crittografia TLS / SSL

score 2 · Answer 1

L'isolamento non è mai male. In un senso generale molto generico, immagina un sottomarino. Sono progettati con la consapevolezza che le cose stanno andando a gonfiarsi dentro, sopra o vicino a loro. Questo è il motivo per cui sono compartimentati permettendo ad uno scafo rotto di pavimentare solo 1/16 del sottomarino. Non a caso, i sottomarini sono anche abbastanza bravi a non affondare (e rimanere affondati).

Presumibilmente i tuoi due server web hanno credenziali differenti per desktop remoto (o telnet o SSH a tua scelta) e se non lo fanno, questo è già un grosso problema. In generale, un server web contenente dati segreti di livello 7/10 (assumerò almeno informazioni personali piuttosto che informazioni finanziarie o fiscali o informazioni sulla salute) la password per quella macchina potrebbe essere molto più pensata, ad esempio, un 16 carattere crpyto-password generata casualmente. Almeno questo è quello che potrei fare. In alternativa, il mio server Web di 2/10 segretezza potrebbe avere una password facile da ricordare, perché siamo umani e pigri. Ad esempio, forse il nome utente è admin e la password è adminCompanyNameSecret. Ancora non facile da indovinare, ma molto più prevedibile di una password cripto-casuale.

Spero che tu veda dove sto andando qui. Naturalmente, come amministratori, applicheremo precauzioni di sicurezza più rilassate sui server che hanno un target di valore inferiore. Il problema è che sono sicuro che tu sappia e realizzi che, una volta che un utente malintenzionato può accedere al server A, accedere al server B (server sicuro) sulla stessa rete sarà molto più facile che accedere al server B dalla rete.

Quindi non c'è niente di sbagliato nel mantenere entrambi i server sulla stessa rete e, come hai detto, potrebbe avere senso da un punto di vista dell'architettura, ma se lo fai devi fare quanto segue:

Tratta ENTRAMBI i server di segretezza 2/10 e 7/10 come se fossero server di segretezza 7/10. Assicurati che entrambi siano completamente aggiornati su tutti gli aggiornamenti del sistema operativo, segui le buone pratiche con accesso fisico e sicurezza, password cripto-casuali e nomi utente univoci. Assicurati che solo pochi conoscano le password, ecc. Se segui questa procedura, sei sicuro quanto hai isolato i due server. Se consideri il 2/10 come un server di segretezza 2/10, hai praticamente ridotto il valore dei dati nell'altro server a 2/10.

score 0 · Answer 2

Consiglio vivamente di separarli. Poiché sono due server Web diversi e servono contenuti diversi, sono stati introdotti altri possibili punti di vulnerabilità. O forse il web server 'meno importante' non viene aggiornato / testato frequentemente poiché non contiene comunque dati sensibili, quindi è da qualche parte che un utente malintenzionato potrebbe fare il pivot dal server sensibile.