Bài này là governance owner cho WordPress Roles & Capabilities. Dùng khi bạn cần thiết kế mô hình phân quyền, Access Review, time-bound privilege, service account và quyết định keep/reduce/revoke. Nếu bạn đang cần một checklist áp dụng least privilege cho các account hiện có, chuyển sang Least Privilege WordPress: checklist role và capability.
Phạm vi của bài
Bài này trả lời câu hỏi “mô hình quyền của WordPress nên được thiết kế và review như thế nào?”. Nó sở hữu governance và Access Review, không phải checklist thao tác từng account. Kết quả mong muốn là mapping identity → business need → capability → decision → ngày review tiếp theo.
Least Privilege trong WordPress là nguyên tắc mỗi user, service account hoặc integration chỉ có đúng quyền cần thiết cho nhiệm vụ hiện tại. Mục tiêu là giảm impact nếu credential bị lộ, giảm thao tác nhầm và giúp audit rõ ai có thể làm gì.
Role và Capability trong WordPress
Role là nhóm quyền; capability là quyền cụ thể như chỉnh bài, quản lý user hoặc cập nhật plugin. Plugin có thể thêm role/capability riêng, nên không nên đánh giá chỉ dựa trên tên role. Khi viết hoặc review plugin, capability check cũng phải tách khỏi admin context; xem vì sao is_admin() không phải kiểm tra quyền trong WordPress.
Thiết kế Least Privilege theo nhiệm vụ thực tế
Vì sao quá nhiều Administrator là rủi ro?
Administrator thường có quyền rộng. Khi số account này tăng, attack surface identity cũng tăng, việc offboarding khó hơn và audit attribution kém hơn. Không cấp Administrator chỉ vì tiện.
Nguyên tắc phân quyền
| Nhu cầu | Hướng xử lý |
|---|---|
| Chỉ viết/chỉnh nội dung | Dùng role nội dung phù hợp |
| Quản lý user | Chỉ cấp capability cần thiết |
| Developer cần deploy | Tách quyền ứng dụng và hạ tầng nếu có thể |
| Integration/API | Dùng account riêng, scope tối thiểu |
| Emergency admin | Có owner và quy trình sử dụng riêng |
Least Privilege phải dựa trên nhiệm vụ, không dựa trên chức danh
Hai người có cùng chức danh không nhất thiết cần cùng capability. Một content manager có thể cần publish nhưng không cần cài plugin; một developer có thể cần deploy qua CI/CD nhưng không cần quyền quản lý user. Hãy map quyền với action thực tế thay vì chọn role cao hơn “cho chắc”.
Shared account có vấn đề gì?
Dùng chung một tài khoản khiến khó xác định actor trong audit log và khó revoke khi một thành viên rời dự án. Nếu workflow cho phép, mỗi người nên có identity riêng.
Custom role cần review kỹ
Một custom role có thể chứa capability mạnh hơn tên gọi gợi ý. Hãy review capability thực tế và map nó với business function. Xem thêm kiểm tra tài khoản, role và capability WordPress.
Capability quan trọng nên được phân nhóm
| Nhóm quyền | Ví dụ hành động | Risk khi cấp quá rộng |
|---|---|---|
| Content | Viết, sửa, publish bài | Thay đổi nội dung ngoài scope |
| User | Tạo, sửa, xóa user | Tăng privilege hoặc tạo persistence |
| Plugin/Theme | Cài, update, activate | Thay đổi code thực thi |
| Configuration | Thay đổi setting quan trọng | Ảnh hưởng security/business flow |
| API/Integration | Đọc/ghi qua REST hoặc automation | Credential compromise mở rộng impact |
Service account và integration
API, automation hoặc webhook nên dùng identity riêng nếu có thể, không mượn Administrator cá nhân. Ghi rõ owner, purpose, credential type và ngày review. Với REST API có thể tham khảo Application Passwords WordPress.
Time-bound privilege khi cần quyền tạm thời
Nếu một vendor hoặc developer chỉ cần quyền cao trong maintenance window, hãy xem đó là quyền tạm thời: có thời điểm bắt đầu, thời điểm revoke, owner và validation sau công việc. Quyền tạm nhưng không có expiration thường biến thành privilege tồn tại lâu dài.
Quy trình triển khai Least Privilege
- Inventory toàn bộ user và integration.
- Đánh dấu privileged account.
- Map role/capability với nhiệm vụ thật.
- Xác định account có quyền cao hơn business need.
- Hạ quyền account vượt nhu cầu.
- Tách shared account nếu khả thi.
- Bật MFA cho privileged identity theo policy.
- Test workflow sau thay đổi.
- Review lại định kỳ và khi offboarding.
Access review và vòng đời quyền
Access review nên có quyết định cuối cùng
Mỗi identity nên kết thúc review bằng một quyết định rõ: keep, reduce, revoke, investigate hoặc exception. Chỉ đánh dấu “đã review” nhưng không có decision khiến governance khó đo lường.
Không sửa quyền hàng loạt thiếu kiểm soát
Role change có thể phá workflow, automation hoặc approval chain. Trước khi hạ quyền cần snapshot, owner và rollback. Nếu account đáng ngờ trong incident, lưu evidence trước khi xóa.
Role drift và privilege creep
Privilege creep xảy ra khi user tích lũy quyền qua nhiều project hoặc thay đổi nhiệm vụ nhưng quyền cũ không được thu hồi. Baseline user/role và access review định kỳ giúp phát hiện tình trạng này.
Offboarding
Khi nhân sự hoặc vendor rời dự án, revoke account, session và credential liên quan. Nếu trước đó dùng shared account, cần đánh giá rotation cho credential dùng chung. Với quy trình end-to-end, xem bàn giao và thu hồi quyền quản trị WordPress.
Evidence pack cho access review
- Identity và owner.
- Role/capability thực tế.
- Business need.
- MFA/session state nếu thuộc scope.
- Decision keep/reduce/revoke/exception.
- Ngày review tiếp theo.
Validation
- Mọi privileged account có owner.
- Không còn Administrator không cần thiết.
- Custom role được map capability.
- Service account có purpose rõ.
- Quyền tạm thời có expiration/revoke.
- Offboarding có thể thực hiện mà không ảnh hưởng user khác.
Nguồn kỹ thuật
- WordPress — Roles and Capabilities
- WordPress — User Roles and Capabilities
- WordPress — Hardening WordPress
Kết luận
WordPress Roles & Capabilities ở cấp governance là bài toán thiết kế quyền, review và quyết định vòng đời. Khi cần thao tác áp dụng least privilege cho từng account hiện hữu, chuyển sang checklist implementation riêng để tránh hai URL cùng sở hữu một search task.