Nel modello di FortiSOAR “proprietario” e “assegnatario” sono due cose diverse, e vengono da due meccanismi diversi. Chi le tratta come sinonimi arriva sempre allo stesso incidente: un alert riassegnato a un analista che poi non riesce ad aprirlo.

Owner e Assigned To non sono la stessa cosa

I proprietari di un record sono team, non persone. La proprietà arriva dal modello di sicurezza, si vede nella scheda Access Control della vista di dettaglio ed è quella che decide se il record esiste per te. Assigned To è invece un campo normale del modulo, di tipo Lookup verso il modulo People: è un’informazione di workflow, dice chi ci sta lavorando, e non concede nessun accesso.

La conseguenza è la trappola documentata da Fortinet: puoi assegnare un alert a un utente che non ha accesso a quel record, e quell’utente continuerà a non vederlo. Per questo il campo Lookup verso People offre l’opzione Only show users with record ownership, che riduce l’elenco ai soli utenti che hanno effettivamente proprietà sul record, e l’opzione Limit ownership users to ones with module access to, che filtra ulteriormente per permesso sul modulo. Se scegli Update, Read viene selezionato automaticamente.

Dalla griglia puoi riassegnare in blocco con il pulsante Reassign, insieme agli altri pulsanti di massa come Change Severity, Change Status, Change Queue, Execute, Escalate e Resolve. Ma riassegnare in blocco non tocca la proprietà: sposta solo il valore del campo.

Le due caselle che decidono chi possiede cosa

La proprietà non è automatica: si accende sul modulo, dal Module Editor. Ci sono due caselle distinte e vengono chieste spesso.

Team Ownable  -> il record può essere posseduto da uno o più team   (esempio: Incidents)
User Ownable  -> il record può essere posseduto da utenti o appliance (esempio: Alerts)
nessuna delle due -> il record è pubblico, visibile a qualunque utente del sistema (esempio: Addresses)

Da qui discendono i comportamenti che fanno perdere il punto intero. Un record senza proprietari è visibile a “All”: non è protetto, è pubblico. Se converti un modulo da non ownable a ownable, i record creati prima restano visibili a tutti e, finché non gli assegni un team, sono di sola lettura: i campi non si possono modificare. Chi sta lavorando su un record senza proprietari deve assegnargli il proprio team per poterlo salvare.

La gerarchia estende la proprietà, non i permessi

L’insieme dei record su cui puoi esercitare i tuoi permessi si chiama Ownership Sphere ed è dato dai team di cui fai parte più le loro relazioni. Le relazioni possibili sono tre e non sono simmetriche:

Parent   -> proprietario virtuale dei record del team Child; agisce come se ne fosse membro
Sibling  -> i due team agiscono sui record reciproci come se fossero lo stesso team
Child    -> l'inverso di Parent: il figlio NON agisce sui record del genitore

Due regole che l’esame verifica volentieri. La visibilità verso l’alto attraversa più livelli: i record creati dall’ennesimo livello sono visibili ai team antenati, quindi anche i nipoti risalgono al nonno. Ma non esiste alcuna ereditarietà orizzontale: due team figli dello stesso genitore non sono fratelli fra loro, e se li vuoi fratelli devi dichiararlo esplicitamente.

L’editor si usa portando un team “in focus”, con drag and drop o doppio clic, e mostra le tre corsie Parent, Sibling e Child rispetto a quel team. Le modifiche restano in sospeso finché non premi Save, poi hanno effetto immediato. Attenzione: nella vista dei record correlati la RBAC per impostazione predefinita viene ignorata, quindi vedi anche gli indicatori a cui non hai accesso, e ottieni “Access Denied” solo aprendoli. Per cambiare comportamento:

/opt/cyops-api/config/parameters_prod.yaml
ignore_rbac_for_related_record: false
systemctl restart php-fpm && sudo -u nginx php /opt/cyops-api/bin/console cache:clear && systemctl restart php-fpm

Stessa logica per i commenti: appartengono al record, non al modulo, quindi chi vede il record per proprietà o per gerarchia vede tutti i commenti, chiunque li abbia scritti.

Un caso d’uso completo

Prendi la struttura di esempio della documentazione: SOC Team genitore di L1, L2 e L3; L1 fratello di L2; L3 figlio di L2; L1 genitore di L3; Legal Team senza alcuna relazione.

Il risultato è che il SOC Team possiede di fatto tutti i record di L1, L2 e L3 e nessuno di Legal. L2 possiede di fatto i record di L1 e di L3, ma nessun record del SOC. L3 possiede solo i propri. Legal resta isolato in entrambe le direzioni, ed è il modo corretto di dare al team legale un perimetro suo, non visibile al SOC.

Nota il dettaglio che la documentazione mette in evidenza: lo stesso effetto del SOC Team si otterrebbe mettendo i manager dentro ogni team, ma allora quei manager non potrebbero più possedere record in esclusiva. La gerarchia esiste proprio per evitare quel compromesso. E ricorda che ogni azione compiuta attraverso una relazione è comunque tracciata nell’audit log.

La navigazione mostra solo ciò che sei autorizzato a vedere

La barra di navigazione a sinistra è costruita sull’autorizzazione: espone i componenti e i moduli che puoi vedere, e dentro un modulo vedi i record della tua Ownership Sphere. Anche la ricerca globale rispetta l’autorizzazione e non restituisce risultati dai moduli su cui non hai Read.

La struttura del menu si modifica in Settings, Application Editor, Navigation. Tre cose da sapere. Le modifiche sono di sistema e valgono per tutti: non esiste una navigazione per utente. Le voci sono a uno o due livelli, e la voce di secondo livello che raggruppa non è un collegamento, lo sono solo i suoi sotto elementi. La prima voce dell’elenco è sempre la pagina di atterraggio dopo il login, per default il Dashboard, e si cambia riordinando. Per modificare serve almeno Read e Update sul modulo Application; per cancellare voci di navigazione o picklist serve anche Delete.