オフサイトのバックアップストレージは、組織のディザスタリカバリ計画の重要な部分である必要があります。データを別の物理的な場所に保存する機能は、プライマリデータセンター内のすべてのデータを破壊する壊滅的なイベントに耐えることができ、データの存続と組織の継続性を保証します。クラウドストレージサービスは、オフサイトのバックアップを保存するための非常に優れた方法です。クラウドプロバイダーを使用している場合でも、データを外部データセンターにコピーしている場合でも、そのような場合はバックアップの暗号化が必須です。以前のブログの1つで、バックアップを暗号化するいくつかの方法について説明しました。今日は、バックアップ暗号化に関するいくつかのベストプラクティスに焦点を当てます。
秘密が安全であることを確認する
データを暗号化および復号化するには、ある種のパスワードまたはキーを使用する必要があります。暗号化方法（対称または非対称）に応じて、暗号化と復号化の両方で1つの秘密にすることも、暗号化用の公開鍵と復号化用の秘密鍵にすることもできます。重要なのは、それらを安全に保つ必要があるということです。非対称暗号化を使用する場合は、バックアップの復号化に使用する秘密鍵に注目する必要があります。
キーはキー管理システムまたはボールトに保存できます。AmazonのKMSやHashicorpのボールトなど、市場には多数のオプションがあります。これらのソリューションを使用しないことにした場合でも、正しいユーザーだけがキーとパスワードにアクセスできるようにするなど、一般的なセキュリティ対策を適用する必要があります。また、実行中のプロセスのリストにキーやパスワードが表示されないように、バックアップスクリプトを準備することを検討する必要があります。理想的には、いくつかのコマンドの引数として渡すのではなく、ファイルに入れてください。
非対称暗号化を検討する
対称暗号化と非対称暗号化の主な違いは、暗号化と復号化の両方に対称暗号化を使用する一方で、単一のキーまたはパスワードを使用することです。これには、プロセスの両端でより高いセキュリティ基準が必要です。対称暗号化キーのリークにより、暗号化されたすべてのバックアップにアクセスできるようになるため、データを暗号化するホストが非常に安全であることを確認する必要があります。
一方、非対称暗号化を使用する場合は、データを暗号化するための公開鍵と復号化のための秘密鍵の2つの鍵があります。これにより、作業が非常に簡単になります。公開鍵を気にする必要はありません。侵害されたとしても、バックアップからのデータへのいかなる種類のアクセスも許可されません。秘密鍵のセキュリティのみに焦点を当てる必要があります。より簡単です-復元が時々行われる間、バックアップを毎日（より頻繁ではないにしても）暗号化する可能性が高く、秘密鍵をより安全な場所に（専用の物理デバイス上でも）保存することが可能になります。以下は、gpgを使用してキーペアを生成し、それを使用してデータを暗号化する方法の非常に簡単な例です。
まず、キーを生成する必要があります：
[email protected]:~# gpg --gen-key
gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <[email protected]>"
Real name: Krzysztof Ksiazek
Email address: [email protected]
Comment: Backup key
You selected this USER-ID:
"Krzysztof Ksiazek (Backup key) <[email protected]>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.これにより、公開鍵と秘密鍵の両方が作成されました。次に、データの暗号化に使用する公開鍵をエクスポートします。
gpg --armor --export [email protected] > mybackupkey.asc次に、それを使用してバックアップを暗号化できます。
[email protected]:~# xtrabackup --backup --stream=xbstream | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backup最後に、主キー（この場合はローカルキーリングに保存されています）を使用してバックアップを復号化する方法の例：
[email protected]:/backup# gpg -d /backup/pgp_encrypted.backup | gunzip | xbstream -x
encryption: using gcrypt 1.6.5
You need a passphrase to unlock the secret key for
user: "Krzysztof Ksiazek (Backup key) <[email protected]>"
4096-bit RSA key, ID E047CD69, created 2018-11-19 (main key ID BC341551)
gpg: gpg-agent is not available in this session
gpg: encrypted with 4096-bit RSA key, ID E047CD69, created 2018-11-19
"Krzysztof Ksiazek (Backup key) <[email protected]>"暗号化キーを回転させる
実装した暗号化の種類（対称または非対称）に関係なく、キーのローテーションについて考える必要があります。まず、キーを回転させるメカニズムを用意することが非常に重要です。これはセキュリティ違反の場合に役立つ可能性があり、バックアップの暗号化と復号化に使用するキーをすばやく変更する必要があります。もちろん、セキュリティ違反が発生した場合は、侵害されたキーを使用して暗号化された古いバックアップで何が起こるかを考慮する必要があります。目標復旧時点に従って有用で必要な場合もありますが、これらは危険にさらされています。それらを再暗号化するか、妥協のないローカリゼーションに移動するなど、いくつかのオプションがあります。
並列化することで暗号化プロセスを高速化
暗号化プロセスの並列化を実装するオプションがある場合は、それを検討してください。暗号化のパフォーマンスは主にCPUパワーに依存するため、より多くのCPUコアを並行して動作させてファイルを暗号化すると、暗号化時間が大幅に短縮されます。一部の暗号化ツールには、そのようなオプションがあります。そのうちの1つは、組み込み暗号化を使用してプロセスを並列化するオプションを備えたxtrabackupです。
探しているのは、埋め込み暗号化を有効にする「--encrypt-key」または「--encrypt-key-file」オプションのいずれかです。その際、「-encrypt-threads」と「--encrypt-chunk-size」を定義することもできます。次に、暗号化用の作業バッファーを増やし、最初に暗号化に使用するスレッドの数を定義します。
もちろん、これは実装できるソリューションの1つにすぎません。これは、シェルツールを使用して実現できます。以下の例：
[email protected]:~# files=2 ; mariabackup --user=root --backup --pass=pass --stream=xbstream |split -b 60M - backup ; ls backup* | parallel -j ${files} --workdir "$(pwd)" 'echo "encrypting {}" ; openssl enc -aes-256-cbc -salt -in "{}" -k mypass > "111{}"'達成したい並列化レベルに一致する事前定義された数のファイルにバックアップが分割されることを事前に知っておく必要があるため、これは決して完璧なソリューションではありません（2 CPUを使用する場合）コア、4コア、4ファイルなどを使用する場合は、2つのファイルが必要です。また、最初は分割を使用して複数のファイルを生成し、次に暗号化によって暗号化されたファイルの別のセットが作成されるため、バックアップの2倍のサイズのディスクスペースが必要です。一方、データセットのサイズが許容範囲内であり、暗号化のパフォーマンスを向上させたい場合は、それを検討することができます。バックアップを復号化するには、個々のファイルを復号化してから、「cat」を使用してそれらを結合する必要があります。
バックアップをテストする
バックアップ暗号化をどのように実装する場合でも、それをテストする必要があります。まず第一に、すべてのバックアップは、暗号化されているかどうかにかかわらず、テストする必要があります。バックアップが完了していないか、何らかの種類の破損が発生している可能性があります。実際に復元を実行するまで、バックアップを復元できるかどうかを確認することはできません。そのため、定期的なバックアップ検証が必須です。暗号化により、バックアッププロセスがさらに複雑になります。暗号化時に問題が発生する可能性があります。バグや不具合により、暗号化されたファイルが破損する可能性があります。暗号化されたら、問題はそれを復号化して復元できるかどうかです。
復元テストプロセスを実施する必要があります。理想的には、復元テストは各バックアップの後に実行されます。少なくとも、バックアップを1年に数回テストする必要があります。バックアッププロセスに変更が加えられたらすぐにテストする必要があります。バックアップに圧縮を追加しましたか？暗号化方式を変更しましたか？暗号化キーをローテーションしましたか？これらのアクションはすべて、実際にバックアップを復元する能力に何らかの影響を与える可能性があります。したがって、変更のたびにプロセス全体をテストする必要があります。
ClusterControlは、オンデマンドまたはすべてのバックアップ後にスケジュールされた検証プロセスを自動化できます。
既存のバックアップを確認するには、リストからバックアップを選択し、[復元]オプションをクリックして、復元ウィザードを実行するだけです。まず、復元するバックアップを確認する必要があります。
次に、次の手順で、復元と確認のオプションを選択する必要があります。
復元をテストするホストに関する情報を渡す必要があります。 ClusterControlインスタンスからSSH経由でアクセスできる必要があります。復元テストサーバーを稼働させたままにするか（部分的な復元を行う場合は、サーバーから部分的なデータをダンプする）、またはシャットダウンするかを決定できます。
最後のステップは、正しい選択をしたかどうかを確認することです。はいの場合、バックアップ検証ジョブを開始できます。
検証が正常に完了すると、バックアップのリストでバックアップが検証済みとしてマークされていることがわかります。
このプロセスを自動化する場合は、ClusterControlを使用することもできます。バックアップをスケジュールするときに、バックアップ検証を有効にできます：
これにより、バックアップスケジュールウィザードに別の手順が追加されます。
ここでも、バックアップ復元テストに使用するホストを定義し、そのホストにソフトウェアをインストールするかどうか（または、すでに実行済みかどうか）、復元サーバーを稼働させ続けるかどうか、およびバックアップが完了した直後にテストするか、少し待ちたい場合があります。