Server Secrets Management là cách quản vòng đời các thông tin có thể cấp quyền: SSH private key, database password, API token, service credential, TLS private key, CI/CD secret và environment variable. Mục tiêu không chỉ là “giấu secret”, mà là biết secret nào tồn tại, ai/tiến trình nào dùng, quyền của nó lớn đến đâu, cách rotate/revoke và evidence khi có incident.
OWASP hiện khuyến nghị secret phải có lifecycle rõ: creation, rotation, revocation và expiration; quyền đọc/cập nhật phải theo least privilege. Với web server, nguyên tắc thực dụng là không hardcode → không share rộng → không log plaintext → scope tối thiểu → rotate/revoke có kiểm thử.
Inventory và storage fundamentals
1. Lập inventory secret trước khi chọn công cụ
| Secret | Consumer | Blast radius |
|---|---|---|
| SSH private key | Admin/automation | Server access |
| Database credential | Application | Database/schema |
| API token | CI/CD/service | External platform |
| TLS private key | Web server | TLS identity |
| Environment secret | Runtime | App/service specific |
Mỗi secret cần owner, purpose, consumer, location, privilege, rotation method và incident contact.
2. Không hardcode secret vào source code
Secret trong repository dễ bị copy qua fork, backup, artifact hoặc commit history. Nếu secret từng commit, chỉ xóa dòng ở commit mới là chưa đủ; cần coi secret đã exposure và rotate/revoke theo risk.
3. Environment variable không phải secret vault
Environment variable tiện nhưng có thể xuất hiện trong process inspection, crash dump, debug output hoặc CI/CD log tùy hệ thống. OWASP không khuyến nghị dùng env nếu có phương án phù hợp hơn.
Nếu buộc phải dùng env:
- Inject ở runtime, không hardcode Dockerfile/ENV/ARG.
- Không echo toàn bộ environment vào log.
- Giới hạn process/user có thể đọc.
- Rotate cùng consumer.
SSH, service và privilege controls
4. SSH private key phải có owner rõ
OpenSSH yêu cầu private key chỉ readable bởi user sở hữu; client có thể bỏ qua key nếu file accessible bởi người khác. Mỗi human/automation nên có key riêng thay vì share một private key cho cả team. Authentication method, allowed remote users/groups và lockout-safe rollout của SSH thuộc SSH Hardening; bài này giữ owner cho lifecycle của key như một secret.
stat ~/.ssh/id_ed25519
ssh-keygen -lf ~/.ssh/id_ed25519.pubKhông dump private key để “audit”. Fingerprint/public key đủ cho inventory.
5. SSH key cũng cần rotation và revocation
Khi nhân sự/vendor rời hoặc key nghi bị lộ, xóa public key khỏi authorized_keys hoặc revoke theo cơ chế đang dùng. Rotation chỉ hoàn tất khi key cũ không còn được chấp nhận và automation mới đã test PASS.
6. Service credential nên tách theo application
Một database/API password dùng chung cho nhiều service làm tăng blast radius và khó biết source leak. Tạo credential riêng theo workload/environment khi platform hỗ trợ.
7. Scope quyền tối thiểu
Token chỉ cần đọc không nên có write/admin; deploy credential không cần quản billing; application DB user không cần account-management privilege. Secret value và authorization scope phải được review cùng nhau. Nếu vấn đề là identity có thể dùng sudo/service/automation path để đạt quyền cao hơn, chuyển sang Root, sudo & Least Privilege để xử lý privilege scope ở OS.
8. Secret file cần permission đúng
Nếu secret nằm trong file, owner/group/mode phải phù hợp và file không nằm trong public web root. Xem File Permission & Ownership.
9. Secret manager khi nào có giá trị?
Designated secret manager giúp centralize access control, audit, versioning và rotation. Tuy nhiên secret manager cũng là privileged system; credential để service truy cập secret manager phải được scope và bảo vệ.
10. Dynamic/short-lived secret giảm blast radius
Khi platform hỗ trợ, short-lived credential hoặc dynamic secret giảm thời gian secret bị đánh cắp còn giá trị. Không phải workload nào cũng phù hợp, nhưng đây là hướng tốt hơn static password tồn tại nhiều năm.
Rotation, pipelines và incident response
11. Rotation phải có transition plan
Đổi secret đột ngột có thể gây outage. Workflow an toàn:
- Tạo secret mới.
- Cấp quyền đúng.
- Cập nhật consumer.
- Test consumer bằng secret mới.
- Thu hồi secret cũ.
- Read-back log/error.
Nếu platform hỗ trợ nhiều credential đồng thời, dùng overlap ngắn để giảm downtime.
12. Không log plaintext secret
Không ghi Authorization header, private key, password, token hay full connection string vào log. Redaction/masking cần xảy ra trước log sink nếu có thể. Secret đã lọt log cần được rotate và xử lý retention/access của log. Event taxonomy, retention và cách giữ evidence mà không biến log thành secret leak thuộc Server Audit Logging.
13. CI/CD là một secret consumer
Pipeline maintainer thường có khả năng làm job in secret theo cách gián tiếp. Vì vậy CI/CD secret cần scope nhỏ, environment separation, protected branch/approval và audit.
14. Backup có thể chứa secret
Backup source/config/home directory có thể copy private key, env file và token. Backup access phải được coi nhạy cảm tương đương production. Restore cũng cần bảo đảm secret cũ/revoked không vô tình quay lại.
15. Secret incident response
Khi phát hiện secret bị lộ:
- Xác định secret và privilege.
- Contain access nếu cần.
- Rotate/revoke nhanh.
- Cập nhật consumer.
- Tìm nơi secret đã xuất hiện: code, log, artifact, backup.
- Review activity trong thời gian secret có thể bị sử dụng.
- Không chỉ xóa file rồi kết luận sạch.
16. Metadata cần giữ
Ít nhất: owner, purpose, consumer, created/rotated/revoked time, rotation method, expiry, privilege scope và incident contact. Không lưu plaintext secret trong inventory spreadsheet.
17. Validation sau rotation
- Consumer hoạt động với secret mới.
- Secret cũ bị từ chối.
- Không có error loop.
- Không log secret mới.
- Monitoring/backup/deploy path vẫn PASS.
Secrets Register mẫu
Đây là template metadata, không chứa secret value.
| Secret ID | Consumer | Scope | Storage | Owner | Rotation | Expiry |
|---|---|---|---|---|---|---|
| db-app-prod | Web runtime | App schema | Secret manager/file protected | App/Ops | Documented | Defined |
Checklist Server Secrets Management
- Inventory secret theo owner/purpose.
- Không hardcode plaintext trong code.
- Không share private key/team password.
- SSH private key permission chặt.
- Service credential tách theo workload.
- Privilege scope tối thiểu.
- Env var chỉ dùng khi phù hợp và không bị log.
- Secret file ngoài public root.
- Secret manager có access control/audit.
- Ưu tiên short-lived/dynamic secret khi phù hợp.
- Rotation có transition/test.
- Revocation được chứng minh.
- CI/CD secret được scope.
- Backup/restore không tái kích hoạt secret cũ.
- Incident runbook có owner.
Nguồn kỹ thuật tham khảo
Kết luận
Secret management tốt không chỉ là nơi lưu password. Nó là lifecycle có owner, scope, rotation, revocation, audit và incident response.
Trên web server, ưu tiên credential riêng theo workload, quyền tối thiểu, storage phù hợp, không log plaintext và rotation có validation. Nếu không thể thu hồi secret cũ một cách chắc chắn, quá trình rotation chưa hoàn tất.