Giải quyết bài toán Sơ đồ tổ chức & Ma trận Phân quyền động (Dynamic RBAC) trong kiến trúc SaaS

Hồi mới vào nghề, khi làm tính năng phân quyền, đa số anh em Dev chúng ta thường áp dụng một công thức quen thuộc: Fix cứng các Role như Admin, Staff, User. Viết vài cái if/else hoặc gắn Guard/Authorize cứng vào các Route là xong.

Tuy nhiên, khi bạn đảm nhận thiết kế kiến trúc cho một hệ thống SaaS (Software as a Service) phục vụ các doanh nghiệp lớn (B2B), bài toán không còn đơn giản như vậy.

Hãy tưởng tượng khách hàng của bạn là một tập đoàn có 5 chi nhánh, 20 phòng ban. Ông Giám đốc yêu cầu: "Cho nhân viên Nguyễn Văn A quyền Xóa hóa đơn nhưng chỉ được thực hiện ở Chi nhánh Gò Vấp, còn Chi nhánh Tân Bình thì chỉ được Xem. À, tiện thể khóa quyền Xuất file Excel của toàn bộ Kế toán thực tập nhé!"

Nếu dùng cách fix cứng Role cũ, kiến trúc của bạn sẽ vỡ vụn ngay lập tức. Để giải quyết triệt để bài toán này, chúng ta cần một kiến trúc Dynamic RBAC (Role-Based Access Control) kết hợp Sơ đồ tổ chức đa cấp. Dưới đây là cách tôi đã tiếp cận và giải quyết.

1. Xây dựng Sơ đồ tổ chức dạng Tree-view (Đệ quy)

Trước khi phân quyền, hệ thống phải hiểu được người dùng đang đứng ở đâu trong công ty.

Thay vì tạo các bảng phẳng rời rạc, chúng ta thiết kế một cấu trúc bảng tự trỏ (Self-referencing) trong Database. Một Node (Đơn vị) có thể là Công ty mẹ, Chi nhánh, hoặc Phòng ban. Mỗi Node sẽ có một ParentId trỏ về Node cha của nó.

• Ưu điểm: Hệ thống có thể mở rộng N cấp độ đệ quy mà không giới hạn.
• Truy vấn: Khi dùng Entity Framework Core trên .NET 8, kết hợp với các CTE (Common Table Expressions) trong SQL Server, truy xuất toàn bộ cây tổ chức chỉ mất vài mili-giây.

2. Thiết kế Ma trận Phân quyền Động (Dynamic RBAC)

Lúc này, Role không còn là một cái tên vô tri nữa, mà nó là một Ma trận (Matrix). Chúng ta chia nhỏ quyền hạn thành 5 action cơ bản cho mọi module: Xem (Read), Thêm (Create), Sửa (Update), Xóa (Delete), và Xuất file (Export).

Khi Quản trị viên của khách hàng cấp quyền cho một Vai trò (VD: Quản lý chi nhánh), họ sẽ nhìn thấy một bảng ma trận giao diện trực quan. Họ tick vào ô nào, database sẽ lưu mapping ô đó. Backend lúc này chỉ việc check: "User này có chứa Action Code SYS.INVOICE.DELETE không?", bất chấp họ mang Role tên là gì.

3. Tính năng "Trùm cuối": Ghi đè quyền ngoại lệ (User Override)

Đây là tính năng tạo nên sự khác biệt của một hệ thống Enterprise. Sẽ luôn có những cá nhân xuất sắc được giao phó trọng trách "vượt rào".

Thay vì phải tạo ra một Role mới (VD: KeToan_DacBiet_DuocPhepXoa) chỉ dành riêng cho 1 người, hệ thống cung cấp cơ chế Ghi đè (Override). Tức là, User A vẫn mang Role "Kế toán" (bị cấm Xóa), nhưng ta cấp riêng lẻ quyền Xóa vào trực tiếp User A.

Logic ở Backend sẽ đánh giá theo thứ tự ưu tiên: Quyền Ghi đè (User Override) > Quyền của Vai trò (Role). #### Kết luận Việc xây dựng từ đầu một hệ thống đáp ứng đủ bộ 3: Multi-tenant (Đa khách hàng) + Sơ đồ tổ chức đệ quy + Ma trận phân quyền động thực sự tốn rất nhiều chất xám và thời gian (thường mất từ 2-3 tháng đối với một team Dev cứng).

💡 Bạn đang cần xây dựng một hệ thống SaaS hoặc Web App doanh nghiệp? Thay vì tốn hàng tháng trời loay hoay với logic nền tảng phức tạp, bạn có thể rút ngắn thời gian dự án bằng bộ Source Code kiến trúc Core chuẩn mực do chính tôi thiết kế và đóng gói. Hệ thống được build bằng .NET 8, C# (EF Core) và Next.js-React

👉 Xem Demo & Đặt mua Source Code NhatSoft SaaS Core Engine tại đây 📞 Cần tư vấn sâu hơn về kiến trúc kỹ thuật? Kết nối trực tiếp Zalo với tôi: 0907.011.886 ---