Utenti, ruoli e permessi

La pagina di gestione degli utenti si trova all'indirizzo Setup > Users > Users. In un'istanza appena creata, questa pagina ha questo aspetto (nell'immagine sono state ridotte solo alcune colonne della tabella):

L'immagine sopra mostra tutti gli utenti che sono stati creati automaticamente al momento della creazione dell'istanza: Un utente automazione, seguito dall'utente singolo (cmkadmin) per il login interattivo con password. Con la Checkmk Appliance, questo utente può avere un nome diverso, poiché sei tu a definire il suo nome e la sua password. Questo utente cmkadmin ha le seguenti proprietà:

Il modulo per creare un nuovo utente (con ) o modificare un utente esistente (con ) è diviso in cinque sezioni. La prima sezione riguarda l'identità.

Come sempre in Checkmk, l'ID di un dataset (Username) non può essere modificato in seguito. Viene utilizzato per l'accesso e anche come chiave interna in tutti i file e le strutture di dati.

L'indirizzo e-mail è facoltativo ed è richiesto solo se l'utente deve diventare un contatto da avvisare via e-mail (è necessaria la configurazione SMTP). Allo stesso modo, il campo Pager address è destinato alle notifiche via SMS o sistemi simili. Se scrivi i tuoi script di notifica, puoi accedere ai valori in questi campi e usarli per qualsiasi scopo.

Con Monitored sites puoi, se vuoi, limitare l'accesso alle istanze esistenti. Questo è particolarmente utile per ambienti molto grandi, come un monitoraggio distribuito con centinaia di istanze. Se un utente ha bisogno solo di un certo numero di queste istanze per i suoi host, la GUI contatterà solo le istanze selezionate per configurare le visualizzazioni, il che a sua volta migliora notevolmente la performance.

Questa box serve per il login e l'autorizzazione. L'opzione "Automation secret for machine accounts" è pensata per gli account che accedono a Checkmk tramite HTTP/HTTPS e si autenticano tramite l'URL. Ti mostreremo come farlo qui sotto.

Per i ruoli, devi selezionarne almeno uno. In teoria potresti assegnare più ruoli a un utente, che otterrebbe così i diritti di tutti questi ruoli. Con i ruoli predefiniti, tuttavia, ciò avrebbe poco senso.

Se blocchi gli utenti con l'opzione "disable the login to this account", appariranno nella tabella con il simbolo "". Non potranno più effettuare il login, ma rimarranno comunque nel sistema. Se un utente è un contatto, le notifiche non ne risentiranno e l'utente continuerà a ricevere e-mail, ecc. Se l'utente era connesso al momento del blocco, verrà automaticamente disconnesso.

Non appena assegni un utente a uno o più gruppi di contatti, questo utente diventa un contatto. Quando viene creato un nuovo sito, viene creato anche il gruppo di contatti Everything, che contiene sempre tutti gli host e tutti i servizi. Un utente in questo gruppo sarà quindi automaticamente responsabile di tutti gli host e i servizi.

Nella box "Notifications", puoi usare l'opzione "Receive fallback notifications" per specificare che questo contatto riceverà le notifiche quando non si applica alcuna regola di notifica.

Gli utenti possono anche modificare autonomamente tutte le impostazioni in questa box tramite User > Edit profile (tranne che con il ruolo Guest user). A parte la selezione della lingua dell'interfaccia, queste impostazioni sono raramente necessarie. I dettagli si trovano come sempre nell'aiuto in linea.

Gli utenti possono anche personalizzare le impostazioni dell'interfaccia da soli utilizzando User > Edit profile. Di particolare interesse è l'opzione "Show more / Show less" per determinare se Checkmk debba mostrare più o meno informazioni nell'interfaccia. Se vuoi vedere sempre tutto, puoi forzare questa opzione qui con "Enforce show more".

I gruppi di contatti sono il collegamento tra host e servizi da un lato e i contatti dall'altro. Ogni gruppo di contatti rappresenta una responsabilità per un'area specifica nel tuo panorama IT. Ad esempio, il gruppo di contatti "SAP" potrebbe comprendere tutte le persone che gestiscono i sistemi SAP ed essere assegnato a tutti gli host e i servizi che forniscono tali servizi in questo ambiente.

Puoi gestire i gruppi di contatto tramite Setup > Users > Contact groups. La figura seguente mostra questo modulo con tre gruppi di contatto creati manualmente:

Creare un nuovo gruppo è semplicissimo. Come sempre, l’ID è permanente e l’alias è un nome visualizzato che puoi modificare in qualsiasi momento in seguito:

Il nuovo gruppo di contatti è vuoto sotto due aspetti: non contiene né contatti né host o servizi. L'assegnazione dei gruppi di contatti ai contatti avviene tramite i profili utente, come hai già visto durante la modifica dell'utente.

Esistono due metodi per includere gli host nei gruppi di contatti: tramite cartella e tramite regole. È anche possibile combinare entrambi i metodi. In questo caso, all'host verrà assegnata un'aggregazione dei rispettivi gruppi di contatti.

Non sempre ha senso che un servizio si trovi negli stessi gruppi di contatto del suo host. Puoi quindi utilizzare il set di regole "Assignment of services to contact groups" (Assegna a tutti i gruppi di contatto dell'host) indipendentemente dai gruppi di contatto dell'host. Si applicano le seguenti regole:

In un ambiente semplice, è quindi sufficiente assegnare i gruppi di contatto solo agli host. Non appena hai bisogno di una maggiore differenziazione, puoi anche creare regole per i servizi.

Puoi verificare se hai configurato correttamente tutte le regole e le cartelle controllando i dettagli di un host o di un servizio nell'ambiente di monitoraggio. Lì troverai le voci Host contact groups e Host contacts (o rispettivamente Service contact groups e Service contacts), che elencano le assegnazioni effettive per questo oggetto:

Il fatto che gli utenti normali (ruolo Normal monitoring user) vedano solo gli oggetti di cui sono contatti è tanto più importante quanto più grande è il tuo ambiente di monitoraggio. Questo non solo offre una panoramica chiara, ma impedisce anche agli utenti di intervenire dove non dovrebbero.

In qualità di amministratore (ruolo Administrator) hai ovviamente sempre la possibilità di vedere tutto. Questo è controllato tramite il permesso See all host and services. Nelle tue impostazioni personali, all'indirizzo Visibility of hosts/services, troverai la checkbox Only show hosts and services the user is a contact for. In questo modo puoi rinunciare volontariamente alla visualizzazione completa e visualizzare solo gli host e i servizi per i quali sei un contatto. Questa opzione è pensata per i ruoli duali, ovvero per chi è sia amministratore che utente normale.

Il ruolo "Guest user" è preimpostato in modo che i suoi utenti possano vedere tutto. Qui gli interventi o le impostazioni personali sono disabilitati.

Per gli utenti normali, la visibilità nell'ambiente di monitoraggio è implementata in modo tale che gli host e i servizi per i quali non sei un contatto non sembrino nemmeno esistere nel sistema. Tra le altre cose, i seguenti elementi tengono conto della visibilità:

Come abbiamo mostrato sopra, è possibile che tu sia un contatto per un host ma non per tutti i suoi servizi. Tuttavia, in tal caso potrai vedere tutti i servizi dell'host nella GUI.

Questa eccezione è predefinita perché solitamente è utile. In pratica, ciò significa, ad esempio, che il collega responsabile dell'host effettivo può vedere anche tutti i servizi collegati a quell'host, ma non riceve alcuna notifica relativa a tali servizi!

Se non ti piace questo approccio, puoi modificarlo nelle edizioni commerciali tramite Global settings > Monitoring core > Authorization settings. Se lì cambi l'impostazione "Services" in "Strict - Visible if user is contact for the service", gli utenti potranno vedere i servizi solo se sono stati assegnati direttamente come contatto per quel servizio.

A proposito, tutto questo non ha nulla a che vedere con il fatto che un servizio erediti i gruppi di contatti del suo host se al servizio non sono stati assegnati gruppi di contatti propri, poiché in tal caso saresti un contatto per il servizio e riceveresti quindi le sue notifiche.

La seconda opzione nell'Authorization settingse globale riguarda i gruppi di host e di servizi. Normalmente puoi vedere un gruppo ogni volta che riesci a vedere almeno un elemento del gruppo, tuttavia il gruppo apparirà come se contenesse solo gli elementi che sono visibili a te.

Passando all'Strict - Visible if all members are visiblee si nasconderanno tutti i gruppi per i quali non sei un contatto per almeno un host o un servizio.

Tieni presente che queste due impostazioni di visibilità non hanno alcuna influenza sulle notifiche.

Checkmk assegna sempre i permessi agli utenti tramite ruoli, mai direttamente. Un ruolo non è altro che un elenco di permessi. È importante capire che i ruoli definiscono il livello di permessi e non fanno riferimento a host o servizi specifici. A questo servono i gruppi di contatto.

Checkmk include i seguenti ruoli predefiniti, che non possono essere eliminati, ma possono essere personalizzati a piacere:

La gestione dei ruoli avviene tramite Setup > Users > Roles & permissions:

A proposito, quando si crea una nuova istanza Checkmk, viene creato un solo utente (cmkadmin) con il ruolo Administrator per il login all'interfaccia di Checkmk. Gli altri ruoli possibili non verranno utilizzati per il momento. Se hai bisogno di un utente ospite, devi crearlo tu stesso.

Come al solito, l' ti porta alla modalità di modifica di un ruolo:

Puoi scoprire cosa significano i vari permessi (qui mostrati in estratti) dall'aiuto in linea.

La particolarità in questo caso è che per ogni permesso ci sono tre opzioni: yes, no e default (yes) o default (no). Al momento dell'installazione tutti i valori sono impostati su default. Ai fini dell'autorizzazione stessa non fa differenza se hai impostato yes o default (yes). È tuttavia possibile che l'installazione di una nuova versione di Checkmk possa modificare un valore predefinito (anche se questo accade molto raramente). Un'impostazione che hai effettuato esplicitamente non sarebbe quindi influenzata dall'installazione.

Inoltre, questo principio ti permette di riconoscere molto rapidamente dove la tua installazione di Checkmk potrebbe essersi discostata dallo standard.

Potresti essere sorpreso dal fatto che non ci sia un pulsante per creare un nuovo ruolo. C'è una ragione precisa per questo. Si creano nuovi ruoli derivandoli da quelli esistenti utilizzando Clone. Il nuovo ruolo non viene semplicemente creato come copia, ma mantiene la sua relazione con il ruolo originale (Based on role):

Questa connessione ha una funzione importante. Infatti, tutti i permessi del ruolo clonato che non sono impostati esplicitamente (cioè sono ancora impostati su default) verranno ereditati dal ruolo di origine. Le modifiche successive al ruolo di origine verranno trasferite al nuovo ruolo clonato. Questo è molto pratico se pensi a quanti permessi potrebbero esserci nel ruolo originale. Con una semplice copia, potresti facilmente perdere di vista ciò che è effettivamente speciale nel ruolo che hai definito per te stesso.

Questa funzione di derivazione risolve anche un altro problema: Dato che continuiamo a sviluppare Checkmk, vengono aggiunti continuamente nuovi permessi. Ogni volta decidiamo quindi in quale dei tre ruoli Administrator, Normal monitoring user e Guest user debba essere inserito il nuovo permesso. Dato che ciascuno dei tuoi ruoli deriva da uno dei ruoli predefiniti, il nuovo permesso viene automaticamente preimpostato su un valore sensato. Sarebbe molto poco pratico se, ad esempio, definissi il tuo ruolo utente e lì mancassero sempre i nuovi permessi. Dovresti adattare il tuo ruolo per ogni nuova funzionalità, affinché gli utenti possano utilizzarle.

Se vuoi confrontare i permessi nei singoli ruoli, puoi avvalerti della visualizzazione a matrice, accessibile tramite Setup > Users > Roles & permissions > Roles > Permission matrix. Questa opzione di menu crea la seguente visualizzazione, in cui non solo puoi confrontare i permessi dei singoli ruoli, ma anche vedere dove i permessi sono stati impostati esplicitamente () o rimossi ().

Durante l’installazione di Checkmk, viene creato un amministratore di default — come già menzionato sopra. Questo amministratore si chiama cmkadmin. Ora puoi continuare a lavorare con questo amministratore come preferisci, ma potresti non voler utilizzare questo amministratore predefinito. Ad esempio, a causa di regolamenti interni all’azienda, perché vuoi definire più amministratori, o per rispettare raccomandazioni di sicurezza come lo standard OWASP Application Security Verification Standard (ASVS).

Innanzitutto, un amministratore è un utente come tutti gli altri. Viene quindi creato come descritto nel capitolo Gestione utenti nell'ambiente di configurazione. Tuttavia, sono determinanti i diritti assegnati all'utente tramite il ruolo selezionato.

Seleziona il ruolo "Administrator" quando crei l'utente. Anche tutte le altre impostazioni vengono effettuate per l'amministratore in base alle preferenze personali o alle specifiche interne dell'azienda.

Quando si effettua la connessione di Checkmk ad altri sistemi, spesso si desidera automatizzare alcune attività che normalmente avvengono tramite la GUI. Alcuni esempi sono:

In queste situazioni, il software esterno deve essere in grado di recuperare automaticamente determinati URL dall'interfaccia di Checkmk. Questo ovviamente solleva la questione di come l'utente effettui il login. Il metodo tradizionale tramite la finestra di dialogo di login è macchinoso e richiede il recupero di diversi URL in successione e il salvataggio di un cookie.

Per semplificare questo processo, Checkmk offre il concetto di utenti automazione. Questi utenti sono destinati esclusivamente al controllo remoto e non consentono un normale login tramite la GUI. L'autenticazione avviene tramite Autenticazione semplice HTTP.

In ogni sito Checkmk è già configurato un utente automazione: serve per registrare l'agente Checkmk sul server Checkmk per il trasferimento dei dati crittografati con TLS. Per altre attività, puoi creare ulteriori utenti automazione, solitamente con il ruolo "administrator". Si crea un utente automazione come un utente normale, ma non si assegna una password normale, bensì una password di automazione (Automation secret). Puoi far creare automaticamente questa password con il cubo "":

Un utente automazione ha un ruolo proprio come un utente normale e può anche essere un contatto. Ciò significa che puoi limitare i permessi e la visibilità di host e servizi secondo necessità.

Per il recupero automatico delle pagine web, inserisci quindi l'intestazione dell'Autenticazione semplice HTTP, che fondamentalmente ha questo aspetto: Authorization: Basic 1234567890abcdef. La stringa di caratteri è la forma codificata in Base64 di username:password.

Ecco un esempio di recupero di una visualizzazione in formato JSON con l'utente automazione automation e la sua password di automazione — la codifica Base64 viene eseguita da curl:

Se lo script che recupera l'URL viene eseguito direttamente nel sito di monitoraggio, puoi leggere la password di automazione dell'utente direttamente dal file system. Non si tratta di una vulnerabilità di sicurezza, ma è intenzionale: Puoi scrivere script di automazione che non devono contenere la password di automazione e non richiedono un file di configurazione. Per farlo, leggi il file ~/var/check_mk/web/myuser/automation.secret:

Puoi facilmente memorizzare il contenuto di questo file in una variabile nella shell, ad esempio in modo che possa essere letto in seguito con uno script:

Se hai un ambiente di monitoraggio piuttosto esteso da gestire, ti conviene coinvolgere altri amministratori nella configurazione e soprattutto nella gestione di host e servizi. Per mantenere il controllo su chi è autorizzato ad apportare modifiche e su cosa può fare, e per evitare che le persone si intralcino a vicenda, puoi assegnare i permessi per Checkmk Setup in base alle cartelle.

Il primo passo è far lavorare i tuoi colleghi amministratori con i propri utenti basati sul ruolo "Normal monitoring user".

Questo ruolo ha fondamentalmente l'autorizzazione per l'ambiente di configurazione, ma con alcune restrizioni importanti:

Finché non hai ancora rilasciato alcuna cartella o pacchetto BI, ciò significa che gli utenti con il ruolo "Normal monitoring user" non possono inizialmente apportare alcuna modifica. Il menu "Setup" (Configurazione) appare così per i normali utenti di monitoraggio:

Un utente riceve l'autorizzazione a creare, modificare e rimuovere host tramite i gruppi di contatto. La procedura è la seguente:

L'esempio seguente mostra le proprietà di una cartella in cui tutti gli utenti del gruppo di contatto "Linux" sono autorizzati a gestire gli host. L'opzione è stata attivata per consentire ciò anche nelle sottocartelle.

Sta a te decidere se includere automaticamente gli host nel gruppo di contatti. In questo esempio l'opzione "Add these groups as contacts to all hosts in this folder" non è stata impostata e gli host non verranno aggiunti al gruppo di contatti "Linux". Ciò significa che nell'ambiente di monitoraggio non saranno visibili al gruppo di contatti "Linux" (a meno che non ci sia una regola che se ne occupi). Quindi, come puoi vedere, la visibilità (e la responsabilità nel monitoraggio) e l'autorizzazione per l'ambiente di configurazione possono essere regolate separatamente.

La sicurezza è una priorità assoluta al giorno d'oggi. Per questo motivo, in alcune aziende esistono linee guida generali su come gestire le password. Checkmk offre diverse impostazioni per applicare tali impostazioni predefinite. Alcune di esse si trovano in Global settings > User management > Password policy for local accounts:

La prima opzione Minimum password length serve a garantire la qualità della password.

Per la seconda opzione Number of character groups to use ci sono in totale quattro gruppi di caratteri:

Se inserisci qui un "4", la password dovrà contenere almeno un carattere per ciascuno dei gruppi sopra indicati. Con un "2" si garantisce almeno che la password non sia composta, ad esempio, solo da lettere minuscole. Queste impostazioni vengono checkate ogni volta che si cambia la password.

La terza opzione "Maximum age of passwords" (Modifica password) obbliga l'utente a cambiare la propria password a intervalli regolari. Una volta giunto il momento, al prossimo accesso alla pagina verrà visualizzato il seguente messaggio:

Gli utenti potranno proseguire solo dopo aver modificato la password.

Puoi richiedere la modifica della password iniziale al primo login. Questo si fa con l'opzione "Enforce change: Change password at next login or access" nella sezione "Security" nelle proprietà dell'utente in questione.

In "Global settings > User management" troverai ulteriori impostazioni globali che regolano i logins degli utenti.

Per migliorare la sicurezza delle tue istanze Checkmk, Checkmk offre la funzione di autenticazione a due fattori per ogni utente. Questa autenticazione a due fattori si basa sullo standard internet FIDO2/WebAuthn. L'autenticazione si basa tradizionalmente sulla conoscenza (una password) e sul possesso (un autenticatore).

Puoi utilizzare qualsiasi hardware compatibile con FIDO2 supportato dal tuo browser e dal tuo sistema operativo. I token USB o NFC come lo YubiKey sono i più diffusi. In alternativa, è possibile utilizzare app Authenticator (ad esempio sullo smartphone) che generano una one-time password temporanea (TOTP).

In caso di emergenza, puoi anche modificare una password tramite la riga di comando. Questo ti salva in una situazione in cui hai perso la password per cmkadmin. Il presupposto è, ovviamente, che sia ancora possibile effettuare il login come utente Linux sul server Checkmk e che tu possa diventare un utente dell’istanza con omd su mysite.

Le password sono memorizzate nel file ~/etc/htpasswd, come già descritto sopra.

La modifica delle password si effettua con il comando cmk-passwd. Questo comando non ti chiederà la password esistente. In una versione attuale di Checkmk, cmk-passwd sceglierà sempre un metodo di crittografia sicuro per memorizzare le tue password. Attualmente cmk-passwd utilizza bcrypt per questo scopo. Le password non crittografate o crittografate in modo debole (ad es. con MD5) non consentono il login alla GUI.