Microsoft Defender for Cloud との GitHub 高度なセキュリティ統合 ・ サンドボックスプロジェクト

このガイドでは、シンプルなユースケースを用いて、GitHub Advanced Security (GHAS) と Microsoft Defender for Cloud のエンドツーエンド統合を評価するのに役立つサンドボックスプロジェクトのセットアップ手順について説明します。

GASとMicrosoft Defender for Cloudの統合は、実行時のリスクやコンテキストを生成コードと関連付けることで、AI駆動の迅速な修復を可能にすることで、Microsoftのクラウドネイティブアプリケーションのセキュリティを最大化します。

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

• Defender for Cloud カバレッジ用に GitHub リポジトリを設定します。
• ランタイム リスクファクターを作成します。
• コードをランタイム リソースにリンクします。
• Defender for Cloud で実際のユース ケースをテストします。

前提条件

環境を準備する

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

統合をテストするには、サンドボックスの例GitHubリポジトリを使用します。このリポジトリには、脆弱なコンテナー イメージを構築するためのすべてのコンテンツが既に含まれています。

リポジトリを設定する前に、次の点を確認してください。

• Defender for Cloud ポータルで使用するGitHub組織のコネクタを定義します。 「GitHub 環境を Microsoft Defender for Cloud に接続する」の手順に従います。
• GitHub コネクタのエージェントレス コード スキャンを構成します。 エージェントレス コード スキャンの構成 (プレビュー) の手順に従います。
• 統合にはプライベート リポジトリを使用します。

1. GitHub組織に次のリポジトリを複製します。

• https://github.com/build25-woodgrove/mdc-customer-playbook このリポジトリでは GHAS が有効になっており、Defender CSPMが有効になっているAzure テナントにオンボードされます。

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

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

以下の手順を踏めば、Azureポータルでコンテナレジストリ認証サーバー、ユーザー名、パスワードを確認できます。

1. デプロイするコンテナー レジストリを選択します。
2. [ 設定] で、[ アクセス キー] を選択します。
3. [ アクセス キー ] ウィンドウには、認証サーバー、ユーザー名、およびパスワードのキーが表示されます。

リポジトリで [ アクション] を選択 し、[ビルドして ACR にプッシュ ] ワークフローを選択し、[ ワークフローの実行] を選択します。

イメージがコンテナー レジストリにデプロイされたことを確認します。 リポジトリの例では、タグがmdc-mock-0001された mdc-ghas-integration というレジストリにイメージを配置する必要があります。

mdc-mock-0001:mdc-ghas-integrationイメージをクラスタ上で実行中のコンテナとして展開します。 コンテナイメージをクラスターにデプロイする一つの方法は、クラスターに接続して「 kubectl run コマンド」を使うことです。 Azure Kubernetes Service (AKS) の例を次に示します。

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

az account set --subscription $subscriptionID

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

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

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

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

手順 2: リスク要因の例を作成する (ビジネス クリティカルなルール)

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

1. Defender for Cloud ポータルで、[>] に移動します。
2. 右側のウィンドウで、リンクを選択して Microsoft Defender を開きます。
3. [ 新しい分類の作成] を選択します。
4. 名前と説明を入力します。
5. クエリ ビルダーで、[ クラウド リソース] を選択します。 リソース 名 を、検証のためにクラスターにデプロイしたコンテナーの名前と同じ名前に設定するクエリを記述します。 次に、[次へ] を選択します。
6. Preview Assets ページで、もし Microsoft Defender がリソースを既に検出している場合、コンテナーの名前は資産の種類が K8s-container または K8s-pod として表示されます。 名前がまだ表示されていない場合でも、次の手順に進みます。
7. 重要度レベルを選択し、分類規則を確認して送信します。

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

検証では、コードを実行時の推奨事項に表示し、実行可能な結果を生成するように環境が正しく構成されていることを確認します。

検証中、Defenderは実行時の可視性まで完全なコードを検証します。

• Microsoft Defender for Cloudは、セキュリティの脆弱性についてソース コード リポジトリを継続的に監視します。
• コンテナー イメージなどのビルド成果物は、デプロイ前にコンテナー レジストリでスキャンされます。
• Kubernetes クラスターにデプロイされたランタイム ワークロードは、セキュリティ リスクを監視します。
• Defender for Cloud、コードからビルドとデプロイ、ランタイム、および戻る各成果物を関連付け、トレースします。

GitHubのエージェントレススキャンがリポジトリを検出するかをテストします。

Cloud Security Explorerにアクセスし、以下のリストに記載されている検証クエリを実行してください。 これらの検証クエリは、Defenderがパイプラインやワークロードによって生成されるアーティファクトを特定できるかどうかをテストします。 クエリから結果が返された場合は、スキャンと相関関係が期待どおりに動作していることを示します。

• Defender for Cloud (Azure Container Registry) がコンテナー イメージをスキャンし、それを使用してコンテナーを作成したことを確認します。
• クエリで、特定のデプロイの条件を追加します。
• コンテナーが実行されていること、および Defender for Cloud が AKS クラスターをスキャンしたことを確認します。
• Defender for Cloud 側でリスク要因が正しく構成されていることを検証します。 Defender for Cloud インベントリ ページでコンテナー名を検索すると、それが重大としてマークされていることがわかります。

検証が成功すると、推奨事項、キャンペーン、GitHubでの問題生成など、後続の手順で意味のある結果が得られます。

次のステップ

関連するコンテンツ

• GitHubのAdvanced Securityネイティブ連携をMicrosoft Defender for Cloudと設定します
• GitHub Advanced Security と Microsoft Defender for Cloud の統合とは何ですか？
• クイック スタート: GitHub 環境を Microsoft Defender for Cloud に接続する