Контейнеры в ИТ: почему это выгодно и как их защищать

Крупные информационные системы разрабатывают и эксплуатируют промышленными способами — у их создателей есть настоящий сборочный конвейер (он называется CI/CD pipeline), а в результате его работы приложение поставляется в виде контейнера, который передается службе ИТ для развертывания в инфраструктуре клиента.

Контейнер – это изолированная среда, в которой запускается единственное приложение. Контейнер легковеснее, чем виртуальная машина, но содержит все необходимое (компоненты, настройки) для запуска приложения. Поэтому в контейнерной инфраструктуре приложения быстрее развертывать и проще масштабировать. Это приводит к существенным экономическим выгодам: компании быстрее выпускают на рынок новые функции и лучше адаптируются к изменениям на рынке. Неудивительно, что более половины компаний Топ-500 РБК используют контейнеры, а например в финансовой сфере эта цифра достигает 78%.

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

Чем выгодны контейнеры в ИТ-системах и как они влияют на эффективность?

1. Высокая скорость развертывания. Программный код и его зависимости упаковываются в стандартный пакет (контейнер), который одинаково запускается в различных вычислительных средах. Поэтому установка приложений и обновлений может быть высоко автоматизирована, проходит более быстро и надежно. Стандартом де факто для упаковки приложения в контейнер является Docker. А публичные реестры контейнерных образов содержат тысячи «шаблонов», из которых можно развернуть нужное приложение или взять его за основу собственных разработок.

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

3. Экономическая эффективность. Поскольку контейнеры вычислительно дешевле виртуальных машин, на том же «железе» можно запускать больше приложений.

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

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

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

Контейнеры и микросервисы, как элементы головоломки, складываются в современную картину «промышленной» ИТ-разработки, а третьим важным ее элементом является методология непрерывной интеграции и развертывания (CI/CD, continuous integration, continuous delivery), помогающая выпускать обновления приложений быстрее и с меньшим числом ошибок, чем при сопровождении монолитного приложения. Этот подход предусматривает короткий цикл разработки, параллельную работу команд над одним кодом, автоматизацию рутинных действий. Применение контейнеризации в конвейере CI/CD повышает эффективность этого конвейера: система CI/CD использует образы контейнеров в качестве шаблонов и доставляет сборку в виде готового к развертыванию образа.

Ну а завершает головоломку четвертый фрагмент – безопасность. В числе этапов «ИТ-конвейера» есть различные тесты и проверки, поскольку тестирование – неотъемлемая часть выпуска ИТ-продукта. Но кроме безошибочной работы, в последнее время на конвейере проверяют также безопасность получившегося приложения. Это делается в рамках методологии DevSecOps, которая позволяет не просто автоматизировать ИТ-процессы, но и установить им нужную планку качества и безопасности. Контейнерная безопасность – не единственное, что требуется для построения DevSecOps; приложение должно пройти и другие виды анализа, чтобы считаться защищенным. Но защита контейнеров служит здесь необходимым базовым слоем, о котором стоит поговорить подробнее.

Что угрожает контейнерным средам

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

Полный список рисков и их систематизация по компонентам контейнерной инфраструктуры — на иллюстрации. Отметим, что риски эти не гипотетические. Например, зловреды неоднократно обнаруживались в Docker Hub (в самом известном случае были заражены более 1600 образов), а срок обнаружения ВПО в реестре достигал года. Известны вредоносные кампании, использующие Docker API для запуска «левых» контейнеров и майнинга на атакованных системах.

Даже если оставить зловредную активность за скобками, контейнеры — благоприятная среда для «забытых» уязвимостей. Образ контейнера может использоваться снова и снова, а в нем навсегда запечатана устаревшая версия популярного компонента — например, CURL или Apache Log4J. Пока образ не выпустят заново с новой, не подверженной уязвимости, версией компонента, все основанные на этом образе приложения продолжат быть уязвимыми.

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

Изоляция, которую создает система контейнеризации, как облегчает, так и затрудняет работу защитников. Средства защиты конечных точек, такие как системы поиска секретов и анализа уязвимостей, EDR, работающие на уровне компьютера, не могут полноценно сканировать содержимое контейнеров. Дело затрудняет многослойная структура образов контейнеров, которые часто основаны на других, «базовых» образах. Когда запущенные контейнеры обмениваются сетевым трафиком, это делается через виртуальный сетевой адаптер на уровне оркестратора, и этот трафик не контролируется межсетевыми экранами. Ну а главное – значительно возрастает количество ручных действий, которые нужно предпринять ИТ и ИБ, чтобы выполнить свою работу по защите. Поэтому для защиты контейнерных инфраструктур нужно специализированное решение, глубоко интегрированное с оркестратором, системой CI/CD и способное работать с запущенными контейнерами и их образами.

Как защищать системы контейнеризации

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

Одним из ключевых элементов системы защиты будет регулярная проверка образов. Корпоративные реестры образов, равно как и используемые публичные реестры (DockerHub, GitLab Registry, JFrog Artifactory, Harbor), должны сканироваться в соответствии с политиками организации. Используемые в компании образы, как минимум, проверяют на уязвимости и вредоносное ПО, но возможны и более детальные проверки — например, на соответствие лучшим практикам CIS Kubernetes.

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

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

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

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

Для продуктивной работы ИБ-специалистов защита контейнеров должна быть не просто комплексной, но и органично встроенной в общую ИБ-архитектуру компании. Например, в Kaspersky Container Security для этого предусмотрены интеграция с SIEM-системой и популярными каналами оповещений о найденных проблемах, возможность регулярного автоматического сканирования всех образов по обновляемой базе уязвимостей (NVD или БДУ), функциональность для временного принятия ИБ-рисков, а также детальное протоколирование административных событий.

Защита контейнеров в российских компаниях

Хотя контейнеризация, ее выгоды и угрозы – это общемировой тренд, использование контейнерных сред в российской инфраструктуре имеет свою специфику. Российские регуляторы накладывают достаточно жесткие требования по информационной безопасности (например приказ ФСТЭК России №118 от 4.07.2022 г.), а отечественные компании активно переходят на российские ОС. Поэтому, внедряя решение для контейнерной безопасности, нужно учитывать эти аспекты и, например, проверять уязвимости не только по западным базам данных, но и в БДУ, поддерживаемой ФСТЭК. Этим требованиям удовлетворяет Kaspersky Container Security, в том числе поддерживая образы на базе Astra Linux и РЕД ОС.

На иллюстрации — общая архитектура Kaspersky Container Security. Сканер регулярно проверяет образы контейнеров на всех этапах работы с ними, а агент, запущенный как отдельный контейнер под управлением оркестратора, обеспечивает защиту узлов в среде выполнения и безопасность среды оркестрации в целом. Центральный компонент Kaspersky Container Security обеспечивает интеграцию этих частей и позволяет их настраивать. Благодаря высокой производительности KCS способна эффективно защищать кластеры Kubernetes с сотнями нод.

Защита контейнеров глазами бизнеса

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

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

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

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