Práticas recomendadas sobre como federar o Google Cloud com um provedor de identidade externo

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 G Suite 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 G Suite para cada funcionário, é possível federar o Cloud Identity ou o G Suite 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 aprovisionamento automático de contas de usuário relevantes de uma origem autorizada externa para o Cloud Identity ou o G Suite.
  • 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 G Suite é 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 G Suite.

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 aprovisionamento 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 G Suite. 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 G Suite. 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 userPrincipalName no 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 UserPrincipalName para 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 G Suite. 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 Cloud, eles são solicitados a fornecer o endereço de e-mail principal do usuário do Cloud Identity ou do G Suite 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 G Suite, 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 G Suite 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 G Suite 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 essas soluções não forem práticas, considere adicionar o G Suite à sua conta do Cloud Identity e atribuir licenças do G Suite 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 G Suite, é 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 G Suite 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 G Suite.

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 G Suite, 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:

  1. identidades externas que mapeiam para uma identidade no Cloud Identity ou no G Suite;
  2. identidades externas que o IdP externo permite para o Logon único no Cloud Identity ou no G Suite.

    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 G Suite 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 G Suite. 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 G Suite 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 G Suite.

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 G Suite se não tiver criado uma conta de usuário com a mesma identidade no Cloud Identity ou no G Suite.

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 G Suite apenas para usuários que precisam delas e que não têm uma conta de consumidor 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 G Suite, 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.

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 G Suite 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 G Suite não impede que os funcionários se inscrevam em novas contas pessoais usando o mesmo domínio. Essas novas contas pessoais são exibidas como usuários não gerenciados na sua conta do Cloud Identity ou do G Suite, 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 G Suite.

Uma maneira de bloquear a criação de uma nova conta pessoal é criar uma conta de usuário no Cloud Identity ou no G Suite 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 G Suite, 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 G Suite, 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 G Suite.

  • Provisione usuários do Cloud Identity ou do G Suite a 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.

Como evitar novas inscrições de contas pessoais.

Se você ainda estiver no processo de migração de contas pessoais, monitore temporariamente as novas inscrições de contas pessoais capturando os e-mails de verificação enviados durante o processo de inscrição. Configure um filtro em seu sistema de e-mail para endereços de remetente que correspondam a *@idverification.bounces.google.com e retenha os e-mails correspondentes para análise interna.

Tornar as identidades do Cloud Identity ou do G Suite um subconjunto das identidades no IdP externo

Sua conta do Cloud Identity ou do G Suite 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 G Suite 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 G Suite 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 G Suite, 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 G Suite 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 G Suite. 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 G Suite 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 G Suite 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 G Suite 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 G Suite.

Usar usuários superadministradores dedicados

As contas de superadministrador do G Suite 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 G Suite, 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.com e 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.com e 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 G Suite ou seu sistema de e-mail existente para que o endereço de e-mail alice-admin@example.com seja um alias ou seja encaminhado para alice@example.com.

Verifique se as duas identidades são reconhecidas pelo IdP externo para que o conjunto de identidades no Cloud Identity ou no G Suite 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 G Suite 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 puder 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 acesso aos recursos 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 G Suite.

Com ela, você ativa uma conta de serviço para agir em nome de um usuário do Cloud Identity ou do G Suite. 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 G Suite para cada conta de serviço do Google Cloud ativada para a delegação em todo o domínio do G Suite. Crie esse usuário no IdP externo e provisione-o no Cloud Identity ou no G Suite 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 G Suite que você não pretende usar para a delegação em todo o domínio do G Suite.

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:

  1. Uma nova conta de usuário é criada para um funcionário que está integrando o quadro da organização.
  2. A conta de usuário pode ser temporariamente suspensa e reativada posteriormente, por exemplo, quando o funcionário sair.
  3. 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.

Como mapear ciclos de vida da conta de usuário.

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 G Suite 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 G Suite, ao contrário das realizadas no Cloud Identity e no G Suite.

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 G Suite 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 aprovisionamento de usuários no Cloud Identity ou no G Suite

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 G Suite. 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 G Suite:

  • Ao automatizar o provisionamento, você garante que as identidades do Cloud Identity ou do G Suite 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 G Suite 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 G Suite, como no diagrama a seguir.

Provisione contas de usuário para seu IdP externo e para o Cloud Identity ou o G Suite.

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 G Suite.

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 G Suite. 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.

Como usar o IdP externo como origem autorizada para provisionar usuários no Cloud Identity ou no G Suite.

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 G Suite. Como o G Suite 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 G Suite

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 G Suite 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 G Suite atribuída, os e-mails continuarão a ser enviados para a caixa de correio do usuário, que ainda aparecerá no catálogo 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 G Suite 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 G Suite também será suspensa. Suspender um usuário no Cloud Identity ou no G Suite 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 G Suite.

Suspender uma conta de usuário no Cloud Identity ou no G Suite é 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 G Suite permanecem anexadas e os papéis atribuídos no Google Cloud permanecem inalterados.

Propagar eventos de exclusão para o Cloud Identity ou o G Suite

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 G Suite, 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 G Suite. 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 G Suite, exclua um usuário do Cloud Identity ou do G Suite 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 G Suite é 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/G Suite 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 G Suite 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.com como obsolete-yyyymmdd-alice@example.com, em que yyyymmdd reflete 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 G Suite de usuários suspensos, mantenha a licença do G Suite atribuída ao usuário ou altere-a para uma licença de usuário arquivado, garantindo assim que as regras de armazenamento do Vault do G Suite 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 G Suite.

O diagrama a seguir ilustra esse processo de autenticação.

Processo de autenticação do Google.

Se você configurar uma conta do Cloud Identity ou do G Suite 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 G Suite, 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 G Suite 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 G Suite 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 G Suite é 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 G Suite. Ative a opção do emissor específico de domínio se houver mais de uma conta do Cloud Identity ou do G Suite (e, portanto, vários domínios) e se seu IdP precisar distinguir logins iniciados por uma conta do Cloud Identity ou do G Suite 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 G Suite.

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 G Suite 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 Cloud, bem como à ferramenta de linha de comando gcloud 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 G Suite.

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.

Autenticação multifator

Ativar o Logon único entre o Cloud Identity ou o G Suite 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 G Suite, 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.

Implementar a autenticação em duas etapas do Google para superadministradores

As contas de superadministrador do G Suite e do Cloud Identity estão isentas do Logon único e têm um conjunto poderoso de permissões, o que as torna um alvo atraente para invasores. Por padrão, a autenticação em duas etapas é opcional para contas do Google, incluindo contas de superadministrador. Os usuários podem ativar o recurso, mas não são obrigados a fazer isso, a menos que você implemente a autenticação em duas etapas.

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 G Suite.

    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.

Não restringir o Logon único por máscara de rede

Ao configurar o Logon único no Cloud Identity ou no G Suite, 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 G Suite.

A seguir