Um canal de controle infalsificável: TOFU + assinatura assimétrica
Quando um sistema pode enviar comandos às máquinas dos clientes, a pergunta mais importante é: quem está realmente autorizado a enviá-los? A resposta intuitiva — "uma senha interna secreta" — é mais fraca do que parece. Veja por que escolhemos algo mais forte.
A ideia intuitiva: um segredo compartilhado
A ideia óbvia: existe uma "senha interna" que só o sistema conhece, e todo comando é verificado contra ela. Se algo estranho tentar injetar um comando — ele não conhece o segredo, então falha. Parece razoável.
Mas há uma fraqueza aqui: para verificar um comando, o segredo precisa estar presente no ponto de verificação. Se a nossa nuvem ou a máquina forem violadas — o segredo fica legível, e o atacante forja comandos à vontade. Um segredo compartilhado (mesmo rotativo) se quebra no momento em que alguém o vê.
O que escolhemos: assinatura assimétrica
Em vez de um segredo compartilhado, usamos um par de chaves assimétricas. O operador tem uma chave privada que nunca o deixa, e todo comando é assinado com ela. O agente na máquina detém apenas a chave pública — que consegue verificar uma assinatura, mas não consegue forjá-la.
A diferença é fundamental: uma violação completa tanto da nossa nuvem quanto da máquina do cliente não consegue forjar um comando, porque a chave privada simplesmente não está presente em nenhum desses lugares. Nossa nuvem apenas retransmite o comando assinado — ela não verifica nem executa nada.
Segundo reforço: TOFU — fixação de chave
Mas e se um atacante que violou a nossa nuvem trocar a chave pública pela dele? Então ele poderia assinar em nome próprio. Para fechar isso, adicionamos o TOFU (Trust On First Use): o agente fixa a chave do operador uma vez, na primeira inscrição. Em cada verificação posterior, ele confere se a chave que a nuvem apresenta é idêntica à fixada — e, se não for, recusa.
Rotacionar a chave é, portanto, uma ação deliberada fora de banda, não uma sobrescrita silenciosa a partir da nuvem. Um atacante que assumiu a nossa nuvem não consegue trocar a chave fixada — o agente simplesmente não aceitará a troca.
Terceiro reforço: sem shell livre
Mesmo que uma assinatura válida fosse de algum modo produzida, queríamos que o dano possível fosse limitado. Portanto, as ações são uma lista de permissão finita e paramétrica (como reiniciar ou reiniciar-serviço) — e não há ação de "executar comando arbitrário". Removemos deliberadamente todo caminho que passe uma string para um shell. Nem mesmo uma assinatura válida jamais alcança um shell root.
Como testamos
Verificamos o modelo no comportamento, não apenas na teoria: simulamos o cenário em que a nuvem apresenta uma chave diferente da fixada e confirmamos que o agente de fato recusa (rc=2) e não executa. Esse padrão — fixar → verificar → recusar — é o cerne da nossa resiliência de cadeia de suprimentos.
Como continuamos aprimorando isto — controle de qualidade contínuo
Confiança não é "configurar e esquecer". Todo comando é gravado num log de auditoria imutável (quem, quando, o quê, qual assinatura), de modo que qualquer ação pode ser reconstruída após o fato. Os próximos passos já planejados: anti-replay (nonce + carimbo de tempo na forma canônica, para que um comando antigo não possa ser reproduzido), um token por servidor em vez de um token compartilhado e um "kill-switch" no nível do cliente. Também atacamos a nós mesmos (purple-team autorizado) para provar que as defesas realmente se sustentam. Esta camada continua ficando mais forte.
Este artigo descreve o modelo de confiança em nível de princípio — e isso é, na verdade, uma força para publicar, porque saber como a defesa funciona não ajuda um atacante (a chave privada não é exposta). Não há aqui chaves, segredos ou detalhes de implementação sensíveis.
← Todos os posts