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

Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ

69 703 1
Tài liệu đã được kiểm tra trùng lặp

Đ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 69
Dung lượng 1,62 MB

Nội dung

Tài liệu tham khảo công nghệ thông tin Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ

Trang 1

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

KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ thông tin

Trang 2

HÀ NỘI - 2009

Trang 3

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

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

Trang 4

HÀ NỘI - 2009

LỜI CẢM ƠN

Em xin cảm ơn bộ môn Công nghệ phần mềm – khoa công nghệ thông tin- ĐạiHọc Công Nghệ - Đại Học Quốc Gia Hà Nội đã cho phép và giúp đỡ em thực hiệnkhóa luận này Xin cảm ơn quý thầy cô trong khoa Công nghệ thông tin đã tận tìnhchỉ bảo, rèn luyện, truyền đạt những chi thức, kỹ năng, kinh nghiệm quý báu cho emtrong suốt bốn năm ở giảng đường đại học Đây là những hành trang quý giá để embướ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ờigian 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ữngchỉ 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ánhkhỏ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ủaquý 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

Trang 5

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ôngtin thư từ cho đến việc trao đổi và chia sẻ tài nguyên như hình ảnh âm thanh, các tàiliệ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ạngInternet 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ấtphá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ảomậ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ểntruy 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ảntrị 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ảntrị 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

Trang 6

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

Trang 7

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 55

KẾT LUẬN 56

Trang 8

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 53

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 54

Trang 10

DANH SÁCH CÁC THUẬT NGỮ VÀ KHÁI NIỆM

MAC Mandatory access control – điều khiển truy cập bắt buộcDAC Discretionary access control – điều khiển truy cập tùy quyền

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 độngdata 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ể

Trang 11

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ếnlượ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ẩmcô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ũinhọ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 đượcthự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ậpchung 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úcnà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ậyvớ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ảomậ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àmthế nào để đảm bảo rằng chỉ những người dùng đã được xác thực mới được phép truycậ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

Trang 12

đượ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àynhữ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ácvấ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ứcnă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ệcquả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ốicù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ìnhRBAC

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

Trang 13

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

Trang 14

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 ứngdụ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ăngnhậ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ầnmềm đều quan tâm đến các kiểu của điều khiển truy cập (access control) để chắc chắnrằ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àinguyê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 haycò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 đượcdù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ạmdụng Kỹ thuật này được phát triển để mở rộng và thay thế kỹ thuật điều khiển truycậ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ữngkhái niệm về người dùng và nhóm người dùng

Trang 15

Đặc trưng quan trọng nhất của MAC bao hàm việc từ chối người dùng toànquyề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àinguyê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 truycậ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 tamộ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ở vaitrò (RBAC) là một trong số các phương pháp điều khiển và đảm bảo quyền sử dụngcho 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ềukhiển truy cập tùy quyền – DAC và điều khiển truy cập bắt buộc – MAC DAC và

Trang 16

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ếumột hệ thống không dùng DAC thì người ta chỉ có thể cho rằng hệ thống đó dùngMAC 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ứcnă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 chongườ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ôngthườ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ềnhạ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 đốitượ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óicho ta biết phương cách cụ thể để thay đổi tệp tin đó Trong một hệ thống dùngRBAC, 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ươngtrì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

Trang 17

đượ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ànthể 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 tinkhô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

Trang 18

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 chocá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ớiRBAC đượ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ôitrường hiện tại cũng đã cung cấp một vài sự hỗ trợ RBAC ở mức độ ứng dụng Tuynhiê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 ứngdụ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ácvai 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 vaitrò 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áchnà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 đếnnay, 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ớiRBAC, 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ảntrong 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ànhphầ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ìnhtrự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

Trang 19

ủ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ếtcủ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ácnhiệ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 vaitrò 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ểmtra 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ảituâ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ácnguyê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ácdạ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à saucù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 vaitrò một nhà điều hành kinh doanh Một vai trò bao gồm quyền và trách nhiệm trong đó

Trang 20

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 quanhiề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 truycậ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ạngnhư 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 đượcgá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ệcbả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 truycậ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

Trang 21

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ứcnâ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 chocá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

Trang 22

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ạ đếnduy 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ựchiệ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}

Trang 23

 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ậctrong 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ố

Trang 24

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ò r1chứ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ữngngườ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ừauser 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ợpngườ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ộttậ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}

Trang 25

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ânchia trách nhiệm) vào mô hình RBAC SoD được sử dụng để thực thi các chính sáchxung độ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ãicho các ứng dụng trong kinh doanh, các ngành công nghiệp và chính phủ Mục đíchcủ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ôngnhiệ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 doanhnghiệ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 chophé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ể ở trongmộ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 độnglư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áctrườ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

Trang 26

(accounting supervisor) có thể thực hiện hành động chỉnh sửa thông tin của các tàikhoả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 thungâ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ânviê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 đượcphé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àntrái ngược nhau hay nói cách khác là xung đột nhau, và sẽ không bao giờ có chuyệnmộ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)

Trang 27

 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 Tuynhiê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ênkhu 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ácvai 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 chophé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ếumộ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ênlà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 ddướ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ủ

Trang 28

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

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

Trang 29

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ênthô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ị

Trang 30

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.

Hình thức hóa chức năng này như sau:

Trang 31

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ếungườ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 đã đượcgán vào vai trò này từ trước đó

Hình thức hóa chức năng này như sau:

Trang 32

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ư vaitrò 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ườidù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à đangquả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:

Trang 33

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ụnghiệ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 trongmộ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:

Trang 34

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ộtsession đang ánh xạ đến một người sử dụng hàm này trái ngược lại với hàmAddActiveRole

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 đó haykhô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ủasession này

Hình thức hóa chức năng này như sau:

Ngày đăng: 23/11/2012, 13:44

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
[3] David Ferriaolo, Janet Cugini, and Richard Kuhn. Role-based access control (RBAC): Features and Motivations. Proceeding s of 11 th Annual Computer Security Application Conference, pages 241-248, New Orleans, LA, Dec 11-15 1995 Sách, tạp chí
Tiêu đề: David Ferriaolo, Janet Cugini, and Richard Kuhn. Role-based access control (RBAC): Features and Motivations. Proceeding s of 11"th
[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 Sách, tạp chí
Tiêu đề: UML-based Representation of Role-based Access Control
[5] Ravi Sandhu. Rational for the RBAC96 Family of Access Control Models. In Proceedings of 1 st ACM Workshop on Role-based Access control, ACM, 1997 Sách, tạp chí
Tiêu đề: Ravi Sandhu. Rational for the RBAC96 Family of Access Control Models. In Proceedings of 1"st
[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 Sách, tạp chí
Tiêu đề: P. Epstein and R. S. Sandhu. Towards a UML Based Approach to Role Engineering
[7] Role Based Access Control– Draft & Presentation on RBAC standard by Wilfredo Alvarez available at http://csrc.nist.gov/rbac/ Link
[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]http://www.wikipedia.org Link
[1] Grady Booch and Jim Rumbaugh, Unified Method for Object-Oriented Development v.0.8. Rational software Corp. 1995 Khác
[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 Khác
[6] Ravi Sandhu, E. Coyne, H. Feinstein and C. Youman. Role-based access control model. IEEE Computer, 29(2), Feb. 1996 Khác
[8] Modeling Role-Based Access Control Using Parameterized UML Models -- Dae- Kyoo Kim, Indrakshi Ray, Robert France, Na Li Khác

HÌNH ẢNH LIÊN QUAN

Hình 1. Điểm khác biệt giữa RBAC và các mô hình truyền thống - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 1. Điểm khác biệt giữa RBAC và các mô hình truyền thống (Trang 17)
Hình 1. Điểm khác biệt giữa RBAC và các mô hình truyền thống - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 1. Điểm khác biệt giữa RBAC và các mô hình truyền thống (Trang 17)
3.3. Họ mô hình RBAC - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
3.3. Họ mô hình RBAC (Trang 21)
Hình 2:  Họ RBAC - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 2 Họ RBAC (Trang 21)
Hình 3. Mô hình tổng quát Core RBAC - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 3. Mô hình tổng quát Core RBAC (Trang 22)
Hình 3. Mô hình tổng quát  Core RBAC - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 3. Mô hình tổng quát Core RBAC (Trang 22)
Hình 4. Mô hình tổng quát Role hierarchy (RBAC 1) - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 4. Mô hình tổng quát Role hierarchy (RBAC 1) (Trang 23)
Hình 4. Mô hình tổng quát Role hierarchy ( RBAC 1) - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 4. Mô hình tổng quát Role hierarchy ( RBAC 1) (Trang 23)
Hình 5: Mô hình tổng quát các quan hệ SSD - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 5 Mô hình tổng quát các quan hệ SSD (Trang 26)
Hình 5:  Mô hình tổng quát các quan hệ SSD - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 5 Mô hình tổng quát các quan hệ SSD (Trang 26)
Hình 6: Mô hình tổng quát các quan hệ DSD - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 6 Mô hình tổng quát các quan hệ DSD (Trang 27)
Hình 6:  Mô hình tổng quát các quan hệ DSD - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 6 Mô hình tổng quát các quan hệ DSD (Trang 27)
Hình 7: Mô hình tổng quát RBAC cấp cao nhấ t- RBAC 3 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 7 Mô hình tổng quát RBAC cấp cao nhấ t- RBAC 3 (Trang 28)
Hình 7:  Mô hình tổng quát  RBAC cấp cao nhất - RBAC 3 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 7 Mô hình tổng quát RBAC cấp cao nhất - RBAC 3 (Trang 28)
Hình 8: Mô hình RBAC cấp cao nhất – triển khai chi tiết - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 8 Mô hình RBAC cấp cao nhất – triển khai chi tiết (Trang 29)
Hình 8:   Mô hình RBAC cấp cao nhất – triển khai chi tiết - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 8 Mô hình RBAC cấp cao nhất – triển khai chi tiết (Trang 29)
4.1.Mô hình use case - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
4.1. Mô hình use case (Trang 44)
Hình 9:  dưới đây là Component view của mô hình use case cho RBAC: - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 9 dưới đây là Component view của mô hình use case cho RBAC: (Trang 44)
Hình 10. sơ đồ use case theo từng gói chi tiết - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 10. sơ đồ use case theo từng gói chi tiết (Trang 45)
4.1.2. Sơ đồ use case: - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
4.1.2. Sơ đồ use case: (Trang 45)
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 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
rong 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 (Trang 51)
4.2. Mô hình đối tượng - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
4.2. Mô hình đối tượng (Trang 51)
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. - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
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 (Trang 51)
Hình 11: Mô hình đối tượng của RBAC - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 11 Mô hình đối tượng của RBAC (Trang 51)
Hình 13: Các lớp cơ sở và mối quan hệ giữa chúng - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 13 Các lớp cơ sở và mối quan hệ giữa chúng (Trang 52)
4.3. Mô hình hóa động - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
4.3. Mô hình hóa động (Trang 52)
Hình 14: Biểu đồ tuần tự: User Asignment - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 14 Biểu đồ tuần tự: User Asignment (Trang 52)
Hình 13: Các lớp cơ sở và mối quan hệ giữa chúng - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 13 Các lớp cơ sở và mối quan hệ giữa chúng (Trang 52)
Hình 15: Biểu đồ tuần tự: Permission Assignment - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 15 Biểu đồ tuần tự: Permission Assignment (Trang 53)
Hình 16. Biểu đồ hợp tác: User Assignment - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 16. Biểu đồ hợp tác: User Assignment (Trang 53)
Hình 15: Biểu đồ tuần tự: Permission Assignment - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 15 Biểu đồ tuần tự: Permission Assignment (Trang 53)
Hình 17 Biểu đồ hợp tác: permission Assignment - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 17 Biểu đồ hợp tác: permission Assignment (Trang 54)
Hình 17 Biểu đồ hợp tác: permission Assignment - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 17 Biểu đồ hợp tác: permission Assignment (Trang 54)
Hình 18: Mô hình cơ sở dữ liệu quan hệ của ứng dụng RBAC - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 18 Mô hình cơ sở dữ liệu quan hệ của ứng dụng RBAC (Trang 55)
Hình 18:  Mô hình cơ sở dữ liệu quan hệ của ứng dụng RBAC - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 18 Mô hình cơ sở dữ liệu quan hệ của ứng dụng RBAC (Trang 55)
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 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
h ư đã 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 (Trang 58)
Hình 19. Màn hình nhập liệu chức năng quản lý vai trò. - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 19. Màn hình nhập liệu chức năng quản lý vai trò (Trang 58)
Hình 20. Màn hình nhập liệu chức năng quản lý người sử dụng - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 20. Màn hình nhập liệu chức năng quản lý người sử dụng (Trang 59)
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ò - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
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ò (Trang 59)
Hình 20. Màn hình nhập liệu chức năng quản lý người sử dụng - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 20. Màn hình nhập liệu chức năng quản lý người sử dụng (Trang 59)
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ò - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
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ò (Trang 59)
Hình 22. Màn hình nhập liệu chức năng cấp quyền cho vai trò - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 22. Màn hình nhập liệu chức năng cấp quyền cho vai trò (Trang 59)
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 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
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 (Trang 60)
Hình 23. Màn hình nhập liệu chức năng quản lý các hành động - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 23. Màn hình nhập liệu chức năng quản lý các hành động (Trang 60)
Hình 23. Màn hình nhập liệu chức năng quản lý các hành động - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 23. Màn hình nhập liệu chức năng quản lý các hành động (Trang 60)
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 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
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 (Trang 60)
Hình 26. Màn hình nhập liệu chức năng quản lý miền đối tượng - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 26. Màn hình nhập liệu chức năng quản lý miền đối tượng (Trang 61)
Hình 25. Màn hình nhập liệu chức năng quản lý đối tượng - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 25. Màn hình nhập liệu chức năng quản lý đối tượng (Trang 61)
Hình 26. Màn hình nhập liệu chức năng quản lý miền đối tượng - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 26. Màn hình nhập liệu chức năng quản lý miền đối tượng (Trang 61)
Hình 25. Màn hình nhập liệu chức năng quản lý đối tượng - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 25. Màn hình nhập liệu chức năng quản lý đối tượng (Trang 61)
5.6.2. Tiến hành kiểm thử và kết quả 5.6.2.1. Test case 1 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
5.6.2. Tiến hành kiểm thử và kết quả 5.6.2.1. Test case 1 (Trang 63)
Hình 27. kết quả thực hiện gán người sủ dụng vào vai trò trong test 1 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 27. kết quả thực hiện gán người sủ dụng vào vai trò trong test 1 (Trang 63)
Hình 29. kết quả thực hiện gán người sử dụng vào vai trò trong test 2 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 29. kết quả thực hiện gán người sử dụng vào vai trò trong test 2 (Trang 64)
Hình 28. kết quả thực hiện cấp quyền cho vai trò trong test 1 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 28. kết quả thực hiện cấp quyền cho vai trò trong test 1 (Trang 64)
Hình 29. kết quả thực hiện gán người sử dụng vào vai trò trong test 2 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 29. kết quả thực hiện gán người sử dụng vào vai trò trong test 2 (Trang 64)
Hình 28. kết quả thực hiện cấp quyền cho vai trò trong test 1 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 28. kết quả thực hiện cấp quyền cho vai trò trong test 1 (Trang 64)
Hình 30. kết quả thực hiện cấp quyền cho vai trò trong test 2 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 30. kết quả thực hiện cấp quyền cho vai trò trong test 2 (Trang 65)
Hình 30. kết quả thực hiện cấp quyền cho vai trò trong test 2 - Nghiên cứu ngôn ngữ đặc tả security policy và xây dựng công cụ hỗ trợ
Hình 30. kết quả thực hiện cấp quyền cho vai trò trong test 2 (Trang 65)

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