Aislamiento de servidor y dominio mediante IPsec y Directiva de grupo

Capítulo 3: Cómo determinar el estado actual de su infraestructura de TI

Actualizado: febrero 16, 2005

Este capítulo proporciona información sobre cómo obtener la información necesaria para planificar e implementar una solución de aislamiento de servidor y dominio. Una implementación satisfactoria requiere una imagen precisa y actual de la infraestructura de TI. Tras leer este capítulo, sabrá qué información se necesita para completar el diseño de una solución de aislamiento de servidor y dominio.

La parte final de este capítulo discute el proceso de comprender y documentar qué equipos identificados pueden actuar como equipos "de confianza" en la solución. El equipo de diseño necesitará esta información para la planificación de la solución.

En esta página

	Requisitos previos
	Destinatarios del capítulo
	Identificación del estado actual
	Consideraciones de capacidad
	Cuestiones previas a la implementación
	Determinación de confianza
	Obtención de los costes de actualización de los hosts actuales
	Resumen

Requisitos previos

Antes de utilizar la información de este capítulo, compruebe que usted y su organización cumplen los requisitos previos siguientes. La información de este capítulo está pensada para satisfacer las necesidades de una organización alineada con estos requisitos previos. No cumplir todos los requisitos previos no tendrá necesariamente un impacto negativo sobre su proyecto, pero si los cumple maximizará el valor de esta guía.

Requisitos previos de conocimientos

Debe estar familiarizado con los conceptos de IPsec y debe tener una comprensión sólida de:

•	La autenticación de Microsoft® Windows® (específicamente el protocolo de autenticación Kerberos versión 5)
•	Los conceptos de servicio de directorios de Active Directory® (incluidas la estructura y las herramientas de Active Directory; manipulación de usuarios, grupos y otros objetos de Active Directory; y el uso de Directiva de grupo).
•	La seguridad del sistema Windows, incluidos conceptos de seguridad como usuarios, grupos, auditoría y listas de control de acceso (ACL)
•	Las convenciones de nomenclatura del sistema de su organización
•	Las ubicaciones físicas y lógicas de su organización
•	Las prácticas de administración de riesgos que se utilizan en la organización
•	Los principales conceptos de trabajo en red, incluido el filtrado de puertos mediante servidores de seguridad

Antes de seguir con este capítulo, debería leer los capítulos anteriores de esta guía y comprender los conceptos arquitectónicos y de diseño de la solución.

Requisitos previos organizativos

Planificar los grupos de aislamiento de una organización es una tarea que suele implicar a diversas personas. La información necesaria para determinar los requisitos exactos procederá con frecuencia de una serie de fuentes de la organización. Debe consultar a otras personas de su organización que podrían necesitar implicarse en la planificación de estos grupos, incluidas:

•	Patrocinadores ejecutivos
•	Personal de seguridad y auditoría
•	Personal de ingeniería, administración y operación de Active Directory
•	Propietarios de aplicaciones, DNS (Sistema de nombres de dominio) y servidor Web
•	Personal de administración y operación de la red
•	Personal interno de formación y del servicio de asistencia Nota: según la estructura de la organización de TI, estas funciones las pueden desempeñar varias personas distintas o unas pocas personas pueden abarcar varias funciones.

Además de solicitar información de los equipos indicados, es importante entender que la introducción de IPsec en el entorno comportará la actualización de las prácticas operativas actuales. También es posible que sea necesario actualizar el software y el hardware, como el BIOS y las actualizaciones de firmware para dispositivos de red. Finalmente, quizás sean necesarias herramientas de red adicionales para el soporte técnico y la solución de problemas relacionados con el entorno IPsec.

Requisitos previos de la infraestructura de TI

Este capítulo también asume que existe la siguiente infraestructura de TI:

•

Un dominio Active Directory de Microsoft Windows Server™ 2003 en modo mixto o modo nativo. Esta solución utiliza grupos universales para la aplicación de Objetos de directiva de grupo (GPO). Aunque la organización no utilice el modo mixto o el modo nativo, seguirá siendo posible aplicar los GPO utilizando configuraciones de grupo estándar globales y locales. Sin embargo, puesto que esta opción es más difícil de administrar, nuestra solución no la utiliza.

Nota: Windows Server 2003 introdujo diversas mejoras que afectan a las directivas IPsec. Esta solución también podría implementarse con Windows 2000. No obstante, la solución se ha probado únicamente con Windows Server 2003 Active Directory.
Para obtener más información acerca de las mejoras para IPsec que introduce Windows Server 2003, consulte la página New features for IPsec (Funciones nuevas para IPsec) del sitio Web de Microsoft, en www.microsoft.com/resources/documentation/
WindowsServ/2003/standard/
proddocs/en-us/ipsec_whatsnew.asp.

•

La capacidad y experiencia de llevar a cabo una supervisión de la red, analizar los datos de la supervisión y tomar decisiones de planificación de la capacidad basándose en dichos datos.

Nota: en muchas organizaciones, el uso de herramientas de supervisión de la red está restringido, por lo tanto es preciso asegurarse de que se siguen los procedimientos operativos correctos cuando se utilizan estas herramientas.

•

Existen herramientas que permiten capturar los datos de configuración de la red para los hosts de la red. Para recoger esta información, pueden utilizarse, por ejemplo, los sistemas de administración de activos existentes. Para obtener más información, consulte la sección "Detección de host" de este capítulo.

Principio de la página

Destinatarios del capítulo

Este capítulo está dirigido a los profesionales de TI encargados de crear el inventario de infraestructura de TI que utilizarán los diseñadores y arquitectos de la solución. Estos profesionales de TI normalmente serán miembros del personal de soporte técnico u operaciones de la organización. Para sacar el máximo provecho de este capítulo, es necesario un buen nivel de comprensión técnica, tanto de las herramientas y las tecnologías implicadas en el proceso de recopilación de información, como de la infraestructura actual de la organización.

Principio de la página

Identificación del estado actual

El proceso de obtener y mantener un registro fiable de los equipos, el software y los dispositivos de red de una organización es uno de los retos clásicos del departamento de TI El éxito de un proyecto dependerá de la información que se obtenga de dicho proceso. Antes de iniciar el proceso de planificación para un proyecto de aislamiento de servidor y dominio, es necesario recoger y analizar información actualizada sobre los equipos, la red y los servicios de directorio que ya se han implementado en la organización. Esta información le permitirá crear un diseño que tenga en cuenta todos los elementos posibles de la infraestructura existente. Si la información recogida no es precisa, pueden surgir problemas si durante la implementación aparecen dispositivos y equipos que no se tuvieron en cuenta durante la fase de planificación. La siguientes secciones resumen la información necesaria en cada área y proporcionan ejemplos de la información que se recogió para la solución de aislamiento de servidor y dominio de Woodgrove Bank.

Detección de redes

Quizás el aspecto más importante de la planificación del aislamiento de servidor y dominio sea la arquitectura de la red, pues IPsec se encuentra en una capa del propio protocolo de Internet. La solución de aislamiento no tendrá éxito si no existe una comprensión previa completa y adecuada de la red. El entendimiento del diseño de las subredes, los esquemas de direccionamiento IP y los patrones de tráfico forma parte de este esfuerzo, pero los dos componentes siguientes son vitales para completar la fase de planificación de este proyecto:

•	La documentación de la segmentación de la red
•	La documentación del modelo de tráfico de red actual

El objetivo es tener suficiente información para identificar un activo por su ubicación en la red, además de su ubicación física.

Es preferible empezar con una arquitectura de red bien planificada, con intervalos de direcciones fácilmente identificables y tan pocas superposiciones o intervalos discontinuos como sea posible. Podrían darse ciertas circunstancias (p.ej. fusiones y adquisiciones) o existir requisitos empresariales que no permitieran una red "simplificada", pero si el estado actual está documentado y se entiende, la tarea de identificar la red y los activos administrados será más sencilla. Como punto de partida para el diseño no debe utilizarse una red compleja y mal documentada, pues puede dejar demasiadas áreas sin identificar que podrían causar problemas durante la implementación.

Esta guía le ayudará a obtener la información más relevante para planificar el aislamiento de servidor y dominio pero no intenta abordar otros temas, como las máscaras de subred de longitud variable y la asignación de direcciones TCP/IP, la segmentación de la red de área local virtual (VLAN) u otros métodos y técnicas de optimización de la red. La información obtenida se utilizará para formular la implementación y los componentes operativos de la solución de aislamiento de servidor y dominio.

Documentación de la segmentación de la red

Si la organización no tiene documentada la arquitectura actual de la red, dicha información deberá obtenerse tan pronto como sea posible antes de seguir con la solución. Si la información documentada no es actual o no ha sido validada recientemente, tiene dos opciones básicas:

•	Aceptar que la información puede conllevar riesgos indebidos para el proyecto.
•	Emprender un proyecto de descubrimiento basado en procesos manuales o en una herramienta de análisis de la red que pueda proporcionarle la información necesaria para documentar la topología actual de la red.

Aunque la información requerida puede presentarse de formas distintas, el método más efectivo para ilustrar y entender la configuración actual de la red suele ser el uso de diagramas esquemáticos. Cuando cree diagramas de la red, evite incluir en estos diagramas demasiada información. Si es necesario, utilice múltiples diagramas que muestren niveles de detalle distintos.

Por ejemplo, en el escenario de Woodgrove Bank, el equipo creó el siguiente diagrama para ilustrar la vista general de la red de área amplia (WAN) y el entorno de sitio existentes:

Figura 3.1 Diagrama de WAN y red de sitio de Woodgrove Bank
Ver imagen a tamaño completo

Tras crear este diagrama, el equipo pasó a crear diagramas más detallados para cada sitio y finalmente para las subredes de cada sitio.

Cuando documente la red, quizás encuentre algunas aplicaciones y servicios de la red que no son compatibles con IPsec. Algunos ejemplos de dicha incompatibilidad incluyen:

•	Cisco NetFlow en enrutadores no puede analizar paquetes entre miembros IPsec basados en protocolo o puerto.
•	La calidad de servicio (QoS) basada en enrutador no puede utilizar puertos o protocolos para dar prioridad al tráfico. Sin embargo, ello no afectará a la utilización de direcciones IP específicas para dar prioridad al tráfico. Por ejemplo, una regla que especificara "Dar prioridad de cualquiera a cualquiera que utilice el puerto 80" no funcionaría, mientras que una regla que especificara "Dar prioridad de cualquiera a 10.0.1.10" no se vería afectada.
•	Dispositivos que no dan soporte o permiten el protocolo IP 50, el puerto utilizado por la carga de seguridad de encapsulación (ESP).
•	Los algoritmos WFQ (Weighted Fair Queuing) y otros métodos de prioridad de tráfico de enrutador basados en el flujo podrían dar errores.
•	Los monitores de la red podrían no ser capaces de analizar paquetes ESP que no estén cifrados (ESP-Null). Nota: la versión 2.1 de Microsoft Network Monitor incorpora un analizador de ESP para solucionar los problemas derivados de los paquetes IPsec no cifrados. Network Monitor se incluye con Microsoft Systems Management Server (SMS). Para obtener más información, visite la página de Microsoft Systems Management Server en http://www.microsoft.com/smserver.
•	Si el dispositivo no puede analizar ESP, cualquier lista de control de acceso (ACL) que especifique reglas de protocolo o puerto no se procesará en los paquetes ESP.
•	Si el dispositivo incorpora un analizador de ESP y emplea el cifrado, las listas de control de acceso (ACL) que especifiquen reglas de protocolo o puerto no se procesarán en los paquetes ESP.

IPsec cancela la administración del tráfico basada en puerto/protocolo y la priorización basada en redes cuando se utilizan puertos y protocolos. Desgraciadamente, no hay ninguna solución para los paquetes cifrados. Si la priorización o la administración del tráfico debe basarse en puertos o protocolos, el propio host deberá poder encargarse de todas las funciones de priorización o administración del tráfico.

A continuación, es importante anotar exactamente qué información se necesita para los distintos dispositivos de la red.

Dispositivos de la infraestructura de red

Los dispositivos que constituyen la infraestructura de la red (enrutadores, conmutadores, equilibradores de carga y servidores de seguridad) se comunicarán mediante IPsec cuando se haya implementado la solución. Por ello es importante examinar las siguientes características de estos dispositivos de la red para asegurarse de que podrán satisfacer los requisitos técnicos y físicos del diseño:

•	Marca/modelo. Puede utilizar esta información para determinar las funciones que admite el dispositivo. Además, deberá comprobar el BIOS o software del dispositivo para asegurarse de que admite IPsec.
•	Cantidad de RAM. Esta información puede resultar útil para determinar la capacidad necesaria o el impacto de IPsec sobre el dispositivo.
•	Análisis del tráfico. Esta información (utilización máxima además de tendencias diarias/semanales que indiquen el uso diario del dispositivo) siempre resulta útil. En relación con IPsec, esta información ayuda a obtener una visión general del dispositivo y cómo se utiliza a lo largo de un período de tiempo. Si surgen problemas tras la implementación de IPsec, la información puede ayudarnos a determinar si el problema está relacionado con una elevada utilización del dispositivo.
•	Las ACL que afectan directamente a IPsec. Las ACL afectan directamente al funcionamiento de determinados protocolos. Por ejemplo, IPsec no funcionará si no se permite el protocolo Kerberos (Protocolo de datagrama de usuario [UDP] y puerto TCP 88) o el protocolo IP (no el puerto, sino el protocolo) 50 o 51. Los dispositivos deben estar configurados para transmitir el tráfico de intercambio de claves de Internet (IKE) (UDP 500 y 4500) con la configuración transversal de traducción de direcciones de red (NAT-T).
•	Redes/subredes conectadas a la interfaz del dispositivo. Esta información ayuda a facilitar el mejor análisis posible del aspecto de la red interna. La definición del límite de la red basándose en un intervalo de direcciones es muy clara y ayuda a identificar si otras direcciones no están administradas o son externas a la red interna (como las direcciones de Internet). Esta información es necesaria para las decisiones de directiva IPsec que se toman en los capítulos sucesivos de esta guía.
•	Si el dispositivo efectúa la traducción de las direcciones de red (NAT). La traducción de las direcciones de red suele utilizarse para presentar todo un intervalo de direcciones como una IP única ante una red conectada o ante Internet. El encargado de planificar la solución debe saber dónde tiene lugar este proceso en la red. Nota: el artículo 818043 de Microsoft Knowledge Base (KB) "L2TP/IPsec NAT-T update for Windows XP and Windows 2000" en http://support.microsoft.com/kb/818043 proporciona la funcionalidad NAT-T como corrección descargable para Windows XP Service Pack (SP) 1 y Windows 2000 SP4. Sin embargo, un IPsec de respuesta no funcionaría correctamente a menos que tuviera instalado Windows XP SP2 o Windows Server 2003 SP1.
•	Segmentación de VLAN. El proceso de determinar cómo están actualmente implementadas las VLAN en la red le ayudará a entender los modelos de tráfico o requisitos de seguridad que existen actualmente y a averiguar cómo afectará IPsec a estos requisitos.
•	Los vínculos a los que está conectado el dispositivo. Esta información le ayudará a describir las conexiones que mantiene el dispositivo entre redes. También ayuda a identificar la red lógica y las conexiones a diversas ubicaciones en una interfaz determinada.
•	El tamaño de la unidad de transmisión máxima (MTU) en la interfaz del dispositivo. La MTU define el datagrama más voluminoso que puede transmitirse en una interfaz determinada sin que sea necesario dividirlo para su transmisión (un proceso también conocido como "fragmentación"). En las comunicaciones IPsec, la MTU es necesaria para determinar en qué áreas tendrá lugar una fragmentación. El enrutador deberá controlar la fragmentación de paquetes para ISAKMP (Internet Security Association and Key Management Protocol). IPsec configurará el tamaño de la MTU en la sesión según la MTU mínima detectada junto con la ruta de comunicación que se utiliza y establecerá el bit "no fragmentar" (DF bit) en 1. Nota: si el descubrimiento de MTU de ruta (PMTU) está activado y funciona correctamente, no tendrá que recoger el tamaño de MTU en interfaces de dispositivo. Algunas fuentes, como la Guía de consolidación de Windows Server 2003, recomiendan desactivar el descubrimiento de PMTU. Sin embargo, el descubrimiento de PMTU deberá activarse para que IPsec pueda funcionar correctamente.

Tenga también en cuenta que IPsec puede afectar a un sistema de detección de intrusos (IDS), pues se necesitará un analizador específico para interpretar los datos de los paquetes. Si el sistema IDS no posee un analizador, no podrá examinar los datos de dichos paquetes para determinar si una sesión concreta constituye una amenaza potencial. En ese caso, si se decide utilizar IPsec significa que la organización necesita más IPsec que IDS.

La información identificada en esta sección es crítica para el éxito del proyecto, pues ayuda a entender la configuración actual y la "salud" de la infraestructura de red antes de configurar dichos dispositivos para la utilización de IPsec (o antes de colocar cargas adicionales sobre ellos si ya se han configurado para transmitir el tráfico IPsec). Estudiando la información de uso máximo, podrá determinar si el dispositivo es capaz de utilizar IPsec en su estado actual o si requiere una actualización de firmware o de memoria para admitir la carga esperada. La información de marca y modelo resultará útil en la obtención de hardware para actualizar los dispositivos (si es necesario). También resultará útil la información obtenida sobre otras características o parámetros de configuración específicos para dicha marca y modelo. El número de ACL configuradas para dispositivos le ayudará a estimar el esfuerzo necesario para configurar los dispositivos de forma que admitan IPsec. Si no se ha configurado ningún dispositivo de la red para permitir el tráfico IPsec y su red tiene un número elevado de enrutadores, la configuración de los dispositivos podría suponer un esfuerzo importante.

Tras la obtención de esta información, podrá determinar rápidamente si es necesario actualizar los dispositivos de forma que satisfagan los requisitos del proyecto, cambiar las ACL o tomar otras medidas para asegurarse de que los dispositivos podrán manejar las cargas previstas.

Análisis del modelo de tráfico de red actual

Tras recoger información sobre la infraestructura de la red y las asignaciones, el siguiente paso lógico es examinar cuidadosamente el flujo de comunicaciones. Por ejemplo, si el departamento de Recursos Humanos (RRHH) está distribuido por varios edificios y desea utilizar IPsec para cifrar la información de este departamento, deberá saber el modo en que estos edificios están conectados para determinar el nivel de "confianza" que merece la conexión. Un edificio muy seguro conectado por cable de cobre con otro edificio que no está protegido puede verse afectado por un ataque de interceptación o un ataque de reproducción de la información. Ante ataques de este tipo, IPsec facilita una autenticación mutua segura y cifrado del tráfico para hosts de confianza. Sin embargo, la falta de seguridad física en los hosts de confianza seguiría constituyendo una amenaza.

Al examinar el flujo de tráfico, observe atentamente cómo interactúan todos los dispositivos administrados y no administrados, incluyendo los dispositivos que no están basados en Windows, como Linux, UNIX y Mac, además de las versiones de Windows anteriores a Windows 2000 SP4. Plantéese si determinadas comunicaciones tienen lugar en el nivel de puerto/protocolo o si hay muchas sesiones entre los mismos hosts a lo largo de una gran variedad de protocolos. ¿De qué modo se comunican entre sí los servidores y clientes? ¿Existe algún proyecto o dispositivo de seguridad actual implementado o planificado que pueda afectar al proyecto de aislamiento? Por ejemplo, el uso de Windows XP SP2 y Windows Firewall para "cerrar" algunos puertos, como UDP 500, provocaría el fracaso de la negociación del IKE.

Si utiliza el proceso de modelado de amenazas descrito en el capítulo 2, "Comprensión del aislamiento de servidor y dominio" para examinar los diversos tipos de tráfico de red, fácilmente encontrará aquellos protocolos y aplicaciones generadores de tráfico que debería protegerse ante dispositivos que no son de confianza o que no están administrados. Algunos de los protocolos y aplicaciones más habituales son:

•	NetBIOS con TCP/IP (NetBT) y bloque de mensajes de servidor (SMB). En una LAN, es habitual tener los puertos 137, 138 y 139 habilitados para NetBT y el puerto 445 habilitado para SMB. Estos puertos proporcionan servicios de resolución de nombres NetBIOS, además de otras características. Desafortunadamente, también son los responsables de la creación de lo que se conoce como sesiones nulas. Una sesión nula es una sesión establecida en un host que no utiliza el contexto de seguridad de una entidad o usuario conocido. Con frecuencia estas sesiones son anónimas.
•	Llamada a procedimiento remoto (RPC). Normalmente, RPC opera presentando una aplicación con un puerto de escucha (también conocido como asignador de extremos, el puerto TCP 135) que indica al "llamador" (que suele ser otra aplicación) que inicie la comunicación en otro puerto en el intervalo efímero. En una red segmentada por servidores de seguridad, esta comunicación RPC presenta un reto de configuración, pues significa abrir el puerto de escucha RPC y todos los puertos por encima de 1024. La apertura de tantos puertos incrementa la superficie de ataque de toda la red y reduce la eficacia de los servidores de seguridad. Sin embargo, la ventaja de RPC es que presenta una abstracción de la funcionalidad en las capas 1-4 del modelo de Interconexión de sistemas abiertos (OSI) para las aplicaciones que lo utilizan, de forma que no es necesario que los programadores proporcionen llamadas de nivel bajo a la red para sus aplicaciones distribuidas. Puesto que muchas aplicaciones dependen de RPC para la funcionalidad básica, la directiva IPsec deberá dar cuenta de RPC. Para obtener más información sobre la creación de la directiva IPsec, consulte el capítulo 5, "Creación de directivas de aislamiento para grupos de aislamiento".
•	Otro tráfico. IPsec puede ayudar a proteger las transmisiones entre hosts mediante la autenticación de los paquetes, además del cifrado de los datos que contienen. Es importante identificar qué es necesario proteger y qué amenazas es preciso mitigar. Deberá examinarse y modelarse apropiadamente el resto de tráfico o los tipos de tráfico que es preciso proteger. Por ejemplo, una base de datos con una finalidad específica a la que sólo pueden acceder unos cuantos clientes o una aplicación específica para el equipo de RRHH que sólo utilizan los directores de este departamento.

Tras la documentación de la red física y lógica, el siguiente paso consiste en examinar los modelos de tráfico actuales y responder a las preguntas siguientes:

•	¿Tiene actualmente subredes dedicadas a tipos específicos de tráfico (por ejemplo, estaciones de trabajo Mac y estaciones de trabajo UNIX o conexiones de gran sistema (mainframe) a terminal?
•	¿Necesita separar tipos diferentes de tráfico o el tráfico entre ubicaciones?

Active Directory

Después de la red, Active Directory es el segundo elemento en importancia del que recoger información. Deberá entender la estructura de bosque, incluidos la disposición de los dominios, la arquitectura de unidad organizativa (OU) y la topología del sitio. Esta información permite saber dónde están situados actualmente los equipos, su configuración y el impacto de introducir cambios en Active Directory como resultado de la implementación de IPsec. La lista siguiente describe la información necesaria para completar este apartado del proceso de descubrimiento.

•	Número de bosques. Puesto que el bosque es el límite de seguridad en una implementación de Active Directory, es necesario entender la arquitectura actual de Active Directory para determinar qué hosts deben aislarse y cómo conseguir dicho aislamiento.
•	Nombres y número de dominios. La autenticación IPsec se produce como resultado del proceso de negociación del IKE. En esta solución, el método de autenticación es el protocolo Kerberos. Este protocolo asume que los equipos están incorporados al dominio y que satisfacen los requisitos previos de versión de sistema operativo (Windows 2000, Windows XP o Windows Server 2003).
•	Número y tipos de confianzas. Es importante conocer el número y tipos de confianzas, pues afecta a los límites lógicos de aislamiento y al mismo tiempo definen cómo puede (o debe) tener lugar la autenticación del IKE en la solución.
•	Nombres y número de sitios. La arquitectura de sitios suele corresponderse con la topología de la red. El simple hecho de comprender cómo están definidos los sitios en Active Directory le ayudará a conocer el proceso de replicación, entre otros detalles. Para esta solución, la arquitectura de sitio permite entender mejor la implementación de Active Directory tal como existe actualmente.
•	Estructura OU. Una pequeña planificación en el momento de crear una estructura de OU le permitirá conseguir una gran eficacia operativa. Las OU son construcciones lógicas y, por lo tanto, puede moldearse para ajustarse a requisitos y objetivos diferentes. La estructura de OU es un lugar ideal para examinar de qué modo se utiliza actualmente la directiva de grupo y cuál es la disposición de las OU. Los capítulos 4 y 5 de esta solución tratan sobre la arquitectura de la OU e indican cómo puede utilizarse esta arquitectura para aplicar la directiva IPsec.
•	Uso existente de la directiva IPsec. Puesto que este proyecto culminará con la implementación de la directiva IPsec, es muy importante entender cómo utiliza actualmente IPsec la red (si lo utiliza). Tanto si está utilizando filtros IPsec sencillos (como los que se indican en una guía de consolidación) o implementando directivas completas, el entendimiento de sus necesidades y uso actual le ayudará a facilitar la integración de esta solución.

El escenario de Woodgrove Bank utiliza un solo bosque (corp.woodgrovebank.com) que contiene cuatro dominios distribuidos a lo largo de cinco sitios. Cada sitio puede contener un servidor controlador de dominio (DC), un servidor controlador de dominio primario (PDC) o un servidor de catálogo global (GC), tal como muestra la tabla siguiente:

Tabla 3.1: Información de Active Directory para Woodgrove Bank

Sitio físico	Dominio	Usuarios	Tipo de controlador de dominio
New York, NY	corp.woodgrovebank.com americas.corp.woodgrovebank.com	5.000	Catálogo global de raíz de bosque PDC GC regional de América DC regional de Europa DC regional de Asia
Chicago, IL	americas.corp.woodgrovebank.com	750	GC regional de América
Atlanta, GA	americas.corp.woodgrovebank.com	1.450	GC regional de América
Boston, MA	americas.corp.woodgrovebank.com	480	GC regional de América
San Francisco, CA	americas.corp.woodgrovebank.com	250	GC regional de América
Pittsburgh, PA	americas.corp.woodgrovebank.com	50	GC regional de América
Phoenix, AZ	americas.corp.woodgrovebank.com	50	GC regional de América
Miami, FL	americas.corp.woodgrovebank.com	50	GC regional de América
Washington, DC	americas.corp.woodgrovebank.com	75	GC regional de América
Cambridge, MA	americas.corp.woodgrovebank.com	36	GC regional de América
Toronto, Canadá	americas.corp.woodgrovebank.com	25	GC regional de América
Londres, Reino Unido	europe.corp.woodgrovebank.com corp.woodgrovebank.com	5.200	GC raíz de bosque Emulador PDC GC regional de Europa DC regional de América DC regional de Asia
Ginebra, Suiza	europe.corp.woodgrovebank.com	350	GC regional de Europa
Amsterdam, Holanda	europe.corp.woodgrovebank.com	295	GC regional de Europa
Munich, Alemania	europe.corp.woodgrovebank.com	149	GC regional de Europa
Roma, Italia	europe.corp.woodgrovebank.com	80	GC regional de Europa
Dublín, Irlanda	europe.corp.woodgrovebank.com	79	GC regional de Europa
Edimburgo, Escocia	europe.corp.woodgrovebank.com	40	GC regional de Europa
Johannesburg, Sudáfrica	europe.corp.woodgrovebank.com	37	GC regional de Europa
Tokio, Japón	asia.corp.woodgrovebank.com corp.woodgrovebank.com	500	GC raíz de bosque Emulador PDC GC regional de Asia DC regional de Europa DC regional de América
Hong Kong, China	asia.corp.woodgrovebank.com	100	GC regional de Asia
Bangkok, Tailandia	asia.corp.woodgrovebank.com	150	GC regional de Asia
Singapur	asia.corp.woodgrovebank.com	210	GC regional de Asia
Sydney, Australia	asia.corp.woodgrovebank.com	45	GC regional de Asia
Bangalore, India	asia.corp.woodgrovebank.com	35	GC regional de Asia
Taipei, Taiwan	asia.corp.woodgrovebank.com	65	GC regional de Asia

El diseño de Active Directory de Woodgrove Bank utilizó las relaciones de confianza bidireccionales que crea automáticamente el bosque. No se utilizaron bosques cruzados o confianzas externas adicionales.

La imagen siguiente muestra un ejemplo de la estructura de OU de alto nivel que se utilizó en Woodgrove Bank. Esta estructura se utilizó de forma consistente en los tres dominios regionales principales de América, Europa y Asia.

Figura 3.2 Ejemplo de estructura de OU para Woodgrove Bank
Ver imagen a tamaño completo

Puesto que el proyecto de aislamiento de servidor y dominio era la primera implementación de IPsec en Woodgrove Bank, no había ninguna directiva IPsec activa vigente.

Detección de host

La principal ventaja de un proyecto de descubrimiento de activos es la gran cantidad de datos que se obtiene sobre los hosts (estaciones de trabajo y servidores) de la red. En el capítulo 4, "Diseño y planificación de grupos de aislamiento", se toman decisiones que requieren una información precisa sobre el estado de todos los hosts para asegurarse de que pueden participar en las comunicaciones IPsec del diseño.

Requisitos de datos de host

Esta sección describe la información de host necesaria y explica cómo representar esta información física y lógicamente.

•	Nombre del equipo. Se trata del nombre NetBIOS o DNS del equipo que identifica al equipo en la red. Puesto que un equipo puede tener más de un control de acceso a medios (MAC) y/o dirección IP, el nombre del equipo es uno de los criterios que pueden utilizarse para determinar la exclusividad en la red. Los nombres de equipo pueden duplicarse en algunas circunstancias, de forma que la exclusividad no debería considerarse absoluta.
•	Direcciones IP para cada tarjeta de interfaz de red (NIC). La dirección IP es la dirección utilizada con la máscara de subred para identificar a un host en la red. Debe tener en cuenta que una dirección IP no es una forma eficaz de identificar un activo, ya que suele estar sujeta a modificaciones.
•	Dirección MAC para cada NIC. La dirección MAC es una dirección única de 48 bits que se utiliza para identificar una interfaz de red. Puede utilizarse para diferenciar entre interfaces de red distintas en el mismo dispositivo.
•	Versiones de sistema operativo, service pack y revisiones. La versión de sistema operativo es un factor clave para determinar la capacidad de un host de comunicarse con IPsec. También es importante el seguimiento del estado actual de los service pack y las revisiones que se han instalado, pues suelen utilizarse para determinar que se han satisfecho los estándares mínimos de seguridad.
•	Pertenencia a dominios. Esta información se utiliza para determinar si un equipo puede obtener directivas IPsec de Active Directory o si será necesario utilizar una directiva IPsec local.
•	Ubicación física. Se trata de la ubicación del dispositivo en su organización. Puede utilizarse para determinar si un dispositivo debería participar en un grupo de aislamiento particular basándose en su ubicación o en la ubicación de los dispositivos con los que se comunica regularmente.
•	Tipo/función de hardware. Quizás no sea posible recoger esta información mediante un proceso automatizado. Algunas herramientas que se encargan del descubrimiento de host pueden facilitar esta información consultando la información del hardware y ejecutando aplicaciones para determinar su tipo, por ejemplo servidor, estación de trabajo o Tablet PC. Podría utilizar esta información para determinar la idoneidad de un equipo determinado a la hora de participar en el aislamiento y en qué grupo de aislamiento ubicar el equipo. Nota: la información de tipo de hardware se obtiene de la interpolación de datos o de un producto de software que efectúa consultas para facilitar esta información. Por ejemplo, sabe que un HP Evo n800 es un equipo móvil y si puede consultar en el nivel de hardware (o posee una etiqueta de activo que lo identifica como tal), podrá determinar fácilmente la directiva IPsec apropiada que debe asignarse al dispositivo.

Tras recoger toda esta información y consolidarla en una base de datos, deberá llevar a cabo esfuerzos de descubrimiento regulares a intervalos periódicos para actualizar la información. Necesitará la imagen más completa y actualizada de los hosts administrados en sus redes para crear un diseño que satisfaga los requisitos de su organización.

Puede utilizar varios métodos para recoger datos de los hosts de la red. Estos métodos van desde sistemas superiores totalmente automatizados a la recopilación de datos totalmente manual. Normalmente, por motivos de velocidad y precisión, se prefiere el uso de métodos automatizados para recoger datos sobre métodos manuales. Sin embargo, la información necesaria es la misma independientemente del método utilizado; sólo varía la cantidad de tiempo que se invierte en obtenerla. Algunos problemas habituales de los procesos manuales son la obtención de información duplicada, asegurarse de que el alcance del esfuerzo es adecuado (si se han explorado todas las redes y se ha recogido la información de hosts o sólo las subredes de cliente), y la obtención de información a tiempo de modo que resulte de utilidad para el proyecto. La discusión de todos los elementos de una auditoría completa del sistema de TI queda fuera del alcance de este proyecto. Sin embargo, es importante entender que esta información de auditoría le resultará útil a la organización por muchos otros motivos además de para esta solución. La administración de los riesgos de seguridad y el seguimiento de activos son sólo dos ejemplos importantes de procesos que requieren un inventario actual y preciso del sistema.

Descubrimiento automático

La utilización de un sistema de administración de redes con auditoría automatizada como SMS proporcionará información valiosa sobre el estado actual de la infraestructura de TI. Sin embargo, un problema de los sistemas automatizados es que los hosts que no estén en línea y conectados o no puedan responder física (o lógicamente) a las peticiones de información no aparecerán en la base de datos final. Incluso los sistemas más automatizados requieren un elemento de administración manual para asegurarse de que es posible acceder a los hosts y tenerlos en cuenta de la forma apropiada.

Diversos proveedores ofrecen productos y herramientas distintos. Algunos métodos utilizan un mecanismo de exploración central y otros utilizan agentes que se instalan en los equipos cliente. Queda fuera del alcance de esta guía comparar o recomendar la adquisición de determinados productos, aunque la solución requiere que los datos de descubrimiento que se destacan en este capítulo estén presentes para las consideraciones de diseño que se efectúan en los capítulos 4 y 5.

Para obtener más información sobre cómo puede ayudar SMS 2003 a la administración de activos (o puede ayudar a recoger la información que requiere este proyecto), consulte la demostración y hoja de datos de administración de activos que encontrará en la página SMS 2003 Asset Management en www.microsoft.com/smserver/evaluation/capabilities/
asset.asp.

Descubrimiento manual

La mayor diferencia entre los métodos de descubrimiento manual y los métodos automatizados es el tiempo. Para recoger la información requerida para este proyecto, podrían necesitarse docenas de personas trabajando durante días o incluso semanas, e incluso más si se trata de una organización más grande. Si prevé utilizar un método manual para efectuar una auditoría del estado actual de su infraestructura, es importante que la información obtenida esté disponible en formato electrónico, por ejemplo en una hoja de cálculo o base de datos. El abrumador volumen de datos que puede generarse puede dificultar el proceso de filtrado y análisis de la información, y es posible que no pueda generar de un modo rápido y preciso consultas específicas que le proporcionen la información necesaria. Además, puede utilizar administradores de TI locales para obtener la información o validar cualquier información recogida anteriormente.

Incluso si su organización no posee una herramienta de auditoría automatizada, puede obtener un elemento de automatización utilizando las interfaces de secuencias de comandos y de administración remota estándar disponibles en la plataforma Windows. El principal problema derivado del uso de estas herramientas es asegurarse de que no se pasen por alto algunos clientes sólo por el hecho de que no son compatibles con la herramienta administrativa o secuencia de comandos.

Puede utilizar Windows Scripting Host (WSH), Microsoft Visual Basic® Scripting Edition (VBScript) y Windows Management Instrumentation (WMI) para crear un archivo de comandos que pueda recoger información de configuración del sistema. La tabla siguiente muestra la disponibilidad de VBScript y WMI por plataforma.

Tabla 3.2: Disponibilidad de VBScript y WMI por plataforma

Plataforma	VBScript	WMI
Windows 95	Instalación de WSH 5.6	Instalación de WMI CORE 1.5
Windows 98	Integrado	Instalación de WMI CORE 1.5
Windows Millennium	Integrado	Integrado
Microsoft Windows NT® versión 4.0	Instalación de WSH 5.6	Instalación de WMI CORE 1.5
Windows 2000	Integrado	Integrado
Windows XP	Integrado	Integrado
Windows Server 2003	Integrado	Integrado

Nota: puede descargar Microsoft Windows Script 5.6 Update de la página Microsoft Windows Script Downloads en http://msdn.microsoft.com/library/default.asp?url=/
downloads/list/webdev.asp.
Puede descargar el archivo de instalación Windows Management Instrumentation (WMI) CORE 1.5 del Centro de descarga de Microsoft en www.microsoft.com/downloads/details.aspx?FamilyID=afe41f46-e213-4cbf-9c5b-fbf236e0e875&DisplayLang=en.

En la carpeta Herramientas y plantillas de esta solución se facilita un ejemplo de VBScript bajo el nombre de Discovery.vbs. Esta secuencia de comandos utiliza WMI para recoger toda la información que aparece bajo la sección "Requisitos de datos de host" de este capítulo, a excepción de la función y la ubicación física. La información se guarda en el archivo de texto C:\Discovery\<systemname>_info.txt en el equipo local. Podría modificar la secuencia de comandos para recoger más información o colocar la información recogida en un archivo compartido remoto.

Si WMI o VBScript no están disponibles en el equipo host, puede recoger cierta información utilizando un archivo de comandos por lotes y herramientas externas. El problema es que el lenguaje de lotes es muy limitado en cuanto a funcionalidad y no resulta fácil obtener la información de configuración de la línea de comandos en versiones anteriores de Windows.

Para llevar a cabo un descubrimiento de host, es necesario consultar los hosts y proporcionar un lugar en el que guardar los resultados de dichas consultas.

Tanto si utiliza una opción automática, manual o híbrida para recoger la información, uno de los temas más importantes que puede causar problemas en el diseño es capturar los cambios entre la exploración de inventario original y el punto en el que la implementación está preparada para funcionar. Tras completar la primera exploración, deberá indicar al personal de soporte técnico que es imprescindible anotar en el inventario todos los cambios y las actualizaciones posteriores.

Este inventario será crítico para planificar e implementar directivas IPsec, que se abordarán en capítulos posteriores.

Principio de la página

Consideraciones de capacidad

Tras completar la recogida de información, deberá proceder a estudiar el impacto de IPsec y a planificar la capacidad hasta cierto punto. Esta sección describe algunos de los aspectos esenciales de la planificación correcta de IPsec en su entorno.

Impacto de IPsec

Puesto que IPsec utiliza varias técnicas de cifrado, puede suponer una carga importante para un equipo. Los escenarios que será preciso analizar con más detalle son aquellos que requieren cifrado. Por ejemplo, podría utilizarse el estándar de cifrado de datos triple (3DES) y el algoritmo hash seguro (SHA-1) para verificar la integridad en aquellas situaciones que requieren protección de intercambio de claves y el cifrado más potente disponible. Otro escenario implica la negociación de asociación de seguridad (SA). Podría emplear un ciclo de vida más corto para la SA de modo principal, por ejemplo tres horas, pero al igual que sucede con muchas consideraciones de seguridad se espera que haga algunas concesiones. Cada SA de modo principal ocupa aproximadamente 5 KB de RAM. Si se espera que un servidor actúe como intermediario para decenas de miles de conexiones concurrentes, podría provocar una sobreutilización. Otros factores incluyen la utilización de la CPU en servidores de infraestructura de red, mayor carga sobre los servidores y estaciones de trabajo que utilizan IPsec (especialmente los servidores, pues en muchos casos contienen más SA de modo principal que los clientes), y mayor latencia de red como resultado de la negociación de IPsec.

Nota: en la implementación de Microsoft de esta solución se descubrió que es normal esperar un incremento de entre un uno y un tres por ciento en la utilización de la red como resultado directo del uso de IPsec.

Otra cuestión importante es la presencia de redes conectadas con un dispositivo de NAT entre ellas. El problema es que la NAT no admite conversaciones de encabezado de autenticación (AH) entre hosts, pues la NAT infringe el principio básico que el AH pretende facilitar: la autenticación de un paquete sin modificar, incluido el encabezado. Si existen dispositivos de NAT en la red interna, será necesario seleccionar ESP en lugar de AH. ESP ofrece la capacidad de cifrar datos, pero no requiere el cifrado. Este factor es importante desde el punto de vista de la consideración de la capacidad, pues el cifrado comporta cargas que deberán considerarse durante las fases de planificación y diseño del proyecto. ESP también puede implementarse con cifrado nulo, para facilitar la comunicación IPsec de igual a igual más segura posible sin interrumpir las comunicaciones con NAT. Además, puesto que no emplea el cifrado, tendría un impacto inferior que ESP con cifrado.

Impacto de la directiva

La directiva IPsec y la directiva de grupo afectarán a los tiempos de arranque de los equipos, así como al tiempo que necesitan los usuarios para iniciar la sesión. En la fase de recopilación de información, resulta útil anotar los tiempos de arranque del equipo y los tiempos de inicio de sesión de los usuarios, antes de implementar la solución. Registrar estos tiempos le permitirá comparar los sistemas de prueba durante la prueba piloto para determinar el impacto sobre el tiempo total que tardará un usuario en iniciar la sesión.

Principio de la página

Cuestiones previas a la implementación

En las secciones anteriores se describe la información que debe recoger de la red, Active Directory y los hosts para que la solución de aislamiento tenga éxito. En esta sección encontrará las cuestiones que debe examinar atentamente antes de implementar IPsec.

Infraestructura de red

La recopilación de información le permite planificar el aislamiento de IPsec en una red. Tras recoger esta información, un análisis detallado de los datos revelará la mayoría de los problemas a los que se enfrentará durante la prueba piloto y la implementación. Aunque los siguientes elementos no constituyen una lista exhaustiva, es importante tenerlos en cuenta cuando empiece el análisis de la información recogida antes de la fase de prueba e implementación.

Dispositivos que se utilizan en exceso

Quizás necesite actualizar o volver a configurar conmutadores o enrutadores que actualmente superan el 75% de utilización para permitir un mayor tráfico en el dispositivo y prever una utilización extra en caso de picos de tráfico. La planificación correcta de la capacidad para la implementación de IPsec está más relacionada con la evaluación y la previsión de las cargas de tráfico que con cálculos exactos. Puesto que es muy improbable que el escenario, los modelos de tráfico, las concentraciones de usuarios y las aplicaciones sean exactamente iguales para dos clientes distintos, resulta imprescindible efectuar una planificación adecuada y considerar de qué modo se verán afectados los dispositivos de la red. Por ejemplo, algunos aspectos de IPsec son totalmente predecibles. Un paquete que utilice IPsec con ESP tendrá un tamaño 36 bytes superior que un paquete que no utilice IPsec. Puesto que se necesitan seis mensajes para establecer una sola SA de modo principal, es más sencillo dar cuenta de cómo se verá afectada la utilización en un dispositivo concreto. Puede utilizar herramientas como la aplicación PROVISO de Quallaby en www.quallaby.com u otras soluciones de analizador de red para ayudar en la planificación de capacidad para IPsec en su entorno de TI.

Dispositivos incompatibles

Los dispositivos que no son compatibles con IPsec no pueden participar en las comunicaciones IPsec. Si dichos dispositivos necesitan comunicarse con un dispositivo gestionado, deberá colocarlos en la lista de exenciones de IPsec. Una alternativa es actualizar el hardware o el software del dispositivo para permitir IPsec. Otra alternativa consiste en permitir que dichos dispositivos no administrados se comuniquen con equipos de límite cuando retrocedan a texto no cifrado para sus comunicaciones salientes.

Dispositivos mal configurados

Los dispositivos mal configurados incrementan la posibilidad de errores de comunicación y mayor carga en el dispositivo, e incluso podría ponerse en peligro el propio dispositivo. Las siguientes prácticas recomendadas para la configuración, administración y seguridad de los dispositivos le ayudarán a aliviar el problema.

Asignación de direcciones IP

Puesto que las direcciones IP son el pilar fundamental de una solución IPsec, es importante que la asignación de direcciones sea tan "clara" como sea posible. Cuestiones como espacios de dirección solapados, direcciones duplicadas, máscaras de subred incorrectas y otros problemas pueden complicar el funcionamiento normal de la red. Si se incorpora IPsec a una red de este tipo será más difícil solucionar los problemas y probablemente los usuarios sospecharán que IPsec es la causa de todos ellos. El crecimiento de una organización, las fusiones y adquisiciones, y otros factores similares pueden ser los responsables de una imagen imprecisa y anticuada de la asignación de direcciones IP en una red. Para eliminar los principales problemas relacionados con IPsec, asegúrese de que la red está dividida en subredes que no se solapan, que las tablas de rutas están bien resumidas y que la agregación de direcciones se define fácilmente.

Información de Active Directory

Si la implementación de Active Directory actual funciona correctamente (es decir, resolución de nombre, protocolo de configuración dinámica de host [DHCP], aplicación de directiva de grupo, relaciones de confianza, etc.) nada debería afectar a IPsec. Analice los cambios realizados entre el momento en que se examinó Active Directory y el momento en que se inicia el proyecto de aislamiento para asegurarse de que no tendrá ningún problema de incompatibilidad.

Información de host

Las secciones anteriores le habrán ayudado a recoger información suficiente sobre los hosts de la red. Tras determinar qué clientes y servidores pueden utilizar IPsec, observe de qué forma es necesario aislarlos y qué aplicaciones es preciso examinar atentamente para averiguar qué impacto tendrá la solución de aislamiento sobre ellas.

Cómo determinar la participación de cliente/servidor

Tras recoger información sobre los hosts, resulta bastante sencillo determinar qué hosts podrán integrarse en la solución de aislamiento. Por ejemplo, sólo los equipos basados en Windows 2000, Windows Server 2003 y Windows XP pueden comunicarse con IPsec. Sin embargo, quizás no todos los clientes que pueden participar deberían hacerlo. Una parte importante del proceso de diseño es determinar, a partir de la información recogida en este capítulo, qué equipos y dispositivos se incluirán en la solución y en qué grupo residirán.

Cómo determinar los servicios que es preciso aislar

En el contexto del proyecto de aislamiento de servidor y dominio, un servicio es una aplicación, como Microsoft Exchange Server, Microsoft SQL Server™ o Internet Information Services (IIS), que facilita sus servicios a clientes de la red. Debería evaluar estos servicios individualmente para determinar si son candidatos para el aislamiento de servidor y dominio. Existen varios motivos por los que estos servicios podrían tener que incluirse en la solución, como la política organizativa, la normativa gubernamental u otros requisitos empresariales. Por ejemplo, podría existir una política organizativa que exigiera que todas las comunicaciones entre servidores de correo se protegieran mediante IPsec, y que al mismo tiempo indicara que no es necesario proteger de este modo las comunicaciones entre clientes y servidores. En el capítulo 4, "Diseño y planificación de grupos de aislamiento", se discute el proceso de aislamiento en más detalle. Cuando intente aislar servicios, considere atentamente aquellos servidores que presentan múltiples servicios, como un servidor de archivos que facilita servicios Web y protocolo de transferencia de archivos (FTP) y, al mismo tiempo, actúa como servidor de correo.

Equilibrio de cargas de la red y clúster

Las organizaciones que aplican el aislamiento de servidor y dominio pueden excluir a los equipos que empleen el equilibro de cargas de la red (NLB) y clúster. IPsec no es compatible con NLB en modo de "no afinidad", pues IPsec evita que equipos diferentes utilicen la misma conexión de cliente. Debido a esta incompatibilidad, no debe intentar utilizar NLB en modo de "no afinidad" con IPsec.

Administración de excepciones

La administración de excepciones es una parte importante de la planificación de IPsec. Un elemento crucial del aislamiento es determinar dónde utilizar equipos que permitan el acceso de hosts que no son de confianza y controlar el acceso entre equipos administrados y no administrados. Una práctica recomendada es mantener el número de excepciones tan bajo como sea posible. Las necesidades técnicas pueden exigir que no se implante IPsec en algunos equipos o servicios, como controladores de dominio y servidores DHCP, DNS y WINS. Puesto que de todos modos será necesario administrar estos equipos, el riesgo potencial es más bajo que permitir que equipos no administrados se comuniquen con equipos administrados y de confianza.

Dispositivos no basados en Windows

La mayoría de las redes empresariales no son homogéneas. Para la planificación de una implementación de IPsec, deberá tenerse en cuenta la diversidad de elementos como sistemas operativos, infraestructura de red y plataformas de hardware. Si su organización tiene equipos no basados en Windows, debería saber que de momento no es posible utilizar directivas IPsec fuera del entorno de Windows. Una organización podría reaccionar ante esta restricción tratando algunas plataformas como de confianza, pero puesto que en estas plataformas no se puede aplicar la directiva IPsec, la solución de aislamiento de servidor y dominio no las protegería. En la sección siguiente se indica cómo determinar la confianza.

Dispositivos de administración y supervisión

Un aspecto de IPsec que con frecuencia se olvida durante la planificación inicial es el impacto de la administración y la supervisión del tráfico de la red. Puesto que IPsec requiere autenticación y permite el cifrado, algunos dispositivos no podrán supervisar o administrar equipos habilitados para IPsec. En aquellos casos en los que es obligatorio el cifrado, la organización está indicando que es más importante la seguridad que la necesidad operativa de supervisar los datos transmitidos por la red. En otros casos, será necesario evaluar qué cambios se pueden introducir en una aplicación o dispositivo para permitir la supervisión de IPsec (como un analizador ESP que pueda controlar el tráfico ESP). Si no es posible actualizar los dispositivos de administración o supervisión para que admitan IPsec, es vital que registre esta información. El arquitecto de la solución o el equipo de diseño deberá utilizar esta información en el capítulo 4, "Diseño y planificación de grupos de aislamiento".

Principio de la página

Determinación de confianza

Tras obtener información sobre los dispositivos host que actualmente forman parte de la infraestructura de TI, debe efectuar una determinación fundamental que afectará directamente a la capacidad de un host para participar en la solución. Esta determinación es decidir en qué punto puede considerarse de confianza un host. El término de confianza puede tener varios significados según quién lo interprete, por lo tanto es importante proporcionar una definición fija del mismo a todos los implicados en el proyecto. De lo contrario, podrían surgir problemas de seguridad en el entorno de confianza, pues la seguridad global no puede sobrepasar el nivel de seguridad establecido por el cliente menos seguro al que se le concede el estado "de confianza".

Para comprender este concepto, considere los cuatro estados básicos aplicables a los hosts en una infraestructura de TI típica. Estos estados son (en orden de riesgo, el de menos riesgo en primer lugar):

1.	De confianza
2.	Digno de confianza
3.	Conocido, no es de confianza
4.	Desconocido, no es de confianza

El resto de esta sección define estos estados y el modo de determinar qué hosts de la organización pertenecen a qué estados.

Estado de confianza

Clasificar un host como de confianza no implica que el host sea completamente seguro o invulnerable. Fundamentalmente, de confianza significa que los riesgos de seguridad del host están administrados. La responsabilidad de este estado administrado recae en los administradores de TI y los usuarios responsables de la configuración del host. Un host de confianza que no esté bien administrado probablemente se convertirá en un punto débil para toda la solución.

Cuando un host se considera de confianza, el resto de hosts de confianza deben poder asumir razonablemente que el host no iniciará un ataque malintencionado. Por ejemplo, los hosts de confianza deben esperar que el resto de hosts de confianza no ejecutarán un virus que pueda atacarles, pues todos los hosts de confianza deben utilizar mecanismos (como software antivirus) para mitigar la amenaza de virus.

La comunicación entre hosts de confianza no debe estar obstruida por la infraestructura de red. Por ejemplo, puesto que un host de confianza puede asumir que otros hosts de confianza no tienen malas intenciones, no suele ser necesario bloquear los paquetes de nivel IP para restringir el acceso por parte de otros hosts de confianza. Debería implementar las restricciones necesarias para controlar las comunicaciones de host por puerto o protocolo utilizando un servidor de seguridad basado en host en el propio equipo, y no mediante IPsec.

En el escenario de Woodgrove Bank, el equipo de seguridad definió los siguientes cinco objetivos clave que se utilizaron para planificar qué tecnologías necesitaría un host para que pudiera obtener el estado "de confianza":

•

No ha quedado comprometida la identidad del equipo o del usuario.

•

Los recursos requeridos son seguros y están disponibles, independientemente del lugar en el que residan en el entorno administrado.

•	Un recurso designado como seguro no presenta alteraciones, virus o accesos no autorizados.
•	Un recurso designado como disponible satisface o supera los niveles prometidos de tiempo de actividad y no presenta vulnerabilidades de seguridad.
•	Un entorno que ha sido designado como administrado tiene equipos con Windows 2000 SP4 o posteriores, bien configurados y revisados.

•

Los datos y las comunicaciones son privadas, es decir, sólo los destinatarios previstos leen y utilizan la información.

•

El operador/propietario del dispositivo entiende y cumple con las directivas y procedimientos para garantizar que el entorno sigue siendo digno de confianza.

•

Existe una respuesta oportuna ante riesgos y amenazas.

El equipo de soporte de Woodgrove Bank utilizó estos objetivos para definir un conjunto de requisitos tecnológicos que permitiera determinar si un host podía considerarse de confianza.

Al definir el estado de confianza, asegúrese de que los propietarios de activos pueden imponer requisitos de seguridad adicionales para satisfacer las necesidades empresariales de un activo específico. Por ejemplo, su departamento de RRHH podría necesitar un mecanismo de inicio de sesión biométrico para determinados servidores. Este requisito no afectará a la capacidad de los servidores de ser servidores de confianza en el contexto de esta solución. Sin embargo, debe estar atento para asegurarse de que los requisitos de un activo específico no entran en conflicto con los requisitos del estado de confianza.

Dedique algún tiempo a definir los objetivos y los requisitos tecnológicos que consideraría apropiados su organización como configuración mínima para que un host obtuviera el estado de confianza.

Por ejemplo, el equipo de diseño utilizó la siguiente lista de requisitos tecnológicos en el escenario de Woodgrove Bank:

•	Sistema operativo. Un host de confianza debe utilizar Windows XP SP2 o Windows Server 2003 o, como mínimo, Windows 2000 SP4.
•	Pertenencia a dominios. Un host de confianza pertenecerá a un dominio administrado, lo que significa que el departamento de TI necesita derechos de administración de seguridad.
•	Cliente de administración. Todos los hosts de confianza deben ejecutar un cliente de administración de red específico para permitir la administración y control centralizados de políticas de seguridad, configuraciones y software.
•	Software antivirus. Todos los clientes de confianza ejecutarán el software antivirus configurado para comprobar y actualizar automáticamente los últimos archivos de firma de virus a diario.
•	Sistema de archivos. Todos los hosts de confianza se configurarán con el sistema de archivos NTFS.
•	Configuración de BIOS. Todos los equipos móviles de confianza se configurarán con una contraseña de nivel de BIOS administrada por el equipo de soporte técnico de TI.
•	Requisitos de contraseña. Los clientes de confianza deben utilizar contraseñas seguras.

Es importante entender que el estado de confianza no es constante; se trata de un estado transitivo sujeto a estándares de seguridad variables y al cumplimiento de dichos estándares. Constantemente surgen nuevas amenazas y defensas. Por ello es muy importante que los sistemas administrativos de la organización comprueben continuamente los hosts de confianza, para asegurarse de que siguen cumpliendo los estándares. Además, estos sistemas deben ser capaces de entregar actualizaciones o cambios de configuración, si es necesario, para mantener el estado de confianza.

Un host que sigue satisfaciendo todos estos requisitos de seguridad puede considerarse un host de confianza. Sin embargo, es muy probable que la mayoría de equipos host identificados en el proceso de descubrimiento descrito anteriormente no satisfagan estos requisitos actualmente. Por lo tanto, es importante identificar qué hosts pueden ser de confianza y qué hosts no pueden serlo. Para facilitar este proceso, puede definir un estado intermedio de host digno de confianza. En el resto de esta sección se discuten los diferentes estados y sus implicaciones.

Estado "Digno de confianza"

Resulta útil identificar tan pronto como sea posible los hosts de la infraestructura actual a los que se podrá asignar un estado de confianza, si es necesario. Un estado digno de confianza puede asignarse para indicar que el host actual es físicamente capaz de alcanzar el estado de confianza con los cambios de software y configuración necesarios.

Para cada equipo al que se asigne un estado digno de confianza, deberá crear una nota de configuración que registre qué se necesita para que el host pueda alcanzar el estado de confianza. Esta información es especialmente importante para el equipo de diseño del proyecto (para estimar los costes de agregar el host a la solución) y para el personal de soporte técnico (para que puedan aplicar la configuración necesaria). Normalmente, los hosts dignos de confianza se inscriben en uno de los siguientes dos grupos:

•

Configuración necesaria. El hardware, sistema operativo y software actual permitirán al host alcanzar el estado digno de confianza. Sin embargo, antes de poder alcanzar los niveles de seguridad requeridos, deberán efectuarse cambios adicionales de configuración. Por ejemplo, si la organización requiere un sistema de archivos seguro para poder considerar que un host es de confianza, un host con un disco duro con formato FAT32 no satisfaría este requisito.

•

Actualización necesaria. Este grupo de equipos necesitará actualizaciones del sistema antes de poder ser considerados de confianza. La siguiente lista proporciona algunos ejemplos del tipo de actualización necesaria para los equipos de este grupo:

•	Actualización de sistema operativo necesaria. Si el sistema operativo actual del host no puede satisfacer las necesidades de seguridad de la organización, será necesaria una actualización para que el host pueda alcanzar el estado de confianza.
•	Software necesario. Un host que no posea una aplicación de seguridad necesaria, como un escáner antivirus o un cliente de administración, no podrá considerarse de confianza hasta que estas aplicaciones estén instaladas y activas.
•	Actualización de hardware necesaria. En algunos casos, un host puede requerir una determinada actualización de hardware antes de alcanzar el estado de confianza. Este tipo de host normalmente necesita una actualización de sistema operativo o un software adicional que impulse la actualización de hardware necesaria. Por ejemplo, un software de seguridad que necesitara espacio de almacenamiento adicional en el equipo impulsaría un requisito de más espacio en el disco duro.
•	Sustitución de equipo necesaria. Esta categoría está reservada para los hosts que no pueden alcanzar los requisitos de seguridad de la solución porque su hardware no admite la configuración mínima aceptable. Por ejemplo, un equipo que no pueda ejecutar un sistema operativo seguro porque tiene un procesador antiguo (por ejemplo, un equipo basado en x86 de 100 megaherzios [MHz]).

Utilice estos grupos para asignar costes de implementación de la solución en los equipos que requieren actualizaciones.

Estado "Conocido, no es de confianza"

Durante el proceso de categorizar los hosts de una organización, identificará algunos hosts a los que no se les puede asignar el estado de confianza por determinados motivos claros y bien definidos. Existen tipos de motivos diferentes:

•	Financiero. No se dispone de los fondos necesarios para actualizar el hardware o software de este host.
•	Político. El host podría tener que permanecer en un estado que no es de confianza como resultado de una situación política o empresarial que no le permite satisfacer los requisitos de seguridad mínimos especificados por la organización. Se recomienda que se ponga en contacto con el responsable de negocios o proveedor de software independiente (ISV) del host para discutir el valor añadido del aislamiento de servidor y dominio.
•	Funcional. El host debe utilizar un sistema operativo no seguro o funcionar de una forma no segura para llevar a cabo su función. Por ejemplo, el host podría verse obligado a utilizar un sistema operativo anterior porque la aplicación de una línea de negocios determinada sólo funciona con dicho sistema operativo.

Puede haber diversos motivos funcionales por los que un host debe permanecer en un estado conocido que no es de confianza. La lista siguiente incluye varios ejemplos de motivos funcionales que comportan una clasificación de este estado:

•	Equipos que utilizan Windows 9x o Windows Millennium Edition. Los equipos con estas versiones del sistema operativo Windows no pueden clasificarse como dignos de confianza, pues no admiten una infraestructura de seguridad básica. En realidad, el diseño de estos sistemas operativos no incluye ningún tipo de infraestructura de seguridad. Además, estos sistemas operativos sólo tienen capacidades de administración central rudimentarias para configuraciones de sistemas específicas de usuario (a través de secuencias de comandos de inicio de sesión de usuario y directiva del sistema). Finalmente, estos sistemas operativos no ofrecen ninguna de las capacidades de administración de seguridad necesarias.
•	Equipos que utilizan Windows NT. Los equipos que utilizan Windows NT no pueden clasificarse como dignos de confianza en el contexto de un aislamiento de servidor y dominio porque este sistema operativo no admite totalmente una infraestructura de seguridad básica. Por ejemplo, Windows NT no admite ACL de denegación en recursos locales para garantizar la confidencialidad e integridad de las comunicaciones de red, tarjetas inteligentes para autenticación segura o administración centralizada de configuraciones de equipos (aunque sí admite la administración central limitada de las configuraciones de usuario). Windows NT tampoco facilita ningún modo de protección de la confidencialidad de los datos ni garantías de su integridad (como Windows 2000 Encrypting File System). Además, Windows NT no admite todas las capacidades de seguridad obligatorias. Por ejemplo, no admite la Directiva de grupo o Directiva IPsec ni proporciona un mecanismo que garantice la obtención del acceso local de nivel de administrador si es necesario. Además, sus configuraciones de seguridad no se aplican regularmente para garantizar que siguen siendo válidas. Nota: la descripción de Windows NT como un sistema no digno de confianza se refiere únicamente a la implementación del aislamiento de servidor y dominio y no se refiere a su utilización como sistema operativo en general. Para los servidores de este proyecto, la actualización a la plataforma Windows Server 2003 representa la solución más segura y fácil de administrar.
•	Equipos independientes. Los equipos con cualquier versión de Windows configurados como equipos independientes o como miembros de un grupo de trabajo normalmente no pueden alcanzar un estado digno de confianza. Aunque estos sistemas operativos admiten totalmente la mínima infraestructura de seguridad básica requerida, resulta difícil alcanzar las capacidades de administración de seguridad necesarias si el equipo no forma parte de un dominio de confianza.
•	Equipos que forman parte de un dominio que no es de confianza. Un equipo que es miembro de un dominio clasificado como dominio que no es de confianza por el departamento de TI de una organización no puede considerarse de confianza. Un dominio que no es de confianza es aquel que no puede proporcionar las capacidades de seguridad requeridas a sus miembros. Aunque quizás los sistemas operativos de los equipos que son miembros de este dominio que no es de confianza admitan la mínima infraestructura de seguridad básica requerida, no es posible garantizar las capacidades de administración de seguridad requeridas si los equipos no pertenecen a un dominio de confianza. Por ejemplo, en un dominio que no sea de confianza no existe ningún mecanismo disponible para asegurarse de que, si es necesario, un usuario de confianza puede obtener acceso local de nivel de administrador. Además, las configuraciones de seguridad pueden ser anuladas fácilmente por los administradores del dominio que no es de confianza (incluso las administradas centralmente). Tampoco es posible garantizar el cumplimiento de la configuración, el software, las directivas y estándares de seguridad, y no existen medidas para supervisar su cumplimiento de una forma eficaz.
•	Equipos en un dominio de Windows NT. Los equipos que son miembros de un dominio basado en Windows NT no pueden clasificarse como de confianza. Aunque sus sistemas operativos admiten totalmente la mínima infraestructura de seguridad básica requerida, las capacidades de administración de seguridad necesarias no se admiten por completo si el equipo no forma parte de un dominio de Windows NT. Sin embargo, si es necesario tener en cuenta el host en el diseño porque proporciona una función necesaria para la organización debería asignarle el estado "conocido, no es de confianza". Esto significa que se ha identificado un riesgo que la solución no puede mitigar. Deberá utilizar técnicas adicionales para mitigar esta amenaza conocida. Debido a la naturaleza de los hosts en esta categoría, no es posible facilitar información específica sobre estas técnicas. Sin embargo, el objetivo de estas técnicas debería ser minimizar el riesgo que conlleva este host.

Estado desconocido, no es de confianza

El estado desconocido, no es de confianza, debería considerarse el estado predeterminado para todos los hosts. Puesto que los hosts con este estado tienen una configuración desconocida, no pueden clasificarse como de confianza. Toda planificación referente a hosts en este estado debe asumir que el host ha estado o puede estar en peligro y, por lo tanto, supone un riesgo no aceptable para la organización. Los diseñadores de esta solución deberán esforzarse por minimizar el impacto que pueden tener sobre la organización los equipos con este estado.

Principio de la página

Obtención de los costes de actualización de los hosts actuales

El paso final de este capítulo se refiere al proceso de registrar el coste aproximado de actualizar los equipos para que puedan participar en la solución. Durante la fase de diseño del proyecto, deberá tomar varias decisiones clave que requieren respuestas para las preguntas siguientes:

•	¿Satisface el equipo los requisitos de hardware mínimos necesarios para el aislamiento?
•	¿Satisface el equipo los requisitos de software mínimos necesarios para el aislamiento?
•	¿Qué cambios de configuración son necesarios para integrar este equipo en la solución de aislamiento?
•	¿Cuál es el coste proyectado o el impacto de introducir los cambios propuestos para que el equipo pueda alcanzar un estado de confianza?

Respondiendo estas preguntas, podrá averiguar rápidamente el nivel de esfuerzos y el coste aproximado de incorporar un host determinado o un grupo de hosts al marco del proyecto. Es muy probable que una sola persona (o incluso varias personas con una misma función), no puedan recoger toda esta información. El servicio de asistencia o los técnicos de servicio aportarán parte de la información, pero probablemente también se necesitará un arquitecto o entrada de nivel de patrocinador empresarial para recoger el resto. Es importante recordar que el estado de un equipo es transitivo y que, si llevan a cabo las medidas correctivas indicadas, podrá cambiar el estado de un equipo y convertirlo en un equipo de confianza. Tras decidir si clasificar un equipo como de confianza, podrá empezar a planificar y diseñar los grupos de aislamiento según se especifica en el Capítulo 4, "Diseño y planificación de grupos de aislamiento", incluido en esta guía.

La tabla siguiente es un ejemplo de una hoja de datos que podría utilizar para recoger el estado actual de un host y los requisitos para que el host alcance un estado de confianza.

Tabla 3.3: Recogida de datos de host de muestra

Nombre del host	Requisitos de hardware satisfechos	Requisitos de software satisfechos	Configuración necesario	Detalles	Coste previsto
HOST-NYC-001	No	No	Actualización de hardware y software.	El sistema operativo actual es Windows NT 4.0. El hardware anterior no es compatible con Windows XP SP2.	XXX USD
SERVER-LON-001	Sí	No	Dominio de confianza y actualización de Windows NT 4.0 a Windows 2000 SP4 o posterior.	No hay software antivirus instalado.	XXX USD

En la lista siguiente se explican las columnas de la Tabla 3.3:

Nombre del host. El nombre del dispositivo host en la red.

•	Requisitos de hardware satisfechos. Refleja si un equipo satisface los requisitos de hardware mínimos para participar en la solución.
•	Requisitos de software satisfechos. Refleja si un equipo satisface los requisitos de software mínimos para participar en la solución. En Woodgrove Bank, el mínimo se estableció en Windows 2000 SP4, Windows XP SP2 o Windows Server 2003, así como todas las revisiones críticas de seguridad para cada sistema operativo. Además, los equipos debían estar en un dominio de confianza (es decir, un dominio administrado centralmente por el personal de TI de Woodgrove Bank) y debe facilitar a los administradores de TI acceso al ordenador.
•	Configuración necesaria. Indica las medidas necesarias para que el equipo sea de confianza.
•	Detalles. Describe los motivos por los que el equipo actualmente no se encuentra en un estado de confianza.
•	Coste proyectado. Indica el coste proyectado para que el equipo alcance un estado de confianza. Este coste debería incluir estimaciones de software, hardware, productividad perdida y soporte técnico. Esta información le ayudará a decidir si es práctico o vale la pena desde una perspectiva empresarial agregar un equipo determinado a la solución como equipo de confianza.

En la tabla anterior, el host HOST-NYC-001 actualmente tiene el estado "conocido, no es de confianza". No obstante, podría considerarse digno de confianza si fueran posibles las actualizaciones necesarias. Sin embargo, hay muchos equipos que requieren las mismas actualizaciones, el coste total de la solución será considerablemente más elevado.

El host SERVER-LON-001 satisface los requisitos de hardware pero deberá actualizarse a un sistema operativo que acepte la directiva IPsec y se incorpore al dominio. También requiere software antivirus. El coste proyectado se refiere al esfuerzo requerido para actualizar el sistema operativo e instalar software antivirus combinado con el coste de las licencias del sistema operativo y del software antivirus.

Tras conseguir la información que se describe en la Tabla 3.3, guárdela con el resto de información que ha recogido en este capítulo de forma que el arquitecto o equipo de diseño pueda utilizarla. Esta información constituirá la base para el Capítulo 4, que se centra en el diseño de los grupos de aislamiento.

Tenga en cuenta que los costes identificados en esta sección sólo se refieren al coste proyectado de las actualizaciones de host. Existen muchos costes adicionales de diseño, soporte técnico, evaluación y formación que se asociarán con el proyecto. Estos costes adicionales deberán considerarse en la planificación del proyecto global para averiguar el coste exacto del proyecto.

Principio de la página

Resumen

Este capítulo proporciona un resumen de la información necesaria para llevar a cabo un proyecto de aislamiento de servidor y dominio, y tiene en cuenta el impacto del proyecto. Puede utilizar la información de este capítulo para realizar las siguientes tareas:

•	Identificar los activos de la red
•	Recoger información de la red
•	Recoger información de los host
•	Determinar la información de tráfico actual
•	Examinar la arquitectura actual de Active Directory para obtener la información pertinente.
•	Examinar las consideraciones de capacidad de IPsec
•	Ver las cuestiones previas a la implementación para IPsec
•	Explicar qué son los dispositivos dignos de confianza y no dignos de confianza y la clasificación que adquieren en el escenario de Woodgrove Bank

Llevar a cabo estas tareas le proporcionará toda la información necesaria para iniciar el diseño del grupo de aislamiento en el capítulo siguiente.

Información adicional

Esta sección incluye vínculos a áreas de información adicional que pueden ser de utilidad para implementar esta solución:

•	Si desea obtener más información sobre la configuración de los servidores de seguridad para que acepten IPsec con Windows Server 2003, consulte la página de Configuración de servidores de seguridad de la documentación de Windows Server 2003 en www.microsoft.com/resources/documentation/ WindowsServ/2003/all/deployguide/en-us/ dnsbj_ips_schx.asp.
•	Puede descargar el paquete de instalación de Windows Management Instrumentation (WMI) CORE 1.5 (Windows 95/98/NT 4.0) del sitio Web del Centro de descarga de Microsoft en www.microsoft.com/downloads/details.aspx? FamilyID=afe41f46-e213-4cbf-9c5b-fbf236e0e875&DisplayLang=en.
•	Para obtener más información acerca de WMI, consulte la documentación del Instrumental de administración de Windows en MSDN® de http://msdn.microsoft.com/library/en-us/wmisdk/ wmi/wmi_start_page.asp.
•	Puede descargar Microsoft Windows Script 5.6 para Windows 2000 y XP del Centro de descarga de Microsoft en www.microsoft.com/downloads/details.aspx? FamilyId=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylang=en.
•	Puede descargar Microsoft Windows Script 5.6 para Windows 98, Windows Millennium Edition y Windows NT 4.0 del Centro de descarga de Microsoft en www.microsoft.com/downloads/details.aspx? FamilyId=0A8A18F6-249C-4A72-BFCF-FC6AF26DC390&displaylang=en.
•	Puede descargar la documentación de Windows Script 5.6 del Centro de descarga de Microsoft en www.microsoft.com/downloads/details.aspx? FamilyId=01592C48-207D-4BE1-8A76-1C4099D7BBB9&displaylang=en.

Principio de la página

4 de 13

En este artículo

•	Información general
•	Capítulo 1: Introducción al aislamiento de servidor y dominio
•	Capítulo 2: Comprensión del aislamiento de servidor y dominio
•	Capítulo 3: Cómo determinar el estado actual de su infraestructura de TI
•	Capítulo 4: Diseño y planificación de grupos de aislamiento
•	Capítulo 5: Creación de directivas IPsec para grupos de aislamiento
•	Capítulo 6: Administración de un entorno de aislamiento de servidor y dominio
•	Capítulo 7: Solución de problemas de IPsec
•	Apéndice A: Descripción general de los conceptos de la directiva IPsec
•	Apéndice B: Resumen de la directiva IPsec
•	Apéndice C: Guía de generación de laboratorio
•	Apéndice D: Categorías de amenaza de TI
•	Agradecimientos

Descargar la solución completa

Aislamiento de servidor y dominio mediante IPsec y Directiva de grupo