VDI: невиртуальные проблемы «виртуалки» и их реальные решения

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

Однако, возможность разместить множество серверов на одном физическом хосте – лишь одна из многочисленных радостей «виртуалки».

Пожалуй, второе по значимости применение технологий виртуализации в наши дни – это Инфраструктура виртуальных десктопов (Virtual Desktop Infrastructure, VDI). Использующая все ту же главную идею множества компьютеров в одном физическом «теле», она предназначена совершенно для другого: заменить многообразие физических рабочих станций единообразной и легко контролируемой виртуальной средой.

В отличие от привычной – и разменявшей уже не первый десяток лет – Инфраструктуры терминальных сервисов, предлагающей разделяемый доступ к среде операционной системы сервера-хоста, VDI – это про «настоящую» виртуализацию. Это значит, что каждая виртуальная рабочая станция представляет собой «вещь-в-себе», со своим собственным набором виртуального «железа» и операционной системой – и своим собственным набором потенциальных проблем безопасности, которые, на поверку, могут возникать куда чаще, чем в случае с серверной виртуализацией. Особенно в случае если рабочий сценарий подразумевает доступ к «большому интернету» – вместе с его ландшафтом угроз и армиями любителей поживиться за чужой счет. И не дай бог вам хотя бы на мгновение поверить в миф о том, что виртуальные вычислительные среды безопаснее физических. Отнюдь; в большинстве аспектов обеспечения безопасности они крайне похожи на привычные физические – а некоторые их особенности делают эту задачу еще сложнее.

Именно об этом – о безопасности VDI, ее мифах и особенностях, и о том, как правильно подойти к задаче ее обеспечения, – мы и хотим поговорить в этом посте.

VDI: плюсы и минусы

Плюсы VDI

Прежде чем мы перейдем к проблемам VDI, хотелось бы лишний раз напомнить, за что её любят как сисадмины, так и специалисты ИТ-безопасности. Итак:

• VDI является практически независимой от клиентского «железа» и операционной системы. Все, что требуется от устройства, – будь то обычный компьютер, смартфон или «тонкая» станция – это способность запустить программу-клиент (а в некоторых случаях хватит и веб-браузера).
• VDI предлагает существенно более высокий уровень безопасности данных: в самом деле, вся ценная информация сохраняется удаленно, практически исключая риск физической утери или похищения данных вместе с клиентским устройством.
• VDI обеспечивает гибкость управления средой: виртуализированные рабочие станции и приложения могут создаваться и управляться с легкостью, недостижимой в физических средах. При хорошо отлаженном рабочем процессе в случае возникновения «виртуальных» проблем на одной из машин их может даже не понадобиться решать; станции заново создаются из предварительно подготовленного шаблона, а централизованно хранящиеся пользовательские данные станут доступными сразу после запуска машины и авторизации клиента.

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

Минусы VDI

К сожалению, ни одно решение в мире не состоит из одних лишь плюсов. У VDI
также есть свои ограничения и нюансы, которые необходимо учитывать:

• Чувствительность к ресурсопотреблению. Виртуальные рабочие среды нужны для выполнения задач более или менее аналогичных тем, что пользователи привыкли решать, используя обычные компьютеры. Однако, среди этих задач, даже если в рабочем процессе нет ничего лишнего, бывают и достаточно ресурсоемкие – а пользователя, как известно, мало что демотивирует так, как медленная работа оборудования. Периодические «тормоза» легко способны свести на нет выигрыш в эффективности, полученный в результате внедрения VDI. Это значит, нужно постоянно учитывать все составляющие отзывчивого функционирования системы – включая эффект от работы защитных решений.
• Целесообразность формализации рабочего процесса. Лучше всего VDI работает, когда рабочий процесс предсказуем, все запускаемые приложения известны, и у пользователя нет никакой возможности это изменить. В противном случае все тщательные расчеты ресурсопотребления могут оказаться напрасными. К тому же программы неизвестного происхождения, которые не ограниченный политиками пользователь может устанавливать и запускать, могут нести угрозу корпоративной безопасности.
• Высокие требования к защитному решению. В отличие от атак на серверы хранения данных и других подобных сценариев, где главным объектом нападения являются удаленно доступные данные, виртуальные рабочие станции подвержены практически полному спектру угроз, от которых страдают станции физические. Эти угрозы могут включать, например, бестелесные зловреды, прямую инъекцию в процессы с помощью эксплойтов и т.д. Это значит, что большинство хорошо известных решений для виртуальных сред, которые учитывают все их нюансы, но защищают только на уровне файлов, не сможет обеспечить адекватную защиту VDI. Разумеется, можно установить обыкновенное «десктопное» решение – производители чаще всего бодро заявляют о поддержке ими виртуальных сред. Однако, на деле это в лучшем случае ведет к резкому снижению ресурсоэффективности VDI; ведь каждая виртуальная машина несет полный набор движков и независимо обновляющиеся базы. В худшем же случае «шторм» одновременных сканирований или обновлений может привести к катастрофическому падению производительности – или даже отказу в обслуживании.

Мифы и угрозы

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

1. Зловреды подозревают в виртуальной машине «песочницу» (Sandbox) или рабочую среду исследователя-безопасника и, определив ее наличие, не запускаются в ней.
2. В грамотно сконфигурированной VDI виртуальная машина сама по себе не представляет никакой ценности; в случае заражения, проще уничтожить машину и создать из шаблона новую.

Попробуем разобраться, что на самом деле стоит за этими аргументами, и стоит ли на них опираться при организации защиты VDI.

«Виртуалка» как пугало для зловреда?

В основе этого аргумента лежит достоверный факт: многие зловреды действительно ищут признаки того, что запущены в виртуальной машине. Но последствия обнаружения этих признаков далеко на всегда однозначны. Создатели зловредов отчетливо понимают, что с виртуальных машин, НЕ являющихся «песочницами» или компьютерами вирусных аналитиков, можно похитить весьма ценные данные – а потому учатся выявлять как опасные так и, наоборот, интересные для них виртуальные машины. Для этого может использоваться целый ряд признаков: заранее выясненные IP-адреса исследовательских систем, типовые имена пользователей и компьютеров, отсутствие «урезанных» ради уменьшения ресурсопотребления системных компонентов и так далее. Существуют и более продвинутые способы: оставление в файловой системе машины метки, повторные сеансы связи зловреда с серверами управления (C&C), подтверждающие ее сохранность (время жизни работающей в автоматическом режиме «песочницы» обычно ограничено) и т.д. Что уж говорить о целевых нападениях, когда принятие решения о дальнейшем развитии атаки на основе полученных разведданных остается за живыми людьми.

Вывод прост: вероятность того, что зловред не заработает, существует, но надеяться на это при построении системы безопасности для VDI (которая вдобавок имеет гораздо больше возможностей для заражения, чем виртуальные серверы) – непростительная ошибка.

Нет машины – нет заражения?

Ключевая ошибка второго аргумента состоит в том, что не стоит рассматривать отдельно инфекцию каждой виртуальной машины. В типичном случае в одном и том же сегменте сети их может работать множество, и при попадании зловреда на одну из них, особенно с учетом молниеносной скорости работы виртуальной сети, распространение вредоносной программы по всему сегменту может произойти очень быстро. И неважно, что машина, ставшая «нулевым пациентом», скоро будет уничтожена; перекрестное заражение машин в сети может теоретически происходить до бесконечности, точнее, до тех пор, пока не будет погашена вся сеть, в пределах которой мог распространяться зловред. Более того, следы деятельности зловреда, успевшего отработать в системе «нулевого пациента», пропадут вместе с исчезновением этой виртуальной машины – а ведь они являются наиболее ценными с точки зрения расследования инцидента!

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

Таким образом, при обнаружении заражения возможность уничтожить зараженную «виртуалку» может в лучшем случае лишь слегка облегчить задачу восстановления рабочего процесса, ни коим образом не влияя на безопасность в целом.

Полный спектр угроз

Очевидно, что виртуальные десктопы подвержены практически полному спектру угроз, от которых страдают машины физические. А что насчет специальных атак, тех, что эксплуатируют особенности именно виртуальной среды? Исследователи на конференциях успели показать немало концепций нападения на «виртуалку» (Proof-of-Concept), потенциально способных натворить немало бед, – однако до сих пор ни одного случая реализации таких атак в реальных условиях зарегистрировано не было. Но не стоит обольщаться: драйвером технологического роста для атакующих является востребованность. Как только проникновение виртуальных сред во все области жизни достигнет определенного уровня, концептуальные атаки легко могут стать реальностью. И в данном случае речь идет об относительно массовых угрозах. В случае же необходимости направленно атаковать некую особо важную цель – и наличии у заказчика средства на такую сложную атаку – в ход могут пойти любые известные и неизвестные разработки, включая и эксплуатацию особенностей VDI и виртуальных сред как таковых.

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

Защита VDI: стратегия и тактика

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

Конфигурируй безопасно!

Как мы все давно знаем, самая страшная уязвимость любой системы – это люди. Однако не стоит забывать, что это относится не только к рядовым пользователям, безрассудно кликающим на ссылки от незнакомцев, но и к ИТ-специалистам, которые оставили при конфигурировании системы возможности для злоумышленников. Какие же еще «гайки» можно закрутить, чтобы максимально усложнить жизнь нападающим? Ниже несколько примеров, которые, теоретически, применимы и в физических сетях, и в сетях виртуальных.

• Запретить с помощью доменных политик любую локальную авторизацию. Особенно это актуально в средах с «одноразовыми» машинами, которые создаются и уничтожаются по мере необходимости; задача отладки «заглючившей» в процессе работы машины практически исключена.
• В любом сценарии с формализованным рабочим процессом максимально сократить возможности для запуска сторонних программ, вплоть до применения принципа «Запрет по умолчанию» (Default Deny). При известной специфике рабочих сценариев с использованием VDI, особенно в таких сферах как здравоохранение или страхование, внедрение такого подхода возможно достаточно легко и безболезненно.
• Запретить использование Java и всех командных интерпретаторов, включая Powershell
  и даже CMD.EXE, если они строго не необходимы для исполнения каких-то рабочих задач. Java остается одним из наиболее часто эксплуатируемых объектов, а скриптовые цепочки получают все большее распространение в качестве «легального» (т.е. использующего встроенные системные возможности) способа обхода механизмов детектирования.
• Если конфигурация сети позволяет, использовать Private VLANs (приватные виртуальные сети), для того чтобы изолировать виртуальные машины друг от друга. В подавляющем большинстве сценариев у них нет необходимости видеть друг друга в сети, а нужен лишь доступ к интернету и к серверам с базами данных/бэкэндами корпоративных приложений. Такая конфигурация позволит существенно сократить возможности для распространения инфекции. Стоит заметить, что в ряде случае это потребует от физических свитчей, если такие есть в коммутационной цепи, поддержки PVLAN. Однако уже сейчас в рамках парадигмы Программно-определяемых сетей (Software Defined Networks) существуют виртуальные свитчи, помогающие избежать флада (flood) свитчей, не поддерживающих PVLAN.

Виртуальные частные сети позволяют разграничивать сетевой доступ между виртуальными машинами без истощения адресной емкости IP-подсетей. Источник: VMware

Многослойная защита

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

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

Стандартный подход

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

Безагентский подход

Наиболее распространенный тип специализированных решений для защиты виртуальных сред ориентирован на защиту исключительно систем под управлением продуктов VMware. Для доступа к виртуальным машинам они используют «безагентский» подход на базе механизма VMware vShield – или же более современного, присутствующего в VMware NSX. В этом варианте за защиту отвечает специализированная виртуальная машина защиты (Security Virtual Machine, SVM), используя технологию платформы для доступа к защищаемым «виртуалкам». Вполне естественно, что такой подход значительно экономнее полноагентского, поскольку исчезает необходимость дублирования задач обновления и сканирования – их выполняет SVM. Это также решает проблему штормов активности: обновляются только базы на SVM, а сканирование машин автоматически распределяется во времени, чтобы избежать пиковых нагрузок.

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

Подход с использованием легковесных агентов

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

Подобно «безагентским» решениям, такие решения также используют выделенную виртуальную «машину безопасности» (Security Virtual Machine, SVM), которая позволяет избавиться от дублирования сканирующих механизмов и обновлений на каждой «виртуалке». Вместе с тем, небольшие программные агенты, обеспечивающие связь SVM с пользовательскими машинами, обеспечивают также полный контроль процессов в памяти, дающий возможность поведенческого детектирования. Кроме того, в решениях, построенных по такому принципу, могут быть реализованы дополнительные слои безопасности.

Так, в нашем продукте Kaspersky Security for Virtualization в варианте с Легким Агентом реализованы:

• Защита от эксплойтов (Automatic Exploit Prevention, AEP)
• Контроль приложений, использующий облачные Динамические списки разрешенных программ
• Веб-контроль с облачной поддержкой категорий веб-ресурсов
• Контроль устройств
• nIDS/nIPS (Network Attack Blocker, детектирование и защита от сетевых атак)
• HIPS (хостовая защита от вторжений)
• Файрволл, работающий на нескольких уровнях модели OSI, включая уровень Приложений
• Антифишинг с поддержкой облачного репутационного сервиса и автономной эвристики

(Подробнее о Kaspersky Security for Virtualization с Легким Агентом см. здесь.)

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

Также немаловажным является более высокая отказоустойчивость такой системы: в случае возникновения проблем с SVM, дополнительные слои безопасности не оставят пользователей совсем без защиты; отслеживаемые же на каждой станции системные события могут быть сохранены локально и обработаны позже при восстановлении связи с SVM – или же временно перенаправлены для обработки другой SVM, находящейся в той же сети.

При этом решения полностью учитывают все особенности виртуальных сред и конкретно VDI, включая такие механизмы как миграция машин между гипервизорами или поддержка «связанных клонов». Также мини-агенты легко можно встроить в шаблоны виртуальных машин, позволяя получить защиту сразу после их активации. Поддержка этих специфических механизмов нашим продуктом Security for Virtualization
с Легким Агентом была многократно протестирована, в том числе и в «боевых» условиях, в работе с наиболее популярными VDI средами, такими как VMware Horizon и Citrix XenDesktop.

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

Заключение

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