Scegliere il data connector in base alla sorgente

In Microsoft Sentinel l’ingestion decide quali detection potrai scrivere e quanto costerà tenerle accese. Il ragionamento parte dalla sorgente, non dal connettore. Per i servizi first-party Microsoft esiste quasi sempre un connettore nativo che porta i dati nelle tabelle attese: Microsoft Entra ID alimenta SigninLogs e AuditLogs, il connettore Microsoft Defender XDR porta alert e incident in SecurityAlert e SecurityIncident. Per le terze parti la domanda diventa: l’appliance parla CEF, syslog generico o REST API, e dove può girare un agente?

Il fatto più penalizzato d’esame: il Log Analytics agent (MMA/OMS) è ritirato. L’unico agente supportato è Azure Monitor Agent (AMA), che non ha una configurazione propria: raccoglie solo ciò che una data collection rule (DCR) gli dice di raccogliere. La DCR è una risorsa associata a una o più macchine (Azure, Arc-enabled o on-premises) e definisce sorgente, filtro e destinazione.

Windows Security Events, AMA e DCR

Il connettore Windows Security Events via AMA porta il security event log dei server Windows nella tabella SecurityEvent. Puoi scegliere un set predefinito (tutti gli eventi, comune, minimo) o una selezione custom via query XPath.

Qui sta il trade-off: più eventi raccogli, più detection e hunting sono possibili, ma il volume è la voce di costo dominante del workspace. La leva corretta per contenerlo è modificare la DCR, filtrando per event ID o canale — non disinstallare agenti né spegnere il connettore. La stessa leva vale al contrario: se una analytics rule non scatta perché l’event ID che cerca non arriva, il problema è quasi sempre nella DCR, non nella query KQL. Per verificare che una macchina stia ancora inviando dati usa Heartbeat.

Una macchina può ricevere più DCR: è così che si differenzia la raccolta fra domain controller (verbosi) e server applicativi (minimali) senza duplicare configurazioni.

Quando l’agente non si può installare: WEF

Su parchi legacy o host dove le policy vietano l’agente ovunque, la risposta è Windows Event Forwarding: i client inoltrano gli eventi via WinRM a un collector centrale tramite subscription, e AMA con la relativa DCR sta solo sul collector. Attenzione: il connettore Windows Forwarded Events scrive in una tabella propria (WindowsEvent), non in SecurityEvent.

Syslog, CEF, attività Azure e tabelle custom

Firewall, proxy e appliance di rete non ospitano agenti. Il pattern è un log forwarder Linux con AMA che riceve i messaggi dai dispositivi e li consegna secondo la DCR:

  • Syslog via AMA per messaggi syslog generici: filtri per facility e severity nella DCR, dati in Syslog.
  • CEF via AMA quando l’appliance emette Common Event Format: i campi arrivano normalizzati in CommonSecurityLog, molto più utile per correlare vendor diversi.

Le attività del control plane di Azure (chi ha creato, modificato o eliminato risorse) arrivano in AzureActivity tramite diagnostic setting verso il workspace; per garantirne la copertura su decine di subscription si usa Azure Policy, che applica il setting anche alle risorse future.

Ciò che nessun connettore copre — un applicativo interno, un log proprietario — si porta in tabelle di log custom definite tramite DCR e Logs ingestion API (con data collection endpoint); per le API REST di terze parti esiste la codeless connector platform. È la scelta di ultima istanza: nessun parser e nessuna regola pronta.

Trappole tipiche d’esame

  • Ridurre il costo di ingestion mantenendo le detection sui logon → filtrare la DCR per event ID: cambiare tier o rimuovere il connettore sono i distrattori; solo il filtro lato DCR taglia volume senza perdere gli eventi che servono.
  • Un’opzione propone di installare il Log Analytics agent (MMA) → è ritirato: qualunque risposta basata su MMA/OMS è errata; l’agente è AMA e la configurazione vive nella DCR.
  • Centinaia di host Windows senza agente su ognuno → Windows Event Forwarding verso un collector con AMA: un solo punto di raccolta, ma i dati finiscono in WindowsEvent, non in SecurityEvent.
  • Firewall di terze parti che emette CEF → CEF via AMA su un forwarder Linux, tabella CommonSecurityLog: se lo scenario parla di syslog non strutturato è invece Syslog via AMA e tabella Syslog.
  • Tracciare le operazioni sulle risorse Azure in tutte le subscription, incluse quelle future → diagnostic setting applicato via Azure Policy, tabella AzureActivity: la configurazione manuale per singola subscription è la risposta che non scala.
  • Sorgente applicativa senza connettore → tabella custom con DCR e Logs ingestion API: non forzare quei dati in una tabella standard; parser e analytics rule vanno scritti da zero.