С точки зрения безопасности и управляемости - что лучше?
Если веб-серверы
или
Не требуется наличия учетных записей пользователей на веб-серверах, только учетные записи управления (управление сервером, системная отчетность, развертывание контента и т. Д.)
Абсолютно для внутреннего использования. Таким образом, ими будет управлять объект групповой политики, установить исправления не так сложно, а мониторинг можно будет выполнить без множества обходных путей.
В демилитаризованной зоне, как правило, я бы посоветовал нет, они не должны находиться в демилитаризованной зоне. Если они находятся в домене и в DMZ, проблема, с которой вы столкнетесь, заключается в том, что веб-сервер должен иметь определенное соединение по крайней мере с одним DC. Следовательно, если внешний злоумышленник скомпрометирует веб-сервер, он или она теперь могут напрямую запускать атаки против одного из контроллеров домена. Владеть DC, владеть доменом. Владеть доменом, владеть лесом.
Если вы хотите использовать делегирование Kerberos для создания безопасной инфраструктуры (а ВЫ ДЕЛАЕТЕ), вам необходимо присоединить эти веб-серверы к домену. Веб-серверу (или учетной записи службы) потребуется возможность делегировать назначенное ему, чтобы разрешить олицетворение пользователя против вашего SQL-сервера.
Вероятно, вы не захотите использовать аутентификацию на основе SQL на сервере SQL, если у вас есть какие-либо аудиторские или законодательные требования для отслеживания доступа к данным (HIPAA, SOX и т. Д.). Вы должны отслеживать доступ в процессе подготовки (т.е. кто находится в какие группы, как это было одобрено и кем) и весь доступ к данным должен осуществляться через назначенную пользователем учетную запись.
Для Проблемы DMZ, связанные с доступом к AD, вы можете решить некоторые из этих проблем с помощью Server 2008, используя контроллер домена только для чтения (RODC), но по-прежнему существует риск развертывания в DMZ. Есть также несколько способов заставить контроллер домена использовать определенные порты для пробивания брандмауэра, но этот тип катомизации может затруднить устранение проблем с аутентификацией.
Если у вас есть особые потребности, чтобы разрешить пользователям Интернета и интрасети доступ к одному и тому же приложению, вам может потребоваться изучить возможность использования одного из продуктов Federeated Services, либо предложения Microsoft, либо чего-то вроде Ping Federated.
Почему бы не иметь домен веб-сервера в DMZ?
Это может быть отдельный лес с односторонними доверительными отношениями для администрирования домена из вашего основного домена без предоставления каких-либо разрешений домену WS для вашего основного домена.
Все прелести AD / WSUS / GPO - особенно полезно, если у вас их целая ферма - и если он скомпрометирован, это не ваша основная сеть.
Если веб-сервер находится в той же сети, что и контроллер (-ы) домена, я бы определенно добавил его в домен - так как это, очевидно, добавляет большую управляемость. Однако я обычно стараюсь помещать веб-серверы в DMZ для повышения безопасности, что делает доступ к домену невозможным без отверстий (а это очень плохая идея!)
Как отмечали другие, если они общедоступны и не требуют аутентификации пользователей в каталоге, тогда выполните не поместите их в домен.
Однако, если вам потребуется какая-то аутентификация или поиск информации из AD, возможно, изучите возможность запуска Active Directory Application Mode (АДАМ) в демилитаризованной зоне. Возможно, вам потребуется реплицировать соответствующую информацию из AD в раздел Applicaton, поскольку ADAM не синхронизирует стандартные разделы AD.
Если вы просто ищете возможности управления, ADAM не подходит.