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

ĐẠI HỌC QUỐC GIA HÀ NỘI
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
DỰA THÀNH PHẦN


Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 60 48 10


LUẬN VĂN THẠC SĨ



NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. Nguyễn Việt Hà



Hà Nội - 2011
iii

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
iv


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 RBAC
0
17
Hình 2.3: Mô hình RBAC
1
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 RBAC
3
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
v


Danh mục ký hiệu, từ viết tắt
Từ viết tắt Thuật ngữ
ACL Access Control List
API Application Programming Interface
AS Application Server
BMP Bean Managed Persistence
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
DD Deployment Descriptor
DSD Dynamic Separation of Duty
DTD Document Type Definition

EJB Enterprise JavaBeans
IDL Interface Definition Language
J2EE Java 2 Enterprise Edition
JAAS Java Authentication and Authorization Service
JCA Java Cryptography Architecture
JCE Java Cryptographic Extension
JMS Java Message Service
JNDI Java Naming and Directory Interface
MAC Mandatory Access Control
MDB Message–Driven Bean
vi

MTS Microsoft Transaction Server
OLE Object Linking and Embedding
OMG Object Management Group
PTP Point to Point
RBAC Role-Based Access Control
RPC Remote Procedure Call
SDK Software Development Kit
SoD Separation of Duty
SSD Static Separation of Duty
TLS Transport Layer Security
UML Unified Modeling Language
VMC Model View Controller
WORA Write Once Run Anywhere
XML eXtensible Markup Language

1

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
2

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.


3

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.

4

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

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

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

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


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
9

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
10

(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.
11

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
1 public class TxBean {
2 EJBContext ctx;
3
4 public void transfer(int from, int to, double amount){
12

5 if(!ctx.isCallerInRole("VIPCustomer")){
6 throw new SecurityException(c);
7 }
8 // transfer money
9
10 }
11
12 }
Trong đoạn mã trên, chỉ có vai trò VIPCustomer được phép thực hiện
phương thức transfer() của TxBean. Nếu bất kỳ vai trò nào khác thực hiện
phương thức này, một bắt lỗi an ninh sẽ phát sinh. Như có thể thấy, với phương
pháp này (tức là phương pháp dùng chương trình) các chính sách điều khiển truy
cập được đặt bên trong mã EJB.
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

1 <method-permission>

2 <role-name> VIPCustomer </role-name>
3 <method>
4 <ejb-name> TxBean </ejb-name>
5 <method-name> transfer </method-name>
6 </method>
7 </method-permission>
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
trình

1 if(ctx.isCallerInRole("admin") {
2 m
1
();
3 } else {
4 m
2
();
5 }
13

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ấp phép.
Danh mục 1.4: Một ví dụ của cơ chế ủy quyền
1 <session>
2 <ejb-name> TxBean </ejb-name>
3
4 <security-identity>
5 <run-as>
6 <role-name> admin </role-name>
7 </run-as>
8 </security-identity>
9
9 </session>
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")
2 public class TxBean {
3
4 }

14

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
15

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

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

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 (RBAC
3
) 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à RBAC
0
) 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

18

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

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.
- SESSIONS, tập các phiên.
- user_sessions(u: USERS) → 2
SESSIONS
, ánh xạ của người dùng u tới một
tập các phiên.
- session_roles(s: SESSIONS) → 2

ROLES
, ánh xạ của phiên s trên một tập
các vai trò: session_roles(s
i
)
⊆
{r
∈
ROLES | (session_users(s
i
), r)
∈

UA}.
- 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à RBAC
1
) thêm khái niệm về phân cấp vai trò
vào RBAC
0
. Đó là những vai trò có quyền thừa kế từ các vai trò khác. Ví dụ,
20

nếu vai trò r
2
được thừa kế từ r

1
, và r
1
có quyền thiết lập p
1
khi đó r
2
cũng sẽ có
quyền thiết lập p
1
(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ò r
1

chứa đựng vai trò r
2
nếu như tất cả người dùng được xác thực cho r
1
cũng là
những người dùng được xác thực cho r
2

. Chú ý rằng, một người dùng của r
1
có
tất cả các quyền của r
2
, trong khi sự kế thừa quyền cho r
1
và r
2
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à ,
r
1
r
2
chỉ khi tất cả các quyền của r
2
cũng là các quyền của r
1
và tất cả
người sử dụng của r
1

cũng là những người sử dụng của r
2
. r
1
r
2
Þ
authorized_permissions(r
2
)
⊆
authorized_permissions(r
1
).
- authorized_users(r: ROLES) → 2
USERS
, ánh xạ vai trò r lên trên một tập
người dùng trong sự hiện diện của một RH, authorized_users(r) = {u
Í

USERS | r’ r , (u, r’)
Í
UA}.