Chương 1. GIỚI THIỆU Trình bày tổng quan về đề tài, mục tiêu của đề tài, ý nghĩa khoa học - thực tiễn, và giới hạn của đề tài. CƠ SỞ DỮ LIỆU NOSQL Trình bày cơ sở lý thuyết, các mô hình cơ sở dữ liệu NoSQL và lý do áp dụng mô hình Document Store cho đề tài này. Từ đó đưa ra lựa chọn MongoDB sẽ là cơ sở dữ liệu được áp dụng trong đề tài luận văn.
ĐIỀU KHIỂN TRUY XUẤT Trình bày cơ sở lý thuyết về điều khiển truy xuất, các mô hình điều khiển truyền thống và mô hình điều khiển dựa trên thuộc tính ABAC. Trình bày về XACML v3.0 là một hiện thực của mô hình ABAC và sẽ được áp dụng trong đề tài này. CƠ SỞ LÝ THUYẾT VÀ CÁC CÔNG TRÌNH NGHIÊN CỨU LIÊN QUAN Trình bày khái niệm về lý thuyết SMT, chính sách bảo mật động (dynamic policy). Định nghĩa như thế nào là một hệ thống có hỗ trợ chính sách bảo mật động, các tiêu chí đánh giá.
Tóm tắt các nghiên cứu trước đây về đánh giá chính sách và đưa ra giải pháp cho chính sách bảo mật động. 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ĩ 3 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. 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.
ĐÁ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. KẾT LUẬN Trình bày tổng kết báo cáo, các giới hạn và hướng phát triển của đề tài.
Luận văn Thạc Sĩ 4 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.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 Các mô hình dữ liệu NoSQL 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ĩ 5 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. 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ĩ 6 HV: Hà Xuân Sơn – 1570226 2.2 Mô hình Document Store Trong mô hình này, khái niệm document là để chỉ một nội dung có cấu trúc, bán cấu trúc hoặc không có cấu trúc. Ví dụ của document có thể rất đa dạng, như JSON, BSON, XML, YAML hay phức tạp hơn là các file Word, Excel, PDF,… Ta có thể xem mô hình Document Store là một bản cải tiến của mô hình Key-Value. Khi các bộ Key-Value có thêm thuộc tính ngữ nghĩa hoặc siêu dữ liệu đến một mức độ nhất định, ta có thể gom nhóm các bộ key-value thành một document. Việc gom nhóm đó ta có thể thực hiện theo 4 phương thức chính sau đây.
• Gom nhóm thành Collections, tức là ta gom nhóm một cách chủ động, người dùng hoặc chương trình trong quá trình chạy sẽ gom nhóm trực tiếp các dữ liệu liên quan. • Gom nhóm theo Tags, các nội dung sẽ được gán các tags, sau đó các dữ liệu sẽ gom nhóm thành document theo các tags. • Gom nhóm theo các siêu dữ liệu vô hình (Non-visible Metadata). • Gom nhóm thành cấu trúc phân cấp (Directory Hierachies).
Mô hình Document Store thích hợp với các hệ thống lưu trữ Big Data phần nào coi trọng tính ngữ nghĩa của dữ liệu (khác với mô hình Key-Value, đơn thuần chỉ là lưu trữ dữ liệu). Ví dụ, mô hình Key-Value lưu trữ các log file (web/game/application logs,…) còn mô hình Document Store có thể ứng dụng trong lưu trữ các status của một mạng xã hội, tweet, comments,… Do đặc tính có thêm ngữ nghĩa của document trong Document Store, cơ chế bảo mật của mô hình này được nâng cao hơn, uyển chuyển và mịn hơn so với mô hình Key-Value. Ngoài các cơ chế bảo mật cơ bản như xác thực người dùng, mã hoá dữ liệu, ta có thể áp dụng các cơ chế điều khiển truy xuất cơ bản cho mô hình Document Store (như RBAC), hoặc cung cấp cơ chế cho phép người lập trình thực hiện điều khiển truy xuất tuỳ chỉnh trên dữ liệu lưu trữ [3,4,13,14,15]. Tuỳ theo công nghệ hiện thực mà mức độ nâng cao này cũng khác nhau.
Ta xem xét hai ví dụ về công nghệ sau đây để tham khảo rõ hơn về vấn đề này. MongoDB : MongoDB lưu trữ một collection dưới định dạng BSON, mỗi một collection được xem như một “database” và người lập trình/ quản trị viên có thể cài đặt điều khiển truy xuất ở mức độ database trong hệ thống. Mô hình điều khiển truy xuất được áp dụng trong MongoDB là RBAC. Mỗi người dùng (tiến trình, thành phần chủ động) sẽ được gán vào một role.
Trong MongoDB, có 3 nhóm role [11]: Read (chỉ đọc), ReadWrite (đọc và ghi) và Admin (quản trị). Mỗi role cung cấp cho người dùng một danh sách các quyền truy Luận văn Thạc Sĩ 7 HV: Hà Xuân Sơn – 1570226 xuất trên một database luận lý cụ thể. Một người dùng có thể có nhiều role trên nhiều database luận lý. Một giới hạn của RBAC trong MongoDB là role khi được uỷ thác cho người dùng, ta không thể tuỳ chỉnh giảm bớt quyền trong role đó đối với người dùng đã được cấp.
CouchDB : CouchDB [12] là kho lưu trữ dữ liệu document dưới dạng JSON, đặc biệt được thiết kế cho ứng dụng WebService hoặc REST-API. Vì đặc thù ứng dụng Web, nên CouchDB cung cấp cơ chế xác thực người dùng qua 3 phương thức OAuth, HTTP và Basic [12]. Về điều khiển truy xuất, tương tự như MongoDB, CouchDB điều khiển truy xuất theo mô hình RBAC. Mỗi người dùng dữ liệu (gồm cả các tiến trình, thành phần chủ động dùng dữ liệu) sẽ được gán role thuộc 3 nhóm sau đây: • DB Members có quyền Read (+Write) trên một database.
• DB Admin có toàn quyền trên một database. • Server Admin có toàn quyền trên tất cả database Ngoài ra, CouchDB cung cấp một cơ chế cho phép điều khiển truy xuất ở mức mịn hơn, nhưng đòi hỏi người lập trình phải tốn công sức lập trình. Đó là cơ chế kiểm định dữ liệu thông qua hook validate_doc_update [12].