Consideraciones sobre seguridad

 

Se aplica a: System Center 2012 R2 Operations Manager, Data Protection Manager for System Center 2012, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager

La mayor parte del trabajo de preparación del entorno para System Center 2012 – Operations Manager engloba tareas relacionadas con la seguridad. Esta sección trata esas tareas de forma somera. 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).

La preparación de las tareas de seguridad conlleva lo siguiente:

• Comprender, planificar y preparar la supervisión a través de los límites de confianza.

• Comprender, planificar y preparar la supervisión de equipos UNIX o Linux.

• Planificar y preparar las cuentas de servicio, las cuentas de usuario y los grupos de seguridad necesarios.

• Comprender y preparar los puertos de red según sea necesario por diseño.

Límites de confianza

Los dominios de Active Directory forman la unidad básica de un límite de confianza Kerberos tal y como lo detecta Operations Manager. Este límite se expande automáticamente a otros dominios del mismo espacio de nombres (el mismo árbol de Active Directory) y entre dominios que están en árboles de Active Directory diferentes (pero en el mismo bosque de Active Directory) a través de confianzas transitivas. El límite de confianza se puede expandir aún más entre dominios de bosques de Active Directory diferentes a través del uso de confianzas entre bosques.

Kerberos

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.

Certificados

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.

Entidad de certificación

Para obtener los certificados necesarios, necesita tener acceso a una entidad de certificación (CA). Esta puede ser Servicios de Certificate Server de Microsoft o un servicio de certificación de terceros como VeriSign.

Servicios de Certificate Server de Microsoft

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.

Supervisión de equipos UNIX y Linux

System Center 2012 – Operations Manager puede supervisar equipos UNIX y Linux. Debido a que los equipos UNIX y Linux no participan en el dominio de Active Directory del cual el grupo de administración es una variante, se usa el método de certificación de autenticación mutua mencionado anteriormente.

Establecimiento de autenticación mutua con equipos UNIX y Linux

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.

Planificación para perfiles de ejecución 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.

Cuentas y grupos

En el transcurso de la implementación de Operations Manager, es posible que necesite varias cuentas y varios grupos de seguridad. Durante la instalación de Operations Manager, sólo se le solicitarán cuatro. Debe considerar la creación de cuentas adicionales cuando planifique asignaciones de seguridad basadas en roles, notificaciones y otras credenciales para ejecutar procesos. Para obtener orientación sobre la planificación de asignaciones de seguridad basadas en roles, vea Planificación de la implementación de System Center 2012 - Operations Manager.

Cuentas y grupos de seguridad basados en roles

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.

Nombre de rol	Tipo de perfil	Descripción de perfil	Ámbito de rol
Administradores de Operations Manager: Se crea en la instalación; no se puede eliminar; debe contener uno o más grupos globales	Administrador	Tiene todos los privilegios en Operations Manager; no es compatible con la administración de ámbitos del perfil Administrador	Acceso total a todos los datos, servicios, herramientas administrativas y herramientas de creación de Operations Manager
Operadores avanzados de Operations Manager: Se crea en la instalación; tiene un ámbito global; no se puede eliminar	Operador avanzado	Tiene acceso de modificación limitado a la configuración de Operations Manager; capacidad para invalidar reglas; monitores para destinos o grupos de destinos dentro del ámbito configurado.	Acceso a todos los grupos, vistas y tareas presentes actualmente y a aquellos importados en el futuro
Autores de Operations Manager: Se crea en la instalación; tiene un ámbito global; no se puede eliminar	Autor	Tiene capacidad para crear, editar y eliminar tareas, reglas, monitores y vistas dentro del ámbito configurado	Acceso a todos los grupos, vistas y tareas presentes actualmente y a aquellos importados en el futuro
Operations Manager Operadores: Se crea en la instalación; tiene un ámbito global; no se puede eliminar	Operador	Tiene la capacidad de interactuar con las alertas, ejecutar tareas y obtener acceso a vistas en función del ámbito configurado	Acceso a todos los grupos, vistas y tareas presentes actualmente y a aquellos importados en el futuro
Operadores de sólo lectura de Operations Manager: Se crea en la instalación; tiene un ámbito global; no se puede eliminar	Operador de solo lectura	Tiene la capacidad de ver alertas y obtener acceso a vistas en función del ámbito configurado	Acceso a todos los grupos y vistas presentes actualmente y a aquellos importados en el futuro
Operadores de informes de Operations Manager: Se crea en la instalación; tiene un ámbito global	Operador de informes	Tiene la capacidad de ver informes en función del ámbito configurado	Ámbito global
Administradores de seguridad de informes de Operations Manager: Integra seguridad de SQL Reporting Services con roles de usuario de Operations Manager; proporciona a los administradores de Operations Manager la capacidad para controlar el acceso a informes; no puede delimitarse el ámbito	Administrador de seguridad de informes	Permite la integración de la seguridad de SQL Server Reporting Services con roles de Operations Manager	Sin ámbito

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.

Nota

Las funciones predeterminadas tienen un ámbito global, lo que les proporciona acceso a todos los grupos, vistas y tareas (excepto Administrador de seguridad de informes).

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.

Cuentas y grupos de notificación

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.

Cuentas de servicio

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.

Nombre de cuenta	Solicitada al	Usada para	Bajo mantenimiento	Alta seguridad
Cuenta de acción del servidor de administración	instalar el servidor de administración	Recopilación de datos de proveedores, ejecución de respuestas	Sistema local	Cuenta de dominio de privilegios bajos
Servicio de acceso de datos y cuenta de servicio de configuración	instalar el servidor de administración	Escritura en base de datos operativa, ejecución de servicios	Sistema local	Cuenta de dominio de privilegios bajos
Cuenta de administrador local para dispositivos de destino	Detectar y forzar la instalación de agentes	Instalación de agentes	Cuenta de dominio o de administrador local	Cuenta de dominio o de administrador local
Cuenta de acción del agente	Detectar y forzar la instalación de agentes	Recopilación de información y ejecución de respuestas en equipos administrados	Sistema local	Cuenta de dominio de privilegios bajos
Cuenta de acción de escritura de almacenamiento de datos	Instalar el servidor de informes	Escritura en la base de datos de almacenamiento de datos de informes	Cuenta de dominio de privilegios bajos	Cuenta de dominio de privilegios bajos
Cuenta de lectura de datos	Instalar el servidor de informes	Consulta de la base de datos de SQL Reporting Services	Cuenta de dominio de privilegios bajos	Cuenta de dominio de privilegios bajos

Nombres principales de servicio

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>

Nota

Todos los servicios de acceso a datos de System Center que se ejecuten detrás del equilibrador de carga se deben ejecutar con la misma cuenta de dominio.

Cuentas de ejecución

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).

Vea también

Requisitos previos de entorno para Operations Manager