Виртуализация становится все более распространенной технологией консолидации парка серверов.
Кризис подтолкнул многие организации к его широкому использованию.
По данным IDC, в последнем квартале 2009 года было выпущено 350 000 серверов, из которых 18,2% были виртуализированы.
На первый взгляд, виртуализация примечательна со всех сторон, потому что.
позволяет оптимизировать утилизацию оборудования и повышает гибкость инфраструктуры.
Но если присмотреться, то окажется, что оно имеет и неочевидные негативные последствия.
Давайте посмотрим на один из них.
Как только технологии виртуализации становятся доступными достаточному количеству людей в организации, наступает эйфория.
Теперь развернуть набор виртуальных машин с необходимыми сервисами гораздо проще, чем физический сервер.
Ресурсы кажутся практически безграничными, поэтому каждый отдел начинает развертывать свои собственные виртуальные машины.
В этот момент начинается бесконтрольное распространение виртуальных машин.
Через какое-то время все запутываются в том, кому теперь чем принадлежит, кто отвечает за конкретную виртуальную машину и где она находится.
В результате со временем в вашей инфраструктуре появляется множество бесхозных виртуальных машин.
Некоторые из них продолжают бесконтрольно работать, некоторые отключены, а некоторые месяцами находятся в спящем состоянии.
Из-за того, что обновление этих тестовых виртуальных машин не настроено, получается, что внутри инфраструктуры появляются точки, не подпадающие под действие корпоративной политики безопасности.
Если в организации нет процесса управления конфигурацией и изменениями, она вскоре столкнется с инцидентами безопасности.
Все методы, о которых я напишу ниже, в основном применимы к виртуальным машинам Windows, но частично применимы и к Linux/Unix. Бороться с проблемой отсутствия обновлений внутри виртуальных машин можно комбинацией нескольких методов.
Реализация единой системы хранения образов развертывания виртуальных машин, например библиотеки SCVMM. Шаблоны виртуальных машин уже должны содержать заранее указанные методы автоматического обновления.
Чтобы владелец виртуальной машины не смог отключить в ней агент обновлений, вы можете использовать технологию Network Access Protection, которая позволяет помещать в карантин физические и виртуальные машины, если они не соответствуют нашим сетевым политикам.
Одной из политик может быть то, что в системе работает агент обновлений и что последнее обновление не старше X дней или часов.
Таким же образом мы можем контролировать наличие антивируса в системе, его обновления и статус, а также другие необходимые нам системные процессы.
Эти меры решают проблему поддержания включенных виртуальных машин в актуальном состоянии.
К сожалению, на данный момент ни WSUS, ни SCCM не могут обновлять только системы, находящиеся во включенном состоянии.
А как насчет эталонных виртуальных машин, хранящихся в библиотеке SCVMM, или машин, находящихся в приостановленном состоянии на узлах Hyper-V? Обычно на сленге такие машины называют «спящими».
В таком состоянии они могут оставаться месяцами.
Все это время на них не устанавливаются обновления.
При включении такие машины потенциально могут послужить плацдармом для атаки или распространения эпидемии.
Чтобы поддерживать эти системы в актуальном состоянии, нам понадобится Инструмент автономного обслуживания виртуальных машин Microsoft он же ОВМСТ.
Этот инструмент позволяет выполнять следующие задачи:
- Обновите виртуальные машины завершения работы в библиотеке SCVMM.
- Найдите и обновите остановленные и неактивные виртуальные машины на хостах Hyper-V.
- Обновите шаблоны виртуальных машин.
- Начиная с версии 3.0 утилита Offline Virtual Machine Servicing Tool позволяет добавлять файлы обновлений в VHD-файлы виртуальных жестких дисков, хранящиеся в библиотеке SCVMM.
Как видите, наша инфраструктура содержит библиотеку и сервер SCVMM, сервер для обслуживания виртуальных машин и сервер обновлений WSUS или SCSM. Стоит отметить, что все эти хосты обычно изолированы от основной сети с помощью VLAN. Только хост с SCVMM имеет доступ к основной сети.
В данном случае это шлюз между VLAN. Это сделано для того, чтобы виртуальные машины, которые мы будем обновлять, не могли подвергнуть риску основную сеть, обмениваясь в ней данными во время установки обновлений.
Давайте пошагово рассмотрим, как обновляются виртуальные машины?
- Чтение данных из библиотеки SCVMM и выбор виртуальных машин, шаблонов, дисков.
- Найдите «спящие» виртуальные машины на хостах Hyper-V, подключенных к SCVMM.
- Создание групп сервисов и размещение в них виртуальных машин и шаблонов дисков, собранных на первом и втором шагах.
- Перенос «спящих» виртуальных машин с хостов Hyper-V или развертывание их из шаблонов, хранящихся в библиотеке SCVMM, на хостах Hyper-V, предназначенных для обновления гостевых ОС.
- Выключите или включите компьютеры, обновляемые на узле обслуживания Hyper-V.
- Принудительная проверка обновлений, необходимых виртуальной машине.
- Применение обновлений к виртуальной машине.
- Проверка статуса обновлений.
- Выключение виртуальной машины и при необходимости подготовка к ее возвращению в библиотеку SCVMM с помощью sysprep.
- Возвращение виртуального.
машину на хост, где она изначально находилась, или поместив ее в библиотеку, откуда мы ее получили
Теги: #Виртуализация #безопасность #Hyper-V #обновление Windows
-
Проектирование В Confluence
19 Oct, 24 -
Офисные Гарнитуры Snom A100M И A100D
19 Oct, 24 -
Почему Не Стоит Учиться Программировать
19 Oct, 24
