ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Đặng Ngọc Tuyên
NGHIÊN CỨU NGÔN NGỮ ĐẶC TẢ SECURITY POLICY
VÀ XÂY DỰNG CÔNG CỤ HỖ TRỢ
KHÓA 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
ii
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Đặng Ngọc Tuyên
NGHIÊN CỨU NGÔN NGỮ ĐẶC TẢ SECURITY POLICY
VÀ XÂY DỰNG CÔNG CỤ HỖ TRỢ
KHÓA 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
i
HÀ NỘI - 2009
LỜI CẢM ƠN
Em xin cảm ơn bộ môn Công nghệ phần mềm – khoa công nghệ thông tin- Đại
Học Công Nghệ - Đại Học Quốc Gia Hà Nội đã cho phép và giúp đỡ em thực hiện khóa
luận này. Xin cảm ơn quý thầy cô trong khoa Công nghệ thông tin đã tận tình chỉ bảo,
rèn luyện, truyền đạt những chi thức, kỹ năng, kinh nghiệm quý báu cho em trong suốt
bốn năm ở giảng đường đại học. Đây là những hành trang quý giá để em bước vào đời.
Khóa luận sẽ không thể hoàn thành nếu như không có sự giúp đỡ, hướng dẫn và
tận tình chỉ bảo của TS. Trương Ninh Thuận, người thầy đã đi cùng em trong suốt thời
gian em nghiên cứu và thực hiện khóa luận này. Em xin chân thành biết ơn về những chỉ
bảo, định hướng nghiên cứu và thực hiện, hỗ trợ, và tạo điều kiện tốt nhất cho em.
Mặc dù đã hết sức nỗ lực và cố gắng, nhưng chắc chắn khóa luận sẽ không tránh
khỏi những khuyến khuyết. em kính mong nhận được sự cảm thông và tận tình chỉ bảo
của quý thầy cô và các bạn.
Hà Nội, ngày 15 tháng 05 năm 2009
Sinh viên: Đặng Ngọc Tuyên
ii
TÓM TẮT KHÓA LUẬN
Trong thời đại ngày nay, với sự phát triển nhanh chóng của công nghệ thông tin và
xu hướng hội nhập kinh tế quốc tế, nhu cầu trao đổi thông tin và tài nguyên giữa các tổ
chức , cá nhân thông qua mạng Internet ngày càng gia tăng. Từ việc trao đổi thông tin thư
từ cho đến việc trao đổi và chia sẻ tài nguyên như hình ảnh âm thanh, các tài liệu…tất cả
giờ đây đã được số hóa. Các ứng dụng theo mô hình cổ điển – chỉ hoạt động trên desktop
và có ít người sử dụng ngày càng trở nên không phù hợp với thực tế cuộc sống nữa. Các
ứng dụng ngày nay đều đòi hỏi phải có khả năng kết nối với mạng Internet và phục vụ
được hàng triệu người sử dụng trong cùng một thời điểm. Và xuất phát từ thực tế đó, một
vấn đề nảy sinh ra đó là làm thế nào để đảm bảo an ninh và bảo mật dữ liệu trong một hệ
thống đa người dùng như vậy ? đây chính là lý do cho sự ra đời của các mô hình điều
khiển truy cập.
Nội dung khóa luận đưa ra một cái nhìn tổng quát về các mô hình điều khiển truy
cập phổ biến đặc biệt chú trọng là mô hình điều khiển truy cập trên cơ sở vai trò –
RBAC. Từ những kiến thức cơ bản đó khóa luận tiến tới việc đặc tả các chức năng quản
trị cơ bản trong một hệ thống cài đặt mô hình RBAC.
Sau khi đưa những kiến thức lý thuyết một cách chi tiết và dễ hiểu vể RBAC,
khóa luận tiến hành phân tích , thiết kế và cài đặt một công cụ hỗ trợ cho các nhà quản trị
website trong việc điều khiển truy cập, công cụ này sẽ cài đặt những chức năng cơ bản
nhất của mô hình RBAC.
iii
MỤC LỤC
CHƯƠNG 1. ĐẶT VẤN ĐỀ ...................................................................................................... 1
1.1. Bối cảnh ................................................................................................................................ 1
1.2. Muc tiêu của đề tài ............................................................................................................... 2
1.3. Cấu trúc của khóa luận ......................................................................................................... 2
CHƯƠNG 2. CÁC MÔ HÌNH ĐIỀU KHIỂN TRUY CẬP ...................................................... 4
2.1. Giới thiệu tổng quan ............................................................................................................. 4
2.2. Mô hình điều khiển truy cập tùy quyền DAC ...................................................................... 4
2.3. Mô hình điều khiển truy cập bắt buộc MAC ....................................................................... 4
2.4. Mô hình điều khiển truy cập trên cơ sở vai trò RBAC ........................................................ 5
CHƯƠNG 3. ROLE-BASED ACCESS CONTROL ................................................................. 8
3.1. Nền tảng và sự phát triển ...................................................................................................... 8
3.2. Vai trò và các định nghĩa liên quan ...................................................................................... 9
3.3. Họ mô hình RBAC ............................................................................................................. 11
3.3.1. Core RBAC (RBAC 0) ................................................................................................ 11
3.3.2. Role hierarchy ............................................................................................................ 13
3.3.3. Constrained RBAC ...................................................................................................... 15
3.3.4. RBAC 3 ....................................................................................................................... 18
3.4. Hệ thống RBAC và đặc tả các chức năng quản trị ............................................................ 19
3.4.1. Core RBAC ................................................................................................................. 19
3.4.2. Role hierarchy ............................................................................................................. 27
CHƯƠNG 4. PHÂN TÍCH VÀ THIẾT KẾ CÔNG CỤ HỖ TRỢ .......................................... 33
4.1.Mô hình use case ................................................................................................................. 34
4.1.1. Danh sách các tác nhân ............................................................................................... 34
4.1.2. Sơ đồ use case: ............................................................................................................ 35
4.1.3. Giải thích một số use case quan trọng ........................................................................ 36
4.1.3.2. Add user .................................................................................................................... 37
4.1.3.3. User Assignment ...................................................................................................... 38
4.1.3.4. Permission Assignment ............................................................................................ 39
4.1.3.5. Session Establishing ................................................................................................. 40
4.2. Mô hình đối tượng .............................................................................................................. 41
4.3. Mô hình hóa động .............................................................................................................. 42
4.3.1. Biểu đồ tuần tự (sequence diagram): .......................................................................... 42
4.3.2. Biểu đồ hợp tác ............................................................................................................ 43
4.3.2.1. Biểu đồ hợp tác: User Assignment .............................................................................. 43
.................................................................................................................................................... 43
Hình 16. Biểu đồ hợp tác: User Assignment ........................................... 43
4.3.2.1. Biểu đồ hợp tác: permission Assignment .................................................................... 44
4.4. Thiết kế cơ sở dữ liệu ......................................................................................................... 44
CHƯƠNG 5. CÀI ĐẶT CHƯƠNG TRÌNH VÀ THỰC NGHIỆM ........................................ 46
5.1. Môi trường và công cụ cần thiết ........................................................................................ 46
5.2. Cài đặt local webserver trên Ubuntu 8.10 .......................................................................... 46
5.3. Sử dụng thư viện nguồn mở ADODB thao tác với cơ sở dữ liệu ..................................... 47
5.4. Các chức năng chính của chương trình .............................................................................. 48
5.5. Phát triển ứng dụng ........................................................................................................... 48
5.5.1. Quản lý các vai trò và người sử dụng ......................................................................... 48
5.5.2. Chức năng quản lý các đặc quyền ............................................................................... 50
5.5.3. Chức năng quản lý các miền đối tượng ..................................................................... 51
iv
5.6. Kiểm thử ............................................................................................................................. 52
5.6.1. Đề xuất các trường hợp kiểm thử ............................................................................... 52
output ..................................................................................................................................... 53
5.6.2. Tiến hành kiểm thử và kết quả .................................................................................... 53
5.6.2.1. Test case 1 .................................................................................................................... 53
Kết quả của chương trình khi thực hiện lệnh gán người sử dụng ngoctuyen vào vai trò
publisher ..................................................................................................................................... 53
.................................................................................................................................................... 53
5.6.2.1. Test case 2 .................................................................................................................... 54
Kết quả của chương trình khi thực hiện lệnh gán người sử dụng ben vào vai trò editor ......... 54
5.7 Kết quả đạt được sau khi hoàn thành chương trình ............................................................ 55
5.8. Những hạn chế của chương trình ....................................................................................... 55
5.9. Hướng phát triển chương trình trong tương lai ................................................................. 56
KẾT LUẬN .................................................................................................................................... 57
v
DANH SÁCH CÁC HÌNH VẼ
Hình 1. Điểm khác biệt giữa RBAC và các mô hình truyền thống................................................7
Hình 2: Họ RBAC........................................................................................................................11
Hình 3. Mô hình tổng quát Core RBAC.......................................................................................12
Hình 4. Mô hình tổng quát Role hierarchy ( RBAC 1).................................................................13
Hình 5: Mô hình tổng quát các quan hệ SSD...............................................................................16
Hình 6: Mô hình tổng quát các quan hệ DSD..............................................................................17
Hình 7: Mô hình tổng quát RBAC cấp cao nhất - RBAC 3........................................................18
Hình 8: Mô hình RBAC cấp cao nhất – triển khai chi tiết.........................................................19
Hình 9. Component view của mô hình use case cho RBAC........................................................34
Hình 10. sơ đồ use case theo từng gói chi tiết..............................................................................35
Hình 11: Mô hình đối tượng của RBAC.......................................................................................41
Hình 12: Các lớp thực thể trong mô hình đối tượng của RBAC.................................................41
Hình 13: Các lớp cơ sở và mối quan hệ giữa chúng.....................................................................42
Hình 14: Biểu đồ tuần tự: User Asignment...................................................................................42
Hình 15: Biểu đồ tuần tự: Permission Assignment.......................................................................43
Hình 17 Biểu đồ hợp tác: permission Assignment.......................................................................44
Hình 18: Mô hình cơ sở dữ liệu quan hệ của ứng dụng RBAC..................................................45
Hình 19. Màn hình nhập liệu chức năng quản lý vai trò..............................................................48
Hình 20. Màn hình nhập liệu chức năng quản lý người sử dụng.................................................49
Hình 21. Màn hình nhập liệu chức năng gán người sử dụng vào các vai trò...............................49
Hình 23. Màn hình nhập liệu chức năng quản lý các hành động.................................................50
Hình 24. Màn hình nhập liệu chức năng gán các hành động vào đặc quyền...............................50
Hình 25. Màn hình nhập liệu chức năng quản lý đối tượng.........................................................51
Hình 26. Màn hình nhập liệu chức năng quản lý miền đối tượng................................................51
Hình 27. kết quả thực hiện gán người sủ dụng vào vai trò trong test 1........................................53
Hình 28. kết quả thực hiện cấp quyền cho vai trò trong test 1.....................................................54
Hình 29. kết quả thực hiện gán người sử dụng vào vai trò trong test 2.......................................54
vi
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
Role-based access control – điều khiển truy cập trên cơ sở vai
trò
GFAC
Generalized Framework for Access Control – kiến trúc
frameword tổng quát cho điều khiển truy cập
ACL
Access control list – Danh sách điều khiển truy cập
least privilege
Đặc quyền tối thiểu
separation of
duties
Phân chia trách nhiệm
SSD
Static separation of duties – phân chia trách nhiệm tĩnh
DSD
Dynamic separation of duties – phân chia trách nhệm động
data abstraction
Trừu tượng hóa dữ liệu
Role hierarchy
Cấp bậc trong vai trò
Core RBAC
Mô hình RBAC cơ sở
Constrained RBAC
Các ràng buộc RBAC
ROLE data set
Tập hợpc các vai trò
SSD role set
Tập hợp các vai trò có thêm ràng buộc SSD
USER data set
Tập hợp người sử dụng
OBJS data set
Tập hợp các đối tượng
OPS
Tập hợp các hành động trên một đối tượng cụ thể
vii
CHƯƠNG 1. ĐẶT VẤN ĐỀ
1.1. Bối cảnh
Ngày nay, công nghệ thông tin đang là ngành công nghiệp mũi nhọn trong chiến
lược phát triển kinh tế và xây dựng đất nước của hầu hết các quốc gia. Các sản phẩm
công nghệ thông tin đã và đang được ứng dụng trong mọi lĩnh vực của đời sống kinh tế,
xã hội và hầu hết đều đem lại những giá trị thiết thực.
Đối tượng phục vụ chính của ngành công nghệ thông tin hiện nay chính là các tổ
chức, các doanh nghiệp…Nhu cầu ứng dụng các sản phẩm của ngành công nghiệp mũi
nhọn này để hỗ trợ tin học hóa quy trình nghiệp vụ mà từ trước đến nay vốn vẫn được
thực hiện một cách thủ công đang ngày càng trở nên cấp thiết. Các sản phẩm dạng này
đều có một đặc điểm chung là có độ phức tạp cao, chi phí sản xuất và bảo trì lớn, mức độ
cụ thể còn tùy vào độ lớn của tổ chức cũng như độ phức tạp của các quy trình nghiệp vụ
cần xử lý.
Với sự phát triển nhanh chóng của Internet cộng thêm với xu hướng hội nhập chung
của toàn thế giới, các tổ chức, cá nhân cần bắt tay, phối hợp hoạt động và chia sẻ tài
nguyên với nhau để nâng cao hiệu quả hoạt động. Lúc này các sản phẩm sẽ có độ phức
tạp cao hơn, kéo theo đó là chi phí sản xuất, quản lý và bảo trì. Các ứng dụng lúc này sẽ
có hàng trăm đến hàng triệu người sử dụng trong cùng một thời điểm. Như vậy với xu
hướng mới đó ngành công nghệ phần mềm lại phải đối mặt với các vấn đề khó khăn như
vấn đề tái sử dụng và mở rộng các hệ thống sẵn có, vấn đề về an ninh bảo mật. Nhưng có
lẽ vấn đề khó khăn nhất chính là vấn đề an ninh và bảo mật. Phải làm thế nào để đảm bảo
rằng chỉ những người dùng đã được xác thực mới được phép truy cập đến dữ liệu hay tài
nguyên nào đó trong một hệ thống.
Trước những yêu cầu cấp thiết như trên, các nhà phát triển hệ thống và các nhà phát
triển phần mềm đã bắt đầu nghiên cứu các chính sách điều khiển truy cập (Access
control). Mô hình đầu tiên được đưa ra là DAC [11] (mô hình điều khiển truy cập tùy
quyền), tiếp theo đó là MAC [11] (mô hình điều khiển truy cập bắt buộc) và cuối cùng là
RBAC (mô hình điều khiển truy cập trên cơ sở vai trò). Mỗi mô hình trên đều có những
ưu điểm và nhược điểm riêng, song cho đến ngày nay RBAC [5] vẫn là mô hình được
1
đánh giá là đã giải quyết những khó khăn trên một cách tối ưu nhất và sẽ là xu thế tương
lai. Thế thì RBAC là gì ? cách nó giải quyết những vấn đề khó khăn ở trên như thế nào?
Đây chính là lý do chúng tôi thực hiện đề tài này.
1.2. Muc tiêu của đề tài
Để thực hiện những vấn đề đã nêu ra ở trên, khóa luận sẽ lần lượt trình bày những
kiến thức cần thiết để giải quyết bài toán đặt ra. Khóa luận sẽ tập trung vào các vấn đề
sau:
• Tìm hiểu khái quát về các mô hình điều khiển truy cập phổ biến là DAC,
MAC và RBAC. Phân tích và đánh giá điểm mạnh và điểm yếu của từng
mô hình.
• Tìm hiểu chi tiết về mô hình điều khiển truy cập trên cơ sở vai trò RBAC từ
mô hình cơ sở đến mô hình cấp cao nhất, đưa ra được các đặc tả chức năng
quản trị cho từng mô hình trong họ gia đình RBAC.
• Phân tích, thiết kế và cài đặt một công cụ hỗ trợ nhà quản trị trong việc
quản lý và điều khiển truy cập.
1.3. Cấu trúc của khóa luận
Các phần còn lại của khóa luận bao gồm các phần sau:
Chương 2: Trình bày tổng quan về điều khiển truy cập, giới thiệu các mô hình
điều khiển truy cập phổ biến là DAC, MAC và RBAC. So sánh ưu điểm và
nhược điểm giữa chúng.
Chương 3: Trình bày chi tiết về mô hình điều khiển truy cập trên cơ sở vai trò
RBAC. Tìm hiểu chi tiết về từng mô hình trong họ các mô hình RBAC, và cuối
cùng là đặc tả các chức năng quản trị trong các mô hình thuộc họ các mô hình
RBAC.
Chương 4: Sẽ phân tích, thiết kế một ứng dụng trên nền web, ứng dụng này sẽ áp
dụng mô hình RBAC trong việc quản lý và điều khiển truy cập đối với người sử
dụng.
2
Chương 5: Trình bày quá trình cài đặt và thực nghiệm đối với ứng dụng đã phân
tích thiết kế trong chương 4, đưa ra các kết quả đạt được.
3
CHƯƠNG 2. CÁC MÔ HÌNH ĐIỀU KHIỂN TRUY CẬP
2.1. Giới thiệu tổng quan
Bắt đầu từ những thập niên 70, các hệ thống máy tính đưa ra rất nhiều các ứng
dụng và phục vụ rất nhiều người dùng trên khắp thế giới, do đó đã làm tăng khả năng
nhận thức về bảo mật dữ liệu. Các nhà phát triển hệ thống và các nhà phát triển phần
mềm đều quan tâm đến các kiểu của điều khiển truy cập (access control) để chắc chắn
rằng chỉ những người dùng đã được xác thực mới có thể truy cập đến dữ liệu hoặc tài
nguyên nào đó. Xuất phát từ thực tế đó, một số mô hình điều khiển truy cập đã được
đưa ra. Trong đó nổi tiếng nhất là ba mô hình: MAC (mandatory access control), DAC
(discretionary access control) và RBAC (Role-based access control).
2.2. Mô hình điều khiển truy cập tùy quyền DAC
Trước tiên chúng ta tìm hiểu về DAC. Theo định nghĩa chính thức thì DAC hay
còn gọi là mô hình điều khiển truy cập tùy quyền là một phương pháp nhằm hạn chế
truy cập các đối tượng trên cơ sở nhận dạng (identity) và nhu cầu cần biết (need-to-
know) của nhiều người dùng và/hoặc của một nhóm các đối tượng trực thuộc. Phương
pháp điều khiển truy cập được coi là tùy quyền là vì một chủ thể với một phép truy cập
nào đó có thể chuyển nhượng phép truy cập (trực tiếp hay gián tiếp) sang bất cứ một
chủ thể nào khác trong hệ thống. Nói cách khác, kỹ thuật này cho phép người dùng có
toàn quyền quyết định quyền truy cập được công nhận cho các tài nguyên của họ, có
nghĩa là họ có thể (tình cờ hay ác ý) ban quyền truy cập cho những người dùng bất hợp
pháp.
2.3. Mô hình điều khiển truy cập bắt buộc MAC
MAC – hay còn gọi là mô hình điều khiển truy cập bắt buộc là một kỹ thuật được
dùng để bảo vệ các quy trình máy tính, dữ liệu và các thiết bị hệ thống khỏi sự lạm
dụng. Kỹ thuật này được phát triển để mở rộng và thay thế kỹ thuật điều khiển truy cập
tùy quyền DAC đối với các phép truy cập và sử dụng hệ thống tệp tin cùng những khái
niệm về người dùng và nhóm người dùng.
4
Đặc trưng quan trọng nhất của MAC bao hàm việc từ chối người dùng toàn quyền
truy cập/ sử dụng tài nguyên do chính họ tạo ra. Chính sách an ninh của hệ thống (như
đã được administrator quy định) hoàn toàn quyết định các quyền truy cập được công
nhận và một người dùng không thể tự hạn chế quyền truy cập vào các tài nguyên của họ
hơn những gì mà administrator chỉ định.
Mục đích của MAC là định nghĩa một kiến trúc mà trong đó nó đòi hỏi sự đánh
giá tất cả các label có liên quan đến vấn đề an ninh an ninh (security-related labels) và
đưa ra những quyết định dựa trên cơ sở ngữ cảnh của các thao tác cùng các nhãn dữ liệu
(data labels) tương đồng. Kiến trúc FLASK và những kiến trúc cơ cấu tổ chức tổng quát
đối với điều khiển truy cập (Generalized Framework for Access Control - GFAC), đi đôi
với MAC, trở thành những kỹ thuật khả thi cho những hệ thống an ninh đa tầng cấp
(multilevel security systems).
Một kiến trúc như vậy sẽ ngăn chặn một người dùng đã được xác thực, hoặc một
quy trình tại một phân hạng cụ thể nào đấy, hoặc có một mức độ tin cẩn (trust-level)
nhất định nào đấy, không cho họ truy cập thông tin, truy cập các tiến trình hoặc truy cập
các thiết bị ở một tầng cấp khác. Kết quả của việc này là nó cung cấp cho chúng ta một
cơ chế chính sách ngăn chặn đối với người dùng và các quy trình, hoặc biết, hoặc chưa
biết (lấy ví dụ, một chương trình ứng dụng lạ, chưa từng thấy (unknown program có thể
bao hàm một chương trình ứng dụng không đáng tin (untrusted application) và hệ thống
phải theo dõi, giám sát và/hay khống chế những truy cập của nó vào các thiết bị và các
tập tin).
2.4. Mô hình điều khiển truy cập trên cơ sở vai trò RBAC
Trong an ninh đối với các hệ thống máy tính, điều khiển truy cập trên cơ sở vai trò
(RBAC) là một trong số các phương pháp điều khiển và đảm bảo quyền sử dụng cho
người dùng. Đây là một phương pháp có thể thay thế đ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).
Điều khiển truy cập dựa trên cơ sở vai trò (RBAC) khác với các hình thức điều
khiển truy cập tùy quyền – DAC và điều khiển truy cập bắt buộc – MAC. DAC và MAC
5
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 DAC thì người ta chỉ có thể cho rằng hệ thống đó dùng MAC mà
không có lựa chọn thứ ba. Song sau những cuộc nghiên cứu vào những năm 90 đã cho
thấy RBAC không phải là DAC hay MAC.
Trong nội bộ một tổ chức, các vai trò (role) đượ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ể. Các thành viên trong lực
lượng cán bộ công nhân viên (hoặc những người dùng trong hệ thống) được phân phối
một vai trò riêng, và thong 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 trực tiếp, mà chỉ tiếp thu được quyền hạn
thông qua vai trò của họ (hoặc các vai trò), việc quản lý quyền hạn của người dùng trở
thành một việc khá đơ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 cho thêm một người dùng vào trong hệ thống, hay đổi phòng 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ể với ý nghĩa 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, 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
trong ‘tài khoản tín dụng’ (credit account transaction). Việc chỉ định quyền hạn cho
phép thi hành một thao tác là một việc làm đầy ý nghĩa, vì các thao tác đã được phân
định tinh tế và mỗi cá nhân thao tác có một ý nghĩa riêng trong chương trình ứng dụng.
Việc sử dụng RBAC để quản lý các đặc quyền của người dùng trong một hệ thống
duy nhất hay trong một chương trình ứng dụng là một sự thực hành tốt nhất được chấp
nhận một cách rộng rãi. Các hệ thống bao gồm: thư mục động (Active Directory) của
6
Microsoft, SELinux, Oracler DBMS, PostgreSQL 8.1, SAP R/3…đều thực thi một một
trong những hình thức của RBAC.
Hình 1. Điểm khác biệt giữa RBAC và các mô hình truyền thống
Tuy nhiên, việc sử dụng RBAC để quản lý quyền lợi của người dùng, trên toàn thể
các chương trình ứng dụng, là một việc làm còn nhiều tranh luận. Sở dĩ như vậy là vì
người dùng thường là một đơn vị đặc hữu (unique), cho nên nhiệm vụ định nghĩa các
vai trò tương ứng (defining sufficient roles) và chỉ định các tư cách hội viên cho các vai
trò một cách phù hợp, trong một tổ chức với hạ tầng cơ sở kỹ thuật thông tin không
đồng nhất, hòng nắm bắt các nhu cầu về quyền lợi, trong khi các nhu cầu này có tầm trải
rộng trên hàng chục, hằng trăm hệ thống và trên các chương trình ứng dụng, là một việc
hết sức phức tạp.
7
CHƯƠNG 3. ROLE-BASED ACCESS CONTROL
3.1. Nền tảng và sự phát triển
Mục đích chính của RBAC là làm thuận tiện cho quá trình quản trị bảo mật và
kiểm duyệt. Rất nhiều các hệ thống điều khiển truy cập tốt trong thương mại dành cho
các máy tính lớn hiện nay đã cài đặt các vai trò để quản trị bảo mật.
Trong quá khứ và cho đến ngày nay, nhiều ứng dụng đã được xây dựng với RBAC
được mã hóa bên trong bản thân ứng dụng đó. Các hệ điều hành và các môi trường hiện
tại cũng đã cung cấp một vài sự hỗ trợ RBAC ở mức độ ứng dụng. Tuy nhiên một
nhiệm vụ khó khăn đặt ra là làm thế nào để nhận biết các điều kiện ứng dụng thực sự
độc lập, thực sự linh hoạt, thực sự đơn giản để cài đặt và sử dụng, để hỗ trợ rộng rãi cho
các ứng dụng với một sự tùy chỉnh nhỏ nhất.
Những sự biến đổi phức tạp của RBAC bao gồm khả năng thiết lập mối quan hệ
giữa các vai trò, giữa các quyền với các vai trò và giữa những người sử dụng và các vai
trò. Lấy ví dụ, hai quyền có thể được thiết lập để triệt tiêu lẫn nhau, do đó cùng là một
người sử dụng thì không thể cùng ở trong hai vai trò này được.
Các vai trò cũng có thể đảm nhiệm các quan hệ kế thừa, nhờ vào đó mà một vai trò
có thể kế thừa toàn bộ các quyền của một vai trò khác. Các mối quan hệ vai trò – vai trò
này có thể được sử dụng để đảm bảo các chính sách bảo mật, các chính sách này bao
gồm sự phân biệt giữa các trách nhiệm và sự ủy thác của thẩm quyền. Cho đến nay, các
quan hệ này đã được mã hóa bên trong các phần mềm ứng dụng; cùng với RBAC,
chúng có thể được chỉ định cho một trong các miền bảo mật.
Với RBAC, có thể định nghĩa lại các quan hệ quyền-vai trò, tạo nên sự đơn giản
trong việc gán người sử dụng vào trong các vai trò được định nghĩa lại đó. Chính sách
điều khiển truy cập là hiện thân trong các thành phần khác nhau của RBAC giống như
các mối quan hệ vai trò – quyền, người sủ dụng – vai trò, vai trò- vai trò. Các thành
phần này sẽ quyết định xem một người sử dụng có được phép truy cập đến một khối dữ
liệu riêng trong hệ thống hay không. Các thành phần RBAC có thể được cấu hình trực
tiếp bởi các owner của hệ thống hoặc gián tiếp thông qua các vai trò xấp xỉ được ủy thác
8
bởi các owner của hệ thống. Hơn thế nữa, chính sách điều khiển truy cập có thể làm
tăng thêm vòng đời của hệ thống. Khả năng thay đổi chính sách khi cần thiết của một tổ
chức là một lợi thế của RBAC.
Mặc dầu vậy RBAC là một chính sách tự nhiên, nó hỗ trợ chính xác ba nguyên lý
bảo mật nổi tiếng: least privilege(đặc quyền tối thiểu), separation of duties (phân chia
trách nhiệm), và data abstraction(trừu tượng hóa dữ liệu). Least privilege – đặc quyền
tối thiểu được hỗ trợ vì RBAC có thể được cấu hình sao cho chỉ có các quyền cho các
nhiệm vụ được chỉ đạo bởi các thành viên của vai trò mới được gán vào vai trò đó.
separation of duties – sự phân chia trách nhiệm được hỗ trợ để chắc chắn rằng các vai
trò loại bỏ lần nhau có thể được gọi để hoàn thành các nhiệm vụ nhạy cảm, giống như
sự cần thiết một tài khoản thư ký và một tài khoản quản lý để tham gia vào việc kiểm
tra. data abstraction – trừu tượng hóa dữ liệu được hỗ trợ bởi tính chất của các quyền
trừu tượng giống như credit(cho vay) và debit(ghi nợ) của một đối tượng account (tài
khoản), đúng hơn là đọc, ghi, và thực thi các quyền đặc trưng được cung cấp bởi hệ điều
hành. Tuy nhiên, RBAC không thể ép buộc ứng dụng của các nguyên lý đó phải tuân
theo. Một nhân viên bảo mật không thể cấu hình RBAC để nó vi phạm các nguyên lý
đó. Ngoài ra mức độ của sự trừu tượng hóa dữ liệu có thể được xác định bởi sự cài đặt
chi tiết.
RBAC không phải là giải pháp cho toàn bộ các điều khiển truy cập được đưa ra.
RBAC không cố gắng điều khiển trực tiếp các quyền như một chuỗi các sự kiện. Các
dạng khác của điều khiển truy cập có thể được đặt ở tầng trên của RBAC cũng chính vì
mục đích này.
3.2. Vai trò và các định nghĩa liên quan
Với RBAC các nhà phát triển tạo ra các vai trò theo các chức năng công việc được
thực hiện trong công ty hay tổ chức, cấp các quyền cho các vai trò này và sau cùng là
gán những người sử dụng vào các vai trò này dựa trên cơ sở trách nhiệm và năng lực
của công việc đặc thù đó.
Một vai trò có thể trình bày một nhiệm vụ cụ thể như là một vai trò bác sĩ hay vai
trò một nhà điều hành kinh doanh. Một vai trò bao gồm quyền và trách nhiệm trong đó
9
quyền và trách nhiệm được phân biệt rất rõ ràng. Một người có thể có quyền quản lý
nhiều phòng ban nhưng anh ta chỉ có trách nhiệm đối với phòng ban cụ thể được quản
lý. Các vai trò cũng có thể phản ánh trách nhiệm cụ thể được gán vòng quanh qua nhiều
người sử dụng, ví dụ như trách nhiệm của một bác sĩ hay một nhân viên làm ca.
Các vai trò định nghĩa cả sự cho phép riêng biệt cụ thể để truy cập các tài nguyên
và quy mô của các tài nguyên được truy cập. Lấy ví dụ một vai trò người điều hành có
thể truy cập tất cả các tài nguyên máy tính nhưng không thể thay đổi các quyền truy cập
của mình, hay một kiểm toán viên chỉ có thể truy cập vào máy tính để kiểm tra sổ sách.
Các vai trò được sử dụng để quản trị hệ thống trong nhiều hệ điều hành mạng như
NetWare của Novell hay WindowNT của Microsoft.
Sự kết hợp của người sử dụng và các quyền tạo nên một vai trò. Các quyền được
gán một cách gián tiếp cho người sử dung thông qua một vai trò, chính vì thế mà việc
bảo mật các lỗ hổng trên các vai trò đơn giản hơn rất nhiều so với trên các quyền. Người
sử dụng có thể được gán lại sang các vai trò khác nếu cần thiết.
Một câu hỏi thường xuyên được đặt ra là “Đâu là điểm khác nhau giữa các vai trò
(role) và các nhóm (group)”. Nhóm người sử dụng là một đơn vị của điều khiển truy cập
khá phổ biến được cung cấp bởi các hệ thống điều khiển truy cập. Một chuyên đề khác
giữa hầu hết những sự cài đặt của các nhóm và định nghĩa của các vai trò đó là: nhóm là
một chuẩn giao tiếp giống như một tập hợp người sử dụng và không phải là tập hợp của
các quyền. Một vai trò là cả một tập hợp của người sử dụng ở một bên và một tập hợp
các quyền ở một bên khác. Vai trò hoạt động như một người trung gian để nhóm hai tập
hợp đó lại với nhau.
10
3.3. Họ mô hình RBAC
Về cơ bản, RBAC được chia thành bốn mức khác nhau, từ mức cơ sở đến mức
nâng cao như hình vẽ dưới đây:
Hình 2: Họ RBAC
3.3.1. Core RBAC (RBAC 0)
Trong hình trên (hình 2), RBAC 0 base model [6] là mô hình cơ bản nhất cho các
hệ thống RBAC và chứa năm phần tử dữ liệu cơ bản đó là:
• Users (U): tập hợp người sử dụng
• Roles (R): tập hợp các vai trò
• Permissions (PRMS) : các quyền
• Objects (OBS) : các đối tượng
• Operations (OPS): các hành động
Trong mô hình RBAC, người sử dụng có thể là con người, các cỗ máy, các
mạng…chứ không nhất thiết phải mang yếu tố con người. Một vai trò trình bày một
chức năng công việc (job-function). Các quyền là một sự phê chuẩn để thực thi các hành
động (operations) trên một hay nhiều đối tượng, các quyền phải luôn luôn rõ ràng, có
thể áp dụng cho nhiều đối tượng và phải được miêu tả một cách trừu tượng, thêm vào
đó các quyền chỉ có thể có tác dụng đối với các đối tượng dữ liệu và tài nguyên của hệ
thống mà không thể có tác dụng đối với các thành phần RBAC. Đối với các thành phần
RBAC chỉ có các quyền quản trị mới có thể thao tác được. Mô hình tổng quát của
RBAC 0 được mô tả như trong hình 3 dưới đây:
11
Hình 3. Mô hình tổng quát Core RBAC
Ngoài ra trong mô hình trên ta còn thấy một thành phần nữa đó là Session (S).
Session đánh dấu phiên làm việc của người sử dụng, mỗi một session sẽ ánh xạ đến duy
nhất một người sử dụng và một tập hợp con các vai trò được kích hoạt mà người sử
dụng được gán tới. Điều đó có nghĩa rằng tại một thời điểm, một user có thể có nhiều
phiên làm việc và nhiều vai trò có thể được kích hoạt tại cùng một thời điểm đó. Session
chính là nhân tố quyết định xem liệu hệ thống có cho phép người sử dụng thực hiện
multi login hay không, hay cũng có thể dùng session để kiểm tra xem hiện tại có bao
nhiêu người đang truy cập hệ thống…
Một cách tổng quát nhất, RBAC có thể được định nghĩa như sau:
• U, R, PRMS và S trình bày theo thứ tự tập hợp Users – những người sử dụng,
Roles – các vai trò, Permisstions – các quyền, và Sessions – các phiên.
• RH R X R là một phần t rên các vai trò, được gọi là mối quan hệ ưu thế,
được viết tắt là , và định nghĩa một thứ tự các vai trò, đó là r1 r2, với (r1,
r2) R.
• UA U X R là mối quan hệ gán những người sử dụng với các vai trò.
• assign_roles(u:U) , là ánh xạ của một người sử dụng lên trên một tập các
vai trò mà cô ta/anh ta được gán. Chính xác hơn: assign_roles(u) = {r R |
(u, r) UA}.
12
• assign_users(r:R) , là ánh xạ của một vai trò lên trên một tập người sử
dụng được gán vai trò này. Chính xác hơn:
assign_users(r) = {u U | (u, r) UA}.
• PA R X PRMS, là mối quan hệ gán một quyền cho một vai trò.
• assign_perms(r:R) , là ánh xạ của một vai trò lên trên một tập hợp các
quyền. Chính xác hơn:
assign_perms(r) = {p PRMS | (r, p) PA}.
• user_ses(u:U) , là ánh xạ của một người sử dụng lên trên một tập các
phiên.
• Ses_roles(s:S) , là ánh xạ của mỗi một phiên tới một tập vai trò.
• avail_session_perms(s:S) , các quyền sẵn có trong một phiên, đó là
assign_perms(r).
3.3.2. Role hierarchy
RBAC 1 tích hợp thêm Role Hierarchy – RH [3] hay còn gọi là hệ thống cấp bậc
trong vai trò. Mô hình tổng quát của RBAC 1 như sau:
Hình 4. Mô hình tổng quát Role hierarchy ( RBAC 1)
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, ví dụ như vai trò r1 kế thừa vai trò r2 nếu như tất cả các đặc
quyền của r2 cũng là các đặc quyền của r1 ngoài ra r1 có thể có thêm một số quyền
13
khác. 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 sử dụng chứa đựng các quan hệ, vai trò r1 chứa
đựng vai trò r2 nếu như tất cả người sử dụng được xác thực cho r1 cũng là những người
sử dụng được xác thực cho r2. Chú ý rằng, một người sử dụng của r1 có tất cả các đặc
quyền của r2, trong khi sự kế thừa quyền cho r1 và r2 không nói đến bất cứ điều gì về
UA (User Assignment).
Có hai kiểu RH đó là:
General Role Hierarchies (RH tổng quát)
Limited Role Hierarchies (RH giới hạn).
3.3.2.1. General Role Hierarchies
General Role Hierarchies hỗ trợ định nghĩa đa kế thừa (multiple inheritance). Điều
này có nghĩa rằng nó cung cấp khả năng kế thừa quyền cũng như việc kế thừa user
membership từ hai hay nhiều vai trò nguồn.
• RH ROLES × ROLES được gọi là quan hệ kế thừa, viết tắt là ,
r1 r2 chỉ khi tất cả các quyền của r2 cũng là các quyền của r1 và tất cả người
sử dụng của r1 cũng là những người sử dụng của r2. r1 r2
authorized_permissions(r2)⊆ authorized_permissions(r1)
• authorized_users(r: ROLES) → 2^USERS, ánh xạ vai trò r lên trên một tập hợp
người sử dụng trong sự hiện diện của một RH, authorized_users(r) = {u
USERS | r’ r , (u, r’) UA}
• authorized_permissions(r: ROLES) → 2^PRMS, ánh xạ vai trò r lên trên một tập
hợp các quyền trong sự hiện diện của một RH.
authorized_permissions(r) = {p PRMS | r’ r, (p, r’) PA}
14
3.3.2.2. Limited Role Hierarchies
Limited Role Hierarchies không hỗ trợ định nghĩa đa kế thừa
Định nghĩa giống như RH tổng quát nhưng có thêm giới hạn sau đây:
r, r1, r2 ROLES, r r1 ∧ r r2 ⇒ r1 = r2
3.3.3. Constrained RBAC
Constrained RBAC [3] thêm các quan hệ Separation of Duty (SoD - sự phân chia
trách nhiệm) vào mô hình RBAC. SoD được sử dụng để thực thi các chính sách xung
đột lợi ích mà các tổ chức có thể sử dụng để ngăn chặn người sử dụng vượt quá một
mức độ hợp lý cho các quyền của họ.
Giống như một yếu tố bảo mật cơ bản, SoD đã được công nhận một cách rộng rãi
cho các ứng dụng trong kinh doanh, các ngành công nghiệp và chính phủ. Mục đích của
nó là để đảm bảo rằng các sai sót và gian lận bên trong một tổ chức chỉ là kết quả của
việc thông đồng giữa các cá nhân. Để giảm thiểu khả năng thông đồng, các cá nhân
thuộc các nhóm kỹ năng khác nhau hoặc lợi ích khác nhau được phân công nhiệm vụ
cần thiết và riêng biệt trong việc thực hiện các chức năng của một doanh nghiệp. Động
lực ở đây chính là để đảm bảo rằng các sai sót và gian lận không xảy ra và cũng không
có việc thông đồng của nhiều người sử dụng. Chuẩn RBAC này cho phép cả SoD tĩnh
và SoD động.
3.3.3.1 . Các quan hệ Static SoD (SSD)
Chúng ta biết rằng trong một hệ thống RBAC, một người sử dụng có thể ở trong
một hoặc nhiều vai trò khác nhau. Như vậy, một câu hỏi đặt ra là liệu có sự sung đột về
lợi ích của người sử dụng hay không khi trong trường hợp họ ở trong hai vai trò khác
nhau mà hai vai trò này lại mâu thuẫn với nhau? Câu trả lời là điều này hoàn toàn có thể
xảy ra, chúng ta hãy lấy ví dụ:
Trong một nhà băng, một nhân viên thu ngân (teller) có thể thực hiện hành động
lưu các khoản tiền mà khách hàng gửi vào tài khoản của mình trong ngân hàng. Để thực
hiện hành động này, nhân viên thu ngân phải truy cập để đọc và viết vào các trường đặc
biệt bên trong một file. Trong lúc này, nhân viên giám sát tài khoản (accounting
15