Práticas recomendadas para executar o Active Directory em Google Cloud

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Este guia apresenta práticas recomendadas para executar o Active Directory em Google Cloud. O guia concentra-se em práticas que são específicas para Google Cloud ou de particular importância ao implantar o Active Directory em Google Cloud. Considere o guia como um complemento às práticas recomendadas gerais para proteger o Active Directory publicadas pela Microsoft .

Arquitetura

As seções a seguir detalham as melhores práticas relacionadas à arquitetura.

Use o padrão de arquitetura que melhor atenda às suas necessidades

Para implantar o Active Directory em Google Cloud, primeiro você precisa decidir qual domínio e arquitetura de floresta usar. Se você já usa o Active Directory, também terá que decidir se e como integrar os dois ambientes.

O design que melhor se adapta à sua situação depende de vários fatores, incluindo o design da sua rede local, como a rede local eGoogle Cloud recursos irão interagir, bem como seus requisitos de disponibilidade e autonomia administrativa. Consulte nossos padrões para usar o Active Directory em um ambiente híbrido para ver como esses fatores devem determinar seu design.

Se você quiser manter um limite de confiança entreGoogle Cloud e seu ambiente local, considere implementar o padrão de floresta de recursos . Neste padrão, você implanta uma floresta separada em Google Cloud e usar um fundo florestal unilateral para integrar o Google Cloud floresta com sua floresta local existente do Active Directory.

Teste 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 teste de aplicativos. Os desenvolvedores podem precisar criar e modificar contas do Active Directory , alterar associações de grupos se os aplicativos usarem grupos para lidar com autorização ou ingressar e remover computadores.

Para evitar que o trabalho de desenvolvimento e teste afete as cargas de trabalho de produção ou prejudique a segurança da sua implantação, considere implantar um domínio ou floresta separada do Active Directory 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 de tais mudanças incluem experimentar políticas de grupo, testar scripts de automação ou ações potencialmente arriscadas, como aumentar o nível funcional de uma floresta.

Configurar a federação do Cloud Identity, além de implantar o Active Directory em Google Cloud

Implantando o Active Directory em Google Cloud permite gerenciar VMs do Windows em Google Cloud, pode permitir que os usuários façam login em VMs do Windows usando suas contas de usuário existentes e oferece suporte a 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 Google Cloud ferramentas, você precisa se autenticar com uma identidade do Google. Implantando o Active Directory em Google Cloud portanto, não substitui a federação do seu Active Directory existente comGoogle Cloud se você pretende usar o Active Directory como seu sistema líder para gerenciamento de usuários.

Por exemplo, se você implantar uma floresta separada em Google Cloud, você poderá configurar a federação no Active Directory local, conforme ilustrado no diagrama a seguir. Os usuários com contas no Active Directory local podem então usar ferramentas que exigem uma identidade do Google, bem como seus aplicativos que dependem do Active Directory para autenticação.

Se você decidir estender sua floresta ou domínio existente para Google Cloud, você também terá a opção de usar controladores de domínio e servidores AD FS implantados em Google Cloud para criar a federação.

A Federação também permite impor um ciclo de vida comum para contas do Google e contas do Active Directory, de modo que, quando você desabilita uma conta de usuário no Active Directory local, o usuário do Google correspondente também seja suspenso.

Rede

A seção a seguir detalha as práticas recomendadas relacionadas à rede.

Implantar 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. Usar uma rede VPC compartilhada tem diversas vantagens:

• Cada aplicativo que possa exigir acesso ao Active Directory pode ser potencialmente implantado em um projeto separado. Usar projetos separados ajuda a isolar recursos e permite gerenciar o acesso individualmente.

• Você pode usar um projeto dedicado para controladores de domínio do Active Directory, que permite um controle refinado sobre quais usuários podem acessar domínios relacionados. Google Cloud recursos.

• As redes VPC compartilhadas 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 , você pode 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 de VM sem endereços IP externos não têm acesso à Internet por padrão, você precisa executar etapas adicionais 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, ative o Acesso privado do Google na sub-rede em que você planeja implantar controladores de domínio e verifique se as instâncias de VM podem acessar kms.windows.googlecloud.com . Isso permite que a ativação ocorra sem acesso direto à Internet.

Existem várias opções para oferecer suporte a atualizações do Windows:

• Se você tiver um servidor WSUS local, poderá configurar a conectividade híbrida e configurar seus controladores de domínio para usar o servidor WSUS como fonte de atualizações.

• Você pode ativar o acesso à Internet por meio de um gateway NAT implantando o Cloud NAT .

• Se você configurou a conectividade híbrida, também poderá rotear o tráfego de saída por meio de um gateway NAT local ou de um servidor proxy.

Reserve endereços IP estáticos para controladores de domínio com antecedência

Como os controladores de domínio funcionam como servidores DNS, eles precisam receber um endereço IP que não mude . Para conseguir isso, configure endereços IP internos estáticos para as VMs do 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 para o mesmo endereço. Embora esta etapa seja opcional, ela impede que o Active Directory emita mensagens de aviso indicando que o endereço IP da máquina ainda pode estar atribuído dinamicamente.

Implante controladores de domínio em diversas zonas

Para aumentar a disponibilidade, implante pelo menos dois controladores de domínio e distribua-os em diversas zonas . Como as sub-redes e os endereços IP não estão vinculados a uma zona, você pode implantar todos os controladores de domínio em uma única sub-rede.

Se você planeja implantar cargas de trabalho em diversas regiões, considere implantar 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 neste site, o cliente prosseguirá e tentará localizar um controlador de domínio em um site diferente.

Você pode aproveitar esse comportamento criando um site separado para cada região em que implantar controladores de domínio ou clientes de domínio. Os clientes preferirão automaticamente 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 possuem um controlador de domínio, poderá influenciar quais controladores de domínio esses clientes escolherão ajustando os custos do link de site para refletir a proximidade geográfica das regiões e ativando a configuração Tentar próximo site mais próximo .

O uso de vários sites influencia o comportamento de replicação entre 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 intra-site.

No entanto, você não pode criar sites do Active Directory no Managed Microsoft AD porque o Managed Microsoft AD não oferece suporte ao recurso Sites e Serviços do Active Directory.

Usar zonas de encaminhamento privadas do Cloud DNS

Quando você cria uma nova instância de VM no Compute Engine, o sistema operacional é pré-configurado para usar um servidor DNS padrão que fornece acesso ao DNS interno e ao DNS público.

Antes de poder associar uma máquina a um domínio do Active Directory, você deve garantir que a máquina seja capaz de 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 será capaz de resolver nomes DNS gerenciados pelo Active Directory.

Crie uma zona privada de encaminhamento de DNS no Cloud DNS para permitir que os clientes resolvam registros DNS gerenciados pelo Active Directory. Configure a zona para encaminhar consultas que correspondam ao seu domínio do Active Directory para seus controladores de domínio.

Usar uma zona de encaminhamento de DNS privada tem diversas vantagens em relação à configuração de clientes para usar diretamente seus controladores de domínio do Active Directory como servidores DNS:

• Você não precisa 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 privada e não precisa modificar nenhuma configuração 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 seus controladores de domínio.

Se você usar vários domínios, crie uma zona de encaminhamento de DNS privada separada para cada domínio do Active Directory.

As zonas de encaminhamento privadas do Cloud DNS têm como escopo uma única VPC. Se você usar várias VPCs conectadas por meio de peering , poderá expor as zonas de encaminhamento privadas a outras VPCs configurando o peering de DNS .

Você ainda precisa definir manualmente as configurações de DNS nos controladores de domínio. Use 127.0.0.1 como servidor DNS primário e, opcionalmente, use o endereço IP de outro controlador de domínio como servidor DNS secundário. Para obter mais informações, consulte Configurações de DNS recomendadas e opções alternativas .

Conectividade Híbrida

A seção a seguir detalha as práticas recomendadas relacionadas à conectividade híbrida.

Use o encaminhamento de entrada de DNS para resolver Google Cloud Nomes DNS locais

Os clientes em sua rede local talvez precisem resolver os nomes DNS dos recursos implantados em Google Cloud. Se você estender sua floresta ou implantar uma floresta de recursos emGoogle Cloud, use o encaminhamento de entrada de DNS para permitir que clientes locais procurem registros DNS para recursos implantados em Google Cloud. Para usar o encaminhamento de entrada, crie uma política de servidor DNS para alocar um endereço IP de encaminhador de entrada e tornar esse endereço acessível à rede local.

Se o domínio DNS usado em Google Cloud (por exemplo, cloud.example.com ) é um subdomínio do domínio DNS usado localmente (por exemplo, example.com ) e configure a delegação 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 procurar um nome DNS no Google Cloud-domínio hospedado a ser redirecionado para o endereço IP do encaminhador de entrada.

Se os domínios DNS usados ​​em Google Cloud e seu Active Directory local forem diferentes (por exemplo, cloud.example.com e corp.example.com ), configure o encaminhamento de DNS condicional em seus domínios locais e use o endereço IP do encaminhador de entrada como destino. Quando solicitado a resolver um nome DNS no Google Cloud-domínio hospedado, os controladores de domínio locais encaminharão a missão para o endereço IP do encaminhador de entrada.

Ao usar o encaminhamento de DNS de entrada, certifique-se de que seus firewalls estejam configurados adequadamente .

O encaminhamento de entrada de DNS não será necessário se você estender seu domínio existente para o Active Directory. Neste cenário, todos os registros DNS do domínio são replicados automaticamente entre Google Cloud e seu ambiente local e disponibilizado para pesquisa em ambos os ambientes.

Use o encaminhamento de saída de DNS para resolver nomes DNS locais de Google Cloud

Clientes em execução Google Cloud talvez precise ser capaz de resolver os nomes dos recursos implantados no local. Se você estender sua floresta ou implantar uma floresta de recursos em Google Cloude 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, certifique-se de que seus firewalls estejam configurados adequadamente .

O encaminhamento de saída de DNS não será necessário se você estender seu domínio existente para o Active Directory. Neste cenário, todos os registros DNS do domínio são replicados automaticamente entre Google Cloud e seu ambiente local e disponibilizado para pesquisa 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.

Google Cloud garante que o tráfego entre máquinas virtuais seja criptografado, portanto, é aceitável usar LDAP não criptografado em sua VPC. Se você conectar sua VPC a uma rede local, certifique-se de que o tráfego LDAP seja trocado apenas por canais confiáveis.

Se você usa o Cloud VPN para se conectar Google Cloud e sua rede local, o tráfego será criptografado automaticamente usando IPSec entreGoogle Cloud e seu endpoint 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 na conexão do Interconnect usando um dispositivo VPN do Google Cloud Marketplace .

Use autenticação seletiva e AES para relações de confiança florestais

Ao criar uma relação de confiança entre florestas do Active Directory, prefira relações de confiança de floresta a relações de confiança externas e aproveite os seguintes recursos para melhorar a segurança:

• Habilite a autenticação seletiva em relações de confiança de saída na floresta de recursos. A autenticação seletiva garante que os usuários da floresta organizacional não possam acessar recursos na floresta de recursos, a menos que tenham permissão explicitamente concedida.

• Habilite a aplicação do limite da floresta para a delegação completa do Kerberos em relações de confiança de entrada na floresta organizacional. Esse recurso ajuda a evitar ataques de escalonamento de privilégios, impedindo que recursos na floresta de recursos solicitem TGTs (Ticket Granting Tickets) de usuários na floresta organizacional.

• Habilite a opção O outro domínio suporta criptografia Kerberos AES ao criar relações de confiança. Esta opção garante que os tickets usados ​​para autenticação entre florestas sejam criptografados usando AES em vez do algoritmo RC4 menos seguro.

Segurança

A seção a seguir detalha as práticas recomendadas relacionadas à segurança.

Evitar Google Cloud segurança interferindo na segurança do Active Directory

O Active Directory oferece controle detalhado 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 às instâncias subjacentes Google Cloudprojeto, você deve considerar caminhos adicionais que possam permitir que um usuário acesse uma máquina:

• Um membro do projeto que recebeu a função de administrador de instância do Compute 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, pois 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 privilegiado do projeto pode injetar código malicioso em uma VM que é executada como nt authority\system na próxima vez que a máquina for reinicializada.

• Ao usar o console serial , um membro privilegiado do projeto também pode acessar o Windows Special Administration Console (SAC). O Windows considera os logons por meio do SAC como logons locais. O SAC pode, portanto, ser utilizado indevidamente para evitar políticas que negam logons via RDP, mas deixam de negar logons locais.

• Um membro privilegiado do projeto pode usar o SAC para emitir um comando crashdump , que pode fazer com que um dump de memória seja gravado no disco. Esse despejo de memória pode incluir informações e credenciais confidenciais.

• Ao montar o disco permanente em uma VM diferente ou usar snapshots, um membro privilegiado do projeto poderá acessar o conteúdo do disco, incluindo potencialmente despejos de memória, de máquinas nas quais o usuário, de outra forma, não teria permissão para fazer logon.

Ao usar o Microsoft AD gerenciado, você estará mais protegido contra esses caminhos de acesso adicionais por padrão. O serviço não permite que usuários privilegiados em 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 AD.

Para mitigar ainda mais esses riscos, certifique-se de que as permissões de IAM de projetos que contêm instâncias de VM ingressadas no domínio sejam gerenciadas com base em privilégios mínimos. Você pode reduzir ainda mais o risco do usuário de políticas de organização, políticas de grupo e VMs protegidas:

• Use uma política organizacional para desabilitar o acesso à porta serial.

• Aplique uma política de grupo que impeça a criação de contas de administrador local desativando o gerenciador de contas . Defina uma preferência de arquivos INI em sua política de grupo (Configuração do computador > Preferências > Configurações do Windows > Arquivos INI) para aplicar a seguinte configuração:

  • 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

• Aplique uma política de grupo que remova todas as contas 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 ao grupo Administradores e outros grupos confidenciais.

• Considere usar VMs blindadas em combinação com a criptografia de disco BitLocker para evitar que discos persistentes ou instantâneos sejam legíveis por usuários não autorizados.

Evite que a segurança do Active Directory interfira Google Cloud segurança

Em um domínio do Active Directory, as máquinas confiam nos controladores de domínio para lidar com a autenticação e autorização em seu nome. A menos que seja restrito por uma política de grupo, uma política de segurança local de uma máquina ou uma autenticação seletiva, um usuário que tenha comprovado sua identidade com sucesso em um dos controladores de domínio poderá fazer logon em qualquer máquina do domínio.

A capacidade dos usuários do Active Directory fazerem logon em qualquer máquina pode permitir que invasores executem movimentos laterais dentro de um domínio. Esses movimentos laterais podem levar a escalonamentos de privilégios se algumas instâncias de VM estiverem isentas de restrições de firewall ou de uso Google Cloud contas de serviço : 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 logon em uma máquina poderá, portanto, acessar essas credenciais de conta de serviço para obter acesso a qualquer Google Cloudrecursos aos quais a conta de serviço tem acesso.

Ao configurar o Microsoft AD gerenciado, o serviço cria um grupo para facilitar a permissão de usuários específicos para RDP em VMs ingressadas no domínio.

Para reduzir o risco de movimentos laterais, organize os usuários em níveis administrativos e use as políticas de grupo Negar acesso a este computador pela rede e Negar logon por meio de Serviços de Área de Trabalho Remota para restringir o acesso às suas VMs com base no nível de nível.

Numa topologia de floresta de recursos , aproveite ainda mais a autenticação seletiva para restringir ainda mais o conjunto de utilizadores de outras florestas que têm permissão para iniciar sessão nas suas VMs. Você pode simplificar o gerenciamento de permissões de autenticação seletiva alinhando Google Cloud e estruturas de recursos do Active Directory : se as unidades organizacionais do Active Directory forem mapeadas para projetos do Google Cloud, você poderá conceder aos usuários o direito de autenticação 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 de VM ou em um compartilhamento de arquivos e proteja-as usando uma ACL NTFS para que somente 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 sua 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 privilégios mínimos. Ao criar o projeto, esteja ciente de que algumas permissões podem ser herdadas das pastas pai . Para evitar a concessão inadvertida de acesso por meio de herança, considere criar o projeto fora de sua hierarquia de pastas usual.

Ao configurar políticas do IAM para o projeto, preste atenção especial à restrição do acesso às instâncias de 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 políticas do IAM para limitar o acesso ao projeto, proteja o projeto contra exclusão acidental .

Use VMs e projetos separados para gerenciar o Active Directory

Para gerenciar o Active Directory, você precisa poder usar 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 alvo atraente para roubo de credenciais ou keylogging.

Para minimizar o risco de um invasor obter 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 :

• Utilize políticas de grupo para garantir que apenas um subconjunto selecionado de utilizadores tenha o direito de iniciar sessão em VMs de gestão. Se você implementou a administração em camadas, esse grupo de usuários corresponde à Camada 0.

• Semelhante aos controladores de domínio, as VMs administrativas podem ser colocadas em risco se os membros do projeto criarem contas de administrador local , fizerem login por meio do console serial ou adulterarem 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 privilégios mínimos.

Se você planeja acessar VMs administrativas de uma rede local usando 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 seus firewalls locais. Se você usar uma VPC compartilhada , use permissões no nível da sub-rede para garantir que apenas administradores privilegiados tenham permissão para implantar instâncias de VM na sub-rede de gerenciamento. Esta prática ajuda a garantir que, se os firewalls locais aplicarem regras diferentes para VMs de gerenciamento e para outras VMs, os usuários não poderão escapar das regras de firewall colocando VMs que não sejam de gerenciamento na sub-rede de gerenciamento.

Além disso, considere restringir a política de grupo que gere restrições de início de sessão para VMs de gestão à sub-rede de gestão. Esta 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 na sub-rede/endereço IP).

Além de usar políticas do IAM para limitar o acesso ao projeto, proteja o projeto contra exclusão acidental .

Use regras de firewall para proteger controladores de domínio e servidores

Os controladores de domínio expõem vários serviços, incluindo LDAP, DNS, Kerberos e RPC. Dependendo dos seus casos de uso, as VMs implantadas em Google Cloud, bem como máquinas executadas no local, podem precisar de acesso a diferentes subconjuntos desses serviços para aproveitar as vantagens do Active Directory.

Ao usar o Microsoft AD gerenciado, 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 é automaticamente protegida com regras de firewall específicas do AD.

Para reduzir a superfície de ataque dos controladores de domínio e das suas VMs, utilize firewalls para proibir qualquer comunicação de rede que não seja estritamente necessária. Consulte nosso guia sobre como usar o Active Directory em firewalls para obter detalhes sobre quais configurações de firewall são necessárias para acessar o Active Directory de dentro da sua VPC ou de redes locais.

Organize recursos e usuários do Active Directory em camadas administrativas

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. Controladores de domínio e 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 das suas máquinas, utilize uma taxonomia de níveis. Embora o número certo de níveis dependa da sua configuração específica, você pode começar distinguindo entre três níveis:

• Camada 0 (altamente crítica) : esta camada inclui todas as máquinas que são críticas para a segurança da sua floresta do Active Directory. Depois que uma única máquina de nível 0 for comprometida, você deverá presumir que toda a sua floresta estará comprometida.

• Camada 1 (Crítica) : Esta camada inclui a maioria dos servidores em seu ambiente, incluindo servidores de aplicativos e servidores de banco de dados. Um servidor de camada 1 comprometido pode ter um impacto substancial nos negócios, mas não representa uma ameaça imediata para toda a floresta.

• Camada 2 (Normal) : Esta camada 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 impacto limitado nos negócios e na segurança geral.

Embora o impacto imediato de uma máquina de nível 2 comprometida possa parecer limitado, existe o risco de efeitos indiretos: quando um usuário com acesso administrativo a máquinas de nível 0 ou de nível 1 é atraído a 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, aumentando o impacto geral.

Para evitar esses efeitos indiretos, certifique-se de categorizar não apenas as máquinas, mas também as contas de usuário, e restringir a qual conjunto de máquinas esses usuários têm acesso:

• Camada 0 (altamente crítica) : usuários que têm acesso a máquinas de camada 0.

• Camada 1 (crítica) : usuários que têm acesso a máquinas de camada 1.

• Camada 2 (Normal) : Usuários que têm acesso a máquinas de camada 2.

Use a tabela a seguir como orientação sobre quais usuários devem ter acesso a quais recursos:

Consulte a documentação da Microsoft para obter mais detalhes e práticas recomendadas sobre a implementação de um modelo de camada administrativa no Active Directory.

Ao usar o modelo de camada administrativa na floresta do Active Directory, certifique-se de que a integridade dele não seja prejudicada por relações de confiança da floresta. Se a floresta confiável também aplicar um modelo de administração em camadas, use a autenticação seletiva para garantir que os usuários da floresta confiável só tenham permissão para acessar recursos dentro da mesma camada:

Se a floresta confiável não implementar administração em camadas, mapeie a floresta confiável para uma determinada camada e use a autenticação seletiva para garantir que os usuários da floresta confiável tenham permissão apenas para acessar recursos dessa camada específica.

Como usar o VPC Service Controls e o Private Google Access para hosts locais

As APIs gerenciadas do Microsoft AD permitem redefinir a senha do administrador e realizar outras operações confidenciais. Para implantações críticas de produção, recomendamos ativar o VPC Service Controls e usar o Private Google Access para hosts locais para aumentar a segurança.

Gerenciamento

A seção a seguir detalha as práticas recomendadas relacionadas ao gerenciamento do Active Directory.

Alinhar Google Cloud e estruturas de recursos do Active Directory

Ao implantar um novo domínio ou floresta do Active Directory emGoogle Cloud, será necessário definir uma estrutura de unidade organizacional (OU) para organizar seus recursos com seu domínio do Active Directory. Em vez de projetar uma estrutura totalmente nova ou aplicar a estrutura que você usa em seu ambiente local, crie uma estrutura de UO que esteja alinhada com sua Google Cloud hierarquia de recursos :

• Se você usar um modelo de administração em camadas , as UOs de nível superior deverão refletir suas camadas administrativas.

• Para cada camada, crie UOs para usuários e grupos. Se você planeja gerenciar um grande número de usuários e grupos, crie subunidades organizacionais conforme apropriado.

• Para cada nível, crie uma unidade organizacional Projects e subunidades organizacionais para cada projeto do Google Cloud que contenha recursos do Active Directory. Use a subunidade organizacional específica do projeto para gerenciar contas de computador, contas de serviço ou outros recursos do Active Directory que correspondam a Google Cloudrecursos do respectivo projeto. Certifique-se de que haja um mapeamento 1:1 entre UOs e projetos.

O diagrama a seguir mostra um exemplo de hierarquia que segue estes princípios:

Se o número de projetos que contêm recursos do Active Directory for moderado, você poderá criar uma estrutura de UO simples na UO Projects . Se você espera gerenciar um grande número de projetos e projetou seuGoogle Cloud hierarquia de recursos para usar vários níveis de pastas e considere refletir essa estrutura de pastas na UO Projects .

Alinhando a estrutura da UO do Active Directory e Google Cloud a hierarquia de recursos tem várias vantagens:

• Ao delegar permissões administrativas a um projeto do Google Cloud usando políticas do IAM, talvez você também precise conceder aos usuários do projeto determinados privilégios no Active Directory. Por exemplo, os administradores do Compute Engine podem precisar associar máquinas ao domínio em uma determinada unidade organizacional. Alinhar unidades organizacionais e projetos do Google Cloud permite conceder essas permissões no mesmo nível de granularidade no Active Directory como em Google Cloud.

• Se você planeja usar objetos de política de grupo (GPOs) para gerenciar computadores, então uma estrutura de UO que reflita o Google Cloud a hierarquia de recursos ajuda a garantir que os GPOs sejam aplicados de forma consistente a todas as VMs de um determinado projeto ou pasta.

• Se você usar uma confiança entre florestas com autenticação condicional, poderá usar as unidades organizacionais que correspondem aos projetos do Google Cloud para conceder a permissão Permitido para autenticar por projeto.

• Quando você exclui um projeto em Google Cloud, você pode simplesmente excluir a UO associada, reduzindo o risco de deixar recursos obsoletos em seu diretório.

Se você acha que sua estrutura OU precisa se desviar da estrutura do projeto, isso pode ser uma indicação de que a estrutura do seu projeto é muito fina ou muito grossa.

Use servidores do Google Time

A autenticação Kerberos depende de carimbos de data e hora como parte de seu protocolo. Para que a autenticação seja bem -sucedida, os relógios da máquina do cliente e do servidor devem sincronizar dentro de uma determinada margem. Por padrão, o Active Directory não permite mais de 5 minutos de diferença.

Em um ambiente local do Active Directory, a seguir, a configuração padrão para sincronizar o tempo:

• Máquinas com junto de domínio sincronizam seu tempo com um controlador de domínio.
• Os controladores de domínio sincronizam seu tempo com o emulador de PDC do domínio.
• Os emuladores de PDC de todos os domínios sincronizam seu tempo com o emulador de PDC do domínio da raiz florestal.

Nesta configuração, o emulador PDC do domínio da raiz florestal é a fonte final de tempo para o Active Directory, e é comum configurar esta máquina para usar um servidor NTP externo como fonte de tempo.

No mecanismo de computação, a configuração padrão para o Windows VMS é usar o servidor de metadados ( metadata.google.internal ) como servidor NTP, que por sua vez depende dos servidores NTP do Google para obter o tempo correto. A união de uma VM em um domínio do Active Directory não altera essa configuração padrão.

Mantenha a configuração padrão do mecanismo de computação, a menos que o emulador de PDC do seu domínio da raiz florestal seja implantado fora do Google Cloud.

Se o seu emulador de PDC for implantado fora de Google Cloud, configure -o para usar time.google.com como fonte NTP . Como alternativa, você pode restaurar o comportamento padrão do Active Directory de sincronizar o tempo com o emulador de PDC, reconfigurando as VMs do mecanismo de computação para usar a fonte NTP DOMHIER e configurar as regras do firewall para permitir o tráfego NTP de entrada (UDP/123) para seus controladores de domínio.

Consolidar e monitorar logs de auditoria

Quando você implanta o Active Directory em Google Cloud, a segurança da sua floresta do Active Directory e seus projetos de nuvem do Google estão vinculados a outro: atividade suspeita no Active Directory e Windows pode colocar em risco a segurança de alguns outros recursos da mesma maneira que a atividade suspeita em Google Cloud Pode colocar seu diretório ativo em risco .

Os logs de auditoria consistentes são uma ferramenta importante para identificar ameaças ou equivocação antecipadamente e permitir que você reconstrua e examine a atividade passada. O log de auditoria em nuvem permite capturar e analisar logs de atividades de administrador e logs de acesso a dados . Da mesma forma, você pode usar as regras de firewall e logs de fluxo VPC para analisar o tráfego de rede. Esses serviços de plataforma desconhecem quaisquer eventos relacionados à segurança que ocorrem no Active Directory, no entanto. Para estabelecer uma trilha de auditoria consistente que cubra eventos de auditoria relacionados à plataforma e eventos de auditoria relacionados ao Active Directory, instale o agente de log de nuvem nos controladores de domínio e máquinas de domínio para exportar logs de eventos de segurança do Windows para o log de nuvem.

Por padrão, o log de eventos de segurança do Windows pode não capturar todos os eventos necessários para seus fins de auditoria. Consulte as recomendações da Microsoft sobre como configurar políticas de auditoria e monitorar o Active Directory para obter sinais de compromisso para garantir que você capture todos os eventos de auditoria relevantes.

Ao lidar com um grande volume de eventos, é fácil perder eventos críticos. Para evitar a falta de eventos críticos, crie métricas baseadas em logs para eventos que podem ser particularmente críticos ou suspeitos e considere configurar alertas para notificá-lo quando a taxa de eventos mudar ou exceder os limites aceitáveis.

O que vem a seguir

• Descubra qual padrão para usar o Active Directory em um ambiente híbrido se adequa melhor à sua situação.

• Saiba como você pode configurar o Active Directory para VMs para ingressar automaticamente em um domínio .

• Experimente o outro Google Cloud recursos para você. Veja nossos tutoriais .