Federe Google Cloud com o Active Directory

Este documento descreve como pode configurar o Cloud ID ou o Google Workspace para usar o Active Directory como IdP e origem autorizada.

O documento compara a estrutura lógica do Active Directory com a estrutura usada pelo Cloud Identity e Google Workspace, e descreve como pode mapear florestas, domínios, utilizadores e grupos do Active Directory. O documento também inclui um fluxograma que ajuda a determinar a melhor abordagem de mapeamento para o seu cenário.

Este documento pressupõe que está familiarizado com o Active Directory.

Implemente a federação

Google Cloud usa identidades Google para autenticação e gestão de acesso. A manutenção manual das identidades Google para cada funcionário pode adicionar custos gerais de gestão desnecessários quando todos os funcionários já têm uma conta no Active Directory. Ao federar identidades de utilizadores entre o Google Cloud e o seu sistema de gestão de identidades existente, pode automatizar a manutenção das identidades Google e associar o respetivo ciclo de vida aos utilizadores existentes no Active Directory.

A configuração da federação entre o Active Directory e o Cloud ID ou o Google Workspace envolve dois elementos:

• Aprovisionamento de utilizadores: os utilizadores e os grupos relevantes são sincronizados periodicamente do Active Directory para o Cloud ID ou o Google Workspace. Este processo garante que, quando cria um novo utilizador no Active Directory, pode fazer referência a ele Google Cloud mesmo antes de o utilizador associado ter iniciado sessão pela primeira vez. Este processo também garante que as eliminações de utilizadores estão a ser propagadas.

  O aprovisionamento funciona num sentido, o que significa que as alterações no Active Directory são replicadas para o Google Cloud , mas não o contrário. Além disso, o aprovisionamento não inclui palavras-passe. Numa configuração federada, o Active Directory continua a ser o único sistema que gere estas credenciais.

• Início de sessão único: sempre que um utilizador precisa de autenticar, Google Cloud delega a autenticação no Active Directory através do protocolo Security Assertion Markup Language (SAML). Esta delegação garante que apenas o Active Directory gere as credenciais do utilizador e que quaisquer políticas aplicáveis ou mecanismos de autenticação multifator (AMF) estão a ser aplicados. No entanto, para que um início de sessão seja bem-sucedido, o utilizador em questão tem de ter sido aprovisionado anteriormente.

Para implementar a federação, pode usar as seguintes ferramentas:

• A Sincronização de diretórios do Google Cloud (GCDS) é uma ferramenta gratuita fornecida pela Google que implementa o processo de sincronização. O GCDS comunica com o Google Cloud através da camada de ligação segura (SSL) e, normalmente, é executado no ambiente de computação existente.
• O Active Directory Federation Services (AD FS) é fornecido pela Microsoft como parte do Windows Server. Com o AD FS, pode usar o Active Directory para a autenticação federada. Normalmente, o AD FS é executado no ambiente de computação existente.

Uma vez que as APIs para Google Cloud estão disponíveis publicamente e o SAML é uma norma aberta, existem muitas ferramentas disponíveis para implementar a federação. Este documento centra-se na utilização do GCDS e do AD FS.

Estrutura lógica do Active Directory

Numa infraestrutura do Active Directory, o componente de nível superior é a floresta. A floresta funciona como um contentor para um ou mais domínios e deriva o respetivo nome do domínio raiz da floresta. Os domínios numa floresta do Active Directory confiam uns nos outros, o que permite que os utilizadores autenticados num domínio acedam a recursos que estão noutro domínio. A menos que as florestas estejam ligadas através de relações de confiança entre florestas, as florestas separadas não confiam umas nas outras por predefinição, e os utilizadores autenticados numa floresta não podem aceder a recursos que estejam numa floresta diferente.

Os domínios do Active Directory são contentores para gerir recursos e são considerados limites administrativos. Ter vários domínios numa floresta é uma forma de simplificar a administração ou aplicar uma estrutura adicional, mas os domínios numa floresta não representam limites de segurança.

Estrutura lógica de Google Cloud

Nas Google Cloud, organizações servem como contentores para todos os recursos e podem ser ainda mais segmentadas através de pastas e projetos. Por conseguinte, as organizações, as pastas e os projetos têm uma finalidade semelhante à dos domínios do Active Directory.

O Active Directory trata os utilizadores como recursos, pelo que a gestão de utilizadores e a autenticação estão associadas a domínios. Por outro lado, Google Cloud não gere utilizadores numa organização, exceto contas de serviço. Em alternativa, Google Cloud usa o Cloud ID ou o Google Workspace para gerir os utilizadores.

Uma conta do Cloud ID ou do Google Workspace funciona como um diretório privado para utilizadores e grupos. Enquanto administrador da conta, pode controlar o ciclo de vida e a configuração dos utilizadores e grupos, bem como definir como a autenticação pode ser realizada.

Quando cria uma conta do Cloud Identity ou do Google Workspace, uma Google Cloud organização é criada automaticamente para si. A conta do Cloud ID ou do Google Workspace e a Google Cloud organização associada partilham o mesmo nome e estão interligadas. No entanto, uma Google Cloud organização pode fazer referência a utilizadores e grupos de outras contas do Cloud Identity ou do Google Workspace.

Integre o Active Directory e Google Cloud

Apesar de existirem algumas semelhanças entre a estrutura lógica do Active Directory e o Google Cloud, não existe um único mapeamento entre as duas estruturas que funcione igualmente bem em todos os cenários. Em alternativa, a abordagem correta para integrar os dois sistemas e mapear a estrutura depende de vários fatores:

• Como mapear domínios e florestas para contas do Cloud ID ou do Google Workspace
• Como mapear domínios DNS
• Como mapear utilizadores
• Como mapear grupos

As secções seguintes analisam cada um destes fatores.

Mapeie florestas

Especialmente em organizações maiores, usa frequentemente mais do que um domínio do Active Directory para gerir identidades e acesso em toda a empresa. Quando planeia federar o Active Directory e Google Cloud, o primeiro fator a ter em conta é a topologia da sua infraestrutura do Active Directory.

Floresta única, domínio único

Quando uma floresta inclui apenas um domínio, pode mapear toda a floresta do Active Directory para uma única conta do Cloud ID ou do Google Workspace. Esta conta fornece, então, a base para uma única Google Cloud organização que pode usar para gerir os seus Google Cloud recursos.

Num ambiente de domínio único, os controladores de domínio e os servidores de catálogo global dão acesso a todos os objetos geridos no Active Directory. Na maioria dos casos, pode executar uma única instância do GCDS para sincronizar contas de utilizador e grupos com o Google Cloude para manter uma única instância ou frota do AD FS para processar o início de sessão único.

Uma única floresta, vários domínios

Quando uma floresta contém vários domínios do Active Directory, pode organizá-los numa ou mais árvores de domínios. Em ambos os casos, pode mapear toda a floresta para uma única conta do Cloud ID ou do Google Workspace. Esta conta fornece, então, a base para uma única Google Cloud organização que pode usar para gerir os seus Google Cloud recursos.

Num ambiente de vários domínios, existe uma diferença entre as informações que podem ser obtidas de um controlador de domínio e as que podem ser consultadas num servidor de catálogo global. Embora os controladores de domínio sirvam dados apenas do respetivo domínio local, os servidores de catálogo global fornecem acesso a informações de todos os domínios na floresta. É fundamental que os dados disponibilizados pelos servidores de catálogo global sejam parciais e não tenham determinados atributos LDAP. Esta limitação pode afetar a forma como configura o GCDS para sincronizar grupos.

Consoante a forma como planeia mapear grupos, a federação de uma floresta de vários domínios com o GCDS Google Cloud requer uma ou mais instâncias do GCDS, mas apenas uma única instância ou frota do AD FS para processar o início de sessão único.

Várias florestas com confiança entre florestas

Em organizações maiores, não é invulgar ter mais do que uma floresta do Active Directory, muitas vezes como resultado de uma fusão ou aquisição. Pode combinar estas florestas usando uma confiança bidirecional entre florestas para que os utilizadores possam partilhar e aceder a recursos nos limites de uma única floresta.

Se todas as florestas tiverem uma relação de confiança bidirecional com outra floresta, pode mapear todo o ambiente para uma única conta do Cloud ID ou do Google Workspace. Esta conta fornece a base para uma única Google Cloud organização que pode usar para gerir os seus Google Cloud recursos.

Embora os servidores de catálogo global forneçam acesso a dados de vários domínios, o respetivo âmbito está limitado a uma única floresta. Assim, num ambiente com várias florestas, tem de consultar vários controladores de domínio ou servidores de catálogo global para obter, por exemplo, uma lista completa de utilizadores. Como resultado desta limitação, a federação de um ambiente com várias florestas com o Google Cloud requer, pelo menos, uma instância do GCDS por floresta. As relações de confiança entre florestas permitem que a autenticação de utilizadores funcione em limites de florestas, pelo que uma única instância ou frota do AD FS é suficiente para processar o início de sessão único.

Se o seu ambiente abranger várias florestas sem confiança entre florestas, mas todos os domínios do Active Directory relevantes para a federação com o Google Cloudestiverem ligados através de confianças externas, aplicam-se as mesmas considerações.

Vários domínios florestais sem confiança entre domínios florestais

No ambiente ilustrado aqui, não é possível autenticar nem aceder a recursos nos limites da floresta. Também não é possível que uma única instância ou frota do AD FS processe pedidos de início de sessão único para utilizadores de todas as florestas.

Por conseguinte, não é possível mapear várias florestas que não tenham relações de confiança entre florestas para uma única conta do Cloud ID ou do Google Workspace. Em alternativa, cada floresta tem de ser mapeada para uma conta do Cloud Identity ou Google Workspace separada, o que envolve a execução de, pelo menos, uma instância do GCDS e um servidor ou uma frota do AD FS por floresta.

Na Google Cloud, é criada uma organização separada para cada conta do Cloud ID ou do Google Workspace. Na maioria dos casos, não precisa de manter várias organizações separadas. Pode selecionar uma das organizações e associá-la às outras contas do Cloud Identity ou Google Workspace, criando efetivamente uma organização federada com várias florestas do Active Directory. As outras organizações permanecem não usadas.

Mapeie domínios DNS

O DNS desempenha um papel crucial no Active Directory e no Cloud ID e no Google Workspace. O segundo fator a ter em conta quando planeia federar o Active Directory e o Google Workspace é como partilhar ou mapear domínios DNS entre o Active Directory e o Google Workspace. Google Cloud Google Cloud

Utilização de domínios DNS no Active Directory

Numa floresta do Active Directory, os domínios DNS são usados em vários locais:

• Domínios DNS do Active Directory: cada domínio do Active Directory corresponde a um domínio DNS. Este domínio pode ser global, como corp.example.com, ou pode ser um nome de domínio local, como corp.local ou corp.internal.
• Domínios de troca de correio (MX): os endereços de email usam um domínio DNS. Em alguns casos, este domínio é o mesmo que o domínio DNS do Active Directory, mas, em muitos casos, é usado um domínio diferente, muitas vezes mais curto, como example.com. Idealmente, os utilizadores no Active Directory têm o endereço de email associado ao atributo opcional mail.
• Domínios de sufixo UPN: estes domínios são usados para nomes principais de utilizadores (UPN). Por predefinição, o domínio DNS do Active Directory do domínio do utilizador é usado para criar um UPN. Para um utilizador john no domínio corp.example.com, o UPN predefinido é, por conseguinte, [e-mail]. No entanto, pode configurar uma floresta para usar domínios DNS adicionais como sufixos de UPN que não correspondam a domínios DNS do Active Directory nem a domínios MX. Os UPNs são opcionais e são armazenados no campo userPrincipalName do utilizador.
• Domínios de pontos finais: normalmente, é atribuído um nome DNS aos servidores virados para o público, como os servidores AD FS, por exemplo, login.external.example.com. O domínio usado para estes fins pode sobrepor-se ao MX, ao sufixo UPN ou ao domínio DNS do Active Directory, ou pode ser um domínio totalmente diferente.

Utilização de domínios DNS em Google Cloud

O início de sessão na Google, que Google Cloud usa para autenticação, usa endereços de email para identificar os utilizadores. A utilização de endereços de email não só garante que são globalmente únicos, como também permite enviar mensagens de notificação para os endereços. Google Cloud

O Início de sessão Google determina o diretório ou o fornecedor de identidade a usar para autenticar um utilizador com base na parte do domínio dos endereços de email, que segue o @. Para um endereço de email que usa o domínio gmail.com, por exemplo, o início de sessão Google usa o diretório de utilizadores do Gmail para autenticação.

Quando se inscreve numa conta do Google Workspace ou do Cloud Identity, cria um diretório privado que o Início de sessão pode usar para autenticação. Tal como o diretório do Gmail está associado ao domínio gmail.com, as contas do Google Workspace e do Cloud ID têm de estar associadas a um domínio personalizado. São usados três tipos diferentes de domínios:

• Domínio principal: este domínio identifica a conta do Cloud Identity ou do Google Workspace e é usado como o nome da organização no Google Cloud. Quando se inscreve no Cloud ID ou no Google Workspace, tem de especificar este nome de domínio.
• Domínio secundário: juntamente com o domínio principal, pode associar outros domínios secundários a uma conta do Cloud ID ou do Google Workspace. Cada utilizador no diretório está associado ao domínio principal ou a um dos domínios secundários. Dois utilizadores, [e-mail] e [e-mail], são considerados utilizadores separados se example.com for o domínio principal e secondary.example.com for um domínio secundário.
• Domínio do alias: um domínio do alias é um nome alternativo para outro domínio. Ou seja, [e-mail] e [e-mail] referem-se ao mesmo utilizador se alias.example.com estiver configurado como um domínio de alias para example.com.

Todos os domínios têm de cumprir os seguintes requisitos:

• Têm de ser nomes de domínio DNS globais válidos. Durante a configuração, pode ter de ter acesso administrativo às respetivas zonas de DNS para validar a propriedade do domínio.
• Um domínio, como example.com, só pode referir-se a um único diretório. No entanto, pode usar subdomínios diferentes, como subdomain.example.com, para se referir a diretórios diferentes.
• Os domínios principal e secundário devem ter um registo MX válido para que as mensagens enviadas para endereços de email formados através deste nome de domínio possam ser entregues corretamente.

Para ativar a sincronização entre os diretórios, é necessário fazer algum mapeamento entre os domínios do Active Directory e os domínios que o Cloud Identity ou o Google Workspace usam. A determinação do mapeamento correto depende da forma como usa o Active Directory e requer uma análise mais detalhada da forma como os utilizadores são identificados numa floresta do Active Directory e como podem ser mapeados para o Cloud Identity ou o Google Workspace.

Utilizadores do mapa

O terceiro fator a ter em conta ao planear a federação do Active Directory e do Google Cloud é como mapear os utilizadores entre o Active Directory e o Cloud ID ou o Google Workspace.

Identifique utilizadores no Active Directory

Internamente, o Active Directory usa dois identificadores para identificar os utilizadores de forma exclusiva:

• objectGUID: este ID globalmente exclusivo é gerado quando um utilizador é criado e nunca muda.
• objectSID: O SID> ou identificador de segurança, é usado para todas as verificações de acesso. Embora este ID seja único e estável num domínio, é possível que, quando movido para um domínio diferente na floresta, seja atribuído um novo SID a um utilizador.

Nenhum destes IDs é significativo para os utilizadores, pelo que o Active Directory oferece duas formas fáceis de usar para identificar os utilizadores:

• UPN (userPrincipalName): a forma preferencial de identificar um utilizador é através do UPN. Os UPNs seguem o formato RFC 822 dos endereços de email e são criados combinando o nome de utilizador com um domínio de sufixo UPN, como em [e-mail]. Apesar de ser a forma preferencial de identificar os utilizadores, os UPNs são opcionais, pelo que alguns utilizadores na sua floresta do Active Directory podem não ter um UPN.

  Embora seja considerada uma prática recomendada que os UPNs sejam endereços de email válidos, o Active Directory não aplica esta prática.

• Nome de início de sessão anterior ao Windows 2000 (sAMAccountName): este nome combina o nome de domínio NetBIOS e o nome de utilizador através do formato domain<var>user, como em corp\johndoe. Embora estes nomes sejam considerados antigos, continuam a ser usados frequentemente e são o único identificador obrigatório de um utilizador.

Em particular, o Active Directory não usa o endereço de email do utilizador (mail) para identificar utilizadores. Consequentemente, este campo não é obrigatório nem tem de ser único numa floresta.

Pode alterar todos estes identificadores em qualquer altura.

Mapeie identidades de utilizadores

Mapear utilizadores do Active Directory para utilizadores do Cloud ID ou do Google Workspace requer duas informações para cada utilizador:

• Um ID estável e exclusivo que pode usar durante a sincronização para acompanhar que utilizador do Active Directory corresponde a que utilizador no Cloud ID ou Google Workspace. No lado do AD, o objectGUID é perfeitamente adequado para este fim.
• Um endereço de email cuja parte do domínio corresponde a um domínio principal, secundário ou alias da sua conta do Cloud ID ou do Google Workspace. Uma vez que este endereço de email vai ser usado em todo o processo Google Cloud, certifique-se de que o endereço é significativo. Derivar um endereço do objectGUID é impraticável, tal como acontece com outros endereços de email gerados automaticamente.

Para um utilizador do Active Directory, existem dois campos candidatos a fornecer um endereço de email do Cloud ID ou do Google Workspace: userPrincipalName e mail.

Mapeie por nome principal do utilizador

A utilização do campo userPrincipalName requer o cumprimento de dois critérios para todos os utilizadores sujeitos à sincronização:

• Os nomes principais de utilizadores (UPNs) têm de ser endereços de email válidos. Todos os domínios que são usados como domínios de sufixo UPN também têm de ser domínios MX e têm de ser configurados para que um email enviado para o UPN de um utilizador seja entregue na respetiva caixa de entrada de email.

• As atribuições de UPN têm de estar concluídas. Todos os utilizadores sujeitos à sincronização têm de ter um UPN atribuído. O seguinte comando do PowerShell pode ajudar a encontrar utilizadores que não têm um UPN:

  Get-ADUser -LDAPFilter "(!userPrincipalName=*)"

Se estes dois critérios forem cumpridos, pode mapear com segurança os UPNs para endereços de email do Cloud Identity ou do Google Workspace. Pode usar um dos domínios de sufixo do UPN como o domínio principal no Cloud ID ou no Google Workspace e adicionar quaisquer outros domínios de sufixo do UPN como domínios secundários.

Se um dos critérios não for cumprido, ainda pode mapear UPNs para endereços de email do Cloud Identity ou do Google Workspace, mas aplicam-se as seguintes ressalvas:

• Se os UPNs não forem endereços de email válidos, os utilizadores podem não receber emails de notificação enviados por Google Cloud, o que pode fazer com que os utilizadores percam informações importantes.
• Os utilizadores sem UPNs são ignorados durante a sincronização.
• Pode configurar a sincronização para substituir o domínio do sufixo do UPN por um domínio diferente. Quando usa vários domínios de sufixo UPN numa floresta, esta abordagem pode criar duplicados, no entanto, porque todos os domínios de sufixo UPN são substituídos por um único domínio. Em caso de duplicados, só é possível sincronizar um utilizador.

Uma grande vantagem da utilização de UPNs para mapear utilizadores é que os UPNs são garantidamente únicos numa floresta e usam um conjunto selecionado de domínios, o que ajuda a evitar potenciais problemas de sincronização.

Mapeie por endereço de email

A utilização do campo mail requer o cumprimento dos seguintes critérios para todos os utilizadores sujeitos à sincronização:

• As atribuições de email têm de estar concluídas. Todos os utilizadores sujeitos à sincronização têm de ter o campo mail preenchido. O seguinte comando do PowerShell pode ajudar a encontrar utilizadores para os quais este campo não está preenchido:

  Get-ADUser -LDAPFilter "(!mail=*)"

• Os endereços de email têm de usar um conjunto organizado de domínios, todos eles pertencentes a si. Se alguns dos seus utilizadores usarem endereços de email que se referem a empresas parceiras ou fornecedores de email de consumidor, esses endereços de email não podem ser usados.

• Todos os endereços de email têm de ser exclusivos na floresta. Uma vez que o Active Directory não aplica a exclusividade, pode ter de implementar verificações ou políticas personalizadas.

Se todos os utilizadores relevantes cumprirem estes critérios, pode identificar todos os domínios usados por estes endereços de email e usá-los como domínios principais e secundários no Cloud Identity ou Google Workspace.

Se um dos critérios não for cumprido, ainda pode mapear endereços de email para endereços de email do Cloud Identity ou Google Workspace, com as seguintes ressalvas:

• Durante a sincronização, os utilizadores sem endereços de email são ignorados, tal como os utilizadores com endereços de email que usam domínios não associados à conta do Cloud ID ou do Google Workspace.
• Quando dois utilizadores partilham o mesmo endereço de email, apenas um utilizador é sincronizado.
• Pode configurar a sincronização para substituir o domínio dos endereços de email por um domínio diferente. Este processo pode criar duplicados, caso em que apenas um utilizador é sincronizado.

Grupos de mapas

O quarto fator a ter em conta quando planeia federar o Active Directory e Google Cloud é se deve sincronizar grupos entre o Active Directory e Google Cloud e como mapeá-los.

Os Google Cloud, grupos são usados frequentemente como uma forma de gerir o acesso de forma eficiente em vários projetos. Em vez de atribuir utilizadores individuais a funções do IAM em cada projeto, define um conjunto de grupos que modelam funções comuns na sua organização e, em seguida, atribui esses grupos a um conjunto de funções do IAM. Ao modificar a associação dos grupos, pode controlar o acesso dos utilizadores a um conjunto completo de recursos.

O Active Directory distingue entre dois tipos de grupos: grupos de distribuição e grupos de segurança. Os grupos de distribuição são usados para gerir listas de correio. A sincronização de grupos de distribuição é relevante quando está a migrar do Microsoft Exchange para o Google Workspace, para que o GCDS possa processar grupos de distribuição normais e dinâmicos. Os grupos de distribuição não são uma preocupação na gestão de identidade e acesso para o Google Cloud. No entanto, esta discussão centra-se exclusivamente nos grupos de segurança.

O mapeamento de grupos entre o Active Directory e Google Cloud é opcional. Depois de configurar o aprovisionamento de utilizadores, pode criar e gerir grupos diretamente no Cloud Identity ou no Google Workspace, o que significa que o Active Directory continua a ser o sistema central para a gestão de identidades, mas não para a gestão de acesso. Para manter o Active Directory como o sistema central para a gestão de identidades e a gestão de acesso, recomendamos que sincronize os grupos de segurança do Active Directory em vez de os gerir no Cloud ID ou no Google Workspace. Com esta abordagem, pode configurar o IAM para poder usar as subscrições de grupos no Active Directory para controlar quem tem acesso a determinados recursos no Google Cloud.

Grupos de segurança no Active Directory

Os grupos de segurança desempenham um papel fundamental na segurança do Windows e na gestão de acesso do Active Directory. Esta função é facilitada por três tipos diferentes de grupos do Active Directory: grupos locais do domínio, grupos globais e grupos universais.

Grupos locais de domínio

Estes grupos só são relevantes no âmbito de um único domínio e não podem ser referenciados noutros domínios. Uma vez que a respetiva lista de membros não tem de ser replicada na floresta, os grupos locais do domínio são os mais flexíveis no que diz respeito aos tipos de membros que podem incluir.

Grupos globais

Estes grupos são apresentados e podem ser referenciados noutros domínios. No entanto, a respetiva lista de membros não é replicada. Esta limitação restringe os tipos de membros que estes grupos podem incluir. Estes grupos só podem incluir utilizadores e outros grupos globais do mesmo domínio.

Grupos universais

Estes grupos, juntamente com as respetivas listas de membros, são replicados na floresta. Por conseguinte, podem ser referenciados noutros domínios e podem incluir não só utilizadores e outros grupos universais, mas também grupos globais de todos os domínios.

Se a floresta do Active Directory contiver apenas um domínio, pode sincronizar os três tipos de grupos de segurança através do GCDS. Se a floresta do Active Directory usar mais do que um domínio, o tipo de um grupo determina se e como pode ser sincronizado com o Cloud Identity ou o Google Workspace.

Uma vez que os grupos locais e globais do domínio não são totalmente replicados numa floresta, os servidores do catálogo global contêm informações incompletas sobre os mesmos. Embora esta limitação seja deliberada e ajude a acelerar a replicação do diretório, é um obstáculo quando quer sincronizar esses grupos com o Cloud ID ou o Google Workspace. Especificamente, se configurar o GCDS para usar um servidor de catálogo global como origem, a ferramenta vai poder encontrar grupos de todos os domínios na floresta. No entanto, apenas os grupos que estão no mesmo domínio que o servidor do catálogo global contêm uma lista de membros e são adequados para replicação. Para sincronizar grupos locais ou globais de domínios num conjunto de domínios múltiplos, tem de executar uma instância do GCDS separada por domínio.

Uma vez que os grupos universais são totalmente replicados na floresta, não têm esta restrição. Uma única instância do GCDS pode sincronizar grupos universais de vários domínios.

Antes de concluir que precisa de várias instâncias do GCDS para sincronizar vários domínios do Active Directory com o Cloud Identity ou o Google Workspace, tenha em atenção que nem todos os grupos podem precisar de ser sincronizados. Por este motivo, vale a pena analisar a forma como os diferentes tipos de grupos de segurança são normalmente usados na sua floresta do Active Directory.

Utilização de grupos de segurança no Active Directory

As secções seguintes descrevem os tipos de grupos de segurança usados no Active Directory.

Grupos de recursos

O Windows usa um modelo de acesso baseado em listas de controlo de acesso (ACLs). Cada recurso, como um ficheiro ou um objeto LDAP, tem uma ACL associada que controla os utilizadores que têm acesso ao mesmo. Os recursos e as ACLs são muito detalhados, pelo que existem muitos. Para simplificar a manutenção das ACLs, é comum criar grupos de recursos para agrupar recursos que são usados e acedidos com frequência em conjunto. Adiciona o grupo de recursos a todas as ACLs afetadas uma vez e gere o acesso adicional alterando a associação do grupo de recursos e não as ACLs.

Normalmente, os recursos agrupados desta forma residem num único domínio. Consequentemente, um grupo de recursos também tende a ser referenciado apenas num único domínio, seja em ACLs ou por outros grupos de recursos. Uma vez que a maioria dos grupos de recursos é local, estes são normalmente implementados através de grupos locais do domínio no Active Directory.

Funções e grupos de organização

Os grupos de recursos ajudam a simplificar a gestão de acesso, mas, num ambiente grande, pode ter de adicionar um novo utilizador a um grande número de grupos de recursos. Por este motivo, os grupos de recursos são normalmente complementados por grupos de funções ou grupos de organização.

Os grupos de funções agregam as autorizações que uma função específica requer na organização. Um grupo de funções denominado Engineering Documentation Viewer, por exemplo, pode conceder aos membros acesso só de leitura a toda a documentação de engenharia. Na prática, implementaria isto criando um grupo de funções e tornando-o membro de todos os grupos de recursos usados para controlar o acesso a vários tipos de documentação.

Da mesma forma, os grupos de organizações agregam as autorizações necessárias pelos departamentos de uma organização. Por exemplo, um grupo organizacional denominado Engenharia pode conceder acesso a todos os recursos que os membros do departamento de Engenharia normalmente precisam.

Tecnicamente, não existe diferença entre os grupos de funções e os grupos de recursos, e os dois são usados frequentemente em conjunto. No entanto, ao contrário dos grupos de recursos, os grupos de funções e de organização podem ter relevância para além dos limites de um domínio. Para permitir que os grupos sejam referenciados por grupos de recursos noutros domínios, os grupos de funções e de organizações são normalmente implementados através de grupos globais, que estão restritos a membros de um único domínio e, por vezes, complementados por grupos universais, que permitem membros de domínios diferentes.

O diagrama seguinte mostra um padrão de aninhamento usado frequentemente em ambientes do Active Directory com vários domínios.

Grupos no Cloud ID e Google Workspace

No Cloud Identity e no Google Workspace, existe apenas um tipo de grupo. Os grupos no Cloud ID e no Google Workspace não se limitam ao âmbito da conta do Cloud ID ou do Google Workspace onde foram definidos. Em alternativa, podem incluir utilizadores de diferentes contas do Cloud ID ou Google Workspace, suportar referências e aninhamento noutras contas, e ser usadas em qualquer Google Cloud organização.

Tal como acontece com os utilizadores, o Cloud ID e o Google Workspace identificam os grupos por endereço de email. O endereço de email não tem de corresponder a uma caixa de correio real, mas tem de usar um dos domínios registados para a respetiva conta do Cloud ID.

Ao contrário dos grupos do Active Directory, os membros de um grupo do Cloud ID ou do Google Workspace não recebem implicitamente autorização para listar outros membros do mesmo grupo. Em alternativa, a consulta da associação a grupos geralmente requer autorização explícita.

Utilização de grupos no Google Cloud

Google Cloud usa um modelo de acesso baseado em funções em vez de um modelo de acesso baseado em ACLs. As funções aplicam-se a todos os recursos de um determinado tipo que se enquadram num determinado âmbito. Por exemplo, a função de programador do Kubernetes Engine tem acesso total aos objetos da API Kubernetes em todos os clusters num determinado projeto. Devido à natureza dos papéis, existe pouca necessidade de manter grupos de recursos no Google Cloude raramente existe necessidade de sincronizar grupos de recursos com o Google Cloud.

Os grupos de funções e os grupos de organização são tão relevantes no Google Cloud como no Active Directory, porque facilitam a gestão do acesso para um grande número de utilizadores. A sincronização das funções e dos grupos da organização ajuda a manter o Active Directory como o local principal para gerir o acesso.

Se implementar consistentemente grupos de recursos como grupos locais de domínio e grupos de funções e organizações como grupos globais ou universais, pode usar o tipo de grupo para garantir que apenas os grupos de funções e organizações são sincronizados.

A questão de saber se é suficiente executar uma única instância da GCDS por floresta de vários domínios ou se precisa de várias instâncias da GCDS torna-se a questão de saber se usa grupos globais. Se implementar todas as funções e grupos organizacionais através de grupos universais, basta uma única instância da GCDS. Caso contrário, precisa de uma instância da GCDS por domínio.

Mapeie identidades de grupos

O mapeamento de grupos de segurança do Active Directory para grupos do Cloud ID ou do Google Workspace requer um identificador comum. No Cloud ID e no Google Workspace, este identificador tem de ser um endereço de email cuja parte do domínio corresponda a um domínio principal, secundário ou alias da conta do Cloud ID ou do Google Workspace. Uma vez que este endereço de email vai ser usado em todo o Google Cloud, o endereço tem de ser legível. O endereço de email não tem de corresponder a uma caixa de correio.

No Active Directory, os grupos são identificados pelo respetivo nome comum (cn) ou por um nome de início de sessão anterior ao Windows 2000 (sAMAccountName). Semelhante às contas de utilizador, os grupos também podem ter um endereço de email (mail), mas os endereços de email são um atributo opcional para os grupos, e o Active Directory não verifica a unicidade.

Tem duas opções para mapear identidades de grupos entre o Active Directory e o Cloud ID ou o Google Workspace.

Mapeie por nome comum

A vantagem de usar o nome comum (cn) é que está garantido que está disponível e, pelo menos numa unidade organizacional, é exclusivo. No entanto, o nome comum não é um endereço de email, pelo que precisa de um sufixo @DOMAIN anexado para se tornar um endereço de email.

Pode configurar o GCDS para tratar automaticamente da anexação de um sufixo ao nome do grupo. Uma vez que o Active Directory garante que os nomes dos grupos e os nomes dos utilizadores não entram em conflito, é também pouco provável que um endereço de email derivado desta forma cause conflitos.

Se a sua floresta do Active Directory contiver mais do que um único domínio, aplicam-se as seguintes ressalvas:

• Se dois grupos em domínios diferentes partilharem um nome comum, o endereço de email derivado vai entrar em conflito, o que faz com que um grupo seja ignorado durante a sincronização.
• Só pode sincronizar grupos de domínios de uma única floresta. Se sincronizar grupos de várias florestas através de instâncias separadas do GCDS, os endereços de email derivados do nome comum não refletem a floresta à qual correspondem. Esta ambiguidade faz com que uma instância do GCDS elimine qualquer grupo que tenha sido criado anteriormente a partir de uma floresta diferente por outra instância do GCDS.
• Não pode mapear grupos por nome comum se usar a substituição de domínio para mapear utilizadores.

Mapeie por endereço de email

A utilização do endereço de email (mail) para mapear identidades de grupos significa que tem de cumprir os mesmos critérios que quando utiliza o endereço de email para mapear utilizadores:

• As atribuições de email têm de estar concluídas. Embora seja comum os grupos de distribuição terem um endereço de email, os grupos de segurança não costumam ter este atributo. Para usar o endereço de email para mapear identidades, os grupos de segurança sujeitos à sincronização têm de ter o campo mail preenchido. O seguinte comando do PowerShell pode ajudar a encontrar contas para as quais este campo não está preenchido:

  Get-ADGroup -LDAPFilter "(!mail=*)"

• Os endereços de email têm de usar um conjunto selecionado de domínios, todos pertencentes a si. Se alguns dos seus utilizadores usarem endereços de email que se referem a empresas parceiras ou fornecedores de email de consumidores, não pode usar esses endereços.

• Todos os endereços de email têm de ser exclusivos na floresta. Uma vez que o Active Directory não aplica a exclusividade, pode ter de implementar verificações ou políticas personalizadas.

Se todos os grupos relevantes cumprirem estes critérios, pode identificar todos os domínios que são usados por estes endereços de email e garantir que a lista de domínios DNS registados no Cloud Identity ou no Google Workspace abrange estes domínios.

Se um dos critérios não for cumprido, ainda pode mapear UPNs para endereços de email do Cloud Identity ou do Google Workspace, com as seguintes ressalvas:

• Os grupos sem endereços de email são ignorados durante a sincronização, bem como os endereços de email que usam domínios não associados à conta do Cloud ID ou do Google Workspace.
• Quando dois grupos partilham o mesmo endereço de email, apenas um deles é sincronizado.

O mapeamento de grupos por endereço de email não é suportado se a floresta do Active Directory contiver mais do que um único domínio e usar a substituição de domínio para mapear utilizadores.

Mapeie unidades organizacionais

A maioria dos domínios do Active Directory usa extensivamente unidades organizacionais para agrupar e organizar recursos hierarquicamente, controlar o acesso e aplicar políticas.

Nas Google Cloud, pastas e projetos têm um objetivo semelhante, embora os tipos de recursos geridos numa Google Cloud organização sejam muito diferentes dos recursos geridos no Active Directory. Como resultado, uma hierarquia de pastas adequada para uma empresa tende a diferir significativamente da estrutura das unidades organizacionais no Active Directory. Google CloudPor conseguinte, o mapeamento automático de unidades organizacionais para pastas e projetos raramente é prático e não é suportado pelo GCDS.

Não relacionado com pastas, o Cloud ID e o Google Workspace suportam o conceito de unidades organizacionais. As unidades organizacionais são criadas para agrupar e organizar os utilizadores, de forma semelhante ao Active Directory. No entanto, ao contrário do Active Directory, aplicam-se apenas aos utilizadores e não aos grupos.

O GCDS oferece a opção de sincronizar unidades organizacionais do Active Directory com o Cloud ID ou o Google Workspace. Numa configuração em que o Cloud Identity é usado apenas para estender a gestão de identidades do Active Directory para Google Cloud, o mapeamento de unidades organizacionais geralmente não é necessário.

Escolha o mapeamento certo

Conforme indicado no início deste documento, não existe uma única melhor forma de mapear as estruturas do Active Directory e do Google Cloud. Para ajudar a escolher o mapeamento certo para o seu cenário, os seguintes gráficos de decisão resumem os critérios abordados nas secções anteriores.

Primeiro, consulte o gráfico seguinte para identificar quantas contas do Cloud Identity ou do Google Workspace, instâncias do GCDS e instâncias ou frotas do AD FS precisa.

Em seguida, consulte o segundo gráfico para identificar os domínios a configurar na sua conta do Cloud Identity ou do Google Workspace.

O que se segue?

• Leia acerca das práticas recomendadas para planear contas e organizações e das práticas recomendadas para federar Google Cloud com um fornecedor de identidade externo.
• Configure o GCDS para sincronizar utilizadores e grupos do Active Directory com o Cloud ID.
• Configure o Início de sessão único entre o Active Directory e o Google Cloud.
• Saiba mais sobre as práticas recomendadas para gerir contas de superadministrador