Так сложилось (и весьма логично), что виртуализация начиналась с крупных компаний и постепенно доехала и до небольших организаций, где уже покупают не сотни и десятки лицензий VMware vSphere, а единицы (зачастую, вообще на 2 сервера). При этом осознание проблемы того, что виртуальная инфраструктура оказывается защищенной меньше, чем ее физический предшественник, пришло далеко не сразу. Это неудивительно, поскольку виртуализация дает столько новых возможностей администраторам, что они даже думать отказываются о таких вещах.
Но потом понимание необходимости защиты виртуальной среды постепенно начало приходить в крупные компании. Как пример можно привести компанию Лукойл, где ИТ-менеджеры уже думают не только о защите VMware vSphere, но и выработали регламенты для защиты инфраструктуры виртуальных ПК VMware View. Потом стали появляться инциденты ИБ в сфере виртуализации (например, тут) и многие всерьез задумались, что надо хотя бы как-то базово защищать хост-серверы VMware ESX/ESXi и виртуальные машины. Стали появляться как внутренние регламенты ИБ виртуальных инфраструктур в организациях, так и внешние руководящие документы, например, VMware Security Hardening Guide и PCI DSS 2.0, CIS VMware ESX Server Benchmark 4 и другие.
(руководящие документы по безопасности - таблицы, таблицы, таблицы)
Оказалось, что возможных уязвимостей виртуальной среды VMware vSphere не так уж и мало: один только Security Hardening от VMware содержит 113 страниц информации о том, как можно потенциально "нагнуть" серверы виртуализации или сервер vCenter и скомпрометировать ВМ и их данные. Администраторы, взглянув на эти документы, поняли, что вручную настраивать и поддерживать инфраструктуру в соответствии с внутренними и внешними стандартами очень запарно, поэтому многие вообще отказались этим заниматься.
(новые угрозы в виртуальной инфраструктуре - 3 главных штуки)
Кроме того, учитывая специфику российских организаций, зачастую в компании вообще нет администратора ИБ, а полномочия между администраторами вообще никак не разделены - все они делят между собой роль суперпользователя для всего ИТ компании. Таким образом, смею утверждать, что большинство российских компаний, активно использующих виртуализацию, не защищены от внутренних и внешних угроз. От внутренних - потому что администраторы vSphere потенциально могут сделать все, что захотят с виртуальными машинами и их данными, а от внешних - потому что никто не хочет ковыряться в настройках (но это еще полбеды), а также поддерживать эти настройки постоянно, включая новые объекты виртуальной инфраструктуры - хосты, машины, сети, хранилища и т.п. (вот это уже целая беда). И это большие затраты.
Так вот компания Код Безопасности предлагает вам начать думать о защите виртуализации самым простым образом - без всяких таблиц и консольных утилит. Можно просто воспользоваться продуктом vGate R2, с помощью которого можно сделать первые шаги в обеспечении безопасности виртуальной инфраструктуры, а именно:
Просканировать инфраструктуру VMware vSphere на наличие уязвимостей. Это можно сделать совершенно бесплатно, используя утилиту vGate Compliance Checker от Кода Безопасности. Он поддерживает и vSphere 5, и 4.1, поэтому подойдет всем. По результатам анализа вы можете решить, какие именно уязвимости актуальны для вашей компании и какой потенциальный урон может быть нанесен, если кто-то их сможет использовать.
Определить, кто будет отвечать за безопасность VMware vSphere. Этот человек в компании может быть просто самым надежным администратором, ему можно назначить роль администратора ИБ, при этом сам он может вообще быть не администратором vSphere. Он сможет ограничивать других администраторов только сферой их полномочий, а также проводить регулярный аудит активностей:
Сделать простенькую модель угроз. Вообще, на сегодняшний день для виртуальной инфраструктуры VMware vSphere не существует адекватной модели угроз, которая бы не мешала нормальной работе администраторов и пользователей. Да, есть конечно всякие чеклисты и классификаторы уязвимостей, которые очень оторваны от жизни. Не смотрите на них, сделайте для себя просто список того, что нужно закрыть в первую очередь.
Сделать пилотную зону для vGate R2. Включить в нее несколько хостов, попробовать шаблоны политик безопасности для хостов ESXi и ВМ, посмотреть как будет выглядеть рабочий процесс по приведению в соответствие политикам новых объектов виртуальной инфраструктуры. Далее можно создать совсем простые политики из имеющегося большого набора шаблонов, которые закрывают самые большие дырки. Сами политики в vGate R2 применяются одной кнопкой, инженеры Кода Безопасности уже все продумали, как их там внутри ESX-а накатывать:
Потом можно попробовать поэкспериментировать с управлением полномочиями администраторов за счет средств защиты от несанкционированного доступа.
Попробуйте вовлечь все ИТ-подразделение компании в решение проблемы обеспечения ИБ. Напугайте их законом о персональных данных, если таковые есть в виртуальных машинах (подробнее тут, а тут для банков), объясните руководству требования руководящих документов (перечислены в начале), покажите сертификаты ФСТЭК на vGate R2 начальству, которыми в случае чего можно будет обороняться от различных органов.
То есть основная мысль такова - безопасностью VMware никто не хочет заниматься, потому что это муторно. Но если поставите vGate R2, то увидите, что это то средство, которым можно решить проблему, не особо напрягая ни себя, ни другие ресурсы компании.
Далее порекомендую несколько ссылочек, чтобы начать ознакомление с продуктом vGate R2:
Ну а если вы государственная организация, то есть специальное издание - vGate-S R2, которое позволяет применять продукт в автоматизированных системах уровня защищенности до класса 1Б включительно и информационных системах обработки персональных данных (ИСПДн) до класса К1включительно.
Ну и, напоследок, новая презентация о продукте vGate R2 в контексте госучреждений:
RSS
