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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (757.14 KB, 64 trang )

Trang 1<div class="page_container" data-page="1">

LUẬN VĂN THẠC SĨ

TP. HỒ CHÍ MINH, tháng 01 năm 2021

</div>Trang 2<div class="page_container" data-page="2">

Cán bộ hướng dẫn khoa học: TS. TRƯƠNG TUẤN ANH

Cán bộ chấm nhận xét 1: TS. Đặng Trần Trí

Cán bộ chấm nhận xét 2: TS. Lê Lam Sơn

Luận văn thạc sĩ được bảo vệ tại Trường Đại học Bách Khoa, ĐHQG Tp. HCM ngày 06 tháng 08 năm 2021

Thành phần Hội đồng đánh giá luận văn thạc sĩ gồm:

1. Chủ tịch: PGS.TS Đặng Trần Khánh ...

2 Thư ký: TS. Phan Trọng Nhân ... .

3 GVPB 1:TS. Đặng Trần Trí ... .

4. GVPB 2: TS. Lê Lam Sơn ...

5. Ủy viên: PGS. TS. Huỳnh Trung Hiếu ...

Xác nhận của Chủ tịch Hội đồng đánh giá luận văn và Trưởng Khoa quản lý chuyên ngành sau khi luận văn được sửa chữa nếu có.

KHOA HỌC VÀ KỸ THUẬT MÁY TÍNH

</div>Trang 3<div class="page_container" data-page="3">

ĐẠI HỌC QUỐC GIA TP. HCM

TRƯỜNG ĐẠI HỌC BÁCH KHOA

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM Độc lập - Tự do - Hạnh phúc

NHIỆM VỤ LUẬN VĂN THẠC SĨ

Họ tên học viên: TRẦN ĐỨC TUẤN ... MSHV: 1770483 Ngày, tháng, năm sinh: 06/08/1992 ... Nơi sinh: LÂM ĐỒNG Chuyên ngành: KHOA HỌC MÁY TÍNH ... Mã số : 60480101

I. TÊN ĐỀ TÀI: 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.

II. NHIỆM VỤ VÀ NỘI DUNG:

- Tìm hiểu các kiến thức về các mơ hình điều khiển truy xuất và các phương pháp phân tích tự động các mơ hình điều khiển truy xuất.

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

III. NGÀY GIAO NHIỆM VỤ: 03/2021

IV. NGÀY HOÀN THÀNH NHIỆM VỤ: 07/2021 V. CÁN BỘ HƯỚNG DẪN: TS. TRƯƠNG TUẤN ANH

Tp. HCM, ngày tháng năm 2021

TRƯỞNG KHOA KHOA HỌC VÀ KỸ THUẬT MÁY TÍNH

</div>Trang 4<div class="page_container" data-page="4">

LỜI CẢM ƠN

Trong quá trình làm đề tài, bên cạnh những cố gắng của cá nhân, tơi cịn nhận được sự hỗ trợ tận tình, quý báu từ các thầy, anh chị trong ngành, cùng với sự động viên chia sẻ đến từ gia đình và bạn bè. Điều này giúp tôi vượt qua được những khó khăn trong thời gian thực hiện đề tài, giúp tơi ln bám sát và hồn thành đề tài.

Tôi xin chân thành cảm ơn TS. Trương Tuấn Anh đã giúp tôi định hướng đề tài và có những ý kiến đóng góp quý báu giúp đề tài ngày càng hồn thiện. Sự tận tình của thầy đã giúp tôi luôn luôn vững tin và vượt qua được những khó khăn trong suốt q trình nghiên cứu. Tôi cũng xin gửi lời cảm ơn của mình đến tất cả những giảng viên khoa Khoa Học và Kỹ Thuật Máy Tính đã tận tâm giảng dạy giúp tơi có những kiến thức nền tảng vững chắc để thực hiện đề tài.

Tôi xin cảm ơn khoa Khoa Học và Kỹ Thuật Máy Tính và trường Đại Học Bách Khoa đã hỗ trợ tận tình trong quá trình làm luận văn.

TP. Hồ Chí Minh, ngày 04 tháng 07 năm 2021

Học viên thực hiện

Trần Đức Tuấn

</div>Trang 5<div class="page_container" data-page="5">

TÓM TẮT LUẬN VĂN

Do những hạn chế của mơ hình Kiểm sốt truy cập dựa trên vai trị (RBAC), mơ hình Kiểm sốt truy cập dựa trên thuộc tính (ABAC) đang được nghiên cứu và hứa hẹn sẽ trở thành mơ hình truy cập thống trị trong tương lai gần. Tương tự như mơ hình RBAC, vấn đề phân tích bảo mật, tức là vấn đề phân tích chính sách bảo mật để xác minh xem có bất kỳ vấn đề bảo mật nào trong chính sách bảo mật hay không, là một trong những vấn đề quan trọng của mơ hình ABAC. Trong luận văn này, chúng tôi xem xét vấn đề bảo mật trong một mơ hình cải tiến của mơ hình ABAC, cụ thể là 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) và mơ hình quản trị của nó là mơ hình quản trị cho người dùng và phân bổ thuộc tính nhóm (GURAG).Chúng tôi đã nghiên cứu và sử dụng phương pháp tiếp cận ngược để xây dựng kỹ thuật phân tích cho các chính sách của GURAG. Chúng tôi đã sử dụng các kỹ thuật và thực hiện một số thí nghiệm để chứng minh tính khả thi và mở rộng của các kỹ thuật phân tích đã đề xuất. Ngồi ra chúng tơi cịn nghiên cứu và xây dựng các heuristics để làm giảm thời gian phân tích.

</div>Trang 6<div class="page_container" data-page="6">

ABSTRACT

Due to the limitations of the Role-Based Access Control (RBAC) model, the Attribute-Based Access Control (ABAC) model is being researched and promised to become a dominant access model shortly. Similar to RBAC, the security analysis problem, i.e., the problem to analyze the policy to verify if there is any security issue in the policy, is one of the crucial problems in ABAC. In this thesis, we consider the security analysis problem in a recently proposed implementation of the ABAC model, namely hierarchical group and attribute-based access control (HGABAC), and its administration model namely Administrative Model for User and Group Attribute Assignment (GURAG). We have investigated and assembled backward algorithm to develop analytical techniques for GURAG's policies. We also implement the technique and perform some experiments to show the scalability of the proposed technique. Moreover, we also research and build heuristics to improve performance.

</div>Trang 7<div class="page_container" data-page="7">

LỜI CAM ĐOAN

Tôi xin cam đoan tồn bộ những phần nghiên cứu và trình bày của tôi đều dưới sự hướng dẫn của TS. TRƯƠNG TUẤN ANH. Ngoài những tài liệu tham khảo được liệt kê trong phần tài liệu tham khảo thì tơi không sao chép bất cứ tài liệu hoặc các công trình nghiên cứu khác. Nếu có bất kỳ sai phạm nào, tơi xin chịu hồn tồn trách nhiệm trước Ban Chủ Nhiệm Khoa và Ban Giám Hiệu Nhà Trường.

TP. Hồ Chí Minh, ngày 04 tháng 07 năm 2021

Học viên thực hiện

Trần Đức Tuấn

</div>Trang 8<div class="page_container" data-page="8">

MỤC LỤC

NHIỆM VỤ LUẬN VĂN THẠC SĨ ... ILỜI CẢM ƠN... IITÓM TẮT LUẬN VĂN ... IIIABSTRACT ... IVLỜI CAM ĐOAN ... VMỤC LỤC ... VIDANH MỤC BẢNG BIỂU ... IXDANH MỤC HÌNH VẼ ... XDANH SÁCH TỪ VIẾT TẮT ... XI

CHƯƠNG 1: MỞ ĐẦU ... 1

1.GIỚI THIỆU ĐỀ TÀI ... 1

1.1.Ngữ cảnh bài toán ... 1

1.2.Vấn đề cần giải quyết ... 1

2.MỤC TIÊU CỦA ĐỀ TÀI ... 2

3.GIỚI HẠN CỦA ĐỀ TÀI ... 2

</div>Trang 9<div class="page_container" data-page="9">

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

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

CHƯƠNG 3: MƠ HÌNH HGABAC VÀ MƠ HÌNH GURAG ... 9

1.MƠ HÌNH HGABAC ... 9

1.1.Mơ tả mơ hình HGABAC ... 9

1.2.Cơng thức HGABAC thay thế ... 10

2.MƠ HÌNH GURAG ... 14

CHƯƠNG 4: HIỆN THỰC ... 17

1.HIỆN THỰC MODEL CHECKING ... 17

1.1.Phân tích mơ hình GURAG ... 17

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

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

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

1.5.Ngôn ngữ MCMT cho các test case ... 23

1.THÍ NGHIỆM CHƯA CĨ HEURISTICS ... 35

2.THÍ NGHIỆM VỚI HEURISTICS ... 39

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

2.2.Thí nghiệm với giải thuật tiếp cận xi ... 41

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

2.4.Thí nghiệm với Heuristic 3 ... 43

2.5.Thí nghiệm với Heuristic 4 ... 44

2.6.Thí nghiệm với Heuristic 5 ... 45

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

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

CHƯƠNG 6: KẾT LUẬN ... 48

</div>Trang 10<div class="page_container" data-page="10">

1.TỔNG KẾT ... 482.CÔNG VIỆC CHO TƯƠNG LAI ... 48

TÀI LIỆU THAM KHẢO ... 49

</div>Trang 11<div class="page_container" data-page="11">

DANH MỤC BẢNG BIỂU

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

TABLE 2 KẾT QUẢ KHI NUMBER OF ATTRIBUTES OF USER TĂNG ... 37

TABLE 3 KẾT QUẢ KHI SỐ LƯỢNG ACTION TĂNG ... 38

TABLE 4 THÍ NGHIỆM TĂNG SỐ LƯỢNG ACTION CHƯA ÁP DỤNG HEURISTICS ... 40

TABLE 5 THÍ NGHIỆM ÁP DỤNG GIẢI THUẬT TIẾP CẬN XI ... 41

TABLE 6 THÍ NGHIỆM ÁP DỤNG PHƯƠNG PHÁP TIẾP CẬN NGƯỢC ... 42

TABLE 7 THÍ NGHIỆM ÁP DỤNG HEURISTICS 3 ... 43

TABLE 8 THÍ NGHIỆM ÁP DỤNG HEURISTICS 4 ... 44

TABLE 9 THÍ NGHIỆM ÁP DỤNG HEURISTICS 5 ... 45

TABLE 10 THÍ NGHIỆM ÁP DỤNG GIẢI THUẬT SẮP XẾP ... 46

TABLE 11 THÍ NGHIỆM ÁP DỤNG TẤT CẢ CÁC HEURISTICS ... 47

</div>Trang 12<div class="page_container" data-page="12">

DANH MỤC HÌNH VẼ

FIGURE 2.1 CẤU TRÚC MƠ HÌNH ABAC [3] ... 8

FIGURE 3.1 MƠ HÌNH KHÁI NIỆM CỦA HGABAC [1] ... 10

FIGURE 3.2 VÍ DỤ VỀ Q TRÌNH U CẦU TRUY CẬP ... 14

FIGURE 4.1 VẤN ĐỀ BÙNG NỔ TRẠNG THÁI ... 18

FIGURE 4.2 PHƯƠNG PHÁP TIẾP CẬN XUÔI VÀ TIẾP CẬN NGƯỢC ... 19

FIGURE 5.1 THÍ NGHIỆM CHƯA CĨ HEURISTIC... 36

FIGURE 5.2 THÍ NGHIỆM VỚI ATTRIBUTE USER TĂNG DẦN ... 38

FIGURE 5.3 THÍ NGHIỆM VỚI SỐ LƯỢNG ACTION TĂNG DẦN ... 39

</div>Trang 13<div class="page_container" data-page="13">

DANH SÁCH TỪ VIẾT TẮT

ABAC Điều khiển truy cập dựa trên thuộc tính

RBAC Điều khiển truy xuất dựa trên vai trò

</div>Trang 14<div class="page_container" data-page="14">

Một trong các mơ hình đang được các nhà khoa học quan tâm hàng đầu là mơ hình điều khiển truy xuất dựa trên thuộc tính (Attribute-based access control). Mơ hình điều khiển truy xuất dựa trên thuộc tính (ABAC) hứa hẹn sẽ trở thành mơ hình điều khiển truy xuất được sử dụng rộng rãi trong tương lai gần. Hàng loạt các mơ hình điều khiển truy xuất dựa trên thuộc tính (ABAC) đã được đề xuất. Tuy nhiên vấn đề phân tích tự động các thuộc tính bảo mật của mơ hình ABAC chưa thật sự được quan tâm. Bài toán đặt ra là làm sao có thể phân tích tự động được mơ hình ABAC với các chính sách bảo mật của nó đã thật sự an tồn trước khi được đưa vào sử dụng.

1.2. Vấn đề cần giải quyết

Trong đề tài này, chúng tôi nghiên cứu về một mô hình điều khiển truy xuất dựa trên thuộc tính (ABAC) mà cụ thể là 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) và mơ hình quản trị của mơ hình HGABAC là mơ hình quản trị cho người dùng và phân bổ thuộc tính nhóm (GURAG).

</div>Trang 15<div class="page_container" data-page="15">

Hệ thống bảo mật được xây dựng gồm rất nhiều những hành động quản trị. Mỗi khi một hành động quản trị được thực hiện sẽ khiến cho hệ thống bị thay đổi và có thể dẫn đến hệ thống xuất hiện lỗ hổng dẫn đến bị vi phạm các tính chất bảo mật.

Vấn đề cần giải quyết là khi hệ thống có rất nhiều người dùng, admin và các chính sách bảo mật. Số lượng các hành động quản trị có thể được thực hiện là rất lớn dẫn đến không gian trạng thái có thể được sinh ra rất lớn. Việc kiểm tra lỗ hổng bảo mật trên từng trạng thái sẽ khiến thời gian kiểm tra là rất lớn và không khả thi khi triển khai thực tế. Do vậy cần có phương pháp phân tích tự động một cách phù hợp và xây dựng các heuristic nhằm tăng tốc q trình phân tích.

2. MỤC TIÊU CỦA ĐỀ TÀI

Trong một hệ thống điều khiển truy cập luôn cần có những người quản trị hệ thống (admin). Những admin này có nhiệm vụ điều khiển quyền truy cập vào hệ thống cũng như quyền truy xuất tài nguyên của hệ thống. Một hệ thống sử dụng mơ hình ABAC cũng vậy.

Những người quản trị có quyền gán những thuộc tính (attribute) cho người dùng (user), để người dùng có thể truy xuất tài nguyên hệ thống. Nhưng nếu những admin này vơ tình hoặc cố ý thông đồng với user để gán quyền một các trái phép cho user, khiến cho những user này có thể truy xuất một cách trái phép những tài nguyên nhạy cảm của hệ thống. Như vậy hệ thống sẽ xuất hiện lỗ hổng bảo mật. Mục tiêu của đề tài là tìm ra một mơ hình có thể phân tích được mơ hình quản trị của ABAC có tồn tại lỗ hổng bảo mật hay không, đồng thời xây dựng các giải thuật heuristic nhằm làm tăng q trình phân tích.

3. GIỚI HẠN CỦA ĐỀ TÀI

Mặc dù có một số mơ hình ABAC đã được đề xuất, tuy nhiên mơ hình điều khiển truy xuất dựa trên vai trò kết hợp hệ thống phân cấp nhóm “hierarchical group and

</div>Trang 16<div class="page_container" data-page="16">

attribute based access control (HGABAC) model” cùng với mơ hình quản trị của nó “GURAG Administrative Model” được lựa chọn làm đối tượng để phân tích vì tính đơn giản và khả năng triển khai thực tế cao của chúng.

Tuy nhiên nhằm đơn giản hóa để tiện cho việc phân tích phần cốt lõi của hai mơ hình này. Phần nhóm và phân cấp nhóm (group and hierarchical group) được tạm thời lược bỏ khỏi hai mơ hình này. Chúng tơi mong muốn đề xuất ra được một mô hình phân tích tính bảo mật cho GURAG đồng thời tạo ra một chương trình demo có thể chạy thử được một số test case cho chương trình này trong thời gian chấp nhận được. Đồng thời chúng tơi cịn xây dựng các heuristics nhằm làm giảm thời gian phân tích.

4. ĐĨNG GÓP CỦA ĐỀ TÀI

Đề tài phân tích tự động các chính sách bảo mật của mô hình ABAC, một mơ hình được đánh giá sẽ khắc phục được các nhược điểm của mô hình RBAC và sẽ được ứng dụng rộng rãi trong tương lai. Các lỗ hổng bảo mật được tìm thấy sẽ giúp xây dựng lại các chính sách bảo mật một cách chặt chẽ hơn, giúp hệ thống trở nên hoàn thiện hơn, đáng tin cậy hơn.

5. CẤU TRÚC CỦA ĐỀ TÀI

Chương I – Tổng quan: trình bày tổng quan về ngữ cảnh của bài tốn, mục tiêu, giới hạn và đóng góp của đề tài

Chương II – Các cơng trình liên quan và kiến thức nền tảng: trình bày một số

kiến thức nền tảng để người đọc có thể dễ dàng tiếp cận nội dung các chương sau. Các kiến thức này bao gồm khái niệm về các mơ hình điều khiển truy xuất.

Chương III – Mơ hình HGABAC và mơ hình GURAG: Trình bày hai mơ hình

được sử dụng để nghiên cứu và phân tích là HGABAC và GURAG, một số công thức và thành phần được thể hiện và điều chỉnh cho phù hợp với mục đích nghiên cứu.

</div>Trang 17<div class="page_container" data-page="17">

Chương IV – Hiện thực: Trình bày cách hiện thực phương pháp tiếp cận ngược

để giải quyết bài tốn sử dụng cơng cụ MCMT. Các tiếp cận và sử dụng ngôn ngữ đầu vào cho MCMT. Trình bày các heuristics nhằm làm giảm thời gian phân tích.

Chương V – Thử nghiệm: sẽ trình bày phương pháp và kết quả thử nghiệm của

chúng tôi.

Chương VI - Kết luận và cơng việc trong tương lai: trình bày các vấn đề đã

thực hiện được và chưa thực hiện được của đề tài. Đưa ra hướng phát triển và mở rộng trong tương lai.

</div>Trang 18<div class="page_container" data-page="18">

CHƯƠNG 2: TỔNG QUAN

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

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

</div>Trang 19<div class="page_container" data-page="19">

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.

</div>Trang 20<div class="page_container" data-page="20">

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.

</div>Trang 21<div class="page_container" data-page="21">

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 tương ứng với tập thuộc tính của người dùng, chủ thể và đối tượng. P là hàm kiểm sốt truy cập quyết định liệu chủ thể “s” có thể truy cập vào đối tượng “o” hay không.

</div>Trang 22<div class="page_container" data-page="22">

CHƯƠNG 3: MƠ HÌNH HGABAC VÀ MƠ HÌNH GURA

G

1. 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 mơ hình HGABAC, các thực thể (entity) của mơ hình là người dùng (user), đối tượng (object) và chủ thể (subject). Đối tượng là tài nguyên của hệ thống (tệp, ứng dụng, v.v.). Người dùng truy cập gián tiếp vào các đối tượng thông qua chủ thể. Các chủ thể được tạo ra bởi người dùng (quá trình ‘processes’, phần ‘sections’) khi họ tương tác với hệ thống. Một chủ thể sở hữu các thuộc tính của người dùng tạo ra nó, các thuộc tính này có thể khác nhau theo thời gian nhưng khơng vượt q các tập thuộc tính của người dùng tạo ra nó. Chủ thể và người dùng có cùng một tập hợp tối đa các thuộc tính trong khi, các đối tượng có một tập hợp các thuộc tính riêng biệt phản ánh các đặc điểm của chúng. Các hoạt động (operation) là các tác vụ truy cập hệ thống (đọc, ghi) được thực hiện bởi các chủ thể lên các đối tượng. Các thuộc tính là một tập hợp các giá trị thuộc tính (attribute value).

Sự cải tiến của mơ hình HGABAC là mơ hình được tổ chức theo các nhóm và các nhóm được phân theo các cấp. Người dùng, chủ thể và đối tượng thuộc về các nhóm. Người dùng, chủ thể hoặc đối tượng có các giá trị thuộc tính riêng của mình đồng thời kế thừa các giá trị thuộc tính từ nhóm mà nó thuộc về. Thay vì thay đổi giá trị thuộc tính cho từng người dùng, admin có thể thay thay đổi giá trị thuộc tính từ nhóm. Do đó, mơ hình HGABAC giảm hàng nghìn hành động quản trị bằng cách thay đổi giá trị thuộc tính trên các nhóm thay vì thay đổi giá trị thuộc tính trên hàng nghìn user đơn lẻ.

</div>Trang 23<div class="page_container" data-page="23">

Nhằm đơn giản hóa mơ hình HGABAC để dễ dàng hơn trong q 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)

UA ⊆ U × A và OA ⊆ O × A

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.

</div>Trang 24<div class="page_container" data-page="24">

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

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” ] bool_var

/ [ “NOT” ] “(”Au_func “)”

term = const / att_name

bool_var = boolean / att_name

boolean = “TRUE” / “FALSE”

set = “{” “}” / “{” setval “}”

</div>Trang 25<div class="page_container" data-page="25">

setval = atomic / atomic “,” setval

atomic = int / float / string / “NULL”

Trong đó user_att_name, admin_att_name là tên thuộc tính của người dùng và

admin trong tập UA, object_att_value là tên thuộc tính của đối tượng trong tập OA.

Các thành phần int, float, string là các giá trị có kiểu dữ liệu tương ứng int, float,

˄ 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: U = {Alice, Bob, Shan}

Au = {UserType, Location, Faculty} Trong đó:

UserType ={student, teacher, tutor assistant}; Location = {Paris, New York, London}; and Faculty = {Chemistry, Medical, Physical} O = {O1, O2}

</div>Trang 26<div class="page_container" data-page="26">

Ao= [ReaderType, Location} Trong đó:

ReaderType = {student, teacher} and Location = {Paris, New York} Mô hình HGABAC với UA và OA như sau:

User UserType Location Faculty

Alice Student Paris Chemistry Bob Teacher New York Medical Shan Tutor

assistant

London Physical

Giả sử: op = {read}

S = {UserType: student, Location: Paris}

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

Quá 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. Trong đó các điều kiện user.UserType ∈ object.ReaderType và user.Location = object.Location được thỏa mãn, do đó chủ thể s được phép đọc o1.

Object ReaderType Location

O1 Student Paris

</div>Trang 27<div class="page_container" data-page="27">

Figure 3.2 Ví dụ về q trình 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ể ln có thể nhận thuộc tính từ người dùng hoặc tồ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).

2. MÔ HÌNH GURAG

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.

</div>Trang 28<div class="page_container" data-page="28">

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

</div>Trang 29<div class="page_container" data-page="29">

Đ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 hồn tồn có thể thêm hoặc xóa attribute_target cho người dùng.

Ví dụ:

Can_add_attjobTitle rule:

(DeptAdmin, graduated ∈ effectiveUserType(u), {TA}) Can_delete_attroomAcc rule:

(BuildAdmin, graduated ∈ effectivestudStatus(u), {1.2, 2.03, 2.04, 3.02})

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.

</div>Trang 30<div class="page_container" data-page="30">

CHƯƠNG 4: HIỆN THỰC

1. HIỆN THỰC MODEL CHECKING

1.1. Phân tích mơ hình GURAG

Mục tiêu của đề tài là tìm ra xem hệ thống có xuất hiện lỗ hổng bảo mật hay không. Nghĩa là sau một số các hành động quản trị, xuất hiện một người dùng có quyền truy cập đến một tài nguyên nhạy cảm mà hành động này dẫn đến nguy hiểm cho hệ thống. Khi hệ thống xuất hiện lỗ hổng bảo mật, ta nói rằng hệ thống khơng an tồn (unsafe). Tài nguyên nhạy cảm chỉ có thể được truy cập thông qua người dùng sở hữu những giá trị thuộc tính nhất định. Như vậy chỉ cần tìm được liệu hệ thống có xuất hiện một người dùng sở hữu những giá trị thuộc tính cần tìm, là ta đã có thể xác định tài nguyên nhạy cảm có thể bị truy xuất một cách bất hợp pháp hay không từ đấy có thể suy ra hệ thống có khơng an tồn hay khơng. Ví dụ, nếu có một người dùng sở hữu cùng lúc 2 giá trị thuộc tính “sinh viên, giảng viên” như vậy hệ thống không an tồn khi một sinh viên có thể truy xuất đến những tài nguyên nhạy cảm của giảng viên. Tập thuộc tính mà ta muốn tìm được định nghĩa là “Goal”.

Để phân tích được hệ thống, ta cần thu thập tất cả các hành động quản trị mà hệ thống có thể có. Từ đó xét duyệt từng hoạt động quản trị. Từ khi hệ thống chưa có bất kỳ hành động quản trị nào được thực hiện. Hệ thống sẽ xác định xem những hành động quản trị nào có thể được thực thi. Khi một hành động quản trị được thực hiện, hệ thống sẽ được chuyển sang một trạng thái mới và cần phải được kiểm tra lại tồn bộ. Đây là một q trình phân tích mật 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ị

</div>Trang 31<div class="page_container" data-page="31">

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 tồ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 tồ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 tồ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 xi 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

</div>Trang 32<div class="page_container" data-page="32">

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". Ngồ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

</div>