En este documento se describen los requisitos que debes tener en cuenta al implementar Active Directory en Google Cloud y se te ayuda a elegir la arquitectura adecuada.
Al federar Active Directory con Cloud Identity o Google Workspace (consulta los patrones para autenticar a los usuarios de la plantilla en un entorno híbrido), puedes permitir que los usuarios de tus dominios de Active Directory se autentiquen y accedan a los recursos de Google Cloud. También puedes implementar Active Directory en Google Cloud si tienes previsto usar Active Directory para gestionar servidores Windows en Google Cloud o si utilizas protocolos que no son compatibles con Google Cloud.
Antes de implementar Active Directory en Google Cloud, debes decidir qué arquitectura de dominio y bosque vas a usar y cómo se integrará con tu bosque de Active Directory.
Evaluar los requisitos
Active Directory admite una serie de arquitecturas de dominio y de bosque. En un entorno híbrido, una opción es ampliar un único dominio de Active Directory a varios entornos. También puedes usar dominios o bosques independientes y conectarlos mediante relaciones de confianza. La mejor arquitectura depende de tus requisitos.
Para elegir la mejor arquitectura, ten en cuenta estos factores:
- Alineación con las zonas de seguridad actuales
- Interacción entre recursos locales y de Google Cloud
- Autonomía administrativa
- Disponibilidad
En las siguientes secciones se analizan estos factores.
Alineación con las zonas de seguridad actuales
Empieza 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 el uso de VLANs o subredes independientes. En una red que se ha segmentado en zonas de seguridad, la comunicación dentro de una zona de seguridad no está restringida o solo está sujeta a políticas de cortafuegos y auditoría ligeras. Por el contrario, cualquier comunicación entre zonas de seguridad está sujeta a estrictas políticas de cortafuegos, auditoría o inspección del tráfico.
Sin embargo, el objetivo de las zonas de seguridad va más allá de restringir y auditar la comunicación de red, ya que también 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í de forma local mediante la comunicación entre procesos y pueden comunicarse entre máquinas mediante protocolos como HTTP. En esta red de comunicación, los participantes no siempre confían entre sí en la misma medida. Por ejemplo, los procesos pueden confiar más en los procesos que se ejecutan en la misma máquina que en los que se ejecutan en otras máquinas. Y algunas máquinas pueden considerarse más fiables que otras.
Un límite de confianza obliga a discriminar entre las partes de la comunicación, ya que confía más en un conjunto de partes que en otro.
Los límites de confianza son fundamentales para contener el impacto de un ataque. Los ataques rara vez terminan cuando se ha vulnerado un solo sistema, ya sea un proceso o un equipo completo. En su lugar, es probable que un atacante intente ampliar el ataque a otros sistemas. Como los sistemas de un límite de confianza no se discriminan entre sí, es más fácil propagar un ataque dentro de ese límite que atacar sistemas que se encuentran en diferentes límites de confianza.
Una vez que se ha vulnerado un sistema en un límite de confianza, se debe asumir que todos los demás sistemas de ese límite de confianza también se han vulnerado. Esta suposición puede ayudarte a identificar límites de confianza o a validar si un límite de un sistema determinado es un límite de confianza. Por ejemplo:
Supongamos que un atacante ha conseguido el nivel de acceso más alto al objetivo A (por ejemplo, acceso de administrador o acceso raíz a una máquina o aplicación). Si pueden aprovechar estos privilegios para obtener el mismo nivel de acceso al objetivo B, entonces A y B se encuentran, por definición, dentro del mismo límite de confianza. De lo contrario, habrá un límite de confianza entre A y B.
Al restringir 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 límite de confianza real, las cargas de trabajo de cada lado del límite deben distinguir entre las solicitudes que proceden de la misma zona de seguridad y las que proceden de diferentes zonas de seguridad, y analizar estas últimas con más detenimiento.
Modelo de confianza cero
El modelo de confianza cero es el modelo de red preferido en Google Cloud.
Si se detecta un sistema vulnerado en un límite de confianza, puedes dar por hecho que todos los sistemas de ese límite están vulnerados. Esta suposición sugiere que es mejor que los límites de confianza sean más pequeños. Cuanto más pequeño sea el límite de confianza, menos sistemas se verán comprometidos y más límites tendrá que superar un atacante para que un ataque se propague.
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 únicos. Todas las comunicaciones entre máquinas están sujetas al mismo escrutinio y cortafuegos, y todas las solicitudes de red se tratan como si procedieran de una fuente que no es de confianza.
A nivel de red, puedes implementar un modelo de confianza cero mediante reglas de cortafuegos para restringir el tráfico y registros de flujo de VPC y registros de reglas de cortafuegos para analizar el tráfico. En el nivel de aplicación, debes asegurarte de que todas las aplicaciones gestionen la autenticación, la autorización y la auditoría de forma coherente y segura.
Límites de confianza en Active Directory
En un dominio de Active Directory, los equipos confían en los controladores de dominio para gestionar la autenticación y la autorización en su nombre. Una vez que un usuario ha demostrado su identidad a uno de los controladores de dominio, puede iniciar sesión de forma predeterminada en todos los equipos del mismo dominio. Los derechos de acceso que el controlador de dominio concede al usuario (en forma de privilegios y pertenencia a grupos) se aplican a muchas máquinas del dominio.
Mediante las políticas de grupo, puedes impedir que los usuarios accedan a determinadas máquinas o restringir sus derechos en ellas. Sin embargo, una vez que se ha visto comprometida una máquina, un atacante podría robar contraseñas, hashes de contraseñas o tokens de Kerberos de otros usuarios del dominio que hayan iniciado sesión en la misma máquina. De esta forma, el atacante puede usar estas credenciales para extender el ataque a otros dominios del bosque.
Teniendo en cuenta estos factores, lo mejor es asumir 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 dominio, cuyo objetivo es controlar la replicación y conceder autonomía administrativa a diferentes partes de la organización, los límites de bosque pueden proporcionar un aislamiento más sólido. Los bosques pueden actuar como límite de confianza.
Alinear bosques de Active Directory y zonas de seguridad
Si se considera el bosque como el límite de confianza, se influye en el diseño de las zonas de seguridad. Si un bosque se extiende por dos zonas de seguridad, a un atacante le resultará más fácil eliminar el límite entre estas zonas. Como resultado, las dos zonas de seguridad se convierten en una y forman un único límite de confianza.
En un modelo de confianza cero, cada máquina de una red se puede considerar como una zona de seguridad independiente. Desplegar Active Directory en una red de este tipo socava este concepto y amplía el límite de seguridad efectivo para incluir todas las máquinas del bosque de Active Directory.
Para que una zona de seguridad sirva como límite de confianza, debe asegurarse de que todo el bosque de Active Directory esté en la zona de seguridad.
Impacto de la extensión de Active Directory a Google Cloud
Cuando planifiques una implementación en Google Cloud que requiera Active Directory, debes elegir entre dos opciones para alinear la implementación con tus zonas de seguridad:
Amplía una zona de seguridad que ya tengas Google Cloud. Puedes ampliar una o varias de tus zonas de seguridad a Google Cloud aprovisionando una VPC compartida en Google Cloud y conectándola a la zona en cuestión mediante Cloud VPN o Cloud Interconnect.
Los recursos desplegados de forma local y en Google Cloud que comparten una zona común también pueden compartir un bosque de Active Directory común, por lo que no es necesario desplegar un bosque independiente en Google Cloud.
Por ejemplo, considera una red que tenga 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 amplías las zonas de seguridad aGoogle Cloud, todas las implementaciones de Google Cloud también formarán parte de una de estas dos zonas de seguridad y podrán usar los mismos bosques de Active Directory.
Presenta las nuevas zonas de seguridad. Puede que no sea aplicable ampliar una zona de seguridad porque no quieras ampliarla más o porque los requisitos de seguridad de tus zonas de seguridad no coincidan con los de tus implementaciones de Google Cloud. Puedes tratarlo Google Cloud como zonas de seguridad adicionales.
Por ejemplo, supongamos que tienes un entorno local con una red perimetral, pero no distingue entre las cargas de trabajo de desarrollo y producción. Para separar estas cargas de trabajo en Google Cloud, puedes crear dos VPCs compartidas y considerarlas nuevas zonas de seguridad. A continuación, implementa dos bosques de Active Directory adicionales en Google Cloud, uno por zona de seguridad. Si es necesario, puedes establecer relaciones de confianza entre bosques para habilitar la autenticación en las zonas de seguridad.
Interacción entre recursos locales y de Google Cloud
El segundo factor que debes tener en cuenta al ampliar tu Active Directory aGoogle Cloud es la interacción de los usuarios y los recursos entre las instalaciones locales y Google Cloud. En función del caso práctico, esta interacción puede ser de leve a intensa.
Interacción con la luz
Si el único propósito de usar Active Directory en Google Cloud es gestionar una flota de servidores Windows y permitir que los administradores inicien sesión en estos servidores, el nivel de interacción entre los entornos es bajo:
- El conjunto de empleados que interactúan con los recursos de 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 funciones de autenticación de Windows, como Kerberos y NTLM.
En un escenario ligero, puedes integrar tus entornos locales yGoogle Cloud de una de las dos formas siguientes:
Dos bosques de Active Directory disjuntos: puedes aislar los dos entornos usando 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 independiente de cuentas de usuario para ellos en el Google Cloud bosque.
Mantener un conjunto duplicado de cuentas de usuario aumenta el esfuerzo administrativo y conlleva el riesgo de olvidar inhabilitar las cuentas cuando los empleados dejan la empresa. Una mejor opción es aprovisionar estas cuentas automáticamente.
Si las cuentas de usuario de tu Active Directory local se aprovisionan mediante un sistema de información de recursos humanos (SIRR), es posible que puedas usar un mecanismo similar para aprovisionar y gestionar cuentas de usuario en elGoogle Cloud bosque. También 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 entre bosques: si usas dos bosques de Active Directory y los conectas con una relación de confianza entre bosques, puedes evitar tener que mantener cuentas duplicadas. Los administradores utilizan 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 independientes te permite mantener un límite de confianza entre tu entorno local y el de Google Cloud .
Interacción moderada
Tu caso práctico puede ser más complejo. Por ejemplo:
- Es posible que los administradores que inicien sesión en servidores Windows implementados enGoogle Cloud necesiten acceder a recursos compartidos de archivos alojados en las instalaciones.
- Las aplicaciones pueden usar Kerberos o NTLM para autenticarse y comunicarse entre límites de entornos.
- Puede que quieras permitir que los empleados usen la autenticación integrada de Windows (IWA) para autenticarse en aplicaciones web implementadas en Google Cloud.
En un escenario moderado, operar con dos bosques de Active Directory disjuntos puede ser demasiado limitante: no puedes usar Kerberos para autenticarte en los dos bosques y, para usar la autenticación de transferencia de NTLM, debes mantener sincronizadas las cuentas de usuario y las contraseñas.
En este caso, le recomendamos que utilice dos bosques de Active Directory con una confianza entre bosques.
Interacción intensa
Algunas cargas de trabajo, como las implementaciones de infraestructura de escritorio virtual (VDI), pueden requerir una gran interacción entre los recursos locales y los recursos implementados en Google Cloud. Cuando los recursos de los entornos están estrechamente acoplados, puede que no sea práctico intentar mantener un límite de confianza entre los entornos y que usar dos bosques con una relación de confianza entre bosques sea demasiado restrictivo.
En este caso, te recomendamos que uses un único bosque de Active Directory y que lo compartas entre entornos.
Autonomía administrativa
El tercer factor que debes tener en cuenta al ampliar tu Active Directory a Google Cloud es la autonomía administrativa.
Si tienes previsto distribuir cargas de trabajo entre entornos locales y Google Cloud, las cargas de trabajo que vayas a ejecutar en Google Cloud pueden ser muy diferentes de las que mantengas en el entorno local. Incluso puedes decidir que sean equipos diferentes los que gestionen los dos entornos.
Para separar las responsabilidades entre los distintos equipos, es necesario conceder a cada uno cierta autonomía administrativa. En Active Directory, puedes conceder a los equipos la autoridad para gestionar recursos mediante la administración delegada o mediante dominios independientes.
La administración delegada es una forma sencilla de delegar tareas administrativas y conceder cierta autonomía a los equipos. Mantener un solo dominio también puede ayudarte a asegurar la coherencia entre entornos y equipos.
Sin embargo, no puedes delegar todas las funciones administrativas y compartir un solo dominio puede aumentar la carga administrativa de la coordinación entre equipos. En ese caso, te recomendamos que uses dominios independientes.
Disponibilidad
El último factor que debes tener en cuenta al ampliar tu Active Directory aGoogle Cloud es la disponibilidad. En cada dominio de un bosque de Active Directory, el controlador de dominio actúa como proveedor de identidades para los usuarios de ese dominio.
Cuando se usa Kerberos para la autenticación, un usuario debe interactuar con un controlador de dominio de Active Directory en varios puntos:
- Autenticación inicial (obtención de un ticket de concesión de tickets).
- Reautenticación periódica (actualización de un vale de concesión de vales).
- Autenticarse con un recurso (obtener un ticket de servicio).
Para realizar la autenticación inicial y la reautenticación periódica, solo es necesario comunicarse con un controlador de dominio, que es el del dominio al que pertenece el usuario.
Al autenticarte con un recurso, puede que sea necesario interactuar con varios controladores de dominio, en función del dominio en el que se encuentre el recurso:
- Si el recurso se encuentra en el mismo dominio que el usuario, este puede usar el mismo controlador de dominio (u otro controlador de dominio del mismo dominio) para completar el proceso de autenticación.
- Si el recurso se encuentra en un dominio diferente, pero hay una relación de confianza directa con el dominio del usuario, el usuario debe interactuar con al menos dos controladores de dominio: uno en el dominio del recurso y otro en el dominio del usuario.
- Si el recurso y el usuario forman parte de dominios diferentes y solo hay una relación de confianza indirecta entre estos dominios, para que la autenticación se realice correctamente, es necesario comunicarse con los controladores de dominio de cada dominio de la ruta de confianza.
Localizar usuarios y recursos en diferentes dominios o bosques de Active Directory puede limitar la disponibilidad general. Como la autenticación requiere interactuar con varios dominios, una interrupción en uno de ellos puede afectar a la disponibilidad de recursos en otros dominios.
Teniendo en cuenta el posible impacto de la topología de Active Directory en la disponibilidad, te recomendamos que adaptes la topología de Active Directory a tu estrategia híbrida.
Cargas de trabajo distribuidas
Para aprovechar las funciones únicas de cada entorno de computación, puedes usar un enfoque híbrido para 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 aplicaciones que se ejecuten de forma local, por lo que la conectividad híbrida de alta disponibilidad es un requisito fundamental.
Si implementas un bosque o un dominio de Active Directory independiente en Google Cloud y usas una relación de confianza para conectarlo a tu Active Directory local, añades otra dependencia entre Google Cloud y tu entorno local. Esta dependencia tiene un efecto mínimo en la disponibilidad.
Cargas de trabajo redundantes
Si usas Google Cloud para garantizar la continuidad de tu negocio, tus cargas de trabajo en Google Cloud reflejarán algunas de las cargas de trabajo de tu entorno local. Esta configuración permite que un entorno asuma el rol del otro si se produce un error. Por lo tanto, debes analizar todas las dependencias entre estos entornos.
Si implementas un bosque o un 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 crees una dependencia que perjudique el objetivo de la configuración. Si el Active Directory local deja de estar disponible, todas las cargas de trabajo implementadas enGoogle Cloud que dependan de la autenticación entre dominios o entre bosques también podrían dejar de estar disponibles.
Si tu objetivo es asegurar la continuidad del negocio, puedes usar bosques de Active Directory independientes en cada entorno que no estén conectados entre sí. También puedes ampliar un dominio de Active Directory aGoogle Cloud. Al implementar controladores de dominio adicionales enGoogle Cloud y replicar 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, utiliza el siguiente esquema para identificar una arquitectura de bosque y dominio adecuada.
En las siguientes secciones se describe cada patrón.
Bosques sincronizados
En el patrón de bosques sincronizados, se despliega un bosque de Active Directory independiente en Google Cloud. Esta bosque se usa para gestionar los recursos implementados en Google Cloud , así como las cuentas de usuario necesarias para gestionar estos recursos.
En lugar de crear una relación de confianza entre el nuevo bosque y un bosque local, sincroniza las cuentas. Si usas un SIAR como sistema principal para gestionar cuentas de usuario, puedes configurarlo 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.
Usa el patrón de bosques sincronizados si se cumple alguna de las siguientes condiciones:
- El uso que quieres dar a Google Cloud se ajusta a uno de los patrones de implementación redundantes y quieres evitar las dependencias de tiempo de ejecución entre tu entorno local y Google Cloud.
- Quieres 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 confías más en un entorno que en otro.
- Esperas que haya poca o ninguna interacción entre los recursos gestionados por Active Directory en las instalaciones y en Google Cloud.
- El número de cuentas de usuario que necesitas en el entorno de Active Directory alojado en Google Cloudes pequeño.
Ventajas:
- El patrón de bosques sincronizados te permite mantener un alto nivel de aislamiento entre los dos entornos de Active Directory. Un atacante que vulnera un entorno puede obtener pocas ventajas al atacar el segundo entorno.
- No es necesario que configures la conectividad híbrida entre tus redes locales y Google Cloud para usar Active Directory.
- El servicio Active Directory alojado en Google Cloudno se ve afectado por una interrupción de tu servicio Active Directory local. Este patrón es adecuado para casos prácticos de continuidad empresarial u otros escenarios que requieran una alta disponibilidad.
- Puedes conceder un alto nivel de autonomía administrativa a los equipos que gestionan el bosque de Active Directory alojado en Google Cloud.
- Este patrón es compatible con el servicio gestionado para Microsoft Active Directory.
Prácticas recomendadas:
- No sincronices las contraseñas de las cuentas de usuario entre los dos bosques de Active Directory. De esta forma, se debilita el aislamiento entre los entornos.
- No dependas de la autenticación directa, ya que requiere sincronizar las contraseñas de las cuentas de usuario.
- Asegúrate de que, cuando un empleado deje la empresa, sus cuentas de ambos entornos de Active Directory se inhabiliten o eliminen.
Bosque de recursos
En el patrón de bosque de recursos, se despliega un bosque de Active Directory independiente en Google Cloud. Puedes usar este bosque para gestionar los recursos implementados enGoogle Cloud , así como un conjunto mínimo de cuentas de usuario de administrador necesarias para gestionar el bosque. Al establecer una relación de confianza entre bosques con tu bosque de Active Directory local, permites que los usuarios de tu bosque se autentiquen y accedan a los recursos gestionados por el bosque de Active Directory alojado enGoogle Cloud.
Si es necesario, puedes convertir este patrón en una topología de concentrador y radios con tu bosque de Active Directory en el centro, conectado a muchos bosques de recursos.
Considera usar el patrón de bosque de recursos si se da una o varias de las siguientes circunstancias:
- El uso que quieres dar a Google Cloud se ajusta a uno de los patrones de implementación distribuida y es aceptable una dependencia entre tu entorno local y Google Cloud.
- Quieres 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 fiable que el otro.
- Esperas un nivel de interacción moderado entre los recursos gestionados por Active Directory on-premise y en Google Cloud.
- Tienes un gran número de usuarios que necesitan acceder a recursos implementados en Google Cloud, por ejemplo, a aplicaciones web que usan IWA para la autenticación.
Ventajas:
- El patrón de bosque de recursos te permite mantener un límite de confianza entre los dos entornos de Active Directory. En función de cómo se configure la relación de confianza, un atacante que ponga en peligro un entorno podría obtener poco o ningún acceso al otro.
- Microsoft AD gestionado admite este patrón por completo.
- Puedes conceder un alto nivel de autonomía administrativa a los equipos que gestionan 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 Cloudconfíe en tu Active Directory, 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, Partner Interconnect o Cloud VPN para asegurar una conectividad de red de alta disponibilidad entre tu red on-premise y Google Cloud.
Dominio ampliado
En el patrón de dominio ampliado, se amplían uno o varios de los dominios de Active Directory a Google Cloud. En cada dominio, se implementan uno o varios controladores de dominio en Google Cloud, lo que provoca 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 locales y Google Cloud , te aseguras de que los clientes se comuniquen con los controladores de dominio que estén más cerca de ellos.
Te recomendamos que uses el patrón de dominio ampliado si se da alguna de las siguientes circunstancias:
- El uso que quieres dar a Google Cloud se ajusta a uno de los patrones de implementación redundantes y quieres evitar las dependencias de tiempo de ejecución entre tu entorno local y Google Cloud.
- Esperas una interacción intensa entre los recursos gestionados por Active Directory en las instalaciones y enGoogle Cloud.
- Quieres acelerar la autenticación de las aplicaciones que dependen de LDAP para la autenticación.
Ventajas:
- El servicio Active Directory alojado en Google Cloudno se ve afectado por una interrupción de tu servicio Active Directory local. El patrón es adecuado para casos prácticos de continuidad de negocio u otros escenarios que requieran alta disponibilidad.
- Puedes limitar la comunicación entre tu red on-premise 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 forma 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 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 a un dominio que se ejecuten enGoogle Cloud sigan necesitando comunicarse con los controladores de dominio de los dominios no replicados. Asegúrate de que las reglas de cortafuegos que se aplican a la comunicación entre el entorno local y Google Cloud tengan en cuenta todos los casos pertinentes.
- Ten en cuenta que la replicación entre sitios se produce solo a determinados intervalos, por lo que las actualizaciones realizadas en un controlador de dominio local se reflejan enGoogle Cloud solo después de un tiempo (y viceversa).
- Te recomendamos que utilices controladores de dominio de solo lectura (RODCs) para mantener una copia de solo lectura de los datos del dominio en Google Cloud, pero ten en cuenta que hay un equilibrio entre el almacenamiento en caché de las contraseñas de los usuarios. Si permites que los RODCs almacenen en caché las contraseñas y que 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, las ventajas de seguridad de usar un RODC en lugar de un controlador de dominio normal son limitadas. Si inhabilitas el almacenamiento en caché de contraseñas, un RODC vulnerado solo podría suponer un riesgo limitado para el resto de tu Active Directory, pero perderás la ventaja de queGoogle Cloud no se vea afectado por una interrupción de los controladores de dominio locales.
Bosque extenso
En el patrón de bosque extendido, se despliega un nuevo dominio de Active Directory en Google Cloud, pero se integra en el bosque ya creado. Utilizas el nuevo dominio para gestionar los recursos implementados en Google Cloud y para mantener un conjunto mínimo de cuentas de usuario administrador para gestionar el dominio.
Al ampliar las relaciones de confianza implícitas a otros dominios del bosque, permites que los usuarios de otros dominios se autentiquen y accedan a los recursos gestionados por el dominio de Active Directory alojado en Google Cloud.
Usa el patrón de bosque extendido si se da una o varias de las siguientes circunstancias:
- El uso que quieres dar a Google Cloud se ajusta a uno de los patrones de implementación distribuidos y se acepta una dependencia entre tu entorno local y Google Cloud .
- Los recursos que tienes previsto implementar Google Cloud requieren una configuración o estructura de dominio diferente a la que proporcionan tus dominios actuales, o bien quieres conceder un alto nivel de autonomía administrativa a los equipos que administran el dominio alojado en Google Cloud.
- Esperas una interacción de moderada a intensa entre los recursos gestionados por Active Directory en las instalaciones y en Google Cloud.
- Tienes muchos usuarios que necesitan acceder a 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 forma 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 puede ayudarte a limitar el consumo general de ancho de banda.
- Puedes conceder un alto nivel de autonomía administrativa a los equipos que gestionan el dominio de Active Directory alojado en Google Cloud.
Prácticas recomendadas:
- Usa conexiones redundantes de Interconexión dedicada, Partner Interconnect o Cloud VPN para asegurar una conectividad de red de alta disponibilidad entre tu red on-premise y Google Cloud.
Bosque de recursos con dominio ampliado
El patrón bosque de recursos con dominio extendido es una extensión del patrón bosque de recursos. El patrón de bosque de recursos te permite mantener un límite de confianza entre 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 una conectividad de red fiable con tu centro de datos local.
Puedes superar estas limitaciones combinando el patrón de bosque de recursos con el patrón de dominio extendido. Al replicar el dominio, tus cuentas de usuario se encuentran en Google Cloudy puedes asegurarte de 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 red.
Te recomendamos que uses el bosque de recursos con el patrón de dominio ampliado si se da alguna de las siguientes circunstancias:
- Quieres mantener un límite de confianza entre tu bosque principal de Active Directory y el bosque de recursos.
- Quieres evitar que una interrupción de los controladores de dominio locales o la pérdida de conectividad de red con tu entorno local afecte a tus cargas de trabajo alojadas enGoogle Cloud.
- Esperas una interacción moderada entre los recursos gestionados por Active Directory on-premise y en Google Cloud.
- Tienes muchos usuarios de un solo dominio de Active Directory que necesitan acceder a 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. Este patrón es adecuado para casos prácticos de continuidad empresarial u otras situaciones que requieran una alta disponibilidad.
- Este patrón te permite mantener un límite de confianza entre los dos bosques de Active Directory. En función de cómo se configure la relación de confianza, un atacante que vulnere un entorno podría obtener poco o ningún acceso al otro.
- La comunicación entre tu red on-premise y la red Google Cloud se limita a la replicación de Active Directory entre controladores de dominio. Puedes implementar reglas de cortafuegos para rechazar todas las demás comunicaciones, lo que refuerza el aislamiento entre entornos.
- Puedes conceder un alto nivel de autonomía administrativa a los equipos que gestionan el bosque de Active Directory alojado en Google Cloud.
- Puedes usar Microsoft AD gestionado para el bosque de recursos.
Prácticas recomendadas:
- Implementa controladores de dominio para el dominio ampliado en unGoogle Cloud proyecto y una VPC independientes para separar estos componentes de los componentes del bosque de recursos.
- Usa el emparejamiento de VPC para conectar la VPC a la VPC compartida o a la VPC que usa el bosque de recursos y configura cortafuegos para restringir la comunicación a la autenticación de usuarios de Kerberos y a la creación de relaciones de confianza entre bosques.
- Conecta los dos bosques de Active Directory mediante una relación de confianza unidireccional para que el Active Directory alojado en Google Cloudconfíe en tu bosque de Active Directory, 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.
- Tenga en cuenta que la replicación entre sitios solo se produce a intervalos determinados, por lo que las actualizaciones realizadas en un controlador de dominio local solo se reflejan enGoogle Cloud después de un tiempo (y viceversa).
- Te recomendamos que uses RODCs para el dominio extendido, pero asegúrate de permitir el almacenamiento en caché de contraseñas para mantener las ventajas de disponibilidad en comparación con el patrón de bosque de recursos.
Siguientes pasos
- Consulta más información sobre Microsoft AD gestionado.
- Consulta las prácticas recomendadas para desplegar un bosque de recursos de Active Directory en Google Cloud.
- Consulta cómo desplegar un entorno de Active Directory tolerante a fallos en Google Cloud.
- Consulta nuestras prácticas recomendadas sobre el diseño de VPCs.
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.