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 リソースのログを読み取るためのアクセス権を与えても、それらのログが含まれるワークスペースのクエリを実行するためのアクセス許可を与えていない可能性があります。 ワークスペースのブール型プロパティを使用してログを表示するためのワークスペース管理者リソース。 これにより、ユーザーは、ターゲットの Azure リソースのログを読み取るためのアクセス権を持っている限り、特定のワークスペースにあるターゲットの Azure リソースに関連するログにアクセスできます。

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

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

エラー応答

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

Azure リソースが存在しない

    HTTP/1.1 404 Not Found 
    { 
        "error": { 
            "message": "The resource /subscriptions/7fd50ca7-1e78-4144-ab9c-0ec2faafa046/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 から追加のテーブルが除外されます。

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

• ワークスペースから Tables.Custom が除外された、WS1 内の VM1 のログ。
• WS2 の SecurityEvent と SecurityBaseline が除外された、VM2 のログ。