Role-based access control

Chia sẻ kiến thức Hits: 804

{jcomments on}

Author: Trần Hà Tuấn Kiệt

Published date: 12/03/2022

Lời mở đầu

Hạ tầng thông tin ngày càng đóng vai trò quan trọng trong một xã hội số. Đi kèm với mở rộng quy mô, đảm bảo an ninh cho hệ thống thông tin được đặc biệt xem trọng. Quản lí bảo mật cho hệ thống thông tin lớn thường phức tạp; tuy nhiên, công việc có thể đơn giản hóa bằng các mô hình dựa trên chính sách Role-based Access Control.

Sơ nét về Access Control

Trong lĩnh vực bảo mật thông tin, Access control - kiểm soát truy cập - là phương pháp hỗ trợ hệ thống thông tin giới hạn mức độ tiếp cận tài nguyên (resource) mà người dùng hoặc hệ thống khác bất kì thao tác trên một hệ thống. Access control tập trung vào các quyền hạn (permissions) trên mỗi tài nguyên, bao gồm thời điểm và địa điểm mà chủ thể (người dùng hoặc hệ thống) được phép tiếp cận và cách mà chủ thể được phép sử dụng (operations) tài nguyên trên.

Access control liên kết chặt chẽ với các công nghệ, các chương trình và các chính sách bảo mật trong một hệ thống thông tin. Hình 1 thể hiện một ngữ cảnh mà các công cụ bảo mật tương tác với nhau, bên cạnh access control còn có:

Hình 1: Access control và các dịch vụ bảo mật khác tương tác trong hệ thống

Access control làm cầu nối trung gian giữa người dùng (hoặc các tiến trình thực thi như người dùng) với tài nguyên của hệ thống, ví dụ các ứng dụng, hệ điều hành, tường lửa, routers, các file và database. Bằng cách này, access control ngăn chặn các hoạt động có thể tạo ra lỗ hổng bảo mật.

Các chính sách (Policy) của Access control đóng vai trò như một bản hướng dẫn chi tiết các truy cập được kiểm soát như thế nào, trong trường hợp nào, bởi đối tượng nào. Các chính sách của Access Control gồm những dạng sau:

Discretionary access control (DAC): Controls access dựa trên danh tính của người dùng và các điều khoản mà chính người dùng đó được phép (hoặc không được phép) truy cập.

Mandatory access control (MAC): Controls access dựa trên việc so sánh các nhãn (security labels - dùng để đánh dấu yêu cầu bảo mật của một tài nguyên hệ thống) với các giấy phép (security clearances - dùng để xác định đối tượng được phép truy cập loại tài nguyên phù hợp với mức độ bảo mật).

Role-based access control (RBAC): Control access dựa trên các vai (roles). Các phần sau sẽ làm rõ nội dung của chính sách này.

Nền tảng của RBAC

RBAC hiện thực cách quản lý truy cập thông qua các vai (roles). Mỗi role được gán với một tập hợp các quyền hạn và các quyền hạn được xây dựng từ các tài nguyên và các hành vi thực hiện trên chính tài nguyên đó. Mỗi chủ thể đã được đăng kí trong hệ thống sẽ được gán một hoặc nhiều role. Các role có thể được cấp thêm những quyền hạn mới và các quyền hạn mới có thể bị thu hồi từ các role khi cần.

Hình 2: Hình 2: ERD mô tả chính sách RBAC

Mô hình nền tảng của RBAC được xây dựng trên những yêu cầu tối thiểu đã được đề cập ở trên. Ba đối tượng chính của mô hình gồm: Users, Roles và Permissions

Giữa Users và Roles hình thành một quan hệ, được gọi là User Assignment, tương tự quan hệ giữa Roles và Permissions gọi là Permission Assignment

Hình 3: Các đối tượng chính của mô hình nền tảng trên chính sách RBAC

Ngoài ba đối tượng trên, đối tượng Session (phiên làm việc) được thiết lập cho mô hình yêu cầu một user đảm nhận nhiều role. Một user có thể có nhiều Session mở đồng thời, mỗi Session như vậy có thể kết hợp với nhiều Roles khác nhau thuộc về user.

Phạm vi áp dụng của RBAC trải rộng từ hệ cơ sở dữ liệu (databases), các ứng dụng (applications) cho đến các môi trường (environments) làm việc và phát triển.

Lợi ích khi hiện thực RBAC trong hệ thống

Mục đích chính của RBAC là tối đa hóa việc quản lý. Nhiều hệ thống Access control trong thương mại đã chọn giải pháp tích hợp các role để giải quyết bài toán quản trị. Vai trò “điều hành” (operator) có thể truy cập đến tất cả tài nguyên, nhưng không thay đổi được các quyền hạn truy cập. Vai trò “giám sát” (auditor) chỉ có thể truy cập lịch sử hoạt động (audit trail). Cách sử dụng role như trên còn được tìm thấy ở các phiên bản hệ điều hành gần đây, chẳng hạn như họ Windows NT.

Thành phần role giúp access control trở nên linh hoạt hơn (về mặt ngữ nghĩa) trong việc quản trị ở bất kì tổ chức. Một role có thể đại diện cho chuyên ngành của người dùng, như bác sĩ và dược sĩ trong hệ thống quản lý bệnh viện. Một role còn thể hiện quyền lực và trách nhiệm, chẳng hạn chức vụ giám sát dự án. Việc giao role cho một người dùng không yêu cầu kĩ năng về mặt kĩ thuật mà thiên về quản trị, vì thế công việc trở nên đơn giản hơn.

RBAC không giới hạn trong một khung tiêu chuẩn nhất định. Điều này cho phép RBAC tùy biến để thích ứng với tầm nhìn của bất kì tổ chức nào. Các biến thể của RBAC đã có thể hình thành các ràng buộc giữa các role, cũng như giữa quyền hạn với role và giữa người dùng với role. Chẳng hạn, hai role được hình thành với ràng buộc xung khắc với nhau, khi đó một user không được có cả hai role cùng lúc. Ngoài ra, các role có thể hình thành quan hệ kế thừa, khi mà một role kế thừa quyền hạn cho một role khác. Các quan hệ hình thành trên cơ sở giữa 2 role như trên giúp siết chặt chính sách bảo mật liên quan đến phân chia trách nhiệm và ủy thác quyền lực.

Các mô hình xây dựng từ RBAC

Như đã đề cập ở trên, RBAC không giới hạn trong một khung tiêu chuẩn nhất định. Dựa trên mô hình nền tảng, các mô hình dưới đây bổ sung đặc tính trong chính sách RBAC

Mô hình Role phân cấp (Role hierarchies):

Mô hình Role phân cấp được áp dụng phổ biến trong các hệ thống hỗ trợ role. Phân cấp là hình thức tổ chức role nhằm phản ánh chiều hướng quyền lực và trách nhiệm trong một tổ chức. Chức vụ quyền lực hơn sẽ xuất hiện ở phần trên của sơ đồ, và chức vụ ít quyền lực hơn xuất hiện ở dưới cùng của sơ đồ. Về mặt toán học, sự phân tầng được sắp theo thứ tự bộ phận (partially orders).

Hình 4: Ứng dụng Salesforce sử dụng mô hình Role phân cấp để quản lí nhân sự trong hệ thống của tổ chức. Nguồn Understanding Roles in Salesforce | APPSeCONNECT

Khi hiện thực, role bậc cao sẽ kế thừa permission của role bậc thấp hơn, đồng nghĩa với việc, role có nhiều quyền lực hơn đã bao gồm permission của một hoặc nhiều role bậc thấp liền kề nó. Vì vậy, chiều hướng kế thừa sẽ đi từ thấp lên cao, trái ngược với chiều hướng quyền lực (đi từ cao xuống thấp). Với mô hình phân cấp Role trên hình 5, tất cả người dùng trong hệ thống đều là thành viên của dự án, do đó, role họ nhận được hoặc là Project Member, hoặc kế thừa permission từ Project Member. Cả Test Engineer (kĩ sư kiểm định) và Programmer (Lập trình viên) đều kế thừa từ Project Member, nhưng mỗi role còn được gán cho những permission khác. Hình 5 còn mô tả đa kế thừa, tại đó Project Supervisor (Người giám sát dự án) kế thừa từ Test Engineer và Programmer.

Hình 5: Một ví dụ cho việc phân cấp role

Mô hình Ràng buộc (Constraints)

Bản thân chính sách RBAC không đề cập đến điều kiện ràng buộc cho từng thực thể. Dựa trên mô hình nền tảng, mô hình Ràng buộc sẽ thêm vào chính sách các điều kiện đến bất kì đối tượng (Users, Roles, Permissions) và bất kì quan hệ (User Assignment, Permission Assignment).

Hình 6: Ràng buộc đến các thực thể trong RBAC

Các ràng buộc là cơ chế cực kì hữu hiệu khi tích hợp vào RBAC. Ràng buộc giúp chính sách trở nên tường minh hơn. Một ví dụ thường gặp là những role được chỉ định xung khắc với nhau, chẳng hạn một cá nhân thực hiện quyết toán lương thưởng không thể là người soạn dự thảo lương thưởng. Trong trường hợp này, người dùng không được phép sở hữu cả hai role vì điều này chắc chắn sẽ dẫn đến hành vi trục lợi. Như vậy, ràng buộc đã giúp hệ thống bảo đảm một nguyên tắc cơ bản: phân chia trách nhiệm (Separation of duties). Nguyên tắc này yêu cầu không một người dùng nào được giao đủ quyền để lạm dụng hệ thống.

Ngoài ra, cơ chế ràng buộc cũng có thể bắt gặp ở hình thức giới hạn số lượng user trong một role, hoặc ở hình thức cần có role tiên quyết để được đảm nhận một role.

Mô hình Kết hợp (Consolidated model)

Mô hình Kết hợp là sự tổng hoà giữa mô hình Role phân cấp và mô hình Ràng buộc. Kết hợp hai mô hình trong một vừa đem lại thế mạnh của hai ý tưởng trên, tuy nhiên, vừa phát sinh một số vấn đề không mong muốn.

Trong mô hình này, ràng buộc có thể áp dụng lên việc phân cấp Role. Các ràng buộc có thể giới hạn số loại role bậc cao hoặc thấp gần nhất mà role hiện tại được phép có. Ngoài ra, hai hoặc nhiều role có thể ràng buộc bằng điều kiện không được có chung một role có bậc cao hoặc thấp gần nhất.

Tuy nhiên, sự tương tác giữa các role phân cấp gặp trở ngại không nhỏ bởi chính ràng buộc. Với ý định sử dụng mô hình kết hợp và cách tổ chức role như hình 5, giả sử Test Engineer và Programmer là hai role xung khắc với nhau (được giới thiệu ở phần Mô hình Ràng buộc). Project Supervisor vi phạm ràng buộc xung khắc do kế thừa từ hai role không được phép đi cùng với nhau . Do đó, mô hình khi được xây dựng phải đảm bảo sự phân cấp và ràng buộc không gây ra mâu thuẫn cho hệ thống.

Kết luận

Các mô hình xây dựng từ chính sách RBAC trải rộng từ đơn giản đến phức tạp. Các mô hình này là nguồn tham khảo tin cậy cho việc nghiên cứu và phát triển các mô hình và hệ thống phù hợp với bất kì cá nhân hoặc tổ chức. Khía cạnh về quản trị của chính sách RBAC không chỉ dừng lại ở mô hình Role phân cấp và Ràng buộc, mà còn cần được nghiên cứu nhiều hơn. Các vấn đề phát sinh liên quan đến RBAC thường đan xen với nhau, đặt ra yêu cầu cho một giải pháp tối ưu hơn.

Tài liệu tham khảo

[1] Sandhu, R. S., & Samarati, P. (1994). Access control: principle and practice. IEEE Communications Magazine, 32(9), 40–48. doi:10.1109/35.312842

[2] Sandhu, R. S., Coyne, E. J., Feinstein, H. L., & Youman, C. E. (1996). Role-based access control models. Computer, 29(2), 38–47. doi:10.1109/2.485845

[3] Understanding Roles in Salesforce, APPSeCONNECT, www.appseconnect.com/roles-in-salesforce/

Print

Related Articles

BIẾN ĐỔI FOURIER