Как написать ВКР на тему «Разработка информационной системы электронных банковских услуг»

Как написать ВКР на тему: «Разработка информационной системы электронных банковских услуг (на примере «…»)»

Нужна работа по этой теме?

Получите консультацию за 10 минут! Мы знаем все требования к ВКР по направлению Программная инженерия и поможем реализовать безопасную банковскую систему с полным циклом платежей и переводов.

Telegram: @Diplomit
Телефон/WhatsApp: +7 (987) 915-99-32
Email: admin@diplom-it.ru

Заказать ВКР онлайн

Почему тема банковской системы требует особого подхода к безопасности?

Выпускная квалификационная работа по направлению «Программная инженерия» на тему банковской системы имеет критически важную специфику. В отличие от обычных веб-приложений, здесь требуется не только техническая реализация, но и строгое соответствие нормативным требованиям финансового сектора с продуманной архитектурой безопасности на каждом уровне.

Ключевая сложность темы «Разработка информационной системы электронных банковских услуг» — необходимость баланса между:

• Безопасностью и удобством: двухфакторная аутентификация повышает безопасность, но усложняет пользовательский опыт — нужно найти оптимальный баланс
• Соответствием нормативам и технической реализацией: требования ЦБ РФ, ФЗ-152, PCI DSS должны быть не просто упомянуты, а реализованы в коде и архитектуре
• Отказоустойчивостью и производительностью: банковская система должна работать 24/7 с минимальными задержками даже при пиковых нагрузках
• Интеграцией с внешними системами: взаимодействие с платёжными системами (МИР, Visa, Mastercard), системами межбанковских переводов (СПБ, БЭСП), корпоративными системами банка

Даже при хорошем знании веб-разработки студенты теряют баллы из-за типичных ошибок: отсутствие глубокого анализа нормативных требований, поверхностная реализация безопасности («просто добавили пароль»), отсутствие аудита операций, нереалистичные экономические расчёты. Особенно критична ошибка — реализация «учебной» системы без учёта требований ЦБ РФ к защите финансовых данных и аутентификации пользователей.

В этой статье вы получите пошаговый план с учётом требований программной инженерии и финансового сектора, примеры реализации ключевых модулей с акцентом на безопасность, шаблоны для описания архитектуры и методики оценки эффективности. Это практическое руководство поможет избежать типичных ошибок и подготовить работу объёмом 60–70 страниц, полностью соответствующую требованиям вуза (оригинальность ≥80%).

Сложности с анализом нормативных требований или проектированием архитектуры безопасности?

Мы подготовим детальный план с привязкой к каждому разделу ВКР и примерами для банковской системы.

Telegram: @Diplomit | Телефон: +7 (987) 915-99-32

Получить план работы

Структура ВКР по направлению Программная инженерия: детальный разбор

Введение

Цель раздела: Обосновать актуальность темы, сформулировать цель, задачи, объект, предмет исследования, методы, новизну.

Пошаговая инструкция:

1. Актуальность: Опишите рост рынка цифровых банковских услуг и угрозы безопасности. Приведите статистику: по данным ЦБ РФ (2025), объём операций через мобильные приложения банков вырос на 67% за год, достигнув 148 трлн руб.; при этом количество мошеннических операций увеличилось на 43%, убытки клиентов составили 28.7 млрд руб.; 76% банков не соответствуют требованиям Указания ЦБ РФ №5791-У по двухфакторной аутентификации. Укажите, что современные требования (ФЗ-152, ФЗ-161, PCI DSS, Указания ЦБ РФ) обязывают кредитные организации обеспечивать многоуровневую защиту финансовых данных и операций клиентов.
2. Цель исследования: «Разработка информационной системы электронных банковских услуг для [название банка-примера] с обеспечением многоуровневой безопасности, соответствием требованиям ЦБ РФ и ФЗ-152, а также достижением экономического эффекта за счёт сокращения операционных издержек и повышения лояльности клиентов».
3. Задачи исследования:
   • Провести анализ требований нормативных документов (ФЗ-152, ФЗ-161, Указания ЦБ РФ, PCI DSS) к системам электронных банковских услуг
   • Исследовать существующие решения (Сбербанк Онлайн, Тинькофф, Альфа-Мобайл) и выявить их недостатки в части безопасности и удобства
   • Разработать функциональные и нефункциональные требования к информационной системе
   • Спроектировать архитектуру системы с учётом требований безопасности и отказоустойчивости
   • Реализовать ключевые модули системы: аутентификацию, платежи, переводы, аудит операций
   • Обеспечить интеграцию с платёжными системами и корпоративными системами банка
   • Провести тестирование на соответствие требованиям безопасности и оценить экономическую эффективность
4. Объект исследования: Процессы предоставления электронных банковских услуг в кредитной организации.
5. Предмет исследования: Программное обеспечение информационной системы электронных банковских услуг.
6. Методы исследования: Анализ нормативных документов, сравнительный анализ существующих решений, проектирование архитектуры (диаграммы компонентов UML), объектно-ориентированное программирование, тестирование на уязвимости (OWASP, PCI DSS), экономический анализ.
7. Новизна: Комбинация современной микросервисной архитектуры с реализацией требований ЦБ РФ к двухфакторной аутентификации и защите финансовых данных, включая адаптивную систему безопасности на основе анализа поведения пользователя.

Типичные сложности и временные затраты:

• Ошибка 1: Актуальность без привязки к реальным угрозам и требованиям ЦБ РФ («банковские приложения популярны» вместо «43% рост мошенничества, 76% банков не соответствуют Указанию №5791-У»).
• Ошибка 2: Цель не отражает критическую важность безопасности («сделать приложение для банка» вместо «разработать систему с обеспечением многоуровневой безопасности и соответствием требованиям ЦБ РФ»).
• Ориентировочное время: 8–10 часов (формулировка, согласование с научным руководителем).

Глава 1. Анализ предметной области и нормативных требований

1.1. Требования нормативных документов к банковским системам

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

Пошаговая инструкция:

1. Ключевые нормативные документы:

   Документ	Основные требования	Применение в системе
   ФЗ-152 «О ПДн»	Защита персональных данных, согласие на обработку, хранение на территории РФ, шифрование	Шифрование ПДн при хранении (AES-256), получение согласия при регистрации, аудит доступа к ПДн
   ФЗ-161 «О НПС»	Требования к платёжным операциям, идентификация участников, защита от мошенничества	Валидация реквизитов, лимиты на операции, система мониторинга подозрительных транзакций
   Указание ЦБ РФ №5791-У	Обязательная двухфакторная аутентификация для всех операций с деньгами	Реализация 2FA через SMS/TOTP/биометрию для входа и подтверждения операций
   Указание ЦБ РФ №3894-У	Требования к защите информации в кредитных организациях	Сегментация сети, межсетевые экраны, системы обнаружения вторжений (IDS)
   PCI DSS v4.0	Защита данных платёжных карт, шифрование, регулярные проверки безопасности	Шифрование PAN при хранении, маскирование карт в интерфейсе, ежеквартальное сканирование уязвимостей

2. Анализ угроз безопасности банковских систем:
   • Фишинг и социальная инженерия: 58% мошеннических операций начинаются с фишинга (данные ЦБ РФ)
   • Утечка учётных данных: использование слабых паролей, перехват SMS-кодов
   • Атаки на клиентское приложение: реверс-инжиниринг, модификация кода, перехват трафика
   • Атаки на серверную часть: SQL-инъекции, межсайтовый скриптинг (XSS), DDoS
   • Внутренние угрозы: несанкционированный доступ сотрудников к данным клиентов

1.2. Анализ существующих решений и их недостатков

Цель раздела: Обосновать необходимость разработки новой системы или улучшения существующей.

Пошаговая инструкция:

1. Сравнительный анализ банковских приложений:

Пример таблицы сравнения банковских приложений:

Вывод: «Анализ существующих решений показал, что большинство банковских приложений не обеспечивают полного соответствия требованиям ЦБ РФ, особенно в части обязательной двухфакторной аутентификации (Указание №5791-У). Предлагаемая система закрывает эти пробелы за счёт реализации обязательной 2FA для всех операций с деньгами, адаптивной аутентификации на основе поведенческого анализа и многоуровневой защиты финансовых данных с соответствием всем нормативным требованиям».

Типичные сложности и временные затраты:

• Ошибка 1: Отсутствие анализа конкретных нормативных документов с привязкой к требованиям системы.
• Ошибка 2: Нет сравнительной таблицы существующих решений с обоснованием недостатков и преимуществ предлагаемой системы.
• Ориентировочное время: 25–30 часов (изучение нормативов, анализ приложений, написание).

Сложности с анализом нормативных требований или сравнением решений?

Наши эксперты подготовят Главу 1 с детальным анализом требований ЦБ РФ, ФЗ-152, PCI DSS и обоснованием выбора архитектурных решений.

Telegram: @Diplomit | Телефон: +7 (987) 915-99-32

Заказать помощь по разделам

Глава 2. Проектирование архитектуры информационной системы

2.1. Формализация требований к системе

Цель раздела: Систематизировать все требования к разрабатываемой системе.

Пошаговая инструкция:

1. Функциональные требования (согласно IEEE 830):

   ID	Требование	Приоритет
   FR-01	Система должна обеспечивать двухфакторную аутентификацию для входа и подтверждения операций (в соответствии с Указанием ЦБ РФ №5791-У)	Критический
   FR-02	Система должна поддерживать операции: переводы между счетами, платежи в бюджет, оплата услуг, покупка валюты	Высокий
   FR-03	Система должна вести полный аудит всех операций с сохранением в защищённом журнале (в соответствии с ФЗ-152)	Критический
   FR-04	Система должна обеспечивать шифрование персональных данных клиентов при хранении и передаче (в соответствии с ФЗ-152 и PCI DSS)	Критический
   FR-05	Система должна поддерживать интеграцию с платёжными системами (МИР, СПБ) и корпоративными системами банка (БЭСП, АБС)	Средний
   FR-06	Система должна обеспечивать адаптивную аутентификацию на основе анализа поведения пользователя	Средний

2. Нефункциональные требования:
   • Безопасность: соответствие требованиям ЦБ РФ, ФЗ-152, PCI DSS, защита от OWASP Top 10
   • Отказоустойчивость: доступность 99.99%, автоматическое переключение на резервные системы
   • Производительность: время подтверждения операции ≤ 5 сек, поддержка 10 000+ одновременных пользователей
   • Масштабируемость: горизонтальное масштабирование без остановки системы

2.2. Архитектура программной системы

Цель раздела: Представить детальное проектирование системы с обоснованием выбора технологий и решений безопасности.

Пошаговая инструкция:

1. Технологический стек:
   • Frontend (мобильное приложение): React Native + TypeScript (кроссплатформенность) + React Native Biometrics (биометрия)
   • Frontend (веб-версия): React 18 + TypeScript + WebAuthn API (биометрия в браузере)
   • Backend: Java 17 + Spring Boot 3 (микросервисы) + Spring Security (безопасность)
   • База данных: PostgreSQL 14 (основная БД) + Redis (кеширование, сессии) + MongoDB (логи аудита)
   • Безопасность:
     • HashiCorp Vault — управление секретами (ключи шифрования, токены)
     • Keycloak — централизованное управление аутентификацией и авторизацией
     • ModSecurity — WAF для защиты от атак на веб-интерфейс
   • Инфраструктура: Docker + Kubernetes (оркестрация), Nginx (балансировщик), ELK Stack (логирование)
2. Диаграмма компонентов с акцентом на безопасность:

   ┌──────────────────────────────────────────────────────────────────────────────┐
   │                          Мобильное приложение / Веб-интерфейс                │
   │  ┌──────────────────────────────────────────────────────────────────────┐    │
   │  │  Аутентификация (биометрия, 2FA)                                     │    │
   │  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  │    │
   │  │  │  Переводы   │  │  Платежи    │  │  Валюта     │  │  История    │  │    │
   │  │  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘  │    │
   │  └──────────────────────────────────────────────────────────────────────┘    │
   └───────────────────────────────┬──────────────────────────────────────────────┘
                                   │ HTTPS + TLS 1.3
                           ┌───────▼────────┐
                           │  API Gateway   │
                           │  (Nginx +      │
                           │   ModSecurity) │ ← WAF защищает от атак
                           └───────┬────────┘
                                   │
           ┌───────────────────────┼───────────────────────┐
           │                       │                       │
   ┌───────▼────────┐    ┌────────▼────────┐    ┌────────▼────────┐
   │ Auth Service   │    │ Payment Service │    │ Audit Service   │
   │ (Keycloak +    │    │ (Микросервис    │    │ (Запись всех    │
   │  2FA)          │    │  платежей)      │    │  операций)      │
   └───────┬────────┘    └────────┬────────┘    └────────┬────────┘
           │                      │                      │
           └──────────────────────┼──────────────────────┘
                                  │
           ┌──────────────────────┼──────────────────────┐
           │                      │                      │
   ┌───────▼────────┐    ┌────────▼────────┐    ┌────────▼────────┐
   │  PostgreSQL    │    │     Redis       │    │  HashiCorp      │
   │  (Основная БД) │    │  (Сессии,       │    │  Vault          │
   │  + шифрование  │    │   кеширование)  │    │  (Секреты)      │
   └────────────────┘    └─────────────────┘    └─────────────────┘
           │                      │                      │
           └──────────────────────┼──────────────────────┘
                                  │
           ┌──────────────────────┼──────────────────────┐
           │                      │                      │
   ┌───────▼────────┐    ┌────────▼────────┐    ┌────────▼────────┐
   │  Платёжные     │    │  Корпоративные  │    │  ELK Stack      │
   │  системы       │    │  системы банка  │    │  (Логирование)  │
   │  (СПБ, МИР)    │    │  (БЭСП, АБС)    │    │                 │
   └────────────────┘    └─────────────────┘    └─────────────────┘
   	

3. Проектирование базы данных (основные таблицы с учётом аудита):

   -- Таблица пользователей с безопасным хранением данных
   CREATE TABLE users (
       id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
       phone VARCHAR(20) UNIQUE NOT NULL,  -- Номер телефона (основной идентификатор)
       email VARCHAR(255) UNIQUE,
       password_hash VARCHAR(255) NOT NULL,  -- Argon2id хеширование
       pin_hash VARCHAR(255),  -- Хеш PIN-кода для быстрого входа
       biometric_key_encrypted TEXT,  -- Зашифрованный ключ биометрии
       is_2fa_enabled BOOLEAN DEFAULT TRUE,  -- Обязательная 2FA (требование ЦБ РФ)
       status VARCHAR(20) DEFAULT 'active',  -- active, blocked, deleted
       created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
       last_login TIMESTAMP,
       CONSTRAINT valid_phone CHECK (phone ~ '^\+7\d{10}$')
   );
   -- Таблица счетов клиентов
   CREATE TABLE accounts (
       id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
       user_id UUID REFERENCES users(id) ON DELETE CASCADE,
       account_number VARCHAR(20) UNIQUE NOT NULL,  -- Номер счёта
       currency VARCHAR(3) DEFAULT 'RUB',  -- Валюта счёта
       balance NUMERIC(15, 2) DEFAULT 0.00 CHECK (balance >= 0),
       status VARCHAR(20) DEFAULT 'active',  -- active, blocked
       created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
       updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
   );
   -- Таблица операций с полным аудитом (требование ФЗ-152)
   CREATE TABLE transactions (
       id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
       user_id UUID NOT NULL REFERENCES users(id),
       account_from UUID REFERENCES accounts(id),  -- Счёт отправителя
       account_to UUID REFERENCES accounts(id),    -- Счёт получателя
       amount NUMERIC(15, 2) NOT NULL CHECK (amount > 0),
       currency VARCHAR(3) DEFAULT 'RUB',
       operation_type VARCHAR(50) NOT NULL,  -- transfer, payment, currency_exchange
       status VARCHAR(20) DEFAULT 'pending',  -- pending, completed, failed, cancelled
       description TEXT,
       ip_address INET NOT NULL,  -- IP-адрес для аудита
       device_info JSONB,  -- Информация об устройстве
       risk_score NUMERIC(3, 2),  -- Оценка риска операции (0.00-1.00)
       created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
       completed_at TIMESTAMP,
       -- Поля для аудита (требование ФЗ-152 и ЦБ РФ)
       audit_user_id UUID,  -- Кто изменил статус операции (для внутренних операций)
       audit_timestamp TIMESTAMP,
       audit_reason TEXT  -- Причина изменения статуса
   );
   -- Журнал аудита всех действий с ПДн (требование ФЗ-152 ст. 18.1)
   CREATE TABLE pdn_audit_log (
       id BIGSERIAL PRIMARY KEY,
       user_id UUID NOT NULL REFERENCES users(id),
       operation_type VARCHAR(50) NOT NULL,  -- view, modify, delete
       entity_type VARCHAR(50) NOT NULL,  -- user, account, transaction
       entity_id UUID NOT NULL,
       field_changed VARCHAR(100),  -- Какое поле изменено
       old_value TEXT,
       new_value TEXT,
       ip_address INET NOT NULL,
       user_agent TEXT,
       timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
       CONSTRAINT valid_operation CHECK (operation_type IN ('view', 'modify', 'delete', 'access'))
   );
   -- Индексы для производительности и безопасности
   CREATE INDEX idx_transactions_user_status ON transactions(user_id, status, created_at DESC);
   CREATE INDEX idx_transactions_created ON transactions(created_at DESC);
   CREATE INDEX idx_pdn_audit_user ON pdn_audit_log(user_id, timestamp DESC);
   CREATE INDEX idx_pdn_audit_timestamp ON pdn_audit_log(timestamp DESC);
   	

Глава 3. Реализация программного обеспечения

3.1. Реализация модуля двухфакторной аутентификации

Цель раздела: Детально описать реализацию критически важного компонента системы с учётом требований ЦБ РФ.

Пошаговая инструкция:

1. Реализация гибридной 2FA с поддержкой нескольких методов:

   // AuthService.java (Spring Boot)
   @Service
   @RequiredArgsConstructor
   public class AuthService {
       private final UserRepository userRepository;
       private final SmsService smsService;
       private final TotpService totpService;
       private final BiometricService biometricService;
       private final AuditService auditService;
       /**
        * Инициация процесса аутентификации
        * Соответствует требованиям Указания ЦБ РФ №5791-У (обязательная 2FA)
        */
       public AuthInitResponse initiateAuth(String phone) {
           // Поиск пользователя по номеру телефона
           User user = userRepository.findByPhone(phone)
               .orElseThrow(() -> new UserNotFoundException("Пользователь не найден"));
           // Проверка статуса пользователя
           if (!user.getStatus().equals("active")) {
               throw new UserBlockedException("Учётная запись заблокирована");
           }
           // Генерация одноразового кода (6 цифр)
           String otpCode = generateOtpCode();
           // Сохранение кода в кэше с временем жизни 5 минут
           String cacheKey = "otp:" + phone;
           redisTemplate.opsForValue().set(cacheKey, otpCode, 5, TimeUnit.MINUTES);
           // Отправка SMS с кодом
           smsService.sendSms(phone, "Ваш код подтверждения: " + otpCode);
           // Запись в журнал аудита
           auditService.logAuthAttempt(user.getId(), phone, "SMS", "INITIATED");
           return AuthInitResponse.builder()
               .sessionId(generateSessionId())
               .phoneMask(maskPhone(phone))
               .expiresIn(300) // 5 минут
               .build();
       }
       /**
        * Подтверждение кода и завершение аутентификации
        */
       @Transactional
       public AuthResponse verifyOtp(String sessionId, String otpCode, String phone) {
           // Проверка кода из кэша
           String cacheKey = "otp:" + phone;
           String storedCode = redisTemplate.opsForValue().get(cacheKey);
           if (storedCode == null) {
               auditService.logAuthAttempt(null, phone, "SMS", "EXPIRED");
               throw new OtpExpiredException("Код подтверждения истёк");
           }
           if (!storedCode.equals(otpCode)) {
               // Учёт неудачных попыток (защита от brute force)
               incrementFailedAttempts(phone);
               if (getFailedAttempts(phone) >= 5) {
                   blockUserTemporarily(phone);
                   auditService.logAuthAttempt(null, phone, "SMS", "BLOCKED_AFTER_5_FAILED");
                   throw new UserBlockedException("Учётная запись временно заблокирована");
               }
               auditService.logAuthAttempt(null, phone, "SMS", "FAILED");
               throw new InvalidOtpException("Неверный код подтверждения");
           }
           // Получение пользователя
           User user = userRepository.findByPhone(phone)
               .orElseThrow(() -> new UserNotFoundException("Пользователь не найден"));
           // Сброс счётчика неудачных попыток
           resetFailedAttempts(phone);
           // Генерация JWT токена с коротким сроком жизни (15 минут)
           String accessToken = jwtService.generateToken(user, 15);
           String refreshToken = jwtService.generateRefreshToken(user, 43200); // 30 дней
           // Запись успешной аутентификации в аудит
           auditService.logAuthAttempt(user.getId(), phone, "SMS", "SUCCESS");
           // Очистка OTP из кэша
           redisTemplate.delete(cacheKey);
           return AuthResponse.builder()
               .accessToken(accessToken)
               .refreshToken(refreshToken)
               .userId(user.getId())
               .phone(user.getPhone())
               .is2faEnabled(user.is2faEnabled())
               .build();
       }
       /**
        * Подтверждение операции с деньгами (требование ЦБ РФ)
        * Используется отдельный код для каждой операции
        */
       public boolean confirmOperation(UUID userId, UUID operationId, String otpCode) {
           // Генерация уникального ключа для операции
           String operationKey = "op:" + operationId.toString();
           // Получение сохранённого кода для операции
           String storedCode = redisTemplate.opsForValue().get(operationKey);
           if (storedCode == null || !storedCode.equals(otpCode)) {
               auditService.logOperationConfirmation(userId, operationId, "FAILED");
               return false;
           }
           // Успешное подтверждение
           redisTemplate.delete(operationKey);
           auditService.logOperationConfirmation(userId, operationId, "SUCCESS");
           return true;
       }
       /**
        * Генерация одноразового кода (6 цифр)
        */
       private String generateOtpCode() {
           SecureRandom random = new SecureRandom();
           int code = 100000 + random.nextInt(900000); // 100000-999999
           return String.valueOf(code);
       }
       // Вспомогательные методы для защиты от brute force
       private void incrementFailedAttempts(String phone) {
           String key = "fail:" + phone;
           Integer attempts = redisTemplate.opsForValue().get(key);
           redisTemplate.opsForValue().set(key, (attempts == null ? 1 : attempts + 1), 1, TimeUnit.HOURS);
       }
       private int getFailedAttempts(String phone) {
           String key = "fail:" + phone;
           Integer attempts = redisTemplate.opsForValue().get(key);
           return attempts == null ? 0 : attempts;
       }
       private void resetFailedAttempts(String phone) {
           redisTemplate.delete("fail:" + phone);
       }
       private void blockUserTemporarily(String phone) {
           String blockKey = "block:" + phone;
           redisTemplate.opsForValue().set(blockKey, "blocked", 30, TimeUnit.MINUTES);
       }
   }
   	

2. Реализация адаптивной аутентификации на основе поведенческого анализа:

   // AdaptiveAuthService.java
   @Service
   @RequiredArgsConstructor
   public class AdaptiveAuthService {
       private final RiskAssessmentService riskAssessmentService;
       private final DeviceFingerprintService deviceFingerprintService;
       private final LocationService locationService;
       /**
        * Оценка риска операции и принятие решения о дополнительной аутентификации
        * Соответствует рекомендациям ЦБ РФ по адаптивной безопасности
        */
       public AuthDecision assessRisk(AuthContext context) {
           RiskScore riskScore = new RiskScore();
           // 1. Анализ устройства (новое устройство = повышенный риск)
           DeviceFingerprint currentDevice = deviceFingerprintService.getFingerprint(context.getDeviceId());
           boolean isKnownDevice = deviceFingerprintService.isKnownDevice(context.getUserId(), currentDevice);
           if (!isKnownDevice) {
               riskScore.addPoints(30, "NEW_DEVICE");
           } else {
               // Проверка изменений в отпечатке устройства
               if (deviceFingerprintService.hasSignificantChanges(currentDevice)) {
                   riskScore.addPoints(20, "DEVICE_MODIFIED");
               }
           }
           // 2. Анализ геолокации (новое местоположение = повышенный риск)
           Location currentLocation = locationService.getLocationFromIp(context.getIpAddress());
           boolean isKnownLocation = locationService.isKnownLocation(context.getUserId(), currentLocation);
           if (!isKnownLocation) {
               riskScore.addPoints(25, "NEW_LOCATION");
               // Проверка невозможного перемещения (Москва → Владивосток за 1 час)
               if (locationService.isImpossibleTravel(context.getUserId(), currentLocation)) {
                   riskScore.addPoints(40, "IMPOSSIBLE_TRAVEL");
               }
           }
           // 3. Анализ поведения (время суток, сумма операции, тип операции)
           if (context.getOperationAmount() > context.getUserAverageAmount() * 3) {
               riskScore.addPoints(20, "UNUSUAL_AMOUNT");
           }
           if (!context.getOperationTime().isWithinNormalHours()) {
               riskScore.addPoints(15, "UNUSUAL_TIME");
           }
           // 4. Анализ истории операций (частота, типы операций)
           OperationHistory history = operationHistoryService.getHistory(context.getUserId());
           if (history.isSuspiciousPattern()) {
               riskScore.addPoints(35, "SUSPICIOUS_PATTERN");
           }
           // Принятие решения на основе итогового риска
           if (riskScore.getTotal() >= 70) {
               return AuthDecision.REQUIRE_STRONG_2FA; // Требуется биометрия или SMS + PIN
           } else if (riskScore.getTotal() >= 40) {
               return AuthDecision.REQUIRE_STANDARD_2FA; // Требуется стандартная 2FA
           } else {
               return AuthDecision.ALLOW_WITH_SESSION; // Разрешить с текущей сессией
           }
       }
       /**
        * Класс для расчёта и хранения оценки риска
        */
       @Data
       private static class RiskScore {
           private int totalScore = 0;
           private List<String> riskFactors = new ArrayList<>();
           public void addPoints(int points, String factor) {
               totalScore += points;
               riskFactors.add(factor + " (+" + points + ")");
           }
           public int getTotal() {
               return totalScore;
           }
           public List<String> getFactors() {
               return riskFactors;
           }
       }
   }
   	

Типичные сложности и временные затраты:

• Ошибка 1: Отсутствие реализации требований ЦБ РФ к двухфакторной аутентификации (Указание №5791-У).
• Ошибка 2: Нет описания мер защиты от атак (brute force, фишинг) и адаптивной аутентификации.
• Ориентировочное время: 40–50 часов (разработка, отладка, документирование кода).

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

4.1. Тестирование на соответствие требованиям безопасности

Цель раздела: Обосновать объективную методику оценки эффективности разработанного решения.

Пошаговая инструкция:

1. Тестирование на уязвимости (пентест):

   Уязвимость	Инструмент тестирования	Результат до защиты	Результат после защиты	Соответствие
   SQL-инъекции	sqlmap	Уязвимость обнаружена	Защищено (ORM + PreparedStatement)	PCI DSS 6.5.1
   XSS	OWASP ZAP	Уязвимость обнаружена	Защищено (экранирование вывода)	OWASP A7
   Brute force	Hydra	500 попыток/мин	Блокировка после 5 попыток	ЦБ РФ №3894-У
   Утечка ПДн	Burp Suite	Данные в открытом виде	AES-256 шифрование	ФЗ-152 ст. 19
   Отсутствие 2FA	Ручное тестирование	Однофакторная аутентификация	Обязательная 2FA для всех операций	ЦБ РФ №5791-У

2. Сертификация и соответствие стандартам:
   • PCI DSS: пройдено самостоятельное сканирование уязвимостей через Qualys, все критические уязвимости устранены
   • ФЗ-152: проведена оценка соответствия требованиям Роскомнадзора, реализованы все необходимые меры защиты ПДн
   • Требования ЦБ РФ: система соответствует Указаниям №3894-У, №4224-У, №5791-У по защите информации и аутентификации

4.2. Экономическая эффективность внедрения системы

Цель раздела: Обосновать целесообразность внедрения разработанной системы.

Пошаговая инструкция:

1. Расчёт экономического эффекта (на примере регионального банка):
   • Сокращение очередей в отделениях: 500 клиентов/день × (8 мин – 2 мин) × 1 500 руб./час × 22 дня = 1 650 000 руб./мес
   • Снижение затрат на кассиров: 10 кассиров × 60 000 руб./мес × 30% (сокращение нагрузки) = 180 000 руб./мес
   • Снижение потерь от мошенничества: 28.7 млрд руб. (рыночные потери) × 0.5% (доля банка) × 40% (снижение благодаря системе защиты) = 57 400 000 руб./год
   • Рост доходов от увеличения операций: 15% рост количества операций × 50 руб. комиссия × 10 000 операций/день × 22 дня × 12 мес. = 19 800 000 руб./год
   • Итого годовой экономический эффект: (1 650 000 + 180 000) × 12 + 57 400 000 + 19 800 000 = 99 160 000 руб.
2. Затраты на разработку и внедрение:
   • Разработка ПО: 2 800 000 руб.
   • Серверное оборудование и лицензии: 1 200 000 руб.
   • Сертификация и аудит безопасности: 650 000 руб.
   • Обучение персонала: 180 000 руб.
   • Итого единовременные затраты: 4 830 000 руб.
   • Ежегодные затраты на поддержку: 1 440 000 руб.
3. Срок окупаемости:

   Срок окупаемости = Единовременные затраты / (Годовой эффект – Ежегодные затраты)
                      = 4 830 000 / (99 160 000 – 1 440 000)
                      = 4 830 000 / 97 720 000
                      = 0.049 года ≈ <strong>18 дней</strong>
   	

   Вывод: Внедрение разработанной информационной системы электронных банковских услуг окупается менее чем за 3 недели эксплуатации, что подтверждает исключительную экономическую эффективность решения. Дополнительный эффект — повышение лояльности клиентов, снижение рисков мошенничества и полное соответствие требованиям ЦБ РФ и ФЗ-152.

Типичные сложности и временные затраты:

• Ошибка 1: Отсутствие количественной оценки соответствия требованиям безопасности (только качественные утверждения «система защищена»).
• Ошибка 2: Нет расчёта экономического эффекта с обоснованием исходных данных (почему 500 клиентов/день?).
• Ориентировочное время: 20–25 часов (проведение тестов, сбор данных, расчёты).

Практические инструменты для написания ВКР

Шаблоны формулировок для ключевых разделов

Актуальность (введение): «Рынок цифровых банковских услуг в России демонстрирует стремительный рост: по данным ЦБ РФ (2025), объём операций через мобильные приложения достиг 148 трлн руб., увеличившись на 67% за год. Однако одновременно растёт и количество мошеннических операций — на 43%, убытки клиентов составили 28.7 млрд руб. Критически важно, что 76% банков не соответствуют требованиям Указания ЦБ РФ №5791-У по обязательной двухфакторной аутентификации для всех операций с деньгами. Современные требования законодательства (ФЗ-152, ФЗ-161, Указания ЦБ РФ, стандарт PCI DSS) обязывают кредитные организации обеспечивать многоуровневую защиту финансовых данных и операций клиентов. Разработка информационной системы электронных банковских услуг с реализацией обязательной двухфакторной аутентификации, адаптивной системой безопасности и полным соответствием требованиям ЦБ РФ позволит снизить риски мошенничества на 40%, сократить операционные издержки на 1.83 млн руб./мес и обеспечить окупаемость за 18 дней при годовом экономическом эффекте 99.16 млн руб.».

Выводы по работе: «В ходе выполнения выпускной квалификационной работы разработана информационная система электронных банковских услуг с обеспечением многоуровневой безопасности и соответствием требованиям ЦБ РФ. Ключевые результаты: 1) Проведён анализ нормативных требований (ФЗ-152, ФЗ-161, Указания ЦБ РФ №3894-У, №5791-У, стандарт PCI DSS) с привязкой к архитектурным решениям; 2) Спроектирована микросервисная архитектура системы с выделением компонентов (аутентификация, платежи, аудит) и реализацией многоуровневой защиты; 3) Реализован модуль двухфакторной аутентификации с поддержкой SMS, TOTP и биометрии в соответствии с Указанием №5791-У; 4) Разработана адаптивная система безопасности на основе поведенческого анализа для снижения рисков мошенничества; 5) Обеспечено шифрование ПДн (AES-256) и ведение полного аудита всех операций в соответствии с ФЗ-152; 6) Проведено тестирование на соответствие требованиям безопасности: все критические уязвимости устранены, система соответствует стандартам PCI DSS и требованиям ЦБ РФ; 7) Рассчитан экономический эффект: годовая экономия 99.16 млн руб., срок окупаемости 18 дней. Разработанное решение соответствует требованиям программной инженерии и обеспечивает высокий уровень безопасности при управлении финансовыми операциями».

Чек-лист самопроверки перед сдачей ВКР

• ✅ Объём работы 60–70 страниц основного текста (без приложений)?
• ✅ Во введении есть все обязательные элементы (актуальность с цифрами по мошенничеству и требованиям ЦБ РФ, цель с указанием безопасности)?
• ✅ В Главе 1 приведён анализ конкретных нормативных документов (ФЗ-152, Указания ЦБ РФ) с привязкой к требованиям системы?
• ✅ В Главе 1 представлена сравнительная таблица существующих решений с обоснованием недостатков?
• ✅ В Главе 2 представлены формализованные требования с пометкой «Критический» для требований безопасности?
• ✅ В Главе 2 есть диаграмма архитектуры с компонентами безопасности (WAF, Vault, аудит)?
• ✅ В Главе 2 есть схема БД с таблицами аудита и защиты ПДн?
• ✅ В Главе 3 приведены листинги кода с реализацией 2FA и адаптивной аутентификации?
• ✅ В Главе 3 есть описание мер защиты от атак (brute force, SQL-инъекции)?
• ✅ В Главе 4 проведено тестирование на соответствие требованиям безопасности с таблицей результатов?
• ✅ В Главе 4 рассчитан экономический эффект с обоснованием исходных данных?
• ✅ В приложениях — диаграммы архитектуры, листинги кода (500+ строк), результаты тестирования, скриншоты интерфейса?
• ✅ Список литературы содержит 25+ источников (нормативные документы, стандарты безопасности)?
• ✅ Уникальность текста не ниже 80% по системе «Антиплагиат ВУЗ»?
• ✅ Оформление соответствует требованиям ГОСТ 7.32-2017?

Перед сдачей научному руководителю — проверьте работу на соответствие требованиям безопасности и нормативам ЦБ РФ.

Наши эксперты проведут аудит: полнота анализа нормативных требований, корректность архитектурных решений безопасности, правильность реализации 2FA и защиты ПДн, качество экономических расчётов.

Telegram: @Diplomit | Телефон: +7 (987) 915-99-32

Заказать аудит ВКР

Два пути к успешной защите ВКР

Путь 1: Самостоятельная работа

Подходит студентам с опытом в области информационной безопасности и пониманием требований финансового сектора. Объём работы: 160–200+ часов. Вы получите ценные навыки проектирования безопасных систем, реализации требований ЦБ РФ, оценки уязвимостей. Однако риски значительны: сложность глубокого анализа нормативных документов, ошибки в проектировании архитектуры безопасности, необходимость многократных правок по замечаниям руководителя, стресс из-за сжатых сроков. Особенно критичны разделы с экономическим расчётом — здесь чаще всего требуются доработки из-за отсутствия обоснования исходных данных.

Путь 2: Профессиональная помощь как стратегическое решение

Это взвешенное решение для тех, кто хочет гарантировать соответствие требованиям вуза и финансового регулятора. Преимущества:

• Гарантия соответствия нормативам: все компоненты спроектированы с учётом требований ЦБ РФ, ФЗ-152, PCI DSS
• Реализация критических модулей безопасности: двухфакторная аутентификация, адаптивная защита, аудит операций, шифрование ПДн
• Корректная оценка безопасности: тестирование на уязвимости, соответствие стандартам, документация для аудита
• Реалистичные экономические расчёты: обоснование исходных данных, расчёт срока окупаемости, сравнение с существующими решениями
• Поддержка до защиты: бесплатные доработки по замечаниям научного руководителя без ограничения по времени

Это не «сдача чужой работы», а фокус на результате: вы глубоко изучаете материал для защиты, а эксперты обеспечивают техническое качество и соответствие стандартам финансового сектора. Для многих студентов это оптимальный путь к защите с отличием без излишнего стресса.

Готовы сделать шаг к успешной защите?

Получите бесплатный расчёт стоимости и сроков по вашей теме ВКР.

Рассчитать стоимость ВКР

Или напишите в Telegram: @Diplomit

Итоги: ключевое для написания ВКР по банковской системе

Успешная ВКР по теме банковской системы требует строгого следования проектно-исследовательскому подходу: анализ нормативных требований ЦБ РФ и ФЗ-152 с привязкой к архитектуре → проектирование системы с многоуровневой защитой (2FA, шифрование, аудит) → реализация ключевых модулей с акцентом на безопасность → объективная оценка соответствия требованиям через тестирование и экономический расчёт. Особое внимание — реализации обязательной двухфакторной аутентификации в соответствии с Указанием ЦБ РФ №5791-У, защите персональных данных по ФЗ-152 и корректному расчёту экономического эффекта с обоснованием всех исходных данных.

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

Готовы начать работу над ВКР?

Оставьте заявку прямо сейчас и получите бесплатный расчёт стоимости и сроков по вашей теме.

Оставить заявку на расчёт

Или свяжитесь любым удобным способом: Telegram: @Diplomit, Телефон: +7 (987) 915-99-32

Почему 350+ студентов выбрали нас в 2025 году

• Знание требований финансового сектора: Работаем с ВКР по банковским системам, знаем все нюансы требований ЦБ РФ, ФЗ-152, PCI DSS.
• Экспертиза в информационной безопасности: Авторы с опытом разработки защищённых финансовых систем, знание методологий тестирования на уязвимости.
• Рабочие решения: Все модули реализованы и протестированы, предоставляется полный исходный код с документацией.
• Корректная оценка безопасности: Тестирование на соответствие стандартам, документация для аудита, расчёт экономического эффекта.
• Поддержка до защиты: Бесплатные доработки по замечаниям научного руководителя без ограничения по времени.
• Гарантия оригинальности: Уникальность 85%+ по системе «Антиплагиат ВУЗ».

Полезные материалы:

• Условия работы и как сделать заказ
• Наши гарантии
• Отзывы студентов по программной инженерии
• Другие статьи по написанию ВКР по информационной безопасности