Quản lý secret với Vault: đừng hardcode password trong code nữa

Một buổi sáng, developer của một startup fintech ở TP.HCM mở email và thấy thông báo từ AWS: hóa đơn bất thường 2.300 USD chỉ trong một đêm, ai đó đã dùng key của công ty để đào coin trên hàng chục instance EC2. Điều tra ra, nguyên nhân là một dòng AWS_SECRET_KEY bị vô tình đẩy lên repo GitHub public từ hai tuần trước. Bot quét secret tự động đã "nhặt" được key chỉ sau vài phút, và kẻ xấu làm phần còn lại.

Câu chuyện trên không hiếm — chỉ là một trong hàng nghìn vụ rò rỉ secret mỗi năm, mà điểm khởi đầu thường giống hệt nhau: hardcode password, API key, token ngay trong code. Nếu team bạn vẫn lưu password database trong file config hay copy key qua Zalo, bài viết này dành cho bạn. Chúng ta sẽ tìm hiểu vault quản lý secret — cách HashiCorp Vault cất mọi bí mật vào một "két sắt số", cấp phát có kiểm soát, tự động thu hồi, để không còn dòng password nào nằm lẫn trong code nữa.

Vault quản lý secret: 1. Vì sao hardcode password trong code là "bom hẹn giờ"?

Hardcode nghĩa là ghi trực tiếp thông tin nhạy cảm (password, API key, token, private key) vào mã nguồn hoặc file cấu hình đi kèm dự án. Cách làm này tiện lúc viết code, nhưng để lại rủi ro kéo dài suốt vòng đời phần mềm.

Thứ nhất, code có xu hướng lan rộng. Một repo hôm nay private, mai có thể public để demo, ngày kia được fork sang đơn vị outsource. Mỗi bản clone là một bản sao của secret. Càng nhiều người nhìn thấy code, xác suất secret bị lộ càng tăng theo cấp số nhân.

Thứ hai, lịch sử Git không quên. Xóa dòng password ở commit mới nhất không xóa được nó khỏi hàng chục commit cũ. Ai biết SHA của commit cũ vẫn xem được credential — kể cả khi repo đã private trở lại. Muốn "quên" thật phải rewrite toàn bộ lịch sử, vốn là việc tốn kém và rủi ro.

Thứ ba, bot săn secret hoạt động 24/7. Các công cụ như truffleHog, gitleaks hay GitGuardian quét mọi commit public trên GitHub trong vài giây. Quy trình tấn công điển hình: push code → bot match regex (ví dụ sk_live_...) → thử key qua API thật → khai thác. Từ lúc push đến lúc bị lợi dụng có thể chỉ mất dưới 5 phút (minh họa theo kịch bản tấn công phổ biến được mô tả trong các tài liệu bảo mật).

Cuối cùng, thiệt hại không chỉ là tiền. Key bị lộ có thể dẫn tới rò rỉ dữ liệu khách hàng, gián đoạn dịch vụ, mất uy tín — và với doanh nghiệp chịu ràng buộc tuân thủ (ngân hàng, fintech, y tế), đó còn là rủi ro pháp lý.

Vault quản lý secret: 2. Secret thường "chảy" ra ngoài bằng những con đường nào?

Trước khi nói về giải pháp, hãy điểm mặt các kênh rò rỉ phổ biến nhất trong thực tế vận hành của team SME:

• Repo Git (public hoặc bị lộ quyền): kênh số một. Developer quên bỏ .env vào .gitignore, commit nhầm, hoặc repo private bị cấp quyền nhầm cho tài khoản ngoài.
• File cấu hình trên server: config.php, appsettings.json, docker-compose.yml chứa password plaintext, ai SSH vào server là đọc được.
• Chat và ghi chú: gửi key qua Zalo, Slack, Telegram "tạm thời", rồi quên xóa; lưu trong Notion, Google Docs chia sẻ rộng.
• Log và error message: ứng dụng in connection string ra log khi crash, log lại được đẩy lên hệ thống tập trung mà cả team xem được.
• CI/CD pipeline: secret nằm trong script build, trong biến môi trường của job mà mọi thành viên có quyền xem pipeline đều thấy.
• Máy cá nhân: file .env trên laptop developer, laptop mất hoặc bị malware là secret "đi" theo.

Điểm chung: secret tồn tại ở quá nhiều nơi, không ai biết chính xác có bao nhiêu bản sao, và không có cách nào thu hồi triệt để khi có sự cố. Muốn giải quyết tận gốc, cần một nguồn sự thật duy nhất cho mọi bí mật — đó chính là vai trò của Vault.

Vault quản lý secret: 3. HashiCorp Vault là gì và hoạt động ra sao?

HashiCorp Vault là nền tảng quản lý secret mã nguồn mở, được thiết kế để lưu trữ, kiểm soát truy cập và cấp phát mọi loại thông tin nhạy cảm: password, API key, token, chứng chỉ số, khóa mã hóa. Thay vì secret nằm rải rác khắp nơi, tất cả được tập trung trong Vault, và ứng dụng "mượn" secret khi cần thông qua API có xác thực.

Ba nguyên tắc cốt lõi làm nên sức mạnh của Vault:

Mã hóa mọi lúc. Mọi dữ liệu trong Vault đều được mã hóa trước khi ghi xuống storage backend (mặc định là Raft). Kể cả ai đó lấy được file dữ liệu thô cũng không đọc được nội dung.

Không tin ai mặc định (deny by default). Mọi request tới Vault đều phải xác thực và chỉ được phép làm đúng những gì policy cho phép. Không có "quyền ngầm định".

Secret có thời hạn (lease). Vault không chỉ lưu secret tĩnh — nó có thể sinh ra credential động, tự động hết hạn sau một khoảng thời gian. Đây là khác biệt lớn nhất so với việc cất password trong file .env.

Cơ chế seal và unseal: két sắt hai lớp khóa

Khi khởi động, Vault ở trạng thái sealed (niêm phong): toàn bộ dữ liệu mã hóa bằng một root key, và root key này lại bị "chẻ" thành nhiều unseal key (mặc định 5 mảnh, cần ít nhất 3 mảnh để mở — cơ chế Shamir's Secret Sharing). Muốn Vault hoạt động, cần đủ số người giữ key cùng thực hiện vault operator unseal.

Nghe có vẻ rườm rà, nhưng đây chính là lớp bảo vệ cuối cùng: kẻ xấu chiếm được server Vault mà không có đủ unseal key thì dữ liệu vẫn là "cục gạch" mã hóa vô dụng. Team nhỏ có thể dùng auto-unseal qua KMS của cloud provider để đơn giản hóa, với trade-off là phụ thuộc vào nhà cung cấp KMS.

4. Secrets engine: các "ngăn kéo" chuyên dụng của Vault

Trong Vault, secrets engine là module chuyên xử lý một loại secret. Mỗi engine được "mount" tại một đường dẫn riêng và có API riêng. Hiểu đúng các engine giúp bạn chọn đúng công cụ cho từng nhu cầu.

Ví dụ với KV v2 — engine phổ biến nhất cho team mới bắt đầu:

# Kích hoạt KV engine phiên bản 2 (có lưu lịch sử phiên bản)
vault secrets enable -path=secret kv-v2

# Ghi secret cho ứng dụng web
vault kv put secret/webapp/config \
  db_user="app_user" \
  db_password="DoiMatKhauManh_TaiDay_2026" \
  stripe_key="sk_live_..."

# Đọc lại khi cần
vault kv get secret/webapp/config

KV v2 tự động lưu lịch sử các phiên bản: đổi password nhầm vẫn rollback được về bản cũ — điều mà file .env không bao giờ làm được.

5. Dynamic secrets: chìa khóa tự hủy sau vài giờ

Đây là tính năng "đáng tiền" nhất của Vault và là lý do nhiều team chuyển sang vault quản lý secret thay vì chỉ dùng file .env mã hóa. Dynamic secret là credential được Vault sinh ra theo yêu cầu, chỉ tồn tại trong thời gian ngắn (lease, ví dụ 1 giờ), hết hạn là tự động bị thu hồi.

Hãy so sánh hai cách cấp password database cho ứng dụng:

Ví dụ (minh họa): hệ thống thương mại điện tử của một SME có 10 microservice cùng kết nối database đơn hàng. Trước đây cả 10 service dùng chung một password cố định trong file config — một service bị xâm nhập là toàn bộ database gặp nguy. Sau khi dùng Vault Database engine, mỗi service xin một credential riêng có lease 2 giờ. Service A bị lộ credential? Kẻ xấu chỉ có tối đa 2 giờ, và credential đó không dùng được cho service khác.

Cách dùng cơ bản:

# Kích hoạt database engine và cấu hình kết nối
vault secrets enable database
vault write database/config/mysql-db \
  plugin_name=mysql-database-plugin \
  connection_url="{{username}}:{{password}}@tcp(db:3306)/" \
  allowed_roles="webapp-role"

# Định nghĩa role: mỗi credential sống 1h, tối đa gia hạn 24h
vault write database/roles/webapp-role \
  db_name=mysql-db \
  creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}'; GRANT SELECT,INSERT,UPDATE ON shop.* TO '{{name}}'@'%';" \
  default_ttl="1h" max_ttl="24h"

# Ứng dụng xin credential động
vault read database/creds/webapp-role

Kết quả trả về là một username/password ngẫu nhiên kèm lease_id và lease_duration. Ứng dụng dùng xong, Vault tự thu hồi — không còn password nào "sống" trong config để mà lộ.

6. Authentication methods: ai được phép mở két?

Vault không cấp secret cho "ai hỏi cũng đưa". Mọi client — con người hay ứng dụng — đều phải xác thực trước, và Vault hỗ trợ nhiều phương thức phù hợp từng đối tượng:

• Token: phương thức gốc, dùng cho quản trị và trường hợp đơn giản. Token luôn có thời hạn — không tồn tại khái niệm "token vĩnh cửu" trong thực hành tốt.
• Userpass / LDAP: cho con người đăng nhập bằng username/password hoặc tài khoản AD/LDAP của công ty.
• AppRole: dành cho ứng dụng và CI/CD. Mỗi service có một role_id (định danh, có thể công khai) và secret_id (bí mật, cần bảo vệ và luân chuyển). Đây là cách chuẩn để server backend lấy secret mà không hardcode.
• Kubernetes: pod trong cluster K8s tự xác thực bằng service account — không cần nhúng credential nào vào image.
• JWT/OIDC: tích hợp SSO (Google Workspace, Azure AD...) để nhân sự đăng nhập Vault bằng tài khoản công ty, kèm MFA.

Nguyên tắc vàng: mỗi workload một danh tính riêng. Đừng dùng chung một token "siêu quyền" cho cả team dev lẫn CI/CD. Token rò rỉ thì chỉ cần revoke token đó, thay vì đổi toàn bộ secret hệ thống.

# Ví dụ: tạo AppRole cho service thanh toán
vault auth enable approle
vault write auth/approle/role/payment-service \
  token_policies="payment-read" \
  token_ttl="1h" token_max_ttl="4h"

# Lấy role_id (công khai được) và secret_id (giữ kín, luân chuyển định kỳ)
vault read auth/approle/role/payment-service/role-id
vault write -f auth/approle/role/payment-service/secret-id

7. Policy: luật phân quyền chi tiết đến từng đường dẫn

Policy trong Vault là văn bản HCL quy định "ai được làm gì, ở đường dẫn nào". Mọi token đều gắn với một hoặc nhiều policy, và Vault từ chối mọi thứ không được cho phép rõ ràng.

# payment-read.hcl: service thanh toán chỉ được ĐỌC secret của chính nó
path "secret/data/payment/*" {
  capabilities = ["read"]
}
path "secret/metadata/payment/*" {
  capabilities = ["list"]
}
# Cấm tuyệt đối đọc secret của service khác
path "secret/data/hr/*" {
  capabilities = ["deny"]
}

Ba thực hành tốt khi viết policy cho team SME:

1. Tối thiểu đặc quyền (least privilege). Service nào chỉ đọc secret của chính nó. Developer chỉ đọc môi trường dev/staging, không chạm vào production. Người quản trị mới có quyền ghi.

2. Tách policy theo môi trường. webapp-dev-read, webapp-prod-read là hai policy khác nhau, gắn cho hai AppRole khác nhau. Lỡ token dev bị lộ cũng không ảnh hưởng production.

3. Dùng templating cho quy mô lớn. Khi team có hàng chục developer, thay vì viết policy cho từng người, dùng biến identity.entity.name để mỗi người chỉ thấy "ngăn" của mình — viết một lần, áp dụng cho tất cả.

Lưu ý nhỏ nhưng quan trọng với KV v2: đường dẫn policy phải trỏ vào secret/data/... (dữ liệu) chứ không phải secret/..., vì v2 tách metadata và dữ liệu thành hai API. Đây là lỗi cấu hình phổ biến khiến policy "không ăn".

8. Lộ trình triển khai Vault cho team nhỏ trong 1 ngày

Nghe Vault có vẻ "doanh nghiệp lớn", nhưng một team 3–10 người hoàn toàn có thể dựng Vault chạy production trong một ngày làm việc, theo lộ trình sau:

Buổi sáng — dựng và niêm phong két.

1. Chuẩn bị 1 Cloud Server/VPS riêng cho Vault (tối thiểu 2 vCPU, 4 GB RAM), chỉ mở port 8200 cho dải IP nội bộ/VPN.
2. Cài Vault binary, cấu hình Raft storage (không cần database ngoài), bật TLS.
3. Chạy vault operator init -key-shares=5 -key-threshold=3: thu 5 unseal key, chia cho 3 người giữ ở 3 nơi khác nhau (có thể in giấy cất két sắt thật).
4. Unseal bằng 3 key, đăng nhập bằng root token, rồi thu hồi root token ngay và tạo tài khoản admin riêng.

Buổi chiều — đưa secret vào két và nối ứng dụng.

1. Kích hoạt KV v2 tại secret/, nhập toàn bộ secret hiện tại theo cấu trúc secret/<service>/<môi-trường> (ví dụ secret/payment/prod).
2. Viết policy cho từng service theo nguyên tắc tối thiểu đặc quyền, tạo AppRole tương ứng.
3. Sửa code: thay vì đọc từ file config, ứng dụng gọi Vault API (hoặc dùng Vault Agent chạy sidecar tự render secret ra file/env cho app — app gần như không phải sửa code).
4. Bật audit log (ghi mọi lượt đọc secret: ai, khi nào, đọc gì) và chuyển log về hệ thống tập trung.
5. Xóa secret khỏi code, khỏi .env mẫu (chỉ giữ .env.example với tên biến trống), bật secret scanning (gitleaks) trong CI để chặn commit chứa secret mới.

Checklist cuối ngày: unseal key đã chia cho 3 người ☐ | root token đã thu hồi ☐ | TLS đã bật ☐ | audit log đã chảy ☐ | không còn secret trong repo ☐.

Ví dụ tích hợp nhanh bằng Vault Agent (không sửa code ứng dụng):

# agent-config.hcl: agent tự đăng nhập bằng AppRole và render secret ra file
auto_auth {
  method "approle" {
    config = {
      role_id_file_path   = "/etc/vault/role-id"
      secret_id_file_path = "/etc/vault/secret-id"
    }
  }
}
template {
  source      = "/etc/vault/app.ctmpl"   # chứa {{ with secret "secret/data/payment/prod" }}...
  destination = "/run/app/.env"          # file env app đọc như bình thường
}

Ứng dụng vẫn đọc /run/app/.env như cũ, nhưng file đó do Vault Agent sinh ra và tự cập nhật khi secret đổi — developer không bao giờ thấy password thật.

9. Luân chuyển secret và playbook khi secret bị lộ

Có Vault rồi chưa phải xong — giá trị lớn nhất nằm ở luân chuyển (rotation) định kỳ và khả năng thu hồi khẩn cấp khi có sự cố.

Luân chuyển định kỳ: đặt lịch đổi secret theo độ nhạy cảm — API key thanh toán 30 ngày, password database 90 ngày, token CI/CD 7 ngày. Với dynamic secret, việc này gần như tự động nhờ lease. Với secret tĩnh trên KV v2, dùng script cron gọi Vault API đổi giá trị; Vault Agent sẽ tự đẩy bản mới xuống ứng dụng.

Playbook 5 bước khi nghi ngờ secret bị lộ:

1. Thu hồi ngay (revoke): vault lease revoke -prefix database/creds/ để hủy toàn bộ credential động đang lưu hành; với token bị lộ, vault token revoke <token>. Kẻ xấu giữ key cũng thành "giấy lộn".
2. Xoay secret gốc: đổi password/API key thật trên hệ thống nguồn (database, Stripe, AWS...), cập nhật vào Vault.
3. Truy vết: mở audit log, lọc xem token/credential đó đã đọc những secret nào, từ IP nào, trong khoảng thời gian nào — đánh giá phạm vi ảnh hưởng.
4. Rà soát kênh lộ: kiểm tra Git history (gitleaks), log, chat nội bộ xem secret còn sót ở đâu; xóa và rotate tiếp nếu phát hiện bản sao.
5. Rút kinh nghiệm: siết policy (giảm TTL, thu hẹp quyền), bổ sung cảnh báo khi có lượt đọc bất thường.

Điểm mấu chốt: khi secret nằm trong Vault, bước 1 và 2 thực hiện trong vài phút bằng vài câu lệnh. Khi secret nằm rải rác trong code và chat, cùng công việc đó có thể mất vài ngày — và không bao giờ chắc đã hết.

10. Backup, unseal key và phục hồi thảm họa

Vault là "két sắt trung tâm" — két mà mất thì cả hệ thống đứng yên. Vì vậy kế hoạch dự phòng phải có từ ngày đầu.

Backup dữ liệu: với Raft storage backend, dùng lệnh vault operator raft snapshot save backup.snap để chụp snapshot định kỳ (ví dụ mỗi 6 giờ), mã hóa file snapshot và lưu ở vị trí khác với server Vault (object storage hoặc server backup riêng). Định kỳ diễn tập restore lên môi trường test — backup chưa từng restore thành công thì chưa thể gọi là backup.

Quản lý unseal key: đây là "chìa khóa của chìa khóa". 5 mảnh key chia cho ít nhất 3 người ở 3 nơi khác nhau; mỗi người lưu bằng hình thức khác nhau (một người dùng password manager, một người in giấy cất két, một người lưu USB mã hóa). Tuyệt đối không lưu cả 5 mảnh chung một chỗ, không gửi qua email/chat.

Kịch bản mất server: dựng Vault mới, restore snapshot, unseal bằng đủ key — hệ thống hoạt động trở lại với toàn bộ secret nguyên vẹn. Với Cloud Server của SunCloud, snapshot định kỳ của cả VM Vault là lớp bảo vệ bổ sung khi phần cứng gặp sự cố.

Kịch bản mất unseal key: đây là tình huống "mất là mất thật" — không có cơ chế "quên mật khẩu" cho unseal key. Phòng tránh bằng cách chia key cho đủ người ngay từ đầu, hoặc dùng auto-unseal bằng KMS cho hệ thống production quan trọng.

11. 7 sai lầm thường gặp khi dùng Vault

1. Để Vault chạy HTTP thay vì HTTPS. Secret truyền plaintext trên mạng nội bộ vẫn bị sniff được. Bật TLS là việc đầu tiên, không phải "để sau".

2. Dùng root token cho vận hành hàng ngày. Root token là "chìa khóa vạn năng" chỉ dùng lúc khởi tạo. Quên thu hồi nó thì mọi policy phân quyền đều vô nghĩa.

3. Policy quá rộng ("cho đọc hết cho tiện"). Tiện hôm nay, trả giá khi sự cố. Luôn bắt đầu từ deny-all rồi mở dần theo nhu cầu thực tế.

4. Token/AppRole không đặt TTL hoặc TTL quá dài. Token sống 30 ngày của một service tạm thời là 29 ngày rủi ro thừa. Đặt TTL ngắn nhất mà workload chịu được.

5. Quên audit log. Không bật audit thì khi sự cố xảy ra, bạn mù hoàn toàn: không biết ai đã đọc gì. Audit log là "camera an ninh" của két sắt.

6. Lưu unseal key chung một chỗ. Cả 5 mảnh trong một file Google Drive chia sẻ cho team thì cơ chế Shamir chỉ còn là hình thức.

7. Không diễn tập restore. Đến lúc server cháy mới phát hiện file snapshot 3 tháng nay bị lỗi. Hãy restore thử mỗi quý một lần — mất 30 phút nhưng cứu được cả công ty.

Kết luận

Hardcode password trong code là thói quen "tiện trước mắt, đắt về sau": secret lan rộng không kiểm soát, không thu hồi được khi lộ, và mỗi vụ rò rỉ đều có thể thành hóa đơn nghìn đô hoặc vụ việc pháp lý. Vault quản lý secret đảo ngược hoàn toàn cuộc chơi: mọi bí mật tập trung trong một két sắt mã hóa, ứng dụng mượn secret qua xác thực chặt chẽ, credential động tự hủy sau vài giờ, và mọi lượt truy cập đều được ghi lại.

Tin tốt là bạn không cần team hàng chục người mới dùng được Vault — một buổi làm việc là đủ để dựng két, chia khóa, đưa secret vào và nối ứng dụng đầu tiên. Bắt đầu từ KV v2 cho secret tĩnh, rồi nâng dần lên dynamic secret cho database khi team đã quen.

Nếu bạn đang tìm hạ tầng ổn định để đặt "két sắt" Vault — Cloud Server riêng biệt, snapshot định kỳ, uptime cam kết 99,98% cùng đội ngũ kỹ thuật hỗ trợ 24/7 — SunCloud là lựa chọn đáng cân nhắc cho team kỹ thuật Việt Nam. Liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn để được tư vấn cấu hình phù hợp.

Câu hỏi thường gặp

Vault có miễn phí không?

Có. HashiCorp Vault Community Edition là mã nguồn mở, miễn phí đầy đủ tính năng cốt lõi (KV, dynamic secrets, policy, audit). Bản Enterprise trả phí bổ sung các tính năng như replication đa cụm, HSM auto-unseal và namespace cho tập đoàn lớn — team SME hiếm khi cần tới.

Team chỉ 3 developer có nên dùng Vault không?

Nên, nếu hệ thống đã có dữ liệu khách hàng hoặc giao dịch thật. Chi phí dựng Vault (1 VPS + 1 ngày công) nhỏ hơn rất nhiều so với một vụ rò rỉ key. Team siêu nhỏ có thể bắt đầu đơn giản: chỉ dùng KV v2 + AppRole, chưa cần dynamic secrets ngay.

Vault khác gì file .env mã hóa hay AWS Secrets Manager?

File .env mã hóa vẫn là secret tĩnh, chia sẻ thủ công và khó thu hồi. AWS Secrets Manager tiện nhưng khóa bạn vào một cloud. Vault trung lập hạ tầng (chạy được on-premise, mọi cloud), mạnh nhất ở dynamic secrets, policy chi tiết và audit log toàn diện.

Dùng Vault rồi có cần đổi password định kỳ nữa không?

Với dynamic secrets thì gần như không — credential tự hết hạn theo lease. Với secret tĩnh (API key bên thứ ba), vẫn nên luân chuyển định kỳ 30–90 ngày; Vault giúp việc này dễ hơn nhờ versioning và Vault Agent tự cập nhật xuống ứng dụng.

Mất unseal key thì có lấy lại secret được không?

Không. Đây là thiết kế có chủ ý của cơ chế Shamir's Secret Sharing. Vì vậy phải chia key cho nhiều người ngay từ ngày đầu, lưu ở nhiều nơi khác nhau, hoặc dùng auto-unseal qua KMS cho hệ thống quan trọng.

Vault có làm chậm ứng dụng không?

Không đáng kể. Ứng dụng thường lấy secret một lần lúc khởi động (hoặc Vault Agent cache sẵn), không phải gọi Vault cho mỗi request. Độ trễ chỉ phát sinh ở thời điểm xin cấp secret, thường dưới vài chục mili-giây trong mạng nội bộ.