Безопасность и добросовестность наших финансовых операций
Банки, подобные нашему, используют специализированную серверную инфраструктуру для обслуживания различных операционных направлений. С учётом архитектурных требований и финансового регулирования к основным типам серверов относятся:
1. Серверы основной банковской системы
Эти серверы образуют центральную операционную основу, обеспечивающую ведение клиентских счетов, проведение операций и соблюдение требований комплаенс:
- Серверы обработки транзакций: выполняют авторизацию платежей в реальном времени, проверки на мошенничество и расчёты (например, SWIFT, SEPA).
- Серверы управления счетами: обрабатывают события жизненного цикла счёта (открытие и закрытие), расчёт процентов и мониторинг ликвидности.
- Серверы регуляторного комплаенса: автоматизация проверок по AML (противодействию отмыванию денежных средств), аудиторских следов и отчётности (например, по IFRS, GDPR).
2. Серверы реестра
Отвечает за ведение неизменяемых финансовых записей:
- Серверы главной книги: ведут учёт по методу двойной записи по счетам, обеспечивая соблюдение стандартов бухгалтерского учёта, таких как МСФО.
- Серверы технологии распределённого реестра (DLT): системы на основе блокчейна для трансграничных платежей, проверки KYC и защищённых от подделки журналов операций.
3. Серверы внешних коммуникаций
Обеспечивают защищённое взаимодействие с внешними организациями:
- Серверы EBICS: обеспечивают работу стандарта электронного банковского взаимодействия через Интернет (Electronic Banking Internet Communication Standard) для платежей SEPA, широко используемого в Германии, Франции и Швейцарии.
- Серверы Host-to-Host (H2H): прямые SFTP/FTPS-соединения для корпоративных операций большого объёма (например, массовая обработка заработной платы).
- Серверы шлюза API: предоставляют интерфейсы RESTful для инициирования платежей в реальном времени и агрегирования счетов (защищены с помощью OAuth2/mTLS).
- Серверы интерфейса Swift: подключают банк к сети Swift для межбанковского обмена сообщениями (SCORE — это закрытая группа пользователей Swift для корпоративного доступа, а не тип сервера).
4. Серверы баз данных
Центральные хранилища структурированных финансовых данных:
- Серверы клиентских данных: хранят документы KYC, историю операций и поведенческую аналитику.
- Серверы каталога продуктов: управление предложениями, такими как кредиты, ипотека и ставки по депозитам.
5. Серверы безопасности и инфраструктуры
Обеспечивают целостность систем и соблюдение нормативных требований:
- Серверы аппаратных модулей безопасности (HSM): защита криптографических ключей для цифровых подписей и шифрования SSL/TLS.
- Серверы межсетевых экранов/VPN: обеспечивают сегментацию сети и защищённый удалённый доступ для сотрудников.
- Серверы аварийного восстановления: размещают резервные системы для обеспечения непрерывности деятельности при сбоях.
Современные банки нередко применяют гибридные архитектуры, сочетающие локальные ядровые серверы с облачными узлами DLT для обеспечения масштабируемости. Например, банк может использовать локальные серверы основной банковской системы IBM наряду с серверами реестра на платформе AWS для сверки в режиме реального времени. Такой модульный подход позволяет сбалансировать комплаенс, производительность и инновации.
Банки должны соблюдать баланс между консолидацией серверов в целях повышения эффективности и сохранением изоляции в целях безопасности и соблюдения нормативных требований. Ниже приведён разбор серверов, которые можно и нельзя объединять, исходя из технических ограничений и отраслевой практики:
Серверы, которые можно объединять
1. Веб-серверы и серверы приложений
- Комбинированный метод: виртуализация (VMware, KVM) или контейнеризация (Docker/Kubernetes)
- Пример: размещение нескольких банковских порталов (для розничных клиентов, корпоративных клиентов, мобильного банкинга) на кластере гипервизоров с балансировкой нагрузки.
2. Серверы баз данных
- Комбинированный метод: многопользовательские облачные базы данных (AWS RDS, Azure SQL)
- Базы данных основных банковских систем на Oracle/MS SQL могут сосуществовать с аналитическими системами на PostgreSQL/MongoDB в гибридных облачных конфигурациях.
3. Внешние коммуникационные шлюзы
- Комбинированный метод: единые API-шлюзы (Apigee, MuleSoft)
- Сервисы EBICS, SWIFT и SFTP могут работать на общей инфраструктуре с микросервисами, специфичными для каждого протокола.
4. Серверы аварийного восстановления
- Метод комбинирования: географическое резервирование в режиме «активный-активный»
- Реплики основной банковской системы и резервные серверы бухгалтерских книг могут использовать общие кластеры аварийного восстановления.
5. Серверы промежуточного программного обеспечения
- Комбинированный метод: корпоративная сервисная шина (ESB)
- Маршрутизация платежей, проверки на соответствие требованиям и услуги по конвертации валют, консолидированные на платформах IBM Integration Bus/SAP PI.
Серверы, которые должны оставаться изолированными
1. Серверы ядра обработки транзакций
- Обоснование: разделение (физическое или посредством строгой сегментации) сокращает сферу действия требований PCI DSS и мер контроля SOC 2
- Пример: системы IBM zSystems, на которых работают мониторы транзакций CICS, не могут использовать аппаратные ресурсы совместно с другими рабочими нагрузками.
2. Серверы с аппаратными модулями безопасности (HSM)
- Причина: стандарт FIPS 140-2/140-3 уровня 3 предписывает использование специализированного аппаратного обеспечения, защищённого от несанкционированного вскрытия
- Реализация: HSM-модули Thales/Gemalto, обеспечивающие работу с цифровыми подписями и ключами шифрования.
3. Системы учёта в режиме реального времени
- Причина: двойная запись в бухгалтерском учёте требует атомарности
- Пример: серверы реестра Oracle Financial Services с локально подключёнными накопителями NVMe.
4. Серверы регуляторной отчётности
- Причина: журналы аудита должны быть защищены от изменения и храниться в течение сроков, установленных GDPR и законодательством по AML; разделение облегчает подтверждение этого
- Конфигурация: изолированные экземпляры SQL Server для отчётности по MiFID II/FATCA.
5. Системы авторизации банкоматов и POS-терминалов
- Причина: соглашение об уровне обслуживания с доступностью 99,999% и требования к сегментации сети
- Архитектура: IBM Power Systems с резервированными сетями хранения данных Fibre Channel.
Технические ограничения:
- Высоконагруженным основным банковским системам требуются выделенные сетевые подключения с высокой пропускной способностью
- Стандарт PCI DSS требует, чтобы хранимые номера карт (PAN) были приведены в нечитаемый вид, а среда обработки данных держателей карт была сегментирована
- Программа обеспечения безопасности клиентов Swift (CSP) требует размещения инфраструктуры Swift в защищённой изолированной зоне
Мы успешно консолидировали 80% некритичных серверов (веб-серверы, серверы приложений и промежуточного программного обеспечения), сохранив полную изоляцию основных систем, HSM и систем бухгалтерского учёта.
Обеспечение безопасности серверов реестра в облаке требует многоуровневой защиты, учитывающей особую чувствительность финансовых данных. Ниже изложен структурированный подход, основанный на лучших практиках безопасности AWS и на решениях, применяемых в банковской сфере:
1. Технология неизменяемого реестра
Используйте специализированные реестровые базы данных с криптографической верификацией каждой операции:
- Криптографическое связывание: каждая транзакция хешируется и связывается с предыдущей записью, что формирует неизменяемый аудиторский след.
- Встроенные механизмы контроля целостности: база данных автоматически проверяет собственную историю, что исключает возможность несанкционированного изменения данных.
- Запросы, подобные SQL: обеспечивает совместимость с существующими финансовыми системами, добавляя при этом безопасность, присущую блокчейну.
2. Изоляция сети
- Архитектура VPC: размещайте серверы реестра в частных подсетях без доступа из публичной сети интернет.
- Группы безопасности: ограничьте входящий трафик определёнными портами (например, PostgreSQL/Aurora) из заранее утверждённых диапазонов IP-адресов.
- Конечные точки VPC: используйте AWS PrivateLink для защищённого взаимодействия серверов реестра с такими сервисами, как S3/KMS, без раскрытия данных в открытой сети.
3. Шифрование
- В состоянии покоя: ключи, управляемые AWS KMS, шифруют данные реестра в Amazon Aurora с автоматической ротацией ключей.
- При передаче данных: обязательное применение TLS 1.3 для всех взаимодействий между клиентом и сервером и между сервисами.
- Шифрование на стороне клиента: предварительное шифрование конфиденциальных полей (например, остатков по счетам) перед хранением с использованием AWS Encryption SDK.
4. Контроль доступа
- Роли IAM: назначайте детализированные права доступа (например, роли только с правом добавления данных), чтобы предотвратить случайное или умышленное удаление данных.
- Временные учётные данные: используйте AWS STS для доступа, ограниченного по времени, на период технического обслуживания.
- Обязательная многофакторная аутентификация (MFA): требуйте аппаратные токены (YubiKey) для учётных записей root/администратора.
5. Мониторинг и аудит
- Оповещения в режиме реального времени: настройте AWS CloudWatch на отправку оповещений о нетипичных схемах транзакций (например, переводах свыше €1 млн).
- Журналы активности: отслеживание всех изменений в регистре через AWS CloudTrail, интегрированный со средствами SIEM.
- Автоматизированный аудит: еженедельный запуск правил AWS Config для проверки состояния шифрования и сетевых политик.
6. Комплаенс и корпоративное управление
- Сегментация по зонам: разделение сред реестра DEV/TEST/PROD с использованием AWS Organizations.
- Автоматизированная отчётность: формирование отчётов о соответствии PCI DSS/GDPR средствами AWS Audit Manager.
- Аудит третьими сторонами: ежегодно планируйте тестирование на проникновение с привлечением партнёров, одобренных AWS.
7. Аварийное восстановление
- Межрегиональная репликация: поддержание зашифрованных реплик реестра в регионах AWS во Франкфурте и Стокгольме.
- Восстановление на момент времени: включите непрерывное резервное копирование, чтобы восстанавливать данные на любую секунду в пределах срока хранения (до 35 дней).
- Резервные копии в изолированной среде (air-gapped): квартальные снимки реестра хранятся в AWS Backup Vault со сроком хранения 7 лет.
Чтобы предотвратить распространение вредоносных записей на серверы аварийного восстановления (DR), банки применяют многоуровневые стратегии безопасности, которые изолируют резервные копии, обеспечивают строгий контроль доступа и проверяют целостность данных. Ниже приведено техническое описание ключевых мер:
1. Неизменяемые резервные копии с конфигурацией «однократная запись — многократное чтение» (WORM)
- Назначение: не допустить изменения или шифрования резервных данных программами-вымогателями.
Реализация: используйте AWS S3 Object Lock или Azure Blob Immutable Storage, чтобы исключить удаление и изменение данных в течение установленного срока хранения. Применяйте криптографическое хеширование (SHA-256) к резервным копиям файлов: любое вмешательство нарушает хеш и приводит к срабатыванию оповещений.
2. Изолированная (air-gapped) и автономная репликация
- Сетевая изоляция: размещайте серверы аварийного восстановления в отдельной VPC/VLAN без входящего доступа из интернета. Используйте однонаправленную репликацию (основной узел → резервный узел) с помощью таких средств, как AWS Storage Gateway или Azure Site Recovery, блокируя обратную синхронизацию.
- Физическая изоляция (air-gapping): для критически важных систем следует хранить резервные копии на ленточных носителях или в автономных хранилищах, подключаемых только на время запланированных окон репликации.
3. Контроль доступа по принципу нулевого доверия
- Аутентификация: обеспечьте обязательное применение многофакторной аутентификации (MFA) для всех интерфейсов управления аварийным восстановлением (например, AWS SSO, Azure AD Conditional Access). Назначайте роли IAM с минимально необходимыми правами (например, только `s3:GetObject`).
- Сетевая безопасность: ограничьте трафик репликации туннелями IPsec VPN или каналами AWS Direct Connect/Azure ExpressRoute. Разверните системы обнаружения вторжений (IDS), такие как Snort или Suricata, для мониторинга каналов репликации.
4. Проверка целостности данных
- Проверки перед репликацией: перед репликацией проверяйте исходные данные на наличие вредоносного ПО с помощью таких средств, как ClamAV или CrowdStrike Falcon. Сравнивайте контрольные суммы до и после передачи для выявления несанкционированных изменений.
- Аудит после репликации: используйте AWS Config или Azure Policy для применения политик шифрования и доступа на серверах аварийного восстановления. Планируйте ежедневные проверки целостности с помощью скриптов (например, проверка `sha256sum`).
5. Логически разделённые среды
6. Тестирование автоматического переключения на резервные системы
- Имитация атак: использование таких инструментов, как Chaos Monkey, для имитации заражения программами-вымогателями и проверки устойчивости серверов аварийного восстановления. Измерение целевых показателей времени восстановления (RTO) и целевых показателей точки восстановления (RPO) в ходе учений.
- Криминалистический анализ: хранить журналы VPC Flow Logs и события CloudTrail за 90 дней для отслеживания аномалий репликации.
Внедрение неизменяемых резервных копий имеет решающее значение для защиты данных от программ-вымогателей, случайного удаления и нарушений требований соответствия. С учётом отраслевых стандартов и инструментов, таких как AWS, Veeam и Azure, рекомендуется придерживаться следующих практик:
1. Обеспечение неизменяемости на уровне хранилища
- Используйте конфигурации WORM (Write-Once-Read-Many — однократная запись, многократное чтение) на базе объектного хранилища с S3 Object Lock (AWS), Azure Immutable Blob Storage или Veeam Hardened Repositories.
- Включите блокировки хранения, чтобы предотвратить преждевременное удаление или изменение данных, в том числе администраторами.
2. Применяйте стратегию резервного копирования «3-2-1-1»
- 3 копии данных (основная + две резервные)
- 2 типа носителей данных (например, диск + облако)
- 1 копия вне основной площадки (географически обособленная)
- 1 неизменяемая копия (изолированная от сети или с поддержкой WORM).
3. Внедрите строгий контроль доступа
- Ролевой доступ (RBAC): ограничение прав с помощью ролей IAM (например, политик доступа к хранилищу AWS Backup Vault).
- Многофакторная аутентификация (MFA): обязательное применение для интерфейсов управления резервным копированием (например, Azure AD Conditional Access).
- Сетевая изоляция: храните резервные копии в частных подсетях/VPC без доступа к открытому интернету.
4. Используйте сквозное шифрование данных
- При хранении: используйте AES-256 или ключи, управляемые через KMS (AWS, Azure).
- При передаче: TLS 1.3 для каналов репликации.
- Шифрование на стороне клиента: предварительное шифрование конфиденциальных полей перед резервным копированием (например, AES-256 в Veeam с ключами, управляемыми пользователем).
5. Автоматизация хранения и проверки данных
- Политики хранения: определите целевые показатели RPO/RTO и автоматизируйте правила жизненного цикла данных (например, семилетний срок хранения в AWS Backup Vault).
- Проверка контрольных сумм: проверка целостности данных до и после репликации (например, с помощью хеширования SHA-256).
- Регулярные проверки: используйте такие инструменты, как AWS Config или Veeam SureBackup, для тестирования восстановления.
6. Многоуровневая защита для гибридных сред
7. Обеспечение соблюдения требований и безотзывности
- Зафиксируйте параметры неизменяемости после тестирования (например, состояние «Enabled and locked» в Azure).
- Соблюдение нормативных требований: обеспечьте соответствие GDPR, HIPAA или SOX с помощью таких инструментов, как AWS Audit Manager.
- Аудиты третьих сторон: ежегодно планируйте тесты на проникновение (например, с привлечением партнёров, одобренных AWS).
Пример рабочего процесса с использованием AWS и Veeam
1. Основное резервное копирование: Veeam Backup & Replication в корзину S3 с блокировкой объектов (Object Lock).
2. Репликация: AWS DataSync во вторичный регион (Франкфурт → Стокгольм).
3. Проверка: ежедневные журналы CloudTrail и ежеквартальные учения по восстановлению данных.
4. Хранение: 90-дневный неизменяемый период с шифрованием KMS.
Сочетая функции неизменяемости, механизмы контроля доступа и гибридное резервирование, организации могут создавать резервные копии, устойчивые к программам-вымогателям, и одновременно выполнять требования комплаенса.