Informes de cumplimiento: primer paso en el control de acceso de nube de cliente

Mejore sus informes de auditoría y cumplimiento con NAP e Ipsec para controlar el acceso de cliente a través de DirectAccess.

Dan Griffin y Lee Walker

Establecer un acceso seguro es un primer paso lógico para extender la empresa a la nube. Al establecer directivas de cumplimiento, informes y conectividad remota ahora, prepara el terreno para cómo trabajará su equipo dentro de la nube de manera dinámica y segura. Usar Protección de acceso a redes (NAP) con tecnologías de conectividad IPsec como DirectAccess puede ayudar, ya que mejora sus informes de auditoría y cumplimiento.

Puede resultar difícil identificar y reunir los datos necesarios al crear una solución de auditoría e informes para una implementación nueva de DirectAccess o IPsec. Aquí le mostraremos cómo una empresa hipotética podría crear una solución de DirectAccess y NAP, y proporcionar datos de informes para determinar quién se conectó, cuándo lo hizo y si el equipo cliente estaba en cumplimiento.

El problema del cumplimiento

Conforme los recursos se vuelven cada vez más móviles, más organizaciones están adoptando las tecnologías flexibles de acceso remoto como DirectAccess. Con DirectAccess, siempre que una máquina autorizada se conecta a Internet, el usuario se conecta automáticamente a la red remota. Como los clientes remotos a veces pueden no estar al día con los parches de seguridad y posiblemente tener un malware, muchas organizaciones también implementan NAP con IPsec para garantizar que sólo los clientes en buen estado tengan acceso a recursos seguros.

En industrias como los servicios financieros, atención de salud y gobierno, la importancia de comprobar que sólo clientes en buen estado y que cuentan con aprobación se conecten a recursos de red basados en nube o in situ es esencial para la integridad de los datos. A menudo directivas de cumplimiento internas y la ley federal exigen a estas industrias que confirmen que no ha habido acceso a información de identificación personal (PII), como números de cuentas bancarias, nombres y registros de salud, por parte de ninguna parte sin autorización (incluidos malware y aplicaciones desconocidas de terceros).

A medida que los usuarios buscan un acceso remoto más fácil a sus recursos de red, los administradores de TI de estas industrias seguras también deben garantizar que sólo clientes en buen estado tengan acceso a la red corporativa. Lamentablemente, existen desafíos para crear informes significativos desde registros de NAP y DirectAccess.

Configurar una infraestructura de DirectAccess para un acceso de cliente remoto sin problemas, asegurar los recursos de intranet con NAP e IPsec y supervisar la directiva a través de informes es la solución. TechNet incluye cierta información de ayuda acerca de cómo implementar NAP con DirectAccess, pero hay poca orientación acerca de cómo registrar e informar de manera eficaz respecto del estado del cliente. Examinaremos una empresa hipotética (Banco Nacional de Woodgrove) y mostraremos cómo un consultor podría usar cierto código sencillo y consultas de SQL para crear informes legibles en que se detallen los clientes que se conectaron durante un período específico de tiempo y si cumplían con NAP.

Configuración de NAP sobre DirectAccess

DirectAccess requiere que los clientes en conexión ejecuten una versión compatible de Windows (Windows 7 Ultimate o Windows 7 Enterprise). Estos clientes se conectan a un servidor de DirectAccess con Windows Server 2008 R2. Una implementación de DirectAccess puede incluir uno o más servidores de DirectAccess. (Recomendamos al menos dos servidores para ayudar a equilibrar las cargas en redes ocupadas.) La implementación también debe incluir un servidor de ubicación de red (para determinar si el cliente está conectado a Internet o intranet) y uno o más puntos de distribución de lista de revocación de certificados (CRL) (usados para hacer un seguimiento de los clientes a quienes ya no se debe permitir el acceso). Para aprender a diseñar una implementación de DirectAccess, consulte la Guía de diseño de DirectAccess en TechNet.

Al agregar NAP sobre DirectAccess, debe implementar el método de cumplimiento de IPsec para NAP. Al usar IPsec, a los clientes que cumplen con NAP se les otorgan certificados de estado. Si un equipo no está en cumplimiento, no se le permite comunicarse con equipos que sí lo están. Para obtener información sobre cómo diseñar e implementar NAP, consulte Planeación de DirectAccess con Protección de acceso a redes en TechNet. Para obtener información sobre cómo diseñar NAP con IPsec como método de cumplimiento, consulte Diseño de cumplimiento de IPsec en TechNet.

Es interesante considerar cómo funciona el escenario de cumplimiento de IPsec de NAP dentro del contexto de DirectAccess y sus directivas de conexión de IPsec. Primero, como DirectAccess usa IPsec para autenticación y confidencialidad, el escenario de cumplimiento de NAP en una implementación de DirectAccess debe ser IPsec. Segundo, no olvide que el componente AuthIP de IPsec le permite configurar dos requisitos de autenticación por separado en la directiva, de manera que la conexión debe cumplir con ambos para estar correcta. Normalmente, si se configuran ambas opciones de autenticación de AuthIP, la primera es la credencial de la máquina y la segunda es la credencial del usuario. Sin embargo, es técnicamente posible configurar dos credenciales de máquina.

¿Qué papel juega NAP en las directivas de AuthIP? El escenario de cumplimiento de NAP/IPsec otorga a las máquinas en buen estado un certificado con el identificador de objeto (OID) de estado. El motor de directivas de AuthIP incluye una opción para exigir ese OID de estado. De esta manera, sólo las máquinas en buen estado podrán cumplir el primer requisito de autenticación de AuthIP y establecer una conexión IPsec con el servidor de DirectAccess.

Por último, la credencial de usuario es el propósito de la segunda opción de autenticación de AuthIP. Desde el punto de vista técnico, la credencial de usuario es opcional para DirectAccess. En otras palabras, los clientes podrían autenticarse ante el extremo de DirectAccess mediante un simple certificado de máquina. El personal de TI a cargo de la seguridad debe estar nervioso respecto de otorgar total acceso remoto a redes sin una autenticación sólida. Como mínimo, por tanto, la directiva de AuthIP debe configurarse para que exija una segunda autenticación de Kerberos. Exigir un certificado para la credencial de usuario, como en el escenario del Banco Nacional de Woodgrove, es preferible porque reduce el riesgo de ataques remotos de contraseña estática.

En este escenario, los departamentos de seguridad de redes y cumplimiento del Banco Nacional de Woodgrove solicitaron un informe que muestre qué clientes se conectaron a la red corporativa en un período específico de tiempo y si cumplían con NAP. Estos grupos creen que los datos de clientes pueden haber resultado comprometidos durante ese tiempo. Como consultores del banco, debemos determinar cómo habilitar informes posteriores al hecho para DirectAccess y NAP, y luego colocar esa información en un informe legible.

Configuración adecuada de directiva

En este escenario hipotético, el Banco Nacional de Woodgrove configuró DirectAccess de manera que la directiva de IPsec exige certificados de cliente que incluyan el OID de estado del sistema NAP y el OID de la autenticación de cliente. Woodgrove está usando NAP en modo de cumplimiento (en lugar de tan sólo modo de informes), lo cual significa que aquellos clientes que no estén en buen estado quedarán incomunicados con los clientes que sí lo están.

Por último, Woodgrove ha configurado la directiva de IPsec de DirectAccess para usar dos credenciales basadas en certificados: una del equipo cliente y una del usuario. Tal como se sugirió anteriormente, Woodgrove optó por la configuración de doble certificado a fin de utilizar mejor su inversión en PKI, para eliminar contraseñas estáticas para acceso remoto y aprovechar la inscripción automática de certificados.

Lo que resta de esta historia supone que usted posee un conocimiento acabado de cómo funciona el modo de cumplimiento de DirectAccess, NAP e IPsec. Consulte los siguientes recursos para obtener más información acerca de estas tecnologías:

• Información general ejecutiva de DirectAccess
• Introducción a Protección de acceso a redes
• Descripción del cumplimiento de IPsec de NAP

La siguiente solución de informes aprovecha las características de auditoría integradas de IPsec en el servidor de DirectAccess, así como las capacidades de auditoría de la característica Autoridad de registro de mantenimiento (HRA) del Servidor de directivas de redes (NPS). Estas características de auditoría producen eventos en los registros de sistema y de eventos de seguridad, los cuales extraemos e informamos. Al desarrollar este enfoque, descubrimos que los eventos de HRA se producen de manera predeterminada, mientras que los eventos de IPsec tendrían que habilitarse de manera explícita. Puede usar los siguientes comandos en una ventana de símbolo del sistema para habilitar los 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

Informes de estado de DirectAccess

Para comenzar a trabajar con los eventos de NAP y DirectAccess del Banco Nacional de Woodgrove, descargamos e instalamos Log Parser 2.2 de Microsoft. Log Parser es una herramienta indispensable para un proyecto como éste, en que debe explorar un nuevo origen de eventos y desarrollar un esquema apropiado. En resumen, Log Parser puede importar a varios formatos de datos y exportar desde allí, incluido el registro de eventos de Windows (.evtx), CSV y SQL.

El paso siguiente es capturar los eventos que son de interés. Por ejemplo:

• Eventos relacionados con la Asociación de seguridad de IPsec en el registro de seguridad de los servidores de DirectAccess
• Eventos relacionados con la Autoridad de registro de mantenimiento en los registros de seguridad y sistema del servidor (o servidores) de HRA (este elemento sólo aplica si está usando NAP)

Una solución ideal para reunir esos eventos es de manera automatizada y centralizada. La característica de reenvío de eventos de Windows es una opción. Ahora, en una implementación de producción de gran envergadura sería más normal usar Microsoft System Center. En nuestro caso, no deseábamos introducir nuevas dependencias a los servidores de producción, así que usamos scripts sencillos para reunir los eventos.

Dado ese enfoque, el desafío es doble. Primero, como el objetivo es correlacionar varios orígenes de datos, es importante que los datos de todos los orígenes se reúnan aproximadamente al mismo tiempo. Segundo, como sólo estamos tomando una instantánea de los registros y los registros de eventos de alto tráfico pasan rápidamente, es inevitable que falten algunos eventos de correlación, sobre todo al filo de la instantánea. Esto no invalida el experimento, pero sí hace más difícil sintonizar las consultas.

Por cada asociación de seguridad de modo principal de IPsec (en uno de los servidores de DirectAccess), esperamos ver el tráfico del estado de NAP (en uno de los servidores de HRA). En el modo de generación de informes de NAP, la máquina cliente puede haber estado en cumplimiento o no. En el modo de cumplimiento de NAP, la máquina cliente debe haber estado en cumplimiento. De lo contrario, ¿cómo es que tiene un certificado válido para autenticación en el servidor de DirectAccess y establecimiento de una asociación de seguridad (SA)? Supongamos que hacemos una captura de registros de una vez en todos los servidores de DirectAccess y HRA al mismo tiempo a las 3 p.m. Es posible que veamos el evento de la asociación de seguridad de modo principal (MM SA), pero no el evento de estado.

Incluso más probable es que veamos los eventos de asociación de seguridad de modo rápido de IPsec (QM SA) y de asociación de seguridad de modo extendido de IPsec (EM SA), pero no los eventos de MM SA o de estado. Lo primero puede ocurrir hasta una hora o más después de lo último. Además, como los registros en servidores aparte casi con seguridad pasan a diferentes frecuencias, es posible que tengamos eventos de las 2 p.m. en el servidor de DirectAccess, pero eventos no antes de las 2:30 p.m. en el HRA. Por estos motivos, deseamos reiterar que es importante reunir los eventos de manera centralizada en la producción.

Generación de los datos

Para generar los datos, ejecutamos scripts en los servidores de DirectAccess y los servidores de HRA. También configuramos los scripts para que se ejecutaran de manera automática con el Programador de tareas. Configuramos el script para que se ejecutara en el servidor de DirectAccess y todos los HRA una vez, al mismo tiempo.

Recopilación de datos en servidores de DirectAccess

Usamos el siguiente script para capturar eventos en el servidor de DirectAccess (consulte 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: este script usa una copia local de LogParser.exe (y LogParser.dll, su dependencia). Esta referencia se usó por conveniencia de manera que pudiéramos copiar fácilmente el script de servidor a servidor.

Figura 1 Detalles de los eventos capturados desde el servidor de DirectAccess mediante un script que se ejecutó de manera automática con el Programador de tareas.

Recopilación de datos en los servidores HRA

Para capturar eventos en los servidores HRA, usamos el siguiente 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

Nota: en el script de HRA, la categoría de evento 12552 se asigna al servicio del Servidor de directivas de redes.

Importación de datos

Después de ejecutar los scripts, reunimos los archivos CSV de salida en una máquina aparte con SQL Server 2008. Usamos el siguiente script para importar los datos CSV en 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

Notas:

• El nombre de la máquina host SQL es dev1. La base de datos se llama NapDa y se creó con los valores predeterminados de SQL Management Studio.
• Las tres tablas, DaSasTable, HraSecurityEventsTable y HraSystemEventsTable no existían todavía. La opción de línea de comandos de Parser -createTable:ONLog especifica que Log Parser cree de manera automática esas tablas con un esquema adecuado basado en los datos de entrada (los archivos CSV del registro de eventos, en este caso).
• La configuración -maxStrFieldLen:1023setting es importante en este escenario. Sin ella, Log Parser usaría una longitud de campo varchar predeterminada para los diversos campos de cadenas de registros de eventos. Sin embargo, el formato CSV del registro de eventos tiene algunas cadenas de datos más largas que eso (sobre todo en el campo Strings, consulte Figura 2) y es importante que no se resulten truncadas. De manera experimental, una longitud predeterminada de 1023 parece adecuada.

En la Figura 2 se muestra el esquema que resultó de la importación del registro de eventos CSV de Log Parser.

Figura 2 Esquema para la importación del registro de eventos CSV de Log Parser.

Preparación de los datos

Al crear el informe de mantenimiento de DirectAccess, el desafío principal en términos de extracción de los datos requeridos es que el formato CSV del registro de eventos se base en cadenas de datos. En el contexto de una GUI, los datos se intercalan en cadenas estáticas que describen el significado de cada campo de datos. Las cadenas de datos incluyen todo lo que es interesante para un informe de mantenimiento de DirectAccess, incluidos nombres de usuario, nombres de máquinas, nombres de grupos de directivas y direcciones IP.

Las cadenas de datos se concatenan en un campo CSV único y finalmente en una columna SQL única (nuevamente, cadenas). Cada cadena se separa de la siguiente mediante un carácter “|”. Una opción sería otorgar un token a las cadenas, antes o inmediatamente después de importar los datos a SQL. Sin embargo, nuestra preferencia fue, en su lugar, analizar las cadenas después de que están en SQL, para luego extraer los pocos elementos de datos específicos que necesitábamos para poblar las tablas SQL aparte con esos elementos.

Lograr esta tarea con un patrón de cadenas que coincidan con T-SQL es difícil. Como una alternativa, usamos un enfoque documentado en un artículo anterior de MSDN Magazine, “Las expresiones regulares facilitan las coincidencias con patrones y la extracción de datos: implementación de funciones definidas por usuario para SQL con C#, en especial para el propósito de coincidencia regular de patrones basados en expresiones.

Con Visual Studio 2008, seguimos los pasos indicados en ese artículo casi al pie de la letra, aunque fue útil consultar documentación adicional sobre cómo obtener SQL inicial e integración de CLR que trabajan con Visual Studio. También, debido a la complejidad inherente de expresiones regulares (RegEx), asimismo fue útil consultar la documentación para esa tecnología, en particular la sección sobre agrupación, ya que ése es el enfoque usado por el código de ejemplo del artículo de MSDN Magazine.

El siguiente ejemplo de código detalla el código fuente para la función de SQL definida por el usuario que expone las capacidades RegEx en nuestras instrucciones SELECT. La función se denomina RegexGroup, tal como la del artículo de MSDN Magazine. Hicimos una modificación en las primeras dos líneas del cuerpo de la función para poder revisar si hay valores de entrada NULL. Antes de agregar estas dos líneas, encontramos numerosas excepciones porque varias de nuestras columnas de tablas SQL auxiliares (descritas aquí) tienen 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;

}

};

Los siguientes comandos SQL crean y pueblan dos tablas auxiliares que constan de cadenas extraídas del conjunto de datos iniciales que usan 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]

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

El último paso al poblar la tabla de informes SaHealthReport es correlacionar la información de mantenimiento de HRA con la información de identidad del equipo y el usuario, lo cual hasta ahora ha provenido en exclusiva del servidor de DirectAccess. La incorporación de la información del servidor de HRA a esta mezcla es una herramienta eficaz que le permite determinar si los equipos conectados de manera remota a su red representan riesgo (por no encontrarse en cumplimiento). Consulte la instrucción UPDATE de la consulta de SQL anterior (la correlación entre los datos de DirectAccess y HRA se logra al usar el nombre del equipo de cliente).

En la Figura 5 se muestran datos de ejemplo que podrían devolverse de un informe de mantenimiento finalizado.

Figura 5 Informe de mantenimiento de ejemplo finalizado

Puede establecer informes sobre implementación de IPsec (incluido DirectAccess) y NAP de manera relativamente fácil con algunos scripts personalizados y la herramienta LogParser. Este enfoque ayudará a que una empresa comience a crear un marco seguro para exponer servicios de línea de negocio, ya sea in situ o en la nube.

Contenido relacionado

• Cable Guy: DirectAccess y la red perimetral fina
• Inspección de seguridad: reflexiones sobre la identidad, parte 1
• Inspección de seguridad: reflexiones sobre la identidad, parte 2