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

При этом термин «облако» порой трактуется настолько широко, что может предполагать самые разнообразные способы организации ИТ-систем. Например, Алексей Андрияшин, консультант по безопасности Check Point Software Technologies, отмечает, что за эпитетом «облачный» может скрываться практически любой проект, в котором используются распределенные вычисления: «Центры обработки данных, которые строятся по принципам отказоустойчивости, тоже можно отнести к облакам». Компания может и не планировать построить облако, но заниматься, например, обеспечением отказоустойчивости приложений или распределенными вычислениями в нескольких собственных ЦОД, однако она должна соблюдать общие «облачные» законы. И одним из таких законов являются правила безопасности.

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

Модель угроз

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

Клиенты облаков

Доступ к облачным ресурсам происходит с клиентских машин, на которых установлено специальное программное обеспечение для доступа или универсальный клиент — браузер. На рабочем месте могут быть установлены и другие программы, которые могут вмешиваться в работу клиента, перехватывая передачу информации или навязывая собственное поведение браузеру (например, посредством сценариев JavaScript). Таким образом, первым уязвимым местом облачной инфраструктуры, как это ни странно, является клиент.

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

Впрочем, сейчас «кража личности» администратора в основном происходит на клиентском компьютере с помощью троянских программ.

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

Сетевая инфраструктура

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

Элементы облачной инфраструктуры, каждый из которых подвержен собственным угрозам и рискам

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

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

Впрочем, уже начали появляться сервисы для сетевой защиты облачных инфраструктур. Например, компания Novell выпустила на рынок сервис Cloud Security Service, который включает в себя набор инструментов для организации защиты облачной инфраструктуры. Кирилл Степанов, технический директор представительства компании, так прокомментировал появление этого сервиса: «Проблема безопасности при работе с облаками состоит в необходимости обеспечить контроль доступа пользователей корпоративной сети к вычислительным ресурсам облака и строгое соблюдение регламентов при создании ресурсов в облаке и работе с ними. Это особенно важно, если облако внешнее».

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

Среда исполнения

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

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

Тем не менее для защиты облачной среды исполнения следует в первую очередь позаботиться о классической защите узлов облака с помощью межсетевых экранов, антивирусных программ, систем управления аутентификационной информацией, сканеров безопасности и других инструментов. А уже затем обеспечивать безопасность виртуальных серверов с помощью специализированных продуктов для защиты виртуальных сред. Например, компания Check Point выпустила специальную версию межсетевого экрана Security Gateway Virtual Edition, которая может взаимодействовать с виртуальными средами VMware. Для провайдеров облачных сервисов нужно также иметь защищенную биллинговую систему, которая строго контролировала бы потраченные клиентами вычислительные ресурсы и не допускала злоупотребления и взаимовлияния систем различных заказчиков. Также логично использовать специальные фрод-машины, способные обнаруживать мошенничество и нарушения политики безопасности при пользовании виртуальных машин.

Хранение данных

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

Антон Салов, руководитель департамента корпоративных интернет-решений SoftCloud, так описал собственный опыт построения систем защиты облачных инфраструктур: «Все средства по защите информации наших клиентов я бы разделил на два блока: средства, направленные на предотвращение потерь данных, и системы предотвращения утечек информации. К первым мы относим совокупность высококлассной серверной архитектуры, распределенной системы ЦОД и системы регулярных бэкапов на специальные независимые системы хранения, а ко вторым — сочетание мер качественной изоляции виртуальных ресурсов каждого клиента со стороны производителя платформы, компании Parallels, c собственными мерами защиты».

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

***

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

Недостающее звено безопасности облака

Ни один поставщик общедоступной облачной инфраструктуры в качестве сервиса не предлагает заказчикам сервиса протоколирования событий

Облачные решения, в особенности общедоступная облачная инфраструктура, предоставляемая в качестве сервиса (Infrastructure as aService, IaaS), пока не стали привычными. Что же мешает внедрению IaaS? Одна из главных проблем — безопасность.

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

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

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

Андреас Антонопулос
Network World, США

Поделитесь материалом с коллегами и друзьями