Luận văn thạc sĩ Khoa học máy tính: Điều khiển truy xuất dựa trên thuộc tính

Kiểm soát truy cập dựa trên thuộc tính ABAC Attribute-Based Access Control sử dụng các thuộc tính trên chủ thể, tài nguyên và có thể cả các thực thể khác ví dụ: ngữ cảnh / môi trường và

Mục tiêu và phạm vi đề tài

Luận văn tập trung vào xây dựng hệ thống ABAC từ mô hình kiến trúc, hiện thực, triển khai nhằm bổ sung giải pháp kiểm soát truy xuất linh hoạt cho các hệ thống ứng dụng Cung cấp phương pháp phát hiện xung đột và thuật toán giải quyết xung đột trong quá trình thiết kế chính sách Đồng thời đề xuất áp dụng một số phương pháp để bảo vệ quyền riêng tư của dữ liệu dựa trên thuộc tính theo cấp độ

2 mong muốn Hệ thống có khả năng đáp ứng để sử dụng cho xác thực và cấp quyền truy xuất ứng dụng trên các nền tảng khác nhau thông qua sử dụng các API Service hoặc Core Engine.

Cấu trúc luận văn

 Chương 2: Cơ sở lý thuyết

 Chương 3: Kiến trúc tổng thể của mô hình ABAC

 Chương 4: Vấn đề Conflict rule trong ABAC

 Chương 5: Hiện thực Core ABAC & Đánh giá

Những nghiên cứu liên quan

Một số mô hình điều khiển truy xuất dựa trên thuộc tính đã được các các tác giả nghiên cứu và đề xuất trong tài liệu với xu hướng: mô hình ABAC [1] tổng quát và mô hình ABAC cho một ứng dụng cụ thể, hoặc tích hợp ABAC để cải thiện mô hình truyền thống từ RBAC [2].

ABACα [3] là một trong mô hình đầu tiên ABAC Nó được thiết kế để thể hiện tính linh hoạt của hệ thống ABAC để cấu hình các mô hình DAC, MAC và RBAC ABACα bao gồm subjects, objects và thuộc tính của chúng, mô tả một ngôn ngữ ràng buộc để chỉ định các thuộc tính chủ thể và thuộc tính của các đối tượng truy cập Nhưng không đề cập đến thành phần môi trường (environment) trong chính sách

HGABAC [4] thiết kế một ngôn ngữ chính sách linh hoạt có khả năng cấu hình DAC, MAC và RBAC, đồng thời cũng giải quyết một vấn đề thực tế là gán các thuộc tính cho một tập hợp lớn người dùng và đối tượng HGABAC chỉ định các nhóm phân cấp và cung cấp một cơ chế để kế thừa các thuộc tính từ một nhóm ABAC cho Web services: Đề xuất kiến trúc phân tán để cấp quyền, quản lý, triển khai và thực thi hệ thống ABAC

UCON giải quyết là làm thế nào để xử lý cấp quyền cho thuộc tính và giá trị từ chủ thể và đối tượng, UCON chỉ định các thuộc tính có thể thay đổi và thực thi liên tục

Trong ABE [5], khóa và bản mã của người dùng được gắn nhãn với các tập hợp các thuộc tính mô tả và một khóa cụ thể chỉ có thể giải mã một bản mã cụ thể nếu có sự trùng khớp giữa các thuộc tính của bản mã và khóa của người dùng Vấn đề với lược đồ mã hóa dựa trên thuộc tính (ABE) là chủ sở hữu dữ liệu cần sử dụng khóa công khai của mọi người dùng được xác thực để mã hóa dữ liệu Ứng dụng của lược đồ này bị hạn chế trong môi trường thực vì nó sử dụng quyền truy cập của các thuộc tính đơn điệu để kiểm soát quyền truy cập của người dùng trong hệ thống Hai loại trong ABE đó là: Key-Policy ABE (KP-ABE) và Ciphertext-Policy ABE (CP-ABE) [6] Trong KP-ABE, chủ sở hữu dữ liệu không phải là người có thẩm quyền quyết định về cấu trúc kiểm soát truy cập, nhưng nó là trung tâm phân phối khoá (key distribution center) Trong CP-ABE, mọi bản mã được kết hợp với chính sách truy cập trên các thuộc tính và khóa bí mật (private-key) của mọi người dùng được kết hợp với một tập các thuộc tính Với CP-ABE, chủ sở hữu dữ liệu có toàn quyền kiểm soát hoàn toàn chính sách truy cập

Một số giải pháp dựa vào ABE để cung cấp khả năng kiểm soát truy cập chi tiết cho dữ liệu thuê ngoài Mặc dù các giải pháp hiệu quả để bảo vệ dữ liệu nhưng chúng yêu cầu sử dụng một trung tâm cấp quyền đáng tin cậy (central trusted authority) để quản lý tất cả các thuộc tính và cấp các khóa bí mật liên quan cho người dùng trong hệ thống Do đó, central trusted authority này có thể đạt được một cuộc tấn công ký quỹ (escrow attack) khóa, do biết về khóa riêng của người dùng Ngoài ra còn có một số giải pháp dựa trên ẩn danh quyền riêng tư [7] [8] cho thấy một số tiềm năng hướng tới việc cung cấp một giải pháp thay thế ít phức tạp hơn Tuy nhiên, giải pháp dựa trên ẩn danh không đạt được tất cả các chỉ số đánh giá khác ngoại trừ quyền riêng tư về dữ liệu Kỹ thuật phân vùng dữ liệu cũng được sử dụng, nhưng sự nhấn mạnh của nó là phân vùng dữ liệu dựa trên tính toán, không cung cấp giải pháp cho quyền riêng tư

Giải pháp kiểm soát truy xuất dựa trên thuộc tính (ABAC) kết hợp với việc bảo vệ tính riêng tư của các thuộc tính dữ liệu trong NoSQL [9], [10], [11] đã cung một số phương pháp bảo vệ quyền riêng tư như: masking, anonymization, encryption trong một vài ngữ cảnh

Mặc dù các nghiên cứu liên quan đáng kể đã được công bố cho thấy nhiều ưu điểm của ABAC về tính linh hoạt và bổ sung nhiều hạn chế của các mô hình truyền thống, nhưng vẫn chưa có thỏa thuận về mô hình ABAC chính thức Để đạt được mục tiêu đã nêu trong luận văn, hướng tiếp cận tiếp theo sẽ được trình bày bắt đầu từ một số kiến thức nền tảng làm cơ sở cho những đề xuất giải pháp tiếp theo

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT

Kiểm soát truy cập là một thuật ngữ chung có thể được mô tả như cho phép, hạn chế hoặc từ chối quyền truy cập vào tài nguyên một cách an toàn, do đó bảo vệ tài nguyên khỏi các nguy cơ tiềm ẩn Trong phần này, các phương pháp luận quan trọng nhất để thực thi kiểm soát truy cập sẽ được mô tả Trước khi tiếp tục, một số thuật ngữ chính cần được giải thích vì chúng sẽ được sử dụng trong suốt quá trình này

1 Subject (Chủ thể): thuật ngữ chỉ thực thể đang cố gắng truy cập vào một tài nguyên nhất định Đây có thể là một người, nhưng cũng có thể là một ứng dụng, hoặc bất kỳ hệ thống máy tính nào khác đang cố gắng truy cập tài nguyên

2 Resource/Object (Tài nguyên / Đối tượng): đại diện cho bất kỳ điều gì mà kiểm soát truy cập đang được thực thi Điều này có nghĩa là tài nguyên có thể là cơ sở dữ liệu, quyền truy cập vào ứng dụng, dịch vụ, quyền truy cập vào thiết bị (router, server, firewall), vị trí (cơ quan, tòa nhà)

3 Request (Yêu cầu): đây là một thuật ngữ đại diện cho yêu cầu của chủ thể đối với một tài nguyên

4 Policy (Chính sách): thuật ngữ này đại diện cho một hoặc nhiều quy tắc mà hệ thống kiểm soát truy cập sẽ thực thi khi đánh giá một yêu cầu

Quy trình làm việc điển hình với kiểm soát truy cập sẽ bao gồm: nhận yêu cầu cho một tài nguyên nhất định, đánh giá yêu cầu dựa trên một hoặc nhiều chính sách và cho phép hoặc từ chối yêu cầu tùy thuộc vào kết quả đánh giá Hệ thống thực thi kiểm soát truy cập phải có kiến trúc để tạo điều kiện thuận lợi cho việc thực thi kiểm soát truy cập, một phương pháp đánh giá và các chính sách được xác định rõ ràng để đánh giá các yêu cầu.

Các mô hình kiểm soát truy cập

Trong phần này, một số loại kiểm soát truy cập quan trọng và có ý nghĩa nhất sẽ được trình bày Các ví dụ sẽ được hiển thị và so sánh sẽ được đưa ra khi trình bày từng loại Kiểm soát truy cập

Hình 2.1: Các mô hình kiểm soát truy cập [20]

DAC (Kiểm soát truy cập tùy quyền)

DAC là một loại kiểm soát truy cập thực thi tiêu chí đánh giá (hoặc chính sách) chủ yếu hạn chế quyền truy cập đối với chủ sở hữu hoặc nhóm tài nguyên, cùng với tất cả quyền kiểm soát đối với tài nguyên đó bao gồm cấp quyền truy cập cho các đối tượng khác Nó thường được thực hiện tự động hoặc gián tiếp Người dùng / chủ sở hữu tài nguyên, có quyền kiểm soát quyền truy cập vào tài nguyên Một ví dụ trong hệ điều hành, người dùng tạo tệp có quyền sở hữu chúng và có thể giới hạn quyền truy cập cho chính họ hoặc cho phép người dùng khác truy cập

Bảng 2.1: Quan hệ quyền của chủ thể thực thi trên đối tượng

Bảng 1 có thể được sử dụng để quản lý quyền truy cập vào tệp và hành động trên các tệp đó Người dùng là chủ sở hữu (thường là người tạo) tệp có toàn quyền đối với tệp và có thể thay đổi quyền cho những người dùng khác đối với các tệp đó Điều này có nghĩa là chủ sở hữu có thể cấp hoặc xóa quyền Đọc hoặc Ghi cho bất kỳ người dùng nào khác Nếu người dùng cố gắng thực hiện các hành động trên các tệp mà họ không có quyền, yêu cầu của họ sẽ bị từ chối Bảng bên trái, cột chứa

7 quyền cho những người khác mà chỉ chủ sở hữu mới có thể chỉnh sửa Bảng bên phải hiển thị tập hợp kết quả các hành động được phép cho tất cả người dùng trên tất cả các tệp được sử dụng trong ví dụ này.

Mặt khác, MAC là một loại kiểm soát truy cập trong đó thực thể bên ngoài (thường là quản trị viên) quyết định cấp hoặc từ chối quyền truy cập vào tài nguyên Điều này có nghĩa là các đối tượng cá nhân không thể thay đổi các chính sách và cấp quyền truy cập cho chính mình hoặc các đối tượng khác Một ví dụ sẽ là hệ thống quản lý cơ sở dữ liệu Chúng cho phép truy cập vào tài nguyên tùy thuộc vào quyền mà người dùng có Quản trị viên hệ thống có quyền sở hữu tất cả các tài nguyên và quyền cấp hoặc xóa quyền đối với chúng Các đối tượng / tài nguyên thường được chia thành nhiều loại tùy theo mức độ bảo mật hoặc mức độ quan trọng của chúng Sự phân loại này thường được tổ chức như một hệ thống phân cấp

Ví dụ: các mức bảo mật: TS, S, U hoặc LOW, HIGH Hơn nữa, các chủ thể sẽ có thông tin xác thực phản ánh loại hành động mà họ có thể thực hiện Do đó, các thông tin xác thực này là các quyền và quản trị viên có thể sửa đổi chúng cùng với việc thay đổi danh mục mà một đối tượng / tài nguyên được chỉ định

Bảng 2.2: MAC phân quyền READ/WRITE

Trong Bảng 2 có thể thấy một ma trận ví dụ cho MAC Các giá trị HIGH và LOW đại diện cho các mức danh mục bảo mật cho các đối tượng và chủ thể cho các hoạt động Đọc và Ghi Trong ví dụ này, có thể thấy rằng các đối tượng chỉ có thể thực hiện các hoạt động nếu mức của hoạt động đó bằng hoặc cao hơn mức được chỉ định cho Đối tượng Điều này cho phép người quản trị thực hiện các thay đổi riêng lẻ đối với các tài nguyên hoặc loại đối tượng nhất định nhưng cũng có thể thực hiện các thay đổi toàn cục tại một thời điểm có thể ảnh hưởng đến tất cả

IBAC (Identity-based access control)

IBAC dựa trên việc cấp quyền truy cập vào tài nguyên tùy thuộc vào danh tính người dùng Ví dụ về việc triển khai IBAC sẽ có danh sách những người dùng được ủy quyền và từ chối quyền truy cập vào mọi người dùng không công khai Việc triển khai thường trở thành RBAC vì danh tính được nhóm lại, các nhóm sau đó có các quyền khác nhau hoặc có thể truy cập các tài nguyên khác nhau và do đó chúng có thể được xem như các vai trò IBAC có thể rất chi tiết vì nó có thể có các quyền khác nhau được xác định cho mọi người dùng Trong trường hợp đó, nó có nhược điểm là rất khó quản lý nếu không có một hệ thống quản lý tiên tiến và phức tạp Hầu hết các triển khai đầy đủ sẽ như trong ví dụ đã đề cập trước đây, hoặc hệ thống xác thực dựa trên mật khẩu (thẻ xác thực, vân tay ) giới hạn quyền truy cập vào tài nguyên có thể là tài khoản, phòng bảo mật

RBAC (Role Based Access Control)

RBAC (Điều khiển truy cập dựa trên vai trò) là một hệ thống kiểm soát truy cập nơi người dùng được chỉ định vào các nhóm (hoặc vai trò) có quyền truy cập tài nguyên Quản trị có quyền thay đổi các chính sách truy cập tài nguyên Giải pháp này là một trong những giải pháp phổ biến nhất vì sự đơn giản của việc thực hiện, tính linh hoạt tốt và quản trị trực quan Các vai trò khác nhau có các mức quyền hạn khác nhau Tùy thuộc vào việc triển khai, các vai trò có thể được tổ chức theo cây phân cấp hoặc một danh sách các vai trò hoặc nhóm độc lập đơn giản Hầu hết mọi hệ thống website đều có hệ thống RBAC được triển khai nhằm hạn chế quyền truy cập thông tin, thay đổi và thêm dữ liệu, v.v Người dùng thường được chia thành các nhóm với các cấp độ truy cập khác nhau tùy thuộc vào loại người dùng (người mua, người bán, khách truy cập ) và quản trị viên được chia thành các cấp và khu vực khác nhau (quản trị viên, người điều hành) để duy trì hiệu quả hệ thống Một vấn đề xảy ra với RBAC đó là số lượng lớn các vai trò tạo ra một hệ thống khó quản lý và duy trì Một nhà quản trị cần có hiểu biết sâu sắc về tất cả các vai trò và đối tượng được giao cho những vai trò này để duy trì thành công hệ thống

Bảng 2.3: Nhóm vai trò trong một trang web

Trong bảng bên phải, C, R, U và D được lấy từ từ viết tắt CRUD (Create, Read, Update, Delete), thường được sử dụng trong thuật ngữ trong web

Hình 2.2: Các nhóm chức năng API được thực thi bên trong ứng dụng

ABAC (Attribute Based Access Control)

Sự phức tạp của bối cảnh CNTT ngày nay - ví dụ ứng dụng đám mây, kho dữ liệu, IoT, Dữ liệu lớn - đã bộc lộ những hạn chế của các giải pháp kiểm soát truy cập dựa trên vai trò (RBAC), khiến các tổ chức dễ bị tấn công về khâu bảo mật dữ liệu ABAC hiện đang được sử dụng như một công nghệ thế hệ tiếp theo để truy cập an toàn vào dữ liệu quan trọng của doanh nghiệp

Theo NIST, ABAC được định nghĩa là “một phương pháp kiểm soát truy cập trong đó chủ thể yêu cầu thực hiện các hoạt động trên đối tượng được cấp hoặc từ chối dựa trên các thuộc tính được chỉ định của chủ thể, các thuộc tính được chỉ định của

10 đối tượng, điều kiện môi trường và một bộ chính sách được chỉ định xét về các thuộc tính và điều kiện đó."

Hình 2.3: Attribute-Based Access Control Model [20]

Attributes: Thuộc tính là đặc điểm của chủ thể, đối tượng hoặc điều kiện môi trường Các thuộc tính chứa thông tin được cung cấp bởi một cặp key - value (khóa – giá trị)

Subject: Chủ thể là người dùng con người (hoặc cơ chế hoạt động thay mặt cho người dùng hoặc người yêu cầu), chẳng hạn như thiết bị đưa ra yêu cầu truy cập để thực hiện các hành động trên đối tượng Các chủ thể được gán một hoặc nhiều thuộc tính

Object (hay Resource): Một đối tượng là một thông tin thụ động liên quan đến hệ thống thông tin, nó có thể là tài nguyên hoặc thực thể được yêu cầu, cũng như bất cứ thứ gì mà một chủ thể có thể thực hiện một hoạt động bao gồm dữ liệu, ứng dụng, dịch vụ, thiết bị và mạng

Environmental conditions: Điều kiện môi trường là các yếu tố động, độc lập với chủ thể và đối tượng, có thể được sử dụng như các thuộc tính tại thời điểm quyết định để ảnh hưởng đến quyết định truy cập Ví dụ về các thuộc tính môi trường bao gồm thời gian, vị trí, nhiệt độ, địa chỉ IP v.v

eXtensible Access Control Markup Language (XACML)

XACML (Ngôn ngữ đánh dấu kiểm soát truy cập eXtensible) là một ngôn ngữ dựa trên XML để kiểm soát truy cập đã được tiêu chuẩn hóa bởi Ủy ban kỹ thuật của tổ chức OASIS XACML phổ biến như một phương pháp phân quyền chi tiết (a fine grain authorization method) XACML mô tả cả ngôn ngữ chính sách kiểm soát truy cập, ngôn ngữ yêu cầu / phản hồi và kiến trúc tham chiếu Ngôn ngữ chính sách được sử dụng để diễn đạt các chính sách kiểm soát truy cập (ai có thể làm gì? khi nào?)

Hình 2.5:Các thành phần chính XACML

Ngôn ngữ yêu cầu / phản hồi thể hiện các truy vấn về việc có nên cho phép một truy cập cụ thể hay không (yêu cầu) và mô tả câu trả lời cho các truy vấn đó (phản hồi) Kiến trúc tham chiếu đề xuất một tiêu chuẩn để triển khai các mô-đun phần mềm cần thiết trong cơ sở hạ tầng để cho phép thực thi các chính sách một cách hiệu quả

XACML hỗ trợ kiểm soát truy cập dựa trên thuộc tính (ABAC) và việc đánh giá có thể được thực hiện với dữ liệu bổ sung được truy xuất từ Policy Information Point (PIP) được xác định bởi kiến trúc tham chiếu XACML

Mặc dù phiên bản ban đầu của tiêu chuẩn dựa trên XML, phiên bản XACML 3.0 đã đề cập JSON để đặc tả các chính sách cho mô hình [12]

XML 1 (Ngôn ngữ đánh dấu có thể mở rộng) là một ngôn ngữ đánh dấu được sử dụng để định dạng dữ liệu theo cách mà cả người và máy đều có thể đọc được Nó được xác định bởi một tập hợp các quy tắc để mã hóa, các tài liệu theo Đặc tả XML 1.0 của W3C Mặc dù trọng tâm của thiết kế XML là sử dụng để lưu trữ nhiều loại dữ liệu có cấu trúc khác nhau

JSON [13] (JavaScript Object Notation) là một định dạng trao đổi dữ liệu nhẹ, cú pháp dễ đọc hơn so với XML Mặc dù được xây dựng dựa trên JavaScript, nó hoàn toàn độc lập với ngôn ngữ và lý tưởng để ánh xạ thông tin được lưu trữ trong các đối tượng (trên các ngôn ngữ hướng đối tượng OOP) hoặc cấu trúc, do đó JSON là sự lựa chọn phù hợp để trao đổi dữ liệu giữa các hệ thống với nhau

md:record/md:patient/md:patientDoB

"AttributeId": "urn:oasis:names:tc:xacml:3.0:content- selector",

1 https://en.wikipedia.org/wiki/XML

"urn:oasis:names:tc:xacml:3.0:attribute-category:resource",

"urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"

"Namespace": "urn:example:med:schemas:record" }],

"XPath": "md:record/md:patient/md:patientDoB"

Ví dụ về cú pháp của XML và JSON

Dựa trên khung tham chiếu kiến trúc XACML, phần tiếp theo luận văn hướng tới xây dựng mô hình kiểm soát truy cập dựa trên thuộc tính ABAC; thông qua việc sử dụng kiến trúc các thành phần cơ bản, đặc tả ngôn ngữ chính sách mới dựa trên JSON, hiện thực hệ thống ABAC với các module chức năng của ABAC nhằm tăng cường các giải pháp kiểm soát truy cập cho ứng dụng, đồng thời hệ thống ABAC có thể dễ tích hợp với các mô hình hiện nay

CHƯƠNG 3 KIẾN TRÚC TỔNG THỂ CỦA MÔ HÌNH

Trong phần này, mô hình ABAC được giới thiệu bao gồm: kiến trúc tổng thể của hệ thống ; ngôn ngữ chính sách (policy language) Đây là những mô tả khung kiến trúc nền tảng cho việc triển khai và áp dụng ABAC cho các ứng dụng

 Kiến trúc tổng quan ABAC: triển khai các module phần mềm cho việc lưu trữ các chính sách, thuộc tính cũng như modul tính toán và thực thi các quyết định kiểm soát truy cập dựa trên các chính sách và thuộc tính

 Ngôn ngữ chính sách ABAC: đặc tả các chính sách và xác định yêu cầu cho kiểm soát truy xuất bằng cách sử dụng các rule, các policy và tập policy, được thể hiện thông qua thuộc tính của subject (user), resource, action (hành động), environmental và một tập các thuật toán kết hợp combining các policy và các rule

 Giao thức Request/response trong ABAC: Sử dụng cho truy vấn quyết định được đánh giá từ các yêu cầu truy xuất của chủ thể và phản hồi quyết định.

Kiến trúc tổng quan mô hình ABAC

Các thành phần trong kiến trúc tổng thể minh họa ở hình 3.1 bao gồm: Điểm thực thi chính sách - policy enforcement point (PEP), điểm quyết định - policy decision point (PDP), và điểm quản trị chính sách - policy administration point (PAP), điểm thông tin chính sách - Policy information point (PIP)

Hình 3.1 Kiến trúc tổng quan ABAC

 Điểm thực thi chính sách (PEP): Là một module phần mềm được phát triển có nhiệm vụ tiếp nhận các yêu cầu của user thông qua interface trong từng ngữ cảnh khác nhau, PEP xử lý yêu cầu trích xuất thông tin thuộc tính (subject, resource, action, environment) theo định dạng json để chuyển tiếp cho PDP, sau đó PEP nhận thông tin đánh giá cấp quyền từ PDP và các thông tin tùy chọn (resource, obligations) để phản hồi tới user PEP trả quyết định cho phép thực thi nếu đánh giá quyết định nhận được là “Permit” và kèm thêm điều kiện (obligation) nếu có Nếu không, PEP trả về quyết định Deny Những các chính sách có thể yêu cầu thực hiện các giải pháp liên quan bảo vệ tính riêng tư của dữ liệu đã được trình bày [11], PEP sẽ hỗ trợ trong việc kết nối các API Services để thực thi các quyền sau khi user đã xác thực thành công

 Policy Decision Point (PDP) - Điểm quyết định chính sách: thành phần này chịu trách nhiệm đánh giá, tính toán và đưa ra các quyết định ủy quyền

( authorization decision) dựa trên chủ thể gửi request và các policy mà PDP nhận

17 được từ các điểm truy xuất chính sách - Policy Retrieval Point (PRP), PRP được kết nối với kho lưu trữ policy hoặc truy xuất thông tin thông qua PIP

 PIP (Policy Information Point -Điểm thông tin chính sách): thành phần chịu trách nhiệm truy vấn các thuộc tính: thuộc tính chủ thể, môi trường và tài nguyên

Một policy có thể tham khảo các thuộc tính không có trong request mà chủ thể cung cấp, nó sẽ phải truy vấn các thuộc tính này từ PIP PDP tìm nạp các thuộc tính đó trong khi đánh giá chính sách Để có thể truy cập thông tin PIP trong hệ thống ABAC được tích hợp trong phần hiện thực bởi các module API và Function Libraries

 PAP (Policy Administration Point - Điểm quản trị chính sách): thành phần chứa các chức năng cần thiết để quản lý các kho policy Quản trị viên có thể thực hiện các hành động như tạo, sửa đổi, xóa và tìm kiếm chính sách thông qua giao diện người dùng PAP được phát triển hỗ trợ admin trong việc định nghĩa, thiết kế các chính sách, đồng thời kiểm tra ràng buộc và khả năng đụng độ trong quá trình thêm mới chính sách Thông tin chính sách và các thuộc tính liên quan được lưu trữ và quản lý trên MongoDB [14]

Sự liên kết tương quan các thành phần trong kiến trúc tổng thể ABAC được diễn giải chi tiết như sau:

Bằng cách thực hiện kiểm soát truy cập, hệ thống có thể xác định xem một yêu cầu nên được cho phép hay bị từ chối PEP là thành phần chịu trách nhiệm tiếp nhận các yêu cầu của người dùng và thực hiện các quyết định dựa trên các kết quả tính toán từ PDP phản hồi Khi một chủ thể gửi yêu cầu truy cập tài nguyên thông qua PEP, PEP sẽ gửi yêu cầu truy cập tới trình xử lý ngữ cảnh bao gồm các thuộc tính của chủ thể, tài nguyên, hành động, môi trường Trình xử lý ngữ cảnh tạo ra một thông báo yêu cầu dưới dạng cú pháp json dựa trên các yêu cầu của người dùng và gửi nó đến PDP PDP tiếp nhận thông tin request đã được trích xuất thuộc tính từ cú pháp json, tìm kiếm và đánh giá các chính sách liên quan, sau đó PDP trả về quyết định ủy quyền cuối cùng cho trình xử lý ngữ cảnh (Context Handler) Trình xử lý ngữ cảnh tạo một thông báo phản hồi kết quả và chuyển phản hồi tới PEP để thực

18 thi quyết định đã nhận PDP tham khảo thông tin từ điểm thông tin chính sách (PIP) để đánh giá các yêu cầu của người dùng PIP lưu trữ các thuộc tính bổ sung cần thiết để đánh giá chính sách (ví dụ: subject attribute, resource attribute, and environment attribute)

Một thành phần quan trọng trong hệ thống ABAC để đưa ra quyết định là ngôn ngữ chính sách (policy language) , làm thế nào để xử kiểm soát truy xuất và đưa ra quyết định khi người dùng gửi yêu cầu truy cập Mục đích của định nghĩa ngôn ngữ chính sách là cung cấp các khối cơ bản nhất bên trong một policy, tất cả các thành phần mở rộng có thể được được định nghĩa dựa trên policy model Đầu tiên chúng tôi sẽ tiến hành xây dựng ngôn ngữ chính sách để chỉ định các yêu cầu kiểm soát truy cập bằng cách sử dụng các luật (rules), chính sách (policies) và tập chính sách (policy set) Ngôn ngữ chính sách được xây dựng trên các thuộc tính của chủ thể (subject), tài nguyên (resource) và những hành động (action) thực thi trên tài nguyên đó.

ABAC Policy language

Một chính sách có các khả năng ngăn chặn và phát hiện được sử dụng để đưa ra quyết định truy cập Các thành phần chính trong ngôn ngữ chính sách là: Rule, Policy, Policy Set Các Policy Set bao gồm nhiều tập policy hoặc các policy, và một policy bao gồm một tập các Rules

Hình 3.2: Minh họa các thành phần của ngôn ngữ chính sách

Các Rule là các thành phần bên trong chính sách bao gồm ba phần tử: target, effect, và condition

Phần tử target định nghĩa là tập các yêu cầu mà rule được chỉ định áp dụng dưới dạng các biểu thức logic, đóng một vai trò quan trọng trong việc thu hẹp nhiều chính sách, lọc ra chính sách được áp dụng thông qua so trùng target với các thành phần bên trong của nó Phần tử effect của Rule chỉ định kết quả ("Permit" or

"Deny") sẽ được sử dụng khi kết quả tính toán condition của một rule được thỏa mãn Phần tử condition là một biểu thức boolean sẽ được thực hện, kết quả trả về của condition là ‘True’ hoặc ‘False’ Policy là một tập hợp các rule được nhóm lại bằng cách sử dụng thuật toán kết hợp rule-combining [15]

Hình 3.3: Cấu trúc ABAC policy language

Policy set Trường "id" là một chuỗi hoặc số định danh duy nhất một policy set

Trường "target" sử dụng để định nghĩa điều kiện trên các thuộc tính của phần tử kiểm soát truy xuất, chẳng hạn như các biểu thức Boolean chỉ ra các thuộc tính subjects, resources, actions hoặc environment mà policy set được áp dụng Trường

"policies" lưu trữ một danh sách các policy Trường "algorithm" cho biết tên các giải thuật combining được kết hợp để tính toán cơ sở quyết định cuối cùng dựa trên việc kết hợp các kết quả của các policy và policy set Trường "priority” là một giá trị number cho biết độ ưu tiên được sử dụng để giải quyết xung đột với các bộ chính sách khác

"policies": ["policy block", "policy block","policy block" ],

"algorithm": ("permit-overrides"| "deny-overrides"|"first-applicable"|"highest- priority"),

Policy block Một policy bao gồm các phần tử: id, target, policies_id, collection_name, action, rule, algorithm, tag_views, priority Điểm khác biệt là policy có một phần tử “Rules” là một array chứa nhiều rule bên trong Trường

“collection_name” là thông tin về một tài nguyên, action: là các hành động của chủ thể đối với tài nguyên khi truy vấn

"action": ["read"|"write"|"delete"|"update"],

"rule": [, , , ],

"algorithm": ("permit-overrides" | "deny-overrides" | "first-applicable" | "highest- priority"),

Rule block Các rule cho phép chỉ định các điều kiện trực tiếp trên subject, action resource, và environment hoặc trên các thuộc tính của chúng Một khối bao gồm một phần tử "condition" chỉ định điều kiện để áp dụng rule và phần tử "effect", nếu rule được áp dụng thì quyết định trả về của rule là giá trị của effect (Permit hoặc

Deny) So với các biểu thức boolean bên trong target, một condition thường phức tạp hơn và bao gồm các hàm (ví dụ., greater-than, less-than, equal) để so sánh giá trị thuộc tính và các phép toán logic (and, or), có thể kết hợp nhiều điều kiện Nếu quyết định cuối cùng của biểu thức hoặc hàm ( expressions/functions ) trong target

(hoặc trong condition) không thỏa mãn thì quyết định trả về của rule là Not

"condition": {condition_list_of_rule}

Ví dụ, chính sách của rule 1 là “professors” hoặc “assistants” có thể xem thông tin về điểm của sinh viên theo lớp học phần đăng ký Nếu thỏa điều kiện

String_Equal(Subject.role,"professor") OR String_Equal(Subject.role,"assistants"), thì giá trị của effect sẽ là "Permit"

"parameters": [{ "value": "active", "resource_id": "Subject" }, { "value": "true" }]},

"parameters": [{"value": "role","resource_id": "Subject" }, {"value":

"parameters": [{"value": "role","resource_id": "Subject"}, {"value":

ABAC Request/Response

Request Mô tả kịch bản phía người dùng, một request bao gồm một số thuộc tính và các thuộc tính bao gồm trong bốn danh mục: subject, resource, action, và environment Một request là một JSON Object chứa cặp name/value (thuộc tính/giá trị) với thuộc tính được xác định trước Mỗi giá trị của thuộc tính có thể là JSON value bất kỳ (ví dụ: object, array, number, string, true, false, hoặc null)

Một ví dụ request JSON

"attributes": {"collection_name": " student-score"}

Response thông thường là quyết định trả về từ PEP chứa các thuộc tính decision, resource, các obligation đi kèm (hoặc environment).

Trong ví dụ trên, khi chủ thể Khanh có vai trò là “professor”, gửi yêu cầu xem điểm của sinh viên Minh họa như hình 3.1 sẽ hiển thị quy trình xử lý quá trình này Đầu tiên, yêu cầu từ phía người dùng được PEP thu nhận (bước 1) và gửi đến trình xử lý ngữ cảnh (Context handler) ở (bước 2) Sau đó yêu cầu được kiểm tra định dạng cấu trúc và thực hiện quá trình trích xuất thuộc tính (được thực hiện ở bước 3,4) để tạo ra các request object ở định dạng JSON và chuyển tiếp đến PDP (bước 5) PDP chỉ tìm nạp các policy dựa trên target, sau đó lọc các policy dựa trên sự phù hợp với yêu cầu cấp quyền (bước 6, 7) Quá trình này được thực hiện bằng cách so sánh bốn

23 thuộc tính (chủ đề, tài nguyên, hành động và môi trường) trong phần target của một chính sách với các thuộc tính tương ứng trong một request (JSON object) Để mang lại hiệu quả hơn và dễ dàng đánh giá, yếu tố target trong mỗi chính sách đóng một vai trò quan trọng trong việc thu hẹp nhiều chính sách thành những chính sách chỉ áp dụng cho một request nhất định Đánh giá chính sách không nhất thiết phải đánh giá tất cả các chính sách được lưu trữ Khi tìm thấy chính sách tương ứng với yêu cầu, PDP truy xuất thông tin thuộc tính liên quan, PDP gọi PIP để yêu cầu phản hồi bổ sung (bước 8.1, 8.2) Kết quả phê duyệt cuối cùng được xác định dựa trên đánh giá ( evaluates) và tổ hợp ( combines ) của các rule liên quan Cuối cùng, PDP đánh giá và phản hồi kết quả theo từng bước 9, 10, 11.

Policy evaluation

Để đưa ra quyết định cuối cùng cho việc cấp quyền truy xuất khi nhận một request, PDP đánh giá tất cả các tập policy hiện có so với thông tin nhận được từ PEP Mỗi tập policy và policy sẽ tính toán để đưa ra các quyết định d = {Permit, Deny, Not_Applicable, Indeterminate} Vì một Policy có thể chứa nhiều rule và một PolicySet có thể chứa nhiều Policy hoặc PolicySet Với mỗi Rule, Policy có thể đánh giá các quyết định khác nhau (Cho phép, Từ chối, Không áp dụng) PDP có thể sử dụng các thuật toán kết hợp (combining algorithm) để giải quyết xung đột đối với các trường hợp cho nhiều kết quả quyết định khác nhau

Chiến lược giải quyết xung đột được áp dụng khi có sự chồng chéo, các policy hoặc các rule có thể xung đột và đưa ra các quyết định hoàn toàn khác nhau (cả Permit and Deny) cho cùng một request ABAC giải quyết vấn đề này bằng cách áp dụng một số thuật toán kết hợp quyết định ở các cấp độ khác nhau, chẳng hạn như thuật toán kết hợp rule-combining của một policy và thuật toán policy-combining [15] của một tập các policy (policy set) Một vài thuật toán kết hợp tiêu chuẩn được triển khai bao gồm:

 Permit-Overrides: Nếu bất kỳ rule (hoặc policy) trong tập đánh giá là Permit, thì tổ hợp đánh giá combining của tập rule (hoặc policy) là Permit

 Deny-Overrides: Nếu bất kỳ rule (hoặc policy) trong tập đánh giá là Deny, thì tổ hợp đánh giá combining của tập rule (hoặc policy) là Deny

 First - Applicable: Mỗi rule (hoặc policy) được đánh giá theo thứ tự được liệt kê trong policy (hoặc policy set), quyết định cuối cùng được trả về là quyết định (output) đầu tiên được thực hiện là Permit hoặc Deny

 Only-One-Applicable: Thuật toán chỉ được sử dụng trong việc kết hợp policy- combining của một bộ chính sách, nó phải đánh giá tất cả các chính sách để đưa ra đánh giá cuối cùng Nếu chỉ áp dụng một quyết định, thì kết quả của quyết định Permit hoặc Deny; nếu nhiều hơn một quyết định được áp dụng, thì kết quả là Indeterminate

 Highest - Priority: áp dụng đánh giá quyết định ưu tiên cao nhất Nếu có nhiều quyết định có cùng mức độ ưu tiên cao nhất, thì thuật toán Deny - Overrides sẽ áp dụng trong số đó

Policy evaluation Giá trị policy được gán phụ thuộc vào kết quả đánh giá target và condition của policy (các kết quả condition có thể đạt được true hoặc fasle) Bảng 4 cung cấp giá trị trả về của policy

Target Expression Condition Policy Value false (not matching) don’t care Not_Applicable true (matching) false Not_Applicable error don’t care Indeterminate true (matching) Error Indeterminate true (matching) true Effect (Permit hoặc Deny)

Policy Set: Giá trị quyết định (Not_Applicable, Indeterminate, Permit hoặc Deny) cũng có thể được chỉ định cho một policy set Giá trị này phụ thuộc vào kết quả đánh giá của target expression trong policy set

Target Expression Condition Policy Set Value false (not matching) don’t care Not_Applicable true (matching) don’t care Kết quả Combining

Algorithm được áp dụng cho các chính sách

Rule evaluation

Như đã đề cập, một target hoặc một condition là một biểu thức boolean chỉ định ràng buộc trên các thuộc tính của subject, resouce, environment và hành động của request

Biểu thức boolean của một target thường đơn giản, nhưng biểu thức của một condition đôi khi có thể phức tạp với các ràng buộc về đánh giá nhiều thuộc tính có thể sử dụng các toán tử so sánh (Equal, Greater, Less, GreaterOrEqual hoặc toán tử logic(and, or) giữa thuộc tính và tham số

Target Expression Condition Rule Value

Match hoặc no target True Effect

Match hoặc no target Fasle Not_Applicable

Match hoặc no target Indeterminate Indeterminate (P) nếu effect là Permit hoặc Indeterminate (D) nếu effect là Deny

No - match Don’t care Not_Applicable

Indeterminate Don’t care Indeterminate (P) nếu effect là Permit hoặc Indeterminate (D) nếu effect là Deny

Nếu target là thỏa mãn, rule được áp dụng Nếu tất cả các điều kiện của rule thỏa điều kiện “true” thì giá trị của rule là giá trị của effect (“Permit” hoặc “Deny”) Nếu request cung cấp thiếu thông tin hoặc có sự nhập nhằng giữa các policy, rule, PDP có thể trả kết quả Indeterminate hoặc NotApplicable Các trường hợp khác giá trị trả về của rule có thể được gán thông qua bảng Rule evaluation

Environment attribute Thuộc tính Environment trong ngôn ngữ chính sách như một nghĩa vụ được chỉ định tùy chọn (optional) trong một Rule, một Policy hoặc một PolicySet Khi PDP đánh giá một bộ chính sách có chứa các biểu thức nghĩa vụ, nó sẽ đánh giá các biểu thức nghĩa vụ và trả lại các nghĩa vụ đó cho PEP cùng với việc thực thi quyết định ủy quyền Ví dụ: chỉ cho phép truy cập vào hệ thống có địa chỉ IP cục bộ "192.168.10.201"

Decision: Quyết định cho PEP biết nên cấp hay từ chối quyền truy cập Chỉ cấp quyền truy cập nếu quyết định là "Permit" Thuộc tính quyết định có thể là một trong các giá trị sau với các ý nghĩa được mô tả:

26 o "Permit": Quyền truy cập phải được cấp o "Deny": Quyền truy cập phải bị từ chối o "Not_Applicable ": Không thể đưa ra quyết định vì không có chính sách nào được áp dụng cho đăng ký ủy quyền PEP nên từ chối quyền truy cập o "Indeterminate ": Không thể đưa ra quyết định vì đã xảy ra lỗi PEP nên từ chối quyền truy cập trong trường hợp này.

Function expressions

Để đảm bảo tính linh hoạt, các phần khác nhau của policy có thể là các biểu thức trong Target, biểu thức trong Condition của các Rule được tính toán tại thời điểm thực thi ABAC cung cấp ngôn ngữ biểu thức thống nhất cung cấp các tính năng hữu ích và có khả năng dễ đọc, viết cho lập trình viên Vì JSON là mô hình dữ liệu cơ sở, mỗi expression đánh giá một kiểu dữ liệu JSON Các kiểu dữ liệu và cú pháp expression được mô tả trong phần này

JSON (JavaScript Object Notation) [16], [17] là một định dạng để biểu diễn dữ liệu dạng văn bản theo cách có cấu trúc JSON có cấu trúc giống với XML nhưng khác về syntax/format JSON là Lightweight hơn so với XML trong lưu trữ dữ liệu Trong JSON, dữ liệu được biểu diễn ở một trong hai dạng - dưới dạng một đối tượng (object) hoặc một mảng (array) giá trị Một đối tượng JSON dưới dạng tập hợp các cặp key - value , trong đó Key chỉ đơn giản là một chuỗi biểu thị tên của thuộc tính và value là một trong các kiểu: String, number, boolean, null, object hoặc một array

Hình 3.4 Cấu trúc dữ liệu JSON Định nghĩa của một đối tượng JSON là đệ quy trong đó một đối tượng có thể chứa các đối tượng khác Mảng được định nghĩa là một tập hợp các giá trị có thứ tự Dữ liệu JSON thể hiện các đặc điểm sau

Dữ liệu JSON tạo thành cấu trúc phân cấp cây gốc o Trong cây, các nút lá đại diện cho các giá trị và một nút không phải lá đại diện cho các khóa o Một nút trong cây, có thể được xác định duy nhất bằng một đường dẫn duy nhất

ABAC dựa trên Json để biểu diễn dữ liệu có cấu trúc Mọi giá trị của thuộc tính và các expression bên trong policy được biểu diễn và đặc tả theo cú pháp Json Các kiểu JSON và ký hiệu là:

 Primitive Types o Number: Được biểu diễn trong cơ số 10 và các định dạng bát phân và thập lục phân không được sử dụng Ví dụ: { "age": 36 } o String: Một chuỗi rỗng hoặc nhiều ký tự, được viết trong dấu ngoặc kép hoặc dấu nháy đơn, ví dụ: "một chuỗi" hoặc { "name":"studentA" } o Boolean: Kiểu dữ liệu luận lý có thể là true or false Ví dụ { "result" : true } o Null: Chỉ định một giá trị rỗng - null

 Object: Một tập các cặp name/value không có thứ tự, name đại điện cho tên các attribute và value là giá trị của kiểu dữ liệu đã được định nghĩa như trên Bản thân nó cũng có thể là một object Cú pháp {key: value, ….}

"student":{ "name":"Tinh", "age":36, "score": 7.6}

 Array: là một tập hợp các giá trị có thứ tự và bắt đầu bằng [(ngoặc trái) và kết thúc bằng] (ngoặc phải) Các giá trị của mảng được phân tách bằng dấu, (dấu phẩy)

Ví dụ: [ "A value", 10 , {"attribute" : "value"]

Vì tính đơn giản của nó, JSON nhỏ gọn hơn, yêu cầu ít bit hơn để lưu trữ, truyền qua mạng và xử lý trên thiết bị di động và thiết bị nhúng Hiện nay JSON đang chiếm ưu thế trong lưu trữ NoSQL (document stores) như MongoDB và CouchDB Ngoài ra, JSON cung cấp cho các nhà phát triển sức mạnh tổng hợp cao hơn với ngôn ngữ lập trình mà họ lựa chọn và cho phép lưu trữ trực tiếp, nguyên bản cho dữ liệu đang truyền từ thiết bị di động, thông qua lớp ứng dụng vào đĩa Điều này làm giảm chi phí chuyển đổi và tách dữ liệu

Các biểu thức sử dụng trong ABAC bao gồm các biểu thức cơ bản và các biểu thức toán tử (được tạo từ các biểu thức khác sử dụng các toán tử)

 Value Expression: một giá trị cụ thể trong ký hiệu json (ví dụ: “value”)

 Identifier Expression: tên của một biến hoặc thuộc tính của request (subject, resource, action, hoặc environment)

 Function Expression: Một hàm cụ thể, hoặc một lời gọi hàm, ví dụ Acess_Rules[i].Condition.FunctionName()

Một function expression bao gồm tên hàm FunctionName (parameter 1, parameter

2,…) và các đối số Các biểu thức hàm lập trình sẵn và được tích hợp trong hệ thống Core ABAC phục vụ chức năng tính toán của PDP Khi đánh giá một biểu thức hàm, các biểu thức đại diện cho các đối số gọi hàm được đánh giá trước Sau đó, kết quả được chuyển cho hàm dưới dạng đối số Biểu thức đánh giá giá trị trả về của hàm ABAC cung cấp các toán tử số học, so sánh, logic, chuỗi có thể được sử dụng khi xây dựng các biểu thức

Toán tử số học: Giả sử exp1 và exp2 là các biểu thức đánh giá dạng số, các toán tử sau có thể được áp dụng

Toán tử so sánh: {, =, =, in }

Rule Điều kiện trong Policy Thông tin Request

Bảng 3.4: Các toán tử so sánh

Toán tử logic: giả sử exp1 và exp2 là các biểu thức đánh giá đúng hoặc sai, các toán tử sau có thể được áp dụng Biểu thức mới được đánh giá là true hoặc false:

 exp1 || exp2 (logical OR) Điểm khác biệt giữa AND là lazy evaluation, trong khi phép OR là eager evaluation

Rule Điều kiện trong Policy Thông tin Request

And 'Score': And(Greater(50), Less(89)) 'score': 79

Or 'Score': Or(Greater(50), Less(100), Eq(80)) 'score': 79

Bảng 3.5: Các toán tử logic

MongoDB

MongoDB là một chương trình cơ sở dữ liệu hướng tài liệu hỗ trợ đa nền tảng, lưu trữ dữ liệu bằng các mô hình linh hoạt Được phân loại là một chương trình quản lý cơ sở dữ liệu NoSQL, cơ sở dữ liệu NoSQL rất đa dạng dựa trên data model, MongoDB sử dụng các loại chính: document, key-value, wide-column, và graph giống như cấu trúc JSON với các lược đồ tùy chọn

Khi có sự thường xuyên thay đổi schema như các dự án agile thì đây là ưu điểm cho phép các các lập trình viên tập trung vào business logic và giải thuật thay vì phải tập trung vào schema MongoDB cung cấp các schema linh hoạt, dễ dàng mở rộng quy mô theo chiều ngang (horizontal scaling - scale-out across commodity servers) với lượng lớn dữ liệu và người dùng Khi lựa chọn cơ sở dữ liệu cho mục đích chung như web app thì MongoDB là lý tưởng cho phép các nhà phát triển xây dựng các ứng dụng không cần quản lý cơ sở hạ tầng cơ sở dữ liệu, cùng với sự linh hoạt của việc sử dụng bất kỳ ngôn ngữ lập trình

Minh họa hệ thống là một database lưu trữ thông tin các thực thể liên quan đến chính sách Để quản lý thuộc tính của mỗi subject và object và dữ liệu khác

Hình 3.5: Chính sách lưu trữ trên MongoDB

CHƯƠNG 4 VẤN ĐỀ CONFLICT RULE TRONG ABAC

Thách thức đối với hệ thống kiểm soát truy cập ABAC là số lượng lớn các thuộc tính của subject, resource có sử dụng trong quá trình tính toán đưa ra quyết định bởi PDP, điều này dẫn đến khả năng xung đột chính sách ở các cấp độ khác nhau: cấp độ tập policy, tập các rule

Dựa trên sự phân tích và đánh giá chiến lược giải quyết xung đột giữa các rule trong cùng một policy và giữa các policy trong tập policy set đã được trình bày trong phần 3.4, để nhận dạng khả năng đụng độ và hỗ trợ quá trình thiết kế các policy sẽ được hiện thực như một phần của điểm quản lý chính sách PAP Một số các vấn đề liên quan đến phát hiện và giải quyết những conflict rule trong quá trình thiết kế policy của module chức năng PAP trước khi public các policy cho PDP được xem xét.

Nhận dạng vấn đề conflict

Mặc dù trong 3.4 cũng đã cung cấp các giải thuật combining để giải quyết xung đột giữa các các policy, những giải thuật được áp dụng bởi PDP chỉ cung cấp phương pháp động để giải quyết xung đột đến từ request, không được chọn để phát hiện xung đột giữa các policy, vì vậy xung đột giữa các rule vẫn còn tồn tại trong quá trình thiết kế policy mới Có nhiều nghiên cứu liên quan đến phát hiện xung đột: static conflict (xung đột tĩnh) và dymanic conflict (xung đột động)

Phương pháp phát hiện xung đột tĩnh: thực hiện trước khi hệ thống thực thi, phát hiện trước và giải quyết trước các xung đột liên quan đến thiết kế policy, cải thiện và tăng hiệu suất cho quá trình tính toán quyết định đưa ra bởi PDP Phương pháp phát hiện động chỉ thực hiện tại thời điểm hệ thống thực thi (run time)

Phương pháp phát hiện xung đột tĩnh không phụ thuộc vào user khi gửi yêu cầu truy xuất hệ thống, trong khi phương pháp động lại phụ thuộc bởi các giá trị thuộc tính của user để phát hiện xung đột So với dymanic conflict thì phương pháp phát hiện static conflict có nhiều ưu điểm hơn Một số định nghĩa về biểu thức thuộc tính được đề cập cho quá trình phát hiện các conflict

32 Định nghĩa 1: Một biểu thức điều kiện dựa trên thuộc tính a_exp định nghĩa phép toán so sánh giữa giá thuộc tính với giá trị của ngữ cảnh Các toán tử a_exp có thể là {, =, =}

Ví dụ: "condition": " ( Resource.dept_id >= 20 )" Định nghĩa 2: Một rule được mô tả R = (S, R, OP, d), chỉ định một tập các hành động (CRUD) của Subject thực thi trên các Resource, được gán bởi tập quyết định d

= {permit, deny} Trong đó S và R là đại diện cho các biểu thức thuộc tính so sánh của subject và resource a_exp = {a_exp1, a_exp2, … , a_expn} OP là tập các action mà S được quyền thực thi trên R: OP = {“read”, “write”, “update”, “delete”} Định nghĩa 3: Một request Req = (Sreq, Rreq, areq) mô tả một yêu cầu xác thực và cấp quyền truy xuất hệ thống

Với những đặc tả của rule trong policy, những rule khác nhau có thể áp dụng cho cùng một request của chủ thể, điều gì xảy ra nếu quyết định áp dụng giữa các rule là khác nhau? Cho ví dụ conflict rule 01, rule 02

Vấn đề một request của user có thể áp dụng cả 2 quyết định bởi các rule, đây gọi là conflict trong policy Chi tiết các vấn đề conflict trong ABAC đã được chỉ ra trong [18] Định nghĩa 4: Một conflict rule xảy ra giữa Ri và Rj trong cùng một request (req) của user

(1) Hai rule được áp dụng cho request

(Rule[i].Sreq == Rule[j].Sreq) && (Rule[i].Rreq == Rule[j].Rreq)

(2) Các decision của hai rule là khác nhau

Một conflict xảy ra giữa các rule có thể xảy ra khi chúng có cùng thuộc tính của S,

R và tập giá trị của giao nhau giữa hai rule là khác rỗng, ví dụ:

Trong đó, (3) và (4) là dấu hiệu định nghĩa khả năng có thể xảy ra conflict Định nghĩa 5: Hai Rule[i] và Rule[j] xảy ra khả năng conflict trong policy nếu:

(1) Một rule chia sẽ các thuộc tính định danh (a) với rule khác, giả sử Rule[i] chia sẽ tất cả các thuộc tính định danh với Rule[j] Khi đó,

∀ a ∈ (Rule[i] Sa ∪ Rule[i].Ra), ∃ a’ ∈ (Rule[j] Sa’ ∪ Rule[j].Ra’) => a a’

S a , S a’ : lần lượt là thuộc tính của subject; R a, R a’ : thuộc tính resource Điều kiện xảy ra (Rule[i].Sa == Rule[j].Sa’) && (Rule[i].Ra = Rule[j].Ra’)

(2) Một conflict xảy ra giữa các rule có thể xảy ra khi chúng có cùng thuộc tính của S, R và tập giá trị của giao nhau giữa hai rule là khác rỗng, ví dụ: (Rule[i].Sa ∩ Rule[j].Sa’) != {∅};

Các function trong biểu thức điều kiện Condition có cùng thuộc tính sẽ được tính toán

(3) Quyết định trong hai rule là khác nhau: d(Rule[i]) != d(Rule[j]); Định nghĩa 6: Các chính sách tương đương về ngữ nghĩa

Cho hai chính sách P = {Rule1, Rule2,…,Rulen} và P’ = {Rule’1,Rule’2,…,Rule’n}là tương đương ngữ nghĩa nếu:

 Với mọi tuple của Rule = (S, R, OP) và bất kỳ quyết định d của một chính sách cũng có thể tìm thấy trong một chính sách khác

 Trả về cùng tập quyết định khi đánh giá chính sách cho một request bất kỳ

Phương pháp xử lý conflict

Theo định nghĩa 5, 6 vấn đề conflict Rule[i] và Rule [j] là phương pháp chi tiết để phân tích trong số các rule của chính sách, từ đó kết quả được tổng quát hoá và sử dụng cho việc xác định khả năng conflict các policy với nhau Phần tiếp theo sẽ định nghĩa khả năng conflict giữa các rule trong cùng policy và giữa các policy trong tập policy

 Conflict các rule trong một policy (local level)

 Conflict các rule với các rule trong policy khác (global level)

Một Policy P = { PolicyId, Target, CollectionName, RuleCombining, Action,

Rules} và Policy P’ = { PolicyId, Target, CollectionName, RuleCombining, Action, Rules}

Có khả năng tương đương hoặc conflict khi:

(1) Tất cả các giá thuộc tính của subject và object của rule trong policy P tương ứng với các rule trong P’ (theo định nghĩa 5)

(2) Các giá trị của thuộc tính khác trong Policy P lần lượt trùng hoặc có mặt trong policy P’ Để xác định chính xác các chính sách có khả năng đụng độ, kỹ thuật phân lớp và tách các miền giá trị thuộc tính trùng nhau được sử dụng khi giải quyết đụng độ Phương pháp nhận dạng, xử lý các trường hợp đụng độ rule trong policy và giữa các policy với nhau được thực hiện theo các bước như sau:

(1) Trích xuất thông tin attribute của subject và resource khi thêm mới

(2) Tính toán các attribute giống nhau của subject và resource giữa các rule input Phân lớp các policy tương đồng

Tính toán các miền giao trên tập rule [i, j]

Kiểm tra conflict giữa các rule

Xử lý conflict (loại bỏ, tách)

Policy đã xử lý conflict

Cập nhật policy sau xử lý

(3) Tính toán tập giá trị giao (∩)giữa giá trị thuộc tính của subject rule[i] với rule[j] , tính toán tập giao (∩) giữa giá trị thuộc tính của resource rule[i] với rule[j]

(4) Từ kết quả tính toán bước 3, và định nghĩa 4,5,6 để xác định vấn đề trùng lặp hoặc conflict Để có thể thực hiện việc kiểm tra so sánh hai policy bất kỳ, đồng thời có thể truy xuất thông tin cụ thể của cặp key/value các thuộc tính Model các lớp class của ngôn ngữ được xây dựng theo cấu trúc đặc tả trong ngôn ngữ chính sách ABAC ở phần trước, điều này phù hợp với các ngôn ngữ lập trình hiện đại để xử lý và truy xuất thông tin thuộc tính dữ liệu qua model, chi tiết một policy tương ứng với class thông tin policy collection được minh họa: public class PolicyViewModel

{ public string CollectionName { get; set; } public string PolicyId { get; set; } public string Description { get; set}; public string RuleCombining { get; set}; public string Action { get; set; } public string Target { get; set; } public ICollection Rules { get; set; }

} public class Rule { public string Id { get; set; } public string Effect { get; set; } public string Condition { get; set; } } public class Condition { public string function_name { get; set; } public List parameters { get; set; } } public class Parameter { public string value { get; set; } public string resource_id { get; set; } }

Với mỗi policy khi thêm mới được truyền qua model với các thông tin từ command var accessControlModel = new APolicy()

// Load Rule from policy var accessControlRules = new List(); foreach (var rule in command.Rules)

{ var condition = _ExpressionService.Parse(rule.Condition); var accessControlRule = new ARule()

Các thông tin Key/Value của attribute bất kỳ được xử lý thông qua FunctionName và các Parameters

Ví dụ cho một rule bên policy được khai báo; các FunctionName là: StringEqual ,

Or, StringEqual , các tham số : Subject.role

"condition": "StringEqual ( Subject.role , professor ) Or StringEqual ( Subject.role , student_care )"

Các hàm chức năng thực hiện việc chuyển đổi qua lại giữa các toán hạng và toán tử để phù hợp với yêu cầu cần tính toán giá trị Minh họa cho rules trên thì

FunctionName là toán tử ở giữa if (func.FunctionName.Equals("And") || func.FunctionName.Equals("Or"))

{ result += Convert2(func.Parameters[0]) + " " + func.FunctionName + " " +

Như vậy cặp key/value có thể được gọi thông qua cú pháp các hàm với Parameters[0] Value: là tên của attribute , Parameters[1].Value: là giá trị của attribute var a = accessControlRules[i].Condition.Parameters[0].ResourceID + "." + accessControlRules[i].Condition.Parameters[0].Value; var b = accessControlRules[j].Condition.Parameters[0].ResourceID + "." + accessControlRules[j].Condition.Parameters[0].Value;

Tên hàm được truy cập bởi: accessControlRules[j].Condition.FunctionName

Phương pháp tiếp cận thông qua xây dựng Model view như trên có thể cung cấp toàn bộ thông tin cho quá trình phát hiện thông tin dư thừa và conflict giữa các rule, policy với nhau Các hàm liên quan đến toán tử so sánh có thể được phát hiện khả conflict ngầm định giữa các rule

Trong một số trường hợp ví dụ sau việc phát hiện conflict giữa các rule, policy là tường minh

"condition": "StringEqual ( Subject.role , tinh)"

"condition": "StringEqual ( Subject.role , tinh )"

Minh họa giải thuật kiểm tra khả năng conflict hai rule tường minh như trên private HasDuplicate_Rule(sl) { var out = []; for (var i = 0, l = sl.length; i < l; i++) { var unique = true; for (var j = 0, k = out.length; j < k; j++) { if ((sl[i].effect === out[j].effect) && (JSON.stringify(sl[i].condition )==JSON.stringify(out[j].condition))) { unique = false; this.msgs.push({ detail: "Conflict 2 rule local - Duplicate" });

} if (unique) { out.push(sl[i]);

Tuy nhiên, một số trường hợp các rule có thể khác nhau về giá trị các biểu thức thuộc tính attribute, đây là trường hợp khó xác định khả năng conflict rule như ví dụ minh họa đưới đây: rule 01 cho phép sinh viên có điểm trung bình >=7 được phép đăng ký học vượt, nhưng rule 02 lại cấm những sinh viên có điểm trung bình