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

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 HÀ NỘI – 2009 ii ĐẠ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 iii 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 iv 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. v Danh sách các thuật ngữ và khái niệm THUẬT NGỮ KHÁI NIỆM MAC Mandatory access control – điều khiển truy cập bắt buộc DAC Discretionary access control – điều khiển truy cập tùy quyền RBAC Role-based access control – điều khiển truy cập trên cơ sở vai trò ACL Access control list – Danh sách điều khiển truy cập Role 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í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 Quyền hạn Role Vai trò Expression Các biểu thức (Ở đây tập trung nói về các biểu thức điều kiện) vi 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++. vii 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 viii 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 1 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 2 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. 3 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, 4 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 5 đặ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 6 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ế. 7 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) 8 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 9 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 10 (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ó 11 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 12 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. 13 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}. Hình 2.2: Mô hình RBAC0 Chúng tôi mong chờ mỗi role được gán ít nhất một permission và mỗi user được gán ít nhất một role. Với mô hình này, tuy nhiên, không yêu cầu điều này. Như đã được nói ở trên, RBAC0 xử lý các permission như những ký hiệu chưa được thông dịch bởi vì bản chất rõ ràng của một permission là sự cài đặt và sự phụ thuộc hệ thống. Các permission được sửa đổi để thiết lập U, R và P và quan hệ PA và UA được gọi bởi các permission quản lý. Những điều này sẽ được thảo luận sau trong mô hình quản lý cho RBAC. Còn bây giờ thừa nhận rằng chỉ có một mình nhân viên bảo vệ có thể thay đổi những thành phần này. 14 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) 15 (b) (c) Hình 2.3: Các ví dụ của Role Hierarchies 16 (a) Role Hierarchies (b) Quản lý Role Hierarchies 17 (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 18 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 19 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ả 20 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 2.1(a). Các ràng buộc là một diện mạo quan trọng của RBAC và thỉnh thoảng tranh luận cho nguồn gốc cho sự thúc đẩy của RBAC. Một ví dụ phổ biến mà các role tháo rời qua lại lẫn nhau, giống như quản lý việc mua và quản lý tài khoản trả. Trong hầu hết các tổ chức (ngoại trừ rất nhỏ) giống như các nhân riêng lẻ sẽ không được phép để là thành viên của cả 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 21 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ụ 22 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 23 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 24 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, 25 Programmar0 và Project Supervisor có thể được khai báo loại trừ lẫn nhau. Bởi vì 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. 26 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 thành công của RBAC. Ở đây chúng tôi chỉ có thể chạm vào một vài vấn đề lớn. 27 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ý. 28 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 29 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. 30 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. 31 CHƯƠNG 3. GIỚI THIỆU CÔNG CỤ CDT TRONG ECLIPSE 3.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 32 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. 33 DOM AST có cấu trúc như sau: Hình 3.3: Giao diện DOM AST Trong phần giới thiệu về CDT sẽ không nói tất cả các thành phần của CDT chỉ tập trung vào thành phần quan trọng nhất liên quan tới thuật toán là các API và cụ thể là org.Eclipse.CDT.core.dom.AST. Đây là thành phần quan trọng nhất. Thành phần này cung cấp hầu hết các API cần sử dụng để thực hiện các bước trong thuật toán. 34 Ví dụ: IASTNode: API cung cấp cấu trúc node của mã nguồn với hai phương thức chính là getParent() và getChild() để duyệt cây. Hình 3.4: Mô tả cách duyệt cây Ngoài thành phần này có một API khác: IASTStatement (có Superinterfaces là IASTNode) cung cấp các Subinterfaces gồm các thành phần sau: IASTBreakStatement,IASTCaseStatement,IASTCompoundStatement,IASTContinu eStatement,IASTDeclarationStatement,IASTDefaultStatement,IASTDoStatement,I ASTExpressionStatement,IASTForStatement,IASTGotoStatement,IASTIfStatement ,IASTLabelStatement,IASTNullStatement,IASTProblemStatement,IASTReturnStat ement,IASTSwitchStatement,IASTWhileStatement,ICPPASTCatchHandler,ICPPA STForStatement,ICPPASTIfStatement,ICPPASTSwitchStatement,ICPPASTTryBlo ckStatement,ICPPASTWhileStatement. Để bài toán kiểm chứng được phát triển toàn diện cần quan tâm tới các Statement chứa điều kiện như IASTIfStatement, IASTWhileStatement và nhiều Statement khác. Parent Child Child Child getChild() getParent() 35 Ngoài ra, các biểu thức điều kiện cần API là IASTExpression. Nó duyệt được các biểu thức điều kiện trong các Statement để so sánh với các biểu thức điều kiện quy định sẵn (ảnh hưởng đến dữ liệu nhạy cảm) 3.4. Kết luận Nội dung trên đã trình bày về CDT – một công cụ hữu hiệu trong việc kiểm chứng các mô hình RBAC, các API được cung cấp cho bài toán kiểm chứng Trình bày về cách duyệt cây qua các phương thức được cung cấp, cách lấy ra các điều kiện trong các Statement để so sánh với điều kiện cho trước. 36 CHƯƠNG 4. BÀI TOÁN KIỂM CHỨNG 4.1. Giới thiệu: Mã nguồn của một ngôn ngữ được tổ chức dưới dạng cây. Cây được tổ chức với các node. Node tương ứng với từng thành phần trong ngôn ngữ. Có thể hình dung một cây như sau: Cây mà luôn có một node gốc (root) là node mà không có cha nào cả. Từ node gốc có thể đi đến các node con và từ một node đi lên cha của nó (cha trực tiếp) qua các phương thức tương ứng. Cụ thể, với lệnh if luôn được cấu trúc dưới dạng cây. Với 2 con tương ứng là các điều kiện và các thân của if Hình 4.1: Cấu trúc cây của ifStatement đơn giản 4.2. Khái quát thuật toán Thuật toán duyệt cây như sau: Với tổ chức của AST cần phải duyệt từ trên xuống dưới. Trong quá trình duyệt từ trên xuống nếu nhận được những hàm tác động đến mô hình RBAC hay dữ liệu nhạy cảm cần quan tâm. Ví dụ, có một đoạn mã nguồn mà ảnh hưởng trực tiếp đến dữ liệu nhạy ifStatement Expression Condition CompoundStatement 37 cảm “write (“RBAC.TXT”)” sau khi xác định được node này (thuộc loại node gì?) Sau đó, đi ngược lên trên để tìm điều kiện tương ứng. Phần này chỉ tìm hiểu một số Statement đơn giản là các Statement chứa các điều kiện liên quan đến vấn đề cần kiểm chứng. Khi xác định điều kiện cần xem node ảnh hưởng đến dữ liệu nằm trong các Statement nào? Với Statement là if cần xem xét biểu thức điều kiện của if. Nếu điều kiện của if thuộc một trong những điều kiện đã giới hạn cũng như đã quy định từ trước khi đó bắt đầu xét sâu đến Statement này. Khi kiểm chứng, nếu Statement có điều kiện thỏa mãn với yêu cầu kiểm chứng tiếp tục đi lên trên nếu không thỏa mãn in ra thông báo lỗi luôn. Sau khi đi lên trên, kiểm tra xem tiếp các Statement với các điều kiện đã quy định và cứ tiếp tục như vậy cho đến khi đi đến Statement ngoài cùng thì thôi. Thuật toán sẽ duyệt cây từ dưới lên, lấy cha của node xác định là tác động đến dữ liệu sau khi đi lên trên xác định đâu là các Statement mới khai thác chi tiết. CDT là một công cụ rất quan trọng để kiểm chứng thuật toán. Thuật toán được xây dựng dựa trên kiến trúc của AST. CDT sinh ra AST để có cái nhìn rõ ràng nhất về cấu trúc tổ chức của một mã nguồn C/C++. Trong tương lai, nếu muốn cải tiến thuật toán với công cụ khác là JDT thì tìm hiểu và sử dụng thành thạo công cụ CDT sẽ làm cho công việc dễ dàng và thuận lợi hơn nhiều. 38 Mô hình dùng để mô tả cách triển khai thuật toán dựa trên AST như sau: Hình 4.2: Mô tả thuật toán kiểm chứng cơ chế bảo mật Với mô hình này, thuật toán được triển khai dựa trên hai thành phần chính là AST và RBAC. Với một cơ chế bảo mật được xây dựng sẵn dựa trên các mô hình của RBAC, một đoạn mã nguồn đưa vào với đặc trưng các mô hình RBAC. Thuật toán được xây dựng phải làm nổi bật rõ ràng nhất những ưu điểm của các mô hình RBAC và có sự kiểm soát mã nguồn một cách chi tiết và toàn diện nhất. 4.3. Những khía cạnh liên quan 4.3.1. Khía cạnh lý thuyết Phần này sẽ đề cập tới những khía cạnh chuyên sâu hơn của thuật toán. Thuật toán đang xây dựng liên quan nhiều đến kiểm chứng cơ chế bảo mật. Do đó, vấn đề an toàn luôn được đặt lên hàng đầu, cần phải xét tất cả những gì có thể liên quan đến hệ thống dữ liệu đang cần bảo mật. Một sự tác động vào cơ chế bảo mật có thể có nhiều con đường khác nhau. Những con đường đó thường tập trung vào: - Ghi dữ liệu lên vùng cấm ghi (ví dụ: ghi thêm vào file RBAC.TXT) - Xóa những dữ liệu quan trọng (ví dụ: xóa file RBAC.TXT) 39 - Cấp phát bộ nhớ cho vùng dữ liệu được giới hạn cấp phát … Trong AST không chỉ quan tâm tới các điều kiện trong các Statement (tuy điều này là quan trọng nhất) mà phải chú ý tới các hàm có thể ảnh hưởng tới dữ liệu được liệt kê sơ bộ ở trên. Thuật toán duyệt cây ở trên đã nắm bắt được các trường hợp trong mã nguồn có thể sinh ra và người viết mã nguồn cố tình vi phạm. Để thuật toán chạy nhanh hơn thì những điều kiện không có trong quy định sẽ được chạy qua mà không cần bất cứ một sự kiểm tra nào. Đây là chỗ hổng để người viết mã nguồn với ý định xấu có thể lợi dụng. Chẳng hạn, với ifStatement nếu chỉ xét một điều kiện thì rất cực đoan nên cần xử lý với nhiều điều kiện. Do chỉ minh họa về mặt công nghệ nên bài toán đưa ra sẽ là một trường hợp rất nhỏ, cần phát triển và cải tiến hơn trong tương lai. Hình 4.3: Cấu trúc của lệnh if phức tạp Sự phức tạp trong mã nguồn có rất nhiều trường hợp. Một điều rất mâu thuẫn là phải chọn giữa tốc độ và sự an toàn. Thuật toán phải đảm bảo được cả hai tính chất này. Do 40 C/C++ là những ngôn ngữ chuyên dụng và phổ biến nên việc nghiên cứu thuận lợi hơn nhưng trong tương lai khi phát triển với Java hay C# thì thuật toán này là nền tảng quan trọng 4.3.2. Khía cạnh thực tiễn Trong thực tiễn, thuật toán cần có tính khả dụng và được triển khai trong lĩnh vực của đời sống. Ngân hàng là một ngành yêu cầu tính bảo mật và an toàn cực kỳ cao. Với đội ngũ nhân viên được phân công với các mục đích và vai trò hết sức chi tiết. Việc xây dựng mô hình RBAC0 không thể đáp ứng được đòi hỏi của ngành này. Vì thế, thuật toán phải được xây dựng trên hướng mở. Tức là, nó không chỉ mang tính chủ quan, cá thể mà phải có tính phổ biến và áp dụng cho tất cả các mô hình RBAC đã nghiên cứu. Điều này đươc thể hiện trong sự phức tạp của AST Hình vẽ dưới đây sẽ cho thấy rất rõ điều này: Hình 4.4: Thể hiện phức tạp trên AST Liên kết nhiều điều kiện Điều kiện 1 Điều kiện 2 41 4.4. Ứng dụng thuật toán 4.4.1. Khái quát về ứng dụng Những nghiên cứu của thuật toán ở phần trên cho phép hình dung cách thức thực hiện việc kiểm chứng. Để làm rõ hơn tính lý thuyết của thuật toán cần đưa thuật toán vào thực tế. Phần này xây dựng một bài toán nhỏ nhưng thể hiện đầy đủ khía cạnh mà thuật toán trên đã đề cập. Để tiến hành thuận lợi, chúng tôi lựa chọn mô hình kiểm chứng là mô hình tuy đơn giản nhất nhưng là nền tảng của hầu hết các mô hình của RBAC. 4.4.2. Mục tiêu bài toán: Mục tiêu của bài toán là xây dựng một phương pháp kiểm chứng mô hình đơn giản nhất của RBAC là RBAC0. Có một đoạn mã nguồn cho sẵn (Đoạn mã nguồn này thể hiện rõ mô hình RBAC0 với các Statement và các điều kiện được quy định từ trước) và với một file đầu vào là mô hình RBAC0 thể hiện như sau: File thể hiện mô hình RBAC0 PERMISSION USER ROLE Operate Object ThanhNV Doctor Write RBAC.TXT TanNV Patient Read RBAC.TXT ThangLC Nurse Remove RBAC.TXT Chúng tôi sẽ kiểm chứng đoạn mã đã cho sẵn có điều kiện nào trái với mô hình này không? Với các “dữ liệu nhạy cảm” thì một người với không có quyền hạn có thể thực 42 hiện được không? Ví dụ như “write (“RBAC.TXT”)”. Đây là một ví dụ đơn giản, nó sẽ được mở rộng trong một ứng dụng cụ thể trong thực tế (chẳng hạn Y tế …) 4.4.3. Yêu cầu bài toán: Bài toán phải được xây dựng đáp ứng các yêu cầu sau: - Phải kiểm soát được mã nguồn và các biểu thức điều kiện rõ ràng. - Phải thể hiện đặc trưng của mô hình RBAC0 - Phải có output rõ ràng bắt được các lỗi và cấu trúc chương trình rõ ràng. 4.4.4. Phân tích bài toán Bài toán đang nghiên cứu là một trường hợp trong bài toán lớn. Trên thực tế có thể mở rộng bài toán cho các lĩnh vực nhất định để kiểm soát được sự truy cập của từng người với chức quyền khác nhau vào các dữ liệu quan trọng. Bài toán không chỉ dừng lại ở việc kiểm chứng mô hình RBAC0, mà cao hơn nữa có thể xây dựng để kiểm chứng các mô hình cấp cao hơn để có thể ứng dụng trong những lĩnh vực mà có yêu cầu về sự bảo mật cũng như phân công vai trò nhiệm vụ quan trọng hơn. Việc xây dựng bài toán kiểm chứng các mô hình RBAC dựa trên AST để thực hiện việc kiểm soát những đoạn mã nguồn mà có thể từ dó dẫn đến sự rò rỉ thông tin cũng như đe dọa tới hệ thống các dữ liệu. Với người bình thường thì ảnh hưởng rất hạn chế nhưng với các cơ quan chính phủ hay các lĩnh vực yêu cầu sự bảo mật rất cao như Ngân hàng, Quân sự … thì bài toán xây dựng thực sự hữu ích. Với chỉ một đoạn mã sai không có sự kiểm chứng có thể biến một người dùng bình thường trở thành người kiểm soát hệ thống và làm thay đổi mục đích sử dụng của hệ thống. 43 Hình 4.4: Lỗi thể hiện trong đoạn mã Có rất nhiều điểm mà người viết mã nguồn có thể lợi dụng để chèn những đoạn mã “độc” vào mà khó có thể kiểm soát được. 4.5. Kết luận Chương này đã trình bày bài toán kiểm chứng dựa trên AST gồm các phần sau. Giới thiệu cấu trúc một mã nguồn được tổ chức dưới dạng cây như thế nào? Sâu đó khái quát thuật toán sẽ được triển khai. Bằng việc nhìn được cấu trúc mã nguồn qua cây Error 44 cú pháp trừu tượng – AST , nội dung của chương tập trung vào việc phân tích thuật toán duyệt cây. Không chỉ khái quát hóa thuật toán mà còn đưa ra được những khía cạnh khác liên quan sâu hơn đến thuật toán cả về mặt lý thuyết lẫn thực tiễn để có một cái nhìn sâu hơn và toàn diện hơn về thuật toán đang xây dựng. Chúng tôi đã đưa ra ứng dụng của thuật toán trong một bài toán cụ thể. Cách tiếp cận này thuật toán được nhìn nhận trực quan hơn và cụ thể hơn. Với bài toán được xây dựng đáp ứng đầy đủ những gì mà thuật toán muốn đạt được trong thực tiễn. Trong tương lai, thuật toán được mở rộng với nhiều ngôn ngữ hơn và nhiều dạng mã nguồn hơn. 45 CHƯƠNG 5. THỰC NGHIỆM Trong chương này sẽ xây dựng ứng dụng cụ thể với bài toán được phân tích ở trên gồm có việc cài đặt, xây dựng và triển khai của bài toán. 5.1. Phạm vi ứng dụng Trong khóa luận, chỉ đưa ra một ứng dụng nhỏ để thể hiện được mặt công nghệ của bài toán kiểm chứng. Ứng dụng được chia làm các nhiệm vụ chính sau: - Xây dựng đoạn mã ví dụ để kiểm chứng với một file chứa mô hình của RBAC0. - Xây dựng chương trình thể hiện thuật toán kiểm chứng trên môi trường Eclipse (Với plug-in là công cụ CDT) 5.2. Thiết kế ứng dụng Cài đặt chương trình: Bài toán được xây dựng dựa trên ngôn ngữ Java (Ngôn ngữ độc lập nền), vì thế sau khi xây dựng có thể triển khai trên môi trường Window, Linux, Unix … Để xây dựng và triển khai bài toán ta cần một số chương trình sau: Cài đặt môi trường chạy cho Java: Cài đặt JDK-1.6 và thiết lập biến môi trường JAVA_HOME: “C:\Program Files\Java\jdk1.6.0\bin”. Cài đặt bộ biên dịch C/C++: MinGW Download MinGW sau đó cài đặt tự động vào C:\MinGW Cài đặt Eclipse: dùng Eclipse (GADIMEDE) Cài đặt công cụ CDT: dùng công cụ CDT 6.0 46 Sau khi cài đặt thành công các thành phần trên sẽ có kết quả với StartPage của Eclipse như sau: Hình 5.1: Giao diện StartPage sau khi cài CDT Với quá trình cài đặt thêm công cụ CDT vào Eclipse sẽ có một công cụ để phát triển với C/C++. Đặt biệt sau khi cài đặt thành công công cụ này có thêm thành phần DOM AST là thành phần quan trọng nhất của khóa luận. 47 Cấu trúc của thành phần DOM AST như sau: Hình 5.2: Cấu trúc DOM AST DOM AST AST Chọn node Mã nguồn 48 5.3. Xây dựng và triển khai bài toán 5.3.1. Xây dựng chương trình chính Chương trình chính viết trên Eclipse với ngôn ngữ Java. Do đây là bài toán rất nhỏ nên chỉ thao tác với hai file chính trong Project VisitorAST:  “FindAExpressionVisitor.Java” (Thực hiện việc visitor các Expression trong mã nguồn)  “GetProject.Java” (Thực hiện hầu hết các thao tác xử lý và chạy chương trình). Để thực hiện được thuật toán cần phải thực hiện rất nhiều bước. Bước 1: Xác định được Project cần kiểm tra. Sau đó, mới bắt đầu thực hiện việc xử lý với Project đó Bước 2: Duyệt một node trong các thành phần của cây. Với công cụ CDT, Eclipse cung cấp một thành phần là DOM AST nhưng vấn đề quan trọng là phải nắm bắt được và thực hiện được việc duyệt được AST. Công cụ này cung cấp rất nhiều API để có thể thực hiện việc duyệt cây này. Ví dụ để duyệt các Expression : shouldVisitExpressions = true ; và hàm override hàm visit của nó @Override public int visit(IASTExpression myExpression) Tất cả những công việc này chúng tôi sẽ triển khai ở một file chứa class riêng để thực hiện. Công việc thực hiện ở file “GetProject.Java” chỉ là gọi các đối tượng của class này và thực hiện câu lệnh accept để bắt đầu tiến hành duyệt các Expression từ trên xuống trong file mã nguồn. 49 Bước 3: Thực hiện so sánh các Expression này với các Expression của các Statement đang xét (ví dụ: ifStatement, whileStatement …). Vì có nhiều Statement cần xét nên cần xây dựng một phương thức thể hiện tính đa hình của ngôn ngữ lập trình hướng đối tượng. checkRBAC(ExpressionFunction, object, functionCall) Phương thức này xử lý các trường hợp của Statement và cho kết quả là true hay false. Kết quả trả về này rất quan trọng trong quá trình kiểm tra các điều kiện của mã nguồn tương ứng với các mô hình RBAC0. Để hiển thị được kết quả sau khi kiểm tra có phương thức: treatFunction(functionName, functionCall) Phương thức này sẽ hiển thị các dòng thông báo sau khi kiểm tra thông báo lỗi cũng thấy rất rõ kết quả. 5.3.2. Xây dựng chương trình kiểm tra: Chương trình kiểm tra khá đơn giản là một Project C/C++ tên RBACTest chứa file RBACTest.CPP. File này có nhiệm vụ xây dựng một chương trình thể hiện được mô hình RBAC0 với các biểu thức điều kiện và các hàm tác động đến “dữ liệu nhạy cảm” như đã quy định sẵn trong chương trình chính. Với mục đích chỉ thể hiện về mặt công nghệ nên mã nguồn được xây dựng trước (hard-code) nếu để phát triển lên một cấp cao hơn trong tương lai phải thực hiện với những đoạn mã nguồn không được quy định sẵn và được phát triển với hầu hết các mã nguồn đưa vào. Bắt đầu duyệt 50 Chương trình kiểm tra nhất thiết phải là “runtime-EclipseApplication” để có thể chạy được chương trình. Với đầu vào là Project RBACTest. Giao diện của chương trình Test như sau: Hình 5.3: Giao diện chương trình Test Chạy chương trình Test 51 Với giao diện này khi chạy, sẽ có kết quả hiển thị ở màn hình console của chương trình chính. Khi chạy thành công sẽ hiển thị thông báo như sau: Hình 5.4: Giao diện khi chạy Test thành công 52 Và kết quả nhận được ở chương trình chính như sau: Hình 5.5: Giao diện kết quả 53 5.4. Kiểm thử chương trình 5.4.1. Nội dung kiểm thử Chương trình sẽ chạy thử với các yêu cầu kiểm tra khác nhau. Với input (đầu vào): một file RBAC.TXT được cấu trúc theo mô hình RBAC0. File RBAC.TXT có dạng như sau: User Role Permission ThanhNV Root Write (“RBAC.TXT”) TanNV User Read (“PUBLIC.TXT”) TrungND User Write (“DB.TXT”) HungNT Root Remove (“RBAC.TXT”) Và mã nguồn C/C++ được viết theo mô hình mà file RBAC.TXT đã cung cấp. Mã nguồn cụ thể hóa vấn đề role là root sẽ có permission Write (“RBAC.TXT”) và điều cần làm là đối chiếu với file RBAC.TXT (như trên) để đưa ra output (đầu ra) để so sánh với output mong muốn đạt được. 54 1. Với biểu thức điều kiện đơn:  Trường hợp lệnh write: Nếu nhập role là user và có quyền Write (“RBAC.TXT”) thì output mong muốn là lỗi. Và có thông báo lỗi cụ thể. Hình 5.6(a): kiểm tra với lệnh write(có lỗi) Dữ liệu nhập vào Output mong muốn: Có lỗi Output chương trình So sánh 55 Còn nếu role là root mà permission là write (“RBAC.TXT”) thì không có lỗi xảy ra và output mong muốn là OK. Hình 5.6(b) : kiểm tra với lệnh write ( không có lỗi) Dữ liệu nhập vào Output mong muốn: Thỏa mãn Output chương trình So sánh 56  Trường hợp với lệnh remove: đây là xóa dữ liệu, việc Test cũng như với lệnh write. Với mong muốn output là OK. Hình 5.6(c) : kiểm tra với lệnh remove( không có lỗi) Dữ liệu nhập vào Output mong muốn: Thỏa mãn Output chương trình So sánh 57 Với mong muốn output là có lỗi: Hình 5.6(d) : kiểm tra với lệnh remove(có lỗi) Dữ liệu nhập vào Output mong muốn: Có thông báo lỗi Output chương So sánh 58 2. Với biểu thức điều kiện lồng nhau:  Trường hợp lệnh write: output mong muốn là lỗi. Hình 5.7(a): kiểm tra với lệnh write(có lỗi) Dữ liệu nhập vào Output mong muốn: Có lỗi Output chương So sánh 59 Nếu output mong muốn là OK. Hình 5.7(b) : kiểm tra với lệnh write ( không có lỗi)  Trường hợp với lệnh remove: đây là lệnh xóa dữ liệu, việc Test cũng như với lệnh write. Dữ liệu nhập vào Output mong muốn: Thỏa mãn Output chương trình So sánh 60 Với mong muốn output là OK. Hình 5.7(c) : kiểm tra với lệnh remove( không có lỗi) Dữ liệu nhập vào Output mong muốn: Thỏa mãn Output chương trình So sánh 61 Với mong muốn output là có lỗi: Hình 5.7(d) : kiểm tra chương trình với lệnh remove(có lỗi) 5.4.2. Kết quả Chương trình đã chạy thử và cho kết quả tốt. Khi Test với nhiều input khác nhau, chương trình đã chạy đúng và cho ra output đúng theo thuật toán. Chương trình đã Test tất cả các trường hợp được mô hình RBAC0 mô tả gồm: 1. Trường hợp chỉ có một biểu thức điều kiện trực tiếp. 2. Trường hợp có nhiều biểu thức điều kiện lồng nhau. 3. Test với các lệnh ảnh hưởng trực tiếp đến hệ thống gồm write, remove … Tuy nhiên, nhược điểm lớn nhất của chương trình là giao diện chưa thân thiện. Kết quả chủ yếu chạy trên màn hình console. Dữ liệu nhập vào Output mong muốn: Có lỗi Output chương trình So sánh 62 Tuy đáp ứng được về mặt thuật toán nhưng chương trình cũng mới dừng lại ở việc “hard-code” và kiểm chứng với mô hình RBAC0 chưa mở rộng với các mô hình phức tạp hơn. 63 CHƯƠNG 6. KẾT LUẬN “Kiểm chứng cơ chế bảo mật dựa trên AST” là đề tài nghiên cứu mới. Đã có rất nhiều cơ chế bảo mật được phát triển với những ưu điểm và nhược điểm riêng. Trong các cơ chế bảo mật đáng quan tâm thì nổi bật nhất là RBAC (điều khiển truy cập dựa trên vai trò). RBAC là một mô hình điều khiển truy cập tối ưu, có thể quản lý người dùng và truy cập của họ một cách khoa học nhằm hạn chế tối đa những xâm phạm bất hợp pháp vào tài nguyên của hệ thống. Dựa trên các mô hình của RBAC, cụ thể là RBAC0 đề tài đã xây dựng bài toán kiểm chứng dựa trên cây cú pháp trừu tượng (AST). Sau khi hoàn thành, khóa luận đã đạt được những kết quả sau đây: 1. Đã tìm hiểu chi tiết về các mô hình điều khiển truy cập, đánh giá được điểm mạnh và điểm hạn chế và những ứng dụng cụ thể của từng mô hình, đưa ra ứng dụng của từng mô hình trong thực tiễn. 2. Đã tìm hiểu chuyên sâu về họ các mô hình điều khiển truy cập trên cơ sở vai trò (RBAC), phân tích chi tiết từng mô hình của RBAC và nhấn mạnh vào mô hình nền tảng RBAC0. 3. Đã tìm hiểu bài toán kiểm chứng. Xây dựng mô hình duyệt cây cú pháp trừu tượng (AST), đưa ra thuật toán kiểm chứng hoàn thiện cho các mô hình của RBAC, đưa ra bài toán nhỏ để kiểm chứng mô hình RBAC0. 4. Hoàn thành việc cài đặt và triển khai bài toán trên Eclipse tích hợp công cụ CDT. Đã đưa ra kết quả chạy chương trình hoàn toàn khớp với kết quả mong muốn, chương trình chạy ổn định khớp với thuật toán cả về mặt lý thuyết lẫn thực tiễn. 64 Tuy nhiên do hạn chế về mặt thời gian nghiên cứu, khóa luận khó tránh khỏi những khiếm khuyết kể cả về mặt lý thuyết lẫn việc phân tích và thiết kế công cụ hỗ trợ. Những mặt hạn chế này bao gồm: 1. Mới chỉ tìm hiểu ở mức độ cơ bản bài toán kiểm chứng. Dừng lại ở kiểm chứng mô hình RBAC0 và với mã nguồn C/C++. 2. Vẫn còn “hard-code”, bài toán chưa mở rộng cho nhiều ngôn ngữ và các trường hợp Test chưa nhiều. 3. Giao diện chạy chương trình còn đơn giản, chỉ là console. Chưa tạo giao diện input và output chuyên nghiệp. Trong tương lai, chúng tôi sẽ tiếp tục mở rộng đề tài này theo hướng nghiên cứu chuyên sâu về thuật toán để kiểm chứng với nhiều ngôn ngữ, mở rộng với nhiều mô hình RBAC hơn, không chỉ dừng lại ở RBAC0, tránh tối đa việc “hard-code”. Chương trình sẽ có giao diện chuyên nghiệp hơn và các chức năng sẽ thân thiện hơn với người sử dụng để ứng dụng thực tế trong lĩnh vực cụ thể. 65 Tài liệu tham khảo [1] David F. Ferraiolo, Dennis M. Gilbert, and Nickilyn Lynch. An examination of federal and commercial access control policy needs. In NIST-NCSC National Computer Security Conference, pages 107{116, Baltimore, MD, September 20-23 1993. [2] Common Criteria Editorial Board. Common Criteria for Information Technology Security Evaluation, December 1994. Version 0.9, Preliminary Draft. [3] Imtiaz Mohammed and David M. Dilts. Design for dynamic user-role-based security. [4] Roshan Thomas and Ravi S. Sandhu. Conceptual foundations for a model of task based authorizations. In IEEE Computer Security Foundations Workshop 7. [5] Ravi S. Sandhu. Lattice-based access control models. IEEE Computer, 26(11):9{19, November 1993. [6] Dirk Jonscher. Extending access controls with duties|realized by active mecha- nisms. In B. Thuraisingham and C.E. Landwehr, editors, Database Security VI: Status and Prospects. [7] David Ferraiolo and Richard Kuhn. Role-based access controls. In 15th NIST-NCSC National Computer Security Conference. [8] M.-Y. Hu, S.A. Demurjian, and T.C. Ting. User-role based security in the ADAM object-oriented design and analyses environment. In J. Biskup, M. Morgernstern, and C. Landwehr, editors, Database Security VIII: Status and Prospects. North-Holland, 1995. [9] Matunda Nyanchama and Sylvia Osborn. Access rights administration in role-based security systems. In J. Biskup, M. Morgernstern, and C. Landwehr, editors, Database Security VIII: Status and Prospects. North-Holland, 1995. 66 [10] S. H. von Solms and Isak van der Merwe. The management of computer security profiles using a role-oriented approach. [11] ISO/IEC 10040. Information Technology Open Systems Interconnection { Systems Management Overview. [12] Ravi S. Sandhu. The typed access matrix model. In Proceedings IEEE Com- puter Society Symposium on Research in Security and Privacy. [13] Jonathan D. Mo_ett and Morris S. Sloman. Delegation of authority. In I. Krishnan and W. Zimmer, editors, Integrated Network Management II. [14] Eduardo B. Fernandez, Jie Wu, and Minjie H. Fernandez. User group structures in object-oriented database authorization. In J. Biskup, M. Morgernstern, and C. Landwehr, editors, Database Security VIII: Status and Prospects. North-Holland, 1995. 67 Phụ lục A1: Cài đặt Công cụ CDT 1. Khởi động Eclipse (GANYMEDE): vào Help chọn Software Updates Sẽ hiện ra giao diện sau : Ta chọn Add Site như trên thể hiện sẽ đến giao diện sau: Nhấn nút này 68 Chọn Archive… để đến được vị trí của file CDT-mASTer-6.0.0- I200902031437.zip file này có thể download trên mạng theo địa chỉ: ông cụs/CDT/builds/6.0.0/I.I200902031437/index.html Đến các bước tiếp theo cứ thực hiện như cài đặt một chương trình phần mềm bình thường. 2. Cài đặt MinGW Chỉ cần download file MinGW-5.1.4.exe và tiến hành cài đặt là được Download ở trang: Giao diện khi cài đặt các bước lần lượt như sau: Nhấn vào đây 69 Nhấn vào đây Nhấn vào đây 70 71 Phụ lục A2: Cấu hình các file để chạy chương trình Test trên C/C++ 1. Thêm vào các thư viện liên quan Cấu hình trong file MANIFEST.MF Giao diện tiếp theo khi chọn để cấu hình: File này Chọn phần này 72 2. Cấu hình lại các Plug-in Nội dung file plugin.xml phải như sau: <extension point="org.eclipse.ui.actionSets"> <actionSet label="VisitorCPPAST" Thêm các thành phần 73 visible="true" id="VisitorCPPAST.actionSet"> <menu label="Sample &Menu" id="sampleMenu"> <separator name="sampleGroup"> <action label="&Sample Action" icon="icons/tree.gif" class="visitorcppAST.actions.GetProject" công cụtip="Visitor" menubarPath="sampleMenu/sampleGroup" công cụbarPath="sampleGroup" id="visitorcppAST.actions.GetProject">