Nghiên cứu phương pháp điều khiển truy cập dựa vai trò trong việc đảm bảo an toàn cho các ứng dụng dựa thành phần

Cơ chế hiện hành đối với điều khiển truy cập của các ứng dụng dựa thành phần thường dựa trên dữ liệu của các thành phần hoặc các phương thức cung cấp bởi các thành phần.. Vấn đề an ninh

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN THỊ THU PHƯƠNG

NGHIÊN CỨU PHƯƠNG PHÁP ĐIỀU KHIỂN TRUY CẬP DỰA VAI TRÒ TRONG VIỆC ĐẢM BẢO AN TOÀN CHO CÁC ỨNG DỤNG

Mục lục

Danh mục hình vẽ iv

Danh mục ký hiệu, từ viết tắt v

Mở đầu 1

Chương 1 Công nghệ thành phần phần mềm 4

1.1 Công nghệ thành phần phần mềm 4

1.1.1 Một số định nghĩa 4

1.1.2 Vấn đề an ninh đối với phần mềm dựa thành phần 5

1.2 Enterprise JavaBeans 6

1.2.1 Tổng quan 6

1.2.2 Vấn đề an ninh trong công nghệ EJB 11

Chương 2 Điều khiển truy cập dựa vai trò (RBAC) 14

2.1 Giới thiệu 14

2.2 Mô hình RBAC 17

2.2.1 Mô hình RBAC cơ sở 17

2.2.2 RBAC phân cấp 19

2.2.3 RBAC ràng buộc 21

2.2.4 RBAC hợp nhất 23

2.3 Ưu điểm của RBAC 24

2.4 Chính sách điều khiển truy cập đối với các ứng dụng EJB 26

2.4.1 Một ví dụ 26

2.4.2 RBAC trong đặc tả EJB hiện hành 27

Chương 3 Chương trình quản trị - báo cáo thanh toán hóa đơn 30

3.1 Tổng quan 30

3.1.1 Các thông tin cơ sở 30

3.1.2 Công nghệ sử dụng 30

3.1.3 Các yêu cầu của hệ thống 31

3.2 Phân tích - thiết kế hệ thống 31

3.2.1 Phân tích hoạt động hệ thống 31

3.2.2 Kiến trúc hệ thống 34

3.2.3 Thiết kế dữ liệu 36

3.2.4 Thiết kế hướng đối tượng 36

3.3 Điều khiển truy cập cho hệ thống 39

3.3.1 Phương pháp điều khiển truy cập hiện tại 39

3.3.2 Áp dụng RBAC cho hệ thống 41

KẾT LUẬN 47

TÀI LIỆU THAM KHẢO 49

Danh mục hình vẽ

Hình 1.1: Các thành phần EJB trong các ứng dụng đa tầng 6

Hình 1.2: Trình chứa EJB 8

Hình 1.3 Tương tác giữa client và thành phần EJB 8

Hình 2.1: Điều khiển truy cập truyền thống và Điều khiển truy cập dựa vai trò 16 Hình 2.2: Mô hình RBAC0 17

Hình 2.3: Mô hình RBAC1 20

Hình 2.4: Mô hình SSD 22

Hình 2.5: Mô hình DSD 23

Hình 2.6: Quan hệ giữa các mô hình RBAC 23

Hình 2.7: Mô hình RBAC3 24

Hình 2.8: RBAC làm giảm độ phức tạp trong việc quản trị hệ thống 24

Hình 2.9: Các thành phần EJB trong hệ thống eBank 26

Hình 3.1: Các đối tượng tương tác với hệ thống 32

Hình 3.2: Hoạt động của Giao dịch viên 32

Hình 3.3: Hoạt động của quản lý chi nhánh 32

Hình 3.4: Hoạt động của người quản trị 33

Hình 3.5: Các tầng trong mô hình J2EE cho hệ thống 34

Hình 3.6: Các trình chứa J2EE cho hệ thống 34

Hình 3.7: Chu trình hoạt động của chương trình qua các thành phần 35

Hình 3.8: Thuộc tính và phương thức của lớp thực thể dữ liệu 37

Hình 3.9: Thuộc tính và phương thức của lớp Session EJB 38

Hình 3.10: Lớp JavaBean 39

Hình 3.11: Sequence Diagram cho chức năng tạo người dùng 40

Danh mục ký hiệu, từ viết tắt

API Application Programming Interface

CBSE Component-Based Software Engineering CMP Container Managed Persistence

COM/DCOM Component Object Model/

Distributed Component Object Model CORBA Common Object Request Broker Architecture DAC Discretionary Access Control

IDL Interface Definition Language

J2EE Java 2 Enterprise Edition

JAAS Java Authentication and Authorization Service JCA Java Cryptography Architecture

JNDI Java Naming and Directory Interface

MTS Microsoft Transaction Server

Mở đầu

Hầu hết các hệ thống thông tin quy mô lớn hiện nay được xây dựng dựa trên công nghệ thành phần phần mềm Trong kỹ nghệ phần mềm dựa thành phần (Component-Based Software Engineering - CBSE), các hệ thống thông tin được phát triển bởi các thành phần Các thành phần được sử dụng trong một ứng dụng

có thể được tự phát triển hoặc có thể được mua từ bên thứ ba Hơn nữa, một thành phần có thể được tái sử dụng trong nhiều ứng dụng khác nhau Kết quả là, tính phức tạp, thời gian và chi phí phát triển ứng dụng được giảm đáng kể Ngoài ra, việc bảo trì và phát triển các ứng dụng cũng dễ dàng hơn

Bên cạnh những lợi ích trên, việc sử dụng các thành phần trong việc phát triển các hệ thống thông tin cũng đưa ra nhiều thách thức mới Ví dụ về những thách thức này là sự thay đổi trong vòng đời phần mềm, những khó khăn trong việc kiểm thử, và sự phức tạp trong việc đảm bảo an ninh Các vấn đề an ninh của các ứng dụng dựa thành phần ngày càng được quan tâm xem xét Có nhiều vai trò tham gia vào quá trình phát triển một ứng dụng dựa thành phần, do đó, có nhiều khó khăn hơn trong việc giữ cho các ứng dụng được xây dựng từ các thành phần an toàn so với các ứng dụng được phát triển từ đầu Ngoài ra, các thành phần được mua từ bên thứ ba thường không có mã nguồn, điều này dẫn đến khó khăn trong việc đánh giá tính an toàn của các thành phần cũng như các ứng dụng phát triển từ các thành phần này

Các nghiên cứu về vấn đề cung cấp an ninh cho các ứng dụng dựa thành phần có thể được phân thành ba hướng chính Hướng thứ nhất là về sự tương thích của các thuộc tính an ninh của các thành phần được sử dụng trong một ứng Hướng thứ hai là bảo vệ các thành phần và các ứng dụng dựa thành phần từ người dùng độc hại Hướng thứ ba là bảo vệ các ứng dụng từ các thành phần độc hại Đối với hai hướng sau, cơ chế phổ biến nhất để bảo vệ các ứng dụng dựa thành phần là cơ chế điều khiển truy cập

Cơ chế hiện hành đối với điều khiển truy cập của các ứng dụng dựa thành phần thường dựa trên dữ liệu của các thành phần hoặc các phương thức cung cấp bởi các thành phần Trong hầu hết các ứng dụng dựa thành phần, các chính sách điều khiển truy cập được thiết lập cho từng thành phần riêng lẻ Điều này có thể gây ra các vấn đề trong phát triển ứng dụng khi kết hợp các thành phần với nhau

Cùng với CORBA (Common Object Request Broker Architecture) và COM/DCOM (Component Object Model/Distributed Component Object Model), Enterprise JavaBeans (EJB) là một trong những mô hình thành phần

phổ biến nhất Như nhiều mô hình thành phần khác, EJB sử dụng điều khiển truy cập như một phương tiện để bảo vệ tài nguyên ứng dụng Trong mô hình thành phần EJB cũng như trong các mô hình thành phần khác, điều khiển truy cập được thiết lập cho từng thành phần riêng lẻ (tức là dựa trên dữ liệu hoặc các phương thức của các thành phần) Điều này có thể gây ra các vấn đề phát triển ứng dụng khi kết hợp các thành phần lại với nhau để xây dựng ứng dụng

Công nghệ thành phần phần mềm đã được đề cập đến trong một thời gian dài và đã có rất nhiều định nghĩa khác nhau về công nghệ này (tức là một thành phần là gì?) Bên cạnh đó, tồn tại nhiều mô hình thành phần khác nhau Đối với việc nghiên cứu về vấn đề an ninh trong công nghệ thành phần, cần lựa chọn một trong các mô hình này Luận văn này thực hiện theo mô hình thành phần Enterprise JavaBeans (EJB) và tôi chỉ xem xét các cơ chế cấp phép (authorization) của công nghệ này

Việc cấp phép của công nghệ EJB dựa vào cơ chế điều khiển truy cập dựa vai trò (Role-Based Access Control - RBAC) Trong RBAC, mỗi người dùng được gán cho một hoặc nhiều vai trò Mỗi vai trò có một tập các quyền truy cập (tức là được phép thực hiện một phương thức nhất định) Quyền truy cập của mỗi người dùng là hợp các tập quyền truy cập của tất cả các vai trò mà người sử dụng hiện đang thuộc về

Trong các ứng dụng EJB, có hai phương pháp để thiết lập điều khiển truy cập dựa vai trò: điều khiển truy cập chương trình (programmatic access control)

và điều khiển truy cập khai báo (declarative access control) Trong phương pháp thứ nhất, các chính sách kiểm soát được nhúng vào bên trong mã thành phần thông qua các lời gọi API (Application Programming Interface) (tức là được quyết định bởi các nhà phát triển thành phần) Phương pháp thứ hai cho phép các nhà phát triển ứng dụng xác định các chính sách điều khiển truy cập trong một tập tin riêng biệt Một trong những lợi thế của điều khiển truy cập chương trình là cơ chế này cung cấp cho nhà phát triển khả năng xác định các chính sách mịn (fine-grained policies) Tuy nhiên, điều khiển truy cập khai báo đơn giản và linh hoạt hơn Bằng việc sử dụng phương pháp điều khiển truy cập này, ta có thể tách riêng vấn đề an ninh khỏi các chức năng của ứng dụng Vì vậy, cơ chế này phù hợp hơn đối với các ứng dụng dựa thành phần so với điều khiển truy cập chương trình Do lợi thế của nó, đề tài này tập trung nghiên cứu điều khiển truy cập khai báo

Các phần còn lại của luận văn có cấu trúc như sau:

Trong chương một, luận văn nghiên cứu về công nghệ thành phần phần mềm và một số mô hình thành phần phần mềm, đặc biệt đi sâu vào nghiên cứu

mô hình thành phần Enterprise JavaBeans (EJB)

Ở chương hai, luận văn nghiên cứu cơ chế điều khiển truy cập dựa vai trò (RBAC) và RBAC trong các ứng dụng EJB Có hai phương pháp điều khiển truy cập dựa vai trò trong đặc tả EJB: điều khiển truy cập chương trình và điều khiển truy cập khai báo Phân tích ưu điểm cũng như hạn chế của hai phương pháp Luận văn tập trung vào điều khiển truy cập khai báo do phương pháp này phù hợp hơn với công nghệ thành phần EJB

Trong chương ba, luận văn phân tích hệ thống quản trị - báo cáo thanh toán hóa đơn, từ đó đưa ra những hạn chế về mặt an ninh của hệ thống hiện tại Sau

đó, áp dụng phương pháp điều khiển truy cập dựa vai trò khắc phục các hạn chế

về an ninh của hệ thống

Chương 1 Công nghệ thành phần phần mềm

1.1 Công nghệ thành phần phần mềm

Trong thập kỷ qua, kỹ nghệ phần mềm dựa thành phần (CBSE) đã trở thành một chủ đề quan trọng trong kỹ nghệ phần mềm Điều cần quan tâm là xây dựng các ứng dụng phần mềm từ các thành phần phần mềm đã được xây dựng trước

Mô hình này cung cấp nhiều lợi ích khi được so sánh với việc xây dựng ứng dụng phần mềm từ đầu Sử dụng các thành phần làm tăng khả năng dùng lại vì các thành phần phần mềm có thể được sử dụng trong các ứng dụng khác nhau Điều này dẫn đến việc giảm chi phí sản xuất và giảm thời gian đưa ra thị trường của phần mềm Xây dựng các ứng dụng từ các thành phần cũng đơn giản hoá việc bảo trì các ứng dụng Ví dụ, khi ta muốn thay đổi một số chức năng của ứng dụng, ta chỉ cần thay đổi các thành phần tương ứng với chức năng, các bộ phận khác của ứng dụng được giữ lại nguyên vẹn Ngoài ra, mỗi thành phần thường tập trung vào một khía cạnh cụ thể và được phát triển bởi chuyên gia trong lĩnh vực đó Với việc mua các thành phần này từ thị trường, nhà phát triển ứng dụng vẫn có thể có thành phần chất lượng cao mà không cần sử dụng các chuyên gia

1.1.1 Một số định nghĩa

Mặc dù mọi người đều nhất trí về lợi ích của công nghệ dựa thành phần, tuy nhiên quan điểm về một thành phần phần mềm lại rất khác nhau Một số nhà nghiên cứu cho rằng một thành phần giống như một thư viện Một số người khác lại cho rằng một thành phần phần mềm phải có khả năng triển khai một cách độc lập Luận văn này sử dụng định nghĩa về các thành phần phần mềm được đưa ra bởi Szyperski [14]

Một thành phần phần mềm là một đơn vị của một tổ hợp với các giao diện được xác định và chỉ phụ thuộc vào ngữ cảnh rõ ràng Một thành phần phần mềm có thể được triển khai một cách độc lập và là đối tượng để kết hợp bởi các bên thứ ba

Điều quan trọng ở đây là sự tách biệt giữa sự thực thi (implementation) thành phần và các giao diện (interface) thành phần Các giao diện xác định làm thế nào để tương tác với các thành phần, trong khi đó các phần thực thi thực hiện các chức năng được cung cấp bởi các thành phần Điều này có nghĩa là nếu ta thay đổi phần thực thi của một thành phần mà không thay đổi các giao diện của

nó, các thành phần khác trong cùng một ứng dụng sẽ không nhận biết được sự thay đổi

Một điểm khác ta cần phải xem xét là sự khác nhau giữa các giao diện và các hợp đồng (contract) Giao diện quy định cú pháp cho các thành phần khách

sử dụng một thành phần cụ thể Các giao diện thường bao gồm tên và các tham

số của phương thức (method) Hợp đồng xác định ngữ nghĩa của các giao diện

và các phương thức Hợp đồng lập danh sách các ràng buộc (constraint) được bảo trì bởi các thành phần như các mẫu (pattern) đối với nhóm các thành phần

để tương tác với nhau

Chi tiết của một thành phần phần mềm được xác định bởi một mô hình thành phần Ví dụ, COM/DCOM [11] và Enterprise JavaBeans [13] là các mô hình thành phần Các mô hình thành phần định nghĩa các chuẩn đối với việc xây dựng và kết hợp các thành phần

1.1.2 Vấn đề an ninh đối với phần mềm dựa thành phần

Bên cạnh những lợi ích như giảm độ phức tạp, thời gian, và chi phí phát triển hệ thống, việc sử dụng các thành phần trong các hệ thống thông tin đang phát triển có thể đem lại những thách thức an ninh mới [7] [8]

Từ quan điểm của người phát triển thành phần, việc cung cấp an ninh cho các thành phần là khó Lý do là khi phát triển một thành phần cụ thể, người phát triển thành phần không biết về môi trường trong đó thành phần được sử dụng và

họ cũng thiếu các yêu cầu an ninh từ phía người dùng thành phần (tức là người phát triển ứng dụng) Điều này dẫn đến một thực tế là thành phần không được kiểm tra triệt để

Từ quan điểm của người phát triển ứng dụng, đảm bảo an ninh cho các ứng dụng dựa thành phần là phức tạp vì các thành phần thường được mua từ thị trường mà không có mã nguồn Kết quả là, các đánh giá về an ninh của mỗi thành phần riêng biệt cũng như toàn bộ ứng dụng đã tích hợp các thành phần này

là phức tạp Ngoài ra, các thành phần có thể được mua từ nhiều nguồn (nghĩa là

từ các bên thứ ba khác nhau) và cơ chế an ninh của các thành phần này có thể không tương thích

Như đã đề cập ở trên, một trong những đặc trưng quan trọng nhất của công nghệ thành phần là khả năng tái sử dụng của các thành phần Một thành phần có thể được sử dụng trong nhiều hệ thống khác nhau Nhược điểm của đặc trưng này là nếu thành phần chứa một lỗ hổng bảo mật, bất kỳ hệ thống nào đang sử dụng nó cũng bị đe dọa

1.2 Enterprise JavaBeans

1.2.1 Tổng quan

Sun Microsystems công bố đặc tả Enterprise JavaBean (EJB) vào năm

1998 Kiến trúc EJB là kiến trúc thành phần dành cho việc phát triển và triển khai các ứng dụng phân tán hướng thành phần Một thành phần EJB là thành phần có khả năng sử dụng lại, viết một lần chạy mọi nơi (Write Once Run Anywhere - WORA), có tính khả chuyển, tính linh hoạt và thành phần đã được biên dịch có thể được triển khai trên bất kỳ máy chủ EJB nào như Java 2 Enterprise Edition (J2EE), JBoss hay môi trường WebLogic Enterprise Công nghệ EJB là một phần của J2EE, nó cung cấp một tập API và các dịch vụ khác Việc cài đặt EJB tập trung vào lô gic nghiệp vụ J2EE được thiết kế để hỗ trợ các ứng dụng doanh nghiệp cung cấp các dịch vụ thương mại

Cùng với CORBA [9] và DCOM [11], Enterprise JavaBeans (EJB) [13] là một trong những công nghệ hàng đầu cho việc phát triển các ứng dụng dựa thành phần Công nghệ EJB hỗ trợ xây dựng các thành phần trên máy chủ của các ứng dụng J2EE đa tầng Hình 1.1 dưới đây cho thấy vị trí của các thành phần EJB trong một ứng dụng J2EE Các thành phần EJB được sử dụng trong tầng nghiệp vụ của hệ thống

Hình 1.1: Các thành phần EJB trong các ứng dụng đa tầng

Mỗi thành phần EJB là một thành phần phần mềm Các thành phần EJB có thể được triển khai độc lập bên trong trình chứa EJB (EJB container) Các trình chứa cung cấp môi trường thực thi cho các thành phần EJB và kiểm soát hầu hết các khía cạnh phi chức năng như an ninh, giao dịch và lưu trữ, phục hồi đối tượng

Kiến trúc EJB giúp cho việc phát triển các ứng dụng doanh nghiệp dễ dàng hơn vì chúng không cần quan tâm đến các dịch vụ mức hệ thống như là quản lý

giao dịch, quản lý an ninh, quản lý đa luồng, và các vấn đề quản lý chung khác Kiến trúc EJB hỗ trợ WORA và các giải pháp di động Một thành phần EJB có thể được phát triển một lần sau đó có thể sử dụng lại trong nhiều ứng dụng và triển khai trên nhiều nền tảng khác nhau mà không phải biên dịch và sửa lại mã nguồn Một thành phần EJB là một thành phần phía server cung cấp các dịch vụ cho điều khiển từ xa hoặc client cục bộ, trong khi một java bean là một thành phần phía client được cài đặt và chạy hầu hết ở phía client Chúng ta có thể có một java bean phía server nhưng khó có thể cung cấp các dịch vụ cho các client

từ xa Một thành phần EJB được chứa bởi trình chứa của nó và trình chứa được

hỗ trợ bởi J2EE hoặc bất kì công cụ nào tuân theo J2EE

Trình chứa EJB

Một thể hiện EJB được chạy trên một trình chứa EJB Trình chứa là môi

trường chạy (tập các file class được sinh ra trong quá trình phát triển), nó điều

khiển một thể hiện thành phần EJB và cung cấp tất cả các dịch vụ quản lý cần thiết cho toàn bộ vòng đời của nó [1] Các dịch vụ bao gồm:

- Quản lý giao tác: đảm bảo các đặc tính giao tác của việc thực thi giao

tác phân tán

- Quản lý lưu trữ bền vững: đảm bảo trạng thái bền vững của một entity

bean được sao lưu bởi cơ sở dữ liệu

- Quản lý vòng đời: đảm bảo sự dịch chuyển trạng thái của thành phần

EJB trong vòng đời của nó

Trình chứa EJB cung cấp một giao diện cho thành phần EJB để giao tiếp với thế giới bên ngoài Tất cả các yêu cầu tới thành phần EJB hay các đáp ứng

từ thành phần EJB đều phải thông qua trình chứa EJB Trình chứa EJB cô lập thành phần EJB để nó không bị truy nhập trực tiếp từ các client Trình chứa sẽ chặn lời gọi từ client để đảm bảo tính bền vững, các đặc tính giao tác, và an ninh các hoạt động của client trên EJB Hình 1.2 chỉ ra rằng trình chứa EJB hỗ trợ thành phần EJB và một thành phần EJB cần trình chứa để đi ra bên ngoài và để nhận các thông tin cần thiết từ giao diện ngữ cảnh của nó Trình chứa EJB có trách nhiệm tạo ra các đối tượng EJB Home, giúp cho việc xác định, tạo và xóa

bỏ các đối tượng thành phần EJB Giao diện ngữ cảnh EJB cung cấp bởi trình chứa EJB đóng gói các thông tin liên quan về môi trường của trình chứa như là định danh của một thành phần EJB, các trạng thái của giao tác và tham chiếu từ

xa tới EJB

Hình 1.2: Trình chứa EJB

Thành phần EJB

Một enterprise bean là một thành phần phân tán trong một trình chứa EJB

và được truy cập bởi client từ trên mạng thông qua giao diện từ xa của nó hoặc được truy nhập thông qua enterprise bean khác trên cùng server thông qua giao diện địa phương (local) của nó Thành phần EJB là một thành phần có khả năng thực thi từ xa được triển khai trên server của nó và có khả năng tự mô tả được chỉ ra bởi DD (Deployment Descriptor) với định dạng XML (eXtensible Markup Language)

Mỗi thành phần EJB có một giao diện lô gic nghiệp vụ được tạo ra bởi thành phần đó nên các client có thể truy cập vào các thao tác lô gic nghiệp vụ thông qua giao diện này mà không cần phải biết cài đặt chi tiết đằng sau giao diện đó Chúng ta gọi giao diện như vậy là một remote interface Một thể hiện của thành phần EJB được tạo ra và quản lý thông qua home interface của nó bởi trình chứa EJB Mỗi enterprise bean phải có một home interface và một remote interface Thành phần EJB có thể được cấu hình tại thời gian triển khai bằng đặc

tả DD Hình 1.3 mô tả cấu trúc của một thành phần EJB và biểu đồ quá trình tương tác giữa một client và một thành phần EJB

Hình 1.3 Tương tác giữa client và thành phần EJB

Lớp EJB đằng sau các giao diện home và remote được thiết kế để thực thi hai giao diện Một thành phần EJB là một thành phần hộp đen (black–box component) Client của một thành phần EJB chỉ biết thành phần nào chứ không biết nó như thế nào Client tạo một yêu cầu tới thành phần EJB với tên được triển khai của nó bằng việc tìm kiếm trong JNDI (Java Naming and Directory Interface) để lấy tham chiếu đối tượng của thành phần EJB Client sau đó có thể tạo một thể hiện của thành phần EJB này trên server theo tham chiếu đối tượng Cuối cùng, client gọi các phương thức của thể hiện EJB này Tất nhiên một EJB phải đăng kí với JNDI để các client có thể tìm kiếm nó

Các enterprise bean là các thành phần phần mềm có thể được nhúng trong nhiều ứng dụng khác nhau mà không cần phải dịch lại hoặc thay đổi mã nguồn Chúng có thể được triển khai trong nhiều máy chủ tuân theo mô hình EJB Mô hình thành phần EJB hỗ trợ những loại enterprise bean sau:

Bean phiên (Session Bean)

Một bean phiên biểu diễn một client đơn bên trong máy chủ ứng dụng (Application Server - AS) Để sử dụng một ứng dụng được triển khai trên server, client gọi các phương thức của bean phiên Bean phiên thực hiện công việc cho các client của nó Việc này tránh cho client phải thực hiện các công việc phức tạp, thay vì đó nó sẽ được thực hiện trên server Giống như tên của nó, bean phiên giống như một phiên tương tác (interactive session) Một bean phiên không thể chia sẻ, nó chỉ có thể có một client Giống như một phiên tương tác,

dữ liệu của bean phiên không được lưu vào cơ sở dữ liệu Khi client ngắt, bean phiên của nó cũng bị ngắt, nó không kết nối lâu dài với client Có 2 kiểu bean phiên đó là trạng thái (stateful) và phi trạng thái (stateless):

- Bean phiên trạng thái (stateful session bean): Trạng thái của một đối

tượng bao gồm giá trị của các biến Trong một bean phiên trạng thái, các giá trị biểu diễn trạng thái của một bean phiên cho duy nhất một client Vì client tương tác với bean của nó, trạng thái này thường được gọi là trạng thái đàm thoại Trạng thái này được duy trì trong suốt phiên làm việc giữa client và bean Nếu client loại bỏ bean hoặc ngắt, phiên kết thúc và các trạng thái sẽ mất

- Bean phiên phi trạng thái (stateless session bean): Không duy trì trạng

thái đàm thoại với client Khi một client gọi các phương thức của một bean phiên phi trạng thái, các biến của bean có thể chứa một trạng thái

cụ thể cho một client, nhưng chỉ trong thời gian của lời gọi Khi phương thức hoàn thành, trạng thái này sẽ bị mất Tuy nhiên, các client

có thể thay đổi trạng thái của các biến trong bean phiên được lưu lại

(pooled stateless bean), trạng thái này sẽ được giữ đến lời gọi tiếp theo của bean phiên Vì bean phiên phi trạng thái có thể hỗ trợ nhiều client, chúng có tính khả chuyển đối với các ứng dụng đòi hỏi số client lớn Đặc biệt, một ứng dụng yêu cầu ít bean phiên phi trạng thái hơn bean phiên trạng thái để hỗ trợ cùng số client

Bean thực thể (Entity Bean)

Một bean thực thể biểu diễn một dữ liệu bền vững được sao lưu bởi một cơ

sở dữ liệu Các nhân viên, các phòng ban, và các giao dịch là những ví dụ của bean thực thể Mỗi bean thực thể có một bảng trong cơ sở dữ liệu và mỗi thể hiện của bean được lưu giữ trong một hàng của bảng Một bean thực thể không tương ứng với bất kỳ một client cụ thể nào Nó cung cấp một truy cập được chia

sẻ Nó được hỗ trợ bởi dịch vụ giao tác EJB qua trình chứa của nó Nó có một trạng thái bền vững với một định danh khóa chính duy nhất, có thể được sử dụng bởi một client để xác định vị trí một bean thực thể cụ thể

Bean hướng thông báo (Message-Driven Beans - MDB)

Một bean hướng thông báo là một enterprise bean cho phép các ứng dụng J2EE xử lý các thông điệp theo cách không đồng bộ Nó hoạt động như một bộ lắng nghe thông điệp JMS (Java Message Service), nó giống như một bộ lắng nghe sự kiện trừ khi nó nhận các thông điệp JMS theo các sự kiện Các thông điệp có thể được gửi bởi bất kì thành phần J2EE nào (các ứng dụng client, một enterprise bean khác, web thành phần) hoặc bởi một ứng dụng JMS hoặc hệ thống không sử dụng công nghệ Java Bean hướng thông báo có thể xử lý các thông điệp JMS hoặc các kiểu thông điệp khác

Bean hướng thông báo có thể làm việc theo cách khác nhau: Điểm – Điểm (Point to Point – PTP) và Nhà xuất bản/Người đăng ký (publisher/subcriber) PTP làm việc trong chế độ một – một (one – to – one) và publisher/subscriber làm việc ở trong chế độ quảng bá (một – nhiều: one – to – many) MDB làm việc trong chế độ không đồng bộ, trong đó một thông báo có thể được nhận bởi một MDB thành phần và các phản ứng của nó có thể ngay lập tức hoặc lâu hơn Một thành phần MDB làm việc theo cách sau:

- Trình chứa đăng ký thành phần MDB với JMS

- JMS đăng kí tất cả các đích JMS với JNDI

- Trình chứa EJB thể hiện thành phần MDB

- Client tìm kiếm đích với MDB

- Client gửi thông điệp đến đích

- Trình chứa EJB chọn MDB tương ứng để xử lý gói tin

Thành phần MDB làm việc trong chế độ publisher/subscriber không đồng

bộ và loại thông điệp có thể là tin nhắn văn bản, tin nhắn đối tượng, tin nhắn dòng, hoặc tin nhắn byte Các gói tin được đẩy và xử lý trong một phương thức Message Listener được gọi là onMessage()

1.2.2 Vấn đề an ninh trong công nghệ EJB

An ninh của các ứng dụng EJB bao gồm ba phần: mã hóa, chứng thực và cấp phép [10] Luận văn tập trung nghiên cứu sự cấp phép Vì vậy, phần này chỉ giới thiệu ngắn gọn về mã hóa và chứng thực Cơ chế ủy quyền của EJB, có thể được coi như một phần của sự cấp phép cũng sẽ được trình bày

Mã hóa (Cryptography)

Sự mã hóa đạt được thông qua sự hỗ trợ của kiến trúc mã hóa Java (Java Cryptography Architecture - JCA) và phần mở rộng mã hóa Java (Java Cryptographic Extension - JCE) JCA cung cấp sự hỗ trợ quy tắc thông điệp và chữ ký số Trong khi đó, JCE cung cấp sự mã hóa

Chứng thực (Authentication)

Sự chứng thực trong các ứng dụng EJB dựa trên JAAS (Java Authentication and Authorization Service) JAAS là một giao diện linh hoạt được cung cấp bởi Java 2 SDK (Software Development Kit) Nó cho phép người phát triển ứng dụng viết các mô đun chứng thực tùy biến và cung cấp thủ tục chứng thực mà không cần đến hệ thống an ninh cơ sở đang được sử dụng

Cấp phép (Authorization)

Sự cấp phép của EJB dựa trên công nghệ điều khiển truy cập dựa vai trò

Có hai cách thiết lập điều khiển truy cập bao gồm cả điều khiển truy cập chương trình và điều khiển truy cập khai báo Trong điều khiển truy cập chương trình, các nhà phát triển bean sử dụng các API để kiểm tra sự cho phép của các vai trò thực hiện các phương thức bean Việc kiểm tra được nhúng bên trong mã của các thành phần EJB Ví dụ, để kiểm tra việc người dùng gọi một phương thức

trong vai trò VIPCustomer, người phát triển bean có thể sử dụng API

EJB-Context.isCallerInRole("VIPCustomer") Hoặc, đối với việc lấy thông tin của

người dùng, có thể sử dụng API EJBContext.getCallerPrinciple() Các dòng mã

trong danh mục 1.1 cho ví dụ về sử dụng điều khiển truy cập chương trình [15]

Danh mục 1.1: Một ví dụ về điều khiển truy cập chương trình

Với điều khiển truy cập khai báo, ngược lại, các điều khiển truy cập được thiết đặt độc lập với mã bean Trong ứng dụng EJB, một tập tin (được đặt tên là

ejb-jar.xml) được dùng để xác định các chính sách điều khiển truy cập khai báo

Ví dụ, nếu một người nào đó muốn xác định chỉ những người dùng trong vai trò

VIPCustomer mới có thể thực hiện phương thức transfer() của bean TxBean,

ông ta sẽ đưa vào file ejb-jar.xml đoạn mã dưới đây (danh mục 1.2) Chính sách

trong đoạn này tương đương với đoạn mã trong danh mục 1.1 [15]

Danh mục 1.2: Một ví dụ về điều khiển truy cập khai báo

Khi các chính sách được nhúng bên trong mã EJB, cách thức chương trình

là tốt hơn so với cách thức khai báo trong việc xác định các chính sách điều khiển truy cập mịn (fine-grained) Ví dụ, trong một số ứng dụng, các nhà phát

triển ứng dụng muốn kiểm soát luồng gọi nếu vai trò thực hiện là admin sau đó

m 1 () được thi hành, nếu không m 2 () được thi hành (danh mục 1.3) Trong trường

hợp này không thể sử dụng điều khiển truy cập khai báo

Danh mục 1.3: Ví dụ trong đó bắt buộc dùng điều khiển truy cập chương

Tuy nhiên, khi các chính sách điều khiển truy cập được xác định trong một tập tin riêng biệt từ mã của các thành phần, điều khiển truy cập khai báo là linh động hơn khi so sánh với điều khiển truy cập chương trình Trong bối cảnh công nghệ dựa thành phần, điều khiển truy cập khai báo được ưa thích hơn

Ủy quyền (Principal Delegation)

Đối với lần đầu tiên một người dùng gọi một phương thức bean, sự chứng thực được thực hiện Các thông tin thu được từ việc chứng thực (được gọi là ngữ cảnh an ninh) sau đó được sử dụng cho việc ủy quyền Nếu phương thức gọi các phương thức của các bean khác, bối cảnh an ninh được truyền đến nơi được gọi

Công nghệ EJB cung cấp cơ chế ủy quyền cho người phát triển ứng dụng

để kiểm soát việc truyền ngữ cảnh an ninh Với cơ chế này, các nhà phát triển có thể xác định bất kỳ lời gọi nào từ bean cụ thể được xem như lời gọi từ vai trò được định nghĩa trước Ví dụ, với đoạn mã trong danh mục 1.4 (được xác định

trong file ejb-jar.xml), không quan tâm đến vai trò gọi phương thức transfer() của TxBean, nếu phương thức transfer() gọi bất kỳ phương thức m nào, khi đó m được xem như được gọi bởi vai trò admin Phương pháp chương trình tương

đương được thể hiện trong danh mục 1.5

Danh mục 1.5: Một ví dụ về ủy quyền bằng chương trình

1 @Runas ("admin")

Chương 2 Điều khiển truy cập dựa vai trò (RBAC) 2.1 Giới thiệu

Điều khiển truy cập là một phương tiện có khả năng cho phép hoặc hạn chế người dùng tương tác với tài nguyên Các tài nguyên có thể là một tòa nhà, một

cơ quan, hoặc một hệ thống máy tính Điều khiển truy cập, trong thực tế, là hiện tượng hàng ngày Khóa trên cửa xe là một hình thức điều khiển truy cập Số PIN trên một hệ thống ATM tại một ngân hàng là một phương tiện điều khiển truy cập khác Việc sở hữu điều khiển truy cập là việc quan trọng hàng đầu khi con người tìm kiếm sự an toàn và bảo mật cho các thông tin nhạy cảm hay các thiết

bị

Điều khiển truy cập dựa trên máy tính có thể quy định không chỉ con người hay quá trình có thể truy cập vào một tài nguyên hệ thống cụ thể, mà còn quy định loại truy cập nào là được phép

Công nghệ điều khiển truy cập được phát triển từ nghiên cứu được hỗ trợ bởi bộ quốc phòng Mỹ (DoD) Kết quả của nghiên cứu này là hai loại điều khiển truy cập cơ bản: điều khiển truy cập tùy quyền (Discretionary Access Control - DAC) và điều khiển truy cập bắt buộc (Mandatory Access Control - MAC) Nghiên cứu ban đầu tập trung giải quyết việc ngăn chặn truy cập trái phép các thông tin mật Tuy nhiên, các ứng dụng ngày nay đã áp dụng các chính sách điều khiển truy cập vào môi trường thương mại

Điều khiển truy cập tùy quyền (DAC) cho phép việc cấp và thu hồi quyền điều khiển truy cập theo quyết định của người dùng cá nhân [3] Một cơ chế DAC cho phép người dùng cấp hoặc thu hồi quyền truy cập tới bất kỳ đối tượng nào thuộc phạm vi kiểm soát của họ Như vậy, người dùng được cho là chủ sở hữu các đối tượng thuộc phạm vi kiểm soát của họ Tuy nhiên, đối với nhiều tổ chức, người dùng cuối không sở hữu các thông tin mà họ được phép truy cập Đối với các tổ chức này, tổng công ty hoặc cơ quan chủ quản là chủ sở hữu thực

sự các đối tượng hệ thống cũng như các chương trình xử lý chúng Các quyền ưu tiên truy cập được kiểm soát bởi tổ chức và thường dựa trên chức năng của nhân viên chứ không phải là quyền sở hữu dữ liệu Có hai khái niệm quan trọng trong điều khiển truy cập tùy quyền Thứ nhất là quyền sở hữu tập tin và dữ liệu (File and data ownership): bất cứ một đối tượng nào trong một hệ thống cũng phải có một chủ nhân là người sở hữu nó Chính sách truy cập các đối tượng là do chủ nhân tài nguyên quyết định, những tài nguyên bao gồm: các tập tin, các thư mục,

dữ liệu, các tài nguyên của hệ thống, và các thiết bị Theo lý thuyết, đối tượng

nào không có chủ sở hữu thì đối tượng đó bị bỏ qua, không được bảo vệ Thông thường thì chủ sở hữu của tài nguyên chính là người kiến tạo nên tài nguyên (như tập tin hoặc thư mục) Thứ hai, các quyền và phép truy cập: đây là những quyền truy cập tài nguyên mà chủ sở hữu của tài nguyên chỉ định cho mỗi một người hoặc mỗi một nhóm người dùng

Điều khiển truy cập bắt buộc (MAC) là một chính sách truy cập không do

cá nhân sở hữu tài nguyên quyết định mà do hệ thống quyết định [3] MAC được dùng trong các hệ thống đa cấp, là những hệ thống xử lý các loại dữ liệu nhạy cảm như các thông tin được phân hạng về mức độ bảo mật trong chính phủ và trong quân đội Trong hệ thống dùng điểu khiển truy cập bắt buộc, hệ thống chỉ định một nhãn nhạy cảm (sensitivity label) cho mỗi chủ thể và mỗi đối tượng trong hệ thống Nhãn nhạy cảm của một chủ thể xác định mức tin cậy cần thiết

để truy cập Để truy cập một đối tượng nào đấy, chủ thể phải có một mức độ nhạy cảm tương đương hoặc cao hơn mức độ của đối tượng yêu cầu Việc điều khiển xuất/nhập thông tin (bao gồm cả các máy in) là một chức năng trọng yếu trong các hệ thống sử dụng điều khiển truy cập bắt buộc Nhiệm vụ của việc xuất/nhập thông tin là phải đảm bảo các nhãn nhạy cảm được giữ gìn một cách đúng đắn và nhiệm vụ này phải được thực hiện sao cho các thông tin nhạy cảm phải được bảo vệ trong bất kỳ tình huống nào

Những chính sách điều khiển truy cập này không đặc biệt thích hợp với yêu cầu của các tổ chức xử lý các thông tin nhạy cảm nhưng không được phân loại Điều khiển truy cập dựa vai trò (Role-Based Access Control - RBAC) khác với hình thức MAC và DAC truyền thống MAC và DAC trước đây là hai mô hình duy nhất được phổ biến trong điều khiển truy cập Nếu một hệ thống không dùng MAC thì người ta chỉ có thể cho rằng hệ thống đó dùng DAC, hoặc ngược lại Song các nghiên cứu trong những năm 1990 đã chứng minh rằng RBAC không phải là MAC hoặc DAC Hình 2.1 so sánh sự khác nhau giữa phương pháp điều khiển truy cập truyền thống và phương pháp điều khiển truy cập dựa vai trò

Với điều khiển truy cập dựa vai trò, các quyết định truy cập dựa trên vai trò

mà người dùng cá nhân có như là một phần của một tổ chức.Vai trò liên quan chặt chẽ đến khái niệm của nhóm người dùng trong điều khiển truy cập Tuy nhiên giữa hai khái niệm “vai trò” và “nhóm người dùng” vẫn có sự khác biệt Các nhóm người dùng như một đơn vị điều khiển truy cập thường được nhiều hệ thống điều khiển truy cập cung cấp Nhóm người dùng thường được xem như như một tập hợp người dùng chứ không phải là một tập hợp các quyền hạn (permission) Một vai trò một mặt vừa là một tập hợp người dùng mặt khác lại là

một tập hợp các quyền hạn Vai trò đóng vai trò trung gian để kết nối hai tập hợp này lại với nhau

Hình 2.1: Điều khiển truy cập truyền thống và Điều khiển truy cập dựa vai trò

Ý tưởng cơ bản của RBAC là người dùng (user) được gắn với các vai trò (role) và các vai trò lần lượt được giao quyền (permission) Kết quả là sự đơn giản của các quyền quản lý Trong nội bộ một tổ chức, các vai trò (roles) được kiến tạo để đảm nhận các chức năng công việc khác nhau Mỗi vai trò được gắn liền với một số quyền hạn (permissions) cho phép nó thao tác một số hoạt động

cụ thể Những người dùng trong hệ thống được phân phối một vai trò riêng, và thông qua việc phân phối vai trò này mà họ tiếp thu được một số những quyền hạn cho phép họ thi hành những chức năng cụ thể trong hệ thống

Vì người dùng không được cấp phép một cách trực tiếp, chỉ nhận được những quyền hạn thông qua vai trò (hoặc các vai trò) của họ, việc quản lý quyền hạn của người dùng trở thành một việc đơn giản, và người ta chỉ cần chỉ định những vai trò thích hợp cho người dùng mà thôi Việc chỉ định vai trò này đơn giản hóa những công việc thông thường như việc thêm một người dùng vào hệ thống, hay thay đổi đơn vị công tác (department) của người dùng

RBAC khác với các danh sách điểu khiển truy cập (Access Control List - ACL) được dùng trong hệ thống điều khiển truy cập tùy quyền, ở chỗ, nó chỉ định các quyền hạn tới từng hoạt động cụ thể trong cơ quan tổ chức, thay vì tới các đối tượng dữ liệu hạ tầng Lấy ví dụ, một danh sách điều khiển truy cập có thể được dùng để cho phép hoặc từ chối quyền truy cập viết một tập tin hệ thống (system file), song nó không nói cho ta biết phương cách cụ thể để thay đổi tập tin đó Trong một hệ thống dùng RBAC, một thao tác có thể là việc một chương trình ứng dụng tài chính kiến tạo một giao dịch ngân hàng Việc chỉ định quyền hạn cho phép thi hành một thao tác nhất định và mỗi cá nhân thao tác có một ý nghĩa riêng trong chương trình ứng dụng

Việc sử dụng RBAC để quản lý các đặc quyền của người dùng trong một

hệ thống duy nhất hay trong một chương trình ứng dụng là một thực hành tốt nhất được chấp thuận rộng rãi Các hệ thống bao gồm Active Directory của Microsoft, SELinux, Oracle DBMS, PostgreSQL 8.1, SAP R/3 và nhiều hệ thống khác hầu như đều thực thi một trong những hình thức của RBAC

2.2 Mô hình RBAC

Mô hình tham chiếu RBAC xác định một tập hợp các thành phần mô hình

Nó định nghĩa một tập các phần tử RBAC cơ bản: users (người dùng), roles (vai trò), permissions (quyền hạn), operations (hoạt động), objects (các đối tượng), các quan hệ và các chức năng

Mô hình tham chiếu NIST RBAC được định nghĩa trong bốn thành phần

mô hình [4] [5] [12]: RBAC cơ sở (Core RBAC), RBAC phân cấp (Hierarchical RBAC), RBAC ràng buộc tĩnh (Static Separation of Duty Relations) và RBAC ràng buộc động (Dynamic Separation of Duty Relations) Ngoài ra, mô hình RBAC hợp nhất (RBAC3) là tổng hợp các mô hình trên

2.2.1 Mô hình RBAC cơ sở

Mô hình RBAC cơ sở (còn gọi là RBAC0) bao gồm các tập phần tử và mối quan hệ được định nghĩa trong hình 2.2 RBAC cơ sở gồm tập năm phần tử dữ liệu cơ bản được gọi là người dùng (USERS), vai trò (ROLES), các đối tượng (OBS), các hoạt động (OPS), và các quyền hạn (PRMS) Mô hình RBAC cơ sở

có tất cả những thành phần cơ bản được quy định như người dùng cá nhân được phân công vào các vai trò và các quyền hạn được giao cho các vai trò Như vậy, vai trò là một phương tiện cho việc đặt tên cho các mối quan hệ nhiều-nhiều giữa người dùng cá nhân và quyền hạn Ngoài ra, mô hình RBAC cơ sở bao gồm một tập các phiên làm việc (SESSIONS), mỗi phiên làm việc là một ánh xạ giữa một người dùng và một tập con các vai trò được phân công cho người dùng

Hình 2.2: Mô hình RBAC 0

Người dùng (user) trong mô hình là người dùng hệ thống Khái niệm người dùng sẽ được khái quát hóa bao gồm cả các tác nhân thông minh và chủ thể khác như robot, máy tính, thậm chí là cả các mạng máy tính Để đơn giản, phần này tập trung vào người dùng là con người

Vai trò (role) là một chức năng công việc trong ngữ cảnh của một tổ chức với một số ngữ nghĩa có liên quan về quyền hạn và trách nhiệm

Quyền hạn (permission) được phê duyệt để thực hiện một hoạt động trên một hoặc nhiều đối tượng được bảo vệ

Một hoạt động là một chương trình có khả năng thực hiện khi có lời gọi thực thi một số chức năng cho người dùng Các kiểu hoạt động và các đối tượng

mà RBAC điều khiển phụ thuộc vào kiểu hệ thống trong đó chúng sẽ được thực thi Ví dụ, trong một hệ thống tập tin, các hoạt động có thể là đọc, viết và thực hiện; trong một hệ quản trị cơ sở dữ liệu, các hoạt động có thể là thêm, xóa, và cập nhật

Mục đích của bất kỳ cơ chế điều khiển truy cập nào là để bảo vệ tài nguyên

hệ thống Tuy nhiên, trong việc ứng dụng RBAC vào một hệ thống máy tính, chúng ta nói về các đối tượng được bảo vệ Phù hợp với các mô hình điều khiển truy cập trước đây, một đối tượng là một thực thể chứa hoặc nhận thông tin Đối với một hệ thống thực hiện RBAC, các đối tượng có thể đại diện cho các trình chứa thông tin (như các tập tin hoặc thư mục trong một hệ điều hành, và/hoặc các cột, các hàng, các bảng biểu, trong một hệ quản trị cơ sở dữ liệu) hoặc các đối tượng có thể đại diện cho tài nguyên hệ thống như máy in, không gian đĩa, Tập các đối tượng được bảo vệ bởi RBAC bao gồm tất cả các đối tượng được liệt kê trong các quyền hạn được giao cho các vai trò

Trọng tâm của RBAC là khái niệm về các mối quan hệ vai trò, một vai trò

là một cấu trúc ngữ nghĩa cho việc xây dựng chính sách Hình 2.2 minh họa mối quan hệ người dùng-vai trò (UA) và mối quan hệ quyền hạn-vai trò (PA) Các mũi tên cho biết mối quan hệ nhiều-nhiều (ví dụ, một người sử dụng có thể được phân công vào một hoặc nhiều vai trò, và một vai trò có thể được giao cho một hoặc nhiều người dùng) Sự sắp xếp này cung cấp sự linh hoạt và chi tiết của việc giao quyền hạn cho vai trò và người dùng với vai trò Nếu không có những mối quan hệ này, có thể người dùng được cấp nhiều quyền truy cập hơn cần thiết vì việc điều khiển bị giới hạn bởi các kiểu truy cập mà có thể được liên kết với người dùng và các nguồn lực Người dùng có thể cần danh sách các thư mục

và sửa đổi các tập tin hiện có, ví dụ, không cần tạo các tập tin mới, hoặc họ có thể cần phải thêm bản ghi vào một tập tin mà không sửa đổi bản ghi hiện có

Việc tăng tính linh hoạt cho việc điều khiển truy cập tài nguyên cũng làm tăng tính ứng dụng của nguyên tắc quyền tối thiểu

Mỗi phiên là một ánh xạ của một người dùng tới các vai trò có thể, một người dùng thiết lập một phiên trong đó người dùng kích hoạt một số tập con của vai trò mà họ được phân công Mỗi phiên được liên kết với một người dùng duy nhất và mỗi người dùng kết hợp với một hoặc nhiều phiên

Định nghĩa của RBAC cơ sở như sau:

- USERS, ROLES, OPS, và OBS (users, roles, operations, và objects,

tương ứng)

- UA ⊆ USERS × ROLES, là quan hệ nhiều-nhiều của tập người dùng đối

với tập vai trò, một người dùng có thể có nhiều vai trò, một vai trò có thể có nhiều người dùng

- assigned_users(r:ROLES) → 2 USERS , ánh xạ của vai trò r trên một tập người dùng: assigned_users(r) = {u∈ USERS | (u, r )∈ UA}

- PRMS = 2 (OPS × OBS), tập các quyền hạn

- PA ⊆ PRMS × ROLES, là quan hệ nhiều-nhiều của tập quyền đối với

tập vai trò, một vai trò có thể được cấp nhiều quyền, một quyền có thể được cấp cho nhiều vai trò

- assigned_permissions(r: ROLES) → 2 PRMS , ánh xạ của vai trò r lên một tập các quyền hạn: assigned_permissions(r) = {p∈ PRMS | (p,r) ∈

PA}

- Ob(p: PRMS) → {op ⊆ OPS}, ánh xạ quyền hạn tới hoạt động, một tập

các hoạt động liên kết với quyền p

- Ob(p: PRMS) → {ob ⊆ OBS}, ánh xạ quyền hạn tới đối tượng, một tập

các đối tượng liên kết với quyền p

- avail_session_perms(s: SESSIONS) → 2 PRMS, các quyền hạn có thể đối với một người dùng trong một phiên

2.2.2 RBAC phân cấp

RBAC phân cấp (còn gọi là RBAC1) thêm khái niệm về phân cấp vai trò vào RBAC0 Đó là những vai trò có quyền thừa kế từ các vai trò khác Ví dụ,

nếu vai trò r2 được thừa kế từ r1, và r1 có quyền thiết lập p1 khi đó r2 cũng sẽ có quyền thiết lập p1 (và các quyền khác) Hình 2.3 biểu diễn mô hình RBAC phân cấp

Hình 2.3: Mô hình RBAC 1

Phân cấp vai trò (Role Hierarchy - RH) định nghĩa một quan hệ kế thừa giữa các vai trò, sự kế thừa đó được miêu tả bên trong các nhóm quyền Trong một vài cài đặt cụ thể của RBAC, các quyền không được quản lý một cách tập trung, trong khi đó RH lại được quản lý tập trung Với các hệ thống đó, RH được quản lý bên trong các nhóm người dùng chứa đựng các quan hệ, vai trò r1 chứa đựng vai trò r2 nếu như tất cả người dùng được xác thực cho r1 cũng là những người dùng được xác thực cho r2 Chú ý rằng, một người dùng của r1 có tất cả các quyền của r2, trong khi sự kế thừa quyền cho r1 và r2 không nói đến bất

cứ điều gì về phân công người dùng (User Assignment)

Có hai kiểu RH đó là: General Role Hierarchies (RH tổng quát) và Limited Role Hierarchies (RH giới hạn)

RH tổng quát hỗ trợ định nghĩa đa kế thừa (multiple inheritance) Điều này

có nghĩa là nó cung cấp khả năng kế thừa quyền cũng như việc kế thừa người dùng từ hai hay nhiều vai trò nguồn

- RH Í ROLES × ROLES được gọi là quan hệ kế thừa, viết tắt là ,

r1 r2 chỉ khi tất cả các quyền của r2 cũng là các quyền của r1 và tất cả người sử dụng của r1 cũng là những người sử dụng của r2 r1 r2 Þ

- authorized_permissions(r: ROLES) → 2 PRMS , ánh xạ vai trò r lên trên

một tập các quyền trong sự hiện diện của một RH

Giống như một yếu tố an ninh cơ bản, SoD đã được công nhận một cách rộng rãi cho các ứng dụng trong kinh doanh, các ngành công nghiệp và chính phủ Mục đích của nó là để đảm bảo rằng các sai sót và gian lận bên trong một

tổ chức chỉ là kết quả của việc thông đồng giữa các cá nhân Để giảm thiểu khả năng thông đồng, các cá nhân thuộc các nhóm kỹ năng khác nhau hoặc lợi ích khác nhau được phân công nhiệm vụ cần thiết và riêng biệt trong việc thực hiện các chức năng của một doanh nghiệp Động lực ở đây chính là để đảm bảo rằng các sai sót và gian lận không xảy ra và cũng không có việc thông đồng của nhiều người sử dụng Mô hình RBAC2 cho phép cả SoD tĩnh (Static Separation of Duty Relations - SSD) và SoD động (Dynamic Separation of Duty Relations - DSD)

Chúng ta biết rằng trong một hệ thống RBAC, một người sử dụng có thể ở trong một hoặc nhiều vai trò khác nhau Như vậy, một câu hỏi đặt ra là liệu có

sự xung đột về lợi ích của người sử dụng không trong trường hợp họ ở trong hai vai trò khác nhau mà hai vai trò này lại mâu thuẫn với nhau? Câu trả lời là điều này hoàn toàn có thể xảy ra Giả sử, trong một ngân hàng, để thực hiện một giao dịch rút tiền từ tài khoản khách hàng Hành động này cần hai vai trò cùng thực hiện, vai trò giao dịch viên thực hiện giao dịch và kiểm soát viên thực hiện phê duyệt giao dịch Khi đó giao dịch rút tiền mới có thể hoàn tất Rõ ràng, trong ví

dụ này, giao dịch viên và giám sát viên là hai vai trò xung đột nhau và trong thực tế không thể có chuyện một người vừa là giao dịch viên vừa là kiểm soát viên

SSD được đưa ra để giải quyết các vấn đề xung đột lợi ích như đã nói ở trên Mô hình tổng quát các SoD tĩnh được minh họa trong hình 2.4

Hình 2.4: Mô hình SSD

SSD ⊆ (2ROLES

× N) là một tập hợp của cặp (rs, n) trong SoD tĩnh, trong đó mỗi rs là một tập vai trò, t là một tập con của rs, và n là một số tự nhiên ≥ 2, với thuộc tính là không có người dùng nào được gán tới n hoặc nhiều hơn các vai trò

SoD động cũng giống SoD tĩnh ở chỗ cả hai đều được sử dụng để giới hạn các quyền có thể được cung cấp đến người dùng Tuy nhiên, DSD khác với các quan hệ SSD ở ngữ cảnh mà trong đó những ràng buộc đó được áp đặt SSD định nghĩa và đặt các ràng buộc dựa vào tổng số quyền của người sử dụng, còn DSD lại đặt các ràng buộc lên các vai trò có thể được kích hoạt trong một phiên làm việc của người sử dụng DSD cho phép một người dùng được xác thực cho hai hoặc nhiều vai trò mà không tạo ra xung đột lợi ích giữa các vai trò khi chúng hoạt động độc lập Điều này có nghĩa rằng nếu một vai trò thuộc một quan hệ DSD được kích hoạt trong phiên làm việc của người sử dụng thì các vai trò có liên quan khác không thể được kích hoạt trong cùng một phiên làm việc

đó Mô hình tổng quát của các quan hệ DSD được minh họa như trong hình 2.5