Referencia técnica de controles criptográficos

Se aplica a: Configuration Manager (rama actual)

Configuration Manager usa la firma y el cifrado para ayudar a proteger la administración de los dispositivos en la jerarquía de Configuration Manager. Con la firma, si los datos se han modificado en tránsito, se descartan. El cifrado ayuda a evitar que un atacante lea los datos mediante un analizador de protocolo de red.

El algoritmo hash principal que utiliza Configuration Manager para firmar es SHA-256. Cuando dos sitios de Configuration Manager se comunican entre sí, firman sus comunicaciones con SHA-256.

A partir de la versión 2107, el algoritmo de cifrado principal que usa Configuration Manager es AES-256. El cifrado se produce principalmente en las dos áreas siguientes:

• Si habilita el sitio para usar el cifrado, el cliente cifra sus datos de inventario y los mensajes de estado que envía al punto de administración.

• Cuando el cliente descarga directivas secretas, el punto de administración siempre cifra estas directivas. Por ejemplo, una secuencia de tareas de implementación de sistema operativo que incluya contraseñas.

Cuando use la comunicación con clientes a través de HTTPS, configure la infraestructura de claves públicas (PKI) para usar certificados con los algoritmos hash y las longitudes de clave máximos. Al usar certificados CNG v3, los clientes de Configuration Manager solo admiten certificados que usan el algoritmo criptográfico RSA. Para obtener más información, consulte Requisitos de los certificados PKI e Información general sobre los certificados CNG v3.

Por motivos de seguridad en el transporte, todo lo que use TLS es compatible con AES-256. Esta compatibilidad incluye cuando configura el sitio para HTTP (E-HTTP) o HTTPS mejorados . En el caso de los sistemas de sitio locales, puede controlar los conjuntos de cifrado TLS. Para los roles basados en la nube, como Cloud Management Gateway (CMG), si habilita TLS 1.2, Configuration Manager configura los conjuntos de cifrado.

Para la mayoría de las operaciones criptográficas con sistemas operativos basados en Windows, Configuration Manager usa estos algoritmos de la biblioteca Windows CryptoAPI rsaenh.dll.

Para obtener más información sobre funciones específicas, vea Operaciones del sitio.

Operaciones del sitio

La información de Configuration Manager se puede firmar y cifrar. Admite estas operaciones con o sin certificados PKI.

Firma y cifrado de directivas

El sitio firma las asignaciones de directivas de cliente con su certificado autofirmado. Este comportamiento ayuda a evitar que el riesgo de seguridad de un punto de administración en peligro envíe directivas manipuladas. Si usa la administración de clientes basada en Internet, este comportamiento es importante porque requiere un punto de administración accesible desde Internet.

Cuando la directiva contiene datos confidenciales, a partir de la versión 2107, el punto de administración los cifra con AES-256. La directiva que contiene datos confidenciales solo se envía a los clientes autorizados. El sitio no cifra la directiva que no tiene datos confidenciales.

Cuando un cliente almacena una directiva, la cifra mediante la interfaz de programación de aplicaciones de protección de datos de Windows (DPAPI).

Aplicación hash de directiva

Cuando un cliente solicita una directiva, primero obtiene una asignación de directiva. Entonces sabe qué políticas se le aplican y solo puede solicitar esos organismos políticos. Cada asignación de directiva contiene el hash calculado para el cuerpo de directivas correspondiente. El cliente descarga los cuerpos de directivas aplicables y, a continuación, calcula el hash de cada cuerpo de directiva. Si el hash del cuerpo de directivas no coincide con el hash de la asignación de directivas, el cliente descarta el cuerpo de directivas.

El algoritmo hash para la directiva es SHA-256.

Aplicación de hash de contenido

El servicio de administrador de distribución del servidor del sitio aplica un algoritmo hash a los archivos de contenido de todos los paquetes. El proveedor de directivas incluye el hash en la directiva de distribución de software. Cuando el cliente de Configuration Manager descarga el contenido, vuelve a generar el hash localmente y lo compara con el proporcionado en la directiva. Si los hashes coinciden, el contenido no se modifica y el cliente lo instala. Si se modifica un solo byte del contenido, los hashes no coincidirán y el cliente no instalará el software. Esta comprobación ayuda a asegurarse de que se instaló el software correcto porque el contenido real se compara con la directiva.

El algoritmo hash predeterminado para el contenido es SHA-256.

No todos los dispositivos admiten el cifrado de hash de contenido. Las excepciones incluyen:

• Windows cuando transmiten contenido de App-V.

Firma y cifrado de inventario

Cuando un cliente envía inventario de hardware o software a un punto de administración, siempre firma el inventario. No importa si el cliente se comunica con el punto de administración a través de E-HTTP o HTTPS. Si usan E-HTTP, también puede optar por cifrar estos datos, lo cual es recomendado.

Cifrado de migración de estado

Cuando una secuencia de tareas captura datos de un cliente para la implementación del sistema operativo, siempre cifra los datos. En la versión 2103 y posteriores, la secuencia de tareas ejecuta la Herramienta de migración de estado de usuario (USMT) con el algoritmo de cifrado AES-256 .

Cifrado para paquetes de multidifusión

Para cada paquete de implementación del sistema operativo, puede habilitar el cifrado cuando use multidifusión. Este cifrado utiliza el algoritmo AES-256 . Si habilita el cifrado, no se requiere ninguna otra configuración de certificado. El punto de distribución habilitado para multidifusión genera automáticamente claves simétricas para cifrar el paquete. Cada paquete tiene una clave de cifrado diferente. La clave se almacena en el punto de distribución habilitado para multidifusión mediante las API estándar de Windows.

Cuando el cliente se conecta a la sesión de multidifusión, el intercambio de claves se produce a través de un canal cifrado. Si el cliente usa HTTPS, usa el certificado de autenticación de cliente emitido por PKI. Si el cliente usa E-HTTP, usa el certificado autofirmado. El cliente solo almacena la clave de cifrado en la memoria durante la sesión de multidifusión.

Cifrado para medios de implementación del sistema operativo

Cuando utilice medios para implementar sistemas operativos, siempre debe especificar una contraseña para proteger los medios. Con una contraseña, las variables de entorno de secuencia de tareas se cifran con AES-128. Otros datos en los medios, incluidos paquetes y contenido para aplicaciones, no están cifrados.

Cifrado del contenido basado en la nube

Cuando se habilita una puerta de enlace de administración en la nube (CMG) para almacenar contenido, el contenido se cifra con AES-256. El contenido se cifra cada vez que lo actualiza. Cuando los clientes descargan el contenido, se cifra y protege mediante la conexión HTTPS.

Inicio de sesión de actualizaciones de software

Todas las actualizaciones de software deben estar firmadas por un editor de confianza para protegerlas contra alteraciones. En los equipos cliente, el Agente de Windows Update (WUA) busca las actualizaciones en el catálogo. No instalará la actualización si no puede encontrar el certificado digital en el almacén de editores de confianza en el equipo local.

Al publicar actualizaciones de software con System Center Novedades Publisher, un certificado digital firma las actualizaciones de software. Puede especificar un certificado PKI o configurar Novedades Publisher para generar un certificado autofirmado para firmar la actualización de software. Si usa un certificado autofirmado para publicar el catálogo de actualizaciones, como Editores WSUS autofirmados, el certificado también debe estar en el almacén de certificados de entidades de certificación raíz de confianza en el equipo local. WUA también comprueba si la configuración de directiva de grupo Permitir contenido firmado desde la ubicación del servicio Microsoft Update de intranet está habilitada en el equipo local. Esta configuración de directiva debe estar habilitada para que WUA busque las actualizaciones creadas y publicadas con System Center Novedades Publisher.

Datos de configuración firmados para la configuración de cumplimiento

Al importar datos de configuración, Configuration Manager comprueba la firma digital del archivo. Si los archivos no están firmados o si se produce un error en la comprobación de la firma, la consola te advertirá que continúes con la importación. Importe los datos de configuración solo si confía explícitamente en el editor y en la integridad de los archivos.

Cifrado y hash para notificación de cliente

Si usa la notificación al cliente, toda la comunicación usa TLS y los algoritmos más altos que el servidor y el cliente pueden negociar. La misma negociación se produce para cifrar con hash los paquetes que se transfieren durante la notificación del cliente, que utiliza SHA-2.

Certificados

Para obtener una lista de los certificados de infraestructura de claves públicas (PKI) que puede usar Configuration Manager, los requisitos o limitaciones especiales y cómo se usan los certificados, consulte Requisitos de los certificados PKI. En esta lista se incluyen los algoritmos hash y las longitudes de clave admitidos. La mayoría de los certificados admiten SHA-256 y una longitud de clave de 2048 bits.

La mayoría de las operaciones de Configuration Manager que usan certificados también admiten certificados v3. Para obtener más información, consulte Introducción a los certificados CNG v3.

Configuration Manager requiere certificados PKI para los escenarios siguientes:

• Al administrar clientes de Configuration Manager en Internet

• Cuando se usa una puerta de enlace de administración en la nube (CMG)

Para la mayoría de las demás comunicaciones que requieren certificados para autenticación, firma o cifrado, Configuration Manager usa automáticamente certificados PKI si están disponibles. Si no están disponibles, Configuration Manager genera certificados autofirmados.

Administración de dispositivos móviles y certificados PKI

Implementación del sistema operativo y certificados PKI

Cuando se usa Configuration Manager para implementar sistemas operativos y un punto de administración requiere conexiones de cliente HTTPS, el cliente necesita un certificado para comunicarse con el punto de administración. Este requisito es incluso cuando el cliente se encuentra en una fase de transición, como arrancar desde un medio de secuencia de tareas o un punto de distribución habilitado para PXE. Para admitir este escenario, cree un certificado de autenticación de cliente PKI y expórtelo con la clave privada. A continuación, impórtelo a las propiedades del servidor de sitio y agregue también el certificado de CA raíz de confianza del punto de administración.

Si crea un medio de arranque, importe el certificado de autenticación de cliente al crear el medio de arranque. Para ayudar a proteger la clave privada y otros datos confidenciales configurados en la secuencia de tareas, configure una contraseña en el medio de arranque. Todos los equipos que arrancan desde el medio de arranque usan el mismo certificado con el punto de administración que se requiere para las funciones de cliente, como solicitar la directiva de cliente.

Si usa PXE, importe el certificado de autenticación de cliente al punto de distribución habilitado para PXE. Usa el mismo certificado para cada cliente que arranca desde ese punto de distribución habilitado para PXE. Para ayudar a proteger la clave privada y otros datos confidenciales en las secuencias de tareas, necesite una contraseña para PXE.

Si cualquiera de estos certificados de autenticación de cliente está en peligro, bloquee los certificados en el nodo Certificados del área de trabajo Administración , nodo Seguridad . Para administrar estos certificados, necesita el permiso para administrar el certificado de implementación del sistema operativo.

Una vez que Configuration Manager implementa el sistema operativo e instala el cliente, el cliente requiere su propio certificado de autenticación de cliente PKI para la comunicación con el cliente HTTPS.

Soluciones de proxy ISV y certificados PKI

Los proveedores de software independientes (ISV) pueden crear aplicaciones que amplíen Configuration Manager. Por ejemplo, un ISV podría crear extensiones para admitir plataformas de cliente que no sean de Windows. Sin embargo, si los sistemas del sitio requieren conexiones de cliente HTTPS, estos clientes también deben usar certificados PKI para la comunicación con el sitio. Configuration Manager incluye la capacidad de asignar un certificado al proxy ISV que permite las comunicaciones entre los clientes proxy ISV y el punto de administración. Si usa extensiones que requieren certificados de proxy ISV, consulte la documentación del producto.

Si el certificado ISV está en peligro, bloquee el certificado en el nodo Certificados del área de trabajo Administración , nodo Seguridad .

Copiar GUID para el certificado de proxy ISV

A partir de la versión 2111, para simplificar la administración de estos certificados de proxy ISV, ahora puede copiar su GUID en la consola de Configuration Manager.

1. En la consola de Configuration Manager, ve al área de trabajo Administración.

2. Expanda Seguridad y seleccione el nodo Certificados .

3. Ordene la lista de certificados por la columna Tipo .

4. Seleccione un certificado de tipo ISV Proxy.

5. En la cinta de opciones, seleccione Copiar GUID de certificado.

Esta acción copia el GUID de este certificado, por ejemplo: aa05bf38-5cd6-43ea-ac61-ab101f943987

Inteligencia de activos y certificados

Desde noviembre de 2021, la inteligencia de activos ha quedado obsoleta y recomendamos a los clientes que desinstalen este rol.

Servicios y certificados de Azure

Cloud Management Gateway (CMG) requiere certificados de autenticación del servidor. Estos certificados permiten al servicio proporcionar comunicación HTTPS a los clientes a través de Internet. Para obtener más información, consulte Certificado de autenticación del servidor CMG.

Los clientes necesitan otro tipo de autenticación para comunicarse con CMG y el punto de administración local. Pueden usar Microsoft Entra ID, un certificado PKI o un token de sitio. Para obtener más información, consulte Configuración de la autenticación de cliente para la puerta de enlace de administración en la nube.

Los clientes no requieren un certificado PKI de cliente para usar el almacenamiento basado en la nube. Después de autenticarse en el punto de administración, el punto de administración emite un token de acceso de Configuration Manager al cliente. El cliente presenta este token al CMG para acceder al contenido. El token es válido durante ocho horas.

Comprobación de CRL para certificados PKI

Una lista de revocación de certificados (CRL) PKI aumenta la seguridad general, pero requiere cierta sobrecarga administrativa y de procesamiento. Si habilita la comprobación de CRL, pero los clientes no pueden acceder a la CRL, se produce un error en la conexión PKI.

IIS habilita la comprobación de CRL de forma predeterminada. Si utiliza una CRL con la implementación de PKI, no es necesario configurar la mayoría de los sistemas de sitio que ejecutan IIS. La excepción es para las actualizaciones de software, que requieren un paso manual para habilitar la comprobación de CRL a fin de comprobar las firmas en los archivos de actualización de software.

Cuando un cliente usa HTTPS, habilita la comprobación de CRL de forma predeterminada.

Las conexiones siguientes no admiten la comprobación de CRL en Configuration Manager:

• Conexiones de servidor a servidor

Comunicación del servidor

Configuration Manager utiliza los siguientes controles criptográficos para la comunicación con el servidor.

Comunicación de servidor dentro de un sitio

Cada servidor del sistema del sitio utiliza un certificado para transferir datos a otros sistemas del sitio en el mismo sitio de Configuration Manager. Algunos roles del sistema de sitio también usan certificados para la autenticación. Por ejemplo, si instala el punto de proxy de inscripción en un servidor y el punto de inscripción en otro servidor, pueden autenticarse entre sí mediante este certificado de identidad.

Cuando Configuration Manager usa un certificado para esta comunicación, si hay un certificado PKI disponible con la funcionalidad de autenticación del servidor, Configuration Manager lo usa automáticamente. Si no es así, Configuration Manager genera un certificado autofirmado. Este certificado autofirmado tiene capacidad de autenticación de servidor, usa SHA-256 y tiene una longitud de clave de 2048 bits. Configuration Manager copia el certificado en el almacén Trusted People en otros servidores del sistema del sitio que podrían necesitar confiar en el sistema del sitio. Los sistemas del sitio pueden confiar entre sí mediante estos certificados y PeerTrust.

Además de este certificado para cada servidor del sistema del sitio, Configuration Manager genera un certificado autofirmado para la mayoría de los roles del sistema del sitio. Cuando hay más de una instancia del rol de sistema de sitio en el mismo sitio, comparten el mismo certificado. Por ejemplo, puede tener varios puntos de administración en el mismo sitio. Este certificado autofirmado usa SHA-256 y tiene una longitud de clave de 2048 bits. Se copia en los servidores del sistema de Trusted People Store in situ que podrían necesitar confiar en él. Los siguientes roles del sistema de sitio generan este certificado:

• Punto de sincronización de Asset Intelligence

• Punto de protección de punto de conexión

• Punto de estado de reserva

• Punto de administración

• Punto de distribución habilitado para multidifusión

• Punto de servicios de informes

• Punto de actualización del software

• Punto de migración de estado

Configuration Manager genera y administra automáticamente estos certificados.

Para enviar mensajes de estado desde el punto de distribución al punto de administración, Configuration Manager usa un certificado de autenticación de cliente. Cuando se configura el punto de administración para HTTPS, se requiere un certificado PKI. Si el punto de administración acepta conexiones E-HTTP, puede usar un certificado PKI. También puede usar un certificado autofirmado con capacidad de autenticación de cliente, usa SHA-256 y tiene una longitud de clave de 2048 bits.

Comunicación de servidores entre sitios

Configuration Manager transfiere datos entre sitios mediante la replicación de bases de datos y la replicación basada en archivos. Para obtener más información, consulte Transferencias de datos entre sitios y Comunicaciones entre extremos.

Configuration Manager configura automáticamente la replicación de bases de datos entre sitios. Si está disponible, usa certificados PKI con capacidad de autenticación de servidor. Si no está disponible, Configuration Manager crea certificados autofirmados para la autenticación del servidor. En ambos casos, se autentica entre sitios mediante certificados en el almacén Trusted People que usa PeerTrust. Utiliza este almacén de certificados para asegurarse de que solo los servidores SQL Server de la jerarquía de Configuration Manager participen en la replicación de sitio a sitio.

Los servidores del sitio establecen una comunicación de sitio a sitio mediante un intercambio seguro de claves que se produce automáticamente. El servidor del sitio emisor genera un hash y lo firma con su clave privada. El servidor del sitio receptor comprueba la firma mediante la clave pública y compara el hash con un valor generado localmente. Si coinciden, el sitio receptor acepta los datos duplicados. Si los valores no coinciden, Configuration Manager rechaza los datos de replicación.

La replicación de bases de datos en Configuration Manager utiliza Service Broker de SQL Server para transferir datos entre sitios. Utiliza los siguientes mecanismos:

• SQL Server a SQL Server: esta conexión usa credenciales de Windows para la autenticación del servidor y certificados autofirmados con 1024 bits para firmar y cifrar los datos con el algoritmo AES. Si está disponible, usa certificados PKI con capacidad de autenticación de servidor. Solo usa certificados del almacén de certificados personales del equipo.

• SQL Service Broker: este servicio usa certificados autofirmados con 2048 bits para la autenticación y para firmar y cifrar los datos con el algoritmo AES. Sólo utiliza certificados de la base de datos maestra de SQL Server.

La replicación basada en archivos utiliza el protocolo de bloque de mensajes del servidor (SMB). Usa SHA-256 para firmar datos que no están cifrados y que no contienen datos confidenciales. Para cifrar estos datos, use IPsec, que implementará independientemente de Configuration Manager.

Clientes que usan HTTPS

Cuando los roles de sistema de sitio aceptan conexiones de cliente, puede configurarlos para que acepten conexiones HTTPS y HTTP o solo conexiones HTTPS. Los roles del sistema de sitio que aceptan conexiones de Internet solo aceptan conexiones de cliente a través de HTTPS.

Las conexiones de cliente a través de HTTPS ofrecen un mayor nivel de seguridad al integrarse con una infraestructura de claves públicas (PKI) para ayudar a proteger la comunicación de cliente a servidor. Sin embargo, la configuración de conexiones de cliente HTTPS sin tener un conocimiento profundo de la planificación, la implementación y las operaciones de PKI podría dejarle vulnerable. Por ejemplo, si no protege su entidad de certificación raíz (CA), los atacantes podrían poner en peligro la confianza de toda su infraestructura de PKI. Si no se implementan y administran los certificados PKI mediante procesos controlados y protegidos, se pueden producir clientes no administrados que no puedan recibir paquetes o actualizaciones de software críticos.

Comunicación no cifrada cuando los clientes usan HTTPS

Cuando los clientes se comunican con los sistemas del sitio a través de HTTPS, la mayor parte del tráfico está cifrado. En las situaciones siguientes, los clientes se comunican con los sistemas del sitio sin usar cifrado:

• El cliente no puede establecer una conexión HTTPS en la intranet y recurre a HTTP cuando los sistemas del sitio permiten esta configuración.

• Comunicación a los siguientes roles del sistema de sitio:

  • El cliente envía mensajes de estado al punto de estado de reserva.

  • El cliente envía solicitudes PXE a un punto de distribución habilitado para PXE.

  • El cliente envía datos de notificación a un punto de administración.

Los puntos de servicios de informes se configuran para usar HTTP o HTTPS independientemente del modo de comunicación con el cliente.

Clientes que utilizan E-HTTP

Cuando los clientes usan la comunicación E-HTTP para los roles del sistema de sitio, pueden usar certificados PKI para la autenticación de cliente o certificados autofirmados que genera Configuration Manager. Cuando Configuration Manager genera certificados autofirmados, tiene un identificador de objeto personalizado para la firma y el cifrado. Estos certificados se usan para identificar de forma única al cliente. Estos certificados autofirmados utilizan SHA-256 y tienen una longitud de clave de 2048 bits.

Implementación del sistema operativo y certificados autofirmados

Cuando se usa Configuration Manager para implementar sistemas operativos con certificados autofirmados, el cliente también debe tener un certificado para comunicarse con el punto de administración. Este requisito es incluso si el equipo se encuentra en una fase de transición, como arrancar desde un medio de secuencia de tareas o un punto de distribución habilitado para PXE. Para admitir este escenario para conexiones de cliente E-HTTP, Configuration Manager genera certificados autofirmados que tienen un identificador de objeto personalizado para la firma y el cifrado. Estos certificados se usan para identificar de forma única al cliente. Estos certificados autofirmados utilizan SHA-256 y tienen una longitud de clave de 2048 bits. Si estos certificados autofirmados están en peligro, evite que los atacantes los usen para suplantar clientes de confianza. Bloquee los certificados en el nodo Certificados del área de trabajo Administración , nodo Seguridad .

Autenticación de cliente y servidor

Cuando los clientes se conectan a través de E-HTTP, autentican los puntos de administración mediante Servicios de dominio de Active Directory o la clave raíz de confianza de Configuration Manager. Los clientes no autentican otros roles del sistema del sitio, como puntos de migración de estado o puntos de actualización de software.

Cuando un punto de administración autentica por primera vez un cliente mediante el certificado de cliente autofirmado, este mecanismo proporciona una seguridad mínima porque cualquier equipo puede generar un certificado autofirmado. Use la aprobación del cliente para mejorar este proceso. Aprobar solo los equipos de confianza, ya sea automáticamente por Configuration Manager o manualmente por un usuario administrativo. Para obtener más información, consulte Administrar clientes.

Acerca de las vulnerabilidades de SSL

Para mejorar la seguridad de los clientes y servidores de Configuration Manager, realice las siguientes acciones:

• Habilite TLS 1.2 en todos los dispositivos y servicios. Para habilitar TLS 1.2 para Configuration Manager, consulte Cómo habilitar TLS 1.2 para Configuration Manager.

• Deshabilite SSL 3.0, TLS 1.0 y TLS 1.1.

• Reordene los conjuntos de cifrado relacionados con TLS.

Para más información, consulte los siguientes artículos:

• restringir el uso de determinados protocolos y algoritmos criptográficos en Schannel.dll
• Priorizar conjuntos de cifrado Schannel

Estos procedimientos no afectan a la funcionalidad de Configuration Manager.