ホームサーバーの機密情報を設定ファイルからシークレットストアに移す理由は？

ホームサーバーのシークレットはシークレットストアに移すべきです。設定ファイルに長期間有効な認証情報を記述すると、アプリ、バックアップ、ログ、管理者の作業フロー全体に同じ認証情報が複製されるためです。

セルフホスト型サーバーは、composeファイルにデータベースのパスワードを1つ記述するところから始まり、やがてAPIキー、クラウドトークン、SMTP認証情報、VPNキー、暗号化パスワード、Webhookシークレット、管理者Cookieなどが加わっていくことがあります。これらの値は、環境ファイル、エクスポートしたスタック、スクリーンショット、バックアップ、シェル履歴、サポート用バンドルにコピーされる可能性があります。シークレットストアがすべてのアプリを信頼できるものにするわけではありませんが、個別の認証、ローテーション、ポリシー、監査記録を備えた、制御された単一の取得経路を作れます。以下では、それによって露出範囲がどのように変わるのかを説明します。

設定ファイルは1つの認証情報を複数のコピーに変える

設定ファイルは、アプリが読み取れるように設計されており、デプロイにも便利です。そこに平文の認証情報が含まれていると、そのファイルのコピーはすべて、シークレットが失われる可能性のある新たな場所になります。

HashiCorpは、シークレットの拡散を、信頼できる単一のインベントリがないまま、ソースコード、設定、バージョン管理、Wikiなどのシステムに認証情報が現れる状態として説明しています。ホームサーバーでは、エクスポートしたcomposeスタックや自動バックアップによって、稼働中のアプリを変更した後も古い値が長期間保存されることがあります。

リスクは現在使われているファイルの盗難だけではありません。秘匿化したダッシュボード、コピーされたトラブルシューティング用アーカイブ、廃止したバックアップに、誰も失効させることを思い出さない、まだ有効なトークンが含まれている可能性もあります。

シークレットストアは設定と認証情報を分離する

アプリにはデータベースのアドレス、ユーザー名、シークレット名、取得方法などが必要ですが、デプロイ用の設定に認証情報そのものの値を含める必要はなくなります。

一元化されたストアは、認証済みのワークロードが使用を許可されたシークレットだけを受け取る、制御された取得経路を作ります。シークレットは実行時に注入したり、アクセスを制限したメモリーバックのパスにマウントしたり、短期間だけ有効な認証情報と交換したりできます。

これによって、侵害された認証済みアプリが自身のシークレットを使用することまで防げるわけではありません。しかし、無関係なアプリ、バックアップ、設定ファイルの読み取り処理が、デフォルトでその値を受け取ることは防げます。

ストア自体が重要なインフラになるため、その可用性、バックアップ、復旧、管理者アクセスは明確に設計する必要があります。

アプリごとのIDが共有管理者認証情報に置き換わる

シークレットストアは、各アプリがそれぞれ固有のIDで認証するときに最も有効です。複数のコンテナが1つのrootトークンや、広範囲から読み取り可能なマスターファイルを共有してシークレットを取得する構成は避けるべきです。

現代的なシークレット管理では、ワークロードIDと最小権限のポリシーを組み合わせます。これにより、写真アプリにはデータベースのパスワードを読み取らせ、ダウンローダーにはバックアップ暗号化キーを要求させない、といった制御が可能になります。IDは、マシン、サービスアカウント、オーケストレーター、証明書、短期間だけ有効なログインフローなどに紐付けられます。

これにより、アプリの認証情報が漏えいした場合の影響範囲が変わります。攻撃者が得るのは、ホスト上のすべてのサービスの認証情報を含むファイルではなく、範囲を限定した1つのシークレット取得経路です。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

ローテーションがファイル探しではなくライフサイクル運用になる

ハードコードされた認証情報は、すべての利用箇所とコピーされた設定を見つけ、正しい順序で編集して再起動する必要があるため、変更が困難です。この運用コストが、長期間有効なシークレットの使用を招きます。

動的シークレットを使えば、1回のアプリセッション用に認証情報を生成し、複数のファイルに永続的なパスワードを書き込むことなく、失効または期限切れにできます。バックエンドが動的に認証情報を発行できない場合でも、静的なシークレットを一元的にバージョン管理してローテーションできます。

ただし、ローテーションには、認証情報を安全に再読み込みまたは更新できるアプリの動作が必要です。アプリが起動時に一度しかシークレットを読み込まず、古い接続を無期限に保持する場合、ストアだけでダウンタイムをなくすことはできません。

監査記録によって、どのワークロードがシークレットを取得したかがわかる

平文ファイルには、誰が読み取ったかが記録されることはほとんどありません。ファイルシステムのログによって一部の環境ではアクセスが示される場合もありますが、通常はその読み取りを、名前付きのシークレットバージョン、ポリシーによる判断、その後のバックエンドでの使用と結び付けることはできません。

シークレット管理のガイダンスでは、アクセス監査を一元化の主要なメリットとしています。取得記録には、ワークロード、シークレットのパス、時刻、送信元、結果を記録でき、通常の起動と予期しない大量アクセスを区別するのに役立ちます。

監査ログは、監視対象のアプリとは別の場所に保存し、それ自体からのシークレット漏えいも防ぐ必要があります。返された値をそのままログに記録すると、元の露出が再現されてしまいます。

移行では、Vaultを追加するだけでなく古いコピーも削除する必要がある

認証情報をストアに移しても、Gitの履歴、バックアップ、composeのエクスポート、スクリーンショット、シェル履歴、アプリケーションログにすでに存在するコピーが無効になるわけではありません。

GitGuardianは、専用の管理機能に認証情報のローテーションとスキャンを組み合わせることを推奨しています。Vaultは正しく取得された値を管理しますが、以前に外部へ流出したシークレットを消去することはできないためです。移行後に認証情報をローテーションし、可能な範囲で復元可能な古いコピーを削除または期限切れにします。

ZimaSpaceのバインドマウントの範囲に関する説明も、同じ境界に関係します。ソースをVaultと呼んでいても、すべてのコンテナにマウントされたシークレットファイルは広範囲に露出したままです。

元の設定上のシークレットを削除した状態で、クリーンな再起動から復旧できるかテストします。意図したアプリが最新の値を取得し、権限のないアプリが失敗し、ローテーションが成功し、シークレットストア自体も安全に復元できて初めて、移行は完了です。

FAQ

環境変数はシークレットストアですか？

いいえ。環境変数は値を受け渡すための仕組みであり、プラットフォームによっては、プロセスの検査、クラッシュレポート、コンテナメタデータ、デバッグ出力、デプロイ時のエクスポートなどに現れる可能性があります。

すべてのホームサーバーで専用のVault製品を使うべきですか？

必ずしもそうではありません。必要な複雑さは、アプリの数、脅威モデル、復旧スキル、そして保護されたファイルの注入によって狭いアクセス範囲と信頼できるローテーションを実現できるかどうかによって異なります。

シークレットストアは、侵害された認証済みアプリから保護できますか？

部分的にしか保護できません。アプリが受け取るシークレットの種類を制限し、有効期間を短縮することはできますが、アプリは取得を正当に許可された認証情報を引き続き使用できます。