«Il playbook non parte» sono in realtà due guasti diversi, e la prima mossa serve a separarli: o il playbook non è mai stato innescato, oppure è partito e un task è morto per strada. Sono percorsi di diagnosi che non si assomigliano. La domanda da farsi per prima è sempre la stessa: esiste un job?

Il Playbook Monitor è il primo posto dove guardare

Sotto Incidents & Events, in Automation, la scheda Playbook Monitor elenca i job. Ogni riga porta un Job ID (data, ora di avvio e un numero univoco), il nome del playbook, l’utente che l’ha avviato se il trigger era On Demand, gli orari e lo stato.

Gli stati del job sono tre: Running, Success e Failed. L’icona Details apre la finestra Playbook Tasks con lo stato di ogni singolo task, e lì gli stati diventano quattro:

  • Scheduled: schedulato.
  • Success: completato correttamente.
  • Failed: non completato.
  • Upstream_failed: fallito perché il task non è riuscito a contattare un dispositivo a monte.

Una sottigliezza da avere in testa: un job con anche un solo task fallito viene etichettato Failed, ma le singole azioni possono essere andate a buon fine. Se la quarantena dell’endpoint ha dato Success e il task del ticket ha dato Failed, l’endpoint è in quarantena davvero. Non rilanciare il playbook per riflesso: rischi di rieseguire le azioni riuscite.

Se invece non c’è nessuna riga, l’esecuzione non è mai cominciata e il problema è a monte.

Nessun job: trigger, abilitazione, ADOM, permessi

I sospettati sono pochi e si controllano in ordine.

Il playbook è abilitato? Nell’editor c’è un toggle Enabled, e solo i playbook abilitati partono quando le condizioni del trigger sono soddisfatte. Uno salvato ma disabilitato non lascia traccia da nessuna parte.

Il trigger è quello che credi? Ogni playbook ne ammette uno solo. Se è ON_DEMAND non partirà mai da sé: va lanciato a mano dall’elenco dei playbook o dalla pagina Incident Analysis di un incidente. Se è ON_SCHEDULE controlla inizio, fine e frequenza. Se è EVENT_TRIGGER o INCIDENT_TRIGGER, i filtri si combinano in All o Any: un filtro troppo stretto non genera niente, ma anche il caso senza filtri è insidioso, perché lì il playbook parte su qualunque evento.

Sei nell’ADOM giusto? Con gli ADOM abilitati ciascuno ha i propri event handler e la propria lista di eventi, e i connettori FortiOS esistono solo negli ADOM FortiGate e Fabric.

Chi doveva lanciarlo aveva il permesso? Per gestire i playbook serve Read-Write su Incidents & Events. Il profilo tipico dell’analista ha invece Read-Only più qualche permesso puntuale in Read-Write, fra cui Execute Playbook, che è quello che consente di vedere ed eseguire un playbook. Senza, l’analista non riesce a far partire un ON_DEMAND: non è un guasto del playbook.

Il job parte ma un task muore: quasi sempre è il connettore

Quando il job c’è e il task è Failed o Upstream_failed, torna in Active Connectors e guarda il pallino: rosso è connessione API caduta, arancione stato sconosciuto. Upstream_failed dice proprio che il task non ha raggiunto il dispositivo a monte: credenziali, raggiungibilità e stato del connettore vengono prima di ogni ipotesi sulla logica del playbook.

Due classici.

L’azione FortiOS non compare nel menu del task. Non è un bug: le azioni del connettore FortiOS sono le automation rule del FortiGate, e appaiono solo se usano il trigger Incoming Webhook e sono abilitate in FortiOS. Le regole omonime su più FortiGate vengono poi mostrate una volta sola, perché FortiAnalyzer le tratta come la stessa regola: se ti aspettavi due voci e ne vedi una, è normale. Con più connettori il dispositivo viene scelto in base al devid indicato nel task, a mano o passato da un task precedente: se quel valore non arriva, il task non sa a chi parlare.

Il connettore FortiClient EMS Cloud resta rosso. Dopo la creazione manda una richiesta di autenticazione da approvare dentro EMS, in Administration > Fabric Devices: finché nessuno la approva, non funziona nulla che dipenda da quel connettore.

Dati che non arrivano e falsi allarmi sull’enrichment

Se il task gira ma riceve un valore vuoto, sospetta le variabili. I task ID non sono visibili dentro il task: si leggono col giro documentato dell’azione Local Attach Data to Incident, selezionando il task precedente nel menu Attachment e passando alla modalità testo. Una variabile di output che punta al task ID sbagliato non dà un errore rumoroso, dà un input vuoto.

Sull’arricchimento degli indicatori tre cose sembrano guasti e non lo sono: il playbook Indicator Enrichment è abilitato di default ed è in sola lettura; VirusTotal non restituisce niente finché non inserisci la API key e non abiliti il connettore; gli IP privati non sono indicatori validi, quindi l’opzione Enrich può non comparire. E l’indicatore viene processato solo dopo Save Enrichment.

Un playbook importato non è quello che stai modificando

Chiudo con l’errore più subdolo. Quando importi un playbook omonimo di uno esistente, FortiAnalyzer non sovrascrive e non chiede conferma: crea un nuovo nome che include il timestamp dell’import.

Ti ritrovi così due playbook quasi identici. Se ne modifichi uno e ne resta abilitato un altro, passerai il pomeriggio a chiederti perché le modifiche non hanno effetto, o perché ogni evento produce due job. E in export ricordati del toggle sui connettori: un playbook importato senza i suoi fallirà sui task, non sul trigger.