Requêtes de ressources Azure dans les journaux

Article
06/01/2023

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

Cette autorisation peut être ajoutée aux rôles à l’aide de la propriété « actions » afin d’autoriser les tables spécifiées et la propriété « notActions » afin d’interdire les tables spécifiées.

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

Aujourd’hui, les requêtes de ressources Azure considèrent les espaces de travail Log Analytics comme des sources de données possibles. Toutefois, les administrateurs peuvent avoir verrouillé 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 souhaiter utiliser des requêtes de ressources Azure sans rompre le contrôle RBAC existant, créant ainsi un scénario dans lequel un utilisateur peut avoir accès en lecture aux journaux d’une ressource Azure sans avoir l’autorisation d’interroger l’espace de travail contenant ces journaux. Les administrateurs d’espace de travail peuvent autoriser l’affichage des journaux par le biais d’une propriété booléenne sur l’espace de travail. Cela permet aux utilisateurs d’accéder aux journaux relatifs à la ressource Azure cible dans un espace de travail particulier, tant que l’utilisateur dispose d’un accès en lecture aux journaux de la ressource Azure cible.

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

Vous trouverez ci-dessous 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. Lorsqu’un utilisateur ne dispose pas de l’un des éléments suivants :

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

Il verra une réponse normale, mais les sources de données pour lesquelles il ne dispose pas des autorisations d’accès seront filtrées en mode silencieux. 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 requêtes. La réponse JSON inclura alors une section telle que la suivante :

    { 
        "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 ne dispose pas des autorisations nécessaires pour interroger WS3, et une table supplémentaire est filtrée hors de WS1.

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

Journaux pour VM1 dans WS1, à l’exclusion de Tables.Custom de l’espace de travail
Journaux pour VM2, à l’exception de SecurityEvent et SecurityBaseline, dans WS2

Partage via