I server Web Windows devono essere membri di un dominio Active Directory

14

In termini di sicurezza e gestibilità - Qual è la migliore pratica?

Dovrebbe server web

Essere aggiunto e gestito da un dominio di Active Directory

o

Far parte di un gruppo di lavoro "web server" separato dalla directory attiva "server risorse"?

Non è necessario che ci siano account utente sui server Web, solo account di gestione (gestione server, report di sistema, distribuzione di contenuti ecc.)

— David Christiansen
fonte

Questi server web sono in un Colo o in una DMZ nel tuo ufficio?

— Rob Bergin,

Buon punto da sollevare. I server sono sotto il nostro controllo nella nostra sala server.

— David Christiansen,

8

Se si desidera utilizzare la delega Kerberos per creare un'infrastruttura sicura (e FARE TU), sarà necessario unire tali server Web al dominio. Il server Web (o l'account del servizio) avrà bisogno della possibilità di delegare ad esso assegnato per consentire la rappresentazione dell'utente sul proprio server SQL.

Volete evitare di utilizzare l'autenticazione basata su SQL sul server SQL se avete requisiti di controllo o di legge per il tracciamento dell'accesso ai dati (HIPAA, SOX, ecc.) Dovreste tenere traccia dell'accesso attraverso il processo di provisioning (ovvero chi è in quali gruppi, come è stato approvato e da chi) e tutti gli accessi ai dati dovrebbero avvenire tramite l'account assegnato di un utente.

Per problemi relativi a DMZ relativi all'accesso all'AD , è possibile risolverne alcuni con Server 2008 utilizzando un controller di dominio di sola lettura (RODC), ma esiste ancora il rischio con la distribuzione nella DMZ. Esistono anche alcuni modi per forzare un controller di dominio a utilizzare porte specifiche per eseguire il punch through di un firewall, ma questo tipo di cutomization può rendere difficile risolvere problemi di autenticazione.

Se hai esigenze specifiche per consentire agli utenti di Internet e Intranet di accedere alla stessa applicazione, potresti dover esaminare uno dei prodotti Federeated Services, l'offerta Microsoft o qualcosa come Ping Federated.

— Ryan Fisher
fonte

8

Uso interno, assolutamente. In questo modo vengono gestiti dall'oggetto Criteri di gruppo, l'applicazione di patch non è così difficile e il monitoraggio può essere realizzato senza una serie di soluzioni alternative.

Nella DMZ, generalmente consiglierei di no, non dovrebbero essere sulla DMZ. Se si trovano nel dominio e nella DMZ, il problema che si verifica è che il server Web deve disporre di una certa connettività su almeno un controller di dominio. Pertanto, se un utente malintenzionato esterno compromette il server Web, ora può avviare direttamente attacchi contro uno dei controller di dominio. Possedere il controller di dominio, possedere il dominio. Possiedi il dominio, possiedi la foresta.

— K. Brian Kelley
fonte

Grazie KB e Rob. La creazione di un altro annuncio nella rete perimetrale è una risposta, ma non posso giustificare la necessità di acquistare un altro server solo per essere l'host di un annuncio per server web. Urg. Un'altra complicazione è che i server web devono avere ALCUNI traffico consentito nella rete "attendibile" interna (ad esempio SQL) e che il traffico SQL è protetto mediante una connessione di rete affidabile. Immagino che dovremmo parlare di due annunci pubblicitari e di una fiducia tra i due?

— David Christiansen,

Questo è il percorso più sicuro, sì. Hai una foresta per i server basati su DMZ e ha una fiducia unidirezionale verso la foresta interna. Tuttavia, vorrei prima consentire l'autenticazione basata su SQL Server.

— K. Brian Kelley,

Sono d'accordo, questa è la strada da percorrere.

— squillman,

6

Perché non avere un dominio Web server nella DMZ?

Potrebbe essere una foresta separata con una relazione di trust unidirezionale per amministrare il dominio dal dominio principale senza concedere alcuna autorizzazione al dominio WS per il dominio principale.

Tutte le gioie di AD / WSUS / GPO - particolarmente utili se ne hai un'intera farm - e se sono compromesse non è la tua rete principale.

— Jon Rhoades
fonte

1

Questa è la strada più sicura da percorrere se devi usare un dominio. Tuttavia, stai ancora parlando di ottenere un attacco diretto su una DC. E nello scenario che dai, se ottengo quel controller di dominio, a meno che tu non abbia rimosso le credenziali memorizzate nella cache, posso comunque estrarle e disporre delle credenziali da utilizzare rispetto al dominio / foresta primario.

— K. Brian Kelley,

KB, per interesse, puoi descrivere le "credenziali memorizzate nella cache"

— David Christiansen,

1

A meno che non lo si disattivi, un sistema Windows memorizzerà nella cache le credenziali della password (in realtà un hash di un hash) quando si accede. Questo è ciò che ti consente di avere un laptop e accedere con il tuo accesso al dominio quando sei lontano dalla rete aziendale. Estrai quello, usa le tabelle arcobaleno, ottieni l'idea.

— K. Brian Kelley,

3

Se il trust è solo uno, le credenziali memorizzate nella cache sono irrilevanti in quanto il server DMZ non eseguirà mai l'autenticazione con il dominio primario.

— Jon Rhoades,

2

Se il server web si trova sulla stessa rete dei controller di dominio, lo aggiungerei sicuramente al dominio, poiché questo ovviamente aggiunge molta gestibilità. Tuttavia, di solito cerco di inserire server Web in una DMZ per aumentare la sicurezza, il che rende impossibile l'accesso al dominio senza fori (e questa è una pessima idea!)

— Rob Golding
fonte

1

Come altri hanno già detto, se questi sono rivolti al pubblico e non richiedono l'autenticazione degli utenti rispetto alla directory, non inserirli nel dominio.

Tuttavia, se dovessi richiedere una sorta di autenticazione o ricerca di informazioni da AD, cerca eventualmente di eseguire Active Directory Application Mode ( ADAM ) nella DMZ. Potrebbe essere necessario replicare le informazioni di relavent da AD nella partizione Applicaton poiché ADAM non sincronizza le partizioni AD standard.

Se stai solo cercando funzionalità di gestione, ADAM non si applica.

— Doug Luxem
fonte