Джон Хоуи (jhowie@microsoft.com) — менеджер центра Microsoft Security Center of Excellence. Имеет сертификаты CISSP, CISM и CISA

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

У публичного «облака» много достоинств, в том числе повышенный динамизм информационных технологий, сокращенное время развертывания новых продуктов и служб, доступ к новейшим технологиям, отсутствующий внутри компании. Можно даже найти пути обхода ограничений, установленных ИТ-подразделениями, в частности, на размер вложенных файлов электронной почты или типы файлов, отправляемых и принимаемых по электронной почте. По этим причинам многие ИТ-подразделения рассматривают вопрос о развертывании частного «облака», к которому подразделения могут обращаться вместо публичного. Примеры: банк State Street, руководство которого надеется, сэкономив средства, повысить эффективность труда и безопасность данных клиентов; инженерная и строительная компания Bechtel и группа химических компаний Sinochem.

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

Обзор частного «облака»

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

Справедливости ради надо сказать, что большинство существующих или развертываемых сегодня частных «облаков» находится внутри компании, предоставляет инфраструктуру как услугу (IaaS) и использует технологию виртуализации для формирования пула ресурсов, распределяемого по мере необходимости. Однако в действительности частное «облако» — просто «облако», предоставленное компании в исключительное пользование. Частное «облако» может располагаться в компании или вне ее пределов, и несколько авторитетных поставщиков частного «облака» используют свои центры обработки данных для размещения частных «облаков» клиентов. Некоторые из этих поставщиков частного «облака» (например, Microsoft) предоставляют также услуги публичного «облака». Частное «облако» не ограничивается инфраструктурой как услугой. Многие могут предоставляют платформу как услугу (PaaS) и программное обеспечение как услугу (SaaS). Виртуализация, особенно для «облаков» SaaS — не обязательное условие. Чтобы лучше понять «облака», в том числе частные, полезно познакомиться с публикацией Special Publication 800-145 Национального института стандартов и технологии (NIST).

Угрозы в «облаках»

В марте 2010 г. организация Cloud Security Alliance (CSA) опубликовала исследовательский отчет Top Threats to Cloud Computing. Документ был выпущен уже несколько лет назад и сейчас перерабатывается, но содержащаяся в нем информация остается актуальной. Каждая из семи угроз, названных в отчете, применима к частным «облакам», размещаемым как внутри, так и вне предприятия. Все семь применимы к «облакам» IaaS, шесть — к PaaS и пять — к SaaS. Это следующие угрозы (в произвольном порядке):

* злоупотребления и неправомерное использование «облака»;

* уязвимые API-интерфейсы;

* злоумышленники внутри компании;

* уязвимость совместно используемых технологий;

* потери и утечки данных;

* перехват (hijacking) учетной записи, службы и трафика;

* неизвестный профиль риска.

CSA опубликовала рекомендации и описала инструменты, с помощью которых потребители и поставщики «облачных» услуг смогут противостоять угрозам. Инструменты можно бесплатно получить на сайте CSA.

Однако перечисленные угрозы далеко не единственные. По опыту работы с частными «облаками» можно выделить несколько областей, требующих особого внимания компаний. Как отмечалось выше, в большинстве случаев частное «облако» предоставляет IaaS и использует виртуализацию для предоставления виртуальных машин подразделениям и пользователям внутри компании по мере необходимости. И Microsoft, и Vmware предоставляют необходимую технологию для построения частных «облаков» с нуля. Превосходные открытые инструменты, такие как OpenStack, совместимы с различными гипервизорами, в том числе Citrix Xen и Virtual Machine (KVM) на основе ядра Linux, а также гипервизорными технологиями Microsoft и Vmware. По этой причине в оставшейся части статьи речь пойдет об опасностях для IaaS.

Опасность № 1: забытые виртуальные машины

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

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

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

Опасность № 2: раскрытие конфиденциальных данных

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

Существует много инструментов для подключения VHD через букву диска или в виде точки подключения, если он не используется. С помощью этих инструментов взломщик может получить неограниченный доступ к данным на VHD, в том числе конфиденциальным. Но злоумышленники — не единственные, кто обращается к виртуальным жестким дискам в поисках конфиденциальной информации, ценной для компаний. Благодаря частным «облакам» и виртуализации разработчикам не составляет труда обратиться к производственным серверам, которые, в сущности, представляют собой виртуальные серверы, в целях тестирования и отладки, просто копируя файлы конфигурации и VHD в свою среду разработки. Существует много ограничений для доступа к различным типам данных, и, возможно, компании придется оповестить власти и даже клиентов о непреднамеренном доступе разработчиков к данным. Следствием такого раскрытия могут стать штрафы и другие наказания, а также потеря доверия клиентов и партнеров. По этой причине необходимо отслеживать и контролировать доступ к файлам конфигурации и VHD, составляющим виртуальные машины. Несмотря на потери производительности, следует шифровать конфиденциальные данные, сохраняемые в виртуальной машине, сохранив ключи шифрования отдельно, например в сетевом устройстве шифрования (в аппаратном модуле безопасности — HSM). Если нельзя шифровать данные, сохраненные внутри виртуальной машины (например, при запуске готовых коммерческих программ, не обеспечивающих шифрование в виртуальной машине), возможно, удастся шифровать файлы конфигурации и VHD виртуальных машин, в зависимости от использованной технологии виртуализации. И наконец, в среде размещения и в библиотеке следует использовать средства логического контроля доступа, такие как собственные ACL (DACL), для ограничения доступа к неиспользуемым файлам виртуальной машины.

Опасность № 3: отсутствие управления сетевым доступом

Третья проблема, которая часто встречается в частных «облаках», особенно тех из них, где виртуальные машины можно перемещать между узлами, обеспечивая обслуживание серверов или определенный уровень бесперебойной работы в случае отказа сервера, заключается в том, что сети, к которым подключены машины, являются сравнительно плоскими (например, используют адреса RFC 1918 Class A в диапазоне 10.x.x.x или адреса Class B в диапазонах 172.16.x.x — 172.31.x.x). Используя плоские сети, проще строить и управлять физическими сетями, соединяющими виртуальные машины. Кроме того, в этих сетях легче обеспечить связь одной виртуальной машины с другой, физическим компьютером или Интернетом, независимо от физического узла, на котором функционирует виртуальная машина.

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

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

Опасность № 4: недостаток средств защиты от вредоносных программ

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

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

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

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

Опасность № 5: децентрализация

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

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

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

Баланс преимуществ и рисков

Частное «облако» может принести множество преимуществ, в том числе снизить затраты, повысить динамизм бизнеса, расширить возможности отдельных бизнес-подразделений и лучше согласовать нужды ИТ и бизнеса. Компаниям, обдумывающим переход к частному «облаку» — и тем, кто уже развернул его — следует изучить руководства CSA и поставщиков программного обеспечения, чьи продукты и инструменты используются для создания частного «облака». Полезны также ресурсы, предоставляемые поставщиками публичного «облака», такими как Google, Amazon, Microsoft, HP, Verizon и Rackspace. Эти ресурсы предназначены в первую очередь для решения проблем конфиденциальности и безопасности потенциальных клиентов, но содержат и сведения о том, как поставщики строили собственные «облачные» инфраструктуры и защищали данные клиентов.