高価なスマートフォンであろうと会社のサーバーであろうと、私たちは通常、大切なものを世話します。データは組織の最も重要な資産の1つであり、私たちにはわかりませんが、慎重に保護する必要があります。保存データの暗号化を実装して、データを含むデータベースファイルまたはボリューム全体を暗号化します。 SSLを使用して転送中のデータ暗号化を実装し、ネットワークを介して送信されるデータをだれも盗聴して収集できないようにします。バックアップも例外ではありません。これが完全バックアップであるか増分バックアップであるかに関係なく、データの少なくとも一部が保存されます。そのため、バックアップも暗号化する必要があります。このブログ投稿では、バックアップの暗号化に関していくつかのオプションを検討します。ただし、最初に、バックアップを暗号化する方法と、それらの方法の使用例を見てみましょう。
バックアップを暗号化する方法
ローカルファイルを暗号化する
まず、既存のファイルを簡単に暗号化できます。すべてのバックアップをバックアップサーバーに保存するバックアッププロセスがあると想像してみてください。ある時点で、ディザスタリカバリのためにオフサイトのバックアップストレージを実装する時期が来たと判断しました。そのために、他のクラウドプロバイダーのS3または同様のインフラストラクチャを使用できます。もちろん、暗号化されていないバックアップを信頼できるネットワークの外部にアップロードすることは望ましくないため、バックアップの暗号化を何らかの方法で実装することが重要です。既存のバックアップスクリプトに変更を加える必要がない非常に簡単な方法は、バックアップファイルを取得し、暗号化してS3にアップロードするスクリプトを作成することです。データの暗号化に使用できる方法の1つは、opensslを使用することです：
openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpasswordこれにより、現在のディレクトリに新しい暗号化ファイル「backup_file.tar.gz.enc」が作成されます。次を実行することで、後でいつでも復号化できます：
openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpasswordこの方法は非常に簡単ですが、いくつかの欠点があります。最大のものは、ディスク容量の要件です。上記のように暗号化する場合、暗号化されていないファイルと暗号化されたファイルの両方を保持する必要があり、その結果、バックアップファイルの2倍のサイズのディスクスペースが必要になります。もちろん、要件によっては、これが必要な場合もあります。暗号化されていないファイルをローカルに保持すると、リカバリ速度が向上します。結局、データの復号化にも時間がかかります。
バックアップをオンザフライで暗号化
暗号化されたデータと暗号化されていないデータの両方を保存する必要がないように、バックアッププロセスの初期段階で暗号化を実装することをお勧めします。私たちはパイプを通してそれを行うことができます。パイプは、要するに、あるコマンドから別のコマンドにデータを送信する方法です。これにより、データを処理する一連のコマンドを作成できます。データを生成し、それを圧縮して暗号化することができます。このようなチェーンの例は次のとおりです。
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.encこの方法は、xtrabackupまたはmariabackupでも使用できます。実際、これはMariaDBドキュメントの例です：
mariabackup --user=root --backup --stream=xbstream | openssl enc -aes-256-cbc -k mypass > backup.xb.enc必要に応じて、プロセスの一部としてデータをアップロードすることもできます。
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その結果、ローカルファイル「mysqldump.gz.enc」が表示され、データのコピーがプログラムにパイプされ、プログラムがそれに対して何かを実行します。 「nc」を使用しました。これは、以下が実行された別のホストにデータをストリーミングしました。
nc -l 9991 > backup.gz.encこの例では、mysqldumpとncを使用しましたが、xtrabackupまたはmariabackupと、Amazon S3、Google Cloud Storage、またはその他のクラウドプロバイダーにストリームをアップロードするツールを使用できます。 「nc」の代わりに、stdin上のデータを受け入れる任意のプログラムまたはスクリプトを使用できます。
埋め込み暗号化を使用する
場合によっては、バックアップツールに暗号化のサポートが組み込まれています。ここでの例は、ファイルを内部で暗号化できるxtrabackupです。残念ながら、mariabackupは、xtrabackupのフォークですが、この機能をサポートしていません。
使用する前に、データの暗号化に使用するキーを作成する必要があります。次のコマンドを実行することで実行できます：
[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1FhunjbXtrabackupは、プレーンテキスト形式のキーを受け入れるか（--encrypt-keyオプションを使用）、ファイルからキーを読み取ることができます（--encrypt-key-fileオプションを使用）。後者の方が安全です。パスワードとキーをプレーンテキストとしてコマンドに渡すと、それらがbash履歴に保存されるからです。実行中のプロセスのリストでもはっきりと確認できますが、これは非常に悪いことです：
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/理想的には、ファイルに保存されているキーを使用しますが、注意しなければならない小さな落とし穴があります。
[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.あなたは問題が何であるか疑問に思うかもしれません。 hexeditのような16進エディタでencrypt.keyファイルを開くと明らかになります：
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.これで、「0A」を使用してエンコードされた最後の文字に気付くことができます。これは基本的に改行文字ですが、暗号化キーを評価する際に考慮されます。削除すると、最終的にバックアップを実行できます。
[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その結果、暗号化されたファイルでいっぱいのバックアップディレクトリができあがります：
[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.xbcryptXtrabackupには、暗号化パフォーマンスを調整するために使用できる他の変数がいくつかあります。
- -encrypt-threadsにより、暗号化プロセスの並列化が可能になります
- -encrypt-chunk-sizeは、暗号化プロセス用の作業バッファーを定義します。
ファイルを復号化する必要がある場合は、-decryptオプションを指定してinnobackupexを使用できます。
[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/xtrabackupは暗号化されたファイルをクリーンアップしないため、次のワンライナーを使用してそれらを削除することをお勧めします。
for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; doneClusterControlでのバックアップ暗号化
ClusterControlを使用すると、暗号化されたバックアップをワンクリックで実行できます。すべてのバックアップ方法（mysqldump、xtrabackup、またはmariabackup）は暗号化をサポートしています。アドホックにバックアップを作成することも、バックアップのスケジュールを準備することもできます。
この例では、完全なエクストラバックアップを選択し、それをコントローラーインスタンスに保存します。
次のページで、暗号化を有効にしました。前述のように、ClusterControlは自動的に暗号化キーを作成します。これで、[バックアップの作成]ボタンをクリックするとプロセスが開始されます。
新しいバックアップがバックアップリストに表示されます。暗号化されているとマークされています（鍵のアイコン）。
このブログ投稿で、バックアップが適切に暗号化されていることを確認する方法についての洞察が得られることを願っています。