A ideia básica
- O host a ser configurado deve ter um certificado instalado (com chave privada).
- Ao configurar o gerenciador de configuração local (LCM) do nó de destino, você deve especificar a impressão digital desse mesmo certificado. Isso informa ao LCM qual certificado local (ou com mais precisão qual chave privada do certificado) será usado para decriptografar a credencial.
- Sua configuração do DSC deve apontar para um arquivo que contenha somente o certificado (chave pública) desse mesmo certificado. Isso é feito nos dados de configuração, para que você possa especificar um certificado diferente para cada nó, caso pretenda usar a mesma configuração para cada um.
- Quando o MOF é gerado, a chave pública é usada pela máquina que gera o MOF para criptografar a credencial.
- Quando o LCM no nó de destino recupera a configuração do servidor de recebimento (no formulário MOF), ele usa a chave privada do certificado identificado pela impressão digital para descriptografar o objeto de credencial.
Em algum detalhe
A chave pública não pode ser usada para descriptografar, e você não está compartilhando a chave privada com a geração de configuração nem as máquinas de distribuição.
Parece que você está considerando o fluxo de trabalho como se houvesse um único certificado em uso para todas as credenciais. Você poderia fazer isso, mas acho que a idéia é que cada nó tem seu próprio par de chaves.
"Usuários médios", que estou assumindo como usuários não administrativos, não podem exportar a chave privada de um certificado (a menos que recebam as permissões) e, como você não estará movendo essa chave, não há pouca chance de ser exposto. Se o usuário é administrador, então é claro que ele tem acesso.
É muito mais provável que o armazenamento de credenciais de texto simples em uma configuração seja exposto, seja pela configuração do powershell não processado ou pelo MOF gerado. Se não estiver criptografado, você precisará proteger:
- O sistema de arquivos / local de compartilhamento de rede em que a configuração está armazenada
- O fs / share onde os MOFs gerados são armazenados
- O fs / share onde você armazena os MOFs no servidor pull
- Assegure-se de que o servidor pull esteja executando por SSL (você deve fazer isso de qualquer maneira)
- Verifique se há autenticação no servidor Pull, caso contrário, qualquer consulta anônima pode recuperar uma configuração com credenciais expostas.
Acredito que as credenciais seguras no DSC são bem feitas, mas é um pouco difícil de configurar inicialmente.
O AD PKI facilita isso
Se você estiver usando o Enterprise PKI em seu ambiente de AD, há uma boa chance de que cada máquina esteja configurada para inscrição automática na CA, por isso já possui um certificado específico de máquina que renova em si. Ele tem as configurações necessárias para serem usadas para esse propósito.
Como estou implementando isso
Como o ferramental está tão vazio para o DSC agora, é provável que você crie seu próprio fluxo de trabalho para gerar configurações e escrever scripts para ajudar de qualquer maneira.
No meu caso eu tenho scripts separados para gerar o meta MOF do LCM e para gerar a configuração real do nó, então meus passos para proteger credenciais são divididos entre ambos.
No script de geração do LCM, na verdade, consultei a autoridade de certificação do domínio para encontrar o certificado que corresponde ao nome do host da máquina que está sendo configurada. Eu recupero o certificado (a CA não tem a chave privada, apenas o público) e salve-a em um caminho para uso posterior. O meta MOF é configurado para usar a impressão digital do certificado.
No script de configuração do nó, defino os dados de configuração para usar o arquivo cert (novamente, somente chave pública). Quando o MOF é gerado, as credenciais são criptografadas com esse certificado e só podem ser descriptografadas com a chave privada no nó específico.
Referência
Eu referenciei minha própria experiência acima, mas este artigo foi uma grande ajuda ao longo do caminho: link
Eu mesmo tive que preencher alguns dos buracos. Uma coisa a ser observada nos exemplos mostrados é que eles fornecem o Thumprint na configuração do nó. Isso não é necessário para a configuração do nó; eles estão apenas gerando a configuração e a meta-configuração do LCM ao mesmo tempo e usando os dados de configuração para armazenar a impressão digital para uso lá.
Esse último parágrafo pode ser confuso, mas faz mais sentido no contexto do artigo. Se você não estiver gerando as duas configurações ao mesmo tempo, o exemplo delas parecerá estranho. Eu testei isso; Thumbprint não é necessário nos dados de configuração para criptografia de credenciais. CertificateFile é necessário, e deve estar nos dados de configuração, portanto, se você não estava usando dados de configuração antes, você estará agora.