La sécurité informatique est l’un des problèmes qui préoccupe réellement les entreprises. Et ce à juste titre, comme le montrent de plus en plus d’attaques contre les infrastructures. Les scripts qui contrôlent de nombreuses tâches sont également des cibles prisées pour les attaques. Mais comment augmenter la sécurité dans l’environnement PowerShell ? L’article suivant propose des solutions pour certains des problèmes identifiés.

Ce que PowerShell peut offrir

PowerShell inclut déjà certaines fonctionnalités «standard» destinées à renforcer la sécurité et à prévenir les attaques malveillantes, telles que les stratégies d’exécution, la fonction de journalisation et de surveillance et la signature numérique. C’est un bon début.

Politiques d’exécution

Avec PowerShell, la sécurité commence par les stratégies d’exécution elles spécifient les conditions à créer pour que PowerShell puisse exécuter des scripts. Ici, vous pouvez définir différents niveaux, par exemple, les scripts locaux peuvent être exécutés sans signature, tandis que les scripts téléchargés doivent être signés. En soi, cette fonctionnalité est utile pour empêcher l’exécution accidentelle de scripts. Les pirates, cependant, ne sont pas impressionnés.

Conseil: Si vous utilisez les stratégies d’exécution, contrôlez-les via les stratégies de groupe. Celles-ci sont toujours situées au-dessus des autorisations locales et sont donc plus puissantes dans la lutte contre les exécutions indésirables.

Vérifiez les stratégies définies avec «Get-ExecutionPolicy -list». Si les paramètres sont définis sur RemoteSigned, cela signifie que les scripts locaux sont toujours exécutés, les scripts téléchargés ne comportant qu’une signature. Si le script lui-même est maintenant simplement défini sur «débloqué» et mis à disposition localement, l’obstacle est déjà surmonté.

Enregistrement et surveillance

La journalisation et la surveillance sont également incluses dans PowerShell. Ici, vous pouvez vous assurer que l’exécution des scripts est traçable via le journal des événements Windows. Cependant, vous devez également le faire via les règles de groupe, car la traçabilité ne peut être obtenue que par la centralisation.

Signature numérique

Nous avons déjà mentionné la signature numérique dans les directives d’exécution et constaté qu’elle pouvait être extrêmement importante. Il répond à deux questions: Qui a créé le script (authentification)? Et le script a-t-il été modifié à nouveau après la signature (intégrité)? Il est certainement préférable d’acheter des certificats auprès de fournisseurs officiels, car ils sont considérés comme particulièrement sûrs. Vous pouvez également utiliser New-SelfSignedCertificate pour créer vos propres certificats et les utiliser dans des scripts.

Après chaque modification d’un script, il doit être re-signé.

Langage contraint

PowerShell peut être utilisé dans différents modes linguistiques. L’un d’entre eux est le langage contraint. Il a récemment été largement implémenté, mais nécessite une centralisation si vous souhaitez limiter les fonctionnalités du langage et des commandes PowerShell.

Cela est dû au fait que le paramètre est réinitialisé sur FullLanguage pour chaque nouvelle session. La centralisation n’est donc possible qu’avec des solutions telles qu’Applocker ou Device Guard.

Identifiants

Les informations d’identification requises pour exécuter les scripts PowerShell constituent un sujet passionnant et, en même temps, l’un des plus grands défis.

Les informations d’identification PowerShell se composent d’un nom d’utilisateur et d’un mot de passe et n’ont rien perdu dans les scripts. La saisie manuelle des informations d’identification par l’utilisateur est sûre, mais empêche bien sûr l’exécution automatique des scripts. Une façon de contourner ce problème consiste à chiffrer les informations de mot de passe, qui sont ensuite lues au moment de l’exécution par le script PowerShell. Toutefois, cela ne fonctionne que sur la machine sur laquelle le cryptage a été effectué. Si le fichier de mots de passe est copié sur un autre ordinateur, il ne peut plus être utilisé sur ce dernier. Avec cette méthode, même la délégation sécurisée ne peut pas être mise en œuvre.

JAA – Juste assez d’administration

JAA a pour objectif de fournir aux utilisateurs uniquement les autorisations nécessaires pour effectuer certaines actions. Un exemple serait ici la création d’un utilisateur dans l’Active Directory (AD), sans que l’utilisateur ne dispose donc encore d’autorisations dans l’AD.

JAA fournit une plate-forme de contrôle d’accès basée sur les rôles (RBAC) pour PowerShell. La liste blanche étant utilisée ici, il est impératif de connaître toutes les actions que les utilisateurs doivent pouvoir effectuer. Par conséquent, la mise à jour des directives appropriées est en conséquence complexe et requiert toujours la connaissance de l’utilisateur PowerShell.

Comment ScriptRunner augmente considérablement la sécurité

PowerShell est donc doté de certaines «fonctionnalités de base» pour pouvoir gérer les scripts en toute sécurité. D’autre part, un certain nombre de problèmes rencontrés lors de l’utilisation pratique de PowerShell ne sont pas résolus. Les fonctionnalités de sécurité avancées de ScriptRunner sont décrites ci-dessous.

Centralisation des scripts

Avec ScriptRunner, tous les scripts PowerShell sont stockés et structurés de manière centralisée. Cela crée la condition préalable au développement et à l’utilisation en équipe.

De plus, il est garanti que tous les participants travaillent toujours avec les versions de script actuelles. L’accès aux scripts est contrôlé à l’aide du contrôle des droits. À l’aide du complément ScriptRunner pour PowerShell ISE, les scripts peuvent être modifiés dans le référentiel central et archivés. L’intégration avec Git, TFS et d’autres systèmes de gestion de code source est également possible.

Gestion sécurisée des identifiants

Les informations d’identification sont requises pour exécuter la plupart des scripts PowerShell. Avec ScriptRunner, ces informations peuvent être stockées de manière centralisée et sécurisée. Le magasin d’informations d’identification Windows sur le serveur ScriptRunner est disponible à cet effet et les solutions de serveur de mots de passe de CyberArk, Pleasant et Thycotic sont prises en charge. Cela vous permet de gérer toutes les informations d’identification dans un référentiel central, ce qui simplifie considérablement l’administration, en particulier lorsque vous utilisez plusieurs instances de ScriptRunner.

Aucune autorisation privilégiée pour les utilisateurs

ScriptRunner contrôle les autorisations permettant d’exécuter des scripts PowerShell à partir de comptes de service centraux. Cela signifie que les comptes de service appropriés sont utilisés pour chaque cible (Exchange, Active Directory, Azure, Office365, VMware, etc.).

Les utilisateurs (par exemple, de l’équipe du centre d’assistance) qui devraient pouvoir démarrer des scripts n’ont donc pas besoin d’autorisations spéciales sur les cibles correspondantes.

Cette séparation permet de déléguer en toute sécurité des tâches à des utilisateurs qui ne sont que des utilisateurs de domaine standard.

Exécution sécurisée et surveillance centralisée

ScriptRunner offre toutes les possibilités pour une exécution sécurisée des scripts PowerShell: de l’exécution locale à la communication à distance PowerShell et des modes d’exécution spéciaux, par exemple. JEA, de nombreuses options sont disponibles. L’exécution elle-même est possible de trois manières:

  1. exécution manuelle par les utilisateurs
  2. exécution contrôlée dans le temps
  3. exécution automatique déclenchée par des systèmes tiers tels que des systèmes de surveillance ou de workflow

Toutes les activités peuvent être suivies via le tableau de bord central. Des informations importantes sont également disponibles dans le journal des événements Windows et via le compteur de performances Windows.

Délégation sécurisée

Les fonctions décrites jusqu’à présent permettent aux employés de déléguer des tâches individuelles facilement et en toute sécurité. Sécurisé, car les utilisateurs n’ont besoin d’aucune autorisation spéciale pour effectuer les tâches. Simple, car les employés n’ont besoin d’aucun savoir-faire PowerShell et sont gérés via une interface Web pratique. Les masques de saisie requis sont créés dynamiquement à partir du script PowerShell correspondant. Cela signifie qu’il n’est pas du tout nécessaire de développer une interface utilisateur.

Le résultat est une solution sécurisée pour l’ensemble du cycle de vie de PowerShell, du développement de script commun à l’utilisation par les équipes de support technique et les utilisateurs finaux.

Auteur: Heiko Brenn, Head of International Business, ScriptRunner

Essayez ScriptRunner dès maintenant gratuitement :  http://www.cooperteam.com/fr/scriptrunner.html