Numero speciale Windows Server 2008

Controllo e conformità in Windows Server 2008

Rob Campbell e Joel Yoker

Panoramica:

• Aumento dell'importanza della conformità
• Comprensione delle modifiche nell'ambiente in uso
• Problemi correlati al controllo degli eventi di protezione
• Aspetti tecnici del controllo

Nel mondo della tecnologia IT il cambiamento è costante. La maggior parte delle organizzazioni IT si trova oggi sotto la crescente pressione di comprendere i cambiamenti che si verificano nel proprio ambiente. Maggiore è la complessità e la scalabilità degli ambienti IT, più significativo sarà l'impatto di

eventuali errori amministrativi e divulgazioni accidentali dei dati. La società odierna richiede un'assunzione di responsabilità e rendiconto nei confronti di eventi di questo tipo e, pertanto, le organizzazioni sono ora ritenute legalmente responsabili della salvaguardia delle informazioni che gestiscono.

Di conseguenza, il controllo delle modifiche nell'ambiente aziendale ha acquisito un'importanza fondamentale. Perché? Il controllo consente di comprendere e gestire le modifiche negli attuali ambienti IT di grandi dimensioni e a distribuzione elevata. In questo articolo verranno illustrati le problematiche più comuni a cui la maggior parte delle organizzazioni deve far fronte, gli scenari della conformità e delle normative nel settore IT e alcuni dei concetti alla base del meccanismo di controllo di Windows®. Verrà inoltre descritto come le funzionalità di Windows Server® 2008 e il servizio Audit Collection Services (ACS) di Microsoft® System Center Operations Manager 2007 siano in grado di integrare una strategia di controllo completa.

Controllo delle problematiche

Basta dare una rapida occhiata ai titoli dei giornali per rendersi conto che la divulgazione dei dati sta diventano un problema quotidiano. Molti di questi eventi implicano per le organizzazioni responsabili problemi correlati ad azioni legali, perdite finanziarie e relazioni pubbliche. La capacità di spiegare che tipo di modifiche sono state eseguite e di identificare rapidamente i problemi è essenziale per ridurre l'impatto degli episodi di divulgazione accidentale dei dati.

Si supponga, ad esempio, che la propria organizzazione sia responsabile della gestione di informazioni che consentono l'identificazione personale per una determinata base di clienti. Nonostante l'ampia gamma di metodi disponibili per proteggere le informazioni contenute nei sistemi gestiti dalla propria organizzazione, esiste comunque il rischio che i dati vengano compromessi. Un controllo appropriato potrebbe consentire all'organizzazione di determinare con esattezza quali sistemi sono stati compromessi e, probabilmente, quali dati sono andati persi. Senza un sistema di controllo, l'impatto della perdita dei dati potrebbe essere molto più significativo, in particolare perché non si potrebbe in alcun modo stimare l'entità della compromissione.

Perché, dunque, le organizzazioni IT non hanno ancora implementato un sistema di controllo? Il fatto è che la maggior parte delle organizzazioni non è in grado di comprendere appieno gli aspetti tecnici del controllo. Sebbene i responsabili senior siano in grado di comprendere concetti come backup e ripristino, la complessità inerente del controllo delle modifiche nell'ambiente è un concetto piuttosto difficile da convogliare. Di conseguenza, le domande relative al controllo vengono in genere poste solo dopo l'insorgenza di un evento significativo. È possibile, ad esempio, attivare il controllo di base, ma se il sistema non viene configurato per il controllo di una specifica modifica, a causa della mancanza di pianificazione, tali informazioni non verranno raccolte.

Inoltre, gli eventi di protezione controllati presentano alcuni problemi intrinseci che devono essere gestiti dai professionisti IT. Una di queste difficoltà è rappresentata dalla distribuzione di sistemi all'interno dei moderni ambienti informatici di grandi dimensioni, che pone significativi problemi in termini di raccolta e aggregazione, in quanto una modifica può verificarsi in qualsiasi sistema o insieme di sistemi in qualsiasi momento. Una situazione di questo tipo può condurre a un altro problema: la correlazione. La conversione delle relazioni tra gli eventi che si verificano su un singolo sistema o su più sistemi si rende spesso necessaria per fornire un vero significato a ciò che sta accadendo.

Un altro problema è rappresentato dal fatto che il controllo in genere supera i tradizionali confini delle organizzazioni. Strutture di organizzazioni o di team differenti esistono per ragioni differenti e non è sempre semplice stabilire un collegamento tra loro. Molte organizzazioni dispongono di un team per i servizi directory, un team per l'infrastruttura di messaggistica e un team per le applicazioni desktop, ma probabilmente prevedono un unico team di protezione responsabile per tutte queste aree. Inoltre, il personale responsabile della protezione potrebbe non essere fisicamente presente in tutte le sedi di un'organizzazione. Ad esempio, le succursali fanno in genere affidamento su un singolo individuo o un piccolo team per tutte le attività, tra cui la gestione dei registri eventi di protezione.

Infine, l'enorme quantità di eventi rappresenta una vera sfida. Gli eventi di protezione controllati si verificano in volumi molto più elevati rispetto ad altri tipi di registrazione di eventi. Il numero di eventi raccolti rende difficile mantenere ed esaminare in modo efficace i registri. Inoltre, stipulando i requisiti di conservazione per queste informazioni, le normative correnti e proposte non contribuiscono a ridurre questo onere nelle infrastrutture informatiche attuali.

In passato, il controllo dell'accesso alle informazioni poteva essere considerato come un desiderio di "sapere" e un tentativo di garantire la protezione. Ora, poiché le organizzazioni e i dirigenti senior vengono ritenuti legalmente responsabili della perdita di informazioni o della mancanza di misure di protezione appropriate, è fondamentale per gli amministratori IT acquisire dimestichezza con le normative che potrebbero essere applicabili ai relativi ambienti. Per le aziende globali, le sfide sono ancora più complesse, in quanto ogni paese prevede normative specifiche riguardanti le informazioni e la relativa protezione. Alcuni esempi di leggi sulla conformità normativa esistenti sono elencati nella Figura 1, insieme alle aspettative nei confronti delle organizzazioni IT.

Figure 1 Normative e relative implicazioni per i professionisti IT

Considerata tutta la pressione legale, che tipo di azione è necessario che i professionisti IT intraprendano? I responsabili e i tecnici IT devono creare un progetto chiaro e conciso da presentare ai collaboratori interni ed esterni all'organizzazione. Questo include lo sviluppo di una strategia di controllo appropriata che richiede misure e investimenti proattivi. Il concetto principale è che il sistema di controllo non può essere progettato solo dopo il verificarsi di un problema, come spesso accade.

Questi tipi di sfide IT possono essere in genere risolte grazie a una combinazione di persone, processi e tecnologie. Nell'ambito del controllo, il processo rappresenta l'area di maggiore interesse. Pertanto, il primo passo deve prevedere la conoscenza dei concetti di base in modo da poter rispondere alle esigenze e ai requisiti di conformità normativa della propria organizzazione. In questo articolo verranno illustrati i concetti alla base del meccanismo di controllo in Windows, quindi verranno esaminate le modifiche introdotte in Windows Server 2008 e Windows Vista®.

Controllo degli eventi di protezione

Tutti gli eventi controllati vengono registrati nel registro eventi di protezione di Windows. Questi eventi, in genere, non sono immediatamente utilizzabili e spesso sono di natura informativa. Ogni evento registra un semplice risultato di tipo "controllo riuscito" o "controllo non riuscito" per un tipo specifico di accesso. Questo registro è diverso dai registri eventi dell'applicazione e del sistema, in cui i problemi possono essere identificati tramite la codifica con colori (suggerimento: cercare gli eventi rossi per identificare immediatamente il problema).

Il registro eventi di protezione è differente in quanto gli eventi controllati vengono in genere nascosti in base al relativo volume e, come notato in precedenza, la correlazione dei dati di protezione può rivelarsi una sfida significativa. Anche una semplice violazione dei dati su un singolo sistema può causare problemi. È necessario analizzare il registro eventi di protezione per identificare l'account che è stato utilizzato per accedere ai dati, il che richiede che un amministratore esamini l'intero registro per tentare di individuare l'account. Sfortunatamente, i sofisticati attacchi attuali sono in genere coordinati e distribuiti, rendendo piuttosto difficoltoso questo tipo di analisi per la vittima.

Detto questo, è importante acquisire familiarità con gli elementi chiave che consentono di registrare le informazioni nel registro eventi di protezione di Windows: i criteri di controllo e gli elenchi di controllo di accesso di sistema (SACL, System Access Control List). I criteri di controllo sono impostazioni configurabili per un computer locale tramite Criteri di gruppo o Criteri di protezione locali e definiscono l'insieme di eventi riusciti e non riusciti per specifici tipi di accesso. Le seguenti categorie principali dei criteri di controllo sono presenti in Windows da molti anni (ulteriori informazioni sulla nuova funzionalità criteri di controllo granulari (GAP, Granular Audit Policy) di Windows Server 2008 verranno fornite più avanti):

• Controlla eventi accesso account
• Controlla gestione degli account
• Controlla accesso al servizio directory
• Controlla eventi di accesso
• Controlla accesso agli oggetti
• Controlla modifica ai criteri
• Controlla uso dei privilegi
• Controlla traccia processo
• Controlla eventi di sistema

La necessità di definire i criteri di controllo e le categorie associate è in genere compresa dalla maggior parte delle organizzazioni IT, ma i criteri di controllo rappresentano solo una parte della soluzione. Anche gli elenchi di controllo di accesso di sistema giocano un ruolo significativo nell'implementazione di un piano di controllo olistico. Due specifiche categorie dei criteri di controllo, Controlla accesso al servizio directory e Controlla accesso agli oggetti, sono completamente dipendenti dagli elenchi di controllo di accesso di sistema per la restituzione delle informazioni nel registro eventi di protezione. Cosa sono esattamente gli elenchi di controllo di accesso di sistema?

Ogni oggetto, file, Registro di sistema o servizio directory, dispone di un elenco di controllo di accesso (ACL) con una o più voci di controllo di accesso (ACE) suddivise in due tipi: un elenco di controllo di accesso discrezionale (DACL) e un SACL (quest'ultimo definisce le impostazioni che consentono di registrare i tentativi di accesso agli oggetti protetti). Ogni voce di controllo di accesso in un SACL specifica i tipi di tentativi di accesso da parte di un trustee specificato che devono essere registrati nel registro eventi di protezione. Le voci di controllo di accesso definiscono la registrazione dei tentativi di accesso riusciti e/o non riusciti agli oggetti specificati. Nella Figura 2 viene illustrato l'utilizzo di un SACL in un oggetto per generare gli eventi per specifici tipi di accesso.

Figura 2** Utilizzo di un SACL in un oggetto **(Fare clic sull'immagine per ingrandirla)

La comprensione della relazione tra i criteri di controllo e gli elenchi di controllo di accesso di sistema è fondamentale dal momento che la configurazione è necessaria per acquisire gli eventi controllati "corretti" in quanto correlati alle modifiche nell'ambiente. Come menzionato in precedenza, i criteri di controllo Controlla accesso al servizio directory e Controlla accesso agli oggetti consentono la generazione di controlli nel registro eventi di protezione solo per queste specifiche categorie, ma gli eventi vengono generati solo se un oggetto prevede una voce ACE di controllo configurata nel relativo SACL. Gli eventi di protezione vengono generati dall'autorità di protezione locale (LSA) di Windows e scritti nel registro eventi di protezione.

Gli eventi sono composti da due aree distinte: l'intestazione, che è statica ed è predefinita per ciascun identificatore di evento (ID evento), e il corpo, che è dinamico e contiene dettagli differenti per i diversi eventi. Nella Figura 3 questi due elementi vengono riportati in un evento di protezione di Windows Server 2008 di esempio. La comprensione di questi componenti degli eventi è importante per la fase di analisi di qualsiasi progetto di controllo ed è di particolare interesse rispetto alla modalità di restituzione delle informazioni in strumenti come ACS.

Figura 3** Intestazione e corpo di un evento controllato **(Fare clic sull'immagine per ingrandirla)

Windows Eventing 6.0

Una volta compreso il problema, in che modo Windows Server 2008 aiuta le organizzazioni ad affrontare queste sfide? Windows Server 2008 è la prima versione server a contenere il nuovo sottosistema di eventi Windows Eventing 6.0, che migliora significativamente lo scenario correlato alla gestione degli eventi di protezione. Notare che, sebbene in questo articolo l'attenzione venga focalizzata su Windows Server 2008, il 95% del nuovo set di funzionalità esiste anche in Windows Vista.

Il primo componente di Windows Eventing 6.0 che molti utenti noteranno è la nuova interfaccia utente. Il nuovo snap-in di Microsoft Management Console (MMC), Visualizzatore eventi, offre una straordinaria pagina Panoramica e riepilogo, visualizzazioni personalizzate flessibili e testo esplicativo notevolmente migliorato. Queste interfacce consentono all'utente finale o all'amministratore di sistema di individuare le informazioni sugli eventi e di configurare importanti opzioni per i registri eventi direttamente dal Visualizzatore eventi.

Un problema chiave che ha di frequente avuto un notevole impatto sui dati di protezione all'interno del registro eventi era rappresentato dal mantenimento dei dati. In precedenza, il sottosistema Registro eventi (che includeva tutti i registri) presentava limiti di scalabilità. Se questi limiti fossero stati superati, l'intero sottosistema avrebbe interrotto la registrazione degli eventi. Questo, tuttavia, non avviene in Windows Eventing 6.0, e le organizzazioni sono ora limitate solo dalla quantità di spazio disponibile su disco. Tuttavia, tenere presente che registri eventi di dimensioni eccessive possono essere difficili da analizzare, in quanto ogni singola voce del registro deve essere valutata durante l'applicazione di filtri; pertanto, è consigliabile mantenere il registro a dimensioni gestibili.

Naturalmente, è compito dell'amministratore IT sviluppare un piano di archiviazione per i registri eventi su più sistemi. Una funzionalità, ora esposta in Windows Eventing 6.0, fornisce assistenza nello svolgimento di questa attività a livello di server locale, ovvero l'opzione "Archivia il registro quando è pieno (non sovrascrivere gli eventi). Nelle versioni precedenti di Windows, questa opzione poteva essere impostata solo direttamente tramite la modifica del valore del Registro di sistema AutoBackupLogFiles. Sebbene questa opzione fornisca un meccanismo per l'archiviazione locale dei registri, non fornisce una soluzione per la gestione di questi file nel tempo, né affronta il problema di aggregazione che si verifica su più sistemi. Audit Collection Services fornisce da questo punto di vista una soluzione completa, che verrà analizzata tra breve.

La nuova interfaccia è solo l'inizio. La vera potenza di Windows Eventing 6.0 è rappresentata dal nuovo servizio Registro eventi di Windows e dal motore basato su XML sottostante. Questi componenti garantiscono opzioni di scalabilità, accesso facilitato e gestione migliorate. Gli eventi vengono ora memorizzati in un formato XML flessibile che rende possibili soluzioni personalizzate in grado di interagire con queste informazioni in modo nativo.

Windows Eventing 6.0 fornisce inoltre la capacità di associare azioni amministrative a specifici eventi. Questo risultato viene ottenuto integrando il servizio Raccolta eventi Windows con il servizio Utilità di pianificazione in modo da garantire eventi basati su attività. Si tratta di un nuovo paradigma per il servizio Utilità di pianificazione, che in precedenza era limitato all'attivazione di eventi in base al tempo. La procedura guidata "Associa attività all'evento" (disponibile nel menu di scelta rapida di qualsiasi evento nel Visualizzatore eventi di Windows Server 2008) fornisce un metodo semplice per avviare un programma, inviare un messaggio di posta elettronica o visualizzare un messaggio ogni volta che viene registrato uno specifico evento. Questa procedura può rivelarsi molto utile quando si tenta di identificare le azioni specifiche eseguite nell'ambiente in uso che possono essere isolate in uno specifico evento di protezione. Se, ad esempio, si stanno controllando le modifiche apportate alla chiave del Registro di sistema per l'autorizzazione dell'aggiornamento dello schema nei controller di dominio, è possibile creare un'attività che consente di inviare un messaggio di posta elettronica a specifici amministratori della protezione per informarli quando questa chiave del Registro di sistema viene modificata.

Oltre alla nuova capacità di raccogliere e archiviare un numero elevato di voci di eventi, è inoltre possibile eseguire un controllo più efficace degli eventi che vengono registrati nel registro eventi. Questa operazione viene resa possibile grazie a una nuova funzionalità, criteri di controllo granulari (GAP). Nelle versioni precedenti di Windows, le nove categorie di controllo disponibili causavano in genere un sovraccarico di eventi. Queste categorie di alto livello possono essere ora controllate da 50 sottocategorie granulari,, ciascuna delle quali rappresenta un sottoinsieme correlato di eventi.

Questo consente di filtrare le informazioni non critiche dal registro eventi senza perdere visibilità a livello di categoria. Ad esempio, se su uno specifico sistema si desidera monitorare solo le modifiche apportate al Registro di sistema, ma non il file system, in precedenza era possibile scegliere solo di riportare gli eventi riusciti o non riusciti nella categoria Accesso agli oggetti. Con GAP, ora è possibile filtrare le sottocategorie, come File system, Servizi di Certificazione e Condivisione file, e riportare solo gli eventi nella sottocategoria Registro di sistema. Per esplorare le sottocategorie di GAP su un sistema Windows Server 2008, è necessario eseguire il comando Auditpol da un prompt dei comandi con privilegi elevati. Per elencare le sottocategorie di GAP disponibili, digitare quanto segue:

auditpol /list /subcategory:*

Per ottenere un elenco di sottocategorie di GAP configurate sul sistema in uso, digitare quanto segue:

auditpol /get /category:*

Tenere presente che la funzionalità GAP non è configurabile tramite l'interfaccia utente di Criteri di gruppo standard e deve essere gestita mediante auditpol.exe. L'articolo della Knowledge Base all'indirizzo support.microsoft.com/kb/921469 contiene indicazioni su come distribuire le impostazioni di GAP tramite Criteri di gruppo per i sistemi Windows Server 2008 e Windows Vista.

Windows Server 2008 è in grado inoltre di acquisire i valori nuovi e precedenti dei tipi specifici presenti nel registro eventi di protezione. Nelle versioni precedenti di Windows, il sottosistema di controllo registrava solo il nome del valore modificato del Registro di sistema o dell'attributo dell'oggetto Active Directory®, ma non registrava i valori precedenti e correnti dell'attributo. Questa nuova funzionalità si applica a Servizi di dominio Active Directory, ad Active Directory Lightweight Directory Services e al Registro di sistema di Windows. Attivando Controllo operazioni riuscite o Controllo operazioni non riuscite nelle sottocategorie "Registro di sistema" o "Modifiche servizio directory" e impostando gli elenchi di controllo di accesso di sistema associati, nel registro eventi verranno generati eventi dettagliati relativi alle azioni su questi oggetti. Questa operazione può essere eseguita utilizzando i seguenti comandi auditpol:

auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service     
    Changes" /success:enable

Le modifiche al Registro di sistema vengono visualizzate come eventi ID evento 4657, come illustrato nella Figura 4.

Figura 4** Prima e dopo una modifica del Registro di sistema **(Fare clic sull'immagine per ingrandirla)

Questa funzionalità è particolarmente utile quando si tenta di tenere traccia delle modifiche negli oggetti Active Directory. Per la sottocategoria Modifiche servizio directory, queste modifiche vengono visualizzate in un paio di eventi ID evento 5136, come illustrato nella Figura 5. Ogni evento include nel relativo corpo un'operazione, un attributo e un oggetto servizio directory. Per le modifiche agli attributi con i dati esistenti, vengono visualizzate due operazioni: Valore eliminato e Valore aggiunto. Per gli attributi che non sono stati compilati, viene visualizzata solo l'operazione Valore aggiunto quando vengono scritti dati in tali attributi. Ad esempio, quando un'operazione di modifica riuscita viene eseguita su un attributo di un oggetto utente, come telephoneNumber, Active Directory registra i valori precedenti e correnti dell'attributo in voci del registro eventi dettagliate.

Figura 5** Prima e dopo un evento Modifiche servizio directory **(Fare clic sull'immagine per ingrandirla)

Se viene creato un nuovo oggetto, verranno registrati i valori degli attributi che vengono compilati al momento della creazione dell'oggetto. Se un oggetto viene spostato all'interno di un dominio, verranno registrate la nuova posizione e la posizione precedente (sotto forma di nome distinto). Questa funzionalità dei valori nuovi e vecchi viene attivata per impostazione predefinita quando vengono applicate le impostazioni dei criteri di controllo appropriate. Se è presente un attributo che si desidera mantenere privato, come le modifiche al codice dipendente, è possibile escludere specificamente gli attributi eseguendo una semplice modifica dello schema. Modificando la proprietà searchFlags dell'attributo nello schema in 0x100 (valore 256 -NEVER_AUDIT_VALUE), come illustrato nella Figura 6, l'evento Modifiche servizio directory non viene generato quando vengono apportate modifiche all'attributo.

Figura 6** Esclusione di un attributo da Modifiche servizio directory **(Fare clic sull'immagine per ingrandirla)

Infine, una delle più interessanti funzionalità di Windows Eventing 6.0 è rappresentata dalle sottoscrizioni di eventi. Come affermato in precedenza, l'accesso e l'analisi del registro eventi è un'attività di amministrazione del sistema fondamentale. La nuova funzionalità di sottoscrizione di eventi consente di inoltrare direttamente gli eventi tra i sistemi. Le sottoscrizioni di eventi sono costituite da un servizio Raccolta eventi, che raccoglie gli eventi, e da origini di eventi, che vengono configurate per l'inoltro di eventi agli host specificati. La possibilità di utilizzare gli eventi viene fornita dal servizio Raccolta eventi Windows (una novità di Windows Eventing 6.0), mentre la funzionalità di sottoscrizione è incorporata nel servizio Registro eventi di Windows. È possibile configurare un agente di raccolta per la raccolta di eventi da più origini eventi, che possono essere rappresentate da un sistema Windows Server 2008 o Windows Vista.

Tutti i dati raccolti dalle origini eventi risiedono in un registro eventi discreto, denominato Eventi inoltrati (ForwardedEvents.evtx), e vengono gestiti dal servizio Registro eventi nell'agente di raccolta. La configurazione su entrambi gli endpoint (agente di raccolta e origine) è necessaria e può essere automatizzata (winrm quickconfig –q nell'origine; wecutil qc /q nell'agente di raccolta). È importante notare che la funzionalità di sottoscrizione degli eventi non è stata progettata per le aziende o per sostituire i sistemi che inviano eventi a un database esterno.

Questa funzionalità potrebbe, ad esempio, essere utilizzata con una piccola Web farm. Si supponga di disporre di un piccolo insieme di sistemi associati a uno specifico sito Web, inclusi server Web e server SQL. Tali sistemi possono consolidare le relative informazioni del registro eventi di protezione su un singolo sistema utilizzando la nuova funzionalità di sottoscrizione degli eventi. Gli ambienti di maggiori dimensioni richiedono in genere un set di strumenti di consolidamento del registro eventi più avanzato.

Audit Collection Services

Considerate tutte le nuove funzionalità di Windows Server 2008, la soluzione reale per la gestione e l'archiviazione a lungo termine delle informazioni del registro eventi di protezione è rappresentata da un database centralizzato di informazioni di controllo. Audit Collection Services è una funzionalità fondamentale di System Center Operations Manager 2007. ACS fornisce un meccanismo per l'inoltro, la raccolta, l'archiviazione e l'analisi dei dati degli eventi di protezione. Gli eventi di protezione vengono raccolti quasi in tempo reale e archiviati in un archivio SQL centrale. ACS offre inoltre alle organizzazioni un metodo per fornire l'accesso con privilegi minimi alle informazioni di controllo, in quanto non è necessario l'accesso fisico ai sistemi sottoposti a controllo. Passiamo ora a esaminare il funzionamento di ACS.

ACS include tre componenti principali. Primo, il server di inoltro, che rappresenta il componente dell'agente Operations Manager che trasmette i dati dei registri eventi dal client all'infrastruttura ACS. I server di inoltro trasmettono i dati al secondo componente, l'agente di raccolta, che rappresenta il listener sul lato server. I server di inoltro di ACS si connettono attraverso la porta TCP 51909 per comunicare in modo protetto con l'agente di raccolta ad essi associato. Prima della trasmissione, i dati dei registri eventi vengono normalizzati in formato XML, il che implica che le informazioni in eccesso vengono rimosse, mentre le informazioni sugli eventi vengono riepilogate in campi mappati in base alle informazioni del corpo e dell'intestazione specifiche degli eventi. Una volta raggiunto l'agente di raccolta, le informazioni vengono inviate al terzo e ultimo componente, il database ACS. Questo database diventa l'archivio per l'archiviazione a lungo termine delle informazioni degli eventi di protezione. Una volta memorizzate, è possibile eseguire ricerche nelle informazioni direttamente tramite query SQL o eseguirne il rendering utilizzando i report HTML tramite SQL Server® Reporting Services. ACS fornisce tre visualizzazioni predefinite, come illustrato nella Figura 7.

Figure 7 Visualizzazioni ACS

Dalla prospettiva delle prestazioni, un singolo agente di raccolta ACS può gestire un numero massimo di picco di 100.000 eventi al secondo e un numero massimo continuo di 2.500 eventi al secondo. Ai fini della pianificazione, un singolo agente di raccolta ACS è in grado di supportare fino a 150 controller di dominio, 3.000 server membro o 20.000 workstation in base alle impostazioni predefinite dei criteri di controllo. In uno scenario reale testato, circa 150 controller di dominio hanno riportato un massimo di 140 eventi circa al secondo con una media di picco di 500.000 eventi all'ora. In solo 14 giorni (l'impostazione di mantenimento predefinita per ACS), sono stati archiviati oltre 150 GB di dati di eventi di protezione nel database SQL Server. Una configurazione più "aggressiva" dei criteri di controllo e dei SACL associati genererà ovviamente un numero ancora maggiore di dati (all'ora, al giorno e a livello globale).

Il punto importante da considerare è che con questo volume di dati, nessun essere umano sarebbe in grado di esaminare ogni evento in un tipico ambiente aziendale di grandi dimensioni. Le organizzazioni, al contrario, non devono farsi intimorire dai numeri rappresentati in questo esempio. La comprensione delle modifiche che avvengono nel proprio ambiente presuppone l'inconveniente di analizzare una quantità elevata di dati.

È in tale contesto che ACS si esprime al meglio. Tramite SQL Server Reporting Services e ACS, è possibile trasformare i problemi generalmente nascosti all'interno del registro eventi di protezione in qualcosa facilmente identificabile, come gli eventi codificati a colori presenti nel registro eventi dell'applicazione. Sebbene ACS includa un insieme di report predefiniti, l'estensione di tali report per le esigenze specifiche dell'ambiente in uso è piuttosto semplice.

Si consideri il seguente scenario: a causa della riservatezza dei trust esterni nell'ambiente, il corpo direttivo ha richiesto lo sviluppo di un report in cui venga illustrata in dettaglio la creazione dei trust di Active Directory. Dopo alcune ricerche, si è scoperto che, quando si crea un trust, viene creato un oggetto trustedDomain nel contenitore cn=Sistema all'interno dello specifico contesto di denominazione del dominio in Active Directory. Dopo aver modificato il SACL in questo contenitore per controllare se la creazione di qualsiasi oggetto dominio trusted sia avvenuta in modo corretto, sarà possibile acquisire gli eventi di protezione ogni volta che viene creato un oggetto di questo tipo. Il rendering di queste informazioni viene eseguito nell'evento 566 nel registro eventi di protezione nel controller di dominio in cui è stato creato il trust. Per recuperare queste informazioni da ACS, è possibile scrivere una semplice query SQL:

select * from AdtServer.dvAll 
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc

Per includere tali informazioni in un report, utilizzare la versione di Visual Studio® 2005 inclusa in SQL Server 2005 Reporting Services, in quanto specificamente progettata per lo sviluppo di report. Dopo il completamento della procedura guidata, sarà piuttosto semplice creare report molto simili a quello riportato nella Figura 8. Inoltre, qualsiasi modifica nell'ambiente che è possibile rappresentare nel registro eventi di protezione, potrà essere riepilogata in un report dall'aspetto professionale simile a quello riportato in figura.

Figura 8** Report ACS di esempio **(Fare clic sull'immagine per ingrandirla)

Sviluppo di un piano di controllo

Una volta compresi i problemi e gli aspetti tecnici e legali del controllo, qual è l'iter che gli amministratori IT devono seguire per sviluppare un "piano di controllo" per la relativa organizzazione? Lo sviluppo di un criterio di controllo completo è un processo che prevede più fasi. La prima fase consiste nel determinare gli elementi da controllare. Questo include l'analisi dell'ambiente e la determinazione dei tipi di eventi e modifiche che devono generare i controlli. Questo potrebbe includere elementi semplici, come blocchi di account, modifiche a gruppi riservati e creazione di trust, o modifiche complesse, come la modifica degli elementi di configurazione all'interno delle applicazioni nel proprio ambiente. Il punto chiave è che i dirigenti devono essere coinvolti nella determinazione del "cosa" in un piano di controllo. Questo esercizio deve essere eseguito su carta e ripetuto a intervalli regolari, non solo dopo incidenti significativi.

La seconda fase consiste nell'identificare il metodo con cui le informazioni di controllo relative a specifiche modifiche vengono restituite sotto forma di eventi di protezione. Le informazioni di controllo sono a volte enigmatiche e non facilmente leggibili. Prima dell'implementazione, è necessario stabilire delle correlazioni tra gli eventi di protezione e le varie azioni per comprendere il reale significato degli eventi di protezione. Il momento immediatamente successivo al verificarsi di un problema significativo non rappresenta il momento opportuno per stabilire delle relazioni tra gli eventi e le azioni.

La terza fase prevede l'implementazione dei criteri di controllo e dei SACL. Come discusso in precedenza, è necessario definire le impostazioni dei criteri di controllo (per attivare la generazione di eventi di protezione) e i SACL (per generare gli audit trail per le azioni associate) nella directory, nel file system e nel Registro di sistema in modo da ottenere un quadro completo delle modifiche in queste aree.

Tutto questo ci porta alla quarta e ultima fase: la raccolta, i trigger e l'analisi. A seconda delle dimensioni e delle esigenze dell'organizzazione, è possibile eseguire queste operazioni utilizzando le funzionalità native di Windows Server 2008 o soluzioni avanzate, come la funzionalità Audit Collection Services di System Center Operations Manager. Un errore comune commesso dalla maggior parte delle organizzazioni è impostare solo i criteri di controllo senza definire i SACL. L'ultimo passaggio riguarda sostanzialmente l'implementazione di una soluzione tecnologica per l'inclusione di dati in report e la condivisione dei dati con gli interessati nell'organizzazione. In precedenza si è affermato che la maggior parte delle organizzazioni prevede un'entità stabilita responsabile della protezione e che un piano di controllo, per essere efficace, deve essere strutturato intorno agli elementi organizzativi esistenti. L'elemento chiave per il successo di questo passaggio finale consiste ne raccogliere e nel presentare le informazioni in modo significativo a tutti coloro che hanno la responsabilità di comprendere le modifiche nell'ambiente.

Nella maggior parte delle organizzazioni IT il verificarsi di un evento significativo è ciò che separa la semplice considerazione di un piano di controllo completo dall'effettiva adozione. Windows Server 2008 fornisce, rispetto alle piattaforme precedenti, meccanismi migliorati per la raccolta e l'analisi dei dati degli eventi di protezione. Tecnologie avanzate per la raccolta e la creazione di report, come ACS, espongono problemi una volta nascosti dal volume e dalla distribuzione degli eventi, evidenziando queste modifiche in modo immediato.

Come la maggior parte dei problemi IT, il processo rappresenta la sfida principale. Operazioni aggiuntive di configurazione e analisi sono sempre necessarie per soddisfare le aspettative dei manager IT; pertanto, una conoscenza approfondita dei requisiti dell'ambiente in uso e delle funzionalità della piattaforma Windows consentirà di far fronte a queste problematiche in modo immediato. Ricerca efficace.

Rob Campbell e Joel Yoker Rob Campbell è uno specialista tecnico senior, mentre Joel Yoker è un consulente senior del team federale Microsoft. Joel e Rob si occupano dello sviluppo e della distribuzione di soluzioni di protezione per clienti nel governo federale degli Stati Uniti.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.