This article will be completed in the near future to provide a central overview on all aspects of security measures implemented in Checkmk and aids on further improving security.
First the Good News: Since its beginning Checkmk has used an architecture that considers security needs and — wherever possible — applies these to its standard settings. There are however aspects where user intervention is required, for example when keys or certificates have to be generated or imported.
 |
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. |
Este artículo se completará en un futuro próximo para proporcionar una visión general central sobre todos los aspectos de las medidas de seguridad implementadas en Checkmk y ayudas para seguir mejorando la seguridad.
Primero las Buenas Noticias: Desde sus inicios, Checkmk ha utilizado una arquitectura que tiene en cuenta las necesidades de seguridad y, siempre que es posible, las aplica a sus configuraciones estándar. Sin embargo, hay aspectos en los que se requiere la intervención del usuario, por ejemplo, cuando hay que generar o importar claves o certificados.
1. Salida del agente
Desde la versión 2.1.0, Checkmk ofrece encriptación TLS para la comunicación entre el servidor y los agentes en hosts Linux y Windows. En los siguientes artículos encontrarás información detallada sobre esta comunicación:
Sin embargo, hay algunos entornos en los que no se puede configurar el cifrado TLS para clientes Linux o Unix. En estos casos, puedes utilizar túneles cifrados, por ejemplo con SSH:
2. Comunicación HTTP(S)
En muchos lugares de Checkmk la comunicación se realiza a través de HTTP. Esto se aplica a la comunicación interna y a configuraciones como la monitorización distribuida. Cambia a HTTPS siempre que sea posible:
3. Control de acceso
Checkmk admite conexiones con varios protocolos de autenticación y también es capaz de aplicar la autenticación de dos factores para una seguridad aún mayor:
4. Registro
El archivo de registro security.log facilita la detección de eventos relevantes para la seguridad. Aquí se registran eventos de las categorías de autenticación, administración de usuarios, servicios (por ejemplo, el inicio y la detención de sitios) y errores de aplicación. Puedes encontrar este archivo de registro en el directorio del site, y a continuación se muestran algunos ejemplos de entradas de registro típicas:
2024-04-02 19:12:33,891 [cmk_security.service 269382] {"summary": "site stopped", "details": {}}
2024-04-03 08:55:46,480 [cmk_security.service 5652] {"summary": "site started", "details": {}}
2024-04-03 09:21:18,830 [cmk_security.auth 8798] {"summary": "authentication succeeded", "details": {"method": "login_form", "user": "cmkadmin", "remote_ip": "127.0.0.1"}}
2024-04-03 15:41:20,499 [cmk_security.user_management 8798] {"summary": "user created", "details": {"affected_user": "myuser", "acting_user": "cmkadmin"}}
2024-04-03 16:36:04,099 [cmk_security.auth 1882076] {"summary": "authentication failed", "details": {"user_error": "Incorrect username or password. Please try again.", "method": "login_form", "user": "myuser", "remote_ip": "127.0.0.1"}}
2024-04-03 18:19:05,640 [cmk_security.application_errors 1882076] {"summary": "CSRF token validation failed", "details": {"user": "cmkadmin", "remote_ip": "127.0.0.1"}}Cada línea está estructurada como sigue
Fecha y hora (hora local) en que se creó la entrada de registro.
Dominio de seguridad (por ejemplo,
cmk_security.auth) e ID del proceso.El mensaje en sí como resumen (
summary) y en detalle (details), cada uno en formato JSON. El contenido de los detalles varía en función del dominio de seguridad.
Ten en cuenta que el contenido del archivo de registro puede cambiar en el futuro, por ejemplo debido a la adición de dominios de seguridad adicionales, eventos registrados o la información proporcionada en los detalles.