Cloud Native Security: как устроена безопасность облачных приложений

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

Об актуальности этой темы лучше всего говорит тот факт, что в 2022 году почти половина утечек данных была связана с облаками. До этого компания Redhat сообщала, что почти 60% компаний сталкивались с инцидентом, связанным с неправильной конфигурацией в средах Kubernetes.

Необходимость в в новых стратегиях безопасности привела к появлению Cloud Native Security (CNS) —  комплексного подхода к защите облачных данных, приложений и инфраструктуры. Эта методология призвана обеспечить безопасность с самого начала процесса разработки до поставки продукта пользователям, автоматизируя рабочие процедуры, выстраивая многоуровневую защиту и постоянный мониторинг для обнаружения новых уязвимостей.

Александр Зубриков

Генеральный директор ITGLOBAL.COM Security

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

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

Сергей Полунин

Руководитель группы защиты инфраструктурных ИТ компании «Газинформсервис»

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

На чем основана Cloud Native Security

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

Станислав Навсегда

Руководитель отдела сетевой безопасности и аудита компании Axoft

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

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

Непрерывная интеграция/непрерывное развертывание (continuous integration/continuous delivery, CI/CD). Конвейеры CI/CD обеспечивают быстрое и автоматизированное развертывание исправлений и обновлений безопасности.

Лука Сафонов

Технический директор компании Weblock (входит в холдинг «Гарда»)

[Необходимо] внедрить в CI/CD пайплайн к SAST (Static Application Security Testing — тестирование «белого ящика», которое позволяет разработчикам находить уязвимости безопасности в исходном коде приложения на ранних этапах жизненного цикла разработки ПО) и DAST (Dynamic Application Security Testing — тестирование «черного ящика», может обнаруживать уязвимости и слабые места в работающем приложении), парадигму RASP (Run-time Application Security Protection – технология обнаружения и блокировки атаки на приложения в реальном времени с помощью функций защиты в среде исполнения).

Александр Буравцов

Директор по информационной безопасности компании «МойОфис»

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

Сергей Полунин

Руководитель группы защиты инфраструктурных ИТ компании «Газинформсервис»

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

Контейнеризация ПО. Cloud Native Security использует контейнеризацию для защиты и изоляции данных и приложений.

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

Соответствие стандартам безопасности. Cloud Native Security изначально создавалась с учетом лучшего мирового опыта по безопасности, включая ISO 27001.

Четыре принципа облачной безопасности

Разработчики Kubernetes предлагают выстраивать безопасность облачной инфраструктуры на четырех уровнях: облако, кластер, контейнер, код. На английском эта концепция получила название 4C от Cloud, Cluster, Container, Code.

1. Облако (Cloud). Интерфейс облачного уровня взаимодействует с внешними средами, включая сторонние подключаемые модули, пользователей и внешние API. Таким образом, уязвимости системы безопасности на облачном уровне существенно повлияют на все приложения, службы и процессы, размещенные в облаке.
2. Кластер (Cluster). В современных облаках приложения разбиваются на модули и группируются по контейнерам. На этом уровне обеспечение безопасности включает в себя защиту самих приложений и создание безопасной конфигурации для потоков данных в кластере.
3. Контейнер (Container). Этот слой разработчики Kubernetes называют наиболее важным с точки зрения безопасности облачных приложений. Если преступникам удастся подменить содержимое контейнера, они смогут разом атаковать все инфраструктуры, которые в дальнейшем развернут его у себя.
4. Код (Code). Технологии защиты на уровне кода объединены в практиках DevSecOps. Их основная цель — чтобы команда использовала безопасные методы, начиная с самых ранних этапов разработки. Это позволяет компании выявлять уязвимости как можно быстрее, сокращая свои затраты на их устранение с точки зрения времени и ресурсов.

Денис Бандалетов

Руководитель группы защиты корпоративных сетей передачи данных Angara Security

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

Специфические уязвимости Cloud Native Security

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

Александр Зубриков

ITGLOBAL.COM Security

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

Николай Щербатенко

Руководитель продукта факультета программирования Университета «Синергия»

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

Во-первых, дорого. Во-вторых, нужно правильно выставить окружение. В-третьих, правильно подобрать параметры.

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

Вот некоторые распространенные уязвимости Cloud Native Security, которые необходимо учитывать.

Неправильно настроенные контейнеры. Как мы говорили выше, безопасность контейнеров — одна из ключевых задач при создании облачных приложений. В мире Cloud Native легко запускать новые веб-серверы и создавать новые контейнеры. Без внимания к ИБ разработчики могут, например, оставить доступ к сети, позволяя всем желающим подключиться к приложению и внести свои изменения.

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

Ольга Карпова

Руководитель отдела по информационной безопасности RooX

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

Небезопасные значения по умолчанию. Не все инструменты и приложения Cloud Native безопасны «из коробки», поскольку некоторые из них имеют гибкие конфигурации. По данным компании Accurics, 48% инцидентов безопасности в облачных приложениях связаны именно с небезопасными настройками по умолчанию.

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

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

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

Это далеко не полный список угроз. В 2022 году некоммерческая организация Open Web Application Security Project (OWASP) опубликовала первый рейтинг уязвимостей приложений Kubernetes, куда вошли и проблемы аутентификации, и ошибки логирования и мониторинга, и другие часто встречающиеся пробелы безопасности. Представители организации призвали ИБ-специалистов, системных администраторов и разработчиков использовать этот рейтинг, чтобы контролировать риски в Kubernetes-экосистемах. 

Денис Бандалетов

Руководитель группы защиты корпоративных сетей передачи данных Angara Security

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

Традиционные средства ИБ в облаках

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

Сергей Полунин

Руководитель группы защиты инфраструктурных ИТ компании «Газинформсервис»

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

Денис Бандалетов

Руководитель группы защиты корпоративных сетей передачи данных Angara Security

Статические файрволы и системы предотвращения вторжений становятся менее эффективными в среде Cloud Native из-за ее динамичности, распределенности и автоматизации. Они не могут эффективно справляться с непрерывными изменениями в конфигурации и трафике. Вместо них Cloud Native требует более гибких и автоматизированных инструментов безопасности: микросегментация сети, средства защиты на основе идентификации и управления доступом (IAM) и контейнерная безопасность.

Сергей Стариков

Эксперт по созданию архитектур приложений в компании EPAM Systems

Новые средства безопасности включают в себя:

• Zero Trust Security: подход к безопасности, который не доверяет никаким сущностям внутри или снаружи сети и требует строгой проверки подлинности и авторизации для любого доступа к данным или ресурсам.
• Service Mesh: слой инфраструктуры, который обеспечивает надежное и безопасное взаимодействие между микросервисами в облаке с помощью шифрования, балансировки нагрузки, трассировки и мониторинга.
• DevSecOps: подход к разработке, который интегрирует безопасность во все этапы жизненного цикла приложения от проектирования до развертывания и поддержки.
• Cloud Security Posture Management (CSPM): процесс постоянного мониторинга и улучшения конфигурации и политик безопасности в облаке с помощью автоматизации и аналитики.

• Cloud Workload Protection Platform (CWPP): решение для защиты облачных рабочих нагрузок от вредоносного ПО, атак и утечек данных с помощью антивирусов, брандмауэров, инспекции трафика и анализа поведения.

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