Doogree
Resposta · Remediação

Corrigir com consentimento: remediar sem cruzar a linha

06/07/2026 · leitura de ~5 min
RemediaçãoNIST RespondTOFUCanal de Controle Assinado

A detecção é apenas metade do trabalho. A outra metade é corrigir — mas a remediação automática cega é exatamente tão perigosa quanto o próprio problema. A abordagem da Doogree é simples: não corrigimos pelas suas costas. Todo problema corrigível aflora como uma sugestão, alguém a aprova e só então uma ação conhecida, restrita e reversível segue seu caminho.

A anatomia de uma sugestão de correção

Todo problema corrigível não é executado por conta própria — ele é proposto. O operador vê três botões: Aprovar / Corrigir, Agora não, Descartar. Tocar em Aprovar envia uma ação modelada, em lista de permissão — e não um comando de shell arbitrário — e então o sistema reverifica o estado e executa o laço novamente até que o problema seja resolvido ou descartado. Não há "corrigir tudo com um clique" rodando no escuro; há uma cadeia curta de sugestão → aprovação → ação → verificação.

Uma sugestão, não uma execução. O padrão é sempre que o humano (ou, mais adiante, uma política definida) esteja no laço. Uma ação relevante nunca acontece sem consentimento explícito, e cada uma tem uma trilha de auditoria completa — quem aprovou, o que foi enviado e qual foi o resultado.

Por que não há shell livre — o modelo de confiança

O segredo é que as ações não são "execute este comando". As ações contra um servidor são enviadas por um canal de controle assinado, com fixação TOFU (Trust On First Use): a forma canônica do comando é assinada, de modo que um replay ou uma adulteração são detectados imediatamente. Não há shell livre — apenas ações de uma lista de permissão, chamadas por seus nomes explícitos. O significado prático: mesmo que uma nuvem ou um banco de dados sejam violados, um atacante não consegue forjar um comando e transformá-lo em RCE na frota. A linha entre "detectar" e "executar código num dispositivo" é guardada com zelo.

Privilégio mínimo em ação. Toda ação sabe exatamente o que tem permissão para fazer, e nada além disso. Não há "chave para toda porta" — há chaves específicas, em lista de permissão, cada uma abrindo apenas uma porta e deixando um rastro.

Incidente crítico → botão de contenção

O corrigir-com-consentimento se conecta diretamente ao motor de incidentes. Quando o motor SIEM-lite agrupa múltiplos alertas num incidente correlacionado com severidade alta/crítica, ele oferece automaticamente um botão de contenção. Aprovar o botão age pelo mesmo canal de controle assinado — o mesmo modelo de confiança, a mesma lista de permissão, a mesma auditoria. Assim, a cadeia de ataque não é apenas detectada e marcada — ela recebe uma ação de resposta reversível a um toque de distância.

Por que isso é crítico para uma pequena empresa

Uma pequena empresa geralmente não tem um engenheiro de segurança em tempo integral. O corrigir-com-consentimento dá a um dono de empresa não especialista um botão seguro de "corrigir isto" — totalmente documentado — em vez de precisar de um SOC caro. E, quando é algo relevante, o humano permanece no laço; mais adiante, você pode restringi-lo por uma política com aprovação 2FA (push-approval), para que uma ação arriscada só saia após verificação.

O arcabouço teórico: este é o estágio Respond do NIST — não apenas detectar, mas responder de forma controlada. Tudo é construído sobre o privilégio mínimo e sobre a segurança da cadeia de suprimentos: não há canal pelo qual uma nuvem violada pudesse lançar comandos arbitrários nos dispositivos. Remediação — sim. Cruzar a linha — jamais.

← Voltar ao blog · Como funciona →