Politique d'exécution PowerShell et signature de scripts — Guide pratique pour sortir de l'exploitation « on colmate avec Bypass »

« Sur un nouveau PC, un script ne s’exécute pas et affiche “l’exécution de scripts est désactivée sur ce système…” » « J’ai ajouté -ExecutionPolicy Bypass et ça a marché, alors maintenant c’est écrit comme ça dans toutes les tâches » « Un fichier .ps1 placé dans un dossier partagé déclenche une erreur de signature, mais seulement sur le poste d’une personne » — la politique d’exécution de PowerShell est un mur contre lequel on se heurte presque à coup sûr dès que l’on avance dans l’automatisation interne. Et sur beaucoup de terrains, le correctif qui s’accumule, sans que le mécanisme soit vraiment compris, consiste à « colmater avec Bypass ».

Ce qui rend les choses délicates, c’est qu’il est facile de se méprendre sur ce que la politique d’exécution protège réellement. La traiter comme une fonctionnalité de sécurité et la durcir à l’excès finit par bloquer le travail. À l’inverse, se dire « de toute façon ça ne sert à rien » et tout basculer en Bypass revient à retirer le dernier dispositif de sécurité qui empêche les erreurs accidentelles. Ces deux écueils s’évitent dès lors que l’on comprend le mécanisme.

Cet article s’adresse aux responsables informatiques de PME et à toute personne qui automatise des tâches internes récurrentes avec PowerShell. Il expose, en s’appuyant sur la documentation officielle, ce qu’est réellement la politique d’exécution, l’ordre de priorité des portées, sa relation avec Zone.Identifier (le fameux Mark of the Web), ainsi que la mise en place d’une exploitation de distribution reposant sur la signature de scripts.

1. L’essentiel en bref

• La politique d’exécution est un dispositif de sécurité, pas une frontière de sécurité. La documentation officielle affirme sans détour que « la politique d’exécution n’est pas un système de sécurité qui restreint les actions de l’utilisateur » et qu’« elle peut être trivialement contournée en tapant le contenu d’un script dans la ligne de commande ». Son but est de fixer des règles de base et d’empêcher une exécution non intentionnelle — des erreurs accidentelles.¹
• La politique d’exécution n’affecte que l’exécution des scripts — vous pouvez toujours exécuter des commandes interactives, quelle qu’elle soit. Windows PowerShell 5.1 est réglé par défaut sur Restricted (aucune exécution de script) sur les OS clients et sur RemoteSigned sur Windows Server. PowerShell 7 est réglé par défaut sur RemoteSigned.²¹
• La politique comporte cinq portées, avec l’ordre de priorité MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine. MachinePolicy et UserPolicy sont réservées à la Stratégie de groupe ; vous ne pouvez pas les modifier avec Set-ExecutionPolicy, et aucune spécification en ligne de commande ne peut non plus les remplacer.¹³
• RemoteSigned n’exige une signature que pour les scripts provenant « d’Internet ». Cette origine est déterminée par le flux de données alternatif Zone.Identifier attaché au fichier (le Mark of the Web) ; une fois le contenu examiné, le supprimer avec Unblock-File permet d’exécuter le script sans jamais modifier la politique.¹⁴
• AllSigned exige la signature d’un éditeur de confiance sur tous les scripts, y compris ceux créés localement. La signature s’applique avec Set-AuthenticodeSignature, qui l’intègre sous forme d’un bloc de commentaires # SIG # en fin de fichier.¹⁵
• Attachez toujours un horodatage (-TimestampServer) à une signature. Avec un horodatage, le script continue de fonctionner même après l’expiration du certificat de signature. La plupart des certificats de signature de code étant valides un an, omettre ce point transforme la situation en bombe à retardement qui explose chaque année.⁶⁵
• Un certificat auto-signé est réservé aux tests. Un script signé avec un certificat auto-signé ne s’exécutera sur aucun autre ordinateur. Pour une distribution au sein de l’organisation, utilisez un certificat de signature de code émis par une autorité de certification (une AC interne ou une AC commerciale).⁵⁷
• Pour un contrôle à l’échelle de l’organisation, gérez-le de façon centralisée via le réglage « Activer l’exécution de scripts » de la Stratégie de groupe. Ce réglage prime sur tous les réglages de portée côté PowerShell.¹

2. Ce qu’est réellement la politique d’exécution — un « dispositif de sécurité », pas une « frontière de sécurité »

Commençons par vérifier la prémisse. La documentation officielle (about_Execution_Policies) est directe sur ce point. La politique d’exécution est un « dispositif de sécurité » (safety feature) qui contrôle les conditions dans lesquelles PowerShell charge les fichiers de configuration et exécute les scripts — ce n’est « pas un système de sécurité qui restreint les actions de l’utilisateur ». C’est parce que même un utilisateur qui ne peut pas exécuter un script peut réaliser le même traitement en collant simplement le contenu du script dans la ligne de commande. Il est explicitement indiqué que le rôle de la politique d’exécution est de fixer des règles de base et d’empêcher une violation non intentionnelle de celles-ci.¹ La documentation de prise en main répète le même point : « ce n’est pas une frontière de sécurité ; elle ne peut pas arrêter un utilisateur qui cherche délibérément à exécuter un script ».²

Une fois cette position bien comprise, l’orientation de la conception opérationnelle se dessine d’elle-même. « Durcir la politique d’exécution empêchera les attaques » comme « c’est inutile de toute façon puisqu’on peut la contourner » sont deux idées fausses. La lutte contre les attaques relève d’une autre couche (contrôle des applications, principe du moindre privilège, journaux d’audit) ; le travail de la politique d’exécution est de prévenir les accidents.⁸

Voici un résumé des différences entre les principales politiques.¹

C’est facile à négliger, mais Restricted ne bloque pas seulement vos propres scripts métier — elle empêche également le chargement des profils (.ps1), des modules (.psm1) et des fichiers de configuration de mise en forme (.ps1xml).¹ Découvrir que « le profil ne se charge pas sur le nouveau poste » est causé par la politique d’exécution est un motif de consultation classique et récurrent.

3. Portées et ordre de priorité — ce qui se cache derrière « je l’ai configuré, mais rien n’a changé »

La politique d’exécution n’est pas une valeur unique — elle peut être définie indépendamment à cinq portées différentes, et celle qui a la priorité la plus élevée devient la valeur effective.¹

La façon standard de diagnostiquer « je l’ai configuré, mais rien n’a changé » consiste à regarder la liste complète, pas seulement la valeur effective.

# Vérifiez toujours quelle portée est réellement appliquée, pas seulement la politique effective
Get-ExecutionPolicy -List

# Exemple : même avec LocalMachine réglé sur AllSigned, le RemoteSigned de CurrentUser l'emporte
#         Scope ExecutionPolicy
#         ----- ---------------
# MachinePolicy       Undefined
#    UserPolicy       Undefined
#       Process       Undefined
#   CurrentUser    RemoteSigned
#  LocalMachine       AllSigned

# Pour ne modifier que votre propre environnement, la portée CurrentUser est pratique car elle ne nécessite pas de droits d'administrateur
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Comme CurrentUser prime sur LocalMachine, la politique effective dans l’exemple ci-dessus est RemoteSigned.¹ Set-ExecutionPolicy écrit par défaut dans la portée LocalMachine, ce qui nécessite des droits d’administrateur, mais à la portée CurrentUser, même un utilisateur standard peut la modifier.³

Et l’outil incontournable pour la gestion à l’échelle de l’organisation est la Stratégie de groupe. Le réglage « Activer l’exécution de scripts » (Turn on Script Execution) prime sur toutes les portées définies côté PowerShell. Le désactiver équivaut à Restricted ; l’activer permet de choisir entre « Autoriser tous les scripts » (Unrestricted), « Autoriser les scripts locaux et les scripts distants signés » (RemoteSigned) et « Autoriser uniquement les scripts signés » (AllSigned), et ce réglage se trouve sous le modèle d’administration Composants Windows\Windows PowerShell. La Configuration ordinateur prime sur la Configuration utilisateur.¹ Dans un environnement géré par GPO, Set-ExecutionPolicy enregistre bien le réglage, mais celui-ci ne prend pas effet, et un message explicatif du conflit s’affiche.³

Il y a ici une conséquence importante. Si la GPO gère la politique, un -ExecutionPolicy Bypass inscrit dans une tâche ou un raccourci n’a aucun effet. Il est explicitement documenté qu’une spécification à la portée Process l’emporte sur la configuration LocalMachine/CurrentUser, mais ne peut pas l’emporter sur la Stratégie de groupe.¹ Dit autrement, « il suffit d’écrire Bypass pour que ça marche » n’est vrai que dans les environnements où l’organisation ne gère pas du tout la politique d’exécution.

4. Zone.Identifier (Mark of the Web) et Unblock-File

La notion de « distant (provenant d’Internet) » de RemoteSigned n’est pas déterminée par l’emplacement du fichier, mais par une marque apposée sur le fichier. Des programmes comme les navigateurs attachent un flux de données alternatif à un fichier qu’ils téléchargent, le marquant comme « un fichier provenant d’Internet ».¹ Ce flux, c’est Zone.Identifier, qui porte la valeur 3, indiquant la zone Internet. C’est le fameux Mark of the Web.⁴

Essayez d’exécuter un script non signé portant cette marque dans un environnement RemoteSigned, et il est bloqué avec une erreur « non signé numériquement ». La solution se déroule en deux étapes.

# 1) Vérifiez d'abord quels fichiers sont bloqués (opération sûre, en lecture seule)
Get-Item -Path C:\Tools\*.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue

# 2) Ne débloquez que les fichiers dont vous avez examiné le contenu et jugé qu'il était sûr
#    (Unblock-File supprime le flux Zone.Identifier ; la politique d'exécution elle-même ne change pas)
Unblock-File -Path C:\Tools\Get-InventoryReport.ps1

Unblock-File est l’applet de commande qui supprime le flux de données alternatif Zone.Identifier, et c’est la même opération que la case « Débloquer » dans les propriétés du fichier dans l’Explorateur de fichiers. Le point clé est que cela permet de ne laisser passer que les fichiers examinés, sans jamais assouplir la politique d’exécution.⁴ La documentation officielle présente également « vérifier le fichier et sa provenance, et confirmer qu’il est sûr avant de l’utiliser » comme une étape obligatoire.⁴³

Il vaut aussi la peine de connaître le piège en sens inverse. Tous les canaux d’obtention n’apposent pas le Mark of the Web. Il est explicitement documenté que les fichiers téléchargés avec curl.exe, Invoke-WebRequest ou Invoke-RestMethod peuvent ne pas recevoir la marque de la zone Internet.¹ Autrement dit, RemoteSigned n’est pas une garantie que « tout fichier téléchargé dangereux sera arrêté » — c’est justement pour cela qu’il s’agit d’un dispositif de sécurité et non d’une frontière de sécurité. Il existe aussi une mise en garde selon laquelle, sur des systèmes configurés pour ne pas distinguer les chemins UNC des chemins Internet, un script placé sur un dossier partagé peut se voir refuser l’exécution sous RemoteSigned.¹ Si des fichiers .ps1 placés sur un partage cessent de fonctionner sur seulement certains postes, soupçonnez la configuration de zone et la présence ou non de Zone.Identifier.

Le mécanisme SmartScreen, qui provoque un symptôme similaire du côté des fichiers exécutables (.exe) téléchargés, est traité dans Pourquoi Windows affiche « Windows a protégé votre PC ».

5. La pratique de la signature de scripts — Set-AuthenticodeSignature et l’horodatage

Passer à une exploitation AllSigned, ou signer les fichiers distribués dans un environnement RemoteSigned, nécessite un certificat de signature de code. On peut classer son obtention en trois voies.⁵

La documentation officielle présente les choses de la même façon : « un certificat émis par une autorité de certification est également approuvé sur d’autres ordinateurs », alors qu’« un certificat auto-créé est gratuit mais spécifique à votre propre ordinateur, et doit être limité à des fins de test ».⁵ Si l’objectif est une distribution interne, il est réaliste d’émettre un certificat de signature de code depuis une AC interne telle qu’Active Directory Certificate Services.

Vérifions d’abord le déroulement avec un certificat auto-signé de test.

# Créer un certificat de signature de code de test (auto-signé — approuvé uniquement sur ce poste)
$params = @{
    Subject           = 'CN=KomuraSoft Code Signing (Test)'
    Type              = 'CodeSigningCert'
    CertStoreLocation = 'Cert:\CurrentUser\My'
    HashAlgorithm     = 'sha256'
}
$cert = New-SelfSignedCertificate @params

New-SelfSignedCertificate est l’applet de commande qui crée un certificat auto-signé à des fins de test ; spécifier -Type CodeSigningCert ajoute l’extension de signature de code. La durée de validité par défaut est d’un an.⁷ Si vous voulez utiliser un certificat auto-signé pour tester un environnement AllSigned, il doit être enregistré dans le magasin des autorités de certification racines de confiance de ce poste.⁵

En production, la signature elle-même tient en une ligne.

# Récupérer le certificat de signature de code dans le magasin de certificats et signer avec
# -CodeSigningCert se contente de filtrer sur les « certificats utilisables pour la signature de code »,
# il faut donc aussi se limiter à ceux qui possèdent une clé privée et sont encore dans leur période
# de validité, et dans un environnement où plusieurs correspondent, les identifier par Subject ou Thumbprint
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert |
    Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) -and
                   $_.Subject -eq 'CN=KomuraSoft Code Signing (Test)' } |
    Sort-Object NotAfter -Descending |
    Select-Object -First 1   # Si le renouvellement laisse plusieurs certificats avec le même Subject, ne garder que celui dont l'expiration est la plus lointaine

# L'horodatage est obligatoire. Il permet à la signature de rester valide même après l'expiration du certificat
# Remplacez l'URL par le service d'horodatage indiqué par l'émetteur de votre certificat (AC interne / fournisseur)
Set-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1 -Certificate $cert `
    -HashAlgorithm SHA256 -TimestampServer 'http://timestamp.example.com'

# L'état de la signature peut être vérifié avec Get-AuthenticodeSignature (Valid/NotSigned/HashMismatch, etc.)
Get-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1

Trois points précis méritent d’être retenus.⁶⁵

• La signature est intégrée sous forme d’un bloc de commentaires # SIG # en fin de fichier. Toute signature existante est remplacée. Cela signifie que modifier ne serait-ce qu’un seul caractère du script après la signature invalide celle-ci — c’est exactement ce qui en fait un mécanisme de détection d’altération.
• Spécifier -TimestampServer fait que le script cesse d’échouer une fois le certificat expiré. Une signature reste valide soit « tant que le certificat de signature lui-même est valide », soit « tant que le serveur d’horodatage peut vérifier qu’elle a été apposée alors que le certificat était valide » ; comme la plupart des certificats de signature de code ont une durée de validité d’un an, l’horodatage est la bouée de sauvetage pour une exploitation de longue durée.⁶⁵ Suivez les indications de l’émetteur de votre certificat (l’AC) pour savoir quelle URL de service d’horodatage utiliser.
• Un script signé sous Windows PowerShell 5.1, ou sous une version de PowerShell antérieure à 7.2, devait être enregistré en ASCII ou en UTF8NoBOM. PowerShell 7.2 et les versions ultérieures prennent en charge les scripts signés dans n’importe quel encodage.⁵ Sur les postes où la 5.1 subsiste encore, ce point est une source fréquente d’incidents où la vérification de la signature échoue à cause de l’encodage d’un script contenant des commentaires en japonais — soyez vigilant. Pour l’ensemble des différences entre la 5.1 et la 7, ainsi que la migration, consultez « Différences entre Windows PowerShell 5.1 et PowerShell 7, et migration ».

Dans un environnement AllSigned, si un script est signé mais que son éditeur n’a pas encore été classé comme fiable ou refusé, une invite apparaît à l’exécution demandant « Voulez-vous exécuter un logiciel provenant de cet éditeur non approuvé ? ». Choisir « Toujours exécuter » évite qu’on vous repose la question pour cet éditeur.¹⁵ Dans une exploitation à base d’AC interne, distribuer également le certificat d’éditeur dans le magasin « Éditeurs de confiance » de chaque poste permet de supprimer cette confirmation de l’exploitation courante.

6. Bonnes pratiques (tableau de décision) — de « colmater avec Bypass » à une exploitation basée sur la signature

Le pilotage de la distribution et de l’exécution des scripts internes se pense de façon standard à l’aide du tableau de décision suivant.

Une précision sur la dernière ligne. Le problème d’une exploitation qui « colmate avec ExecutionPolicy Bypass » n’est pas d’ouvrir une faille de sécurité en tant que telle (puisque la politique d’exécution n’a jamais été une frontière). Le problème tient à trois points.

• L’abandon du dispositif de sécurité — vous retirez de façon permanente le dernier filet qui rattrape l’accident consistant à exécuter le mauvais script par erreur, ou à exécuter sans s’en rendre compte un script qui a été altéré.
• La dérive par rapport à la gouvernance — au moment où la GPO commence à gérer la politique d’exécution, la spécification Bypass cesse de fonctionner, et toutes les tâches qui colmataient le problème échouent d’un coup.¹ C’est une dette technique où « la raison pour laquelle ça fonctionnait » se révèle avoir été une brèche non maîtrisée.
• Le brouillage des enquêtes de cause racine — une fois Bypass disséminé un peu partout, il devient impossible de déduire le comportement à partir de la politique effective de l’environnement, ce qui complique fortement l’investigation des différences d’un poste à l’autre (pourquoi seul ce poste échoue-t-il).

Bypass lui-même est un réglage prévu pour des configurations où une application bâtie sur PowerShell exerce son propre contrôle via son propre modèle de sécurité.¹ Il faut accepter qu’il n’est pas destiné à être utilisé de façon habituelle comme option de lancement pour des scripts opérationnels écrits par des humains. La mise en place d’une exécution planifiée sûre et fiable dans le Planificateur de tâches est traitée en détail dans « Les tâches du Planificateur de tâches qui ne s’exécutent pas ou se terminent en 0x1 — isoler la cause et concevoir une exploitation fiable ».

7. Résumé

• La politique d’exécution est un dispositif de sécurité, pas une frontière de sécurité. Traitez la lutte contre les attaques dans une autre couche, et confiez à la politique d’exécution le rôle de « prévenir les erreurs accidentelles ».
• La politique comporte cinq portées, avec l’ordre de priorité MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine. Commencez toute investigation par Get-ExecutionPolicy -List.
• Ce que RemoteSigned examine, c’est Zone.Identifier (le Mark of the Web). Laissez passer les fichiers examinés avec Unblock-File, sans assouplir la politique.
• Signez avec Set-AuthenticodeSignature, et spécifiez toujours -TimestampServer. Pour la distribution interne, utilisez un certificat émis par une AC interne ; l’auto-signé est réservé aux tests.
• Centralisez la gouvernance de l’organisation via le réglage « Activer l’exécution de scripts » de la Stratégie de groupe. Ce réglage prime sur toutes les portées et sur toute spécification -ExecutionPolicy.
• L’usage systématique de -ExecutionPolicy Bypass abandonne le dispositif de sécurité, et de toute façon cela n’a aucun effet sous gestion par GPO. La bonne voie consiste à rendre le « colmatage » inutile en mettant correctement en place la politique de l’environnement et une exploitation de signature.

Articles connexes

• Les bases des commandes PowerShell — les opérations à apprendre en premier et comment les utiliser en toute sécurité
• Pourquoi Windows affiche « Windows a protégé votre PC »
• Les tâches du Planificateur de tâches qui ne s’exécutent pas ou se terminent en 0x1 — isoler la cause et concevoir une exploitation fiable
• Conception de la gestion des erreurs et des nouvelles tentatives pour les scripts PowerShell
• Différences entre Windows PowerShell 5.1 et PowerShell 7, et migration
• Décider de migrer d’un fichier batch vers PowerShell

Domaines de conseil associés

Komura Software LLC prend en charge la conception de la politique d’exécution et de l’exploitation de signature pour les scripts PowerShell internes, l’étude d’un déploiement via la Stratégie de groupe, ainsi que l’investigation de différences d’environnement du type « ce script ne fonctionne que sur certains postes ». Nous pouvons également accompagner la bascule d’actifs existants (fichiers batch, scripts) vers une exploitation plus sûre.

• Conseil technique et revue de conception
• Investigation de bugs et analyse des causes profondes
• Modernisation et maintenance des applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

La politique d'exécution de PowerShell est-elle une fonctionnalité de sécurité ?

La documentation officielle affirme sans détour que « la politique d'exécution n'est pas un système de sécurité qui restreint les actions de l'utilisateur ». En effet, elle peut être contournée trivialement en collant simplement le contenu d'un script dans la ligne de commande. Le but de la politique d'exécution est de fixer des règles de base et de servir de dispositif de sécurité qui empêche l'accident consistant à « exécuter par inadvertance un script que l'on ne voulait pas exécuter » — il ne faut surtout pas la concevoir comme une frontière de sécurité destinée à arrêter un attaquant. La lutte contre les attaques relève d'une autre couche (contrôle des applications, principe du moindre privilège, etc.).

Quelle est la différence entre RemoteSigned et AllSigned ?

RemoteSigned n'exige la signature d'un éditeur de confiance que pour les scripts provenant d'Internet (porteurs du Mark of the Web) ; les scripts créés localement peuvent s'exécuter sans signature. AllSigned exige une signature sur tous les scripts et fichiers de configuration, y compris ceux créés localement, et demande une confirmation avant d'exécuter quoi que ce soit provenant d'un éditeur qu'il n'a pas encore classé. AllSigned est le choix réaliste si votre organisation peut mettre en place une exploitation de signature (distribution de certificats de signature de code et procédure de signature) ; RemoteSigned est réaliste si vous ne disposez pas d'une telle organisation.

Pourquoi un script téléchargé refuse-t-il de s'exécuter avec une erreur « non signé numériquement » ?

Les fichiers téléchargés via un navigateur ou un outil similaire reçoivent un flux de données alternatif appelé Zone.Identifier, qui les marque comme « un fichier provenant d'Internet ». Si votre politique d'exécution est RemoteSigned, un script non signé portant cette marque voit son exécution bloquée. Une fois que vous avez examiné le contenu et jugé qu'il était sûr, vous pouvez supprimer le flux Zone.Identifier avec l'applet de commande Unblock-File, ou via la case « Débloquer » dans les propriétés du fichier dans l'Explorateur de fichiers, et l'exécuter sans jamais modifier votre politique d'exécution.

Comment gérer de façon réaliste des scripts PowerShell distribués en interne ?

Il existe globalement deux options. La première est RemoteSigned associé au dépôt des scripts sur un serveur de fichiers, ce qui permet de démarrer sans mettre en place d'organisation de signature, mais selon le canal de distribution, le Mark of the Web peut se retrouver ajouté et bloquer l'exécution, et cette approche ne permet pas non plus de détecter une altération d'un script. La seconde est AllSigned associé à une exploitation de signature : on signe les scripts avec Set-AuthenticodeSignature à l'aide d'un certificat de signature de code (réalistiquement, un certificat émis par une AC interne), et l'on gère la politique de façon centralisée via la Stratégie de groupe. En échange du contrôle sur la politique d'exécution et de la capacité à détecter les altérations, on assume le coût opérationnel de la distribution et du renouvellement des certificats.

Peut-on continuer à spécifier -ExecutionPolicy Bypass dans le Planificateur de tâches ?

Cela fonctionnera, mais ce n'est pas recommandé. D'abord, dans un environnement où la politique d'exécution est gérée par la Stratégie de groupe, une spécification ExecutionPolicy en ligne de commande ne peut pas l'emporter sur la Stratégie de groupe, donc elle n'a même pas d'effet. Ensuite, l'usage systématique de Bypass revient à retirer soi-même le dispositif de sécurité destiné à empêcher une exécution accidentelle, et cela devient une cause d'écart croissant entre la politique de l'organisation et la réalité du terrain. Si vous voulez que cela devienne une pratique pérenne, l'approche correcte consiste à configurer correctement la politique de l'environnement via la Stratégie de groupe ou un Set-ExecutionPolicy exécuté par un administrateur, et à faire en sorte que les scripts démontrent leur confiance par la signature.

Pourquoi la signature de scripts nécessite-t-elle un horodatage (-TimestampServer) ?

La validité d'une signature est en principe liée à la date d'expiration du certificat de signature, mais avec un horodatage, le serveur d'horodatage atteste du fait que « ceci a été signé alors que le certificat était encore valide », ce qui permet de continuer à utiliser le script même après l'expiration du certificat. La plupart des certificats de signature de code ont une durée de validité d'environ un an, donc exploiter sans horodatage revient à porter, chaque année, le risque qu'« un beau jour, sans prévenir, tous les scripts signés de l'entreprise cessent de fonctionner d'un coup ». Spécifiez toujours -TimestampServer lors de la signature.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.