Cloud DE 4 — Mạng & bảo mật nền tảng dữ liệu

Bảo mật không phải là lớp phủ cuối cùng

Ở Cloud DE 3 — Compute ta đã ghép đúng loại compute với workload. Nhưng một cụm Spark chạy đúng, một warehouse truy vấn nhanh mà để lộ ra internet hoặc cấp quyền quá tay thì với một ngân hàng là thảm hoạ: rò rỉ dữ liệu khách hàng, phạt tuân thủ, mất niềm tin. Trong ngân hàng, mạng và bảo mật không phải phần thêm vào cuối — chúng là ràng buộc thiết kế từ ngày đầu.

Bài này đi qua hai trụ cột: mạng (dữ liệu chảy qua đường nào, ai chạm được vào endpoint) và danh tính & quyền (ai được làm gì với dữ liệu), cộng với mã hoá, secrets, audit và tuân thủ. Đây là những khái niệm nền — chi tiết nghiệp vụ ngân hàng sâu hơn ở Cloud DE 8 — Kiến trúc dữ liệu ngân hàng, và mảng bảo mật dữ liệu chuyên đề ở sec-08 — Bảo mật dữ liệu ngân hàng.

Nguyên tắc xuyên suốt: defense-in-depth (nhiều lớp phòng thủ, thủng lớp này vẫn còn lớp khác) và zero trust (không tin mặc định thứ gì, luôn xác thực và cấp quyền tối thiểu).

---

Phần I — Mạng: dựng đường đi cho dữ liệu

VPC/VNet — mạng riêng ảo của bạn

VPC (Virtual Private Cloud, AWS/GCP) hay VNet (Virtual Network, Azure) là một mạng riêng ảo biệt lập trong cloud, có dải IP riêng (ví dụ 10.0.0.0/16). Mọi tài nguyên bạn dựng — VM, cụm EMR, database — nằm trong VPC này và không thấy được từ VPC của khách khác. Đây là ranh giới cô lập mạng cơ bản nhất.

Bên trong VPC, bạn chia thành subnet — các dải con gắn với một vùng khả dụng (AZ). Điểm quan trọng nhất với dữ liệu là phân biệt:

• Subnet public: có đường ra internet trực tiếp (qua internet gateway). Đặt ở đây: load balancer, bastion host, thứ cần nhận traffic từ ngoài.
• Subnet private: không có đường vào từ internet. Đây là nơi đặt mọi dịch vụ dữ liệu: database, warehouse, cụm Spark, feature store. Chúng vẫn ra internet được (để tải patch) nhưng qua NAT gateway — một chiều, ngoài không gọi vào được.

Nguyên tắc vàng cho ngân hàng: dịch vụ dữ liệu luôn nằm trong subnet private, không bao giờ để lộ IP public.

Route table, internet gateway, NAT gateway

• Route table: bảng định tuyến gắn với mỗi subnet, quyết định traffic đi đâu. Subnet public có route 0.0.0.0/0 → internet gateway; subnet private có route 0.0.0.0/0 → NAT gateway.
• Internet gateway (IGW): cổng hai chiều ra/vào internet, chỉ gắn cho public subnet.
• NAT gateway: cho phép tài nguyên private khởi tạo kết nối ra ngoài (pull image, gọi API) nhưng chặn kết nối đến từ bên ngoài. Đây là cách một database private vẫn update được mà không lộ mặt ra internet.

Security group & NACL — hai lớp tường lửa

• Security group (SG): tường lửa stateful gắn ở cấp tài nguyên (VM, database endpoint). Quy tắc theo kiểu allowlist: "chỉ cho port 5432 từ SG của app-tier". Stateful nghĩa là traffic đã cho vào thì reply tự động được ra. Đây là lớp kiểm soát chính, nên rất chặt.
• NACL (Network ACL): tường lửa stateless ở cấp subnet, chạy trước SG, cho phép cả rule deny (SG chỉ có allow). Dùng như lớp bảo vệ thô ở biên subnet.

Kết hợp: NACL chặn thô ở biên subnet, SG kiểm soát mịn ở từng tài nguyên — một ví dụ điển hình của defense-in-depth.

Private link / private endpoint — chìa khoá cho dữ liệu nhạy cảm

Đây là khái niệm quan trọng nhất của bài với ngân hàng. Vấn đề: khi bạn gọi một dịch vụ managed (S3, BigQuery, một database managed), theo mặc định traffic có thể đi qua internet công cộng hoặc endpoint public của dịch vụ. Với dữ liệu nhạy cảm, điều đó không chấp nhận được.

Private link / private endpoint giải quyết bằng cách tạo một giao diện mạng riêng ngay trong VPC của bạn ánh xạ tới dịch vụ managed. Traffic tới dịch vụ đó không rời khỏi mạng riêng của cloud, không đi ra internet — dù dịch vụ nằm ngoài VPC bạn.

• AWS: VPC Endpoint (Gateway endpoint cho S3/DynamoDB; Interface endpoint / PrivateLink cho hầu hết dịch vụ khác).
• GCP: Private Service Connect / Private Google Access.
• Azure: Private Endpoint / Private Link.

Với ngân hàng, mẫu hình chuẩn là: truy cập warehouse, object store, secrets manager qua private endpoint — vừa không lộ internet, vừa cho phép chặn hẳn public endpoint của dịch vụ.

VPC peering & transit — nối nhiều mạng

Khi có nhiều VPC (mỗi môi trường dev/uat/prod một VPC, hoặc mỗi phòng ban một VPC), bạn cần nối chúng:

• VPC peering: nối trực tiếp hai VPC, traffic đi riêng không qua internet. Không bắc cầu (A-B, B-C không tự thành A-C).
• Transit gateway / hub: một hub trung tâm nối nhiều VPC và cả on-premise (qua VPN/Direct Connect), thay cho mạng lưới peering rối rắm khi số VPC lớn.

Với ngân hàng, kết nối on-premise ↔ cloud thường qua đường riêng (Direct Connect / ExpressRoute) chứ không qua internet, để dữ liệu core banking không bao giờ chạm mạng công cộng.

---

Phần II — IAM: trái tim của bảo mật cloud

Mạng kiểm soát đường đi; IAM (Identity and Access Management) kiểm soát ai được làm gì. Trong cloud, IAM là lớp bảo mật quan trọng nhất — thủng mạng còn có IAM chặn, nhưng IAM cấu hình sai thì một credential rò rỉ có thể xoá cả data lake.

Ba khối cơ bản

• Principal — chủ thể thực hiện hành động: user (người), role (vai trò tạm mượn), service account / service principal (danh tính cho ứng dụng/dịch vụ).
• Policy — tài liệu (thường JSON) mô tả: principal nào được làm action gì (s3:GetObject) trên resource nào (arn:...:bucket/raw/*), với điều kiện gì.
• Đánh giá quyền: cloud gộp mọi policy áp dụng, mặc định deny, chỉ cho phép khi có allow rõ ràng và không có deny nào đè lên.

Least privilege — chỉ cấp quyền thực sự cần

Đây là nguyên tắc số một: mỗi principal chỉ có đúng quyền tối thiểu để làm việc của nó, không hơn. Job ETL đọc bucket raw thì chỉ cấp read trên raw, không cấp admin toàn tài khoản. Least privilege thu hẹp "bán kính vụ nổ" (blast radius) khi credential bị lộ.

Chống lại nó là thói quen tai hại: cấp *:* (admin) cho tiện, rồi quên thu lại. Trong ngân hàng, mỗi quyền thừa là một lỗ hổng kiểm toán sẽ chỉ ra.

Role & temporary credentials thay cho key tĩnh

Sai lầm phổ biến và nguy hiểm nhất: tạo access key tĩnh (một cặp key sống mãi) rồi nhét vào code, biến môi trường, file config. Key tĩnh không hết hạn, rò rỉ một lần là lộ vĩnh viễn cho tới khi ai đó nhớ ra để thu hồi.

Cách đúng: dùng role và temporary credentials.

• Ứng dụng/VM/pod mượn (assume) một role và nhận credential tạm thời tự hết hạn (vài phút tới vài giờ).
• Không có key nào để rò: credential chỉ sống trong bộ nhớ và tự chết.
• AWS: IAM Role + STS (instance profile cho EC2, IRSA cho EKS pod). GCP: service account + Workload Identity. Azure: Managed Identity.

Quy tắc: ứng dụng chạy trên cloud không bao giờ cần key tĩnh — luôn có cơ chế danh tính-gắn-workload để lấy credential tạm.

Service account cho ứng dụng, không hardcode credential

Ứng dụng dùng service account (danh tính phi-người) với quyền least-privilege riêng. Và tuyệt đối không hardcode credential vào code hay repo. Khi thật sự cần một bí mật (chuỗi kết nối tới hệ on-premise chẳng hạn), đọc nó lúc chạy từ secrets manager — xem mục dưới và gov-05 — Mã hoá & masking / gov-06 — Access control.

---

Phần III — Mã hoá, secrets, bảo vệ dữ liệu

Mã hoá at-rest và in-transit

• At-rest (dữ liệu nằm trên đĩa/object store): ba cloud mặc định mã hoá dữ liệu lưu trữ. Với ngân hàng, ta thường nâng lên customer-managed key (CMK) qua KMS (Key Management Service) để tự kiểm soát vòng đời key và có thể "thu hồi quyền đọc" bằng cách vô hiệu key.
• In-transit (dữ liệu đang truyền): bắt buộc TLS cho mọi kết nối — client tới warehouse, service tới service. Ngân hàng thường enforce TLS và từ chối kết nối không mã hoá.

KMS & xoay vòng key

KMS quản lý key mã hoá tập trung: tạo, phân quyền dùng key (qua IAM), và xoay vòng (rotation) định kỳ. Xoay vòng giới hạn thiệt hại nếu một key bị lộ. Điểm mạnh của mô hình cloud: bản thân dữ liệu được mã hoá bằng data key, data key lại được mã hoá bằng master key trong KMS (envelope encryption) — quản một master key thay vì hàng triệu data key.

Secrets manager — nơi cất bí mật

Mật khẩu DB, API token, chuỗi kết nối không được nằm trong code, biến môi trường plaintext hay file config. Chúng thuộc về secrets manager:

• AWS Secrets Manager / SSM Parameter Store, GCP Secret Manager, Azure Key Vault.
• Ứng dụng đọc secret lúc chạy bằng danh tính của nó (service account), có audit ai đọc secret nào, và tự động xoay vòng (ví dụ đổi mật khẩu DB định kỳ).

Bảo vệ dữ liệu ở tầng lưu trữ

• Block public access: bật chặn công khai ở cấp tài khoản/bucket. Đây là biện pháp cắt tận gốc kịch bản "bucket dữ liệu bị để public" — nguyên nhân của vô số vụ rò rỉ.
• Encryption enforcement: policy từ chối ghi dữ liệu không mã hoá, từ chối kết nối không TLS.
• Data classification: phân loại dữ liệu (public / internal / confidential / PII) để áp chính sách tương ứng.
• DLP (Data Loss Prevention): quét và ngăn dữ liệu nhạy cảm (số thẻ, CCCD) rò ra ngoài phạm vi cho phép.

Chi tiết phân loại PII và masking xem gov-04 — Classification & PII.

---

Phần IV — Audit, tuân thủ, defense-in-depth

Audit & logging — ai làm gì, khi nào

Mọi hành động trên control plane cloud đều phải để lại vết. Audit log trả lời câu hỏi kiểm toán: ai đã gọi API nào, lúc nào, từ IP nào, thành công hay bị từ chối.

• AWS CloudTrail, GCP Cloud Audit Logs, Azure Activity Log.

Với ngân hàng, audit log là bắt buộc theo tuân thủ, phải được ghi bất biến (không sửa được), lưu đủ lâu, và giám sát để phát hiện hành vi bất thường (một service account bỗng đọc toàn bộ bucket PII lúc 3h sáng). Kết hợp với vòng đời & audit dữ liệu ở gov-08 — Lifecycle & Audit.

Tuân thủ: data residency & network isolation

Ngân hàng chịu ràng buộc pháp lý và quy định (ở Việt Nam là các quy định về bảo vệ dữ liệu cá nhân và an toàn hệ thống thông tin):

• Data residency: dữ liệu khách hàng phải nằm trong vùng (region) được phép — chọn đúng region, chặn sao chép ra vùng khác.
• Network isolation: dữ liệu nhạy cảm phải nằm trong mạng cô lập, truy cập qua private link, không đi internet.
• Phân tách môi trường (dev/uat/prod), phân tách nhiệm vụ (separation of duties).

Xem thêm khía cạnh quyền riêng tư & tuân thủ ở gov-07 — Privacy & Compliance.

Defense-in-depth & zero trust

Hai nguyên tắc bao trùm mọi thứ trên:

• Defense-in-depth: nhiều lớp phòng thủ độc lập — mạng private, SG chặt, IAM least-privilege, mã hoá, audit. Thủng một lớp vẫn còn các lớp khác. Không lớp nào là "viên đạn bạc".
• Zero trust: không tin mặc định dựa trên vị trí mạng ("ở trong VPC nên tin được"). Mọi truy cập đều phải xác thực danh tính và cấp quyền tối thiểu, kể cả traffic nội bộ. Zero trust là lý do least-privilege và private endpoint cùng tồn tại — mạng riêng chưa đủ, danh tính vẫn phải kiểm.

---

Bảng ánh xạ ba cloud

Khái niệm	AWS	GCP	Azure
Mạng riêng ảo	VPC	VPC	Virtual Network (VNet)
Subnet public/private	Subnet + route table	Subnet + route	Subnet + route table
Ra internet 1 chiều	NAT Gateway	Cloud NAT	NAT Gateway
Tường lửa tài nguyên	Security Group	Firewall Rules	Network Security Group
Private endpoint	VPC Endpoint / PrivateLink	Private Service Connect	Private Endpoint / Private Link
Nối nhiều mạng	VPC Peering / Transit GW	VPC Peering / Network Connectivity Center	VNet Peering / Virtual WAN
Danh tính & quyền	IAM	IAM	Entra ID + Azure RBAC
Danh tính cho workload	IAM Role + STS / IRSA	Service Account + Workload Identity	Managed Identity
Quản lý key	KMS	Cloud KMS	Key Vault (keys)
Secrets	Secrets Manager / SSM	Secret Manager	Key Vault (secrets)
Audit log	CloudTrail	Cloud Audit Logs	Activity Log

Tên khác nhau nhưng mô hình giống nhau: mạng riêng có public/private, tường lửa, private endpoint; IAM với role + least privilege; KMS + secrets; audit log tập trung. Nắm mô hình rồi thì đổi cloud chỉ là đổi tên.

---

Use case thực tế

Bối cảnh: NCB xây nền tảng dữ liệu trên AWS, chứa sao kê giao dịch và hồ sơ khách hàng (PII). Yêu cầu tuân thủ: dữ liệu không được lộ internet, phải mã hoá, mọi truy cập phải kiểm toán được. Trạng thái ban đầu có mấy vấn đề: một bucket staging lỡ để public, job ETL dùng access key tĩnh nhét trong biến môi trường, và analyst nối tới warehouse qua endpoint public.

Sau khi rà soát theo defense-in-depth:

(1) Cô lập mạng. Toàn bộ warehouse, cụm Spark, database chuyển vào private subnet — không còn IP public. Analyst và service truy cập warehouse qua VPC Interface Endpoint (PrivateLink); endpoint public của warehouse bị chặn. Traffic tới S3 đi qua Gateway VPC Endpoint, không rời mạng AWS.

(2) Khoá tầng lưu trữ. Bật Block Public Access ở cấp tài khoản → bucket staging không thể public dù cấu hình sai. Bật encryption enforcement với KMS CMK và policy từ chối ghi không mã hoá / kết nối không TLS.

(3) Bỏ key tĩnh. Job ETL chạy trên EKS chuyển sang IRSA — pod mượn IAM role, nhận credential tạm tự hết hạn. Không còn key tĩnh nào trong biến môi trường. Chuỗi kết nối tới hệ on-premise chuyển vào Secrets Manager, đọc lúc chạy, xoay vòng định kỳ.

(4) Least privilege + audit. Role ETL chỉ có read trên raw và write trên curated, không có quyền xoá hay quyền admin. Bật CloudTrail ghi bất biến, giám sát cảnh báo khi có principal đọc bất thường bucket PII.

Kết quả: dữ liệu nhạy cảm không còn đường ra internet, không còn key tĩnh để rò, một cấu hình sai đơn lẻ (public bucket) đã bị chặn ở lớp tài khoản, và mọi hành động đều để lại vết kiểm toán. Đây là mô tả kịch bản minh hoạ điển hình, không phải cấu hình cụ thể của hệ thống thật.

---

Ghi nhớ

• Dịch vụ dữ liệu luôn nằm trong private subnet, không lộ IP public; ra internet (nếu cần) chỉ một chiều qua NAT gateway.
• Private link / private endpoint là chìa khoá cho dữ liệu nhạy cảm: truy cập dịch vụ managed qua mạng riêng, không đi internet.
• Security group (stateful, cấp tài nguyên) là lớp tường lửa chính; NACL (stateless, cấp subnet) là lớp thô — kết hợp cho defense-in-depth.
• IAM là trái tim bảo mật cloud; nguyên tắc số một là least privilege — chỉ cấp quyền tối thiểu, thu hẹp blast radius.
• Dùng role + temporary credentials (IRSA / Workload Identity / Managed Identity), không dùng key tĩnh, không hardcode credential — bí mật để trong secrets manager.
• Mã hoá at-rest (KMS CMK, xoay vòng key) và in-transit (enforce TLS) là mặc định; bật block public access và encryption enforcement ở tầng lưu trữ.
• Audit log (CloudTrail / Cloud Audit Logs / Activity Log) ghi bất biến "ai làm gì" — bắt buộc cho tuân thủ ngân hàng, cùng data residency và network isolation.
• Bao trùm tất cả: defense-in-depth (nhiều lớp) và zero trust (không tin mặc định theo vị trí mạng, luôn xác thực + cấp quyền tối thiểu).