イントロダクション
このチュートリアルでは、漏洩したシークレットの修復作業を整理します。 次の方法について学習します。
- 修復作業を追跡するセキュリティ キャンペーンを作成する
- 所有権に基づいてアラートを割り当てる
- 修復の進行状況を監視する
- 利害関係者とコミュニケーションを取る
[前提条件]
- GitHub Secret Protection と secret scanning の両方が組織で有効になっている必要があります。 「GitHub Secret Protection の料金と有効化」を参照してください。
- 既存の secret scanning アラートが使用可能である必要があります。
手順 1: シークレット スキャンニング アラート
を確認する
アクションを実行する前に、組織のセキュリティ アラートの現在の状態を理解する必要があります。
-
GitHub で、organization のメイン ページに移動します。
-
Organization 名の下にある [ Security] をクリックします。
![組織の水平ナビゲーション バーのスクリーンショット。 盾のアイコンと [セキュリティ] というラベルのタブが、濃いオレンジ色の枠線で囲まれています。](/assets/cb-22170/images/help/organizations/organization-security-tab.png)
-
左側のサイドバーの [アラート] セクションで、Secret scanning の右側にある 記号をクリックします。
-
ドロップダウン リストで、
Defaultを選択します。Defaultは、サポートされているパターンと指定されたカスタム パターンに関連しています。 -
または、
Genericを選択して、パスワードなどの非構造化シークレットを確認することもできます。 ただし、一般的なパターンでは通常、既定のパターンよりも多くの誤検知が発生するため、優先順位の高いリークに対処した後でこれらのアラートを確認することを検討してください。 -
影響を受ける開いているアラートとリポジトリの合計数を確認します。
-
フィルターを使用して最も緊急なアラートを特定し、修復作業に優先順位を付けます。 * パブリック リポジトリにリークを表示するには、
publicly-leakedを使用します。- 同じ組織内または企業内の 複数のリポジトリ で見つかったシークレット リークを表示するには、
is:multi-repositoryを使用します。 -
**有効な**シークレットを表示するには、`validity:active`を使用します。 - 特定の サービス 資格情報 (AWS、Azure、GitHub) でフィルター処理するには、
provider:を使用します。 - 特定の トークンの種類でフィルター処理するには、
secret-type:を使用します。
- 同じ組織内または企業内の 複数のリポジトリ で見つかったシークレット リークを表示するには、
-
必要に応じて、サイドバーの [メトリック] の下にある Secret scanning をクリックして確認します。
- 最も頻繁にブロックまたはバイパスされたシークレットの種類
- ブロックされたプッシュまたはバイパスが最も多いリポジトリ
手順 2: セキュリティ キャンペーンを作成する
リポジトリ間で修復作業を整理して追跡するためのセキュリティ キャンペーンを設定できます。
- 組織に移動し、[ [セキュリティ] をクリックします。
- 左側のパネルで、 キャンペーンを選択してください。
- [ キャンペーンの作成] をクリックし、次のいずれかをクリックします。
- 定義済みのシークレット キャンペーン テンプレートを選択します。
- カスタム フィルターを使用して、特定のアラート (
is:open provider:azureやis:open validity:activeなど) を対象とします。
- アラート (最大 1000) を確認し、必要に応じてフィルターを調整します。
- [ 名前を付けて保存] をクリックし、[ キャンペーンの発行] を選択します。
- キャンペーン情報を入力し、[キャンペーンの 発行] をクリックします。
手順 3: チーム メンバーにアラートを割り当てる
キャンペーンを作成したら、それらを修正する開発者に個別のアラートを割り当てる必要があります。
- キャンペーンページで、リポジトリを展開してアラートを表示するには、[ をクリックします。
- アラートをクリックして詳細ページを開きます。
- 右側のサイドバーで、[ 担当者] をクリックします。
- アラートを修正する開発者を選択します。 通常、これは、シークレットをコミットした人またはリークが検出されたリポジトリの管理者です。 彼らは書き込みアクセス権が必要です。
手順 4: 修復の進行状況を監視する
アラートが割り当てられたら、キャンペーンの進行状況を定期的に追跡して、タイムリーに完了できるようにする必要があります。
- キャンペーン ページで、キャンペーンの概要を確認します。 次のように表示されます。 * キャンペーンの進行状況: 閉じている (固定または無視された) アラートの数、またはまだ確認が残っているアラートの数 * 状態: キャンペーンの期限までの日数
- キャンペーンの詳細を調べることができます。
- リポジトリを展開して、アラートの修復の進行状況を確認します。
- すべてのアラートの一覧を表示するには、[ グループ化 ] を [なし] に設定します。
- フィルターを使用して、特定のリポジトリまたはアラートに焦点を当てます。
- 最も多くのオープンアラートがあるリポジトリまたは最近の進捗がないリポジトリに基づいて注目すべきエリアを特定し、それらのリポジトリの管理者や担当者にサポートのため連絡します。
手順 5: 利害関係者と通信する
修復プロセス全体を通じて、定期的な進行状況の更新について関係者に通知する必要があります。 キャンペーン ダッシュボードの情報を使用して、これらの更新プログラムを生成できます。
- キャンペーン ダッシュボードに移動します。
- レポートに含める情報を特定します。 次の主要なメトリックについて考えてみましょう。
- 今週解決されたアラート
- 開いている残りのアラート
- オントラック項目とリスクがある項目
- 注目すべき実績または阻害要因
- メトリックを更新プログラムに組み込み、メール、Slack、Teams、またはセキュリティ会議を介して配布します。
手順 6: 修復手順を文書化する
最後に、将来の修復作業をより効率的にするために、標準化された手順を作成する必要があります。
- シークレットの種類固有のガイドを開発します。 例えば次が挙げられます。 * AWS の資格情報: アクセス キーをローテーションしてサービスを更新する方法 * GitHub トークン: Personal Access Tokens を取り消して再生成する方法 * API キー: サービス固有のローテーション プロシージャ * データベース資格情報: サービスの中断を伴わない安全なローテーション
- 修復チェックリストを作成します。
- シークレットが実際にリークされていることを確認します。
- シークレットがまだアクティブかどうかを確認します。
- 侵害されたシークレットを無効化するか、ローテートします。
- 古いシークレットを使用して、すべてのシステムを更新します。
- システムが新しい資格情報で機能することをテストします。
- インシデントと修復の手順を文書化します。
- アラートを解決済みとしてマークします。
- エスカレーション パスを確立します。
- セキュリティ リーダーシップにエスカレートするタイミングを定義します。
- さまざまなシークレットの種類について、主題の専門家を特定します。
- 重大なリークに対するインシデント対応手順を作成します。