УЦСБ завершил оценку защищенности приложений финансовых сервисов «Банка Синара»: в проект попали более 200 микросервисов и свыше 2 млн строк кода. Для рынка это не просто еще одна новость про «успешно прошли проверку», а вполне приземленный сигнал: требования регулятора к банковскому софту становятся частью конвейера разработки, а защищенность приложений уже нельзя оставлять на финальный этап перед релизом.
Проект охватил не только сам банк «Синара», но и Газэнергобанк, Делобанк и инвестбанк «Синара». По данным CNews, проверка проводилась по оценочному уровню доверия ОУД4, который относится к числу наиболее жестких сценариев оценки для прикладных систем. Итогом стало положительное заключение о соответствии требованиям Центробанка, а заодно и настройка постоянного процесса контроля безопасности, а не разовой кампании под проверку.
С технической стороны история выглядит заметно интереснее, чем стандартный пресс-релиз про кибербезопасность. Эксперты УЦСБ использовали собственную платформу Apsafe и прогнали приложения через несколько слоев анализа. Статический анализ исходного кода и композиционный анализ зависимостей охватили более двух миллионов строк. Дальше подключили динамический анализ и пентест, то есть проверку уже не на бумаге и не в теории, а через моделирование действий реального атакующего. До этого команда изучала архитектуру продуктов и общалась с внутренними командами банка, чтобы не стрелять сканерами по всему подряд, а понимать, где у системы действительно чувствительные места.
Отдельный важный момент — проверка по компоненту доверия AVA_VAN.3 из ГОСТ ИСО/МЭК 15408. За этой формулировкой скрывается не бюрократическая экзотика, а требование копать уязвимости глубже обычного чек-листа. Для банков это критично: если сервис формально «чистый», но при этом уязвим в цепочках вызовов, зависимостях или нестандартных сценариях работы, цена такой формальной чистоты быстро становится слишком высокой. Поэтому все результаты автоматических сканеров аналитики УЦСБ проверяли вручную. Практическая польза от такого подхода понятна любому тимлиду: разработчикам не приходится тратить время на ложные срабатывания и разбираться с десятками фантомных инцидентов ради галочки в отчете.
Главный инженерный вызов здесь — микросервисная архитектура. УЦСБ пришлось анализировать взаимодействие более 200 микросервисов, у каждого из которых свои сценарии работы, свой ритм обновлений и, как это обычно бывает, свои команды разработки. На бумаге микросервисы отлично масштабируются. На практике они еще и отлично размножают поверхность атаки: чем больше сервисов, интеграций, API и зависимостей, тем сложнее удерживать целостную картину рисков. Именно поэтому история с защищенностью приложений в банке давно перестала быть задачей одного AppSec-специалиста с хорошим сканером. Нужен процесс, который видит не только отдельный сервис, но и его влияние на соседей.
Под эту задачу УЦСБ доработал интерфейс Apsafe и добавил несколько функций, которые звучат гораздо полезнее большинства «инновационных» обещаний на рынке ИБ. Во-первых, появилась возможность отслеживать наиболее уязвимые сервисы в приоритете. Во-вторых, несколько микросервисов можно объединять в одно приложение и смотреть на безопасность уже на уровне продукта, а не только отдельных кусков системы. В-третьих, автоматизирована проверка статуса ручного анализа всех коммитов, вошедших в релиз. Для DevSecOps это, пожалуй, самый показательный фрагмент всей истории: безопасность здесь встроена в релизный цикл и начинает работать как часть поставки, а не как внешний аудит с драматическим дедлайном в конце квартала.
Руководитель направления разработки УЦСБ Евгений Тодышев в комментарии подчеркнул, что крупные игроки финансового сектора уже не первый год встраивают безопасность прямо в процесс создания цифровых продуктов. Это звучит как ожидаемая позиция исполнителя проекта, но в данном случае она неплохо подтверждается составом работ. Если после оценки защищенности приложений кодовые изменения автоматически уходят в Apsafe, проверяются на уязвимости и на влияние на другие сервисы, а затем только попадают в рабочую среду, значит речь действительно идет о постоянной практике, а не о разовой сертификационной фотографии «на паспорт».
Для разработчиков и продуктовых команд вывод довольно прямой. Регуляторные требования в банках все сильнее толкают ИБ влево по жизненному циклу разработки, и это уже влияет на архитектуру, релизы и внутренние процессы. Чем раньше команда умеет проверять зависимости, код и межсервисные связи, тем дешевле устранять проблемы. Чем дольше безопасность живет отдельно от CI/CD и release management, тем выше шанс, что релиз придется тормозить в последний момент, а спор между разработкой и безопасностью снова сведется к вечному «почему вы пришли так поздно».
Для бизнеса новость тоже читается без особых шифров. Банковские приложения давно стали непрерывно обновляемыми сервисами, а не тяжелыми системами, которые меняют два раза в год и потом осторожно не трогают. В такой модели соответствие требованиям ЦБ становится не итоговым документом, а свойством производственного процесса. И если кейс «Банка Синара» действительно закрепит DevSecOps как регулярную практику сразу в нескольких структурах группы, то следующим ориентиром для рынка станет уже не сам факт прохождения ОУД4, а скорость, с которой банки смогут проходить такие проверки без ручного героизма и остановки продуктовой разработки.