Su FortiSOAR l’accesso non è un interruttore unico: è il prodotto di due configurazioni che il prodotto tiene deliberatamente separate. Confonderle è il modo più rapido per creare un utente che entra e trova una pagina bianca.

Autenticazione e autorizzazione: due configurazioni, non una

L’autenticazione è la capacità di fare login (credenziali database, LDAP, SSO, eventuale 2FA). L’autorizzazione è ciò che puoi fare sui dati dopo, e si configura assegnando team e ruoli. La documentazione lo dice senza giri di parole: se definisci solo l’autenticazione, l’utente entra e può ritrovarsi davanti a uno schermo vuoto per mancanza di autorizzazione.

Gli utenti sono persone: al login ricevono un token a scadenza, che per default vive 30 minuti prima di essere rigenerato. Le appliance rappresentano utenti non umani e si autenticano in HMAC con una coppia di chiavi pubblica/privata; dalla 7.5.0 l’automazione può in alternativa usare API key. Entità diverse, stesso modello di autorizzazione: anche un’appliance ha team e ruoli.

Dettagli che valgono l’intero punto. Il campo Username è obbligatorio, case sensitive e non più modificabile una volta impostato. Gli stati utente sono Active, Unlocked, Inactive e Locked. Dalla UI un utente non si cancella: si mette Inactive (la cancellazione vera richiede uno script), e l’effetto non è istantaneo perché l’utente smette di lavorare solo alla scadenza del token già emesso. Il lock invece è automatico: superati i tentativi di login consentiti (default 5) l’account resta bloccato 30 minuti, e dalla 7.0.0 un amministratore può sbloccare dalla UI ma non bloccare.

Il ruolo governa le colonne

Team e ruoli sono modellati sul disegno di una tabella dati: i team possiedono le righe, i ruoli governano le colonne con i permessi Create, Read, Update, Delete. Un utente può avere più ruoli e i ruoli sono additivi: il permesso effettivo è l’unione dei CRUD di tutti i ruoli assegnati, non l’intersezione.

Sulla pagina Roles agiscono alcuni automatismi:

Create  -> seleziona automaticamente Read
Update  -> seleziona automaticamente Read e Create
Playbooks: C R U D + Execute (permesso in più, solo su questo modulo)
Nuovo ruolo: Read su "Application" è già selezionato

Chiunque debba lavorare in FortiSOAR ha bisogno come minimo di Read su Application, Audit Log Activities e Security. Senza Read su Application non si usa la GUI: è esattamente il modo documentato per tenere fuori dall’interfaccia un utente API pur lasciandogli i permessi sui moduli.

Il permesso Execute sui Playbook non è cosmetico: senza, all’utente non compaiono i pulsanti Execute, e con essi spariscono Escalate e Resolve, che sono azioni di playbook. Per lanciare azioni di connettore da un record servono invece Read ed Execute sul modulo Connectors, e se l’azione dichiara dei ruoli, quelli dell’utente vengono confrontati con l’elenco ammesso.

Sotto il modulo c’è il campo: il link Set Field Permissions regola il singolo campo, e l’effetto va oltre il campo stesso. Se User Id del modulo People è impostato su No Access, l’utente non vede più le colonne Locked, User Id e Login Status nella pagina Users.

Ultima trappola: dare CRUD su Incidents non basta per lavorare sugli incidenti. Serve almeno Read su tutti i moduli correlati, che si leggono in Settings, Modules.

Team e gerarchia: dove il ruolo non arriva

I team non concedono permessi, concedono proprietà. La gerarchia estende quella proprietà da un team a un altro, e la documentazione la paragona a un sudo: agisci come se fossi membro di un altro team pur non essendo nel suo elenco. Ma il cosa puoi fare resta deciso dal ruolo: serve proprietà estesa più privilegio sufficiente sul modulo, e uno solo dei due non produce nulla.

Per amministrare team e gerarchie serve CRUD sul modulo Security, e qui c’è l’avvertenza esplicita di Fortinet: chiunque abbia anche solo Read su Security vede tutti i team, tutti i ruoli e tutte le relazioni, e si accorgerebbe quindi di un’indagine interna avviata a livello di team. Concedilo con parsimonia.

Trappola operativa: ogni volta che crei un nuovo team devi aggiornare l’assegnazione dell’appliance Playbook (in passato WFUSER), inclusa di default nei nuovi team. Richiede CRUD su Appliances, e se quell’appliance non ha i permessi giusti i playbook falliscono.

Assegnare i ruoli: limiti e tempi di applicazione

I ruoli non si assegnano in blocco. Vanno messi sul singolo profilo utente o appliance, in creazione o in modifica. I team invece sì: dalla pagina Teams si collegano membri in blocco con il pulsante Link, e la membership ha effetto immediato in tutto il sistema.

Per aggiungere utenti e modificarne il profilo serve CRU su People; per cambiare lo stato Active/Inactive servono Read e Update sia su Security sia su People. Il pulsante View Effective Role Permissions, dalla 7.2.1, mostra l’aggregato dei permessi effettivi di un utente o di una API key e richiede almeno Read su Security.

Quando modifichi i permessi di un ruolo l’applicazione è immediata, ma la UI viene costruita al login: la voce di menu resta visibile fino al refresh o al logout, e cliccandola si ottiene un errore di accesso. Non è un bug.

Due casi limite: il Super Admin, che entra anche in violazione delle licenze, deve avere Read e Update su Security e People e non può essere reso Inactive né cancellato; e l’utente SSO, il cui profilo nasce al primo login con team e ruolo di default. Senza default e senza fallback role, quel profilo nasce privo di team e ruolo, con il solo accesso di base.