Nell’ambito dello sviluppo di applicativi custom, soprattutto se questi vanno ad interagire con dati e / o API esterne, è sicuramente utile generare dei log che in un secondo momento possano aiutarci a risolvere eventuali problemi. Non solo i log potranno riverlarsi utili in chiave tecnica, ma anche per la creazione di uno storico degli accessi a dati sensibili. In questo articolo vedremo come creare delle tabelle custom all’interno di Log Analytics Workspace e / o Microsoft Sentinel per poi popolarle con dati provenienti dai nostri applicativi.
Log Analytics Workspace e Sentinel
Lo strumento che Microsoft mette a disposizione per l’archiviazione e la visualizzazione dei log è il Log Analytics Workspace. A primo impatto può sembrare simile a un database relazionale poiché organizza i dati in tabelle con una struttura definita, ma in realtà utilizza un modello di archiviazione ottimizzato per l’analisi di grandi volumi di log e sfrutta il linguaggio KQL per l’estrazione e la visualizzazione avanzata dei dati.
Sentinel, invece, è il “SIEM” di Microsoft, che si avvale di un Log Analytics Workspace per salvare i log che ottiene dai diversi connettori (interfacciati a loro volta ai vari servizi compatibili, che fanno da sorgenti dati), e ci consente di centralizzare le analisi delle informazioni raccolte per correlare gli eventi, allertare gli amministratori di attività sospette ed anche di definire alcune procedure da avviare automaticamente al verificarsi di determinate condizioni.
Quali dati è possibile salvare?
I Log Analytics Workspace vengono utilizzati da molte risorse Azure per archiviare i log generati. Ad esempio, nel caso delle Function Apps, è possibile attivare Application Insights per raccogliere e analizzare automaticamente i log delle “Invocation”, degli errori e delle performance. Se configurato, Application Insights può inviare questi dati a un Log Analytics Workspace per una consultazione più approfondita. Successivamente, le chiamate delle Function Apps possono essere visualizzate nella sezione ‘Invocations’ all’interno di Application Insights. Questo è solo un esempio: l’utilizzo dei Log Analytics Workspace è molto esteso e perfettamente integrato con le risorse Azure.
In Microsoft Sentinel la raccolta dei log avviene tramite appositi connettori, sviluppati sia da Microsoft che da software house di terze parti. Questi connettori prelevano i dati dai componenti software e hardware che contribuiscono alla cybersecurity aziendale (come firewall, antivirus, servizi cloud e dispositivi di rete) e li archiviano nel Log Analytics Workspace associato a Sentinel. Una volta raccolti, i log possono essere analizzati per individuare minacce, correlare eventi e attivare risposte automatiche.
Tabelle personalizzate
Non sempre è disponibile un connettore per l’applicativo o servizio da noi utilizzato, tuttavia all’interno dei Log Analytics Workspace è possibile creare delle tabelle personalizzate che ci consentiranno di archiviare i log all’interno della struttura che incontra al meglio le esigenze dell’applicativo / servizio in questione.
Come vengono ricevuti i dati?
La trasmissione avviene tramite delle richieste POST del protocollo HTTPS ed i dati dovranno essere formattati in JSON.
L’architettura di ricezione è composta da 3 parti:
- Il Data Collection Endpoint (DCE): è la destinazione verso cui dovremo mandare le richieste HTTPS, e che si occuperà di processarle;
- La Data Collection Rule (DCR): conterrà uno o più flussi di dati, per ciascuno dovremo predisporre un identificativo, una regola di trasformazione (data transformation rule) e la relativa tabella di destinazione;
- La tabella di destinazione: verrà creata all’interno del Log Analyics Workspace ed archivierà i dati raccolti.
Nota: tutti i componenti dovranno trovarsi all’interno della stessa region Azure.
Data Collection Endpoint (DCE)
La creazione di questa risorsa è molto semplice, basterà attribuirle il nome, sottoscrizione, resource group e region di residenza:
La pagina principale della nuova risorsa mostrerà due link, per la trasmissione dei log utilizzermo quello contrassegnato come “Log Ingestion”:
Il Data Collection Endpoint è configurabile sia per ricevere i log da qualsiasi sorgente su Internet, che per limitare questa possibilità ai soli client con accesso ad un Private Link, rendendolo così più sicuro.
Tabella e Data Collection Rule
Queste due componenti si creano contestualmente l’una all’altra, per fare ciò dovremo recarci direttamente sul Log Analytics a cui vogliamo aggiungere la tabella e cliccare sull’apposito bottone, dal menù a tendina bisognerà sceglere la nuova tabella basata su DCR:
Come prima cosa ci verranno richiesti nome (da notare Azure apporrà automaticame il suffisso “_CL”) e descrizione della nuova tabella:
Dal form procediamo anche con la creazione della nuova data collection rule inserendo i dati richiesti:
Fatto ciò sarà possibile terminare la creazione della tabella con la DCR e il DCE:
Per il passo successivo occorrerà avere un file JSON contenente uno o più oggetti strutturati in modo uguale a quelli che verranno inviati all’endpoint, esso dovrà essere caricato con l’apposito bottone ed il risultato sarà il seguente:
Come da avviso evidenziato in rosso, è obbligatorio che la tabella contenga una colonna denominata “TimeGenerated”. Tale campo di ogni riga dovrà essere valorizzato con il timestamp a cui è stato generato il relativo log. Se, come in questo caso, non è presente la colonna “TimeGenerated” sarà necessario aggiungerla, nell’esempio il timestamp di generazione del log è inserito nel campo “orario”, per rinominarlo dovremo utilizzare una regola KQL di trasformazione, applicabile con il bottone “Transformation Editor”:
In questo caso la regola utilizza la direttiva KQL “extend” per aggiungere la colonna “TimeGenerated” e la valorizza con la data (convertita in formato datetime dalla stringa formattata in ISO 8601 contenuta nel campo “orario”). Successivamente elimina la colonna “orario” con “project-away”.
Terminiamo così la creazione degli elementi necessari.
Configurare l’Access Control per autorizzare l’invio dei logs
Una volta creati gli elementi necessari per l’archiviazione dei log, dovremo concedere i permessi alle identità dei software che li genereranno e li invieranno.
Per fare ciò ci sono due modi:
- Managed Identity: nel caso in cui la sorgente sia una risorsa Azure che supporta le Managed Identity (Automation Account, Web App, Function App, etc…) sarà sufficiente assegnare a quest’ultima il ruolo di “Monitoring Metrics Publisher” nella sezione “Access Control (IAM)” della Data Collection Rule creata al paragrafo precedente.
- App registration / service principal: in caso contrario, se la sorgente dei log si trovasse all’esterno di Azure, dovremo procedere con la registrazione di una nuova app (se non già esistente). Ad ogni app registration viene automaticamente collegato un service principal (elencato nella sezione “Enterprise Application” di Azure), a cui dovremo assegnare il ruolo di “Monitoring Metrics Publisher” nella sezione “Access Control (IAM)” della Data Collection Rule creata al paragrafo precedente.
Come inviare i log dall’applicazione sorgente
Come anticipato, i log dovranno essere inviati in formato JSON, incorporati all’interno di una richiesta HTTPS POST.
Per la corretta identificazione del flusso dati destinatario avremo bisogno di 3 elementi:
- L’indirizzo del Data Collection Endpoint per il Log Ingestion, (visto nel paragrafo dedicato di questo articolo);
- L’ID Immutabile della data collection rule, ottenibile nella sua pagina principale:
Figura 11 – Immutable ID della data collection rule - Il nome della sorgente dati assegnato dalla DCR, reperibile nella pagina “Data sources”:
Figura 12 – Come ottenere il nome della data source
La richiesta HTTPS dovrà essere autenticata, questo per consentire ad Azure, alla ricezione dei log, di poter verificare che essi provengano dalle sorgenti autorizzate.
Il processo di autenticazione e invio dipende dal linguaggio di programmazione utilizzato dalla sorgente dei log. Bisogna notare che per i più famosi Microsoft ha rilasciato delle librerie che rendono molto più veloce l’implementazione sia del processo di autenticazione (con Managed Identity oppure Service Principal) che l’invio dei log.
Se invece dovessimo avvalerci dell’invio tramite richiesta HTTPS dovremo provvedere manualmente anche all’ottenimento del bearer token. Il processo step-by-step è descritto bene dalla stessa Microsoft nell’esempio di codice ufficiale scritto in PowerShell, da cui è possibile capire tutti i passaggi ed i dati necessari. Saranno disponibili link per l’approfondimento nei riferimenti di questo articolo.
Conclusioni
Le potenzialità di Log Analytics Workspace, ed ancora di più, Microsoft Sentinel sono molto alte.
Avere la possibilità di includere anche i log (tecnici, o di auditing) all’interno di questi strumenti amplia ulteriormente la capacità di storicizzare e correlare i dati, cosa fondamentale per un SIEM aziendale.
Riferimenti esterni
Introduzione ai Log Analytics Workspace
Introduzione a Microsoft Sentinel
Documentazione ufficiale riguardante l’invio dei log
Approfondimento sulle Managed Identities (per semplificare l’invio dei log nei casi in cui la sorgente risieda in una risorsa Azure che le supporta)
Documentazione ufficiale riguardante i Data Collection Endpoint
Documentazione ufficiale riguardante le Data Collection Rules
Esempi ufficiali di codice per l’invio dei log. L’esempio in PowerShell, non dispondendo di una libreria dedicata allo scopo, consente di capire come interfacciare l’app custom esclusivamente in HTTP. Gli altri esempi, presentati in diversi linguaggi di programmazione, invece, consentono di capire l’utilizzo delle librerie.