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
USER ROLE PERMISSION
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 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.
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 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.
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)
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.
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
5.3. Xây dựng và triển khai bài toán5.3.1. Xây dựng chương trình chính 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
publicint 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.
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.
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
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:
Và kết quả nhận được ở chương trình chính như sau:
5.4. Kiểm thử chương trình5.4.1. Nội dung kiểm thử 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ó permissionWrite (“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.
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
Output mong muốn:
Có lỗi
Output chương trình So sánh
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
Output mong muốn:
Thỏa mãn
Output chương trình So sánh
• 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
Output mong muốn:
Thỏa mãn
Output chương trình So sánh
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
Output mong muốn:
Có thông báo lỗi
Output chương
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
Output mong muốn:
Có lỗi
Output chương So sánh
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
Output mong muốn:
Thỏa mãn
Output chương trình So sánh
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
Output mong muốn:
Thỏa mãn
Output chương trình So sánh
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
Output mong muốn:
Có lỗi
Output chương trình So sánh
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.
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.
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ể.
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.
[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