Лука Сафонов, бизнес-партнер по инновационному развитию компании «Гарда», участник рабочей группы ООН по управлению данными, лидер Российского отделения консорциума OWASP
Финансово-банковский сектор в России и СНГ вошел в цифровую эпоху позже многих зарубежных рынков, но этот старт дал практическое преимущество. Инфраструктуру строили сразу под высокие требования к доступности и устойчивости, а также под жесткий контроль регуляторов. Банки с первых лет работы учитывали требования ЦБ, платежных систем и отраслевых стандартов. Поэтому масштабные утечки и успешные кражи денег из банков случаются реже, чем в других странах, и связаны с частными или нетиповыми сценариями, а инциденты часто выражаются в локальных сбоях сервисов, простое отдельных функций и временных ограничениях для клиентов.
За рубежом ситуация иная. Финансовые сервисы там часто опираются на платформы, заложенные 20–30 лет назад. В момент их создания никто не ожидал такого роста трафика и числа цифровых сервисов. Эти архитектуры работали годами без пересмотра, а новые нагрузки и модели атак стали для них неприятным сюрпризом. С развитием цифровых каналов появился устойчивый миф о регулярных взломах банков ради прямого хищения средств. На практике же многие громкие истории сводились к утечкам учетных данных и слабому контролю доступа, что приводило к волнам мошенничества, росту обращений в кол-центры и массовым перевыпускам карт и учетных записей.
Регулирование и экономика риска
Поступательное усиление регулирования финансового сектора в России также сыграло свою роль. Требования ЦБ, отраслевые стандарты и международные нормы вроде PCI DSS (стандарт безопасности платежных карт) постепенно ужесточаются. То, что раньше носило рекомендательный характер, сегодня переходит в обязательные требования. Это вынуждает банки поддерживать высокий уровень защищенности даже тогда, когда бизнесу это неудобно или дорого.
При этом потери от кибератак остаются значительными. По оценке Сбербанка, совокупный ущерб экономики РФ от кибератак за 2025 год может достигать 1,5 трлн рублей. Во многих случаях успех атаки связан не с высоким уровнем подготовки злоумышленников, а с ошибками самих компаний в гонке за скоростью вывода продуктов на рынок. Бизнес придумывает новый сервис, разработка спешит запустить его раньше конкурентов, а вопросы безопасности отходят на второй план – особенно если безопасность проверяют перед релизом, а не в процессе разработки.
В поспешно выпущенном продукте остаются архитектурные огрехи и непроверенные сценарии работы, что оборачивается внеплановыми остановками сервиса, срочными релизами «в ночь», привлечением внешних подрядчиков и потерей фокуса у продуктовых команд. Такая логика характерна не только для финтеха. Во многих отраслях расчет прост: потенциальная прибыль перекрывает возможные потери от инцидента. Это не столько техническое, сколько управленческое решение: какие сроки считать допустимыми, какие риски – приемлемыми, а какие проблемы можно «решить потом».
Есть и более прагматичный подход. В России в некоторых сегментах дешевле заплатить штраф или принять риск, чем внедрять средства защиты, которые замедлят сервис и ударят по конверсии. Крупные маркетплейсы с огромным трафиком и оборотом денег часто идут именно этим путем. Фактически это означает, что риск осознанно принимается на уровне руководства как допустимый элемент бизнес-модели. Задержка или блокировка легитимных пользователей обходится им дороже, чем редкие атаки, особенно при невысоких санкциях со стороны регуляторов, хотя при крупном инциденте маркетплейсы все же сталкиваются с массовыми возвратами средств, наплывом жалоб и оттоком продавцов и покупателей.
Зоны риска и построение кибербезопасности
Отдельная зона риска – открытые API, то есть программные интерфейсы, через которые сайты, мобильные приложения и внешние сервисы обмениваются данными между собой. Массовый переход к модели API-first привел к тому, что интерфейсы появляются быстрее, чем осмысленная архитектура и контроль. На практике встречаются случаи, когда банк или сервис можно вывести из строя простым некорректным запросом. API падает и тянет за собой веб-интерфейсы и личные кабинеты, из-за чего клиенты не могут войти в аккаунты, оплатить услуги или перевести деньги в течение нескольких часов. При этом владельцы систем часто не знают точное число своих API, не понимают, какие данные через них проходят и когда такие интерфейсы стоит выводить из эксплуатации, – если в компании нет списка всех API и ответственных за них команд, риски практически невозможно контролировать. Компании, которые инвестируют время в такую инвентаризацию заранее, обычно сталкиваются с меньшим числом аварий и проще их локализуют.
Именно на этом уровне часто появляются инфраструктурные меры защиты сетевой безопасности класса WAF – как прослойка, которая берет на себя фильтрацию очевидного мусора и аномалий в HTTP-трафике, снижая нагрузку на команды и уменьшая число инцидентов, вызванных тривиальными ошибками или автоматизированными атаками.
Проблему усугубляет слабое распространение практик безопасной разработки API. Это напрямую связано с тем, какие инициативы получают бюджет и приоритет, а какие считаются вторичными. Описания моделей атак и методов защиты долго оставались нишевыми. Рейтинг консорциума OWASP API Top 10 знают немногие, а системный подход безопасной разработки применяют редко. Чаще всего мешают нехватка экспертизы, инерция процессов и ориентация на поддержку устаревших решений, что приводит к накоплению уязвимостей и росту стоимости их устранения со временем.
Мобильные бэкенды дополняют картину. В них регулярно встречаются простые логические ошибки и просчеты в ограничениях. Через такие уязвимости злоумышленники атакуют не только пользователей, но и сам бизнес. Известны случаи, когда из-за отсутствия лимитов на попытки аутентификации через API за одну ночь сервис SMS-рассылки терял десятки миллионов рублей, – если лимиты на запросы и попытки настраиваются вручную или «по факту», вероятность такого сценария резко возрастает. Как правило, это происходит там, где нет формального требования учитывать такие риски на уровне продуктового планирования. Сегодня похожие атаки направлены на исчерпание токенов и лимитов вспомогательных сервисов, что напрямую увеличивает операционные расходы.
Отдельного внимания требуют системы веб-платежей – те самые узлы, где сходятся пользовательский трафик, деньги, регуляторные требования и репутационные риски. Для бизнеса это не просто еще один сервис, а точка, где любая техническая ошибка немедленно превращается в прямые потери: в недополученную выручку, возвраты средств, рост обращений в поддержку и вопросы со стороны регуляторов и платежных систем. Даже кратковременный сбой на платежной странице обходится дороже, чем аналогичный простой информационного сервиса, потому что он напрямую влияет на конверсию и доверие клиентов.
При этом атаки на веб-платежи редко выглядят как «классический взлом банка». Чаще это перегрузка формы оплаты автоматизированными запросами, попытки подбора параметров транзакций, злоупотребление логикой возвратов, повторные отправки платежей или использование уязвимостей во фронт-энде и связке фронт-бэкенд. Во многих случаях злоумышленнику не нужно проникать внутрь системы – достаточно заставить ее работать в нештатном режиме, чтобы бизнес начал терять деньги и клиентов.
Поэтому защита платежных сервисов строится не вокруг одного средства, а вокруг набора дисциплин. На техническом уровне это изоляция платежного контура от остальной инфраструктуры, жесткие ограничения на параметры транзакций, контроль повторов и аномалий, лимиты на частоту и объем операций, а также мониторинг не только ошибок, но и отклонений в поведении пользователей и трафика. Такие меры позволяют заранее отсекать большую часть автоматизированных атак и логических злоупотреблений, не дожидаясь, пока они превратятся в инцидент.
На процессном уровне важна интеграция требований безопасности в продуктовый цикл. Изменения в платежной логике, интерфейсах и интеграциях с внешними провайдерами требуют такого же внимания к рискам, как и изменения в ядре банковской системы. Это означает обязательную проверку сценариев злоупотреблений, тестирование граничных условий и анализ того, как новая функция может быть использована не по назначению. Команды, которые закладывают это на этапе проектирования, реже сталкиваются с ситуацией, когда новый «удобный» сценарий становится дорогим каналом потерь.
Но даже без прямого ущерба инциденты бьют по репутации. Любой слух об атаке мгновенно отражается на биржевых котировках. Иногда достаточно сообщения в телеграм-канале, чтобы акции пошли вниз. Регуляторы в таких ситуациях усиливают контроль, а компания получает вопросы к качеству управления и контроля рисков, в том числе со стороны совета директоров и инвесторов.
При этом отношение к публичному поиску уязвимостей в банках остается настороженным. Руководство часто воспринимает bug bounty* и работу с белыми хакерами как прямую угрозу репутации. Любое упоминание об уязвимости в публичном поле пугает клиентов, особенно консервативных. Логика проста: раз нашли дыру, значит, могут украсть деньги. Такой подход закрывает канал раннего выявления проблем и оставляет бизнес один на один с реальными злоумышленниками, что повышает вероятность дорогостоящего инцидента вместо контролируемого исправления. В то же время компании, которые используют bug bounty осознанно, чаще получают возможность исправить проблемы до того, как они станут публичными.
Практические шаги по кибербезопасности: дисциплина, инвентаризация и управление рисками
Если говорить проще, большинство атак начинаются не со сложных хакерских трюков, а с обычных технических ошибок и человеческого фактора. Открытые порты, уязвимости в сайтах и интерфейсах обмена данными, ошибки в настройках доступа, работе с базами данных и формами ввода до сих пор играют на руку злоумышленникам. Через эти же механизмы работают клиенты, партнеры и внешние сервисы, поэтому любая недоработка быстро превращается в бизнес-риск и выражается в участившемся простое сервисов, потоке жалоб, потерянных сделках и ручной работе сотрудников. Даже небольшие компании часто строят сложные цепочки интеграций, а в крупных организациях эта конструкция напоминает слоеный пирог из решений разного возраста, где старый фундамент соседствует с новыми надстройками.
В этих условиях защита требует не деклараций, а дисциплины. Компаниям важно контролировать архитектуру, учитывать все интерфейсы и вводить ограничения по умолчанию. Раннее признание проблем значительно снижает ущерб, в отличие от попытки скрыть их до инцидента. Но эта дисциплина начинается не в ИБ-подразделении, а в менеджменте – с того, какие требования включаются в KPI, дорожные карты и критерии готовности продукта.
Начинать стоит с базовых мер. Компаниям важно точно знать, какие веб-сервисы и API работают в инфраструктуре, какие данные через них проходят, и кто за них отвечает. Без этого невозможно ни закрывать уязвимости, ни оценивать риски. Регулярное тестирование, инвентаризация интерфейсов и отключение неиспользуемых точек входа дают быстрый и ощутимый эффект даже без крупных инвестиций. В этом же ряду находятся и прикладные меры вроде WAF – как способ закрыть типовые векторы атак и выиграть время для более глубоких изменений в процессах и архитектуре.
Следующий шаг – встроить безопасность в процесс разработки сервисов. Проверки кода, ограничения доступов по умолчанию, контроль ошибок и лимиты на запросы снижают риск простых, но массовых атак. Это особенно важно для API и мобильных бэкендов, где одна логическая ошибка может привести к прямым финансовым потерям. Скорость вывода продукта не должна отменять базовые проверки.
Также стоит иначе смотреть на внешнюю экспертизу и информацию об ИБ-инцидентах. Работа с белыми хакерами, анализ чужих ошибок и открытый разбор проблем помогают находить слабые места раньше злоумышленников. Репутационные риски в таком подходе ниже, чем последствия реальной атаки, которая почти всегда выходит в публичное поле и стоит бизнесу дороже, чем профилактика. В условиях постоянного давления на цифровые сервисы выигрывают те, кто заранее принимает ограничения и управляет рисками, а не надеется, что проблемы обойдут стороной.
В итоге устойчивость цифровых сервисов – это не столько вопрос отдельных технологий, сколько качество управленческих решений и дисциплины на всех уровнях. Компании, которые заранее считают риски, закладывают безопасность в процессы и принимают осознанные компромиссы, реже сталкиваются с кризисами и переживают их значительно дешевле, чем те, кто реагирует уже постфактум.
*Bug bounty (Баг Баунти), дословно переводится как «награда за ошибку», — программа, в рамках которой организации (компании, государственные учреждения) предлагают денежное вознаграждение (или другие формы поощрения) независимым исследователям безопасности (так называемым «белым хакерам» или «этичным хакерам») за обнаружение и ответственное раскрытие уязвимостей (багов) в их программном обеспечении, веб-сайтах, приложениях или инфраструктуре.
Фото: Предоставлено автором
