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)
- 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
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
4.4. Ứng dụng thuật toán4.4.1. Khái quát về ứng dụng 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