Protection des informations d'identification dans la configuration de l'état souhaité à l'aide de certificats

Je suis nouveau chez DSC et j'essaie de comprendre comment le faire fonctionner pour nous.

Ce que je suis bloqué, c'est la façon dont les informations d'identification sont réellement protégées. Ma compréhension actuelle est que ce n'est pas si grand que ça.

Les trois grands problèmes sont les suivants. Comment l'utilisation d'une clé publique comme source de déchiffrement protège-t-elle vraiment ces informations d'identification? Quels ordinateurs ont besoin du certificat dans les scénarios push et pull? Quelles sont les meilleures pratiques pour gérer les informations d'identification à la lumière de ces problèmes?

L'utilisation d'une clé publique d'un certificat est utile pour authentifier la source d'une transmission. Mais en l'utilisant comme clé de déchiffrement, l'accès à la clé publique du certificat détermine l'accès au mot de passe.

Si vous devez envoyer le certificat à chaque ordinateur qui doit décrypter les fichiers MOF, qu'est-ce qui empêche les utilisateurs moyens d'accéder au certificat et de pouvoir décrypter le MOF? Dire la sécurité Active Directory signifie que vous pouvez aussi bien le laisser en texte brut et simplement compter sur la sécurité AD.

Quelqu'un peut-il m'aider à comprendre cela?

L'idée de base

1. L'hôte à configurer doit avoir un certificat installé (avec clé privée).
2. 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.
3. 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.
4. 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.
5. 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 Thumprintconfiguration 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é; Thumbprintn'est pas requis dans les données de configuration pour crypter les informations d'identification. CertificateFileest 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.