Migrazione di Log Analytics Agent verso Azure Monitoring Agent per continuare la log collection in Microsoft Sentinel

Microsoft nell’ultima settimana, per le organizzazioni che all’interno della propria infrastruttura stanno utilizzando Log Analytics Agent per la collezione dei log, stà mandando diverse comunicazione per procedere alla migrazione verso Azure Monitoring Agent.

Il 31/8/2024 Log Analytics Agent non sarà più supportato quindi entro questa data dovrete procedere alla migrazione verso Azure Monitoring Agent (AMA).

Eseguire questa migrazione significa continuare a ricevere i log dei vostri dispositivi verso Microsoft Sentinel utilizzando un servizio pienamente supportato e con i massimi standard di sicurezza disponibili sul mercato, all’interno di questo articolo vi mostrerò come procedere alla migrazione di una macchina Linux da Log Analytics Agent (MMA) verso Azure Monitoring Agent (AMA).

Cosa succede quindi dopo il 31/8/2024 ?

Dopo questa data se sono presenti ancora degli Agent Legacy potreste trovarvi difronte ad uno dei seguenti scenari:

  • Caricamento dei Dati: la casa di Redmond pian piano ridurrà il supporto per gli agent in modalità Legacy, questo potrebbe comportare problemi di compatibilità di questi agent, è bene specificare la l’ingestion dei log con MMA rimarrà invariata fino al 1° Febbraio 2025
  • Installazione: la possibilità di installare agent legacy verrà rimossa dal portale di Microsoft Azure, ma sarà possibile installare l’estensione di MMA o utilizzare la modalità Offiline
  • Assistenza Clienti: Non sarà possibile aprire ticket di assistenza e quindi ottenere supporto sugli agent in modatlià Legacy ed inoltre non verrà garantita la compatibilità con i nuovi sistemi operativi anche in modalità offiline o di estensione
  • MMA continuerà a funzionare, ma non sarà più in grado di connettersi ai Log Analytics Workspace
  • MMA e AMA possono coesistere, ma se “raccolgono” gli stessi dati potreste trovarvi dei duplicati

 

Quali sono i benefici di questa migrazione ?

Se utilizzerete Azure Monitoring Agent, avrete dei vantaggi immediati

Figura 1: Vanataggi di Azure Monitoring Agent

  • Risparmio sui costi utilizzando le Data Collection Rule Collect data with Azure Monitor Agent – Azure Monitor | Microsoft Learn
    • Consente la raccolta di dati in modo mirata e granulare rispetto ad un approccio “tutto o niente” di agent legacy
    • Consente di creare delle regole puntuali per la collezione dei log e di ridurre il volume complessivo dei dati che vengono immagazzinati, riducendo i costi di acquisizione e archiviazione
  • Sicurezza e Prestazioni
    • Incremento della security tramite l’utilizzo di Token di Managed Identity e Microsoft Entra
    • Velocità effettiva di raccolta degli eventi, maggiore del 25 % rispetto agli Agent Legacy
  • Gestione Semplificata
    • Supporta il caricamento di log verso più destinazioni (più log analytics Workspace), include inoltre la possibilità di eseguire log collection tra più tenant utilizzando Azure LightHouse)
    • Qualsiasi modifica della configurazione viene implementata in tutti gli Agent

 

Prerequisiti

Prima di procedere con la migrazione del servizio, dovrete eseguire alcune verifiche preliminari, vi sono quindi alcuni prerequisiti da rispettare

Scenario

Per darvi evidenza della migrazione nel mio ambiente di demo ho una macchina Linux Ubuntu 22.04 LTS in hosting presso Microsoft Azure, ed un tenant Microsoft 365 in cui vi è un Log Analytics Workspace per la collezione dei Log di questa macchina, che al momento ha un agent in versione legacy

Figura 2: Macchina Linux per Demo

Figura 3: Configurazione Agent Legacy della macchina Linux con avviso Microsoft che vi avverte di dover procedere alla migrazione verso AMA

Figura 4: Log Analytics Workspace utilizzato per la log collection con istanza di Microsoft Sentinel

Figura 5: Workspace di Microsoft Sentinel che collezione attualmente in log con Agent Legacy

Svolgimento

Ora che abbiamo visto insieme i prerequisiti e lo scenario, entriamo nella parte puramente tecnica dell’articolo. Vorrei cominciare ad indicarvi che nel mio caso, essendo una sola macchina virtuale, l’individuazione che utilizzi un Agent Legacy è immediata, ma in organizzazioni complesse è possibile sfruttare un Workbook di Sentinel per verificare quali macchine utilizzino un agent legacy, operazione che vi mostrerò, accedete quindi all’interno del Workspace di Microsoft Sentinel nella sezione Workbook

Figura 6: Creazione Workbook per vedere quali dispositivi utilizzano agent legacy

Figura 7: Modifica del Workbook

Ora dovrete recuperare il JSON ufficiale del workbook, potete farlo direttamente da Github direttamente a questo link AzureMonitorCommunity/Azure Services/Log Analytics workspaces/Workbooks/Workspace Audit.json at master · microsoft/AzureMonitorCommunity · GitHub

Figura 8: Modifica Avanzata del Workbook

Ora copiate il codice JSON recuperato da Github e salvate

Figura 9: Salvataggio del Workbook creato

Figura 10: Salvataggio Workbook creato

Figura 11: Scelta della Subscription in cui salvare il Workbook

Ora che avrete salvato il Workbook potete aprirlo per visualizzare i dati

Figura 12: Dispositivi Linux che inviano log in modalità Legacy

Figura 13: Workbook che fornisce il risultato degli Agent Legacy Installati nel mio caso uno soltanto

Ora che avrete visualizzato i dispositivi, nel mio caso linux, in cui è installato un agent legacy (linuxvm nel mio caso) dovrete procedere a migrare le configurazioni verso delle DCR (Data Collection Rule) ed anche in questo caso la casa di Redmond mette a disposizione uno strumento che ci permette di migrare, nei limiti del possibile, queste configurazioni strumento di cui potete approfondire le caratteristiche al seguente link Workspace configuration to DCR config generator – Azure Monitor | Microsoft Learn

Scaricate quindi lo script dal seguente link AzureMonitorCommunity/Azure Services/Azure Monitor/Agents/Migration Tools/DCR Config Generator at master · microsoft/AzureMonitorCommunity · GitHub

Figura 14: Download Powershell Script per la migrazione delle regole verso Data Collection Rule

Ora aprite la powershell come amministratore e posizionatevi della cartella in cui è presente lo script appena scaricato, nel mio caso C:\service, lo script dovrà essere eseguito in questo modo

.\WorkspaceConfigToDCRMigrationTool.ps1 -SubscriptionId $subId -ResourceGroupName $rgName -WorkspaceName $workspaceName -DCRName $dcrName -OutputFolder $outputFolderPath

I campi obbligatorio sono:

  • SubscriptionID in cui è presente il workspace
  • ResourceGroupName in cui è presente il worksapce
  • WorkspaceName nome appunto del workspace
  • DCRName nome che si vuole dare alle Data Collection Rule
  • OutputFolder directory in cui salvare l’Export, non obbligatorio e se non inserito utilizzerà la cartella home, nel mio caso specifico C:\service

Vi riporto, come ho modificato io lo script per passargli i parametri necessari

Figura 15: Modifica Script per “passare” i parametri necessari

Figura 16: Esecuzione comando Connect-AzAccount

Figura 17: Richiesta di Procedere con il template esportato, nel mio caso procederò in modo automatico

Figura 18: DCR creata in modo corretto dallo script

Figura 19: DCR creata dallo script vista dal portale di Microsoft Azure

Figura 20: DCR correttamente presente in AMA connector e raccoglie i log in modo corretto

Ora possiamo procedere a “Sganciare” l’agent in modalità legacy

Figura 21: Disconnessione del Legacy Agent dalla macchina Linux

Figura 22: Connettore AMA attivo e funzionante

Conclusioni

Come avete potuto notare con gli strumenti messi a disposizione dalla casa di Redmond la migrazione da un sistema Legacy ad uno strumento, in questo caso AMA (Azure Monitoring Agent), è estremamente semplice e veloce.

Con questi strumenti possiamo automatizzare tutto il flusso di migrazione e per ultimo, ma non per importanza, non abbiamo disservizio lato log collection e quindi potete eseguire l’attività anche in orario lavorativo sulle macchine di produzione.

Avete degli Agent legacy per la log collection ?

E’ arrivato il momento di passare ad AMA per avere il pieno supporto dalla casa di Redmond.