Luận văn thạc sĩ Khoa học máy tính: Nghiên cứu phát triển mô hình điều khiển truy xuất cho dữ liệu lớn

Với các đặc điểm về khối lượng lớn, tính đa dạng, sự phát triển liên tục của dữ liệu lớn, 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ốn

GIỚI THIỆU

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

Như đã đề cập ở trên, mặc dù dữ liệu lớn ngày càng thu hút được sự quan tâm của các nhà nghiên cứu nhưng các mô hình điều khiển truy xuất cho dữ liệu lớn vẫn còn nhiều hạn chế, vẫn chưa đạt đến độ mịn và linh động Do đó 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 lớn, xây dựng một cơ chế điều khiển truy xuất để đánh giá mô hình đã đề xuất.

Ý 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 lớn Mô hình điều khiển truy xuất này sẽ làm nền tảng vững chắc, tạo tiền đề nghiên cứu và phát triển các ứng dụng dữ liệu lớn

Về mặt thực tiễn, đề tài xây dựng một cơ chế điều khiển truy xuất, 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 lớn.

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

Do thời gian có hạn, nên phạm vi nghiên cứu của đề tài trước mắt tập trung vào việc xây dựng một mô hình điều khiển truy xuất tổng quát cho dữ liệu lớn Việc xây dựng một cơ chế điều khiển để đánh giá mô hình chỉ được xây dựng trên một mô hình dữ liệu lớn Cụ thể là trong đề tài này sẽ sử dụng mô hình document store MongoDB

Về mô hình điều khiển truy xuất áp dụng cho MongoDB, đề tài sẽ sử dụng mô hình ABAC và hiện thực mô hình ABAC để có thể áp dụng cho MongoDB.

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

2 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 và thực tiễn của vấn đề được nêu ra, 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 về dữ liệu lớn, các mô hình cơ sở dữ liệu NoSQL và mô hình MongoDB sẽ là cơ sở dữ liệu được áp dụng trong đề tài này

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 kiển dựa trên thuộc tính ABAC sẽ được áp dụng trong đề tài này

Chương 4 KIẾN TRÚC HỆ THỐNG trình bày kiến trúc tổng quan hệ thống

Chương 5 HIỆN THỰC HỆ THỐNG trình bày kiến trúc hiện thực của hệ thống

Chương 6 KẾT QUẢ THỰC NGHIỆM trình bày kết quả đánh giá hệ thống

Chương 7 KẾT LUẬN trình bày tổng kết báo cáo và hướng phát triển của đề tài

CƠ SỞ DỮ LIỆU NOSQL

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 (volumme) 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 Phần tiếp theo sẽ trình bày tóm tắt các mô hình dữ liệu lớn cùng với các hệ thống quản lý dữ liệu lớn đang có trong thực tế.

Các mô hình dữ liệu lớn

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 vì vậy 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ó

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ụ dưới 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

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ủadocument 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

6 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

So sánh các mô hình dữ liệu lớn

Các mô hình lưu trữ NoSQL: mô hình Key-Value, mô hình Document Store, mô hình Column Oriented mô hình Graph Databases không những khác nhau về cấu trúc dữ liệu lưu trữ và tính linh hoạt của mô hình dữ liệu mà còn khác nhau ở các đặc điểm sau: khả năng truy vấn (Query possibilities), truy cập đồng thời (Concurrency control), phân tán dữ liệu (Partition), nhân bản dữ liệu (Replication) Để chọn được một mô hình lưu trữ dữ liệu phù, cần phải phân tích mô hình dữ liệu và các đặc điểm kể trên của mô hình

Bởi vì mô hình dữ liệu được kết chặt chẽ với khả năng truy vấn, phân tích các loại truy vấn được hỗ trợ bởi các cơ sở dữ liệu là một quá trình rất quan trọng để tìm ra một mô hình dữ liệu phù hợp Cơ sở dữ liệu NoSQL không chỉ khác nhau về mô hình dữ liệu cung cấp mà

14 cũng khác nhau về sự phong phú của các chức năng truy vấn được cung cấp của họ Do có sự khác biệt trong mô hình dữ liệu được cung cấp, ngôn ngữ truy vấn và các API của các mô hình NoSQL, nên cần phải phân tích và chọn lựa mô hình dữ liệu có hổ trợ truy vấn phù hợp với bài toán cụ thể

Do mô hình dữ liệu đơn giản, các mô hình Key-Value chỉ hỗ trợ truy vấn dữ liệu dựa trên khóa của dữ liệu thông qua các hàm (APIs) như put, get, delete, … Nếu như cần thêm những phương thức truy vấn dữ liệu khác, thì ứng dụng phải tự xây dựng thêm, việc đó sẽ làm cho hệ thống phức tạp và ảnh hưởng đến hiệu suất của hệ thống Do đó, không nên sử dụng mô hình Key-Value trong trường hợp cần có những câu truy vấn phức tạp hoặc truy vấn dựa trên giá trị của dữ liệu

Mô hình Document Store cung cấp truy vấn dữ liệu phức tạp hơn mô hình Key-Value: truy vấn dựa trên giá trị dữ liệu, chỉ mục thứ cấp, truy vấn dữ liệu lồng nhau, hỗ trợ các toán tử như “and”, “or”, “between” Trong Riak và MongoDB, truy vấn có thể được mở rộng với các biểu thức chính quy (regular expressions ) Trong khi MongoDB hỗ trợ thêm các toán tử “count” và “distinct” thì Riak cung cấp các chức năng để đi duyệt qua mối liên kết giữa các tài liệu một cách dễ dàng Truy vấn thông qua REST cũng được hỗ trợ bởi các mô hình Document Store

Mô hình Column Oriented chỉ hỗ trợ truy vấn vùng (range queries) và các toán tử như "in"

, "and/or" và biểu thức chính quy trên khóa dữ liệu và chỉ mục dữ liệu Mặc dù mô hình này cũng hỗ trợ ngôn ngữ truy vấn giống SQL hỗ trợ thân thiện với người dùng, tuy nhiên cũng chỉ có thể truy vấn trên khóa dữ liệu và chỉ mục dữ liệu

Ngoài ra các mô hình Document Store và Column Oriented có hỗ trợ chương trình nền tảng MapReduce cho phép việc truy vấn một cách song song các dữ liệu lớn được phân tán trên các máy khác nhau

Mô hình Graph Databases hỗ trợ truy vấn thông qua duyệt đồ thị và tìm ra thành phần của đồ thị thỏa mãn một khuôn mẫu định trước Hầu hết các mô hình Graph Databases đều hỗ

15 trợ truy vấn bằng REST, các hàm cung cấp sẵn (APIs), ngôn ngữ truy vấn Tuy nhiên, khác với các mô hình NoSQL khác, có một số ngôn ngữ truy vấn được hỗ trợ cùng được hỗ trợ bởi các mô hình Graph Database khác nhau SPARQL là ngôn ngữ duyệt đồ thị được hỗ trợ bởi Sesame, BigData và Ne04j

Các mô hình NoSQL cung cấp khả năng hỗ trợ truy vấn khác nhau Tùy vào yêu cầu cụ thể của bài toán, sẽ chọn ra mô hình với cách truy vấn phù hợp Trong trường hợp đơn giản thì không cần hỗ trợ truy vấn thông qua API hay ngôn ngữ truy vấn, REST phù hợp cho các ứng dụng web Sau đây là bảng tóm khả năng hổ trợ truy vấn của các mô hình NoSQL :

Bảng 2-2: Khả năng hổ trợ truy vấn của các mô hình NoSQL

Khi người dùng thực hiện truy cập dữ liệu một cách đồng thời, phải có cơ chế để đảm bảo sự thống nhất của dữ liệu Trong mô hình NoSQL có 3 chiến lược ngăn chặn sự mất nhất quán của dữ liệu dựa trên khái niệm các thao tác xung đột [19]:

Bảng 2-3: Khả năng hổ trợ truy cập đồng thời của các mô hình NoSQL

 Chiến lược khóa dữ liệu: chiến lược này thường được dùng với các hệ cơ sở dữ liệu quan hệ truyền thống Với chiến lược này khi một giao tác bắt đầu thay đổi giá trị của dữ liệu, thì nó sẽ khóa lại và không cho các giao tác khác thay đổi Chiến lược này chỉ phù hợp khi chi phí cho việc khóa dữ liệu không lớn và dữ liệu không bị khóa trong một khoảng thời gian dài Với các hệ cơ sở dữ liệu phân tán và khối lượng dữ liệu lớn thì chi phí cho việc thực thi khóa lớn, ảnh hướng đến hiệu suất của hệ cơ sở dữ liệu

 Chiến lược khóa lạc quan (optimistic locking): trước khi dữ liệu thay đổi được khi xuống hệ thống, giao tác sẽ kiểm tra xem có giao tác khác ghi dữ liệu xuống trước, làm mất tính nhất quán của dữ liệu Trong trường có sự mất nhất quán dữ liệu xảy ra, giao tác này sẽ được phục hồi lại (roll back) Chiến lược này phù hợp khi có ít thao tác làm thay đổi dữ liệu và khả năng làm mất tính nhất quan của dữ liệu thấp

Khi đó chi phí cho việc kiểm tra và phục hồi lại dữ liệu sẽ tốn ít chi phí hơn việc khóa dữ liệu

Hình 2.5: Chiến lược khóa dữ liệu

 Chiến lược quản lý nhiều phiên bản (Multiversion concurrency control, MVCC): để nâng cao hiệu suất của hệ thống, một số mô hình NoSQL không đảm bảo sự nhất quán chính xác một cách nghiêm ngặt Việc truy cập đồng thời không được quản lý bởi việc khóa dữ liệu mà bằng các phiên bản có thứ tự của dữ liệu Trong khi một giao tác đang đọc dữ liệu, một giao tác khác có thể thay đổi dữ liệu trên một phiên bản khác của dữ liệu Bên cạnh việc cắt giảm mức độ thống nhất của dữ liệu, MVCC còn đòi hỏi tốn nhiều dung lượng lưu trữ hơn vì nhiều phiên bản của dữ liệu được lưu trữ đồng thời Trong các hệ thống này sẽ có bộ dọn rác để xóa đi các phiên bản cũ không còn sử dụng của dữ liệu, và các giải thuật để giải thuật để giả quyết sự mất nhất quán của dữ liệu

Bởi vì khối lượng dữ liệu lớn và tấn suất truy cập dữ liệu, một máy chủ đơn lẻ không thể đáp ứng được yêu cập về tốc độ, do đó dữ liệu sẽ được phân tán trên một hệ thống các máy chủ liên kết với nhau Các mô hình NoSQL khác nhau có cách phân tán dữ liệu khác

18 nhau Các mô hình dựa trên Key-Value như Key-Value, Document Store, Column family có 2 cách để phân tán dữ liệu [19]:

Bảng 2-4: Khả năng hổ trợ phân tán dữ liệu

 Phân tán dựa trên vùng giá trị của khóa (range based):

Cơ sở dữ liệu MongoDB

2.4.1 Giới thiệu mongoDB MongoDB là một cơ sở dữ liệu đa nền tảng, hoạt động trên các khái niệm Collection và Document, nó cung cấp hiệu suất cao, tính khả dụng cao và khả năng mở rộng dễ dàng

 Khái niệm Database Database là một nơi chứa vật lý cho các Collection Mỗi Database lấy tập hợp các file riêng của nó trên hệ thống file Mỗi MongoDB Server có thể có nhiều cơ sở dữ liệu

 Khái niệm Collection Collection là một nhóm các Document trong MongoDB Nó tương đương như một bảng trong RDBMS Do đó, một Collection tồn tại bên trong một cơ sở dữ liệu duy nhất Các Collection không có ràng buộc Relationship như các hệ quản trị cơ sở dữ liệu khác nên việc truy xuất rất nhanh, chính vì thế mỗi collection có thể chứa nhiều thể loại khác nhau không giống như table trong hệ quản trị mysql là các field cố định Các Document bên trong một Collection có thể có nhiều trường khác nhau Đặc biệt, tất cả các Document trong một Collection là tương tự nhau hoặc với cùng mục đích liên quan

21 Một Document trong MongoDB, có cấu trúc tương tự như kiểu dữ liệu JSON, là một tập hợp các cặp key-value Các Document có schema động, nghĩa là Document trong cùng một Collection không cần thiết phải có cùng một tập hợp các trường hoặc cấu trúc giống nhau, và các trường chung trong Document của một Collection có thể giữ các kiểu dữ liệu khác nhau

Hình 2.8: Mô hình document trong mongodb

MongoDB cung cấp các API để thao tác dữ liệu trên server Hiện tại, mongoDB có hiện thực các driver trên một số ngôn ngữ : C, C++, C#, Java, Nodejs, Rubi, Python, PHP, Scala… Các chương trình tương tác với API của mongoDB thông qua các API này

Một số API cơ bản của MongoDB :

 Thêm document : Để thêm document, ta sử dụng API insert : db.COLLECTION_NAME.insert(document)

Trong đó document là một document la dữ liệu cần thêm vào, COLLECTION – NAME là tên của collection sẽ được thêm dữ liệu

_id: ObjectId(7df78ad8902c), title: 'MongoDB Overview', description: 'MongoDB is no sql database',

22 by: 'tutorials point', url: 'http://www.tutorialspoint.com', tags: ['mongodb', 'database', 'NoSQL'], likes: 100

 Tìm kiếm document : Để tìm kiếp document, ta sử dụng API find:

"_id": ObjectId(7df78ad8902c), "title": "MongoDB Overview", "description": "MongoDB is no sql database", "by": "tutorials point",

"url": "http://www.tutorialspoint.com", "tags": ["mongodb", "database", "NoSQL"], "likes": "100"

} Để truy vấn Document dựa trên một số điều kiện nào đó, ta có thể sử dụng các phép toán sau:

Phép toán Cú pháp Ví dụ Mệnh đề WHERE tương đương

Equality {:} db.mycol.find({"by":"tutorials point"}) where by =

'tutorials point' Less Than {:{$lt:}} db.mycol.find({"likes":{$lt:50}}) where likes < 50

{:{$lte:}} db.mycol.find({"likes":{$lte:50}}) where likes 50

{:{$gte:}} db.mycol.find({"likes":{$gte:50}}) where likes >= 50

Not Equals {:{$ne:}} db.mycol.find({"likes":{$ne:50}}) where likes != 50

Bảng 2-6: Các thao tác truy vấn trên MongoDB

 Thay đổi document : Phương thức update() hoặc save() trong MongoDB được sử dụng để cập nhật Document vào trong một Collection Phương thức update() cập nhật các giá trị trong Document đang tồn tại trong khi phương thức save() thay thế Document đang tồn tại với Document đã truyền trong phương thức save() đó

>db.COLLECTION_NAME.update(SELECTIOIN_CRITERIA, UPDATED_DATA)

Ví dụ sau sẽ thiết lập tiêu đề mới 'New MongoDB Tutorial' của Document có tiêu đề là 'MongoDB Overview':

>db.mycol.update({'title':'MongoDB Overview'},{$set:{'title':'New MongoDB Tutorial'}})

>db.mycol.find() { "_id" : ObjectId(5983548781331adf45ec5), "title":"New MongoDB Tutorial"}

{ "_id" : ObjectId(5983548781331adf45ec6), "title":"NoSQL Overview"}

{ "_id" : ObjectId(5983548781331adf45ec7), "title":"Tutorials Point Overview"}

 Xóa document : Phương thức remove() trong MongoDB được sử dụng để xóa Document từ Collection

Phương thức remove() nhận hai tham số Tham số đầu tiên deletion criteria xác định Document để xóa, và tham số thứ hai là justOne

- deletion criteria : (Tùy ý) Xác định Document để xóa

- justOne : (Tùy ý) Nếu được thiết lập là true hoặc 1, thì chỉ xóa một Document

Cú pháp cơ bản của phương thức remove() là như sau:

>db.COLLECTION_NAME.remove(DELLETION_CRITTERIA) Ví dụ sau sẽ xóa tất cả Document có title là 'MongoDB Overview':

>db.mycol.remove({'title':'MongoDB Overview'})

>db.mycol.find() { "_id" : ObjectId(5983548781331adf45ec6), "title":"NoSQL Overview"}

{ "_id" : ObjectId(5983548781331adf45ec7), "title":"Tutorials Point Overview"}

2.4.3 Điều khiển truy xuất cho 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

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

ĐIỀU KHIỂN TRUY XUẤT

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]

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ả

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

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

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 danh định 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 lậ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 đó

 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ó

27 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

Hình 3.1: 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

29 Từ đây nó sẽ khai thác vào các tài nguyên bí mật, kích hoạt các truy cập trái phép vào dữ liệu

Hình 3.2: Ví dụ về trojan horse tren DAC

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

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

Như đã giới thiệu ở phần 3.2, bắt đầu với ma trận truy cập của Lampson trong cuối những năm 1960, hàng chục mô hình điều khiển truy cập đã được đề xuất Tuy nhiên, chỉ có ba mô hình đã đạt được những thành công trong thực tế: điều khiển truy cập tùy ý (DAC) , điều khiển truy cập bắt buộc (MAC) và kiểm soát truy cập dựa trên vai trò (RBAC) DAC kiểm soát truy cập dựa trên danh tính của các đối tượng và MAC ra quyết định kiểm soát truy cập dựa trên mức độ bảo mật của các chủ thể và các đối tượng Trong RBAC, quyền được gán cho vai trò, từ đó người sử dụng có quyền truy cập thông qua các vai trò được gán Người dùng kích hoạt vai trò được giao để nhận các quyền gắn liền với vai trò Tuy 3 mô hình này lâu đời, được áp dụng rộng rãi trong thực tế nhưng đều có những hạn chế cần được phải khắc phục

Trong 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ô hình 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 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 Do đó mô hình RBAC ra đời để giải quyết các vấn đề của các mô hình điều khiển truyền thống

Tuy nhiên gần đây, mô hình 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 Hơn nữa việc tạo vai trò cũng làm trì hoãn việc triển khai RBAC vì đò là chi phí lớn nhất trước khi khiển khai hệ thống

32 Những hạn chế đã được giải quyết bằng hai cách bởi các nhà nghiên cứu Một bộ phận nhà nghiên cứu đã tạo ra các mở rộng để giải quyết các vấn đề Ví dụ như: quá trình kích hoạt vai trò được mở rộng bằng cách ràng buộc bởi thông tin ngữ cảnh như: thời gian, địa điêm, người dùng được gán với các thông tin khác ngoài vai trò như: tổ chức, nhóm, …, quyền cũng được mở rộng bao gồm mục đích và điều kiện để hỗ trợ chính sách bảo vệ tính riêng tư Tuy nhiên các mở rộng đó chỉ giải quyết một bài toán cụ thể và không có một framework thống nhất để tích hợp điểm mạnh của những mở rộng đó Việc thiếu tính thừa hưởng của các mở rộng làm giảm việc triển khai bời vì các mô hình mở rộng đó không tổng quát Bên cạnh các mở rộng, các nhà nghiên cứu cũng đưa ra các mô hình điều khiển truy xuất để khắc phục các hạn chế đó Mô hình điều khiển truy xuất dựa trên tổ chức (organization based access control), mô hình điều khiển truy xuất dựa trên công việc (task based access control), mô hình điều khiển truy xuất dựa trên quan hệ (relationship based access control)

Tuy nhiên, những mô hình đó được phát triển cho một ngữ cảnh ứng dụng cụ thể hơn là mô hình tổng quát

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

Do những hạn chế trong các mô hình truyền thống cũng như trong các mô hình mở rộng, đòi hỏi cần có một mô hình tổng quát để giải quyết các vấn đề hạn chế Mô hình điều khiển truy xuất dựa trên thuộc tính ABAC là một mô hình mới giải quyết được các hạn chế trên và mô hình này cũng bao gồm ưu điểm của các mô hình truyền thống Về cơ bản, thuộc

33 tính được xem như cặp khóa-giá trị gắn với các thực thể của hệ thống: người dùng, dữ liệu,

… Thuộc tính có thể biễu diễn các định danh trong mô hình DAC, các nhãn bảo mật trong mô hình MAC, các ai trò trong mô hình RBAC Hơn nữa, thuộc tính có thể biểu diễn được các thuộc tính khác như: địa điểm, thời gian, trạng thái hệ thống,… Do đó, không những ABAC có thể bao gồm các mô hình điều khiển truyền thống mà còn biểu diễn được các chính sách phức tạp hơn, linh động hơn

Mô hình điều khiển truy xuất dữ trên thuộc tính(ABAC): là một phương thức điều khiển truy xuất trong đó yêu cầu thao tác trên dữ liệu được cho phép hay từ chối dựa vào thuộc tính của chủ thể, thuộc tính của dữ liệu, các điều kiện môi trường, và tập hợp các chính sách được xác định dựa trên các thuộc tính, điều kiện đó

Mô hình ABAC chứa các thành phần cơ bản bao gồm: Người dùng (User), Thuộc tính người dùng (User Attribute), Chủ Thể (Subject), Thuộc Tính Chủ Thể (Subject Attribute), Đối Tượng (Object), Thuộc Tính Đối Tượng (Object Attribute), Ngữ cảnh (Context), Thuộc tính ngữ cảnh (Context attribute), Quyền (Permission), Chính sách Phân Quyền

Hình 3.5: Mô hình điều khiển truy xuất dựa trên thuộc tính ABAC o Một Thuộc Tính là một hàm trả về giá trị cụ thể cho một thực thể: Người dùng,

Chủ Thể, Đối Tượng, Ngữ cảnh Giá trị của thuộc tính được xác định bởi phạm vi và loại của thuộc tính Phạm vi của một thuộc tính được xác định bởi một tập hợp hữu hạn các giá trị nguyên tử Một thuộc tính nguyên tử (atomic attribute) sẽ trả lại một giá trị đơn lẻ trong phạm vi, trong khi một thuộc tính tập hợp sẽ trả về một tập hợp con của phạm vi Nói cách khác, phạm vi của một thuộc tính nguyên tử là tương đương với phạm vi của nó, trong khi đối với một thuộc tính tập hợp thì phạm vi là các powerset của phạm vi o Mỗi Người dùng được liên kết với một tập hữu hạn các Thuộc tính người dùng có giá trị được chỉ định bởi người quản trị an ninh (ngoài phạm vi của mô hình ABAC) Những Thuộc tính này đại diện cho thông tin của người dùng, chẳng hạn như tên, tuổi, vai trò và giới tính, độ tin cậy,

35 o Chủ thể được tạo ra bởi Người dùng để thực hiện một số hành động trong hệ thống Đối với mục đích của mô hình này, các Chủ thể chỉ có thể được tạo ra bởi một Người dùng và không được phép để tạo ra các Chủ thể khác Người dùng tạo ra là người duy nhất có thể chấm dứt một Chủ thể Mỗi Chủ thể được liên kết với một tập hữu hạn các Thuộc Tính Chủ Thể được gắn một giá trị ban đầu vào thời điểm khởi tạo Thuộc Tính Chủ Thể được thiết lập bởi Người dùng tạo ra và bị ràng buộc bởi chính sách được thiết lập bởi các kiến trúc an ninh Ví dụ, một Thuộc Tính Chủ Thể có thể được thừa kế từ một Thuộc tính người dùng tương ứng, điều này được thể hiện như một mũi tên từ UA sang SA trong hình 2 o Đối tượng là những tài nguyên cần được bảo vệ Đối Tượng được liên kết với một tập hữu hạn các Thuộc tính đối tượng Đối Tượng có thể được tạo ra bởi một

Chủ thể đại diện cho Người dùng Khi khởi tạo, giá trị thuộc tính của đối tượng có thể được thiết lập bởi người sử dụng thông qua các Chủ thể Các giá trị có thể bị hạn chế bởi các thuộc tính tương ứng của các đối tượng Ví dụ, một Thuộc

Tính đối tượng mới có thể kế thừa các giá trị từ các Thuộc Tính Chủ Thể tương ứng, điều này được thể hiện như một mũi tên từ UA sang SA trong hình 2 o Ràng buộc (Constraint) là các hàm dùng để ràng buộc sự thay đổi giá trị trên

Chủ thể hoặc Đối tượng Các ràng buộc này được kiến trúc an ninh cấu hình thông qua các chính sách ràng buộc o Quyền là những khả năng mà Người dùng giữ và thực thi trên một Đối tượng và được thực hiện thông qua Chủ thể Quyền cho phép một Chủ thể truy cập vào một đối tượng trong một chế độ cụ thể, chẳng hạn như đọc hoặc ghi Việc định nghĩa Quyền là phụ thuộc vào hệ thống cụ thể o Chính sách phân quyền là những hàm dùng để đánh giá các yêu cầu truy cập, cho chép các truy cập này được phép thực hiện hay không o Ngữ cảnh (Context) và Thuộc tính ngữ cảnh (Context attribute) : các thuộc tính này độc lập với Người dùng ,Chủ thể , Đối tượng và không thể bị thay đổi bởi

Người dùng và Chủ thể Hơn nữa những thuộc tính này được cập nhật một cách

36 tự động bời hệ thống hoặc quản trị hệ thống Ví dụ như: thời gian, tỉ lệ sử dụng CPU, tỉ lệ sử dụng ổ cứng

KIẾN TRÚC HỆ THỐNG

Mô hình tổng quan

Cấu trúc của mô hình được biểu diễn như hình 4.1, bao gồm các thành phần chính chủ thể

(subject S), hành động (action A), đối tượng (object O), môi trường (environemt E), quyền (permission P), các chính sách phân quyền (Authorization policy)

Hình 4.1: Tổng quan mô hình

 Chủ thể (S) : đưa ra yêu cầu truy xuất vào hệ thống, mỗi chủ thể được gắn với một tập hợp các thuộc tính SA Các thuộc tính này thể hiện thông tin của chủ thể như : tên, tuổi, giới tính, mức độ tin cậy, …

 Hành động (A) : thể hiện thao tác mà chủ thể sẽ tác động lên dữ liệu như : đọc, ghi, xóa, sửa Mỗi hành động cũng được gắn với một danh sách các thuộc tính AA thể hiện thông tin lúc hành động đó được thực thi Các thuộc tính này có thể là : thời gian, địa điểm, IP của thiết bị, … lúc chủ thể đưa ra yêu cầu

 Đối tượng (O) : chính là dữ liệu mà hệ thống cần được bảo vệ, mỗi đối tượng cũng được gắn với một danh sách các thuộc tính OA, các thuộc tính này thể hiện thông tin của đối tượng như : độ bảo mật, chủ sở hữu, thời gian tạo ra, số lần truy cập, …

 Môi trường (E) : được gắn với một danh sách các thuộc tính EA thể hiện trang thái hiện tại của hệ thống : mức độ bảo mật, trạng thái hệ thống, tải của hệ thống

 Chính sách phân quyền : các chính sách mô tả các luật dùng để đánh giá các yêu cầu truy cập vào dữ liệu dựa trên các thuộc tính SA, AA, OA, EA.

Kiến trúc tổng quan

Trong mô hình hệ thống cũng bao gồm các khối chủ yếu PEP, PAP, PDP, PIP có chức năng tương tự như trong mô hình khác như mô hình XACML 3.0 Hình dưới đây mô tả cụ thể các bước thực hiện của một yêu cầu gửi đến hệ thống và được hệ thống trả lời là chấp nhận (Permit) hay không chấp nhận yêu cầu (Deny), ngoài ra còn hai dạng trả về của hệ thống cho người dùng là: Indeterminate và Not Applicable lần lượt khi yêu cầu của người dùng bị lỗi hoặc không có bất kỳ một Policy nào thỏa mãn được yêu cầu đó

Hình 4.2: Kiến trúc tổng quan hệ thống

Các bước thực hiện tuần tự theo thứ tự luồng công việc đã đưa ra trong hình ở trên

1 Đầu tiên người quản trị hệ thống sẽ đặc tả các Policy trong PAP dưới định dạng

JSON để cung cấp cho PDP, sau này đây chính là tập các chính sách quy định việc cấp phép hay không cấp phép một yêu cầu từ phía người dùng vào hệ thống

2 Tiếp theo sau khi access requester đã vượt qua được mức authentication (đăng nhập vào hệ thống) họ sẽ gửi các yêu cầu thao tác trên các đối tượng Object và các yêu cầu này sẽ gửi đến PEP Ở PEP yêu cầu của người dùng sẽ được định nghĩa lại theo chuẩn JSON bao gồm 4 trường cơ bản là: Subject đối tượng gửi yêu cầu (các nhóm

40 đối tượng này đã được định nghĩa trước đó), Action hành động của Subject đối với Object (read, rewrite, execute), Environment các thông tin liên quan khi gửi yêu cầu đó (thời gian, địa điểm), và Resource đối tượng mong muốn được thao tác (file, bảng, cột hay một đối tượng cụ thể)

3 Các yêu cầu từ PFP sẽ được gửi xuống khối PDP, ở đây sẽ phân chia các thông tin của một yêu cầu về từng thành phần cụ thể: các thông tin liên quan đến dữ liệu và thuộc tính của đối tượng sẽ được gửi cho PIP nơi mà tương tác với cơ sở dữ liệu để lấy các thông tin về thuộc tính của đối tượng, ngữ cảnh, môi trường, về phía đánh giá yêu cầu đó có được thực thi hay không sẽ là công việc của PDP Dựa vào các thông tin trong yêu cầu, khối PDP sẽ yêu cầu khối PRP để lấy các chính sách được áp dụng cho yêu cầu này

4 Khối PRP sẽ truy xuất các chính sách sẽ được áp dụng cho yêu cầu của người dùng từ các chính sách đã được tạo ra ở bước số 1

5 Sau khi lấy xong các chính sách xong, khối PRP sẽ trả lại các chính sách này cho khối PDP

6 Sau khi lấy được các chính sách được áp dụng cho yêu cầu, khối PDP sẽ bắt đầu đánh giá các chính sách Trong quá trình đánh giá này, các thông tin về thuộc tính của đối tượng, hành động, tài nguyên, môi trường sẽ được lấy ra từ trong yêu cầu để phục vụ đánh giá

7 Trong trường hợp, nội dung của yêu cầu không chứa các thông tin này, khối PDP sẽ yêu cầu khối PIP đề lấy thông tin

8 Khối PIP tạo kết nối đến cơ sở dữ liệu để lấy các thuộc tính được yêu cầu

9 Sau khi nhận được các thuộc tính cần thiết, PDP sẽ đánh giá các luật/chính sách

Trong PDP các Policy sẽ kết hợp lại với nhau theo các giải thuật kết nối tập các policy để tìm ra policy tốt nhất để đánh giá yêu cầu ban đầu Hai trường hợp chủ yếu gửi về cho context handler là cho phép (permit) hoặc không cho phép (deny) ngoài ra có hai kết quả trả về không mang giá trị cho người dùng là Indeterminate và Not Applicable

10 PDP trả kết quả đánh giá cuối cùng cho khôí PFP

41 11 PFP dựa vào kết quả đánh giá của khối PDP, trả dữ liệu về cho người dùng

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

Do độ phức tạp của hệ thống và thời gian hạn chế của đề tài, hệ thống hiện tại chỉ tập trung vào xây dựng khối quyết định chính sách PDP, các khối còn lại PIP, PFP, PRP chỉ được hiện thực các hàm cơ bản nhằm phục vụ cho việc đánh giá chính sách của khối PDP.

Cấu trúc chính sách và luật

Trong hệ thống này, các chính sách sẽ được lưu dưới dạng json document bởi vì : - Dữ liệu dưới dạng json sẽ thích hợp lưu trữ trong các cơ sở dữ liệu NoSQL

- Cho phép thể hiện các thuộc tính một cách dễ dàng dưới dạng các cặp key-value

Hình 4.4: Cấu trúc json dùng để lưu chính sách phân quyền

Cấu trúc của các chính sách có thể minh hóa như hình 4.3, trong đó :

Hình 4.5: Cấu trúc chính sách

- Mục tiêu (Target) : dùng để xác định các tập chính sách, chính sách, luật có được áp dụng cho yêu cầu hay không Mục tiêu sẽ gồm các thành phần : chủ thể (subject), hành động (action), tài nguyên (resource)

- Tập chính sách (PolicySet) : bao gồm một danh sách các chính sách và luật kết hợp các chính sách lại với nhau để ra kết quả đánh giá cuối cùng cho yêu cầu

- Chính sách : một chính sách bao gồm các một danh sách các luật và giải thuật để kết hợp kết quả các luật lại cho ra kết quả của chính sách

- Luật : một luật sẽ bao gồm hiệu ứng của luật, hiệu ứng này có thể là cho phép hoặc từ chối, hiệu ứng được áp dụng khi và chỉ khi kết quả đánh giá của biểu thức điền kiện (condition) là đúng

- Điều kiện : đây là một biều thức luận lý được đánh giá dựa vào thuộc tính của các thành phần : chủ thể hành động, đối tượng, môi trường.

Giải thuật kết hợp các chính sách và luật

Trong một tập chính sách (PolicySet) sẽ có nhiều chính sách, trong một chính sách sẽ có nhiều luật Khi một yêu cầu truy cập được đánh giá, hệ thống sẽ chọn ra các chính sách, luật sẽ được áp dụng cho yêu cầu đó Do đó, cần có các giải thuật kết hợp các kết quả đánh giá của các chính sách và các luật đơn lẻ thành kết qua cuối cùng của hệ thống

4.4.1 Giải thuật kết hợp luật a Deny-overrides

Trong toàn bộ các rule trong policy, nếu có bất kỳ rule nào được đánh giá là Deny, vậy thì kết quả kết hợp sẽ là Deny Nếu bất kỳ rule nào đánh giá là Permit và tất các những rule còn lại đánh giá là NotApplicable thì kết quả kết hợp là Permit Nói cách khác, Deny sẽ đóng vai trò ưu tiên khi đưa ra kết quả kết hợp Nếu có một lỗi xảy ra khi đánh giá target hoặc condition của một rule chứa giá trị Effect là Deny vậy thì việc đánh giá sẽ được tiếp tục cho các rule tiếp theo, để tìm kiếm kết quả Deny Nếu không còn rule nào được đánh giá là Deny vậy thì kết quả kết hợp sẽ là Indeterminate với trạng thái lỗi đi kèm Nếu có ít nhất một rule được đánh giá là Permit, tất cả các rule còn lại không có lỗi, được đánh giá là Permit hoặc NotApplicable và các rule mà có lỗi khi đánh giá nhưng giá trị Effect là Permit thì kết quả kết hợp sẽ là Permit b Permit-overrides

Trong toàn bộ các rule trong policy, nếu có bất kỳ rule nào được đánh giá là Permit, vậy thì kết quả kết hợp sẽ là Permit Nếu bất kỳ rule nào đánh giá là Deny và tất các những rule còn lại đánh giá là NotApplicable thì kết quả kết hợp là Deny Nói cách khác, Permit sẽ đóng vai trò ưu tiên khi đưa ra kết quả kết hợp Nếu có một lỗi xảy ra khi đánh giá target hoặc condition của một rule chứa giá trị Effect là Permit vậy thì việc đánh giá sẽ được tiếp tục cho các rule tiếp theo, để tìm kiếm kết quả Permit Nếu không còn rule nào được đánh giá là Permit vậy thì kết quả kết hợp sẽ là Indeterminate với trạng thái lỗi đi kèm Nếu có ít nhất một rule được đánh giá là Deny, tất cả các rule còn lại không có lỗi, được đánh giá

45 là Deny hoặc NotApplicable và các rule mà có lỗi khi đánh giá nhưng giá trị Effect là Deny thì kết quả kết hợp sẽ là Deny c First-applicable

Mỗi rule được đánh giá theo thứ tự được liệt kê trong policy Với một rule nào đó mà target được thỏa và condition được đánh giá là True vậy thì việc đánh giá policy đó sẽ dừng và kết quả kết hợp trả về là giá trị Effect của rule đó Nếu target của rule đó là không thỏa hoặc condition trả về False, vậy thì rule kế tiếp sẽ được đánh giá Nếu không có rule nào nữa thì policy sẽ trả về NotApplicable

Nếu một lỗi xảy ra khi đánh giá Target và Condition của một rule, vậy thì việc đánh giá sẽ dừng, policy sẽ trả về là Indeterminate với một trạng thái lỗi tương ứng

4.4.2 Giải thuật kêt hợp chính sách a Deny-overrides

Trong toàn bộ các policy của policy-set, nếu bất kỳ policy được đánh giá là Deny, vậy thì kết quả kết hợp sẽ là Deny Nếu một lỗi xảy ra trong khi đánh giá Target của policy hoặc policy tham khảo là không hợp lệ hoặc kết quả đánh giá là Indeterminate, vậy thì policy- set đó có giá trị là Deny b Permit-overrides

Trong toàn bộ các policy của policy-set, nếu bất kỳ policy được đánh giá là Permit, vậy thì kết quả kết hợp sẽ là Permit Nếu một lỗi xảy ra trong khi đánh giá Target của policy hoặc policy tham khảo là không hợp lệ hoặc kết quả đánh giá là Indeterminate và không có policy nào được đánh giá là Permit hay Deny, vậy thì policy-set đó có giá trị là Indeterminate với trạng thái lỗi đi đèm

Mỗi policy được đánh giá theo thứ tự xuất hiện trong policy-set Với một policy nào đó mà target được thỏa và policy được đánh giá là Permit hay Deny vậy thì việc đánh giá policy- set đó sẽ dừng và kết quả kết hợp trả về là giá trị Effect của policy đó Nếu target của rule đó là không thỏa hoặc policy đánh giá là NotApplicable, vậy thì policy kế tiếp sẽ được đánh giá Nếu không có policy nào nữa thì policy-set sẽ trả về NotApplicable

Nếu một lỗi xảy ra khi đánh giá Target hoặc khi đánh giá một policy nào đó, policy tham khảo không hợp lệ hoặc policy đó được đánh giá là Indeterminate, vậy thì việc đánh giá sẽ dừng, policy-set sẽ trả về là Indeterminate với một trạng thái lỗi tương ứng d Only-one-applicable

Giải thuật kết hợp này chỉ được áp dụng cho policy-set Trong tập các policy của policy- set, nếu không có policy nào là khả áp dụng do Target của nó vậy thì kết quả của việc kết hợp policy sẽ là NotApplicable Nếu có nhiều hơn một policy là khả áp dụng vậy thì kết quả kết hợp sẽ là Indeterminate Nếu chỉ có duy nhất một policy là khả áp dụng vậy thì kết quả kết hợp sẽ trả về kết quả đánh giá policy đó Nếu có lỗi xảy ra khi đánh giá Target của một policy, hoặc một tham khảo là không hợp lệ hoặc việc đánh giá policy trả về kết quả là Inderterminate, vậy thì policy-set sẽ trả về là Indeterminate với một trạng thái lỗi tương ứng

Dưới đây là giải thuật thực hiện việc kết hợp các luật, chính sách, các giải thuật Deny- overrides, Permit-overrides, First-applicable được dùng chung cho cả luật, chính sách

 Giải thuật kết hợp Deny-overrides

Boolean atLeastOnePermit = false; for (i = 0; i < lengthOf(children); i++) {

Decision decision = children[i].evaluate(); if (decision == Deny) { return Deny;

} if (decision == Permit) { atLeastOnePermit = true;

} else if (decision == NotApplicable) { continue;

} else if (decision == Indeterminate) { atLeastOneError = true;

Hình 4.6: Giải thuật kết hợp Deny-overrides

 Giải thuật kết hợp Permit-overrides

Boolean atLeastOneDeny = false; for (i = 0; i < lengthOf(children); i++) {

Decision decision = children[i].evaluate(); if (decision == Deny) { atLeastOneDeny = true;

} else if (decision == Permit) { return Permit;

} else if (decision == NotApplicable) { continue;

} else if (decision == Indeterminate) { atLeastOneError = true;

Hình 4.7: Giải thuật kết hợp Permit-overrides

 Giải thuật kết hợp First-applicable

Decision firstApplicableCombiningAlgorithm(Node[] children) { for (i = 0; i < lengthOf(children); i++) {

Decision decision = children[i].evaluate(); if (decision == Deny) { return Deny;

} else if (decision == Permit) { return Permit;

} else if (decision == NotApplicable) { return NotApplicable } else if (decision == Indeterminate) { return Indeterminate;

Hình 4.8: Giải thuật kết hợp First-applicable

 Giải thuật kết hợp Only-one-applicable

Node selectedNode = null; for (i = 0; i < lengthOf(children); i++) {

Decision decision = children[i].evaluate(); if (decision == Indeterminate) { return Indeterminate;

} else if (decision == NotApplicable) { continue;

} else { if(atLeastOne) { return Indeterminate;

} else { atLeastOne = true; decisionResult = result; selectedNode = children[i];

Hình 4.9: Giải thuật kết hợp Only-one-applicable

HIỆN THỰC HỆ THỐNG

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

Dựa trên kiến trúc được đưa ra ở chương 4, ở chương này sẽ đưa ra cách hiện thực của hệ thống Hệ thống gồm các thành phần : “PDP Engine”, “Policy Manager”, “Database Manager”, “Attribute Manager”, “Antlr Parse”, “Utility”, “Model”, “Condition Object”

Hình 5.1: Lược đồ thành phần

- Thành phần “PDP Engine”: là trung tâm của hệ thống, đây là nơi nhận các yêu cầu của người dùng Khởi tạo các thành phần khác hỗ trợ cho quá trình đánh giá các chính sách Thành phần này cũng hiện thực các giải thuật kết hợp các chính sách, luật

- Thành phần “Database Manager”: là thành phần quản lý các truy xuất đến database

Hiện tai hệ thống chỉ hiện thực cho phần quản lý truy cập MongoDB

- Thành phần “Attribute Manager”: là thành phần quản lý các thuộc tích của các đối tượng trong hệ thống, cung cấp các thuộc tính này trong quá trình đánh giá các chính sách “Attribute Manager” sẽ sử dụng “Database Manager” để lưu trữ và lấy ra các thuộc tính lưu trữ trong cơ sở dữ liệu

- Thành phần “Policy Manager”: là thành phần quản lý các chính sách phân quyền, lấy ra các chính sách được áp dụng khi có yêu cầu truy cập từ người dùng “Policy

50 Manager” sử dụng “Database Manager” để lưu trữ các chính sách trong cơ sở dữ liệu

- Thành phần “Antlr Parse”: thành phần này phân tích biểu thức điều kiện trong chính sách, luật thành cây luận lý để đánh giá

- Thành phần “Utility”: là thành phần hỗ trợ cung cấp các tiệc ích, cấu hình chương trình, …

- Thành phần “Model”: chứa các mô hình cho các cấu trúc data như thuộc tính, yêu cầu, … giúp cho việc truy xuất dữ liệu trên các cấu trúc này đơn giản hơn

- Thành phần “Condition Object”: là thành phần chứa các mô hình để phân tích biểu thức điều kiện trong chính sách, luật thành cây luận lý.

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

Trong phần này, sẽ mô tả các lớp của hệ thống, cũng như mối quan hệ giữa các lớp đó với nhau Hình 5.2 sẽ mô tả các lớp chính của hệ thống:

Hình 5.2: Lược đồ lớp của hệ thống

51 - Lớp PDPEngine: có lớp chính của chương trình, có nhiệm vụ nhận các yêu cầu từ khối PFP, khởi tạo Evaluate Context chứa các thông tin của yêu cầu và các thông tin cần thiết đề đánh giá các chinh sách, gọi lớp PolicyManager để lấy các chính sách được áp dụng cho yêu cầu, gọi lớp EvaluateHelper để đánh giá các biểu thức điều kiện trong chính sách

- Lớp PolicyManger: có nhiệm vụ quản lý các chính sách, tuy nhiên trong hệ thống hiện tại chỉ tập trung vào khối PDP nên hiện tại lớp này chỉ có nhiệm thêm các chính sách và lấy ra các chính sách được áp dụng cho một yêu cầu

- Lớp AttributeManager: dùng để cung cấp các thuộc tính của thực thể, môi trường, đối tượng được lưu giữ trong cơ sở dữ liệu

- Lớp ExpressionTreeBuilder: có nhiệm vụ phân giải biểu thức điều kiện thành cấu trúc cây để đánh giá sau này

- Lớp EvaluateContext: dùng để chứa các thông tin về yêu cầu, cung cấp các hàm để lấy các thông tin phục vụ cho đánh giá các biểu thức điều kiện

- Lớp EvaluateHelper có nhiệm vụ đánh giá các biểu thức đơn lẻ, lớp này sẽ gọi lớp ExpressionTreeBuilder để phân giải biểu thức điều kiện thành cấu trúc cây rồi đánh giá Trong quá trình đánh giá, sẽ gọi lớp AttributeManager để lấy các thông tin cần thiết

Hình 5.3: Lược đồ lớp chi tiết của hệ thống

Các chính sách được lưu trữ trong mongoDB dưới dạng các document, và khi được truy xuất từ cơ sở dữ liệu, hệ thống sẽ nhận được các dữ liệu dưới dạng json Do đó hệ thống này sẽ sử dụng thư viện spring-mongodb giúp lấy data dưới dạng các mô hình, từ đó việc lấy thông tin của chính sách sẽ đơn giản hơn Để mô hình các chính sách , hệ thống xây dựng các lớp như hình 5.4

Hình 5.4: Lược đồ lớp biểu diễn chính sách

Trong một luật, biểu thức điều kiện (condition) là một biểu thức logic được lưu dưới dạng một cấu trúc, để phân tích cấu trúc sử dụng thư viện Antlr, đây là một thư viện được dùng bởi nhiều hệ thống lớn để phân tích cú pháp như Hive, Pig, Oracle, Antlr hỗ trợ cho ta cú pháp để định nghĩ các dữ liệu có cú pháp và thư viện để phân tích dữ liệu này Hình 5.5 mô tả cú pháp của biểu thức điều kiện trong hệ thống hiện tại

54 condition : logicalExpr EOF; logicalExpr : logicalExpr AND logicalExpr # LogicalExpressionAnd | logicalExpr OR logicalExpr # LogicalExpressionOr | LPAREN logicalExpr RPAREN # LogicalExpressionInParen | comparison_expr # ComparisonExpression | BOOLEAN # LogicalEntity

; comparison_expr : comparison_operand atomicCompare comparison_operand | comparison_operand setCompare comparison_operand

; comparison_operand : arithmetic_expr; atomicCompare : GT | GE | LT | LE | EQ | NE ; setCompare : 'IN' | 'EQ'; arithmetic_expr : MINUS arithmetic_expr # ArithmeticExpressionNegation | LPAREN arithmetic_expr RPAREN # ArithmeticExpressionParens | operand # ArithmeticExpressionNumeric | arithmetic_expr MULT arithmetic_expr # ArithmeticExpressionMult | arithmetic_expr DIV arithmetic_expr # ArithmeticExpressionDiv | arithmetic_expr PLUS arithmetic_expr # ArithmeticExpressionPlus | arithmetic_expr MINUS arithmetic_expr # ArithmeticExpressionMinus ; operand : 'Subject.' ID # OperandSubjectAttribute | 'Resource.' ID # OperandResourceAttribute | 'Environment.' ID # OperandEnvironmentAttribute | 'ResourceData.' fieldName # OperandResourceData

| 'MongoDB' ':' ID ':' ID ':' fieldName ':' ('[' ']' | '[' filter (',' filter)* ']') # OperandDataPath | constant # OperandConstant | '['constant (',' constant)* ']' # OperandArrayConstant | '[' ']' # OperandArrayEmpty ; constant : DECIMAL #ConstantNumber | STRING #ConstantString ; fieldName : ID (('.' INDEX) ? ('.' ID))*; filter : fieldName filter_operation (DECIMAL | STRING); filter_operation: '$eq' | '$gt' | '$gte' | '$lt' | '$lte' | '$ne' | '$in' | '$nin';

Hình 5.5: Biểu diễn biểu thức điều kiện dưới dạng Antlr

Theo hình 5.5, một biểu thức điều kiện, bao gồm các thành phần cơ bản : - Một biểu thức điều kiện và một biểu thức luận lý hoặc các phép toán (AND, OR) trên các biểu thức luận lý

- Biểu thức luận lý là một phép so sánh ( >, >=,