В современных крупных ИТ-системах широко применяются технологии виртуализации и контейнеризации. Контейнеры предоставляют множество преимуществ не только на этапе разработки программного обеспечения, но и при его эксплуатации и сопровождении. Такой подход ускоряет процессы разработки, снижает затраты и оптимизирует использование ресурсов.
Однако к контейнерам нельзя напрямую применять многие методы, которые используются для защиты виртуальных или физических серверов. Поэтому при внедрении контейнеризации в организации необходимо учитывать специфические риски и разрабатывать меры для обеспечения безопасности контейнерной инфраструктуры.
Мы решили поговорить с экспертами отрасли о защите контейнерных сред, попросили их рассказать об актуальных угрозах для основных элементов систем контейнеризации, об обеспечении защиты контейнерной инфраструктуры без применения специализированных СЗИ, о наиболее эффективных для защиты контейнерных сред СЗИ, о необходимых шагах по интеграции защиты контейнеров в процесс DevSecOps и о многом другом. На наши вопросы ответили:

Виктор Засорин, руководитель направления информационной безопасности департамента развития продуктовых направлений компании Axoft.
Дмитрий Евдокимов, основатель и технический директор Luntry.
Анатолий Карпенко, инженер по автоматизации Luntry.
Антон Шмаков, технический директор «Группы Астра».

Какие угрозы актуальны для основных элементов системы контейнеризации?
Дмитрий Евдокимов, основатель и технический директор Luntry:

Дмитрий Евдокимов, основатель и технический директор Luntry
«Сразу оговорюсь, что здесь и далее буду под контейнерными средами понимать Kubernetes, как стандарт де-факто среди оркестраторов в мире. Нужно понимать, что уровень контейниризации и оркестрации это дополнительные слои над железом, виртуализацией, хостовой ОС. Так что дополнительно к уже известным уровням и их угрозам добавляются новы. Но также же нужно иметь в виду, что эти новые уровни дают новые механизмы и инструменты, используя которые можно решить (и часто во много раз проще) те проблемы, что раньше без них было решить сложно или невозможно.

Сейчас добавилось безопасность образов, безопасность контейнеров, безопасность среды контейнеризации (Kubernetes), безопасность YAML файлов, которыми оперирует оркестратор, управление секретами, микросегементация между микросервисами, runtime контроль происходящего в контейнерах (на пример, обнаруживать побеги из контейнеров), собственная модель управления правами (RBAC). Отдельно стоит выделить момент с мультетенантностью (Multi-tenancy), так как важно правильно и безопасно разделать окружения между проектами и командами. Иначе компрометация одного проекта приведет к компрометации всех рядом стоящих».
Антон Шмаков, технический директор «Группы Астра»: «Система контейнеризации состоит из нескольких ключевых компонентов, каждый из которых нуждается в соответствующих средствах защиты. Образы контейнеров должны быть защищены от использования уязвимых или устаревших компонентов, также их надо проверять на предмет отсутствия вредоносного кода. Кроме того, потенциальным источником опасности могут стать неправильная конфигурация и избыточные разрешения для пользователей, процессов и приложений.
Для container runtime угрозой будет эксплуатация уязвимостей в системе изоляции контейнеров, атаки через общие ресурсы хоста, а также повышение привилегий и выход за пределы контейнера.
Потенциальной угрозой для оркестраторов, таких как Kubernetes, может стать неправильная и некорректная настройка ролевой модели доступа (RBAC). Также возможны атаки на компоненты оркестратора (etcd, API-server и т. д.).
Необходимо защищать не только компоненты системы контейнеризации по отдельности, но и применять комплекс мер на всех уровнях: безопасную конфигурацию, сканирование уязвимостей, контроль доступа, мониторинг и логирование.
В текущих условиях сетевой безопасности контроль трафика и взаимодействия между сервисами критически важен для защиты приложений от изменений и угроз. Следует мониторить входящий и исходящий трафик для выявления аномалий, обеспечивать целостность приложений и контейнеров с помощью многоуровневых стратегий защиты, безопасной разработки, обновлений и систем обнаружения вторжений. Важно учитывать, что защита секретов и учетных данных пользователей требует шифрования и надежного управления доступом для минимизации утечек информации».
Возможно ли обеспечить защиту контейнерной инфраструктуры без применения специализированных СЗИ?
Виктор Засорин, руководитель направления информационной безопасности департамента развития продуктовых направлений компании Axoft:

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

Антон Шмаков, технический директор «Группы Астра»: «Да, обеспечить базовый уровень защиты возможно и без применения специализированных средств защиты информации (СЗИ). Это можно сделать, используя встроенные механизмы безопасности. Например, встроенные средства безопасности Docker: пространства имен (namespaces) для изоляции, cgroups для ограничения ресурсов, capabilities для ограничения привилегий, seccomp для фильтрации системных вызовов.
Средства безопасности Kubernetes: RBAC (Role-Based Access Control), сетевые политики для контроля сетевого трафика, политики безопасности Pod (PodSecurityPolicies или PodSecurityStandards), а также etcd с шифрованием данных. Кроме того, можно использовать инструменты для сканирования образов на уязвимости (Trivy или Clair), а также инструменты мониторинга (Prometheus и Grafana) и логирования (Elasticsearch, Logstash, Kibana). Конечно, встроенные средства поддерживают безопасность сред контейнеризации на базовом уровне. На профессиональном все же рекомендуется использовать СЗИ, поскольку именно они позволяют комплексно защищать контейнерные среды на всех уровнях, начиная от уровня runtime и заканчивая сканирование финальных образов приложений».
Дмитрий Евдокимов, основатель и технический директор Luntry: «Нет. Контейнерные инфраструктуры — это свой мир, со своими правилами, спецификой и особенностями. И просто взять, и перенести то, что привыкли делать в Windows или Linux сетях, не получится. Ну точнее перенести можно, но это не будет эффективно работать и давать пользу. Например, классические EDR не знают ничего про образы контейнеров, про то как определять контейнеры и привязывать их к верхнестоящим абстракциям Kubernetes (типа Pod, ReplicaSet, Deployment, Namespace и т.д.). И в итоге у нас отсутствует контекст для происходящего.
Специализированные решения (Container Security Platform (CSP)) как раз дают контекст и все становится понятным и прозрачным. И во много раз уменьшается вероятность что вы примете решения на не полной информации и нанесете своей компании ущерб, когда захотите что-то остановить, запретить».
Какие СЗИ наиболее эффективны для защиты контейнерных сред?
Антон Шмаков, технический директор «Группы Астра», заявил, что поскольку зарубежные средства защиты информации не доступны заказчикам в нашей стране, то имеет смысл говорить об отечественных СЗИ для контейнерных сред, хотя их количество на российском ИТ-рынке пока меньше, чем на международном.
«Перечислю несколько. Kaspersky Container Security — это решение, которое обеспечивает безопасность контейнерных приложений на всех этапах жизненного цикла, защищает образы, созданные на основе российских ОС, таких как Astra Linux и РЕД ОС. Positive Technologies Application Firewall обеспечивает комплексную защиту веб-приложений, в том числе и тех, которые размещены в контейнерах. InfoWatch Traffic Monitor — распространенная в России система DLP, которая также имеет функции для мониторинга и защиты контейнерных сред.
Также не стоит исключать инструмент для компаний, стремящихся к цифровой трансформации Luntry. Это достаточно инновационное решение для управления данными и интеграции сервисов, которое дает возможность организациям эффективно анализировать информацию в реальном времени, оптимизировать бизнес-процессы и повышать продуктивность».
Дмитрий Евдокимов, основатель и технический директор Luntry: «Специализированные, собирающие все элементы контейнерной инфраструктуры в один контекст. Нужно из одного окна понимать какие процессы в каком контейнере, на базе какого образа, в каком YAML файле, для какого микросервиса, в каком кластере что делает. И в добавок к этому с оценкой на каждом этапе насколько это правильно, безопасно настроено и эксплуатируется, каие механизмы и практики по безопасности уже применены, чтобы правильно расчитывать риски и угрозы. Если это все у вас разрозненная информация он пару десятков независимых инструментов, то особой пользы от этого не будет – каждый из них покрывает только маленький аспект, без понимания целой картины.
Специализированные вам помогут и с образами, контейнерами, YAML файлами, RBAC, runtime, сетевой безопасностью – связывая все в единую картину».
Какие шаги по интеграции защиты контейнеров в процесс DevSecOps наиболее эффективны?
Анатолий Карпенко, инженер по автоматизации Luntry:

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

Или, например, композиционный анализ, в результате которого создаётся не только описание компонент (вместе с зависимостями), но также и список уязвимостей, которые присутствуют в компонентах. Аналогично можно говорить и про шаги защиты связанные с runtime.
Поэтому важно выстраивать сбалансированный процесс DevSecOps в котором различные этапы будут дополнять друг друга и в «статике», и в «динамике», тем самым обеспечивая комплексную защиту».
Какие меры защиты контейнерной инфраструктуры необходимо принимать на каждом этапе жизненного цикла, начиная с разработки и заканчивая эксплуатацией?
Антон Шмаков, технический директор «Группы Астра», уверен, что внедрять механизмы безопасности нужно уже на этапе разработки. Этот процесс включает в себя интеграцию инструментов статического анализа кода в IDE разработчиков, автоматическое сканирование зависимостей на уязвимости, использование безопасных базовых образов контейнеров и т. д. Следующий этап — проверка безопасности в CI/CD-пайплайнах. Он включает в себя сканирование образов контейнеров на уязвимости, проверку соответствия политикам безопасности, а также автоматическое подписание образов для обеспечения целостности.
«Хорошей практикой можно назвать внедрение принципа наименьших привилегий. Он подразумевает запуск контейнеров от имени непривилегированных пользователей, плюс использование политик безопасности Kubernetes. Эффективным будет и внедрение динамического анализа безопасности (DAST), что подразумевает автоматическое тестирование развернутых приложений на уязвимости, а также интеграцию результатов в процесс разработки для быстрого исправления ошибок. Во время выполнения необходимо использовать средства мониторинга аномального поведения и инструменты для блокировки подозрительной активности».
Какие меры безопасности необходимо принимать для защиты Docker-демона и операционной системы хоста, чтобы минимизировать риски компрометации контейнеров?
Анатолий Карпенко, инженер по автоматизации Luntry: «По нашему опыту системы без оркестратора контейнеров (Kubernetes) встречаются все реже и можно назвать устаревшими. Ввиду этого и инструментов и подходов для их обеспечения не так много.
Касаемо хостовой системы docker-демона. Хостовая система должна быть минималистична. Чем меньше компонент в ОС, тем меньше поверхность атаки.
Существует несколько «тонких» специализированных дистрибутивов ОС, которые предназначены для запуска контейнеризированных приложений, но все они «заточены» под Kubernetes. Примерами таких операционных систем являются Talos Linux, Fedora CoreOS, RancherOS. Если возможно, то процесс должен строится поверх иммутабельных (неизменяемых) ОС, когда сама хостовая машина неизменяема, а обновление компонент происходит через обновление неизменяемого образа.
Для Docker-демона основными мерами являются ограничение доступа пользователей к Docker-сервису к сокету Docker. Обязательно должно быть настроено логирование событий как в случае событий на хосте, так и в случае событий конкретно Docker-демона».
Антон Шмаков, технический директор «Группы Астра», указал на то, что для защиты Docker-демона необходимо предпринять ряд мер безопасности. Прежде всего, важно ограничить доступ к Docker-сокету, используя Unix-сокет вместо TCP, настроив правильные разрешения на сокет-файл и применяя TLS для шифрования соединений при использовании TCP.
«Следует также настроить аутентификацию и авторизацию, используя плагины авторизации Docker и интегрируя систему с управлением идентификацией и доступом (IAM). Регулярное обновление Docker, включая установку последних патчей безопасности и мониторинг уведомлений о безопасности, является критически важным для поддержания защищенности системы. Ограничение возможностей контейнеров, а также запрет на запуск контейнеров в привилегированном режиме помогут снизить риски. Наконец, настройка ресурсных лимитов, ограничивающих использование CPU, памяти и дискового пространства контейнерами, обеспечит дополнительную защиту и стабильность системы.
Что касается защиты контейнеров на уровне ОС, Astra Linux предоставляет комплексный набор встроенных средств защиты информации, которые эффективно обеспечивают безопасность контейнеров. Мандатный контроль доступа (МКД) позволяет назначать метки безопасности контейнерам и их ресурсам, обеспечивая строгое разграничение доступа на основе уровней конфиденциальности. Механизм замкнутой программной среды (ЗПС) ограничивает запуск только разрешенных приложений в контейнерах, предотвращая выполнение вредоносного кода. Контроль целостности проверяет файлы и компоненты контейнеров, обнаруживая несанкционированные изменения. Механизмы криптографической защиты обеспечивают шифрование данных контейнеров при хранении и передаче, защищая от несанкционированного доступа. Встроенный межсетевой экран фильтрует сетевой трафик контейнеров, защищая от сетевых атак. SELinux предоставляет дополнительное разграничение доступа на уровне системы, изолируя контейнеры друг от друга и от хост-системы. Использование этих встроенных СЗИ Astra Linux в сочетании с правильной настройкой Docker значительно повышает безопасность контейнеризованных приложений, обеспечивая комплексную защиту на различных уровнях».
Какие особенности безопасности необходимо учитывать при использовании контейнерных оркестраторов, таких как Kubernetes, и какие угрозы они привносят?
Виктор Засорин, руководитель направления информационной безопасности департамента развития продуктовых направлений компании Axoft: «Kubernetes – продукт, разработанный компанией Google в 2014 году, переданный в Open Source (Cloud Native Computing Foundation), не обеспечивает защиту контейнерной среды. По сути, это оркестратор, позволяющий легко создавать, удалять контейнеры и поддерживать работоспособность контейнерной среды. Так как он находится в Open Source-сообществе, он подвержен высокой опасности в части киберинцидентов – каждый может изучить досконально продукт, найти в нем уязвимости и впоследствии использовать для целенаправленных атак.
Аналогию можно провести с операционными системами на базе Linux: как только операционная система набирает популярность у пользователей, находятся «специалисты», которые «разбирают» ее на мелкие составляющие в части безопасности и выявленные уязвимости используют в своих корыстных целях. Поэтому отдельных особенностей Kubernetes я бы не выделял, а относился к нему в целом как к продукту, которому необходима защита».
Дмитрий Евдокимов, основатель и технический директор Luntry: «С появлением любой новой технологии появляются и новые задачи по их безопасности. Kubernetes тут не исключение. Еще Kubernetes уникален тем, что это декларативная система, практически полностью состоящая из YAML файлов. И валидация, контроль этих YAML файлов это львиная доля безопансоти в Kubernetes. Для классического специалиста по безопасности такое может показаться странным и очень непривычным, но это так.
Для контроля YAML файлов даже есть специальный класс решение, который называется PolicyEngine. Это просто must have инструмент для любой Kubernetes инфраструктуры. При этом он будет полезен как для задач ИБ, так и для задач ИТ.
Другой специфичный момент, который хотелось бы отметить при использовании контейнерных сред, то малый срок жизни контейнеров – они часто запускаются, перезапускаются из-за обновлений или скейлинга. Ввиду, этого всегда нужно понимать, что происходит внутри контейнера иначе вы не сможете обнаружить атакующего.
Сигнатурный подход обнаружения в контейнерах не работает. Каждый контейнер свой маленький уникальный мир. Подробно мы об этом рассказывали и показывали на SOC-форум 2023 в докладе «EDR vs Containers: актуальные проблемы».
Антон Шмаков, технический директор «Группы Астра», отметил, что при использовании контейнерных оркестраторов необходимо учитывать ряд важных аспектов безопасности и потенциальных угроз. Это, прежде всего, расширенная поверхность атаки, обусловленная дополнительными компонентами и сервисами оркестраторов, которая увеличивает количество потенциальных векторов атаки. Сложность конфигурации – еще один риск, поскольку она требует глубокого понимания. Неправильная конфигурация может привести к серьезным уязвимостям. Управление секретами становится критически важным, поскольку необходимо обеспечить безопасное хранение и распространение чувствительных данных, избегая рисков утечки при неправильном управлении.
«Сетевая безопасность представляет особую сложность из-за необходимости контроля взаимодействия между контейнерами и подами, что требует тщательной настройки сетевых политик и сегментации. Контроль доступа к кластеру и его ресурсам является ключевым аспектом безопасности, так как слабая аутентификация может привести к неавторизованному доступу. Регулярные обновления и патчи компонентов оркестратора и контейнеров важны для предотвращения использования уязвимых версий ПО. Обеспечение надежной изоляции между контейнерами и подами необходимо для минимизации рисков утечки данных или атак через общие ресурсы».
Какие подходы и технологии используются для обеспечения сетевой безопасности в контейнерных средах?
Антон Шмаков, технический директор «Группы Астра»: «Нужен целый комплекс подходов и технологий. Сегментация сети играет ключевую роль, позволяя разделить среду на изолированные сегменты с помощью виртуальных сетей и сетевых политик Kubernetes. Шифрование трафика обеспечивает защиту коммуникаций между сервисами с помощью TLS, а также безопасный внешний доступ через VPN.
Контроль доступа к сети реализуется через ограничение доступа к портам и сервисам, использование ACL и принципа наименьших привилегий. Мониторинг сетевого трафика, включающий анализ потоков данных и применение систем обнаружения вторжений, позволяет своевременно выявлять и реагировать на угрозы. Защита от DDoS-атак обеспечивается комбинацией облачных сервисов, ограничения скорости и автоматического масштабирования ресурсов. Безопасность DNS укрепляется с помощью DNSSEC, приватных DNS-серверов и фильтрации запросов. Управление идентификацией и доступом интегрируется с внешними системами аутентификации и использует многофакторную аутентификацию и ролевой доступ».
Дмитрий Евдокимов, основатель и технический директор Luntry: «Очень многие департаменты информационной безопасности хотят тут воткнуть какой-нибудь аппаратный firewall, но в Kubernetes в сети свои правила и подобные решения там абсолютно не эффективны. Чисто для справки IP адрес у микросервисов можно сказать динамический, переходящий и в разные моменты времени может принадлежать разным сервисам – доверия ему нет.
В Kubernetes для обеспечения безопасности на сетевом уровне обычно используют 2 решения: NetworkPolicy и политики ServiceMesh.
NetworkPolicy можно сказать как раз и является родным для Kubernetes межсетевым экраном. По сути, это (как и все в Kubernetees) YAML файл, где по принципу whitelist прописывается какой микросервис с каким микросервисом может общаться и каким способом (с L3 по L7). То есть с его помощью можно сделать хорошую микросегементацию в кластере. В разных реализация NetworkPolicy, что зависят от Container Network Interface (CNI) плагина, возможности могут варьироваться и это нужно учитывать: кто-то умеет в L7, blacklist и приоритезацию правил, а кто-то нет. Но все равно это самый правильный путь для работы по безопасности сети в Kubernetes.
Политики ServiceMesh могут помочь реализовать как шифрование трафика, взаимную аутентификацию и контроль доступа на L7. Но тут сразу появляется приличный оверхед на вычислительные ресурсы и их надо заранее закладывать. Но данные решения не стоят на месте и развиваются, и вопрос с ресурсами в ближайшем будущем должен быть решен.
Можно еще упомянуть Ingress, Egress, API Gateway, но это в основном про публикацию сервисов наружу и их общение с внешним миром, что тоже важно для задач ИБ. Прекрасно что это все декларативно в виде YAML и достаточно просто валидируется и пишется».
Как организовать эффективное управление доступом и привилегиями в контейнерных средах?
Дмитрий Евдокимов, основатель и технический директор Luntry: «Тут на помощь приходить 3 вещи:

Identity and Access Management (IAM).
Privileged Access Management (PAM).
Role Base Access Control (RBAC).

Благодаря первому классу решений мы централизованно можем управлять и контролировать всех пользователей что взаимодействуют с системой и при этом уже заведены в компании в том же ActiveDirectory.
Второй класс решений позволяет контролировать действия привилегированных пользователей. И часто в компаниях это сочетается с MFA, выделенными jump хостами с дополнительными контролями.
Переходя к стадии авторизации, то в Kubernetes встроенный механизм управления правами RBAC. Тут задача отдела безопасности контролировать, аудировать права и следовать принципу наименьших привелегий».
Антон Шмаков, технический директор «Группы Астра» дал несколько рекомендаций. Основополагающим принципом является использование наименьших привилегий, что подразумевает запуск контейнеров с минимально необходимыми правами, ограничение их доступа к хост-системе и применение режима read-only там, где это возможно. Изоляция контейнеров достигается путем использования сетевых namespace для изоляции сетевого стека, применения cgroups для ограничения ресурсов и настройки security contexts в Kubernetes.
Как обеспечить безопасность контейнерных образов на этапе их создания и хранения?
Виктор Засорин, руководитель направления информационной безопасности департамента развития продуктовых направлений компании Axoft: «Это один из самых моих любимых вопросов, а также вопрос, вызывающий живые дискуссии среди моих коллег. Есть два пути решения этой задачи:

Скачивать образы, проверять их на НДВ (не декларированные возможности), затем тестировать на стенде и пускать в «продакшн».
Создавать образы самостоятельно. Это трудно, затратно и не гарантирует 100% защиты от НДВ, но дает больше уверенности, что НДВ не внедрены на этапе сборки образа. Далее также необходимо использовать СЗИ для тестирования образов операционных систем.

Для хранения готовых образов можно использовать свой собственный доверенный репозиторий, который либо находится в закрытом контуре, либо имеет налагаемые средства защиты информации».
Дмитрий Евдокимов, основатель и технический директор Luntry: «Если оставить за скобками уже всем хорошо известные задачи, связанные со сканированием образов с CI/CD и в image registry на SBOM, известные уязвимости, вредоносный код, соответствию лучшим практикам dockerfile и поиск секретов / чувствительной информации в слоях образа, то тогда, нужно и важно сказать про использование тонких / минималистичных базовых образов (возможно вы слышали про scratch, distroless, chainguard образы), в которых отсутствует все лишнее, что не требуется для работы приложения. Это позволяет радикально снизить поверхность атаки (уменьшается и количество false positive результатов от сканеров) и сильно усложнить жизнь атакующему, которому в таком окружении будет тяжело (а порой и не возможно) закрепиться и / или развить свою атаку дальше.
А также, любой pipeline сборки с амбициями на безопасность должен заканчиваться подписью данного образа. Чтобы в дальнейшем в окружении запускались только те образы, которые прошли все внутренние проверки и никакие другие».
Антон Шмаков, технический директор «Группы Астра»: «Начиная с этапа создания образов, важно использовать минимальные базовые образы, например, на основе ОС Astra Linux, чтобы уменьшить поверхность атаки. Регулярное обновление базовых образов и зависимостей помогает устранить известные уязвимости. Применение инструментов статического анализа кода и сканирования уязвимостей поможет выявить потенциальные проблемы безопасности на ранних стадиях. Внедрение процесса подписи образов обеспечивает подтверждение их подлинности, а использование многоэтапной сборки помогает минимизировать конечный размер образа.
На этапе хранения образов главная мера — это ограничение доступа к реестру контейнеров. Для этого используются политики аутентификации и авторизации, шифрование образов при хранении, а также исключение факта использования непроверенных или устаревших образов. Для защиты данных и секретов рекомендуется использовать специализированные системы управления секретами. Подобные продукты выпускают «Лаборатория Касперского», «КриптоПро», «Аладдин Р.Д.» и другие российские ИБ-вендоры. Всегда можно узнать, совместимо ли то или иное решение с Astra Linux, по наличию сертификата программы технологического партнерства Ready for Astra. Важно реализовать динамическое внедрение секретов в контейнеры во время выполнения, а не хранить их в образах. Шифрование данных в состоянии покоя и при передаче, а также использование временных учетных данных с ограниченным сроком действия дополнительно усиливают безопасность».
Какие методы и инструменты наиболее эффективны для защиты данных и секретов внутри контейнерных сред?
Дмитрий Евдокимов, основатель и технический директор Luntry: «По нашим клиентам и аудитам Kubernetes кластеров можно точно сказать, что большие и средние компании для работы с секретами выбирают инструмент HashiCorp Vault. Помимо того, что они его используют не только в контейнерных средах, так он практически единственный позволяет решить все необходимые задачи по работе с секретами.
Тут мы понимаем: выставлять короткий срок жизни, производить периодическую ротацию, проводить отзыв, передавать по защищенным каналам и напрямую доводить до runtime приложения. Также в его механизмах на сегодняшний день есть как pull, так и push стратегии, что добавляет вариативности при использовании для тех или иных команд или проектов».
Виктор Засорин, руководитель направления информационной безопасности департамента развития продуктовых направлений компании Axoft, убеждён, что нет разницы – контейнерная среда или облачная, виртуализированная или просто сервер с операционной системой. Защита необходима в любом случае.
«Часто я слышу, что заказчики предпринимают компенсационные меры, то есть защищают не целое приложение / сервис, а только базу данных с чувствительными данными, каналы передачи данных. Я считаю, что этого недостаточно для эффективной защиты. Необходим комплексный подход: применять налагаемое средство защиты нужно и для базы данных, и для каналов передачи данных, и для приложений».
Как эффективно проводить аудит и сканирование контейнеров на предмет уязвимостей?
Виктор Засорин, руководитель направления информационной безопасности департамента развития продуктовых направлений компании Axoft: «На российском рынке представлено достаточно большое количество решений по классу VM (Vulnerability Management – управление уязвимостями), но выбор самих сканеров уязвимостей невелик. Поэтому многие компании в рамках аудита используют мультивендорные решения. Например, применяют продукт VM от одного вендора, а сканер – от другого. И даже если у VM-решения сканер есть, данные со «второго» сканера «сливают» в VM. И уже далее отрабатывают все найденные уязвимости.
У контейнеров, как и у обычных систем, имеется большое количество уязвимостей, которые вносят в свой реестр MITRE, а также ФСТЭК России. Регулятор ведет банк данных уязвимостей, где можно найти все известные на данный момент угрозы, база постоянно обновляется, поэтому информация об уязвимостях появляется в ней оперативно.
Суммируя вышеизложенное, для проведения аудита и сканирования контейнеров на предмет уязвимостей рекомендую использовать несколько решений от разных вендоров – помимо VM применять еще отдельный сканер, который позволит более детально «покопаться» в вашей инфраструктуре».
Дмитрий Евдокимов, основатель и технический директор Luntry: «Говоря про мониторинг известных уязвимостей в образах контейнеров, надо сразу смериться с двумя мыслями:

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

Тут можно рассказать про Shift Left / Everywhere Security, сканирование в CI/CD, сканирование в image registry и runtime, настройку Security / QualityGate и т.д. Это все хорошо и правильно, но на практике все равно в любой момент времени есть сервисы с известными уязвимостями. И при этом чтобы их закрыть командам нужно время. И, следовательно, у атакующего всегда есть время (и оно на него стороне), чтобы этим воспользоваться.
При этом по нашему опыту взаимодействия с клиентами из абсолютно разных отраслей от металлургической до финансовой, проблема не в сканировании, обнаружении уязвимостей. А в том, что их много, очень много, а людей мало и остро стоит вопрос приоритезации закрытия этих уязвимостей. И тут важно понимать свою инфраструктуру, чтобы приоритезировать».
Как защитить контейнерные среды от атак на уровне ядра операционной системы, включая эксплуатацию уязвимостей ядра?
Дмитрий Евдокимов, основатель и технический директор Luntry: «Kubernetes и его экосистема прекрасна тем, что для решения одной и той же задачи может предлагать множество решений. И вопрос с уязвимостями ядра хостовой ОС не является исключением.
Можно выделить три направления:

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

Для первого это будут механизмы и подходы: AppArmor профили, rootless контейнеры, distroless образы, альтернативные container runtime на базе sandbox или виртуализации. Для второго это будут механизмы и подходы: SeLinux профили, seccomp профили, специализированные ОС для контейнерных сред.
И само собой обновления ядра хостовой ОС является важным моментом.
Конечно, у каждого из способов есть свои сильные и слабые стороны, некоторые можно сочетать, а некоторые, наоборот, не сочетаются совсем».
Виктор Засорин, руководитель направления информационной безопасности департамента развития продуктовых направлений компании Axoft: «Берем решение от ФСТЭК России – банк данных уязвимостей, находим уязвимости уровня ядра и закрываем их в соответствии с рекомендациями регулятора. Как правило, достаточно бывает «закрыть порт», даже не применяя налагаемые средства защиты данных. Если уязвимость требует более серьезного «вмешательства», можно использовать альтернативные решения, например, иную хостовую операционную систему».
Какие рекомендации вы можете дать организациям, только начинающим внедрять практики защиты контейнерных сред и интегрировать их в существующие процессы безопасности?
Антон Шмаков, технический директор «Группы Астра»: «Первым делом важно оценить все риски. Это позволит адаптировать существующие процессы безопасности к новым реалиям и выявить потенциальные уязвимости. Далее нужно сформировать кросс-функциональную команду, объединяющую специалистов по безопасности, разработке и эксплуатации в рамках подхода DevSecOps. Это обеспечит всесторонний взгляд на безопасность контейнеров и поможет выработать эффективные стратегии защиты. Следующим важным шагом станет разработка базовых стандартов безопасности для контейнеров, включающих требования к минимальным базовым образам, правила конфигурации, политики управления секретами и стандарты сетевой изоляции. Важно развернуть инструменты автоматизированного сканирования на предмет уязвимостей, а также реализовать принцип наименьших привилегий, о чем уже говорилось выше. Сетевые политики Kubernetes помогут предотвратить несанкционированный доступ и распространение угроз, поскольку они обеспечивают изоляцию сети между контейнерами.
Среди прочих мер можно упомянуть обучение персонала, в частности, действиям при нештатных ситуациях, проведение пилотных проектов и регулярный аудит безопасности. Это общие меры для обеспечения ИБ, и в отношении контейнерных сред они также актуальны».
Дмитрий Евдокимов, основатель и технический директор Luntry: «Не начинайте с прямолинейного закрытия проблем. Сначала увидьте и поймите свою инфраструктуру. Все контейнерные среды уникальные ввиду, того, что строятся из множества различных частей. В результате получается уникальная поверхность атаки, уникальные модели нарушителя и т.д. Все начинается с инвентаризации. Нельзя защитить, то, что вы до конца не видите – атакующий обязательно воспользуется этими слепыми зонами.
Если экспертизы в данной области в компании немного, то обратите внимание на CIS Kubernetes Benchmark. И обязательно на все его 5 разделов (в 4 и 5 собрано все самое важное), а не только на те, что будут реализованы в OpenSource инструментах. Иначе у вас сложиться не правильная картина».
Виктор Засорин, руководитель направления информационной безопасности департамента развития продуктовых направлений компании Axoft: «Как можно больше читать, изучать продукты, которые вам предлагают, не бояться навредить своей инфраструктуре, так как безопасность – это очень важный фактор! Еще один совет – не надеяться на «авось». Кейсы успешных атак на отечественные компании подтверждают – многие организации строят безопасность на уровне «ну кто нас тронет, кому мы нужны?». Вот именно такой подход нужно исключить изначально. Не стоит думать, что ваша компания никому не интересна или «авось нас не тронут». Вас «тронут». И вы этого можете даже не заметить, так как целью атаки может быть компания, в которой вы являетесь подрядчиком или с которой имеете общие каналы связи. Поэтому, чтобы не понести материальные и/или репутационные потери, не следует пренебрегать безопасностью. И последний важный аспект – это бюджет. Используя Open Source-решения, вы должны помнить о рисках киберинцидентов. Поэтому обязательно найдите бюджет на информационную безопасность, чтобы после атаки ваши ИТ- и ИБ-специалисты не перекладывали ответственность друг на друга, а по факту никто из них не оказался виноватым. Ведь потери будет нести ваш бизнес».