Este guia apresenta práticas recomendadas para executar o Active Directory no Google Cloud. O guia foca-se em práticas específicas Google Cloud ou de particular importância quando implementa o Active Directory no Google Cloud. Considere o guia complementar às práticas recomendadas gerais para proteger o Active Directory publicadas pela Microsoft.
Arquitetura
As secções seguintes detalham as práticas recomendadas relacionadas com a arquitetura.
Use o padrão de arquitetura que melhor se adapta aos seus requisitos
Para implementar o Active Directory no Google Cloud, primeiro tem de decidir que arquitetura de domínio e floresta usar. Se já usa o Active Directory, também tem de decidir se e como integrar os dois ambientes.
O design mais adequado à sua situação depende de vários fatores, incluindo o design da sua rede no local, a forma como os recursos no local e na nuvem vão interagir, bem como os seus requisitos de disponibilidade e autonomia administrativa.Google Cloud Consulte os nossos padrões de utilização do Active Directory num ambiente híbrido para ver como estes fatores têm de determinar o seu design.
Se quiser manter um limite de confiança entre o Google Cloud e o seu ambiente no local, considere implementar o padrão de floresta de recursos.Google Cloud Neste padrão, implementa uma floresta separada no Google Cloud e usa uma confiança de floresta unidirecional para integrar a floresta Google Cloud com a sua floresta do Active Directory nas instalações existente.
Testes e produção separados
Consoante a sua utilização do Active Directory, pode ser necessário fazer alterações frequentes no Active Directory durante o desenvolvimento e os testes de aplicações. Os programadores podem ter de conseguir criar e modificar contas do Active Directory, alterar as associações a grupos se as aplicações usarem grupos para processar a autorização, ou juntar e remover computadores.
Para evitar que o trabalho de desenvolvimento e testes afete as cargas de trabalho de produção ou prejudique a segurança da sua implementação, considere implementar um domínio ou uma floresta do Active Directory separados para desenvolvimento e testes.
Ter um domínio ou uma floresta de desenvolvimento e testes separados também lhe permite validar as alterações administrativas antes de as aplicar à produção. Exemplos de tais alterações incluem a experimentação com políticas de grupo, testes de scripts de automatização ou ações potencialmente arriscadas, como aumentar o nível funcional de uma floresta.
Configure a federação do Cloud ID, além de implementar o Active Directory no Google Cloud
A implementação do Active Directory no Google Cloud permite-lhe gerir VMs do Windows no Google Cloud, pode permitir que os utilizadores iniciem sessão em VMs do Windows com as respetivas contas de utilizador existentes e suporta aplicações que dependem do Kerberos, NTLM ou LDAP para autenticação.
No entanto, para usar a Google Cloud consola, a ferramenta de linha de comandos gcloud ou outras ferramentas da Google, tem de se autenticar com uma identidade Google. Google Cloud Por conseguinte, a implementação do Active Directory no Google Cloud não
substitui a federação do seu Active Directory existente com o
Google Cloud se pretender usar o Active Directory
como o seu sistema principal para gerir utilizadores.
Por exemplo, se implementar uma floresta separada no Google Cloud, pode configurar a federação com o seu Active Directory no local, conforme ilustrado no seguinte diagrama. Os utilizadores com contas no Active Directory no local podem, em seguida, usar ferramentas que requerem uma identidade Google, bem como as suas aplicações que dependem do Active Directory para autenticação.
Se, em alternativa, decidir expandir a sua floresta existente ou o domínio para Google Cloud, também tem a opção de usar controladores de domínio e servidores AD FS implementados em Google Cloud para configurar a federação.
A federação também lhe permite aplicar um ciclo de vida comum para as contas Google e as contas do Active Directory, para que, quando desativa uma conta de utilizador no Active Directory no local, o utilizador Google correspondente também seja suspenso.
Trabalhar em rede
A secção seguinte detalha as práticas recomendadas relacionadas com as redes.
Implemente o Active Directory numa rede de VPC partilhada
Para permitir que o Active Directory seja usado em vários projetos, implemente controladores de domínio numa rede VPC partilhada. A utilização de uma rede VPC partilhada tem várias vantagens:
Cada aplicação que possa exigir acesso ao Active Directory pode ser implementada num projeto separado. A utilização de projetos separados ajuda a isolar os recursos e permite-lhe gerir o acesso individualmente.
Pode usar um projeto dedicado para controladores de domínio do Active Directory, o que lhe permite um controlo detalhado sobre a que dos seus utilizadores podem aceder aos recursos Google Cloud relacionados.
As redes de VPC partilhadas permitem-lhe centralizar a gestão de endereços IP e a configuração da firewall, o que ajuda a garantir a consistência em vários projetos.
Como as VPCs são um recurso global, pode usar a mesma rede VPC partilhada 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.
Uma vez que as instâncias de VM sem endereços IP externos não têm acesso à Internet por predefinição, tem de tomar medidas adicionais para garantir que a ativação do Windows e as atualizações do Windows não são prejudicadas nos controladores de domínio.
Para suportar a ativação do Windows, ative o acesso privado à Google na sub-rede na qual planeia implementar controladores de domínio e certifique-se de que as instâncias de VM podem aceder a kms.windows.googlecloud.com. Isto permite que a ativação ocorra sem acesso direto à Internet.
Existem várias opções para suportar as atualizações do Windows:
Se tiver um servidor WSUS no local, pode configurar a conetividade híbrida e configurar os controladores de domínio para usar o servidor WSUS como a origem das atualizações.
Pode ativar o acesso à Internet através de uma gateway NAT implementando o Cloud NAT.
Se tiver configurado a conetividade híbrida, também pode encaminhar o tráfego de saída através de um servidor proxy ou um gateway NAT no local.
Reserve endereços IP estáticos para controladores de domínio antecipadamente
Uma vez que os controladores de domínio funcionam como servidores DNS, têm de lhes ser atribuído um endereço IP que não se altere. Para o conseguir, configure endereços IP internos estáticos para as VMs do controlador de domínio.
Quando reserva um endereço IP, o comportamento predefinido é que um endereço não usado é escolhido automaticamente. Para garantir que os endereços IP dos controladores de domínio são 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 este passo seja opcional, impede que o Active Directory emita mensagens de aviso a indicar que o endereço IP da máquina ainda pode ser atribuído dinamicamente.
Implemente controladores de domínio em várias zonas
Para aumentar a disponibilidade, implemente, pelo menos, dois controladores de domínio e distribua-os por várias zonas. Uma vez que as sub-redes e os endereços IP não estão associados a uma zona, pode implementar todos os controladores de domínio numa única sub-rede.
Se planear implementar cargas de trabalho em várias regiões, considere implementar controladores de domínio em cada região relevante. Uma vez que as sub-redes são um recurso regional, a implementação numa região adicional requer uma sub-rede adicional.
Crie um site por região
Quando um cliente tenta localizar um controlador de domínio, procura primeiro um controlador de domínio no site do Active Directory que corresponde ao endereço IP do cliente. Se não estiver disponível nenhum controlador de domínio neste site, o cliente continua e tenta localizar um controlador de domínio num site diferente.
Pode tirar partido deste comportamento criando um site separado para cada região na qual implementa controladores de domínio ou clientes de domínio. Os clientes vão, então, preferir 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 tiver clientes em regiões que não têm um controlador de domínio, pode influenciar os controladores de domínio que estes clientes escolhem ajustando os custos das associações de sites para refletir a proximidade geográfica das regiões e ativando a definição Experimentar o site mais próximo seguinte.
A utilização de vários sites influencia o comportamento de replicação entre os controladores de domínio. Uma desvantagem da utilização de vários sites pode ser o facto de a replicação entre sites ocorrer com menos frequência do que a replicação no mesmo site.
No entanto, não pode criar sites do Active Directory no Managed Microsoft AD, porque o Managed Microsoft AD não suporta a funcionalidade de sites e serviços do Active Directory.
Use zonas de encaminhamento privado do Cloud DNS
Quando cria uma nova instância de VM no Compute Engine, o sistema operativo é pré-configurado para usar um servidor DNS predefinido que fornece acesso ao DNS interno e ao DNS público.
Antes de poder associar um computador a um domínio do Active Directory, tem de garantir que o computador consegue resolver os registos DNS geridos pelo Active Directory. O servidor DNS predefinido que o Compute Engine configura para uma instância de VM fornece acesso ao DNS interno e ao DNS público, mas não vai conseguir resolver nomes DNS geridos pelo Active Directory.
Crie uma zona de encaminhamento de DNS privado no Cloud DNS para permitir que os clientes resolvam registos de DNS geridos pelo Active Directory. Configure a zona para encaminhar consultas que correspondam ao seu domínio do Active Directory para os controladores de domínio.
A utilização de uma zona de encaminhamento DNS privada tem várias vantagens em relação à configuração dos clientes para utilizarem diretamente os controladores de domínio do Active Directory como servidores DNS:
Não precisa de ajustar a configuração de rede das instâncias de VM. Isto simplifica o processo de criação de novas VMs.
Quando promove ou despromove um controlador de domínio, só precisa de atualizar a configuração da zona de encaminhamento de DNS privado e não precisa de modificar nenhuma definição do cliente.
As instâncias de VM continuam a ter acesso ao DNS interno.
Todos os registos de DNS que não correspondam ao seu domínio do Active Directory são processados pelo Cloud DNS, o que reduz a carga nos seus controladores de domínio.
Se usar vários domínios, crie uma zona de encaminhamento de DNS privado separada para cada domínio do Active Directory.
As zonas de encaminhamento privado do Cloud DNS estão no âmbito de uma única VPC. Se usar vários VPCs ligados através de peering, pode expor as zonas de encaminhamento privado a outros VPCs configurando o peering de DNS.
Continua a ter de configurar manualmente as definições de DNS nos controladores de domínio. Use
127.0.0.1 como o servidor DNS principal e, opcionalmente, use o endereço IP de outro controlador de domínio como o servidor DNS secundário. Para mais informações, consulte o artigo
Definições de DNS recomendadas e opções alternativas.
Conetividade híbrida
A secção seguinte detalha as práticas recomendadas relacionadas com a conetividade híbrida.
Use o encaminhamento de entrada de DNS para resolver Google Cloud nomes DNS a partir de local
Os clientes na sua rede no local podem ter de conseguir resolver os nomes DNS dos recursos implementados no Google Cloud. Se estender a sua floresta ou implementar uma floresta de recursos no Google Cloud, use o encaminhamento de entrada de DNS para permitir que os clientes no local procurem registos de DNS para recursos implementados no Google Cloud. Para usar o encaminhamento de entrada, crie uma política de servidor DNS para atribuir um endereço IP de encaminhador de entrada e tornar este endereço acessível à rede no local.
Se o domínio 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 registo NS no domínio no local que aponte para o endereço IP do encaminhador de entrada. O registo NS faz com que os clientes que tentam procurar um nome DNS no domínio alojado em Google Cloudsejam redirecionados para o endereço IP do encaminhador de entrada.
Se os domínios DNS usados no Google Cloud e no seu Active Directory no local forem diferentes (por exemplo, cloud.example.com e corp.example.com), configure o encaminhamento DNS condicional nos seus domínios no local e use o endereço IP do encaminhador de entrada como destino. Quando
solicitado para resolver um nome DNS no domínio alojado no Google Cloud,
os controladores de domínio no local encaminham o pedido para o endereço IP
do encaminhador de entrada.
Quando usar o encaminhamento DNS de entrada, certifique-se de que as firewalls estão configuradas adequadamente.
O encaminhamento de entrada de DNS não é necessário se estender o seu domínio existente ao Active Directory. Neste cenário, todos os registos DNS do domínio são replicados automaticamente no ambiente local e no ambiente da nuvem, e ficam disponíveis para consulta em ambos os ambientes. Google Cloud
Use o encaminhamento de saída de DNS para resolver nomes de DNS no local a partir de Google Cloud
Os clientes executados no Google Cloud podem ter de conseguir resolver os nomes dos recursos implementados no local. Se estender a sua floresta ou implementar uma floresta de recursos no Google Cloud, crie uma zona de encaminhamento privado no Cloud DNS para encaminhar consultas DNS para os seus domínios no local para os seus servidores DNS no local.
Quando usar o encaminhamento de DNS de saída, certifique-se de que as firewalls estão configuradas adequadamente.
O encaminhamento de saída de DNS não é necessário se estender o seu domínio existente ao Active Directory. Neste cenário, todos os registos DNS do domínio são replicados automaticamente no Google Cloud e no seu ambiente no local, e ficam disponíveis para consulta em ambos os ambientes.
Use túneis VPN para proteger o tráfego LDAP
O Active Directory usa extensivamente o protocolo LDAP. Ao contrário da maioria dos outros protocolos usados pelo Active Directory, o LDAP não é encriptado por predefinição.
Google Cloud garante que o tráfego entre máquinas virtuais está encriptado, pelo que a utilização do LDAP não encriptado na sua VPC é aceitável. Se ligar a sua VPC a uma rede no local, certifique-se de que o tráfego LDAP só é trocado através de canais fidedignos.
Se usar a Cloud VPN para se ligar Google Cloud à sua rede no local, o tráfego é encriptado automaticamente através do IPSec entre o Google Cloud e o ponto final da VPN no local.Google Cloud
O Cloud Interconnect e o Partner Interconnect não oferecem encriptação. Para garantir uma comunicação segura, estabeleça um túnel VPN através da ligação do Interconnect com um dispositivo VPN do Google Cloud Marketplace.
Use a autenticação seletiva e o AES para relações de confiança entre florestas
Ao criar uma relação de confiança entre florestas do Active Directory, prefira confianças de florestas a confianças externas e tire partido das seguintes funcionalidades para melhorar a segurança:
Ative a autenticação seletiva em relações de confiança de saída na floresta de recursos. A autenticação seletiva garante que os utilizadores da floresta organizacional não podem aceder a recursos na floresta de recursos, a menos que lhes seja concedida explicitamente autorização.
Ative 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. Esta funcionalidade ajuda a evitar ataques de escalada de privilégios ao não permitir que os recursos na floresta de recursos peçam pedidos para obter pedidos (TGTs) a utilizadores na floresta organizacional.
Ative a opção O outro domínio suporta a encriptação AES do Kerberos quando criar relações de confiança. Esta opção garante que os pedidos de autenticação entre florestas são encriptados através do AES em vez do algoritmo RC4 menos seguro.
Segurança
A secção seguinte detalha as práticas recomendadas relacionadas com a segurança.
Evite Google Cloud que a segurança interfira na segurança do Active Directory
O Active Directory oferece-lhe um controlo detalhado sobre os utilizadores que têm autorização para aceder a recursos específicos. Quando as máquinas são implementadas como instâncias de VM no Compute Engine e os utilizadores têm acesso ao Google Cloud projeto subjacente, tem de considerar caminhos adicionais que possam permitir que um utilizador aceda a uma máquina:
Um membro do projeto ao qual foi atribuída a função de administrador da instância de computação num Google Cloud projeto pode usar a funcionalidade de reposição de palavra-passe para criar contas de administrador local. As contas de administrador local representam uma ameaça à segurança do seu domínio do Active Directory, uma vez que podem ser usadas para prejudicar as políticas de grupo ou para instalar software malicioso que possa capturar credenciais de domínio de outros utilizadores com sessão iniciada.
Ao adicionar um script de arranque, um membro privilegiado do projeto pode injetar código malicioso numa VM que é executado como
nt authority\systemna próxima vez que a máquina for reiniciada.Ao usar a consola série, um membro privilegiado do projeto também pode aceder à consola de administração especial (SAC) do Windows. O Windows considera os inícios de sessão através do SAC como inícios de sessão locais. Por conseguinte, o SAC pode ser usado indevidamente para evitar políticas que negam inícios de sessão através do RDP, mas não negam inícios de sessão locais.
Um membro privilegiado do projeto pode usar o SAC para emitir um comando
crashdump, que pode fazer com que um despejo de memória seja escrito no disco. Este despejo de memória pode incluir informações confidenciais e credenciais.Ao montar o disco persistente numa VM diferente ou usar instantâneos, um membro do projeto com privilégios pode aceder aos conteúdos do disco, potencialmente incluindo despejos de memória, de máquinas às quais o utilizador não teria permissão para iniciar sessão.
Quando usa o Microsoft AD gerido, está mais bem protegido contra estes caminhos de acesso adicionais por predefinição. O serviço não permite que os utilizadores privilegiados no seu projeto reponham a palavra-passe do administrador do domínio, executem scripts de arranque ou acedam à consola série nas VMs do controlador de domínio do AD.
Para mitigar ainda mais estes riscos, certifique-se de que as autorizações da IAM dos projetos que contêm instâncias de VMs associadas a um domínio são geridas com base no princípio do menor privilégio. Pode reduzir ainda mais o risco através da utilização de políticas da organização, políticas de grupo e VMs protegidas:
Use uma política organizacional para desativar o acesso à porta de série.
Aplique uma política de grupo que impeça a criação de contas de administrador local desativando o gestor de contas. Defina uma preferência de ficheiros INI na sua política de grupo (Configuração do computador > Preferências > Definições do Windows > Ficheiros INI) para aplicar a seguinte definição:
- Ação: atualizar
- Caminho do ficheiro:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - Nome da secçã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 VMs. Use a funcionalidade Utilizadores e grupos locais (Configuração do computador > Preferências > Definições do painel de controlo > Utilizadores e grupos locais) para remover a associação ao grupo Administradores e a outros grupos confidenciais.
Considere usar VMs protegidas em combinação com a encriptação de disco do BitLocker para evitar que os discos persistentes ou as capturas de ecrã sejam legíveis por utilizadores não autorizados.
Evite que a segurança do Active Directory interfira com a Google Cloud segurança
Num domínio do Active Directory, as máquinas confiam nos controladores de domínio para processar a autenticação e a autorização em seu nome. 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 utilizador que tenha comprovado com êxito a sua identidade a um dos controladores de domínio tem autorização para iniciar sessão em qualquer máquina no domínio.
A capacidade de os utilizadores do Active Directory iniciarem sessão em qualquer máquina pode permitir que os atacantes realizem movimentos laterais num domínio. Estes movimentos laterais podem levar a escalamentos de privilégios se algumas instâncias de VM estiverem isentas de restrições de firewall ou usarem contas de serviço: as credenciais de uma conta de serviço estão acessíveis a todos os processos e utilizadores numa instância de VM. Google Cloud Qualquer utilizador que possa usar o Active Directory para iniciar sessão numa máquina pode, por conseguinte, aceder a estas credenciais da conta de serviço para aceder a quaisquer recursos aos quais a conta de serviço tenha acesso. Google Cloud
Quando configura o Microsoft AD gerido, o serviço cria um grupo para facilitar a concessão a utilizadores específicos da capacidade de RDP em VMs associadas ao domínio.
Para reduzir o risco de movimentos laterais, organize os utilizadores em níveis administrativos e use as políticas de grupo Negar acesso a este computador a partir da rede e Negar início de sessão através dos Serviços de ambiente de trabalho remoto para restringir o acesso às suas VMs com base no nível.
Numa topologia de floresta de recursos, tire partido adicional da autenticação seletiva para restringir ainda mais o conjunto de utilizadores de outras florestas que têm autorização para iniciar sessão nas suas VMs. Pode simplificar a gestão das autorizações de autenticação seletiva alinhando as Google Cloud estruturas de recursos do Active Directory: se as unidades organizacionais do Active Directory forem mapeadas para Google Cloud projetos, pode conceder aos utilizadores o direito de autenticação num nível que corresponda a um Google Cloud projeto.
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, guarde-as no disco local da instância de VM ou numa partilha de ficheiros e proteja-as com uma ACL NTFS para que apenas os utilizadores do Active Directory autorizados 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 a comprometer 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 Google Cloud projeto separado para implementar controladores de domínio e conceder acesso a este projeto com base no princípio do menor privilégio. Ao criar o projeto, tenha em atenção que algumas autorizações podem ser herdadas de pastas principais. Para evitar conceder inadvertidamente acesso através da herança, considere criar o projeto fora da hierarquia de pastas habitual.
Ao configurar as políticas de IAM para o projeto, preste especial atenção à restrição do acesso a instâncias de VM, aos discos persistentes que contêm a base de dados ntds.dit, bem como a quaisquer localizações de armazenamento que possam conter cópias de segurança.
Além de usar políticas de IAM para limitar o acesso ao projeto, proteja o projeto contra a eliminação acidental.
Use VMs e projetos separados para gerir o Active Directory
Para gerir o Active Directory, tem de poder usar ferramentas como Utilizadores e computadores do Active Directory ou o Centro de Administração do Active Directory. Estas ferramentas requerem que inicie sessão com uma conta de domínio privilegiada, o que torna a máquina em que executa estas ferramentas um alvo atrativo para o roubo de credenciais ou o registo de teclas.
Para minimizar o risco de um atacante obter credenciais de domínio privilegiadas, use instâncias de VM dedicadas para a administração de domínio e processe essas VMs de gestão como estações de trabalho de acesso privilegiado:
Use políticas de grupo para garantir que apenas um subconjunto selecionado de utilizadores tem o direito de iniciar sessão em VMs de gestão. Se implementou a administração hierárquica, este grupo de utilizadores corresponde ao Nível 0.
À semelhança dos controladores de domínio, as VMs administrativas podem ser colocadas em risco se os membros do projeto criarem contas de administrador local, iniciarem sessão através da consola série ou adulterarem os respetivos discos persistentes. Para limitar o risco de acesso não autorizado, use umGoogle Cloud projeto separado para VMs administrativas e conceda acesso a este projeto com base no princípio do menor privilégio.
Se planear aceder a VMs administrativas a partir de uma rede no local através da conetividade híbrida, implemente VMs administrativas numa sub-rede de VPC dedicada. Uma sub-rede dedicada a VMs de gestão permite-lhe distinguir melhor entre VMs administrativas e outras VMs ao configurar as suas firewalls no local. Se usar uma VPC partilhada, use autorizações ao nível da sub-rede para garantir que apenas os administradores privilegiados podem implementar instâncias de VMs na sub-rede de gestão. Esta prática ajuda a garantir que, se as firewalls no local aplicarem regras diferentes às VMs de gestão do que a outras VMs, os utilizadores não podem evitar as regras de firewall colocando VMs que não sejam de gestão na sub-rede de gestão.
Além disso, pondere restringir a política de grupo que gere as restrições de início de sessão para VMs de gestão à sub-rede de gestão. Esta prática aplica o alinhamento entre as restrições de início de sessão (com base numa política de grupo) e as regras da firewall (com base na sub-rede/endereço IP).
Além de usar políticas de IAM para limitar o acesso ao projeto, proteja o projeto contra a eliminaçã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. Consoante os seus exemplos de utilização, as VMs implementadas no Google Cloud, bem como as máquinas executadas no local, podem precisar de acesso a diferentes subconjuntos destes serviços para tirar partido do Active Directory.
Quando usa o Microsoft AD gerido, os controladores de domínio do AD são implementados num projeto de inquilino dedicado. A rede que aloja os controladores de domínio do AD está protegida automaticamente com regras de firewall específicas do AD reforçadas.
Para reduzir a superfície de vetores de ataque dos controladores de domínio e das suas VMs, use firewalls para não permitir qualquer comunicação de rede que não seja estritamente necessária. Consulte o nosso guia sobre a utilização do Active Directory em firewalls para ver detalhes sobre as configurações de firewall necessárias para aceder ao Active Directory a partir da sua VPC ou de redes no local.
Organize os recursos e os utilizadores do Active Directory em níveis administrativos
Algumas máquinas numa 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 que são particularmente críticas e, por isso, particularmente sensíveis a potenciais ataques.
Para identificar a criticidade de cada uma das suas máquinas, use uma taxonomia de níveis. Embora o número certo de níveis dependa da sua configuração específica, pode começar por distinguir entre três níveis:
Nível 0 (altamente crítico): este nível inclui todas as máquinas que são críticas para a segurança da sua floresta do Active Directory. Quando uma máquina de nível 0 é comprometida, tem de assumir que toda a floresta está comprometida.
Nível 1 (crítico): este nível inclui a maioria dos servidores no seu ambiente, incluindo servidores de aplicações e servidores de bases de dados. Um servidor de nível 1 comprometido pode ter um impacto empresarial substancial, mas não representa uma ameaça imediata para toda a floresta.
Nível 2 (normal): este nível inclui estações de trabalho ou outras máquinas de uso geral. Espera-se que uma violação de uma máquina de nível 2 tenha um impacto limitado na empresa e na segurança geral.
Embora o impacto imediato de uma máquina de nível 2 comprometida possa parecer limitado, existe um risco de efeitos indiretos: quando um utilizador com acesso administrativo a máquinas de nível 0 ou nível 1 é atraído para iniciar sessão numa máquina de nível 2 comprometida, pode ser vítima de um registador de teclas ou outras formas de roubo de credenciais. As credenciais capturadas podem ser usadas para atacar máquinas de níveis superiores, o que faz com que o impacto geral aumente.
Para evitar estes efeitos indiretos, certifique-se de que não só categoriza as máquinas, mas também as contas de utilizador, e restringe o conjunto de máquinas a que estes utilizadores têm acesso:
Nível 0 (altamente crítico): utilizadores que têm acesso a máquinas de nível 0.
Nível 1 (crítico): utilizadores com acesso a máquinas de nível 1.
Nível 2 (normal): utilizadores que têm acesso a máquinas de nível 2.
Use a tabela seguinte como orientação para saber que utilizadores devem ter acesso a que 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 | Utilizador limitado | Bloqueado | Bloqueado |
| Administradores do servidor de gestão | 0 | Utilizador limitado | Administrador | Bloqueado | Bloqueado |
| Administradores do servidor | 1 | Utilizador limitado | Bloqueado | Administrador | Bloqueado |
| Administradores de estações de trabalho VDI | 2 | Utilizador limitado | Bloqueado | Bloqueado | Administrador |
| Utilizadores de estações de trabalho VDI | 2 | Utilizador limitado | Bloqueado | Bloqueado | Utilizador limitado |
Consulte a documentação da Microsoft para ver mais detalhes e práticas recomendadas sobre a implementação de um modelo de nível administrativo no Active Directory.
Quando usa o modelo de nível administrativo na sua floresta do Active Directory, certifique-se de que a integridade do mesmo não é comprometida por relações de fidedignidade da floresta. Se a floresta fidedigna também aplicar um modelo de administração hierárquico, use a autenticação seletiva para garantir que os utilizadores da floresta fidedigna só têm autorização para aceder a recursos na mesma hierarquia:
Se a floresta fidedigna não implementar a administração hierárquica, mapeie a floresta fidedigna para um determinado nível e use a autenticação seletiva para garantir que os utilizadores da floresta fidedigna só têm autorização para aceder aos recursos desse nível específico.
Usar os VPC Service Controls e o acesso privado à Google para anfitriões no local
As APIs Microsoft AD geridas permitem repor a palavra-passe do administrador e realizar outras operações confidenciais. Para implementações de produção críticas, recomendamos que ative os VPC Service Controls e use o acesso privado à Google para hosts no local para aumentar a segurança.
Gestão
A secção seguinte detalha as práticas recomendadas relacionadas com a gestão do Active Directory.
Alinhe Google Cloud as estruturas de recursos do Active Directory
Quando implementa um novo domínio ou floresta do Active Directory no Google Cloud, tem de definir uma estrutura de unidade organizacional (UO) para organizar os seus recursos com o domínio do Active Directory. Em vez de conceber uma estrutura totalmente nova ou aplicar a estrutura que usa no seu ambiente no local, crie uma estrutura de UO alinhada com a sua Google Cloud hierarquia de recursos:
Se usar um modelo de administração hierárquico, as UOs de nível superior têm de refletir os seus níveis administrativos.
Para cada nível, crie UOs para utilizadores e grupos. Se planeia gerir um grande número de utilizadores e grupos, crie UOs secundárias conforme adequado.
Para cada nível, crie uma
ProjectsUO e crie sub-UOs para cada Google Cloud projeto que contenha recursos do Active Directory. Use a subunidade organizacional específica do projeto para gerir contas de computador, contas de serviço ou outros recursos do Active Directory que correspondam aos recursos do projeto respetivo. Google CloudCertifique-se de que existe um mapeamento de 1:1 entre as UOs e os projetos.
O diagrama seguinte 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,
pode criar uma estrutura de UO simples na UO Projects. Se espera gerir um grande número de projetos e tiver estruturado a sua hierarquia de recursos para usar vários níveis de pastas, considere refletir esta estrutura de pastas abaixo da UO.Google Cloud Projects
O alinhamento da estrutura da UO do Active Directory e da hierarquia de Google Cloud recursos tem várias vantagens:
Quando delega autorizações administrativas a um Google Cloud projeto através de políticas de IAM, também pode ter de conceder aos utilizadores do projeto determinados privilégios no Active Directory. Por exemplo, os administradores do Compute Engine podem ter de conseguir associar máquinas ao domínio numa determinada UO. O alinhamento das UOs e dos Google Cloud projetos permite-lhe conceder essas autorizações no mesmo nível de detalhe no Active Directory que no Google Cloud.
Se planeia usar objetos de política de grupo (GPOs) para gerir computadores, uma estrutura de UO que reflita a Google Cloud hierarquia de recursos ajuda a garantir que os GPOs são aplicados de forma consistente a todas as VMs de um determinado projeto ou pasta.
Se usar uma confiança entre florestas com autenticação condicional, pode usar as UOs que correspondem aos Google Cloud projetos para conceder a autorização Allowed to authenticate (Autorizado a autenticar) por projeto.
Quando elimina um projeto no Google Cloud, pode simplesmente eliminar a UO associada, reduzindo o risco de deixar recursos desatualizados no seu diretório.
Se considerar que a estrutura da UO tem de divergir da estrutura do projeto, isto pode indicar que a estrutura do projeto é demasiado detalhada ou demasiado genérica.
Use servidores de tempo da Google
A autenticação Kerberos baseia-se em indicações de tempo como parte do respetivo protocolo. Para que a autenticação seja bem-sucedida, os relógios do cliente e do servidor têm de ser sincronizados dentro de uma determinada margem. Por predefinição, o Active Directory não permite uma diferença superior a 5 minutos.
Num ambiente do Active Directory no local, a seguinte é a configuração predefinida para sincronizar a hora:
- As máquinas associadas ao domínio sincronizam a respetiva hora com um controlador de domínio.
- Os controladores de domínio sincronizam a respetiva hora com o emulador de PDC do respetivo domínio.
- Os emuladores de PDC de todos os domínios sincronizam a respetiva hora com o emulador de PDC do domínio raiz da floresta.
Nesta configuração, o emulador de PDC do domínio raiz da floresta é a fonte de tempo final para o Active Directory, e é comum configurar esta máquina para usar um servidor NTP externo como fonte de tempo.
No Compute Engine, a configuração predefinida para VMs Windows é usar o servidor de metadados
(metadata.google.internal) como servidor NTP, que, por sua vez, depende dos servidores NTP da Google para obter a hora correta. A associação de uma VM a um domínio do Active Directory não altera esta configuração predefinida.
Mantenha a configuração predefinida do Compute Engine, a menos que o emulador de PDC do domínio raiz da floresta esteja implementado fora de Google Cloud.
Se o emulador de PDC estiver implementado fora de Google Cloud, configure-o para usar time.google.com como origem de NTP.
Em alternativa, pode restaurar o comportamento predefinido do Active Directory de sincronização da hora com o emulador de PDC reconfigurando as VMs do Compute Engine para usar a DOMHIERorigem NTP e configurando regras de firewall para permitir o tráfego NTP de entrada (UDP/123) para os controladores de domínio.
Consolide e monitorize os registos de auditoria
Quando implementa o Active Directory no Google Cloud, a segurança da sua floresta do Active Directory e dos seus projetos do Google Cloud estão interligadas: a atividade suspeita no Active Directory e no Windows pode pôr em perigo a segurança de alguns outros recursos da mesma forma que a atividade suspeita no Google Cloud pode pôr o seu Active Directory em risco.
Os registos de auditoria consistentes são uma ferramenta importante para identificar ameaças ou configurações incorretas antecipadamente e permitem-lhe reconstruir e examinar a atividade anterior. O Cloud Audit Logging permite-lhe capturar e analisar registos de atividade do administrador e registos de acesso aos dados. Da mesma forma, pode usar o registo de regras de firewall e os registos de fluxo de VPC para analisar o tráfego de rede. No entanto, estes serviços de plataforma não têm conhecimento de eventos relacionados com a segurança que ocorram no Active Directory. Para estabelecer uma trilha de auditoria consistente que abranja eventos de auditoria relacionados com a plataforma e eventos de auditoria relacionados com o Active Directory, instale o agente do Cloud Logging em controladores de domínio e máquinas associadas ao domínio para exportar registos de eventos de segurança do Windows para o Cloud Logging.
Por predefinição, o registo de eventos de segurança do Windows pode não capturar todos os eventos de que precisa para fins de auditoria. Consulte as recomendações da Microsoft sobre a configuração de políticas de auditoria e a monitorização do Active Directory para detetar sinais de comprometimento para garantir que capta todos os eventos de auditoria relevantes.
Quando lida com um grande volume de eventos, é fácil perder eventos críticos. Para evitar perder eventos críticos, crie métricas baseadas em registos para eventos que possam ser particularmente críticos ou suspeitos e considere configurar alertas para receber notificações quando a taxa de eventos mudar ou exceder os limites aceitáveis.
O que se segue?
Descubra que padrão de utilização do Active Directory num ambiente híbrido se adequa melhor à sua situação.
Saiba como pode configurar o Active Directory para que as VMs se juntem automaticamente a um domínio.
Experimente outras Google Cloud funcionalidades. Consulte os nossos tutoriais.