Bảo mật trong các mô hình này chủ yếu dựa trên: xác thực người dùng, mã hoá dữ liệu trước khi lưu trữ, tận dụng cơ chế bảo mật của hệ thống file, phân quyền mức dịch vụ, hay gần đây nhất
GIỚI THIỆU
Giới thiệu đề tài
Ngày nay, việc tăng trưởng các nhu cầu cung cấp dịch vụ thông qua các hệ thống phân tán, mạng xã hội hay các dịch vụ trực tuyến trên điện toán đám mây đã tạo ra một nhu cầu rất lớn cho việc phát triển hệ thống lưu trữ Các hệ thống lưu trữ hiện tại theo hướng cấu trúc đã không còn đủ khả năng hỗ trợ các hệ thống này Các chuyên gia đều cho rằng các dữ liệu được lưu trữ dưới dạng cấu trúc chỉ chiếm khoảng gần 20% dữ liệu được lưu trữ cho các hệ thống bên ngoài [20], 80% còn lại được lưu trữ dưới dạng bán cấu trúc và không có cấu trúc Thuật ngữ dữ liệu không có cấu trúc ra đời nhằm mở ra một hướng mới cho công nghệ lưu trữ dữ liệu và cũng là tiền đề cho nhiều ngành khoa học có thể phát triển mạnh về sau
Dữ liệu không có cấu trúc được lưu trong các cơ sở dữ liệu NoSQL Đặc điểm chính của các mô hình này là: hỗ trợ tốt các loại dữ liệu từ có cấu trúc, bán cấu trúc đến không có cấu trúc Mô hình dữ liệu đơn giản, ngôn ngữ truy vấn dữ liệu đơn giản, khả năng mở rộng và độ tin cậy cao Tuy nhiên cơ chế bảo mật còn thô sơ và đơn giản Bảo mật trong các mô hình này chủ yếu dựa trên: xác thực người dùng, mã hoá dữ liệu trước khi lưu trữ, tận dụng cơ chế bảo mật của hệ thống file, phân quyền mức dịch vụ, hay gần đây nhất là hỗ trợ mô hình điều khiển truy xuất dựa trên vai trò
Với các đặc điểm về khối lượng lớn, tính đa dạng về mặt lưu trữ, sự phát triển liên tục của dữ liệu không cấu trúc, thì việc bảo vệ dữ liệu trong các hệ thống này là vô cùng khó khăn
Một trong những vấn đề bảo mật đang rất được lưu ý hiện nay là vấn đề điều khiển truy xuất Việc cung cấp quyền truy xuất cho dữ liệu ngày càng phức tạp, các mô hình điều khiển truyền thống như DAC, MAC, RBAC và những mở rộng của chúng gặp nhiều hạn chế và không còn phù hợp Đối với mô hình điều khiển truy xuất tùy quyền (DAC), dữ liệu có thể được truy cập trái phép bởi người dùng bởi vì không có điều khiển truy xuất trên bản sao chép của dữ liệu trong mô hình này Mặt khác trong mô hình điều khiển truy xuất bắt buộc (MAC) giải quyết vấn đề này bằng cách gán các cấp bậc bảo mật trên cả người dùng và dữ liệu, hệ thống áp dụng MAC phải có mức độ phân cấp ở phía người dùng và dữ liệu Tất cả người dùng bắt buộc phải có một mức bảo mật nhất định mới có quyền truy cập dữ liệu và nhãn bảo mật được gán trên cả các bản sao chép Tuy nhiên các chính sách trong DAC và MAC thì cố định và không hỗ trợ điều khiển truy cập linh hoạt Cũng tương tự như hai mô hình trên, mô hình điều khiển truy xuất theo vai trò (RBAC) nảy sinh nhiều vấn đề hạn chế Bùng nổ vai trò (role) là một trong những vấn đề lớn nhất của RBAC, bởi vì mỗi vai trò đòi hỏi những tập quyền khác nhau và một số lượng lớn vai trò phải được khai báo
Lu ậ n v ă n Th ạ c S ĩ 2 HV: Hà Xuân S ơ n – 1570226
Một trong những nghiên cứu đang nổi lên là mô hình điều khiển truy xuất dựa trên thuộc tính (ABAC) Ưu điểm của mô hình này là hỗ trợ các chính sách điều khiển linh động, cho phép hỗ trợ các chính sách mịn hơn dựa trên các thuộc tính của người dùng, dữ liệu, các thông tin liên quan đến ngữ cảnh Tuy nhiên, mô hình này mới được phát triển mạnh ở nền tảng lý thuyết Trong ABAC cũng còn rất nhiều vấn đề cần phải nghiên cứu và phát triển thêm Một trong các vấn đề đang được chú trọng nghiên cứu là làm thế nào để có thể đảm bảo được tính bảo mật trong điều kiện chính sách bảo mật bị thay đổi và làm thế nào để đảm bảo được tính bảo mật đối với yêu cầu không đủ quyền truy cập trên dữ liệu lớn [21]
Hay nói cách khác trong môi trường chính sách bảo mật động, chưa có một cơ chế hay nền tảng lý thuyết nào được nghiên cứu đúng mức Cho nên đề tài này, sẽ nghiên cứu mô hình điều khiển truy xuất cho dữ liệu NoSQL và thỏa mãn được các điều kiện ràng buộc về chính sách bảo mật động.
Mục tiêu của đề tài
Như đã đề cập ở trên, mặc dù dữ liệu không có cấu trúc đang có vai trò vô cùng quan trọng trong việc phát triển hệ thống lưu trữ và ngày càng thu hút được sự quan tâm của các nhà nghiên cứu Tuy nhiên, các mô hình điều khiển truy xuất cho dữ liệu này vẫn còn nhiều hạn chế, chưa đạt đến độ mịn và linh động, đặc biệt trong môi trường chính sách động nơi mà các chính sách bảo mật sẽ bị thay đổi theo thời gian nhằm đáp ứng các tính chất về đa dạng và độ lớn của dữ liệu lưu trữ Vì vậy mục tiêu của đề tài là nghiên cứu và đề xuất ra một mô hình điều khiển truy xuất cho dữ liệu NoSQL trong môi trường chính sách bảo mật động, xây dựng một cơ chế điều khiển truy xuất để đánh giá mô hình đã đề xuất.
Ý nghĩa đề tài
Về mặt khoa học, đề tài nghiên cứu và đề xuất một mô hình điều khiển truy xuất mới cho dữ liệu NoSQL Mô hình điều khiển truy xuất này còn có thể đáp ứng các yêu cầu bảo mật trong môi trường chính sách động
Về mặt thực tiễn, đề tài xây dựng một cơ chế điều khiển truy xuất động, dựa trên mô hình điều khiển và cơ chế điều khiển truy xuất này giúp nâng cao bảo mật trong việc quản lý dữ liệu NoSQL Đề tài cũng sử dụng tập mẫu được sử dụng ở ngoài đời thực để đo đạc và đánh giá tính khả dụng của mô hình.
Giới hạn của đề tài
Đề tài tập trung vào việc xây dựng một mô hình điều khiển truy xuất giải quyết vấn đề chính sách bảo mật động cho dữ liệu NoSQL Việc xây dựng một cơ chế điều khiển để đánh giá mô hình được xây dựng trên một mô hình XACML v3.0 là một hiện thực của mô
Lu ậ n v ă n Th ạ c S ĩ 3 HV: Hà Xuân S ơ n – 1570226 hình điều khiển truy xuất dựa theo thuộc tính ABAC Cụ thể là trong đề tài này sẽ sử dụng mô hình này áp dụng với lý thuyết SMT để làm tăng hiệu suất đánh giá câu truy vấn (tìm policy thích hợp cho câu truy vấn của người dùng) Để thỏa mãn đầu vào của một SMT Solver chúng tôi sẽ chuyển đổi định dạng ban đầu của chính sách bảo mật (XML format)
Về mô lưu trữ dữ liệu NoSQL, đề tài sẽ sử dụng mô hình Document Store, cụ thể ở trong tài liệu này là MongoDB.
Cấu trúc báo cáo
Bài báo cáo chia làm 8 chương:
Trình bày tổng quan về đề tài, mục tiêu của đề tài, ý nghĩa khoa học - thực tiễn, và giới hạn của đề tài.
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 (volume) dữ liệu khổng lồ, có tốc độ (velocity) được sinh ra lớn, và bao gồm nhiều kiểu (variety) dữ liệu khác nhau mà không thể được xử lý hiệu quả bởi các công cụ dữ liệu truyền thống Ngoài ra, độ tin cậy và tính xác thực (veracity) khi dữ liệu càng nhiều và bị nhiễu, sự không thống nhất, nhu cầu quản lý và xác thực dữ liệu càng tăng theo Do đó, tính chất này là một điều kiện cần thiết để tạo ra chất lượng dữ liệu làm tăng độ chính xác cho các ứng dụng, đặc biệt các ứng dụng phân tích và ra quyết định dựa trên dữ liệu lớn Phần tiếp theo sẽ trình bày tóm tắt các mô hình dữ liệu NoSQL cùng với các hệ thống quản lý dữ liệu lớn đang có trong thực tế.
Các mô hình dữ liệu NoSQL
Cấu trúc lưu trữ của mô hình Key-Value (khoá-giá trị) là sự ánh xạ một giá trị nội dung thuộc kiểu bất kì (có thể có cấu trúc, bán cấu trúc hay không có cấu trúc) vào một khoá
Khoá này có thể thuộc một kiểu bất kì (có/bán hoặc không có cấu trúc) Vì vậy, giá trị của khoá và nội dung lưu trữ có thể rất đa dạng, từ các kiểu cơ bản như byte, integer, float, double,… đến các kiểu phức tạp như XML, JSON,… hay file hình ảnh, âm thanh, video
Mô hình Key-Value rất thích hợp để lưu trữ dữ liệu lớn vì tính đa dạng (từ có/bán đến không cấu trúc), dễ dàng mở rộng dung lượng lưu trữ khi cần thiết (như trong hệ thống Hadoop [9] ta chỉ cần thêm vào một máy tính nào đó), và khả năng lưu trữ dữ liệu với tốc độ cao (vì cơ chế lưu trữ rất đơn giản và trực tiếp, thêm vào nhanh)
Mô hình Key-Value rất phổ biến trong công nghệ NoSQL đang được ứng dụng nhiều trong các hệ thống dữ liệu lớn [1] Tuy nhiên, các cơ chế bảo mật cho mô hình dữ liệu Key-Value hiện tại vẫn còn rất thô sơ và đơn giản Bảo mật trong mô hình này chủ yếu dựa trên 3 yếu tố chính sau đây:
• Xác thực: Các kỹ thuật xác thực người dùng, chủ thể sử dụng dữ liệu đang có
Lu ậ n v ă n Th ạ c S ĩ 6 HV: Hà Xuân S ơ n – 1570226
• Mã hoá dữ liệu: Các dữ liệu mang tính nhạy cảm, cần bảo mật sẽ được mã hoá trước khi lưu trữ xuống Tuy nhiên quá trình mã hoá này phải nhanh, không ảnh hưởng nhiều đến tốc độ và hiệu suất của hệ thống
• Tận dụng cơ chế bảo mật của hệ thống file sẵn có: Do thông thường các bộ Key-
Value sẽ được lưu trữ thành file, do đó hệ thống lưu trữ sẽ phân quyền cho các file này ngay tại thời điểm ghi xuống
Sau đây ta xem xét hai ví dụ về công nghệ điển hình cho mô hình lưu trữ Key-Value là Hadoop [9] và Redis [10]
Hadoop : Cơ chế bảo mật của Hadoop về cơ bản dựa trên 3 yếu tố chính sau đây
• Xác thực người dùng bằng công nghệ Kerberos
• Phân quyền file HDFS (Hadoop File System) Đây là một hệ thống file phân quyền theo chuẩn POSIX Khi ghi xuống hệ thống sẽ xác định owner (chủ sở hữu) và group (nhóm sở hữu) của file Một bộ quyền hạn trên file được xác lập bao gồm quyền đọc (read), ghi (write) và thực thi (execute) cho owner, group và tất cả còn lại
• Phân quyền mức dịch vụ (Service Level Authorization, SLA) Một hệ thống Hadoop bao gồm nhiều dịch vụ nhỏ, như Map, Reduce, Datanode,… SLA cho phép người quản trị phân quyền sử dụng các dịch vụ này cho từng người dùng (hiểu rộng ra là người dùng, tiến trình hoặc bất kì thành phần chủ động nào trong hệ thống) Sau đây là hai ví dụ minh hoạ cụ thể cho việc gán quyền SLA
Trong ví dụ như hình 2.1 về phân quyền, người dùng Alice, Bob và nhóm Mapreduce được phép thực thi các hàm map-reduce
Hình 2 1: Phân quyền mức dịch vụ SLA
Redis: Redis là hệ thống lưu trữ Key-Value trên bộ nhớ chính (in-memory keyvalue storage) Cơ chế bảo mật của Redis rất thô sơ, chỉ cho phép xác thực người dùng [10], và không có cơ chế điều khiển truy xuất mịn hơn (như SLA của Hadoop) Ngoài ra, Redis khuyến khích ta mã hoá các dữ liệu nhạy cảm trước khi lưu trữ để tăng cường tính bảo mật
Lu ậ n v ă n Th ạ c S ĩ 7 HV: Hà Xuân S ơ n – 1570226
Trong mô hình này, khái niệm document là để chỉ một nội dung có cấu trúc, bán cấu trúc hoặc không có cấu trúc Ví dụ của document có thể rất đa dạng, như JSON, BSON, XML, YAML hay phức tạp hơn là các file Word, Excel, PDF,… Ta có thể xem mô hình
Document Store là một bản cải tiến của mô hình Key-Value Khi các bộ Key-Value có thêm thuộc tính ngữ nghĩa hoặc siêu dữ liệu đến một mức độ nhất định, ta có thể gom nhóm các bộ key-value thành một document
Việc gom nhóm đó ta có thể thực hiện theo 4 phương thức chính sau đây
• Gom nhóm thành Collections , tức là ta gom nhóm một cách chủ động, người dùng hoặc chương trình trong quá trình chạy sẽ gom nhóm trực tiếp các dữ liệu liên quan
• Gom nhóm theo Tags , các nội dung sẽ được gán các tags, sau đó các dữ liệu sẽ gom nhóm thành document theo các tags
• Gom nhóm theo các siêu dữ liệu vô hình (Non-visible Metadata)
• Gom nhóm thành cấu trúc phân cấp (Directory Hierachies)
Mô hình Document Store thích hợp với các hệ thống lưu trữ Big Data phần nào coi trọng tính ngữ nghĩa của dữ liệu (khác với mô hình Key-Value, đơn thuần chỉ là lưu trữ dữ liệu)
Ví dụ, mô hình Key-Value lưu trữ các log file (web/game/application logs,…) còn mô hình
Document Store có thể ứng dụng trong lưu trữ các status của một mạng xã hội, tweet, comments,…
Do đặc tính có thêm ngữ nghĩa của document trong Document Store, cơ chế bảo mật của mô hình này được nâng cao hơn, uyển chuyển và mịn hơn so với mô hình Key-Value
Ngoài các cơ chế bảo mật cơ bản như xác thực người dùng, mã hoá dữ liệu, ta có thể áp dụng các cơ chế điều khiển truy xuất cơ bản cho mô hình Document Store (như RBAC), hoặc cung cấp cơ chế cho phép người lập trình thực hiện điều khiển truy xuất tuỳ chỉnh trên dữ liệu lưu trữ [3,4,13,14,15] Tuỳ theo công nghệ hiện thực mà mức độ nâng cao này cũng khác nhau Ta xem xét hai ví dụ về công nghệ sau đây để tham khảo rõ hơn về vấn đề này
MongoDB : MongoDB lưu trữ một collection dưới định dạng BSON, mỗi một collection được xem như một “database” và người lập trình/ quản trị viên có thể cài đặt điều khiển truy xuất ở mức độ database trong hệ thống Mô hình điều khiển truy xuất được áp dụng trong MongoDB là RBAC Mỗi người dùng (tiến trình, thành phần chủ động) sẽ được gán vào một role Trong MongoDB, có 3 nhóm role [11]: Read (chỉ đọc), ReadWrite (đọc và ghi) và Admin (quản trị) Mỗi role cung cấp cho người dùng một danh sách các quyền truy
ĐIỀU KHIỂN TRUY XUẤT
Bảo mật thông tin và tính riêng tư
Trước khi tìm hiểu sâu hơn về điều khiển truy xuất tổng quát nói chung và cho dữ liệu NoSQL nói riêng, ta cần có cái nhìn tổng quát về bảo mật thông tin và tính riêng tư, cũng như cách kết hợp hai khía cạnh này để bảo đảm tính an toàn cho thông tin
Bảo mật thông tin được xem là một cơ chế để bảo vệ dữ liệu Thông thường, bảo mật thông tin được hiểu là cách hiện thực công nghệ trong các hệ thống IT để bảo vệ dữ liệu được lưu Trên thực tế, bảo mật thông tin bao gồm việc bảo vệ dữ liệu dưới tất cả các hình thức (dữ liệu số, dữ liệu giấy hay các hình thức khác) [34] Bảo mật thông tin cũng bao gồm việc bảo vệ dữ liệu khỏi bất kỳ hình thức tấn công bên ngoài lẫn bên trong hệ thống Khi xét đến bảo mật thông tin, ta cần xét đến ba khía cạnh chính sau:
Hình 3 1: Ba khía cạnh chính của bảo mật thông tin
• Tính bảo mật (Confidentiality): có nghĩa là bảo vệ dữ liệu, trong tất cả các tình huống truy cập trái phép trong suốt toàn bộ vòng đời của một dữ liệu (từ lúc tạo dữ liệu đến hủy dữ liệu) Truy cập trái phép bao gồm truy cập bởi các cá nhân không liên kết với các tổ chức cơ bản lưu trữ dữ liệu (ví dụ, bọn tội phạm và tin tặc) Nó cũng bao gồm quyền truy cập của các cá nhân trong một tổ chức người cố tình vượt quá phạm vi của họ về quyền tiếp cận thông tin (ví dụ, cá nhân tìm kiếm các hồ sơ
Lu ậ n v ă n Th ạ c S ĩ 22 HV: Hà Xuân S ơ n – 1570226 của người nổi tiếng hay các cá nhân có mục tiêu khác khi họ có lý do chính đáng không chuyên nghiệp để làm như vậy)
• Tính toàn vẹn (Integrity): nghĩa là đảm bảo rằng dữ liệu trong hệ thống là chính xác Điều này có nghĩa là hệ thống khởi tạo và quản lý dữ liệu thực hiện các điều khiển trong hệ thống để đảm bảo rằng người dùng nhập và xử lý dữ liệu một cách chính xác; bên cạnh đó các mâu thuẫn trên dữ liệu được xác định và giải quyết
• Tính sẵn sàng (Availability): đảm bảo tính chất dữ liệu luôn sẵn có khi cần thiết
Khi người dùng đăng nhập thành công (Authentication) các yêu cầu truy vấn dữ liệu hoặc tương tác với Server phải được đáp ứng nếu đúng các chính sách của hệ thống
Các mối đe dọa phổ biến đến hệ thống thông tin bao gồm maleware, spyware, keystroke loggers, backdoor access, phishing và targeted scams; sử dụng sai mục đích của người truy cập hợp pháp và cách tấn công DoS Ngoài các mối đe dọa trên, người quản lý hệ thống thông tin và quản lý dữ liệu còn phải lưu tâm đến những việc không mong muốn có thể xảy ra như: thiên tai, mất điện, mất hoặc thất lạc nguồn tài nguyên thông tin Ngoài ra, người quản lý hệ thống còn phải bảo vệ dữ liệu trước những hành động vô tình của người dùng hợp pháp như xóa dữ liệu quan trọng, công khai các dữ liệu nhạy cảm hoặc gửi dữ liệu cho người không được phép truy cập
Bên cạnh đó, sự gia tăng về độ lớn của dữ liệu cũng như nhiều dạng dữ liệu mới được ra đời cùng đồng hành với các lo ngại về vấn đề bảo mật tính riêng tư của dữ liệu Việc bảo mật tính riêng tư của dữ liệu được nói rộng ra nghĩa là các dữ liệu sẽ được quản lý bởi chính người sở hữu (tạo ra) dữ liệu đó và người quản trị có thể không được truy cập nếu không có sự đồng ý của người chủ sở hữu Việc này hướng đến chỉ có một nhóm người cụ thể mới có khả năng truy cập vào nhóm các đối tượng này Tuy nhiên trong môi trường mà ngày càng có nhiều thông tin được chia sẻ thì việc đảm bảo quyền này là vô cùng khó khăn
Trong đề tài này, đề tài tập trung vào việc bảo mật dữ liệu bằng cách đánh giá các yêu cầu truy xuất đến dữ liệu trong hệ thống dựa trên một tập các chính sách đã được định nghĩa trước đó.
Nhu cầu điều khiển truy xuất cho dữ liệu NoSQL
Để hiểu về nhu cầu điều khiển truy xuất cho dữ liệu NoSQL, ta sẽ sơ lược những đánh giá và nhận định của các chuyên gia về vấn đề bảo mật và quyền riêng tư cho dữ liệu lớn nói chung, nhu cầu sử dụng dữ liệu lớn và mức độ khó khăn trong việc bảo mật trên loại dữ liệu này Đầu tiên tôi xin đưa ra con số cụ thể về độ lớn của dữ liệu và từ đó sẽ giải thích được vì sao dữ liệu lớn lại cần thiết đối với chúng ta hiện nay và những nguyên nhân gì mà phải lựa chọn cấu trúc dữ liệu NoSQL thay vì các cấu trúc truyền thống Định nghĩa về
“Big Data” (dữ liệu lớn) bao gồm một số lượng rất lớn các thông tin dữ liệu được lưu trữ trong các công ty về lĩnh vực CNTT bên cạnh đó là các vấn đề liên quan giữ chính phủ đối
Lu ậ n v ă n Th ạ c S ĩ 23 HV: Hà Xuân S ơ n – 1570226 với người dân và môi trường của họ Số lượng dữ liệu được tạo ra gấp đôi cứ sau mỗi năm cụ thể: từ 2500 exabyte vào năm 2012 đến 40.000 exabyte vào năm 2020 [35] (Hình 3.2) Điều này cũng tương đương với việc dữ liệu càng lớn thì thách thức về tính riêng tư và bảo mật càng cao Các ứng dụng trước đây sử dụng dữ liệu lớn thường được áp dụng cho các công ty và các tổ chức lớn, bởi vì để có thể tạo ra một cơ sở hạ tầng cho việc lưu trữ và xử lý dữ liệu là vô cùng tốn kém Tuy nhiên, đến thời điểm hiện tại việc ứng dụng Big Data vào các công ty nhỏ, vừa cũng như các tổ chức có quy mô nhỏ đã rất rộng rãi thông qua sự hỗ trợ của các cấu trúc nền tảng cho dữ liệu lớn như Cloud Computing, Hadoop, v.v… Tuy nhiên, khi ứng dụng các cấu trúc này thì mức độ bảo mật là điều phải xem xét do tính dùng chung và không có một chuẩn bảo mật nào giữa “khớp nối” từ dữ liệu nội bộ đối với môi trường bên ngoài Các chức năng bảo mật dạng truyền thống trước đây (firewalled, semi- isolated networks) cũng không đủ điều kiện để áp dụng Chính vì thế vấn đề bảo mật cho dữ liệu lớn được đặc biệt quan tâm
Hình 3 2: Lượng dữ liệu số ước tính được sinh ra từ năm 2010 đến năm 2020 [35]
Ngoài ra, chính vì sự khác biệt về cấu trúc và các đặc tính giữa dữ liệu truyền thống và dữ liệu lớn mà vấn bảo mật trên dữ liệu lớn cũng rất khác so với bảo mật trên dữ liệu truyền
Lu ậ n v ă n Th ạ c S ĩ 24 HV: Hà Xuân S ơ n – 1570226 thống và đang gặp phải rất nhiều khó khăn Trong bài nghiên cứu [36], nhóm tác giả đã đưa ra những nhận định của mình về 10 vấn đề quan trọng được xem là thử thách và ngày càng được tập trung giải quyết trong lĩnh vực “Privacy and Security” cho dữ liệu lớn
Dưới đây là 10 thách thức bảo mật trong Big Data:
1 Secure computations in distributed programming frameworks 2 Security best practices for non-relational data stores
3 Secure data storage and transactions logs 4 End-point input validation/filtering 5 Real-time security monitoring 6 Scalable and composable privacy-preserving data mining and analytics 7 Cryptographically enforced data centric security
8 Granular access control 9 Granular audits
Trong đó, làm sao có thể giám sát tình hình bảo mật trong thời gian thực (Real-time security monitoring) và điều khiển truy cập mịn “Granular access control” là hai trong các vấn đề quan trọng được đưa ra
Tính chất chủ yếu của điều khiển truy xuất đó chính là việc giữ tính bảo mật đối với các yêu cầu không đủ quyền truy cập Hay nói một cách khác, các dữ liệu không được phép truy cập từ một nhóm người dùng nào đó sẽ được bảo vệ và hạn chế truy cập (chỉ được truy cập khi có đủ quyền hạn) chức năng đó được gọi là “Bảo Mật” Điều khiển truy xuất mịn, khiến cho người quản trị quản lý dữ liệu tốt hơn khi chia sẻ, mà không ảnh hưởng đến tính bảo mật chung của dữ liệu (đối với đối tượng nào được phép xem dữ liệu đó thì vẫn được cấp quyền) Ngoài ra, trong tài liệu này, chúng tôi xin giới thiệu đến một hướng tiếp cận mới nhằm thỏa mãn tính bảo mật trong thời gian thực Cụ thể ở đây, chúng tôi sẽ đưa ra cách thức đảm điều khiển truy cập kể cả khi các chính sách thay đổi mà không làm ảnh hưởng đến hệ thống (dừng hệ thống hay cập nhật lại hệ thống).
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]
Lu ậ n v ă n Th ạ c S ĩ 25 HV: Hà Xuân S ơ n – 1570226
Các tác giả trong [2] định nghĩa một hệ thống điều khiển truy xuất (access control system) bao gồm: chính sách điều khiển truy xuất (access control policy), mô hình điều khiển truy xuất (access control model), và cơ chế điều khiển truy xuất (access control mechanism)
Trong đó, các chính sách định nghĩa các luật cho phép xác định một yêu cầu truy xuất là được phép hay không Các chính sách sau đó được cụ thể hóa (formalize) trong mô hình truy xuất và sau cùng được thực thi bởi cơ chế điều khiển truy xuất
Ngoài ra, một hệ thống điều khiển truy xuất phải thỏa mãn các tính chất quan trọng sau [2]:
• Simple (tính đơn giản): hệ thống phải hỗ trợ cho người quản lý dễ dàng trong việc tạo và chỉnh sửa các đặc tả kỹ thuật về yêu cầu bảo mật
• Expressive: hệ thống phải cung cấp khả năng mô tả các yêu cầu uyển chuyển, có khả năng áp dụng cho nhiều nguồn tài nguyên và loại dữ liệu khác nhau
• Policy combination: khi có nhiều quyết định nhận được cho một yêu cầu truy xuất, hệ thống phải hỗ trợ việc kết hợp các quyết định này thành một quyết định đơn duy nhất
• Anonymity: có rất nhiều dịch vụ không yêu cầu định danh thực sự của người dùng; do đó, hệ thống cũng cần hỗ trợ điều khiển truy xuất dựa trên đặc tính của người dùng (các định danh kỹ thuật số)
• Data outsourcing: xu hướng hiện nay của các doanh nghiệp và thuê nguồn tài nguyên từ bên ngoài; vì vậy, hệ thống được áp dụng phải đảm bảo điều khiển
Các mô hình điều khiển truy xuất hiện nay đều dựa trên ba mô hình kinh điển có thể được kể đến là: DAC, MAC và RBAC [3] Gần đây, mô hình ABAC, là một mô hình mới được giới thiệu, vừa bao gồm ưu điểm của các mô hình truyền thống, vừa rất linh động cho phép biểu diễn các chính sách phân quyền linh động, hiệu quả
Theo Sandhu R.S [4], một khung điều khiển truy xuất tổng quát bao gồm các thành phần như hình vẽ bên dưới:
Hình 3 3: Khung điều khiển truy xuất tổng quát
Lu ậ n v ă n Th ạ c S ĩ 26 HV: Hà Xuân S ơ n – 1570226
• Authentication: mô hình xác thực người dùng
• Authorization rules: tập các luật phân quyền được định nghĩa dựa theo mô hình
(hoặc ) Với S (Subject) là đại diện cho người dùng hoặc quá trình muốn truy xuất vào dữ liệu, O (Object) là đối tượng dữ liệu mà S muốn truy xuất, P (Privilege hay Permission) đại diện cho các tác vụ xác định mà S có thể thực hiện trên O, và C (Constraint) là những ràng buộc không gian có thể có
• Resources: là dữ liệu đích mà người dùng dự định truy xuất vào
• PIP: Policy Information Point, có nhiệm vụ tạo mới và chỉnh sửa các luật phân quyền nằm trong Authorization rules để phù hợp với nhu cầu nghiệp vụ
• PEP: Policy Enforcement Point, chuyển đổi các yêu cầu nhận được từ phía người dùng sang dạng tương thích với các luật phân quyền được chứa trong Authorization rules, hoặc chuyển đổi các quyết định từ PDP sang dạng người dùng có thể hiểu được
• PDP: Policy Decision Point, tìm các luật phân quyền có liên quan, so sánh với yêu cầu của người dùng (được chuyển từ PEP) và đưa ra quyết định, chuyển quyết định này cho PEP
Cơ chế hoạt động của khung điều khiển có thể tóm lược như sau: trước hết, người dùng phải là người dùng hợp lệ của hệ thống, PEP nhận yêu cầu từ phía người dùng và chuyển sang dạng tương thích với các luật phân quyền được đã được định nghĩa từ PIP; sau đó, PEP sẽ chuyển các yêu cầu này cho PDP Nhiệm vụ của PDP là tìm các luật phân quyền có liên quan, so sánh với các yêu cầu của người dùng, từ đó đưa ra quyết định (cho phép hoặc từ chối), đồng thời, PDP cũng chuyển quyết định ngược lại cho PEP Để kết thúc quá trình, PEP tiếp tục chuyển các quyết định sang định dạng mà người dùng có thể hiểu được và trả kết quả về cho người dùng.
Các mô hình truyền thống
Mô hình bảo mật tùy quyền, hoặc mô hình điều khiển truy cập tùy quyền (DAC model), quản lý và điều khiển các truy cập của người dùng đến các thông tin dựa vào định danh của người dùng và tập các luật điều khiển truy cập Luật điều khiển truy cập định nghĩa với mỗi người dùng và đối tượng (object), sẽ có quy định các loại truy cập mà người dùng được phép làm trên đối tượng đó
Khi người dùng yêu cầu truy cập đến một đối tượng, một bộ phận định quyền (authorization module) sẽ kiểm tra xem người dùng đó có được phép truy cập không Nếu có thì cho phép, còn không thì từ chối Trong mô hình điều khiển truy cập tùy quyền thì :
• Người dùng có thể bảo vệ những gì thuộc về mình
• Chủ của dữ liệu sẽ có toàn quyền trên dữ liệu đó
Lu ậ n v ă n Th ạ c S ĩ 27 HV: Hà Xuân S ơ n – 1570226
• Chủ của dữ liệu có quyền định nghĩa các loại truy cập đọc/ghi/thực thi (read/write/execute/…) và gán những quyền đó cho những người dùng khác
Mô hình điều khiển truy cập tùy quyền có thể được thực hiện với nhiều cơ chế khác nhau :
• Bảng phân quyền : mỗi phần tử được lưu trong bảng sẽ gồm có 3 thành phần : người dùng (user), hành động (action), thực thể (object) với ý nghĩa là người dùng
U có quyền A trên thực thể O Hình 3.1.a là một ví dụ về bảng phân quyền, trong đó người dùng Ann có quyền read trên Document1
• Danh sách điều khiển (Access control list ACL) : trong cách thực hiện này : mỗi thực thể sẽ được gắn với một danh các người dùng cùng với quyền mà người đó được phép thực hiện Hình 3.1.b là một ví dụ về danh sách điều khiển, trong ví dụ này : trên tài liệu Document1 thì Ann có quyền Read,Write và Bob có quyền Read
• Danh sách quyền (Capability) : trong danh sách này, mỗi một người dùng được gắn với một danh sách các thực thể cùng với các hành động được phép thực thi trên thực thể đó Hình 3.1.b là một ví dụ về danh sách quyền, trong đó Ann được quyền
Read/Write trên Document1 , quyền Read trên Document2, quyền execute trên
Hình 3 4: Mô hình điều khiển truy cập tùy quyền
Mô hình này đơn giản nhưng rất hiệu quả và linh động trong việc thể hiện các chính sách điều khiển truy xuất Tuy nhiên, mô hình này lại vướng phải nhược điểm, nó không thể điều khiển thông tin được truyền và sử dụng như thế nào khi nó được một chủ thể đã được gán quyền truy cập vào Chính vì thế mà mô hình này có thể bị tấn công bởi Trojan Hourse
Lu ậ n v ă n Th ạ c S ĩ 28 HV: Hà Xuân S ơ n – 1570226
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 Điểm yếu này của mô hình DAC được mô tả trong hình 3.5
Hình 3 5: Ví dụ về trojan horse trên DAC
3.4.2 Mô hình điều khiển truy cập bắt buộc
Mô hình chỉ cung cấp cho các chủ sở hữu giám sát quản lý điều khiển truy xuất trên những chủ thể và dữ liệu đã được phân loại cơ bản trước, những dữ liệu được đóng nhãn bảo mật
Người tạo ra dữ liệu không có khả năng gán quyền tự do cho bất kì chủ thể nào.Mô hình này chủ yếu phát triển cho các ứng dụng quân sự, cần vững chắc, phù hợp và để đảm bảo dễ dàng điều khiển nhiều hơn
Trong mô hình này, người dùng và dữ liệu được phân loại dựa theo các lớp bảo mật (security classes)
• Phân loại người dùng dựa theo mức độ tin cậy và lĩnh vực hoạt động của người dùng
• Phân loại dữ liệu dựa theo mức độ nhạy cảm và lĩnh vực của dữ liệu
Mô hình này được phát triển là do nhu cầu cần có một cơ chế bảo vệ mạnh mẽ, ngăn cản việc truy cập không được phân quyền để bảo vệ tài nguyên, cụ thể là tấn công của Trojan Hourse
Lu ậ n v ă n Th ạ c S ĩ 29 HV: Hà Xuân S ơ n – 1570226
3.4.3 Mô hình điều khiển truy cập theo vai trò
Trong mô hình này, vai trò được định nghĩa như một tập hợp các quyền mà người dùng được phép làm khi sở hữu vai trò đó Khi truy cập vào hệ thống, mỗi người dùng phải xác định vai trò của mình và từ đó có quyền trên hệ thống thông qua các vai trò mà họ được gán Một chính sách điều khiển truy cập sẽ gồm 2 giai đoạn : đầu tiên, nhà quản trị sẽ định nghĩa ra các vai trò và các quyền gắn với các vai trò đó, sau đó người dùng sẽ được gán với các vai trò phù hợp
Hình 3 6: Mô hình điều khiển truy cập dựa trên vai trò
Với điều khiển truy cập dựa vai trò, các quyết định truy cập dựa trên vai trò (role) mà người dùng thuộc về Ví dụ, một kế toán trong một công ty sẽ được giao cho vai trò kế toán, được phép thực hiện các công việc liên quan đến kế toán.Tương tự như vậy, một kỹ sư phần mềm có thể được giao cho các vai trò nhà phát triển (developer role)
Trong điều khiển truy cập dựa vai trò, mỗi người dùng (user) được gắp với các vai trò (role), các vai trò được gán một tập quyền (permission).Vì người dùng không được cấp phép một cách trực tiếp, chỉ nhận được những quyền hạn thông qua vai trò (hoặc các vai trò) của họ, việc quản lý quyền hạn của người dùng trở thành một việc đơn giản, và người ta chỉ cần chỉ định những vai trò thích hợp cho người dùng
Lu ậ n v ă n Th ạ c S ĩ 30 HV: Hà Xuân S ơ n – 1570226
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.4, 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
Hình 3 7: Đặc điểm các mô hình điều khiển truy xuất
Lu ậ n v ă n Th ạ c S ĩ 31 HV: Hà Xuân S ơ n – 1570226
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 triển khai hệ thống
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
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 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 vai 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 Hình 3.4 mô tả đặc điểm các mô hình điều khiển từ DAC, MAC, RBAC đến ABAC, độ linh động của các chính sách tăng dần, mức độ tự động, khả năng thích ứng cũng tăng dầ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 đó
Lu ậ n v ă n Th ạ c S ĩ 32 HV: Hà Xuân S ơ n – 1570226
Hình 3.8 dưới đây mô tả chuẩn NIST của ABAC, thể hiện các thành phần cơ bản của mô hình, cũng như kịch bản hoạt động của mô hình
Hình 3 8: Kịch bản của mô hình ABAC cơ bản
Các thành phần cơ bản: Mô hình ABAC chứa các thành phần cơ bản bao gồm: Chủ Thể
(Subject), Thuộc Tính Chủ Thể (Subject Attribute), Đối Tượng (Object), Thuộc Tính Đối
Tượng (Object Attribute), Các điều kiện môi trường (Environment conditions), Chính sách Phân Quyền (Access control policy) o Một Thu ộ c Tính là một hàm trả về giá trị cụ thể cho một thực thể: Ch ủ Th ể , Đố i T ượ ng, Môi tr ườ ng 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
Lu ậ n v ă n Th ạ c S ĩ 33 HV: Hà Xuân S ơ n – 1570226 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 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ó 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 chủ thể, chẳng hạn như tên, tuổi, vai trò và giới tính, độ tin cậy, o Đố i t ượ ng là những tài nguyên cần được bảo vệ Các Đố i t ượ ng có thể là: thiết bị, file, các chương trình, các dịch vụ, dữ liệu, … Đố 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 thể hiện đặc tính của đối tượng như: ngày tạo ra, chủ sở hữu, … o Chính sách phân quy ề n bao gồm các luật 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 dựa vào thuộc tính của Ch ủ th ể , Đố i t ượ ng, và Đ i ề u ki ệ n môi tr ườ ng o Đ i ề u ki ệ n môi tr ườ ng thể hiện ngữ cảnh khi yêu cầu truy xuất xảy ra Điều kiện môi trường độc lập với Ch ủ th ể , Đố i t ượ ng; có thể bao gồm thời gian hiện tại, ngày trong tuần, vị trí của người dùng, …
Kịch bản điều khiển truy xuất: như hình 3.5 mô tả, quá trình điều khiển truy xuất gồm 3 bước cơ bản:
1 Ch ủ th ể (Subject) đưa ra các yêu cầu truy xuất trên các Đố i t ượ ng (Object)
2 C ơ ch ế đ i ề u khi ể n truy xu ấ t (Access control mechanism) đánh giá yêu cầu dựa vào a) luật, b) thuộc tính chủ thể, c) thuộc tính đối tượng, d) thuộc tính hành động và điều kiện môi trường
3 Tùy theo kết quả đánh giá mà yêu cầu truy xuất được cho phép hoặc bị cấm.
Mô hình điều khiển truy xuất XACML
XACML (eXtensible Access Control Markup Language), là một ví dụ của mô hình điều khiển truy xuất dựa theo thuộc tính được OASIS (Organization for the Advancement of Structured Information Standards) Phiên bản mới nhất hiện nay là bản 3.0 [19] Trong mô hình XACML 3.0 các khối chủ yếu PEP, PAP, PDP, PIP có chức năng tương tự như trong mô hình ABAC 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 đó
Lu ậ n v ă n Th ạ c S ĩ 34 HV: Hà Xuân S ơ n – 1570226 access requester PEP
PAP subject environment obligation service
4 request notification 5 attribute queries 6 attributes query 7a subject attributes 7b resource attributes 7c environment attributes 8 attribute
Hình 3 9: Thành phần và luồng xử lý XACML [19]
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 3.7 Đầu tiên người quản trị hệ thống sẽ đặc tả các Policy trong PAP dưới định dạng XML để 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 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 (hoặc XML) bao gồm 4 trường cơ bản là:
Subject đối tượng gửi yêu cầu (các nhóm đố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ể) Các yêu cầu này sẽ được gửi xuống context handler ở đâ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à dữ liệu sau đó sẽ gửi lại cho context handler, 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 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 Sau khi các quá trình tính toán và xử lý được hoàn tất thì sẽ gửi về cho context handler tổng hợp và gửi lại PEP dưới form XML
Sau đó PEP sẽ gửi về cho obligation service
Lu ậ n v ă n Th ạ c S ĩ 35 HV: Hà Xuân S ơ n – 1570226
3.6.2 Chính sách và luật trong XACML
Cấu trúc của một policy được mô tả cụ thể trong hình sau:
Hình 3 10: Cấu trúc chính sách trong XACML [19]
Một thẻ Target sẽ có một hoặc nhiều thẻ AnyOf Các thẻ AnyOf tượng trưng cho mối liên hệ hoặc nghĩa là để thỏa mãn các yêu cầu trong tập các AnyOf chỉ cần một trường hợp đúng Bên trong từng cặp thẻ AnyOf là AllOf nghĩa là tất cả các thuộc tính có chứa bên trong của AllOf phải được thỏa mãn nếu không sẽ trả về trường hợp là “false”
Một policy set có thể bao gồm nhiều policy hoặc nhiều rule với nhau theo giải thuật kết nối Trong các Rule luôn gắn một giá trị Effect có giá trị là “Permit” hoặc “Deny” nhằm xác định giá trị của policy đó là cho phép hoặc không cho phép một thao tác được gửi từ phía người dùng, bên cạnh đó còn có tập các điều kiện “condition” ràng buộc phải thỏa mãn tất cả các điều kiện trong tập condition này thì giá trị trong Effect mới được thỏa mãn
Hình 3.8 mô tả một policy mẫu theo các chuẩn đã được nêu ra ở trên
Lu ậ n v ă n Th ạ c S ĩ 36 HV: Hà Xuân S ơ n – 1570226
Hình 3 11: Ví dụ về chính sách trong XACML [19]
3.6.3 Đầu vào và đầu ra trong XACML
Các định dạng yêu cầu trong XACML 3.0 có thể định dạng theo kiểu XML hoặc JSON theo một vài Tool hỗ trợ XACML 3.0 phát triển Ở trong tài liệu này xin giới thiệu dạng yêu cầu dưới dạng định dạng XML Ở mỗi kiểu định dạng cũng đều phân ra làm 4 phần như đã nói ở phần XACML Model Lấy ví dụ một dạng yêu cầu như sau:
“Bart Simpson, với địa chỉ email là "bs@simpsons.com" muốn đọc các thông tin về thuốc của anh ấy tại Medi Corp” Yêu cầu trên có thể được biểu diễn dưới dạng XML như hình 3.10: thứ tự các Attribute nằm trong cặp thẻ chứa các thông tin liên quan đến Subject, Resrouce và Action
Lu ậ n v ă n Th ạ c S ĩ 37 HV: Hà Xuân S ơ n – 1570226
Hình 3 12: Ví dụ về đầu vào trong XACML [19]
Kết quả trả về được định dạng dưới form XML như hình 3.11
Vì không tìm được các Policy tương ứng để đưa ra câu trả lời là Permit hoặc Deny nên kết quả đưa ra là không tìm thấy Not Applicable
Hình 3 13: Ví dụ về đầu ra trong XACML [19]
3.6.4 Giải thuật kết hợp trong XACML
Có ba loại kết hợp trong XACML 3.0
• Các Condition tạo ra Rule
• Các Rule tạo ra Policy
Lu ậ n v ă n Th ạ c S ĩ 38 HV: Hà Xuân S ơ n – 1570226
• Các Policy tạo ra PolicySet Đối với từng loại kết hợp thì việc so khớp ban đầu trước khi gọi giải thuật kết nối là rất cần thiết Mục đích chính của việc “Match” các điều kiện tại từng trường hợp khác nhau sẽ giảm đáng kể thời gian chạy các giải thuật kết nối đối với các policy không có quan hệ với nhau Việc kết hợp các Policy lại với nhau thường theo một giải thuật định, có nhiều giải thuật có thể được ứng dụng trong việc kết hợp giữa các condition, rule và policy Các bảng dưới đây đánh giá kết quả như sau:
Match True Phụ thuộc giá trị Effect là Permit hay Deny
None Match Không quan tâm Not Applicable
Indeterminate Không quan tâm Indeterminate
Bảng 3 1: Kết quả khi kết hợp các Condition trong một Rule [19]
Match Có ít nhất một Rule giá trị là Effect Xác định bởi giải thuật kết hợp rule Match Tất cả các Rule là “Not Applicable” Not Applicable Match Có ít nhất một Rule giá trị là Indeterminate Xác định bởi giải thuật kết hợp rule
None Match Không quan tâm Not Applicable
Indeterminate Không quan tâm Indeterminate
Bảng 3 2: Kết quả khi kết hợp các Rule trong một Policy [19]
Match Có ít nhất một policy giá trị là Decision Xác định bởi giải thuật kết hợp policy Match Tất cả các policy là “Not Applicable” Not Applicable Match Có ít nhất một policy giá trị là
Indeterminate Xác định bởi giải thuật kết hợp policy
None Match Không quan tâm Not Applicable
Indeterminate Không quan tâm Indeterminate
Bảng 3 3: Kết quả khi kết hợp các Policy trong một PolicySet [19]
Một vài giải thuật được sử dụng trong việc kết nối là: deny-overrides, permit-overrides, first-applicable, orderred-deny-overrides, orderred-permit-overrides, only-one-applicable
Lu ậ n v ă n Th ạ c S ĩ 39 HV: Hà Xuân S ơ n – 1570226
CƠ SỞ LÝ THUYẾT VÀ CÁC CÔNG TRÌNH NGHIÊN CỨU LIÊN
Trình bày khái niệm về lý thuyết SMT, chính sách bảo mật động (dynamic policy) Định nghĩa như thế nào là một hệ thống có hỗ trợ chính sách bảo mật động, các tiêu chí đánh giá Tóm tắt các nghiên cứu trước đây về đánh giá chính sách và đưa ra giải pháp cho chính sách bảo mật động
Chương 5 KIẾN TRÚC HỆ THỐNG
Trình bày các hướng tiếp cận của phương pháp đánh giá chính sách, cấu trúc của một chính sách bảo mật, cách chuyển đổi định dạng chính sách từ XML (XACML v3.0)
Lu ậ n v ă n Th ạ c S ĩ 4 HV: Hà Xuân S ơ n – 1570226 sang dạng input của SMT Solver Trình bày về mô hình và kiến trúc tổng quan của hệ thống
Chương 6 HIỆN THỰC HỆ THỐNG
Trình bày các giải thuật chính và kiến trúc hiện thực của hệ thống
Chương 7 ĐÁNH GIÁ HỆ THỐNG
Trình bày môi trường đánh giá, thông tin về tập mẫu sử dụng và đưa ra kết quả đánh giá hệ thống So sánh với giải thuật đã đề xuất với hướng tiếp cận hiện tại Phân tích và giải thích lý do sự khác biệt giữa hai hệ thống
Trình bày tổng kết báo cáo, các giới hạn và hướng phát triển của đề tài
Lu ậ n v ă n Th ạ c S ĩ 5 HV: Hà Xuân S ơ n – 1570226
Chương 2 CƠ SỞ DỮ LIỆU NOSQL
Trong phần này tài liệu sẽ trình bày cơ sở lý thuyết, các mô hình cơ sở dữ liệu NoSQL và lý do áp dụng mô hình Document Store cho đề tài luận văn Từ đó đưa ra lựa chọn MongoDB sẽ là cơ sở dữ liệu được áp dụng trong đề tài này
2.1 Khái niệm cơ bản về dữ liệu lớn
Dữ liệu lớn là dữ liệu có dung lượng (volume) dữ liệu khổng lồ, có tốc độ (velocity) được sinh ra lớn, và bao gồm nhiều kiểu (variety) dữ liệu khác nhau mà không thể được xử lý hiệu quả bởi các công cụ dữ liệu truyền thống Ngoài ra, độ tin cậy và tính xác thực (veracity) khi dữ liệu càng nhiều và bị nhiễu, sự không thống nhất, nhu cầu quản lý và xác thực dữ liệu càng tăng theo Do đó, tính chất này là một điều kiện cần thiết để tạo ra chất lượng dữ liệu làm tăng độ chính xác cho các ứng dụng, đặc biệt các ứng dụng phân tích và ra quyết định dựa trên dữ liệu lớn Phần tiếp theo sẽ trình bày tóm tắt các mô hình dữ liệu NoSQL cùng với các hệ thống quản lý dữ liệu lớn đang có trong thực tế
2.2 Các mô hình dữ liệu NoSQL 2.2.1 Mô hình Key-Value
Cấu trúc lưu trữ của mô hình Key-Value (khoá-giá trị) là sự ánh xạ một giá trị nội dung thuộc kiểu bất kì (có thể có cấu trúc, bán cấu trúc hay không có cấu trúc) vào một khoá
Khoá này có thể thuộc một kiểu bất kì (có/bán hoặc không có cấu trúc) Vì vậy, giá trị của khoá và nội dung lưu trữ có thể rất đa dạng, từ các kiểu cơ bản như byte, integer, float, double,… đến các kiểu phức tạp như XML, JSON,… hay file hình ảnh, âm thanh, video
Mô hình Key-Value rất thích hợp để lưu trữ dữ liệu lớn vì tính đa dạng (từ có/bán đến không cấu trúc), dễ dàng mở rộng dung lượng lưu trữ khi cần thiết (như trong hệ thống Hadoop [9] ta chỉ cần thêm vào một máy tính nào đó), và khả năng lưu trữ dữ liệu với tốc độ cao (vì cơ chế lưu trữ rất đơn giản và trực tiếp, thêm vào nhanh)
Mô hình Key-Value rất phổ biến trong công nghệ NoSQL đang được ứng dụng nhiều trong các hệ thống dữ liệu lớn [1] Tuy nhiên, các cơ chế bảo mật cho mô hình dữ liệu Key-Value hiện tại vẫn còn rất thô sơ và đơn giản Bảo mật trong mô hình này chủ yếu dựa trên 3 yếu tố chính sau đây:
• Xác thực: Các kỹ thuật xác thực người dùng, chủ thể sử dụng dữ liệu đang có
Lu ậ n v ă n Th ạ c S ĩ 6 HV: Hà Xuân S ơ n – 1570226
• Mã hoá dữ liệu: Các dữ liệu mang tính nhạy cảm, cần bảo mật sẽ được mã hoá trước khi lưu trữ xuống Tuy nhiên quá trình mã hoá này phải nhanh, không ảnh hưởng nhiều đến tốc độ và hiệu suất của hệ thống
• Tận dụng cơ chế bảo mật của hệ thống file sẵn có: Do thông thường các bộ Key-
Value sẽ được lưu trữ thành file, do đó hệ thống lưu trữ sẽ phân quyền cho các file này ngay tại thời điểm ghi xuống
Sau đây ta xem xét hai ví dụ về công nghệ điển hình cho mô hình lưu trữ Key-Value là Hadoop [9] và Redis [10]
Hadoop : Cơ chế bảo mật của Hadoop về cơ bản dựa trên 3 yếu tố chính sau đây
• Xác thực người dùng bằng công nghệ Kerberos
• Phân quyền file HDFS (Hadoop File System) Đây là một hệ thống file phân quyền theo chuẩn POSIX Khi ghi xuống hệ thống sẽ xác định owner (chủ sở hữu) và group (nhóm sở hữu) của file Một bộ quyền hạn trên file được xác lập bao gồm quyền đọc (read), ghi (write) và thực thi (execute) cho owner, group và tất cả còn lại
• Phân quyền mức dịch vụ (Service Level Authorization, SLA) Một hệ thống Hadoop bao gồm nhiều dịch vụ nhỏ, như Map, Reduce, Datanode,… SLA cho phép người quản trị phân quyền sử dụng các dịch vụ này cho từng người dùng (hiểu rộng ra là người dùng, tiến trình hoặc bất kì thành phần chủ động nào trong hệ thống) Sau đây là hai ví dụ minh hoạ cụ thể cho việc gán quyền SLA
Trong ví dụ như hình 2.1 về phân quyền, người dùng Alice, Bob và nhóm Mapreduce được phép thực thi các hàm map-reduce
Hình 2 1: Phân quyền mức dịch vụ SLA
Redis: Redis là hệ thống lưu trữ Key-Value trên bộ nhớ chính (in-memory keyvalue storage) Cơ chế bảo mật của Redis rất thô sơ, chỉ cho phép xác thực người dùng [10], và không có cơ chế điều khiển truy xuất mịn hơn (như SLA của Hadoop) Ngoài ra, Redis khuyến khích ta mã hoá các dữ liệu nhạy cảm trước khi lưu trữ để tăng cường tính bảo mật
Lu ậ n v ă n Th ạ c S ĩ 7 HV: Hà Xuân S ơ n – 1570226
Trong mô hình này, khái niệm document là để chỉ một nội dung có cấu trúc, bán cấu trúc hoặc không có cấu trúc Ví dụ của document có thể rất đa dạng, như JSON, BSON, XML, YAML hay phức tạp hơn là các file Word, Excel, PDF,… Ta có thể xem mô hình
Document Store là một bản cải tiến của mô hình Key-Value Khi các bộ Key-Value có thêm thuộc tính ngữ nghĩa hoặc siêu dữ liệu đến một mức độ nhất định, ta có thể gom nhóm các bộ key-value thành một document
Việc gom nhóm đó ta có thể thực hiện theo 4 phương thức chính sau đây
Đánh giá chính sách
XACML đang ngày càng chứng tỏ là một trong những chuẩn công nghiệp được ưa chuộng nhất hiện nay trong vấn đề điều khiển truy xuất Rất nhiều nghiên cứu trước đây đã nâng cấp XACML từ mô hình lý thuyết đến các hệ thống ứng dụng thực tế đã làm cho XACML ngày càng được phổ biến rỗng rãi hơn Tuy nhiên, nó vẫn còn nhiều vấn đề bị giới hạn và cần phải có nhiều nghiên cứu chuyên sâu Các giới hạn của XACML có thể kể đến như: nó không những không hỗ trợ việc xác thực tin cậy mà còn không cho phép gửi các yêu cầu ẩn danh Điều này rất nguy hiểm đối với người dùng có thông tin nhạy cảm cũng phải cung cấp toàn bộ thông tin cá nhân (kể cả thông tin nhạy cảm) để có thể xác thực thành công
Bên cạnh đó cơ chế lưu trữ xác thực tin cậy của XACML chưa được nghiên cứu một cách triệt để cũng đã làm ảnh hưởng không nhỏ đến vấn đề bảo mật hệ thống Ngoài ra Turkmen và Crispo [54] cũng đã chứng minh được rằng đánh giá chính sách trong XACML sẽ phải đối mặt với vấn đề mở rộng (scalability problem) trong trường hợp chính sách bảo mật ngày càng lớn và phức tạp Chính vì các lý do trên mà bài toán đánh giá chính sách đang ngày càng được chú trọng và giải quyết ngày một tối ưu hơn
Các nghiên cứu trước đây giải quyến bài toán đánh giá chính sách theo nhiều hướng tiếp cận khác nhau Phương pháp tiếp cận bằng phương thức thống kê (statistic method) [55], Decision Diagrams (DDs) [56], Binary Decision Diagrams (BDDs) [57], Multi-data-types Interval Decision Diagrams (MIDD) [58], Answer Set Programming (ASP) [59] Marouf và cộng sự [55] thống kê số lượng yêu cầu từ phía người dùng trong các lần truy cập quá khứ và tìm các luật và chính sách thích hợp Ở phương pháp này cố gắng tìm kiếm luật và chính sách thích hợp với yêu cầu người dùng phụ thuộc vào kết quả của việc thống kê Giới hạn chính đối với phương pháp này đến từ phương thức thống kê không thể cải thiệt thời gian tính toán khi các yêu cầu của người dùng không đúng định dạng và các luật/chính sách động Liu và cộng sự [56] đã giới thiệu một phương pháp khác để đánh giá chính sách là XEngine, với nhiệm vụ chính là đánh giá chính sách cho XACML Hướng tiếp cận chính của phương pháp này là dùng lý thuyết của Decision Diagram để cải thiện thời gian xử lý trong quá trình đánh giá chính sách của XACML Giới hạn chính của XEngine đó là chỉ hỗ trợ được một phần chính sách XACML và phương thức numericalization không hỗ trợ
Lu ậ n v ă n Th ạ c S ĩ 41 HV: Hà Xuân S ơ n – 1570226 các phương thức so sánh Ngoài ra hướng tiếp cận này cũng loại bỏ chức năng hỗ trợ nghĩa vụ người dùng (obligation) do hướng tiếp cận chỉ hỗ trợ duy nhất mỗi giải thuật kết nối (First Applicable)
Pina và cộng sự [57] giải quyết vấn đề đánh giá chính sách dựa trên nền tảng lý thuyết của BDDs Trong phương pháp tiếp cận của họ sẽ xây dựng nên hai cây bao gồm: Matching
Tree dựa trên giải thuật tìm kiếm nhị phân với mục tiêu là tăng nhanh thời gian tìm kiếm luật thích hợp và Combining Tree hỗ trợ việc đánh giá các tập luật kết hợp Ngo Canh và cộng sự cũng có hướng giải quyết tương tự như hướng tiếp cận của Pina nhưng họ có hỗ trợ nhiều nhóm dữ liệu hơn (Multi-data-types) Tuy nhiên, các hướng tiếp cận ứng dụng lý thuyết của Decision Diagram nhìn chung sẽ có vài hạn chế về thiết kế phương thức so sánh
Nó chỉ hỗ trợ một vài phương thức so sánh căn bản như: lớn hơn, nhỏ hơn và so sánh bằng
Bên cạnh đó, Turkmen [60] đã đưa ra nhận định rằng “thật khó khăn khi chuyển đổi một – một từ các phương thức so sánh trong XACML sang các phương thức so sánh của Decision Diagram Chính vì lý do trên mà nhóm tác giả này đã đề xuất một phương thức mới cho việc chuyển đổi các phép toán so sánh trong XACML thành đầu vào của SMT Phần sau sẽ định nghĩa SMT là gì và cách thức có thể chuyển đổi từ một điều kiện ràng buộc trong policy thành một phép toán logic và dễ dàng thể hiện thành đầu vào của SMT Solver.
Satisfiability Modulo Theories (SMT)
SMT là một mở rộng của lý thuyết SAT (Satisfiability) với mục tiêu là trả về giá trị thuộc kiểu Boolean khi nhận vào một hàm (hàm logic, tập luật suy diễn, …) và một giá trị mục tiêu (trạng thái, giá trị cụ thể, …) Nếu như giá trị trả về khới với giá trị mục tiêu trong quá trình suy diễn thì kết quả sẽ trả về là True (tức là có tồn tại trạng thái hay giá trị mục tiêu) và trả về False cho trường hợp còn lại SMT sử dụng các lý thuyết tính toán trên nhiều nhóm dữ liệu khác nhau có thể kể đến bao gồm: lý thuyết số, bit – vector, mảng, chuỗi, lượng từ và các lý thuyết first – order logic khác SMT Solver là một nơi giải quyết bài toán, nó thiết lập các giá trị thỏa mãn của một công thức toán học không chỉ có chia nhỏ việc tính toán theo lý thuyết first – order logic (ví dụ BSR fragment) mà còn tính toán dựa trên lý thuyết (ví dụ Linear Arithmetic) Từng công thức của SMT cụ thể phải đảm bảo thỏa mãn các yêu cầu của SMT – LIB [45] phiên bản 2 và lý thuyết first – order logic Hiện nay, SMT được ứng dụng rất rộng rãi trong các lĩnh vực nghiên cứu khoa học khác nhau bao gồm: static checking, predicate abstraction, test case generation, và bounded model checking over infinite domains; [46] giới thiệu SMT trên phương diện lý thuyết và các ứng dụng của nó Trong tài liệu này, chúng tôi sử dụng SMT như một Engine đánh giá chính sách Thay vì chúng tôi sẽ tìm kiếm policy nào thõa mãn yêu cầu người dùng với hệ thống
Lu ậ n v ă n Th ạ c S ĩ 42 HV: Hà Xuân S ơ n – 1570226 mà thay vào đó là xác định policy nào có giá trị trả về là “true” khi kết hợp với yêu cầu của người dùng Từ đó có thể tìm được chính sách thích hợp
Ngoài các phép toán so sánh về lý thuyết chuỗi như equal (=) hay not_equal (≠) các nghiên cứu trước đây đã sử dụng lý thuyết của First – Order Logic để thể hiện các phép so sánh trên SMT Kroning và cộng sự [47] đã sử dụng lý thuyết mảng “over bag” để có thể chuyển đổi các phép toán thuộc (∈) Ví dụ: ∀ 𝑣 ∈ {𝐶𝑎𝑛 𝑇ℎ𝑜; 𝐻𝑜 𝐶ℎ𝑖 𝑀𝑖𝑛ℎ; 𝐶𝑎 𝑀𝑎𝑢} Hay Suter [48] đã sử dụng lý thuyết khoảng “set function” để có thể chuyển đổi phép toán tập hợp (set theory) (, ≤, ≥) Ví dụ: age ≤ 16 Ngoài hai nghiên cứu trên, Zheng và cộng sự [49] đã ứng dụng các lý thuyết chuỗi để định nghĩa các phép toán so sánh phức tạp (over strings và string conversion) Để có thể sử dụng SMT trong đánh giá chính sách, chúng tôi cần phải có một phương thức chuyển đổi một – một từ cấu trúc XML theo XACML 3.0 sáng dạng đầu vào của SMT Solver Hướng tiếp cận của chúng tôi sẽ là chuyển đổi các yêu cầu ràng buộc của chính sách thành các phép toán logic thõa mãn SMT–LIB, tiếp theo tìm lý thuyết cho phép chuyển đổi từ một yêu cầu ràng buộc trên chính sách sang lý thuyết first – order logic Bước cuối cùng là chuyển đổi toàn bộ yêu cầu của người dùng thành dạng chuỗi giá trị của thuộc tính
Xem chuỗi này như một biến và chính sách như một hàm Chuyển toàn bộ biến và hàm vào SMT Solver sau đó chỉ nhận các cặp có giá trị trả về là “true” Phần 5.4 (định dạng đầu vào hệ thống) sẽ trình bày rõ hơn về cách chuyển đổi chính sách và yêu cầu truy cập.
Khái niệm chính sách bảo mật động
Sự khác biệt chính yếu của chính sách bảo mật động so với chính sách bảo mật tĩnh là trong suốt quá trình đánh giá yêu cầu người dùng thì chính sách bảo mật động được quyền thay đổi các giá trị thuộc tính và điều kiện ràng buộc, hay thậm chí là xóa bỏ toàn bộ policy đó hoặc thêm một policy mới ngay cả trong trường hợp policy bị cập nhật đã được gán cho yêu cầu của người dùng Nhóm tác giả Sloman và cộng sự [38] cũng giới thiệu một trong các tiêu chí của hệ thống quản lý chính sách bảo mật là làm cách nào để có thể thỏa mãn các tính năng cập nhật chính sách mà không làm ảnh hưỡng đến toàn hệ thống và không phải dừng hệ thống Khái niệm này cũng được nêu ra trong nghiên cứu của Laborde [39]
Theo như Dunlopt và cộng sự đã định nghĩa trong [40] một hệ thống được cho là có hỗ trợ môi trường chính sách động phải bao gồm các yêu tố sau:
• Chính sách có chứa các biến số mà giá trị của nó bị biến thiên theo thời gian (VD thời gian, vị trí)
• Các chính sách có thể bị thay đổi trong suốt thời gian đánh giá yêu cầu người dùng
Lu ậ n v ă n Th ạ c S ĩ 43 HV: Hà Xuân S ơ n – 1570226
• Các chính sách có thể được tạo mới cập nhật chỉnh sửa hoặc thêm mới trong thời gian đánh giá yêu cầu người dùng
• Một policy có thể bị loại bỏ mặc dù đã được gán cho một yêu cầu từ phía người dùng nhưng không được xử lý.
Ứng dụng của chính sách bảo mật động
Ngày nay ứng dụng của chính sách bảo mật động đang ngày càng được áp dụng và là một phương án thay thế thích hợp cho các hệ thống sữ dụng dữ liệu NoSQL cũng như các hệ thống phân tán, mạng xã hội, điện toán đám mây hay gần đây nhất là các ứng dụng được hỗ trợ IoTs (Internet of Things) Có rất nhiều nghiên cứu đã ứng dụng chính sách động thay cho chính sách tĩnh cho hệ thống của mình như [41] Các nghiên cứu ngày khai thác mức độ linh hoạt của chính sách động nhằm mục đích đáp ứng các yêu cầu về tính đa dạng của hệ thống (nhiều loại thiết bị kết nối, nhiều chính sách bảo mật, xử lý dữ liệu từ nhiều nguồn khác nhau) hoặc đa dạng về dạng dữ liệu lưu trữ (Dữ liệu có giá trị biến thiên theo thời gian, lưu trữ nhiều kiểu dữ liệu, hệ thống hay phát sinh dữ liệu mới)
Mazurek và cộng sự đã ứng dụng chính sách bảo mật động trong mô hình dữ liệu phân tán của mình trong [42] Trong hệ thống này, người dùng là chủ của dữ liệu mình sẻ được quyền tự đưa ra các chính sách bảo mật cho chính dữ liệu của họ Ở đây họ được quyền cập nhật dữ liệu ngay cả khi có sự tương tác của một người dùng khác Đặc điểm chính trong mô hình này là nhóm người dùng sử dụng được tác giả nhắm đến là các đối tượng người dùng không chuyên hoặc có ít kỹ năng tin học vẫn có thể tiếp cận và có khả năng sử dụng hệ thống Một ví dụ tiêu biểu khác của việc ứng dụng môi trường chính sách bảo mật động đó là nghiên cứu của hai tác giả Nabeel và Bertino [43] Trong nghiên cứu này hệ thống ứng dụng cơ chế chính sách bảo mật động để bảo vệ các dữ liệu nhạy cảm của người dùng khi được lưu trữ trên cloud và làm giảm đi chi phí về chu trình (mã hóa – giải mã) Ngoài ra, các hệ thống về quản lý công việc, giáo dục và y tế cũng ứng dụng khái niệm về chính sách bảo mật động nhằm linh hoạt chu trình xử lý và tăng mức độ an toàn trong các tình huống phức tạp thể hiện ở [44].
KIẾN TRÚC HỆ THỐNG
Cấu trúc policy
Trong hệ thống đề xuất của chúng tôi, chúng tôi vẫn sử dụng chuẩn XML để thiết kế chính sách bảo mật Cấu trúc cụ thể của một chính sách được thể hiện trong mô hình sau:
Hình 5.1: Mô hình cấu trúc chính sách bảo mật
• 0 *: có thể không có hoặc nhiều
• 1 *: tối thiểu là 1 hoặc nhiều hơn 1
Một chính sách bào mật bao gồm 3 mức như sau: Policy Set bao gồm một tập các policy được liên kết với nhau bằng giải thuật kết nối policy, một policy set sẽ gồm một hoặc nhiều policy; Policy bao gồm các luật (Rule) được liên kết với nhau bằng giải thuật kết nối luật, một policy sẽ bao gồm một hoặc nhiều rule; Rule bao gồm một Target (Action, Subject, Environment và Resource) và một condition chứa điều kiện so sánh
• Subject Category: chủ thể gửi câu truy vấn
• Action Category: hành động của chủ thể gửi câu truy vấn
• Environment Category: các giá trị môi trường khi chủ thể gửi câu truy vấn cho hệ thống
• Resource Category: Vùng dữ liệu mà người dùng muốn tương tác
• Effect: chứa các giá trị Permit và Deny nếu như toàn bộ Target và Rule đều được thỏa mãn thì giá trị của Effect sẽ được trả về
Lu ậ n v ă n Th ạ c S ĩ 49 HV: Hà Xuân S ơ n – 1570226 Hình 5.2: Thành phần chính sách bảo mật
Trong policy sẽ có nhiều luật (rule) trong mỗi luật sẽ có một Target để định nghĩa các thuộc tính sử dụng và một Condition để đặc tả điều kiện của tập luật đó Nếu thỏa mãn toàn bộ Condition thì kết quả trả về là giá trị trong Effect của Rule đó, nếu không thỏa mãn một trong các Condition trả về trường hợp ngược lại Trong trường hợp không thỏa mãn Target thì kết quả trả về sẽ là Indeterminate
Trong policy sẽ có một hoặc nhiều Target để lọc các yêu cầu của người dùng Nếu thỏa mãn toàn bộ Target sẽ xét đến các điều kiện ràng buộc trong rule Nếu không thỏa mãn một trong các Target sẽ trả về giá trị Not Applicable
Trong policy sẽ có một Effect nơi định nghĩa kết quả trả về khi thỏa mãn toàn bộ
Trong policy sẽ có một giải thuật kết nỗi các luật (Combining Algorithm Rule) lưu thuật toán kết hợp các luật trong chính sách
• Target: một policy sẽ bao gồm nhiều Target mục đích chính của Target trong Policy là loại bỏ các request nếu không thỏa mãn các điều kiện Chính vì vậy một request nếu không thể thõa mãn các điều kiện Target sẽ bị trả về là Not Applicable
• Rule: một policy sẽ có nhiều Rule Trong mỗi Rule tương ứng sẽ bao gồm một Target và một Condition Target đóng vai trò định nghĩa các thuộc tính người dùng, các yêu cầu ràng buộc về môi trường, các hoạt động cụ thể trên vùng dữ liệu cụ thể
• Condition: chứa đựng các giá trị để so sánh cũng như phương thức so sánh Ví dụ trong khoảng, lớn hơn, nhỏ hơn, thuộc tập hợp, v.v… Nếu các điều kiện trong mỗi Rule không được thỏa mãn thì kết quả trả về sẽ là Indeterminate
• Combining Algorithm: chứa mã ID của giải thuật ứng dụng để kết nối các luật có trong chính sách
Lu ậ n v ă n Th ạ c S ĩ 50 HV: Hà Xuân S ơ n – 1570226
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 quả cuối cùng của hệ thống
5.1.2.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 Not Applicable 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à Not Applicable 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á là Deny hoặc Not Applicable 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
Lu ậ n v ă n Th ạ c S ĩ 51 HV: Hà Xuân S ơ n – 1570226 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ề Not Applicable
5.1.2.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 c) First-applicable
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à Not Applicable, 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ề Not Applicable
Cấu trúc request
Request là yêu cầu truy cập được gửi từ người dùng Trong đó bao gồm các thuộc tính Subject, Resource, Action và Environment
Subject là thực thể yêu cầu truy cập Một Subject thì bao gồm định danh cho subject đó và có thể có một hay nhiều thuộc tính Trong ví dụ sau thì subject “Nguyen Van A” có vai trò là “Admin”, tuổi là 18 và địa chỉ ở “Ho Chi Minh”
Resource là một dữ liệu, vùng dữ liệu hay một thành phần của hệ thống mà Subject yêu cầu truy xuất Mỗi Resource gồm định danh của resource (ResourceID), ResourceRequest thể hiện câu truy vấn người dùng yêu cầu, Attributes là các tiêu chí lọc của người dùng
Action là thành phần xác định các loại truy cập được yêu cầu trên Resource Action bao gồm định danh cho action đó và có thể có một hoặc nhiều thuộc tính thể hiện ngữ cảnh khi hành động đó được thực hiện Các lệnh được hỗ trợ bao gồm {READ, WRITE, EXE} tuy nhiên trong phần hiện thực chúng tôi chỉ chú trọng đến lệnh READ
Lu ậ n v ă n Th ạ c S ĩ 53 HV: Hà Xuân S ơ n – 1570226
Environment là thành phần cung cấp các thông tin về hệ thống Mỗi hệ thống sẽ có 1 định danh và có thể có một hoặc nhiều thuộc tính Trong ví dụ sau thể hiện hệ thống HCMUT có thời gian làm việc là 19:00, và yêu cầu đó được thực hiện tại Tp Hồ Chí Minh
“Place” : “Ho Chi Minh City University of Technology”,
Kịch bản
Để hiểu rõ hơn ta xét ví dụ sau được lấy ra từ [52]:
Policy: “Một y tá khi muốn truy c ậ p vào dữ liệu của b ệ nh nhân phải thỏa mãn các tính chất sau: đang ở phòng b ệ nh nơi có sự hiện diện của bệnh nhân hoặc người thân của bệnh nhân đó trong khoảng thời gian từ 8:00 sáng đế n 20:00; bệnh nhân phải l ớ n h ơ n 16 tu ổ i, địa chỉ bao gồm (Can Tho, TP Ho Chi Minh, Ca Mau), khoa chữa trị là khoa tim m ạ ch và có b ệ nh là cao huy ế t áp Các luật thể hiện là Deny và luật kết hợp giữa các luật đó là Deny overrides (dov)”
Request: “Vào lúc 8:00AM một y tá gửi yêu cầu muốn đọ c tất cả thông tin b ệ nh nhân đang có mặt tại phòng đ i ề u tr ị với các thông tin như sau: bệnh nhân bị b ệ nh cao huy ế t áp và có thông tin cá nhân là tu ổ i l ớ n h ơ n 50, địa chỉ t ạ i TP H ồ Chí Minh”
Yêu cầu trên sẽ được thể hiện thành câu request theo định dạng JSON như sau:
“Location” : “Patients Room”, “WorkingTime” : “8:00 AM”,
“Address”: “Ho Chi Minh city”, }
Lu ậ n v ă n Th ạ c S ĩ 54 HV: Hà Xuân S ơ n – 1570226
Định dạng đầu vào hệ thống
Hệ thống của chúng tôi sẽ nhận đầu vào là yêu cầu truy cập của người dùng biểu diễn một chuỗi các giá trị cụ thể kết hợp với tập các policy có sẵn trong hệ thống Cấu trúc cặp request và policy được định nghĩa như sau:
Câu trúc đầu vào trong hệ thống được chia thành 2 phần: phần đầu là định dạng chính sách (theo XML format) thành input SMT Solver Format, phần thứ hai là chuyển các yêu cầu từ phía người dùng (theo JSON format) thành dạng input của SMT Solver
5.4.1 Policy Để dễ dàng biểu diễn chính sách thành các toán tử trong phép toán logic, ta có ký hiệu như bảng sau:
Bảng 5 1: Các ký hiệu sử dụng trong trài liệu
Dựa vào bảng ký hiệu trên ta có công thức rút gọm của Policy trên như sau:
• com_al_ID: là giải thuật kết hợp các tập luật mà policy đó ứng dụng
• r 1 , r 2 , … , r n : là tập các rule của policy đó
Lu ậ n v ă n Th ạ c S ĩ 55 HV: Hà Xuân S ơ n – 1570226
Dựa vào yêu cầu của Policy là các tập luật sẽ thể hiện theo kiểu Deny ta sẽ định nghĩa thành từng rule như sau:
• P[dov]: and (subject - “Y tá”, action – “đọc”, resource – “thông tin bệnh nhân”)
• r1[Deny]: or (current – time < 8:00 AM, current – time > 8:00 PM)
• r2[Deny]: different (current – place , Patient room)
• r3[Deny]: not belong (address, {Can Tho, Ho Chi Minh, Ca Mau})
• r5[Deny]: different (bệnh, bệnh cao huyết áp)
• r6[Deny]: different (khoa, khoa tim mạch)
Sau đó chúng tôi sẽ chuyển toàn bộ rule và policy này thành các application constrain (ac) như sau:
• ac1 : “thông tin bệnh nhân” ∈ resource
• ac3 : ∀ v ∈ thời gian truy cập, v > 8:00 AM
• ac4 : ∀ v ∈ thời gian truy cập, v < 8:00 PM
• ac5 : ∀ v ∈ vị trí truy cập, v ≠ phòng bệnh nhân
• ac6 : ∀ v ∈ {Can Tho, Ho Chi Minh, Ca Mau}, v ≠ địa chỉ
• ac8 : bệnh ≠ bệnh cao huyết áp
• ac9 : khoa ≠ khoa tim mạch
Với thuộc tính là một thành phần nằm trong tập hợp {subject, action, resource, thời gian truy cập, vị trí truy cập, địa chỉ, tuổi, bệnh, khoa} các ràng buộc từ ac10 …ac18 giải quyết vấn đề Indeterminate nếu các yêu cầu từ phía người dùng không chứa các thuộc tính đã nêu
Dựa vào kiến trúc của một policy chúng tôi phân loại thành những Applicable Space (AS) như sau: nếu các yêu cầu của người dùng thỏa mãn hết các luật và ràng buộc của chính sách bảo mật thì kết quả trả về sẽ là giá trị của Effect Trường hợp khác, nếu như các yêu cầu của người dùng thiếu đi một thuộc tính của luật hoặc ràng buộc nào đó sẽ trả về kết quả Indeterminate Trường hợp còn lại sẽ trả về Not Applicable khi các giá trị Target không được thỏa mãn Như vậy một policy sẽ có 3 vùng dữ liệu bao gồm: Applicable Space;
Indeterminate Space; Not Applicable Space Dựa vào định nghĩa này chúng tối đưa ra định nghĩa vùng quản lý dữ liệu của một policy như sau:
Lu ậ n v ă n Th ạ c S ĩ 56 HV: Hà Xuân S ơ n – 1570226
Một request được xem là thích hợp với một policy khi rơi vào AS AS , AS IN trường hợp còn lại sẽ trả về AS NA Kết hợp với các tập luật đã được định nghĩa thành các ac phía trên policy ban đầu sẽ biến đổi thành:
Tùy thuộc vào các quyết định trên XACML, một không gian dữ liệu của chính sách sẽ được chia thành 4 disjoint subjects (DS) bao gồm (DSP, DSD, DSIN, DSNA) tượng chưng cho Permit, Deny, Indetermintae và Not Applicable Các DS này sẽ thể hiện thành những phép toán logic mà ở đó một yêu cầu từ phía người dùng chỉ có thể thỏa mãn một trong 4 DS của một policy Chúng tôi sẽ định nghĩa từng DS dựa vào bảng dưới đây
Hình 5.3: Công thức xác định Decision Space [61]
Một câu request sẽ xét xem nó có thuộc lớp DSNA hay không nếu không rơi vào trường hợp Not Applicable thì nó sẽ rơi vào ba trường hợp còn lại là DSP, DSD, DSIN Dưới đây là biểu thức logic cho từng rule của policy ban đầu được tái định nghĩa thành phép toán logic và được sắp xếp theo thứ tự (DSP, DSD, DSIN, DSNA):
Lu ậ n v ă n Th ạ c S ĩ 57 HV: Hà Xuân S ơ n – 1570226
Giải thuật kết hợp các tập luật rule trong policy sử dụng là deny – override ta ứng dụng công thức tính disjoint subjects của một policy như sau:
Theo định nghĩa của XACML 3.0 [19] thì ta có định nghĩa tập disjoint subject của Indeterminate sẽ là tập hợp của toàn bộ Indeterminate Permit, Indeterminate Deny, và Indeterminate Permit Deny Ta có công thức sau:
Dựa các công thức trên chúng ta xây dựng 4 disjoint subject cho policy ban đầu như sau:
Với A, B, và C lần lượt là:
Sau khi biến đổi một policy theo cấu trúc của XACML 3.0 thành các disjoint subject được định nghĩa bằng phép toán logic Chúng ta áp dụng lý thuyết của SMT [62] để chuyển toàn bộ DS này thành đầu vào của một SMT Lợi thế chính của giải pháp này là chúng ta có thể áp dụng các lý thuyết về First Order Logic để định nghĩa các ràng buộc điều kiện có chứa trong chính sách bảo mật mà các hướng tiếp cận khác gặp vấn đề Chính vì vậy ta có đầu vào của chính sách được định nghĩa như sau:
Với A, B, và C lần lượt là:
Lu ậ n v ă n Th ạ c S ĩ 58 HV: Hà Xuân S ơ n – 1570226
5.4.2 Request Để có thể chuyển đổi một – một từ yêu cầu định dạng kiểu JSON sang mảng dữ liệu Mảng dữ liệu này chứa các giá trị là thuộc tính và loại truy cập của người dùng, thuộc tính của môi trường và vùng dữ liệu muốn truy xuất Để chuyển đổi yêu cầu từ JSON format sang dạng input SMT Solver format ta sẽ chuyển thành một tập chứa các giá trị thuộc tính như sau:
𝑄: { SubjectID = "Nurse", Location = "Patients Room", WorkingTime = "8:00AM", Action
= "Read", PatientDisease = "hypertension", Age > 50, Address = "Ho Chi Minh city"}
Cấu trúc đầu ra
Giá trị trả về (response) của một chính sách khi kết hợp với một yêu cầu của người dùng có thể trả về là: Permit trong trường hợp cho phép truy cập, Deny trong trường hợp không được truy cập, Not Applicable trong trường hợp yêu cầu của người dùng không thích hợp với chính sách đó và Indeterminate trong trường hợp thiếu các thuộc tính bắt buộc trong chính sách Ví dụ trong chính sách yêu cầu phải có thông tin về độ tuổi người gửi yêu cầu (age > 16) tuy nhiên trong câu truy vấn của người dùng không chứa thuộc tính đó và sẽ bị trả về là Indeterminate Trong đặc tả mới đây của XACML v3.0 thì ngoài 4 nhóm response chính thì trong Indetermiate được chia thành 3 nhóm nhỏ hơn bao gồm: Indetermiate Permit, Indeterminate Deny, Indeterminate Permit Deny Cả ba nhóm trên có thể được trả về nếu như giải thuật kết hợp của chính sách lựa chọn là: Permit Override và Deny Override Định nghĩa cụ thể về ba nhóm giá trị này được đưa ra bởi [19] như sau:
• Indeterminate Permit: Sử dụng trong trường hợp chính sách đánh giá có thể được xem xét là Permit (thiếu điều kiện thỏa mãn) nhưng không phải Deny, và giá trị của
• Indeterminate Deny: Sử dụng trong trường hợp chính sách đánh giá có thể được xem xét là Deny (thiếu điều kiện thỏa mãn) nhưng không phải Permit, và giá trị của
• Indterminate Permit Deny: Sử dụng trong trường hợp chính sách đánh giá có thể được xem xét vừa là Permit vừa là Deny cùng với đó giá trị của Effect vừa là Permit và Deny Ví dụ trong một chính sách tồn tại đồng thời hai luật với hai giá
Lu ậ n v ă n Th ạ c S ĩ 59 HV: Hà Xuân S ơ n – 1570226 trị Effect lần lượt là Permit và Deny Tuy nhiên không thể thỏa mãn được cả hai luật đó chính vì vậy giá trị trả về sẽ là Indeterminate Permit Deny
Với: IN = IN P ∪ IN D ∪ IN PD
Phụ thuộc và tập các giá trị thuộc tính của yêu cầu người dùng mà chúng ta có thể xác định được già trị của từng formulas (𝐹) là {True, False} thì chúng ta sẽ xác định được giá trị trả về của câu truy vấn đó là một trong các giá trị {Permit, Deny, Not Applicable,
Indeterminate} Quay lại kịch bản đưa ra ở đầu bài, ta có bảng giá trị sau:
Subject Y tá Y tá ac 0 = True
Resource Thông tin bệnh nhân Thông tin bệnh nhân ac 1 = True
Action Đọc Đọc ac 2 = True
Thời gian truy cập Or (v > 8:00 AM, v < 8:00 PM) 8:00 AM ac 3,4 = False
Vị trí truy cập v ≠ Phòng điều trị Phòng điều trị ac 5 = False Địa chỉ v ≠ {Can Tho, Ho Chi Minh,
Ho Chi Minh ac 6 = False
Bệnh Cao huyết áp Cao huyết áp ac 8 = False
Khoa điều trị Khoa tim mạch ac 18 = True Indeterminate
Bảng 5 2: Phân tích mức độ tương thích giữa request và policy Ở bảng 5.2 các thuộc tính yêu cầu của chính sách bảo mật gần như được yêu cầu truy cập thỏa mãn Tuy nhiên ở thuộc tính khoa điều trị do ac 18 quản lý không có giá trị trong yêu cầu truy cập nên giá trị trả về của ac 18 = True Chính vì vậy giá trị trả về là Indeterminate
Phân loại cập nhật chính sách
Các cập nhật trên PAP đều được lắng nghe qua các applicable constrain (ac) và đối tượng quản lý chính sách Để thỏa mãn các yêu cầu về môi trường động và cũng như tăng khả năng xử lý, chúng tôi phân chia các yêu cầu trên thành hai loại:
• Loại 1: cập nhật lại các policy nhưng policy được gán cho yêu cầu người dùng không bị cập nhật: loại này hệ thống của chúng tôi không xử lý mà vẫn tiếp tục thực hiện bình thường
• Loại 2: cập nhật lại các policy trong đó có policy gán quyền cho phép hoặc không cho phép người dùng truy cập Trong loại này chúng tôi tiếp tục chia nhỏ ra thành hai trường hợp cụ thể Trường hợp thứ nhất là cập nhật chính sách bảo mật thông qua việc xóa bỏ policy và trường hợp thứ hai là cập nhật chính sách bảo mật thông
Lu ậ n v ă n Th ạ c S ĩ 60 HV: Hà Xuân S ơ n – 1570226 qua việc thay đổi nội dùng policy bao gồm: thay đổi giá trị thuộc tính, thay đổi giá trị effect, ràng buộc (ac) loại một rule trong chính sách hoặc thậm chí thêm rule mới
Tr ườ ng h ợ p 1: Xóa policy
Hình 5 4: Trường hợp xóa policy
Hình 5 5: Tìm một policy thích ứng thay thế cho policy bị xóa
Trong trường hợp này policy gán cho câu request bị xóa khỏi PAP như hình 5.4 Lúc này hệ thống sẽ tìm lại một policy thích hợp (trong tập policy hiện tại ở PAP) Nếu có bất kỳ policy nào có DS là Deny hoặc Permit trả về giá trị “true” thì sẽ gán cho câu truy vấn của người dùng Trường hợp các policy bị Indeterminate sẽ tiến hành viết lại câu truy vấn
Trường hợp còn lại là Not Applicable sẽ loại bỏ Sau cùng dựa vào các (ac) còn thiếu mà hệ thống sẽ gửi yêu cầu đến hệ thống và người dùng cung cấp giá trị của các thuộc tính yêu cầu (tồn tại trong chính sách nhưng không xuất hiện trong yêu cầu người dùng) Dựa vào kết quả trả về của hệ thống và người dùng mà hệ thống sẽ lựa chọn chính sách bảo mật thích hợp và gán quyền cho câu truy vấn Hoạt động cụ thể được miêu tả chi tiết trên hình 5.5
Tr ườ ng h ợ p 2: C ậ p nh ậ t thông tin và giá tr ị ràng bu ộ c trên policy
Lu ậ n v ă n Th ạ c S ĩ 61 HV: Hà Xuân S ơ n – 1570226
Các thông tin bị cập nhật bao gồm: điều kiện, giá trị Effect, các thuộc tính, cập nhật các giá trị ràng buộc trên (ac) hay thậm chí là thêm mới hoặc lại bỏ luật bảo mật Ở trường hợp thứ 2 chúng tôi phân loại thành 3 trường hợp con bao gồm:
• Cập nhật: các thông tin và điều kiện ràng buộc của policy bị cập nhật
• Thêm điều kiện hoặc luật: Thêm luật hoặc điều kiện ràng buộc
• Xóa luật hoặc điều kiện: Xóa luật hoặc điều kiện ràng buộc
Tùy thuộc vào dạng thay đổi mà chúng tôi sẽ viết lại câu truy vấn, tái đánh giá hoặc đi qua bước tiếp theo Bảng dưới đây sẽ thể hiện rõ các bước thực hiện
Xóa Thêm Cập nhật Định nghĩa Xóa luật hay các ràng buộc điều kiện (ac)
Thêm luật hay các ràng buộc điều kiện (ac)
Cập nhật điều kiện, luật, Effect và giải thuật kết hợp
Tái đánh giá Không Có Có
Viết lại câu truy vấn Không Có Không
Bảng 5 3: Phân loại các dạng cập nhật của chính sách bảo mật
Trong mô hình của chúng tôi các (ac) sau khi được gán cho từng luật hoặc ràng buộc cụ thể sẽ luôn lắng nghe PAP có bất kỳ cập nhật nào hay không và phân loại loại thay đổi sau đó gửi về cho PDP tất cả các thông tin về cập nhật Ở đây việc phân loại và thực hiện các yêu cầu về nghĩa vụ người dùng sẽ được tiến hành
Trong bảng 5.3 trường hợp xóa (ac) sẽ làm giảm bớt các ràng buộc có trong chính sách bảo vệ chính vì vậy ở loại cập nhật này chúng ta không cần tái đánh giá chính sách cũng như viết lại câu truy vấn ban đầu Trong trường hợp cập nhật lại các giá trị thuộc tính hay các giá trị ở Effect và (ac) thì sẽ làm ảnh hưởng đến kết quả đánh giá câu truy vấn chính vì vậy sau khi nhận được có sự thay đổi là cập nhật (ac) thì yêu cầu truy cập phải được đánh giá chính sách lại với đúng chính sách đã gán trước đó sau đó thực thi nghĩa vụ người dùng
Trong trường hợp cuối, loại cập nhật là thêm (ac) chính sách sẽ có thêm ràng buộc chính vì vậy yêu cầu truy cập của người dùng phải thỏa mãn điều kiện ràng buộc của (ac) này Chính vì lý do đó mà câu yêu cầu ban đầu của người dùng có khả năng trả về không xác định (Indeterminate) vì không thể thỏa mãn thuộc tính yêu cầu của chính sách dẫn đến hệ thống không thể trả về Permit hay Deny Để giải quyết vấn đề này yêu cầu truy cập ban đầu phải được viết lại bằng cách thêm thuộc tính còn thiếu vào câu truy vấn và giá trị thuộc tính này sẽ phụ thuộc vào kết quả trả về khi người dùng phản hồi lại yêu cầu cung cấp thông tin từ phía hệ thống thông qua tác vụ Obligation Service
Lu ậ n v ă n Th ạ c S ĩ 62 HV: Hà Xuân S ơ n – 1570226
Mô hình tổng quan
Cấu trúc của mô hình được biểu diễn như hình 5.6, bao gồm các thành phần chính chủ thể
(Subject S), hành động (Action), dữ liệu (Resource), môi trường (Environemt E), chính sách (Policy), các chính sách phân quyền (Authorization), SMT Solver (Evaluation), và nghĩa vụ người dùng (Obligation)
Hình 5 6: Tổng quan mô hình
• Chủ thể (Subject) : đư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 Subject Attribute 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, vai trò trong hệ thống, …
• Hành động (Action) : thể hiện thao tác mà chủ thể sẽ tác động lên dữ liệu như : Read, Write và Execute Mỗi hành động chỉ được mang một giá trị tại mỗi thời điểm
• Dữ liệu (Resource) : chính là vùng dữ liệu mà hệ thống cần được bảo vệ hoặc vùng dữ liệu mà người dùng muốn truy cập, mỗi đối tượng cũng được gắn với một danh sách các thuộc tính Resource Attribute
• Môi trường (Environment) : được gắn với một danh sách các thuộc tính
Environment Attribute thể hiện trạng thái hiện tại của hệ thống : thời gian, địa điểm, trạng thái hệ thống
• Chính sách phân quyền (Authorization) : các chính sách mô tả các luật dùng để lựa chọn chính sách thích hợp để gán cho yêu cầu truy cập Authorization sẽ gửi các thuộc tính Policy, Request Access, Environment Attribute, Action, và Subject
Lu ậ n v ă n Th ạ c S ĩ 63 HV: Hà Xuân S ơ n – 1570226
• Đánh giá chính sách (SMT Solver): đóng vai trò đánh giá chính sách, ở chức năng này sẽ trả về giá trị Response tùy thuộc vào giá trị trả về mà hệ thống sẽ sinh ra
Obligation Service hay truy xuất vào Resource hay không cấp quyền truy cập cho người dùng
• Nghĩa vụ người dùng (Obligation): Gửi các request về phía người dùng cung cấp các giá trị trên các thuộc tính còn thiếu và gửi về hệ thống trước khi truy xuất vào vùng dữ liệu bảo vệ.
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 5, ở 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”, “PEP Engine”, “Policy Manager”,
“Resource Manager”, “Update Manager”, “SMT Solver”, “Response”, “Obligation” và được biểu diễn như hình 6.1
Hình 6 1: Lược đồ thành phần
- PDP Engine: là trung tâm của hệ thống, đây là nơi 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
- PEP Engine: đây là nơi nhận các yêu cầu của người dùng dưới dạng định dạng JSON sau đó sẽ chuyển đổi toàn bộ yêu cầu cho PDP dưới định dạng tập giá trị thuộc tính
- Policy Manager (PAP): 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 Manager” được định nghĩa thành 4 nhóm Decision Space tương ứng với giá trị có thể gán cho yêu cầu truy cập {Indeterminate, Not Applicable, Permit, Deny} với mỗi nhóm là một phép toán logic
- Resource Manager (PIP): là thành phần quản lý các truy xuất đến database Hiện tai hệ thống chỉ hỗ trợ trên dữ liệu MongoDB
- Update Manager (PAP): là thành phần quản lý các cập nhật có trong PAP và phân loại nhóm cập nhật Nếu có bất kỳ cập nhật nào xảy ra thì thành phần này sẽ báo với hệ thống để tái đánh giá, viết lại câu truy vấn, tìm một truy vấn thích hợp hơn hay đi đến bước kế tiếp
Lu ậ n v ă n Th ạ c S ĩ 68 HV: Hà Xuân S ơ n – 1570226
- SMT Solver (PDP): thành phần này chịu tránh nhiệm đánh giá chính sách Có thể xem thành phần này là con của “PDP Engine”
- Response: là thành phần chứa giá trị trả về Phụ thuộc vào giá trị trả về của SMT
Solver mà policy sẽ có kết quả {Indeterminate, Not Applicable, Permit, Deny} với yêu cầu người dùng
- Obligation: chứa các nghĩa vụ mà người dùng phải thỏa mãn trước khi truy cập vào dữ liệu Trong mô hình của chúng tôi, thành phần này còn đóng vai trò khá quan trọng là lấy giá trị của các thuộc tính sau khi viết lại câu truy vấn.
Lược đồ lớp hệ thống
Các chính sách được lưu trữ tập trung trong PAP dưới dạng file XML, khi có bất kỳ yêu cầu truy cập nào từ phía người dùng các chính sách này sẽ được định dạng thành input của SMT Solver và gán vào yêu cầu của người dùng tại PDP sau đó gửi về SMT Solver Để mô hình các chính sách , hệ thống xây dựng các lớp như hình 6.2 Các lớp này hiện thực các thành phần của chính sách được mô tả trong phần cấu trúc policy (5.1) Trong đó:
- Lớp Condition: được sử dụng trong Policy và Rule, dùng để định nghĩa các ràng buộc mà yêu cầu truy xuất phải thỏa mãn nếu muốn truy xuất vào dữ liệu hệ thống Điều kiện sẽ gồm các thành phần: chủ thể (subject), hành động (action), dữ liệu
(resource), và môi trường (environment)
- Lớp Target: được sử dụng trong PolicySet, Policy và Rule, 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), dữ liệu (resource)
- Lớp PolicySet: bao gồm một danh sách các chính sách (policies : List) và luật kết hợp (combiningPolicyAlgID) 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 Một danh sách các mục tiêu (target: List)
- Lớp Policy : một chính sách bao gồm các một danh sách các luật (rules : List) và giải thuật (combiningPolicyAlgID) để kết hợp kết quả của các luật lại cho ra kết quả của chính sách Một danh sách các mục tiêu (target: List)
- Lớp Rule : một luật sẽ bao gồm hiệu ứng (effect) của luật, hiệu ứng này có thể là cho phép hoặc từ chối (Permit/Deny), hiệu ứng được áp dụng khi và chỉ khi kết quả đánh giá của biểu thức điều kiện (condition) là đúng Khác với Policy và PolicySet một luật chỉ có tối đa một mục tiêu (target: Target)
Lu ậ n v ă n Th ạ c S ĩ 69 HV: Hà Xuân S ơ n – 1570226
Hình 6 2: Lược đồ lớp biểu diễn chính sách bảo mật
6.2.2 Lược đồ lớp biểu diễn cấu trúc đầu vào Định dạng của đầu vào được mô tả trong phần cấu trúc request (5.2) Trong phần này sẽ mô tả phần hiện thực liên quan Khi hệ thống nhận được các yêu cầu truy xuất, thì các yêu cầu này cũng được gởi dưới dạng JSON Do đó để cho việc lấy thông tin đơn giản, hệ thống sẻ chuyển đổi từ JSON thành dạng chuỗi các dữ liệu để lưu nội dung yêu cầu dưới dạng các giá trị cụ thể cho mỗi thuộc tính Trong phần này, yêu cầu truy xuất sẽ được phân rã ra thành 4 thành phần chính bao gồm (Request Subject, Request Action, Request Resource và Request Environment) như hình 6.3 Trong lớp Request có chứa các phương thức để lấy các giá trị cụ thể cho mỗi thuộc tính
- Request: là lớp biểu diễn yêu cầu của người dùng, lớp này có các lớp
RequestSubject, RequestAction, RequestResource, RequestEnvironment biểu diễn các thành phần Subject, Action, Resource, Environment của yêu cầu Lớp này cũng chứa các phương thức để lấy ra thuộc tính của các thành phần
- RequestSubject: biểu diễn thành phần Subject của yêu cầu, gồm có danh sách các thuộc tính (SubjectAtt) và giá trị cụ thể cho từng thuộc tính đó (SubjectVal)
- RequestAction: biểu diễn thành phần Action của yêu cầu, gồm có danh sách các thuộc tính (ActionAtt) và giá trị cụ thể cho từng thuộc tính đó (ActionVal)
- RequestResource: biểu diễn thành phần Resource của yêu cầu, gồm có danh sách các thuộc tính (ResourceAtt) và giá trị cụ thể cho từng thuộc tính đó (ResourceVal)
Lu ậ n v ă n Th ạ c S ĩ 70 HV: Hà Xuân S ơ n – 1570226
- RequestEnvironment: biểu diễn thành phần Environment của yêu cầu, gồm có danh sách các thuộc tính (EnvironmentAtt) và giá trị cụ thể cho từng thuộc tính đó (EnvironmentVal),
Hình 6 3: Lược đồ lớp biểu diễn cấu trúc đầu vào – (Request)
Trong hướng tiếp cận của chúng tôi, đầu vào của SMT Solver ngoài yêu cầu truy cập của người dùng nó còn nhận vào danh sách các chính sách nằm trong PAP Danh sách này được biểu diễn thành 4 thành phần Decision Space (DS) bao gồm (Permit, Deny, Indeterminate, Not Applicable) Trong lớp DecisionSpace có chứa các phương thức lấy giá trị công thức của 4 DS được biểu diễn như hình 6.4
- Decision Space (DS): Sau khi chính sách bảo mật của hệ thống được nạp vào PAP, các chính sách này sẽ được chuyển thành dữ liệu đầu vào của SMT Solver dưới dạng các phép toán logic Ở đây, các Decision Space sẽ được chia thành 4 Disjoint Subject (tương ứng với Permit, Deny, Indeterminate và Not Applicable) Các phương thức trong lớp này lấy từng DS thông qua các phương thức lấy tương ứng
Lu ậ n v ă n Th ạ c S ĩ 71 HV: Hà Xuân S ơ n – 1570226
- Decision Space Permit: Quy định phương thức đánh giá request (danh sách các giá trị của thuộc tính) cho trường hợp Permit
Hình 6 4: Lược đồ lớp biểu diễn cấu trúc đầu vào – (Decision Space)
- Decision Space Deny: Quy định phương thức đánh giá request (danh sách các giá trị của thuộc tính) cho trường hợp Deny
- Decision Space Not Applicable: Quy định phương thức đánh giá request (danh sách các giá trị của thuộc tính) cho trường hợp Not Applicable
- Decision Space Indeterminate: Quy định phương thức đánh giá request (danh sách các giá trị của thuộc tính) cho trường hợp Indeterminate
6.2.3 Lược đồ lớp biểu diễn cấu trúc đầu ra
Trong phần này sẽ mô tả phần biểu diễn của cấu trúc đầu ra Như đã trình bày ở cấu trúc đầu ra (5.7) Để dễ dàng cho cập nhật giá trị đầu ra trong quá trình đánh giá, đầu ra được diễn bằng các lớp như hình 5.6 Một đầu ra sẽ bao gồm kết quả đánh giá phân quyền cuối cùng, trạng thái đánh giá: đánh giá thành công hay có lỗi, trong trường hợp có lỗi sẽ có danh sách các lỗi đính kèm Hơn nữa đầu ra cũng có chứa danh sách các chính sách đã được đánh giá và kết quả đánh giá của chính sách
- Response: thể hiện kết quả trả về sau khi đánh giá yêu cầu truy cập, bao bồm yêu cầu truy cập của người dùng và danh sách các chính sách được thể hiện dưới dạng công thức logic Ở đây giá trị của yêu cầu truy cập sẽ phụ thuộc vào có bất kỳ chính sách nào có giá trị trả về là “ true ”
- Request: là lớp biểu diễn yêu cầu của người dùng, lớp này có các lớp RequestSubject, RequestAction, RequestResource, RequestEnvironment biểu diễn
Lu ậ n v ă n Th ạ c S ĩ 72 HV: Hà Xuân S ơ n – 1570226 các thành phần Subject, Action, Resource, Environment của yêu cầu Lớp này cũng chứa các phương thức để lấy ra thuộc tính của các thành phần
Hình 6 5: Lược đồ lớp biểu diễn cấu trúc đầu ra
- DecisionSpace: Sau khi chính sách bảo mật của hệ thống được nạp vào PAP, các chính sách này sẽ được chuyển thành dữ liệu đầu vào của SMT Solver dưới dạng các phép toán logic Ở đây, các Decision Space sẽ được chia thành 4 Disjoint Subject (tương ứng với Permit, Deny, Indeterminate và Not Applicable) Các phương thức trong lớp này lấy từng DS thông qua các phương thức lấy tương ứng
6.2.4 Lược đồ lớp biểu diễn quản lý cập nhật chính sách
Trong phần này sẽ mô tả các chức năng cập nhật chính sách Ở lớp này chia làm hai phần quản lý hai đối tượng khác nhau là policy và applicable constraint Ở lớp policy các chính sách có thể được cập nhật một cách ngẫu nhiên vì vậy việc quản lý cập nhật cho policy là quan sát các policy hiện tại trong hệ thống có bị loại bỏ hay không hay có thêm bất kỳ policy nào mới hay không Tương tự đối với lớp AC (Applicable Contrains) sẽ theo dõi sự cập nhật các điều kiện ràng buộc, giá trị thuộc tính hay việc thêm và xóa các AC Hình 6.5 dưới đây mô tả chi tiết hơn về lớp UpdateManagement
Lược đồ lớp tuần tự
Trong phần này, đề tài sẽ trình bày các lược đồ tuần tự chính của hệ thống:
Lược đồ tuần tự đánh giá yêu cầu truy cập: lược đồ này mô tả quá trình đánh giá một yêu cầu truy cập Lược đồ này được mô tả trong hình 6.9 và bao gồm các bước:
- Nhận yêu cầu (bước 1.1) từ phía người dùng: hệ thống nhận yêu cầu truy xuất từ người dùng dưới dạng JSON
- Chuyển đổi yêu cầu người dùng (bước 1.2) PEP sẽ chuyển đổi yêu cầu của người dùng cho PDP dưới dạng chuỗi giá trị thuộc tính
- Lấy chính sách bảo mật (bước 1.3) sau khi nhận được yêu cầu người dùng, PDP sẽ lấy danh sách các chính sách bảo mật từ PAP (Policy Manager) dưới định dạng 4 Disjoint Subject tương ứng với (Permit, Deny, Indeterminate và Not Applicable)
- Đánh giá chính sách : Sau khi nhận được yêu cầu truy cập và danh sách chính sách bảo mật PDP sẽ dùng SMT Solver tìm một chính sách bảo mật thích hợp nhất Nếu trong chính sách bảo mật có các yêu cầu nghĩa vụ người dùng thì PDP sẽ gửi yêu cầu đến Obligation Service (bước 1.4.1) tại đây sau khi thực hiện các yêu cầu nghĩa vụ này sau đó sẽ gửi lại phản hồi cho PDP
- Gửi kết quả đánh giá (bước 1.5): Sau khi tìm được chính sách thích hợp PDP sẽ gửi giá trị đánh giá chính sách cho Response
Lu ậ n v ă n Th ạ c S ĩ 76 HV: Hà Xuân S ơ n – 1570226
- Gửi giá trị cho PEP (bước 1.6): Response sẽ gửi giá trị là đồng ý cho truy cập hay không cho phép truy cập
- Trả về kết quả (bước 1.7): chuyển giá trị thực thi cho người dùng
Hình 6 9: Lược đồ lớp của quá trình đánh giá câu truy vấn
Lược đồ tuần tự viết lại yêu cầu truy cập: lược đồ này mô tả quá trình viết lại một yêu cầu truy cập Lược đồ này được mô tả trong hình 6.10 và bao gồm các bước:
- Nhận yêu cầu (bước 1.1) từ phía người dùng: hệ thống nhận yêu cầu truy xuất từ người dùng dưới dạng JSON
- Chuyển đổi yêu cầu người dùng (bước 1.2) PEP sẽ chuyển đổi yêu cầu của người dùng cho PDP dưới dạng chuỗi giá trị thuộc tính
- Lấy chính sách bảo mật (bước 1.3) sau khi nhận được yêu cầu người dùng, PDP sẽ lấy danh sách các chính sách bảo mật từ PAP (Policy Manager) dưới định dạng 4 Disjoint Subject tương ứng với (Permit, Deny, Indeterminate và Not Applicable)
- Đánh giá chính sách : Sau khi nhận được yêu cầu truy cập và danh sách chính sách bảo mật PDP sẽ dùng SMT Solver tìm một chính sách bảo mật thích hợp nhất
- Cập nhật chính sách bảo mật (bước 1.3.1): Nếu có bất kỳ cập nhật nào xảy ra trong Policy Manager thì lớp này sẽ gửi một thông báo đến quản lý cập nhật (Update Manager) Quản lý cập nhật sẽ xem xét loại cập nhật và gửi về PDP Engine loại cập nhật cùng với ID của chính sách bảo mật (bước 1.3.2) Tại đây, PDP sẽ phân ra hai trường hợp là chính sách đó có phải là chính sách gán quyền cho yêu cầu truy cập
Lu ậ n v ă n Th ạ c S ĩ 77 HV: Hà Xuân S ơ n – 1570226 hay không Nếu có thì tùy thuộc vào loại cập nhật mà làm bước tiếp theo Nếu không phải là chính sách bảo mật gán quyền cho yêu cầu truy cập thì đi đến bước kế tiếp
Trong mô hình 6.10 trình bày về phương thức viết lại câu truy vấn
- Gửi yêu cầu xác định giá trị thuộc tính (bước 1.3.3): hệ thống xác định giá trị thuộc tính còn thiếu bằng cách khởi tạo các Obligation Service
- Gửi trả về giá trị thuộc tính yêu cầu (bước 1.3.4): Sau khi người dùng cung cấp giá trị của thuộc tính còn thiếu Giá trị này sẽ được chuyển về cho PDP Sau đó PDP sẽ chuyển toàn bộ giá trị thuộc tính này và yêu cầu truy cập ban đầu về cho PEP (bước 1.3.5)
- Viết lại câu truy vấn (bước 1.3.6): Yêu cầu mới được sinh ra và gửi về lại cho PDP Engine Vòng lặp này sẽ bị lặp đi lặp lại khi có mỗi thay đổi nào trên đối tượng chính sách bảo mật
- Gửi kết quả đánh giá (bước 1.4): Sau khi tìm được chính sách thích hợp PDP sẽ gửi giá trị đánh giá chính sách cho Response
- Gửi giá trị cho PEP (bước 1.5): Response sẽ gửi giá trị là đồng ý cho truy cập hay không cho phép truy cập
- Trả về kết quả (bước 1.6): chuyển giá trị thực thi cho người dùng
Hình 6 10: Lược đồ lớp của quá trình viết lại câu truy vấn
Giải thuật chính trong mô hình Rew – SMT
Hai giải thuật chính của hệ thống bao gồm:
Lu ậ n v ă n Th ạ c S ĩ 78 HV: Hà Xuân S ơ n – 1570226
{ Giải thuật 1: sẽ tìm policy thích hợp nhất thay thế cho policy bị xóa Giải thuật này sẽ lấy đầu vào là request ban đầu và toàn bộ policy đang có trong hệ thống Nếu như tìm được một policy có kết quả trả về là Permit/Deny là true thì giải thuật sẽ trả về ID của policy đó và kết thúc giải thuật Nếu không tồn tại một Policy nào thỏa mãn mà trả về kết quả Indeterminate Trong trường hợp này mọi tập luật và điều kiện ràng buộc bị thiếu sẽ tự sinh thành các nghĩa vụ (obligation) tương tác trực tiếp với hệ thống hoặc người dùng Phụ thuộc vào giá trị trả về của hệ thống hoặc người dùng mà chúng ta sẽ tìm được policy tương ứng
Giải thuật 1: tìm policy thay thế cho policy bị xóa
{ Giải thuật 2: có mục tiêu chính là phân loại và giải quyết các trương hợp cập nhật trên đối tượng policy được gán quyền cho yêu cầu truy cập của người dùng Trong trường hợp giá trị cập nhật của chính sách là “Delete” thì giải thuật không làm gì và trả về kết quả câu truy vấn ban đầu Trường hợp khác khi giá trị cập nhật là “Update” giải thuật sẽ tái đánh giá câu truy vấn ban đầu và trả về giá trị sau khi kết thúc quá trình tái đánh giá chính sách Trong trường hợp còn lại, các tập luật và ràng buộc điều kiện trong chính sách mới cập nhật sẽ được bổ xung bằng cách tương tác với người dùng và hệ thống thông qua chức năng Obligation, sau đó các giá trị này sẽ được kết hợp với yêu cầu truy cập ban đầu và trả về một câu request mới Cuối cùng PDP sẽ đánh giá lại yêu cầu sau khi được viết lại với chính sách sau khi được cập nhật
Lu ậ n v ă n Th ạ c S ĩ 79 HV: Hà Xuân S ơ n – 1570226
Giải thuật 2: các phân loại và thực hiện khi policy thay đổi
ĐÁNH GIÁ HỆ THỐNG
Chính sách bảo mật mẫu
Để có dữ liệu cho quá trình đánh hệ thống, đề tài có liên hệ với các tác giả ở các nghiên cứu trước đây và xin tập dữ liệu chính sách mẫu Sau đó các chính sách này phải thỏa mãn các yêu cầu về cấu trúc của một chính sách được đưa ra bởi tổ chức OASIS cụ thể là ở phiên bản mới nhất (XACML v3.0) Trong quá trình lựa chọn, đề tài sử dụng ba tập mẫu được sử dụng ở ngoài đời thật và được miêu tả cụ thể ở bảng 7.1 và được miêu tả chi tiết như sau: v Continue-a: Tập chính sách này được thực hiện và chuyển đổi thành định dạng XACML v3.0 bởi Canh Ngo và cộng sự [58] Ban đầu định dạng của tập chính sách bảo mật này được đinh dạng theo chuẩn XACML v2.0 Nó là một chính sách bảo mật được sử dụng để điều chỉnh các quyền của người dùng như tác giả hoặc các thành viên ủy ban chương trình trong một hệ thống quản lý hội nghị v KMarket: Là một chính sách bảo mật thực tế được lấy từ Balana vào năm 2013
KMarket là một chính sách bảo mật mã nguồn mở và được sử dụng để quản lý ủy quyền trong một ứng dụng thương mại trực tuyến Các phép toán so sánh sử dụng bên trong KMarket bao gồm các phép tính cơ bản như so sánh bằng (equal) và phép toán so sánh số học (integer-greater-than, integer-one-and-only) v GEYSERS: Là một chính sách bảo mật thực tế được lấy từ dự án GEYSERS
GEYSERS được viết tắt từ tên của dự án đó (Generalised Architecture for Dynamic Infrastructure Services) Các thông tin liên quan đến dự án và tập chính sách bảo mật này có thể tham khảo thêm ở đường dẫn sau (http://www.geysers.eu/)
Lu ậ n v ă n Th ạ c S ĩ 81 HV: Hà Xuân S ơ n – 1570226
Policy set Policies Rules Attributes Operators
GEYSERS 3 6 7 33 3 Bảng 7 1: Tập dữ liệu chính sách bảo mật
Trong đó, ý nghĩa của các tham số như sau:
- Policy levels: số lượng các chính sách bảo mật lồng nhau Ở đây độ phức tạp được tính bởi mức độ lồng nhau giữa các chính sách bảo mật Ở Continue có số lượng chính sách lồng nhau nhiều nhất với 6 lớp chính sách GEYSERS và KMarket lần lượt là 3 và 2 lớp chính sách Chính vì vậy độ phức tạp của Continue-a sẽ cao hơn hai tập dữ liệu mẫu còn lại
- Policy set: số lượng tập chính sách bảo mật (policy set) Bảng trên cũng cho thấy có sự khác biết rất lớn ở số lượng tập chính sách bảo mật giữa ba tập chính sách mẫu Với số lượng lần lượt là 111, 1 và 6 thuộc về Continue-a, GEYSERS và KMarket
- Policies: số lượng các chính sách bảo mật Ở Continue-a là 266 và GEYSERS, KMarket lần lượt là 7 và 3 policies
- Rules: số lượng các luật bảo mật Ở Continue-a là 298 và GEYSERS, KMarket lần lượt là 12 và 33 policies
- Attributes: số lượng các thuộc tính của mỗi tập dữ liệu mẫu, các thuộc tính bao gồm chủ thể, hành động, đối tượng, môi trường trong hệ thống được bảo vệ bởi chính sách bảo mật Ở đây độ phức tạp cũng được tính bởi số lượng khác nhau giữa các thuộc tính Vì vậy độ phức tạp của Continue-a (14 thuộc tính) cao hơn rõ rệt so với GEYSERS và KMarket với cùng 3 thuộc tính
- Operators: Miêu tả các phương thức so sánh được định nghĩa bên trong tập dữ liệu mẫu Tuy thuộc vào phương thức so sánh được đưa ra trong tập mẫu mà chúng ta thiết kế các comparation function tương ứng.
![Hình 3. 2: Lượng dữ liệu số ước tính được sinh ra từ năm 2010 đến năm 2020 [ 35 ] - 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 NoSQL](https://media.store123doc.com/figures/005/199/hinh-luong-lieu-uoc-tinh-sinh-5199603.webp)
![Hình 3. 9: Thành phần và luồng xử lý XACML [19] - 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 NoSQL](https://media.store123doc.com/figures/005/199/hinh-thanh-phan-luong-xu-ly-xacml-5199609.webp)
![Hình 3. 10: Cấu trúc chính sách trong XACML [19] - 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 NoSQL](https://media.store123doc.com/figures/005/199/hinh-cau-truc-sach-xacml-5199610.webp)
![Hình 3. 11: Ví dụ về chính sách trong XACML [19] - 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 NoSQL](https://media.store123doc.com/figures/005/199/hinh-vi-du-sach-xacml-5199611.webp)
![Hình 4. 3: Rew-XAC Model [52] - 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 NoSQL](https://media.store123doc.com/figures/005/199/hinh-rew-xac-model-5199614.webp)
![Hình 5.3: Công thức xác định Decision Space [61] - 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 NoSQL](https://media.store123doc.com/figures/005/199/hinh-cong-thuc-xac-dinh-decision-space-5199616.webp)
