Como federar o Google Cloud com o Active Directory: introdução

Este artigo é a primeira parte de uma série que mostra como estender uma solução atual de gerenciamento de identidade baseada no Active Directory para o Google Cloud. Neste artigo, descrevemos como estabelecer mecanismos de autenticação e autorização consistentes em um ambiente de computação híbrida. O conteúdo do artigo se concentra no uso do Cloud Identity, embora algumas das discussões se apliquem ao G Suite.

A série contém estas partes:

Os departamentos de TI das empresas geralmente dependem do Active Directory para gerenciar contas de usuários e controlar o acesso a aplicativos e recursos de computação. Essa confiança faz do Active Directory uma das bases do cenário de TI e da infraestrutura local dessas empresas.

Ao estender seu cenário de TI ao Google Cloud como parte de uma estratégia híbrida, convém manter apenas um ponto em que as identidades são gerenciadas. Ter apenas uma solução de gerenciamento de identidades minimiza o esforço administrativo e ajuda a garantir que usuários e aplicativos sejam autenticados com segurança em um ambiente híbrido.

Neste artigo, comparamos as estruturas lógicas do Active Directory e do GCP e mostramos maneiras de associar contas do Active Directory a contas de usuários e de grupos no GCP para implementar a federação. No final do artigo, um fluxograma ajuda a determinar a melhor abordagem para sua realidade para o mapeamento entre o Active Directory e o GCP.

Neste artigo, pressupomos que você esteja familiarizado com o Active Directory.

Como implementar a federação

O Google Cloud usa identidades do Google para autenticação e gerenciamento de acesso. Para acessar qualquer recurso do Google Cloud, um funcionário precisa ter uma identidade do Google. Manter as identidades do Google para cada funcionário de forma manual seria complicado se todos os funcionários já tivessem uma conta no Active Directory. Ao federar identidades de usuários entre o Active Directory e o Google Cloud, é possível automatizar a manutenção de contas do Google e vincular o ciclo de vida delas às contas no Active Directory. A federação ajuda a garantir que:

  • o Active Directory continue a ser o único lugar confiável para o gerenciamento de identidades;
  • uma Conta do Google seja criada automaticamente para todas as contas de usuário no Active Directory ou para um subconjunto selecionado;
  • caso uma conta seja desativada ou excluída no Active Directory, a Conta do Google correspondente também seja suspensa ou excluída. Por outro lado, suspender ou excluir uma Conta do Google não afeta o Active Directory, porque a Conta do Google será recriada automaticamente durante a próxima sincronização;
  • o Active Directory processe a autenticação do usuário para que você não precise sincronizar senhas com o Google Cloud.

No Google, use o Cloud Identity para configurar um diretório de conta de usuário particular para criar e gerenciar Contas do Google. Portanto, federar o Active Directory com o Cloud Identity envolve dois elementos:

Federar o Active Directory com o Cloud Identity

  • Sincronização de contas: contas de usuários e grupos relevantes são sincronizados periodicamente do Active Directory para o Cloud Identity. Esse processo garante que, ao criar uma nova conta no Active Directory, ela possa ser referenciada no Google Cloud antes mesmo de o usuário associado fazer login pela primeira vez. Esse processo também garante que as remoções de contas sejam propagadas.

    A sincronização é unidirecional, o que significa que as alterações no Active Directory são replicadas para o Cloud Identity, mas que o contrário não ocorre. Além disso, a sincronização não inclui senhas. Em uma configuração federada, o Active Directory continua sendo o único sistema que gerencia essas credenciais.

  • Logon único: sempre que um usuário precisa se autenticar no Google Cloud, o Cloud Identity delega a autenticação ao Active Directory usando o protocolo SAML (Linguagem de marcação para autorização de segurança). Essa delegação garante que somente o Active Directory gerencie as credenciais do usuário e que as políticas ou os mecanismos de autenticação multifator (MFA) sejam aplicados. Para que um login seja bem-sucedido, no entanto, a respectiva conta precisa ter sido previamente sincronizada.

As seguintes ferramentas podem ser usadas para implementar a federação:

  • O Google Cloud Directory Sync é uma ferramenta gratuita fornecida pelo Google que implementa o processo de sincronização. O Cloud Directory Sync se comunica com o Cloud Identity via SSL (Secure Sockets Layer) e geralmente é executado no ambiente de computação atual.
  • Os Serviços de Federação do Active Directory (AD FS) são fornecidos pela Microsoft como parte do Windows Server. Essa ferramenta permite o uso do Active Directory para autenticação federada. O AD FS geralmente é executado no ambiente de computação atual.

Como as APIs do Cloud Identity estão disponíveis publicamente e o SAML é um padrão aberto, muitas ferramentas estão disponíveis para implementar a federação. Neste artigo, nos concentramos no uso do Cloud Directory Sync e do AD FS.

Estrutura lógica do Active Directory

Em uma infraestrutura do Active Directory, o componente de nível superior é a floresta. A floresta serve como um contêiner para um ou mais domínios e deriva o próprio nome do domínio raiz dela. Os domínios em uma floresta do Active Directory confiam uns nos outros, permitindo que usuários autenticados em um domínio acessem recursos que estão em outro domínio. A menos que as florestas estejam conectadas usando relações de confiança entre elas, florestas separadas não confiam umas nas outras por padrão, e usuários autenticados em uma não podem acessar recursos que estão em outra.

Infraestrutura do Active Directory

Os domínios do Active Directory são contêineres para o gerenciamento de recursos e são considerados limites administrativos. Ter vários domínios em uma floresta é uma maneira de simplificar a administração ou de aplicar estrutura extra, mas os domínios em uma floresta não representam limites de segurança.

Estrutura lógica do Google Cloud

No Google Cloud, você gerencia recursos em organizações, que podem ser ainda mais segmentadas com o uso de pastas e projetos. Organizações, pastas e projetos, portanto, servem a um propósito semelhante aos domínios do Active Directory.

O Active Directory trata as contas de usuários como recursos e, portanto, o gerenciamento e a autenticação de contas de usuários estão vinculados a domínios. Por outro lado, o Google Cloud não gerencia contas de usuário em uma organização, exceto para contas de serviço. Em vez disso, o Google Cloud depende do Cloud Identity ou do G Suite para gerenciar contas de usuários.

O Cloud Identity permite criar e gerenciar diretórios particulares para contas e grupos de usuários. Cada um desses diretórios é gerenciado de forma independente. Eles podem, por exemplo, apresentar diferenças com relação aos métodos de autenticação permitidos ou às políticas de senha aplicadas. No Cloud Identity, os diretórios são chamados de contas do Cloud Identity e são identificados por nomes de domínio.

Infraestrutura de identidade do GCP

Assim como uma floresta e um domínio raiz de floresta sempre são criados em conjunto no Active Directory, uma conta do Cloud Identity é sempre criada em paralelo com uma organização do Google Cloud. Assim como a floresta e o domínio raiz dela compartilham o mesmo nome e não podem ser desanexados, a conta do Cloud Identity e a organização do Google Cloud compartilham o mesmo nome e estão vinculadas entre si. No entanto, uma organização do Google Cloud pode se referir a usuários e grupos de outras contas do Cloud Identity.

Como integrar o Active Directory e o Google Cloud

Há certas semelhanças entre a estrutura lógica do Active Directory e do Google Cloud, mas nenhum mapeamento único entre as duas estruturas funciona igualmente bem em todos os cenários. Na verdade, a abordagem correta para integrar os dois sistemas e mapear a estrutura depende de vários fatores:

  • Como associar domínios e florestas a contas do Cloud Identity
  • Como mapear domínios DNS
  • Como mapear contas de usuários
  • Como mapear grupos

As seções a seguir analisam cada um desses pontos.

Como mapear florestas

É comum, especialmente em organizações maiores, o uso de mais de um domínio do Active Directory para gerenciar as identidades e os acessos de toda a empresa. Quando você planeja federar o Active Directory e o Google Cloud, o primeiro fator a ser considerado é a topologia da infraestrutura do Active Directory.

Floresta única, domínio único

Floresta única, domínio único

Quando uma floresta inclui apenas um domínio, é possível associar toda a floresta do Active Directory a uma conta do Cloud Identity. Essa conta fornece a base para uma organização do Google Cloud, que é possível usar para gerenciar seus recursos do Google Cloud.

Em um ambiente de domínio único, os controladores de domínio e os servidores de catálogo global fornecem acesso a todos os objetos gerenciados no Active Directory. Na maioria dos casos, é possível executar apenas uma instância do Cloud Directory Sync para sincronizar contas e grupos de usuários com o Google Cloud e manter uma instância ou frota do AD FS para lidar com o Logon único.

Floresta única, vários domínios

Floresta única, vários domínios

Quando uma floresta contém vários domínios do Active Directory, é possível organizá-los em uma ou mais árvores de domínio. Nos dois casos é possível associar toda a floresta a uma conta do Cloud Identity. Essa conta fornece a base para uma organização do Google Cloud, que é possível usar para gerenciar seus recursos do Google Cloud.

Em um ambiente com vários domínios, há uma diferença entre quais informações podem ser recuperadas de um controlador de domínio e quais podem ser consultadas em um servidor de catálogo global. Embora os controladores de domínio exibam dados apenas do domínio local, os servidores de catálogo global fornecem acesso a informações de todos os domínios da floresta. Os dados que são exibidos por servidores de catálogo global são parciais e não têm determinados atributos LDAP. Essa limitação pode afetar a forma como o Cloud Directory Sync é configurado para sincronizar grupos.

Dependendo de como você planeja mapear grupos, a federação de uma floresta de vários domínios com o Google Cloud requer uma ou mais instâncias do Cloud Directory Sync, mas apenas uma instância ou frota do AD FS para lidar com o Logon único.

Várias florestas com relação de confiança entre si

Várias florestas com relação de confiança entre si

Em organizações maiores, não é incomum haver mais de uma floresta do Active Directory, geralmente como resultado de uma fusão ou de uma aquisição. É possível combinar essas florestas usando uma confiança entre florestas bidirecional para que os usuários possam compartilhar e acessar recursos através dos limites de uma única floresta.

Se todas as florestas tiverem uma relação de confiança bidirecional com outra floresta, será possível associar todo o ambiente a uma conta do Cloud Identity. Essa conta fornece a base para uma organização do Google Cloud, que pode ser usada para gerenciar seus recursos do Google Cloud.

Embora os servidores de catálogo global forneçam acesso a dados de vários domínios, o escopo deles é limitado a uma floresta. Portanto, em um ambiente de várias florestas, você precisa consultar vários controladores de domínio ou servidores de catálogo global para receber, por exemplo, uma lista completa de contas de usuários. Como resultado dessa limitação, a federação de um ambiente de várias florestas com o Google Cloud requer pelo menos uma instância do Cloud Directory Sync por floresta. As relações de confiança entre florestas permitem que a autenticação do usuário funcione além dos limites da floresta. Portanto, uma instância ou frota do AD FS é suficiente para lidar com o Logon único.

Se o ambiente abranger várias florestas sem confiança entre florestas, mas todos os domínios do Active Directory relevantes para federação com o Google Cloud estiverem conectados por meio de relações de confiança externas, as mesmas considerações serão aplicáveis.

Várias florestas sem relação de confiança entre si

Várias florestas sem relação de confiança entre si

No ambiente ilustrado aqui, não é possível autenticar nem acessar recursos além dos limites da floresta. Também não é possível que uma única instância ou frota do AD FS processe solicitações de logon único para usuários de todas as florestas.

Portanto, não é possível associar florestas múltiplas que não tenham relações de confiança entre si a uma única conta do Cloud Identity. Em vez disso, cada floresta precisa ser associada a uma conta separada do Cloud Identity, o que envolve a execução de pelo menos uma instância do Cloud Directory Sync e um servidor ou frota do AD FS por floresta.

No Google Cloud, é criada uma organização separada para cada conta do Cloud Identity. Não é preciso, na maioria dos casos, manter várias organizações independentes. Uma das organizações pode ser selecionada e associada a outras contas do Cloud Identity, criando efetivamente uma organização federada com várias florestas do Active Directory. As outras organizações continuam sem uso.

Como mapear domínios DNS

O DNS desempenha um papel crucial, tanto no Active Directory quanto no Cloud Identity. O segundo fator a ser analisado quando você planeja federar o Active Directory e o Google Cloud é como compartilhar ou mapear domínios DNS entre o Active Directory e o Google Cloud.

Uso de domínios DNS no Active Directory

Em uma floresta do Active Directory, os domínios DNS são usados em vários lugares:

  • Domínios DNS do Active Directory: cada domínio do Active Directory corresponde a um domínio DNS. Esse 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 e-mails (MX, na sigla em inglês): os endereços de e-mail usam um domínio DNS. Em alguns casos, esse domínio é igual ao domínio DNS do Active Directory, mas, em muitos casos, é usado um domínio diferente, geralmente mais curto, como example.com. O ideal é que as contas de usuário no Active Directory tenham o endereço de e-mail associado ao atributo opcional mail.
  • Domínios de sufixo UPN: esses domínios são usados para Nomes principais do usuário (UPN, na sigla em inglês). Por padrão, o domínio DNS do Active Directory do domínio da conta é usado para criar um UPN. Portanto, para um usuário john no domínio corp.example.com, o UPN padrão seria john@corp.example.com. No entanto, é possível configurar uma floresta para usar outros domínios DNS como sufixos UPN que não correspondam aos domínios DNS do Active Directory nem aos domínios MX. UPNs são opcionais e são armazenados no campo userPrincipalName da conta de usuário.
  • Domínios de endpoint: servidores públicos, como os servidores do AD FS, geralmente recebem um nome DNS, como login.external.example.com. O domínio usado para essas finalidades pode se sobrepor ao MX, ao sufixo UPN ou ao domínio DNS do Active Directory ou pode ser um domínio totalmente diferente.

Uso de domínios DNS no Google Cloud

O Login do Google, do qual o Google Cloud depende para autenticação, usa endereços de e-mail para identificar usuários. O uso de endereços de e-mail não só garante que eles sejam exclusivos globalmente, como também permite que o Google Cloud envie mensagens de notificação para os endereços.

O Login do Google determina o diretório ou o provedor de identidade a ser usado para autenticar um usuário com base na parte do domínio dos endereços de e-mail, que segue o caractere @. Para um endereço de e-mail que usa o domínio gmail.com, por exemplo, o Login do Google usa o diretório de contas de usuário do Gmail para autenticação.

Uso de domínios DNS no GCP

Ao se inscrever em uma conta do G Suite ou do Cloud Identity, você está essencialmente criando um diretório particular que o Google Identity Platform pode usar para autenticação. Da mesma forma que o diretório do Gmail é associado ao domínio gmail.com, as contas do G Suite e do Cloud Identity precisam ser associadas a um domínio personalizado. Três tipos diferentes de domínios são usados:

  • Domínio principal: esse domínio identifica o diretório do Cloud Identity e também é usado como o nome da organização no Google Cloud. Ao se inscrever no Cloud Identity, você precisa especificar esse nome de domínio.
  • Domínio secundário: além do domínio principal, é possível associar outros domínios secundários a um diretório do Cloud Identity. Todas as contas no diretório são associadas ao domínio principal ou a um dos domínios secundários. Duas contas, johndoe@example.com e johndoe@secondary.example.com, serão consideradas contas separadas se example.com for o domínio principal e secondary.example.com for o domínio secundário de um diretório.
  • Domínio de alias: um domínio de alias é um domínio alternativo para o domínio principal. Ou seja, johndoe@example.com e johndoe@alias.example.com farão referência à mesma conta se alias.example.com estiver configurado como um domínio de alias. Um domínio de alias pode fornecer um nome alternativo apenas para o domínio principal. Não é possível adicionar domínios de alias para domínios secundários.

Todos os domínios precisam atender aos requisitos a seguir:

  • Precisam ser nomes de domínio DNS válidos e globais. Nomes de domínio locais, como corp.local ou corp.internal, como normalmente usados no Active Directory, não são permitidos. Durante a configuração, pode ser necessário acesso administrativo às respectivas zonas DNS para verificar a propriedade do domínio.
  • Um domínio, como example.com, só pode se referir a um diretório. No entanto, é possível usar subdomínios diferentes, como subdomain.example.com, para referenciar diferentes diretórios.
  • Domínios principais e secundários precisam ter registros MX válidos. Dessa maneira, as mensagens enviadas para endereços de e-mail que são formados usando esse nome de domínio podem ser entregues corretamente.

Para permitir a sincronização entre os diretórios, é necessário algum nível de mapeamento entre os domínios do Active Directory e os domínios usados pelo Cloud Identity. A definição da forma mais apropriada de mapeamento depende de como o Active Directory é usado e exige uma análise mais detalhada sobre a forma como as contas de usuário são identificadas em uma floresta do Active Directory e como elas podem ser associadas ao Cloud Identity.

Como mapear contas de usuários

O terceiro fator a ser considerado ao planejar a federação do Active Directory e do Google Cloud é como mapear contas de usuários entre o Active Directory e o Cloud Identity.

Como identificar contas de usuários no Active Directory

Internamente, o Active Directory usa dois identificadores para identificar contas de usuários de maneira exclusiva:

  • objectGUID: esse ID globalmente exclusivo é gerado quando um usuário é criado e nunca é alterado.
  • objectSID: o SID, ou identificador de segurança, é usado para todas as verificações de acesso. Embora esse ID seja único e estável em um domínio, é possível que, quando uma conta for movida para um domínio diferente na floresta, ela receba um novo SID.

Nenhum desses IDs é relevante para os usuários. Assim, o Active Directory oferece duas maneiras fáceis de identificar as contas de usuários:

  • UPN (userPrincipalName): a maneira preferencial de identificar uma conta de usuário é por UPN. Os UPNs seguem o formato RFC 822 de endereços de e-mail e são criados por meio da combinação do nome do usuário com um domínio de sufixo UPN, como em johndoe@corp.example.com. Embora esta seja a maneira preferida para identificar contas de usuário, os UPNs são opcionais. Portanto, algumas contas de usuário na floresta do Active Directory podem não ter um UPN.

    Embora seja considerado uma prática recomendada que os UPNs sejam endereços de e-mail válidos, o Active Directory não impõe essa prática.

  • Nome de logon anterior ao Windows 2000 (sAMAccountName): esse nome combina o nome de domínio NetBIOS e o nome de usuário usando o formato domain\user, como em corp\johndoe. Embora esses nomes sejam considerados legados, eles ainda são comumente usados e são o único identificador obrigatório de uma conta de usuário.

O Active Directory não usa o endereço de e-mail do usuário (mail) para identificar usuários. Consequentemente, esse campo não é obrigatório nem precisa ser exclusivo em uma floresta.

Todos esses identificadores podem ser alterados a qualquer momento.

Como mapear identidades de conta

A associação de contas do Active Directory a contas do Cloud Identity exige duas informações para cada conta de usuário:

  • Um ID único e estável que pode ser usado durante a sincronização para rastrear qual conta do Active Directory corresponde a qual conta do Cloud Identity. No lado do AD, o objectGUID é perfeitamente adequado para essa finalidade.
  • Um endereço de e-mail em que a parte do domínio corresponde a um domínio principal, secundário ou de alias do Cloud Identity. Como esse endereço de e-mail será usado em todo o Google Cloud, certifique-se de que ele seja significativo. Não é prático derivar um endereço de objectGUID como é o caso com outros endereços de e-mail gerados automaticamente.

Em uma conta de usuário do Active Directory, dois campos são candidatos a fornecer um endereço de e-mail do Cloud Identity: userPrincipalName e mail.

Como mapear a partir do nome principal do usuário

O uso do campo userPrincipalName requer que dois critérios sejam atendidos para todas as contas sujeitas a sincronização:

  • Os UPNs precisam ser endereços de e-mail válidos. Todos os domínios usados como domínios de sufixo UPN também precisam ser domínios MX e precisam ser configurados para que um e-mail enviado para o UPN de um usuário seja entregue em sua caixa de entrada.
  • As atribuições UPN precisam estar completas. Todas as contas de usuário sujeitas a sincronização precisam ter um UPN atribuído. O seguinte comando do PowerShell pode ser útil para encontrar contas sem um UPN:

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

Se esses dois critérios forem atendidos, será possível associar UPNs aos endereços de e-mail do Cloud Identity com segurança. É possível usar um dos domínios de sufixo UPN como o domínio principal no Cloud Identity e adicionar outros domínios de sufixo UPN como domínios secundários.

Se um dos critérios não for atendido, ainda será possível associar os UPNs aos endereços de e-mail do Cloud Identity, mas as seguintes advertências se aplicam:

  • Se os UPNs não forem endereços de e-mail válidos, os usuários talvez não recebam e-mails de notificação enviados pelo Google Cloud, o que pode fazer com que eles percam informações importantes.
  • Contas sem UPNs serão ignoradas durante a sincronização.
  • É possível configurar a sincronização para que o domínio de sufixo UPN seja substituído por um domínio diferente. Quando vários domínios de sufixo UPN estão sendo usados em uma floresta, isso pode criar duplicatas, porque todos os domínios de sufixo UPN serão substituídos por um único domínio. No caso de duplicatas, apenas uma única conta pode ser sincronizada.

Uma grande vantagem do uso de UPNs para mapear usuários é que eles têm a garantia de serem exclusivos em uma floresta e usam um conjunto selecionado de domínios, o que ajuda a evitar possíveis problemas de sincronização.

Como mapear por endereço de e-mail

Para usar o campo mail, é necessário atender aos seguintes critérios para todas as contas sujeitas a sincronização:

  • As atribuições de e-mail precisam estar completas. Todas as contas de usuário sujeitas a sincronização precisam ter o campo mail preenchido. O seguinte comando do PowerShell pode ser útil para encontrar contas em que esse campo não esteja preenchido:

    Get-ADUser -LDAPFilter "(!mail=*)"
  • Os endereços de e-mail precisam usar um conjunto selecionado de domínios, todos pertencentes a você. Se algumas de suas contas usarem endereços de e-mail que se refiram a empresas parceiras ou provedores de e-mail de clientes, esses endereços não poderão ser usados.

  • Todos os endereços de e-mail precisam ser exclusivos na floresta. Como o Active Directory não impõe exclusividade, talvez seja preciso implementar verificações ou políticas personalizadas.

Se todas as contas relevantes atenderem a esses critérios, será possível identificar todos os domínios usados por esses endereços de e-mail e usá-los como domínios principais e secundários no Cloud Identity.

Se um desses critérios não for atendido, você ainda assim pode mapear os endereços de e-mail para endereços de e-mail do Cloud Identity, com as ressalvas a seguir:

  • Durante a sincronização, as contas sem endereços de e-mail serão ignoradas, assim como as contas com endereços de e-mail que usam domínios que não estejam associados ao diretório do Cloud Identity.
  • Quando duas contas compartilharem o mesmo endereço de e-mail, apenas uma delas será sincronizada.
  • É possível configurar a sincronização para substituir o domínio de endereços de e-mail por um domínio diferente. Esse processo pode criar duplicatas e, nesse caso, apenas uma conta será sincronizada.

Como mapear grupos

O quarto fator a ser analisado quando você planeja federar o Active Directory e o Google Cloud é se os grupos serão sincronizados entre o Active Directory e o Google Cloud.

No Google Cloud, os grupos são normalmente usados como uma maneira de gerenciar o acesso de forma eficiente em projetos. Em vez de atribuir usuários individuais a papéis do Cloud Identity and Access Management (Cloud IAM) em cada projeto, é possível definir um conjunto de grupos que modelam papéis comuns em sua organização e, em seguida, atribuir esses grupos a um conjunto de papéis do Cloud IAM. Ao modificar a associação dos grupos, é possível controlar o acesso dos usuários a todo um conjunto de recursos.

O Active Directory diferencia dois tipos de grupos: grupos de distribuição e grupos de segurança. Grupos de distribuição são usados para gerenciar listas de e-mail. A sincronização de grupos de distribuição é relevante na migração do Microsoft Exchange para o G Suite. Assim, o Cloud Directory Sync pode lidar tanto com grupos de distribuição regulares quanto com grupos dinâmicos. No entanto, grupos de distribuição não são uma preocupação no gerenciamento de identidade e acesso do Google Cloud. Portanto, essa discussão se concentra exclusivamente em grupos de segurança.

O mapeamento de grupos de segurança entre o Active Directory e o Google Cloud é opcional. Após as contas de usuários serem federadas, será possível criar e gerenciar grupos diretamente no Cloud Identity. Isso significa que o Active Directory continua sendo o sistema central para o gerenciamento de identidades, mas não para o gerenciamento de acesso. Para manter o Active Directory como o sistema central de gerenciamento de identidades e gerenciamento de acesso, recomendamos que seja feita a sincronização dos grupos de segurança do Active Directory em vez de gerenciá-los no Cloud Identity. Com essa abordagem, é possível configurar o Cloud IAM para usar as associações a 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 no gerenciamento de acesso ao Active Directory. Esse papel é facilitado por três tipos diferentes de grupos do Active Directory: grupos de domínio local, grupos globais e grupos universais.

Grupos de segurança no AD

Grupos de domínio local
Esses grupos são relevantes apenas no escopo de um domínio e não podem ser referenciados em outros domínios. Como a lista de membros não precisa ser replicada na floresta, os grupos de domínio local são os mais flexíveis em relação aos tipos de membros que podem incluir.
Grupos globais
Esses grupos são exibidos em outros domínios e podem ser referenciados nesses domínios. No entanto, a lista de membros desses grupos não é replicada. Essa limitação restringe os tipos de membros que podem ser incluídos nesses grupos. Eles podem incluir apenas contas de usuários e outros grupos globais do mesmo domínio.
Grupos universais
Esses grupos, assim como suas listas de membros, são replicados na floresta. Eles podem, portanto, ser referenciados em outros domínios e podem incluir não apenas contas de usuários e outros grupos universais, mas também grupos globais de todos os domínios.

Se uma floresta do Active Directory contiver apenas um único domínio, será possível sincronizar todos os três tipos de grupos de segurança usando o Cloud Directory Sync. Se uma floresta do Active Directory usar mais de um domínio, o tipo de um grupo determinará se ele pode ser sincronizado com o Cloud Identity e como isso pode ser feito.

Como os grupos de domínio local e os grupos globais não são totalmente replicados na floresta, os servidores de catálogo global contêm informações incompletas sobre eles. Embora essa limitação seja deliberada e ajude a acelerar a replicação de diretórios, representa um obstáculo quando se quer sincronizar esses grupos com o Cloud Identity. Especificamente, se você configurar o Cloud Directory Sync para usar um servidor de catálogo global como origem, a ferramenta poderá encontrar grupos de todos os domínios em toda a floresta. Porém, apenas os grupos que estiverem no mesmo domínio que o servidor de catálogo global conterão uma lista de associação e serão adequados para replicação. Para sincronizar grupos de domínio local ou grupos globais em uma floresta com vários domínios, é preciso executar uma instância separada do Cloud Directory Sync por domínio.

Como os grupos universais são totalmente replicados na floresta, eles não têm essa restrição. Uma única instância do Cloud Directory Sync pode sincronizar grupos universais de vários domínios.

Antes de concluir que você precisa de várias instâncias do Cloud Directory Sync para sincronizar vários domínios do Active Directory com o Cloud Identity, lembre-se de que nem todos os grupos precisam ser sincronizados. Por esse motivo, vale a pena observar como tipos diferentes de grupos de segurança são normalmente usados na floresta do Active Directory.

Uso de grupos de segurança no Active Directory

Grupos de recursos

O Windows usa um modelo de acesso baseado em listas de controle de acesso (ACLs, na sigla em inglês). Cada recurso, como um arquivo ou objeto LDAP, tem uma ACL associada que controla quais usuários têm acesso a ele. Recursos e ACLs são muito detalhados, então existem muitos deles. Para simplificar a manutenção de ACLs, é comum criar grupos de recursos para reunir recursos que costumam ser usados e acessados juntos. O grupo de recursos é adicionado uma vez a todas as ACLs afetadas e isso permite gerenciar o acesso extra ao alterar a associação do grupo de recursos, e não ao alterar as ACLs.

Os recursos que são agrupados dessa forma normalmente residem em um único domínio. Consequentemente, um grupo de recursos também tende a ser referenciado apenas em um único domínio, seja em ACLs ou por outros grupos de recursos. Como a maioria dos grupos de recursos é local, eles geralmente são implementados usando grupos de domínio local no Active Directory.

Grupos de papéis e de organizações

Grupos de recursos ajudam a simplificar o gerenciamento de acesso, mas em um ambiente grande pode ser preciso adicionar um novo usuário a um grande número de grupos de recursos. Por esse motivo, os grupos de recursos geralmente são complementados por grupos de papéis ou por grupos de organizações.

Os grupos de papéis agregam as permissões que um papel específico exige na organização. Um grupo de papéis denominado Leitor de Documentação de Engenharia, por exemplo, pode conceder aos membros acesso somente leitura a toda documentação de engenharia. Na prática, isso seria implementado criando um grupo de papéis e tornando esse grupo membro de todos os grupos de recursos usados para controlar o acesso a vários tipos de documentação.

De maneira semelhante, os grupos de organizações agregam as permissões exigidas pelos departamentos de uma organização. Por exemplo, um grupo de organizações denominado Engenharia pode conceder acesso a todos os recursos que os membros do departamento de engenharia normalmente exigem.

Tecnicamente, não há diferença entre grupos de papéis e grupos de recursos, e ambos são geralmente usados em conjunto. Diferentemente dos grupos de recursos, no entanto, grupos de papéis e de organizações podem ter relevância além dos limites de um domínio. Para permitir que esses grupos sejam referenciados por grupos de recursos em outros domínios, grupos de papéis e de organizações geralmente são implementados usando grupos globais, que são restritos a membros de um único domínio e, às vezes, complementados por grupos universais, que permitem membros de domínios diferentes.

O diagrama a seguir mostra um padrão de aninhamento usado com frequência em ambientes do Active Directory com vários domínios.

Padrão de aninhamento usado em ambientes AD de vários domínios

Grupos no Cloud Identity

No Cloud Identity, há apenas um único tipo de grupo, que se comporta de maneira semelhante aos grupos universais no Active Directory. Ou seja, os grupos não estão restritos ao escopo da conta do Cloud Identity em que foram definidos. Em vez disso, os grupos podem incluir contas de usuários de diferentes contas do Cloud Identity. Esses grupos podem ser referenciados e aninhados em outras contas do Cloud Identity e podem ser usados em qualquer organização do Google Cloud.

Ao contrário dos grupos do Active Directory, os membros de um grupo do Cloud Identity não recebem permissão implícita para listar outros membros do mesmo grupo. Em vez disso, consultar a associação a um grupo geralmente exige autorização explícita.

Uso de grupos no Google Cloud

O Google Cloud usa um modelo de acesso baseado em papéis em vez de um modelo de acesso baseado em ACL. Os papéis se aplicam a todos os recursos de um determinado tipo que se enquadram em um determinado escopo. Por exemplo, o papel de Desenvolvedor do Kubernetes Engine tem acesso total aos objetos da API Kubernetes dentro de todos os clusters em um determinado projeto. Devido à natureza dos papéis, há pouca necessidade de manter grupos de recursos no Google Cloud, e raramente é necessário sincronizar grupos de recursos com o Google Cloud.

Grupos de papéis e grupos de organizações são tão relevantes no Google Cloud quanto no Active Directory porque facilitam o gerenciamento do acesso para um grande número de usuários. A sincronização de grupos de papéis e de organizações ajuda a manter o Active Directory como o local principal para gerenciar o acesso.

Como sincronizar papéis e grupos de organizações

Se grupos de recursos forem consistentemente implementados como grupos de domínio local e se grupos de papéis e de organizações forem implementados como grupos globais ou universais, será possível usar o tipo de grupo para garantir que apenas grupos de papéis e de organizações sejam sincronizados.

A questão de se é suficiente executar uma única instância do Cloud Directory Sync por floresta de vários domínios ou se são necessárias várias instâncias do Cloud Directory Sync torna-se assim a questão do uso de grupos globais. Se todos os seus grupos de papéis e de organizações forem implementados usando grupos universais, uma única instância do Cloud Directory Sync será suficiente. Caso contrário, você precisará de uma instância do Cloud Directory Sync por domínio.

Como mapear identidades de grupos

A associação de grupos de segurança do Active Directory a grupos do Cloud Identity exige um identificador comum. No Cloud Identity, esse identificador precisa ser um endereço de e-mail para que a parte do domínio corresponda a um domínio principal, secundário ou de alias do Cloud Identity. Como esse endereço de e-mail será usado em todo o Google Cloud, ele precisa ser legível. O endereço de e-mail não precisa corresponder a uma caixa de correio.

No Active Directory, os grupos são identificados pelo nome comum (cn) ou por um nome de logon anterior ao Windows 2000 (sAMAccountName). Assim como contas de usuário, grupos também podem ter endereços de e-mail (mail), mas estes são um atributo opcional para grupos, e o Active Directory não verifica a exclusividade.

Há duas opções para mapear identidades de grupo entre o Active Directory e o Cloud Identity.

Como mapear por nome comum

A vantagem de usar o nome comum (cn) é que ele está disponível e, pelo menos, dentro de uma unidade organizacional, é exclusivo. No entanto, o nome comum não é um endereço de e-mail. Portanto, ele precisa de um sufixo @[DOMAIN] para se transformar em um endereço de e-mail.

É possível configurar o Cloud Directory Sync para adicionar automaticamente um sufixo ao nome do grupo. Como o Active Directory garante que os nomes de grupos e os nomes de contas de usuários não entrem em conflito, é improvável que um endereço de e-mail derivado dessa maneira cause conflitos.

Se uma floresta do Active Directory contiver mais de um domínio, as seguintes advertências se aplicarão:

  • Se dois grupos em domínios diferentes compartilharem um nome comum, haverá um conflito com o endereço de e-mail derivado, fazendo com que um grupo seja ignorado durante a sincronização.
  • Só é possível sincronizar grupos de domínios de uma floresta. Se você sincronizar grupos de várias florestas usando instâncias separadas do Cloud Directory Sync, os endereços de e-mail derivados do nome comum não refletirão a qual floresta eles correspondem. Essa ambiguidade fará com que uma instância do Cloud Directory Sync exclua qualquer grupo que tenha sido criado anteriormente e se originado de uma floresta diferente por outra instância do Cloud Directory Sync.
  • Não é possível mapear grupos por nome comum se for usada a substituição de domínio para o mapeamento de contas de usuário.

Como mapear por endereço de e-mail

Usar o endereço de e-mail (mail) para mapear identidades de grupo significa que você precisa atender aos mesmos critérios de uso do endereço de e-mail para mapear identidades de conta:

  • As atribuições de e-mail precisam estar completas. Embora seja comum que os grupos de distribuição tenham um endereço de e-mail, os grupos de segurança geralmente não têm esse atributo. Para usar o endereço de e-mail para mapear identidades, os grupos de segurança sujeitos a sincronização precisam ter o campo mail preenchido. O seguinte comando do PowerShell pode ser útil para encontrar contas em que esse campo não esteja preenchido:

    Get-ADGroup -LDAPFilter "(!mail=*)"
  • Os endereços de e-mail precisam usar um conjunto selecionado de domínios, todos de sua propriedade. Se algumas de suas contas usarem endereços de e-mail que se refiram a empresas parceiras ou provedores de e-mail de clientes, não será possível usar esses endereços.

  • Todas as contas de e-mail precisam ser exclusivas na floresta. Como o Active Directory não impõe exclusividade, talvez seja preciso implementar verificações ou políticas personalizadas.

Se todos os grupos relevantes atenderem a esses critérios, será possível identificar todos os domínios usados por esses endereços de e-mail e garantir que a lista de domínios DNS registrados no Cloud Identity cubra esses domínios.

Se um dos critérios não for atendido, ainda será possível associar os UPNs aos endereços de e-mail do Cloud Identity, com as seguintes advertências:

  • Os grupos sem endereços de e-mail serão ignorados durante a sincronização, assim como os endereços de e-mail que usam domínios que não estejam associados ao diretório do Cloud Identity.
  • Quando dois grupos compartilharem o mesmo endereço de e-mail, apenas um deles será sincronizado.

Não será possível mapear grupos por endereço de email se a floresta do Active Directory contiver mais de um único domínio e a substituição de domínio for usada para mapear contas de usuário.

Como mapear unidades organizacionais

A maioria dos domínios do Active Directory faz uso muito frequente de unidades organizacionais para agrupar e organizar recursos hierarquicamente, controlar o acesso e aplicar políticas.

No Google Cloud, pastas e projetos têm uma finalidade semelhante, embora os tipos de recursos gerenciados em uma organização do Google Cloud sejam muito diferentes dos recursos gerenciados no Active Directory. Como resultado, uma hierarquia de pastas apropriada do Google Cloud para uma empresa tende a ser significativamente diferente da estrutura das unidades organizacionais no Active Directory. Portanto, raramente a associação automática de unidades organizacionais a pastas e projetos é algo prático, além de não ser compatível com o Cloud Directory Sync.

Não tendo relação com pastas, o Cloud Identity é compatível com o conceito de unidades organizacionais. Essas unidades são criadas para agrupar e organizar contas de usuário, de forma semelhante ao que ocorre no Active Directory. Mas, diferentemente do que é observado no Active Directory, elas se aplicam apenas a contas de usuários, não a grupos.

O Cloud Directory Sync oferece a opção de sincronizar as unidades organizacionais do Active Directory com as unidades organizacionais do Cloud Identity. Em uma configuração em que o Cloud Identity é usado apenas para estender o gerenciamento de identidade do Active Directory para o Google Cloud, o mapeamento de unidades organizacionais geralmente não é necessário.

Como escolher o mapeamento certo

Conforme observado no início deste artigo, não há uma única maneira melhor de mapear as estruturas do Active Directory e do Google Cloud. Para ajudar na escolha do mapeamento certo para seu cenário, os gráficos de decisão a seguir resumem os critérios discutidos nas seções anteriores.

Primeiro, consulte o gráfico a seguir para identificar quantas contas do Cloud Identity, instâncias do Cloud Directory Sync e instâncias ou frotas do AD FS serão necessárias.

Gráfico de decisão para determinar o número de frotas ou instâncias necessárias

Em seguida, consulte o segundo gráfico para identificar os domínios a serem configurados na sua conta do Cloud Identity.

Gráfico de decisão para identificar os domínios a serem configurados no Cloud Identity

A seguir