Secrets & API Key Management cho website là cách quản lý những “chìa khóa kỹ thuật” mà website dùng để kết nối với dịch vụ khác: API key, token, webhook secret, SMTP credential, payment key, database credential và WordPress Application Password.
Nói dễ hiểu: nếu mật khẩu đăng nhập là chìa khóa của một người, API key và secret thường là chìa khóa mà hệ thống dùng để nói chuyện với hệ thống khác. Nếu những chìa khóa này bị lộ, người khác có thể gửi email, gọi API, truy cập dữ liệu hoặc sử dụng dịch vụ dưới danh nghĩa website.
Secret là gì và khác mật khẩu người dùng thế nào?
Mật khẩu người dùng phục vụ việc con người đăng nhập. Secret thường được dùng tự động giữa website và một dịch vụ khác, ví dụ website gửi email qua SMTP, gọi CRM, nhận webhook thanh toán hoặc truy cập storage.
Vì vậy secret không nên phụ thuộc vào một cá nhân duy nhất và cũng không nên tồn tại vô thời hạn mà không ai biết nó đang dùng ở đâu.
Website thường có những secret nào?
- API key hoặc token của CRM, ERP, email, bản đồ, AI hoặc analytics;
- SMTP username/password hoặc token;
- payment gateway key và secret;
- webhook signing secret;
- database credential;
- cloud, CDN hoặc storage credential;
- WordPress Application Password;
- deployment hoặc repository token.
Ví dụ thực tế: đổi nhân sự nhưng quên thu hồi API key
Một agency cài integration cho website bằng API key do họ tạo. Sau khi hợp đồng kết thúc, tài khoản WordPress của agency đã bị xóa nhưng API key vẫn còn hiệu lực. Nếu không có danh sách secret và cách thu hồi, doanh nghiệp có thể tưởng đã offboarding xong trong khi một “chìa khóa kỹ thuật” vẫn tồn tại.
Mỗi secret tối thiểu cần biết những gì?
| Cần biết | Ý nghĩa |
|---|---|
| Tên | Tên nhận diện, không ghi giá trị bí mật vào danh sách công khai |
| Mục đích | Secret phục vụ integration hoặc chức năng nào |
| Người/đội chịu trách nhiệm | Ai phải xử lý khi cần đổi hoặc thu hồi |
| Quyền | Secret được phép làm gì |
| Môi trường | Production, staging hay development |
| Nơi lưu | Được quản lý ở đâu |
| Ngày tạo/đổi gần nhất | Giúp theo dõi vòng đời |
| Cách thu hồi | Làm sao vô hiệu hóa khi không còn dùng hoặc nghi bị lộ |
Không để secret trong nơi dễ bị lộ
API key không nên được hard-code vào source code public, gửi qua chat không kiểm soát hoặc lưu trong tài liệu mà quá nhiều người có thể đọc. Nếu một key từng bị commit lên repository công khai hoặc gửi nhầm, nên coi nó có nguy cơ đã bị lộ và đánh giá việc đổi hoặc thu hồi.
Google cũng khuyến nghị không nhúng API key trực tiếp vào code hoặc đặt trong source tree khi có nguy cơ bị public. Mục tiêu là giảm khả năng credential vô tình xuất hiện trong source control.
Chỉ cấp đúng quyền cần thiết
Nếu dịch vụ cho phép tạo key chỉ đọc thay vì toàn quyền, hoặc tách key theo từng ứng dụng, nên chọn phạm vi nhỏ nhất đủ dùng. Khi một key bị lộ, quyền càng hẹp thì thiệt hại tiềm năng càng nhỏ.
Production và staging nên tách secret
Staging thường có nhiều developer hoặc vendor truy cập hơn production. Nếu hai môi trường dùng chung payment key, SMTP hoặc webhook secret, một thử nghiệm sai trên staging có thể tác động dữ liệu thật.
Khi nhà cung cấp hỗ trợ sandbox hoặc test credential, nên ưu tiên dùng riêng cho staging.
Khi nào cần đổi hoặc thu hồi secret?
- nhân sự hoặc vendor rời dự án;
- secret bị gửi nhầm, commit lên repository hoặc nghi đã lộ;
- xảy ra sự cố bảo mật;
- integration được thay thế;
- quyền hoặc người chịu trách nhiệm thay đổi;
- nhà cung cấp yêu cầu đổi;
- chính sách nội bộ yêu cầu với secret quan trọng.
Không có một chu kỳ cố định phù hợp cho mọi API key. Điều quan trọng hơn là biết rõ khi nào phải đổi và có khả năng thu hồi nhanh khi cần.
Đổi secret phải kiểm tra nơi đang sử dụng
Thay một API key mà quên cron job, webhook hoặc plugin đang dùng key cũ có thể làm website lỗi. Trước khi đổi, hãy xác định tất cả nơi đang sử dụng secret, cập nhật theo thứ tự phù hợp, kiểm tra hoạt động rồi mới thu hồi key cũ.
Với production, nên áp dụng Change Management nếu thay đổi có thể ảnh hưởng chức năng quan trọng.
WordPress Application Password dùng khi nào?
WordPress Application Password cho phép tạo credential riêng cho một ứng dụng hoặc integration và có thể thu hồi độc lập với mật khẩu đăng nhập chính. Cách này phù hợp hơn việc đưa mật khẩu tài khoản WordPress chính cho script hoặc ứng dụng bên ngoài.
Nên đặt tên theo integration và thu hồi khi ứng dụng không còn sử dụng.
Checklist Secrets & API Key Management
- Biết website đang có những API key, token và Application Password quan trọng nào.
- Mỗi secret có mục đích và người chịu trách nhiệm.
- Không lưu giá trị secret trong danh sách tài sản công khai.
- Không dùng chung một key cho nhiều môi trường nếu có thể tách.
- Chỉ cấp quyền vừa đủ.
- Biết cách thu hồi từng secret.
- Có trigger rõ ràng để đổi khi nhân sự/vendor rời dự án hoặc nghi bị lộ.
- Offboarding kiểm tra cả API key và token, không chỉ WordPress user.
Kết luận
Secrets & API Key Management là việc biết website đang dùng những “chìa khóa kỹ thuật” nào, ai chịu trách nhiệm và cách vô hiệu hóa chúng khi cần. Quản lý tốt giúp giảm tình trạng chia sẻ credential, key bị quên và quyền tồn tại lâu hơn nhu cầu thực tế.
Đây là một phần của Website Security Operations và liên quan trực tiếp đến quản lý quyền admin WordPress cũng như quyền kiểm soát website.
Nguồn tham khảo: WordPress Application Passwords, OWASP Secrets Management Cheat Sheet và hướng dẫn bảo vệ API key của Google.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.