Назад | Перейти на главную страницу

Должны ли производственные веб-серверы Windows (IIS и SQL) находиться в домене?

У нас есть несколько веб-серверов и несколько серверов баз данных. На сегодняшний день это были отдельные машины, не входящие в домен. Веб-серверы не взаимодействуют друг с другом, а веб-серверы общаются с серверами баз данных через SQL Auth.

Мое беспокойство по поводу объединения машин в домен было

  1. добавленная сложность - это еще одна "вещь", которая работает и делает "вещи", которые могут пойти не так.
  2. риск - если контроллер домена выходит из строя, подвергаю ли я риску другие машины?

Однако в определенных сценариях им кажется удобным находиться в домене и совместно использовать учетные данные. Например, если я хочу предоставить управление «службами» на одной машине доступ к другой машине (поскольку удаленный рабочий стол гадит) Мне нужно войти и назначить привилегии на нескольких машинах - я считаю, что Active Directory и учетные записи домена должны упростить это.

Мой вопрос: я уверен, что есть вещи, которые я здесь не рассматриваю. Есть лучшая практика?

The Powers That Be, конечно, может прояснить ситуацию, но вся сеть StackOverflow работает на серверах IIS с серверной частью SQL в домене Active Directory. Я бы сказал, работает хорошо.

  • добавленная сложность - это еще одна «вещь», которая работает и делает «вещи», которые могут пойти не так.

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

  • риск - если контроллер домена выходит из строя, подвергаю ли я риску другие машины?

Вот почему у вас есть два контроллера домена, и вы не делаете их доступными из Интернета. Если кто-то проникнет на ваш сайт, вы все равно окажетесь под угрозой. Вот почему это очень хорошая идея, чтобы ваш домен AD был просто для вашей прикладной среды, если это возможно.

И, наконец, Microsoft проектирует свою среду для работы в AD. Межсерверная связь становится проще и безопаснее, когда AD участвует в арбитраже аутентификации и поощряет использование безопасного протокола.

Не надо просто подумайте о стоимости AD, подумайте, что он добавляет

  • централизованное управление счетами
  • возможность установить и обеспечить соблюдение согласованные политики безопасности
  • возможность централизовать развертывание программного обеспечения
  • возможность автоматизировать фактическую установку операционной системы

Все это может снизить сложность и повысить безопасность онлайн-сайта - мы надеемся, что централизация данных упростит его последовательное развертывание.

Конечно, это не то же самое, что правильное / безопасное развертывание, но это означает, что, как только вы выясните, какое правильное / безопасное развертывание означает, что вам нужно только один раз сделать это правильно в своем централизованном образе и настройках ОС, и это может быть постоянно выталкивается на новые серверы. Полезно как для расширения ваших систем, если вам это нужно, так и для создания сред тестирования / разработки, аналогичных производственной сети.

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

У нас есть все наши серверы в домене, где я работаю, по причинам, которые я указал выше (отдельный домен со стороны LAN). Конечно, у этого подхода есть риски и издержки. Нужно учитывать обе стороны и принимать взвешенное решение.