Cloud DE 6 — IaC & DevOps cho hạ tầng dữ liệu

Vì sao không "click tay" nữa

Ở các bài trước ta đã dựng từng viên gạch: lưu trữ, tính toán, mạng & bảo mật, rồi dịch vụ dữ liệu managed. Câu hỏi thực chiến là: tạo và quản lý những tài nguyên đó bằng cách nào?

Cách "click tay" — vào console AWS/Azure/GCP bấm nút tạo bucket, tạo VPC, cấp quyền — chạy được cho một môi trường nhỏ, nhưng gây ra hàng loạt vấn đề khi lên quy mô ngân hàng:

• Không tái lập được: dev dựng tay một pipeline, đến khi cần dựng lại y hệt ở staging/prod thì không ai nhớ đã bấm những gì. Mỗi môi trường một kiểu.
• Không có lịch sử thay đổi: ai đã mở port 5432 ra Internet lúc nào, vì sao? Console không lưu vết như Git.
• Drift (lệch cấu hình): một người sửa nóng bucket policy trên console để "chữa cháy", cấu hình thực tế lệch khỏi thiết kế, không ai biết.
• Không review được: thay đổi hạ tầng nhạy cảm (mở firewall, cấp IAM) đi thẳng vào production, không qua ánh mắt thứ hai.
• Cấu hình sai gây lộ dữ liệu: một cú click nhầm để bucket ở chế độ public là đủ để rò rỉ dữ liệu khách hàng — rủi ro sinh tử với ngân hàng.

Infrastructure as Code (IaC) giải quyết tất cả: mô tả toàn bộ hạ tầng bằng file code, đưa vào Git, review, tự động áp dụng. Hạ tầng trở thành một artifact phần mềm — có version, có test, có pipeline, có audit trail.

Infrastructure as Code là gì và lợi ích

IaC là việc định nghĩa hạ tầng (mạng, máy ảo, bucket, database, IAM…) bằng file văn bản có thể version-control, thay vì thao tác thủ công. Lợi ích cốt lõi:

Với NCB, ba lợi ích quan trọng nhất là tái lập (dựng lại nhanh khi audit/DR), audit trail (chứng minh tuân thủ với thanh tra), và chống cấu hình sai (guardrail chặn ngay từ code).

Declarative vs Imperative

Có hai phong cách mô tả hạ tầng:

• Imperative (mệnh lệnh): bạn viết ra các bước phải làm — "tạo VPC, rồi tạo subnet, rồi gắn route table…". Giống viết script bash. Nếu chạy lại, phải tự lo trạng thái hiện tại (đã tạo chưa?).
• Declarative (khai báo): bạn mô tả trạng thái mong muốn cuối cùng — "tôi muốn có 1 VPC, 3 subnet, 1 bucket mã hoá". Công cụ tự tính ra cần làm gì để đạt trạng thái đó, và idempotent (chạy nhiều lần vẫn ra một kết quả).

IaC hiện đại chuộng declarative vì nó khớp tự nhiên với ý tưởng "hạ tầng mong muốn = source of truth". Terraform, CloudFormation, Bicep đều declarative.

Các công cụ IaC chính

Terraform là lựa chọn phổ biến nhất cho đội data đa cloud vì trung lập nhà cung cấp và hệ sinh thái module khổng lồ. Phần còn lại của bài đi sâu vào Terraform.

Khái niệm cốt lõi trong Terraform

• Provider: plugin nói chuyện với một nền tảng (aws, azurerm, google). Khai báo provider + credential để Terraform gọi API.
• Resource: một đơn vị hạ tầng cần quản lý (một bucket, một subnet, một IAM role). Đây là "danh từ" chính của Terraform.
• State file: Terraform lưu ánh xạ giữa code và tài nguyên thật vào file terraform.tfstate. Đây là "bộ nhớ" giúp nó biết cái gì đã tạo, để lần sau chỉ đổi phần khác biệt. State chứa dữ liệu nhạy cảm (đôi khi cả secret) → không bao giờ commit vào Git.
• Remote backend: thay vì để state trên máy cá nhân, lưu nó tập trung (S3 + DynamoDB lock, Azure Storage, GCS, Terraform Cloud). Cho phép cả đội dùng chung state và khoá (locking) để tránh hai người apply cùng lúc gây hỏng.
• plan / apply: terraform plan tính ra kế hoạch thay đổi (tạo/sửa/xoá gì) mà CHƯA đụng vào hạ tầng — đây là "bản xem trước" để review. terraform apply mới thực sự thi hành.
• Module: gói tài nguyên tái dùng, có input (variable) và output. Ví dụ module "landing-zone-account" hay "secure-data-bucket" dùng lại cho mọi môi trường.
• Workspace: nhiều trạng thái tách biệt từ cùng một code, thường dùng tách dev/staging/prod (dù nhiều đội chuộng tách bằng thư mục/backend riêng cho an toàn hơn).

Ví dụ Terraform HCL (minh hoạ — không phải SQL)

Đoạn dưới chỉ để minh hoạ một bucket dữ liệu "an toàn theo mặc định" — bật mã hoá, chặn public, bật versioning:

terraform {
  backend "s3" {
    bucket         = "ncb-tfstate-prod"
    key            = "data-platform/terraform.tfstate"
    dynamodb_table = "ncb-tf-lock"   # khoá state
    encrypt        = true
  }
}

provider "aws" {
  region = "ap-southeast-1"
}

variable "environment" { type = string }

resource "aws_s3_bucket" "raw_zone" {
  bucket = "ncb-datalake-raw-${var.environment}"

  tags = {
    owner       = "data-platform"
    environment = var.environment
    cost_center = "CC-DATA-01"
    data_class  = "confidential"
  }
}

# Chặn public hoàn toàn — guardrail chống lộ dữ liệu
resource "aws_s3_bucket_public_access_block" "raw_zone" {
  bucket                  = aws_s3_bucket.raw_zone.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "raw_zone" {
  bucket = aws_s3_bucket.raw_zone.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.data.arn
    }
  }
}

Quy trình: terraform init (tải provider, kết nối backend) → terraform plan (xem trước) → review PR → terraform apply (thi hành). Tài nguyên trên là an toàn theo mặc định vì guardrail nằm ngay trong code, không phụ thuộc trí nhớ người dựng. Xem thêm về mã hoá & chống lộ dữ liệu ở bảo mật dữ liệu ngân hàng.

Landing zone & tổ chức tài khoản

Ở quy mô ngân hàng, không dồn mọi thứ vào một tài khoản (account) cloud. Landing zone là khung tổ chức nhiều account/subscription theo chuẩn, đặt sẵn guardrail trước khi đội bắt đầu dựng workload.

Nguyên tắc multi-account/subscription:

• Tách theo môi trường: dev / staging / prod ở các account riêng → sự cố hoặc thao tác nhầm ở dev không đụng tới prod; giới hạn quyền (blast radius) rõ ràng.
• Tách theo đơn vị: đội data, đội core banking, đội thẻ… mỗi bên account riêng để tách chi phí và quyền.
• Guardrail/policy tập trung: quản trị đặt chính sách ở cấp tổ chức, các account con bắt buộc tuân theo, không thể vượt rào.
  • AWS: Service Control Policies (SCP) ở AWS Organizations — ví dụ chặn tạo tài nguyên ở region ngoài Việt Nam/Singapore, cấm tắt CloudTrail.
  • Azure: Azure Policy ở Management Group — ví dụ bắt buộc mọi storage account phải bật mã hoá.

Landing zone thường được dựng bằng chính IaC (Terraform module, hoặc AWS Control Tower / Azure Landing Zones) để bản thân khung tổ chức cũng tái lập và version được.

CI/CD & GitOps cho hạ tầng

Đưa IaC vào pipeline biến "thay đổi hạ tầng" thành một quy trình phần mềm có kiểm soát. Đây chính là GitOps: Git là source of truth, mọi thay đổi hạ tầng đi qua commit/PR, pipeline tự đồng bộ trạng thái thực tế về đúng như Git.

Các bước then chốt trong pipeline:

1. Test/kiểm tra IaC: terraform fmt (định dạng), terraform validate (cú pháp), tflint (lỗi thường gặp) — chạy tự động khi mở PR.
2. Plan review: pipeline chạy terraform plan và đăng kết quả plan lên PR. Reviewer thấy chính xác sẽ tạo/xoá/sửa gì trước khi đồng ý. Với prod, một cú xoá database nhầm sẽ lộ ngay ở plan.
3. Apply tự động có phê duyệt: sau khi PR merge, terraform apply chạy tự động — nhưng với môi trường prod thường có cổng phê duyệt thủ công (manual approval gate) bắt buộc một người có quyền bấm duyệt.

Cùng tinh thần GitOps, các pipeline dữ liệu (Airflow DAG, dbt model) cũng nên đi qua Git + CI/CD. Nếu chạy trên Kubernetes, xem thêm vận hành production trên K8s.

Tagging chuẩn — nền tảng của quản trị & chi phí

Mọi tài nguyên nên mang tag chuẩn hoá bắt buộc. Tag là cặp key-value gắn vào tài nguyên, và là mấu chốt để phân bổ chi phí, quản lý chủ sở hữu, tách môi trường.

Bộ tag tối thiểu nên bắt buộc:

Vì tag định nghĩa ngay trong IaC nên nó luôn nhất quán — khác hẳn tag gắn tay hay bị quên. Đây là điều kiện cần để làm FinOps — quản trị chi phí cloud: không có tag chuẩn thì không thể trả lời "đội data tiêu bao nhiêu, pipeline nào tốn nhất".

Quản lý state & secret an toàn

Hai thứ dễ gây rò rỉ nhất trong IaC:

• State file: chứa ánh xạ tài nguyên và có thể chứa giá trị nhạy cảm (mật khẩu DB, khoá). Quy tắc: (1) không commit state vào Git; (2) lưu ở remote backend có mã hoá (S3+KMS, Azure Storage với mã hoá); (3) bật state locking để tránh hai apply đồng thời; (4) giới hạn quyền đọc state chặt như dữ liệu mật.
• Secret trong code: tuyệt đối không hard-code mật khẩu/khoá vào file .tf. Dùng secret manager (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) và cho Terraform đọc lúc chạy, hoặc truyền qua biến môi trường/CI secret. Sinh mật khẩu ngẫu nhiên bằng random_password rồi lưu thẳng vào Key Vault, không để lộ ra plaintext.

Policy as Code — tự động ép tuân thủ

Policy as Code biến các quy tắc tuân thủ hạ tầng thành code kiểm tra tự động, chặn vi phạm ngay ở pipeline trước khi tài nguyên được tạo. Đây là cách một ngân hàng ép quy định mà không phụ thuộc con người rà tay.

Ví dụ quy tắc điển hình:

• Cấm tạo bucket/storage public (chống lộ dữ liệu).
• Bắt buộc mã hoá at-rest cho mọi storage và database.
• Cấm mở security group 0.0.0.0/0 vào cổng nhạy cảm (5432, 3306…).
• Bắt buộc đủ bộ tag chuẩn mới cho apply.

Công cụ phổ biến:

Chèn các bước này vào CI (như sơ đồ GitOps ở trên): PR nào tạo bucket public hay quên mã hoá sẽ fail ngay, không bao giờ tới được production. Liên hệ nguyên tắc phòng thủ ở bảo mật & mạng và bảo mật dữ liệu ngân hàng.

Use case thực tế

Bối cảnh: NCB cần dựng data platform mới trên AWS cho 3 môi trường (dev/staging/prod), yêu cầu: mọi bucket phải mã hoá KMS, không bucket nào được public, đủ tag chi phí, và toàn bộ audit được cho thanh tra ngân hàng.

Cách làm bằng IaC:

1. Landing zone: dùng Terraform + AWS Organizations dựng 4 account (shared-services + dev/staging/prod), gắn SCP cấm tạo tài nguyên ngoài region ap-southeast-1/ap-southeast-2 và cấm tắt CloudTrail.
2. Module tái dùng: viết module secure-data-bucket (mã hoá KMS + public access block + versioning + tag bắt buộc). Cả 3 môi trường gọi cùng module, chỉ khác biến environment → đảm bảo dev/staging/prod giống hệt nhau về cấu hình an toàn.
3. Remote backend: state lưu ở S3 riêng của account shared-services, bật mã hoá + DynamoDB lock; không lập trình viên nào giữ state trên máy.
4. Pipeline GitOps: mỗi PR chạy tflint + tfsec + terraform plan. tfsec chặn ngay nếu ai đó lỡ tạo bucket public hoặc quên mã hoá. Plan đăng lên PR để reviewer duyệt.
5. Apply có phê duyệt: prod bắt buộc một trưởng nhóm bấm approve trước khi apply.

Kết quả: khi thanh tra hỏi "chứng minh không bucket nào public trong 6 tháng qua", đội trả lời bằng lịch sử Git + log tfsec đã pass mọi PR — không phải kiểm tra tay. Khi cần dựng môi trường DR ở region khác, chỉ chạy lại code với biến region khác. Khi kế toán hỏi chi phí đội data, tag cost_center cho câu trả lời chính xác. Toàn bộ hạ tầng tái lập, có version, tự động ép tuân thủ — đúng ba yêu cầu sinh tử của ngân hàng.

Ghi nhớ

• IaC = quản lý hạ tầng như code: tái lập, versioning, review qua PR, chống drift, tự động hoá, và code là tài liệu sống. Đừng "click tay" ở quy mô ngân hàng.
• Declarative (mô tả trạng thái mong muốn, idempotent) được ưa chuộng hơn imperative. Terraform/CloudFormation/Bicep đều declarative.
• Terraform phổ biến nhất vì đa cloud (HCL). Nắm chắc: provider, resource, state + remote backend (có lock), plan/apply, module tái dùng, workspace.
• State chứa dữ liệu nhạy cảm → không commit vào Git, lưu remote backend có mã hoá + locking. Secret không hard-code → dùng Key Vault/Secrets Manager/Vault.
• Landing zone multi-account: tách dev/staging/prod và theo đơn vị; guardrail tập trung bằng SCP (AWS) / Azure Policy.
• GitOps: Git là source of truth; pipeline chạy lint → policy check → plan review → apply (prod có phê duyệt thủ công).
• Tagging chuẩn bắt buộc (owner/cost_center/environment/data_class) là nền tảng cho FinOps và quản trị.
• Policy as Code (tfsec/Checkov/OPA/Sentinel) tự động chặn cấu hình sai (bucket public, thiếu mã hoá) ngay ở pipeline — cách ép tuân thủ không dựa vào trí nhớ con người.