Sécurité des scripts

 

Sapplique à :Exchange Server 2013

La sécurité des scripts dans l'environnement de ligne de commandeExchange Management Shell aide à lutter contre l'exécution de scripts nuisibles ou indésirables dans votre organisation. Vous disposez de différentes options pour modifier la sécurité des scripts afin de l'adapter aux besoins de votre organisation.

Vous rencontrez normalement des scripts de différentes sources : vous-même, une autre personne de votre organisation et des rédacteurs de script extérieurs à votre organisation, par exemple en provenance d'Internet. Si vous écrivez un script, vous l'approuvez pour qu'il fasse ce pour quoi il est conçu. Si vous partagez le script avec d'autres administrateurs au sein de votre organisation, ces derniers approuvent également le script mais uniquement parce qu'ils vous approuvent.

Lorsque les scripts proviennent d'autres sources, telles qu'Internet, leur sécurité est un souci. La seule manière de pouvoir approuver des scripts de sources inconnues de votre organisation consiste à examiner leur code directement et à les tester dans un environnement expérimental isolé. Bien que ce processus soit long et fastidieux, il est recommandé d'éviter toute exécution involontaire de code nuisible ou destructeur.

L'environnement de ligne de commande Exchange Management Shell prend en charge l'utilisation recommandée de signatures numériques pour vous assurer qu'un script n'est pas endommagé après sa création. Pour plus d'informations sur les signatures numériques, consultez la section « ABC de la signature de code » plus loin dans cette rubrique.

Quatre modes d'exécution de script dans l'environnement de ligne de commande Exchange Management Shell contrôlent la manière dont les scripts sont utilisés, en fonction de la manière dont ils sont signés et selon qu'ils proviennent de sources connues ou non. Le tableau suivant décrit chaque mode d'exécution de script.

ImportantImportant :
L'environnement de ligne de commande Exchange Management Shell distant exige que le mode d'exécution de script soit défini sur RemotedSigned ou Unrestricted. Pour plus d’informations sur l’environnement de ligne de commande Exchange Management Shell distant, voir Utilisation de PowerShell avec Exchange 2013 (Exchange Management Shell).

Modes d'exécution de script

Mode Description

Mode Restricted

Aucun script, même signé par un éditeur approuvé, n'est exécuté. Il s'agit du mode d'exécution de script par défaut.

Mode AllSigned

Tous les scripts doivent porter la signature numérique d'un éditeur approuvé avant leur exécution.

Mode RemoteSigned

Tous les scripts créés localement s'exécutent. Les scripts téléchargés à partir d'emplacements distants, tels qu'Internet, dont l'approbation est impossible, ne s'exécutent pas.

Mode Unrestricted

Tous les scripts, qu'ils portent une signature numérique ou qu'ils soient approuvés, s'exécutent. Le mode Unrestricted n'est pas recommandé, à moins que vous n'exécutiez le script dans un environnement de test contrôlé et non pas dans un environnement de production.

Pour définir un mode d'exécution de script différent du mode Restricted par défaut, utilisez la cmdlet Set-ExecutionPolicy dans l'environnement de ligne de commande Exchange Management Shell. Cet exemple modifie la stratégie d'exécution en mode RemotedSigned.

Set-ExecutionPolicy RemotedSigned

L'environnement de ligne de commande Exchange Management Shell reconnaît la modification de la stratégie immédiatement.

RemarqueRemarque :
Si le contrôle d'accès des utilisateurs est activé, vous devez ouvrir l'environnement de ligne de commande Exchange Management Shell avec des autorisations élevées pour définir la stratégie d'exécution. Pour ouvrir l'environnement de ligne de commande Exchange Management Shell avec des autorisations élevées, cliquez avec le bouton droit sur l'icône Environnement de ligne de commande Exchange Management Shell et sélectionnez Exécuter en tant qu'administrateur.

Les organisations de grande taille qui souhaitent définir un mode d'exécution de script cohérent pour tous les ordinateurs exécutant l'environnement de ligne de commande Exchange Management Shell doivent appliquer le paramètre de mode d'exécution du script à l'aide d'une stratégie de groupe Active Directory. Vous configurez la stratégie de groupe Active Directory pour définir la valeur ExecutionPolicy, située sous la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell, sur le mode d'exécution de script de votre choix.

AttentionAttention :
Une modification incorrecte du Registre peut être à l’origine de problèmes graves qui vous obligeront peut-être à réinstaller votre système d’exploitation. Il se peut que les problèmes résultant d’une modification incorrecte du Registre soient impossibles à résoudre. Avant de modifier le Registre, sauvegardez les données importantes.

Les signatures numériques sont créées à l'aide d'un algorithme de clé publique utilisant deux clés cryptographiques différentes appelées paire de clés : la clé publique et la clé privée. La clé privée n'est connue que du propriétaire, tandis que la clé publique est connue de tous. Dans les signatures numériques, la clé privée génère la signature et la clé publique correspondante la valide.

Un certificat est un document numérique généralement utilisé pour l'authentification et pour aider à sécuriser des informations sur des réseaux ouverts. Un certificat lie de façon sécurisée une clé publique à l'entité contenant la clé privée correspondante. Les certificats sont signés de façon numérique par l'autorité de certification qui les émet. En utilisant un certificat de signature de code, l'auteur du script ajoute une signature numérique au fichier de script. Durant ce processus, un hachage unidirectionnel du script est créé et chiffré à l'aide de la clé privée. Le hachage chiffré est une chaîne de signature numérique ajoutée au fichier de script. La chaîne de signature numérique est annulée, de façon à ce qu'elle n'interfère pas avec la fonctionnalité du script.

Lors de l'exécution de ce script dans l'environnement de ligne de commande Exchange Management Shell où une signature du code est requise, un nouveau hachage unidirectionnel du fichier de script est effectué. Le hachage unidirectionnel est comparé au hachage chiffré inclus dans le fichier de script après son déchiffrage à l'aide de la clé publique. Si le script n'a pas été modifié après sa signature, les hachages correspondent. L'ordinateur essaie ensuite de vérifier que la signature provient d'un éditeur approuvé en créant une chaîne de certificat auprès d'une autorité de certification approuvée. Si l'approbation est vérifiée, le script s'exécute.

Le fait qu'un script provient d'une source approuvée dépend de l'origine du certificat de signature de code utilisé pour signer le script de façon numérique. Il existe généralement deux types de certificats :

  • Certificats émis par une autorité de certification approuvée   L'autorité de certification vérifie l'identité du demandeur avant d'émettre un certificat de signature de code. L'autorité émettrice peut être une tierce partie publique externe qui vend des certificats ou une autorité de certification interne hébergée par votre organisation. Si vous signez un script à l'aide de ce type de certificat, vous pouvez partager le script avec des utilisateurs d'autres ordinateurs qui reconnaissant et approuvent l'autorité de certification ayant émis le certificat.

  • Certificats auto-signés   Pour ce type de certificat, votre ordinateur est l'autorité qui crée le certificat. L'avantage d'un certificat auto-signé est qu'il vous permet d'écrire, de signer et d'exécuter des scripts sur votre ordinateur. Vous ne pouvez cependant pas partager votre script pour l'exécuter sur d'autres ordinateurs, car votre ordinateur n'est pas reconnu comme autorité de certification approuvée. Si votre ordinateur n'est pas approuvé, votre signature auto-signée ne peut pas être validée et le script ne s'exécute pas.

L'environnement de ligne de commande Exchange Management Shell inclut deux cmdlets pour la gestion de la signature de code. La cmdlet Set-AuthenticodeSignature permet d'ajouter des signatures numériques à des fichiers de script. La cmdlet Set-AuthenticodeSignature prend le nom du fichier à signer comme premier paramètre de type positionnel. Si le fichier ne se trouve pas dans le répertoire de travail en cours, vous devez spécifier le chemin d'accès au fichier. Le second paramètre d'entrée pour cette cmdlet est le certificat utilisé pour la signature. Ce certificat est stocké dans la banque d'informations de certificats locale. Vous devez fournir ce paramètre sous la forme d'une chaîne faisant référence au certificat. Le certificat est accessible via le lecteur de certificats M:

L'autre cmdlet pour la gestion de la signature de code est la cmdlet Get-AuthenticodeSignature . Utilisez la cmdlet Get-AuthenticodeSignature pour vérifier et confirmer l'état de signature du code actuel pour le fichier fourni comme entrée de paramètre. Si un problème survient lors de l'utilisation d'un script au code signé, la sortie de la cmdlet Get-AuthenticodeSignature fournit des informations de dépannage utiles.

Si vous voulez exécuter des scripts à partir de sources externes, par exemple Microsoft, vous devez les adapter au mode d'exécution de script de votre environnement. Vous pouvez recevoir des scripts sous la forme de fichiers .txt simples, les renommer comme fichiers de script .ps1, puis, après avoir appliqué une signature obligatoire, les exécuter comme si vous les aviez écrits vous-même.

Pour plus d'informations sur la signature numérique et les stratégies d'exécution de script, dans l'environnement de ligne de commande Exchange Management Shell, exécutez la commande suivante : Get-Help About_Signing. Cette commande renvoie des informations qui incluent des instructions détaillées sur la signature numérique des scripts.

 
Afficher: