La domanda «come lo installo» sembra da amministratore, ma qui è da analista: il modello di deployment decide dove possono girare le azioni dei connettori, e quindi decide quali playbook riesci a far funzionare davvero. Un’azione che non raggiunge l’endpoint è un playbook che fallisce, e il modo in cui FortiSOAR risolve quel problema ha nomi e vincoli precisi.

Le forme in cui FortiSOAR si installa

Il nodo singolo si ottiene in due modi: importando la virtual appliance (OVA per VMware, ESX/ESXi e AWS, oppure KVM) o lanciando l’installer su un sistema con Rocky Linux 9.3 o RHEL 9.3. Esiste anche il deployment Docker, incluso quello su un cluster Amazon EKS. Sopra il nodo singolo c’è il cluster in alta disponibilità, con heartbeat e replica fra i nodi.

Ci sono poi due forme che chi studia a memoria dimentica sempre: FortiSOAR è disponibile come servizio ospitato su FortiCloud, ed è disponibile come Management Extension Application (MEA) su FortiAnalyzer e su FortiManager. Se una domanda elenca i modelli di deployment e la MEA compare fra le opzioni, è corretta.

I prerequisiti dell’installer sono un campo minato, perché sono controintuitivi:

- installa su un OS NON preindurito: l'hardening lo applica FortiSOAR dopo l'installazione
- locale obbligatoria en_US.UTF-8, altrimenti il servizio postgresql-16 non parte
- disabilita IPv6 se non lo usi (i file ifcfg sono deprecati da RHEL/Rocky 9.0)
- non modificare /etc/sudoers: gli utenti che FortiSOAR aggiunge servono al prodotto

Indurire l’OS «per sicurezza» prima di installare è l’errore classico: porta a installazioni fallite, servizi che non partono e problemi di permessi sui file. E dalla 7.5.0 le OVA hanno layout disco GPT, il che serve per superare i 2 TB: un’istanza più vecchia non si allarga, si migra su una VM nuova con i wizard di export e import.

Il secure message exchange è il perno

Quando gli endpoint su cui vuoi eseguire azioni stanno in un altro segmento di rete, FortiSOAR non chiede una VPN. Introduce un componente leggero, l’FSR Agent, che si registra su un secure message exchange (SME) e da lì riceve ed esegue le azioni dei connettori.

La caratteristica da ricordare parola per parola è la direzione del traffico: l’agent ha bisogno soltanto di connettività in uscita verso il secure message exchange sulla sua porta TCP. Non serve una VPN e non serve alcuna connettività in ingresso verso l’agent. È il motivo per cui questo modello passa i firewall interni. E il secure message exchange non richiede licenze aggiuntive.

L’autenticazione fra agent e SME può essere Basic Auth o Certificate Auth. Cambiare strategia o rinnovare i certificati senza rigenerare il canale lascia l’agent bloccato in «Remote Node Unreachable». E se sposti un nodo su un SME diverso le due procedure non coincidono: un tenant va riconfigurato, un agent richiede di riscaricare ed eseguire di nuovo l’installer sulla macchina dell’agent.

Agent o tenant dedicato

Questa è la distinzione su cui l’esame insiste, ed è netta. Un FSR Agent può rappresentare un agent standalone piazzato presso un endpoint, oppure può rappresentare un tenant dedicato. Ma il criterio di scelta è funzionale:

Se il requisito è eseguire azioni dei connettori in remoto, l’agent basta e avanza. Se invece servono capacità di incident management, oppure devi ingerire grandi volumi di dati da una sorgente in una rete remota, allora ti serve un’istanza tenant dedicata: l’agent non è sufficiente. Rispondere «agent» a una domanda che nomina l’incident management è un punto perso, e non c’è credito parziale.

Su un singolo nodo enterprise puoi installare più agent, uno per segmento, ed è la scelta giusta quando mettere un nodo FortiSOAR completo in ogni segmento non è praticabile.

Vivere con gli agent

Lo stato di un agent è «Remote Node Connected» oppure «Remote Node Unreachable», e non è una decorazione: i menu a tendina che ti fanno scegliere l’agent — nella configurazione del connettore, nello step di playbook, nella finestra di installazione di un connettore — elencano soltanto gli agent connessi. Un agent che non compare non è un bug della UI.

I permessi minimi per far girare azioni tramite agent sono Execute su Connectors e Read su Application e Agents. Se usi connettori listener-based, che restano in ascolto e innescano playbook di ingestion, l’appliance dell’agent deve avere anche Execute su Playbooks: senza, il connettore ascolta e non innesca nulla.

Un vincolo che sorprende: su un agent puoi installare solo connettori che sono già installati sul nodo FortiSOAR. Per il resto c’è la CLI csagent, che importa e configura connettori, ne verifica lo stato di salute ed esegue operazioni:

csagent --option check_health --name NOME --version VERSIONE --config CONFIG
csagent --option execute --name NOME --version VERSIONE --config CONFIG -operation AZIONE

Il file che dice all’agent a quale nodo e a quale SME agganciarsi è agent_config.yml, sotto /opt/cyops-integrations/integrations/configs/.

Infine la trappola più sgradevole, perché è silenziosa. In uno step di playbook puoi risolvere l’agent dinamicamente indicando il nome della configurazione, anche con un’espressione Jinja. Se quel nome è sbagliato, lo step non fallisce: viene eseguito con la configurazione predefinita del connettore sul sistema locale, non sull’agent. L’azione parte dal posto sbagliato e nessun errore te lo dice. In ambiente multi-tenant, sul nodo master, l’opzione «Pick From Record’s Ownership» evita il problema alla radice, perché legge il tenant dal record e sceglie l’agent di conseguenza.