Relatórios de conformidade: primeiro passo para o controle do acesso do cliente à nuvem

Melhore seus relatórios de auditoria e conformidade usando NAP e IPsec para controlar o acesso para cliente por meio do DirectAccess.

Dan Griffin e Lee Walker

Estabelecer acesso seguro é um primeiro passo lógico para a extensão da empresa na nuvem. Definindo políticas para conformidade, relatórios e conectividade remota agora, você define o cenário em que sua equipe atuará na nuvem de maneira tranquila e segura. O uso da NAP (Proteção de Acesso à Rede) com tecnologias de conectividade IPsec como DirectAccess pode ajudar, melhorando seus relatórios de auditoria e conformidade.

Pode ser difícil identificar e reunir os dados necessários quando se cria uma solução de auditoria e relatórios para uma nova implantação de DirectAccess ou IPsec. Aqui, mostraremos como uma empresa hipotética pode criar uma solução com DirectAccess e NAP, e fornecer dados de relatório para determinar quem estava conectado, quando e se o computador cliente estava em conformidade.

O problema da conformidade

Conforme a força de trabalho vai se tornando cada vez mais móvel, mais organizações estão adotando tecnologias flexíveis de acesso remoto como DirectAccess. Com o DirectAccess, toda vez que um computador autorizado se conecta à Internet, o usuário é conectado automaticamente à rede remota. Como os clientes remotos podem ocasionalmente estar desatualizados com relação aos patches de segurança e talvez infectados por malware, muitas organizações também implantam a NAP com IPsec para ajudar a garantir que apenas clientes íntegros acessem recursos protegidos.

Em setores como os de serviços financeiros, saúde e governo, confirmar que apenas clientes íntegros e aprovados se conectem a recursos baseados na nuvem ou de rede no local é de importância vital para a integridade dos dados. Esses setores frequentemente precisam cumprir exigências de políticas internas de conformidade e da legislação federal no sentido de confirmar que nenhuma parte não autorizada (incluindo malware e aplicativos de terceiros desconhecidos) teve acesso a informações de identificação pessoal, como números de contas bancárias, nomes e registros médicos.

Conforme os usuários buscam obter acesso remoto mais fácil a seus recursos profissionais, os gerentes de TI desses setores protegidos devem também garantir que apenas clientes íntegros acessem a rede corporativa. Infelizmente, a criação de relatórios significativos a partir de logs da NAP e DirectAccess traz alguns desafios.

Configurar a infraestrutura do DirectAccess para acesso integrado do cliente remoto, proteger os recursos da intranet com NAP e IPsec, e monitorar a política através de relatórios é a solução. O TechNet apresenta boas informações sobre como implementar NAP com DirectAccess, mas há poucas orientações sobre como registrar em log e gerar relatórios de integridade do cliente de forma eficaz. Examinaremos uma empresa hipotética (o Banco Nacional de Woodgrove) e mostraremos como um consultor poderia usar código simples e consultas SQL para criar relatórios legíveis, detalhando os clientes que se conectaram durante um período específico e se eles eram compatíveis com a NAP.

Configurando a NAP sobre o DirectAccess

O DirectAccess requer que os clientes que se conectarem executem uma versão compatível do Windows (Windows 7 Ultimate ou Windows 7 Enterprise). Esses clientes se conectam a um servidor DirectAccess executando o Windows Server 2008 R2. Uma implantação do DirectAccess pode incluir um ou mais servidores DirectAccess. (Recomendamos pelo menos dois servidores, para ajudar no balanceamento da carga em redes com muito tráfego.) A implantação também deve incluir um servidor de local de rede (para determinar se o cliente está conectado à Internet ou intranet) e um ou mais pontos de distribuição de CRL (lista de certificados revogados), usados para controlar os clientes que não devem ter mais permissão de acesso. Para saber como projetar uma implantação do DirectAccess, consulte o Guia de Design do DirectAccess no TechNet.

Ao adicionar a NAP sobre o DirectAccess, você deve implementar o método de imposição IPsec para NAP. Quando usam IPsec, os clientes compatíveis com NAP recebem certificados de integridade. Se um computador não é compatível, ele não tem permissão para se comunicar com computadores compatíveis. Para saber como projetar e implantar a NAP, consulte Planejando o DirectAccess com Proteção de Acesso a Rede no TechNet. Para saber como projetar o NAP com IPsec como método de imposição, consulte Design de imposição IPsec no TechNet.

É interessante considerar como o cenário de imposição IPsec na NAP funciona no contexto do DirectAccess e de suas diretivas de conexão IPsec. Primeiro, porque o DirectAccess usa IPsec para autenticação e confidencialidade, e o cenário de imposição de NAP em uma implantação do DirectAccess deve ser IPsec. Segundo, lembre-se de que o componente AuthIP do IPsec permite que você configure dois requisitos de autenticação separados na diretiva, de forma tal que a conexão deve cumprir ambos os requisitos para obter êxito. Em geral, se ambas as opções de autenticação AuthIP estão configuradas, a primeira é a credencial do computador e a segunda é a credencial do usuário. Entretanto, é tecnicamente possível configurar duas credenciais do computador.

Onde o NAP se encaixa nas políticas do AuthIP? O cenário de imposição de NAP/IPsec fornece aos computadores íntegros um certificado com o OID (identificador do objeto) de integridade. O mecanismo da diretiva do AuthIP inclui uma opção para exigir esse OID de integridade. Assim, apenas computadores íntegros poderão cumprir o primeiro requisito de autenticação do AuthIP e estabelecer uma conexão IPsec com o servidor DirectAccess.

Por fim, a credencial do usuário é a finalidade da segunda opção de autenticação do AuthIP. Tecnicamente, a credencial do usuário é opcional para o DirectAccess. Ou seja, os clientes podem se autenticar no ponto de extremidade do DirectAccess usando apenas um certificado do computador. O pessoal de TI que se preocupa com a segurança deve ficar nervoso só de pensar em dar acesso remoto total à rede sem uma autenticação forte. No mínimo, portanto, a diretiva do AuthIP deve ser configurada para exigir uma segunda autenticação do Kerberos. Exigir um certificado para a credencial do usuário, como no caso do cenário do Banco Nacional de Woodgrove, é preferível porque reduz o risco de ataques remotos a senhas estáticas.

Nesse cenário, os departamentos de conformidade e de segurança de rede do Banco Nacional de Woodgrove solicitaram um relatório mostrando quem se conectou à rede corporativa no decorrer de um período específico e se esses clientes eram ou não compatíveis com NAP. Esses grupos acreditam que pode ter havido um comprometimento dos dados dos clientes nesse período. Como consultores para o banco, precisamos determinar como habilitar relatórios posteriores para o DirectAccess e a NAP, e então extrair essas informações em um relatório legível.

Configuração apropriada da diretiva

Nesse cenário hipotético, o Banco Nacional de Woodgrove configurou o DirectAccess de forma que a diretiva IPsec exija certificados de cliente que incluam o OID de integridade do sistema da NAP e o OID de autenticação do cliente. O Woodgrove está usando a NAP em modo de imposição (em vez de apenas no modo de relatório), o que significa que os clientes não íntegros serão impedidos de se comunicarem com clientes íntegros.

Por fim, o Woodgrove configurou a diretiva IPsec do DirectAccess para usar duas credenciais baseadas em certificado: uma do computador cliente e uma do usuário. Como havia sido sugerido anteriormente, o Woodgrove escolheu a configuração de duplo certificado para aproveitar melhor seu investimento em PKI, eliminar senhas estáticas para acesso remoto e se beneficiar do registro automático do certificado.

O resto desta história pressupõe que você tenha conhecimento de trabalho de como o DirectAccess, a NAP e o modo de imposição IPsec funcionam. Consulte os seguintes recursos para saber mais sobre essas tecnologias:

• Visão geral executiva do DirectAccess
• Introdução à Proteção de Acesso à Rede
• Noções básicas sobre imposição IPsec para NAP

A solução de relatórios a seguir se beneficia dos recursos internos de auditoria do IPsec no servidor DirectAccess, bem como da capacidade de auditoria do recurso de Autoridade de Registro de Integridade (HRA) do Servidor de Diretivas de Rede (NPS). Esses recursos de auditoria produzem eventos nos logs de eventos do sistema e de segurança, que extraímos e relatamos. No desenvolvimento desta abordagem, constatamos que os eventos HRA são produzidos por padrão, enquanto os eventos IPsec talvez tenham de ser explicitamente habilitados. Os seguintes comandos podem ser usados em uma janela de prompt de comando para habilitar eventos IPsec:

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

Relatórios de integridade do DirectAccess

Para começar a trabalhar com eventos da NAP e DirectAccess do Banco Nacional de Woodgrove, baixamos e instalamos o Log Parser 2.2 da Microsoft. O Log Parser é uma ferramenta indispensável para um projeto como este, em que é necessário explorar uma nova fonte de eventos e desenvolver um esquema apropriado. Em resumo, o Log Parser pode importar de e exportar para diversos formatos de dados, inclusive o log de eventos do Windows (.evtx), CSV d SQL.

O próximo passo é capturar os eventos de interesse, como por exemplo:

• Eventos relacionados à Associação de Segurança do IPsec no log de segurança dos servidores DirectAccess
• Eventos relacionados à Autoridade de Registro de Integridade nos logs de segurança e sistema do(s) servidor(es) HRA (este item se aplica apenas se você está usando NAP)

Uma solução ideal para reunir esses eventos deve ser automatizada e centralizada. O recurso de encaminhamento de eventos do Windows é uma opção. O Microsoft System Center seria mais tipicamente usado em uma grande implantação de produção. No nosso caso, não queríamos introduzir novas dependências para os servidores de produção, então usamos scripts simples para reunir os eventos.

Em função dessa abordagem, o desafio é duplo. Primeiro, porque o objetivo é correlacionar várias fontes de dados; então, é importante que os dados de todas as fontes sejam reunidos mais ou menos ao mesmo tempo. Segundo, porque só estamos obtendo um instantâneo dos logs, e logs de eventos de alto tráfego passam rapidamente, então é inevitável que alguns eventos correlacionados faltem, especialmente no início e no fim do período do instantâneo. Isso não invalida a experiência, mas torna mais difícil ajustar as consultas.

Para cada associação de segurança de modo principal do IPsec (em um dos servidores DirectAccess), esperamos ver tráfego de integridade da NAP (em um dos servidores HRA). No modo de relatório da NAP, o computador cliente pode ter sido compatível ou não. No modo de imposição da NAP, a máquina cliente deveria ter sido compatível. Caso contrário, como ela tem um certificado válido para autenticar no servidor DirectAccess e estabelecer uma associação de segurança (SA)? Suponha que façamos uma captura de log única em todos os servidores DirectAccess e HRA simultaneamente às 15:00. Possivelmente veríamos o evento de associação de segurança de modo principal (MM SA), mas não o evento de integridade.

Talvez mais provavelmente ainda veríamos eventos de associação de segurança de modo rápido (QM SA) e de modo estendido (EM SA) do IPsec, mas não eventos de MM SA ou integridade. O primeiro pode ocorrer uma hora ou mais após o segundo. Além disso, como os logs em servidores separados quase certamente ocorrem em frequências diferentes, podemos ter eventos de 14:00 no servidor DirectAccess, mas eventos somente a partir de 14:30 no HRA. Por esses motivos, gostaríamos de reforçar a importância de usar coleta de eventos centralizada em produção.

Gerando os dados

Para gerar os dados, executamos scripts nos servidores DirectAccess e HRA. Também configuramos os scripts para execução automática com o Agendador de Tarefas. Configuramos o script para execução no servidor DirectAccess e em todos os HRAs uma única vez, simultaneamente.

Coletando dados nos servidores DirectAccess

Usamos o seguinte script para capturar eventos no servidor DirectAccess (consulte a 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

Observação: este script usa uma cópia local do LogParser.exe (e do LogParser.dll, sua dependência). Esta referência foi usada para conveniência, a fim de que pudéssemos copiar facilmente o script de um servidor para outro.

Figura 1 Detalhes dos eventos capturados do servidor DirectAccess usando um script executado automaticamente com o Agendador de Tarefas.

Coletando dados nos servidores HRA

Para capturar eventos nos servidores HRA, usamos o seguinte script:

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

Observação: no script HRA, a categoria de evento 12552 mapeia para o serviço do Servidor de Diretiva de Rede.

Importando os dados

Após a execução dos scripts, reunimos os arquivos CSV de saída em um computador separado executando o SQL Server 2008. Usamos o seguinte script para importar os dados de CSV para 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

Observações:

• O nome do computador host SQL é dev1. O banco de dados chama-se NapDa e foi criado usando os valores padrão no SQL Management Studio.
• As três tabelas, DaSasTable, HraSecurityEventsTable e HraSystemEventsTable, não existiam. A opção de linha de comando -createTable:ONLog Parser especifica a criação automática dessas tabelas pelo Log Parser com um esquema adequado baseado nos dados de entrada (os arquivos CSV do log de eventos, neste caso).
• A configuração -maxStrFieldLen:1023 é importante neste cenário. Sem ela, um comprimento padrão de 255 para o campo varchar seria usado pelo Log Parser para os vários campos de cadeias de caracteres do log de eventos. Entretanto, o formato CSV do log de eventos tem algumas cadeias de dados que são maiores do que isso (particularmente no campo Cadeias de Caracteres; consulte a Figura 2) e é importante que não fiquem truncadas. Experimentalmente, um comprimento padrão de 1023 parece adequado.

A Figura 2 mostra o esquema resultante da importação do log de eventos em CSV do Log Parser.

Figura 2 Esquema da importação do log de eventos em CSV do Log Parser.

Preparando os dados

Na criação do relatório de integridade do DirectAccess, o principal desafio em termos de extração dos dados necessários está no fato de que o formato CSV do log de eventos é baseado em cadeias de dados. No contexto de uma interface gráfica do usuário, os dados são intercalados em cadeias de caracteres estáticas que descrevem o significado de cada campo de dados. As cadeias de dados incluem tudo o que interessa para um relatório de integridade do DirectAccess, incluindo nomes de usuários, nomes de computadores, nomes de grupos de diretivas e endereços IP.

As cadeias de dados são concatenadas em um único campo CSV e depois em uma única coluna SQL (novamente, cadeias de caracteres). Cada cadeia de caracteres é separada da seguinte por um caractere “|”. Uma opção seria criar tokens das cadeias de caracteres, antes ou imediatamente após importar os dados para SQL. Entretanto, nossa preferência foi analisar as cadeias de caracteres depois que elas estavam em SQL, extrair os poucos itens de dados específicos de que precisávamos e preencher tabelas SQL separadas com esses itens.

Realizar essa tarefa com o padrão das cadeias de caracteres correspondendo ao T-SQL é difícil. Como alternativa, usamos uma abordagem documentada em um artigo anterior da MSDN Magazine, “Expressões regulares facilitam a correspondência de padrões e a extração de dados — implementando funções definidas pelo usuário para SQL usando C#, especificamente para a finalidade de correspondência de padrões baseada em expressões regulares.

Usando o Visual Studio 2008, seguimos as etapas desse artigo quase exatamente, embora tenha sido útil consultar documentação adicional sobre como fazer a integração inicial de SQL e CLR funcionar com o Visual Studio. Além disso, devido à complexidade inerente das expressões regulares (RegEx), também foi útil consultar a documentação dessa tecnologia, particularmente a seção sobre agrupamento, já que essa é a abordagem usada pelo código de exemplo do artigo da MSDN Magazine.

O exemplo de código a seguir detalha o código-fonte para a função SQL definida pelo usuário que expõe os recursos do RegEx em nossas instruções SELECT. A função chama-se RegexGroup, assim como a do artigo da MSDN Magazine. Fizemos uma modificação nas duas primeiras linhas do corpo da função, para podermos verificar se há valores de entrada NULL. Antes de adicionarmos essas duas linhas, encontramos numerosas exceções, pois diversas das nossas colunas da tabela auxiliar do SQL (descritas aqui) têm valores 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;

}

};

Os comandos SQL a seguir criam e preenchem duas tabelas auxiliares compostas por cadeias de caracteres extraídas do conjunto de dados inicial usando 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]

Você pode ter uma noção dos padrões das cadeias de caracteres examinando a primeira instrução SELECT e seu uso da função RegexGroup instalada com a técnica que descrevemos. A Figura 3 detalha os três padrões de RegEx que definimos.

Figura 3 Os três padrões de RegEx definidos usando comandos SQL.

Juntas, essas expressões regulares ajudam a criar uma tabela, que consiste em informações do Usuário, Computador e Endereço de cada linha na DaSasTable (ou seja, os eventos SA do IPsec exportados do computador com DirectAccess).

Depois que a tabela UserComputerAndAddr table é criada e preenchida, uma segunda tabela é criada, mapeando o nome do computador para o tipo de evento para cada linha da tabela HraSystemEventsTable. Se você examinar o padrão do nome do computador, verá que o formato do nome do computador é diferente neste log em relação ao log do DirectAccess. Nesse caso, estamos procurando cadeias de caracteres como REDMOND\dan-dev-1. A Figura 4 detalha os diferentes eventos que podem estar presentes no campo EventType.

Figura 4 Tipos de evento que podem estar presentes no campo EventType.

No relatório de integridade desta implantação, esperamos apenas ver o tipo de evento 0. Isso se deve ao fato de a NAP estar sendo usada no modo de imposição. Como você verá abaixo, também estamos filtrando as associações de segurança IPsec bem-sucedidas. Se o cliente não era compatível, ele não deve ter conseguido adquirir um certificado IPsec válido e estabelecer uma SA. Por outro lado, se sua organização implantou a NAP em modo de relatório, você deverá ver alguns computadores não compatíveis conectados. A porcentagem relativa de computadores compatíveis e não compatíveis conectados à rede é uma estatística importante a ser relatada.

Observação: ao usar tabelas para resultados de RegEx, recomendamos que você use tabelas SQL permanentes. Se você usar tabelas temporárias (como fazemos para a demonstração na etapa seguinte), as consultas de RegEx ficarão lentas.

Criando o relatório

Com a análise das expressões regulares concluída e as tabelas auxiliares criadas, agora podemos nos concentrar na criação do relatório de integridade em si. Depois que os dados foram preparados, escrever as consultas do relatório é relativamente fácil.

A finalidade deste relatório de exemplo é listar todos os usuários que estabeleceram uma conexão DirectAccess entre 15:00 e 16:00 no dia 5 de maio de 2010. Junto com o nome do usuário, o relatório lista o nome do computador e o status da integridade.

Para identificar esses usuários, começaremos consultando QM SAs (categoria de evento 12549) bem-sucedidos (tipo de evento 8) nesse período. O evento QM SA é útil nesse cenário, porque o IPsec foi configurado para exigir autenticação de segundo fator (as credenciais do usuário). Optamos por usar essa abordagem de relatório porque os QM SAs têm vida relativamente curta (uma hora, neste caso, com tempo limite de inatividade de cinco minutos) e, portanto, são úteis para acesso de auditoria. Um MM SA, em contrapartida, apenas implica o uso da credencial do computador e persiste por oito horas por padrão (embora seja recomendável diminuir o tempo de vida do MM se a auditoria for um componente importante da sua implantação do DirectAccess).

Infelizmente, os eventos QM não incluem o nome do usuário nem do computador, apenas o endereço IP. Para mapear o endereço IP para um nome de computador e nome de usuário, podemos usar algumas instruções SELECT em nossa consulta SQL. A primeira instrução SELECT na consulta a seguir retornará a lista de endereços que aparecem em novos QM SAs dentro desse período. A segunda instrução SELECT usa esses endereços para mapear para o nome do usuário e o nome do computador associados a esse endereço em outro ponto do log. (Essa associação usuário/computador/endereço está nos eventos EM SA. Esses eventos são cruciais para este exercício, pois contêm os três valores; se você não exigir a segunda autenticação do IPsec, não poderá fazer esse tipo de relatório.)

/* 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

A etapa final no preenchimento da tabela de relatório SaHealthReport é correlacionar as informações de integridade HRA com as informações de identidade do computador e do usuário, que até agora vieram exclusivamente do servidor DirectAccess. A incorporação das informações do servidor HRA a esta combinação é uma poderosa ferramenta que permite determinar se os computadores que se conectam remotamente à sua rede estão introduzindo algum risco (devido à não conformidade). Consulte a instrução UPDATE na consulta SQL anterior — a correlação entre os dados do DirectAccess e do HRA é realizada usando o nome do computador cliente.

A Figura 5 mostra dados de exemplo que poderiam ser retornados de um relatório de integridade concluído.

Figura 5 Exemplo de relatório de integridade concluído

Você pode estabelecer relatórios sobre a implantação de IPsec (incluindo DirectAccess) e NAP com relativa facilidade usando alguns scripts personalizados e a ferramenta LogParser. Essa abordagem ajudará a empresa a começar a criar uma estrutura segura para expor serviços de linha de negócios, seja no local ou na nuvem.

Dan Griffin é consultor de segurança de software em Seattle. Entre em contato com ele através do site www.jwsecure.com

Lee Walker é o arquiteto de tecnologia do departamento de TI interno da Microsoft, com foco em IPv6, IPsec, NAP, DirectAccess e outras tecnologias. Entre em contato com ele através do email lee.walker@microsoft.com.

Conteúdo relacionado

• Cable Guy: DirectAccess e a rede de borda
• Security Watch: Considerações sobre identidade, Parte 1
• Security Watch: Considerações sobre identidade, Parte 2