Tutto ciò che in FortiSOAR sembra «una schermata» è un modulo, cioè un modello di dati con campi e relazioni descritti in un file di metadati, l’mmd. Conoscere questo strato spiega perché un Publish fallisce, o perché cancellando un alert sono spariti anche i suoi eventi.

Moduli e record: le proprietà che decidono il comportamento

Un modulo dà accesso a un modello di dati nel database; un record è un’istanza di quel modello. Il Module Editor si apre sulla scheda Summary, e ogni casella lì dentro cambia il comportamento a runtime.

Il nome singolare genera plurale e Type, cioè l’identificatore del modulo nell’API. Il Display Template stabilisce come un record viene etichettato quando è referenziato altrove. Record Uniqueness definisce la combinazione di campi che impedisce i duplicati: negli Indicators, Type più Value.

Poi ci sono gli interruttori che l’esame ama:

Team Ownable          record di proprietà di team; se NON attivo sono pubblici
User Ownable          record di proprietà di utenti o appliance
Trackable             traccia chi ha creato e modificato il record, e quando
Taggable              consente i tag sui record
Queueable             il modulo è assegnabile tramite le code
Enable Recycle Bin    cancellazione soft, con ripristino
Enable Multi-Tenancy  aggiunge il campo Tenant e abilita la replica

Due vincoli irreversibili. Dopo la creazione non si toccano Type e Table Name, e il nome singolare più una «s» genera l’endpoint API: rinominarlo rompe le chiamate esistenti. E Enable Recycle Bin non è selezionabile per i moduli di sistema — People, Appliances, Agents, Approvals, Tenants, Routers, Comments, Saved Reports — i cui record vengono sempre cancellati in modo definitivo.

Campi: dove si perde il punto

Il Field Title genera il Field API Key, che poi non cambia più. Puoi rinominare l’etichetta quanto vuoi: la chiave resta quella della creazione, perché non esiste migrazione dal vecchio nome al nuovo.

I tipi coprono testo, numeri, data/ora, checkbox, file, JSON, picklist e relazioni. Il sottotipo raffina: per il testo hai Text Field, Rich Text (Markdown), Rich Text (HTML), Text Area, IPv4, IPv6, Domain, URL, Filehash; per la data hai Date o Date/Time, e un campo Date fissa l’ora a mezzanotte. Il tipo JSON è la scelta giusta per campi come Source Data: consente ai playbook di leggere il JSON senza uno step di parsing.

Le opzioni che vanno sapute a memoria sono queste. Encrypted cifra il valore in AES-256. Il prezzo è alto: su un campo cifrato non puoi cercare, i filtri non funzionano e l’upsert non è utilizzabile. Visibility su Hidden rende il campo accessibile solo via API, e la documentazione avverte di non combinare Hidden con Required (by condition). Searchable lo rende cercabile nella griglia; Default Grid Column lo mostra come colonna, nell’ordine dei campi nel Fields Editor.

I campi di sistema sono in sola lettura. L’unica eccezione è la modifica una tantum, ammessa quando il valore era nullo o quando il campo è tenant con valore self: al momento della creazione di un alert il tenant vero spesso non è ancora determinabile.

Relazioni: la causa numero uno di Publish falliti

I tipi di relazione sono Lookup (One to Many o One to One), Many to One e Many to Many. Scegliendone uno compare Related Model, e devi indicare il modulo correlato e il Field Title prima di pubblicare.

Qui sta l’errore che blocca il lavoro: se aggiungi un campo Many to One, sul modulo correlato deve esistere un campo Lookup corrispondente. Se manca, il Publish fallisce con un messaggio esplicito: per quel campo many-to-one non è presente alcun campo lookup nel modulo correlato. Nel caso Many to Many, invece, FortiSOAR aggiunge da solo il campo sul lato opposto.

L’opzione Delete Associations With Parent va maneggiata con paura: cancella a cascata i figli di una relazione Many to One, e per i figli l’RBAC non viene applicato. Con Delete sugli Alerts ma non sugli Events, cancellare un alert cancella comunque i suoi eventi. Senza quell’opzione vale la regola normale: cancellare un record elimina i suoi legami, non le entità collegate.

Picklist e correlazione visiva

Il Picklist Editor si comporta all’opposto del Module Editor: le modifiche sono attive subito al salvataggio, perché nomi e valori delle picklist sono record nel database. Ogni valore è identificato da un UUID, quindi rinominare «Theft» in «Physically Stolen» aggiorna tutti i record esistenti senza rompere nulla. I nomi degli item non ammettono questi caratteri:

{ } ( ) / \ @ :

I colori si assegnano in esadecimale e più item possono condividere lo stesso colore. Ogni item può essere Visible, Disabled, Hidden, Conditionally Visible o Conditionally Enabled: Hidden lo nasconde in creazione e modifica, ma resta ricercabile.

Il widget Visual Correlation disegna il grafo dei record collegati; si configura in Correlation Settings scegliendo per ciascun modulo Node Label, Node Shape e Node Color. La profondità predefinita dei nodi è 3, e si va oltre con un doppio clic. Alerts, Assets, Incidents, Indicators e War Rooms sono già preconfigurati; se aggiungi come modulo correlato uno che non lo è, devi configurarlo tu, altrimenti la correlazione non funziona. Se il campo del colore è una picklist, il colore del nodo è quello del valore: la coerenza del grafo dipende dal Picklist Editor.

Promemoria trasversale: nel Module Editor Save mette in staging, Publish scrive lo schema, mette il sistema offline per qualche minuto ed è irreversibile.