ROLE BASED ACCESS CONTROL MODELS

Điều khiển truy cập dựa trên vai trò

Đặ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

Giới thiệu  Điều khiển truy cập dựa trên vai trò (Role Based Access

 RBAC gán các quyền cho các vai trò cụ thể trong tổ

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

chức. Các vai trò sau đó được gán cho người dùng

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

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.

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.

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

Role-Based Access Control

Có 2 loại quyền:

• 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.

• Quyền hệ thống (System Privilege):

Role-Based Access Control

tượng (Schema Object Privilege hoặc Object

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

Quyền đối Privilege): • Là quyền thực hiện một hành động cụ thể trên một đối tượng schema cụ

Role-Based Access Control

• Vai trò (Role) là "là một tập hợp các quyền (permissions)”

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 đó.

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.

Role-Based Access Control

Ví dụ,

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.

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).

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.

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

Role-Based Access Control

 Vai

So sánh giữa Role (vai trò) và Group (nhóm):

trò đang liên kết với một chức năng, các nhóm

 Vai trò tạo thành một hệ thống phân cấp, các nhóm thì

không nhất thiết

 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

không

xác định permission của nhóm.

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ý.

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

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

 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ột nhiệm vụ cụ thể,

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

 ví dụ công việc của một bác sỹ nội khoa hay một quản lí

cụ thể được luân phiên giữa nhiều user,

ca.

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

Role-Based Access Control

Users

Roles

 Sự phức tạp của quản trị được giảm thông qua:  Phân công người sử

dụng vai trò

 Phân quyền cho các vai

trò

Procedures + Types = Permissions

 Tổ chức vai trò thành

một hệ thống

Objects

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

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.

Example: The Three Musketeers (User/Permission Association)

Jim

John

Tom

Rob

Example: The Three Musketeers (RBAC)

John

Tom

Jim

Rob

John

Jim

Tom

Rob

Example: The Three Musketeers (RBAC)

John Tom Jim Rob

John

Jim

Tom

Rob

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ế.

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

RBAC Reference Model

PA

UA

Users

Roles

Operations

Objects

Permissions

user_sessions (one-to-many)

role_sessions (many-to-many)

Sessions

An important difference from classical models is that Subject in other models corresponds to a Session in RBAC

Example: (John becomes a Musketeer)

JOHN

JOHN

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.

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.

Core RBAC

(PA)

Permission Assignment

(UA) User Assignment

OBJECTS

ROLES

USERS

OPERA 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

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

Core RBAC  U = (User)Người dùng = Một người hoặc một tác nhân tự

 R = (Role)Vai trò = Chức năng công việc / Danh hiệu dùng

động.

 P = Quyềnn được cấp = Sự phê chuẩn một hình thức truy

định nghĩa một cấp bậc quyền thế.

 S = (Session)Phiên giao dịch = Một xếp đặt liên kết giữa

cập tài nguyên.

 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à >

U, R và P

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ò

USERS

Proces s

Intelligent Agent Person

ROLES

An organizational job function with a clear definition of inherent responsibility and authority (permissions).

Director Developer

Relation between USERS & PRMS

Budget Manager

Help Desk Representative

OPERATIONS

 Database – Update Insert Append  Delete Locks – Open Close  Reports – Create View Print  Applications - Read Write Execute

An execution of an a program specific function that’s invocated by a user.

SQL

OBJECTS

An entity that contains or receives information, or has exhaustible system resources.

RBAC will deal with all the objects listed in the permissions assigned to roles.

• OS Files or Directories • DB Columns, Rows, Tables, or Views • Printer • Disk Space • Lock Mechanisms

USER Assignment

USERS set

ROLES set

A user can be assigned to one or more roles

Developer

Help Desk Rep A role can be assigned to one or more users

USER Assignment

Mapping of role r onto a set of users

ROLES set

USERS set

User.DB1

permissions

object

User.F1 User.F2 User.F3 User.DB1 •View •Update •Append

User.DB1

PERMISSIONS

User.DB1 •View •Update •Append

User.F1 •Read •Write •Execute

permissions object

permissions object

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ệ.

Permissions Assignment

ROLES set PRMS set

A prms can be assigned to one or more roles

Create Delete Drop Admin.DB1

A role can be assigned to one or more prms

View Update Append

User.DB1

Permissions Assignment

Mapping of role r onto a set of permissions

•Read •Write •Execute

SQL

ROLES set PRMS set

•View •Update •Append •Create •Drop

User.F1 User.F2 User.F3 Admin.DB1

Permission Assignments

Mapping of permissions to objects

Open Close

PRMS set Objects

BLD1.door2

Gives the set of objects associated with the prms

View Update Append Create Drop

SQL

DB1.table1

SESSIONS

The set of sessions that each user invokes.

FIN1.report1

USER SESSION

DB1.table1

APP1.desktop

SQL

SESSIONS

The mapping of user u onto a set of sessions.

User2.FIN1.report1.session

USER1

USERS SESSION

User2.DB1.table1.session

USER2

User2.APP1.desktop.session

SQL

SESSIONS

SQL

• Admin • User • Guest

DB1.table1.session

SESSION ROLES

SESSIONS

Permissions available to a user in a session.

ROLE PRMS SESSION

•View •Update •Append •Create •Drop

DB1.table1.session

DB1.ADMIN

SQL

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ò.

Hierarchical RBAC

Role Hierarchy

(PA)

Permission Assignment

(UA) User Assignment

OBJECTS

ROLES

USERS

OPERA 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

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).

The Role Hierarchy

Jill

CSD Secretary

Cardiologist

Dermatologist

Comp Security Division

“contains”

“contains”

MEL Secretary

ITL Secretary

Specialist

NIST Secretary

“contains”

p r i v i l e g e

m e m b e r s h i p

Doctor

Added Advantages: • Người sử dụng có thể được đưa vào các

cạnh của đồ thị

“contains”

• Vai trò của thể được xác định từ những đặc quyền của hai hoặc nhiều vai trò cấp dưới

Employee

a-Limited Hierarchies

b-General Hierarchies

Hierarchal RBAC

Hierarchal RBAC

Hierarchal RBAC

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 Inheritance

Guest Role Set

User Role Set

Power User Role Set

Admin Role Set

Chỉ khi tất cả các quyền của r1 cũng là quyền của r2

Guest -r-

i.e. r1 inherits r2

Chỉ khi tất cả người dùng của r1 cũng là người sử dụngr2

User r-w-h

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.DB3 User.DB1 •View •Update •Append

User.DB1

permissions object

User.DB1

Authorized Permissions

Mapping of a role onto a set of permissions in the presence of a role hierarchy

•View •Update •Append

ROLES set PRMS set

•Create •Drop

SQL

User.DB1 User.DB2 User.DB3 Admin.DB1

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

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

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

–

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

Có 2 loại

Constrained RBAC

RH (role hierarchy)

Static Separation of Duty

PA

UA

Users

Roles

Operations

Objects

Permissions

user_sessions (one-to-many)

Dynamic Separation of Duty

Sessions

Separation of Duties

dụng hệ thống riêng của họ.

 Không có người sử dụng nên được trao đủ quyền để lạm

 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

Static Separation of Duty Relations

SSD

Role Hierarchy

(UA) User Assignment

(PA) Permission Assignment

OBJECTS

ROLES

USERS

OPERA 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

Dynamic Separation of Duty Relations

Role Hierarchy

User Assign- ment

Permission Assignment

OBJECTS

ROLES

USERS

OPERA TIONS

privileges

session_roles

user_sessions

SES- SIONS

Dynamic 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

Dynamic Separation of Duty Relations

inherits

Reduce CODE

Roles

Cashier Supervisor

Closes Cashier Role session

Close Cash Drawer Opens Supv Role

Supervisor

Cashier session

Open Cash Drawer

Correct Error Accounting Error

RBAC Family of Models

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.

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.

RBAC0 Models

RBAC0 Components

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.

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.

RBAC1 – RBAC0 + Role Hierarchy

• Ví dụ: một số mô hình RBAC1

RBAC0 Components

RBAC1 – RBAC0 + Role Hierarchy

How to limit the scope of inheritance?

E.g. do not let p boss see incomplete work in progress?

How to limit the scope of inheritance?

E.g. do not let p boss see incomplete work in progress?

Role Hierarchies with Private Roles

Role Hierarchies with Private Roles

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ý.

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

RBAC2 – RBAC0 + Constraints

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.

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.

RBAC3 – RBAC0 + RBAC1

Mô hình RBAC quản lý

Ư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.

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.

Some of the Vendors Offering RBAC Products

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;

Case Study: Oracle Enterprise Server

 User1 activates the roles

 Set role update_role identified by passwd,

 Set default active role for User1

 Alter user user1 default role query_role;

 Assignable privileges

 System: create session, create table, select any

query_role;

 Table: select, update, insert, delete, alter, create index  View: select, update, insert, delete  Procedures & functions: execute

table  Object:

Case Study: Oracle Enterprise Server

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

Configuring RBAC to Enforce MAC and DAC

 Each user with label Write Read  x is assigned roles xR & LW (why?)  Additional Constraints:

y)

 Each session has exactly two matching roles yR and yW (x  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

Configuring RBAC to Enforce MAC and DAC

Configuring RBAC to Enforce MAC and DAC

Configuring RBAC to Enforce MAC and DAC

Configuring RBAC to Enforce MAC and DAC

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)

Eight Permissions  The following eight permissions are also created along

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

with creation of each object O.  canRead_O: assigned to the role READ_O (authorizes read

Roles and associated Permissions

 OWN_O

 destroyObject_O, addParentWithGrant_O,

 addParent_O, deleteParent_O

 PARENT_O

 addReadUser_O, deleteReadUser_O

 READ_O

 canRead_O

deleteParentWithgrant_O  PARENTwithGRANT_O

Strict DAC

 Only owner has discretionary authority to grant

access to an object.

 Example:

 Alice has created an object (she is owner) and grants

 Bob. Now Bob cannot propagate the access to another

access to

 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

user.

Liberal DAC

 Owner can delegate discretionary authority

for granting access to other users.  One Level grant  Two Level Grant  Multilevel Grant

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

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

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

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

Grant-Dependent Revocation

Grant-Dependent Revocation

 We need a different administrative role U_PARENT_O

 U_READ_O for each user U authorized to do a one-level

and a regular role

 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

grant by owner.

Summary

 Group is NOT the same as Role  Role hierarchy is NOT the same as company (report-to)

 RBAC can support SoD, data abstraction and least

hierarchy

 RBAC can be used to configure DAC and MAC

privilege