En esta guía se presentan las prácticas recomendadas para ejecutar Active Directory en Google Cloud. La guía se centra en prácticas específicas de Google Cloud o de especial importancia al implementar Active Directory en Google Cloud. Esta guía complementa las prácticas recomendadas generales para proteger Active Directory publicadas por Microsoft.
Arquitectura
En las siguientes secciones se detallan las prácticas recomendadas relacionadas con la arquitectura.
Usa el patrón de arquitectura que mejor se adapte a tus requisitos
Para desplegar Active Directory en Google Cloud, primero debes decidir qué arquitectura de dominio y bosque vas a usar. Si ya usas Active Directory, también debes decidir si quieres integrar 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 van a interactuar los recursos locales y los deGoogle Cloud , así como tus requisitos de disponibilidad y autonomía administrativa. Consulta nuestros patrones para usar Active Directory en un entorno híbrido para ver cómo deben determinar estos factores tu diseño.
Si quieres mantener un límite de confianza entre Google Cloud y tu entorno local, considera la posibilidad de 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 entre bosques para integrar el bosque Google Cloud con el bosque de Active Directory local.
Separar las pruebas y la producción
En función del uso que hagas de Active Directory, puede que tengas que hacer cambios con frecuencia en Active Directory durante el desarrollo y las pruebas de las aplicaciones. Es posible que los desarrolladores necesiten crear y modificar cuentas de Active Directory, cambiar las pertenencias a grupos si las aplicaciones usan grupos para gestionar la autorización, o unir y quitar ordenadores.
Para evitar que el trabajo de desarrollo y pruebas afecte a las cargas de trabajo de producción o ponga en peligro la seguridad de su implementación, le recomendamos que implemente un dominio o un bosque de Active Directory independiente para el desarrollo y las pruebas.
Tener un dominio o un bosque de desarrollo y pruebas independientes también le permite verificar los cambios administrativos antes de aplicarlos a la producción. Algunos ejemplos de estos cambios son experimentar con políticas de grupo, probar secuencias de comandos de automatización o realizar acciones potencialmente arriesgadas, como aumentar el nivel funcional de un bosque.
Configurar la federación de Cloud Identity además de implementar Active Directory en Google Cloud
Al implementar Active Directory en Google Cloud , puedes gestionar máquinas virtuales Windows en Google Cloud, permitir que los usuarios inicien sesión en máquinas virtuales Windows con sus cuentas de usuario y usar aplicaciones que dependan de Kerberos, NTLM o LDAP para la autenticación.
Sin embargo, para usar la Google Cloud consola, la gcloudherramienta de línea de comandos u otras herramientas de Google y Google Cloud , debes autenticarte con una identidad de Google. Por lo tanto, implementar Active Directory en Google Cloud no
sustituye a federar tu Active Directory con
Google Cloud si tienes intención de usar Active Directory
como sistema principal para gestionar usuarios.
Por ejemplo, si implementas un bosque independiente en Google Cloud, puedes configurar la federación con tu Active Directory local, tal como se muestra en el siguiente diagrama. Los usuarios con cuentas en Active Directory local pueden usar herramientas que requieran una identidad de Google, así como tus aplicaciones que dependan de Active Directory para la autenticación.
Si decides ampliar tu bosque o dominio a Google Cloud, también puedes usar controladores de dominio y servidores de 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 a las cuentas de Google y a las cuentas de Active Directory, de forma que, cuando inhabilites una cuenta de usuario en tu Active Directory local, la cuenta de usuario de Google correspondiente también se suspenda.
Redes
En la siguiente sección se detallan las prácticas recomendadas relacionadas con las redes.
Desplegar Active Directory en una red de VPC compartida
Para permitir que Active Directory se use en varios proyectos, despliega controladores de dominio en una red de VPC compartida. Usar una red de VPC compartida tiene varias ventajas:
Cada aplicación que pueda requerir acceso a Active Directory se puede implementar en un proyecto independiente. Usar proyectos independientes ayuda a aislar los recursos y te permite gestionar el acceso de forma individual.
Puedes usar un proyecto específico para los controladores de dominio de Active Directory, lo que te permite controlar con precisión qué usuarios pueden acceder a los recursos relacionados con Google Cloud .
Las redes de VPC compartidas te permiten centralizar la gestión de direcciones IP y la configuración de firewalls, lo que ayuda a garantizar la coherencia en varios proyectos.
Como las VPCs son un recurso global, puedes usar la misma red de VPC compartida en varias regiones.
No expongas los controladores de dominio externamente
Para reducir la superficie de ataque de Active Directory, no asignes direcciones IP externas a los controladores de dominio.
Como las instancias de VM sin direcciones IP externas no tienen acceso a Internet de forma predeterminada, debes seguir pasos adicionales para asegurarte de 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, habilita Acceso privado de Google en la subred en la que tienes previsto implementar los controladores de dominio y asegúrate de que las instancias de VM puedan acceder a kms.windows.googlecloud.com. De esta forma, la activación se puede llevar a cabo sin acceso directo a Internet.
Hay varias opciones para admitir actualizaciones de Windows:
Si tienes un servidor WSUS local, puedes configurar la conectividad híbrida y configurar tus controladores de dominio para que usen el servidor WSUS como fuente de actualizaciones.
Puedes habilitar el acceso a Internet a través de una pasarela NAT desplegando Cloud NAT.
Si has configurado la conectividad híbrida, también puedes enrutar el tráfico saliente a través de una pasarela de NAT o un servidor proxy locales.
Reservar direcciones IP estáticas para controladores de dominio con antelación
Como los controladores de dominio actúan como servidores DNS, se les debe asignar una dirección IP que no cambie. Para ello, configura direcciones IP internas estáticas para las VMs del controlador de dominio.
Cuando reservas una dirección IP, el comportamiento predeterminado es que se elija automáticamente una dirección que no se esté usando. Para que las direcciones IP de los controladores de dominio sean fáciles de recordar, reserva una dirección IP estática interna.
En los controladores de dominio, asigna la misma dirección IP a la tarjeta de red. Aunque este paso es opcional, evita que Active Directory emita mensajes de advertencia que indiquen que la dirección IP del equipo aún se puede asignar de forma dinámica.
Desplegar controladores de dominio en varias zonas
Para aumentar la disponibilidad, despliega al menos dos controladores de dominio y distribúyelos en varias zonas. Como 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 tienes previsto desplegar cargas de trabajo en varias regiones, te recomendamos que despliegues controladores de dominio en cada una de las regiones pertinentes. Como las subredes son un recurso regional, para implementar en una región adicional se necesitará otra subred.
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 otro sitio.
Puedes aprovechar este comportamiento creando un sitio independiente para cada región en la que implementes 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 coste de transferencia de datos salientes entre regiones.
Si tienes clientes en regiones que no tienen un controlador de dominio, puedes influir en los controladores de dominio que elijan estos clientes ajustando los costes de los enlaces de sitio para reflejar la proximidad geográfica de las regiones y habilitando la opción Probar el siguiente sitio más cercano.
El uso de varios sitios influye en el comportamiento de la replicación entre los controladores de dominio. Una de las desventajas de usar varios sitios es que la replicación entre sitios se produce con menos frecuencia que la replicación dentro de un mismo sitio.
Sin embargo, no puedes crear sitios de Active Directory en Managed Microsoft AD porque no admite la función Sitios y servicios de Active Directory.
Usar zonas de reenvío privadas de Cloud DNS
Cuando creas una instancia de VM en Compute Engine, el sistema operativo se preconfigura para usar un servidor DNS predeterminado que proporciona acceso al DNS interno y al DNS público.
Antes de poder unir un equipo a un dominio de Active Directory, debes asegurarte de que el equipo pueda resolver los registros DNS gestionados por Active Directory. El servidor DNS predeterminado que configura Compute Engine para una instancia de VM proporciona acceso al DNS interno y al DNS público, pero no podrá resolver nombres de DNS gestionados por Active Directory.
Crea una zona de reenvío de DNS privada en Cloud DNS para permitir que los clientes resuelvan registros DNS gestionados por Active Directory. Configura la zona para reenviar las consultas que coincidan con tu dominio de Active Directory a tus controladores de dominio.
Usar una zona de reenvío de DNS privada tiene varias ventajas con respecto a configurar clientes para que usen directamente los controladores de dominio de Active Directory como servidores DNS:
No es necesario que ajustes la configuración de red de las instancias de VM. De esta forma, se simplifica el proceso de creación de máquinas virtuales.
Cuando asciendes o degradas un controlador de dominio, solo tienes que actualizar la configuración de la zona de reenvío de DNS privada y no tienes que modificar ningún ajuste del cliente.
Las instancias de VM siguen teniendo acceso al DNS interno.
Cloud DNS gestionará los registros DNS que no coincidan con tu dominio de Active Directory, lo que reducirá la carga de tus controladores de dominio.
Si usas varios dominios, crea una zona de reenvío de DNS privada independiente para cada dominio de Active Directory.
Las zonas de reenvío privadas de Cloud DNS se limitan a una sola VPC. Si usas varias VPCs conectadas mediante emparejamiento, puedes exponer las zonas de reenvío privadas a otras VPCs configurando el emparejamiento de DNS.
Aun así, tendrás que configurar manualmente los ajustes de DNS en los controladores de dominio. Usa 127.0.0.1 como servidor DNS principal y, opcionalmente, usa la dirección IP de otro controlador de dominio como servidor DNS secundario. Para obtener más información, consulta Configuración de DNS recomendada y opciones alternativas.
Conexión híbrida
En la siguiente sección se detallan las prácticas recomendadas relacionadas con la conectividad híbrida.
Usar el reenvío de DNS entrante para resolver Google Cloud nombres de DNS desde el entorno local
Es posible que los clientes de tu red local necesiten resolver los nombres DNS de los recursos implementados en Google Cloud. Si amplías tu bosque o implementas un bosque de recursos enGoogle Cloud, usa el reenvío de entrada de DNS para permitir que los clientes locales busquen registros DNS de recursos implementados en Google Cloud. Para usar el reenvío entrante, crea una política de servidor DNS para asignar una dirección IP de reenviador entrante y haz que esta dirección sea accesible para la red local.
Si el dominio DNS usado en Google Cloud (por ejemplo, cloud.example.com) es un subdominio del dominio DNS usado en las instalaciones (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 del reenviador entrante. El registro NS hace que los clientes que intentan buscar un nombre de DNS en el dominio alojado en Google Cloudse redirijan a la dirección IP del reenviador entrante.
Si los dominios DNS que se usan en Google Cloud y en tu Active Directory local son diferentes (por ejemplo, cloud.example.com y corp.example.com), configura el reenvío condicional de DNS en tus dominios locales y usa la dirección IP del reenviador entrante como destino. Cuando se solicite resolver un nombre de DNS en el dominio alojado en Google Cloud, los controladores de dominio locales reenviarán la solicitud a la dirección IP del reenviador entrante.
Cuando utilices el reenvío de DNS entrante, asegúrate de que tus cortafuegos estén configurados correctamente.
No es necesario reenviar el DNS entrante si extiendes tu dominio a Active Directory. En este caso, todos los registros DNS del dominio se replican automáticamente en Google Cloud y en tu entorno local, y se pueden consultar en ambos entornos.
Usar el reenvío de salida de DNS para resolver nombres de 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 de forma local. Si amplías tu bosque o implementas un bosque de recursos en Google Cloud, crea una zona de reenvío privada en Cloud DNS para reenviar las consultas de DNS de tus dominios locales a tus servidores DNS locales.
Cuando utilices la redirección de DNS saliente, asegúrate de que tus cortafuegos estén configurados correctamente.
No es necesario reenviar el DNS saliente si extiendes tu dominio a Active Directory. En este caso, todos los registros DNS del dominio se replican automáticamente en Google Cloud y en tu entorno local, y se pueden consultar en ambos entornos.
Usar 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 que usa Active Directory, LDAP no está cifrado de forma predeterminada.
Google Cloud asegura que el tráfico entre máquinas virtuales esté cifrado, por lo que se puede usar LDAP sin cifrar en tu VPC. Si conectas tu VPC a una red on-premise, asegúrate de que el tráfico LDAP solo se intercambie a través de canales de confianza.
Si usas Cloud VPN para conectar Google Cloud y tu red on-premise, el tráfico se encripta automáticamente mediante IPSec entreGoogle Cloud y tu endpoint de VPN on-premise.
Cloud Interconnect y Partner Interconnect no proporcionan cifrado. Para asegurar la comunicación, establece un túnel VPN a través de la conexión Interconnect mediante un dispositivo VPN de Google Cloud Marketplace.
Usar la autenticación selectiva y AES para las relaciones de confianza entre bosques
Cuando crees una relación de confianza entre bosques de Active Directory, prioriza las relaciones de confianza entre bosques sobre las relaciones de confianza externas y aprovecha las siguientes funciones para mejorar la seguridad:
Habilita la autenticación selectiva en las relaciones de confianza salientes del bosque de recursos. La autenticación selectiva asegura que los usuarios del bosque de la organización no puedan acceder a los recursos del bosque de recursos a menos que se les conceda permiso explícitamente.
Habilita la implementación obligatoria del límite del bosque para la delegación completa de Kerberos en las relaciones de confianza entrantes del bosque de la organización. Esta función ayuda a evitar ataques de escalada de privilegios al no permitir que los recursos del bosque de recursos soliciten TGTs a los usuarios del bosque de la organización.
Habilita la opción El otro dominio admite el cifrado AES de Kerberos al crear relaciones de confianza. Esta opción asegura que los tickets que se usan para la autenticación entre bosques se cifren 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.
Evitar que la seguridad de Google Cloud interfiera con la seguridad de Active Directory
Active Directory te ofrece 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 proyecto subyacente, debes tener en cuenta otras rutas que podrían permitir a un usuario acceder a una máquina: Google Cloud
Un miembro de un proyecto al que se le ha asignado el rol Administrador de instancias de Compute en un Google Cloud proyecto puede usar la función de restablecimiento de contraseña para crear cuentas de administrador locales. Las cuentas de administrador locales suponen una amenaza para la seguridad de tu dominio de Active Directory, ya que se pueden usar para eludir 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.
Si se añade una secuencia de comandos de inicio, un miembro del proyecto con privilegios puede inyectar código malicioso en una máquina virtual que se ejecute como
nt authority\systemla próxima vez que se reinicie la máquina.Si usas la consola serie, un miembro del proyecto con privilegios también puede acceder a la consola de administración especial (SAC) de Windows. Windows considera los inicios de sesión a través de SAC como inicios de sesión locales. Por lo tanto, el SAC se puede usar de forma inadecuada para eludir las políticas que deniegan los inicios de sesión a través de RDP, pero no deniegan los inicios de sesión locales.
Un miembro del proyecto con privilegios puede usar el SAC para emitir un comando
crashdump, que puede provocar que se escriba un volcado de memoria en el disco. Este volcado de memoria puede incluir información sensible y credenciales.Si se monta el disco persistente en otra VM o se usan instantáneas, un miembro del proyecto con privilegios podría acceder al contenido del disco, lo que podría incluir volcados de memoria, desde máquinas a las que el usuario no tendría permiso para iniciar sesión.
Si usas Microsoft AD gestionado, estarás mejor protegido contra estas vías de acceso adicionales de forma predeterminada. El servicio no permite que los usuarios con privilegios de tu proyecto restablezcan la contraseña del administrador del dominio, ejecuten secuencias de comandos de inicio ni accedan a la consola serie en las VMs del controlador de dominio de AD.
Para reducir aún más estos riesgos, asegúrate de que los permisos de gestión de identidades y accesos de los proyectos que contengan instancias de VM unidas a un dominio se gestionen con el principio de privilegio mínimo. Puedes reducir aún más los riesgos mediante el uso de políticas de organización, políticas de grupo y VMs blindadas:
Usa una política de la organización para inhabilitar el acceso a los puertos serie.
Aplica una política de grupo que impida la creación de cuentas de administrador local inhabilitando el gestor de cuentas. Define una preferencia de archivos INI en tu directiva de grupo (Configuración del equipo > Preferencias > Configuración de Windows > Archivos INI) para aplicar el siguiente ajuste:
- Acción: actualizar
- Ruta del 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 elimine las cuentas de administrador locales de las instancias de VM. Usa la función Usuarios y grupos locales (Configuración del equipo > Preferencias > Configuración del Panel de control > Usuarios y grupos locales) para quitar la pertenencia al grupo Administradores y a otros grupos sensibles.
Te recomendamos que uses VMs protegidas junto con el cifrado de disco BitLocker para evitar que usuarios no autorizados puedan leer discos persistentes o capturas.
Evitar que la seguridad de Active Directory interfiera con la Google Cloud seguridad
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. A menos que se restrinja mediante una política de grupo, una política de seguridad local de un equipo o una autenticación selectiva, un usuario que haya demostrado su identidad correctamente a uno de los controladores de dominio podrá iniciar sesión en cualquier equipo del dominio.
La capacidad de los usuarios de Active Directory para iniciar sesión en cualquier máquina puede permitir a los atacantes realizar movimientos laterales dentro de un dominio. Estos movimientos laterales pueden provocar escaladas de privilegios si algunas instancias de VM están exentas de las restricciones del firewall o usan Google Cloud cuentas de servicio: las credenciales de una cuenta de servicio son accesibles para todos los procesos y usuarios de una instancia de VM. Por lo tanto, cualquier usuario que pueda usar Active Directory para iniciar sesión en una máquina puede acceder a estas credenciales de cuenta de servicio para obtener acceso a cualquier recurso de Google Cloudal que se le haya concedido acceso a la cuenta de servicio.
Al configurar Microsoft AD gestionado, el servicio crea un grupo para permitir fácilmente que usuarios específicos puedan conectarse a máquinas virtuales unidas a un dominio mediante RDP.
Para reducir el riesgo de movimientos laterales, organiza a los usuarios en niveles administrativos y usa las políticas de grupo Deny access to this computer from the network (Denegar acceso a este ordenador desde la red) y Deny logon through Remote Desktop Services (Denegar inicio de sesión a través de Servicios de Escritorio remoto) para restringir el acceso a tus VMs en función del nivel.
En una topología de bosque de recursos, aprovecha aún más la autenticación selectiva para restringir el conjunto de usuarios de otros bosques que pueden iniciar sesión en tus VMs. Puedes simplificar la gestión de los permisos de autenticación selectiva alineando Google Cloud y las estructuras de recursos de Active Directory: si las unidades organizativas de Active Directory se asignan a proyectos de Google Cloud , puedes conceder a los usuarios el derecho de autenticarse en un nivel que coincida con un proyecto deGoogle Cloud .
En los casos en los que no se puedan aplicar la autenticación selectiva ni las políticas de grupo, crea una cuenta de servicio independiente, exporta las claves de la cuenta de servicio, guárdalas en el disco local de la instancia de VM o en un recurso compartido de archivos y protégelas con una LCA de NTFS para que solo los usuarios de Active Directory autorizados puedan leer y usar las claves.
Usar proyectos dedicados para los controladores de dominio
Los controladores de dominio desempeñan un papel fundamental en la seguridad de un dominio de Active Directory. Si se vulnera un solo controlador de dominio, se puede vulnerar todo el bosque de Active Directory.
Para limitar el riesgo de acceso no autorizado, usa un Google Cloud proyecto independiente para implementar controladores de dominio y concede acceso a este proyecto con el principio de privilegio mínimo. Cuando crees el proyecto, ten en cuenta que algunos permisos se pueden heredar de las carpetas principales. Para evitar que se conceda acceso por herencia de forma inadvertida, crea el proyecto fuera de tu jerarquía de carpetas habitual.
Cuando configures las políticas de IAM del proyecto, presta especial atención a la restricción del acceso a las instancias de VM, a los discos persistentes que contengan la base de datos ntds.dit y a cualquier ubicación de almacenamiento que pueda contener copias de seguridad.
Además de usar políticas de gestión de identidades y accesos para limitar el acceso al proyecto, protégelo para que no se elimine por error.
Usar máquinas virtuales y proyectos independientes para gestionar Active Directory
Para gestionar Active Directory, debes poder usar herramientas como Usuarios y equipos de Active Directory o el Centro de administración de Active Directory. Para usar estas herramientas, debes iniciar sesión con una cuenta de dominio con privilegios, lo que convierte al equipo en el que ejecutas estas herramientas en un objetivo atractivo para el robo de credenciales o el registro de pulsaciones de teclas.
Para minimizar el riesgo de que un atacante obtenga credenciales de dominio con privilegios, usa instancias de VM dedicadas para la administración del dominio y gestiona esas VMs de administración como estaciones de trabajo con acceso privilegiado:
Usa políticas de grupo para asegurarte de que solo un subconjunto de usuarios tenga derecho a iniciar sesión en las máquinas virtuales de gestión. Si has implementado la administración por niveles, este grupo de usuarios corresponde al nivel 0.
Al igual que los controladores de dominio, las VMs administrativas pueden correr riesgos si los miembros del proyecto crean cuentas de administrador locales, inician sesión a través de la consola serie o manipulan sus discos persistentes. Para limitar el riesgo de accesos no autorizados, usa unGoogle Cloud proyecto independiente para las máquinas virtuales administrativas y concede acceso a este proyecto según el principio de mínimos accesos.
Si tienes previsto acceder a las máquinas virtuales administrativas desde una red local mediante conectividad híbrida, implementa las máquinas virtuales administrativas en una subred de VPC específica. Una subred dedicada a las máquinas virtuales de gestión te permite distinguir mejor entre las máquinas virtuales administrativas y otras máquinas virtuales al configurar tus cortafuegos locales. Si usas una VPC compartida, utiliza permisos a nivel de subred para asegurarte de que solo los administradores con privilegios puedan implementar instancias de VM en la subred de gestión. De esta forma, si los firewalls locales aplican reglas diferentes a las máquinas virtuales de gestión que a otras máquinas virtuales, los usuarios no pueden eludir las reglas del firewall colocando máquinas virtuales que no sean de gestión en la subred de gestión.
Además, considera la posibilidad de restringir la política de grupo que gestiona las restricciones de inicio de sesión de las VMs de gestión a la subred de gestión. Esta práctica obliga a que haya una alineación entre las restricciones de inicio de sesión (basadas en una política de grupo) y las reglas de cortafuegos (basadas en la subred o la dirección IP).
Además de usar políticas de gestión de identidades y accesos para limitar el acceso al proyecto, protégelo para que no se elimine por error.
Usar reglas de cortafuegos para proteger los controladores de dominio y los servidores
Los controladores de dominio exponen varios servicios, como LDAP, DNS, Kerberos y RPC. En función de tus casos prácticos, es posible que las VMs implementadas en Google Cloud, así como las máquinas que se ejecutan de forma local, necesiten acceder a diferentes subconjuntos de estos servicios para aprovechar Active Directory.
Cuando se usa Microsoft AD gestionado, los controladores de dominio de AD se despliegan en un proyecto de inquilino dedicado. La red que aloja los controladores de dominio de AD está protegida automáticamente con reglas de cortafuegos reforzadas específicas de AD.
Para reducir la superficie de ataque de los controladores de dominio y de tus VMs, usa cortafuegos para inhabilitar cualquier comunicación de red que no sea estrictamente necesaria. Consulta nuestra guía sobre cómo usar Active Directory en cortafuegos para obtener información sobre las configuraciones de cortafuegos necesarias para acceder a Active Directory desde tu VPC o desde redes locales.
Organizar los recursos y los usuarios de Active Directory en niveles administrativos
Algunos equipos de un bosque de Active Directory son más importantes para la seguridad general de Active Directory que otros. Los controladores de dominio y las VMs administrativas son dos ejemplos de máquinas que son especialmente críticas y, por lo tanto, especialmente sensibles a posibles ataques.
Para identificar la criticidad de cada una de tus máquinas, usa una taxonomía de niveles. Aunque el número adecuado de niveles depende de tu configuración específica, puedes empezar distinguiendo entre tres niveles:
Nivel 0 (muy crítico): este nivel incluye todas las máquinas que son críticas para la seguridad de tu bosque de Active Directory. Una vez que se vea comprometida una sola máquina de nivel 0, debes asumir que todo el bosque está comprometido.
Nivel 1 (crítico): 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 empresarial considerable, pero no supone 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 la vulneración de una máquina de nivel 2 tenga un impacto limitado en la empresa y en la seguridad general.
Aunque el impacto inmediato de una máquina de nivel 2 vulnerada pueda parecer limitado, existe el riesgo de que se produzcan efectos en cadena: si se engaña a un usuario que tiene acceso de administrador a máquinas de nivel 0 o 1 para que inicie sesión en una máquina de nivel 2 vulnerada, puede ser víctima de un keylogger u otras formas de robo de credenciales. Las credenciales capturadas se pueden usar para atacar máquinas de niveles superiores, lo que provoca que el impacto general aumente.
Para evitar estos efectos, no solo debes categorizar las máquinas, sino también las cuentas de usuario, y restringir el conjunto de máquinas a las que tienen acceso estos usuarios:
Nivel 0 (muy 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.
Usa la siguiente tabla como referencia para saber qué usuarios deben tener acceso a qué recursos:
| Grupo | Nivel | Acceso al dominio | Acceso a ordenadores de nivel 0 | Acceso a ordenadores de nivel 1 | Acceso a ordenadores de nivel 2 |
|---|---|---|---|---|---|
| Administradores de Active Directory | 0 | Administrador | Usuario limitado | Bloqueado | Bloqueado |
| Administradores del servidor de gestión | 0 | Usuario limitado | Administrador | Bloqueado | Bloqueado |
| Administradores de servidores | 1 | Usuario limitado | Bloqueado | Administrador | Bloqueado |
| Administradores de estaciones de trabajo VDI | 2 | Usuario limitado | Bloqueado | Bloqueado | Administrador |
| Usuarios de estaciones de trabajo VDI | 2 | Usuario limitado | Bloqueado | Bloqueado | Usuario limitado |
Consulta la documentación de Microsoft para obtener más información y conocer las prácticas recomendadas para implementar 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 entre bosques no afecten a su integridad. Si el bosque de confianza también aplica un modelo de administración por niveles, usa la autenticación selectiva para asegurarte de que los usuarios del bosque de confianza solo puedan acceder a los recursos del mismo nivel:
Si el bosque de confianza no implementa la administración por niveles, asigna el bosque de confianza a un nivel determinado y usa la autenticación selectiva para asegurarte de que los usuarios del bosque de confianza solo puedan acceder a los recursos de ese nivel concreto.
Usar Controles de Servicio de VPC y Acceso privado de Google para hosts on-premise
Las APIs de Microsoft AD gestionado permiten restablecer la contraseña de administrador y realizar otras operaciones sensibles. En las implementaciones de producción críticas, te recomendamos que habilites Controles de Servicio de VPC y que uses Acceso privado de Google para los hosts locales con el fin de aumentar la seguridad.
Gestión
En la siguiente sección se detallan las prácticas recomendadas relacionadas con la gestión de Active Directory.
Alinear Google Cloud y estructuras de recursos de Active Directory
Cuando implementas un nuevo dominio o bosque de Active Directory enGoogle Cloud, debes definir una estructura de unidades organizativas para organizar tus recursos con tu dominio de Active Directory. En lugar de diseñar una estructura completamente nueva o aplicar la estructura que usas en tu entorno local, crea una estructura de unidad organizativa que se ajuste a tu Google Cloud jerarquía de recursos:
Si usas un modelo de administración por niveles, las UOs de nivel superior deben reflejar tus niveles administrativos.
Crea unidades organizativas para usuarios y grupos en cada nivel. Si tienes previsto gestionar un gran número de usuarios y grupos, crea subunidades organizativas según sea necesario.
En cada nivel, crea una
Projectsunidad organizativa y subunidades organizativas para cada proyectoGoogle Cloud que contenga recursos de Active Directory. Usa la subunidad organizativa específica del proyecto para gestionar cuentas de ordenador, cuentas de servicio u otros recursos de Active Directory que correspondan a los Google Cloud recursos del proyecto en cuestión. Asegúrate de que haya una asignación de uno a uno entre las UOs y los proyectos.
En el siguiente diagrama se muestra un ejemplo de jerarquía que sigue estos principios:
Si el número de proyectos que contienen recursos de Active Directory es moderado, puedes crear una estructura de UOs plana en la unidad organizativa Projects. Si tienes previsto gestionar un gran número de proyectos y has diseñado tuGoogle Cloud jerarquía de recursos para usar varios niveles de carpetas, te recomendamos que reflejes esta estructura de carpetas en la unidad organizativa Projects.
Alinear la estructura de las unidades organizativas de Active Directory y la jerarquía de recursos tiene varias ventajas: Google Cloud
Cuando delegas permisos de administrador en un Google Cloud proyecto mediante políticas de gestión de identidades y accesos, es posible que también tengas que conceder ciertos privilegios a los usuarios del proyecto en Active Directory. Por ejemplo, los administradores de Compute Engine pueden necesitar unir máquinas al dominio de una unidad organizativa concreta. Al alinear las UOs y los Google Cloud proyectos puedes conceder estos permisos con el mismo nivel de granularidad en Active Directory que en Google Cloud.
Si tienes previsto usar objetos de directivas de grupo (GPOs) para gestionar ordenadores, una estructura de unidad organizativa que refleje la Google Cloud jerarquía de recursos te ayudará a asegurarte de que los GPOs se apliquen de forma coherente a todas las VMs de un proyecto o una carpeta concretos.
Si usas una confianza entre bosques con autenticación condicional, puedes usar las UOs que correspondan a los proyectos de Google Cloud para conceder el permiso Allowed to authenticate (Permitir autenticación) por proyecto.
Cuando eliminas un proyecto en Google Cloud, puedes eliminar la unidad organizativa asociada para reducir el riesgo de que queden recursos obsoletos en tu directorio.
Si crees que la estructura de tus UOs debe desviarse de la estructura de tus proyectos, puede que la estructura de tus proyectos sea demasiado detallada o demasiado general.
Usar servidores de hora de Google
La autenticación de Kerberos se basa en marcas de tiempo como parte de su protocolo. Para que la autenticación se realice correctamente, los relojes de la máquina del cliente y del servidor deben sincronizarse dentro de un margen determinado. De forma predeterminada, Active Directory no permite una diferencia de más de 5 minutos.
En un entorno de Active Directory local, la configuración predeterminada para sincronizar la hora es la siguiente:
- Los equipos unidos a un dominio sincronizan su hora con un controlador de dominio.
- Los controladores de dominio sincronizan su hora con el emulador de PDC de su dominio.
- Los emuladores de PDC de todos los dominios sincronizan su hora con el emulador de PDC del dominio raíz del bosque.
En esta configuración, el emulador de PDC del dominio raíz del bosque es la fuente de tiempo definitiva de Active Directory. Es habitual configurar esta máquina para que use un servidor NTP externo como fuente de tiempo.
En Compute Engine, la configuración predeterminada de las VMs 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 de PDC del dominio raíz del bosque se haya implementado fuera de Google Cloud.
Si tu emulador de PDC se ha implementado fuera de Google Cloud, configúralo para que use time.google.com como fuente NTP.
También puedes restaurar el comportamiento predeterminado de Active Directory de sincronizar la hora con el emulador de PDC. Para ello, vuelve a configurar las VMs de Compute Engine para que usen la fuente NTP DOMHIER y configura reglas de firewall para permitir el tráfico NTP entrante (UDP/123) a tus controladores de dominio.
Consolidar y monitorizar registros de auditoría
Cuando implementas Active Directory en Google Cloud, la seguridad de tu bosque de Active Directory y de tus proyectos de Google Cloud está vinculada entre sí: la actividad sospechosa en Active Directory y Windows puede poner en peligro la seguridad de otros recursos de la misma forma que la actividad sospechosa en Google Cloud puede poner en riesgo tu Active Directory.
Los registros de auditoría coherentes son una herramienta importante para identificar amenazas o errores de configuración de forma temprana, así como para reconstruir y examinar la actividad anterior. Cloud Audit Logging te permite registrar y analizar registros de actividad del administrador y registros de acceso a datos. Del mismo modo, puedes usar los registros de reglas de cortafuegos y los registros de flujo de VPC para analizar el tráfico de red. Sin embargo, estos servicios de plataforma no tienen constancia de ningún evento relacionado con la seguridad que tenga lugar en Active Directory. Para establecer un registro de auditoría coherente que cubra tanto los eventos de auditoría relacionados con la plataforma como los 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 registre todos los eventos que necesitas para tus auditorías. Consulta las recomendaciones de Microsoft sobre cómo configurar políticas de auditoría y monitorizar Active Directory para detectar signos de vulneración y así asegurarte de registrar todos los eventos de auditoría relevantes.
Cuando se trata de un gran volumen de eventos, es fácil pasar por alto los eventos críticos. Para no perderte eventos críticos, crea métricas basadas en registros para los eventos que puedan ser especialmente críticos o sospechosos y considera la posibilidad de configurar alertas para recibir notificaciones cuando la frecuencia de los eventos cambie o supere los umbrales aceptables.
Siguientes pasos
Descubre qué patrón para usar Active Directory en un entorno híbrido se adapta mejor a tu situación.
Consulta cómo configurar Active Directory para que las máquinas virtuales se unan automáticamente a un dominio.
Prueba otras Google Cloud funciones por tu cuenta. Consulta nuestros tutoriales.