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