Arquiteturas de referência

Este documento apresenta arquiteturas típicas que pode usar como referência para gerir identidades empresariais. Os dois princípios fundamentais da gestão da identidade corporativa são os seguintes:

  • Uma fonte autorizada de identidades que é o único sistema que usa para criar, gerir e eliminar identidades dos seus funcionários. As identidades geridas no sistema de origem autoritário podem ser propagadas a outros sistemas.

  • Um fornecedor de identidade (IdP) central que é o único sistema de autenticação e que oferece uma experiência de início de sessão único aos seus funcionários que abrange várias aplicações.

Quando utiliza o Google Cloud ou outros serviços Google, tem de decidir que sistema usar como fornecedor de identidade e que sistema usar como fonte autorizada.

Use a Google como IdP

Ao usar o Cloud ID Premium ou o Google Workspace, pode tornar a Google o seu IdP principal. A Google oferece uma grande seleção de integrações prontas a usar para aplicações de terceiros populares, e pode usar protocolos padrão, como SAML, OAuth, e OpenID Connect para integrar as suas aplicações personalizadas.

A Google como IdP e fonte fidedigna

Pode usar o Cloud ID Premium ou o Google Workspace como IdP e como origem autoritária, como no diagrama seguinte.

A Google como IdP e fonte fidedigna.

  • Usa o Cloud ID Premium ou o Google Workspace para gerir utilizadores e grupos.
  • Todos os serviços Google usam o Cloud ID Premium ou o Google Workspace como IdP.
  • Configura aplicações empresariais e outros serviços SaaS para usar o Google como IdP.

Experiência do utilizador

Nesta configuração, a experiência do utilizador de início de sessão para um funcionário tem o seguinte aspeto:

  1. Ao pedir um recurso protegido ou acesso a uma aplicação corporativa, o funcionário é redirecionado para o ecrã de início de sessão do Google, que lhe pede o seu endereço de email e palavra-passe.
  2. Se a validação em dois passos estiver ativada, é pedido ao funcionário que faculte um segundo fator, como uma chave USB ou um código.
  3. Quando o funcionário é autenticado, é redirecionado de volta para o recurso protegido.

Vantagens

A utilização do Google como IdP e fonte autorizada tem as seguintes vantagens:

Quando usar esta arquitetura

Considere usar a Google como IdP e origem autorizada nos seguintes cenários:

  • Já usa o Google Workspace como solução de colaboração e produtividade.
  • Não existe nenhuma infraestrutura no local ou IdP com a qual tenha de se integrar, ou quer mantê-la separada de todos os seus recursos no Google (no Google Cloud, no Google Ads, etc.).
  • Não precisa de integração com um sistema de informações de recursos humanos (HRIS) para gerir identidades.

A Google como IdP com um HRIS como origem fidedigna

Se usar um sistema de informações de recursos humanos (HRIS) para gerir o processo de integração e desvinculação dos seus funcionários, pode continuar a usar a Google como o seu IdP. O Cloud Identity e o Google Workspace fornecem APIs que permitem que o SHRH e outros sistemas assumam o controlo da gestão de utilizadores e grupos, conforme mostrado no diagrama seguinte.

A Google como IdP com um HRIS como origem fidedigna.

  • Usa o seu SRHI existente para gerir utilizadores e, opcionalmente, grupos. O HRIS continua a ser a única fonte de verdade para a gestão de identidades e aprovisiona automaticamente os utilizadores para o Cloud ID ou o Google Workspace.
  • Todos os serviços Google usam o Cloud ID Premium ou o Google Workspace como IdP.
  • Configura aplicações empresariais e outros serviços SaaS para usar o Google como IdP.

Experiência do utilizador

Para um funcionário, a experiência do utilizador de início de sessão é equivalente à utilização da Google como IdP e fonte autorizada.

Vantagens

A utilização da Google como IdP e origem autorizada tem as seguintes vantagens:

  • Pode minimizar os custos administrativos reutilizando os fluxos de trabalho do SRH existentes.
  • Pode tirar total partido das funcionalidades de autenticação multifator e de gestão de dispositivos móveis da Google.
  • Não precisa de um IdP adicional, o que pode poupar-lhe dinheiro.

Quando usar esta arquitetura

Considere usar o Google como IdP com um HRIS como origem autorizada nos seguintes cenários:

  • Tem um HRIS ou outro sistema existente que serve como a origem autorizada de identidades.
  • Já usa o Google Workspace como solução de colaboração e produtividade.
  • Não existe uma infraestrutura nas instalações nem um IdP com o qual tenha de se integrar ou que queira manter separado do seu domínio Google.

Use um IdP externo

Se a sua organização já usar um IdP, como o Active Directory, o Microsoft Entra ID (anteriormente Azure AD), o ForgeRock, o Okta ou o Ping Identity, pode integrar Google Cloud com este IdP externo através da federação.

Ao federar uma conta do Cloud Identity ou do Google Workspace com um IdP externo, pode permitir que os funcionários usem a respetiva identidade e credenciais existentes para iniciar sessão em serviços Google, como o Google Cloud, o Google Marketing Platform e o Google Ads.

IDaaS externo como IdP e origem autorizada

Se usar um fornecedor de identidade como serviço (IDaaS), como ForgeRock, Okta ou Ping Identity, pode configurar a federação conforme ilustrado no diagrama seguinte.

IDaaS externo como IdP e origem autorizada.

  • O Cloud ID ou o Google Workspace usa o seu IDaaS como o IdP para o início de sessão único.
  • O IDaaS aprovisiona automaticamente utilizadores e grupos para o Cloud Identity ou o Google Workspace.
  • As aplicações empresariais existentes e outros serviços SaaS podem continuar a usar o seu IDaaS como IdP.

Para saber mais sobre a federação do Cloud Identity ou do Google Workspace com o Okta, consulte o artigo Aprovisionamento de utilizadores e início de sessão único do Okta.

Experiência do utilizador

Para um funcionário, a experiência do utilizador de início de sessão tem o seguinte aspeto:

  1. Ao pedir um recurso protegido, o funcionário é redirecionado para o ecrã de início de sessão da Google, que lhe pede o endereço de email.
  2. O Início de sessão da Google redireciona para a página de início de sessão do seu IDaaS.
  3. Faz a autenticação com o seu IDaaS. Dependendo do seu IDaaS, isto pode exigir que faculte um segundo fator, como um código.
  4. Depois de a sua identidade ser validada, a página é redirecionada novamente para o recurso protegido.

Vantagens

A utilização de um IDaaS externo como IdP e origem autorizada tem as seguintes vantagens:

  • Ativa uma experiência de início de sessão único para os seus funcionários que se estende aos serviços Google e a outras aplicações integradas com o seu IDaaS.
  • Se configurou o seu IDaaS para exigir a autenticação multifator, essa configuração aplica-se automaticamente ao Google Cloud.
  • Não precisa de sincronizar palavras-passe nem outras credenciais com a Google.
  • Pode usar a versão gratuita do Cloud ID.

Quando usar esta arquitetura

Considere usar um IDaaS externo como IdP e fonte autorizada nos seguintes cenários:

  • Já usa um fornecedor de IDaaS, como ForgeRock, Okta ou Ping Identity, como IdP.

Práticas recomendadas

Consulte as nossas práticas recomendadas para federar Google Cloud com um fornecedor de identidade externo.

O Active Directory como IdP e origem autorizada

Se usar o Active Directory como a fonte de verdade para a gestão de identidades, pode configurar a federação conforme ilustrado no diagrama seguinte.

O Active Directory como IdP e origem autorizada.

  • Usa a Sincronização de diretórios do Google Cloud (GCDS) para aprovisionar automaticamente utilizadores e grupos do Active Directory para o Cloud Identity ou o Google Workspace. O Google Cloud Directory Sync é uma ferramenta gratuita fornecida pela Google que implementa o processo de sincronização e pode ser executada no Google Cloud ou no seu ambiente nas instalações. A sincronização é unidirecional, pelo que o Active Directory permanece a fonte de informações fidedignas.
  • O Cloud ID ou o Google Workspace usa os Serviços de federação do Active Directory (AD FS) para o início de sessão único.
  • As aplicações empresariais existentes e outros serviços SaaS podem continuar a usar o AD FS como um IdP.

Para uma variação deste padrão, também pode usar os serviços de diretório simples do Active Directory (AD LDS) ou um diretório LDAP diferente com o AD FS ou outro IdP compatível com SAML.

Para mais informações sobre esta abordagem, consulte o artigo Federar Google Cloud com o Active Directory.

Experiência do utilizador

  1. Ao pedir o recurso protegido, o funcionário é redirecionado para o ecrã de início de sessão da Google, que lhe pede o endereço de email.
  2. O Início de sessão com o Google redireciona o funcionário para a página de início de sessão do AD FS.
  3. Consoante a configuração do AD FS, o funcionário pode ver um ecrã de início de sessão a pedir o nome de utilizador e a palavra-passe do Active Directory. Em alternativa, o AD FS pode tentar iniciar sessão automaticamente no funcionário com base no respetivo início de sessão no Windows.
  4. Depois de o AD FS autenticar o funcionário, este é redirecionado de volta para o recurso protegido.

Vantagens

A utilização do Active Directory como IdP e origem autorizada tem as seguintes vantagens:

  • Ativa uma experiência de Início de sessão único para os seus funcionários que se estende aos serviços Google e ao seu ambiente no local.
  • Se configurou o AD FS para exigir a autenticação multifator, essa configuração aplica-se automaticamente ao Google Cloud.
  • Não precisa de sincronizar palavras-passe nem outras credenciais com a Google.
  • Pode usar a versão gratuita do Cloud ID.
  • Uma vez que as APIs que o GCDS usa são acessíveis publicamente, não é necessário configurar a conetividade híbrida entre a sua rede no local e a Google Cloud.

Quando usar esta arquitetura

Considere usar o Active Directory como o IdP e a origem autorizada nos seguintes cenários:

  • Tem uma infraestrutura do Active Directory existente.
  • Quer oferecer uma experiência de início de sessão integrada para os utilizadores do Windows.

Práticas recomendadas

Tenha em conta estas práticas recomendadas:

  • O Active Directory e o Cloud Identity usam uma estrutura lógica diferente. Certifique-se de que compreende as diferenças e avalie que método de mapeamento de domínios, identidades e grupos se adequa melhor à sua situação. Para mais informações, consulte o nosso guia sobre a federação Google Cloud com o Active Directory.
  • Sincronizar grupos além de utilizadores. Com esta abordagem, pode configurar o IAM para poder usar as subscrições de grupos no Active Directory para controlar quem tem acesso a que recursos noGoogle Cloud.
  • Implemente e exponha o AD FS para que os utilizadores empresariais possam aceder ao mesmo, mas não o exponha mais do que o necessário. Embora os utilizadores empresariais tenham de poder aceder ao AD FS, não existe nenhum requisito para que o AD FS seja acessível a partir do Cloud ID ou do Google Workspace, ou de qualquer aplicação implementada no Google Cloud.
  • Pondere ativar a autenticação integrada do Windows (IWA) no AD FS para permitir que os utilizadores iniciem sessão automaticamente com base no respetivo início de sessão no Windows.
  • Se o AD FS ficar indisponível, os utilizadores podem não conseguir usar a Google Cloud consola nem qualquer outro recurso que use o Google como IdP. Por isso, certifique-se de que o AD FS e os controladores de domínio nos quais o AD FS se baseia estão implementados e dimensionados para cumprir os seus objetivos de disponibilidade.

  • Se usar o Google Cloud para ajudar a garantir a continuidade da empresa, confiar num AD FS no local pode comprometer a intenção de usar o Google Cloud como uma cópia independente da sua implementação. Neste caso, considere implementar réplicas de todos os sistemas relevantes Google Cloud de uma das seguintes formas:

    • Estenda o seu domínio do Active Directory existente para Google Cloud e implemente o GCDS para ser executado em Google Cloud.
    • Execute servidores AD FS dedicados em Google Cloud. Estes servidores usam os controladores de domínio do Active Directory que estão a ser executados emGoogle Cloud.
    • Configure o Cloud ID para usar os servidores AD FS implementados no Google Cloud para o Início de sessão único.

Para saber mais, consulte as Práticas recomendadas para a federação Google Cloud com um fornecedor de identidade externo.

O Entra ID como IdP com o Active Directory como origem autorizada

Se for cliente do Microsoft 365 ou do Azure, pode ter associado o seu Active Directory no local ao Entra ID. Se todas as contas de utilizador que podem precisar de acesso a Google Cloud já estiverem a ser sincronizadas com o Entra ID, pode reutilizar esta integração federando o Cloud Identity com o Entra ID, conforme mostrado no diagrama seguinte.

O Entra ID como IdP com o Active Directory como origem autorizada.

  • Usa o Entra ID para aprovisionar automaticamente utilizadores e grupos no Cloud Identity ou no Google Workspace. O próprio Entra ID pode estar integrado com um Active Directory no local.
  • O Cloud ID ou o Google Workspace usam o Entra ID para o início de sessão único.
  • As aplicações empresariais existentes e outros serviços SaaS podem continuar a usar o Entra ID como um IdP.

Para obter informações mais detalhadas sobre esta abordagem, consulte o artigo Federar Google Cloud com o Microsoft Entra ID.

Experiência do utilizador

  1. Ao pedir o recurso protegido, o funcionário é redirecionado para o ecrã de início de sessão da Google, que lhe pede o endereço de email.
  2. O Início de sessão da Google redireciona-os para a página de início de sessão do AD FS.
  3. Consoante a forma como o Active Directory no local está ligado ao Entra ID, o Entra ID pode pedir-lhes um nome de utilizador e uma palavra-passe ou pode redirecioná-los para um AD FS no local.
  4. Depois de o funcionário ser autenticado com o Entra ID, é redirecionado de volta para o recurso protegido.

Vantagens

A utilização do Entra ID como IdP com o Active Directory como origem autorizada tem várias vantagens:

  • Ativa uma experiência de início de sessão único para os seus funcionários que se estende aos serviços Google, ao Entra e ao seu ambiente no local.
  • Se configurou o Entra ID para exigir a autenticação multifator, essa configuração aplica-se automaticamente ao Google Cloud.
  • Não precisa de instalar software adicional no local.
  • Se o seu Active Directory no local usar vários domínios ou florestas e tiver configurado uma configuração personalizada do Entra ID Connect para mapear esta estrutura para um inquilino do Entra ID, pode tirar partido deste trabalho de integração.
  • Não precisa de sincronizar palavras-passe nem outras credenciais com a Google.
  • Pode usar a versão gratuita do Cloud ID.
  • Pode apresentar a Google Cloud consola como um mosaico no portal do Office 365.
  • Uma vez que as APIs que o Entra ID usa são acessíveis publicamente, não é necessário configurar a conetividade híbrida entre o Entra e o Google Cloud.

Quando usar esta arquitetura

Considere usar o Entra ID como IdP com o Active Directory como origem autorizada nos seguintes cenários:

  • Já usa o Entra ID e o integrou com uma infraestrutura do Active Directory existente.
  • Quer oferecer uma experiência de início de sessão integrada para os utilizadores no Entra e Google Cloud.

Práticas recomendadas

Siga estas práticas recomendadas:

  • Uma vez que o Entra ID e o Cloud Identity usam uma estrutura lógica diferente, certifique-se de que compreende as diferenças. Avalie que método de mapeamento de domínios, identidades e grupos se adequa melhor à sua situação. Para mais informações detalhadas, consulte o artigo Federar Google Cloud com o Microsoft Entra ID.
  • Sincronizar grupos além de utilizadores. Com esta abordagem, pode configurar o IAM para usar as associações a grupos no Entra ID para controlar quem tem acesso a que recursos noGoogle Cloud.
  • Se usar o Google Cloud para ajudar a garantir a continuidade da empresa, confiar no Entra ID para autenticação pode prejudicar a intenção de usar oGoogle Cloud como uma cópia independente da sua implementação.

Para saber mais, consulte as Práticas recomendadas para a federação Google Cloud com um fornecedor de identidade externo.

O que se segue?