Este documento apresenta práticas recomendadas e orientações que ajudam a configurar a federação de forma consistente e segura. Estas orientações baseiam-se nas práticas recomendadas para usar o Cloud ID ou o Google Workspace com Google Cloud.
Todos os serviços Google, incluindo o Google Cloud, a Google Marketing Platform e o Google Ads, dependem do início de sessão na Google para autenticar os utilizadores. Em vez de criar e manter manualmente contas de utilizador no Cloud ID ou no Google Workspace para cada funcionário, pode federar o Cloud ID ou o Google Workspace com o seu fornecedor de identidade (IdP) externo , como o Active Directory ou o Microsoft Entra ID (anteriormente Azure Active Directory). A configuração da federação implica normalmente o seguinte:
- Aprovisionamento automático de contas de utilizador relevantes a partir de uma origem autorizada externa para o Cloud ID ou o Google Workspace.
- Permitir que os utilizadores usem um IdP externo para autenticar os serviços Google.
Mapeie identidades
A identidade de uma conta de utilizador gerida pelo Cloud ID ou pelo Google Workspace é definida pelo respetivo endereço de email principal. O endereço de email principal é apresentado como email da Conta Google na página da Conta Google. Para ser considerado válido, o endereço de email principal tem de usar um dos domínios que adicionou à sua conta do Cloud ID ou do Google Workspace.
O endereço de email principal também serve para os seguintes fins:
- O endereço de email principal é o nome de utilizador que um utilizador tem de indicar quando inicia sessão. Embora os utilizadores possam adicionar endereços de email alternativos ou alias à respetiva conta de utilizador Google, estes endereços não são considerados identidades e não podem ser usados para iniciar sessão.
- Quando um administrador precisa de enviar notificações aos utilizadores (por exemplo, para anunciar um potencial risco de segurança), essas notificações são enviadas apenas para o endereço de email principal.
Para configurar o início de sessão único e o aprovisionamento automático de utilizadores entre a Google e o seu IdP externo, tem de mapear as identidades no seu IdP externo para as identidades correspondentes no Cloud ID ou no Google Workspace. As secções seguintes descrevem as práticas recomendadas para estabelecer este mapeamento.
Use a mesma identidade em todos os sistemas federados
Para estabelecer um mapeamento, basta verificar se a declaração SAML que o IdP fornece à Google contém uma reivindicação NameID com um valor que corresponda ao endereço de email principal de um utilizador existente do Cloud Identity ou do Google Workspace. O IdP é livre de usar
qualquer mapeamento ou lógica aplicável para derivar uma reivindicação NameID adequada para
os seus utilizadores existentes.
Muitos IdPs baseiam-se em endereços de email (ou, de forma mais geral, em nomes em conformidade com o RFC 822) para identificar os utilizadores. Os exemplos incluem o seguinte:
- O atributo
userPrincipalNameno Active Directory é um nome compatível com RFC 822 que identifica exclusivamente um utilizador e que pode ser usado para iniciar sessão no Windows ou nos Active Directory Federation Services (AD FS). - O Entra ID usa o atributo
UserPrincipalNamepara identificar os utilizadores e permitir que iniciem sessão.
Se os utilizadores que o seu IdP externo gere já dependem de um endereço de email como a respetiva identidade, pode usar a mesma identidade como o endereço de email principal no Cloud Identity ou no Google Workspace. A utilização da mesma identidade do utilizador em sistemas federados tem várias vantagens:
Quando os utilizadores iniciam sessão numa ferramenta Google, como a Google Cloud consola, é-lhes pedido que indiquem o endereço de email principal do respetivo utilizador do Cloud ID ou Google Workspace antes de serem redirecionados para o seu IdP externo. Consoante o seu IdP, o utilizador pode ver outro ecrã de início de sessão que pede o nome de utilizador e a palavra-passe.
Se os endereços de email forem diferentes nestes passos, a sequência de ecrãs de início de sessão pode confundir facilmente os utilizadores finais. Por outro lado, se os utilizadores puderem usar uma identidade comum em todos os passos, não são expostos às diferenças técnicas entre os IdPs, o que minimiza a potencial confusão.
Se não tiver de fazer o mapeamento entre identidades de utilizadores, é mais fácil correlacionar os registos de auditoria do Google Workspace com os registos de sistemas no local. Google Cloud
Da mesma forma, se as aplicações implementadas no local e na Google Cloud precisarem de trocar dados que contenham identidades de utilizadores, evita a complexidade adicional de ter de mapear os identificadores dos utilizadores.
Para mais detalhes sobre o mapeamento de utilizadores do Active Directory ou do Entra ID para o Cloud Identity ou o Google Workspace, consulte o guia do Active Directory ou do Microsoft Entra ID.
Certifique-se de que as identidades usam endereços de email encaminháveis
Google Cloud usa o endereço de email principal de um utilizador para enviar emails de notificação. Seguem-se alguns exemplos destas notificações:
Alertas de orçamento: se tiver configurado um alerta de orçamento, Google Cloud envia uma notificação aos administradores de faturação e aos utilizadores de faturação quando um limite de orçamento é ultrapassado.
Notificações de pagamento: todas as notificações ou alertas relacionados com pagamentos são enviados para os endereços de email dos utilizadores de pagamentos configurados para a conta de faturação afetada.
Convites de projetos: se atribuir a função de administrador do projeto a um utilizador que faça parte de uma conta do Cloud ID ou do Google Workspace diferente daquela à qual a organização do projeto está associada, é enviado um convite ao utilizador. Antes de a função recém-concedida entrar em vigor, o utilizador tem de aceitar o convite clicando num link na mensagem de email.
Respostas a registos de apoio ao cliente e outras notificações do apoio técnico.
Se usar o Google Workspace e tiver configurado corretamente os registos MX DNS necessários, todos os emails de notificação enviados para o endereço de email principal são entregues na caixa de entrada do Gmail do utilizador correspondente.
Para os utilizadores do Cloud Identity, Google Cloud também tenta enviar emails de notificação, mas o email tem de ser processado pela sua infraestrutura de email existente. Para garantir que os utilizadores do Cloud Identity não perdem notificações, certifique-se de que o seu sistema de email existente aceita mensagens enviadas para os endereços de email principais dos utilizadores do Cloud Identity e que encaminha este email para as caixas de correio corretas. Faça o seguinte:
Certifique-se de que todos os domínios adicionados ao Cloud ID têm registos MX de DNS que apontam para o seu sistema de email existente.
Certifique-se de que o endereço de email principal de um utilizador do Cloud ID corresponde a uma caixa de correio existente no seu sistema de email. Se existir uma incompatibilidade entre o endereço de email principal usado pelo Cloud ID e o endereço de email do utilizador, configure um alias no seu sistema de email existente para que o email enviado para cada endereço de email principal seja encaminhado para a caixa de correio correta.
Se estas soluções não forem práticas, considere adicionar o Google Workspace à sua conta do Cloud ID existente e atribuir licenças do Google Workspace aos utilizadores principais responsáveis pela faturação ou pela interação com o apoio técnico e, por isso, mais propensos a receber notificações.
Avalie as opções de migração para contas de consumidor existentes
Se os seus funcionários estavam a usar serviços Google, como o Google Ad Manager, Google AdSense, ou o Google Analytics antes de a sua organização se inscrever no Cloud Identity ou no Google Workspace, é possível que os seus funcionários tenham usado contas de consumidor para aceder a estes serviços.
Permitir que os funcionários usem contas de consumidor para fins empresariais pode ser arriscado. Para ver mais detalhes sobre estes riscos e como pode apresentar contas de consumidor existentes, consulte o artigo Avaliar as suas Contas Google existentes.
Pode processar as contas de consumidor existentes das seguintes formas:
- Manter as contas de consumidor tal como estão, aceitando potenciais riscos.
- Migre as contas para o Cloud ID ou o Google Workspace iniciando uma transferência.
- Forçar os proprietários das contas de utilizador não geridas a alterar o respetivo endereço de email para usar um domínio diferente.
Para mais detalhes sobre como consolidar contas de consumidor existentes, consulte o artigo Avaliar opções de consolidação de identidade.
A forma como decide lidar com as contas de consumidor influencia como e em que sequência configura a federação. Avalie as contas de consumidor existentes que os seus utilizadores usam antes de começar a criar contas de utilizador ou configurar o início de sessão único no Cloud Identity ou Google Workspace.
Mapeie conjuntos de identidades
Quando tiver definido como as identidades individuais são mapeadas entre o seu IdP externo e o Cloud ID ou o Google Workspace, tem de determinar o conjunto de identidades para as quais ativar o acesso aos serviços Google.
O conjunto eficaz de identidades que podem ser autenticadas nos serviços Google é a interseção de dois conjuntos:
- Identidades externas que mapeiam para uma identidade no Cloud ID ou no Google Workspace.
Identidades externas que o seu IdP externo permite para o início de sessão único no Cloud ID ou no Google Workspace.
O processo de controlo de quem tem autorização para usar o início de sessão único difere consoante o IdP que usar. Por exemplo, o Entra ID baseia-se em atribuições, enquanto o AD FS usa políticas de controlo de acesso.
Limite o conjunto de identidades que podem autenticar-se nos serviços Google
Consoante a forma como planeia usar o Google Cloud, o Google Workspace e outras ferramentas Google, todos os funcionários da sua organização ou apenas um subconjunto dos mesmos têm de conseguir autenticar-se nos serviços Google.
Se planeia conceder acesso aos serviços Google apenas a um subconjunto dos funcionários da sua organização, é melhor restringir a autenticação a este conjunto de utilizadores. Ao restringir o número de utilizadores que podem autenticar, estabelece uma camada de defesa adicional que ajuda caso tenha configurado acidentalmente uma regra de controlo de acesso demasiado permissiva.
Pode limitar o conjunto de utilizadores que podem autenticar-se no Google das seguintes formas:
- Minimize o número de contas de utilizador no Cloud ID ou no Google Workspace. Se não existir uma conta de utilizador mapeada, qualquer tentativa de autenticação por parte de um utilizador falha, mesmo que o IdP permita que o utilizador inicie sessão no Cloud ID ou no Google Workspace através do início de sessão único.
- Configure o início de sessão único no seu IdP para minimizar o número de utilizadores que têm autorização para iniciar sessão no Cloud ID ou no Google Workspace.
A melhor abordagem para a sua situação depende de ter contas de consumidor que precisa de migrar.
Limite o conjunto de identidades que aprovisiona se ainda precisar de migrar contas de consumidor
Só pode migrar uma conta de consumidor para o Cloud ID ou o Google Workspace se não tiver criado uma conta de utilizador com a mesma identidade no Cloud ID ou no Google Workspace.
Se tiver contas de consumidor existentes que ainda planeia migrar, tem de ter cuidado para não criar acidentalmente contas de utilizador em conflito. Siga estas diretrizes:
- Limite a autenticação criando novas contas de utilizador do Cloud ID ou do Google Workspace apenas para utilizadores que delas necessitem e que não tenham uma conta de consumidor existente.
- Evite bloquear inadvertidamente as contas migradas permitindo o início de sessão único não só para os utilizadores para os quais cria contas de utilizador no Cloud Identity ou Google Workspace, mas também para todas as contas de consumidor que ainda não foram migradas.
O diagrama seguinte mostra a sobreposição e a interligação dos diferentes tipos de identidades.
No diagrama, as identidades com uma conta de utilizador no Cloud ID ou no Google Workspace estão na elipse mais pequena (amarela). Essa elipse está contida na segunda elipse (azul), que contém identidades capazes de autenticar. A terceira elipse, a maior (cinzenta), contém as outras e consiste nas identidades que têm uma conta de utilizador no seu IdP. Para ver detalhes sobre como configurar o Active Directory, o Entra ID ou o Okta, consulte o nosso guia de práticas recomendadas separado.
Impeça novas inscrições de contas de consumidor
A adição de um domínio, como example.com, à sua conta do Cloud Identity ou do Google Workspace não impede que os funcionários se inscrevam em novas contas de consumidor com o mesmo domínio. Estas novas contas de consumidor são apresentadas como utilizadores não geridos na sua conta do Cloud ID ou do Google Workspace, mas não podem usar o início de sessão único nem qualquer outra configuração que tenha aplicado na sua conta do Cloud ID ou do Google Workspace.
Uma forma de bloquear a criação de uma nova conta de consumidor é criar uma conta de utilizador no Cloud ID ou no Google Workspace com o mesmo endereço de email. Por exemplo, se criou um utilizador alice@example.com na sua conta do Cloud ID ou Google Workspace, todas as tentativas de um funcionário de se inscrever numa nova conta de consumidor com a mesma identidade falham. No entanto, se ainda não existir nenhum utilizador correspondente no Cloud Identity ou no Google Workspace, a inscrição numa nova conta de consumidor é bem-sucedida.
Quando não existirem mais contas de consumidor para migrar para o Cloud Identity, evite novas inscrições de contas de consumidor aplicando a seguinte configuração:
Limite a autenticação permitindo que apenas os utilizadores relevantes utilizem o início de sessão único no Cloud ID ou no Google Workspace.
Aprovisione utilizadores do Cloud ID ou do Google Workspace para todos os funcionários. Certifique-se de que as contas de utilizador usam o endereço de email corporativo do funcionário como o endereço de email principal ou o alias para que não seja possível criar novas contas de consumidor com o mesmo endereço de email. Se possível, mantenha as contas de utilizador que não estão ativadas para o início de sessão único num estado suspenso.
O diagrama seguinte mostra esta configuração.
Se ainda estiver no processo de migração de contas de consumidor, pode monitorizar temporariamente as novas inscrições de contas de consumidor captando os emails de validação enviados durante o processo de inscrição. Os emails de validação usam um endereço de remetente do envelope que corresponde a *@idverification.bounces.google.com.
Configure um filtro no seu sistema de email que identifique emails com este endereço do remetente do envelope e os retenha para revisão interna.
Transforme as identidades do Cloud ID ou do Google Workspace num subconjunto das identidades no seu IdP externo
A sua conta do Cloud ID ou do Google Workspace pode conter contas de utilizador com identidades que não são mapeadas para nenhum utilizador no seu IdP externo. Existem dois cenários típicos que podem resultar nestas contas de utilizador:
- Cria uma nova conta de utilizador no Cloud ID ou no Google Workspace e usa um endereço de email principal que não é mapeado para nenhum utilizador no seu IdP externo.
- Tem uma conta de utilizador no Cloud ID ou no Google Workspace que é mapeada para uma identidade no seu IdP externo, mas depois elimina a identidade no IdP externo. Por exemplo, pode eliminar a identidade se o funcionário sair da empresa.
Quando ativa o início de sessão único no Cloud Identity ou no Google Workspace, todos os utilizadores (com exceção dos superadministradores) são obrigados a usar o início de sessão único. Para uma conta de utilizador do Cloud ID ou do Google Workspace que não esteja mapeada para uma identidade no seu IdP externo, qualquer tentativa de usar o início de sessão único falha. Uma conta de utilizador sem uma contrapartida deste tipo está efetivamente extinta, mas pode continuar a representar um risco, como nas seguintes situações:
Se, em algum momento, o início de sessão único for desativado temporária ou permanentemente, a conta de utilizador pode ser usada novamente. Isto pode permitir que um antigo funcionário inicie sessão e aceda a recursos empresariais.
O nome da conta de utilizador eliminada pode ser reutilizado. Por exemplo, um funcionário que entra na empresa pode ter o mesmo nome que um funcionário diferente que saiu da empresa meses ou anos antes. Se a conta de utilizador do funcionário anterior tiver sido eliminada entretanto, é possível que possa atribuir ao novo funcionário o nome de utilizador que o funcionário anterior usava.
A conta de utilizador do novo funcionário pode ter um ID interno diferente do do antigo funcionário. No entanto, do ponto de vista da federação, as duas contas de utilizador são consideradas iguais se ambas forem mapeadas para o mesmo endereço de email principal no Cloud ID ou no Google Workspace. Como resultado, quando o novo funcionário inicia sessão no Google, pode "herdar" dados, definições e autorizações existentes do antigo funcionário.
Os utilizadores superadministradores do Cloud Identity e do Google Workspace estão isentos do requisito de utilização do Início de sessão único, mas continuam a poder utilizar o Início de sessão único quando o início de sessão é iniciado pelo IdP. A capacidade de usar o Início de sessão único iniciado pelo IdP torna os utilizadores com privilégios de superadministrador sensíveis à apropriação de nomes se não tiverem uma contrapartida no seu IdP externo.
Considere o seguinte exemplo: a Alice tem um utilizador superadministrador
alice-admin@example.com no Cloud ID ou no Google Workspace
e não usa a validação em dois passos. A Mallory, que não sabe a palavra-passe da Alice, encontra uma forma de criar um novo utilizador no IdP externo que é mapeado para alice-admin@example.com. Embora esta conta de utilizador recém-criada possa não ter privilégios especiais e não tenha relação com a conta de utilizador de Alice, o facto de partilhar uma identidade comum com a conta de superadministrador de Alice permite agora que Mallory use o início de sessão único iniciado pelo IdP e se autentique como alice-admin@example.com.
Para mitigar este risco de roubo de nome, certifique-se de que as identidades do Cloud ID ou do Google Workspace são um subconjunto das identidades no seu IdP externo. A melhor forma de o fazer é mapear todo o ciclo de vida da conta de utilizador, conforme implementado pelo seu IdP externo, para o ciclo de vida da conta de utilizador no Cloud Identity ou Google Workspace.
Use utilizadores superadministradores dedicados
As contas de superadministrador do Google Workspace e do Cloud ID têm um conjunto de autorizações avançado que se aplica não só à conta do Cloud ID ou do Google Workspace, mas também a uma Google Cloud organização associada. Uma vez que apenas um pequeno número de atividades requer privilégios de superadministrador, sempre que possível, é melhor limitar o número de administradores com acesso de superadministrador e usar contas de utilizador com menos privilégios para a administração diária da sua conta ou Google Cloud organização.
Quando tiver identificado os administradores que requerem acesso de superadministrador, crie contas de utilizador de superadministrador dedicadas, por exemplo:
- Crie uma conta de utilizador com a identidade
alice@example.come atribua autorizações normais. Esta conta deve ser usada diariamente para atividades de rotina. Crie uma segunda conta de utilizador com a identidade
alice-admin@example.come atribua-lhe privilégios de superutilizador. É uma prática recomendada que a Alice use esta conta apenas para ocasiões em que são necessários privilégios de superadministrador.Para garantir que os emails de notificação enviados para este endereço de email são recebidos na caixa de correio do utilizador, configure o Google Workspace ou o seu sistema de email existente para que o endereço de email
alice-admin@example.comseja um alias ou seja encaminhado paraalice@example.com.
Certifique-se de que ambas as identidades são reconhecidas pelo seu IdP externo para que o conjunto de identidades no Cloud ID ou Google Workspace continue a ser um subconjunto das identidades no seu IdP externo.
Recomendamos que siga um esquema de nomenclatura para estas contas de superadministrador dedicadas, de modo que nos registos de auditoria possa acompanhar onde e como estão a ser usadas. Por exemplo, adicione -admin ao nome de utilizador, como no exemplo anterior.
Limite o número de utilizadores de serviços no Google Workspace e Cloud ID
O seu IdP externo pode conter não só contas de utilizador para funcionários, mas também contas de utilizador destinadas a utilizadores de máquinas, como aplicações, ferramentas ou tarefas em segundo plano.
Por outro lado, a forma preferencial de Google Cloud ativar uma aplicação para autenticar e aceder às APIs Google é implementar uma das seguintes abordagens:
Uma aplicação ou uma ferramenta Web que precise de aceder a APIs ou serviços Google em nome de um utilizador final deve usar o OAuth 2.0 ou o OpenID Connect. Ao usar um destes protocolos, a aplicação solicita primeiro o consentimento do utilizador final para aceder aos dados do utilizador e, ao receber o consentimento, fica então apta a realizar o acesso em nome do utilizador final.
Se o acesso a APIs ou serviços não deve ser em nome de um utilizador final, mas sim em nome da própria aplicação, é melhor usar Google Cloud contas de serviço para autenticação e, em seguida, conceder acesso à conta de serviço aos recursos através do IAM.
Se Google Cloud as contas de serviço tiverem as funções adequadas no IAM, podem ser usadas para autenticar e usar qualquer API Cloud. Se precisar de conceder acesso a uma conta de serviço a APIs que estão fora do Google Cloud, por exemplo, à API Directory ou à API Drive, pode usar a delegação ao nível do domínio do Google Workspace.
Com a delegação ao nível do domínio do Google Workspace, permite que uma conta de serviço atue em nome de um utilizador do Cloud ID ou do Google Workspace. Uma vez que a delegação é um privilégio poderoso, recomendamos que use a delegação ao nível do domínio do Google Workspace apenas nos casos em que a abordagem OAuth não seja prática.
Use um utilizador do Cloud ID ou do Google Workspace dedicado para cada Google Cloud conta de serviço ativada para delegação em todo o domínio do Google Workspace. Crie este utilizador no seu IdP externo e, em seguida, faculte-o ao Cloud ID ou ao Google Workspace para que o conjunto de utilizadores no Cloud ID ou no Google Workspace continue a ser um subconjunto dos utilizadores no seu IdP externo.
Evite criar utilizadores de serviço no Cloud ID e no Google Workspace que não pretenda usar para a delegação em todo o domínio do Google Workspace.
Mapeie os ciclos de vida das contas de utilizador
As contas de utilizador no seu IdP externo seguem um determinado ciclo de vida. Normalmente, este ciclo de vida reflete a relação de emprego entre o funcionário e a empresa:
- É criada uma nova conta de utilizador para um funcionário que se junta à organização.
- A conta de utilizador pode ser suspensa temporariamente e, posteriormente, reativada, por exemplo, quando o funcionário entra de férias.
- Quando o utilizador sai da empresa, a conta de utilizador é eliminada ou mantida num estado de suspensão durante um determinado período de retenção antes de ser eliminada.
O diagrama seguinte ilustra este ciclo de vida.
Esta secção apresenta práticas recomendadas para garantir que o ciclo de vida das contas de utilizador no Cloud ID ou Google Workspace segue o ciclo de vida das contas de utilizador correspondentes no seu IdP externo.
Designe o seu IdP externo como a fonte de informações fidedignas
Muitos sistemas de informações de RH (HRIS), IdPs e adaptadores só suportam o aprovisionamento de utilizadores unidirecional. Isto significa que as alterações efetuadas no HRIS ou no IdP são propagadas para o Cloud ID ou o Google Workspace, mas as alterações efetuadas no Cloud ID ou no Google Workspace não são propagadas novamente.
Para evitar inconsistências causadas pelo aprovisionamento unidirecional, designe o seu IdP externo como a fonte de informação fidedigna. Use exclusivamente o seu IdP externo (ou HRIS) para criar, modificar ou eliminar utilizadores e confie no aprovisionamento automático para que as alterações sejam propagadas ao Google Workspace e ao Cloud Identity. Ao designar o seu IdP externo como a fonte de informações fidedignas, limita o risco de inconsistências e de ter modificações manuais substituídas pelo IdP.
Automatize o aprovisionamento de utilizadores no Cloud ID ou no Google Workspace
Para permitir que um funcionário se autentique no Google através do Início de sessão único, tem de criar primeiro uma conta de utilizador para o funcionário no Cloud Identity ou no Google Workspace. Para garantir a consistência com o seu IdP externo, é melhor automatizar o processo de aprovisionamento destas contas de utilizador no Cloud ID ou no Google Workspace:
- Ao automatizar o aprovisionamento, pode garantir que as identidades do Cloud ID ou do Google Workspace são sempre um subconjunto das identidades no seu IdP externo.
- Minimiza o risco de introduzir inadvertidamente uma incompatibilidade entre uma identidade no Cloud ID ou Google Workspace e a identidade correspondente no seu IdP externo. As não correspondências, como um erro ortográfico acidental do endereço de email, podem fazer com que os funcionários tenham problemas ao iniciar sessão.
- Minimiza o esforço de administração manual.
Se usar um HRIS para gerir o processo de integração, uma forma de automatizar o aprovisionamento de utilizadores é configurar o HRIS para aprovisionar contas de utilizador no seu IdP externo e no Cloud ID ou Google Workspace, como no diagrama seguinte.
Para que esta configuração funcione bem, tem de garantir que o seu SRHI aprovisiona contas de utilizador para que estas sejam corretamente mapeadas entre si. Além disso, o SRHI tem de processar a decisão de que contas de utilizador aprovisionar para o Cloud ID ou o Google Workspace.
Outra forma de automatizar o aprovisionamento de utilizadores que funciona independentemente de um HRIS é usar o seu IdP externo como a origem autorizada para o aprovisionamento de utilizadores no Cloud Identity ou no Google Workspace. Nesta configuração, a configuração para mapear contas de utilizadores e conjuntos de contas de utilizadores é gerida no IdP ou pelo adaptador, conforme mostra o diagrama seguinte.
Se usar o Active Directory como IdP, pode duplicar esta configuração usando Google Cloud a sincronização de diretórios. Outros IdPs, como o Entra ID ou o Okta, têm adaptadores incorporados para o aprovisionamento de utilizadores no Google Workspace. Uma vez que o Google Workspace e o Cloud ID se baseiam na mesma plataforma e usam as mesmas APIs, estes adaptadores também podem ser usados para o Cloud ID.
Propague eventos de suspensão para o Cloud ID ou o Google Workspace
Quando um funcionário sai da organização, quer seja temporária ou permanentemente, recomendamos que revogue o acesso do funcionário aos serviços Google. Ao suspender a conta de utilizador do funcionário no seu IdP externo, revoga a respetiva capacidade de usar o início de sessão único para autenticar no Google, mas isso pode não revogar totalmente o acesso a todos os serviços Google. As seguintes situações podem continuar a ocorrer:
- Se o utilizador do Cloud ID ou do Google Workspace tiver uma sessão do navegador ativa, a sessão continua a funcionar. Todos os tokens OAuth já obtidos também continuam a ser válidos.
- Se o utilizador tiver privilégios de superadministrador ou se tiver configurado máscaras de rede, o funcionário pode continuar a iniciar sessão com uma palavra-passe.
- A conta do utilizador ainda pode receber notificações de Google Cloud, incluindo alertas de orçamento.
- Se o utilizador tiver uma licença do Google Workspace atribuída, os emails continuam a ser entregues na caixa de correio do utilizador, o utilizador continua a aparecer no livro de endereços e pode continuar a ser apresentado como disponível no Calendário Google.
- Se permitir que os utilizadores utilizem apps menos seguras, o utilizador pode continuar a aceder ao Gmail, ao Calendário Google e a outros dados através de palavras-passe de apps.
Para revogar totalmente o acesso aos serviços Google, propague os eventos de suspensão para o Cloud ID ou o Google Workspace das seguintes formas:
Certifique-se de que, sempre que uma conta de utilizador é suspensa no seu IdP externo, a conta de utilizador correspondente no Cloud ID ou no Google Workspace também é suspensa. A suspensão de um utilizador no Cloud Identity ou no Google Workspace termina as sessões ativas do navegador, invalida os tokens e revoga todos os outros acessos.
Da mesma forma, quando reativa uma conta de utilizador no seu IdP externo, certifique-se de que também reativa a conta de utilizador correspondente no Cloud ID ou Google Workspace.
A suspensão de uma conta de utilizador no Cloud ID ou no Google Workspace é uma operação não destrutiva. Enquanto a conta de utilizador estiver suspensa, os dados do utilizador são retidos, as licenças do Google Workspace permanecem associadas e as funções atribuídas no Google Cloud permanecem inalteradas.
Propague eventos de eliminação para o Cloud ID ou o Google Workspace
Quando um funcionário sai permanentemente da organização, pode decidir não só suspender a conta de utilizador do funcionário no seu IdP externo, mas também eliminá-la.
Se eliminar uma conta de utilizador no seu IdP externo, mas não eliminar o utilizador correspondente do Cloud ID ou do Google Workspace, o conjunto de utilizadores no Cloud ID e no Google Workspace deixa de ser um subconjunto dos utilizadores no seu IdP externo. Isto pode tornar-se um problema no futuro se um novo funcionário entrar na sua organização e tiver o mesmo nome que o funcionário que saiu da empresa. Se criar uma conta de utilizador no seu IdP para o novo funcionário, pode reutilizar o nome de utilizador do funcionário antigo, o que faz com que a nova conta de utilizador seja mapeada para a conta de utilizador antiga no Cloud Identity ou Google Workspace. Como tal, o novo funcionário pode obter acesso aos dados e às definições do antigo funcionário.
Pode evitar os riscos associados a contas de utilizador órfãs do Cloud ID ou do Google Workspace eliminando um utilizador do Cloud ID ou do Google Workspace assim que a conta de utilizador correspondente no seu IdP for eliminada.
A eliminação de um utilizador do Cloud ID ou do Google Workspace é uma operação destrutiva que só pode ser anulada num determinado período. Consoante os serviços Google consumidos pelo utilizador, a eliminação do utilizador pode fazer com que os dados associados sejam eliminados permanentemente e, por conseguinte, pode não cumprir os seus requisitos de conformidade.
Para preservar as definições e os dados do utilizador durante um determinado período de retenção antes de os eliminar permanentemente, implemente uma das seguintes abordagens:
Atrasar a eliminação da conta de utilizador no seu IdP externo, mantendo o utilizador num estado suspenso durante um determinado período de retenção. Elimine o utilizador no seu IdP e no Cloud Identity ou Google Workspace após o período de retenção ter terminado.
Quando elimina uma conta de utilizador no seu IdP externo, suspenda o utilizador do Cloud Identity ou do Google Workspace correspondente e altere o respetivo endereço de email principal para um nome que seja pouco provável que cause um conflito. Por exemplo, mude o nome de
alice@example.comparaobsolete-yyyymmdd-alice@example.com, em queyyyymmddreflete a data de eliminação no seu IdP externo. Manter a conta de utilizador com o nome alterado num estado suspenso durante um período de retenção e eliminá-la após o período de retenção ter terminado.
Para preservar os dados do Google Workspace de utilizadores suspensos, mantenha a licença do Google Workspace atribuída ao utilizador ou mude-a para uma licença de utilizador arquivado para garantir que as regras de retenção do Google Workspace Vault continuam a ser aplicadas e que os dados do utilizador são preservados.
Início de sessão único
Todos os produtos Google, incluindo serviços como o Google Cloud,
Google Ads e o YouTube, usam o
início de sessão Google
para autenticar os utilizadores. Um serviço inicia o processo de autenticação ao
redirecionar um utilizador para accounts.google.com, onde o utilizador vê o ecrã de início de sessão
do Google e é-lhe pedido o respetivo endereço de email. Consoante o domínio do endereço de email fornecido, a conta de utilizador é, em seguida, procurada no Gmail, no diretório de contas de consumidor ou, se o domínio corresponder ao respetivo domínio principal, secundário ou alias, numa conta do Cloud ID ou do Google Workspace.
O diagrama seguinte ilustra este processo de autenticação.
Se configurar uma conta do Cloud ID ou do Google Workspace para usar o Início de sessão único, os utilizadores são redirecionados para um IdP externo para autenticação. Quando o IdP externo conclui a autenticação, o resultado é retransmitido para o início de sessão Google através de uma afirmação SAML. Esta afirmação SAML serve como prova de uma autenticação bem-sucedida. A afirmação contém o endereço de email do utilizador e é assinada pelo certificado do IdP externo para que o Início de sessão do Google possa validar a respetiva autenticidade.
Este processo é denominado início de sessão único iniciado pelo fornecedor de serviços e aplica-se a todos os utilizadores, exceto aos superadministradores. Os superadministradores nunca são redirecionados para um IdP externo e, em vez disso, é-lhes pedida uma palavra-passe.
Alguns IdPs também suportam o Início de sessão único iniciado pelo IdP. Neste modelo, o utilizador autentica-se no IdP externo e, em seguida, segue um link que aponta para um serviço Google, como o Google Cloud ou o Google Ads. Se o Início de sessão único tiver sido ativado para uma conta do Cloud Identity ou do Google Workspace, todos os utilizadores dessa conta podem usar o Início de sessão único iniciado pelo IdP, incluindo os superadministradores.
Minimize o conjunto de atributos transmitidos em afirmações SAML
Depois de um utilizador ser autenticado no IdP externo, o Cloud ID ou o Google Workspace usam a declaração SAML transmitida pelo IdP externo para estabelecer uma sessão. Além de validar a respetiva autenticidade, este processo inclui a identificação da conta de utilizador do Cloud ID ou do Google Workspace que corresponde ao valor NameID na declaração SAML.
Espera-se que o valor NameID contenha o endereço de email principal da conta de utilizador a autenticar. O endereço de email é sensível a maiúsculas e minúsculas. Os alias e os
endereços de email alternativos não são considerados.
Para evitar erros ortográficos ou de capitalização acidentais, é melhor aprovisionar automaticamente as contas de utilizador.
As afirmações SAML podem conter atributos adicionais, mas não são consideradas durante a autenticação. Os atributos que contêm informações, como o nome próprio, o apelido ou as associações a grupos de um utilizador, são ignorados porque a conta do utilizador no Cloud ID ou no Google Workspace é considerada a única origem destas informações do utilizador.
Para minimizar o tamanho das afirmações SAML, configure o seu IdP para não incluir atributos que não sejam necessários para o Início de sessão da Google.
Use google.com como emissor
As sessões de Início de sessão Google não estão restritas a uma única ferramenta ou domínio. Em alternativa, assim que uma sessão é estabelecida, é válida em todos os serviços Google aos quais o utilizador tem acesso. Esta lista de serviços pode incluir serviços como o Google Cloud e o Google Ads, bem como serviços como a Pesquisa Google e o YouTube.
A natureza global de uma sessão reflete-se na troca de protocolos SAML: por predefinição, a Google usa google.com como emissor (o elemento Issuer no pedido SAML) nos pedidos SAML e espera que as afirmações SAML especifiquem google.com como público (o elemento Audience na resposta SAML).
Pode alterar esta predefinição ativando a opção Usar um emissor específico do domínio quando configura o início de sessão único no Cloud ID ou no Google Workspace. Ative a opção de emissor específico do domínio apenas se tiver mais do que uma conta do Cloud ID ou do Google Workspace (e, por conseguinte, vários domínios) e o seu IdP precisar de conseguir distinguir entre inícios de sessão iniciados por uma conta do Cloud ID ou do Google Workspace e outra conta. Quando ativa a opção, os pedidos SAML usam
google.com/a/DOMAIN como emissor e esperam
google.com/a/DOMAIN como público-alvo, onde
DOMAIN é o domínio principal da conta do
Cloud ID ou Google Workspace.
Em todos os outros casos, mantenha a definição predefinida para usar google.com como emissor e configure o seu IdP externo para especificar google.com como público-alvo nas afirmações SAML. Consoante o seu IdP, esta definição também pode ser designada por emissor, identificador de confiança da parte fidedigna ou ID da entidade.
Alinhe a duração das sessões da Google e das sessões do IdP
Quando um utilizador conclui o processo de início de sessão único e é estabelecida uma sessão, a sessão de início de sessão com o Google permanece ativa durante um determinado período. Quando este período expira ou se o utilizador terminar sessão, é-lhe pedido que volte a fazer a autenticação repetindo o processo de início de sessão único.
Por predefinição, a duração da sessão para os serviços Google é de 14 dias. Para utilizadores com uma licença do Cloud Identity Premium ou Google Workspace Business, pode alterar a duração da sessão predefinida para um período diferente, como 8 horas.
Pode controlar a duração da sessão usada pelo Google Cloud. A sessão aplica-se à consola, bem como à CLI gcloud e a outros clientes API. Google Cloud Google Cloud Pode definir a Google Cloud duração da sessão em todos os tipos de contas do Cloud ID e do Google Workspace.
A maioria dos IdPs externos também mantém uma sessão para utilizadores autenticados. Se a duração da sessão do IdP for superior à duração da sessão da Google, a reautenticação pode ocorrer de forma silenciosa. Ou seja, o utilizador é redirecionado para o IdP, mas pode não ter de introduzir novamente as credenciais. A reautenticação silenciosa pode prejudicar a intenção de reduzir a duração das sessões da Google.
Para garantir que os utilizadores têm de introduzir novamente as respetivas credenciais após a expiração de uma sessão da Google, configure a duração da sessão da Google e a duração da sessão do IdP de modo que a duração da sessão do IdP seja inferior à duração da sessão da Google.
Desative o Início de sessão único para utilizadores superadministradores
Para os utilizadores superadministradores, o SSO é opcional: podem usar o SSO quando o início de sessão é iniciado pelo IdP, mas também podem iniciar sessão usando o nome de utilizador e a palavra-passe.
Se não planeia usar o início de sessão único iniciado pelo IdP para utilizadores superadministradores, pode diminuir o risco através do seguinte procedimento:
- Adicione uma unidade organizacional dedicada para superadministradores.
- Atribua um perfil de SSO à unidade organizacional que desativa o Início de sessão único.
Caso contrário, se planeia usar o Início de sessão único iniciado pelo IdP, certifique-se de que aplica a validação pós-SSO aos utilizadores superadministradores.
Autenticação multifator
A ativação do início de sessão único entre o Cloud ID ou o Google Workspace e o seu IdP externo melhora a experiência do utilizador para os funcionários. Os utilizadores têm de autenticar com menos frequência e não precisam de memorizar credenciais separadas para aceder aos serviços Google.
No entanto, permitir que os utilizadores se autentiquem facilmente em vários serviços e ambientes também significa que o potencial impacto das credenciais de utilizador comprometidas aumenta. Se o nome de utilizador e a palavra-passe de um utilizador forem perdidos ou roubados, um atacante pode usar estas credenciais para aceder a recursos não só no seu ambiente existente, mas também em um ou mais serviços Google.
Para mitigar o risco de roubo de credenciais, é melhor usar a autenticação multifator para todas as contas de utilizador.
Aplique a autenticação multifator aos utilizadores
Quando configura o início de sessão único para a sua conta do Cloud ID ou do Google Workspace, os utilizadores sem privilégios de superadministrador têm de usar o seu IdP externo para autenticação.
Configure o seu IdP para exigir a utilização de um segundo fator (como um código único ou uma chave USB) para aplicar a autenticação multifator sempre que o Início de sessão único na Google for utilizado.
Se o seu IdP externo não suportar a autenticação multifator, considere ativar a validação pós-SSO para que a Google faça uma validação adicional depois de o utilizador regressar da autenticação com o seu IdP externo.
Evite usar máscaras de rede, porque podem ser usadas indevidamente como forma de contornar a autenticação multifator para os utilizadores.
Aplique a autenticação em dois passos da Google para utilizadores superadministradores
Os utilizadores com privilégios de superadministrador não são redirecionados para o seu IdP externo quando tentam iniciar sessão na Google Cloud consola ou noutros sites Google. Em alternativa, é pedido aos utilizadores superadministradores que façam a autenticação através do nome de utilizador e da palavra-passe.
Uma vez que os utilizadores com privilégios de superadministrador podem autenticar-se através do nome de utilizador e da palavra-passe, não estão sujeitos a políticas de autenticação multifator que o seu IdP possa aplicar. Para proteger os utilizadores superadministradores, aplique a autenticação em dois passos da Google a todos os utilizadores superadministradores.
Normalmente, os utilizadores com função de superadministrador pertencem a uma de duas categorias:
Utilizadores superadministradores personalizados: estes utilizadores são personalizados e destinam-se a ser usados por um único administrador. Recomendamos que aplique a validação em dois passos a todos os utilizadores superadministradores personalizados.
Utilizadores superadministradores de máquinas: embora seja melhor evitar estas contas de utilizador, por vezes, são necessárias para ativar ferramentas como o Cloud Directory Sync ou a app de galeria do Entra ID para gerir utilizadores e grupos no Cloud ID ou Google Workspace.
Limite o número de utilizadores superadministradores da máquina e tente ativar a validação em 2 passos sempre que possível.
Para utilizadores que não usam o início de sessão único, pode aplicar a autenticação em dois passos na conta globalmente, por unidade organizacional ou por grupo:
Se não tiver utilizadores superadministradores de máquinas que não possam usar a validação em dois passos, é melhor ativar a aplicação para todos os utilizadores. Ao aplicar a validação em dois passos a todos os utilizadores, evita o risco de esquecer-se de utilizadores acidentalmente.
Se tiver alguns utilizadores superadministradores de máquinas que não podem usar a validação em dois passos, use um grupo dedicado para controlar a validação em dois passos. Crie um novo grupo, ative a aplicação para o grupo e adicione todos os superutilizadores relevantes ao mesmo.
Para mais detalhes sobre a utilização da autenticação em dois passos para proteger os utilizadores superadministradores, consulte as nossas práticas recomendadas de segurança para contas de administrador.
Aplique a validação após o SSO para utilizadores superadministradores
Embora os utilizadores superadministradores não tenham de usar o Início de sessão único, continuam a poder usá-lo quando iniciado pelo IdP. Para garantir que os utilizadores superadministradores estão sempre sujeitos à validação em dois passos, mesmo que se autentiquem através do início de sessão iniciado pelo IdP, ative as validações de SSO adicionais e a validação em dois passos para todos os utilizadores superadministradores.
As validações de SSO adicionais podem parecer redundantes nos casos em que o seu IdP já aplica a autenticação multifator, mas a definição pode ajudar a proteger os utilizadores superadministradores se o seu IdP for comprometido.
Não restrinja o Início de sessão único por máscara de rede
Quando configura o início de sessão único no Cloud ID ou Google Workspace, pode especificar opcionalmente uma máscara de rede. Se especificar uma máscara, apenas os utilizadores com endereços IP correspondentes à máscara estão sujeitos ao início de sessão único. Os outros utilizadores são solicitados a introduzir uma palavra-passe quando iniciam sessão.
Se usar máscaras de rede, pode estar a prejudicar a autenticação multifator aplicada pelo seu IdP externo. Por exemplo, ao alterar as localizações ou usar uma VPN, um utilizador pode controlar se a máscara de rede se aplica ou não. Se aplicar a autenticação multifator no IdP externo, esta tática pode permitir que um utilizador ou um atacante contorne as políticas de autenticação multifator configuradas no seu IdP externo.
Para garantir que a autenticação multifator se aplica de forma consistente, independentemente da localização ou do endereço IP de um utilizador, evite restringir o início de sessão único por máscara de rede.
Para restringir o acesso a recursos por endereço IP, configure uma lista de autorizações de IP adequada no seu IdP externo ou use o acesso sensível ao contexto para Google Cloud e o Google Workspace.
O que se segue?
- Saiba mais sobre práticas recomendadas adicionais:
- Compare os padrões para federar um IdP externo com o Google Cloud.