Khóa luận tốt nghiệp: Kiểm chứng cơ chế bảo mật dựa trên AST

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

-----

Nguyễn Văn Thanh

KIỂM CHỨNG CƠ CHẾ BẢO MẬT DỰA TRÊN AST

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công nghệ thông tin

HÀ NỘI – 2009

i


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

-----

Nguyễn Văn Thanh

KIỂM CHỨNG CƠ CHẾ BẢO MẬT DỰA TRÊN AST

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY
Ngành: Công nghệ thông tin

Cán bộ hướng dẫn: TS. Trương Ninh Thuận

HÀ NỘI – 2009

ii


Lời cảm ơn
Em xin gửi lời cảm ơn chân thành nhất đến TS. Trương Ninh Thuận, người thầy đã
cho em định hướng, những ý kiến quý báu về kiểm chứng cơ chế bảo mật dựa trên
AST và đã tận tình hướng dẫn em hoàn thành khóa luận. Thầy đã giúp đỡ em rất nhiều và
đi cùng em trong suốt thời gian thực hiện khóa luận. Thầy chỉ cho em cách tiếp cận,
nghiên cứu một công nghệ mới, cách tìm ra giải pháp cho vấn đề mắc phải.
Em xin chân thành cảm ơn quý thầy cô và các bạn đã giúp đỡ em trong những năm
học qua. Em xin chân thành cảm ơn Bộ môn Công nghệ phần mềm, Khoa Công nghệ
thông tin, Trường Đại Học Công Nghệ, Đại Học Quốc Gia Hà Nội đã tạo điều kiện thuận
lợi cho em trong suốt quá trình học tập và làm khóa luận này.
Đề tài “Kiểm chứng cơ chế bảo mật dựa trên AST” là một đề tài khá mới mẻ lại
được hoàn thành trong quỹ thời gian hạn hẹp nên khó tránh khỏi những khiếm khuyết em
mong nhận được những góp ý chân thành từ thầy cô giáo và các bạn để đề tài có thể được
mở rộng và nghiên cứu kỹ hơn, đưa vào trong thực tiễn ngành Công nghệ thông tin hiện
nay.

Hà Nội, ngày 10 tháng 5 năm 2009
Sinh viên

Nguyễn Văn Thanh

iii

Danh sách các hình vẽ
Hình 2.1: Một họ của các mô hình RBAC
Hình 2.2: Mô hình RBAC0
Hình 2.3: Các ví dụ của Role Hierarchies
Hình 2.4: Role Hierarchies cho một dự án
Hình 2.5: Mô hình tổng quát của RH (RBAC1)
Hình 2.6: Mô hình RBAC quản lý
Hình 3.1: Cấu trúc tổng quát CDT
Hình 3.2: Cấu trúc chi tiết của CDT
Hình 3.3: Giao diện DOM AST
Hình 3.4: Mô tả cách duyệt cây
Hình 4.1: Cấu trúc cây của ifStatement đơn giản
Hình 4.2: Mô tả thuật toán kiểm chứng cơ chế bảo mật
Hình 4.3: Cấu trúc của lệnh if phức tạp
Hình 4.4: Thể hiện phức tạp trên AST
Hình 4.4: Lỗi thể hiện trong đoạn mã
Hình 5.1: Giao diện StartPage sau khi cài CDT
Hình 5.2: Cấu trúc DOM AST
Hình 5.3: Giao diện chương trình Test
Hình 5.4: Giao diện khi chạy Test thành công
Hình 5.5: Giao diện kết quả
Hình 5.6, 5.7: Minh họa kết quả kiểm tra chương trình.

iv


Danh sách các thuật ngữ và khái niệm
THUẬT NGỮ

KHÁI NIỆM

MAC

Mandatory access control – điều khiển truy cập bắt buộc

DAC

Discretionary access control – điều khiển truy cập tùy quyền

RBAC
ACL
Role hierarchy
OPS

Role-based access control – điều khiển truy cập trên cơ sở vai trò
Access control list – Danh sách điều khiển truy cập
Cấp bậc trong vai trò
Tập hợp các hành động trên một đối tượng cụ thể
Quá trình chạy một chương trình để kiểm tra một thuật toán hay

Test

một bài toán cụ thể.

File

Đối tượng tệp văn bản được sao lưu trên máy tính

Project

Nói về một dự án được tạo ra cụ thể là Eclipse

Session

Phiên làm việc

User

Người sử dụng

Permission
Role
Expression

Quyền hạn
Vai trò
Các biểu thức (Ở đây tập trung nói về các biểu thức điều kiện)

v


Tóm tắt khóa luận
Từ trước đến nay, bảo mật thông tin luôn chiếm một vai trò rất quan trọng của một
tổ chức, công ty hay quốc gia. Trong Công nghệ thông tin vấn đề bảo mật được chú trọng
và quan tâm một cách nghiêm túc. Đã có rất nhiều cơ chế bảo mật được đưa ra và thích
hợp cho từng lĩnh vực riêng.
Khóa luận tập trung nghiên cứu các vấn đề liên quan đến kiểm chứng cơ chế bảo
mật thông tin dựa trên RBAC. Nghiên cứu các mô hình RBAC, các ví dụ về các mô hình
và ứng dụng của các mô hình này trong thực tiễn.

Giới thiệu công cụ CDT để xây dựng mô hình kiểm chứng cơ chế bảo mật dựa trên
AST (Abstract Syntax Tree). Các ứng dụng của CDT trong bài toán kiểm chứng.
Những nghiên cứu tập trung vào kiểm chứng mô hình RBAC dựa trên AST sẽ là
nền móng cho những nghiên cứu rộng hơn và khả dụng hơn trong tương lai không xa.
Để thuyết phục hơn, khóa luận đưa ra một bài toán ví dụ để kiểm chứng mô hình
RBAC0 và mã nguồn viết bằng Java (trên công cụ Eclipse) và mô hình được Test trên
ngôn ngữ C/C++.

vi


MỤC LỤC
CHƯƠNG 1. GIỚI THIỆU ........................................................................... 1
1.1. Bối cảnh .......................................................................................................... 1
1.2. Mục tiêu khóa luận ........................................................................................ 1
1.3. Cấu trúc khóa luận ........................................................................................ 2

CHƯƠNG 2. CÁC MÔ HÌNH ĐIỀU KHIỂN TRUY CẬP DỰA TRÊN
VAI TRÒ ........................................................................................................ 3
2.1. Giới thiệu ........................................................................................................ 3
2.2. Nền tảng và động lực ..................................................................................... 4
2.3. Các vai trò và các khái niệm liên quan ........................................................ 7
2.4. Các mô hình một họ tham chiếu................................................................... 8
2.5. Mô hình cơ sở ............................................................................................... 10
2.6. Role có cấp bậc ............................................................................................. 14
2.7. Các ràng buộc............................................................................................... 20
2.8. Mô hình hợp nhất ........................................................................................ 24
2.9. Các mô hình quản lý .................................................................................... 26
2.10. Kết luận ....................................................................................................... 29

CHƯƠNG 3. GIỚI THIỆU CÔNG CỤ CDT TRONG ECLIPSE .......... 31
3.1. Tổng quan ..................................................................................................... 31
3.2. Cấu trúc của CDT ........................................................................................ 31
3.3. Các tính năng của CDT ............................................................................... 32
3.4. Kết luận ......................................................................................................... 35

CHƯƠNG 4. BÀI TOÁN KIỂM CHỨNG ................................................ 36
4.1. Giới thiệu: ..................................................................................................... 36
4.2. Khái quát thuật toán ................................................................................... 36
4.3. Những khía cạnh liên quan ......................................................................... 38
4.3.1. Khía cạnh lý thuyết ......................................................................................... 38
4.3.2. Khía cạnh thực tiễn ......................................................................................... 40

vii


4.4. Ứng dụng thuật toán.................................................................................... 41
4.4.1. Khái quát về ứng dụng ................................................................................... 41
4.4.2. Mục tiêu bài toán: ........................................................................................... 41
4.4.3. Yêu cầu bài toán:............................................................................................. 42
4.4.4. Phân tích bài toán ........................................................................................... 42

4.5. Kết luận ......................................................................................................... 43

CHƯƠNG 5. THỰC NGHIỆM .................................................................. 45
5.1. Phạm vi ứng dụng ........................................................................................ 45
5.2. Thiết kế ứng dụng ........................................................................................ 45
5.3. Xây dựng và triển khai bài toán ................................................................. 48
5.3.1. Xây dựng chương trình chính ........................................................................ 48
5.3.2. Xây dựng chương trình kiểm tra:.................................................................. 49

5.4. Kiểm thử chương trình................................................................................ 53
5.4.1. Nội dung kiểm thử ........................................................................................... 53
5.4.2. Kết quả ............................................................................................................. 61

CHƯƠNG 6. KẾT LUẬN ........................................................................... 63

viii


CHƯƠNG 1. GIỚI THIỆU
1.1. Bối cảnh
Trong thời kỳ thông tin bùng nổ như hiện nay, tất cả các lĩnh vực trong đời sống xã
hội đều sử dụng công nghệ thông tin như các cơ quan chính phủ, các ngân hàng hay các tổ
chức.. Nhưng một thực tế đáng lo ngại là vấn đề bảo mật chưa được quan tâm thích đáng
và chưa sử dụng hợp lý.
Có rất nhiều cơ chế bảo mật được nghiên cứu và triển khai thích họp cho từng lĩnh
vực khác nhau. Trong các mô hình đang tồn tại thì toàn diện nhất là RBAC.
RBAC điều khiển việc truy cập dựa trên vai trò của từng người sử dụng. Mô hình
này có nhiều ưu điểm, nhưng nội dung rất rộng nên khóa luận tập trung chuyên sâu vào
mô hình đơn giản nhất và đặc trưng nhất của RBAC là RBAC0.

1.2. Mục tiêu khóa luận
Khóa luận sẽ nghiên cứu những vấn đề sau:
Khái niệm RBAC và đi vào chi tiêt các mô hình RBAC. Phần này giới thiệu một
cách khái quát nhất RBAC là gì? Những đặc điểm, các mô hình và ứng dụng trong cơ chế
bảo mật như thế nào?
Sau khi tìm hiểu về RBAC, phần tiếp theo phát biểu bài toán kiểm chứng các mô
hình của RBAC (cụ thể là RBAC0). Mã nguồn được biểu diễn dưới cấu trúc cây, phần
này nêu lên thuật toán duyệt cây và đưa ra kết luận về tính đúng đắn của mã nguồn so với

mô hình RBAC0.
Khóa luận sẽ đề cập tới việc dùng Eclipse với công cụ CDT để sinh ra cây cú pháp
trừu tượng (AST), cấu trúc AST và cách để duyệt nó.
Mục tiêu quan trong của luận văn là lam sao đề xuất được một phương pháp hiệu
quả để kiểm chứng mô hình RBAC0 với phần thực thi chương trình sử dụng AST

1


1.3. Cấu trúc khóa luận
Khóa luận được cấu trúc như sau:
Chương 2 phân tích chi tiết về các mô hình điều khiển truy cập dựa trên vai trò
(RBAC). Các cách tiếp cận các mô hình của RBAC qua các ví dụ cụ thể
Chương 3 giới thiệu về CDT - một công cụ để triển khai bài toán kiểm chứng. Giới
thiệu trực quan qua các hình ảnh và các ứng dụng của thể của CDT. Chương này không
nói hết về CDT chỉ đề cập các phần quan trọng nhất của CDT phục vụ trực tiếp cho khóa
luận.
Chương 4 nghiên cứu bài toán kiểm chứng và ứng dụng trên mô hình RBAC0. Từ
cây cú pháp trừu tượng (AST) đưa ra thuật toán kiểm chứng có đầu vào là mã nguồn
C/C++ và kết quả được so sánh với mô hình RBAC0 và kết luận về sự tương ứng của mô
hình so với đoạn mã chuơng trình.
Chương 5 là phần thực nghiệm sẽ cụ thể thuật toán đã đề cập ở chương 4 bằng cách
đưa ra một bài toán cụ thể. Chương này sẽ đưa ra các chi tiết chạy chương trình và kết
quả đạt được liên quan tới bài toán đang được nghiên cứu.
Chương 6 là chương cuối nêu lên kết luận về khóa luận.

2


CHƯƠNG 2. CÁC MÔ HÌNH ĐIỀU KHIỂN TRUY CẬP

DỰA TRÊN VAI TRÒ
2.1. Giới thiệu
Khái niệm điều khiển truy cập dựa trên vai trò (RBAC) bắt đầu với hệ thống đa
người sử dụng và đa ứng dụng trực tuyến được đưa ra lần đầu vào những năm 70. Ý
tưởng trọng tâm của RBAC là permission (quyền hạn) được kết hợp với role (vai trò) và
user (người sử dụng) được phân chia dựa theo các role thích hợp. Điều này làm đơn giản
phần lớn việc quản lý những permission. Tạo ra các role cho các chức năng công việc
khác nhau trong một tổ chức và user cũng được phân các role dựa vào trách nhiệm và
trình độ của họ. Phân lại cho user từ chức năng này sang chức năng khác. Những role
được cấp các permission mới vì các ứng dụng gắn kết chặt chẽ với các hệ thống và các
permission được hủy khỏi các role khi cần thiết.
Một role được xem như một kết cấu ngữ nghĩa mà cơ chế điều khiển truy cập đều
hình thành xung quanh. Một tập hợp riêng biệt những user và các permission được lập ra
bởi các role chỉ là tạm thời. Role ổn định hơn bởi vì hoạt động hay chức năng của một tổ
chức thường ít thay đổi hơn.
Một role tương ứng với một năng lực để làm một nhiệm vụ cụ thể, ví dụ một bác sỹ
nội khoa hay một dựợc sỹ. Một role cũng là hiện thân của một thẩm quyền và một bổn
phận như một giám sát dự án.
Một thẩm quyền hay một trách nhiệm khác với một năng lực. Jane Doe có năng lực
để điều hành một số bộ phận nhưng chỉ được phân công điều hành một bộ phận. Các role
phản ánh cho các nhiệm vụ được phân công cụ thể được luân phiên giữa nhiều user, ví dụ
công việc của một bác sỹ nội khoa hay một quản lí ca. Các mô hình RBAC và sự cài đặt
nên có khả năng cải thiện cung cấp tất cả các biểu hiện của khái niệm role.
Theo một nghiên cứu mới đây của NIST [1] thì RBAC nhằm vào nhu cầu của các
ngành kinh doanh hay của cả chính phủ. Trong công trình nghiên cứu của 28 tổ chức này,

3


nhu cầu điều khiển truy cập bị chi phối bởi nhiều mối quan tâm khác nhau gồm cả người

tiêu dùng, cổ đông và sự tin cậy của các công ty bảo hiểm, sự riêng tư của thông tin cá
nhân, việc ngăn chặn sự phân bố tài sản tài chính trái phép, ngăn chặn sử dụng không
phép các đường dây điện thoại đường dài và sự giữ vững các tiêu chuẩn nghề nghiệp.
Nhiều tổ chức đưa ra các quyết định điều khiển truy cập dựa trên role mà user là cá
nhân đảm nhận như một bộ phận của tổ chức. Nhiều tổ chức thích kiểm soát tập trung và
duy trì quyền truy cập, không theo ý muốn cá nhân của người quản lí hệ thống lắm mà
theo các chỉ dẫn bảo vệ của tổ chức.
Bản nghiên cứu cho thấy các tổ chức thường xem các nhu cầu điều khiển truy cập
của họ là duy nhất và cảm thấy các sản phẩm có sẵn thiếu sự linh hoạt.
Các role được xem như một phần của tiêu chuẩn SQL3 nổi bật cho hệ thống quản lí
dữ liệu, dựa vào sự thực hiện của chúng trong Oracle 7. Các role được kết nối chặt chẽ
trong hiện trạng an ninh thương mại. RBAC cũng phù hợp với công nghệ đang thịnh hành
và các xu hướng kinh doanh. Một loạt sản phẩm cung cấp trực tiếp một dạng RBAC, các
sản phẩm khác hỗ trợ những tính năng có liên quan chặt chẽ, ví dụ nhóm user, những tính
năng này được sử dụng để thực hiện các role.

2.2. Nền tảng và động lực
Mục đích chính của RBAC làm cho việc quản trị an ninh và xem lại thuận tiện hơn.
Nhiều hệ thống kiểm soát truy cập cho các máy tính lớn thành công về thương mại thực
hiện role quản trị an ninh. Ví dụ, role là người vận hành có thể truy cập tất cả các tài
nguyên mà không thay đổi các quyền truy cập, role là một nhân viên bảo vệ có thể thay
đổi các quyền truy cập nhưng không được truy cập vào các tài nguyên, và role là một
kiểm toán viên có thể truy cập vào các đường kiểm toán. Việc sử dụng các role mang tính
quản lí này cũng đựợc có trong các hệ thống điều khiển mạng hiện đại như Novell’s
NetWare và Microsoft Windows NT.
Sự quan tâm mới xuất hiện trở lại đây đối với RBAC tập trung chủ yếu vào khả
năng sử dụng RBAC ở cấp độ ứng dụng. Trong quá khứ và cả ngày nay, các ứng dụng

4

đặc biệt đã được xây dựng với RBAC được mã hóa trong bản thân sự ứng dụng. Các hệ
điều hành hiện có và các môi trường cung cấp rất ít khả năng sử dụng RBAC ở cấp độ
ứng dụng. Khả năng này bây giờ bắt đầu xuất hiện trong các sản phẩm. Thách thức đặt ra
là phải xác định được ứng dụng độc lập tiện lợi khá linh hoạttất nhiên dễ dàng thực hiện,
sử dụng và hỗ trợ nhiều ứng dụng với sự điều chỉnh nhỏ nhất.
Các biến thể tinh vi của RBAC bao gồm khả năng thiết lập mối quan hệ giữa các
role cũng như là giữa các permission và các role và giữa các user với các role.
Ví dụ, hai role có thể đươc lập sao cho loại trừ nhau do đó cùng một user không
đựơc phép thực hiện cả hai role. Các role cũng có thể có quan hệ kế thừa, theo đó một
role kế thừa các permission được gắn cho role khác. Những mối quan hệ role – role này
có thể được sử dụng để làm cho các chính sách bảo mật bao gồm sự tách rời các công việc
và sự ủy thác của người có thẩm quyền. Từ trước đến nay những mối quan hệ này đựợc
mã hóa trong phần mềm ứng dụng, với RBAC, chúng đựợc định rõ một lần cho một miền
bảo mật.
Với RBAC, người ta có thể xác định được các mối quan hệ role – permission. Điều
này giúp cho việc gán cho các user tới các role xác định dễ dàng. Bản nghiên cứu NIST
[1] chỉ ra rằng các permission được phân cho các role có xu hướng thay đổi tương đối
chậm so với sự thay đổi thành viên những user các role. Nghiên cứu này cũng đã nhận
thấy việc cho phép các quản trị viên cấp hoặc hủy bỏ tư cách thành viên của các user
trong các role đang tồn tại mà không cho các quản trị viên này quyền tạo role mới hay
thay đổi sự phân chia role – permission là điều đang đựợc mong muốn.
Việc phân công các user theo role sẽ cần ít kĩ năng kĩ thuật hơn việc phân công các
permission theo role. Nếu không có RBAC, việc xác định permission nào được ủy thác
cho user nào sẽ khó.
Chính sách điều khiển truy cập được thể hiện ở các thành tố khác nhau của RBAC
như mối quan hệ role – permission, mối quan hệ user – role và mối quan hệ role – role.
Những thành tố này cùng xác định xem liệu một user cụ thể có được phép truy cập vào

5

môt mảng dữ liệu trong hệ thống hay không. Các thành tố RBAC có thể đựợc định dạng
trực tiếp bởi người sở hữu hệ thống hay gián tiếp bởi các role thích hợp mà người sở hữu
hệ thống ủy thác. Chính sách có hiệu lực trong một hệ cụ thể nào đó là kết quả cuối cùng
của việc định dạng các thành tố RBAC khác nhau một cách trực tiếp bởi người sở hữu hệ
thống. Ngoài ra chính sách điều khiển truy cập có thể gia tăng trong chu kì của hệ thống
và ở các hệ lớn điều này là chắc chắn xảy ra. Khả năng biến đổi chính sách để đáp ứng
được nhu cầu đang thay đổi của một tổ chức là một lợi ích quan trọng của RBAC.
Mặc dù RBAC là một chính sách trung lập, nó trực tiếp hỗ trợ ba nguyên tắc bảo
mật nổi tiếng: đặc quyền ít nhất, sự tách biệt các nhiệm vụ, trừu tượng hóa dữ liệu.
Nguyên tắc đặc quyền ít nhất đựợc hỗ trợ vì RBAC được định dạng do đó chỉ những
permission mà nhiệm vụ do các thành viên của role quản lí đó cần mới được phân cho
role đó. Sự tách biệt các nhiệm vụ đạt được bằng cách đảm bảo những role có quan hệ
loại trừ lẫn nhau phải đựơc sử dụng tới để hoàn thành một công việc nhạy cảm như yêu
cầu một nhân viên kế toán và một quản lí kế toán tham gia vào phát hành một tấm Sec.
Trừu tượng hóa dữ liệu được hỗ trợ bằng các permission trừu tượng như credit (bên có)
và debit (bên nợ) cho một tài khoản, chứ không phải là các permission đọc, viết, quản lí
thường đựợc hệ điều hành cung cấp. Tuy nhiên, RBAC không cho phép ứng dụng các
nguyên lý này. Nhân viên bảo mật có thể định dạng được RBAC do đó nó vi phạm những
nguyên lí này. Ngoài ra, mức độ trừu tuợng hóa dữ liệu đựợc hỗ trợ sẽ do các chi tiết bổ
sung quyết định.
RBAC không phải là giải pháp cho mọi vấn để kiểm soát truy cập. Người ta cần
những dạng kiểm soát truy cập phức tạp hơn khi xử lí các tình huống mà trong đó chuỗi
các thao tác cần được kiểm soát. Ví dụ, một lệnh mua cần nhiều bước trước khi đơn dặt
hàng mua được phát hành. RBAC không cố kiểm soát trực tiếp các permission cho một
chuỗi các sự kiện như vậy. Các dạng khác của kiểm soát truy cập đựợc cài đặt trên bề mặt
RBAC vì mục đích này. Việc kiểm soát một chuỗi các thao tác ngoài phạm vi của
RBAC, mặc dù RBAC có thể là nền móng để xây dựng những kiểm soát như thế.

6


2.3. Các vai trò và các khái niệm liên quan
Một câu hỏi thường được hỏi là “sự khác nhau giữa các role và các group là gì?”.
Các nhóm user như một đơn vị kiểm soát truy cập thường được nhiều hệ thống kiểm soát
truy cập cung cấp. Điểm khác biệt chính giữa hầu hết các group và khái niệm role là
group thường đựợc đối xử như một tập hợp những user chứ không phải là một tập hợp
các permission. Một role một mặt vừa là một tập hợp các user mặt khác lại là một tập
hợp các permission. Role đóng vai trò trung gian để kết nối hai tập hợp này lại với nhau.
Hãy xem xét hệ điều hành Unix. Thành viên nhóm trong Unix được xác định ở
trong hai file /ect/password và /ect/group. Do đó để xác định một user cụ thể thuộc
group nào hoặc xác định tất cả các thành viên của một group cụ thể là khá dễ dàng. Các
permission giành cho các nhóm dựa vào các permission kết hợp với các file cá nhân và
các thư mục. Để xác định permission nào một nhóm cụ thể thường có sẽ cần sự nghiên
cứu kĩ luỡng cả một cây hệ thống file. Do đó việc xác định thành viên của nhóm thường
dễ hơn việc xác định permission của nhóm. Ngoài ra, việc giao permission cho nhóm
được phi tập trung hóa cao. Về cơ bản, người sở hữu một sub-tree (cây con) của hệ thống
file Unix có thể giao permission của sub-tree đó cho một nhóm. (mức độ chính xác việc
này có thể làm được phụ thuộc vào dạng Unix cụ thể được nói đến). Tuy nhiên, nhóm
Unix có thể được dùng để thực hiện role trong hoàn cảnh cụ thể mặc dù theo khái niệm
role của chúng tôi các nhóm không giống nhau.
Để minh họa bản chất sự khác biệt của group và role, hãy xem xét hệ thống mang
tính giả thuyết mà cần gấp đôi thời gian để xác định thành viên nhóm so với xác định
permission của nhóm. Hãy cho rằng permission của nhóm và thành viên nhóm chỉ có thể
được nhân viên bảo mật hệ thống thay đổi. Trong trường hợp này, cơ chế nhóm sẽ trở nên
rất gần với khái niệm role của chúng tôi.
Một vấn đề được quan tâm nữa là mối quan hệ giữa role và Compartment.
Compartment là một phần của cấu trúc nhãn bảo mật được sử dụng trong quốc phòng
hay các cơ quan nhà nước. Compartment dựa vào quan điểm cần là biết (need-to-know)

7


có nghĩa rộng đối với thông tin có sẵn ở một nhãn compartment tương tự nghĩa ngữ
nghĩa của role. Tuy nhiên, người ta sử dụng compartment cho một chính sách sở hữu
thông tin một chiều riêng biệt trong hàng rào các nhãn. Role không thực hiện chính sách
nào thuộc loại này cả.
Lâu nay vẫn tồn tại sự khác biệt giữa kiểm soát truy cập theo ý muốn và kiểm soát
truy cập bắt buộc được biết đến lần lượt là DAC và MAC. Sự khác biệt này xuất hiện khi
người ta nghiên cứu bảo mật trong ngành quốc phòng. MAC cho phép việc kiểm soát truy
cập dựa vào nhãn bảo mật gửi kèm tới các user (chính xác hơn là chủ thể) và khách thể
(object). DAC cho phép kiểm soát truy cập thực hiên được đối với khách thể (object) dựa
trên cơ sở permission hoặc từ chối hoặc cả hai do một user riêng biệt, thường là người sở
hữu object đó định dạng. RBAC có thể được xem như một thành tố kiểm soát truy cập
độc lập, cùng tồn tại với MAC và DAC lúc thích hợp. Trong trường hợp này việc truy
cập sẽ được phép nếu RBAC, MAC và DAC cho phép. Hi vọng rằng RBAC trong nhiều
trường hợp sẽ tự nó tồn tại.
Như một vấn đề liên quan, RBAC bản thân nó là một cơ chế tùy ý hay bắt buộc?
Câu trả lời phụ thuộc vào định nghĩa chính xác của cái quan niệm “tùy ý” và “bắt buộc”
cũng như là bản chất thực và sự định hình các permission, role và user trong một hệ
thống RBAC. Việc hiểu bắt buộc có nghĩa là các user cá nhân không có sự lựa chọn nào
đối với việc permission hoặc user nào được giao đến một role nào, trong khi tùy ý có
nghĩa là user được tự đưa ra các quyết định này. Như đã nói ở trên, RBAC bản thân nó là
một chính sách trung tính. Các dạng nhất định nào đó của RBAC có thể là bắt buộc, trong
khi các dạng khác có thể lại là tùy ý.

2.4. Các mô hình một họ tham chiếu
Để hiểu các chiều khác nhau của RBAC, cần xác định một dòng của 4 mô hình khái
niệm. Mối quan hệ giữa 4 mô hình này được trình bày ở Hình 2.1(a) và các đặc điểm cơ

bản được minh họa ở Hình 2.1(b). RBAC0, mô hình cơ bản nằm ở dưới cùng cho thấy đó
là yêu cầu tối thiểu cho bất kì một hệ thống nào hỗ trợ RBAC. RBAC1 và RBAC2 đều

8


bao gồm RBAC0 nhưng có thêm một số nét khác với RBAC0. Chúng được gọi là các mô
hình tiên tiến. RBAC1 có thêm khái niệm cấp bậc role (khi các role có thể kế thừa
permission từ role khác). RBAC2 có thêm những ràng buộc (đặt ra các hạn chế chấp
nhận các dạng của các thành tố khác nhau của RBAC). RBAC1 và RBAC2 không so
sánh được với nhau. Mô hình hợp nhất RBAC3 bao gồm cả RBAC1 và RBAC2 và cả
RBAC0 nữa.
Những mô hình này là điểm tham chiếu để so sánh với các hệ thống và mô hình
khác mà những nhà nghiên cứu và phát triển khác sử dụng. chúng cũng như một chỉ dẫn
cho việc phát triển sản phẩm và sự đánh giá sản phẩm của các khách hàng tiềm năng
trong tương lai. Hiên tại, cứ cho rằng có một security officer (nhân viên an ninh) là
người duy nhất có thẩm quyền định ra các thiết lập và các mối liên hệ của những mô hình
này. Sau này chúng tôi sẽ giới thiệu một mô hình quản lí tinh vi hơn.

(a) Quan hệ giữa các mô hình RBAC

9


(b) Các mô hình RBAC
Hình 2.1: Một họ của các mô hình RBAC

2.5. Mô hình cơ sở
Mô hình cơ sở RBAC0 trình bày trong bao gồm phần ở Hình 2.1(b), không phải là
một trong 3 mô hình tiên tiến. Có 3 nhóm thực thể được gọi là user (U), role (R) và

permission (P). Một tập hợp các session (S) đựợc thể hiện trong biểu đồ.
User trong mô hình này là con người. Khái niệm user sẽ được khái quát hóa bao
gồm cả các tác nhân thông minh và tự chủ khác như robot, máy tính cố định, thậm chí là
các mạng lưới máy tính. Để cho đơn giản, nên tập trung vào user là con người. Một role
là một chức năng công việc hay tên công việc trong tổ chức theo thẩm quyền và trách
nhiệm trao cho từng thành viên. Một permission là một sự cho phép của một chế độ cụ
thể nào đó truy cập vào một hay nhiều object trong hệ thống. Các thuật ngữ
authorization (sự xác thực), access right (quyền truy cập) và privilege (quyền ưu tiên)
đều để chỉ một permission. Các permission luôn tích cực và trao cho người có

10


permission khả năng thực hiện một vài công viêc trong hệ thống. Các object là các số
liệu object cũng như là các nguồn object được thể hiện bằng số liệu trong hệ thống máy
tính. Mô hình chấp nhận một loạt các cách diễn giải khác nhau cho các permission, ví dụ,
từ những hạt rất to và thô (từ những cái sơ lược nhất) ở đó được phép truy cập vào cả một
mạng nhỏ, tới những hạt mịn (những cái tinh vi) nơi mà đơn vị truy cập chỉ là một lĩnh
vực riêng nào đó của một bản chi nào đó.
Một số tài liệu về kiểm soát truy cập nói về permission từ chối “negative
permission”. Cái này từ chối, chứ không cho phép truy cập. Trong bài, việc từ chối truy
cập được gọi là sự hạn chế chứ không phải là một permission từ chối.
Bản chất của permission phụ thuộc nhiều vào các chi tiết thực hiện của một hệ
thống mà loại hệ thống đó là gì. Một mô hình khái quát của kiểm soát truy cập do đó phải
coi các permission như các biểu tượng không ngắt quãng về mặt nào đó. Mọi hệ thống
đều bảo vệ các object trừu tượng mà nó thực hiện. Do đó, một hệ điều hành bảo vệ các
thứ như file, thư mục, thiết bị, và các cổng và các thao tác như đọc, viết và thực thi. Một
hệ thống quản lí cơ sở dữ liệu có quan hệ sẽ bảo vệ các mối quan hệ, các tipple, thuộc tính
và các hiển thị với các thao tác SELECT, UPDATE, DELETE, và INSERT. Một ứng
dụng kế toán sẽ bảo vệ các tài khoản và các sổ cái với các thao tác debit (ghi bên nợ),

credit (ghi bên có), transfer (chuyển khoản), create-account (tạo tài khoản), và deleteaccount (xóa tài khoản). Thao tác credit (ghi vào bên có) đó nên được phân cho một role
chứ không nên bắt buộc phải phân cho role đó cả thao tác debit (ghi vào bên nợ) nữa.
Các permission có thể áp dụng cho một object hay nhiều object. Ví dụ, một
permission có thể cụ thể như đọc lệnh truy cập vào một file riêng biệt nào đó hoặc có thể
là chung chung như đọc lệnh truy cập tới tất cả các file thuộc một bộ phận nào đó. Các
permission cá nhân được cho vào một permission chung , do đó chúng có thể được giao
với tư cách một đơn vị riêng biệt. Việc làm này phụ thuộc nhiều vào sự cài đặt.
Hình 2.1(b) cũng thể hiện mối quan hệ giữa việc phân công các user và giao cáo
permission. cả hai việc này đều có nhiều quan hệ qua lại. một user có thể là một thành

11


viên của nhiều role, và một role có thể có nhiều user. Tương tự như thế, một role có thể
có nhiều permission, và cùng một permission có thể được giao cho nhiều role. Mấu chốt
của RBAC nằm ở hai mối quan hệ này. Rut cục thì chính user là người thực hiện các
permission. Sự sắp đặt một role như một phương tiện trung gian cho phép user thực hiện
một permission tạo cho sự kiểm soát lớn lên sự định dạng và xem xét truy cập hơn nhiều
so với việc để user tiếp cận trực tiếp với permission.
Mỗi session là một tham chiếu của một user tới những role có thể, ví dụ, một user
thiết lập một session khi mà user kích hoạt một vài tập con của các role mà anh ấy hay cô
ấy là một thành viên. Mũi tên hau đầu từ session to R trong Hình 2.1(b) cho biết những
role được kích hoạt cùng lúc. Permission có thể được user kết hợp các permission từ tất
cả các role được kích hoạt trong session đó. Mỗi session được kết hợp với một đơn người
dùng, như cho biết bởi mũi tên một đầu từ session tới U trong Hình 2.1(b). Sự kết hợp
này lưu giữ hằng cho cuộc sống của một session.
Một user có thể có đa sessions mở trong cùng một thời gian, mỗi cái trong một cửa
sổ trên màn hình của máy trạm cho từng trường hợp. Mỗi session có thể có một sự kết
hợp khác của những role hoạt động. Tính năng này của RBAC0 trợ giúp nguyên tắc của
quyền lợi tối thiểu. Một user là thành viên của một vài role có thể gọi nhiều tập con của

chúng mà phù hợp cho công việc đã hoàn thành trong session đó. Như vậy, một user là
một thành viên của một role quyền lực nhất có thể thông thường giữ role không hoạt
động này và rõ ràng kích hoạt nó khi cần thiết. Có thể trì hoãn sự xem xét của tất cả các
loại của ràng buộc, bao gồm các ràng buộc trên các role đang hoạt động, với RBAC2.
Như thế trong RBAC0 nó được toàn vẹn tùy vào sự thận trọng của user như với những
role được kích hoạt trong một session định sẵn. RBAC0 cũng cho phép những role kích
hoạt và không kích hoạt động trong suốt thời gian hiệu lực của session. Khái niệm của
một session tương đương với quan niệm truyền thống của một chủ thể trong khi truy cập
điều khiển tài liệu. Một chủ thể (hay một session) là một đơn vị của truy cập điều khiển,
và một user có thể có đa chủ thể (hay session) khác với nhưng permission hoạt động
trong cùng một thời gian.

12


Công thức định nghĩa được cho bên dưới
Định nghĩa 1: Mô hình RBAC0 có các thành phần:
• U, R, P và S (user, roles, permission và session riêng biệt)
• PA ⊆ P x R, một quan hệ nhiều – nhiều gán cho permission tới role.
• UA ⊆ U x R, một quan hệ nhiều – nhiều gán cho user tới role.
• user: S → U, một chức năng ánh xạ mỗi session si tới một user user(si) (Hằng số
cho thời gian tồn tại của session) và
• roles: S → 2R, một chức năng tham chiếu mỗi session si tới một sự thiết lập roles
roles(si) ⊆ { r | (user(si),r)) ∈ UA}.

Hình 2.2: Mô hình RBAC0
Chúng tôi mong chờ mỗi role được gán ít nhất một permission và mỗi user được
gán ít nhất một role. Với mô hình này, tuy nhiên, không yêu cầu điều này.
Như đã được nói ở trên, RBAC0 xử lý các permission như những ký hiệu chưa
được thông dịch bởi vì bản chất rõ ràng của một permission là sự cài đặt và sự phụ thuộc

hệ thống. Các permission được sửa đổi để thiết lập U, R và P và quan hệ PA và UA được
gọi bởi các permission quản lý. Những điều này sẽ được thảo luận sau trong mô hình
quản lý cho RBAC. Còn bây giờ thừa nhận rằng chỉ có một mình nhân viên bảo vệ có thể
thay đổi những thành phần này.

13


Những session dưới sự điều khiển của những user riêng lẻ. Như những mô hình có
liên quan, một user có thể tạo ra một session và chọn để kích hoạt một vài tập con của
những role của user. các role hoạt động trong một session có thể đuợc thay đổi trong sự
thận trọng của user. Session giới hạn bởi năng lực của user. Một vài hệ thống sẽ giới hạn
một session nếu nó không hoạt động động trong thời gian quá dài. Nói đúng ra, đây là
một ràng buộc và hợp lý trong RBAC2.
Một trách nhiệm là một nghĩa vụ trên một phần của user để thi hành một hay nhiều
nhiệm vụ, nói chung là rất cần thiết cho các hoạt động trơn tru của một tổ chức. Trong
trách nhiệm của chúng tôi được xem như một khái niệm nâng cao mà không thuộc trong
RBAC0. Chúng tôi đã chọn không kết hợp trách nhiệm trong mô hình nâng cao và cảm
nhận sự không kết hợp các khái niệm giống như trách nhiệm trong mô hình điều khiển
truy cập yêu cầu nghiên cứu trong tương lai. Một cách tiếp cận là xử lý chúng giống như
với các permission. Những cách tiếp cận khác có thể là cơ sở cho mô hinhg điều khiển
truy cập mới giống như nhiệm vụ dựa trên sự xác thực [4].

2.6. Role có cấp bậc

(a)

14

(b)

(c)
Hình 2.3: Các ví dụ của Role Hierarchies

15


(a) Role Hierarchies

(b) Quản lý Role Hierarchies

16


(c) Sự riêng tư và phạm vi của Role
Hình 2.4: Role Hierarchies cho một dự án

Mô hình RBAC1 giới thiệu role có thứ bậc (RH), giống như đã trình bày sơ qua
trong Hình 2.1. Chúng cũng được cài đặt thông thường trong hệ thống như các role cung
cấp. Role có thứ bậc có một nghĩa tự nhiên cho các role có cấu trúc để phản ánh một tổ
chức của permission và trách nhiêm. Ví dụ về role có thứ bậc được thấy trong Hình 2.3.
Bởi việc quy ước các role nhiều quyền lực hơn được hiện thị phía trên các sơ đồ và các
role ít quyền lực hơn phía dưới sơ đồ. Trong Hình 2.3(a) role của người có chức vụ thấp
là Health-care provider. Role là Physician là người có chức cao hơn Health-care
provider và do đó thừa kế tất cả các permission từ Health-care provider. Thừa kế của
permission nói rõ ra, cho ví dụ, trong Hình 2.3(a), role là Primary-care Physician thừa
kế permission từ Physician và Health-care provider. Cả Primary-care Physician và
Specialist Physician đều thừa kế permission từ role của Physician, nhưng mỗi loại này
sẽ có những permission khác nhau được gán trực tiếp tới chúng. Hình 2.3(b) giải thích đa

17