次の方法で共有

Azure リソースのログのクエリ

  • [アーティクル]

Azure Monitor Log Analytics でのクエリは、通常、ワークスペースのコンテキストで実行されます。 ワークスペースには多くのリソースのデータが含まれている場合があるため、特定のリソースのデータを分離することが難しくなります。 さらに、リソースから複数のワークスペースにデータが送信される場合があります。 このエクスペリエンスを簡単にするため、REST API では、Azure リソースのログに対して直接クエリを実行できます。

応答形式

Azure リソースのクエリでは、Log Analytics ワークスペースを対象とするクエリと同じ形式の応答が生成されます。

URL 形式

完全修飾識別子を持つ Azure リソースについて考えます。

/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>

直接 API エンドポイントに対するこのリソースのログのクエリは、次の URL に送信されます。

https://api.loganalytics.azure.com/v1/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>/query

同じリソースに対する ARM によるクエリでは、次の URL を使います。

https://management.azure.com/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>/providers/microsoft.insights/logs?api-version=2018-03-01-preview

基本的に、この URL は完全修飾された Azure リソースに拡張機能プロバイダーを付加したものです: /providers/microsoft.insights/logs。

テーブル アクセスと RBAC

microsoft.insights リソース プロバイダーによって、テーブル レベルでログへのアクセスを制御するための新しい操作のセットが公開されます。 これらの操作には、テーブル名 tableName を付加した次の形式を使います。

microsoft.insights/logs/<tableName>/read

このアクセス許可をロールに追加できます。指定したテーブルを許可する場合は actions プロパティを使い、指定したテーブルを許可しない場合は notActions プロパティを使います。

ワークスペースのアクセス制御

Azure リソースのクエリでは、可能なデータ ソースとして Log Analytics ワークスペースが検索されます。 ただし、管理者が RBAC ロールを使ってワークスペースへのアクセスをロックできます。 既定では、ユーザーがアクセス許可を持っているワークスペースからの結果のみが、API から返されます。

ワークスペース管理者は、既存の RBAC を終了することなく、Azure リソース クエリを使用できます。 ワークスペースのブール型プロパティにより、読み取りアクセス許可を持つユーザーは特定の Azure リソースのログを表示できますが、それらのログを含むワークスペースにクエリを実行することはできません。

これは、ワークスペース レベルでアクセスのスコープをテーブルに設定するためのアクションです。

microsoft.operationalinsights/workspaces/query/<tableName>/read

エラー応答

ここでは、Azure リソースのクエリを実行するときの一般的なエラー シナリオと、現象の動作について説明します。

Azure リソースが存在しない

    HTTP/1.1 404 Not Found 
    { 
        "error": { 
            "message": "The resource /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/test-rg/providers/microsoft.storage/storageaccounts/exampleResource was not found", 
            "code": "ResourceNotFoundError" 
        }
    }
}

リソースへのアクセス権がない

HTTP/1.1 403 Forbidden 
{
    "error": { 
        "message": "The provided credentials have insufficient access to  perform the requested operation", 
        "code": "InsufficientAccessError", 
        "innererror": { 
            "code": "AuthorizationFailedError",
            "message": "User '92eba38a-70da-42b0-ab83-ffe82cce658f' does not have access to read logs for this resource"
        }
    } 
}

リソースからログが返されない、またはそれらのログが含まれるワークスペースへのアクセス許可がない

データとアクセス許可の正確な組み合わせに応じて、応答には結果のデータがなくて 200 が含まれるか、または構文エラー (4xx エラー) がスローされます。

部分的なアクセス

特定のリソースのログにアクセスするためのアクセス許可の一部だけを、ユーザーが持っている場合があります。 以下は、ユーザーにどちらかが不足している場合です。

  • Azure リソースのログを含むワークスペースへのアクセス権。
  • クエリ内のテーブル参照へのアクセス権。

ユーザーにアクセス許可がないデータ ソースは通知なしにフィルター処理され、通常の応答が表示されます。Azure リソース、基になる Log Analytics ワークスペース、特定のテーブルへのユーザーのアクセスに関する情報を確認するには、要求にヘッダー Prefer: include-permissions=true を含めます。 これにより、応答の JSON に次の例のようなセクションが含まれるようになります。

{ 
    "permissions": { 
        "resources": [ 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.Compute/virtualMachines/VM1", 
                "dataSources": [ 
                    "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS1" 
                ] 
            }, 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.Compute/virtualMachines/VM2", 
                "denyTables": [ 
                    "SecurityEvent", 
                    "SecurityBaseline" 
                ], 
                "dataSources": [ 
                    "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS2",
                    "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS3" 
                ] 
            } 
        ], 
        "dataSources": [ 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS1", 
                "denyTables": [ 
                    "Tables.Custom" 
                ] 
            }, 
            { 
                "resourceId": "/subscriptions/<id>/resourceGroups<id>/providers/Microsoft.OperationalInsights/workspaces/WS2" 
            } 
        ] 
    } 
}

resources ペイロードでは、2 つの VM のクエリを実行する試みが記述されています。 VM1 のデータはワークスペース WS1 に送信されますが、VM2 のデータは 2 つのワークスペース WS2 と WS3 に送信されます。 さらに、ユーザーには、リソースの SecurityEvent または SecurityBaseline テーブルのクエリを実行するアクセス許可がありません。

dataSources ペイロードでは、ユーザーがクエリを実行できるワークスペースを記述することで、結果がさらにフィルター処理されます。 この場合、ユーザーには WS3 のクエリを実行するためのアクセス許可がなく、WS1 から他のテーブルが除外されます。

そのようなクエリから返されるデータを明確に示すと、次のようになります。

  • WS1 の VM1 のログ (テーブルを除く)。 ワークスペースからのカスタマイズ。
  • WS2 の SecurityEvent と SecurityBaseline が除外された、VM2 のログ。