АХҚО (AIFC) заңдары бойынша FinTech: Аудиторлар алдында ұятқа қалмайтын банктік инфрақұрылымды GCP-де 12 минутта көтеру

12.08.2026

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

Қазақстанда финтех-стартапты іске қосу — бұл жай ғана Flutter-де әдемі қосымша жазып, Node.js-те бэкенд көтеру емес. Сіз нақты ақшамен, транзакциялармен немесе азаматтардың дербес деректерімен жұмыс істеуді ұйғарған сәтте, есігіңізді комплаенстің қатал шындығы қағады. Реттеушілер, Ұлттық банк, АХҚО (AIFC) ережелері, PCI-DSS стандарттары және ҚР дербес деректер туралы заңы — мұның бәрі сіздің инфрақұрылымыңыздан кәдімгі e-commerce түсіне де кірмейтін паранойя деңгейін талап етеді.

Тарихи тұрғыдан алғанда, ТМД-да бұл мәселе қарапайым, бірақ ауыр жолмен шешілетін: компания серверлік тіректерді (стойка) сатып алып, оларды сертификатталған ХҚО-ға (ЦОД) орнататын, VMware немесе Proxmox тартатын, аппараттық брандмауэрлерді (Cisco, Fortinet) қойып, қауіпсіздік мамандарының тұтас армиясын жалдайтын. Нәтижесі? Жарты жыл уақыт және тек бастау үшін ғана жүздеген мың доллар. Бірақ осы оқ өтпейтін банктік инфрақұрылымның барлығын Google Cloud Platform (GCP) желісінде дәл 12 минут ішінде орналастыруға болады десем ше? Ең бастысы — аудиторлар дән риза болады.

Паранойяға кіріспе: Аудиторлар бізден не қалайды?

Сізге АҚ (Ақпараттық қауіпсіздік) аудиторы келгенде (әсіресе "үлкен төрттік" немесе АХҚО реттеушілері), олар сіздің кодыңыздың қаншалықты әдемі екеніне қарамайды. Олар процестерге, оқшаулауға және бақылауға қарайды. Міне, сізді бірінші кездесуде-ақ кері қайтаратын негізгі чек-лист:

Ешқандай жария (public) IP-мекенжайлар болмауы тиіс. Дерекқорлар, кластерлердің жұмыс түйіндері және ішкі балансировщиктер интернетке шықпауы керек.
Барлық жерде шифрлау. Data at rest, data in transit. Оның үстіне, провайдердің стандартты кілттерімен емес, сіздің жеке кілттеріңізбен (Customer-Managed Encryption Keys - CMEK).
Желілік периметр. Бұлттан деректерді жүктеп алуға тыйым салу. Егер біреу әзірлеушінің есептік жазбасын ұрлап алса, ол дерекқор дампын өзінің үй компьютеріне жүктей алмауы керек.
Audit Trails (Аудит журналдары). Ресурсқа кім, қашан және не үшін жүгінді? Логтарды жоюға немесе өзгертуге болмайды.
Инфрақұрылым код ретінде (IaC). Егер сіз желіні веб-консоль арқылы қолмен баптаған болсаңыз — процестер аудитінен өтпейсіз. Инфрақұрылым қайталанатын болуы керек, ал әрбір өзгеріс Git, шолу (review) және құбырлар (pipelines) арқылы өтуі тиіс.

Келіңіздер, Terraform және GCP көмегімен осындай архитектура құрайық.

1-қадам: Іргетас. Желі және жеке GKE кластерлері

Ең маңыздысынан — оқшаулаудан бастайық. Біз Google Kubernetes Engine (GKE) қолданамыз, бірақ кәдімгісін емес, Private Cluster. Мұндай кластерде түйіндерде (nodes) жария IP-мекенжайлар болмайды. Сыртқы әлеммен байланыс қатаң түрде Cloud NAT арқылы жүзеге асады.

# gke_secure_cluster.tf
# FinTech үшін жеке GKE кластерін құрамыз

resource "google_container_cluster" "fintech_secure_cluster" {
  name     = "fintech-core-cluster"
  location = "europe-west3" # Франкфурт (егер жергілікті ХҚО болмаса, әдетте көптеген юрисдикцияларды қанағаттандырады)

  # Дефолтты түйіндер пулын өшіреміз, біз қажетті саясаттары бар кастомды пул құрамыз
  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"
    }
  }

  # Kubernetes құпияларын (etcd) шифрлау үшін Cloud KMS-пен интеграция
  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 және сенімді платформа модулінің (vTPM) виртуалды модульдерін пайдаланатын виртуалды машиналар. Егер біреу гипервизор деңгейінде ОЖ ядросын ауыстыруға тырысса, машина жай ғана жүктелмейді. Аудиторлар бұл құсбелгіні өте жақсы көреді. Сондай-ақ, біз бірден Workload Identity қосамыз — бұл біздің подтарға (pods) дерекқорға кіру үшін JSON кілттерін жүктеп алудың қажеті жоқ дегенді білдіреді. Подтар тікелей IAM Google Cloud арқылы авторизацияланады. Кілттер аз болған сайын — ағып кету қаупі де аз болады.

2-қадам: Шифрлау кілттерін басқару (KMS)

Финтех әлемінде сіз жай ғана: "Google бәрін өзі шифрлайды" дей алмайсыз. Аудитор: "Ал кілттерді кім басқарады?" деп сұрайды. Егер Google сіздің деректеріңізді оқуды шешсе (немесе оған мәжбүрлесе), ол оны істей ала ма? 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-дегі сүйікті фичам. Мынандай жағдайды елестетіп көріңізші: базаны (Cloud SQL) және бакеттерді (Cloud Storage) оқуға құқығы бар сіздің Senior Backend Developer жұмыстан шығады. Соңғы күні ол сервистік кілтті генерациялайды, үйіне келеді, өзінің үйіндегі Wi-Fi желісіне қосылып, клиенттердің бір терабайт деректерін жүктеп алады. Бұдан қалай қорғануға болады? Мұнда IAM саясаттары көмектеспейді, өйткені оның құқықтары *бар*.

Оқуға ұсынамыз

Cloud CDN: Сайтыңызды Ақтауда да, Өскеменде де бір секундта қалай жүктеуге болады

03.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 # Корпоративтік VPN IP-мекенжайлары
            - 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 құбырлары арқылы енгізе аламыз. Ешкім консольге қолмен кірмейді. Желіні, брандмауэрді немесе дерекқорды кез келген өзгерту GitHub/GitLab-тағы Pull Request арқылы өтеді. Код main-ге біріктірілген кезде (merged), раннер 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 және IaC қолданылған GCP инфрақұрылымын салыстыру (%)

Графикте нақты көрінеді: дәстүрлі орналастыру әдістері құпияларды басқаруда және периметрді қорғауда үлкен тесіктер қалдырады, ал GCP негізіндегі тәсіл қораптан шыққан барлық талаптарды дерлік жауып, инженерлерге IPsec туннельдерін баптауға емес, бизнес-логикаға уақыт қалдырады.

Қорытынды

Қауіпсіз банктік инфрақұрылымды 12 минут ішінде орналастыру (Terraform құбыры дәл осынша уақыт жұмыс істейді) — бұл сиқыр емес, бұл дұрыс абстракцияларды пайдаланудың нәтижесі. Google Cloud Platform параноиктер үшін керемет құралдар жиынтығын ұсынады. Дерекқордың ағып кетуі бизнестің соңын білдіретін әлемде, архитектурадан үнемдеу — қылмыс.

Осы мақалада келтірілген Terraform скрипттерін (және басқаларын) біз blog-configs ашық репозиторийіне салдық. Оқыңыз, енгізіңіз, аудиторлар сіздің архитектураңызға қарап бақыттан жыласын.

Егер сіз Қазақстанда финтех-жобаны іске қосып жатсаңыз және сізге архитектура, AIFC аудитінен өту немесе миграция бойынша көмек қажет болса — OZAT командасы жүйе жылдам, әзірлеушілер бақытты, ал қауіпсіздік бұзылмайтындай етіп гайкаларды қалай бұрау керектігін біледі. Өндірісте (prod) кездескенше!

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

Инженерлік блог авторы

Google Cloud архитектурасы саласындағы сарапшы және 15 жылдан астам тәжірибесі бар Senior Full-Stack әзірлеушісі. Ақауға төзімді архитектураларға, жоғары жүктемелі жобаларды оңтайландыруға және AI (Vertex AI) интеграциясына маманданған.

Сараптама: GCP, Kubernetes, Микросервистер, React, Node.js

АХҚО (AIFC) заңдары бойынша FinTech: Аудиторлар алдында ұятқа қалмайтын банктік инфрақұрылымды GCP-де 12 минутта көтеру

Паранойяға кіріспе: Аудиторлар бізден не қалайды?

1-қадам: Іргетас. Желі және жеке GKE кластерлері

2-қадам: Шифрлау кілттерін басқару (KMS)

3-қадам: Болат күмбез - VPC Service Controls

Cloud CDN: Сайтыңызды Ақтауда да, Өскеменде де бір секундта қалай жүктеуге болады

4-қадам: CI/CD және Audit Logs

Комплаенс көрсеткіштеріне шолу (дейін және кейін)

АХҚО (AIFC) аудитіне дайындық деңгейі

Қорытынды

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

Пікірлер (0)