Mejores prácticas para ejecutar Active Directory en Google Cloud

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Esta guía presenta las mejores prácticas para ejecutar Active Directory en Google Cloud. La guía se centra en prácticas que son específicas de Google Cloud o de particular importancia al implementar Active Directory en Google Cloud. Considere que la guía complementa las mejores prácticas generales para proteger Active Directory publicadas por Microsoft .

Arquitectura

Las siguientes secciones detallan las mejores prácticas relacionadas con la arquitectura.

Utilice el patrón de arquitectura que mejor se adapte a sus necesidades

Para implementar Active Directory en Google Cloud, primero debe decidir qué dominio y arquitectura de bosque utilizar. Si ya utiliza Active Directory, también debe decidir si integra los dos entornos y cómo hacerlo.

El diseño que mejor se adapte a su situación depende de una serie de factores, incluido el diseño de su red local, la forma en que la red local yGoogle Cloud van a interactuar los recursos, así como sus requisitos de disponibilidad y autonomía administrativa. Consulte nuestros patrones para usar Active Directory en un entorno híbrido para ver cómo estos factores deben determinar su diseño.

Si desea mantener un límite de confianza entreGoogle Cloud y su entorno local, considere implementar el patrón de bosque de recursos . En este patrón, implementa un bosque separado en Google Cloud y utilizar un fideicomiso forestal unidireccional para integrar el Google Cloud bosque con su bosque de Active Directory local existente.

Pruebas y producción separadas

Dependiendo de su uso de Active Directory, puede que sea necesario realizar cambios frecuentes en Active Directory durante el desarrollo y prueba de aplicaciones. Es posible que los desarrolladores necesiten poder crear y modificar cuentas de Active Directory , cambiar las membresías de grupos si las aplicaciones usan grupos para manejar la autorización, o unirse y eliminar computadoras.

Para evitar que el trabajo de desarrollo y pruebas afecte las cargas de trabajo de producción o obstaculice la seguridad de su implementación, considere implementar un dominio o bosque de Active Directory separado para desarrollo y pruebas.

Tener un dominio o bosque de desarrollo y prueba separado también le permite verificar los cambios administrativos antes de aplicarlos a la producción. Ejemplos de tales cambios incluyen experimentar con políticas de grupo, probar scripts de automatización o acciones potencialmente riesgosas, como elevar el nivel funcional de un bosque.

Configurar la federación de Cloud Identity además de implementar Active Directory en Google Cloud

Implementación de Active Directory en Google Cloud le permite administrar máquinas virtuales Windows en Google Cloud, puede permitir a los usuarios iniciar sesión en máquinas virtuales de Windows utilizando sus cuentas de usuario existentes y admite aplicaciones que dependen de Kerberos, NTLM o LDAP para la autenticación.

Sin embargo, para usar la consola de Google Cloud , la herramienta de línea de comandos gcloud u otros servicios de Google y Google Cloud herramientas, debe autenticarse con una identidad de Google. Implementación de Active Directory en Google Cloud Por lo tanto, no reemplaza la federación de su Active Directory existente conGoogle Cloud si tiene la intención de utilizar Active Directory como su sistema principal para administrar usuarios.

Por ejemplo, si implementa un bosque separado en Google Cloud, luego podrá configurar la federación en su Active Directory local como se ilustra en el siguiente diagrama. Los usuarios con cuentas en Active Directory local pueden usar herramientas que requieren una identidad de Google, así como sus aplicaciones que dependen de Active Directory para la autenticación.

Si, en cambio, decide ampliar su bosque o dominio existente a Google Cloud, también tiene la opción de usar controladores de dominio y servidores AD FS implementados en Google Cloud para constituir la federación.

La federación también le permite imponer un ciclo de vida común para las cuentas de Google y las cuentas de Active Directory, de modo que cuando deshabilita una cuenta de usuario en su Active Directory local, el usuario de Google correspondiente también se suspende.

Redes

La siguiente sección detalla las mejores prácticas relacionadas con la creación de redes.

Implementar Active Directory en una red de VPC compartida

Para permitir que Active Directory se utilice en varios proyectos, implemente controladores de dominio en una red de VPC compartida. Usar una red VPC compartida tiene múltiples ventajas:

• Cada aplicación que pueda requerir acceso a Active Directory puede potencialmente implementarse en un proyecto separado. El uso de proyectos separados ayuda a aislar los recursos y le permite administrar el acceso individualmente.

• Puede utilizar un proyecto dedicado para controladores de dominio de Active Directory, que le permite un control detallado sobre cuáles de sus usuarios pueden acceder a sitios relacionados. Google Cloud recursos.

• Las redes de VPC compartidas le permiten centralizar la administración de direcciones IP y la configuración del firewall, lo que ayuda a garantizar la coherencia entre múltiples proyectos.

Como las VPC son un recurso global , puede utilizar la misma red de VPC compartida en varias regiones.

No exponga controladores de dominio externamente

Para reducir la superficie de ataque de Active Directory, evite asignar direcciones IP externas a controladores de dominio.

Debido a que las instancias de VM sin direcciones IP externas no tienen acceso a Internet de forma predeterminada, debe tomar medidas adicionales para garantizar que la activación y las actualizaciones de Windows no se vean afectadas en los controladores de dominio.

Para admitir la activación de Windows, habilite el acceso privado a Google en la subred en la que planea implementar controladores de dominio y asegúrese de que las instancias de VM puedan acceder a kms.windows.googlecloud.com . Esto permite que la activación se realice sin acceso directo a Internet.

Hay varias opciones para admitir actualizaciones de Windows:

• Si tiene un servidor WSUS local, puede configurar la conectividad híbrida y configurar sus controladores de dominio para usar el servidor WSUS como fuente de actualizaciones.

• Puede habilitar el acceso a Internet a través de una puerta de enlace NAT implementando Cloud NAT .

• Si ha configurado la conectividad híbrida, también puede enrutar el tráfico saliente a través de una puerta de enlace NAT local o un servidor proxy.

Reserve direcciones IP estáticas para controladores de dominio con anticipación

Debido a que los controladores de dominio funcionan como servidores DNS, se les debe asignar una dirección IP que no cambie . Para lograrlo, configure direcciones IP internas estáticas para las máquinas virtuales del controlador de dominio.

Cuando reserva una dirección IP, el comportamiento predeterminado es que se elige automáticamente una dirección no utilizada. Para garantizar que las direcciones IP de los controladores de dominio sean fáciles de memorizar, reserve una dirección IP estática interna .

En los controladores de dominio, configure la dirección IP del adaptador de red en la misma dirección. Aunque este paso es opcional, evita que Active Directory emita mensajes de advertencia que indiquen que la dirección IP de la máquina aún podría estar asignada dinámicamente.

Implemente controladores de dominio en múltiples zonas

Para aumentar la disponibilidad, implemente al menos dos controladores de dominio y distribúyalos en varias zonas . Dado que las subredes y las direcciones IP no están vinculadas a una zona, puede implementar todos los controladores de dominio en una única subred.

Si planea implementar cargas de trabajo en varias regiones, considere implementar controladores de dominio en cada región relevante. Dado que las subredes son un recurso regional , la implementación en una región adicional requerirá una subred adicional.

Crear un sitio por región

Cuando un cliente intenta localizar un controlador de dominio , primero buscará un controlador de dominio en el sitio de Active Directory que corresponda a la dirección IP del cliente. Si no hay ningún controlador de dominio disponible en este sitio, el cliente continuará e intentará localizar un controlador de dominio en un sitio diferente.

Puede aprovechar este comportamiento creando un sitio separado para cada región en la que implemente controladores de dominio o clientes de dominio. Los clientes preferirán automáticamente usar controladores de dominio ubicados en la misma región, lo que puede ayudar a reducir la latencia y el costo de transferencia de datos salientes entre regiones .

Si tiene clientes en regiones que no tienen un controlador de dominio, puede influir en qué controladores de dominio eligen estos clientes ajustando los costos de vínculos a sitios para reflejar la cercanía geográfica de las regiones y habilitando la configuración Probar el siguiente sitio más cercano .

El uso de varios sitios influye en el comportamiento de replicación entre controladores de dominio. Una desventaja de utilizar varios sitios puede ser que la replicación entre sitios se produce con menos frecuencia que la replicación dentro de un sitio.

Sin embargo, no puede crear sitios de Active Directory en Microsoft AD administrado porque Microsoft AD administrado no admite la función Sitios y servicios de Active Directory.

Usar zonas de reenvío privado de Cloud DNS

Cuando creas una nueva instancia de VM en Compute Engine, el sistema operativo estará preconfigurado para usar un servidor DNS predeterminado que proporciona acceso al DNS interno y al DNS público.

Antes de poder unir una máquina a un dominio de Active Directory, debe asegurarse de que la máquina pueda resolver los registros DNS administrados por Active Directory. El servidor DNS predeterminado que Compute Engine configura para una instancia de VM proporciona acceso al DNS interno y al DNS público, pero no podrá resolver nombres DNS administrados por Active Directory.

Cree una zona de reenvío de DNS privada en Cloud DNS para permitir a los clientes resolver registros DNS administrados por Active Directory. Configure la zona para reenviar consultas que coincidan con su dominio de Active Directory a sus controladores de dominio.

Usar una zona de reenvío de DNS privada tiene múltiples ventajas sobre la configuración de clientes para usar directamente sus controladores de dominio de Active Directory como servidores DNS:

• No es necesario ajustar la configuración de red de las instancias de VM. Esto simplifica el proceso de creación de nuevas máquinas virtuales.

• Cuando asciende o degrada un controlador de dominio, solo necesita actualizar la configuración de la zona de reenvío DNS privada y no necesita modificar ninguna configuración del cliente.

• Las instancias de VM todavía tienen acceso al DNS interno .

• Cualquier registro DNS que no coincida con su dominio de Active Directory será manejado por Cloud DNS, lo que reduce la carga en sus controladores de dominio.

Si utiliza varios dominios, cree una zona de reenvío de DNS privada independiente para cada dominio de Active Directory.

Las zonas de reenvío privado de Cloud DNS tienen como ámbito una única VPC. Si utiliza varias VPC conectadas mediante emparejamiento , puede exponer las zonas de reenvío privadas a otras VPC configurando el emparejamiento DNS .

Aún debe configurar manualmente los ajustes de DNS en los controladores de dominio. Utilice 127.0.0.1 como servidor DNS principal y, opcionalmente, utilice la dirección IP de otro controlador de dominio como servidor DNS secundario. Para obtener más información, consulte Configuración de DNS recomendada y opciones alternativas .

Conectividad híbrida

La siguiente sección detalla las mejores prácticas relacionadas con la conectividad híbrida.

Utilice el reenvío entrante de DNS para resolver Google Cloud Nombres DNS locales

Es posible que los clientes de su red local necesiten poder resolver los nombres DNS de los recursos implementados en Google Cloud. Si amplía su bosque o implementa un bosque de recursos enGoogle Cloudy luego use el reenvío entrante de DNS para permitir que los clientes locales busquen registros DNS para recursos implementados en Google Cloud. Para utilizar el reenvío entrante, cree una política de servidor DNS para asignar una dirección IP de reenvío entrante y hacer que esta dirección sea accesible para la red local.

Si el dominio DNS utilizado en Google Cloud (por ejemplo, cloud.example.com ) es un subdominio del dominio DNS utilizado localmente (por ejemplo, example.com ), luego configure la delegación de DNS. Cree un registro NS en el dominio local que apunte a la dirección IP del reenviador entrante. El registro NS hace que los clientes intenten buscar un nombre DNS en el Google Cloud-dominio alojado que se redirigirá a la dirección IP del reenviador entrante.

Si los dominios DNS utilizados en Google Cloud y su Active Directory local son diferentes (por ejemplo, cloud.example.com y corp.example.com ), luego configure el reenvío de DNS condicional en sus dominios locales y use la dirección IP del reenviador entrante como destino. Cuando se le solicita resolver un nombre DNS en el Google Cloud-dominio alojado, los controladores de dominio locales reenviarán la búsqueda a la dirección IP del reenviador entrante.

Cuando utilice el reenvío de DNS entrante, asegúrese de que sus firewalls estén configurados adecuadamente .

El reenvío entrante de DNS no es necesario si extiende su dominio existente a Active Directory. En este escenario, todos los registros DNS del dominio se replican automáticamente en Google Cloud y su entorno local y estarán disponibles para su búsqueda en ambos entornos.

Utilice el reenvío saliente de DNS para resolver nombres DNS locales desde Google Cloud

Clientes ejecutándose en Google Cloud Es posible que deba poder resolver los nombres de los recursos implementados en las instalaciones. Si amplía su bosque o implementa un bosque de recursos en Google Cloudy luego cree una zona de reenvío privada en Cloud DNS para reenviar consultas de DNS para sus dominios locales a sus servidores DNS locales.

Cuando utilice el reenvío de DNS saliente, asegúrese de que sus firewalls estén configurados adecuadamente .

El reenvío saliente de DNS no es necesario si extiende su dominio existente a Active Directory. En este escenario, todos los registros DNS del dominio se replican automáticamente en Google Cloud y su entorno local, y estarán disponibles para su búsqueda en ambos entornos.

Utilice túneles VPN para proteger el tráfico LDAP

Active Directory hace un uso extensivo del protocolo LDAP. A diferencia de la mayoría de los demás protocolos utilizados por Active Directory, LDAP no está cifrado de forma predeterminada.

Google Cloud garantiza que el tráfico entre máquinas virtuales esté cifrado, por lo que es aceptable utilizar LDAP sin cifrar dentro de su VPC. Si conecta su VPC a una red local, asegúrese de que el tráfico LDAP solo se intercambie a través de canales confiables.

Si usa Cloud VPN para conectarse Google Cloud y su red local, el tráfico se cifra automáticamente mediante IPSec entreGoogle Cloud y su punto final VPN local.

Cloud Interconnect y Partner Interconnect no proporcionan cifrado. Para garantizar una comunicación segura, establezca un túnel VPN a través de la conexión de interconexión mediante un dispositivo VPN de Google Cloud Marketplace .

Utilice autenticación selectiva y AES para confianzas forestales

Al crear una relación de confianza entre bosques de Active Directory, prefiera las confianzas de bosque a las confianzas externas y aproveche las siguientes características para mejorar la seguridad:

• Habilite la autenticación selectiva en confianzas salientes en el bosque de recursos. La autenticación selectiva garantiza que los usuarios del bosque organizacional no puedan acceder a los recursos del bosque de recursos a menos que se les otorgue permiso explícitamente.

• Habilite la aplicación de los límites del bosque para la delegación completa de Kerberos en confianzas entrantes en el bosque organizacional. Esta característica ayuda a prevenir ataques de escalada de privilegios al no permitir que los recursos del bosque de recursos soliciten tickets de concesión de tickets (TGT) a los usuarios del bosque organizacional.

• Habilite la opción El otro dominio admite el cifrado Kerberos AES al crear confianzas. Esta opción garantiza que los tickets que se utilizan para la autenticación entre bosques estén cifrados mediante AES en lugar del algoritmo RC4, menos seguro.

Seguridad

La siguiente sección detalla las mejores prácticas relacionadas con la seguridad.

Evitar Google Cloud seguridad que interfiere con la seguridad de Active Directory

Active Directory le brinda un control detallado sobre qué usuarios pueden acceder a qué recursos. Cuando las máquinas se implementan como instancias de VM en Compute Engine y los usuarios tienen acceso al subyacente Google Cloudproyecto, debe considerar rutas adicionales que podrían permitir a un usuario acceder a una máquina:

• Un miembro del proyecto al que se le ha asignado la función de administrador de instancia informática en un proyecto de Google Cloud puede usar la función de restablecimiento de contraseña para crear cuentas de administrador local. Las cuentas de administrador local representan una amenaza para la seguridad de su dominio de Active Directory, ya que pueden usarse para socavar las políticas de grupo o para instalar software malicioso que podría capturar las credenciales de dominio de otros usuarios que hayan iniciado sesión.

• Al agregar un script de inicio , un miembro privilegiado del proyecto puede inyectar código malicioso en una máquina virtual que se ejecuta como nt authority\system la próxima vez que se reinicie la máquina.

• Al utilizar la consola serie , un miembro privilegiado del proyecto también puede acceder a la Consola de administración especial (SAC) de Windows. Windows considera los inicios de sesión a través del SAC como inicios de sesión locales. Por lo tanto, se puede hacer un mal uso del SAC para evadir políticas que niegan los inicios de sesión a través de RDP, pero no deniegan los inicios de sesión locales.

• Un miembro privilegiado del proyecto puede utilizar el SAC para emitir un comando crashdump , lo que puede provocar que un volcado de memoria se escriba en el disco. Un volcado de memoria de este tipo podría incluir información y credenciales confidenciales.

• Al montar el disco persistente en una máquina virtual diferente o usar instantáneas, un miembro privilegiado del proyecto podría acceder al contenido del disco, incluidos potencialmente los volcados de memoria, desde máquinas en las que el usuario de otro modo no tendría permiso para iniciar sesión.

Al utilizar Microsoft AD administrado, estará mejor protegido contra estas rutas de acceso adicionales de forma predeterminada. El servicio no permite que los usuarios privilegiados de su proyecto restablezcan la contraseña del administrador de dominio, ejecuten scripts de inicio o accedan a la consola serie en las máquinas virtuales del controlador de dominio AD.

Para mitigar aún más estos riesgos, asegúrese de que los permisos de IAM de los proyectos que contienen instancias de VM unidas a un dominio se administren con privilegios mínimos. Puede reducir aún más el riesgo por parte del usuario de políticas de organización, políticas de grupo y máquinas virtuales protegidas:

• Utilice una política organizacional para deshabilitar el acceso al puerto serie.

• Aplique una política de grupo que impida la creación de cuentas de administrador local deshabilitando el administrador de cuentas . Defina una preferencia de Archivos INI en su política de grupo (Configuración del equipo > Preferencias > Configuración de Windows > Archivos Ini) para aplicar la siguiente configuración:

  • Acción: Actualizar
  • Ruta del archivo: C:\Program Files\Google\Compute Engine\instance_configs.cfg
  • Nombre de la sección: accountManager
  • Nombre de propiedad: disable
  • Valor de la propiedad: true

• Aplique una política de grupo que elimine cualquier cuenta de administrador local de las instancias de VM. Utilice la funcionalidad Usuarios y grupos locales (Configuración de la computadora > Preferencias > Configuración del panel de control > Usuarios y grupos locales) para eliminar la membresía del grupo Administradores y otros grupos confidenciales.

• Considere el uso de máquinas virtuales blindadas en combinación con el cifrado de disco BitLocker para evitar que usuarios no autorizados puedan leer el disco persistente o las instantáneas.

Evite que la seguridad de Active Directory interfiera con Google Cloud seguridad

En un dominio de Active Directory, las máquinas confían en los controladores de dominio para manejar la autenticación y la autorización en su nombre. A menos que esté restringido por una política de grupo, la política de seguridad local de una máquina o una autenticación selectiva, un usuario que haya demostrado exitosamente su identidad ante uno de los controladores de dominio puede iniciar sesión en cualquier máquina del dominio.

La capacidad de los usuarios de Active Directory de iniciar sesión en cualquier máquina podría permitir a los atacantes realizar movimientos laterales dentro de un dominio. Estos movimientos laterales pueden dar lugar a escaladas de privilegios si algunas instancias de VM están exentas de restricciones de firewall o de uso. Google Cloud cuentas de servicio : las credenciales de una cuenta de servicio son accesibles para todos los procesos y usuarios en una instancia de VM. Por lo tanto, cualquier usuario que pueda utilizar Active Directory para iniciar sesión en una máquina puede acceder a estas credenciales de cuenta de servicio para obtener acceso a cualquier Google Cloudrecursos a los que se concede acceso a la cuenta de servicio.

Al configurar Microsoft AD administrado, el servicio crea un grupo para permitir que usuarios específicos puedan realizar RDP en máquinas virtuales unidas a un dominio.

Para reducir el riesgo de movimientos laterales, organice a los usuarios en niveles administrativos y utilice las políticas de grupo Denegar acceso a esta computadora desde la red y Denegar inicio de sesión a través de Servicios de Escritorio remoto para restringir el acceso a sus máquinas virtuales según el nivel de nivel.

En una topología de bosque de recursos , aproveche adicionalmente la autenticación selectiva para restringir aún más el conjunto de usuarios de otros bosques a los que se les permite iniciar sesión en sus máquinas virtuales. Puede simplificar la gestión de permisos de autenticación selectiva alineando Google Cloud y estructuras de recursos de Active Directory : si las unidades organizativas de Active Directory se asignan a proyectos de Google Cloud, puede otorgar a los usuarios el derecho a autenticarse en un nivel que coincida con un proyecto de Google Cloud.

En los casos en los que no se apliquen ni la autenticación selectiva ni las políticas de grupo, cree una cuenta de servicio separada, exporte las claves de la cuenta de servicio , guárdelas en el disco local de la instancia de VM o en un archivo compartido y protéjalas usando una ACL NTFS para que solo los usuarios autorizados de Active Directory puedan leer y usar las claves.

Utilice proyectos dedicados para controladores de dominio

Los controladores de dominio desempeñan un papel crucial en la seguridad de un dominio de Active Directory y el compromiso de un único controlador de dominio puede resultar en el compromiso de todo su bosque de Active Directory.

Para limitar el riesgo de acceso no autorizado, utilice un proyecto de Google Cloud independiente para implementar controladores de dominio y otorgar acceso a este proyecto con privilegios mínimos. Al crear el proyecto, tenga en cuenta que algunos permisos pueden heredarse de las carpetas principales . Para evitar otorgar acceso inadvertidamente mediante herencia, considere crear el proyecto fuera de su jerarquía de carpetas habitual.

Al configurar políticas de IAM para el proyecto, preste especial atención a restringir el acceso a las instancias de VM, los discos persistentes que contienen la base de datos ntds.dit , así como cualquier ubicación de almacenamiento que pueda contener copias de seguridad.

Además de utilizar políticas de IAM para limitar el acceso al proyecto, proteja el proyecto contra una eliminación accidental .

Utilice máquinas virtuales y proyectos separados para administrar Active Directory

Para administrar Active Directory, debe poder utilizar herramientas como Usuarios y computadoras de Active Directory o el Centro administrativo de Active Directory . Estas herramientas requieren que inicie sesión con una cuenta de dominio privilegiada, lo que hace que la máquina en la que ejecuta estas herramientas sea un objetivo atractivo para el robo de credenciales o el registro de teclas.

Para minimizar el riesgo de que un atacante obtenga credenciales de dominio privilegiadas, utilice instancias de VM dedicadas para la administración del dominio y maneje dichas máquinas virtuales de administración, como estaciones de trabajo con acceso privilegiado :

• Utilice políticas de grupo para garantizar que solo un subconjunto seleccionado de usuarios tenga derecho a iniciar sesión en las máquinas virtuales de administración. Si implementó administración por niveles, este grupo de usuarios corresponde al Nivel 0.

• Al igual que los controladores de dominio, los miembros del proyecto pueden poner en riesgo las máquinas virtuales administrativas al crear cuentas de administrador local , iniciar sesión a través de la consola serie o alterar sus discos persistentes. Para limitar el riesgo de acceso no autorizado, utilice un proyecto de Google Cloud independiente para las máquinas virtuales administrativas y otorgue acceso a este proyecto con privilegios mínimos.

Si planea acceder a las máquinas virtuales administrativas desde una red local mediante conectividad híbrida , implemente las máquinas virtuales administrativas en una subred de VPC dedicada. Una subred dedicada a las máquinas virtuales de administración le permite distinguir mejor entre las máquinas virtuales administrativas y otras máquinas virtuales al configurar sus firewalls locales. Si utiliza una VPC compartida , utilice permisos a nivel de subred para garantizar que solo los administradores con privilegios puedan implementar instancias de VM en la subred de administración. Esta práctica ayuda a garantizar que, si los firewalls locales aplican reglas diferentes para las máquinas virtuales de administración que para otras máquinas virtuales, los usuarios no puedan evadir las reglas del firewall colocando máquinas virtuales que no sean de administración en la subred de administración.

Además, considere restringir la política de grupo que administra las restricciones de inicio de sesión para las máquinas virtuales de administración a la subred de administración. Esta práctica exige la alineación entre las restricciones de inicio de sesión (basadas en una política de grupo) y las reglas de firewall (basadas en la subred/dirección IP).

Además de utilizar políticas de IAM para limitar el acceso al proyecto, proteja el proyecto contra una eliminación accidental .

Utilice reglas de firewall para proteger servidores y controladores de dominio

Los controladores de dominio exponen una serie de servicios, incluidos LDAP, DNS, Kerberos y RPC. Dependiendo de sus casos de uso, las máquinas virtuales implementadas en Google Cloud, así como las máquinas que se ejecutan localmente, pueden necesitar acceso a diferentes subconjuntos de estos servicios para aprovechar Active Directory.

Cuando se utiliza Microsoft AD administrado, los controladores de dominio de AD se implementan en un proyecto de inquilino dedicado. La red que aloja los controladores de dominio de AD está protegida automáticamente con reglas de firewall reforzadas específicas de AD.

Para reducir la superficie de ataque de los controladores de dominio y sus máquinas virtuales, utilice firewalls para impedir cualquier comunicación de red que no sea estrictamente necesaria. Consulte nuestra guía sobre el uso de Active Directory en firewalls para obtener detalles sobre qué configuraciones de firewall son necesarias para acceder a Active Directory desde su VPC o desde redes locales.

Organice los recursos y usuarios de Active Directory en niveles administrativos

Algunas máquinas en un bosque de Active Directory son más críticas que otras para la seguridad general de Active Directory. Los controladores de dominio y las máquinas virtuales administrativas son dos ejemplos de máquinas que son particularmente críticas y, por lo tanto, particularmente sensibles a posibles ataques.

Para identificar la criticidad de cada una de sus máquinas, utilice una taxonomía de niveles. Si bien la cantidad correcta de niveles depende de su configuración específica, puede comenzar distinguiendo entre tres niveles:

• Nivel 0 (altamente crítico) : este nivel incluye todas las máquinas que son críticas para la seguridad de su bosque de Active Directory. Una vez que una sola máquina de nivel 0 se ve comprometida, debe asumir que todo su bosque está comprometido.

• Nivel 1 (crítico) : este nivel incluye la mayoría de los servidores de su entorno, incluidos servidores de aplicaciones y servidores de bases de datos. Un servidor de nivel 1 comprometido podría tener un impacto empresarial sustancial, pero no representa una amenaza inmediata para todo el bosque.

• Nivel 2 (Normal) : este nivel incluye estaciones de trabajo u otras máquinas de uso general. Se espera que el compromiso de una máquina de nivel 2 tenga un impacto limitado en el negocio y en la seguridad general.

Aunque el impacto inmediato de una máquina de nivel 2 comprometida puede parecer limitado, existe el riesgo de efectos en cadena: cuando un usuario que tiene acceso administrativo a máquinas de nivel 0 o 1 es atraído a iniciar sesión en una máquina de nivel 2 comprometida, puede ser víctima de un registrador de pulsaciones de teclas u otras formas de robo de credenciales. Las credenciales capturadas podrían luego usarse para atacar máquinas de niveles superiores, lo que provocaría que el impacto general aumentara.

Para evitar tales efectos en cadena, asegúrese no solo de categorizar las máquinas, sino también las cuentas de usuario, y restringir a qué conjunto de máquinas tienen acceso estos usuarios:

• Nivel 0 (altamente crítico) : usuarios que tienen acceso a máquinas de nivel 0.

• Nivel 1 (crítico) : usuarios que tienen acceso a máquinas de nivel 1.

• Nivel 2 (Normal) : usuarios que tienen acceso a máquinas de nivel 2.

Utilice la siguiente tabla como guía para saber qué usuarios deberían tener acceso a qué recursos:

Consulte la documentación de Microsoft para obtener más detalles y mejores prácticas sobre la implementación de un modelo de nivel administrativo en Active Directory.

Cuando utilice el modelo de nivel administrativo en su bosque de Active Directory, asegúrese de que las relaciones de confianza del bosque no socaven su integridad. Si el bosque de confianza también aplica un modelo de administración por niveles, utilice la autenticación selectiva para garantizar que los usuarios del bosque de confianza solo puedan acceder a recursos dentro del mismo nivel:

Si el bosque de confianza no implementa una administración por niveles, asigne el bosque de confianza a un nivel determinado y utilice la autenticación selectiva para garantizar que los usuarios del bosque de confianza solo puedan acceder a los recursos de ese nivel en particular.

Uso de controles de servicio VPC y acceso privado a Google para hosts locales

Las API administradas de Microsoft AD permiten restablecer la contraseña del administrador y realizar otras operaciones confidenciales. Para implementaciones de producción críticas, recomendamos habilitar los controles de servicio de VPC y utilizar el acceso privado a Google para hosts locales para aumentar la seguridad.

Gestión

La siguiente sección detalla las mejores prácticas relacionadas con la administración de Active Directory.

Alinear Google Cloud y estructuras de recursos de Active Directory

Cuando implementa un nuevo dominio o bosque de Active Directory enGoogle Cloud, debe definir una estructura de unidad organizativa (OU) para organizar sus recursos con su dominio de Active Directory. En lugar de diseñar una estructura completamente nueva o aplicar la estructura que utiliza en su entorno local, cree una estructura de unidad organizativa que esté alineada con su Google Cloud jerarquía de recursos :

• Si utiliza un modelo de administración por niveles , las unidades organizativas de nivel superior deben reflejar sus niveles administrativos.

• Para cada nivel, cree unidades organizativas para usuarios y grupos. Si planea administrar una gran cantidad de usuarios y grupos, cree subunidades organizativas según corresponda.

• Para cada nivel, cree una unidad organizativa Projects y cree subunidades organizativas para cada proyecto de Google Cloud que contenga recursos de Active Directory. Utilice la subunidad organizativa específica del proyecto para administrar cuentas de computadora, cuentas de servicio u otros recursos de Active Directory que correspondan a Google Cloudrecursos del respectivo proyecto. Asegúrese de que haya una asignación 1:1 entre las unidades organizativas y los proyectos.

El siguiente diagrama muestra un ejemplo de jerarquía que sigue estos principios:

Si la cantidad de proyectos que contienen recursos de Active Directory es moderada, puede crear una estructura de unidad organizativa plana en la unidad organizativa Projects . Si esperas gestionar una gran cantidad de proyectos y has diseñado tuGoogle Cloud jerarquía de recursos para usar múltiples niveles de carpetas, luego considere reflejar esta estructura de carpetas debajo de la unidad organizativa Projects .

Alinear la estructura de su unidad organizativa de Active Directory y Google Cloud La jerarquía de recursos tiene varias ventajas:

• Cuando delega permisos administrativos a un proyecto de Google Cloud mediante políticas de IAM, es posible que también deba otorgar a los usuarios del proyecto ciertos privilegios en Active Directory. Por ejemplo, es posible que los administradores de Compute Engine necesiten poder unir máquinas al dominio bajo una determinada unidad organizativa. Alinear las unidades organizativas y los proyectos de Google Cloud le permite otorgar dichos permisos con el mismo nivel de granularidad en Active Directory que en Google Cloud.

• Si planea utilizar objetos de política de grupo (GPO) para administrar computadoras, entonces una estructura de unidad organizativa que refleje las Google Cloud La jerarquía de recursos le ayuda a garantizar que los GPO se apliquen de forma coherente a todas las máquinas virtuales de un proyecto o carpeta determinado.

• Si utiliza una confianza entre bosques con autenticación condicional, puede usar las unidades organizativas que corresponden a los proyectos de Google Cloud para otorgar el permiso Permitido para autenticar por proyecto.

• Cuando eliminas un proyecto en Google Cloud, simplemente puede eliminar la unidad organizativa asociada, lo que reduce el riesgo de dejar recursos obsoletos en su directorio.

Si cree que la estructura de su unidad organizativa debe desviarse de la estructura de su proyecto, entonces esto podría ser una indicación de que la estructura de su proyecto es demasiado detallada o demasiado gruesa.

Utilice los servidores de hora de Google

La autenticación de Kerberos se basa en las marcas de tiempo como parte de su protocolo. Para que la autenticación tenga éxito, los relojes del cliente y la máquina del servidor deben sincronizarse dentro de un cierto margen. Por defecto, Active Directory no permite más de 5 minutos de diferencia.

En un entorno de Active Directory en las instalaciones, la siguiente es la configuración predeterminada para el tiempo de sincronización:

• Las máquinas unidas por dominio sincronizan su tiempo con un controlador de dominio.
• Los controladores de dominio sincronizan su tiempo con el emulador PDC de su dominio.
• Los emuladores de PDC de todos los dominios sincronizan su tiempo con el emulador PDC del dominio de la raíz del bosque.

En esta configuración, el emulador PDC del dominio de la raíz del bosque es la fuente final de tiempo para Active Directory, y es común configurar esta máquina para usar un servidor NTP externo como fuente de tiempo.

En el motor Compute, la configuración predeterminada para Windows VMS es usar el servidor de metadatos ( metadata.google.internal ) como servidor NTP, que a su vez se basa en los servidores NTP de Google para obtener el tiempo correcto. Unirse a una VM a un dominio de Active Directory no cambia esta configuración predeterminada.

Mantenga la configuración predeterminada del motor de cómputo a menos que el emulador PDC de su dominio de la raíz del bosque esté implementado fuera de Google Cloud.

Si su emulador PDC se implementa fuera de Google Cloud, Confígalo para usar time.google.com como fuente NTP . Alternativamente, puede restaurar el comportamiento predeterminado de Active Directory del tiempo de sincronización con el emulador PDC reconfigurando las máquinas virtuales del motor para usar la fuente DOMHIER NTP y configurar las reglas de firewall para permitir el tráfico NTP entrante (UDP/123) a sus controladores de dominio.

Consolidar y monitorear los registros de auditoría

Cuando implementa Active Directory en Google Cloud, la seguridad de su bosque Active Directory y sus proyectos de Google Cloud están vinculados a otro: la actividad sospechosa en Active Directory y Windows podría poner en peligro la seguridad de otros recursos de la misma manera que la actividad sospechosa en Google Cloud podría poner en riesgo su directorio activo .

Los registros de auditoría consistentes son una herramienta importante para identificar amenazas o configuración errónea temprano y permitirle reconstruir y examinar la actividad pasada. El registro de auditorías en la nube le permite capturar y analizar registros de actividad de administración y registros de acceso a datos . Del mismo modo, puede usar registros de reglas de firewall y registros de flujo VPC para analizar el tráfico de redes. Sin embargo, estos servicios de plataforma desconocen los eventos relacionados con la seguridad en Active Directory. Para establecer una pista de auditoría consistente que cubra tanto los eventos de auditoría relacionados con la plataforma como los eventos de auditoría relacionados con el directorio de Active Directory, instale el agente de registro en la nube en controladores de dominio y máquinas unidas por dominio para exportar registros de eventos de seguridad de Windows a registro en la nube.

Por defecto, el registro de eventos de seguridad de Windows podría no capturar todos los eventos que necesita para sus propósitos de auditoría. Consulte las recomendaciones de Microsoft sobre la configuración de las políticas de auditoría y el monitoreo de Active Directory para obtener signos de compromiso para garantizar que capture todos los eventos de auditoría relevantes.

Cuando se trata de un gran volumen de eventos, es fácil perderse eventos críticos. Para evitar eventos críticos faltantes, cree métricas basadas en registros para eventos que puedan ser particularmente críticos o sospechosos y considere configurar alertas para notificarle cuándo cambia la tasa de eventos o excede los umbrales aceptables.

¿Qué sigue?

• Descubra qué patrón para usar Active Directory en un entorno híbrido se adapta mejor a su situación.

• Aprenda cómo puede configurar Active Directory para VMS para unirse automáticamente a un dominio .

• Prueba otros Google Cloud características para ti. Ver nuestros tutoriales .