Имеет смысл использовать единственное физическое поле и в демилитаризованной зоне и в Защищенной Зоне

Нет никакого окончательного ответа к этому вопросу, он зависит от Ваших собственных политик и персональных мнений о безопасности. Конечно, если Вы будете говорить с Cisco, VMware или Microsoft об их Nexus/ESX/Hyper-V продуктах, то они скажут, что они рады, что их продукты будут достаточно безопасны, чтобы сделать это, если настроено правильно - они однако не прыгнут в передачу что как риск.

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

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

Надеюсь, это поможет.

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

Позиция VMware по такого рода вещи:

Истина, уязвимости и использование никогда не будут полностью уходить ни для какого программного обеспечения предприятия, но ESX был удивительно стойким к таким проблемам. Если это произойдет снова, то мы найдем проблему и зафиксируем ее быстро, как мы сделали для CVE-2009-1244.

Мое взятие на этом - то, что выполнение VMs от различных сегментов сети на тех же хостах приемлемо. Я склонен разграничивать путем выделения отдельных физических ссылок NIC и vSwitches для крупнейших зон (пара NICs для 'Переднего Зонального' трафика демилитаризованной зоны и пара для 'Обратного Зонального' внутреннего трафика). Это подходится в интерфейсах, зависающих от базового брандмауэра поэтому, если у Вас есть интерфейс на брандмауэре, выделенном для определенного набора VLAN, у Вас есть та же самая группа на vSwitch в виртуальной среде.

Как общее объяснение, я беру урок от облачных вычислений на этом - Многие люди являются удобными рабочими нагрузками размещения, даже чувствительные, в вычисляют облака как амазонка ec2. Если бы Вы довольны тем сценарием для рассматриваемой рабочей нагрузки, почему Вы не были бы довольны им в своей собственной системе? В облаке Ваши рабочие нагрузки клиентских данных могли выполняться прямо вместе с любым количеством рабочих нагрузок неизвестного третьего лица. В Вашей собственной системе это всегда будет намного более управляемым, чем тот сценарий.

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

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

По-моему, я думаю, что это - лучшее решение.

Интернет - Cisco Брандмауэр - демилитаризованная зона - маршрутизатор Cisco - Сеть компании