RumataRus
Commander
Commander

Обеспечение безопасности vCenter Server

Jump to solution

Допустим, каждый хост нашей инфраструктуры имеет две подсети.

Подсеть 0 – management network (vkernel, vmotion)

Подсеть 1 – виртуальные машины

vCenter Server мы хотим разместить в виртуальной машине (будем считать, что SQL сервер и сама база данных vCenter устанавливаются локально на той же ВМ).

В соответствии с рекомендациями по обеспечению безопасности vCenter Server должен иметь доступ только к подсети 0. На Firewall открыт минимум необходимых портов: TCP 389, TCP 443, TCP/UDP 902, TCP 903 (предоплагается, что Linked Mode отсутствует, доступ через Web-интерфейс не нужен). Если я не прав - поправьте.

С другой стороны, vCenter Server нужен доступ к службам DNS и NTP, которые я хотел бы разместить в подсети 1. Как лучше организовать этот доступ? Добавлять в ВМ с vCenter Server еще одну vNIC для доступа к подсети 1 противоречит рекомендациями по обеспечению безопасности. С другой стороны, организация промежуточных DNS и NTP серверов усложняет инфраструктуру...

Еще один момент связан с включением ВМ с vCenter Server в домен Windows. Включать/не включать?

0 Kudos
1 Solution

Accepted Solutions
Umlyaut
Expert
Expert

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

Михаил, Вы не обижайтесь, но "я Вам сейчас один умный вещ скажу"(с)Мимино. :smileygrin:

ИМХО, практически любую сложную тему можно "примитивизировать" (в хорошем смысле - свести на уровень базовых примитивов, определяющих самую суть). Как говорил Фейнман - "если вы не можете понятно объяснить суть своей работы несведущему человеку, значит вы пока не столь хороши в своём деле, как вам кажется". Это не личный выпад, если что... Smiley Happy

Причём действительно важные вещи по-настоящему инвариантны (ну вот люблю я этот строгий термин!) относительно "построения инфраструктуры безопасности, ролей, архитектуры информационной системы и много чего еще" - и даже с учётом "конкретного случая", "места внедрения" и "многих других причин".

Эту точку зрения с соответствующими аргументами и примерами я уже имел возможность привести здесь - причём предельно конкретно. Если Вам есть чем крыть - вэлкам, но, пожалуйста, только не общими соображениями. В конце концов, если Вы опрокинете мои аргументы для конкретных примеров своими столь же прикладными возражениями, то я охотно признАю, что ринг за Вами. Пока что мои опасения насчёт (не)безопасности представляются мне столь же обоснованными, сколь и конкретными.

Можно конечно подискутировать, но опять же если брать общие случаи, то любой вариант как с доменом так и без него, можно прекрасно размазать и аргументировать.

Дык зачем же дело стало - дискутируйте, размазывайте меня по стене, сложенной из Ваших аргументов! Smiley Happy

Причём, коллега, я не беру "общие случаи" - своего рода, "сферический домен в вакууме".

Вот Вам мой прошлый довод (для Марии) - виртуализируЮЩАЯ (хосты ESX, СХД и сеть между ними) и виртуализируЕМАЯ (VMки с домен-контроллерами, файлерами, мэйлерами, проксями, серверами БД, терминальниками и чёрт-те чем ещё) инфраструктуры изначально НЕ равны по иерархии: первая контролирует вторую, хостит её, обеспечивает связью элементы, быкапит, резервирует, хайавэйлибилитирует и прочая, и прочая, и прочая. Кто контролирует первую (контейнер), тот (до известной степени) контролирует и вторую (содержимое) - обратное НЕ верно! И делать один из ключевых элементов первой инфраструктуры (vCenter) одной из составляющих второй (AD) - значит рисковать скомпрометировать первую (наружную) инфраструктуру при компрометации второй (внутренней). Либо рисковать работоспособностью данного ключевого элемента (и завязанной на него первой инфраструктуры) при возникновении проблем со второй.

Опровегайте!!! :smileygrin:

View solution in original post

0 Kudos
79 Replies
Umlyaut
Expert
Expert

Допустим, каждый хост нашей инфраструктуры имеет две подсети.

Подсеть 0 – management network (vkernel, vmotion)

Подсеть 1 – виртуальные машины

vCenter Server мы хотим разместить в виртуальной машине (будем считать, что SQL сервер и сама база данных vCenter устанавливаются локально на той же ВМ).

В соответствии с рекомендациями по обеспечению безопасности vCenter Server должен иметь доступ только к подсети 0. На Firewall открыт минимум необходимых портов: TCP 389, TCP 443, TCP/UDP 902, TCP 903 (предоплагается, что Linked Mode отсутствует, доступ через Web-интерфейс не нужен). Если я не прав - поправьте.

С другой стороны, vCenter Server нужен доступ к службам DNS и NTP, которые я хотел бы разместить в подсети 1. Как лучше организовать этот доступ? Добавлять в ВМ с vCenter Server еще одну vNIC для доступа к подсети 1 противоречит рекомендациями по обеспечению безопасности. С другой стороны, организация промежуточных DNS и NTP серверов усложняет инфраструктуру...

Если есть возможность разместить NIC VMки vCenter`a в том же vlan`e, что и DNS/NTP серверы (subnet 1), то вообще всё просто: на NIC VMки с vCenter подвесить IPшник из subnet 1, а в настройках VM указать явно IP-адреса требуемых серверов. На файере VMки разрешить outgouing по 53 и 123 портам.

Если же VMка с vCenter торчит своим основным NICом жёстко только в vlan`e для subnet 0, то не вижу большого греха в добавлении в VMку второго NICa - далее см. выше: на этом NICе наглухо перекрывается всякий incoming, а outgouing разрешается только по портам 53 и 123. От этого безопасность не пострадает.

Еще один момент связан с включением ВМ с vCenter Server в домен Windows. Включать/не включать?

О каком домене идёт речь? Если о том, что живёт в subnet 1, то Вы этим включением противоречите самому себе (по части т.н. безопасности).

А если речь идёт о subnet 0, но там этот домен ещё сгородить требуется.

В случае vCenter основные преимущества домена - глобальные политики и глобальная же аутентификация - нафиг никому не сдались. Тем паче, что при stand-alone server vCenter можно разграничить полномочия по обслуживанию инфраструктуры: доменом занимаются доменные админы, не имеющие доступа на vCenter. И если предположить, что домен скомпрометируют, то даже тогда доступа у роли админа домена на Ваш vCenter не будет.

VTsukanov
Virtuoso
Virtuoso

Вам и без меня накидают рекомендаций, да и я держу vc на железе поэтому только комментарии

  • К vkernel доступ от vCenter не нужен, нужен доступ к SC (вообще используемые порты и сервисы тут - TCP and UDP Ports for vCenter Server, ESX hosts, and other network components management access[/url]) выбирите то чем собираетесь пользоваться.

  • Домен - мое имхо включать - это и контроль дополнительный и дополнительные рычаги обеспечения безопасности на хосте с vc.

Umlyaut
Expert
Expert
  • Домен - мое имхо включать - это и контроль дополнительный и дополнительные рычаги обеспечения безопасности на хосте с vc.

Про "контроль" и "рычаги" поподробнее можно? В чём профит по сравнению с локальным сервером? Только чур, GP не вспоминать - они тут не при чём.

0 Kudos
VTsukanov
Virtuoso
Virtuoso

Ну тут возможно моя специфика:

Контороль - потому творцов у нас много, желательно иметь следы кто что сделал (кастомное поле Created by в vc сильно помогает)

Только чур, GP не вспоминать

Ну как жеж не вспоминать Smiley Happy Если настройки окружения которые проще насаживать через GP, есть группа локальных администраторов которых тоже как то ограничивать нужно.

и это ... я специально оговорился - "мое имхо включать" - так что считаете не нужным - не вгоняте

0 Kudos
Umlyaut
Expert
Expert

Ну тут возможно моя специфика:

Контороль - потому творцов у нас много, желательно иметь следы кто что сделал (кастомное поле Created by в vc сильно помогает)

М-ммм... А что, стандартное логгирование на stand-alone server`e не помогает? Для чего на одиночном vCenter использовать сетевые фичи AD? Чего конкретно нельзя сделать для контроля локальными механизмами?

Только чур, GP не вспоминать

Ну как жеж не вспоминать Smiley Happy Если настройки окружения которые проще насаживать через GP, есть группа локальных администраторов которых тоже как то ограничивать нужно.

Настройки окружения, обычно, требуется "насаждать" на клиентские компы в AD - тут GP юзабельны, не спорю. Для сервера же vCenter такой необходимости не наблюдаю.

"Локальных администраторов" чего - сервера vCenter? Тогда вопрос - для чего и в какую сторону их ограничивать?

Дело в том, что "локальные администраторы" доменного сервера всё-равно имеют массу возможностей на нём - если уж им даны подобные привилегии, то на это есть резоны - и "ограничивать" их при этом.... м-да...

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

0 Kudos
VTsukanov
Virtuoso
Virtuoso

стандартное логгирование на stand-alone server`e не помогает?

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

доменного сервера всё-равно имеют массу возможностей на нём

заводим ou, загоняем тестовый сервер, выключаем через gp некий win сервис, применяем политику и попытаемся под любым административным аккоунтом его поднять на этом тестовом сервере

Будем надеяться, Вы знаете что творите в своей сети

будем

0 Kudos
Umlyaut
Expert
Expert

fixed

0 Kudos
RumataRus
Commander
Commander

Коллеги, мне кажется за время моего отсутствия Вы ушли от поднятой темы.

Предлагаю вести себя корректнее. Боже упаси, не подумайте, что я собираюсь вас воспитывать.

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

По существу поднятой темы.

Если есть возможность разместить NIC VMки vCenter`a в том же vlan`e, что и DNS/NTP серверы (subnet 1), то вообще всё просто: на NIC VMки > с vCenter подвесить IPшник из subnet 1, а в настройках VM указать явно IP-адреса требуемых серверов. На файере VMки разрешить

outgouing по 53 и 123 портам.

Если же VMка с vCenter торчит своим основным NICом жёстко только в vlan`e для subnet 0, то не вижу большого греха в добавлении в VMку

второго NICa - далее см. выше: на этом NICе наглухо перекрывается всякий incoming, а outgouing разрешается только по портам 53 и 123. От

этого безопасность не пострадает.

А если вообще без VLANов? Как я понимаю, тогда нужно реализовывать вариант №2: первую NIC привязывать к subnet 0 и разрешать входящий/исходящий трафик только по портам TCP 389, TCP 443, TCP/UDP 902, TCP 903 и другим по необходимости; вторую NIC привязывать к subnet 1 и, как Вы рекомендуете перекрывать всякий входящий трафик, а для исходящего разрешать только порты 53 (DNS) и 123 (NTP).

При этом, как я Вас понимаю, предполагается, что эту ВМ мы в домен, что живёт в subnet 1, не включаем. Если включаем - придется на второй NIC разрешать трафик на порты для доступа к AD.

О каком домене идёт речь? Если о том, что живёт в subnet 1, то Вы этим включением противоречите самому себе (по части т.н. безопасности).

Речь идет о домене в subnet 1. Я затем и задавал вопрос, чтобы услышать разные аргументированные мнения.

А если речь идёт о subnet 0, но там этот домен ещё сгородить требуется.

В случае vCenter основные преимущества домена - глобальные политики и глобальная же аутентификация - нафиг никому не сдались. Тем

паче, что при stand-alone server vCenter можно разграничить полномочия по обслуживанию инфраструктуры: доменом занимаются доменные

админы, не имеющие доступа на vCenter. И если предположить, что домен скомпрометируют, то даже тогда доступа у роли админа домена на > Ваш vCenter не будет.

В домене на subnet 0 я для своей инфраструктуры необходимости не вижу.

0 Kudos
RumataRus
Commander
Commander

заводим ou, загоняем тестовый сервер, выключаем через gp некий win сервис, применяем политику и попытаемся под любым административным аккоунтом его поднять на этом тестовом сервере

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

Дело в том, что изначально он пишет о локальным сервере. А затем о доменном. Но у меня сложилось впечатление, что когда он говорит о возможностях локальных администраторов, он имеет ввиду все-таки локальный сервер, т.е. не включенный в домен.

А если сервер включен в домен, то конечно Вы правы - локальных администраторов с помощью GP при необходимости ограничить можно.

0 Kudos
VTsukanov
Virtuoso
Virtuoso

За что вы извиняетесь, это ваш топик

Да сервере не включенном в домен такая манипуляция не возможна.

А включать в домен свой сервер с vc, или не включать, определять вам согласно вашей политики безопасности, текущей и планируемой инфраструктуры.

0 Kudos
RumataRus
Commander
Commander

Топик мой, но спор не мой. Я просто пытался разобраться из-за чего шумим.

0 Kudos
VTsukanov
Virtuoso
Virtuoso

Шумим ... ааа нет это просто было обсуждение вопроса нужно ли включать сервер с VC в домен и зачем.

0 Kudos
MariaSidorova
Enthusiast
Enthusiast

На мой взгляд, корректнее было бы сделать так:

1. Ввести сервер управления в домен. Аутентификацию пользователей производить с использованием доменных учетных записей. Управление доступом пользователей к объектам инфраструктуры производить с использованием всего набора возможностей ролевого механизма.

2. Для полного административного доступа к серверу управления создать специальную персонализированную учетную запись (доступ в исключительных случаях).

-


http://www.risc.today/ https://www.facebook.com/groups/RISClub/ https://twitter.com/RISClubSPb
0 Kudos
MKorotko
Expert
Expert

Я соглашусь с Марией.

У меня в паре инфраструктур так и сделано.

-


VMware vExpert 2010

VMware vExpert 2010, 2011 - http://vm.pro-it.kz
0 Kudos
VTsukanov
Virtuoso
Virtuoso

Мария

исходно вопрос был включать ли в домен, я слабоаргументировано высказался за домен, коллега Umlyaut высказал сомнение в целесообразности действия (это я к тому что убеждать меня в целесообразности включения в домен не нужно). По поводу ролевого механизма - мы практически им не пользуемся (исключение тогда когда нужно end user-у дать доступ к консоли vm или права на on/off через VMRC). Частично причины, возможно необоснованные : недоверие к MSSQL security + существование в базе незамысловатой таблицы VPX_ACCESS (как можно использовать для локальных пользователей в kb vmware[/url]).

0 Kudos
Umlyaut
Expert
Expert

Рискуя прослыть негалантным, буду спорить... :smileygrin:

На мой взгляд, корректнее было бы сделать так:

1. Ввести сервер управления в домен. Аутентификацию пользователей производить с использованием доменных учетных записей.

Первое замечание (не в смысле нарекания, а в формате notabene) - про "аутентификацию пользователей".

Каких "пользователей", Мария? У вин-сервера с vCenter "пользователи" - это администраторы VI, обслуживанием которой и занимается этот vCenter. Доменным пользователям делать на нём решительно нечего (в отличие от серверов, предоставляющих в домене доступ к различным сетевым ресурсам - шары, спулеры, еtc.).

Управление доступом пользователей к объектам инфраструктуры производить с использованием всего набора возможностей ролевого механизма.

Так, давайте разбираться.

Что является "объектами инфраструктуры" (полагаю, что речь идёт о VI, а не об инфраструктуре домена, "живущего внутри" этой VI, нет?) ??? Видимо, это хосты ESX(i), СХД, сетевые устройства.

"Среди меня" (как выражается ув.коллега michigun Smiley Happy ) есть мнение, что пользователи домена (о которых Вы печётесь Smiley Happy ) НЕ должны иметь доступа к объектам этой, базовой, несущей инфраструктуры (VI).

Т.е., даже если ввести сервер vCenter в домен, то всё равно давать к нему (а через него - к объектам VI !) доступ пользователям "с использованием всего набора возможностей ролевого механизма" не представляется необходимым.

Теперь notabene 2...

В вышеизложенных рассуждениях есть одна недоговорённость ( сознательно отложенная до отдельного объяснения): "пользователи домена" считаются именно пользователями - т.е., юзерами, - хотя с формальной точки зрения админы домена тоже входят в множество пользователей. Т.е., введя сервер с vCenter в домен, можно, по идее, дать к нему доступ роли админа домена (или специально сделанной для этой цели отдельной роли) и не давать доступа остальным ("рядовым") ролям.

Однако такое рассуждение будет в известной степени спекулятивным - по соображениям той же безопасности.

Во-первых, VI в иерархическом смысле находится "над" инфраструктурой домена (AD), базирующейся внутри VI.

Соответственно, в общем случае, админы VI имеют доступ по вектору "вниз" (к виртуальным машинам, составляющим домен (AD), и данным на них), тогда как админы домена НЕ имеют симметричного доступа по вектору "вверх" - точнее, они даже (в теории) не осознают, что есть уровень "над" их доменом, бо серверы, составляющие домен, крутятся в вирт.машинах так же, как и на физ.машинах в физ.сети.

Для админов домена (AD) наличие "над" доменом VI "прозрачно" до состояния невидимости.

Отсюда следует, что доступ какой-либо роли "изнутри" домена к серверу vCenter (сделанному членом данного домена) есть нечто противоестественное (и потенциально небезопасное).

Во-вторых, даже если допустить ситуацию, когда админ(ы) домена (AD) и админ(ы) VI функционально совпадают (одни и те же сотрудники IT-отдела), то всё равно пользоваться доменной учёткой (соответствующей роли) для доступа на сервер vCenter не есть секурно - мне доводилось сталкиваться с ситуацией, когда административный доступ в домене получали неуполномоченные на то пользователи. Способы были разные - "угон" админского пароля, повышение привилегий до уровня админского через уязвимость, ошибки распределения ролей по группам.

В подобном случае возможно (и далеко не теоретически!) проникновение "незаконного админа" из домена (AD) на сервер vCenter с последующей компрометацией им ("админом") уже самой VI. В случае же standalone server`a с vCenter доменные админы (кто бы они не были) доступа к нему не имеют.

2. Для полного административного доступа к серверу управления создать специальную персонализированную учетную запись (доступ в исключительных случаях).

Мария, я не совсем понял эту фразу... О каком "сервере управления" идёт речь - о вин-сервере, на котором стоИт vCenter? Или вы "сервером управления" называете сам vCenter?

Впрочем, в любом случае роль админа домена имеет приоритет перед любой другой ролью (включая локальные роли сервера-носителя vCenter) - соответственно, всё вышесказанное мною остаётся в силе.

0 Kudos
RumataRus
Commander
Commander

Не могу предугадать ответы Марии, но могу с уверенностью сказать, что я с Вами солидарен во взглядах по этой теме.

0 Kudos
Umlyaut
Expert
Expert

Пока ехал на работу, в голову пришёл ещё один (контр)аргумент - изложу его отдельно (чтоб не апдейтить мой ответ Марии).

Дело в том, что если сервер-носитель vCenter будет членом домена (AD), то вполне реальна ситуация, когда какие-либо траблы (в т.ч. и особенно - с VI) приведут к недоступности для него контроллеров домена. В этом случае зайти на данный сервер под доменной учёткой с сетевой авторизацией будет проблематично.

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

Однако, даже если воспользоваться одним из этих обходных путей и попасть на сервер (для работы с vCenter), то всё равно нас могут ждать проблемы следующего свойства: для работы с vCenter очень часто используют "сквозную", доменную авторизацию (по учётке AD). В этом случае я не поручусь, что локальное кеширование поможет: емнимс, попытка авторизации на контроллере домена будет предпринята директивно при заходе в vCenter. И ещё одни подводные грабли - MSSQL (используемый в качестве БД для vCenter) принято по умолчанию интегрировать в AD для всё той же"сквозной авторизации". И если для своей работы учётка SQL потребует связи с DC, который в данный момент недоступен, то можно оказаться без (работающего) vCenter - и как раз в тот момент, когда он весьма нужен. Smiley Happy

Вот где-то так... Smiley Happy

0 Kudos
RumataRus
Commander
Commander

Это, кстати, та проблема (частичная или полная неработоспособность AD), которая стала для меня одним из весомых аргументов в пользу выбора VMware вместо Hyper-V.

Как я понимаю, проблемы с AD могут привести к проблемам доступа к Cluster Shared Volume, на котором размещаются виртуальные машины со всеми вытекающими отсюда последствиями.

На семинарах Microsoft, посвященных Hyper-V, я частным порядком спрашивал у ведущих, как быть с этой проблемой, но вразумительных ответов не получил.

0 Kudos