Reporting della conformità: introduzione al controllo degli accessi client alla Cloud

Articolo
08/24/2016

Come migliorare le attività di reporting di controllo e della conformità mediante l'utilizzo di Protezione accesso alla rete e del protocollo IPsec per controllare l'accesso dei client tramite DirectAccess.

Dan Griffin e Lee Walker

La configurazione di un accesso protetto rappresenta il primo passo logico per estendere l'infrastruttura aziendale alla Cloud. Configurando subito i criteri per la conformità, il reporting e la connettività in remoto, creerete le condizioni per consentire al vostro team di lavorare all'interno della cloud in modo semplice e sicuro. L'utilizzo di tecnologie di connessione di Protezione accesso alla rete con IPsec come DirectAccess vi aiuteranno a migliorare le vostre attività di reporting di controllo e della conformità.

Può risultare difficile identificare e raccogliere i dati necessari per la creazione di una soluzione di controllo e reporting per una nuova distribuzione di DirectAccess o IPsec. Illustreremo come un'ipotetica azienda potrebbe creare una soluzione DirectAccess e di Protezione accesso alla rete e fornire i dati di reporting per stabilire gli utenti connessi, i relativi orari di connessione e il livello di conformità dei computer client.

Il problema della conformità

A causa del costante aumento di forza lavoro sempre più mobile, un maggior numero di aziende adotta tecnologie di accesso remoto flessibili come DirectAccess. Con DirectAccess, ogniqualvolta una macchina autorizza si connette a Internet, l'utente viene automaticamente connesso alla rete remota. Poiché i client remoti possono talvolta non essere aggiornati con le patch di sicurezza o essere infetti da malware, molte aziende distribuiscono anche la tecnologia Protezione accesso alla rete con IPsec per garantire l'accesso alle risorse protette solo ai client integri.

In settori quali i servizi finanziari, il settore sanitario e delle amministrazioni pubbliche, l'importanza di verificare che solo i client integri e approvati si connettano alle risorse di rete basate su cloud o in sede è fondamentale per garantire l'integrità dei dati. Tali settori devono spesso, in base a quanto richiesto da criteri di conformità interni e a leggi federali, verificare che non avvengano accessi alle informazioni che consentono l'identificazione personale dell'utente, quali numeri di conto corrente bancario, nomi e cartelle cliniche, da parte di utenti non autorizzati (compresi malware e applicazioni di terze parti sconosciute).

Poiché gli utenti sono alla ricerca di modalità di accesso remoto più semplici alle proprie risorse di lavoro, i responsabili IT in tali settori protetti devono inoltre garantire che l'accesso alla rete aziendale sia consentito solo ai client integri. Sfortunatamente, risulta problematico creare rapporti significativi sulla base dei registri generati da Protezione accesso alla rete e DirectAccess.

La soluzione è rappresentata dalla configurazione di un'infrastruttura DirectAccess per garantire un accesso remoto dei client senza problemi, dalla protezione delle risorse disponibili nella rete intranet mediante Protezione accesso alla rete e IPsec e dal monitoraggio dei criteri mediante le attività di reporting. TechNet include alcune informazioni utili su come implementare un'infrastruttura di Protezione accesso alla rete con DirectAccess, ma sono disponibili informazioni limitate sulle modalità di registrazione e reporting efficienti per stabilire l'integrità dei client. Esamineremo un'ipotetica azienda (Woodgrove National Bank) e illustreremo come un consulente possa utilizzare delle semplici righe di codice e query SQL per creare rapporti leggibili in cui siano incluse informazioni dettagliate sui client connessi durante un periodo di tempo specificato e sul relativo livello di compatibilità con la tecnologia di Protezione accesso alla rete.

Configurazione della tecnologia di Protezione accesso alla rete in un'infrastruttura DirectAccess

Per utilizzare la tecnologia DirectAccess è necessario che sui client che eseguono la connessione sia in esecuzione una versione compatibile di Windows (Windows 7 Ultimate o Windows 7 Enterprise). I client si connettono a un server DirectAccess su cui è in esecuzione Windows Server 2008 R2. Una distribuzione DirectAccess può comprendere uno o più server DirectAccess. Si consiglia di implementare almeno due server per bilanciare il carico in reti a elevato traffico. La distribuzione deve inoltre includere un server dei percorsi di rete (per stabilire se il client sia connesso a Internet o alla rete intranet) e uno o più punti di distribuzione di elenchi di revoche di certificati (CRL), utilizzati per tenere traccia dei client a cui non deve più essere consentito l'accesso. Per informazioni sulla progettazione di una distribuzione di DirectAccess, vedere la Guida alla progettazione di DirectAccess su TechNet.

Quando si aggiunge la tecnologia di Protezione accesso alla rete a un'infrastruttura DirectAccess, è necessario implementare il metodo di imposizione IPsec per Protezione accesso alla rete. Quando si utilizza il protocollo IPsec, ai client compatibili con Protezione accesso alla rete vengono concessi certificati di integrità. Ai computer non compatibili non è consentito comunicare con computer compatibili. Per informazioni sulla progettazione e sulla distribuzione di Protezione accesso alla rete, vedere Planning DirectAccess with Network Access Protection su TechNet. Per informazioni sulla progettazione della tecnologia di Protezione accesso alla rete con IPsec come metodo di imposizione, vedere IPsec Enforcement Design su TechNet.

È interessante considerare come lo scenario di imposizione di Protezione accesso alla rete con IPsec funzioni nel contesto di DirectAccess e dei relativi criteri di connessione IPsec. Innanzitutto, poiché DirectAccess utilizza il protocollo IPsec per l'autenticazione e lo scambio di informazioni riservate, lo scenario di imposizione di Protezione accesso alla rete in una distribuzione di DirectAccess deve essere basato sul protocollo IPsec. In secondo luogo, occorre tenere presente che il componente AuthIP di IPsec consente di configurare due requisiti di autenticazione indipendenti nel criterio che dovranno essere entrambi soddisfatti per consentire il completamento della connessione. Solitamente, se sono configurate entrambe le opzioni di autenticazione AuthIP, la prima è costituita dalle credenziali della macchina mentre la seconda dalle credenziali dell'utente. È, tuttavia, tecnicamente possibile configurare due credenziali per macchina.

Come si inserisce la tecnologia di Protezione accesso alla rete all'interno dei criteri AuthIP? Lo scenario di imposizione di Protezione accesso alla rete/IPsec fornisce alle macchine integre un certificato con un identificato di integrità oggetto. Il sistema di gestione dei criteri AuthIP include un'opzione per richiedere tale identificatore. Tuttavia, solo le macchine integre saranno in grado di soddisfare il primo requisito di autenticazione AuthIP e stabilire una connessione IPsec al server DirectAccess.

Infine, le credenziali dell'utente rappresentano lo scopo della seconda opzione di autenticazione AuthIP. Le credenziali dell'utente sono tecnicamente facoltative per DirectAccess. In altre parole, i client possono eseguire l'autenticazione con l'endpoint DirectAccess utilizzando semplicemente un certificato macchina. Il personale IT attento alla sicurezza dovrebbe preoccuparsi di concedere un accesso remoto alla rete completo senza implementare un sistema di autenticazione avanzato. Pertanto, come minimo, sarebbe opportuno configurare il criterio AuthIP in modo che richieda una seconda autenticazione Kerberos. La richiesta di un certificato per le credenziali dell'utente, come nel caso della Woodgrove National Bank, rappresenta la scelta preferibile, perché riduce il rischio di attacchi remoti a password statiche.

In tale scenario, i reparti responsabili della protezione della rete e della conformità di Woodgrove National Bank hanno richiesto un rapporto in cui siano indicati gli utenti connessi alla rete aziendale in un periodo di tempo specificato e il relativo livello di compatibilità dei client con Protezione accesso alla rete. Tali reparti ritengono possa essersi verificata una compromissione dei dati dei clienti in tale periodo di tempo. In qualità di consulenti della banca, dobbiamo stabilire come attivare un sistema di reporting a posteriori per Direct Access e Protezione accesso alla rete da cui derivarne delle informazioni da convertire in un formato leggibile.

Configurazione corretta dei criteri

In questo scenario ipotetico, Woodgrove National Bank ha configurato DirectAccess in modo che il criterio IPsec richieda i certificati client che includano un identificato di integrità oggetto di Protezione accesso alla rete e un identificatore di oggetto di autenticazione client. Woodgrove utilizza la tecnologia Protezione accesso alla rete in modalità di imposizione (invece che in modalità di reporting), il che comporta il blocco delle comunicazioni tra client non integri e client integri.

Infine, Woodgrove ha configurato il criterio IPsec di DirectAccess per l'utilizzo di due credenziali basati su certificato, uno del computer client e un altro dell'utente. Come suggerito in precedenza, Woodgrove ha scelto la configurazione a doppio certificato per sfruttare al meglio la propria infrastruttura a chiave pubblica (PKI), per eliminare le password statiche per l'accesso remoto e per sfruttare i vantaggi della registrazione automatica dei certificati.

Per la parte restante di questo articolo, si presuppone che il lettore disponga di una conoscenza pratica delle modalità di funzionamento delle tecnologie DirectAccess, Protezione accesso alla rete e della modalità di imposizione IPsec. Per ulteriori informazioni su queste tecnologie, vedere i riferimenti seguenti:

Nella soluzione di reporting seguente vengono sfruttate le funzioni di controllo incorporate del protocollo IPsec sul server DirectAcces nonché le funzionalità di controllo dell'Autorità registrazione integrità del Server dei criteri di rete. Tali funzioni di controllo producono eventi nei log eventi di sistema e di protezione che provvederemo a estrarre e a includere in un rapporto. Durante lo sviluppo di questa strategia, abbiamo scoperto che gli eventi dell'Autorità registrazione integrità vengono prodotti per impostazione predefinita, mentre è possibile sia necessario abilitare gli eventi IPsec in modo esplicito. Per abilitare gli eventi IPsec, è possibile utilizzare i seguenti comandi in una finestra del prompt dei comandi:

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Main Mode" /success:enable /failure:enable

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Quick Mode" /success:enable /failure:enable

auditpol.exe /set /category:"Logon/Logoff" /subcategory:"IPsec Extended Mode" /success:enable /failure:enable

Reporting dell'integrità di DirectAccess

Per iniziare a utilizzare gli eventi di Protezione accesso alla rete e di DirectAccess di Woodgrove National Bank, abbiamo scaricato e installato lo strumento Log Parser 2.2 di Microsoft. Log Parser è uno strumento indispensabile per un progetto simile a questo, in cui è necessario analizzare una nuova origine eventi e sviluppare un relativo schema appropriato. In sintesi, Log Parser consente di importare da ed esportare in diversi formati di dati, tra cui registro eventi di Windows (.evtx), CSV ed SQL.

Il passaggio successivo consiste nell'acquisire gli eventi di interesse, tra cui:

Gli eventi correlati all'associazione di protezione IPsec nel registro di protezione dei server DirectAccess
Gli eventi correlati all'Autorità registrazione integrità nei registri di protezione e di sistema del server o dei server Autorità registrazione integrità (tale condizione è valida solo se si utilizza Protezione accesso alla rete)

Una soluzione ideale per acquisire tali eventi deve essere automatizzata e centralizzata. La funzione di inoltro eventi di Windows potrebbe rappresentare un'opzione. Microsoft System Center è la soluzione più adatta in una distribuzione di produzione di grosse dimensioni. Nel nostro caso, non volendo introdurre nuove dipendenze per i server di produzione, abbiamo optato per semplici script per l'acquisizione degli eventi.

Con questo approccio, il problema è duplice. In primo luogo, poiché l'obbiettivo è mettere in correlazione più origini dati, è importante che i dati provenienti da tute le origini vengano approssimativamente acquisiti contemporaneamente. In secondo luogo, poiché stiamo acquisendo solo un'istantanea dei registri e i registri eventi a traffico elevato di dati vengono generati rapidamente, è inevitabile che alcuni eventi di correlazione non saranno inclusi, specialmente in prossimità del termine del periodo di tempo oggetto dell'istantanea. Tuttavia, tale condizione non invalida l'esperimento, ma rende più difficile l'ottimizzazione delle query.

Per ciascuna associazione di protezione in modalità principale IPsec (su uno dei server DirectAccess) prevediamo di rilevare del traffico di scambio informazioni di integrità (su uno dei server Autorità registrazione integrità). Nella modalità di reporting Protezione accesso alla rete, la macchina client non deve essere obbligatoriamente compatibile. Nella modalità di imposizione Protezione accesso alla rete, la macchina cliente deve essere necessariamente compatibile. In alternativa, in che modo può disporre di un certificato valido per l'autenticazione con il server DirectAccess e per stabilire un'associazione di protezione? Supponiamo di eseguire l'acquisizione un'unica acquisizione dei registri di tutti i server DirectAccess e di Autorità registrazione integrità simultaneamente alle ore 15.00. È possibile che rileveremmo lo stesso evento di associazione della protezione in modalità principale, ma che non rileveremmo alcun evento di scambio informazioni di integrità.

È ancora più probabile che rileveremmo eventi di associazione della protezione in modalità rapida e in modalità estesa IPsec, ma nessun evento di associazione della protezione in modalità principale o di scambio informazioni di integrità. Il primo caso può verificarsi fino a un'ora prima o oltre dopo l'ultimo. Inoltre, poiché i registri presenti su server dipendenti quasi certamente vengono generati con frequenze diverse, potremmo ritrovarci con eventi verificatisi alle 14.00 sul server DirectAccess, ma sono con eventi verificatisi appena non prima delle 14.30 sul server di Autorità registrazione integrità. Per tali motivi, vorremo ribadire che è importante utilizzare sistemi di acquisizione eventi centralizzati in ambienti di produzione.

Generazione dei dati

Per generare i dati, abbiamo eseguito script sui server DirectAccess e di Autorità registrazione integrità. Abbiamo inoltre configurato gli script per l'esecuzione automatica mediante Utilità di pianificazione. Abbiamo configurato gli script per l'esecuzione simultanea sul server DirectAccess e su tutti i server di Autorità registrazione integrità.

Raccolta dei dati sui server DirectAccess

Abbiamo utilizzato lo script seguente per acquisire gli eventi sul server DirectAccess (vedere la Figura 1):

set MPATH=c:\temp\Logs

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\DA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12549 OR EventCategory=12547 OR EventCategory=12550" -o:CSV

Nota: in questo script viene utilizzata una copia locale di LogParser.exe (and della dipendenza LogParse.dll). Il riferimento è stato utilizzato per comodità in modo da consentirci di copiare facilmente lo script da un server a un altro.

Figura 1 Dettagli degli eventi acquisiti dal server DirectAccess mediante uno script eseguito automaticamente tramite Utilità di pianificazione.

Evento	Descrizione
12547	Informazioni sull'associazione della protezione in modalità principale IPsec
12549	Informazioni sull'associazione della protezione in modalità rapida IPsec
12550	Informazioni sull'associazione della protezione in modalità estesa IPsec

Raccolta dei dati sui server di Autorità registrazione integrità

Abbiamo utilizzato lo script seguente per acquisire gli eventi sui server di Autorità registrazione integrità:

set MPATH=c:\temp\Logs

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_Security_Events_%COMPUTERNAME%.csv FROM Security WHERE EventCategory=12552" -o:CSV

%MPATH%\LogParser.exe "SELECT * INTO %MPATH%\HRA_System_Events_%COMPUTERNAME%.csv FROM System WHERE SourceName='HRA'" -o:CSV

Nota: nello script per i server di Autorità registrazione integrità, la categoria evento 12552 è associata al servizio Server dei criteri di rete.

Importazione dei dati

Dopo l'esecuzione degli script, abbiamo acquisito i file CSV di output in una macchina separata su cui è in esecuzione SQL Server 2008. Abbiamo utilizzato lo script seguente per importare i dati in formato CSV in SQL:

LogParser.exe "SELECT * INTO DaSasTable FROM DA_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023
LogParser.exe "SELECT * INTO HraSecurityEventsTable  FROM HRA_Security_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023
LogParser.exe "SELECT * INTO HraSystemEventsTable  FROM HRA_System_*.csv" -i:CSV -o:SQL -server:dev1 -database:NapDa -createTable:ON -maxStrFieldLen:1023

Note:

Il nome della macchina host SQL è dev1. Il nome del database è NapDa e i database sono stati creati utilizzando i valori predefiniti in SQL Management Studio.
Le tre tabelle, DaSasTable, HraSecurityEventsTable e HraSystemEventsTable non erano preesistenti. L'opzione della riga di comando -createTable:ONLog Parser indica a Log Parser di creare automaticamente le tavella con uno schema compatibile basato sui dati di input (i file CSV del registro eventi, in questo caso).
L'impostazione -maxStrFieldLen:1023 è importante in questo scenario. Senza questa impostazione, verrebbe utilizzata da Log Parser una lunghezza del campo varchar pari a 255 per i vari campi stringa del registro eventi. Tuttavia, il formato CSV del registro eventi dispone di alcune stringhe di dati più lunghe di questo limite (in particolare nel campo Strings; vedere la Figura 2) ed è importante che non vengano troncate. A livello sperimentale, una lunghezza predefinita pari a 1023 risulta essere sufficiente.

La Figura 2 mostra lo schema risultante dall'importazione del registro eventi in formato CSV da parte di Log Parser.

La Figura 2 mostra lo schema risultante dall'importazione del registro eventi in formato CSV da parte di Log Parser.

Figura 2 Schema dell'importazione del registro eventi in formato CSV da parte di Log Parser.

Preparazione dei dati

Durante la creazione del rapporto di integrità di DirectAccess, il problema principale in termini di estrazione dei dati richiesti è rappresentato dal fatto che il formato CSV del registro eventi è basato su stringhe di dati. Nel contesto di un'interfaccia utente, i dati sono interfoliati in stringhe statiche che descrivono il significato di ciascun campo dati. Le stringhe di dati includono tutte le informazioni interessanti per un rapporto di integrità di DirectAccess, tra cui nomi utente, nomi macchine, nomi di gruppi di criteri e indirizzi IP.

Le stringhe di dati sono concatenante in un singolo campo CSV e alla fine in una singola colonna SQL (anche in questo caso, di stringhe). Ciascuna stringa è separata dalla successiva dal carattere "|". Una possibile consiste nel suddividere le stringhe in token, prima o immediatamente dopo l'importazione dei dati in SQL. Tuttavia, abbiamo preferito di analizzare invece le stringhe dopo l'importazione in SQL, estrarre i pochi elementi di dati specifici necessari e di popolare le tabelle SQL separate con tali elementi.

Completare questa attività tramite la corrispondenza dei modelli delle stringhe mediante T-SQL può risultare un'impresa difficile. Come alternativa, abbiamo utilizzato un approccio documentato in un articolo precedente di MSDN Magazine, "Le espressioni regolari semplificano l'estrazione dei dati e delle corrispondenze dei modelli" il quale tratta dell'implementazione delle funzioni definite dall'utente per codice SQL basato sul linguaggio C#, specificamente rivolta alla corrispondenza di modelli basati su espressioni regolari.

Utilizzando Visual Studio 2008, ci siamo attenuti quasi esattamente alle istruzioni indicate nell'articolo, benché si sia rivelato utile consultare la documentazione aggiuntiva per consentire il funzionamento dell'integrazione iniziale del codice SQL e CLR con Visual Studio. Inoltre, a causa della complessità intrinseca delle espressioni regolari (RegEx), si è rivelato utile consultare anche la documentazione relativa alla tecnologia e in particolare la sezione sul raggruppamento, poiché è questo l'approccio utilizzato per il codice di esempio illustrato nell'articolo di MSDN Magazine.

Nel seguente esempio di codice viene illustrato il codice sorgente per la funzione definita dall'utente SQL che espone le funzionalità RegEx nelle nostre istruzioni SELECT. La funzione è denominata RegexGroup, esattamente come quella illustrata nell'articolo di MSDN Magazine. Abbiamo apportato una modifica nelle prime due righe del corpo della funzione in modo da poter controllare i valori di input NULL. Prima di aggiungere le due righe, abbiamo riscontrato numerose eccezioni perché diverse colonne della tabella SQLHelper (descritte in questo esempio) hanno valori NULL:

usingSystem;

usingSystem.Data;

usingSystem.Data.SqlClient;

usingSystem.Data.SqlTypes;

usingMicrosoft.SqlServer.Server;

usingSystem.Text.RegularExpressions;

publicpartialclassUserDefinedFunctions

{

    [Microsoft.SqlServer.Server.SqlFunction]

publicstaticSqlChars RegexGroup(

SqlChars input, SqlString pattern, SqlString name)

{

if (true == input.IsNull)

returnSqlChars.Null;

Regex regex = newRegex(pattern.Value, Options);

Match match = regex.Match(newstring(input.Value));

returnmatch.Success ?

newSqlChars(match.Groups[name.Value].Value) : SqlChars.Null;

}

};

I seguenti comandi SQL consentono di creare e popolare due tabelle dell'helper costituite da stringhe estratte dall'insieme di dati iniziale mediante RegEx:

/* Create the User-Computer-Address mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE UserComputerAndAddr
(
[RowN] int null,
[UserName] varchar(1023) null,
[ComputerName] varchar(1023) null,
[Address] varchar(1023) null
)

/* Populate the User-Computer-Address table */
/* This step should only be performed once per data set */
INSERT INTO UserComputerAndAddr(RowN, UserName, ComputerName, Address)
SELECT RowNumber,
    dbo.RegexGroup([Strings],N'(?<un>[0-9a-zA-Z]+)@redmond.corp.microsoft.com',N'un'),
    dbo.RegexGroup([Strings],N'(?<machine>[0-9a-zA-Z\-]+)(?<!CO1RED-TPM-01)\$@redmond.corp.microsoft.com',N'machine'),
    dbo.RegexGroup([Strings],N'(?<ipv6addr>[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4}:[0-9a-fA-F]{1,4})',N'ipv6addr')
FROM [NapDa].[dbo].[DaSasTable]

/* Create the Computer-Health mapping helper table */
/* This step should only be performed once per data set */
CREATE TABLE ComputerHealth
(
[RowN] int null,
[TimeGenerated] datetime null,
[EventType] int null,
[ComputerName] varchar(1023) null
)

/* Populate the Computer-Health mapping table */
/* This step should only be performed once per data set */
INSERT INTO ComputerHealth(RowN, TimeGenerated, EventType, ComputerName)
SELECT RowNumber,
    TimeGenerated,
    EventType,
    dbo.RegexGroup([Strings],N'REDMOND\\(?<machine>[0-9a-zA-Z\-]+)\$',N'machine')
FROM [NapDa].[dbo].[HraSystemEventsTable]

Per ottenere un'immagine chiara dei modelli di stringhe, occorre esaminare la prima istruzione SELECT e il relativo utilizzo della funzione RegexGroup installata con la tecnica descritta. Nella Figura 3 vengono illustrati i modelli RegEx definiti.

Figura 3 I tre modelli RegEx definiti mediante i comandi SQL.

Modello di espressioni regolari	Note
Nome utente	Esempio: ichiro@redmond.corp.microsoft.com
Nome computer	Esempio: dan-dev-1@redmond.corp.microsoft.com Si osservi che, in questo modello, stiamo escludendo in modo esplicito le corrispondenze relative al server DirectAccess stesso.
Indirizzo IPv6	Esempio: 2001:0:4137:1f6b:8c8:2f30:e7ed:73a8 · Questo modello non corrisponderà a tutti gli indirizzi IPv6 validi. Sarà necessario ampliare il modello se si desidera utilizzarlo in altri contesti. · Benché fossero presenti altri campi indirizzo IPv6 incorporati nella colonna Strings, l'indirizzo del client è risultato essere l'unico corrispondente a tale modello. Potrebbe essere necessario rieseguire la procedura se si ottengono indirizzi imprevisti nelle query.

Complessivamente tali espressioni regolari consentono di creare una tabella costituita dalle informazioni sugli utenti, sui computer e sugli indirizzi provenienti da ciascuna riga della tabella DaSasTable (ad esempio, gli eventi di associazione della protezione IPsec esportati dalla macchina DirectAccess).

Dopo aver completato la creazione e il popolamento della tabella UserComputerAndAdd, viene creata una seconda tabella che associa il nome del computer al tipo di evento per ciascun riga presente nella tabella HraSystemEventsTable. Se si esamina il modello di nomi di computer, si scoprirà che il formato del nome di computer è diverso in questo registro rispetto al registro di DirectAccess. Nel nostro caso, stiamo cercando stringhe simili a REDMOND\dan-dev-1. Nella Figura 4 vengono descritti i diversi eventi che potrebbero essere presenti nel campo EventType.

Figura 4 Tipi di eventi che potrebbero essere presenti nel campo EventType.

Tipo di evento	Descrizione
0	Operazione riuscita. Il computer ha inviato un rapporto di integrità di Protezione accesso alla rete compatibile.
1	Errore. Il computer non era compatibile con il criterio di Protezione accesso alla rete.

Nel rapporto di integrità per questa distribuzione, prevediamo solo di rilevare tipi di eventi 0, perché Protezione accesso alla rete è utilizzato in modalità di imposizione. Come è possibile vedere di seguito, vengono filtrate anche associazioni della protezione IPsec correttamente completate. Se il client non fosse stato compatibile, non sarebbe neanche stato in grado di acquisire un certificato IPsec valido e stabilire un'associazione della protezione. D'altro canto, se la vostra azienda ha distribuito Protezione accesso alla rete in modalità di reporting, è prevedibile che siano presenti alcune macchine non compatibili. La percentuale relativa di macchine compatibili rispetto alle macchine non compatibili connesse alla rete rappresenta un importante parametro statistico da includere nel rapporto.

Nota: quando si utilizzano i risultati di RegEx, si consiglia di utilizzare tabelle SQL permanenti. Se si utilizzano tabelle temporanee (come faremo nella dimostrazione illustrata nel prossimo passaggio), le query RegEx verranno eseguite lentamente.

Creazione del rapporto

Avendo completato l'analisi delle espressioni regolari e la creazione delle tabelle dell'helper, possiamo concentrarci sulla creazione del rapporto di integrità. Una volta preparati i dati, la creazione delle query per la creazione del rapporto è relativamente semplice.

Lo scopo di questo rapporto di esempio consiste nell'elencare tutti gli utenti che hanno stabilito una connessione al server DirectAccess tra le 15.00 e le 16.00 del 5 maggio 2010. Oltre al nome utente, nel rapporto viene indicato il nome del computer e lo stato di integrità.

Per poter identificare gli utenti, inizieremo a eseguire query di associazioni della protezione in modalità rapida (categoria evento 12549) completate correttamente (tipo di evento 8) verificatisi in tale periodo di tempo. L'evento di associazione della protezione in modalità rapida è utile in questo scenario poiché il protocollo IPsec è stato configurato per la richiesta dell'autenticazione basata su un secondo fattore (le credenziali dell'utente). Abbiamo scelto di utilizzare questo approccio di reporting perché le associazioni della protezione in modalità rapida sono relativamente brevi (un'ora, in questo caso, con un timeout di inattività di cinque minuti) e pertanto risultano utili per il controllo degli accessi. Un'associazione della protezione in modalità principale, al contrario, implica solo l'utilizzo delle credenziali del computer e ha una durata di otto ore per impostazione predefinita (benché consigliamo di ridurre la durata della modalità principale se l'attività di controllo è un componente importante della distribuzione DirectAccess).

Sfortunatamente, gli eventi in modalità rapida non includono né il nome utente, né il nome macchina, ma solo l'indirizzo IP. Per associare l'indirizzo IP a un nome macchina e a un nome utente, possiamo utilizzare alcune istruzioni SELECT all'interno della nostra query SQL. La prima istruzione SELECT nella query seguente restituirà l'elenco di indirizzi riportati in nuove associazioni della protezione in modalità rapida entro il periodo specificato. La seconda istruzione SELECT utilizza tali indirizzi per l'associazione del nome utente e del nome computer associati all'indirizzo in altri punti del registro. Questa associazione utente/computer/indirizzo si trova negli eventi di associazione della protezione in modalità estesa. Tali eventi sono fondamentali per questo esercizio poiché contengono tutti i tre valori; se non viene richiesta l'autenticazione secondaria IPsec, non sarà possibile eseguire questo tipo di reporting.

/* The following steps build the report, based on the three imported tables

* plus the two helpers above. These steps can be run any number of times as

* you refine your query.

*/

/* Create a temporary table to populate as the final report */

CREATE TABLE #SaHealthReport
(

[UserName] varchar(1023) null,

[ComputerName] varchar(1023) null,

[HealthEventType] int null

)

/* Run a query to find all IPsec Quick Mode Security Associations established

* within a given period. Populate a temporary table with the client IPv6

* addresses. */

SELECT DISTINCT[Address] INTO #TempAddresses

FROM [NapDa].[dbo].[DaSasTable] JOIN [NapDa].[dbo].[UserComputerAndAddr]

      ON RowN = RowNumber

WHERE [EventType]=8 AND

      [EventCategory]=12549 AND

      ([TimeGenerated] BETWEEN'2010-05-10 15:00:00.000' AND '2010-05-10 16:00:00.000')

/* Map the QM SA addresses to user and computer names and insert those into

* the final report. */

INSERT INTO #SaHealthReport(UserName,ComputerName)

SELECT UserComputerAndAddr.UserName,UserComputerAndAddr.ComputerName

FROM [NapDa].[dbo].[UserComputerAndAddr] JOIN #TempAddresses

      ON #TempAddresses.Address = UserComputerAndAddr.Address

WHERE (UserComputerAndAddr.UserName IS NOT NULL) AND (UserComputerAndAddr.ComputerName IS NOT NULL)

/* Populate the health column of the report. */

UPDATE #SaHealthReport

SET HealthEventType = ComputerHealth.EventType

FROM #SaHealthReport JOIN [NapDa].[dbo].[ComputerHealth]

      ON #SaHealthReport.ComputerName = ComputerHealth.ComputerName

/* Display all rows and columns of the report. */

SELECT DISTINCT *

FROM #SaHealthReport

Il passaggio finale per popolare le tabelle del rapporto SaHealthReport consiste nella correlazione delle informazioni di integrità dell'Autorità registrazione integrità con le informazioni relative all'identità del computer e dell'utente che finora sono state acquisite esclusivamente dal server DirectAccess. L'integrazione delle informazioni sul server di Autorità registrazione integrità rappresenta uno strumento potente che consente di stabilire se il computer che si connette in remoto alla propria rete possa rappresentare un rischio (dovuto alla non compatibilità). Vedere l'istruzione UPDATE nella query SQL precedente: la correlazione tra i dati del server DirectAccess e del server di Autorità registrazione integrità viene ottenuta mediante l'utilizzo del nome computer.

Nella Figura 5 vengono mostrati dati di esempio che potrebbero essere restituiti a seguito del completamento di un rapporto di integrità.

Figura 5 Rapporto di integrità completato di esempio

UserName	ComputerName	HealthEventType
Ichiro	ichiroadmin1	0
Grinch	whoville-cli	0
Raquel	omybc	0

È possibile creare rapporti relativi a distribuzioni IPsec (compreso DirectAccess) e Protezione accesso alla rete in modo relativamente semplice grazie ad alcuni script personalizzati e allo strumento LogParser. Questo approccio consentirà a un'azienda di iniziare la creazione di un'infrastruttura protetta per la distribuzione di servizi line-of-business sia in sede che nella cloud.

Invia un messaggio di posta elettronica a Dan Griffin

Dan Griffin è un consulente esperto nella protezione del software che risiede a Seattle. È possibile contattarlo all'indirizzo www.jwsecure.com

Invia un messaggio di posta elettronica a Lee Walker

Lee Walker è Technology Architect per il reparto IT interno di Microsoft, specializzato in IPv6, IPsec, Protezione accesso alla rete, DirectAccess e altre tecnologie. È possibile contattarlo all'indirizzo lee.walker@microsoft.com.