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

данных, инсайдер или случайная ошибка администратора, приводящая к оста- новке сервисов. Безопасность и надеж- ность – две стороны одной медали: сле- дование лучшим практикам делает систему более управляемой и устойчи- вой. Сегодня Kubernetes – не только для банков и маркетплейсов. Контейнери- зация активно используется в нефтегазе, металлургии, промышленности. Наконец, есть и регуляторный аспект. Российская регуляторика постепенно догоняет реальность. Появляются новые требо- вания и разъяснения, в том числе со стороны ФСТЭК России. Если раньше фокус был в основном на виртуальных машинах, то сейчас контейнеризация воспринимается как отдельный, быстро растущий сегмент, который тоже должен быть под контролем. Поэтому риски здесь действительно не только техниче- ские, но и управленческие – включая соответствие требованиям и возможные последствия при проверках или инци- дентах. – Как выглядит типичный заказ- чик Luntry с точки зрения зрело- сти процессов? – У заказчика может не быть почти ничего. Ключевое условие – контейнеры или планы на них и Kubernetes. Чем раньше компания задумывается о без- опасности, тем проще. Но если инфра- структура уже построена, активно раз- вивается, а сервисы работают в продак- шене, то интеграция проходит сложнее: процессы устоялись, поэтому изменения воспринимаются в штыки. Конечно, построение с нуля, когда все только проектируется, проще и позволяет сразу заложить правильные принципы: проду- мать модель доступа, разграничение ролей, процессы контроля, интеграцию с SOC – лучшие практики становятся частью фундамента, а не надстройкой поверх уже сложившейся архитектуры. Профиль заказчиков у нас довольно широкий. Есть компании, которые только начинают, им не хватает экспертизы – они приходят за методологией. Есть зрелые организации, лидеры рынка, которые понимают нашу специализацию. Luntry не является гигантским вендором с десятками разнонаправленных про- дуктов. Мы сфокусированы на одной теме, в которой разбираемся лучше всех в СНГ, – безопасности контейнеров и Kubernetes. При этом универсального профиля заказчика не существует. Формально все занимаются разработкой ПО или приобретают ПО, но внутри у каждой компании – своя специфика: разные процессы, разные модели нарушителя, разные требования к изоляции, разная модель угроз. Под одну гребенку их привести невозможно, и именно поэтому важен индивидуальный подход. Кто-то приходит с точечным запросом (SOC не видит контейнерную среду), кому-то нужно выстроить безопасную разработ- ку, а кто-то говорит: "Мы ничего не понимаем, помогите с нуля". В этом слу- чае начинаем с базовых шагов, приме- няем принцип 80/20 и постепенно раз- виваем систему. – Таких новичков больше, чем зрелых? – Да, их больше. Топовых зрелых игроков в России не так много. Но это не плохо: те, кто в авангарде, первыми набивают шишки и собирают опыт. Мы можем делиться этим опытом, чтобы другие не тратили время впустую. – С чего вы рекомендуете начи- нать путь к безопасному Kuber- netes? – Начинать нужно с понимания своей системы. В безопасности все начинается с инвентаризации. Если подходить по принципу "давайте включим тут, включим там, поставим все галочки, включим все детекты", можно что-то действительно заблокировать или ограничить, но при этом основная про- блема окажется вообще в другом месте. На практике чаще всего такой подход приводит только к ложным срабатыва- ниям и к ощущению, что "мы что-то сде- лали", хотя реального эффекта нет. Когда мы в Luntry создавали плат- форму, мы изначально исходили из того, что первым шагом команда должна уви- деть, что у нее вообще есть, как устроена система и как компоненты взаимодей- ствуют между собой. Слепое следование лучшим практикам иногда приводит к убыткам. Например, был случай, когда компания заблокировала доступ к пла- тежному шлюзу, не зная, что это за адрес, и простой стоил огромных денег, хотя внешний злоумышленник не смог бы нанести такой ущерб из-за других мер защиты. Сначала нужно вернуть системе наблюдаемость, потом накладывать ограничения. Задача безопасности – не сделать дашборды зелеными, а не допу- стить ущерб. Поняв систему, определяем модель нарушителя и строим план на 3–6 месяцев. В безопасности Kubernetes семь доменов безопасности, и я не встречал компаний, внедряющих все сразу – это требует много специалистов, которых на рынке мало. Начинать нужно с понимания, что даст максимальный прирост безопасности именно сейчас, а мы как эксперты в этой области, конечно, помогаем в этом. – В чем основная идея и цен- ность решения Luntry? – Ключевая идея – в комплексном подходе к безопасности Kubernetes. Мы исходим из того, что полноценный DevSecOps невозможен без совместной работы ИТ и ИБ. Платформа охватывает семь доменов, и ответственность часто распределена: например, пять доменов в зоне ИБ, два – в ИТ. Только совмест- ными усилиями, в комплексе, закрыва- ется весь контур. Мы регулярно сталкиваемся с попыт- ками перенести в Kubernetes подходы из мира Windows или классического Linux. Например, начинают фокусиро- ваться на тех аспектах, которые в кон- тейнерной среде уже не играют ключе- вой роли. Бывает, что компании хотят вложиться в защиту хостовой опера- ционной системы контейнерного узла, хотя в реальности, если атакующий туда уже попал, ему зачастую даже не нужны дополнительные уязвимости для повы- шения привилегий – сама архитектура контейнерного хоста предполагает нали- чие привилегированных сервисов. Ценность Luntry – в сочетании ком- плексного покрытия, глубокой специа- лизации и ориентации не только на ИБ, но и на ИТ. Рынок чувствителен к таким решениям, потому что контейнеризация стала массовой, а специалистов с пони- манием безопасности мало. Этот разрыв мы и закрываем. – Какую сильную сторону реше- ния вы бы выделили? – Гибкость. Причем начиная с уста- новщика. За шесть лет мы увидели мно- жество разных инфраструктур и пони- маем, что двух одинаковых не бывает, и этап внедрения и эксплуатации должен быть адаптивным. Гибкость пронизывает все решение: новички используют встроенные политики и правила, про- двинутые – конструкторы для создания собственных. Небольшие компании рабо- тают через веб-интерфейс, в крупных инфраструктурах с тысячами нод важнее API и интеграции. – Как вы определяете безопас- ную базовую конфигурацию кла- стера? – Через семь доменов безопасности Kubernetes – это целостная модель. Можно начать с состояния кластера: актуальность версий и патчей, обнов- ленное ядро системы. Далее – соответ- ствие отраслевым стандартам, например CIS Kubernetes Benchmark. Это мини- мальный уровень гигиены, включающий около 130 требований. Третий аспект – контроль ресурсов Kubernetes, то есть YAML-манифестов. Они определяют, что запускается и с какими правами. Нужно проверять их на соответствие лучшим практикам и внутренним стандартам. Следующий блок – управление правами доступа: пользователи, группы, сервисные аккаунты. Здесь критичен принцип наи- меньших привилегий, иначе компроме- тация одной учетки даст контроль над кластером. Отдельный домен – сетевая безопас- ность. Нужно понимать, откуда приходят соединения, куда сервисы обращаются 10 • В ФОКУСЕ