Mục lục

Lesson 6.2: RBAC vs ABAC

Phân biệt và áp dụng các mô hình phân quyền: Role-Based (RBAC) và Attribute-Based (ABAC) Access Control.

Security
Authorization
RBAC

Thời lượng: 20 phút
Level: Intermediate
Yêu cầu: Đã hiểu về Authentication và JWT.

Mục tiêu bài học

Sau bài học này, bạn sẽ:

  • Phân biệt được mô hình RBAC và ABAC.
  • Thiết kế được bảng phân quyền cơ bản cho ứng dụng.
  • Biết khi nào nên nâng cấp từ RBAC lên ABAC.

Nội dung chính

1. RBAC (Role-Based Access Control)

Đây là mô hình phổ biến nhất. Quyền hạn được gán cho Vai trò (Role), và người dùng được gán vào các vai trò đó.

  • Cấu trúc: User -> Roles -> Permissions.
  • Ví dụ:
    • Role ADVISOR có quyền view_reports.
    • Role MANAGER có quyền view_reports, edit_reports, delete_reports.

Ưu điểm: Dễ hiểu, dễ quản lý, phù hợp với 90% các ứng dụng thông thường. Nhược điểm: Khó xử lý các điều kiện linh hoạt (VD: Manager chỉ được xóa report của chính mình).

2. ABAC (Attribute-Based Access Control)

Quyền hạn được quyết định dựa trên các Thuộc tính (Attributes) của User, Tài nguyên và Môi trường.

  • Cấu trúc: Nếu (User.Attribute AND Resource.Attribute) THÌ Cho phép.
  • Ví dụ: Cho phép User xóa Report NẾU (User.id == Report.author_id) HOẶC (User.role == 'admin').

Ưu điểm: Cực kỳ linh hoạt, xử lý được các logic nghiệp vụ phức tạp. Nhược điểm: Phức tạp khi triển khai, hiệu năng có thể giảm do phải check nhiều điều kiện.

3. So sánh nhanh

Đặc điểmRBACABAC
Độ phức tạpThấpCao
Tính linh hoạtTrung bìnhRất cao
Khả năng mở rộngTốtRất tốt nhưng khó duy trì
Ví dụ điển hìnhAdmin, Staff, UserAWS IAM, Hệ thống Ngân hàng

Nguyên tắc then chốt

"Bắt đầu với RBAC, mở rộng bằng ABAC khi cần thiết."

Đừng làm phức tạp hóa hệ thống ngay từ đầu. Hãy dùng Role để phân nhóm lớn, sau đó kết hợp thêm các câu lệnh check Logic (giống ABAC) ở tầng Service để kiểm tra quyền sở hữu tài nguyên (Ownership).


Thực hành

Bài tập 1: Thiết kế hệ thống phân quyền cho E-learning

Bối cảnh: Hệ thống có các đối tượng: Student, Teacher, Admin. Tài nguyên: Course.

Yêu cầu:

  • Student: Được xem course đã mua.
  • Teacher: Được tạo course, sửa course của mình, xem danh sách học sinh của mình.
  • Admin: Được làm mọi thứ.

Hãy xác định: Cái nào dùng RBAC, cái nào dùng ABAC?

Xem đáp án mẫu
  • RBAC: Phân cấp Admin/Teacher/Student (Dùng để hiển thị Menu hoặc chặn các đầu mục lớn).
  • ABAC (Logic check):
    • Teacher chỉ sửa được Course của mình (course.teacher_id == user.id).
    • Student chỉ xem được Course đã mua (user.purchased_courses.includes(course.id)).

Tình huống thực tế

Scenario 1: Quyền truy cập theo thời gian (Time-based)

Bối cảnh: Nhân viên bảo trì chỉ được phép truy cập server vào khung giờ hành chính (8h - 17h).

Giải quyết: Đây là bài toán điển hình của ABAC. Role TECHNICIAN của nhân viên không đổi, nhưng hệ thống sẽ check thêm thuộc tính của Môi trường (Environment)current_time.

Nếu dùng RBAC thuần túy, bạn sẽ không thể làm được điều này trừ khi bạn viết thêm code logic riêng lẻ ở mọi API.


Câu hỏi phỏng vấn

Senior Level

  1. Q: Làm thế nào để lưu trữ Permissions trong JWT mà không làm nó quá lớn? A:
    • Thay vì lưu mảng string ['view_user', 'edit_user', ...], ta có thể lưu dưới dạng bitmask hoặc chỉ lưu Role ID, sau đó Backend Map Role ID đó với Cache (Redis) để lấy List Permissions tương ứng.
    • Một cách khác là phân cấp: Permissions = DOMAIN:ACTION.

Tóm tắt

Những điều cần nhớ

  • RBAC phù hợp cho phân nhóm người dùng.
  • ABAC phù hợp cho các quy tắc nghiệp vụ tinh vi.
  • Luôn kiểm tra quyền sở hữu (Ownership) ở tầng cuối cùng trước khi thay đổi dữ liệu.

Bước tiếp theo

Trong bài tiếp theo, bạn sẽ học về Lesson 6.3: API Key Management - Cách mở cửa API cho các đối tác và ứng dụng bên thứ ba một cách an toàn.

Tiếp tục bài 6.3 →

Quảng cáo
mdhorizontal