Comment utiliser le chiffrement PKI avec PowerShell dans Windows Server 2016

Bien que Microsoft ait introduit plusieurs nouveaux mécanismes de sécurité PowerShell dans la version 5.0, aucun n’est aussi remarquable que la toute nouvelle prise en charge du chiffrement par clé publique. Les entreprises qui utilisent régulièrement PowerShell apprécieront cette fonctionnalité pour renforcer la sécurité de leurs données les plus sensibles.


PowerShell 5.0, livré avec Windows Server 2016 et Windows 10, comprend trois cmdlets liées à PKI : Get-CmsMessage, Protect-CmsMessage et Unprotect-CmsMessage.

Le chiffrement PKI reposant sur l’utilisation de certificats à clé publique et privée, vous devrez créer un certificat et l’ajouter au magasin de certificats, avant de pouvoir chiffrer des données à l’aide de PowerShell.

Il est préférable de se procurer un certificat auprès d’une autorité de certification commerciale bien connue ou auprès de l’autorité de certification d’entreprise de votre propre organisation. Vous pouvez aussi générer votre propre certificat et le signer automatiquement. Mieux vaut ne pas utiliser un certificat auto-signé dans un environnement de production, mais dans un environnement de test, cela ne pose aucun problème.

S’il existe plusieurs façons de générer un certificat auto-signé, Microsoft recommande de créer un simple fichier texte qui pourra servir de contenu du certificat.

[Version]

Signature = « $Windows NT$ »

[Strings]

szOID_ENHANCED_KEY_USAGE = « 2.5.29.37 »

szOID_DOCUMENT_ENCRYPTION = « 1.3.6.1.4.1.311.80.1 »

[NewRequest]

Subject = « cn=youralias@emailaddress.com »

MachineKeySet = false

KeyLength = 2048

KeySpec = AT_KEYEXCHANGE

HashAlgorithm = Sha1

Exportable = true

RequestType = Cert

KeyUsage = « CERT_KEY_ENCIPHERMENT_KEY_USAGE | CERT_DATA_ENCIPHERMENT_KEY_USAGE »

ValidityPeriod = « Years »

ValidityPeriodUnits = « 1000 »

[Extensions]

%szOID_ENHANCED_KEY_USAGE% = « {text}%szOID_DOCUMENT_ENCRYPTION% »

Le seul changement à apporter consiste à inclure un texte d’identification unique dans la ligne Subject. Pour cela, le plus simple est encore de remplacer l’adresse e-mail donnée en exemple par la vôtre.

Dès que vous avez créé un fichier de certificat ou que vous en avez téléchargé un depuis une autorité de certification, importez-le dans votre magasin de certificats.

Renommez le fichier de certificat de façon qu’il porte l’extension .INF et s’exécute dans la commande suivante :

certreq -new DocumentEncryption.cer

La figure A résume le déroulement de ce processus.

http://cdn.ttgtmedia.com/rms/editorial/sWindowsServer_FigureA_080116.png

Figure A. PowerShell est capable de convertir le fichier .INF en un fichier .CER, puis de l’importer dans le magasin de certificats.

Il ne sert à rien de laisser un certificat sur le disque dur du système dès lors que ce nouveau certificat est ajouté dans le magasin de certificats de l’ordinateur.

Partons du principe que vous lancez la commande ci-dessus à partir du dossier racine sur le lecteur C:, le certificat sera placé dans C:. Vous pouvez afficher le fichier de certificat soit à l’aide de l’Explorateur de fichiers, soit en entrant la cmdlet DIR ou Get-ChildItem, suivie du nom de fichier du certificat (Figure B).

http://cdn.ttgtmedia.com/rms/editorial/sWindowsServer_FigureB_080116.png

Figure B. La cmdlet Get-ChildItem révèle l’existence du fichier C:DocumentEncryption.cer.

Si votre fichier de certificat est un certificat auto-signé que vous avez l’intention d’utiliser dans un environnement de test, l’existence du fichier de certificat n’est pas source d’inquiétude. En revanche, si le certificat a été fourni par une autorité de certification en vue d’une utilisation dans l’environnement de production, ce fichier doit alors être déplacé en lieu sûr.

Que vous décidiez de déplacer ce fichier ou de le laisser à son emplacement d’origine, vous devez retenir le chemin d’accès et le nom du fichier de certificat. En effet, le fichier de certificat est appelé dans le cadre du processus de chiffrement.

Pour expliquer le processus de chiffrement, j’ai créé un fichier nommé C:ScriptsHello.txt. Ce fichier contient le texte Hello World. La commande suivante permet de chiffrer le fichier :

Protect-CmsMessage –Path C:ScriptsHello.txt –To C:DocumentEncryption.cer –Outfile Hello.cms

http://cdn.ttgtmedia.com/rms/editorial/sWindowsServer_FigureC_080116.png

Figure C. PowerShell crée un fichier chiffré.

Notez que la commande ci-dessus utilise le paramètre –Outfile. Ce paramètre indique que le contenu du fichier sera chiffré et écrit dans un nouveau fichier : dans ce cas, Hello.cms.

Le fichier de texte d’origine reste non chiffré. La figure C montre comment utiliser la cmdlet Protect-CmsMessage.

La commande Type permet ensuite de confirmer que le fichier Hello.txt n’est pas chiffré, alors que le fichier Hello.cms l’est.

Le déchiffrement est tout aussi facile. En supposant que la clé privée nécessaire figure bien dans le magasin de certificats de l’ordinateur, il suffit d’émettre ces commandes pour déchiffrer le fichier :

$PlainText = Unprotect-CmsMessage –Path C:Hello.cms

$PlainText

La première ligne de code utilise la cmdlet Unprotect-CmsMessage pour déchiffrer le contenu du fichier. Le fichier lui-même reste chiffré, mais le contenu du fichier est écrit dans une variable nommée $PlainText.

La deuxième ligne de code affiche le contenu de cette variable. Vous pouvez voir le résultat dans la figure D.

http://cdn.ttgtmedia.com/rms/editorial/sWindowsServer_FigureD_080116.png

Figure D. La variable $PlainText contient le fichier déchiffré.

Transcriptions des commandes utilisées

PowerShell peut afficher un historique des dernières commandes. Il y a plusieurs façons de faire.

Vous pouvez utiliser la cmdlet Get-History pour récupérer les 64 dernières commandes entrées dans la session actuelle de PowerShell. Une autre solution consiste à enregistrer une transcription à l’aide de la cmdlet Start-Transcript.

Dans Windows Server 2016, Microsoft a apporté deux améliorations à cet outil de transcription.

Premièrement, Microsoft permet à la transcription de s’appliquer à la fois à PowerShell et à l’environnement d’écriture de scripts intégré de PowerShell. Plus important encore, il est désormais possible d’activer la transcription au niveau d’une stratégie de groupe pour permettre une transcription à l’échelle du système.

Les paramètres de la stratégie de groupe liée à la transcription se trouvent sous Modèles d’administration>Composants Windows>Windows PowerShell.

Rapport d’erreur centralisé avec PowerShell DSC

La centralisation des rapports d’erreurs à l’aide du service de configuration d’état souhaitée (Desired State Configuration, DSC) est une autre nouvelle fonctionnalité intéressante de PowerShell.

La fonction DSC de PowerShell permet aux administrateurs de définir une configuration système souhaitée et de détecter toute dérive. Il manquait encore l’option de consignation centralisée à DSC.

Dans Windows Server 2016, Microsoft permet d’envoyer automatiquement les erreurs DSC dans un emplacement central, ce qui facilite considérablement l’examen des erreurs. Cette nouvelle fonction peut être utilisée indépendamment du fait qu’un serveur cible soit configuré pour rapatrier les informations de configuration DSM d’un noeud Pull.

Les erreurs DSC sont de toute façon enregistrées dans les propres journaux d’événements du serveur.

Pour plus d’informations sur les autres cmdlets liées à la sécurité de PowerShell, cliquez ici.

Go to Source


bouton-devis