RBAC (Role-Based Access Control) là mô hình kiểm soát truy cập dựa trên vai trò: quyền được gắn với vai trò công việc, sau đó người dùng được gán vào vai trò phù hợp. Ví dụ, nhân viên bán hàng được cập nhật thông tin khách hàng, còn kế toán được xử lý hóa đơn theo nhiệm vụ.
RBAC giúp chuẩn hóa cấp và thu hồi quyền, giảm quyền thừa và rủi ro truy cập trái phép. Tuy nhiên, mô hình này không bảo đảm loại bỏ rò rỉ dữ liệu; hiệu quả còn phụ thuộc phạm vi dữ liệu, cách kiểm tra quyền và quản trị tài khoản.
RBAC hoạt động thế nào?
Cấu trúc cơ bản là Người dùng → Vai trò → Quyền. Khi nhiệm vụ thay đổi, doanh nghiệp điều chỉnh vai trò thay vì sửa từng quyền rời rạc cho mỗi tài khoản. Một người có thể có nhiều vai trò, nhưng cần kiểm tra tổng quyền thực tế và các xung đột phát sinh.
| Thành phần | Ý nghĩa | Ví dụ |
|---|---|---|
| Người dùng | Tài khoản thực hiện công việc | Nhân viên bán hàng A |
| Vai trò | Nhóm trách nhiệm được xác định | Nhân viên bán hàng |
| Quyền | Hành động được phép trên tài nguyên | Xem, tạo hoặc cập nhật hồ sơ khách hàng |
Tham khảo định nghĩa RBAC của NIST. Vai trò nên bám theo nhiệm vụ thực tế, không chỉ theo chức danh hoặc phòng ban.
Quyền thao tác khác phạm vi dữ liệu thế nào?
“Được xem khách hàng” và “được xem khách hàng nào” là hai điều phải xác định riêng. Gán vai trò Sale không tự bảo đảm nhân viên A chỉ thấy khách hàng được giao cho A. Hệ thống cần kiểm tra thêm phạm vi bản ghi, nhóm, chi nhánh hoặc tổ chức theo chính sách.
Ví dụ, A và B cùng có quyền xem hồ sơ khách hàng. Khi A yêu cầu mở hồ sơ được giao cho B, máy chủ phải kiểm tra quan hệ phân công trước khi trả dữ liệu. Việc chỉ lọc danh sách trên giao diện không đủ nếu chức năng xem chi tiết vẫn cho truy cập ngoài phạm vi.
Phạm vi này có thể được triển khai bằng vai trò có phạm vi hoặc kết hợp điều kiện theo thuộc tính/quan hệ. Cần ghi rõ điều kiện và kiểm thử, thay vì cho rằng tên vai trò đã diễn tả toàn bộ chính sách.
Mẫu ma trận phân quyền trong doanh nghiệp
Bảng dưới là mẫu minh họa để thảo luận với người phụ trách nghiệp vụ; cần điều chỉnh theo trách nhiệm thực tế. Quyền xuất dữ liệu, xóa, duyệt và cấp quyền nên được xét riêng.
| Vai trò | Được phép | Phạm vi và giới hạn |
|---|---|---|
| Nhân viên bán hàng | Xem và cập nhật khách hàng | Chỉ khách hàng được giao; không mặc định xuất toàn bộ CRM. |
| Trưởng nhóm bán hàng | Xem báo cáo và phân công khách hàng | Trong nhóm phụ trách; không tự có quyền truy cập nhóm khác. |
| Kế toán lập thanh toán | Tạo hồ sơ thanh toán, xem chứng từ liên quan | Không tự duyệt khoản thanh toán do mình lập. |
| Người duyệt thanh toán | Duyệt theo thẩm quyền | Kiểm tra hạn mức và tách người lập với người duyệt theo quy trình. |
| Quản trị hệ thống | Cấu hình và quản lý quyền được phê duyệt | Dùng tài khoản cá nhân, ghi nhật ký; quyền đọc dữ liệu nghiệp vụ phải được xét riêng. |
Ba nguyên tắc cần đưa vào thiết kế
Quyền tối thiểu: chỉ cấp những quyền cần cho công việc. Quyền đặc biệt nên có người phê duyệt, lý do và thời điểm hết hạn nếu là nhu cầu tạm thời. Xem nguyên tắc least privilege của NIST.
Tách nhiệm vụ: không để một người tự hoàn thành toàn bộ giao dịch nhạy cảm khi quy trình yêu cầu kiểm soát chéo. Việc đặt hai vai trò “người lập” và “người duyệt” chưa đủ nếu cùng một người được gán cả hai và vẫn tự duyệt được.
Mặc định từ chối và kiểm tra tại máy chủ: yêu cầu chưa được cho phép rõ ràng phải bị từ chối. Kiểm tra quyền ở mỗi yêu cầu, kể cả API, tải tệp và xuất dữ liệu. Ẩn nút chỉ hỗ trợ giao diện, không thay thế kiểm soát truy cập. Đây là các khuyến nghị trong OWASP Authorization Cheat Sheet.
Quy trình triển khai RBAC
1. Liệt kê hệ thống và thao tác nhạy cảm. Bắt đầu với một hệ thống như CRM, ERP hoặc ứng dụng nội bộ. Ghi rõ tài nguyên, người sử dụng và các thao tác xem, tạo, sửa, xóa, xuất, duyệt, cấp quyền.
2. Lập vai trò và phạm vi. Với mỗi vai trò, ghi nhiệm vụ, quyền cần thiết, phạm vi dữ liệu và người chịu trách nhiệm duyệt. Tránh vai trò “Nhân viên” quá rộng hoặc tạo một vai trò mới cho từng ngoại lệ nhỏ.
3. Rà quyền hiện có. Đối chiếu ma trận với quyền thực tế, kể cả quyền cấp trực tiếp, quyền kế thừa và quyền từ nhiều nhóm. Ghi ngoại lệ được duyệt; thu hồi quyền không còn cần thiết theo kế hoạch để tránh gián đoạn công việc.
4. Chạy thử và nghiệm thu. Dùng tài khoản thử nghiệm ở các vai trò khác nhau. Kiểm tra cả hành động được phép lẫn hành động phải bị chặn, sau đó mới mở rộng sang hệ thống khác.
5. Gắn phân quyền với vòng đời nhân sự. Khi nhận người mới, cấp đúng vai trò; khi chuyển vị trí, rà và gỡ quyền cũ trước khi quyền cộng dồn ngoài ý muốn; khi nghỉ việc, vô hiệu hóa truy cập theo quy trình. Kiểm tra cả phiên đăng nhập, mã truy cập và tài khoản liên quan để quyền đã thu hồi thực sự hết hiệu lực.
6. Rà soát theo rủi ro và sự kiện. Ưu tiên tài khoản quản trị, nhà cung cấp và quyền xuất/xóa dữ liệu. Không có chu kỳ cố định phù hợp mọi doanh nghiệp; rà thêm khi đổi nhiệm vụ, kết thúc dự án hoặc phát hiện bất thường.
Với tài khoản do đối tác nắm giữ, xem checklist quyền kiểm soát website. Kết hợp giám sát bảo mật để theo dõi thay đổi quyền và truy cập bất thường.
Bảng nghiệm thu phân quyền
Thực hiện các tình huống dưới đây trong môi trường thử nghiệm hoặc phạm vi được cho phép. Kết quả mong đợi phải dựa trên chính sách đã được doanh nghiệp duyệt.
| Tình huống | Kết quả mong đợi |
|---|---|
| A xem khách hàng được giao cho A | Cho phép đúng các trường thông tin thuộc quyền của A. |
| A yêu cầu hồ sơ của B, cùng vai trò nhưng khác phạm vi | Từ chối nếu chưa có quyền chia sẻ; không trả dữ liệu ngoài phạm vi. |
| Nhân viên không có quyền xuất dữ liệu gọi trực tiếp chức năng xuất | Máy chủ từ chối, kể cả khi bỏ qua giao diện. |
| Người lập tự duyệt giao dịch của mình | Bị chặn khi chính sách yêu cầu tách người lập và người duyệt. |
| Người dùng được gán thêm một vai trò | Tổng quyền được kiểm tra; không vô tình bỏ qua giới hạn hoặc tách nhiệm vụ. |
| Nhân viên chuyển bộ phận hoặc nghỉ việc | Quyền cũ và phiên/mã truy cập liên quan được xử lý đúng chính sách, không còn truy cập ngoài thẩm quyền. |
| Chức năng mới chưa có quy tắc cấp quyền | Mặc định từ chối cho đến khi quyền được thiết kế và phê duyệt. |
Lưu tài khoản thử, vai trò, phạm vi, kết quả thực tế và người nghiệm thu. Chạy lại các kiểm tra liên quan khi sửa vai trò, thêm API hoặc đổi logic nghiệp vụ.
Khi nào cần kết hợp ABAC hoặc ReBAC?
RBAC phù hợp khi quyền bám tương đối ổn định theo công việc. Nếu phải tạo rất nhiều vai trò để biểu diễn từng khách hàng, tài liệu hoặc ngữ cảnh, nên xem xét mô hình bổ sung.
| Mô hình | Căn cứ quyết định | Ví dụ |
|---|---|---|
| RBAC | Vai trò | Kế toán được lập hồ sơ thanh toán. |
| ABAC | Thuộc tính người dùng, tài nguyên, hành động và môi trường | Cho phép truy cập khi thuộc đúng đơn vị và đáp ứng điều kiện thiết bị theo chính sách. |
| ReBAC | Quan hệ với tài nguyên | Người được giao hoặc được chia sẻ mới được xem hồ sơ. |
Các mô hình có thể kết hợp. Mục tiêu là diễn tả đúng chính sách và thực thi nhất quán, không phải thay RBAC chỉ vì mô hình khác linh hoạt hơn. Tham khảo NIST SP 800-162 về ABAC.
Câu hỏi thường gặp
RBAC có ngăn hoàn toàn rò rỉ dữ liệu không?
Không. Người có quyền hợp lệ vẫn có thể thao tác sai hoặc làm lộ dữ liệu. Cần kết hợp quản trị tài khoản, xác thực, nhật ký và các biện pháp bảo vệ phù hợp.
Có MFA rồi còn cần phân quyền không?
Có. MFA hỗ trợ xác minh danh tính; phân quyền quyết định danh tính đó được làm gì và với dữ liệu nào.
RBAC khác IAM và Zero Trust thế nào?
RBAC là một mô hình phân quyền. IAM bao quát quản lý danh tính và truy cập; Zero Trust là cách tiếp cận kiến trúc rộng hơn. Triển khai RBAC không tự đồng nghĩa đã triển khai đầy đủ hai phạm vi này.
Doanh nghiệp nhỏ có cần nhiều vai trò không?
Không. Bắt đầu bằng các nhiệm vụ thực sự khác nhau và quyền nhạy cảm cần tách. Mô hình ít vai trò nhưng rõ phạm vi, có kiểm thử và thu hồi quyền đúng lúc thường dễ vận hành hơn.
Đ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ả.