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

Тему про платформы мы обсуждали на конференции OFFZONE – междуна- родной конференции по практической кибербезопасности, которая ежегодно собирает в Москве тысячи специалистов и сотни экспертов. Создаются такие платформы не ради безопасности. Инициаторами почти все- гда выступают уставшие от рутины раз- работчики или SRE (Site Reliability Engi- neer, инженеры по надежности серви- сов). Главная их мотивация – сэкономить время и ресурсы. Но платформа стано- вится инструментом удобства и стан- дартизации, а вот безопасность, если и вспоминается, то где-то в конце списка требований. Тем не менее именно здесь и возни- кает парадокс: упрощая жизнь инжене- рам, платформа невольно делает шаг навстречу безопасности. Там, где рань- ше у каждой команды был свой пай- плайн, свои скрипты и свои костыли, появляется единая точка контроля. Все, что проходит через платформу, можно сделать безопасным по умолчанию: задать правильные шаблоны, встроить проверку кода, унифицировать автори- зацию. Без давления, без борьбы за дисциплину – просто потому, что иначе система не работает. Парадокс платформенной безопасности Когда мы начали строить внутренние платформы, задача казалась сугубо инженерной: ускорить работу команд, убрать рутину, сократить количество ручных действий. Безопасность тогда почти не упоминалась – казалось, что речь идет просто о повышении эффек- тивности. Но довольно быстро стало ясно: как только компания переходит на платформенный подход, именно плат- форма начинает определять, какой у нее уровень безопасности. В "Авито" это проявилось особенно отчетливо. Платформа для микросерви- сов, созданная изначально ради удоб- ства, внезапно стала центральной точкой контроля – через нее проходили все репозитории, пайплайны, настройки окружений. Мы получили возможность внедрять единые стандарты, автомати- чески создавать безопасные шаблоны для развертывания сервисов в Kuber- netes, включать авторизацию и разметку чувствительных данных без участия раз- работчиков. Безопасность перестала быть отдельным проектом: она просто шла в комплекте с инфраструктурой. Но у медали сразу нашлась обратная сторона. Стоило в шаблоне обнаружить уязвимость, как она мгновенно размно- жалась во всех новых сервисах. Мы буквально видели, как ошибка тиражи- руется сотнями инстансов – идеальный пример того, как автоматизация усили- вает и хорошее, и плохое. PaaS внутри "Авито" Первой крупной платформой, где мы почувствовали эффект безопасности по умолчанию, стала внутренняя PaaS – система для создания и управления мик- росервисами. До этого запуск нового сервиса занимал недели: инженеры копировали шаблоны конфигураций, вручную настраивали процессы сборки и доставки кода, подбирали рабочие окружения, устраняли ошибки при уста- новке. Когда число разработчиков выросло, стало ясно, что такой подход нужно автоматизировать. Так появилась команда, которая написала инструмент, превращающий создание микросервиса в минутную операцию. Теперь все выглядит просто: разра- ботчик придумывает имя, вводит коман- ду service create, и за десять секунд система создает репозиторий, подклю- чает CI/CD, заводит метрики и логиро- вание. Вторая команда – service deploy – и сервис уже в продакшене. Оказалось, что единый пайплайн и стандартные шаблоны автоматически сделали инфраструктуру безопаснее. Разработчик не видит конфигурацион- ные файлы и поэтому не может случайно их испортить. В каждом сервисе по умолчанию работают тесты, проверки качества кода, аутентификация и авто- ризация. Мы даже добавили разметку чувствительных данных в API – теперь платформа знает, где проходят персо- нальные данные, и позволяет строить карту их движения. Но, проявились и упомянутые ранее риски. Уязвимость в шаблоне означала, что каждая новая команда service create создает уязвимый сервис. Если не фикси- ровать такие ошибки мгновенно, платфор- ма начнет размножать проблемы быстрее, чем мы успеем их устранять. Плюс ограничения самой системы: внедрить, например, Distroless-образы оказалось невозможно без переделки платформы – слишком глубоко вшита логика сборки. Тем не менее эффект оказался рево- люционным. Мы больше не навязываем безопасные практики – платформа сама заставляет следовать им, просто потому что иначе она не работает. Платформа публикации API Следующим шагом стала платформа, которая позволила разработчикам само- стоятельно публиковать API и фронтен- ды. Интерфейс прост: несколько кликов, и ручки сервиса уже доступны из интер- нета. Разработчик сам связывает нуж- ные куски фронта и бэка, задает правила публикации – все красиво. Описание в изложении владельца про- дукта звучало идеально: команды будут радоваться, что теперь не нужно ждать очереди на выкладку, а бизнес получит фичи заметно быстрее. Но во время тестирования стало понятно: стоило одно- му инженеру промахнуться при выборе API, и во внешний мир уйдёт ручка без проверки прав. В другом сценарии из-за неявной логики на фронт могут попасть лишние персональные данные. 66 • УПРАВЛЕНИЕ Когда платформа становится безопаснее, чем безопасник крупных компаниях стало слишком много инженерии. Коман- ды растут, микросервисы множатся, инфраструктура услож- няется, а вместе с ней – и стоимость ее поддержки. Поэтому идея внутренних платформ выглядит естественным ответом на хаос. То, что раньше требовало согласований и ручных настроек, теперь превращается в сервис – Platform as a Service, Publication as a Service, Admin as a Service. В Александр Трифанов, руководитель направления Application Security, “Авито” Фото: "Авито"