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. |
Questo articolo sarà completato nel prossimo futuro per fornire una panoramica centrale su tutti gli aspetti delle misure di sicurezza implementate in Checkmk e sugli aiuti per migliorare ulteriormente la sicurezza.
Prima le buone notizie: Sin dall'inizio Checkmk ha utilizzato un'architettura che tiene conto delle esigenze di sicurezza e, laddove possibile, le applica alle sue impostazioni standard. Ci sono tuttavia aspetti in cui è necessario l'intervento dell'utente, ad esempio quando è necessario generare o importare chiavi o certificati.
1. Uscita degli agenti
Dalla versione 2.1.0, Checkmk offre la crittografia TLS per la comunicazione tra il server e gli agenti su host Linux e Windows. Informazioni dettagliate su questa comunicazione sono contenute nei seguenti articoli:
Tuttavia, in alcuni ambienti non è possibile impostare la crittografia TLS per i client Linux o Unix. In questi casi puoi utilizzare tunnel criptati, ad esempio con SSH:
2. Comunicazione HTTP(S)
In molti punti di Checkmk la comunicazione avviene tramite HTTP. Questo vale per la comunicazione interna e per le configurazioni come il monitoraggio distribuito. Passa a HTTPS dove possibile:
3. Controllo degli accessi
Checkmk supporta connessioni a diversi protocolli di autenticazione ed è anche in grado di applicare l'autenticazione a due fattori per una sicurezza ancora maggiore:
4. Log
Il file di log security.log facilita il rilevamento degli eventi rilevanti per la sicurezza. Qui vengono registrati eventi appartenenti alle categorie dell'autenticazione, dell'amministrazione degli utenti, dei servizi (es. l'avvio e l'arresto dei siti) e degli errori delle applicazioni. Puoi trovare questo file di log nella directory del sito e di seguito sono riportati alcuni esempi di voci di log tipiche:
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"}}Ogni riga è strutturata come segue:
Data e ora (ora locale) in cui è stata creata la voce di log.
Dominio di sicurezza (es.
cmk_security.auth) e ID del processo.Il messaggio stesso come riassunto (
summary) e in dettaglio (details), ciascuno in formato JSON. Il contenuto dei dettagli varia a seconda del dominio di sicurezza.
Si noti che il contenuto del file di log potrebbe cambiare in futuro, ad esempio a causa dell'aggiunta di altri domini di sicurezza, di eventi registrati o delle informazioni fornite nei dettagli.