#sentinel

Il problema del “connector sprawl” nei SOC multi-tenantChi gestisce un SOC (Security Operations Center) per un’organizzazione di dimensioni medio-grandi conosce bene un problema che raramente compare nelle demo dei prodotti #SIEM: le aziende moderne non vivono con un solo account per servizio. Un gruppo con più business unit può avere diversi tenant Auth0 segmentati per prodotto, più ambienti CrowdStrike Falcon per effetto di fusioni e acquisizioni, o più organizzazioni Salesforce distinte per area geografica o #normativa.

Fino a oggi, portare tutta questa telemetria dentro un’unica workspace Microsoft #Sentinel significava scontrarsi con un limite architetturale del modello dei connector: un connector, un account. Il risultato erano configurazioni duplicate, script custom per aggregare i dati, o — nello scenario peggiore — interi ambienti lasciati fuori dal perimetro di monitoraggio per semplice sovraccarico operativo. Microsoft ha ora affrontato direttamente questo problema con il supporto multi-account per tre connector molto usati in ambito enterprise.

Cosa cambia: supporto multi-account per Auth0, CrowdStrike Falcon e SalesforceCon l’aggiornamento annunciato sul Microsoft Sentinel Blog, i data connector per Auth0, CrowdStrike Falcon e Salesforce Service #Cloud supportano ora l’ingestione da più account o tenant attraverso un’unica configurazione di connector. La funzionalità si appoggia al Codeless Connector Framework (CCF), il framework che Microsoft utilizza per costruire connector dichiarativi senza dover scrivere codice custom per ogni integrazione.

Nello specifico, per ciascuna delle tre piattaforme cambia questo:

Auth0 — Multi-Tenant Identity Monitoring: i team che gestiscono più tenant Auth0 possono ora far confluire eventi di autenticazione, pattern di login anomali e violazioni di policy da tutti i tenant in un’unica workspace Sentinel, senza dover cambiare contesto per ogni ambiente.

CrowdStrike Falcon — Telemetria endpoint consolidata: le organizzazioni con più tenant Falcon (tipicamente per effetto di M&A o strutture regionali separate) possono ora far confluire detection alert, threat intelligence ed endpoint telemetry da tutti i tenant in un’unica pipeline di ingestione.

Salesforce Service Cloud — Insight cross-org: le aziende con più organizzazioni Salesforce possono centralizzare audit log, cronologia dei login e attività API su tutte le org, semplificando il rilevamento di insider threat, accessi non autorizzati e gap di #compliance senza dover correlare manualmente dati provenienti da fonti separate.

Come funziona in pratica: il workflow “Add Account”Il punto di forza dell’implementazione è la sua semplicità operativa. Non serve distribuire una nuova istanza del connector per ogni account: il connector esistente espone un nuovo comando che permette di aggiungere account aggiuntivi alla stessa configurazione. Il flusso, come descritto da Microsoft, si riduce a pochi passaggi:

Aprire Microsoft Sentinel → Data Connectors nel portale #Azure.

Cercare il connector desiderato (Auth0, CrowdStrike Falcon o Salesforce).

Aprire il connector e selezionare l’opzione “Add Account”.

Autenticare e autorizzare l’account aggiuntivo (tramite le credenziali/API key specifiche della piattaforma).

Avviare l’ingestione: i dati del nuovo account confluiscono automaticamente nella stessa tabella di log della workspace.

Un dettaglio operativo rilevante per chi già gestisce regole di detection in produzione: le analytics rule, i workbook e i playbook esistenti continuano a funzionare senza modifiche, perché operano sullo stesso schema di dati indipendentemente dal numero di account collegati. Non è quindi necessario duplicare le regole di correlazione per ogni tenant aggiunto: una singola query KQL scritta per rilevare, ad esempio, tentativi di login falliti ripetuti su Auth0 continuerà a funzionare — e a coprire — tutti i tenant collegati al connector, con la possibilità di filtrare o raggruppare per account direttamente nella query se serve un’#analisi granulare.

Perché conta per chi gestisce un SOCAl di là dell’annuncio, il valore pratico di questa funzionalità si misura su tre assi che chiunque abbia gestito un ambiente Sentinel multi-tenant riconoscerà:

Riduzione del carico di configurazione. Ogni connector duplicato è una configurazione da mantenere, da tenere sotto controllo per la scadenza delle credenziali, da documentare separatamente. Consolidare in un’unica configurazione riduce direttamente il lavoro di manutenzione ricorrente.

Eliminazione dei blind spot. È comune che un ambiente “secondario” (un tenant acquisito di recente, una org regionale minore) resti fuori dal monitoraggio semplicemente perché configurarlo separatamente non è mai stata la priorità. Abbassare la barriera operativa per aggiungere un account rende più probabile che venga effettivamente monitorato.

Indagini cross-environment più semplici. Durante un incident response, poter interrogare un’unica tabella per correlare eventi provenienti da più tenant/org, invece di dover incrociare manualmente dati da workspace o strumenti diversi, accorcia sensibilmente il tempo di analisi.

Cosa considerare prima di attivarloQualche aspetto pratico da valutare prima del rollout in un ambiente esistente:

Volume di ingestione e costi. Consolidare più account nello stesso connector aumenta il volume di dati ingeriti nella workspace Sentinel: vale la pena rivedere le stime di costo (Sentinel fattura in base al volume di dati analizzato/ingerito) prima di collegare tutti gli account contemporaneamente.

Permessi e segregazione. Se la governance interna richiede una separazione netta tra i dati di sicurezza di business unit diverse (ad esempio per requisiti normativi regionali), verificate come vengono gestiti i controlli di accesso a livello di query/workbook nella workspace condivisa, dato che i dati di più account convivono nelle stesse tabelle.

Compatibilità delle credenziali API. Ogni account aggiunto richiede la propria autenticazione verso la piattaforma di origine (API key Auth0, credenziali API CrowdStrike, connected app Salesforce): pianificate la rotazione delle credenziali per ciascun account separatamente.

Microsoft indica inoltre che il supporto multi-account continuerà a essere esteso ad altri connector nei prossimi rilasci, segno che il modello “un connector, molti account” diventerà probabilmente lo standard per le integrazioni costruite sul Codeless Connector Framework, non un’eccezione limitata a queste tre piattaforme.

ConclusionePer i team che gestiscono Microsoft Sentinel su ambienti articolati — gruppi con più società, aziende cresciute per acquisizioni, organizzazioni con presenza multi-regionale — questo aggiornamento rimuove uno degli attriti operativi più concreti nella gestione quotidiana del SIEM. Vale la pena rivedere oggi stesso la configurazione dei connector Auth0, CrowdStrike Falcon e Salesforce già in uso, capire quanti account “orfani” non sono ancora monitorati per pura complessità di setup, e valutare la migrazione verso la configurazione multi-account, tenendo d’occhio l’impatto sul volume di ingestione prima di collegare tutto in blocco.

Fonte: Microsoft Security Community Blog.

Il SOC incontra il GitOpsCon l’aggiornamento di luglio 2026, Microsoft Sentinel porta la logica DevOps fin dentro il cuore del rilevamento delle minacce: le regole di detection personalizzate entrano ufficialmente tra i contenuti gestibili come Detections-as-Code (DaC) tramite le Sentinel Repositories, mentre un nuovo pannello Table Insights rende finalmente leggibile a colpo d’occhio lo stato di salute dell’ingestion. Sono due funzionalità distinte ma complementari, ed entrambe parlano direttamente a chi in azienda gestisce SIEM e pipeline CI/CD con lo stesso approccio.

Detections-as-Code: le regole di rilevamento come contenuto versionatoMicrosoft Sentinel Repositories esisteva già per contenuti come analytics rules, automation rules, hunting queries, parser, playbook e workbook: la novità è che ora anche le regole di detection personalizzate (custom detection rules) rientrano in questo flusso, gestibili tramite la Microsoft Security Bicep extension. Il repository esterno — GitHub o Azure DevOps — diventa la single source of truth: qualunque modifica fatta manualmente dal portale di Sentinel viene sovrascritta alla successiva sincronizzazione dal repository.

Per collegare un repository servono permessi precisi, spesso motivo di attrito nei team più strutturati:

ruolo Owner sul resource group che contiene il workspace Sentinel, per creare la connessione;

accesso Collaborator sul repository GitHub, oppure Project Administrator su Azure DevOps;

GitHub Actions abilitate (o Pipelines per Azure DevOps);

per Azure DevOps, la connessione deve risiedere nello stesso tenant del workspace Sentinel.

Ogni workspace Sentinel è limitato a cinque connessioni repository, e ogni resource group a 800 deployment nella sua history — un limite da tenere presente se si pianifica una struttura multi-repo per team o ambienti diversi.

Bicep, non ARM JSON: la scelta consigliataMicrosoft consiglia esplicitamente Bicep rispetto ai template ARM JSON grezzi per descrivere le regole. Un paio di dettagli tecnici da non sottovalutare in fase di migrazione:

i file Bicep non supportano la proprietà id: le regole esportate da Sentinel la includono, e va rimossa manualmente prima della decompilazione;

per una decompilazione pulita da ARM JSON a Bicep conviene forzare lo schema alla versione 2019-04-01;

le connessioni create prima del 1° novembre 2024 non supportano Bicep e vanno rimosse e ricreate per abilitarlo.

Per chi parte da zero, il repository ufficiale SentinelCICD/RepositoriesSampleContent fornisce template di esempio per ogni tipo di contenuto, comprese le funzionalità avanzate delle connessioni repository.

Smart deployments: non ridistribuire ciò che non è cambiatoUna delle frizioni tipiche del content-as-code applicato a un SIEM è il rischio di ridistribuire regole invariate a ogni deploy, resettando ad esempio schedule dinamici delle analytics rule. Sentinel risolve il problema con gli smart deployments: un file CSV nella cartella .sentinel del repository tiene traccia dei commit e il workflow evita di ridistribuire contenuti non modificati dall’ultimo deploy. È abilitato di default sulle nuove connessioni; per disattivarlo (e forzare sempre il deploy completo) si interviene sul file YAML del workflow o della pipeline.

Il flusso operativo tipico diventa quindi: un analista propone una nuova regola di detection in una pull request, il team la revisiona come farebbe con codice applicativo, al merge la pipeline CI/CD (GitHub Actions o Azure Pipelines) distribuisce automaticamente solo le modifiche nel workspace Sentinel collegato — con audit trail completo su chi ha cambiato cosa e quando, cosa che il portale da solo non garantisce con la stessa granularità.

Table Insights: capire l’ingestion senza scrivere KQLLa seconda novità rilevante del mese è Table Insights, un nuovo pannello nella pagina Tables della configurazione di Sentinel (Defender portal → Microsoft Sentinel → Configuration → Tables). Mostra, senza bisogno di query KQL manuali:

il volume di ingestion degli ultimi 30 giorni, suddiviso per tier (Analytics vs Auxiliary/Data Lake);

le variazioni giorno su giorno e settimana su settimana, utili per individuare picchi o cali anomali;

le tabelle che consumano più ingestion, per stimare rapidamente i costi;

i connettori che hanno smesso di inviare dati — spesso il primo sintomo di un problema di raccolta che altrimenti si scopre solo durante un’investigazione, quando è troppo tardi.

Chi preferisce restare in KQL può ottenere una vista equivalente sfruttando il campo Plan della tabella Usage, che permette di scomporre l’ingestion per Analytics, Basic e Auxiliary direttamente in query native — utile per costruire dashboard personalizzate o alert di costo oltre al pannello grafico.

Nuovi connettori datiL’aggiornamento di luglio amplia anche la copertura dei data connector con il supporto nativo per GitHub Enterprise, Agari, Airlock Digital e Gigamon — un’estensione che si allinea bene proprio con l’adozione di Detections-as-Code, dato che GitHub Enterprise diventa ora sia sorgente di log di audit sia repository di regole.

Perché conviene iniziare oraPer un SOC maturo, la combinazione di queste due funzionalità è più significativa della somma delle parti: Detections-as-Code porta revisione tra pari, versionamento e rollback affidabile sulle regole di rilevamento, mentre Table Insights riduce il tempo necessario per accorgersi che una sorgente di log si è interrotta silenziosamente — un problema che, senza query dedicate, spesso passa inosservato per settimane. Chi gestisce già Infrastructure-as-Code su Azure con Bicep o Terraform troverà il modello concettuale familiare; la parte più delicata resta la migrazione delle regole esistenti dal portale al repository, che conviene pianificare per gruppi di severità o per data source, non tutta insieme.

Fonte: Petri IT Knowledgebase – Microsoft Sentinel Adds Detections-As-Code, Table Insights, and New Data Connectors, con approfondimenti dalla documentazione ufficiale Microsoft Learn su Sentinel Repositories.