Visão geral do gerenciamento de identidade do Google

Last reviewed 2023-02-27 UTC

Todos os serviços do Google, incluindo o Google Cloud, o Google Marketing Platform e o Google Ads, dependem do Login do Google para autenticar usuários. Neste documento, explicamos o modelo de domínio que o Login do Google usa para autenticação e gerenciamento de identidades. O modelo de domínio ajuda você a entender como o Login do Google funciona em um contexto corporativo, como as identidades são gerenciadas e como você possibilita a integração com um provedor de identidade (IdP, na sigla em inglês) externo. No diagrama a seguir, mostramos a interação das entidades.

Visão geral do modelo de domínio.

Como mostrado neste diagrama, no centro do modelo está a identidade do Google, que é usada pelo Login do Google. A identidade do Google está relacionada a várias outras entidades relevantes no contexto do gerenciamento de identidades:

  • O Google para consumidores contém as entidades relevantes para uso dos serviços do Google com foco no consumidor, como o Gmail.
  • O Google para organizações contém entidades gerenciadas pelo Cloud Identity ou pelo Google Workspace. Essas entidades são as mais relevantes para o gerenciamento de identidades corporativas.
  • O Google Cloud contém as entidades específicas do Google Cloud.
  • Externo contém as entidades relevantes se você integrar o Google a um IdP externo.

As setas sólidas no diagrama indicam que as entidades fazem referência mútua ou contêm umas às outras. Por outro lado, as setas tracejadas indicam um relacionamento de federação.

Identidades do Google

Identidades, usuários e contas de usuário desempenham um papel fundamental no gerenciamento de identidades. Os três termos estão estreitamente relacionados e, às vezes, são até usados de modo intercambiável. No entanto, no contexto do gerenciamento de identidades, vale a pena diferenciar os conceitos:

  • Uma identidade é um nome que identifica exclusivamente a pessoa que está interagindo com um serviço do Google. O Google usa os endereços de e-mail para essa finalidade. O endereço de e-mail de uma pessoa é considerado a identidade do Google dela.

    O processo de verificação da associação entre uma pessoa e uma identidade é chamado de autenticação ou login, que é um meio para a pessoa comprovar que a identidade é realmente dela.

    Uma pessoa pode ter vários endereços de e-mail. Já que os serviços do Google usam o endereço de e-mail como identidade, eles consideram que essa pessoa tem várias identidades.

  • Uma conta de usuário é uma estrutura de dados que controla os atributos, as atividades e as configurações que devem ser aplicados sempre que uma determinada identidade interage com um serviço do Google. As contas de usuário não são criadas imediatamente, mas precisam ser provisionadas antes do primeiro login.

    Elas são identificadas por um ID que não é exposto externamente. Portanto, as interfaces do usuário ou APIs exigem que você indique a conta de usuário indiretamente por meio da identidade associada, como alice@gmail.com. Mesmo que de modo indireto, todos os dados e detalhes de configuração estão associados à conta de usuário, não à identidade.

Na maioria dos casos, há um relacionamento um para um entre as contas de usuário e as identidades, o que facilita confundi-las. Mas isso nem sempre acontece, conforme ilustrado nos casos extremos a seguir:

  • O relacionamento entre as contas de usuário e as identidades não é fixo. É possível alterar o endereço de e-mail principal de uma conta de usuário, o que associa uma identidade diferente ao usuário.

    Como administrador do Cloud Identity ou do Google Workspace, você tem a opção até de alternar os endereços de e-mail principais de dois usuários. Por exemplo, se você alternar os endereços de e-mail principais de Alice (alice@example.com) e de Bob (bob@example.com), Alice usará a conta de usuário que antes era de Bob, e Bob usará a conta de usuário que antes era de Alice. Como os dados e a configuração estão associados à conta de usuário, e não à identidade, Alice também usará a configuração e os dados atuais de Bob, e Bob usará a configuração e os dados de Alice. Na figura a seguir, mostramos esse relacionamento.

    Relacionamento das identidades de Bob e Alice.

    Em uma configuração não federada, também é necessário redefinir as senhas para alternar as contas de usuário de Alice e Bob. Em uma configuração federada em que Alice e Bob usam um IdP externo para autenticação, não é necessário redefinir as senhas.

  • O relacionamento entre a identidade e os usuários não pode ser de 1:1. Uma conta pessoal pode ser intencionalmente associada a várias identidades, como no diagrama a seguir.

    É possível também que uma identidade se refira a duas contas de usuário diferentes. Recomendamos que você evite essa situação, mas ela pode surgir no caso de uma conta de usuário conflitante. Nesse caso, um usuário vê uma tela de seleção durante a autenticação, em que ele escolhe a conta que será usada.

    Alice: a relação entre usuário e identidade nem sempre é de 1:1.

O Google diferencia dois tipos de contas de usuário: pessoal e gerenciada. Nas seções a seguir, explicamos os dois tipos de contas de usuário e as entidades relacionadas com mais detalhes.

Google para consumidores

Se você tem um endereço de e-mail do Gmail, como alice@gmail.com, sua conta do Gmail é pessoal. Do mesmo modo, se você usar o link Criar conta na página de Login do Google e, durante a inscrição, fornecer um endereço de e-mail personalizado de sua propriedade, como alice@example.com, o resultado será também uma conta pessoal.

Conta pessoal

As contas pessoais são criadas por autoatendimento e devem ser usadas principalmente para fins particulares. A pessoa que criou a conta pessoal tem controle total dela e de todos os dados criados usando essa conta. O endereço de e-mail usado pela pessoa durante a inscrição torna-se o e-mail principal da conta pessoal e serve como identidade. Essa pessoa pode adicionar endereços de e-mail à conta pessoal. Eles servem como identidades extras e também podem ser usados para fazer login.

Quando uma conta pessoal usa um endereço de e-mail principal que corresponde ao domínio principal ou secundário de uma conta do Cloud Identity ou do Google Workspace, a conta pessoal também é chamada de conta de usuário não gerenciada.

Uma conta pessoal pode ser membro de vários grupos.

Google para organizações

Se sua organização usa os serviços do Google, é melhor usar contas de usuário gerenciadas. Essas contas são chamadas de gerenciadas porque o ciclo de vida e a configuração delas podem ser totalmente controlados pela organização.

As contas de usuário gerenciadas são um recurso do Cloud Identity e do Google Workspace.

Conta do Cloud Identity ou do Google Workspace

Uma conta do Cloud Identity ou do Google Workspace é o contêiner de nível superior para usuários, grupos, configurações e dados. Uma conta do Cloud Identity ou do Google Workspace é criada quando uma empresa se inscreve no Cloud Identity ou no Google Workspace e corresponde à noção de locatário.

O Cloud Identity e o Google Workspace compartilham uma plataforma técnica comum. Os dois produtos usam o mesmo conjunto de APIs e ferramentas administrativas e compartilham a noção de uma conta como contêiner para usuários e grupos. Esse contêiner é identificado por um nome de domínio. Para gerenciar usuários, grupos e autenticação, em grande parte, os dois produtos podem ser considerados equivalentes.

Uma conta contém grupos e uma ou mais unidades organizacionais.

Unidade organizacional

Uma unidade organizacional (UO) é um subcontêiner de contas de usuário que permite segmentar as contas de usuário definidas no Cloud Identity ou no Google Workspace em conjuntos separados para facilitar o gerenciamento.

As unidades organizacionais são organizadas de modo hierárquico. Cada conta do Cloud Identity ou do Google Workspace tem uma UO raiz, em que é possível criar mais UOs conforme necessário. É possível também aninhar suas UOs.

O Cloud Identity e o Google Workspace permitem aplicar determinadas configurações por UO, como atribuição de licença ou verificação em duas etapas. Essas configurações são automaticamente aplicadas a todos os usuários na UO e também são herdadas pelas UOs filhas. Portanto, as UOs desempenham um papel fundamental no gerenciamento da configuração do Cloud Identity e do Google Workspace.

Uma conta de usuário não pode pertencer a mais de uma UO, o que torna as UOs diferentes dos grupos. As UOs são úteis para aplicar a configuração às contas de usuário, mas não devem ser usadas para gerenciar o acesso. Para isso, recomendamos que você use grupos.

As UOs se parecem com as pastas do Google Cloud, mas as duas entidades têm finalidades diferentes e não há uma relação entre elas.

Conta de usuário gerenciada

As contas de usuário gerenciadas funcionam de modo parecido com as pessoais, mas podem ser totalmente controladas pelos administradores da conta do Cloud Identity ou do Google Workspace.

A identidade de uma conta de usuário gerenciada é definida pelo endereço de e-mail principal dela. O endereço de e-mail principal precisa usar um domínio que corresponda a um dos domínios principais, secundários ou de alias adicionados à conta do Cloud Identity ou do Google Workspace. As contas de usuário gerenciadas podem ter outros endereços de e-mail de alias e um endereço de e-mail de recuperação, mas esses endereços não são considerados identidades e não podem ser usados para fazer login. Por exemplo, se Alice usa alice@example.com como o endereço de e-mail principal dela e configurou ally@example.com como endereço de e-mail de alias e alice@gmail.com como endereço de e-mail de recuperação, o único e-mail que ela pode usar para fazer login é alice@example.com.

As contas de usuário gerenciadas fazem parte de uma unidade organizacional e podem ser membros de vários grupos.

As contas de usuário gerenciadas devem ser usadas por pessoas, e não por máquinas. Uma conta de usuário de máquina é um tipo especial usado por um aplicativo ou uma instância de máquina virtual (VM), não por uma pessoa. Para usuários de máquina, o Google Cloud oferece as contas de serviço. As contas de serviço serão discutidas com mais detalhes mais adiante neste documento.

Grupo

Os grupos permitem reunir vários usuários. É possível usá-los para gerenciar uma lista de e-mails ou aplicar um controle de acesso ou configuração comum a vários usuários.

O Cloud Identity e o Google Workspace identificam os grupos pelo endereço de e-mail, por exemplo, billing-admins@example.com. Assim como o endereço de e-mail principal de um usuário, o endereço de e-mail do grupo precisa usar um dos domínios principais, secundários ou de alias da conta do Cloud Identity ou do Google Workspace. O endereço de e-mail não precisa corresponder a uma caixa de correio, a menos que o grupo seja usado como uma lista de e-mails. A autenticação ainda é feita pelo e-mail do usuário, e não pelo e-mail do grupo. Portanto, um usuário não pode fazer login usando um endereço de e-mail de grupo.

Um grupo pode ter as seguintes entidades como membros:

  • Usuários (usuários gerenciados ou contas pessoais)
  • Outros grupos
  • Contas de serviço

Ao contrário de uma unidade organizacional, os grupos não atuam como um contêiner:

  • Um usuário ou grupo pode ser membro de vários grupos, não apenas um.
  • A exclusão de um grupo não remove os usuários ou grupos integrantes.

Os grupos podem incluir membros de qualquer conta do Cloud Identity ou do Google Workspace, além das contas pessoais. É possível usar a configuração não permitir membros de fora da sua organização para restringir os membros às contas de usuário procedentes da mesma conta do Cloud Identity ou do Google Workspace.

Identidades externas

Ao federar uma conta do Cloud Identity ou do Google Workspace com um IdP externo, você permite que os funcionários usem a identidade e as credenciais atuais deles para fazer login nos serviços do Google.

No nível mais básico, a federação envolve a configuração do Logon único usando o SAML, que vincula as identidades no Cloud Identity ou no Google Workspace às identidades gerenciadas pelo IdP externo. Para vincular uma identidade como alice@example.com e permitir que seja usada como Logon único no Google, você precisa atender a dois pré-requisitos:

  • Seu IdP externo precisa reconhecer a identidade alice@example.com e permitir que ela seja usada como Logon único.
  • Sua conta do Cloud Identity ou do Google Workspace precisa incluir uma conta de usuário que use alice@example.com como identidade. Essa conta de usuário precisa existir antes da primeira tentativa de Logon único.

Em vez de criar e manter as contas de usuário manualmente no Cloud Identity ou no Google Workspace, é possível automatizar o processo combinando o Logon único baseado em SAML com o provisionamento automático de usuários. A ideia do provisionamento automático de usuários é sincronizar todos ou um subconjunto de usuários e grupos de uma fonte autoritativa externa com o Cloud Identity ou o Google Workspace.

Dependendo da sua escolha de IdP, o Logon único baseado em SAML e o provisionamento automático de usuários podem ser processados pelo mesmo componente de software ou podem exigir componentes separados. Portanto, o modelo de domínio diferencia um provedor de identidade SAML de uma fonte autoritativa externa.

Provedor de identidade SAML externo

O IdP externo é o único sistema de autenticação que oferece uma experiência de Logon único para seus funcionários que abrange os aplicativos. Ele é externo ao Google e, portanto, chamado de provedor de identidade externo.

Quando você ativa o Logon único, o Cloud Identity ou o Google Workspace redireciona as decisões de autenticação para o IdP SAML. Em termos de SAML, o Cloud Identity ou o Google Workspace atua como um provedor de serviços que confia no IdP SAML para verificar a identidade de um usuário.

Cada conta do Cloud Identity ou do Google Workspace pode se referir a, no máximo, um IdP externo. Várias contas do Cloud Identity ou do Google Workspace podem se referir a IdPs SAML diferentes, mas uma única conta do Cloud Identity ou do Google Workspace não pode usar vários IdPs SAML.

Os IdPs externos mais usados incluem os Serviços de Federação do Active Directory (AD FS, na sigla em inglês), o Azure AD, o Okta ou o Ping Identity.

Fonte autoritativa externa

A fonte autoritativa de identidades é o único sistema que você usa para criar, gerenciar e excluir identidades de seus funcionários. Ela é externa ao Google e, portanto, é chamada de fonte autoritativa externa.

Por ela, as contas de usuário e os grupos podem ser provisionados automaticamente no Cloud Identity ou no Google Workspace. O provisionamento pode ser feito pela própria fonte autoritativa ou pelo middleware.

Para que o provisionamento automático de usuários seja eficaz, os usuários precisam ser provisionados com uma identidade que seu IdP SAML reconheça. Se você fizer o mapeamento entre identidades, por exemplo, se mapear a identidade alice@example.com no Cloud Identity ou no Google Workspace para u12345@corp.example.com no IdP SAML, o IdP SAML e o middleware de provisionamento precisarão fazer o mesmo mapeamento.

Conta de usuário externa

Os provedores de identidade externos têm o conceito de uma conta de usuário que controla o nome, os atributos e a configuração.

É esperado que a fonte autoritativa (ou o middleware de provisionamento) provisione todas as contas de usuário externas ou um conjunto delas para o Cloud Identity ou o Google Workspace a fim de proporcionar uma experiência de login. Em muitos casos, é suficiente propagar apenas um subconjunto dos atributos do usuário, como endereço de e-mail, nome e sobrenome, ao Cloud Identity ou ao Google Workspace para você limitar a redundância de dados.

Grupo externo

Se o IdP externo aceitar a noção de grupo, será possível mapear esses grupos para grupos no Cloud Identity ou no Google Workspace.

O mapeamento e o provisionamento automático de grupos são opcionais e não são necessários para o Logon único, mas as duas etapas poderão ser úteis se você quiser reutilizar os grupos atuais para controlar o acesso no Google Workspace ou no Google Cloud.

Google Cloud

Assim como outros serviços do Google, o Google Cloud depende do Login do Google para autenticar usuários. O Google Cloud também está estreitamente integrado ao Google Workspace e ao Cloud Identity para permitir o gerenciamento eficiente de recursos.

O Google Cloud apresenta a noção de nós, pastas e projetos da organização. Essas entidades são usadas principalmente para gerenciar o acesso e a configuração. Portanto, elas são relevantes apenas no contexto do gerenciamento de identidades. No entanto, o Google Cloud também inclui outro tipo de conta de usuário: contas de serviço. As contas de serviço pertencem a projetos e desempenham um papel fundamental no gerenciamento de identidades.

Nó da organização

Uma organização é o nó raiz na hierarquia de recursos do Google Cloud e um contêiner de projetos e pastas. As organizações permitem estruturar recursos hierarquicamente e são fundamentais para gerenciar recursos de maneira centralizada e eficiente.

Cada organização pertence a uma única conta do Cloud Identity ou do Google Workspace. O nome da organização é derivado do nome de domínio principal da conta do Cloud Identity ou do Google Workspace correspondente.

Pasta

As pastas são nós na hierarquia de recursos do Google Cloud e podem incluir projetos, outras pastas ou uma combinação dos dois. Use pastas para agrupar recursos que compartilham políticas de gerenciamento de identidade e acesso (IAM) ou políticas da organização comuns. Essas políticas são automaticamente aplicadas a todos os projetos na pasta e também são herdadas pelas pastas filhas.

As pastas são semelhantes, mas não estão relacionadas às unidades organizacionais. As unidades organizacionais ajudam você a gerenciar usuários e aplicar configurações ou políticas comuns aos usuários. Por outro lado, as pastas ajudam você a gerenciar projetos do Google Cloud e aplicar configurações ou políticas comuns aos projetos.

Projeto

Um projeto é um contêiner de recursos. Os projetos desempenham um papel fundamental no gerenciamento de APIs, no faturamento e no gerenciamento de acesso a recursos.

No contexto do gerenciamento de identidades, os projetos são relevantes porque são os contêineres das contas de serviço.

Conta de serviço

Uma conta de serviço, ou conta de serviço do Google Cloud, é um tipo especial de conta de usuário que deve ser usado por aplicativos e outros tipos de usuários de máquina.

Cada conta de serviço pertence a um projeto do Google Cloud. Como acontece com as contas de usuário gerenciadas, os administradores podem controlar totalmente o ciclo de vida e a configuração de uma conta de serviço.

As contas de serviço também usam um endereço de e-mail como identidade, mas, ao contrário das contas de usuário gerenciadas, o endereço de e-mail sempre usa um domínio do Google, como developer.gserviceaccount.com.

As contas de serviço não participam da federação e também não têm uma senha. No Google Cloud, você usa o IAM para controlar a permissão que uma conta de serviço tem em relação a um recurso de computação, como uma máquina virtual (VM) ou uma Função do Cloud. Isso remove a necessidade de gerenciar as credenciais. Fora do Google Cloud, é possível usar chaves de conta de serviço para permitir que um aplicativo seja autenticado por meio de uma conta de serviço.

Conta de serviço do Kubernetes

As contas de serviço do Kubernetes são um conceito do Kubernetes (em inglês), que são relevantes quando você usa o Google Kubernetes Engine (GKE). Assim como no Google Cloud, as contas de serviço do Kubernetes são usadas por aplicativos, não por pessoas.

As contas de serviço do Kubernetes podem ser usadas para autenticação quando um aplicativo chama a API Kubernetes de um cluster do Kubernetes, mas elas não podem ser usadas fora do cluster. Elas não são reconhecidas por nenhuma API do Google e, portanto, não substituem uma conta de serviço do Google Cloud.

Ao implantar um aplicativo como um pod do Kubernetes, é possível associar o pod a uma conta de serviço (links em inglês). Essa associação permite que o aplicativo use a API Kubernetes sem precisar configurar ou manter certificados nem outras credenciais.

Ao usar a Identidade da carga de trabalho, é possível vincular uma conta de serviço do Kubernetes a uma conta de serviço do Google Cloud. Esse vínculo também permite que um aplicativo seja autenticado nas APIs do Google, sem precisar manter certificados nem outras credenciais.

A seguir