Bài giảng Bảo mật cơ sở dữ liệu - Điều khiển truy cập dựa trên vai trò

Nội dung text: Bài giảng Bảo mật cơ sở dữ liệu - Điều khiển truy cập dựa trên vai trò

1. ROLE BASED ACCESS CONTROL MODELS Điều khiển truy cập dựa trên vai trò
2. Đặt vấn đề Sự phức tạp của bảo mật quản trị  Khi hệ thống có số lượng lớn các chủ thể và các đối tượng tham gia thì sự ủy quyền có thể trở nên cực kỳ lớn và phức tạp  Khi hệ thống có quá nhiều người sử dụng thì các thao tác cấp quyền và thu hồi quyền rất khó thực hiện và khó quản lý Để giải quyết vấn đề trên người ta dùng cơ chế Role Based access control model
3. Giới thiệu  Điều khiển truy cập dựa trên vai trò (Role Based Access Control-RBAC)  Phát minh vào năm 1970  Áp dụng với hệ thống đa người dùng và đa ứng dụng trực tuyến  Còn được gọi là Điều khiển Truy cập không tùy ý  Quyền truy cập dựa trên chức năng công việc  RBAC gán các quyền cho các vai trò cụ thể trong tổ chức. Các vai trò sau đó được gán cho người dùng
4. Giới thiệu  Điều khiển truy cập dựa trên vai trò (Rule Based Access Control-RBAC)  Tự động gán vai trò cho các chủ thể dựa trên một tập quy tắc do người giám sát xác định  Mỗi đối tượng tài nguyên chứa các thuộc tính truy cập dựa trên quy tắc  Khi người dùng truy cập tới tài nguyên, hệ thống sẽ kiểm tra các quy tắc của đối tượng để xác định quyền truy cập  Thường được sử dụng để quản lý truy cập ngưới dùng tới một hoặc nhiều hệ thống  Những thay đổi trong doanh nghiệp có thể làm cho việc áp dụng các quy tắc thay đổi
5. Role-Based Access Control  Ý tưởng trọng tâm của RBAC là permission (quyền hạn) được kết hợp với role (vai trò) và user (người sử dụng) được phân chia dựa theo các role thích hợp.  RBAC làm đơn giản việc quản lý các permission.Tạo các role cho các chức năng công việc khác nhau trong một tổ chức và các USER được phân các role dựa vào trách nghiệm và quyển hạn cua ho.Những role được cấp các permission mới hoặc hủy bỏ permission khi cần thiết.
6. Role-Based Access Control  Các khái niệm cơ bản:  User (Người dùng) - một con người, một máy, một quá trình, vv  Role là một tập hợp bao gồm các quyền (permission) và các role khác  Đối tượng tham số đặc quyền để hạn chế quyền truy cập vào một tập hợp con của các đối tượng.  Session(phiên) là một phần quan trọng của RBAC phân biệt nó với cơ chế group truyền thống. Session cho phép kích hoạt một tập hợp con của role được gán cho user. Nếu không có session thì tất cả các role của user luôn được kích hoạt dẫn đến việc có thể vi phạm đặc quyền tối thiếu.
7. Role-Based Access Control  Quyền hạn (permission): là một sự cho phép thực hiện một câu lệnh SQL nào đó hoặc được phép truy xuất đến một đối tượng nào đó.  Chỉ cấp cho user chính xác những quyền mà user cần đến. Việc cấp dư thừa những quyền không cần thiết có thể gây nguy hại cho việc bảo mật hệ thống.  Một permission có thể là một cặp object-method hay class-method trong môi trường hướng đối tượng  Một permission cũng có thể là 1 cặp table-query hay view-query trong ứng dụng CSDL  Permissions are assigned to roles: Permission assignment (PA): role- permission  Users are assigned to roles: User assignment (UA): user-role
8. Role-Based Access Control Có 2 loại quyền: • Quyền hệ thống (System Privilege): • Là quyền thực hiện một tác vụ CSDL cụ thể hoặc quyền thực hiện một loại hành động trên tất cả những đối tượng schema của hệ thống. • Vd: quyền ALTER SYSTEM, quyền CREATE TABLE, quyền DELETE ANY TABLE (xóa các hàng của bất kỳ bảng nào trong CSDL), • User có thể cấp 1 quyền hệ thống nếu có một trong các điều kiện sau: • User đã được cấp quyền hệ thống đó với tùy chọn WITH ADMIN OPTION. • User có quyền GRANT ANY PRIVILEGE.
9. Role-Based Access Control Quyền đối tượng (Schema Object Privilege hoặc Object Privilege): • Là quyền thực hiện một hành động cụ thể trên một đối tượng schema cụ thế. • Vd: quyền xóa các hàng dữ liệu khỏi bảng Department. • Có nhiều quyền đối tượng khác nhau dành cho các loại đối tượng schema khác nhau. • Dùng để quản lý việc truy xuất đến các đối tượng schema cụ thể nào đó. • User có thể cấp 1 quyền đối tượng nếu có một trong các điều kiện sau: • User có tất cả mọi quyền đối tượng trên tất cả các đối tượng thuộc schema của mình. Vì vậy user có quyền cấp bất kỳ quyền đối tượng trên bất kỳ đối tượng nào thuộc sở hữu của mình cho bất cứ user nào khác. • User có quyền GRANT ANY OBJECT PRIVILEGE. User được cấp quyền đối tượng đó với tùy chọn WITH GRANT OPTION
10. Role-Based Access Control • Vai trò (Role) là "là một tập hợp các quyền (permissions)”
11. Role-Based Access Control • Role là một tập hợp bao gồm các quyền và các role khác. • Role được gán cho các user hoặc các role khác. • Role giúp cho việc quản trị người dùng dễ dàng và tiết kiệm công sức hơn. • Có một số role có sẵn do hệ thống định nghĩa(vd: DBA, RESOURCE, CONNECT, ) nhưng đa phần các role là do người quản trị CSDL tạo ra. • Role không phải là một đối tượng schema (schema object) nên không được lưu trữ trong schema của user tạo ra nó. Do vậy, user tạo ra một role có thể bị xóa mà không ảnh hưởng đến role đó.
12. Role-Based Access Control Ví dụ, • role là người vận hành có thể truy cập tất cả các tài nguyên mà không thay đổi các quyền truy cập, • role là một nhân viên bảo vệ có thể thay đổi các quyền truy cập nhưng không được truy cập vào các tài nguyên, • role là một kiểm toán viên có thể truy cập vào các việc kiểm toán. • Việc sử dụng các role mang tính quản lí này cũng có trong các hệ thống điều khiển mạng hiện đại như Novell’s NetWare và Microsoft Windows NT.
13. Role-Based Access Control Ví dụ,
14. Role-Based Access Control User có thể cấp 1 role nếu có một trong các điều kiện sau: • User đã tạo ra role đó. • User đã được cấp role đó với tùy chọn WITH ADMIN OPTION. • User có quyền GRANT ANY ROLE.
15. Role-Based Access Control Role (vai trò):  Các vai trò được cấp phát dựa trên cấu trúc tổ chức với sự nhấn mạnh đặc biệt về cấu truc bảo mật.  Các vai trò được cấp phát bởi người quản trị dựa trên các mối quan hệ nội tại của tổ chức hoặc cá nhân. Vi dụ, một người quản lý co thể có các giao dịch được cấp phép với nhân viên của anh ta. Một người quản trị có thể có các giao dịch được cấp phép trong phạm vi quản lý của mình (sao lưu, tạo tai khoản ).  Mỗi vai trò được chỉ định rõ một hồ sơ bao gồm tất cả các câu lệnh, giao dịch và các truy xuất hợp pháp tới thông tin.  Các vai trò được cấp quyền hạn dựa trên nguyên lý đặc quyền tối thiểu (the principle of least privilege).
16. Role-Based Access Control Role (vai trò):  Các vai trò được xác định với các nhiệm vụ khác nhau do đó người có vai trò developer sẽ không thực hiện các nhiệm vụ của vai tro tester.  Các vai trò được kich hoạt tĩnh hoặc động tùy thuộc vào những sự kiện kích hoạt có liên quan (hàng đợi trợ giúp, cảnh báo bảo mật, khởi tạo một project ).  Các vai trò chỉ có thể được chuyển giao hoặc ủy quyền khi sử dụng một quy trình và thủ tục nghiêm ngặt.  Các vai trò được quản ly tập trung bởi một người quản trị bảo mật hoặc trưởng dự án.
17. Role-Based Access Control So sánh giữa Role (vai trò) và Group (nhóm):  Group thường đựợc xem như một tập hợp những user chứ không phải là một tập hợp các permission.  Một role một mặt vừa là một tập hợp các user mặt khác lại là một tập hợp các permission. Role đóng vai trò trung gian để kết nối hai tập hợp này lại với nhau.  Vai trò có thể được kích hoạt và vô hiệu hoá, các nhóm thì không  Các nhóm có thể được sử dụng để ngăn chặn truy cập với thẩm quyền tiêu cực.  Vai trò có thể được vô hiệu hoá cho đặc quyền tối thiểu  Có thể dễ dàng liệt kê các quyền mà một vai trò có, nhưng nhóm thì không
18. Role-Based Access Control So sánh giữa Role (vai trò) và Group (nhóm):  Vai trò đang liên kết với một chức năng, các nhóm không nhất thiết  Vai trò tạo thành một hệ thống phân cấp, các nhóm thì không  Xác định một user cụ thể thuộc group nào hoặc xác định tất cả các thành viên của một group cụ thể là khá dễ dàng.  Việc xác định thành viên của nhóm thường dễ hơn việc xác định permission của nhóm.
19. Role-Based Access Control RBAC là một cơ chế kiểm soát truy cập :  Mô tả chính sách kiểm soát truy cập phức tạp.  Làm giảm sai sót trong quản lý.  Giảm chi phí quản lý.
20. Role-Based Access Control  Chính sách điều khiển truy cập được thể hiện trong các thành phần khác nhau của RBAC như  Mối quan hệ giữa Role-Permission  Mối quan hệ giữa User - Role  Mối quan hệ giữa Role - Role
21. Role-Based Access Control Mối quan hệ giữa Role-Permission  Một role tương ứng với một quyền permission để làm một nhiệm vụ cụ thể,  ví dụ Jane Doe có năng lực để điều hành một số bộ phận nhưng chỉ được phân công điều hành một bộ phận. Mối quan hệ giữa User - Role  Các role phản ánh cho các nhiệm vụ được phân công cụ thể được luân phiên giữa nhiều user,  ví dụ công việc của một bác sỹ nội khoa hay một quản lí ca.
22. Role-Based Access Control Mối quan hệ giữa Role - Role  Ví dụ, hai role có thể đươc lập sao cho loại trừ nhau do đó cùng một user không đựơc phép thực hiện cả hai role.  Các role cũng có thể có quan hệ kế thừa, theo đó một role kế thừa các permission được gắn cho role khác.  Những mối quan hệ role – role này có thể được sử dụng để làm cho các chính sách bảo mật bao gồm sự tách rời các công việc và sự ủy thác của người có thẩm quyền
23. Role-Based Access Control  Sự phức tạp của quản Users trị được giảm thông qua: Roles  Phân công người sử dụng vai trò Procedures  Phân quyền cho các vai + trò Types =  Tổ chức vai trò thành Permissions một hệ thống Objects
24. Role-Based Access Control  RBAC là một chính sách trung lập, nó trực tiếp hỗ trợ ba nguyên tắc bảo mật nổi tiếng:  đặc quyền ít nhất - Least Privilege  sự tách biệt các nhiệm vụ - Separation of duties  trừu tượng hóa dữ liệu.- Data Abstraction
25. Role-Based Access Control  Nguyên tắc đặc quyền ít nhất đựợc hỗ trợ vì RBAC được định dạng do đó chỉ những permission mà nhiệm vụ do các thành viên của role quản lí đó cần mới được phân cho role đó.  Sự tách biệt các nhiệm vụ đạt được bằng cách đảm bảo những role có quan hệ loại trừ lẫn nhau phải đựơc sử dụng tới để hoàn thành một công việc nhạy cảm như yêu cầu một nhân viên kế toán và một quản lí kế toán tham gia vào phát hành một tấm Sec.  Trừu tượng hóa dữ liệu được hỗ trợ bằng các permission trừu tượng như credit (bên có) và debit (bên nợ) cho một tài khoản, chứ không phải là các permission đọc, viết, quản lí thường đựợc hệ điều hành cung cấp.  Tuy nhiên, RBAC không cho phép ứng dụng các nguyên lý này. Nhân viên bảo mật có thể định dạng được RBAC do đó nó vi phạm những nguyên lí này. Ngoài ra, mức độ trừu tuợng hóa dữ liệu đựợc hỗ trợ sẽ do các chi tiết bổ sung quyết định.
26. Example: The Three Musketeers (User/Permission Association) John Jim Tom Rob
27. Example: The Three Musketeers (RBAC) John Tom Jim Rob John Jim Tom Rob
28. Example: The Three Musketeers (RBAC) John Tom Jim Rob John Jim Tom Rob
29. Role-Based Access Control  RBAC không phải là giải pháp cho mọi vấn để kiểm soát truy cập. Người ta cần những dạng kiểm soát truy cập phức tạp hơn khi xử lí các tình huống mà trong đó chuỗi các thao tác cần được kiểm soát. Ví dụ, một lệnh mua cần nhiều bước trước khi đơn dặt hàng mua được phát hành.  RBAC không cố kiểm soát trực tiếp các permission cho một chuỗi các sự kiện như vậy. Các dạng khác của kiểm soát truy cập đựợc cài đặt trên bề mặt RBAC vì mục đích này.  Việc kiểm soát một chuỗi các thao tác ngoài phạm vi của RBAC, mặc dù RBAC có thể là nền móng để xây dựng những kiểm soát như thế.
30. RBAC Reference Model  Mô hình tham chiếu RBAS: định nghĩa một tập hợp các yếu tố cơ bản RBAC (người dùng, vai trò, quyền hạn, hoạt động và đối tượng) và các mối quan hệ như các loại và các chức năng có trong mô hình.  Có hai mục đích:  Xác định nghiêm ngặt phạm vi của tính năng RBAC  Bao gồm các thiết lập các tính năng có trong tất cả các hệ thống RBAC, hệ thống phân cấp vai trò, các mối quan hệ ràng buộc tĩnh, và các mối quan hệ ràng buộc động.  Nó cung cấp một ngôn ngữ chính xác và nhất quán để xác định các đặc tả chức năng
31. RBAC Reference Model UA PA Users Roles Operations Objects Permissions user_sessions role_sessions (one-to-many) (many-to-many) Sessions An important difference from classical models is that Subject in other models corresponds to a Session in RBAC
32. Example: (John becomes a Musketeer) JOHN JOHN
33. Các tiêu chuẩn RBAC do NIST đề xuất  Tiêu chuẩn RBAC này gồm hai phần chính:mô hình tham chiếu RBAC và hệ thống RBAC với đặc tả chức năng quản trị.  Mô hình tham chiếu RBAC định nghĩa tập hợp các yếu tố cơ bản RBAC và loại quan hệ,các chức năng được bao gồm trong tiêu chuẩn này  Hệ thống RBAC với đặc tả chức năng quản trị xác định các yêu cầu đối với hoạt động quản lý tạo và bảo trì danh sách phần tử và các mối quan hệ của RBAC.
34. RBAC Reference Model  The NIST RBAC model is defined in terms of four model components .  Core RBAC  Hierarchical RBAC  Static Separation of Duty Relations  Dynamic Separation of Duty Relations  Each Component is defined by subcomponents:  Set of basic elements sets  A set of RBAC relations involving those elements sets.  A set of mapping functions that yield instances of members from one element set for a given instance from another element set.
35. Core RBAC (PA) Permission (UA) User Assignment Assignment OPERA ROLES OBJECTS USERS TIONS privileges user_sessions session_roles Sess- ions  Mối quan hệ nhiều – nhiều giữa các cá nhân và các đặc quyền  Session là một ánh xạ giữa một người sử dụng và một tập hợp con mới về vai trò được giao  Quan hệ User / vai trò có thể được xác định độc lập các mối quan hệ vai trò / đặc quyền  Đặc quyền hệ thống / ứng dụng phụ thuộc  Chứa kiểm soát truy cập mạnh mẽ dựa trên nhóm truyền thống
36. Core RBAC  Permissions = 2Operations x Objects  UA ⊆ Users x Roles  PA ⊆ Permissions x Roles  assigned_users: Roles 2Users  assigned_permissions: Roles 2Permissions  Op(p): set of operations associated with permission p  Ob(p): set of objects associated with permission p  user_sessions: Users 2Sessions  session_user: Sessions Users  session_roles: Sessions 2Roles  session_roles(s) = {r | (session_user(s), r) UA)}  avail_session_perms: Sessions 2Permissions
37. Core RBAC  U = (User)Người dùng = Một người hoặc một tác nhân tự động.  R = (Role)Vai trò = Chức năng công việc / Danh hiệu dùng định nghĩa một cấp bậc quyền thế.  P = Quyềnn được cấp = Sự phê chuẩn một hình thức truy cập tài nguyên.  S = (Session)Phiên giao dịch = Một xếp đặt liên kết giữa U, R và P  UA = (User Assignment)Chỉ định người dùng.  PA = (Permission Assignment)Cấp phép  RH = (Role Hierarchy)Sắp xếp trật tự một phần nào theo thứ tự cấp bậc của vai trò. RH còn có thể được viết là >
38. Core RBAC  Một người dùng có thể có nhiều vai trò.  Một vai trò có thể có thể có nhiều người dùng.  Một vai trò có thể có nhiều phép được cấp cho nó.  Một phép được cấp có thể được chỉ định cho nhiều vai trò
39. USERS Proces s Person Intelligent Agent
40. ROLES An organizational job function with a clear definition of inherent responsibility and authority (permissions). Developer Director Budget Manager Help Desk Relation between Representative USERS & PRMS
41. OPERATIONS An execution of an a program specific function that’s invocated by a user.  Database – Update Insert Append  Delete Locks – Open Close  Reports – Create View Print  Applications - Read Write Execute SQL
42. OBJECTS An entity that contains or receives information, or has exhaustible system resources. • OS Files or Directories • DB Columns, Rows, Tables, or Views • Printer • Disk Space • Lock Mechanisms RBAC will deal with all the objects listed in the permissions assigned to roles.
43. USER Assignment USERS set A user can be assigned ROLES set to one or more roles Developer A role can be assigned to one or more users Help Desk Rep
44. USER Assignment Mapping of role r onto a set of users ROLES set USERS set UA  USERSxROLES User.F1 User.F2 User.F3 User.DB1 User.DB1 •View •Update •Append permissions object User.DB1
45. PERMISSIONS The set of permissions that each grant the approval to perform an operation on a protected object. Tập các quyền mà mỗi cấp chính thực hiện một hoạt động trên một đối tượng được bảo vệ. User.DB1 User.F1 •View •Read •Update •Write •Append •Execute permissionsobject permissionsobject
46. Permissions Assignment PRMS set A prms can be ROLES set assigned to one or more roles Create Delete Drop Admin.DB1 View Update Append A role can be assigned to one or more prms User.DB1
47. Permissions Assignment Mapping of role r onto a set of permissions ROLES set PRMS set UA  USERSxROLES User.F1 •Read •Write User.F2 •Execute User.F3 •View SQL •Update Admin.DB1 •Append •Create •Drop
48. Permission Assignments Mapping of permissions to objects PRMS set Objects Open Close Gives the set of objects associated BLD1.door2 with the prms View Update Append SQL Create Drop DB1.table1
49. SESSIONS The set of sessions that each user invokes. USER SESSION FIN1.report1 SQL DB1.table1 APP1.desktop
50. SESSIONS The mapping of user u onto a set of sessions. USERS SESSION User2.FIN1.report1.session USER1 SQL User2.DB1.table1.session USER2 User2.APP1.desktop.session
51. SESSIONS SESSION ROLES • Admin SQL • User • Guest DB1.table1.session
52. SESSIONS Permissions available to a user in a session. ROLE PRMS SESSION •View •Update •Append SQL •Create •Drop DB1.ADMIN DB1.table1.session
53. Hierarchical RBAC  Hierarchical RBAC hỗ trợ hệ thống phân cấp vai trò. Một hệ thống phân cấp là xác định thứ tự một mối quan hệ thâm niên giữa các vai trò.
54. Hierarchical RBAC Role Hierarchy (PA) Permission (UA) User Assignment Assignment OPERA ROLES OBJECTS USERS TIONS privileges user_sessions session_roles Sess- ions  Quan hệ Role/role xác định thành viên sử dụng và thừa kế đặc quyền  Phản ánh cơ cấu tổ chức và chức năng của hệ thống  Hai loại phân cấp:  Hệ thống phân cấp giới hạn  Hệ thống phân cấp tổng quát
55. Hierarchal RBAC  Hệ thống phân cấp vai trò tổng quát: hỗ trợ cho một phần trong hệ thống phân cấp vai trò, bao gồm các khái niệm của thừa kế các quyền truy cập và vai trò của thành viên sử dụng trong hệ thống.  Hệ thống phân cấp vai trò giới hạn: áp đặt các gới hạn truy cập theo dạng cấu trúc cây đơn giản (ví dụ, một vai trò có thể có một hoặc nhiều ascendants (cha), nhưng chỉ được truy cập trực tiếp 1 descendant (con) duy nhất).
56. The Role Hierarchy Jill CSD Secretary Dermatologist Cardiologist Comp Security Division m p “contains” “contains” e r m i b MEL Secretary ITL Secretary v e Specialist i r NIST Secretary l s e “contains” h g i e p Added Advantages: Doctor • Người sử dụng có thể được đưa vào các “contains” cạnh của đồ thị • Vai trò của thể được xác định từ những đặc Employee quyền của hai hoặc nhiều vai trò cấp dưới a-Limited Hierarchies b-General Hierarchies
57. Hierarchal RBAC
58. Hierarchal RBAC
59. Hierarchal RBAC
60. General Role Hierarchies  Hỗ trợ đa thừa kế (multiple inheritance), cung cấp khả năng thừa kế đặc quyền từ hai hay nhiều vai trò nguồn và để thừa kế từ một hay nhiều vai trò của các thành viên trong hệ thống. Đa thừa kế là một thuộc tính quan trọng của mô hình RBAC. Support Multiple Guest Role Set Inheritance User Role Set Power User Role Set Admin Role Set i.e. r1 inherits r2 Chỉ khi tất cả các quyền của r1 cũng là quyền của r2 Chỉ khi tất cả người User Guest dùng của r1 cũng là r-w-h -r- người sử dụngr2
61. Authorized Users Mapping of a role onto a set of users in the presence of a role hierarchy Ánh xạ một vai trò vào một tập hợp các người sử dụng theo hệ thống phân cấp vai trò ROLES set First Tier USERS set Admin.DB1 User.DB2 User.DB1 User.DB3 User.DB1 •View •Update •Append User.DB1 permissions object
62. Authorized Permissions Mapping of a role onto a set of permissions in the presence of a role hierarchy ROLES set PRMS set User.DB1 •View •Update User.DB2 •Append User.DB3 •Create SQL Admin.DB1 •Drop
63. LIMITED RH Restriction on the immediate descendants of the general role hierarchy Hạn chế truy cập trực tiếp lớp con cháu trong hệ thống phân câp vai trò tổng quát Role2 Role2 inherits from Role1 Role3 Role1 Role3 does not inherit from Role1 or Role2
64. Limited Role Hierarchies Notice that Frank has two roles: Billing and Cashier This requires the union of two distinct roles and prevents Frank from being a node to others Chú ý rằng Frank có hai vai trò: Thanh toán và thủ quỹ Điều này đòi hỏi sự kết hợp của hai vai trò khác nhau và ngăn Frank từ một nút đến người khác
65. Constrained RBAC – Thi hành tách các yêu cầu nhiệm vụ separation of duty (SOD) – Giảm sự gian lận – Lan truyền trách nhiệm và quyền cho một hành động qua nhiều cá nhân Có 2 loại – Static • Không cho phép kết hợp phân công vai trò người dung • Dễ dàng để thử nghiệm – Dynamic • Không cho phép kết hợp UR trên một mỗi giao dịch cơ bản • Linh hoạt hơn Static
66. Constrained RBAC RH Static (role hierarchy) Separation of Duty UA PA Users Roles Operations Objects Permissions user_sessions (one-to-many) Dynamic Separation of Duty Sessions
67. Separation of Duties . Không có người sử dụng nên được trao đủ quyền để lạm dụng hệ thống riêng của họ. . Tĩnh: xác định xung đột giữa các vai trò . Động: Thi hành các điều khiển ở truy cập theo thời gian
68. Static Separation of Duty Relations SSD Role Hierarchy (UA) User (PA) Permission Assignment Assignment OPERA ROLES OBJECTS USERS TIONS privileges session_roles user_sessions SES- SIONS Chính sách SOD ngăn chặn gian lận bằng cách đặt ràng buộc về các hoạt động của administrative và đưa ra các rang buộc về các đặc quyền mà người dung có sẵn. Ví dụ, không có người sử dụng có thể là một thành viên của cả hai nhiệm vụ thủ quỹ và Thư ký tại Accounts Receivable Department
69. Dynamic Separation of Duty Role HierarchyRelations User Assign- Permission ment Assignment OPERA ROLES OBJECTS USERS TIONS privileges session_roles user_sessions SES- Dynamic SIONS Separation of Duty Chính sách ngăn chặn gian lận DSoD bằng cách đặt những hạn chế về vai trò có thể được kích hoạt trong bất kỳ phiên nào bằng cách hạn chế sự kết hợp của những đặc quyền mà có sẵn cho người dùng
70. Dynamic Separation of Duty Relations Roles Reduce inherits CODE Cashier Supervisor Closes Cashier Role session Close Cash Drawer Opens Supv Role Supervisor Cashier session Accounting Error Open Cash Drawer Correct Error
71. RBAC Family of Models
72. RBAC Family of Models  RBAC0, mô hình cơ bản nằm ở dưới cùng cho thấy đó là yêu cầu tối thiểu cho bất kì một hệ thống nào hỗ trợ RBAC.  RBAC1 có thêm khái niệm cấp bậc role (khi các role có thể kế thừa permission từ role khác).  RBAC2 có thêm những ràng buộc (đặt ra các hạn chế chấp nhận các dạng của các thành tố khác nhau của RBAC). RBAC1 và RBAC2 không so sánh được với nhau.  Mô hình hợp nhất RBAC3 bao gồm cả RBAC1 và RBAC2 và cả RBAC0 nữa.
73. RBAC0 Models  Có 3 nhóm thực thể được gọi là user (U), role (R) và permission (P). Một tập hợp các session (S) đựợc thể hiện trong biểu đồ.  User trong mô hình này là con người.  Một role là một chức năng công việc hay tên công việc trong tổ chức theo thẩm quyền và trách nhiệm trao cho từng thành viên.  Một permission là một sự cho phép của một chế độ cụ thể nào đó truy cập vào một hay nhiều object trong hệ thống.  Mỗi session là một tham chiếu của một user tới những role có thể  Các object là các số liệu object cũng như là các nguồn object được thể hiện bằng số liệu trong hệ thống máy tính.
74. RBAC0 Models
75. RBAC0 Components
76. RBAC0 Components • RBAC0 xử lý các permission như những ký hiệu chưa được thông dịch bởi vì bản chất rõ ràng của một permission là sự cài đặt và sự phụ thuộc hệ thống. • Các permission được sửa đổi để thiết lập U, R và P và quan hệ PA và UA được gọi bởi các permission quản lý. • Những session dưới sự điều khiển của những user riêng lẻ. Một user có thể tạo ra một session và chọn để kích hoạt một vài tập con của những role của user. các role hoạt động trong một session có thể đuợc thay đổi trong sự thận trọng của user. Session giới hạn bởi năng lực của user.
77. RBAC1 – RBAC0 + Role Hierarchy • Một user được cho phép thiết lập một session với nhiều sự kết hợp của role người chức vụ thấp tới user là thành viên của nó. • Hơn nữa, các permission trong một session được gán trực tiếp tới các role của session cũng tốt như việc được gán tới các role của người cấp bậc thấp tới những cái này.
78. RBAC1 – RBAC0 + Role Hierarchy • Ví dụ: một số mô hình RBAC1
79. RBAC0 Components
80. RBAC1 – RBAC0 + Role Hierarchy
81. How to limit the scope of inheritance? E.g. do not let p boss see incomplete work in progress?
82. How to limit the scope of inheritance? E.g. do not let p boss see incomplete work in progress?
83. Role Hierarchies with Private Roles
84. Role Hierarchies with Private Roles
85. RBAC2 – RBAC0 + Constraints • Mô hình RBAC2 giới thiệu khái niệm của ràng buộc. Các ràng buộc là một cơ chế quyền lực đặt cấp cao hơn chính sách của tổ chức. Điều chắc chắn là các role được khai báo loại trừ lẫn nhau, ở đó cần quan tâm quá nhiều về nhiệm vụ của từng user riêng biệt tới các role. • Những hoạt động sau đó có thể được ủy nhiệm và chuyển giao ngoài sự thỏa hiệp toàn bộ cơ chế các đối tượng của tổ chức. • Vì vậy, việc quản lý RBAC được kiểm soát toàn bộ bởi security officer, những ràng buộc là hữu ích cho sự tiện lợi, nhưng hiệu quả cùng lúc có thể lớn hơn giành được bởi sự quan tâm đúng đắn của phần việc của security officer. • Tuy nhiên, nếu sự quản lý của RBAC được chuyển giao, những ràng buộc trở thành một cơ cấu bởi security officer có chức vụ cao hơn có thể giới hạn khả năng của user mà có thể thực hiện đặc quyền quản lý.
86. RBAC2 – RBAC0 + Constraints • RBAC2 không được thay đổi từ RBAC0 ngoại trừ việc yêu cầu có một tập hợp của các ràng buộc mà quyết định dù giá trị của các thành phần khác nhau của RBAC0 có được chấp nhận hay không. Chỉ các giá trị được chấp nhận sẽ được cho phép. • Các ràng buộc có thể được áp dụng tới các session, và chức năng user và các role kết hợp với một session. Nó có thể chấp nhận cho một user là thành viên của 2 role nhưng user không thể hoạt động cả 2 role cùng lúc. Các ràng buộc khác trên các session có thể giới hạn số các session mà user có thể hoạt động cùng lúc. Do đó, số các session mà một permission được gán được giới hạn. • Một hệ thống thứ bậc role có thể được xem như một ràng buộc. Ràng buộc này là một permission gán tới role một người có chức vụ thấp phải được gán tới tất cả các role của người có chức vụ cao hơn
87. RBAC2 – RBAC0 + Constraints
88. RBAC3 – RBAC0 + RBAC1 • RBAC3 là sự kết hợp của RBAC1 và RBAC2 để cung cấp cả hai hệ thống thứ bậc role và các ràng buộc.
89. RBAC3 – RBAC0 + RBAC1 • RBAC3 là sự kết hợp của RBAC1 và RBAC2 để cung cấp cả hai hệ thống thứ bậc role và các ràng buộc.
90. RBAC3 – RBAC0 + RBAC1 Mô hình RBAC quản lý
91. Ưu điểm RBAC  Phù hợp với hầu hết các ứng dụng trong thực tế.  Mô hình đơn giản, hiệu quả.  Đơn giản trong việc quản lý permission, thay vì quản lý permission trên từng user ta sẽ quản lý permission trên mỗi nhóm.Việc này giúp giảm công sức, thời gian cũng như giảm rủi ro nhầm lẫn.  Mô hình RBAC phân cấp hỗ trợ sự phân cấp vai trò (Role hierarchies) với mối quan hệ cha con, theo đó tất cả quyền hạn của role cha được kế thừa bởi role con.Điều này ngăn cản sự bùng nổ role và tăng khả năng sử dụng lại trong mô hình RBAC.
92. Hạn chế của RBAC  Hầu hết các ứng dụng trong thực tế đều có thể điều khiển truy cập theo vai trò, vì thế RBAC có tính phổ dụng cao.Tuy nhiên, nó cũng có một vài hạn chế: . Không phù hợp với một số tài nguyên cần bảo vệ là chưa biết trước. . Không phù hợp khi quy tắc điều khiển truy cập phức tạp, việc điều khiển truy cập không chỉ dựa vào thông tin về vai trò, mà còn phụ thuộc vào các thông tin ngữ cảnh khác. . Không phù hợp với các ứng dụng mà một người dùng có thể mang nhiều vai trò mâu thuẫn với nhau.Điều này phần nào được giải quyết với mô hình RBAC ràng buộc tĩnh hay động.Tuy nhiên khi các quy tắc đảm bảo tính loại trừ là phức tạp và chưa biết trước thì RBAC ràng buộc không đáp ứng được hoặc khó cài đặt.
93. Some of the Vendors Offering RBAC Products
94. Case Study: Oracle Enterprise Server  Create password-protected role for update  Create role update_role identified by passwd;  Grant update privileges to protected role  Grant insert, update on app.table1 to update_role;  Create non-password protected role for query  Create role query_role;  Grant select privileges to unprotected role  Grant select on app.table1 to query_role;  Grant both roles to users  Grant update role, query role to user1;
95. Case Study: Oracle Enterprise Server  User1 activates the roles  Set role update_role identified by passwd, query_role;  Set default active role for User1  Alter user user1 default role query_role;  Assignable privileges  System: create session, create table, select any table  Object:  Table: select, update, insert, delete, alter, create index  View: select, update, insert, delete  Procedures & functions: execute
96. Case Study: Oracle Enterprise Server
97. Configuring RBAC to Enforce MAC and DAC  Construction (Liberal *-Property) (write-up)  R = {L1R. . . LnR, L1W. . . LnW} where Li denote label i  RH which consists of two disjoint role hierarchies. The first role hierarchy consists of the “read“ roles {L1R. . . LnR} and has the same partial order as ≥MAC ;  the second partial consists of the “write” roles {L1W. . LnW} . and has a partial order which is the inverse of ≥MAC .  P = { (o,r),(o,w) | o is an object in the system}  Constraint on UA: Each user is assigned to exactly two roles xR and LW where x is the label assigned to the user and LW is the write role corresponding to the lowermost security level according to ≥MAC  Constraint on sessions: Each session has exactly two roles yR and yW (x ≥ y) Constraints on PA:  (o,r) is assigned to xR iff (o,w) is assigned to xW  ( o,r) is assigned to exactly one role xR such that x is the label of o
98. Configuring RBAC to Enforce MAC and DAC  Each user with label Write Read  x is assigned roles xR & LW (why?)  Additional Constraints:  Each session has exactly two matching roles yR and yW (x y)  For each object with label x, a pair of permissions (o,r) & (o,w) is assigned to exactly one matching pair of xR and xW roles
99. Configuring RBAC to Enforce MAC and DAC
100. Configuring RBAC to Enforce MAC and DAC
101. Configuring RBAC to Enforce MAC and DAC
102. Configuring RBAC to Enforce MAC and DAC
103. Configuring RBAC for DAC  The basic idea is to simulate the owner-centric policies of  DAC using roles that are associated with each object.  Strict DAC – only owner can grant access  Liberal DAC – owner can delegate discretionary authority for granting access to an object to other users  Create an Object. For every object O that is created, three administrative roles and one regular role are also created (we show only Read operation)
104. Eight Permissions  The following eight permissions are also created along with creation of each object O.  canRead_O: assigned to the role READ_O (authorizes read operation on object O)  destroyObject_O: assigned to the role OWN_O (authorizes deletion of the object)  addReadUser_O, deleteReadUser_O: assigned to the role PARENT_O (add/remove users to/from role READ_O)  addParent_O, deleteParent_O: assigned to the role PARENTwithGRANT_O (add/remove users to/from role PARENT_O)  addParentWithGrant_O, deleteParentWithGrant_O: assigned to the role OWN_O (add/remove users to/from PARENTwithGRANT_O)  Object deletion removes the roles OWN_O, PARENT_O, PARENTwithGRANT_O and READ_O along with the 8 permissions
105. Roles and associated Permissions  OWN_O  destroyObject_O, addParentWithGrant_O, deleteParentWithgrant_O  PARENTwithGRANT_O  addParent_O, deleteParent_O  PARENT_O  addReadUser_O, deleteReadUser_O  READ_O  canRead_O
106. Strict DAC  Only owner has discretionary authority to grant access to an object.  Example:  Alice has created an object (she is owner) and grants access to  Bob. Now Bob cannot propagate the access to another user.  Cardinality constraints on roles:  OWN_O = 1  PARENT_O = 0  PARENTwithGRANT_O = 0  By virtue of the role hierarchy, owner can change assignments of the role READ_O
107. Liberal DAC  Owner can delegate discretionary authority for granting access to other users.  One Level grant  Two Level Grant  Multilevel Grant
108. One Level Grant  Owner can delegate authority to another user but they cannot further delegate this power.  Cardinality constraints as:  Role OWN_O = 1  Role PARENTwithGRANT O = 0  No restriction on Parent_O
109. One Level Grant  In addition to a one level grant the owner can allow some users to delegate grant authority to other users.  Cardinality constraints as:  Role OWN_O = 1
110. Multi-Level Grant  In addition to a one level grant the owner can allow some users to delegate grant authority to other users.  Cardinality constraints as:  Role OWN_O = 1  Additional permission  PARENTwithGRANT_O  AddParentWithGrant_O  DeleteParentWithGrant_O  Grant independent revocation  Alternatively OWN
111. Revocation  Grant-Independent Revocation  Grant may be revoked by anyone (not necessarily the granter)  Alice grants Bob access, but Bob’s access may be revoked by Charles  Grant-Dependent Revocation  Revocation is tied to the granter  grants Bob access, and only Alice can revoke Bob’s access
112. Grant-Dependent Revocation
113. Grant-Dependent Revocation  We need a different administrative role U_PARENT_O and a regular role  U_READ_O for each user U authorized to do a one-level grant by owner.  We also need two new administrative permissions  addU_ReadUser_O, deleteU_ReadUser_O: assigned to U_PARENT_O  authorize the operations to add users to role U_Read_O and delete users from U_Read_O  cardinality of U_PARENT_O = 1
114. Summary  Group is NOT the same as Role  Role hierarchy is NOT the same as company (report-to) hierarchy  RBAC can support SoD, data abstraction and least privilege  RBAC can be used to configure DAC and MAC