Nghiên cứu phát triển mô hình điều khiển truy xuất cho dữ liệu nosql

Bảo mật trong các mô hình này chủ yếu dựa trên: xác thực người dùng, mã hoá dữ liệu trước khi lưu trữ, tận dụng cơ chế bảo mật của hệ thống file, phân quyền mức dịch vụ, hay gần đây nhất

Trang 1

Luận văn Thạc Sĩ I HV: Hà Xuân Sơn – 1570226

ĐẠI HỌC QUỐC GIA TP HCM TRƯỜNG ĐẠI HỌC BÁCH KHOA

Trang 2

Luận văn Thạc Sĩ II HV: Hà Xuân Sơn – 1570226

CÔNG TRÌNH ĐƯỢC HOÀN THÀNH TẠI

TRƯỜNG ĐẠI HỌC BÁCH KHOA –ĐHQG -HCM

Cán bộ hướng dẫn khoa học : PGS TS Đặng Trần Khánh

Cán bộ chấm nhận xét 1 : TS Trương Tuấn Anh

Cán bộ chấm nhận xét 2 : TS Nguyễn Tuấn Đăng

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 29 tháng 12 năm 2017

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

1 TS Lê Lam Sơn

2 TS Phan Trọng Nhân

3 TS Trương Tuấn Anh

4 TS Nguyễn Tuấn Đăng

5 TS Lê Hồng Trang

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

CHỦ TỊCH HỘI ĐỒNG TRƯỞNG KHOA KH & KT MÁY TÍNH

TS Lê Lam Sơn

Trang 3

Luận văn Thạc Sĩ III HV: Hà Xuân Sơn – 1570226

ĐẠ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: Hà Xuân Sơn MSHV:1570226 Ngày, tháng, năm sinh: 17/03/1991 Nơi sinh: Cần Thơ Chuyên ngành: Khoa học máy tính Mã số: 60480101

I TÊN ĐỀ TÀI: Nghiên cứu phát triển mô hình điều khiển truy xuất cho dữ liệu lớn

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

- Nghiên cứu lý thuyết về dữ liệu NoSQL

- Nghiên cứu lý thuyết về mô hình điều khiển truy xuất

- Nghiên cứu lý thuyết về hệ thống hỗ trợ môi trường chính sách động

- Nghiên cứu và đề xuất một mô hình điều khiển truy xuất cho hệ thống hỗ trợ chính sách động

- Xây dựng cơ chế điều khiển truy xuất dựa trên mô hình lý thuyết đã đề xuất

- Tìm hiểu về các kỹ thuật và công nghệ để kiểm nghiệm và đánh giá các kết quả nghiên cứu

III NGÀY GIAO NHIỆM VỤ : 04/07/2016

IV NGÀY HOÀN THÀNH NHIỆM VỤ: 18/06/2017

Trang 4

Luận văn Thạc Sĩ IV HV: Hà Xuân Sơn – 1570226

LỜI CẢM ƠN

Tôi xin gửi lời cảm ơn sâu sắc đến PGS.TS Đặng Trần Khánh đã tận tình hướng dẫn, giúp

đỡ tôi thực hiện đề tài nghiên cứu này.Tôi cũng xin gửi lời cảm ơn đến các thành viên của nhóm DStar Lab, AC Lab của trường Đại học Bách Khoa TP Hồ Chí Minh và DISIs Lab của trường Đại học Trento (Ý) đã hỗ trợ và tạo điều kiện nghiên cứu cho tôi trong suốt thời gian qua

Sau cùng, tôi xin chân thành cám ơn đến gia đình và bạn bè đã luôn bên cạnh động viên và giúp đỡ tôi

Trang 5

Luận văn Thạc Sĩ V HV: Hà Xuân Sơn – 1570226

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

Với sự phổ biến ngày càng tăng của điện toán đám mây, hệ thống phân tán và mạng xã hội, dẫn đến rủi ro của những vi phạm dữ liệu nhạy cảm đã tăng lên Bởi vì ngày càng có nhiều doanh nghiệp và cá nhân có xu hướng lưu trữ thông tin cá nhân của họ trên Internet Đặc biệt là các thông tin và dữ liệu của các hệ thống liên quan đến giao thông, giáo dục, y tế, giải trí được lưu trữ với số lượng dữ liệu lớn, nhiều dạng khác nhau nhằm đáp ứng nhu cầu quản lý, thống kê và dự báo Song song với việc ứng dụng dữ liệu lớn là những yêu cầu về bảo mật và tính riêng tư càng trở nên cần thiết Chính vì vậy, bảo mật dữ liệu lớn đã được xem là một trong mười thác thức đặt ra cho các nghiên cứu trong tương lai về Big Data [2]

Có 3 cột mốc quan trọng trong việc bảo vệ tính riêng tư cho dữ liệu lớn phải kể đến là: access control, auditing và statistical privacy [1] Trong đó access control (điều khiển truy xuất) là khía cạnh được quan tâm của đề tài này Cho đến nay, một số mô hình kiểm soát truy cập đã được đề xuất dưới dạng đặc tả tính chất hoặc thực thi các cơ chế kiểm soát truy cập như kiểm soát truy cập bắt buộc (MAC), kiểm soát truy cập tùy quyền (DAC), kiểm soát truy cập dựa trên vai trò (Role-based Access Control - RBAC) và gần đây nhất là kiểm soát truy cập dựa trên thuộc tính (ABAC) [9] Vì tính chất của điều khiển truy xuất là hỗ trợ càng cao thì chi phí quản lý và vận hành càng lớn [1], chính vì vậy, các mô hình điều khiển truy xuất hiện nay đang vấp phải rất nhiều khó khăn khi ứng dụng cho cơ sở dữ liệu lớn Tóm lại, việc xây dựng một mô hình bảo mật tổng quát cho dữ liệu lớn vẫn còn là bài toán mở cho các hãng công nghệ và các nhóm nghiên cứu

Điều khiển truy đóng một vai trò quan trọng trong việc bảo vệ thông tin nhạy cảm và ngăn chặn kẻ tấn công không được tiếp cận thích hợp Hệ thống dựa trên chính sách bảo mật để xác định yêu cầu truy cập cho phép hoặc từ chối Tuy nhiên, trong những năm gần đây, do

sự phổ biến của dữ liệu lớn đã tạo ra một thách thức mới mà quản lý chính sách an ninh đang đối mặt như chính sách năng động, hay nói cách khác là cập nhật chính sách theo thời gian thực Áp dụng chính sách năng động mang lại lợi ích rất lớn cho các hệ thống phân tán, hệ thống điện toán đám mây và mạng xã hội Tuy nhiên, có rất ít các nghiên cứu trước đây tập trung vào việc giải quyết các vấn đề ủy quyền trong chính sách năng động Trong bài báo này, chúng tôi tập trung vào việc phân tích cách thay đổi chính sách và đưa ra các giải pháp trong môi trường chính sách năng động Sự đóng góp của bài báo này là hai lần: bao gồm cả giải pháp thay đổi chính sách ngay cả khi yêu cầu truy cập đã được cấp bởi chính sách và chúng tôi cung cấp triển khai dựa trên XACML kết hợp mô hình yêu cầu viết lại Kết quả kinh nghiệm với các chính sách thực tế đã đưa ra giá trị thực tiễn và lý thuyết của cách tiếp cận mới được giới thiệu của chúng tôi

Trang 6

Luận văn Thạc Sĩ VI HV: Hà Xuân Sơn – 1570226

ABSTRACT

With the growing popularity of cloud computing, distributed system and social networks, the risks of sensitive data breaches have increased due to the fact that more and more enterprises and individuals tend to store their private information on the Internet Especially, the database and information in the management system relating to transportation, education, health, and entertainment are stored with large quantities of data, under different types, processing speed increases, with the purpose to meet the requirements of management, statistics, forecasts, planning Therefore, big data security has been considered one of the ten challenges for future research on big data [2]

There are 3 important point in the protection of privacy for big data must be mentioned are: access control, auditing and statistical privacy [1] In particular, access control are interest aspects of this thesis Until now, several access control models have been proposed for the specification and enforcement of access control mechanisms such as Mandatory Access Controls (MAC), Discretionary Access Control (DAC), Role-based Access Control (RBAC) [29] and most recently Attribute-based Access Control (ABAC) [9] Because of the ability to control access higher require costs for the management and operation of the higher [1]; therefore, the current access control models have many difficulties when applied

to big

Authorization or access plays an important role in protecting sensitive information and preventing the attacker who is not granted any proper access The system is based on the security policy to determine an access request allow or deny But, in recent years, due to the growing popularity of big data has created a new challenge which the security policy management is facing such as dynamic policy, update policy in real time Application of dynamic policy has brought benefits to distributed systems, cloud systems, and social network However, there are no previous studies focused on solving authorization problems

in the dynamic policy In this thesis, we focus on analyzing the way of policy change and providing solutions in the dynamic policy environment The contribution of this thesis is two-fold: including the solution for changing policy even when the access request has been granted by the policy and we provide an XACML-based implementation that incorporates the rewriting request model Experiential results with real-world policies have established the practical and theoretical value of our newly introduced approach

Trang 7

Luận văn Thạc Sĩ VII HV: Hà Xuân Sơn – 1570226

LỜI CAM ĐOAN

Tôi cam đoan rằng, ngoại trừ các kết quả tham khảo từ các công trình khác như đã ghi rõ trong luận văn, các công việc trình bày trong luận văn cũng như các kết quả thực nghiệm

là do chính tôi thực hiện và chưa có phần nội dung nào của luận văn này được nộp để lấy một bằng cấp ở bất kì một trường nào khác

Ngày 29 tháng 12 năm 2017 Học viên thực hiện luận văn

Hà Xuân Sơn

Trang 8

Luận văn Thạc Sĩ VIII HV: Hà Xuân Sơn – 1570226

MỤC LỤC

LỜI CẢM ƠN IV TÓM TẮT LUẬN VĂN V ABSTRACT VI LỜI CAM ĐOAN VII MỤC LỤC VIII DANH MỤC HÌNH XI DANH MỤC BẢNG XIII

Chương 1 GIỚI THIỆU 1

1.1 Giới thiệu đề tài 1

1.2 Mục tiêu của đề tài 2

1.3 Ý nghĩa đề tài 2

1.4 Giới hạn của đề tài 2

1.5 Cấu trúc báo cáo 3

Chương 2 CƠ SỞ DỮ LIỆU NOSQL 5

2.1 Khái niệm cơ bản về dữ liệu lớn 5

2.2 Các mô hình dữ liệu NoSQL 5

2.2.1 Mô hình Key-Value 5

2.2.2 Mô hình Document Store 7

2.2.3 Mô hình Graph Databases 8

2.2.4 Mô hình Column Oriented 11

2.3 Lý do lựa chọn MongoDB 13

2.3.1 Bench Mark MongoDB với các CSDL khác 13

2.3.2 Mức độ phổ biến của MongoDB 17

2.3.3 Đánh giá cơ chế bảo mật hiện tại của MongoDB 19

Chương 3 ĐIỀU KHIỂN TRUY XUẤT 21

3.1 Bảo mật thông tin và tính riêng tư 21

3.2 Nhu cầu điều khiển truy xuất cho dữ liệu NoSQL 22

3.3 Khái niệm về điều khiển truy xuất 24

3.4 Các mô hình truyền thống 26

3.4.1 Mô hình điều khiển truy cập tùy quyền 26

Trang 9

Luận văn Thạc Sĩ IX HV: Hà Xuân Sơn – 1570226

3.4.2 Mô hình điều khiển truy cập bắt buộc 28

3.4.3 Mô hình điều khiển truy cập theo vai trò 29

3.5 Mô hình điều khiển truy xuất dựa trên thuộc tính 30

3.5.1 Giới thiệu mô hình ABAC 30

3.5.2 Mô hình ABAC 31

3.6 Mô hình điều khiển truy xuất XACML 33

3.6.1 Mô hình XACML 33

3.6.2 Chính sách và luật trong XACML 35

3.6.3 Đầu vào và đầu ra trong XACML 36

3.6.4 Giải thuật kết hợp trong XACML 37

3.7 Kết luận 39

Chương 4 CƠ SỞ LÝ THUYẾT VÀ CÁC CÔNG TRÌNH NGHIÊN CỨU LIÊN QUAN 40 4.1 Đánh giá chính sách 40

4.2 Satisfiability Modulo Theories (SMT) 41

4.3 Khái niệm chính sách bảo mật động 42

4.4 Ứng dụng của chính sách bảo mật động 43

4.5 Hướng giải quyết chính sách bảo mật động 43

4.5.1 Điều khiển truy cập động 43

4.5.2 Theo dõi sự thay đổi trên PIP 45

4.5.3 Rew-XAC model 46

Chương 5 KIẾN TRÚC HỆ THỐNG 48

5.1 Cấu trúc policy 48

5.1.1 Thành phần (Component) 48

5.1.2 Combining Algorithm 50

5.2 Cấu trúc request 52

5.2.1 Subject 52

5.2.2 Resource 52

5.2.3 Action 52

5.2.4 Environment 53

5.3 Kịch bản 53

5.4 Định dạng đầu vào hệ thống 54

Trang 10

Luận văn Thạc Sĩ X

HV:

HV: Hà Xuân Sơn – 1570226

5.4.1 Policy 54

5.4.2 Request 58

5.5 Cấu trúc đầu ra 58

5.6 Phân loại cập nhật chính sách 59

5.7 Mô hình tổng quan 62

5.8 Kiến trúc tổng quan 63

Chương 6 HIỆN THỰC HỆ THỐNG 67

6.1 Kiến trúc tổng quan hệ thống 67

6.2 Lược đồ lớp hệ thống 68

6.2.1 Lược đồ lớp biểu diễn chính sách 68

6.2.2 Lược đồ lớp biểu diễn cấu trúc đầu vào 69

6.2.3 Lược đồ lớp biểu diễn cấu trúc đầu ra 71

6.2.4 Lược đồ lớp biểu diễn quản lý cập nhật chính sách 72

6.2.5 Lược đồ lớp biểu diễn quá trình đánh giá 73

6.2.6 Lược đồ lớp biểu diễn viết lại câu truy vấn 74

6.3 Lược đồ lớp tuần tự 75

6.4 Giải thuật chính trong mô hình Rew – SMT 77

6.5 Công nghệ sử dụng 79

Chương 7 ĐÁNH GIÁ HỆ THỐNG 80

7.1 Chính sách bảo mật mẫu 80

7.2 Kết quả đánh giá 81

7.2.1 Xóa chính sách bảo mật 82

7.2.2 Cập nhật chính sách bảo mật 83

Chương 8 KẾT LUẬN 85

8.1 Đánh giá kết quả 85

8.2 Hướng phát triển đề tài 86

Danh mục các công trình khoa học 88

Tài liệu tham khảo 89

PHỤ LỤC A: Chuyển đổi Policy thành Applicable Constraint 93

PHỤ LỤC B: Các công trình khoa học 99

LÝ LỊCH TRÍCH NGANG 155

Trang 11

Luận văn Thạc Sĩ XI HV: Hà Xuân Sơn – 1570226

DANH MỤC HÌNH

Hình 2 1: Phân quyền mức dịch vụ SLA 6

Hình 2 2: Ví dụ về mô hình Graph Database 9

Hình 2 3: Điều khiển truy xuất trong mô hình Graph Database 10

Hình 2 4: Mô hình lưu trữ row-store và column-store 11

Hình 2 5: Tối ưu hiệu suất - Workload A – thông lượng 14

Hình 2 6 Tối ưu hiệu suất - Workload B – thông lượng 15

Hình 2 7 Tối ưu độ bền vững dữ liệu - Workload A – thông lượng 16

Hình 2 8 Tối ưu độ bền vững dữ liệu - Workload B – thông lượng 16

Hình 2 9: Tỷ lệ về mức độ phổ biến giữa các hệ quản trị cơ sở dữ liệu 18

Hình 3 1: Ba khía cạnh chính của bảo mật thông tin 21

Hình 3 2: Lượng dữ liệu số ước tính được sinh ra từ năm 2010 đến năm 2020 [35] 23

Hình 3 3: Khung điều khiển truy xuất tổng quát 25

Hình 3 4: Mô hình điều khiển truy cập tùy quyền 27

Hình 3 5: Ví dụ về trojan horse trên DAC 28

Hình 3 6: Mô hình điều khiển truy cập dựa trên vai trò 29

Hình 3 7: Đặc điểm các mô hình điều khiển truy xuất 30

Hình 3 8: Kịch bản của mô hình ABAC cơ bản 32

Hình 3 9: Thành phần và luồng xử lý XACML [19] 34

Hình 3 10: Cấu trúc chính sách trong XACML [19] 35

Hình 3 11: Ví dụ về chính sách trong XACML [19] 36

Hình 3 12: Ví dụ về đầu vào trong XACML [19] 37

Hình 3 13: Ví dụ về đầu ra trong XACML [19] 37

Hình 4 1: Situation-Oriented Authorization Architecture 44

Hình 4 2: Mô hình cập nhật thông tin trên PIP (Policy Information Point) 45

Hình 4 3: Rew-XAC Model [52] 46

Hình 4 4: Các bước thực hiện trong điều khiển truy xuất dữ liệu [53] 46

Hình 5.1: Mô hình cấu trúc chính sách bảo mật 48

Hình 5.2: Thành phần chính sách bảo mật 49

Hình 5.3: Công thức xác định Decision Space [61] 56

Hình 5 4: Trường hợp xóa policy 60

Hình 5 5: Tìm một policy thích ứng thay thế cho policy bị xóa 60

Hình 5 6: Tổng quan mô hình 62

Hình 5 7: Mô hình Rew-SMT 63

Hình 5 8: Luồng chạy tổng quan của hệ thống 65

Hình 6 1: Lược đồ thành phần 67

Hình 6 2: Lược đồ lớp biểu diễn chính sách bảo mật 69

Hình 6 3: Lược đồ lớp biểu diễn cấu trúc đầu vào – (Request) 70

Hình 6 4: Lược đồ lớp biểu diễn cấu trúc đầu vào – (Decision Space) 71

Hình 6 5: Lược đồ lớp biểu diễn cấu trúc đầu ra 72

Hình 6 6: Lược đồ lớp biểu diễn quản lý cập nhật chính sách 73

Hình 6 7: Lược đồ lớp của quá trình đánh giá truy cập 74

Trang 12

Luận văn Thạc Sĩ XII HV: Hà Xuân Sơn – 1570226

Hình 6 8: Lược đồ lớp của quá trình viết lại câu truy vấn 75

Hình 6 9: Lược đồ lớp của quá trình đánh giá câu truy vấn 76

Hình 6 10: Lược đồ lớp của quá trình viết lại câu truy vấn 77

Hình 7 1: So sánh hiệu suất giữa hai giải thuật tại trường hợp xóa chính sách 82

Hình 7 2: So sánh hiệu suất giữa hai giải thuật tại trường hợp cập nhật chính sách 84

Trang 13

Luận văn Thạc Sĩ XIII HV: Hà Xuân Sơn – 1570226

DANH MỤC BẢNG

Bảng 2 1: So sánh thời gian truy xuất của cơ sở dữ liệu quan hệ và Neo4j 9

Bảng 2 2: Tối ưu hiệu suất - Workload A - Độ trễ 15

Bảng 2 3: Tối ưu hiệu suất - Workload B - Độ trễ 15

Bảng 2 4: Tối ưu độ bền vững dữ liệu - Workload A – độ trễ 16

Bảng 2 5: Tối ưu độ bền vững dữ liệu - Workload B – độ trễ 17

Bảng 2 6: Các hệ quản trị phổ biến nhất hiện nay 18

Bảng 2 7: Các hệ quản trị theo mô hình Document Store phổ biến nhất hiện nay 19

Bảng 3 1: Kết quả khi kết hợp các Condition trong một Rule [19] 38

Bảng 3 2: Kết quả khi kết hợp các Rule trong một Policy [19] 38

Bảng 3 3: Kết quả khi kết hợp các Policy trong một PolicySet [19] 38

Bảng 5 1: Các ký hiệu sử dụng trong trài liệu 54

Bảng 5 2: Phân tích mức độ tương thích giữa request và policy 59

Bảng 5 3: Phân loại các dạng cập nhật của chính sách bảo mật 61

Bảng 7 1: Tập dữ liệu chính sách bảo mật 81

Bảng 7 2: Thời gian chi tiết phương thức đo đạc 83

Trang 14

Luận văn Thạc Sĩ 1 HV: Hà Xuân Sơn – 1570226

Chương 1 GIỚI THIỆU

1.1 Giới thiệu đề tài

Ngày nay, việc tăng trưởng các nhu cầu cung cấp dịch vụ thông qua các hệ thống phân tán, mạng xã hội hay các dịch vụ trực tuyến trên điện toán đám mây đã tạo ra một nhu cầu rất lớn cho việc phát triển hệ thống lưu trữ Các hệ thống lưu trữ hiện tại theo hướng cấu trúc

đã không còn đủ khả năng hỗ trợ các hệ thống này Các chuyên gia đều cho rằng các dữ liệu được lưu trữ dưới dạng cấu trúc chỉ chiếm khoảng gần 20% dữ liệu được lưu trữ cho các hệ thống bên ngoài [20], 80% còn lại được lưu trữ dưới dạng bán cấu trúc và không có cấu trúc Thuật ngữ dữ liệu không có cấu trúc ra đời nhằm mở ra một hướng mới cho công nghệ lưu trữ dữ liệu và cũng là tiền đề cho nhiều ngành khoa học có thể phát triển mạnh về sau

Dữ liệu không có cấu trúc được lưu trong các cơ sở dữ liệu NoSQL Đặc điểm chính của các mô hình này là: hỗ trợ tốt các loại dữ liệu từ có cấu trúc, bán cấu trúc đến không có cấu trúc Mô hình dữ liệu đơn giản, ngôn ngữ truy vấn dữ liệu đơn giản, khả năng mở rộng và

độ tin cậy cao Tuy nhiên cơ chế bảo mật còn thô sơ và đơn giản Bảo mật trong các mô hình này chủ yếu dựa trên: xác thực người dùng, mã hoá dữ liệu trước khi lưu trữ, tận dụng

cơ chế bảo mật của hệ thống file, phân quyền mức dịch vụ, hay gần đây nhất là hỗ trợ mô hình điều khiển truy xuất dựa trên vai trò

Với các đặc điểm về khối lượng lớn, tính đa dạng về mặt lưu trữ, sự phát triển liên tục của

dữ liệu không cấu trúc, thì việc bảo vệ dữ liệu trong các hệ thống này là vô cùng khó khăn Một trong những vấn đề bảo mật đang rất được lưu ý hiện nay là vấn đề điều khiển truy xuất Việc cung cấp quyền truy xuất cho dữ liệu ngày càng phức tạp, các mô hình điều khiển truyền thống như DAC, MAC, RBAC và những mở rộng của chúng gặp nhiều hạn chế và không còn phù hợp Đối với mô hình điều khiển truy xuất tùy quyền (DAC), dữ liệu có thể được truy cập trái phép bởi người dùng bởi vì không có điều khiển truy xuất trên bản sao chép của dữ liệu trong mô hình này Mặt khác trong mô hình điều khiển truy xuất bắt buộc (MAC) giải quyết vấn đề này bằng cách gán các cấp bậc bảo mật trên cả người dùng và dữ liệu, hệ thống áp dụng MAC phải có mức độ phân cấp ở phía người dùng

và dữ liệu Tất cả người dùng bắt buộc phải có một mức bảo mật nhất định mới có quyền truy cập dữ liệu và nhãn bảo mật được gán trên cả các bản sao chép Tuy nhiên các chính sách trong DAC và MAC thì cố định và không hỗ trợ điều khiển truy cập linh hoạt Cũng tương tự như hai mô hình trên, mô hình điều khiển truy xuất theo vai trò (RBAC) nảy sinh nhiều vấn đề hạn chế Bùng nổ vai trò (role) là một trong những vấn đề lớn nhất của RBAC, bởi vì mỗi vai trò đòi hỏi những tập quyền khác nhau và một số lượng lớn vai trò phải được khai báo

Trang 15

Một trong những nghiên cứu đang nổi lên là mô hình điều khiển truy xuất dựa trên thuộc tính (ABAC) Ưu điểm của mô hình này là hỗ trợ các chính sách điều khiển linh động, cho phép hỗ trợ các chính sách mịn hơn dựa trên các thuộc tính của người dùng, dữ liệu, các thông tin liên quan đến ngữ cảnh Tuy nhiên, mô hình này mới được phát triển mạnh ở nền tảng lý thuyết Trong ABAC cũng còn rất nhiều vấn đề cần phải nghiên cứu và phát triển thêm Một trong các vấn đề đang được chú trọng nghiên cứu là làm thế nào để có thể đảm bảo được tính bảo mật trong điều kiện chính sách bảo mật bị thay đổi và làm thế nào để đảm bảo được tính bảo mật đối với yêu cầu không đủ quyền truy cập trên dữ liệu lớn [21] Hay nói cách khác trong môi trường chính sách bảo mật động, chưa có một cơ chế hay nền tảng lý thuyết nào được nghiên cứu đúng mức Cho nên đề tài này, sẽ nghiên cứu mô hình điều khiển truy xuất cho dữ liệu NoSQL và thỏa mãn được các điều kiện ràng buộc về chính sách bảo mật động

1.2 Mục tiêu của đề tài

Như đã đề cập ở trên, mặc dù dữ liệu không có cấu trúc đang có vai trò vô cùng quan trọng trong việc phát triển hệ thống lưu trữ và ngày càng thu hút được sự quan tâm của các nhà nghiên cứu Tuy nhiên, các mô hình điều khiển truy xuất cho dữ liệu này vẫn còn nhiều hạn chế, chưa đạt đến độ mịn và linh động, đặc biệt trong môi trường chính sách động nơi

mà các chính sách bảo mật sẽ bị thay đổi theo thời gian nhằm đáp ứng các tính chất về đa dạng và độ lớn của dữ liệu lưu trữ Vì vậy mục tiêu của đề tài là nghiên cứu và đề xuất ra một mô hình điều khiển truy xuất cho dữ liệu NoSQL trong môi trường chính sách bảo mật động, xây dựng một cơ chế điều khiển truy xuất để đánh giá mô hình đã đề xuất

1.3 Ý nghĩa đề tài

Về mặt khoa học, đề tài nghiên cứu và đề xuất một mô hình điều khiển truy xuất mới cho

dữ liệu NoSQL Mô hình điều khiển truy xuất này còn có thể đáp ứng các yêu cầu bảo mật trong môi trường chính sách động

Về mặt thực tiễn, đề tài xây dựng một cơ chế điều khiển truy xuất động, dựa trên mô hình điều khiển và cơ chế điều khiển truy xuất này giúp nâng cao bảo mật trong việc quản lý dữ liệu NoSQL Đề tài cũng sử dụng tập mẫu được sử dụng ở ngoài đời thực để đo đạc và đánh giá tính khả dụng của mô hình

1.4 Giới hạn của đề tài

Đề tài tập trung vào việc xây dựng một mô hình điều khiển truy xuất giải quyết vấn đề chính sách bảo mật động cho dữ liệu NoSQL Việc xây dựng một cơ chế điều khiển để đánh giá mô hình được xây dựng trên một mô hình XACML v3.0 là một hiện thực của mô

Trang 16

hình điều khiển truy xuất dựa theo thuộc tính ABAC Cụ thể là trong đề tài này sẽ sử dụng

mô hình này áp dụng với lý thuyết SMT để làm tăng hiệu suất đánh giá câu truy vấn (tìm policy thích hợp cho câu truy vấn của người dùng) Để thỏa mãn đầu vào của một SMT Solver chúng tôi sẽ chuyển đổi định dạng ban đầu của chính sách bảo mật (XML format)

Về mô lưu trữ dữ liệu NoSQL, đề tài sẽ sử dụng mô hình Document Store, cụ thể ở trong tài liệu này là MongoDB

1.5 Cấu trúc báo cáo

Bài báo cáo chia làm 8 chương:

Chương 1 GIỚI THIỆU

Trình bày tổng quan về đề tài, mục tiêu của đề tài, ý nghĩa khoa học - thực tiễn, và giới hạn của đề tài

Chương 2 CƠ SỞ DỮ LIỆU NOSQL

Trình bày cơ sở lý thuyết, các mô hình cơ sở dữ liệu NoSQL và lý do áp dụng mô hình Document Store cho đề tài này Từ đó đưa ra lựa chọn MongoDB sẽ là cơ sở dữ liệu được áp dụng trong đề tài luận văn

Chương 3 ĐIỀU KHIỂN TRUY XUẤT

Trình bày cơ sở lý thuyết về điều khiển truy xuất, các mô hình điều khiển truyền thống

và mô hình điều khiển dựa trên thuộc tính ABAC Trình bày về XACML v3.0 là một hiện thực của mô hình ABAC và sẽ được áp dụng trong đề tài này

Chương 4 CƠ SỞ LÝ THUYẾT VÀ CÁC CÔNG TRÌNH NGHIÊN CỨU LIÊN QUAN

Trình bày khái niệm về lý thuyết SMT, chính sách bảo mật động (dynamic policy) Định nghĩa như thế nào là một hệ thống có hỗ trợ chính sách bảo mật động, các tiêu chí đánh giá Tóm tắt các nghiên cứu trước đây về đánh giá chính sách và đưa ra giải pháp cho chính sách bảo mật động

Chương 5 KIẾN TRÚC HỆ THỐNG

Trình bày các hướng tiếp cận của phương pháp đánh giá chính sách, cấu trúc của một chính sách bảo mật, cách chuyển đổi định dạng chính sách từ XML (XACML v3.0)

Trang 17

sang dạng input của SMT Solver Trình bày về mô hình và kiến trúc tổng quan của hệ thống

Chương 8 KẾT LUẬN

Trình bày tổng kết báo cáo, các giới hạn và hướng phát triển của đề tài

Trang 18

Chương 2 CƠ SỞ DỮ LIỆU NOSQL

Trong phần này tài liệu sẽ trình bày cơ sở lý thuyết, các mô hình cơ sở dữ liệu NoSQL và

lý do áp dụng mô hình Document Store cho đề tài luận văn Từ đó đưa ra lựa chọn MongoDB sẽ là cơ sở dữ liệu được áp dụng trong đề tài này

2.1 Khái niệm cơ bản về dữ liệu lớn

Dữ liệu lớn là dữ liệu có dung lượng (volume) dữ liệu khổng lồ, có tốc độ (velocity) được sinh ra lớn, và bao gồm nhiều kiểu (variety) dữ liệu khác nhau mà không thể được xử lý

hiệu quả bởi các công cụ dữ liệu truyền thống Ngoài ra, độ tin cậy và tính xác thực

(veracity) khi dữ liệu càng nhiều và bị nhiễu, sự không thống nhất, nhu cầu quản lý và xác

thực dữ liệu càng tăng theo Do đó, tính chất này là một điều kiện cần thiết để tạo ra chất lượng dữ liệu làm tăng độ chính xác cho các ứng dụng, đặc biệt các ứng dụng phân tích và

ra quyết định dựa trên dữ liệu lớn Phần tiếp theo sẽ trình bày tóm tắt các mô hình dữ liệu NoSQL cùng với các hệ thống quản lý dữ liệu lớn đang có trong thực tế

2.2 Các mô hình dữ liệu NoSQL

2.2.1 Mô hình Key-Value

Cấu trúc lưu trữ của mô hình Key-Value (khoá-giá trị) là sự ánh xạ một giá trị nội dung

thuộc kiểu bất kì (có thể có cấu trúc, bán cấu trúc hay không có cấu trúc) vào một khoá Khoá này có thể thuộc một kiểu bất kì (có/bán hoặc không có cấu trúc) Vì vậy, giá trị của khoá và nội dung lưu trữ có thể rất đa dạng, từ các kiểu cơ bản như byte, integer, float, double,… đến các kiểu phức tạp như XML, JSON,… hay file hình ảnh, âm thanh, video

Mô hình Key-Value rất thích hợp để lưu trữ dữ liệu lớn vì tính đa dạng (từ có/bán đến

không cấu trúc), dễ dàng mở rộng dung lượng lưu trữ khi cần thiết (như trong hệ thống Hadoop [9] ta chỉ cần thêm vào một máy tính nào đó), và khả năng lưu trữ dữ liệu với tốc

độ cao (vì cơ chế lưu trữ rất đơn giản và trực tiếp, thêm vào nhanh)

Mô hình Key-Value rất phổ biến trong công nghệ NoSQL đang được ứng dụng nhiều trong

các hệ thống dữ liệu lớn [1] Tuy nhiên, các cơ chế bảo mật cho mô hình dữ liệu Key-Value hiện tại vẫn còn rất thô sơ và đơn giản Bảo mật trong mô hình này chủ yếu dựa trên 3 yếu

tố chính sau đây:

• Xác thực: Các kỹ thuật xác thực người dùng, chủ thể sử dụng dữ liệu đang có

Trang 19

• Mã hoá dữ liệu: Các dữ liệu mang tính nhạy cảm, cần bảo mật sẽ được mã hoá

trước khi lưu trữ xuống Tuy nhiên quá trình mã hoá này phải nhanh, không ảnh hưởng nhiều đến tốc độ và hiệu suất của hệ thống

• Tận dụng cơ chế bảo mật của hệ thống file sẵn có: Do thông thường các bộ

Key-Value sẽ được lưu trữ thành file, do đó hệ thống lưu trữ sẽ phân quyền cho các file này ngay tại thời điểm ghi xuống

Sau đây ta xem xét hai ví dụ về công nghệ điển hình cho mô hình lưu trữ Key-Value là Hadoop [9] và Redis [10]

Hadoop : Cơ chế bảo mật của Hadoop về cơ bản dựa trên 3 yếu tố chính sau đây

• Xác thực người dùng bằng công nghệ Kerberos

• Phân quyền file HDFS (Hadoop File System) Đây là một hệ thống file phân quyền theo chuẩn POSIX Khi ghi xuống hệ thống sẽ xác định owner (chủ sở hữu) và group (nhóm sở hữu) của file Một bộ quyền hạn trên file được xác lập bao gồm quyền đọc (read), ghi (write) và thực thi (execute) cho owner, group và tất cả còn lại

• Phân quyền mức dịch vụ (Service Level Authorization, SLA) Một hệ thống Hadoop bao gồm nhiều dịch vụ nhỏ, như Map, Reduce, Datanode,… SLA cho phép người quản trị phân quyền sử dụng các dịch vụ này cho từng người dùng (hiểu rộng ra là người dùng, tiến trình hoặc bất kì thành phần chủ động nào trong hệ thống) Sau đây

là hai ví dụ minh hoạ cụ thể cho việc gán quyền SLA

Trong ví dụ như hình 2.1 về phân quyền, người dùng Alice, Bob và nhóm Mapreduce được phép thực thi các hàm map-reduce

Hình 2 1: Phân quyền mức dịch vụ SLA

Redis: Redis là hệ thống lưu trữ Key-Value trên bộ nhớ chính (in-memory keyvalue

storage) Cơ chế bảo mật của Redis rất thô sơ, chỉ cho phép xác thực người dùng [10], và

không có cơ chế điều khiển truy xuất mịn hơn (như SLA của Hadoop) Ngoài ra, Redis

khuyến khích ta mã hoá các dữ liệu nhạy cảm trước khi lưu trữ để tăng cường tính bảo mật

Trang 20

2.2.2 Mô hình Document Store

Trong mô hình này, khái niệm document là để chỉ một nội dung có cấu trúc, bán cấu trúc

hoặc không có cấu trúc Ví dụ của document có thể rất đa dạng, như JSON, BSON, XML, YAML hay phức tạp hơn là các file Word, Excel, PDF,… Ta có thể xem mô hình

Document Store là một bản cải tiến của mô hình Key-Value Khi các bộ Key-Value có

thêm thuộc tính ngữ nghĩa hoặc siêu dữ liệu đến một mức độ nhất định, ta có thể gom nhóm

các bộ key-value thành một document

Việc gom nhóm đó ta có thể thực hiện theo 4 phương thức chính sau đây

• Gom nhóm thành Collections, tức là ta gom nhóm một cách chủ động, người dùng

hoặc chương trình trong quá trình chạy sẽ gom nhóm trực tiếp các dữ liệu liên quan

• Gom nhóm theo Tags, các nội dung sẽ được gán các tags, sau đó các dữ liệu sẽ

gom nhóm thành document theo các tags

• Gom nhóm theo các siêu dữ liệu vô hình (Non-visible Metadata)

• Gom nhóm thành cấu trúc phân cấp (Directory Hierachies)

Mô hình Document Store thích hợp với các hệ thống lưu trữ Big Data phần nào coi trọng tính ngữ nghĩa của dữ liệu (khác với mô hình Key-Value, đơn thuần chỉ là lưu trữ dữ liệu)

Ví dụ, mô hình Key-Value lưu trữ các log file (web/game/application logs,…) còn mô hình Document Store có thể ứng dụng trong lưu trữ các status của một mạng xã hội, tweet,

comments,…

Do đặc tính có thêm ngữ nghĩa của document trong Document Store, cơ chế bảo mật của

mô hình này được nâng cao hơn, uyển chuyển và mịn hơn so với mô hình Key-Value

Ngoài các cơ chế bảo mật cơ bản như xác thực người dùng, mã hoá dữ liệu, ta có thể áp

dụng các cơ chế điều khiển truy xuất cơ bản cho mô hình Document Store (như RBAC),

hoặc cung cấp cơ chế cho phép người lập trình thực hiện điều khiển truy xuất tuỳ chỉnh trên dữ liệu lưu trữ [3,4,13,14,15] Tuỳ theo công nghệ hiện thực mà mức độ nâng cao này cũng khác nhau Ta xem xét hai ví dụ về công nghệ sau đây để tham khảo rõ hơn về vấn

đề này

MongoDB : MongoDB lưu trữ một collection dưới định dạng BSON, mỗi một collection

được xem như một “database” và người lập trình/ quản trị viên có thể cài đặt điều khiển truy xuất ở mức độ database trong hệ thống Mô hình điều khiển truy xuất được áp dụng trong MongoDB là RBAC Mỗi người dùng (tiến trình, thành phần chủ động) sẽ được gán

vào một role Trong MongoDB, có 3 nhóm role [11]: Read (chỉ đọc), ReadWrite (đọc và ghi) và Admin (quản trị) Mỗi role cung cấp cho người dùng một danh sách các quyền truy

Trang 21

xuất trên một database luận lý cụ thể Một người dùng có thể có nhiều role trên nhiều database luận lý Một giới hạn của RBAC trong MongoDB là role khi được uỷ thác cho người dùng, ta không thể tuỳ chỉnh giảm bớt quyền trong role đó đối với người dùng đã được cấp

CouchDB : CouchDB [12] là kho lưu trữ dữ liệu document dưới dạng JSON, đặc biệt được

thiết kế cho ứng dụng WebService hoặc REST-API Vì đặc thù ứng dụng Web, nên CouchDB cung cấp cơ chế xác thực người dùng qua 3 phương thức OAuth, HTTP và Basic [12] Về điều khiển truy xuất, tương tự như MongoDB, CouchDB điều khiển truy xuất theo

mô hình RBAC Mỗi người dùng dữ liệu (gồm cả các tiến trình, thành phần chủ động dùng

dữ liệu) sẽ được gán role thuộc 3 nhóm sau đây:

• DB Members có quyền Read (+Write) trên một database

• DB Admin có toàn quyền trên một database

• Server Admin có toàn quyền trên tất cả database

Ngoài ra, CouchDB cung cấp một cơ chế cho phép điều khiển truy xuất ở mức mịn hơn, nhưng đòi hỏi người lập trình phải tốn công sức lập trình Đó là cơ chế kiểm định dữ liệu

thông qua hook validate_doc_update [12]

2.2.3 Mô hình Graph Databases

Hệ quản trị Graph database [7] là một hệ cơ sở dữ liệu trực tuyến hỗ trợ xử lý các giao tác

trực tuyến (OLTP) và các tác vụ CRUD (Create, Read, Update, và Delete) Graph được tạo thành từ các nốt (nodes), quan hệ (relationships) và thuộc tính (attributes)

• Node chứa các thuộc tính Các thuộc tính này được lưu trữ như các tài liệu (document) Nội dung của tài liệu là tập hợp các cặp khóa – giá trị (key – value)

Key có kiểu giá trị chuỗi và value có thể lưu bất kỳ kiểu giá trị nào

• Relationship kết nối và cấu trúc các node Một relationship luôn có hướng, có tên,

có node bắt đầu và node kết thúc Các thông tin này làm rõ thêm ngữ nghĩa cấu trúc

node của đồ thị Relationship cũng có các thuộc tính Các thuộc tính này sẽ cung

cấp thêm thông tin hỗ trợ cho các giải thuật đồ thị, thêm ngữ nghĩa cho đồ thị (như thông tin lượng số hay trọng số), và thêm thông tin cho các truy vấn trong thời gian thực thi

Bằng cách kết hợp các node trừu tượng và các các quan hệ với nhau trong những cấu trúc

kết nối, Graph database cho phép chúng ta tạo ra các mô hình phức tạp nhưng gần với

Trang 22

các vấn đề thực tế Các mô hình này sẽ đơn giản hơn và dễ hiểu hơn các mô hình được tạo

ra bằng cơ sở dữ liệu quan hệ Một ví dụ minh họa được thể hiện trong hình 2.2 bên dưới

Hình 2 2: Ví dụ về mô hình Graph Database

Về cấu trúc lưu trữ dữ liệu, Graph database sử dụng cách lưu trữ tự nhiên của đồ thị Điều

này giúp tối ưu cho lưu trữ, hiệu suất, mở rộng và quản lý đồ thị Hiệu suất xử lý của cấu trúc lưu trữ này sẽ được nâng cao khi xử lý các tác vụ cần phải di chuyển qua các node trên

đồ thị nhưng sẽ không tốt khi các truy vấn không di chuyển hay cần nhiều bộ nhớ Tuy nhiên, không phải tất cả các Graph database đều sử dụng cách lưu trữ dạng đồ thị Các cơ

sở dữ liệu này ánh xạ dữ liệu vào cơ sở dữ liệu quan hệ (My Sql), hoặc cơ sở dữ liệu hướng đối tượng, hoặc các mô hình lưu trữ dữ liệu cho mục đích chung (không hướng đồ thị) Bảng sau so sánh thời gian truy xuất của Graph database xây dựng dựa trên cơ sở dữ liệu quan hệ và cơ sở dữ liệu dạng đồ thị (Neo4j [16])

Số lượng node Thời gian truy xuất

Cơ sở dữ liệu quan hệ 1.000 2000ms

Bảng 2 1: So sánh thời gian truy xuất của cơ sở dữ liệu quan hệ và Neo4j

Giải pháp điều khiển truy xuất trong graph database cho phép xác định:

• Các loại tài nguyên (như cấu trúc công ty, các sản phẩm, các dịch vụ, người dùng cuối,…) mà người quản trị có thể quản lý

Trang 23

• Loại tài nguyên nào mà người dùng cuối có thể truy cập

• Với một tài nguyên, xác định người có thể thay đổi cấu hình truy xuất

Hình dưới đây minh họa một cấu trúc điều khiển truy xuất 2 cấp được dùng để quản lý tài nguyên con người, nhân viên trong công ty Cấp thứ nhất gồm những người quản trị được gán vào các nhóm (group) Nhóm có các quyền khác nhau và liên kết đến thành viên trong

tổ chức để tạo thành cấp thứ hai Các thành viên của tổ chức cũng liên kết với nhau bằng quan hệ cha con

Hình 2 3: Điều khiển truy xuất trong mô hình Graph Database

Các quyền của group bao gồm:

• ALLOWED_INHERIT kết nối người X quản trị một nhóm đến một thành viên Y

của tổ chức và cho phép người X quản lý các thành viên con của thành viên X Ví

dụ Ben quản lý Group 1 thì anh ta sẽ quản lý Acme và các thành viên con của Acme (Arnold, Charlie,…)

• ALLOWED_DO_NOT_INHERIT kết nối một người X là quản trị nhóm đến một

thành viên Y của tổ chức và nhưng không cho phép X quản lý các thành viên con của thành viên Y Sarah quản lý Group 2 thì Sarah quản lý Acme nhưng không quản

lý các thành viên con của Acme

Trang 24

• DENIED cấm người quản trị truy cập vào một thành viên của tổ chức Mặc dù thành

viên Skunkworkz là con của thành viên Startup, Sarah quản lý Group 3 và thành viên Startup nhưng không thể truy cập Skunkworkz do bị DENIED

Neo4J [16] là một hệ thống mã nguồn mở quản lý dữ liệu dạng đồ thị thay vì dạng bảng

Các node trong Neo4j được kết nối trực tiếp bằng các quan hệ Cả node và quan hệ đều có thuộc tính Neo4j hỗ trợ điều khiển truy xuất của đồ thị hoặc người dùng cấu hình theo mô

hình Access control list (ACL) ACL là tập hợp các quyền được gán với một đối tượng

ACL xác định những người dùng hay quá trình được gán quyền truy xuất đến các đối tượng cũng như những hành động được phép thực hiện trên đối tượng đó [13,14,15]

OrientDB [17] là một hệ cơ sở dữ liệu NoSQL mã nguồn mở được viết bằng Java

OrientDB là cơ sở dữ liệu thuộc mô hình Document nhưng quan hệ được quản lý như Graph database với các kết nối trực tiếp giữa các record OrientDB bảo mật dựa trên người dùng, vai trò và hỗ trợ truy vấn SQL

2.2.4 Mô hình Column Oriented

Hệ quản trị cơ sở dữ liệu hướng cột lưu trữ các bảng dữ liệu thành các cột, khác với cơ sở

dữ liệu quan hệ lưu thành các dòng Mô hình dữ liệu lớn này phù hợp với các ứng dụng chỉ đọc dữ liệu, đọc dữ liệu với cường độ lớn, dữ liệu lớn (như các kho dữ liệu, các hệ thống quản lý quan hệ khách hàng (CRM)), hay các hệ thống cần tính toán tổng hợp từ lượng lớn mục dữ liệu tương tự nhau Hình sau minh họa cấu trúc lưu trữ dữ liệu khác nhau giữa mô hình dữ liệu quan hệ (row store) và mô hình dữ liệu hướng cột (column store):

Hình 2 4: Mô hình lưu trữ row-store và column-store

Ví dụ bảng dữ liệu sau:

Trang 25

Trong hệ thống hướng dòng, dữ liệu sẽ được xếp theo thứ tự như sau:

001:10,Smith,Joe,40000;002:12,Jones,Mary,50000;003:11,Johnson,Cathy,44000;004:22,Jones,Bob,55000;

Chỉ số dòng (rowId) được dùng để ánh xạ đến dòng dữ liệu (rowId = 001 ánh xạ đến dữ liệu dòng một là “10, Smith, Joe, 40000”) Nhưng với hệ thống hướng cột thì dữ liệu được lưu theo từng cột và giá trị dữ liệu sẽ ánh xạ ngược lại chỉ số dòng (giá trị Smith ánh xạ đến rowId = 001)

10:001,12:002,11:003,22:004;Smith:001,Jones:002,Johnson:003,Jones:004;Joe:001,Mary:002,Cathy:003,Bob:00 4;40000:001,50000:002,44000:003,55000:004;

Các dữ liệu có cùng kiểu được lưu trữ với nhau nên làm tăng khả năng nén dữ liệu, tối ưu chi phí lưu trữ Tỉ lệ nén dữ liệu từ 10:1 đến 30:1 Ngoài ra, với một bảng lớn có 1 triệu dòng, mỗi dòng cần trung bình 1024 byte, một ô cần 8 byte lưu trữ, khi đó tính toán trên chỉ một cột của bảng chúng ta chỉ cần đọc 8 MB cho trường hợp dữ liệu lưu trữ hướng cột thay vì 1 GB như với dữ liệu được lưu trữ trong các RDBMS truyền thống

Bảo mật và điều khiển truy xuất không được chú ý nhiều trong các cơ sở dữ liệu hướng cột, thường chỉ hỗ trợ Access control list [1,2]

Cassandra [18] là một hệ cơ sở dữ liệu phân tán mã nguồn mở, cung cấp cấu trúc lưu trữ

dạng key-value Các key được ánh xạ đến nhiều giá trị (column) Những giá trị này được nhóm lại thành các column family Bốn khái niệm cơ bản trong Cassandra là:

• Column là đơn vị dữ liệu nhỏ nhất trong Cassandra, gồm có name, value và

timestamp Ví dụ:

{ name: “country”, value: “vietnam”,

Trang 26

timestamp: 123456789 }

• Supper column là column có value là 1 danh sách các column Supper column

không có timestamp Ví dụ:

{ name: "myAddress", value: {

street: {name: "street", value: "123 xyz", timestamp: 123456789}, city: {name: "city", value: "HCMC", timestamp: 123456789}, }

}

• Column family là tập hợp các columns Nó như là table trong các RDBMS Mỗi

row trong 1 column family bao gồm key và các column gắn liền với key đó Column family sẽ được sắp xếp theo key Các column family được cố định khi cơ sở dữ liệu Cassandra được tạo ra, nhưng các cột có thể thêm vào family bất cứ khi nào Ngoài

ra, trong cùng một family, các cột gắn với một số khóa cụ thể, do đó các khóa khác nhau sẽ có số cột khác nhau

• Keyspaces là tập hợp các column family Thông thường mỗi ứng dụng có riêng một

keyspaces Chúng ta có thể liên tưởng keyspaces với schema trong các RDBMS

HBase [8] là hệ quản trị cơ sở dữ liệu phân tán dạng cột, mã nguồn mở, dựa trên mô hình

BigTable của Google HBase hỗ trợ nén dữ liệu, xử lý trên bộ nhớ (in-memory), cho phép lưu trữ các bảng dữ liệu rất lớn (nghìn tỉ dòng x triệu cột) và cung cấp khả năng truy xuất (đọc/ghi) thời gian thực trên dữ liệu lớn Từ các phiên bản 0.92 trở đi, HBase hỗ trợ bảo vệ tài nguyên dựa trên ACL Để thiết lập ACL, HBase phải được cấu hình để bảo mật truy cập từ khách hàng đến HBase [7] và cấu hình ZooKeeper để thực thi bảo mật Những thay đổi ACL được đồng bộ cả hệ thống máy tính thông qua ZooKeeper Ngoài ra, xác thực bảo mật đến ZooKeeper cũng phải được thiết lập để tránh bị tấn công HBase thông qua ZooKeeper

2.3 Lý do lựa chọn MongoDB

2.3.1 Bench Mark MongoDB với các CSDL khác

Mỗi cơ sở dữ liệu NoSQL cung cấp cho người dùng những tính năng khác nhau, từ mô hình dữ liệu, hiệu suất, khả năng mở rộng Để chọn được cơ sở dữ liệu phù hợp cho bài toán cụ thể thì phải xem xét đánh giá nhiều yếu tố: hiệu suất, chức năng, công cụ hoạt động, mức độ dễ sử dụng, hệ sinh thái công nghệ đi kèm, kiểm soát an ninh, độ tin cậy Trong đó hiệu suất là một trong những yếu tố quan trọng nhất

Trang 27

Hiện tại Cassandra, Couchbase, và MongoDB là những cơ sở dữ liệu NoSQL được sử dụng thông dụng nhất Để đánh giá 3 cơ sở dữ liệu này, các tác giả của [32] sử dụng một chuẩn công nghiệp được tạo ra bởi Yahoo là YCSB

Hầu hết các cơ sở dữ liệu, hiệu suất được giới hạn bởi tốc độ của hệ thống lưu trữ hoặc là

về số lượng yêu cầu có thể thực hiện, độ trễ khi thực thi một yêu cầu Hơn nữa, hiệu suất còn bị giới hạn bởi yêu cầu về độ bền vững của dữ liệu Đối với các cơ sở dữ liệu NoSQL, khi xử lý các yêu cầu, dữ liệu sẽ được lưu tạm trên bộ nhớ chính, và được lưu xuống hệ thống lưu trữ định kỳ sau đó Nếu hệ thống ngưng hoạt động đột ngột trước khi dữ liệu được lưu xuống hệ thống lưu trữ

Các hệ thống đều cho phép người dùng điều chỉnh mức độ bền vững của dữ liệu Để đảm bảo mức độ bền vững càng cao thì hiệu suất sẽ càng thấp Trong bài báo, các tác giả đánh giá các NoSQL trong cả hai trường hợp: tối ưu hiệu suất, tối ưu độ bền vững dữ liệu

a) Tối ưu hiệu suất

Hình 2 5: Tối ưu hiệu suất - Workload A – thông lượng

Đối với cấu hình này, không sử dụng WAL cho các cơ sở dữ liệu Do đó nếu máy chủ bị

hư, tắt đột ngột trước khi dữ liệu được lưu xuống hệ thống lưu trữ, dữ liệu sẽ bị mất Cấu hình này chỉ phù hợp một số ít ứng dụng trong thực tế

Với một cấu hình tối ưu hóa cho thông lượng, 50/50 khối lượng công việc trong các thử nghiệm chứng tỏ rằng MongoDB cung cấp thông lượng cao hơn khoảng 50% so với Couchbase, và thông lượng lớn hơn khoảng 20% so với Cassandra Độ trễ nằm trong một phạm vi hẹp cho cả ba cơ sở dữ liệu

Trang 28

Bảng 2 2: Tối ưu hiệu suất - Workload A - Độ trễ

Hình 2 6 Tối ưu hiệu suất - Workload B – thông lượng

Bảng 2 3: Tối ưu hiệu suất - Workload B - Độ trễ

Với cấu hình tối ưu hóa cho thông lượng, khối lượng công việc đọc lớn (95% thao tác đọc) cho thấy MongoDB cung cấp thông lượng cao hơn khoảng 35% so với Cassandra, và thông lượng tốt hơn một chút so với Couchbase Như với 50/50 khối lượng công việc, thời gian trễ nằm trong một phạm vi hẹp tương tự như trên các cơ sở dữ liệu

b) Tối ưu độ bền vững dữ liệu

Cấu hình tối ưu hóa cho độ bền, 50/50 khối lượng công việc trong các thử nghiệm chứng

tỏ rằng MongoDB cung cấp hơn thông lượng lớn hơn 25 lần Couchbase và 5 lần Cassandra Các thông thấp quan sát cho tất cả các hệ thống khi so sánh với các kết quả cho các cấu

Trang 29

hình thông tối ưu hóa là một kết quả của từng hoạt động viết chờ ghi xác nhận đã được tiếp tục lưu vào đĩa

Hình 2 7 Tối ưu độ bền vững dữ liệu - Workload A – thông lượng

Bảng 2 4: Tối ưu độ bền vững dữ liệu - Workload A – độ trễ

Hình 2 8 Tối ưu độ bền vững dữ liệu - Workload B – thông lượng

Trang 30

Bảng 2 5: Tối ưu độ bền vững dữ liệu - Workload B – độ trễ

Độ trễ là tương đối thấp đối với cả ba cơ sở dữ liệu cho đọc dữ liệu, nhưng độ trễ cho các thao tác cập nhật dữ liệu là tương đối lớn, nhưng độ trễ của MongoDB 5ms vần còn chấp nhận được, so với 41ms của Casandra và 203ms của Couchbase

Thông qua việc chạy các NoSQL với các cấu hình khác nhau, các tác giả cho thấy MongoDB cung cấp hiệu suất lớn hơn Couchbase hoặc Cassandra trong tất cả các cấu hình, trong một số trường hợp là 25 lần MongoDB cung cấp sự linh hoạt để đảm bảo độ bền cho các hoạt động cụ thể: người sử dụng có thể lựa chọn cấu hình tối ưu độ bền cho các hoạt động cụ thể được coi là quan trọng nhưng mà thời gian trễ thêm là chấp nhận được Đối với Cassandra thay đổi này đòi hỏi phải chỉnh sửa cấu hình và khởi động lại toàn bộ cơ sở

dữ liệu Đối với Couchbase, người dùng phải lựa chọn giữa thông lượng cao với khả năng mất mát đáng kể dữ liệu, hoặc không mất dữ liệu tiềm năng với thông lượng thấp và độ trễ rất cao

2.3.2 Mức độ phổ biến của MongoDB

Để đánh giá mức độ phổ biến của MongoDB so với các hệ quản trị cơ sở dữ liệu khác chúng tôi đánh giá trên hai tiêu chí Thứ nhất là mức độ phổ biến của MongoDB so với toàn bộ hệ quản trị cơ sở dữ liệu khác Thứ hai là mức độ phổ biến của MongoDB so với những hệ quản trị theo mô hình Document-Store Phương thức đánh giá mức độ phổ biến chúng tôi áp dụng theo cơ chế đánh giá của [33] như sau:

• Số lượng tìm kiếm <Tên hệ thống> và từ khóa “dữ liệu”: thông qua

website tìm kiếm: được đo đạc bằng số kết quả trả về thông qua các trang web tìm kiếm phổ biến hiện nay như: Google (https://www.google.com), Bing (https://www.bing.com/), và Yandex (https://www.yandex.com/) Để loại bỏ các kết quả không cần thiết họ áp dụng phương thức tính toán trên <system name> và từ khóa bắt buộc “database” Ví dụ "Oracle" và "database"

• Xu hướng của hệ thống: Để có được số liệu này họ lấy số liệu thông qua việc tìm

kiếm các từ khóa trên Google Trends (https://trends.google.com.vn/trends/)

• Tần suất thảo luận về các vấn đề kỹ thuật của hệ thống: Họ tính toán dựa trên

số lượng các thảo luận (thắc măc – trả lời) và số lượng người dùng quan

Trang 31

tâm trên các diễn đàn Q&A nổi tiếng về công nghệ thông tin phải kể đến như Stack Overflow (https://stackoverflow.com/) và DBA Stack Exchange (https://dba.stackexchange.com/)

• Số lượng việc làm: nơi mà các hệ thống này được đề cập, họ sử dụng số liệu từ các

website giới thiệu việc làm hàng đầu hiện nay như: Indeed (https://vn.indeed.com/)

và Simply Hired (https://www.simplyhired.com/)

• Số lượng profile từ các hệ thống lý lịch nghề nghiệp: nơi mà các hệ thống

này được nhắc đến Số liệu này được lấy từ các website như: LinkedIn (https://www.linkedin.com/) và Upwork (https://www.upwork.com/)

• Sự liên quan trong các mạng xã hội: họ đếm số lượng các Twitter tweets

Thông qua các số liệu thu thập được từ các cách nêu trên, họ sẽ tổng kết mỗi tháng và đưa

ra bảng xếp hạng các hệ quản trị cơ sở dữ liệu đang phổ biến hiện nay

Bảng 2 6: Các hệ quản trị phổ biến nhất hiện nay

Hình 2 9: Tỷ lệ về mức độ phổ biến giữa các hệ quản trị cơ sở dữ liệu

Nhìn vào bảng 2.6 ta thấy rằng dữ liệu quan hệ (Relational DBMS – (R-DBMS)) đang áp đảo các mô hình dữ liệu NoSQL Ở trong top 10 hệ quản trị phổ biến nhất này thì có đến 6

hệ quản trị thuộc nhóm R-DBMS Tuy nhiên, so với tốc độ phát triển và sự ra đời giữa các

Trang 32

mô hình dữ liệu NoSQL so với R-DBMS thì MongoDB đang ngày càng phát triển và có tốc độ phổ biến ngày càng tăng So với các mô hình dữ liệu NoSQL khác thì Document Sotre cũng là mô hình được ứng dụng nhiều và rộng rãi nhất thể hiện qua hình 2.9

Bảng 2 7: Các hệ quản trị theo mô hình Document Store phổ biến nhất hiện nay

Về mức độ phổ biến riêng về mô hình Document store thì MongoDB đứng đầu và bỏ xa các hệ quản trị khác, thể hiện trong bảng 2.7

2.3.3 Đánh giá cơ chế bảo mật hiện tại của MongoDB

MongoDB sử dụng một điều khiển truy xuất cơ bản dựa trên mô hình điều khiển truy xuất dựa trên vai trò RBAC nhằm vào việc quản trị quyền truy xuất dữ liệu vào hệ thống MongoDB Người dùng sẽ được cấp sẵn một hay nhiều quyển (ROLE), các quyền này bao gồm các việc chấp nhận người sử dụng truy xuất vào môi trường CSDL và thao tác trên

đó Bên cạnh đó việc gán quyền cũng sẽ ngăn chặn người dùng truy cập vào hệ thống

MonogDB không hỗ trợ việc “Cấp quyền” (Authority) dưới dạng mặc định Nghĩa là để kích hoạt chức năng Authority thông qua việc sử dụng auth hoặc lựa chọn keyFile, hay một cách khác nếu chúng ta sử dụng cấu hình file có sẵn với secutity.authorization hoặc security.keyFile MongoDB cung cấp các vai trò mặc định nhằm cung cấp các chức năng thông thường hay sử dụng của một người dùng bình thường Ví dụ các chức năng read, readWrite, dbAdmin và root

Người quản trị hệ thống hoàn toàn có thể tạo mới một vai trò và gán vào đó các quyền

(previleges) cũng như các “chức năng” (Operation) cần thiết Người quản trị cũng có thể gán các vai trò với các quyền theo từng mục đích riêng biệt (scoped) ví dụ như gán quyền

theo từng mức độ của các Collection

Trang 33

Người dùng có thể được gán nhiều vai trò trong cùng một thời điểm: giả sử người dùng nhận được tất cả các quyền có thể từ vai trò bất kỳ, tuy nhiên họ cũng sẽ có một phân vùng

quyền khác (một vài trò khác) ngay tại thời điểm đó Thì ứng với từng thời điểm cụ thể hoặc ràng buộc cụ thể thì người dùng sẽ có các quyền đặc trưng trên các đối tượng được truy xuất

Trang 34

Chương 3 ĐIỀU KHIỂN TRUY XUẤT

Trong phần này tài liệu sẽ trình bày cơ sở lý thuyết về điều khiển truy xuất, các mô hình điều khiển truyền thống và mô hình điều khiển dựa trên thuộc tính ABAC Trình bày về XACML v3.0 là một hiện thực của mô hình ABAC và sẽ được áp dụng trong đề tài này

3.1 Bảo mật thông tin và tính riêng tư

Trước khi tìm hiểu sâu hơn về điều khiển truy xuất tổng quát nói chung và cho dữ liệu NoSQL nói riêng, ta cần có cái nhìn tổng quát về bảo mật thông tin và tính riêng tư, cũng như cách kết hợp hai khía cạnh này để bảo đảm tính an toàn cho thông tin

Bảo mật thông tin được xem là một cơ chế để bảo vệ dữ liệu Thông thường, bảo mật thông tin được hiểu là cách hiện thực công nghệ trong các hệ thống IT để bảo vệ dữ liệu được lưu Trên thực tế, bảo mật thông tin bao gồm việc bảo vệ dữ liệu dưới tất cả các hình thức (dữ liệu số, dữ liệu giấy hay các hình thức khác) [34] Bảo mật thông tin cũng bao gồm việc bảo vệ dữ liệu khỏi bất kỳ hình thức tấn công bên ngoài lẫn bên trong hệ thống Khi xét đến bảo mật thông tin, ta cần xét đến ba khía cạnh chính sau:

Hình 3 1: Ba khía cạnh chính của bảo mật thông tin

• Tính bảo mật (Confidentiality): có nghĩa là bảo vệ dữ liệu, trong tất cả các tình

huống truy cập trái phép trong suốt toàn bộ vòng đời của một dữ liệu (từ lúc tạo dữ liệu đến hủy dữ liệu) Truy cập trái phép bao gồm truy cập bởi các cá nhân không liên kết với các tổ chức cơ bản lưu trữ dữ liệu (ví dụ, bọn tội phạm và tin tặc) Nó cũng bao gồm quyền truy cập của các cá nhân trong một tổ chức người cố tình vượt quá phạm vi của họ về quyền tiếp cận thông tin (ví dụ, cá nhân tìm kiếm các hồ sơ

Trang 35

của người nổi tiếng hay các cá nhân có mục tiêu khác khi họ có lý do chính đáng không chuyên nghiệp để làm như vậy)

• Tính toàn vẹn (Integrity): nghĩa là đảm bảo rằng dữ liệu trong hệ thống là chính

xác Điều này có nghĩa là hệ thống khởi tạo và quản lý dữ liệu thực hiện các điều khiển trong hệ thống để đảm bảo rằng người dùng nhập và xử lý dữ liệu một cách chính xác; bên cạnh đó các mâu thuẫn trên dữ liệu được xác định và giải quyết

• Tính sẵn sàng (Availability): đảm bảo tính chất dữ liệu luôn sẵn có khi cần thiết

Khi người dùng đăng nhập thành công (Authentication) các yêu cầu truy vấn dữ liệu hoặc tương tác với Server phải được đáp ứng nếu đúng các chính sách của hệ thống Các mối đe dọa phổ biến đến hệ thống thông tin bao gồm maleware, spyware, keystroke loggers, backdoor access, phishing và targeted scams; sử dụng sai mục đích của người truy cập hợp pháp và cách tấn công DoS Ngoài các mối đe dọa trên, người quản lý hệ thống thông tin và quản lý dữ liệu còn phải lưu tâm đến những việc không mong muốn có thể xảy ra như: thiên tai, mất điện, mất hoặc thất lạc nguồn tài nguyên thông tin Ngoài ra, người quản lý hệ thống còn phải bảo vệ dữ liệu trước những hành động vô tình của người dùng hợp pháp như xóa dữ liệu quan trọng, công khai các dữ liệu nhạy cảm hoặc gửi dữ liệu cho người không được phép truy cập

Bên cạnh đó, sự gia tăng về độ lớn của dữ liệu cũng như nhiều dạng dữ liệu mới được

ra đời cùng đồng hành với các lo ngại về vấn đề bảo mật tính riêng tư của dữ liệu Việc bảo mật tính riêng tư của dữ liệu được nói rộng ra nghĩa là các dữ liệu sẽ được quản lý bởi chính người sở hữu (tạo ra) dữ liệu đó và người quản trị có thể không được truy cập nếu không có sự đồng ý của người chủ sở hữu Việc này hướng đến chỉ có một nhóm người cụ thể mới có khả năng truy cập vào nhóm các đối tượng này Tuy nhiên trong môi trường mà ngày càng có nhiều thông tin được chia sẻ thì việc đảm bảo quyền này là vô cùng khó khăn Trong đề tài này, đề tài tập trung vào việc bảo mật dữ liệu bằng cách đánh giá các yêu cầu truy xuất đến dữ liệu trong hệ thống dựa trên một tập các chính sách đã được định nghĩa trước đó

3.2 Nhu cầu điều khiển truy xuất cho dữ liệu NoSQL

Để hiểu về nhu cầu điều khiển truy xuất cho dữ liệu NoSQL, ta sẽ sơ lược những đánh giá

và nhận định của các chuyên gia về vấn đề bảo mật và quyền riêng tư cho dữ liệu lớn nói chung, nhu cầu sử dụng dữ liệu lớn và mức độ khó khăn trong việc bảo mật trên loại dữ liệu này Đầu tiên tôi xin đưa ra con số cụ thể về độ lớn của dữ liệu và từ đó sẽ giải thích được vì sao dữ liệu lớn lại cần thiết đối với chúng ta hiện nay và những nguyên nhân gì mà phải lựa chọn cấu trúc dữ liệu NoSQL thay vì các cấu trúc truyền thống Định nghĩa về

“Big Data” (dữ liệu lớn) bao gồm một số lượng rất lớn các thông tin dữ liệu được lưu trữ trong các công ty về lĩnh vực CNTT bên cạnh đó là các vấn đề liên quan giữ chính phủ đối

Trang 36

với người dân và môi trường của họ Số lượng dữ liệu được tạo ra gấp đôi cứ sau mỗi năm

cụ thể: từ 2500 exabyte vào năm 2012 đến 40.000 exabyte vào năm 2020 [35] (Hình 3.2) Điều này cũng tương đương với việc dữ liệu càng lớn thì thách thức về tính riêng tư và bảo mật càng cao Các ứng dụng trước đây sử dụng dữ liệu lớn thường được áp dụng cho các công ty và các tổ chức lớn, bởi vì để có thể tạo ra một cơ sở hạ tầng cho việc lưu trữ và xử

lý dữ liệu là vô cùng tốn kém Tuy nhiên, đến thời điểm hiện tại việc ứng dụng Big Data vào các công ty nhỏ, vừa cũng như các tổ chức có quy mô nhỏ đã rất rộng rãi thông qua sự

hỗ trợ của các cấu trúc nền tảng cho dữ liệu lớn như Cloud Computing, Hadoop, v.v… Tuy nhiên, khi ứng dụng các cấu trúc này thì mức độ bảo mật là điều phải xem xét do tính dùng chung và không có một chuẩn bảo mật nào giữa “khớp nối” từ dữ liệu nội bộ đối với môi trường bên ngoài Các chức năng bảo mật dạng truyền thống trước đây (firewalled, semi-isolated networks) cũng không đủ điều kiện để áp dụng Chính vì thế vấn đề bảo mật cho

dữ liệu lớn được đặc biệt quan tâm

Hình 3 2: Lượng dữ liệu số ước tính được sinh ra từ năm 2010 đến năm 2020 [ 35 ]

Ngoài ra, chính vì sự khác biệt về cấu trúc và các đặc tính giữa dữ liệu truyền thống và dữ liệu lớn mà vấn bảo mật trên dữ liệu lớn cũng rất khác so với bảo mật trên dữ liệu truyền

Trang 37

thống và đang gặp phải rất nhiều khó khăn Trong bài nghiên cứu [36], nhóm tác giả đã đưa ra những nhận định của mình về 10 vấn đề quan trọng được xem là thử thách và ngày càng được tập trung giải quyết trong lĩnh vực “Privacy and Security” cho dữ liệu lớn

Dưới đây là 10 thách thức bảo mật trong Big Data:

1 Secure computations in distributed programming frameworks

2 Security best practices for non-relational data stores

3 Secure data storage and transactions logs

4 End-point input validation/filtering

5 Real-time security monitoring

6 Scalable and composable privacy-preserving data mining and analytics

7 Cryptographically enforced data centric security

8 Granular access control

9 Granular audits

10.Data provenance

Trong đó, làm sao có thể giám sát tình hình bảo mật trong thời gian thực (Real-time security monitoring) và điều khiển truy cập mịn “Granular access control” là hai trong các vấn đề quan trọng được đưa ra

Tính chất chủ yếu của điều khiển truy xuất đó chính là việc giữ tính bảo mật đối với các yêu cầu không đủ quyền truy cập Hay nói một cách khác, các dữ liệu không được phép truy cập từ một nhóm người dùng nào đó sẽ được bảo vệ và hạn chế truy cập (chỉ được truy cập khi có đủ quyền hạn) chức năng đó được gọi là “Bảo Mật” Điều khiển truy xuất mịn, khiến cho người quản trị quản lý dữ liệu tốt hơn khi chia sẻ, mà không ảnh hưởng đến tính bảo mật chung của dữ liệu (đối với đối tượng nào được phép xem dữ liệu đó thì vẫn được cấp quyền) Ngoài ra, trong tài liệu này, chúng tôi xin giới thiệu đến một hướng tiếp cận mới nhằm thỏa mãn tính bảo mật trong thời gian thực Cụ thể ở đây, chúng tôi sẽ đưa ra cách thức đảm điều khiển truy cập kể cả khi các chính sách thay đổi mà không làm ảnh hưởng đến hệ thống (dừng hệ thống hay cập nhật lại hệ thống)

3.3 Khái niệm về điều khiển truy xuất

Điều khiển truy xuất (access control) là quá trình trung gian xử lý nằm giữa câu lệnh truy xuất và nguồn tài nguyên hoặc dữ liệu Quá trình này được quản lý bởi hệ thống và có nhiệm vụ xác định yêu cầu truy xuất là được phép hay không [2] Theo một cách khác, điều khiển truy xuất được được định nghĩa bao gồm xác thực (authentication) và phân quyền (authorization) [4]

Trang 38

Các tác giả trong [2] định nghĩa một hệ thống điều khiển truy xuất (access control system) bao gồm: chính sách điều khiển truy xuất (access control policy), mô hình điều khiển truy xuất (access control model), và cơ chế điều khiển truy xuất (access control mechanism) Trong đó, các chính sách định nghĩa các luật cho phép xác định một yêu cầu truy xuất là được phép hay không Các chính sách sau đó được cụ thể hóa (formalize) trong mô hình truy xuất và sau cùng được thực thi bởi cơ chế điều khiển truy xuất

Ngoài ra, một hệ thống điều khiển truy xuất phải thỏa mãn các tính chất quan trọng sau [2]:

• Simple (tính đơn giản): hệ thống phải hỗ trợ cho người quản lý dễ dàng trong việc

tạo và chỉnh sửa các đặc tả kỹ thuật về yêu cầu bảo mật

• Expressive: hệ thống phải cung cấp khả năng mô tả các yêu cầu uyển chuyển, có

khả năng áp dụng cho nhiều nguồn tài nguyên và loại dữ liệu khác nhau

• Policy combination: khi có nhiều quyết định nhận được cho một yêu cầu truy xuất,

hệ thống phải hỗ trợ việc kết hợp các quyết định này thành một quyết định đơn duy nhất

• Anonymity: có rất nhiều dịch vụ không yêu cầu định danh thực sự của người dùng;

do đó, hệ thống cũng cần hỗ trợ điều khiển truy xuất dựa trên đặc tính của người dùng (các định danh kỹ thuật số)

• Data outsourcing: xu hướng hiện nay của các doanh nghiệp và thuê nguồn tài

nguyên từ bên ngoài; vì vậy, hệ thống được áp dụng phải đảm bảo điều khiển Các mô hình điều khiển truy xuất hiện nay đều dựa trên ba mô hình kinh điển có thể được

kể đến là: DAC, MAC và RBAC [3] Gần đây, mô hình ABAC, là một mô hình mới được

giới thiệu, vừa bao gồm ưu điểm của các mô hình truyền thống, vừa rất linh động cho phép biểu diễn các chính sách phân quyền linh động, hiệu quả

Theo Sandhu R.S [4], một khung điều khiển truy xuất tổng quát bao gồm các thành phần như hình vẽ bên dưới:

Hình 3 3: Khung điều khiển truy xuất tổng quát

Trong đó:

Trang 39

• Authentication: mô hình xác thực người dùng

• Authorization rules: tập các luật phân quyền được định nghĩa dựa theo mô hình

<S, O, P> (hoặc <S, O, P, C>) Với S (Subject) là đại diện cho người dùng hoặc quá trình muốn truy xuất vào dữ liệu, O (Object) là đối tượng dữ liệu mà S muốn truy xuất, P (Privilege hay Permission) đại diện cho các tác vụ xác định mà S có thể thực hiện trên O, và C (Constraint) là những ràng buộc không gian có thể có

• Resources: là dữ liệu đích mà người dùng dự định truy xuất vào

• PIP: Policy Information Point, có nhiệm vụ tạo mới và chỉnh sửa các luật phân

quyền nằm trong Authorization rules để phù hợp với nhu cầu nghiệp vụ

• PEP: Policy Enforcement Point, chuyển đổi các yêu cầu nhận được từ phía người

dùng sang dạng tương thích với các luật phân quyền được chứa trong Authorization rules, hoặc chuyển đổi các quyết định từ PDP sang dạng người dùng có thể hiểu được

• PDP: Policy Decision Point, tìm các luật phân quyền có liên quan, so sánh với yêu

cầu của người dùng (được chuyển từ PEP) và đưa ra quyết định, chuyển quyết định này cho PEP

Cơ chế hoạt động của khung điều khiển có thể tóm lược như sau: trước hết, người dùng phải là người dùng hợp lệ của hệ thống, PEP nhận yêu cầu từ phía người dùng và chuyển sang dạng tương thích với các luật phân quyền được đã được định nghĩa từ PIP; sau đó, PEP sẽ chuyển các yêu cầu này cho PDP Nhiệm vụ của PDP là tìm các luật phân quyền có liên quan, so sánh với các yêu cầu của người dùng, từ đó đưa ra quyết định (cho phép hoặc từ chối), đồng thời, PDP cũng chuyển quyết định ngược lại cho PEP Để kết thúc quá trình, PEP tiếp tục chuyển các quyết định sang định dạng

mà người dùng có thể hiểu được và trả kết quả về cho người dùng

3.4 Các mô hình truyền thống

3.4.1 Mô hình điều khiển truy cập tùy quyền

Mô hình bảo mật tùy quyền, hoặc mô hình điều khiển truy cập tùy quyền (DAC model), quản lý và điều khiển các truy cập của người dùng đến các thông tin dựa vào định danh của người dùng và tập các luật điều khiển truy cập Luật điều khiển truy cập định nghĩa với mỗi người dùng và đối tượng (object), sẽ có quy định các loại truy cập mà người dùng được phép làm trên đối tượng đó

Khi người dùng yêu cầu truy cập đến một đối tượng, một bộ phận định quyền (authorization module) sẽ kiểm tra xem người dùng đó có được phép truy cập không Nếu có thì cho phép, còn không thì từ chối Trong mô hình điều khiển truy cập tùy quyền thì :

• Người dùng có thể bảo vệ những gì thuộc về mình

• Chủ của dữ liệu sẽ có toàn quyền trên dữ liệu đó

Trang 40

• Chủ của dữ liệu có quyền định nghĩa các loại truy cập đọc/ghi/thực thi (read/write/execute/…) và gán những quyền đó cho những người dùng khác

Mô hình điều khiển truy cập tùy quyền có thể được thực hiện với nhiều cơ chế khác nhau :

• Bảng phân quyền : mỗi phần tử được lưu trong bảng sẽ gồm có 3 thành phần :

người dùng (user), hành động (action), thực thể (object) với ý nghĩa là người dùng

U có quyền A trên thực thể O Hình 3.1.a là một ví dụ về bảng phân quyền, trong đó người dùng Ann có quyền read trên Document1

• Danh sách điều khiển (Access control list ACL) : trong cách thực hiện này : mỗi

thực thể sẽ được gắn với một danh các người dùng cùng với quyền mà người đó được phép thực hiện Hình 3.1.b là một ví dụ về danh sách điều khiển, trong ví dụ

này : trên tài liệu Document1 thì Ann có quyền Read,Write và Bob có quyền Read

• Danh sách quyền (Capability) : trong danh sách này, mỗi một người dùng được

gắn với một danh sách các thực thể cùng với các hành động được phép thực thi trên thực thể đó Hình 3.1.b là một ví dụ về danh sách quyền, trong đó Ann được quyền

Read/Write trên Document1 , quyền Read trên Document2, quyền execute trên

Program1

Hình 3 4: Mô hình điều khiển truy cập tùy quyền

Mô hình này đơn giản nhưng rất hiệu quả và linh động trong việc thể hiện các chính sách điều khiển truy xuất Tuy nhiên, mô hình này lại vướng phải nhược điểm, nó không thể điều khiển thông tin được truyền và sử dụng như thế nào khi nó được một chủ thể đã được gán quyền truy cập vào Chính vì thế mà mô hình này có thể bị tấn công bởi Trojan Hourse

Định dạng
Số trang	168
Dung lượng	27,56 MB