HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

Báo cáo đề tài:

BẢO MẬT DỮ LIỆU TRONG
ĐIỆN TOÁN ĐÁM MÂY

Giảng viên hướng dẫn: TS. Đặng Minh Tuấn

Sinh viên thực hiện:
Nguyễn Đức Kiên B14DCAT202
Trịnh Đức Quang B14DCAT233
Nguyễn Đình Thái B14DCAT161

Hà Nội 2018

1
 MỤC LỤC
DANH MỤC CÁC CHỮ VIẾT TẮT...........................................................4
LỜI MỞ ĐẦU................................................................................................5
CHƯƠNG 1. TỔNG QUAN VỀ ĐIỆN TOÁN ĐÁM MÂY VÀ VẤN
ĐỀ BẢO MẬT DỮ LIỆU TRONG ĐIỆN TOÁN ĐÁM MÂY..................7
1.1. Khái niệm....................................................................................7
1.2. Mô hình kiến trúc điện toán đám mây.....................................7
1.2.1. Kiến trúc phân lớp dịch vụ...................................................................7
1.2.1.1. Dịch vụ ứng dụng (Software as a Service – SaaS).......................11
1.2.1.2. Dịch vụ nền tảng hệ thống (Platform as a Service – PaaS).........12
1.2.1.3. Dịch vụ cơ sở hạ tầng (Infrastructure as a Service – IaaS)........12
1.2.2.1. Đám mây riêng................................................................................14
1.2.2.2. Đám mây công cộng........................................................................14
1.2.2.3. Đám mây lai....................................................................................15
1.2.2.4. Đám mây cộng đồng.......................................................................16
1.3. Vấn đề bảo mật trong điện toán đám mây.............................16
1.3.1.1. An ninh ở mức hạ tầng...................................................................17
1.3.1.2. An ninh ở mức dịch vụ nền tảng...................................................18
1.3.1.3. An ninh ở mức dịch vụ phần mềm................................................19

CHƯƠNG 2. MÃ HÓA DỮ LIỆU TRONG BẢO MẬT ĐIỆN

TOÁN ĐÁM MÂY.......................................................................................21
2.1 CryptDB và Mô hình xử lý dữ liệu đã mã hóa...........................21
2.1.1 Giới thiệu về CryptDB.........................................................................21
2.2 Truy vấn trên dữ liệu mã hóa.......................................................23
2.2.1 Mã hóa trong CryptDB.......................................................................24
2.2.2 Mã hóa lớp............................................................................................26
2.2.3 Hàm người dùng định nghĩa - UDF: User-Defined Function..........29
2.2.4 Điều chỉnh mã hóa dựa theo truy vấn................................................30
2.2.5 Cấu trúc dữ liệu trong CryptDB........................................................33
2.2.6 Thực thi truy vấn trên dữ liệu mã hóa..............................................34
2.2.7 Tính toán liên kết giữa các cột............................................................43

2
 CHƯƠNG 3: PHÂN LOẠI DỮ LIỆU VÀ CHIẾN LƯỢC BẢO
MẬT..............................................................................................................46
3.1 Giới thiệu..........................................................................................46
3.2 Phân loại dữ liệu............................................................................47
3.2.2 Access Control......................................................................................47
3.2.3 Content..................................................................................................47
3.3.3 Storage..................................................................................................48

TÀI LIỆU THAM KHẢO.............................................................................49

3
 DANH MỤC CÁC CHỮ VIẾT TẮT

Ký hiệu Thuật ngữ Ý nghĩa

IT Information Technology Công nghệ thông tin
NIST National Institute of Standards and Viện Tiêu chuẩn và Công
Technology nghệ Quốc gia Hoa Kỳ
MIT Massachusetts Institute of Viện Công nghệ
Technology Massachusetts
SLA Service Level Agreement Hợp đồng thỏa thuận dịch vụ
QoS Quality of Service Chất lượng dịch vụ
IaaS Infrastructure-as-a-Service Cơ sở hạ tầng như một dịch vụ
PaaS Platform-as-a-Service Nền tảng như một dịch vụ
SaaS Software-as-a-Service Phần mềm như một dịch vụ
DBaaS Database-as-a-Service Cơ sở dữ liệu như một dịch vụ
VM Virtual Machine Máy ảo
CRM Customer Relationship Quản lý quan hệ khách hàng
Management
ERP Enterprise Resource Planning hoạch định nguồn lực doanh
nghiệp
SQL Structured Query Language Ngôn ngữ truy vấn cấu trúc
DBMS Database Management System Hệ quản trị cơ sở dữ liệu
UDF User-Defined Function Hàm người dùng định nghĩa
DBA Database Administrator Quản trị viên cơ sở dữ liệu
MK Master Key Khóa chính
PRP Pseudo-Random Permutation Hoán vị giả ngẫu nhiên
PRF Pseudo-Random Function Hàm giả ngẫu nhiên

4
 DANH MỤC CÁC HÌNH VẼ

Hình 1. 1 Điện toán đám mây...................................................................................7

Hình 1. 2 Mô hình kiến trúc dịch vụ điện toán đám mây của SOMF.......................8
Hình 1. 3 Mô hình SPI..............................................................................................9
Hình 1. 4 Mô hình SPI với các ứng dụng trong thực tế............................................9
Hình 1. 5 Mức độ kiểm soát/trách nhiệm giữa khách hàng và nhà cung cấp dịch vụ
.................................................................................................................................11
Hình 1. 6 SaaS cung cấp dịch vụ cho khách hàng..................................................12
Hình 1. 7 PaaS cho phép khách hàng truy cập vào một nền...................................12
Hình 1. 8 IaaS cho phép nhà cung cấp dịch vụ thuê những tài nguyên phần cứng 13
Hình 1. 9 Phạm vi kiểm soát giữa nhà cung cấp/sử dụng dịch vụ IaaS..................13
Hình 1. 10 Mô hình triển khai điện toán đám mây.................................................13
Hình 1. 11 Các thành phần trong đám mây riêng...................................................14
Hình 1. 12 Đám mây công cộng............................................................................15
Hình 1. 13 Mô hình đám mây lai............................................................................16
Hình 1. 14 Kiến trúc phân tầng dịch vụ trong điện toán đám mây.........................17

Hình 2. 1 Kiến trúc của CryptDB...........................................................................22

Hình 2. 2 EQ Onion................................................................................................28
Hình 2. 3 ORD Onion............................................................................................29
Hình 2. 4 SEARCH và ADD Onion........................................................................30
Hình 2. 5 Bảng Square............................................................................................31
Hình 2. 6 Kết quả....................................................................................................31
Hình 2. 7 Các lớp mã hóa Onion và các lớp tính toán được phép..........................32
Hình 2. 8 Bảng dữ liệu gốc.....................................................................................34
Hình 2. 9 Bảng được tạo ra bởi Proxy Server.........................................................34
Hình 2. 10 Bảng Students sau khi được tạo............................................................36
Hình 2. 11 Bảng mã hóa được tạo trên Proxy Server..............................................37
Hình 2. 12 Kết quả của truy vấn.............................................................................37
Hình 2. 13 Kết quả được trả về từ phía Proxy Server y..........................................38
Hình 2. 14 Lược đồ cơ sở dữ liệu ví dụ..................................................................38
Hình 2. 15 Lược đồ cơ sở dữ liệu ví dụ..................................................................38
Hình 2. 16 Các lớp mã hóa của các cột...................................................................38
Hình 2. 17 Các lớp mã hóa của các cột...................................................................38

5
Hình 2. 18 Lược đồ cơ sở dữ liệu sau bước 1.........................................................39
Hình 2. 19 Lược đồ cơ sở dữ liệu sau bước 1.........................................................39
Hình 2. 20 Lớp mã hóa của các cột sau bước 1......................................................39
Hình 2. 21 Lớp mã hóa của các cột sau bước 1......................................................39
Hình 2. 22 Lược đồ cơ sở dữ liệu sau bước 2.........................................................40
Hình 2. 23 Lược đồ cơ sở dữ liệu sau bước 2.........................................................40
Hình 2. 24 Bảng được cập nhật với các giá trị Grade được thêm...........................42
Hình 2. 25 Bảng được cập nhật với các giá trị Grade được thêm...........................42
Hình 2. 26 Bảng được cập nhật được mã hóa bên Proxy Server............................42
Hình 2. 27 Bảng được cập nhật được mã hóa bên Proxy Server............................42

Hình 3. 1 Access Control........................................................................................48

LỜI MỞ ĐẦU

Ngày nay, cùng với sự phát triển của công nghệ thông tin, hệ thống phần
mềm ứng dụng, hệ thống máy chủ của các tổ chức doanh nghiệp ngày càng
tăng nhanh. Điều đó dẫn tới chi phí đầu tư cho hạ tầng công nghệ thông tin
ngày càng lớn, chi phí cho việc quản lý hệ thống cũng tăng lên. Để giảm thiểu
được các chi phí đó và tăng khả năng ứng dụng công nghệ thông tin trong sản
xuất kinh doanh của doanh nghiệp, điện toán đám mây là giải pháp đang được
rất nhiều doanh nghiệp lựa chọn. Bên cạnh những lợi ích to lớn mà điện toán
đám mây đem lại, nó cũng tồn tại một số hạn chế nhất định, nhất là trong vấn
đề bảo mật dữ liệu của người sử dụng. Trong thời đại ngày nay, nhiều thông
tin, dữ liệu nhạy cảm có giá trị rất to lớn, đôi khi nắm vai trò sống còn của
một doanh nghiệp, vấn đề đảm bảo bí mật cho những thông tin, dữ liệu như
vậy khi lưu trữ trên đám mây của nhà cung cấp dịch vụ lại càng trở nên quan
trọng hơn bao giờ hết.

Đề tài “Bảo mật dữ liệu trong điện toán đám mây” nhằm mục đích
nghiên cứu, tìm hiểu, xây dựng, và đưa ra phương pháp mới giải quyết bài
toán bảo đảm bí mật cho những dữ liệu, thông tin nhạy cảm được lưu trữ trên
điện toán đám mây.

Nội dung trình bày gồm có 3 phần, trong đó:

6
 Chương 1. Tổng quan về điện toán đám mây và vấn đề bảo mật dữ
liệu trong điện toán đám mây. Kết thúc chương này ta sẽ có cái nhìn tổng
quan nhất về điện toán đám mây, biết được những lợi ích to lớn mà điện toán
đám mây đem lại so với điện toán truyền thống cũng như một số vấn đề về
bảo mật dữ liệu chúng ta sẽ gặp phải khi sử dụng các dịch vụ điện toán đám
mây.
Chương 2. Mã hóa dữ liệu trong bảo mật điện toán đám mây. Chương
này sẽ trình bày về Database-as-a-Service – DBaaS hay còn gọi là cơ sở dữ
liệu như một dịch vụ.

Chương 3. Phân loại dữ liệu và các chiến lược bảo mật. Chương này sẽ
trình bày về một số loại dữ loại kèm them đó là các chiến lược bảo mật.

7
 CHƯƠNG 1. TỔNG QUAN VỀ ĐIỆN TOÁN ĐÁM MÂY VÀ
VẤN ĐỀ BẢO MẬT DỮ LIỆU TRONG ĐIỆN TOÁN ĐÁM
MÂY.
Khái niệm.
Theo Wikipedia: “Điện toán đám mây (cloud computing) là một mô hình điện
toán có khả năng co giãn (scalable) linh động và các tài nguyên thường được ảo
hóa được cung cấp như một dịch vụ trên mạng Internet”. Điện toán đám mây,
còn gọi là điện toán máy chủ ảo, là mô hình điện toán (hình 1.1) sử dụng các
công nghệ máy tính và phát triển dựa vào mạng Internet.
Theo Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ (NIST): “Điện
toán đám mây là một mô hình cho phép truy cập mạng thuận tiện, theo nhu
cầu đến một kho tài nguyên điện toán dùng chung, có thể định cấu hình:
mạng, máy chủ, lưu trữ, ứng dụng,…có thể được cung cấp và thu hồi một
cách nhanh chóng với yêu cầu tối thiểu về quản lý hoặc can thiệp của nhà
cung cấp dịch vụ.”

Hình 1. 1 Điện toán đám mây

Mô hình kiến trúc điện toán đám mây

1.1.1. Kiến trúc phân lớp dịch vụ

Hiện nay có một số mô hình kiến trúc phân lớp dịch vụ cho điện toán đâm
mây, ví dụ như mô hình kiến trúc dịch vụ của SOMF như hình 1.1. Tùy theo
nhà cung cấp dịch vụ điện toán đám mây, họ sẽ cung cấp các loại dịch vụ điện
toán đám mây khác nhau

8
 Hình 1. 2 Mô hình kiến trúc dịch vụ điện toán đám
mây của SOMF

Tuy nhiên các mô hình kiến trúc dịch vụ điện toán đám mây đều có ba loại
dịch vụ điện toán đám mây cơ bản là: dịch vụ cơ sở hạ tầng (Infrastructure as
a Service – IaaS), dịch vụ nền tảng (Platform as a Service – PaaS) và dịch vụ
phần mềm (Software as a Service – SaaS). Cách phân loại này thường được
gọi là mô hình SPI.
Hình 1.3 dưới đây sẽ mô tả mô hình dịch vụ SPI (Software – Platform –
Infrastructure).

9
 Hình 1. 3 Mô hình SPI
Trong hình 1.4 dưới đây sẽ cho chúng ta thấy mô hình SPI của điện toán
đám mây gắn liền với một số ứng dụng, dịch vụ cụ thể trong thực tế.

Hình 1. 4 Mô hình SPI với các ứng dụng trong thực tế

10
 Mô hình dịch vụ xác định tùy chọn điều khiển khác nhau cho các khách
hàng và cung cấp dịch vụ điện toán đám mây. Ví dụ, khách hàng SaaS chỉ
cần sử dụng các ứng dụng và dịch vụ được cung cấp bởi các CSP, nơi IaaS
khách hàng duy trì kiểm soát môi trường của mình được lưu trữ trên cơ sở
hạ tầng cơ bản của CSP. Ba mô hình dịch vụ thường được sử dụng nhất
được mô tả như sau.

SaaS: Khả năng cho khách hàng sử dụng các ứng dụng của nhà cung cấp
đang chạy trên một cơ sở hạ tầng điện toán đám mây. Các ứng dụng có thể
truy cập từ các thiết bị khách hàng khác nhau hoặc thông qua một giao diện
chẳng hạn như một trình duyệt web, hoặc một giao diện chương trình.

PaaS: Khả năng cho khách hàng triển khai các ứng dụng của họ (được tạo
ra hoặc mua lại) vào cơ sở hạ tầng điện toán đám mây, sử dụng ngôn ngữ lập
trình, thư viện, dịch vụ, và các công cụ hỗ trợ của nhà cung cấp.
IaaS: Khả năng cho khách hàng sử dụng xử lý của nhà cung cấp, lưu trữ,
mạng, và tài nguyên máy tính cơ bản khác để triển khai và chạy hệ điều hành,
các ứng dụng và phần mềm khác trên một cơ sở hạ tầng điện toán đám mây.

Sự khác biệt chính giữa các cấp dịch vụ liên quan đến cách điều khiển
được chia sẻ giữa các khách hàng và CSP, do đó ảnh hưởng đến mức độ trách
nhiệm cho cả hai bên. Cần lưu ý rằng, khác hơn trong một đám mây thực sự
tin (on-premise) kịch bản, khách hàng hiếm khi có bất kỳ kiểm soát phần
cứng, và nó là mức độ mà các thành phần ảo, các ứng dụng và phần mềm
được quản lý bởi các bên khác nhau để phân biệt các mô hình dịch vụ. Theo
nguyên tắc chung, SaaS cung cấp cho khách hàng với số tiền ít nhất kiểm
soát, trong khi IaaS cung cấp sự kiểm soát nhất cho khách hàng.

Điều quan trọng cần lưu ý là những mô tả triển khai và mô hình dịch vụ,
mặc dù được chấp nhận rộng rãi bởi các ngành công nghiệp, có thể không
hoàn toàn được theo sau bởi các nhà cung cấp điện toán đám mây hoặc phản
ánh môi trường điện toán đám mây thực tế. Ví dụ, một CSP có thể được bán
một "đám mây riêng" dịch vụ không đáp ứng được mục đích của "tư nhân"
như được mô tả ở trên. Tương tự như vậy, các chi tiết về những gì được và
những gì không được bao gồm trong một dịch vụ cụ thể có thể sẽ khác nhau

11
 giữa các CSP, ngay cả khi họ từng xác định dịch vụ của họ bằng cách cùng kỳ
hạn (IaaS, PaaS hay SaaS).

Mức độ trách nhiệm an ninh trên các mô hình dịch vụ điện toán đám mây
nói chung và di cư đối với khách hàng là khách hàng di chuyển từ một mô
hình SaaS (trách nhiệm của khách hàng ít nhất) đến một mô hình IaaS (hầu
hết trách nhiệm của khách hàng). Mức độ lớn nhất của trách nhiệm cho các
CSP để duy trì kiểm soát an ninh và hoạt động hiện diện trong mô hình dịch
vụ SaaS.

Hình 1. 5 Mức độ kiểm soát/trách nhiệm giữa khách hàng và nhà cung cấp dịch vụ

Trong khi khách hàng có thể được thu hút vào các mô hình SaaS và PaaS
do tiết kiệm tài nguyên và giảm trách nhiệm về quản lý môi trường điện toán
đám mây, họ nên biết rằng các mô hình này cũng tương ứng với một mất mát
lớn hơn của kiểm soát các dữ liệu nhạy cảm của họ. Thỏa thuận hợp đồng và
thẩm định liên tục trở nên đặc biệt quan trọng, nơi kiểm soát là bên ngoài, để
đảm bảo rằng các biện pháp an ninh cần được đáp ứng và duy trì bởi CSP
trong thời gian thỏa thuận.

1.1.1.1. Dịch vụ ứng dụng (Software as a Service – SaaS)

Đây là mô hình dịch vụ mà trong đó nhà cung cấp dịch vụ sẽ cung cấp cho
khách hàng một phần mềm dạng dịch vụ hoàn chỉnh. Khách hàng chỉ cần
lựa chọn ứng dụng phần mềm nào phù hợp với nhu cầu và chạy ứng dụng
đó trên cơ sở hạ tầng Cloud. Mô hình này giải phóng người dùng khỏi việc
quản lý hệ thống, cơ sở hạ tầng, hệ điều hành… tất cả sẽ do nhà cung cấp

12
 dịch vụ quản lý và kiểm soát để đảm bảo ứng dụng luôn sẵn sàng và hoạt
động ổn định.

Hình 1. 6 SaaS cung cấp dịch vụ cho khách hàng

1.1.1.2. Dịch vụ nền tảng hệ thống (Platform as a Service – PaaS)
Nhà cung cấp dịch vụ sẽ cung cấp một nền tảng (platform) cho khách hàng.
Khách hàng sẽ tự phát triển ứng dụng của mình nhờ các công cụ và môi
trường phát triển được cung cấp hoặc cài đặt các ứng dụng sẵn có trên nền
platform đó. Khách hàng không cần phải quản lý hoặc kiểm soát các cơ sở
hạ tầng bên dưới bao gồm cả mạng, máy chủ, hệ điều hành, lưu trữ, các
công cụ, môi trường phát triển ứng dụng nhưng quản lý các ứng dụng mình
cài đặt hoặc phát triển.

Hình 1. 7 PaaS cho phép khách hàng truy cập vào một nền
tảng trên điện toán đám mây

1.1.1.3. Dịch vụ cơ sở hạ tầng (Infrastructure as a Service – IaaS)

Trong loại dịch vụ này, khách hàng được cung cấp những tài nguyên máy
tính cơ bản (như bộ xử lý, dung lượng lưu trữ, các kết nối mạng…). Khách
hàng sẽ cài hệ điều hành, triển khai ứng dụng và có thể nối các thành phần
như tường lửa và bộ cân bằng tải. Nhà cung cấp dịch vụ sẽ quản lý cơ sở hạ
tầng cơ bản bên dưới, khách hàng sẽ phải quản lý hệ điều hành, lưu trữ, các
ứng dụng triển khai trên hệ thống, các kết nối giữa các thành phần.

13
 Hình 1. 8 IaaS cho phép nhà cung cấp dịch vụ thuê những tài nguyên
phần cứng

Các dịch vụ cơ sở hạ tầng tập trung vào vấn đề trang bị cho các trung tâm
dữ liệu bằng cách đảm bảo công suất điện toán khi cần thiết. Trên thực tế các
kỹ thuật ảo hóa thường được sử dụng trong tầng này, nên có thể thấy rõ sự tiết
kiệm chi phí khi sử dụng tài nguyên hệ thống.

Hình 1. 9 Phạm vi kiểm soát giữa nhà cung cấp/sử dụng dịch vụ IaaS
1.2.2. Mô hình triển khai
Điện toán đám mây phân thành ba mô hình triển khai: điện toán đám mây
riêng, đám mây công cộng và đám mây lai. Sau đây chúng ta sẽ đi tìm hiểu
lần lượt từng mô hình triển khai.

14

Hình 1. 10 Mô hình triển khai điện toán đám mây

1.2.2.1. Đám mây riêng
Các đám mây riêng là các dịch vụ đám mây được cung cấp trong doanh
nghiệp. Những đám mây này tồn tại bên trong tường lửa công ty và chúng
được doanh nghiệp quản lý.

Các đám mây riêng đưa ra nhiều lợi ích giống như các đám mây chung,
điểm khác biệt chính là doanh nghiệp chịu trách nhiệm thiết lập và bảo trì đám
mây. Việc thiết lập đám mây riêng đôi khi không còn chi phí cho việc sử dụng
và duy trì hoạt động liên tục của đám mây và có thể vượt quá chi phí khi sử
dụng một đám mây chung.

Hình 1. 11 Các thành phần trong đám mây riêng

1.2.2.2. Đám mây công cộng
Các đám mây công cộng là các dịch vụ đám mây được một bên thứ ba
(người bán) cung cấp. Chúng tồn tại ngoài tường lửa công ty và chúng được
lưu trữ đầy đủ và do nhà cung cấp đám mây quản lý.

Các đám mây công cộng cung cấp cho khách hàng các dịch vụ công
nghệ thông tin tốt nhất. Có thể là phần mềm, cơ sở hạ tầng ứng dụng hoặc cơ
sở hạ tầng vật lý. Các nhà cung cấp đám mây chịu trách nhiệm cài đặt, quản
lý, cung cấp và bảo trì. Khách hàng tính phí cho các tài nguyên nào mà họ sử
dụng.

15
 Các dịch vụ thường được cung cấp với các quy ước về cấu hình, chúng
được cung cấp với những trường hợp sử dụng phổ biến nhất. Khách hàng chỉ
có quyền truy cập vào tài nguyên được cấp phát.

Hình 1. 12 Đám mây công cộng

1.2.2.3. Đám mây lai

Đám mây lai là sự kết hợp của các đám mây công cộng và riêng. Những
đám mây này thường do doanh nghiệp tạo ra và chịu trách nhiệm quản
lý.
Nó được phân chia giữa doanh nghiệp và nhà cung cấp đám mây công
cộng. Đám mây lai sử dụng các dịch vụ có trong cả đám mây công cộng
và đám mây riêng.
Các đám mây lai hầu hết thường được sử dụng làm những việc sau:
- Là nơi các ứng dụng lưu trú trong đám mây và các ứng dụng
quan trọng vẫn còn trên trang web.
- Là nơi thí nghiệm, nơi đám mây được sử dụng với vùng làm việc
tạm thời.
- Khả năng bổ sung hay bùng nổ dịch vụ nơi đám mây được sử
dụng cho các đột biến bất ngờ.

16
 Hạn chế chính với đám mây lai là khó khăn trong việc tạo ra và quản lý
chúng. Giải pháp đặt ra là tiếp nhận và cung cấp các dịch vụ từ các
nguồn khác nhau như thể chúng có nguồn gốc từ một nơi và có thể
tương tác giữa các đám mây riêng và chung.

Hình 1. 13 Mô hình đám mây lai

1.2.2.4. Đám mây cộng đồng

Các đám mây cộng đồng là các đám mây được chia sẻ bởi một số tổ chức
và hỗ trợ một cộng đồng cụ thể có mối quan tâm chung như: chung mục đích,
yêu cầu an ninh, chính sách. Nó có thể được quản lý bởi các tổ chức hoặc một
bên thứ ba.

Một đám mây cộng đồng có thể được thiết lập bởi một số tổ chức có
yêu cầu tương tự và tìm cách chia sẻ cơ sở hạ tầng để thực hiện một số lợi ích
của điện toán đám mây.

Tùy chọn này là tốn kém hơn nhưng có thể đáp ứng về sự riêng tư, an
ninh hoặc tuân thủ các chính sách tốt hơn.

Vấn đề bảo mật trong điện toán đám mây

1.3.1. An toàn liên quan đến kiến trúc của điện toán đám mây

17
 Một đám mây là một cụm máy tính kết nối nhau thông qua mạng cục bộ
hoặc mạng diện rộng trên cơ sở ảo hóa tài nguyên phần cứng nhờ chức năng
ảo hóa để cung cấp một cách trong suốt ba dịch vụ cơ bản của điện toán đám
mây là SaaS, PaaS và IaaS. Mô hình triển khai đám mây có thể là công cộng,
đám mây riêng hoặc cộng đồng hay hỗn hợp như đã nói ở phần trên. Các dịch
vụ điện toán đám mây có kiến trúc phân tầng (layer), mỗi tầng cung cấp các
dịch vụ và tiện ích (chức năng) riêng của nó trên cơ sở các dịch vụ và tiện ích
của tầng thấp hơn. Vì vậy an ninh của hệ thống phụ thuộc vào an ninh của
mỗi tầng được thiết kế và cài đặt kèm theo như là 1 dịch vụ hay tiện ích.

Hình 1. 14 Kiến trúc phân tầng dịch vụ trong điện toán đám mây
1.3.1.1. An ninh ở mức hạ tầng
An ninh của các dịch vụ ở tầng thấp như tầng vật lý hay hạ tầng (IaaS)
phụ thuộc vào nhà cung cấp, tức là chủ sở hữu của đám mây. Hiện tại, có một
số nhà cung cấp dịch vụ IaaS nhưng chưa có chuẩn nào về an ninh cho các
dịch vụ này. Về mặt nguyên tắc, khách hàng thuê bao dịch vụ IaaS có thể áp
đặt các chính sách an ninh của mình bằng cách phát triển các dịch vụ hay tiện
ích riêng thông qua các dịch vụ của tầng vật lý và các dịch vụ IaaS của nhà
cung cấp. Chính sách về an toàn ở mức này là rất phức tạp vì nhiều chính sách
khác nhau áp đặt lên cùng một môi trường phần cứng (vật lý).

Những mối đe dọa an toàn ở mức này có thể liên quan tới máy chủ ảo
(Virtual Machine) như là vi-rút và các phần mềm độc hại khác. Nhà cung cấp
dịch vụ chịu trách nhiệm chính về giải pháp cho vấn đề này. Khách hàng thuê
bao cũng có thể thực hiện các giải pháp và chính sách an toàn riêng cho mình,
18
từ đó làm gia tăng gánh nặng lên phần cứng và hiệu năng chung của hệ thống.
Các máy chủ ảo vẫn có thể bị lây nhiễm hay bị kiểm soát bởi phần mềm độc
hại. Trong trường hợp này, các chính sách an ninh của khách hàng có thể bị
vô hiệu, như vậy nhà cung cấp dịch vụ phải là người có vai trò chính trong an
ninh ở mức này. Ngoài ra, vì IaaS khai thác hạ tầng vật lý và chính sách chung
như DNS Server, Switch, IP protocol,… Vì vậy, khả năng bị tấn công vào
“khách hàng yếu nhất” sau đó “lây lan” cho các khách hàng khác. Vấn đề này
hiện nay khách hàng thuê bao không thể can thiệp gì vì nhiều máy chủ ảo chia
sẻ cùng tài nguyên vật lý như CPU, bộ nhớ, đĩa,… Mọi ánh xạ vật lý- máy ảo,
máy ảo-vật lý đều thông qua một “bộ ảo hóa”, nếu bộ này bị phần mềm độc
hại kiểm soát thì toàn bộ khách hàng trong đám mây sẽ bị cùng một mối hiểm
họa như nhau.

1.3.1.2. An ninh ở mức dịch vụ nền tảng

Ở mức trung gian, dịch vụ nền tảng (PaaS) dựa trên dịch vụ tầng dưới
(IaaS) và cung cấp dịch vụ của mình cho tầng trên nó (SaaS). Ở mức này, các
dịch vụ hay tiện ích về an toàn có thể được cài đặt thêm hoặc cấu hình các
dịch vụ được cung cấp từ tầng dưới. Ở đây, người dùng có thể quản trị phần
thuê bao của mình để tạo ra môi trường thực thi các ứng dụng. Hiện nay, dịch
vụ PaaS của đám mây dựa trên mô hình kiến trúc hướng dịch vụ (SOA) vì vậy
những nguy cơ về an toàn giống hệt như những nguy cơ an toàn của SOA như
tấn công từ chối dịch vụ, tấn công XML và nhiều cách tấn công khác.

Vì dịch vụ nền tảng là dịch vụ đa thuê bao, nhiều người dùng nên cơ chế
xác thực, chứng thực là rất quan trọng. Trách nhiệm bảo mật và an toàn trong
trường hợp này liên quan đến cả nhà cung cấp, người thuê bao và người dùng
(user). Các dịch vụ PaaS phải cung cấp môi trường để phát triển ứng dụng bao
gồm chức năng tác nghiệp, các chức năng an toàn và quản lí hệ thống. Nhà
cung cấp cần có cơ chế bắt buộc chứng thực để truy cập các dịch vụ PaaS,
người thuê bao có trách nhiệm phát triển hay cung cấp các chức năng bảo mật
cần thiết thông qua cơ chế chứng thực chung và người dùng phải có trách
nhiệm bảo vệ tài khoản đăng nhập cá nhân của mình.

1.3.1.3. An ninh ở mức dịch vụ phần mềm

19
 Ở mức dịch vụ phần mềm (SaaS), các phần mềm được cung cấp như là
dịch vụ trên mạng, sử dụng các chính sách bảo mật dữ liệu và tài nguyên khác
từ các tầng bên dưới cung cấp. Một số dịch vụ phần mềm khá phổ biến hiện
nay là Google Search Engine, Google mail… Khách hàng của các dịch vụ này
không biết được dữ liệu của mình được quản lí và khai thác như thế nào và nó
nằm ở đâu trên thế giới này. Vấn đề an ninh ở đây liên quan đến bảo mật dữ
liệu, rò rỉ thông tin nhạy cảm và nguy cơ bị tấn công từ chối truy cập… Trách
nhiệm về an toàn được chia sẻ cho nhà cung cấp hạ tầng đám mây và nhà
cung cấp dịch vụ phần mềm. Người dùng đầu cuối (end user) chỉ là người
dùng phần mềm với các lựa chọn cấu hình khác nhau được cung cấp bởi phần
mềm nên không có nhiều vai trò trong an toàn hệ thống. Người dùng cuối chỉ
biết tin vào nhà cung cấp phần mềm và các cam kết của nhà cung cấp về trách
nhiệm bảo mật. Thông thường các cam kết này có thể là điều khoản trong hợp
đồng thuê bao phần mềm, như là: an toàn thông tin và chất lượng dịch vụ.
Chúng thường bao gồm: dung lượng dữ liệu, toàn vẹn dữ liệu, chính sách về
phân tán, sao lưu và phục hồi dữ liệu khi có sự cố, độ tin cậy, tính riêng tư và
an toàn mạng cùng với các cam kết khác về chất lượng dịch vụ như dung
lượng đường truyền, tính sẵn dùng.

Ở mức này, các phần mềm được cung cấp trên nền web (web-based
application). Các web này thường được đặt ở máy chủ ảo trên đám mây, cho
nên chúng phải được kiểm tra bằng cách quét các yếu điểm web nhờ vào một
ứng dụng quét nào đó. Các tường lửa có thể được dùng đển ngăn chặn các tấn
công vào điểm yếu đã biết của các phần mềm nền web. Những công việc này
thuộc về nhà cung cấp phần mềm hoặc đám mây, người dùng cuối nhiều lắm
là tham gia vào lựa chọn các cấu hình (option) khác nhau mà thôi. Tình hình
này có thể dẫn đến những lộn xộn trong cấu hình an toàn chung của hệ thống
do tính chất đa thuê bao, kéo theo những lỗ hổng trong an toàn hệ thống. Vì
vậy, các nhà cung cấp phải có những chính sách chung bắt buộc và cách kiểm
soát sao cho những cấu hình an toàn, bảo mật phải nhất quán, chặt chẽ và
không có lỗ hổng.

1.3.2. Vấn đề quản lí an toàn hệ thống

Phần trên vừa trình bày cho thấy tính phức tạp trong “kỹ thuật” an toàn
trên đám mây từ góc độ kiến trúc và dịch vụ của điện toán đám mây. Phần
20
này đề cập đến một số khía cạnh về quản lí, vốn không thể tách rời với kỹ
thuật nhằm đảm bảo cho sự áp dụng chính sách bảo mật đúng đắn, cộng tác
và có trách nhiệm giữa các bên có liên quan trong điện toán đám mây. Nghiên
cứu về quản lí an toàn trên đám mây là rất phức tạp vì nó liên quan đến số
lượng lớn người có liên quan với các yêu cầu (requirement) khác nhau về an
toàn. Việc quản lí an toàn liên quan tới việc xây dựng các yêu cầu về an toàn,
đặc tả chính sách an toàn, cơ chế kiểm soát và các cấu hình khác nhau về an
toàn tương ứng với các chính sách đặc thù. Việc quản lí này là động vì luôn
phải đáp ứng các yêu cầu mới, các phản hồi từ môi trường và từ chính quá
trình kiểm soát an toàn.

Điện toán đám mây cung cấp các dịch vụ trên cơ sở một hợp đồng trách
nhiệm (SLA – Service Level Agreement), đây là pháp lý quan trọng trong các
tranh chấp, bất đồng sau này. Hợp đồng thông thường bao gồm chất lượng
dịch vụ, tính sẵn dùng, độ tin cậy và an toàn. Và như bao cam kết hợp đồng,
nó có những điều khoản về trả phí dịch vụ xử phạt và bồi thường. Một đòi hỏi
cao về an toàn thường dẫn đến một tiêu tốn nhiều nguồn lực và vì vậy mức
giá dịch vụ sẽ cao lên tương ứng. Cần lưu ý rằng những đòi hỏi khắc khe về
an toàn có thể ảnh hưởng đến hiệu năng chung của hệ thống (cồng kềnh hơn,
chậm hơn,…). Vì vậy, cần có sự cân bằng giữa yêu cầu an toàn, chi phí và
hiệu năng của hệ thống.

21
CHƯƠNG 2. MÃ HÓA DỮ LIỆU TRONG BẢO MẬT ĐIỆN
TOÁN ĐÁM MÂY.
CryptDB và Mô hình xử lý dữ liệu đã mã hóa

2.1.1 Giới thiệu về CryptDB

CryptDB là một phương pháp mới để đảm bảo an toàn cho các cơ sở dữ
liệu, nó là một proxy quản lý tất cả những thông tin đi tới hoặc đi từ các cơ sở
dữ liệu. Nó hoạt động như một lớp trung gian, tiếp nhận tất cả các truy vấn,
đảm bảo an toàn cho chúng và gửi chúng tới máy chủ cơ sở dữ liệu. Sau đó nó
sẽ nhận lại dữ liệu đã mã hóa từ cơ sở dữ liệu, giải mã và gửi lại dữ liệu đã
được giải mã tới người dùng hợp pháp. CryptDB làm việc bằng cách làm cho
DBMS thực thi các truy vấn trên cơ sở dữ liệu đã mã hóa như là đang thực thi
trên cơ sở dữ liệu rõ. Điều này được áp dụng bằng cách thay đổi cấu trúc của
cơ sở dữ liệu để che dấu những thông tin, mối quan hệ có thể được trích ra từ
cơ sở dữ liệu và những thông tin này được che dấu bên trong proxy, thậm chí
bằng cách mã hóa tên các bảng và các cột. Sau đó mỗi cột sẽ được mã hóa
theo một cách nào đó tùy thuộc vào bản chất dữ liệu của chính nó và các truy
vấn có thể được áp dụng trên những dữ liệu này.

Hình 2. 1 Kiến trúc của CryptDB

Kiến trúc của CryptDB bao gồm 2 phần: một database proxy và một
unmodified DBMS. CryptDB sử dụng các hàm người dùng định nghĩa (user-
defined functions – UDFs) để thực hiện các tính toán mật mã trong DBMS.
Các hộp chữ nhật vuông và bo tròn đại diện các tiến trình và dữ liệu tương
ứng. Các hình có màu đậm chỉ ra các thành phần được thêm vào bởi
CryptDB. Các đường nét đứt cho thấy sự tách biệt giữa máy tính của người
dùng, máy chủ ứng dụng, máy chủ đang chạy proxy cơ sở dữ liệu của
CryptDB và máy chủ DBMS. Máy chủ ứng dụng chạy code ứng dụng và sinh
22
ra các truy vấn DBMS; máy chủ DBMS lưu trữ, xư lý dữ liệu đã được mã hóa
như dữ liệu không mã hóa, ngoài ra còn lưu trữ một vài bảng phụ được sử
dụng bởi CryptDB proxy; CryptDB proxy lưu trữ key, mã hóa truy vấn nhận
được từ ứng dụng và gửi cho máy chủ DBMS, mã hóa/giải mã dữ liệu.

CryptDB giải quyết vấn đề khi một người quản trị cơ sở dữ liệu “tò mò”
(curious database administrator – DBA) hoặc có ý đồ xấu truy cập vào dữ liệu
cá nhân của người dùng (ví dụ các bản ghi sức khỏe,các báo cáo tài chính,
thông tin cá nhân) bằng cách đánh cắp dữ liệu trên máy chủ DBMS; tại đây,
CryptDB ngăn chặn các DBA này đọc được dữ liệu cá nhân của người dùng.
Nhưng có một điều cần cân nhắc đó là đánh đổi giữa giữa việc tối thiểu
những thông tin quan trọng để lộ cho máy chủ DBMS và khả năng thực thi có
hiệu quả một loạt các truy vấn. Các phương pháp tiếp cận hiện tại để tính toán
trên dữ liệu mã hóa hoặc là quá chậm hoặc là không cung cấp đủ tính bí mật.
Mặt khác, việc mã hoa dữ liệu với một hệ thống mã hóa mạnh, như AES
chẳng hạn, sẽ ngăn chặn máy chủ DBMS thực thi nhiều truy vấn SQL. Trong
trường hợp này, giải pháp thực tế duy nhất sẽ là để cho server DBMS truy cập
tới key mã hóa, nhưng điều đó cũng sẽ cho phép kẻ xấu đạt được truy cập tới
toàn bộ dữ liệu.

CryptDB giải quyết thách thức này bằng những ý tưởng chính sau:

 Đầu tiên là thực thi các truy vấn SQL trên dữ liệu mã hóa. CryptDB thực
hiện ý tưởng này bằng cách sử dụng một chiến lược mã hóa nhận biết
SQL (SQL-aware encryption). CryptDB mã hóa mỗi mục dữ liệu theo
cách mà cho phép DBMS thực thi trên dữ liệu chuyển đổi. CryptDB hiệu
quả bởi nó chủ yếu sử dụng mã hóa đối xứng, tránh mã hóa đồng cấu đầy
đủ (fully homomorphic encryption), và chạy trên phần mềm DBMS
không sửa đổi (bằng cách sử dụng các hàm chức năng người dùng định
nghĩa).
 Kỹ thuật thứ hai là điều chỉnh mã hóa dựa trên truy vấn (adjustable
query-based encryption). Một vài lược đồ mã hóa làm rò rỉ thông tin về
dữ liệu cho máy chủ DBMS nhiều hơn một số khác, nhưng được yêu cầu
để xử lý các truy vấn nhất định. Để tránh tiết lộ tất cả mã hóa có thể của
dữ liệu cho DBMS từ trước đó, CryptDB điều chỉnh lược đồ má hóa nhận
biết SQL (SQL-aware encryption scheme) cho bất kỳ mục dữ liệu đã cho
nào, tùy thuộc vào các truy vấn được thực hiện. Để thực hiện những điều
chỉnh này một cách hiệu quả, CryptDB sử dụng onions of encryption (sẽ
được giải thích rõ ràng hơn trong các phần sau). Các onion là một cách
23
 mới để lưu trữ một cách chặt chẽ nhiều bản mã trong mỗi onion khác
trong cơ sở dữ liệu để tránh chi phí trong việc mã hóa lại.
2.2Truy vấn trên dữ liệu mã hóa
Bây giờ ta sẽ tìm hiểu cách mà CryptDB thực thi các truy vấn SQL trên
dữ liệu mã hóa nhằm chống lại mối đe dọa từ các DBA xấu của bên thứ ba.
Các máy DMBS và những người quản trị không đáng tin cậy, nhưng ứng
dụng và proxy là tin cậy.

CryptDB cho phép máy chủ DBMS thực thi các truy vấn SQL trên dữ liệu
mã hóa gần như giống với nó được thực thi cùng các truy vấn trên dữ liệu rõ.
Các ứng dụng có sẵn không cần thiết thay đổi. Cách tiến hành truy vấn của
DMBS cho truy vấn mã hóa thường giống như đối với các truy vấn nguyên
gốc, ngoại trừ các toán tử bao gồm truy vấn, chẳng hạn như lựa chọn
(selections), phép chiếu (projections), kết hợp (joins), tập hợp (aggregates),
và xếp thứ tự (ordering), được thực hiện trên bản mã, và sử dụng các toán tử
sửa đổi trong một số trường hợp.

Proxy của CryptDB lưu trữ một secret master key MK, lược đồ cơ sở dữ
liệu, và các lớp (layers) mã hóa hiện tại của tất cả các cột. Máy chủ DBMS
server chỉ thấy một lược đồ ẩn danh (với tên bảng và tên cột nào được thay
thế bởi các định danh hoàn toàn vô nghĩa), dữ liệu người dùng mã hóa, và một
vài bảng phụ được CryptDB sử dụng. CryptDB cũng trang bị cho máy chủ
với các chức năng người dùng định nghĩa cụ thể cho phép máy chủ tính toán
trên các bản mã cho các phép toán nhất định.

Việc xử lý một truy vấn trong CryptDB gồm 4 bước:

 Ứng dụng sinh ra một truy vấn, proxy chặn lại và viết lại: để bảo vệ
danh tính của các bảng và cột, nó ẩn danh mỗi tên bảng, tên cột, sử
dụng master key MK mã hóa mỗi hằng số (constant) trong truy vấn
với một lược đồ mã hóa phù hợp nhất cho phép toán mong muốn
 Proxy kiểm tra xem liệu máy chủ DBMS có được đưa các key để
điều chỉnh các lớp mã hóa trước khi thực thi truy vấn, và nếu có,
sinh ra một truy vấn UPDATE tại máy chủ DBMS để gọi một UDF
để điều chỉnh lớp mã hóa của các cột thích thợp
 Proxy chuyển tiếp truy vấn được mã hóa đến máy chủ DBMS, nơi
24
 thực hiện nó sử dụng SQL tiêu chuẩn (đôi khi gọi UDFs cho các
hàm tập hợp (aggregation) hoặc tìm kiếm từ khóa).
 DBMS server trả về kết quả truy vấn (được mã hóa), proxy sẽ giải
mã và trả về cho ứng dụng.

2.2.1 Mã hóa trong CryptDB

Phần này mô tả các loại mã hóa mà CryptDB sử dụng. Mỗi loại mã hóa sẽ
được làm rõ đặc điểm an toàn, chức năng, và cách mà nó được thực hiện.

Random (RND). RND cung cấp bảo mật tối đa trong CryptDB: an toàn
ngữ nghĩa dưới một tấn công lựa chọn bản rõ thích ứng - IND-CPA, hai giá trị
bằng nhau được ánh xạ tới hai bản mã khác nhau. Mặt khác, RND không cho
phép bất cứ sự tính toán nào được thực hiện hiệu quả trên bản mã. Một cấu
trúc hiệu quả của RND là sử dụng mã hóa khối như AES hoặc Blowfish trong
chế độ CBC với một vector khởi tạo ngẫu nhiên (IV). (hầu như sử dụng AES,
ngoại trừ các giá trị nguyên, Blowfish được sử dụng với kích thước khối là 64
bit vì khối 128 bit của AES sẽ khiến cho bản mã dài hơn đáng kể). Lớp mã
hóa này cho phép máy chủ thực hiện các truy vấn SELECT không có điều
kiện.
Deterministic (DET). DET có một đảm bảo hơn yếu hơn, nhưng nó vẫn
cung cấp bảo mật mạnh mẽ: nó chỉ rò rỉ các giá trị mã hóa tương ứng với giá
trị cùng một dữ liệu, bằng cách sinh ra cùng bản mã cho cùng bản rõ. Lớp mã
hóa này cho phép server thực hiện các equality checks, có nghĩa là nó có thể
thực hiện SELECT … WHERE …, GROUP BY, IN, COUNT, DISTINCT,…

Trong giới hạn mật mã, DET là một phép hoán vị giả ngẫu nhiên (pseudo-
random permutation – PRP – hay còn gọi là Block ciphers). Với các giá trị 64
bit và 128 bit, một mã hóa khối với một kích thước khối phù hợp được sử
dụng (Blowfish và AES tương ứng). Các giá trị nhỏ hơn 64 bít sẽ được đệm
(padding), nhưng với dữ liệu dài hơn một khối AES 128 bit, chế độ CBC tiêu
chuẩn của phép toán sẽ rò rỉ tiền tố bằng nhau (ví dụ, nếu hai mục dữ liệu có
một tiền tố đồng nhất dài ít nhất 128 bit). Để tránh vấn đề này, AES được sử
dụng với biến thể của chế độ CMC [7].

25
 Order-preserving encryption (OPE). OPE cho phép quan hệ thứ tự giữa
các mục dữ liệu được thiết lập dựa theo các giá trị mã hóa của chúng mà
không tiết lộ dữ liệu của chính nó. Nếu x < y, thì OPEK(x) < OPEK(y), với bất
cứ khóa bí mật K nào. Vì thế, nếu một cột được mã hóa với OPE, server có
thể thực hiện các truy vấn sắp xếp (range queries) khi các hằng số được mã
hóa đã cho OPEK(c1) và OPEK(c2) tương ứng với khoảng [c1, c2]. Server cũng
có thể thực hiện ORDER BY, MIN, MAX, SORT, vv…

OPE là một lược đồ mã hóa yếu hơn DET vì nó để lộ thứ tự. Do đó,
CryptDB proxy sẽ chỉ để lộ các cột được mã hóa OPE cho máy chủ nếu
những người dùng yêu cầu các truy vấn thứ tự (order queries) trên các cột đó.
Thuật toán mã hóa của Boldyreva [8] được sử dụng giúp OPE đạt được những
đảm bảo an toàn có thể chứng minh được: mã hóa tương đương với một ánh
xạ ngẫu nhiên duy trì thứ tự.

Homomorphic encryption (HOM). HOM là một lược đồ mã hóa cho

phép máy chủ thực hiện các tính toán trên dữ liệu mã hóa với kết quả cuối
dùng được giải mã tại proxy. Trong khi mã hóa đồng cấu đầy đủ (fully
homomorphic encryption) phục vụ chậm [9], mã hóa đồng cấu cho các phép
toán cụ thể có hiệu quả hơn. Để hỗ trợ tính tổng của các giá trị nguyên, hệ mật
Paillier [10] được thực hiện, với Paillier, kết quả của phép nhân các mã hóa
của hai giá trị dẫn tới kết quả là một mã hóa của tổng các giá trị đó, ví dụ,
HOMK(x) * HOMK(y) = HOMK(x + y), với phép nhân được thực hiện modulo
một vài giá trị khóa công khai. Để tính các hàm tập hợp SUM, proxy thay thế
SUM với các lời gọi tới một UDF thực hiện phép nhân Paillier trên một cột
được mã hóa với HOM. HOM cũng có thể được sử dụng để tính toán giá trị
trung bình bằng cách DBMS server trả về giá trị tổng (sum) và đếm (count)
riêng biệt.

Join (Equi-JOIN và OPE-JOIN). Một lược đồ mã hóa riêng là cần thiết

để phục vụ cho phép kết hợp (joins) giữa hai cột vì CryptDB sử dụng các key
khác nhau cho DET để ngăn chặn các mối tương quan giữa các cột. Equi-
JOIN hỗ trợ tất cả các phép toán mà DET cho phép và cũng cho phép máy
chủ xác định những giá trị lặp lại giữa hai cột. OPE-JOIN cho phép các liên
kết dựa trên các mối liên hệ thứ tự.
26
 Word search (SEARCH). SEARCH được sử dụng để thực hiện các tìm
kiếm trên văn bản được mã hóa để hỗ trợ các truy vấn như LIKE của MySQL
chẳng hạn. Giao thức mã hóa của Song [11] được sử dụng theo một cách
khác, dẫn tới kết quả là một đảm bảo an toàn tốt hơn. Cho mỗi cột cần
SEARCH, văn bản được chia thành các từ khóa sử dụng các ký tự phân cách
tiêu chuẩn (hoặc sử dụng một chức năng trích ra từ khóa đặc biệt được quy
định bởi người phát triển lược đồ). Sau đó những từ lặp lại được loại bỏ, hoán
vị ngẫu nhiên vị trí của các từ và rồi mã hóa mỗi từ sử dụng lược đồ của
Song, đệm (padding) mỗi từ cho cùng kích thước. SEARCH có mức độ an
toàn gần như RND: mã hóa ko để lộ cho máy chủ DBMS bất kể một từ nào
đó được lặp đi lặp lại trong nhiều hàng, nhưng nó rò rỉ số lượng từ khóa được
mã hóa với SEARCH; kẻ xấu có thể ước lượng số lượng các từ khác biệt hoặc
trùng lặp (ví dụ, bằng cách so sánh kích thước của các bản mã SEARCH và
các bản mã RND của cùng dữ liệu).

Chú ý răng SEARCH chỉ cho phép CryptDB thực hiện các tìm kiếm từ
khóa từ đầy đủ (full-word keyword searches); nó không thể hỗ trợ các biểu
thức chính quy tùy ý. Với các ứng dụng yêu cầu tìm kiếm nhiều từ liền kề,
CryptDB cho phép nhà phát triển ứng dụng vô hiệu hóa việc loại bỏ trùng lặp
và sắp xếp lại bằng cách chú thích lược đồ, mặc dù đây không phải là mặc
định. Sử dụng LIKE hầu hết được SEARCH hỗ trợ với những chú thích như
vậy. Tất nhiên, ta vẫn có thể kết hợp nhiều toán tử LIKE với AND hoặc OR
để kiểm tra xem nhiều từ độc lập có trong văn bản hay không.

2.2.2 Mã hóa lớp

Mã hóa dữ liệu trên cơ sở dữ liệu được tính toán theo lớp. Có 4 mục tiêu
chính khác nhau để đạt được, và với mỗi mục tiêu tồn tại một “nhân” được
bao bọc bởi các lớp khác nhau, được gọi là onion: EQ, ORD, SEARCH và
ADD onion. EQ onion nhằm mục đích điều chỉnh các lớp cho các truy vấn
equality, trong khi ORD onion nhằm mục đích điều chỉnh các lớp cho các truy
vấn so sánh (comparison), SEARCH onion được sử dụng để tìm kiếm một
đoạn văn bản trong cơ sở dữ liệu mà không làm rò rỉ bất kỳ thông tin gì.
Onion này không cho phép thực thi các giá trị nguyên (integer values). Cuối
cùng Add onion nhằm mục đích cộng (add) các giá trị mã hóa mà chỉ hỗ trợ
các giá trị nguyên. Các onion này có các lớp khác nhau và mỗi lớp được mã
27
hóa sử dụng các thuật toán khác nhau. Hơn nữa, những thuật toán này có các
mức độ an toàn khác nhau với các lớp bên ngoài của một onion sẽ bảo mật
hơn các lớp bên trong. Một khi cơ sở dữ liệu được tạo ra, tất cả các onion sẽ ở
tại lớp an toàn nhất.

Các truy vấn được xử lý như các cột trong cơ sở dữ liệu, do đó, CryptDB
là hướng cột (column-oriented). Nếu một giá trị cần được giải mã tới lớp yếu
hơn, thì toàn bộ cột chứa giá trị đó sẽ được giải mã. Tuy nhiên, nó gây ra rò rỉ
thông tin nhiều hơn yêu cầu. Nếu chúng ta cần một giá trị được giải mã đến
lớp yếu nhất, toàn bộ cột có chứa giá trị đó cũng sẽ được giải mã tới lớp này
và dẫn tới rò rỉ thông tin. Cũng lưu ý rằng lớp trong cùng là lớp yếu nhất,
nhưng nó cũng không tiết lộ bất kỳ bản rõ nào cho máy chủ DBMS. Lớp bên
trong của các onion là Equi-JOIN, OPE-JOIN, SEARCH và HOM không bao
giờ được gỡ bỏ.

Hình 2. 2 EQ Onion.

EQ Onion. Tại lớp an toàn nhất của EQ onion là lớp RND. Lớp RND này
mã hóa mỗi giá trị với AES (thuật toán Rjindaels) trong chế độ CBC. Với số
nguyên, Blowfish trong chế độ CBC thích hợp hơn vì kích thước khối 64 bit
của nó thay vì kích thước khối 128 bit sẽ giảm độ dài của bản mã. Giá trị khởi
tạo cho cả hai loại mã hóa là các giá trị được chọn ngẫu nhiên. Mỗi giá trị
được mã hóa thành các bản mã khác nhau kể khi bản rõ là như nhau. Vì lý do
này, lớp RND không thể bị tấn công lựa chọn bản rõ thích ứng. Tuy nhiên,
lớp này không cung cấp chức năng hiệu quả.
28
 Khi cần thiết thực hiện equality check, Lớp RND cần được loại bỏ. Lớp
bên trong tiếp theo của EQ onion là lớp DET. Lớp này là lớp bất định
(derministic layer). Sau khi mã hóa được thực hiện, nếu hai giá trị giống nhau
thì bản mã tương ứng của chúng cũng giống nhau.

Với các giá trị trong cùng một cột, hai lớp RND và DET đủ để xử lý các
truy vấn. Tuy nhiên, một vài truy vấn cần kiểm tra sự bằng nhau (equality)
của hai cột khác nhau hoặc hai cột khác nhau của các bảng khác nhau. Đối
với những trường hợp này, lớp hiện tại cần được cập nhật thành lớp Equi-
JOIN.

Hình 2. 3 ORD Onion.

ORD onion. Lớp an toàn nhất của ORD onion giống như EQ onion, là lớp
RND. Lớp bên trong của RND cho ORD onion là lớp OPE. Các thuật toán mã
hóa duy trì thứ tự không có đủ an toàn và hiệu quả cho đến bây giờ. Nếu mã
hóa của x nhỏ hơn mã hóa của y, thì giá trị x cũng nhỏ hơn giá trị y. Nếu
chúng ta tìm ra bất kỳ giá trị được mã hóa nào gữa hai mã hóa này, thì bản rõ
cũng sẽ nằm giữa x và y. Cụ thể, lược đồ này rò rỉ thứ tự, do đó, nó là một
lược đồ yếu hơn khi được so sánh với sự rò rỉ của equality.

Đối với các giá trị tại cùng một cột, lớp này là đủ để xử lý các truy vấn,
nhưng nếu hai cột khác nhau được so sánh để kiểm tra thứ tự, thì chúng ta cần
tháo bỏ lớp OPE, và đạt tới lớp OPE-JOIN. Lớp này thiếu tính chức năng hơn
lớp EQUI-JOIN của EQ onion. Để điều chỉnh hai cột là không thể vì sự thiếu
29
hiệu quả của các thuật toán duy trì thứ tự. Có hai giải pháp. Giải pháp đầu tiên
là ứng dụng sẽ khai báo các cột có thể được kết nối, và trong khi sắp xếp các
khóa, cùng một khóa sẽ được sử dụng cho những cột này. Nó không hợp lý
trong hầu hết tình huống khai báo trước. Giải pháp thứ hai là cùng một khóa
sẽ được sử dụng cho tất cả các cột tại lớp này. Giải pháp này cũng không phải
là giải pháp tốt. May thay, các range join không được sử dụng quá nhiều.

Hình 2. 4 SEARCH và ADD Onion.

SEARCH & ADD onions. SEARCH onion chỉ có một lớp, vì thế không
có quá trình giải mã nào cho onion này. SEARCH onion có một giá trị, và lớp
SEARCH trong đó bao gồm giá trị này. Thuật toán tìm kiếm được sử dụng
trong CryptDB là thuật toán tìm kiếm của Song. Mục đích của SEARCH
onion là tìm kiếm các giá trị mã hóa bên trong một bảng mã hóa. ADD onion
cũng tương tự như vậy. Lớp HOM là lớp duy nhất của ADD onion. Mục đích
của onion này là cung cấp một số chức năng với các giái trị mã hóa mà không
truy cập bản rõ. Điều này có thể đạt được với mã hóa đồng cấu (homomorphic
encryption). Thuật toán được sử dụng cho mã hóa đồng cấu của CryptDB là
thuật toán của Paillier.

2.2.3 Hàm người dùng định nghĩa - UDF: User-Defined Function

Một hàm (chức năng – function) chứa các hướng dẫn để thực hiện một tác
vụ cụ thể và cung cấp để lặp lại tác vụ này dễ dàng. Hàm người dùng định
nghĩa cũng là một chức năng, và nó được tạo bởi người dùng. Người dùng
này cần có quyền để thực hiện các tiến trình trong cơ sở dữ liệu, hoặc người
sở hữu cơ sở dữ liệu (database owner – dbo) có thể được sử dụng. dbo là một
người dùng có thể thực hiện tất cả các hoạt động trên cơ sở dữ liệu.

Nếu chúng ta có một bảng được gọi là Square có hai cột là EdgeLength và
Number, thì chúng ta có thể tạo một UDF để tính toán diện tích của các hình
vuông bên trong cơ sở dữ liệu. Ví dụ bảng Square trong Hình 2.6.
30
 Hình 2. 5 Bảng Square.

Không cần thiết phải giữ các giá trị diện tích thêm vào cơ sở dữ liệu.
Chúng ta có thể tạo một UDF, và gọi nó khi cần tính toán diện tích. Đây là
một ví dụ tạo một UDF.

CREATE FUNCTION dbo.area (edge FLOAT) RETURNS FLOAT

RETURN(edge * edge);

Một truy vấn ví dụ để sử dụng UDF này có thể như sau:

SELECT Number, area (Edge Length) AS Area FROM Square;

Kết quả trả về sẽ giống Hình 2.7.

Hình 2. 6 Kết quả

Thay vì giữ dữ liệu cho từng thông tin có thể được yêu cầu, sẽ tốt hơn khi
tạo một UDF và gọi nó bất cứ khi nào tác vụ cần. Trong CryptDB, UDF cũng
là một yêu cầu. Việc giải mã của kiến trúc lớp để điều chỉnh lớp hiện tại được
thực hiện bằng cách sử dụng các UDF. Và cập nhật trạng thái hiện tại của các
lớp onion cũng được thực hiện bằng cách sử dụng các UDF. Việc thay đổi tất
cả cơ chế cơ sở dữ liệu hiện tại là khó đạt được. Do đó, các UDF rất quan
trọng đối với các chức năng bổ sung trong hệ thống cơ sở dữ liệu.

2.2.4 Điều chỉnh mã hóa dựa theo truy vấn

Một phần quan trọng trong thiết kế của CryptDB là tự động điều chỉnh lớp
mã hóa trên máy chủ DBMS. Mục đích là để sử dụng các lược đồ mã hóa an
toàn nhất mà có thể chạy các truy vấn được yêu cầu. Ví dụ, nếu ứng dụng
không sinh ra truy vấn nào so sánh các mục dữ liệu trong một cột, hoặc sắp
xếp cột, cột phải được mã hóa với RND. Đối với những cột yêu cầu các
31
equality check nhưng không yêu cầu inequality check, DET cũng đủ. Tuy
nhiên, tập truy vấn không phải lúc nào cũng được biết trước. Do đó, chúng ta
cần một lược đồ có khả năng thích ứng mà tự động điều chỉnh các mã hóa.

“Onions of encryption” – có thể hiểu là mã hóa nhiều lớp. Ý tưởng là mã

hóa từng mục dữ liệu trong một hoặc nhiều onion: tức là, mỗi giá trị sẽ được
bọc trong các lớp mã hóa ngày càng mạnh hơn. Mỗi lớp của mỗi onion cho
phép mỗi loại chức năng như được chú thích. Ví dụ, các lớp ngoài cùng như
RND và HOM cung cấp bảo mật tối đa, trong khi các lớp bên trong như OPE
cung cấp nhiều chức năng hơn.

Hình 2. 7 Các lớp mã hóa Onion và các lớp tính toán được phép.
Tên của Onion cho biết các phép toán chúng cho phép tại một vài lớp của
chúng (Equality, Order, Search, và Addition). Trong thực tế cần nhiều onion,
vì các phép toán được hỗ trợ bởi các lược đồ mã hóa khác nhau không luôn
luôn theo thứ tự một cách hoàn toàn, và vì cần phải cân nhắc hiệu suất thực
hiện (kích thước của bản mã và thời gian mã hóa cho các lớp onion lồng vào
nhau). Phụ thuộc vào loại dữ liệu (và các chú thích (annotations) được cung
cấp bởi nhà phát triển ứng dụng trên lược đồ cơ sở dữ liệu), CryptDB có thể
không duy trì tất cả các onion cho mỗi cột. Ví dụ, Search onion không có ý
nghĩa đối với các số nguyên (integers), và Add onion không có ý nghĩa cho
các chuỗi (strings).

Với mỗi lớp của mỗi onion, proxy sử sử dụng cùng một key cho các giá trị
đang mã hóa trong cùng một cột, và các key khác nhau trên các bảng, các cột,
các onion, và các lớp onion khác nhau. Việc sử dụng cùng một key cho tất cả
các giá trị trên một cột cho phép proxy thực hiện các phép toán trên một cột
mà không phải tính toán các key riêng biệt cho từng hàng. Việc sử dụng các

32
key khác nhau trên các cột ngăn chặn máy chủ tìm ra bất kỳ mối liên hệ bổ
sung nào. Tất cả những key này được bắt nguồn từ masterk key MK. Ví dụ,
với bảng t, cột c, onion o, và lớp mã hóa l, proxy sử dụng key

Kt,c,o,l = PRPMK(bảng t, cột c, onion o, lớp l), (1)

với PRP là một hoán vị giả ngẫu nhiên – pseudo random permutation (ví
dụ, AES)

Mỗi onion bắt đầu được mã hóa với lược đồ mã hóa an toàn nhất (RND
cho onion Eq và Ord, HOM cho onion Add, và SEARCH cho onion Search).
Khi proxy nhận các truy vấn SQL từ ứng dụng, nó xác định xem các lớp mã
hóa nào cần được gỡ bỏ. Để cho phép P trên cột c thực thi một truy vấn trên
máy chủ, proxy đầu tiên thiết lập lớp onion cần thiết để tính toán P trên c. nếu
mã hóa của c không phải là đã ở một lớp onion mà cho phép P, proxy bóc
tách các lớp onion để cho phép P trên c, bằng cách gửi key onion tương ứng
tới máy chủ. Proxy không bao giờ giải mã dữ liệu qua các lớp onion mã hóa
kém an toàn.

CryptDB thực hiện việc giải mã lớp onion sử dụng các UDF chạy trên
máy chủ DBMS. Ví dụ, để giải mã onion Ord của cột 2 trong bảng 1 tới lớp
OPE, proxy sinh ra truy vấn sau tới server sử dụng DECRYPT_RND UDF:

UPDATE Table1 SET

C2-Ord = DECRYPT_RND(K, C2-Ord, C2-IV)

với K là key phù hợp được tính toán từ phương trình (1). Tại cùng thời
điểm, proxy cập nhật trạng thái bên trong của chính nó để ghi nhớ rằng cột
C2-Ord trong Table1 bây giờ đang ở lớp OPE trong DBMS.

Chú ý rằng việc giải mã onion được thực hiện toàn bộ bởi máy chủ
DBMS. Trong trạng thái ổn định, việc giải mã ở phía máy chủ là không cần
thiết bởi vì việc giải mã onion xảy ra chỉ khi một lớp tính toán mới được yêu
cầu trên một cột. Ví dụ, sau một equality check được yêu cầu trên một cột và
máy chủ đưa cột đó vào lớp DET, cột vẫn tồn tại trong trạng thái đó, và các
truy vấn sau đó với các equality check không yêu cầu giải mã.

33
 2.2.5 Cấu trúc dữ liệu trong CryptDB
Trong các hệ thống cơ sở dữ liệu, người dùng yêu cầu một vài thông tin
hoặc chức năng từ các ứng dụng. Các truy vấn SQL được sử dụng để đám ứng
nhu cầu của người dùng. Các máy chủ ứng dụng gửi các truy vấn tới máy chủ
DBMS. Máy chủ DBMS xử lý và phản hồi tập kết quả. Hệ thống này có thể
bị kẻ xấu tấn công hoặc nghe trộm. Các máy chủ DBMS cũng tò mò về các
truy vấn và theo dõi các truy vấn với kết quả của chúng. Khả năng khác là
truy cập vật lý và đĩa có thể gây mất trộm dữ liệu. Trong CryptDB, cơ chế của
các truy vấn là tương tự, nhưng kiến trúc máy chủ một cách nào đó thay đổi
và một máy chủ bổ sung được gọi là Proxy Server được thêm vào hệ thống cơ
sở dữ liệu.

Nó giả định rằng tất cả truy vấn từ máy chủ ứng dụng được thực hiện bởi
Proxy Server và gửi tới DBMS Server sau khi sửa đôi. Mục đích là giữ thông
tin vô nghĩa tại phía DBMS Server để ngăn chặn những người quản trị cơ sở
dữ liệu tò mò dòm ngó tới nội dung của các bảng trong cơ sở dữ liệu của nó.
Vì lý do này, chúng ta cần làm cho toàn bộ dữ liệu trở nên vô nghĩa.

Việc đầu tiên là tạo một bảng để giữ một vài dữ liệu bên trong cơ sở dữ
liệu của DBMS Server. Trong CryptDB, bảng của DBMS Server hoàn toàn
khác với bảng thực. Proxy Server thay đổi tên bảng. Sau đó, tùy theo loại của
cột (ví dụ int, varchar), sẽ được đưa vào các onion có thể. Proxy Server giữ tất
cả các dữ liệu của onion có thể trong các cột khác nhau một cách riêng biệt
trong bảng này. Bảng trong Hình 2.9 là một ví dụ đơn giản.

Bảng được tạo mới từ bảng trong Hình 2.9 bởi Proxy Server được thể hiện
trong Hình 2.10.

Hình 2. 8 Bảng dữ liệu gốc

Hình 2. 9 Bảng được tạo ra bởi Proxy Server.

Việc thứ hai là thêm các trường hợp (instances) vào các bảng hiện tại. Tên
của các cột được thay đổi, và mỗi giá trị trong bảng được mã hóa tùy theo
thuật toán của lớp onion của nó. Ví dụ, nếu lớp hiện tại của EQ onion là RND,
và truy vấn thực hiện equality, thì từng giá trị trong cột tương ứng sẽ được mã
hóa với AES trong chế độ CBC. Hoặc thuật toán của Paillier sẽ được sử dụng
để mã hóa các giá trị thuộc về lớp HOM của ADD onion. Tất cả những tiến
trình mã hóa này được thực hiện bởi Proxy Server.

Khi một truy vấn đến Proxy Server, nó thay đổi truy vấn, Trước hết, Proxy
Server quyết định onion nào được sử dụng cho truy vấn này. Proxy Server có
các bảng thêm, một trong số chúng là để giữ trạng thái hiện tại của từng onion
của từng cột. Sau khi quyết định onion của truy vấn, Proxy Server nhìn vào
bảng này, và kiểm tra xem bảng hiện tại của onion có đang ở lớp cần thiết cho
truy vấn này không. Nếu không, Proxy Server gọi UDF chịu trách nhiệm gỡ
bỏ lớp hiện tại đến lớp cần thiết. Sau quá trình này, Proxy Server thay đổi truy
vấn, và gửi nó nó DBMS Server. Toàn bộ dữ liệu được lưu trữ trong cơ sở dữ
liệu của DBMS Server đã được mã hóa, và các truy vấn không có ý nghĩa đối
với người quản trị cơ sở dữ liệu.

DBMS Server xử truy vấn đã được sửa đổi và trả về một kết quả đã mã
hóa cho Proxy Server. Proxy Server lấy các giá trị mã hóa, giải mã chúng và
gửi cho Application Server. Application Server không quan tâm đến bất kỳ
quá trình mã hóa nào, nó chỉ gửi bản rõ gốc và lấy kết quả, cung cấp dịch vụ
cho các client với những kết quả này. Cấu trúc máy chủ cơ bản của CryptDB
là như vậy.

2.2.6 Thực thi truy vấn trên dữ liệu mã hóa

Khi các lớp onion trên DBMS đang ở lớp cần thiết để thực thi một truy
vấn, proxy biến đổi truy vấn để hoạt động trên các onion này. Đặc biệt, proxy
thay thế các tên cột trong một truy vấn với các tên onion tương ứng, dựa trên
lớp tính toán được thực hiện trên cột đó. Ví dụ, với lược đồ được thể hiện
trong Hình 2.10, một tham chiếu đến cột Name cho một so sánh bằng (ví dụ
WHERE Name = „Alice‟) sẽ được thay thế với một tham chiếu tới cột Name-
EqOn.

Proxy cũng thay thế mỗi hằng số trong truy vấn với mã hóa onion tương
ứng của hằng số đó, dựa trên các tính toán trong đó nó được sử dụng. Ví dụ,
nếu một truy vấn chứa WHERE Name = „Alice‟, proxy mã hóa „Alice‟ bằng
cách áp dụng lần lượt tất cả các lớp mã hóa tương ứng với onion Eq mà vẫn
chưa được loại bỏ khỏi C2-Eq.

Cuối cùng, server thay thế các toán tử nhất định với các UDF tương ứng.
Ví dụ, toán tử tập hợp SUM và toán tử cộng cột „+‟ phải được thay thế với một
lời gọi của một UDF mà thực hiện phép tính cộng HOM của các bản mã. Các
toán tử Equality và Order (như „=‟ và „<‟ chẳng hạn) không cần thiết thay thế
như vậy và có thể được áp dụng trực tiếp vào các bản mã DET và OPE.

Khi proxy chuyển đổi truy vấn, nó gửi truy vấn tới DBMS server, nhận
các kết quả truy vấn (bao gồm dữ liệu mã hóa), giải mã các kết quả sử dụng
các onion key tương ứng, và gửi kết quả giải mã cho ứng dụng.

Thực thi các truy vấn không có chức năng. Giả sử bảng bảng Studens
có hai cột là ID và Name. Cột ID có giá trị nguyên trong khi cột Name có giá
trị là chuỗi. Bảng Students được tạo ra bằng câu lệnh sau:

CREATE TABLE Students (ID int, Name varchar(255));

Sau khi tạo bảng, chúng ta chèn một vài giá trị như sau:

INSERT INTO Students VALUES(1, “Alice”);

INSERT INTO Students VALUES(2, “Bob”);
INSERT INTO Students VALUES(3, “Eve”);

Khi chúng ta chạy tất cả các truy vấn này, Application Server tạo bảng
Students. bảng này có dữ liệu thô, vì vậy nó không phải là cách tốt để lưu trữ
bảng này trong cơ sở dữ liệu của DBMS Server vì lý do an ninh. Cụ thể,
Proxy Server tạo một bảng đã mã hóa mới cho DBMS Server. Bảng mã hóa
được tạo mới sẽ như bảng trong Hình 2.12.

Hình 2. 10 Bảng Students sau khi được tạo.

 Hình 2. 11 Bảng mã hóa được tạo trên Proxy Server.

Vì loại dữ liệu của cột ID là nguyên, SEARCH onion không dùng cho cột
này và loại dữ liệu của cột Name là chuỗi, HOM onion cũng không dùng cho
cột này. Như đã mô tả từ trước, tất cả các lớp sẽ ở lớp mã hóa an toàn nhất lúc
đầu. Có bảy lớp. Các lớp an toàn nhất của các onion là ba lớp RND,
SEARCH và HOM. Tuy nhiên, chúng cũng có ít chức năng nhất. Ví dụ, lớp
RND không rò rỉ bất kỳ dữ liệu nào, nhưng nó không có chức năng hiệu quả.
Nếu chúng ta quay trở lại ví dụ, bằng cách sử dụng lớp an toàn nhất, chúng ta
có thể chạy các truy vấn như SELECT * FROM Students;”, “SELECT Name
FROM Students;”

Chú ý rằng Proxy phải thay đổi các truy vấn để bảo vệ nội dung bảng gốc.
Nếu chúng ta tiếp tục với truy vấn “SELECT Name FROM Students;”, truy
vấn được thay đổi sẽ như sau:

SELECT C2-IV, C2-Eq FROM DBMS_Table1;

DBMS Server sẽ xử lý truy vấn này, và trả về kết quả trong Hình 2.13

Hình 2. 12 Kết quả của truy vấn

Hình 2. 13 Kết quả được trả về từ phía Proxy Server y

Bảng tương ứng khi Proxy Server giải mã và gửi cho Application Server
sẽ giống như Hình 2.13.
Truy vấn này trả về kết quả mà không có chức năng nào. Tuy nhiên,
không có sự thay đổi nào tại bản rõ trong bảng của DBMS Server. Bạn chỉ có
thể đọc dữ liệu trả về, nhưng nói chung các truy vấn đến Application Server
yêu cầu một số chức năng như cập nhật dữ liệu, lựa chọn và hiển thị một vài
hàng cụ thể của bảng, tính trung bình của một cột.

Thực thi truy vấn với chức năng equality check. Để hiểu sự thực thi
truy vấn trên các bản mã, xem xét lược đồ cơ sở dữ liệu ví dụ sau.

Hình 2. 14 Lược đồ cơ sở dữ liệu ví dụ.

Hình 2. 15 Lược đồ cơ sở dữ liệu ví dụ.

Ban đầu, mỗi cột trong bảng được bọc trong tất cả các onion mã hóa, với
RND, HOM, và SEARCH là các lớp ngoài cùng. Tại thời điểm này, máy chủ
không thể biết gì về dữ liệu ngoại trừ số cột, số hàng, và kích thước dữ liệu.

Hình 2. 16 Các lớp mã hóa của các cột.

Hình 2. 17 Các lớp mã hóa của các cột.

Giả sử Eq Onion đang ở lớp mã hóa mặc định RND, thực hiện truy vấn
sau:
SELECT ID FROM Employees WHERE Name = „Alice‟ Lúc này mã hóa của Name
sẽ được yêu cầu giảm xuống tới lớp DET. Sau đây là các bước để thực hiện được truy vấn trên dữ liệu
mã hóa:

Bước 1: proxy gửi tới DBMS:

UPDATE Table1 SET

C2-Eq = DECRYPT_RND(KT1,C2,Eq,RND, C2-Eq, C2-IV),

với cột C2-Eq tương ứng với Name. Tại DBMS, cột C2-Eq được giải mã
tới lớp DET:

DKeyT1,C2,Eq,RND(xd1e3, x8a13) = x7b3d

DKeyT1,C2,Eq,RND(x3f2a, x73fd) = xbb4a

proxy sau đó cập nhật vào log rằng Table1 cột C2-Eq hiện tại đang ở lớp
DET trong DMBS.

Hình 2. 18 Lược đồ cơ sở dữ liệu sau bước 1

Hình 2. 19 Lược đồ cơ sở dữ liệu sau bước 1

Hình 2. 20 Lớp mã hóa của các cột sau bước 1

Hình 2. 21 Lớp mã hóa của các cột sau bước 1

 Bước 2: Proxy mã hóa „Alice‟ lên lớp DET của Eq Onion thu được giá trị
x7b3d bằng cách thực hiện mã hóa
EKeyT1,C2,Eq,DET(EKeyT1,C2,Eq,JOIN(Alice))

proxy sau đó sinh ra một truy vấn và gửi nó cho DBMS:

SELECT C1-Eq, C1-IV FROM Table1 WHERE C2-Eq = x7b3d

với cột C1-Eq tương ứng với ID, và x7b3d là mã hóa Eq onion của
“Alice” với các key KT1,C2,Eq,JOIN và KT1,C2,Eq,DET. Chú ý rằng proxy phải yêu càu
IV ngẫu nhiên từ cột C1-IV để giải mã bản mã RND từ C1-Eq. Các lớp Eq
Onion và các giá trị mã hóa vẫn không thay đổi sau bước UPDATE.

Hình 2. 22 Lược đồ cơ sở dữ liệu sau bước 2.

Hình 2. 23 Lược đồ cơ sở dữ liệu sau bước 2.

Bước 3: Cuối cùng, proxy nhận được kết quả x2b82 tại lớp RND, tiến
hành giải mã nó sử dụng các key KT1;C1;Eq;RND, KT1;C1;Eq;DET, và KT1;C1;Eq;JOIN,
thu được kết quả 23, và trả nó về cho ứng dụng.

DKeyT1,C1,Eq,JOIN(DKeyT1,C1,Eq,DET(DKeyT1,C1,Eq,RND (x2b82, x27c3))) = 23

Nếu truy vấn tiếp theo là SELECT COUNT(*) FROM Employees

WHERE Name = „Bob‟, cột C2-Eq lúc này đã ở lớp DET, không cần thiết
phải giải mã ở phía máy chủ, và proxy trực tiếp sinh ra truy vấn SELECT
COUNT(*) FROM Table2 WHERE C2-Eq = xbb4a, với xbb4a là mã hóa Eq
onion của “Bob” sử dụng KT1;C2;Eq;JOIN và KT1;C2;Eq;DET.

Thực thi truy vấn với các chức năng order check. Mã hóa duy trì thứ tự
(Order preserving encryption) là một vấn đề khó khăn trong các cơ chế tìm
kiếm riêng tư bao gồm cả trong CryptDB. Phần này có thể được tóm tắt như
sau, nếu giá trị mã hóa của x nhỏ hơn giá trị mã hóa của y, thì ta biết được
rằng giá trị x nhỏ hơn y. Nếu chúng ta tìm ra bất kỳ giá trị mã hóa nào nằm
giữa hai giá trị mã hóa này, thì dạng giải mã sẽ nằm giữa x và y. Lược đồ này
để lộ thứ tự, nó là lược đồ yếu nhất. các truy vấn “lớn hơn”, “nhỏ hơn”,
ORDER BY, SORT, MAX, MIN có thể được thực hiện với lược đồ mã hóa.
Việc thực hiện mã hóa duy trì thứ tự không được thực hiện cho đến khi có
CryptDB, và thậm chí cũng không có ước lượng nào cho tính thực tế của lược
đồ. Có nghĩa là, CryptDB là triển khai đầu tiên của mã hóa duy trì thứ tự sử
dụng thuât toán của Boldyreva [8].

Các truy vấn với chức năng tìm kiếm. CryptDb sử dụng triển khai thuât
toán tìm kiếm của Song [11]. Thuật toán này thực hiện các tìm kiếm từ đầy đủ
(full-word) với các truy vấn LIKE. Trong CryptDB, việc lặp lại các từ được
loại bỏ và các từ được hoán vị để cung cấp an toàn hơn trong tìm kiếm. Tuy
nhiên bằng cách so sánh số lượng bản mã RND với bản mã SEARCH, có thể
biết được số lượng các từ lặp lại. Sau đó, các từ được đệm (padded) tới độ dài
cố định N bit để mã hóa theo thuật toán của Song. Các truy vấn có thể được
chạy như sau:

SELECT * FROM Students WHERE Name LIKE “% Alice %”;

Sau khi truy vấn này tới Proxy Server, nó sẽ sửa đổi truy vấn với việc mã
hóa chuỗi “Alice”. Mã hóa được giả sử là x29b0 trong ví dụ.

SELECT * FROM DBMS_Table1 WHERE C2-Search LIKE “% x29b0 %”;

Một trong các UDF làm cho DBMS Server kiểm tra sự phù hợp của bản
mã trong cột SEARCH với mã hóa của chuỗi “Alice”. Sự rò rỉ duy nhất cho
DBMS Server là liệu có sự phù hợp nào với từ đầy đủ này hay không. Các
biểu thức chính quy và nhiều từ không được hỗ trợ, chỉ các tìm kiếm từ đầy
đủ (full-word) có thể được thực hiện với thuật toán này, vì thế phần tìm kiếm
này của CryptDB không đủ đáp ứng nhu cầu của chúng ta cho các truy vấn
tìm kiếm.

Các truy vấn với chức năng tính tổng các giá trị. Từ quan điểm của các
truy vấn SQL, tổng của số nguyên được sử dụng không chỉ cho các truy vấn
SUM mà còn được sử dụng để tính toán giá trị trung bình. Việc thực hiện
chức năng cộng cho bản mã có thể đạt được bằng cách sử dụng mã hóa đồng
cấu. Trong mã hóa đồng cấu, phép nhân của hai bản mã là mã hóa của phép
cộng của bản rõ của hai bản mã đó. Ta có thể mô tả như sau:
 m1 và m2 là bản rõ của hai giá trị

c1 la mã hóa của m1.

c2 là mã hóa của m2.

c1 × c2 = Enc(m1 + m2) với Enc là hàm mã hóa có đặc tính đồng cấu.

Thuật toán đồng cấu được sử dụng trong CryptDB là thuật toán của Paillier
[10]. Trong CryptDB, chúng ta giữ các giá trị mã hóa trong cơ sở dữ liệu. Vì
lý do này, đặc tính đồng cấu là một giải pháp cho CryptDB. Các truy vấn với
SUM và AVG được bao gồm trong phần này. Chúng ta có thể tạo ra một truy
vấn theo ví dụ sau, ta sẽ tính toán tổng số điểm (Grade) của các học sinh trong
bảng ví dụ sau được minh họa trong Hình 2.20.

Hình 2. 24 Bảng được cập nhật với các giá trị Grade được thêm.

Hình 2. 25 Bảng được cập nhật với các giá trị Grade được thêm.
Bảng trong Hình 2.20 không được giữ bên trong cơ sở dữ liệu. Proxy
Server mã hóa các giá trị cho việc tạo ra một bảng khác cho DBMS Server.
Cơ sở dữ liệu được tạo ra cho DBMS Server sẽ giống như bảng trong Hình
2.21.

Hình 2. 26 Bảng được cập nhật được mã hóa bên Proxy Server.

Hình 2. 27 Bảng được cập nhật được mã hóa bên Proxy Server.
Truy vấn ví dụ của chúng ta có thể giống như sau:

SELECT SUM (grade) AS average FROM Students;

Proxy Server sẽ chỉnh sửa truy vấn, và gửi tới DBMS Server. Theo bảng
của DBMS Server, truy vấn sửa đổi sẽ như sau:
SELECT SUM (c3-Hom) AS average FROM DBMS_Table2;

Sau khi lấy truy vấn SQL này, DBMS Server sẽ gọi UDF chịu trách nhiệm
tính toán tổng của các giá trị. Tính tổng này sẽ được thực hiện bằng cách sử
dụng đặc tính đồng cấu. Có nghĩa là, các giá trị mã hóa của cột C3-HOM sẽ
được nhân và kết quả sẽ là dạng mã hóa của các bản rõ.

Ở đây, các giá trị là qmdl, ahc0, và h9dj. Giả sử rằng giá trị của phép nhân
là a83g.

(qmdl × ahc0 × h9dj) = a83g

Lưu ý rằng DBMS Server sẽ không thể biết được các giá trị và kết quả vì
mã hóa. Các bản mã được nhân sẽ dẫn đến kết quả một bản mã mới. Proxy
Server sẽ lấy kết quả mã hóa này và sẽ giải mã nó. Giá trị giải mã này sẽ là
tổng của các giá trị bên trong cột Grade nhờ đặc tính đồng cấu.

a83g = Enc (86 + 77 + 95)

nếu Dec là hàm giải mã của Enc có đặc tính đồng cấu thì ta sẽ có:

Dec (a83g) = 86 + 77 + 95

Cuối cùng, phép tính tổng được thực hiện chính xác trên phía DBMS
Server mà không để lộ ra bất kỳ thông tin nào trên dữ liệu. Cụ thể là, DBMS
Server sẽ không thể nhìn thấy các bản rõ, những nó vẫn có thể tính tổng chỉ
bằng cash tính toán phép nhân trên các bản mã.

Thực thi các truy vấn viết. Để hỗ trợ các truy vấn INSERT, DELETE, và
UPDATE, proxy áp dụng cùng một xử lý cho các vị từ (ví dụ, mệnh đề
WHERE) như cho các truy vấn đọc. Các truy vấn DELETE không yêu cầu
thêm xử lý nào khác. Với tất cả các truy vấn INSERT và UPDATE mà thiết
lập giá trị của một cột thành một hằng số, proxy mã hóa từng giá trị của cột
được chèn vào với từng lớp onion mà vẫn chưa được gỡ bỏ trong cột đó.

Các đặc điểm DMBS khác. Hầu hết các cơ chế DMBS khác, như giao
dịch (transaction) và lập chỉ mục (indexing) hoạt động tương tự với CryptDB
trên dữ liệu mã hóa như chúng làm trên bản rõ mà không có sự thay đổi nào.
CryptDB hiện tại không hỗ trợ các thủ tục lưu trữ, mặc dù các thủ tục lưu trữ
nhất định có thể được hỗ trợ bằng cách viết lại mã của chúng theo cùng cách
mà proxy của CryptDB viết lại các câu lệnh SQL.

DBMS xây dựng các chỉ mục cho dữ liệu mã hóa theo cùng một cách như
cho bản rõ. Hiện tại, nếu ứng dụng yêu cầu một chỉ mục (index) trên một cột,
proxy yêu cầu máy chủ DBMS xây dựng các chỉ mục trên các lớp DET, Equi-
JOIN, OPE, hoặc OPE-JOIN onion của cột đó (nếu chúng bị lộ), nhưng không
phải cho RND, HOM, hoặc SEARCH. Các thuật toán lựa chọn chỉ mục hiệu
quả hơn có thể được nghiên cứu.

2.2.7 Tính toán liên kết giữa các cột

Có hai loại liên kết được hỗ trợ bởi CryptDB: equality joins, trong đó vị từ
liên kết được dựa trên equality, và range joins, trong đó liên quan đến các
order check. Để thực hiện một equi-join của hai cột mã hóa, các cột phải được
mã hóa với cùng một khóa để máy chủ có thể thấy các giá trị khớp giữa hai
cột. Tại cùng thời điểm, để cung cấp bảo mật tốt hơn, máy chủ DBMS không
được liên kết các cột mà ứng dụng không yêu cầu liên kết, vì vậy các cột mà
không bao giờ được liên kết không nên được mã hóa với cùng các khóa.

Nếu các truy vấn mà có thể được sinh ra hoặc các cặp cột mà có thể được
liên kết được biết từ trước đó,việc hỗ trợ equi-join rất dễ dàng: CryptDB có
thể sử dụng mã hóa DET với cùng key cho mỗi nhóm của các cột mà được
liên kết với nhau. Tuy nhiên, trường hợp khó khăn là khi proxy không biết tập
các cột được liên kết từ trước đó, và do đó không biết các cột nào phải được
mã hóa với các khóa phù hợp.

Để giải quyết vấn đề này, một cơ sở mật mã mới được giới thiệu, JOIN-
ADJ (adjustable join), cho phép DMBS server điều chỉnh khóa của từng cột
tại thời điểm chạy. JOIN-ADJ có thể được coi như là một băm mật mã được
bảo vệ bằng khóa (keyed cryptographic hash) với các đặc điểm bổ sung mà
các băm có thể được điều chỉnh để thay đổi khóa của chúng mà không cần
truy cập tới bản rõ. JOIN-ADJ là một hàm tất định của các đầu vào của nó, có
nghĩa là nếu hai bản rõ giống nhau, các giá trị JOIN-ADJ tương ứng cũng
bằng nhau. JOIN-ADJ chống được đụng độ (collision-resistant), và có chiều
dài đầu ra đủ dài (192 bit) để cho phép chúng ta thừa nhận rằng các đụng độ
không bao giờ xảy ra trong thực tế.
 Lược đồ mã hóa Equi-JOIN là một chuỗi kết nối Equi-JOIN(v) = JOIN-
ADJ(v)||DET(v). cấu trúc này cho phép proxy giải mã một cột JOIN(v) để thu
được v bằng cách giải mã thành phần DET, và cho phép máy chủ DBMS
kiểm tra hai giá trị Equi-JOIN có bằng nhau không bằng cách so sánh các
thành phần JOIN-ADJ.

Mỗi cột ban đầu được mã hóa tại lớp Equi-JOIN sử dụng khóa khác nhau,
do đó ngăn chặn bất kỳ các liên kết nào giữa các cột. Khi một truy vấn yêu
cầu một liên kết, proxy đưa cho máy chủ DBMS một khóa onion để điều
chỉnh các giá trị JOIN-ADJ trong một hoặc hai cột, để nó phù hợp với khóa
JOIN-ADJ của cột khác (được ký hiệu là cột join-base). Sau khi điều chỉnh,
các cột chia sẻ cùng một khóa JOIN-ADJ, cho phép máy chủ DBMS liên kết
chúng lại với nhau. Các thành phần DET của Equi-JOIN vẫn được mã hóa với
các khóa khác nhau.

Chú ý rằng liên kết điều chỉnh được ở đây có tính bắc cầu: nếu người dùng
liên kết các cột A và B và rồi liên kết cột B và C, máy chủ có thể liên kết A và
C. Tuy nhiên, máy chủ không thể liên kết các cột trong “các nhóm bắc cầu”
khác nhau. Ví dụ, nếu cột D và E được liên kết với nhau, DBMS server không
thể liên kết cột A và D.

Sau một truy vấn liên kết ban đầu, các giá trị JOIN-ADJ vẫn được chuyển
đổi với cùng khóa, vì vậy không cần thiết điều chỉnh lại cho các truy vấn liên
kết đến sau giữa cùng hai cột. Một ngoại lệ là nếu ứng dụng sinh ra truy vấn
khác, liên kết một trong các cột đã được điều chỉnh với một cột thứ ba, sẽ
khiến cho proxy điều chỉnh lại cột sang một join-base khác. Để tránh những
dao động (oscillations) và để hội tụ (converge) tại một trạng thái mà tất cả các
cột trong một nhóm bắc cầu chia sẻ cùng join-base, CryptDB chọn cột đầu
tiên có tên theo thứ tự từ điển trong bảng là join-base. Với n cột, số lượng
tổng thế tối đa của các chuyển đổi join là n(n-1)/2.

Đối với các range join, một lược đồ tái điều chỉnh động tương tự là khó
khăn để xây dựng do thiếu sót cấu trúc trong các lược đồ OPE. Thay vào đó,
CryptDB yêu cầu cặp cột đó mà sẽ được liên hệ với nhau bằng các liên kết
được ứng dụng khai báo trước, do đó các key phù hợp được sử dụng cho lớp
OPE-JOIN của các cột đó; nếu không, cùng một key sẽ được sử dụng cho tất
cả các cột tại lớp OPE-JOIN. May mắn thay, các range join hiếm khi xuất
hiện.
Cấu trúc JOIN-ADJ. Thuật toán được sử dụng để mã hóa là đường cong
elliptic (elliptic-curve cryptography - ECC). JOIN-ADJ K(v) được tính toán
như sau:

Với K là khóa khởi tạo cho bảng, cột, onion và lớp đó, P là một điểm trên
một đường cong elliptic (là một tham số public), và PRFK0 là một hàm giả
ngấu nhiên (pseudo-random function) ánh xạ các giá trị tới các số giả ngẫu
nhiên, như AESK0(SHA(v)) chẳng hạn, với K0 là một khóa, khóa này như nhau
cho tất cả các cột và có nguồn gốc từ MK. Các “lũy thừa” (“exponentiation”)
thực tế là sự bổ sung các hình lặp đi lặp lại của các điểm đường cong elliptic;
nó nhanh hơn đáng kể so với lũy thừ RSA.

Khi một truy vấn join cột c và c’, mỗi khóa K và K’ tại lớp join, proxy tính
toán ΔK = K/K’ (trong một nhóm thích hợp) và gửi nó cho máy chủ. Sau đó
với JOIN-ADJK’(v) đã cho (các giá trị JOIN-ADJ từ cột c‟) và ΔK, máy chủ
DBMS sử dụng một UDF để điều chỉnh key trong c’ bằng cách tính :

Bây giờ các cột c và c‟ chia sẻ cùng JOIN-ADJ key, và DBMS có thể thực
hiện một equi-join trên c và c‟ bằng cách lấy bộ phận JOIN-ADJ của JOIN
onion cipertext.

Tại một mức cao hơn, độ an toàn của lược đồ này là máy chủ không thể
suy ra các mối quan hệ liên kết giữa các nhóm của các cột mà không được
yêu cầu bởi các truy vấn liên kết hợp pháp, và lược đồ không để lộ bản rõ.
 CHƯƠNG 3: PHÂN LOẠI DỮ LIỆU VÀ CHIẾN LƯỢC
BẢO MẬT
3.1 Giới thiệu
Dữ liệu là tài nguyên quan trọng cho bất kỳ tổ chức nào. Dữ liệu có thể thuộc
nhiều dạng khác nhau, như dạng số, từ, hình ảnh, v.v. Bảo mật dữ liệu và an ninh
là vấn đề quan trọng cho mọi tổ chức. Dữ liệu kèm theo những đặc tính khác nhau
như độ chính xác, tính hợp lệ, và độ tin cậy, v.v. Được mô tả như bên dưới:
 Độ chính xác: Đề cập tới độ chính xác của dữ liệu được xác định bởi nguồn
gốc. Dữ liệu phải chính xác cho mục đích sử dụng và nên được sử dụng một
lần tại đúng thời điểm.
 Tính hợp lệ: Dữ liệu được ghi lại và sử dụng cho các yêu cầu liên quan.
 Đầy đủ: Dữ liệu được sử dụng phải đầy đủ và hoàn chỉnh.
 Khả năng truy cập: Liên quan tới thời gian và chi phí truy cập dữ liệu
 Tính nhất quán: Đề cập tới sự đồng nhất về mặt nội dung liên quan đến các
thay đổi và giao dịch sử dụng dữ liệu.
Vấn đề bảo mật dữ liệu bao gồm tính bí mật, toàn vẹn, sẵn sàng. Tính bí mật dữ
liệu liên quan tới chính sách bảo mật dữ liệu bao gồm xác thực và quyền truy cập
dữ liệu nhạy cảm. Tính toàn vẹn dữ liệu liên quan tới nội dung dữ liệu. Tính nhất
quán và độ chính xác của dữ liệu là cần thiết để đạt được tính toàn vẹn. Các vấn đề
tính sẵn sàng của dữ liệu liên quan tới việc lưu trữ, quy định về khôi phục thảm
họa và kế hoạch dự phòng.
Mối quan tâm về tính sẵn sàng dữ liệu là một vấn đề quan trọng đối với bất kỳ tổ
chức nào khi chuyển qua đám mây. Các vấn đề bảo mật liên quan tới sự gia tăng
dữ liệu khi chuyển lên đám mây. Kiểm soát người dùng về dữ liệu, cơ chế bảo vệ
dữ liệu được cung cấp và tính sẵn sàng dữ liệu là một vài vấn đề mà người dùng
cần biết trước khi sử dụng đám mây cho việc lưu trữ dữ liệu. Dữ liệu được lưu trữ
trên đám mây nên được bảo vệ từ thảm họa mã độc không mong muốn. Các thảm
họa này có thể là nhân tạo hay tự nhiên.
Phân loại dữ liệu là quá trình xác định mức độ dữ liệu khác nhau và quyết định độ
nhạy cảm của nó. Nó là một hoạt động cần thiết tại các giai đoạn khác nhau như
khi dữ liệu đang được khởi tạo, sửa đổi, lưu trữ, hay vận chuyển. Việc phân loại
dữ liệu xác định mức độ cần được bảo mật và giá trị của dữ liệu đó về tài sản
doanh nghiệp. Phân loại dữ liệu hoàn thành dựa trên các yếu tố khác nhau. Một số
phân loại dữ liệu theo điểm yếu liên quan tới những thứ đã biết. Chúng được công
khai. Một số thì phân loại dữ liệu dựa trên cách nó được tạo, dữ liệu cá nhân người
dùng, mẫu sử dụng của chúng, vv.
Trong tài nguyên dữ liệu môi trường điện toán đám mây là rất quan trọng phụ
thuộc vào doanh nghiệp và mô hình phân phối dịch vụ. Để cung cấp việc kiểm soát
truy cập và xác thực, phân loại dữ liệu dựa trên tiêu chí mức độ an toàn khu vực
mà nhiều tổ chức sử dụng hoặc cung cấp dịch vụ đám mây.
 3.2 Phân loại dữ liệu
Phân loại dữ liệu là quá trình định danh thành phần dữ liệu liên quan tới giá trị của
nó trong doanh nghiệp. Giá trị được định danh dựa trên phạm vi truy cập và sử
dụng của chúng. Hình 3.1 chỉ ra ba loại đặc tính trên dữ liệu phải được phân loại
và có thể cân nhắc các bảo mật phù hợp.

Hình 3. 1 Access Control

Loại này xác định phạm vi truy cập áp dụng trên dữ liệu. Nó bao gồm;
 Frequency of Access: Các thành phần dữ liệu có thể được truy cập thường
xuyên, ít thường xuyên hơn hoặc với một số lần vừa phải. Người sử dụng có
thể quyết định ngưỡng hoặc giới hạn tối đa cho các phạm vi này, có thể phân
loại chúng dựa trên một trong ba giá trị.
 Frequency of Update: Cập nhật dữ liệu có thể được lặp lại.
 Visibility and Accessibility: Dữ liệu có thể được phân loại dựa trên vùng
truy cập và hiển thị. Nó có thể lấy giá trị giới hạn đối với một số tiêu chí
hoặc cho tất cả. Tiêu chí giới hạn có thể được xác định bởi dữ liệu chủ sở
hữu và tổ chức sử dụng nó.
 Retention: Một trong những tham số để phân loại dữ liệu có thể là khoảng
thời gian lưu trữ dữ liệu có sẵn trong hệ thống.
3.2.2 Content
Nội dung dữ liệu có các thuộc tính liên quan đến các sửa đổi của nó. Nội dung dữ liệu có
một vài thuộc tính và có thể được phân loại như sau.
 Precision/ Accuracy: Độ chính xác của dữ liệu có thể được sử dụng để phân
loại như là cao, thấp hoặc tệ. Nội dung độ chính xác cao là điều mong muốn
đối với một số thành phần dữ liệu.
  Reliability/ Validity: Phụ thuộc vào độ chính xác, khả dụng và tính hợp lệ
của dữ liệu được xác định. Có thể lấy giá trị như thấp, trung bình và cao.
 Degree of Completeness: Đối với một số thành phần dữ liệu, độ hoàn thiện
có thể được sử dụng để phân loại. Nó có thể là bắt buộc hoặc tùy chọn nếu
dữ liệu được chọn là đầy đủ.
 Consistency: Tính nhất quán dữ liệu mô tả độ chính xác của dữ liệu tại bất
kỳ thời điểm nào. Với một số trường hợp tính nhất quán dữ liệu là bắt buộc,
trong khi một số trường hợp khác thì không yêu cầu.
 Auditability: Như đối với tính nhất quán, một số dữ liệu được kiểm toán và
một số thì không. Điều này làm cho khả năng kiểm toán có thể hoặc không
để phân loại các mục dữ liệu.
3.3.3 Storage
Chính sách lưu trữ dữ liệu có thể được áp dụng dựa trên tiêu chí và ràng buộc được áp
dụng cho các loại khác nhau.
 Storage-encryption: Mã hóa dữ liệu dựa trên kích thước của khóa mã. Như
mức độ bảo mật yêu cầu cho sự gia tăng dữ liệu, nó sẽ yêu cầu khóa có kích
thước lớn. Vì sẽ cần nhiều thời gian để phá khóa có kích thước lớn do đó
bảo mật hơn.
 Communication-encryption: Dữ liệu di chuyển tới hoặc từ hệ thống cũng dễ
bị rò rỉ và nghe lén. Một giao tiếp mã hóa nên được bổ sung cho những mục
dữ liệu giới hạn và nhạy cảm.
 Integrity: Tính toàn vẹn dữ liệu là vấn đề quan trọng và phải được giải quyết
bằng thuật toán băm như MD5, SHA, v.v. Nó cũng ứng dụng dựa trên yêu
cầu mức độ bảo mật đạt được cho các thành phần dữ liệu xác định.
 Access Control: Một chính sách kiểm soát truy cập định nghĩa trước phải
được liên kết với các thành phần dữ liệu khác nhau. Vai trò dựa trên kiểm
soát truy cập cho người dùng khác nhau và các đặc quyền phải được xác
định dựa trên chính sách và phạm vi hướng dẫn.
 Backup and recovery plan: Kế hoạch sao lưu cho lưu trữ là yêu cầu cơ bản
cho mục đích thảm họa và phục hồi.
 Data Quality Standards: Các tiêu chuẩn khác nhau để xác nhận dữ liệu dữ
liệu cũng được người dùng mong muốn tại thời điểm phân loại dữ liệu. Tiêu
chuẩn chất lượng dữ liệu làm tăng tính bảo mật của dữ liệu được lưu trữ
trong hệ thống.
 TÀI LIỆU THAM KHẢO
[1]. Rajkumar Buyya, Christian Vecchiola, S. Thamarai Selvi. Masterting
Cloud Computing – Foundations and Applications Programming.
[2]. Raluca Ada Popa, Catherine M. S. Redfield, Nickolai Zeldovich, Hari
Balakrishnan. CryptDB: Protecting Confidentiality with Encrypted Query
Processing. In Proceedings of the 23rd ACM Symposium on Operating
Systems Principles (SOSP), Cascais, Portugal, October 2011.
[3]. Carlo Curino, Evan P. C. Jones, Raluca Ada Popa, Nirmesh Malviya,
Eugene Wu, Sam Madden, Hari Balakrishnan, Nickolai Zeldovich. Relational
Cloud: A Database-as-a-Service for the Cloud. In Proceedings of the 5th
Biennial Conference on Innovative Data Systems Research (CIDR 2011),
Pacific Grove, CA, January 2011.
[4]. Raluca Ada Popa, Frank H. Li, Nickolai Zeldovich. An Ideal-Security
Protocol for Order-Preserving Encoding. In Proceedings of the 34th IEEE
Symposium on Security and Privacy (IEEE S&P/Oakland), San Francisco,
CA, May 2013.
[5]. Stephen Tu, M. Frans Kaashoek, Samuel Madden, Nickolai Zeldovich.
Processing Analytical Queries over Encrypted Data. In Proceedings of the
39th International Conference on Very Large Data Bases (VLDB), Riva del
Garda, Italy, August 2013.
[6]. Raluca Ada Popa, Nickolai Zeldovich. Cryptographic treatment of
CryptDB's Adjustable Join. Technical Report MIT-CSAIL-TR-2012-006,
Computer Science and Artificial Intelligence Laboratory, Cambridge, MA,
March 2012.
[7]. S. Halevi and P. Rogaway. A tweakable enciphering mode. In
Advances in Cryptology (CRYPTO), 2003.
[8]. A. Boldyreva, N. Chenette, Y. Lee, and A. O‟Neill. Order preserving
symmetric encryption. In Proceedings of the 28th Annual International
Conference on the Theory and Applications of Cryptographic Techniques
(EUROCRYPT), Cologne, Germany, April 2009.
[9]. M. Cooney. IBM touts encryption innovation; new technology performs
calculations on encrypted data without decrypting it. Computer World, June
2009.[10]. P. Paillier. Public-key cryptosystems based on composite degree
residuosity classes. In Proceedings of the 18th Annual International
Conference on the Theory and Applications of Cryptographic Techniques
(EUROCRYPT), Prague, Czech Republic, May 1999.
[11]. D. X. Song, D. Wagner, and A. Perrig. Practical techniques for
searches on encrypted data. In Proceedings of the 21st IEEE Symposium on
Security and Privacy, Oakland, CA, May 2000.