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

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

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

Виртуальные машины подвержены тем же проблемам безопасности, что и их пустые аналоги, и в некоторой степени проблемы безопасности контейнеров отражают проблемы безопасности их составных частей: ошибка MySQL в конкретной версии апстрим-приложения затронет и контейнерные версии. Что касается виртуальных машин, «пустых» установок и контейнеров, то проблемы и действия в области кибербезопасности очень похожи. Однако развертывание контейнеров и их инструментарий создают особые проблемы безопасности для тех, кто занимается запуском приложений и сервисов, будь то ручная сборка приложений с помощью контейнеров или их запуск в производстве с помощью оркестровки в масштабе.

Риски безопасности, характерные для контейнеров

• Неправильная конфигурация: Сложные приложения состоят из множества контейнеров, и неправильная конфигурация — часто всего одна строка в файле .yaml — может предоставить ненужные привилегии и увеличить площадь атаки. Например, хотя злоумышленнику несложно получить root-доступ к хост-машине из контейнера, все еще слишком распространена практика запуска Docker от имени root, например, без ремаппинга пространства имен пользователя.
• Уязвимые образы контейнеров: В 2022 году Sysdig обнаружил в Docker Hub более 1600 образов, идентифицированных как вредоносные, в дополнение к множеству контейнеров, хранящихся в репозитории с жестко закодированными учетными данными облака, ключами ssh и токенами NPM. Процесс извлечения образов из публичных реестров непрозрачен, а удобство развертывания контейнеров (плюс давление на разработчиков, требующее быстрого получения результатов) может означать, что приложения могут быть легко созданы с изначально небезопасными или даже вредоносными компонентами.
• Уровни оркестровки: Для крупных проектов инструменты оркестровки, такие как Kubernetes, могут увеличить площадь атаки, как правило, из-за неправильной конфигурации и высокого уровня сложности. Исследование 2022 года, проведенное компанией D2iQ, показало, что только 42 % приложений, работающих на Kubernetes, попали в производство — отчасти из-за сложности администрирования больших кластеров и крутой кривой обучения.

По словам Ари Вейла из Akamai, «Kubernetes уже развита, но большинство компаний и разработчиков не понимают, насколько сложной […] она может быть, пока не начнут работать в масштабе».

ОНЛАЙН-ПРАКТИКУМ

ЗАПУСК DEEPSEEK R1 ЛОКАЛЬНО НА СВОЕМ КОМПЬЮТЕРЕ

ЧТО БУДЕТ НА ОБУЧЕНИИ?

• ПОКАЖЕМ, КАК РАЗВЕРНУТЬ МОДЕЛЬ DEEPSEEK R1 ПРЯМО НА СВОЁМ КОМПЬЮТЕРЕ
• Где и как применять? Потестируем модель после установки на разных задачах
• Как дообучить модель под себя?

Участвовать бесплатно

Безопасность контейнеров с помощью машинного обучения

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

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

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

Заключение

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

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