Mã hóa dữ liệu trong suốt (Transparent data encrytion – TDE) là một trong những cơ chế an toàn, cho phép mã hóa dữ liệu nhạy cảm được lưu trữ trong bảng và không gian bảng. Dữ liệu được mã hóa và giải mã trong suốt đối với người dùng và các ứng dụng có quyền truy cập vào dữ liệu. Để ngăn chặn việc giải mã trái phép, TDE lưu trữ các khóa mã hóa trong mô-đun an toàn bên ngoài cơ sở dữ liệu (CSDL).

TDE thực hiện mã hóa và giải mã thời gian thực các dữ liệu và các tệp nhật ký [1]. Việc mã hóa sử dụng khóa mã hóa dữ liệu (Data Encryption Key - DEK) được lưu trữ trong bản ghi khởi động CSDL để sẵn sàng trong quá trình phục hồi. Bên cạnh đó, TDE có khả năng bảo vệ dữ liệu lưu trữ, nghĩa là các tệp dữ liệu và nhật ký. Nó cung cấp khả năng tuân thủ nhiều luật, quy định và hướng dẫn được thiết lập trong các ngành công nghiệp khác nhau. Điều này cho phép các nhà phát triển phần mềm mã hóa dữ liệu bằng cách sử dụng thuật toán mã hóa AES và 3DES mà không cần thay đổi các ứng dụng hiện có.

Người dùng và ứng dụng cơ sở dữ liệu không cần quản lý lưu trữ khóa hoặc tạo bảng phụ, dạng xem và kích hoạt. Một ứng dụng xử lý dữ liệu nhạy cảm có thể sử dụng TDE để cung cấp mã hóa dữ liệu mạnh mẽ với ít hoặc không có thay đổi nào đối với ứng dụng.

Vì vậy, TDE có các ưu điểm nổi bật sau:

- Đảm bảo an toàn các dữ liệu nhạy cảm trong trường hợp phương tiện lưu trữ hoặc tệp dữ liệu bị đánh cắp.

- Tuân thủ các quy định liên quan đến an toàn.

- Không cần tạo trình kích hoạt hoặc chế độ xem để giải mã dữ liệu cho người dùng hoặc ứng dụng được ủy quyền. Dữ liệu từ các bảng được giải mã trong suốt cho người dùng và ứng dụng CSDL.

- Các ứng dụng không cần phải sửa đổi để xử lý dữ liệu được mã hóa. Mã hóa và giải mã dữ liệu được quản lý bởi cơ sở dữ liệu.

- Hoạt động quản lý được tự động hóa. Người dùng hoặc ứng dụng không cần quản lý khóa mã hóa.

Các loại mã hóa TDE

Theo [3], có hai loại mã hóa TDE: Mã hóa cột và mã hóa không gian bảng. Trong khi mã hóa cột TDE cho phép mã hóa dữ liệu nhạy cảm được lưu trữ trong các cột của bảng được chọn, thì mã hóa không gian bảng TDE cho phép mã hóa tất cả dữ liệu được lưu trữ trong một vùng bảng.

Cả mã hóa cột và mã hóa không gian bảng TDE đều sử dụng kiến trúc dựa trên khóa hai tầng. Ngay cả khi dữ liệu mã hóa được truy xuất, dữ liệu cũng không được hiển thị cho đến khi quá trình giải mã được ủy quyền xảy ra, quá trình này là tự động cho người dùng được ủy quyền truy cập vào bảng.

Mã hóa cột TDE

Mã hóa cột TDE được sử dụng để bảo vệ dữ liệu nhạy cảm, chẳng hạn như thẻ tín dụng và số an sinh xã hội, được lưu trữ trong các cột của bảng. Loại mã hóa này sử dụng kiến trúc hai lớp, dựa trên khóa để mã hóa và giải mã các cột bảng nhạy cảm. Trong đó, khóa mã hóa chính (Master encryption key) được sử dụng để mã hóa khóa bảng (Table key). Khóa mã hóa chính được lưu trữ trong một mô-đun an toàn bên ngoài, có thể là ví (Wallet) hoặc mô-đun an toàn phần cứng (HSM). Chẳng hạn, đối với hệ quản trị Oracle sử dụng Oracle Wallet hoặc mô-đun an toàn phần cứng để lưu trữ khóa mã hóa chính.

Hình 1. Quá trình mã hóa cột TDE [3]

Việc lưu trữ theo cách này sẽ ngăn việc sử dụng trái phép các khóa mật và tách biệt các chức năng chương trình thông thường khỏi các hoạt động mã hóa, giúp phân chia nhiệm vụ giữa người quản trị CSDL và quản trị an toàn, dẫn đến tăng cường khả năng bảo mật.

Mã hóa không gian bảng TDE

Mã hóa không gian bảng TDE cho phép mã hóa toàn bộ vùng bảng. Tất cả các đối tượng được tạo trong không gian bảng sẽ được mã hóa tự động. Mã hóa không gian bảng TDE rất hữu ích nếu trong trường hợp muốn bảo vệ dữ liệu nhạy cảm trong các bảng. Trường hợp này, không cần thực hiện phân tích chi tiết từng cột trong bảng để xác định các cột cần mã hóa.

Ngoài ra, mã hóa không gian bảng TDE tận dụng mã hóa hàng loạt và bộ đệm để cung cấp hiệu suất nâng cao. Mặc dù tác động hiệu suất thực tế trên các ứng dụng có thể khác nhau, nhưng chi phí hiệu năng được ước tính trong khoảng từ 5% đến 8%.

Hình 2. Quá trình mã hóa không gian bảng TDE [3]

Mã hóa không gian bảng TDE là một thay thế tốt cho mã hóa cột TDE nếu các bảng chứa dữ liệu nhạy cảm trong nhiều cột hoặc nếu muốn bảo vệ toàn bộ bảng chứ không chỉ các cột riêng lẻ.

Loại mã hóa này mã hóa tất cả dữ liệu được lưu trữ trong một vùng bảng và dữ liệu làm lại (redo) tương ứng của nó. Điều này bao gồm (các LOB) đối tượng lớn bên trong như BLOBs và CLOBs. Mã hóa không gian bảng TDE không mã hóa dữ liệu được lưu trữ bên ngoài vùng bảng. Ví dụ, dữ liệu BFILE không được mã hóa vì nó được lưu trữ bên ngoài CSDL. Nếu tạo một bảng có một cột BFILE trong không gian bảng được mã hóa, thì cột cụ thể này sẽ không được mã hóa. Tuy nhiên, các file LOB được hỗ trợ từ CSDL Oracle 11 g phiên bản 1 (11.1).

Tất cả dữ liệu trong một vùng bảng được mã hóa sẽ được lưu trữ ở định dạng mã hóa trên đĩa. Dữ liệu được giải mã trong suốt cho người dùng được ủy quyền có các đặc quyền cần thiết để được xem hoặc sửa đổi dữ liệu. Người dùng hoặc ứng dụng CSDL không cần biết liệu dữ liệu trong một bảng cụ thể có được mã hóa trên đĩa hay không. Trong trường hợp các tệp dữ liệu trên đĩa hoặc phương tiện sao lưu bị đánh cắp, dữ liệu sẽ không bị xâm phạm.

Mã hóa không gian bảng TDE cũng sử dụng kiến trúc hai tầng (Hình 2), dựa trên khóa để mã hóa trong suốt và giải mã không gian bảng. Khóa chính TDE cũng có chức năng và cách thức lưu trữ như mã hóa cột TDE.

Mã hóa không gian bảng TDE cũng cho phép phạm vi chỉ mục quét dữ liệu trong không gian bảng được mã hóa. Điều này là không thể với mã hóa cột TDE.

Lưu ý, dữ liệu mã hóa được bảo vệ trong các hoạt động như JOIN và SORT. Điều này có nghĩa là dữ liệu được an toàn khi nó được di chuyển đến các vùng bảng tạm thời. Dữ liệu trong nhật ký hoàn tác và làm lại cũng được bảo vệ.

Các thuật toán mã hóa và toàn vẹn được hỗ trợ

Theo mặc định, TDE sử dụng chuẩn mã hóa nâng cao với khóa mật mã có độ dài 192 bit (AES192). Ngoài ra, theo mặc định salt được thêm vào bản rõ (Clear text) trước khi mã hóa trừ khi được quy định khác. Lưu ý, salt không thể được thêm vào các cột được lập chỉ mục mà người dùng muốn mã hóa. Đối với các cột được lập chỉ mục, chọn tham số NO SALT cho mệnh đề ENCRYPT SQL.

Hình 3 thể hiện một số câu lệnh SQL được sử dụng trong mã hóa TDE.

Hình 3. Các thuật toán mã hóa hỗ trợ cho TDE

Hình 3. Các lệnh SQL trong TDE

Vấn đề an toàn trong TDE

Các cân nhắc về an toàn cho TDE nên được xem xét trong quá trình hoạt động. Quản trị viên an toàn phải xác định mức độ rủi ro cần giải quyết và mức độ nhạy cảm của dữ liệu được duy trì bởi trang web. Chi phí và lợi ích phải được đánh giá cho các phương pháp thay thế để đạt được sự bảo vệ chấp nhận được. Trong nhiều trường hợp, nên có các quản trị viên an toàn riêng biệt, wallet riêng cho TDE và các quy trình sao lưu được bảo vệ cho dữ liệu được mã hóa. Chẳng hạn, trong Oracle, có một wallet riêng cho TDE cho phép tự động đăng nhập cho các thành phần khác nhưng vẫn bảo vệ mật khẩu cho wallet TDE.

Các cân nhắc an toàn bổ sung cũng cần được áp dụng cho CSDL và hoạt động mạng thông thường khi sử dụng TDE. Dữ liệu cột được mã hóa vẫn được mã hóa trong các tệp dữ liệu, hoàn tác nhật ký, nhật ký làm lại và bộ đệm của khu vực chung của hệ thống. Tuy nhiên, dữ liệu được giải mã trong quá trình ước lượng biểu thức, khiến dữ liệu được giải mã có thể xuất hiện trong tệp trao đổi trên đĩa. Khi đó, người dùng hệ điều hành có đặc quyền sẽ có khả năng xem dữ liệu này.

Các giá trị cột được mã hóa bằng TDE được lưu trữ trong các tệp dữ liệu ở dạng được mã hóa. Tuy nhiên, các tệp dữ liệu này vẫn có thể chứa một số đoạn văn bản rõ, được gọi là bản sao ma, còn sót lại bởi các hoạt động dữ liệu trong quá khứ trên bảng. Điều này tương tự với việc tìm kiếm dữ liệu trên đĩa sau khi một tệp đã bị xóa bởi hệ điều hành.

Các đoạn văn bản rõ cũ có thể xuất hiện trong một thời gian cho đến khi cơ sở dữ liệu ghi đè lên các khối có chứa các giá trị đó. Nếu người dùng đặc quyền bỏ qua các điều khiển truy cập của cơ sở dữ liệu, họ có thể truy cập trực tiếp các giá trị này trong tệp dữ liệu lưu giữ không gian bảng. Do đó, có thể sử dụng quy trình sau để giảm thiểu rủi ro này:

Bước 1: Tạo một vùng bảng mới trong một tệp dữ liệu mới, có thể sử dụng câu lệnh CREATE TABLESPACE.

Bước 2: Di chuyển bảng chứa các cột được mã hóa sang không gian bảng mới sử dụng câu lệnh ALTER TABLE.....MOVE. Lặp lại bước này cho tất cả các đối tượng trong không gian bảng ban đầu.

Bước 3: Giải phóng không gian bảng ban đầu sử dụng câu lệnh DROP TABLESPACE tablespace INCLUDING CONTENTS KEEP DATAFILES. Người dùng nên xóa các tệp dữ liệu một cách an toàn bằng các tiện ích cụ thể của DBMS đang sử dụng.

Bước 4: Sử dụng các tiện ích cụ thể của DBMS và hệ thống tệp để xóa an toàn tệp dữ liệu cũ. Chẳng hạn các tiện ích như shred (trên Linux) và sdelete (trên Windows).

Sử dụng TDE trong môi trường đa CSDL

Nếu có nhiều CSDL được cài đặt trên cùng một máy chủ, thì mỗi CSDL phải truy cập vào Wallet mã hóa dữ liệu trong suốt của chính nó. Wallet không được thiết kế để được chia sẻ giữa các cơ sở dữ liệu. Theo thiết kế, phải có một wallet cho mỗi CSDL riêng biệt, nên không thể sử dụng cùng một wallet cho nhiều cơ sở dữ liệu.

Trong Oracle, để định cấu hình tệp sqlnet.ora cho môi trường đa CSDL, hãy sử dụng một trong các tùy chọn sau:

- Nếu các CSDL chia sẻ cùng hệ quản trị Oracle, thì hãy giữ tệp sqlnet.ora ở vị trí mặc định, trong thư mục ORACLE_HOME/network/ admin. Trong trường hợp này, tốt nhất nên sử dụng vị trí mặc định. Đảm bảo rằng tệp sqlnet. ora không có mục WALLET_LOCATION hoặc ENCRYPTION_WALLET_LOCATION. Mã hóa dữ liệu trong suốt truy cập wallet từ sqlnet. ora vị trí mặc định nếu hai mục nhập này không có trong tệp sqlnet.ora.

- Chỉ định vị trí ví dựa trên cài đặt biến môi trường, chẳng hạn như ORACLE_SID. Ví dụ: ENCRYPTION_WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /home/oracle/wallet/$ORACLE_SID)

- Sử dụng các tệp sqlnet.ora riêng biệt, một tệp cho mỗi cơ sở dữ liệu. Đảm bảo rằng đã đặt chính xác biến môi trường TNS_ADMIN để trỏ đến cấu hình cơ sở dữ liệu chính xác.

Hạn chế của TDE

Mặc dù có rất nhiều ưu điểm, nhưng TDE không cung cấp mã hóa trên kênh truyền thông. Khi kích hoạt TDE, phải sao lưu chứng thư và khóa riêng gắn với chứng thư đó. Nếu chứng thư không có sẵn hoặc phải khôi phục hay đính kèm CSDL trên một máy chủ khác, thì phải có bản sao lưu của cả chứng thư và khóa riêng. Nếu không, người dùng sẽ không thể truy cập thành công CSDL.

Bên cạnh đó, phải lưu lại chứng thư mã hóa ngay cả khi TDE không còn được kích hoạt trên CSDL. Mặc dù, CSDL không được mã hóa, nhưng khóa mã hóa CSDL cần được lưu trữ vì có thể cần phải được truy cập cho một số hoạt động.

Mặt khác, việc các chứng thư được bảo vệ bằng mật khẩu sau khi chúng được sử dụng bởi TDE sẽ gây ra việc CSDL không thể truy cập được sau khi khởi động lại.

Kết luận

Mặc dù mã hóa dữ liệu có vẻ như là một quá trình khó khăn, phức tạp, tuy nhiên với phương pháp TDE vấn đề này trở nên đơn giản hơn rất nhiều. Hiện nay hầu hết các hệ quản trị cơ sở dữ liệu mạnh đều hỗ trợ cơ chế mã hóa này, chẳng hạn như Oracle, SQL Server. Tùy vào từng hệ quản trị, các bước tiến hành mã hóa sẽ có thể khác nhau. Đây là phương pháp mã hóa dữ liệu được sử dụng rộng rãi hiện nay cho cơ sở dữ liệu. Tuy nhiên, để áp dụng mã hóa TDE bảo vệ cho dữ liệu nhạy cảm trong CSDL, quản trị viên cần thận trọng và quan tâm đến những vấn đề an toàn liên quan.