Instabilidade na criação de processos - IDCloud

Update timeline

1. investigating Mar 04, 2026, 11:50 AM UTC

   Nossa monitoração identificou um possível impacto no envio de links no IDCloud. Nosso time de tecnologia está analisando o ambiente.

2. identified Mar 04, 2026, 11:53 AM UTC

   Prezado Cliente, Identificamos a causa da instabilidade no envio de links no IDCloud. Nosso time de tecnologia está atuando na resolução do incidente. Em breve retornamos com atualizações.

3. monitoring Mar 04, 2026, 11:54 AM UTC

   Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

4. resolved Mar 04, 2026, 11:55 AM UTC

   Resumo Executivo e Impacto O incidente teve início às 07:20 (Horário de Brasília) e foi totalmente resolvido às 09:40, com a mitigação principal ocorrendo às 07:35. Durante um intervalo de aproximadamente 2 horas e 20 minutos, identificamos uma instabilidade que afetou o serviço de Mensageria, impedindo o envio de comunicações críticas (como SMS) para o fluxo de criação de processos no IDCloud. Além disso, observamos um impacto secundário no serviço de IDToken, que afetou pontualmente a emissão de tokens biométricos para um grupo reduzido de clientes (menos de 100 erros registrados no total). É importante ressaltar que não houve qualquer perda ou comprometimento de dados de clientes ou da Unico durante este evento. Causa Raiz e Resolução A indisponibilidade foi originada por uma alteração de configuração na camada de rede e segurança que envolve o nosso serviço de autenticação. Ao migrarmos esse serviço para um novo provedor de proteção de borda, o sistema de segurança interpretou erroneamente as requisições internas legítimas vindas de nossa infraestrutura em nuvem como tráfego automatizado malicioso (bots). Isso ocorreu porque essas chamadas específicas não continham um cabeçalho de identificação padrão esperado pelo novo filtro. Ações de Correção: Identificação: Detectamos o bloqueio de segurança em menos de 5 minutos após os primeiros alertas. Mitigação: Às 07:35, aplicamos uma regra de liberação total no provedor de borda para restabelecer o fluxo de dados entre os serviços. Estabilização: Monitoramos o ambiente para garantir que os serviços legados e o fluxo de tokens retornassem à normalidade, o que foi confirmado após a cessação dos erros residuais. Compromisso e Próximos Passos Nossa prioridade agora é garantir que situações semelhantes não se repitam em futuras migrações de infraestrutura. Um Postmortem detalhado será compartilhado com todos os stakeholders em breve, focando na criação de novos protocolos de migração que incluam fases de monitoramento passivo ("log only") antes do bloqueio efetivo de tráfego. Pedimos sinceras desculpas pelo transtorno causado aos nossos clientes e parceiros. Seguimos à disposição para quaisquer esclarecimentos. Atenciosamente, Equipe Unico

5. postmortem Apr 09, 2026, 01:35 PM UTC

   **Resumo** Em 4 de março de 2026, uma mudança de configuração em nossa infraestrutura causou uma queda na disponibilidade dos serviços de criação de processos e de tokens biométricos. A equipe técnica identificou rapidamente o problema e implementou uma mitigação em poucos minutos, restaurando a operação normal do sistema. ‌ **Impacto** Durante o incidente, a disponibilidade do serviço principal de criação de processos caiu de aproximadamente 99% para a faixa de 80% em poucos minutos. Um pico de 350 a 400 erros foi registrado entre as 07h35 e 07h37 \(horário de Brasília\). Um serviço secundário focado na obtenção de tokens também foi impactado, apresentando intermitências das 07h20 até aproximadamente 08h23. Esse impacto secundário afetou menos de 100 requisições, concentrando-se majoritariamente em um cliente específico. A conformidade de estabilidade deste serviço caiu temporariamente para a faixa de 85% a 89%. ‌ **Causa Raiz** O incidente foi desencadeado por uma alteração de DNS projetada para adicionar uma nova camada de segurança ao nosso domínio de autenticação. Após a migração, as requisições internas originadas do nosso provedor de nuvem chegaram à nova camada de segurança sem um cabeçalho HTTP padrão \("user-agent"\), o que antes não era necessário. Devido a essa ausência de cabeçalho e ao alto volume, as novas regras de segurança classificaram incorretamente o tráfego interno como atividade automatizada maliciosa \(bots\) e começaram a bloquear as requisições. Sem conseguir obter os tokens de autenticação necessários, o serviço principal passou a retornar erros aos usuários. O serviço secundário também foi afetado ao entrar em um ciclo de repetições contínuas de tentativas falhas ao lidar com esses bloqueios. ‌ **Resolução** Nossa equipe de engenharia identificou a causa raiz e aplicou imediatamente uma regra de liberação irrestrita na nova camada de segurança às 07h35, o que cessou os bloqueios instantaneamente. O serviço principal se recuperou completamente em cerca de 15 minutos após o impacto inicial. O serviço secundário foi totalmente estabilizado em seguida, após as 08h23. A equipe tomou a decisão estratégica de mitigar o bloqueio ajustando as regras de segurança ao invés de reverter as configurações de DNS, evitando assim atrasos de propagação que teriam prolongado o impacto aos usuários. ‌ **Ações Corretivas** * Definir e documentar um procedimento padrão para migrações de camadas de segurança que garanta a prevenção de bloqueios ao tráfego legítimo. * Configurar a liberação padrão \(allowlist\) de todos os endereços IP de saída da nossa infraestrutura interna nas camadas de segurança, prevenindo falsos positivos. * Realizar auditorias e remover dependências de infraestrutura legada que possam gerar falhas em cascata entre os serviços. **Lições Aprendidas** * Futuras migrações que envolvam novas regras de rede não devem ocorrer sem a validação prévia de como o tráfego interno existente será classificado. * Implementações de novas ferramentas de segurança devem sempre adotar uma implantação gradual, começando com regras de observação e liberação geral antes da ativação de recursos restritivos. * Ao planejar mudanças, é essencial avaliar antecipadamente se um procedimento de reversão \(rollback\) é a estratégia mais rápida e segura para a recuperação, definindo abordagens alternativas sempre que a reversão for complexa.