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

Таки образом, тестирование ясно пока- зало, что платформа, созданная для уско- рения, нуждается в собственных меха- низмах защиты. Безопасность нельзя под- ключить постфактум – она должна быть встроена в поток публикации. Мы начали дополнять систему фильтрацией полей, Quality-гейтами, верификацией связей между API и фронтами, чтобы минимизи- ровать влияние человеческого фактора. Главный урок в том, что скорость и безопасность не конфликтуют, если последняя встроена в процесс. Когда же безопасность существует отдельно, любая автоматизация превращается в источник неожиданных рисков. Админка как сервис Третья платформа родилась из банальной усталости инженеров: каждая команда делала собственные админи- стративные панели, писала однотипный CRUD, настраивала доступы, логирова- ние, домены. Задача казалась очевид- ной – собрать универсальный конструк- тор, который создает админку автома- тически. Платформа должна была изба- вить разработчиков от рутинных опера- ций, а безопасникам – дать уверенность, что все интерфейсы проходят ревью и работают по единым правилам. На старте и тут все выглядело идеально. "Админка как сервис" позволяла быстро завести проект, настроить авторизацию, подключить логи и даже получить домен без участия инфраструктурной команды. Более того, создатели платформы сде- лали ставку на безопасность как марке- тинговое преимущество: все проходит ревью, все проверено, можно использо- вать без страха. И действительно, первые интеграции проходили гладко – пока не появились "гипотезы". Разработчики, привыкшие к скорости, начали использовать платформу как песочницу: создавали временные марш- руты, выкладывали тестовые страницы, обходили проверки – "на пять минут, чтобы просто проверить". Формально система оставалась защищенной, но фактически появлялись обходные пути. Так родился классический треугольник ответственности: пользователи обвиняют безопасников в излишней строгости, безопасники – платформу в избыточной гибкости, а платформа – пользователей, которые не на то кликнули. Эта ситуация заставила пересмотреть саму философию продукта. Мы пришли к выводу, что не стоит полагаться на дис- циплину пользователя, если ее можно заменить архитектурой. Платформа долж- на быть устроена так, чтобы ошибиться было невозможно – чтобы временный маршрут просто нельзя было создать без авторизации, а обход защиты требовал сознательных и заметных усилий. В этот момент команда безопасности и разработчики платформы пересмот- рели подход к фичам платформы. Новые версии уже учитывали требования ИБ на уровне логики и API, а не как внешний контроль. Этот переход оказался важнее любых проверок: мы впервые ощутили, что безопасность и инженерия могут двигаться в одном направлении, если их объединяет общая цель – сделать продукт удобным и безопасным одно- временно. Безопасность как сервис, а не как ограничение Когда внутри компании появилось несколько зрелых платформ, стало оче- видно: классическая модель безопасно- сти, основанная на запретах и регла- ментах, просто не работает в такой среде. Скорость релизов, автоматизация и количество интеграций делают ручное вмешательство невозможным. И тогда логика переворачивается – безопасность перестает быть внешней силой и пре- вращается в часть платформы, в тот самый Security as a Service. Смысл этого подхода прост: безопас- ники перестают контролировать каждое действие разработчика и начинают соз- давать сервисы, которые делают без- опасное поведение естественным. Не нужно навязывать линтеры или тесты – они уже встроены в пайплайн. Не нужно проверять деплой – он не состоится, если не пройдены проверки. Безопасность ста- новится свойством экосистемы. В "Авито" этот сдвиг стал переломным моментом. Мы перестали насаждать политику безопасности и начали пред- лагать удобные сервисы: единый CI/CD, шаблоны микросервисов, готовые меха- низмы авторизации. Команды подключа- лись добровольно, потому что это эко- номило им время. А значит, безопас- ность перестала восприниматься как помеха. Ограничения и реальность Стоит упомянуть, что на практике про- явились и ограничения этого подхода. Как только появляется новая технология, язык, формат деплоя – возникает исклю- чение, которое не укладывается в стан- дартные шаблоны. В этот момент про- является хрупкость всей конструкции: единые пайплайны и правила, которые раньше обеспечивали порядок, начинают мешать экспериментам и вынуждают команды искать обходные пути. Мы не раз сталкивались с этим. Напри- мер, при попытке внедрить Distroless- образы оказалось, что платформа не умеет их тестировать: в образе просто нет инструментов для запуска тестов. Исправить это значило переписать часть пайплайна – а значит, затронуть все сервисы, которые через него проходят. Или другой пример – интеграция с внеш- ними платформами, которые живут своей жизнью и не подчиняются внут- ренним стандартам. Здесь безопасность снова возвращается к старым методам: точечный аудит, ручное сопровождение, устные договоренности. Такие ограничения – не ошибка архи- тектуры, а ее естественное свойство. Универсальной платформы не суще- ствует. Зрелость заключается не в том, чтобы охватить все, а в умении видеть границы и управлять ими. Безопасность в этой модели должна быть способна работать в гибридном режиме: где-то встроена в пайплайн, где-то живет как сервис-консультант, где-то – как надзор за нестандартными зонами. Еще один практический урок – зави- симость от самой платформенной коман- ды. Любая задержка с обновлением, любой технический долг в коде плат- формы напрямую влияет на защиту ком- пании. Поэтому роль безопасников неизбежно расширяется: им приходится понимать архитектуру, участвовать в ревью кода, планировать миграции. В заключение Главный результат всей этой эволю- ции – изменение роли безопасности внутри инженерной культуры. Там, где раньше безопасники выступали как над- зорный орган, теперь они становятся частью производственного цикла. Плат- формы заставили команды по-новому взглянуть на саму идею контроля: вместо того чтобы останавливать процессы, безопасность начала обеспечивать их предсказуемость. Этот переход оказался не только куль- турным, но и экономическим. Когда без- опасность встроена в пайплайн, отпадает необходимость в бесконечных согласо- ваниях, аудитах и ручных проверках. Ошибки ловятся автоматически, а реше- ния принимаются быстрее. Самое важное – исчезает конфликт между скоростью и надежностью, который годами отравлял отношения между разработкой и ИБ. Разработчики видят в безопасности не тормоз, а партнера, который делает их сервисы стабильнее и облегчает жизнь. Такое сотрудничество не возникает мгновенно. Оно требует доверия, общего языка и готовности делиться ответствен- ностью. В "Авито" этот путь занял несколько лет: от первых экспериментов с единым пайплайном до появления зре- лых сервисов уровня Security-as-a-Ser- vice. Но именно этот путь показал, что безопасность может быть не барьером, а инфраструктурной функцией, встроен- ной в саму ткань разработки. Когда архитектура позволяет быть защищенным по умолчанию, контроль превращается в сотрудничество, а без- опасность – в естественное свойство системы, а не внешнее требование. И в этом, пожалуй, главный итог всей исто- рии: зрелая компания – это не та, где безопасность всех проверяет, а та, где безопасность встроена в саму логику работы. l • 67 УПРАВЛЕНИЕ www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru