Опубликовано: 01.10.2026 | Источник: CNews (новости)

Защита банковских приложений от ботов в ВКР: архитектура антифрода и метрики обнаружения

Поддомен: Cybersecurity. Роль эксперта: специалист по информационной безопасности.

Введение

По данным CNews, банковские приложения россиян атакуют круглосуточно — без выходных и перерывов на обед. И делают это не люди, а боты: масштаб впечатляет даже опытных специалистов по кибербезопасности, а искусственный интеллект в таких схемах работает как ускоритель. Для выпускника ИТ-направления это не просто новость, а готовая постановка задачи. Массовый автоматизированный трафик ломает привычную модель защиты, где в центре стоял человек-злоумышленник.

Что это даёт вам как автору выпускной квалификационной работы? Возможность построить ВКР вокруг реальной, измеримой и защищаемой проблемы: обнаружение и блокировка автоматизированных атак на клиентский банковский сервис. Ниже — как разложить эту тему по главам, какие метрики считать в третьей главе и где чаще всего спотыкаются на защите.

Частые вопросы студентов по этой теме

Можно ли взять реальные логи банка? Где искать данные для обучения модели?

Реальные логи банка вы не получите — это банковская тайна и коммерческая чувствительная информация. Три рабочих пути: (1) публичные датасеты веб-логов и трафика (CIC-IDS, CSE-CIC-IDS2018, HTTP CSIC 2010) — их легко переразметить под задачу «бот / человек»; (2) генерация синтетики — сами поднимаете стенд с эмуляцией клиентских сессий и снимаете телеметрию; (3) гибрид: публичный датасет для обучения, синтетический для валидации на «своём» профиле угроз. В главе 1 обязательно опишите ограничения данных и то, как вы компенсировали их — комиссия любит именно этот абзац.

Что выбрать: правила (WAF, rate limiting) или машинное обучение?

Не «или», а «и». Правила ловят грубые, известные сценарии (OAT-011 Scraping, OAT-004 Fingerprinting, credential stuffing) с почти нулевым FPR, но обходятся ротацией IP и прокси. Модель ловит поведенческие аномалии, но требует данных и объяснимости. Грамотная архитектура — каскад: детерминированные фильтры на периметре, затем скоринг сессии, затем ручная верификация для «серой зоны». Такая двухуровневая схема отлично смотрится на C4-диаграмме и легко защищается.

Какие метрики считать в третьей главе, чтобы это выглядело по-инженерному?

Для модели: precision, recall, F1, ROC-AUC, PR-AUC (важнее при сильном дисбалансе классов), а также FPR при фиксированном пороге — в антифроде цена ложного срабатывания выше, чем цена пропуска. Для системы: MTTD (среднее время до обнаружения), доля заблокированного автоматизированного трафика, прирост задержки p95/p99 на API, потребление CPU на узле балансировки. И то, и другое привяжите к характеристикам качества по ISO/IEC 25010 — производительность, безопасность, надёжность.

Хватит ли одной третьей главы, чтобы всё это проверить?

Хватит, если заранее сузить периметр. Не пытайтесь «защитить банк целиком» — возьмите один сценарий, например массовый перебор учётных данных или автоматизированный парсинг тарифов через мобильное API. Тогда тестирование укладывается в три подраздела: функциональная проверка детектора, нагрузочное тестирование (k6, Locust), оценка качества классификации на отложенной выборке.

Темы ВКР на основе этого кейса

• Тема 1. Обнаружение автоматизированных атак на API мобильного банка на основе поведенческого скоринга сессий

  Актуальность: статья прямо фиксирует переход от ручных атак к ботовым, работающим круглосуточно; классические сигнатурные фильтры такой поток не держат.

  Цель: разработать компонент поведенческого анализа сессий, снижающий долю успешных автоматизированных операций.

  Задачи: 1) обзор OWASP Automated Threats и модели нарушителя; 2) проектирование признакового пространства (тайминги запросов, энтропия User-Agent, TLS-отпечаток JA4, траектория навигации); 3) реализация скоринга и интеграция с API Gateway; 4) оценка precision/recall и FPR на отложенной выборке.

  Структура: Гл.1 — анализ угроз и существующих решений; Гл.2 — архитектура и реализация конвейера признаков и модели; Гл.3 — эксперименты, метрики, нагрузочные испытания.

• Тема 2. Защита клиентского веб-приложения банка от credential stuffing: гибридная модель правил и машинного обучения

  Актуальность: ботовые атаки на формы входа — самый массовый сценарий; ИИ ускоряет подбор и обход капчи.

  Цель: построить каскадный фильтр, объединяющий rate limiting, репутационные списки и ML-классификатор.

  Задачи: 1) формализовать признаки распределённой атаки; 2) настроить периметр (nginx/Kong, WAF, лимиты по подсетям); 3) обучить и объяснить модель (SHAP); 4) измерить компромисс «блокировка vs. доступность».

  Структура: Гл.1 — теория и анализ инцидентов; Гл.2 — проектирование каскада и конфигурации; Гл.3 — испытания, метрики, экономическая оценка.

• Тема 3. Мониторинг и раннее предупреждение ботовых атак в микросервисной среде банка

  Актуальность: масштаб атак растёт, а ИТ-ландшафт банка — микросервисы; без наблюдаемости инцидент замечают по факту потерь.

  Цель: спроектировать подсистему телеметрии и алертинга, выявляющую аномальные профили трафика.

  Задачи: 1) определить набор метрик и трасс; 2) развернуть коллектор OpenTelemetry в Kubernetes; 3) настроить правила алертов и дежурные пороги; 4) провести имитацию атаки и замерить MTTD.

  Структура: Гл.1 — анализ архитектуры и требований к наблюдаемости; Гл.2 — реализация сбора, хранения и визуализации; Гл.3 — сценарии атак, замеры, выводы.

Основная часть: как разложить кейс по главам

Глава 1. Анализ угроз: от новости к формальной постановке

Технический кейс из статьи превращается в научный текст через три артефакта. Первый — модель нарушителя: кто атакует, какие ресурсы имеет (ботнет, прокси, генеративный ИИ для имитации поведения), какова его мотивация (перебор учёток, парсинг, накрутка, отмывание). Второй — дерево угроз по OWASP Automated Threats to Web Applications: перечислите релевантные категории, покажите, какие из них описаны в вашей работе. Третий — диаграмма потоков данных (DFD по ГОСТ 19.701 или BPMN) с явным указанием точек контроля.

Здесь же хорошо работает сравнение существующих решений: коммерческие антибот-платформы, WAF, капча-сервисы, поведенческая биометрия. Не нужно описывать всё — достаточно таблицы из 4–5 решений по критериям «тип детекции», «устойчивость к обходу», «влияние на UX», «стоимость владения».

Глава 2. Проектирование и реализация: каскад и наблюдаемость

Архитектуру рисуйте в нотации C4 — от контекста до контейнеров. Типовая схема для банковского периметра: мобильный клиент → CDN/балансировщик → WAF с лимитами → API Gateway → сервис скоринга → антифрод-хранилище → SIEM. Сервис скоринга общается с потоком событий (Kafka), признаки считаются в потоковом режиме, модель отдаёт решение в пределах миллисекунд.

Отдельный подраздел — признаки. Именно здесь видно, читали ли вы литературу. Соединяйте сетевой уровень (TLS-отпечаток, репутация ASN), уровень приложения (частота запросов, набор эндпоинтов, наличие заголовков) и поведенческий уровень (тайминги между действиями, энтропия движений, отклонение от «человеческого» профиля).

# Фрагмент конвейера скоринга сессии (упрощённый псевдокод)
FEATURES = [
    "req_per_min",          # интенсивность запросов в сессии
    "endpoint_entropy",     # энтропия распределения эндпоинтов
    "ua_reputation",        # репутация User-Agent
    "tls_ja4_cluster",      # кластер TLS-отпечатка
    "inter_req_gap_cv",     # коэффициент вариации пауз между запросами
    "auth_fail_ratio",      # доля неуспешных попыток входа
]

def score_session(event, model, threshold=0.72):
    vec = build_vector(event, FEATURES)
    p_bot = model.predict_proba([vec])[0][1]      # вероятность автоматизации
    if p_bot >= 0.90:
        return "BLOCK", p_bot
    if p_bot >= threshold:
        return "CHALLENGE", p_bot                 # капча / step-up аутентификация
    return "ALLOW", p_bot

Передайте сюда же конфигурацию периметра — комиссия редко видит реальные лимиты и обычно довольна:

# nginx: ограничение скорости и защита от всплесков
limit_req_zone $binary_remote_addr zone=login_zone:10m rate=5r/m;
limit_req_zone $http_authorization zone=api_zone:10m rate=120r/m;

location /api/v1/auth/login {
    limit_req zone=login_zone burst=3 nodelay;
    limit_req_status 429;
    proxy_pass http://auth_upstream;
}

Наблюдаемость описывайте через OpenTelemetry: единый формат трасс и метрик, экспорт в коллектор, затем в хранилище и дашборд. Обязательно зафиксируйте, какие атрибуты вы прокидываете в спаны (session_id, device_hash, geo, решение детектора) — это объясняет, как вы позже считаете MTTD.

Глава 3. Тестирование и оценка эффективности

Третья глава — место, где ВКР перестаёт быть рефератом. Разделите её на три блока. Первый — качество детектора: отложенная выборка, стратифицированная по типам ботов, матрица ошибок, кривые ROC и PR. Отдельно посчитайте FPR при пороге, который вы выбрали для продакшена, и объясните выбор порога через стоимость ошибок. Второй — производительность: нагрузочное тестирование k6 или Locust, замеры задержки на добавленный скоринг, потребление памяти и CPU. Третий — устойчивость к обходу: сценарии с ротацией прокси, медленными ботами, имитацией человеческих пауз. Если ваш детектор падает при медленной атаке — это честный вывод, а не провал. Провал — это не заметить этого.

Результаты сводите к характеристикам ISO/IEC 25010: функциональная полнота, производительность, безопасность, надёжность. Так выводы получают внешнюю рамку и не выглядят набором случайных чисел.

Чему вы научитесь на этой теме

• Строить модель нарушителя и дерево угроз под конкретный бизнес-сценарий, а не «вообще про хакеров».
• Проектировать каскадную защиту, где правила и ML не заменяют, а дополняют друг друга.
• Считать метрики бинарной классификации при сильном дисбалансе классов и объяснять выбор порога.
• Настраивать наблюдаемость микросервисов через OpenTelemetry и Kubernetes — навык, который прямо спрашивают на собеседованиях.
• Оформлять архитектурные схемы в C4/UML и текстовые разделы по ГОСТ 34.601 без переписывания работы заново.

Источник: Мошенники атакуют банковские приложения россиян ботами для массовых кибератак (опубликовано 2026-03-26)