- A conta do Google Cloud da SSLMate foi suspensa pela terceira vez sem aviso prévio, interrompendo repetidamente os recursos de integração do serviço
- Para a integração dos clientes com Cloud DNS e Cloud Domains, a empresa usava uma estrutura de criação e delegação de contas de serviço conforme a documentação do Google, mas esse modelo continuou sendo alvo de suspensão
- A primeira suspensão (2024) causou grande confusão por causa da ineficiência do processo de recuperação e da falta de clareza sobre a causa; nas duas suspensões seguintes também houve apenas e-mails automatizados repetidos, sem aviso prévio
- Como alternativa, a autenticação baseada em chaves de longa duração é frágil do ponto de vista de segurança, e o OIDC (OpenID Connect) exige um processo de configuração excessivamente complexo
- Como resultado, as integrações com o Google Cloud revelam uma limitação estrutural: só é possível escolher dois entre segurança, conveniência e estabilidade
Caso de suspensões recorrentes de conta no Google Cloud
- A conta da SSLMate no Google Cloud foi suspensa sem aviso prévio em duas sextas-feiras consecutivas, em 2024 e 2025
- Já havia ocorrido a mesma suspensão em 2024 e, nas três vezes, não foi fornecida uma razão clara nem um método para evitar reincidência
- Para se integrar às contas de Google Cloud dos clientes, a SSLMate usa um modelo de delegação de contas de serviço
- Para cada cliente, cria uma conta de serviço dentro de um projeto da SSLMate, e o cliente concede a essa conta permissões de acesso ao Cloud DNS e ao Cloud Domains
- Quando necessário, a SSLMate acessa os recursos se passando virtualmente por essa conta (impersonate)
- Essa estrutura é baseada no método recomendado pela documentação oficial do Google e é segura e simples de configurar, sem credenciais de longa duração
Primeira suspensão (2024)
- Na primeira suspensão, todas as integrações com clientes falharam e o acesso ao console foi bloqueado
- A equipe de suporte do Google respondeu, mas o processo de recuperação foi ineficiente, com e-mails devolvidos porque a conta estava desativada
- Foi solicitado o ID do projeto, mas isso não podia ser fornecido porque o acesso ao console estava indisponível
- Após verificação por número de telefone, apenas alguns projetos foram restaurados, e no dia seguinte chegou novamente um e-mail automático notificando restrição de acesso
- Depois de vários e-mails automáticos, a recuperação completa ocorreu cerca de 19 horas depois
- O Google não revelou o motivo da suspensão e também não houve aviso prévio por e-mail
- Depois disso, a SSLMate adicionou um health check para monitorar a taxa de erro das integrações e tentar detectar o problema mais cedo
Segunda suspensão (por volta de outubro de 2025)
- O health check falhou, e a maioria das integrações retornou o erro “Invalid grant: account not found”
- Era possível fazer login no console, mas chegaram apenas e-mails dizendo que cada projeto havia sido “restaurado com base nas informações fornecidas”
- O e-mail de notificação de suspensão continuou sem chegar
- Depois disso, as integrações voltaram ao normal
Terceira suspensão (novembro de 2025)
- Após nova falha no health check, ao acessar o console apareceu um novo tipo de mensagem de erro
- A maioria dos projetos foi suspensa, incluindo os projetos usados para integração com clientes
- Um recurso foi enviado na sexta-feira, mas no domingo chegou um e-mail notificando a suspensão da conta inteira
- Na segunda-feira, logo após a publicação do texto no Hacker News, a maior parte dos projetos foi restaurada e, algumas horas depois, o acesso total voltou
- Mais uma vez, não foram informados a causa da suspensão nem formas de prevenção
Caso excepcional de um cliente
- Mesmo durante todos os períodos de suspensão, a integração de um cliente continuou funcionando normalmente
- Embora usasse uma conta de serviço no mesmo projeto, ela não foi afetada
- Não houve explicação adicional sobre a causa
Problema de dependência do Google Cloud e alternativas
- A SSLMate concluiu que não pode depender de contas do Google em ambiente de produção
- O sistema do Google permite que contas, projetos ou até todo o GCP sejam suspensos de forma arbitrária
- Alternativa 1: o cliente cria diretamente a conta de serviço e fornece autenticação à SSLMate com uma chave de longa duração (long-lived key)
- A configuração é simples, mas a segurança é fraca por causa do risco de vazamento da chave e da impossibilidade de rotação
- Alternativa 2: usar OpenID Connect (OIDC)
- É o método padrão usado em integrações com GitHub Actions e Azure, permitindo acesso seguro sem credenciais de longa duração
- Porém, no Google Cloud, a configuração exige um processo de 7 etapas, excessivamente complexo
Complexidade da configuração com OIDC
- Para usar OIDC, são necessárias as seguintes etapas
- Ativar a IAM Service Account Credentials API
- Criar uma conta de serviço
- Criar um Workload Identity Pool
- Criar um Workload Identity Provider dentro do Pool
- Conceder permissão para que a SSLMate possa se passar pela conta de serviço
- Conceder um papel (Role) à conta de serviço
- Enviar à SSLMate o ID da conta de serviço criada e o ID do Provider
- Cada etapa exige os IDs de recursos da etapa anterior, o que dificulta para os clientes seguirem o processo
- O autor aponta as seguintes etapas como procedimentos desnecessários
- Deveria ser possível conceder diretamente os papéis sem criar uma conta de serviço
- Na maioria dos casos, o Pool contém apenas um Provider, então a própria criação do Pool é uma duplicação desnecessária
- Também deveria ser possível conceder papéis diretamente ao URL do emissor OIDC e ao subject, sem criar um Provider
Problema estrutural e conclusão
- Hoje, nas integrações com o Google Cloud, só é possível escolher dois entre os três itens abaixo
- Não usar credenciais de longa duração
- Ser fácil para o cliente configurar
- Estar protegido contra suspensões arbitrárias
- O modelo baseado em contas de serviço da SSLMate garante segurança e conveniência, mas continua exposto ao risco de suspensão
- O modelo de conta de serviço + chave é fácil de configurar e sofre menos risco de suspensão, mas tem segurança fraca
- O modelo com OIDC oferece mais segurança e proteção contra suspensão, mas a configuração é complexa
- A conclusão é que, enquanto o Google não simplificar o OIDC como um método de integração de primeira classe, será difícil ter uma integração segura e estável
Resumo dos comentários dos leitores
- Um leitor comentou: “Use outro provedor de nuvem, o GCP é o pior”
- O autor respondeu: “Os clientes usam GCP, então isso é necessário para a integração”
- Outro leitor observou: “Segurança e confiabilidade entram em conflito com simplicidade”, e que clientes que priorizam simplicidade talvez não sejam adequados
2 comentários
"Android developer verification acabaria exatamente assim. Muitas pessoas seriam banidas de desenvolver para Android."
Esse é o comentário do Hacker News de que mais me lembro. Acho que isso não está longe de acontecer.
Comentários do Hacker News
As pessoas pensam no Google como um parceiro confiável, mas na prática ele é um sistema projetado como uma grande fábrica de varejo
atende milhões de pessoas, e uma única medida de proteção automática errada pode arruinar a vida de milhares
a ausência de suporte ao cliente ou respostas automatizadas sem sentido parecem não ser apenas corte de custos, mas uma estratégia para minimizar responsabilidade legal
a maioria das pessoas sabe que uma conta do Google pode ser suspensa a qualquer momento, sem motivo
na prática, quase todo mundo conhece uma ou duas pessoas que perderam acesso à conta
a menos que seja um contrato de milhões de dólares, acho que quase ninguém vê o Google como um parceiro de verdade
Todas as plataformas priorizam escalabilidade
é impossível manter uma relação humana com cada usuário individual e, ao mesmo tempo, preservar margens de lucro no nível de traficantes
se uma pessoa inocente for pega por engano, isso é tratado como “um custo necessário”
ontem foi a Wise, antes disso foram contas do GitHub bloqueadas desse jeito
empresas não funcionam como democracias, mas como feudos
se um sistema automatizado decidir que você é criminoso, a punição vem imediatamente, sem julgamento
nelas você pode falar com uma pessoa de verdade, e não com um chatbot simplório
hoje uso o Tuta Mail, e gosto da criptografia resistente a computadores quânticos e do ambiente sem anúncios
também posso criar quantos aliases quiser com meu próprio domínio
Alguns anos atrás, minha conta do YouTube Premium foi bloqueada por spam
eu só assistia vídeos, mas mesmo assim a conta foi apagada e o acesso à página de pagamento também foi bloqueado
enquanto eu passava pelo processo robótico de apelação, possível só uma vez a cada 3 semanas, as cobranças continuavam
até o suporte pago do Google One foi inútil, dizendo que “era outra equipe e não podia ajudar”
no fim, resolvi cancelando o cartão, e meses depois recebi uma mensagem dizendo que “foi um erro”
ironicamente, o WeChat resolveu meu caso em um dia com atendimento humano — fiquei com a sensação de que o suporte ao cliente de um Estado censor é melhor
O problema não é só o Google, mas toda a estrutura das grandes empresas dependentes de algoritmos
no Reddit também tomei shadowban sem motivo numa conta de 20 anos
os recursos foram ignorados, e todas as minhas postagens e comentários passaram a ser filtrados
o Fediverse mostra um modelo alternativo melhor — a chave são comunidades pequenas e uma alta proporção de moderadores
a estrutura em que uma única tag #fediblock leva a bloqueios automáticos em centenas de servidores acaba repetindo uma censura sem responsabilidade
na prática, a instância de Mastodon da nossa cidade quebrou assim, e todo mundo migrou para o Bluesky
não seria difícil manter umas 100 pessoas para lidar com esses casos de borda
mas eles não fazem isso porque reduziria a margem
não é falta de dinheiro, é uma escolha de não gastar
Parece que esse tipo de problema também vai aparecer na API Gemini
se um cliente gerar uma imagem que viole as regras, isso pode levar à suspensão permanente imediata do Gmail corporativo ou até do Gmail pessoal usado para recuperação
A certificação de desenvolvedor Android também parece caminhar para isso
há uma grande chance de muitos desenvolvedores sofrerem suspensão da conta de desenvolvedor sem motivo claro
já vi um caso em que as contas pessoais de funcionários de uma pequena empresa foram bloqueadas junto, sob a alegação de estarem “associadas a uma conta de desenvolvedor previamente suspensa”
acho difícil manter especialização quando se está tão dependente da plataforma
Nosso serviço usava apenas o botão “Login with Google”, mas de repente a conta foi bloqueada
a única justificativa era vaga: “violação dos termos”
enquanto enviávamos recurso e corríamos para criar uma alternativa de login para os usuários, no dia seguinte chegou do nada um e-mail dizendo que “o recurso foi aprovado”
no fim a conta foi restaurada, mas ficou um sentimento de desconfiança
Minha conta do AdSense foi suspensa três vezes porque coloquei um ponto de exclamação no anúncio
no fim fechei a conta, mas acho que ainda devo estar sendo rastreado como uma “conta potencialmente fraudulenta”
se a estrutura é feita para suspender um usuário novo em uma hora, fica a dúvida de por que o processo de cadastro é tão fácil desde o início
Numa situação dessas, dá vontade de pensar se o certo seria processar o Google ou exigir regulação mais dura
ouvi dizer que muitas vezes o Google nem comparece, ou tenta se defender com base nos TOS e isso acaba irritando o juiz
Fico curioso sobre o que acontece com contas que usam login apenas com Passkey e foram registradas com um e-mail suspenso
quase ninguém deve ter testado se uma Passkey sincronizada no Google Password Manager continua funcionando depois da suspensão da conta,
ou se a falta de acesso ao e-mail torna a recuperação impossível