Este documento discute os requisitos a serem considerados ao implantar o Active Directory no Google Cloud e ajuda você a escolher a arquitetura ideal.
Ao federar o Active Directory com o Cloud Identity ou o Google Workspace (consulte Padrões de autenticação de usuários da força de trabalho em um ambiente híbrido), você pode permitir que os usuários dos domínios atuais do Active Directory façam a autenticação e acessem recursos no Google Cloud. Também é possível implantar o Active Directory no Google Cloud se planeja usar o Active Directory para gerenciar servidores Windows no Google Cloud ou se depende de protocolos que não são compatíveis com o Google Cloud.
Antes de implantar o Active Directory no Google Cloud, você precisa decidir qual arquitetura de domínio e floresta usar e como integrá-la à sua floresta atual do Active Directory.
Como avaliar os requisitos
O Active Directory é compatível com várias arquiteturas de floresta e domínio. Em um ambiente híbrido, uma opção é estender um único domínio do Active Directory em vários ambientes. Como alternativa, é possível usar domínios ou florestas separados e conectá-los por meio de relações de confiança. A melhor arquitetura é a que atende a seus requisitos.
Para escolher a melhor arquitetura, observe estes fatores:
- Alinhamento com as zonas de segurança atuais
- Interação entre recursos no local e no Google Cloud
- Autonomia administrativa
- Disponibilidade
Discutiremos esses fatores nas seções a seguir.
Alinhamento com as zonas de segurança atuais
Comece analisando o design de sua rede local.
Em seu ambiente local, você talvez tenha segmentado sua rede em várias zonas de segurança, usando, por exemplo, VLANs ou sub-redes separadas. Em uma rede segmentada por zonas de segurança, a comunicação dentro de uma zona de segurança é irrestrita ou está sujeita apenas a políticas básicas de auditoria e firewall. Por outro lado, qualquer comunicação entre zonas de segurança está sujeita a políticas rígidas de firewall, auditoria ou inspeção de tráfego.
O objetivo das zonas de segurança, porém, é mais abrangente do que apenas restringir e auditar a comunicação em rede. Elas precisam implementar limites de confiança.
Limites de confiança
Cada máquina em uma rede executa vários processos. Esses processos podem se comunicar localmente usando a comunicação entre processos e podem se comunicar entre máquinas usando protocolos como HTTP. Nesta rede de comunicação, os pares nem sempre confiam uns nos outros da mesma forma. Por exemplo, é possível que os processos confiem mais nos processos que são executados na mesma máquina do que nos que são executados em outras máquinas. Além disso, algumas máquinas podem ser consideradas mais confiáveis do que outras.
Um limite de confiança implica discernir entre as partes da comunicação e confiar mais em umas que em outras.
Os limites de confiança são essenciais para conter o impacto de um ataque. Os ataques raramente terminam quando um único sistema é comprometido, seja esse sistema um único processo, seja uma máquina inteira. Em vez disso, um invasor provavelmente tentará estender o ataque a outros sistemas. Como os sistemas em um limite de confiança não fazem distinção entre si, é mais fácil propagar um ataque dentro desse limite de confiança do que atacar sistemas alheios a esse.
Quando um sistema em um limite de confiança é comprometido, deve-se considerar que todos os outros sistemas nesse limite também foram afetados. Essa suposição pode ajudar você a identificar limites de confiança ou validar se um determinado limite de sistema representa, na realidade, um limite de confiança, por exemplo:
Suponhamos que um invasor tenha alcançado o nível mais alto de acesso ao objetivo A (por exemplo, acesso de administrador ou de raiz a uma máquina ou a um aplicativo). Se esse invasor puder aproveitar esses privilégios para conseguir o mesmo nível de acesso ao objetivo B, então A e B estarão, por definição, dentro do mesmo limite de confiança. Caso contrário, há um limite de confiança entre A e B.
Ao restringir a comunicação de rede, as zonas de segurança podem ajudar a implementar limites de confiança. No entanto, para que uma zona de segurança se torne um verdadeiro limite de confiança, as cargas de trabalho em cada lado do limite precisam discriminar entre solicitações originadas da mesma zona de segurança e solicitações originadas em zonas de segurança diferentes, com uma inspeção mais minuciosa destas últimas.
Modelo de confiança zero
O modelo de confiança zero é o modelo de rede preferencial no Google Cloud.
Se um único sistema está comprometido em um limite de confiança, presume-se que todos os sistemas nesse limite também estão. Essa suposição sugere que limites de confiança menores são melhores. Quanto menor o limite de confiança, menos sistemas são comprometidos e mais limites um invasor precisa transpor para que um ataque se propague.
O modelo de confiança zero leva a uma conclusão lógica: cada máquina na rede é tratada como uma zona de segurança e um limite de confiança exclusivos. Toda a comunicação entre máquinas está sujeita aos mesmos níveis de inspeção e aplicação de firewall, e todas as solicitações de rede são tratadas como originárias de uma fonte não confiável.
No nível da rede, é possível implementar um modelo de confiança zero usando regras de firewall para restringir o tráfego, e os registros de fluxo de VPC e a geração de registros de regras de firewall para analisá-lo. No nível do aplicativo, garanta que todos os aplicativos tratem de forma consistente e segura a autenticação, a autorização e a auditoria.
Limites de confiança no Active Directory
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. Depois que um usuário tiver comprovado a identidade para um dos controladores de domínio, poderá fazer login, por padrão, em todas as máquinas do mesmo domínio. Todos os direitos de acesso que o usuário recebe pelo controlador de domínio (na forma de privilégios e associações a grupos) se aplicam a muitas máquinas do domínio.
Com as políticas de grupo, é possível impedir que usuários acessem determinadas máquinas ou restringir os direitos deles. No entanto, quando uma máquina é comprometida, um invasor pode conseguir roubar senhas, hashes de senha ou tokens do Kerberos de outros usuários do domínio conectados à mesma máquina. O invasor pode aproveitar essas credenciais para propagar o ataque a outros domínios na floresta.
Considerando esses fatores, é melhor presumir que todas as máquinas em uma floresta estão em um limite de segurança confiável.
Em comparação com os limites de domínio, que têm a finalidade de controlar a replicação e conceder autonomia administrativa a diferentes partes da organização, os limites da floresta podem fornecer um isolamento mais sólido. As florestas podem funcionar como um limite de confiança (os 3 links estão em inglês).
Como alinhar florestas e zonas de segurança do Active Directory
Presumir que a floresta é o limite de confiança influencia no design das zonas de segurança. Se uma floresta se estender por duas zonas de segurança, será mais fácil para um invasor ultrapassar o limite entre essas zonas de segurança. Como resultado, as duas zonas de segurança efetivamente se tornam uma e formam um único limite de confiança.
Em um modelo de confiança zero, cada máquina em uma rede pode ser considerada como uma zona de segurança separada. A implantação do Active Directory em uma rede desse tipo coloca esse conceito em xeque e amplia o limite de segurança efetivo para incluir todos os computadores da floresta do Active Directory.
Para que uma zona de segurança sirva como um limite de confiança, garanta que toda a floresta do Active Directory esteja na zona de segurança.
Impacto ao estender o Active Directory para o Google Cloud
Ao planejar uma implantação no Google Cloud que requer o Active Directory, é preciso decidir entre duas opções para alinhar a implantação com as zonas de segurança existentes:
Estender uma zona de segurança existente para o Google Cloud. É possível estender uma ou mais zonas de segurança atuais para o Google Cloud provisionando uma VPC compartilhada no Google Cloud e conectando-a à zona atual usando o Cloud VPN ou o Cloud Interconnect.
Os recursos implantados no local e no Google Cloud que compartilham uma zona comum também podem compartilhar uma floresta comum do Active Directory. Portanto, não é necessário implantar uma floresta separada no Google Cloud.
Como exemplo, considere uma rede atual que tenha uma rede de perímetro de desenvolvimento e uma rede de perímetro de produção como zonas de segurança, com uma floresta separada do Active Directory em cada zona de segurança. Se você estender as zonas de segurança para o Google Cloud, todas as implantações no Google Cloud também farão parte de uma dessas duas zonas de segurança e poderão usar as mesmas florestas do Active Directory.
Introduzir novas zonas de segurança. A extensão de uma zona de segurança pode não ser aplicável porque você não quer expandir ainda mais uma zona ou porque os requisitos de segurança das zonas de segurança existentes não correspondem aos requisitos das implantações do Google Cloud. Você pode tratar o Google Cloud como zonas de segurança adicionais.
Por exemplo, considere um ambiente local que tenha uma rede de perímetro, mas não faça distinção entre cargas de trabalho de desenvolvimento e de produção. Para separar essas cargas de trabalho no Google Cloud, crie duas VPCs compartilhadas e considere-as como novas zonas de segurança. Em seguida, você implanta duas florestas adicionais do Active Directory no Google Cloud, uma para cada zona de segurança. Se necessário, estabeleça relações de confiança entre florestas para ativar a autenticação entre zonas de segurança.
Interação entre recursos no local e no Google Cloud
O segundo fator a ser considerado ao estender seu Active Directory para o Google Cloud é a interação de usuários e recursos entre o que se encontra on-premises e o Google Cloud. Dependendo do seu caso de uso, essa interação pode variar de leve a pesada.
Interação leve
Se o único propósito de usar o Active Directory no Google Cloud for gerenciar uma frota de servidores do Windows e permitir que os administradores façam login nesses servidores, o nível de interação entre os ambientes será leve:
- O conjunto de funcionários que interagem com recursos no Google Cloud é limitado à equipe administrativa.
- Os aplicativos implantados no Google Cloud podem não interagir com aplicativos on-premises ou fazer isso sem depender de instalações de autenticação do Windows, como Kerberos e NTLM.
Em um cenário leve, considere integrar seus ambientes on-premises e do Google Cloud de uma das duas maneiras a seguir:
Duas florestas do Active Directory separadas: é possível isolar os dois ambientes usando duas florestas do Active Directory separadas que não compartilham uma relação de confiança. Para permitir que os administradores se autentiquem, você mantém um conjunto separado de contas de usuário na floresta do Google Cloud.
A manutenção de um conjunto duplicado de contas de usuários aumenta o esforço administrativo e apresenta o risco de se esquecer de desativar contas quando os funcionários deixam a empresa. A melhor abordagem é provisionar essas contas automaticamente.
Se as contas de usuário no Active Directory local forem aprovisionadas por um sistema de informações de recursos humanos (RHIS), você poderá usar um mecanismo semelhante para provisionar e gerenciar contas de usuário na floresta do Google Cloud. Como alternativa, você pode usar ferramentas como o Microsoft Identity Manager para sincronizar contas de usuário entre ambientes.
Duas florestas do Active Directory com confiança entre si: usando duas florestas do Active Directory e conectando-as a uma confiança entre florestas, você evita a necessidade de manter contas duplicadas. Os administradores usam a mesma conta de usuário para se autenticar em ambos os ambientes. Embora o nível de isolamento entre ambientes possa ser considerado mais baixo, o uso de florestas separadas permite manter um limite de confiança entre o ambiente local e o Google Cloud.
Interação moderada
Seu caso de uso pode ser mais complexo. Por exemplo:
- Os administradores que fazem login em servidores Windows implantados no Google Cloud podem precisar acessar compartilhamentos de arquivos hospedados no local.
- Os aplicativos podem usar o Kerberos ou o NTLM para autenticar e se comunicar entre os limites do ambiente.
- Convém permitir que os funcionários usem a Autenticação Integrada do Windows (IWA) para fazer a autenticação em web apps implantados no Google Cloud.
Em um cenário moderado, operar duas florestas separadas do Active Directory pode ser muito limitante: não é possível usar o Kerberos para autenticação nas duas florestas e usar a autenticação de passagem NTLM exige que você mantenha as contas de usuário e senhas sincronizadas.
Nesse caso, recomendamos o uso de duas florestas do Active Directory com uma confiança entre florestas.
Interação pesada
Certas cargas de trabalho, incluindo implantações de infraestrutura de área de trabalho virtual (VDI, na sigla em inglês), podem exigir muita interação entre recursos on-premises e implantados no Google Cloud. Quando os recursos entre ambientes estão estreitamente associados, a tentativa de manter um limite de confiança entre ambientes pode não ser prática. O uso de duas florestas com confiança entre florestas pode ser muito limitador.
Nesse caso, recomendamos usar uma única floresta do Active Directory e compartilhá-la entre ambientes.
Autonomia administrativa
O terceiro fator a ser considerado ao estender seu Active Directory para o Google Cloud é a autonomia administrativa.
Se você planeja distribuir cargas de trabalho no local e no Google Cloud, as cargas de trabalho que serão executadas no Google Cloud podem ser muito diferentes das que você mantém no local. Talvez você até decida que equipes diferentes podem gerenciar os dois ambientes.
Separar responsabilidades entre diferentes equipes requer conceder a cada equipe alguma autonomia administrativa. No Active Directory, é possível conceder às equipes a autoridade para gerenciar recursos usando a administração delegada ou domínios separados.
A administração delegada é uma maneira leve de delegar tarefas administrativas e conceder autonomia às equipes. A manutenção de um único domínio também pode ajudar a garantir a consistência entre ambientes e equipes.
No entanto, não é possível delegar todos os recursos administrativos, e compartilhar um único domínio pode aumentar a sobrecarga administrativa de coordenação entre equipes. Nesse caso, recomendamos o uso de domínios separados.
Disponibilidade
O último fator a considerar ao estender seu Active Directory para o Google Cloud é a disponibilidade. Para cada domínio em uma floresta do Active Directory, o controlador de domínio atua como o provedor de identidade para os usuários nesse domínio.
Ao usar o Kerberos para autenticação, um usuário precisa interagir com um controlador de domínio do Active Directory em vários pontos, como estes:
- Autenticação inicial (recebimento de um tíquete de concessão de tíquete)
- Reautenticação periódica (atualização de um tíquete de concessão de tíquete)
- Autenticação com um recurso (recebimento de um tíquete de serviço)
Executar a autenticação inicial e a reautenticação periódica exige a comunicação apenas com um único controlador de domínio (um controlador do domínio do qual o usuário é membro).
Ao autenticar com um recurso, pode ser necessário interagir com vários controladores de domínio, dependendo do domínio em que o recurso se encontra:
- Se o recurso estiver localizado no mesmo domínio do usuário, ele poderá usar o mesmo controlador de domínio (ou um controlador diferente do mesmo domínio) para concluir o processo de autenticação.
- Se o recurso estiver localizado em um domínio diferente, mas houver uma relação de confiança direta com o domínio do usuário, o usuário precisará interagir com pelo menos dois controladores de domínio: um no domínio de recursos e outro no domínio do usuário.
- Se o recurso e o usuário fizerem parte de domínios diferentes e houver apenas uma relação de confiança indireta entre esses domínios, uma autenticação bem-sucedida exigirá a comunicação com os controladores de domínio de cada domínio no caminho de confiança.
Localizar usuários e recursos em domínios ou florestas diferentes do Active Directory pode limitar a disponibilidade geral. Como a autenticação requer interação com vários domínios, uma falha temporária de um domínio pode afetar a disponibilidade de recursos em outros domínios.
Considerando o possível impacto da topologia do Active Directory sobre a disponibilidade, recomendamos alinhar sua topologia do Active Directory com sua estratégia híbrida.
Cargas de trabalho distribuídas
Para aproveitar os recursos exclusivos de cada ambiente de computação, use uma abordagem híbrida para distribuir cargas de trabalho nesses ambientes. Nessa configuração, as cargas de trabalho implantadas no Google Cloud provavelmente dependerão de outras infraestruturas ou aplicativos em execução no local, o que torna a conectividade híbrida altamente disponível um requisito fundamental.
Se você implantar uma floresta ou um domínio separado do Active Directory no Google Cloud e usar uma confiança para conectá-lo ao Active Directory on-premises, adicione outra dependência entre o Google Cloud e o ambiente local. Essa dependência tem efeito mínimo sobre a disponibilidade.
Cargas de trabalho redundantes
Se você usa o Google Cloud para garantir a continuidade dos negócios, suas cargas de trabalho no Google Cloud refletem algumas das cargas de trabalho no ambiente on-premises. Essa configuração permite que um ambiente assuma o papel do outro ambiente se ocorrer uma falha. Então você precisa analisar todas as dependências entre esses ambientes.
Se você implantar uma floresta ou um domínio do Active Directory separado no Google Cloud e usar uma confiança para conectá-lo ao Active Directory on-premises, poderá criar uma dependência que prejudique a finalidade da configuração. Se o Active Directory on-premises ficar indisponível, todas as cargas de trabalho implantadas no Google Cloud que dependem de autenticação entre domínios ou florestas também poderão ficar indisponíveis.
Se seu objetivo é garantir a continuidade dos negócios, use florestas do Active Directory separadas em cada ambiente que não estejam conectadas umas às outras. Como alternativa, você pode estender um domínio do Active Directory existente para o Google Cloud. Ao implantar mais controladores de domínio no Google Cloud e replicar o conteúdo do diretório entre os ambientes, você garante que os ambientes operem isoladamente.
Padrões de Integração
Depois de avaliar seus requisitos, use a árvore de decisão a seguir para ajudar a identificar uma floresta e uma arquitetura de domínio adequadas.
Nas seções a seguir, descrevemos cada padrão.
Florestas sincronizadas
No padrão de florestas sincronizadas, você implanta uma floresta separada do Active Directory no Google Cloud. Você usa essa floresta para gerenciar todos os recursos implantados no Google Cloud, bem como as contas de usuário necessárias para gerenciar esses recursos.
Em vez de criar uma confiança entre a nova floresta e uma floresta local atual, sincronize as contas. Se você usar um RHIS como sistema principal para gerenciar contas de usuário, poderá configurá-lo para provisionar contas de usuário na floresta do Active Directory hospedada no Google Cloud. Como alternativa, você pode usar ferramentas como o Microsoft Identity Manager para sincronizar contas de usuário entre ambientes.
Considere usar o padrão de florestas sincronizadas se uma ou mais das situações a seguir se aplicarem:
- O uso pretendido do Google Cloud se encaixa em um dos padrões de implantação redundantes. Você também quer evitar dependências de tempo de execução entre o ambiente local e o Google Cloud.
- Você quer manter um limite de confiança entre o ambiente do Active Directory on-premises e o ambiente do Active Directory hospedado pelo Google Cloud, seja como uma medida de defesa profunda ou porque confia em um ambiente mais do que no outro.
- Você espera que não haja interação entre os recursos gerenciados pelo Active Directory no local e no Google Cloud.
- O número de contas de usuário necessárias no ambiente do Active Directory hospedado no Google Cloud é pequeno.
Vantagens:
- O padrão de florestas sincronizadas permite manter um isolamento sólido entre os dois ambientes do Active Directory. Um invasor que comprometer um ambiente pode ganhar pouca vantagem em atacar o segundo ambiente.
- Não é necessário configurar a conectividade híbrida entre suas redes locais e do Google Cloud para operar o Active Directory.
- O Active Directory hospedado pelo Google Cloud não é afetado por uma interrupção do Active Directory on-premises. O padrão é adequado para casos de uso de continuidade de negócios ou outros cenários que exigem alta disponibilidade.
- Você pode conceder um alto nível de autonomia às equipes que gerenciam a floresta do Active Directory hospedada pelo Google Cloud.
- Esse padrão é compatível com o Serviço gerenciado para o Microsoft Active Directory.
Práticas recomendadas:
- Não sincronize senhas de contas de usuários entre as duas florestas do Active Directory. Isso prejudica o isolamento entre os ambientes.
- Não confie na autenticação de passagem, porque ela requer a sincronização de senhas de contas de usuários.
- Certifique-se de que, quando um funcionário sair da empresa, as contas dele nos dois ambientes do Active Directory sejam desativadas ou removidas.
Floresta de recursos
No padrão da floresta de recursos, você implanta uma floresta separada do Active Directory no Google Cloud. Você usa essa floresta para gerenciar todos os recursos implantados no Google Cloud, bem como um conjunto mínimo de contas de usuário administrativas necessárias para gerenciar a floresta. Ao estabelecer uma confiança na floresta do Active Directory on-premises, você permite que os usuários da floresta existente autentiquem e acessem recursos gerenciados pela floresta do Active Directory hospedada pelo Google Cloud.
Se necessário, é possível transformar esse padrão em uma topologia de hub/spoke com a floresta atual do Active Directory no centro, conectada a muitas florestas de recursos.
Considere o uso do padrão de floresta de recursos se um ou mais dos itens a seguir se aplicarem:
- O uso pretendido do Google Cloud se encaixa em um dos padrões de implantação distribuídos. Uma dependência entre o ambiente local e o Google Cloud é aceitável.
- Você quer manter um limite de confiança entre o ambiente do Active Directory on-premises e o ambiente do Active Directory hospedado pelo Google Cloud, seja como uma medida de defesa profunda ou porque considera um ambiente mais confiável que o outro.
- Você espera um nível moderado de interação entre os recursos gerenciados pelo Active Directory on-premises e no Google Cloud.
- Você tem um grande número de usuários que precisam acessar recursos implantados no Google Cloud, por exemplo, para aplicativos da Web que usam o IWA para autenticação.
Vantagens:
- O padrão de floresta de recursos permite manter um limite de confiança entre os dois ambientes do Active Directory. Dependendo de como a relação de confiança é configurada, um invasor que comprometa um ambiente pode ganhar pouco ou nenhum acesso ao outro ambiente.
- Esse padrão é totalmente compatível com o Microsoft AD gerenciado.
- Você pode conceder um alto nível de autonomia às equipes que gerenciam a floresta do Active Directory hospedada pelo Google Cloud.
Práticas recomendadas:
- Conecte as duas florestas do Active Directory usando uma confiança unidirecional para que o Active Directory hospedado pelo Google Cloud confie no Active Directory atual, mas não o contrário.
- Use a autenticação seletiva para limitar os recursos no Active Directory hospedado pelo Google Cloud que os usuários do Active Directory on-premises podem acessar.
- Use conexões redundantes do Dedicated Interconnect, do Partner Interconnect ou do Cloud VPN para garantir uma conectividade de rede altamente disponível entre a rede local e o Google Cloud.
Domínio estendido
No padrão de domínio estendido, você estende um ou mais domínios existentes do Active Directory para o Google Cloud. Para cada domínio, você implanta um ou mais controladores de domínio no Google Cloud, o que faz com que todos os dados do domínio e o catálogo global sejam replicados e disponibilizados no Google Cloud. Ao usar sites do Active Directory separados para as sub-redes locais e do Google Cloud, você garante que os clientes se comuniquem com os controladores de domínio mais próximos.
Considere o uso do padrão de domínio estendido se uma ou mais das situações a seguir se aplicarem:
- O uso pretendido do Google Cloud se encaixa em um dos padrões de implantação redundantes. Você também quer evitar dependências de tempo de execução entre o ambiente local e o Google Cloud.
- Você espera uma interação intensa entre os recursos gerenciados do Active Directory no local e no Google Cloud.
- Você quer acelerar a autenticação de aplicativos que dependem do LDAP para autenticação.
Vantagens:
- O Active Directory hospedado pelo Google Cloud não é afetado por uma interrupção do Active Directory on-premises. O padrão é adequado para casos de uso de continuidade de negócios ou outros cenários que exigem alta disponibilidade.
- Você pode limitar a comunicação entre sua rede local e o Google Cloud. Isso pode economizar largura de banda e melhorar a latência.
- Todo o conteúdo do catálogo global é replicado para o Active Directory e pode ser acessado com eficiência a partir de recursos hospedados no Google Cloud.
Práticas recomendadas:
- Se você replicar todos os domínios, a comunicação entre sua rede local e a rede do Google Cloud será limitada à replicação do Active Directory entre os controladores de domínio. Se você replicar apenas um subconjunto de domínios da floresta, os servidores associados ao domínio em execução no Google Cloud ainda poderão se comunicar com os controladores de domínio de domínios não replicados. Verifique se as regras de firewall que se aplicam à comunicação entre o local e o Google Cloud consideram todos os casos relevantes.
- Lembre-se de que a replicação entre sites acontece apenas em determinados intervalos. Portanto, as atualizações realizadas em um controlador de domínio local só aparecem no Google Cloud após um atraso (e vice-versa).
- Considere usar controladores de domínio somente leitura (RODCs) para manter uma cópia somente leitura dos dados do domínio no Google Cloud. No entanto, lembre-se de que há uma troca relacionada ao armazenamento em cache de senhas de usuário. Se você permitir que os RODCs armazenem senhas em cache e preencham o cache de senha, os recursos implantados no Google Cloud poderão não ser afetados por uma interrupção dos controladores de domínio locais. No entanto, os benefícios de segurança de usar um RODC em um controlador de domínio regular são limitados. Se você desativar o armazenamento em cache de senhas, um RODC comprometido poderá representar um risco limitado para o restante do Active Directory, mas você perderá o benefício do Google Cloud não afetado por uma interrupção dos controladores de domínio locais.
Floresta estendida
No padrão de floresta estendida, você implanta um novo domínio do Active Directory no Google Cloud, mas o integra à floresta existente. Você usa o novo domínio para gerenciar todos os recursos implantados no Google Cloud e manter um conjunto mínimo de contas de usuário administrativas para gerenciar o domínio.
Ao estender as relações de confiança implícitas para outros domínios da floresta, você permite que os usuários existentes de outros domínios autentiquem e acessem recursos gerenciados pelo domínio do Active Directory hospedado no Google Cloud.
Considere o uso do padrão de floresta estendida se um ou mais dos itens a seguir se aplicarem:
- O uso pretendido do Google Cloud se encaixa em um dos padrões de implantação distribuídos. Uma dependência entre o ambiente local e o Google Cloud é aceitável.
- Os recursos que você planeja implantar no Google Cloud exigem uma configuração ou estrutura de domínio diferente do que seus domínios atuais oferecem. Você também pode querer conceder um alto nível de economia administrativa às equipes que administram o domínio hospedado no Google Cloud.
- Você espera uma interação moderada a intensa entre os recursos gerenciados pelo Active Directory on-premises e no Google Cloud.
- Você tem muitos usuários que precisam acessar recursos implantados no Google Cloud, por exemplo, para aplicativos da Web que usam o IWA para autenticação.
Vantagens:
- Todo o conteúdo do catálogo global será replicado para o Active Directory e poderá ser acessado com eficiência a partir de recursos hospedados no Google Cloud.
- O tráfego de replicação entre sua rede local e o Google Cloud é limitado à replicação de catálogo global. Isso pode ajudar a limitar o consumo geral de largura de banda.
- Você pode conceder um alto nível de autonomia às equipes que gerenciam o domínio do Active Directory hospedado no Google Cloud.
Práticas recomendadas:
- Use conexões redundantes de Interconexão dedicada, Interconexão por parceiro ou Cloud VPN para garantir conectividade de rede altamente disponível entre sua rede local e o Google Cloud.
Floresta de recursos com domínio estendido
O padrão de floresta de recursos com domínio estendido é uma extensão do padrão de floresta de recursos. Com o padrão de floresta de recursos, você mantém um limite de confiança entre ambientes e fornece autonomia administrativa. Uma limitação da floresta de recursos é que a disponibilidade geral dela depende da disponibilidade de controladores de domínio locais e de conectividade de rede confiável com seu data center local.
É possível superar essas limitações combinando o padrão de floresta de recursos com o padrão de domínio estendido. Ao replicar o domínio, suas contas de usuário estão localizadas no Google Cloud, e você pode garantir que os usuários possam se autenticar em recursos hospedados no Google Cloud mesmo quando os controladores de domínio locais não estiverem disponíveis ou a conectividade de rede for perdida.
Considere o uso da floresta de recursos com padrão de domínio estendido, se um ou mais dos itens a seguir se aplicarem:
- Você quer manter um limite de confiança entre a floresta principal do Active Directory e a floresta de recursos.
- Você quer evitar que os controladores de domínio locais ou a perda de conectividade de rede com o ambiente local afetem as cargas de trabalho hospedadas no Google Cloud.
- Você espera uma interação moderada entre os recursos gerenciados pelo Active Directory on-premises e no Google Cloud.
- Você tem muitos usuários de um único domínio do Active Directory que precisam acessar recursos implantados no Google Cloud, por exemplo, para aplicativos da Web que usam o IWA para autenticação.
Vantagens:
- Os recursos hospedados pelo Google Cloud não são afetados por uma interrupção do Active Directory on-premises. O padrão é adequado para casos de uso de continuidade de negócios ou outros cenários que exigem alta disponibilidade.
- O padrão permite manter um limite de confiança entre as duas florestas do Active Directory. Dependendo de como a relação de confiança é configurada, um invasor que comprometa um ambiente pode ganhar pouco ou nenhum acesso ao outro ambiente.
- A comunicação entre sua rede local e a rede do Google Cloud é limitada à replicação do Active Directory entre controladores de domínio. É possível implementar regras de firewall para proibir todas as outras comunicações, fortalecendo o isolamento entre os ambientes.
- Você pode conceder um alto nível de autonomia às equipes que gerenciam a floresta do Active Directory hospedada pelo Google Cloud.
- Use o Microsoft AD gerenciado para a floresta de recursos.
Práticas recomendadas:
- Implante controladores de domínio para o domínio estendido em um projeto separado do Google Cloud e a VPC para separar esses componentes dos componentes da floresta de recursos.
- Use o peering de VPC para conectar a VPC à VPC compartilhada ou à VPC usada pela floresta de recursos e configure firewalls para restringir a comunicação com a autenticação de usuário do Kerberos e a criação de confiança da floresta.
- Conecte as duas florestas do Active Directory usando uma confiança unidirecional para que o Active Directory hospedado pelo Google Cloud confie na floresta atual do Active Directory, mas não o contrário.
- Use a autenticação seletiva para limitar os recursos na floresta de recursos que usuários de outras florestas podem acessar.
- Lembre-se de que a replicação entre sites acontece apenas em determinados intervalos. Portanto, as atualizações realizadas em um controlador de domínio local aparecem no Google Cloud somente após um atraso (e vice-versa).
- Considere o uso de RODCs para o domínio estendido, mas certifique-se de permitir o armazenamento em cache de senhas para preservar as vantagens de disponibilidade em comparação com o padrão de floresta de recursos.
A seguir
- Saiba mais sobre o Microsoft AD gerenciado.
- Consulte as práticas recomendadas para implantar uma floresta de recursos do Active Directory no Google Cloud.
- Saiba como implantar um ambiente do Active Directory tolerante a falhas no Google Cloud.
- Leia nossas práticas recomendadas sobre design de VPC.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.