Modelagem de ameaças para uma plataforma pequena em VPS offshore

A modelagem de ameaças tem fama de ser um ritual corporativo com diagramas que ninguém lê. Não precisa ser assim. Para uma pequena plataforma, a versão útil leva uma hora, produz uma lista classificada, e seu principal resultado é saber quais riscos as escolhas de infraestrutura realmente afetam — porque, para a maioria deles, a resposta honesta é nenhum.

A ordem importa mais do que a completude

O erro clássico é uma lista longa com tudo o que pode dar errado, tratada como igualmente urgente. Isso produz paralisia e, ainda assim, uma decisão tomada por impulso. Uma lista classificada de sete itens vale mais do que uma lista exaustiva de quarenta, porque apenas os três primeiros costumam ser colocados em prática — o restante nunca é alcançado de qualquer maneira.

Classifique por probabilidade × custo envolvido, não pelo quanto o cenário soa alarmante. Um adversário estatal é o item mais assustador de qualquer lista e, para quase toda pequena plataforma, o menos provável — enquanto um vazamento de credenciais por um antigo prestador de serviços é banal, extremamente comum e, em geral, catastrófico.

Sete adversários, classificados por probabilidade

Adversários por probabilidade e o que os mitiga

Adversário	Probabilidade	A hospedagem ajuda	O que realmente mitiga
O operador, num dia ruim	Certa	Não	Backups que já foram efetivamente restaurados ao menos uma vez, e um processo de mudança para tudo que envolva autenticação ou DNS. A causa mais provável da pior interrupção é o próprio operador.
Varredura automatizada	Constante	Não	Aplicação de patches, ausência de autenticação por senha, ausência de credenciais padrão. Isso é ruído de fundo constante; não tem alvo específico e nunca cessa.
Comprometimento de credenciais	Alta	Não	Segundo fator em hardware, tokens de API com escopo limitado, e revogação de acesso no dia em que alguém sai, e não no trimestre seguinte.
Um reclamante com um formulário	Alta	Sim	Este é o único caso que a jurisdição de hospedagem realmente resolve: se uma simples correspondência é suficiente para tirar o serviço do ar.
Ataque volumétrico	Média	Parcialmente	Filtragem a montante e, especificamente, um provedor que filtra em vez de recorrer a null-routing para se proteger, deixando o serviço fora do ar.
Um invasor direcionado	Baixa	Não	Segmentação, privilégio mínimo, dados criptografados em repouso e registros em um local que o invasor não consiga alterar.
Um agente estatal	Muito baixa	Parcialmente	A jurisdição molda o caminho jurídico, não o técnico. Se isso realmente fizer parte do modelo, o indicado é buscar aconselhamento jurídico, não um plano de hospedagem.

Quais deles uma decisão de hospedagem afeta

Dois de sete, e parcialmente um terceiro. Essa proporção é, isoladamente, o resultado mais útil do exercício, e é por isso que fazê-lo antes de escolher um provedor economiza mais dinheiro do que qualquer tabela comparativa.

A versão de uma hora

1. Liste o que é efetivamente mantido (10 min). Não sistemas — dados. Endereços de e-mail de usuários, registros de pagamento, mensagens privadas, arquivos enviados, credenciais de outros serviços. Anote o que seria pior perder e o que seria pior vazar; raramente é a mesma coisa.
2. Liste quem haveria de querer cada um deles (10 min). Seja específico. “Hackers” não é um adversário; “alguém que compra vazamentos de credenciais para revender contas” é, e isso implica defesas diferentes.
3. Classifique por probabilidade × custo (10 min). Ignore o quão dramático cada item soa. Os itens banais dominam.
4. Para os três primeiros, escreva a primeira hora (20 min). O que seria feito nos primeiros sessenta minutos de cada um. Se a resposta não existir, esse é o achado — e ele vale mais do que a própria classificação.
5. Marque quais são afetados pelas escolhas de infraestrutura (10 min). Normalmente, dois dos cinco primeiros. A partir daí, fica claro o que a decisão de hospedagem está de fato comprando.

Repita o exercício quando algo estrutural mudar — um novo tipo de dado, uma nova integração, a saída de alguém — em vez de seguir um calendário fixo. Revisões programadas por calendário costumam ser puladas; as motivadas por eventos costumam ser feitas, porque há um motivo concreto à vista.

Três erros que tornam todo o exercício inútil

Modelar o adversário considerado mais interessante. Pensar na capacidade de um Estado-nação é mais divertido do que pensar em um token de API vazado em um repositório público. Um desses dois já aconteceu com quase todo mundo. Classifique com honestidade e os itens monótonos vencem — esse é justamente o objetivo.

Confundir um controle com um resultado. “Usamos criptografia” não é uma mitigação enquanto não for possível dizer o que ela impede e o que não impede. A criptografia de disco completo em um servidor em funcionamento protege contra um disco que sai do prédio; ela não faz nada contra um invasor com um shell na máquina em produção, porque o volume já está desbloqueado.

Produzir um documento em vez de uma decisão. Se nada mudou depois do exercício — nenhuma permissão revogada, nenhum backup testado, nenhuma pergunta feita ao provedor —, não foi uma modelagem de ameaças, foi apenas uma tarde. O resultado deve ser três ações, cada uma com um nome atribuído.

Se a linha do reclamante for a que domina a tabela, a próxima pergunta é qual jurisdição escolher e como verificar o que um provedor afirma a respeito dela — seis perguntas, respondíveis em uma tarde. Se ela nem aparecer entre os cinco primeiros, provavelmente não há necessidade deste serviço, e esse já é um ótimo resultado para uma hora de trabalho.

Escrito pelos engenheiros que operam a plataforma, e revisado em há 1 mês. Se algo aqui estiver errado ou desatualizado, informe pelo painel — foi de lá que veio cerca de metade destes conteúdos.