 |
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. Introduzione
In questo articolo ti illustreremo tutto ciò che riguarda la gestione degli utenti e dei permessi in Checkmk. Ma prima di entrare nei dettagli, dobbiamo chiarire alcuni termini.
In Checkmk, un utente è una persona che ha accesso all'interfaccia utente. Un utente ha uno o più ruoli.Questi ruoli sono la base dei permessi.
Quando un utente è responsabile di determinati host e servizi, viene identificato come contatto. Un contatto normalmente vede solo i propri host e servizi nell'ambiente di monitoraggio e può essere avvisato di eventuali problemi.
Esistono anche utenti che non sono contatti. Un esempio è cmkadmin, che viene generato automaticamente quando viene creato un sito. Questo utente ha il permesso di vedere tutti gli host e i servizi, ma solo perché il ruolo admin contiene il permesso See all hosts and services, e non necessariamente perché sarebbe un contatto per tutto.
Se un contatto è stato creato al solo scopo di notifica (es. per inoltrare le notifiche a un sistema di ticket), può essere utile crearlo in modo tale da non consentire il login all'interfaccia.
Un contatto è sempre membro di uno o più gruppi di contatto, il cui scopo è quello di assegnare i contatti agli host e ai servizi. Ad esempio, il contatto hhirsch potrebbe far parte del gruppo di contatto linux, che a sua volta potrebbe essere assegnato a tutti gli host Linux tramite una regola. L'assegnazione diretta dei contatti ai gruppi di host o ai servizi non è possibile e potrebbe creare difficoltà nella pratica (ad esempio quando un utente lascia l'organizzazione).
In sintesi:
Gli utenti possono utilizzare l'interfaccia utente.
Icontatti sono utenti responsabili di specifici host e servizi.
I gruppi di contatto definiscono le responsabilità di un utente.
I ruoli definiscono i permessi di un utente.
2. Gestione dell'utente attraverso l'ambiente di configurazione
2.1. Panoramica
La pagina di gestione dell'istanza dell'utente si trova sotto Setup > Users > Users. In un sito appena creato, questa pagina ha l'aspetto seguente (nell'immagine è ridotta solo di alcune colonne della tabella):
L'immagine qui sopra mostra tutti gli utenti che sono stati creati automaticamente al momento della creazione del sito. Questi sono i primi due utenti automazione, seguiti dall'utente singolo (cmkadmin) per il login interattivo con password. Con l'istanza Checkmk Appliance, questo utente può avere un nome diverso in quanto sei tu stesso a definirne il nome e la password. Questo utente cmkadmin ha le seguenti proprietà:
Questo utente ha il ruolo Administrator (
admin) e quindi tutti i permessi.Non è responsabile di alcun contatto e non riceve alcuna notifica.
Può comunque vedere tutto (grazie al ruolo
admin).Dovresti assolutamente cambiare la password assegnata al momento della creazione del sito!
Il modulo per la creazione di un nuovo utente si apre con - o per la modifica di un utente esistente con , è diviso in cinque sezioni. La prima sezione riguarda l'identità:
2.2. L'identità
Come sempre in Checkmk, l'ID di un set di dati (in questo casoUsername ) non può essere modificato in seguito. Viene utilizzato per il log-in e 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 che deve essere avvisato via e-mail(configurazione SMTP). Allo stesso modo, il campoPager address è destinato alla notifica via SMS o sistemi simili. Se scrivi i tuoi script di notifica, puoi accedere ai valori di questi campi e utilizzarli per qualsiasi scopo.
Con Authorized sites puoi limitare l'accesso ai siti esistenti. Questo è particolarmente pratico per ambienti molto grandi, come un monitoraggio distribuito con centinaia di siti. Se un utente dell'istanza ha bisogno solo di un certo numero di siti per i suoi host, la GUI contatterà solo i siti autorizzati per impostare le visualizzazioni, migliorando notevolmente le prestazioni.
2.3. Sicurezza
Il secondo box riguarda la registrazione e l'autorizzazione. L'opzione Automation secret for machine accounts è destinata agli account che accedono a Checkmk tramite HTTP e si autenticano tramite l'URL. Di seguito ti mostreremo come fare.
Per quanto riguarda i ruoli, devi selezionarne almeno uno. In teoria, potresti assegnare a un utente più ruoli e ottenere i diritti di tutti i ruoli. Con i ruoli predefiniti (vedi sotto), però, questo non avrebbe molto senso.
Se blocchi gli utenti con l'opzione disable the login to this account, essi appariranno nella tabella con un simbolo. Non potranno più effettuare il log-in, ma rimarranno comunque nel sistema. Se l'utente è un contatto, le notifiche non ne risentiranno e continuerà a ricevere e-mail, ecc. Se l'utente era loggato al momento del blocco, verrà automaticamente disconnesso.
2.4. Gruppi di contatto
Quando assegni un utente a uno o più gruppi di contatto, questo diventa un contatto. Quando viene creato un nuovo sito, viene creato anche il gruppo di contatto Everything, che contiene sempre tutti gli host e tutti i servizi. Un utente di questo gruppo sarà quindi automaticamente responsabile di tutti gli host e i servizi.
2.5. Notifiche
Nel box Notifications, puoi utilizzare l'opzione Receive fallback notifications per specificare che questo contatto riceverà le notifiche quando non si applica alcuna regola di notifica.
2.6. Impostazioni personali
Gli utenti possono modificare tutte le impostazioni di questo box tramite User > Edit profile (ad eccezione del ruolo guest ). Ad eccezione della selezione della lingua dell'interfaccia, queste impostazioni sono raramente necessarie. I dettagli si trovano come sempre nell'aiuto inline.
2.7. Impostazioni dell'interfaccia
Gli utenti possono anche personalizzare le impostazioni dell'interfaccia utilizzando User > Edit profile. Di particolare interesse è l'opzione Show more / Show less che permette di stabilire se Checkmk deve mostrare di più o di meno nell'interfaccia. Se vuoi vedere sempre tutto, puoi forzarlo con Enforce show more.
3. Gruppi di contatto
3.1. Creazione e modifica dei gruppi di contatto
I gruppi di contatto sono il collegamento tra gli host e i servizi da un lato e i contatti dall'altro. Ogni gruppo di contatto rappresenta una responsabilità per un'area specifica del tuo panorama IT. Ad esempio, il gruppo di contatto "SAP" potrebbe comprendere tutte le persone che si occupano della manutenzione dei sistemi SAP ed essere assegnato a tutti i gruppi di host e servizi che forniscono tali servizi in questo ambiente.
La gestione dei gruppi di contatto avviene tramite il sito Setup > Users > Contact groups. La figura seguente mostra questo modulo con quattro gruppi di contatto creati:
Come sempre, l'ID è permanente e l'alias è un nome visualizzato che puoi cambiare in qualsiasi momento:
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 modificando l'utente.
Impostare la visibilità dell'inventario
Inoltre, puoi impostare la visibilità dell'inventario trovato con l'Inventario hardware/software. Per impostazione predefinita l'inventario completo è visibile, ma può anche essere completamente soppresso o abilitato selettivamente con l'opzione Allowed to see the following entries e i percorsi interni dell'inventario:
Per poter inserire le informazioni sul percorso richiesto, devi prima leggerle dai dati dell'inventario. Puoi quindi usare queste informazioni per popolare i percorsi e gli attributi per rendere visibili, ad esempio, solo alcuni dati selezionati del processore (modello e architettura):
3.2. Aggiungere gli host a un gruppo di contatto
Esistono due metodi per includere gli host nei gruppi di contatto: tramite cartella e tramite regole. Puoi anche combinare entrambi i metodi. In questo esempio, all'host verrà assegnata un'aggregazione dei rispettivi gruppi di contatto.
Assegnazione tramite cartelle
Puoi accedere alle proprietà di una cartella tramite il sito Folder > Properties mentre sei nella cartella stessa. Qui troverai l'opzione Permissions. Attiva questo checkbox per accedere alla selezione dei gruppi di contatto:
Il vero scopo di questa opzione è quello di impostare i permessi per il mantenimento degli host, che ti spieghiamo in dettaglio qui di seguito.
Una volta assegnati i permessi per gruppi di contatto specifici, puoi a tua volta inserire questi gruppi come gruppi di contatto per gli host nel monitoraggio. In questo modo, puoi decidere se le assegnazioni devono essere applicate anche agli host nelle sottocartelle e se i servizi di questi host devono ricevere esplicitamente questi gruppi. I servizi senza assegnazioni esplicite ereditano tutti i gruppi di contatto di un host, anche quelli assegnati dalle regole.
 |
L'ereditarietà dell'attributo Permissions sulle cartelle viene sovrascritta a questo punto. Questo ti permette di aggiungere più gruppi di contatto alle sottocartelle. L'assegnazione avviene quindi anche in modo cumulativo attraverso tutte le cartelle madri, se in queste ultime è stata attivata l'opzione Add these groups as contacts in all subfolders. |
Tra l'altro, puoi trovare le opzioni dei gruppi di contatto in un modulo semplificato direttamente nei dettagli di un host, il che significa che puoi utilizzarle anche per assegnare gruppi di contatto a singoli host. Tuttavia, dato che questa operazione può diventare molto confusa, dovresti farlo solo in casi eccezionali e, se dovesse essere necessario, potresti preferire lavorare con le regole.
Assegnazione tramite regole
Il secondo metodo - l'assegnazione dei gruppi di contatto tramite regole- è un po' più complicato, ma molto più flessibile ed è molto utile se non hai impostato la tua struttura di cartelle secondo principi organizzativi strutturati e quindi non puoi assegnare chiaramente i gruppi di contatto alle cartelle.
Il set di regole Assignment of hosts to contact groups necessario a questo scopo si trova all'indirizzoSetup > Hosts > Host monitoring rules.. In questo set di regole troverai una regola predefinita generata al momento della creazione del sito, che assegna tutti gli host al gruppo di contatto Everything.
Nota che questo set di regole è definito in modo tale da valutare tutte le regole applicabili e non solo la prima! Può essere utile che un host appartenga a più di un gruppo di contatto. In questo caso è necessario un set di regole per ogni assegnazione.
3.3. Inclusione di servizi nei gruppi di contatto
Non sempre ha senso che un servizio faccia parte degli stessi gruppi di contatto del suo host. Puoi quindi utilizzare il set di regole Assignment of services to contact groups, indipendentemente dai gruppi di contatto dell'host. Si applicano le seguenti regole:
Se a un servizio non viene assegnato un gruppo di contatto, riceve automaticamente gli stessi gruppi di contatto del suo host.
Non appena viene assegnato esplicitamente almeno un gruppo di contatto a un servizio, questo non eredita più i gruppi di contatto dall'host.
In un ambiente semplice, è quindi sufficiente assegnare i gruppi di contatto solo ai gruppi di host. Quando avrai bisogno di una maggiore differenziazione, potrai anche creare delle regole per i servizi.
3.4. Controllare le assegnazioni
Puoi verificare se hai configurato correttamente tutte le regole e le cartelle consultando i dettagli di un host o di un servizio nell'ambiente di configurazione, dove troverai le voci Host contact groups e Host contacts (o Service contact groups e Service contacts rispettivamente), che elencano le assegnazioni effettive per questo oggetto:
4. Visibilità di host e servizi
4.1. Panoramica
Il fatto che gli utenti normali (ruolo user ) vedano solo gli oggetti per i quali hanno un contatto è tanto più importante quanto più grande è il tuo ambiente di monitoraggio. Questo non solo fornisce una panoramica ordinata, ma evita anche che gli utenti intervengano dove non devono.
Come amministratore (ruolo admin ) hai ovviamente sempre il permesso di vedere tutto. Questo viene controllato tramite il permesso See all host and services. Nelle tue impostazioni personali troverai alla voce Visibility of hosts/services il checkbox Only show hosts and services the user is a contact for. Con questo puoi rinunciare volontariamente a vedere tutto e visualizzare solo gli host e i servizi per i quali sei un contatto. Questa opzione è pensata per i ruoli doppi, cioè per chi è sia amministratore che utente normale.
Il ruolo guest è preimpostato in modo che anche i suoi utenti possano vedere tutto. Le impostazioni di intervento o personali sono disabilitate in questo caso.
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 esistere nel sistema. Tra gli altri elementi che tengono conto della visibilità ci sono i seguenti:
Visualizzazioni di host e servizi
Snap-in dipanoramica della barra laterale
Report creati dall'utente
4.2. Visibilità dei servizi
Come abbiamo mostrato in precedenza, è possibile che tu sia un contatto per un host ma non per tutti i suoi servizi. Tuttavia, in questo caso potrai vedere tutti i servizi dell'host nella GUI.
Questa eccezione è impostata di default perché di solito è utile. In pratica, questo significa, ad esempio, che il collega responsabile dell'host in questione può vedere tutti i servizi connessi a quell'host, ma non riceve alcuna notifica per i servizi!
Se non ti piace questo approccio, puoi cambiarlo tramite Global settings > Monitoring Core > Authorization settings. Se cambi l'impostazione Hosts 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 il servizio.
A proposito, tutto questo non ha nulla a che vedere con il fatto che un servizio eredita i gruppi di contatto del suo host se non sono stati assegnati gruppi di contatto propri al servizio, poiché in questo caso saresti un contatto del servizio e quindi riceveresti le sue notifiche.
4.3. Gruppi di host e gruppi di servizi
La seconda opzione del sito globale Authorization settings 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.
Switchando su Strict - Visible if all members are visible verranno nascosti tutti i gruppi per i quali non sei un gruppo di contatto per almeno un host o un servizio.
Nota che queste due impostazioni di visibilità non hanno alcuna influenza sulle notifiche.
5. Notifiche
L'assegnazione dei contatti influisce anche sulle notifiche. Checkmk è preimpostato in modo che tutti i contatti dell'host o del servizio interessato vengano avvisati in caso di problemi. Questo avviene grazie a una regola di notifica che viene generata automaticamente quando vengono creati nuovi siti. Si tratta di una funzione molto sensata.
Tuttavia, se necessario, puoi adattare la regola o integrarla con altre regole, in modo che in casi estremi le notifiche possano essere effettuate in modo completamente indipendente dai gruppi di contatto. Un motivo comune è che un utente desideri non ricevere determinate notifiche o, viceversa, essere informato sui problemi di singoli host o servizi, anche se non ne è direttamente responsabile (e quindi non è un contatto esplicito).
Per ulteriori dettagli, consulta l'articolo sulle notifiche.
6. Ruoli e permessi
6.1. Ruoli predefiniti
Checkmk assegna sempre i permessi agli utenti tramite i ruoli, mai direttamente. Un ruolo non è altro che un elenco di permessi. È importante che tu capisca che i ruoli definiscono il livello del servizio e non un riferimento a nessun host o servizio. A questo servono i gruppi di contatto.
Checkmk viene fornito con i seguenti ruoli predefiniti, che non possono essere cancellati, ma possono essere personalizzati a piacere:
| Ruolo | Permessi | Funzione |
|---|---|---|
|
Tutti i permessi, in particolare il diritto di modificare i permessi. |
L'amministratore di Checkmk che gestisce il sistema di monitoraggio stesso. |
|
Può vedere solo i propri host e servizi, può apportare modifiche nell'interfaccia web solo nelle cartelle condivise e, in generale, non può fare nulla che influisca sugli altri utenti. |
Il normale utente di Checkmk, che utilizza il monitoraggio e reagisce alle notifiche. |
|
Il permesso di registrare l'agente Checkmk di un host con il server Checkmk per la trasmissione dei dati con crittografia TLS, nient'altro. |
Questo ruolo viene assegnato all'utente automazione |
|
Può vedere tutto ma non modificare nulla. |
Guest è pensato semplicemente per "guardare", per cui tutti gli ospiti condividono un account comune. È utile anche per i monitor di stato "pubblici" appesi a una parete. |
I ruoli sono gestiti da Setup > Users > Roles & permissions:
A proposito, quando si crea una nuova istanza Checkmk, viene creato solo un utente (cmkadmin) per il ruolo admin. Gli altri ruoli possibili non verranno utilizzati per il momento. Se hai bisogno di un utente dell'istanza Checkmk, devi crearlo tu stesso.
6.2. Personalizzare i ruoli esistenti
Come al solito, il pulsante ti porta alla modalità di modifica di un ruolo:
Puoi scoprire il significato dei vari permessi (qui mostrati in estratto) consultando la guida in linea.
La particolarità è che per ogni permesso ci sono tre scelte:sì, no e predefinito (sì) o predefinito (no). Al momento dell'installazione tutti i valori sono impostati come predefiniti. Per l'autorizzazione in sé non fa differenza se hai impostato sì o predefinito (sì). È tuttavia possibile che l'installazione di una nuova versione di Checkmk possa cambiare un valore predefinito (anche se questo accade molto raramente). Un'impostazione che hai fatto esplicitamente non sarebbe quindi influenzata dall'installazione.
Inoltre, questo principio ti permette di riconoscere molto rapidamente i casi in cui la tua installazione di Checkmk potrebbe essersi discostata dallo standard.
6.3. Definire i propri ruoli
Potresti essere sorpreso dal fatto che non ci sia un pulsante per la creazione di un nuovo ruolo. C'è un motivo ben preciso: si creano nuovi ruoli derivandoli da ruoli esistenti utilizzando Clone. Il nuovo ruolo non viene semplicemente creato come una copia, ma mantiene la sua relazione con il ruolo originale Based on role:
Questa connessione ha una funzione importante: tutti i permessi del ruolo clonato che non sono stati impostati in modo esplicito (cioè sono ancora impostati su default) saranno ereditati dal ruolo di origine. Le successive modifiche apportate al ruolo di origine saranno trasferite al nuovo ruolo clonato. Questo è molto pratico se consideri quanti permessi potrebbero esserci nel ruolo originale. Con una semplice copia, potresti facilmente perdere di vista le particolarità del tuo ruolo che hai definito per te stesso.
Questa funzione di derivazione risolve anche un altro problema: poiché continuiamo a sviluppare Checkmk, vengono continuamente aggiunti nuovi permessi e ogni volta decidiamo in quale dei tre ruoli admin, user e guest debba essere inserito il nuovo permesso.
Dato che ogni tuo ruolo deriva da uno dei tre ruoli predefiniti, il nuovo permesso viene automaticamente preimpostato a un valore sensato. Sarebbe molto poco pratico se, ad esempio, tu definissi il tuo ruolo user e i nuovi permessi fossero sempre assenti. Dovresti adattare il tuo ruolo per ogni nuova funzione, affinché i tuoi utenti possano utilizzarla.
6.4. Confrontare i ruoli con la visualizzazione a matrice
Se vuoi confrontare i permessi dei singoli ruoli, puoi avvalerti della visualizzazione a matrice, accessibile da Setup > Users > Roles & permissions > 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 esplicitamente impostati () o rimossi ().
7. Impostazioni personali
Ogni utente può gestire un numero limitato di impostazioni del proprio profilo. Una descrizione dettagliata di tutte le opzioni disponibili si trova nell'articolo sull'interfaccia utente.
Una nota aggiuntiva per il monitoraggio distribuito: in un ambiente distribuito, tutte le nuove impostazioni vengono immediatamente trasferite a tutti i siti di monitoraggio. Questo è l'unico modo per garantire che, in particolare, una password appena assegnata funzioni immediatamente ovunque, e non solo dopo la successiva attivazione delle modifiche. Tuttavia, questo funziona solo per i siti che in quel momento sono accessibili tramite la rete. Tutti gli altri siti ricevono gli aggiornamenti alla successiva attivazione delle modifiche.
8. Utente automazione (per i servizi web)
Quando si connette Checkmk ad altri sistemi, spesso si desidera automatizzare alcune attività che normalmente si svolgono tramite la GUI. Alcuni esempi sono:
Impostazione e rimozione dei tempi di manutenzione programmata tramite script.
Gestione degli host tramite API REST
Recupero dei dati dalle visualizzazioni in formato CSV o JSON per ulteriori processi
Recuperare lo stato attuale delle aggregazioni BI per crearle come servizio.
In queste situazioni, i software esterni devono essere in grado di recuperare automaticamente determinati URL dall'interfaccia di Checkmk. Questo ovviamente solleva la questione del modo in cui l'utente si logga. Il modo abituale attraverso la finestra di dialogo per il login è macchinoso e richiede il recupero di diversi URL in successione e il salvataggio di un cookie.
Per semplificare il tutto, Checkmk offre il concetto di utenti automazione, che servono esclusivamente per il controllo remoto e non consentono un normale login tramite la GUI. L'autenticazione avviene tramite HTTP Basic Authentication.
In ogni istanza Checkmk sono già impostati due utenti di automazione: per i servizi web e per la registrazione dell'agente agent con il server Checkmk per il trasferimento dei dati con crittografia TLS. Puoi utilizzare questi utenti di automazione o crearne uno nuovo. Crea un utente di automazione come un utente normale, ma non assegnare una password normale, bensì una password di automazione (Automation secret). Puoi fare in modo che questa venga creata automaticamente con il cubo:
Un utente automazione ha un ruolo come un utente normale e può anche essere un contatto. Questo significa che puoi limitare i permessi e la visibilità di host e servizi a seconda delle esigenze.
Per il recupero automatico delle pagine web, inserisci l'header dell'autenticazione HTTP Basic, che in pratica si presenta così: Authorization: Basic 1234567890abcdef. La stringa di caratteri è il modulo codificato in Base64 di username:password.
Ecco un esempio di recupero di una visualizzazione in formato JSON con l'utente automazione automation e la password dell'automazione dall'immagine precedente - la codifica Base64 viene effettuata da curl:
root@linux# curl --user automation:a8075a39-e7fe-4b5c-9daa-02635 'http://moni01.mycompany.net/mysite/check_mk/view.py?view_name=svcproblems&output_format=json'
[
"service_state",
"host",
"service_description",
"service_icons",
"svc_plugin_output",
"svc_state_age",
"svc_check_age",
"perfometer"
],
[
"CRIT",
"stable",
"Filesystem /",
"menu pnp",
"CRIT - 96.0% used (207.27 of 215.81 GB), (warn/crit at 80.00/90.00%), trend: +217.07 MB / 24 hours",
"119 min",
"30 sec",
"96%"
],
...Se lo script che recupera l'URL viene eseguito direttamente nel sito di monitoraggio, è possibile leggere la password di automazione dell'utente direttamente dal file system. Questa non è una vulnerabilità di sicurezza, ma è intesa come tale: puoi scrivere script di automazione che non devono contenere la password di automazione e non hanno bisogno di un file di configurazione. A tal fine, leggi il file ~/var/check_mk/web/myuser/automation.secret:
OMD[mysite]:~$ cat var/check_mk/web/automation/automation.secret
a8075a39-e7fe-4b5c-9daa-02635Puoi facilmente memorizzare il contenuto di questo file in una variabile della shell:
OMD[mysite]:~$ SECRET=$(cat var/check_mk/web/automation/automation.secret)
OMD[mysite]:~$ echo "$SECRET"
a8075a39-e7fe-4b5c-9daa-02635Questo file è utilizzato anche, ad esempio, dallo script downtime, che si trova nella directory Checkmk treasures e che può essere utilizzato per impostare e rimuovere i tempi di manutenzione programmata per gli host e i servizi controllati dallo script. Se l'utente automazione si chiama automation, come nel nostro esempio, l'unico argomento necessario è il nome dell'host per il quale vuoi specificare un tempo di manutenzione programmata:
OMD[mysite]:~$ ~/share/doc/check_mk/treasures/downtime.py myhost123Ulteriori opzioni per questo script sono disponibili nella sua guida online:
OMD[mysite]:~$ ~/share/doc/check_mk/treasures/downtime.py --help9. Login automatico via URL
|
Il login automatico tramite URL nel browser descritto di seguito è stato disabilitato per motivi di sicurezza dall'istanza Checkmk 2.2.0, perché le credenziali (nome utente e password) passate tramite URL vengono archiviate nei file di log dell'Apache specifico del sito (vedi Werk #14261). Se vuoi utilizzare il login automatico tramite URL nonostante questo rischio di sicurezza, devi abilitarlo esplicitamente con l'impostazione globale Setup > General > Global settings > User interface > Enable login via GET requests. |
Come abbiamo visto, è possibile utilizzare l'automazione degli utenti per recuperare qualsiasi URL utilizzando uno script, senza la necessità di effettuare il login. In situazioni che richiedono un vero e proprio login al browser, tuttavia, questo non funziona, perché i dati di login per qualsiasi link incluso (ad es. alle immagini e agli iframe) non vengono trasmessi.
L'esempio migliore è il desiderio di appendere a parete un monitor che mostri continuamente uno specifico dashboard di Checkmk. Questo monitor deve essere controllato da un computer che all'avvio apre automaticamente il browser, si logga a Checkmk e richiama il dashboard richiesto.
Per ottenere questo risultato, è meglio creare un utente speciale per questo scopo. Il ruolo guest è la suite ideale per questa funzione perché concede tutti i diritti di lettura, ma non consente modifiche o interventi.
Costruisci l'URL per il login automatico come segue:
Inizia con:
http://mycmkserver/mysite/check_mk/login.py?_origtarget=Determina l'URL effettivo da visualizzare (ad es. quello della dashboard) con il tuo browser, preferibilmente senza navigazione, cosa che può essere fatta tramite Display > This page without navigation.
Aggiungi questo URL, tralasciando tutto ciò che precede la parte
/mysite/….Aggiungi all'URL le due variabili
_usernamee_passwordnel modulo seguente:&_username=myuser&_password=mysecret.Aggiungi un altro
&_login=1.
Ecco un esempio di URL di questo tipo:
http://mycmkserver/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=mypassword&_login=1Nota:
Nell'esempio, sostituisci i valori
mycmkserver,mysite,myuseremypasswordcon i valori appropriati. Non puoi utilizzare l'utente automazione comemyuser, poiché il log in tramite GUI non è consentito per questo utente.Se i caratteri speciali
&o%compaiono in uno di questi valori o nel valore di_origtarget, devi sostituirli come segue:&con%26e%con%25.
Prova il tutto effettuando il logout dal tuo browser da Checkmk e copiando poi l'URL costruito nel tuo browser. A questo punto dovrai andare direttamente alla pagina di destinazione, senza finestra di dialogo. Allo stesso tempo sarai loggato e potrai richiamare direttamente i link contenuti nella pagina.
Puoi anche provare l'URL finito con curl sulla linea di comando. Se hai fatto tutto correttamente, riceverai il codice di stato HTTP 302 FOUND e verrai reindirizzato alla pagina location specificata, come nel seguente output abbreviato:
OMD[mysite]:~$ curl -v 'http://mycmkserver/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=mypassword&_login=1'
...
< HTTP/1.1 302 FOUND
...
< Location: /mysite/check_mk/dashboard.py?name=mydashboard
...Se nonostante il messaggio di successo non ottieni la visualizzazione desiderata nel browser, controlla l'URL indicato in Location: anche se non è corretto, curl restituirà il codice di stato HTTP 302 FOUND.
Se i dati di login non sono corretti, riceverai il codice di stato HTTP 200 OK, ma vedrai solo il codice HTML della pagina di login, come nel seguente output abbreviato:
OMD[mysite]:~$ curl -v 'http://mycmkserver/mysite/check_mk/login.py?_origtarget=/mysite/check_mk/dashboard.py?name=mydashboard&_username=myuser&_password=NOT&_login=1'
...
< HTTP/1.1 200 OK
...
<!DOCTYPE HTML>
<html><head><meta content="text/html; ...
...
</script>
<script type="text/javascript">
cmk.visibility_detection.initialize();
</script>
</body></html>10. Permessi in Checkmk
10.1. Funzione del ruolo "utente" in Checkmk
Se devi gestire un ambiente di monitoraggio un po' più ampio, allora vorrai coinvolgere i tuoi colleghi amministratori nella configurazione e soprattutto nella gestione degli host e dei servizi. Per mantenere il controllo su chi può apportare modifiche e su cosa può fare e per evitare che le persone si intralcino a vicenda, puoi assegnare i permessi per il Checkmk Setup sulla base di cartelle.
Il primo passo è quello di far lavorare i tuoi colleghi amministratori con i propri utenti in base al ruolo user.
Questo ruolo ha sostanzialmente l'autorizzazione per l'ambiente di configurazione, ma con alcune importanti restrizioni:
Sono consentite solo le modifiche a host, servizi, regole e aggregazioni BI.
Gli host, i servizi e le regole possono essere gestiti solo in cartelle condivise.
Le aggregazioni BI possono essere gestite solo in pacchetti BI condivisi.
Tutto ciò che ha implicazioni globali non è consentito.
Se non hai ancora rilasciato cartelle o pacchetti BI, questo significa che gli utenti con il ruolo user non possono inizialmente apportare alcuna modifica! Il semplice menu Setup nella barra di navigazione si presenta così per gli utenti normali:
10.2. Autorizzare gli utenti a gestire degli host
Un utente riceve l'autorizzazione a creare, modificare e rimuovere gli host tramite i gruppi di contatto.La procedura è la seguente:
Aggiungi l'utente a un gruppo di contatto.
Descrivi una o più cartelle per le quali l'utente deve essere autorizzato.
Attiva la proprietà Permissions per queste cartelle e seleziona il gruppo di contatto.
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 questa operazione anche nelle sottocartelle.
Se vuoi includere automaticamente gli host nel gruppo di contatto dipende da te. In questo esempio l'opzione Add these groups as contacts to all hosts in this foldernon è stata impostata e gli host non saranno aggiunti al gruppo di contatto Linux. Ciò significa che nell'ambiente di monitoraggio non saranno visibili al gruppo di contatto Linux (a meno che non sia una regola a occuparsene). Quindi, come puoi vedere, la visibilità (e la responsabilità nel monitoraggio) e l'autorizzazione per l'ambiente di configurazione possono essere regolate separatamente.
11. Le password
11.1. Sicurezza delle password
Al giorno d'oggi la sicurezza è una priorità assoluta. Per questo motivo, in alcune aziende esistono delle linee guida generali su come gestire le password. Checkmk offre diverse impostazioni per applicare tali impostazioni predefinite, alcune delle quali si trovano alla voce 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:
lettere minuscole
lettere maiuscole
cifre
caratteri speciali
Se inserisci un 4, la password deve contenere almeno un carattere di ciascuno dei gruppi sopra elencati. Con 2 si garantisce almeno che la password non sia composta, ad esempio, solo da lettere minuscole. Queste impostazioni vengono verificate ogni volta che la password viene modificata.
La terza opzione Maximum age of passwords obbliga l'utente a cambiare la password a intervalli regolari. Una volta giunto il momento, il successivo accesso alla pagina presenterà all'utente il seguente prompt:
Gli utenti possono continuare solo dopo aver cambiato la password.
Puoi richiedere la modifica della password iniziale al primo login. Questo si può fare con l'opzione Enforce change: Change password at next login or access nella sezione Security delle proprietà del rispettivo utente.
11.2. Policy di login
In Global settings > User management troverai altre impostazioni globali che regolano i login degli utenti.
Blocco a seguito di login non validi
Con l'impostazione Lock user accounts after N logon failures puoi bloccare un account dopo una serie di tentativi di login falliti:
Lo sblocco è possibile solo da parte di un utente con il ruolo admin. Come amministratore, puoi sbloccare gli altri utenti tramite Setup > Users >Users e poi le proprietà dell'utente bloccato. Nota che anche gli account di amministratore possono essere bloccati! Se sei bloccato in modo permanente come ultimo o unico amministratore, puoi sbloccare il tuo account solo tramite la linea di comando. Per farlo, modifica il file etc/htpasswd come utente dell'istanza e rimuovi il punto esclamativo dalla riga dell'utente interessato, qui myuser:
OMD[mysite]:~$ cat etc/htpasswd
agent_registration:$2y$12$83XzYwtQJVFizC...
automation:$2y$12$zKF4Sasws7rDJCByZ1r5ke...
cmkadmin:$2y$12$ZmE96frGSm9sdWiWRXtxbuyu...
myuser:!$2y$12$8FU93yH7TFTyJsyUvKCh1eqYJG..
OMD[mysite]:~$ vim etc/htpasswd
...
OMD[mysite]:~$ cat etc/htpasswd
agent_registration:$2y$12$83XzYwtQJVFizC...
automation:$2y$12$zKF4Sasws7rDJCByZ1r5ke...
cmkadmin:$2y$12$ZmE96frGSm9sdWiWRXtxbuyu...
myuser:$2y$12$8FU93yH7TFTyJsyUvKCh1eqYJG...
A questo punto potrai effettuare nuovamente il log-in.
Disconnessione automatica
Nel box Session management puoi specificare due modi diversi di terminare una sessione e combinarli tra loro: da un lato in base alla durata della sessione, dall'altro in base all'attività dell'utente.
Maximum session duration L'opzione "Termina sessione" assicura che la sessione venga terminata automaticamente dopo un periodo di tempo prestabilito. Tra l'altro, questo riduce il rischio di un uso esterno della sessione, in quanto questa non rimane attiva a tempo indeterminato:
Una volta scaduta la durata della sessione definita, l'utente deve effettuare nuovamente il login, indipendentemente dal fatto che fosse attivo o meno al termine della sessione. Allo stesso tempo, puoi utilizzare Advise re-authentication before termination per specificare quando l'utente deve essere avvisato di salvare i propri dati, effettuare il logout e accedere nuovamente prima di una chiusura "dura" della sessione:
L'impostazione Set an individual idle timeout fa sì che la sessione venga terminata se l'utente non utilizza attivamente la GUI per un periodo di tempo prolungato. Ad esempio, se l'utente si è allontanato temporaneamente dalla sua postazione di lavoro senza effettuare il logout in Checkmk. Questo timeout può essere interrotto utilizzando attivamente la GUI. Tuttavia, non è sufficiente avere una visualizzazione aperta che si ricarica regolarmente.
Prevenire i login multipli
L'impostazione Limit login to single session at a time impedisce a un utente di loggarsi a Checkmk con due browser contemporaneamente:
Questa opzione è anche collegata a un timeout per un logout automatico in caso di inattività. Questa funzione ha anche un senso: supponiamo che tu abbia dimenticato di disconnetterti dalla tua postazione di lavoro prima di chiudere il browser. In questa situazione, senza un timeout, non saresti in grado di accedere da casa mentre sei in servizio, poiché la chiusura del browser o lo spegnimento del computer non attivano automaticamente il logout!
Quando tenti un secondo login in parallelo, vedrai il seguente messaggio di errore:
In questo caso, il login può essere effettuato solo se si termina attivamente la sessione esistente o se si attende il timeout.
11.3. Autenticazione a due fattori
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 convenzionalmente 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 YubiKey sono i più utilizzati. In alternativa, è possibile utilizzare software di autenticazione (app Authenticator sullo smartphone) che generano una one-time password temporanea (TOTP).
Requisiti del server Checkmk
In base alle specifiche dello standard WebAuthn, ci sono tre prerequisiti per l'utilizzo dell'autenticazione a due fattori:
Indicazione dell'indirizzo web come semplice nome host o come nome di dominio pienamente qualificato, in ogni caso un indirizzo di dominio valido.
L'URL viene inserito sempre nello stesso formato, ad es. sempre
https://www.mycompany.com/mysite.
Configurazione
Accedi all'autenticazione a due fattori dal menu Utente.
A questo punto ti verranno proposte due opzioni contrassegnate dal simbolo della chiave per aggiungere il secondo fattore:Register authenticator app per configurare un'app che genera one-time password e Register security token per utilizzare un token hardware.
Checkmk riconosce le opzioni di autenticazione disponibili sul tuo computer. Nella finestra del browser si aprirà una piccola finestra di dialogo in cui dovrai specificare l'autenticatore. Se utilizzi un token hardware, la configurazione sarà completata quando toccherai il pulsante. Se utilizzi una one-time password, dovrai inserire una password generata per conferma. La sessione continuerà senza problemi in entrambi i casi.
Login
L'autenticazione a due fattori sarà attiva in Checkmk per i futuri tentativi di login: per prima cosa, inserisci il tuo nome utente e la tua password come di consueto, dopodiché apparirà un'altra schermata di login:
Dopo aver attivato l'autenticazione, puoi lavorare con Checkmk come al solito.
Creare e utilizzare i codici di backup
Se non hai a portata di mano il tuo autenticatore, puoi inserire un codice dell'Authenticator.
A tal fine, crea in anticipo un elenco di codici di backup nella pagina User > Two-factor authentication utilizzando Generate backup codes.
Conserva questi codici in un luogo sicuro.
Se poi vuoi effettuare il login con un codice di backup sul sito web di Checkmk, clicca su Use backup code nella seconda schermata di login. Inserisci uno dei tuoi codici di backup e accedi con Use backup code.
Controllare e annullare l'autenticazione a due fattori come amministratore
In qualità di amministratore, nella gestione degli utenti (Setup > Users > Users) puoi vedere quali utenti hanno impostato l'autenticazione a due fattori osservando la voce nella colonna Authentication.
Se uno di questi utenti non ha più accesso a Checkmk - ad esempio se ha perso o danneggiato il token hardware - puoi rimuovere l'autenticazione a due fattori per questo utente. Per farlo, apri la voce corrispondente nella gestione utenti cliccando su . Nella visualizzazione dell'utente, rimuovi l'autenticazione a due fattori per questo utente tramite User > Remove two-factor authentication.
Dopo aver confermato la richiesta di sicurezza, l'utente potrà nuovamente accedere all'interfaccia web di Checkmk utilizzando "solo" il nome utente e la password.
11.4. Cambiare una password utilizzando la linea di comando
In caso di emergenza, puoi anche cambiare una password tramite la linea di comando. Questo ti salva in una situazione in cui hai perso la password di cmkadmin. Il prerequisito è, ovviamente, che sia ancora possibile accedere come utente Linux al server Checkmk e che tu possa diventare utente dell'istanza omd su mysite.
Le password sono archiviate nel file ~/etc/htpasswd, come già descritto in precedenza.
La modifica delle password si effettua con il comando cmk-passwd, che non ti chiederà la password esistente.cmk-passwd sceglierà sempre un metodo di crittografia sicuro per archiviare le tue password in una versione corrente di Checkmk. Attualmente cmk-passwd utilizza bcrypt per questo scopo. Le password non crittografate o debolmente crittografate (es. con MD5) non consentono il login alla GUI.
OMD[mysite]:~$ cmk-passwd cmkadmin
New password: secret
Re-type new password: secret12. Attributi utente personalizzati
Oltre al campo per l'indirizzo e-mail, è disponibile anche il campo Pager address per la notifica agli utenti. Se questo non è sufficiente e desideri memorizzare altre informazioni su un utente, puoi creare dei campi personalizzati tramite Setup > Users > Custom user attributes > Add attribute, che possono essere riempiti con valori individuali per ogni utente.
La creazione di un nuovo attributo apre la seguente finestra di dialogo:
Come sempre, l'ID (Name) non può essere modificato in seguito, ma il titolo (Title) sì. Topic determina in quale sezione delle impostazioni dell'utente sarà ordinato il nuovo campo. Inoltre, puoi decidere se gli utenti possono modificare il campo stesso (che apparirà quindi nelle loro impostazioni personali) e se il valore deve essere visualizzato direttamente nella tabella degli utenti.
|
Solo se attivi il checkbox all'indirizzo Make this variable available in notifications puoi utilizzare questo valore anche nelle notifiche. A tal fine, il valore deve essere assegnato al nucleo di monitoraggio (es. CMC) in una variabile personalizzata (una cosiddetta "macro personalizzata"). |
Il nome della variabile personalizzata deriva dall'ID che hai scelto, che viene convertito in lettere maiuscole e preceduto da un CONTACT_. Un phone diventa quindi CONTACT_PHONE. Nota che quando la variabile viene passata tramite variabili d'ambiente, la variabile avrà il prefisso NOTIFY_. Con il tuo script di notifica personalizzato la variabile arriverà come NOTIFY_CONTACT_PHONE.
13. Scrivere messaggi agli utenti
Nell'articolo che descrive le notifiche, abbiamo analizzato in dettaglio come Checkmk può informare i contatti di problemi con gli host o i servizi. Tuttavia, a volte potresti voler informare tutti gli utenti (anche quelli che non sono contatti) di questioni organizzative interne, ad esempio la manutenzione del sistema Checkmk stesso.
Per questo Checkmk offre un piccolo strumento integrato per i messaggi, che è completamente separato dalle notifiche. Puoi trovare questo strumento su Setup > Users e su Users > Send user messages. Qui hai la possibilità di inviare un messaggio a tutti o ad alcuni dei tuoi utenti.
Puoi scegliere tra quattro tipi di messaggio:
Show popup message |
La prossima volta che l'utente apre la pagina, si aprirà una finestra popup con il messaggio. |
Show hint in the 'User' menu |
L'utente viene indirizzato al messaggio da un simbolo numerico nel menu Utente della barra di navigazione. |
Send email |
Invia un'e-mail. Tuttavia, questo messaggio raggiungerà solo gli utenti che hanno configurato un indirizzo e-mail. |
Show in the dashboard element 'User messages' |
Il messaggio viene visualizzato in una dashlet del tipo User messages. |
Con Message expiration puoi eliminare facilmente i messaggi che non sono ancora stati recuperati non appena non sono più rilevanti.
14. Altri temi
Checkmk supporta altri metodi di log in:
Connessione di una directory LDAP/Active Directory
Autenticazione con SAML
Autenticazione con Kerberos
Autenticazione in una configurazione con proxy inverso
Autenticazione con l'Autenticazione di base HTTP
15. File e directory
Il seguente elenco mostra quali file e directory del server Checkmk riguardano la gestione degli utenti. Come sempre, tutte le voci dell'elenco sono relative all'istanza Checkmk (es. /omd/sites/mysite).
| Percorso | Funzione |
|---|---|
|
Password degli utenti in formato Apache |
|
Questo file contiene un segreto casuale utilizzato per firmare i cookie di login. In ambienti distribuiti, questo file dovrebbe essere lo stesso per tutti i siti - e lo sarà se hai impostato tutto con l'interfaccia web. Se questo file viene modificato, tutti i login vengono immediatamente invalidati e gli utenti devono effettuare nuovamente il login. Questo file è privilegiato |
|
Numeri di serie delle password per utente. Ogni modifica della password incrementa il numero di serie e quindi rende non valide tutte le sessioni in corso. In questo modo si garantisce che un cambio di password logghi in modo affidabile un utente. |
|
Contiene gli utenti impostati con l'ambiente di configurazione. Qui vengono archiviati solo i dati degli utenti che hanno a che fare esclusivamente con la GUI. Le modifiche manuali in questo file hanno effetto immediato. |
|
Informazioni di contatto per gli utenti configurati con l'ambiente di configurazione. Qui vengono archiviati tutti i dati relativi alla configurazione del nucleo di monitoraggio. Qui vengono elencati solo gli utenti che sono anche contatti. Affinché le modifiche manuali abbiano effetto, la nuova configurazione deve essere caricata nel nucleo - ad es. con |
|
Ogni utente che ha effettuato almeno una volta il login alla GUI ha una sottocartella in cui vengono memorizzati, in piccoli file individuali con estensione |
|
File di log dell'interfaccia utente: qui troverai i messaggi di errore relativi all'autenticazione e alle connessioni LDAP. |