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

Семантический анализ: 1. **Основной поисковый запрос:** «тема ВКР по защите клиентских устройств в банке» 2. **LSI-запросы:** архитектура антифрод-систем, проверка endpoint на вредоносное ПО, интеграция антивирусного SDK, микросервисы и Kubernetes, OpenTelemetry для мониторинга, CI/CD, ГОСТ 34.602-89, ISO/IEC 25010, нагрузочное тестирование, RTO/RPO. 3. **Вопросы студентов:** - Как привязать тему ВКР к новым требованиям законодательства? - Нужно ли обязательно писать код для диплома по архитектуре? - Как измерить эффективность системы в ВКР? - Где брать данные для тестирования механизма проверки устройств? - Как правильно оформить ТЗ и диаграммы по ГОСТ? 4. **Ключевые сущности:** ГОСТ 34.602-89 (техническое задание), ISO/IEC 25010 (модель качества), Kubernetes, OpenTelemetry, CI/CD, VirusTotal SDK, микросервисная архитектура, REST API. ```html

Анализ требований банков к проверке устройств клиентов для ВКР: от закона до архитектуры

В марте 2026 года Госдума приняла закон, обязывающий банки проверять устройства пользователей на предмет заражения вредоносным ПО и компенсировать потери, если меры не были приняты. Операторы связи тоже попали в зону ответственности, а клиенты смогут иметь не более 20 карт. Что это значит для студента технического вуза? Снимается старая проблема дипломных работ «про безопасность вообще» — теперь есть конкретная нормативная задача, под которую заказчик (банк) обязан выделить бюджет и внедрить решение. Выпускник, который может спроектировать и обосновать такой сервис, получает серьёзное конкурентное преимущество на рынке труда.

Темы ВКР, которые легко защитить

1. Модуль проверки устройств в мобильном банке

Актуальность: закон прямо требует, чтобы банк знал, заражено ли устройство клиента. Модуль можно встроить в мобильное приложение и на серверную сторону.

Цель: спроектировать и создать прототип модуля, который собирает сигналы о заражении (root-доступ, подозрительные приложения, аномальные разрешения) и принимает решение о блокировке операции.

Задачи:

• Провести сравнительный анализ существующих антивирусных SDK (VirusTotal, Kaspersky, McAfee) и решить, что использовать.
• Спроектировать клиент-серверную архитектуру модуля, включая REST API для обмена данными.
• Реализовать минимально жизнеспособное решение (MVP), провести его тестирование на синтетических данных.
• Оценить нагрузку и время отклика сервиса.

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

2. Антифрод-система на основе оценки заражённости устройства

Актуальность: закон требует не просто проверять, но и компенсировать потери. Банку выгоднее предотвратить перевод с заражённого устройства, чем платить потом.

Цель: разработать алгоритм или модель, которая определяет степень риска операции, анализируя состояние устройства.

Задачи:

• Исследовать типы вредоносного ПО и индикаторы компрометации.
• Собрать и размеченный датасет (или использовать синтетический).
• Построить модель скоринга на основе правил или ML.
• Оценить точность, полноту и F1-меру на тестовой выборке.

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

3. Масштабируемый сервис проверки устройств на Kubernetes

Актуальность: если банк обслуживает миллионы клиентов, сервис проверки должен быть отказоустойчивым и легко масштабироваться. Здесь в дело вступают современные инструменты — Kubernetes и OpenTelemetry.

Цель: спроектировать облачную инфраструктуру для сервиса проверки устройств.

Задачи:

• Контейнеризировать сервис и развернуть его в Kubernetes.
• Настроить сбор метрик, логов и трейсов через OpenTelemetry.
• Построить CI/CD-пайплайн для автоматического обновления.
• Провести нагрузочное тестирование и измерить RTO/RPO.

Структура: Глава 1 — обзор облачных технологий. Глава 2 — архитектура и оркестрация. Глава 3 — тестирование и анализ производительности.

Как использовать закон в дипломе

Аналитическая глава: сравнение решений

В первой главе традиционно проводится обзор. Теперь появилась точка опоры: вы анализируете, как банк может выполнить требования закона. Покажите таблицу сравнения вариантов реализации модуля — например, покупка готового SDK, интеграция внешнего API или разработка собственного сервиса.

Такая таблица показывает, что вы умеете системно сравнивать решения и обосновывать выбор — именно это любят члены аттестационной комиссии. Не забудьте добавить ссылку на закон и статью CNews в список источников.

Проектная часть: архитектура и интеграция

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

Мобильное приложение —> Bank API —> Сервис проверки устройств
                           |
                           +--> Антивирусный движок (или внешний API)
                           +--> ML-модуль скоринга
                           +--> OpenTelemetry Collector

Каждый компонент раскрывайте отдельно: какие данные собираются (разрешения, список приложений, jailbreak/root), как они передаются (REST/gRPC), как обеспечивается безопасность канала. Если используете Kubernetes — опишите deployment, создание HPA для автоскейлинга.

Тестирование и метрики

Третья глава должна содержать конкретные цифры. Существуют стандартные метрики для таких систем:

• Точность детектирования — доля верно выявленных заражений (не менее 95% на вашем датасете).
• Процент ложных срабатываний — важно для банка, чтобы не блокировать честных клиентов.
• Время отклика — p95 не должен превышать 500 мс, иначе клиенты будут недовольны.
• RTO/RPO — если сервис упал, банк должен восстановить работу за 15 минут и при этом не потерять данные.

Для получения метрик можно использовать JMeter или k6 для нагрузочного тестирования, а OpenTelemetry поможет построить трейсы и профили медленных запросов. Это даёт наглядный материал для таблиц и графиков в работе.

Чему вы научитесь в процессе работы

Вы прокачаете не только технические навыки, но и умение обосновывать решения. Конкретно:

• Проводить анализ нормативных требований и преобразовывать их в технические условия.
• Сравнивать архитектурные альтернативы с помощью таблиц и моделей.
• Проектировать микросервисы и разворачивать их в Kubernetes.
• Настраивать наблюдаемость через OpenTelemetry.
• Оформлять техническое задание по ГОСТ 34.602-89, а критерии качества — по ISO/IEC 25010.

FAQ: вопросы, которые волнуют студентов

Нужно ли писать код для такой ВКР?

В большинстве вузов — да. Но если ваша специальность — «бизнес-информатика» или «менеджмент ИТ-проектов», можно сдать архитектурное проектирование и экономическое обоснование без реализации. Уточните требования своего научного руководителя заранее. Однако вам всё равно понадобится прототип, хотя бы в виде диаграмм или псевдокода.

Как оформить диаграммы?

Используйте UML (диаграмма компонентов, диаграмма последовательностей) или модель C4. В пояснительной записке каждая диаграмма должна подписана по ГОСТ: «Рисунок 2.1 — Архитектура сервиса проверки устройств».

Где брать данные для тестирования?

Реальные данные банков недоступны, поэтому берите синтетические датасеты: можно вручную разметить 100–200 запросов, имитирующих заражённые и чистые устройства. В открытых источниках есть готовые коллекции — например, наборы с Cuckoo Sandbox. Помните, что для диплома допустима небольшая выборка, главное — описать методику её сбора.

Сложно ли реализовать такой проект самостоятельно?

Если вы учились на курсах по Java/Go/Python и Docker — вполне реально. Сложность выше средней, но тема настолько горячая, что многие выбирают именно её. В случае нехватки времени можно заказать помощь с дипломом, но лучше заранее спланировать объём работы.

Источник: Банки обязали проверять клиентов на предмет заражения ПО (опубликовано 2026-03-17)

```