Старая школа мысли заключалась в том, что серверы приложений и баз данных не должны быть частью домена. Моя сеть настроена так, что только серверы приложений могут связываться с серверами db. Серверы приложений находятся в своей собственной рабочей группе, а серверы баз данных находятся в своей собственной рабочей группе. Серверы полностью изолированы от остальной сети, и разработчики получают доступ через vpn / rdp. Это все еще хороший способ создания инфраструктуры?
Причина, по которой я спрашиваю, заключается в том, что я, наконец, обновляю среду с помощью Active Directory, и есть окно для изменения сетевой архитектуры, если это необходимо.
Я не совсем системный администратор, но мне нужно выполнять роль ...
РЕДАКТИРОВАТЬ
Я очень благодарен всем за терпение и помощь. Я очень мало знаю об Active Directory. Меня больше всего беспокоит то, что пользовательская машина будет скомпрометирована (зомби) и что эта скомпрометированная машина может быть использована для доступа к производственным серверам через AD. Использование AD сделало бы мою жизнь намного проще, но один-единственный компромисс разрушил бы компанию. В настоящий момент вероятность того, что неавторизованный пользователь получит доступ к внутренним производственным серверам, очень мала.
В любом случае, похоже, все согласны с тем, что AD не увеличивает риск для производственных серверов, и это обычно приемлемая практика. Итак, я полагаю, мне следует начать расширять свои знания об AD и исправить настройку или посмотреть, есть ли местный эксперт, который может это сделать.
Спасибо за всю информацию.
Есть причина, по которой крупные предприятия используют Active Directory. В этом больше смысла. Что следует учитывать:
Послушайте, вы все еще можете аппаратным брандмауэром отключить ключевые серверы, и это хорошая идея, вырезать соответствующие дыры, чтобы эти серверы могли взаимодействовать с контроллерами домена, и чтобы клиенты могли общаться с этими серверами только через правильные порты. Например, нет причин, по которым конечный пользователь должен иметь доступ NetBIOS к серверу базы данных. И нет причин, по которым файловому серверу нужно общаться с SQL Server, так что не позволяйте им. А затем вы ограничиваете общую площадь поверхности.
Я бы надел их; по крайней мере, выгоды от интегрированной аутентификации намного перевешивают любые предполагаемые недостатки. Общее управление ОС станет намного более плавным, и если ваши приложения и базы данных имеют модель безопасности, которая позволяет им иметь собственных выделенных администраторов и не предоставляет стандартным администраторам домена полный доступ к ним, вы на самом деле не потерять там что-нибудь.
Я не уверен, что опасения по поводу компрометации вашего AD здесь обоснованы. Если ваш AD скомпрометирован, неужели это означает, что у вас все равно проблемы посерьезнее?
Я не могу придумать ни одной веской причины для отделения серверов БД и приложений от домена. У нас в лесу работает огромное количество серверов SQL и Oracle, а также серверов приложений (более 100).
Боюсь представить себе, какой логистической головной болью было бы для нас работать, если бы они были разделены на рабочие группы.
Сложность - враг безопасности. Поместите свои серверы в Active Directory.
Я бы поместил серверы в AD, как предлагают все остальные. Если вас действительно беспокоит безопасность, поместите эти конкретные серверы в отдельную VLAN и разрешите им связываться только с определенными хостами на определенных портах. Это предотвратит доступ RDP, UNC и т. Д. И позволит только то, что необходимо.
AD и домен позволяют централизованно управлять сервером, ограничивая такие вещи, как учетные записи пользователей, GPO, просмотр Интернета, установка программного обеспечения, список бесконечен. Не говоря уже о сбросе пароля, если учетная запись, которая используется на 10 машинах, скомпрометирована, поскольку в рабочей группе 10 машин для входа в систему и сброса, теперь, если это было 100 машин, это безумие, не говоря уже о том, если вы пропустите одну машину, которая у вас есть дыра. Если только вы не начнете все это писать.
Если вы действительно хотите отделить производственные машины от сети рабочих станций, тогда вы можете использовать брандмауэр между двумя сетями и по-прежнему использовать одну и ту же AD.
Или иметь 2 полностью независимых домена с доверительными отношениями (или нет) между ними по мере необходимости.
или иметь домен с 2 лесами
или, ну, список бесконечен, это действительно то, что вам нужно.
Одна из ваших проблем - компьютер пользователя, зараженный вирусом, а затем заражение рабочего сервера, если они оба находятся в AD. AD так не работает. AD сам по себе является базой данных вашего домена.
Если машина A имеет вирус и имеет сетевой доступ к машине B, то машина A может атаковать машину B. AD не задействован. Машина A просто делает то же самое, что и вирус, чтобы атаковать другую машину. Он может пробовать брут для машины B, он может пробовать атаку RPC и так далее. AD не имеет ничего общего с включением этого подключения. В этом случае необходим межсетевой экран между двумя сетями. Таким образом, у вас будет сеть A для рабочих станций и сеть B для производства. Это обычная установка в компаниях: как предотвратить то, о чем вы беспокоитесь.
Проверить Эвана ответ о том, что такое AD.
Я согласен с Иззи. Домены значительно упрощают управление этими серверами, что, в свою очередь, может сделать их более безопасными.
Кажется, вы немного знакомы с AD, но не очень много, поэтому я предлагаю вам пройти либо вводный курс по AD, либо более углубленный курс по AD и Windows Server Management в целом. . Он ответит на множество ваших вопросов, и люди, проводящие курс, должны быть в состоянии ответить на некоторые из ваших вопросов с помощью гипотетических сценариев. Вы должны иметь возможность представить им свою текущую схему сети, и они должны дать вам предложения о том, что можно улучшить, почему интеграция серверов в AD является хорошей идеей, как обезопасить людей от них и т. Д.
Скорее всего, если ваша компания ценит вас как системного администратора, они также могут оплатить ваши курсы, что является бонусом.
Но я собираюсь согласиться со всеми в этом: определенно добавляйте свои серверы в AD, но делайте это правильно. Я не вправе точно говорить, что подходит вашей организации, потому что я ничего об этом не знаю, но заблокируйте это настолько, насколько вы можете, не делая его непригодным для использования людьми, которые должны его использовать.
И вот гипотетическая ситуация, которая может заставить вас снова задуматься о добавлении серверов в AD: у вас есть разработчик или другой системный администратор, который уволен. Ваш босс звонит вам и говорит: «Этого человека НЕОБХОДИМО НЕМЕДЛЕННО заблокировать в системе. Мы подозреваем, что он может пытаться украсть у нас информацию, защищенную HIPAA, и он больше не работает здесь. Заблокируйте его сейчас». (Я предполагаю, что у вас есть данные, которые подпадают под действие HIPAA, как вы упомянули здравоохранение)
С вашей текущей настройкой вы не только должны заблокировать его учетную запись AD, но также должны перейти на каждый сервер и отключить его учетную запись там. Если бы серверы были в AD, вы могли бы мгновенно отключить его доступ к этим серверам менее чем за 30 секунд. Это просто: RDP to DC, Open Active Directory Users and Computers, Щелкните правой кнопкой мыши его имя, нажмите Disable. Бам, готово. Он заблокирован.
Но определенно внесите их в AD, как только поймете, как лучше всего защитить их.
Серверы в рабочих группах - кошмар для большинства сетей. Полученная безопасность более мнимая, чем реальная. Если у скомпрометированной машины есть разрешения на доступ к серверу, не имеет значения, является ли это сервером рабочей группы или доменом. Поскольку разрешениями намного проще управлять на уровне домена, я считаю, что наличие серверов в домене на самом деле повышает безопасность, если, конечно, все сделано правильно.