1. MỤC LỤC
LỜI NÓI ĐẦU...........................................................................................................3
Chương I: Nghiên cứu và tìm hiểu chung về vấn đề an toàn trong SQL Server 2012
...................................................................................................................................5
1.1An toàn máy chủ và an toàn mạng.......................................................................5
1.2An toàn bên trong SQL Server.............................................................................8
1.3Bảo vệ dữ liệu mức phân quyền truy cập...........................................................12
1.4Bảo vệ dữ liệu bằng phương pháp mã hóa.........................................................14
Chương II: Nghiên cứu và tìm hiểu cơ chế mã hóa dữ liệu trong SQL Server 2012
.................................................................................................................................17
2.1Kiến trúc phân cấp khóa trong SQL Server 2012...............................................17
2.2Quá trình tạo và sử dụng khóa trong SQL Server 2012.....................................20
2.2.1Khóa chủ dịch vụ (Service Master Key – SMK).............................................20
2.2.2Khóa chủ cơ sở dữ liệu (Database Master Key - DMK).................................22
2.2.3Tạo và sử dụng khóa mã đối xứng...................................................................24
2.2.4Tạo và sử dụng các khóa phi đối xứng............................................................28
2.2.5Tạo và sử dụng các chứng chỉ.........................................................................29
2.3Quá trình thực hiện mã hóa dữ liệu....................................................................35
2.3.1Mã hóa dữ liệu với các khóa đối xứng............................................................35
2.3.2Mã hóa dữ liệu với các khóa phi đối xứng và chứng chỉ.................................38
2.4Quá trình thực hiện mã hóa dữ liệu sử dụng TDE..............................................40
Chương III: Thực hiện demo việc mã hóa dữ liệu trong SQL Server.....................42
3.1Demo áp dụng mã hóa dữ liệu mức cột..............................................................42

2. 3.2 Demo áp dụng công nghệ mã hóa dữ liệu trong suốt - TDE.............................51
KẾT LUẬN.............................................................................................................56
TÀI LIỆU THAM KHẢO.......................................................................................58

3. LỜI NÓI ĐẦU
Thông tin được xem là tài sản vô giá và cần được bảo vệ bằng mọi cách. Với sự
phát triển hiện nay, yêu cầu chia sẻ thông tin qua các phương tiện truyền thông hay
Internet ngày càng tăng cao, điều này thúc đẩy việc bảo vệ thông tin ngày càng trở
nên cấp thiết.
Hầu hết các doanh nghiệp hay các nhà quản lý hiện nay đều sử dụng 1 hệ quản trị
cơ sở dữ liệu để lưu trữ tập trung tất cả thông tin của mình. Điều này đồng nghĩa
với việc hệ thống này sẽ là tiêu điểm của các kẻ tấn công. Ở mức độ nhẹ, các tấn
công có thể dẫn đến việc hỏng hệ thống cơ sở dữ liệu, làm cho hệ thống hoạt động
không ổn định, mất mát dữ liệu gây ra tổn thất cho các doanh nghiệp. Nghiêm
trọng hơn, các thông tin mật có thể bị tiết lộ và được đem bán cho các doanh
nghiệp đối thủ. Vì vậy việc đảm bảo an toàn và bảo mật cho hệ quản trị CSDL là
vô cùng quan trọng .
Một số hệ quản trị mà chúng ta thường gặp như MySQL Server, Oracle Database
Server, Microsoft SQL Server. Các hệ quản trị cơ sở dữ liệu cung cấp các cơ chế,
các quy tắc đảm bảo tính an toàn cho hệ quản trị của mình. Các nhà thiết kế và
phát triển ứng dụng cơ sở dữ liệu cần phải hiểu và nắm được các nguyên tắc đó để
làm sao trong quá trình thiết kế và xây dựng chương trình cần đảm bảo vấn đề an
toàn cho ứng dụng, an toàn cho dữ liệu trong cơ sở dữ liệu. Bất kỳ người dùng
không hợp lệ không thể khai thác được dữ liệu trong cơ sở dữ liệu.
Xuất phát từ nhu cầu thực, trong phạm vi của đề tài, chúng tôi đi vào nghiên cứu,
tìm hiểu một số vấn đề liên quan đến việc bảo đảm an toàn trong SQL Server 2012:

4. • Tìm hiểu các vấn đề chung liên quan đến việc đảm bảo an toàn cho hệ thống
khai thác cơ sở dữ liệu
• Nghiên cứu tìm hiểu vấn đề bảo đảm an toàn cho cơ sở dữ liệu bằng các
phương pháp mã hóa
• Tạo kịch bản demo áp dụng các phương pháp mã hóa trong SQL Server
Báo cáo của đề tài được trình bày gồm các phần sau:
Chương I: Nghiên cứu và tìm hiểu chung vấn đề an toàn trong hệ quản trị SQL
Server 2012. Trong chương này chúng tôi tìm hiểu các nguyên tắc cơ bản để đảm
bảo an toàn cho SQL Server 2012 bắt đầu từ khi được cài đặt lên máy chủ. An toàn
xác thực người dùng đăng nhập. Bảo vệ dữ liệu trong cơ sở dữ liệu dựa vào cơ chế
phân quyền trong hệ quản trị. Bảo vệ dữ liệu bằng cách áp dụng phương pháp mã
hóa dữ liệu.
Chương II: Nghiên cứu và tìm hiểu cơ chế mã hóa trong SQL Server 2012. Trong
chương này chúng tôi làm rõ hơn quá trình thực hiện mã hóa dữ liệu. Nắm được
kiến trúc phân cấp và quản lý khóa mã trong SQL Server 2012. Cách tạo khóa mã
và sử dụng nó để thực hiện mã hóa dữ liệu theo yêu cầu
Chương III: Thực hiện demo mã hóa dữ liệu trong SQL Server. Trong chương này
chúng tôi sẽ đưa ra kịch bản đơn giản để thấy được ý nghĩa của vấn đề mã hóa dữ
liệu. Áp dụng các kiến thức ở phần trước để thực hiện lập trình và mô phỏng quá
trình bảo vệ dữ liệu trong cơ sở dữ liệu.

5. Chương I: Nghiên cứu và tìm hiểu chung về vấn đề an toàn trong SQL Server
2012
1.1 An toàn máy chủ và an toàn mạng
• Lựa chọn tài khoản để chạy SQL Server: SQL Server là một dịch vụ
Windows, một tiến trình được khởi động bởi hệ điều hành Windows đang
chạy dưới quyền của người dùng hoặc tài khoản hệ thống. Chọn một tài
khoản đúng là rất quan trọng cho vấn đề an toàn. Vì những máy khách truy
cập SQL Server bằng kết nối cơ sở dữ liệu có thể truy cập vào hệ điều hành
Windows trong một vài trường hợp, hoặc nếu như một lỗ hổng an toàn được
tìm thấy trong mã lệnh SQL. SQL Server không cần phải có quyền quản trị
trên máy tính, nó chỉ cần có quyền trên các thư mục nơi nó được lưu trữ dữ
liệu của nó, các file log lỗi, sao lưu, và một số quyền hệ thống.
• Mã hóa phiên với SSL: Giữa máy khách và máy SQL Server, các câu truy
vấn và các dữ liệu kết quả được gửi đi trên mạng mà con người có thể đọc
được bằng cách sử dụng các công cụ bắt gói tin như Wireshark. Để bảo vệ
thông tin này khỏi bị nghe nén trên mạng thì chúng ta cần phải mã hóa
đường truyền thông giữa client và server bằng cách sử dụng SSL (Security
Socket Layer)
• Cấu hình firewall cho truy cập SQL Server: SQL Server trả lời trên cổng
TCP và UDP cụ thể, mà cần phải được mở trên firewall nếu muốn truy cập
vào SQL Server.

6. • Cấm dịch vụ SQL Server Browser: Dịch vụ SQL Server Browser khởi động
tự động khi cài đặt SQL Server. Nhiệm vụ của nó là để giao tiếp với các thể
hiện SQL Server trên máy tính, và gửi cho máy khách cổng TCP mà thể hiện
đó đang lắng nghe. Để che giấu sự hiện diện của một thể hiện SQL Server,
chúng ta có thể dừng nó hoặc cấu hình để nó không đáp ứng các yêu cầu
quảng bá.
• Đóng tất cả các dịch vụ không sử dụng: Nếu cài đặt trọn gói SQL Server,
chúng ta có thể có các thành phần không cần thiết chạy trên máy chủ, do đó
xuất hiện nhiều rủi ro an toàn và làm giảm hiệu suất máy chủ. Ngoài ra còn
có một số dịch vụ khác của Windows chạy trên máy chủ mà chúng ta có thể
vô hiệu hóa một cách an toàn, đặc biệt là trên một máy chủ dành riêng cho
SQL Server
• Sử dụng mã hóa cơ sở dữ liệu trong suốt: Kẻ tấn công có quyền đọc trên thư
mục SQL Server lưu trữ các tập tin dữ liệu của nó (.mdf) sẽ không gặp khó
khăn để đạt được quyền truy cập vào tất cả các cơ sở dữ liệu, chỉ đơn giản
bằng cách sao chép các tệp .mdf và gắn nó vào một SQL Server, nơi hắn có
quyền quản trị hệ thống. Bảo vệ đầu tiên chống lại mối đe dọa này tất nhiên
là quản lý quyền NTFS chặt chẽ trên các thư mục dữ liệu SQL Server. Để
đảm bảo an toàn hơn nữa cho cơ sở dữ liệu, chúng ta có thể sử dụng phương
pháp mã hóa cơ sở dữ liệu trong suốt (Transparent Database Encryption TDE) để mã hoá tất cả các file dữ liệu (một cơ sở dữ liệu có thể bao gồm
một hoặc nhiều tập tin dữ liệu). Kẻ tấn công cố gắng gắn tệp dữ liệu đó vào
một SQL Server khác sẽ không thể giải mã chúng bởi vì không có khóa để
giải mã.

7. • An toàn truy cập máy chủ liên kết: Tính năng Linked Server cho phép chúng
ta định nghĩa bên trong SQL Server, một kết nối đến một máy chủ khác mà
có thể được tham chiếu trong mã T -SQL để truy cập nguồn dữ liệu ở xa.
Với tính năng này, chúng ta có thể tạo ra các truy vấn phân phối hoặc trao
đổi dữ liệu bằng các cách của câu truy vấn (INSERT … SELECT). Giống
như việc lưu trữ chuỗi kết nối trong ứng dụng client, nhưng ứng dụng client
này là một SQL Server. Một máy chủ liên kết có thể tham chiếu tới một
SQL Server ở xa, hoặc bất kỳ nguồn dữ liệu khác có trình điều khiển
OLEDB được cài đặt trên máy SQL Server. Khi chúng ta tạo ra một máy
chủ liên kết, cần phải nhận thức được một số vấn đề bảo mật liên quan.
• Cấu hình an toàn điểm đầu cuối (endpoint): Một điểm đầu cuối SQL Server
là một cửa được mở ra từ hoặc đến SQL Server. Tất cả mọi thứ mà có thể đi
từ SQL Server tới mạng, hoặc từ mạng đến SQL Server, đều đi qua một
điểm đầu cuối. Điểm đầu cuối này có thể là hệ thống hoặc người dùng định
nghĩa. Các điểm đầu cuối hệ thống cho phép các kết nối T-SQL tới SQL
Server để gửi các truy vấn. Chúng ta có thể tạo ra một điểm đầu cuối cho ba
mục đích: Các yêu cầu TCP, service broker, hoặc phản chiếu cơ sở dữ liệu.
Ví dụ chúng ta sử dụng để tạo thiết lập một kết nối chuyên dụng và an toàn
tới SQL Server cho mục đích quản trị hoặc truy cập từ xa.
• Hạn chế các tính năng: Một số tính năng bị vô hiệu hóa trong quá trình cài
đặt SQL Server vì chúng có thể làm xuất hiện các rủi ro mất an toàn.

8. 1.2 An toàn bên trong SQL Server
• Lựa chọn phương pháp xác thực của Windows và SQL Server: Trong quá
trình cài đặt, SQL Server yêu cầu kiểu xác thực để cấu hình. Phương pháp
xác thực Windows mặc định được lựa chọn và là thiết lập được khuyến cáo.
Nó đơn giản hoá quản trị và an toàn hơn, bởi vì nó sử dụng thẻ an toàn
Windows. Người dùng không phải nhớ mật khẩu khác, và không phải truyền
mật khẩu qua mạng khi kết nối với SQL Server. Chúng ta không thể vô hiệu
hóa xác thực Windows, nhưng chỉ chọn để mở rộng nó với xác thực SQL
Server (Windows và SQL Server, còn được gọi là phương pháp xác thực hỗn
hợp). Chúng ta nên sử dụng xác thực SQL Server chỉ khi cần phải cho phép
truy cập từ người dùng bên ngoài mạng cục bộ và các miền Windows tin
cậy.
• Tạo các tài khoản đăng nhập: Một thông tin đăng nhập là một tài khoản
được định nghĩa ở cấp server với các quyền hạn được gán để kết nối và có
thể thực hiện nhiệm vụ quản trị, và để truy cập cơ sở dữ liệu trên các thể
hiện. Tạo ra thông tin đăng nhập là bước đầu tiên để cấp quyền truy cập
trong SQL Server. Mô hình an toàn SQL Server có hai mức: mức server và
mức cơ sở dữ liệu. Một thông tin đăng nhập đầu tiên phải được tạo ra ở
mức server , và sau đó, cho phép truy cập đến một cơ sở dữ liệu, một người
dùng phải được tạo ra trong cơ sở dữ liệu và được ánh xạ tới một thông tin
đăng nhập đang tồn tại.
• Bảo vệ server chống lại các tấn công brute-force: Tấn công brute-force là
một cách để crack mật khẩu đăng nhập SQL bằng cách cố gắng mọi kết hợp
ký tự có thể, hoặc bằng cách sử dụng một từ điển một danh sách từ, có chứa
các mật khẩu có thể xảy ra nhất. Cách tốt nhất để bảo vệ mật khẩu của chống

9. lại tấn công brute-force là để thi hành chính sách mật khẩu Windows và hết
hạn, vì điều này sẽ đảm bảo rằng chúng ta chỉ có mật khẩu mạnh.
• Giới hạn các quyền admin của tài khoản SA: Tài khoản sa là quản trị hệ
thống máy chủ SQL Server. Nó được tạo ra lúc cài đặt. Trước đây đó là một
đăng nhập cố định mà chúng ta không thể thay đổi, nhưng kể từ SQL Server
2005, chúng ta có thể đổi tên và vô hiệu hóa nó để ngăn chặn nó được sử
dụng bởi kẻ tấn công
• Sử dụng các vai trò server đã được cố định: Thông tin đăng nhập cho phép
bạn kết nối tới SQL Server và để truy cập cơ sở dữ liệu khi chúng được ánh
xạ tới người dùng cơ sở dữ liệu. Mặc định chúng không quyền thực hiện các
thao tác quản trị mức server như quản lý các thông tin đăng nhập khác hoặc
thay đổi cấu hình server. Nếu chúng ta muốn cho phép đăng nhập để có
quyền quản trị, chúng ta có thể cung cấp cho nó những đặc quyền hoặc là
thêm chúng vào vai trò máy chủ cố định đã xác định trước. Các vai trò
server cố định cho phép chúng ta dễ dàng thu hồi hoặc cấp một số tập quyền
chung.
• Tạo và sử dụng các vai trò server được người dùng định nghĩa: Một vai trò
server do người dùng định nghĩa là tiện dụng trong việc cấp một nhóm các
thông tin đăng nhập cho một số quyền quản trị, bởi vì nó giúp chúng ta tiết
kiệm khỏi phải áp dụng các quyền riêng lẻ cho mỗi thông tin đăng nhập.
Chúng ta có thể tạo ra một vai trò người dùng xác định, cấp quyền truy cập
vào nó, và thêm các thông tin đăng nhập mong muốn là thành viên vai trò.
Các quyền server có thể được cấp cho một vai trò, ví dụ quyền kết nối tới
một điểm đầu cuối, giả mạo đăng nhập khác (có nghĩa là, để thay đổi ngữ

10. cảnh của nó với EXECUTE AS), hoặc kiểm soát một số thông tin đăng nhập
khác.
• Tạo người dùng cơ sở dữ liệu và ánh xạ tới thông tin đăng nhập: Các thông
tin đăng nhập đảm bảo xác thực và truy cập vào tài nguyên máy chủ. Để truy
cập vào một cơ sở dữ liệu, chúng phải ánh xạ tới một người dùng trong cơ
sở dữ liệu. Truy cập vào các đối tượng cơ sở dữ liệu được cấp cho người
dùng, không áp dụng cho thông tin đăng nhập. dbo là viết tắt của DataBase
Owner. Đây là một người sử dụng cơ sở dữ liệu đặc biệt mà ánh xạ tới chủ
sở hữu của cơ sở dữ liệu. Khi được tạo ra, cơ sở dữ liệu được chỉ định một
chủ sở hữu, đó là tên đăng nhập đã tạo ra nó.
• Ngăn chặn thông tin đăng nhập và người dùng xem siêu dữ liệu: Trước SQL
Server 2005, tất cả các máy chủ và siêu dữ liệu cơ sở dữ liệu là mọi người
đều có thể nhìn thấy. Đó là một vấn đề, ví dụ, các công ty web-hosting
người chia sẻ một thể hiện SQL Server với khách hàng. Tất cả mọi người có
thể nhìn thấy sự hiện diện của cơ sở dữ liệu khách hàng khác trên máy chủ.
Bây giờ chúng ta có thể kiểm soát sự xuất hiện các siêu dữ liệu. Nếu như
chúng ta muốn ẩn các cơ sở dữ liệu đối với tất cả các thông tin đăng nhập,
thì loại bỏ quyền VIEW ANY DATABASE khỏi vai trò server công khai
• Chỉnh sửa các lỗi ánh xạ người dùng tới thông tin đăng nhập trên cơ sở dữ
liệu được khôi phục: Nếu chúng ta di chuyển một cơ sở dữ liệu từ một máy
chủ này sang một máy chủ khác, bằng các cách backup/restore hoặc
detach/attach, sau đó có một dịp nào đó người dùng SQL của bạn sẽ trở
thành mồ côi (orphaned), có nghĩa là họ sẽ không có thông tin đăng nhập
tương ứng. Như ánh xạ giữa tên đăng nhập và người sử dụng được thực hiện
bởi SID, nếu đăng nhập xuất hiện trên thể hiện SQL Server đích có cùng tên
nhưng khác SID, thì người dùng này sẽ lỗi và hệ thống không nhận ra.

12. 1.3 Bảo vệ dữ liệu mức phân quyền truy cập
• Hiểu và quyền: Một hệ thống quản lý dữ liệu quan hệ , chẳng hạn như SQL
Server , không chỉ là đáp ứng lưu trữ và truy xuất dữ liệu , mà còn đảm bảo
sự gắn kết của nó và bảo vệ nó. Giống như hệ thống máy chủ khác , nó xác
thực người sử dụng và duy trì một phiên mà người dùng đó sẽ có thể truy
cập dữ liệu, nếu người này được phép. SQL Server sẽ kiểm tra những quyền
trong mỗi lần đọc hay ghi dữ liệu . Các quyền hạn được thiết lập bởi các câu
lệnh ngôn ngữ kiểm soát dữ liệu (Data Control Language - DCL). DCL là
một tập con của ngôn ngữ SQL được sử dụng để kiểm soát việc truy cập dữ
liệu. Có 3 trạng thái có thể của quyền hạn
o GRANT: Quyền được cho phép
o DENY: Quyền bị từ chối
o REVOKE: Xóa bỏ việc cấp hoặc từ chối quyền
Thuật toán kiểm tra quyền trong SQL Server là phức tạp, nhưng nó giúp ta
có chiến lược cấp quyền một cách đơn giản. Các quyền được phân cấp và
bắc cầu. Hệ thống phân cấp của các đối tượng trong SQL Server là như sau:
Server -> Database -> Schema -> Object -> Column
• Gán các quyền mức cột: Các quyền khoản trong SQL Server được phân cấp,
người dùng có quyền trên lược đồ có cùng các quyền trên các đối tượng bên
trong lược đồ, trừ khi từ chối cho cấp phép đã được thực hiện. Nhưng các
đối tượng này không phải là mức thấp nhất của hệ thống. Chúng ta có thể
thiết lập quyền tới cột đó. Để gán các quyền cho cột chúng ta sử dụng lệnh
GRANT SELECT ON <đối tượng>. Quyền mức cột là không phù hợp với
hệ thống phân cấp quyền chính thức và có thể sẽ thay đổi trong các phiên
bản tương lai, chúng ta có thể áp dụng tốt hơn bằng cách sử dụng các view

13. để hạn chế việc truy cập vào cột. Các view cung cấp mức độ trừu tượng để
truy cập bảng, đây là cách linh hoạt hơn so với thiết lập quyền mức cột.
• Quản lý quyền sở hữu đối tượng: Mặc định, chủ sở hữu đối tượng là chủ sở
hữu của lược đồ thuộc về nó. Chủ sở hữu này có tất cả các quyền đối với đối
tượng, và không thể phủ nhận. Để thiết lập quyền sở hữu đối tượng chúng ta
sử dụng lệnh ALTER AUTHORIZATION. Chúng ta muốn thay đổi quyền
sở hữu khi người dùng cần loại bỏ hoặc khi cần chỉnh sửa một số vấn đề về
sở hữu đối tượng. Tất nhiên, chuyển quyền sở hữu đòi hỏi phải có các quyền
hạn thực hiện điều này vì hai lý do. Thứ nhất, một người nào đó không được
phép ăn cắp một đối tượng, và thứ hai là chủ sở hữu của một đối tượng
không được phép để chuyển nó cho những người không muốn nó.
• Bảo vệ dữ liệu thông qua view và thủ tục lưu trữ: Khi chúng ta tham chiếu
một đối tượng trong một view hoặc một đối tượng code, chẳng hạn như một
thủ tục lưu trữ hoặc một hàm, thì các quyền có thể được thiết lập trên view
hoặc thủ tục, và loại bỏ quyền trên các đối tượng được tham chiếu. Điều này
cho phép bảo vệ các bảng dữ liệu bên dưới chống lại các truy vấn trực tiếp
lên bảng. Chúng ta cần phải hiểu được cách thức hoạt động để thực hiện nó
một cách chính xác.
• Cấu hình an toàn cross-database: Chuỗi các quyền sở hữu (ownership
chaining) cho phép cấp quyền chỉ trên view hay các thủ tục và cấp quyền
cho các các đối tượng bên dưới, điều này mặc định được giới hạn trong một
cơ sở dữ liệu. Nếu chúng ta tham chiếu một đối tượng từ một cơ sở dữ liệu
khác trong view hoặc thủ tục, thì người dùng phải là một người sử dụng
trong cơ sở dữ liệu đó, và có quyền truy cập vào đối tượng này. Đây là cách
an toàn được lựa chọn tốt nhất. Nếu cơ sở dữ liệu của chúng ta được liên kết

14. chặt chẽ, chúng ta có thể cho phép chuỗi sở hữu chéo cơ sở dữ liệu (crossdatabase ownership chaining).
• Sử dụng EXECUTE AS để thay đổi ngữ cảnh người dùng: Kể từ SQL
Server 2005, chúng ta có thể sử dụng lệnh EXECUTE AS để mạo danh
người dùng khác trong một phiên (dcó ích khi dùng để thử nghiệm các
quyền được gán cho người dùng) hoặc để thực thi một thủ tục. Để thay đổi
ngữ cảnh thực hiện trong phiên, chúng ta có thể dùng lệnh sau đây:
EXECUTE AS LOGIN = 'DOMAINFred';
EXECUTE AS USER = 'Fred';
Lệnh đầu thay đổi ngữ cảnh được giả mạo một tài khoản đăng nhập mà được
gán quyền mức server, trong khi đó lệnh thứ hai thay đổi ngữ cảnh chỉ liên
quan đến cơ sở dữ liệu hiện tại và không cho đưa cho người gọi quyền mức
server. Chúng ta sẽ không thể chạy các lệnh bên ngoài của cơ sở dữ liệu
hoặc thay đổi cơ sở dữ liệu hiện tại khi đang trong ngữ cảnh an toàn này.
1.4 Bảo vệ dữ liệu bằng phương pháp mã hóa
Một trong những khó khăn để hiểu các lựa chọn nhất trong SQL Server 2012 là
khả năng mã hóa dữ liệu. Lý do chính là tất cả các khả năng mã hóa khác nhau đều
được cung cấp. Mã hóa dữ liệu có thể được thực hiện bởi hệ điều hành, SQL
Server, hoặc các ứng dụng. Một số tùy chọn mã hóa SQL Server khác nhau.
• Mã hóa dữ liệu trong suốt (Transparent Data Encryption - TDE) là tùy chọn
mã hóa chính trong SQL Server. Lần đầu tiên TDE có sẵn trong SQL Server
2008, SQL Server 2012 và nó chỉ có trong các phiên bản SQL Server
Enterprise. TDE cho phép chúng ta mã hóa toàn bộ một cơ sở dữ liệu. Các
bản sao lưu cơ sở dữ liệu sử dụng TDE cũng được mã hóa. TDE bảo vệ phần
dữ liệu ở trên thiết bị lưu trữ, có nghĩa là các file của cơ sở dữ liệu và các

15. file log được mã hóa bằng thuật toán AES và 3DES. TDE là hoàn toàn trong
suốt với các ứng dụng và không đòi hỏi phải sửa đổi mã lệnh để thực hiện.
• Mã hóa mức cột (Column-level): Mã hóa mức cột (hay còn gọi là mã hóa
mức ô – cell-level) đã được đưa ra trong SQL Server 2005 và có sẵn trong
tất cả các phiên bản của SQL Server. Để sử dụng mã hóa mức ô, các lược đồ
phải thay đổi tới kiểu nhị phân (varbinary), sau đó chuyển đổi lại về kiểu dữ
liệu mong muốn. Điều này có nghĩa là các ứng dụng phải sửa đổi để hỗ trợ
việc mã hóa, giải mã, ngoài ra nó có thể ảnh hưởng đến hiệu năng. Mã hóa
cơ sở dữ liệu xảy ra ở mức trang, nhưng khi các trang được đọc đến pool
đệm thì chúng được giải mã. Dữ liệu có thể được mã hóa bằng cách sử dụng
mật khẩu, khóa bất đối xứng, khóa đối xứng, hoặc chứng chỉ. Các thuật toán
hỗ trợ cho việc mã hóa mức cột là AES với 128, 196, 256 bit khóa và 3DES.
• Mã hóa và giải mã dữ liệu với .NET Framework:. Một tùy chọn khác cho
việc mã hóa dữ liệu được lưu trữ trong SQL Server là thực hiện việc mã hóa
và giải mã từ bên trong ứng dụng. Tất cả các phiên bản của SQL Server hỗ
trợ kiểu mã hóa dữ liệu này. Tuy nhiên, không giống như TDE, mã hóa dữ
liệu trong ứng dụng yêu cầu chúng ta phải viết code ứng dụng để thực hiện
mã hóa bằng cách gọi cách hàm mã hóa và giải mã trong .NET Framework,
bằng cách sử dụng không gian tên System.Security.Cryptography để thực
hiện mã hóa đối xứng hoặc bất đối xứng.
• Mã hóa hệ thống tập tin (Encrypting File Systems - EFS): Phương pháp này
là một tính năng mã hóa file được giới thiệu trong Windows 2000. Windows
Server hỗ trợ EFS để mã hóa dữ liệu vào file và cấp độ thư mục. EFS sử
dụng thuật toán mã hóa AES, ECC và mã hóa dựa vào smartcard. Cài đặt
một cơ sở dữ liệu SQL Server trong EFS trên thực tế là không được đề nghị
vì tăng thêm các chi phí. EFS không được tối ưu hóa cho hiệu suất, và tất cả

16. các thao tác vào/ra là đồng bộ. Nếu chúng ta sử dụng EFS, các tập tin cơ sở
dữ liệu được mã hóa dưới danh tính của các tài khoản đang chạy SQL
Server. Nếu chúng ta thay đổi tài khoản chạy dịch vụ SQL Server, trước tiên
cần phải giải mã các tập tin bằng cách sử dụng tài khoản cũ, sau đó mã hóa
lại chúng bằng cách sử dụng tài khoản mới.
• BitLocker: Đây là một tính năng bảo vệ dữ liệu có sẵn trong Windows
Server 2012, Windows 8, Windows 7 và Windows Server 2008 R2.
BitLocker thực hiện bảo vệ dữ liệu bằng cách mã hóa tất cả các dữ liệu trên
phân vùng của hệ điều hành Windows.

17. Chương II: Nghiên cứu và tìm hiểu cơ chế mã hóa dữ liệu trong SQL Server
2012
Vấn đề bảo vệ dữ liệu nhạy cảm là mối quan tâm quan trọng đối với các tổ chức.
Số thẻ tín dụng, hồ sơ y tế và sức khỏe, và các thông tin cá nhân khác phải được
lưu trữ và bảo đảm theo một cách mà chỉ có nhân viên được ủy quyền mới có thể
truy cập thông tin. Các phiên bản SQL Server 2000, 2005 vấn đề mã hóa cần phải
được xử lý bởi ứng dụng. SQL Server cung cấp các hàm mã hóa, giải mã dữ liệu
để người phát triển tích hợp. Ngoài ra vấn đề quản lý khóa mã do người phát triển
ứng dụng quản lý thủ công. Từ phiên bản SQL Server 2008, 2012 ngoài kế thừa
giải pháp mã hóa của các phiên bản trước, nó áp dụng một công nghệ mới, đó là
công nghệ mã hóa dữ liệu trong suốt (Transparent Data Encryption - TDE). TDE
cho phép thực hiện mã hóa toàn bộ file cơ sở dữ liệu một cách trong suốt, có nghĩa
là ứng dụng người dùng không phải sửa đổi. TDE chỉ có trong các phiên bản SQL
Server sau:
• SQL Server 2012 Enterprise, Developer, Evaluation
• SQL Server 2008 R2 Datacenter, Enterprise, Developer, Evaluation
• SQL Server 2008 Enterprise, Developer, Evaluation
2.1 Kiến trúc phân cấp khóa trong SQL Server 2012
Trong quá trình tính toán, mã hóa bao gồm việc biến đổi đổi dữ liệu từ dạng rõ và
dễ đọc (được gọi là dạng rõ) thành một giá trị nhị phân phức tạp (được gọi là các
bản mã), bằng một thuật toán mã hóa. Hàm mã hóa sử dụng một khóa để mã hóa
dữ liệu, đó là thông tin xác định kết quả bản mã. Khóa mã đảm bảo rằng các kết

18. quả của việc mã hóa sẽ không chỉ phụ thuộc vào các thuật toán mã hóa. Trong thực
tế khóa là yếu tố quan trọng của mã hóa. Chất lượng của khóa đảm bảo rằng rất
khó để giải mã dữ liệu mà không có khóa, nhưng không giữ bí mật thuật toán và
rất nhiều thuật toán có mã nguồn mở. Nếu như việc mã hóa chỉ dựa vào thuật toán,
nó có thể dễ dàng dịch ngược mã lệnh và crack nó.
Vì vậy , ngay cả khi sức mạnh của thuật toán mã hóa phụ thuộc vào chất lượng và
độ phức tạp của thuật toán, thì yếu tố bí mật thực sự là khóa. Một khóa được người
dùng mật mã tạo ra phải có đủ độ dài để ngăn chặn việc tìm kiếm tất cả các khả
năng có thể của các ký tự. Thông thường, độ dài khóa ngày nay là giữa 128 và
2048 bit. Vì vậy , khóa càng dài , mã hóa càng mạnh, nhưng đây không phải là tiêu
chí duy nhất , bởi vì mã hóa mạnh hơn đòi hỏi cần nhiều tài nguyên hơn. Đặc biệt
là trong các hệ thống cơ sở dữ liệu, hiệu suất của mã hóa và giải mã cần được xem
xét. Trong SQL Server chia ra làm nhiều loại khóa nhằm đáp ứng nhu cầu linh
động trong việc quản lý và an toàn các khóa mã, cũng nhu đảm bảo hiệu năng truy
xuất dữ liệu của toàn hệ thống như:
• Service Master Key - SMK
• Database Master Key DMK
• Khóa bất đối xứng
• Chứng chỉ số
• Khóa đối xứng
Các khóa này sẽ được mô tả cụ thể hơn về các loại khóa này. Dưới đây là hệ thống
phân cấp khóa trong SQL Server 2012:

19. Khóa (Key)
Được bảo vệ bởi
Mật khẩu
Mật khẩu
(Password)
(Password)
Chứng chỉ
Chứng chỉ
(Certificate)
(Certificate)
Chứa
Khóa công khai
Khóa công khai
(Public Key)
(Public Key)
Khóa
Khóa
(Key)
(Key)
Gắn kết với
Khóa bí mật
Khóa bí mật
(Private Key)
(Private Key)
Được bảo vệ bởi
Khóa chủ
Khóa chủ
(Master Key)
(Master Key)
Mật khẩu
Mật khẩu
(Password)
(Password)
Được bảo vệ bởi
DP API
DP API
Service Key
Service Key
Được bảo vệ bởi

20. 2.2 Quá trình tạo và sử dụng khóa trong SQL Server 2012
2.2.1 Khóa chủ dịch vụ (Service Master Key – SMK)
SQL Server cho phép tạo và lưu trữ các khóa mã trong một cơ sở dữ liệu. Bí mật là
ở trong khóa, và điều quan trọng là bảo vệ các khóa này. Cách tốt nhất để làm điều
đó là mã hóa các khóa đó sử dụng khóa khác. Trong SQL Server, khóa này được
gọi là khóa chủ (master key). Mỗi cơ sở dữ liệu sử hữu một khóa chủ, và các khóa
chủ cơ sở dữ liệu được mã hóa bằng một khóa chủ mức server. Các khóa chủ cơ sở
dữ liệu được sử dụng để mã hóa một số thông tin nhạy cảm khác, chẳng hạn như
mật khẩu chúng ta nhập vào trong các tùy chọn kết nối máy chủ liên kết.
Trước khi một khóa có thể được sử dụng trong SQL Server, nó phải được mở ra.
Điều này có nghĩa rằng khóa này được đọc từ một bảng hệ thống và giải mã. Sau
khi sử dụng, khóa này được đóng lại bằng cách sử dụng lệnh CLOSE hoặc khi kết
nối được đóng lại.
SMK được bảo vệ bởi Windows Data Protect API (DPAPI), sử dụng thuật toán
AES (Advanced Encryption Standard) và cả các bằng chứng (credentials) tài khoản
máy và tài khoản dịch vụ. SMK được dùng để bảo vệ các khóa DMK (Database
Master Key ).

21. Khóa SMK là gốc của hệ thống phân cấp mã hóa và được tạo tự động lần đầu khi
SQL Server sử dụng để mã hóa khóa khác.
Điều quan trọng là việc sao lưu khóa SMK này, sử dụng lệnh
BACKUP SERVICE MASTER KEY TO FILE = ‘e:encryption_keyssmk.key’
ENCRYPTION BY PASSWORD = ‘a strong password’ ;
Để khôi phục lại khóa SMK, chúng ta sử dụng lệnh sau:
RESTORE SERVICE MASTER KEY FROM FILE = ‘e:encryption_keyssmk.key’
DECRYPTION BY PASSWORD = ‘a strong password’ FORCE ;
Chúng ta có thể quyết định tạo lại khóa SMK như là một phần trong chính sách an
toàn. Nó sẽ thực hiện giải mã và mã hóa lại các khóa mà được bảo vệ bởi SMK. Sử
dụng lệnh sau để tạo lại khóa SMK
ALTER SERVICE MASTER KEY REGENERATE;

22. 2.2.2 Khóa chủ cơ sở dữ liệu (Database Master Key - DMK)
Khóa DMK phải được tạo bên trong một cơ sở dữ liệu. Chúng ta phải cung cấp
một mật khẩu mà đáp ứng các yêu cầu chính sách mật khẩu Windows của máy tính
đang chạy SQL Server. Hai bản sao của khóa DMK được giữ lại: một bản sao
được lưu trong cơ sở dữ liệu đó, và bản sao còn lại lưu trong cơ sở dữ liệu master.
Khóa DMK được bảo vệ bởi khóa SMK. Điều này cho phép khóa DMK được mở
tự động. Đây là tiện dụng, bởi vì chúng ta không cần mở khóa trong mã lệnh,
nhưng nó cũng có nghĩa là bất kỳ người sử dụng cơ sở dữ liệu có thể sử dụng khóa
này.
Để tạo khóa DMK, thực hiện lệnh sau:
USE marketing ;
CREATE MASTER KEY
ENCRYPTION BY PASSWORD = ‘a very strong password’ ;
Chúng ta có thể xem cơ sở dữ liệu của mình có khóa DMK được mã hóa bởi SMK
bằng cách thực hiện truy vấn sau:
SELECT name, is_master_key_encrypted_by_server
FROM sys.databases
ORDER BY name;
Chúng ta có thể biết cơ sở dữ liệu của mình có DMK bằng cách view
sys.symetric_keys như sau:
SELECT *

23. FROM sys.symmetric_keys
WHERE symmetric_key_id = 101;
Khóa DMK là một khóa đối xứng và nó luôn nhận ID là 101 trong cơ sở dữ liệu.
Nó luôn có tên là ###MS_DatabaseMasterKey###
Điều cần thiết là chúng ta cần sao lưu các khóa mã này, sử dụng lệnh
OPEN MASTER KEY
DECRYPTION BY PASSWORD = ‘a very strong password’ ;
BACKUP MASTER KEY TO FILE = ‘e:encryption_keysdmk.key’
ENCRYPTION BY PASSWORD = ‘new strong password’
CLOSE MASTER KEY ;
Để khôi phục khóa DMK từ file, chúng ta thực hiện lệnh sau:
RESTORE MASTER KEY FROM FILE = ‘e:encryption_keysdmk.key’’
DECRYPTION BY PASSWORD = ‘new strong password’
ENCRYPTION BY PASSWORD = ‘a very strong password’
Để tạo một bản sao của DMK được bảo vệ bằng SMK, và lưu nó trong cơ sở dữ
liệu hiện hành và cơ sở dữ liệu master, thực hiện lệnh

24. ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY ;
Chúng ta có thể muốn hạn chế truy cập chỉ để những người dùng cung cấp mật
khẩu. Để làm điều đó, loại bỏ việc bảo vệ SMK, như thể hiện trong ví dụ sau đây
Để loại bỏ việc bảo vệ DMK bởi SMK, thực hiện lệnh sau:
ALTER MASTER KEY
DROP ENCRYPTION BY SERVICE MASTER KEY;
Để xóa bỏ khóa DMK, thực hiện lệnh sau:
DROP MASTER KEY ;
2.2.3 Tạo và sử dụng khóa mã đối xứng
Để mã hóa dữ liệu trong cột, đầu tiên chúng ta cần phải tạo các khóa mã. SQL
Server cho phép chúng ta định nghĩa 2 kiểu khóa:
•
Khóa đối xứng: Cùng một khóa được sử dụng để mã hóa và giải mã
•
Khóa phi đối xứng: Một cặp khóa được sử dụng. Một khóa công khai (public
key) được dùng để mã hóa và một khóa bí riêng (private key) dùng để giải mã
Mã hóa đối xứng là nhanh hơn mã hóa phi đối xứng, nhưng độ an toàn kém hơn.
Thuật toán mã hóa có thể sử dụng các khóa đối xứng đó là DES, TRIPLE_DES,
TRIPLE_DES_3KEY, RC2, RC4, RC4_128, DESX, AES_128, AES_192,
AES_256.

25. Một lần nữa, sự bí mật của mã hóa nằm ở khóa. Khóa này cần được bảo vệ để ngăn
chặn truy cập không mong muốn. Để bảo vệ khóa, chúng ta mã hóa nó với một
khóa khác hoặc với một mật khẩu mạnh. Một khóa có thể được bảo vệ bởi một số
thao tác mã hóa. Ví dụ, chúng ta có thể mã hóa một khóa đối xứng bởi một mật
khẩu và một khóa phi đối xứng. Sau đó để mở nó, chúng ta cần phải cung cấp chỉ
một trong số chúng. Điều này có ích khi chúng ta cung cấp các phương pháp để
giải mã một số dữ liệu cho người sử dụng khác nhau bằng cách sử dụng cùng khóa,
nhưng với mật khẩu cá nhân. Nếu một người sử dụng sẽ cần bị từ chối truy cập
trong tương lai, chúng ta chỉ phải gỡ bỏ mật khẩu từ khóa đó, như thể hiện trong
đoạn mã sau:
CREATE SYMMETRIC KEY UserSKey
WITH ALGORITHM = AES_256
ENCRYPTION BY PASSWORD = 'Password for Fred',
PASSWORD = 'Password for Mary' ;
OPEN SYMMETRIC KEY UserSKey
DECRYPTION BY PASSWORD = 'Password for Fred' ;
ALTER SYMMETRIC KEY UserSKey
DROP ENCRYPTION BY PASSWORD = 'Password for Fred' ;
CLOSE SYMMETRIC KEY UserSKey ;

26. Đoạn mã trên tạo khóa đối xứng UserSKey với 2 mật khẩu. Mary và Fred sẽ có thể
mở được khóa này bằng cách sử dụng mật khẩu được cung cấp. Để ngăn chặn Fred
mở khóa, một người quản trị (là người biết được mật khẩu của Fred và có quyền
ALTER trên khóa) có thể mở khóa và sử dụng lệnh ALTER SYMMETRIC KEY
để loại bỏ mật khẩu.
View sys.openkeys cho chúng ta biết các khóa được mở cho phiên hiện tại. Khóa
được lưu trong cơ sở dữ liệu mà nó được tạo ra. Để mở và sử dụng khóa, chúng ta
phải ở trong ngữ cảnh cơ sở dữ liệu đó. Nếu chúng ta cố gắng để mở một khóa
trong ngữ cảnh cơ sở dữ liệu sai, thì chúng ta sẽ nhận được một thông báo lỗi
‘object not found’. Nếu chúng ta mở thành công một khóa, sau đó thay đổi ngữ
cảnh cơ sở dữ liệu và cố gắng mã hóa một cái gì đó thì sẽ nhận được kết quả
NULL. Trong mã hóa đối xứng, việc mã hóa và giải mã sử dụng cùng một khóa,
đôi khi chúng ta có thể muốn gửi khóa này đến máy chủ khác để trao đổi các thông
tin được mã hóa. Không có cách nào để sao lưu hoặc trích xuất một khóa đối xứng
tạo ra trong SQL Server vào một tập tin, nhưng chúng ta có thể tạo lại khóa này
trên một máy chủ khác. Để thực hiện điều này chúng ta cung cấp tùy chọn
KEY_SOURCE và IDENTITY_VALUE khi chúng ta tạo khóa như sau:
CREATE SYMMETRIC KEY SKeyToShare WITH
ALGORITHM = AES_256,
KEY_SOURCE = 'a complex passphrase #1',
IDENTITY_VALUE = 'a complex passphrase #2'
ENCRYPTION BY PASSWORD = 'a complex passphrase #3';
Hai khóa đối xứng tạo ra với cùng KEY_SOURCE và IDENTITY_VALUE là
giống hệt nhau, và chúng có thể được sử dụng thay thế cho nhau. Ở đây, chúng ta

27. bảo vệ các khóa bằng mật khẩu, nhưng chúng ta cũng có thể bảo vệ chúng với một
khoá phi đối xứng hoặc chứng chỉ.
Khi chúng ta mở khóa bằng lệnh OPEN SYMMETRIC KEY, khóa này sẽ được
duy trì đến khi chúng ta đóng nó hoặc phiên này kết thúc.
Nếu chúng ta muốn mở một khóa cho một phiên hoặc tất cả các phiên, mà không
cần đặt bất kỳ lệnh nào trong mã lệnh của mã khách hàng thì chúng ta thực hiện
lệnh OPEN SYMMETRIC KEY trong sự kiện kích hoạt đăng nhập. Chúng ta có
thể chèn lệnh OPEN SYMMETRIC KEY trong thủ tục lưu trữ với ngữ cảnh thực
hiện là OWNER hoặc SELF để ẩn mật khẩu từ người dùng. Khóa sẽ được mở ra
trong thủ tục và sẽ duy trì cho đến khi phiên kết thúc. Tất nhiên, việc thực hành an
toàn tốt nhất là không giữ việc mở khóa trong thời gian dài hơn mức cần thiết, và
chèn lệnh OPEN SYMMETRIC KEY trong khối xử lý lỗi try/catch để đảm bảo
rằng các khóa đã được đóng ngay cả trường hợp có lỗi xảy ra, như trong ví dụ sau:
BEGIN TRY
OPEN SYMMETRIC KEY UserSKey
DECRYPTION BY PASSWORD = 'I am for Fred';
/* Thực hiện các công việc tại đây */
……
CLOSE SYMMETRIC KEY UserSKey;
END TRY
BEGIN CATCH
IF EXISTS (SELECT * FROM sys.openkeys WHERE key_name = 'UserSKey')
CLOSE SYMMETRIC KEY UserSKey;
END CATCH

28. 2.2.4 Tạo và sử dụng các khóa phi đối xứng
Một khóa bất đối xứng là một cặp khóa: một khóa công khai mà chỉ có thể mã hóa
dữ liệu, và một khóa riêng chỉ có thể giải mã những gì đã được mã hóa bằng khóa
công khai tướng ứng. Để có các khóa bất đối xứng được mã hóa bằng các khóa
DMK, trước hết chúng ta phải tạo các khóa DMK. Nếu cơ sở dữ liệu không có
khóa DMK, chúng ta vẫn có thể tạo khóa bất đối xứng, nhưng sẽ được bảo vệ bằng
mật khẩu.
Để tạo một khóa bất đối xứng, chúng ta thực hiện các bước sau:
• Tạo khóa bất đối xứng một cách đơn giản nhất, thực hiện lệnh:
CREATE ASYMMETRIC KEY EmployeeSalaryASKey
WITH ALGORITHM = RSA_2048;
Lưu ý rằng, lệnh ở trên chúng ta không cung cấp mật khẩu. Nếu chúng ta tạo
một khóa bất đối xứng mà không cung cấp mật khẩu thì khóa riêng sẽ được mã
hóa bằng khóa DMK.
• Để thấy những khóa đang tồn tại trong cơ sở dữ liệu hiện tại, chúng ta có thế
xem view sys.asymmetric_keys, như sau:
SELECT * FROM sys.asymmetric_keys;
Thuật toán mật mã được sử dụng cho khóa bất đối xứng là RSA (được đặt theo tên
của 3 người tạo ra thuật toán: Ron Rivest, Adi Shamir, Leonard Adleman). Độ dài
khóa ở đây chọn là 2028 bit.
Microsoft khuyến cáo sử dụng khóa đối xứng để mã hóa dữ liệu, bởi vì lý do chính
là mã hóa và giải mã khóa bất đối xứng cần nhiều tài nguyên hơn. Cách sử dụng
thông thường là sử dụng mã hóa đối xứng để mã hóa dữ liệu, và khóa đối xứng này
được bảo vệ bởi khóa mã bất đối xứng. Theo cách này thì hiệu năng thực hiện

29. không giảm đáng kể vì việc giải mã khóa bất đối xứng chỉ xảy ra một lần khi giải
mã để lấy khóa phi đối xứng. Đoạn mã sau chỉ ra cách sử dụng khóa bất đối xứng
để bảo vệ khóa đối xứng.
USE HumanResources;
CREATE ASYMMETRIC KEY HumanResourceASKey
WITH ALGORITHM = RSA_2048
ENCRYPTION BY PASSWORD = 'We need a very strong password';
CREATE SYMMETRIC KEY SalarySKey
WITH ALGORITHM = AES_256
ENCRYPTION BY ASYMMETRIC KEY HumanResourceASKey;
OPEN SYMMETRIC KEY SalarySKey
DECRYPTION BY ASYMMETRIC KEY HumanResourceASKey WITH PASSWORD =
'We need a very strong password';
SELECT * FROM sys.openkeys;
CLOSE SYMMETRIC KEY SalarySKey;
Ở đây chúng ta tạo một khóa bất đối xứng để bảo vệ khóa đối xứng. Khóa bất đối
xứng có tên HumanResourceASKey được bảo vệ bằng mật khẩu, không phải là sử
dụng khóa DMK. Điều này cung cấp việc kiểm soát những ai có thể mở khóa này.
Các khóa bất đối xứng không thể kết xuất (export) hoặc trao đổi. Nếu chúng ta
muốn có thể sao lưu, kết xuất hoặc kết nhập khóa mã đến một cơ sở dữ liệu khác
hoặc server khác thì cần phải sử dụng chứng chỉ.
2.2.5 Tạo và sử dụng các chứng chỉ
Một chứng chỉ là một khóa bất đối xứng gắn kèm với thông tin định danh. Chúng
ta có thể xem nó như là một khóa với tên chủ sở hữu ghi trên đó. Nó theo tiêu
chuẩn X.509 cho cơ sở hạ tầng khóa công khai (Public Key Infrastructure - PKI).

30. Một chứng chỉ cho phép không chỉ lưu trữ và trao đổi dữ liệu được mã hóa, mà còn
để đảm bảo người nhận (có khóa riêng, sẽ được sử dụng để giải mã) là đúng người,
bằng một phương pháp chữ ký số. Nó là một ý tưởng tốt để sử dụng chứng chỉ như
là nơi chứa (container) khóa bất đối xứng, bởi vì chúng ta có thể thêm một số
thông tin trong nó, ví dụ như thời gian hết hạn.
Một chứng chỉ phải được ký. Một chữ ký số chứng minh tính xác thực của chứng
chỉ đó, và cần phải đến từ một cơ quan đáng tin cậy, đó là một CA (Certificate
Authority(CA). CA là một công ty có trách nhiệm là để đảm bảo rằng một người
nào đó yêu cầu một chứng chỉ là người mà anh công bố. Chứng chỉ cũng có thể tự
ký (self-signed), có nghĩa là các thực thể sử dụng chứng chỉ là cùng một thực thể
đã ký nó (chứng chỉ được ký bằng khóa riêng của nó). Điều này không cung cấp
bất kỳ đảm bảo thực cho các bên khác, nhưng có lợi thế là dễ dàng và được tạo ra
miễn phí. Trong bối cảnh của SQL Server, các chứng chỉ này có thể được sử dụng
thay cho các khóa bất đối xứng để bảo vệ khóa đối xứng. Sơ đồ dưới đây cho thấy
SQL Server cung cấp tất cả các khả năng để mã hóa dữ liệu:

31. Để có các chứng chỉ được mã hóa bởi DMK, chúng ta phải tạo DMK trước. Nếu
cơ sở dữ liệu không có khóa DMK, chúng ta vẫn có thể tạo chứng chỉ nhưng nó sẽ
được bảo vệ bởi mật khẩu.
• Đoạn mã sau mô tả cách tạo một chứng chỉ tự ký (self-signed certificate)
được bảo vệ bằng mật khẩu.
CREATE CERTIFICATE HumanResourceCert
ENCRYPTION BY PASSWORD = 'I am a very strong password'
WITH SUBJECT = 'DataHero Human Resources',
EXPIRY_DATE = '20131231';
• Chúng ta có thể import một chứng chỉ đang có như sau:
CREATE CERTIFICATE HumanResourceCert
FROM FILE = 'e:encryption_keysHumanResourceCert.cer'
WITH PRIVATE KEY (FILE = 'e:encryption_keysHumanResourceCert.pvk',
DECRYPTION BY PASSWORD = 'the password set at backup');
• Để nhận biết được các khóa có tồn tại trong cơ sở dữ liệu hiện tại, chúng ta
thực hiện truy vấn như sau:
SELECT * FROM sys.certificates;
• Chúng ta có thể sử dụng hàm CertProperty() để lấy thong tin chứng chỉ:
SELECT CertProperty(Cert_Id('HumanResourceCert'), 'Expiry_Date');
Các chứng chỉ được dùng trong SQL Server tuân theo chuẩn X.509v3, được mô tả
trong IETF RFC 5280, và sử dụng thuật toán RSA. Khóa riêng có độ dài 1024 bit.
Khi chúng ta import một chứng chỉ từ file, thì file đó có định dạng CER/PVK. SQL
Server không trực tiếp import các file chứng chỉ PFX hoặc PKCS#12.

32. Chúng ta có thể chuyển đổi các dạng file chứng chỉ bằng cách sử dụng các công cụ
mã nguồn mở, ví dụ như OpenSSL. Khi tạo một chứng chỉ, chúng ta có thể đề cập
đến các trường X.509 như: chủ đề, ngày bắt đầu, ngày hết hạn.
Chứng chỉ có thể được sao lưu ra file như sau:
BACKUP CERTIFICATE HumanResourceCert TO FILE =
'D:certificatesHumanResourceCert.cer'
WITH PRIVATE KEY (
FILE = 'D:certificatesHumanResourceCert.pvk' ,
ENCRYPTION BY PASSWORD = 'a strong password to encrypt the private key',
DECRYPTION BY PASSWORD = 'the strong password that protect the certificate'
);
Đây là ví dụ hoàn chỉnh thực hiện export chứng chỉ và khóa riêng của chứng chỉ ra
file. Nếu chúng ta không xác định phần PRIVATE KEY thì chỉ chỉ có khóa công
khai được export. Nó có thể được dung để mã hóa dữ liệu hoặc kiểm tra chữ ký
được tạo ra bởi chứng chỉ, nhưng không dùng được cho giải mã hoặc tạo chữ ký.
Khi chúng ta bảo vệ khóa riêng, chúng ta phải cung cấp mật khẩu để bảo vệ file.
Sau đó để import nó ở bất kỳ đâu, chúng ta tạo chứng chỉ này từ file như sau:
USE HumanResources_Copy;
CREATE CERTIFICATE HumanResourceCert
FROM FILE = 'D:certificatesHumanResourceCert.cer'
WITH PRIVATE KEY (FILE = 'D:certificatesHumanResourceCert.pvk',
DECRYPTION BY PASSWORD = 'a strong password to encrypt the private key');
Để sao chép chứng chỉ tới một cơ sở dữ liệu khác trên cùng một server, chúng ta sử
dụng hàm CERTENCODED() và CERTPRIVATEKEY() để chuyển một bản sao

33. dạng nhị phân (kiểu VARBINARY(MAX)) của khóa cho lệnh CREATE
CERTIFICATE:
USE Marketing;
SELECT CERTENCODED(CERT_ID('HumanResourceCert')) as [Certificate];
SELECT CERTPRIVATEKEY(CERT_ID('HumanResourceCert'),
'a password to encrypt the result',
'the password to decrypt the private key')
as [Certificate private key];
Kết quả của các hàm trên được chỉ ra như hình sau:
Sau đó sao chép và dán vào lệnh CREATE CERTIFICATE trong cơ sở dữ liệu
khác:
USE HumanResources;
CREATE CERTIFICATE HumanResourceCert
FROM BINARY = <the CERTENCODED binary value>
WITH PRIVATE KEY (
BINARY = <the CERTPRIVATEKEY binary value>,
DECRYPTION BY PASSWORD = 'the password provided to the CERTPRIVATEKEY
function');
Một khả năng các chứng chỉ và các khóa bất đối xứng là để tách biệt quá trình mã
hóa ra khỏi quá trình giải mã. Nếu chúng ta muốn giữ một bản sao các dữ liệu
được mã hóa trên một máy chủ mà không có khả năng để giải mã nó tại nơi cục bộ,

34. hoặc mã hóa trong một cơ sở dữ liệu để giải mã trong cơ sở dữ liệu khác, chúng ta
có thể chỉ cần giữ khóa công khai trên máy chủ này hoặc cơ sở dữ liệu. Khóa công
khai sẽ được sử dụng để mã hóa dữ liệu, mà không cần mật khẩu (khóa công khai
không cần được bảo vệ), chúng ta chỉ có thể mã hóa dữ liệu của với các khóa công
khai mà không cần phải mở toàn bộ khóa đó. Điều này có thể được thực hiện dễ
dàng với một chứng chỉ. Chúng ta có thể làm điều này theo hai cách, trước hết tạo
ra một chứng chỉ và sao lưu chỉ khóa công khai, như trong đoạn mã sau:
USE Marketing;
CREATE CERTIFICATE BackupCert1
WITH SUBJECT = 'Encryption for distant decryption',
EXPIRY_DATE = '2013-10-30';
BACKUP CERTIFICATE BackupCert1
TO FILE = 'E:encryption_keysBackupCert1.cer';
USE HumanResources;
CREATE CERTIFICATE BackupCert1
FROM FILE = 'E:encryption_keysBackupCert1.cer';
Tiếp theo, chúng ta loại bỏ khóa riêng khỏi chứng chỉ đang tồn tại như sau:
USE Marketing;
CREATE CERTIFICATE BackupCert2
WITH SUBJECT = 'Encryption for distant decryption',
EXPIRY_DATE = '2013-10-30';
BACKUP CERTIFICATE BackupCert2
TO FILE = 'E:encryption_keysBackupCert2.cer'
WITH PRIVATE KEY (
FILE = 'E:encryption_keysBackupCert2.pvk',
ENCRYPTION BY PASSWORD = 'SDf4(4rzdZRGefF-U_8zr5é"4é"é"'
);

35. ALTER CERTIFICATE BackupCert2
REMOVE PRIVATE KEY;
ALTER CERTIFICATE BackupCert2
WITH PRIVATE KEY (
FILE = 'E:encryption_keys .pvk',
DECRYPTION BY PASSWORD = 'SDf4(4rzdZRGefF-U_8zr5é"4é"é"'
);
Chúng ta có thể thấy các chứng chỉ không có khóa riêng trong sys.Certificates.
Cột pvt_key_encryption_type và pvt_key_encryption_type_desc chỉ ra chế độ mã
hóa của khóa riêng và gồm các gái trị sau:
2.3 Quá trình thực hiện mã hóa dữ liệu
2.3.1 Mã hóa dữ liệu với các khóa đối xứng
Mục đích chính của các khóa là để mã hóa dữ liệu, chẳng hạn như giá trị dữ liệu
trong cột. SQL Server khuyến cáo nên sử dụng khóa đối xứng thể hiện hiện mã hóa
dữ liệu này, bởi vì mã hóa bất đối xứng và giải mã là chậm hơn đáng kể. Khóa đối

36. xứng sẽ được bảo vệ bởi một khoá bất đối xứng hoặc chứng chỉ.
Để mã hóa dữ liệu với một khóa đối xứng, thực hiện các bước sau:
• Để mã hóa dữ liệu bằng khóa đối xứng chúng ta sử dụng hàm
EncryptByKey()
USE marketing ;
CREATE TABLE dbo.Customer (
CustomerId int NOT NULL IDENTITY(1,1) PRIMARY KEY,
Firstname varchar(50) NOT NULL,
Lastname varchar(50) NOT NULL,
CreditCardInfo varbinary(2000) NOT NULL
)
CREATE CERTIFICATE KeyProtectionCert
WITH SUBJECT = 'to protect symmetric encryption keys';
CREATE SYMMETRIC KEY CreditCardSKey
WITH ALGORITHM = AES_256,
KEY_SOURCE = '4frT-7FGHFDfTh98#6erZ3dq#«',
IDENTITY_VALUE = 'l·Fg{(ZEfd@23fz4fqeRHY&4efVql'
ENCRYPTION BY CERTIFICATE KeyProtectionCert;
OPEN SYMMETRIC KEY CreditCardSKey
DECRYPTION BY CERTIFICATE KeyProtectionCert;
INSERT INTO dbo.Customer (Firstname, LastName, CreditCardInfo)
VALUES ('Jim', 'Murphy',
EncryptByKey(Key_Guid('CreditCardSKey'), '1111222233334444;12/13,456', 1,
'JimMurphy')
);
CLOSE SYMMETRIC KEY CreditCardSKey;

37. Để đọc dữ liệu và lấy dữ liệu gốc khi chưa mã hóa (bản rõ), sử dụng hàm
DecryptByKey() như sau:
OPEN SYMMETRIC KEY CreditCardSKey DECRYPTION BY CERTIFICATE
KeyProtectionCert;
SELECT Firstname, Lastname,
CAST(DecryptByKey(CreditCardInfo, 1, Firstname + Lastname) as varchar(50))
FROM dbo.Customer;
CLOSE SYMMETRIC KEY CreditCardSKey;
Ở đây, mục đích là để lưu trữ dữ liệu được mã hóa trong một cột. Kết quả của hàm
EncryptByKey () là một giá trị nhị phân có thể lên đến 8000 byte. Do đó, chúng ta
sẽ cần phải tạo ra các cột VARBINARY để lưu trữ các dữ liệu được mã hóa. Mã
hóa, đối lập với băm, cho phép đảo ngược các giá trị và lấy bản rõ được giải mã.
Nhưng một người nào đó có quyền truy cập vào bản mã mà không thể giải mã nó
nhưng vẫn có thể sử dụng nó để gây ra thiệt hại.
Chúng ta có thể sử dụng hàm EncryptByPassphrase() and DecryptByPassphrase()
để mã hóa dữ liệu mà không cần bất ky khóa nào. Chúng ta có thể thêm một thông
tin xác thực cho các hàm này. Chúng không yêu cầu bất kỳ quyền cụ thể nào.
Có những ưu và khuyết điểm về hiệu năng khi thực hiện mã hóa ở bên phía hệ
quản trị. Chúng ta có thể lựa chọn việc mã hóa trong khi viết ứng dụng khách hàng
và gửi các kết quả đã được mã hóa này vào trong một cột cơ sở dữ liệu bằng câu
lệnh SQL. Cách này có ưu điểm là bản rõ không được gửi qua mạng. Điều tệ hại
là khóa cần phải xuất hiện trên mỗi máy trạm nơi mà mã lệnh ứng dụng khách
hàng được cài đặt, và do đó dễ dàng tiếp cận với khóa mã.
Mã hóa phía máy chủ cho phép tập trung các khóa và ngăn ngừa việc di chuyển
khóa trên mạng và máy trạm, nhưng các bản rõ lại được truyền trên mạng. Để nhất

38. quán với mã hóa máy chủ SQL, chúng ta cần phải suy nghĩ nghiêm túc về việc mã
hóa các kết nối với SSL.
2.3.2 Mã hóa dữ liệu với các khóa phi đối xứng và chứng chỉ
Như đã nói ở trên, vì lý do hiệu năng nên mã hóa dữ liệu sử dụng khóa đối xứng,
và để bảo vệ khóa đối xứng sử dụng bởi một khoá bất đối xứng hoặc chứng chỉ.
Tuy nhiên cũng có thể mã hóa dữ liệu trực tiếp với một khóa công khai của một
cặp khóa.
Để thực hiện được mã hóa khóa bất đối xứng, chúng ta phải tạo ra một khoá bất
đối xứng hoặc chứng chỉ, và sử dụng hàm EncryptByAsymKey() hoặc
EncryptByCert () như trong đoạn mã sau. Chú ý khóa chủ cơ sở dữ liệu đã phải
tồn tại trong cơ sở dữ liệu đó (ở đây, cơ sở dữ liệu marketing).
USE marketing ;
CREATE ASYMMETRIC KEY DataEncryptionAsymKey
WITH ALGORITHM = RSA_2048;
DECLARE @plaintext NVARCHAR(1000) = 'I have nothing interesting to say, but I don''t
want anybody to know that';
DECLARE @ciphertext VARBINARY(8000) ;
SELECT @ciphertext =
ENCRYPTBYASYMKEY(ASYMKEY_ID('DataEncryptionAsymKey'), @plaintext) ;
SELECT @ciphertext;
SELECT
CAST(DECRYPTBYASYMKEY(ASYMKEY_ID('DataEncryptionAsymKey'),@ciphertext)
AS NVARCHAR(1000)) as plaintext_again;
Ở đây, chúng ta tạo ra một khóa bất đối xứng và sử dụng nó để mã hóa nội dung
của một biến. Sau đó chúng ta giải mã nó trở lại bằng cách sử dụng hàm

39. DecryptByAsymKey(). Nếu chúng ta đang sử dụng một chứng chỉ, thì hàm này sẽ
là DecryptByCert ().
Tham số đầu tiên trong hàm DecryptByAsymKey () và DecryptByCert () là định
danh khóa. Giá trị này có thể được lấy ra bởi hàm AsymKey_Id () hoặc Cert_Id ().
Không giống như các khóa đối xứng, khóa bất đối xứng và chứng chỉ không cần
phải được mở trước. Chúng ta chỉ cần sử dụng chúng với các hàm phù hợp. Trong
ví dụ dưới đây các khóa bất đối xứng được bảo vệ bởi khóa DMK. Nếu sử dụng
mật khẩu để bảo vệ thì chúng ta gửi nó cho các hàm này.

40. 2.4 Quá trình thực hiện mã hóa dữ liệu sử dụng TDE
TDE cung cấp khả năng mã hóa toàn bộ cơ sở dữ liệu và có quá trình mã hóa hoàn
toàn trong suốt minh cho ứng dụng truy cập cơ sở dữ liệu. TDE mã hóa dữ liệu
được lưu trữ trong cả hai tập tin dữ liệu cơ sở dữ liệu (.MDF.) và tập log (.LDF)
bằng cách sử dụng thuật toán mã hóa AES (Advanced Encryption Standard) hoặc
3DES (Triple DES). Ngoài ra, bất kỳ bản sao lưu cơ sở dữ liệu đều được mã hóa.
Điều này đảm bảo rằng những dữ liệu còn lại trên thiết bị lưu trữ được bảo vệ
chống lại mất thông tin nhạy cảm nếu như các phương tiện sao lưu bị mất hoặc bị
đánh cắp.
Giống như nén dữ liệu, mã hóa cơ sở dữ liệu TDE được thực hiện ở mức trang .
Dữ liệu được mã hóa trên đĩa và được giải mã khi nó được đọc vào bộ nhớ. Thực
hiện mã hóa ở mức trang cho phép quá trình mã hóa là hoàn toàn trong suốt với các
ứng dụng client. Khả năng tìm kiếm và truy vấn dữ liệu trong cơ sở dữ liệu mã hóa
không bị hạn chế.
Điều quan trọng cần lưu ý rằng mặc dù TDE mã hóa dữ liệu lưu trữ, nó không mã
hóa các liên kết truyền thông giữa máy chủ và các ứng dụng của khách hàng . Nếu
chúng ta cần để mã hóa các kết nối dữ liệu giữa các ứng dụng và máy chủ, chúng
ta cần phải sử dụng một kết nối SSL cho khách hàng.
Việc sử dụng TDE tương đối đơn giản. Để má hóa một cơ sở dữ liệu, thực hiện các
bước sau:
• Tạo một khóa chủ của cơ sở dữ liệu, đó là khóa DMK .
• Tạo một chứng chỉ được bảo vệ bằng khóa DMK

41. • Tạo một khóa đặc biệt được sử dụng để bảo vệ cơ sở dữ liệu. Khóa này được
gọi là khóa mã cơ sở dữ liệu (DEK) và chúng ta bảo vệ nó bằng cách sử
dụng chứng chỉ
• Cho phép mã hóa
Để cho phép TDE, đầu tiên chúng ta phải tạo một khóa chủ. Điều quan trọng cần
lưu ý rằng khóa chủ này phải được tạo ra trong cơ sở dữ liệu master. Lệnh
CREATE MASTER KEY sẽ tạo ra khóa chủ cùng với mật khẩu liên quan trong
cơ sở dữ liệu master.
Tiếp theo lệnh CREATE CERTIFICATE được sử dụng để tạo một chứng chỉ mới.
Sau khi chứng chỉ được tạo, dùng lệnh USE để chuyển vào cơ sở dữ liệu cần áp
dụng mã hóa. Sau đó thực hiện lệnh CREATE DATABASE ENCRYPTION KEY
để tạo khóa DEK với thuật toán chỉ định. Chúng ta có thể chọn một trong các thuật
toán mã hóa sau: AES_128, AES_192, AES_256, or TRIPLE_DES_3KEY.
Sau khi khóa mã hóa cơ sở dữ liệu được tạo ra, lệnh ALTER DATABASE được sử
dụng để cho phép mã hóa. Tiến trình mã hóa chạy như là nhiệm vụ nền, vì vậy cơ
sở dữ liệu vẫn có sẵn trong khi nó mã hóa. Tuy nhiên, có ảnh hưởng hiệu năng
trong thời gian này. Cần lưu ý rằng nếu có bất kỳ cơ sở dữ liệu trên một máy chủ
được mã hóa bằng TDE, cơ sở dữ liệu tempdb cũng được mã hóa.
Sao lưu chứng chỉ là cực kỳ quan trọng bởi vì các dữ liệu được mã hóa không thể
được truy cập hoặc khôi phục mà không có chứng chỉ. Tương tự như vậy, nếu
chúng ta cần di chuyển một cơ sở dữ liệu được mã hóa từ một SQL Server đến
máy chủ khác, thì chúng ta cũng cần phải di chuyển chứng chỉ này. Mã trong Liệt
kê 2 cho thấy làm thế nào để sao lưu các chứng chỉ tới một tập tin trong hệ thống

42. tập tin. Tập tin này sau đó có thể được sao lưu hoặc sao chép vào một hệ thống
khác để cho phép cơ sở dữ liệu được mã hóa để được phục hồi.
Để di chuyển hoặc khôi phục lại cơ sở dữ liệu đến một thể hiện SQL Server khác,
chúng ta cần khôi phục chứng chỉ cho máy chủ mới.
Chương III: Thực hiện demo việc mã hóa dữ liệu trong SQL Server
3.1Demo áp dụng mã hóa dữ liệu mức cột
Trong phần này chúng tôi thực hiện các thao tác cơ bản khi áp dụng giải pháp mã
hóa dữ liệu mức cột trong SQL server 2012 như sau:
• Tạo cơ sở dữ liệu và tạo bảng
• Xây dựng thủ tục thực hiện mã hóa dữ liệu
• Thực hiện thêm dữ liệu vào bảng có áp dụng mã hóa
• Truy xuất dữ liệu trong bảng, thực hiện giải mã dữ liệu khi xem dữ liệu
• Một số đánh giá
Bước 1: Tạo cơ sở dữ liệu HSCB_ENC, tạo bảng canhan gồm các cột stt, hoten,
ngaysinh, sothe, diachi. Cột sothe lưu thông mã số tài khoản của một người và
chúng thực hiện mã hóa dữ liệu của cột này.

44. Bước 2: Thực hiện xây dụng các thủ tục lưu trữ sau
• Thủ tục tao_khoa: Thực hiện chức năng tạo các khóa mã hóa dữ liệu gồm:
o Khóa chủ cơ sở dữ liệu: Có tên là masterkey@HSCB_ENC, sử dụng
để mã hóa khóa riêng của chứng chỉ. Được bảo vệ bằng mật khẩu.
o Chứng chỉ: Có tên là HSCB_ENC_CER, sử dụng để bảo vệ khóa đối
xứng
o Khóa đối xứng: Có tên là khoa_canhan, sử dụng để mã hóa dữ liệu
trong bảng canhan

45. • Thủ tục xoa_khoa: Thực hiện xóa các khóa được tạo trong thủ tục tạo khóa,
gồm các khóa đối xứng, chứng chỉ, khóa chủ cơ sở dữ liệu
• Thủ tục them_dulieu: Thủ tục này thực hiện chức năng thêm dữ liệu vào
trong bảng, trong quá trình này thực hiện mã hóa dữ liệu chứa thông tin tài
khoản trước khi ghi vào bảng

46. • Thủ tục thục hiện giải mã dữ liệu: Thực hiện truy xuất toàn bộ các bản ghi
trong bảng canhan. Trong đó thực hiện giải mã cột dữ liệu sothe.

47. Bước 3: Thực hiện thêm một số dữ liệu vào bảng, cần thực hiện các bước sau
• Thực hiện tạo khóa, sử dụng thủ tục tao_khoa nếu các khóa này chưa tồn tại.
Thực hiện lệnh EXEC tao_khoa
• Thực hiện thủ tục them_dulieu để chèn một bản ghi vào bảng, trong đó
thông tin tài khoản sẽ được mã hóa, ví dụ như hình thực hiện thêm 4 bản ghi
vào bảng cá nhân

48. Bước 4: Hình sau hiển thị các thông tin vừa nhập vào trong bảng cá nhân. Thông
tin trong cột sothe là thông tin về tài khoản cá nhân đã được mã hóa. Chúng tôi
thấy rằng trong mỗi bản mã (mỗi ô dữ liệu) đều gắn thêm chỉ số của khóa đối xứng
(khoa_canhan) được sử dụng để mã hóa dữ liệu.

49. Để giải mã dữ liệu của cột và hiển thị dữ liệu trong bảng canhan, chúng ta thực
hiện thủ tục xem_dulieu. Hình sau hiển thị dữ liệu trong bảng canhan.

50. Tóm lại sau khi thực hiện những thao tác mã hóa đơn giản để mô phỏng quá trình
thực hiện, chúng tôi thấy rằng:
• Dữ liệu cột sothe được mã hóa bằng thuật toán AES, với độ dài khóa 256
bit
• Khóa mã dữ liệu này được bảo vệ bằng chứng chỉ, và chứng chỉ được bảo
vệ bởi khóa chủ cơ sở dữ liệu. Và cuối cùng khóa chủ cơ sở dữ liệu được
bảo vệ bởi mật khẩu.
• Trong hàm giải mã trong SQL Server, chúng ta chỉ cần cung cấp bản mã mà
không cần cung cấp thông tin gì về khóa giải mã vì mỗi bản mã đều có gắn
thêm chỉ số của các khóa dùng để mã hóa. Do đó khi thực hiện giải mã,
SQL Server sẽ lấy chỉ số khóa từ bản mã, tìm trong bộ nhớ của nó xem đã
được mở chưa. Nếu khóa này đã mở thì sẽ giải mã cho bản rõ, còn không
trả về giá trị NULL

51. 3.2 Demo áp dụng công nghệ mã hóa dữ liệu trong suốt - TDE
Trong phần này chúng tôi thực hiện áp dụng công nghệ mã hóa dữ liệu trong suốt
(TDE) cho một cơ sở dữ liệu giả định để thấy được ý nghĩa của chúng khi so sánh
với một cơ sở dữ liệu khác không thiết lập mã hóa TDE.
Bước 1: Thực hiện tạo và nhập dữ liệu 2 cơ sở dữ liệu: HSCB và HSCB_TDE.
Trong mỗi cơ sở dữ liệu này, thực hiện tạo bảng canhan có cấu trúc như hình sau,
và nhập một số thông tin như nhau.
Bước 2: Hiển thị dữ liệu trong 2 cơ sở dữ liệu trên. Dưới đây là dữ liệu có trong
bảng canhan trong cơ sở dữ liệu HSCB
Và đây là dữ liệu có trong bảng canhan trong cơ sở dữ liệu HSCB_TDE

52. Giả sử dữ liệu của hai cơ sở dữ liệu này là giống nhau.
Bước 3: Thiết lập mã hóa trong suốt (TDE) áp dụng cho cơ sở dữ liệu HSCB_TDE
/* Chọn csdl hiện hành là master */
USE Master;
GO
/* Tạo khóa DMK */
-- Create the master key.
CREATE MASTER KEY ENCRYPTION
BY PASSWORD='tde@123';
GO

53. /* Tạo chứng chỉ */
CREATE CERTIFICATE MySQLCert
WITH SUBJECT='HSCB_TDE DEK';
GO
/* Chọn csdl hiện hành để cho phép TDE */
USE HSCB_TDE
GO
/* Gắn kết chứng chỉ với csdl */
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE MySQLCert;
GO
/* Cho phép mã hóa csdl */
ALTER DATABASE HSCB_TDE
SET ENCRYPTION ON;
GO
Bước 4: Hiển thị dữ liệu trong tệp dữ liệu (*.mdf) của hai cơ sở dữ liệu để thấy
được sự khác biệt và ý nghĩa việc áp dụng TDE
Thường thì các tệp tin của cơ sở dữ liệu có tên giống như tên cơ sở dữ liệu và phần
mở rộng là (*.mdf), chúng có thể được lưu trong thư mục data.

54. Trước hết chúng ta đóng dịch vụ SQL Server lại, sử dụng chương trình
notepad.exe mở tệp tin HSCB.mdf, khi đó bằng mắt thường chúng ta thấy được dữ
liệu rõ trong tệp tin cơ sở dữ liệu. Ví dụ như hình sau chúng ta thấy được tên
người, mã tài khoản là Trần Thu Minh, TK0898674398
Tiếp theo sử dụng chương trình notepad.exe mở tệp tin HSCB_TDE.mdf. Tệp tin
này hoàn toàn đã được SQL Server mã hóa sử dụng công nghệ TDE, ví dụ như
hình sau

55. Chúng ta tìm chuỗi ký tự ‘TK0898674398’ trong tệp tin này nhưng hoàn toàn
không thấy vì nó đã được mã hóa.
Như vậy công nghệ mã hóa cơ sở dữ liệu trong suốt giúp chúng ta bảo vệ các tệp
cơ sở dữ liệu. Nếu như kẻ tấn công bằng cách nào đó lấy trộm được các tệp tin này
đều hoàn toàn không thể khai thác được thông tin.
Việc truy xuất đến các cơ sở dữ liệu đối với người dùng hợp lệ là hoàn toàn trong
suốt, ứng dụng người dùng không phải thay đổi để cho phù hợp.

56. KẾT LUẬN
Ngày nay hầu hết các thông tin của tổ chức, cá nhân đều được trong cơ sở dữ liệu.
Vấn đề đảm bảo an toàn dữ liệu cũng như tính bí mật của dữ liệu đó hết sức cần
thiết. Các hệ quản trị cơ sở dữ liệu cung cấp khả năng và giải pháp nhằm đảm bảo
an toàn cho cơ sở dữ liệu. Nếu đứng trên phương diện người phát triển các ứng
dụng cơ sở dữ liệu thì chúng ta cần phải nắm rõ các khả năng mà hệ quản trị đó
cho phép để từ đó giúp cho việc thiết kế và xây dựng phương pháp đảm bảo vấn đề
an ninh, an toàn cho hệ thống và cho dữ liệu.
Xuất phát từ nhu cầu đó chúng tôi tập trung tìm hiểu và các vấn đề liên quan để
đảm bảo an ninh, an toàn cho cơ sở dữ liệu trong hệ quản trị SQL Server 2012.
Sau một khoảng thời gian không dài, chúng tôi đã nghiên cứu tìm hiểu một số vấn
đề sau:
• Tổng hợp và giới thiệu các vấn đề an ninh cơ bản đối với hệ quản trị cơ sở
dữ liệu SQL Server 2012.
• Tìm hiểu chuyên sâu giải pháp và phương pháp thực hiện mã hóa dữ liệu
trong SQL Server 2012 nhằm đảm bảo mục tiêu an toàn cho hệ thống dữ liệu
được lưu trữ.
• Qua những chương trình demo, mỗi cá nhân trong nhóm nhận thức được ý
nghĩa và vai trò của vấn đề mã hóa cơ sở dữ liệu. Vì khả năng tiếp xúc với
việc lập trình còn hạn chế nên chúng tôi bước đầu nắm được việc thiết kế và
tích hợp phương pháp mã hóa trong quy trình khi xây dựng ứng dụng cơ sở
dữ liệu.
Nhìn chung, đề tài đã hoàn thành được cơ bản những yêu cần đặt ra ban đầu của
giảng viên hướng dẫn.

57. Một số hạn chế còn tồn tại:
• Vẫn còn những thuật toán mã hóa cũng như các phương pháp mã hóa chưa
được nghiên cứu cụ thể trong đề tài.
• Hiểu biết và khả năng lập trình trên SQL Server còn hạn chế nên cũng khó
khăn trong quá trình tìm hiểu giải pháp và thực thi.
• Hiện tại việc nghiên cứu còn dừng lại ở mức độ nghiên cứu và tìm hiểu để
phát triển chứ chưa đưa ra được các ý tưởng riêng.
Hướng phát triển tiếp theo của đề tài: Tiếp tục nghiên cứu, tìm hiểu các giải pháp
đã có trên trong các hệ quản trị cơ sở dữ liệu khác, cũng như các sản phẩm trên thế
giới để từ đó nâng cao kiến thức hiểu biết hệ quản trị, khả năng lập trình cơ sở dữ
liệu. Từ đó có thể lựa chọn một giải pháp an toàn và bảo mật phù hợp để có thể tự
xây dựng và phát triển ứng dụng .
Cuối cùng nhóm đề tài xin chân thành cảm ơn sự giúp đỡ của thầy giáo hướng dẫn,
phòng Quản lý Nghiên cứu Khoa học đồng nghiệp, các thầy cô giáo và bạn bè đã
giúp đỡ chúng tôi trong quá trình hoàn thành đề tài.
Hà Nội, 11/2013
Nhóm đề tài

58. TÀI LIỆU THAM KHẢO
<1> Microsoft SQL Server 2012 Security Cookbook
<2> Phần Security and Protection trong tài liệu SQL Server Book Online
<3> SQL_Server_2012_Security_Best_Practice_Whitepaper_Apr2012.doc