Tweet
🔥 Bạn đang lưu trữ secrets cho ứng dụng của mình theo cách nào?
Nhiều DevOps vẫn đang dùng .env, mã hoá thủ công, thậm chí... hard-code trong source code! Nhưng liệu bạn có đang tạo ra “lỗ hổng bảo mật ngọt ngào” cho attacker?
Cùng điểm qua các chiến lược lưu trữ secrets phổ biến nhất – từ cổ điển tới hiện đại – và rủi ro đằng sau mỗi lựa chọn.
✅ 1. Lưu thẳng secrets vào code hoặc file môi trường (.env)
Ví dụ:
API_KEY = "sk_live_abc123xyz"
Hoặc:
export DB_PASSWORD="mypassword"
Ưu điểm:
Nhược điểm:
✅ 2. Lưu secrets trong database (với xác thực truy cập)
Thay vì ghi trực tiếp vào code, bạn lưu API key hoặc mật khẩu vào một bảng secrets trong DB và truy vấn khi cần.
Ưu điểm:
Nhược điểm:
✅ 3. Sử dụng dịch vụ lưu trữ secrets của cloud provider
Các dịch vụ như AWS Secrets Manager, Azure Key Vault, hoặc HashiCorp Vault.
Ưu điểm:
Nhược điểm:
✅ 4. Lưu secret đã mã hoá trong code
Bạn có thể mã hoá một secret, lưu chuỗi mã hoá trong code, và ứng dụng sẽ giải mã khi cần.
Ví dụ:
ENCRYPTED_API_KEY = "ad0e5a73bdb1e7f..." # Đã được AES mã hoá
Ưu điểm:
Nhược điểm:
💡 Thực tế
Một công ty fintech từng chia sẻ: họ dùng AWS Secrets Manager, nhưng API key truy cập dịch vụ lại nằm trong một container image được push lên Docker Hub công khai! 🤯 Dù họ nghĩ "đã mã hoá hết rồi", attacker chỉ cần image đó là đủ mở khoá mọi thứ.
🧠 Tổng kết
Không có giải pháp hoàn hảo. Mỗi mô hình đều giải quyết được một phần bài toán, nhưng cũng mở ra những rủi ro mới.
Vấn đề không chỉ là lưu secret ở đâu, mà là ai có quyền truy cập vào đâu và bạn kiểm soát điều đó tốt thế nào.
Bạn đang dùng chiến lược nào cho hệ thống của mình? Có đang rotate secret tự động chưa?
Hãy chia sẻ để cùng học hỏi! 👇
Nhiều DevOps vẫn đang dùng .env, mã hoá thủ công, thậm chí... hard-code trong source code! Nhưng liệu bạn có đang tạo ra “lỗ hổng bảo mật ngọt ngào” cho attacker?
Cùng điểm qua các chiến lược lưu trữ secrets phổ biến nhất – từ cổ điển tới hiện đại – và rủi ro đằng sau mỗi lựa chọn.
✅ 1. Lưu thẳng secrets vào code hoặc file môi trường (.env)
Ví dụ:
API_KEY = "sk_live_abc123xyz"
Hoặc:
export DB_PASSWORD="mypassword"
Ưu điểm:
- Quản lý đơn giản, không cần thêm hệ thống bên ngoài.
- File biến môi trường thường đã sẵn có trong quá trình deploy nên không cần tạo thêm.
Nhược điểm:
- Developer hoặc bất kỳ ai có quyền đọc source đều biết toàn bộ secret.
- Nếu push nhầm lên GitHub? Coi như bạn đang mời cả thế giới vào hệ thống của mình!
✅ 2. Lưu secrets trong database (với xác thực truy cập)
Thay vì ghi trực tiếp vào code, bạn lưu API key hoặc mật khẩu vào một bảng secrets trong DB và truy vấn khi cần.
Ưu điểm:
- Tập trung quản lý, dễ thay đổi hoặc rotate secret.
- Được dùng nhiều trong các hệ thống CI/CD tự xây dựng.
Nhược điểm:
- Vẫn cần credential để kết nối DB (tức là bạn lại phải... lưu một secret khác).
- Bạn đang chuyển vấn đề từ “lưu secret” sang “lưu credential truy cập DB”.
✅ 3. Sử dụng dịch vụ lưu trữ secrets của cloud provider
Các dịch vụ như AWS Secrets Manager, Azure Key Vault, hoặc HashiCorp Vault.
Ưu điểm:
- Hỗ trợ mã hóa, phân quyền truy cập, và audit logs.
- Có sẵn hàm mã hoá, giải mã, và tích hợp với ứng dụng thông qua API hoặc SDK.
Nhược điểm:
- Cần có API key hoặc token để truy cập → vấn đề vòng lặp lại quay về: lưu cái key truy cập dịch vụ này ở đâu?
✅ 4. Lưu secret đã mã hoá trong code
Bạn có thể mã hoá một secret, lưu chuỗi mã hoá trong code, và ứng dụng sẽ giải mã khi cần.
Ví dụ:
ENCRYPTED_API_KEY = "ad0e5a73bdb1e7f..." # Đã được AES mã hoá
Ưu điểm:
- Developer không thấy được secret thật.
- Dù lộ code thì attacker cũng không dễ lấy được secret.
Nhược điểm:
- Ứng dụng vẫn cần key giải mã để sử dụng → lại là một secret khác phải bảo vệ.
- Nếu file key bị lộ, toàn bộ mô hình bảo mật sụp đổ.
💡 Thực tế
Một công ty fintech từng chia sẻ: họ dùng AWS Secrets Manager, nhưng API key truy cập dịch vụ lại nằm trong một container image được push lên Docker Hub công khai! 🤯 Dù họ nghĩ "đã mã hoá hết rồi", attacker chỉ cần image đó là đủ mở khoá mọi thứ.
🧠 Tổng kết
Không có giải pháp hoàn hảo. Mỗi mô hình đều giải quyết được một phần bài toán, nhưng cũng mở ra những rủi ro mới.
Vấn đề không chỉ là lưu secret ở đâu, mà là ai có quyền truy cập vào đâu và bạn kiểm soát điều đó tốt thế nào.
Bạn đang dùng chiến lược nào cho hệ thống của mình? Có đang rotate secret tự động chưa?
Hãy chia sẻ để cùng học hỏi! 👇