Il primo bivio di un progetto FortiAnalyzer non è quanto disco comprare: è decidere che ruolo dare a ogni appliance. Le modalità operative sono due, Analyzer e Collector, e la scelta cambia quali menu esistono nella GUI.

Analyzer o Collector: cosa perdi davvero passando a Collector

Analyzer è la modalità predefinita e supporta tutte le funzioni. Il Collector ha un compito diverso: inoltrare i log dei device connessi verso un Analyzer e archiviarli. Invece di scriverli nel database li trattiene nel formato binario originale in attesa dell’upload, e gran parte delle funzioni risulta disabilitata.

Il confronto ufficiale è secco. Device Manager, System Settings e Log Forwarding restano in entrambe le modalità; FortiView, Incidents & Events, il monitoraggio dei device e il Reporting esistono solo in Analyzer; Log View in Collector si riduce ai soli raw archive log.

La ragione tecnica sta sotto: in Collector mode il database SQL è disabilitato per impostazione predefinita, quindi tutto ciò che dipende dal SQL non è disponibile finché non lo abiliti a mano. È la trappola più frequente di chi eredita un Collector e non capisce perché Log View sembri vuoto. Lì la strada giusta è Log View > Logs > Log Browse, selezionando il file più recente: è così che si guardano i messaggi correnti su un Collector.

Il cambio di modalità si fa dal widget System Information in Dashboards > Status, campo Operation Mode. Cambia anche come allochi il disco: sul Collector la maggior parte dello spazio va agli Archive log, tenuti quanto basta ai requisiti normativi; sull’Analyzer va agli Analytics, con una finestra tipica di 30-90 giorni.

Farli collaborare: chi inoltra, chi accetta

Lo schema classico è la sede remota con FortiGate e FortiAnalyzer in Collector, la sede centrale con un FortiAnalyzer in Analyzer: il Collector scarica l’Analyzer dal lavoro di ricezione, così l’Analyzer si concentra su analisi e report.

Servono tre pezzi, e saltarne uno è l’errore più comune. Sul Collector configuri il log forwarding con Remote Server Type su FortiAnalyzer, l’IP dell’Analyzer e la selezione esplicita dei device. Sull’Analyzer verifichi che il servizio di aggregazione sia attivo:

config system log-forward-service
    set accept-aggregation enable
end

Poi — il passaggio che manca quasi sempre — aggiungi e autorizzi sull’Analyzer il FortiGate della sede remota: finché quel device non esiste nella sua tabella, i log arrivano e non trovano casa.

C’è anche il caso inverso, recuperare log a posteriori dal Collector: lì i ruoli si ribaltano rispetto all’intuito, perché il Collector fa da fetch server e l’Analyzer da fetch client.

Per vedere chi manda log a chi c’è System Settings > Advanced > Logging Topology, che disegna la topologia fisica dei device del Fabric: il tasto destro offre View Related Logs e porta in Log View già filtrato.

ADOM: chi vede cosa, e con quanto disco

Gli ADOM limitano l’accesso di un amministratore a un sottoinsieme di device, e sui prodotti con VDOM possono restringere ai dati di un singolo VDOM. Sono disabilitati per default e solo un profilo Super_User può abilitarli, dal toggle Administrative Domain nel widget System Information: al termine vieni disconnesso e devi rientrare.

Tre cose da sapere prima di disegnarli. Un device non può stare in due ADOM. Gli ADOM vanno abilitati per supportare logging e reporting dei device non FortiGate, quindi con FortiMail, FortiWeb o FortiSandbox in progetto la scelta è già fatta. E ogni ADOM porta con sé la propria politica di storage, in System Settings > ADOMs.

Il device mode è Normal per default: un FortiGate entra in un solo ADOM, VDOM compresi. In Advanced puoi assegnare singoli VDOM ad ADOM diversi, ma è raccomandato solo agli utenti esperti, e per tornare a Normal devi prima liberare tutti i VDOM assegnati. Con gli ADOM attivi il root ADOM è di tipo Fabric: mostra risultati combinati di tutti i device del Security Fabric in Device Manager, Log View, FortiView, Incidents & Events e Reports.

Disabilitarli non è simmetrico: prima sposti tutti i device nel root ADOM, poi cancelli gli ADOM non-root, e solo allora il toggle si spegne.

Autorizzare i device senza sorprese

Un device configurato per inviare log ma non ancora autorizzato compare nel root ADOM sotto Unauthorized Devices, raggiungibile dalla quick status bar. Finché non lo autorizzi, FortiAnalyzer non riceve i suoi log. Se ne autorizzi più d’uno insieme finiscono tutti nello stesso ADOM, e se le versioni firmware non coincidono con quella dell’ADOM ricevi un Version Mismatch Warning: puoi procedere, ma parte della sintassi potrebbe non essere pienamente supportata.

Due dettagli che risolvono ticket. L’autorizzazione presuppone l’account admin predefinito senza password: se è stata cambiata il processo fallisce, e il rimedio è cancellare il device e riaggiungerlo con l’Add Device wizard, dove credenziali, numero di serie o pre-shared key si dichiarano esplicitamente. E soprattutto: cancellando un device i suoi file di log raw se ne vanno con lui, mentre i log già nel database SQL restano.

L’autorizzazione resta comunque metà del lavoro: il device va anche configurato per inviare, sul FortiGate in Log & Report > Log Settings, opzione Send Logs to FortiAnalyzer/FortiManager.

Sul fronte Fabric, la correlazione fra traffic log e UTM log tra membri diversi dello stesso Cooperative Security Fabric non richiede alcuna configurazione: FortiAnalyzer costruisce da sé i riferimenti UTM, tenendo conto anche del NAT. I connettori invece si dichiarano a mano, in Incidents & Events > Automation > Active Connectors.