Вопросы безопасности для облачных вычислений (часть 1) — платформа виртуализации

• Вопросы безопасности для облачных вычислений (часть 2)
• Вопросы безопасности для облачных вычислений (часть 5) — быстрая эластичность
• Соображения безопасности для облачных вычислений (часть 6) — измеряемые услуги

В предыдущей статье Microsoft Private Cloud: Обзор безопасности гипервизора мы говорили о безопасности гипервизора в частном облаке Microsoft. Но облачные вычисления — как общедоступные, так и частные — это сложная тема, и в этой серии мы собираемся углубиться в некоторые из этих сложностей. Среда облачных вычислений предлагает множество преимуществ. Однако вы должны понимать, что, хотя гипервизор является важным компонентом, облачные вычисления — это больше, чем просто виртуализация. Помните, что согласно NIST облако имеет следующие характеристики:

• Самообслуживание
• Широкий доступ к сети
• Эластичность
• Возвратный платеж
• Объединение ресурсов

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

Однако прежде чем вы сможете разумно подумать о проблемах безопасности, связанных с виртуализацией и облачными вычислениями, вы должны понять, как виртуализация используется в облачной среде. Виртуальная машина (обычно называемая «ВМ») обычно представляет собой серийный экземпляр операционной системы, который содержится в настроенном и работающем образе ОС. Образ ОС представляет собой моментальный снимок сервера и включает пространство для хранения виртуального диска. Вам нужна какая-то технология для поддержки виртуальных машин, и это делается с помощью гипервизора. Гипервизор представляет виртуальной машине аппаратную среду, с которой она может работать.

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

• Гипервизоры типа 1 работают непосредственно на голом оборудовании. Гостевые операционные системы работают поверх гипервизора. Примеры включают Microsoft Hyper-Vand VMware ESX.
• Гипервизоры типа 2 также называются «размещенными гипервизорами», где гипервизор работает как программа в хост-ОС. Виртуальные машины работают поверх гипервизора типа 2. Примеры гипервизоров типа 2 включают Oracle VirtualBox, Parallels, Virtual PC, VMware Fusion, VMware Server, Xen и XenServer.

Подробное обсуждение того, как работает виртуализация, выходит за рамки этой статьи. На веб-сайтах Microsoft и VMware есть ряд полезных ресурсов, где вы можете узнать больше о платформах виртуализации. Здесь мы сосредоточимся на некоторых важных проблемах безопасности, связанных с гипервизорами, и эти проблемы безопасности становятся еще более важными, когда мы думаем об использовании виртуализации в облаке. Давайте посмотрим на некоторые из них:

• Первое соображение заключается в том, что когда вы создаете новую виртуальную машину и включаете ее, вы добавляете новую операционную систему в производственную среду. Независимо от операционной системы, каждая работающая операционная система имеет свои собственные риски безопасности. Это означает, что вам нужно быть очень осторожным, чтобы каждая операционная система, работающая в вашей виртуальной среде, исправлялась, поддерживалась и контролировалась в соответствии с ее предполагаемым использованием, как и любая невиртуальная операционная система в вашей сети.
• Кроме того, вам необходимо знать, что обычные системы обнаружения вторжений в сеть, которые сегодня используются в корпоративных сетях, не обязательно будут работать так же хорошо в виртуализированной инфраструктуре. Это особенно актуально, когда трафик, который вы хотите отслеживать, проходит между виртуальными машинами, размещенными на одном виртуальном сервере или члене кластера или массива виртуальных серверов. В результате методы, используемые для мониторинга трафика между виртуальными машинами, должны будут использовать альтернативные методы или полностью отказаться от сетевой системы обнаружения вторжений и перенести обнаружение обратно на хост.
• Еще одним важным моментом является то, что когда вы перемещаете виртуальные машины с одного физического сервера на другой, например, когда вы используете динамическое планирование ресурсов или PRO-мониторинг сети, системы могут не знать, что эти виртуальные машины и запущенные ими службы были перемещены, и, таким образом, могут генерировать ложные срабатывания (ложные срабатывания). Ситуация еще более проблематична, когда вы используете кластеризацию в сочетании с виртуализацией.
• Наконец, виртуализация требует, чтобы вы применяли различные методы управления во всем решении для предоставляемых вами услуг. Необходимо пересмотреть такие вопросы, как управление требуемой конфигурацией (DCM), мобильность виртуальных машин, а также планирование и управление емкостью. Кроме того, вы можете столкнуться с проблемами с выделением ресурсов, что может привести к значительному замедлению работы всей инфраструктуры. По этим причинам вам необходимо уделять особое внимание управлению производительностью при запуске приложений и служб в виртуализированной среде.

Безопасность платформы облачных вычислений и виртуализации

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

В традиционном центре обработки данных автоматизация обычно не является таким важным компонентом, если только количество развертываемых клиентских или серверных операционных систем и административные накладные расходы не будут огромными без какого-либо метода автоматизации. Как правило, в современных центрах обработки данных на основе локальной сети настройка новых физических серверов включает по крайней мере некоторые действия, выполняемые администратором вручную. Напротив, в облачной среде ОС должна быть высокоавтоматизированной, чтобы поддерживать несколько ключевых принципов самих облачных вычислений.

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

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

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

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

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

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

• Операционная система может остановиться или выйти из строя до того, как ресурсы будут обнулены.
• Не все операционные системы управляют клиринговыми данными одинаково; некоторые могут очистить его при выпуске, тогда как другие могут сделать это при распределении.

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

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

Как насчет сетевых атак между гостями, размещенными на одном сервере в массиве или кластере виртуальных серверов? Сможете ли вы их обнаружить? Проблема в том, что если вы не видите трафик от каждой виртуальной машины, вы не можете подтвердить, что трафик между виртуальными машинами невозможен, даже если вы установили эти элементы управления безопасностью. Есть несколько возможных решений, которые вы можете использовать. Во-первых, пользователь виртуальной машины может просто вызвать фильтрацию трафика или брандмауэр на основе ОС, а во-вторых, вы можете развернуть новые виртуальные экземпляры традиционных решений для управления сетью и мониторинга, таких как Cisco 1000V.

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

Большинство гипервизоров корпоративного уровня (например, Microsoft Hyper-V) имеют виртуальные коммутаторы (а также поддержку виртуальных брандмауэров), которые расположены между физическими сетевыми адаптерами сервера и виртуальными сетевыми адаптерами, используемыми виртуальными машинами. Облачная структура должна адаптироваться к изменениям, когда они вносятся в расположение виртуальных машин, и включать или, по крайней мере, разрешать допустимые и недопустимые пути связи между ними.

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

Чтобы это работало, нам нужна поддержка VLAN за пределами основной физической сетевой инфраструктуры, чтобы перенести ее на виртуальные серверы. Хорошей новостью является то, что корпоративные решения, такие как Hyper-V и ESX, поддерживают это уже сегодня. Однако решение также должно масштабировать возможности VLAN для поддержки больших динамических облаков. Опять же, с введением System Center Virtual Machine Manager 2012 у вас будет эта поддержка, и ее можно будет связать с вашими текущими системами управления сетью и выбором гипервизора (SCVMM поддерживает Hyper-V, ESX и Xen).

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

• Вопросы безопасности для облачных вычислений (часть 2)
• Вопросы безопасности для облачных вычислений (часть 5) — быстрая эластичность
• Соображения безопасности для облачных вычислений (часть 6) — измеряемые услуги