Быстро, но не всегда безопасно // Эксперты «Лаборатории Касперского» о рисках контейнерной разработки
Большинство из нас заказывают через приложения еду, слушают музыку, переводят деньги. Но немногие задумываются о том, как устроены такие приложения, и насколько они безопасны. Чаще всего они разрабатываются по принципу микросервисов, которые «упаковываются» в контейнеры. Это относительно новая технология, имеющая как свои достоинства, так и уязвимости. Почему её безопасности нужно уделять особое внимание, рассказывают эксперты «Лаборатории Касперского».
Старые угрозы — новые вызовы
Пользователи наверняка много слышали о традиционных атаках с использованием вредоносного ПО. С помощью него злоумышленники могут получить несанкционированный доступ к устройству, похитить персональные или финансовые данные. Также злоумышленники для атак пользуются различными уязвимостями — в программном обеспечении, операционной системе, процессорах.
Один из ярких примеров — бэкдоры. Это «дыра» в коде, которая позволяет в него внедриться и затем, как вариант, перехватить управление устройством. Бэкдор могут оставлять как злоумышленники, так и разработчики ПО — например, чтобы у них была возможность принять меры, если заказчик не оплачивает услуги. А ещё бэкдоры могут появляться случайно. В частности, от того, что в коде нарушилась логика, и разработчик этого не заметил. Но зато это может обнаружить злоумышленник и использовать для проникновения в систему. Злоумышленники также могут проникнуть в систему, если, например, неправильно настроены политики доступа — введены недостаточные ограничения на аутентификацию или авторизацию. На языке обычных пользователей это можно сравнить с ненадёжным паролем или отключенной двухфакторной аутентификацией.
Часть этих рисков актуальна и для контейнерной разработки. Это относительно новая технология, которая быстро завоёвывает популярность. При этом в отличие, например, от операционных систем, механизмы защиты которых уже хорошо налажены, безопасности контейнерных сред стали уделять внимание не так давно.
Что такое микросервисы и контейнеризация
Многие приложения сейчас разрабатываются на основе микросервисной архитектуры — это способ разработки, при котором разные функции одного большого приложения выделяются в отдельные, независимые друг от друга микросервисы. В качестве примера можно привести музыкальный плеер внутри социальной сети или заказ авиабилетов внутри банковского приложения.
Такие микросервисы могут поставляться в виде контейнеров. В образ контейнера входит как приложение, так и необходимые ему настройки и вспомогательные компоненты. Эта технология упрощает как сам процесс разработки, так и дальнейшее развёртывание продукта. Одно из важнейших преимуществ контейнерной разработки — независимость контейнеров и приложений/кода внутри них друг от друга. Если что-то случится с одним контейнером, это не приведёт к обрушению всей системы.
Контейнеризация может использоваться в любых отраслях — телекоммуникации, ритейл, страхование, банковский, финансовый сектор и т. д. Это могут быть как привычные нам потребительские сервисы — доставка еды, онлайн-банки, прогноз погоды, видео- и аудиоплееры, покупка билетов, так и более сложные промышленные и бизнес-решения — сканирование товаров на складах, программы для контроля оборудования, корпоративный мессенджер.
Контейнеры активно используются и для разработки защитных решений в области кибербезопасности. Например, на контейнерной архитектуре построена SIEM-система Kaspersky Unified Monitoring and Analysis Platform.
Почему безопасности контейнерных сред нужно уделять особое внимание
Одно из главных преимуществ контейнерной разработки — возможность быстро создавать и выпускать на рынок продукты. Однако сервисы, которые создаются с её помощью, не всегда проходят тщательную проверку с точки зрения кибербезопасности.
Для компаний очень важен Time to Market (время от момента создания продукта до начала продаж). Любая дополнительная проверка замедляет сроки выхода продукта на рынок, что критично для бизнеса. Поэтому из-за сжатых сроков на безопасность может просто не хватать времени. Также контейнерной разработкой пользуются небольшие компании и стартапы, у которых зачастую просто не хватает ресурсов на кибербезопасность. Для них основная задача — побыстрее вывести продукт на рынок и получить первых заказчиков.
На этапе разработки проверить продукт на безопасность тоже удаётся не всегда. Главная задача разработчика — написать свою часть кода и закрыть задачу. Безопасность кода часто не входит в обязанности специалиста, если только в организации не введён специальный KPI или практики безопасной разработки (DevSecOps). Проверкой приложения в данном случае занимается служба ИБ, если она есть, либо же надёжность и безопасность используемых инструментов остаются без внимания. А ещё на исследование может просто не остаться времени — опять же в связи со сжатыми сроками.
Однако из-за кибератак компании могут столкнуться с большими финансовыми и репутационными потерями, особенно если речь идёт о крупных компаниях и промышленных предприятиях. При этом уязвимости могут быть в каждом из компонентов контейнерной инфраструктуры: образах, реестрах образов, оркестраторах, контейнерах и ОС хоста.
С подобными проблемами столкнулась компания Tesla. В 2018 году злоумышленники проникли через незащищённую консоль администратора в оркестраторе Kubernetes (открытое ПО для автоматизации развёртывания, масштабирования и управления контейнеризированными приложениями) и использовали мощности компании для майнинга. А у одной из отечественных авиакомпаний в открытом доступе оказался реестр образов контейнеров, использовавшихся в работе сайта. Реестр образов — один из главных компонентов контейнерной инфраструктуры (в нём хранятся шаблоны, из которых потом создаются контейнеры). По сути, в реестр мог проникнуть любой желающий и потом, например, нарушить работу системы покупки билетов, регистрации на рейс, получить персональные данные. Для этого можно загрузить в него вредоносный образ, из которого потом могут сделать контейнер. Если вовремя его не обнаружить, с его помощью злоумышленник проникнет в инфраструктуру компании. Кстати, самый популярный реестр — Docker — это open source-проект, его возможностями активно пользуются злоумышленники.
Почему старые методы защиты не работают
Для обеспечения безопасности контейнерных продуктов не подходят традиционные решения, так как у контейнеров нет собственной операционной системы — они используют ОС хоста. Поэтому в них, например, нельзя установить агент безопасности виртуальной машины. Как следствие, у обычных решений есть серьёзные ограничения: это отсутствие анализа и контроля ошибок в конфигурации оркестратора, интеграции с процессами разработки, реестрами образов, CI/CD и оркестраторами, визуализации компонентов контейнерных сред. При этом нужно учитывать, что компаниям важно не снижать Time to Market, поэтому безопасность нужно очень грамотно встраивать в процесс разработки.
Чтобы решить эту проблему, «Лаборатория Касперского» разработала специализированное решение для защиты контейнерных сред — Kaspersky Container Security, в котором учтены все эти особенности. Оно помогает защитить все компоненты контейнерной инфраструктуры, при этом его легко интегрировать в процесс разработки. Решение способно заменить зарубежные аналоги (например, продукты Aqua Security и Palo Alto) и при этом обладает дополнительной функциональностью, необходимой для нашего российского рынка. Также оно предоставляет возможность сканирования по Банку данных угроз ФСТЭК России, обеспечивает защиту в рантайме (когда приложение уже запустили), поддерживает отечественные операционные системы Astra Linux и РЕД ОС.
***
Контейнеры значительно упрощают разработку — с их помощью можно быстрее создавать удобные, современные сервисы, которыми будут пользоваться тысячи людей. Но чтобы эта технология приносила только пользу, важно не забывать о безопасности — и для этого сейчас есть все возможности.