Usuarios, roles y permisos

La página de gestión de usuarios se encuentra en Setup > Users > Users. En un sitio recién creado, esta página tiene este aspecto (en la imagen solo se han omitido algunas columnas de la tabla):

La imagen de arriba muestra todos los usuarios que se crearon automáticamente al crear el sitio: Un usuario de automatización, seguido del usuario único (cmkadmin) para el inicio de sesión interactivo con contraseña. Con la Appliance Checkmk, este usuario puede tener un nombre diferente, ya que tú mismo defines su nombre y contraseña. Este usuario cmkadmin tiene las siguientes propiedades:

El formulario para crear un nuevo usuario (en ) o realizar la edición de uno ya existente (en ) se divide en cinco secciones. La primera sección trata sobre la identidad.

Como siempre en Checkmk, el ID de un conjunto de datos (Username) no se puede cambiar posteriormente. Se utiliza para iniciar sesión y también como clave interna en todos los archivos y estructuras de datos.

La dirección de correo electrónico es opcional y solo es necesaria si el usuario va a ser un contacto al que se le notificará por correo electrónico (se requiere configuración SMTP). Del mismo modo, el campo Pager address está pensado para notificaciones por SMS o sistemas similares. Si escribes tus propios scripts de notificación, puedes acceder a los valores de estos campos y utilizarlos para cualquier propósito.

Con Monitored sites puedes restringir opcionalmente a cuáles de los sitios existentes se puede acceder. Esto resulta especialmente práctico en entornos muy grandes, como una monitorización distribuida con cientos de sitios. Si un usuario solo necesita un número determinado de estos sitios para sus hosts, la GUI solo se pondrá en contacto con los sitios seleccionados para configurar las vistas de tabla, lo que a su vez mejora considerablemente el rendimiento.

Este cuadro es para el inicio de sesión y la autorización. La opción «Automation secret for machine accounts» está pensada para cuentas que acceden a Checkmk a través de HTTP/HTTPS y se autentican mediante la URL. A continuación te mostraremos cómo hacerlo.

En cuanto a los roles, debes seleccionar al menos uno. En teoría, podrías asignar varios roles a un usuario, y este obtendría entonces los derechos de todos esos roles. Sin embargo, con los roles predefinidos, esto no tendría mucho sentido.

Si bloqueas a los usuarios con la opción «disable the login to this account», aparecerán en la tabla con el icono «». Ya no podrán iniciar sesión, pero seguirán estando en el sistema. Si un usuario es un contacto, las notificaciones no se verán afectadas y el usuario seguirá recibiendo correos electrónicos, etc. Si el usuario estaba conectado en el momento del bloqueo, se le cerrará la sesión automáticamente.

En cuanto asignes a un usuario a uno o más grupos de contactos, ese usuario se convierte en un contacto. Cuando se crea un nuevo site, también se crea el grupo de contactos Everything, que siempre contiene todos los hosts y todos los servicios. Un usuario de este grupo será entonces automáticamente responsable de todos los hosts y servicios.

En la caja «Notifications», puedes usar la opción «Receive fallback notifications» para especificar que este contacto reciba notificaciones cuando no se aplique ninguna regla de notificación.

Los usuarios también pueden cambiar ellos mismos todos los ajustes de esta caja a través de User > Edit profile (excepto con el rol de Guest user). Aparte de la selección del idioma de la interfaz, estos ajustes rara vez son necesarios. Como siempre, puedes encontrar más detalles en la ayuda en línea.

Los usuarios también pueden personalizar ellos mismos la configuración de la interfaz a través de User > Edit profile. Es especialmente interesante la opción «Show more / Show less» para determinar si Checkmk debe mostrar más o menos información en la interfaz. Si siempre quieres verlo todo, puedes forzarlo aquí con «Enforce show more».

Los grupos de contactos son el enlace entre los hosts y los servicios, por un lado, y los contactos, por otro. Cada grupo de contactos representa una responsabilidad sobre un área específica de tu entorno TI. Por ejemplo, el grupo de contactos «SAP» podría incluir a todas las personas que mantienen los sistemas SAP y estar asignado a todos los hosts y servicios que prestan dichos servicios en este entorno.

Puedes gestionar los grupos de contactos a través de Setup > Users > Contact groups. La siguiente imagen muestra este módulo con tres grupos de contactos creados manualmente:

Crear un nuevo grupo es muy sencillo. Como siempre, el ID es permanente y el alias es un nombre de visualización que puedes cambiar más adelante en cualquier momento:

El nuevo grupo de contactos está vacío en dos aspectos: no contiene ni contactos, ni hosts, ni servicios. La asignación de grupos de contactos a los contactos se realiza a través de los perfiles de usuario, como ya has visto al editar el usuario.

Hay dos métodos para incluir hosts en grupos de contactos: a través de carpetas y a través de reglas. También puedes combinar ambos métodos. En este caso, se asignará al host una agregación de los respectivos grupos de contactos.

No siempre tiene sentido que un servicio esté en los mismos grupos de contacto que su host. Por lo tanto, puedes usar el conjunto de reglas «Assignment of services to contact groups» (Asignar grupos de contacto al servicio), independientemente de los grupos de contacto del host. Se aplican las siguientes reglas:

En un entorno sencillo, por lo tanto, basta con asignar grupos de contacto solo a los hosts. En cuanto necesites una mayor diferenciación, también puedes crear reglas para los servicios.

Puedes comprobar si has configurado correctamente todas las reglas y carpetas consultando los detalles de un host o servicio en el entorno de monitorización. Allí encontrarás las entradas Host contact groups y Host contacts (o Service contact groups y Service contacts, respectivamente), que forman una lista de las asignaciones reales para este objeto:

El hecho de que los usuarios normales (el rol Normal monitoring user) solo vean aquellos objetos de los que son contacto cobra mayor importancia cuanto más grande es tu entorno de monitorización. Esto no solo proporciona una vista general ordenada, sino que también evita que los usuarios intervengan donde no les corresponde.

Como administrador (el rol «Administrator»), por supuesto, siempre puedes verlo todo. Esto se controla mediante el permiso «See all host and services». En tu configuración personal, en Visibility of hosts/services, encontrarás la checkbox «Only show hosts and services the user is a contact for». Con esto, puedes renunciar voluntariamente a ver todo y mostrar solo los hosts y servicios para los que eres contacto. Esta opción está pensada para roles duales, es decir, para alguien que es tanto administrador como usuario normal.

El rol «Guest user» está preconfigurado para que sus usuarios también puedan verlo todo. Aquí están desactivados los ajustes y las intervenciones.

Para los usuarios normales, la visibilidad en el entorno de monitorización está implementada de tal manera que los hosts y servicios para los que no eres contacto parecen ni siquiera existir en el sistema. Entre otras cosas, los siguientes elementos tienen en cuenta la visibilidad:

Como hemos mostrado anteriormente, es posible que seas un contacto para un host, pero no para todos sus servicios. No obstante, en tal caso podrás ver todos los servicios del host en la GUI.

Esta excepción está configurada por defecto porque suele ser útil. En la práctica, esto significa, por ejemplo, que el compañero responsable del host en cuestión también puede ver cualquier servicio conectado a ese host, ¡aunque no reciba ninguna notificación sobre dichos servicios!

Si no te gusta este enfoque, puedes cambiarlo en las ediciones comerciales a través de Global settings > Monitoring core > Authorization settings. Si allí cambias la configuración «Services» a «Strict - Visible if user is contact for the service», los usuarios solo podrán ver los servicios si han sido asignados directamente como contacto para ese servicio.

Por cierto, todo esto no tiene nada que ver con el hecho de que un servicio herede los grupos de contactos de su host si no se le han asignado grupos de contactos propios, ya que en ese caso tú serías un contacto del servicio y, por lo tanto, recibirías sus notificaciones.

La segunda opción en la configuración global de Authorization settings se refiere a los grupos de hosts y servicios. Normalmente puedes ver un grupo siempre que puedas ver al menos un elemento del grupo; sin embargo, el grupo parecerá entonces como si solo contuviera los elementos que son visibles para ti.

Si cambias a «Strict - Visible if all members are visible», se ocultarán todos los grupos en los que no seas contacto de al menos un host o servicio.

Ten en cuenta que estos dos ajustes de visibilidad no influyen en las notificaciones.

Checkmk siempre asigna permisos a los usuarios a través de roles, nunca directamente. Un rol no es más que una lista de permisos. Es importante que entiendas que los roles definen el nivel de permisos y no hacen referencia a ningún host o servicio. Para eso están los grupos de contacto.

Checkmk incluye los siguientes roles predefinidos, que nunca se pueden eliminar, pero se pueden personalizar como quieras:

Los roles se gestionan a través de Setup > Users > Roles & permissions:

Por cierto, al crear un nuevo site de Checkmk, solo se crea un usuario (cmkadmin) con el rol Administrator para el inicio de sesión en la interfaz de Checkmk. Los demás roles posibles no se utilizarán por el momento. Si necesitas un usuario invitado, debes crearlo tú mismo.

Como de costumbre, el te lleva al modo de edición de un rol:

Puedes averiguar qué significan los distintos permisos (que se muestran aquí en extractos) en la ayuda en línea.

La particularidad aquí es que para cada permiso hay tres opciones: yes, no y default (yes) o default (no). Durante la instalación, todos los valores se establecen en default. Para la autorización en sí, no importa si has establecido yes o default (yes). Sin embargo, es posible que la instalación de una nueva versión de Checkmk cambie un valor por defecto (aunque esto ocurra muy raramente). Una configuración que hayas establecido explícitamente no se vería afectada por la instalación.

Además, este principio te permite reconocer muy rápidamente en qué aspectos tu instalación de Checkmk podría haberse desviado del estándar.

Quizás te sorprenda que no haya ningún botón para crear un nuevo rol. Hay una razón deliberada para ello. Los nuevos roles se crean derivándolos de los ya existentes mediante Clone. El nuevo rol no se crea simplemente como una copia, sino que conserva su relación con el rol original (Based on role):

Esta conexión tiene una función importante. Porque todos los permisos del rol clonado que no se hayan establecido explícitamente (es decir, que sigan configurados como default) se heredarán del rol de origen. Los cambios posteriores en el rol de origen se trasladarán al nuevo rol clonado. Esto resulta muy práctico si piensas en la cantidad de permisos que podría tener el rol original. Con una simple copia, podrías perder fácilmente la pista de qué es lo que realmente tiene de especial el rol que has definido para ti mismo.

Esta función de derivación también resuelve otro problema: Dado que seguimos desarrollando Checkmk, se añaden continuamente nuevos permisos. Cada vez que lo hacemos, decidimos en cuál de los tres roles Administrator, Normal monitoring user y Guest user debe incluirse el nuevo permiso. Dado que cada uno de tus propios roles se deriva de uno de los roles predefinidos, el nuevo permiso se preconfigura automáticamente con un valor razonable. Sería muy poco práctico si, por ejemplo, definieras tu propio rol de usuario y siempre faltaran allí los nuevos permisos. Tendrías que adaptar tu rol para cada nueva función, para que tus usuarios pudieran utilizarlas.

Si quieres comparar los permisos de cada rol, puedes utilizar la vista de tabla, a la que puedes acceder a través de Setup > Users > Roles & permissions > Roles > Permission matrix. Esta opción del menú muestra la siguiente vista de tabla, en la que no solo puedes comparar los permisos de cada rol, sino también ver dónde se han establecido explícitamente los permisos () o se han eliminado ().

Al instalar Checkmk, se crea un administrador por defecto, como ya se ha mencionado anteriormente. Este administrador se llama cmkadmin. Ahora puedes seguir trabajando con este administrador como desees, aunque es posible que no quieras utilizar este administrador predeterminado. Por ejemplo, debido a normativas internas de la empresa, porque quieres definir varios administradores o para cumplir con recomendaciones de seguridad como el Estándar de Verificación de Seguridad de Aplicaciones (ASVS) de OWASP.

En primer lugar, un administrador es un usuario como cualquier otro. Por lo tanto, se crea tal y como se describe en el capítulo «Administración de usuarios» del entorno de configuración. Sin embargo, los derechos que se asignan al usuario a través del rol seleccionado son decisivos.

Selecciona el rol «Administrator» al crear el usuario. El resto de ajustes para el administrador también se realizan según tus preferencias personales o las especificaciones internas de la empresa.

Al realizar la conexión de Checkmk a otros sistemas, a menudo se desea automatizar ciertas actividades que normalmente se realizan a través de la GUI. Algunos ejemplos son:

En tales situaciones, el software externo debe poder recuperar automáticamente ciertas URL de la interfaz de Checkmk. Esto, por supuesto, plantea la cuestión de cómo inicia sesión el usuario. La forma habitual a través del diálogo de inicio de sesión es engorrosa y requiere recuperar varias URL seguidas y guardar una cookie.

Para simplificar esto, Checkmk ofrece el concepto de usuarios de automatización. Estos usuarios son exclusivamente para el control remoto y no permiten un inicio de sesión normal a través de la GUI. La autenticación se realiza aquí mediante la autenticación básica HTTP.

En cada sitio de Checkmk ya hay un usuario de automatización configurado: para registrar el agente Checkmk en el servidor Checkmk para la transferencia de datos cifrada con TLS. Para otras tareas, puedes crear usuarios de automatización adicionales, normalmente con el rol «administrator». Se crea un usuario de automatización igual que un usuario normal, pero no se le asigna una contraseña normal, sino una contraseña de automatización (Automation secret). Puedes hacer que esta contraseña se cree automáticamente con el cubo «»:

Un usuario de automatización tiene un rol igual que un usuario normal y también puede ser un contacto. Esto significa que puedes restringir los permisos y la visibilidad de los hosts y servicios según sea necesario.

Para la recuperación automática de páginas web, introduce el encabezado de la autenticación HTTP Basic, que básicamente tiene este aspecto: Authorization: Basic 1234567890abcdef. La cadena de caracteres es la forma codificada en Base64 de username:password.

Aquí tienes un ejemplo de cómo recuperar una vista de tabla en formato JSON con el usuario de automatización automation y su contraseña de automatización; la codificación Base64 la realiza curl:

Si el script que recupera la URL se ejecuta directamente en el sitio de monitorización, puedes leer la contraseña de automatización del usuario directamente desde el sistema de archivos. Esto no es una vulnerabilidad de seguridad, sino que está pensado para que así sea: Puedes escribir scripts de automatización que no necesiten contener la contraseña de automatización ni un archivo de configuración. Para ello, lee el archivo ~/var/check_mk/web/myuser/automation.secret:

Puedes guardar fácilmente el contenido de este archivo en una variable del shell, por ejemplo, para poder leerlo más tarde con un script:

Si tienes que gestionar un entorno de monitorización algo más grande, te interesará involucrar a otros administradores en la configuración y, sobre todo, en la gestión de hosts y servicios. Para mantener el control sobre quién puede realizar cambios y qué se les permite hacer, y para que nadie se entrometa en el trabajo de los demás, puedes asignar permisos para la configuración de Checkmk basándote en carpetas.

El primer paso para ello es que tus compañeros administradores trabajen con sus propios usuarios basados en el rol «Normal monitoring user».

Este rol básicamente tiene autorización para el entorno de configuración, pero con algunas restricciones importantes:

Mientras no hayas publicado ninguna carpeta o paquete BI, esto significa que los usuarios con el rol «Normal monitoring user» no pueden realizar ningún cambio inicialmente. El sencillo menú «Setup» tiene este aspecto para los usuarios de monitorización normales:

Un usuario recibe la autorización para crear, editar y eliminar hosts a través de grupos de contacto. El procedimiento es el siguiente:

El siguiente ejemplo muestra las propiedades de una carpeta en la que todos los usuarios del grupo de contacto «Linux» pueden gestionar hosts. Se ha activado la opción para permitir esto también en las subcarpetas.

Tú decides si quieres incluir automáticamente los hosts en el grupo de contactos. En este ejemplo, la opción «Add these groups as contacts to all hosts in this folder» no se ha activado y los hosts no se añadirán al grupo de contactos «Linux». Esto significa que, en el entorno de monitorización, no serán visibles para el grupo de contactos «Linux» (a menos que una regla se encargue de ello). Así pues, como puedes ver, la visibilidad (y la responsabilidad en la monitorización) y la autorización para el entorno de configuración se pueden regular por separado.

La seguridad es una prioridad hoy en día. Por eso, en algunas empresas hay directrices generales sobre cómo gestionar las contraseñas. Checkmk ofrece varias opciones para aplicar estas normas. Algunas de ellas las encontrarás en Global settings > User management > Password policy for local accounts:

La primera opción, «Minimum password length», sirve para garantizar la calidad de la contraseña.

Para la segunda opción Number of character groups to use hay un total de cuatro grupos de caracteres:

Si introduce aquí «4», la contraseña deberá contener al menos un carácter de cada uno de los grupos anteriores. Con «2», al menos se garantiza que la contraseña no esté compuesta, por ejemplo, solo por letras minúsculas. Estos ajustes se checkan cada vez que se cambia la contraseña.

La tercera opción, «Maximum age of passwords», obliga al usuario a cambiar su contraseña a intervalos regulares. Cuando llegue el momento, al acceder a la página siguiente se le mostrará al usuario el siguiente mensaje:

Los usuarios solo podrán continuar después de cambiar su contraseña.

Puedes exigir un cambio de la contraseña inicial en el primer inicio de sesión. Esto se hace con la opción «Enforce change: Change password at next login or access» en la sección «Security» de las propiedades del usuario correspondiente.

En «Global settings > User management» encontrarás más ajustes globales que regulan los inicios de sesión de los usuarios.

Para mejorar la seguridad de tus sitios Checkmk, Checkmk ofrece la función de autenticación de dos factores para cada usuario. Esta autenticación de dos factores se basa en el estándar de internet FIDO2/WebAuthn. La autenticación se basa convencionalmente en el conocimiento (una contraseña) y la posesión (un autenticador).

Puedes utilizar cualquier dispositivo compatible con FIDO2 que sea compatible con tu navegador y sistema operativo. Los tokens USB o NFC, como el YubiKey, son los más utilizados. Como alternativa, es posible utilizar aplicaciones de autenticación (por ejemplo, en el smartphone) que generan una contraseña de un solo uso basada en el tiempo (TOTP).

En caso de emergencia, también puedes cambiar una contraseña a través de la línea de comandos. Esto te salva en una situación en la que hayas perdido la contraseña de cmkadmin. El requisito previo es, por supuesto, que aún sea posible iniciar sesión como usuario de Linux en el servidor Checkmk y que puedas convertirte en usuario del site con omd su mysite.

Las contraseñas se almacenan en el archivo ~/etc/htpasswd, como ya se ha descrito anteriormente.

El cambio de contraseñas se realiza con el comando cmk-passwd. Esto no te pedirá la contraseña actual. cmk-passwd siempre elegirá un método de cifrado seguro para almacenar tus contraseñas en una versión actual de Checkmk. Actualmente, cmk-passwd utiliza bcrypt para ello. Las contraseñas sin cifrar o con un cifrado débil (por ejemplo, con MD5) no permiten el inicio de sesión en la GUI.