Bài giảng Bảo mật cơ sở dữ liệu: Chương 4 - Trần Thị Kim Chi

Bài giảng Bảo mật cơ sở dữ liệu - Chương 4: Role based access control models (Điều khiển truy cập dựa trên vai trò) trình bày các nội dung: Role-Based Access control, các tiêu chuẩn RBAC do NIST đề xuất, core RBAC, operations, permissions assignment, the role hierarchy,... Mời các bạn cùng tham khảo.

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

Role-Based Access Control

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 rolecho 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ểnhạn cua ho.Những role được cấp các permission mới hoặchủy bỏ permission khi cần thiết

Role-Based Access Control

 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ượngnào đó

 Chỉ cấp cho user chính xác những quyền mà user cần đến Việccấp dư thừa những quyền không cần thiết có thể gây nguy hạicho 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

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.

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

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ệmcô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à dongười quản trị CSDL tạo ra

• Role không phải là một đối tượng schema (schema object) nênkhô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

• role là một nhân viên bảo vệ có thể thay đổi các quyề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ó

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

 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

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

không nhất thiết

không

định tất cả các thành viên của một group cụ thể là khá

dễ dàng

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

Role-Based Access ControlMối quan hệ giữa Role-Permission

một nhiệm vụ cụ thể,

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ụ 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

Role-Based Access ControlMố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.

dụng để làm cho các chính sách bảo mật bao gồm sự

quyền

Role-Based Access Control

= Permissions

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)

John

Tom

Jim

Rob

Example: The Three Musketeers

(RBAC)

John

Tom

Jim Rob

John

Tom

Jim

Rob

Example: The Three Musketeers

(RBAC)

John Tom Jim Rob

John

Tom

Jim

Rob

Role-Based Access Control

 RBAC không phải là giải pháp cho mọi vấn để kiểm soát

phức tạp hơn khi xử lí các tình huống mà trong đó chuỗi

cần nhiều bước trước khi đơn dặt hàng mua được pháthà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

đích này

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

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

 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

ions

Sess-user_sessions session_roles

Core RBAC

 Permissions = 2 Operations x Objects

 UA ⊆ Users x Roles

 PA ⊆ Permissions x Roles

 assigned_users: Roles  2 Users

 assigned_permissions: Roles  2 Permissions

 Op(p): set of operations associated with permission p

 Ob(p): set of objects associated with permission p

 user_sessions: Users  2 Sessions

 session_user: Sessions  Users

 session_roles: Sessions  2 Roles

 session_roles(s) = {r | (session_user(s), r)  UA)}

 avail_session_perms: Sessions  2 Permissions

thứ tự cấp bậc của vai trò RH còn có thể được viết là >

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

vai trò

Process

Developer

BudgetManagerHelp Desk

Representative

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

DirectorRelation betweenUSERS & PRMS

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

SQL

 Database – Update Insert Append

 Delete Locks – Open Close

 Reports – Create View Print

 Applications - Read Write Execute

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

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

USER Assignment

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

S USERSxROLE

•Read

•Write

•Execute permissions object

Permissions Assignment

A prms can be assigned to one or more roles

Admin.DB1

A role can be assigned

Permissions Assignment

S USERSxROLE

UA

PRMS setROLES set

View Update Append Create Drop

The set of sessions that each user invokes.USER

SQLDB1.table1 FIN1.report1

APP1.desktop

SESSION

USERS

SQLUser2.DB1.table1.session User2.FIN1.report1.sessionSESSION

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

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

ions

Sess-user_sessions session_roles

Role Hierarchy

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

NIST Secretary

ITL Secretary MEL Secretary

CSD Secretary Comp Security Division

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.

Userr-w-h

Guest-r-

Chỉ khi tất cả các quyền của

Guest Role Set

Power User Role Set User Role Set

Admin Role Set

Support Multiple Inheritance

permissions object

Admin.DB1User.DB2User.DB3

Authorized Permissions

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

PRMS setROLES set

User.DB1User.DB2User.DB3Admin.DB1

Role2 inherits from 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)

• 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

Separation of Duties

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

Static Separation of Duty Relations

privileges

Role Hierarchy

(UA) User Assignment (PA) Permission Assignment

SIONS

SES-session_roles user_sessions

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

SSD