Угрозы безопасности в облаке
Теперь, когда мы понимаем, как соблюдается соглашение между клиентом и поставщиком, давайте рассмотрим основную проблему, актуальную как для поставщиков облачных служб, так и для пользователей: безопасность.
В процессе конкуренции поставщиков облачных служб за лидирующее положение на рынке их функции безопасности стали важнейшим фактором, определяющим различия.
На одном уровне поставщики облачных служб могут использовать эффект удешевления за счет массовости. Внедряя меры безопасности в больших масштабах, они могут обеспечить более доступные защитные механизмы при меньших затратах. Обычно это включает сетевой мониторинг и фильтры, управление обновлениями, аппаратную защиту, реагирование на инциденты и криминалистику, а также различные типы управления угрозами.
Как правило, они также предоставляют доступный интерфейс для изменения настроек безопасности, что обеспечивает безопасную смену ключей, своевременные обновления и исправления. Кроме того, так как все действия виртуализированы, можно регулярно делать их моментальные снимки и выполнять криминалистический анализ для выявления попыток использования уязвимостей, которые пока неизвестны (также называемых уязвимостями "нулевого дня").
Давайте взглянем на облако с точки зрения типичного предприятия, использующего собственную ИТ-инфраструктуру. Руководители предприятий считают, что они теряют контроль как функцию владения активами, когда переходят от традиционных серверов к частным облакам, а затем повышают ставки от IaaS к SaaS (рис. 11). Во всех трех моделях обслуживания поставщик облачных служб полностью владеет базовой инфраструктурой (сетями, хранилищами и узлами). В PaaS поставщик услуг может дополнительно претендовать на частичное владение инфраструктурой приложения. Наконец, в модели SaaS инфраструктура приложения полностью принадлежит поставщику услуг.
Рис. 11. Предприятия теряют контроль по мере перемещения по общедоступному стеку облака
Однако во всех трех моделях предприятие полностью владеет всеми своими данными. Но, к сожалению, оно не может полностью контролировать эти данные, так как они хранятся за пределами периметра сети. Отсутствие контроля над хранением и передачей конфиденциальных данных является одним из главных факторов, препятствующих масштабному внедрению облаков. Две трети потенциальных пользователей считают "безопасность и конфиденциальность данных" самым большим риском в облачных вычислениях.
Рис. 12. Проблемы безопасности являются самыми большими барьерами для крупномасштабных внедрения облака
Угрозы
Крупнейшие угрозы на высоком уровне — это угрозы, вызванные зависимостью от поставщика (приложения не очень просто переносить между платформами), риски соответствия требованиям (соблюдать большинство стандартов соответствия гораздо сложнее в общедоступных облаках) и потеря управления (большинство поставщиков облачных служб не предоставляют соглашения об уровне обслуживания, включающие гарантии безопасности данных).
На более низком уровне угрозы связаны с общей инфраструктурой, отсутствием жесткого периметра и ограниченным контролем над физическим хранением и удалением данных. Следует отметить, что атаки на гипервизоры и общее размещение значительно реже и сложнее, чем атаки на операционные системы и сети, докучающие традиционным приложениям.
Федерация информационной облачной безопасности предоставляет классификацию угроз, которые приведены далее.
Угроза 1. Злоупотребление и невзрачное использование облачных вычислений
Затронутые службы: IaaS, PaaS
Злоумышленники могут использовать анонимность, которую обеспечивают общедоступные облака, для запуска вредоносных атак с минимальными затратами. Общедоступные облака использовались для ботнетов, проводящих атаки с командным центром, взлома CAPTCHA, вычислений радужных таблиц и динамических атак. Каждое из этих злонамеренных действий использует грубую силу, предоставляемую центром обработки данных.
Поставщики пытались противостоять этой угрозе путем добавления строгих проверок регистрации и исчерпывающего мониторинга всего сетевого трафика. Например, поставщик облачных служб может отслеживать метаданные всех исходящих электронных писем для выяснения, не используется ли он клиентом для рассылки спама.
Угроза 2. Небезопасные интерфейсы и API
Затронутые службы: IaaS, PaaS, SaaS
Как упоминалось ранее, поставщики облачных решений предоставляют простые в использовании консоли, панели мониторинга, интерфейсы и веб-службы для взаимодействия с облаком. Однако если в этих интерфейсах существует какая-либо уязвимость, это создает дополнительную угрозу для всей сети. Таким образом, даже если вся облачная инфраструктура разработана с надежной защитой, единственная уязвимость на веб-сайте поставщика может позволить злоумышленнику захватить учетную запись клиента.
В настоящее время большинство поставщиков используют строгую многофакторную проверку подлинности, ведение подробного журнала, обнаружение аномалий и безопасные настройки по умолчанию для противодействия этой угрозе. Веб-интерфейсы публикуются только после очень строгой проверки на наличие уязвимостей в коде (тестирование методом белого ящика), а также в реализации (тестирование методом черного ящика).
Угроза 3. Вредоносные программы предварительной оценки
Затронутые службы: IaaS, PaaS, SaaS
Когда организация использует общедоступные облака, растет угроза от внутренних злоумышленников. В отличие от развертывания собственной ИТ-инфраструктуры, доступ к центру обработки данных имеют не только сотрудники предприятия. Так как служба работает на внешнем компьютере и хранит данные в ресурсах поставщика, всегда существует вероятность, что недовольный или имеющий другую мотивацию сотрудник поставщика облачных служб сможет сделать то, что негативно повлияет на службу поставщика.
Чтобы противостоять этой угрозе, поставщики облачных служб применяют строгие стандарты по отношению к сотрудникам и проводят детальный аудит и мониторинг. Они также по контракту определяют политики найма сотрудников и уведомлений о нарушениях в рамках контракта службы.
Угроза 4. Проблемы с общими технологиями
Затронутые службы: IaaS
Это одна из фундаментально "новых" угроз, возникшая в рамках облачной парадигмы. Облако работает, предоставляя нескольким арендаторам (например, вам и вашим одноклассникам) виртуальный доступ к общей инфраструктуре. Изоляция между совместными арендаторами обеспечивается с помощью "песочницы" (изолированной программной среды, называемой гипервизором), которая является промежуточным звеном между виртуальными машинами и базовой инфраструктурой.
Хотя сотенанты должны быть не в состоянии получить доступ к деталям своих соседей, несколько эксплойтов в течение многих лет позволили клиентам выйти из песочницы и украсть данные из памяти другого клиента, сети и т. д. Примером этого может быть то, что при написании кода на облачной виртуальной машине для решения проектов классов одноклассник управляет входом на виртуальную машину на том же физическом компьютере, что и вы, а затем использует некоторые свойства общего физического компьютера для кражи кода. Полностью изолировать всех пользователей — очень сложная проблема, даже с современными гипервизорами.
Для устранения такой угрозы поставщики облачных служб добавляют серьезные возможности мониторинга, используя соглашения об уровне обслуживания для обеспечения своевременного управления уязвимостями и исправлениями, а также проводят регулярные аудиты. Кроме того, гипервизоры должны периодически усиливаться для защиты от потенциальных новых атак.
Например, на странице с рекомендациями по безопасности Xen приведены рекомендации по безопасности для гипервизора Xen. Каждый раз, когда атака становится известной, поставщик облачных служб должен обновить системы безопасности всех своих серверов, чтобы злоумышленник не мог использовать эти эксплойты.
Угроза 5. Потеря или утечка данных
Затронутые службы: IaaS, PaaS, SaaS
Это еще один недостаток облаков с внешним размещением. Часто нормативные акты требуют, чтобы предприятие несло юридическую ответственность за любые конфиденциальные данные, которые используются или хранятся его приложениями. Даже если эти данные зашифрованы и хранятся в облаке, в облаке также должен находиться и ключ для расшифровки этих данных.
Новые исследования в области технологий шифрования привели к появлению гомоморфного и раздельного управления ключами. Гомоморфные ключи позволяют выполнять обработку зашифрованных данных. Таким образом, сам ключ не нужно переносить в облако. В решениях с разделением ключей подразумевается наличие главного ключа (который надежно хранится вне облака) и нескольких подчиненных ключей для каждого приложения или модуля. Так как главный ключ никогда не попадает в облако, угроза взлома данных уменьшается.
К сожалению, эти методы все еще имеют ограничения и требуют больших затрат. На договорном уровне важно определить процессы резервного копирования, хранения данных, очистки данных, безопасного управления ключами и их хранения, а также достаточные привилегии для проведения аудита. Это подразумевает, что должен соблюдаться определенный набор хорошо разработанных стандартов, таких как рекомендации NIST по обеспечению безопасности и конфиденциальности в общедоступных облачных вычислениях.
Важно также рассмотреть в контракте все вопросы юрисдикции. Несмотря на то, что данные хранятся у поставщика облачных служб, контракты оформляются таким образом, что любая ответственность в случае бреши в системе возлагается на владельца приложения. Следовательно, большинству поставщиков облачных служб необходимо пройти аудиты на соответствие стандартам ISO 27001, SAS-70, а также другие аудиты, относящиеся к конкретному региону, которые покажут зрелость процесса и наличие элементов управления безопасности.