MariaDB
 sql >> Cơ Sở Dữ Liệu >  >> RDS >> MariaDB

Cách mã hóa bản sao lưu MySQL &MariaDB của bạn

Chúng tôi thường quan tâm đến những thứ mà chúng tôi đánh giá cao, cho dù đó là điện thoại thông minh đắt tiền hay máy chủ của công ty. Dữ liệu là một trong những tài sản quan trọng nhất của tổ chức và mặc dù chúng ta không nhìn thấy nó, nhưng nó phải được bảo vệ cẩn thận. Chúng tôi triển khai mã hóa dữ liệu ở trạng thái còn lại để mã hóa các tệp cơ sở dữ liệu hoặc toàn bộ khối lượng chứa dữ liệu của chúng tôi. Chúng tôi triển khai mã hóa dữ liệu chuyển tiếp bằng SSL để đảm bảo không ai có thể đánh hơi và thu thập dữ liệu được gửi qua các mạng. Các bản sao lưu không có gì khác biệt. Bất kể đây là bản sao lưu đầy đủ hay tăng dần, nó sẽ lưu trữ ít nhất một phần dữ liệu của bạn. Do đó, các bản sao lưu cũng phải được mã hóa. Trong bài đăng trên blog này, chúng tôi sẽ xem xét một số tùy chọn bạn có thể có khi mã hóa các bản sao lưu. Tuy nhiên, trước tiên, hãy xem cách bạn có thể mã hóa các bản sao lưu của mình và những trường hợp sử dụng có thể là gì đối với những phương pháp đó.

Làm cách nào để mã hóa bản sao lưu của bạn?

Mã hóa tệp cục bộ

Trước hết, bạn có thể dễ dàng mã hóa các tệp hiện có. Hãy tưởng tượng rằng bạn có một quy trình sao lưu lưu trữ tất cả các bản sao lưu của bạn trên một máy chủ dự phòng. Tại một số thời điểm, bạn đã quyết định rằng đây là thời điểm thích hợp để triển khai bộ nhớ dự phòng ngoại vi để khắc phục thảm họa. Bạn có thể sử dụng S3 hoặc cơ sở hạ tầng tương tự từ các nhà cung cấp đám mây khác cho việc đó. Tất nhiên, bạn không muốn tải lên các bản sao lưu không được mã hóa ở bất kỳ đâu bên ngoài mạng đáng tin cậy của mình, do đó, điều quan trọng là bạn phải triển khai mã hóa sao lưu theo cách này hay cách khác. Một phương pháp rất đơn giản, không yêu cầu bất kỳ thay đổi nào trong các tập lệnh sao lưu hiện có của bạn sẽ là tạo một tập lệnh sẽ lấy một tệp sao lưu, mã hóa nó và tải nó lên S3. Một trong những phương pháp bạn có thể sử dụng để mã hóa dữ liệu là sử dụng openssl:

openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpassword

Thao tác này sẽ tạo một tệp mới, được mã hóa, ‘backup_file.tar.gz.enc’ trong thư mục hiện tại. Bạn luôn có thể giải mã nó sau này bằng cách chạy:

openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpassword

Phương pháp này rất đơn giản, nhưng nó có một số hạn chế. Điều lớn nhất là yêu cầu về dung lượng ổ đĩa. Khi mã hóa như chúng tôi đã mô tả ở trên, bạn phải giữ lại cả tệp chưa mã hóa và được mã hóa và kết quả là bạn yêu cầu dung lượng đĩa lớn gấp đôi kích thước của tệp sao lưu. Tất nhiên, tùy thuộc vào yêu cầu của bạn, đây có thể là điều bạn muốn - giữ các tệp không được mã hóa cục bộ sẽ cải thiện tốc độ khôi phục - sau khi tất cả việc giải mã dữ liệu cũng sẽ mất một khoảng thời gian.

Mã hóa sao lưu khi đang di chuyển

Để tránh nhu cầu lưu trữ cả dữ liệu được mã hóa và không được mã hóa, bạn có thể muốn thực hiện mã hóa ở giai đoạn trước của quá trình sao lưu. Chúng tôi có thể làm điều đó thông qua các đường ống. Tóm lại, Pipes là một cách để gửi dữ liệu từ lệnh này sang lệnh khác. Điều này giúp bạn có thể tạo một chuỗi lệnh xử lý dữ liệu. Bạn có thể tạo dữ liệu, sau đó nén và mã hóa. Ví dụ về chuỗi như vậy có thể là:

mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl  enc -aes-256-cbc -k mypass > backup.xb.enc

Bạn cũng có thể sử dụng phương pháp này với xtrabackup hoặc mariabackup. Trên thực tế, đây là ví dụ từ tài liệu MariaDB:

mariabackup --user=root --backup --stream=xbstream  | openssl  enc -aes-256-cbc -k mypass > backup.xb.enc

Nếu muốn, bạn thậm chí có thể thử tải lên dữ liệu như một phần của quy trình:

mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl  enc -aes-256-cbc -k mysecretpassword | tee -a mysqldump.gz.enc | nc 10.0.0.102 9991

Kết quả là, bạn sẽ thấy một tệp cục bộ ‘mysqldump.gz.enc’ và bản sao của dữ liệu sẽ được chuyển tới một chương trình sẽ thực hiện điều gì đó về nó. Chúng tôi đã sử dụng ‘nc’, truyền dữ liệu đến một máy chủ khác, trên đó thực thi các lệnh sau:

nc -l 9991 > backup.gz.enc

Trong ví dụ này, chúng tôi đã sử dụng mysqldump và nc nhưng bạn có thể sử dụng xtrabackup hoặc mariabackup và một số công cụ sẽ tải luồng lên Amazon S3, Google Cloud Storage hoặc một số nhà cung cấp dịch vụ đám mây khác. Bất kỳ chương trình hoặc tập lệnh nào chấp nhận dữ liệu trên stdin đều có thể được sử dụng thay cho ‘nc’.

Sử dụng mã hóa nhúng

Trong một số trường hợp, một công cụ sao lưu có hỗ trợ mã hóa được nhúng. Một ví dụ ở đây là xtrabackup, có thể mã hóa nội bộ tệp. Rất tiếc, mariabackup, mặc dù là một nhánh của xtrabackup, không hỗ trợ tính năng này.

Trước khi có thể sử dụng nó, chúng ta phải tạo một khóa sẽ được sử dụng để mã hóa dữ liệu. Nó có thể được thực hiện bằng cách chạy lệnh sau:

[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1Fhunjb

Xtrabackup có thể chấp nhận khóa ở định dạng văn bản thuần túy (sử dụng tùy chọn --encrypt-key) hoặc có thể đọc khóa từ tệp (sử dụng tùy chọn --encrypt-key-file). Cách sau an toàn hơn vì chuyển mật khẩu và khóa dưới dạng văn bản thuần túy đến các lệnh dẫn đến việc lưu trữ chúng trong lịch sử cơ sở. Bạn cũng có thể thấy rõ điều đó trên danh sách các tiến trình đang chạy, điều này khá tệ:

root      1130  0.0  0.6  65508  4988 ?        Ss   00:46   0:00 /usr/sbin/sshd -D
root     13826  0.0  0.8  93100  6648 ?        Ss   01:26   0:00  \_ sshd: [email protected]
root     25363  0.0  0.8  92796  6700 ?        Ss   08:54   0:00  \_ sshd: vagrant [priv]
vagrant  25393  0.0  0.6  93072  4936 ?        S    08:54   0:01  |   \_ sshd: [email protected]/1
vagrant  25394  0.0  0.4  21196  3488 pts/1    Ss   08:54   0:00  |       \_ -bash
root     25402  0.0  0.4  52700  3568 pts/1    S    08:54   0:00  |           \_ sudo su -
root     25403  0.0  0.4  52284  3264 pts/1    S    08:54   0:00  |               \_ su -
root     25404  0.0  0.4  21196  3536 pts/1    S    08:54   0:00  |                   \_ -su
root     26686  6.0  4.0 570008 30980 pts/1    Sl+  09:48   0:00  |                       \_ innobackupex --encrypt=AES256 --encrypt-key=TzIZ7g+WzLt0PXWf8WDPf/sjIt7UzCKw /backup/

Lý tưởng nhất là bạn sẽ sử dụng khóa được lưu trữ trong một tệp nhưng sau đó, có một lỗi nhỏ mà bạn phải biết.

[email protected]:~# openssl rand -base64 24 > encrypt.key
[email protected]:~# innobackupex --encrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/
.
.
.
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
encryption: unable to set libgcrypt cipher key - User defined source 1 : Invalid key length
encrypt: failed to create worker threads.
Error: failed to initialize datasink.

Bạn có thể tự hỏi vấn đề là gì. Sẽ trở nên rõ ràng khi chúng tôi mở tệp mã hóa.key trong trình chỉnh sửa hệ thập lục phân như hexedit:

00000000   6D 6B 2B 4B  66 69 55 4E  5A 49 48 77  39 42 36 72  68 70 39 79  6A 56 44 72  47 61 79 45  6F 75 6D 70  0A                                     mk+KfiUNZIHw9B6rhp9yjVDrGayEoump.

Bây giờ bạn có thể nhận thấy ký tự cuối cùng được mã hóa bằng ‘0A’. Về cơ bản đây là ký tự nguồn cấp dữ liệu dòng, nhưng nó được xem xét trong khi đánh giá khóa mã hóa. Sau khi chúng tôi xóa nó, cuối cùng chúng tôi có thể chạy bản sao lưu.

[email protected]:~# innobackupex --encrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/
xtrabackup: recognized server arguments: --datadir=/var/lib/mysql --innodb_buffer_pool_size=185M --innodb_flush_log_at_trx_commit=2 --innodb_file_per_table=1 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_read_io_threads=4 --innodb_write_io_threads=4 --innodb_doublewrite=1 --innodb_log_file_size=64M --innodb_log_buffer_size=16M --innodb_log_files_in_group=2 --innodb_flush_method=O_DIRECT --server-id=1
xtrabackup: recognized client arguments: --datadir=/var/lib/mysql --innodb_buffer_pool_size=185M --innodb_flush_log_at_trx_commit=2 --innodb_file_per_table=1 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_read_io_threads=4 --innodb_write_io_threads=4 --innodb_doublewrite=1 --innodb_log_file_size=64M --innodb_log_buffer_size=16M --innodb_log_files_in_group=2 --innodb_flush_method=O_DIRECT --server-id=1 --databases-exclude=lost+found --ssl-mode=DISABLED
encryption: using gcrypt 1.6.5
181116 10:11:25 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".

181116 10:11:25  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/var/lib/mysql/mysql.sock' as 'backupuser'  (using password: YES).
181116 10:11:25  version_check Connected to MySQL server
181116 10:11:25  version_check Executing a version check against the server...
181116 10:11:25  version_check Done.
181116 10:11:25 Connecting to MySQL server host: localhost, user: backupuser, password: set, port: not set, socket: /var/lib/mysql/mysql.sock
Using server version 5.7.23-23-57
innobackupex version 2.4.12 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 170eb8c)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup:   innodb_data_home_dir = .
xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup:   innodb_log_group_home_dir = ./
xtrabackup:   innodb_log_files_in_group = 2
xtrabackup:   innodb_log_file_size = 67108864
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
181116 10:11:25 >> log scanned up to (2597648)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 19 for mysql/server_cost, old maximum was 0
181116 10:11:25 [01] Encrypting ./ibdata1 to /backup/2018-11-16_10-11-25/ibdata1.xbcrypt
181116 10:11:26 >> log scanned up to (2597648)
181116 10:11:27 >> log scanned up to (2597648)
181116 10:11:28 [01]        ...done
181116 10:11:28 [01] Encrypting ./mysql/server_cost.ibd to /backup/2018-11-16_10-11-25/mysql/server_cost.ibd.xbcrypt
181116 10:11:28 [01]        ...done
181116 10:11:28 [01] Encrypting ./mysql/help_category.ibd to /backup/2018-11-16_10-11-25/mysql/help_category.ibd.xbcrypt
181116 10:11:28 [01]        ...done
181116 10:11:28 [01] Encrypting ./mysql/slave_master_info.ibd to /backup/2018-11-16_10-11-25/mysql/slave_master_info.ibd.xbcrypt
181116 10:11:28 [01]        ...done

Kết quả là chúng tôi sẽ kết thúc với một thư mục sao lưu chứa đầy các tệp được mã hóa:

[email protected]:~# ls -alh /backup/2018-11-16_10-11-25/
total 101M
drwxr-x---  5 root root 4.0K Nov 16 10:11 .
drwxr-xr-x 16 root root 4.0K Nov 16 10:11 ..
-rw-r-----  1 root root  580 Nov 16 10:11 backup-my.cnf.xbcrypt
-rw-r-----  1 root root  515 Nov 16 10:11 ib_buffer_pool.xbcrypt
-rw-r-----  1 root root 101M Nov 16 10:11 ibdata1.xbcrypt
drwxr-x---  2 root root 4.0K Nov 16 10:11 mysql
drwxr-x---  2 root root  12K Nov 16 10:11 performance_schema
drwxr-x---  2 root root  12K Nov 16 10:11 sys
-rw-r-----  1 root root  113 Nov 16 10:11 xtrabackup_checkpoints
-rw-r-----  1 root root  525 Nov 16 10:11 xtrabackup_info.xbcrypt
-rw-r-----  1 root root 2.7K Nov 16 10:11 xtrabackup_logfile.xbcrypt

Xtrabackup có một số biến khác có thể được sử dụng để điều chỉnh hiệu suất mã hóa:

  • --encrypt-thread cho phép song song quá trình mã hóa
  • --encrypt-chunk-size xác định một bộ đệm hoạt động cho quá trình mã hóa.

Nếu bạn cần giải mã các tệp, bạn có thể sử dụng innobackupex với tùy chọn --decrypt cho điều đó:

[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/

Vì xtrabackup không làm sạch các tệp được mã hóa, bạn có thể muốn xóa chúng bằng cách sử dụng một lớp lót sau:

for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; done

Mã hóa sao lưu trong ClusterControl

Với ClusterControl, các bản sao lưu được mã hóa chỉ bằng một cú nhấp chuột. Tất cả các phương pháp sao lưu (mysqldump, xtrabackup hoặc mariabackup) đều hỗ trợ mã hóa. Bạn có thể vừa tạo một bản sao lưu đột xuất hoặc bạn có thể chuẩn bị một lịch trình cho các bản sao lưu của mình.

Trong ví dụ của chúng tôi, chúng tôi đã chọn một xtrabackup đầy đủ, chúng tôi sẽ lưu trữ nó trên phiên bản controller.

Trên trang tiếp theo, chúng tôi đã bật mã hóa. Như đã nêu, ClusterControl sẽ tự động tạo khóa mã hóa cho chúng tôi. Vậy là xong, khi bạn nhấp vào nút “Tạo bản sao lưu”, một quá trình sẽ được bắt đầu.

Bản sao lưu mới hiển thị trên danh sách sao lưu. Nó được đánh dấu là đã mã hóa (biểu tượng ổ khóa).

Chúng tôi hy vọng rằng bài đăng trên blog này cung cấp cho bạn một số thông tin chi tiết về cách đảm bảo các bản sao lưu của bạn được mã hóa đúng cách.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Cách STRCMP () hoạt động trong MariaDB

  2. 20 Mẹo:Chuẩn bị cơ sở dữ liệu của bạn cho Thứ Sáu Đen và Thứ Hai Điện Tử

  3. Phần 2:Phân loại hình ảnh với Máy chủ MariaDB và TensorFlow - Hướng dẫn

  4. Cách chạy SHOW LOCALES trong MariaDB

  5. DROP BẢNG NẾU TỒN TẠI trong MariaDB