Sécuriser l’envoi de données dans Log Analytics v2 avec Azure Function

Dans cet article, je vais vous montrer une façon d’envoyer des données de manière sécurisée vers Log Analytics v2 en utilisant Azure Function et l’API Log Ingestion.

Contexte

Log Analytics est très utile pour créer vos propres tableaux de bord avec des données personnalisées.
Par exemple, vous pouvez utiliser un script de remédiation pour collecter des données à partir de vos appareils Intune et les envoyer à Log Analytics.
Pour cela, vous devez utiliser l’API Log Ingestion.
Le processus peut être trouvé dans mon article ici.

Par défaut, Microsoft recommande de créer un enregistrement d’application pour utiliser l’API Log Ingestion.
Le problème est que vous devez fournir des informations sur l’application dans votre script : appid, secret.
Dans cet article, nous voulons éviter cela et voir une méthode alternative.

La solution

Dans mon précédent article, j’ai expliqué comment faire cela en utilisant Azure Automation.
Voyons maintenant comment le faire avec Azure Function.

Voici comment cela fonctionne :

1. Une Azure Function avec une identité managée est créée.
2. Un script est utilisé pour collecter des données sur vos appareils.
3. Le script envoie les données à l’Azure Function.
4. L’Azure Function envoie les données à Log Analytics via l’identité managée.

Obtenir les scripts

Cliquez sur l’image GitHub ci-dessous pour obtenir les scripts.
Vous y trouverez :

• Assign_permissions.ps1 : script pour ajouter des permissions à l’identité managée.
• Function.ps1 : le script Azure Function.
• Un dossier d’exemples de scripts de remédiation.

Prérequis

Vous devez d’abord ajouter les prérequis pour utiliser l’API Log Ingestion (aussi appelée Log Analytics v2).
Consultez mon article ici pour plus d’informations.

Création de l’Azure Function

Objectif : Créer une Azure Function qui sera utilisée pour exécuter le script.

1. Allez sur Azure.
2. Accédez à Function app.
3. Choisissez Consumption

1. Cliquez sur Select.
2. Choisissez une Subscription, un resource group et une région.
3. Entrez un nom.
4. Dans Runtime stack, choisissez PowerShell.
5. Dans Version, choisissez la version par défaut.
6. Dans OS, sélectionnez Windows

1. Cliquez sur Review+Create.
2. Cliquez sur Create.

Configuration de l’identité managée

Objectif : L’identité managée est utilisée pour s’authentifier auprès de votre tenant, ce qui évite de fournir des identifiants.
Lors de la configuration, une nouvelle application d’entreprise Azure sera créée.
Celle-ci sera utilisée pour s’authentifier et effectuer des appels API.

Étapes :

1. Accédez à votre Function app.
2. Allez dans Identity

1. Sélectionnez System assigned
2. Activez On

1. Cliquez sur Save.
2. Cliquez sur Yes.
3. Une nouvelle application d’entreprise sera créée avec le même nom que le compte d’automatisation.

Ajout des permissions

Objectif : Pour vérifier si l’appareil existe et est géré, nous avons besoin des permissions suivantes.

Étapes :

1. Modifiez le script Assign_permissions.ps1.
2. Modifiez les variables $TenantID et $DisplayNameOfMSI.
3. Exécutez le script avec des droits d’administrateur global.

Création du script de fonction

1. Accédez à votre Function app.
2. Cliquez sur Create function

1. Sélectionnez HTTP trigger, puis cliquez sur Next

1. Entrez un nom.
2. Dans Authorization level, choisissez Anonymous

1. Cliquez sur Create.
2. Accédez à Code + Test

1. Sélectionnez Run.ps1.
2. Copiez le contenu de Function.ps1.
3. Cliquez sur Save.
4. Accédez à Get function URL

1. Copiez le lien pour plus tard (sans le « ? »).
2. Accédez à App files.
3. Allez dans profile.ps1.
4. Vérifiez que le code suivant est présent.

Ajout du rôle DCR

Objectif : Donner à l’application la permission d’utiliser le DCR.

Étapes :

1. Accédez à votre DCR.
2. Allez dans Access Control (IAM)

1. Cliquez sur Add role assignment

1. Sélectionnez Monitoring Metrics Publisher

1. Cliquez sur Next.
2. Choisissez User, group, or service principal.
3. Cliquez sur Select members

1. Recherchez l’identité managée de l’Azure Function.
2. Cliquez sur Select.
3. Cliquez sur Review + assign.

Sécurisation du processus

Dans le script de remédiation ou le script de base

Processus :

1. Collecter les données dans un tableau.
2. Ajouter le nom de la table et l’ID DCR au tableau.
3. Convertir le contenu en JSON.
4. Envoyer les données à l’Azure Function via le webhook.

Dans le dossier d’exemples, vous trouverez deux scripts pour collecter des données sur vos appareils :

• Send_drivers.ps1
• Send_services.ps1

Nous procéderons comme suit :

Remplir les variables $DCR, $Table et $AZ_Function_URL avec les infos appropriées

Collecter les informations nécessaires (ici, les drivers)

$PNPSigned_Drivers = get-ciminstance win32_PnpSignedDriver | where {($_.manufacturer -ne "microsoft") -and ($_.driverprovidername -ne "microsoft") -and`
($_.DeviceName -ne $null)} | select-object @{label="TimeGenerated";Expression={get-date -Format "dddd MM/dd/yyyy HH:mm K"}},`
@{Label="DCR";Expression={$DCR}},`
@{Label="Table";Expression={$Table}},`
@{Label="DeviceName";Expression={$env:computername}},`
@{Label="ModelFriendlyName";Expression={$Model_FriendlyName}},`
@{Label="DeviceManufacturer";Expression={$Manufacturer}},`
@{Label="Model";Expression={$Model}},`
@{Label="DriverName";Expression={$_.DeviceName}},DriverVersion,`
@{Label="DriverDate";Expression={$_.ConvertToDateTime($_.DriverDate)}},`
DeviceClass, DeviceID, manufacturer,InfName,Location

Convertir le contenu en JSON

$PS_Version = ($psversiontable).PSVersion.Major
If($PS_Version -eq 7)
    {
        $Body_JSON = $PNPSigned_Drivers | ConvertTo-Json -AsArray;
    }Else{
        $Body_JSON = $PNPSigned_Drivers | ConvertTo-Json
    }

Envoyer les données au runbook à l’aide du webhook

$AZ_Function_URL = ""
$Secure_header = @{message='Iam_a_bi_more_secure'}
$response = Invoke-WebRequest -Uri $AZ_Function_URL -Method POST -Body $body_json -Headers $Secure_header

Ici, vous remarquerez que j’ai ajouté un mot de passe dans l’en-tête, stocké dans la variable <code>$Secure_header

Dans le runbook, nous devrons bien sûr comparer les informations.
D’accord, d’accord, ce n’est pas suffisamment sécurisé, alors maintenant, travaillons sur le côté de la fonction Azure.

Dans le script de l’Azure Function

Dans le script d’envoi, nous avons ajouté un mot de passe. Pour le vérifier, procédez comme suit :

• Si le mot de passe du script de remédiation ne correspond pas, le script de la Function sera arrêté.
• Pour plus de sécurité, vérifiez que la source d’envoi est valide en s’assurant que l’appareil source est conforme et géré.

Ci-dessous le code pour vérifier la présence de ce qui a été saisi dans le header :

If($Request.Headers.message -ne 'Iam_a_bit_more_secure')
    {
        "Password not valid"
        EXIT
    }