phân tích tự động thuộc tính bảo mật cho mô hình điều khiển truy xuất dựa trên thuộc tính

- Nghiên cứu và đề xuất một giải pháp để phân tích thuộc tính bảo mật cho mô hình điều khiển truy xuất dựa trên thuộc tính, xây dựng các giải thuật nhằm giảm thời gian thực thi.. TÓM TẮT

TỔNG QUAN

CÁC CÔNG TRÌNH LIÊN QUAN

Năm 2018, Shamik Sural và các cộng sự công bố công trình nghiên cứu về phân tích bảo mật cho mô hình quản trị của mô hình ABAC trong bài báo “Security Analysis of ABAC under an Administrative Model”[7] Bài báo này nghiên cứu trên mô hình quản trị AMABAC (Administrative Model for ABAC) Tuy nhiên, nghiên cứu này dựa trên một tập người dùng giới hạn Vấn đề bùng nổ trạng thái chưa được đề cập đến trong nghiên cứu.

CÁC KIẾN THỨC NỀN TẢNG

2.1 Mô hình điều khiển truy cập Điều khiển truy cập [10] là quá trình xác minh quyền truy cập hạn chế vào tài nguyên hệ thống Quá trình điều khiển truy cập là quá trình quyết định xem một người dùng nào đó có được phép xem, sửa hay xóa một tài nguyên nào đó trong hệ thống hay không Vấn đề bảo vệ tài nguyên hệ thống khỏi tin tặc hoặc những người dùng cơ hội muốn lấy đi những thông tin quan trọng của hệ thống là vấn đề cực kỳ quan trọng trong lĩnh vực an ninh đối với các hệ thống máy tính

Từ nhu cầu bảo vệ tài nguyên của hệ thống máy tính mà hàng loạt các mô hình điều khiển truy cập ra đời và phát triển Những mô hình điều khiển truy cập sớm nhất xuất hiện là mô hình điều khiển truy cập tùy quyền (Discretionary Access Control [11]) và mô hình điều khiển truy cập bắt buộc (Mandatory Access Control [12]) xuất hiện vào đầu những năm 1970 Cả hai mô hình điều khiển truy cập tùy quyền và điều khiển truy cập bắt buộc đều xuất hiện những điểm yếu cố hữu sau một thời gian được ứng dụng trong thực tế Các tin tặc có thể tận dụng được những điểm yếu cố hữu này để tấn công các hệ thống sử dụng mô hình điều khiển truy cập tùy quyền và mô hình điều khiển truy cập bắt buộc Do vậy, mô hình điều khiển truy cập dựa trên vai trò (Role - based access control [13] [14]) xuất hiện và thay thế các mô hình điều khiển truy cập tùy quyền và bắt buộc Tuy nhiên các hệ thống máy tính càng ngày càng có xu hướng mở rộng với số lượng người dùng ngày càng lớn, số lượng các chính sách bảo mật và sự phức tạp ngày càng tăng Do vậy, các nghiên cứu gần đây có xu hướng tìm kiếm một mô hình mới thay thế cho mô hình điều khiển truy cập dựa trên vai trò Do đó, mô hình điều khiển truy cập dựa trên thuộc tính ra đời, với tính linh hoạt và khả năng mở rộng cao, mô hình điều khiển truy cập dựa trên thuộc tính nổi lên như một mô hình điều khiển truy xuất thay thế cho mô hình điều khiển truy xuất dựa trên vai trò trong tương lai gần

2.2 Mô hình điều khiển truy cập dựa trên vai trò (RBAC)

Mô hình điều khiển truy cập dựa trên vai trò lần đầu tiên được giới thiệu bởi D Richard Kuhn và David Ferraiolo vào năm 1992 [4] Sau đó mô hình RBAC được phát triển bởi R Sandhu và các cộng sự vào năm 1996 [5] Đến năm 2000, Sandhu, Ferraiolo, và Kuhn đã đề xuất một tiêu chuẩn thống nhất cho mô hình RBAC [6] Năm

2004, tiêu chuẩn đã được thông qua với tên gọi INCITS 359-2004 bởi Viện Tiêu Chuẩn và Kỹ Thuật Quốc Gia Hoa Kỳ (NIST)

Các hệ thống điều khiển truy xuất dựa trên vai trò kiến tạo vai trò (role) để đảm nhận các công việc khác nhau Đồng thời các vai trò gắn liền với các quyền hạn nhất định của người dùng trong hệ thống Vì người dùng được cấp quyền một cách gián tiếp thông qua các vai trò, nên việc quản lý hệ thống trở nên đơn giản hơn Mô hình RBAC gồm 2 thành phần chính: User to role assignment (UA) và Role to permission assignment (PA) UA quản lý việc gắn các vai trò cho người dùng trong khi PA quản lý việc gán quyền cho vai trò Sau đây là ví dụ về UA và PA

Khi hệ thống kiểm soát truy cập dựa trên vai trò (RBAC) trở nên phức tạp hơn do số lượng người dùng và vai trò tăng lên, các ràng buộc liên quan cũng trở nên phức tạp Một người dùng có thể nắm giữ nhiều vai trò cùng lúc và tùy thuộc vào bối cảnh cụ thể, họ có thể kích hoạt các vai trò khác nhau Do đó, một số mô hình RBAC nâng cao đã đưa ra các ràng buộc bổ sung như ngữ cảnh không gian và thời gian để đáp ứng nhu cầu của các hệ thống ngày càng phức tạp.

2.3 Mô hình điều khiển truy cập dựa trên thuộc tính (ABAC)

Do những hạn chế của mô hình RBAC mô ABAC được ra đời và phát triển theo rất nhiều hướng khác nhau rất nhiều mô hình đã được giới thiệu, trong đó mô hình ABACα [3] được giới thiệu năm 2012 bởi Ravi Sandhu và các đồng nghiệp trở thành mô hình cơ sở phát triển cho các mô hình ABAC khác Trong mô hình ABAC, quyền truy cập được được cấp cho người dùng thông qua việc sử dụng các chính sách kết hợp các thuộc tính với nhau Hệ thống phân bổ thuộc tính cho người dùng dựa trên vai trò, nhiệm vụ và đặc điểm riêng của người dùng Hệ thống đồng thời quản lý quyền truy cập dựa trên các chính sách kết hợp các thuộc tính Một người dùng cần phải sở hữu một tập hữu hạn các thuộc tính để có thể thực hiện các truy cập mong muốn Trong mô hình ABACα, người dùng thực hiện các quyền truy cập này gián tiếp thông qua các chủ thể (subject) Các thành phần cơ bản của mô hình ABAC được thể hiện trong hình sau

Figure 2 1 Cấu trúc mô hình ABAC [3]

Trong đó U,S,O lần lượt tương ứng với tập người dùng, chủ thể và đối tượng

UA, SA, OA lần lượt biểu thị tập thuộc tính của người dùng, chủ thể và đối tượng.

MÔ HÌNH HGABAC VÀ MÔ HÌNH GURA G

MÔ HÌNH HGABAC

Năm 2014, Sylvia L Osborn và các đồng sự đã giới thiệu mô hình phân cấp nhóm và điều khiển truy cập dựa trên thuộc tính (HGABAC) [2] Mô hình HGABAC được phát triển từ mô hình ABACα Mô hình HGABAC cải thiện được nhiều nhược điểm của mô hình ABACα trước đây và có thể sớm được triển khai trên thực tế

1.1 Mô tả mô hình HGABAC

Trong HGABAC, các thực thể người dùng (user), đối tượng (object) và chủ thể (subject) tương tác: người dùng truy cập đối tượng gián tiếp qua chủ thể Chủ thể, do người dùng tạo, sở hữu thuộc tính của người dùng nhưng có thể thay đổi theo thời gian (luôn thấp hơn tập thuộc tính của người dùng tạo) Họ chia sẻ tập thuộc tính tối đa, trong khi đối tượng có tập riêng Hoạt động (operation) là truy cập hệ thống (đọc, ghi) do chủ thể thực hiện lên đối tượng Thuộc tính bao gồm tập các giá trị.

Mô hình HGABAC được tổ chức theo hệ thống phân cấp các nhóm, bao gồm nhóm người dùng, chủ thể và đối tượng Các cá thể này thừa hưởng các thuộc tính từ nhóm mà họ thuộc về, bên cạnh các thuộc tính riêng Thay vì điều chỉnh thuộc tính cho từng cá nhân, quản trị viên có thể thay đổi thuộc tính cấp nhóm, qua đó giảm đáng kể các tác vụ quản lý bằng cách thay đổi thuộc tính cho nhóm thay vì từng người dùng riêng lẻ.

Nhằm đơn giản hóa mô hình HGABAC để dễ dàng hơn trong quá trình phân tích Tôi tạm thời bỏ qua nhóm và hệ thống phân cấp nhóm trong mô hình HGABAC

1.2 Công thức HGABAC thay thế

Trong phần này, tôi sẽ trình bày những công thức của mô hình HGABAC, những công thức này bao gồm những công thức được đề xuất bởi Maanak Gupta và Ravi Sandhu và một số những được thay thế điều chỉnh Những công thức thay thế này được biến đổi hoặc đơn giản hóa từ những công thức gốc để phù hợp hơn với nghiên cứu của tôi Những công thức thay thế này không làm thay đổi bản chất của mô hình HGABAC

Figure 3.1 Mô hình khái niệm của HGABAC [1]

UA, OA (một tập hợp hữu hạn các thuộc tính người dùng và thuộc tính đối tượng tương ứng)

Mô hình khái niệm HGABAC được minh họa trong Hình 1 U là tập người dùng,

S là tập chủ thể, O là tập đối tượng, OP là tập hành động quản trị UG, OG lần lượt là tập nhóm người dùng và nhóm đối tượng UA, OA là tập hợp hữu hạn các thuộc tính người dùng và thuộc tính đối tượng

Gọi Au, Ao, lần lượt là tập hữu hạn các thuộc tính của người dùng, thuộc tính của đối tượng Ta có UA ⊆ U × Au và OA ⊆ O × Ao

Hàm ủy quyền (Authorization Function) [2] Đối với mỗi op ∈ OP, hàm ủy quyền Authorizationop (s: S, o: O) trả về true hoặc false được định nghĩa bằng cú pháp ABNF như sau:

Au_func = exp [ bool_op Au_func]

/ exp exp = term op term

/ [ “NOT” ] “(”Au_func “)” term = const / att_name bool_var = boolean / att_name op = “>” / “=” / “ 18

Authorizationwrite(s:S, o:O) = user.UserType ∈ object.ReaderType ˄ user.Id ∈ {1,3,5,7} ˄ user.Location = object.Location ˄ user.Faculty ∈ {Medical, Physical}

Ví dụ, hãy xem xét một hệ thống HGABAC gồm các thành phần như sau:

UserType ={student, teacher, tutor assistant};

Location = {Paris, New York, London}; and

ReaderType = {student, teacher} and Location = {Paris, New York}

Mô hình HGABAC với UA và OA như sau:

Alice Student Paris Chemistry Bob Teacher New York Medical Shan Tutor assistant

Authorizationread(s:S, o1:O) ≡ user.UserType ∈ object.ReaderType ˄ user.Location = object.Location

Quy trình yêu cầu truy cập của người dùng u tới đối tượng o1 được minh họa trong Hình 2 Theo đó, nếu người dùng u có loại là ReaderType và cùng vị trí với đối tượng o1, thì người dùng này có quyền đọc đối tượng o1.

Figure 3.2 Ví dụ về quá trình yêu cầu truy cập

Chủ thể s được phép truy cập đối tượng o nếu và chỉ khi Authorization(s, o) được đánh giá là đúng Vì chủ thể luôn có thể nhận thuộc tính từ người dùng hoặc toàn bộ thuộc tính của người dùng, do đó trong phần sau, tôi sẽ chỉ phân tích thuộc tính của người dùng mà không phân tích thuộc tính của từng chủ thể Chúng tôi giả định nếu người dùng có đủ thuộc tính để thực hiện hành động quản trị trên đối tượng, thì người dùng đó cũng có thể tạo một chủ thể đủ điều kiện để thực hiện một hành động trên đối tượng (tức là tập chủ thể giống với tập người dùng).

MÔ HÌNH GURA G

Trong phần này, tôi đề xuất một mô hình quản trị thay thế của mô hình HGABAC Mô hình thay thế này dựa trên mô hình quản trị chỉ định thuộc tính người dùng và nhóm GURAG (Administrative Model for User and Group Attribute Assignment)[1] do Maanak Gupta và Ravi Sandhu đề xuất Mô hình quản trị thay thế này dựa trên mô hình GURAG được đơn giản hóa và được chỉnh sửa để phù hợp với công việc của luận văn Mô hình quản trị GURAG có 3 mô hình con: Mô hình con quản lý thuộc tính người dùng (user attribute assignment) UAA, mô hình con quản lý thuộc tính cho nhóm (user-group attribute assignment) UGAA, mô hình con quản lý người dùng cho nhóm (user to user-group assignment) UGA

Mô hình con UAA có nhiệm vụ quản lý thuộc tính người dùng (thêm hoặc xóa giá trị thuộc tính cho người dùng) Mô hình con UGAA có nhiệm vụ quản lý nhóm cho người dùng (thêm và xóa các thuộc tính cho nhóm của người dùng) Mô hình con UGA kiểm soát việc chỉ định người dùng vào các nhóm người dùng, cũng như việc xóa người dùng khỏi các nhóm người dùng Do việc tạm thời không phân tích thành phần

“nhóm” trong mô hình HGABAC nên mô hình con UGAA và mô hình con UGA có liên quan đến việc quản lý nhóm cũng sẽ tạm thời không được phân tích

Mô hình quản lý thuộc tính người dùng (user attribute assignment UAA) thay thế được sử dụng trong nghiên cứu của luận văn này Đây là mô hình được xây dựng dựa trên mô hình con UAA của GURAG Trong phần này, mô hình UAA sẽ được chỉnh sửa một số công thức và điều chỉnh đề phù hợp hơn với luận văn, tuy nhiên về bản chất của thì không hề thay đổi so với mô hình UAA ban đầu

Can_add_att/Can_delete_att({admin_role_set}, {user_attribute_set},)

{ target_attribute_set }) là hành động quản trị thêm, xóa giá trị thuộc tính của mô hình UAA Trong đó admin_role_set là vai trò (role) của admin, do mô hình GURAG sử dụng mô hình RBAC để quản lý admin nên admin trong hệ thống có một tập vai trò Trong mô hình ABAC chúng ta có thể coi vai trò như là thuộc tính Vì vậy, để đơn giản hóa chúng ta coi admin cũng là người dùng sở hữu các thuộc tính và vai trò cũng được coi là một thuộc tính điều này có thể giúp chúng ta mở rộng mô hình GURAG một cách dễ dàng và linh hoạt trong tương lai

Admin_role_set là tập điều kiện của admin, user_attribute_set là tập điều kiện của người dùng và attribute_target là giá trị thuộc tính mà hành động quản trị muốn thêm hoặc xóa trên tập thuộc tính của người dùng Điều kiện 1: Khi trong hệ thống tồn tại một admin thỏa mãn tập điều kiện trong admin_role_set thì điều kiện đầu tiên của hành động đã thỏa mãn Điều kiện 2: là điều kiện của người dùng Nếu có một người dùng trong hệ thống có tập thuộc tính thỏa mãn user_attribute_set thì admin thỏa điều kiện một hoàn toàn có thể thêm hoặc xóa attribute_target cho người dùng

Trong ví dụ đầu tiên ở trên, điều kiện một thỏa khi trong hệ thống tồn tại một admin a có giá trị thuộc tính là deptAdmin Điều kiện 2 thỏa khi trong hệ thống tồn tại một người dùng u có graduated ∈ effectivestudType(u) khi đó deptAdmin có thể gán giá trị thuộc tính TA cho thuộc tính UserType của người dùng u.

HIỆN THỰC

HIỆN THỰC MODEL CHECKING

1.1 Phân tích mô hình GURA G

Mục tiêu của phân tích là phát hiện lỗ hổng bảo mật, nghĩa là sau một số hành động quản trị, có thể xuất hiện người dùng có quyền truy cập tài nguyên nhạy cảm, gây nguy hiểm cho hệ thống Khi đó hệ thống được gọi là không an toàn Tài nguyên nhạy cảm chỉ có thể truy cập được bởi người dùng sở hữu các giá trị thuộc tính nhất định Do đó, chỉ cần tìm người dùng sở hữu các giá trị thuộc tính cần tìm là có thể xác định được tài nguyên nhạy cảm có bị truy cập bất hợp pháp hay không, từ đó suy ra hệ thống có không an toàn Để phân tích hệ thống, cần thu thập tất cả các hành động quản trị có thể xảy ra, kiểm tra từng hành động và xác định các trạng thái mới sau mỗi hành động Quá trình phân tích mật này tiêu tốn nhiều thời gian.

Giải thuật đầu tiên tôi muốn giới thiệu là phương pháp tiếp cận xuôi Đây là giải thuật tìm kiếm hệ thống có lỗ hổng bảo mật hay không Nếu hệ thống không có lỗ hổng bảo, giải thuật sẽ kiểm tra tất cả các trạng thái mà hệ thống có thể sinh ra, sau đó kết thúc và kết luận rằng hệ thống an toàn Khi hệ thống thực hiện một hành động quản trị nào đó, nó sẽ chuyển sang trạng thái mới Giải thuật sẽ bắt đầu từ trạng thái ban đầu khi mà chưa có hành động quản trị nào được thực hiện Sau đó, giải thuật sẽ kiểm tra mọi trạng thái có thể được sinh ra bởi trạng thái ban đầu Hãy gọi các trạng thái này là trạng thái lớp thứ nhất 1 Trạng thái ban đầu là trạng thái lớp 0 Sau đó, giải thuật sẽ kiểm tra tất cả các trạng thái lớp thứ 1 Nếu có lỗ hổng bảo mật, thì hệ thống không an toàn Nếu không, hệ thống sẽ tạo ra tất cả các trạng thái lớp thứ 2 được tạo từ các trạng thái lớp thứ 1 Sau đó kiểm tra xem hệ thống có an toàn hay không Hệ thống sẽ thực hiện k lớp (0 k) Nó sẽ dừng nếu hệ thống không an toàn hoặc không có thêm trạng thái nào được sinh ra

1.2 Vấn đề bùng nổ trạng thái

Giải thuật tiếp cận xuôi có thể tìm kiếm được lỗ hổng bảo mật trong hệ thống được xây dựng bởi mô hình quản trị GURAG Nhưng khi số lượng người dùng, quản trị viên và hành động quản trị rất lớn Nhiệm vụ này có thể mất rất nhiều thời gian để hoàn thành, và không khả thi khi áp dụng trong thực tế Chúng ta có thể thấy trong hình 3 Nó cho thấy rằng khi k tăng, số lượng trạng thái bùng nổ nhanh chóng với giải thuật tiếp cận xuôi

Figure 4.1 Vấn đề bùng nổ trạng thái

1.3 Giải thuật tiếp cận ngược

Trong phần này, tôi sẽ giới thiệu phương pháp tiếp cận ngược [20] để giải quyết vấn đề bùng nổ trạng thái Thay vì tìm kiếm từ trạng thái ban đầu, phương pháp tiếp cận ngược bắt đầu tìm kiếm từ goal Goal là một tập các giá trị thuộc tính Để đơn giản hóa, goal sẽ chỉ chứa một giá trị thuộc tính

Phương pháp tiếp cận ngược chạy theo các bước sau:

1 sử dụng goal làm mục tiêu tìm kiếm ban đầu

2 tìm tất cả các hành động quản trị làm cho giá trị thuộc tính trong goal thỏa mãn

3 kiểm tra xem có trạng thái nào được tìm thấy là trạng thái ban đầu hay không, nếu có thì dừng lại

4 điều kiện của tất cả các hành động đã được tìm thấy trong bước 2 trở thành mục tiêu tìm kiếm Lặp lại bước 2

Figure 4 2 Phương pháp tiếp cận xuôi và tiếp cận ngược

Chúng ta có thể so sánh 2 giải thuật như trong hình 4 Chúng ta có thể thấy rằng phương pháp tiếp cận ngược có thể giảm rất nhiều hành động quản trị không liên quan đến "goal" Ngoài ra, giải thuật tiếp cận xuôi không dừng lại cho đến khi hệ thống không thể thực hiện thêm bất kỳ hành động quản trị nào hoặc tìm thấy trạng thái không an toàn trong khi phương pháp tiếp cận ngược tránh được việc mở rộng không giới hạn này

1.4 Xây dựng các công thức logic vị từ cho mô hình GURA G và mô hình kiểm tra bằng MCMT

Trong phần này, tôi sẽ giới thiệu công cụ MCMT [15] MCMT là một công cụ thực hiện phương pháp tiếp cận ngược Tôi sẽ sử dụng MCMT để tự động kiểm tra lỗ hổng bảo mật trong mô hình GURAG Để sử dụng MCMT, tôi phải dịch tất cả các hành động quản trị sang ngôn ngữ đầu vào của MCMT Các hành động quản trị này phải được dịch sang logic vị từ trước khi chuyển đổi sang dạng ngôn ngữ đầu vào của MCMT

Tập hợp các hành động quản trị trong hệ thống MCMT có nhiệm vụ kiểm tra đường đi từ trạng thái ban đầu đến trạng thái mục tiêu Trạng thái ban đầu là trạng thái không kích hoạt bất kỳ giá trị thuộc tính nào của người dùng và quản trị viên Trạng thái mục tiêu là tập hợp các giá trị thuộc tính của người dùng; nếu người dùng sở hữu đủ các giá trị này, hệ thống sẽ trở nên không an toàn.

Ví dụ, chính sách “sinh viên không được phép truy cập đối tượng O (readerType: teacher)” có nghĩa là người dùng sở hữu giá trị thuộc tính đồng thời là sinh viên và giảng viên sẽ gây mất an toàn cho hệ thống Goal: {sinh viên, giảng viên}

Goal = {attribute_value 1, attribute_value 2, attribute_value n}

Goal được viết dưới dạng logic vị từ như sau: attribute_value 1 ˄ attribute_value 2 ˄ attribute_value 3 ˄ ˄ attribute_value n Các hành động quản trị trong GURAG gồm 3 phần chính, admin role, user condition set, và target set MCMT chỉ có thể kích hoạt một target đối với mỗi hành động quản trị Vì vậy chúng tôi tách các hành động quản trị có target gồm nhiều giá trị thuộc tính ra thành nhiều hành động quản trị với target đơn

Ví dụ, Can_add_attjobTitle rule:

(DeptAdmin, graduated ∈ effectiveUserType(u), {Student,TA}) sẽ được tách thành 2 hành động quản trị với điều kiện của admin và người dùng được giữ nguyên Hành động quản trị 1: Can_add_attjobTitle rule:

Hành động quản trị 2: Can_add_attjobTitle rule:

Các hành động xác thực trong tập hợp kiểm thử được định dạng là: Can_add_att thuộc tính_quyền_giá_trị, thuộc tính_người_dùng_giá_trị 1, thuộc tính_người_dùng_giá_trị 2, , thuộc tính_người_dùng_giá_trị n; giá_trị_mục_tiêu.

Khi các test case xuất hiện điều kiện “true” đối với admin hoặc người dùng nghĩa là điều kiện này luôn thỏa mãn

Can_add_att và Can_delete_att được viết dưới dạng logic vị từ như sau:

Can_add_att (ad_att_value,u_att_value1, u_att_value2, u_att_value3…att_value)

∃ ua, u ˄ (ua, ad_att_value) ∈ 𝑈𝐴 ˄ (u, u_att_value1) ∈ 𝑈𝐴 ˄ (u, u_att_value2) ∈ 𝑈𝐴 ˄ (u, u_att_value3) ∈ 𝑈𝐴

Can_delete_att (ad_att_value,u_att_value1, u_att_value2, u_att_value3…att_value)

Một tập test case bao gồm tất cả các hành động quản trị của hệ thống là dữ liệu đầu vào cho quá trình phân tích Vì vậy cần tạo ra một tập các test case để sử dụng cho quá trình phân tích tự động mô hình GURAG Do mô hình HGABAC và GURAG chưa được sử dụng trong thực tế nên không thể có được một tập test case thực tế cho quá trình phân tích Do đó, chúng tôi tạo ra tập test case cho quá trình phân tích dựa trên một tập test case thực tế của mô hình RBAC được thu thập từ các bệnh viện và trường học

Tập test case của mô hình RBAC là tập test case chỉ sử dụng role Mô hình GURAG lại sử dụng mô hình RBAC để quản lý các admin Vì vậy chúng tôi giữ lại các hành động quản trị trong mô hình RBAC như là phần quản trị cho admin Sau đó, tôi thêm các action thực thi các hành động quản trị trên người dùng Chúng tôi ký hiệu các giá trị thuộc tính vai trò của admin là “an” trong đó a biểu thị thuộc tính vai trò admin n biểu thị giá trị thuộc tính, ví dụ a5 là một giá trị thuộc tính vai trò

Các thuộc tính của người dùng sẽ được ký hiệu với các chữ cái tiếp theo b,c,d…Người dùng sẽ không được sở hữu các thuộc tính vai trò của admin Vì vậy các target của các hành động quản trị trên người dùng sẽ không chứa các giá trị thuộc tính vai trò

Ví dụ một hành động quản trị cho admin sẽ như sau:

Trong ví dụ trên, một người admin có giá trị thuộc tính vai trò là a1 có thể gán giá trị thuộc tính vai trò a4 cho một người admin sở hữu giá trị thuộc tính vai trò a2 và a3 cùng một lúc

Ví dụ một hành động quản trị cho người dùng sẽ như sau

HIỆN THỰC HEURISTIC

Trong phần này tôi sẽ trình bày về các heuristics (phương pháp giải quyết vấn đề bằng cách đánh giá kinh nghiệm, và tìm giải pháp qua thử nghiệm và rút tỉa khuyết điểm) Các heuristics được tạo ra sau khi thực hiện chương trình nhằm làm giảm thời gian chạy của chương trình hiện thực Model checking có thể phải được chạy nhiều lần với rất nhiều goal khác nhau để có thể kiểm tra được toàn bộ chính sách của hệ thống

Do vậy, thời gian chạy của model checking là một yếu tố quan trọng ảnh hưởng đến việc model checking có được áp dụng vào thực tế hay không

Các heuristics được áp dụng nhằm làm giảm số lượng action và các điều kiện của action trong file test case trước khi các test case được chạy bởi chương trình MCMT

Giải thuật tiếp cận xuôi được áp dụng nhằm xóa bỏ những action không thể được kích hoạt khi tìm kiếm từ trạng thái khởi đầu tới trạng thái kết thúc Tuy nhiên nếu kiểm tra các điều kiện đủ của từng action trong từng trạng thái thì sẽ rất khó và có thể tốn quá nhiều thời gian trong khi MCMT sẽ kiểm tra tất cả các trạng thái Vì vậy, việc kiểm tra những điều kiện đủ là không cần thiết Điều kiện cần để một action có thể được kích hoạt là các điều kiện của người dùng và admin ít nhất là có thể được kích hoạt, nếu không ta có thể chắc chắn rằng action đó sẽ không thể được thực thi

Ví dụ, khi xem xét action bên trên, nếu trong hệ thống các điều kiện a2, b1, c1 không thể được kích hoạt thì action trên không bao giờ có thể được thực thi Sau đây là một ví dụ về một tập các action và quá trình tiếp cận xuôi sẽ được giải thích thông qua ví dụ cụ thể

Action 1: Can_add_att true , true ; a2

Action 2: Can_add_att a2 , true ; b1

Trong ví dụ trên, khi xét các điều kiện của admin và user, action 1 sẽ đủ điều kiện để được thực thi và trong hệ thống sẽ xuất hiện admin sở hữu thuộc tính a2 Như vậy từ trạng thái khởi đầu hệ thống đã chuyển qua trạng thái thứ nhất với thuộc tính a2 có thể được gán cho một admin nào đó Khi tiếp tục xem xét điều kiện của các action khác, action 2 sẽ được thực thi vì điều kiện a2 giờ đây đã có thể thỏa mãn và hệ thống chuyển sang trạng thái kế tiếp Tương tự, hệ thống tiếp theo có thể kích hoạt action 3 vì điều kiện a2 của admin và điều kiện b1 của user đều có thể được thỏa mãn Tuy nhiên, action 4 sẽ không bao giờ có thể được kích hoạt vì điều kiện c1 không được thỏa mãn

Do đó, action 4 sẽ được xóa bỏ khỏi tập test case

Tương tự như giải thuật tiếp cận xuôi, phương pháp tiếp cận ngược sẽ tìm kiếm tất cả các action có thể được suy ra từ trạng thái “goal” Sau đây là ví dụ về một tập các action, “goal” Sau đó tôi sẽ phân tích phương pháp tiếp cận ngược thông qua ví dụ này

Từ trạng thái “goal”, 2 điều kiện cần thiết để kích hoạt trạng thái này là “b1” và

“c2” Hai điều kiện này cần phải được kích hoạt để trạng thái “goal” có thể được đạt tới Do vậy, tất cả các action có target là “b1” hoặc ”c1” sẽ được thực hiện Action 2 và action 4 sẽ được thực thi Sau đó, tất cả các điều kiện cần cho hai action này sẽ được kiểm tra xem liệu nó đã được kích hoạt chưa, nên điều kiện “a2” là điều kiện cần cho cả hai action 2 và 4 sẽ được kiểm tra Action 1 do đó sẽ được thực thi Quá trình tìm kiếm kết thúc khi không còn điều kiện nào cần được kích hoạt Do đó, action 5 và 6 sẽ bị xóa bỏ khỏi tập test case

Nếu trong tất cả các giá trị thuộc tính trong goal không xuất hiện trong phần target của các action trong tập test case Vậy sẽ có giá trị thuộc tính trong goal không bao giờ có thể được kích hoạt, nên có thể kết luận ngay hệ thống an toàn Ví dụ, “goal : a1 b3 c2” nếu trong toàn bộ tập test case không có bất kỳ một action nào có thể kích hoạt được giá trị thuộc tính “b3” thì hệ thống chắc chắn an toàn với goal này

Heuristic thứ ba, là heuristic nhằm gộp những action tương tự nhau nhưng trong phần điều xuất hiện các thuộc tính trái ngược nhau.

Cùng xem xét 2 action ở trên, có thể nhận thấy rằng nếu các điều kiện “a2” và

“c1” đều được thỏa mãn, thì điều kiện “b1” là dư thừa Vì nếu điều kiện “b1” không thể được thỏa mãn thì điều kiện “-b1” chắc chắn được thỏa mãn và ngược lại Do đó, nếu action 1 không thể được thực thi thì action 2 chắc chắn sẽ được thực thi và ngược lại Vậy nên 2 action 1 và 2 cùng tồn tại trong tập test case sẽ khiến chương trình MCMT sẽ phải kiểm tra trên cả 2 action và thời gian chạy sẽ lâu hơn Do vậy 2 action trên sẽ được gộp thành action 3 phía dưới và 2 action này sẽ được xóa bỏ khỏi tập test case

Trong phần này, tôi sẽ trình bày heuristic thứ 4 Đây là heuristic nhằm xóa bỏ những action có điều kiện user chứa thuộc tính âm và không thể được thực hiện bởi hệ thống Cùng xem xét tập các action dưới đây

Action 6: Can_delete_att a2 , true ; b1

Sau khi xét action 6, điều kiện đủ để thực hiện action 5 là điều kiện quản trị viên "a2", điều kiện người dùng "-b1" và "c2" Điều kiện quản trị viên "a2" được action 1 đảm bảo Chỉ có duy nhất action 4 khiến điều kiện "c2" đạt; tương ứng, chỉ action 3 khiến điều kiện người dùng của action 4 ("b2") đạt Cuối cùng, điều kiện người dùng "b1" của action 3 chỉ đạt khi thực hiện được action 2.

3 -> action 4 -> action 5 để có thể khiến điều kiện user “c2” của action 5 có thể được thỏa mãn Điều này đồng nghĩa với việc user sở hữu attribute “c2” chắc chắn sẽ sở hữu attribute “b1” Nếu vậy điều kiện “-b1” trong action 5 sẽ không thể được thỏa mãn Do vậy, action 5 hoàn toàn có thể được xóa bỏ khỏi tập test case Action 5 chỉ có thể được thực thi khi có một con đường nào đó khác để kích hoạt được attribute “c2” hoặc một action có thể xóa bỏ attribute “b1” cho user như action 6

When a negative condition action occurs, heuristics checks to see if any action can remove that attribute, so that the negative condition can be satisfied Likewise, other positive attributes will also be checked to see if a similar case occurs If there is a single and compelling path, as in the above example, and there is no action to remove the condition for the negative attribute, the action will be removed.

2.5 Heuristic 5 Đây là heuristic nhằm làm giảm các điều kiện trong action và gộp các action giống nhau sau khi được giảm điều kiện

Action 2: Can_delete_att true , true ; a1

Điều kiện "a1" luôn được thỏa mãn do có action 1 thỏa mãn "a1" và action 2 thỏa mãn "-a1" Do đó, điều kiện "a1" hoặc "-a1" trở nên dư thừa trong hệ thống có hai action 1 và 2.

THÍ NGHIỆM

THÍ NGHIỆM CHƯA CÓ HEURISTICS

Trong thí nghiệm đầu tiên của chúng tôi Chúng tôi cho số lượng của attribute role admin max value, number attributes of user, attribute user max value, number of action tăng một cách từ từ Đối với mỗi giá trị chúng tôi tạo ra 10 test case với goal được tạo ngẫu nhiên khác nhau Sau đó chạy MCMT và lấy kết quả trung bình thời gian chạy của 10 test case Kết quả thu được cho thấy, thời gian chạy cũng tăng một cách từ từ

Table 1 Thí nghiệm nghiên cứu sự ảnh hưởng của các yếu tố và không áp dụng heuristics

Figure 5.1 Thí nghiệm chưa có heuristic

Trong thí nghiệm thứ 2 của chúng tôi, chúng tôi chọn lựa một test case với attribute role admin max value là 10, attribute user max value là 50, number of action là 100 Sau đó chúng tôi cho number attributes of user tăng dần Với mỗi giá trị của number attributes of user chúng tôi tạo ra 10 test case với goal khác nhau Sau đó thực thi bằng MCMT và lấy thời gian chạy trung bình của 10 test case Kết quả được thể

Test 1 Test 2 Test 3 Test 4 Test 5 Test 6 Test 7

Average runtime hiện như trong bảng 2 Kết quả cho thấy thời gian chạy trung bình tăng khi number attributes of user tăng

Table 2 Kết quả khi number of attributes of user tăng

Trong thí nghiệm thứ 3 của chúng tôi Chúng tôi chọn một test case có attribute role admin max value là 5, Number attributes of user là 7, attribute user max value là

10 Sau đó chúng tôi cho number of action tăng dần, Đối với mỗi giá trị của Number of action chúng tôi tạo ra 10 test case với goal khác nhau Sau đó chạy MCMT và tính kết quả trung bình của 10 test case Kết của của thí nghiệm được thể hiện trong bảng 3 Qua kết quả trong bảng 3 chúng ta có thể thấy rằng thời gian chạy của các test case tăng theo số lượng của các action

Table 3 Kết quả khi số lượng action tăng

# Number of action Average run-time (sec)

Mối tương quan giữa số lượng attribute user và thời gian chạy trung bình

Thời gian chạy trung bình

Hình 5 0.1 Thí nghiệm với attribute user tăng dần

Figure 3.2 Thí nghiệm với attribute user tăng dần

Figure 5.3 Thí nghiệm với số lượng action tăng dần

THÍ NGHIỆM VỚI HEURISTICS

Trong phần này, các giải thuật heuristic sẽ được triển khai để tối ưu thời gian thực thi của chương trình MCMT Ban đầu, một tập hợp các trường hợp thử nghiệm có cấu hình 15 15 15 15 sẽ được tạo ra, số lượng các hành động tăng dần Sau đó, thí nghiệm sẽ được thực thi.

Mối tương quang giữa số lượng action và thời gian chạy trung bình

Thời gian chạy trung bình với từng heuristic đơn lẻ và ở thí nghiệm cuối cùng, tất cả các heuristic sẽ được tích hợp lại Đối với mỗi test case, chương trình kiểm thử sẽ tạo ra 10 goal một cách ngẫu nhiên, sau đó chạy 10 lần và lấy kết quả trung bình

2.1 Thí nghiệm chưa có heuristic

Trong thí nghiệm đầu tiên này, chưa có bất kỳ một heuristic nào được áp dụng Kết quả được thể hiện trong bảng sau

Table 4 Thí nghiệm tăng số lượng action chưa áp dụng heuristics

2.2 Thí nghiệm với giải thuật tiếp cận xuôi

Trong thí nghiệm này, giải thuật tiếp cận xuôi được áp dụng Kết quả được thể hiện trong bảng sau

Table 5 Thí nghiệm áp dụng giải thuật tiếp cận xuôi

Average runtime with heuristic (sec)

Average runtime without heuristic (sec)

Khi so sánh kết quả giữa việc áp dụng giải thuật và không áp dụng giải thuật, có thể thấy rằng giải thuật có hiệu quả trong một số trường hợp

2.3 Thí nghiệm với phương pháp tiếp cận ngược

Trong thí nghiệm này, phương pháp tiếp cận ngược được áp dụng Kết quả được thể hiện trong bảng sau

Table 6 Thí nghiệm áp dụng phương pháp tiếp cận ngược

Trong thí nghiệm này, heuristic thứ 3 được áp dụng (tham khảo chương 4 mục 2.3) Kết quả được thể hiện trong bảng sau

Table 7 Thí nghiệm áp dụng heuristics 3

Khi so sánh kết quả sử dụng giải thuật với trường hợp không sử dụng, có thể nhận thấy rằng giải thuật tỏ ra hiệu quả trong một số trường hợp.

2.7 Thí nghiệm với giải thuật sắp xếp

Trong thí nghiệm này, giải thuật sắp xếp được áp dụng Kết quả được thể hiện trong bảng sau

Table 10 Thí nghiệm áp dụng giải thuật sắp xếp

2.8 Thí nghiệm tích hợp tất cả các heuristic

Trong thí nghiệm này, tất cả các heuristic được áp dụng cùng lúc Kết quả được thể hiện trong bảng sau

Table 11 Thí nghiệm áp dụng tất cả các heuristics

Việc kết hợp các giải thuật heuristic giúp cải thiện hiệu suất đáng kể Qua so sánh kết quả giữa việc áp dụng giải thuật kết hợp và không áp dụng, có thể thấy sự cải thiện rõ rệt khi sử dụng phương pháp kết hợp.

Tiêu đề	Phân tích tự động thuộc tính bảo mật cho mô hình điều khiển truy xuất dựa trên thuộc tính
Tác giả	Trần Đức Tuấn
Người hướng dẫn	TS. Trương Tuấn Anh
Trường học	Trường Đại học Bách Khoa, Đại học Quốc gia TP.HCM
Chuyên ngành	Khoa học Máy tính
Thể loại	Luận văn Thạc sĩ
Năm xuất bản	2021
Thành phố	Hồ Chí Minh

Định dạng
Số trang	64
Dung lượng	757,14 KB