Partager via


Comment utiliser App Control pour sécuriser PowerShell

Cet article explique comment configurer une stratégie App Control for Business . Vous pouvez configurer la stratégie de manière à appliquer ou auditer la règle de stratégie. En mode audit, le comportement de PowerShell ne change pas, mais il enregistre les messages avec l’ID d’événement 16387 dans le journal des événements PowerShellCore/Analytic. En mode de mise en conformité, PowerShell applique les restrictions de la stratégie.

Cet article suppose que vous utilisez une machine de test pour pouvoir tester le comportement de PowerShell sous une stratégie App Control à l’échelle de l’ordinateur avant de déployer la stratégie dans votre environnement.

Créer une stratégie App Control

Une stratégie App Control est décrite dans un fichier XML, qui contient des informations sur les options de stratégie, les fichiers autorisés et les certificats de signature reconnus par la stratégie. Lorsque la stratégie est appliquée, les fichiers approuvés sont les seuls autorisés à être chargés et exécutés. PowerShell bloque l’exécution des fichiers de script non approuvés ou les exécute en mode ConstrainedLanguage, en fonction des options de la stratégie.

Vous créez et manipulez la stratégie App Control à l’aide du module ConfigCI , disponible sur toutes les versions de Windows prises en charge. Ce module Windows PowerShell peut être utilisé dans Windows PowerShell 5.1 ou PowerShell 7 via la couche de compatibilité Windows. Il est plus facile d’utiliser ce module dans Windows PowerShell. La stratégie que vous créez peut être appliquée à n’importe quelle version de PowerShell.

Étapes de création d’une stratégie De contrôle d’application

Pour les tests, il suffit de créer une stratégie par défaut et un certificat de signature de code auto-signé.

  1. Créer une stratégie par défaut

    New-CIPolicy -Level PcaCertificate -FilePath .\SystemCIPolicy.xml -UserPEs
    

    Cette commande crée un fichier de stratégie par défaut appelé SystemCIPolicy.xml, qui permet à tous les fichiers avec code de signature Microsoft de s’exécuter.

    Remarque

    L’exécution de cette commande peut prendre jusqu’à deux heures, car elle doit analyser l’intégralité de l’ordinateur de test.

  2. Désactiver le mode audit dans la stratégie par défaut

    Une nouvelle stratégie est toujours créée en mode Audit. Pour tester l’application de la stratégie, vous devez désactiver le mode audit lorsque vous appliquez cette stratégie. Modifiez le fichier SystemCIPolicy.xml à l’aide d’un éditeur de texte tel que notepad.exe ou Visual Studio Code (VS Code). Commentez l’option Audit mode.

    <!--
    <Rule>
      <Option>Enabled:Audit Mode</Option>
    </Rule>
    -->
    
  3. Créer un certificat de signature de code auto-signé

    Vous avez besoin d’un certificat de signature de code pour signer tous les fichiers binaires de test ou de script que vous souhaitez exécuter sur votre ordinateur de test. Le New-SelfSignedCertificate est fourni par le module PKI. Pour obtenir les meilleurs résultats, vous devez exécuter cette commande dans Windows PowerShell 5.1.

    $newSelfSignedCertificateSplat = @{
        DnsName = $env:COMPUTERNAME
        CertStoreLocation = "Cert:\CurrentUser\My\"
        Type = 'CodeSigningCert'
    }
    $cert = New-SelfSignedCertificate @newSelfSignedCertificateSplat
    Export-Certificate -Cert $cert -FilePath c:\certs\signing.cer
    Import-Certificate -FilePath C:\certs\signing.cer -CertStoreLocation "Cert:\CurrentUser\Root\"
    $cert = Get-ChildItem Cert:\CurrentUser\My\ -CodeSigningCert
    
    dir c:\bin\powershell\pwsh.exe | Set-AuthenticodeSignature -Certificate $cert
    
  4. Ajouter le certificat de signature de code à la stratégie

    Utilisez la commande suivante pour ajouter le nouveau certificat de signature de code à la stratégie.

    Add-SignerRule -FilePath .\SystemCIPolicy.xml -CertificatePath c:\certs\signing.cer -User
    
  5. Convertir le fichier de stratégie XML en fichier binaire d’application de la stratégie

    Enfin, vous devez convertir le fichier XML en fichier binaire utilisé par App Control pour appliquer une stratégie.

    ConvertFrom-CIPolicy -XmlFilePath .\SystemCIPolicy.xml -BinaryFilePath .\SIPolicy.p7b
    
  6. Appliquer la stratégie App Control

    Pour appliquer la stratégie à votre ordinateur de test, copiez le fichier SIPolicy.p7b sur l’emplacement système requis, C:\Windows\System32\CodeIntegrity.

    Remarque

    Certaines définitions de stratégies doivent être copiées dans un sous-dossier tel que C:\Windows\System32\CodeIntegrity\CiPolicies. Pour plus d’informations, consultez Les conseils d’administration du contrôle d’application et les problèmes connus.

  7. Désactiver la stratégie App Control

    Pour désactiver la stratégie, renommez le fichier SIPolicy.p7b. Si vous devez effectuer d’autres tests, vous pouvez redonner au fichier son ancien nom pour réactiver la stratégie.

    Rename-Item -Path .\SIPolicy.p7b -NewName .\SIPolicy.p7b.off
    

Tester à l’aide de l’audit de stratégie App Control

PowerShell 7.4 a ajouté une nouvelle fonctionnalité pour prendre en charge les stratégies App Control en mode Audit . En mode audit, PowerShell exécute les scripts non approuvés en mode ConstrainedLanguage sans erreur, mais par contre, il enregistre les messages dans le journal des événements. Les messages du journal décrivent les restrictions qui s’appliqueraient si la stratégie était en mode de mise en conformité.

Affichage des événements d’audit

PowerShell enregistre les événements d’audit dans le journal des événements PowerShellCore/Analytic . Le journal n’est pas activé par défaut. Pour activer le journal, ouvrez l’observateur d’événements Windows, cliquez avec le bouton droit sur le journal PowerShellCore/Analytic, puis sélectionnez Activer le journal.

Nous pouvez également exécuter la commande suivante à partir d’une session PowerShell avec élévation de privilèges.

wevtutil.exe sl PowerShellCore/Analytic /enabled:true /quiet

Vous pouvez afficher les événements dans l’observateur d'événements Windows ou utiliser Get-WinEvent cmdlet pour récupérer les événements.

Get-WinEvent -LogName PowerShellCore/Analytic -Oldest |
    Where-Object Id -eq 16387 | Format-List
TimeCreated  : 4/19/2023 10:11:07 AM
ProviderName : PowerShellCore
Id           : 16387
Message      : App Control Audit.

    Title: Method or Property Invocation
    Message: Method or Property 'WriteLine' on type 'System.Console' invocation will not
        be allowed in ConstrainedLanguage mode.
        At C:\scripts\Test1.ps1:3 char:1
        + [System.Console]::WriteLine("pwnd!")
        + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    FullyQualifiedId: MethodOrPropertyInvocationNotAllowed

Le message d’événement inclut la position du script où la restriction serait appliquée. Ces informations vous aident à comprendre où vous devez modifier votre script afin qu’il s’exécute sous la stratégie App Control.

Important

Une fois que vous avez examiné les événements d’audit, vous devez désactiver le journal analytique. Les journaux analytiques augmentent rapidement et consomment de grandes quantités d’espace disque.

Affichage des événements d’audit dans le débogueur PowerShell

Si vous définissez la variable $DebugPreference sur Break pour une session PowerShell interactive, PowerShell s’insère dans le débogueur de script de ligne de commande à l’emplacement actuel du script où l’événement d’audit s’est produit. Le point d’arrêt vous permet de déboguer votre code et d’inspecter l’état actuel du script en temps réel.