En este artículo, se describen los requisitos que debes tener en cuenta cuando implementas Active Directory en Google Cloud y te ayuda a elegir la arquitectura adecuada.
Mediante la federación de Active Directory con Cloud Identity o Google Workspace (consulta el artículo asociado), puedes permitir que los usuarios de tus dominios de Active Directory existentes se autentiquen y accedan a recursos en Google Cloud. También puedes implementar Active Directory en Google Cloud si planeas usar Active Directory para administrar servidores de Windows en Google Cloud o si usas protocolos que no son compatibles con Google Cloud.
Antes de implementar Active Directory en Google Cloud, debes decidir qué arquitectura de bosque y dominio usar, además de cómo integrarla a tu bosque de Active Directory existente.
Evaluación de los requisitos
Active Directory admite una variedad de arquitecturas de dominio y de bosque. En un entorno híbrido, una opción es extender un solo dominio de Active Directory entre varios entornos. Si no, puedes usar dominios o bosques separados y conectarlos mediante relaciones de confianza. Tus requisitos determinarán cuál es la mejor arquitectura para tu caso.
Para elegir la mejor arquitectura, considera estos factores:
- Alineación con las zonas de seguridad existentes
- Interacción entre recursos locales y recursos de Google Cloud
- Autonomía administrativa
- Disponibilidad
Estos factores se analizan en las siguientes secciones.
Alineación con las zonas de seguridad existentes
Comienza por revisar el diseño de tu red local.
En tu entorno local, es posible que hayas segmentado tu red en varias zonas de seguridad (por ejemplo, mediante VLAN o subredes independientes). En una red segmentada en zonas de seguridad, la comunicación dentro de una zona de seguridad puede ser irrestricta o estar sujeta solo a políticas de firewall y auditoría básicas. En cambio, toda comunicación que cruce de una zona de seguridad a otra está sujeta a políticas de firewall, auditoría o inspección de tráfico estrictas.
Sin embargo, las zonas de seguridad no existen solo para limitar y auditar la comunicación de red; deben implementar límites de confianza.
Límites de confianza
Cada máquina de una red ejecuta varios procesos. Estos procesos pueden comunicarse entre sí a nivel local mediante la comunicación entre procesos y pueden comunicarse a través de máquinas mediante protocolos como HTTP. En esta red de comunicación, los pares no siempre se tienen la misma confianza. Por ejemplo, es posible que un proceso confíe más en los procesos que se ejecutan en la misma máquina que en los que se ejecutan en otras. Además, algunas máquinas pueden considerarse más confiables que otras.
Un límite de confianza implica discriminar entre los participantes de una comunicación y confiar más en algunos que en otros.
Los límites de confianza son fundamentales para contener el impacto de un ataque. Los ataques rara vez se terminan una vez que un solo sistema se ve vulnerado, ya sea que se trate de un proceso aislado o de una máquina entera. Por el contrario, es probable que el responsable de un ataque intente extenderlo a otros sistemas. Como los sistemas que se encuentran dentro de un límite de confianza no discriminan entre sí, es más fácil propagar un ataque dentro de ese límite de confianza que atacar sistemas ajenos a este.
Una vez que un sistema dentro de un límite de confianza se encuentra vulnerado, debe suponerse que todos los otros sistemas de ese límite de confianza también están vulnerados. Esta suposición puede ayudarte a identificar los límites de confianza o validar si determinado límite del sistema es un límite de confianza. Considera el siguiente ejemplo:
Supongamos que un atacante alcanzó el nivel de acceso más alto al objetivo A (por ejemplo, acceso raíz o de administrador a una máquina o aplicación). Si puede aprovechar estos privilegios para obtener el mismo nivel de acceso al objetivo B, significa que A y B están, por definición, dentro del mismo límite de confianza. De lo contrario, hay un límite de confianza entre A y B.
Mediante la limitación de la comunicación de red, las zonas de seguridad pueden ayudar a implementar límites de confianza. Sin embargo, para que una zona de seguridad se convierta en un verdadero límite de confianza, las cargas de trabajo de cada lado del límite deben discriminar entre las solicitudes que se originan en la misma zona de seguridad y las que se originan en otras zonas de seguridad, a fin de analizar estas últimas con mayor detenimiento.
Modelo de confianza cero
El modelo de confianza cero es el modelo de redes preferido en Google Cloud.
Si hay un solo sistema vulnerado en un límite de confianza, puedes suponer que todos los sistemas del límite están vulnerados. Este supuesto sugiere que es mejor tener límites de confianza más pequeños. Cuanto más reducido es el límite de confianza, menos sistemas se ven vulnerados y más son los límites que debe superar una persona malintencionada para propagar su ataque.
El modelo de confianza cero lleva esta idea a su conclusión lógica: Cada máquina de la red se trata como una zona de seguridad y un límite de confianza único. Todas las comunicaciones entre las máquinas están sujetas al mismo grado de escrutinio y control mediante firewall, y todas las solicitudes de red se tratan como provenientes de una fuente no confiable.
En el nivel de red, puedes implementar un modelo de confianza cero con reglas de firewall que restrinjan el tráfico y registros de flujo de VPC, junto con registros de reglas de firewall que analicen el tráfico. En el nivel de la aplicación, debes asegurarte de que todas las aplicaciones manejen la autenticación, la autorización y la auditoría de manera uniforme y segura.
Límites de confianza en Active Directory
En un dominio de Active Directory, las máquinas confían en los controladores de dominio para que manejen la autenticación y la autorización en su nombre. Una vez que un usuario prueba su identidad frente a uno de los controladores de dominio, puede iniciar sesión de manera predeterminada en todas las máquinas del mismo dominio. Todos los derechos de acceso que el controlador de dominio le otorga al usuario (en forma de privilegios y membresías de grupo) se aplican a muchas máquinas del dominio.
Con las políticas de grupo, puedes limitar el acceso o los derechos de los usuarios en determinadas máquinas. Sin embargo, una vez que una máquina está vulnerada, un atacante podría robar contraseñas, hashes de contraseña o tokens de Kerberos de otros usuarios del dominio que hayan iniciado sesión en la misma máquina. Luego, el agresor puede aprovechar estas credenciales para propagar el ataque a otros dominios del bosque.
Teniendo en cuenta estos factores, es mejor suponer que todas las máquinas de un bosque se encuentran en un límite de seguridad de confianza.
En comparación con los límites de los dominios, cuyo propósito es controlar la replicación y otorgar autonomía administrativa a diferentes partes de la organización, los límites de los bosques pueden proporcionar un aislamiento más sólido. Los bosques pueden funcionar como un límite de confianza.
Alinea las zonas de seguridad y los bosques de Active Directory
Tomar el bosque como límite de confianza influye en el diseño de las zonas de seguridad. Si un bosque comprende dos zonas de seguridad, es más fácil para un atacante superar el límite que las separa. Como consecuencia, las dos zonas de seguridad se convierten, en la práctica, en una sola, con un solo límite de confianza.
En un modelo de confianza cero, cada máquina de una red puede considerarse una zona de seguridad aparte. La implementación de Active Directory en una red de este tipo socava este concepto y amplía el límite de seguridad en la práctica, de modo que este abarque todas las máquinas del bosque de Active Directory.
Para que una zona de seguridad funcione como límite de confianza, debes asegurarte de que todo el bosque de Active Directory esté en la zona de seguridad.
Impacto en la extensión de Active Directory a Google Cloud
Cuando planificas una implementación en Google Cloud que requiere Active Directory, debes decidir entre dos opciones para alinear la implementación con tus zonas de seguridad existentes:
Extender una zona de seguridad existente a Google Cloud: Puedes extender una o más de tus zonas de seguridad existentes a Google Cloud si aprovisionas una VPC compartida en Google Cloud y la conectas a la zona existente mediante Cloud VPN o Interconnect.
Los recursos implementados a nivel local y en Google Cloud que comparten una zona también pueden compartir un bosque de Active Directory, por lo que no es necesario implementar un bosque independiente en Google Cloud.
Como ejemplo, considera una red existente que tiene una DMZ de desarrollo y una DMZ de producción como zonas de seguridad con un bosque de Active Directory independiente en cada zona de seguridad. Si extiendes las zonas de seguridad a Google Cloud, todas las implementaciones en Google Cloud también forman parte de una de estas dos zonas de seguridad y pueden usar los mismos bosques de Active Directory.
Agregar nuevas zonas de seguridad: Es posible que la extensión de una zona de seguridad no sea aplicable, ya sea porque no deseas expandir aún más una zona o porque los requisitos de seguridad de tus zonas de seguridad existentes no coinciden con los requisitos de tus implementaciones de Google Cloud. Puedes considerar a Google Cloud como zonas de seguridad adicionales.
Como ejemplo, considera un entorno local que tiene una DMZ, pero que no distingue entre las cargas de trabajo de desarrollo y producción. Para separar estas cargas de trabajo en Google Cloud, puedes crear dos VPC compartidas y considerarlas como zonas de seguridad nuevas. Luego, implementa dos bosques de Active Directory adicionales en Google Cloud, uno por cada zona de seguridad. Si es necesario, puedes establecer relaciones de confianza entre bosques para habilitar la autenticación en varias zonas de seguridad.
Interacción entre recursos locales y recursos de Google Cloud
El segundo factor que debes considerar cuando extiendes tu Active Directory a Google Cloud es la interacción de los usuarios y los recursos entre las instalaciones locales y Google Cloud. Según tu caso práctico, esta interacción puede variar de leve a intensa.
Interacción leve
Si el único propósito de usar Active Directory en Google Cloud es el de administrar una flota de servidores de Windows y permitir que los administradores accedan a esos servidores, el nivel de interacción entre los entornos es leve:
- El conjunto de empleados que interactúan con los recursos en Google Cloud se limita al personal administrativo.
- Es posible que las aplicaciones implementadas en Google Cloud no interactúen con las aplicaciones locales o que lo hagan sin depender de las herramientas de autenticación de Windows, como Kerberos y NTLM.
En una situación leve, considera la integración de tus entornos locales y de Google Cloud de una de las siguientes dos formas:
Dos bosques inconexos de Active Directory: Puedes aislar los dos entornos mediante dos bosques de Active Directory independientes que no compartan una relación de confianza. Para permitir que los administradores se autentiquen, debes mantener un conjunto individual de cuentas de usuario para ellos en el bosque de Google Cloud.
Mantener dos conjuntos de cuentas de usuario aumenta el esfuerzo administrativo y aumenta el riesgo de que la persona encargada olvide inhabilitar alguna cuenta cuando un empleado abandone la empresa. Un enfoque más efectivo es aprovisionar estas cuentas de forma automática.
Si un sistema de información de recursos humanos (HRIS) aprovisiona cuentas de usuario en tu Active Directory local, es posible que puedas usar un mecanismo similar para aprovisionar y administrar cuentas de usuario en el bosque de Google Cloud. Como alternativa, puedes usar herramientas como Microsoft Identity Manager para sincronizar cuentas de usuario entre entornos.
Dos bosques de Active Directory con una relación de confianza: Si usas dos bosques de Active Directory y los conectas con una relación de confianza común, puedes evitar tener que mantener cuentas duplicadas. Los administradores usan la misma cuenta de usuario para autenticarse en ambos entornos. Aunque el nivel de aislamiento entre entornos puede considerarse más débil, el uso de bosques individuales te permite mantener un límite de confianza entre tu entorno local y de Google Cloud.
Interacción moderada
Tu caso práctico podría ser más complejo. Por ejemplo:
- Es posible que los administradores que accedan a los servidores de Windows implementados en Google Cloud necesiten acceder a los archivos compartidos alojados de manera local.
- Las aplicaciones pueden usar Kerberos o NTLM para autenticarse y comunicarse de un entorno a otro.
- Se recomienda permitir que los empleados usen la Autenticación integrada de Windows (IWA) para autenticarse en aplicaciones web implementadas en Google Cloud.
En una situación de interacción moderada, operar dos bosques inconexos de Active Directory puede ser demasiado limitante: no se puede usar Kerberos para autenticarse en los dos bosques y el uso de la autenticación de tránsito de NTLM hace necesario mantener sincronizadas las cuentas de usuario y las contraseñas.
En este caso, recomendamos usar dos bosques de Active Directory vinculados mediante una relación de confianza.
Interacción intensa
Ciertas cargas de trabajo, lo que incluye las implementaciones de Infraestructura de escritorio virtual (VDI), pueden requerir una interacción intensa entre los recursos locales y los recursos implementados en Google Cloud. Cuando los recursos de los dos entornos están muy relacionados, mantener un límite de confianza entre los entornos puede no ser práctico, y usar dos bosques vinculados mediante una relación de confianza puede ser demasiado restrictivo.
En este caso, recomendamos usar un solo bosque de Active Directory y compartirlo entre los entornos.
Autonomía administrativa
El tercer factor a considerar cuando extiendes tu Active Directory a Google Cloud es la autonomía administrativa.
Si planeas distribuir cargas de trabajo entre las instalaciones locales y Google Cloud, las cargas de trabajo que ejecutarás en Google Cloud pueden ser muy diferentes a las que tienes de forma local. Incluso puede suceder que prefieras que se encarguen de cada entorno diferentes equipos.
Para separar las responsabilidades entre diferentes equipos, tienes que otorgarle cierta autonomía administrativa a cada uno. En Active Directory, puedes otorgarles a los equipos la autoridad para administrar recursos mediante la administración delegada o mediante dominios independientes.
La administración delegada es una forma básica de delegar tareas administrativas y otorgar cierta autonomía a los equipos. Mantener un solo dominio también puede ayudarte a garantizar la coherencia entre los entornos y los equipos.
Sin embargo, no puedes delegar todas las capacidades administrativas, y compartir un solo dominio puede aumentar la sobrecarga administrativa de la coordinación entre los distintos equipos. En tal caso, recomendamos que uses dominios aparte.
Disponibilidad
El último factor a tener en cuenta cuando extiendes tu Active Directory a Google Cloud es la disponibilidad. Para cada dominio en un bosque de Active Directory, el controlador de dominio funciona como proveedor de identidad para los usuarios de ese dominio.
Cuando se utiliza Kerberos para la autenticación, un usuario debe interactuar con un controlador de dominio de Active Directory en distintos puntos:
- Autenticación inicial (obtener un ticket de concesión de tickets)
- Reautenticación periódica (actualizar un ticket de concesión de tickets)
- Autenticación con un recurso (obtener un ticket de servicio)
Para realizar la autenticación inicial y la reautenticación periódica, es necesario comunicarse con un solo controlador de dominio (el del dominio al cual pertenece el usuario).
Para autenticarse con un recurso, puede ser necesario interactuar con varios controladores de dominio, según el dominio en el que se encuentre el recurso:
- Si el recurso está ubicado en el mismo dominio que el usuario, este puede usar el mismo controlador de dominio (o uno diferente dentro del mismo dominio) para completar el proceso de autenticación.
- Si el recurso se encuentra en otro dominio, pero existe una relación de confianza directa con el dominio del usuario, este debe interactuar con al menos dos controladores: uno en el dominio del recurso y otro en el dominio del usuario.
- Si el recurso y el usuario pertenecen a dominios diferentes entre los que solo existe una relación de confianza indirecta, entonces una autenticación exitosa requiere la comunicación con los controladores de cada uno de los dominios ubicados en la ruta de confianza.
La ubicación de usuarios y recursos en diferentes dominios o bosques de Active Directory puede limitar la disponibilidad general. Dado que es necesario interactuar con varios dominios para realizar la autenticación, el hecho de que se interrumpa el servicio en un dominio puede afectar la disponibilidad de los recursos de otros dominios.
Dado el posible impacto de la topología de Active Directory en la disponibilidad, recomendamos que alinees tu topología de Active Directory con tu estrategia híbrida.
Cargas de trabajo distribuidas
Para aprovechar las capacidades únicas de cada entorno informático, puedes usar un enfoque híbrido a fin de distribuir las cargas de trabajo entre esos entornos. En esta configuración, es probable que las cargas de trabajo que implementes en Google Cloud dependan de otra infraestructura o de aplicaciones que se ejecuten de forma local, lo que hace que la conectividad híbrida con alta disponibilidad sea un requisito fundamental.
Si implementas un bosque o un dominio independiente de Active Directory en Google Cloud y usas una relación de confianza para conectarlo a tu Active Directory local, agrega otra dependencia entre Google Cloud y tu entorno local. Esta dependencia tiene un efecto mínimo sobre la disponibilidad.
Cargas de trabajo redundantes
Si usas Google Cloud para garantizar la continuidad del negocio, tus cargas de trabajo en Google Cloud reflejarán algunas de las cargas de trabajo en tu entorno local. Esta configuración permite que un entorno tome las riendas en lugar del otro si se produce una falla. Por lo tanto, debes considerar cada dependencia entre estos entornos.
Si implementas un bosque o dominio de Active Directory independiente en Google Cloud y usas una relación de confianza para conectarlo a tu Active Directory local, puedes crear una dependencia que comprometa el propósito de la configuración. Si el Active Directory local no está disponible, todas las cargas de trabajo implementadas en Google Cloud que dependan de la autenticación entre dominios o entre bosques también pueden dejar de estar disponibles.
Si tu objetivo es garantizar la continuidad del negocio, puedes usar bosques de Active Directory independientes en cada entorno, sin interconectarlos. También puedes extender un dominio existente de Active Directory a Google Cloud. Si implementas controladores de dominio adicionales en Google Cloud y replicas el contenido del directorio entre entornos, te aseguras de que los entornos funcionen de forma aislada.
Patrones de integración
Una vez que hayas evaluado tus requisitos, usa el siguiente árbol de decisión para ayudar a identificar una arquitectura de dominio y de bosque adecuada.
Las siguientes secciones describen cada patrón.
Bosques sincronizados
En el patrón de bosques sincronizados, implementa un bosque de Active Directory independiente en Google Cloud. Usa este bosque para administrar los recursos implementados en Google Cloud, así como las cuentas de usuario necesarias para administrar esos recursos.
En lugar de crear una relación de confianza entre el nuevo bosque y un bosque local existente, se sincronizan las cuentas. Si usas un HRIS como el sistema principal para administrar cuentas de usuario, puedes configurar el HRIS a fin de aprovisionar cuentas de usuario en el bosque de Active Directory alojado en Google Cloud. También puedes usar herramientas como Microsoft Identity Manager para sincronizar cuentas de usuario entre entornos.
Considera usar el patrón de bosques sincronizado si se aplica una o más de las siguientes condiciones:
- El uso que pretendes darle a Google Cloud se ajusta a uno de los patrones de implementación redundante y quieres evitar dependencias de entornos de ejecución entre tu entorno local y Google Cloud.
- Deseas mantener un límite de confianza entre el entorno de Active Directory local y el entorno de Active Directory alojado en Google Cloud, ya sea como una medida de defensa en profundidad o porque confías en un entorno más que en el otro.
- Esperas una interacción leve o nula entre los recursos administrados por Active Directory en las instalaciones locales y en Google Cloud.
- La cantidad de cuentas de usuario que necesitas en el entorno de Active Directory alojado en Google Cloud es pequeña.
Ventajas:
- El patrón de bosques sincronizados te permite mantener un fuerte aislamiento entre los dos entornos de Active Directory. En caso de que un atacante vulnere uno de los entornos, obtendría pocas ventajas para atacar al otro.
- No necesitas configurar la conectividad híbrida entre tus redes locales y de Google Cloud para que Active Directory funcione.
- El Active Directory alojado en Google Cloud no se ve afectado si sucede una interrupción en tu Active Directory local. El patrón es adecuado para casos prácticos de continuidad del negocio y otras situaciones en las que se requiere alta disponibilidad.
- Puedes otorgar un nivel de autonomía administrativa alto a los equipos que administran el bosque de Active Directory alojado en Google Cloud.
- Este patrón es compatible con el servicio administrado para Microsoft Active Directory.
Prácticas recomendadas:
- No sincronices las contraseñas de las cuentas de usuario entre los dos bosques de Active Directory. Si lo haces, estarías socavando el aislamiento entre los entornos.
- No uses la autenticación de tránsito, ya que requiere que las contraseñas de las cuentas de usuario estén sincronizadas.
- Asegúrate de que cuando un empleado abandone la empresa, se inhabiliten o quiten sus cuentas en ambos entornos de Active Directory.
Bosque de recursos
En el patrón de bosque de recursos, implementa un bosque de Active Directory independiente en Google Cloud. Usa este bosque para administrar cualquier recurso implementado en Google Cloud, así como un conjunto mínimo de cuentas de usuario administrativas necesarias para administrar el bosque. Cuando estableces una relación de confianza en tu bosque de Active Directory existente local, habilitas a los usuarios de tu bosque existente a autenticarse y acceder a los recursos administrados por el bosque de Active Directory alojado en Google Cloud.
Si es necesario, puedes convertir este patrón en una topología de tipo radial en la que tu bosque de Active Directory existente sirva como centro de interconexión entre muchos otros bosques de recursos.
Considera usar el patrón de bosque de recursos si se aplica una o más de las siguientes condiciones:
- El uso que pretendes darle a Google Cloud se adapta a uno de los patrones de implementación distribuidos, y se acepta una dependencia entre tu entorno local y Google Cloud.
- Deseas mantener un límite de confianza entre el entorno local de Active Directory local y el entorno de Active Directory alojado en Google Cloud, ya sea como una medida de defensa en profundidad o porque consideras que un entorno es más confiable que el otro.
- Esperas un nivel moderado de interacción entre los recursos administrados por Active Directory de forma local y en Google Cloud.
- Tienes una gran cantidad de usuarios que necesitan acceder a los recursos implementados en Google Cloud; por ejemplo, a las aplicaciones web que usan IWA para la autenticación.
Ventajas:
- El patrón del bosque de recursos te permite mantener un límite de confianza entre los dos entornos de Active Directory. Según cómo esté configurada la relación de confianza, en caso de que un atacante vulnere un entorno, obtendría poco o ningún acceso al otro.
- Este patrón es compatible por completo con Microsoft AD administrado.
- Puedes otorgar un nivel de autonomía administrativa alto a los equipos que administran el bosque de Active Directory alojado en Google Cloud.
Prácticas recomendadas:
- Conecta los dos bosques de Active Directory mediante una relación de confianza unidireccional para que el Active Directory alojado en Google Cloud confíe en tu Active Directory existente, pero no al revés.
- Usa la autenticación selectiva para limitar los recursos en el Active Directory alojado en Google Cloud al que pueden acceder los usuarios del Active Directory local.
- Usa conexiones redundantes de interconexión dedicada, interconexión de socio o Cloud VPN para garantizar una conectividad de red con alta disponibilidad entre tu red local y Google Cloud.
Dominio extendido
En el patrón de dominio extendido, se extiende uno o más de tus dominios de Active Directory existentes a Google Cloud. Se implementa uno o más controladores de dominio en Google Cloud para cada dominio, lo que hace que todos los datos de dominio, así como el catálogo global, se repliquen y estén disponibles en Google Cloud. Si usas sitios de Active Directory independientes para tus subredes locales y de Google Cloud, te aseguras de que los clientes se comuniquen con los controladores de dominio más cercanos.
Considera usar el patrón de dominio extendido si se aplica una o más de las siguientes condiciones:
- El uso que pretendes darle a Google Cloud se adapta a uno de los patrones de implementación redundantes y deseas evitar las dependencias del entorno de ejecución entre tu entorno local y Google Cloud.
- Esperas una interacción intensa entre los recursos administrados por Active Directory de forma local y en Google Cloud.
- Deseas acelerar la autenticación de las aplicaciones que dependen de LDAP para la autenticación.
Ventajas:
- El Active Directory alojado en Google Cloud no se ve afectado si sucede una interrupción en tu Active Directory local. El patrón es adecuado para casos prácticos de continuidad del negocio y otras situaciones en las que se requiere alta disponibilidad.
- Puedes limitar la comunicación entre tu red local y Google Cloud. Así, se podría ahorrar ancho de banda y mejorar la latencia.
- Todo el contenido del catálogo global se replica en Active Directory y se puede acceder a él de manera eficiente desde los recursos alojados en Google Cloud.
Prácticas recomendadas:
- Si replicas todos los dominios, la comunicación entre tu red local y la red de Google Cloud se limitará a la replicación de Active Directory entre los controladores de dominio. Si solo replicas un subconjunto de los dominios de tu bosque, es posible que los servidores unidos al dominio que se ejecutan en Google Cloud necesiten comunicarse con los controladores de dominios no replicados. Asegúrate de que las reglas de firewall que se aplican a la comunicación entre las instalaciones locales y Google Cloud consideren todos los casos relevantes.
- Ten en cuenta que la replicación entre sitios solo ocurre cada ciertos intervalos, por lo que las actualizaciones que se realizan en un controlador de dominio local solo se muestran en Google Cloud después de una demora (y viceversa).
- Considera usar controladores de dominio de solo lectura (RODC) para mantener una copia de solo lectura de los datos de dominio en Google Cloud, pero ten en cuenta que existe una compensación relacionada con el almacenamiento en caché de las contraseñas de los usuarios. Si permites que los RODC almacenen en caché las contraseñas y propaguen de forma previa la caché de las contraseñas, los recursos implementados en Google Cloud pueden no verse afectados por una interrupción de los controladores de dominio locales. Sin embargo, los beneficios de seguridad de usar un RODC en vez de un controlador de dominio regular se verán limitados. Si inhabilitas el almacenamiento en caché de las contraseñas, puede que un RODC afectado solo represente un riesgo limitado para el resto de tu Active Directory, pero pierdes el beneficio de que Google Cloud no se vea afectado por una interrupción de los controladores de dominio locales.
Bosque extendido
En el patrón de bosque extendido, implementas un dominio de Active Directory nuevo en Google Cloud, pero lo integras en tu bosque existente. Usa el dominio nuevo para administrar los recursos implementados en Google Cloud y a fin de mantener un conjunto mínimo de cuentas de usuario administrativas para administrar el dominio.
Si extiendes las relaciones de confianza implícitas a otros dominios del bosque, habilitas a los usuarios existentes de otros dominios a autenticarse y acceder a los recursos administrados por el dominio de Active Directory alojado en Google Cloud.
Considera usar el patrón de bosque extendido si se aplica una o más de las siguientes condiciones:
- El uso que pretendes darle a Google Cloud se adapta a uno de los patrones de implementación distribuidos, y se acepta una dependencia entre tu entorno local y Google Cloud.
- Los recursos que planeas implementar en Google Cloud requieren una configuración o estructura de dominio diferente de la que proporcionan tus dominios existentes, o deseas otorgar un alto nivel de autonomía administrativa a los equipos que administran el dominio alojado en Google Cloud.
- Esperas una interacción moderada a intensa entre los recursos administrados por Active Directory de forma local y en Google Cloud.
- Tienes muchos usuarios que necesitan acceder a los recursos implementados en Google Cloud. Por ejemplo, a las aplicaciones web que usan IWA para la autenticación.
Ventajas:
- Todo el contenido del catálogo global se replicará en Active Directory y se podrá acceder de manera eficiente desde los recursos alojados en Google Cloud.
- El tráfico de replicación entre tu red local y Google Cloud está limitado a la replicación del catálogo global. Esto podría ayudar a limitar el consumo de ancho de banda total.
- Puedes otorgar un nivel alto de autonomía administrativa a los equipos que administran el dominio de Active Directory alojado en Google Cloud.
Recomendaciones:
- Usa conexiones redundantes de interconexión dedicada, interconexión de socio o Cloud VPN para garantizar una conectividad de red con alta disponibilidad entre tu red local y Google Cloud.
Bosque de recursos con dominio extendido
El patrón de bosque de recursos con dominio extendido es una extensión del patrón de bosque de recursos. El patrón de bosque de recursos te permite mantener un límite de confianza entre los entornos y proporcionar autonomía administrativa. Una limitación del bosque de recursos es que su disponibilidad general depende de la disponibilidad de los controladores de dominio locales y de que exista una conectividad de red confiable a tu centro de datos local.
Para superar estas limitaciones, puedes combinar el patrón de bosque de recursos con el patrón de dominio extendido. Si replicas el dominio, tus cuentas de usuario se encontrarán en Google Cloud, y puedes asegurarte de que los usuarios puedan autenticarse en los recursos alojados en Google Cloud incluso cuando los controladores de dominio locales no estén disponibles o se pierda la conectividad de red.
Considera usar el bosque de recursos con el patrón de dominio extendido si se aplica una o más de las siguientes condiciones:
- Deseas mantener un límite de confianza entre tu bosque principal de Active Directory y el bosque de recursos.
- Deseas evitar que una interrupción de los controladores de dominio locales o la pérdida de conectividad de red a tu entorno local afecten tus cargas de trabajo alojadas en Google Cloud.
- Esperas una interacción moderada entre los recursos administrados por Active Directory de forma local y en Google Cloud.
- Tienes muchos usuarios de un solo dominio de Active Directory que necesitan acceder a los recursos implementados en Google Cloud, por ejemplo, a aplicaciones web que usan IWA para la autenticación.
Ventajas:
- Los recursos alojados en Google Cloud no se ven afectados si sucede una interrupción en tu Active Directory local. El patrón es adecuado para casos prácticos de continuidad del negocio y otras situaciones en las que se requiere alta disponibilidad.
- El patrón te permite mantener un límite de confianza entre los dos bosques de Active Directory. Según cómo esté configurada la relación de confianza, en caso de que un atacante vulnere un entorno, obtendría poco o ningún acceso al otro.
- La comunicación entre tu red local y la red de Google Cloud se limita a la replicación de Active Directory entre controladores de dominio. Puedes implementar reglas de firewall para rechazar todas las demás comunicaciones, lo que refuerza el aislamiento entre los entornos.
- Puedes otorgar un nivel de autonomía administrativa alto a los equipos que administran el bosque de Active Directory alojado en Google Cloud.
- Puedes usar Microsoft AD administrado para el bosque de recursos.
Recomendaciones:
- Implementa controladores de dominio para el dominio extendido en un proyecto de Google Cloud y una VPC diferentes a fin de separar estos componentes de los componentes del bosque de recursos.
- Usa el intercambio de tráfico entre redes de VPC con el fin de conectar la VPC con la VPC compartida o la VPC que usa el bosque de recursos y configura firewalls para restringir la comunicación con la autenticación de usuarios de Kerberos y la creación de la relación de confianza de bosque.
- Conecta los dos bosques de Active Directory mediante una relación de confianza unidireccional para que el Active Directory alojado en Google Cloud confíe en tu bosque de Active Directory existente, pero no al revés.
- Usa la autenticación selectiva para limitar los recursos del bosque de recursos a los que pueden acceder los usuarios de otros bosques.
- Ten en cuenta que la replicación entre sitios solo ocurre cada ciertos intervalos, por lo que las actualizaciones que se realizan en un controlador de dominio local solo se muestran en Google Cloud después de una demora (y viceversa).
- Considera el uso de RODC para el dominio extendido, pero asegúrate de permitir el almacenamiento en caché de las contraseñas a fin de preservar las ventajas de disponibilidad en comparación con el patrón de bosque de recursos.
¿Qué sigue?
- Obtén más información sobre Microsoft AD administrado.
- Consulta la página sobre las prácticas recomendadas para implementar un bosque de recursos de Active Directory en Google Cloud .
- Obtén más información sobre cómo implementar un entorno de Active Directory tolerante a errores en Google Cloud.
- Revisa nuestras recomendaciones de diseño de VPC.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.