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

Este artigo é a primeira parte de uma série que discute como estender uma solução atual de gerenciamento de identidades baseada no Active Directory para o Google Cloud Platform (GCP). 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 consiste nestas partes:

Os departamentos de TI das empresas geralmente dependem do Active Directory para gerenciar contas de usuários e para 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.

Estender o cenário de TI atual para o GCP como parte de uma estratégia híbrida tem como objetivo manter um único ponto para o gerenciamento de identidades. Ter uma única 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 discutimos 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 GCP usa as identidades do Google para autenticação e gerenciamento de acesso. Para acessar os recursos do GCP, um funcionário precisa ter uma identidade do Google. Manter as identidades do Google para cada funcionário de forma manual seria complicado quando todos os funcionários já têm uma conta no Active Directory. Ao federar identidades de usuários entre o Active Directory e o GCP, é 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 de usuários, o que torna desnecessária a sincronização das senhas com o GCP.

No Google, use o Cloud Identity para configurar um diretório de conta de usuário privado para criar e gerenciar contas do Google. Assim, 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 sincronizadas periodicamente do Active Directory para o Cloud Identity. Esse processo garante que uma nova conta criada no Active Directory possa ser referenciada no GCP antes mesmo que o usuário associado tenha feito 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 precisar se autenticar no GCP, o Cloud Identity delegará a autenticação ao Active Directory usando o protocolo Linguagem de marcação para autorização de segurança (SAML, na sigla em inglês). 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 na sigla em inglês) 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. Ele se comunica com o Google Identity Platform por meio do Secure Sockets Layer (SSL) e geralmente é executado no ambiente de computação atual.
  • Os Serviços de Federação do Active Directory (AD FS, na sigla em inglês) 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 Google Identity Platform estão disponíveis ao público 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 seu nome é derivado do domínio raiz da floresta. 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 florestas, florestas separadas não confiam umas nas outras por padrão, e usuários autenticados em uma floresta não podem acessar recursos que estão em outra floresta.

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 GCP

O GCP permite o gerenciamento de recursos nas organizações. Esses recursos podem ser ainda mais segmentados 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, de modo que o gerenciamento e a autenticação de contas de usuários estão vinculados a domínios. Por outro lado, o GCP não gerencia contas de usuário em uma organização, com exceção das contas de serviço. Em vez disso, o GCP depende do Cloud Identity ou do G Suite para gerenciar contas de usuários.

O Cloud Identity permite criar e gerenciar diretórios privados 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

De forma semelhante a como uma floresta e um domínio raiz de floresta são sempre criados em conjunto no Active Directory, uma conta do Cloud Identity é sempre criada em paralelo com uma organização do GCP. E da mesma forma que um domínio raiz de floresta e uma floresta compartilham o mesmo nome e não podem ser desvinculados um do outro, a conta do Cloud Identity e a organização do GCP compartilham o mesmo nome e estão vinculadas uma à outra. No entanto, uma organização do GCP tem permissão para fazer referência a mais usuários e grupos de contas do Cloud Identity.

Como integrar o Active Directory e o GCP

Embora haja algumas semelhanças entre a estrutura lógica do Active Directory e do GCP, 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 alguém planeja federar o Active Directory e o GCP, o primeiro fator a ser observado é a topologia da sua 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 única conta do Cloud Identity. Essa conta fornece então a base para uma única organização do GCP, que pode ser usada para gerenciar seus recursos do GCP.

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 uma única instância do Cloud Directory Sync para sincronizar contas e grupos de usuários com o GCP e manter uma única 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. Em ambos os casos é possível associar toda a floresta a uma única conta do Cloud Identity. Essa conta fornece então a base para uma única organização do GCP que pode ser usada para gerenciar seus recursos do GCP.

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. Enquanto os controladores de domínio fornecem apenas dados de seu domínio local, os servidores de catálogo global fornecem acesso a informações de todos os domínios da floresta. É importante ter claro que os dados disponibilizados pelos servidores de catálogo global são parciais e não têm certos atributos LDAP. Essa limitação pode afetar a forma como o Cloud Directory Sync é configurado para sincronizar grupos.

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

Múltiplas florestas com relação de confiança entre si

Múltiplas 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 única conta do Cloud Identity. Essa conta fornece a base para uma única organização do GCP, que pode ser usada para gerenciar os recursos do GCP.

Embora os servidores de catálogo global forneçam acesso a dados de vários domínios, seu escopo é limitado a uma única floresta. Portanto, em um ambiente com várias florestas, é preciso consultar vários controladores de domínio ou servidores de catálogo global para ter acesso, por exemplo, a uma lista completa de contas de usuários. Como resultado dessa limitação, federar um ambiente com várias florestas com o GCP 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 trabalhe além dos limites da floresta. Isso faz com que uma única instância ou frota do AD FS seja suficiente para lidar com o logon único.

Aplicam-se as mesmas considerações caso o ambiente abranja várias florestas sem relação de confiança entre si, mas todos os domínios do Active Directory que sejam relevantes para a federação com o GCP estejam conectados por meio de relações de confiança externas.

Múltiplas florestas sem relação de confiança entre si

Múltiplas 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 GCP, uma organização independente é criada 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 ponto a ser observado quando você planeja federar o Active Directory e o GCP é como compartilhar ou mapear domínios DNS entre o Active Directory e o GCP.

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 é o mesmo que o 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. Para um usuário john no domínio corp.example.com, o UPN padrão é 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. Os UPNs são opcionais e são armazenados no campo userPrincipalName da conta do usuário.
  • Domínios do endpoint: os servidores voltados para o público, como 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 GCP

O Google Identity Platform, de que o GCP depende para autenticação, usa endereços de e-mail para identificar usuários. O uso de endereços de e-mail não apenas garante que eles sejam globalmente únicos, mas também permite que o GCP envie mensagens de notificação para esses endereços.

O Google Identity Platform determina o diretório ou o provedor de identidade a ser usado para autenticar um usuário com base no domínio dos endereços de e-mail, que vem após o @. Para um endereço de e-mail que usa o domínio gmail.com, por exemplo, o Google Identity Platform 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 está associado ao domínio gmail.com, as contas do G Suite e do Cloud Identity precisam estar 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 GCP. Ao se inscrever no Cloud Identity, você precisa especificar esse nome de domínio.
  • Domínio secundário: juntamente com o 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, são consideradas contas separadas se example.com for o domínio principal e secondary.example.com 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 referem-se à 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 local, como corp.local ou corp.internal, como são 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 por exemplo example.com, pode se referir apenas a um único diretório. É possível no entanto usar subdomínios diferentes, como subdomain.example.com, para se referir a diretórios diferentes.
  • 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 ponto a ser observado para o planejamento de federação do Active Directory e do GCP é 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 código 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 código 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 códigos é 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 preferida para identificar uma conta de usuário. Os UPNs seguem o formato RFC 822 de endereços de e-mail e são criados combinando o nome de usuário com um sufixo UPN de domínio, 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): 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 código ú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 que se refere ao Active Directory, o objectGUID é perfeito para esse propósito.
  • 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. Uma vez que esse endereço de e-mail será usado no GCP, verifique se o endereço é significativo. Derivar um endereço a partir do objectGUID é impraticável, assim como acontece com outros endereços de e-mail gerados automaticamente.

Em uma conta de usuário do Active Directory, dois campos podem 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 exige 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 podem não receber os e-mails de notificação enviados pelo GCP, o que pode levar os usuários a perder 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

O uso do campo mail exige o atendimento dos 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 façam referência 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 ponto a ser observado quando alguém planeja federar o Active Directory e o GCP é sincronizar grupos entre o Active Directory e o GCP e como mapeá-los.

No GCP, os grupos costumam ser usados como uma forma de gerenciar de maneira eficiente o acesso entre os projetos. Em vez de atribuir usuários individuais a papéis de gerenciamento de identidade e acesso do Cloud (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 um problema no gerenciamento de identidade e acesso do GCP. 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 GCP é opcional. Após as contas de usuários serem federadas, é 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 que associações a grupos possam ser usadas no Active Directory para controlar quem tem acesso a determinados recursos no GCP.

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 único 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 o Cloud Directory Sync for configurado para usar um servidor de catálogo global como uma fonte, então a ferramenta será capaz de localizar grupos de todos os domínios na floresta. Mas somente grupos que estão no mesmo domínio do 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 GCP.

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 GCP

O GCP usa um modelo de acesso baseado em papéis, e não um modelo 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 GCP e raramente é necessário sincronizar os grupos de recursos com o GCP.

Grupos de papéis e grupos de organizações são tão relevantes no GCP quanto no Active Directory porque facilitam o gerenciamento do acesso de 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.

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 no GCP, 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 por seu nome comum (cn) ou por um nome de logon anterior ao Windows 2000 (sAMAccountName). Assim como ocorre com as contas de usuário, os grupos também podem ter um endereço de e-mail (mail), mas endereços de e-mail são um atributo opcional no caso de 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) é o fato de que é garantido que ele esteja disponível e, pelo menos dentro de uma unidade organizacional, que seja exclusivo. No entanto, o nome comum não é um endereço de e-mail. Por isso, é necessário um sufixo @[DOMAIN] anexado 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 única floresta. Se grupos de várias florestas forem sincronizados 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.

Mapear por endereço de e-mail

Usar o endereço de e-mail (mail) para mapear identidades de grupo significa que é preciso atender aos mesmos critérios quando o endereço de e-mail é usado 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 mapeamento de identidades, os grupos de segurança sujeitos à 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 GCP, as pastas e os projetos têm um objetivo semelhante, embora os tipos de recursos gerenciados em uma organização do GCP sejam muito diferentes dos recursos gerenciados no Active Directory. Como resultado, uma hierarquia de pastas do GCP apropriada para uma empresa tende a diferir significativamente 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 ao GCP, 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 mais adequada para mapear as estruturas do Active Directory e do GCP. Para ajudá-lo a escolher o mapeamento correto para sua realidade, 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

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…