バックアップの暗号化：そのフィニッシュラインに到達する

公開: 2017-09-02

注：このエンジニアリング投稿は、データベース管理者のSilviaBotrosによって作成されました。 彼女の他のDBA投稿のいくつかをここでチェックしてください。

1年前、SendGridはSOC2認証に向けて懸命に取り組んでいました。誰もが関わっていました。第3四半期の終わりまでに認定されることを目指していたため、SOC2タグが付いたほぼすべての配信チームボードにストーリーがありました。ご想像のとおり、データベースの責任者であるため、スタックのその部分に対して行うべき作業が確かにありました。

このビジネス全体の取り組みの私のタスクリストには、バックアップが暗号化されていることを確認することが含まれていました。私の精通している分野はDBAツールであり、Perconaのxtrabackupがすでに暗号化をサポートしていることを知っているので、このタスクの最初の試みとしてそれに行くことは予測可能でした。

このアプローチをテストする際に、いくつかの重要なことが私の目に見えました。

明らかに、バックアップは暗号化する必要がありました
バックアップを作成するためのオーバーヘッドは、既知で許容できるものである必要がありました
リカバリ時にバックアップを復号化するためのオーバーヘッドは、既知で許容できるものである必要がありました

つまり、最初に、バックアップにかかる時間を追跡できる必要がありました。

バックアップ時間の追跡

SendGridはインフラストラクチャメトリックにGraphiteを使用し、大部分はSensu経由で送信されますが、Graphiteはbashラインを介してメトリックを直接送信するのに十分簡単です。バックアップスクリプトはbashであるため非常に便利です。 Graphiteでメトリックを直接送信することはそれほどスケーラブルではありませんが、これらのバックアップは最大で1時間に1回実行されるため、私のニーズには問題ありませんでした。

その部分は比較的簡単であることがわかりました。

その最後の行で何が起こったかを説明するために、送信するメトリックのパス（一意であることを確認してください）、メトリック値、そしてエポック形式の現在時刻をGraphiteに送信します。 Netcatは私が簡単にするために使用することに決めたものであり、1秒のタイムアウトを与えます。そうしないと、Netcatが終了することはありません。 `graphite url`は、データセンター内のGraphiteのDNSエンドポイントです。

比較するベースラインができたので、暗号化方式のテストを開始する準備が整いました。

これを行う方法に関するPerconaからの詳細なドキュメントに従って、私はキーを作成することから始めました。そのドキュメントページを注意深く読むと、何かに気付くかもしれません。

このキーはバックアップツールに直接渡され、スナップショットを復号化できるのと同じキーです。これは対称暗号化と呼ばれ、双方向の同じ鍵の性質上、非対称暗号化よりも安全性が低くなります。私は、単純さがこれを実行可能なアプローチにするかどうかを確認するためにテストを続けることにしました。

数百MBという非常に小さなDBでのテストは成功しました。ツールは期待どおりに機能し、文書化されていますが、それは機能テストであり、本当の問題は「大規模なDBでの暗号化のペナルティの大きさはどれくらいか」でした。 SendGridのよりレガシーなインスタンスは、1〜2TBから単一の18TBの獣のサイズに成長しました。私が小さなインスタンスに使用しようとしていたものは、大きなインスタンスでも操作上許容できるものでなければなりませんでした。

ここで、テストとベンチマークが面白くなりました

かなりのサイズの私の最初のテスト対象は、ディスク上に1TBのデータベースです。すぐに予期しない問題が発生しました。最小限の暗号化設定（1スレッド、デフォルトのチャンクサイズ）では、バックアップが次のエラーで失敗することがわかりました。

当時、これらのデータベースはトランザクションログファイルのサイズとして512MBを使用していましたが、これはかなりビジーなクラスターであるため、これらのファイルはほぼ毎分ローテーションしていました。通常、これはDBのパフォーマンスで顕著になりますが、ソリッドステートドライブの驚異によってほとんど隠されていました。並列暗号化スレッドを設定しないようです（読み取り：1つ使用）。つまり、 `.ibd`ファイルの暗号化に多くの時間を費やしているため、下からのinnodbREDOログロールによってバックアップが中断されていました。

それでは、いくつかの暗号化スレッドを使用してこれを再試行してみましょう。最初の試みとして、50スレッドで試しました。ここでの秘訣は、CPUをめぐって競合することなく、高速暗号化のスイートスポットを見つけることです。また、`ib_logfiles`のサイズをそれぞれ1GBに増やしました。

これは私が一晩醸造させて幸せだったより成功したテストでした。最初の数晩は、物事は良さそうだった。あまり大きくならないバックアップを作成するときが来ましたが、バックアッププロセス中のボックス負荷の平均は、追加された手順を明確に示していました。

ただし、復元のテストに移ったところ、暗号化を追加した後の同じバックアップの復元プロセスが60分から280分に増加したことがわかりました。これは、災害が発生した場合に約束された復旧時間に重大なペナルティを課すことを意味します。

それをより合理的な時間枠に戻す必要がありました。

これは、チームワークと問題に対するより簡単な解決策が輝いた場所です。 InfoSecチームメンバーの1人は、このソリューションを簡素化できるかどうかを確認することにしました。そこで彼はさらにテストを行い、よりシンプルで安全なものを持って戻ってきました。私はまだgpg2について学んでいなかったので、これは私にとっても学習演習になりました。

gpg2の良いところは、非対称暗号化をサポートしていることです。プライベート部分とパブリック部分があるキーペアを作成します。パブリック部分は、gpg2にフィードすることを決定したストリームまたはファイルを暗号化するために使用され、プライベートシークレットは復号化に使用できます。

これに暗号化を追加するためのバックアップスクリプトへの変更。これを読みやすくするために、いくつかの引数が削除されています。

一方、バックアップを復元するときは、受け入れ可能な秘密鍵がホストのキーリングにあることを確認してから、次のコマンドを使用する必要があります。

私もgpg2を初めて使用したので、これは私にとって学習の機会になりました。すばらしいInfoSecチームメンバーであるColinは、gpg2を使用すると、xtrabackupの組み込み圧縮を使用することに対して、次のような複数の利点があることを確認するまで、gpg2を使用してバックアップと復元をテストし続けました。

非対称でした
復号化のためのその秘密の管理は比較的簡単にローテーションされます（これについては以下で詳しく説明します）
これはツールに依存しません。つまり、xtrabackupを使用していない他の種類のバックアップでも同じ方法を使用できます。
復号化に複数のコアを使用していたため、復元時間が短縮されました

常に改善の余地

まだ改善の余地があると思う場所の1つは、これらのファイルを復号化できる秘密をどのように処理するかです。現在、エンタープライズパスワード管理ソリューションにそれらが含まれていますが、そこから取得し、バックアップをテストするために使用するのは手動のプロセスです。次の計画では、Vault by Hashicorpを実装し、それをシームレスに使用して、指定されたホストで、復号化のために秘密鍵をプルし、ローカルリングから削除して、自動テストで簡単に利用でき、保護された状態にすることです。

最終的に、バックアップのパフォーマンスやディザスタリカバリのSLAを犠牲にすることなく、SOC2のニーズに間に合うようにすべてのデータベースバックアップを取得しました。私はInfoSecチームと一緒にこの課題に取り組むことをとても楽しんで、新しいツールを学ぶことから生まれました。さらに、最も単純なソリューションが自分のタスクに最も適している場合は、常に便利です。