1. Trang chủ
  2. » Luận Văn - Báo Cáo

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

61 1,4K 5

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 61
Dung lượng 2,37 MB

Nội dung

Truy cập là khái niệm để nói đến khả năng thực hiện một tác vụ nào đó sử dụng, đọc, thay đổi… của một chủ thể subject/user với một tài nguyên máy tính resource.Điều khiển truy cập access

Trang 1

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Trang 2

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

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

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

Hà Nội, 2013

Trang 3

1

MỤC LỤC

MỤC LỤC 1

Danh mục hình vẽ 3

Danh mục bảng 4

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

MỞ ĐẦU 6

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

1.1 Điều khiển truy cập 8

1.1.1 Điều khiển truy cập bắt buộc 8

1.1.2 Điều khiển truy cập tuỳ quyền 9

1.1.3 Điều khiển truy cập theo vai trò 9

1.1.4 Điều khiển truy cập theo luật 9

1.2 Các mô hình tham chiếu RBAC 10

1.2.1 Mô hình RBAC cơ sở 10

1.2.2 RBAC phân cấp 12

1.2.3 RBAC ràng buộc 14

1.2.4 Ưu nhược điểm của RBAC 16

1.3 Định danh dựa trên tuyên bố (Claims-based identity) 17

1.3.1 Tuyên bố (Claim) 17

1.3.2 Định danh (Identiy) 17

1.3.3 Principal 17

1.4 RBAC TRONG NET FRAMEWORK 17

1.4.1 Kiểm tra vai trò dựa trên khai báo 18

1.4.2 Kiểm tra vai trò trong mã nguồn 18

1.4.3 RBAC với ứng dụng ASP.NET 18

1.4.4 RBAC với ứng dụng ASP.NET MVC 19

1.4.5 Các hạn chế của RBAC trong Net Framework 20

Chương 2 MỞ RỘNG ĐIỀU KHIỂN TRUY CẬP RBAC VỚI LUẬT 21

Trang 4

2

2.1 Đặc tả điều khiển truy cập RBAC 21

2.2 Điều khiển truy cập theo luật 22

2.3 Mở rộng điều khiển truy cập RBAC với luật 25

2.4 Khiển khai RBAC mở rộng với luật 27

2.4.1 Kiến trúc tổng quát 27

2.4.2 Biểu đồ thành phần 29

2.4.3 Biểu đồ lớp 30

2.4.4 Biểu diễn và lượng giá luật với cây biểu thức 36

2.4.5 Authorization API 38

Chương 3 ỨNG DỤNG 41

3.1 Bài toán chia sẻ tệp 41

3.2 Phân tích, thiết kế hệ thống 42

3.2.1 Hiện trạng hệ thống 42

3.2.2 Phân tích hoạt động hệ thống 42

3.2.3 Lựa chọn nền tảng, công nghệ 43

3.2.4 Kiến trúc ứng dụng 43

3.2.5 Biểu đồ lớp 45

3.2.6 Biểu đồ trình tự 46

3.2.7 Điều khiển truy cập trong trong ứng dụng chia sẻ tệp 51

KẾT LUẬN 57

TÀI LIỆU THAM KHẢO 59

Trang 5

3

Danh mục hình vẽ

Hình 1.1: Mô hình RBAC [4] 11

Hình 1.2: Mô hình RBAC [4] 13

Hình 1.3: Mô hình SSD với RBAC phân cấp [4] 15

Hình 1.4 : Mô hình DSD [4] 15

Hình 2.1: Kiến trúc tổng quát 28

Hình 2.2: Biểu đồ thành phần 29

Hình 2.3: Biểu đồ lớp ClaimMembershipProvider 31

Hình 2.4: Biểu đồ lớp Authentication 32

Hình 2.5: Biểu đồ lớp Authorization 35

Hình 2.6: Logic điều khiển truy cập 39

Hình 3.1: Biểu đồ use case 43

Hình 3.2: Kiến trúc ứng dụng chia sẻ tệp 44

Hình 3.3: Biểu đồ lớp 45

Hình 3.4: Biểu đồ trình tự Hiển thị nội dung thư mục 46

Hình 3.5: Biểu đồ trình tự Tạo thư mục 47

Hình 3.6: Biểu đồ trình tự Upload file 47

Hình 3.7: Biểu đồ trình tự Download file 48

Hình 3.8: Biểu đồ trình tự Xóa thư mục, tệp 48

Hình 3.9: Biểu đồ trình tự Hiển thị danh sách người dùng 48

Hình 3.10: Biểu đồ trình tự Tạo người dùng 49

Hình 3.11: Biểu đồ trình tự Cập nhật thông tin người dùng 50

Hình 3.12: Biểu đồ trình tự Xóa người dùng 50

Trang 6

4

Danh mục bảng

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

Trang 7

5

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

Trang 8

6

MỞ ĐẦU

Các hệ thống phần mềm thường có nhiều người sử dụng, mỗi người sử dụng lại có các vai trò khác nhau, hay nói cách khác họ có tập các đặc quyền khác nhau Vì thế cần đảm bảo rằng mỗi người sử dụng chỉ có thể thực hiện được các tác vụ mà họ có đặc quyền.Do đó, vấn đề đảm bảo an ninh trong các ứng dụng là một trong các yêu cầu quan trọng, cần quan tâm xem xét

Truy cập là khái niệm để nói đến khả năng thực hiện một tác vụ nào đó (sử dụng, đọc, thay đổi…) của một chủ thể (subject/user) với một tài nguyên máy tính (resource).Điều khiển truy cập (access control) là khái niệm để chỉ sự cho phép hay hạn chế sự truy cập của chủ thể với tài nguyên máy tính dưới một cách thức nào đó[6]

Kiểm soát truy cập là thuật ngữ dễ gây hiểu nhầm, trong một số trường hợp

nó được hiểu như sự kiểm soát quyền truy cập vào hệ thống từ bên ngoài (ví

dụ như kiểm soát quá trình đăng nhập, qua đó người dùng được truy cập vào vào máy chủ hay máy cá nhân).Trong thực tế, kiểm soát truy cập như vậy được gọi là xác thực (authenticate) người dùng.Trong khi, kiểm soát truy cập

đề cập đến việc kiểm soát quyền truy cập vào tài nguyên hệ thống sau khi thông tin tài khoản của người dùng đã được xác thực Ví dụ, một người dùng

cụ thể, hoặc một nhóm người sử dụng, chỉ có thể được phép truy cập vào các tập tin nhất định sau khi đã đăng nhập hệ thống, trong khi đồng thời bị từ chối quyền truy cập vào tất cả các tài nguyên khác

Với điều khiển truy cập theovai trò (Role Based Access Control – RBAC)[4], mỗi người sử dụng sẽ được gán một hoặc nhiều vai trò, mỗi vai trò có một tập các quyền truy xuất Quyền truy cập của mỗi người dùng là hợp các tập quyền truy xuất của tất cả các vai trò mà người sử dụng hiện đang thuộc về

RBAC là một phương pháp đơn giản, trực quan và hiệu quả, song nó vẫn còn những hạn chế, chẳng hạn như khi có hai người sử dụng có cùng một vai trò, nhưng quyền truy xuất khác nhau, do có các thông tin ngữ cảnh khác nhau Vì thế ta cần bổ sung thêm thông tin ngữ cảnh khi ra quyết định cho phép hay từ chối truy cập.Trên các Framework như EJB hay Net Framework đều hỗ trợ RBAC, tuy nhiên khi cần điều khiển truy cập theo vai trò kết hợp với các thông tin ngữ cảnh khác của người dùng thì mỗi ứng dụng phải tự xây dựng module điều khiển truy cập, việc này nghĩa là ngoài việc cài đặt nghiệp vụ của

Trang 9

7

ứng dụng, họ còn phải lo phần bảo mật của ứng dụng Việc tự cài đặt module điều khiển truy cập có thể bị sai sót, dẫn đến các kết quả đáng tiếc.Do vậy, tác giả đã đề xuất phương pháp mở rộng RBAC theo ngữ cảnh bằng phương sử dụng luật và triển khai đề xuất trên Net Framework Theo đó, các ứng dụng

sẽ không cần phải xây dựng module điều khiển truy cập riêng, mà chỉ cần mô

tả tài nguyên cần bảo vệ trong chương trình và định nghĩa các vai trò, các luật trong file điều khiển truy cập

Bố cục của luận văn như sau:

Chương 1, luận văn nghiên cứu phương pháp điều khiển truy cập theovai trò, các mô hình điều khiển truy cập RBAC Phân tích ưu, nhược điểm của RBAC

Chương 2, luận văn giới thiệu về điều khiển truy cập trong Net Framework, các hạn chế của điều khiển truy cập trong Net Framework

Chương 3, luận văn đề xuất một đặc tả truy cập dựa trên tệpmô tả, đặc tả truy cập dựa trên luật, đề xuất đặc tả cho phép mở rộng RBAC theo ngữ cảnh bằng cách kết hợp giữa đặc tả truy cập RBAC với luật.Cũng trong chương này luận văn đề xuất giải pháp triển khai đặc tả RBAC mở rộng với luật

Chương 4, luận văn đề xuất một ứng dụng thực tế sử dụng RBAC mở rộng như một demo cho phần triển khai RBAC mở rộng

Trang 10

8

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

1.1 Điều khiển truy cập

Điều khiển truy cập là một phương thức dùng để hạn chế hoặc cho phép người dùng thực hiện thao tác nào đó trên tài nguyên[4] Các tài nguyên ở đây được hiểu theo nghĩa rộng, nó có thể là các mục dữ liệu trong CSDL, tệp, máy

in v.v Các thao tác có thể là đọc, ghi, cập nhật v.v

Điều khiển quyền truy cập bao gồm các bước cơ bản:

 Định danh người dùng (Identification): bước này xác định người dùng

hệ thống là ai thông qua việc đưa ra thông tin định danh như username,

số chứng minh thư nhân dân…

 Xác thực người dùng (Authentication): bước này xác định xem người dùng có thực sự có định danh như bước trước hay không thông qua việc đưa ra thông tin xác thực như mật khẩu, vân tay mà chỉ người dùng đó biết hoặc sở hữu

 Kiểm soát quyền truy cập (Authorization): bước này xác định xem người dùng được làm gì trong hệ thống

Có nhiều phương pháp điều khiển truy cập khác nhau, song chúng được chia thành hai loại cơ bản: điều khiển truy cập bắt buộc (Mandatory Access Control - MAC) vàđiều khiển truy cập tuỳ quyền (Discretionary Access Control - DAC)[4]

1.1.1 Điều khiển truy cập bắt buộc

Điều khiển truy cập bắt buộc là khắt khe nhất trong tất cả các cấp kiểm soát[6] Ban đầu MAC được thiết kế để sử dụng bởi chính phủ MAC có một cách tiếp cận phân cấp để kiểm soát truy cập vào các nguồn tài nguyên Với MAC, việc điều khiển truy cập tới tất cả các tài nguyên hệ thống được thiết lập bởi người quản trị hệ thống, hay nói cách khác người dùng không có khả năng thay đổi quyền truy cập trên các tài nguyên hệ thống

Trong MAC, mỗi đối tượng trong hệ thống được gán một mức nhạy cảm Mức nhạy cảm của một chủ thể xác định khả năng truy cập của chủ thể.Để truy cập một đối tượng nào đấy, chủ thể phải có một mức độ nhạy cảm tương đồng hoặc cao hơn mức độ của đối tượng yêu cầu

Trang 11

9

1.1.2 Điều khiển truy cập tuỳ quyền

Với MAC, điều khiển truy cập được thiết lập bởi quản trị viên hệ thống (system administrator), thì vớiDAC, điều khiển truy cập trên một tài nguyên được thiết lập bởi người chủ của tài nguyênđó DAC là cơ chế kiểm soát truy cập mặc định cho hầu hết các hệ điều hành máy tính cá nhân[6]

Trong DAC, mỗi tài nguyên hệ thống có một danh sách truy cập (Access Control List-ACL) ACL chứa danh sách người dùng, nhóm và quyền truy

xuất cho mỗi người dùng, nhóm đó Ví dụ, người dùngA có quyền read-only, người dùng có quyền read và write, nhóm quản trị có toàn quyền

Cơ chế của DAC linh hoạt hơn nhiều so với MAC, nhưng cũng làm tăng nguy

cơ mất an toàn do không được quản lý tập trung bởi quản trị viên hệ thống

1.1.3 Điều khiển truy cập theo vai trò

Với điều khiển truy cậptheo vai trò, các quyết định truy cập dựa trên vai trò (role) mà người dùng thuộc về.Ví dụ, một kế toán trong một công ty sẽ được giao cho vai trò kế toán, được phép thực hiện các công việc liên quan đến kế toán.Tương tự như vậy, một kỹ sư phần mềm có thể được giao cho các vai trò nhà phát triển[6]

Khái niệm vai trò ở đây có điểm tương đồng với khái niệm nhóm.Nhóm người dùng thường được xem như như một tập hợp người dùng chứ không phải là một tập hợp các quyền hạn, trong khi một vai trò một mặt vừa là một tập hợp người dùng mặt khác lại là một tập hợp các quyền hạn

Trong RBAC mỗi người dùng được gắn với các vai trò, các vai trò được gán một tập quyền Dongười dùng không được cấp phép quyền một cách trực tiếp, chỉ nhận được những quyền hạn thông qua vai trò (hoặc các vai trò) của họ, việc quản lý quyền hạn của người dùng trở thành một việc đơn giản, và người

ta chỉ cần chỉ định những vai trò thích hợp cho người dùng mà thôi

1.1.4 Điều khiển truy cập theo luật

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

Trang 12

10

hệ thống sẽ kiểm tra tất cả các luật trên tài nguyên đó để quyết định cho phép hay từ chối truy cập Tương tự như MAC, người dùng không thể thay đổi được luật (quyền truy cập), chỉ có quản trị hệ thống mới có thể thay đổi được tập luật trên mỗi tài nguyên[6]

1.2 Các mô hình tham chiếu RBAC

Các mô hình tham chiếu RBAC bao gồm các phần tử cơ bản:

- User (người dùng)

- Role (vai trò)

- Objects (các đối tượng): Là những đối tượng mà người dùng muốn truy xuất, ta còn gọi Object là những tài nguyên hệ thống (system resource)

Ví dụ, như tệp, máy in, bản ghi trong cơ sở dữ liệu…

- Operations (thao tác): Là các thao tác mà người dùng thực hiện trên Object Ví dụ như read, write, print…

- Permissions (quyền hạn): Quyền thực thi Operation của chủ thể trên Object

Có bốn mô hình tham chiếu RBAC:

- RBAC cơ sở (Core RBAC),

- RBAC phân cấp (Hierarchical RBAC),

- RBAC ràng buộc tĩnh (Static Separation of Duty Relations)

- RBAC ràng buộc động (Dynamic Separation of Duty Relations)

1.2.1 Mô hình RBAC cơ sở

Mô hình này (Hình 1.1) bao gồm các phần tử cơ bản: người dùng (USERS), vai trò (ROLES), các đối tượng (OBS), các thao tác (OPS), các quyền hạn (PRMS) và mỗi quan hệ giữa chúng.Ngoài ra, mô hình RBAC cơ sở còn bao gồm một tập các phiên làm việc (SESSIONS), mỗi phiên làm việc là một ánh

xạ giữa một người dùng và một tập con các vai trò được phân công cho người dùng[4]

Trang 13

11

(PA) Permission Assignment

IONS

PRMS

(UA) User Assignment

Một user được hiểu là một người dùng Tuy nhiên khái niệm người dùng cần

được hiểu theo nghĩa rộng, vì nó có thể là máy tính, tác nhân (agent) hay một

hệ thống khác Để đơn giản ta gọi chung là người dùng

Một role là một chức năng công việc trong ngữ cảnh của một tổ chức với một

số ngữ nghĩa có liên quan về quyền hạn và trách nhiệm

Một permission là một quyền hạn được phê duyệt để thực hiện một hoạt động

trên một hoặc nhiều đối tượng được bảo vệ

Một operationlà hành động của người dùng trên tài nguyên.Các operation có

thể có phụ thuộc vào mỗi hệ thống cụ thể, mỗi loại tài nguyên cụ thể Ví dụ, trong một hệ thống tập tin, các hoạt động có thể là read, write và execute; trong một hệ quản trị cơ sở dữ liệu, các hoạt động có thể là insert, update, và delete

Mục đích của bất kỳ cơ chế điều khiển truy cập nào là để bảo vệ tài nguyên hệ thống Tuy nhiên, trong RBAC chúng ta sử dụng thuật ngữ đối tượng được bảo vệ để nói đến các đối tượng chứa thông tin cần được bảo vệ như tệp, thư mục, hệ điều hành, bản ghi trong cơ sở dữ liệu hoặc cũng có thể là máy in, ổ cứng, CPU

Mỗi phiên là một ánh xạ của một người dùng tới các vai trò có thể, một người dùng thiết lập một phiên trong đó người dùng kích hoạt một số tập con của vai trò mà họ được phân công.Mỗi phiên được liên kết với một người dùng duy nhất và mỗi người dùng kết hợp với một hoặc nhiều phiên

Đặc tả RBAC cơ sở[4]:

Trang 14

12

- USERS, ROLES, OPS, vàOBS (users, roles, operations, và objects)

- UA USERS × ROLES, là quan hệ nhiều-nhiều giữa tập người dùng

với tập vai trò, một người dùng có thể có nhiều vai trò, một vai trò có thể có nhiều người dùng

- assigned_users(r:ROLES)→2 USERS , ánh xạ của vai trò r trên một tập người dùng: assigned_users(r) = {uUSERS | (u, r ) UA}

- PRMS = 2 (OPS × OBS), tập các quyền hạn

- PA PRMS × ROLES, là quan hệ nhiều-nhiều giữa tập quyền với

tập vai trò, một vai trò có thể được cấp nhiều quyền, một quyền có thể được cấp cho nhiều vai trò

- assigned_permissions(r: ROLES)→2 PRMS , ánh xạ của vai trò r lên một tập các quyền hạn: assigned_permissions(r) = {p PRMS | (p,r)

- avail_session_perms(s: SESSIONS)→2 PRMS, các quyền hạn có thể đối với một người dùng trong một phiên

Trang 15

13

(PA) Permission Assignment

IONS

PRMS

(UA) User Assignment

- Role

(RH) Role Hierarchy

Hình 1.2: Mô hình RBAC[4]

Điểm mấu chốt của mô hình này là giữa các vai trò có thể có quan hệ kế thừa,

nó cho phép một role con kế thừa tất cả các quền hạn của role cha.Có hai kiểu

kế thừa đó là: Mô hình phân cấp vai trò tổng quát (General Role Hierarchies)

và Mô hình phân cấp vai trò hạn chế (Limited Role Hierarchies)[4]

Mô hình phân cấp vai trò tổng quáthỗ trợ đa kế thừa (multiple inheritance)

Điều này có nghĩa là một role có thể kế thừa từ nhiều role khác

Định nghĩa hình thức[4]:

1 RH ROLES × ROLES được gọi là quan hệ kế thừa, viết tắt là ,

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

Trang 16

RBAC ràng buộc (Hình 1.3) thêm các quan hệ phân chia trách nhiệm (Separation of Duty - SoD) vào mô hình RBAC cơ sở SoD được sử dụng để tránh xung đột về quyền hạn khi một người thuộc về các vai trò khác nhau

Mô hình RBAC ràng buộc được chia thành hai loại: Ràng buộc tĩnh (Static Separation of Duty Relations - SSD) vàràng buộc động (Dynamic Separation

of Duty Relations - DSD)

Ràng buộc tĩnh:

SSD ⊆ (2ROLES × N) là một tập các cặp (rs, n) trong SoD tĩnh, vớirs là một tập vai trò, t là một tập con của rs, và n là một số tự nhiên ≥ 2, với đặc tính không có người dùng nào được gán tới n hoặc nhiều hơn vai trò từ tập hợp rs trong mỗi cặp (rs, n) SSD Một cách hình thức:

(rs, n) SSD, t rs : |t | ≥ n rt assigned_users(r) = Ø

Ràng buộc tĩnh với RBAC phân cấp:

Đối với ràng buộc tĩnh trong mô hình RBAC phân cấp thì ta cần ràng buộc trên authorized users thay vì assigned users Một cách hình thức thì:

(rs, n) SSD, t rs : |t | ≥ n rt authorized_users(r) = Ø

Trang 17

15

(PA) Permission Assignment

IONS

PRMS

(UA) User Assignment

Hình 1.3: Mô hình SSD với RBAC phân cấp[4]

Ràng buộc động:

SoD động (Hình 1.4) cũng giống SoD tĩnh ở chỗ cả hai đều được sử dụng để giới hạn các quyền có thể được cung cấp đến người dùng DSD khác SSD ở giới hạn role được thiết lập trên mỗi phiên làm việc, điều này cho phép một người có thể có nhiều role có vai trò xung đột nhau, nhưng trong mỗi phiên làm việc thì các role được kích hoạt (active) là không xung đột Hay nói cách khác DSD cho phép một người dùng được xác thực cho hai hoặc nhiều vai trò

mà chúng xung đột nhau

(PA) Permission Assignment

IONS

PRMS

(UA) User Assignment

U

ser - S

ession

Sessio

- Role

Trang 18

16

s SESSIONS, rs2 ROLES ,role_subset 2 ROLES , n N, (rs, n) DSD, role_subsetrs, role_subsetsession_roles(s) |role_subset| < n

1.2.4 Ưunhược điểm của RBAC

1.2.4.1 Ưu điểmcủa RBAC

- Phù hợp với hầu hết các ứng dụng trong thực tế

- Mô hình đơn giản, hiệu quả

- Đơn giản trong việc quản trị quyền truy cập, thay vì quản lý quyền truy cập trên từng user ta sẽ quản lý quyền truy cập trên mỗi nhóm Việc này giúp giảm công sức, thời gian cũng như giảm rủi ro do nhầm lẫn

khả năng sử dụng lại trong mô hình RBAC

1.2.4.2 Nhược điểm của RBAC

Hầu hết các ứng dụng trong thực tế đều có thể điều khiển truy cập theo vai trò, vì thế RBAC có tính phổ dụng cao Tuy nhiên, nó cũng có một vài hạn chế:

- Không phù hợp với các ứng dụng có tài nguyên cần bảo vệ là chưa biết trước

- Không phù hợp khi quy tắc điều khiển truy cập phức tạp, việc điều khiển truy cập không chỉ dựa vào thông tin về vai trò, mà còn phụ thuộc vào các thông tin ngữ cảnh khác

- Không phù hợp với các ứng dụng mà một người dùng có thể mang nhiều vai trò mâu thuẫn nhau Điều này phần nào được giải quyết với

mô hình RBAC ràng buộc tĩnh hay động Tuy nhiên, khi các quy tắc đảm bảo tính loại trừ là phức tạp và chưa biết trước thì RBAC ràng buộc không đáp ứng được hoặc khó cài đặt

Trang 19

17

1.3 Định danh dựa trên tuyên bố (Claims-based identity)

Claims-based identity là một cách phổ biến cho các ứng dụng khi cần thông tin nhận diện về người dùng trong tổ chức của họ hoặc trong tổ chức khác hoặc trên môi trường Internet.Nó cung cấp một cách tiếp cận thống nhất cho các ứng dụng [1]

1.3.1 Tuyên bố (Claim)

Một Claim là một phát biểu (Statement) về một thực thể (con người, tổ chức) được thực hiện bởi chính nó hoặc một người khác Chủ thể cung cấp claim được gọi là provider hay issuer

1.3.3 Principal

Principallà một đối tượng đặc biệt nó gắn với ngữ cảnh bảo mật (security context) của người dùng, trong khi Identity là thông tin định danh người dùng Mỗi thread có chứa một đối tượng Principal (Thread.CurrentPrincipal), thread này sẽ thực thi trong ngữ cảnh bảo mật của đối tượng Principal Có thể hình dung Principal nhưmột thẻ bài (token) của người dùng trong ứng dụng

1.4 RBACTRONG.NET FRAMEWORK

.Net Framework hỗ trợ RBAC thông qua hai hình thức: khai báo (Declarative)

và lập trình (Imperative) [5] Ngoài ra, với ứng dụng ASP.NET còn hỗ trợ

RBAC theo URL, hay với ASP.NET MVC đưa ra lớp AuthorizeAttribute để điều khiển truy cập trên các action của controller

Trang 20

18

1.4.1 Kiểm tra vai trò dựa trên khai báo

.Net Framework cung cấp lớp PrincipalPermissionAttribute cho phép ta chỉ

định chỉ người dùng nào có vai trò nào đó mới có quyền thực thi phương thức bằng cách gắn khai báo ở đầu phương thức Ví dụ, để đảm bảo rằng chỉ có người sử dụng có vai trò là giao dịch viên mới có thể thực thi phương thức

Transfer ta làm như sau:

[ PrincipalPermission ( SecurityAction Demand, Role = "Teller" )]

void Transfer()

{

}

Việc khai báo cho phương thức Transfer thuộc tính

[PrincipalPermission(SecurityAction.Demand, Role = "Teller")] khiến Net Framework phải kiểm tra xem người dùng hiện tại (Thread.CurrentPrincipal)

có vai trò Teller hay không Nếu người dùng hiện tại không có vai trò Teller thì một SecurityException sẽ được ném ra, và như vậy phương thức Transfer

sẽ không được thực thi

1.4.2 Kiểm tra vai trò trong mã nguồn

Đôi khi ta không thể sử dụng cách thức khai báo như mục 1.4.1, bởi các lý do khác nhau như: ta chỉ muốn kiểm tra quyền truy cho một đoạn chương trình (block) mà thôi, thay vì toàn bộ phương thức, hoặc khi trong phương thức đó

có nhiều vai trò cần kiểm tra dựa vào các điều kiện khác nhau Với tình huống này ta cần đặt đoạn chương trình kiểm tra quyền truy cập vào bên trong code

của phương thức Mỗi Principal đều kế thừa từ IPrincipal, do đó để đảm bảo

chỉ những role xác định được quyền truy cập tới một tài nguyên nào đó ta sử

dụng phương thức IPrincipal.IsInRole Ví dụ, để đảm bảo rằng chỉ có người

sử dụng có vai trò là giao dịch viên mới có thể thực thi một tác vụ nào đó ta

sẽ kiểm tra như sau:

if ( Thread CurrentPrincipal.IsInRole( "Teller" ){

//Thực thi tác vụ nào đó mà chỉ có giao dị ch viên mới được phép

}

1.4.3 RBAC với ứng dụng ASP.NET

.Net Framework cho phép điều khiển truy cập theo URL thông qua việc thiết lập trong tệpweb.config của ứng dụng Ví dụ, chỉ có người sử dụng có role là

Trang 21

19

Teller mới có quyền truy xuất đến trang Transfer.aspx và chỉ có người sử dụng có role là Admin mới có quyền truy xuất đến các trang trong thư mục Account ta làm như sau:

1.4.4 RBAC với ứng dụng ASP.NET MVC

ASP.NET MVC bổ sung lớp AuthorizeAttribute cho phép điều khiển truy cập cho các action của controller Ví dụ, để đảm bảo rằng chỉ có người sử dụng

có vai trò là giao dịch viên mới có thể thực thi action Transfer ta làm như sau:

[ Authorize (Roles = "Teller" )]

public ActionResult Transfer()

{

return View();

}

Chú ý rằng AuthorizeAttribute là một ActionFilter của ASP.NET

MVC[7]Error! Reference source not found., vì thế nó chỉ có thể được gắn

cho action của controller mà thôi, ta không thể dùng nó với các phương thức khác không phải là action.Hay nói cách khác nói chỉ được sử dụng cho ứng dụng ASP.NET MVC mà thôi

Trang 22

20

1.4.5 Các hạn chế của RBAC trong Net Framework

.Net Framework chỉ cho phép điều khiển truy cập RBAC bằng cách chèn mã điều khiển truy cập vào trong chương trình, điều này dẫn đến các hạn chế:

- Logic điều khiển truy cập đan xen với logic nghiệp vụ

- Không linh hoạt khi cần thay đổi quyền truy cập, cụ thể là mỗi khi cần thay đổi điều khiển truy cập (thậm chí chỉ thay đổi tên của vai trò) cần sửa chương trình và biên dịch lại

- Việc điều khiển truy cập chưa hướng đến đối tượng được bảo vệ (tài nguyên hệ thống như tệp, printer…)

Vì thế ta cần tách biệt hoàn toàn logic điều khiển truy cập ra khỏi code (điều khiển truy cập nên được xác định trong tệp xml) Việc này cho phép code gọn hơn, linh hoạt hơn khi thay đổi quyền truy cập mà không cần sửa code và biên dịch lại chương trình.Hơn nữa việc điều khiển truy cập cần hướng tới đối tượng được bảo vệ hơn là phương thức

Trang 23

<? xmlversion = 1.0 " encoding = utf-8 " ?>

< AccessControl >

< Resources >

< ResourceName = File "

< OperationName = View "

< RoleName = Admin " ></ Role >

< RoleName = Guest, HR " ></ Role >

nguyên có thuộc tính Name cho biết định danh của tài nguyên Định danh này là duy nhất

Operation Định nghĩa phép toán trên tài nguyên

Thuộc tính Name cho biết tên phép toán, tên phép toán là duy nhất trên mỗi tài nguyên

Trang 24

22

hiện phép toán trên tài nguyên Thuộc tính Name cho biết tên vai trò

Bảng 2.1:Ý nghĩa các thẻtrong đặc tả truy cập RBAC

Đặc tả này là độc lập với code, vì thế ta có thể lưu đặc tả này trong file hoặc trong CSDL Trong luận văn này, chúng tôi lưu đặc tả truy cập trong một tệp xml.Đặc tả này cho phép ta định nghĩa các tài nguyên cần bảo vệ, các thao tác trên tài nguyên và vai trò nào được phép thực hiện thao trên tài nguyên

Ưu điểm của cách tiếp cận này là chương trình sẽ không có các chỉ thị để xác định xem vai trò nào được phép thực thi mà chỉ có chỉ thị để xác định đây là thao tác gì, trên tài nguyên nào, vì thế nó linh hoạt hơn khi ta muốn thay đổi quyền truy cập.Hơn nữa, nó hướng đến tài nguyên được bảo vệ hơn là phương thức

2.2 Điều khiển truy cập theoluật

Điều khiển truy cập theo luật cho phép ta ra quyết định chấp nhận hay từ chối truy cập bằng cách kết hợp các thông tin của người, mỗi luật là một phát biểu dưới dạng nếu - thì.Tuy nhiên Net Framework không hỗ trợ điều khiển truy cập theo luật Vì thế, chúng tôi đề xuất đặc tả điều khiển truy cập theo luật như sau:

<? xmlversion = 1.0 " encoding = utf-8 " ?>

Trang 26

Rule Định nghĩa luật Mỗi luật có hai thuộc

tính là Id và Description Thuộc tín Id là duy nhất

Conditions Định nghĩa biểu thức điều khiện của

luật Thuộc tính Operator của Condition cho biết phép toán được thực hiện Coditions được biểu diễn dạng cây biểu thức

ClaimItem Định nghĩa claim được sử dụng trong

luật, thuộc tính ClaimType cho biết claim được sử dụng, thuộc tính DataType (tùy chọn) cho biết kiểu dữ liệu của claim Việc chỉ định kiểu dữ liệu cho claim sẽ giúp việc lượng giá luật chính xác hơn

luật Thuộc tính Value cho biết giá trị của hằng số, thuộc tính DataType cho biết kiểu dữ liệu

Condtions của luật là đúng Nó có thể nhận một trong hai giá trị là Allow và Deny

nguyên có thuộc tính Name cho biết định danh của tài nguyên Định danh này là duy nhất

Trang 27

25

Operation Định nghĩa phép toán trên tài nguyên

Thuộc tính Name cho biết tên phép toán, tên phép toán là duy nhất trên mỗi tài nguyên

Rule (Thẻ con của Operation) Cho biết luật nào cần được kiểm tra khi

thực hiện Operation trên Resource

Bảng 2.2:Ý nghĩa các thẻ trong đặc tả truy cậptheo luật

Tương tự như đặc tả truy cập RBAC trong mục 2.1, đặc tả này là độc lập với code, vì thế ta có thể lưu đặc tả này trong file hoặc trong database.Đặc tả này cho phép ta định nghĩa các tài nguyên cần bảo vệ, các thao tác trên tài nguyên

và các luật

Điều khiển truy cập theo luật cho phép ta ra quyết định dựa vào việc kết hợp nhiều thông tin của người dùng với nhau, thay vì chỉ có thông tin về vai trò Hay nói cách khác, điều khiển truy cập theo luật là mềm dẻo và mạnh mẽ hơn điều khiển truy cập theo vai trò

2.3 Mở rộng điều khiển truy cập RBAC với luật

Như đã đề cập trong mục 1.2.4.1, ta cần mở rộng RBAC theo ngữ cảnh, hay nói cách khác quyết định chấp nhận hay từ chối không chỉ dựa vào vai trò của người dùng mà còn kết hợp với các thông tin khác của người dùng Vì thế, chúng tôi đề xuất kết hợp giữa RBAC với điều khiển truy cập theo luật

Chúng tôi đề xuất đặc tảmở rộng điều khiển truy cập RBAC với luật như sau:

<? xmlversion = 1.0 " encoding = utf-8 " ?>

Trang 28

< RoleName = Admin " ></ Role >

< RoleName = Guest, HR " ></></ Role >

</ Operation >

< OperationName = Update "

< RoleName = Admin " RuleId = r1 " ></ Role >

< RoleName = HR " RuleId = r2, r3 " ></ Role >

Trang 29

27

</ AccessControl >

Điểm khác biệt giữa đặc tả này với đặc tả trong mục 2.1và 2.2 là thẻ Role của Operation bao gồm hai thuộc tính Name và RuleId cho biết vai trò nào, luật nào cần được kiểm tra khi thực hiện phép toán trên tài nguyên

Đặc tả này cho phép ta định nghĩa các tài nguyên cần bảo vệ, các thao tác trên tài nguyên, các vai trò và các luậtgắn với mỗi vai trò Với cách tiếp cận này quyết định chấp nhận hay từ chối dựa vào cả vai trò lẫn các luật Hay nói cách khác ngoài thông tin về vai trò của người dùng, ta còn dựa vào thông tin ngữ cảnh khác của người dùng

2.4 Khiển khai RBAC mở rộng với luật

Trong mục này, tác giả đề xuất giải pháp triển khai RBAC mở rộng với luậttheo đặc tả được đề xuất trong 2.3 Triển khai này không nhằm hướng đến một kiểu ứng dụng cụ thể nào Vì thế, có thể sử dụng nó trong cả ứng dụng desktop (Windows form/Console) lẫn ứng dụng web (ASP.NET/ASP.NET MVC)

2.4.1 Kiếntrúc tổng quát

Triển khai ExtensibilityRBAC sử dụng WIF (Windows Identity Foundation) trên nền.Net Framework Kiến trúc tổng quát của ExtensibilityRBAC được đề xuất như sau:

Trang 30

28

ExtensibilityRBAC Infrastructure

Authentication Authorization

ClaimMembership

.NET Framework Windows Identity Foundation NET Framework Desktop/Web Application

Hình 2.1: Kiến trúc tổng quát

ExtensibilityRBACInfrastructure bao gồm 3 thành phần:

 Authentication: Thành phần này cung cấp dịch vụ xác thực người dùng,

nó được sử dụng cho các ứng dụng web Tuy nhiên, ứng dụng web có thể sử dụng một module xác thựckhác

 ClaimMembership: Thành phần này cung cấp dịch vụ quản lý thông tin người dùng, nó được sử dụng bởi module Authentication Tuy nhiên, ứng dụng có thể sử dụng trình quản lý thông tin người dùng khác

 Authorization: Điều khiển truy cập RBAC mở rộng với luật Đây là thành phần chính của ExtensibilityRBAC Nó được sử dụng trong bất

cứ ứng dụng nào (kể cả web lẫn desktop) muốn điều khiển truy cập RBAC mở rộng

ExtensibilityRBACchú trọng vào việc điều khiển truy cập.Tuy nhiên, để dễ dàng hơn cho việc sử dụng, chúng tôi đưa vào hai module Authentication và ClaimMembership như một giải pháp toàn diện Với các ứng dụng có sử dụng các dịch vụ xác thực khác như Google, Facebook vẫn có thể sử dụng module

Ngày đăng: 25/03/2015, 10:01

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
[1]. Dominick Baier (2010), “A Guide to Claims-based Identity”. Microsoft Publishing Sách, tạp chí
Tiêu đề: A Guide to Claims-based Identity
Tác giả: Dominick Baier
Năm: 2010
[2]. Rick G. Garibay (2012), “Microsoft Windows Identity Foundation Cookbook”. Packt Publishing Sách, tạp chí
Tiêu đề: Microsoft Windows Identity Foundation Cookbook
Tác giả: Rick G. Garibay
Năm: 2012
[3]. Vittorio Bertocci (2010). “Programming Windows Identity Foundation”. Microsoft Publishing Sách, tạp chí
Tiêu đề: Programming Windows Identity Foundation
Tác giả: Vittorio Bertocci
Năm: 2010
[4]. Ninghui Li (2004), “A Critique of the ANSI Standard on Role Based Access Control”, CERIAS and Department of Computer Science Purdue University Sách, tạp chí
Tiêu đề: A Critique of the ANSI Standard on Role Based Access Control
Tác giả: Ninghui Li
Năm: 2004
[6]. Neil Smyth (2009),“Security+ Essentials”. Payload MediaPublishing Sách, tạp chí
Tiêu đề: Security+ Essentials
Tác giả: Neil Smyth
Năm: 2009
[7]. Jeffrey Palermo (2012). “ASP.NET MVC 4 in Action”. Manning Publications Sách, tạp chí
Tiêu đề: ASP.NET MVC 4 in Action
Tác giả: Jeffrey Palermo
Năm: 2012
[8]. DOD (1985), Trusted Computer System Evaluation Criteria (TCSEC). Department of DefenseStandard 5200.28-STD (OrangeBook) Sách, tạp chí
Tiêu đề: Trusted Computer System Evaluation Criteria (TCSEC)
Tác giả: DOD
Năm: 1985
[9]. David F. Ferraioloand R. Kuhn (1992), “Role-Based Access Control”, In Proceedings of 15 th NIST-NCSC National Computer Security Conference, pp. 554-563 Sách, tạp chí
Tiêu đề: Role-Based Access Control”," In Proceedings of 15"th" NIST-NCSC National Computer Security Conference
Tác giả: David F. Ferraioloand R. Kuhn
Năm: 1992
[10]. David F. Ferraiolo, Ravi Sandhu, SerbanGavrila, D. Richard Kuhn, and RamaswamyChandramouli (2001), “Proposed NIST Standard for Role- Based Access Control”, ACM Transactions on Information and System Security, Vol. 4, No. 3, pp. 224–274 Sách, tạp chí
Tiêu đề: Proposed NIST Standard for Role-Based Access Control”, "ACM Transactions on Information and System Security
Tác giả: David F. Ferraiolo, Ravi Sandhu, SerbanGavrila, D. Richard Kuhn, and RamaswamyChandramouli
Năm: 2001
[11]. U. Lindqvistand E. Jonsson (1998), “A Map of Security Risks Associated with Using COTS”, Computer, vol. 31, no. 6, pp. 60–66.IEEE Computer Society Sách, tạp chí
Tiêu đề: A Map of Security Risks Associated with Using COTS”, "Computer
Tác giả: U. Lindqvistand E. Jonsson
Năm: 1998
[12]. N. R. Mead (2004), “Who Is Liable for Insecure Systems”, Computer, vol.37, no.7, pp.27-34, IEEE Computer Society Sách, tạp chí
Tiêu đề: Who Is Liable for Insecure Systems”, "Computer
Tác giả: N. R. Mead
Năm: 2004
[13]. Ravi S. Sandhu, Edward J. Coynek, Hal L. Feinsteink and Charles E Khác
[14]. Jonathan D. Moffett. Control principles and role hierarchies. In Proceedings of the Third ACM Workshop on Role-Based Access Control (RBAC 1998), October 1998 Khác
[15]. Trent Jaeger and Jonathon E. Tidswell. Practical safety in flexible access control models. ACM Transactions on Information and System Security, 4(2):158–190, May 2001 Khác

TỪ KHÓA LIÊN QUAN

TRÍCH ĐOẠN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w