Planear la seguridad en Configuration Manager
Se aplica a: Configuration Manager (rama actual)
En este artículo se describen los siguientes conceptos que debe tener en cuenta al planear la seguridad con la implementación de Configuration Manager:
Certificados (autofirmados y PKI)
La clave raíz de confianza
Firma y cifrado
Administración basada en roles
Azure Active Directory
Autenticación de proveedor de SMS
Antes de empezar, asegúrese de que está familiarizado con los aspectos básicosde la seguridad en Configuration Manager .
Certificados
Configuration Manager usa una combinación de certificados digitales autofirmados y de infraestructura de clave pública (PKI). Use certificados PKI siempre que sea posible. Algunos escenarios requieren certificados PKI. Cuando los certificados PKI no están disponibles, el sitio genera automáticamente certificados autofirmados. Algunos escenarios siempre usan certificados autofirmados.
Para obtener más información, vea Plan for certificates.
La clave raíz de confianza
La clave raíz de confianza de Configuration Manager proporciona un mecanismo para que los clientes de Configuration Manager comprueben que los sistemas de sitio pertenecen a su jerarquía. Cada servidor de sitios genera una clave de intercambio de sitios para comunicarse con otros sitios. La clave de intercambio de sitios del sitio de nivel superior de la jerarquía se denomina clave raíz de confianza.
La función de la clave raíz de confianza en Configuration Manager es similar a un certificado raíz en una infraestructura de clave pública. Cualquier cosa firmada por la clave privada de la clave raíz de confianza es de confianza más abajo en la jerarquía. Los clientes almacenan una copia de la clave raíz de confianza del sitio en el root\ccm\locationservices espacio de nombres WMI.
Por ejemplo, el sitio emite un certificado al punto de administración, que firma con la clave privada de la clave raíz de confianza. El sitio comparte con los clientes la clave pública de su clave raíz de confianza. A continuación, los clientes pueden diferenciar entre los puntos de administración que están en su jerarquía y los puntos de administración que no están en su jerarquía.
Los clientes obtienen automáticamente la copia pública de la clave raíz de confianza mediante dos mecanismos:
Puede ampliar el esquema de Active Directory para Configuration Manager y publicar el sitio en Servicios de dominio de Active Directory. A continuación, los clientes recuperan la información de este sitio de un servidor de catálogo global. Para obtener más información, vea Prepare Active Directory for site publishing.
Al instalar clientes mediante el método de instalación de inserción de cliente. Para obtener más información, vea Instalación de inserción de cliente.
Si los clientes no pueden obtener la clave raíz de confianza mediante uno de estos mecanismos, confían en la clave raíz de confianza proporcionada por el primer punto de administración con el que se comunican. En este escenario, un cliente podría desviarse erróneamente al punto de administración de un atacante donde recibiría la directiva desde el punto de administración no fiable. Esta acción requiere un atacante sofisticado. Este ataque se limita al poco tiempo antes de que el cliente recupere la clave raíz de confianza desde un punto de administración válido. Para reducir este riesgo de que un atacante dirija mal a los clientes a un punto de administración no cifrado, aprovisione previamente a los clientes con la clave raíz de confianza.
Para obtener más información y procedimientos para administrar la clave raíz de confianza, vea Configure security.
Firma y cifrado
Cuando usa certificados PKI para todas las comunicaciones de cliente, no tiene que planear la firma y el cifrado para ayudar a proteger la comunicación de datos del cliente. Si configura algún sistema de sitio que ejecute IIS para permitir conexiones de cliente HTTP, decida cómo proteger la comunicación del cliente para el sitio.
Importante
A partir de configuration manager versión 2103, los sitios que permiten la comunicación de cliente HTTP están en desuso. Configure el sitio para HTTPS o HTTP mejorado. Para obtener más información, vea Enable the site for HTTPS-only or enhanced HTTP.
Para ayudar a proteger los datos que los clientes envían a los puntos de administración, puede requerir que los clientes firmen los datos. También puede requerir el algoritmo SHA-256 para firmar. Esta configuración es más segura, pero no requiere SHA-256 a menos que todos los clientes la admitan. Muchos sistemas operativos admiten este algoritmo de forma nativa, pero los sistemas operativos antiguos pueden requerir una actualización o revisión.
Aunque la firma ayuda a proteger los datos de la manipulación, el cifrado ayuda a proteger los datos de la divulgación de información. Puede habilitar el cifrado para los datos de inventario y los mensajes de estado que los clientes envían a los puntos de administración del sitio. No tiene que instalar ninguna actualización en los clientes para admitir esta opción. Los clientes y los puntos de administración requieren más uso de CPU para el cifrado y descifrado.
Nota
Para cifrar los datos, el cliente usa la clave pública del certificado de cifrado del punto de administración. Solo el punto de administración tiene la clave privada correspondiente, por lo que solo puede descifrar los datos.
El cliente inicia este certificado con el certificado de firma del punto de administración, que arranca con la clave raíz de confianza del sitio. Asegúrese de aprovisionar de forma segura la clave raíz de confianza en los clientes. Para obtener más información, vea La clave raíz de confianza.
Para obtener más información acerca de cómo configurar las opciones de firma y cifrado, vea Configure signing and encryption.
Para obtener más información sobre los algoritmos criptográficos usados para la firma y el cifrado, vea Cryptographic controls technical reference.
Administración basada en roles
Con Configuration Manager, se usa la administración basada en roles para proteger el acceso que los usuarios administrativos necesitan para usar Configuration Manager. También protege el acceso a los objetos que administra, como colecciones, implementaciones y sitios.
Con la combinación de roles de seguridad, ámbitos de seguridad y colecciones, se separan las asignaciones administrativas que cumplen los requisitos de la organización. Se usan juntos y definen el ámbito administrativo de un usuario. Este ámbito administrativo controla los objetos que un usuario administrativo ve en la consola de Configuration Manager y controla los permisos que un usuario tiene en esos objetos.
Para obtener más información, consulte Aspectos básicos de la administración basada en roles.
Azure Active Directory
Configuration Manager se integra con Azure Active Directory (Azure AD) para permitir que el sitio y los clientes usen la autenticación moderna.
Para obtener más información sobre Azure AD, vea Azure Active Directory documentación.
La incorporación del sitio con Azure AD admite los siguientes escenarios de Configuration Manager:
Escenarios de cliente
Escenarios de servidor
Autenticación de proveedor de SMS
Puede especificar el nivel mínimo de autenticación para que los administradores accedan a los sitios de Configuration Manager. Esta característica exige a los administradores que inicien sesión en Windows con el nivel necesario antes de poder acceder a Configuration Manager. Se aplica a todos los componentes que tienen acceso al proveedor de SMS. Por ejemplo, la consola de Configuration Manager, los métodos SDK y Windows PowerShell cmdlets.
Configuration Manager admite los siguientes niveles de autenticación:
Windows autenticación: requerir autenticación con credenciales de dominio de Active Directory. Esta configuración es el comportamiento anterior y la configuración predeterminada actual.
Autenticación de certificado: requiere autenticación con un certificado válido emitido por una entidad de certificación PKI de confianza. Este certificado no se configura en Configuration Manager. Configuration Manager requiere que el administrador haya iniciado sesión en Windows mediante PKI.
Windows Hello para empresas: requiere autenticación con autenticación sólida de dos factores que está vinculada a un dispositivo y usa biometría o PIN. Para obtener más información, vea Windows Hello for Business.
Importante
Al seleccionar esta configuración, el proveedor de SMS y el servicio de administración requieren que el token de autenticación del usuario contenga una notificación de autenticación multifactor (MFA) de Windows Hello para empresas. En otras palabras, un usuario de la consola, SDK, PowerShell o servicio de administración tiene que autenticarse para Windows con su PIN de Windows Hello para empresas o biométrica. De lo contrario, el sitio rechaza la acción del usuario.
Este comportamiento es para Windows Hello para empresas, no para Windows Hello.
Para obtener más información sobre cómo configurar esta configuración, vea Configure SMS Provider authentication.