Tocantins suspende sistema financeiro estadual após tentativas de ataque cibernético

A Secretaria da Fazenda do Tocantins (Sefaz) informou nesta segunda-feira (5) que identificou e bloqueou, na sexta-feira (2), várias tentativas de ataque cibernético contra o Sistema Integrado de Administração Financeira do Estado (Siafe-TO) — a plataforma que processa pagamentos e movimentações financeiras do governo estadual. Segundo a pasta, uma das tentativas envolveu uma operação financeira cujo pagamento não foi autorizado pela instituição bancária. Os mecanismos de segurança e os procedimentos de controle impediram outras transações suspeitas, e a Sefaz afirma que não houve prejuízo aos cofres públicos.

Como parte do protocolo de resposta a incidentes, o governo suspendeu temporariamente o funcionamento do Siafe-TO e retirou o Portal da Transparência do ar de forma preventiva. A previsão é restabelecer o portal nesta terça-feira (6) e o Siafe-TO até quinta-feira (8), condicionado às verificações técnicas e de segurança. O sistema não atende só a administração estadual: é usado também pelo Tribunal de Justiça, Tribunal de Contas, Ministério Público, Defensoria Pública e Assembleia Legislativa. Foi instituída uma força-tarefa interinstitucional, e a Sefaz registrou boletim de ocorrência para investigar a origem das tentativas.

Fonte: Jornal Opção · T1 Notícias · Conexão Tocantins

Por que isso importa

O detalhe mais relevante do caso não é o volume da tentativa — que a Sefaz não detalhou — e sim onde ela parou: na autorização da instituição financeira. Em sistemas que executam ação crítica, como aprovar um pagamento, a última barreira costuma ser um controle de autorização, não o perímetro da rede. Quando uma operação não autorizada chega até esse ponto, a pergunta que fica não é "o firewall aguentou?", mas quem — ou qual API, token ou credencial — conseguiu iniciar uma transação de pagamento sem a dupla validação prevista. É um padrão recorrente em operações financeiras, públicas e privadas: os controles existem no papel, mas raramente são testados por alguém tentando, de propósito, contorná-los.

O segundo ponto é o custo da resposta. Suspender um sistema financeiro central por dias — com pagamentos parados e o portal de transparência fora do ar — também é impacto. A decisão foi correta do ponto de vista de segurança, mas só foi necessária porque as tentativas chegaram até a camada transacional.

O que a organização deve testar e monitorar

• Quem está autorizado a executar ação crítica (iniciar, aprovar, alterar beneficiário de pagamento) e se esse controle resiste a abuso de função, manipulação de parâmetro e uso de credencial antiga.
• Se os controles de aprovação funcionam de fato — não se estão documentados, mas se foram exercitados por uma simulação de adversário antes do incidente.
• Trilha de auditoria exportável: quem fez o quê, quando, de qual IP e com qual conta, para reconstruir o ocorrido sem investigação manual.
• Detecção e resposta: tempo entre o primeiro sinal e a contenção, e o plano de continuidade dos órgãos que dependem do mesmo sistema.

É a mesma classe de risco de qualquer operação com sistema crítico: acesso, credencial, API, superfície, auditoria e resposta. O caso é um lembrete de que testar isso é trabalho contínuo — não item de checklist anual.