Сравнение Cloud-Native подходов к обеспечению безопасности облачных сервисов

Ответственность за обеспечение безопасности в облаке распределяется между службой безопасности поставщика облачных услуг (CSP) и корпоративной службой ИБ. Чтобы они могли обеспечить нормативно-правовое соответствие, видимость и контроль в рамках всего стека приложений, поставщики облачных услуг и решений в сфере безопасности добавили различные инновационные подходы на разных уровнях. Эксперт McAfee сравнил и проанализировал эти подходы.

Эксперт: Сергей Меньшаков, инженер-пресейл направления McAfee

Краткий обзор

Поставщики облачных услуг (CSP) с головокружительной скоростью запускают новые сервисы, чтобы разработчики корпоративных приложений быстрее выводили на рынок новые решения для бизнеса. CSP берут на себя всё больше и больше ответственности за обеспечение безопасности каждого из этих сервисов, позволяя корпоративным службам безопасности сосредоточиться на приложении. Чтобы иметь возможность обеспечивать видимость и безопасность, а также совершенствовать существующие инструменты в таких разнообразных и быстро меняющихся средах, CSP подключают журналы регистрации событий, API (программный интерфейс приложения), облачно-ориентированных (Cloud Native) агентов и другие технологии, которые могут использоваться корпоративными службами безопасности.

Подходы

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

1. API и журналы регистрации событий – оптимальный подход для выявления уязвимостей облачных учетных записей и обнаружения в них аномальной активности, которая представляет интерес для служб безопасности. С помощью этих механизмов можно легко получить доступ к данным различных учетных записей, при этом всё, что требуется сделать службам безопасности — это получить мультиаккаунтный доступ к многочисленным учетным записям в организации. Такой подход обеспечивает отличную видимость, но его необходимо дополнить методиками защиты.
2. Анализ изображений и моментальных снимков состояния (снапшотов) является эффективным подходом для получения более подробных данных о рабочих нагрузках как до запуска приложений, так и в процессе их выполнения. В рамках этого метода снапшот диска действующей системы может быть проанализирован для обнаружения любых аномалий, уязвимостей, инцидентов из-за ошибок конфигурации и т.д. Снапшоты предоставляют подробные данные о рабочих нагрузках, но могут не выявить ОЗУ-резидентные проблемы, например, бесфайловые вредоносные программы. Кроме того, когда мы переходим к приложениям без данных, использование периодического анализа снимков может быть ограничено. Этот механизм может быть непригоден для облачных сервисов, для которых невозможно получить снапшоты. Данный подход предоставляет глубокие данные снапшотов, но должен быть дополнен какими-либо методами защиты.
3. Облачно-ориентированные агенты и скрипты являются эффективным подходом для обеспечения повышенной видимости и управляемости. Они предоставляют простой способ совершенствования cloud-native агентов, таких как SSM, на виртуальной машине. В зависимости от их функциональности агенты могут потреблять много ресурсов. Поддержка облачно-ориентированных агентов ограничена предоставляемыми CSP возможностями, например, поддержкой операционных систем или предоставляемыми функциями. Во многих случаях cloud-native агенты запускают команды, которые регистрируют необходимую информацию, что подразумевает параллельную работу средств регистрации данных.
4. Контейнеры DaemonSet и Sidecar представляют собой подход к простому развертыванию агентов в контейнерных и бессерверных средах. Sidecar позволяет запускать один контейнер для каждого пода, предоставляя большие данные. Однако, он использует большое количество ресурсов и имеет высокую стоимость из-за того, что несколько sidecar-контейнеров работают на одном сервере. Они могут использоваться в бессерверных контейнерных моделях, в которых не применимы наборы DaemonSet. Поскольку функциональные возможности Sidecar и DaemonSet аналогичны функциям агентов, многие из упомянутых ограничений агентов применимы и в их случае.
5. Подход с использованием агентов обеспечивает максимальную видимость и наиболее эффективный контроль над средой, в которой работает приложение — за счет запуска кода, который находится в памяти одновременно с приложением. Однако этот подход сложнее, поскольку службам безопасности необходимо заранее иметь в наличии средства глубинного обнаружения (Deep Discovery), чтобы иметь возможность развертывать эти агенты. Сложности также могут возникнуть при добавлении агентов, поскольку они должны работать на каждой машине, а у службы безопасности отсутствуют права на запуск программного обеспечения на каждой машине, особенно в облаке. В зависимости от поддерживаемых вариантов, использование ресурсов и стоимость решения могут быть высокими. Новые технологии, например, Extended Berkley Packet Filters (eBPF или расширенные пакетные фильтры Berkley) позволяют сократить использование ресурсов агентами, чтобы сделать их пригодными для более широкого использования.
6. Подход «встроенный в образ/встроенный в код» позволяет встроить средства обеспечения безопасности в развернутый образ приложения. Это позволяет развертывать функциональные элементы безопасности без необходимости развертывания агента с каждой рабочей нагрузкой. Данный подход обеспечивает высокую видимость работы приложения и пригоден даже для бессерверных приложений. Компиляция кода создает серьезные дополнительные трудности из-за необходимости добавлять код в процессе сборки программного продукта, а библиотеки кода должны быть доступны на каждом языке функционального программирования.

Заключение

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

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

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