En este documento, 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 Patrones para autenticar usuarios de personal en un entorno híbrido), 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 usarlo 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 dominio y de bosque usar y cómo hacer la integración con tu bosque existente de Active Directory.
Evalúa 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 Google Cloud locales y recursos
- 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 red 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 y 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:
Extiende 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 Cloud Interconnect.
Los recursos implementados de manera local y en Google Cloud que comparten una zona común también pueden compartir un bosque común de Active Directory, por lo que no es necesario implementar un bosque aparte en Google Cloud.
Como ejemplo, considera una red existente que tiene una red perimetral de desarrollo y una red perimetral 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 aGoogle 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 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 red perimetral, 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 nuevas zonas de seguridad. Luego, implementas dos bosques adicionales de Active Directory 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 Google Cloud locales y recursos
El segundo factor que debes considerar cuando extiendes tu Active Directory aGoogle 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 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 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 en absoluto o, si lo hacen, no utilicen funciones de autenticación de Windows como Kerberos y NTLM.
En una situación leve, considera la integración de tus entornos locales y deGoogle 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 deGoogle 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. Si bien el nivel de aislamiento entre entornos puede considerarse más débil, el uso de bosques independientes te permite mantener un límite de confianza entre tu entorno local y el entorno 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 enGoogle 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
Algunas cargas de trabajo, incluidas las implementaciones de la 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 diferentes entornos están estrechamente vinculados, es posible que no sea práctico intentar mantener un límite de confianza entre ellos, y usar dos bosques con una confianza entre bosques puede ser demasiado limitante.
En este caso, recomendamos usar un solo bosque de Active Directory y compartirlo entre los entornos.
Autonomía administrativa
El tercer factor que debes considerar cuando extiendes tu Active Directory aGoogle Cloud es la autonomía administrativa.
Si planeas distribuir cargas de trabajo entre las instalaciones locales y Google Cloud, es posible que las cargas de trabajo que ejecutarás en Google Cloud sean 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 que debes considerar cuando extiendes tu Active Directory aGoogle 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 una configuración de este tipo, es probable que las cargas de trabajo que implementes en Google Cloud dependan de otra infraestructura o aplicaciones que se ejecuten de forma local, por lo cual resulta esencial tener una conectividad híbrida con alta disponibilidad.
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, agregas 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 reflejan algunas de las cargas de trabajo de 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, es posible que creas una dependencia que socave el propósito de la configuración. Si el Active Directory local deja de estar disponible, es posible que también dejen de estarlo todas las cargas de trabajo implementadas enGoogle Cloud que dependen de la autenticación entre dominios o bosques.
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 aGoogle Cloud. Si implementas controladores de dominio adicionales enGoogle 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 para que aprovisione 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 redundantes y deseas evitar las dependencias del entorno de ejecución entre tu entorno local y Google Cloud.
- Deseas mantener un límite de confianza entre tu 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 de forma local y en Google Cloud.
- La cantidad de cuentas de usuario que necesitas en el entorno de Active Directory alojado en Google Cloudes 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 Google Cloud para operar Active Directory.
- El Active Directory alojado en Google Cloudno 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 alto de autonomía administrativa 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 enGoogle 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 enGoogle 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 ajusta a uno de los patrones de implementación distribuidos, y es aceptable que exista una dependencia entre tu entorno local y Google Cloud.
- Deseas mantener un límite de confianza entre tu entorno de Active Directory local y el entorno de Active Directory alojado en Google Cloud, ya sea como 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 alto de autonomía administrativa a los equipos que administran el bosque de Active Directory alojado en Google Cloud.
Prácticas recomendadas:
- Conecta los dos bosques de Active Directory con una relación de confianza unidireccional para que el Active Directory alojado en Google Cloudconfíe en tu Active Directory existente, pero no al revés.
- Usa la autenticación selectiva para limitar los recursos del Active Directory alojado en Google Clouda los que pueden acceder los usuarios del Active Directory local.
- Usa conexiones redundantes de interconexión dedicada, interconexión de socios 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. Para cada dominio, se implementan uno o más controladores de dominio en Google Cloud, lo que hace que todos los datos del dominio, así como el catálogo global, se repliquen y estén disponibles enGoogle Cloud. Si usas sitios de Active Directory independientes para tus subredes Google Cloud 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 ajusta 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 enGoogle Cloud.
- Deseas acelerar la autenticación de las aplicaciones que dependen de LDAP para la autenticación.
Ventajas:
- El Active Directory alojado en Google Cloudno 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 yGoogle Cloud. Esto puede 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 controladores de dominio. Si replicas solo un subconjunto de los dominios de tu bosque, es posible que los servidores unidos a un dominio que se ejecutan enGoogle Cloud aún deban comunicarse con los controladores de los 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 realizadas en un controlador de dominio local solo se muestran enGoogle 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 guarden las contraseñas en caché y rellenen previamente la caché de contraseñas, los recursos implementados en Google Cloud no se verán 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, un RODC vulnerado no representaría más que un riesgo limitado para el resto de tu Active Directory, pero pierdes la ventaja de queGoogle 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 enGoogle Cloud, pero lo integras en el bosque existente. Usa el dominio nuevo para administrar los recursos implementados en Google Cloud y 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 ajusta a uno de los patrones de implementación distribuidos, y es aceptable que exista 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 a 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 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 a él de manera eficiente desde los recursos alojados en Google Cloud.
- El tráfico de replicación entre tu red local yGoogle Cloud se limita a la replicación del catálogo global. Esto podría ayudar a limitar el consumo de ancho de banda total.
- Puedes otorgar un alto nivel 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 socios 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 encuentran en Google Cloudy puedes garantizar que los usuarios puedan autenticarse en los recursos alojados en Google Cloudincluso cuando los controladores de dominio locales no estén disponibles o se pierda la conectividad de la 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 enGoogle 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 enGoogle Cloudno se ven afectados por una interrupción de 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 alto de autonomía administrativa a los equipos que administran el bosque de Active Directory alojado en Google Cloud.
- Puedes usar Microsoft AD administrado para el bosque de recursos.
Prácticas recomendadas:
- Implementa controladores de dominio para el dominio extendido en un proyecto deGoogle Cloud y una VPC independientes para separar estos componentes de los del bosque de recursos.
- Usa el intercambio de tráfico entre redes de VPC para conectar la VPC a la VPC compartida o a 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 con una relación de confianza unidireccional para que el Active Directory alojado en Google Cloudconfí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 realizadas en un controlador de dominio local solo se muestran enGoogle 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.
- Revisa las prácticas recomendadas para implementar un bosque de recursos de Active Directory en Google Cloud.
- Obtén más información para implementar un entorno de Active Directory tolerante a errores en Google Cloud.
- Revisa nuestras recomendaciones de diseño de VPC.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.