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

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

Phase 3: Pilot GitHub Secret Protection

4 件中 4 件目
その他の記事→

この記事で

イントロダクション

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

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

このチュートリアルでは、シークレットを誤ってリポジトリにコミットした場合、またはリポジトリ内のシークレット リークに対してアラートが送信された場合の手順について説明します。

[前提条件]

  • リポジトリへの書き込みアクセス以上の権限があること。
  • 省略可能: Secret scanning はリポジトリに対して有効です。

    メモ

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

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

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

  1. シークレットの種類とプロバイダーを特定します。
    • たとえば、シークレットは GitHubpersonal 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. シークレットに依存するのがどのサービスやアプリケーションであるかを評価し、そのシークレットを直ちに取り消した場合のダウンタイムや中断の可能性を考慮します。

ヒント

GitHub TeamおよびGitHub Enterprise計画の組織は、漏洩したシークレットへの露出を評価する無料のシークレット リスク評価 (オンデマンドのポイントインタイム スキャン) を実行できます。 「GitHubを使用したシークレット セキュリティ」を参照してください。

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

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

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

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

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

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

    メモ

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

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

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

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

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

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

手順 4. シークレットを取り消す

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

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

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

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

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

メモ

GitHub は、公開リポジトリで漏洩した GitHubpersonal access tokens (PAT) を自動的に無効化します。

プライベート リポジトリ内で漏洩したGitHubPAT、GitHubアラート内で漏洩を報告をクリックすると、secret scanningにその漏洩を直接報告できます。

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

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

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

Identify

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

Coordinate

  1. 影響を受けるサービスの更新に関連するタスクごとに、問題 (およびサブイシュー) を作成するように Copilot に指示します。

「AUTOTITLE」を参照してください。

  1. 複数の利害関係者が関与している場合は、進行状況を追跡し、コミュニケーションを促進するために、その issue のプロジェクト ボードを作成します。

更新して検証する

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

    ヒント

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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