Consideraciones sobre seguridad

El protocolo de autenticación de Kerberos, compatible con controladores de dominio de Windows 2000 o superior, sólo se puede producir dentro de un límite de confianza. La autenticación de Kerberos es el mecanismo usado para realizar la autenticación mutua del agente/servidor de Operations Manager. La autenticación/mutua del agente/servidor es obligatoria para toda comunicación agente/servidor en Shell de Operations Manager.

Un grupo de administración de Operations Manager tiene la capacidad para realizar la detección y supervisión fuera del límite de confianza de Kerberos en el que se encuentra. No obstante, debido a que el protocolo de autenticación predeterminado para equipos Windows que no están unidos a un dominio de Active Directory es NTLM, se debe usar otro mecanismo para permitir la autenticación mutua. Esto se realiza a través del intercambio de certificados entre agentes y servidores.

Cuando la comunicación de Operations Manager se tiene que producir a través de límites de confianza (como por ejemplo, cuando un servidor que se desea supervisar se encuentra en un dominio de Active Directory que no es de confianza y es distinto al grupo de administración que realiza la supervisión), se pueden usar certificados para satisfacer el requisito de autenticación mutua. A través de la configuración manual, se pueden obtener certificados y asociarlos con los equipos y los servicios de Operations Manager que se ejecutan en ellos. Cuando se inicia un servicio que necesita comunicarse con un servicio de un equipo diferente e intenta autenticarse, se intercambiarán los certificados y se realizará una autenticación mutua.

Importante
Los certificados usados para este propósito deben confiar, en última instancia, en la misma entidad de certificación raíz (CA).

Para obtener más información sobre la obtención y el uso de certificados para la autenticación mutua, vea Implementación de un servidor de puerta de enlace.

Existen cuatro tipos de entidades de certificación de Microsoft:

• Raíz de empresa

• Subordinada de empresa

• Raíz independiente

• Subordinada independiente

• Ambos tipos de empresa de entidades de certificación requieren servicios de dominio de Active Directory, mientras que las entidades de certificación independientes no. Cada tipo de entidad de certificación puede emitir los certificados necesarios para la autenticación mutua de agente/servidor a través de límites de confianza.

Habitualmente, una infraestructura de entidad de certificación consta de una entidad de certificación raíz que firma sus propios certificados y se certifica a sí misma, y una o más entidades de certificación subordinadas certificadas por la raíz. Los servidores de entidades de certificación subordinadas son los que solicitan un certificado de servicios, mientras que la raíz se desconecta y se mantiene por motivos de seguridad. Para obtener más información acerca del diseño de certificados, consulte Infrastructure Planning and Design (Diseño y planificación de infraestructura) y Autenticación y cifrado de datos para equipos Windows.

Se usará el Asistente para detección para encontrar equipos UNIX y Linux, y agregarlos al grupo de administración como objetos administrados. Durante el proceso del Asistente para detección, Operations Manager consigue que el equipo UNIX y Linux detectado genere un certificado autofirmado que se usa para autenticación mutua con el servidor de administración. El proceso de generación, firma e intercambio de certificado funciona del siguiente modo cuando está habilitada la detección SSH:

1. El proceso del Asistente para detección en el servidor de administración permite que el equipo UNIX o Linux detectado genere un certificado autofirmado.

2. El servidor de administración detector emite una solicitud de obtención de certificado al equipo UNIX o Linux.

3. El equipo UNIX o Linux devuelve el certificado al servidor de administración

4. El servidor de administración detector crear un par de claves y un certificado autofirmado propio. El servidor de administración sólo genera un par de claves y un certificado autofirmado cuando detecta su primer equipo UNIX o Linux. A continuación, el servidor de administración importa su propio certificado en su almacén de certificados de confianza. El servidor de administración detector firma a continuación el certificado UNIX o Linux con su clave privada. Cualquier firma posterior de certificados de equipos UNIX o Linux por parte del servidor de administración volverá a usar la clave privada del servidor de administración que se generó en la primera firma.

5. A continuación, el servidor de administración detector emite una solicitud de colocación de certificado que vuelve a colocar el certificado firmado por el servidor de administración en el equipo UNIX o Linux que lo generó inicialmente. La capa de comunicación WSMAN del equipo UNIX o Linux se reinicia a continuación para activar el nuevo certificado generado por el equipo UNIX\Linux.

6. Ahora, cuando el servidor de administración solicite que el equipo UNIX o Linux se autentique, el equipo UNIX o Linux proporcionará el certificado de confianza al servidor de administración y el servidor de administración leerá la firma del certificado con el que se presenta, comprobará que confía en esta firma (porque la firma es su propia clave privada que se almacena en su propio almacén de certificados de confianza) y aceptará este certificado como prueba de que el equipo UNIX o LINUX es quien el servidor de administración cree que es.

7. El servidor de administración de detección utilizará las credenciales de UNIX o Linux tal y como está configurado en el correspondiente perfil de ejecución para autenticarse a sí mismo con el equipo UNIX o Linux. Consulte la sección Planificación para perfiles de ejecución UNIX o Linux para obtener más información.

Importante
El orden de operaciones anterior es para la versión de baja seguridad de detección de UNIX o Linux.

Una vez que el servidor de administración detector comienza a administrar el equipo UNIX o Linux, comienzan a ejecutarse las detecciones y los flujos de trabajo del módulo de administración. Estos flujos de trabajo requieren el uso de credenciales para ejecutarse correctamente. Estas credenciales, los objetos, las clases o el grupo al que se aplicarán, y los equipos en los que se distribuirán están incluidos en los perfiles de ejecución. Hay dos perfiles de ejecución que se importan al importar los módulos de administración de UNIX en su grupo de administración. Estos perfiles son:

• Perfil de cuenta de acción de Unix – Este perfil de ejecución y sus credenciales de UNIX o Linux asociadas se usan para actividades de baja seguridad en los equipos UNIX o Linux designados.

• Perfil de cuenta con privilegios de Unix - Este perfil de ejecución y sus credenciales de UNIX o Linux asociadas se usan para actividades protegidas por un nivel más alto de seguridad y, por lo tanto, requieren una cuenta que tenga privilegios más altos en el equipo UNIX o Linux. Esta puede ser (pero no tiene por qué serlo necesariamente) la cuenta raíz.

Deberá configurar estos perfiles con las credenciales de equipo UNIX o Linux adecuadas para los flujos de trabajo del módulo de administración que las usen para funcionar correctamente.

Operations Manager controla el acceso a los grupos supervisados, tareas, vistas y funciones administrativas a través de la asignación de las cuentas de usuario a roles. Un rol en Operations Manager es la combinación de un tipo de perfil (operador, operador avanzado, administrador) y un ámbito (los datos a los que el rol tiene acceso). Normalmente, los grupos de seguridad de Active Directory se asignan a roles y, a continuación, las cuentas individuales se asignan a esos grupos. Antes de la implementación, planifique los grupos de seguridad de Active Directory que se pueden agregar a estos roles y a cualquier rol personalizado, de modo que pueda agregar cuentas de usuario individuales a los grupos de seguridad.

Operations Manager proporciona las siguientes definiciones de roles de forma predeterminada.

Puede agregar grupos de seguridad de Active Directory o cuentas individuales a cualquiera de estos roles predeterminados. Si lo hace, esas cuentas individuales podrán ejercer los privilegios de rol proporcionados a través del ámbito de los objetos.

Operations Manager también le permite crear roles personalizados basados en los perfiles Operador, Operador de sólo lectura, Autor y Operador avanzado. Al crear el rol, podrá precisar mejor el ámbito de los grupos, tareas y vistas a los que el rol puede tener acceso. Por ejemplo, puede crear un rol denominado "Operador de Exchange" y precisar el ámbito a solo vistas, tareas y grupos relacionados con Exchange. Las cuentas de usuario asignadas a este rol solo podrán ejecutar acciones de nivel de operador en objetos relacionados con Exchange.

Las personas de su compañía que interactúan con Operations Manager frecuentemente (como por ejemplo, un administrador de Exchange al que se le ha asignado la función de operador de Exchange), necesitan un modo de detectar nuevas alertas. Esto se puede realizar observando la consola del operador para detectar nuevas alertas o haciendo que Operations Manager les informe sobre la alerta a través de los canales de comunicación admitidos.Operations Manager admite notificaciones a través del correo electrónico, la mensajería instantánea, el servicio de mensajes cortos o los mensajes de buscapersonas. Las notificaciones sobre lo que el rol necesita conocer se envían a los destinatarios especificados en Operations Manager. Un destinatario de Operations Manager es simplemente un objeto que tiene una dirección válida para recibir la notificación, por ejemplo, una dirección SMTP para notificaciones de correo electrónico.

Por tanto, es lógico combinar la asignación de funciones con la pertenencia a un grupo de notificación a través de un grupo de seguridad habilitado para correo electrónico. Por ejemplo, cree un grupo de seguridad de administradores de Exchange y rellénelo con individuos que tengan la información y los permisos para resolver cosas en Exchange. Asigne este grupo de seguridad a una función de administrador de Exchange personalizada para que tenga acceso a los datos y esté habilitado para correo electrónico. A continuación, cree un destinatario mediante la dirección SMTP del grupo de seguridad habilitado para correo electrónico.

En el momento de la implementación, necesita tener listas las cuentas de servicio siguientes. Si usa cuentas de dominio y se ha configurado la directiva de expiración de la contraseña predeterminada de su dominio objeto de directiva de grupo (GPO) según sea necesario, tendrá que cambiar las contraseñas de las cuentas de servicio en función de la programación, usar cuentas de sistema de bajo mantenimiento, o configurar las cuentas para que las contraseñas nunca expiren.

Cuando se implementa Operations Manager, es posible que deba registrar un nombre principal de servicio (SPN) en algunas configuraciones. La autenticación Kerberos utiliza los SPN para que el cliente se autentique mutuamente con el servidor. Para obtener más información, vea What Are Service Publication and Service Principal Names? (¿Qué es la publicación de servicios y un nombre principal de servicio?).

Al instalar Operations Manager, seleccione una cuenta para el servicio de configuración de System Center y el servicio de acceso a datos de System Center. Para obtener más información, vea Implementación de System Center 2012 - Operations Manager.

Precaución
No modifique los permisos predeterminados de Active Directory para permitir que una cuenta realice modificaciones sin restricciones de su propio SPN.

Si selecciona el sistema local como cuenta del servicio de acceso a datos de System Center, la cuenta podrá crear el SPN adecuado. No se requiere ninguna configuración adicional.

Si utiliza una cuenta de dominio, debe registrar un SPN para cada servidor de administración. Utilice la herramienta de línea de comandos SETSPN. Para obtener más información sobre la ejecución de dicha herramienta, vea Setspn Overview (Información general sobre Setspn).

Registre el nombre netbios y el nombre de dominio completo del servidor de administración, utilizando la sintaxis siguiente:

setspn –a MSOMSdkSvc/<netbios name> <DAS account domain>\<DAS account name>

setspn –a MSOMSdkSvc/<fqdn> <DAS account domain>\<DAS account name>

Sugerencia
Puede enumerar los SPN registrados para cuentas de usuario o equipos con la siguiente sintaxis: setspn –l <DAS account name> setspn –l <fqdn>

Si utiliza el equilibrio de carga de red o un equilibrador de carga hardware, el servicio de acceso a datos de System Center debe ejecutarse con una cuenta de dominio. Además del programa de instalación ya descrito, también debe registrar el nombre de carga equilibrada, utilizando la sintaxis siguiente:

setspn –a MSOMSdkSvc/<load balanced name> <DAS account domain>\<DAS account name>

En los equipos supervisados, los agentes puede ejecutar tareas, módulos y monitores a petición, así como en respuesta a unas condiciones predeterminadas. De forma predeterminada, todas las tareas se ejecutan mediante credenciales de cuenta de acción del agente. En algunos casos, la cuenta de acción del agente podría tener derechos y privilegios insuficientes para ejecutar una acción determinada en el equipo.Operations Manager permite que los agentes ejecuten tareas en el contexto de un conjunto alternativo de credenciales que se denomina "cuenta de ejecución". Una cuenta de ejecución es un objeto creado en Operations Manager, al igual que lo es un destinatario, y que se asocia a una cuenta de usuario de Active Directory. A continuación, se usa un perfil de ejecución que asocia la cuenta de ejecución a un equipo específico. Cuando una regla, tarea o monitor que se ha asociado con un perfil de ejecución durante el desarrollo de un módulo de administración necesita ejecutarse en el equipo de destino, lo hace mediante la cuenta de ejecución especificada.

De forma predeterminada, Operations Manager proporciona un número de cuentas de ejecución y de perfiles de ejecución; no obstante, se pueden crear cuentas y perfiles adicionales si es necesario. También puede decidir modificar las credenciales de Active Directory con las que está asociada una cuenta de ejecución. Esto requerirá planear, crear y mantener credenciales de Active Directory adicionales para este propósito. Debe tratar estas cuentas como cuentas de servicio con respecto a la expiración de la contraseña, los servicios de dominio de Active Directory, la ubicación y la seguridad.

Deberá trabajar con los creadores de módulos de administración ya que ellos desarrollan solicitudes para cuentas de ejecución. Para obtener más información, vea Index to Security-related Information for Operations Manager (Índice de información relacionada con la seguridad para Operations Manager).