В современных крупных ИТ-системах широко применяются технологии виртуализации и контейнеризации. Контейнеры предоставляют множество преимуществ не только на этапе разработки программного обеспечения, но и при его эксплуатации и сопровождении. Такой подход ускоряет процессы разработки, снижает затраты и оптимизирует использование ресурсов.
Однако к контейнерам нельзя напрямую применять многие методы, которые используются для защиты виртуальных или физических серверов. Поэтому при внедрении контейнеризации в организации необходимо учитывать специфические риски и разрабатывать меры для обеспечения безопасности контейнерной инфраструктуры.
Мы решили поговорить с экспертами отрасли о защите контейнерных сред, попросили их рассказать об актуальных угрозах для основных элементов систем контейнеризации, об обеспечении защиты контейнерной инфраструктуры без применения специализированных СЗИ, о наиболее эффективных для защиты контейнерных сред СЗИ, о необходимых шагах по интеграции защиты контейнеров в процесс DevSecOps и о многом другом. На наши вопросы ответили:
- Виктор Засорин, руководитель направления информационной безопасности департамента развития продуктовых направлений компании Axoft.
- Дмитрий Евдокимов, основатель и технический директор Luntry.
- Анатолий Карпенко, инженер по автоматизации Luntry.
- Антон Шмаков, технический директор «Группы Астра».
Какие угрозы актуальны для основных элементов системы контейнеризации?
Дмитрий Евдокимов, основатель и технический директор Luntry:
«Сразу оговорюсь, что здесь и далее буду под контейнерными средами понимать Kubernetes как стандарт де-факто среди оркестраторов в мире. Нужно понимать, что уровень контейнеризации и оркестрации — это дополнительный слой над железом, виртуализацией, хостовой ОС. Так что к уже известным уровням и их угрозам добавляются новые. Но также нужно иметь в виду, что эти новые уровни дают новые механизмы и инструменты, используя которые можно легко решить — те проблемы, что раньше без них было решить сложно или невозможно.
Сейчас добавились безопасность образов, контейнеров, среды контейнеризации (Kubernetes) и YAML файлов, которыми оперирует оркестратор, управление секретами, микросегментация между микросервисами, runtime-контроль происходящего в контейнерах (например, обнаружить побеги из контейнеров), собственная модель управления правами (RBAC). Отдельно стоит выделить момент с мультитенантностью (Multi-tenancy), так как важно правильно и безопасно разделять окружения между проектами и командами. Иначе компрометация одного проекта приведет к компрометации всех рядом стоящих».
Антон Шмаков, технический директор «Группы Астра»: «Система контейнеризации состоит из нескольких ключевых компонентов, каждый из которых нуждается в соответствующих средствах защиты. Образы контейнеров должны быть защищены от использования уязвимых или устаревших компонентов, также их надо проверять на предмет отсутствия вредоносного кода. Кроме того, потенциальным источником опасности могут стать неправильная конфигурация и избыточные разрешения для пользователей, процессов и приложений.
Для container runtime угрозой будет эксплуатация уязвимостей в системе изоляции контейнеров, атаки через общие ресурсы хоста, а также повышение привилегий и выход за пределы контейнера.
Потенциальной угрозой для оркестраторов, таких как Kubernetes, может стать неправильная и некорректная настройка ролевой модели доступа (RBAC). Также возможны атаки на компоненты оркестратора (etcd, API-server и т. д.).
Необходимо защищать не только компоненты системы контейнеризации по отдельности, но и применять комплекс мер на всех уровнях: безопасную конфигурацию, сканирование уязвимостей, контроль доступа, мониторинг и логирование.
В текущих условиях сетевой безопасности контроль трафика и взаимодействия между сервисами критически важен для защиты приложений от изменений и угроз. Следует мониторить входящий и исходящий трафик для выявления аномалий, обеспечивать целостность приложений и контейнеров с помощью многоуровневых стратегий защиты, безопасной разработки, обновлений и систем обнаружения вторжений. Важно учитывать, что защита секретов и учетных данных пользователей требует шифрования и надежного управления доступом для минимизации утечек информации».
Возможно ли обеспечить защиту контейнерной инфраструктуры без применения специализированных СЗИ?
Виктор Засорин, руководитель направления информационной безопасности департамента развития продуктовых направлений компании 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:
«Каждый добавленный шаг по защите контейнеров закрывает собой решение отдельных проблем. В процессе на начальном этапе могут присутствовать различные линтеры и статические анализаторы для 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 не исключение. Он уникален тем, что представляет собой декларативную систему, практически полностью состоящую из 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 межсетевым экраном. По сути, как и все в Kubernetes, это 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-решения, вы должны помнить о рисках киберинцидентов. Поэтому обязательно найдите бюджет на информационную безопасность, чтобы после атаки ваши ИТ- и ИБ-специалисты не перекладывали ответственность друг на друга, а по факту никто из них не оказался виноватым. Ведь потери будет нести ваш бизнес».
Оригинал публикации на сайте CISOCLUB: "Защита контейнерных сред".
Смотреть публикации по категориям: Новости | Мероприятия | Статьи | Обзоры | Отчеты | Интервью | Видео | Обучение | Вакансии | Утечки | Уязвимости | Сравнения | Дайджесты | Прочее.
Подписывайтесь на нас: VK | Rutube | Telegram | Дзен | YouTube | X.
