Должны ли веб-серверы Windows быть членами домена Active Directory

14

С точки зрения безопасности и управляемости - Какова лучшая практика?

Должны ли веб-серверы

Быть добавленным и управляемым из домена Active Directory

или

Быть частью рабочей группы «веб-сервер», которая отделена от активной директории «сервер ресурсов»?

Не требуется наличие учетных записей пользователей на веб-серверах, только учетных записей управления (управление сервером, системная отчетность, развертывание контента и т. Д.).

— Дэвид Кристиансен
источник

Эти веб-серверы находятся в Коло или DMZ в вашем офисе?

— Роб Бергин

Хороший вопрос для поднятия. Серверы находятся под нашим собственным контролем в нашей собственной серверной комнате.

— Дэвид Кристиансен

8

Если вы хотите использовать делегирование Kerberos для создания защищенной инфраструктуры (и ВЫ ДЕЛАЕТЕ), вам необходимо присоединить эти веб-серверы к домену. Веб-серверу (или учетной записи службы) потребуется возможность делегировать назначенный ему, чтобы позволить олицетворение пользователя на вашем SQL-сервере.

Вы, вероятно, хотите избежать использования аутентификации на основе SQL на сервере SQL, если у вас есть какие-либо требования аудита или законодательные требования для отслеживания доступа к данным (HIPAA, SOX и т. Д.). Вы должны отслеживать доступ через процесс инициализации (т. Е. Кто в какие группы, каким образом это было одобрено и кем) и весь доступ к данным должен осуществляться через назначенную пользователем учетную запись.

Что касается проблем DMZ, связанных с доступом к AD , некоторые из них можно решить с помощью Server 2008 с использованием контроллера домена только для чтения (RODC), но при развертывании в DMZ все еще существует риск. Есть также несколько способов заставить DC использовать определенные порты для пробивки через брандмауэр, но этот тип cutomization может затруднить решение проблем аутентификации.

Если у вас есть особые потребности, чтобы разрешить пользователям Интернета и интрасети доступ к одному и тому же приложению, вам может понадобиться использовать один из продуктов Federeated Services, будь то предложение Microsoft или что-то вроде Ping Federated.

— Райан Фишер
источник

8

Внутреннее использование, абсолютно. Таким образом, управление ими осуществляется с помощью GPO, исправление не так сложно, а мониторинг можно выполнить без множества обходных путей.

В DMZ вообще я бы посоветовал нет, они не должны быть в DMZ. Если они находятся в домене и в демилитаризованной зоне, проблема, с которой вы сталкиваетесь, заключается в том, что веб-сервер должен иметь определенное подключение обратно как минимум к одному DC. Таким образом, если внешний злоумышленник скомпрометирует веб-сервер, он или она теперь могут напрямую запускать атаки на один из контроллеров домена. Собственный DC, владение доменом. Собственный домен, собственный лес.

— К. Брайан Келли
источник

Спасибо КБ и Роб. Создание еще одного AD в сети периметра - это один из ответов, но я не могу оправдать то, что мне нужно покупать другой сервер, чтобы быть хостом AD для веб-серверов. Urg. Другая сложность заключается в том, что веб-серверам должен быть разрешен НЕКОТОРЫЙ трафик во внутреннюю «доверенную» сеть (например, SQL), а трафик SQL защищен с помощью надежного сетевого подключения. Я предполагаю, что мы должны говорить о двух объявлениях и доверии между ними?

— Дэвид Кристиансен

Это самый безопасный маршрут, да. У вас есть лес для серверов на основе DMZ, и он имеет одностороннее доверие к внутреннему лесу. Однако сначала я бы хотел разрешить аутентификацию на основе SQL Server.

— К. Брайан Келли

Я согласен, это путь.

— squillman

6

Почему бы не иметь домен веб-сервера в DMZ?

Это может быть отдельный лес с односторонними доверительными отношениями для администрирования домена из основного домена без предоставления каких-либо разрешений домену WS для вашего основного домена.

Все радости AD / WSUS / GPO - особенно полезны, если у вас есть целая ферма из них - и если она скомпрометирована, это не ваша основная сеть.

— Джон Роудс
источник

1

Это самый безопасный путь, если вам нужно использовать домен. Тем не менее, вы все еще говорите о получении прямой атаки на DC. И в сценарии, который вы даете, если я получу этот DC, если вы не извлечете кэшированные учетные данные, я все равно смогу получить их и использовать их для основного домена / леса.

— К. Брайан Келли

KB, Из интереса, можете ли вы описать «кэшированные учетные данные»

— Дэвид Кристиансен,

1

Если вы не отключите его, система Windows будет кэшировать учетные данные пароля (фактически хэш хеша) при входе в систему. Это то, что позволяет вам иметь ноутбук и войти в систему с помощью входа в домен, когда вы находитесь вне корпоративной сети. Извлеките это, используйте радужные таблицы, вы поняли идею.

— К. Брайан Келли

3

Если доверие только одно, то кэшированные учетные данные не имеют значения, поскольку сервер DMZ никогда не будет проходить аутентификацию на основном домене.

— Джон Роудс

2

Если веб-сервер находится в той же сети, что и контроллеры домена, то я бы определенно добавил его в домен, поскольку это, очевидно, добавляет значительную управляемость. Тем не менее, я обычно стремился бы поместить веб-серверы в DMZ для повышения безопасности - что делает невозможным доступ к домену без дырок (и это очень плохая идея!)

— Роб Голдинг
источник

1

Как уже упоминали другие, если они общедоступны и не требуют аутентификации пользователей по каталогу, не помещайте их в домен.

Однако, если вам требуется какая-либо проверка подлинности или поиск информации из AD, возможно, обратите внимание на запуск режима приложений Active Directory ( ADAM ) в DMZ. Возможно, вам придется скопировать информацию о релевантных данных из AD в раздел Applicaton, поскольку ADAM не синхронизирует стандартные разделы AD.

Если вы просто ищете функции управления, ADAM не применяется.

— Дуг Люксем
источник