Utenti e permessi
Gli utenti si gestiscono in Sistema → Amministrazione.
Il modello
Sezione intitolata “Il modello”Un utente ha uno o più ruoli; un ruolo è un insieme di permessi. I permessi sono granulari e coprono sia la visibilità delle sezioni del menu sia le azioni possibili.
Il modello si applica ovunque: portale, API e Corell!A. Non ci sono percorsi che lo aggirano — anche le risposte di Corell!A sono costruite solo sui dati che l’utente potrebbe comunque vedere.
Ruoli predefiniti
Sezione intitolata “Ruoli predefiniti”| Ruolo | Ambito |
|---|---|
| Amministratore | Tutto, compresa la gestione degli utenti |
| Operatore | Operatività quotidiana: viste, allarmi, console, script |
| Analista | Sola lettura su tutto, più report e capacity planning |
| Sola lettura | Sola lettura, senza azioni |
| Service Desk | Ticket, change, problem, CMDB |
| Amministratore PAM | Configurazione e governo del PAM |
| Approvatore PAM | Solo approvazione delle richieste |
I ruoli predefiniti coprono i casi normali. Quando non bastano, si creano ruoli personalizzati partendo da uno di questi.
Famiglie di permessi
Sezione intitolata “Famiglie di permessi”I permessi sono raggruppati per ambito. Le due famiglie principali:
menu.* — determinano quali sezioni compaiono nel menu. Sono un filtro di
visibilità: menu.pam, menu.citrix, menu.kubernetes, menu.agent.
Permessi d’azione — determinano che cosa si può fare:
vm_actions.console_access, scripts.view, alerts.view, reports.view,
ai.view, capacity.view, settings.security.manage.
Alcune capacità hanno permessi separati per piattaforma, ed è deliberato: il provisioning Citrix e quello Horizon sono deleghe diverse, spesso a persone diverse, e vengono licenziate separatamente. Non condividono un permesso comune.
Doppio filtro del menu
Sezione intitolata “Doppio filtro del menu”Quello che un utente vede dipende da due condizioni che si sommano:
- i permessi del suo ruolo;
- le piattaforme effettivamente collegate.
Un ambiente senza Citrix non mostra le pagine Citrix a nessuno, nemmeno all’amministratore. Non è un permesso mancante: non c’è niente da mostrare.
Vale la pena saperlo prima di andare a caccia di un permesso che non esiste.
Identity provider aziendale
Sezione intitolata “Identity provider aziendale”La piattaforma si integra con Active Directory e Microsoft Entra ID: gli utenti accedono con le credenziali aziendali e i ruoli si assegnano ai gruppi di directory invece che alle singole persone.
È il modo corretto di gestirlo in un’organizzazione di qualunque dimensione: chi entra e chi esce viene gestito una volta sola, dove già lo si gestisce.
L’autenticazione a più fattori è supportata e va attivata almeno per gli account con permessi di amministrazione.
Chiavi API
Sezione intitolata “Chiavi API”Le chiavi API si generano dal portale e servono alle integrazioni. Proprietà importanti:
- ereditano i permessi dell’utente che le crea — una chiave non può fare più di chi l’ha generata;
- sono revocabili singolarmente, senza toccare l’utente;
- sono visibili una volta sola, al momento della creazione;
- hanno una scadenza configurabile.
Una chiave generata da un account amministratore ha permessi di amministratore. Create le chiavi da un utente di servizio con i soli permessi necessari.
Buone pratiche
Sezione intitolata “Buone pratiche”Ruoli, non permessi individuali. Assegnare permessi al singolo utente produce in sei mesi una situazione che nessuno sa più leggere.
Un utente di servizio per integrazione. Con permessi minimi. Quando l’integrazione va rivista o revocata, si sa esattamente che cosa toccare.
Rivedere periodicamente. La pagina degli utenti mostra ultimo accesso e ruoli: è il materiale per una revisione trimestrale degli accessi.
Separare i ruoli PAM. Chi chiede, chi approva e chi configura devono essere persone diverse — altrimenti l’approvazione è un passaggio senza contenuto. Vedi PAM.