Planeación de la seguridad en Configuration Manager

 

Se aplica a: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1

La siguiente información le ayudará a planear la seguridad en Microsoft System Center 2012 Configuration Manager.

  • Planeación de certificados (autofirmados y PKI)

    • Planeación de la revocación de certificados PKI

    • Planeación de los certificados raíz de confianza PKI y la lista de emisores de certificados

    • Planeación de la selección de certificados de cliente PKI

    • Planeación de una estrategia de transición para certificados PKI y administración de cliente basada en Internet

  • Planeación de la clave raíz confiable

  • Planeación de la firma y el cifrado

  • Planeación de la administración basada en roles

Además de estas secciones, consulte Seguridad y privacidad para la administración de sitios en Configuration Manager.

Para obtener información adicional acerca de cómo utiliza Configuration Manager los certificados y los controles criptográficos, consulte Referencia técnica para los controles criptográficos utilizados en Configuration Manager.

Planeación de certificados (autofirmados y PKI)

Configuration Manager utiliza una combinación de certificados autofirmados y certificados de infraestructura de clave pública (PKI).

Por motivos de seguridad, se recomienda utilizar certificados PKI siempre que sea posible. Para obtener más información acerca de los requisitos de los certificados PKI, consulte Requisitos de certificados PKI para Configuration Manager. Cuando Configuration Manager solicita los certificados PKI, como por ejemplo durante la inscripción de dispositivos móviles y el aprovisionamiento de AMT, se debe utilizar Servicios de dominio de Active Directory y una entidad de certificación empresarial. En todos los demás casos, los certificados PKI se deben implementar y administrar independientemente de Configuration Manager.

Los certificados PKI también se necesitan cuando los equipos cliente se conectan a sistemas de sitio basados en Internet, y se recomienda su uso cuando los clientes se conectan a sistemas de sitio que ejecutan Internet Information Services (IIS). Para obtener más información acerca de la comunicación de cliente, consulte Planeación de las comunicaciones de cliente en Configuration Manager.

Cuando utiliza PKI, también puede utilizar IPsec para proteger la comunicación de servidor a servidor entre sistemas de sitio en un sitio y entre sitios, y para cualquier otro escenario cuando transfiere datos entre equipos. Debe configurar e implementar IPsec independientemente de Configuration Manager.

Configuration Manager puede generar automáticamente certificados autofirmados cuando no hay certificados PKI disponibles, y algunos certificados de Configuration Manager siempre son autofirmados. En la mayoría de los casos, Configuration Manager administra automáticamente los certificados autofirmados y no es necesario tomar medidas adicionales. El certificado de firma de servidor de sitio constituye una posible excepción. El certificado de firma de servidor de sitio siempre es autofirmado, y garantiza que las directivas de cliente que los clientes descargan del punto de administración se enviaron desde el servidor de sitio y no fueron alteradas.

Planeación del certificado de firma de servidor de sitio (autofirmado)

Los clientes pueden obtener de forma segura una copia del certificado de firma de servidor de sitio a través de Servicios de dominio de Active Directory y de la instalación de inserción de cliente. Si los clientes no pueden obtener una copia del certificado de firma de servidor de sitio mediante uno de estos mecanismos, por motivos de seguridad se recomienda instalar una copia del certificado de firma de servidor de sitio al instalar el cliente. Esto resulta de especial importancia si la primera comunicación del cliente con el sitio se realiza desde Internet, ya que el punto de administración está conectado a una red que no es de confianza y, por tanto, es vulnerable a los ataques. Si no se realiza este paso adicional, los clientes descargan automáticamente una copia del certificado de firma de servidor de sitio desde el punto de administración.

Los posibles escenarios de clientes que no pueden obtener de forma segura una copia del certificado de firma de servidor de sitio son los siguiente:

  • No se instala el cliente mediante la inserción de cliente, y se cumple cualquiera de las siguientes condiciones:

    • El esquema de Active Directory no se extiende para Configuration Manager.

    • El sitio del cliente no está publicado en Servicios de dominio de Active Directory.

    • El cliente pertenece a un grupo de trabajo o un bosque que no es de confianza.

  • El cliente se instala cuando está en Internet.

Utilice el siguiente procedimiento para instalar clientes junto con una copia del certificado de firma de servidor de sitio.

Para instalar clientes con una copia del certificado de firma de servidor de sitio

  1. Busque el certificado de firma de servidor de sitio en el servidor de sitio primario del cliente. El certificado se almacena en el almacén de certificados SMS; su nombre de sujeto es Servidor del sitio y su nombre descriptivo es Certificado de aprovisionamiento de AMT.

  2. Exporte el certificado sin la clave privada, almacene el archivo de forma segura y acceda al mismo sólo desde un canal seguro (por ejemplo, mediante la firma de SMB o IPsec).

  3. Instale el cliente mediante el uso de la propiedad de Client.msi SMSSIGNCERT=<ruta completa y nombre de archivo> con CCMSetup.exe.

Planeación de la revocación de certificados PKI

Cuando utilice certificados PKI con Configuration Manager, planee si y cómo los clientes y servidores utilizarán una lista de revocación de certificados (CRL) para comprobar el certificado en el equipo que se conecta. La lista de revocación de certificados (CRL) es un archivo creado y firmado por una entidad de certificación (CA) que contiene una lista de certificados emitidos y revocados. Los certificados pueden ser revocados por un administrador de CA, por ejemplo, si se sabe o se sospecha que un certificado emitido está comprometido.

System_CAPS_importantImportante

Como la ubicación de la CRL se agrega al certificado cuando lo emite la CA, asegúrese de tener en cuenta la CRL antes de implementar los certificados PKI que va a utilizar Configuration Manager.

De forma predeterminada, IIS comprueba siempre la CRL de los certificados de cliente, y no se puede cambiar esta configuración en Configuration Manager. De forma predeterminada, los clientes de Configuration Manager comprueban siempre la CRL de los sistemas de sitio; no obstante, se puede deshabilitar esta opción si se especifica una propiedad de sitio y una propiedad de CCMSetup. Si administra equipos basados en Intel AMT fuera de banda, puede habilitar también la comprobación de CRL para el punto de servicio fuera de banda y para equipos que ejecutan la consola de administración fuera de banda.

Si los equipos utilizan la comprobación de revocación de certificados pero no pueden encontrar la CRL, se comportan como si todos los certificados de la cadena de certificación estuvieran revocados, ya que no se puede comprobar su ausencia de la lista. En este escenario, se produce un error en todas las conexiones que requieren certificados y utilizan una CRL.

La comprobación de la CRL cada vez que se usa un certificado proporciona una mayor seguridad contra certificados que han sido revocados pero incorpora un retraso en la conexión e implica un procesamiento adicional en el cliente. Es más probable que se requiera esta comprobación de seguridad adicional cuando los clientes están en Internet o en una red que no es de confianza.

Consulte con los administradores de PKI antes de decidir si los clientes de Configuration Manager deben comprobar la CRL, y después considere la posibilidad de mantener esta opción habilitada en Configuration Manager cuando se cumplen las condiciones siguientes:

  • La infraestructura PKI es compatible con una CRL, y está publicada donde todos los clientes de Configuration Manager pueden encontrarla. Recuerde que podrían estar incluidos los clientes de Internet, si utiliza la administración de cliente basada en Internet, así como los clientes de bosques que no son de confianza.

  • La necesidad de comprobar la CRL para cada conexión a un sistema de sitio configurado para el uso de un certificado PKI tiene mayor importancia que la necesidad de conexiones más rápidas y un procesamiento eficaz en el cliente, y tiene asimismo mayor importancia que el riesgo de que los clientes no se puedan conectar a los servidores si no pueden encontrar la CRL.

Planeación de los certificados raíz de confianza PKI y la lista de emisores de certificados

Si los sistemas de sitio de IIS utilizan certificados de cliente PKI para la autenticación de cliente a través de HTTP o para la autenticación de cliente y el cifrado a través de HTTPS, podría ser necesario importar los certificados CA raíz como una propiedad de sitio. Los dos escenarios son los siguientes:

  • Se implementan los sistemas operativos mediante el uso de Configuration Manager, y los puntos de administración solo aceptan conexiones de cliente HTTPS.

  • Se utilizan certificados de cliente PKI que no están vinculados a un certificado de entidad de certificación (CA) raíz que es confiable para los puntos de administración.

    Nota

    Cuando se emiten certificados PKI de cliente de la misma jerarquía de CA que emite los certificados de servidor utilizados para los puntos de administración, no es necesario especificar este certificado de CA raíz. Sin embargo, si utiliza varias jerarquías de CA y no está seguro de si tienen confianza mutua, importe la CA raíz de la jerarquía de la CA de los clientes.

Si debe importar los certificados de CA raíz para Configuration Manager, expórtelos desde la CA emisora o desde el equipo cliente. Si exporta el certificado desde la CA emisora que también es la CA raíz, asegúrese de que no se exporta la clave privada. Almacene el archivo de certificado exportado en una ubicación segura para evitar que sea alterado. Debe poder acceder al archivo al configurar el sitio, de modo que si accede al archivo a través de la red, asegúrese de que la comunicación está protegida contra alteraciones mediante la firma de SMB o IPsec.

Si cualquiera de los certificados de CA raíz que importa se renuevan, debe importar los certificados renovados.

Estos certificados de CA raíz importados y el certificado de CA raíz de cada punto de administración forman la lista de emisores de certificados que los equipos de Configuration Manager utilizan de las siguientes maneras:

  • Cuando los clientes se conectan a puntos de administración, el punto de administración comprueba que el certificado de cliente está vinculado a un certificado raíz de confianza de la lista de emisores de certificados del sitio. Si no es así, se rechaza el certificado y se produce un error en la conexión de PKI.

  • Cuando los clientes seleccionan un certificado PKI, si tienen una lista de emisores de certificados, seleccionan un certificado vinculado a un certificado raíz de confianza de la lista de emisores de certificados. Si no hay ninguna coincidencia, el cliente no selecciona un certificado PKI. Para más información sobre el proceso de certificado de cliente, consulte la sección Planeación de la selección de certificados de cliente PKI en este tema.

Independientemente de la configuración del sitio, también podría tener que importar un certificado de CA raíz al inscribir dispositivos móviles o equipos Mac y al realizar el aprovisionamiento de equipos basados en Intel AMT para redes inalámbricas.

Planeación de la selección de certificados de cliente PKI

Si los sistemas de sitio de IIS utilizan certificados de cliente PKI para la autenticación de cliente a través de HTTP o para la autenticación de cliente y el cifrado a través de HTTPS, planee cómo seleccionarán los clientes basados en Windows el certificado que se debe utilizar para Configuration Manager.

Nota

No todos los dispositivos admiten un método de selección de certificado y en su lugar, seleccionan automáticamente el primer certificado que cumple los requisitos del certificado. Por ejemplo, los clientes de equipos Mac y dispositivos móviles no admiten un método de selección de certificado.

En muchos casos, la configuración y el comportamiento predeterminados serán suficientes. El cliente de Configuration Manager en equipos basados en Windows filtra varios certificados mediante los siguientes criterios:

  1. La lista de emisores de certificados: El certificado está vinculado a una CA raíz que es confiable para el punto de administración.

  2. El certificado se encuentra en el almacén de certificados predeterminado Personal.

  3. El certificado es válido, no se revocó y no expiró. La comprobación de validez incluye comprobar que la clave privada es accesible y que el certificado no se creó con la versión 3 de la plantilla de certificado, que no es compatible con Configuration Manager.

  4. El certificado tiene capacidad de autenticación de cliente, o se emitió con el nombre del equipo.

  5. El certificado tiene el periodo de validez más largo.

Los clientes se pueden configurar para utilizar la lista de emisores de certificados mediante los siguientes mecanismos:

  • Se publica como información de sitio de Configuration Manager en Servicios de dominio de Active Directory.

  • Los clientes se instalan mediante la inserción de cliente.

  • Los clientes lo descargan desde el punto de administración después de ser asignados correctamente a su sitio.

  • Se especifica durante la instalación del cliente, como una propiedad CCMCERTISSUERS de CCMSetup Client.msi.

Si los clientes no tienen la lista de emisores de certificados cuando se instalan por primera vez y todavía no están asignados al sitio, omiten esta comprobación. Cuando tienen la lista de emisores de certificados pero no tienen un certificado PKI vinculado a un certificado raíz de confianza de la lista de emisores de certificados, se produce un error en la selección de certificados y los clientes no continúan con los demás criterios de selección de certificados.

En la mayoría de los casos, el cliente de Configuration Manager identifica correctamente un certificado PKI exclusivo y adecuado para utilizarlo. Sin embargo, si no es así, en lugar de seleccionar el certificado en función de la capacidad de autenticación de cliente, puede configurar dos métodos de selección alternativos:

  • Una coincidencia de cadena parcial del nombre de sujeto del certificado de cliente. Esta coincidencia, que no distingue mayúsculas de minúsculas, resulta adecuada si se utiliza el nombre de dominio completo (FQDN) de un equipo en el campo del sujeto y se desea basar la selección de certificados en el sufijo del dominio, por ejemplo contoso.com. Sin embargo, se puede utilizar este método de selección para identificar cualquier cadena de caracteres secuenciales del nombre de sujeto del certificado que permita distinguir este último de los demás certificados del almacén de certificados de cliente.

    Nota

    No se puede utilizar la coincidencia de cadena parcial con el nombre alternativo del sujeto (SAN) como configuración de sitio. Aunque se puede especificar una coincidencia de cadena parcial para el SAN mediante el uso de CCMSetup, las propiedades de sitio la sobrescribirán en los siguientes escenarios:

    • Los clientes recuperan información del sitio que está publicada en Servicios de dominio de Active Directory.

    • Los clientes se instalan mediante la instalación de inserción de cliente.

    Utilice una coincidencia de cadena parcial del SAN solo cuando instala los clientes manualmente, y cuando estos no recuperan información del sitio desde Servicios de dominio de Active Directory. Por ejemplo, estas condiciones se aplican a los clientes solo de Internet.

  • Una coincidencia de los valores de atributo del nombre de sujeto del certificado de cliente o de los valores de atributo del nombre alternativo del sujeto (SAN). Esta coincidencia, que distingue mayúsculas de minúsculas, resulta adecuada si se utiliza un nombre distintivo X500 u OID (identificadores de objetos) equivalentes conforme a RFC 3280 y se desea basar la selección de certificados en los valores de atributo. Puede especificar sólo los atributos, con sus valores, que necesita para identificar de manera exclusiva o validar el certificado y distinguirlo de los demás certificados del almacén de certificados de cliente.

En la siguiente tabla aparecen los valores de atributo que Configuration Manager admite para los criterios de selección de certificados de cliente.

Atributo OID

Atributo de nombre distintivo

Definición de atributo

0.9.2342.19200300.100.1.25

DC

Componente de dominio

1.2.840.113549.1.9.1

E o E-mail

Dirección de correo electrónico

2.5.4.3

CN

Nombre común

2.5.4.4

SN

Nombre de sujeto

2.5.4.5

SERIALNUMBER

Número de serie

2.5.4.6

C

Código de país

2.5.4.7

L

Localidad

2.5.4.8

S o ST

Nombre de estado o provincia

2.5.4.9

STREET

Dirección

2.5.4.10

O

Nombre de la organización

2.5.4.11

OU

Unidad organizativa

2.5.4.12

T o Title

Título

2.5.4.42

G o GN o GivenName

Nombre dado

2.5.4.43

I o Initials

Iniciales

2.5.29.17

(ningún valor)

Nombre alternativo del sujeto

Si se encuentra más de un certificado adecuado después de aplicar los criterios de selección, se puede invalidar la configuración predeterminada que establece la selección del certificado que tenga el periodo de validez más largo y en su lugar especificar que no se debe seleccionar ningún certificado. En este escenario, el cliente no podrá comunicarse con los sistemas de sitio de IIS mediante un certificado PKI. El cliente envía un mensaje de error al punto de estado de reserva asignado para alertar acerca del error de selección de certificados de manera que se puedan modificar o refinar los criterios de selección de certificados. El comportamiento del cliente luego dependerá de si la conexión con errores era HTTPS o HTTP:

  • Si la conexión con errores era HTTPS: El cliente intenta establecer una conexión a través de HTTP y utiliza el certificado autofirmado del cliente.

  • Si la conexión con errores era HTTP: El cliente intenta establecer otra conexión a través de HTTP con el certificado autofirmado del cliente.

Para facilitar la identificación de un certificado de cliente PKI exclusivo, también puede especificar un almacén personalizado distinto al almacén predeterminado Personal del almacén del Equipo. Sin embargo, debe crear este almacén independientemente de Configuration Manager y debe poder implementar certificados en este almacén personalizado así como renovarlos antes de que expire el periodo de validez.

Para más información sobre cómo configurar las opciones de los certificados de cliente, consulte la sección Configurar certificados PKI de cliente en el tema Configuración de la seguridad para Configuration Manager.

Planeación de una estrategia de transición para certificados PKI y administración de cliente basada en Internet

Las opciones de configuración flexible de Configuration Manager permiten llevar a cabo una transición gradual en los clientes y el sitio hacia el uso de los certificados PKI para proteger los extremos de cliente. Los certificados PKI proporcionan mayor seguridad y permiten administrar los clientes cuando están en Internet.

Debido al número de opciones de configuración de Configuration Manager, no existe una única manera de llevar a cabo la transición de un sitio para que todos los clientes utilicen conexiones HTTPS. Sin embargo, puede seguir estos pasos como guía:

  1. Instale el sitio de Configuration Manager y configúrelo para que los sistemas de sitio acepten conexiones de cliente a través de HTTPS y HTTP.

  2. Configure la pestaña Comunicación de equipo cliente de las propiedades del sitio de modo que la Configuración de sistema de sitio sea HTTP o HTTPS, y active la casilla Usar un certificado de cliente PKI (capacidad de autenticación de cliente) cuando esté disponible. Configure las demás opciones de esta pestaña que desee. Para obtener más información, consulte la sección Configurar certificados PKI de cliente del tema Configuración de la seguridad para Configuration Manager.

  3. Lleve a cabo una implementación de PKI para certificados de cliente. Para ver una implementación de ejemplo, consulte la sección Implementación del certificado de cliente para equipos Windows en el tema Ejemplo paso a paso de implementación de los certificados PKI para Configuration Manager: Entidad de certificación de Windows Server 2008.

  4. Instale los clientes mediante el método de instalación de inserción de cliente. Para obtener más información, consulte la sección Instalación de clientes de Configuration Manager mediante la inserción de cliente del tema Instalación de clientes en equipos Windows en Configuration Manager.

  5. Supervise la implementación y el estado de los clientes mediante los informes y la información de la consola de Configuration Manager.

  6. Para realizar el seguimiento del número de clientes que utilizan un certificado PKI de cliente, consulte la columna Certificado de cliente del área de trabajo Activos y compatibilidad, nodo Dispositivos.

    También puede implementar la herramienta de evaluación de preparación de HTTPS (Configuration Manager) de cmHttpsReadiness.exe en los equipos y utilizar los informes para ver cuántos equipos pueden utilizar un certificado PKI de cliente con Configuration Manager.

    Nota

    Cuando el cliente de Configuration Manager se instala en equipos cliente, la herramienta cmHttpsReadiness.exe se instala en la carpeta %windir%\CCM. Cuando ejecuta esta herramienta en los clientes, puede especificar las siguientes opciones:

    • /Store:<nombre>

    • /Issuers:<lista>

    • /Criteria:<criterios>

    • /SelectFirstCert

    Estas opciones se asignan a las propiedades CCMCERTSTORE, CCMCERTISSUERS, CCMCERTSEL y CCMFIRSTCERT de Client.msi, respectivamente. Para obtener más información acerca de estas opciones, consulte Acerca de las propiedades de instalación de cliente de Configuración Manager.

  7. Cuando esté seguro de que un número suficiente de los clientes está utilizando correctamente su certificado PKI de cliente para la autenticación a través de HTTP, haga lo siguiente:

    1. Implemente un certificado de servidor web PKI en un servidor miembro que vaya a ejecutar un punto de administración adicional para el sitio, y configure ese certificado en IIS. Para obtener más información, consulte la sección Implementación del certificado de servidor web para sistemas de sitio que ejecutan IIS del tema Ejemplo paso a paso de implementación de los certificados PKI para Configuration Manager: Entidad de certificación de Windows Server 2008.

    2. Instale el rol de punto de administración en este servidor y configure la opción Conexiones de cliente de las propiedades del punto de administración para HTTPS.

  8. Compruebe que los clientes que tienen un certificado PKI utilizan el nuevo punto de administración mediante HTTPS. Puede utilizar el registro de IIS o los contadores de rendimiento para comprobarlo.

  9. Vuelva a configurar otros roles de sistema de sitio para utilizar conexiones de cliente HTTPS. Si desea administrar clientes en Internet, asegúrese de que los sistemas de sitio tienen un FQDN de Internet y configure puntos de administración y puntos de distribución individuales para que acepten conexiones de cliente de Internet.

    System_CAPS_importantImportante

    Antes de configurar los roles de sistema de sitio para que acepten conexiones de Internet, revise la información de planeación y los requisitos previos de la administración de cliente basada en Internet. Para obtener más información, consulte la sección Planeación de la administración de cliente basada en Internet del tema Planeación de las comunicaciones en Configuration Manager.

  10. Amplíe la implementación de certificados PKI a clientes y sistemas de sitio que ejecutan IIS, y configure los roles de sistema de sitio para las conexiones de cliente HTTPS y las conexiones de Internet, según sea necesario.

  11. Para obtener la máxima seguridad: Cuando esté seguro de que todos los clientes utilizan un certificado PKI de cliente para la autenticación y el cifrado, cambie las propiedades del sitio para que se use HTTPS solamente.

Si sigue este plan para introducir gradualmente los certificados PKI, primero para la autenticación solo a través de HTTP y luego para la autenticación y el cifrado a través de HTTPS, se reducirá el riesgo de que los clientes dejen de estar administrados. Además, se beneficiará de la máxima seguridad que Configuration Manager admite.

Planeación de la clave raíz confiable

La clave raíz confiable de Configuration Manager permite que los clientes de Configuration Manager comprueben que los sistemas de sitio pertenecen a su jerarquía. Cada servidor de sitio genera una clave de intercambio de sitio para comunicarse con otros sitios. La clave de intercambio de sitio del sitio de nivel superior de la jerarquía se denomina clave raíz confiable.

La función de la clave raíz confiable en Configuration Manager es similar a la de un certificado raíz en una infraestructura de clave pública, ya que cualquier elemento firmado por la clave privada de la clave raíz confiable se considerará confiable en los niveles inferiores de la jerarquía. Por ejemplo, al firmar el certificado de punto de administración con la clave privada del par de claves raíz confiables, y al poner a disposición de los clientes una copia de la clave pública del par de claves raíz confiables, los clientes pueden distinguir 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 utilizan WMI para almacenar una copia de la clave raíz confiable en el espacio de nombres root\ccm\locationservices.

Los clientes pueden recuperar automáticamente la copia pública de la clave raíz confiable mediante dos mecanismos:

  • El esquema de Active Directory se extiende para Configuration Manager, el sitio está publicado en Servicios de dominio de Active Directory y los clientes pueden recuperar la información del sitio desde un servidor de catálogo global.

  • Los clientes se instalan mediante la inserción de cliente.

Si los clientes no pueden recuperar la clave raíz confiable mediante uno de estos mecanismos, confiarán en la clave raíz confiable que proporcione el primer punto de administración con el que se comuniquen En este escenario, un cliente podría ser dirigido erróneamente al punto de administración de un atacante, donde recibiría una directiva del punto de administración no autorizado. Tal cosa, que sería obra de un atacante sofisticado, podría suceder solo en un plazo de tiempo limitado antes de que el cliente recupere la clave raíz confiable de un punto de administración válido. Sin embargo, para reducir el riesgo de que un atacante dirija erróneamente los clientes a un punto de administración no autorizado, puede aprovisionar los clientes previamente con la clave raíz confiable.

Utilice los siguientes procedimientos para aprovisionar previamente un cliente de Configuration Manager y comprobar su clave raíz confiable:

  • Aprovisione previamente un cliente con la clave raíz confiable mediante un archivo.

  • Aprovisione previamente un cliente con la clave raíz confiable sin utilizar un archivo.

  • Compruebe la clave raíz confiable de un cliente.

Nota

No es necesario aprovisionar previamente los clientes con la clave raíz confiable si la pueden obtener en Servicios de dominio de Active Directory o se instalan mediante la instalación de inserción de cliente. Asimismo, no es necesario aprovisionar previamente los clientes cuando utilizan la comunicación HTTPS con los puntos de administración, ya que la confianza se establece mediante los certificados PKI.

Puede quitar la clave raíz confiable de un cliente mediante la propiedad de Client.msi RESETKEYINFORMATION = TRUE con CCMSetup.exe Para reemplazar la clave raíz confiable, vuelva a instalar el cliente junto con la nueva clave raíz confiable, por ejemplo, mediante la inserción de cliente, o mediante la propiedad de Client.msi SMSPublicRootKey con CCMSetup.exe.

Para aprovisionar previamente un cliente con la clave raíz confiable mediante un archivo

  1. En un editor de texto, abra el archivo <Directorio de Configuration Manager>\bin\mobileclient.tcf.

  2. Busque la entrada SMSPublicRootKey=, copie la clave de esa línea y cierre el archivo sin realizar ningún cambio.

  3. Cree un nuevo archivo de texto y pegue la información de la clave copiada del archivo mobileclient.tcf.

  4. Guarde el archivo y colóquelo en un lugar donde todos los equipos tengan acceso al mismo y donde esté protegido para evitar alteraciones.

  5. Instale el cliente mediante cualquier método de instalación que acepte las propiedades de Client.msi, y especifique la propiedad de Client.msi SMSROOTKEYPATH=<ruta completa y nombre de archivo>.

    System_CAPS_importantImportante

    Cuando especifique la clave raíz confiable para incrementar la seguridad durante la instalación de clientes, también debe especificar el código de sitio mediante la propiedad de Client.msi SMSSITECODE=<código de sitio>.

Para aprovisionar previamente un cliente con la clave raíz confiable sin utilizar un archivo

  1. En un editor de texto, abra el archivo <Directorio de Configuration Manager>\bin\mobileclient.tcf.

  2. Busque la entrada SMSPublicRootKey=, anote la clave de esa línea o cópiela en el Portapapeles y, a continuación, cierre el archivo sin realizar ningún cambio.

  3. Instale el cliente mediante cualquier método de instalación que acepte las propiedades de Client.msi, y especifique la propiedad de Client.msi SMSPublicRootKey=<clave>, donde <clave> es la cadena copiada de mobileclient.tcf.

    System_CAPS_importantImportante

    Cuando especifique la clave raíz confiable para incrementar la seguridad durante la instalación de clientes, también debe especificar el código de sitio mediante la propiedad de Client.msi SMSSITECODE=<código de sitio>.

Para comprobar la clave raíz confiable de un cliente

  1. En el menú Inicio, haga clic en Ejecutar y, a continuación, escriba Wbemtest.

  2. En el cuadro de diálogo Herramienta de comprobación del instrumental de administración de Windows, haga clic en Conectar.

  3. En el cuadro de diálogo Conectar, en la casilla Espacio de nombres, escriba root\ccm\locationservices y, a continuación, haga clic en Conectar.

  4. En el cuadro de diálogo Herramienta de comprobación del instrumental de administración de Windows, en la sección IWbemServices, haga clic en Clases enumeradoras.

  5. En el cuadro de diálogo Información de la superclase, seleccione Recurrente y, a continuación, haga clic en Aceptar.

  6. En la ventana Resultado de la consulta, desplácese hasta el final de la lista y, a continuación, haga doble clic en TrustedRootKey ().

  7. En el cuadro de diálogo Editor de objetos de TrustedRootKey, haga clic en Instancias.

  8. En la nueva ventana Resultado de la consulta donde se muestran las instancias de TrustedRootKey, haga doble clic en TrustedRootKey=@

  9. En el cuadro de diálogo Editor de objetos de TrustedRootKey=@, en la sección Propiedades, desplácese hacia abajo hasta TrustedRootKey CIM_STRING. La cadena de la columna de la derecha es la clave raíz confiable. Compruebe que coincide con el valor de SMSPublicRootKey del archivo <directorio de Configuration Manager>\bin\mobileclient.tcf.

Planeación de la firma y el cifrado

Cuando se utilizan certificados PKI para todas las comunicaciones de cliente, no es necesario planear la firma y el cifrado para proteger la comunicación de datos de cliente. Sin embargo, si configura sistemas de sitio que ejecutan IIS para permitir las conexiones de cliente HTTP, debe decidir cómo proteger la comunicación de cliente del sitio.

Para proteger los datos que los clientes envían a los puntos de administración, puede requerir la firma de los datos. Además, puede requerir que todos los datos firmados de los clientes que utilizan HTTP se firmen mediante el algoritmo SHA-256. Aunque se trata de una configuración más segura, no habilite esta opción a menos que todos los clientes admitan SHA-256. Muchos sistemas operativos admiten de forma nativa SHA-256, pero los sistemas operativos anteriores pueden necesitar una actualización o revisión. Por ejemplo, los equipos que ejecutan Windows Server 2003 SP2 deben instalar una revisión a la que se hace referencia en el artículo de Knowledge Base 938397.

La firma permite proteger los datos contra la manipulación, y el cifrado permite proteger los datos contra la divulgación de información. Puede habilitar el cifrado 3DES para los mensajes de estado y datos de inventario que los clientes envían a los puntos de administración del sitio. No es necesario que instale actualizaciones en los clientes para admitir esta opción, pero tenga en cuenta el uso adicional de CPU que será necesario en los clientes y en el punto de administración para cifrar y descifrar datos.

Para más información sobre cómo configurar las opciones de firma y cifrado, consulte la sección Configurar la firma y el cifrado en el tema Configuración de la seguridad para Configuration Manager.

Planeación de la administración basada en roles

La administración basada en roles le permite diseñar e implementar la seguridad administrativa de la jerarquía de System Center 2012 Configuration Manager mediante el uso de alguna o de todas las opciones siguientes:

  • Roles de seguridad

  • Recopilaciones

  • Ámbitos de seguridad

Estas opciones se combinan para definir un ámbito administrativo para un usuario administrativo. El ámbito administrativo controla los objetos que un usuario administrativo puede ver en la consola de Configuration Manager y los permisos que el usuario tiene en dichos objetos. Las configuraciones de administración basada en roles se replican en cada sitio en la jerarquía como datos globales y, a continuación, se aplican a todas las conexiones administrativas.

System_CAPS_importantImportante

Los retrasos de replicación entre sitios pueden impedir que un sitio reciba los cambios de la administración basada en roles. Para obtener más información acerca de la supervisión de la replicación de base de datos entre sitios, consulte la sección Cómo supervisar los vínculos de replicación de bases de datos y el estado de replicación del tema Supervisión de sitios y jerarquía de Configuration Manager.

Planeación de roles de seguridad

Use roles de seguridad para conceder permisos de seguridad a usuarios administrativos. Los roles de seguridad son grupos de permisos de seguridad que se asignan a usuarios administrativos para que puedan realizar sus tareas administrativas. Estos permisos de seguridad definen las acciones administrativas que un usuario administrativo puede realizar y los permisos que se conceden para determinados tipos de objetos. Como medida de seguridad recomendada, asigne roles de seguridad que proporcionen el menor nivel de permisos.

System Center 2012 Configuration Manager dispone de varios roles de seguridad integrados para admitir las agrupaciones habituales de tareas administrativas. Puede crear sus propios roles de seguridad para satisfacer sus requisitos empresariales. Ejemplos de roles de seguridad integrados:

  • Administrador total: Este rol de seguridad concede todos los permisos en Configuration Manager.

  • Analista de activos: Este rol de seguridad permite a los usuarios administrativos ver datos recopilados mediante Asset Intelligence, inventario de software, inventario de hardware y la disponibilidad de software. Los usuarios administrativos pueden crear reglas de compatibilidad y categorías, familias y etiquetas de Asset Intelligence.

  • Administrador de actualizaciones de software: Este rol de seguridad concede permisos para definir e implementar actualizaciones de software. Los usuarios administrativos asociados a este rol pueden crear recopilaciones, grupos de actualizaciones de software, implementaciones y plantillas, y habilitar actualizaciones de software para Protección de acceso a redes (NAP).

System_CAPS_tipSugerencia

Puede ver la lista de los roles de seguridad integrados y los roles de seguridad personalizados que crea, y sus descripciones, en la consola de Configuration Manager. A tal efecto, en el área de trabajo Administración, expanda Seguridad y, a continuación, haga clic en Roles de seguridad.

Cada rol de seguridad tiene determinados permisos para distintos tipos de objetos. Por ejemplo, el rol de seguridad Administrador de aplicaciones tiene los siguientes permisos para las aplicaciones: Aprobar, Crear, Eliminar, Modificar, Modificar carpetas, Mover objetos, Leer/Implementar, Establecer ámbito de seguridad. No puede cambiar los permisos de los roles de seguridad integrados, pero puede copiar el rol, realizar cambios y, a continuación, guardar estos cambios como un nuevo rol de seguridad personalizado. También puede importar roles de seguridad que ha exportado desde otra jerarquía (por ejemplo, de una red de prueba). Revise los roles de seguridad y sus permisos para determinar si utilizará los roles de seguridad integrados o si debe crear sus propios roles de seguridad personalizados.

Los pasos siguientes le permiten planear los roles de seguridad:

  1. Identifique las tareas que los usuarios administrativos realizan en System Center 2012 Configuration Manager. Estas tareas pueden estar relacionadas con uno o más grupos de tareas de administración, como la implementación de aplicaciones y paquetes, la implementación de sistemas operativos y configuraciones para el cumplimiento, la configuración de sitios y seguridad, la realización de auditorías, el control remoto de equipos y la recopilación de datos de inventario.

  2. Asigne estas tareas administrativas a uno o varios roles de seguridad integrados.

  3. Si algunos de los usuarios administrativos realiza las tareas de varios roles de seguridad, asigne dichos roles de seguridad a estos usuarios administrativos en vez de crear un nuevo rol de seguridad que combine las tareas.

  4. Si las tareas que identificó no se ajustan a los roles de seguridad integrados, cree y pruebe nuevos roles de seguridad.

Para más información sobre cómo crear y configurar roles de seguridad para la administración basada en roles, consulte las secciones Crear roles de seguridad personalizados y Configurar roles de seguridad en el tema Configuración de la seguridad para Configuration Manager.

Planeación de recopilaciones

Las recopilaciones especifican los recursos de usuario y equipo que los usuarios administrativos pueden ver o administrar. Por ejemplo, para que los usuarios administrativos puedan implementar aplicaciones o ejecutar el control remoto, deben estar asignados a un rol de seguridad que conceda acceso a la recopilación que contiene dichos recursos. Puede seleccionar recopilaciones de usuarios o dispositivos.

Para obtener más información acerca de las recopilaciones, consulte Introducción a las colecciones en Configuration Manager.

Antes de configurar la administración basada en roles, compruebe si tiene que crear nuevas recopilaciones por cualquiera de las siguientes razones:

  • Organización funcional. Por ejemplo, separar recopilaciones de servidores y estaciones de trabajo.

  • Alineación geográfica. Por ejemplo, separar recopilaciones de Europa y América del Norte.

  • Requisitos de seguridad y procesos empresariales. Por ejemplo, separar las recopilaciones para equipos de prueba y producción.

  • Alineación de la organización. Por ejemplo, separar recopilaciones para cada unidad de negocio.

Para más información sobre cómo configurar recopilaciones para la administración basada en roles, consulte la sección Configurar recopilaciones para administrar la seguridad en el tema Configuración de la seguridad para Configuration Manager.

Planeación de ámbitos de seguridad

Use los ámbitos de seguridad para proporcionar acceso a objetos protegibles para los usuarios administrativos. Los ámbitos de seguridad son un conjunto de objetos protegibles asignados a usuarios administrativos como un grupo. Todos los objetos protegibles deben estar asignados a uno o más ámbitos de seguridad.Configuration Manager tiene dos ámbitos de seguridad integrados:

  • Todos: Este ámbito de seguridad integrado concede acceso a todos los ámbitos. No se pueden asignar objetos a este ámbito de seguridad.

  • Predeterminado: Este ámbito de seguridad integrado se utiliza para todos los objetos de forma predeterminada. Cuando se instala inicialmente System Center 2012 Configuration Manager, todos los objetos se asignan a este ámbito de seguridad.

Si desea restringir los objetos que los usuarios administrativos pueden ver y administrar, debe crear y utilizar sus propios ámbitos de seguridad personalizados. Los ámbitos de seguridad no admiten estructuras jerárquicas y no se pueden anidar. Los ámbitos de seguridad pueden contener uno o varios tipos de objetos, como:

  • Suscripciones de alerta

  • Aplicaciones

  • Imágenes de arranque

  • Grupos de límites

  • Elementos de configuración

  • Configuraciones personalizadas de cliente

  • Puntos de distribución y grupos de puntos de distribución

  • Paquetes de controladores

  • Condiciones globales

  • Trabajos de migración

  • Imágenes de sistema operativo

  • Paquetes de instalación de sistema operativo

  • Paquetes

  • Consultas

  • Sitios

  • Reglas de disponibilidad de software

  • Grupos de actualizaciones de software

  • Paquetes de actualizaciones de software

  • Paquetes de secuencias de tareas

  • Paquetes y elementos de configuración de dispositivos Windows CE

También hay algunos objetos que no se incluyen en los ámbitos de seguridad ya que solo se pueden proteger mediante roles de seguridad. El acceso administrativo a estos objetos no se puede limitar a un subconjunto de los objetos disponibles. Por ejemplo, puede tener un usuario administrativo que crea grupos de límites que se utilizan en un determinado sitio. Ya que el objeto de límite no admite ámbitos de seguridad, no puede asignar al usuario un ámbito de seguridad que solo proporciona acceso a los límites que puedan estar asociados a ese sitio. Como los objetos de límite no pueden estar asociados a un ámbito de seguridad, cuando asigna un rol de seguridad que incluye el acceso a objetos de límite a un usuario, el usuario puede obtener acceso a todos los límites de la jerarquía.

Entre los objetos que no están limitados por ámbitos de seguridad se incluyen los siguientes:

  • Bosques de Active Directory

  • Usuarios administrativos

  • Alertas

  • Directivas antimalware

  • Límites

  • Asociaciones de equipos

  • Configuración de cliente predeterminada

  • Plantillas de implementación

  • Controladores de dispositivo

  • Conector de Exchange Server

  • Asignaciones de sitio a sitio de migración

  • Perfiles de inscripción de dispositivo móvil

  • Roles de seguridad

  • Ámbitos de seguridad

  • Direcciones de sitios

  • Roles de sistema de sitio

  • Títulos de software

  • Actualizaciones de software

  • Mensajes de estado

  • Afinidades de dispositivo de usuario

Cree ámbitos de seguridad si tiene que limitar el acceso a instancias independientes de objetos. Por ejemplo:

  • Un grupo de usuarios administrativos tiene que poder ver las aplicaciones de producción pero no tiene que poder ver aplicaciones de prueba. Cree un ámbito de seguridad para las aplicaciones de producción y otro para las aplicaciones de prueba.

  • Los distintos usuarios administrativos requieren un determinado acceso a algunas instancias de un tipo de objeto. Por ejemplo, un grupo de usuarios administrativos requiere el permiso Leer en determinados grupos de actualizaciones de software, y otro grupo de usuarios administrativos requiere el permiso Modificar y Eliminar para otros grupos de actualizaciones de software. Cree distintos ámbitos de seguridad para estos grupos de actualizaciones de software.

Para más información sobre cómo configurar ámbitos de seguridad para la administración basada en roles, consulte la sección Configurar ámbitos de seguridad para un objeto en el tema Configuración de la seguridad para Configuration Manager.