セルフホスト環境のバックアップ (Pro)

デプロイはデータベースだけで成り立っているわけではありません。データベースのみを取得したバックアップを復元すると、システム自体は動作するものの、アップロードされたファイルが欠けており、他のツール用に保持している認証情報を復号できない状態になります。このページでは、何を取得すべきか、それぞれがどこに存在するか、そして復元結果が正しいことをどのように確認するかを説明します。

取得すべき 4 つの要素#

データベースには、組織、アセット、エンゲージメント、テスト、検出事項、ユーザー、そして設定が保存されています。

アップロードされたファイルはデータベースの外部に存在します。スクリーンショット、脅威モデル、リスク受容ドキュメントなどの添付ファイルはファイルシステム上にあり、データベースにはそれらへのパスのみが保存されています。

デプロイの設定は、独自のカスタマイズや TLS 証明書を含め、アプリケーションを同じ状態で再度起動できるようにするものです。

暗号化キーは、最も見落とされがちな要素です。認証情報暗号化キーは、連携しているツールの保存済み認証情報を読み取り可能にするものです。これがないままデータベースを復元すると、認証情報自体は残っていても復号できなくなり、すべての連携を手動で入力し直す必要が生じます。

データベース#

ほとんどのセルフホストデプロイは、チャートのデフォルトかつ推奨構成であるマネージド PostgreSQL サービスを利用します。この場合、独自にバックアップを構築するのではなく、プロバイダー自身の自動バックアップとポイントインタイムリカバリを使用してください。決め打ちにせず確認すべき点が 2 つあります。1 つは、インスタンス上で自動バックアップが実際に有効になっているかどうかです。バックアップが無効になっているマネージドデータベースにはバックアップが存在しません。もう 1 つは、保持期間が組織の要件に合っているかどうかです。

PostgreSQL を自分で運用している場合は、圧縮されたカスタム形式のダンプを取得します。

pg_dump -h <db_host> -U <db_user> -Fc <db_name> > defectdojo-$(date +%F).dump

pg_restore で復元します。復元先のロールが復元元と異なる場合は、--no-owner と --no-privileges を使用してください。

pg_restore -v --no-owner --no-privileges -h <db_host> -U <db_user> -d <db_name> defectdojo-<date>.dump

ダンプはスケジュールに従って取得し、生成元のマシン以外の場所に保存してください。また、すぐには気づかない問題にも耐えられるよう、十分な世代数を保持してください。

アップロードされたファイル#

Docker Compose デプロイでは、アップロードされたファイルはホスト上のデプロイディレクトリ内の media ディレクトリにあります。このパスは通常のファイルシステムバックアップでバックアップしてください。別のストレージに移動している場合は、マウントポイントではなくそのファイルシステム自体をバックアップしてください。

Kubernetes では、media ボリュームは設定したストレージバックエンドに従ってプロビジョニングされ、データが物理的にどこに存在するかによって保護方法が決まります。

チャートはボリュームをプロビジョニングするだけで、その内容を保護するものではありません。スナップショットのスケジュールは組み込まれていないため、バックアップはプラットフォーム側、または独自のツールで用意する必要があります。

設定とキー#

Compose では、customizations ディレクトリ、certs ディレクトリ、そして CLI が保存している設定と環境変数を取得してください。設定されている内容は config print と environment print で確認できます。

Kubernetes では、values ファイルと、リリースが参照する secrets の内容を取得してください。

いずれの場合も、認証情報暗号化キーとシークレットキーは、バックアップとは別に、耐久性のあるシークレットマネージャーなどの場所に保管してください。データベースと認証情報キーの両方を手にした者は、連携しているすべてのツールの認証情報を読み取れてしまうため、両者を一緒に持ち運ぶべきではありません。

バックアップとはみなせないもの#

チャートは persistent volume claim にアノテーションを付与し、helm uninstall を実行しても残るようにしています。これはデフォルトで有効です。しかしこれは誤ったアンインストールに対する保護であり、バックアップではありません。破損、アプリケーション内での削除、うまくいかなかったアップグレードのいずれに対しても効果はありません。これらのケースではいずれもボリューム自体は残りますが、損傷はそのボリューム内に存在するためです。

同様に、デプロイと同じアカウントやプロジェクト内にのみ保持されているスナップショットも、見た目ほど頼りになりません。デプロイを削除できるものであれば、通常はそれらのスナップショットも削除できてしまうためです。

バックアップが復元可能であることを確認する#

一度も復元されたことのないバックアップは、単なる仮定に過ぎません。本番環境の上に直接ではなく、検証用の使い捨て環境に復元してテストし、次の点を確認してください。

1. ログインし、組織、アセット、エンゲージメント、テスト、検出事項が想定どおりの件数で存在することを確認します。
2. 添付ファイル付きの検出事項を開き、ダウンロードします。データベースだけでは添付ファイルが一覧には表示されても実際には取得できないため、これにより media の復元が成功したことを確認できます。
3. 設定済みのツール連携を開き、認証情報が問題なく機能することを確認します。これにより、認証情報暗号化キーを正しく復元できたことを確認できます。この確認は、問題を発見できる可能性が最も高いチェックです。
4. ユーザーとグループが正しく引き継がれていることを確認します。SSO などの認証設定は、環境が異なれば通常再設定が必要になるため、そこでの差異は復元の失敗ではなく想定内のものとして扱ってください。

この訓練は、必要になったときだけでなく、定期的に実施してください。復元をインシデント発生時に初めて行うことこそ、バックアップ計画が失敗する典型的な原因です。

ご質問やサポートについて#

デプロイのバックアップ計画についてサポートが必要な場合、または復元が想定どおりの結果にならない場合は、までご連絡ください。