Tài liệu Khóa luận Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ: ĐẠ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
i
ĐẠ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
HÀ NỘI - 2009
ii
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 ...
67 trang |
Chia sẻ: haohao | Lượt xem: 1020 | Lượt tải: 0
Bạn đang xem trước 20 trang mẫu tài liệu Khóa luận Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ, để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên
ĐẠ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
i
ĐẠ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
HÀ NỘI - 2009
ii
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
iii
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.
iv
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.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
v
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
5.6. Kiểm thử .........................................................................................................52
5.6.1. Đề xuất các trường hợp kiểm thử ..............................................................52
5.6.2. Tiến hành kiểm thử và kết quả ..................................................................53
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
vi
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 16. Biểu đồ hợp tác: User 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
Hình 30. kết quả thực hiện cấp quyền cho vai trò trong test 2 ....................................55
vii
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ể
1
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
2
được đá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.
3
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.
4
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.
5
Đặ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à
6
MAC 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
7
đượ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 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.
8
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
9
ủy thác 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 đó
10
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.
11
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:
12
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}.
13
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ố
14
quyền 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}
15
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
16
(accounting supervisor) có thể thực hiện hành động chỉnh sửa thông tin của các tài
khoản bằng cách truy cập để đọc và viết lên các trường trong file mà nhân viên thu
ngân đã mở ra và thêm dữ liệu ở trên. Tuy nhiên theo quy định của ngân hàng thì nhân
viên giám sát tài khoản không được phép khởi tạo hay dỡ bỏ đối với một tài khoản mà
chỉ được phép chỉnh sửa thông tin của tài khoản và nhân viên thu ngân không được
phép thực hiện chỉnh sửa những giao tác mà anh ta đã hoàn thành.
Như vậy thông qua ví dụ trên chúng ta thấy rõ rằng, vai trò nhân viên thu ngân
(teller) và vai trò nhân viên giám sát (accounting supervisor) là hai vai trò hoàn toàn
trái ngược nhau hay nói cách khác là xung đột nhau, và sẽ không bao giờ có chuyện
một nhân viên trong ngân hàng vừa đóng vai trò nhân viên thu ngân vừa đóng vai trò
nhân viên giám sát tài khoản.
Quan hệ SSD được đưa ra để giải quyết các vấn đề xung đột lợi ích như đã nói ở
trên. Mô hình tổng quát các quan hệ SSD được minh họa trong hình 5 dưới đây:
Hình 5: Mô hình tổng quát các quan hệ SSD
là một tập hợp của cặp (rs, n) trong Static SoD, nơi mà
mỗi rs là một tập hợp vai trò, t là một tập hợp con của rs, và n là một số tự
nhiên >= 2, với đặc tính rằng không có người sử dụng được gán tới n hoặc
nhiều vai trò từ tập hợp rs trong mỗi cặp (rs, n)
17
Dạng tổng quát:
Như vậy, các chính sách SSD ngăn ngừa các xung đột bằng cách đặt các ràng
buộc lên các hành động quản lý mà qua đó giới hạn việc kết hợp các đặc quyền của
người sử dụng.
3.3.3.2. Các quan hệ Dynamic SoD (DSD)
Các quan hệ Dynamic SoD cũng giống như các quan hệ Static SoD ở 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 sử dụng. Tuy
nhiên, các quan hệ DSD khác với các quan hệ SSD ở ngữ cảnh mà trong đó những sự
giới hạn đó được áp đặt. Các mối quan hệ SSD định nghĩa và đặt các ràng buộc trên
khu vực tổng số quyền của người sử dụng, còn DSD lại đặt các ràng buộc lên trên các
vai trò có thể được kích hoạt trong một phiên làm việc của người sử dụng. DSD cho
phép một user được xác thực cho hai hoặc nhiều vai trò mà không tạo ra một sự xung
đột lợi ích giữa các vai trò khi chúng hoạt động độc lập. Điều này có nghĩa rằng nếu
một vai trò thuộc một quan hệ SSD được kích hoạt trong phiên làm việc của người sử
dụng thì các vai trò có liên quan khác không thể được kích hoạt trong cùng một phiên
làm việc đó. Mô hình tổng quát của các quan hệ DSD được minh họa như trong hình d
dưới đây:
Hình 6: Mô hình tổng quát các quan hệ DSD
là tập hợp của cặp (rs, n) trong DSD, trong đó mỗi rs là một
tập hợp các vai trò và n là một số tự nhiên >= 2, với đặc tính là không có chủ
18
thể nào có thể kích hoạt n hay nhiều vai trò từ tập hợp rs trong mỗi dsd thuộc
DSD.
Dạng tổng quát
và
3.3.4. RBAC 3
Là sự kết hợp của RBAC 1 (Role Hirerachy) và RBAC 2 (Constrained RBAC).
Mô hình tổng quát như sau:
Hình 7: Mô hình tổng quát RBAC cấp cao nhất - RBAC 3
19
Một cách chi tiết hơn:
Hình 8: Mô hình RBAC cấp cao nhất – triển khai chi tiết
Mô hình RBAC 3 [5] được triển khai bằng ngôn ngữ mô hình hóa UML.
Chú ý: trong hình 4.4.2, chúng ta thấy các vai trò được phân làm hai loại Roles –
vai trò thông thường và Administrative Role – vai trò quản trị đó là bởi vì trong mô
hình RBAC các vai trò thông thường chỉ có quyền thao tác trên dữ liệu và tài nguyên
thông thường của hệ thống còn đối với các thành phần thuộc RBAC(U, R,
S,PRMS,…) thì các vai trò thông thường này không có quyền thao tác. Chính vì thế
các vai trò quản trị được định nghĩa cho ra để cho phép quản lý các thành phần RBAC.
3.4. Hệ thống RBAC và đặc tả các chức năng quản trị
3.4.1. Core RBAC
3.4.1.1. Administrative commands cho core RBAC
AddUser
Tạo ra một người sử dụng mới. Câu lệnh này chỉ có hiệu lực khi mà người sử
dụng này chưa là thành viên của tập hợp USERS dataset(chưa có tài khoản trong hệ
thống). Sau khi thêm mới người sử dụng USERS dataset sẽ được cập nhật.
20
DeleteUser
Xóa bỏ một người sử dụng đang tồn tại trong cơ sở dữ liệu RBAC. Câu lệnh chỉ
có hiệu lực khi người sử dụng đang là thành viên của USERS dataset. Sau khi xóa
thành công USERS, UA dataset và phương thức assigned_users sẽ được cập nhật.
AddRole
Tạo ra một vai trò mới. Lệnh này chỉ thực sự có hiệu lực nếu và chỉ nếu vai trò
này chưa là một thành viên của ROLES dataset.
Hình thức hóa chức năng này như sau:
DeleteRole
Xóa bỏ một vai trò đang tồn tại trong cơ sở dữ liệu RBAC. Câu lệnh này chỉ có
tác dụng nếu và chỉ nếu vai trò cần xóa này đang là một thành viên của ROLES
dataset.
Hình thức hóa chức năng này như sau:
21
AssignUser
Gán một người sủ dụng vào một vai trò. Câu lệnh chỉ có tác dụng nếu và chỉ nếu
người sử dụng đang là một thành viên của USERS dataset và vai trò mà người sử dụng
được gán vào phải đang là thành viên của ROLES dataset.
Hình thức hóa chức năng này như sau:
DeassignUser
Loại bỏ một người sử dụng khỏi một vai trò. Câu lệnh này chỉ có tác dụng nếu và
chỉ nếu người sử dụng đang là một thành viên của USERS dataset, vai trò mà người sử
dụng sẽ bị loại ra đang là thành viên của ROLES dataset và người sử dụng đã được
gán vào vai trò này từ trước đó.
Hình thức hóa chức năng này như sau:
22
GrantPermission
Cấp cho vai trò một số quyền để có thể thao tác trên các đối tượng. Lệnh này chỉ
có tác dụng nếu như vai trò này đang là thành viên của ROLES dataset.
Hình thức hóa chức năng này như sau:
RevokePermission
Gỡ bỏ các quyền đã cấp cho một vai trò. Lệnh này chỉ có tác dụng nếu như vai
trò này đang là thành viên của ROLES dataset.
Hình thức hóa chức năng này như sau:
3.4.1.2. Các chức năng hỗ trợ hệ thống cho core RBAC
CreateSession(user, session)
Tạo ra một session – hay phiên làm việc mới. hàm này sẽ được gọi khi người
dùng lần đầu tiên đăng nhập vào hệ thống đồng thời sẽ kích hoạt tất cả vai trò mà đang
quản lý người sử dụng này. Qúa trình tạo ra một session này chỉ có tác dụng nếu và chỉ
nếu:
Người sử dụng là thành viên của USERS dataset
Tập hợp các vai trò được kích hoạt là một tập con của tập tất cả các vai trò
được gán tới người sử dụng
Hình thức hóa chức năng này như sau:
23
DeleteSession(user, session)
Xóa bỏ một session gắn với một người sử dụng. Hàm này chỉ có tác dụng nếu và
chỉ nếu session identifier là một thành viên của SESSION dataset, người sử dụng là
một thành viên của USERS dataset và session này được nắm giữa bởi người sử dụng
hiện tại.
Hình thức hóa chức năng này như sau:
AddActiveRole
Hàm này sẽ thêm mới một vai trò giống như một vai trò được kích hoạt trong
một session.mà một người sử dụng đang ánh xạ đến. hàm này chỉ có tác dụng nếu và
chỉ nếu:
Người sử dụng là thành viên của USERS dataset
Vai trò là thành viên của ROLES dataset
Session identifier là thành viên của SESSION dataset
Vai trò này đã được gán cho người sử dụng hiện tại từ trước
Session đang được nắm giữ bởi người sử dụng
Hình thức hóa chức năng này như sau:
24
DropActiveRole
Xóa một vai trò ra khỏi tập hợp các vai trò đang được kích hoạt trong một
session đang ánh xạ đến một người sử dụng. hàm này trái ngược lại với hàm
AddActiveRole.
Hình thức hóa chức năng này như sau:
CheckAccess
Hàm này trả về một giá trị Boolean để kiểm tra xem chủ thể của một session có
được phép thực hiện một hành động nào đó (operaion) lên một đối tượng nào đó hay
không. Hàm này chỉ có tác dụng nếu và chỉ nếu:
Session indentifier là thành viênc của SESSION dataset.
Đối tượng là một thành viên của OBJ dataset
Operation là một thành viên của OPS dataset
Quyền này đã được cấp cho một trong các vai trò đã được kích hoạt của
session này
Hình thức hóa chức năng này như sau:
25
3.4.1.3. Các chức năng review cho Core RBAC
AssignedUsers
Hàm này trả về một tập hợp người sử dụng đã được gán tới một vai trò nào đó.
Hàm này chỉ có tác dụng nếu và chỉ nếu vai trò là một thành viên của ROLES dataset.
Hình thức hóa chức năng này như sau:
AssignedRoles
Hàm này trả về một tập hợp các vai trò đã được gán tới một người sử dụng nào
đó. Hàm này chỉ có tác dụng nếu và chỉ nếu người sử dụng là thành viên của USERS
dataset.
Hình thức hóa chức năng này như sau:
3.4.1.4. Các chức năng review cao cấp cho Core RBAC
RolePermissions
Hàm này trả về một tập hợp các quyền (op, obj) được cấp cho một vai trò. Hàm
này chỉ có tác dụng nếu và chỉ nếu vai trò là thành viên của ROLES dataset.
Hình thức hóa chức năng này như sau:
26
UserPermissions
Hàm này trả về các quyền mà một người sử dụng được cấp thông qua vai trò của
anh ta/cô ta được gán. Hàm này chỉ có tác dụng nếu và chỉ nếu người sử dụng là một
thành viênc của USERS dataset.
Hình thức hóa chức năng này như sau:
SessionRoles
Hàm này trả về các quyền một session nào đó. Các quyền này được cấp cho các
vai trò đang được kích hoạt bởi session. Hàm này chỉ có tác dụng nếu và chỉ nếu
session indentifier là một thành viên của SESSION dataset.
Hình thức hóa chức năng này như sau:
RoleOperationsOnObject
Hàm này trả về một tập hợp các hành động mà một vai trò được phép thực hiện
trên một tập hợp đối tượng nào đó. Hàm này chỉ có tác dụng nếu và chỉ nếu vai trò là
một thành viên của ROLES dataset, đối tượng là một thành viên của OBJ dataset.
Hình thức hóa chức năng này như sau:
27
UserOperationsOnObject
Hàm này trả về một tập hợp các quyền mà một người sử dụng có thể được phép
thực thi trên một tập hợp đối tượng nào đó. Hàm này chỉ có tác dụng nếu và chỉ nếu
người sử dụng là thành viên của USERS dataset, đối tượng là thành viên của OBJ
dataset.
Hình thức hóa chức năng này như sau:
3.4.2. Role hierarchy
3.4.2.1. Administrative commands cho role hierarchy tổng quát
AddInheritance
câu lệnh này khởi tạo một quan hệ kế thừa trực tiếp giữa các vai trò r_asc và
r_desc. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu r_asc và r_desc là thành viên của
ROLE data set, r_desc chưa kếu thừa r_asc . schema dưới đây sử dụng các ký hiệu:
Hình thức hóa chức năng này như sau:
28
DeleteInheritance
Câu lệnh này xóa bỏ một mối quan hệ kế thừa giữa r_asc và r_desc. Lệnh này
chỉ có tác dụng nếu và chỉ nếu r_asc và r_desc là thành viên của ROLE dataset và
r_desc đang kế thừa r_asc.
Hình thức hóa chức năng này như sau:
AddAscendant
Câu lệnh này tạo ra một vai trò mới có tên r_asc, và thêm nó vào trong role
hieararchy giống như nó là đối tượng cơ sở của r_desc. Câu lệnh này chỉ có tác dụng
nếu và chỉ nếu r_asc chưa là một thành viên của ROLE dataset, r_desc là thành viên
của ROLE data set.
Hình thức hóa chức năng này như sau:
AddDescendant
Câu lệnh này thực hiện việc tạo ra một vai trò mới có tên r_desc và thêm nó vào
role hierarchy giống như nó không phải là đối tượng kế thừa của r_asc. Câu lệnh này
chỉ có tác dụng nếu và chỉ nếu r_desc chưa phải là thành viên của ROLE data set.
Hình thức hóa chức năng này như sau:
29
3.4.2.2. Các chức năng hệ thống cho role hierarchy
CreateSession(user, session)
Câu lệnh này khởi tạo ra một phiên làm việc mới cho một người sử dụng đồng
thời điều chỉnh các vai trò được kích hoạt. câu lệnh này chỉ có tác dụng nếu và chỉ nếu:
Người sử dụng là một thành viên của USER data set
Vai trò được kích hoạt là thành viên của tập các vai trò được phép xác
thực cho người sử dụng này. Chú ý rằng khi một vai trò được kích hoạt
cho một phiên làm việc thì các vai trò kế thừa nó cũng như các vai trò nó
kế thừa sẽ không được phép kích hoạt cho session này.
Hình thức hóa chức năng này như sau:
AddActiveRole
Câu lệnh kích hoạt một vai trò mới cho một phiên làm việc của một người sử
dụng. câu lệnh này chỉ có tác dụng nếu và chỉ nếu:
Người sử dụng là thành viên của USER data set
Vai trò được kích hoạt mới là thành viên của ROLE data set
Phiên làm việc hiện tại là thành viên của SESSION data set
Người sử dụng được xác thực cho vai trò đó, và
Session được nắm giữ bởi người sử dụng này
Hình thức hóa chức năng này như sau:
30
3.4.2.3. Các chức năng review cho role hierarchy tổng quát
AuthorizedUsers
Câu lệnh này trả lại một tập hợp những người sử dụng được xác thực cho một
vai trò hiện tại. Những người sử dụng này được gán tới một vai trò mà vai trò này lại
kế thừa vai trò hiện tại. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu vai trò hiện tại là
thành viên của ROLE data set.
Hình thức hóa chức năng này như sau:
AuthorizedRoles
Câu lệnh này trả lại một tập hợp các vai trò được xác thực cho một người sử
dụng. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu người sử dụng là thành viên của
USER data set.
Hình thức hóa chức năng này như sau:
31
3.4.2.4 – Các chức năng review cao cấp cho role hierarchy
RolePermissions
Câu lệnh này trả về một tập hợp tất cả các quyền (op, obj) được gán hoặc được
kế thừa bởi một vai trò hiện tại. Câu lệnh này chỉ có tác dụng nếu và chỉ nếu vai trò
hiện tại là thành viên của ROLE data set.
Hình thức hóa chức năng này như sau:
UserPermissions
Câu lệnh này trả lại một tập hợp các quyền của một người sử dụng, được lấy thông
qua các vai trò được xác thực của anh ta. Câu lệnh này chỉ tồn tại nếu và chỉ nếu người
sử dụng là thành viên của USER data set.
Hình thức hóa chức năng này như sau:
RoleOperationsOnObject
Câu lệnh này trả lại một tập hơp các hành động mà một vai trò được phép thực
hiện trên một đối tượng hiện tại. Tập hợp này chứa đựng toàn bộ các hành động được
gán trực tiếp cho vai trò hay vai trò hiện tại kế thừa từ các vai trò khác. Câu lệnh này
chỉ có tác dụng nếu và chỉ nếu vai trò là một thành viên của ROLE data set, đối tượng
hiện tại là một thành viên của OBJS data set.
Hình thức hóa chức năng này như sau:
32
UserOperationsOnObject
Câu lệnh này trả lại một tập hợp các hành động mà một người sử dụng được
phép thực hiện trong trên một đối tượng hiện tại. Tập hợp này chứa đựng tất cả các
hành động của người sử dụng thông qua các vai trò được xác thực của anh ta. Câu lệnh
này chỉ có tác dụng nếu và chỉ nếu người sử dụng là thành viên của USER data set.
Đối tượng hiện tại là thành viên của OBJS data set.
Hình thức hóa chức năng này như sau:
33
CHƯƠNG 4. PHÂN TÍCH VÀ THIẾT KẾ CÔNG CỤ HỖ TRỢ
Trong chương này chúng tôi sẽ tập trung vào việc thiết kế một ứng dụng minh
họa việc triển khai mô hình RBAC vào cài đặt thực tế để quản lý và điều khiển truy
cập. Ứng dụng này sẽ tập trung vào việc mô tả và cài đặt những chức năng cơ bản nhất
mà một hệ thống RBAC phải có. Các chức năng này bao gồm : chức năng quản lý các
vai trò, quản lý người sử dụng, quản lý các đối tượng và quyền thực thi trên các đối
tượng này, quản lý các đặc quyền của các vai trò.
Việc cài đặt mô hình RBAC sao cho đảm bảo được mọi yêu cầu như: xử lý các
ràng buộc, các xung đột quyền lợi, kiểm tra hiệu năng… mà lý thuyết đã chỉ ra là một
việc không hề đơn giản, đòi hỏi nhiều thời gian và công sức cũng như kinh nghiệm.
Trong khuân khổ của khóa luận này, chúng tôi sẽ tạm thời không xử lý đến những vấn
đề đó. Mục đích chính của việc cài đặt này là làm sáng tỏ hơn các khái niệm vai trò
(role), các quyền (permission), hay các phiên làm việc (session).
Mặt khác chúng ta biết rằng mô hình RBAC được đưa ra để áp dụng cho những
ứng dụng đa người dùng (multi user), chính vì lý do đó chúng tôi quyết định triển khai
ứng dụng trên nền web – một kiểu ứng dụng đa người dùng phổ biến nhất hiện nay.
Việc triển khai RBAC trên nền web cũng là một việc hết sức thiết thực bởi thế giới
công nghệ đang chuyển mình nhanh chóng sang nền web, các ứng dụng chỉ chạy trên
desktop đã dần trở nên lỗi thời và bộc lộ nhiều bất cập.
Một điểm nữa là theo truyền thống, các ứng dụng web thường chia làm hai phần
riêng biệt: phần dành cho người quản trị (back-end) và phần dành cho người sử dụng
bình thường. Tuy nhiên như đã thảo luận ở trên, ứng dụng của chúng ta áp dụng mô
hình RBAC vào để quản lý và điều khiển truy cập. Với lý do đó chúng tôi chỉ xây
dựng phần dành cho người quản trị, bởi đây là khu vực mà người quản trị bảo mật sẽ
làm việc, điều khiển, cấp quyền truy cập cho các vai trò tới các tài nguyên của hệ
thống, quản lý và theo dõi từng người dùng.
34
4.1.Mô hình use case
4.1.1. Danh sách các tác nhân
STT Tên tác nhân Ý nghĩa
1 Regular User Vai trò người sử dụng bình thường.
2 Role Domain Engineer Quản lý các vai trò, tổ chức các quyền. cấu
trúc role hierarchy và chỉ định các ràng buộc.
3 Security administrator Quản trị bảo mật, vai trò này chịu trách
nhiệm quản lý người dùng, gán quyền cũng
như vai trò cho người dung.
4 Super administrator Siêu quản trị, vai trò này có toàn quyền đối
với hệ thống. Kế thừa tất cả các quyền của
các vai trò ở trên.
Hình 9: dưới đây là Component view của mô hình use case cho RBAC:
Hình 9. Component view của mô hình use case cho RBAC
35
4.1.2. Sơ đồ use case:
Add user
Update user
Delete user
User assignment
Permistion assignment
Security
administrator
Add role
Update role
Delete role
Permission oganizing
Role hierarchy structuring
Constraints specifying
Role Domain
Engineer
Session Establishing
Permission approval
Session Closing
Regular user
Hình 10. sơ đồ use case theo từng gói chi tiết
36
4.1.3. Giải thích một số use case quan trọng
4.1.3.1. Add role
Tên use case Add role
Tác nhân Role Domain Engineer
Miêu tả Miêu tả quá trình tạo ra một vai trò
Các hành động 1. Use case được khởi tạo khi Role Domain Engineer mở
ứng dụng để thêm vai trò mới.
2. Role Domain Engineer nhập các thông tin của vai trò
mới và submit.
3. Hệ thống thực hiện lệnh thêm mới một vai trò
Ngoại lệ Trong bước 2: nếu Role Domain Engineer không nhập đầy
đủ thông tin bắt buộc thì hệ thống sẽ báo lỗi và yêu cầu
nhập lại
Trong bước 4: nếu vai trò này đã tồn tại thì hệ thống sẽ báo
lỗi và yêu cầu nhập tên khác.
Điều kiện tiên quyết Use case " Session Establishing" đã được xử lý
Kết quả Một vai trò mới được tạo ra
37
4.1.3.2. Add user
Tên use case Add role
Tác nhân Security Administrator
Miêu tả Miêu tả quá trình tạo ra một người dùng mới
Các hành động 4. use case được khởi tạo khi Security Administrator mở
ứng dụng để thêm người dùng mới.
5. Security Administrator nhập các thông tin của người
dùng mới, chọn các vai trò cho người dùng này và
submit.
6. Hệ thống thực hiện lệnh thêm mới một người dùng
Ngoại lệ Trong bước 2: nếu Security Administrator không nhập đầy
đủ thông tin bắt buộc thì hệ thống sẽ báo lỗi và yêu cầu
nhập lại
Trong bước 4: nếu người này đã tồn tại thì hệ thống sẽ báo
lỗi và yêu cầu nhập tên khác.
Điều kiện tiên quyết Use case " Session Establishing" đã được xử lý
Kết quả Một người mới được tạo ra
38
4.1.3.3. User Assignment
Tên use case User Assignment
Tác nhân Security Administrator
Miêu tả Miêu tả quá trình mà Security administrator gán vai trò cho
một regular user
Các hành động 7. User case được khởi tạo khi security administrator mở
ứng dụng user assignment
8. Danh sách người sử dụng và các vai trò đã tồn tại sẽ
xuất hiện
9. Security administrator chọn người sử dụng được gán
cho các vai trò
10. Nếu quan hệ UA là hợp lệ, quan hệ UA này sẽ được
thêm vào hệ thống.
Ngoại lệ Trong bước 4, nếu quan hệ UA là không hợp, hệ thống sẽ
gửi một thông báo lỗi cho security administrator
Điều kiện tiên quyết Use case " Session Establishing" đã được xử lý
Kết quả Một UA được thêm
39
4.1.3.4. Permission Assignment
Tên use case Permission Assignment
Tác nhân Security Administrator
Miêu tả Miêu tả quá trình security administrator cấp quyền cho một
vai trò.
Các hành động 1.use case được khởi tạo khi security administrator mở
ứng dụng permission assignment
2.Danh sách các vai trò hiện ra
3.security administrator chọn vai trò và các quyền gán cho
vai trò này.
4.nếu quan hệ PA này là hợp lệ, quan hệ này sẽ đựoc thêm
vào hệ thống.
Ngoại lệ Trong bước 4, nếu quan hệ PA không hợp lệ thì hệ thống sẽ
gửi một thông báo lỗi cho security administrator
Điều kiện tiên quyết Use case " Session Establishing" đã được xử lý
Kết quả Một quan hệ PA được thêm vào hệ thống
40
4.1.3.5. Session Establishing
Sau khi người sử dụng đã được gán vào một số vai trò, người sủ dụng có thể thiết
lập phiên làm việc trong hệ thống dựa trên vai trò. Khi một người sử dụng thiết lập
một phiên, anh ta đầu tiên sẽ gửi lên một thỉnh cầu, hệ thống sẽ hiển thị tất cả các vai
trò mà anh ta có thể kích hoạt. Người sử dụng sau đó sẽ lựa chọn vai trò mà anh ta
muốn kích hoạt trong phiên làm việc này.
Tên use case Session Establishing
Tác nhân Regular user
Miêu tả Miêu tả quá trình một người sử dụng khởi tạo một phiên
làm việc mới.
Các hành động 1. Use case được khởi tạo khi người sử dụng mở một
ứng dụng để khởi tạo một phiên
2. Nười sử dụng xác thực cho việc khởi tạo một phiên
3. Hệ thống sẽ hiển thị tất cả các vai trò mà người sử
dụng có thể kích hoạt
4. Người sử dụng chọn các vai trò mà anh ra muốn kích
hoạt trong phiên
5. Một phiên làm việc mới được tạo ra với các vai trò
mà người sử dụng đã lựa chọn
Ngoại lệ Trong bước 2, nếu sự xác thực người sử dụng không
được công nhận, thì tiến trình bị hủy bỏ.
Điều kiện tiên quyết
Kết quả Một phiên mới được khởi tạo
41
4.2. Mô hình đối tượng
Trong mô hình đối tượng, các đối tượng và quan hệ giữa chúng được nhận biết từ
mô hình use case. Có ba hệ thống đối tượng trong mô hình đối tượng RBAC. Đó là:
Access Control System, Administration System và Role Engineering System. Hình 12
dưới đây là component view của mô hình đối tượng RBAC.
Hình 11: Mô hình đối tượng của RBAC
Hình 13 dưới đây biểu diễn mô hình các lớp thực thể trong mô hình đối tượng
RBAC.
Hình 12: Các lớp thực thể trong mô hình đối tượng của RBAC
Các lớp cơ sở và mối quan hệ giữa chúng trong hệ thống đối tượng access control
system được biểu điễn trong hình 14 dưới đây:
42
Hình 13: Các lớp cơ sở và mối quan hệ giữa chúng
4.3. Mô hình hóa động
4.3.1. Biểu đồ tuần tự (sequence diagram):
4.3.1.1. Biểu đồ tuần tự: User Assignment
Biểu đồ tuần tự dưới đây mô tả tiến trình xảy ra khi security administrator thực
hiện hành động gán một người sử dụng vào trong một hay nhiều vai trò:
: Security
administrator
:UA interface : UAControl : User : Regular
Role
: Constraint : UA
1: initiate( ) 2: initiate( )
3: ShowSessName()
4: getUserList()
5: showUserList()
6: getRoleList( )
7: showRoleList()
8: selectUser( )
9: selectRole( )
10: setUA( )
11: checkUA( )
12: AddUA( )
13: ShowResult()
Hình 14: Biểu đồ tuần tự: User Asignment
43
4.3.1.2. Biểu đồ tuần tự: Permisstion Assignment
Khi một người sử dụng đã ở trong một hay nhiều vai trò. Security administrator
có thể cấp các đặc quyền cho các vai trò này. Biểu đồ tuần tự dưới đây mô tả tiến trình
security administrator cấp đặc quyền cho một vai trò.
: Security
administrator
:PA interface :PA control :Regular role :Permission :Constraints :PA
1: Initiate() 2: Initiate()
3: getRoleList()
5: ShowRoleList()
4: getPermissionList()
6: ShowPermissionList()
7: Select role()
8: Select permissions()
9: SetPA()
10: CheckPA()
11: AddPA()
12: ShowResult()
Hình 15: Biểu đồ tuần tự: Permission Assignment
4.3.2. Biểu đồ hợp tác
4.3.2.1. Biểu đồ hợp tác: User Assignment
: Security
administrator
:UA
interface
: UAControl : User
: Regular
Role
: Constraint: UA
1: initiate( )
8: selectUser( )
9: selectRole( )
2: initiate( )
10: setUA( )
3: ShowSessName()
5: showUserList()
7: showRoleList()
13: ShowResult()
4: getUserList()
6: getRoleList( )
11: checkUA( )
12: AddUA( )
Hình 16. Biểu đồ hợp tác: User Assignment
44
4.3.2.1. Biểu đồ hợp tác: permission Assignment
: Security
administrator
:PA
interface
:PA
control
:Regular
role
:Constrai
nts
:PA
:Permissi
on
1: Initiate()
2: Initiate()
3: getRoleList()
4: getPermissionList()
5: ShowRoleList()
6: ShowPermissionList()
7: Select role()
8: Select permissions()
9: SetPA()
10: CheckPA()
11: AddPA()
12: ShowResult()
Hình 17 Biểu đồ hợp tác: permission Assignment
4.4. Thiết kế cơ sở dữ liệu
Dựa vào những phân tích ở trên chúng ta có thể đưa ra một mô hình cơ sở dữ liệu
quan hệ cho ứng dụng của chúng ta như hình 16 bên dưới. Trong mô hình này
Privilege là một tập hợp các đặc quyền mà một vai trò có thể sử dụng để thao tác trên
Domain - một tập hợp các đối tượng.
Actions là đối tượng chứa các hành động cụ thể trên một đối tượng như thêm
(insert), sửa (edit), xóa (delete), truy cập (access)…Đối tượng Object là đối tượng cụ
thể như : user_setting page, login page…
Đối tượng session được dùng để đánh dấu phiên làm việc của một người dùng
khi anh ta đang online, với đối tượng này chúng ta có thể dễ dàng kiểm soát được số
người đã đăng nhập và đang truy cập hệ thống, định thời gian dateline của một phiên
làm việc, đồng thời có thể thực hiện chính sách multi login hay singler login thông qua
đối tượng này. Điều này có nghĩa rằng chúng ta có thể sử dụng đối tượng session để
cho phép người dùng có thể cùng một lúc đăng nhập cùng một tài khoản tại các vị trí
khác nhau, hoặc chỉ cho phép người dùng được đăng nhập một lần tại một thời điểm.
Mô hình cơ sở dữ liệu quan hệ của ứng dụng RBAC được miêu tả như trong hình 19
dưới đây:
45
Hình 18: Mô hình cơ sở dữ liệu quan hệ của ứng dụng RBAC
46
CHƯƠNG 5. CÀI ĐẶT CHƯƠNG TRÌNH VÀ THỰC NGHIỆM
5.1. Môi trường và công cụ cần thiết
Như đã nói ở trên, công cụ mà chúng tôi xây dựng là một ứng dụng trên nền web,
thêm vào đó, ứng dụng này là một công cụ cho phép những nhà quản trị hệ thống có
thể dễ dàng trong việc quản lý và điều khiển truy cập, do đó chúng tôi chỉ xây dựng
ứng dụng web ở phía hậu trường (back-end). Để có thể cài đặt được chương trình nhất
thiết phải có/cài đặt đầy đủ các yêu cầu dưới đây:
1. PHP 4.0 hoặc cao hơn
2. MySql 4 hoặc cao hơn
3. Apache webserver
4. ADODB Connection layer
5.2. Cài đặt local webserver trên Ubuntu 8.10
Trước khi cài đặt chương trình, bước đầu tiên phải tiến hành là cài đặt một local
webserver để có thể dễ dàng cài đặt và test ứng dụng. Ở đây chúng tôi đã tiến hành cài
đặt một local webserver trên nền hệ điều hành Ubuntu 8.10. Các bước tiến hành như
sau:
1. Mở phần Terminal (Applications > Accessories > Terminal)
2. Cài đặt Apache: tại cửa sổ Terminal gõ lệnh sau:
$sudo apt-get install apache2
Terminal sẽ hỏi mật khẩu, nhập nó vào và enter. Để kiểm tra chắc chắn
xem apache đã được cài đặt thành công hay chưa, chúng ta chỉ việc mở
trình duyệt và gõ vào địa chỉ nếu hiện ra dòng chứ “It
works “ thì có nghĩa là chúng ta đã cài đặt thành công apache.
3. Cài đặt PHP 5: tại cửa sổ Terminal gõ lệnh sau:
$sudo apt-get install php5 libapache2-mod-php5
để PHP tương thích với Apache chúng ta phải tiến hành khởi động lại
apache bằng lệnh sau:
$sudo /etc/init.d/apache2 restart
47
4. Cài đặt MySql 5: tại cửa sổ Terminal gõ lệnh sau:
$sudo apt-get install mysql-server
5. Restart apache lại một lần nữa để hoàn tất quá trình cài đặt
5.3. Sử dụng thư viện nguồn mở ADODB thao tác với cơ sở dữ liệu
Trong ứng dụng , chúng tôi sử dụng thư viện ADODB để thao tác với cơ sở dữ
liệu. Đây là một thư viện nguồn mở khá nổi tiếng và được khá nhiều lập trình viên sử
dụng trong các ứng dụng PHP hay PyThon. Thư viện này dựa trên cùng khái niệm với
ActiveX Data Object của Microsoft. Nó cho phép nhà phát triển viết các ứng dụng một
cách khá thống nhất bất kể cơ sở dữ liệu lưu trữ thông tin phía dưới là gì. Lợi điểm của
thư viện này là cơ sở dữ liệu có thể thay đổi mà không cần phải viết lại mọi lời gọi
đến nó trong mã nguồn. Có thể download phiên bản mới nhất của ADODB từ địa chỉ
adodb.sourceforge.net. Sau khi download về, giải nén toàn bộ vào thư mục chứa mã
nguồn của chương trình hoặc có thể đặt riêng ở một nơi khác trong thư mục root.
Chúng tôi đặt đường dẫn đến thư viện này trong file config.php như sau:
…
define('DEBUG', TRUE);
define('DOMAIN', '
define('BASE_DIR', '/var/www/rbac/');
define('CLASSES_DIR', BASE_DIR.'classes/');
define('CSS_DIR', DOMAIN.'classes/form/css/');
define('TPL_DIR', BASE_DIR.'templates/');
define('FORM_INFO_IMG', 'images/question.png');
define('FORM_WARN_IMG', 'images/warning.png');
define('ADODB_INC', '/var/www/rbac/adodb5/adodb.inc.php');
define('DB_CON_FILE', BASE_DIR.'db_connection.php');
define('DB_DEF_DIR', BASE_DIR.'db/');
…
Đồng thời chúng tôi cũng đặt những thông số cần thiết cho việc kêt nối cơ sở
dữ liệu trong file db_connection.php. Nội dung của file này như sau:
<?php
$_host = 'localhost';//Tên server
$_user = 'root'; //Tên đăng nhập để quản lý cơ sở dữ liệu
$_pswd = 'abc123'; //Mật khẩu đăng nhập
$db_name = 'rbac'; //Tên cơ sở dữ liệu
?>
48
5.4. Các chức năng chính của chương trình
Như đã trình bày ở chương 4, việc cài đặt mô hình RBAC sao cho đảm bảo
được mọi yêu cầu như: xử lý các ràng buộc, kiểm tra hiệu năng…mà lý thuyết đã chỉ
ra là một việc không hề đơn giản, tốn nhiều thời gian, công sức…trong thời gian hạn
hẹp chúng tôi không thể cài đặt hết mọi chức năng cấp cao của RBAC. Trong ứng
dụng này chúng tôi chỉ tập trung cài đặt những chức năng cơ bản nhất mà một hệ
thống RBAC phải có để quản lý và điều khiển truy cập. Những chức năng này bao
gồm:
1. Quản lý các vai trò (role) và người sử dụng (user)
2. Quản lý các miền đối tượng (Domain)
3. Quản lý các đặc quyền (Privilege)
5.5. Phát triển ứng dụng
5.5.1. Quản lý các vai trò và người sử dụng
Chức năng này bao gồm các chức năng con sau:
1. Quản lý các vai trò
2. Quản lý người sử dụng
3. Quản lý việc gán người sử dụng vào các vai trò (user assignment)
4. Quản lý việc cấp quyền cho các vai trò (permission assignment)
Màn hình nhập liệu của các chức năng này như sau:
Hình 19. Màn hình nhập liệu chức năng quản lý vai trò.
Quản lý các vai trò
và người sử dụng
49
Hình 20. Màn hình nhập liệu chức năng quản lý người sử dụng
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ò
Hình 22. Màn hình nhập liệu chức năng cấp quyền cho vai trò
50
5.5.2. Chức năng quản lý các đặc quyền
Chức năng này bao gồm các chức năng con sau đây:
1. Quản lý các hành động
2. Quản lý các đặc quyền
3. Gán các hành động cụ thể vào đặc quyền
Màn hình nhập liệu của các chức năng này như sau:
Hình 23. Màn hình nhập liệu chức năng quản lý các hành động
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
Quản lý các đặc quyền
51
5.5.3. Chức năng quản lý các miền đối tượng
Chức năng này bao gồm các chức năng con sau:
1. Quản lý các đối tượng
2. Quản lý các miền đối tượng
3. Gán các đối tượng vào trong một miền
Màn hình nhập liệu của các chức năng này như sau:
Hình 25. Màn hình nhập liệu chức năng quản lý đối tượng
Hình 26. Màn hình nhập liệu chức năng quản lý miền đối tượng
Quản lý các miền đối
tượng
52
5.6. Kiểm thử
Sau khi quá trình lập trình đã hoàn tất, chúng tôi chuyển sang giai đoạn kiểm thử
để chắc chắn về tính chính xác của chương trình đã xây dựng. Trong giai đoạn này
chúng tôi đưa ra các bộ test khác nhau, mỗi một bộ test sẽ có một dữ liệu đầu vào
(input) và kết quả đầu ra (output) tương ứng với dữ liệu đầu vào đó, kết quả trả về
của chương trình phải khớp với kết quả trong bộ test, nếu không khớp thì có nghĩa là
chúng ta cần phải xem xét lại mã nguồn.
5.6.1. Đề xuất các trường hợp kiểm thử
5.6.1.1. Test case 1.
Gán người dùng ngoctuyen vào vai trò publisher và cấp quyền publish cho vai trò
publisher trên miền các đối tượng post_manage.
Input
Username ngoctuyen
Role publisher
Privilege publish
Domain post_manage
Output
Username Role Privilege Domain
ngoctuyen publisher publish post_manage
53
5.6.1.2. Test case 2.
Gán người dùng ben vào vai trò editor và cấp quyền insert cho vai trò editor trên
miền các đối tượng post_manage.
Input
Username ben
Role editor
Privilege insert
Domain post_manage
output
Username Role Privilege Domain
ben editor insert post_manage
5.6.2. Tiến hành kiểm thử và kết quả
5.6.2.1. Test case 1
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
Hình 27. kết quả thực hiện gán người sủ dụng vào vai trò trong test 1
Gán vai trò thành công
54
Kết quả của chương trình khi thực hiện lệnh cấp quyền publish cho vai trò
publisher.
Hình 28. kết quả thực hiện cấp quyền cho vai trò trong test 1
Kết luận: Như vậy kết quả thực hiện của chương trình khớp với output mong
muốn, nguời sử dụng ngoctuyen đã được gán vào vai trò publisher và vai trò
publisher được cấp quyền publish cho miền đối tượng post_manage.
5.6.2.1. Test case 2
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
Hình 29. kết quả thực hiện gán người sử dụng vào vai trò trong test 2
Gán vai trò thành công
Cấp quyền thành công
55
Kết quả của chương trình khi thực hiện lệnh cấp quyền insert cho vai trò editor
trên miền các đối tượng post_manage.
Hình 30. kết quả thực hiện cấp quyền cho vai trò trong test 2
Kết luận: Như vậy kết quả thực hiện của chương trình khớp với output mong
muốn, nguời sử dụng ben đã được gán vào vai trò editor và vai trò editor được cấp
quyền insert cho miền đối tượng post_manage.
5.7 Kết quả đạt được sau khi hoàn thành chương trình
Đã cài đặt và chạy tốt các chức năng cơ bản của một hệ thống RBAC
Cho phép nhà quản trị quản lý và điều khiển truy cập một cách trực quan và
hoàn toàn động (dynamic).
Giao diện đơn giản dễ sử dụng
5.8. Những hạn chế của chương trình
Do thời gian bị giới hạn và khuân khổ của đồ án không cho phép, chúng tôi
chưa thực sự cài đặt mô hình RBAC vào một ứng dụng cụ thể trong thực tế. Chương
trình mà chúng tôi thiết kế chỉ mang tính chất minh họa cho cách triển khai mô hình
RBAC vào một ứng dụng như thế nào, để thông qua đó làm sáng tỏ hơn nữa những
khái niệm cơ bản của mô hình RBAC, đồng thời mô tả những ưu điểm của mô hình
RBAC trong việc điều khiển truy cập.
Cấp quyền thành công
56
Một hạn chế nữa đó là chúng tôi chưa cài đặt các chức năng cao cấp trong mô
hình RBAC như sự kế thừa các vai trò, các ràng buộc SSD và DSD, cũng như các
phiên làm việc Session.
5.9. Hướng phát triển chương trình trong tương lai
Tiếp tục nghiên cứu , phân tích, thiết kế và cài đặt các chức năng cao cấp của
RBAC vào ứng dụng như đã nói ở trên. Nghiên cứu phương pháp để phát triển các cài
đặt trên thành một framework, tạo sự dễ dàng hơn trong việc tích hợp RBAC vào các
ứng dụng cụ thể có tính thực tiễn cao hơn.
57
KẾT LUẬN
Điều khiển truy cập (access control) là một khái niệm không hề mới mẻ, nó là
khái niệm được hình thành từ thuở sơ khai của ngành công nghiệp máy tính. Tuy nhiên
đây vẫn là một thách thức và gây nhiều tranh cãi trong giới chuyên môn. Một vấn đề
mà tất cả các nhà phát triển đều quan tâm là làm sao tìm ra được một mô hình điều
khiển truy cập tối ưu nhất, có thể quản lý người dùng và truy cập của họ một cách
khoa học nhất nhằm hạn chế tối đa những xâm phạm bất hợp pháp vào tài nguyên của
hệ thống. Hai mô hình tiền nhiệm của RBAC là MAC và DAC đã phần nào giải quyết
được những vấn đề trên, tuy nhiên sự giải quyết đó là chưa toàn diện và còn nhiều
khiếm khuyết. Cho đến khi mô hình RBAC ra đời, giới chuyên môn đã thực sự bị
thuyết phục bởi ưu điểm của mô hình này. RBAC gắn liền với khái niệm vai trò (role)
và cho đến ngày nay RBAC đang là một mô hình được áp dụng rộng rãi nhất không
chỉ trong các ứng dụng mà còn trong những hệ thống điều hành lớn như các hệ điều
hành mạng Windowns NT của Microsoft, NetWare của Novell, hay hệ điều hành Sun
Solaris của Sun micro system.
Sau một thời gian nỗ lực nghiên cứu và học hỏi, đến nay chúng tôi đã hoàn thành
khóa luận và đạt được những kết quả sau đây:
1. Đã tìm hiểu một cách khái quát về các mô hình điều khiển truy cập, đánh
giá được điểm mạnh và điểm hạn chế của từng mô hình.
2. Đã tìm hiểu ở mức độ cơ bản họ các mô hình điều khiển truy cập trên cơ
sở vai trò RBAC.
3. Đã phân tích và thiết kế hoàn thiện công cụ hỗ trợ bằng ngôn ngữ mô hình
hóa UML.
4. Hoàn thành việc cài đặt công cụ hỗ trợ bằng ngôn ngữ lập trình PHP trên
nền hệ điều hành nguồn mở Ubuntu sử dụng Apache webserver và cơ sở
dữ liệu MySql.
58
Tuy nhiên do hạn chế về mặt thời gian nghiên cứu, khóa luận khó tránh khỏi
những khiếm khuyết kể cả về mặt lý thuyết lẫn việc phân tích và thiết kế công cụ hỗ
trợ. Những mặt hạn chế này bao gồm:
1. Mới chỉ tìm hiểu ở mức độ cơ bản về họ các mô hình RBAC
2. Trong quá trình phân tích, thiết kế và cài đặt công cụ hỗ trợ, chưa đặc tả
được các chức năng quản trị cao cấp của RBAC như: sự kế thừa các vai
trò, sự xung đột về lợi ích của người sử dụng khi họ ở trong hai vai trò đối
lập nhau, các ràng buộc SSD, DSD, và các phiên làm việc.
Trong tương lai, chúng tôi sẽ tiếp tục mở rộng đề tài này theo hướng nghiên cứu
chuyên sâu hơn về họ các mô hình RBAC, các xung đột quyền hạn. Phân tích, thiết kế
và cài đặt thêm các chức năng cao cấp của RBAC vào công cụ hỗ trợ cũng như cách
tích hợp mô hình điều khiển truy cập RBAC trong một hệ thống thông tin hiện đại.
59
TÀI LIỆU THAM KHẢO
[1] Grady Booch and Jim Rumbaugh, Unified Method for Object-Oriented
Development v.0.8. Rational software Corp. 1995
[2] [ES99] Pete Epstein, Ravi S. Sandhu: Towards a UML Based Approach to Role
Engineering. ACM Workshop on Role-Based Access Control 1999: 135-143
[3] David Ferriaolo, Janet Cugini, and Richard Kuhn. Role-based access control
(RBAC): Features and Motivations. Proceeding s of 11th Annual Computer
Security Application Conference, pages 241-248, New Orleans, LA, Dec 11-15
1995
[4] Michael E. Shin and Gail-Joon Ahn, "UML-based Representation of Role-based
Access Control," In Proceedings of 5th IEEE International Workshop on
Enterprise Security, NIST, MD, June 14-16, 2000.
[5] Ravi Sandhu. Rational for the RBAC96 Family of Access Control Models. In
Proceedings of 1st ACM Workshop on Role-based Access control, ACM, 1997
[6] Ravi Sandhu, E. Coyne, H. Feinstein and C. Youman. Role-based access control
model. IEEE Computer, 29(2), Feb. 1996.
[7] Role Based Access Control– Draft & Presentation on RBAC standard by Wilfredo
Alvarez available at
[8] Modeling Role-Based Access Control Using Parameterized UML Models -- Dae-
Kyoo Kim, Indrakshi Ray, Robert France, Na Li
[9] P. Epstein and R. S. Sandhu. Towards a UML Based Approach to Role
Engineering. In Proceedings of the 4th ACM Workshop on Role-Based Access
Control, pages.
[10] F. Chen and R. Sandhu. Constraints for Role-Based Access Control. In
Proceedings of the 1st ACM Workshop on Role-Based Access Control,
Gaithersburg, MD, 1995.
[11]
Các file đính kèm theo tài liệu này:
- LUẬN VĂN- NGHIÊN CỨU NGÔN NGỮ ĐẶC TẢ SECURITY POLICY VÀ XÂY DỰNG CÔNG CỤ HỖ TRỢ.pdf