 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Introducción
Checkmk está disponible en varias ediciones que se diferencian tanto por sus prestaciones como por sus posibles aplicaciones. A continuación, queremos presentarte Checkmk MSP, una de las ediciones comerciales.
En la monitorización distribuida con una configuración distribuida, los usuarios suelen conectarse al site central, para realizar allí las configuraciones o para acceder a los datos de monitorización. Los usuarios también pueden conectarse a los sites remotos, ya que sólo son responsables de los host y servicios que se monitorizan desde allí, por ejemplo. Sin embargo, el concepto de autorización Checkmk de restringir la visibilidad y configurabilidad de hosts y servicios mediante roles y grupos de contacto es totalmente suficiente para ambos escenarios. Los usuarios con autorizaciones muy restringidas no tendrán, por lo general, acceso directo a la línea de comandos del servidor de monitorización y, por tanto, sólo podrán ver los datos de los que son responsables. El hecho de que puedan estar informados de la existencia de otros hosts y servicios no supone ningún problema.
En una configuración distribuida, Checkmk en Checkmk Raw, Checkmk Enterprise y Checkmk Cloud distribuirá, por tanto, todos los datos de configuración a todos los sitios participantes, ya que los datos podrían, en principio, estar ubicados o ser necesarios en cualquiera de ellos. Por ejemplo, las contraseñas gestionadas centralmente también deben estar disponibles para los sitios remotos, ya que los host/servicios de los grupos de contacto pueden estar distribuidos en varios sites.
Sin embargo, cuando Checkmk se va a ofrecer como servicio a un tercero (es decir, a un cliente), determinados datos de configuración sólo pueden distribuirse a los sitios remotos designados. Esto significa que los datos confidenciales de un cliente no deben almacenarse en el servidor de otro cliente, por lo que ya no basta con una mera restricción de visibilidad en la interfaz web. Por último, puede ocurrir que el propio cliente opere el servidor de monitorización local o que tenga acceso directo a la línea de comandos del servidor de alguna otra forma.
Además, ya no es necesario que el cliente pueda configurar su propio site, ya que todo el concepto de un servicio distribuido es precisamente ahorrarle al cliente ese trabajo. El cliente tampoco necesita una vista de tabla del site central, ya que sólo necesita acceder a sus propios datos.
Con Checkmk MSP, a través de la monitorización distribuida, un proveedor de servicios (es decir, un proveedor de servicios gestionados, MSP o proveedor para abreviar) integra para cada uno de sus clientes uno o varios sites remotos en el site central del proveedor -a estos sites remotos sólo puede acceder el cliente en cuestión-. Los elementos individuales del Setup se asignan entonces a este cliente. Al distribuir los datos de configuración, Checkmk sólo los enviará ahora a un site del cliente, que sea de carácter general o que haya sido liberado para este cliente. El proveedor puede seguir realizando la configuración cómodamente a través de la configuración distribuida de su propio site central. El proveedor también dispone de una interfaz web central para que todos sus clientes puedan trabajar con los datos de monitorización. Esto funciona exactamente igual que en un entorno de configuración distribuida normal, con la única diferencia de que todos los sites participantes deben utilizar Checkmk MSP.
Los datos de configuración importantes (por ejemplo, los sitios remotos y los usuarios) se pueden asignar a los clientes en Checkmk MSP. Por tanto, el cliente sólo tiene acceso a su propia configuración con los datos de host y servicio a través del sitio que se le haya asignado. Sólo tendrá que iniciar sesión en su propio site y, por tanto, sólo recibirá sus propios datos. No es necesario iniciar sesión en la instancia central del proveedor, ¡y tampoco es posible!
Importante: debes utilizar Checkmk MSP si utilizas Checkmk para monitorizar no sólo tu propia infraestructura, sino también la de otras organizaciones.
2. Vista general de Checkmk MSP
Checkmk MSP es actualmente la edición más completa de Checkmk. En términos de contenido, se basa en Checkmk Cloud y es su extensión con capacidad multi-tenant. Tiene todas las funciones necesarias para operar sitios Checkmk independientes para múltiples clientes mediante monitorización distribuida.
Si como proveedor quieres ofrecer Checkmk como servicio a tus clientes, ésta es tu edición.
3. Funciones adicionales con Checkmk MSP
La principal función de Checkmk MSP que la distingue de otras ediciones es la posibilidad de asignar los siguientes elementos a los clientes:
Site remotos
Usuarios
Conexiones LDAP
Reglas y paquetes de reglas para la Consola de eventos
Contraseñas en el almacén de contraseñas
Grupos de contacto
AgregacionesBI
Ajustes globales para sites remotos
4. Actualización a Checkmk MSP
Para pasar de una de las otras ediciones a Checkmk MSP, sigue la descripción de la actualización. Para una actualización a Checkmk MSP en entornos distribuidos, sólo se puede utilizar la actualización offline.
Tras una actualización, todos los componentes compatibles de Checkmk se asignan a Provider. Ahora tienes a tu disposición todas las funciones para crear clientes y asignarles sites, usuarios, etc.
Presta atención a las posibles dependencias que puedan resultar de una configuración existente y, en consecuencia, asigna también al cliente los elementos correctos de los demás componentes de Checkmk antes de activar la asignación a un site.
Importante: Debe transferirse al menos un usuario al site del cliente. No importa si se trata de un usuario global que se replica a todos los sites o si es un usuario específico del cliente.
En el capítulo siguiente encontrarás más información al respecto.
5. Configuración
5.1. Crear clientes
Puedes crear uno de tus clientes en un solo paso: En Setup > Users > Customers, selecciona el botón Add customer y asígnale un ID único, así como el nombre tal y como debe aparecer en Checkmk. Después de guardar, se habrá creado tu primer cliente en Checkmk:
Como puedes ver, el proveedor también es tratado como cliente y, por tanto, ya ha sido creado como Provider. Esta asignación no se puede borrar.
5.2. Asignación de sites
Una vez que has creado un cliente, el siguiente paso es vincular los componentes correspondientes en Checkmk a este cliente. El site central, al que todos los demás sites del cliente envían sus datos, también se denomina site proveedor. La separación de datos sólo funciona si creas un site distinto para cada cliente y lo conectas a tu site proveedor. En este caso, la configuración difiere en un único punto: en Basic settings introduces el Customer, que creaste anteriormente, además del ID y el alias:
Como el proveedor también es tratado como un cliente, Checkmk siempre sabe qué host pertenece a cada cliente en función de su asignación a un site concreto.
 |
Puedes configurar el Global settings para un site de cliente como de costumbre a través de la configuración global específica del site. |
5.3. Otras asignaciones
Además del site en sí, también puedes asignar otros elementos del Setup a un cliente, como ya se ha mencionado anteriormente. Un elemento se asigna directamente a un cliente. Alternativamente, también puedes hacer que un usuario o una contraseña estén disponibles para todos con la entrada Global. Aquí tienes un ejemplo de asignación de un usuario:
La asignación se realiza siempre a través de las propiedades del elemento correspondiente utilizando la opción Customer. Los ajustes globales específicos del site quedan excluidos de esta asignación.
Características especiales de la Consola de eventos
En la Consola de eventos puedes asignar a un cliente tanto reglas individuales como paquetes de reglas completos. Es importante tener en cuenta que la herencia es siempre obligatoria para los paquetes de reglas. A diferencia de lo que ocurre con las carpetas, no puede ser sobrescrita por las reglas individuales. De esta forma, siempre puedes estar seguro de que la asignación está garantizada para cada regla.
Si un paquete de reglas no está asignado a un cliente, también puedes asignar las reglas individuales a un cliente.
5.4. Componentes no personalizables
Todos los componentes que no se han mencionado en el capítulo anterior no se pueden asignar a clientes individuales. No obstante, hay que decir algunas palabras sobre varios componentes para llamar la atención sobre características especiales. El incumplimiento de estas notas puede suponer un riesgo moderado para la seguridad.
Tags del host
Lo mismo se aplica a los tags del host: no deben contener ninguna información confidencial, ya que los tags se distribuyen a todos los sites.
Notificaciones
Las reglas para las notificaciones suelen contener grupos de contacto y condiciones muy específicas en las que debe activarse y enviarse la notificación. Como estas reglas también se distribuyen a todos los sites, no incluyas nombres explícitos de host y servicios, direcciones de contacto ni ningún otro dato confidencial.
Personalizaciones para usuarios globales
Ten en cuenta que todas las personalizaciones realizadas para un usuario global se transfieren a todos los sites del cliente. Por tanto, los usuarios globales no son adecuados para vistas especiales, gráficos definidos por el usuario o marcadores, ya que pueden contener datos sensibles específicos del cliente. Por tanto, debes utilizar los usuarios globales sólo para casos excepcionales y no para tareas habituales y cotidianas.
5.5. Gestión de certificados
Los puntos mencionados en el capítulo anterior, como las notificaciones con grupos de contacto o tags del host, sólo pueden revelar información sobre las estructuras organizativas de otros clientes.
La situación es distinta con la distribución de certificados raíz de CA ("autoridad de certificación"): si un certificado de CA destinado al cliente A se distribuyera al cliente B, existiría el riesgo de que empleados malintencionados del cliente A pudieran llevar a cabo un ataque de máquina en el medio a la comunicación cifrada del cliente B. Por este motivo, los certificados de CA almacenados con la configuración global Trusted certificate authorities for SSL no se transmiten a los sites remotos.
La forma correcta de configurar certificados de CA específicos del cliente es introducirlos en la configuración global específica del site de los sites remotos del cliente.
6. Diferencias de los componentes en detalle
6.1. Interfaz de configuración
Puedes acceder a una vista de tabla para gestionar clientes en Setup > Users > Customers.
Cuando configures los elementos que se pueden asignar a los clientes, dispondrás de un campo adicional Customer.
Estas funciones se describen a modo de ejemplo en el capítulo de configuración.
6.2. Interfaz de monitorización
Dashboard (panel de control)
Una novedad en Main dashboard es el dashlet Customers, que se encuentra a la izquierda de los problemas de servicio:
Cuando seleccionas un cliente, aparece una vista en la que se enumeran todos sus host. Por tanto, esta vista de tabla funciona como la vista All hosts, con la diferencia de que en este caso sólo se muestran los elementos de un cliente concreto.
Barra lateral
Para la barra lateral, en el site central está el snap-in Customers, que funciona de la misma manera que el snap-in de aspecto similar Site status. Aquí puedes mostrar el estado de los sites para los clientes individuales, y también haciendo clic en el estado ocultar clientes específicos de, o mostrarlos en la vista.
Construir y filtrar vistas
Por supuesto, también puedes utilizar los filtros y conjuntos de datos que se utilizan para el dashlet y el snap-in para tus propias vistas. Por un lado, el filtro Site se ha ampliado para personalizar las vistas:
Por otro lado, también puedes crear vistas completamente nuevas basadas en uno o todos los clientes. Para ello, selecciona All customers como fuente de datos:
