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

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜ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 QUY Ngành: Công nghệ thông tin HÀ NỘI – 2009 i ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ ---------- 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 QUY Ngành: Công nghệ thông tin Cán bộ hướng dẫn: TS. Trương Ninh Thuận HÀ NỘI – 2009 ii Lời cảm ơn Em xin 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 2009 Sinh viên Nguyễn Văn Thanh iii Danh sách các hình vẽ Hình 2.1: Một họ của các mô hình RBAC Hình 2.2: Mô hình RBAC0 Hình 2.3: Các ví dụ của Role Hierarchies Hình 2.4: Role Hierarchies cho một dự án Hình 2.5: Mô hình tổng quát của RH (RBAC1) Hình 2.6: Mô hình RBAC quản lý 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 Hì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ạp Hì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 CDT Hì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ông Hì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. iv Danh sách các thuật ngữ và khái niệm THUẬT NGỮ KHÁI NIỆM MAC Mandatory access control – điều khiển truy cập bắt buộc DAC Discretionary access control – điều khiển truy cập tùy quyền RBAC ACL Role hierarchy OPS Role-based access control – điều khiển truy cập trên cơ sở vai trò Access control list – Danh sách điều khiển truy cập Cấp bậc trong vai trò Tập hợp các hành động trên một đối tượng cụ thể Quá trình chạy một chương trình để kiểm tra một thuật toán hay Test 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ính Project Nói về một dự án được tạo ra cụ thể là Eclipse Session Phiên làm việc User Người sử dụng Permission Role Expression Quyền hạn Vai trò Các biểu thức (Ở đây tập trung nói về các biểu thức điều kiện) v 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++. vi MỤC LỤC CHƯƠNG 1. GIỚI THIỆU.......................................................................... 1 1.1. Bối cảnh .......................................................................................................1 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 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 2.5. Mô hình cơ sở ............................................................................................10 2.6. Role có cấp bậc ..........................................................................................14 2.7. Các ràng buộc............................................................................................20 2.8. Mô hình hợp nhất......................................................................................24 2.9. Các mô hình quản lý .................................................................................26 2.10. Kết luận ...................................................................................................29 CHƯƠNG 3. GIỚI THIỆU CÔNG CỤ CDT TRONG ECLIPSE .......... 31 3.1. Tổng quan..................................................................................................31 3.2. Cấu trúc của CDT .....................................................................................31 3.3. Các tính năng của CDT ............................................................................32 3.4. Kết luận .....................................................................................................35 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 vii 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 4.5. Kết luận .....................................................................................................43 CHƯƠNG 5. THỰC NGHIỆM ................................................................. 45 5.1. Phạm vi ứng dụng .....................................................................................45 5.2. Thiết kế ứng dụng .....................................................................................45 5.3. Xây dựng và triển khai bài toán ...............................................................48 5.3.1. Xây dựng chương trình chính .....................................................................48 5.3.2. Xây dựng chương trình kiểm tra: ...............................................................49 5.4. Kiểm thử chương trình .............................................................................53 5.4.1. Nội dung kiểm thử .......................................................................................53 5.4.2. Kết quả .........................................................................................................61 CHƯƠNG 6. KẾT LUẬN .......................................................................... 63 viii CHƯƠNG 1. GIỚI THIỆU 1.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 RBAC0. 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 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. 2 CHƯƠNG 2. CÁC MÔ HÌNH ĐIỀU KHIỂN TRUY CẬP DỰ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, 3 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 sử dụng RBAC ở cấp độ ứng dụng. Trong quá khứ và cả ngày nay, các ứng dụng 4 đặc biệt đã đượ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 5 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ế. 6 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) 7 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 8 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 9 (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ó 10 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à deleteaccount (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 11 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. 12