Neste guia, apresentamos as práticas recomendadas para executar o Active Directory no Google Cloud. O guia se concentra em práticas específicas para o Google Cloud ou de importância especial ao implantar o Active Directory no Google Cloud. Considere o guia como complementar às práticas recomendadas gerais para proteger o Active Directory publicado pela Microsoft.
Arquitetura
As seções a seguir detalham as práticas recomendadas relacionadas à arquitetura.
Use o padrão de arquitetura que melhor se adapta aos seus requisitos
Para implantar o Active Directory no Google Cloud, primeiro você precisa decidir qual arquitetura de floresta e domínio usará. Se já usa o Active Directory, decida também se e como integrar os dois ambientes.
O design adequado à sua situação depende de vários fatores, incluindo o design da sua rede local, a interação entre os recursos locais e os do Google Cloud, bem como seus requisitos para disponibilidade e autonomia administrativa. Consulte nossos padrões de uso do Active Directory em um ambiente híbrido para ver como esses fatores determinam seu design.
Se você quiser manter um limite de confiança entre o Google Cloud e seu ambiente local, considere implementar o padrão de floresta de recursos. Nesse padrão, implante uma floresta separada no Google Cloud e use uma confiança de floresta unidirecional para integrar a floresta do Google Cloud à floresta local já existente do Active Directory.
Testes e produção separados
Dependendo do uso do Active Directory, pode ser necessário realizar alterações frequentes no Active Directory durante o desenvolvimento e o teste de aplicativos. Os desenvolvedores podem precisar criar e modificar contas do Active Directory, alterar as associações do grupo se os aplicativos usarem grupos para processar autorização ou participar e remover computadores.
Para evitar que o trabalho de desenvolvimento e teste cause impactos nas cargas de trabalho de produção ou na segurança da implantação, pense em implantar um domínio ou uma floresta do Active Directory separados para desenvolvimento e teste.
Ter um domínio ou floresta de desenvolvimento e teste separado também permite verificar alterações administrativas antes de aplicá-las à produção. Exemplos dessas alterações incluem testar políticas de grupo, testar scripts de automação ou ações potencialmente perigosas, como aumentar o nível funcional de uma floresta.
Configure a federação do Cloud Identity e implante o Active Directory no Google Cloud
A implantação do Active Directory no Google Cloud permite gerenciar VMs do Windows no Google Cloud, permite que os usuários efetuem login nas VMs do Windows usando suas contas de usuário existentes e é compatível com aplicativos que dependem de Kerberos, NTLM ou LDAP para autenticação.
No entanto, para usar o Console do Google Cloud, a ferramenta de linha de comando gcloud ou outras ferramentas do Google e do Google Cloud, você precisa se autenticar com uma identidade do Google. Portanto, não é possível implantar o Active Directory no Google Cloud
como um substituto à federação do Active Directory existente com o
Google Cloud se você pretende usar o Active Directory
como sistema líder para gerenciamento de usuários.
Por exemplo, se você implantar uma floresta separada no Google Cloud, poderá configurar a federação no seu Active Directory local, conforme ilustrado pelo diagrama a seguir. Os usuários com contas no Active Directory local podem usar ferramentas que exigem uma identidade do Google e também os aplicativos que dependem do Active Directory para autenticação.
Se você decidir estender a floresta atual ou o domínio para o Google Cloud, também terá a opção de usar os controladores de domínio e os servidores do AD FS implantados. no Google Cloud para configurar a federação.
A federação também permite impor um ciclo de vida comum para contas do Google e contas do Active Directory, para que, quando você desabilitar uma conta de usuário no Active Directory local, o usuário correspondente do Google também seja suspenso.
Rede
Na seção a seguir, detalhamos as práticas recomendadas relacionadas à rede.
Implante o Active Directory em uma rede VPC compartilhada
Para permitir que o Active Directory seja usado em vários projetos, implante controladores de domínio em uma rede VPC compartilhada. O uso de uma rede VPC compartilhada tem várias vantagens:
Cada aplicativo que pode exigir acesso ao Active Directory pode potencialmente ser implantado em um projeto separado. O uso de projetos separados ajuda a isolar recursos e permite gerenciar o acesso individualmente.
Use um projeto dedicado para controladores de domínio do Active Directory, que permite um controle refinado sobre os quais os usuários podem acessar recursos relacionados ao Google Cloud.
As redes VPC compartilhada permitem centralizar o gerenciamento de endereços IP e a configuração do firewall, o que ajuda a garantir a consistência em vários projetos.
Como as VPCs são um recurso global, é possível usar a mesma rede VPC compartilhada em várias regiões.
Não exponha controladores de domínio externamente
Para reduzir a superfície de ataque do Active Directory, evite atribuir endereços IP externos a controladores de domínio.
Como as instâncias da VM sem endereços IP externos não têm acesso à Internet por padrão, é necessário executar outras etapas para garantir que a ativação e as atualizações do Windows não sejam prejudicadas nos controladores de domínio.
Para oferecer suporte à ativação do Windows, habilite o Acesso privado do Google na sub-rede em que planeja implantar controladores de domínio e verifique se as instâncias da VM podem acessar kms.windows.googlecloud.com. Isso permite que a ativação ocorra sem acesso direto à Internet.
Há várias opções para oferecer compatibilidade com as atualizações do Windows:
Se você tiver um servidor WSUS local, poderá configurar a conectividade híbrida e também seus controladores de domínio para que usem o servidor WSUS como fonte de atualizações.
Habilite o acesso à Internet por meio de um gateway NAT implantando Cloud NAT.
Se você tiver configurado a conectividade híbrida, também poderá encaminhar o tráfego de saída usando um gateway NAT ou servidor proxy local.
Reserve endereços IP estáticos para controladores de domínio com antecedência
Como os controladores de domínio servem como servidores DNS, eles precisam receber um endereço IP que não mude. Para isso, reserve e atribua endereços IP internos estáticos a VMs de controlador de domínio.
Quando você reserva um endereço IP, o comportamento padrão é que um endereço não utilizado seja escolhido automaticamente. Para garantir que os endereços IP dos controladores de domínio sejam fáceis de memorizar, reserve um endereço IP estático interno.
Nos controladores de domínio, defina o endereço IP do adaptador de rede como o mesmo endereço. Embora essa etapa seja opcional, ela impede que o Active Directory emita mensagens de aviso indicando que o endereço IP da máquina ainda pode ser atribuído dinamicamente.
Implante controladores de domínio em várias zonas
Para aumentar a disponibilidade, implante pelo menos dois controladores de domínio e distribua-os em várias zonas. Como as sub-redes e os endereços IP não estão vinculados a uma zona, é possível implantar todos os controladores de domínio em uma única sub-rede.
Se você planeja implantar cargas de trabalho em várias regiões, implante controladores de domínio em cada região relevante. Como as sub-redes são um recurso regional, a implantação em uma região extra exigirá uma sub-rede adicional.
Crie um site por região
Quando um cliente tenta localizar um controlador de domínio, ele primeiro procura um controlador de domínio no site do Active Directory que corresponda ao endereço IP do cliente. Se nenhum controlador de domínio estiver disponível nesse site, o cliente continuará e tentará localizar um controlador de domínio em outro site.
Aproveite esse comportamento criando um site separado para cada região em que você implanta controladores de domínio ou clientes de domínio. Os clientes preferem usar controladores de domínio localizados na mesma região, o que pode ajudar a reduzir a latência e o custo de transferência de dados de saída entre regiões.
Se você tiver clientes em regiões que não têm um controlador de domínio, poderá influenciar quais controladores de domínio eles escolherão ajustando custos de link do site para refletir a proximidade geográfica das regiões e habilitando a configuração Tente site mais próximo.
O uso de vários sites influencia o comportamento de replicação entre os controladores de domínio. Uma desvantagem do uso de vários sites pode ser que a replicação entre sites ocorre com menos frequência do que a replicação intrasite.
No entanto, não é possível criar sites do Active Directory no Microsoft AD gerenciado porque esse serviço não é compatível com o recurso Sites e serviços do Active Directory.
Use zonas de encaminhamento privado do Cloud DNS
Ao criar uma nova instância de VM no Compute Engine, o sistema operacional será pré-configurado para usar um servidor DNS padrão que fornece acesso ao DNS interno e ao DNS público.
Antes de associar uma máquina a um domínio do Active Directory, você precisa garantir que a máquina possa resolver os registros DNS gerenciados pelo Active Directory. O servidor DNS padrão que o Compute Engine configura para uma instância de VM fornece acesso ao DNS interno e ao DNS público, mas não poderá resolver nomes DNS gerenciados pelo Active Directory.
Crie uma zona de encaminhamento de DNS particular no Cloud DNS para permitir que os clientes resolvam registros DNS gerenciados pelo Active Directory. Configure a zona para encaminhar consultas que correspondam ao domínio do Active Directory para os controladores de domínio.
O uso de uma zona de encaminhamento de DNS particular tem várias vantagens em relação à configuração dos clientes para usar diretamente seus controladores de domínio do Active Directory como servidores DNS:
Não é preciso ajustar a configuração de rede das instâncias de VM. Isso simplifica o processo de criação de novas VMs.
Ao promover ou rebaixar um controlador de domínio, você só precisa atualizar a configuração da zona de encaminhamento de DNS particular e não precisa modificar as configurações do cliente.
As instâncias de VM ainda têm acesso ao DNS interno.
Quaisquer registros DNS que não correspondam ao seu domínio do Active Directory serão tratados pelo Cloud DNS, reduzindo a carga nos controladores de domínio.
Se você usar vários domínios, crie uma zona de encaminhamento de DNS particular separada para cada domínio do Active Directory.
As zonas de encaminhamento privado do Cloud DNS têm como escopo uma única VPC. Se você usar várias VPCs conectadas usando peering, poderá expor as zonas de encaminhamento privadas a outras VPCs configurando peering DNS.
Você também precisa definir manualmente as configurações de DNS nos controladores de domínio. Use
127.0.0.1 como o servidor DNS primário e use o IP de outro controlador de domínio
como o servidor DNS secundário. Para ver mais informações, consulte
Configurações de DNS recomendadas e opções alternativas.
Conectividade híbrida
Na seção a seguir, detalhamos as práticas recomendadas relacionadas à conectividade híbrida.
Use o encaminhamento de entrada DNS para resolver os nomes DNS do Google Cloud no local
Os clientes na sua rede local podem precisar resolver os nomes de DNS dos recursos implantados no Google Cloud. Se você estender a floresta ou implantar uma floresta de recursos no Google Cloud, use o encaminhamento de entrada de DNS para permitir que os clientes locais busquem registros DNS para recursos implantados no Google Cloud. Para usar o encaminhamento de entrada, crie uma política de servidor DNS para alocar um endereço IP do encaminhador de entrada e torne-o acessível à rede local.
Se o domínio de DNS usado no Google Cloud (por exemplo, cloud.example.com) for um subdomínio
do domínio DNS usado no local (por exemplo, example.com), configure a delegação de
DNS. Crie um registro NS no domínio local que aponte para o
endereço IP do encaminhador de entrada. O registro NS faz com que os clientes tentem buscar
um nome DNS no domínio hospedado pelo Google Cloud para serem redirecionados para o
endereço IP do encaminhador de entrada.
Se os domínios DNS usados no Google Cloud e no Active Directory local forem diferentes (por exemplo, cloud.example.com e corp.example.com), configure o encaminhamento de DNS condicional nos domínios locais e use o endereço IP do encaminhador de entrada como destino. Quando solicitados a resolver um nome DNS no domínio hospedado no Google Cloud, os controladores de domínio locais encaminham a busca para o endereço IP do encaminhador de entrada.
Ao usar o encaminhamento de DNS de entrada, verifique se os firewalls estão configurados corretamente.
O encaminhamento de entrada de DNS não será necessário se você ampliar seu domínio atual para o Active Directory. Nesse cenário, todos os registros DNS do domínio são replicados automaticamente no Google Cloud e no seu ambiente local e disponibilizados para busca em ambos os ambientes.
Use o encaminhamento de saída DNS para resolver os nomes DNS do Google Cloud no local
Os clientes em execução no Google Cloud podem precisar resolver os nomes dos recursos implantados no local. Se você ampliar a floresta ou implantar uma floresta de recursos no Google Cloud, crie uma zona de encaminhamento privada no Cloud DNS para encaminhar consultas DNS dos seus domínios locais para os servidores DNS locais.
Ao usar o encaminhamento de DNS de saída, verifique se seus firewalls estão configurados corretamente.
O encaminhamento de saída de DNS não será necessário se você ampliar seu domínio atual para o Active Directory. Nesse cenário, todos os registros DNS do domínio são replicados automaticamente no Google Cloud e no ambiente local, além de disponibilizados para busca em ambos os ambientes.
Use túneis VPN para proteger o tráfego LDAP
O Active Directory faz uso extensivo do protocolo LDAP. Ao contrário da maioria dos outros protocolos usados pelo Active Directory, o LDAP não é criptografado por padrão.
O Google Cloud garante que o tráfego entre máquinas virtuais seja criptografado. Portanto, o uso de LDAP não criptografado na VPC é aceitável. Se você conectar sua VPC a uma rede local, garanta que o tráfego LDAP seja trocado apenas por canais confiáveis.
Se você usa o Cloud VPN para conectar o Google Cloud e sua rede local, o tráfego é criptografado automaticamente usando IPSec entre o Google Cloud e seu endpoint da VPN local.
O Cloud Interconnect e o Partner Interconnect não fornecem criptografia. Para garantir uma comunicação segura, estabeleça um túnel VPN pela conexão do Interconnect usando um dispositivo VPN do Google Cloud Marketplace.
Use autenticação seletiva e AES para relações de confiança da floresta
Ao criar um relacionamento de confiança entre florestas do Active Directory, prefere relações de confiança da floresta a relações de confiança externas e aproveita os recursos a seguir para melhorar a segurança:
Ative a autenticação seletiva em confianças de saída na floresta de recursos. A autenticação seletiva garante que os usuários da floresta organizacional não possam acessar os recursos na floresta de recursos, a menos que a permissão seja concedida explicitamente.
Ative a aplicação do limite da floresta para a delegação completa do Kerberos em confianças de entrada na floresta organizacional. Esse recurso ajuda a evitar ataques de escalonamento de privilégios impedindo que os recursos da floresta de recursos solicitem tíquetes de concessão de tíquete (TGTs, na sigla em inglês) de usuários na floresta organizacional.
Ative a opção O outro domínio é compatível com a criptografia AES do Kerberos ao criar confianças. Essa opção garante que os tíquetes usados para autenticação entre florestas sejam criptografados com AES em vez do algoritmo RC4 menos seguro.
Security
Na seção a seguir, detalhamos as práticas recomendadas relacionadas à segurança.
Evitar que a segurança do Google Cloud interfira na segurança do Active Directory
O Active Directory oferece um controle refinado sobre quais usuários têm permissão para acessar quais recursos. Quando as máquinas são implantadas como instâncias de VM no Compute Engine e os usuários têm acesso ao projeto subjacente do Google Cloud, é preciso considerar caminhos adicionais que podem permitir que um usuário acesse uma máquina:
Um membro do projeto que recebeu o papel Administrador de instância de computação em um projeto do Google Cloud pode usar a funcionalidade de redefinição de senha para criar contas de administrador local. As contas de administrador local representam uma ameaça à segurança do seu domínio do Active Directory, porque podem ser usadas para minar políticas de grupo ou para instalar software malicioso que pode capturar credenciais de domínio de outros usuários conectados.
Ao adicionar um script de inicialização, um membro do projeto privilegiado pode injetar código malicioso em uma VM que será executada como
nt authority\systemna próxima vez que a máquina for reinicializada.Ao usar o console serial, um membro de projeto privilegiado também pode acessar o Console de administração especial do Windows (SAC, na sigla em inglês). O Windows considera os logons por meio do SAC como logons locais. Portanto, o SAC pode ser usado indevidamente para burlar políticas que negam logins via RDP, mas não negam logins locais.
Um membro do projeto com privilégios pode usar o SAC para emitir um comando
crashdump, o que pode fazer com que um dump de memória seja gravado no disco. Esse dump de memória pode incluir informações confidenciais e credenciais.Ao montar o disco permanente em uma VM diferente ou usar snapshots, um membro do privilegiado projeto poderá acessar o conteúdo do disco, incluindo potencialmente dumps de memória, de máquinas em que o usuário não teria permissão para fazer logon.
Ao usar o Managed Microsoft AD, por padrão você fica mais protegido contra esses outros caminhos de acesso. O serviço não permite que usuários privilegiados do seu projeto redefinam a senha do administrador de domínio, executem scripts de inicialização ou acessem o console serial nas VMs do controlador de domínio do AD.
Para reduzir ainda mais esses riscos, verifique se as permissões do IAM de projetos que contêm instâncias de VM associadas ao domínio são gerenciadas de acordo com o privilégio mínimo. É possível reduzir ainda mais o risco de usuários de políticas da organização, políticas de grupo e VMs protegidas:
Use uma política organizacional para desativar o acesso à porta serial.
Aplique uma política de grupo que impeça a criação de contas de administrador local desativando o gerente de contas. Defina uma preferência Arquivos INI em sua política de grupo (Configuração do Computador > Preferências > Configurações do Windows > Arquivos Ini) para aplicar a configuração a seguir:
- Ação: atualizar
- Caminho do arquivo:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - Nome da seção:
accountManager - Nome da propriedade:
disable - Valor da propriedade:
true
aplicar uma política de grupo que remova qualquer conta de administrador local das instâncias de VM. Use a funcionalidade Usuários e grupos locais (Configuração do computador > Preferências > Configurações do painel de controle > Usuários e grupos locais) para remover a associação do grupo Administradores e de outros grupos confidenciais.
Considere usar VMs protegidas em combinação com a criptografia de disco do BitLocker para evitar que usuários não autorizados consigam ler o disco permanente ou snapshots.
Evite que a segurança do Active Directory interfira na segurança do Google Cloud
Em um domínio do Active Directory, as máquinas confiam em controladores de domínio para lidar com autenticação e autorização em nome delas. A menos que seja restringido pela política de grupo, pela política de segurança local de uma máquina ou pela autenticação seletiva, um usuário que tenha comprovado com êxito sua identidade a um dos controladores de domínio poderá fazer logon em qualquer máquina do domínio.
A capacidade de usuários do Active Directory fazerem login em qualquer máquina pode permitir que os invasores realizem movimentos laterais dentro de um domínio. Esses movimentos laterais podem levar a encaminhamentos de privilégios se algumas instâncias de VM forem isentas de restrições de firewall ou usarem contas de serviço do Google Cloud: as credenciais de uma conta de serviço podem ser acessadas por todos os processos e usuários em uma instância de VM. Qualquer usuário que possa usar o Active Directory para fazer login em uma máquina pode acessar essas credenciais da conta de serviço para ter acesso aos recursos do Google Cloud aos quais a conta de serviço tem acesso.
Ao configurar o Managed Microsoft AD, o serviço cria um grupo que facilita a usuários específicos executar RDP em VMs ingressadas no domínio.
Para reduzir o risco de movimentos laterais, organize os usuários em camadas administrativas e use as políticas de grupo Negar acesso a este computador pela rede e Negar logon pelos Serviços de Área de Trabalho Remota para restringir o acesso às suas VMs com base no nível da camada.
Em uma topologia de floresta de recursos, aproveite mais a autenticação seletiva para restringir ainda mais o conjunto de usuários de outras florestas que podem fazer login nas suas VMs. Você pode simplificar o gerenciamento de permissões de autenticação seletivas alinhando as estruturas de recursos do Google Cloud e do Active Directory: se as unidades organizacionais do Active Directory forem mapeadas para projetos do Google Cloud, será possível conceder aos usuários o direito de autenticar em um nível que corresponda a um projeto do Google Cloud.
Nos casos em que nem a autenticação seletiva nem as políticas de grupo são aplicáveis, crie uma conta de serviço separada, exporte as chaves da conta de serviço, salve-as no disco local da instância da VM ou em um compartilhamento de arquivo e proteja-as usando um NTFS ACL para que apenas usuários autorizados do Active Directory possam ler e usar as chaves.
Use projetos dedicados para controladores de domínio
Os controladores de domínio desempenham um papel crucial na segurança de um domínio do Active Directory e o comprometimento de um único controlador de domínio pode resultar no comprometimento de toda a floresta do Active Directory.
Para limitar o risco de acesso não autorizado, use um projeto separado do Google Cloud para implantar controladores de domínio e conceder acesso a esse projeto com base na abordagem de menor privilégio. Ao criar o projeto, lembre-se de que algumas permissões podem ser herdadas de pastas pai. Para evitar conceder acesso inadvertidamente por meio de herança, crie o projeto fora da hierarquia de pastas comum.
Ao configurar políticas do IAM para o projeto, preste atenção especial à restrição de acesso às instâncias da VM, aos discos permanentes que contêm o banco de dados ntds.dit, bem como a quaisquer locais de armazenamento que possam conter backups.
Além de usar as políticas do IAM para limitar o acesso ao projeto, é preciso proteger o projeto contra exclusão acidental.
Use VMs e projetos separados para gerenciar o Active Directory
Para gerenciar o Active Directory, use ferramentas como Usuários e Computadores do Active Directory ou o Centro Administrativo do Active Directory. Essas ferramentas exigem que você faça logon usando uma conta de domínio privilegiada, o que torna a máquina em que você executa essas ferramentas um destino atraente para o roubo de credenciais ou keylogging.
Para minimizar o risco de um invasor conseguir credenciais de domínio privilegiadas, use instâncias de VM dedicadas para administração de domínio e lide com essas VMs de gerenciamento como estações de trabalho com acesso privilegiado:
Use políticas de grupo para garantir que apenas um subconjunto selecionado de usuários tenha o direito de fazer login em VMs de gerenciamento. Se você implementou a administração em camadas, esse grupo de usuários corresponde ao nível 0.
Assim como os controladores de domínio, as VMs administrativas podem ser colocadas em risco pelos membros do projeto criando contas de administrador local, fazendo login por meio do console serial ou adulterando seus discos permanentes. Para limitar o risco de acesso não autorizado, use um projeto separado do Google Cloud para VMs administrativas e conceda acesso a esse projeto com base na abordagem de menor privilégio.
Se você planeja acessar VMs administrativas de uma rede local usando a conectividade híbrida, implante VMs administrativas em uma sub-rede VPC dedicada. Uma sub-rede dedicada a VMs de gerenciamento permite distinguir melhor entre VMs administrativas e outras VMs ao configurar os firewalls locais. Se você usar uma VPC compartilhada, use permissões no nível da sub-rede para garantir que somente administradores com privilégios tenham permissão para implantar instâncias de VM na sub-rede de gerenciamento. Essa prática ajuda a garantir que, se os firewalls locais aplicarem regras diferentes a VMs de gerenciamento, os usuários não poderão burlar regras de firewall colocando VMs que não sejam de gerenciamento na sub-rede de gerenciamento.
Além disso, considere restringir à sub-rede de gerenciamento a política de grupo que gerencia as restrições de logon para VMs de gerenciamento. Essa prática impõe o alinhamento entre restrições de logon (com base em uma política de grupo) e regras de firewall (com base no endereço de sub-rede/IP).
Além de usar as políticas do IAM para limitar o acesso ao projeto, é preciso proteger o projeto contra exclusão acidental.
Use regras de firewall para proteger servidores e controladores de domínio
Os controladores de domínio expõem vários serviços, incluindo LDAP, DNS, Kerberos e RPC. Dependendo dos casos de uso, as VMs implantadas no Google Cloud e as máquinas em execução no local podem precisar de acesso a diferentes subconjuntos desses serviços para aproveitar o Active Directory.
Ao usar o Managed Microsoft AD, os controladores de domínio do AD são implantados em um projeto de locatário dedicado. A rede que hospeda os controladores de domínio do AD é protegida automaticamente por regras de firewall específicas do AD aprimoradas.
Para reduzir a superfície de ataque dos controladores de domínio e das VMs, use firewalls para impedir qualquer comunicação de rede que não seja estritamente necessária. Consulte nosso guia sobre como usar o Active Directory em firewalls para detalhes sobre quais configurações de firewall são necessárias para acessar o Active Directory da sua VPC ou de redes locais.
Organize recursos e usuários do Active Directory em níveis administrativos
Algumas máquinas em uma floresta do Active Directory são mais críticas para a segurança geral do Active Directory do que outras. Os controladores de domínio e as VMs administrativas são dois exemplos de máquinas particularmente críticas e, portanto, particularmente sensíveis a possíveis ataques.
Para identificar a criticidade de cada uma de suas máquinas, use uma taxonomia de níveis. Enquanto o número certo de níveis depende da sua configuração específica, é possível começar distinguindo entre três níveis:
Nível 0 (Altamente crítico): esse nível inclui todas as máquinas críticas à segurança da floresta do Active Directory. Depois que uma única máquina de nível 0 é comprometida, você precisa pressupor que toda a floresta está comprometida.
Nível 1 (Crítico): essa nível inclui a maioria dos servidores em seu ambiente, incluindo servidores de aplicativos e servidores de banco de dados. Um servidor de nível 1 comprometido pode ter um impacto comercial substancial, mas não representa uma ameaça imediata para toda a floresta.
Nível 2 (Normal): esse nível inclui estações de trabalho ou outras máquinas de uso geral. Espera-se que o comprometimento de uma máquina de nível 2 tenha um impacto limitado nos negócios e na segurança geral.
Embora o impacto imediato de uma máquina comprometida do nível 2 possa parecer limitado, há um risco de efeitos indiretos: quando um usuário que tem acesso administrativo a máquinas de nível 0 ou 1 é atraído para fazer logon em uma máquina de nível 2 comprometida, ele pode ser vítima de um keylogger ou de outras formas de roubo de credenciais. As credenciais capturadas podem então ser usadas para atacar máquinas de níveis mais altos, causando o aumento do impacto geral.
Para evitar esses efeitos indiretos, é necessário categorizar as máquinas e também as contas de usuário, além de restringir o conjunto de máquinas que podem ser acessadas por esses usuários:
Nível 0 (Altamente crítico): usuários que têm acesso a máquinas de nível 0.
Nível 1 (Crítico): usuários que têm acesso a máquinas de nível 1.
Nível 2 (Normal): usuários que têm acesso a máquinas de nível 2.
Use a tabela a seguir como orientação para saber quais usuários precisam ter acesso a quais recursos:
| Grupo | Nível | Acesso ao domínio | Acesso ao computador de nível 0 | Acesso ao computador de nível 1 | Acesso ao computador de nível 2 |
|---|---|---|---|---|---|
| Administradores do Active Directory | 0 | Administrador | Usuário limitado | Bloqueado | Bloqueado |
| Administradores do servidor de gerenciamento | 0 | Usuário limitado | Administrador | Bloqueado | Bloqueado |
| Administradores de servidor | 1 | Usuário limitado | Bloqueado | Administrador | Bloqueado |
| Administradores da estação de trabalho VDI | 2 | Usuário limitado | Bloqueado | Bloqueado | Administrador |
| Usuários da estação de trabalho VDI | 2 | Usuário limitado | Bloqueado | Bloqueado | Usuário limitado |
Consulte a documentação da Microsoft para conseguir mais detalhes e práticas recomendadas sobre a implementação de um modelo de nível administrativo no Active Directory.
Ao usar o modelo de nível administrativo na floresta do Active Directory, verifique se a integridade desse modelo não está comprometida pelas relações de confiança da floresta. Se a floresta confiável também aplicar um modelo de administração em níveis, use a autenticação seletiva para garantir que os usuários da floresta confiável só possam acessar recursos no mesmo nível:
Se a floresta confiável não implementar administração em níveis, mapeie a floresta confiável para um determinado nível e use a autenticação seletiva para garantir que os usuários da floresta confiável só possam acessar recursos desse nível específico.
Como usar o VPC Service Controls e o Acesso privado do Google para hosts locais
As APIs do Managed Microsoft AD permitem redefinir a senha do administrador e executar outras operações confidenciais. Para implantações de produção cruciais, recomendamos ativar o VPC Service Controls e usar o Acesso privado do Google para hosts locais para aumentar a segurança.
Gerenciamento
Na seção a seguir, detalhamos as práticas recomendadas relacionadas ao gerenciamento do Active Directory.
Alinhe estruturas de recursos do Google Cloud e do Active Directory
Ao implantar um novo domínio ou floresta do Active Directory no Google Cloud, você precisa definir uma estrutura de unidade organizacional (UO) para organizar seus recursos com o domínio do Active Directory. Em vez de criar uma estrutura totalmente nova ou aplicar aquela já usada em seu ambiente local, crie uma estrutura UO alinhada com sua hierarquia de recursos do Google Cloud:
Se você usar um modelo de administração em níveis, as UOs de nível superior precisarão refletir seus níveis administrativos.
Para cada nível, crie UOs para usuários e grupos. Se você planeja gerenciar um grande número de usuários e grupos, crie subUOs conforme apropriado.
Para cada nível, crie uma UO
Projectse subUOs para cada projeto do Google Cloud que contenha recursos do Active Directory. Use a subUO específica do projeto para gerenciar contas de computador, contas de serviço ou outros recursos do Active Directory que correspondam aos recursos do Google Cloud do respectivo projeto. Verifique se há um mapeamento 1:1 entre UOs e projetos.
No diagrama a seguir, mostramos um exemplo de hierarquia que segue estes princípios:
Se o número de projetos que contêm recursos do Active Directory for moderado, será possível criar uma estrutura de UO simples na UO Projects. Se você quer gerenciar um grande número de projetos e criou sua hierarquia de recursos do Google Cloud para usar vários níveis de pastas, considere refletir essa estrutura de pastas abaixo da UO Projects.
O alinhamento da estrutura de UO do Active Directory com a hierarquia de recursos do Google Cloud oferece várias vantagens:
Ao delegar permissões administrativas para um projeto do Google Cloud usando políticas do IAM, conceda também aos usuários do projeto determinados privilégios no Active Directory. Por exemplo, administradores do Compute Engine podem precisar associar máquinas ao domínio em uma determinada UO. O alinhamento de UOs com projetos do Google Cloud permite conceder essas permissões no mesmo nível de granularidade no Active Directory e no Google Cloud.
Se você planeja usar objetos de política de grupo (GPOs) para gerenciar computadores, uma estrutura de UO que reflete a hierarquia de recursos do Google Cloud ajuda a garantir que os GPOs sejam aplicados de maneira consistente a todas as VMs de um determinado projeto ou pasta.
Se você usar uma relação de confiança entre florestas com autenticação condicional, use as UOs que correspondem aos projetos do Google Cloud para conceder a permissão Permitido autenticar por projeto.
Ao excluir um projeto no Google Cloud, é possível simplesmente excluir a UO associada, reduzindo o risco de deixar recursos obsoletos em seu diretório.
Se você acha que a estrutura da sua UO precisa se desviar da estrutura do projeto, isso poderá ser um indicativo de que a estrutura do projeto é muito refinada ou muito grosseira.
Use servidores de horário do Google
A autenticação Kerberos depende de carimbos de data/hora como parte do protocolo. Para que a autenticação seja bem-sucedida, os relógios da máquina do cliente e do servidor precisam ser sincronizados dentro de uma determinada margem. Por padrão, o Active Directory permite no máximo 5 minutos de diferença.
Em um ambiente do Active Directory no local, estas são a configuração padrão para a sincronização de horário:
- As máquinas associadas ao domínio sincronizam o tempo com um controlador de domínio.
- Os controladores de domínio sincronizam o tempo com o emulador PDC do domínio.
- Os emuladores de PDC de todos os domínios sincronizam o tempo com o emulador PDC do domínio raiz da floresta.
Nessa configuração, o emulador PDC do domínio raiz da floresta é a fonte de tempo final do Active Directory, e é comum configurar essa máquina para usar um servidor NTP externo como fonte de horário.
No Compute Engine, a configuração padrão para VMs do Windows é usar o servidor de metadados
(metadata.google.internal) como servidor NTP, que, por sua vez, depende dos servidores
NTP do Google para receber as o horário correto. Mesclar uma VM a um
domínio do Active Directory não altera essa configuração padrão.
Mantenha a configuração padrão do Compute Engine, a menos que o emulador PDC do domínio raiz da floresta seja implantado fora do Google Cloud.
Se o emulador de PDC for implantado fora do Google Cloud, configure-o
para usar time.google.com como origem do NTP.
Como alternativa, é possível restaurar o comportamento padrão do Active Directory de sincronização
de tempo com o emulador PDC, reconfigurando as VMs do Compute Engine para usar
a origem NTP DOMHIER
e configurando o regras de firewall para permitir o tráfego de entrada NTP (UDP/123) para seus
controladores de domínio.
Consolide e monitore registros de auditoria
Quando você implanta o Active Directory no Google Cloud, a segurança da floresta do Active Directory e dos projetos do Google Cloud é vinculada a outra; atividade suspeita no Active Directory e no Windows pode pôr em risco a segurança de alguns outros recursos da mesma maneira que atividade suspeita no Google Cloud pode colocar o Active Directory em risco.
Os registros de auditoria consistentes são uma ferramenta importante para identificar ameaças ou erros de configuração antecipadamente e permitir que você reconstrua e examine atividades anteriores. O Cloud Audit Logging permite capturar e analisar registros de atividades do administrador e registros de acesso a dados. Da mesma forma, é possível usar os registros de regras de firewall e os registros de fluxo de VPC para analisar o tráfego de rede. No entanto, esses serviços de plataforma não estão cientes de eventos relacionados à segurança que ocorrem no Active Directory. Para estabelecer uma trilha de auditoria consistente que abranja eventos de auditoria relacionados à plataforma e eventos de auditoria relacionados ao Active Directory, instale o agente do Cloud Logging em controladores de domínio e máquinas de mesclagem de domínios para exportar registros de eventos de segurança do Windows para o Cloud Logging.
Por padrão, o registro de eventos de segurança do Windows pode não capturar todos os eventos necessários para fins de auditoria. Consulte as recomendações da Microsoft sobre a configuração de políticas de auditoria e como monitorar o Active Directory quanto a sinais de comprometimento para garantir a captura de todos os eventos de auditoria relevantes.
Ao lidar com um grande volume de eventos, é fácil perder eventos cruciais. Para evitar a perda de eventos cruciais, crie métricas baseadas em registros para eventos que possam ser particularmente cruciais ou suspeitos e considere configurar alertas para notificá-lo quando a taxa de eventos mudar ou exceder os limites aceitáveis.
A seguir
Descubra qual padrão de uso do Active Directory em um ambiente híbrido se adapta melhor à sua situação.
Saiba como configurar o Active Directory para VMs para ingressar automaticamente em um domínio.
Teste outros recursos do Google Cloud. Veja nossos tutoriais.