Arquiteturas de referência

Last reviewed 2024-07-11 UTC

Neste documento, apresentamos arquiteturas típicas que podem ser usadas como referência para gerenciar identidades corporativas. Dois princípios básicos do gerenciamento de identidade corporativa são os seguintes:

  • Uma fonte autoritativa para identidades, que é o único sistema usado para criar, gerenciar e excluir identidades para seus funcionários. As identidades gerenciadas no sistema de fonte autoritativa podem ser propagadas para outros sistemas.

  • Um provedor de identidade (IdP, na sigla em inglês) central, que é o único sistema de autenticação e que fornece uma experiência de Logon único aos seus funcionários, inclusive para aplicativos.

Ao usar o Google Cloud ou outros serviços do Google, você precisa decidir qual sistema usar como provedor de identidade e qual sistema usar como fonte autoritativa.

Usar o Google como um IdP

Ao usar o Cloud Identity Premium ou o Google Workspace, é possível tornar o Google seu IdP principal. O Google fornece uma grande variedade de integrações prontas para uso para apps famosos de terceiros, e é possível usar protocolos padrão como SAML, OAuth e OpenID Connect para integrar apps personalizados.

Google como IdP e fonte autoritativa

É possível usar o Cloud Identity Premium ou o Google Workspace como o IdP e como fonte autorizada, como no diagrama a seguir.

Google como IdP e fonte autoritativa.

  • Use o Cloud Identity Premium ou o Google Workspace para gerenciar usuários e grupos.
  • Todos os serviços do Google usam o Cloud Identity Premium ou o Google Workspace como o IdP.
  • Você configura aplicativos corporativos e outros serviços de SaaS para usar o Google como o IdP.

Experiência do usuário

Nesta configuração, para um funcionário, a experiência do usuário de login é assim:

  1. Ao solicitar um recurso protegido ou acesso a um aplicativo corporativo, o funcionário é redirecionado para a tela de login do Google, que solicita seu endereço de e-mail e sua senha.
  2. Se a verificação em duas etapas estiver ativada, o funcionário precisará fornecer um segundo fator, como uma chave USB ou um código.
  3. Quando o funcionário é autenticado, ele é redirecionado para o recurso protegido.

Vantagens

Usar o Google como seu IdP e fonte autoritativa tem as seguintes vantagens:

Quando usar esta arquitetura

Considere usar o Google como IdP e fonte autoritativa nos seguintes cenários:

  • Você já usa o Google Workspace como sua solução de colaboração e produtividade.
  • Não há uma infraestrutura local ou um IdP que você precisa integrar ou que gostaria de manter separado de todos os seus recursos no Google (no Google Cloud, no Google Ads etc.).
  • Você não precisa de integração com um sistema de informações de recursos humanos (HRIS, na sigla em inglês) para gerenciar identidades.

Google como IdP com um HRIS como fonte autoritativa

Se você usa um sistema de informações de recursos humanos (HRIS, na sigla em inglês) para gerenciar o processo de integração e desligamento dos seus funcionários, ainda pode usar o Google como seu IdP. O Cloud Identity e o Google Workspace oferecem APIs que permitem que o HRIS e outros sistemas controlem o gerenciamento de usuários e grupos, conforme mostrado no diagrama a seguir.

Google como IdP com um HRIS como fonte autoritativa.

  • Você usa seu HRIS atual para gerenciar usuários e, como opção, grupos. O HRIS continua sendo a única fonte de confiança para o gerenciamento de identidades e provisiona automaticamente os usuários para o Cloud Identity ou o Google Workspace.
  • Todos os serviços do Google usam o Cloud Identity Premium ou o Google Workspace como o IdP.
  • Você configura aplicativos corporativos e outros serviços de SaaS para usar o Google como o IdP.

Experiência do usuário

Para um funcionário, a experiência do usuário de login é equivalente ao uso do Google como IdP e fonte autoritativa.

Vantagens

Usar o Google como o IdP e a fonte autoritativa tem as seguintes vantagens:

Quando usar esta arquitetura

Considere usar o Google como seu IdP com um HRIS como fonte autoritativa nos seguintes cenários:

  • Você tem um HRIS atual ou outro sistema que serve como fonte autoritativa para identidades.
  • Você já usa o Google Workspace como sua solução de colaboração e produtividade.
  • Não há uma infraestrutura local ou um IdP que você precise integrar ou que gostaria de manter separado do seu espaço do Google.

Usar um IdP externo

Caso sua organização já use um IdP como Active Directory, Azure AD, ForgeRock, Okta ou Ping Identity, será possível integrar o Google Cloud a esse IdP externo usando a federação.

Ao federar uma conta do Cloud Identity ou do Google Workspace com um IdP externo, é possível permitir que os funcionários usem a identidade e as credenciais atuais para fazer login nos serviços do Google, como o Google Cloud, o Google Marketing Platform e o Google Ads.

IDaaS externa como IdP e fonte autoritativa

Se você usar um provedor de identidade como serviço (IDaaS), como ForgeRock, Okta ou Ping Identity, poderá configurar a federação conforme ilustrado no diagrama a seguir.

IDaaS externa como IdP e fonte autoritativa.

  • O Cloud Identity ou o Google Workspace usa sua IDaaS como o IdP para logon único.
  • A IDaaS do cliente provisiona automaticamente usuários e grupos no Cloud Identity ou no Google Workspace.
  • Aplicativos corporativos atuais e outros serviços de SaaS podem continuar para sua IDaaS como um IdP.

Para saber mais sobre como federar o Cloud Identity ou o Google Workspace com o Okta, consulte Provisionamento de usuários e Logon único do Okta.

Experiência do usuário

Para um funcionário, a experiência do usuário de login é assim:

  1. Ao solicitar um recurso protegido, o funcionário é redirecionado para a tela de login do Google, que solicita o endereço de e-mail e a senha.
  2. O Login do Google redireciona você para a página de login da sua IDaaS.
  3. Você autentica com sua IDaaS. Dependendo da IDaaS, isso pode exigir que você forneça um segundo fator, como um código.
  4. Após a autenticação, você irá para o recurso protegido.

Vantagens

Usar uma IDaaS externo como IdP e fonte autoritativa tem as seguintes vantagens:

  • Você ativa uma experiência de Logon único para seus funcionários que se estende pelos serviços do Google e outros aplicativos integrados à IDaaS.
  • Se você configurou a IDaaS para exigir autenticação multifator, essa configuração será aplicada automaticamente ao Google Cloud.
  • Não é necessário sincronizar senhas ou outras credenciais com o Google.
  • É possível usar a versão gratuita do Cloud Identity.

Quando usar esta arquitetura

Considere usar uma IDaaS externa como IdP e fonte autoritativa nos seguintes cenários:

  • Você já usa um provedor de IDaaS, como ForgeRock, Okta ou Ping Identity, como seu IdP.

Práticas recomendadas

Veja nossas práticas recomendadas para federar o Google Cloud com um provedor de identidade externo.

Active Directory como IdP e fonte autoritativa

Se você usar o Active Directory como a fonte confiável para o gerenciamento de identidades, poderá configurar a federação conforme ilustrado no diagrama a seguir.

Active Directory como IdP e fonte autoritativa.

  • Use o Google Cloud Directory Sync (GCDS) para provisionar automaticamente usuários e grupos do Active Directory para o Cloud Identity ou o Google Workspace. O Google Cloud Directory Sync é uma ferramenta gratuita fornecida pelo Google que implementa o processo de sincronização e pode ser executada no Google Cloud ou no ambiente local. A sincronização é unidirecional para que o Active Directory permaneça a fonte confiável.
  • O Cloud Identity ou o Google Workspace usam os Serviços de federação do Active Directory (AD FS, na sigla em inglês) para logon único.
  • Os aplicativos corporativos atuais e outros serviços de SaaS podem continuar usando o AD FS como um IdP.

Se quiser uma variação desse padrão, use também o Active Directory Lightweight Directory Services (AD LDS) ou um diretório do LDAP diferente com o AD FS ou outro IdP compatível com SAML.

Para mais informações sobre essa abordagem, consulte Como federar o Google Cloud com o Active Directory.

Experiência do usuário

  1. Ao solicitar o recurso protegido, o funcionário é redirecionado para a tela de Login do Google, que solicita o endereço de e-mail.
  2. O Login do Google redireciona o funcionário para a página de login do AD FS.
  3. Dependendo da configuração do AD FS, o funcionário pode ver uma tela de login solicitando o nome de usuário e a senha do Active Directory. Como alternativa, o AD FS pode tentar fazer login do funcionário automaticamente com base no login do Windows.
  4. Depois que o AD FS autentica o funcionário, ele é redirecionado para o recurso protegido.

Vantagens

Usar o Active Directory como IdP e fonte autoritativa tem as seguintes vantagens:

  • Você ativa uma experiência de Logon único para seus funcionários que se estende pelos serviços do Google e pelo ambiente local.
  • Se você configurou o AD FS para exigir autenticação multifator, essa configuração é aplicada automaticamente ao Google Cloud.
  • Não é necessário sincronizar senhas ou outras credenciais com o Google.
  • É possível usar a versão gratuita do Cloud Identity.
  • Como as APIs que o GCDS usa são acessíveis publicamente, não é necessário configurar a conectividade híbrida entre a rede local e o Google Cloud.

Quando usar esta arquitetura

Considere usar o Active Directory como o IdP e a fonte autoritativa nos seguintes cenários:

  • Você tem uma infraestrutura do Active Directory.
  • Você quer oferecer uma experiência de login perfeita para usuários do Windows.

Práticas recomendadas

Considere estas práticas recomendadas:

  • O Active Directory e o Cloud Identity usam uma estrutura lógica diferente. Compreenda as diferenças e avalie qual método de mapeamento de domínios, identidades e grupos é mais adequado à sua situação. Para mais informações, consulte nosso guia sobre como federar o Google Cloud com o Active Directory.
  • Sincronize os grupos, além dos usuários. Com essa abordagem, é possível configurar o IAM para usar as associações a grupos no Active Directory para controlar quem tem acesso a quais recursos no Google Cloud.
  • Implante e exponha o AD FS para que os usuários corporativos possam acessá-lo. No entanto, faça isso na medida certa. Ainda que os usuários corporativos possam acessar o AD FS, não é preciso que o AD FS seja acessado pelo Cloud Identity ou pelo Google Workspace ou por qualquer aplicativo implantado no Google Cloud.
  • Pense em ativar a Autenticação Integrada do Windows (IWA, na sigla em inglês) no AD FS para que os usuários façam login automaticamente com base no login do Windows.
  • Se o AD FS ficar indisponível, talvez os usuários não consigam usar o Console do Google Cloud ou qualquer outro recurso que use o Google como IdP. Portanto, verifique se o AD FS e os controladores de domínio de que o AD FS depende são implantados e dimensionados para atender aos seus objetivos de disponibilidade.
  • Se você usa o Google Cloud para garantir a continuidade dos negócios, depender de um AD FS local pode prejudicar a intenção de usar o Google Cloud como uma cópia independente da implantação. Nesse caso, considere implantar réplicas de todos os sistemas relevantes no Google Cloud de uma das seguintes maneiras:

    • Estenda o domínio atual do Active Directory para o Google Cloud e implante o GCDS para execução no Google Cloud.
    • Execute servidores dedicados do AD FS no Google Cloud. Esses servidores usam os controladores de domínio do Active Directory em execução no Google Cloud.
    • Configure o Cloud Identity para usar os servidores do AD FS implantados no Google Cloud para Logon único.

Para saber mais, consulte Práticas recomendadas para federar o Google Cloud com um provedor de identidade externo.

Azure AD como IdP com o Active Directory como fonte autoritativa

Se você for um cliente do Microsoft Office 365 ou do Azure, talvez tenha conectado seu Active Directory local ao Azure AD. Se todas as contas de usuário que podem precisar de acesso ao Google Cloud já estiverem sendo sincronizadas com o Azure AD, reutilize essa integração federando o Cloud Identity com o Azure AD, conforme mostrado no diagrama a seguir.

Azure AD como IdP com o Active Directory como fonte autoritativa.

  • Use o Azure AD para provisionar automaticamente usuários e grupos para o Cloud Identity ou o Google Workspace. O Azure AD pode ser integrado a um Active Directory local.
  • O Cloud Identity ou o Google Workspace usam o Azure AD para logon único.
  • Os aplicativos corporativos atuais e outros serviços de SaaS podem continuar usando o Azure AD como um IdP.

Para informações mais detalhadas sobre essa abordagem, consulte Como federar o Google Cloud com o Azure Active Directory.

Experiência do usuário

  1. Ao solicitar o recurso protegido, o funcionário é redirecionado para a tela de Login do Google, que solicita o endereço de e-mail.
  2. O Login do Google os redireciona para a página de login do AD FS.
  3. Dependendo de como o Active Directory local está conectado ao Azure AD, o Azure AD pode solicitar um nome de usuário e uma senha ou redirecioná-los para um AD FS local.
  4. Depois que o funcionário é autenticado com o Azure AD, ele é redirecionado para o recurso protegido.

Vantagens

Usar o Azure AD como seu IdP com o Active Directory como fonte autoritativa tem várias vantagens:

  • Você ativa uma experiência de Logon único para seus funcionários que se estende pelos serviços do Google, pelo Azure e pelo ambiente local.
  • Se você configurou o Azure AD para exigir autenticação multifator, essa configuração será aplicada automaticamente ao Google Cloud.
  • Você não precisa instalar mais nenhum software no local.
  • Esse trabalho de integração pode ser vantajoso se o Active Directory local usa vários domínios ou florestas e se você definiu uma configuração personalizada do Azure AD Connect para mapear essa estrutura para um locatário do Azure AD.
  • Não é necessário sincronizar senhas ou outras credenciais com o Google.
  • É possível usar a versão gratuita do Cloud Identity.
  • É possível exibir o console do Google Cloud como um bloco no portal do Office 365.
  • Como as APIs que o Azure AD usa são acessíveis publicamente, não há necessidade de configurar a conectividade 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 fonte autoritativa nos seguintes cenários:

  • Você já usa o Azure AD e o integrou a uma infraestrutura atual do Active Directory.
  • Você quer oferecer uma experiência de login perfeita para usuários no Azure e no Google Cloud.

Práticas recomendadas

Siga estas práticas recomendadas:

  • Como o Azure AD e o Cloud Identity usam uma estrutura lógica diferente, você precisa entender as diferenças. Avalie qual método de mapeamento de domínios, identidades e grupos é mais adequado à sua situação. Para informações mais detalhadas, consulte Como federar o Google Cloud com o Azure AD.
  • Sincronize os grupos, além dos usuários. Essa abordagem permite configurar o IAM para usar assinaturas de grupo no Azure AD e controlar quem tem acesso aos recursos no Google Cloud.
  • Se você usa o Google Cloud para garantir a continuidade dos negócios, depender do Azure AD para autenticação pode prejudicar a intenção de usar o Google Cloud como uma cópia independente da implantação.

Para saber mais, consulte Práticas recomendadas para federar o Google Cloud com um provedor de identidade externo.

A seguir