Олег Файницкий, 13/01/22
Облачные технологии выглядят сегодня весьма привлекательно для заказчиков: гибкость, доступность, возможность масштабирования и использование открытых платформ создают все условия для динамичного развития бизнеса. Более того, облачная модель организации ИТ как нельзя лучше подходит для внедрения современных практик DevOps и Agile-разработки, помогая компаниям сокращать время вывода новых продуктов на рынок (Time-to-Market). Однако при этом облака создают новые риски информационной безопасности, которые необходимо учитывать как заказчикам сервисов, так и провайдерам.
Автор: Олег Файницкий, архитектор по облачной безопасности Oracle
С одной стороны, перенос данных в облако провайдера позволяет компаниям с небольшим или нулевым штатом ИТ переложить задачи обеспечения ИБ на специалистов провайдера. Это вроде правильно, ведь трудоемкость атаки на облачного провайдера, как правило, не сравнима с трудоемкостью атаки на отдельного заказчика. Провайдеры имеют больше возможностей и ресурсов для защиты инфраструктуры и клиентских данных. Но есть и нюансы.
Облака бывают разные
Тем не менее как на стороне провайдера, так и в своей инфраструктуре можно столкнуться с различным уровнем безопасности. Существуют разные типы облаков и разные подходы к их защите. И сегодня, даже если провайдер не декларирует предоставление сервисов ИБ, заказчики априори ожидают от любого облака определенного уровня защиты. Например, ранее в своем отчете за II квартал 2021 г. редакторы TAG Cyber отметили [1], что расширение ответственности провайдера услуг в сторону кибербезопасности фактически неизбежно, если он хочет сохранить свои позиции на рынке.
Но, к сожалению, многие компании по-прежнему размещают свои данные и нагрузки в облаках, руководствуясь исключительно минимальной стоимостью хранения информации. И если созданные в облаках виртуальные машины просто распределяются между клиентами без дополнительной защиты и изоляции, успешная атака может принести хакеру данные целого ряда организаций и частных лиц. Однако облачные сервисы, ориентированные на корпоративных заказчиков и критически важные нагрузки, отличаются как архитектурно, так и функционально. Они уже не дают киберпреступникам шанса завладеть информацией большого количества пользователей. Так, существуют технологии изоляции виртуальных пространств разных заказчиков, разделения сетевых сегментов, шифрования данных и раздельного хранения информации. Более того, подобные решения применяются сегодня даже в рамках одного сервера! К примеру, недавно представленная Exadata X9M позволяет провайдерам полностью изолировать нагрузки, предоставляя доступ к высокопроизводительной платформе работы с СУБД в том числе для заказчиков из сегмента СМБ без каких-либо компромиссов с безопасностью.
Говоря про типы облаков, необходимо упомянуть облачную инфраструктуру, которую провайдер разворачивает непосредственно в ЦОД заказчика, так называемый Cloud@Customer. Такой подход дает заказчикам, для которых важно физическое месторасположение данных, возможность воспользоваться инновационным программным обеспечением, доступным только в облаке (чаще зарубежном), по цене подписки на аналогичные сервисы публичного облака. Но при этом у заказчика сохраняется полный контроль над своими критически важными данными. Однако и вопросы безопасности в этом случае приходится решать на уровне собственного ЦОД.
Вектор атаки – эксплойт или уязвимость?
Учитывая, что облака провайдеров корпоративного уровня, как правило, надежно защищены, атаки на облачные ресурсы обычно происходят одним из двух способов.
Во-первых, хакеры часто пытаются взломать всю экосистему облачного провайдера через одного из клиентов. И если в облаке не применяются средства изоляции рабочих сред, это вполне может сработать. Для атак используется разнообразное вредоносное ПО, а также фишинг, уровень которого вырос за последний год вдвое, по данным отчета Anti-Phishing Working Group (APWG). Фальшивые письма рассылаются сотрудникам компаний и ведут на поддельные сайты, где люди вводят свои учетные данные, заражаются вирусами и троянскими программами, а как следствие – открывают злоумышленникам доступ в корпоративную сеть и в облако. При этом со стороны провайдера сперва не наблюдается ничего необычного, ведь перед началом атаки пользователь входит в свою учетную запись.
Во-вторых, возможна атака на саму ИТ-инфраструктуру провайдера. Обычно ключевым элементом такой атаки является уязвимость в программном обеспечении. В 2021 г. были зафиксированы случаи эксплуатации брешей в специализированных решениях управления серверами. Атаки типа Supply Chain направлены как раз на использование инфраструктуры сервис-провайдера для получения данных его клиентов. Однако хакеры все чаще пытаются найти уязвимости и в общих решениях, которые встречаются как в корпоративной среде, так и у облачных провайдеров.
Риски информационной безопасности остаются высокими
Любая атака может стать причиной утечки данных большого количества компаний, если не принимать специальные меры для их защиты. Показательным примером может служить атака на компанию SolarWind в декабре 2020 г. Группировка REvil провела хитроумную работу и больше года готовилась к заражению инфраструктурного ПО, которое используют тысячи клиентов. В результате пострадало более 17 тыс. компаний, среди них оказались и облачные провайдеры. Как следствие, злоумышленники получили доступ к клиентским данным.
Очевидно, что недопустимо использовать полностью открытые облака без специализированных инструментов ИБ. Однако зачастую заказчик не в состоянии самостоятельно оценить уровень защищенности системы, а также выбрать, какие именно из многочисленных сервисов облачной безопасности провайдера использовать. Тут на помощь приходят готовые рецепты безопасности, средства автоматизации анализа уязвимостей как на традиционном уровне виртуальных машин и сети, так и на уровне контейнеров, а также средства автоматизации реагирования на инциденты. Учитывая вышесказанное, средства безопасности, предоставляемые облачным провайдером, должны быть всегда включены, просты в использовании и не приводить к дополнительным затратам, чтобы избежать компромиссов между ценой и безопасностью.
Опыт Oracle
Облачные сервисы Oracle сопровождаются дополнительными средствами защиты и мониторинга, которые сами по себе несут все необходимые рекомендации и автоматизируют ответы на инциденты. Например, опция зон максимальной безопасности (Maximum Security Zones) позволяет выделить инфраструктуру каждого клиента в дискретный логический слой, доступ неавторизованных лиц к которому просто невозможен, равно как невозможно случайно разместить конфиденциальные данные в открытой и незащищенной зоне облака. А опция Cloud Guard позволит выявить и автоматизированно устранить инциденты безопасности в вашей облачной инфраструктуре. Причем эти опции включаются в стоимость облака.
Более того, специальные облачные сервисы помогают обеспечить безопасность доступа к широкому спектру ресурсов с единым ID. Например, именно таким образом поступили в японской компании Ricoh. Глобальная корпорация значительно повысила общий уровень безопасности десятков внутренних и внешних ИТ-систем, внедрив облачную систему управления учетными записями и аутентификацией Oracle Cloud Identity Management.
Заключение
При этом нельзя забывать и про дополнительные инструменты киберзащиты. Например, для реального обеспечения безопасности важную роль играют такие сервисы, как мониторинг безопасности, система управления обновлениями ПО и, конечно, средства защиты, использующие искусственный интеллект для обнаружения еще неизвестных угроз. Заказчики, уже пострадавшие от инцидентов безопасности или оценившие с финансовой точки зрения риски ИБ, все чаще ищут облачных провайдеров, которые готовы предоставить им все необходимые инструменты одновременно с гарантиями безопасности облачных нагрузок.
Модель коллективной ответственности за облачную безопасность
Модель коллективной ответственности за безопасность облака предполагает разделение ответственности между поставщиком облачного решения и подписчиком на эти услуги. Четкое понимание этой модели имеет важное значение для защищенности данных, но, к сожалению, эта модель на сегодняшний день остается одной из наименее понятных концепций: только 8% директоров по информационной безопасности полностью осознают свою роль в обеспечении безопасности SaaS. Модель коллективной ответственности за безопасность устанавливает сферу ответственности поставщика облачных решений – поддержание безопасности и доступности услуги, а также ответственность клиента за обеспечение безопасного использования услуги, и обе стороны при этом берут на себя определенные обязательства.
Компаниям, пользующимся облачными сервисами, необходимо понимать свои обязанности, ведь отсутствие надлежащей защиты данных может привести к серьезным и дорогостоящим последствиям, и не путать "безопасность облака" с "безопасностью в облаке".
