ĐẠ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
HÀ NỘI - 2009
iiLỜ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
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
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
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ư
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
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
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
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,
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)
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:
Copyright: Tài liệu đại học ©