Se você suspeitar que uma das suas credenciais foi comprometida, tome medidas imediatas para limitar o impacto dessa violação na suaCloud de Confiance by S3NS conta.
As credenciais doCloud de Confiance controlam o acesso aos recursos hospedados no Cloud de Confiance.O Cloud de Confiance inclui credenciais de longa e curta duração. Para ajudar a manter seus dados seguros e protegidos contra invasores, você precisa lidar com suas credenciais com o máximo de cuidado e responder rapidamente a qualquer suspeita de comprometimento.
Cloud de Confiance credentials
A tabela a seguir descreve credenciais Cloud de Confiance comuns.
| Credencial | Descrição |
|---|---|
| Chaves privadas de conta de serviço (arquivos JSON e p12) |
Tipo:credencial de serviço de longa duração Locais típicos:
Correção:chaves e tokens de contas de serviço |
| Tokens de conta de serviço (tokens de acesso do OAuth 2.0) |
Tipo:credencial de curta duração Locais típicos:
Correção:chaves e tokens de contas de serviço |
| Chaves de API |
Tipo:credencial de serviço de longa duração Locais típicos:
Correção:chaves de API |
| Chaves secretas de ID do cliente OAuth 2.0 |
Tipo:credencial de serviço de longa duração Locais típicos:
|
| Credenciais da Google Cloud CLI |
Tipo:credencial de usuário de longa duração Local típico:diretório inicial do usuário. Para listar as credenciais ativas, execute o comando Remediação:Credenciais do usuário e tokens OAuth da CLI do Google Cloud |
| Tokens de acesso OAuth para a Google Cloud CLI |
Tipo:credencial de curta duração Local típico:estações de trabalho de desenvolvedores Remediação:credenciais de usuário e tokens OAuth da CLI gcloud |
| Application Default Credentials |
Tipo:credencial de usuário de longa duração Local típico:estações de trabalho de desenvolvedores Correção:Application Default Credentials |
| Cookies do navegador |
Tipo:credencial de usuário de longa duração Localização típica:específica do navegador, mas geralmente armazenada em estações de trabalho de desenvolvedores Remediação:cookies do navegador |
| Tokens de acesso federado do Security Token Service para a federação de identidade da carga de trabalho |
Tipo:credencial de curta duração Locais típicos:
Correção:tokens de acesso federado do Serviço de token de segurança |
| Tokens de acesso federado do Security Token Service para a federação de identidade da força de trabalho |
Tipo:credencial de curta duração Locais típicos:
Correção:tokens de acesso federado do Serviço de token de segurança |
Proteja seus recursos do Cloud de Confiance contra o comprometimento de credenciais
Se você suspeitar que uma credencial está comprometida, revogue e emita novamente. Continuar para não ter uma interrupção do serviço como resultado da revogação. credenciais.
Em geral, para reemitir credenciais, gere uma nova, implante-a para todos os serviços e usuários que precisam dela e, em seguida, revogue a credencial antiga.
As seções a seguir têm instruções específicas para cada tipo de credencial.
Chaves e tokens de conta de serviço
Conclua as etapas a seguir para substituir uma chave de conta de serviço comprometida e bloquear tokens de conta de serviço de curta duração comprometidos.
Os tokens de conta de serviço de curta duração existem separadamente da credencial ou permissão usada para gerá-los e não podem ser revogados. Os tokens de acesso da conta de serviço são tokens de portador e permanecem válidos até o tempo de expiração (por padrão, até 60 minutos ou até 12 horas se uma política de ciclo de vida estendido do token for configurada).
Ao contrário dos tokens de acesso concedidos a identidades de usuário, tokens de acesso concedidos a contas de serviço não podem ser invalidados no Admin Console ou em comandos como gcloud auth revoke.
Além disso, a duração da sessão especificada no
controle de sessão doCloud de Confiance
se aplica a contas de usuário no diretório do Cloud Identity ou
do Google Workspace, mas não a contas de serviço. Portanto, a
resposta ao incidente para contas de serviço comprometidas precisa resolver os
arquivos de chaves permanentes e os tokens de acesso de curta duração.
Funções exigidas
Para receber as permissões necessárias para responder a chaves e tokens de conta de serviço comprometidas, peça ao administrador para conceder a você os seguintes papéis do IAM:
-
Gerenciar chaves da conta de serviço:
Administrador da chave da conta de serviço (
roles/iam.serviceAccountKeyAdmin) no projeto que contém a conta de serviço -
Desativar, ativar ou excluir contas de serviço:
Administrador da conta de serviço (
roles/iam.serviceAccountAdmin) no projeto que contém a conta de serviço -
Aplicar políticas de negação para bloquear tokens ativos:
Administrador de negação (
roles/iam.denyAdmin) na organização -
Revogue os papéis de representação:
Administrador do IAM do projeto (
roles/resourcemanager.projectIamAdmin), Administrador da conta de serviço (roles/iam.serviceAccountAdmin) no projeto
Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.
Esses papéis predefinidos contêm as permissões necessárias para responder a chaves e tokens de conta de serviço comprometidas. Para acessar as permissões exatas necessárias, expanda a seção Permissões necessárias:
Permissões necessárias
As seguintes permissões são necessárias para responder a chaves e tokens de conta de serviço comprometidas:
-
Gerenciar chaves de conta de serviço:
-
iam.serviceAccountKeys.createno projeto que contém a conta de serviço -
iam.serviceAccountKeys.deleteno projeto que contém a conta de serviço -
iam.serviceAccountKeys.listno projeto que contém a conta de serviço
-
-
Desativar, ativar ou excluir contas de serviço:
-
iam.serviceAccounts.disableno projeto que contém a conta de serviço -
iam.serviceAccounts.enableno projeto que contém a conta de serviço -
iam.serviceAccounts.deleteno projeto que contém a conta de serviço
-
-
Aplicar políticas de negação para bloquear tokens ativos:
iam.denypolicies.createna organização -
Revogar papéis de representação:
-
resourcemanager.projects.setIamPolicyno projeto -
iam.serviceAccounts.setIamPolicyno projeto que contém a conta de serviço
-
Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.
Responder a chaves e tokens de conta de serviço comprometidos
Para bloquear um token de conta de serviço comprometido, faça uma das seguintes ações:
Desative a conta de serviço que a credencial representa.
Aplique uma política de negação do IAM ao principal da conta de serviço (
principal://iam.googleapis.com/projects/-/serviceAccounts/SA_EMAIL_ADDRESS) nos seus projetos ou pastas. A política de negação do IAM nega o acesso a APIs e permissões sensíveis para tokens e cargas de trabalho ativos. Assim, você pode investigar o incidente sem destruir a conta de serviço.
Se você desativar ou excluir a conta de serviço, qualquer carga de trabalho que a use perderá imediatamente o acesso aos recursos.
Para substituir uma chave de conta de serviço comprometida, siga estas etapas:
No console Cloud de Confiance , acesse a página Contas de serviço.
Localize a conta de serviço afetada.
Se necessário, crie uma nova chave para a conta de serviço e implante-a em todos os locais em que a chave antiga estava em uso.
Desative a chave antiga para verificar se a nova funciona conforme o esperado.
Exclua a chave antiga.
Para mais informações, consulte Criar e excluir conta de serviço de serviço.
Se principais não autorizados tiverem permissão para gerar tokens, revogue o papel Criador de token da conta de serviço (
roles/iam.serviceAccountTokenCreator). Para instruções, consulte Gerenciar o acesso a projetos, pastas e organizações.Depois que o incidente for resolvido, aguarde pelo menos 60 minutos após desativar a conta de serviço para que o token comprometido possa expirar. Se você definir uma política de ciclo de vida estendido usando
constraints/iam.allowServiceAccountCredentialLifetimeExtension, aguarde o tempo especificado na restrição antes de reativar a conta de serviço.Depois que o tempo de espera necessário passar, reative a conta de serviço e redefina a política de negação.
Credenciais do usuário e tokens OAuth da CLI gcloud
Depois que um endpoint for comprometido, determine como responder à ameaça principal de um endpoint comprometido e à ameaça secundária de tokens comprometidos. Se um invasor tiver acesso persistente à estação de trabalho do desenvolvedor, ele poderá copiar tokens novamente após a reautenticação do usuário legítimo.
Funções exigidas
Para ter as permissões necessárias para revogar o acesso do usuário e invalidar tokens OAuth da CLI gcloud no Admin Console do Google Workspace, peça ao administrador para conceder a você os seguintes papéis de administrador do Google Workspace:
- Gerenciar apps conectados de terceiros e controles de sessão: Administrador de segurança ou Superadministrador
- Gerenciar credenciais de usuário e sessões de login: administrador de gerenciamento de usuários ou superadministrador
- Execute o script de revogação de diretório do SDK Admin: superadministrador ou uma função de administrador personalizada com privilégios da API Admin para gerenciamento de usuários (
https://www.googleapis.com/auth/admin.directory.user.security)
Para mais informações sobre como atribuir funções de administrador no Google Workspace, consulte Atribuir funções de administrador no Google Admin Console.
Invalidar tokens da CLI gcloud para contas de usuário específicas
Siga estas etapas para remover o acesso de um usuário à CLI gcloud e invalidar todos os tokens comprometidos:
Para remover o acesso de um usuário à Google Cloud CLI, siga uma destas etapas:
Como administrador do Google Workspace, remova o acesso à Google Cloud CLI da lista de apps conectados do usuário. Para saber mais, consulte Ver e remover o acesso a aplicativos de terceiros.
Forneça as seguintes instruções ao usuário:
Abra a lista de apps com acesso à sua Conta do Google.
Remova a Google Cloud CLI da lista de apps conectados.
Quando o usuário acessar a Google Cloud CLI de novo, ele vai precisar reautorizar o aplicativo.
Se você extraiu ou interceptou uma string de token comprometida específica (seja um token de atualização ou de acesso), é possível invalidá-la diretamente usando o endpoint de revogação do OAuth 2.0 do Google:
curl -d "token=TOKEN_STRING" \ -H "Content-Type: application/x-www-form-urlencoded" \ -X POST "https://oauth2.googleapis.com/revoke"Quando você executa esse comando para revogar um token de atualização, ele revoga o token de atualização e todos os tokens de acesso associados. Ao executar esse comando para revogar um token de acesso, você também invalida o token de atualização associado.
Se você ainda não tiver aplicado o controle de sessão doCloud de Confiance , ative-o imediatamente com uma frequência curta de reautenticação. Esse controle ajuda a garantir que todos os tokens de atualização expirem no final da duração definida, o que limita o tempo em que um invasor pode usar os tokens comprometidos.
Invalidar tokens da CLI gcloud para muitas contas de usuário
Se você suspeitar de uma violação, mas não conseguir identificar quais usuários foram afetados, revogue as sessões ativas para todos os usuários da sua organização mais rapidamente do que a política de reautenticação permite.
Essa abordagem pode ser prejudicial para usuários legítimos e encerrar processos de longa duração que dependem das credenciais do usuário. Se você escolher adotar essa abordagem, prepare uma solução de script para a Central de Operações de Segurança (SOC, na sigla em inglês) para ser executada com antecedência e teste com alguns usuários.
O exemplo de código a seguir usa o SDK Admin do Google Workspace para identificar todas as identidades de usuário na sua conta do Google Workspace ou do Cloud Identity que têm acesso à CLI gcloud. Se um usuário tiver autorizado a CLI gcloud, o script revogará o token de atualização e o token de acesso e forçará o usuário a se autenticar novamente com a senha ou a chave de segurança. Para instruções sobre como ativar a API SDK Admin e executar esse código, consulte o Guia de início rápido do Google Apps Script.
Application Default Credentials
Se você suspeitar que uma credencial padrão do aplicativo está comprometida, poderá revogá-la. Esse procedimento pode causar uma interrupção temporária até que o arquivo de credenciais seja recriado.
Funções exigidas
Para conseguir as permissões necessárias para remover o acesso de aplicativos conectados no Admin Console do Google Workspace, peça ao administrador para conceder a função de administrador de segurança ou superadministrador.
Os comandos locais executados em estações de trabalho de desenvolvedores não exigem papéis de administrador. Para mais informações sobre como atribuir funções de administrador no Google Workspace, consulte Atribuir funções de administrador no Google Admin Console.
Revogar o Application Default Credentials
Siga uma das etapas a seguir:
Como administrador do Google Workspace, remova o acesso à Biblioteca do Google Auth da lista de apps conectados do usuário. Para saber mais, consulte Ver e remover o acesso a apps de terceiros.
Instrua o proprietário da credencial comprometida a fazer o seguinte:
Instale e inicialize a CLI gcloud, caso ainda não tenha feito isso.
Revogue as credenciais:
gcloud auth application-default revokeSe não for possível executar a CLI gcloud, faça o seguinte:
Revogue o acesso à Biblioteca de autenticação do Google usando myaccount.google.com/permissions ou o endpoint de revogação do OAuth 2.0.
Exclua manualmente o arquivo
application_default_credentials.json:- Linux, macOS:
$HOME/.config/gcloud/application_default_credentials.json - Windows:
%APPDATA%\gcloud\application_default_credentials.json
- Linux, macOS:
Recrie o arquivo de credenciais com sua identidade de usuário:
gcloud auth application-default login
Chaves de API
Siga estas etapas para regenerar uma chave de API comprometida.
Funções exigidas
Para receber as permissões necessárias
para gerenciar chaves de API,
peça ao administrador para conceder a você o papel do IAM de
Administrador de chaves de API (roles/serviceusage.apiKeysAdmin) no projeto.
Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.
Esse papel predefinido contém as permissões necessárias para gerenciar chaves de API. Para acessar as permissões exatas necessárias, expanda a seção Permissões necessárias:
Permissões necessárias
As seguintes permissões são necessárias para gerenciar chaves de API:
-
apikeys.keys.create -
apikeys.keys.delete -
apikeys.keys.update -
apikeys.keys.getKeyString -
apikeys.keys.list -
apikeys.keys.get
Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.
Regenerar uma chave de API
No Cloud de Confiance console, acesse a página Credenciais.
Clique no nome da chave de API que você quer girar.
Clique em Alternar chave.
Insira um nome e confirme as restrições.
Clique em Criar.
Atualize os aplicativos para usar a nova chave de API.
Em Chave anterior, clique em Excluir a chave anterior.
Para mais informações, consulte Girar uma chave de API.
Chaves secretas do ID do cliente OAuth 2.0
Alterar uma chave secreta de ID do cliente causa uma interrupção temporária enquanto a chave secreta é alternada.
Funções exigidas
Para receber as permissões necessárias
para redefinir os segredos de ID do cliente OAuth 2.0,
peça ao administrador para conceder a você o
papel do IAM de Editor de configuração do OAuth (roles/oauthconfig.editor) no projeto.
Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.
Esse papel predefinido contém as permissões necessárias para redefinir secrets de ID do cliente OAuth 2.0. Para acessar as permissões exatas necessárias, expanda a seção Permissões necessárias:
Permissões necessárias
As seguintes permissões são necessárias para redefinir secrets de ID do cliente OAuth 2.0:
-
clientauthconfig.clients.createSecret -
clientauthconfig.clients.getWithSecret -
clientauthconfig.clients.update -
clientauthconfig.clients.get
Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.
Redefinir uma chave secreta de ID do cliente OAuth 2.0
No Cloud de Confiance console, acesse a página Credenciais.
Selecione e edite o ID do cliente OAuth 2.0 comprometido.
Clique em Redefinir secret.
Implante o novo secret no aplicativo.
Para saber mais, consulte Como configurar o OAuth 2.0 e Como usar o OAuth 2.0 para acessar as APIs do Google.
Tokens de acesso federado do Security Token Service
Quando as sessões de identidade externa são comprometidas, é necessário interromper as novas trocas de tokens e revogar os tokens de acesso federado ativos. Essa tarefa se aplica a tokens de acesso emitidos pela federação de identidade da carga de trabalho ou pela federação de identidade da força de trabalho.
Funções exigidas
Para receber as permissões necessárias para gerenciar a federação de identidade da carga de trabalho e a federação de identidade da força de trabalho para bloquear tokens federados, peça ao administrador para conceder a você os seguintes papéis do IAM:
-
Gerenciar pools e provedores de identidade de carga de trabalho:
Administrador de pool de Identidade da carga de trabalho (
roles/iam.workloadIdentityPoolAdmin) no projeto que contém o pool de identidade da carga de trabalho -
Gerenciar pools e provedores de identidade da força de trabalho:
Administrador do pool de colaboradores (
roles/iam.workforcePoolAdmin) na organização que contém o pool de identidade da força de trabalho -
Aplique políticas de negação para bloquear tokens ativos:
Administrador de negação (
roles/iam.denyAdmin) na organização -
Gerenciar identidade temporária de conta de serviço:
Administrador da conta de serviço (
roles/iam.serviceAccountAdmin) no projeto que contém a conta de serviço
Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.
Esses papéis predefinidos contêm as permissões necessárias para gerenciar a Federação de identidade da carga de trabalho e a Federação de identidade da força de trabalho para bloquear tokens federados. Para acessar as permissões exatas necessárias, expanda a seção Permissões necessárias:
Permissões necessárias
As permissões a seguir são necessárias para gerenciar a federação de identidade da carga de trabalho e a federação de identidade de colaboradores para bloquear tokens federados:
-
Gerenciar pools e provedores de identidade de carga de trabalho:
-
iam.workloadIdentityPools.updateno projeto que contém o pool de identidades da carga de trabalho -
iam.workloadIdentityPoolProviders.updateno projeto que contém o pool de identidades da carga de trabalho
-
-
Gerenciar pools e provedores de identidade da força de trabalho:
-
iam.workforcePools.updatena organização que contém o pool de identidades de força de trabalho -
iam.workforcePoolProviders.updatena organização que contém o pool de identidades de força de trabalho
-
-
Aplique políticas de negação para bloquear tokens ativos:
-
iam.denypolicies.createna organização -
iam.denypolicies.updateno projeto, na pasta ou na organização
-
-
Gerenciar a identidade temporária de conta de serviço:
iam.serviceAccounts.setIamPolicyno projeto que contém a conta de serviço
Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.
Bloquear tokens de acesso federado
Siga uma das etapas a seguir:
Para bloquear novas trocas de tokens, desative o provedor de pool de Identidade da carga de trabalho ou o provedor de pool de identidade de colaboradores.
Para bloquear novas trocas de tokens e tokens ativos em todo um pool, desative o pool de identidades da carga de trabalho ou desative o pool de identidades de colaboradores.
Para bloquear o acesso imediato de tokens de portador ativos (válidos por até uma hora), faça uma destas ações:
Para bloquear o acesso direto aos recursos, revogue os papéis do IAM para o principal ou principalSet afetado ou aplique uma política de negação do IAM temporária.
Se a identidade federada representar uma conta de serviço (
roles/iam.workloadIdentityUser), conclua Chaves e tokens de conta de serviço. Para evitar problemas futuros de representação, remova a vinculação de papel de representação.
No seu provedor de identidade, gire as credenciais comprometidas, revogue as sessões ativas ou exclua a entidade comprometida.
Cookies do navegador
Siga estas etapas para invalidar cookies do navegador para um usuário.
Funções exigidas
Para receber as permissões necessárias para encerrar a sessão de um usuário e forçar uma mudança de senha no Admin Console do Google Workspace, peça ao administrador para conceder a você a função de administrador de gerenciamento de usuários ou superadministrador.
Para mais informações sobre como atribuir funções de administrador no Google Workspace, consulte Transformar um usuário em administrador.
Invalidar cookies do navegador
Se você suspeitar que os cookies do navegador foram comprometidos, faça o seguinte:
Como administrador do Google Workspace, saia da conta de um usuário e force imediatamente uma mudança de senha.
Oriente o usuário a sair da Conta do Google e mudar a senha imediatamente.
Essas ações invalidam todos os cookies, e o usuário precisará fazer login novamente.
Investigar acesso e recursos não autorizados após revogar credenciais
Depois de revogar as credenciais comprometidas e restaurar o serviço, revise todo o acesso aos recursos do Cloud de Confiance . É possível usar o Cloud Logging ou o Security Command Center.
Funções exigidas
Para ter as permissões necessárias para investigar acesso e recursos não autorizados, peça ao administrador para conceder a você os seguintes papéis do IAM:
-
Ver registros de auditoria no Cloud Logging:
Leitor de registros (
roles/logging.viewer) no projeto, na pasta ou na organização -
Veja os registros de auditoria de acesso a dados no Logging:
Leitor de registros particulares (
roles/logging.privateLogViewer) no projeto, na pasta ou na organização -
Ver descobertas no Security Command Center:
Leitor de descobertas da Central de segurança (
roles/securitycenter.findingsViewer) no projeto ou na organização
Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.
Esses papéis predefinidos contêm as permissões necessárias para investigar acessos e recursos não autorizados. Para acessar as permissões exatas necessárias, expanda a seção Permissões necessárias:
Permissões necessárias
As permissões a seguir são necessárias para investigar acesso e recursos não autorizados:
-
Acessar registros de auditoria no Logging:
-
logging.logEntries.listno projeto, na pasta ou na organização -
logging.views.accessno projeto, na pasta ou na organização
-
-
Ver os registros de auditoria de acesso a dados no Logging:
logging.privateLogEntries.listno projeto, na pasta ou na organização -
Veja as descobertas no Security Command Center:
-
securitycenter.findings.listno projeto ou na organização -
securitycenter.findings.getno projeto ou na organização
-
Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.
Investigar acesso e recursos não autorizados
No Logging, faça o seguinte:
Analise os registros de auditoria no console doCloud de Confiance .
Pesquise todos os recursos possivelmente afetados e verifique se todas as atividades da conta (especialmente as relacionadas às credenciais comprometidas) estão conforme o esperado.
Por exemplo, faça o seguinte:
- Pesquise todas as chamadas de API iniciadas pela identidade comprometida durante a janela do incidente.
- Se a identidade tiver privilégios de representação, pesquise ações em que
protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmailcorresponda ao principal comprometido. - Verifique se novas chaves de conta de serviço, contas de usuário ou chaves SSH no nível do projeto foram criadas durante o incidente.
No Security Command Center, faça o seguinte:
No console do Cloud de Confiance , acesse a página Descobertas do Security Command Center.
Se necessário, selecione o Cloud de Confiance projeto ou a organização.
Na seção Filtros rápidos, clique em um filtro apropriado para exibir a descoberta necessária na tabela Resultados da consulta de descobertas. Por exemplo, se você selecionar Event Threat Detection ou Detecção de Ameaças em Contêiner na subseção Nome de exibição da origem, somente descobertas do serviço selecionado aparecem nos resultados.
A tabela será preenchida com descobertas da origem selecionada.
Para ver detalhes sobre uma descoberta específica, clique no nome da descoberta em Categoria. O painel de detalhes da descoberta se expande para exibir um resumo dos detalhes da descoberta.
Para exibir todas as descobertas causadas pelas ações do mesmo usuário:
- No Painel de detalhes da descoberta, copie o endereço de e-mail ao lado de E-mail principal.
- Fechar painel.
No Editor de consultas, digite a seguinte consulta:
access.principal_email="USER_EMAIL"Substituir USER_EMAIL pelo endereço de e-mail que você copiado anteriormente.
O Security Command Center exibe todas as descobertas associadas a ações realizadas pelo usuário que você especificou.
Excluir todos os recursos não autorizados
Verifique se não há recursos inesperados, como VMs, aplicativos do App Engine, contas de serviço e buckets do Cloud Storage, que a credencial comprometida possa acessar.
Depois de identificar todos os recursos não autorizados, você pode excluí-los imediatamente. A ação imediata é especialmente importante para recursos do Compute Engine, porque os invasores podem usar contas violadas para exfiltrar dados ou comprometer os sistemas de produção.
Para excluir recursos não autorizados, consulte a seguinte documentação:
- Excluir uma instância do Compute Engine
- Excluir um bucket do Cloud Storage
- Excluir uma conta de serviço
Como alternativa, tente isolar os recursos não autorizados para que suas próprias equipes forenses realizem análises adicionais.
Entre em contato com o atendimento ao cliente
Se precisar de ajuda para encontrar as Cloud de Confiance descobertas e as ferramentas necessárias para as etapas de investigação e mitigação, entre em contato com o Cloud Customer Care e abra um caso de suporte.
Lidar com bloqueios de conta
Se você não conseguir acessar sua conta, considere as seguintes opções:
Use o formulário de recuperação de conta do Google Workspace, disponível na caixa de ferramentas do administrador do Google Workspace. Para mais informações, consulte Recuperar o acesso de administrador à conta.
Se um invasor estiver criando recursos fraudulentos enquanto você está completamente bloqueado e tiver um direito de suporte, faça o seguinte:
Em uma janela anônima, acesse o Solucionador de problemas de contato com o suporte.
Selecione Sim e clique em Enviar um tíquete.
Preencha e envie o formulário com seus dados.
Se um invasor estiver criando recursos fraudulentos enquanto você está completamente bloqueado e não tem direito a suporte, faça o seguinte:
Em uma janela anônima, acesse o Solucionador de problemas de contato com o suporte.
Responda às perguntas da seguinte forma:
Pergunta do solucionador de problemas Seleção obrigatória Você tem direito a suporte? Não Você está no período de teste sem custos financeiros? Não Você é o administrador de faturamento de uma conta de faturamento do GCP (Cloud de Confiance)? Não Você está enfrentando alguma dessas situações? Não consigo mais acessar meu projeto do GCP ou minha conta de faturamento e preciso recuperar o acesso. Clique em Enviar um tíquete para nossa equipe de recuperação de acesso.
Preencha e envie o formulário de contato não autenticado com seus dados, incluindo IDs de conta de faturamento ou indicadores de pagamento que você possa fornecer para verificar sua identidade.
A seguir
Implemente as práticas recomendadas a seguir para evitar o comprometimento de credenciais:
Práticas recomendadas relacionadas a falhas de autenticação em Mitigar o OWASP Top 10:2025 no Cloud de Confiance. Por exemplo, separe as credenciais do código e use o Secret Manager para armazenar e gerenciar secrets.
Práticas recomendadas para proteger credenciais de desenvolvedor.