Un connettore dati non esiste finché non installi la soluzione che lo contiene. È il passo che salta chi arriva da AZ-500: cerchi Azure Activity fra i connettori e non lo trovi, perché la soluzione omonima non è ancora installata. Servono permessi di lettura e scrittura sul workspace, e il percorso è Data connectors, poi Open connector page.

Diagnostic settings: due modi, e uno solo scala

Le risorse Azure non parlano con Sentinel: scrivono sul workspace attraverso le diagnostic settings. Da qui due modalità.

La prima è la diagnostic setting standalone, che configuri risorsa per risorsa: dal menu della risorsa apri Diagnostic settings, aggiungi un’impostazione, spunti Send to Log Analytics, scegli il workspace di Sentinel e le categorie di log e metriche. Funziona, non scala.

La seconda usa Azure Policy e applica una sola configurazione a uno scope intero: sul connettore trovi il pulsante che lancia il wizard di assegnazione. Due cose da sapere. Per assegnare la policy serve il ruolo Owner sullo scope. E la policy si applica alle risorse create dopo: per quelle già esistenti devi spuntare Create a remediation task nella scheda Remediation, o il parco esistente resta scoperto. Nella scheda Parameters togli il flag che mostra solo i parametri obbligatori, o i tipi di log da abilitare non compaiono.

Le trappole per singola risorsa

Tre casi che non si comportano come ti aspetti.

Azure Activity passa ora dalla pipeline delle diagnostic settings. Se hai subscription collegate con il metodo legacy vanno scollegate tutte, con Disconnect All, prima di configurare il connettore nuovo: altrimenti raddoppi dati e spesa.

Storage account: la risorsa padre e i servizi figli sono oggetti distinti. Sul padre esporti la metrica Transaction; su ciascun figlio — blob, file, table, queue — esporti tutti i log e le metriche. Se configuri solo il padre non vedrai nessun accesso ai blob.

Azure DDoS Protection: lo stato del connettore diventa Connected solo mentre le risorse protette sono sotto attacco. Non è un guasto.

Per i connettori gestiti da policy vale poi una regola di stato che confonde: la spia verde significa “dati ingeriti negli ultimi 14 giorni”. Dopo 14 giorni a secco il connettore risulta scollegato, e torna verde appena arriva un evento. Infine il vincolo che non si aggira: una diagnostic setting non può puntare a un workspace che sta in un tenant diverso da quello della risorsa.

Syslog e CEF: dov’è davvero il collo di bottiglia

I connettori sono due, Syslog via AMA e Common Event Format (CEF) via AMA, con tabelle di destinazione diverse: Syslog per il syslog normale, CommonSecurityLog per il CEF. Il flusso è sempre lo stesso, con o senza log forwarder: gli apparati mandano i messaggi sulla porta 514 UDP o TCP del daemon della macchina Linux, rsyslog o syslog-ng; il daemon li consegna all’Azure Monitor Agent, sulla porta TCP 28330 dalla versione 1.28.11 in poi e tramite Unix domain socket nelle versioni precedenti; l’agente li spedisce al workspace.

I prerequisiti del forwarder sono tutti bloccanti. Deve essere una VM Azure o una macchina con l’agente Azure Arc Connected Machine: senza, non compare nemmeno nell’elenco delle risorse quando crei il DCR. Deve avere Python 2.7 o 3 e il daemon rsyslog o syslog-ng attivo. Lato Azure servono Virtual Machine Contributor o Azure Connected Machine Resource Administrator per installare l’agente, Monitoring Contributor per creare e modificare i DCR, e un ruolo che includa l’azione di deployment ARM.

Il DCR filtra, lo script apre la porta

La configurazione vive nella Data Collection Rule: scegli le macchine, poi nella scheda Collect la facility e il livello minimo di severità. Il livello è inclusivo verso l’alto: se selezioni LOG_ERR raccogli anche LOG_CRIT, LOG_ALERT e LOG_EMERG. Dal portale puoi indicare solo il minimo; per una selezione puntuale di livelli devi creare il DCR via API, dove facilityNames e logLevels sono espliciti e lo stream distingue i due formati:

"streams": [ "Microsoft-Syslog" ]              syslog
"streams": [ "Microsoft-CommonSecurityLog" ]   CEF

Creato il DCR e installato l’agente manca un passo, ed è qui che nasce la maggior parte dei “non arriva niente”: sul forwarder devi lanciare lo script di installazione, che riconfigura il daemon e apre la 514 in UDP e TCP.

sudo wget -O Forwarder_AMA_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Forwarder_AMA_installer.py&&sudo python Forwarder_AMA_installer.py

Il rischio è la doppia ingestione: se la stessa facility trasporta sia syslog sia CEF, gli stessi eventi finiscono in Syslog e in CommonSecurityLog, e li paghi due volte. Si risolve dedicando facility separate sui dispositivi sorgente, o aggiungendo al DCR una trasformazione in ingestione che scarti i messaggi CEF dallo stream syslog. Dalla versione 1.41 dell’agente il campo ProcessName non contiene sempre “CEF” per i vendor che non rispettano l’header RFC 3164 o 5424: il filtro va scritto su ProcessName e su SyslogMessage.

Verificare senza illudersi

Sul forwarder, netstat -lnptv deve mostrare il daemon in ascolto sulla 514; sudo tcpdump -i any port 514 or 28330 -A -vv fa vedere se il traffico arriva e se prosegue verso l’agente. Un messaggio di prova si genera con logger o nc. Poi pazienza: i log possono metterci fino a 20 minuti ad apparire nel workspace.

Un’ultima cosa che manda fuori strada nelle indagini: TimeGenerated è l’ora UTC in cui il forwarder ha processato il messaggio, mentre EventTime esce dall’header syslog, che non porta il fuso orario e viene convertita con l’offset locale del forwarder. Se apparato e forwarder stanno in fusi diversi, i due campi divergono.