Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Windows PowerShell
  3. Scripting
Extrait - Windows PowerShell Administration de postes clients Windows (4e édition)
Extraits du livre
Windows PowerShell Administration de postes clients Windows (4e édition)
1 avis
Revenir à la page d'achat du livre

Scripting

La sécurité

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 :

  • La source du script : ce dernier peut provenir d’Internet, ou avoir été développé en interne par une personne mal intentionnée.

  • La méthode de diffusion : e-mails, périphériques de stockage, réseaux sont les méthodes de diffusion les plus communes.

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...

Windows PowerShell ISE

L’éditeur de script Windows PowerShell ISE fournit un environnement complet pour le développement de scripts Windows PowerShell. Complétions des commandelettes et des paramètres, débogage, sont des fonctionnalités qui vous feront gagner du temps dans l’écriture de scripts.

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 :

  • Mettez des commentaires :

  • Commentaire monoligne : mettez un caractère # en début de ligne.

  • Commentaire multiligne : pour commenter un bloc, ouvrez ce dernier à l’aide des caractères <#, puis refermez-le avec les caractères #>.

  • Donnez des noms explicites aux variables, par exemple $tabUtilisateurs pour un tableau représentant une liste d’utilisateurs.

  • Insérez des tabulations : lors de l’utilisation de fonctions, boucles, conditions, etc., n’hésitez pas à mettre une tabulation pour bien marquer à quel bloc les commandes appartiennent. Voici un exemple :

Function abc ($a, $b, $c) 
{ 
    If ($a -eq $b) 
    { 
        Write-Host "Les 2 variables sont identiques !" 
    } 
    Else 
    { 
       $a = $c 
    } 
} 
  • Utilisez les fonctions : ces dernières ont la particularité d’être pratiques pour exécuter des tâches répétitives, mais aussi pour structurer le code et faciliter sa compréhension.

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

  • disposer d’une copie du script avant modification ;...

Exécuter et déployer des scripts

Le développement d’un script PowerShell peut être parfois long et fastidieux, mais en retour, cela est largement récompensé par le temps gagné à chaque exécution du script. En règle générale, lorsqu’un administrateur écrit un script, ce dernier a pour vocation à être exécuté à maintes reprises (tâche répétitive), ou bien déployé et exécuté sur un nombre indéfini de postes de travail, ou une combinaison des deux à la fois.

Ainsi, vous allez voir dans cette section comment exécuter un script simplement avec la console Windows PowerShell, mais aussi une méthode de déploiement de scripts par GPO.

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.

Images/08EI08N.png

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 :

  • au démarrage de Windows ;...

Importer des données à partir d’un fichier XML ou JSON

Dans certains cas, lorsque l’on développe un script, on souhaite que celui-ci puisse facilement être transposable d’un environnement à un autre. Les exemples sont multiples : domaine différents, suffixes réseau différents, architectures système différentes en fonction du client, etc. C’est ici qu’interviennent l’utilisation de fichiers XML ou JSON pour stocker des données et valeurs propres à l’environnement sur lequel vous souhaitez exécuter votre script.

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.

images/08EI27N.png

Utilisation de fichiers XML avec un script PowerShell

a. Explication et scénario d’exemple

Soit le fichier XML suivant :

<?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> ...