Привет! Текст подготовлен на основе выступления Александра Сербула, руководителя больших данных, высоконагруженных систем и машинного обучения, «1С-Битрикс» на форуме ITSEC 2025.

Работая с самыми разными заказчиками, в разных компаниях и на разных должностях, я видел массу нарушений ИБ. Например, новый сотрудник подписывает NDA, но при этом сервера в компании не обновляются годами, а разработчики используют права root-пользователя. Безопасник не может оценить написанный код, потому что не знает языка программирования. И это не говоря уже о типичном отсутствии антивируса на рабочих местах, отсутствии ротации паролей и двухфакторной авторизации. 

В этой статье я расскажу о том, как мы видим безопасность изнутри проекта, какие шаги предпринимаем при быстрой разработке — мы выпускаем два релиза в год, каждый проект запускается за 3-5 месяцев, поэтому у нас нет времени на проектирование, написание и согласование ТЗ. И на долгие проверки кода безопасниками времени тоже нет. Тем не менее, нам удается поддерживать высокое качество и безопасность проектов и мы поделимся своими секретами в статье.

Рассказывать буду на примере продукта, в создании которого я принимал непосредственное участие и как архитектор, и как разработчик. Это BI-конструктор, популярный продукт в Битрикс24, доступный десяткам тысяч коммерческих компаний. 

Для начала расскажу о самых частых проблемах безопасности, приведу примеры решений и покажу роль контейнеров в них.

Проблема 1: ИБ отстает от разработки 

На коротких проектах или в стартапах разработчики пишут код очень быстро и используют максимум готовых решений. Но ИБ-специалисту требуются недели, чтобы этот код проверить. Специалист по безопасности может не знать языка программирования, на котором написан код или в принципе не готов изучать новые технологии, например, Kubernetes. Парадоксальный пример — я пишу в основном на Rust, это хороший язык, он позволяет безопасно работать с памятью. Но в ИБ его знают единицы. А разработчики в результате сталкиваются с ситуациями, когда безопасник обращается к нейронным сетям за помощью в проверке незнакомого кода. 

Разработчики постоянно развиваются, изучают новое, знают несколько языков. А вот ИБ-специалистов, которые знают больше одного языка программирования, к сожалению, катастрофически мало. 

Решение: обучать, объединяться с разработкой

Безопасников нужно постоянно учить. Например, мы 4 месяца прокачивали своих сотрудников в Kubernetes, прежде чем начать использовать его на проектах. Если безопасники отстают от разработчиков в понимании технологий, в знании стека, они не смогут провести аудит когда. О какой безопасности тогда может идти речь? 

Если нет возможности обучать безопасника — подключайте тимлида, который хорошо знает технологический стек и может сделать аудит кода. Безопасник объяснит, что именно проверять в коде, а тимлид будет выполнять задачу. Это касается в первую очередь кода на Java, Rust, Kotlin, Scala и прочей «экзотике».

Проблема 2: в компании огромное количество необновленных ОС и софта

Ситуация особенно распространена в консервативных отраслях, в промышленности. На заводе может стоять Linux, который не обновляли уже 10 лет, опасаясь, что после этого все упадет. Или потому что в компании нет людей, которые администрировали сервер и знакомы со всеми нюансами его работы. 

Решение: использовать контейнеры

Я рекомендую ставить Docker или аналоги, разворачивать ОС и размещать весь софт в контейнерах. Таким образом можно будет безопасно обновлять ОС, и отдельно обновлять софт в контейнерах. Мы именно так делаем — в результате у нас работают актуальные версии софта и всех библиотек.

Проблема 3: для проверки Open Source кода требуется слишком много времени

Все современные проекты, которые запускаются быстро, устроены примерно одинаково. Разработчики используют контейнеры с Open Source решениями, собирают их в Docker Compose, пишут относительно немного кода и запускают это все в продакшн. Это бизнес — выпускать продукты нужно быстро. Например, у нас в BI-конструкторе основная логика работает на базе Apache Superset. Безопаснику, чтобы проверить такой контейнер, нужно три недели работы фултайм при условии, что он знает Python, Bash и в целом работу с контейнерами. Но в моей практике ИБ-специалисты часто смотрят на содержимое Open Source контейнеров очень поверхностно.

Еще сложнее на проектах, где используется, например, Helm Chart в Kubernetes — эта история на порядки больше по объему и сложнее, чем контейнеры. В Helm Chart сотни страниц документации, которые безопаснику необходимо изучить.

Решение: использовать официальные контейнеры для Open Source решений

В компании должен быть репозиторий официальных контейнеров. Безопасник будет проверять один контейнер несколько месяцев — так делают только в очень больших компаниях и то не всегда. Поэтому первое, что можно сделать — скачать контейнер из официального репозитория, от вендора. Их регулярно обновляют и поддерживают с точки зрения безопасности. В этом случае останется проверить только собственный код, что займет значительно меньше времени. 

А теперь перейдем к конкретному примеру: расскажу, как работает наш BI-конструктор и где в этом проекте место информационной безопасности. 

Архитектура BI-конструктора Битрикс24 и потоки данных

Это типичный пример того,  как разработка за 4-5 месяцев запускает в продакшн большой международный проект. 

В основе продукта лежит Docker-compose c Apache Superset и Trino. Вот список наших контейнеров - Apache Superset, Trino, Redis, MySql.

Если посмотреть на архитектуру, то нашего кода в ней не так много, он в основном в Apache Superst и в плагине Trino, написанном на Java. Все остальное - Open Source решения в контейнерах.

Как это работает

Apache Superset — Open Source продукт, который позволяет решать задачи BI-аналитики, визуализирует данные. 

В Kubernetes мы выделяем под каждого клиента один под, на котором ставим контейнеры с Apache Superset и Redis.

Superset хранит данные в MySQL, которая также находится в контейнере, но вынесена за пределы Kubernetes. Мы вообще вынесли за пределы k8s максимум статики, во-первых, чтобы сократить поверхность атаки, и во-вторых, чтобы сократить ресурсы на обработке данных.

Именно поэтому вне Kubernetes у нас также находится БД Trino — один из лучших в мире движков для BI-аналитики. Это MPP (massive parallel processing) база данных, которая позволяет очень быстро обрабатывать данные в памяти на кластере. Apache Superset обращается к ней через плагин, который мы написали, кеширует часть данных в Redis и затем выводит результат клиенту в браузер. 

У нас есть непосредственно несколько десятков тысяч порталов клиентов Битрикс24. Мы обращаемся за пределы Kubernetes на портал, забираем данные (лиды, сделки, компании, контакты), плагин их обрабатывает, а потом уже Superset визуализирует их в браузер клиента. 

Как мы защитились в Kubernetes на этом проекте

Еще раз напомню, что у нас были сжатые сроки проекта, поэтому мы запустились в управляемом Kubernetes в VK cloud. Наш облачный кластер Kubernetes - один из крупнейших в России. 

В подах облачного провайдера скорее всего не будет никаких дополнительных инструментов безопасности, эти возможности сильно ограничены, поэтому я расскажу, как выживать в облачном k8s.

Мы провели аудит безопасности, который оперативно выявил несколько критичных проблем. 

1. За обновление Kubernetes, за инфраструктуру внутри отвечает облачный провайдер. Но когда вы запускаете его с вашими контейнерами в облачном провайдере, имейте в виду, что классический Vanilla k8s – абсолютно прозрачный! Каждый под видит другие поды, вы можете сходить с пода одного клиента на под другого, взломать его и дальше пойти в redis. Поэтому не забывайте закрывать, как минимум,  порты, привязывая их на localhost.

2. Контейнеры на Docker хабе часто выкладываются с запуском под root-пользователем. Постепенно мы их доработали, поменяли права доступа на менее привилегированные при запуске

3. Open Source могут обновляться реже, чем следует — это серьезная проблема в ИБ. Мы перекачали контейнер Apache Superset к себе в репозиторий, сами его патчим и раскатываем на десятки тысяч клиентов через «helm upgrade».

4. Мы используем обычные «секреты» в k8s, из аддонов — только локальный registry. Vaults не используем. Самое важное в Kubernetes — для каждого клиента мы заводим собственный namespace, отдельную папку. Это обязательная история для коротких проектов. Если все валить в кучу, поддерживать ИБ будет практически невозможно. И еще одно непреложное правило, которому я лично следую много лет — в системе должны быть длинные и сложные пароли. Начините с этого и постепенно закручивайте гайки все больше и больше, но не выше необходимого

5. Всегда готовьтесь к тому, что данные могут быть слиты. Например, человек увольняется и даже несмотря на уголовную ответственность, он может их слить. Поэтому чувствительные данные клиентов нужно шифровать. У нас симметрично шифруются «на лету» базы клиентов в MySQL, ключи хранятся отдельно. Файлы паролей в Trino мы хранием в виде хэшей с солью.

6. В плагине Trino написали свой менеджер безопасности с логированием secure-операций. По логам всегда можно понять, что систему атакуют или подбирают пароли. Обязательно логируйте все, что связано с ИБ, все операции в критически важных участках системы. 

7. TLS-терминация – за пределами k8s в nginx на балансерах, хотя начинали с секретов внутри k8s и TLS в ингресс-контроллере 

8. Ingress-контроллер был «ingress-nginx», сейчас «contour-envoy». Это точка входа в Kubernetes, контроллер, который маршрутизирует по подам запросы из браузеров. Один только ingress-nginx — это сложный элемент k8s с сотнями страниц документации. В contour-envoy документации еще больше. К сожалению, админы не любят погружаться в такие сложные системы, а безопасники недовольны ими еще больше. «Запасайтесь терпением и действуйте с любовью, но строго (С)».

И напоследок еще раз ключевые рекомендации:

1. Выстраивайте взаимодействие тимлид+ИБ. Тимлид делает аудит кода, специалист по ИБ говорит, что проверять.

2. Контролируйте админов и обновление серверов. Первый шаг в безопасности - это именно прийти к админам и спросить, когда в последний раз обновляли сервера. 

3. Прокачивайте свои команды в Kubernetes. Курсов, на которых даются практические знания, очень мало, и их становится все меньше. Я рекомендую посещать конференции и организовывать обучение внутри компании. 

4. Безопасник должен быть круче разработчика, должен знать языки программирования и технологический стек. В идеале, получив доступ на проект, он должен сделать аудит кода и найти все места, где проект можно взломать. 

5. Максимально подключайте автоматический мониторинг для обновлений серверов, уязвимостей в контейнерах. 

И помните, несмотря на кажущуюся сложность, k8s и контейнеры делают процесс разработки более последовательным и упрощают контроль ИБ. Для быстрых проектов —  это лучшее решение.