Nguyễn Văn Thanh

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

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 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.

Mô hình dùng để mô tả cách triển khai thuật toán dựa trên AST như sau:

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)
  
• 
  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

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

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.

Каталог: jspui -> bitstream -> 123456789
123456789 -> Nguyễn Ngọc Lý Giám đốc Trung tâm Nghiên cứu về Môi trường và Cộng đồng
123456789 -> Vò Quúnh Thu Cao häc K18
123456789 -> Khoa Báo chí Đhkhxh&NV
123456789 -> Acknowledgements
123456789 -> Danh mục chữ viết tắT
123456789 -> Chương TỔng quan vật liệu mao quản trung bình (mqtb) trật tự 1 Giới thiệu chung
123456789 -> Khoa hóa họC (141 142 báo cáo)

tải về 296.99 Kb.

Chia sẻ với bạn bè của bạn: