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.
- 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:
- 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.
- 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.
- Quando o funcionário é autenticado, é redirecionado de volta para o recurso protegido.
Vantagens
A utilização do Google como IdP e origem autorizada tem as seguintes vantagens:
- 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 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 fonte 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.
- 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 nenhuma infraestrutura no local nem 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.
- 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:
- 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.
- O Início de sessão da Google redireciona para a página de início de sessão do seu IDaaS.
- Faz a autenticação com o seu IDaaS. Dependendo do seu IDaaS, isto pode exigir que faculte um segundo fator, como um código.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
Azure AD como IdP com o Active Directory como origem autorizada
Se for cliente do Microsoft Office 365 ou do Azure, pode ter associado o seu Active Directory no local ao Azure AD. Se todas as contas de utilizador que potencialmente precisam de acesso já estiverem a ser sincronizadas com o Azure AD, pode reutilizar esta integração federando o Cloud ID com o Azure AD, conforme mostrado no diagrama seguinte. Google Cloud
- Usa o Azure AD para aprovisionar automaticamente utilizadores e grupos no Cloud Identity ou no Google Workspace. O próprio Azure AD pode estar integrado com um Active Directory no local.
- O Cloud ID ou o Google Workspace usam o Azure AD para o início de sessão único.
- As aplicações empresariais existentes e outros serviços SaaS podem continuar a usar o Azure AD como um IdP.
Para informações mais detalhadas sobre esta abordagem, consulte o artigo Estabeleça uma federação Google Cloud com o Azure Active Directory.
Experiência do utilizador
- 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.
- O Início de sessão da Google redireciona-os para a página de início de sessão do AD FS.
- Consoante a forma como o Active Directory no local está ligado ao Azure AD, o Azure AD pode pedir-lhe um nome de utilizador e uma palavra-passe ou pode redirecioná-lo para um AD FS no local.
- Depois de o funcionário ser autenticado com o Azure AD, é redirecionado de volta para o recurso protegido.
Vantagens
A utilização do Azure AD 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 Azure e ao seu ambiente no local.
- Se configurou o Azure AD 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 Azure AD Connect para mapear esta estrutura para um inquilino do Azure AD, pode tirar partido desta 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 Azure AD usa são acessíveis publicamente, não é necessário configurar a conetividade híbrida entre o Azure e o Google Cloud.
Quando usar esta arquitetura
Considere usar o Azure AD como IdP com o Active Directory como origem autorizada nos seguintes cenários:
- Já usa o Azure AD e o integrou com uma infraestrutura do Active Directory existente.
- Quer oferecer uma experiência de início de sessão integrada aos utilizadores no Azure e Google Cloud.
Práticas recomendadas
Siga estas práticas recomendadas:
- Uma vez que o Azure AD 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 Azure AD.
- Sincronizar grupos além de utilizadores. Com esta abordagem, pode configurar o IAM para usar as associações a grupos no Azure AD 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 Azure AD para autenticação pode prejudicar a intenção de usar o Google 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?
- Saiba mais sobre a federação com o Active Directory.
- Saiba como configurar a federação com o Azure AD.
- Reveja as nossas práticas recomendadas para planear contas e organizações e para federar Google Cloud com um fornecedor de identidade externo.