Nghiên cứu về điều khiển truy cập sử dụng mô hình RBAC mở rộng

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ



NGUYỄN ÁNH NGUYỆT



NGHIÊN CỨU VỀ ĐIỀU KHIỂN TRUY CẬP SỬ DỤNG MÔ
HÌNH RBAC MỞ RỘNG




LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN






Hà Nội, 2013



ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN ÁNH NGUYỆT


NGHIÊN CỨU VỀ ĐIỀU KHIỂN TRUY CẬP SỬ DỤNG MÔ
HÌNH RBAC MỞ RỘNG


Ngành: Công nghệ thông tin
Chuyên ngành: Hệ thống thông tin
Mã số: 60.48.05

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN


NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS. NGUYỄN VIỆT HÀ



Hà Nội, 2013

1

MỤC LỤC
MỤC LỤC 1
Danh mục hình vẽ 3
Danh mục bảng 4
Danh mục ký hiệu, từ viết tắt 5
MỞ ĐẦU 6

Chương 1. ĐIỀU KHIỂN TRUY CẬP THEO VAI TRÒ 8
1.1 Điều khiển truy cập 8
1.1.1 Điều khiển truy cập bắt buộc 8
1.1.2 Điều khiển truy cập tuỳ quyền 9
1.1.3 Điều khiển truy cập theo vai trò 9
1.1.4 Điều khiển truy cập theo luật 9
1.2 Các mô hình tham chiếu RBAC 10
1.2.1 Mô hình RBAC cơ sở 10
1.2.2 RBAC phân cấp 12
1.2.3 RBAC ràng buộc 14
1.2.4 Ưu nhược điểm của RBAC 16
1.3 Định danh dựa trên tuyên bố (Claims-based identity) 17
1.3.1 Tuyên bố (Claim) 17
1.3.2 Định danh (Identiy) 17
1.3.3 Principal 17
1.4 RBAC TRONG .NET FRAMEWORK 17
1.4.1 Kiểm tra vai trò dựa trên khai báo 18
1.4.2 Kiểm tra vai trò trong mã nguồn 18
1.4.3 RBAC với ứng dụng ASP.NET 18
1.4.4 RBAC với ứng dụng ASP.NET MVC 19
1.4.5 Các hạn chế của RBAC trong .Net Framework 20
Chương 2. MỞ RỘNG ĐIỀU KHIỂN TRUY CẬP RBAC VỚI LUẬT 21

2

2.1 Đặc tả điều khiển truy cập RBAC 21
2.2 Điều khiển truy cập theo luật 22
2.3 Mở rộng điều khiển truy cập RBAC với luật 25
2.4 Khiển khai RBAC mở rộng với luật 27
2.4.1 Kiến trúc tổng quát 27

2.4.2 Biểu đồ thành phần 29
2.4.3 Biểu đồ lớp 30
2.4.4 Biểu diễn và lượng giá luật với cây biểu thức 36
2.4.5 Authorization API 38
Chương 3. ỨNG DỤNG 41
3.1 Bài toán chia sẻ tệp 41
3.2 Phân tích, thiết kế hệ thống 42
3.2.1 Hiện trạng hệ thống 42
3.2.2 Phân tích hoạt động hệ thống 42
3.2.3 Lựa chọn nền tảng, công nghệ 43
3.2.4 Kiến trúc ứng dụng 43
3.2.5 Biểu đồ lớp 45
3.2.6 Biểu đồ trình tự 46
3.2.7 Điều khiển truy cập trong trong ứng dụng chia sẻ tệp 51
KẾT LUẬN 57
TÀI LIỆU THAM KHẢO 59


3

Danh mục hình vẽ
Hình 1.1: Mô hình RBAC [4] 11
Hình 1.2: Mô hình RBAC [4] 13
Hình 1.3: Mô hình SSD với RBAC phân cấp [4] 15
Hình 1.4 : Mô hình DSD [4] 15
Hình 2.1: Kiến trúc tổng quát 28
Hình 2.2: Biểu đồ thành phần 29
Hình 2.3: Biểu đồ lớp ClaimMembershipProvider 31
Hình 2.4: Biểu đồ lớp Authentication 32
Hình 2.5: Biểu đồ lớp Authorization 35

Hình 2.6: Logic điều khiển truy cập 39
Hình 3.1: Biểu đồ use case 43
Hình 3.2: Kiến trúc ứng dụng chia sẻ tệp 44
Hình 3.3: Biểu đồ lớp 45
Hình 3.4: Biểu đồ trình tự Hiển thị nội dung thư mục 46
Hình 3.5: Biểu đồ trình tự Tạo thư mục 47
Hình 3.6: Biểu đồ trình tự Upload file 47
Hình 3.7: Biểu đồ trình tự Download file 48
Hình 3.8: Biểu đồ trình tự Xóa thư mục, tệp 48
Hình 3.9: Biểu đồ trình tự Hiển thị danh sách người dùng 48
Hình 3.10: Biểu đồ trình tự Tạo người dùng 49
Hình 3.11: Biểu đồ trình tự Cập nhật thông tin người dùng 50
Hình 3.12: Biểu đồ trình tự Xóa người dùng 50

4

Danh mục bảng
Bảng 2.1: Ý nghĩa các thẻ trong đặc tả truy cập RBAC 22
Bảng 2.2: Ý nghĩa các thẻ trong đặc tả truy cập theo luật 25
Bảng 2.3: Ý nghĩa các giao diện, module 30
Bảng 2.4: Ý nghĩa các giao diện, lớp trong trong module ClaimMembership 31
Bảng 2.5: Ý nghĩa các giao diện, lớp trong module Authentication 32
Bảng 2.6: Ý nghĩa các giao diện, lớp trong module Authorization 35
Bảng 3.1: Ý nghĩa các lớp trong ứng dụng chia sẻ tệp 46


5

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

Thuật ngữ
ACL
Access Control List
MAC
Mandatory Access Control
DAC
Discretionary Access Control
SoD
Separation of Duty
SSD
Static Separation of Duty
DSD
Dynamic Separation of Duty
RBAC
Role-Based Access Control
RBAC
Rule-Based Access Control
CSDL
Cơ sở dữ liệu
URL
Uniform Resource Locator
XML
eXtensibleMarkup Language
MVC
Model View Controller
EJB
Enterprise JavaBeans


6

MỞ ĐẦU
Các hệ thống phần mềm thường có nhiều người sử dụng, mỗi người sử dụng
lại có các vai trò khác nhau, hay nói cách khác họ có tập các đặc quyền khác
nhau. Vì thế cần đảm bảo rằng mỗi người sử dụng chỉ có thể thực hiện được
các tác vụ mà họ có đặc quyền.Do đó, vấn đề đảm bảo an ninh trong các ứng
dụng là một trong các yêu cầu quan trọng, cần quan tâm xem xét.
Truy cập là khái niệm để nói đến khả năng thực hiện một tác vụ nào đó (sử
dụng, đọc, thay đổi…) của một chủ thể (subject/user) với một tài nguyên máy
tính (resource).Điều khiển truy cập (access control) là khái niệm để chỉ sự cho
phép hay hạn chế sự truy cập của chủ thể với tài nguyên máy tính dưới một
cách thức nào đó[6].
Kiểm soát truy cập là thuật ngữ dễ gây hiểu nhầm, trong một số trường hợp
nó được hiểu như sự kiểm soát quyền truy cập vào hệ thống từ bên ngoài (ví
dụ như kiểm soát quá trình đăng nhập, qua đó người dùng được truy cập vào
vào máy chủ hay máy cá nhân).Trong thực tế, kiểm soát truy cập như vậy
được gọi là xác thực (authenticate) người dùng.Trong khi, kiểm soát truy cập
đề cập đến việc kiểm soát quyền truy cập vào tài nguyên hệ thống sau khi
thông tin tài khoản của người dùng đã được xác thực. Ví dụ, một người dùng
cụ thể, hoặc một nhóm người sử dụng, chỉ có thể được phép truy cập vào các
tập tin nhất định sau khi đã đăng nhập hệ thống, trong khi đồng thời bị từ chối
quyền truy cập vào tất cả các tài nguyên khác.
Với điều khiển truy cập theovai trò (Role Based Access Control – RBAC)[4],
mỗi người sử dụng sẽ được gán một hoặc nhiều vai trò, mỗi vai trò có một tập
các quyền truy xuất. Quyền truy cập của mỗi người dùng là hợp các tập quyền
truy xuất của tất cả các vai trò mà người sử dụng hiện đang thuộc về.
RBAC là một phương pháp đơn giản, trực quan và hiệu quả, song nó vẫn còn
những hạn chế, chẳng hạn như khi có hai người sử dụng có cùng một vai trò,
nhưng quyền truy xuất khác nhau, do có các thông tin ngữ cảnh khác nhau. Vì
thế ta cần bổ sung thêm thông tin ngữ cảnh khi ra quyết định cho phép hay từ

chối truy cập.Trên các Framework như EJB hay .Net Framework đều hỗ trợ
RBAC, tuy nhiên khi cần điều khiển truy cập theo vai trò kết hợp với các
thông tin ngữ cảnh khác của người dùng thì mỗi ứng dụng phải tự xây dựng
module điều khiển truy cập, việc này nghĩa là ngoài việc cài đặt nghiệp vụ của

7

ứng dụng, họ còn phải lo phần bảo mật của ứng dụng. Việc tự cài đặt module
điều khiển truy cập có thể bị sai sót, dẫn đến các kết quả đáng tiếc.Do vậy, tác
giả đã đề xuất phương pháp mở rộng RBAC theo ngữ cảnh bằng phương sử
dụng luật và triển khai đề xuất trên .Net Framework. Theo đó, các ứng dụng
sẽ không cần phải xây dựng module điều khiển truy cập riêng, mà chỉ cần mô
tả tài nguyên cần bảo vệ trong chương trình và định nghĩa các vai trò, các luật
trong file điều khiển truy cập.
Bố cục của luận văn như sau:
Chương 1, luận văn nghiên cứu phương pháp điều khiển truy cập theovai trò,
các mô hình điều khiển truy cập RBAC. Phân tích ưu, nhược điểm của
RBAC.
Chương 2, luận văn giới thiệu về điều khiển truy cập trong .Net Framework,
các hạn chế của điều khiển truy cập trong .Net Framework.
Chương 3, luận văn đề xuất một đặc tả truy cập dựa trên tệpmô tả, đặc tả truy
cập dựa trên luật, đề xuất đặc tả cho phép mở rộng RBAC theo ngữ cảnh bằng
cách kết hợp giữa đặc tả truy cập RBAC với luật.Cũng trong chương này luận
văn đề xuất giải pháp triển khai đặc tả RBAC mở rộng với luật.
Chương 4, luận văn đề xuất một ứng dụng thực tế sử dụng RBAC mở rộng
như một demo cho phần triển khai RBAC mở rộng.

8

Chương 1. ĐIỀU KHIỂN TRUY CẬP THEO VAI TRÒ

1.1 Điều khiển truy cập
Điều khiển truy cập là một phương thức dùng để hạn chế hoặc cho phép
người dùng thực hiện thao tác nào đó trên tài nguyên[4]. Các tài nguyên ở đây
được hiểu theo nghĩa rộng, nó có thể là các mục dữ liệu trong CSDL, tệp, máy
in v.v. Các thao tác có thể là đọc, ghi, cập nhật v.v.
Điều khiển quyền truy cập bao gồm các bước cơ bản:
 Định danh người dùng (Identification): bước này xác định người dùng
hệ thống là ai thông qua việc đưa ra thông tin định danh như username,
số chứng minh thư nhân dân…
 Xác thực người dùng (Authentication): bước này xác định xem người
dùng có thực sự có định danh như bước trước hay không thông qua
việc đưa ra thông tin xác thực như mật khẩu, vân tay mà chỉ người
dùng đó biết hoặc sở hữu.
 Kiểm soát quyền truy cập (Authorization): bước này xác định xem
người dùng được làm gì trong hệ thống.
Có nhiều phương pháp điều khiển truy cập khác nhau, song chúng được chia
thành hai loại cơ bản: điều khiển truy cập bắt buộc (Mandatory Access
Control - MAC) vàđiều khiển truy cập tuỳ quyền (Discretionary Access
Control - DAC)[4].
1.1.1 Điều khiển truy cập bắt buộc
Điều khiển truy cập bắt buộc là khắt khe nhất trong tất cả các cấp kiểm
soát[6]. Ban đầu MAC được thiết kế để sử dụng bởi chính phủ. MAC có một
cách tiếp cận phân cấp để kiểm soát truy cập vào các nguồn tài nguyên. Với
MAC, việc điều khiển truy cập tới tất cả các tài nguyên hệ thống được thiết
lập bởi người quản trị hệ thống, hay nói cách khác người dùng không có khả
năng thay đổi quyền truy cập trên các tài nguyên hệ thống.
Trong MAC, mỗi đối tượng trong hệ thống được gán một mức nhạy cảm.
Mức nhạy cảm của một chủ thể xác định khả năng truy cập của chủ thể.Để
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.

9

1.1.2 Điều khiển truy cập tuỳ quyền
Với MAC, điều khiển truy cập được thiết lập bởi quản trị viên hệ thống
(system administrator), thì vớiDAC, điều khiển truy cập trên một tài nguyên
được thiết lập bởi người chủ của tài nguyênđó. DAC là cơ chế kiểm soát truy
cập mặc định cho hầu hết các hệ điều hành máy tính cá nhân[6].
Trong DAC, mỗi tài nguyên hệ thống có một danh sách truy cập (Access
Control List-ACL). ACL chứa danh sách người dùng, nhóm và quyền truy
xuất cho mỗi người dùng, nhóm đó. Ví dụ, người dùngA có quyền read-only,
người dùng có quyền read và write, nhóm quản trị có toàn quyền.
Cơ chế của DAC linh hoạt hơn nhiều so với MAC, nhưng cũng làm tăng nguy
cơ mất an toàn do không được quản lý tập trung bởi quản trị viên hệ thống.
1.1.3 Điều khiển truy cập theo vai trò
Với điều khiển truy cậptheo vai trò, các quyết định truy cập dựa trên vai trò
(role) mà người dùng thuộc về.Ví dụ, một kế toán trong một công ty sẽ được
giao cho vai trò kế toán, được phép thực hiện các công việc liên quan đến kế
toán.Tương tự như vậy, một kỹ sư phần mềm có thể được giao cho các vai trò
nhà phát triển[6].
Khái niệm vai trò ở đây có điểm tương đồng với khái niệm nhóm.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, trong khi 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.
Trong RBAC mỗi người dùng được gắn với các vai trò, các vai trò được gán
một tập quyền. Dongười dùng không được cấp phép quyền 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.
1.1.4 Điều khiển truy cập theo luật

Điều khiển truy cập theo luật (Rule Based Access Control), quyết định cho
phép hay từ chối truy cập được xác định bởi một tập các luật (rules) được
định nghĩa bởi quản trị hệ thống. Tương tự như DAC, mỗi tài nguyên hệ
thống sẽ có một danh sách các luật, khi người dùng truy cập đến tài nguyên,

10

hệ thống sẽ kiểm tra tất cả các luật trên tài nguyên đó để quyết định cho phép
hay từ chối truy cập. Tương tự như MAC, người dùng không thể thay đổi
được luật (quyền truy cập), chỉ có quản trị hệ thống mới có thể thay đổi được
tập luật trên mỗi tài nguyên[6].
1.2 Các mô hình tham chiếu RBAC
Các mô hình tham chiếu RBAC bao gồm các phần tử cơ bản:
- User (người dùng)
- Role (vai trò)
- Objects (các đối tượng): Là những đối tượng mà người dùng muốn truy
xuất, ta còn gọi Object là những tài nguyên hệ thống (system resource).
Ví dụ, như tệp, máy in, bản ghi trong cơ sở dữ liệu…
- Operations (thao tác): Là các thao tác mà người dùng thực hiện trên
Object. Ví dụ như read, write, print…
- Permissions (quyền hạn): Quyền thực thi Operation của chủ thể trên
Object.
Có bốn mô hình tham chiếu RBAC:
- RBAC cơ sở (Core RBAC),
- RBAC phân cấp (Hierarchical RBAC),
- RBAC ràng buộc tĩnh (Static Separation of Duty Relations)
- RBAC ràng buộc động (Dynamic Separation of Duty Relations).
1.2.1 Mô hình RBAC cơ sở
Mô hình này (Hình 1.1) bao gồm các phần tử cơ bản: người dùng (USERS),
vai trò (ROLES), các đối tượng (OBS), các thao tác (OPS), các quyền hạn

(PRMS) và mỗi quan hệ giữa chúng.Ngoài ra, mô hình RBAC cơ sở còn 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[4].

11

USERS ROLES
(PA)
Permission Assignment
SESS-
IONS
OPS OBS
PRMS
(UA)
User Assignment
User
-

Session
Session
-

Role

Hình 1.1:Mô hình RBAC[4]
Một user được hiểu là một người dùng. Tuy nhiên khái niệm người dùng cần
được hiểu theo nghĩa rộng, vì nó có thể là máy tính, tác nhân (agent) hay một
hệ thống khác. Để đơn giản ta gọi chung là người dùng.
Một 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.
Một permission là một quyền hạn đượ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 operationlà hành động của người dùng trên tài nguyên.Các operation có
thể có phụ thuộc vào mỗi hệ thống cụ thể, mỗi loại tài nguyên cụ thể. Ví dụ,
trong một hệ thống tập tin, các hoạt động có thể là read, write và execute;
trong một hệ quản trị cơ sở dữ liệu, các hoạt động có thể là insert, update, và
delete.
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 RBAC chúng ta sử dụng thuật ngữ đối tượng được
bảo vệ để nói đến các đối tượng chứa thông tin cần được bảo vệ như tệp, thư
mục, hệ điều hành, bản ghi trong cơ sở dữ liệu hoặc cũng có thể là máy in, ổ
cứng, CPU.
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.
Đặc tả RBAC cơ sở[4]:

12

- USERS, ROLES, OPS, vàOBS (users, roles, operations, và objects).
- UA
⊆
USERS × ROLES, là quan hệ nhiều-nhiều giữa tập người dùng
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 giữa tập quyền 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.

1.2.2 RBAC phân cấp
RBAC phân cấp (Hình 1.2) thêm khái niệm về phân cấp vai trò vào RBAC cơ
sở.Đó là những vai trò có quyền thừa kế từ các vai trò khác.Ví dụ, 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
.

13

USERS ROLES
(PA)
Permission Assignment
SESS-
IONS
OPS OBS
PRMS
(UA)
User Assignment
User
-

Session
Session
-

Role
(RH)
Role Hierarchy

Hình 1.2: Mô hình RBAC[4]
Điểm mấu chốt của mô hình này là giữa các vai trò có thể có quan hệ kế thừa,
nó cho phép một role con kế thừa tất cả các quền hạn của role cha.Có hai kiểu
kế thừa đó là: Mô hình phân cấp vai trò tổng quát (General Role Hierarchies)
và Mô hình phân cấp vai trò hạn chế (Limited Role Hierarchies)[4].
Mô hình phân cấp vai trò tổng quáthỗ trợ đa kế thừa (multiple inheritance).
Điều này có nghĩa là một role có thể kế thừa từ nhiều role khác
Định nghĩa hình thức[4]:
1. 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
).
2. authorized_users(r: ROLES) → 2
USERS
, ánh xạ vai trò r lên trên một
tập người dùng, authorized_users(r) = {u

USERS | r’ r , (u, r’)


UA}.
3. authorized_permissions(r: ROLES) → 2
PRMS
, ánh xạ vai trò r lên
trên một tập các quyền. authorized_permissions(r) = {p

PRMS | r’
r, (p, r’)

PA}.
Mô hình phân cấp vai trò hạn chế chỉ hỗ trợ kế thừa đơn, nghĩa là mỗi role
chỉ có thể kế thừa từ một role khác.
Về mặt định nghĩathì mô hình phân cấp vai trò hạn chế tương tự nhưmô hình
phân cấp vai trò tổng quát, nhưng có thêm ràng buộc[4]:

14

r, r
1
, r
2

ROLES, r r
1
∧
r r
2
⇒
r
1
= r
2

để đảm bảo mỗi role chỉ có thể kế thừa từ một role khác.
1.2.3 RBAC ràng buộc
RBAC cho phép một người sử dụng có thể có nhiều vai trò khác nhau, các vai
trò này có thể có các quyền hạn xung đột nhau.Chẳng hạn như trong hệ thống
ngân hàng, các giao dịch được thực hiện bởi giao dịch viên, nhưng các giao
dịch đó chỉ được thực hiện khi đã được phê duyệt bởi kiểm soát viên. Rõ
ràng, trong ví dụ này, giao dịch viên và kiểm soá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. Vì thế, cần bổ sung thêm các ràng buộc để tránh xung
đột[4].
RBAC ràng buộc (Hình 1.3) thêm các quan hệ phân chia trách nhiệm
(Separation of Duty - SoD) vào mô hình RBAC cơ sở. SoD được sử dụng để

tránh xung đột về quyền hạn khi một người thuộc về các vai trò khác nhau.
Mô hình RBAC ràng buộc được chia thành hai loại: Ràng buộc tĩnh (Static
Separation of Duty Relations - SSD) vàràng buộc động (Dynamic Separation
of Duty Relations - DSD).
Ràng buộc tĩnh:
SSD ⊆ (2
ROLES
× N) là một tập các cặp (rs, n) trong SoD tĩnh, vớirs 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 đặc tính
không có người dùng nào được gán tới n hoặc nhiều hơn vai trò từ tập hợp rs
trong mỗi cặp (rs, n)
∈
SSD. Một cách hình thức:
∀
(rs, n)
∈
SSD,
∀
t
⊆
rs : |t | ≥ n
⇒
tr

assigned_users(r) = Ø
Ràng buộc tĩnh với RBAC phân cấp:
Đối với ràng buộc tĩnh trong mô hình RBAC phân cấp thì ta cần ràng buộc
trên authorized users thay vì assigned users. Một cách hình thức thì:
∀
(rs, n)

∈
SSD,
∀
t
⊆
rs : |t | ≥ n
⇒
tr

authorized_users(r) = Ø

15

USERS ROLES
(PA)
Permission Assignment
SESS-
IONS
OPS OBS
PRMS
(UA)
User Assignment
User
-

Session
Session
-

Role

(RH)
Role Hierarchy
SSD

Hình 1.3: Mô hình SSD với RBAC phân cấp[4]
Ràng buộc động:
SoD động (Hình 1.4) 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. DSD khác SSD ở
giới hạn role được thiết lập trên mỗi phiên làm việc, điều này cho phép một
người có thể có nhiều role có vai trò xung đột nhau, nhưng trong mỗi phiên
làm việc thì các role được kích hoạt (active) là không xung đột. Hay nói cách
khác DSD cho phép một người dùng được xác thực cho hai hoặc nhiều vai trò
mà chúng xung đột nhau.
USERS ROLES
(PA)
Permission Assignment
SESS-
IONS
OPS OBS
PRMS
(UA)
User Assignment
User
-

Session
Session
-

Role

DSD

Hình 1.4 :Mô hình DSD[4]
DSD
⊆
(2
ROLES
× N) là tập của cặp (rs, n) trong DSD, trong đó mỗi rs là một
tập các vai trò và n là một số tự nhiên ≥ 2, với đặc tính không có chủ thể nào
có thể kích hoạt n hay nhiều vai trò từ tập rs trong mỗi dsd

DSD[4]:
∀
rs
∈
2
ROLES
, n
∈
N, (rs, n)
∈
DSD
⇒
n ≥ 2
∧
|rs| ≥ n, và

16

∀

s
∈
SESSIONS,
∀
rs
∈
2
ROLES
,
∀
role_subset
∈
2
ROLES
,
∀
n
∈
N, (rs, n)
∈
DSD,
role_subset
⊆
rs, role_subset
⊆
session_roles(s)
⇒
|role_subset| < n
1.2.4 Ưunhược điểm của RBAC
1.2.4.1 Ưu điểmcủa RBAC

- Phù hợp với hầu hết các ứng dụng trong thực tế
- Mô hình đơn giản, hiệu quả
- Đơn giản trong việc quản trị quyền truy cập, thay vì quản lý quyền truy
cập trên từng user ta sẽ quản lý quyền truy cập trên mỗi nhóm. Việc
này giúp giảm công sức, thời gian cũng như giảm rủi ro do nhầm lẫn.
- Mô hình RBAC phân cấp hỗ trợ sự phân cấp vai trò (Role Hierarchies)
với mối quan hệ cha-con, theo đó tất cả quyền hạn của vai trò cha được
kế thừa bởi vai trò con. Điều này ngăn cản sự bùng nổ vai trò và tăng
khả năng sử dụng lại trong mô hình RBAC.

1.2.4.2 Nhược điểm của RBAC
Hầu hết các ứng dụng trong thực tế đều có thể điều khiển truy cập theo vai
trò, vì thế RBAC có tính phổ dụng cao. Tuy nhiên, nó cũng có một vài hạn
chế:
- Không phù hợp với các ứng dụng có tài nguyên cần bảo vệ là chưa biết
trước
- Không phù hợp khi quy tắc điều khiển truy cập phức tạp, việc điều
khiển truy cập không chỉ dựa vào thông tin về vai trò, mà còn phụ
thuộc vào các thông tin ngữ cảnh khác.
- Không phù hợp với các ứng dụng mà một người dùng có thể mang
nhiều vai trò mâu thuẫn nhau. Điều này phần nào được giải quyết với
mô hình RBAC ràng buộc tĩnh hay động. Tuy nhiên, khi các quy tắc
đảm bảo tính loại trừ là phức tạp và chưa biết trước thì RBAC ràng
buộc không đáp ứng được hoặc khó cài đặt.

17

1.3 Định danh dựa trên tuyên bố (Claims-based identity)
Claims-based identity là một cách phổ biến cho các ứng dụng khi cần thông
tin nhận diện về người dùng trong tổ chức của họ hoặc trong tổ chức khác

hoặc trên môi trường Internet.Nó cung cấp một cách tiếp cận thống nhất cho
các ứng dụng [1].
1.3.1 Tuyên bố (Claim)
Một Claim là một phát biểu (Statement) về một thực thể (con người, tổ chức)
được thực hiện bởi chính nó hoặc một người khác. Chủ thể cung cấp claim
được gọi là provider hay issuer.
Ví dụ:
- Bob là một administrator
- Bob có địa chỉ email là
1.3.2 Định danh (Identiy)
Identity là một tập thông tin về một người dùng hoặc một thực thể được xác
thực. Trong Claim based identity, mỗi Identity là một tập các claim của người
dùng.
1.3.3 Principal
Principallà một đối tượng đặc biệt nó gắn với ngữ cảnh bảo mật (security
context) của người dùng, trong khi Identity là thông tin định danh người
dùng. Mỗi thread có chứa một đối tượng Principal (Thread.CurrentPrincipal),
thread này sẽ thực thi trong ngữ cảnh bảo mật của đối tượng Principal. Có thể
hình dung Principal nhưmột thẻ bài (token) của người dùng trong ứng dụng.

1.4 RBACTRONG.NET FRAMEWORK
.Net Framework hỗ trợ RBAC thông qua hai hình thức: khai báo (Declarative)
và lập trình (Imperative) [5]. Ngoài ra, với ứng dụng ASP.NET còn hỗ trợ
RBAC theo URL, hay với ASP.NET MVC đưa ra lớp AuthorizeAttribute để
điều khiển truy cập trên các action của controller.

18

1.4.1 Kiểm tra vai trò dựa trên khai báo
.Net Framework cung cấp lớp PrincipalPermissionAttribute cho phép ta chỉ

định chỉ người dùng nào có vai trò nào đó mới có quyền thực thi phương thức
bằng cách gắn khai báo ở đầu phương thức. Ví dụ, để đảm bảo rằng chỉ có
người sử dụng có vai trò là giao dịch viên mới có thể thực thi phương thức
Transfer ta làm như sau:
[PrincipalPermission(SecurityAction.Demand, Role = "Teller")]
void Transfer()
{
}
Việc khai báo cho phương thức Transfer thuộc tính
[PrincipalPermission(SecurityAction.Demand, Role = "Teller")] khiến .Net
Framework phải kiểm tra xem người dùng hiện tại (Thread.CurrentPrincipal)
có vai trò Teller hay không. Nếu người dùng hiện tại không có vai trò Teller
thì một SecurityException sẽ được ném ra, và như vậy phương thức Transfer
sẽ không được thực thi.
1.4.2 Kiểm tra vai trò trong mã nguồn
Đôi khi ta không thể sử dụng cách thức khai báo như mục 1.4.1, bởi các lý do
khác nhau như: ta chỉ muốn kiểm tra quyền truy cho một đoạn chương trình
(block) mà thôi, thay vì toàn bộ phương thức, hoặc khi trong phương thức đó
có nhiều vai trò cần kiểm tra dựa vào các điều kiện khác nhau. Với tình huống
này ta cần đặt đoạn chương trình kiểm tra quyền truy cập vào bên trong code
của phương thức. Mỗi Principal đều kế thừa từ IPrincipal, do đó để đảm bảo
chỉ những role xác định được quyền truy cập tới một tài nguyên nào đó ta sử
dụng phương thức IPrincipal.IsInRole . Ví dụ, để đảm bảo rằng chỉ có người
sử dụng có vai trò là giao dịch viên mới có thể thực thi một tác vụ nào đó ta
sẽ kiểm tra như sau:
if (Thread.CurrentPrincipal.IsInRole("Teller"){
//Thực thi tác vụ nào đó mà chỉ có giao dị ch viên mới được phép
}
1.4.3 RBAC với ứng dụng ASP.NET
.Net Framework cho phép điều khiển truy cập theo URL thông qua việc thiết

lập trong tệpweb.config của ứng dụng. Ví dụ, chỉ có người sử dụng có role là

19

Teller mới có quyền truy xuất đến trang Transfer.aspx và chỉ có người sử
dụng có role là Admin mới có quyền truy xuất đến các trang trong thư mục
Account ta làm như sau:
<locationpath="Transfer.aspx">
<system.web>
<authorization>
<allowroles="Teller"/>
</authorization>
</system.web>
</location>
<locationpath="Account">
<system.web>
<authorization>
<allowroles="Admin" />
</authorization>
</system.web>
</location>
Cơ chế này là là hiệu quả với với ASP.NET, khi mà truy xuất đến tài nguyên
được định danh theo URL. Tuy nhiên, cơ chế này không thể dùng được trong
ASP.NET MVC, do URL được cấu hình theo route. Thậm chí, nó cũng không
thể dùng được trong ASP.NET khi ta áp dụng quy tắc biến đổi URL (URL
rewrite).
1.4.4 RBAC với ứng dụng ASP.NET MVC
ASP.NET MVC bổ sung lớp AuthorizeAttribute cho phép điều khiển truy cập
cho các action của controller. Ví dụ, để đảm bảo rằng chỉ có người sử dụng
có vai trò là giao dịch viên mới có thể thực thi action Transfer ta làm như sau:

[Authorize(Roles = "Teller")]
publicActionResult Transfer()
{
return View();
}
Chú ý rằng AuthorizeAttribute là một ActionFilter của ASP.NET
MVC[7]Error! Reference source not found., vì thế nó chỉ có thể được gắn
cho action của controller mà thôi, ta không thể dùng nó với các phương thức
khác không phải là action.Hay nói cách khác nói chỉ được sử dụng cho ứng
dụng ASP.NET MVC mà thôi.

20

1.4.5 Các hạn chế của RBAC trong .Net Framework
.Net Framework chỉ cho phép điều khiển truy cập RBAC bằng cách chèn mã
điều khiển truy cập vào trong chương trình, điều này dẫn đến các hạn chế:
- Logic điều khiển truy cập đan xen với logic nghiệp vụ
- Không linh hoạt khi cần thay đổi quyền truy cập, cụ thể là mỗi khi cần
thay đổi điều khiển truy cập (thậm chí chỉ thay đổi tên của vai trò) cần
sửa chương trình và biên dịch lại.
- Việc điều khiển truy cập chưa hướng đến đối tượng được bảo vệ (tài
nguyên hệ thống như tệp, printer…)
Vì thế ta cần tách biệt hoàn toàn logic điều khiển truy cập ra khỏi code (điều
khiển truy cập nên được xác định trong tệp xml). Việc này cho phép code gọn
hơn, linh hoạt hơn khi thay đổi quyền truy cập mà không cần sửa code và biên
dịch lại chương trình.Hơn nữa việc điều khiển truy cập cần hướng tới đối
tượng được bảo vệ hơn là phương thức.

21

Chương 2. MỞ RỘNG ĐIỀU KHIỂN TRUY CẬP RBAC VỚI LUẬT
2.1 Đặc tả điều khiển truy cập RBAC
Như đã đề cập trong mục 1.4.5, ta cần tách biệt logic điều khiển truy cập ra
khỏi codevà điều khiển truy cập hướng đến đối tượng được bảo vệ hơn là
phương thức. Vì thế, chúng tôi đề xuất đặc tả điều khiển truy cập như sau:
<?xmlversion="1.0"encoding="utf-8" ?>
<AccessControl>
<Resources>
<ResourceName="File">
<OperationName="View">
<RoleName="Admin"></Role>
<RoleName="Guest, HR"></Role>
</Operation>
<OperationName="Update">
<RoleName="Admin"></Role>
<RoleName="HR"></Role>
</Operation>
</Resource>
<ResourceName="Printer">
<OperationName="Print">
<RoleName="HR"></Role>
</Operation>
</Resource>
</Resources>
</AccessControl>
Ý nghĩa của các thẻ như sau:
Tên thẻ
Ý nghĩa
AccessControl
Định nghĩa các điều khiển truy cập theo

RBAC
Resources
Định nghĩa các tài nguyên
Resource
Định nghĩa cho mỗi tài nguyên, mỗi tài
nguyên có thuộc tính Name cho biết
định danh của tài nguyên. Định danh
này là duy nhất.
Operation
Định nghĩa phép toán trên tài nguyên.
Thuộc tính Name cho biết tên phép
toán, tên phép toán là duy nhất trên mỗi
tài nguyên.

22

Role
Định nghĩa các vai trò được phép thực
hiện phép toán trên tài nguyên. Thuộc
tính Name cho biết tên vai trò.

Bảng 2.1:Ý nghĩa các thẻtrong đặc tả truy cập RBAC
Đặc tả này là độc lập với code, vì thế ta có thể lưu đặc tả này trong file hoặc
trong CSDL. Trong luận văn này, chúng tôi lưu đặc tả truy cập trong một tệp
xml.Đặc tả này cho phép ta định nghĩa các tài nguyên cần bảo vệ, các thao tác
trên tài nguyên và vai trò nào được phép thực hiện thao trên tài nguyên.
Ưu điểm của cách tiếp cận này là chương trình sẽ không có các chỉ thị để xác
định xem vai trò nào được phép thực thi mà chỉ có chỉ thị để xác định đây là
thao tác gì, trên tài nguyên nào, vì thế nó linh hoạt hơn khi ta muốn thay đổi
quyền truy cập.Hơn nữa, nó hướng đến tài nguyên được bảo vệ hơn là phương

thức.
2.2 Điều khiển truy cập theoluật
Điều khiển truy cập theo luật cho phép ta ra quyết định chấp nhận hay từ chối
truy cập bằng cách kết hợp các thông tin của người, mỗi luật là một phát biểu
dưới dạng nếu - thì.Tuy nhiên .Net Framework không hỗ trợ điều khiển truy
cập theo luật. Vì thế, chúng tôi đề xuất đặc tả điều khiển truy cập theo luật
như sau:
<?xmlversion="1.0"encoding="utf-8" ?>
<AccessControl>
<Rules>
<RuleId="r1"Description="Date of birth is greater than 1/1/1980">
<ConditionsOperator="GreaterThan">
<Parameter>
<ClaimItemClaimType="DateOfBirth"DataType="DateTime" />
</Parameter>
<ParameterType="DateTime">
<ConstantValue="1/1/1980"DataType="DateTime" />
</Parameter>
</Conditions>
<Action>Allow</Action>
</Rule>
<RuleId="r2"Description="Accept who is came from VN and DoB>1/1/1980">
<ConditionsOperator="And">
<Parameter>
<ConditionsOperator="Equal">

23

<Parameter>
<ClaimItemClaimType="Country" />

</Parameter>
<Parameter>
<ConstantValue="VietNam" />
</Parameter>
</Conditions>
</Parameter>
<Parameter>
<ConditionsOperator="GreaterThan">
<Parameter>
<ClaimItemClaimType="DateOfBirth"DataType="DateTime" />
</Parameter>
<Parameter>
<ConstantValue="1/1/1980"DataType="DateTime" />
</Parameter>
</Conditions>
</Parameter>
</Conditions>
<Action>Allow</Action>
</Rule>
<RuleId="r3"Description="Does not allow who is in 'HaNoi (StateOrProvince)">
<ConditionsOperator="Equal">
<Parameter>
<ClaimItemClaimType="StateOrProvince" />
</Parameter>
<Parameter>
<ConstantValue="HaNoi" />
</Parameter>
</Conditions>
<Action>Deny</Action>
</Rule>

</Rules>
<Resources>
<ResourceName="File">
<OperationName="View">
<Rule>r1</Rule>
</Operation>
<OperationName="Update">
<Rule>r1, r2</Rule>
</Operation>
</Resource>
<ResourceName="Printer">
<OperationName="Print">
<Rule>r3</Rule>
</Operation>
</Resource>
</Resources>
</AccessControl>