Безопасность при использовании облачных сервисов. Риски облаков: угрозы и решения. Доступ к облачным серверам

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

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). Часто провайдеры изолируют данные пользователей друг от друга за счет изменения данных кода в единой программной среде. Данный подход имеет риски, связанные с опасностью найти дыру в нестандартном коде, позволяющему получить доступ к данным. В случаи возможной ошибки в коде пользователь может получить данные другого. В последнее время такие инциденты часто имели место.

Заключение

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

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

Насущные угрозы

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

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

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

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

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

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

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

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

Экспертное мнение

Вячеслав Вовкогон, специалист по информационной безопасности DataLine

Каковы, по вашему мнению, самые главные риски для облачных систем? Связаны ли они с уязвимостями архитектуры, инсайдерскими угрозами и утечками или с проникновением извне и DDoS-атаками на облака?

Можно выделить как угрозы, присущие большинству облачных информационных систем, так и специфичные. Так, проблема уязвимости облачной архитектуры характерна для высокоуровневых моделей (PaaS, SaaS). Она особенно актуальна для организаций госсектора. Например, используемое ПО должно обязательно иметь сертификаты ФСТЭК по отсутствию НДВ (недокументированные возможности).

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

Возможные решения

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

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

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

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

Наконец, сами облака могут предоставлять услуги безопасности даже для вычислительных ресурсов, размещённых на территории заказчика: возможно, что с ростом доверия к облакам Security as a Service станет намного более востребованным сервисом. Облачные антивирусы, системы определения вторжений IDS и защиты от DDoS, а также различные межсетевые экраны могут значительно облегчить задачу обеспечения безопасности даже для крупных компаний.

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

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

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

Экспертное мнение

Эдуард Бавижев, руководитель группы виртуализации DataLine

Для надёжной защиты облачной инфраструктуры необходимо использовать специализированные программные продукты и решения. В практике DataLine для обеспечения безопасного доступа к облаку используется решение Cisco Easy VPN, в рамках которого применяются устойчивые алгоритмы шифрования. Помимо этого, есть возможность разграничения доступа к порталу заказчика с использованием различных методов фильтрации.
Для защиты периметра виртуального дата-центра можно применять как аппаратные решения, так и специализированные программные. В компании DataLine для этих целей служат vShield EDGE и Cisco ASA. Оба варианта поддерживают функции VPN (с возможностью шифрования трафика), преобразования сетевых адресов (NAT), также дают возможность настраивать FireWall по определённым протоколам и портам. Для обеспечения антивирусной защиты виртуальных машин можно прибегнуть к продуктовой линейке vShield – в частности vShield Endpoint, а также к продукту Trend Micro Deep Security. Что касается защиты от DDoS-атак, то DataLine предоставляет соответствующий сервис совместно с компанией Highloadlab.

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

Огромные вычислительные мощности облачных инфраструктур открывают перед пентестерами и блекхатами множество новых возможностей. Сегодня мы посмотрим на 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-адрес атакующего может менять владельца более одного раза за сутки, что усложняет идентификацию злоумышленника. Кроме этого следует точно идентифицировать вид атаки и создать слепок лог-файлов атакуемого сервиса для предоставления службе безопасности провайдера.

Заключение

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

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

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

КОНТРОЛИРУЕМОЕ ИСПОЛЬЗОВАНИЕ РЕСУРСОВ

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

Такие функции предоставляют все наиболее популярные облачные брокеры, такие как vCloud Director, Amazon/ IAM, OpenStack и CloudStack. Во многих случаях возможна даже комбинация локальных и внешних ресурсов. Отказ от этих функций равносилен наличию одного общего пароля для всех сотрудников компании, работающих за общим компьютером, - очевидно, не самый благоприятный сценарий. Поэтому создание и использование ролей, индивидуальных учетных записей или мандантов следует считать обязательным.

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

ДОСТУП К ОБЛАЧНЫМ СЕРВЕРАМ

Один из подходов заключается в разделении внутреннего и внешнего подтверждения прав доступа (Credentials). Это можно реализовать на базе собственных серверов доступа/SSH/ RDP Proxy или с помощью специализированных коммерческих решений. При этом сотрудники указывают свой внутренний пароль для регистрации на сервере доступа, а после проверки предоставленных им прав получают доступ к облачному серверу. Таким образом, при обращении к внешним ресурсам они смогут использовать свои собственные (доменные) пароли без угрозы для безопасности.

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

ЖУРНАЛЬНЫЕ ЗАПИСИ В ОБЛАКЕ

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

Поэтому сохранение важных журнальных записей (вход/выход пользователей, целостность системы, обновления) за весь срок службы облачного сервера является важной и необходимой мерой. Только сбор данных, их объединение и вывод на внешние инструменты, к примеру на сервер Syslog, платформу безопасности с функцией проверки журналов или на систему управления событиями информационной безопасности (Security Information and Event Management, SIEM), позволят осуществить их последующий анализ. Атака на группу облачных серверов может остаться незамеченной, если атаки злоумышленника станут направляться каждый раз на новый сервер, но после вывода журнальных записей за пределы облачных серверов и выполнения их систематизации такое поведение можно будет быстро обнаружить (см. Рисунок 1).

УПРАВЛЕНИЕ БЕЗОПАСНОСТЬЮ

С точки зрения обеспечения безопасности облака представляют собой лишь одну из разновидностей инфраструктурных платформ, пусть даже с высокой степенью автоматизации. Разумеется, и в облаке не обойтись без процессов, которые хорошо зарекомендовали себя в традиционных физических системах. Такие основополагающие функции, как межсетевой экран, IDS/IPS, виртуальное закрытие уязвимостей (Virtual Patching) и антивирусы, являются обязательными элементами любой концепции безопасности, будь то физические, виртуальные или облачные системы. А вот задачи, возникающие при управлении этими функциями, в различных инфраструктурах отличаются.

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

ФИЛЬТРАЦИЯ ДАННЫХ

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

Вместе с тем, это позволяет централизованно контролировать изменения, производимые на облачных серверах (к примеру, в файлах или реестре). Чтобы снизить трудоемкость отслеживания таких событий, необходимо обеспечить автоматическую фильтрацию этих данных посредством специализированного ПО - сортировать вручную все события, к примеру при обновлении стандартной системы Linux или Windows, не получится. Благодаря автоматической фильтрации «положительных» событий появляется возможность подробнее изучить оставшиеся, обнаружить вероятные несанкционированные действия и отследить их.

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

Независимо от того, связан ваш бизнес с Интернетом или нет, в вашей компании все равно есть информационная cеть.

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

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

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

ОБРЕТЕНИЕ СТРАТЕГИИ: В ПОИСКАХ ОРИЕНТИРА

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

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

РЕАЛИЗАЦИЯ ЦИФРОВЫХ ПРЕИМУЩЕСТВ

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

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

ЦИФРОВАЯ БЕЗОПАСНОСТЬ

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

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

ЦИФРОВАЯ ГИБКОСТЬ

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

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

ЦИФРОВАЯ РЕВОЛЮЦИЯ НЕ ДОЛЖНА ЗАСТАТЬ ВРАСПЛОХ

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

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

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

Дмитрий Ушаков - руководитель отдела по подготовке и внедрению технических решений Stonesoft Russia.

ЗАЩИТА ДАННЫХ

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

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

ШИФРОВАНИЕ ДАННЫХ Сервер KMS проверяет идентификационные данные (к примеру, по облачному серверу, IP-адресам, шаблонам, ЦОД или местонахождению) и целостность (брандмауэр, установленные заплаты, наличие активного антивирусного сканера) облачного сервера, направившего запрос, - точно так же, как это делает человек при традиционном шифровании жестких дисков. В случае успеха ключ предоставляется либо автоматически, либо после подтверждения вручную уполномоченным лицом. После этого облачный сервер получает доступ к данным - до тех пор, пока не окажется нарушена его целостность или идентичность.

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

РАЗДЕЛЬНОЕ АДМИНИСТРИРОВАНИЕ КЛЮЧЕЙ

Помимо вышеупомянутого варианта шифрования жестких дисков с раздельным управлением ключами при предоставлении инфраструктуры в качестве сервиса (Infrastructure as a Service, IaaS), эта концепция встречается и при реализации модели предоставления платформы как услуги (Platform as a Service, PaaS). Информация зашифровывается таким образом, что в базы данных, предоставляемые провайдером облачных сервисов, в виде открытого текста она не попадает. В этом случае необходимые для работы с зашифрованными данными ключи тоже контролируются пользователем.

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

Защита в зависимости от облачной модели

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

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

При этом особое внимание следует уделить вопросам доступа к сервису SaaS. Для его защиты необходимы строгая двухфакторная аутентификация пользователей с помощью отчуждаемых носителей (USB-токенов или смарт-карт), например eToken, и передача данных в зашифрованном виде. Для этой цели подходят HTTPS или VPN с поддержкой сертифицированной «российской» криптографии, шифрование выборочных данных на прикладном уровне посредством подключаемого модуля браузера или же описанное автором статьи решение с применением собственных proxy-серверов, которые защищают коммуникацию с провайдером.

Модель «платформа как сервис» (Platform as a Service, PaaS), как и SaaS, при обработке персональных данных применима только при работе с доверенным провайдером. И на нее тоже распространяются все вышеперечисленные подходы (с некоторым расширением).

Кардинальную противоположность SaaS представляет модель «инфраструктура как сервис» (Infrastructure as a Service, IaaS). В данном случае потребителю предоставляется готовая инфраструктура. Это может быть как виртуальная машина, так и целая сеть. При обращении к услугам недоверенного провайдера следует контролировать доступ на уровне гипервизора, иначе все попытки построить эффективную защиту будут сродни построению крепких ворот без забора. При этом задача обеспечения информационной безопасности сводится к комплексной защите удаленного подразделения с применением зарекомендовавших себя традиционных методов, применяемых в физических системах.

В случае недоверенного провайдера при использовании любой модели актуально хранение данных в облаке в зашифрованном виде. Особую остроту этому вопросу придает популярность общедоступных сервисов Data as a Service и Database as a Service, которые не предусматривают защищенного взаимодействия между провайдером и потребителем, нарушая требования регуляторов в области ИБ. Когда HTTPS или VPN с сертифицированной «российской» криптографией не используется, единственно возможным решением представляется передача данных по открытым каналам связи в зашифрованном виде. И такие предложения имеются на рынке - например, «Крипто БД» в режиме работы с шифрующим посредником (proxy). Отличительная особенность этих решений заключается в том, что управление ключами осуществляется администратором ИБ в рамках локальной инфраструктуры, а не в инфраструктуре провайдера.

Максим Чирков - руководитель направления развития сервисов ЭП компании «Аладдин Р.Д.».

ЗАШИФРОВАННАЯ ПЕРЕДАЧА

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

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

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

ТЕХНИЧЕСКИЕ МЕРЫ

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

Удо Шнайдер - системный архитектор по региону ЕМЕА в компании Trend Micro.