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