Avalie o impacto da consolidação de contas de utilizador na federação

Last reviewed 2024-07-11 UTC

Se planeia federar o Cloud ID ou o Google Workspace com um fornecedor de identidade (IdP) externo, mas ainda precisa de consolidar as contas de consumidor existentes, este documento ajuda a compreender e avaliar a interação entre a federação e a consolidação. Este documento também mostra como configurar a federação de forma a não interferir com a sua capacidade de consolidar contas de consumidor existentes.

Interação entre a federação e a consolidação de contas de utilizador

Numa configuração federada, associa o Cloud ID ou o Google Workspace a uma origem autorizada externa para que a origem autorizada possa aprovisionar automaticamente contas de utilizador no Cloud ID ou no Google Workspace.

Normalmente, estas invariantes aplicam-se a uma configuração federada:

  1. A origem autorizada é a única origem para identidades.
  2. Não existem contas de utilizador no Cloud Identity nem no Google Workspace, exceto as aprovisionadas pela origem autorizada.
  3. O fornecedor de identidade SAML não permite o Início de sessão único da Google para identidades que não sejam aquelas para as quais a origem autorizada aprovisionou contas de utilizador.

Embora estas invariantes reflitam as práticas recomendadas para a federação Google Cloud com um fornecedor de identidade externo>, causam problemas quando quer migrar contas de consumidor existentes:

  1. As contas de consumidor existentes não têm origem na fonte autorizada. Estas contas já existem e têm agora de ser associadas a uma identidade conhecida pela fonte autorizada.
  2. As contas de consumidor existentes, assim que são migradas para o Cloud Identity ou o Google Workspace, são contas de utilizador que não foram aprovisionadas pela fonte autorizada. A fonte autorizada tem de reconhecer e "adotar" estas contas migradas.
  3. As identidades das contas de consumidor existentes podem ser desconhecidas para o fornecedor de identidade SAML, mas ainda têm de ter autorização para usar o Início de sessão único.

Para permitir a consolidação de contas de consumidor existentes, tem de configurar temporariamente a federação de uma forma segura para a consolidação de contas.

Torne a federação segura para a consolidação de contas

A tabela seguinte lista os requisitos a ter em conta para tornar a federação segura para a consolidação de contas. Se planear usar um IdP externo, mas ainda precisar de consolidar as contas de consumidor existentes, tem de garantir que a configuração cumpre inicialmente estes requisitos. Depois de concluir a migração das contas de consumidor existentes, pode alterar a configuração, uma vez que os requisitos deixam de se aplicar.

Requisito Justificação
Permita o Início de sessão único para identidades com contas de consumidor A migração de uma conta de consumidor requer uma transferência de conta. Um administrador do Cloud Identity ou do Google Workspace inicia a transferência de conta, mas, para a concluir, o proprietário da conta de consumidor tem de dar o seu consentimento. Como administrador, tem um controlo limitado sobre quando o consentimento é expresso e, por conseguinte, quando a transferência é realizada.

Assim que o proprietário expressar o consentimento e a transferência estiver concluída, todos os inícios de sessão subsequentes estão sujeitos ao início de sessão único através do seu IdP externo.

Para que o Início de sessão único seja bem-sucedido, independentemente de quando a transferência estiver concluída, certifique-se de que o seu IdP externo permite Inícios de sessão únicos para as identidades de todas as contas de consumidor que planeia migrar.

Impeça a administração de contas de utilizadores automática para identidades com contas de consumidor Se aprovisionar uma conta de utilizador para uma identidade que já tenha uma conta de consumidor, cria uma conta em conflito. Uma conta em conflito impede a transferência da propriedade da conta de consumidor, da respetiva configuração e de quaisquer dados associados para o Cloud ID ou o Google Workspace.

O comportamento predefinido de muitos IdPs externos é criar proativamente contas de utilizador no Cloud ID ou no Google Workspace. Este comportamento pode causar inadvertidamente a criação de contas em conflito.

Ao impedir o aprovisionamento automático de utilizadores para identidades com contas de utilizador existentes, evita a criação inadvertida de contas em conflito e garante que as contas de utilizador podem ser transferidas corretamente.

Se identificou contas de consumidor sem uma identidade correspondente no IdP externo que considera legítimas e que quer migrar para o Cloud Identity ou o Google Workspace, tem de se certificar de que a configuração da federação não interfere com a sua capacidade de migrar estas contas de consumidor.

Requisito Justificação
Impeça a eliminação de contas migradas sem uma identidade correspondente no IdP externo Se tiver uma conta de utilizador no Cloud ID ou no Google Workspace que não tenha uma identidade correspondente no seu IdP externo, o IdP pode considerar esta conta de utilizador órfã e pode suspendê-la ou eliminá-la.

Ao impedir que o seu IdP externo suspenda ou elimine contas migradas sem corresponder à identidade no IdP externo, evita perder a configuração e os dados associados às contas afetadas e garante que pode conciliar manualmente as contas.

Torne a federação do Microsoft Entra ID (anteriormente Azure AD) segura para a consolidação de contas

Se planeia federar o Cloud ID ou o Google Workspace com o Microsoft Entra ID (anteriormente Azure AD), pode usar a app da galeria do Google Workspace.

Quando ativa o aprovisionamento, o Microsoft Entra ID ignora as contas existentes no Cloud Identity ou no Google Workspace que não tenham uma contrapartida no Microsoft Entra ID. Deste modo, o requisito para impedir a eliminação de contas migradas sem uma identidade correspondente no IdP externo é sempre cumprido.

Consoante a forma como configura a app de galeria, tem de garantir que faz o seguinte:

Existem várias formas de cumprir estes requisitos. Cada abordagem tem vantagens e desvantagens.

Abordagem 1: não configure o aprovisionamento

Nesta abordagem, configura a app da galeria para processar o Início de sessão único, mas não configura o aprovisionamento automático de utilizadores. Se não configurar o aprovisionamento de utilizadores, impede o aprovisionamento automático de utilizadores para identidades com contas de consumidor.

Para permitir o início de sessão único para identidades com contas de consumidor, atribua a app a todas as identidades que possam precisar de acesso aos serviços Google, mesmo que as respetivas contas de consumidor existentes ainda estejam sujeitas a migração.

Para um utilizador que tenha uma conta de consumidor existente, a conta de utilizador do Cloud ID ou do Google Workspace correspondente é criada automaticamente quando o pedido de transferência é aceite. Esse utilizador pode, então, usar imediatamente o Início de sessão único.

Para os utilizadores que não têm uma conta de utilizador no Cloud ID ou no Google Workspace, tem de criar uma manualmente.

Embora esta abordagem cumpra os requisitos e seja a menos complexa de configurar, tem a limitação de que quaisquer alterações de atributos ou suspensões de utilizadores realizadas no Microsoft Entra ID não são propagadas para o Cloud ID nem para o Google Workspace.

Abordagem 2: duas apps com atribuição manual

Nesta abordagem, supera a limitação de ter de criar manualmente contas de utilizador no Google Workspace ou no Cloud ID para utilizadores que não têm uma conta existente. A ideia é usar duas apps de galeria, uma para o aprovisionamento e outra para o Início de sessão único:

  • A primeira app é usada exclusivamente para o aprovisionamento de utilizadores e grupos e tem o Início de sessão único desativado. Ao atribuir utilizadores a esta app, controla as contas que estão a ser aprovisionadas no Cloud ID ou no Google Workspace.
  • A segunda app é usada exclusivamente para o Início de sessão único e não está autorizada a aprovisionar utilizadores. Ao atribuir utilizadores a esta app, controla que utilizadores têm autorização para iniciar sessão.

Com estas duas apps, atribua utilizadores da seguinte forma:

Abordagem 3: duas apps com a criação de utilizadores desativada

Quando configurar o aprovisionamento, tem de autorizar o Microsoft Entra ID a aceder ao Cloud ID ou ao Google Workspace através de uma conta do Cloud ID ou do Google Workspace. Normalmente, é melhor usar uma conta de superadministrador dedicada para este fim, porque as contas de superadministrador estão isentas do início de sessão único (ou seja, qualquer configuração de SSO não se aplica a elas; continuam a usar palavras-passe para iniciar sessão).

No entanto, para este cenário, pode fazer com que o Microsoft Entra ID use uma conta mais restrita para a migração, uma que não permita que o Microsoft Entra ID crie utilizadores. Desta forma, impede eficazmente que o Azure aprovisione automaticamente contas de utilizador para identidades com contas de consumidor, independentemente dos utilizadores que são atribuídos à app de aprovisionamento.

Uma conta de utilizador de administrador restrita no Cloud ID ou no Google Workspace deve ter apenas os seguintes privilégios:

  • Unidades organizacionais > Ler
  • Utilizadores > Ler
  • Utilizadores > Atualizar
  • Grupos

Uma desvantagem desta abordagem é que, para os utilizadores sem contas não geridas, tem de criar manualmente contas no Cloud Identity ou no Google Workspace.

Estabeleça uma federação com o Microsoft Entra ID: comparação

A tabela seguinte resume as abordagens.

Permita o Início de sessão único para identidades com contas de consumidor Impeça o aprovisionamento automático de utilizadores para identidades com contas de consumidor Impeça a eliminação de contas migradas sem uma identidade correspondente no IdP externo Aprovisione automaticamente novas contas Atualize automaticamente as contas migradas
Abordagem 1: sem aprovisionamento X X
Abordagem 2: duas apps com atribuição manual Propensa a erros manuais
Abordagem 3: duas apps com a criação de utilizadores desativada X

Torne a federação do Active Directory segura para a conta

Se planear federar o Cloud ID ou o Google Workspace com o Active Directory, pode usar a Sincronização de diretórios do Google Cloud (GCDS) e os Serviços de Federação do Active Directory (AD FS). Quando configurar o GCDS e o AD FS, tem de se certificar de que faz o seguinte:

Existem várias formas de cumprir estes requisitos. Cada abordagem tem vantagens e desvantagens.

Abordagem 1: desative a GCDS

Nesta abordagem, configura o início de sessão único com o AD FS, mas não ativa o GCDS até terminar a migração das contas de utilizador não geridas. Ao desativar o GCDS, impede o aprovisionamento automático de utilizadores para identidades com contas de consumidor.

Para permitir o início de sessão único para identidades com contas de consumidor, crie uma política de controlo de acesso personalizada no AD FS e atribua todas as identidades que possam precisar de acesso aos serviços Google, mesmo que as respetivas contas de consumidor existentes ainda estejam sujeitas a migração.

Para um utilizador que tenha uma conta de consumidor existente, a conta de utilizador do Cloud ID ou do Google Workspace correspondente é criada automaticamente quando o pedido de transferência é aceite. Ao usar a política de controlo de acesso personalizado, garante que o utilizador pode usar imediatamente o Início de sessão único.

Para os utilizadores que não têm uma conta de utilizador no Cloud ID ou no Google Workspace, tem de criar uma manualmente.

Embora esta abordagem cumpra os requisitos e seja a menos complexa de configurar, tem a limitação de que quaisquer alterações de atributos ou suspensões de utilizadores realizadas no Active Directory não são propagadas para o Cloud Identity nem para o Google Workspace.

Abordagem 2: GCDS com atribuição manual

Nesta abordagem, supera a limitação de ter de criar manualmente contas de utilizador no Cloud ID ou no Google Workspace para utilizadores que não têm uma conta existente:

Uma limitação fundamental desta abordagem é que não pode impedir a eliminação de contas migradas sem uma identidade correspondente no IdP externo. Por conseguinte, a abordagem só é aplicável se não tiver contas de consumidor sem uma identidade correspondente no IdP externo.

Abordagem 3: não permitir que o GCDS crie utilizadores

Quando configurar o aprovisionamento, tem de autorizar o GCDS a aceder ao Cloud ID ou ao Google Workspace. Normalmente, é melhor usar uma conta de superadministrador dedicada para este fim, porque essas contas estão isentas do início de sessão único (ou seja, qualquer configuração de SSO não se aplica a elas; continuam a usar palavras-passe para iniciar sessão).

No entanto, para este cenário, pode fazer com que o GCDS use uma conta mais restrita para a migração, uma que não lhe permita criar utilizadores. Desta forma, impede eficazmente que a GCDS aprovisione automaticamente contas de utilizador para identidades com contas de consumidor e que elimine contas migradas sem uma identidade correspondente no IdP externo.

Uma conta de utilizador de administrador restrita no Cloud ID ou no Google Workspace só deve ter os seguintes privilégios:

  • Unidades organizacionais
  • Utilizadores > Ler
  • Utilizadores > Atualizar
  • Grupos
  • Gestão de esquema
  • Gestão do domínio

Uma desvantagem desta abordagem é que, para os utilizadores sem contas não geridas, tem de criar manualmente contas no Cloud Identity ou no Google Workspace.

Federe com o Active Directory: comparação

A tabela seguinte resume as abordagens.

Permita o Início de sessão único para identidades com contas de consumidor Impeça o aprovisionamento automático de utilizadores para identidades com contas de consumidor Impeça a eliminação de contas migradas sem uma identidade correspondente no IdP externo Aprovisione automaticamente novas contas Atualize automaticamente as contas migradas
Abordagem 1: não configure o aprovisionamento X X
Abordagem 2: GCDS com atribuição manual Propensa a erros manuais X
Abordagem 3: não permitir que o GCDS crie utilizadores X

Torne a federação do Okta segura para a consolidação de contas

Para federar o Cloud ID ou o Google Workspace com o Okta, pode usar a app Google Workspace a partir do catálogo de apps do Okta. Esta app pode processar o início de sessão único e aprovisionar utilizadores e grupos no Cloud ID ou no Google Workspace.

Quando usa a app Google Workspace para o aprovisionamento, o Okta ignora todos os utilizadores existentes no Cloud ID ou no Google Workspace que não tenham uma contrapartida no Okta. Deste modo, o requisito para impedir a eliminação de contas migradas sem uma identidade correspondente no IdP externo é sempre cumprido.

Consoante a forma como configura o Okta, ainda tem de fazer o seguinte:

Existem várias formas de cumprir estes requisitos. Cada abordagem tem vantagens e desvantagens.

Abordagem 1: não configure o aprovisionamento

Nesta abordagem, configura a app do Google Workspace para processar o Início de sessão único, mas não configura o aprovisionamento. Se não configurar o aprovisionamento de utilizadores, impede o aprovisionamento automático de utilizadores para identidades com contas de consumidor.

Para permitir o início de sessão único para identidades com contas de consumidor, atribua a app a todas as identidades que possam precisar de acesso aos serviços Google, mesmo que as respetivas contas de consumidor existentes ainda estejam sujeitas a migração. Os ícones do Google Workspace ou Google Cloud aparecem na página inicial do Okta de todas as identidades que foram atribuídas à app. No entanto, o início de sessão falha, a menos que exista uma conta de utilizador correspondente no lado da Google.

Para um utilizador que tenha uma conta de consumidor existente, a conta de utilizador do Cloud ID ou do Google Workspace correspondente é criada automaticamente quando o pedido de transferência é aceite. Esse utilizador pode, então, usar imediatamente o Início de sessão único.

Embora esta abordagem cumpra os requisitos e seja a menos complexa de configurar, tem a limitação de que quaisquer alterações de atributos ou suspensões de utilizadores realizadas no Okta não são propagadas para o Cloud ID nem para o Google Workspace. Outra desvantagem desta abordagem é que tem de criar manualmente contas no Cloud ID ou Google Workspace para todos os utilizadores que não tenham uma conta de consumidor existente.

Abordagem 2: aprovisionamento com atribuição manual

Nesta abordagem, configura a app Google Workspace para processar o início de sessão único e o aprovisionamento, mas ativa apenas as seguintes funcionalidades de aprovisionamento:

  • Criar utilizadores
  • Atualize os atributos do utilizador
  • Desative utilizadores

Quando atribui identidades à app, inclua as identidades que, eventualmente, precisam de acesso aos serviços Google, mas exclua todas as identidades que se sabe que têm uma conta de consumidor existente. Desta forma, impede a administração de contas de utilizadores automática para identidades com contas de consumidor.

Assim que um utilizador aceita um pedido de transferência, atribua o utilizador à app para que possa usar o Início de sessão único e aceder ao Google Workspace ou Google Cloud.

Uma desvantagem desta abordagem é que qualquer erro que cometa na atribuição pode levar imediatamente à criação de uma conta em conflito, o que torna esta abordagem muito mais arriscada do que algumas das outras abordagens.

Outra desvantagem desta abordagem é que provoca bloqueios temporários das contas migradas. Depois de aceitar um pedido de transferência, um utilizador tem de efetuar todas as inscrições subsequentes através do Okta. Estas tentativas de início de sessão vão falhar até que tenha atribuído o utilizador à app no Okta.

Abordagem 3: aprovisione com a criação de utilizadores desativada

Nesta abordagem, configura o Google Workspace para processar o início de sessão único e o aprovisionamento, mas ativa apenas as seguintes funcionalidades de aprovisionamento:

  • Atualize os atributos do utilizador
  • Desative utilizadores

Deixe a opção Criar utilizadores desativada e atribua todas as identidades que, eventualmente, precisem de acesso aos serviços Google à app. Inclua identidades com contas de consumidor existentes para permitir o início de sessão único para identidades com contas de consumidor.

Ao não permitir que o Okta crie contas, impede que o Okta faça o aprovisionamento automático de contas de utilizador para identidades com contas de consumidor. Ao mesmo tempo, esta configuração continua a permitir que o Okta propague alterações de atributos e suspensões de utilizadores para o Cloud ID ou o Google Workspace para os utilizadores que tenham uma Conta Google correspondente.

Para identidades que não tenham uma conta de utilizador correspondente no Cloud Identity ou Google Workspace, o Okta pode apresentar uma mensagem de erro na consola do administrador do Okta:

Mensagem de erro da Okta.

Para um utilizador que tenha uma conta de consumidor existente, a conta de utilizador do Cloud ID ou do Google Workspace correspondente é criada automaticamente quando o pedido de transferência é aceite. Esse utilizador pode, então, usar imediatamente o Início de sessão único. Embora a conta de utilizador esteja funcional neste momento, o Okta ainda pode não apresentar um ícone na página inicial do utilizador e, em alternativa, pode continuar a apresentar a mensagem de erro na IU de administração. Para corrigir este problema, tente novamente a tarefa de atribuição no painel de controlo do administrador do Okta.

Esta abordagem impede com êxito que o Okta administre automaticamente contas de utilizador para identidades com contas de consumidor, mas continua a permitir o início de sessão único para identidades com contas de consumidor. A abordagem também é menos suscetível a configurações incorretas acidentais do que a segunda abordagem. Uma desvantagem continua a ser que, para os utilizadores sem contas de consumidor existentes, tem de criar manualmente contas de utilizador no Cloud ID ou no Google Workspace.

Abordagem 4: duas apps com atribuição manual

Pode superar algumas das desvantagens das abordagens anteriores usando duas apps, uma para o aprovisionamento e outra para o início de sessão único:

  • Configure uma instância da app Google Workspace para processar apenas o aprovisionamento. A funcionalidade de início de sessão único da app não é usada. Ao atribuir utilizadores a esta app, controla as contas que estão a ser aprovisionadas no Cloud ID ou no Google Workspace. Pode garantir que esta app está efetivamente oculta dos seus utilizadores ativando a opção Não apresentar o ícone da aplicação aos utilizadores.
  • Configure outra instância da app Google Workspace apenas para fins de início de sessão único. Ao atribuir utilizadores a esta app, controla quem tem autorização para iniciar sessão.

Com estas duas apps, atribua utilizadores da seguinte forma:

Federe com a Okta: comparação

A tabela seguinte resume as abordagens.

Permita o Início de sessão único para identidades com contas de consumidor Impeça o aprovisionamento automático de utilizadores para identidades com contas de consumidor Impeça a eliminação de contas migradas sem uma identidade correspondente no IdP externo Aprovisione automaticamente novas contas Atualize automaticamente as contas migradas
Abordagem 1: sem aprovisionamento X X
Abordagem 2: aprovisionamento com atribuição manual X Arriscado
Abordagem 3: aprovisione com a criação de utilizadores desativada X
Abordagem 4: duas apps com atribuição manual Arriscado

O que se segue?