Come collegare i log di Windows Server a un SOC gestito

Invece di esportare manualmente gli eventi, puoi collegare log Windows Server a SOC gestito con una raccolta continua: abilita l’audit necessario, configura l’inoltro e verifica che ogni evento arrivi al centro operativo di sicurezza, o SOC. Questa guida distingue la raccolta Windows dall’integrazione con il servizio, perché ricevere un log non significa averlo trasformato in un allarme.

Perché serve una raccolta verificabile

Un collegamento funziona quando puoi seguire lo stesso evento dal server fino alla sua gestione nel SOC. Il solo stato del servizio di raccolta non dimostra che i dati siano arrivati, interpretati e associati alla macchina corretta.

Codycloud offre SOC gestito alle PMI che cercano monitoraggio della sicurezza affidato a un fornitore. Il collegamento dei server richiede comunque un accordo tecnico: canali da acquisire, modalità di trasporto, responsabilità operative e trattamento dei dati.

Per un progetto avviato nel 2026, separa tre verifiche: il server genera l’evento, il sistema di raccolta lo riceve, il SOC applica la regola prevista. Un problema in una verifica non si risolve modificando alla cieca le altre.

Prima di iniziare

• Accessi e ambiente: prepara un server di prova, autorizzazioni per leggere e configurare i registri, accesso alle politiche di audit e un referente del SOC. Per il percorso Windows Event Forwarding descritto qui, usa sorgenti e collettore nello stesso dominio Active Directory, con risoluzione dei nomi e autenticazione Kerberos funzionanti.
• Specifiche del collegamento: ottieni dal SOC il metodo supportato, la destinazione, i certificati eventualmente richiesti, il formato degli eventi e le condizioni contrattuali. Non scegliere un agente prima di sapere quale integrazione il servizio accetta.
• Ostacolo da prevenire: il canale Security richiede autorizzazioni specifiche per la lettura. Ricevere System e Application non dimostra di ricevere anche gli eventi di sicurezza; verifica questi permessi prima della distribuzione.

Le modifiche a servizi, firewall e politiche devono avere un’approvazione e una procedura di ripristino della configurazione. Non cancellare registri o dati per preparare il test. Usa account e attività di prova autorizzati, senza intervenire sugli account reali.

Scelta del percorso di raccolta

Windows Event Forwarding, o WEF, inoltra eventi a un collettore Windows. Un agente installato sul server segue invece il percorso previsto dal prodotto e dall’integrazione del SOC. Sono alternative da valutare, non passaggi da sommare automaticamente.

Scegli WEF se il SOC accetta eventi provenienti dal collettore; scegli l’agente se quella è l’integrazione documentata. Non installare entrambi sullo stesso insieme di eventi senza una gestione delle duplicazioni.

Il servizio SOC gestito di Codycloud è un’opzione per le PMI che affidano il monitoraggio a un fornitore. Prima dell’attivazione, richiedi conferma scritta dell’architettura accettata: questa guida non attribuisce al servizio uno specifico agente o connettore.

Configurazione dell’audit Windows

L’audit decide quali eventi Windows genera. Il trasporto raccoglie soltanto ciò che esiste: una sottoscrizione corretta non recupera eventi che la macchina non ha registrato.

1. Apri Visualizzatore eventi sul server di prova. Controlla Registri di Windows, quindi Sicurezza, Sistema e Applicazione.
2. Esamina la configurazione effettiva dell’audit con auditpol /get /category:*. Salva l’output come riferimento prima delle modifiche.
3. Concorda con il SOC le sottocategorie necessarie, distinguendo eventi riusciti e falliti. Distribuisci la politica tramite l’amministrazione del dominio, evitando configurazioni locali che una successiva applicazione delle politiche sovrascrive.
4. Genera un accesso autorizzato con un account di prova e controlla il relativo evento. Aggiungi gli altri canali soltanto quando esiste un’esigenza di rilevamento documentata.

Nel registro di sicurezza, l’ID evento 4624 identifica un accesso riuscito e l’ID 4625 un accesso non riuscito. L’ID 1102 segnala la cancellazione del registro di audit: è un evento da monitorare, non un’azione da eseguire per collaudare la raccolta.

Controlla i campi EventID, Computer, TimeCreated e i dati specifici dell’evento. Il nome dell’account, il dominio e il tipo di accesso aiutano a distinguere un’attività prevista da un evento che richiede analisi.

Risultato atteso: il server genera gli eventi concordati e puoi identificarli nel registro originale. Se mancano qui, correggi l’audit prima di configurare l’inoltro.

Configurazione del collettore WEF

Il collettore riceve gli eventi Windows. Nel percorso descritto, la sottoscrizione è avviata dalle sorgenti: i server autorizzati ricevono la configurazione tramite le politiche di dominio e contattano il collettore.

1. Predisponi una macchina Windows destinata alla raccolta e registra il suo nome DNS, il gruppo delle sorgenti autorizzate e il responsabile operativo. Verifica sincronizzazione dell’orologio e autenticazione di dominio.
2. Sul collettore di prova, esegui wecutil qc da una console amministrativa. Leggi e approva le modifiche proposte dal comando per il servizio Windows Event Collector; non eseguirlo indiscriminatamente sui server di produzione.
3. Crea una sottoscrizione avviata dalle sorgenti con un filtro approvato, un insieme esplicito di computer autorizzati e il registro di destinazione ForwardedEvents. Distribuisci ai server la configurazione del gestore delle sottoscrizioni mediante una politica dedicata.
4. Verifica il servizio Windows Remote Management, o WinRM, e le regole di rete lungo il percorso sorgente-collettore. Le porte predefinite sono 5985/TCP per HTTP e 5986/TCP per HTTPS; apri soltanto il percorso scelto e autorizzato.
5. Controlla che il contesto di raccolta possa leggere ciascun canale incluso. Per Security, usa autorizzazioni documentate e limitate: non assegnare privilegi amministrativi generali per aggirare un errore di accesso.

Queste porte riguardano il trasporto Windows, non necessariamente il collegamento esterno al SOC. Non esporre WinRM su Internet. Per HTTPS, verifica certificato, nome della destinazione e catena di attendibilità; non disabilitare i controlli per far riuscire la connessione.

Risultato atteso: un evento di prova compare in ForwardedEvents con il campo Computer riferito alla sorgente, non al collettore.

Collegamento del collettore al SOC

La consegna al SOC è un passaggio distinto da WEF. Serve il connettore o l’agente approvato dal fornitore; un file esportato manualmente non costituisce una raccolta continua.

1. Configura il componente supportato per acquisire ForwardedEvents. Se il SOC richiede un agente direttamente sui server, segui quel percorso e non aggiungere un collettore non previsto.
2. Imposta destinazione, credenziali o certificati secondo la documentazione dell’integrazione. Conserva i segreti in un sistema autorizzato, non in script condivisi o documenti operativi leggibili da tutti.
3. Verifica che l’integrazione mantenga l’identità della sorgente, il canale e l’ID evento. Separa il timestamp di origine dall’orario di ricezione.
4. Concorda il comportamento durante un’interruzione: accodamento, tentativi di riconsegna, limiti e segnalazione dell’assenza di dati. Registra ciò che il componente supporta, senza presumere che conservi tutto.
5. Cerca nel SOC l’evento già identificato sul server. Confronta macchina, account, orario e campi rilevanti con il registro originale.

Il nome del collettore non deve sostituire quello del server che ha generato l’evento. Altrimenti, le regole raggruppano attività di macchine diverse e il contesto dell’indagine diventa inaffidabile.

Risultato atteso: il SOC riceve un evento riconoscibile, conserva i campi necessari e lo associa alla sorgente corretta.

Collaudo della catena e degli allarmi

Nel collaudo del 2026, usa una scheda di evidenza per ogni prova: azione autorizzata, sorgente, evento osservato e risultato. Distingui il tempo di consegna dal tempo di presa in carico previsto dal contratto.

1. Generazione: esegui un’attività concordata sul server di prova e annota l’orario. Non simulare attacchi su sistemi reali senza un’autorizzazione specifica.
2. Raccolta: trova lo stesso evento nel collettore e confronta i campi di origine. Registra gli orari osservati, senza trasformarli in una garanzia generale di latenza.
3. Rilevamento: chiedi al SOC di verificare una regola concordata, con soglia e contesto espliciti. Un accesso fallito isolato non deve necessariamente generare un incidente.
4. Presa in carico: verifica destinatario, canale di notifica, responsabilità e registrazione dell’esito. Un allarme senza un referente raggiungibile non chiude il processo.

Il percorso deve essere verificabile anche quando non produce un incidente: una prova può dimostrare la corretta ricezione senza superare la soglia della regola.

Controlla i log dei componenti prima e dopo la modifica. Chiudi il collaudo soltanto quando hai verificato anche l’assenza di errori nuovi e rimosso gli account e i dati creati esclusivamente per il test, senza cancellare le evidenze necessarie.

Risultato atteso: ogni passaggio ha un’evidenza e un responsabile; le condizioni di accettazione concordate risultano soddisfatte.

Variante: raccolta con agente sui server

Usa questa variante quando il SOC documenta un agente compatibile o quando l’architettura non prevede WEF. Il principio resta identico: prima l’audit, poi la consegna, infine il rilevamento.

• Distribuisci il pacchetto approvato su una macchina di prova e verifica versione, origine e requisiti.
• Configura i canali richiesti, controllando i permessi per Security.
• Verifica la destinazione e l’autenticazione secondo la documentazione del componente.
• Ripeti il confronto fra evento originale, evento ricevuto e risultato della regola.

Per nuovi server aggiunti nel 2026, inserisci registrazione e collaudo nella procedura di attivazione. Quando cambia una politica di audit o un filtro, ripeti le prove interessate: aggiornare la configurazione non dimostra che la raccolta continui a funzionare.

Problemi frequenti e correzioni

• Arrivano Sistema e Applicazione, ma non Sicurezza. Verifica filtro, audit effettivo e permessi del contesto di raccolta sul canale Security. Non ampliare tutti i privilegi come prima soluzione.
• La sorgente non compare nella sottoscrizione. Controlla applicazione della politica, gruppo autorizzato, DNS, autenticazione e raggiungibilità del collettore. Usa wecutil es per elencare le sottoscrizioni e wecutil gr con il nome della sottoscrizione per consultarne lo stato.
• Gli eventi raggiungono il collettore, ma non il SOC. Controlla il componente di consegna, l’autenticazione e gli errori di acquisizione. Verifica che legga ForwardedEvents, non soltanto i registri locali del collettore.
• Lo stesso evento compare due volte. Cerca percorsi sovrapposti, come agente e WEF sul medesimo canale. Definisci una sola raccolta oppure una deduplicazione documentata, senza scartare eventi diversi perché condividono l’ID.
• Gli orari non coincidono. Confronta timestamp di origine, ricezione e visualizzazione. Controlla sincronizzazione e fuso orario prima di attribuire lo scarto alla rete.

Estensione del monitoraggio

Dopo Windows Server, aggiungi sorgenti soltanto quando migliorano un caso d’uso definito: identità, accessi remoti o modifiche amministrative. Ogni nuova sorgente richiede filtro, responsabilità e prova di consegna.

Per il piano di monitoraggio del 2026, concorda con Codycloud quali attività rientrano nel SOC gestito e quali restano al tuo reparto IT. Metti per iscritto conservazione, accessi ai log, escalation e accordi sui livelli di servizio, o SLA. Non confondere gli SLA di presa in carico con la latenza della raccolta.

I log contengono anche dati riferibili a persone. Limita accessi e acquisizione alle finalità definite; per qualificazioni giuridiche e requisiti normativi, consulta i testi ufficiali e il referente legale. La raccolta dei log, da sola, non dimostra conformità.

FAQ

Ultima verifica: il silenzio della sorgente

Nel 2026, collauda anche l’assenza di eventi, non soltanto la loro ricezione. In un ambiente di prova, interrompi il percorso concordato e verifica come viene segnalata la perdita della sorgente. Documenta poi il ripristino e il comportamento degli eventi accodati: un sistema silenzioso non è automaticamente un sistema sicuro.

Guide correlate

• Collegare Microsoft 365 a un SOC gestito
• Strumenti SIEM per le PMI
• Piattaforme IAM per le PMI