Scripting

1. En quoi la sécurité est-elle importante ?

Avec l’avènement des réseaux locaux, puis d’Internet, la sécurité sur l’ensemble des ordinateurs est devenue quelque chose de primordial. Il ne suffit plus d’attacher son poste de travail avec un câble de sécurité et de mettre une méthode d’identification à l’ouverture de Windows. Aujourd’hui, les failles de sécurité viennent principalement des réseaux (programmes malveillants, personnes mal intentionnées mais aussi incompétentes), des périphériques de stockage (clés USB et disques durs externes, smartphones), etc.

C’est pourquoi mettre en place des politiques de sécurité sur les postes de travail, principalement ceux dédiés aux collaborateurs en entreprise, est important. Mais il convient aussi d’être vigilant lorsqu’on est administrateur : une erreur est vite arrivée...

2. Quels sont les risques ?

Vous avez vu à travers les différents chapitres du livre les possibilités offertes par Windows PowerShell pour l’administration des postes de travail Windows. Imaginez un script PowerShell malveillant qui circule en entreprise : le résultat pourrait avoir de graves conséquences. Il faut alors être attentif principalement aux deux points suivants :

Il convient donc de mettre en place une politique de sécurité sur l’exécution des scripts PowerShell sur les postes de travail, mais aussi sur les interfaces par lesquelles les scripts peuvent transiter.

Bien entendu, le choix de la politique dépend fortement du contexte de l’entreprise, des contraintes de sécurité que peuvent imposer les clients, etc.

3. Optimiser la sécurité d’exécution des scripts

Par défaut, Windows PowerShell est configuré de façon sécurisée. Il est nécessaire de bien appréhender...

1. Les bonnes pratiques du scripting

Pour garantir un bon suivi du développement d’un script, il est bon de respecter quelques bonnes pratiques.

La lisibilité est un point essentiel dans l’écriture de scripts. Cela permet une lecture et une compréhension plus rapide en cas de reprise du script par un autre administrateur, mais également pour vous-même si vous avez oublié le contenu du script. Reprendre un script des mois, voire des années après est courant, et pour faciliter cette reprise, rien de mieux que de respecter les points suivants :

Function abc ($a, $b, $c) 
{ 
    If ($a -eq $b) 
    { 
        Write-Host "Les 2 variables sont identiques !" 
    } 
    Else 
    { 
       $a = $c 
    } 
} 

Enfin, lorsque vous devez procéder à des modifications dans un script, assurez-vous de :

1. Par ligne de commande

Exécuter un script PowerShell en ligne de commande se fait simplement en écrivant le chemin d’accès absolu ou relatif au fichier script Windows PowerShell (.ps1) :

PS C:\Temp> .\debug.ps1 
** Début du script ! ** 
Hello World ! 
 
dimanche 19 octobre 2014 15:19:03 
** Fin du script ! ** 

Si vous devez lancer un script depuis l’invite de commandes, il faut alors préciser le moteur de script Windows PowerShell, qui n’est autre que powershell.exe, suivi du chemin absolu ou relatif au fichier script.

Lancement d’un script PowerShell depuis l’invite de commandes

Dans un cas comme dans l’autre, vous avez la possibilité de mettre des paramètres en les mentionnant après le nom du script, séparés par un espace. Exemple :

PS C:\Temp> .\myScript.ps1 myParameter1 myParameter2 

2. Par GPO

Le déploiement d’un script PowerShell par GPO est le moyen le plus pratique pour le déploiement d’un script en entreprise. Cela ne nécessite rien d’autre qu’un contrôleur de domaine (DC) et que les postes de travail soient rattachés au domaine de l’entreprise.

Ainsi, depuis un DC, vous pouvez paramétrer l’exécution d’un script PowerShell sur l’ensemble des postes de travail que vous aurez déterminés en fonction de l’emplacement de la stratégie de groupe.

L’exécution d’un script PowerShell par GPO peut se faire :

1. Utilisation d’un fichier XML pour vos scripts

Plutôt que d’avoir ainsi un script PowerShell par cas, et qui devient complexe à maintenir à jour, l’ensemble des variables et valeurs définies dans ces scripts sont alors déportées dans un fichier XML. De ce fait, vous n’avez plus qu’un seul fichier script PowerShell à maintenir, et ce dernier ira alors chercher les informations propres à l’environnement dans le fichier XML qui aura été spécifié en argument lors de l’exécution du script.

Utilisation de fichiers XML avec un script PowerShell

<?xml version="1.0" encoding="utf-8"?> 
<Configuration> 
  <DomainInformation> 
    <Name>contoso.local</Name> 
    <Credential> 
      <Login>Administrator</Login> 
      <Password> 
01000000d08c9ddf0115d1118c7a00c04fc297eb010000006f83c5cd643b914894fa4 
c422d15530e0000000002000000000003660000c00000001000000004a4be8eedc4fc 
1c5820250c2cd3418f0000000004800000a000000010000000e2401c201f7a1d46006 
5dfc80076f9144000000050d7b4205d8567e3bbeff5bac617ff2977bef5a0e019d88a 
44e59f5c748e8621349de591629c5728a05291d46d29549bf83dce62b415d82f1b460 
8c9f93c1e8214000000f10d29ebc04ae9427d51234faac11976357c1d78</Password> 
    </Credential> 
  </DomainInformation> 
  <PackageInstallation> 
    <Provider>Chocolatey</Provider> ...