Bài 28 — Secrets Management — Secrets Manager, KMS, Vault

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn vừa hoàn thành một dự án web thương mại điện tử cho một shop mỹ phẩm ở Sài Gòn. Code chạy mượt, giao diện đẹp, thanh toán qua VNPay hoạt động ngon lành. Bạn đẩy code lên GitHub để đồng nghiệp cùng review. Ba ngày sau, hóa đơn cloud của bạn nhảy vọt lên 40 triệu đồng — có ai đó đã quét thấy AWS access key mà bạn vô tình commit vào file config.php, rồi dùng nó để chạy hàng chục máy đào tiền ảo.

Đây không phải chuyện giả tưởng. Theo các báo cáo bảo mật, mỗi ngày có hàng chục nghìn secret bị lộ trên các repo công khai, và các bot dò quét chúng chỉ trong vài phút sau khi commit. Bí mật (secret) bị lộ là một trong những nguyên nhân hàng đầu gây ra sự cố bảo mật cloud.

Bài học này tập trung vào Secrets Management — nghệ thuật và kỷ luật lưu trữ, phân phối, xoay vòng và kiểm soát truy cập các thông tin nhạy cảm. Chúng ta sẽ đi sâu vào ba công cụ tiêu biểu: AWS Secrets Manager, KMS (Key Management Service) và HashiCorp Vault. Đây là kỹ năng nền tảng mà bất kỳ kỹ sư DevOps nào cũng phải nắm vững, vì một secret bị rò rỉ có thể xóa sạch mọi công sức bảo mật khác của bạn.

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

Secret là gì?

"Secret" là bất kỳ thông tin nào mà nếu lọt ra ngoài sẽ cho phép kẻ xấu truy cập trái phép vào hệ thống của bạn. Các loại phổ biến:

• API key của SaaS bên thứ ba: ví dụ key gọi API của OpenAI, Stripe, VNPay, Zalo OA, hay dịch vụ gửi SMS. Ai có key này thì gọi API dưới danh nghĩa (và túi tiền) của bạn.
• Database password: mật khẩu kết nối tới MySQL, PostgreSQL, MongoDB. Lộ ra là mất toàn bộ dữ liệu khách hàng.
• TLS private key: khóa riêng của chứng chỉ HTTPS. Kẻ xấu có nó có thể giả mạo website của bạn hoặc giải mã lưu lượng.
• OAuth client secret: bí mật dùng khi tích hợp đăng nhập Google/Facebook. Lộ ra thì kẻ xấu có thể mạo danh ứng dụng của bạn.
• Encryption key: khóa dùng để mã hóa dữ liệu at-rest. Đây là "chìa khóa của mọi chìa khóa".

Điểm chung: secret không phải là dữ liệu để hiển thị, mà là thông tin xác thực (credential) cần được bảo vệ nghiêm ngặt suốt vòng đời.

Ba trụ cột của Secrets Management

1. Lưu trữ tập trung và mã hóa (Centralized encrypted storage)

Thay vì rải secret khắp nơi — trong code, file .env, biến môi trường trên server, tin nhắn Slack — bạn gom tất cả vào một kho duy nhất được mã hóa. AWS Secrets Manager và Vault đóng vai trò kho này. Khi ứng dụng cần secret, nó gọi API tới kho để lấy về lúc runtime, chứ không lưu cứng trong code.

2. Quản lý khóa mã hóa (KMS — Key Management Service)

Vấn đề "con gà và quả trứng": để mã hóa secret, bạn cần một khóa; nhưng khóa đó cũng là secret. KMS giải quyết bằng cách quản lý các master key trong phần cứng chuyên dụng (HSM — Hardware Security Module). Master key không bao giờ rời khỏi HSM. Kỹ thuật envelope encryption hoạt động thế này: KMS sinh ra một "data key" để mã hóa dữ liệu của bạn, rồi mã hóa chính data key đó bằng master key. Bạn lưu data key đã mã hóa bên cạnh dữ liệu; khi cần dùng, gửi nó lên KMS để giải mã. Master key nằm an toàn trong HSM suốt quá trình.

3. Xoay vòng và kiểm soát truy cập (Rotation & access control)

Secret không nên "sống vĩnh viễn". Rotation là việc tự động thay secret định kỳ (ví dụ mỗi 30 ngày đổi database password). Nếu một secret cũ bị lộ mà bạn không biết, việc xoay vòng vẫn tự động vô hiệu hóa nó. Kết hợp với IAM policy để quy định chính xác ai/service nào được đọc secret nào — nguyên tắc least privilege (quyền tối thiểu).

So sánh nhanh ba công cụ

• AWS Secrets Manager: dịch vụ được quản lý hoàn toàn (managed), tích hợp sâu với AWS, hỗ trợ auto-rotation cho RDS sẵn có. Tính phí ~0.40 USD/secret/tháng cộng phí API call. Phù hợp khi bạn ở trong hệ sinh thái AWS.
• AWS KMS: chuyên về quản lý khóa mã hóa, không lưu secret dạng chuỗi mà lưu/quản lý khóa. Là nền tảng bên dưới cho nhiều dịch vụ khác (S3, EBS, Secrets Manager đều dùng KMS).
• HashiCorp Vault: giải pháp mã nguồn mở, chạy được multi-cloud và on-premise. Mạnh nhất ở dynamic secrets (sinh credential tạm thời theo yêu cầu) và tính trung lập với nhà cung cấp cloud. Phù hợp với môi trường hybrid hoặc multi-cloud, nhưng bạn phải tự vận hành (trừ khi dùng bản HCP Vault managed).

Anti-pattern — những cách làm SAI phổ biến

Đây chính là phần "Anti-" trong dàn ý gốc, và nó cực kỳ quan trọng:

• Hardcode secret trong source code: viết thẳng password = "abc123" vào file. Sai kinh điển nhất.
• Commit file .env chứa secret lên Git: kể cả repo private, vẫn nguy hiểm vì lịch sử Git giữ lại vĩnh viễn.
• Truyền secret qua biến môi trường không mã hóa rồi để lộ qua log hoặc lệnh ps trên server.
• Dùng chung một secret cho mọi môi trường (dev, staging, production dùng chung một database password).
• Không bao giờ xoay vòng secret — dùng một key suốt nhiều năm.
• Chia sẻ secret qua chat (Slack, Telegram, Zalo) rồi để đó mãi mãi trong lịch sử chat.

Tình huống thực tế

Tình huống 1: Startup fintech TP.HCM và sự cố key rò rỉ

Một startup fintech ở Quận 1 (gọi là FinViet) có 15 kỹ sư, xây dựng app ví điện tử trên AWS. Ban đầu, để "cho nhanh", họ để database password và API key của cổng thanh toán trong file application.properties được đóng gói vào Docker image.

Một hôm, một dev junior push nhầm image lên Docker Hub ở chế độ public. Chỉ sau 6 tiếng, đội bảo mật phát hiện có truy vấn lạ tới database production từ một IP ở nước ngoài. May mắn là database có bật giới hạn IP nên chưa mất dữ liệu, nhưng đây là hồi chuông cảnh tỉnh.

Diễn giải: Họ triển khai lại với AWS Secrets Manager. Database credential được lưu trong Secrets Manager, ứng dụng dùng IAM role của ECS task để gọi GetSecretValue lúc khởi động. Docker image không còn chứa bất kỳ secret nào. Họ cũng bật auto-rotation 30 ngày cho RDS. Chi phí thêm chỉ khoảng 8 secret × 0.40 USD ≈ 3.2 USD/tháng — rẻ hơn nhiều so với thiệt hại tiềm tàng.

Bài học: Secret phải được nạp lúc runtime qua IAM role, không bao giờ nằm trong artifact (image, package). Định danh của máy (machine identity) qua IAM role thay thế cho việc lưu credential tĩnh.

Tình huống 2: Công ty e-commerce đa cloud dùng Vault

Một sàn thương mại điện tử tầm trung ở Đông Nam Á (đặt tên là ShopSEA) chạy hệ thống trải trên cả AWS và GCP để tối ưu chi phí và tránh phụ thuộc một nhà cung cấp. Họ gặp vấn đề: mỗi cloud có công cụ secret riêng, đội dev phải học hai hệ thống, và không có nơi nào quản lý tập trung.

Diễn giải: Họ triển khai HashiCorp Vault như một lớp trung gian đứng giữa. Điểm mạnh họ khai thác là dynamic secrets: thay vì cấp một database password cố định, Vault tạo ra một tài khoản database tạm thời với TTL (time-to-live) 1 giờ mỗi khi một service cần kết nối. Sau 1 giờ, credential tự hết hạn và Vault xóa tài khoản đó. Ngay cả khi credential bị chặn bắt trên đường truyền, nó cũng vô dụng sau 60 phút.

Họ cũng dùng tính năng audit log của Vault để ghi lại mọi lần truy cập secret — ai lấy, lúc nào, secret nào — phục vụ điều tra khi có sự cố và đáp ứng yêu cầu tuân thủ.

Bài học: Trong môi trường multi-cloud, một công cụ trung lập như Vault giúp thống nhất cách quản lý. Dynamic secrets là "vũ khí hạng nặng" giảm thiểu rủi ro tối đa vì secret gần như không tồn tại lâu để mà bị lộ.

Tình huống 3: Team nhỏ và bài học về envelope encryption với KMS

Một agency phần mềm ở Đà Nẵng (10 người) làm dự án lưu trữ hồ sơ y tế cho một phòng khám. Yêu cầu: dữ liệu bệnh nhân phải được mã hóa at-rest, và khóa mã hóa phải được bảo vệ tuyệt đối để đáp ứng quy định về dữ liệu cá nhân.

Diễn giải: Họ dùng AWS KMS tạo một Customer Managed Key (CMK). Khi lưu mỗi hồ sơ, ứng dụng gọi KMS GenerateDataKey để lấy một data key, mã hóa hồ sơ bằng data key đó (nhanh, làm local), rồi lưu data key đã được KMS mã hóa cùng với hồ sơ. Master key CMK không bao giờ rời khỏi HSM của AWS. Họ đặt key policy chỉ cho phép service account của ứng dụng gọi Decrypt, và bật CloudTrail để log mọi lời gọi KMS.

Khi một nhân viên nghỉ việc, họ chỉ cần thu hồi quyền IAM của người đó — không cần mã hóa lại toàn bộ dữ liệu, vì người đó chưa bao giờ trực tiếp chạm vào master key.

Bài học: Envelope encryption cho phép mã hóa khối lượng dữ liệu lớn hiệu quả (mã hóa local bằng data key) trong khi vẫn giữ master key an toàn tuyệt đối trong HSM. Kiểm soát truy cập nằm ở tầng chính sách (policy), không ở tầng khóa vật lý.

Hướng dẫn từng bước

Dưới đây là quy trình thiết lập một secret an toàn với AWS Secrets Manager cho ứng dụng — cách làm điển hình mà bạn sẽ gặp trong thực tế.

Bước 1 — Kiểm kê (inventory) secret hiện có. Trước khi làm gì, hãy liệt kê mọi secret đang tồn tại: database password, API key, token. Quét codebase bằng công cụ như gitleaks hoặc trufflehog để tìm secret đã bị hardcode. Đây là bước hay bị bỏ qua nhưng quan trọng nhất.

Bước 2 — Tạo secret trong Secrets Manager.

aws secretsmanager create-secret \
  --name prod/finviet/db-credentials \
  --secret-string '{"username":"app","password":"S3cr3t!2026"}'

Đặt tên theo cấu trúc rõ ràng: môi-trường/dịch-vụ/loại-secret. Điều này giúp viết IAM policy theo prefix dễ dàng.

Bước 3 — Cấp quyền theo least privilege. Tạo một IAM policy chỉ cho phép service đọc đúng secret nó cần:

{
  "Effect": "Allow",
  "Action": "secretsmanager:GetSecretValue",
  "Resource": "arn:aws:secretsmanager:ap-southeast-1:123456789:secret:prod/finviet/db-credentials-*"
}

Gắn policy này vào IAM role của ECS task/Lambda/EC2, không vào một IAM user có access key tĩnh.

Bước 4 — Đọc secret trong ứng dụng lúc runtime. Trong code, gọi SDK để lấy secret khi khởi động, cache lại trong bộ nhớ với TTL ngắn (ví dụ 5 phút) để tránh gọi API quá nhiều:

import boto3, json
client = boto3.client("secretsmanager", region_name="ap-southeast-1")
resp = client.get_secret_value(SecretId="prod/finviet/db-credentials")
creds = json.loads(resp["SecretString"])

Bước 5 — Bật auto-rotation. Với RDS, Secrets Manager có Lambda rotation dựng sẵn. Cấu hình xoay vòng mỗi 30 ngày. Với secret tùy chỉnh, bạn viết Lambda rotation riêng theo mẫu bốn bước: createSecret, setSecret, testSecret, finishSecret.

Bước 6 — Bật audit log. Bật CloudTrail để ghi lại mọi lần GetSecretValue. Thiết lập cảnh báo khi có truy cập bất thường (ví dụ secret production bị đọc từ một region lạ).

Bước 7 — Xóa secret cũ khỏi mọi nơi. Sau khi mọi thứ chạy qua Secrets Manager, xóa file .env, dọn lịch sử Git nếu cần (bằng git filter-repo), và xoay vòng ngay những secret từng bị lộ.

Lỗi thường gặp & mẹo

Lỗi 1 — Nghĩ rằng biến môi trường là an toàn. Nhiều người chuyển secret từ code sang biến môi trường và cho rằng thế là xong. Nhưng biến môi trường có thể lộ qua log lỗi, qua docker inspect, qua tiến trình con. Đúng ra secret nên được lấy từ kho lúc runtime, không đặt cứng vào environment.

Lỗi 2 — Quên rằng lịch sử Git là vĩnh viễn. Xóa secret khỏi file và commit lại KHÔNG loại bỏ nó — nó vẫn nằm trong lịch sử. Nếu đã lỡ commit, coi như secret đó đã bị lộ và phải xoay vòng ngay lập tức, dù bạn có làm sạch lịch sử hay không.

Lỗi 3 — Cấp quyền quá rộng. Dùng Resource: "*" trong IAM policy cho tiện, khiến mọi service đọc được mọi secret. Khi một service bị xâm nhập, kẻ xấu lấy được tất cả. Luôn giới hạn theo ARN cụ thể.

Lỗi 4 — Không phân biệt môi trường. Dùng chung secret cho dev và production. Dev thường có bảo mật lỏng hơn, nên đây là cửa sau vào production. Mỗi môi trường một bộ secret riêng.

Lỗi 5 — Bỏ qua chi phí và rate limit. Gọi GetSecretValue trong vòng lặp nóng hoặc mỗi request có thể tốn tiền và bị throttle. Mẹo: cache secret trong bộ nhớ với TTL hợp lý, dùng thư viện như AWS Secrets Manager caching library.

Mẹo vàng: Áp dụng nguyên tắc "secret zero" — mục tiêu là giảm số secret bạn phải tự quản lý xuống mức thấp nhất, thay bằng identity (IAM role, workload identity). Máy tự chứng minh danh tính của nó thay vì mang theo mật khẩu.

Bài tập thực hành

• Kiểm kê secret: Chọn một project bạn từng làm. Dùng gitleaks detect hoặc trufflehog quét toàn bộ lịch sử Git. Ghi lại có bao nhiêu secret bị hardcode và loại nào.

• Thiết lập Secrets Manager: Trên AWS free tier, tạo một secret chứa cặp username/password giả định. Viết một IAM policy cấp quyền GetSecretValue chỉ cho đúng secret đó (theo ARN). Viết một đoạn script Python/Node đọc secret ra và in ra màn hình.

• Thực hành envelope encryption: Tạo một KMS key, dùng GenerateDataKey lấy một data key, mã hóa một file văn bản nhỏ bằng data key (local), lưu lại data key đã mã hóa, rồi giải mã ngược lại. Ghi chú lại luồng dữ liệu.

• Phân tích anti-pattern: Viết một danh sách 5 chỗ trong hệ thống hiện tại của bạn (hoặc một hệ thống giả định) mà secret có thể đang bị lưu sai cách. Với mỗi chỗ, đề xuất cách khắc phục.

• (Nâng cao) Thử Vault: Chạy Vault ở chế độ dev bằng Docker (vault server -dev). Cấu hình một database secrets engine và tạo thử một dynamic secret có TTL 60 giây. Quan sát credential tự hết hạn.

Tóm tắt

Secrets Management không phải chuyện "nice-to-have" mà là kỷ luật bắt buộc trong mọi hệ thống cloud nghiêm túc. Những điểm cốt lõi cần khắc ghi:

• Secret là mọi credential nhạy cảm: API key, database password, TLS private key, OAuth client secret, encryption key. Lộ một cái là đủ để sập cả hệ thống.
• Ba trụ cột: lưu trữ tập trung có mã hóa (Secrets Manager/Vault), quản lý khóa mã hóa (KMS với envelope encryption), và xoay vòng cùng kiểm soát truy cập theo least privilege.
• AWS Secrets Manager phù hợp hệ sinh thái AWS; KMS là nền tảng quản lý khóa bên dưới; Vault mạnh cho multi-cloud và dynamic secrets.
• Tránh các anti-pattern: đừng hardcode, đừng commit .env, đừng dùng chung secret giữa các môi trường, đừng bao giờ ngừng xoay vòng.
• Nạp secret lúc runtime qua IAM role/identity, không nhét vào artifact. Hướng tới "secret zero" — thay mật khẩu tĩnh bằng danh tính động.

Nếu bạn chỉ nhớ một câu từ bài này, hãy nhớ: một secret đã bị commit là một secret đã bị lộ — hãy xoay vòng nó ngay. Ở các bài tiếp theo, chúng ta sẽ đi vào Compliance & Data Residency, nơi những kỹ năng bảo vệ secret này trở thành yêu cầu pháp lý thực sự.