Kiểm chứng cơ chế bảo mật dựa trên ast

Tài liệu tham khảo công nghệ thông tin Kiểm chứng cơ chế bảo mật dựa trên ast

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

- -Nguyễn Văn Thanh

KIỂM CHỨNG CƠ CHẾ BẢO MẬT DỰA TRÊN AST

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUYNgành: Công nghệ thông tin

HÀ NỘI – 2009

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

- -Nguyễn Văn Thanh

KIỂM CHỨNG CƠ CHẾ BẢO MẬT DỰA TRÊN AST

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUYNgành: Công nghệ thông tin

Cán bộ hướng dẫn: TS Trương Ninh Thuận

HÀ NỘI – 2009

Lời cảm ơn

Em xin gửi lời cảm ơn chân thành nhất đến TS Trương Ninh Thuận, người thầy đã

cho em định hướng, những ý kiến quý báu về kiểm chứng cơ chế bảo mật dựa trên AST

và đã tận tình hướng dẫn em hoàn thành khóa luận Thầy đã giúp đỡ em rất nhiều và đi cùng em trong suốt thời gian thực hiện khóa luận Thầy chỉ cho em cách tiếp cận, nghiên cứu một công nghệ mới, cách tìm ra giải pháp cho vấn đề mắc phải.

Em xin chân thành cảm ơn quý thầy cô và các bạn đã giúp đỡ em trong những năm học qua Em xin chân thành cảm ơn Bộ môn Công nghệ phần mềm, Khoa Công nghệ thông tin, Trường Đại Học Công Nghệ, Đại Học Quốc Gia Hà Nội đã tạo điều kiện thuận lợi cho em trong suốt quá trình học tập và làm khóa luận này.

Đề tài “Kiểm chứng cơ chế bảo mật dựa trên AST” là một đề tài khá mới mẻ lại

được hoàn thành trong quỹ thời gian hạn hẹp nên khó tránh khỏi những khiếm khuyết em mong nhận được những góp ý chân thành từ thầy cô giáo và các bạn để đề tài có thể được mở rộng và nghiên cứu kỹ hơn, đưa vào trong thực tiễn ngành Công nghệ thông tin hiện nay.

Hà Nội, ngày 10 tháng 5 năm 2009Sinh viên

Nguyễn Văn Thanh

Hình 3.1: Cấu trúc tổng quát CDTHình 3.2: Cấu trúc chi tiết của CDTHình 3.3: Giao diện DOM AST

Hình 3.4: Mô tả cách duyệt cây

Hình 4.1: Cấu trúc cây của ifStatement đơn giản

Hình 4.2: Mô tả thuật toán kiểm chứng cơ chế bảo mật

Hình 4.3: Cấu trúc của lệnh if phức tạpHình 4.4: Thể hiện phức tạp trên AST

Hình 4.4: Lỗi thể hiện trong đoạn mã

Hình 5.1: Giao diện StartPage sau khi cài CDTHình 5.2: Cấu trúc DOM AST

Hình 5.3: Giao diện chương trình Test

Hình 5.4: Giao diện khi chạy Test thành côngHình 5.5: Giao diện kết quả

Hình 5.6, 5.7: Minh họa kết quả kiểm tra chương trình.

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ềnRBAC Role-based access control – điều khiển truy cập trên cơ sở vai trò

ACL Access control list – Danh sách điều khiển truy cậpRole hierarchy Cấp bậc trong vai trò

OPS Tập hợp các hành động trên một đối tượng cụ thểTest

Quá trình chạy một chương trình để kiểm tra một thuật toán hay một bài toán cụ thể.

File Đối tượng tệp văn bản được sao lưu trên máy tínhProjectNói về một dự án được tạo ra cụ thể là EclipseSession Phiên làm việc

Tóm tắt khóa luận

Từ trước đến nay, bảo mật thông tin luôn chiếm một vai trò rất quan trọng của một tổ chức, công ty hay quốc gia Trong Công nghệ thông tin vấn đề bảo mật được chú trọng và quan tâm một cách nghiêm túc Đã có rất nhiều cơ chế bảo mật được đưa ra và thích hợp cho từng lĩnh vực riêng.

Khóa luận tập trung nghiên cứu các vấn đề liên quan đến kiểm chứng cơ chế bảo mật

thông tin dựa trên RBAC Nghiên cứu các mô hình RBAC, các ví dụ về các mô hình và

ứng dụng của các mô hình này trong thực tiễn.

Giới thiệu công cụ CDT để xây dựng mô hình kiểm chứng cơ chế bảo mật dựa trên AST (Abstract Syntax Tree) Các ứng dụng của CDT trong bài toán kiểm chứng.

Những nghiên cứu tập trung vào kiểm chứng mô hình RBAC dựa trên AST sẽ là nền

móng cho những nghiên cứu rộng hơn và khả dụng hơn trong tương lai không xa.

Để thuyết phục hơn, khóa luận đưa ra một bài toán ví dụ để kiểm chứng mô hình

RBAC0 và mã nguồn viết bằng Java (trên công cụ Eclipse) và mô hình được Test trên ngôn ngữ C/C++.

1.2 Mục tiêu khóa luận 1

1.3 Cấu trúc khóa luận 2

CHƯƠNG 2 CÁC MÔ HÌNH ĐIỀU KHIỂN TRUY CẬP 3

DỰA TRÊN VAI TRÒ 3

2.1 Giới thiệu 3

2.2 Nền tảng và động lực 4

2.3 Các vai trò và các khái niệm liên quan 7

2.4 Các mô hình một họ tham chiếu 8

CHƯƠNG 4 BÀI TOÁN KIỂM CHỨNG 36

4.1 Giới thiệu: 36

4.2 Khái quát thuật toán 36

4.3 Những khía cạnh liên quan 38

4.3.1 Khía cạnh lý thuyết 38

4.3.2 Khía cạnh thực tiễn 40

4.4 Ứng dụng thuật toán 41

4.4.1 Khái quát về ứng dụng 41

4.4.2 Mục tiêu bài toán: 41

4.4.3 Yêu cầu bài toán: 42

4.4.4 Phân tích bài toán 42

CHƯƠNG 1 GIỚI THIỆU1.1 Bối cảnh

Trong thời kỳ thông tin bùng nổ như hiện nay, tất cả các lĩnh vực trong đời sống xã hội đều sử dụng công nghệ thông tin như các cơ quan chính phủ, các ngân hàng hay các tổ chức Nhưng một thực tế đáng lo ngại là vấn đề bảo mật chưa được quan tâm thích đáng và chưa sử dụng hợp lý.

Có rất nhiều cơ chế bảo mật được nghiên cứu và triển khai thích họp cho từng lĩnh

vực khác nhau Trong các mô hình đang tồn tại thì toàn diện nhất là RBAC.

RBAC điều khiển việc truy cập dựa trên vai trò của từng người sử dụng Mô hình này

có nhiều ưu điểm, nhưng nội dung rất rộng nên khóa luận tập trung chuyên sâu vào mô

hình đơn giản nhất và đặc trưng nhất của RBAC là RBAC0.

1.2 Mục tiêu khóa luận

Khóa luận sẽ nghiên cứu những vấn đề sau:

Khái niệm RBAC và đi vào chi tiêt các mô hình RBAC Phần này giới thiệu một cách khái quát nhất RBAC là gì? Những đặc điểm, các mô hình và ứng dụng trong cơ chế

bảo mật như thế nào?

Sau khi tìm hiểu về RBAC, phần tiếp theo phát biểu bài toán kiểm chứng các mô hình của RBAC (cụ thể là RBAC0) Mã nguồn được biểu diễn dưới cấu trúc cây, phần này nêu

lên thuật toán duyệt cây và đưa ra kết luận về tính đúng đắn của mã nguồn so với mô hình

Khóa luận sẽ đề cập tới việc dùng Eclipse với công cụ CDT để sinh ra cây cú pháp trừu tượng (AST), cấu trúc AST và cách để duyệt nó

Mục tiêu quan trong của luận văn là lam sao đề xuất được một phương pháp hiệu quả

để kiểm chứng mô hình RBAC0 với phần thực thi chương trình sử dụng AST

1.3 Cấu trúc khóa luận

Khóa luận được cấu trúc như sau:

Chương 2 phân tích chi tiết về các mô hình điều khiển truy cập dựa trên vai trò

(RBAC) Các cách tiếp cận các mô hình của RBAC qua các ví dụ cụ thể

Chương 3 giới thiệu về CDT - một công cụ để triển khai bài toán kiểm chứng Giới thiệu trực quan qua các hình ảnh và các ứng dụng của thể của CDT Chương này không nói hết về CDT chỉ đề cập các phần quan trọng nhất của CDT phục vụ trực tiếp cho khóa luận.

Chương 4 nghiên cứu bài toán kiểm chứng và ứng dụng trên mô hình RBAC0 Từ cây cú pháp trừu tượng (AST) đưa ra thuật toán kiểm chứng có đầu vào là mã nguồn C/C++ và kết quả được so sánh với mô hình RBAC0 và kết luận về sự tương ứng của mô hình

so với đoạn mã chuơng trình

Chương 5 là phần thực nghiệm sẽ cụ thể thuật toán đã đề cập ở chương 4 bằng cách đưa ra một bài toán cụ thể Chương này sẽ đưa ra các chi tiết chạy chương trình và kết quả đạt được liên quan tới bài toán đang được nghiên cứu.

Chương 6 là chương cuối nêu lên kết luận về khóa luận.

CHƯƠNG 2 CÁC MÔ HÌNH ĐIỀU KHIỂN TRUY CẬPDỰA TRÊN VAI TRÒ

2.1 Giới thiệu

Khái niệm điều khiển truy cập dựa trên vai trò (RBAC) bắt đầu với hệ thống đa

người sử dụng và đa ứng dụng trực tuyến được đưa ra lần đầu vào những năm 70 Ý tưởng

trọng tâm của RBAC là permission (quyền hạn) được kết hợp với role (vai trò) và user (người sử dụng) được phân chia dựa theo các role thích hợp Điều này làm đơn giản phần

lớn việc quản lý những permission Tạo ra các role cho các chức năng công việc khác nhau trong một tổ chức và user cũng được phân các role dựa vào trách nhiệm và trình độ của họ Phân lại cho user từ chức năng này sang chức năng khác Những role được cấp các permission mới vì các ứng dụng gắn kết chặt chẽ với các hệ thống và các permission được hủy khỏi các role khi cần thiết.

Một role được xem như một kết cấu ngữ nghĩa mà cơ chế điều khiển truy cập đều hình thành xung quanh Một tập hợp riêng biệt những user và các permission được lập ra bởi các role chỉ là tạm thời Role ổn định hơn bởi vì hoạt động hay chức năng của một tổ

chức thường ít thay đổi hơn

Một role tương ứng với một năng lực để làm một nhiệm vụ cụ thể, ví dụ một bác sỹ nội khoa hay một dựợc sỹ Một role cũng là hiện thân của một thẩm quyền và một bổn

phận như một giám sát dự án.

Một thẩm quyền hay một trách nhiệm khác với một năng lực Jane Doe có năng lực

để điều hành một số bộ phận nhưng chỉ được phân công điều hành một bộ phận Các role phản ánh cho các nhiệm vụ được phân công cụ thể được luân phiên giữa nhiều user, ví dụ công việc của một bác sỹ nội khoa hay một quản lí ca Các mô hình RBAC và sự cài đặt nên có khả năng cải thiện cung cấp tất cả các biểu hiện của khái niệm role.

Theo một nghiên cứu mới đây của NIST [1] thì RBAC nhằm vào nhu cầu của các

ngành kinh doanh hay của cả chính phủ Trong công trình nghiên cứu của 28 tổ chức này,

nhu cầu điều khiển truy cập bị chi phối bởi nhiều mối quan tâm khác nhau gồm cả người tiêu dùng, cổ đông và sự tin cậy của các công ty bảo hiểm, sự riêng tư của thông tin cá nhân, việc ngăn chặn sự phân bố tài sản tài chính trái phép, ngăn chặn sử dụng không phép các đường dây điện thoại đường dài và sự giữ vững các tiêu chuẩn nghề nghiệp

Nhiều tổ chức đưa ra các quyết định điều khiển truy cập dựa trên role mà user là cá

nhân đảm nhận như một bộ phận của tổ chức Nhiều tổ chức thích kiểm soát tập trung và duy trì quyền truy cập, không theo ý muốn cá nhân của người quản lí hệ thống lắm mà theo các chỉ dẫn bảo vệ của tổ chức.

Bản nghiên cứu cho thấy các tổ chức thường xem các nhu cầu điều khiển truy cập của họ là duy nhất và cảm thấy các sản phẩm có sẵn thiếu sự linh hoạt.

Các role được xem như một phần của tiêu chuẩn SQL3 nổi bật cho hệ thống quản lí dữ liệu, dựa vào sự thực hiện của chúng trong Oracle 7 Các role được kết nối chặt chẽ trong hiện trạng an ninh thương mại RBAC cũng phù hợp với công nghệ đang thịnh hành và các xu hướng kinh doanh Một loạt sản phẩm cung cấp trực tiếp một dạng RBAC, các sản phẩm khác hỗ trợ những tính năng có liên quan chặt chẽ, ví dụ nhóm user, những tính năng này được sử dụng để thực hiện các role.

2.2 Nền tảng và động lực

Mục đích chính của RBAC làm cho việc quản trị an ninh và xem lại thuận tiện hơn

Nhiều hệ thống kiểm soát truy cập cho các máy tính lớn thành công về thương mại thực

hiện role quản trị an ninh Ví dụ, role là người vận hành có thể truy cập tất cả các tài nguyên mà không thay đổi các quyền truy cập, role là một nhân viên bảo vệ có thể thay đổi các quyền truy cập nhưng không được truy cập vào các tài nguyên, và role là một kiểm toán viên có thể truy cập vào các đường kiểm toán Việc sử dụng các role mang tính quản lí này cũng đựợc có trong các hệ thống điều khiển mạng hiện đại như Novell’s NetWare và Microsoft Windows NT.

Sự quan tâm mới xuất hiện trở lại đây đối với RBAC tập trung chủ yếu vào khả năng

đã được xây dựng với RBAC được mã hóa trong bản thân sự ứng dụng Các hệ điều hành hiện có và các môi trường cung cấp rất ít khả năng sử dụng RBAC ở cấp độ ứng dụng Khả

năng này bây giờ bắt đầu xuất hiện trong các sản phẩm Thách thức đặt ra là phải xác định được ứng dụng độc lập tiện lợi khá linh hoạttất nhiên dễ dàng thực hiện, sử dụng và hỗ trợ nhiều ứng dụng với sự điều chỉnh nhỏ nhất.

Các biến thể tinh vi của RBAC bao gồm khả năng thiết lập mối quan hệ giữa các role cũng như là giữa các permission và các role và giữa các user với các role.

Ví dụ, hai role có thể đươc lập sao cho loại trừ nhau do đó cùng một user không đựơc phép thực hiện cả hai role Các role cũng có thể có quan hệ kế thừa, theo đó một role kế thừa các permission được gắn cho role khác Những mối quan hệ role – role này có thể

được sử dụng để làm cho các chính sách bảo mật bao gồm sự tách rời các công việc và sự ủy thác của người có thẩm quyền Từ trước đến nay những mối quan hệ này đựợc mã hóa

trong phần mềm ứng dụng, với RBAC, chúng đựợc định rõ một lần cho một miền bảo mật.Với RBAC, người ta có thể xác định được các mối quan hệ role – permission Điều này giúp cho việc gán cho các user tới các role xác định dễ dàng Bản nghiên cứu NIST [1] chỉ ra rằng các permission được phân cho các role có xu hướng thay đổi tương đối chậm so với sự thay đổi thành viên những user các role Nghiên cứu này cũng đã nhận thấy việc cho phép các quản trị viên cấp hoặc hủy bỏ tư cách thành viên của các user trong các role đang tồn tại mà không cho các quản trị viên này quyền tạo role mới hay thay đổi sự phân chia role – permission là điều đang đựợc mong muốn.

Việc phân công các user theo role sẽ cần ít kĩ năng kĩ thuật hơn việc phân công các permission theo role Nếu không có RBAC, việc xác định permission nào được ủy thác cho user nào sẽ khó.

Chính sách điều khiển truy cập được thể hiện ở các thành tố khác nhau của RBAC như mối quan hệ role – permission, mối quan hệ user – role và mối quan hệ role – role Những thành tố này cùng xác định xem liệu một user cụ thể có được phép truy cập vào môt mảng dữ liệu trong hệ thống hay không Các thành tố RBAC có thể đựợc định dạng trực

tiếp bởi người sở hữu hệ thống hay gián tiếp bởi các role thích hợp mà người sở hữu hệ

thống ủy thác Chính sách có hiệu lực trong một hệ cụ thể nào đó là kết quả cuối cùng của

việc định dạng các thành tố RBAC khác nhau một cách trực tiếp bởi người sở hữu hệ

thống Ngoài ra chính sách điều khiển truy cập có thể gia tăng trong chu kì của hệ thống và ở các hệ lớn điều này là chắc chắn xảy ra Khả năng biến đổi chính sách để đáp ứng được

nhu cầu đang thay đổi của một tổ chức là một lợi ích quan trọng của RBAC.

Mặc dù RBAC là một chính sách trung lập, nó trực tiếp hỗ trợ ba nguyên tắc bảo mật nổi tiếng: đặc quyền ít nhất, sự tách biệt các nhiệm vụ, trừu tượng hóa dữ liệu Nguyên tắc đặc quyền ít nhất đựợc hỗ trợ vì RBAC được định dạng do đó chỉ những permission mà nhiệm vụ do các thành viên của role quản lí đó cần mới được phân cho role đó Sự tách biệt các nhiệm vụ đạt được bằng cách đảm bảo những role có quan hệ loại

trừ lẫn nhau phải đựơc sử dụng tới để hoàn thành một công việc nhạy cảm như yêu cầu một nhân viên kế toán và một quản lí kế toán tham gia vào phát hành một tấm Sec Trừu tượng

hóa dữ liệu được hỗ trợ bằng các permission trừu tượng như credit (bên có) và debit (bên nợ) cho một tài khoản, chứ không phải là các permission đọc, viết, quản lí thường đựợc hệ điều hành cung cấp Tuy nhiên, RBAC không cho phép ứng dụng các nguyên lý này Nhân viên bảo mật có thể định dạng được RBAC do đó nó vi phạm những nguyên lí này Ngoài

ra, mức độ trừu tuợng hóa dữ liệu đựợc hỗ trợ sẽ do các chi tiết bổ sung quyết định.

RBAC không phải là giải pháp cho mọi vấn để kiểm soát truy cập Người ta cần

những dạng kiểm soát truy cập phức tạp hơn khi xử lí các tình huống mà trong đó chuỗi các thao tác cần được kiểm soát Ví dụ, một lệnh mua cần nhiều bước trước khi đơn dặt hàng

mua được phát hành RBAC không cố kiểm soát trực tiếp các permission cho một chuỗi các sự kiện như vậy Các dạng khác của kiểm soát truy cập đựợc cài đặt trên bề mặt RBAC vì mục đích này Việc kiểm soát một chuỗi các thao tác ngoài phạm vi của RBAC, mặc dù RBAC có thể là nền móng để xây dựng những kiểm soát như thế.

2.3 Các vai trò và các khái niệm liên quan

Một câu hỏi thường được hỏi là “sự khác nhau giữa các role và các group là gì?”

Các nhóm user như một đơn vị kiểm soát truy cập thường được nhiều hệ thống kiểm soát truy cập cung cấp Điểm khác biệt chính giữa hầu hết các group và khái niệm role là group thường đựợc đối xử như một tập hợp những user chứ không phải là một tập hợp các permission Một role một mặt vừa là một tập hợp các user mặt khác lại là một tập hợp các permission Role đóng vai trò trung gian để kết nối hai tập hợp này lại với nhau.

Hãy xem xét hệ điều hành Unix Thành viên nhóm trong Unix được xác định ở trong

hai file /ect/password và /ect/group Do đó để xác định một user cụ thể thuộc group nào

hoặc xác định tất cả các thành viên của một group cụ thể là khá dễ dàng Các permission giành cho các nhóm dựa vào các permission kết hợp với các file cá nhân và các thư mục Để xác định permission nào một nhóm cụ thể thường có sẽ cần sự nghiên cứu kĩ luỡng cả

một cây hệ thống file Do đó việc xác định thành viên của nhóm thường dễ hơn việc xác

định permission của nhóm Ngoài ra, việc giao permission cho nhóm được phi tập trung

hóa cao Về cơ bản, người sở hữu một sub-tree (cây con) của hệ thống file Unix có thể giao permission của sub-tree đó cho một nhóm (mức độ chính xác việc này có thể làm được phụ thuộc vào dạng Unix cụ thể được nói đến) Tuy nhiên, nhóm Unix có thể được

dùng để thực hiện role trong hoàn cảnh cụ thể mặc dù theo khái niệm role của chúng tôi

các nhóm không giống nhau

Để minh họa bản chất sự khác biệt của group và role, hãy xem xét hệ thống mang

tính giả thuyết mà cần gấp đôi thời gian để xác định thành viên nhóm so với xác định

permission của nhóm Hãy cho rằng permission của nhóm và thành viên nhóm chỉ có thể

được nhân viên bảo mật hệ thống thay đổi Trong trường hợp này, cơ chế nhóm sẽ trở nên

rất gần với khái niệm role của chúng tôi

Một vấn đề được quan tâm nữa là mối quan hệ giữa role và Compartment Compartment là một phần của cấu trúc nhãn bảo mật được sử dụng trong quốc phòng hay

các cơ quan nhà nước Compartment dựa vào quan điểm cần là biết (need-to-know) có

nghĩa rộng đối với thông tin có sẵn ở một nhãn compartment tương tự nghĩa ngữ nghĩa của role Tuy nhiên, người ta sử dụng compartment cho một chính sách sở hữu thông tin một chiều riêng biệt trong hàng rào các nhãn Role không thực hiện chính sách nào thuộc

loại này cả.

Lâu nay vẫn tồn tại sự khác biệt giữa kiểm soát truy cập theo ý muốn và kiểm soát

truy cập bắt buộc được biết đến lần lượt là DAC và MAC Sự khác biệt này xuất hiện khi người ta nghiên cứu bảo mật trong ngành quốc phòng MAC cho phép việc kiểm soát truy

cập dựa vào nhãn bảo mật gửi kèm tới các user (chính xác hơn là chủ thể) và khách thể (object) DAC cho phép kiểm soát truy cập thực hiên được đối với khách thể (object) dựa

trên cơ sở permission hoặc từ chối hoặc cả hai do một user riêng biệt, thường là người sở

hữu object đó định dạng RBAC có thể được xem như một thành tố kiểm soát truy cập độc

lập, cùng tồn tại với MAC và DAC lúc thích hợp Trong trường hợp này việc truy cập sẽ được phép nếu RBAC, MAC và DAC cho phép Hi vọng rằng RBAC trong nhiều trường

hợp sẽ tự nó tồn tại

Như một vấn đề liên quan, RBAC bản thân nó là một cơ chế tùy ý hay bắt buộc? Câu trả lời phụ thuộc vào định nghĩa chính xác của cái quan niệm “tùy ý” và “bắt buộc” cũng như là bản chất thực và sự định hình các permission, role và user trong một hệ thống RBAC Việc hiểu bắt buộc có nghĩa là các user cá nhân không có sự lựa chọn nào đối với việc permission hoặc user nào được giao đến một role nào, trong khi tùy ý có nghĩa là user được tự đưa ra các quyết định này Như đã nói ở trên, RBAC bản thân nó là một chính sách trung tính Các dạng nhất định nào đó của RBAC có thể là bắt buộc, trong khi

các dạng khác có thể lại là tùy ý.

2.4 Các mô hình một họ tham chiếu

Để hiểu các chiều khác nhau của RBAC, cần xác định một dòng của 4 mô hình khái

niệm Mối quan hệ giữa 4 mô hình này được trình bày ở Hình 2.1(a) và các đặc điểm cơ

bản được minh họa ở Hình 2.1(b) RBAC0, mô hình cơ bản nằm ở dưới cùng cho thấy đó

là yêu cầu tối thiểu cho bất kì một hệ thống nào hỗ trợ RBAC RBAC1 và RBAC2 đều

bao gồm RBAC0 nhưng có thêm một số nét khác với RBAC0 Chúng được gọi là các mô hình tiên tiến RBAC1 có thêm khái niệm cấp bậc role (khi các role có thể kế thừa permission từ role khác) RBAC2 có thêm những ràng buộc (đặt ra các hạn chế chấp nhận các dạng của các thành tố khác nhau của RBAC) RBAC1 và RBAC2 không so sánh được với nhau Mô hình hợp nhất RBAC3 bao gồm cả RBAC1 và RBAC2 và cả RBAC0 nữa.

Những mô hình này là điểm tham chiếu để so sánh với các hệ thống và mô hình khác mà những nhà nghiên cứu và phát triển khác sử dụng chúng cũng như một chỉ dẫn cho việc phát triển sản phẩm và sự đánh giá sản phẩm của các khách hàng tiềm năng trong tương lai

Hiên tại, cứ cho rằng có một security officer (nhân viên an ninh) là người duy nhất có

thẩm quyền định ra các thiết lập và các mối liên hệ của những mô hình này Sau này chúng tôi sẽ giới thiệu một mô hình quản lí tinh vi hơn.

(a) Quan hệ giữa các mô hình RBAC

(b) Các mô hình RBAC

Hình 2.1: Một họ của các mô hình RBAC

2.5 Mô hình cơ sở

Mô hình cơ sở RBAC0 trình bày trong bao gồm phần ở Hình 2.1(b), không phải là

một trong 3 mô hình tiên tiến Có 3 nhóm thực thể được gọi là user (U), role (R) và permission (P) Một tập hợp các session (S) đựợc thể hiện trong biểu đồ.

User trong mô hình này là con người Khái niệm user sẽ được khái quát hóa bao gồm

cả các tác nhân thông minh và tự chủ khác như robot, máy tính cố định, thậm chí là các

mạng lưới máy tính Để cho đơn giản, nên tập trung vào user là con người Một role là một

chức năng công việc hay tên công việc trong tổ chức theo thẩm quyền và trách nhiệm trao

cho từng thành viên Một permission là một sự cho phép của một chế độ cụ thể nào đó truy cập vào một hay nhiều object trong hệ thống Các thuật ngữ authorization (sự xác thực), access right (quyền truy cập) và privilege (quyền ưu tiên) đều để chỉ một permission Các permission luôn tích cực và trao cho người có permission khả năng thực hiện một vài

công viêc trong hệ thống Các object là các số liệu object cũng như là các nguồn object

được thể hiện bằng số liệu trong hệ thống máy tính Mô hình chấp nhận một loạt các cách

diễn giải khác nhau cho các permission, ví dụ, từ những hạt rất to và thô (từ những cái sơ

lược nhất) ở đó được phép truy cập vào cả một mạng nhỏ, tới những hạt mịn (những cái tinh vi) nơi mà đơn vị truy cập chỉ là một lĩnh vực riêng nào đó của một bản chi nào đó.

Một số tài liệu về kiểm soát truy cập nói về permission từ chối “negative permission” Cái này từ chối, chứ không cho phép truy cập Trong bài, việc từ chối truy cập được gọi là sự hạn chế chứ không phải là một permission từ chối.

Bản chất của permission phụ thuộc nhiều vào các chi tiết thực hiện của một hệ thống

mà loại hệ thống đó là gì Một mô hình khái quát của kiểm soát truy cập do đó phải coi các

permission như các biểu tượng không ngắt quãng về mặt nào đó Mọi hệ thống đều bảo vệ các object trừu tượng mà nó thực hiện Do đó, một hệ điều hành bảo vệ các thứ như file,

thư mục, thiết bị, và các cổng và các thao tác như đọc, viết và thực thi Một hệ thống quản lí cơ sở dữ liệu có quan hệ sẽ bảo vệ các mối quan hệ, các tipple, thuộc tính và các hiển thị

với các thao tác SELECT, UPDATE, DELETE, và INSERT Một ứng dụng kế toán sẽ bảo vệ các tài khoản và các sổ cái với các thao tác debit (ghi bên nợ), credit (ghi bên có), transfer (chuyển khoản), create-account (tạo tài khoản), và delete-account (xóa tài khoản) Thao tác credit (ghi vào bên có) đó nên được phân cho một role chứ không nên bắt buộc phải phân cho role đó cả thao tác debit (ghi vào bên nợ) nữa

Các permission có thể áp dụng cho một object hay nhiều object Ví dụ, một permission có thể cụ thể như đọc lệnh truy cập vào một file riêng biệt nào đó hoặc có thể

là chung chung như đọc lệnh truy cập tới tất cả các file thuộc một bộ phận nào đó Các

permission cá nhân được cho vào một permission chung , do đó chúng có thể được giao

với tư cách một đơn vị riêng biệt Việc làm này phụ thuộc nhiều vào sự cài đặt.

Hình 2.1(b) cũng thể hiện mối quan hệ giữa việc phân công các user và giao cáo

permission cả hai việc này đều có nhiều quan hệ qua lại một user có thể là một thành viên của nhiều role, và một role có thể có nhiều user Tương tự như thế, một role có thể

có nhiều permission, và cùng một permission có thể được giao cho nhiều role Mấu chốt của RBAC nằm ở hai mối quan hệ này Rut cục thì chính user là người thực hiện các permission Sự sắp đặt một role như một phương tiện trung gian cho phép user thực hiện một permission tạo cho sự kiểm soát lớn lên sự định dạng và xem xét truy cập hơn nhiều so với việc để user tiếp cận trực tiếp với permission.

Mỗi session là một tham chiếu của một user tới những role có thể, ví dụ, một user thiết lập một session khi mà user kích hoạt một vài tập con của các role mà anh ấy hay cô

ấy là một thành viên Mũi tên hau đầu từ session to R trong Hình 2.1(b) cho biết những

role được kích hoạt cùng lúc Permission có thể được user kết hợp các permission từ tất cả các role được kích hoạt trong session đó Mỗi session được kết hợp với một đơn người

dùng, như cho biết bởi mũi tên một đầu từ session tới U trong Hình 2.1(b) Sự kết hợp này

lưu giữ hằng cho cuộc sống của một session.

Một user có thể có đa sessions mở trong cùng một thời gian, mỗi cái trong một cửa sổ trên màn hình của máy trạm cho từng trường hợp Mỗi session có thể có một sự kết hợp khác của những role hoạt động Tính năng này của RBAC0 trợ giúp nguyên tắc của quyền lợi tối thiểu Một user là thành viên của một vài role có thể gọi nhiều tập con của chúng mà phù hợp cho công việc đã hoàn thành trong session đó Như vậy, một user là một thành viên của một role quyền lực nhất có thể thông thường giữ role không hoạt động này và rõ

ràng kích hoạt nó khi cần thiết Có thể trì hoãn sự xem xét của tất cả các loại của ràng buộc,

bao gồm các ràng buộc trên các role đang hoạt động, với RBAC2 Như thế trong RBAC0 nó được toàn vẹn tùy vào sự thận trọng của user như với những role được kích hoạt trong một session định sẵn RBAC0 cũng cho phép những role kích hoạt và không kích hoạt động trong suốt thời gian hiệu lực của session Khái niệm của một session tương đương

với quan niệm truyền thống của một chủ thể trong khi truy cập điều khiển tài liệu Một chủ

thể (hay một session) là một đơn vị của truy cập điều khiển, và một user có thể có đa chủ thể (hay session) khác với nhưng permission hoạt động trong cùng một thời gian.

Công thức định nghĩa được cho bên dưới

Định nghĩa 1: Mô hình RBAC0 có các thành phần:

• U, R, P và S (user, roles, permission và session riêng biệt)

• PA ⊆P x R, một quan hệ nhiều – nhiều gán cho permission tới role.

• UA ⊆U x R, một quan hệ nhiều – nhiều gán cho user tới role.

• user: S→U, một chức năng ánh xạ mỗi session si tới một user user(si) (Hằng số

cho thời gian tồn tại của session) và

• roles: S→2R, một chức năng tham chiếu mỗi session si tới một sự thiết lập roles roles(si) ⊆ { r | (user(si),r))∈UA}.

những thành phần này.

Những session dưới sự điều khiển của những user riêng lẻ Như những mô hình có liên quan, một user có thể tạo ra một session và chọn để kích hoạt một vài tập con của

những role của user các role hoạt động trong một session có thể đuợc thay đổi trong sự thận trọng của user Session giới hạn bởi năng lực của user Một vài hệ thống sẽ giới hạn một session nếu nó không hoạt động động trong thời gian quá dài Nói đúng ra, đây là một ràng buộc và hợp lý trong RBAC2.

Một trách nhiệm là một nghĩa vụ trên một phần của user để thi hành một hay nhiều

nhiệm vụ, nói chung là rất cần thiết cho các hoạt động trơn tru của một tổ chức Trong trách nhiệm của chúng tôi được xem như một khái niệm nâng cao mà không thuộc trong

RBAC0 Chúng tôi đã chọn không kết hợp trách nhiệm trong mô hình nâng cao và cảm

nhận sự không kết hợp các khái niệm giống như trách nhiệm trong mô hình điều khiển truy cập yêu cầu nghiên cứu trong tương lai Một cách tiếp cận là xử lý chúng giống như với các

permission Những cách tiếp cận khác có thể là cơ sở cho mô hinhg điều khiển truy cập mới giống như nhiệm vụ dựa trên sự xác thực [4].

2.6 Role có cấp bậc

(a)

Hình 2.3: Các ví dụ của Role Hierarchies

(a) Role Hierarchies

(b) Quản lý Role Hierarchies

(c) Sự riêng tư và phạm vi của Role

Hình 2.4: Role Hierarchies cho một dự án

Mô hình RBAC1 giới thiệu role có thứ bậc (RH), giống như đã trình bày sơ qua

trong Hình 2.1 Chúng cũng được cài đặt thông thường trong hệ thống như các role cung

cấp Role có thứ bậc có một nghĩa tự nhiên cho các role có cấu trúc để phản ánh một tổ

chức của permission và trách nhiêm Ví dụ về role có thứ bậc được thấy trong Hình 2.3

Bởi việc quy ước các role nhiều quyền lực hơn được hiện thị phía trên các sơ đồ và các

role ít quyền lực hơn phía dưới sơ đồ Trong Hình 2.3(a) role của người có chức vụ thấp là

Health-care provider Role là Physician là người có chức cao hơn Health-care provider và do đó thừa kế tất cả các permission từ Health-care provider Thừa kế của

permission nói rõ ra, cho ví dụ, trong Hình 2.3(a), role là Primary-care Physician thừa

kế permission từ Physician và Health-care provider Cả Primary-care Physician và Specialist Physician đều thừa kế permission từ role của Physician, nhưng mỗi loại này

sẽ có những permission khác nhau được gán trực tiếp tới chúng Hình 2.3(b) giải thích đa

thừa kế của permission, nơi mà role là Project Supervisor thừa kế cả role của Tester và Programmer.

Bằng chứng là, những cấp bậc này thứ tự từng phần Một thứ tự từng phần là một

phản thân, bổ ngữ trực tiếp và không đối xứng Sự thừa kế là phản thân bởi vì một role thừa kế permission riêng của nó, bổ ngữ trực tiếp là một yêu cầu tự nhiên trong ngữ cảnh này, và quy tắc không đối xứng ngoài các role mà thừa kế từ một cái khác và vì thế sẽ

không cần thiết.

Công thức định nghĩa của RBAC1 được đưa ra bên dưới

Định nghĩa 2 mô hình RBAC1 có những thành phần sau:

• U, R, P, S, PA, UA, và user không được thay đổi từ RBAC0,

• RH ⊆ R x R là một phần thứ tự trên R gọi là role có cấp bậc hay mối quan hệ

role có ưu thế hơn, cũng được viết như ≥ , và

• roles : S→2R được thay đổi từ RBAC0 để yêu cầu các role (si) ⊆ { r | (∃r’ ≥ r)

[(user(si), r’)∈UA]}.

Hình 2.5: Mô hình tổng quát của RH (RBAC1)

Chú ý rằng một user được cho phép tới thiết lập một session với nhiều sự kết hợp của role người chức vụ thấp tới user là thành viên của nó Hơn nữa, các permission trong một

session được gán trực tiếp tới các role của session cũng tốt như việc được gán tới các role

của người cấp bậc thấp tới những cái này.

Điều này thỉnh thoảng có ích trong thứ bậc để hạn chế phạm vi của thừa kế Xem xét

thứ bậc của Hình 2.3(b) nơi mà role là Project Supervisor là người cấp cao hơn role của

cả Tester và Programmer Bây giờ giả sử rằng Tester mong muốn giữ một vài permission riêng tư tới role của họ và chống lại sự thừa kế của họ trong thứ bậc tới người

điều hành dự án Tình hình này có thể tồn tại cho lý do chính đáng, cho ví dụ, truy cập tới một công việc chưa hoàn thành trong tiến trình có thể không thích hợp cho một người có

chức vụ cao hơn trong khi RBAC có thể hữu ích có thể giống như truy cập tới Tester Tình hình này có thể được giúp đỡ bởi việc định nghĩa một role là Test Engineer0 mới và liên

quan tới nó tới Test Engineer như hiển thị trong Hình 2.3(c).

Permission riêng tư của các Test Engineer có thể được gán tới role là Test Engineer0 Test Engineer được gán tới role là Test Engineer0 và thừa kế permission từ role là Test Engineer, mà được thừa kế ở trên trong hệ thống thứ bậc bởi role là Project Supervisor Permission của Test Engineer0, tuy nhiên, không được thừa kế bởi role là Project Supervisor Có thể gọi các role giống như Test Engine0 như các role riêng tư

Hình 2.3(c) cũng hiển thị một role riêng tư của Programmer0 Trong một vài hệ thống

hiệu quả của các role riêng tư đạt được bởi khối bên trên thừa kế của các permission chắc

chắn Trong một vài trường hợp của hệ thống thứ bậc không mô tả sự phân phối của

permission chính xác Điều này thích hợp để giới thiệu các role riêng tư và giữ nghĩa của hệ thống thứ bậc liên quan xung quanh những role không thay đổi.

Hình 2.4 hiển thị, nhiều điểm chung, một hệ thống thừa kế con của các role có thể được xây dựng như thế nào Hệ thống thứ bậc của Hình 2.4(a) có bốn role công việc, T1,

T2, T3, T4, tất cả đều thừa kế permission từ role dự án phổ biến rộng P Role S ở trên cùng của hệ thống thứ bậc dành cho Project Supervisor Công việc T3 và T4 là một dự án con với P3 như role dự án con rộng, và S3 như role giám sát dự án con Role T1’ trong

Hình 2.4(c) là một role riêng tư cho những thành viên của những nhiệm vụ T1 Giả sử dự

án con trong Hình 2.4(a) gồm có vai trog S3, T3, T4 và P3, yêu cầu một hệ thống thứ bậc

con riêng tư trong các permission riêng tư của dự án có thể được chia sẻ ngoài hệ thống thứ bậc bởi S Trong toàn thể hệ thống cấp bậc con được tái tạo trong dáng vẻ được hiện thị

trong Hình 2.4(c) Các permission có thể thừa kế bởi S có thể được gán tới S3, T3, T4 và

P3, thích hợp trong khi một trong các quyền riêng tư có thể được gán tới S3, T4, T4 và P3’, cho phép những sự thừa kế của chúng chỉ trong dự án con Nhưng trước khi thành viên

của đội dự án con được gán trực tiếp tới S3’, T3’, T4’, hay P3’ Hình 2.4(c) làm cho nó rõ

ràng như các role riêng tư tồn tại trong hệ thống và trợ giúp trong việc truy cập để xem lại tới quyết định sự tự nhiên của các permission riêng tư là gì.

2.7 Các ràng buộc

Mô hình RBAC2 giới thiệu khái niệm của ràng buộc được hiển thị trong Hình 2.1(b)

Mặc dù được gọi trong mô hình RBAC1 và RBAC2, đây không thực sự một ngụ ý của sự

tiến triển Mỗi ràng buộc hay hệ thống thứ bậc các vai trog có thể được giới thiệu đầu tiên

Điều này được chỉ ra bởi sự liên kết có một không hai giữa RBAC1 và RBAC2 trong Hình

hai role, bởi vì việc tạo ra một khả năng cho sự gian lận Đây là một nguyên tắc nổi tiếng

và được ưa chuộng được gọi sự ngăn cách các trách nhiệm.

Những ràng buộc là một cơ chế quyền lực đặt cấp cao hơn chính sách của tổ chức

Điều chắc chắn là các role được khai báo loại trừ lẫn nhau, ở đó cần quan tâm quá nhiều về nhiệm vụ của từng user riêng biệt tới các role Những hoạt động sau đó có thể được ủy

nhiệm và chuyển giao ngoài sự sợ hãi của sự thỏa hiệp toàn bộ cơ chế các đối tượng của tổ

chức Vì vậy, việc quản lý RBAC được kiểm soát toàn bộ bởi security officer, những ràng

buộc là hữu ích cho sự tiện lợi, nhưng hiệu quả cùng lúc có thể lớn hơn giành được bởi sự

quan tâm đúng đắn của phần việc của security officer Tuy nhiên, nếu sự quản lý của RBAC được chuyển giao, những ràng buộc trở thành một cơ cấu bởi security officer có chức vụ cao hơn có thể giới hạn khả năng của user mà có thể thực hiện đặc quyền quản lý

Nó cho phép chief security officer (trưởng nhân viên an ninh) thiết lập ngoài phạm vi

rộng của việc chấp nhận và lạm dụng như yêu cầu bắt buộc trên các security officer khác và những user mà tham gian trong việc quản lý RBAC.

Với sự quan tâm tới những ràng buộc RBAC có thể được áp dụng tới quan hệ UA và PA và user và các chức năng của vai trong với các session khác nhau Các ràng buộc được

khẳng định mà, được áp dụng tới các quan hệ và các chức năng, trả về một giá trị có thể chấp nhận được hay không thể chấp nhận được Các ràng buộc có thể được xem như các câu trong một vài ngôn ngữ chính thức thích hợp Bằng trực giác, các ràng buộc được xem xét tốt hơn theo từng loại của chúng và bản chất

Sau đây là định nghĩa bên dưới.

Định nghĩa 3: RBAC2 không được thay đổi từ RBAC0 ngoại trừ việc yêu cầu có

một tập hợp của các ràng buộc mà quyết định dù giá trị của các thành phần khác nhau của

RBAC0 có được chấp nhận hay không Chỉ các giá trị được chấp nhận sẽ được cho phép

Xem xét việc cài đặt chung gọi cho những ràng buộc đơn giản mà có thể kiểm tra hiệu quả

và làm cho có hiệu lực May mắn thay, trong RBAC các ràng buộc đơn giản có thể đi một

cách lâu dài.

Hầu như tất cả, các ràng buộc áp dụng liên quan tới trách nhiệm của user có một bản sao mà áp dụng liên quan tới trách nhiệm permission Vậy thì thảo luận các ràng buộc trên

hai thành phần song song.

Hầu hết các ràng buộc được đề cập đến trong ngữ cảnh của RBAC là các role loại trừ lẫn nhau Cũng giống như user được gán nhiều nhất một role trong sự thiết lập loại trừ lẫn

nhau Điều này hỗ trợ những nhiệm vụ tách rời nhau Sự cung cấp của ràng buộc này yêu

cầu ít sự tiến triển Hai ràng buộc trên permission nhiệm vụ khó nhận sự chuyển giao trong tài liệu Thực tế là, một ràng buộc loại trừ lẫn nhau trên permission nhiệm vụ có thể cung

cấp thêm sự chắc chắn cho các nhiệm vụ tách rời nhau Hai ràng buộc yêu cầu mà các

nhiệm vụ giống nhau được gán tới nhiều nhất một role trong sự thiết lập loại trừ lẫn nhau Xem xét hai role loại trừ lẫn nhau, quản lý tài khoản và quản lý mua Sự loại trừ lẫn nhau về mặt UA chỉ định mà một cá nhân riêng lẻ không thể là thành viên của cả 2 role Sự loại trừ lẫn nhau về mặt PA chỉ định mà các permission giống nhau không thể được gán tới 2 role.

Cho ví dụ, permission đưa ra kiểm tra không nên được gán tới cả 2 role Thông thường như một permission sẽ được gán tới role quản lý các tài khoản Các ràng buộc loại trừ lẫn nhau trên PA sẽ ngăn chặn permission dù cố ý hay không cố ý, được gán tới role quản lý việc mua Trực tiếp hơn nữa, các ràng buộc loại trừ trên PA là có ích để giới hạn sự phân phối các permission Cho ví dụ, điều này có thể không quan trọng khi role A hay role B đưa ra tín hiệu xác thực cho một tài khoản đặc biệt, nhưng có thể yêu cầu chỉ một trong 2 role với permission này Thông thường thành viên của user trong sự kết hợp khác nhau của các role có thể được cho rằng chấp nhận hay không Như vậy nó có thể được chấp nhận cho một người dùng là thành viên của role là Programmer và role một Tester trong các dự án khác nhau, nhưng không được chấp nhận để nhận cả 2 role trong cùng một dự án Tương tự cho việc gán permission.

Một ví dụ khác của ràng buộc gán cho user là một role có thể có một số lượng thành viên tối đa Cho trường hợp, chỉ có một người trong role của chủ tọa của một văn phòng Tương tự, số lượng của các role tới từng user riêng lẻ có thể được hạn chế Chúng tôi gọi các yếu tố ràng buộc Do đó, số các role mà permission được gán có thể có các yếu tố ràng buộc để điều khiển sự phân phối quyền lực của các permission Nó có thể được chú ý mà các yếu tố ràng buộc tối thiểu có thể khó để cài đặt Cho ví dụ nếu có một số tối thiểu user của một role, hệ thống có thể làm gì nếu một trong số họ không xuất hiện? Hệ thống hiểu

chuyện này đã xảy ra như thế nào?

Khái niệm tiên quyết của các role được dựa trên một sự tương thích và thích hợp, nhờ đó một user có thể được gán tới role A chỉ khi nếu một user đã là thành viên của một role

B Cho ví dụ, chỉ những người dùng mà role là thành viên của một dự án có thể được gán tới role của việc testing trong dự án đó Trong ví dụ này role tiên quyết là người có chức vụ thấp tới một role mới là không có thật Điều kiện giữa các role không thể so sánh được giống như xảy ra trong thực hành Hai ràng buộc gán trên permission áp dụng nhiều hơn trên role kết thúc của quan hệ PA Nó có thể có ích, với sự kiên nhẫn, để yêu cầu permission p được gán tới một role chỉ nếu role đó có permission q rồi Cho trường hợp, trong nhiều hệ thống permission để đọc một file được yêu cầu permission để đọc một thư mục chứa file được chỉ định Việc gán các mẫu ngoài permission sẽ không hoàn thành.

Các ràng buộc được gán tới user là hiệu quả chỉ nếu phù hợp bên ngoài kiến thức được giữ lại trong việc gán định danh user tới nguời thực sự Nếu một vài cá nhân riêng lẻ được gán 2 hay nhiều định danh user, sự ngăn cách và các yếu tố điều khiển phá hủy Phải

có sự tương ứng một – một giữa định danh user và người thực sự Một trách nhiệm tương

tự áp dụng tới các ràng buộc permission Nếu cùng một thao tác được thừa nhận bởi 2 permission khác nhau, hệ thống RBAC không thể thực thi hiệu quả các yếu tố và các ràng

buộc riêng biệt.

Các ràng buộc có thể được áp dụng tới các session, và chức năng user và các role kết hợp với một session Nó có thể chấp nhận cho một user là thành viên của 2 role nhưng user không thể hoạt động cả 2 role cùng lúc Các ràng buộc khác trên các session có thể giới hạn số các session mà user có thể hoạt động cùng lúc Do đó, số các session mà một permission được gán được giới hạn.

Một hệ thống thứ bậc role có thể được xem như một ràng buộc Ràng buộc này là một permission gán tới role một người có chức vụ thấp phải được gán tới tất cả các role của người có chức vụ cao hơn Hay tương đương, ràng buộc mà user được gán tới một role của người có chức vụ cao hơn phải được gán tới tất cả các role của người có chức vụ thấp hơn Trong một số ý nghĩa, RBAC1 là thừa và con của RBAC2 Tuy nhiên, chúng tôi cảm thấy nó thích hợp để đánh giá hiện trạng của hệ thống role có thứ bậc riêng của chúng Chúng

giảm sự ràng buộc chỉ bởi sự giới thiệu thừa của việc gán permission hay gán user Nó

thích hợp hơn để trợ giúp hệ thống thứ bậc trực tiếp hơn gián tiếp bởi cách của gán dư thừa.

2.8 Mô hình hợp nhất

RBAC3 là sự kết hợp của RBAC1 và RBAC2 để cung cấp cả hai hệ thống thứ bậc role và các ràng buộc Có một số kết quả xảy ra bởi đưa ra hai khái niệm đó cùng nhau.

Các ràng buộc có thể được áp dụng tới chính các hệ thống role có thứ bậc, như được

chỉ ra bởi mũi tên đậm tới RH trong Hình 2.1(b) Hệ thống role thứ bậc được yêu cầu của

sự chia ra từng phần.

Ràng buộc này là cốt lõi của mô hình Việc thêm và các ràng buộc có thể giới hạn số

các role của người cấp cao (hay người cấp thấp) mà role nhất định có thể có Hai hay nhiều role có thể được ràng buộc để không có sự phổ biến role của người cấp cao (hay người cấp

thấp) Những loại này của các ràng buộc là hữu ích trong hoàn cảnh nơi mà việc xác thực

thay đổi hệ thống role có thứ bậc được chuyển giao, nhưng trưởng security officer chuyển

toàn bộ các loại trong thay đổi được làm.

Sự ảnh hưởng lẫn nhau một cách tế nhị xuất hiện giữa các ràng buộc và các hệ thống

cấp bậc Giả sử role của Test Engineer và Programmer được khai báo loại trừ lẫn nhau

trong ngữ cảnh của Hình 2.3(b) Role là Project Supervisor vi phạm sự loại trừ lẫn nhau

này Trong một vài trường hợp như một sự vi phạm một ràng buộc loại trừ lẫn nhau bởi

role của một người cấp cao có thể được chấp nhận, trong khi các trường hợp khác là không

thể Chúng tôi cảm thấy các mô hình không nên ngoài một hay các khả năng khác Một

hoàn cảnh giống như xảy ra với các yếu tố ràng buộc Giả sử một user có thể được gán

nhiều nhất một role Liệu việc gán tới role test engineer trong Hình 2.3(b) có vi phạm ràng

buộc này? Nói theo cách khác, các yếu tố ràng buộc chỉ áp dụng trực tiếp tới các thành viên và chúng xúc tiến để các thành viên thừa kế?

Hệ thống có cấp bậc trong Hình 2.3(c) miêu tả các ràng buộc có ích trong sự thể hiện

của các role riêng tư như thế nào Trong một vài trường hợp role là Test Engineer0,

những điều này không phổ biến trong các người cấp cao cho những role này, không có sự xung đột Trong các role riêng tư chung sẽ không xó các người cấp cao thông thường với nhiều role khác nhau bởi vì chúng là những yếu tố toàn diện nhất trong hệ thống cấp bậc Sự loại trừ lẫn nhau của các role riêng tư luôn luôn được chỉ rõ ngoài sự xuất hiện của các xung đột Sự chia sẻ các bản sao của các role riêng tư có thể được riêng tư có thể được khai

báo để có một yếu tố ràng buộc toàn diện nhất không của thành viên nào Với cách này

Test Engineer phải được gán tới role là Test Engineer0 Role là Test Engineer phục vụ như một phương tiện của sự chia sẻ permission với role là Project Supervisor.

2.9 Các mô hình quản lý

Hình 2.6: Mô hình RBAC quản lý

Giả sử rằng tất cả các thành phần của RBAC dưới sự điều khiển trực tiếp của một security officer Trong các hệ thống lớn số các role có thể là hàng trăm hay hàng nghìn Việc quản lý các role này và mối tương quan của chúng là một nhiệm vụ rất khó khăn mà

thường được tập trung cao và được ủy quyền tới một đội quản lý nhỏ.

Bởi vì lợi thế chính của RBAC là việc quản lý các permission dễ dàng hơn, nó là đặc điểm tự nhiên để hỏi RBAC có thể được dùng để quản lý chính RBAC như thế nào? Tin tưởng rằng người dùng RBAC để quản lý RBAC sẽ như là một nhân tố quan trọng trong

ISO phát triển một số việc quản lý an toàn liên quan tới các chuẩn và tài liệu Mô hình ISO là hướng đối tượng và bao gồm một hệ thống có thứ bậc dựa trên chính sách

ngăn chặn (một thư mục chứa các file và một file chứa các bản ghi)

Các role có thể được kết hợp trong hướng tiếp cận ISO.

Có một chặng đường dàimô hình truyền thống cho sự truyền bá của các quyền truy cập, nơi mà quyền tới sự truyền bá các quyền được điều khiển bởi các quyền điều khiển đặc biệt Giữa gần đây nhất và được phát triển nhất của loại mô hình ma trận truy cập của

Sandhu [4] Trong khi thông thường rất khó để phân tích những hậu quả của sự công bằng

đơn giản của các quy luật cho sự truyền bá của các quyền, những mô hình này cho biết rằng những nguồn gốc đơn giản có thể được kết hợp tới sản lượng rất mềm dẻo và các hệ thống rất có ý nghĩa.

Trong ví dụ của công việc trên việc quản lý RBAC bởi Morlet và Sloman người mà

định nghĩa công bằng mô hình phức tạp dựa trên các miền role, người làm chủ, người quản

lý và quản trị bảo mật Trong sự xác thực công việc của họ không được điều khiển hay được ủy nhiệm từ một điểm tập trung, nhưng đúng hơn là sự thương lượng giữa các nhà quản lý độc lập mà chỉ có một trách nhiệm giới hạn trong mỗi người.

Mô hình quản lý RBAC được minh họa trong Hình 2.6 Một nửa phần trên của hình

này về bản chất giống với Hình 2.1(b) Các ràng buộc trong Hình 2.6 được áp dụng tới tất

cả các thành phần Nửa dưới của Hình 2.6 là ánh xạ của nửa trên cho các role quản lý và

các permission quản lý Nó được mong đợi mà các role quản lý AR và các quyền quản lý AP được tách biệt ra giữa các role thông thường R và các permission P Mô hình hiển thị các permission có thể được gán tới các role và các permission quản lý có thể chỉ được gán tới các role quản lý.

Điều này gắn liền các ràng buộc.

Một nửa trên của Hình 2.6 có thể một dãy trong sự tinh tế qua RBAC0, RBAC1,

RBAC2, và RBAC3 Nửa dưới có thể dãy đơn giản trong sự tinh tế qua ARBAC0, ARBAC1, ARBAC2, and ARBAC3 nơi mà A chứng tỏ sự quản lý.

Nhìn chung sẽ trông đợi mô hình quản lý tới mô hình đơn giản hơn chính mô hình

RBAC Do vậy ARBAC0 có thể được dùng để quản lý RBAC3, nhưng dường như không hợp lý khi dùng ARBAC3 để quản lý RBAC0.

Nó cũng quan trọng để nhận ra các ràng buộc có thể cắt cả trên và dưới của Hình 2.6

Chúng tôi xác nhận một ràng buộc gán liền mà các permission có thể được gán tới các role và các permission quản lý có thể tới các role quản lý Nếu các role quản lý loại trừ lẫn nhau với sự lưu tâm tới các role thông thường, có một vị trí mà người quản lý bảo mật có thể quản lý RBAC nhưng không dùng các đặc quyền của chúng

Làm sao để quản lý sự điều hành của hệ thống có thứ bậc? Một nguyên tắc có thể được xây dựng một cấp độ 2 trong việc quản lý hệ thống có thứ bậc tới việc quản lý cấp độ 1 và trên nó Chúng tôi cảm thấy chỉ có một cấp độ 2 của hệ thống quản lý có thứ bậc là không cần thiết Sau đây việc quản lý của quản lý hệ thống có thứ bậc được chuyển tới một

security officer Điều này là chấp nhận được với một tổ chức đơn hay một đơn vị quản lý

đơn trong một tổ chức Vấn đề đặt ra là những đơn vị này ảnh hưởng không trực tiếp được

lấy ra trong mô hình Xác thực sự quản lý trong RBAC có thể được nhìn nhận như khả năng để thay đổi sự gán lên user, gán lên quyền sử dụng và quan hệ hệ thống role có thứ bậc Trong một mô hình quản lý các permission mà được xác thực các hoạt động quản lý

này phải được định nghĩa rõ ràng Chính xác bản chất các quyền truy cập là sự cài đặt cụ thể, nhưng bản chất chung của chúng là giống nhau.

Một trong những vấn đề chính trong mô hình quản lý là phạm vi việc xác thực quản lý

được trao cho như thế nào trong các role quản lý Để minh họa cho việc xem xét này hệ

thống có thứ bậc hiển thị trong Hình 2.4(a) Hệ thống quản lý có thứ bậc trong Hình 2.4(b)

hiển thị một role của security officer trưởng (CSO) mà người cấp cao hơn tới ba role của security officer SO1, SO2 và SO3 Mối quan tâm tới phạm vi của vấn đề mà các role

trong Hình 2.4(a) có thể được được quản lý bởi các role của Hình 2.4(b) Chúng tôi sẽ nói role CSO có thể quản lý tất cả các role trong Hình 2.4(a) Giả sử SO1 quản lý công việc

T1 Nhìn chung không muốn SO1 tự động thừa kế các khả năng quản ly role cấp thấp P

Bởi vậy phạm vi của SO1 có thể được giới hạn hoàn toàn tới T1 Đơn giản là, phạm vi của SO2 có thể được giới hạn tới T2.

Thừa nhận rằng SO3 có thể quản lý trọn vẹn các dự án con gồm có S3, T3, T4 và P3 Phạm vi của SO3 là giới hạn bởi S3 ở trên đỉnh và P3 ở dưới.

Nhìn chung, mỗi role quản lý sẽ được ánh xạ tới một vài tập hợp con của role hệ

thống có cấp bậc có trách nhiệm cho ánh xạ này Có các diện mạo khác của sự quản lý mà

cần được phạm vi hóa Cho ví dụ, SO1 có thể thêm các user tới role T1 nhưng việc di chuyển của chúng yêu cầu CSO tới hành động Hơn nữa, cần tới phạm vi không chỉ các role một sự quản lý các role, mà lại các permission và user Điều này quan trọng để điều khiển thay đổi trong chính hệ thống role có cấp bậc Ví dụ, bởi vì SO3 quản lý các hệ thống có thứ bậc con giữa S3 và P3, SO3 có thể được xác thực tới việc thêm vào các nhiệm

vụ truyền thống tới các dự án con.

2.10 Kết luận

Như đã trình bày một tập hợp của các mô hình RBAC mà sự thống hóa từ đơn giản

tới phức tạp Các mô hình này cung cấp một cấu trúc phổ biến của sự tham chiếu tới một sự nghiên cứu khác và phát triển trên lĩnh vực này Chúng tôi đã trình bày một mô hình quản

lý nơi mà RBAC có thể được dùng để quản lý chính nó Sự trợ giúp này trêm vị trí của chúng rằng RBAC có chính sách trung lập hơn một mô hình của chính sách bảo mật cụ thể.

Nhiều điều còn lại được làm tới sự nhận thức khả năng của RBAC Một trong những

vấn đề nghiên cứu đáng chú ý trong lĩnh vực này là phát triển tới một sự tiếp cận có hệ

thống tới thiết kế và phân tích của các cấu hình RBAC Như đã đề cập từ trước, có ít sự thảo luận trong tài liệu về các ràng buộc trong ngữ cảnh của RBAC [8, 9, 14] Một sự phân

loại và nguyên tắc phân loại của các ràng buộc có thể hữu ích Một ký hiệu hình thức cho trạng thái và sự thi hành các ràng buộc Cùng với một vài biện pháp khó của sự thi hành sẽ được phát triển.

Khả năng về lý do của các ràng buộc và phân tích mạng lưới các hiệu ứng của cấu

hình một RBAC dưới dạng các đối tượng chính sách cấp cao hơn là một lĩnh vực nghiên

cứu mở quan trọng Khía cạnh của việc quản lý RBAC cần thiết cho công việc tương lai

Phát triển có hệ thống các phương pháp mà đề cập với sự thiết kế và phân tích của hệ thống

role có cấp bậc, các ràng buộc, và việc quản lý RBAC trong một sườn thống nhất là một

mục tiêu nghiên cứu đầy thử thách Nhiều trong các vấn đề mở này và các vấn đề được gắn kết vào nhau và sẽ yêu cầu một sự tiếp cận kết hợp với giải quyết của chúng.

CHƯƠNG 3 GIỚI THIỆU CÔNG CỤ CDT TRONG ECLIPSE3.1 Tổng quan

Eclipse CDT là một plug-in của Eclipse biến đổi Eclipse tới một khả năng C/C++ IDE Nó được thiết kế để có thể đưa ra nhiều tính năng Eclipse có được bởi những người phát triển Java tới những người phát triển C/C++, giống như người quản lý các dự án, kết hợp debugging, class wizards, build tự động, kết hợp với JDK Sự thúc đẩy của CDT và kết hợp với các công cụ chuẩn của C/C++, giống như g++, và GDB dẫn tới sự bắt đầu rất nhiều trong Linux, nơi mà các công cụ đó sẵn sàng được dùng trong việc phát triển C/C++ CDT được cài đặt trên Window để dùng giống như các công cụ khác Điều này cũng được trông đợi để dùng CDT để làm việc với các công cụ C++ của Microsoft và hấp dẫn hơn phát triển C++ trên Window.

3.2 Cấu trúc của CDT

Hình 3.1: Cấu trúc tổng quát CDT

Hình 3.2: Cấu trúc chi tiết của CDT

3.3 Các tính năng của CDT

Thành phần đầu tiên là DOM AST Tiện ích này hiển thị AST rất chi tiết và rõ ràng Với một mã nguồn cho trước có thể sinh ra AST với các node tương ứng với các đoạn mã trong file mã nguồn được cung cấp Với AST có thể kiểm soát mã nguồn tốt nhất và cho

phép định hướng, xây dựng thuật toán duyệt cây hoàn chỉnh.