Padrões para usar o Active Directory num ambiente híbrido

Este documento aborda os requisitos a ter em conta quando implementa o Active Directory e ajuda a escolher a arquitetura certa. Google Cloud

Ao federar o Active Directory com o Cloud ID ou o Google Workspace (consulte os padrões para autenticar utilizadores da força de trabalho num ambiente híbrido), pode permitir que os utilizadores dos seus domínios do Active Directory existentes se autentiquem e acedam a recursos no Google Cloud. Também pode implementar o Active Directory Google Cloud se planear usar o Active Directory Google Cloud para gerir servidores Windows ou se depender de protocolos quenão são suportados Google Cloud.

Antes de implementar o Active Directory no Google Cloud, tem de decidir que arquitetura de domínio e floresta usar e como fazer a integração com a sua floresta do Active Directory existente.

A avaliar os requisitos

O Active Directory suporta uma variedade de arquiteturas de domínios e florestas. Num ambiente híbrido, uma opção é expandir um único domínio do Active Directory em vários ambientes. Em alternativa, pode usar domínios ou florestas separados e associá-los através de relações de confiança. A melhor arquitetura depende dos seus requisitos.

Para escolher a melhor arquitetura, tenha em atenção estes fatores:

  • Alinhamento com zonas de segurança existentes
  • Interação entre recursos no local e Google Cloud
  • Autonomia administrativa
  • Disponibilidade

As secções seguintes abordam estes fatores.

Alinhamento com zonas de segurança existentes

Comece por rever o design da sua rede no local.

No seu ambiente no local, pode ter segmentado a sua rede em várias zonas de segurança, por exemplo, através da utilização de VLANs ou sub-redes separadas. Numa rede segmentada em zonas de segurança, a comunicação numa zona de segurança é ilimitada ou está sujeita apenas a políticas de auditoria e firewall simples. Por outro lado, qualquer comunicação entre zonas de segurança está sujeita a políticas rigorosas de firewall, auditoria ou inspeção de tráfego.

No entanto, o objetivo das zonas de segurança é mais abrangente do que apenas restringir e auditar a comunicação de rede. As zonas de segurança devem implementar limites de confiança.

Limites de confiança

Cada máquina numa rede executa vários processos. Estes processos podem comunicar entre si localmente através da comunicação entre processos e podem comunicar entre máquinas através de protocolos como o HTTP. Nesta rede de comunicação, os pares nem sempre confiam uns nos outros na mesma medida. Por exemplo, os processos podem confiar mais nos processos que estão a ser executados na mesma máquina do que nos processos que estão a ser executados noutras máquinas. Além disso, algumas máquinas podem ser consideradas mais fidedignas do que outras.

Um limite de confiança aplica a discriminação entre as partes de comunicação, confiando num conjunto de partes de comunicação mais do que noutro conjunto de partes.

Os limites de confiança são essenciais para conter o impacto de um ataque. Os ataques raramente terminam quando um único sistema é comprometido, quer esse sistema seja um único processo ou uma máquina inteira. Em alternativa, é provável que um atacante tente estender o ataque a outros sistemas. Uma vez que os sistemas num limite de confiança não discriminam entre si, propagar um ataque dentro desse limite de confiança é mais fácil do que atacar sistemas através de um limite de confiança.

Quando um sistema num limite de confiança é comprometido, todos os outros sistemas nesse limite de confiança têm de ser considerados comprometidos. Esta suposição pode ajudar a identificar limites de confiança ou validar se um determinado limite do sistema é um limite de confiança, por exemplo:

Suponhamos que um atacante alcançou o nível de acesso mais elevado ao alvo A (por exemplo, acesso de administrador ou acesso root a uma máquina ou aplicação). Se puderem tirar partido destes privilégios para obter o mesmo nível de acesso ao destino B, então, por definição, A e B estão dentro do mesmo limite de confiança. Caso contrário, existe 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 de cada lado do limite têm de discriminar entre pedidos que se originam na mesma zona de segurança e pedidos que se originam em zonas de segurança diferentes, e analisar estes últimos mais atentamente.

Modelo de confiança zero

O modelo de confiança zero é o modelo de rede preferido no Google Cloud.

Dado um único sistema comprometido num limite de confiança, pode assumir que todos os sistemas nesse limite estão comprometidos. Esta suposição sugere que os limites de confiança mais pequenos são melhores. Quanto menor for o limite de confiança, menos sistemas são comprometidos e mais limites um atacante tem de ultrapassar para que um ataque se propague.

O modelo de confiança zero leva esta ideia à sua conclusão lógica: cada máquina na rede é tratada como uma zona de segurança e um limite de confiança únicos. Toda a comunicação entre máquinas está sujeita à mesma análise e firewalls, e todos os pedidos de rede são tratados como tendo origem numa fonte não fidedigna.

Ao nível da rede, pode implementar um modelo de confiança zero através de regras de firewall para restringir o tráfego e registos de fluxo de VPC e registo de regras de firewall para analisar o tráfego. Ao nível da aplicação, tem de garantir que todas as aplicações processam a autenticação, a autorização e a auditoria de forma consistente e segura.

Limites de fidedignidade no Active Directory

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. Depois de um utilizador provar a sua identidade a um dos controladores de domínio, pode iniciar sessão por predefinição em todas as máquinas do mesmo domínio. Todos os direitos de acesso concedidos ao utilizador pelo controlador de domínio (sob a forma de privilégios e associações a grupos) aplicam-se a muitas máquinas do domínio.

Ao usar políticas de grupo, pode impedir que os utilizadores acedam a determinadas máquinas ou restringir os respetivos direitos em determinadas máquinas. No entanto, depois de uma máquina ser comprometida, um atacante pode conseguir roubar palavras-passe, hashes de palavras-passe ou tokens Kerberos de outros utilizadores do domínio com sessão iniciada na mesma máquina. O atacante pode, em seguida, tirar partido destas credenciais para propagar o ataque a outros domínios na floresta.

Tendo em conta estes fatores, é melhor assumir que todas as máquinas numa floresta estão num limite de segurança de confiança.

Em comparação com os limites de domínio, cujo objetivo é controlar a replicação e conceder autonomia administrativa a diferentes partes da organização, os limites da floresta podem oferecer um isolamento mais forte. As florestas podem servir como limite de confiança.

Alinhar florestas do Active Directory e zonas de segurança

Considerar a floresta como o limite de confiança influencia a conceção das zonas de segurança. Se uma floresta se estender por duas zonas de segurança, é mais fácil para um atacante limpar o limite entre estas zonas de segurança. Como resultado, as duas zonas de segurança tornam-se efetivamente uma e formam um único limite de confiança.

Num modelo de confiança zero, cada máquina numa rede pode ser considerada uma zona de segurança separada. A implementação do Active Directory numa rede deste tipo prejudica este conceito e alarga o limite de segurança eficaz para incluir todas as máquinas da floresta do Active Directory.

Para que uma zona de segurança sirva como limite de confiança, tem de garantir que toda a floresta do Active Directory está na zona de segurança.

Impacto na extensão do Active Directory para Google Cloud

Quando planeia uma implementação para o Google Cloud que requer o Active Directory, tem de decidir entre duas opções para alinhar a implementação com as suas zonas de segurança existentes:

  • Estender uma zona de segurança existente para Google Cloud. Pode estender uma ou mais das suas zonas de segurança existentes Google Cloud através do aprovisionamento da VPC partilhada no Google Cloud e da ligação à zona existente através da Cloud VPN ou do Cloud Interconnect.

    Os recursos implementados no local e na Google Cloud nuvem que partilham uma zona comum também podem partilhar uma floresta do Active Directory comum, pelo que não é necessário implementar uma floresta separada para Google Cloud.

    Por exemplo, considere uma rede existente 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 do Active Directory separada em cada zona de segurança. Se expandir as zonas de segurança para Google Cloud, todas as implementações em Google Cloud também fazem parte de uma destas duas zonas de segurança e podem usar as mesmas florestas do Active Directory.

    Estender uma zona de segurança a Google Cloud

  • Apresente novas zonas de segurança. A extensão de uma zona de segurança pode não ser aplicável, quer porque não quer expandir mais uma zona, quer porque os requisitos de segurança das suas zonas de segurança existentes não correspondem aos requisitos das suas implementações do Google Cloud. Pode tratá-las Google Cloud como zonas de segurança adicionais.

    Por exemplo, considere um ambiente no local que tenha uma rede de perímetro, mas que não distinga entre cargas de trabalho de desenvolvimento e produção. Para separar estas cargas de trabalho no Google Cloud, pode criar duas VPCs partilhadas e considerá-las novas zonas de segurança. Em seguida, implementa dois domínios do Active Directory adicionais para Google Cloud, um por zona de segurança. Se necessário, pode estabelecer relações de confiança entre florestas para ativar a autenticação em zonas de segurança.

    Separar cargas de trabalho em Google Cloud criando duas VPCs partilhadas como novas zonas de segurança.

Interação entre recursos no local e Google Cloud

O segundo fator a considerar quando estende o Active Directory para o Google Cloud é a interação dos utilizadores e dos recursos entre o local e Google Cloud. Consoante o seu exemplo de utilização, esta interação pode ser ligeira ou intensa.

Interação ligeira

Se o único objetivo da utilização do Active Directory no Google Cloud for gerir uma frota de servidores Windows e permitir que os administradores iniciem sessão nestes servidores, o nível de interação entre os ambientes é reduzido:

  • O conjunto de funcionários que interagem com recursos no Google Cloud está limitado ao pessoal administrativo.
  • As aplicações implementadas no Google Cloud podem não interagir com as aplicações no local ou podem fazê-lo sem depender das funcionalidades de autenticação do Windows, como o Kerberos e o NTLM.

Num cenário simples, considere integrar os seus ambientes no local e Google Cloud de uma das duas seguintes formas:

  • Duas florestas do Active Directory separadas: pode isolar os dois ambientes usando duas florestas do Active Directory separadas que não partilham uma relação de confiança. Para permitir que os administradores se autentiquem, tem de manter um conjunto separado de contas de utilizador para eles na Google Cloud floresta.

    A manutenção de um conjunto duplicado de contas de utilizador aumenta o esforço administrativo e introduz o risco de esquecer a desativação de contas quando os funcionários saem da empresa. Uma melhor abordagem é aprovisionar estas contas automaticamente.

    Se as contas de utilizador no seu Active Directory no local forem aprovisionadas por um sistema de informações de recursos humanos (HRIS), pode usar um mecanismo semelhante para aprovisionar e gerir contas de utilizador na florestaGoogle Cloud . Em alternativa, pode usar ferramentas como o Microsoft Identity Manager para sincronizar contas de utilizador entre ambientes.

  • Duas florestas do Active Directory com confiança entre florestas: se usar duas florestas do Active Directory e as associar com uma confiança entre florestas, pode evitar ter de manter contas duplicadas. Os administradores usam a mesma conta de utilizador para autenticar em ambos os ambientes. Embora o nível de isolamento entre ambientes possa ser considerado mais fraco, a utilização de florestas separadas permite-lhe manter um limite de confiança entre o seu ambiente no local e o ambiente Google Cloud .

Interação moderada

O seu exemplo de utilização pode ser mais complexo. Por exemplo:

  • Os administradores que iniciam sessão em servidores Windows implementados no Google Cloud podem ter de aceder a partilhas de ficheiros alojadas no local.
  • As aplicações podem usar o Kerberos ou o NTLM para autenticar e comunicar entre limites de ambiente.
  • Pode querer permitir que os funcionários usem a autenticação integrada do Windows (IWA) para autenticar em aplicações Web implementadas no Google Cloud.

Num cenário moderado, o funcionamento de duas florestas do Active Directory separadas pode ser demasiado limitativo: não pode usar o Kerberos para autenticar nas duas florestas e a utilização da autenticação de passagem requer que mantenha as contas de utilizador e as palavras-passe sincronizadas.

Neste caso, recomendamos que use duas florestas do Active Directory com uma relação de confiança entre florestas.

Interação intensa

Determinadas cargas de trabalho, incluindo implementações de infraestrutura de ambiente de trabalho virtual (VDI), podem exigir uma interação intensa entre recursos no local e recursos implementados no Google Cloud. Quando os recursos em vários ambientes estão estreitamente interligados, tentar manter um limite de confiança entre ambientes pode não ser prático, e usar duas florestas com uma confiança entre florestas pode ser demasiado limitativo.

Neste caso, recomendamos que use uma única floresta do Active Directory e a partilhe em todos os ambientes.

Autonomia administrativa

O terceiro fator a ter em conta quando estende o Active Directory para o Google Cloud é a autonomia administrativa.

Se planeia distribuir cargas de trabalho no local e Google Cloud, as cargas de trabalho que vai executar no Google Cloud podem ser muito diferentes das cargas de trabalho que mantém no local. Pode até decidir que equipas diferentes devem gerir os dois ambientes.

A separação de responsabilidades entre diferentes equipas requer a concessão de alguma autonomia administrativa a cada equipa. No Active Directory, pode conceder às equipas a autoridade para gerir recursos através da administração delegada ou de domínios separados.

A administração delegada é uma forma simples de delegar tarefas administrativas e conceder alguma autonomia às equipas. A manutenção de um único domínio também pode ajudar a garantir a consistência em todos os ambientes e equipas.

No entanto, não pode delegar todas as capacidades administrativas e a partilha de um único domínio pode aumentar os custos administrativos da coordenação entre equipas. Nesse caso, recomendamos que use domínios separados.

Disponibilidade

O fator final a ter em consideração quando estende o Active Directory ao Google Cloud é a disponibilidade. Para cada domínio numa floresta do Active Directory, o controlador de domínio funciona como o fornecedor de identidade para os utilizadores nesse domínio.

Quando usa o Kerberos para autenticação, um utilizador tem de interagir com um controlador de domínio do Active Directory em vários pontos:

  • Autenticação inicial (obter um pedido para obter pedidos).
  • Reautenticação periódica (atualização de um pedido para obter pedidos).
  • Autenticação com um recurso (obtenção de um pedido de serviço).

A realização da autenticação inicial e da reautenticação periódica requer a comunicação apenas com um controlador de domínio, ou seja, um controlador de domínio do domínio do qual o utilizador é membro.

Quando se autentica com um recurso, pode ser necessário interagir com vários controladores de domínio, consoante o domínio em que o recurso se encontra:

A localização de utilizadores e recursos em diferentes domínios ou florestas do Active Directory pode restringir a disponibilidade geral. Uma vez que a autenticação requer interação com vários domínios, uma indisponibilidade de um domínio pode afetar a disponibilidade de recursos noutros domínios.

Tendo em conta o potencial impacto da topologia do Active Directory na disponibilidade, recomendamos que alinhe a topologia do Active Directory com a sua estratégia híbrida.

Cargas de trabalho distribuídas

Para tirar partido das capacidades únicas de cada ambiente de computação, pode usar uma abordagem híbrida para distribuir cargas de trabalho nesses ambientes. Nesta configuração, as cargas de trabalho que implementa no Google Cloud dependem provavelmente de outras infraestruturas ou aplicações executadas no local, o que torna a conetividade híbrida altamente disponívelum requisito essencial.

Se implementar uma floresta ou um domínio do Active Directory separado para Google Cloud e usar uma confiança para o ligar ao seu Active Directory no local, adiciona outra dependência entre Google Cloud e o seu ambiente no local. Esta dependência tem um efeito mínimo na disponibilidade.

Cargas de trabalho redundantes

Se usar o Google Cloud para garantir a continuidade da empresa, as suas cargas de trabalho no Google Cloud refletem algumas das cargas de trabalho no seu ambiente no local. Esta configuração permite que um ambiente assuma a função do outro ambiente se ocorrer uma falha. Por isso, tem de analisar todas as dependências entre estes ambientes.

Se implementar uma floresta ou um domínio do Active Directory separado para Google Cloud e usar uma relação de confiança para o ligar ao seu Active Directory no local, pode criar uma dependência que prejudica o objetivo da configuração. Se o Active Directory no local ficar indisponível, todas as cargas de trabalho implementadas noGoogle Cloud que dependem da autenticação entre domínios ou entre florestas também podem ficar indisponíveis.

Se o seu objetivo for garantir a continuidade da empresa, pode usar florestas do Active Directory separadas em cada ambiente que não estejam ligadas entre si. Em alternativa, pode expandir um domínio do Active Directory existente para o Google Cloud. Ao implementar controladores de domínio adicionais paraGoogle Cloud e replicar o conteúdo do diretório entre ambientes, garante que os ambientes funcionam de forma isolada.

Padrões de integração

Depois de avaliar os seus requisitos, use a seguinte árvore de decisão para ajudar a identificar uma arquitetura de domínio e floresta adequada.

Árvore de decisões para ajudar a escolher uma arquitetura de floresta e domínio

As secções seguintes descrevem cada padrão.

Florestas sincronizadas

No padrão de florestas sincronizadas, implementa uma floresta do Active Directory separada para o Google Cloud. Usa esta floresta para gerir todos os recursos implementados no Google Cloud , bem como as contas de utilizador necessárias para gerir estes recursos.

Em vez de criar uma relação de confiança entre a nova floresta e uma floresta no local existente, sincroniza as contas. Se usar um HRIS como o sistema principal para gerir contas de utilizadores, pode configurar o HRIS para aprovisionar contas de utilizadores na floresta do Active Directory alojada pela Google Cloud. Em alternativa, pode usar ferramentas como o Microsoft Identity Manager para sincronizar contas de utilizador entre ambientes.

Implementar uma floresta do Active Directory separada para Google Cloud

Pondere usar o padrão de florestas sincronizadas se uma ou mais das seguintes situações se aplicar:

  • A utilização pretendida Google Cloud corresponde a um dos padrões de implementação redundantes, e quer evitar dependências de tempo de execução entre o seu ambiente no local e Google Cloud.
  • Quer manter um limite de confiança entre o seu ambiente do Active Directory no local e o ambiente do Active Directory alojado na Google Cloud, seja como uma medida de defesa em profundidade ou porque confia mais num ambiente do que no outro.
  • Espera pouca ou nenhuma interação entre os recursos geridos pelo Active Directory no local e no Google Cloud.
  • O número de contas de utilizadores de que precisa no ambiente do Active Directory alojado Google Cloud é pequeno.

Vantagens:

  • O padrão de florestas sincronizadas permite-lhe manter um forte isolamento entre os dois ambientes do Active Directory. Um atacante que comprometa um ambiente pode obter poucas vantagens ao atacar o segundo ambiente.
  • Não precisa de configurar a conetividade híbrida entre as suas redes locais e Google Cloud para operar o Active Directory.
  • O Active Directory alojado na Google Cloudnuvem não é afetado por uma indisponibilidade do Active Directory no local. O padrão é adequado para exemplos de utilização de continuidade de negócios ou outros cenários que exijam alta disponibilidade.
  • Pode conceder um elevado nível de autonomia administrativa às equipas que gerem a floresta do Active Directory alojada no Google Cloud.
  • Este padrão é suportado pelo Serviço gerido para o Microsoft Active Directory.

Práticas recomendadas:

  • Não sincronize as palavras-passe das contas de utilizador entre as duas florestas do Active Directory. Se o fizer, compromete o isolamento entre os ambientes.
  • Não use a autenticação de passagem, uma vez que requer a sincronização das palavras-passe das contas de utilizador.
  • Certifique-se de que, quando um funcionário sai da empresa, as respetivas contas em ambos os ambientes do Active Directory são desativadas ou removidas.

Floresta de recursos

No padrão de floresta de recursos, implementa uma floresta do Active Directory separada para Google Cloud. Use esta floresta para gerir todos os recursos implementados no Google Cloud , bem como um conjunto mínimo de contas de utilizadores administrativos necessárias para gerir a floresta. Ao estabelecer uma relação de confiança entre florestas com a sua floresta do Active Directory no local existente, permite que os utilizadores da sua floresta existente se autentiquem e acedam a recursos geridos pela floresta do Active Directory alojada noGoogle Cloud.

Se necessário, pode desenvolver este padrão numa topologia de hub e spoke com a floresta do Active Directory existente no centro, ligada a muitas florestas de recursos.

Uma confiança florestal na sua floresta do Active Directory no local, o que permite aos utilizadores da sua floresta existente autenticar e aceder a recursos geridos pela floresta do Active Directory alojada emGoogle Cloud

Pondere usar o padrão de floresta de recursos se uma ou mais das seguintes condições se aplicar:

  • A utilização pretendida do Google Cloud enquadra-se num dos padrões de implementação distribuídos, e uma dependência entre o seu ambiente no local e o Google Cloud é aceitável.
  • Quer manter um limite de confiança entre o seu ambiente do Active Directory no local e o ambiente do Active Directory alojado na Google Cloud, seja como medida de defesa em profundidade ou porque considera um ambiente mais fidedigno do que o outro. Google Cloud
  • Espera um nível moderado de interação entre os recursos geridos pelo Active Directory no local e na nuvem Google Cloud.
  • Tem um grande número de utilizadores que precisam de aceder a recursos implementados em Google Cloud, por exemplo, a aplicações Web que usam a IWA para autenticação.

Vantagens:

  • O padrão de floresta de recursos permite-lhe manter um limite de confiança entre os dois ambientes do Active Directory. Consoante a forma como a relação de confiança está configurada, um atacante que comprometa um ambiente pode obter pouco ou nenhum acesso ao outro ambiente.
  • Este padrão é totalmente suportado pelo Managed Microsoft AD.
  • Pode conceder um elevado nível de autonomia administrativa às equipas que gerem a floresta do Active Directory alojada no Google Cloud.

Práticas recomendadas:

  • Ligue as duas florestas do Active Directory através de uma confiança unidirecional para que o Active Directory alojado no Google Cloud confie no seu Active Directory existente, mas não o contrário. Google Cloud
  • Use a autenticação seletiva para limitar os recursos no Active Directory alojado na Google Cloudaos quais os utilizadores do Active Directory no local têm autorização para aceder.
  • Use ligações Dedicated Interconnect, Partner Interconnect, ou Cloud VPN redundantes para garantir uma conetividade de rede de elevada disponibilidade entre a sua rede no local e o Google Cloud.

Domínio alargado

No padrão de domínio expandido, expande um ou mais dos seus domínios do Active Directory existentes para Google Cloud. Para cada domínio, implementa um ou mais controladores de domínio no Google Cloud, o que faz com que todos os dados do domínio, bem como o catálogo global, sejam replicados e disponibilizados noGoogle Cloud. Ao usar sites do Active Directory separados para os seus sub-redes locais e Google Cloud , garante que os clientes comunicam com os controladores de domínio mais próximos.

Estender um ou mais dos seus domínios do Active Directory existentes para Google Cloud

Pondere usar o padrão de domínio expandido se uma ou mais das seguintes opções se aplicarem:

  • A utilização pretendida Google Cloud adapta-se a um dos padrões de implementação redundantes e quer evitar dependências de tempo de execução entre o seu ambiente no local e Google Cloud.
  • Espera uma interação intensa entre os recursos geridos pelo Active Directory no local e naGoogle Cloud.
  • Quer acelerar a autenticação para aplicações que dependem do LDAP para autenticação.

Vantagens:

  • O Active Directory alojado na Google Cloudnuvem não é afetado por uma indisponibilidade do Active Directory no local. O padrão é adequado para exemplos de utilização de continuidade de negócios ou outros cenários que requerem alta disponibilidade.
  • Pode limitar a comunicação entre a sua rede no local e oGoogle Cloud. Isto pode poupar largura de banda e melhorar a latência.
  • Todo o conteúdo do catálogo global é replicado no Active Directory e pode ser acedido de forma eficiente a partir de recursos alojados no Google Cloud.

Práticas recomendadas:

  • Se replicar todos os domínios, a comunicação entre a sua rede no local e a rede do Google Cloud está limitada à replicação do Active Directory entre controladores de domínio. Se replicar apenas um subconjunto dos domínios da sua floresta, os servidores associados ao domínio que são executados noGoogle Cloud podem ainda ter de comunicar com os controladores de domínio de domínios não replicados. Certifique-se de que as regras da firewall que se aplicam à comunicação entre as instalações no local e a nuvem consideram todos os casos relevantes. Google Cloud
  • Tenha em atenção que a replicação entre sites ocorre apenas a determinados intervalos. Assim, as atualizações realizadas num controlador de domínio no local são apresentadas Google Cloud apenas após um atraso (e vice-versa).
  • Considere usar controladores de domínio só de leitura (RODCs) para manter uma cópia só de leitura dos dados do domínio no Google Cloud, mas tenha em atenção que existe uma compensação relacionada com o armazenamento em cache das palavras-passe dos utilizadores. Se permitir que os RODCs armazenem palavras-passe em cache e pré-preencham a cache de palavras-passe, os recursos implementados em Google Cloud podem permanecer inalterados por uma indisponibilidade dos controladores de domínio no local. No entanto, as vantagens de segurança da utilização de um RODC em vez de um controlador de domínio normal são limitadas. Se desativar o armazenamento em cache de palavras-passe, um RODC comprometido pode representar apenas um risco limitado para o resto do seu Active Directory, mas perde a vantagem de permanecer não afetado por uma indisponibilidade dos controladores de domínio no local.Google Cloud

Floresta expandida

No padrão de floresta expandida, implementa um novo domínio do Active Directory emGoogle Cloud, mas integra-o na sua floresta existente. Usa o novo domínio para gerir todos os recursos implementados no Google Cloud e para manter um conjunto mínimo de contas de utilizador administrativas para gerir o domínio.

Ao estender as relações de confiança implícitas a outros domínios da floresta, permite que os utilizadores existentes de outros domínios se autentiquem e acedam a recursos geridos pelo domínio do Active Directory alojado no Google Cloud.

Implementar um novo domínio do Active Directory em Google Cloud, mas integrá-lo na sua floresta existente

Pondere usar o padrão de floresta expandido se uma ou mais das seguintes opções se aplicarem:

  • A utilização pretendida do Google Cloud enquadra-se num dos padrões de implementação distribuídos e é aceitável uma dependência entre o seu ambiente no local e o Google Cloud .
  • Os recursos que planeia implementar Google Cloud requerem uma configuração ou uma estrutura de domínio diferente da que os seus domínios existentes oferecem, ou quer conceder um elevado nível de autonomia administrativa às equipas que administram o domínio alojado no Google Cloud.
  • Espera uma interação moderada a intensa entre os recursos geridos pelo Active Directory no local e na nuvem Google Cloud.
  • Tem muitos utilizadores que precisam de aceder a recursos implementados para Google Cloud, por exemplo, a aplicações Web que usam a IWA para autenticação.

Vantagens:

  • Todo o conteúdo do catálogo global é replicado no Active Directory e pode ser acedido de forma eficiente a partir de recursos alojados na Google Cloud.
  • O tráfego de replicação entre a sua rede no local e o Google Cloud está limitado à replicação do catálogo global. Isto pode ajudar a limitar o consumo geral de largura de banda.
  • Pode conceder um elevado nível de autonomia administrativa às equipas que gerem o domínio do Active Directory alojado no Google Cloud.

Práticas recomendadas:

  • Use ligações redundantes do Dedicated Interconnect, Partner Interconnect ou Cloud VPN para garantir a conetividade de rede de alta disponibilidade entre a sua rede no local e Google Cloud.

Floresta de recursos com domínio expandido

O padrão de floresta de recursos com domínio expandido é uma extensão do padrão de floresta de recursos. O padrão de floresta de recursos permite-lhe manter um limite de confiança entre ambientes e oferecer autonomia administrativa. Uma limitação da floresta de recursos é que a sua disponibilidade geral depende da disponibilidade dos controladores de domínio no local e da conetividade de rede fiável ao seu centro de dados no local.

Pode ultrapassar estas limitações combinando o padrão de floresta de recursos com o padrão de domínio alargado. Ao replicar o domínio, as suas contas de utilizador estão localizadas em Google Cloud, e pode garantir que os utilizadores se podem autenticar em recursos alojados na Google Cloud, mesmo quando os controladores de domínio no local não estão disponíveis ou a conetividade de rede é perdida.

Combinar o padrão de domínio alargado e a floresta de recursos

Pondere usar a floresta de recursos com o padrão de domínio expandido se se aplicar uma ou mais das seguintes situações:

  • Quiser manter um limite de confiança entre a floresta do Active Directory principal e a floresta de recursos.
  • Quiser impedir que uma indisponibilidade dos controladores de domínio no local ou a perda de conectividade de rede com o seu ambiente no local afete as suas cargas de trabalho alojadas na Google Cloud.
  • Espera uma interação moderada entre os recursos geridos pelo Active Directory no local e na nuvem Google Cloud.
  • Tem muitos utilizadores de um único domínio do Active Directory que precisam de aceder a recursos implementados no Google Cloud, por exemplo, a aplicações Web que usam a IWA para autenticação.

Vantagens:

  • Os recursos alojados noGoogle Cloudnão são afetados por uma indisponibilidade do Active Directory no local. O padrão é adequado para exemplos de utilização de continuidade de negócios ou outros cenários que exijam elevada disponibilidade.
  • O padrão permite-lhe manter um limite de confiança entre as duas florestas do Active Directory. Consoante a forma como a relação de confiança está configurada, um atacante que comprometa um ambiente pode obter pouco ou nenhum acesso ao outro ambiente.
  • A comunicação entre a sua rede no local e a rede Google Cloud está limitada à replicação do Active Directory entre os controladores de domínio. Pode implementar regras de firewall para não permitir outras comunicações, reforçando o isolamento entre ambientes
  • Pode conceder um elevado nível de autonomia administrativa às equipas que gerem a floresta do Active Directory alojada no Google Cloud.
  • Pode usar o Microsoft AD gerido para a floresta de recursos.

Práticas recomendadas:

  • Implemente controladores de domínio para o domínio expandido num Google Cloud projeto e numa VPC separados para separar estes componentes dos componentes da floresta de recursos.
  • Use o peering de VPC para ligar a VPC à VPC partilhada ou à VPC usada pela floresta de recursos e configure firewalls para restringir a comunicação à autenticação de utilizadores Kerberos e à criação de confiança entre florestas.
  • Ligue as duas florestas do Active Directory através de uma confiança unidirecional para que o Active Directory alojado na nuvem confie na sua floresta do Active Directory existente, mas não o contrário. Google Cloud
  • Use a autenticação seletiva para limitar os recursos na floresta de recursos aos quais os utilizadores de outras florestas têm permissão para aceder.
  • Tenha em atenção que a replicação entre sites ocorre apenas em determinados intervalos. Por isso, as atualizações realizadas num controlador de domínio no local são apresentadas apenas após um atraso (e vice-versa).Google Cloud
  • Considere usar RODCs para o domínio expandido, mas certifique-se de que permite a colocação em cache de palavras-passe para preservar as vantagens de disponibilidade em comparação com o padrão de floresta de recursos.

O que se segue?