Mysql mã hóa dữ liệu như thế nào?

Data at Rest Encryption không chỉ là một tính năng nên có mà còn là một yêu cầu đối với HIPAA, PCI và các quy định khác

Có ba cách chính để giải mã hóa dữ liệu khi nghỉ ngơi

1. Mã hóa toàn bộ đĩa
2. Mã hóa cấp cơ sở dữ liệu [bảng]
3. Mã hóa cấp ứng dụng, nơi dữ liệu được mã hóa trước khi đưa vào cơ sở dữ liệu

Tôi coi mã hóa toàn bộ đĩa là phương pháp yếu nhất vì nó chỉ bảo vệ khỏi ai đó đang lấy đĩa ra khỏi máy chủ. Mặt khác, mã hóa cấp ứng dụng là tốt nhất. đây là phương pháp linh hoạt nhất mà hầu như không có chi phí hoạt động và nó cũng giải quyết được mã hóa dữ liệu trên máy bay. Rất tiếc, không phải lúc nào cũng có thể thay đổi mã ứng dụng để hỗ trợ mã hóa cấp ứng dụng nên mã hóa cấp cơ sở dữ liệu có thể là một giải pháp thay thế hữu ích

Sergei Golubchik, Kiến trúc sư trưởng tại MariaDB, đã nêu ra những ưu điểm và nhược điểm của mã hóa cấp cơ sở dữ liệu trong phiên làm việc của ông tại Percona Live Amsterdam

Ưu điểm của mã hóa mức cơ sở dữ liệu

• Toàn bộ sức mạnh của DBMS có sẵn
• Có đầy đủ sức mạnh của DBMS Dễ thực hiện
• Dễ thực hiện – Chỉ có cơ sở dữ liệu mới có thể xem dữ liệu
• Chỉ cơ sở dữ liệu mới có thể xem dữ liệu – Mã hóa trên mỗi bảng, khóa trên mỗi bảng, hiệu suất
• Mã hóa trên mỗi bảng, khóa trên mỗi bảng, hiệu suất

Nhược điểm của mã hóa cấp cơ sở dữ liệu

• Không thể được thực hiện cho mỗi người dùng
• Không bảo vệ chống lại người dùng root độc hại

Dữ liệu khi mã hóa phần còn lại. Tùy chọn cấp cơ sở dữ liệu

Hiện tại, có hai tùy chọn để mã hóa dữ liệu ở trạng thái nghỉ ở cấp cơ sở dữ liệu

• MariaDB 10. 1. 3+ mã hóa hỗ trợ [sử dụng bản vá của Google]
• mysql 5. 7. 11+ [và Máy chủ Percona 5. 7. 11] có mã hóa mức không gian bảng InnoDB

Việc triển khai MariaDB khác với MySQL 5. 7. 11. mysql 5. 7. 11 chỉ mã hóa [các] vùng bảng InnoDB, trong khi  MariaDB có tùy chọn mã hóa nhật ký hoàn tác/làm lại, nhật ký nhị phân/nhật ký chuyển tiếp, v.v. Tuy nhiên, có một số hạn chế [đặc biệt là cùng với Galera Cluster].

• Không xoay vòng phím trong phiên bản plugin mã nguồn mở [MySQL 5. 7. 11 có xoay phím]
• mysqlbinlog không hoạt động với các binlog được mã hóa [đã báo cáo lỗi]
• Percona XtraBackup không hoạt động, vì vậy chúng tôi bị giới hạn ở RSYNC dưới dạng phương thức SST cho Galera Cluster, đây là một phương thức chặn [một nút sẽ không khả dụng để ghi trong SST]. Percona XtraBackup mới nhất hoạt động với MySQL 5. 7. 11 mã hóa không gian bảng
• Dữ liệu sau không được mã hóa [báo cáo lỗi]
  • Galera gcache + Dữ liệu sao chép Galera
  • Nhật ký chung / nhật ký truy vấn chậm

Mã hóa cấp cơ sở dữ liệu cũng có điểm yếu

1. Người dùng root và MySQL có thể đọc tệp khóa, điều này không đạt được mục đích. Tuy nhiên, có thể đặt một khóa trên ổ đĩa được gắn và ngắt kết nối nó khi MySQL khởi động [có thể được viết theo kịch bản]. Nhược điểm của điều này là nếu MySQL gặp sự cố, nó sẽ không tự động khởi động lại nếu không có sự can thiệp của con người
2. Cả phiên bản MariaDB và phiên bản MySQL đều chỉ mã hóa dữ liệu khi ghi vào đĩa – dữ liệu không được mã hóa trong RAM, vì vậy người dùng root có thể đính kèm vào MySQL bằng gdb/strace hoặc các công cụ khác và đọc bộ nhớ máy chủ. Ngoài ra với gdb có thể thay đổi cấu trúc mật khẩu user root rồi dùng mysqldump để copy dữ liệu. Một phương pháp tiềm năng khác là giết MySQL và bắt đầu nó với bỏ qua các bảng cấp. Tuy nhiên, nếu khóa không được đếm [i. e. , trên ổ USB], MySQL sẽ không khởi động hoặc không thể đọc vùng bảng được mã hóa

Ví dụ mã hóa MariaDB

Để bật mã hóa toàn bộ, chúng tôi có thể thêm các tùy chọn sau vào. cnf

1

2

3

4

5

6

7

8

9

10

11

[mysqld]

plugin -tải-thêm=file_key_management.so

file_key_manager_filekey = FILE . /mount /key/ mysql. phím

tệp-khóa- quản lý -filename = /mount/keys/mysql.enc

innodb-mã hóa-bảng = ON

innodb-mã hóa-log = 1

innodb- mã hóa - luồng =1

mã hóa- tmp - đĩa -tables=1

mã hóa- tmp - tệp =1

mã hóa-binlog= 1

file_key_manager_encryption_algorithm = AES_CTR

Sau khi khởi động MariaDB với các cài đặt đó, nó sẽ bắt đầu mã hóa cơ sở dữ liệu ở chế độ nền. Plugin quản lý_khóa_tệp được sử dụng; . Các khóa thực tế được mã hóa bằng

1

# openssl enc -aes-256-cbc -md sha1 -k -in keys.txt -out mysql.enc

The encryption is placed in /mount/keys/mysql.key.

Sau khi khởi động MySQL, chúng ta có thể ngắt kết nối phân vùng “/mount/key”. Trong trường hợp này, khóa sẽ không khả dụng và một hacker tiềm ẩn sẽ không thể khởi động lại MySQL với tùy chọn “–skip-grant-tables” [không có mật khẩu]. Tuy nhiên, nó cũng ngăn khởi động lại bình thường, đặc biệt là SST [đồng bộ hóa toàn bộ cụm]

Ghi chú bổ sung

1. Mã hóa sẽ ảnh hưởng đến tỷ lệ nén, đặc biệt đối với các bản sao lưu vật lý [bản sao lưu logic, i. e. mysqldump không thành vấn đề vì dữ liệu được truy xuất không được mã hóa]. Nếu kích thước bản sao lưu nén ban đầu của bạn chỉ bằng 10% kích thước cơ sở dữ liệu, thì đó sẽ không phải là trường hợp của các bảng được mã hóa
2. Dữ liệu không được mã hóa trong chuyến bay và sẽ không được mã hóa trên các nô lệ sao chép trừ khi bạn bật các tùy chọn tương tự trên các nô lệ. Mã hóa cũng là cục bộ của máy chủ, vì vậy khi mã hóa vừa được bật trên máy chủ, một số bảng có thể chưa được mã hóa [nhưng cuối cùng sẽ được mã hóa]
3. Để kiểm tra xem bảng nào đã được mã hóa, hãy sử dụng bảng Lược đồ thông tin INNODB_TABLESPACES_ENCRYPTION chứa thông tin mã hóa. Để tìm tất cả các bảng được mã hóa, hãy sử dụng truy vấn này
   
   mysql

   1

   chọn * từ information_schema. INNODB_TABLESPACES_ENCRYPTION ở đâu  ENCRYPTION_SCHEME = 1

mysql 5. 7 Ví dụ mã hóa

Để kích hoạt mã hóa, hãy thêm tùy chọn sau vào. cnf

1

2

3

[mysqld]

sớm - plugin -tải=keyring_file.so

keyring_file_data=/mount / mysql - keyring< /keyring

Một lần nữa, sau khi khởi động MySQL, chúng ta có thể ngắt kết nối phân vùng “/mount/mysql-keyring/”

Để bắt đầu mã hóa bảng, chúng ta cần chạy alter table table_name encryption='Y' , as MySQL will not encrypt tables by default.

Percona Xtrabackup mới nhất cũng hỗ trợ mã hóa và có thể sao lưu các bảng được mã hóa

Để tìm tất cả các không gian bảng được mã hóa trong MySQL/Percona Server 5. 7. 11, chúng ta có thể sử dụng information_schema. INNODB_SYS_TABLESPACES và trường cờ. Ví dụ: để tìm các bảng được mã hóa thông thường, hãy sử dụng truy vấn sau

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

mysql > chọn * từ information_schema.INNODB_SYS_TABLESPACES ở đâu cờ = 8225G

*************************** 1. hàng ***************************

         SPACE . 4688

           TÊN. kiểm tra / t1

           CỜ. 8225

   FILE_FORMAT. Cá nhồng

    ROW_FORMAT . Động

     PAGE_SIZE. 16384

ZIP_PAGE_SIZE. 0

     SPACE_TYPE. Độc thân

FS_BLOCK_SIZE. 4096

     FILE_SIZE. 98304

ALLOCATED_SIZE. 98304

*************************** 2. hàng ***************************

         SPACE . 4697

           TÊN. sbtest / sbtest1_enc

           CỜ. 8225

   FILE_FORMAT. Cá nhồng

    ROW_FORMAT . Động

     PAGE_SIZE. 16384

ZIP_PAGE_SIZE. 0

     SPACE_TYPE. Độc thân

FS_BLOCK_SIZE. 4096

     FILE_SIZE. 255852544

ALLOCATED_SIZE. 255856640

2 hàng trong bộ [0. 00 giây]

Bạn cũng có thể sử dụng truy vấn này để thay thế. chọn * từ lược đồ thông tin. bảng nơi CREATE_OPTIONS thích '%ENCRYPTION="Y"%'< . ;.

chi phí hoạt động

Đây là một chủ đề gây tranh cãi, đặc biệt đối với việc triển khai MariaDB khi mọi thứ được định cấu hình để mã hóa. Trong các thử nghiệm của mình, tôi đã thấy ~10% chi phí cho phiên bản MySQL độc lập và ~20% với Galera Cluster

MySQL5. 7/Máy chủ Percona 5. 7 mã hóa mức không gian bảng cho thấy chi phí cực kỳ thấp, tuy nhiên, điều đó cần được kiểm tra trong các điều kiện khác nhau

Phần kết luận

Ngay cả với tất cả các giới hạn trên, mã hóa cấp cơ sở dữ liệu có thể là một lựa chọn tốt hơn so với mã hóa cấp hệ thống tệp nếu không thể thay đổi ứng dụng. Tuy nhiên, nó là một tính năng mới [đặc biệt là MySQL 5. 7. 11] và tôi mong đợi một số lỗi ở đây

MySQL sử dụng loại mã hóa nào?

Làm cách nào để mã hóa dữ liệu trong bảng MySQL?

MySQL mã hóa mật khẩu như thế nào?

MySQL cung cấp bảo mật như thế nào?