Два подхода к защите виртуализированных ЦОД
Виртуальные среды характеризуются чрезвычайной гибкостью, управляемостью, отказоустойчивостью и экономической эффективностью. Но чтобы защитить их от внешних угроз, нужно преодолеть ряд сложностей, и, если это не удастся, проблем не избежать. Это относится как к каждой отдельной виртуальной машине, так и ЦОД в целом.
Вирусные заражения в виртуальных средах происходят удручающе часто, особенно подвержены вирусным атакам VDI-среды: сотрудники заказчиков делают на своих виртуальных рабочих станциях что хотят, не особо заботясь об ИБ-гигиене, полагая, что как их собственный IT-департамент, так и сервис-провайдер стоят стеной на пути любого вредоносного ПО.
При этом провайдер в большинстве случаев не имеет права лезть в машины клиентов. Он вынужден требовать от них защищаться самостоятельно. Многие клиенты, хотя не все, подходят к этому ответственно, устанавливая на машины защитные решения класса endpoint protection – кому какие нравятся.
Случается также, что несмотря ни на какие призывы со стороны провайдера, клиент стоически смиряется с рисками и не делает для защиты вообще ничего. Можно не сомневаться, все его проблемы в итоге будут переложены на провайдера. И провайдеру придется браться за дело всерьез, в корне меняя стратегию защиты. (О связанных с безопасностью бизнес-проблемах, встающих перед дата-центром, читайте здесь).
В виртуализированных ЦОД хранение и обработка информации производится в виртуальных машинах и в системах хранения данных. Это совершенно разные технологии, требующие различных подходов к защите, и в каждом кроется немало нюансов.
Нюансы защиты виртуальной среды
Итак, если сервис-провайдер не займется защитой клиентских виртуальных машин, клиенты это сделают сами, каждый по-своему. С одной стороны, это вроде бы неплохо, каждый сможет выбрать защитное решение по своему вкусу. Но на практике такой подход оказывается не только неэффективен – разведенный на клиентских машинах «зоопарк» сам по себе порождает массу проблем:
- Избыточное использование аппаратных ресурсов. Система безопасности на каждой машине укомплектована полным набором компонентов: антивирусный движок, база сигнатур, брандмауэр и так далее. Каждый занимает свою долю процессорного времени, оперативной памяти, дискового пространства.
- Штормы. Совпавшее по времени антивирусное сканирование или обновление антивирусов на нескольких виртуальных машинах приводит к резкому росту потребления ресурсов, что выливается в падение производительности всей платформы, а то и к отказу в обслуживании. Конечно, защитное ПО можно вручную сконфигурировать так, чтобы не допустить штормов, но для сотен виртуальных машин затраты времени будут весьма чувствительны.
- Панические атаки. Зачастую система безопасности настраивается так, чтобы усиливать защиту при обнаружении вирусов на машине. Активируется «параноидальный» набор правил безопасности, запускаются внеплановые проверки. Это может создать повышенную нагрузку на «железо» хост-машины и негативно повлиять на производительность соседних виртуальных машин.
- Уязвимость при запуске. Виртуальные машины часто остаются неактивными, пока не будут по необходимости запущены. Пока машины не запущены, ни один из компонентов системы безопасности не будет обновлен, и в промежуток между запуском и обновлением защитного ПО машина будет уязвимой.
- Несовместимость. Виртуальные машины во многих аспектах схожи с физическими, но кое в чем существенно отличаются. Например, они используют диски динамически изменяющегося объема и могут мигрировать прямо во время работы. Стандартные системы безопасности, разработанные для физических машин, не учитывают нюансы работы виртуальных систем, что может приводить к задержкам, сбоям, или даже полной невозможности функционирования.
В конечном итоге все эти проблемы будет решать сервис-провайдер, причем на регулярной основе. Избежать этого можно лишь одним способом – с самого начала не допустить разведения «зоопарка», поставив клиентов в условия выбора между несколькими протестированными специализированными защитными решениями для виртуальных сред.
Между агентом и его отсутствием
Ключевое преимущество систем безопасности для виртуализации, подобных Kaspersky Security for Virtualization, кроется в том, что движок и антивирусные базы вынесены на отдельную виртуальную машину (Security Virtual Appliance, SVA), которая и обеспечивает защиту всех машин, запущенных на гипервизоре.
Преимущества такого решения очевидны: защитой сотен машин может заниматься единственный антивирусный движок, запущенный на SVA, который постоянно работает и оперативно обновляется. Все машины получают высокий уровень защищенности, а график сканирования виртуальных машин выстроен так, что исключает чрезмерную нагрузку на среду.
При этом у защитного ПО для виртуализации есть два существенно различающихся подхода к защите: агентский (с легким агентом) и безагентский. Заказчик волен выбрать наиболее для него подходящий подход, или даже сочетать их.
Защитное решение без агента, все компоненты которого работают исключительно на SVA, имеет ряд серьезных ограничений. Предназначенное для работы только в средах на базе продуктов VMware, оно не способно работать с процессами в памяти виртуальных машин, обеспечивая лишь проверку файловой системы и входящего потока сетевых данных. То есть фактически оно может лишь сканировать файлы и блокировать сетевые атаки. В некоторых случаях этого вполне достаточно, при этом безагентское решение позволяет практически моментально обеспечить защиту виртуальных машин сразу после их запуска. На сами клиентские машины ничего устанавливать не нужно.
Безагентский подход к безопасности виртуальных сред на примере решения «Лаборатории Касперского» Kaspersky Security for Virtualization | Agentless
Система безопасности с легким агентом обеспечивает весь спектр защитных технологий (работа с процессами в памяти, контроль приложений, веб-антивирус и т.д.), не тратя большого количества ресурсов благодаря размещению сканирующего движка и баз на SVA. Уровень защиты, обеспечиваемый таким решением, не уступает решениям класса endpoint protection, при этом оно оптимизировано и протестировано под виртуальные среды. Однако на каждую виртуальную машину требуется установить агент, который обеспечивает всесторонний доступ защитного решения к системе.
Это можно рассматривать как неудобство, но многие сценарии виртуализации позволяют использовать шаблоны виртуальных машин; в этом случае агент может быть предварительно установлен в шаблон, так что каждая, развернутая из него виртуальная машина, будет содержать агента, и получит мгновенную защиту сразу после запуска.
Подход к безопасности виртуальных сред с использованием легкого агента на примере решения «Лаборатории Касперского» Kaspersky Security for Virtualization | Light Agent
Выбор между этими двумя видами решений зависит от сопутствующих обстоятельств.
Нередко провайдер не может гарантировать наличие защитного решения у клиента, что создает потенциальную дыру в защите ЦОД. При этом клиент может по своим причинам не разрешать устанавливать на свои машины какое-либо стороннее программное обеспечение. В этом случае оптимальным выбором будет безагентское защитное решение.
В других случаях провайдер и клиент с самого начала договариваются о том, что на виртуальных машинах будет установлено защитное решение из списка протестированных и одобренных провайдером. Тут лучше всего использовать специализированные системы безопасности для защиты виртуальных сред с легким агентом, это позволит обеспечить максимальный уровень защиты при минимуме попутных проблем.
Особняком стоит случай с виртуальной десктопной инфраструктурой (VDI), размещенной в дата-центре. Когда виртуальные машины используются в качестве рабочих станций, каждая из них подвергается множеству угроз во время повседневной работы. Сотрудник может «подцепить» зловред, зайдя на опасный сайт, ему может прийти письмо с вирусным вложением, наконец, нередки случаи распространения вредоносных программ через съемные носители, которые так часто ходят из рук в руки.
При таком спектре возможных векторов заражения безагентского решения будет недостаточно: в силу его ограниченной функциональности риск заражения значительно выше. При этом, если заражение в принципе будет выявлено, это, скорее всего, произойдет слишком поздно, чтобы предотвратить ущерб. С другой стороны, система безопасности с легким агентом способна защитить от гораздо большего набора угроз, проверяя запускаемые программы, превентивно не допуская пользователя на опасные веб-сайты и контролируя запущенные в системе процессы.
Есть и третий, наиболее ресурсоемкий вариант для защиты виртуальных машин. Можно использовать «обычное» защитное решение класса endpoint protection, с полным агентом. Это будет приемлемым выходом, если нет доступа к гипервизору (например, в публичных облаках, таких как Amazon или Azure), или если в ЦОД используется не очень широко распространенный гипервизор, с которым специализированные защитные решения не умеют работать. И, наконец, «обычные» системы безопасности выпускаются под более широкий спектр операционных систем – к примеру, с их помощью можно защитить виртуальные машины, работающие под управлением Mac OS.
При этом следует учитывать, что система безопасности, не предназначенная для работы в виртуальной среде, может быть не вполне совместима с определенными виртуальными машинами и будет работать на них некорректно, либо не работать вообще. Решение проблем такого рода может потребовать значительных временных затрат.
Забота о хранилищах
Заражение сетевых хранилищ ставит под угрозу весь дата-центр, и системы хранения данных как никто нуждаются в антивирусной обороне. В противном случае возможна эпидемия, особенно если не все машины, размещенные в ЦОД, подключены к защитному решению для виртуальных сред.
СХД типа SAN (Storage Area Network) защищаются очень просто – установкой системы безопасности на сервер. Тут нет разницы с защитой любого другого сервера, в этом случае применяется серверное решение, например, Kaspersky Security for File Servers. Иная ситуация с NAS (Network Attached Storage), непосредственный доступ к которым имеют все машины в сети. Тут требуется специализированное решение для NAS.
Типы систем хранения данных в сети
Данные, хранящиеся на NAS, нужно защищать до того, как их получат клиентские машины, а значит, требуется поддержка со стороны самого NAS. Благо большинство NAS умеют работать с внешними защитными решениями и поддерживают для этого ряд специальных протоколов.
Принцип работы решения по защите NAS
При запросе файла клиентом с NAS (1) хранилище отправляет его на сервер системы безопасности (2). Проверив файл, сервер сообщает хранилищу результат (3). Основываясь на вердикте антивируса, NAS отдает файл клиенту либо запрещает к нему доступ (4). Для большей надежности в сети может присутствовать более одного защитного сервера. В нормальном режиме работы СХД будет балансировать нагрузку между ними.
Заключение
При защите виртуализированных центров обработки данных никакой «серебряной пули», идеально решающей все задачи, нет, и быть не может. Возможен лишь оптимальный подбор системы безопасности на основе взвешенной оценки множества факторов.
Безагентское решение больше подойдет для защиты серверов баз данных, веб-серверов в интранете и машин, на которые по каким-то причинам нежелательно устанавливать программное обеспечение, не входящее в определенный набор приложений.
Если же клиент имеет возможность выбора из нескольких одобренных провайдером специализированных защитных решений, лучшим выбором будет решение с легким агентом. Оно подойдет для защиты веб-серверов, виртуальных рабочих станций, серверов обработки конфиденциальных данных.
В защите виртуальных сред как нигде нужна гибкость, и «Лаборатория Касперского» поставляет оба решения – и безагентское, и с легким агентом – под одной лицензией. Это дает заказчику выбор между этими двумя вариантами и возможность при необходимости их сочетать, к примеру, в средах с несколькими различными гипервизорами или для более эффективного решения разных задач. Более подробную информацию см. здесь.
Главное – позаботиться о защите заранее, до появления множества неприятных и дорогостоящих проблем.
Разгоняем «зоопарк»
vladimir tseplyaev
спасибо за нужную и интересною информацию