Означает ли виртуализация сервера еще один уровень ОС для исправления и обновления, больше работы и больший риск?

Я выполнил поиск и не нашел ничего, связанного с исправлениями и обновлениями системы. У меня есть рекомендации, согласно которым на серверах должны быть необходимые исправления. Если у меня есть хост виртуальной машины, то это дополнительный слой для исправления и обновления - даже с «голыми железными» гипервизорами? В отличие от металлического сервера? (т.е. больше работы и тестирования и документации в соответствии с моими рекомендациями).

Как часто обновляются гипервизоры типа 1 / bare-metal? Это имеет значение? Вносит ли тот факт, что это дополнительный программный уровень, большую сложность и риск (безопасность и надежность)? (например, 99% свободного программного обеспечения x 99% свободного программного обеспечения = 98% свободного программного обеспечения)?

(Мой практический опыт работы с VMWare Workstation and Server и VirtualBox.)

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

Я буду использовать VMware ESXi версии 5.0 (не 5.1) в качестве примера ...

ESXi 5.0 имеет следующий график обновления:

В период с 9/2011 по настоящее время были выпущены ДЕСЯТЬ обновлений продукта ESXi 5.0. Из них SIX были ориентированными на безопасность обновлениями, свернутыми в пакеты обновлений с такими описаниями:

«Уязвимость разбора трафика ESXi NFS» - CVE-2012-2448 .

Эти уязвимости безопасности реальны, так как они иногда отражают общие ошибки безопасности Linux, но я думаю, что большинство организаций не очень подвержены рискам. Однако инженер должен оценить этот риск. Хотят ли ваши пользователи массово отключаться, чтобы исправить следующую уязвимость ?

«Макрос encode_name в файле misc / mntent_r.c в библиотеке GNU C (aka glibc или libc6) 2.11.1 и более ранних версий, используемый ncpmount и mount.cifs, неправильно обрабатывает символы новой строки в именах точек монтирования, что позволяет локальным пользователям вызвать отказ в обслуживании (повреждение mtab) или, возможно, изменить параметры монтирования и получить привилегии с помощью специально созданного запроса на монтирование. "

Может быть? Возможно, нет.

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

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

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

По моему опыту, можно сказать, что ESX и HyperV требуют меньше исправлений в целом, чем обычные операционные системы. Это не означает, что они вообще не нуждаются в исправлении или что применение некоторых исправлений не будет полезным независимо от «необходимости», но это означает, что обращения к вашим службам для исправления узла должны происходить реже и больше под вашим контролем. Существует потенциальный риск безопасности для операционных систем гипервизора, равно как и для любых других, и хотя вы можете минимизировать подверженность этому риску (например, только разоблачение управления гипервизором в изолированной VLAN, которая логически не может быть достигнута с скомпрометированного сервера) было бы глупо делать вид, что риска нет вообще.

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

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

Так почему же мы это делаем?

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

Используя этот подход , мне удалось залатать 5 ESX хосты в свою очередь , без каких - либо нарушений при всех к 40 виртуальных серверов , работающих на них. Это просто вопрос экономии за счет масштаба: если у вас достаточно потенциальных виртуальных гостевых машин, чтобы создать такую ​​сложную установку и управлять ею с помощью инструментов, о которых @ewwhite упоминает в своем ответе, окупаемость за счет снижения рисков. ты беспокоишься, прибывает очень быстро.

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

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

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