リポジトリのシークレットの漏洩の修復

はじめに

API キー、トークン、資格情報などのシークレットが誤ってコードベースに公開されたり、不適切に格納されたりすると、チームや organization に重大なセキュリティ リスクをもたらす可能性があります。

シークレットの漏洩は直ちに侵害と見なす必要があり、シークレットを取り消すなど、適切な修復手順を実行することが不可欠です。 コードベースからシークレットを削除したり、新しいコミットをプッシュしたり、リポジトリを削除して再作成したりするだけでは、シークレットの悪用を防ぐことができません。

このハウツーでは、誤ってリポジトリにシークレットをコミットしてしまった場合や、リポジトリでシークレットの漏洩が警告された場合の対処方法について説明します。

前提条件

• リポジトリへの書き込みアクセス以上の権限があること。
• オプション: リポジトリで Secret scanning が有効になっていること。

  メモ

  パブリック リポジトリでは Secret scanning を無料で実行できます。 GitHub Team プランと GitHub Enterprise Cloud プランのプライベート リポジトリでは、GitHub Advanced Security の一部として利用できます。

ステップ 1. シークレットを特定してコンテキストを収集する

漏洩したシークレットに関するできるだけ多くの情報を集めます。 これにより、リスクを評価して、どのような方法で修復するのが最善であるかを判断できます。

1. シークレットの種類とプロバイダーを特定します。
   • たとえば、そのシークレットは GitHub personal access token (PAT)、OpenAI API キー、SSH プライベート キーのうちのどれですか?
2. 漏洩したシークレットが含まれるリポジトリ、ファイル、行を特定します。
3. シークレットの所有者を特定します。 これは、シークレットを作成した、またはシークレットについて責任を負う人物やチームのことです。
   • リポジトリの CODEOWNERS ファイルを確認して、責任を負うチームを特定してください。
   • git log -S を使用すると、リポジトリのコミット履歴を検索して、そのシークレットをコミットしたユーザーを特定できます。

ステップ 2. リスクを評価する

修復のアプローチ方法は、その漏洩したシークレットに関連付けられているリスク要因によって決まります。

Secret scanning を使用すると、アラートに関連するリスクを評価できますが、secret scanning をまだ有効にしていない場合でも、利用できる情報からリスク評価を実行できます。

方法 1. Secret scanning が有効になっている

漏洩に関連する secret scanning のアラートを見直し、そのアラートのラベルや使用可能なメタデータを確認します。

1. シークレットの有効性の状態をチェックし、そのシークレットがまだアクティブであるかどうかを確認します。 アラートには、シークレットがアクティブであるか非アクティブであるか、その有効性が不明であるかを示す状態が含まれます。

   メモ

   • 有効性のチェックは、一部のシークレットでのみ実行できます。 サポートされているシークレットの種類については、「サポートされているシークレット スキャン パターン」を参照してください。
   • シークレットのプロバイダーは常に、シークレットの有効性を判断するための最も信頼できる情報源です。
2. シークレットがパブリック リポジトリに漏洩していないかを判断するには、public exposure ラベルをチェックします。
3. シークレットが複数の場所に公開されていないかを判断するには、multiple leaks ラベルをチェックします。
4. シークレットが GitHub PAT の場合は、アラートのメタデータでそのシークレットが最後に使用されたのはいつか、そのアクセス スコープは何かなどの情報を確認します。
5. シークレットに依存するのがどのサービスやアプリケーションであるかを評価し、そのシークレットを直ちに取り消した場合のダウンタイムや中断の可能性を考慮します。

方法 2. Secret scanning が有効になっていない

リポジトリで secret scanning がまだ有効になっていない場合は、次に基づいてリスク評価を実行します。

1. リポジトリの可視性を確認します。 リポジトリはパブリックですか?
2. そのシークレットが最近使用された形跡を探します。 最近そのシークレットを参照するコミットや pull request はありましたか? そのシークレットが使用されたことを示すログや監査証跡はありますか?
3. シークレットが含まれるファイルと周囲のコンテキストを評価します。 そのシークレットは運用環境のデプロイ スクリプトで使用された (高リスク)、またはテスト ファイルで使用されましたか (低リスク)? そのシークレットはデータベースの資格情報や管理者キーに関連付けられているか (高リスク)?
4. シークレットに依存するのがどのサービスやアプリケーションであるかを評価し、そのシークレットを直ちに取り消した場合のダウンタイムや中断の可能性を考慮します。

手順 3. 修復の戦略を練る

次のステップは、前のステップで実行したリスク評価によって変わります。

高リスクのシークレットに迅速に対処する

自動化されたスキャナーは、公開されているシークレットを数分で見つけ出すことができます。 それらは数時間以内に悪意のある行為者によって悪用されるおそれがあります。 アクティブなシークレットが公開されたままになっている時間が長いほど、深刻な侵害につながる可能性が高くなります。

シークレットが高リスク (シークレットがまだアクティブである、パブリック リポジトリに公開されている、運用環境の資格情報である) 場合は、次のことをお勧めします。

1. シークレットを直ちに取り消すことを優先します。 ステップ 4 を参照してください。

   メモ

   サービスのダウンタイムが心配な場合は、最初に同じアクセス許可を持つ新しいシークレットを生成し、その新しいトークンでアプリケーションを起動して、"その後に" 古いシークレットを取り消します。__

2. 修復中と修復後に、(ステップ 1 で特定した) シークレットの所有者、リポジトリの管理者、セキュリティ リードに連絡します。

中程度から低リスクのシークレット向けの計画

シークレットが中程度から低リスク (シークレットがアクティブでない、プライベート リポジトリに公開されている、テストまたは開発環境の資格情報である) 場合は、状況に応じて次のように修復戦略を計画できます。

1. ステップ 1 で収集した情報を使用して、そのシークレットについて責任を負うチームを特定し、シークレットの漏洩を警告します。
2. 漏洩したものと時間について説明します。 シークレットの取り消し、新しいシークレットの生成、影響を受けたサービスの更新が必要であることを説明します。
3. リポジトリの管理者とセキュリティ リードに漏洩に関する情報を伝え、必要とするまたは既に実行した修復アクションについて説明します。
4. スムーズな移行の調整のために、適切なチームと一緒に取り消しとローテーションを実施する時間を計画します。

中程度から低リスクのシークレットであっても、公開されたままではセキュリティとコンプライアンスの両方にリスクをもたらす可能性があるため、修復することが重要です。

ステップ 4. シークレットを取り消す

単にコードベースからシークレットを削除するだけでは不十分です。 修復のステップのうち最も重要なのは、シークレットのプロバイダーと一緒にシークレットを取り消すことです。 シークレットを取り消すことで、シークレットが悪用される可能性を大幅に減らすことができます。

1. ステップ 1 で収集した情報を使用して、そのシークレットのプロバイダーの web サイトまたはドキュメントを探します。

2. プロバイダーの指示に従ってシークレットを取り消します。 通常、これにはプロバイダーのポータルにログインし、シークレットが管理されているセクションに移動する必要があります。

   プロバイダー ポータルへのアクセス権がない場合は、そのシークレットの所有者または関連するリポジトリの管理者に問い合わせて、シークレットの取り消しについてサポートを受けます。

3. 必要な場合は、取り消したシークレットに代わる新しいシークレットを生成します。 これは多くの場合、元のシークレットに依存していたサービスの機能を復元するために必要です。

ステップ 5: 影響を受けているサービスを特定して更新する

次は、漏洩したシークレットを使用しており影響を受けているすべてのサービスに対する更新を調整し、それらサービスを新しいシークレットで更新する必要があります。

識別

1. GitHub のコード検索を使用して、そのシークレットのすべてのコード、issue、pull request をチェックします。
   • org:YOUR-ORG "SECRET-STRING" を使用して organization 全体を検索します。
   • repo:YOUR-REPO "SECRET-STRING" を使用してリポジトリを検索します。
2. リポジトリに格納されているデプロイ キーとシークレットと変数を確認します。
   • [Settings] をクリックし、[Security] で [Secrets and variables] または [Deploy keys] をクリックします。
3. シークレットを使用している可能性のある GitHub Apps や統合がインストールされていないか確認します。

座標

1. 影響を受けているサービスの更新に関わる各タスクの issue (と sub-issue) を作成するよう Copilot に指示します。
2. 複数の利害関係者が関与している場合は、進行状況を追跡し、コミュニケーションを促進するために、その issue のプロジェクト ボードを作成します。

更新して検証する

1. アプリケーションを新しいシークレットで更新し、アプリケーションで新しい資格情報が正しく使用されていることを確認します。

   ヒント

   機密性の高い資格情報をアプリケーションに安全に提供するには、コンテナーを使用します。 たとえば、リポジトリの設定ページにある [Secrets and variables] ストアを使用して、GitHub のアクションとワークフローで機密性の高い資格情報を使用できるように設定できます。

2. 影響を受けているサービスをテストし、新しいシークレットで正しく動作していることを確認します。

ステップ 6. 未承認のアクセスをチェックする

サービスがバックアップされて実行されたら、シークレットが公開されている間に発生した可能性のある未承認のアクセスをチェックすることが重要です。

1. GitHub の監査ログに、シークレットとその使用状況に関連するイベントがないかを確認します。

   • 個人用アカウントのセキュリティ ログ。 「セキュリティ ログをレビューする」を参照してください。
   • Organization の監査ログ。 「Organization の Audit log をレビューする」を参照してください。
   • Enterprise の監査ログ。 「エンタープライズの監査ログ イベント」を参照してください。

   Organization と Enterprise レベルの監査ログについては、アクセス トークンに関連するイベントを具体的に検索できます。 「アクセス トークンによって実行される監査ログ イベントの識別」(organization) と「アクセス トークンによって実行される監査ログ イベントの識別」(Enterprise) を参照してください。

   GitHub の監査ログへのアクセスはロールによって変わるため、必要なアクセス許可がない場合は、organization の所有者や Enterprise の管理者に連絡する必要があることがあります。

2. シークレットのプロバイダーの監査ログを確認します。

   • たとえば、アマゾン ウェブ サービス (AWS) のシークレットの場合は、CloudTrail のログをチェックして、漏洩したシークレットを使用した未承認のアクセス試行がないかを確認できます。 AWS CloudTrail のドキュメントの「AWS CloudTrail とは」を参照してください。

手順 7. リポジトリをクリーンする

コードベースで該当のシークレットを取り消して更新したものの、そのシークレットはまだリポジトリのコミット履歴に残っている可能性があります。 リポジトリからそのシークレットのすべてのインスタンスを検索して削除するのが理想です。

しかし、Git の履歴をクリーンするのは、リポジトリに対して変更のプッシュを強制することが関与する可能性があるため、破壊的で中断が発生するおそれがあります。

リポジトリのセキュリティ リードと協力して、コンプライアンスやセキュリティの義務を考慮しつつ、リポジトリの履歴をクリーンする影響を慎重に検討してください。 「リポジトリからの機微なデータの削除」を参照してください。

手順 8. アラートを解決する

1. [Close as] を選択し、アラートを [Revoked] とマークして、リポジトリ内の secret scanning のアラートを閉じます。
2. 漏洩を修復するためのステップやそこから学んだ教訓など、チームのナレッジ ベースまたはインシデント管理システムにインシデントを記録します。

手順 9. 今後の漏洩を防止する

シークレットの漏洩に対応することは、しばしば複雑で、中断を伴い、時間のかかる作業です。 シークレットの対応においては、常に漏洩を防ぐことに重点を置く必要があります。

1. まだ有効になっていない場合は、リポジトリでプッシュ保護 (GitHub Advanced Security の一部) が有効になっていることを確認します。 信頼されたユーザーのみがプッシュ保護をバイパスできるように、厳密なバイパス制御の実装について確認します。 「プッシュ保護について」を参照してください。
2. 個人用アカウントで "ユーザーのプッシュ保護" が有効になっていることを確認します。これにより、サポートされているシークレットが "あらゆる" パブリック リポジトリに誤ってプッシュされるのを防ぐことができます。__
3. チームまたは organization 内でシークレット管理に関するベスト プラクティスを推奨または実装します。
   • シークレットをコードベースにハードコーディングするのではなく、環境変数を使用してシークレットを格納します。
   • GitHub のリポジトリの設定ページにある [Secrets and variables] ストアなどのシークレット管理ツールを使用して、シークレットを安全に格納して管理します。
   • シークレットを定期的にローテーションして、潜在的な漏洩の影響を最小限に抑えます。
4. インシデントと修復手順を記録として残し、チームが過去のミスから学び、将来のプラクティスを改善するのに役立てます。
5. 定期的な学習とセキュリティ トレーニングを推奨して実施します。 一例として、Microsoft Learn の「GitHub 高度なセキュリティ」コースを参照してください。

参考資料

• シークレット スキャンについて
• プッシュ保護について
• サポートされているシークレット スキャン パターン
• GitHub Advanced Security について