Каждая новая интеграция расширяет возможности бизнеса, но одновременно создает дополнительную точку контроля. Особенно чувствительны стыки между системами: без шифрования и защищенных каналов интеграция может стать узким местом. Отдельный риск связан с внешними участниками. Компания может хорошо защищать собственную инфраструктуру, но дать доступ подрядчику, безопасность которого никто не проверял. Если злоумышленник сначала скомпрометирует такого партнера, внутрь он попадет уже по легитимному каналу. Поэтому безопасность цепочки поставок — такая же часть общей защиты, как периметр или контроль доступа.
Семён Кошелев, технический директор Rakasta:
«Чем больше IT-решений и интеграций появляется в финансовой инфраструктуре, тем шире становится поверхность атаки. Поэтому безопасность важно учитывать ещё на этапе архитектуры и разработки, а управление уязвимостями, мониторинг и реагирование выстраивать как непрерывный процесс».
В Узбекистане действует закон «О кибербезопасности» (ЗРУ-764), принятый в 2022 году. Банковско-финансовая система отнесена к критической информационной инфраструктуре, поэтому киберустойчивость для финансовых организаций является и технической, и регуляторной задачей.
Уязвимость — не исключение, а часть реальной инфраструктуры
По данным исследовательского центра Compliance Control & Rakasta, за январь-май 2026 года при тестировании компаний финансового сектора, банков, ритейла и маркетплейсов было выявлено 1341 уязвимость. 29,3% из них относились к высокому и критическому уровню.
Статистика уязвимостей по результатам пентестов за январь-май 2026 года. Источник: исследовательский центр Compliance Control и Rakasta.
Для финтеха показательны и сами типы проблем: использование компонентов с известными уязвимостями, ошибки авторизации и контроля доступа, некорректные настройки параметров безопасности, стандартные учетные данные и простые словарные пароли.
Наличие уязвимостей — норма. Важно не их отсутствие, а скорость реакции. Поэтому безопасность нельзя оставлять на последний этап разработки: если продукт создавался без учета требований ИБ, перед запуском может выясниться, что проблема находится глубже — в выбранной библиотеке, фреймворке или подходе к разработке.
API: сначала архитектура
С API действует похожая логика. Риск связан не столько с их количеством, сколько с количеством реализованных через них интеграций. Поэтому сначала важно понять, действительно ли еще одна интеграция необходима. Если да, ее следует защищать как самостоятельный элемент инфраструктуры: использовать шифрованный канал, авторизацию, белые списки, ограничения по времени и заранее определенные условия доступа.
Средство защиты само по себе ещё не создаёт устойчивость
Даже сложное техническое решение не гарантирует безопасность, если команда не готова его полноценно эксплуатировать. Инфраструктура меняется, появляются новые сервисы и подключения, поэтому настройки защиты необходимо регулярно пересматривать.
Если инструментов становится больше, чем команда способна сопровождать, разумнее поэтапное внедрение или аутсорсинг отдельных функций, например SOC.
Управление уязвимостями должно быть непрерывным
Управление уязвимостями не может сводиться к мероприятию раз в год перед аудитом. Сначала необходимо провести инвентаризацию активов, определить их критичность, запустить сканирование, выявить и устранить проблемы. Значительная часть уязвимостей, в том числе критичных, закрывается базовыми мерами: обновлением программного обеспечения, закрытием ненужных портов или переходом на более безопасные протоколы.
После исправления нужна верификация: повторный точечный скан должен подтвердить, что проблема действительно исчезла. Если устранить уязвимость сразу невозможно, риск оценивают отдельно, в том числе через пентест.
Пентест отвечает на практический вопрос: где инфраструктуру можно взломать и насколько сложно это сделать. Важна не только сама уязвимость, но и то, сколько ресурсов потребуется потенциальному атакующему, чтобы ею воспользоваться.
Ошибку дешевле не допустить, чем потом закрывать
ИБ важно подключать еще на этапе планирования, когда разработчики, инфраструктурные специалисты и специалисты по безопасности могут совместно обсудить архитектуру, требования к доступности и потенциальные риски.
Показательный пример возник при подключении одного из клиентов к SOC. Во время анализа логов выяснилось, что в них в открытом виде передаются секретные ключи для взаимодействия между компонентами приложения. Если бы злоумышленник получил доступ к таким логам, он потенциально мог бы использовать эти данные для обращения к продукту извне.
Дополнительного защитного решения здесь не требовалось. Проблема была архитектурной: ключи необходимо было шифровать. После обнаружения риска это исправили. Если бы такое требование было заложено на этапе разработки, проблема не возникла бы.
«Вселенная безопасных платежей» как техническая система
Платежная инфраструктура существует как система взаимосвязанных элементов. Снаружи находятся подрядчики и цепочка поставок. Их необходимо проверять, а внешние взаимодействия делать шифрованными, ограниченными и регламентированными. Там, где это необходимо, использовать дополнительные факторы аутентификации.
Следующий уровень — все, что организация публикует в интернете. Такие системы необходимо регулярно проверять на открытые порты, уязвимости и изменение целостности. Особенно чувствительны платежные страницы. Подмена JavaScript на такой странице может изменить направление платежного потока, поэтому контроль ее целостности становится отдельной технической задачей.
Один из ключевых элементов всей системы — мониторинг и реагирование. Если сайт внезапно перестал работать, это не обязательно обычный технический сбой. За ним может стоять целенаправленная атака.
«Если организация не замечает инцидент и не реагирует на него, злоумышленник может долго оставаться внутри инфраструктуры, изучать ее и готовиться к дальнейшим действиям. Именно поэтому SOC — это не отдельная технология, а часть общей киберустойчивости», — отмечает Семён Кошелев.
«Вселенная безопасных платежей»: участники и элементы платежной инфраструктуры существуют как части единой системы защиты.
С чего начать: краткий чек-лист
Шаги 2−6 не требуют строгой последовательности: при наличии ресурсов их лучше выполнять параллельно:
- Провести инвентаризацию активов и понять собственный периметр.
- Запустить базовое сканирование на уязвимости и закрыть критичные проблемы.
- Встроить безопасность в разработку: проверка библиотек, статический и динамический анализ.
- Защитить API как самостоятельный элемент инфраструктуры: шифрование, авторизация, белые списки.
- Проверять подрядчиков и контролировать цепочку поставок.
- Настроить мониторинг и реагирование SOC или его аналог.
- Регулярно пересматривать конфигурации защитных решений и сверять их с текущей инфраструктурой.
Чем быстрее развивается финтех, тем меньше смысла рассматривать архитектуру, разработку, инфраструктуру и информационную безопасность как независимые процессы. Киберустойчивость появляется тогда, когда они работают как единая система, а мониторинг и реагирование дают возможность вовремя замечать изменения и реальные угрозы.
Эти и другие практические вопросы: от управления уязвимостями до построения SOC будут обсуждаться 30 сентября в Узбекистане на конференции «Финтех в безопасности». К участию приглашаются банки, финансовые и платежные организации, финтех-компании, IT- и ИБ-команды.
На правах рекламы.
