Protección de credenciales en la configuración de estado deseada mediante certificados

Soy nuevo en DSC e intento descubrir cómo hacer que funcione para nosotros.

En lo que estoy atorado es en cómo se protegen las credenciales. Mi comprensión actual es que no todo es tan bueno.

Los tres grandes problemas son estos. ¿Cómo el uso de una clave pública como fuente de descifrado realmente protege esas credenciales? ¿Qué computadoras necesitan el certificado en escenarios push y pull? ¿Cuáles son las mejores prácticas para tratar con credenciales a la luz de estos problemas?

Usar una clave pública de un certificado es bueno para autenticar la fuente de una transmisión. Pero usarlo como clave de descifrado significa que el acceso a la clave pública del certificado determina el acceso a la contraseña.

Si tiene que enviar el certificado a cada computadora que necesita descifrar archivos MOF, ¿qué hay para evitar que los usuarios promedio obtengan acceso al certificado y puedan descifrar el MOF? Decir la seguridad del directorio activo significa que también puede dejarlo en texto plano y simplemente confiar en la seguridad de AD.

¿Alguien puede ayudarme a entender esto?

La idea basica

1. El host a configurar debe tener un certificado instalado (con clave privada).
2. Al configurar el administrador de configuración local (LCM) del nodo de destino, debe especificar la huella digital de ese mismo certificado. Esto le dice al LCM qué certificado local (o más exactamente qué clave privada del certificado) se utilizará para descifrar la credencial.
3. Su configuración DSC debe apuntar a un archivo que contenga solo el certificado (clave pública) de ese mismo certificado. Esto se hace en los datos de configuración, por lo que puede especificar un certificado diferente para cada nodo, si tiene la intención de utilizar la misma configuración para cada uno.
4. Cuando se genera el MOF, la máquina utiliza la clave pública para generar el MOF para encriptar la credencial.
5. Cuando el LCM en el nodo de destino recupera la configuración del servidor de extracción (en forma MOF), utiliza la clave privada del certificado identificado por la huella digital para descifrar el objeto de credencial.

En cierto detalle

La clave pública no se puede usar para descifrar, y no está compartiendo la clave privada con la generación de configuración ni las máquinas de distribución.

Parece que está considerando el flujo de trabajo como si hubiera un solo certificado en uso para todas las credenciales. Podrías hacer eso, pero creo que la idea es que cada nodo tiene su propio par de claves.

Los "usuarios promedio", que considero que significan usuarios no administrativos, no pueden exportar la clave privada de un certificado (a menos que se les otorguen los permisos), y dado que no moverán esta clave, hay pocas posibilidades de está siendo expuesto Si los usuarios son administradores, entonces, por supuesto, tienen acceso.

Es mucho más probable que el almacenamiento de credenciales de texto sin formato en una configuración quede expuesto ya sea a través de la configuración de PowerShell no procesada o del MOF generado. Si no está encriptado, entonces deberá asegurar:

• El sistema de archivos / ubicación de red compartida donde se almacena la configuración
• El fs / share donde se almacenan los MOF generados
• El fs / share donde almacena los MOF en el servidor de extracción
• Asegúrese de que el servidor de extracción se ejecute sobre SSL (debe hacer esto de todos modos)
• Asegúrese de que haya autenticación en el servidor Pull, de lo contrario, cualquier consulta anónima podría recuperar una configuración con credenciales expuestas.

Creo que las credenciales seguras en DSC se hacen bastante bien, pero es un poco difícil de configurar inicialmente.

AD PKI lo hace más fácil

Si está utilizando Enterprise PKI en su entorno de AD, existe una buena posibilidad de que cada máquina esté configurada para la inscripción automática con la CA, por lo que ya tiene un certificado específico de la máquina que se renueva. Tiene la configuración necesaria para ser utilizada para este propósito.

Cómo estoy implementando esto

Dado que las herramientas son tan simples para DSC en este momento, es probable que esté creando su propio flujo de trabajo para generar configuraciones y escribir scripts para ayudar de todos modos.

En mi caso, tengo scripts separados para generar el meta MOF LCM y para generar la configuración real del nodo, por lo que mis pasos para proteger las credenciales se dividen entre ambos.

En el script de generación LCM, en realidad le pregunto a la CA el dominio para encontrar el certificado que corresponde al nombre de host de la máquina que se está configurando. Recupero el certificado (la CA no tiene la clave privada, solo la pública) y la guardo en una ruta para su uso posterior. El meta MOF se configura para usar la huella digital del certificado.

En la secuencia de comandos de configuración de nodo configuré los datos de configuración para usar el archivo cert (de nuevo solo clave pública). Cuando se genera el MOF, las credenciales se cifran con ese certificado y solo se pueden descifrar con la clave privada en el nodo específico.

Referencia

Hice referencia a mi propia experiencia en lo anterior, pero este artículo fue de gran ayuda en el camino: https://devblogs.microsoft.com/powershell/want-to-secure-credentials-in-windows-powershell-desired-state- configuración

Tuve que rellenar algunos de los agujeros yo mismo. Una cosa a tener en cuenta en los ejemplos que muestran es que proporcionan la Thumprintconfiguración en el nodo. Esto no es necesario para la configuración del nodo; solo generan la configuración y la metaconfiguración de LCM al mismo tiempo y usan los datos de configuración para almacenar la huella digital para usarla allí.

Ese último párrafo puede ser confuso, pero tiene más sentido en el contexto del artículo. Si no está generando ambas configuraciones al mismo tiempo, entonces su ejemplo parece extraño. Lo probé; Thumbprintno se requiere en los datos de configuración para cifrar credenciales. CertificateFileSin embargo, es obligatorio, y debe estar en los datos de configuración, por lo que si no estaba utilizando los datos de configuración antes, lo estará ahora.