Sécurité

Name: PowerShell Core et Windows PowerShell Les fondamentaux du langage (2e édition)
Rating: 5 (4 reviews)

La sécurité : pour qui ? Pourquoi ?

L’arrivée des réseaux locaux et d’Internet a changé beaucoup de choses dans la manière de protéger son PC. Il ne suffit plus d’attacher son disque dur au radiateur et de fermer la porte du bureau le soir pour ne pas se faire voler ou pirater des données. Maintenant, protéger son poste de travail est devenu essentiel pour ne pas faire les frais d’intrusions ou de malveillances.

Mais alors contre qui se prémunir ? Eh bien, contre tout ce qui bouge… et même ce qui ne bouge pas. En effet, que ce soient des programmes malveillants, des utilisateurs mal intentionnés, voire des utilisateurs inexpérimentés, tous peuvent être considérés comme une menace. C’est pour cela que vous devez verrouiller votre système en établissant des règles de sécurité, en les appliquant et en vous assurant que les autres en font tout autant.

Les risques liés au scripting

Vous allez vite deviner que ce qui fait la force du scripting en fait aussi sa faiblesse. La facilité avec laquelle vous pouvez tout faire, soit en cliquant sur un script, soit en l’exécutant depuis la fenêtre de commande, peut vous mettre dans l’embarras si vous ne faites pas attention.

Imaginez un script de logon qui dès l’ouverture de la session la verrouille aussitôt ! Alors oui, c’est sympa entre copains, mais en entreprise, nous doutons que cela soit de bon ton. Plus grave encore, un script provenant d’une personne mal intentionnée ou vraiment peu expérimentée en PowerShell (dans ce cas, nous vous conseillons de lui acheter un exemplaire de ce livre…) peut parfaitement vous bloquer des comptes utilisateurs dans Active Directory, vous formater un disque, vous faire rebooter sans cesse. Vous l’avez compris, un script peut tout faire. Car même si aujourd’hui des alertes sont remontées jusqu’à l’utilisateur pour le prévenir de l’exécution d’un script, elles ne sont pas capables de déterminer à l’avance si un script est nuisible au bon fonctionnement du système.

Les risques liés au scripting se résument à une histoire de compromis : soit vous empêchez toute exécution de scripts, c’est-à-dire encourir le risque...

Optimiser la sécurité PowerShell

1. La sécurité PowerShell par défaut

Vous l’avez compris, la sécurité est une chose très importante, surtout dans le domaine du scripting. C’est pour cela que les créateurs de PowerShell ont inclus deux règles de sécurité par défaut.

Des fichiers ps1 associés au bloc-notes

L’extension « .ps1 » des scripts PowerShell, est par défaut associée à l’éditeur de texte bloc-notes (ou Notepad). Ce procédé permet d’éviter de lancer des scripts potentiellement dangereux sur une mauvaise manipulation. Le bloc-notes est certes un éditeur un peu classique, mais il a le double avantage d’être inoffensif et de ne pas bloquer l’exécution d’un script lorsque celui-ci est ouvert avec l’éditeur. Vous remarquerez cependant que l’édition (clic droit + Modifier) des fichiers .ps1 est associée à l’éditeur ISE.

Ce type de sécurité n’était pas mis en place avec les scripts VBS dont l’ouverture était directement associée au Windows Script Host.

Une stratégie d’exécution restreinte

La seconde barrière de sécurité est l’application de la stratégie d’exécution Restricted par défaut pour les postes clients et RemoteSigned celle par défaut pour les serveurs (depuis Windows Server 2012 R2).

La stratégie Restricted est la plus restrictive. C’est-à-dire qu’elle bloque systématiquement l’exécution de tout script. Seules les commandes tapées dans le shell seront exécutées. Pour remédier à l’inexécution des scripts, PowerShell requiert que l’utilisateur change le mode d’exécution avec la commande Set-ExecutionPolicy <mode d’exécution>. Mais pour ce faire il faut être administrateur de la machine.

Peut-être comprenez-vous mieux pourquoi l’utilisation de PowerShell sur vos machines ne constitue pas un accroissement des risques, dans la mesure où certaines règles sont bien respectées.

2. Les stratégies d’exécution

PowerShell intègre un concept de sécurité...

Signature des scripts

1. Les signatures numériques

Une signature numérique est un « procédé » qui permet l’identification du signataire et qui garantit l’intégrité du document. Les signatures numériques, appelées aussi signatures électroniques, sont utilisées par PowerShell pour modérer l’exécution des scripts selon la stratégie d’exécution choisie.

D’un point de vue conceptuel, une signature numérique correspond généralement au chiffrement, à l’aide d’une clé privée, d’une forme abrégée du message appelée « empreinte ». L’empreinte d’un message est le résultat obtenu après avoir appliqué une fonction de hachage au contenu du document.

De l’autre côté de la chaîne, le destinataire s’assure que les données n’ont pas été modifiées durant le transfert en effectuant une comparaison entre l’empreinte qui accompagne le document déchiffré grâce à la clé publique et l’empreinte qu’il a lui-même recalculée. Si les deux empreintes sont identiques, alors cela signifie que les données sont intègres.

2. Les certificats

Un certificat est indissociable d’une clé publique, c’est cet élément-là qui va permettre d’associer une clé à son propriétaire. C’est-à-dire que lorsque l’on déchiffre une signature avec une clé publique, il est plus que nécessaire de vérifier que cette clé est bien celle du signataire. À l’instar d’un document officiel, un certificat contient des informations sur l’identité du propriétaire. Ajouter une signature à un script signifie que vous devez être en possession d’un certificat électronique de signature, qui permet d’identifier de façon sûre la personne qui signe le script. Ce certificat peut être obtenu de diverses façons : soit vous choisissez d’acheter un certificat de signature auprès d’une autorité de certification reconnue, soit vous créez vous-même votre propre certificat...

Gérer les stratégies d’exécution de PowerShell via les stratégies de groupe

Maîtriser la stratégie d’exécution PowerShell au sein d’un groupe d’ordinateurs n’est pas chose aisée, surtout lorsqu’il s’agit d’un parc de plusieurs dizaines de postes informatiques. Si par le passé, il était nécessaire d’installer un modèle d’administration (fichier ADM, Administration Model) de façon à pouvoir appliquer la stratégie d’exécution via les stratégies de groupe (ou GPO en anglais, Group Policy Object), ce n’est aujourd’hui plus le cas. L’application d’une stratégie de sécurité par GPO est en réalité très simple à mettre en place.

Exécutez GPMC.msc.

Sélectionnez l’OU (unité d’organisation) souhaitée, et faites un clic droit pour sélectionner Create a GPO in this domain, and Link it here….