Application Passwords WordPress: credential lifecycle

Bài này là credential-lifecycle owner cho Application Passwords WordPress. Dùng khi bạn cần inventory nhiều credential, gắn owner/purpose, quản lý secret storage, theo dõi sử dụng, rotate/revoke và access review theo thời gian. Nếu bạn chỉ cần triển khai Application Password cho một REST API/integration cụ thể, chuyển sang Application Passwords WordPress: triển khai an toàn cho REST API và integration.

Phạm vi của bài

Bài này trả lời câu hỏi “làm sao quản trị vòng đời Application Passwords như một tập credential kỹ thuật?”. Nó không phải hướng dẫn setup từng integration. Kết quả mong muốn là mỗi credential có owner, purpose, privilege phù hợp, trạng thái keep/rotate/revoke và ngày review.

Application Passwords trong WordPress là credential dành cho ứng dụng hoặc integration truy cập API thay cho việc dùng mật khẩu đăng nhập chính. Chúng hữu ích khi cần automation hoặc kết nối dịch vụ, nhưng phải được quản lý như secret riêng: có owner, purpose, scope và quy trình revoke.

Application Passwords dùng để làm gì?

Chúng thường được dùng cho REST API hoặc integration cần xác thực với một user WordPress. Điểm quan trọng là credential này tách biệt với mật khẩu đăng nhập tương tác và có thể revoke riêng.

Thiết kế credential cho integration an toàn

Không phải MFA và không thay thế mật khẩu user

Application Password không phải yếu tố MFA. Nó là credential riêng cho ứng dụng. Vì vậy không nên dùng nó như bằng chứng rằng account đã được “bảo vệ hai lớp”.

Nguyên tắc sử dụng an toàn

Tạo riêng cho từng integration.
Đặt tên mô tả đúng mục đích.
Dùng user có quyền tối thiểu cần thiết.
Không chia sẻ cùng một credential cho nhiều hệ thống.
Không lưu trong source code hoặc tài liệu công khai.
Revoke khi integration ngừng dùng.

Least Privilege cho Application Password

Application Password kế thừa quyền của user sở hữu nó. Nếu integration chỉ cần thao tác hạn chế, đừng gắn credential với Administrator chỉ vì dễ cấu hình. Xem Least Privilege WordPress.

Đừng dùng một credential cho nhiều integration

Mỗi integration nên có credential riêng để khi cần revoke hoặc điều tra, bạn biết ứng dụng nào bị ảnh hưởng. Dùng chung một Application Password cho nhiều hệ thống làm mất attribution và khiến rotation khó kiểm soát.

Inventory Application Password nên ghi gì?

Trường	Ví dụ	Mục đích
Owner	Team/nhân sự chịu trách nhiệm	Biết ai quyết định rotate/revoke
Purpose	Publish bài qua API	Biết credential còn cần không
User	Service identity phù hợp	Đánh giá privilege
Integration	Automation A	Tách attribution
Created/Reviewed	Ngày tạo, ngày review	Quản lý vòng đời
Status	Active/Rotate/Revoke	Ra quyết định rõ ràng

Secret storage

Lưu credential trong secret manager, biến môi trường hoặc cơ chế phù hợp với deployment. Tránh commit vào Git, gửi qua ticket công khai hoặc nhúng cứng trong plugin/theme.

Khi nào cần rotate?

Rotate khi credential có khả năng bị lộ, khi vendor/người vận hành rời dự án hoặc khi thay đổi integration quan trọng. Rotation phải đi kèm smoke test để tránh làm gián đoạn automation hợp lệ.

Rotation khác revoke thế nào?

Rotate là thay credential cũ bằng credential mới trong khi vẫn duy trì integration. Revoke là vô hiệu credential không còn cần hoặc đang nghi bị lộ. Nếu compromise đang được điều tra, ưu tiên containment và evidence thay vì chỉ đổi secret rồi bỏ qua nguyên nhân.

Monitoring và vòng đời Application Passwords

Monitoring

Nếu có log phù hợp, theo dõi API activity bất thường, user được sử dụng, thời điểm và endpoint. Một request lạ chưa đủ kết luận compromise nhưng có thể là tín hiệu để review credential. Với thay đổi account/credential cần dựng timeline, xem audit log WordPress.

Signal nào nên trigger review?

API request xuất hiện ngoài giờ hoặc pattern bình thường.
Integration truy cập endpoint ngoài business need.
Credential vẫn hoạt động sau khi vendor rời dự án.
Service user được nâng quyền bất thường.
Secret xuất hiện trong repository, log hoặc ticket.

Quy trình quản trị vòng đời

Xác định integration và owner.
Chọn user có quyền tối thiểu.
Tạo credential riêng.
Lưu secret an toàn.
Ghi purpose và ngày review.
Monitor hoạt động.
Ra decision keep/rotate/revoke/investigate.
Smoke test sau rotation.

Evidence pack cho credential review

Owner và purpose.
User/role/capability liên quan.
Integration và endpoint cần dùng.
Ngày tạo/review gần nhất.
Log sử dụng nếu có.
Decision: keep, rotate, revoke hoặc investigate.

Nguồn kỹ thuật

Kết luận

Application Passwords ở cấp owner này là bài toán credential lifecycle: inventory, owner, purpose, privilege, monitoring, rotation và revoke. Khi cần setup một integration REST cụ thể, chuyển sang implementation URL riêng để tránh hai bài cùng sở hữu cùng search task.