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 Google Cloud recursos. A continuidade dos negócios tem como objetivo 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 serviços e infraestrutura críticos não estão disponíveis.

Este documento é destinado a profissionais de segurança ou confiabilidade que são responsáveis pelo Identity and Access Management (IAM, na sigla em inglês) 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 de IAM.

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

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

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

  2. Fornecer alternativas de autenticação para usuários críticos: Se sua organização usa Logon único (SSO, na sigla em inglês), qualquer interrupção que afete o provedor de identidade (IdP, na sigla em inglês) externo pode afetar a capacidade dos funcionários de 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 para os negócios continuem acessando Google Cloud os recursos.

  3. Usar um IdP de backup: para permitir que todos os usuários acessem Google Cloudrecursos durante uma interrupção do IdP, você pode manter um IdP de backup.

    Um IdP de failover 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 Google Cloud recursos e evitar situações em que você possa perder o acesso completamente.

Os usuários de acesso de emergência são caracterizados pelas seguintes propriedades:

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

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

Para Google Cloud ambientes que hospedam cargas de trabalho de produção, o acesso de emergência é fundamental. Para Google Cloud ambientes 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 no 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 da conta podem interromper o acesso a uma conta. Para atenuar esse risco, você pode criar mais de um usuário de acesso de emergência para cada conta do Cloud Identity ou do Google Workspace.

Os usuários de acesso de emergência têm muitos privilégios. Portanto, 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 de acesso de emergência para cada conta do Cloud Identity ou do Google Workspace.

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

Os usuários de acesso de emergência exigem 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 normais, use uma unidade organizacional (UO) dedicada para usuários de acesso de emergência. Uma UO separada permite aplicar configurações personalizadas apenas a usuários de emergência.

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

Use chaves de segurança FIDO (identificação rápida on-line) para a verificação em duas etapas.

Como os usuários de acesso de emergência são usuários com muitos privilégios na sua conta do Cloud Identity ou do Google Workspace, é necessário protegê-los 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 forte. 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 os 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.
  • Para todos os usuários de acesso de emergência, ative a verificação em duas etapas.
  • Para cada usuário de acesso de emergência, registre duas ou mais chaves de segurança FIDO.

Ao registrar 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 de acesso de emergência.

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

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

  • Impeça que pessoas não autorizadas acessem as credenciais de usuário de acesso de emergência. Os usuários de acesso de emergência precisam usar essas credenciais apenas em uma emergência.
  • Garanta que o pessoal autorizado possa acessar as credenciais com o mínimo de atraso durante uma emergência.

Recomendamos que você não dependa de 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 de acesso de emergência.

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

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

Evitar a automação para a 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 comprometimento da segurança. Os usuários de acesso de emergência têm privilégios de superadministrador. Para girar a 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 garantir que você não enfraqueça sua postura de segurança geral, não use a automação para girar as senhas.

Usar senhas fortes

Para ajudar a proteger os usuários de 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ê gire as senhas manualmente, desative a expiração de senha para todos os usuários de 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 baseadas no contexto podem causar uma situação em que até mesmo um usuário de acesso de emergência não consiga 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 políticas de acesso.

Essas isenções ajudam a garantir que pelo menos um dos 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 de acesso de emergência podem manter o acesso.

Configurar alertas para eventos de usuário de acesso de emergência

Qualquer atividade de usuário de 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 de acesso de emergência, crie uma regra de relatório no Google Admin Console. Ao criar uma regra de relatório, você pode 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 for > 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

Fornecer 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 IdP de terceiros se torna fundamental. Qualquer interrupção no 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, você pode configurar sua conta do Cloud Identity ou do Google Workspace para usar um failover de autenticação para usuários críticos. Você pode usar o seguinte plano de failover:

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

As seções a seguir descrevem as práticas recomendadas ao permitir que usuários críticos se autentiquem durante interrupções de IdP externo.

Focar em usuários privilegiados

Para que os usuários críticos se autentiquem durante uma interrupção do serviç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 dos usuários automaticamente, dependendo do seu IdP. Portanto, talvez seja necessário pedir aos usuários que definam uma senha manualmente.
  • Talvez seja necessário pedir aos usuários que registrem uma chave de acesso ou se inscrevam na verificação em duas etapas. Essa etapa geralmente não é necessária para usuários de 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. É mais provável que esses usuários se beneficiem significativamente do acesso ininterrupto, e eles podem ser apenas uma fração da sua base de usuários geral.

Aproveitar 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 essa sobrecarga, você também pode ativar a verificação pós-SSO para esses usuários.

Por padrão, ao configurar o SSO para seus usuários, eles não precisam realizar a verificação em duas etapas. Embora essa prática seja conveniente, se o IdP for comprometido, qualquer usuário que não tenha 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 atenuar o efeito potencial de um comprometimento do IdP, porque os usuários precisam realizar 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 postura de segurança dessas contas de usuário sem sobrecarga adicional.

Usar uma UO separada para usuários privilegiados

Os usuários privilegiados que podem se autenticar durante interrupções de IdP externo exigem uma configuração especial. Essa configuração é diferente da configuração para usuários normais e para usuários de acesso de emergência.

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

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

Usar um IdP de backup

Ao fornecer alternativas de autenticação para usuários críticos durante interrupções do IdP, você ajuda a reduzir o efeito dessa interrupção do IdP 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 podem não conseguir acessar aplicativos e serviços essenciais.

Para reduzir ainda mais o efeito potencial de uma interrupção do IdP, você pode fazer 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 se autentiquem usando o SSO e o IdP principal.
  • Durante uma interrupção do IdP, você muda 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 à configuração do seu 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 de contingência abrangente. No entanto, é necessário ponderar essas vantagens em relação aos riscos adicionais que um IdP de backup pode introduzir. Esses riscos potenciais incluem o seguinte:

  • Se o IdP de backup tiver uma segurança mais fraca do que o IdP principal, a postura de segurança geral do seu Google Cloud ambiente também poderá ser mais fraca durante um failover.
  • Se o IdP principal e o IdP de backup forem diferentes na forma como 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

O Cloud Identity e o Google Workspace permitem 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 para o IdP de backup, prepare um perfil SAML para o IdP de backup com antecedência:

  • Crie perfis SAML separados para o IdP principal e para o IdP de backup.
  • Configure as 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 atual

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

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

Preparar o IdP de backup para processar a carga necessária

Ao mudar a autenticação para o IdP de backup, ele precisa processar todas as solicitações de autenticação que o 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.
  • O tempo de sessão configurado Google Cloud .

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

Testar o procedimento de failover periodicamente

Para garantir que o processo de failover de SSO funcione de maneira confiável, é necessário verificar o processo periodicamente. Ao testar o procedimento de failover, faça o seguinte:

  • Modifique manualmente a atribuição de perfil de SSO de uma ou mais UOs ou grupos para usar o IdP de backup.
  • Verifique se o SSO com o IdP de backup funciona conforme o 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 na nuvem