次の方法で共有


Microsoft Defender for Cloud トラブルシューティング ガイド

このガイドは、Microsoft Defender for Cloud に関連する問題のトラブルシューティングを行う必要がある組織の IT プロフェッショナル、情報セキュリティ アナリスト、クラウド管理者のためのものです。

ヒント

問題に直面している場合、またはサポート チームからのアドバイスが必要な場合は、Azure portal の [問題の診断と解決] セクションが解決策を探すのに適しています。

Defender for Cloud の問題を診断して解決するためのページを示す Azure portal のスクリーンショット。

監査ログを使って問題を調べる

トラブルシューティング情報を探す最初の場所は、失敗したコンポーネントの監査ログです。 監査ログでは、次のような詳細を確認できます。

  • 実行された操作。
  • 操作を開始したユーザー。
  • 操作が発生した時間。
  • 操作の状態。

監査ログには、リソースで実行されたすべての書き込み操作 (PUTPOSTDELETE) が含まれますが、読み取り操作 (GET) は含まれません。

コネクタのトラブルシューティング

Defender for Cloud では、コネクタを使って、アマゾン ウェブ サービス (AWS) アカウントと Google Cloud Platform (GCP) プロジェクトから監視データが収集されます。 コネクタで問題が発生している場合、または AWS や GCP からのデータが表示されない場合は、以下のトラブルシューティングのヒントを確認してください。

コネクタの一般的な問題に関するヒント

  • Azure portal の [ディレクトリとサブスクリプション] セクションにあるサブスクリプション フィルターで、コネクタに関連付けられているサブスクリプションが選ばれていることを確認します。
  • 標準は、セキュリティ コネクタに割り当てる必要があります。 確認するには、Defender for Cloud の左側のメニューで [環境設定] に移動し、コネクタを選んでから、[設定] を選びます。 標準が割り当てられていない場合は、3 つのドットを選んで、標準を割り当てるためのアクセス許可があるかどうかを確認します。
  • コネクタ リソースが、Azure Resource Graph に存在している必要があります。 調べるには、次の Resource Graph クエリを使います: resources | where ['type'] =~ "microsoft.security/securityconnectors"
  • コントロール プレーンの脅威検出アラートを取得できるように、AWS または GCP コネクタで Kubernetes 監査ログの送信が有効になっていることを確認します。
  • Microsoft Defender センサーと Azure Arc 対応 Kubernetes 拡張機能用の Azure Policy が、Amazon Elastic Kubernetes Service (EKS) クラスターと Google Kubernetes Engine (GKE) クラスターに正常にインストールされていることを確認します。 エージェントの確認とインストールは、Defender for Cloud に関する以下の推奨事項に従って実行できます。
    • EKS クラスターには、Azure Arc 用の Microsoft Defender の拡張機能をインストールする必要がある
    • GKE クラスターには、Azure Arc 用の Microsoft Defender の拡張機能をインストールする必要がある
    • Azure Arc 対応 Kubernetes クラスターには、Azure Policy 拡張機能がインストールされている必要がある
    • GKE クラスターには、Azure Policy 拡張機能がインストールされている必要がある
  • AWS または GCP コネクタの削除で問題が発生する場合は、自分がロックを持っているかどうかを調べます。 Azure アクティビティ ログのエラーが、ロックの有無のヒントになる可能性があります。
  • AWS アカウントまたは GCP プロジェクトにワークロードが存在することを確認します。

AWS コネクタの問題に関するヒント

  • CloudFormation テンプレートのデプロイが正常に完了したことを確認します。
  • AWS ルート アカウントの作成後、少なくとも 12 時間待ちます。
  • EKS クラスターが Azure Arc 対応 Kubernetes に正常に接続されていることを確認します。
  • Defender for Cloud に AWS データが表示されない場合は、Defender for Cloud にデータを送信するために必要な AWS リソースが AWS アカウントにあることを確認します。

AWS への API 呼び出しのコストへの影響

AWS の単一アカウントまたは管理アカウントをオンボードすると、Defender for Cloud の検出サービスによって環境の即時スキャンが開始されます。 探索サービスは、Azure がセキュリティ保護に役立つすべてのリソースを取得するため、さまざまなサービス エンドポイントへの API 呼び出しを実行します。

この初期スキャンの後、サービスはユーザーがオンボード時に構成した間隔で、環境の定期的なスキャンを続けます。 AWS では、アカウントに対する API 呼び出しのたびに、CloudTrail リソースに記録される検索イベントが生成されます。 CloudTrail リソースにはコストが発生します。 価格について詳しくは、Amazon AWS のサイトの「AWS CloudTrail の料金」ページをご覧ください。

CloudTrail を GuardDuty に接続した場合は、それに関連するコストも負担します。 これらのコストについては、Amazon AWS のサイトの GuardDuty に関するドキュメントで確認できます。

ネイティブ API 呼び出しの回数を取得する

Defender for Cloud が行った呼び出しの回数を取得するには、2 つの方法があります。

  • 既存の Athena テーブルを使うか、新しく作成します。 詳しくは、Amazon AWS のサイトの「AWS CloudTrail ログのクエリの実行」をご覧ください。
  • 既存のイベント データ ストアを使うか、新しく作成します。 詳しくは、Amazon AWS のサイトの「AWS CloudTrail Lake の使用」をご覧ください。

どちらの方法も、AWS CloudTrail ログのクエリに依存します。

呼び出しの回数を取得するには、Athena テーブルまたはイベント データ ストアに移動し、必要に応じて、次の定義済みクエリのいずれかを使います。 <TABLE-NAME> は、Athena テーブルまたはイベント データ ストアの ID に置き換えてください。

  • Defender for Cloud による API 呼び出し全体の数を一覧表示します。

    SELECT COUNT(*) AS overallApiCallsCount FROM <TABLE-NAME> 
    WHERE userIdentity.arn LIKE 'arn:aws:sts::<YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>' 
    AND eventTime > TIMESTAMP '<DATETIME>' 
    
  • Defender for Cloud による API 呼び出し全体の数を、日別に集計して一覧表示します。

    SELECT DATE(eventTime) AS apiCallsDate, COUNT(*) AS apiCallsCountByRegion FROM <TABLE-NAME> 
    WHERE userIdentity.arn LIKE 'arn:aws:sts:: <YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>' 
    AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY DATE(eventTime)
    
  • Defender for Cloud による API 呼び出し全体の数を、イベント名別に集計して一覧表示します。

    SELECT eventName, COUNT(*) AS apiCallsCountByEventName FROM <TABLE-NAME> 
    WHERE userIdentity.arn LIKE 'arn:aws:sts::<YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>' 
    AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY eventName     
    
  • Defender for Cloud による API 呼び出し全体の数を、リージョン別に集計して一覧表示します。

    SELECT awsRegion, COUNT(*) AS apiCallsCountByRegion FROM <TABLE-NAME> 
    WHERE userIdentity.arn LIKE 'arn:aws:sts::120589537074:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>' 
    AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY awsRegion
    

GCP コネクタの問題に関するヒント

  • GCP Cloud Shell スクリプトが正常に完了したことを確認します。
  • GKE クラスターが Azure Arc 対応 Kubernetes に正常に接続されていることを確認します。
  • Azure Arc エンドポイントがファイアウォール許可リストにあることを確認します。 GCP コネクタにより、これらのエンドポイントに対して API 呼び出しが行われ、必要なオンボード ファイルがフェッチされます。
  • GCP プロジェクトのオンボードが失敗する場合は、オンボード プロセス用のサービス プリンシパルを作成するための compute.regions.list アクセス許可と Microsoft Entra アクセス許可があることを確認します。 GCP リソース WorkloadIdentityPoolIdWorkloadIdentityProviderIdServiceAccountEmail が GCP プロジェクトに作成されていることを確認します。

GCP への Defender API 呼び出し

GCP の単一のプロジェクトまたは組織をオンボードすると、Defender for Cloud の検出サービスによって環境の即時スキャンが開始されます。 探索サービスは、Azure がセキュリティ保護に役立つすべてのリソースを取得するため、さまざまなサービス エンドポイントへの API 呼び出しを実行します。

この初期スキャンの後、サービスはユーザーがオンボード時に構成した間隔で、環境の定期的なスキャンを続けます。

Defender for Cloud が実行したネイティブ API 呼び出しの回数を取得するには:

  1. [ログ]>[Log Explorer] (ログ エクスプローラー) に移動します。

  2. 必要に応じて日付をフィルター処理します (例: 1d)。

  3. Defender for Cloud が実行した API 呼び出しを表示するには、次のクエリを実行します。

    protoPayload.authenticationInfo.principalEmail : "microsoft-defender"
    

ヒストグラムを見て、時間経過に伴う呼び出しの回数を確認します。

Log Analytics エージェントのトラブルシューティング

Defender for Cloud では、データを収集して保存するために Log Analytics エージェントが使用されます。 この記事の情報は、Log Analytics エージェントへの移行後の Security Center の機能を表しています。

アラートの種類は次のとおりです。

  • 仮想マシンの動作分析 (VMBA)
  • ネットワーク分析
  • Azure SQL Database と Azure Synapse Analytics の分析
  • コンテキスト情報

アラートの種類に応じて、アラートを調査するために必要な情報を次のリソースを使って収集できます。

  • Windows の仮想マシン (VM) イベント ビューアーのセキュリティ ログ
  • Linux の監査デーモン (auditd)
  • Azure アクティビティ ログと、攻撃リソースで有効にされている診断ログ

アラートの説明と関連性のフィードバックは共有することができます。 アラートに移動して、[お役に立ちましたか?] ボタンを選び、理由を選んでから、フィードバックを説明するコメントを入力します。 アラートを向上させるために、このフィードバック チャネルは常に監視されています。

Log Analytics エージェントのプロセスとバージョンを確認する

Azure Monitor と同様に、Defender for Cloud でも Log Analytics エージェントを使って、Azure 仮想マシンからセキュリティ データが収集されます。 データ収集を有効にして、エージェントをターゲット マシンに正しくインストールすると、HealthService.exe プロセスが実行されます。

サービス管理コンソール (services.msc) を開き、Log Analytics エージェント サービスが実行されていることを確認します。

タスク マネージャーの Log Analytics エージェント サービスのスクリーンショット。

使っているエージェントのバージョンを確認するには、タスク マネージャーを開きます。 [プロセス] タブで、Log Analytics エージェント サービスを見つけて右クリックし、[プロパティ] を選びます。 [詳細] タブで、ファイルのバージョンを確認します。

Log Analytics エージェント サービスの詳細のスクリーンショット。

Log Analytics エージェントのインストール シナリオを確認する

コンピューターに Log Analytics エージェントをインストールするとき、異なる結果になる可能性がある 2 つのシナリオがあります。 サポートされるシナリオは次のとおりです。

  • Defender for Cloud によって自動的にインストールされたエージェント: Defender for Cloud とログ検索でアラートを表示できます。 リソースが属しているサブスクリプション用のセキュリティ ポリシーで構成したメール アドレスで、メール通知を受け取ります。

  • Azure にある VM に手動でインストールしたエージェント: このシナリオでは、2017 年 2 月以前に手動でダウンロードしてインストールしたエージェントを使っている場合、Defender for Cloud ポータルでアラートを表示できるのは、"ワークスペース" が属しているサブスクリプションでフィルター処理を行った場合だけです。 "リソース" が属しているサブスクリプションでフィルター処理を行った場合は、アラートは表示されません。 ワークスペースが属しているサブスクリプション用のセキュリティ ポリシーで構成したメール アドレスで、メール通知を受け取ります。

    フィルター処理の問題を回避するには、必ず最新バージョンのエージェントをダウンロードしてください。

エージェントのネットワーク接続の問題を監視する

エージェントが Defender for Cloud に接続して登録するには、Azure ネットワーク リソースの DNS アドレスとネットワーク ポートにアクセスできる必要があります。 このアクセスを有効にするには、次のアクションを実行します。

  • プロキシ サーバーを使用する場合は、エージェントの設定で適切なプロキシ サーバー リソースが正しく構成されていることを確認します。
  • Log Analytics へのアクセスを許可するように、ネットワーク ファイアウォールを構成します。

Azure ネットワーク リソースは次のとおりです。

エージェントのリソース Port バイパス HTTPS 検査
*.ods.opinsights.azure.com 443 はい
*.oms.opinsights.azure.com 443 はい
*.blob.core.windows.net 443 はい
*.azure-automation.net 443 はい

Log Analytics エージェントのオンボードで問題が発生する場合は、「Operations Management Suite のオンボードに関する問題のトラブルシューティング」をご覧ください。

不適切に動作するマルウェア対策の保護のトラブルシューティング

ゲスト エージェントは、Microsoft Antimalware 拡張機能によって行われるすべての処理の親プロセスです。 ゲスト エージェント プロセスが失敗すると、ゲスト エージェントの子プロセスとして実行されている Microsoft マルウェア対策の保護も失敗する可能性があります。

トラブルシューティングのいくつかのヒントを次に示します。

  • ターゲット VM がカスタム イメージから作成された場合は、VM の作成者がゲスト エージェントをインストールしたことを確認します。
  • ターゲットが Linux VM の場合、Windows バージョンのマルウェア対策拡張機能をインストールすると失敗します。 Linux ゲスト エージェントには、特定の OS とパッケージの要件があります。
  • VM が以前のバージョンのゲスト エージェントで作成された場合、新しいバージョンに自動更新する機能を以前のエージェントが備えていない可能性があります。 独自のイメージを作成するときは、常に最新バージョンのゲスト エージェントを使ってください。
  • 一部のサード パーティ製管理ソフトウェアによって、ゲスト エージェントが無効にされたり、特定のファイルの場所へのアクセスがブロックされたりする可能性があります。 VM にサード パーティ製管理ソフトウェアがインストールされている場合は、マルウェア対策エージェントが除外リストに含まれていることを確認してください。
  • ファイアウォールの設定とネットワーク セキュリティ グループが、ゲスト エージェントとの間のネットワーク トラフィックをブロックしていないことを確認します。
  • ディスク アクセスを妨げているアクセス制御リストがないことを確認します。
  • ゲスト エージェントが正常に機能するには、十分なディスク領域が必要です。

Microsoft Antimalware のユーザー インターフェイスは、既定では無効になります。 ただし、Azure Resource Manager VM で Microsoft Antimalware のユーザー インターフェイスを有効にできます。

ダッシュボードの読み込みに関する問題のトラブルシューティング

ワークロード保護ダッシュボードの読み込みで問題が発生する場合は、サブスクリプションで Defender for Cloud を最初に有効にしたユーザーと、データ収集を有効にしたいユーザーが、サブスクリプションの "所有者" または "共同作成者" のロールを持っていることを確認します。 そうなっている場合、サブスクリプションの "閲覧者" ロールを持つユーザーは、ダッシュボード、アラート、推奨事項、ポリシーを見ることができます。

Azure DevOps 組織のコネクタに関する問題のトラブルシューティング

Azure DevOps 組織をオンボードできない場合は、次のトラブルシューティングのヒントを試してださい。

  • Azure portal のプレビューではないバージョンを使っていることを確認します。承認手順は、Azure portal のプレビューでは機能しません。

  • システムは、ユーザーがアクセスを承認するときにサインインしているアカウントを使ってオンボードを行うので、そのアカウントを把握しておくことが重要です。 お使いのアカウントは同じメール アドレスに関連付けることができますが、異なるテナントにも関連付けることができます。 アカウントとテナントの適切な組み合わせを選んでいることを確認します。 組み合わせを変更する必要がある場合:

    1. Azure DevOps のプロファイル ページで、ドロップダウン メニューを使って別のアカウントを選びます。

      アカウントの選択に使用される Azure DevOps のプロファイル ページのスクリーンショット。

    2. 適切なアカウントとテナントの組み合わせを選んだ後、Defender for Cloud で [環境設定] に移動し、Azure DevOps コネクタを編集します。 コネクタを再認証して、正しいアカウントとテナントの組み合わせでそれを更新します。 その後、ドロップダウン メニューに正しい組織の一覧が表示されるはずです。

  • オンボードする Azure DevOps 組織に対する "プロジェクト コレクション管理者" ロールがあることを確認します。

  • Azure DevOps 組織で、[OAuth を使用したサード パーティ アプリケーションのアクセス] トグルが [オン] になっていることを確認します。 OAuth アクセスの有効化の詳細を確認してください

Microsoft サポートに問い合わせる

Defender for Cloud のトラブルシューティング情報は、Defender for Cloud の Q&A ページでも確認できます。

さらにサポートが必要な場合は、Azure portal で新しいサポート 要求を開くことができます。 [ヘルプとサポート] ページで、[サポート リクエストの作成] を選択します。

Azure portal でサポート リクエストを作成するための選択項目のスクリーンショット。

関連項目