Práticas recomendadas para acesso contínuo ao Google Cloud

Last reviewed 2025-08-08 UTC

Este documento fornece recomendações para ajudar você a manter o acesso contínuo aos recursos do Google Cloud . A continuidade de negócios visa garantir que sua organização possa manter as operações essenciais, mesmo durante interrupções como falhas ou desastres. Essa meta inclui o acesso contínuo dos funcionários quando os serviços e a infraestrutura essenciais não estão disponíveis.

Este documento é destinado a profissionais de segurança ou confiabilidade responsáveis pelo gerenciamento de identidade e acesso (IAM) e pela manutenção do acesso seguro ao Google Cloud. Neste documento, presumimos que você já esteja familiarizado com o Cloud Identity, o Google Workspace e o gerenciamento do IAM.

Para ajudar você a se preparar para interrupções e garantir o acesso contínuo, este documento descreve as seguintes etapas recomendadas que podem ser implementadas. Você pode seguir todas ou algumas dessas etapas, mas recomendamos que elas sejam implementadas na ordem a seguir.

  1. Configurar o acesso de emergência:ative o acesso de último recurso aos recursos do Google Cloud .

    Recomendamos que você configure o acesso de emergência para todas as suas organizações doGoogle Cloud , independente dos seus requisitos individuais de continuidade dos negócios.

  2. Ofereça alternativas de autenticação para usuários críticos:se sua organização usa logon único (SSO), qualquer interrupção que afete seu provedor de identidade externo (IdP) pode afetar a capacidade dos funcionários de se autenticar e usar o Google Cloud.

    Para reduzir o impacto geral de uma interrupção do IdP na sua organização, ofereça uma alternativa de autenticação para que os usuários essenciais aos negócios continuem acessando os recursos do Google Cloud .

  3. Use um IdP de backup:para permitir que todos os usuários acessem os recursos do Google Cloud durante uma interrupção do IdP, mantenha um IdP de substituição.

    Um IdP de failback pode ajudar a minimizar ainda mais o impacto de uma interrupção, mas essa opção pode não ser econômica para todas as organizações.

As seções a seguir descrevem essas etapas recomendadas e práticas recomendadas.

Configurar o acesso de emergência

O objetivo do acesso de emergência é permitir o acesso de último recurso aos recursos doGoogle Cloud e evitar situações em que você possa perder o acesso completamente.

Os usuários com acesso de emergência têm as seguintes propriedades:

  • São usuários que você cria na sua conta do Cloud Identity ou do Google Workspace.
  • Eles têm o privilégio de superadministrador, que oferece aos usuários acesso suficiente para resolver qualquer configuração incorreta que afete seus recursos do Cloud Identity, do Google Workspace ou do Google Cloud .
  • Elas não estão associadas a um funcionário específico da organização e são isentas do ciclo de vida de entrada, movimentação e saída (JML) das contas de usuário comuns.
  • Eles estão isentos do SSO.

As seções a seguir descrevem as práticas recomendadas para gerenciar e proteger usuários com acesso de emergência.

Crie usuários de acesso de emergência para cada ambiente

Para ambientes Google Cloud que hospedam cargas de trabalho de produção, o acesso de emergência é essencial. Para ambientes Google Cloud usados para testes ou preparo, a perda de acesso ainda pode ser prejudicial.

Para garantir o acesso contínuo a todos os seus Google Cloud ambientes, crie e mantenha usuários de acesso de emergência no Cloud Identity ou Google Workspace para cada ambiente.

Garantir a redundância do acesso de emergência

Um único usuário de acesso de emergência é um ponto único de falha. Nesse cenário, uma chave de segurança quebrada, uma senha perdida ou uma suspensão de conta podem interromper o acesso a uma conta. Para reduzir esse risco, crie mais de um usuário de acesso de emergência para cada conta do Cloud Identity ou do Google Workspace.

Os usuários com acesso de emergência têm privilégios altos. Por isso, não crie muitos deles. Para a maioria das organizações, recomendamos um mínimo de dois e um máximo de cinco usuários com acesso de emergência para cada conta do Cloud Identity ou do Google Workspace.

Usar uma unidade organizacional separada para usuários com acesso de emergência

Os usuários com acesso de emergência precisam de uma configuração especial e não estão sujeitos ao ciclo de vida de JML que você pode seguir para outras contas de usuário.

Para manter os usuários de acesso de emergência separados das contas de usuário comuns, use uma unidade organizacional (UO) dedicada a eles. Uma UO separada permite aplicar configurações personalizadas apenas aos usuários de emergência.

Usar chaves de segurança FIDO na verificação em duas etapas

Use chaves de segurança Fast IDentity Online (FIDO) para a verificação em duas etapas.

Como os usuários com acesso de emergência têm privilégios altos na sua conta do Cloud Identity ou do Google Workspace, é necessário proteger essas pessoas usando a verificação em duas etapas.

Entre os métodos de verificação em duas etapas compatíveis com o Cloud Identity e o Google Workspace, recomendamos o uso de chaves de segurança FIDO. Esse método oferece proteção contra phishing e segurança reforçada. Para garantir que todos os usuários de acesso de emergência usem chaves de segurança FIDO para a verificação em duas etapas, faça o seguinte:

  • Na UO que contém seus usuários de acesso de emergência, configure a verificação em duas etapas para permitir apenas chaves de segurança como método de autenticação.
  • Ative a verificação em duas etapas para todos os usuários com acesso de emergência.
  • Para cada usuário com acesso de emergência, inscreva duas ou mais chaves de segurança FIDO.

Ao inscrever várias chaves para cada usuário, você ajuda a reduzir o risco de perder o acesso devido a uma chave de segurança quebrada. Você também aumenta a probabilidade de o usuário acessar pelo menos uma das chaves em uma emergência.

É aceitável usar o mesmo conjunto de chaves de segurança para vários usuários de acesso de emergência. No entanto, é melhor usar chaves de segurança diferentes para cada usuário com acesso de emergência.

Use controles de segurança física para proteger credenciais e chaves de segurança

Ao armazenar as credenciais e chaves de segurança dos usuários com acesso de emergência, você precisa equilibrar a proteção forte com a disponibilidade durante uma emergência:

  • Impedir que pessoas não autorizadas acessem as credenciais de usuário de acesso de emergência. Os usuários com acesso de emergência só podem usar essas credenciais em uma emergência.
  • Verifique se o pessoal autorizado pode acessar as credenciais com o mínimo de atraso durante uma emergência.

Recomendamos que você não use um gerenciador de senhas baseado em software. Em vez disso, é melhor confiar em controles de segurança física para proteger as credenciais e as chaves de segurança dos usuários com acesso de emergência.

Ao escolher quais controles de segurança física aplicar, considere o seguinte:

  • Melhorar a disponibilidade:
    • Armazene cópias das senhas em vários locais físicos, como cofres de segurança diferentes em escritórios diferentes.
    • Inscreva várias chaves de segurança para cada usuário com acesso de emergência e armazene uma chave em cada local de escritório relevante.
  • Melhore a segurança:armazene a senha e as chaves de segurança em locais diferentes.

Evitar a automação para rotação de senhas

Pode parecer benéfico automatizar a rotação de senhas para usuários de acesso de emergência. No entanto, essa automação pode aumentar o risco de uma violação de segurança. Os usuários com acesso de emergência têm privilégios de superadministrador. Para fazer a rotação da senha de um usuário superadministrador, as ferramentas ou scripts de automação também precisam ter privilégios de superadministrador. Esse requisito pode fazer com que as ferramentas sejam alvos atraentes para invasores.

Para não enfraquecer sua postura geral de segurança, não use a automação para girar as senhas.

Use senhas fortes

Para proteger os usuários com acesso de emergência, verifique se eles usam uma senha longa e forte. Para aplicar um nível mínimo de complexidade de senha, use uma UO dedicada, conforme descrito anteriormente, e implemente requisitos de senha.

A menos que você faça a rotação manual das senhas, desative a expiração de senha para todos os usuários com acesso de emergência.

Excluir um usuário de acesso de emergência das políticas de acesso

Durante uma emergência, as políticas de acesso baseado no contexto podem causar uma situação em que nem mesmo um usuário com acesso de emergência consegue acessar determinados recursos. Para atenuar esse risco, exclua pelo menos um usuário de acesso de emergência de todos os níveis de acesso nas suas políticas de acesso.

Essas isenções ajudam a garantir que pelo menos um dos seus usuários de acesso de emergência tenha acesso contínuo aos recursos. Em caso de emergência ou de uma política de acesso baseada no contexto mal configurada, esses usuários podem manter o acesso.

Configurar alertas para eventos de usuários com acesso de emergência

Qualquer atividade de usuário com acesso de emergência fora de um evento de emergência provavelmente indica comportamento suspeito. Para receber notificações sobre eventos relacionados à atividade de usuários com acesso de emergência, crie uma regra de geração de relatórios no Google Admin Console. Ao criar uma regra de relatórios, é possível definir condições como as seguintes:

  • Origem de dados:eventos de registro do usuário.
  • Atributos na guia Criador de condições:use atributos e operadores para criar um filtro para a UO que contém os usuários de acesso de emergência e os eventos.

    Por exemplo, você pode definir atributos e operadores para criar um filtro semelhante às seguintes instruções condicionais:

    Actor organizational unit Is /Privileged
    
    AND
    
    (Event Is Successful login OR Event Is Failed login OR Event Is Account
    password change)
    
  • Limite:a cada 1 hora quando a contagem > 0

  • Ação:enviar notificações por e-mail

  • Destinatários de e-mail:selecione um grupo que contenha os membros relevantes da sua equipe de segurança.

Oferecer alternativas de autenticação para usuários críticos

Se sua organização usa o SSO para permitir que os funcionários se autentiquem nos serviços do Google, a disponibilidade do seu IdP de terceiros se torna essencial. Qualquer interrupção no seu IdP pode impedir que os funcionários acessem ferramentas e recursos essenciais.

Embora o acesso de emergência ajude a garantir o acesso administrativo contínuo, ele não atende às necessidades dos funcionários durante uma interrupção do IdP.

Para reduzir o efeito potencial de uma interrupção do IdP, configure sua conta do Cloud Identity ou do Google Workspace para usar um fallback de autenticação para usuários críticos. Você pode usar o seguinte plano de contingência:

  • Durante as operações normais, você permite que os usuários façam a autenticação usando o SSO.
  • Durante uma interrupção do IdP, desative seletivamente o SSO para esses usuários críticos e permita que eles se autentiquem usando credenciais de login do Google, que você provisiona com antecedência.

As seções a seguir descrevem as práticas recomendadas quando você permite que usuários críticos façam a autenticação durante interrupções do IdP externo.

Foco em usuários privilegiados

Para que os usuários críticos se autentiquem durante uma interrupção do IdP, eles precisam ter credenciais de login do Google válidas, como as seguintes:

  • Uma senha com uma chave de segurança para autenticação de dois fatores.
  • Uma chave de acesso.

Ao provisionar credenciais de login do Google para usuários que normalmente usam o SSO, você pode aumentar a sobrecarga operacional e o atrito do usuário das seguintes maneiras:

  • Talvez não seja possível sincronizar as senhas de usuário automaticamente, dependendo do seu IdP. Portanto, talvez seja necessário pedir que os usuários definam uma senha manualmente.
  • Talvez seja necessário pedir que os usuários registrem uma chave de acesso ou se inscrevam na verificação em duas etapas. Essa etapa geralmente não é necessária para usuários do SSO.

Para equilibrar os benefícios do acesso ininterrupto aos serviços do Google com a sobrecarga extra, concentre-se em usuários privilegiados e essenciais para os negócios. Esses usuários têm mais chances de se beneficiar significativamente do acesso ininterrupto e podem representar apenas uma fração da sua base de usuários geral.

Aproveite a oportunidade para ativar a verificação pós-SSO

Ao provisionar a autenticação alternativa para usuários privilegiados, um resultado não intencional pode ser uma sobrecarga adicional. Para ajudar a compensar esse overhead, também é possível ativar a verificação pós-SSO para esses usuários.

Por padrão, quando você configura o SSO para seus usuários, eles não precisam fazer a verificação em duas etapas. Embora essa prática seja conveniente, se o IdP for comprometido, qualquer usuário que não tiver a verificação pós-SSO ativada poderá se tornar um alvo de ataques de falsificação de credenciais.

A verificação pós-SSO ajuda a reduzir o efeito potencial de uma violação do IdP porque os usuários precisam fazer a verificação em duas etapas após cada tentativa de SSO. Se você provisionar credenciais de login do Google para usuários privilegiados, a verificação pós-SSO poderá ajudar a melhorar a segurança dessas contas de usuário sem sobrecarga adicional.

Usar uma UO separada para usuários privilegiados

Usuários privilegiados que podem fazer autenticação durante interrupções do IdP externo precisam de uma configuração especial. Essa configuração é diferente da configuração para usuários comuns e para usuários com acesso de emergência.

Para manter os usuários privilegiados separados dessas outras contas, use uma UO dedicada a eles. Essa UO separada ajuda a aplicar políticas personalizadas, como a verificação pós-SSO, apenas a esses usuários privilegiados.

Uma UO separada também ajuda a desativar seletivamente o SSO para usuários privilegiados durante uma interrupção do IdP. Para desativar o SSO na UO, modifique as atribuições de perfil de SSO.

Usar um IdP alternativo

Ao oferecer alternativas de autenticação para usuários críticos durante interrupções do IdP, você ajuda a reduzir o efeito dessa interrupção na sua organização. No entanto, essa estratégia de mitigação pode não ser suficiente para manter a capacidade operacional total. Muitos usuários ainda não conseguem acessar aplicativos e serviços essenciais.

Para reduzir ainda mais o efeito potencial de uma interrupção do IdP, faça failover para um IdP de backup. Você pode usar o seguinte plano de backup:

  • Durante as operações normais, você permite que os usuários façam a autenticação usando o SSO e o IdP principal.
  • Durante uma interrupção do IdP, mude a configuração de SSO da sua conta do Cloud Identity ou do Google Workspace para mudar para o IdP de backup.

O IdP de backup não precisa ser do mesmo fornecedor. Ao criar um IdP de backup, use uma configuração que corresponda à do IdP principal. Para garantir que o IdP de backup permita que todos os usuários se autentiquem e acessem os serviços do Google, ele precisa usar uma cópia atualizada da base de usuários do IdP principal.

Um IdP de backup pode ajudar a fornecer acesso abrangente de contingência. No entanto, é preciso ponderar essas vantagens em relação aos riscos adicionais que um IdP de backup pode apresentar. Esses riscos potenciais incluem o seguinte:

  • Se o IdP de backup tiver uma segurança mais fraca do que o IdP principal, a postura geral de segurança do seu ambiente Google Cloud também poderá ser mais fraca durante um failover.
  • Se o IdP principal e o de backup forem diferentes em como eles emitem declarações SAML, o IdP poderá colocar os usuários em risco de ataques de spoofing.

As seções a seguir descrevem as práticas recomendadas ao usar um IdP de backup para acesso de contingência.

Criar um perfil SAML separado para o IdP de backup

Com o Cloud Identity e o Google Workspace, é possível criar vários perfis SAML. Cada perfil SAML pode se referir a um IdP SAML diferente.

Para minimizar a quantidade de trabalho necessária para fazer failover no IdP de backup, prepare um perfil SAML para o IdP de backup com antecedência:

  • Crie perfis SAML separados para o IdP principal e o de backup.
  • Configure atribuições de perfil de SSO para atribuir apenas o perfil SAML do IdP principal durante as operações normais.
  • Modifique as atribuições de perfil de SSO para usar o perfil SAML do IdP de backup durante uma interrupção do IdP. Não mude as configurações individuais do perfil SAML.

Usar um IdP local

Não é necessário provisionar um IdP extra para servir como backup. Em vez disso, verifique se é possível usar um IdP local para essa finalidade. Por exemplo, sua organização pode usar o Active Directory como fonte autoritativa de identidades e também usar os Serviços de federação do Active Directory (AD FS) para SSO. Nesse cenário, talvez seja possível usar o AD FS como IdP de backup.

Essa abordagem de reutilização pode ajudar a limitar o custo e a sobrecarga de manutenção.

Prepare o IdP de backup para lidar com a carga necessária

Quando você muda a autenticação para o IdP de backup, ele precisa processar todas as solicitações de autenticação que seu IdP principal normalmente processa.

Ao implantar e dimensionar um IdP de backup, lembre-se de que o número de solicitações esperadas depende dos seguintes fatores:

  • O número de usuários na sua conta do Cloud Identity ou do Google Workspace.
  • A duração da sessão configurada.Google Cloud

Por exemplo, se a duração da sessão for entre 8 e 24 horas, as solicitações de autenticação poderão aumentar durante a manhã, quando os funcionários começam o dia de trabalho.

Teste o procedimento de failover periodicamente

Para garantir que o processo de failover do SSO funcione de maneira confiável, verifique-o periodicamente. Ao testar o procedimento de failover, faça o seguinte:

  • Modifique manualmente a atribuição de perfil de SSO de uma ou mais unidades organizacionais ou grupos para usar o IdP de backup.
  • Verifique se o SSO com o IdP de backup funciona conforme esperado.
  • Verifique se os certificados de assinatura estão atualizados.

A seguir

Colaboradores

Autor: Johannes Passing | Arquiteto de soluções na nuvem

Outro colaborador: Ido Flatow | Arquiteto de soluções do Cloud