Fonctionnalités de sécurité PowerShell

PowerShell offre plusieurs fonctionnalités conçues pour améliorer la sécurité de votre environnement de script.

Stratégie d’exécution

La stratégie d’exécution de PowerShell est une fonctionnalité de sécurité qui contrôle les conditions dans lesquelles PowerShell charge les fichiers de configuration et exécute des scripts. Cette fonctionnalité permet d’éviter l’exécution de scripts malveillants. Vous pouvez également utiliser un paramètre de stratégie de groupe afin de définir des stratégies d’exécution pour les ordinateurs et les utilisateurs. Les stratégies d’exécution s’appliquent uniquement à la plateforme Windows.

Pour plus d'informations, voir about_Execution_Policies.

Utilisation de la classe SecureString

PowerShell a plusieurs applets de commande qui prennent en charge l’utilisation de la classe System.Security.SecureString. Et, comme avec n’importe quelle classe .NET, vous pouvez utiliser SecureString dans vos propres scripts. Toutefois, Microsoft ne recommande pas l’utilisation de SecureString pour les nouveaux développements. Microsoft recommande d’éviter d’utiliser des mots de passe et de s’appuyer sur d’autres moyens pour s’authentifier, comme les certificats ou l’authentification Windows.

PowerShell continue de prendre en charge la classe SecureString pour la compatibilité descendante. L’utilisation d’un SecureString est encore plus sécurisée que l’utilisation d’une chaîne de texte brut. PowerShell s’appuie toujours sur le type SecureString pour éviter d’exposer accidentellement le contenu à la console ou dans les journaux. Utilisez SecureString avec soin, car il peut être facilement converti en chaîne de texte brut. Pour une discussion complète sur l’utilisation de SecureString, consultez la documentation de la classe System.Security.SecureString.

Journalisation des modules et des blocs de script

La journalisation de module vous permet d’activer la journalisation des modules PowerShell sélectionnés. Ce paramètre est effectif dans toutes les sessions sur l’ordinateur. PowerShell enregistre les événements d’exécution de pipeline pour les modules spécifiés dans le journal des événements Windows PowerShell.

La journalisation des blocs de script active la journalisation du traitement des commandes, des blocs de script, des fonctions et des scripts, qu’elle soit appelée de manière interactive ou par l’automatisation. PowerShell enregistre ces informations dans le journal des événements Microsoft-Windows-PowerShell/Operational.

Pour plus d’informations, consultez les articles suivants :

• à_propos_des_paramètres_de_stratégie_de_groupe
• À propos de la journalisation sous Windows
• À propos de la journalisation pour les non-Windows

Support AMSI

Windows Antimalware Scan Interface (AMSI) est une API qui permet aux applications de transférer des actions à un détecteur de programme malveillant, tel que Windows Defender, pour détecter les charges utiles malveillantes. À partir de PowerShell 5.1, PowerShell s’exécutant sur Windows 10 (et versions ultérieures) transmet tous les blocs de script à AMSI.

PowerShell 7.3 étend les données qu’il envoie à AMSI pour inspection. Il inclut désormais tous les appels de méthode .NET.

Pour plus d’informations sur AMSI, consultez Comment AMSI aide.

Mode de langage contraint

Le mode ConstrainedLanguage protège votre système en limitant les applets de commande et les types .NET autorisés dans une session PowerShell. Pour obtenir une description complète, consultez about_Language_Modes.

Contrôle d'application

Windows 10 inclut deux technologies, App Control for Business et AppLocker que vous pouvez utiliser pour contrôler les applications. PowerShell détecte si une stratégie de contrôle d’application à l’échelle du système est appliquée. La stratégie applique certains comportements lors de l’exécution de blocs de script, de fichiers de script ou de chargement de fichiers de module pour empêcher l’exécution de code arbitraire sur le système.

App Control for Business est conçu comme une fonctionnalité de sécurité sous les critères de maintenance définis par microsoft Security Response Center (MSRC). Le contrôle d’application est le système de contrôle d’application préféré pour Windows.

Pour plus d’informations sur la façon dont PowerShell prend en charge AppLocker et App Control, consultez Utiliser App Control pour sécuriser PowerShell.

Nomenclature logicielle (SBOM)

À partir de PowerShell 7.2, tous les packages d’installation contiennent une nomenclature logicielle (SBOM). L’équipe PowerShell produit également des nomenclatures logicielles pour les modules qu’elle détient, mais celles-ci sont livrées indépendamment de PowerShell.

Vous trouverez ces fichiers de nomenclature aux emplacements suivants :

• Dans PowerShell, vous trouverez la nomenclature logicielle à l’adresse $PSHOME/_manifest/spdx_2.2/manifest.spdx.json.
• Pour les modules, vous trouverez la nomenclature logicielle dans le dossier du module, sous _manifest/spdx_2.2/manifest.spdx.json.

La création et la publication de la nomenclature logicielle sont les premières étapes permettant de moderniser la cybersécurité du gouvernement fédéral et d’améliorer la sécurité de la chaîne d’approvisionnement des logiciels. Pour plus d’informations sur cette initiative, consultez le billet de blog Generating SBOMs with SPDX at Microsoft.

Transfert de données sécurisé dans PowerShell à distance

Avant PowerShell v7.6-preview5, un Session_Key est utilisé pour chiffrer un SecureString avant de l'envoyer à une session PowerShell à distance. Le protocole PSRP (PowerShell Remoting Protocol) effectue un échange de clés entre le client et le serveur lorsqu’un SecureString objet doit être transféré. L’échange implique les étapes suivantes :

1. Le côté client génère une paire de clés publique/privée et envoie la clé publique au serveur.
2. Le serveur génère une clé de session pour le chiffrement symétrique.
3. Le serveur utilise la clé publique pour chiffrer la clé de session et l’envoie au client.
4. Le client et le serveur utilisent la nouvelle clé de session pour chiffrer un objet SecureString .

Le protocole PSRP (PowerShell Remoting Protocol) utilise l’algorithme RSAEncryptionPadding.Pkcs1 pendant l’échange de clés. L’algorithme n’est pas sécurisé, de sorte que l’échange de clés ne fournit aucune sécurité supplémentaire.

À compter de PowerShell v7.6-preview.5, l’échange de clés a été déconseillé. La version de PSRP a été incrémentée vers la version 2.4 et inclut les modifications suivantes :

• Les messages PSRP suivants sont déconseillés lorsque le client et le serveur sont v2.4 ou ultérieur :

  • PUBLIC_KEY
  • REQUÊTE_CLÉ_PUBLIQUE
  • CLÉ_DE_SESSION_CRYPTÉE

• Les étapes de chiffrement et de déchiffrement sont ignorées SecureString lorsque le client et le serveur sont de version 2.4 ou supérieure.

Cette modification est rétrocompatible.

• Pour les anciens clients ou serveurs (v2.3 ou inférieur), l’échange de clés est toujours utilisé si nécessaire.
• PSRP peut utiliser des sessions distantes via un canal nommé lorsque le client et le serveur se trouvent sur la même machine. Étant donné qu’il est possible pour un client distant de se connecter à un canal nommé et que les données ne sont plus chiffrées avec une clé de session, le canal nommé (utilisé pour Enter-PSHostProcess) rejette le client distant.

Critères de maintenance de la sécurité

PowerShell suit les critères de maintenance de la sécurité de Microsoft pour Windows. Seules les fonctionnalités de sécurité répondent aux critères de maintenance.

Fonctionnalités de sécurité

• Verrouillage du système avec contrôle d’application pour les entreprises
• Mode de langage contraint avec App Control for Business

Fonctionnalités de défense en profondeur

• Verrouillage du système avec AppLocker
• Mode de langage contraint avec AppLocker
• Stratégie d’exécution