En esta guía, se presentan las prácticas recomendadas para ejecutar Active Directory en Google Cloud. En esta guía, nos enfocamos en prácticas que son específicas de Google Cloud o de particular importancia para implementar Active Directory en Google Cloud. Considera que la guía es complementaria a las prácticas recomendadas generales para proteger Active Directory publicadas por Microsoft.
Arquitectura
Las siguientes secciones detallan las prácticas recomendadas relacionadas con la arquitectura.
Usa el patrón de arquitectura que mejor se adapte a tus necesidades
Para implementar Active Directory en Google Cloud, primero debes decidir qué arquitectura de bosque y dominio usar. Si ya usas Active Directory, también debes decidir si integras los dos entornos y cómo hacerlo.
El diseño que mejor se adapte a tu situación depende de varios factores, como el diseño de tu red local, cómo interactuarán los recursos locales y los de Google Cloud, así como tus requisitos de disponibilidad y autonomía administrativa. Consulta nuestros patrones para usar Active Directory en un entorno híbrido a fin de ver cómo estos factores deben determinar tu diseño.
Si deseas mantener un límite de confianza entre Google Cloud y tu entorno local, considera implementar el patrón de bosque de recursos. En este patrón, se implementa un bosque independiente en Google Cloud y se usa una relación de confianza unidireccional para integrar el bosque de Google Cloud con tu bosque de Active Directory local existente.
Pruebas y producción por separado
Según el uso de Active Directory, puede ser necesario realizar cambios frecuentes en Active Directory durante el desarrollo y las pruebas de aplicaciones. Es posible que los desarrolladores necesiten poder crear y modificar cuentas de Active Directory, cambiar membresías de grupos si las aplicaciones usan grupos para manejar la autorización, o unirse y quitar computadoras.
Para evitar que el trabajo de desarrollo y prueba afecte las cargas de trabajo de producción u obstaculice la seguridad de su implementación, considere implementar un dominio o bosque de Active Directory separado para el desarrollo y las pruebas.
Tener un dominio o bosque de desarrollo y prueba separado también te permite verificar los cambios administrativos antes de aplicarlos a la producción. Algunos ejemplos de estos cambios incluyen experimentar con políticas de grupo, probar secuencias de comandos de automatización o acciones potencialmente riesgosas, como elevar el nivel funcional de un bosque.
Configura la federación de Cloud Identity además de implementar Active Directory en Google Cloud
La implementación de Active Directory en Google Cloud le permite administrar máquinas virtuales de Windows en Google Cloud, puede permitir a los usuarios iniciar sesión en máquinas virtuales de Windows mediante 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 de gcloud o alguna otra herramienta de Google y Google Cloud, debes autenticarte con una identidad de Google. Por lo tanto, la implementación de Active Directory en Google Cloud no reemplaza la federación de tu Active Directory existente con Google Cloud si tienes la intención de usar Active Directory como tu sistema líder para administrar usuarios.
Por ejemplo, si implementas un bosque independiente en Google Cloud, puedes configurar la federación en tu 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 tus aplicaciones que usan Active Directory para la autenticación.
Si en cambio decides extender el bosque o dominio existente a Google Cloud, también tienes la opción de usar controladores de dominio y servidores AD FS implementados en Google Cloud para configurar la federación.
La federación también te permite aplicar un ciclo de vida común para las Cuentas de Google y de Active Directory, de modo que, cuando inhabilitas una cuenta de usuario en tu Active Directory local, el usuario de Google correspondiente también se suspende.
Redes
En la siguiente sección, se detallan las prácticas recomendadas relacionadas con las Herramientas de redes.
Implemente Active Directory en una red de VPC compartida
Para permitir que Active Directory se use en varios proyectos, implemente controladores de dominio en una red de VPC compartida. El uso de una red de VPC compartida tiene múltiples ventajas:
Cada aplicación que podría requerir acceso de Active Directory puede implementarse en un proyecto separado. Usar proyectos independientes ayuda a aislar los recursos y te permite administrar el acceso de forma individual.
Puedes usar un proyecto dedicado para los controladores de dominio de Active Directory, que te permite controlar en detalle qué usuarios pueden acceder a los recursos de Google Cloud relacionados.
Las redes de VPC compartida te permiten centralizar la administración de direcciones IP y la configuración de firewall, lo que ayuda a garantizar la coherencia en varios proyectos.
Como las VPC son un recurso global, puede usar la misma red de VPC compartida en varias regiones.
No expongas los controladores de dominio de forma externa
A fin de reducir la superficie de ataque de Active Directory, evita asignar direcciones IP externas a los controladores de dominio.
Debido a que las instancias de VM sin direcciones IP externas no tienen acceso a Internet de forma predeterminada, debes tomar medidas adicionales para garantizar que la activación y las actualizaciones de Windows no se vean afectadas por los controladores de dominio.
Para admitir la activación de Windows, habilita el Acceso privado a Google en la subred en la que planeas implementar controladores de dominio y asegúrate de que las instancias de VM puedan acceder a kms.windows.googlecloud.com. Esto permite que se realice la activación sin acceso directo a Internet.
Existen varias opciones para admitir actualizaciones de Windows:
Si tienes un servidor WSUS local, puedes configurar la conectividad híbrida y configurar los controladores de tu dominio para que usen el servidor WSUS como fuente de actualizaciones.
Puedes habilitar el acceso a Internet a través de una puerta de enlace NAT mediante la implementación de Cloud NAT.
Si configuraste la conectividad híbrida, también puedes enrutar el tráfico de salida mediante una puerta de enlace NAT local o un servidor proxy.
Reserve las direcciones IP estáticas para los controladores de dominio por adelantado
Debido a que los controladores de dominio funcionan como servidores DNS, se les debe asignar una dirección IP que no cambie. Para lograrlo, configura direcciones IP internas estáticas de las VMs del controlador de dominio.
Cuando reservas una dirección IP, el comportamiento predeterminado es que se elige una dirección sin usar de forma automática. Para garantizar que las direcciones IP de los controladores de dominio sean fáciles de memorizar, reserva una dirección IP estática interna.
En los controladores de dominio, configura la dirección IP del adaptador de red para 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 puede asignarse de forma dinámica.
Implementa controladores de dominio en varias zonas
Para aumentar la disponibilidad, implementa al menos dos controladores de dominio y distribúyelos en varias zonas. Debido a que las subredes y las direcciones IP no están vinculadas a una zona, puedes implementar todos los controladores de dominio en una sola subred.
Si planeas implementar cargas de trabajo en varias regiones, considera implementar controladores de dominio en cada región relevante. Debido a que las subredes son un recurso regional, la implementación en una región adicional requerirá una subred adicional.
Crea un sitio por región
Cuando un cliente intenta ubicar un controlador de dominio, primero busca un controlador de dominio en el sitio de Active Directory que corresponde a la dirección IP del cliente. Si no hay un controlador de dominio disponible en este sitio, el cliente intentará ubicar un controlador de dominio en un sitio diferente.
Puedes aprovechar este comportamiento si creas un sitio separado para cada región en la que implementes los controladores de dominio o los clientes de dominio. Automáticamente, los clientes preferirán usar los controladores de dominio ubicados en la misma región, lo que puede ayudar a reducir la latencia y el costo de transferencia de datos saliente entre regiones.
Si tiene clientes en regiones que no tienen un controlador de dominio, puede influir en los controladores de dominio que estos clientes eligen ajustando los costos del vínculo a sitio para reflejar la proximidad 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 los controladores de dominio. Una desventaja de usar varios sitios puede ser que la replicación entre sitios ocurre con menos frecuencia que la replicación dentro del sitio.
Sin embargo, no puedes crear sitios de Active Directory en Microsoft AD administrado porque Microsoft AD administrado no admite la función de sitios y servicios de Active Directory.
Usa zonas de reenvío privado de Cloud DNS
Cuando crea 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 DNS público.
Antes de poder unir una máquina a un dominio de Active Directory, debes asegurarte 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 a DNS interno y DNS público, pero no podrá resolver los nombres de DNS administrados por Active Directory.
Cree una zona de reenvío de DNS privado en Cloud DNS para permitir que los clientes resuelvan los registros DNS administrados por Active Directory. Configure la zona para reenviar consultas cuyo dominio de Active Directory coincida con sus controladores de dominio.
Usar una zona de reenvío de DNS privado tiene varias ventajas sobre la configuración de los clientes para usar directamente tus controladores de dominio de Active Directory como servidores DNS:
No es necesario que ajustes la configuración de red de las instancias de VM. Esto simplifica el proceso de creación de VM nuevas.
Cuando asciende o desciende de nivel un controlador de dominio, solo necesitas actualizar la configuración de la zona privada de reenvío de DNS y no necesitas modificar ninguna configuración del cliente.
Las instancias de VM aún tienen acceso al DNS interno.
Cloud DNS controlará cualquier registro DNS que no coincida con tu dominio de Active Directory, lo que reduce la carga en los controladores de dominio.
Si usas varios dominios, crea una zona de reenvío de DNS privado independiente para cada dominio de Active Directory.
El alcance de las zonas de reenvío privado de DNS en la nube es de una sola VPC. Si utiliza varias VPC conectadas mediante el intercambio de tráfico, puede exponer las zonas de reenvío privadas a otras VPC si configura el intercambio de tráfico de DNS.
Aún debes establecer manualmente la configuración de DNS en los controladores de dominio. Usa 127.0.0.1 como el servidor DNS principal y usa la IP de otro controlador de dominio como servidor DNS secundario. Para obtener más información, consulta Configuración recomendada de DNS y opciones alternativas.
Conectividad híbrida
En la siguiente sección, se detallan las prácticas recomendadas relacionadas con la conectividad híbrida.
Use el reenvío entrante DNS para resolver los nombres de Google Cloud DNS desde las instalaciones
Es posible que los clientes de tu red local necesiten poder resolver los nombres de DNS de los recursos implementados en Google Cloud. Si extiendes tu bosque o implementas un bosque de recursos en Google Cloud, usa el reenvío de entrada de DNS para permitir que los clientes locales busquen registros DNS de recursos implementados en Google Cloud. Si quieres usar el reenvío entrante, crea una política de servidor DNS para asignar una dirección IP de reenvío entrante y haz que esta dirección sea accesible para la red local.
Si el dominio de DNS utilizado en Google Cloud (por ejemplo, cloud.example.com) es un subdominio del dominio DNS usado de forma local (por ejemplo, example.com), configura la delegación de DNS. Crea un registro NS en el dominio local que apunte a la dirección IP de reenvío entrante. El registro NS hace que se redireccionen los clientes que buscan un nombre de DNS en el dominio alojado en Google Cloud a la dirección IP de reenvío 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), configure el reenvío DNS condicional en sus dominios locales y use la dirección IP del servidor de reenvío entrante como el objetivo. Cuando se les solicite resolver un nombre DNS en el dominio alojado en Google Cloud, los controladores de dominio locales reenviarán la búsqueda a la dirección IP del servidor de reenvío entrante.
Cuando utilice el reenvío de DNS entrante, asegúrese de que sus firewalls estén configurados adecuadamente.
El reenvío entrante DNS no es necesario si extiende su dominio existente a Active Directory. En esta situación, todos los registros DNS del dominio se replican automáticamente en Google Cloud y su entorno local y están disponibles para la búsqueda en ambos entornos.
Utilice el reenvío de salida DNS para resolver nombres DNS locales desde Google Cloud
Es posible que los clientes que se ejecutan en Google Cloud necesiten poder resolver los nombres de los recursos implementados localmente. Si extiende su bosque o implementa un bosque de recursos en Google Cloud, cree una zona de reenvío privado en Cloud DNS para reenviar consulta de DNS para su 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 de salida de DNS no es necesario si extiende su dominio existente a Active Directory. En esta situación, todos los registros DNS del dominio se replican automáticamente en Google Cloud y su entorno local y están disponibles para la búsqueda en ambos entornos.
Usa 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 otros protocolos que usa Active Directory, LDAP no se encripta de forma predeterminada.
Google Cloud garantiza que el tráfico entre máquinas virtuales esté encriptado, por lo que es aceptable usar LDAP sin encriptar dentro de tu VPC. Si conectas tu VPC a una red local, asegúrate de que el tráfico LDAP solo se intercambie a través de canales de confianza.
Si utiliza Cloud VPN para conectar Google Cloud y su red local, el tráfico se encripta automáticamente mediante IPSec entre Google Cloud y su extremo de VPN local.
Cloud Interconnect y Partner Interconnect no proporcionan encriptación. Para garantizar una comunicación segura, establezca un túnel VPN a través de la conexión de Interconnect mediante un dispositivo VPN de Google Cloud Marketplace.
Utilice autenticación selectiva y AES para relaciones de confianza de bosques
Cuando se crea una relación de confianza entre los bosques de Active Directory, son preferibles las relaciones de confianza de bosques antes que las de externos para aprovechar las siguientes características para mejorar la seguridad:
Habilite la autenticación selectiva en relaciones de confianza salientes en el bosque de recursos. La autenticación selectiva asegura que los usuarios de bosque organizacional no puedan acceder a los recursos en el bosque de recursos a menos que se les otorgue explícitamente el permiso.
Habilite la aplicación para el límite de bosque para la delegación completa de Kerberos en las relaciones de confianza entrantes en el bosque organizacional. Esta característica ayuda a prevenir ataques de elevación de privilegios al deshabilitar recursos en el bosque de recursos para solicitar tickets de concesión de tickets (TGT) a los usuarios en el bosque organizacional.
Habilite la opción El otro dominio admite la opción de encriptación AES de Kerberos, para ello, cree relaciones de confianza. Esta opción garantiza que los tickets utilizados para la autenticación entre bosques se encripten con AES en lugar del algoritmo RC4 que es menos seguro.
Seguridad
En la siguiente sección, se detallan las prácticas recomendadas relacionadas con la seguridad.
Evita que la seguridad de Google Cloud interfiera en la seguridad de Active Directory
Active Directory te brinda un control detallado sobre qué usuarios tienen permiso para acceder a qué recursos. Cuando las máquinas se implementan como instancias de VM en Compute Engine y los usuarios tienen acceso al proyecto de Google Cloud subyacente, debes tener en cuenta rutas adicionales que podrían permitir que un usuario acceda a una máquina:
Un miembro del proyecto al que se le asignó la función administrador de instancias de Compute en un proyecto de Google Cloud puede usar la función de restablecimiento de contraseña para crear cuentas de administrador locales. Las cuentas de administrador locales representan una amenaza a la seguridad de tu dominio de Active Directory, ya que se pueden usar para socavar las políticas de grupo o para instalar software malicioso que pueda capturar las credenciales de dominio de otros usuarios registrados.
Al agregar una secuencia de comandos de inicio, un miembro privilegiado del proyecto puede inyectar código malicioso en una máquina virtual que se ejecuta como
nt authority\systemla próxima vez que se reinicie la máquina.Con la consola en serie, un miembro del proyecto privilegiado también puede acceder a la consola de administración especial (SAC) de Windows. Windows considera la posibilidad de iniciar sesión con la SAC como inicios de sesión locales. Por lo tanto, la SAC se puede usar de manera incorrecta para evadir las políticas que rechazan los inicios de sesión a través de RDP, pero puede denegar los inicios de sesión locales de forma incorrecta.
Un miembro del proyecto con privilegios puede usar la SAC para emitir un comando
crashdump, que puede hacer que se escriba un volcado de memoria en el disco. Este volcado de memoria puede incluir información sensible y credenciales.Al montar el disco persistente en una máquina virtual diferente o usar instantáneas, un miembro del proyecto privilegiado podría acceder al contenido del disco, incluidos los volcados de memoria, desde máquinas en las que el usuario no tendría permiso para iniciar sesión en otros casos.
Cuando usas Microsoft AD administrado, estás mejor protegido contra estas rutas de acceso adicionales de forma predeterminada. El servicio no permite que los usuarios privilegiados de tu proyecto restablezcan la contraseña del administrador de dominio, ejecuten secuencias de comandos de inicio ni accedan a la consola en serie en las VM del controlador de dominio de AD.
Para mitigar aún más estos riesgos, asegúrate de que los permisos de IAM de los proyectos que contienen instancias de VM unidas al dominio se administren con menos privilegios. Puedes reducir aún más el riesgo mediante el usuario de las políticas de la organización, las políticas de grupo y las VM protegidas:
Utilice políticas de la organización para deshabilitar el acceso al puerto en serie.
Inhabilita el administrador de cuentas para aplicar una política de grupo que impida la creación de cuentas de administrador locales. Define una preferencia de archivos INI en tu política de grupo (Configuración de la computadora > Preferencias > Configuración de Windows > Archivos Ini) para aplicar la siguiente configuración:
- Acción: Actualización
- Ruta de acceso al archivo:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - Nombre de la sección:
accountManager - Nombre de la propiedad:
disable - Valor de la propiedad:
true
Aplica una política de grupo que quite las cuentas de administrador locales de las instancias de VM. Usa la funcionalidad Usuarios y grupos locales (Configuración de la computadora > Preferencias > Configuración del panel de control > Usuarios y grupos locales) para quitar la membresía grupal del grupo Administradores y de otros grupos sensibles.
Considere el uso de máquinas virtuales blindadas en combinación con la encriptación de disco BitLocker para evitar que usuarios no autorizados puedan leer instantáneas o discos persistentes.
Evita que la seguridad de Active Directory interfiera con la seguridad de Google Cloud
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. A menos que esté restringido por la política de grupo, la política de seguridad local de una máquina o la autenticación selectiva, un usuario que ha demostrado con éxito su identidad ante uno de los controladores de dominio puede acceder a cualquier máquina del dominio.
La capacidad de que los usuarios de Active Directory accedan a cualquier máquina puede permitir que los atacantes realicen movimientos laterales dentro de un dominio. Estos movimientos laterales pueden llevar al escalamiento de privilegios si algunas instancias de VM están exentas de restricciones de firewall o usan cuentas de servicio de Google Cloud. Todos los procesos y usuarios de una instancia de VM pueden acceder a las credenciales. Cualquier usuario que pueda usar Active Directory para acceder a una máquina puede acceder a estas credenciales de la cuenta de servicio para obtener acceso a cualquier recurso de Google Cloud al que tenga acceso la cuenta de servicio.
Al configurar Microsoft AD administrado, el servicio crea un grupo para facilitar a los usuarios específicos la capacidad de usar RDP en máquinas virtuales unidas al dominio.
Para reducir el riesgo de movimientos laterales, organice a los usuarios en niveles administrativos y use las políticas de grupo Denegar el acceso a esta computadora desde la red y Denegar el inicio de sesión a través de Servicios de escritorio remoto para restringir el acceso a sus máquinas virtuales en función del nivel.
En una topología de bosque de recursos, aprovecha la autenticación selectiva para restringir aún más el conjunto de usuarios de otros bosques que pueden acceder a tu VM. Puedes simplificar la administración de los permisos de autenticación selectiva mediante la alineación de las estructuras de recursos de Google Cloud y Active Directory. Si las unidades organizacionales de Active Directory se asignan a los proyectos de Google Cloud, puedes otorgar a los usuarios el derecho de autenticarse en un nivel que coincida con un proyecto de Google Cloud.
En los casos en que no se apliquen políticas de autenticación o grupo selectivas, crea una cuenta de servicio separada, exporta las claves de cuenta de servicio y guárdalas en el disco local de la instancia de VM o en un archivo compartido y protégelas con una LCA de NTFS para que solo los usuarios autorizados de Active Directory puedan leer y usar las claves.
Usa proyectos dedicados para controladores de dominio
Los controladores de dominio tienen una función fundamental en la seguridad de un dominio de Active Directory, y la vulneración de un solo controlador de dominio puede dar como resultado la vulneración de todo tu bosque de Active Directory.
Para limitar el riesgo de acceso no autorizado, usa un proyecto de Google Cloud independiente para implementar controladores de dominio y otorgar acceso a este proyecto con menos privilegios. Cuando crees el proyecto, ten en cuenta que algunos permisos pueden heredarse de las carpetas superiores. Para evitar otorgar acceso de manera involuntaria a través de la herencia, considera crear el proyecto fuera de tu jerarquía de carpetas habitual.
Cuando configures las políticas de IAM para el proyecto, presta especial atención a fin de restringir el acceso a las instancias de VM, los discos persistentes que contienen la base de datos ntds.dit y cualquier ubicación de almacenamiento que podría contienen copias de seguridad.
Además de usar políticas de IAM para limitar el acceso al proyecto, protege proyecto contra la eliminación accidental.
Usa VM y proyectos independientes para administrar Active Directory
Para administrar Active Directory, debes poder usar herramientas como usuarios y computadoras de Active Directory o el centro administrativo de Active Directory. Estas herramientas requieren que accedas con una cuenta de dominio con privilegios, lo que hace que la máquina en la que ejecutas estas herramientas sea un destino atractivo para el robo de credenciales o el registro de claves.
A fin de minimizar el riesgo de que un atacante obtenga credenciales de dominio con privilegios, usa instancias de VM dedicadas para la administración de dominios y controla esas VM de administración como estaciones de trabajo con acceso privilegiado:
Usa políticas de grupo para asegurarte de que solo un subconjunto selecto de usuarios tenga derecho a acceder a las VM de administración. Si implementaste la administración por niveles, este grupo de usuarios corresponde al nivel 0.
Del mismo modo que los controladores de dominio, los miembros del proyecto pueden poner en riesgo a las VM administrativas si crean cuentas de administrador locales, se registran en la consola en serie o manipulan sus discos persistentes. Si deseas limitar el riesgo de acceso no autorizado, usa un proyecto de Google Cloud por separado para las VM administrativas y otorga acceso a este proyecto con menos privilegios.
Si planeas acceder a VM administrativas desde una red local con conectividad híbrida, implementa las VM administrativas en una subred de VPC dedicada. Una subred dedicada a las VM de administración te permite distinguir mejor entre las VM administrativas y otras VM cuando configuras tus firewalls locales. Si usas una VPC compartida, usa los 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 VM de administración que para otras VM, los usuarios no puedan evadir las reglas de firewall mediante la ubicación de las VM que no son de administración en la subred de administración.
Además, considera restringir la política de grupo que administra las restricciones de inicio de sesión de las VM de administración en la subred de administración. Esta práctica aplica 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 o dirección IP).
Además de usar políticas de IAM para limitar el acceso al proyecto, protege proyecto contra la eliminación accidental.
Usa reglas de firewall para proteger los servidores y los controladores de dominio
Los controladores de dominio exponen varios servicios, incluidos LDAP, DNS, Kerberos y RPC. Según tus casos prácticos, las VM implementadas en Google Cloud, así como las máquinas que se ejecutan de forma local, pueden necesitar acceso a diferentes subconjuntos de estos servicios para aprovechar Active Directory.
Cuando se usa Managed Microsoft AD, los controladores de dominio AD se implementan en un proyecto de usuario dedicado. La red que aloja los controladores de dominio AD está protegida automáticamente con reglas de firewall específicas de AD endurecidas.
Para reducir la superficie de ataque de los controladores de dominio y las máquinas virtuales, usa firewalls para impedir el acceso a cualquier comunicación de red que no sea estrictamente necesaria. Consulta nuestra guía sobre el uso de Active Directory en los firewalls para obtener detalles sobre qué configuraciones de firewall son necesarias para acceder a Active Directory desde tu VPC o desde redes locales.
Organiza los recursos y usuarios de Active Directory en niveles administrativos
Algunas máquinas en un bosque de Active Directory son más importantes para la seguridad general de Active Directory que otras. Los controladores de dominio y las VM administrativas son dos ejemplos de máquinas que son particularmente fundamentales y, por lo tanto, son sensibles a los posibles ataques.
Para identificar el nivel crítico de cada una de sus máquinas, use una taxonomía de niveles. Si bien la cantidad correcta de niveles depende de su configuración específica, puede comenzar con tres niveles:
Nivel 0 (muy fundamental): este nivel incluye todas las máquinas que son fundamentales para la seguridad de tu bosque de Active Directory. Una vez que una máquina del nivel 0 está en riesgo, debes suponer que todo tu bosque lo está.
Nivel 1 (fundamental): este nivel incluye la mayoría de los servidores de tu entorno, incluidos los servidores de aplicaciones y los servidores de bases de datos. Un servidor de nivel 1 vulnerado puede tener un impacto comercial significativo, pero no representa una amenaza inmediata para todo el bosque.
Nivel 2 (normal): en este nivel, se incluyen estaciones de trabajo o cualquier otra máquina de uso general. Se espera que una vulneración de máquina de nivel 2 tenga un impacto limitado en la seguridad general y de los negocios.
Aunque el impacto inmediato de una máquina de nivel 2 vulnerada puede ser limitado, existe el riesgo de que se produzcan efectos secundarios: cuando un usuario que tiene acceso de administrador al nivel 0 o a máquinas de nivel 1 quiera acceder a una máquina de nivel 2 vulnerada, podría ser víctima de un registrador de claves u otra forma de robo de credenciales. Las credenciales capturadas se pueden usar para atacar a máquinas de niveles superiores, lo que hace que el impacto general aumente.
Para evitar esos efectos secundarios, asegúrate de no solo categorizar las máquinas, sino también las cuentas de usuario, y de restringir a qué conjunto de máquinas tienen acceso estos usuarios:
Nivel 0 (muy fundamental): Usuarios que tienen acceso a máquinas de nivel 0.
Nivel 1 (fundamental): Usuarios que tienen acceso a máquinas de nivel 1.
Nivel 2 (normal): Usuarios que tienen acceso a máquinas de nivel 2.
Use la siguiente tabla como guía para decidir qué usuarios deben tener acceso a qué recursos:
| Grupo | Nivel | Acceso al dominio | Acceso a la computadora de nivel 0 | Acceso a la computadora de nivel 1 | Acceso a la computadora de nivel 2 |
|---|---|---|---|---|---|
| Administradores de Active Directory | 0 | Administrador | Usuario restringido | Bloqueado | Bloqueado |
| Administradores del servidor de administración | 0 | Usuario restringido | Administrador | Bloqueado | Bloqueado |
| Administradores del servidor | 1 | Usuario restringido | Bloqueado | Administrador | Bloqueado |
| Administradores de estaciones de trabajo de VDI | 2 | Usuario restringido | Bloqueado | Bloqueado | Administrador |
| Usuarios de la estación de trabajo de VDI | 2 | Usuario restringido | Bloqueado | Bloqueado | Usuario restringido |
Consulte la documentación de Microsoft para obtener más detalles y las prácticas recomendadas sobre la implementación de un modelo de nivel administrativo en Active Directory.
Cuando uses el modelo de nivel administrativo en tu bosque de Active Directory, asegúrate de que las relaciones de confianza de bosques no socaven su integridad. Si el bosque de confianza también aplica un modelo de administración por niveles, usa la autenticación selectiva para garantizar que los usuarios del bosque de confianza solo puedan acceder a los recursos dentro del mismo nivel:
Si el bosque de confianza no implementa la administración por niveles, asígnalo a un nivel determinado y usa la autenticación selectiva para garantizar que los usuarios del bosque de confianza solo estén autorizados a acceder a los recursos de ese nivel en particular.
Usa Controles del servicio de VPC y Acceso privado a Google para hosts locales
Las API de Microsoft AD administrado permiten restablecer la contraseña de administrador y realizar otras operaciones sensibles. En implementaciones de producción críticas, recomendamos habilitar los Controles del servicio de VPC y usar el Acceso privado a Google para los hosts locales a fin de aumentar la seguridad.
Administración
La siguiente sección detalla las prácticas recomendadas relacionadas con la administración de Active Directory.
Alinea las estructuras de recursos de Google Cloud y Active Directory
Cuando implementas un dominio o bosque de Active Directory nuevo en Google Cloud, debes definir una estructura de unidad organizacional (UO) para organizar tus recursos con tu dominio de Active Directory. En lugar de diseñar una estructura completamente nueva o aplicar la que usas en tu entorno local, crea una estructura de UO que esté alineada con tu jerarquía de recursos de Google Cloud:
Si usas un modelo de administración por niveles, las UO de nivel superior deben reflejar tus niveles administrativos.
En cada nivel, crea UO para usuarios y grupos. Si planeas administrar una gran cantidad de usuarios y grupos, crea UO secundarias según corresponda.
Para cada nivel, crea una UO
Projectsy crea subUO para cada proyecto de Google Cloud que contenga recursos de Active Directory. Usa la subUO específica del proyecto para administrar cuentas de computadora, cuentas de servicio o algún otro recurso de Active Directory que corresponda a los recursos de Google Cloud del proyecto correspondiente. Asegúrate de que haya una asignación idéntica entre las UO y los proyectos.
En el siguiente diagrama, se muestra una jerarquía de ejemplo que sigue estos principios:
Si la cantidad de proyectos que contienen recursos de Active Directory es moderada, puedes crear una estructura de UO plana en la UO Projects. Si esperas administrar una gran cantidad de proyectos y diseñaste tu jerarquía de recursos de Google Cloud para que use varios niveles de carpetas, considera reflejar esta estructura de carpetas debajo de la UO Projects.
Alinear la estructura de UO de Active Directory y la jerarquía de recursos de Google Cloud tiene varias ventajas:
Cuando delegas permisos administrativos a un proyecto de Google Cloud mediante las políticas de IAM, también necesitas otorgar a ciertos 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 con una UO determinada. Si alineas las UO y los proyectos de Google Cloud, podrás otorgar estos permisos en Active Directory con el mismo nivel de detalle de Google Cloud.
Si planeas usar objetos de políticas de grupos (GPO) para administrar computadoras, una estructura de UO que refleje la jerarquía de recursos de Google Cloud te ayudará a garantizar que los GPO se apliquen de forma coherente a todas las VM de una carpeta o proyecto determinado.
Si usa una relación de confianza entre bosques con autenticación condicional, puede usar las unidades organizativas que corresponden a proyectos de Google Cloud para otorgar el permiso Habilitado para autenticar por proyecto.
Cuando elimina un proyecto en Google Cloud, simplemente puede eliminar la unidad organizativa asociada, lo que reduce el riesgo de dejar recursos inactivos en su directorio.
Si cree que su estructura de 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 tiene muy pocas especificaciones.
Usa servidores de tiempo de Google
La autenticación de Kerberos depende de las marcas de tiempo como parte de su protocolo. Para que la autenticación sea exitosa, los relojes de la máquina cliente y del servidor deben sincronizarse en un margen determinado. De forma predeterminada, Active Directory no admite más de 5 minutos de diferencia.
En un entorno de Active Directory local, las siguientes son las opciones de configuración predeterminadas para sincronizar el tiempo:
- Las máquinas unidas al dominio sincronizan su tiempo con un controlador de dominio.
- Los controladores de dominio sincronizan su tiempo con el emulador de PDC de su dominio.
- Los emuladores de PDC de todos los dominios sincronizan su tiempo con el emulador de PDC del dominio raíz del bosque.
En esta configuración, el emulador PDC del dominio raíz del bosque es la última fuente de tiempo para Active Directory y es común configurar esta máquina para usar un servidor NTP externo como fuente de tiempo.
En Compute Engine, la configuración predeterminada para las VM de Windows es usar el servidor de metadatos (metadata.google.internal) como servidor NTP, que, a su vez, depende de los servidores NTP de Google para obtener la hora correcta. Unir una VM a un dominio de Active Directory no cambia esta configuración predeterminada.
Mantén la configuración predeterminada de Compute Engine, a menos que el emulador PDC del dominio raíz de tu bosque se implemente fuera de Google Cloud.
Si tu emulador de PDC se implementa fuera de Google Cloud, configúralo para usar time.google.com como fuente de NTP.
Como alternativa, puedes restablecer el comportamiento predeterminado de Active Directory para sincronizar el tiempo con el emulador PDC mediante la reconfiguración de las VMs de Compute Engine a fin de usar la fuente NTP DOMHIER y la configuración del firewall para permitir el tráfico de entrada NTP (UDP/123) a los controladores de dominio.
Consolida y supervisa registros de auditoría
Cuando implementas Active Directory en Google Cloud, la seguridad de tu bosque de Active Directory y tus proyectos de Google Cloud están vinculados a otros: la actividad sospechosa en Active Directory y Windows podría poner en riesgo la seguridad de otros recursos de la misma manera que la actividad sospechosa en Google Cloud podría poner en riesgo tu Active Directory.
Los registros de auditoría coherentes son herramientas importantes para identificar las amenazas o la configuración incorrecta de forma temprana y permitirte volver a construir y examinar la actividad pasada. Cloud Audit Logging te permite capturar y analizar registros de actividad del administrador y registros de acceso a datos. Del mismo modo, puedes usar el registro de reglas de firewall y los registros de flujo de VPC para analizar el tráfico de redes. Sin embargo, estos servicios de plataforma no están al tanto de ningún evento relacionado con la seguridad en Active Directory. Para establecer un registro de auditoría coherente que cubra los eventos de auditoría relacionados con la plataforma y los eventos de auditoría relacionados con Active Directory, instala el agente de Cloud Logging en los controladores de dominio y en las máquinas unidas al dominio para exportar los registros de eventos de seguridad de Windows a Cloud Logging.
De forma predeterminada, es posible que el registro de eventos de seguridad de Windows no capture todos los eventos que necesitas para la auditoría. Consulta las recomendaciones de Microsoft sobre la configuración de políticas de auditoría y la supervisión de Active Directory para las señales de vulneración a fin de asegurarte de capturar todos los eventos de auditoría relevantes.
Cuando se trata de un gran volumen de eventos, es fácil pasar por alto eventos fundamentales. A fin de no pasar por alto eventos fundamentales, crea métricas basadas en registros para eventos que podrían ser especialmente críticos o sospechosos y considera configurar alertas para notificarte cuando cambie la tasa de eventos o supere los límites aceptables.
¿Qué sigue?
Descubre qué patrón de uso de Active Directory en un entorno híbrido se adapta mejor a tu situación.
Obtén más información sobre cómo configurar Active Directory para que las VM se unan automáticamente a un dominio.
Prueba otras funciones de Google Cloud. Consulta nuestros instructivos.