シークレットの拡散問題

シークレットの拡散とは、組織内で機密性の高い認証情報が無秩序に広がることです。シークレットとは、アクセスを許可するあらゆる情報を指します。APIキー、データベースのパスワード、OAuthトークン、TLS秘密鍵、SSHキー、暗号化キーなどが該当します。

シークレットの拡散は、本来存在すべきでない場所にシークレットが散在すると発生します。

• ソースコードや設定ファイル
• CI/CDパイプラインや環境変数
• コンテナイメージやInfrastructure as Code
• チャットメッセージ、Wiki、チケット管理システム

シークレットが多くの場所に存在すると、追跡、ローテーション、確実な失効を行う能力が失われます。

最も一般的な根本原因は、ソースコードに認証情報を直接書き込むハードコードされたシークレットです。開発中は便利に感じられますが、恒久的なリスクになります。

アプリケーションコード内でデータベースのパスワードをハードコードすると、次のようになります。

これで、このファイルへの読み取りアクセス権を持つ全員が本番環境のパスワードを取得できます。これには、すべての開発者、すべてのCIランナー、そして後からリポジトリをクローンする全員が含まれます。

ハードコードされたシークレットの重大な危険性の一つが、バージョン管理の履歴です。後のコミットでシークレットを削除しても、すべてのクローンのGit履歴には永久に残り続けます。

漏えいしたシークレットは、いつでも履歴から復元できます。

そのため、最新のコミットからシークレットを削除するだけでは、漏えいを解決したことになりません。シークレットは侵害されたものと見なし、直ちにローテーションする必要があります。

ハードコードされたシークレットを含むリポジトリをGitHubのような公開ホストにプッシュすると、自動化されたボットによって数秒から数分以内に収集されます。

現実に起こり得る影響には、次のようなものがあります。

• クラウド料金の爆発：漏えいしたAWSキーが暗号資産マイニング用の大規模な環境の起動に悪用され、一晩で数万ドルの請求が発生します。
• データ侵害：データベースの認証情報が漏えいし、データが完全に持ち出されます。
• ラテラルムーブメント：漏えいしたトークン一つを使って、インフラストラクチャのより深い部分へ侵入されます。

現在では、クラウドプロバイダーやGitHubがシークレットスキャンを実行し、漏えいしたキーを自動検出したり、ときには自動で無効化したりします。しかし、これを安全網として頼ることはできません。

コンテナは、気づきにくい拡散経路を生み出します。ビルド中にイメージへ埋め込まれたシークレットはイメージレイヤーに保存され、そのイメージを取得するすべてのレジストリやホストへ配布されます。

よくある誤りは、シークレットファイルをコピーしてから後のレイヤーで削除することです。しかし、シークレットは前のレイヤーに残っています。

イメージを取得できる人は誰でも、そのレイヤーを抽出してキーを読み取れます。代わりに、ビルドシークレットまたは実行時の注入を使用してください。

コードからシークレットを取り出して環境変数に移すのは一歩前進ですが、完全な解決策ではありません。環境変数はハードコードの問題を解決する一方で、新たな露出経路を生み出します。

• クラッシュダンプやエラーのスタックトレースに漏えいする
• Linuxでは、/proc/<pid>/environを通じて他のプロセスから見える
• 環境全体を出力するデバッグツールによってログに記録される
• 誤ってコミットされるプレーンテキストの.envファイルに保存される

環境変数は機密性の低い設定には使用できますが、価値の高いシークレットはアクセス制御と監査機能を備えた専用のシークレットマネージャーで管理してください。

シークレットの拡散によって、インシデント対応はほぼ不可能になります。シークレットがあらゆる場所に存在すると、次の2つの質問に答えられなくなります。

• どこにあるのか：見つけられないものはローテーションできません。
• 誰が使ったのか：アクセスログを一元管理していなければ、侵害の範囲を特定できません。

一つの認証情報が漏えいした場合の影響範囲は、拡散の度合いに応じて広がります。共有パスワードを10個のサービスで使い回していると、一度の漏えいですべてのサービスが侵害されます。一元管理と、サービスごとに異なる短期間だけ有効なシークレットによって、この影響範囲を大幅に縮小できます。

漏えいを防ぐ最も低コストなタイミングは、シークレットがバージョン管理に入る前です。コミット前のシークレットスキャナーはステージされた変更を検査し、認証情報のパターンを含むコミットをブロックします。

代表的なオープンソースツールには、gitleaks、trufflehog、detect-secretsがあります。一般的なコミット前フックはローカルで実行されます。

これに加えてCIでサーバー側のスキャンも行えば、開発者がローカルフックを回避しても検出できます。

シークレットが置かれるべきでない場所に到達した場合は、次の順序で対応してください。最初にローテーションを行います。履歴のクリーニングは二次的な対応です。すでにコピーが存在している可能性があるためです。

• 1. ローテーション：漏えいしたシークレットを無効化し、直ちに新しいものを発行します。
• 2. 監査：露出していた期間に不正利用がなかったか、アクセスログを確認します。
• 3. 完全削除：履歴からシークレットを削除し（例：git filter-repo）、強制プッシュします。
• 4. 防止：スキャンを追加し、シークレットをマネージャーへ移して再発を防ぎます。

手順1を決して省略しないでください。公開された場所に触れたシークレットは、例外なく侵害されたものと考えます。

シークレットの拡散は、シークレットに過剰な権限が付与され、過剰に共有されることでさらに悪化します。最小権限を適用すると、漏えいが起きた場合の被害を抑えられます。

• 各サービスには専用の認証情報を与え、決して共有しない
• 各シークレットの権限を必要最小限に限定する（読み取り専用か管理者権限か）
• 自動的に期限切れになる短期間だけ有効な認証情報を優先する
• 環境ごとにシークレットを分離する。開発用キーで本番環境にアクセスできてはいけない

これらの習慣により、壊滅的な侵害を、封じ込めて復旧できるインシデントに変えられます。

ツールだけでは拡散を解決できません。文化が必要です。成熟した組織では、シークレット管理を継続的な取り組みとして扱います。

• 基本方針：ソースコードにシークレットを決して含めない
• アクセス制御と監査ログを備えた管理対象の保管庫に保存場所を一元化する
• コミット前、CI、レジストリなど、あらゆる段階でスキャンを自動化する
• ローテーションを、緊急時だけでなく日常的に行う
• すべてのエンジニアが、責められることなく露出を見つけて報告できるようにする

目標は、シークレットを漏えいさせることは難しく、漏えいしても容易に復旧できるシステムです。

漏えいしたシークレットを削除するだけでは不十分な理由を確認しましょう。

散在したハードコードされたシークレットが、最も一般的で被害の大きいセキュリティ上の弱点の一つである理由を学びました。

• シークレットの拡散とは、コード、パイプライン、イメージ、チャットなどに認証情報が無秩序に広がることです。
• ハードコードされたシークレットはGitの履歴に永久に残るため、削除しても漏えいは解決しません。
• 公開リポジトリは数分以内に収集され、クラウド料金の爆発や侵害につながります。
• 環境変数やイメージレイヤーは漏えいしやすい入れ物であり、安全な保管場所ではありません。
• 拡散によって影響範囲が広がり、ローテーションやインシデント対応が不可能になります。
• 対策は、コミット前にスキャンし、漏えい時には最初にローテーションを行い、保管庫で一元管理して、最小権限を適用することです。

次は、保管庫とシークレットストアを使ってシークレットを適切に一元管理します。