Подписаться
Читать в телеграм
Наблюдения
Прошедший 2012-й год показал, что компании в России начали вести реальную работу в области обеспечения защиты своих виртуальных сред (ВС), инициировать первые проекты, определять для себя риски, связанные со свершившимся, практически повсеместным переходом к использованию технологий виртуализации. Принимая во внимание усилия, прилагаемые при построении систем защиты виртуальных сред, странно видеть, когда создаваемая конструкция обеспечивает безопасность лишь с одной стороны, выборочно закрывая очевидные проблемы. Так, одни считают – нужно срочно решать проблемы «9-ти утра» и бороться с антивирусным штормом, другие – обязательно обеспечить контроль управления виртуальной средой, и в результате занимаются только этим.
Все же защита ВС предполагает правильный относительно информационной безопасности дизайн самой инфраструктуры. Он должен не только обеспечивать ее масштабируемость, достаточную плотность размещения виртуальных машин на хост-серверах, отказо- и по необходимости катастрофоустойчивость, но и позволять с точки зрения ИБ построить правильную сетевую топологию, разместить в нужном месте системы хранения, обеспечить достаточную пропускную способность и доступность средств управления в рамках организационных полномочий пользователей. По своей сути ВС адаптирована для преодоления проблем доступности благодаря взаимозаменяемости серверов виртуализации и возможности перемещения виртуальных машин (ВМ) – непосредственных обработчиков конфиденциальной информации – между ними. И здесь на поверхность всплывает пласт угроз нарушения конфиденциальности и целостности данных в результате «соседства» виртуальных машин в рамках одного физического сервера, а также наличия связей между серверами виртуализации и, как правило, единым сервером управления.
Проблемы защиты
Может ли компания доверять права гиперпользователя одному человеку, если это позволяет ему получать доступ к любой информации в ВС? Действительно ли возможно по журналам доступа виртуальной среды определить, какие действия и кем совершались? Можно ли доверять гипервизору как средству разграничения доступа и изоляции виртуальных машин, допускающему использование одних и тех же участков памяти между разными ВМ, не очищая их? Стоит ли обрабатывать информацию разных категорий на одном и том же оборудовании в таких условиях? Эффективно ли обеспечивается антивирусная защита, когда на одном физическом сервере одновременно запущены десятки антивирусных процессов в разных виртуальных машинах? Необходимо ли обеспечивать сетевой контроль между ВМ внутри среды виртуализации? Нужно ли покупать лицензии на каждую виртуальную машину, или дешевле построить защиту на уровне платформы? Эти и другие вопросы стоит задавать себе в ходе построения эффективной защиты, определения внутренних и внешних нарушителей, потенциальных угроз и соответствующих мер безопасности. Практический опыт работы по построению систем защиты ВС позволяет правильно подбирать такие вопросы, а затем оценивать возможные угрозы.
Частные бизнес-примеры
В компаниях, в которых к ВС имеют доступ разные группы лиц – не только администраторы виртуальной инфраструктуры, но и разработчики, тестировщики, прикладные администраторы, сотрудники внешних организаций (поддержка или аутсорсинг), – требуется принимать дополнительные меры безопасности. В этом случае следует подумать об усилении контроля доступа к виртуальной среде и регистрации событий. Так как роль гиперпользователя фактически дает администратору возможности преодоления любых средств защиты в операционных системах ВМ, для отдела, отвечающего за обеспечение информационной безопасности, особенно важной становится подотчетность работы всех пользователей с фиксацией событий ИБ. Также необходима возможность контроля действий пользователей, не обладающих административными правами, но имеющими доступ к интерфейсам управления ВС. Зачастую среда виртуализации не выполняет регистрации событий в достаточной мере с точки зрения ИБ. Так, в среде VMware подключение к виртуальной машине сетевого адаптера из другой сети будет зафиксировано как «Updating Computer Configuration». Т.е. фактически пользователь, подключив 2 сетевых адаптера к 2 разным сетям, может создать маршрутизатор между ними в обход корпоративных маршрутизаторов или межсетевых экранов. Это позволит пренебречь любыми правилами фильтрации между сетями, а действия нарушителя будут зафиксированы таким образом, что никто не сможет восстановить последовательность реально проделанных им операций.
Другим примером является использование ВС для развертывания Internet-faced приложений параллельно с исполнением внутренних корпоративных ресурсов в этой же среде. Так как зачастую оперативная память отдается виртуальным машинам динамически (при этом часть реальной физической памяти еще и разделяется), а гипервизор, как и любое ПО, содержит ошибки, что допускает возможность эксплуатации уязвимости в нем, стоит использовать программные средства для обеспечения привязки ВМ к серверам виртуализации таким образом, чтобы они не пересекались по категориям. Другими словами, серверы демилитаризованной зоны и внутренние виртуальные серверы не должны исполняться на одних и тех же физических серверах. Это позволит исключить возможность получения внешним интернет-нарушителем доступа через ВС к корпоративным ресурсам, не входящим в Internet-faced зону в рамках той же среды виртуализации.
Частой проблемой также является необходимость оптимизировать нагрузку на ВС из-за того, что многие системы защиты используют агент-серверный подход (в виртуальной среде это приводит к неэффективному использованию аппаратных ресурсов). В таком случае мы рекомендуем реализовывать механизмы защиты с применением безагентских технологий.
Подход к защите
Итак, первостепенной задачей является оценка рисков, которые связаны с конкретной реализацией виртуальной среды. Рассмотрев архитектуру системы, особенности работы персонала с ней и ее задачи, можно сформировать конкретный перечень рисков, которые необходимо минимизировать либо принять. При этом нужно помнить, что на безопасность влияет огромное количество компонентов ВС: гипервизоры, средство управления ими, служба каталогов, обеспечивающая аутентификацию в виртуальной среде, средство резервного копирования, имеющее привилегированный доступ к ВС, средство мониторинга, виртуальные машины и ПО в них, виртуальные коммутаторы, виртуальные устройства (virtual appliance), плагины и настройки для среды управления, системы хранения данных и сетевые устройства. В ходе анализа необходимо учитывать влияние этих компонентов друг на друга и возможности нарушителей по преодолению механизмов их защиты.
Как результат, формируются рекомендации по архитектуре системы виртуализации с учетом требований ИБ. В силу того, что виртуальная среда динамична и происходит размывание границ нахождения информации, следует ограничивать обработку данных разных категорий, смешение которых недопустимо без наличия доверенных механизмов защиты, встроенных в сам гипервизор, на одном и том же оборудовании. Отметим, что организационных мер в случае доступа нескольких типов пользователей, в том числе если их должностные инструкции не предполагают административных полномочий, зачастую недостаточно. Безусловно, не стоит забывать и о физическом ограничении доступа к серверам виртуализации, ведь обладая им, можно получить привилегии гиперпользователя на каждом отдельно взятом сервере. Желательно при реализации системы закладывать механизмы защиты, которые смогут обеспечивать взаимоконтроль за счет их изоляции друг от друга. Так, например, функции контроля сетевого трафика и журналов аудита не должны быть размещены на одной ВМ и в рамках одного гипервизора, иначе журналу аудита придется доверять в меньшей степени. Т.е. средство агрегации и анализа событий должно быть отделено от средства контроля сетевых потоков в ВС. Отдельно стоит отметить рассмотрение процедур усиления контроля доступа к гипервизору.
Наша компания видит следующие риски, связанные с защитой виртуальных сред, характерных для России:
- неучастие специалистов службы ИБ в проектах по созданию виртуальных сред;
- отсутствие у них квалификации в области ВС для участия в проектах, связанных с ними;
- компрометация компонентов среды виртуализации может приводить к компрометации всех информационных ресурсов, обрабатываемой в ней;
- неподконтрольность внутренних взаимодействий в ВС между виртуальными машинами и возможность обхода внешних физических средств межсетевого экранирования;
- обработка информации разных категорий на одном и том же физическом сервере;
- отсутствие разделения полномочий управления ВС между разными типами администраторов (системными, сетевыми, администраторами ИБ) и возложение всех обязанностей на одного человека или группу лиц.
По завершении анализа и выявления способов снижения обнаруженных рисков в случае использования технических вариантов решения рекомендуется строить систему защиты по сервисному принципу. Согласно этой концепции ВМ защищается не агентами внутри нее, а выделенной виртуальной машиной защиты с использованием возможностей виртуальной среды. Таким образом, защита становится прозрачной как для пользователя ВМ, так и для потенциального нарушителя. Теоретически противодействовать ей извне сложнее, так как она функционирует в недоступных для злоумышленника областях памяти. Отдельно стоит отметить: наш опыт обеспечения защиты ВС показывает, что ряд типов рисков характерен почти для всех категорий компаний. Так, неучастие службы ИБ в создании виртуальных сред приводит как к организационным конфликтам (например, сетевые администраторы не контролируют сеть в ВС, а ограничиваются предоставлением физического соединения), так и к техническим проблемам.
В результате нет возможности не то что провести расследование по имеющимся журналам событий, но и просто предусмотреть варианты обеспечения контроля доступа к виртуальной среде, обнаружения и предотвращения атак, а иногда и эффективной антивирусной защиты. Проанализировав типовые проблемы и сопоставив особенности реализации виртуальной инфраструктуры, можно выявить и соответствующим образом обработать характерные для нее риски.
Таким образом, риск-ориентированный подход к защите ВС с обеспечением функций защиты как сервисов может рассматриваться в качестве эталонного: следование ему обеспечит безопасность на должном уровне. Искусство создания подобной системы безопасности будет заключаться в том, чтобы реализовать ее максимально просто и эффективно, так что после ее внедрения может быть заметен рост производительности платформы по сравнению с воплощением классического подхода к защите с использованием агентов.
