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

Дмитрий Евдокимов, Luntry Это устоявшийся миф. В контейнер- ных окружениях модель Zero Trust строится на минимизации, на исклю- чении ненужного, что, в свою очередь, убирает много издержек и на саму эксплуатацию системы. Например, в образах контейнеров помещается только необходимое – тут и поверх- ность атаки меньше, и вероятность закрепления с развитием атаки ниже, и сами образы легче, меньше места занимают, быстрее анализируются и оставляются по сети. Или Network- Policy, например, четко описывает и ограничивает, кто с кем может из сервисов общаться, – это и атакующе- му не позволяет развить атаку, и сете- вым плагинам проще обрабатывать пакеты. Михаил Бессараб, Positive Technologies Контейнеризация и ее конкретная реализация оркестрации на базе Kubernetes обладают встроенными инструментами управления сетью на базе API Network Policy, которые поз- воляют обеспечить базовую L3–L4- сегментацию. Однако API – это только обертка над реализацией Container Network Interface. Под капотом во мно- гих плагинах используется netfilter, что может вызывать проблемы в высоко- нагруженных системах. Но уже суще- ствуют такие сетевые плагины как Cillium и Calico, которые позволяют использовать технологию eBPF для управления трафиком между контей- нерами для улучшения производитель- ности и ряда дополнительных возмож- ностей. Игорь Душа, НОТА Zero Trust в микросервисах требует баланса между безопасностью и про- изводительностью. Сквозное шифрова- ние и постоянная верификация увеличи- вают нагрузку на систему, но это можно оптимизировать. Ключевое решение – гибридный подход с mTLS для критиче- ски важных сервисов, JWT-аутентифи- кация – для остальных. Автоматизиро- вать этот процесс помогают сервисные сетки вроде Istio. Максим Чудновский, СберТех Реальную грань определяет для себя каждая конкретная компания, исходя из рисков, возможностей и специфики бизнеса. При этом с точки зрения тех- нологий хорошо помогает такой паттерн, как Service Mesh. Конкретные реализации этого решения могут иметь совершенно разные характеристики и требуют тщательного подбора. Важно отметить, что на рынке существуют продукты, которые могут быть исполь- зованы в разных сценариях, например Platform V Synapse Service Mesh от СберТеха. Руслан Субхангулов, CrossTech Solutions Group Обеспечение модели Zero Trust в микросервисной архитектуре – серь- езный вызов, особенно когда необхо- димо найти баланс между уровнем безопасности, производительностью системы и управляемостью инфра- структуры. Из ключевых подходов я бы выделил: 1. Использование Service Mesh с меха- низмами Zero Trust, которые предостав- ляют "из коробки": автоматическое шиф- рование mTLS для шифрования трафика между микросервисами, идентификация и авторизация на основе удостоверений (SPIFFE/Spire), политикa доступа между сервисами (L4/L7). 2. Чтобы избавить разработчиков от лишней нагрузки в виде дублирующей конфигурации и ручного управления доступом, необходимо делегировать задачи авторизации и политики сетевого доступа на уровень платформы. Это упрощает сопровождение и повышает надежность. 3. Автоматическое применение поли- тики Deny All между всеми сервисами с явным разрешением необходимых соединений позволяет формализовать модель минимально необходимого доступа и снижает риск ошибок конфи- гурации. 4. Внедрение eBPF- или агентских решений, обеспечивающих безопас- ность, помогает не только контролиро- вать трафик, но и выявлять неопти- мальные маршруты, задержки и потен- циальные уязвимости. Zero Trust – это не про "максималь- ную сложность" или "жесткие ограниче- ния". Реальная грань между безопас- ностью и производительностью дости- гается, когда безопасность реализо- вана автоматически и декларативно, накладные расходы сред управления (sidecar, прокси, агент) предсказуемы и масштабируемы, наблюдаемость и аналитика позволяют выявлять узкие места безопасности и производитель- ности до того, как они затронут поль- зователей. Если внедрение Zero Trust приводит к росту ошибок, задержек и трудно- стей с отладкой, значит архитектура перегружена, и подход требует пере- смотра. Хорошо реализованная модель Zero Trust прозрачна для сер- висов, автоматизирована для плат- форменной команды и управляема для SecOps. Главное – не абсолюти- зировать контроль, а выстраивать адаптивную защиту, встроенную в про- цессы доставки и эксплуатации при- ложений. Алексей Рыбалко, Лаборатория Касперского Компромисс между выполнением задач ИБ и производительностью не так-то легко достичь. В процессе соз- дания Kaspersky Container Security раз- работчики пошли на целый ряд такти- ческих решений в угоду производи- тельности: централизация проверок работающих контейнеров на уровне ядра ОС, применение асинхронного режима для проверок (когда проверка процесса осуществляется при факти- чески уже запущенном процессе), закачка правил проверки сетевых сес- сий целиком в ядро ОС. Реальная грань – в осознании последствий при- нятых архитектурных решений в каждой задаче обеспечения высокой произво- дительности. Алексей Рыбалко, Лаборатория Касперского SBOM – это список объектов, который можно автоматически далее проверить по базам уязвимостей. Kaspersky Container Security делает такие про- верки автоматически по западным и отечественным базам, поэтому вопрос о "реальности" даже не возникает. Некоторые заказчики дополнительно делают экспорт SBOM для целей инвен- таризации и подключения иных прове- рок, но в основе Kaspersky Container Security задача проверок закрывается автоматом. Дмитрий Евдокимов, Luntry SBOM – важная и полезная часть современной безопасности. Но он не является панацеей, это лишь малень- кий кусочек пазла в картине безопас- ности. При этом, к сожалению, ата- кующий может запутать анализаторы компонентного анализа, и мы получим недостоверные результаты. Конечно, SBOM сам ради себя не нужен – с его результатами нужно уметь работать. Информация о том, что выявлены пять или десять тысяч уязвимостей, заказ- чика не спасет. Нужно запустить про- цесс обновления, применить митигей- шены в рантайме и провести харденинг окружения. Игорь Душа, НОТА SBOM остается важным инструмен- том на всех этапах жизненного цикла ПО. Плагины для Maven и Gradle авто- матически формируют спецификацию компонентов при сборке, а Trivy, Syft SBOM называют новым стандартом безопасно- сти. но насколько он действительно полезен в условиях тысяч зави- симостей и частых обновлений? реально ли проверять SBOM в продакшене, а не про- сто генерировать его ради галочки? • 43 Защита контейнерных сред www.itsec.ru