GitHub Advanced Security と Microsoft Defender for Cloud の統合をデプロイする

このガイドでは、GitHub Advanced Security (GHAS) と Microsoft Defender for Cloud (MDC) を統合することで、Microsoft のクラウドネイティブ アプリケーション セキュリティを最大限に活用するためのすべてのセットアップ手順について説明します。

このガイドに従うことで、次の操作を行うことができます。

• Microsoft Defender for Cloud (MDC) カバレッジ用の GitHub リポジトリを設定する
• ランタイム リスクファクターを作成する
• MDC で実際のユース ケースをテストする
• コードをクラウド リソースにリンクする
• ランタイム コンテキストを利用して GitHub でセキュリティ キャンペーンを開始し、ランタイム コンテキストに基づいて GHAS セキュリティ アラートに優先順位を付ける
• MDC から GitHub の問題を作成して修復を開始する
• エンジニアリング チームとセキュリティ チームの間のループを閉じる

[前提条件]

特徴	詳細
環境要件	- Microsoft Defender for Cloud (MDC) で作成されたコネクタを含む GitHub アカウント - GitHub Advanced Security (GHAS) ライセンス - サブスクリプションで有効になっている Defender CSPM - GitHub Security Copilot (自動修復の場合は省略可能)
役割と権限	- セキュリティ管理者のアクセス許可 - Azure サブスクリプションのセキュリティ閲覧者 (MDC で結果を表示するため) - GitHub 組織の所有者
クラウド環境	- 商用クラウドでのみ利用可能 (US Gov、China Gov、またはその他のソブリン クラウドでは使用できません)

環境を準備する

手順 1: GitHub リポジトリを設定し、ワークフローを実行する

統合をテストするには、独自のリポジトリまたはすべてのコンテンツが既にある GitHub リポジトリの例を使用して、脆弱なコンテナー イメージを構築します。

• Microsoft Defender for Cloud ポータルで使用する予定の GitHub 組織のコネクタを必ず定義してください。 コネクタの定義については、 GitHub 組織の接続に関する記事の手順に従ってください。

• GitHub コネクタ用にエージェントレス コード スキャンが構成されていることを確認します。 そうでない場合は、「 エージェントレス コード スキャンを構成する (プレビュー)」の手順に従います。

注

統合に使用するリポジトリがプライベートであることを確認します。

サンプル リポジトリを使用する場合は、GitHub 組織に次のリポジトリを複製します。 このリポジトリでは GHAS が有効になっており、DCSPM が有効になっている Azure テナントにオンボードされます:build25-woodgrove/mdc-customer-playbook。 このリポジトリは、お客様が Microsoft Defender for Cloud と GHAS の統合をテストするためのものです。

リポジトリで、次の手順に従います。

1. [設定] に移動します。
2. 左側のパネルで、 シークレットと変数>Actions を選択します。
3. リポジトリまたは組織レベルで次のシークレットを追加します。

Variable	Description
ACR_ENDPOINT	Azure Container Registry のログイン サーバー
ACR_PASSWORD	Azure Container Registry のパスワード
ACR_USERNAME	Azure Container Registry のユーザー名

注

名前は自由に選択でき、特定のパターンに従う必要はありません。

この情報は、次の手順に従って Azure portal で確認できます。

1. デプロイする ACR を選択してください。

2. [設定] で [アクセス キー] を選択します。

   

3. リポジトリで[ アクション]を選択します。

4. [Build and Push to ACR]\(ビルドして ACR にプッシュ\) ワークフローを選択し、ワークフローを実行します。

   

5. イメージが Azure Container Registry にデプロイされたことを確認します。

6. 提供されたリポジトリの例: イメージは 、mdc-ghas-integration というタグを持つ mdc-mock-0001 というレジストリに存在 する必要があります。

7. クラスターで実行中のコンテナーと同じイメージをデプロイします。 この手順を完了する 1 つの方法は、クラスターに接続し、 kubectl run コマンドを使用することです。 AKS の例を次に示します。

   1. クラスター サブスクリプションを設定します。

      az account set --subscription $subscriptionID
      

   2. クラスターの資格情報を設定します。

      az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existing
      

   3. イメージをデプロイします。

      kubectl run $containerName --image=$registryName.azurecr.io/mdc-mock-0001:mdc-ghas-integration
      

手順 2: 最初のリスク要因を作成する - ビジネス クリティカル ルール

Defender for Cloud がこの統合に対して検出するリスク要因の 1 つは、ビジネスの重要度です。 組織は、さまざまなリソースにビジネス クリティカルとしてラベルを付けるルールを作成できます。

1. Microsoft Defender for Cloud ポータル (Azure portal) で 、[環境設定] に移動し、[ リソースの重要度] を選択します。

2. 右側のウィンドウで、リンクを選択して Microsoft Defender を開きます。

   

3. [ 新しい分類の作成] を選択します。

   

4. 名前と説明を入力します。

5. クエリ ビルダーで [クラウド リソース ] を選択します。

6. 検証のためにクラスターにデプロイしたコンテナーの名前と同じ リソース名 を設定するクエリを作成し、[ 次へ] を選択します。

   

7. [ プレビューアセット ] ページで、Microsoft Defender によってリソースが既に検出されている場合、コンテナーの名前は資産の種類が K8s-container または K8s-pod と表示されます。 プレビューアセットページにまだ表示されていない場合でも、次の手順に進みます。 Microsoft Defender は、検出されると、重要度ラベルをコンテナーに適用します。 このプロセスには最大で 24 時間かかります。

8. 重要度レベルを選択し、分類ルールを確認して送信します。

手順 3: 環境の準備ができていることを検証する

注

次の結果を確認するには、前の手順が適用されてから最大 24 時間かかる場合があります。

1. GitHub エージェントレス スキャンによってリポジトリが取得されることをテストします。

2. Cloud Security Explorer に移動し、クエリを実行します。

3. (ACR 内の) MDC がコンテナー イメージをスキャンし、それを使用してコンテナーを作成したことを検証します。 クエリで、特定のデプロイの条件を追加します。

4. コンテナーが実行中であり、MDC が AKS クラスターをスキャンしたことを確認します。

5. リスク要因が MDC 側で正しく構成されていることを検証します。 MDC インベントリ ページでコンテナー名を検索すると、重大としてマークされていることがわかります。

手順 4: GitHub キャンペーンを作成する

ワークフローでは、リスク要因 (ビジネス クリティカル) の 1 つで実行中のコンテナーを作成するイメージがデプロイされるため、開発者は GitHub でリスク要因を確認できます。

注

リソースをクリティカルとして分類した後、MDC が GitHub にデータを送信するまでに最大 12 時間かかることがあります。 詳細については 、こちらをご覧ください。

1. GitHub で、セットアップ テストに使用した GitHub 組織に移動します。

2. セキュリティ>キャンペーン>コードスキャンフィルターからキャンペーンを作成します。

   

3. 次のキャンペーンを作成します。 このキャンペーンでは、リポジトリからデプロイされたイメージが重要なリソースに関連付けられている重大度が中程度のオープン アラートが表示されます。 このキャンペーンでは、テスト リポジトリを検出する必要があります。

   

4. [ 保存] を選択し、[ キャンペーンとして発行] を選択します。

5. 必要な情報を入力し、キャンペーンを発行します。

手順 5: コードからクラウドへの推奨事項を評価する

C2C Recommendation SDLC エクスペリエンスとセキュリティ アラート エンリッチメントを使用して、セキュリティの問題の状態を理解し、関連するエンジニアリング チームに解決の推奨事項を割り当てます。この推奨事項は、[ ランタイムの推奨事項] の [関連する CVE ] タブの Dependabot セキュリティ アラートと一致する CVE の間の接続を利用します。

C2C の推奨事項を表示する

1. MDC ポータルで、[ 推奨事項 ] タブに移動します。
2. 作成したコンテナーの名前を検索し、**Update *** という推奨事項のいずれかを開きます。
3. サンプルリポジトリを使用している場合は、ブレース展開の推奨事項を更新を探します。
4. [Remediation Insights]\(修復の分析情報\) タブに移動し、クラウド ダイアグラムのコードを表示します。
5. この図では、実行中のコンテナーをコード リポジトリ内のコンテナー イメージに、GitHub の元のコード リポジトリにマップします。

双方向エンリッチメント

1. [関連付けられた CVE] タブを選択します。一部の CVE には、関連する GitHub アラートの列にリンクがあることに注意してください。

   

2. GitHub の [表示] リンクを選択して、関連する GHAS セキュリティ アラートを開きます。

エンジニアリングの動員

セキュリティ チームとエンジニアリング チームの間のループを閉じるには、コンテナー化されたアプリケーションの GitHub の問題を作成し、エンジニアリング チームが重点を置く必要があるセキュリティの問題に優先順位を付けることができます。 この優先順位付けには、GHAS が取得しなかったが、直接の依存関係の一部ではない CVE (基本イメージ、OS、NGINX などのサードパーティ製ソフトウェアの脆弱性など) に対して MDC が検出された結果を渡すことが含まれる場合があります。

GitHub の問題は、レコメンデーションのスコープで見つかったすべての CVE に基づいて自動生成されます。Dependabot アラートの有無にかかわらず、それらの問題は、オリジナルのリポジトリのその他のランタイムコンテキストと一致します。

問題を割り当てると、MDC ポータルで問題の状態が更新されます。

エージェントに関する修正

GitHub 側で、GitHub Copilot ライセンスをお持ちの場合は、GitHub コーディング エージェントの助けを借りて問題を解決できます。

1. GitHub コーディング エージェントを問題に割り当てます。
2. 生成された修正プログラムを確認します。
3. 妥当と思われる場合は、修正プログラムを適用します。
4. MDC で問題の状態が [終了] に更新されているのを確認します。

関連コンテンツ

• GitHub Advanced Security 統合の概要
• Microsoft Defender for Cloud DevOps セキュリティの概要
• GitHub 組織を接続する
• エージェントレス コード スキャンを構成する (プレビュー)