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

GitHub リポジトリのシークレットの漏洩に効果的に対処する方法について説明します。

この記事の内容

イントロダクション

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

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

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

[前提条件]

  • リポジトリへの書き込みアクセス以上の権限があること。
  • オプション: リポジトリで 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 を使用すると、リポジトリのコミット履歴を検索して、そのシークレットをコミットしたユーザーを特定できます。

ヒント

リポジトリで secret scanning が有効になっている場合は、secret scanning アラートで、その詳細の大部分を確認できます。

手順 2. リスクを評価する

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

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

オプション 1. Secret scanning が有効になっている

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

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

    メモ

    • 有効性のチェックは、一部のシークレットでのみ実行できます。 サポートされているシークレットの種類については、「AUTOTITLE」を参照してください。
    • シークレットのプロバイダーは常に、シークレットの有効性を判断するための最も信頼できる情報源です。
  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. 必要な場合は、取り消したシークレットに代わる新しいシークレットを生成します。 これは多くの場合、元のシークレットに依存していたサービスの機能を復元するために必要です。

メモ

GitHub は、パブリック リポジトリに漏洩した GitHub personal access tokens (PAT) を自動的に取り消します。

プライベート リポジトリに漏洩した GitHub PAT の場合、secret scanning のアラート内で [漏洩を報告] をクリックして、その漏洩を GitHub に直接報告します。

その他の種類のシークレットについては、GitHub のサポートされているパートナー パターンのいずれかに一致するシークレットが、パブリック リポジトリに漏洩している場合、GitHub はそのシークレットのプロバイダーに漏洩を自動的に報告し、そのプロバイダーは直ちにそのシークレットを取り消します。

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

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

Identify

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

Coordinate

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

更新して検証する

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

    ヒント

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

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

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

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

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

    組織レベルとエンタープライズ レベルの監査ログについては、アクセス トークンに関連するイベントを具体的に検索できます。 「AUTOTITLE」(組織) および「AUTOTITLE」 (エンタープライズ) を参照してください。

    GitHub の監査ログへのアクセスはロールによって変わるため、必要なアクセス許可がない場合は、組織の所有者やエンタープライズの管理者に連絡する必要がある場合があります。

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

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

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

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

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

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

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

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

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

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

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

詳細については、次を参照してください。

  •         [AUTOTITLE](/code-security/secret-scanning/introduction/about-secret-scanning)

  •         [AUTOTITLE](/code-security/secret-scanning/introduction/about-push-protection)

  •         [AUTOTITLE](/code-security/secret-scanning/introduction/supported-secret-scanning-patterns)

  •         [AUTOTITLE](/get-started/learning-about-github/about-github-advanced-security)