Aislamiento de servidor y dominio mediante IPsec y Directiva de grupo

En este capítulo se ofrecen indicaciones para definir grupos de aislamiento que cumplan los requisitos de seguridad empresariales analizados en el capítulo 2, "Comprensión del aislamiento de servidor y dominio". Esta solución utiliza una combinación entre la identidad del equipo en el dominio de servicio de directorio de Active Directory®, la directiva IPsec para autenticar esa identidad y la directiva de seguridad de Microsoft® Windows® para definir y hacer respetar los grupos de aislamiento. Los administradores de tecnología de la información (TI) pueden utilizar el concepto de grupos de aislamiento para administrar el tráfico de red en sus redes internas de un modo seguro que es transparente para las aplicaciones. Esta capacidad puede reducir significativamente la amenaza de daños por infecciones y ataques surgidos de la red.

Mediante el escenario de Woodgrove Bank, en esta guía se muestran los detalles esenciales de cómo una organización puede convertir sus requisitos de seguridad en grupos de aislamiento implementados. Además, la guía muestra cómo se puede combinar IPsec con otras configuraciones de seguridad para construir una solución de servidor y dominio detallada, fácil de administrar y escalable.

Cada organización tendrá unos requisitos únicos para su solución, y los modelos de estas instrucciones no se han concebido para aplicarlos sin cuestionarlos o modificarlos. Las organizaciones que utilicen esta guía necesitarán determinar qué es lo que se requiere y qué se puede lograr en sus propios entornos, y deberán realizar los cambios adecuados en el diseño del modelo de grupo de aislamiento para asegurarse de que se adaptan óptimamente a sus propios requisitos empresariales.

En esta página

	Requisitos previos
	Creación del diseño de aislamiento de servidor y dominio
	Métodos de implementación de grupo
	Implementación de grupo para Woodgrove Bank
	Resumen

Requisitos previos

Esta sección contiene información que ayuda a determinar el método de su organización para la solución de aislamiento de servidor y dominio. La conclusión correcta de una solución de estas características para su organización depende de los requisitos previos que se identifican en esta sección.

Requisitos previos de conocimientos

Debe estar familiarizado con los conceptos y la terminología de IPsec. También se precisa estar familiarizado con Microsoft Windows Server™ 2003 en las siguientes áreas:

Antes de continuar con este capítulo, debería haber leído los capítulos anteriores de esta guía.

Requisitos previos organizativos

Debe consultar a otros miembros de su organización que podrían necesitar implicarse en la implementación de esta solución, incluidas las siguientes personas:

Por otro lado, en este capítulo se supone que cumple los requisitos que se enumeran en el capítulo 2, "Comprensión del aislamiento de servidor y dominio," y en el capítulo 3, "Cómo determinar el estado actual de su infraestructura de TI". Estos requisitos incluyen la recuperación de información de los hosts, la red y Active Directory. También se analiza la recopilación de requisitos comerciales y la obtención de patrocinios empresariales.

Por último, debe tener preparado un plan para formar al personal de servicio de asistencia y de soporte en los nuevos conceptos, terminologías y tecnologías de esta solución. Debido a que esta solución afectará a muchas áreas de la organización, el personal de soporte debe estar preparado para encargarse de solucionar los problemas que puedan surgir durante la implementación.

Requisitos previos de la infraestructura de TI

En este capítulo se presupone la existencia de la infraestructura siguiente:

Principio de la página

Creación del diseño de aislamiento de servidor y dominio

El diseño de la solución depende fundamentalmente de la información y los requisitos empresariales recopilados en los capítulos anteriores. El capítulo 2, "Comprensión del aislamiento de servidor y dominio", y el apéndice D: "Categorías de amenaza de TI", explican los componentes de la solución e identifican las amenazas a las que puede hacer frente y a las que no. El capítulo 3, "Cómo determinar el estado actual de su infraestructura de TI", proporciona información acerca de cómo recopilar datos de planificación, como la arquitectura de red actual y los activos de host en la red. En este capítulo se utilizan la información y requisitos recopilados para Woodgrove Bank, que constan detalladamente en Business_Requirements.xls (disponible en la carpeta Herramientas y plantillas). Consulte este archivo durante el proceso de diseño que describe este capítulo para comprender mejor los motivos que llevan al diseño de la solución. El proceso de diseño de la solución implica las siguientes tareas principales:

En las siguientes secciones se explica cada una de estas tareas.

Modelado de grupos base

En la mayoría de las implementaciones, se recomienda tener un punto de partida común para los grupos de aislamiento iniciales. La siguiente figura muestra los dos grupos de aislamiento iniciales que debe considerar.

Figura 4.1 Grupos de aislamiento base

Los grupos base proporcionan contenedores lógicos que son un excelente punto de partida para el diseño de grupos de aislamiento.

Sistemas que no son de confianza

Conceptualmente, el mejor lugar para empezar son aquellos equipos que no son propiedad, ni están administrados o ni tan siquiera se conoce la existencia por parte del departamento de TI de la organización. Solemos referirnos a estos equipos como hosts que no son de confianza o que no están administrados y son los primeros sistemas que hay que identificar en el diseño. Estos equipos no formarán parte de la solución porque no podrán utilizar las directivas IPsec asignadas por el dominio.

Algunos ejemplos de equipos pertenecientes a este grupo son:

Dominio de aislamiento

El dominio de aislamiento proporciona el primer contenedor lógico para hosts de confianza. Los hosts de este grupo utilizan la directiva IPsec para controlar las comunicaciones que están permitidas hacia y desde ellos mismos. Se utiliza el término dominio en este contexto para ilustrar el límite de confianza y no tanto para sugerir un dominio de Windows. En esta solución, ambas construcciones son muy parecidas, ya que se requiere la autenticación de dominio de Windows (Kerberos) para aceptar conexiones entrantes de hosts de confianza. No obstante, muchos dominios de Windows (o bosques) pueden vincularse mediante relaciones de confianza para proporcionar un único dominio de aislamiento lógico. De modo que no deben considerarse idénticos.

La finalidad de las características de comunicación del dominio de aislamiento es proporcionar las reglas "normales" o estándar para la mayoría de los equipos de la organización. De esta manera, en la mayor parte de las implementaciones, un dominio de aislamiento contendrá la mayor cantidad de equipos. Se pueden crear otros grupos de aislamiento para la solución si sus necesidades de comunicación son distintas de las del dominio de aislamiento. Conceptualmente, un dominio de aislamiento es simplemente un tipo de grupo de aislamiento.

Grupo límite

En casi todas las organizaciones habrá una serie de estaciones de trabajo o servidores que no podrán comunicarse usando IPsec. Por ejemplo, es bastante improbable que equipos como las estaciones de trabajo Mac o UNIX puedan comunicarse usando IPsec. A menudo existen requisitos empresariales para que estos equipos se comuniquen con los hosts de confianza del dominio de aislamiento. Quizá en un mundo ideal, todos los hosts de la red interna pudieran tener el mismo nivel de confianza y utilizar IPsec; el diseño sería más sencillo. Pero la realidad es que no todos los sistemas operativos proporcionan el mismo grado de compatibilidad con IPsec.

La manera recomendada para tratar esta situación es la de crear un grupo de aislamiento (en esta guía se denomina "grupo límite") que contenga hosts con permiso para comunicarse con los sistemas que no son de confianza. Estos hosts estarán expuestos a un nivel mayor de riesgo porque pueden recibir comunicaciones entrantes directamente de los equipos que no son de confianza.

Los equipos del grupo límite son hosts de confianza que pueden comunicarse tanto con otros hosts de confianza como con hosts que no lo son. Los hosts de límite intentarán comunicarse mediante IPsec iniciando una negociación IKE con el equipo de origen. Si en tres segundos no se recibe respuesta de IKE, el host efectuará un retroceso a texto no cifrado y empezará un intento de establecer comunicación en texto sin formato sin IPsec. Los hosts del grupo límite pueden tener una dirección IP dinámica porque utilizan la directiva IPsec como lo hace cualquier otro host de confianza en el dominio de aislamiento. Debido a que estos hosts del grupo límite tendrán permiso para comunicarse con los hosts de confianza, que utilizan comunicaciones de red protegidas por IPsec, y con los hosts que no son de confianza, que utilizan el retroceso a texto no cifrado, deben estar muy protegidos de otras maneras. La comprensión y reducción de este riesgo adicional debe ser parte importante del proceso de decisión a la hora de colocar un equipo en el grupo límite. Por ejemplo, el hecho de establecer un proceso formal de justificación empresarial para cada equipo antes de acordar colocarlo en ese grupo puede ayudar a asegurar que todas las partes interesadas comprendan por qué el riesgo adicional es necesario. La siguiente figura muestra un ejemplo de proceso que puede ayudar a tomar una decisión de estas características.

Figura 4.2 Diagrama de flujo de decisión para el ejemplo del proceso de pertenencia al grupo límite
Ver imagen a tamaño completo

El objetivo de este proceso es determinar si el riesgo de agregar un host al grupo límite puede reducirse a un nivel que resulte aceptable para la organización. En última instancia, debe darse por sentado que si el riesgo no se puede reducir, debe denegarse la pertenencia al grupo.

Creación de listas de exenciones

Todos los modelos de seguridad del aislamiento de servidor y dominio se topan con unas pocas restricciones cuando se implementan en un entorno activo. Los servidores clave de la infraestructura, como los controladores de dominio, servidores DNS y servidores de protocolo de configuración dinámica (DHCP) suelen estar disponibles para todos los sistemas de una red interna. Evidentemente, deben estar protegidos al máximo contra los eventuales ataques a la red. No obstante, puesto que están disponibles para todos los sistemas de la red y no sólo para los miembros del dominio, estos servicios de servidor no pueden requerir IPsec para el acceso entrante ni tampoco pueden sacar partido de utilizar la protección del modo de transporte IPsec para todo su tráfico. Dado que un retroceso a texto no cifrado de tres segundos para acceder a estos servicios, especialmente DNS, afectaría gravemente al rendimiento de todos los accesos internos a la red, no son candidatos para el grupo límite. Los hosts de confianza también necesitan tener acceso al servidor DHCP para obtener una dirección IP (de protocolo de Internet) durante el inicio del equipo o cuando el cable o la tarjeta de red se conecta a un equipo portátil. Asimismo, los hosts de confianza precisan DNS para localizar los controladores de dominio de modo que puedan iniciar sesión en el dominio y recibir las credenciales Kerberos. Por ello, para que IPsec funcione correctamente, se requiere una lista de servidores y servicios (protocolos) que estén exentos de utilizar IPsec (también es necesaria para permitir que todos los hosts internos compartan la infraestructura común de la red interna). La lista de equipos que no pueden protegerse con IPsec se denomina lista de exenciones y se implementa en cada directiva IPsec diseñada. También puede haber otros servidores en la red a los que los hosts de confianza no puedan acceder usando IPsec; éstos se agregarán a la lista de exenciones. En general, las siguientes condiciones pueden causar que un host se encuentre en la lista de exenciones:

La implementación de IPsec en Windows sólo admite el filtrado estático, no el filtrado dinámico (o con estado). Por ello, una exención estática para el tráfico saliente también lo es para el tráfico entrante. Por esta razón, los hosts excluidos disponen de un acceso entrante no autenticado a cualquier host, a los de confianza y a los que no lo son. Así, el número de hosts excluidos debe mantenerse reducido al mínimo y esos hosts deben administrarse estrictamente, y reforzarse al máximo su protección contra ataques e infecciones. Para ayudar a reducir el riesgo de ataques entrantes procedentes de los hosts de la lista de exenciones, se puede utilizar un servidor de seguridad basado en host con filtrado con estado, como Windows Firewall. Windows XP Service Pack (SP) 2 proporciona controles de Directiva de grupo basada en dominio para configurar el servidor de seguridad. Windows Firewall también admite la capacidad de autorizar que sólo determinados equipos pasen por el servidor de seguridad si están protegidos por IPsec mediante la configuración "Windows Firewall: permitir omisión de IPsec autenticada". Woodgrove Bank optó por no implementar Windows Firewall. No obstante, en otros entornos puede resultar necesario lograr niveles altos de seguridad en el interior de un dominio o grupo aislado. Para obtener más información, consulte las notas del producto “Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2” disponibles en el Centro de descarga de Microsoft, en la dirección http://go.microsoft.com/fwlink/?LinkId=23277.

En el caso de las organizaciones grandes, la lista de exenciones puede ser bastante larga si una misma directiva IPsec implementa todas las exenciones para todo el dominio o para todos los bosques de confianza. Una lista grande presenta una serie de efectos no deseados en cada equipo que recibe la directiva, incluidos los siguientes:

Hay varias opciones para mantener reducido al mínimo el número de exenciones:

Del mismo modo que al definir el grupo límite, debe existir un proceso formal para aprobar los hosts que se agregarán a la lista de exenciones. Consulte el flujo de decisión de la figura anterior como modelo para procesar peticiones de exención.

Planificación de los grupos de equipos y de acceso de red

El dominio de aislamiento y cada grupo de aislamiento debe tener unas especificaciones claras y completas de los requisitos de seguridad de la red. La hoja de cálculo Business_Requirements.xls de la carpeta Herramientas y plantillas aporta un modelo para documentar los requisitos. Una vez que los requisitos de entrada y de salida están documentados, se pueden diseñar los mecanismos para implementar los controles de acceso.

En este punto del proceso, debe iniciarse un registro de los nuevos grupos de Active Directory que se precisarán para admitir los requisitos del grupo de aislamiento. Para cada grupo de aislamiento se deberán crear hasta tres grupos de Active Directory especializados. En la siguiente sección se explica la función de cada uno de estos grupos.

Grupos de equipos

Cada grupo de aislamiento necesitará que se cree un grupo de equipos que se utilizará para contener los miembros del grupo de aislamiento. Esto es necesario porque los requisitos de seguridad para un grupo de aislamiento se cumplen mediante varios tipos de configuraciones de seguridad en los GPO u objetos de directiva de grupo asignados del dominio. Por ejemplo, esta solución utiliza el filtrado de grupo de seguridad en los GPO para proporcionar una directiva IPsec a los equipos de un determinado grupo de aislamiento. A las cuentas de equipo que son miembros del grupo de equipos se les asignará la directiva IPsec asociada cuando se procese el GPO. Ello permite evitar la modificación o creación de una nueva estructura de unidades organizativas (OU) basada en la pertenencia al grupo de aislamiento para aplicar los GPO adecuados. Si la estructura de OU se puede cambiar para que refleje la pertenencia al grupo de aislamiento, estos grupos de seguridad de equipos no serán necesarios para controlar la aplicación de Directiva de grupo.

Tabla 4.1: Grupos de equipos de Woodgrove Bank

Grupos de acceso de red

Sólo con utilizar IPsec y Kerberos se logra un límite de autenticación entre los equipos de confianza y los que no lo son. Como ayuda para diferenciar a este grupo de cualquier otro, estos grupos se denominan en esta guía grupos de acceso de red (NAG).

Se pueden crear dos tipos de NAG: permitir y denegar. Son estos grupos los que controlan la capacidad de los otros sistemas de confianza para permitir o denegar explícitamente el acceso. Este control se consigue utilizando el derecho de usuario de Directiva de grupo "Denegar el acceso desde la red a este equipo" (DENY) o bien "Tener acceso a este equipo desde la red" (ALLOW).

Técnicamente, este control de acceso de derecho de usuario sólo se aplica a los servicios de red que reciben credenciales de inicio de sesión con el fin de autenticar la cuenta para que inicie sesión en la red. La "cuenta" puede ser una cuenta de equipo, de usuario o de servicio. Cuando la directiva IPsec está configurada para proteger todo el tráfico, IKE confirmará que el equipo remoto dispone de un derecho de inicio de sesión en la red. Por esta razón, el derecho de inicio de sesión en la red controla ahora la capacidad de un equipo remoto de realizar cualquier conexión protegida por IPsec. Una vez que se ha comprobado este control de acceso de nivel de IP, suelen ser los protocolos de capa superior (por ejemplo, uso compartido de archivos) los que autentican al usuario, los cuales a su vez evalúan los derechos de inicio de sesión en la red de la identidad de usuario. Por último, se evalúan los permisos específicos del servicio (como las listas de control de acceso para el uso compartido de archivos) mediante la identidad del usuario. Para obtener más información, consulte el diagrama de las capas de control de acceso a la red del capítulo 2, "Comprensión del aislamiento de servidor y dominio".

De forma predeterminada, el derecho de usuario ALLOW contiene el grupo Todos, que permite que todos los usuarios y equipos autenticados accedan a ese equipo. Durante la implementación de esta solución, el grupo Todos se reemplazará, mediante la asignación de derechos de usuario de Directiva de grupo, por NAG que contienen equipos específicos o usuarios y grupos, según los requisitos organizativos. Del mismo modo, el derecho de usuario DENY tendrá equipos que no deberán disponer de acceso entrante protegido por IPsec. Aunque se puede utilizar un único grupo que contenga cuentas de usuario y de equipo, Microsoft recomienda que se usen grupos separados, uno para usuarios y otro para equipos. Este método mejora la capacidad de administrar y admitir estas directivas y grupos de forma continuada. La configuración de la asignación de derechos de usuario para ALLOW y DENY complementa las instrucciones que proporcionaban anteriores guías de seguridad de la plataforma Windows, porque esas guías no estaban específicamente adaptadas a la autenticación de equipos que requiere IPsec.

Los requisitos que pueden implementar los NAG incluyen los siguientes:

En el escenario de Woodgrove Bank, uno de los requisitos empresariales establecía un límite para la cantidad de nuevo hardware que podía adquirirse al año. Se necesitaba un servidor de impresión para permitir que tanto los hosts de confianza como los hosts que no son de confianza pudieran imprimir. Aunque Woodgrove hubiera preferido adquirir un servidor nuevo para uso único de los equipos que no son de confianza, decidió que un mismo servidor podría satisfacer las necesidades de ambos tipos de host. Por ello, creó un servidor límite como servidor de impresión. Debido a que el servidor de impresión estaba expuesto a un mayor riesgo de ser infectado o atacado por equipos que no fueran de confianza, el resto de hosts de confianza necesitaba bloquear el acceso entrante desde ese servidor. Los hosts de confianza aún podrían realizar conexiones salientes al servidor de impresión cuando fuera preciso. Por consiguiente, Woodgrove determinó que necesitaba un grupo de acceso de red (NAG) DENY para implementar este requisito.

En este paso del proceso de diseño, no es necesario asignar la pertenencia al NAG. Lo único que se necesita es identificar y documentar los NAG que necesitará el diseño. Los diseñadores de Woodgrove Bank identificaron la necesidad de los siguientes NAG:

Tabla 4.2: Grupos de acceso de red de Woodgrove Bank

Creación de grupos de aislamiento adicionales

En este punto del proceso de diseño, hay dos grupos de aislamiento: el dominio de aislamiento y el grupo límite.

Si este diseño satisface los requisitos empresariales de su organización, puede pasar a la siguiente sección de este capítulo para definir los modelos de tráfico para los dos grupos de aislamiento. No obstante, si su organización necesita que alguno de los hosts de confianza disponga de unos controles de acceso a la red entrante o saliente, o de una protección de tráfico diferentes, se precisarán grupos de aislamiento para cada conjunto distinto de requisitos.

La finalidad de esta sección es la de ayudar a comprender cuándo se necesitan grupos adicionales. Lo primero que hay que hacer es identificar qué equipos tienen necesidades específicas de aislamiento o protección de tráfico que no quedan satisfechas por las configuraciones del dominio de aislamiento. El objetivo debe ser el de mantener reducido al mínimo el número de estos hosts, ya que cada grupo nuevo aumentará la complejidad del diseño global y, por lo tanto, más difícil será el soporte técnico y la administración.

Algunos ejemplos típicos de requisitos que pueden llevar a la creación de un grupo nuevo son los siguientes:

En muchas ocasiones, los requisitos de acceso entrante de servidores que contienen datos de gran valor suelen ser los de permitir que se conecte únicamente un subconjunto de hosts de confianza del dominio. En otras, los hosts de confianza pueden no tener permiso para realizar conexiones salientes con equipos que no son de confianza, con tal de reducir el riesgo de filtración de información o de imponer el cumplimiento normativo para proteger el tráfico de red. Por ejemplo, en el escenario de Woodgrove Bank, los diseñadores identificaron requisitos que sólo se podían cumplir si se creaban los dos siguientes grupos de aislamiento adicionales:

Aunque el segundo grupo tenga un requisito de "sin reserva", los equipos no tienen el conjunto completo de requisitos que tienen los servidores de aplicaciones. Por lo tanto, estos dos conjuntos diferentes de requisitos indicaban que se necesitaban dos grupos de aislamiento adicionales. Con estos grupos adicionales, el total de grupos de Woodgrove Bank ascendía a cuatro. La siguiente figura muestra el aspecto de estos grupos en el diseño definitivo del grupo de aislamiento de Woodgrove Bank:

Figura 4.3 Diseño definitivo de los grupos de Woodgrove Bank

Los siguientes cuatro grupos precisan directivas para lograr los requisitos de diseño:

Debido a que Woodgrove Bank identificó dos grupos adicionales que requerían directivas IPsec, se definieron unos grupos de equipos adicionales para controlar la aplicación de esas directivas recientemente identificadas.

Tabla 4.3: Grupos de equipos adicionales de Woodgrove Bank

Por consiguiente, Woodgrove determinó que iba a necesitar grupos de acceso de red (NAG) para autorizar el acceso entrante para el subconjunto de hosts de confianza. Los diseñadores de Woodgrove Bank crearon los siguientes NAG:

Tabla 4.4: Grupos de acceso de red de Woodgrove Bank

Recopilación de requisitos de tráfico de red

En este punto del proceso de diseño, deben documentarse los requisitos de tráfico de las comunicaciones autorizadas a pasar por los grupos, junto con la forma que tendrán dichas comunicaciones. Hay muchas maneras de registrar los requisitos de tráfico de los grupos. No obstante, el equipo de soporte técnico de TI de Microsoft llegó a la conclusión, basándose en su propia experiencia, de que la creación de un diagrama era el mejor método de comunicar los requisitos exactos.

La siguiente figura muestra las rutas de comunicación que suelen estar autorizadas entre los grupos base, los hosts que no son de confianza y las listas de exenciones. Para simplificar el modelo, las listas de exenciones se muestran como una única agrupación. Éste suele ser el caso de los servicios de infraestructura, como los controladores de dominio o los servidores DNS. No obstante, los grupos de aislamiento pueden tener requisitos empresariales para excluir determinados equipos, sólo para los equipos de ese grupo. En estos casos, el grupo de aislamiento contendría una lista de exenciones adicional con los equipos que deben excluirse, además de las exenciones comunes. Microsoft recomienda mantener la lista de exenciones con el mínimo posible de entradas porque se excluyen sistemas explícitamente de su participación en la infraestructura IPsec. En la figura, todas las flechas que presentan una línea negra continua utilizan IPsec en sus comunicaciones; las líneas discontinuas indican comunicaciones que tienen autorización para llevarse a cabo sin IPsec. Los grupos que se muestran con una línea discontinua gruesa tienen asignada una directiva IPsec a los equipos de ese grupo.

Figura 4.4 Rutas de comunicación habitualmente autorizadas para los grupos de aislamiento base
Ver imagen a tamaño completo

La siguiente tabla muestra las rutas de comunicación autorizadas para el tráfico entre los grupos base, los sistemas no seguros y las listas de exenciones:

Tabla 4.5: Opciones de comunicación autorizadas para los grupos de aislamiento base

La tabla anterior registra los requisitos de comunicación de cada ruta de comunicación autorizada en el diseño inicial del grupo de aislamiento. La siguiente lista explica cada columna:

Se ha utilizado la versión breve de los nombres de grupo para que la información de la tabla sea lo más concisa posible. Al utilizar esta forma de documentación, se puede crear una representación muy concisa de las comunicaciones de la solución. Al suponer que cualquier tráfico de red no está permitido a menos que se indique especialmente en esta tabla, el proceso de identificación del tráfico que estará protegido como parte de la solución resulta mucho más claro. En el ejemplo mostrado en la figura anterior, se explica cada una de las siguientes rutas autorizadas:

Después de haber documentado las comunicaciones base, se pueden agregar grupos adicionales al plan general y registrar sus requisitos de comunicación del mismo modo. Por ejemplo, los dos grupos adicionales que precisaba el escenario de Woodgrove Bank dieron como resultado un diagrama de comunicaciones más complejo, como se muestra en la figura siguiente.

Figura 4.5 Rutas de comunicación permitidas por Woodgrove Bank para los grupos de aislamiento
Ver imagen a tamaño completo

La siguiente tabla muestra las rutas de comunicación autorizadas para el tráfico en los grupos adicionales para el escenario de Woodgrove Bank.

Tabla 4.6: Opciones de comunicación autorizadas para los grupos de aislamiento adicionales

En el ejemplo que se muestra en la figura anterior y descrito en la tabla, se explica cada una de las rutas de acceso adicionales autorizadas:

Como muestra este ejemplo, el hecho de agregar grupos puede tener un impacto exponencial en la complejidad de la solución. Por este motivo, se recomienda mantener al mínimo el número de grupos, especialmente durante las etapas tempranas de una implementación, que es cuando se introducen la mayoría de los cambios.

Asignación de pertenencia a grupo de equipos y a grupo de acceso de red (NAG)

Una vez que los requisitos de tráfico se han detallado y documentado en el diseño, la tarea siguiente es la de identificar los hosts que serán miembros de cada grupo de equipos o cada NAG.

Como ya se ha mencionado anteriormente, los grupos de equipos se usan en esta solución para aplicar el GPO u objeto de directiva de grupo que contiene la directiva IPsec asociada. Después de haber determinado que un equipo debe pertenecer a un determinado grupo de aislamiento, la cuenta de ese equipo se agrega al grupo de equipos de ese grupo de aislamiento. Este paso no es necesario para el dominio de aislamiento porque todos los equipos del dominio pertenecen implícitamente al grupo de equipos del dominio de aislamiento.

La pertenencia a un NAG se basará en la autorización entrante que implementa dicho NAG. Por ejemplo, si existe un NAG para restringir la comunicación de un servidor en particular a un conjunto conocido de clientes, las cuentas del equipo cliente deben ubicarse en el NAG adecuado. Los NAG sólo se crean cuando se necesitan, por lo que no tienen una configuración predeterminada.

Pertenencia a grupo de equipos

Es importante que cada host no se represente en más de un grupo de equipos porque el grupo de equipos se usa para controlar los GPO que se aplican. Aunque teóricamente es posible modificar las directivas para permitir que un host pertenezca a más de un grupo de equipos, la complejidad de un enfoque de estas características haría que la solución fuera rápidamente incompatible.

Generalmente, la tarea de determinación de la pertenencia a grupos por parte de los equipos no es complicada pero puede ser laboriosa. Utilice la información generada por una auditoría, como la realizada en el capítulo 3, "Cómo determinar el estado actual de su infraestructura de TI", de esta guía para ubicar cada host en un grupo de equipos, basándose en la pertenencia al grupo de aislamiento de dicho host. Puede determinar esta ubicación agregando una columna Grupo para registrar la pertenencia al grupo de equipos para el diseño definitivo, como se muestra en la tabla siguiente:

Tabla 4.7: Ejemplo de recopilación de datos de host

Pertenencia a grupo de acceso de red

El paso final de este proceso de diseño es el de rellenar la pertenencia a los NAG o grupos de acceso de red identificados previamente en este capítulo. Aunque un host de confianza sólo debería pertenecer a un grupo de equipos, es posible que un host de confianza sea miembro de varios NAG. Intente utilizar el menor número de NAG posible para limitar la complejidad de la solución.

Cuando asigne la pertenencia a un NAG de las cuentas de usuario, decida con cuánto rigor desea controlar el acceso. De forma que pueda asegurarse que para un recurso con los permisos estándar de acceso a archivos y recursos compartidos exista el nivel de control correcto, el modo más sencillo de asignar la pertenencia sería asignar la pertenencia al NAG del usuario a los usuarios del dominio de cada dominio de confianza del bosque que requieran acceso a dicho recurso. Este método casi restablece el comportamiento del valor predeterminado original de los usuarios autenticados pero no incluye las cuentas de usuario locales. Si se necesitan cuentas de usuario o servicio locales, un GPO u objeto de directiva de grupo basado en el dominio puede no ser el mejor método para configurar los derechos ALLOW y DENY de inicio de sesión en la red. La asignación de derechos de usuario ALLOW y DENY no combina las configuraciones de los distintos GPO. Por ello, deberá evitarse que se asigne a este equipo el GPO basado en el dominio para ALLOW y DENY, y el equipo deberá utilizar un GPO local personalizado. Aunque el GPO basado en el dominio que proporciona la asignación de la directiva IPsec sea distinto al GPO usado para proporcionar los derechos de inicio de sesión en la red, se puede continuar usando para la asignación de la directiva IPsec.

Además, decida cómo implementar los requisitos de acceso entrante mediante un grupo de acceso de red ALLOW o uno DENY, o ambos. La decisión acerca del tipo de NAG que se va a crear se basa únicamente en el comportamiento previsto y en reducir al mínimo el esfuerzo administrativo. Puede resultar de ayuda disponer de un grupo de acceso de red DENY preexistente pero vacío para los usuarios y otro NAG DENY para los equipos ya rellenado en el derecho "Denegar el acceso desde la red a este equipo" del GPO.

Para los escenarios de alta seguridad, la pertenencia de los NAG de usuario puede asignarse a determinados usuarios o grupos. Si se utiliza este método, debe comprenderse que a los usuarios que no son miembros de este grupo se les bloqueará el acceso al equipo a través de la red, incluso si son miembros del grupo de administradores local y disponen de control total en todos los permisos de recursos compartidos y archivos.

En el caso del escenario de Woodgrove Bank, se asignó la pertenencia a NAG_EncryptedResourceAccess_Users a los usuarios del dominio y se registró tal como se muestra en la tabla siguiente:

Tabla 4.8: Grupos de acceso de red de Woodgrove Bank con pertenencia asignada

Nota: la pertenencia a un NAG no controla el nivel de protección de tráfico IPsec. La configuración de la directiva IPsec controla los métodos de seguridad utilizados para proteger el tráfico y es independiente de la identidad autenticada por IKE. La negociación IKE sólo considera si la identidad del equipo Kerberos pasa o no el proceso de autenticación. No puede implementar una directiva del tipo "cifrar si user3 se conecta" o "cifrar si el host de confianza es IPS-SQL-DFS-01 o IPS-SQL-DFS-02". El administrador debe lograr el comportamiento previsto utilizando una directiva IPsec para los servidores del grupo de aislamiento de cifrado que requiera "cifrado para cualquier conexión entrante de host de confianza" y también "cifrado para cualquier conexión saliente con un host de confianza".

Hasta ahora, el proceso de diseño no ha revisado los detalles del diseño de la directiva IPsec. El capítulo 5 aportará detalles del diseño de la directiva IPsec para Woodgrove.

En este punto del proceso de diseño, se han concluido las tareas necesarias para convertir los requisitos en un esbozo del diseño. Esta sección le ha ayudado ha desarrollar la documentación y el diseño necesarios para crear las directivas IPsec.

Limitaciones que pueden afectar al diseño

Los siguientes problemas pueden afectar al diseño y, por lo tanto, deben considerarse antes de que dicho diseño pueda darse por terminado:

Si su diseño se ve afectado por estos problemas, tendrá que repasar el proceso de diseño para solucionarlos. Podría, por ejemplo, solucionar el problema del número máximo de conexiones simultáneas desplazando un servidor muy cargado a las listas de exenciones. Podría resolver la limitación del tamaño máximo del símbolo de Kerberos reduciendo el número de NAG que utilizará su diseño.

Si estas limitaciones no afectan a su diseño, la siguiente tarea es la de considerar cómo se implementará el diseño en la organización.

Principio de la página

Métodos de implementación de grupo

Una vez creado el diseño inicial, debe considerar detenidamente el proceso de implementación de IPsec. Sólo en los entornos más pequeños cabe implementar simplemente las directivas en todos los equipos y esperar que IPsec funcione correctamente con un impacto aceptablemente pequeño en los usuarios.

En las organizaciones grandes, la complejidad y el riesgo exigen una estrategia de implementación por fases. Al usar un método de estas características, la organización puede ayudar a reducir el riesgo asociado a un cambio tan fundamental en el entorno. Sin una planificación cuidadosa, las llamadas al servicio de asistencia y la pérdida de productividad aumentarán rápidamente el coste de la implementación.

Hay una serie de maneras de implementar IPsec en una organización. Algunos de los factores que ayudan a determinar el método de implementación son:

Los siguientes métodos de implementación no lo incluyen todo pero aportan ejemplos de enfoques factibles que pueden plantearse. También puede combinar varios de estos métodos. Por regla general, las organizaciones no deben implementar directivas IPsec que restrinjan o bloqueen la comunicación inicialmente para asegurarse de que se dispone del tiempo suficiente para solucionar los problemas y reducir la coordinación administrativa en entornos complejos.

Independientemente del método que se utilice para implementar IPsec, es muy recomendable probar a fondo el escenario de la implementación en un entorno de laboratorio, incluidas la secuencia y la programación de los pasos de la ejecución y los cambios de directiva. Además, utilice una acción de filtrado que solicite la funcionalidad IPsec pero acepte la comunicación en texto sin formato mediante el uso del retroceso a texto no cifrado. Este método ayudará a minimizar el impacto de la ejecución inicial. Una vez que la ejecución haya concluido, pase a modos de funcionamiento más seguros que requieran la protección del tráfico mediante IPsec.

Para una implementación en un entorno de producción, es muy recomendable realizar una prueba piloto de cada fase principal de la ejecución. Es especialmente importante analizar el impacto de los cambios de directiva IPsec porque tendrán lugar en el entorno de producción como resultado de las vigencias del vale Kerberos, de los intervalos de sondeo de Directiva de grupo y de los intervalos de sondeo de la directiva IPsec. Debe implementar un proceso formal de control de cambios, con estrategias y criterios de restauración, para garantizar que todas las organizaciones de TI afectadas sean conscientes del cambio y su impacto, y sepan cómo coordinar los comentarios a los responsables de la toma de decisiones.

Implementación por grupo

El método de implementación por grupo utiliza directivas IPsec completamente definidas pero controla la aplicación de las mismas mediante el uso de grupos y ACL en los GPO u objetos de directiva de grupo que proporcionan las directivas.

En el método de implementación por grupo, las directivas IPsec se crean en Active Directory con su configuración final. Cada directiva IPsec tiene todas las exenciones y subredes seguras definidas con las acciones de filtrado apropiadas habilitadas.

A continuación, los administradores de directivas IPsec crean los GPO para cada directiva IPsec. Se crean, además, grupos de equipos en el dominio para administrar y aplicar estos GPO recién creados. Las ACL o listas de control de acceso de los GPO se modifican, de modo que los miembros de usuarios autenticados ya no tendrán el derecho de "aplicar". También se conceden derechos para el GPO a los grupos de usuarios administradores adecuados para la administración y aplicación de la directiva.

Después, se asignan las directivas IPsec adecuadas al GPO correspondiente. Además, el GPO se vincula con el objeto adecuado en Active Directory. En este momento, ninguno de los equipos del entorno debería recibir la directiva, puesto que las ACL que controlan la asignación del GPO (la capacidad de leer el GPO) están vacías.

Por último, se identifican los equipos que recibirán las directivas y sus cuentas de equipo se ubican en los grupos de equipos adecuados con acceso de lectura al GPO. Después de que los vales Kerberos del equipo se hayan actualizado con la información de pertenencia al grupo, el GPO, junto con su correspondiente directiva IPsec, se aplicará durante el siguiente intervalo de sondeo de Directiva de grupo.

Nota: no se recomiendan las ACL que restringen la lectura de los objetos de la directiva IPsec o de los contenedores de directivas IPsec en Active Directory por parte de los equipos del dominio.

Pongamos como ejemplo una organización que ha definido dos directivas IPsec: IPsec estándar y Cifrado IPsec. La directiva IPsec estándar es su directiva predeterminada y requiere que el tráfico entrante utilice IPsec, pero también permite que los sistemas retrocedan a texto no cifrado si inician comunicación con un equipo que no esté basado en IPsec. La directiva Cifrado IPsec requiere que siempre se negocie el IPsec cifrado.

En el ejemplo, la administración de la organización crea dos GPO en Active Directory: el GPO IPsec estándar y el GPO Cifrado IPsec. Además, los grupos se identifican en la tabla siguiente:

Tabla 4.9: Grupos de administración de IPsec

Las ACL de los dos GPO recién creados se actualizan para que no se apliquen automáticamente al grupo de usuarios autenticados y de modo que los grupos de aplicaciones y grupos de administración adecuados reciban los derechos correctos. La administración modificó las ACL de ambos GPO según la información que consta en la tabla siguiente:

Tabla 4.10: Derechos de grupo en los GPO

Nota: esta tabla sólo muestra los permisos agregados o modificados. También habrá otros grupos adicionales con permisos.

Los administradores vincularon ambos GPO con el dominio de Active Directory. Este método garantiza que la directiva se aplicará en todos los equipos del dominio sin modificar su ubicación (a no ser que el equipo esté ubicado en una OU que bloquee las directivas).

A medida que se identifican los equipos, se agregan sus cuentas de equipo al grupo IPsecSTD o al grupo IPsecEnc. Pasado un tiempo, la directiva IPsec correspondiente se aplicará y estará vigente.

Este método precisa una planificación cuidadosa para garantizar que no se interrumpen las comunicaciones. Por ejemplo, si se ha colocado un servidor en el grupo IPsecEnc pero varios clientes que dependían de dicho servidor no han podido negociar IPsec, se interrumpirán las comunicaciones entre esos clientes y el servidor.

Implementación por generación de directivas

Este método utiliza una técnica en la que las directivas IPsec pueden generarse desde cero durante la implementación. La ventaja de este método es que IPsec sólo se negocia para un pequeño porcentaje de todo el tráfico TCP/IP, en lugar de negociarse para todas las subredes internas, como en el método de implementación por grupo. También permite probar todas las rutas de red de la red interna hacia esta subred de destino para asegurarse de que no existen problemas a la hora de que la red acepte la negociación IKE y el tráfico protegido por IPsec. Una ventaja adicional es que el intervalo de sondeo para IPsec puede proporcionar con mayor rapidez las actualizaciones de directivas IPsec (incluida la restauración), en lugar de tener que depender de los cambios de la pertenencia al grupo de los vales TGT (vale de concesión de vales) o de servicio de Kerberos. El inconveniente de este método es que se aplica a todos los equipos del dominio o grupo de aislamiento y no a equipos específicos, como en el método de implementación por grupo. Asimismo, todos los equipos presentarán un retraso de tres segundos para el retroceso a texto no cifrado en algún punto de la comunicación con las subredes especificadas.

En este método de implementación, las directivas IPsec sólo incluyen excepciones al principio; en la directiva IPsec no existen reglas para que los equipos negocien la seguridad. Este método prueba y garantiza en primer lugar que cualquier directiva IPsec local existente que pueda estar en uso se haya eliminado. El equipo de administración debe ser capaz de identificar por adelantado los hosts que utilizaban las directivas IPsec definidas localmente para administrar esos sistemas en un proceso especial. Si una directiva de dominio sustituye a una directiva IPsec local, podrían producirse interrupciones de comunicación y darse una pérdida de seguridad en los equipos afectados. A diferencia de las directivas locales que se sustituyen al aplicar la directiva de dominio, las directivas persistentes de Windows Server 2003 se combinan con el resultado de aplicar la directiva de dominio. Un sistema que contiene una directiva persistente aparentemente funciona, pero la configuración de la directiva persistente puede cambiar el comportamiento o reducir verdaderamente la seguridad proporcionada por la directiva de dominio, o bien interrumpir las comunicaciones después de que las reglas de subred seguras se hayan agregado a la directiva.

A continuación, puede crear una regla de seguridad con un filtro que afecte sólo a una subred dentro de la red de la organización, por ejemplo, "Todo el tráfico desde cualquier IP a subred A, negociar". Esta regla aplicaría una acción de filtrado para aceptar el texto sin formato entrante y activaría las negociaciones para todo el tráfico entrante a esa subred, con el retroceso a texto no cifrado habilitado. A medida que se aplica la ejecución de esta directiva IPsec en todos los dominios, las comunicaciones pasarán gradualmente de las asociaciones de seguridad por software a las asociaciones de seguridad IPsec normales para los hosts de confianza de únicamente esa subred. Cualquier error de la negociación IKE se investiga y resuelve. Se identifica y subsana cualquier incompatibilidad de aplicación. IPsec protegerá la comunicación entre hosts de confianza en esa subred. La comunicación con los hosts de confianza en el exterior de esa subred hará un retroceso a texto no cifrado después del retraso de tres segundos. Se van agregando las subredes adicionales a la regla de protección hasta que la directiva se haya generado y haya alcanzado su estado final.

Pongamos como ejemplo una organización que tiene una única directiva IPsec definida, denominada directiva IPsec estándar, que solicita la negociación IPsec pero no tiene en cuenta la comunicación de retroceso a texto no cifrado. La directiva se crea en Active Directory y sólo contiene reglas de exención.

Se crea el GPO IPsec estándar y se vincula de modo que se aplique a todos los equipos del entorno. Además, se asigna la directiva IPsec estándar a este GPO nuevo.

Finalmente, se asigna la directiva IPsec a todos los equipos. Se detectará cualquier problema que surja con las directivas IPsec locales porque esta directiva de dominio sustituirá las directivas locales existentes. Los problemas se van resolviendo continuamente hasta que todas las subredes consten en la lista de filtros Subredes seguras.

Principio de la página

Implementación de grupo para Woodgrove Bank

Woodgrove Bank optó por realizar su implementación en producción, desplazando en primer lugar todos los equipos al grupo límite mediante el método de generación. Este método permitió a los administradores avanzar lentamente y resolver cualquier problema pendiente sin que ello afectara de manera significativa a las comunicaciones entre todos los sistemas. Al implementar en primer lugar una directiva sin ninguna subred segura, el equipo de administración fue capaz de identificar todos los sistemas que tenían asignada una directiva IPsec local y aprovechó esa información para considerarla adicionalmente. A medida que se iban agregando las subredes a la directiva, se iban resolviendo todos los conflictos que surgieron.

Una vez que los equipos funcionaban regidos por la directiva del grupo límite, el equipo implementó el dominio de aislamiento, los grupos sin reserva y de cifrado. Para la implementación de estos grupos se utilizó el método de implementación por grupo. Se seleccionó un conjunto de equipos para una prueba piloto y se agregó a los grupos apropiados que controlaban las directivas nuevas. A medida que surgían, los problemas se fueron resolviendo y se agregaron otros equipos a los grupos hasta que éstos estuvieron completamente llenos.

La siguiente tabla enumera los grupos de equipos y los NAG, así como su pertenencia al grupo una vez que la solución está completamente implementada:

Tabla 4.11: Pertenencia a grupo de equipos y a grupo de acceso de red

Tenga en cuenta que el grupo ANAG_EncryptedResourceAccess_Computers contiene los servidores que se encuentran en el grupo de aislamiento cifrado. Esto es así para que puedan comunicarse con ellos mismos y entre ellos, según se precise. Si estos servidores no requieren esta comunicación, no es necesario agregarlos a este grupo.

Principio de la página

Resumen

En este capítulo se ha descrito el proceso de diseño de una solución de aislamiento de servidor y dominio. Las tareas incluían identificar la necesidad de grupos de equipos y NAG, comprender los grupos de aislamiento base, agregar grupos de aislamiento adicionales, completar un modelo de tráfico, asignar la pertenencia a los grupos y planificar el método de ejecución de la implementación..

En el capítulo también se ha utilizado la implementación de IPsec en Woodgrove Bank, una organización ficticia, para ayudar a ilustrar el diseño del proceso en la práctica y para demostrar el diseño en los laboratorios de pruebas de Microsoft.

El diseño de grupos se ha basado en los requisitos empresariales y la información obtenida en los dos capítulos anteriores y documentada en la hoja de cálculo Business_Requirements.xls (disponible en la carpeta Herramientas y plantillas). La apreciación del impacto de IPsec en una red también ha sido una consideración importante.

Una vez leído este capítulo, debería tener suficiente información para empezar a planificar los grupos de aislamiento, a documentar las necesidades de comunicación entres estos grupos y a planificar la directiva IPsec de alto nivel. Estas tareas le prepararán para el capítulo 5, "Creación de directivas IPsec para grupos de aislamiento".

Información adicional

En esta sección se ofrecen vínculos a información complementaria que puede resultar útil al implementar esta solución.

IPsec

Los siguientes vínculos proporcionan un amplio abanico de contenido relacionado con IPsec específico de Windows:

Seguridad

Windows Server 2003 Active Directory

Para obtener más información acerca de Active Directory, consulte:

Principio de la página

5 de 13