アプリ、データベース、バックアップ向けホームサーバーのシークレットローテーションチェックリスト
安全なアプローチは、在庫管理に基づくローテーションを、認証情報の重複、利用者の検証、失効、復旧用情報の更新を含む、観測可能なゲートの連続として扱うことです。単一のコマンドとして扱ってはいけません。
セルフホスト型アプリ、データベース、バックアップジョブ、自動化を備えたホームサーバーでは、1つの認証情報をローテーションすると、隠れた利用者、スケジュール済みバックアップ、アプリケーションの依存関係が壊れる可能性があります。現在のIDと復旧ポイントを記録し、最も影響の少ない判別手段から始め、別の変数を変更する前に成功・失敗の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーが公開される唯一のものになる場合は停止します。以下のワークフローは、元のワークロードが成功するか、証拠がエスカレーションの境界に達するまで完了しません。
各シークレットとその影響範囲を把握する
データベースのパスワード、APIトークン、バックアップリポジトリのキー、暗号化キー、Webhookシークレット、プロキシ認証情報、サービスアカウントキーを一覧化します。それぞれについて、発行者、権限、保存場所、利用者、再読み込み方法、バックアップ依存関係、復旧担当者、最後に使用された証拠を記録します。ただし、値そのものは記録しません。
GitGuardianの認証情報のローテーションにおける影響範囲では、影響範囲と所有者を中心にローテーションを考えます。認証情報は、それを作成した人やサービスより長く存続する可能性があり、有効であることだけではすべての利用者を特定できません。失効を予定する前に、設定、シークレットストア、スケジュール済みジョブ、CI変数を検索します。
緊急ローテーションと計画的なローテーションは分けて分類します。侵害が疑われる場合は、稼働時間より封じ込めと迅速な失効を優先することがあります。それ以外の場合は、データベースやバックアップで使用されているシークレットを変更する前に、復旧ポイントとテスト済みのロールバック手順を用意します。
重複を作成し、まず発行者を更新する
対応している場合は、古い認証情報が有効なまま、同じ最小限の権限を持つ2つ目の認証情報を作成します。データベースでは2つ目のロールまたはデュアルパスワード機能を使用し、APIサービスでは2つ目のトークンを発行します。暗号化キーでは、キーファイルを場当たり的に置き換えるのではなく、製品の再ラップまたはキースロットの手順に従います。
ゼロダウンタイムのデータベースローテーションガイドでは、2ユーザー認証情報ローテーションパターンについて説明しています。この方法では、元のユーザーを失効させる前に、利用者を2つ目のユーザーへ移行します。すべての利用者を個別に検証できるため、1つの共有パスワードをその場で変更するより安全です。
重複が不可能な場合は、メンテナンス時間を設定し、依存する書き込み処理とバックアップジョブを停止して、正確なロールバックコマンドを文書化します。別の復旧テストで置き換え後の値が確認されるまで、唯一の正常なリポジトリパスワードや暗号化キーを上書きしてはいけません。
すべての利用者を更新し、新しい認証情報の使用を証明する
保護されたシークレットファイルまたはシークレットマネージャーを更新し、利用者を一度に1つずつ再読み込みまたは再作成します。アプリケーションへのログイン、データベースの読み書き、バックグラウンドワーカー、監視、Webhook、リモートレプリケーション、スケジュール済みおよび手動のバックアップ操作をテストします。実行中のコンテナは、古い値をメモリに保持している可能性があります。
ZimaSpaceのDockerシークレットストレージガイドを使用して、認証情報をComposeのYAMLから除外します。生成された設定、環境変数の確認結果、ログ、シェル履歴、サポートバンドルに、古い値と新しい値のどちらも露出しないようにします。
発行者の監査ログを確認するか、安全で隔離された経路から一時的に古い認証情報をテストして、各利用者が新しい認証情報を使用していることを証明します。利用者マトリクスに担当者が割り当てられ、すべての依存関係で合格結果が得られるまで、失効させてはいけません。
失効、クリーンアップ、復旧テストを行う
古い認証情報を失効させ、アクティブなシークレットストアと無効化済みのジョブから削除し、少なくとも通常のスケジュールを1サイクル完了するまで、認証失敗とバックアップアラートを監視します。製品で必要な場合は、下流のセッショントークンやキャッシュ済み接続もローテーションします。
暗号化された復旧用ドキュメントと保護されたオフラインのキーコピーを更新します。古いシークレットを含むバックアップが安全に暗号化され、保持期間の制約を受けているか、特別な対応が必要かを判断します。過去のバックアップを書き換えると復旧可能性が損なわれるおそれがあり、通常は最初に行う対応ではありません。
古い認証情報が失敗し、すべての利用者が新しい認証情報で動作し、バックアップが完了し、復元または復旧ログインが成功した時点で、ローテーションは完了します。ロールバックは、事前に記述した方法でのみ行います。原因不明の認証失敗は、在庫の把握が不完全だったことを意味するため、広範な新しい認証情報で隠してはいけません。
おすすめ商品
サポートとヒント
もっと読む
名前を変更したデータセットと安定したファイルハンドルのためのNFS移行チェックリスト
ストレージの識別情報が変わるとファイルハンドルも変わる可能性があることを前提としてください。クライアントを停止し、エクスポートを意図的に切り替え、再マウントして、開いているファイルと新規ファイルを検証してください。
Windows、macOS、Linux向けSMBクライアントのトラブルシューティングガイド
各クライアントで同じサーバー、アカウント、共有、ファイル操作を使用し、検出、認証情報、ポリシー、ストレージの障害が混在しないようにします。
プロキシとCookieの変更に関するセルフホストアプリのセッション問題解決ガイド
直接接続とプロキシ経由のログイン経路を比較し、実際のCookieのやり取りを確認して、プロキシ、Cookie、またはバックエンドの変数を一度に1つずつ変更します。
