Защита облачных сервисов и приложений
Информационные сервисы все больше абстрагируются от платформенных мощностей. Пользователь хочет сузить круг своей ответственности до уровня необходимых ему сервисов, забыв о программном обеспечении и платформе для их функционирования. Вслед за IaaS- и PaaS-услугами развивается рынок SaaS-, FaaS-, fPaaS-, CaaS-услуг и микросервисов — все они являются разными уровнями абстракции получаемого клиентом сервиса.
Многие предприятия проявляют активный интерес к подобным сервисам ввиду сокращения инвестиций по сравнению с on-premises-решениями и отсутствия платформенных издержек. Вслед за инновационными компаниями такими сервисами заинтересовался малый бизнес, финансовая и другие отрасли.
Пользователь SaaS, FaaS, fPaaS, CaaS получает желаемые услуги, не задумываясь о среде их функционирования, инфраструктуре и нагрузках. Аппаратная часть существует, имеет привычную реализацию, но вопросы ее работы полностью отдаются провайдеру услуги: в его компетенции вопросы распределения нагрузки на систему, масштабирования и отказоустойчивости, организации защиты инфраструктуры, ее регулярное обновление, вопросы физического функционирования.
Ниже рассмотрим, в чем разница понятий SaaS, FaaS, fPaaS, CaaS, когда и зачем нужны эти решения, какие плюсы, минусы и риски они несут, какие средства информационной безопасности (ИБ) имеются на рынке.
О SaaS/FaaS/fPaaS/CaaS и бессерверных приложениях
SaaS — это программное обеспечение как услуга — модель обслуживания, при которой подписчикам предоставляется готовое прикладное ПО, полностью обслуживаемое провайдером. Поставщик в этой модели самостоятельно управляет приложением, предоставляя заказчикам доступ к функциям с клиентских устройств, как правило, через мобильное приложение или веб-браузер.
Что характерно для этой модели: пользователь получает конкретный готовый набор услуг, он не может дописать и добавить необходимую ему функцию. Отчасти доступен механизм фиче-реквеста, а он, как известно, требует финансовых обоснований, roadmap-а и прочих замедляющих внедрение механизмов. Таким образом, услуга удобна, если необходим стандартный набор сервисов, например, электронная почта или файлообменные сервисы.
Примеры популярных сервисов по модели SaaS: Office 365, Gmail, Box, Dropbox, Google Drive, Microsoft SharePoint online, Microsoft OneDrive for business, Microsoft Teams.
Для активно цифровизирующегося предприятия часто требуются более гибкие услуги — отсюда появление модели FaaS, или, более известных в среде разработки, «бессерверных приложений». Функцией является среда для разработки и запуска приложения заказчика, например, Python, Java, Go, PHP-приложения или база данных. То есть вы сами можете создать необходимую функцию или ПО в уже готовой для этого среде.
В качестве примеров сервисов по модели FaaS (бессерверные приложения) можно назвать Google App Engine, Yandex Cloud Functions, AWS Lambda, Microsoft Azure Data Lake (база данных).
Вроде все удобно, но возникает другое неприятное свойство — платформозависимость. FaaS-платформы имеют конкретную реализацию «под капотом», и она не стандартизована. Поэтому, разработав приложения под конкретную FaaS-платформу, вы не сможете мигрировать ее на другую платформу. По сути, понадобится переписать все приложение заново. Таким образом, появилась потребность в более гибкой услуге.
CaaS — Container as a Service (или иногда этот вариант сервиса называют fPaaS — function PaaS) — вариант реализации функции в виде контейнера, где провайдер предоставляет среду для его функционирования и механизмы вызова и запуска функции. Контейнеры являются платформонезависимыми в рамках одного семейства платформ (Linux, Windows), включают в пакет все необходимые зависимости и поэтому обладают свойством быстрой миграции и копирования и, соответственно, легко масштабируемы. При этом пакетируется, по сути, необходимая функция, это не виртуальный сервер, каким мы привыкли его видеть в PaaS.
Популярные формы контейнеризации: Docker, LXC, Rocket. Популярные провайдеры fPaaS (CaaS) сервисов: Google Container Engine (GKE), Amazon EC2 Container Service (ECS), Azure Container Service (ACS).
Плюсы
Высокий уровень абстракции дает свои преимущества, общие для всех обозначенных моделей сервисов:
-
Вопросы функционирования платформы и ПО больше не находятся в зоне ответственности пользователя. Провайдер обеспечивает физические, платформенные и нагрузочные потребности, техническую поддержку.
-
В интересах провайдера осуществлять регулярные своевременные установки патчей на компоненты платформы, особенно обновлений Critical Security. Для SaaS- и FaaS-сервисов обновление программной среды также находится в круге обязанностей провайдера.
-
Как правило, большинство атак направлено на саму платформу, например, Remote Code Execution (RCE-инъекция) или атаки на переполнение буфера. Поскольку функционирование платформы находится в зоне ответственности провайдера, реагирование на подобные атаки также становится его необходимостью. Провайдер услуг обычно имеет больше экспертов и технических возможностей для эффективного обнаружения и реагирования на угрозы ИБ, чем заказчик.
-
Учитывая репутационные риски провайдера сервиса и требования по даунтайму (скорее всего, выше требований заказчика), защита от DDoS-атак также находится в зоне интересов провайдера.
Каждый вид сервиса имеет свои плюсы. В SaaS это:
-
скорость внедрения сервиса становится рекордной, так как не требуется развертывания системы on-premises;
-
мультиплатформенность сервиса, простота интерфейса — как правило, это веб-сервис с предсказуемым ограниченным набором «кнопок»;
-
высокий уровень обслуживания ПО за предсказуемые инвестиции.
В CaaS (fPaaS):
-
в комбинации с микросервисами, контейнеры позволяют организовать микросегментацию — для каждого микросервиса отдельная среда исполнения;
-
платформонезависимость в рамках одной реализации контейнера (Docker) и одного семейства ОС (а здесь инвариантность небольшая: Linux, Windows), возможность дополнять контейнер необходимыми сервисами, в том числе агентами защиты.
В FaaS:
-
быстрота развертывание сервиса;
-
перенос проблемы обновления и патчинга ОС и ПО на провайдера, отсутствие необходимости в системных администраторах на стороне заказчика.
Минусы и риски ИБ
Чем меньше у пользователя механизмов работы со средой функционирования желаемого сервиса, тем проще и надежнее работа для провайдера и самого сервиса. Такая методология имеет свои удобства, но несет и определенные риски ИБ, в частности:
-
Активнее используются HTTP API, подключаются внешние источники (внешние сервисы сообщений, облачные хранилища и т.д.) и, таким образом, расширяется поверхность атаки.
-
И для заказчика, и для провайдера становится сложнее обнаружение и диагностирование атак, анализ рисков. Модель разделенной ответственности вносит свою запутанность.
Для FaaS дополнительно характерны следующие проблемы:
-
Vendor Lock — сервисы FaaS используют определенный нестандартизированный набор функций (библиотеки, хранилища и др.), который крайне редко может быть повторен полностью в альтернативном FaaS-сервисе. То есть приложение, написанное или адаптированное под конкретный FaaS-ресурс, не может быть перенесено на другой ресурс без дополнительной адаптации, требующей значительной переработки исходного кода продукта.
-
Сложно реализовать полноценное тестирование продукта, полноценное антивирусное сканирование.
Для CaaS дополнительно характерны следующие риски ИБ:
-
Встраивание вредоносного ПО в цепочку поставки. Поскольку эта цепочка многоступенчатая, существуют риски публичного репозитория, зависимостей пакетов, наследования уязвимого кода, использования open-source-продуктов.
-
Длительность процедуры антивирусного сканирования при развертывании контейнера.
С точки зрения SaaS:
-
Легкость проникновения и в связи с этим появление теневых неконтролируемых сервисов — Shadow IT, — которое чревато утечками конфиденциальной информации.
-
Ограниченность функционала, невозможность его самостоятельного расширения, добавления функций ИБ.
Средства и методы защиты
В схеме SaaS/FaaS защита инфраструктуры сервиса возложена на провайдера. Если вы используете сервис от крупного провайдера, то у него гарантированно реализованы базовые механизмы защиты, мониторинга и реагирования, отказоустойчивости, резервного копирования и восстановления систем. Например, об архитектуре ИБ облачных сервисов Google можно почитать по ссылке: https://cloud.google.com/security/infrastructure/design/. Но защита контента сервиса остается прерогативой пользователя, будь то почтовая переписка, файлы на файловом ресурсе или исходный код приложения.
Многие SaaS- и FaaS-провайдеры предлагают встроенные механизмы защиты — например, Advanced Threat Protection у Microsoft Office 365. Они реализуют минимально необходимый набор функций защиты, но, как правило, неглубокой и недостаточно кастомизируемый. Другой пример — Google App Engine предлагает встроенные механизмы межсетевого экранирования (включая DDoS-фильтр) и Google Cloud Security Scanner — сканер приложения.
Возможно использование перенаправления трафика через свой фильтрующий узел. В частности, защита почтового потока через дополнительный фильтрующий хоп. Для веб-приложений — применение WAF-решений в качестве reverse-proxy. На своем узле вы можете организовать любые необходимые политики фильтрации, аналогично традиционным методам. Но такой вариант сложно организуем с точки зрения маршрутизации и может привести к появлению «узкого горла» (BottleNeck) в лице контент-шлюза.
Специализированные решения по обеспечению ИБ
Какими продуктами, представленными на рынке, можно минимизировать свои риски при использовании облачных сервисов уровня SaaS/FaaS/fPaaS/CaaS:
-
В случае с SaaS — это Cloud Access Security Brocker (CASB).
-
Вариант fPaaS или CaaS можно защитить с помощью решения Cloud Workload Protection Platform (CWPP).
-
В случае с бессерверными приложениями или FaaS пользователь может использовать статический анализ кода и API Gateway.
В случае CASB интеграция с облачными продуктами производится через Representational State Transfer (REST) APIs и не требует перенаправления e-mail-трафика или использования веб-прокси. Либо добавляется узел и интегрируется в роли прямого или реверс-прокси. Оптимальный вариант — использование гибридной инсталляции. CASB позволяет осуществлять сканирование входящего и исходящего почтового потока от вредоносного ПО, применять политики безопасности. Решение выполняет следующие основные функции:
-
Мониторинг и аудит. Отслеживание Shadow IT — использование сторонних сервисов. Под Shadow IT понимаются ИТ-устройства, ПО и сервисы, которые присутствуют в организации, но не обслуживаются ИТ-отделом. Они не стоят на балансе ИТ-отдела, их состояние и работа не контролируются, более того, ИТ-департамент может вообще ничего о них не знать. К ним относятся Amazon AWS, GPC, amoCRM и другие сервисы.
-
Защита от фишинговых атак и фишинговых URL. Иногда дополнительный анализ и обнаружение атак типа Business Email Compromise (BEC) с использованием искусственного интеллекта (AI) и машинного обучения.
-
Поиск и блокирование известного вредоносного ПО, включая скрытые эксплойты. Иногда поиск неизвестного вредоносного ПО механизмами машинного обучения, анализ файлов в «песочнице», внутренние техники обнаружения обфускаций.
-
Реализация функций Data Loss Prevention (DLP), в том числе для ресурсов файлового обмена.
Рис. 1. Функции CASB в режиме реверс-прокси
Рис. 2. Функции CASB в режиме прямого прокси
Рис. 3. Функции CASB в режиме API-интеграции
Многие провайдеры SaaS-услуг предоставляют нативную интеграцию с известными CASB-решениями в режиме API. В основном поддерживаются все популярные провайдеры сервисов: Office 365, Gmail, Box, Dropbox, Google Drive, Microsoft SharePoint online, Microsoft OneDrive for business, and Microsoft Teams.
Примеры решений: Trend Micro Cloud App Security, FortiCASB, Check Point CloudGuard SaaS.
Вариант fPaaS или CaaS можно защитить с помощью решения Cloud Workload Protection Platform (CWPP). В зависимости от реализации конкретного производителя и варианта исполнения (агентский или безагентский — привилегированный контейнер в рамках облака), решения CWPP выполняют следующие основные функции:
-
Анализ на появление вредоносного ПО внутри контейнера. Причем акцент делается на поведенческий анализ как более оперативный, чем полное сканирование системы.
-
Сканирование образа контейнера на уязвимости и проблемы конфигурации до его публикации. Выявление проблем до применения контейнера, поиск по базе CVE и формирование предложений по устранению проблем.
-
Hardening OS — процесс выявления и устранения излишних сервисов или привилегий в ОС и в пакетах приложений (отключение Telnet, FTP, root ssh и др.).
-
Защита сетевых взаимодействий: межсетевое экранирование и микросегментация, шифрование трафика.
-
Контроль целостности системы (в режимах preboot или postboot) и контроль приложений, вплоть до режима «белого списка» (whitelist).
-
Непрерывный мониторинг и аудит.
-
Защита среды исполнения Runtime и системных вызовов.
-
Deep Packet Inspection для сетевого трафика.
На рис. 4 представлена иерархия функций CWPP-решения, по мнению Gartner, в соответствии с приоритетом: внизу пирамиды — наиболее приоритетные функции, вверху — опциональные.
Рис. 4. Иерархия функций платформ CWPP согласно Gartner
Решения CWPP поддерживают гибридные варианты облачной среды исполнения, включая и контейнеры, и виртуальные среды, и аппаратные реализации.
Примеры решений: Trend Micro Deep Security Smart Check, Qualis Container Security, Palo Alto Networks Container Security Suit (former Twistlock).
В случае с бессерверными приложениями или FaaS пользователь может применить статический анализ кода специализированными продуктами: Micro Focus Fortify Static Code Analyzer, Checkmarx CxSAST, IBM Security AppScan Source, Эшелон AppChecker, PT Application Inspector, InfoWatch Appercut, RT-Solar appScreener. Также предусмотрено использование API Gateway, например, The Netflix API (Java Application) или самописных вариантов.
Часто в компании присутствует весь спектр облачных услуг, с добавлением к SaaS (приложение как сервис) более привычных IaaS (Infrastructure as a Service) или PaaS. Для гибридного облачного варианта нужны более универсальные средства защиты. Gartner в своем исследовании средств защиты облачных сред называет их Cloud Security Posture Management (CSPM) — защита и мониторинг соответствия (Compliance Monitoring) для услуг IaaS (PaaS).
CSPM-решения по функционалу являются вершиной пирамиды и располагаются над облачными сервисами, CASB- и CWPP-решениями.
Рис. 5. Решения по защите облачных сред по версии Gartner
Большинство успешных атак на облачные ресурсы обусловлено ошибками их конфигурации, поэтому основной функционал CPSM, необходимый для защиты, — это анализ рисков и ошибок конфигурации. Функционал средств CSPM также включает:
-
Механизмы по управлению и оркестрации в облачной среде, оптимизации ресурсов и инвестиций (Provisioning & Orchestration, Cost Management & Resource Organization).
-
Средства миграции, резервного копирования и восстановления данных, инвентаризации.
-
Управление учетными записями, защитой и комплаенсом.
-
Мониторинг, аналитика, аудит и тикетная система (Service Requests).
Рис. 6. Функции CSPM-решений
Выводы
Каждая из рассмотренных моделей облачных сервисов имеет свои технологические и инвестиционные плюсы и занимает свою нишу на рынке. Однако, независимо от выбранной заказчиком модели, провайдер услуги должен помнить о необходимости дополнения сервиса функциями защиты от угроз ИБ. С этой точки зрения эффективной стратегией предоставления сервисов, минимизирующей риски простоев, репутационные издержки и негативное влияние на бизнес заказчиков, является проектирование систем защиты, разработка планов реагирования на инциденты ИБ, а также привлечение для внедрения профессиональных команд исполнителей.
Смотреть все статьи по теме "Информационная безопасность"
Опубликовано 11.11.2019
