Облачные услуги: Cнижение рисков и обеспечение высокой готовности

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

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

Джудит Майерсон, инженер, разработчик архитектуры систем, консультант

Джудит М. Майерсон (Judith M. Myerson) - разработчик архитектуры систем, инженер, писатель. В сферу ее интересов входят технологии промежуточного программного обеспечения, системы масштаба предприятия, технологии баз данных, разработка приложений, управление сетями, распределенные системы, технологии на основе компонентов и управление проектами. С ней можно связаться по электронной почте: jmyerson@bellatlantic.net



10.10.2012

Политика безопасности облачных услуг охватывает разные аспекты безопасности в облаке в зависимости от выбранной модели — SaaS, PaaS или IaaS.

  • Стратегия "Программное обеспечение как услуги" (SaaS) сосредоточена на управлении доступом к определенному приложению, арендуемому заказчиками, будь то частные лица, компании или госучреждения. Она должна решать задачу снижения рисков SaaS-приложений, которые уязвимы для атак со стороны вредоносных программ, использующих злонамеренные ресурсы экземпляра. Например, хакеры могут для своего удобства несанкционированно изменить установленные рабочие часы, в которые приложение позволяет правомочным ассистентам стоматологов загружать стоматологические записи, на более ранние утренние часы.
  • Стратегия "Платформа как услуги" (PaaS) сосредоточена на защите данных, а также на управлении доступом к приложениям, создаваемым и размещаемым независимыми поставщиками программного обеспечения, молодыми компаниями или подразделениями крупных предприятий, на протяжении всего их жизненного цикла. Эта стратегия должна снижать риски, связанные с возможностью использования PaaS в качестве центров управления бот-сетями с целью установки вредоносных приложений, например, манипулирующих стоматологическими записями.
  • Стратегия "Инфраструктура как услуги" (IaaS) сосредоточена на управлении виртуальными машинами, а также защите данных и управлении доступом к инфраструктуре тех традиционных вычислительных ресурсов, поверх которых в облачной среде работают виртуальные машины. Эта политика должна ориентировать управление инфраструктурой на смягчение рисков для виртуальных машин. Хакерские центры управления используют IaaS для прямой организации работы бот-сетей с целью установки вредоносных обновлений инфраструктуры внутри виртуальных машин и между ними.

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

Безопасность облачных услуг

Безопасности облачных услуг могут угрожать:

  • некорректный гипервизор;
  • отсутствие ограничительны правил;
  • переполнение механизма выравнивания нагрузки;
  • ненадежное шифрование.

Рассмотрим каждый случай подробнее.

Некорректный гипервизор

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

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

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

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

Отсутствие ограничительных правил

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

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

Отсутствие этих правил представляет угрозу:

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

Переполнение механизма выравнивания нагрузки

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

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

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

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

Ненадежное шифрование

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

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

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


Снижение рисков при использовании облачных услуг

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

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

  1. Определить активы.
  2. Проанализировать риски.
  3. Применить защитные контрмеры.
  4. Провести переоценку после прогона или события.

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

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

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

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

Рассмотрим каждый случай подробнее.

Шаг 1. Определение активов

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

Количество аппаратных и программных активов, которые потребителю необходимо определить при аренде услуг у поставщика SaaS, гораздо меньше, чем при использовании потребителем более подконтрольной ему модели PaaS и еще в большей степени ― IaaS.

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

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

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

  • операционные системы;
  • аппаратное обеспечение;
  • сетевая инфраструктура;
  • приложения для управления доступом;
  • ресурсы экземпляра;
  • обновления и исправления для SaaS-приложений.

Потребитель не несет ответственности за их определение.

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

Под контролем поставщика облачных услуг при схеме PaaS должны находиться, как минимум, следующие активы:

  • операционная система;
  • аппаратное обеспечение;
  • сетевая инфраструктура;
  • ресурсы экземпляра.

Потребитель не несет ответственности за определение этих активов.

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

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

Шаг 2. Анализ рисков

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

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

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

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

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

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

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

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

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

  • как хакер может войти;
  • что он ищет;
  • какие инструменты он имеет в своем распоряжении.

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

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

Шаг 3. Применение защитных контрмер

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

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

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

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

Вот некоторые примеры контрмер, о которых я уже упоминал в этой статье:

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

Шаг 4. Переоценка

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

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

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


Заключение

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

Ресурсы

Научиться

Получить продукты и технологии

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы, Облачные вычисления
ArticleID=839881
ArticleTitle=Облачные услуги: Cнижение рисков и обеспечение высокой готовности
publish-date=10102012