L'idée de base
- L'hôte à configurer doit avoir un certificat installé (avec clé privée).
- Lors de la configuration du gestionnaire de configuration local (LCM) du nœud cible, vous devez spécifier l'empreinte numérique de ce certificat. Cela indique au LCM quel certificat local (ou plus précisément quelle clé privée de certificat) sera utilisé pour déchiffrer les informations d'identification.
- Votre configuration DSC doit pointer vers un fichier qui contient uniquement le certificat (clé publique) de ce même certificat. Cela se fait dans les données de configuration, vous pouvez donc spécifier un certificat différent pour chaque nœud, si vous avez l'intention d'utiliser la même configuration pour chacun.
- Lorsque le MOF est généré, la clé publique est utilisée par la machine générant le MOF pour crypter les informations d'identification.
- Lorsque le LCM sur le nœud cible récupère la configuration du serveur d'extraction (sous forme MOF), il utilise la clé privée du certificat identifié par l'empreinte numérique pour déchiffrer l'objet d'informations d'identification.
En détail
La clé publique ne peut pas être utilisée pour déchiffrer, et vous ne partagez pas la clé privée avec la génération de configuration ni les machines de distribution.
Il semble que vous envisagiez le flux de travail comme s'il y avait un seul certificat utilisé pour toutes les informations d'identification. Vous pouvez le faire, mais je pense que l'idée est que chaque nœud a sa propre paire de clés.
Les "utilisateurs moyens", que j'entends comme des utilisateurs non administratifs, ne sont pas en mesure d'exporter la clé privée d'un certificat (à moins que les autorisations ne leur soient accordées), et puisque vous ne déplacerez pas cette clé, il y a peu de chances il étant exposé. Si l'utilisateur est administrateur, eh bien, bien sûr, il y a accès.
Il est beaucoup plus probable que le stockage des informations d'identification en texte brut dans une configuration soit exposé, que ce soit via la configuration PowerShell non traitée ou le MOF généré. S'il n'est pas chiffré, vous devez sécuriser:
- L'emplacement du système de fichiers / partage réseau où la configuration est stockée
- Le fs / share où les MOF générés sont stockés
- Le fs / share où vous stockez les MOF sur le serveur pull
- Assurez-vous que le serveur d'extraction s'exécute sur SSL (vous devez le faire quand même)
- Assurez-vous qu'il existe une authentification sur le serveur Pull, sinon toute requête anonyme pourrait récupérer une configuration avec des informations d'identification exposées.
Je pense que les informations d'identification sécurisées dans DSC sont assez bien faites, mais c'est un peu une épreuve de les configurer au départ.
AD PKI rend cela plus facile
Si vous utilisez Enterprise PKI dans votre environnement AD, il y a de fortes chances que chaque machine soit configurée pour l'inscription automatique auprès de l'autorité de certification, de sorte qu'elle dispose déjà d'un certificat spécifique à la machine qui se renouvelle. Il dispose des paramètres nécessaires à cette fin.
Comment j'implémente ceci
Étant donné que les outils sont si nus pour DSC en ce moment, il est probable que vous créerez votre propre flux de travail pour générer des configurations et écrire des scripts pour vous aider de toute façon.
Dans mon cas, j'ai des scripts séparés pour générer le méta MOF LCM et pour générer la configuration réelle du nœud, donc mes étapes pour sécuriser les informations d'identification sont réparties entre les deux.
Dans le script de génération LCM, je demande en fait à l'autorité de certification le domaine de trouver le certificat qui correspond au nom d'hôte de la machine en cours de configuration. Je récupère le certificat (l'autorité de certification n'a pas la clé privée, seulement le public) et l'enregistre dans un chemin pour une utilisation ultérieure. Le méta MOF est configuré pour utiliser l'empreinte numérique du certificat.
Dans le script de configuration du nœud, j'ai défini les données de configuration pour utiliser le fichier cert (encore une fois la clé publique). Lorsque le MOF est généré, les informations d'identification sont chiffrées avec ce certificat et ne peuvent être déchiffrées qu'avec la clé privée sur le nœud spécifique.
Référence
J'ai référencé ma propre expérience dans ce qui précède, mais cet article a été d'une grande aide en cours de route:
https://devblogs.microsoft.com/powershell/want-to-secure-credentials-in-windows-powershell-desired-state- configuration
J'ai dû combler moi-même certains trous. Une chose à noter dans les exemples qu'ils montrent, c'est qu'ils fournissent la Thumprint
configuration dans le nœud. Ce n'est pas nécessaire pour la configuration du nœud; ils génèrent simplement la configuration et la méta-configuration LCM en même temps et utilisent les données de configuration pour stocker l'empreinte numérique à utiliser là-bas.
Ce dernier paragraphe peut prêter à confusion, mais il est plus logique dans le contexte de l'article. Si vous ne générez pas les deux configurations en même temps, leur exemple semble étrange. Je l'ai testé; Thumbprint
n'est pas requis dans les données de configuration pour crypter les informations d'identification. CertificateFile
est cependant requis, et il doit être dans les données de configuration, donc si vous n'utilisiez pas de données de configuration auparavant, vous le serez maintenant.