Журнал "Information Security/ Информационная безопасность" #2, 2025

Идеальная система контейнерной без- опасности должна обеспечивать защиту всех компонентов контейнерной инфра- структуры и сопровождать приложение на каждом этапе его жизненного цикла, начиная от разработки и заканчивая эксплуатацией. Во-первых, контейнерная безопасность должна включать в себя статический ана- лиз всех контейнерных образов, находя- щихся в инфраструктуре. Неважно, где именно эти образы размещены – в локаль- ных или внешних реестрах, в нескольких хранилищах одновременно или раздельно. Все объекты, составляющие эти образы, должны быть проверены на наличие уязви- мостей и других рисков. Во-вторых, необходимо интегрировать проверки на безопасность в процессы CI/CD, если таковые в компании выстрое- ны. Согласно исследованиям 1 , только у трети всех организаций организован пол- ноценный цикл внутренней разработки. Но если говорить об эталонном решении, то интеграция в CI/CD – обязательна. Вхо- дящие в сборку образа объекты (SBOM) должны анализироваться на всех этапах, а затем, уже после перехода к фазе conti- nuous delivery, необходимо контролировать, какие именно образы запускаются. Третьим и, пожалуй, самым объемным направлением является обеспечение безопасности на этапе эксплуатации. Когда приложение или сервис уже запу- щены, важно следить за их состоянием и устранять возникающие риски. Наконец, красной нитью через всю систему контейнерной безопасности про- ходит необходимость регулярных про- верок и сканирования самих оркестра- торов, кластеров, реестров и всех сопут- ствующих сущностей. Именно такое понимание контейнер- ной защиты реализовано в Kaspersky Container Security. Ключевые угрозы и векторы атак Когда организация приступает к ана- лизу рисков своей контейнерной инфра- структуры, разумнее всего опираться на регуляторные требования – приказ ФСТЭК России № 118 2 от 4 июля 2022 г., ГОСТ Р 56939–2024 "Защита информа- ции. Разработка безопасного программ- ного обеспечения. Общие требования" 3 , а также на другие авторитетные мате- риалы, в частности, Application Container Security Guide от NIST 4 . В документе от NIST предлагается логич- ная модель, в которой вся контейнерная инфраструктура разделена на несколько ключевых компонентов: образы, реестры, оркестраторы, запущенные контейнеры и хостовые операционные системы. В каж- дом из этих компонентов существуют риски ИБ: например, ошибки конфигурации (mis- configurations), которые могут встречаться на всех уровнях и представляют собой серьезные бреши в безопасности. Есть и более специфические риски, например, связанные с отсутствием должного контроля сетевой активности. Нельзя забывать и о кибергигиене: поли- тике управления доступами, паролями и учетными записями. Эти задачи могут решаться и без специализированных решений класса контейнерной безопас- ности, но их наличие, безусловно, суще- ственно упрощает поддержание защи- щенной инфраструктуры. Для анализа векторов атак важно обратиться к матрице MITRE. Существу- ет как общая матрица атак, так и ее специализированная версия для кон- тейнерных сред 5 . Обе дают подробное представление о наиболее распростра- ненных методах атак. Из наиболее часто встречающихся угроз как в российских, так и в между- народных кейсах стоит выделить: l нарушение изоляции и побег из кон- тейнера; l инъекции вредоносного кода на этапе сборки образа и через базовые образы; l удаленное выполнение скриптов и команд в запущенных контейнерах. В качестве иллюстрации стоит вспом- нить случай с компанией Tesla, когда в контейнерной инфраструктуре незамет- но для команды продолжительное время работали скрытые майнеры – типичный пример атаки на цепочку поставок. Дополнительная защита на уровне Kubernetes На практике интеграция проверки без- опасности на этапе CI/CD часто сталки- вается с проблемами. Владельцем кон- вейера является разработчик, который, обладая необходимыми правами, может отключить проверочные механизмы, осо- бенно в компаниях, где культура без- опасной разработки пока не отлажена. В результате код может пройти в экс- плуатацию без должной проверки. Чтобы предотвратить такие сценарии, на более поздних этапах добавляются дополнительные механизмы защиты на уровне Kubernetes. С помощью admission- контроллеров можно проверять манифе- сты развертываемых контейнеров и их настройки, а также проверять факт про- хождения предыдущих этапов безопасно- сти. Здесь активно применяются меха- низмы цифровой подписи образов, чтобы убедиться, что образ не был подменен. 36 • СПЕЦПРОЕКТ Kaspersky Container Security: контроль над безопасностью контейнерной инфраструктуры егодня уже невозможно всерьез говорить о микросервисоной инфраструктуры без использования инструментов контейнерной безопасности. Практика показывает: отсутствие специализированных механизмов контроля оборачивается уязвимостями и инцидентами. В 2024 г. сразу несколько крупных организаций столкнулись с утечками данных из-за компрометации контейнеров. Чтобы понять, почему такие инциденты неизбежны без соответствующих мер, важно разобраться, что именно включает в себя контейнерная безопасность и какие ее компоненты критичны для защиты. С Алексей Рыбалко, специалист по защите сред разработки, “Лаборатория Касперского” Антон Русаков-Руденко, старший менеджер по продуктовому маркетингу “Лаборатории Касперского” Тимофей Минин, старший менеджер по продуктам “Лаборатории Касперского” 1 https://cd.foundation/state-of-cicd-2024/ 2 https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/trebovaniya-po-bezopasnosti-informatsii-utv erzhd- eny-prikazom-fstek-rossii-ot-4-iyulya-2022-g-n-118 3 https://protect.gost.ru/document1.aspx?control=31&id=263523 4 https://www.nist.gov/publications/application-container-security-guide 5 https://attack.mitre.org/matrices/enterprise/containers/