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

– На каком этапе компания сей- час? – Luntry прошла этап становления и доказала жизнеспособность. Мы само- достаточны, и благодаря этому привлек- ли внимание ведущих игроков рынка. К нам приходили почти все крупные компании с целью обсудить покупку. В декабре сделка состоялась: компания Solar Security приобрела контрольный пакет. Для нас это показатель зрелости и успеха. – Почему вообще тема безопас- ности контейнеров стала замет- ной? И какие типовые ошибки в безопасности Kubernetes вы чаще всего видите? – Причина проста: меняется сама модель разработки. Бизнесу нужно быстрее выпускать фичи, тестировать гипотезы, масштабироваться под нагрузку. Контейнеры позволяют делать это макси- мально оперативно. Они удобны, гибки – если все правильно настроено. Когда кон- тейнеров становится много, управлять ими вручную уже невозможно и здесь появляется оркестрация – Kubernetes, который уже стал стандартом де-факто. Проблема в том, что с появлением Kubernetes возникает новый уровень абстракции: поверх ОС появляется слой контейнеризации и оркестрации с собст- венной бизнес-логикой, моделью поль- зователей, сетью, секретами. Все это нужно защищать. Теперь к вопросу о типовых ошибках. Обычно ждут "топ-5 проблем", но Kuber- netes – не готовый продукт, а конструк- тор. Под разные задачи собираются разные архитектуры: кластер для мар- кетплейса, для обучения нейросетей или для CRM в закрытом контуре – везде разная поверхность атаки. Закрытый контур не отменяет внутренних наруши- телей, атак на цепочки поставок и оши- бок конфигурации. Я стараюсь не давать универсальных рецептов, потому что люди начинают воспринимать их как чек-лист без учета контекста. Повторяющиеся ошибки свя- заны с непониманием архитектуры: не определена модель угроз, не разделены роли, избыточные права, нет изоляции окружений, безопасность не встроена в дизайн. Защищать нужно не Kubernetes вообще, а конкретную систему с ее задачами. – Изменился ли ландшафт угроз для контейнеров за последние 2–3 года? – Эволюция угроз повторяет класси- ческий путь атак на Linux и Windows. Сначала были прямолинейные сценарии: майнеры, закладки в образах. Но быстро стало понятно, что сканирование их обнаруживает, и злоумышленники сме- стили фокус на более сложные техники. Сегодня чаще используются инстру- менты двойного назначения – легитим- ные утилиты, которые выглядят как обычная активность. В Kubernetes ключе- вую роль играет декларативная модель: все описывается в YAML-манифестах. Атаки углубились в эту специфику: используются ошибки конфигурации, злоупотребления сервисными аккаунта- ми, модификация манифестов или экс- плуатация CI/CD. По-настоящему опасными стали сце- нарии, эксплуатирующие легитимные механизмы Kubernetes, – они плохо заметны. Массовые истории про вирусы в контейнерах часто переоценены, осо- бенно в зрелых компаниях. – Чем безопасность контейне- ров отличается от безопасности виртуальных машин? – Ключевое отличие – дополнительный слой абстракции. Можно представить технологии в виде слоеного пирога, который выглядит следующим образом: железо, виртуализация, хостовая ОС, контейнеризация, оркестрация (на базе Kubernetes). Виртуальная машина – пол- ноценная ОС, большая, универсальная, рассчитанная на человека. Контейнер – минималистичная среда, заточенная под конкретную задачу. Если атакующий попадет в контейнер с одним исполняемым файлом, ему не на что опереться – нет инструментов для развития атаки. В виртуальной машине – целая ОС для закрепления и сканирования. Контейнерная инфра- структура проектировалась не для людей, это среда для приложений. Чело- век – источник хаоса, а приложения ведут себя предсказуемо. Если в среде без интерактивной активности появляет- ся человеческое поведение – это ано- малия, по которой можно обнаружить злоумышленника, даже использующего неизвестные ранее уязвимости и инстру- менты. Ошибки возникают при переносе при- вычного мировоззрения из классических серверов в Kubernetes. Первые годы нас спрашивали, какие железки туда поставить. Хотя это программная среда. До сих пор некоторые пытаются ставить в контейнеры классические EDR, но контейнеры генерируют сотни тысяч событий в секунду – агент не успевает: ложится или пропускает события. То же с сетевыми файрволами, которые иногда используют без понимания динамиче- ской сети Kubernetes. – То есть заказчики не до конца понимают, с чем имеют дело? – Я бы не обобщал. Речь о тех, кто без разбора переносит в новую среду свой прошлый опыт. Например, привык- ли фильтровать, разграничивать по IP- адресам, а в Kubernetes сеть динамиче- ская, и IP-адрес сегодня принадлежит одному сервису, а завтра – другому. Мы часто обучаем, объясняем, почему ста- рые подходы не работают. Это проблема не столько Kubernetes, сколько людей, которым тяжело дается новое. Многое зависит от взаимодей- ствия ИБ и ИТ в компании. Болезненные кейсы чаще возникают со стороны без- опасников: ИТ создает систему и пони- мает ее, а когда ИБ предлагают готовую инфраструктуру и говорят "защищай", возникает разрыв в логике того, как все устроено и работает. Поэтому нужен диалог между ИТ и ИБ. Многие считают, что DevSecOps – это "купил инструмент – и всё". На мой взгляд, это максимум 15% результата. Остальное – взаимо- действие и процессы между командами. При этом далеко не каждый инструмент позволит выстроить это взаимодействие. – Где проходит граница ответ- ственности между DevOps, раз- работчиками и ИБ? – Многие пытаются провести четкую границу, но в реальности это не работа- ет. Безопасность контейнеров – распре- деленная ответственность. Важно, чтобы команды работали слаженно и говорили на одном языке. Главный вызов: клас- сическим безопасникам сложно погру- жаться в инженерную тему. Вместо того чтобы рисовать границы, нужно выстраивать прозрачные процес- сы взаимодействия. ИБ должна встраи- ваться в экосистему вместе с ИТ. Наши ведущие клиенты идут к платформиза- ции и тесному сотрудничеству, где без- опасность – часть надежности сервиса. Я не разделяю мнение, что ИТ не заинтересованы в безопасности. Разра- ботчики хотят выпускать надежный про- дукт, но им важно, чтобы безопасность была понятной и не нарушала темп. В Kubernetes-среде люди вовлечены и заряжены на результат. Наш подход: мы не верим в жесткие границы разде- ления, мы верим в совместную работу и общие процессы. – Как объяснить руководителю без технических деталей, в чем бизнес-риски небезопасного Kubernetes? – Для российского рынка это молодое направление, и необходимость защиты не всегда очевидна. Я объясняю через аналогию: мы понимаем, что происходит в классической Linux-инфраструктуре. Но Kubernetes создавался не для людей, а для приложений. Если он не защищен, компания не понимает, что делают ее приложения. У службы безопасности возникает слепая зона. Через эту зону злоумышленнику проще проникнуть внутрь и развивать атаку вглубь инфра- структуры, добираясь до критичных систем. Данные могут незаметно утекать наружу. Если Kubernetes не защищен, никто не ответит на вопрос: "У нас все хорошо?" – если видно лишь 20% инфра- структуры. Последствия могут быть разными: внешняя атака, компрометация учетных • 9 ПЕРСОНЫ www.itsec.ru