Поиск в журналах для ресурсов Azure

В Azure Monitor Log Analytics запросы обычно выполняются в контексте рабочей области. Рабочая область может содержать данные для множества ресурсов, что усложняет их изоляцию для определенного ресурса. Ресурсы могут дополнительно отправлять данные в несколько рабочих областей. Чтобы упростить этот процесс, REST API позволяет выполнять запросы напрямую к журналам ресурсов Azure.

Форматы URL-адресов

Формат запроса

Рассмотрим следующий пример, чтобы понять формат запроса:

Часть запроса Синтаксис
Полностью квалифицированный идентификатор ресурса Azure /subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>
Формат запроса для журналов этого ресурса на прямой конечной точке API https://api.loganalytics.azure.com/v1/subscriptions/<sid>/resourceGroups/<rg>/providers/<providerName>/<resourceType>/<resourceName>/query

Формат ответа

Запросы ресурсов Azure формируют ту же форму ответа, что и запросы для рабочей области Log Analytics.

Доступ к таблицам и RBAC

Лучший способ управления доступом на уровне таблицы — реализовать детализированный RBAC.

Контроль доступа к рабочей области

Запросы ресурсов Azure проверяют рабочие области Log Analytics как возможные источники данных. Однако администраторы могут ограничить доступ к рабочей области с помощью ролей и ограничить доступ к таблицам с детализацией RBAC. По умолчанию API возвращает результаты только из рабочих областей и таблиц, к которым пользователь имеет разрешения на доступ. Чтобы убедиться, что запросы ресурсов соответствуют требованиям RBAC в контексте рабочей области и таблицы, см. сведения, описанные в подробном руководстве по RBAC.

Устранение неполадок

Ниже приведен краткий список распространенных сценариев сбоя при запросе ресурсов 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.
  • Доступ к таблицам, на которые ссылается запрос.

По умолчанию эти сценарии создают успешный ответ с состоянием HTTP 200, но источники данных, у которых у пользователя нет разрешений на доступ, автоматически отфильтровываются.

Чтобы просмотреть подробные сведения о доступе пользователя к ресурсу 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 описывает попытку выполнить запрос к двум виртуальным машинам. Машина VM1 отправляет данные в рабочую область WS1, а VM2 — в две рабочие области: WS2 и WS3. Кроме того, у пользователя нет разрешения выполнять запросы таблиц SecurityEvent или SecurityBaseline для этого ресурса.

Полезная нагрузка dataSources отфильтровывает результаты, описывая, какие рабочие пространства пользователь может запрашивать. Здесь у пользователя нет разрешений на запрос WS3, а другая таблица отфильтровывается из WS1.

При рассмотрении элементов управления доступом для данных запрос возвращает следующее:

  • Журналы для VM1 в рабочей области WS1, за исключением Tables.Custom.
  • Журналы для VM2, кроме SecurityEvent и SecurityBaseline, в WS2.