FinTech по законам МФЦА: Поднимаем банковскую инфраструктуру в GCP за 12 минут, за которую не стыдно перед аудиторами

12.08.2026

Шарафутдинов Р.

Запуск финтех-стартапа в Казахстане — это не просто написать красивое приложение на Flutter и поднять бэкенд на Node.js. Как только вы решаете обрабатывать реальные деньги, транзакции или персональные данные граждан, в дверь стучатся суровые реалии комплаенса. Регуляторы, Нацбанк, правила МФЦА (AIFC), стандарты PCI-DSS и закон о персональных данных РК — все они требуют от вашей инфраструктуры такого уровня паранойи, который обычному e-commerce даже не снился.

Исторически в СНГ это решалось просто, но больно: компания покупала серверные стойки, ставила их в сертифицированный ЦОД, натягивала VMware или Proxmox, ставила аппаратные файрволы (Cisco, Fortinet) и нанимала армию безопасников. Итог? Полгода времени и сотни тысяч долларов только на старт. Но что если я скажу вам, что всю эту пуленепробиваемую банковскую инфраструктуру можно развернуть в Google Cloud Platform (GCP) ровно за 12 минут? И самое главное — аудиторы будут в восторге.

Введение в паранойю: Что от нас хотят аудиторы?

Когда к вам приходит ИБ-аудитор (особенно "большая четверка" или регуляторы из МФЦА), они не смотрят на то, какой красивый у вас код. Они смотрят на процессы, изоляцию и контроль. Вот базовый чек-лист, без которого вас развернут на первой же встрече:

Никаких публичных IP-адресов. Базы данных, рабочие узлы кластеров и внутренние балансировщики не должны торчать в интернет.
Шифрование везде. Data at rest, data in transit. И не просто стандартными ключами провайдера, а вашими собственными ключами (Customer-Managed Encryption Keys - CMEK).
Сетевой периметр. Запрет на выгрузку данных из облака. Если кто-то украл учетные данные разработчика, он не должен иметь возможности скачать дамп базы на свой домашний компьютер.
Audit Trails (Журналы аудита). Кто, когда и зачем обращался к ресурсу? Логи нельзя удалить или изменить.
Инфраструктура как код (IaC). Если вы настраивали сеть руками через веб-консоль — вы не пройдете аудит процессов. Инфраструктура должна быть воспроизводимой, а каждое изменение — проходить через Git, ревью и пайплайны.

Давайте построим такую архитектуру с помощью Terraform и GCP.

Шаг 1: Фундамент. Сеть и приватные кластеры GKE

Начнем с самого важного — изоляции. Мы будем использовать Google Kubernetes Engine (GKE), но не обычный, а Private Cluster. В таком кластере узлы (nodes) не имеют публичных IP-адресов. Общение с внешним миром происходит строго через Cloud NAT.

# gke_secure_cluster.tf
# Создаем приватный GKE кластер для FinTech

resource "google_container_cluster" "fintech_secure_cluster" {
  name     = "fintech-core-cluster"
  location = "europe-west3" # Frankfurt (обычно устраивает большинство юрисдикций, если нет локальных ЦОД)

  # Отключаем дефолтный пул узлов, мы создадим кастомный с нужными политиками
  remove_default_node_pool = true
  initial_node_count       = 1

  # Приватный кластер: узлы не имеют белых IP
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = false
    master_ipv4_cidr_block  = "172.16.0.0/28"
  }

  master_authorized_networks_config {
    cidr_blocks {
      cidr_block   = "10.0.0.0/8"
      display_name = "Corporate VPN"
    }
  }

  # Интеграция с Cloud KMS для шифрования секретов Kubernetes (etcd)
  database_encryption {
    state    = "ENCRYPTED"
    key_name = google_kms_crypto_key.k8s_secrets.id
  }

  # Workload Identity - прощайте сервисные аккаунты в JSON ключах!
  workload_identity_config {
    workload_pool = "${var.project_id}.svc.id.goog"
  }
}

resource "google_container_node_pool" "secure_nodes" {
  name       = "secure-node-pool"
  cluster    = google_container_cluster.fintech_secure_cluster.id
  node_count = 3

  node_config {
    machine_type = "e2-standard-4"
    
    # Shielded VMs - защита от руткитов и изменений на уровне бутлоадера
    shielded_instance_config {
      enable_secure_boot = true
      enable_integrity_monitoring = true
    }

    # Сервисный аккаунт с минимальными правами (Least Privilege)
    service_account = google_service_account.gke_sa.email
    oauth_scopes    = ["https://www.googleapis.com/auth/cloud-platform"]
  }
}

Посмотреть код на GitHub (OZAT-kz)

Что здесь происходит? Мы поднимаем Shielded VMs. Это виртуальные машины, которые используют Secure Boot и виртуальные модули Trusted Platform Module (vTPM). Если кто-то попытается подменить ядро ОС на уровне гипервизора, машина просто не загрузится. Аудиторы очень любят эту галочку. Также мы сразу включаем Workload Identity — это значит, что нашим подам больше не нужно скачивать JSON-ключи для доступа к базе данных. Поды авторизуются через IAM Google Cloud напрямую. Меньше ключей — меньше риск утечки.

Шаг 2: Управление ключами шифрования (KMS)

В мире финтеха вы не можете просто сказать: "Гугл всё шифрует сам". Аудитор спросит: "А кто управляет ключами?". Если Гугл решит (или его заставят) прочитать ваши данные, сможет ли он это сделать? В GCP есть Cloud KMS (Key Management Service). Мы будем использовать подход CMEK (Customer-Managed Encryption Keys).

# cloud_kms_cmek.tf
# Создаем собственные ключи шифрования для базы данных и хранилища

resource "google_kms_key_ring" "fintech_keyring" {
  name     = "fintech-keyring-v1"
  location = "europe-west3"
}

# Ключ для шифрования базы данных Cloud SQL (PostgreSQL)
resource "google_kms_crypto_key" "db_crypto_key" {
  name            = "cloud-sql-encryption-key"
  key_ring        = google_kms_key_ring.fintech_keyring.id
  rotation_period = "7776000s" # Авто-ротация каждые 90 дней (требование PCI-DSS)

  lifecycle {
    prevent_destroy = true # Защита от случайного удаления ключа (и потери всех данных)
  }
}

# Назначаем права сервисному аккаунту Cloud SQL на использование этого ключа
resource "google_kms_crypto_key_iam_binding" "sql_kms_binding" {
  crypto_key_id = google_kms_crypto_key.db_crypto_key.id
  role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"

  members = [
    "serviceAccount:service-${var.project_number}@gcp-sa-cloud-sql.iam.gserviceaccount.com",
  ]
}

Посмотреть код на GitHub (OZAT-kz)

Здесь мы не просто создаем ключ. Мы настраиваем автоматическую ротацию ключей каждые 90 дней. Это прямое требование многих стандартов безопасности, включая PCI-DSS (Payment Card Industry Data Security Standard). При ротации старые данные остаются зашифрованными старой версией ключа, а новые шифруются новой, GCP управляет этим прозрачно для приложения. Но самое главное: если вы отзовете права у сервисного аккаунта на этот ключ, база данных превратится в тыкву за доли секунды. Никто, включая инженеров Google, не сможет ее прочитать.

Шаг 3: Стальной купол - VPC Service Controls

Это моя любимая фича в GCP. Представьте ситуацию: ваш Senior Backend Developer, у которого есть права на чтение базы (Cloud SQL) и бакетов (Cloud Storage), увольняется. В последний день он генерирует сервисный ключ, приходит домой, подключается со своего домашнего Wi-Fi и выкачивает терабайт данных клиентов. Как от этого защититься? IAM-политики тут не помогут, ведь у него *есть* права.

Рекомендуем к прочтению

Как мы остановили ботов: Создание системы обнаружения скликивания (Click Fraud) в реальном времени с помощью Cloud Dataflow и Pub/Sub

05.08.2026

На сцену выходит VPC Service Controls (VPC SC). Это невидимый силовой щит, который накрывает ваши управляемые сервисы (API). Даже если у злоумышленника есть валидный логин, пароль, ключ и права, VPC SC отклонит запрос, если он пришел не из корпоративной сети или не со служебного ноутбука.

# vpc_service_controls.yaml
# Определение периметра безопасности через Access Context Manager

resources:
  - accessPolicies/112233445566/servicePerimeters/fintech_prod_perimeter

servicePerimeters:
  - name: accessPolicies/112233445566/servicePerimeters/fintech_prod_perimeter
    title: FinTech Production Perimeter
    description: "Блокируем доступ к API извне"
    status:
      restrictedServices:
        - storage.googleapis.com
        - sqladmin.googleapis.com
        - pubsub.googleapis.com
        - secretmanager.googleapis.com
      
      accessLevels:
        - accessPolicies/112233445566/accessLevels/corp_vpn_only
      
      # Ресурсы (проекты), которые находятся внутри купола
      resources:
        - projects/fintech-prod-project

accessLevels:
  - name: accessPolicies/112233445566/accessLevels/corp_vpn_only
    title: Corporate VPN Only
    basic:
      conditions:
        - ipSubnetworks:
            - 192.0.2.0/24 # IP-адреса корпоративного VPN
            - 203.0.113.0/24 # IP-адреса офиса в Астане

Посмотреть код на GitHub (OZAT-kz)

Этот YAML-манифест говорит инфраструктуре следующее: "Разреши доступ к Cloud Storage, Cloud SQL, Pub/Sub и Secret Manager ТОЛЬКО если запрос пришел из-под корпоративного VPN или из офиса в Астане. Всем остальным — 403 Forbidden, даже владельцу проекта". Это закрывает риск эксфильтрации (утечки) данных на 99%.

Шаг 4: CI/CD и Audit Logs

Когда инфраструктура описана кодом (IaC), мы можем применять изменения через CI/CD пайплайны. Никто не ходит в консоль руками. Любое изменение сети, фаервола или базы данных проходит через Pull Request в GitHub/GitLab. Когда код вмерживается в main, раннер выполняет terraform apply.

Но как доказать аудитору, что кто-то не зашел ночью и не поменял настройки напрямую? Для этого мы включаем Cloud Audit Logs (Data Access Logs). В GCP по умолчанию включены логи администрирования (Admin Activity), но для FinTech нужно включить логирование доступа к данным. Мы фиксируем каждый SELECT в базу данных (если используется BigQuery или Cloud Spanner) и каждое чтение объекта из Cloud Storage.

Все эти логи должны экспортироваться в изолированный проект (Log Sink), к которому нет доступа даже у DevOps инженеров. Доступ туда имеет только офицер информационной безопасности.

Взгляд на показатели комплаенса (до и после)

Внедрение IaC и нативных средств безопасности GCP кардинально меняет картину прохождения аудитов. Посмотрите на этот график, который мы составили на основе нашего опыта подготовки трех разных финтех-компаний к сертификации в МФЦА:

Уровень готовности к аудиту МФЦА (AIFC)

Сравнение базовой инфраструктуры On-Premises и GCP с применением IaC (в %)

На графике четко видно: традиционные методы развертывания оставляют огромные дыры в управлении секретами и защите периметра, в то время как подход на базе GCP покрывает практически все требования из коробки, оставляя инженерам время на бизнес-логику, а не на настройку IPsec-туннелей.

Итоги

Развернуть безопасную банковскую инфраструктуру за 12 минут (именно столько работает Terraform пайплайн) — это не магия, это результат использования правильных абстракций. Google Cloud Platform предоставляет потрясающий инструментарий для параноиков. В мире, где утечка базы данных означает конец бизнеса, экономить на архитектуре — преступление.

Terraform-скрипты, приведенные в этой статье (и многие другие), мы выложили в наш открытый репозиторий blog-configs. Изучайте, внедряйте, и пусть аудиторы плачут от счастья, глядя на вашу архитектуру.

Если вы запускаете финтех-проект в Казахстане и вам нужна помощь с архитектурой, прохождением аудита AIFC или миграцией — команда OZAT знает, как закрутить гайки так, чтобы система осталась быстрой, разработчики — счастливыми, а безопасность — непробиваемой. Увидимся в проде!

Рустам Шарафутдинов

Автор инженерного блога

Эксперт в области архитектуры Google Cloud и Senior Full-Stack разработчик с более чем 15-летним опытом. Специализируется на отказоустойчивых архитектурах, оптимизации высоконагруженных проектов и интеграции AI (Vertex AI).

Экспертность: GCP, Kubernetes, Микросервисы, React, Node.js

FinTech по законам МФЦА: Поднимаем банковскую инфраструктуру в GCP за 12 минут, за которую не стыдно перед аудиторами

Введение в паранойю: Что от нас хотят аудиторы?

Шаг 1: Фундамент. Сеть и приватные кластеры GKE

Шаг 2: Управление ключами шифрования (KMS)

Шаг 3: Стальной купол - VPC Service Controls

Как мы остановили ботов: Создание системы обнаружения скликивания (Click Fraud) в реальном времени с помощью Cloud Dataflow и Pub/Sub

Шаг 4: CI/CD и Audit Logs

Взгляд на показатели комплаенса (до и после)

Уровень готовности к аудиту МФЦА (AIFC)

Итоги

Рустам Шарафутдинов

Комментарии (0)