>_ andre@system
← cd ../articles // VOLTAR AOS ARTIGOS
bash - viewer: seguranca-missao-critica-shm.md
Publicado
DATA_PUBLICACAO
AUTOR André Souza
TAGS Missão Crítica, Governança, Segurança, SHM, Arquitetura

Segurança em Missão Crítica: Como a Experiência com Baixo Nível no BB Moldou a Arquitetura do SHM

Por que telas bonitas não sustentam operação. Como a vivência com Assembly, C e Payakan guiou a auditoria, rastreabilidade e governança estrita de um sistema corporativo.

Cover: Segurança em Missão Crítica: Como a Experiência com Baixo Nível no BB Moldou a Arquitetura do SHM

Quem já precisou debugar rotinas em Assembly ou lidar com comunicação de baixo nível em C em sistemas bancários de alta escala sabe de uma verdade fundamental: o computador não perdoa premissas implícitas.

Na época em que atuei no ecossistema do Banco do Brasil (BB Tecnologia e Serviços), lidando com terminais de autoatendimento, segurança operacional e protocolos proprietários como o Payakan, aprendi que qualquer brecha na validação de limites ou no rastreamento de estado se transforma em prejuízo real no fechamento contábil. Em sistemas de missão crítica, a segurança não é uma camada decorativa adicionada no fim do projeto. Ela é a própria modelagem dos dados e das transições de estado.

Quando observo a onda recente de desenvolvimento acelerado com agentes de IA, percebo que muitos times confundem velocidade de prototipação com software pronto para produção. Sem governança arquitetural, assistentes de IA geram interfaces funcionais que falham silenciosamente na integridade dos dados e na auditoria.

Ao projetar o Support Hours Manager (SHM), um sistema para Gestão de Contratos de Suporte e Manutenção de Software construído com auxílio de agentes autônomos, apliquei rigorosamente os mesmos princípios de segurança e conformidade aprendidos em décadas de engenharia de software corporativa.

1. Integridade Transacional e Razão Imutável de Saldo

Em contratos de sustentação, o saldo de horas é o ativo financeiro mais sensível. A abordagem ingênua consiste em armazenar um campo numérico editável no registro do contrato e decrementá-lo a cada atendimento.

No SHM, o saldo de horas funciona como um razão contábil. Toda e qualquer alteração de saldo é derivada exclusivamente de lançamentos vinculados a ciclos de manutenção aprovados. Não existe endpoint para ajuste arbitrário de saldo sem contrapartida em um evento formal de auditoria. Isso impede inconsistências silenciosas e fraudes operacionais.

Uma falha clássica de segurança em sistemas corporativos é permitir que tarefas avancem sem a devida autorização do cliente.

O SHM implementa uma máquina de estados estrita para os ciclos de manutenção: orçado, aguardando aprovação, aprovado, em execução, aguardando aceite e aceito. Para eliminar atrito sem comprometer a autenticidade, adotamos o padrão Magic Link com tokens criptográficos de uso único e expiração temporal. O cliente autoriza o início do ciclo ou assina o aceite final com um clique autenticado, gerando um registro imutável com carimbo de tempo e IP de origem.

3. Trava Rígida de Tolerância Orçamentária (+30%)

Em operações de suporte, a sangria financeira costuma ocorrer por apontamentos descontrolados em chamados emergenciais.

Para conter isso no nível do domínio, o SHM impõe uma trava programática que impede o lançamento de horas que ultrapassem o limite de tolerância estabelecido (+30% sobre o orçado). Quando esse limite é atingido, o sistema bloqueia novos apontamentos na camada de serviço e exige que um novo ciclo aditivo seja formalizado e aprovado. A regra reside no backend, desacoplada da interface, impedindo qualquer tentativa de bypass.

4. Linha de Auditoria Forense

Inspirado nas exigências de conformidade e auditoria de sistemas financeiros, o SHM registra cada transição de estado, despacho de notificação e alteração de escopo em uma trilha de auditoria append-only.

Se um chamado for cancelado, reaberto ou contestado, o histórico completo do que foi orçado, executado e comunicado permanece intacto para perícia técnica. O banco de dados preserva o estado histórico mesmo em caso de exclusão lógica (soft delete).

5. Cobertura de 79 Testes Automatizados Guiando a IA

A velocidade proporcionada por ferramentas como Claude Code e Antigravity só se sustenta quando existem barreiras claras de proteção.

No SHM, cada requisito de segurança, trava de tolerância e cálculo de saldo foi protegido por uma suíte de 79 testes automatizados (TDD/SDD). Antes de qualquer refatoração ou adição de funcionalidade pelo agente, os testes garantem que nenhuma invariante de segurança seja quebrada.

Conclusão

Construir software corporativo na era da inteligência artificial exige maturidade de engenharia. Agentes de IA aceleram a codificação, mas a responsabilidade sobre a arquitetura de segurança, a integridade dos dados e a conformidade regulatória permanece sendo do engenheiro de software.

A experiência com missão crítica ensina que a confiança do cliente não se conquista na velocidade da entrega, mas na robustez com que o sistema protege a operação dele ao longo do tempo.

← Voltar para todos os artigos Ver versão corporativa →