Nghiên cứu và phát triển hệ thống điều khiển truy xuất bảo vệ tính riêng tư cho cơ sở dữ liệu nosql mongodb

ĐẠI HỌC QUỐC GIA TP.HCM
TRƯỜNG ĐẠI HỌC BÁCH KHOA
KHOA KHOA HỌC & KỸ THUẬT MÁY TÍNH

LUẬN VĂN TỐT NGHIỆP

NGHIÊN CỨU VÀ PHÁT TRIỂN
HỆ THỐNG ĐIỀU KHIỂN TRUY XUẤT
BẢO VỆ TÍNH RIÊNG TƯ
CHO CƠ SỞ DỮ LIỆU NOSQL MONGODB
GVHD: ThS. TRẦN THỊ QUẾ NGUYỆT
GVPB: ThS. LÊ THỊ KIM TUYẾN
====================
SVTH 1: ĐINH TRẦN VIỆT HOÀNG (51104451)
SVTH 2: NGUYỄN ANH KIỆT

TP. HỒ CHÍ MINH, 5/2016

(50901314)



Chương 1: GIỚI THIỆU
1.1 M
ô tả
vấn
đề
Ngày nay, dữ liệu có cấu trúc, bán cấu trúc (XML), phi cấu trúc (video, hình
ảnh, âm thanh) tăng lên nhanh chóng. IBM ước lượng, có 2.5 nhân 10 mũ 18 bytes
(2,500,000,000,000,000,000) dữ liệu được tạo ra mỗi ngày [1]. Cơ sỡ dữ liệu quan hệ
(RDBMS) khó có thể đáp ứng nhu cầu lưu trữ khi cấu trúc dữ liệu thường xuyên thay

đổi [2]. Big Data ra đời để đáp ứng nhu cầu đó. Khái niệm Big Data được định nghĩa là
sự thu thập, quản lỹ và phân tích dữ liệu [1].
Big data được ứng dụng trong nhiều lĩnh vực như phân tích thị trường chứng
khoán, phân loại ảnh Picasa, khai phá dữ liệu trên Pandora, Netflix, Amazon, phân tích
dựa trên khách hàng hoặc mạng xã hội (Facebook, Twitter),... [1]. Sự bùng nổ thông tin
và dữ liệu cá nhân cần được thu thập, sử dụng đúng mục đích. Việc lạm dụng có thể làm
lộ thông tin cá nhân. Ví dụ chương trình nghe lén điện thoại của Cơ quan An ninh Quốc
Gia Mỹ đã làm giảm lòng tin nhân dân Mỹ. Vì vậy, vấn đề riêng tư và an toàn thông tin
được quan tâm hơn bao giờ hết.
Sau thời gian tìm hiểu, nhóm chọn đề tài “PHÁT TRIỂN FRAMEWORK
ĐIỀU KHIỂN TRUY XUẤT CHO HỆ THỐNG CƠ SỞ DỮ LIỆU NOSQL”.

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

Các mục tiêu và nhiệm vụ được đặt ra:
Tìm hiểu các mô hình điều khiển truy xuất, phân tích ưu nhược điểm của các mô hình
đó.
Tìm hiểu cơ sở dữ liệu lớn, đặc biệt là cơ sở dữ liệu NoSQL MongoDB.
Đề xuất mô hình điều khiển truy xuất trên MongoDB.
Xây dựng Mongo Proxy.

Xây dựng các ứng dụng với các chức năng cơ bản áp dụng hệ thống điều khiển truy cập
bảo vệ tính riêng tư dựa trên mục đích và ngữ cảnh.
Xây dựng framework điều khiển truy cập bảo vệ tính riêng tư dựa trên mục đích và ngữ
cảnh.


1.3 Ý
nghĩ
a
Xây dựng framework điều khiển truy xuất dựa trên vai trò và ngữ cảnh có thể ứng
dụng vào thực tế như quản lý giáo dục, thông tin bệnh viện.


Chương 2: KIẾN THỨC NỀN TẢNG
Trong chương này, chúng ta sẽ đề cập đến vấn đề Big Data, các hệ cơ sở dữ liệu
không quan hệ (NoSQL) và ngôn ngữ lập trình NODE.JS.

2.1 B
ig
Data
2.1.1 Định nghĩa Big Data
Trong những năm gần đây, chúng ta bước vào kỷ nguyên Big Data, kỷ nguyên
bùng nổ thông tin, làm thay đổi cách chúng ta sống, làm việc, suy nghĩ [3]. Thuật ngữ
Big Data bao gồm thu thập, quản lý, phân tích trên các dữ liệu có cấu trúc (dữ liệu quan
hệ), dữ liệu bán cấu trúc (XML), dữ liệu phi cấu trúc (video, hình ảnh). Dữ liệu lớn
cũng có những nguồn mới, như trong máy tính (vd: các file log nhật ký hay mạng cảm
biến), trong thiết bị di động (video, hình ảnh, tin nhắn), và trong các thiết bị máy móc
kết nối với nhau (vd như xe, máy bay hoặc các thiết bị giám sát từ xa) nhằm mục đích
lên kế hoạch bảo trì kịp thời [1].

2.1.2 Đặc điểm Big Data
Big Data có năm đặc điểm [3],[4]:
Volume (khối lượng dữ liệu lớn): số lượng data khổng lồ được tạo ra mỗi
giây, không phải chỉ được tính bằng đơn vị Terabyte mà tính bằng Zettabyte hay
Brontobyte. Cứ mỗi ngày, trên facebook có 10 tỷ tin nhắn, 4,5 tỷ lần “like”, 350 triệu
hình mới được upload,... Sự gia tăng dữ liệu khổng lồ này không khả thi nếu việc lưu
trữ sử dụng công nghệ lưu trữ truyền thống với cơ sở dữ liệu quan hệ. Big Data có thể
lưu trữ dễ dàng lượng thông tin trên và dùng cho hệ thống phân tán (distributed system)
[4]
.
Velocity (tốc độ cao) : Big Data technology cho phép xử lý dữ liệu ngay
khi chúng được tạo ra, ngay cả khi dữ liệu chưa được đưa vào database. Như message
trong mạng xã hội lan truyền trong vài giây, tốc độ kiểm tra gian lận trong giao dịch thẻ
tín dụng, hay tốc độ tính bằng mili giây để quyết định mua bán cổ phiếu dựa vào phân
tích mạng xã hội [4].
Variety (đa dạng các loại dữ liệu) : Trong quá khứ, dữ liệu cấu trúc được
dùng nhiều vì phù hợp với table hoặc cơ sở dữ liệu quan hệ, ví dụ như dữ liệu tài chính.
Như ngày nay, 80% dữ liệu của thế giới là không cấu trúc, vì thế không dễ để đưa vào
các table (ví dụ hình ảnh, video). Với Big Data, có thể sử dụng nhiều loại dữ liệu khác
nhau: bán cấu trúc, không cấu trúc và cả dữ liệu truyền thống là dữ liệu có cấu trúc [4].


Value (giá trị dữ liệu cao): cho phép con người hiểu rõ hiện tại và dự đoán
trước tương lai [3]. Các công ty bắt đầu tạo được những giá trị to lớn từ việc sử dụng Big
Data [4]. Việc kinh doanh nào không quan tâm đặc biệt tới Big Data sẽ bị bỏ lại phía sau
[4]
.
Veracity (tính xác thực thấp) : uncertainties in the data (không chắc chắn
dữ liệu) [3]. Với rất nhiều loại dữ liệu, chất lượng và độ chính xác ít được kiểm soát làm
tính xác thực thấp. Nhưng dữ liệu lớn và công nghệ phân tích cho phép bù đắp cho sự

thiếu xác thực [4].

2.1.3 Những ứng dụng Big Data [1]
•
•
•
•
•
•
•

Phân tích tâm lý thị trường chứng khoán.
Phân loại hình ảnh Picasa của Google.
Phân tích khách hàng (Facebook, Twitter).
Phân tích dữ liệu các hệ thống mạng báo hiệu (đèn giao thông, cơ sở hạ tầng).
Hệ thống đặt chỗ du lịch kết hợp sở thích khách hàng.
Giải trí trên mạng xã hội.
Hệ thống chuẩn đoán y học.

2.1.4 Tính riêng tư trong Big Data [1]
Việc tích hợp giữa phân tích dữ liệu lớn với thông tin công cộng (hoặc thông tin
riêng tư được cung cấp một cách tự nguyện bởi người giám sát được ủy thác thông tin
đó) có thể giúp tìm kiếm nhanh trên các bộ dữ liệu lớn về phim ảnh, giọng nói, dữ liệu
cảm biến, và văn bản thư điện tử để cải thiện độ an toàn chung cho phục hồi sau sự cố,
để ngăn ngừa các mối đe dọa khủng bố, và để hiểu những mối quan tâm của cộng đồng.
Người ta có thể nghĩ tới điều này như là những phản hồi nếu so sánh với những hệ
thống phát cảnh báo khẩn cấp. Tất nhiên, mối quan tâm và mảng đen tối tiềm tàng hiện
hữu trong dữ liệu lớn và các phân tích phim ảnh, giọng nói, thư điện tử khi nó trở thành
sự truy cập trái phép vào các thông tin cá nhân. Những hệ thống như vậy đòi hỏi phải sử
dụng một cách có trách nhiệm, hoàn toàn kín đáo, và phải kiểm duyệt thông tin thu thập

được từ nguồn công cộng và mạng máy tính.

2.2 N
oSQ
L
Các cơ sở dữ liệu quan hệ lưu trữ dữ liệu một cách nhất quán bất kể bản chất
của dữ liệu hay ứng dụng nhưng gặp khó khăn trong vấn đề mở rộng hoặc thay đổi cấu
trúc. Hiện nay, development platforms là web scale chứ không chỉ là network scale,
nhiều ứng dụng có thể chạy phân tán trên nhiều server khác nhau đòi hỏi dynamic
scaled. Bên cạnh đó sự phát triển nhanh chóng của computing và sự bùng nổ thông tin
yêu cầu việc lưu trữ dữ liệu phải nhanh và có thể mở rộng nhanh để đáp ứng các ứng


dụng xử dụng cơ sở dữ liệu. Cơ sở dữ liệu quan hệ làm ảnh hưởng xấu đến hiệu suất,
tốc độ trong các hệ thống web scale nên không còn phù hợp.
Để giải quyết vấn đề trên, nhiều loại cơ sở dữ liệu không sử dụng mô hình dữ
liệu quan hệ (non-relational database) được đưa vào sử dụng trong những năm gần đây,
và được gọi là các NoSQL database. NoSQL có ưu điểm là dễ mở rộng theo chiều
ngang (horizontal scaling), tính sẳn sàng cao (high available), giá thành thấp (low cost),
hiệu suất cao (high performance) [5]. NoSQL là bước phát triển mới của thế hệ cơ sở dữ
liệu mới : phân tán (distributed) và không ràng buộc (non-relational) [7]. NoSQL thường
được dùng để lưu trữ dữ liệu lớn, phù hợp với Big Data.
Kiến trúc NoSQL database hiện nay có lợi cho sự phát triển tự do của dữ liệu
và traffic. Do đó, tạo thuận lợi cho việc phát triển các giải thuật song song (như
MapReduce) giúp các hệ thống phân tán hoạt động hiệu quả. NoSQL đang dẫn đầu các
phương pháp lưu trữ và phân tích thông tin dữ liệu người dùng.
Hệ thống dữ liệu quan hệ sử dụng metadata để kiểm soát chặt chẽ việc xử lý
đồng bộ để duy trì sự nhất quán dữ liệu. Nhưng việc phân tán dữ liệu trên nhiều hệ
thống của NoSQL làm lỏng lẻo việc xử lý đồng bộ. Do đó, tính nhất quán và toàn vẹn
không được đảm bảo. Một điểm yếu khác của NoSQL là hầu như hỗ trợ security cho

lớp database [5].

2.2.1 Các loại NoSQL

Bảng 1: Các loại NoSQL và Database tương ứng [5]


Bảng 2: Bảng so sánh các loại database NoSQL [5]
Trong đó:
Key-Value: loại NoSQL đơn giản nhất, còn gọi là Row Store [5].
Column-Oriented: lưu trữ theo kiểu cột, tối ưu hóa cho truy vấn dữ liệu lớn [5].
Document-Oriented: mỗi khóa kết hợp với một dữ liệu phức tạp có thể là bán
cấu trúc, phi câu trúc; không cần schema chặt chẽ. Nên việc dùng Document-Oriented
làm tăng hiệu suất và dễ sử dụng cho các hệ thống lưu trữ phân tán hơn là dùng các cơ
sở dữ liệu quan hệ truyền thống [5].
Graph database: dùng để lưu trữ thông tin về mạng như mạng xã hội, bản đồ,...

2.2.2 Lợi ích khi dùng NoSQL [6]
NoSQL cung cấp khả năng mở rộng và hiệu suất cao hơn các cơ sở dữ liệu
quan hệ truyền thống:
Đáp ứng được sự thay đổi nhanh chóng của dữ liệu lớn, có cấu trúc,bán cấu trúc và phi
cấu trúc.
• Schema dữ liệu mới thêm vào không ảnh hướng đến dữ liệu cũ.
• Hỗ trợ lập trình hướng đối tượng, do đó dễ sử dụng và linh hoạt hơn.
• Kiến trúc hiệu quả, tăng khả năng mở rộng, xây dựng cơ sở phân tán, linh động thay vì
nguyên khối, cứng nhắc như kiến trúc cũ.
•

2.2.3 Các đặc điểm của NoSQL [6]
Dynamic Schema : (Schema động) Cơ sở dữ liệu quan hệ (RDBMS yêu

cầu phải khai báo Schema trước khi thêm dữ liệu vào. Việc này không phù hợp với sự
phát triển nhanh chóng hiện nay. Có dữ liệu có tính chất khác, thì schema của database
phải thay đổi lại. Nếu database lớn, việc thay đổi này diễn ra chậm đáng kể. Vì vậy sử
dụng các RDBMS cho dữ liệu có schema động không thích hợp. Các NoSQL database
được xây dựng để cho phép dữ thêm dữ liệu mà không cần khai báo schema trước, làm


giảm thời gian chờ, không cần quan tâm đến service interruption. Do đó việc phát triển
ứng dụng nhanh hơn, lập trình và quản lý dữ liệu đơn giản hơn.
Auto - sharding : là cơ chế tự động của MongoDB dùng để chia tách một
dữ liệu kích thước lớn cho rất nhiều server (cluster) [7]. Do đó, MongoDB hỗ trợ việc
định hình theo chiều ngang. Dữ liệu và các câu truy vấn được phân bố đều trên các
server. Khi một server bị hư hại sẽ có server khác thực hiện công việc thay thế [6]. Auto –
Sharding phục vụ 3 mục tiêu [7]:
Làm cho cluster trong suốt với người dùng.
Làm cho cluster luôn sẵn sàng để đọc hoặc ghi.
Làm cho cluster phát triển tự nhiên.
Replication : Hầu hết các NoSQL hỗ trợ nhân rộng dữ liệu để duy trì tính
sẵn sàng trong các trường hợp có sự cố hay bảo trì hệ thống, do đó NoSQL hỗ trợ khả
năng chuyển đổi dự phòng và phục hồi hệ thống.
Integrated Caching : Các NoSQL hỗ trợ khả năng caching rất tốt cho cả
tác vụ đọc và ghi. Thích hợp cho các ứng dụng đòi hỏi băng thông cao và độ trễ thấp,
điều mà các RDBMS khó đáp ứng được.
Với những đặc điểm và lợi ích của NoSQL, nhóm quyết định chọn MongoDB
để hiện thực đề tài.

2.3 M
ongo
DB
2.3.1 Giới thiệu mô hình dữ liệu MongoDB

MongoDB là một schema-free document database được viết bằng C++ trong
một dự án mở của 10gen Inc. Mục đích của MongoDB để rút ngắn khoảng cách giữa
mô hình key-value và RDBMS [5].
MongoDB là một NoSQL theo kiểu document store, lưu trữ dưới dạng BSON
(một dạng tương tự JSON), và có khả năng đánh chỉ mục index. Dữ liệu trong
MongoDB có schema linh hoạt [8], không cần phải khai báo schema nếu thêm dữ liệu
mới.
a. Document Structure
Thiết kế mô hình dữ liệu cho các ứng dụng MongoDB tập trung vào cấu trúc
của document và làm thế nào các ứng dụng biểu diễn quan hệ giữa các dữ liệu. Hai cách
để biểu diễn quan hệ: tham khảo (references) và nhúm document (embedded
documents).
Kiểu biểu diễn tham khảo


Tham khảo là lưu mối quan hệ giữa các dữ liệu bằng các đường link từ 1
document tới 1 document khác. Ứng dụng lưu các tham khảo này và truy xuất các dữ
liệu liên quan. Đó là sự chuẩn hóa mô hình dữ liệu.

Hình :Mô hình dữ liệu sử dụng tham khảo để liên kết các document.
Cả contact document và access document đều chứa tham khảo đến user
document.
Dữ liệu nhúng (embedded data)
Dữ liệu nhúng lưu dữ liệu liên quan trong cùng 1 document. MongoDB
document cho phép nhúng document con vào 1 trường hoặc 1 mảng trong document
cha. Sự không chuẩn hóa này cho phép ứng dụng truy xuất và xử lí dữ liệu có liên quan
trong 1 thao tác cơ sở dữ liệu.


Hình : Ví dụ nhúng document này trong document khác

b. Tính nguyên tố (không thể chia, giãn lược) của tác vụ ghi (Atomicity of
Write Operations)
Trong MongoDB, tính nguyên tố của tác vụ ghi ở mức document, không có tác
vụ ghi đơn nào ảnh hưởng nhiều hơn 1 document hoặc 1 collection. Mô hình dữ liệu
không chuẩn hóa với dữ liệu nhúng kết hợp tất cả dữ liệu liên quan trong 1 document.
Điều này giúp tác vụ ghi có thể chèn hoặc cập nhật dữ liệu cho 1 thực thể 1 lần. Đó gọi
là tính nguyên bản của tác vụ ghi. Dữ liệu chuẩn hóa chia dữ liệu cụ thể thành nhiều
collection và do đó cần nhiều tác vụ ghi hơn đễ cập nhật hoặc chèn dữ liệu. Lúc này tác
vụ ghi không còn nguyên bản nữa. Tuy nhiên, schema hỗ trợ atomic writes cho phép
hạn chế cách sử dụng dữ liệu của ứng dụng để đảm báo tính nguyên tố.
c. Sự phát triển của document
Thao tác thêm phần tử vào mảng hay thêm trường mới đều tăng kích thước
document.
Đối với MMAPv1 storage engine, nếu kích thước document vượt quá sự phân
bổ bộ nhớ cho document đó, MongoDB sẽ phân bổ lại bộ nhớ document trên ổ đĩa, điều
này có thể ảnh hưởng đến quyết định chuẩn hóa hay không chuẩn hóa dữ liệu.
d. Sử dụng dữ liệu và performance
Khi thiết kế mô hình dữ liệu, cần để ý đến việc ứng dụng sẽ sử dụng database
vào việc gì. Ví dụ, nếu ứng dụng chỉ sử dụng những document được thêm vào gần nhất,
cần quan tâm đến capped-collection [9]. Nếu ứng dụng chủ yếu thực hiện tác vụ đọc trên
collection, thêm index để tăng performance.


2.4 C
ác
khái
niệm
mô
hình
hóa

dữ
liệu
tron
g
Mon
goD
B
2.4.1 Thiết kế mô hình dữ liệu (Data Model Design)
Mô hình dữ liệu hiệu quả sẽ hỗ trợ tốt cho ứng dụng. Vấn đề quan tâm chính là
cấu trúc dữ liệu cho ứng dụng sẽ sử dụng kiểu nhúng (embed) hay dùng tham khảo (use
references).
a. Mô hình nhúng (Embedded Data Models)
Với MongoDB, có thể nhúng các dữ liệu quan hệ với nhau trong một cấu trúc
hay một document. Schema này được hiểu là mô hình không chuẩn hóa, tận dụng lợi
thế rich document của MongoDB. Mô hình dữ liệu nhúng giúp các ứng dụng cần ít lệnh
truy vấn và update, làm hiệu suất của thao tác đọc cao hơn so với mô hình dữ liệu tham
khảo.
Tổng quát, dùng mô hình dữ liệu nhúng khi:
-

Quan hệ ràng buộc one-to-one giữa các thực thể, và cần quan sát 1 thực thể bên trong
một thực thể khác.
Quan hệ ràng buộc one-to-many giữa các thực thể, trong đó cần quan sát nhiều thực thể
trong một thực thể khác.


Ví dụ: One-to-One Relationships with Embedded Documents

Hình 3: Ví dụ address document chứa một reference đến patron document.

Hình 4: Sử dụng mô hình dữ liệu nhúng cho patron và address document.


Ví dụ: Model One-to-Many Relationships with Embedded Documents

Hình 5: patron document có nhiều address document

Hình 6: Sử dụng mô hình dữ liệu nhúng cho patron và address document.
Tuy nhiên mô hình này làm tăng kích thước document sau khi được tạo, gây
ảnh hưởng hiệu suất tác vụ ghi và làm dữ liệu phân mãnh. Hơn nữa, kích thước
document MongoDB phải nhỏ hơn kích thước lớn nhất của BSON document (16MB) [8].


b. Mô hình chuẩn hóa dữ liệu (Normalized Data Models)
Mô hình chuẩn hóa dữ liệu mô tả các mối quan hệ dùng tham khảo (reference)
giữa các document.
Tổng quát, dùng mô hình chuẩn hóa khi:
-

Việc nhúng dữ liệu làm tăng dữ liệu trùng lặp nhưng không tăng hiệu suất thao tác đọc.
Biểu diễn các mối quan hệ many-to-many phức tạp.
Cho các tập dữ liệu theo mô hình phân cấp.
Mô hình dùng tham khảo linh động hơn nhúng dữ liệu. Nhưng ứng dụng clientside cần nhiều truy vấn hơn cho tham khảo. Nói cách khác, mô hình chuẩn hóa làm tăng
số kết nối với server.

2.4.2 Operational Factors và mô hình dữ liệu
Mô hình hóa dữ liệu cho MongoDB phụ thuộc vào đặc tính của dữ liệu và đặc
tính của MongoDB. Những mô hình dữ liệu khác nhau có thể cho phép ứng dụng sử
dụng các lệnh truy vấn hiệu quả hơn, hoặc tăng băng thông cho thao tác insert và truy
vấn, hoặc hỗ trợ tốt hơn việc phân tán đến môt sharded cluster.

a. Document Growth
Thao tác update có thể làm tăng kích thước document nếu thêm phần tử vào
mảng hoặc thêm field mới vào document. Nếu kích thước document vượt mức cho
phép, MongoDB phân bổ lại document trên bộ nhớ. Điều này dẫn đến phân mãnh dữ
liệu, làm tăng thời gian tác vụ đọc, cần phải tránh. Do đó, nếu ứng dụng thường xuyên
yêu cầu lệnh update, nên sử dụng mô hình chuẩn hóa (dùng tham khảo) để tránh sự gia
tăng document hơn là dùng mô hình không chuẩn hóa (nhúng).
b. Atomicity
Đã trình bày ở trên. Mô hình kiểu nhúng các dữ liệu liên quan vào một
document là một dạng atomic. Nếu dùng mô hình chuẩn hóa để lưu trữ các reference
giữa các dữ liệu liên quan, ứng dụng phải dùng thao tác đọc và ghi riêng biệt khi thay
đổi các dữ liệu liên quan.
c. Sharding
MongoDB dùng sharding để phát triển theo chiều ngang. Những cluster hỗ trợ
triển khai với những tập dữ liệu lớn và các thao tác yêu cầu băng thông cao. Sharding
cho phép người dùng phân tán một collection trong database trên nhiều mongod, gọi là
shards. MongoDB dùng shard key để phân tán dữ liệu và lưu lượng ứng dụng. Lựa chọn
đúng shard key có ý nghĩa quan trọng cho hiệu năng, cho phép ngăn chặn truy vấn cô
lập và gia tăng khả năng ghi. Cần xem xét cẩn thận field hoặc những field nào để làm
shard key.


d. Indexes
Sử dụng index để tăng hiệu năng cho các truy vấn thông thường. Xây dụng
index cho những field xuất hiện thường xuyên trong truy vấn và các thao tác trả về kết
quả đã được sắp xếp.
MongoDB tự động tạo index cho field _id.
Khi tạo index, cần lưu ý:
- Mỗi index yêu cầu 8KB bộ nhớ.
- Việc thêm index làm giảm hiệu năng thao tác ghi. Đối với các collection

yêu cầu đọc/ghi nhiều, mỗi khi tăng thêm index yêu cầu cập nhật lại index.
- Các collection có mức đọc/ghi cao có thể có lợi ích từ việc thêm index.
Index không ảnh hưởng đến các thao tác up-index.
- Sử dụng index tiêu tốn bộ nhớ. Việc này cần được theo dõi.
e. Large Number of Collections
Trong một số trường hợp, lưu các dữ liệu quan hệ trên nhiều collection hợp lý
có thể tăng hiệu năng so với dùng một collection.
f. Data Lifecycle Management
Việc quyết định mô hình dữ liệu cần xem xét quản lý vòng đời dữ liệu.
Nếu ứng dụng yêu cầu dữ liệu chỉ tồn tại trong một thời gian hạn chế, cần sử
dụng thêm tính năng Time to Live (TTL).

2.4.3 GridFS
MongoDB dùng GridFS làm phương pháp để lưu trữ và truy xuất các tập tin
vượt quá giới hạn 16MB của document BSON.
Thay vì lưu trữ file trong một document, GridFS chia file thành nhiều phần, gọi
là chunk và lưu trữ các chunk này trong các document riêng biệt. Mặc định, kích thước
lớn nhất của chunk này là 255k. GridFS dùng hai collection để lưu file, một để lưu
chunk và một để lưu metadata của file.
Khi cần truy vấn file được lưu trữ bằng GridFS thì client sẽ lắp ráp lại
(reassemble) các chunk này.
GridFS cho phép truy cập thông tin từ các phần tùy ý của file, cho phép bỏ qua
(skip) để vào giữa một video hoặc tập tin âm thanh. GridFS không chỉ hữu ích để lưu
trữ các file kích thước vượt quá 16MB mà còn lưu trữ bất kỳ file nào mà việc truy cập
file không cần phải tải toàn bộ file vào bộ nhớ.


2.5 N
OD
E JS

Node.js được phát triển từ năm 2009 bởi Ryan Dahl, lúc đầu chỉ chạy trên
Linux. Sau một thời gian phát triển, Node.js trở thành một ứng dụng mã nguồn mở, là
môi trường thực thi nền tảng để phát triển ứng dụng web server-side. Node.js được viết
bằng Javascript và có thể chạy trên nhiều nền tảng như OS X, Microsoft Windows,
Linux, FreeBSD, NonStop, IBM AIX, IBM System z và IBM i [10].
Node.js cung cấp kiến trúc sử dụng event-driven và API non-blocking I/O được
thiết kế để tối ưu quá thông lượng (throughout) và khả năng mở rộng cho ứng dụng web
thời gian thực (real-time web application) [10]. Node.js sử dụng Google V8 JavaScript
engine để thực thi code và một phần lớn module được viết bằng JavaScript. Nó chứa
một built-in library cho phép ứng dụng đóng vai trò như một web server đứng một mình
(stand-alone web server: không cần Apache hay IIS). Điều đó làm Node.js tương tự như
PHP như khác biệt ở chổ PHP là ngôn ngữ blocking, khi thực thi một lệnh yêu cầu lệnh
trước đó phải hoàn thành, trong khi Node.js là ngôn ngữ non-blocking, việc xử lý lệnh
được thực hiện parallel, và dùng callbacks để trả tín hiệu hoàn thành [10].
Do vậy, Node.js có thời gian đáp ứng nhanh hơn các server truyền thống, server
tiếp tục thực hiện các hành động bên dưới mà không cần phải chờ tới khi có kết quả trả
về. Node.js thích hợp cho những ứng dụng xử lý lượng kết nối lớn, theo thống kê của
caustik's blog [11], Node.js có khả năng xử lý một triệu kết nối. Rất phù hợp các ứng
dụng thời gian thực giữa client-server, yêu cầu khả năng đáp ứng lượng kết nối lớn, và
dễ mở rộng phân tán theo chiều ngang [10].
Ngày nay, Node.js được sử dụng rộng rãi bởi những tập đoàn lớn như IBM,
Microsoft, Yahoo!, Walmart, Groupon, SAP, LinkedIn, Rakuten, PayPal, Voxer và
GoDaddy [11].


Chương 3: CÁC MÔ HÌNH ĐIỀU KHIỂN TRUY CẬP
3.1 M
Ô
HÌN
H

TRU
YỀN
TH
ỐN
G
Discretionary Access Controls (DAC) – truy cập tùy quyền là cơ chế điều khiển
truy cập đươc ra đời vào những năm 1960, được nghiên cứu và ứng dụng rộng rãi. Đặc
điểm chính của DAC là chủ của dữ liệu có toàn quyền trên dữ liệu đó, có quyền định
nghĩa các loại tri cập đọc/ghi/thực thi ... và gán hoặc thu hồi quyền của những người
dùng khác. Khuyết điểm của DAC là cho phép thông tin từ đối tượng này được truyền
sang đối tượng khác bằng cách đọc thông tin lên từ một đối tượng rồi ghi thông tin
xuống đối tượng khác. Đây là điểm yếu bị khai thác bằng Trojan Horse.
Mandatory Access Controls (MAC) ra đời vào những năm 1970 nhằm khắc
phục điểm yếu của DAC bằng cách phân lớp dữ liệu và người dùng theo các lớp bảo
mật. MAC phân loại người dùng theo mức độ tin cậy và lĩnh vực hoạt động người dùng,
phân loại dữ liệu dựa vào mức độ nhạy cảm và lĩnh vực của dữ liệu, do người quản trị
trung tâm quyết định. Người dùng ở cấp càng cao thì mức độ tin cậy càng lớn, dữ liệu ở
cấp càng cao thì càng nhạy cảm. MAC hoạt động với tính chất không đọc lên – không
ghi xuống (No read-up, No write-down) để đảm bảo không có dòng thông tin nào có thể
đi từ lớp cao xuống lớp thấp.
Ưu điểm của MAC là có tính bảo mật ngăn chặn dòng thông tin bất hợp pháp
và thích hợp cho môi trường quân đội. Khuyết điểm của MAC là không dễ áp dụng, đòi
hỏi người dùng và dữ liệu phải được phân loại rõ ràng, người quản trị trung tâm kiểm
soát hệ thống trao quyền và MAC chỉ được ứng dụng trong một số ít môi trường, không
phù hợp với các ứng dụng ngày nay đòi hỏi cơ chế phân quyền linh hoạt hơn.


3.2 M
Ô
HÌN

H
ĐIỀ
U
KHI
ỂN
TRU
Y
CẬP
DỰ
A
TRÊ
N
VAI
TR
Ò
(RO
LEBAS
ED
AC
CES
S
CO
NTR
OL
MO
DEL
–
RBA
C)

Mô hình điều khiển truy cập dựa trên vai trò (Role-Based Access Control
Model – RBAC) ra đời vào những năm 1990 nhằm thay thế cho các phương pháp
truyền thống DAC và MAC [12].
Ý tưởng trọng tâm của RBAC là quyền (permission) được kết hợp với vai trò
(role), và người dùng (user) được phân chia theo các role thích hợp. Role là tập bao
gồm các permission và các role khác. Session là một phần quan trọng của RBAC, phân
biệt nó với các group truyền thống. Session cho phép kích hoạt một tập con của role
được gán cho user. Nếu không có session thì role của user luôn được kích hoạt có thể
dẫn đến vị phạm đặc quyền tối thiểu.
RBAC làm đơn giản việc quản lý các permission. RBAC tạo các role cho các
chức năng công việc khác nhau trong một tổ chức và các user được phân role dựa theo
vai trò và quyền hạn của họ. Những role này được cấp thêm hoặc hủy bỏ permission khi
cần thiết. Người dùng không được cấp quyền trực tiếp mà thông qua các vai trò. Việc
quản lý vai trò trở nên đơn giản hơn.
Tuy nhiên, việc phát triển RBAC không có chuẩn thống nhất làm RBAC được
thực hiện bằng nhiều cách. Mô hình NIST giải quyết vấn đề này [12]. Mô hình NIST
được tổ chức thành bốn cấp theo thứ tự tăng dần khả năng hoạt động:
1.
2.
3.
4.

RBAC phẳng (Flat RBAC)
RBAC phân cấp (Hierarchical RBAC)
RBAC ràng buộc (Constrained RBAC)
RBAC đối xứng (Symmetric RBAC)

Hình 3: Bảng các loại RBAC [18].

3.2.1 RBAC phẳng (Flat RBAC) [12]

Hình 7 : Flat RBAC
Khái niệm cơ bản của RBAC : người dùng được gán role, permission được gán
role. User sử dụng permission bằng cách trở thành thành viên của role được gán
permission.
User có thể thực hiện nhiều quyền hoặc nhiều vai trò.

3.2.2 RBAC phân cấp (Hierarchical RBAC) [12]

Hình 8 : RBAC phân cấp
Hệ thống RBAC phân cấp xác định mối quan hệ giữa các role. Các role cấp cao
hơn bao gồm các role cấp dưới nó. Hai loại phân cấp role:
•

General Hierarchical RBAC (RBAC phân cấp tổng quát) : hỗ trợ cây phân cấp thứ tự
tùy ý.


•

Limited Hierarchical RBAC (RBAC phân cấp hạn chế) : có thêm các hạn chế hệ thống
phân cấp role như giới hạn cấu trúc đơn giản như cây hoặc cây đảo ngược.

3.2.3 RBAC ràng buộc (Constrained RBAC) [12]

Hình 9 : RBAC ràng buộc tĩnh
RBAC ràng buộc tĩnh: có thêm điều kiện ở giai đoạn gán user-role, nhằm tránh
hiện tượng chồng chéo, mâu thuẫn hoặc xung đột giữa các role được cấp cho cùng một

người dùng. Các ràng buộc được kế thừa trong phân cấp role nên cần tránh hiện tượng
role cha và con có mâu thuẫn.

Hình 10 : RBAC ràng buộc động
RBAC ràng buộc động dựa trong quá trình gán role-session, nhằm hạn chế
permission được gán cho user trong ngữ cảnh nhất định, hỗ trợ nguyên tắc đặc quyền
tối thiểu trong đó user có mức độ cho phép khác nhau vào những ngữ cảnh khác nhau,
tùy thuộc vào role.


3.2.4 RBAC đối xứng (Symmetric RBAC) [12],[13]

Hình 11 : RBAC đối xứng - ràng buộc tĩnh

Hình 12 : RBAC đối xứng - ràng buộc động

Mô hình này có thêm một yêu cầu xem xét quyền – vai trò tương tự
người dùng – vai trò ở Flat RBAC. Vậy nên, vai trò mà quyền được gán có thể được
xác định cũng như quyền được gán tới một vai trò xác định.
Nhận xét
Các mô hình RBAC đã khắc phục được những điểm yếu của các mô hình DAC
và MAC. Có các ưu điểm:
Phù hợp các ứng dụng trong thực tế.
Mô hình đơn giản, hiệu quả
Đơn giản việc quản lý permission, thay vì quản lý trên từng user thì quản lý trên mỗi
nhóm. Giúp giảm công sức, thời gian cũng như rủi ro nhầm lẫn.
• RBAC hỗ trợ sự phân cấp vai trò, quyền hạn của role cha được kế thừa bởi con. Giúp
ngăn chặn sự bùng nổ role và tăng khả năng sử dụng lại.
•
•

•


Bên cạnh đó, RBAC vẫn còn các nhược điểm cần khắc phục:
Không phù hợp các tài nguyên cần bảo vệ, nhưng chưa biết trước.
Không phù hợp khi quy tắc điều khiển là phức tạp, việc điều khiển truy cập không chỉ
phụ thuộc vai trò mà còn phụ thuộc các thông tin ngữ cảnh.
• Nếu các role là phức tạp và người dùng chưa biết trước thì RBAC không đáp ứng được
hoặc khó cài đặt.
•
•

3.3 C
ÁC
MÔ
HÌN
H
ĐIỀ
U
KHI
ỂN
TRU
Y
CẬP
TIÊ
N
TIẾ
N
3.3.1 Mô hình Attribute-Based Access Control (ABAC) [15]
Một mô hình khác có thể khắc phục các nhược điểm của RBAC truyền thống là

ABAC (điều khiển truy cập dựa trên thuộc tính) do Xin Jin, Ram Krishnan và Ravi
Sandhu đề xuất.
ABAC là một phương pháp kiểm soát truy cập mà các subject yêu cầu để thực
hiện các operation trên các object, yêu cầu này được cấp quyền hoặc từ chối dựa trên
các thuộc tính của subject, các thuộc tính của object, điều kiện môi trường, và một tập
các chính sách [19].
Các thành phần chính của mô hình ABAC: users (S), subjects (S), objects (O),
user attributes (UA), subject attributes (SA), object attributes (OA), permissions (P),
authorization policy.


Hình 13: Mô hình ABAC [15].
Mô hình này nhằm kết hợp ưu điểm của DAC, MAC và RBAC. Điểm mới của
mô hình này là có thêm “Attribute” (thuộc tính). Thuộc tính được gắn với bất kỳ thực
thể nào trong hệ thống, từ user, subject, object, role, ... Điểm mạnh ở mô hình này là có
thêm thuộc tính ngữ cảnh (địa điểm, thời gian, ...) khắc phục được điểm yếu là không
hỗ trợ ngữ cảnh của RBAC truyền thống.

Bảng 4: So sánh các mô hình điều khiển truy cập truyền thống với mô hình
ABAC [15]

3.3.2 Mô hình Usage Control (UCON) [16]
Mô hình UCON do Jaehong Park và Ravi Sandhu đề xuất để giải quyết các
nhược điểm của RBAC truyền thống, đây là mô hình toàn diện nhất hiện nay.
Mô hình UCON cũng có thêm thuộc tính giống như mô hình ABAC. Gồm các
thành phần chính: Subject (S), Object (O), Right (R), Authorizations (A), Obligations
(B), Conditions (C) và Usage Decision.