Este documento apresenta práticas recomendadas e orientações que ajudam você a configurar a federação de maneira consistente e segura. A orientação baseia-se nas práticas recomendadas sobre como usar o Cloud Identity ou o Google Workspace com o Google Cloud.
Todos os serviços do Google, incluindo o Google Cloud, o Google Marketing Platform e o Google Ads, dependem do Login do Google para autenticar usuários. Em vez de criar e manter manualmente contas de usuário no Cloud Identity ou no Google Workspace para cada funcionário, é possível federar o Cloud Identity ou o Google Workspace com seu provedor de identidade externo (IdP, na sigla em inglês), como o Active Directory ou o Azure Active Directory. A configuração da federação normalmente envolve:
- O provisionamento automático de contas de usuário relevantes de uma origem autorizada externa para o Cloud Identity ou o Google Workspace.
- A autorização dos usuários para usar um IdP externo na autenticação nos serviços do Google.
Como mapear identidades
A identidade de uma conta de usuário gerenciada pelo Cloud Identity ou pelo Google Workspace é definida pelo endereço de e-mail principal. O endereço de e-mail principal é listado como e-mail da Conta do Google na página da Conta do Google. Para ser considerado válido, o endereço de e-mail principal deve usar um dos domínios adicionados à sua conta do Cloud Identity ou do Google Workspace.
Além disso, ele também atende às seguintes finalidades:
- O endereço de e-mail principal é o nome de usuário que um usuário deve fornecer ao fazer login. Embora os usuários possam adicionar endereços de e-mail ou aliases alternativos à conta de usuário do Google, esses endereços não são considerados identidades e não podem ser usados para fazer login.
- Quando um administrador precisa enviar notificações aos usuários (por exemplo, para comunicar um possível risco de segurança), elas são enviadas apenas para o endereço de e-mail principal.
Para configurar o Logon único (SSO, na sigla em inglês) e o provisionamento automático de usuários entre o Google e o IdP externo, é necessário mapear as identidades no IdP externo para as identidades correspondentes no Cloud Identity ou no Google Workspace. As seções a seguir descrevem as práticas recomendadas sobre como estabelecer esse mapeamento.
Usar a mesma identidade em todos os sistemas federados
Para estabelecer um mapeamento, é somente necessário verificar se a declaração SAML
que o IdP fornece ao Google contém uma
declaração NameID
com um valor que corresponda ao endereço de e-mail principal de um usuário atual do Cloud Identity ou
do Google Workspace. O IdP é livre
para usar qualquer mapeamento ou lógica aplicável para gerar uma declaração NameID adequada
para os usuários existentes.
Muitos IdPs dependem de endereços de e-mail (ou, geralmente, de nomes compatíveis com o RFC 822) para identificar usuários. Os exemplos incluem:
- O atributo
userPrincipalNameno Active Directory é um nome compatível com RFC 822 que identifica exclusivamente um usuário, podendo ser usado para fazer login no Windows ou no Active Directory Campaign Services (AD FS). - O Azure Active Directory usa o atributo
UserPrincipalNamepara identificar usuários e permitir que eles façam login.
Se os usuários gerenciados pelo seu IdP externo já dependem de um endereço de e-mail como identidade, é possível usar a mesma identidade do endereço de e-mail principal no Cloud Identity ou no Google Workspace. Usar a mesma identidade de usuário em sistemas federados tem muitas vantagens:
Quando os usuários fazem login em uma ferramenta do Google, como o console do Google Cloud, eles são solicitados a fornecer o endereço de e-mail principal do usuário do Cloud Identity ou do Google Workspace antes de serem redirecionados ao IdP externo. Dependendo do seu IdP, pode ser exibida outra tela de login que solicita o nome de usuário e a senha.
Se os endereços de e-mail forem diferentes para essas etapas, a sequência de telas de login poderá facilmente confundir os usuários finais. Por outro lado, se for possível que os usuários usem uma identidade comum em todas as etapas, eles não serão expostos às diferenças técnicas entre os IdPs, o que minimiza possíveis confusões.
Se não é necessário mapear entre identidades de usuário, fica mais fácil correlacionar registros de auditoria do Google Cloud com registros de sistemas locais.
Da mesma forma, se os aplicativos implantados no local e no Google Cloud precisarem trocar dados contendo identidades de usuários, evite a complexidade extra de ter que mapear identificadores de usuários.
Para mais detalhes sobre o mapeamento de usuários do Active Directory ou do Azure AD para o Cloud Identity ou o Google Workspace, consulte o guia do Active Directory ou do Azure AD.
Verificar se as identidades usam endereços de e-mail roteáveis
O Google Cloud usa o endereço de e-mail principal de um usuário para enviar e-mails de notificação. São exemplos dessas notificações:
Alertas de orçamento: se você tiver configurado um alerta de orçamento, o Google Cloud enviará uma notificação aos administradores e usuários de faturamento quando um limite de orçamento for ultrapassado.
Notificações de pagamento: todas as notificações ou alertas relacionados a pagamentos são enviados aos endereços de e-mail dos usuários de pagamento configurados para a conta de faturamento afetada.
Convites do projeto: se você atribuir o papel de administrador do projeto a um usuário que faz parte de uma conta do Cloud Identity ou do Google Workspace diferente da qual o projeto está associado, um convite será enviado ao usuário. Para que a função recém-concedida entre em vigor, o usuário precisa aceitar o convite clicando em um link na mensagem de e-mail.
Responde a histórico de consultas e outras notificações do suporte.
Se você usa o Google Workspace e configurou corretamente os registros MX do DNS necessários, todos os e-mails de notificação enviados para o endereço de e-mail principal são enviados para a caixa de entrada do Gmail do usuário correspondente.
Para usuários do Cloud Identity, o Google Cloud também tenta enviar e-mails de notificação, mas o e-mail precisa ser processado pela infraestrutura de e-mail atual. Para garantir que os usuários do Cloud Identity não percam notificações, verifique se o sistema de e-mail atual aceita mensagens enviadas para os endereços de e-mail principais dos usuários do Cloud Identity e se encaminha esse e-mail para as caixas de correio corretas. Faça o seguinte:
Verifique se todos os domínios adicionados ao Cloud Identity têm registros MX do DNS que apontam para seu sistema de e-mail atual.
Verifique se o endereço de e-mail principal de um usuário do Cloud Identity corresponde a uma caixa de correio existente no seu sistema de e-mail. Se houver uma incompatibilidade entre o endereço de e-mail principal usado pelo Cloud Identity e o endereço de e-mail do usuário, configure um alias no sistema de e-mail existente para que os e-mails enviados para cada endereço de e-mail principal sejam roteados para a caixa de correio correta.
Se estas soluções não forem práticas, considere adicionar o Google Workspace à sua conta do Cloud Identity e atribuir licenças do Google Workspace aos principais usuários responsáveis pelo faturamento ou pela interação com o suporte, que estejam propensos a receber notificações.
Avaliar as opções de migração para contas pessoais existentes
Se seus funcionários estavam usando serviços do Google, como o Google Ad Manager, o Google AdSense ou o Google Analytics antes de sua organização se inscrever no Cloud Identity ou Google Workspace, é possível que eles usavam contas pessoais para acessar esses serviços.
Permitir que os funcionários usem contas pessoais para fins comerciais pode ser arriscado. Para mais detalhes sobre esses riscos e sobre como é possível exibir contas pessoais existentes, consulte Como avaliar suas contas do Google atuais.
É possível processar contas pessoais existentes das seguintes maneiras:
- mantenha as contas pessoais como estão, aceitando possíveis riscos;
- migre as contas para o Cloud Identity ou o Google Workspace iniciando uma transferência;
- force os proprietários das contas de usuário não gerenciadas a alterar o endereço de e-mail para usar um domínio diferente.
Para mais detalhes sobre como consolidar contas pessoais existentes, consulte Como avaliar opções de consolidação de identidade.
Como você decide lidar com contas pessoais influencia como e em qual sequência você configurou a federação. Avalie todas as contas pessoais atuais que os usuários usam antes de começar a criar contas de usuário ou configurar o Logon único no Cloud Identity ou no Google Workspace.
Como mapear conjuntos de identidade
Depois de definir como as identidades individuais são mapeadas entre o IdP externo e o Cloud Identity ou o Google Workspace, determine o conjunto de identidades para ativar o acesso aos serviços do Google.
O conjunto efetivo de identidades que podem ser autenticadas nos serviços do Google é a interseção de dois conjuntos:
- identidades externas que mapeiam para uma identidade no Cloud Identity ou no Google Workspace;
identidades externas que o IdP externo permite para o Logon único no Cloud Identity ou no Google Workspace.
O processo para controlar quem tem permissão para usar o Logon único varia de acordo com o IdP que você usa. Por exemplo, o Azure AD depende de atribuições, enquanto o AD FS usa políticas de controle de acesso.
Limitar o conjunto de identidades que podem ser autenticadas nos serviços do Google
Dependendo de como você planeja usar o Google Cloud, o Google Workspace e outras ferramentas do Google, todos os funcionários da sua organização ou apenas um subconjunto deles precisam ser autenticados nos serviços do Google.
Se você planeja conceder a apenas um subconjunto de funcionários da sua organização o acesso aos serviços do Google, é melhor restringir a autenticação a esse conjunto de usuários. Ao restringir o número de usuários que podem ser autenticados, estabeleça uma camada extra de defesa que serve de suporte caso tenha configurado acidentalmente alguma regra de controle de acesso para ser muito permissiva.
É possível limitar o conjunto de usuários que podem se autenticar no Google das seguintes maneiras:
- minimize o número de contas de usuário no Cloud Identity ou no Google Workspace. Se não houver uma conta de usuário mapeada, qualquer tentativa de autenticação do usuário falhará, mesmo que o IdP permita que o usuário faça login no Cloud Identity ou no Google Workspace usando o Logon único;
- configure o Logon único no IdP para minimizar o número de usuários que têm permissão para fazer login no Cloud Identity ou no Google Workspace.
A melhor abordagem para sua situação depende de haver ou não contas pessoais que devem ser migradas.
Limitar o conjunto de identidades provisionadas se ainda for necessário migrar contas pessoais
Só será possível migrar uma conta pessoal para o Cloud Identity ou o Google Workspace se não tiver criado uma conta de usuário com a mesma identidade no Cloud Identity ou no Google Workspace.
Se ainda houver contas pessoais que planeja migrar, é necessário ter cuidado para não criar acidentalmente contas de usuário conflitantes. Siga as seguintes diretrizes:
- limite a autenticação criando novas contas de usuário do Cloud Identity ou do Google Workspace apenas para usuários que precisam delas e que não têm uma conta pessoal existente;
- evite o bloqueio acidental de contas migradas. Para isso, permita o Logon único não apenas para os usuários para os quais você cria contas de usuário no Cloud Identity ou no Google Workspace, mas também para todas as contas pessoais que ainda não foram migradas.
O diagrama a seguir mostra como diferentes tipos de identidades se sobrepõem e se interrelacionam.
No diagrama, as identidades com uma conta de usuário no Cloud Identity ou no Google Workspace estão na menor elipse (amarela). Essa elipse está contida na segunda elipse (azul), que contém identidades que podem ser autenticadas. A terceira e maior elipse (rosa) contém as outras e consiste nas identidades que têm uma conta de usuário no seu IdP. Para saber mais sobre como configurar o Active Directory, o Azure AD ou o Okta, consulte nosso guia separado de práticas recomendadas.
Evitar novas inscrições de contas pessoais
Adicionar 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 pessoais usando o mesmo domínio. Estas novas contas pessoais são
exibidas como usuários não gerenciados na sua conta do Cloud Identity
ou do Google Workspace, mas não têm permissão para usar o Logon único ou
qualquer outra configuração aplicada na sua conta do
Cloud Identity ou do Google Workspace.
Uma maneira de bloquear a criação de uma nova conta pessoal é criar uma conta de
usuário no Cloud Identity ou no Google Workspace com o mesmo endereço
de e-mail. Por exemplo, se você criou um usuário alice@example.com na sua
conta do Cloud Identity ou do Google Workspace, todas as tentativas de
um funcionário de se inscrever em uma nova conta pessoal com a mesma identidade
falharão. No entanto, se ainda não houver um usuário correspondente no Cloud Identity ou
no Google Workspace, a inscrição para uma nova conta pessoal será
bem-sucedida.
Quando não houver mais contas pessoais para migrar para o Cloud Identity, impeça novas inscrições de contas pessoais aplicando a seguinte configuração:
limite a autenticação permitindo que apenas usuários relevantes usem o Logon único no Cloud Identity ou no Google Workspace.
provisione usuários do Cloud Identity ou do Google Workspace para todos os funcionários. verifique se as contas de usuário usam o endereço de e-mail corporativo do funcionário como o endereço ou alias principal para que nenhuma nova conta pessoal possa ser criada usando o mesmo endereço de e-mail. se possível, mantenha as contas de usuário que não estão ativadas para o Logon único em um estado suspenso.
O diagrama a seguir mostra essa configuração.
Se você ainda estiver no processo de migração de contas pessoais, poderá
monitorar temporariamente as novas inscrições de contas pessoais ao capturar os e-mails de
verificação enviados durante o processo de inscrição. Os e-mails de verificação usam um
endereço de remetente do envelope que corresponde a *@idverification.bounces.google.com.
Configure um filtro no sistema de e-mail que identifique os e-mails com esse endereço de
remetente do envelope e os retenha para revisão interna.
Tornar as identidades do Cloud Identity ou do Google Workspace um subconjunto das identidades no seu IdP externo
Sua conta do Cloud Identity ou do Google Workspace pode conter contas de usuário com identidades que não são mapeadas para nenhum usuário no IdP externo. Há dois cenários típicos que podem resultar nessas contas de usuário:
- você cria uma nova conta de usuário no Cloud Identity ou no Google Workspace e usa um endereço de e-mail principal que não é mapeado para nenhum usuário no seu IdP externo;
- você tem uma conta de usuário no Cloud Identity ou no Google Workspace que é mapeada para uma identidade no IdP externo, mas exclui a identidade nele. Por exemplo, poderá excluir a identidade se o funcionário sair da empresa.
Quando você ativa o Logon único no Cloud Identity ou no Google Workspace, todos os usuários (com exceção dos superadministradores) são forçados a usar o Logon único. Para uma conta de usuário do Cloud Identity ou do Google Workspace que não é mapeada para uma identidade no IdP externo, qualquer tentativa de usar o Logon único falhará. Uma conta de usuário sem essa versão está efetivamente extinta, mas ainda pode representar um risco, como nas seguintes situações:
Se, em algum momento, o Logon único for desativado temporária ou permanentemente, a conta de usuário poderá ser usada novamente. Isso pode permitir que um ex-funcionário faça login e acesse recursos corporativos.
O nome da conta de usuário excluída pode ser reutilizado. Por exemplo, um funcionário que entra na empresa pode compartilhar o mesmo nome com outro funcionário que saiu da empresa meses ou anos antes. Se a conta de usuário anterior do funcionário tiver sido excluída, é possível atribuir ao novo funcionário o nome de usuário que o ex-funcionário costumava usar.
A conta de usuário do novo funcionário pode ter um ID interno diferente daquele do ex-funcionário. No entanto, do ponto de vista da federação, as duas contas de usuário serão consideradas iguais se forem mapeadas para o mesmo endereço de e-mail principal no Cloud Identity ou no Google Workspace. Como resultado, quando o novo funcionário fizer login no Google, ele poderá "herdar" os dados, as configurações e as permissões existentes do ex-funcionário.
Os usuários de superadministrador do Cloud Identity e do Google Workspace estão isentos do requisito de usar o Logon único, mas ainda podem usá-lo quando o logon é iniciado pelo IdP. A capacidade de usar o Logon único iniciado pelo IdP torna os usuários superadministradores vulneráveis ao cybersquatting de nomes na ausência de equivalentes no IdP externo.
Veja o exemplo a seguir: Alice tem um usuário superadministrador
alice-admin@example.com no Cloud Identity ou no Google Workspace
e não usa a verificação em duas etapas. Mallory, que não sabe a senha de Alice,
encontra uma maneira de criar um novo usuário no IdP externo que é mapeado para
alice-admin@example.com. Embora essa conta de usuário recém-criada não tenha
privilégios especiais, bem como nenhuma relação com a conta de usuário da Alice, o
fato de compartilhar uma identidade comum com a conta de superadministrador da Alice agora
permite que Mallory use o Logon único iniciado pelo IdP e faça a autenticação como
alice-admin@example.com.
Para reduzir esse risco, verifique se as identidades do Cloud Identity ou do Google Workspace são um subconjunto das identidades no IdP externo. A melhor maneira de fazer isso é mapear todo o ciclo de vida da conta de usuário conforme implementado pelo IdP externo para o ciclo de vida da conta de usuário no Cloud Identity ou no Google Workspace.
Usar usuários superadministradores dedicados
As contas de superadministrador do Google Workspace e do Cloud Identity têm um conjunto avançado de permissões que se aplicam não apenas à conta do Cloud Identity ou do Google Workspace, mas também a uma organização associada do Google Cloud. Como 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 usuário com menos privilégios para a administração diária da sua conta ou organização do Google Cloud.
Depois de identificar os administradores que exigem acesso de superadministrador, crie contas de usuário de superadministrador dedicada. Por exemplo:
- crie uma conta de usuário com a identidade
alice@example.come atribua permissões regulares. Essa conta deve ser usada diariamente para atividades cotidianas; crie uma segunda conta de usuário com a identidade
alice-admin@example.come atribua a ela privilégios de superusuário. É uma prática recomendada para Alice usar essa conta apenas em ocasiões em que os privilégios de superadministrador são obrigatórios.Para garantir que os e-mails de notificação enviados para esse endereço de e-mail sejam recebidos na caixa de correio do usuário, configure o Google Workspace ou seu sistema de e-mail existente para que o endereço de e-mail
alice-admin@example.comseja um alias ou seja encaminhado paraalice@example.com.
Verifique se as duas identidades são reconhecidas pelo IdP externo para que o conjunto de identidades no Cloud Identity ou no Google Workspace continue sendo um subconjunto das identidades no IdP externo.
Recomendamos seguir um esquema de nomenclatura voltado a essas contas de superadministrador dedicadas
para que, nos registros de auditoria, você possa rastrear onde e como elas estão sendo usadas. Por
exemplo, adicione -admin ao nome de usuário, como no exemplo anterior.
Limitar o número de usuários do serviço no Google Workspace e no Cloud Identity
Seu IdP externo pode conter não apenas contas de usuário de funcionários, mas também contas de usuário destinadas a usuários de máquina, como aplicativos, ferramentas ou jobs em segundo plano.
Por outro lado, no Google Cloud a melhor forma de permitir que um aplicativo autentique e acesse as APIs do Google é implementar uma das seguintes abordagens:
Um aplicativo ou ferramenta da Web que precisam acessar APIs ou serviços do Google em nome de um usuário final devem usar o OAuth 2.0 ou o OpenID Connect. Ao usar um desses protocolos, o aplicativo primeiro solicita o consentimento do usuário final para acessar os dados do usuário e, ao recebê-lo, pode realizar esse procedimento de acesso.
Se o acesso a APIs ou serviços não deve ser em nome de um usuário final, mas em nome do próprio aplicativo, é melhor usar contas de serviço do Google Cloud para autenticação e conceder à conta de serviço o acesso aos recursos. Faça isso usando o IAM.
Se as contas de serviço do Google Cloud receberem os papéis apropriados no IAM, elas poderão ser usadas para autenticar e usar qualquer API do Cloud. Se precisar conceder a uma conta de serviço o acesso a APIs que estão fora do Google Cloud, por exemplo, à API Directory ou à API Drive, use a delegação em todo o domínio do Google Workspace.
Com ela, você ativa uma conta de serviço para agir em nome de um usuário do Cloud Identity ou do Google Workspace. Como a delegação é um privilégio poderoso, recomendamos usá-la apenas nos casos em que a abordagem do OAuth não é prática.
Use um usuário dedicado do Cloud Identity ou do Google Workspace para cada conta de serviço do Google Cloud ativada para a delegação em todo o domínio do Google Workspace. Crie esse usuário no IdP externo e provisione-o no Cloud Identity ou no Google Workspace para que o conjunto de usuários neles continue sendo um subconjunto dos usuários no IdP externo.
Evite criar usuários de serviço no Cloud Identity e no Google Workspace que você não pretende usar para a delegação em todo o domínio do Google Workspace.
Como mapear ciclos de vida da conta de usuário
As contas de usuário no seu IdP externo seguem um determinado ciclo de vida. Normalmente, esse ciclo de vida reflete o vínculo empregatício entre o funcionário e a empresa:
- Uma nova conta de usuário é criada para um funcionário que está integrando o quadro da organização.
- A conta de usuário pode ser temporariamente suspensa e reativada posteriormente, por exemplo, quando o funcionário sair.
- Quando o usuário sai da empresa, sua conta é excluída ou mantida em um estado suspenso por um determinado período de retenção antes de ser excluída.
O diagrama a seguir ilustra esse ciclo de vida.
Nesta seção, listamos as práticas recomendadas sobre como garantir que o ciclo de vida das contas de usuário no Cloud Identity ou no Google Workspace siga o ciclo de vida das contas de usuário correspondentes no seu IdP externo.
Designar o IdP externo como a fonte da verdade
Muitos sistemas de informações de RH (RHIS, na sigla em inglês), IdPs e adaptadores são compatíveis apenas com o provisionamento unilateral de usuários. Isso significa que as alterações realizadas no RHIS ou no IdP são propagadas para o Cloud Identity ou o Google Workspace, ao contrário das realizadas no Cloud Identity e no Google Workspace.
Para evitar inconsistências causadas pelo provisionamento unilateral, designe seu IdP externo como a fonte da verdade. Use unicamente seu IdP externo (ou RHIS, na sigla em inglês) para criar, modificar ou excluir usuários, e conte com o provisionamento automatizado para que as alterações sejam propagadas para o Google Workspace e o Cloud Identity. Ao designar seu IdP externo como a fonte da verdade, você limita o risco de inconsistências e de ter alterações manuais modificadas pelo IdP.
Automatizar o provisionamento de usuários no Cloud Identity ou no Google Workspace
Para permitir que um funcionário se autentique no Google usando o Logon único, primeiro é necessário criar uma conta de usuário para o funcionário no Cloud Identity ou no Google Workspace. Para garantir a consistência com seu IdP externo, é melhor automatizar o processo de provisionamento dessas contas de usuário no Cloud Identity ou no Google Workspace:
- Ao automatizar o provisionamento, você garante que as identidades do Cloud Identity ou do Google Workspace sejam sempre um subconjunto das identidades no seu IdP externo.
- Você minimiza o risco de apresentar acidentalmente uma incompatibilidade entre uma identidade no Cloud Identity ou no Google Workspace e a identidade correspondente no seu IdP externo. Incompatibilidades como erros ao digitar o endereço de e-mail podem resultar em problemas de login para os funcionários.
- Você minimiza o esforço de administração manual.
Se você usa um RHIS para gerenciar o processo de integração, uma maneira de automatizar o provisionamento de usuários é configurá-lo para provisionar contas de usuário no seu IdP externo e no Cloud Identity ou no Google Workspace, como no diagrama a seguir.
Para que essa configuração funcione corretamente, é necessário garantir que o RHIS provisione contas de usuário para que elas sejam mapeadas corretamente. Além disso, o RHIS deve processar a decisão de quais contas de usuário provisionar para o Cloud Identity ou o Google Workspace.
Outra maneira de automatizar o provisionamento de usuários que funciona independentemente de um RHIS é usar seu IdP externo como origem autorizada para provisionar usuários no Cloud Identity ou no Google Workspace. Neste caso, a configuração do mapeamento de contas de usuário e de conjuntos de contas de usuário é gerenciada no IdP ou pelo adaptador, conforme mostrado no diagrama a seguir.
Se você usa o Active Directory como seu IdP, é possível duplicar essa configuração usando o Google Cloud Directory Sync. Outros IdPs, como o Azure AD ou o Okta, têm adaptadores integrados para provisionar usuários ao Google Workspace. Como o Google Workspace e o Cloud Identity são baseados na mesma plataforma e usam as mesmas APIs, esses adaptadores também podem ser usados no Cloud Identity.
Propagar eventos de suspensão para o Cloud Identity ou o Google Workspace
Quando um funcionário sai da organização, seja temporária ou permanentemente, recomendamos revogar o acesso do funcionário aos serviços do Google. Ao suspender a conta de usuário do funcionário no IdP externo, você revoga a capacidade de usar o Logon único para autenticar no Google, mas isso pode não revogar completamente o acesso a todos os serviços do Google. As seguintes situações ainda podem ocorrer:
- se o usuário do Cloud Identity ou do Google Workspace tiver uma sessão ativa no navegador, a sessão continuará funcionando. Todos os tokens OAuth que já foram obtidos também continuam válidos;
- se o usuário tiver privilégios de superadministrador ou se você tiver configurado máscaras de rede, o funcionário ainda poderá fazer login usando uma senha.
- a conta de usuário ainda pode receber notificações do Google Cloud, incluindo alertas de orçamento;
- se o usuário tiver uma licença do Google Workspace atribuída, os e-mails continuarão a ser enviados para a caixa de correio do usuário, que ainda aparecerá na lista de endereços, bem como poderá ser listado como disponível no Google Agenda;
- se você permitir que os usuários usem aplicativos menos seguros, o usuário ainda poderá acessar o Gmail, o Google Agenda e outros dados usando senhas de aplicativo.
Para revogar totalmente o acesso aos serviços do Google, propague os eventos de suspensão para o Cloud Identity ou o Google Workspace das seguintes maneiras:
Sempre que uma conta de usuário for suspensa no IdP externo, a conta de usuário correspondente no Cloud Identity ou no Google Workspace também será suspensa. Suspender um usuário no Cloud Identity ou no Google Workspace encerra as sessões ativas do navegador, invalida os tokens e revoga todos os outros acessos;
da mesma forma, ao reativar uma conta de usuário no IdP externo, verifique se você também reativou a conta de usuário correspondente no Cloud Identity ou no Google Workspace.
Suspender uma conta de usuário no Cloud Identity ou no Google Workspace é uma operação não destrutiva. Enquanto a conta de usuário é suspensa, os dados do usuário são mantidos, as licenças do Google Workspace permanecem anexadas e os papéis atribuídos no Google Cloud permanecem inalterados.
Propagar eventos de exclusão para o Cloud Identity ou o Google Workspace
Quando um funcionário sai permanentemente da organização, você poderá optar não apenas por suspender a conta de usuário do funcionário no seu IdP externo, como também excluí-la.
Se você excluir uma conta de usuário no IdP externo, mas não o usuário correspondente do Cloud Identity ou do Google Workspace, o conjunto de usuários neles não será mais um subconjunto dos usuários no IdP externo. Isso pode se tornar um problema no futuro se um novo funcionário que integrar sua organização tiver o mesmo nome do funcionário que saiu da empresa. Se você criar uma conta de usuário no IdP para o novo funcionário, poderá reutilizar o nome de usuário do funcionário antigo, fazendo com que a nova conta de usuário seja mapeada para a conta de usuário antiga no Cloud Identity ou no Google Workspace. Como resultado, o novo funcionário poderá ter acesso aos dados e às configurações do funcionário antigo.
Para evitar os riscos associados a contas de usuário do Cloud Identity ou do Google Workspace, exclua um usuário do Cloud Identity ou do Google Workspace assim que a conta de usuário correspondente no seu IdP for excluída.
A exclusão de um usuário do Cloud Identity ou do Google Workspace é uma operação destrutiva que só pode ser desfeita dentro de um determinado período. Dependendo dos serviços do Google consumidos pelo usuário, a exclusão dele pode fazer com que os dados associados sejam excluídos permanentemente e, portanto, não atenda aos seus requisitos de conformidade.
Para preservar as configurações e os dados do usuário por um determinado período de retenção antes de excluí-los permanentemente, implemente uma das seguintes abordagens:
adie a exclusão da conta de usuário no seu IdP externo mantendo o usuário em um estado suspenso por um determinado período de retenção; exclua o usuário no IdP e no Cloud Identity/Google Workspace após o período de retenção.
Ao excluir uma conta de usuário no IdP externo, suspenda o usuário do Cloud Identity ou do Google Workspace correspondente e altere o endereço de e-mail principal para um nome que provavelmente não causará um conflito. Por exemplo, renomeie
alice@example.comcomoobsolete-yyyymmdd-alice@example.com, em queyyyymmddreflete a data da exclusão no seu IdP externo; mantenha a conta de usuário renomeada em um estado suspenso por um período de retenção e exclua-a após o período de retenção.
Para preservar os dados do Google Workspace de usuários suspensos, mantenha a licença do Google Workspace atribuída ao usuário ou altere-a para uma licença de usuário arquivado, garantindo assim que as regras de retenção do Vault do Google Workspace continuem a serem aplicadas e que os dados do usuário sejam preservados.
Logon único
Todos os produtos do Google, incluindo serviços como o Google Cloud,
o Google Ads e o YouTube, usam o
Login do Google
para autenticar usuários. Um serviço inicia o processo de autenticação redirecionando
um usuário para accounts.google.com, em que é exibida a tela de login do Google
e é solicitado o endereço de e-mail. Dependendo do domínio
do endereço de e-mail fornecido, a conta de usuário é consultada no Gmail, no
diretório da conta pessoal ou, se o domínio corresponder ao
domínio principal, secundário ou de alias,
em uma conta do Cloud Identity ou do Google Workspace.
O diagrama a seguir ilustra esse processo de autenticação.
Se você configurar uma conta do Cloud Identity ou do Google Workspace para usar o Logon único, os usuários serão redirecionados a um IdP externo para autenticação. Quando o IdP externo concluir a autenticação, o resultado será redirecionado para o login do Google por meio de uma declaração SAML. Essa declaração serve como prova de uma autenticação bem-sucedida. Além disso, ela contém o endereço de e-mail do usuário e é assinada pelo certificado do IdP externo para que o Login do Google possa verificar sua autenticidade.
Esse processo é chamado de Logon único iniciado pelo provedor de serviços e se aplica a todos os usuários, exceto aos superadministradores. Os superadministradores nunca são redirecionados a um IdP externo; por sua vez, são solicitados a inserir uma senha.
Alguns IdPs também são compatíveis com o Logon único iniciado pelo IdP. Nesse modelo, o usuário se autentica no IdP externo e segue um link que direciona para um serviço do Google, como o Google Cloud ou o Google Ads. Se o Logon único tiver sido ativado para uma conta do Cloud Identity ou do Google Workspace, todos os usuários dessa conta poderão usar o Logon único iniciado pelo IdP, incluindo superadministradores.
Minimizar o conjunto de atributos transmitidos nas declarações SAML
Depois que um usuário é autenticado no IdP externo, o Cloud Identity ou o
Google Workspace usam a declaração SAML transmitida pelo IdP externo para
estabelecer uma sessão. Além de validar a autenticidade, esse processo
inclui a identificação da conta de usuário do Cloud Identity ou do Google Workspace
que corresponde ao valor NameID na declaração SAML.
O valor NameID deve conter o endereço de e-mail principal da conta de usuário a ser
autenticada. O endereço de e-mail diferencia maiúsculas de minúsculas. Pseudônimos e
endereços de e-mail alternativos não são considerados.
Para evitar erros ortográficos ou incompatibilidades de letras maiúsculas e minúsculas acidentais, é melhor provisionar automaticamente as contas de usuário.
As declarações SAML podem conter outras características, que, no entanto, não são consideradas durante a autenticação. Os atributos que contêm informações como nome, sobrenome ou associação a grupos de um usuário são ignorados porque a conta do usuário no Cloud Identity ou no Google Workspace é considerada como a única fonte dessas informações.
Para minimizar a extensão das declarações SAML, configure seu IdP para não incluir atributos que não sejam exigidos pelo Login do Google.
Usar google.com como emissor
As sessões de Login do Google não estão restritas a uma única ferramenta ou domínio. Em vez disso, depois que uma sessão é estabelecida, ela é válida em todos os serviços do Google aos quais o usuário recebeu acesso. Essa lista de serviços poderá 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 é refletida na troca de protocolo SAML: por padrão,
o Google usa google.com como emissor (o elemento Issuer na
solicitação SAML) em solicitações SAML e espera que as declarações SAML especifiquem
google.com como o público-alvo (o elemento Audience na resposta SAML).
É possível alterar esse padrão ativando a opção Usar um emissor específico de domínio
ao configurar o Logon único no Cloud Identity ou no
Google Workspace. Ative a opção do emissor específico de domínio se
houver mais de uma conta do Cloud Identity ou do Google Workspace (e,
portanto, vários domínios) e se seu IdP precisar distinguir logins
iniciados por uma conta do Cloud Identity ou do Google Workspace
em comparação a outra conta. Ao ativar a opção, as solicitações SAML usam
google.com/a/DOMAIN como emissor e esperam
google.com/a/DOMAIN como público-alvo, em que
DOMAIN é o domínio principal da conta
do Cloud Identity ou do Google Workspace.
Em todos os outros casos, mantenha a configuração padrão para usar google.com como emissor
e configure seu IdP externo para especificar google.com como o público-alvo nas
declarações SAML. Dependendo do seu IdP, essa configuração também pode ser chamada de
emissor, identificador de confiança da parte confiável ou ID de entidade.
Alinhar a duração das sessões do Google e do IdP
Assim que um usuário concluir o processo de Logon único e uma sessão for estabelecida, a sessão de login do Google permanecerá ativa por um determinado período. Quando esse período terminar ou se o usuário sair, será solicitado que ele se autentique novamente repetindo o processo de Logon único.
Por padrão, a duração da sessão dos serviços do Google é de 14 dias. Para usuários com uma licença do Cloud Identity Premium ou do Google Workspace Business, é possível alterar a duração padrão da sessão para um período diferente, como oito horas.
É possível controlar a duração da sessão usada pelo Google Cloud. A sessão do Google Cloud se aplica ao console do Google Cloud, bem como à Google Cloud CLI e a outros clientes da API. É possível definir a duração da sessão do Google Cloud em todos os tipos de conta do Cloud Identity e do Google Workspace.
A maioria dos IdPs externos também mantém uma sessão para usuários autenticados. Se a duração da sessão do IdP for maior do que a duração da sessão do Google, poderá ocorrer uma nova autenticação de forma tácita. Ou seja, o usuário será redirecionado ao IdP, mas poderá não precisar inserir as credenciais novamente. A repetição da autenticação de forma tácita pode prejudicar a intenção de reduzir a duração das sessões do Google.
Para garantir que os usuários insiram suas credenciais novamente depois que uma sessão do Google expirar, configure a duração das sessões do Google e do IdP para que a do IdP seja menor do que a do Google.
Desativar o Logon único para usuários superadministradores
Para usuários superadministradores, o SSO é opcional: podem usar o SSO quando o login é iniciado pelo IdP, mas também podem fazer login usando o nome de usuário e a senha.
Se você não planeja usar o Logon único iniciado pelo IdP para usuários superadministradores, diminua o risco usando o procedimento a seguir:
- Adicione uma unidade organizacional dedicada para superadministradores.
- Atribua um perfil de SSO à unidade organizacional que desativa o Logon único.
Caso contrário, se você planeja usar o Logon único iniciado pelo IdP, é necessário implementar a verificação pós-SSO para usuários superadministradores.
Autenticação multifator
Ativar o Logon único entre o Cloud Identity ou o Google Workspace e o IdP externo melhora a experiência do usuário para os funcionários. Os usuários devem se autenticar com menos frequência e não precisam memorizar credenciais separadas para acessar os serviços do Google.
No entanto, permitir que os usuários se autentiquem perfeitamente em serviços e ambientes também representa o aumento do possível impacto das credenciais de usuário comprometidas. Se o nome de usuário e a senha de um usuário forem perdidos ou roubados, um invasor poderá usar essas credenciais para acessar recursos não apenas no ambiente atual, mas também em um ou mais serviços do Google.
Para reduzir o risco de roubo de credenciais, é melhor usar a autenticação multifator para todas as contas de usuário.
Implementar a autenticação multifator aos usuários
Depois de configurar o Logon único para sua conta do Cloud Identity ou do Google Workspace, os usuários sem privilégios de superadministrador devem usar seu IdP externo para fazer a autenticação.
Configure seu IdP para exigir o uso de um segundo fator (como um código único ou uma chave USB) para impor que a autenticação multifator seja aplicada sempre que o Logon único for usado.
Se o IdP externo não for compatível com a autenticação multifator, considere ativar a verificação pós-SSO para que o Google realize uma verificação adicional depois que o usuário retornar da autenticação com o IdP externo.
Evite o uso de máscaras de rede, porque elas podem ser usadas como uma forma de contornar a autenticação multifator dos usuários.
Aplicar a autenticação em duas etapas do Google para usuários superadministradores
Os usuários superadministradores não são redirecionados ao seu IdP externo quando tentam fazer login no console do Google Cloud ou em outros sites do Google. Em vez disso, eles precisam fazer a autenticação com o nome de usuário e senha.
Como os usuários superadministradores têm essa opção, eles não estão sujeitos a quaisquer políticas de autenticação multifator que seu IdP possa aplicar. Para proteger os usuários superadministradores, aplique a autenticação em duas etapas do Google para todos eles.
Os usuários superadministradores geralmente se enquadram em uma das duas categorias a seguir:
Usuários superadministradores personalizados: esses usuários são personalizados e devem ser usados por um único administrador. Recomendamos que você implemente a verificação em duas etapas para todos os usuários superadministradores personalizados.
Usuários superadministradores de máquina: embora seja melhor evitar essas contas de usuário, às vezes são necessárias para ativar ferramentas como o Cloud Directory Sync ou o aplicativo de galeria do Azure AD para gerenciar usuários e grupos no Cloud Identity ou Google Workspace.
Limite o número de usuários superadministradores de máquina e tente ativar a verificação em duas etapas sempre que possível.
Para usuários que não usam o Logon único, é possível implementar a autenticação em duas etapas globalmente, por unidade organizacional ou por grupo:
se não houver usuários superadministradores de máquina que não possam usar a verificação em duas etapas, é melhor ativar a aplicação para todos os usuários. Ao aplicar a verificação em duas etapas a todos os usuários, você evita o risco de perdê-los involuntariamente;
se houver usuários superadministradores de máquina que não podem usar a verificação em duas etapas, use um grupo dedicado para controlar a verificação. Crie um novo grupo, ative a aplicação do grupo e adicione todos os superusuários relevantes a ele.
Para mais detalhes sobre como usar a autenticação em duas etapas para proteger os usuários superadministradores, consulte nossas práticas recomendadas de segurança para contas de administrador.
Aplicar a verificação pós-SSO para usuários superadministradores
Os usuários superadministradores não precisam usar o logon único, mas eles ainda podem usar esse processo quando ele é iniciado pelo IdP. Para garantir que os usuários superadministradores estejam sempre sujeitos à verificação em duas etapas, mesmo que sejam autenticados por um login iniciado pelo IdP, ative a opção Mais verificações de SSO e verificação em duas etapas para todos eles.
Mais verificações do SSO podem parecer redundantes nos casos em que o IdP já exige a autenticação multifator. No entanto, essa configuração pode ajudar a proteger os usuários superadministradores caso seu IdP seja comprometido.
Não restringir o Logon único por máscara de rede
Ao configurar o Logon único no Cloud Identity ou no Google Workspace, há a opção de especificar uma máscara de rede. Ao especificar uma máscara, somente os usuários com endereços IP correspondentes à máscara estarão sujeitos ao Logon único. Outros usuários, por sua vez, receberão uma solicitação de senha quando fizerem login.
Ao usar máscaras de rede, poderá estar neutralizando a autenticação multifator aplicada pelo IdP externo. Por exemplo, ao alterar os locais ou usar uma VPN, um usuário poderá controlar se a máscara de rede se aplica ou não. Se você aplicar a autenticação multifator no IdP externo, essa tática poderá permitir que um usuário ou invasor burle as políticas de autenticação multifator configuradas no seu IdP externo.
Para garantir que a autenticação multifator seja aplicada de maneira consistente, independentemente da localização ou do endereço IP de um usuário, evite restringir o Logon único por máscara de rede.
Para restringir o acesso aos recursos por endereço IP, configure uma lista de permissões de IP apropriada no seu IdP externo ou use o acesso baseado no contexto para o Google Cloud e o Google Workspace.
A seguir
- Saiba mais sobre outras práticas recomendadas:
- Compare padrões de federação de um IdP externo com o Google Cloud.