Sécurité de script

 

S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Dernière rubrique modifiée : 2007-02-12

Cette rubrique décrit comment la sécurité de script de l'environnement de ligne de commande Exchange Management Shell permet d'empêcher l'exécution de scripts nuisibles ou indésirables dans votre organisation ainsi que les options disponibles pour modifier la sécurité de script afin de répondre aux exigences 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é. Ce processus peut être long et fastidieux. Il est néanmoins 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.

Modes d'exécution de script

Quatre modes d'exécution de script sont possibles pour permettre à l'environnement de ligne de commande Exchange Management Shell de contrôler la manière sont 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.

Modes d'exécution de script

Mode Description

Mode Restricted

Aucun script, même signé par un éditeur approuvé, n'est exécuté.

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. Il s'agit du mode d'exécution de script par défaut.

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 exécutiez le script dans un environnement de test sans production contrôlé.

Pour définir un mode d'exécution de script différent du mode par défaut RemoteSigned, utilisez la cmdlet Set-ExecutionPolicy dans l'environnement de ligne de commande Exchange Management Shell. Par exemple, pour modifier la stratégie d'exécution en mode AllSigned, exécutez la commande suivante :

Set-ExecutionPolicy AllSigned

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

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 appliquent le paramètre de mode d'exécution du script à l'aide d'une stratégie de groupe Active Directory. Vous pouvez configurer la stratégie de groupe Active Directory pour définir la valeur ExecutionPolicy sous la clé de Registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell sur le mode d'exécution de script souhaité.

CautionAttention :
UNRESOLVED_TOKEN_VAL(exRegistry)

ABC de la signature de code

Les signatures numériques sont créés à 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 est celle 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 proviennent 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 :

  • Les certificats utilisés 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 pour l'exécuter d'autres ordinateurs parce qu'ils ne reconnaissent pas l'ordinateur comme autorité de certification. S'ils n'approuvent pas votre ordinateur, ils ne peuvent pas valider votre signature auto-signée et le script ne s'exécute pas.

Cmdlets pour la gestion de la signature de code

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 du 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 Cert: M:

La deuxième cmdlet pour la gestion de la signature est la cmdlet Get-AuthenticodeSignature . La cmdlet Get-AuthenticodeSignature permet de vérifier l'état de signature du code pour actuel du 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 de base, les renommer comme fichiers de script .ps1, puis, après avoir appliqué une signature obligatoire, les exécuter comme 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 d'aide incluant des instructions détaillées sur la signature numérique des scripts.