Requêtes de ressources Azure dans les journaux

Article
10/30/2024

Dans Log Analytics Azure Monitor, les requêtes s’exécutent généralement dans le contexte d’un espace de travail. Un espace de travail peut contenir des données pour de nombreuses ressources, ce qui rend difficile l’isolation des données pour une ressource particulière. Les ressources peuvent également envoyer des données à plusieurs espaces de travail. Pour simplifier cette expérience, l’API REST permet d’interroger directement les journaux des ressources Azure.

Format de la réponse

Les requêtes de ressources Azure produisent la même forme de réponse que les requêtes ciblant un espace de travail Log Analytics.

Format d’URL

Prenons l’exemple d’une ressource Azure avec un identificateur complet :

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

Une requête pour les journaux de cette ressource par rapport au point de terminaison d’API direct accède à l’URL suivante :

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

Une requête portant sur la même ressource via ARM utilise l’URL suivante :

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

Pour l’essentiel, cette URL est la ressource Azure qualifiée complète plus le fournisseur d’extension : /providers/microsoft.insights/logs.

Accès aux tables et RBAC

Le fournisseur de ressources microsoft.insights expose un nouvel ensemble d’opérations pour contrôler l’accès aux journaux au niveau de la table. Ces opérations ont le format suivant pour une table nommée tableName.

microsoft.insights/logs/<tableName>/read

Vous pouvez ajouter cette autorisation aux rôles en utilisant la propriété actions pour autoriser les tables spécifiées, et en utilisant la propriété notActions afin d’interdire les tables spécifiées.

Contrôle d’accès aux espaces de travail

Les demandes de ressources Azure considèrent les espaces de travail Log Analytics comme des sources de données possibles. Toutefois, les administrateurs peuvent verrouiller l’accès à l’espace de travail via des rôles RBAC. Par défaut, l’API retourne uniquement les résultats des espaces de travail pour lesquels l’utilisateur dispose d’autorisations d’accès.

Les administrateurs d’espace de travail peuvent utiliser des demandes de ressources Azure sans enfreindre aux RBAC existants. Une propriété booléenne sur l’espace de travail permet aux utilisateurs disposant d’autorisations de lecture afficher les journaux d’activité d’une ressource Azure spécifique, mais pas d’interroger l’espace de travail qui contient ces journaux.

Voici l’action permettant d’étendre l’accès aux tables au niveau de l’espace de travail :

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

Réponses d’erreur

Voici une brève liste des scénarios d’échec courants lors de l’interrogation des ressources Azure, ainsi qu’une description du comportement symptomatique.

La ressource Azure n’existe pas

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" 
    }
}

Aucun accès à la ressource

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"
        }
    } 
}

Aucun journal de la ressource, ou aucune autorisation sur l’espace de travail contenant ces journaux

Selon la combinaison précise de données et d’autorisations, la réponse contient une erreur 200 sans données résultantes ou génère une erreur de syntaxe (erreur 4xx).

Accès partiel

Dans certains cas, un utilisateur peut avoir des autorisations partielles pour accéder aux journaux d’une ressource particulière. C’est le cas si l’utilisateur n’a pas :

Accès à l’espace de travail contenant les journaux pour la ressource Azure.
Accès à la référence de tables dans la requête.

Ils voient une réponse normale, avec les sources de données auxquelles l’utilisateur n’a pas les autorisations d’accès filtrées silencieusement. Pour afficher des informations sur l’accès d’un utilisateur à une ressource Azure, aux espaces de travail Log Analytics sous-jacents et à des tables spécifiques, incluez l’en-tête Prefer: include-permissions=true avec les demandes. La réponse JSON inclut alors une section semblable à l’exemple suivant :

{ 
    "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" 
            } 
        ] 
    } 
}

La charge utile resources décrit une tentative d’interrogation de deux machines virtuelles. VM1 envoie des données à l’espace de travail WS1, tandis que VM2 envoie des données à deux espaces de travail : WS2 et WS3. En outre, l’utilisateur n’est pas autorisé à interroger les tables SecurityEvent ou SecurityBaseline pour la ressource.

La charge utile dataSources filtre davantage les résultats en décrivant les espaces de travail que l’utilisateur peut interroger. Ici, l’utilisateur n’a pas les autorisations nécessaires pour interroger WS3 et une autre table filtrée sur WS1.

Voici en clair quelles sont les données qu’une telle requête retournerait :

Journaux d’activité de VM1 dans WS1, à l’exception des tables. Personnalisé à partir de l’espace de travail.
Journaux pour VM2, à l’exception de SecurityEvent et SecurityBaseline, dans WS2

Partage via