Безопасность при использовании облачных сервисов. Как избежать уязвимостей и угроз в облачной среде

Что следует знать вашей организации о безопасности в облачной среде

Общие сведения

Один из ведущих аналитиков компании Gartner назвал облачные вычисления «фразой дня». Любой, кто хоть сколько-нибудь времени занимается информационными технологиями (ИТ), знает, что эта фраза, по-видимому, будет актуальна и в ближайшем будущем. Действительно, по прогнозам компании Gartner, объем рынка облачных вычислений к концу 2013 года достигнет 150 миллиардов долларов. Компания Merrill Lynch также прогнозирует взрывной рост объема рынка до 160 миллиардов долларов к 2013 году.

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

Рисунок 1. Схема облачной среды

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

Учитывая все эти возможности сокращения затрат, трудно понять, почему организации порой с такой неохотой перемещают в облако свои данные, программное обеспечение и другие сервисы, - но лишь до тех пор, пока вы не вспомните о рисках с точки зрения безопасности, с которыми сопряжено такое перемещение. Согласно результатам большинства опросов, именно безопасность является основной причиной, по которой руководители по ИТ не решаются начать движение в сторону облачных решений. Один из недавних опросов на портале LinkedIn показал, что у 54% из 7053 респондентов проблема безопасности вызывает наибольшую озабоченность, когда речь заходит о миграции в облако.

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

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

Совместно используемые технологические ресурсы

Облачные среды можно разделить на четыре категории в соответствии с четырьмя моделями развертывания, перечисленными и описанными в .

Таблица 1. Модели развертывания облачных сред

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

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

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

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

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

Потеря и утечка данных

В своей статье «Data Leakage Prevention and Cloud Computing» («Предотвращение утечки данных и облачные вычисления») компания KPMG LLP утверждает: «Как только данные оказываются в общедоступном облаке, развернутые в вашей организации средства предотвращения утечки данных (DLP) обесцениваются, поскольку уже не могут помочь в защите конфиденциальности этих данных. При этом ваша организация не имеет возможности прямого контроля над конфиденциальностью своих данных в общедоступном облаке ни в модели предоставления услуг «программное обеспечение как сервис» (SaaS), ни в модели предоставления услуг «платформа как сервис (PaaS)». Ссылка на полный текст статьи приведена в разделе .

Что можно предпринять для предотвращения утечки данных в облаке в ситуации, когда закон США от 1996 года о преемственности и подотчетности медицинского страхования (HIPAA) и стандарт защиты информации в индустрии платежных карт (PCI DSS) требуют от организаций серьезного подхода к обеспечению защиты данных?

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

Между тем ключом к успеху в предотвращении утечки данных является «упрочнение» систем, которые хранят и транспортируют данные.

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

Еще одной мерой для того, чтобы ваша организация соответствовала требованиям стандарта PCI DSS, является наличие должным образом сконфигурированного межсетевого экрана Web-приложений для защиты последних от разнообразных атак. Прежде чем принимать решение в пользу какого-либо поставщика услуг SaaS, отдел ИТ вашей организации должен оценить имеющийся уровень защиты Web-приложений. Если это разрешено, следует провести испытание проникновением, чтобы проверить защиту от несанкционированного доступа всех используемых вашей компанией приложений.

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

Незащищенные интерфейсы API

Для того чтобы клиенты могли взаимодействовать с облачными сервисами, поставщики услуг используют интерфейсы прикладного программирования (API). Эти интерфейсы применяются для предоставления услуг, управления, оркестровки и мониторинга, поэтому основополагающая безопасность сервисов, предоставляемых в облаке, зависит от того, насколько хорошо защищены данные интерфейсы API.

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

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

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

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

Похищение и несанкционированное использование учетных записей

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

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

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

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

Угрозы со стороны инсайдеров

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

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

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

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

Заключение

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

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

Центр обработки данных (ЦОД) представляет собой совокупность серверов, размещенных на одной площадке с целью повышения эффективности и защищенности. Защита центров обработки данных представляет собой сетевую и физическую защиту, а также отказоустойчивость и надежное электропитание. В настоящее время на рынке представлен широкий спектр решений для защиты серверов и ЦОД от различных угроз. Их объединяет ориентированность на узкий спектр решаемых задач . Однако спектр этих задач подвергся некоторому расширению вследствии постепенного вытеснения классических аппаратных систем виртуальными платформами. К известным типам угроз (сетевые атаки, уязвимости в приложениях операционных систем, вредоносное программное обеспечение) добавились сложности, связанные с контролем среды (гипервизора), трафика между гостевыми машинами и разграничением прав доступа. Расширились внутренние вопросы и политики защиты ЦОД, требования внешних регуляторов. Работа современных ЦОД в ряде отраслей требует закрытия технических вопросов, а также вопросов связанных с их безопасностью. Финансовые институты (банки, процессинговые центры) подчинены ряду стандартов, выполнение которых заложено на уровне технических решений. Проникновение платформ виртуализации достигло того уровня, когда практически все компании, использующие эти системы, весьма серьезно занялись вопросами усиления безопасности в них. Отметим, что буквально год назад интерес был скорее теоретический .
В современных условиях становится все сложнее обеспечить защиту критически важных для бизнеса систем и приложений.
Появление виртуализации стало актуальной причиной масштабной миграции большинства систем на ВМ, однако решение задач обеспечения безопасности, связанных с эксплуатацией приложений в новой среде, требует особого подхода. Многие типы угроз достаточно изучены и для них разработаны средства защиты, однако их еще нужно адаптировать для использования в облаке.

Cуществующие угрозы облачных вычислений

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

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

1. Трудности при перемещении обычных серверов в вычислительное облако

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

2. Динамичность виртуальных машин

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

3. Уязвимости внутри виртуальной среды

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

4. Защита бездействующих виртуальных машин

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

5. Защита периметра и разграничение сети

При использовании облачных вычислений периметр сети размывается или исчезает. Это приводит к тому, что защита менее защищенной части сети определяет общий уровень защищенности. Для разграничения сегментов с разными уровнями доверия в облаке виртуальные машины должны сами обеспечивать себя защитой, перемещая сетевой периметр к самой виртуальной машине (Рис 1.). Корпоративный firewall - основной компонент для внедрения политики IT безопасности и разграничения сегментов сети, не в состоянии повлиять на серверы, размещенные в облачных средах.

Атаки на облака и решения по их устранению

1. Традиционные атаки на ПО

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

2. Функциональные атаки на элементы облака

Этот тип атак связан с многослойностью облака, общим принципом безопасности. В статье об опасности облаков было предложено следующее решение : Для защиты от функциональных атак для каждой части облака необходимо использовать следующие средства защиты: для прокси – эффективную защиту от DoS-атак, для веб-сервера - контроль целостности страниц, для сервера приложений - экран уровня приложений, для СУБД - защиту от SQL-инъекций, для системы хранения данных – правильные бэкапы (резервное копирование), разграничение доступа. В отдельности каждые из этих защитных механизмов уже созданы, но они не собраны вместе для комплексной защиты облака, поэтому задачу по интеграции их в единую систему нужно решать во время создания облака.

3. Атаки на клиента

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

4. Атаки на гипервизор

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

5. Атаки на системы управления

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

Решения по защите от угроз безопасности от компании Cloud Security Alliance (CSA)

Наиболее эффективные способы защиты в области безопасности облаков опубликовала организация Cloud Security Alliance (CSA) . Проанализировав опубликованную компанией информацию, были предложены следующие решения .

1. Сохранность данных. Шифрование

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

2. Защита данных при передаче

Зашифрованные данные при передаче должны быть доступны только после аутентификации. Данные не получится прочитать или сделать изменения, даже в случаи доступа через ненадежные узлы. Такие технологии достаточно известны, алгоритмы и надежные протоколы AES, TLS, IPsec давно используются провайдерами.

3. Аутентификация

Аутентификации - защита паролем. Для обеспечения более высокой надежности, часто прибегают к таким средствам, как токены и сертификаты. Для прозрачного взаимодействия провайдера с системой индетификациии при авторизации, также рекомендуется использовать LDAP (Lightweight Directory Access Protocol) и SAML (Security Assertion Markup Language).

4. Изоляция пользователей

Использование индивидуальной виртуальной машины и виртуальную сеть. Виртуальные сети должны быть развернуты с применением таких технологий, как VPN (Virtual Private Network), VLAN (Virtual Local Area Network) и VPLS (Virtual Private LAN Service). Часто провайдеры изолируют данные пользователей друг от друга за счет изменения данных кода в единой программной среде. Данный подход имеет риски, связанные с опасностью найти дыру в нестандартном коде, позволяющему получить доступ к данным. В случаи возможной ошибки в коде пользователь может получить данные другого. В последнее время такие инциденты часто имели место.

Заключение

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

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

«Несмотря на то что последние масштабные взломы происходили внутри ЦОД , традиционные системы безопасности по-прежнему фокусируются лишь на защите сетевого периметра и контроле прав доступа. При этом редко учитывается негативное влияние решений для защиты физической инфраструктуры на производительность виртуальных сред, - объяснил Вениамин Левцов , вице-президент по корпоративным продажам и развитию бизнеса «Лаборатории Касперского». - Поэтому в конвергентных средах так важно использовать соответствующую комплексную защиту, обеспечивая безопасность виртуальных систем специально предназначенными решениями. Мы реализуем подход, при котором вне зависимости от типа инфраструктуры для всех систем обеспечивается единое по степени защищенности покрытие всей корпоративной сети. И в этом наши технологии и современные разработки VMware (как, например, микросегментация) прекрасно дополняют друг друга».

2014: данные Ponemon и SafeNet

Большинство ИТ-организаций находятся в неведении относительно того, каким образом осуществляется защита корпоративных данных в облаке – в результате компании подвергают рискам учетные записи и конфиденциальную информацию своих пользователей. Таков лишь один из выводов недавнего исследования осени 2014 года, проведённого институтом Ponemon по заказу SafeNet . В рамках исследования, озаглавленного "Проблемы управления информацией в облаке: глобальное исследование безопасности данных", во всём мире было опрошено более 1800 специалистов по информационным технологиям и ИТ-безопасности.

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

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

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

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

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

Более двух третей (71%) респондентов отметили, что защищать конфиденциальные данные пользователей, хранящиеся в облаке, с помощью традиционных средств и методов обеспечения безопасности становится всё сложнее, и около половины (48%) отмечают, что им становится всё сложнее контролировать или ограничивать для конечных пользователей доступ к облачным данным. В итоге более трети (34%) опрошенных ИТ-специалистов заявили, что в их организациях уже внедрены корпоративные политики, требующие в качестве обязательного условия для работы с определёнными сервисами облачных вычислений применения таких механизмов обеспечения безопасности как шифрование. Семьдесят один (71) процент опрошенных отметили что возможность шифрования или токенизации конфиденциальных или иных чувствительных данных имеет для них большое значение, и 79% считают, что значимость этих технологий в течение ближайших двух лет будет повышаться.

Отвечая на вопрос, что именно предпринимается в их компаниях для защиты данных в облаке, 43% респондентов сказали, что в их организациях для передачи данных используются частные сети. Примерно две пятых (39%) респондентов сказали, что в их компаниях для защиты данных в облаке применяется шифрование, токенизация и иные криптографические средства. Еще 33% опрошенных не знают, какие решения для обеспечения безопасности внедрены в их организациях, и 29% сказали, что используют платные сервисы безопасности, предоставляемые их поставщиками услуг облачных вычислений.

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

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

Почему заказчики недовольны поставщиками облака?

Непрозрачное облако

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

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

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

«Среди всех сложностей сегодняшнего облака кроются и досадные изъяны, - пишет Лайлак Шёнбек (Lilac Schoenbeck), вице-президент по сопровождению и маркетингу продукта iland. - Столь важные метаданные не сообщаются, существенно тормозя принятие облака, и всё же организации строят планы роста исходя из допущения безграничности облачных ресурсов».

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

Невнимание к клиентам

Судя по всему, многие пользователи облака не ощущают тот самый индивидуальный подход.

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

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

Слишком много секретов

Нежелание поставщика предоставлять всю информацию не только раздражает заказчиков, но часто стоит им денег.

Все респонденты, принявшие участие в опросе Forrester, ответили, что ощущают определенные финансовые последствия и влияние на текущую работу из-за отсутствующих или закрытых данных об использовании ими облака.

«Отсутствие ясных данных о параметрах использования облака приводит к проблемам производительности, затруднениям отчетности перед руководством о реальной стоимости использования, оплате за ресурсы, так и не потребленные пользователями, и непредвиденным счетам», - констатирует Forrester.

А где метаданные?

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

Участники опроса отметили, что получаемые ими метаданные об облачных рабочих нагрузках обычно бывают неполными. Почти половина компаний ответила, что данные о соблюдении регулятивных норм отсутствуют, 44% указали на отсутствие данных о параметрах использования, 43% - ретроспективных данных, 39% - данных по безопасности, и 33% - данных биллинга и стоимости.

Вопрос прозрачности

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

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

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

Соблюдение регулятивных норм

Как ни крути, организации несут ответственность за все свои данные, будь то на локальных СХД или отправленные в облако.

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

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

Проблемы соответствия

Более 60% опрошенных компаний ответили, что проблемы соблюдения регулятивных требований ограничивают дальнейшее принятие облака.

Главные проблемы таковы:

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

Проблемы миграции

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

Из 51% неудовлетворенных процессом миграции 26% ответили, что это заняло слишком много времени, и 21% пожаловались на отсутствие живого участия со стороны персонала провайдера.

Более половины были также не удовлетворены процессом поддержки: 22% указали на долгое ожидание ответа, 20% - недостаточные знания персонала поддержки, 19% - на затянувшийся процесс решения проблем, и 18% получили счета с более высокой, чем ожидалось, стоимостью поддержки.

Препятствия на пути в облако

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

Шишкин В.М.

Аннотация

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

The situation developing now in connection with intensive expansion of so-called cloud services is analyzed in the paper. Insufficient study and discrepancy of understanding of security in «cloud» is marked and it is underlined trust maintenance as basic condition for successful use of these technologies. The paper considers the possibilities of the author’s technique and software oriented to risk analysis of complex objects which are not certain enough for the cloud computing security research.

Введение

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

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

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

Исходя из собственного опыта, присоединимся к мнению автора : «Сегодня говорить о безопасности облачных вычислений довольно сложно». Разумеется, существуют некоторые руководства по безопасности, выработанные, например, усилиями Cloud Security Alliance (CSA), тем не менее следует признать, что технический стандарт облачных вычислений находится все еще в начальных стадиях разработки .

При этом облачные вычисления как одна из технологий распределения и виртуализации ресурсов, в которой ресурсы и мощности предоставляются пользователю как интернет-сервис, с точки зрения безопасности на первый взгляд имеют преимущества перед традиционными технологиями взаимодействия в сетевых компьютерных структурах. Правда, технологии виртуализации доступа к сетевым ресурсам уже достаточно давно декларировались, в частности в Sun Microsystems, как едва ли не универсальное средство защиты их от несанкционированного использования, но, признавая безусловную эффективность и полезность данного подхода к повышению защищённости информационных ресурсов, панацеей их безопасности он стать, конечно же, не мог. Виртуализация доступа, тем более в отношении публичных сервисов, сама по себе не способна обеспечить информационную безопасность в широком смысле этого слова. Согласно данным CSA , несмотря на наличие встроенных в технологию облачных вычислений механизмов безопасности, при оценке рисков использования «облачных» услуг необходимо принимать во внимание большое количество обстоятельств. Добавим, что они не всегда достаточно определены и могут иметь субъективный характер, что существенно осложняет анализ любой ситуации.

1. Обзор технологических решений

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

инфраструктура как сервис (IaaS); платформа как сервис (PaaS);.

программное обеспечение как сервис (SaaS); хранение данных (рабочее место) как сервис (DaaS); оборудование как сервис (HHaaS);

ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ

PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»

VOL.II, IZHEVSK, NOVEMBER 8–12, 2011

коммуникации как сервис (CaaS).

На рисунке 1 представлена указанная схема архитектуры.

Рис. 1. Архитектура облачных вычислений

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

Sun Cloud Computing Resource Kit (SCCRK) опирается на принципы открытого ПО: предоставление механизмов взаимодействия для больших компьютерных ресурсов и распределенных приложений через компоненты для облачных вычислений. Предлагается ПО для полного построения облака: гипервизор (Sun xVM Server, базируется на Xen), виртуализация ОС (Solaris Containers), виртуализация сети (Crossbow), виртуализация накопителей

(COMSTAR, ZFS) и сервера приложений (GlassFish, Java CAPS).

Amazon EC2 является центральным компонентом системы для облачных вычислений Amazon Web Service (AWS), позволяющих создавать и загружать в

Amazon S3 (Simple Storage Component) образы виртуальных машин (Amazon Machine Image, AMI), настраивать через веб-сервис безопасность и сетевой доступ. Amazon S3 – виртуальный накопитель, доступ к которому осуществяется через веб-сервис. Как и SCCRK, Amazon предоставляет ПО для всех уровней построения облака. Новая разработка Amazon – CCI(Cluster Compute Instances) – предназначена для перенесения присущих облачному подходу масштабируемости и гибкости в область высокопроизводительных приложений. Компания представила классический Grid продукт, основанный на облачных технологиях – он представляет собой переход от Cloud к Grid –

ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ

PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»

VOL.II, IZHEVSK, NOVEMBER 8–12, 2011

явление, обратное обычной эволюции от Grid к Cloud. По сути, в аренду сдаются мощности большого числа стандартных стоечных серверов. При этом сохраняется возможность в любой момент подключить дополнительные узлы и гарантируется высокая скорость обмена данными (до 10 Гбит/с) между всеми узлами. Пока в семейство Cluster Compute Instances входит только одно решение – Cluster Compute Quadruple Extra Large. Его характеристики таковы: 23 Гб оперативной памяти, 33 стандартных узла EC2 с двумя четырёхъядерными процессорами Intel Xeon X5570 на базе микроархитектуры Nehalem и 1690 Гб дискового пространства. В качестве ОС по умолчанию используется CentOS Linux.

Terremark предлагает облачные решения на базе партнерской программы

VMware"s vCloud Express. В основе сервисов компании GoGrid лежат технологические решения на базе гипервизора Xen для запуска веб-

приложений. Joyent предлагает решения на базе Twitter.com. Microsoft Windows

Azure – сервис IaaS. Основной целью и задачей, поставленной перед сервисом, является тотальная интеграция ОС Windows и всего, что с ней связано, в облачную среду. Облачное решение Google App Engine на базе массивной и отказоустойчивой инфраструктуры и OpenSource стандартов и технологий предоставляет платформу для разработки и запуска приложений в их информационной среде.

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

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

(http://www.gazeta.ru/interview/nm/s3680945.shtml) директора по стратегическому развитию «СКБ Контур»: «Слово «облако» мы стараемся не употреблять, потому что пользователь его боится».

ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ

PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»

VOL.II, IZHEVSK, NOVEMBER 8–12, 2011

1. Проблемы безопасности облачных вычислений

Таким образом, первый аспект проблемы безопасности в облачных вычислениях состоит в недостаточной исследованности, определённости и разнородности факторов риска (уязвимостей, угроз и т.д.), сложности структуры их взаимодействия.

Кроме того, проблему обеспечения безопасности в технологиях облачных вычислений приходится рассматривать с двух точек зрения: провайдера услуг и пользователей «облачных» сервисов. Может показаться, что они должны совпадать, т.к. обе стороны заинтересованы в одном и том же результате – безопасности сервисов. Однако на самом деле мотивы, цели и понимание процессов у сторон разные, даже противоположные в некотором смысле, и, следовательно, различаются их модели рисков.

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

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

Таким образом, ещё один необходимый аспект рассмотрения проблемы безопасности в облачных вычислениях определяется наличием двух взаимозависимых, но не равноправных и не равно ответственных субъектов отношений с несовпадающими целями безопасности.

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

ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ

PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»

VOL.II, IZHEVSK, NOVEMBER 8–12, 2011

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

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

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

По оценкам аналитиков, рынок облачных услуг в 2009 г. составил около 17 млрд долл., а к 2013 г. достигнет 44,2 млрд. Согласно по данным Ассоциации аудита и контроля информационных систем (ISACA), опросившей свыше полутора тысяч организаций более чем в 50 странах Европы, Ближнего Востока и Африки, 33% ИТ-менеджеров уже успешно применяют «облачные» технологии. Однако одна пятая респондентов по-прежнему считает, что риски от внедрения «облаков» перевешивают их преимущества. Более 18% ИТпрофессионалов надеются воспользоваться облачными вычислениями в будущих проектах, а другие 18% пока не определились с какими-либо планами. Оставшиеся 63% не намерены адаптировать «облачные» подходы в своих компаниях. Всего 9,4% ИТ-специалистов в настоящий момент планируют прибегнуть к «облачным» службам для обеспечения работы критических приложений, хотя около двух третей (63%) организаций согласны взять на себя связанные с ИТ бизнес-риски, а 12,1% компаний готовы крупно рисковать, надеясь на максимальную отдачу. На вершине приоритетов у 58% респондентов – защита конфиденциальных данных в «облаках».

Принимая во внимание, что значительная часть «облачных» сервисов востребована в Европе (971 млн евро в 2008 г., до 6,005 млрд – в 2013 г.),

ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ

PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»

VOL.II, IZHEVSK, NOVEMBER 8–12, 2011

Европейское агентство по сетевой и информационной безопасности (European Network and Information Security Agency, ENISA) исследовало риски, связанные с такого рода сервисами. Оценка безопасности облачных вычислений проводилась с учетом трех основных тенденций и сценариев: 1) миграции среднего бизнеса на «облачные» сервисы, 2) влияния облачных вычислений на устойчивость обслуживания, 3) использования облачных вычислений в системах eGovernment, eHealth и прочих социально значимых масштабных проектах. Многие аналитики, в том числе специалисты Gartner, отмечают, что важнейшими аргументами за миграцию на «облачные» сервисы являются снижение стоимости и высокая масштабируемость, а наибольшее беспокойство вызывают вопросы конфиденциальности информации и ответственности за инциденты с используемой инфраструктурой.

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

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

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

ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ

PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»

VOL.II, IZHEVSK, NOVEMBER 8–12, 2011

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

Универсальных средств пока нет и от других угроз, тем не менее европейские эксперты разработали ряд рекомендаций по минимизации рисков, связанных с миграцией на облачные вычисления, предполагающих четкое разделение сфер ответственности клиента и провайдера в вопросах безопасности. Квалификация разработчиков политик безопасности, технические механизмы и процесс управления рисками, уровень тестирования сервиса, возможности вендора по выявлению непредвиденных уязвимостей и мониторингу аномальной активности, соответствие регуляторным требованиям, возможности провайдера по хранению и обработке данных в рамках определенной юрисдикции, изоляция данных, средства обеспечения непрерывности бизнеса – вот основные факторы, на которые необходимо обращать внимание при миграции в «облака». Государственным структурам необходимо убедиться еще и в том, может ли провайдер предоставить исчерпывающую информацию и контроль за текущим физическим размещением данных, поддерживает ли он принятую схему их классификации, гарантирует ли полную изоляцию ресурсов клиента (т.е. без совместного использования физических компьютеров), поддерживается ли двухфакторная аутентификация и выполняет ли провайдер требования спецификаций ISO

На рисунке 2, приведённом в , иллюстрируются некоторые аргументы «за» и «против» применения технологий облачных вычислений.

Рис. 2. Облачные вычисления: «за» и «против»

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

ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ

PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»

VOL.II, IZHEVSK, NOVEMBER 8–12, 2011

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

2. Постановка и подход к решению задачи риск-анализа облачных вычислений

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

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

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

ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ

PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»

VOL.II, IZHEVSK, NOVEMBER 8–12, 2011

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

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

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

«угрозы» нарушения безопасности – множество M e (threat events), в котором

выделяется подмножество так называемых «событий риска» – угроз, непосредственно наносящих ущерб объекту;

«компоненты» объекта – множество M c (components).

На множестве M 0 определяется хотя бы один тип отношений: бинарное

отношение причинности R со свойством транзитивности, к которому можно свести многие связи, имеющие импликативный характер.R упорядочиваетM 0

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

W 0.

Цель реализует «система защиты информации» – СЗИ, или, в общем случае, сиcтема защиты противодействия факторам риска, которая представима в виде множества элементов S , каждый из которых осуществляет воздействие на элементы изM 0 . Между элементами множествS иM 0 устанавливается

отношение, формально подобное R , порождающее прямоугольную матрицу отношенийR 0 .

На рисунке 3 показана простая иллюстрация такого представления метамодели.

ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ

PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»

VOL.II, IZHEVSK, NOVEMBER 8–12, 2011

Рис. 3. Структурная схема метамодели

Источники угроз из M s считаются генераторами потока событий (угроз), распространяющегося по каналам, заданным отношениемR наM 0 . Элементы

представляющих события риска, формируется поток угроз, непосредственно воздействующий на объект в составе M c . Тогда средства защиты изS можно

интерпретировать как фильтры.

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

которого по некоторому интервалу времени является, по сути, мерой риска для объекта, измеряемого ущербом, наносимым ему за это время.

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

матрицу W (w ij ) , элементы которой можно рассматривать как весовые

коэффициенты, имеющие смысл меры влияния i -го элемента наj -й. Она

содержит все исходные данные для расчетов на модели, полученные и представленные тем или иным способом.

с учетом транзитивности R . В результате определяется матрицаV , структурно эквивалентнаяW . При отсутствии рефлексии элементов, еслиW считать взвешенной матрицей смежности некоторого графа, они легко рассчитываются на графе в соответствующих терминах как суммы по всем путям изi -й вj -ю

ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ

PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»

VOL.II, IZHEVSK, NOVEMBER 8–12, 2011

вершину произведений оценок дуг каждого пути, что равносильно матричному преобразованию V (I W )1 I .

Однако в общем случае такой расчет не возможен, и тогда V рассчитывается с использованием аппарата марковских цепей следующим образом. ИзW исключается левый блок нулевых столбцов, соответствующих множествуM s , выделяются верхний горизонтальный блок в виде матрицыW s

V e det(D e )(D e 1 ).

Последний, всегда не содержащий нулей, z -й столбецv z матрицыV содержит искомые показатели {v iz } влияния любогоi -го фактора риска на

безопасность объекта. Эти показатели должны целенаправленно ориентировать создание системы защиты на противодействие наиболее значимым факторам риска.

Для получения количественной оценки результативности системы защиты матрица R 0 также арифметизируется, а соответствующая матрицаR (r kj )

содержит оценки воздействия k -го элемента СЗИ наj -й фактор риска. Далее

она преобразуется в вектор r , гдеr j 1 (1r kj ) , или дополняющий

его u ,u j 1r j ,r j 1,u j 0 , представляющие совместное действие элементов системы защиты. Тогда общий показатель её результативностиr z

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

Факторы риска можно также связать с физическими объектами, задав множество P , представляющее оборудование, физические среды, персонал и

защиты получить оценки значимости оборудования в отношении безопасности системы.

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

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

Заключение

Технологии облачных вычислений являются очередным и не последним этапом развития тенденции на распределённость и виртуализацию информационных и технологических ресурсов, которая стала заметной по крайней мере с 70–80-х годов прошлого столетия. Достаточно вспомнить в связи с этим вычислительные сети коллективного пользования тех лет на базе территориально удалённых мэйнфрэймов. Проблемы безопасности таких технологий стояли всегда, хотя и не всегда формулировались явным образом в терминах безопасности, так как это были проблемы профессионалов и для профессионалов, число которых было относительно невелико. Они были вполне конкретны, лишены субъективизма, лежали в организационнотехнической плоскости и решались соответствующими средствами.

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

публичную плоскость, и, соответственно, решаться они должны уже в комплексе, исходя из разных, в том числе противоречивых, интересов.

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

Список литературы

1. Hewitt C. ORGs for Scalable, Robust, Privacy-Friendly Client Cloud Computing // IEEE Internet Computing, 2008, vol. 12, no. 5, p. 96–99.

2. Черняк Л. Безопасность: облако или болото? // Открытые системы. СУБД, 2010, № 1, c. 16–19.

3. Security Guidance for Critical Areas of Focus in Cloud Computing V2.1.

Copyright © 2009 Cloud Security Alliance, 76 p. URL: https://cloudsecurityalliance.org/csaguide.pdf (дата обращения 29.08.2011).

4. Youssef L. et al. Toward a Unified Ontology of Cloud Computing.

5. Дериева Е. «Облака»: преимущества и риски безопасности // Компьютерное

6. Стрельченко Ю. ИТ-специалисты прибегают к «облачным» вычислениям, несмотря на риски [Электронный ресурс] 24.03.2010. URL: http://net.compulenta.ru/517328 (дата обращения 29.08.2011).

7. Шишкин В.М. Сравнительный анализ методик комплексного оценивания рисков в информационных системах // Региональная информатика (РИ2010) / XII Санкт-Петербургская Международная конференция. СанктПетербург: СПОИСУ, 2010, c. 150.

8. Шишкин В.М. Метамодель анализа, оценки и управления безопасностью информационных систем // Проблемы управления информационной безопасностью: Сборник трудов ИСА РАН / Под ред. Д.С.Черешкина. Москва: Едиториал УРСС, 2002, c. 92–105.

9. Shishkin V.M., Savkov S.V. The Method of Interval Estimation in Risk-Analysis System // Proceedings of the Second International Conference on Security of Information and Networks. Famagusta, North Cyprus: New York: ACM, 2009, p. 3–7.

10. Шишкин В.М., Савков С.В. Методика арифметизации неполной

системах: Труды Международной научной школы МА БР – 2010. СанктПетербург: ГУАП, 2010, с. 295–300.

ТРУДЫ КОНФЕРЕНЦИИ «ТЕХНОЛОГИИ ИНФОРМАТИЗАЦИИ

PROCEEDINGS OF CONFERENCE «TECHNOLOGIES OF INFORMATISATION IN PROFESSIONAL ACTIVITY»

VOL.II, IZHEVSK, NOVEMBER 8–12, 2011

Огромные вычислительные мощности облачных инфраструктур открывают перед пентестерами и блекхатами множество новых возможностей. Сегодня мы посмотрим на cloud computing с новой стороны и рассмотрим конкретные кейсы использования облачных мощностей для взлома и пентестинга.

IaaS на службе у хакера

Облачные вычисления представлены для пользователя следующими услугами:

• SaaS (Software as a Service)
• PaaS (Platform as a Service)
• HaaS (Hardware as a Service)
• WaaS (Workplace as a Service)
• IaaS (Infrastructure as a Service)
• EaaS (Everything as a Service)
• DaaS (Data as a Service)
• SaaS (Security as a Service)

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

Что же такое сервис IaaS для пентестера? Это уникальная возможность использовать десятки идентичных по возможностям серверов с целью эффективной реализации классических задач в области пентеста:

• обман IPS при удаленном сканировании портов;
• распределенный перебор паролей;
• атаки на отказ в обслуживании;
• сканирование сетевого периметра;
• автоматизированный поиск уязвимостей.

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

Анонимность

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

Сетевая разведка

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

Сканирование портов

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

Проведение атак

IaaS-площадки идеально подходят и для атак на удаленные сервисы. Например, для перебора паролей, а также различных видов client-side-атак. Во-первых, на площадке достаточно легко и просто «развернуть» любой боевой арсенал, например, metasploit или canvas. Во-вторых, перебор паролей может быть осуществлен распределенно, как и в случае со сканированием портов удаленного хоста, во избежание блокировки IP-адреса атакующего. В третьих, площадка IaaS может послужить отличным посредником между атакующим и целью с точки зрения того, что история всех действий, совершенных с площадки IaaS, будет уничтожена после выключения сервера.

Брутфорс

Возможность использовать условно «неограниченные» ресурсы облачных вычислений позволяет продуктивно проводить мероприятия по брутфорсу хешей и генерации радужных таблиц с последующим восстановлением по ним зашифрованных строк. Явным плюсом генерации радужных таблиц на базе облачных сервисов является возможность использования огромного устройства хранения данных. На практике генерация радужных таблиц для алгоритма ntlm (mixalpha-numeric-all-space, 8 символов) сводится только к вопросу времени и финансовым затратам. Для генерации такой таблицы на топовом домашнем компьютере потребуется порядка 1290 лет. В случае же облачных вычислений, прямо здесь и сейчас можно купить «машину времени», которая будет создаваться примерно 1,5 года и ее стоимость составит порядка $320k. Я хочу сказать, что такую таблицу, используя облачные вычисления, на практике можно создать всего за 1,5 года. В таблице 1 показана детальная статистика по финансовым затратам для такой разработки. В данном случае использовалось 20 серверов со следующими техническими характеристиками: 2xIntel Xeon X5570 quad-core «Nehalem» architecture, 2 ядра NVidia Tesla M2050, 23 Гб ОЗУ.

Цифры говорят о том, что пора менять парольную политику - расшифровать NTLM-хеш пароля из 8 символов вполне реально и доступно для плохих парней. Но это только теория. На практике же политика безопасности паролей более лояльна и ограничивает пользователя лишь длиной пароля - 8 символов в лучшем случае. Статистика используемых паролей в крупных компаниях, составленная Дмитрием Евтеевым и приведенная в его докладе «Анализ проблем парольной защиты в российских компаниях «, говорит о том, что большинство пользователей всеми возможными способами пытаются обойти ограничения парольной политики и использовать простой пароль.

В таблице 2 представлены необходимые для генерации различных радужных таблиц ресурсы.

Как видно, генерация «универсальной» радужной таблицы для паролей, состоящих из символов английского алфавита (lowcase) и цифр (от 1 до 12 символов) занимает целый миллениум и порядка 80 млн долларов. Для частного лица это на грани фантастики, но для государств и даже крупного бизнеса - вполне подъемно. Если же задаться целью, то используя всего 20 000 серверов вместо 20, можно создать такую таблицу всего за год.

Облачный DDoS

В первую очередь необходимо разобраться со схемой проведения эффективной ДДоС-атаки на сервер/сервис. Гаранты эффективности ДДоС-атаки:

• большое количество атакующих машин;

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

Специалистами нашей компании было разработано техническое задание для подобного рода софта. Требования к распределенной системе нагрузочного тестирования:

• мультиплатформенность (Linux/Windows);
• модульность;
• централизованное управление (клиент<->сервер).

Необходимые на первых парах модули:

• SYN flood
• UDP flood
• ICMP flood
• Application flood
• HTTP/HTTPS (GET/POST)
• SMTP/SMTP+SSL/TLS
• POP3/POP3+SSL

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

Из публичных утилит мы использовали два продукта:

• Mauszahn - утилита для генерации трафика (как валидного, так и невалидного). В большинстве случаев используется для проведения тестирования сетей VoIP или больших сетей, а также для проведения аудита безопасности в отношении систем, возможно уязвимых для специфических атак на отказ в обслуживании.
• SlowPost.pl (аналог для SlowLoris HTTP DoS Tool) - небольшой скрипт, позволяющий провести атаку на протокол HTTP через POST-запросы к веб-серверу, с целью вызвать отказ в обслуживании (исчерпав максимальное количество подключений к серверу). Более подробное описание данной атаки представлено на странице SlowLoris HTTP DoS . Аналогичный способ Application Flood для протокола HTTP через POST-запросы с использованием облачных вычислений был представлен Дэвидом Брайеном и Михаилом Андерсоном на хакерской конференции Defcon 18 . Они реализовали функционал распределенной системы Application Flood’а для протокола HTTP, но, к сожалению, практический результат в виде «отказа в обслуживании» реального сервера (парнями был использован для презентации один из веб-серверов Defcon’а) не был получен, хотя задумка в теории действительно должна была отлично работать. К такой заминке могло привести либо недостаточно эффективное осуществление Application Flood, либо недостаточное количество атакующих серверов. В разработке скрипта SlowPost.pl основной качественной характеристикой являлось эффективное осуществление Application Flood. В итоге, скрипт позволяет создать и поддерживать одновременно более 900 подключений к атакуемому веб-серверу с одной атакующий машины. Такие характеристики позволяют с помощью всего одной атакующей машины обеспечить атаку на «отказ в обслуживании» для большинства веб-серверов, работающих под управлением веб-сервера Apache. Ведь директива MaxClients по умолчанию равна 256: веб-сервер обеспечивает возможность работы только с 256 пользователям одновременно. Веб-сервер IIS (Windows 2003 Server), в отличие от Apache, использует значение по умолчанию, равное приблизительно 20 000.

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

Технические характеристики запускаемого Instance, выступающего в роли атакующего звена, представляют собой следующее:

• система x86/x64 (1 CPU);
• 613 Мб ОЗУ;
• 10 Гб HDD.

Технические характеристики Instance были выбраны минимальными в силу того, что для реализации атаки на «отказ в обслуживании» приоритет отдается количеству атакующих машин, а не их вычислительным характеристикам. Каждый Instance снабжен каналом с пропускной способностью 100 Mb/s, поэтому проблем в скорости передачи данных до атакуемого сервера теоретически быть не должно.

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

Как было выяснено, связка 1 «Instance» + скрипт SlowPost.pl позволяет эмулировать более чем 900 клиентов веб-сервера. Таким образом, этой связки достаточно, чтобы вывести из строя любой веб-сервер, поддерживающий максимальное число подключений менее чем 900. Бюджет, необходимый для реализации такой атаки сводится к минимуму за счет потребления лишь компьютерного времени, а не ресурсов и трафика. Себестоимость атаки для таких веб-серверов - меньше 7 рублей в час! (см. таблицу 4)

При тестировании в реальных условиях мишенью выступал веб-сайт, обслуживаемый сервером IIS. Балансировка нагрузки была разделена на два IP-адреса. Таким образом, чтобы положить этот сервер, потребовалось создать более чем 20 000 подключений к каждому из IP-адресов. Настройки атакуемого веб-сервера были установлены по умолчанию. В итоге, для обеспечения всех условий для удачной атаки «отказ в обслуживании» было запущено 46 «Instance», каждый из которых эмулировал одновременную работу 900 пользователей. Кстати, обычным пользователям Amazon позволяется работать одновременно только с 20 «Instance». Чтобы полностью пройти путь плохого парня, задумавшего DDoS-атаку, мы просто зарегистрировали три различных аккаунта. Кроме этого, для регистрации нам понадобилось три сим-карты. Естественно, были куплены анонимные карты с балансами 300 рублей - причем абсолютно легально. К каждой сим-карте была приобретена карта оплаты (Prepaid Card For Internet Shopping) с балансами $5 - карта необходима при регистрации на площадке Amazon и верификации. В итоге, бюджет для атаки «отказ в обслуживании» на веб-сайт достаточно крупной компании составил всего 1150 рублей. Детальная стоимость представлена в таблице 5.

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

Трояны в Instance

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

Для проведения теста потребовалось:

• создать образ популярной ОС в формате AMI и выложить его в открытый доступ в интерфейс Амазона;
• составить хорошее описание настроенной системы (установленный софт, полезные «плюшки» и т.д.);

Кроме этого мелким шрифтом в описании программы было написано, что при старте этого образа ОС в автоматическом режиме происходит HTTP-GET-отстук на сервер, собирающий статистику. Хотя об этом можно было и не говорить в описании образа, мелкий текст не испортил картины. Как результат - более 1000 отстуков за месяц! Представь, какой хороший и бесплатный ботнет можно собрать. Размещаешь протрояненный образ с красивым описанием - пользователи устанавливают его, а ты анонимно пользуешься их серверами за их же деньги.

Abuse-практика

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

Что делать в случаях атак

При первом обращении к провайдеру, служба безопасности просит предоставить следующую информацию:

• IP-адрес атакующего;
• IP-адрес жертвы;
• атакуемый порт и протокол, по которому происходила атака;
• точную дату, время и временную зону жертвы;
• логи с машины жертвы, подтверждающие факт атаки (не более 4 Кб);
• контактные данные.

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

Заключение

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