Objetivos de segurança e modelos de ameaça para decisões criptográficas

Decisões criptográficas boas começam antes de escolher algoritmos, tamanhos de chave ou bibliotecas. Elas começam com duas perguntas: (1) quais objetivos de segurança você precisa atingir e (2) contra quem (e contra o quê) você está se defendendo. Este capítulo organiza esses dois pontos em um processo prático: definir objetivos (o “o que” proteger), construir um modelo de ameaça (o “de quem” e “como” pode ser atacado) e, a partir disso, derivar requisitos criptográficos verificáveis.

Objetivos de segurança: o que a criptografia deve garantir

“Objetivo de segurança” é uma propriedade desejada do sistema. Em criptografia aplicada, os objetivos mais comuns são confidencialidade, integridade, autenticidade, não repúdio e disponibilidade. Nem todo sistema precisa de todos, e confundir objetivos leva a soluções erradas (por exemplo, “criptografar” algo quando o problema real é integridade).

Confidencialidade

Confidencialidade significa impedir que partes não autorizadas aprendam o conteúdo de dados. Em termos práticos: alguém pode capturar tráfego, copiar um banco de dados, acessar backups, ou ler logs; ainda assim, não deve conseguir recuperar o conteúdo protegido.

Exemplos de requisitos de confidencialidade bem formulados:

• “Somente o serviço X e o serviço Y podem ler o campo documento do cliente.”
• “Um atacante que obtenha um dump do banco não consegue recuperar números de cartão sem acesso às chaves.”
• “Um usuário não consegue ler mensagens de outro usuário, mesmo com acesso ao próprio dispositivo.”

Armadilhas comuns: (a) achar que “TLS resolve tudo” quando o risco é vazamento em repouso; (b) criptografar dados, mas deixar chaves no mesmo lugar e com as mesmas permissões do dado; (c) esquecer metadados (quem falou com quem, quando, tamanho da mensagem), que podem ser sensíveis mesmo com conteúdo cifrado.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Integridade

Integridade é garantir que dados não foram alterados de forma não autorizada. Sem integridade, confidencialidade pode ser insuficiente: um atacante pode não ler o conteúdo, mas pode modificar valores (por exemplo, trocar um destinatário, alterar um valor monetário, injetar comandos).

Exemplos práticos:

• “O cliente não pode alterar o valor de uma transação enviada ao servidor sem detecção.”
• “Um arquivo de atualização não pode ser modificado por um intermediário.”
• “Um token não pode ter seus campos (role, exp) alterados sem invalidar a assinatura.”

Integridade frequentemente exige autenticação de mensagem (MAC) ou assinatura digital, e também exige atenção a como os dados são serializados (ordem de campos, canonicalização) para evitar ambiguidades.

Autenticidade (autenticação de origem)

Autenticidade responde: “quem enviou isso?” e “posso confiar que veio de quem diz que veio?”. Em sistemas distribuídos, autenticidade é o que impede que um atacante se passe por um serviço, um usuário ou um componente interno.

Exemplos:

• “O app só aceita respostas do backend legítimo.”
• “O servidor só aceita comandos assinados por um dispositivo provisionado.”
• “Um microserviço só aceita chamadas de outros serviços com identidade verificada.”

Autenticidade pode ser obtida por chaves simétricas (quando as partes compartilham segredo) ou por chaves assimétricas/certificados (quando é necessário escalar ou evitar compartilhamento amplo de segredos).

Não repúdio (quando faz sentido)

Não repúdio é a capacidade de demonstrar para terceiros que uma ação foi realizada por uma entidade, de modo que ela não possa negar de forma plausível. Na prática, isso aparece em contextos regulatórios, contratos, auditoria e trilhas de evidência. É um objetivo mais “jurídico-operacional” e depende de controles além da criptografia (gestão de chaves, identidade, logs imutáveis, processos).

Exemplos:

• “Uma ordem de pagamento deve ser atribuível a um usuário específico com evidência verificável por auditoria.”
• “Um documento assinado deve ser verificável por terceiros sem acesso a segredos internos.”

Armadilha comum: usar assinaturas digitais e assumir automaticamente não repúdio, ignorando que se a chave privada pode ser compartilhada, exportada, ou usada por malware no endpoint, a atribuição fica fraca.

Disponibilidade e resiliência

Disponibilidade é manter o serviço acessível e funcional. Criptografia pode afetar disponibilidade de duas maneiras: (a) proteger contra ataques que derrubam o serviço (por exemplo, autenticação para evitar abuso) e (b) introduzir riscos operacionais (por exemplo, perda de chaves, rotação mal feita, dependência de HSM/KMS).

Exemplos:

• “A perda de um nó não pode impedir a descriptografia de dados críticos (com controles adequados).”
• “Rotação de chaves não pode causar indisponibilidade do serviço.”

Disponibilidade raramente é “resolvida” por um primitivo criptográfico; ela exige arquitetura (redundância, backups, recuperação) e processos (rotação, escrow controlado, testes de restauração).

Privacidade e minimização (objetivo transversal)

Privacidade, no sentido prático, é limitar coleta, exposição e correlação de dados pessoais. Criptografia ajuda, mas também é comum precisar de minimização (coletar menos), segregação (separar domínios), pseudonimização e controles de acesso. Um modelo de ameaça bem feito explicita quais metadados são aceitáveis expor e quais não são.

Modelos de ameaça: contra quem e como

Modelo de ameaça é uma descrição estruturada de adversários, capacidades, superfícies de ataque e cenários. Ele transforma “precisamos de segurança” em hipóteses testáveis: “se um atacante com capacidade X fizer Y, o sistema deve resistir de forma Z”.

Componentes de um modelo de ameaça útil

• Ativos: o que tem valor (dados, chaves, credenciais, dinheiro, reputação, disponibilidade).
• Atores: usuários, serviços internos, administradores, terceiros, atacantes.
• Fronteiras de confiança: onde o controle muda (cliente vs servidor, rede pública vs privada, ambiente interno vs fornecedor).
• Superfícies de ataque: APIs, filas, bancos, storage, logs, CI/CD, endpoints, integrações.
• Capacidades do adversário: interceptar tráfego, ler storage, executar código no cliente, obter credenciais, ser insider, etc.
• Impactos: fraude, vazamento, indisponibilidade, alteração de dados, violação regulatória.

Um bom modelo de ameaça não precisa ser longo; precisa ser específico o suficiente para orientar escolhas. O erro comum é listar ameaças genéricas sem conectar a decisões (por exemplo, “man-in-the-middle” sem dizer onde, com quais consequências e quais controles).

Perfis de adversário (exemplos práticos)

Você pode categorizar adversários por motivação e capacidade. Alguns perfis recorrentes:

• Atacante remoto oportunista: varre a internet, explora configurações fracas, credenciais vazadas, endpoints expostos.
• Atacante com acesso à rede: consegue observar/alterar tráfego (Wi‑Fi público, roteador comprometido, proxy corporativo malicioso).
• Atacante com acesso ao dispositivo do usuário: malware, root/jailbreak, extração de dados locais.
• Insider: funcionário/terceiro com acesso legítimo que abusa de permissões.
• Fornecedor/terceiro comprometido: dependências, integrações, pipelines, bibliotecas.
• Atacante com acesso ao ambiente de nuvem: credenciais de cloud vazadas, IAM mal configurado, snapshots expostos.

O ponto não é “cobrir tudo”, e sim declarar quais perfis você assume como relevantes. Isso define se você precisa, por exemplo, de criptografia ponta a ponta, de criptografia em repouso com chaves fora do banco, de assinaturas em artefatos, ou de segregação forte de chaves.

Escopo e suposições: o que você aceita como risco

Todo modelo de ameaça tem suposições. Exemplos:

• “Assumimos que o servidor pode ser comprometido?” Se sim, talvez seja necessário reduzir confiança no servidor (ponta a ponta, enclaves, segregação de chaves).
• “Assumimos que o cliente pode ser comprometido?” Se sim, criptografia não impede roubo de dados após descriptografia; você foca em limitar impacto (tokens curtos, detecção, revogação, isolamento).
• “Assumimos que o atacante pode ler o banco?” Se sim, criptografia em repouso com chaves bem protegidas vira requisito.

Escrever suposições explicitamente evita decisões incoerentes, como exigir “não repúdio” em um cenário onde chaves privadas ficam em dispositivos sem proteção e sem controles de uso.

Como objetivos e ameaças viram requisitos criptográficos

Objetivos dizem “o que”; ameaças dizem “contra quem/como”; requisitos dizem “o que implementar e como validar”. Requisitos bons são mensuráveis e testáveis.

Exemplo de transformação

Objetivo: confidencialidade de dados sensíveis em repouso. Ameaça: atacante obtém dump do banco via credenciais vazadas. Requisito: “Campos sensíveis devem ser criptografados no nível da aplicação com chaves gerenciadas separadamente do banco; acesso à chave deve exigir identidade do serviço e autorização mínima; rotação deve suportar recriptografia gradual.”

Note que o requisito já aponta decisões: nível de criptografia (aplicação vs storage), separação de chaves, controle de acesso e rotação.

Passo a passo prático: modelagem de ameaça orientada a decisões criptográficas

A seguir, um roteiro aplicável a um serviço, API, aplicativo ou fluxo específico. A ideia é produzir um artefato curto (1–3 páginas) que guie escolhas e revisões.

Passo 1 — Delimite o fluxo e desenhe o caminho do dado

Escolha um fluxo crítico (ex.: “criar pagamento”, “enviar mensagem”, “emitir relatório”). Liste onde o dado nasce, por onde passa e onde fica armazenado. Inclua:

• Cliente (app/web), backend, serviços internos, filas, storage, logs, analytics, backups.
• Protocolos e canais (HTTPS, gRPC, filas, batch).
• Onde há serialização/transformação (JSON, Protobuf, CSV).

Saída esperada: um diagrama simples e uma lista de componentes. Isso revela fronteiras de confiança e pontos onde criptografia pode ser necessária.

Passo 2 — Liste ativos e classifique sensibilidade

Ativos típicos:

• Dados pessoais (PII), dados financeiros, segredos (tokens, senhas, chaves), dados de negócio.
• Chaves criptográficas (de assinatura, de criptografia, de derivação).
• Identidades e credenciais (certificados, chaves de API).

Classifique por impacto de vazamento/alteração: alto, médio, baixo. A classificação ajuda a decidir onde vale custo operacional (HSM/KMS, rotação frequente, auditoria).

Passo 3 — Defina objetivos de segurança por ativo e por etapa

Para cada ativo, declare objetivos em trânsito, em repouso e em uso (quando aplicável). Exemplo para “dados de pagamento”:

• Em trânsito: confidencialidade + integridade + autenticidade do servidor.
• Em repouso: confidencialidade + integridade (detectar adulteração).
• Em uso: limitar exposição (evitar logs, mascarar, reduzir tempo em memória quando possível).

Evite objetivos vagos como “ser seguro”. Prefira frases verificáveis: “somente serviços A e B podem ler”, “qualquer alteração deve ser detectada”, “qualquer comando deve ser autenticado”.

Passo 4 — Identifique adversários relevantes e capacidades

Escolha 2–4 perfis mais prováveis e mais impactantes. Para cada um, escreva capacidades concretas. Exemplo:

• Atacante com acesso à rede: pode interceptar e modificar tráfego entre app e backend.
• Insider de suporte: pode consultar banco e logs, mas não deveria ver campos sensíveis.
• Atacante com credenciais de cloud: pode criar snapshots de disco e baixar backups.

Isso evita “ameaças de catálogo” e foca no que muda decisões.

Passo 5 — Mapeie ameaças por fronteira de confiança

Para cada fronteira (ex.: internet → backend; backend → banco; serviço A → serviço B), pergunte:

• O que um atacante consegue observar?
• O que consegue modificar?
• O que consegue forjar (identidade)?
• O que consegue repetir (replay)?

Exemplo de ameaça de replay: um atacante captura uma requisição válida de “confirmar pagamento” e tenta reenviar. Isso gera requisito de anti-replay (nonce, timestamp, idempotência, tokens de uso único).

Passo 6 — Derive controles criptográficos e controles adjacentes

Agora conecte ameaça → controle. Alguns padrões de decisão:

• Interceptação/modificação em trânsito → canal autenticado e com integridade (ex.: TLS bem configurado) e, quando necessário, autenticação mútua entre serviços.
• Dump de banco/backups → criptografia em repouso; para reduzir risco de insiders, criptografia no nível da aplicação com chaves fora do banco.
• Forja de comandos → assinaturas/MAC em mensagens, autenticação forte de clientes/serviços.
• Atualizações/artefatos → assinatura de código/artefatos e verificação antes de executar.
• Replay → nonces, timestamps, janelas de validade, idempotency keys.
• Exposição de logs → mascaramento, minimização e proibição de registrar segredos.

Inclua controles não criptográficos que são pré-requisitos: IAM mínimo, segregação de funções, auditoria, hardening, monitoramento, rate limiting.

Passo 7 — Transforme em requisitos testáveis e critérios de aceite

Escreva requisitos no formato “deve” + condição + como validar. Exemplos:

• “O serviço deve rejeitar tokens expirados e tokens com assinatura inválida; testes automatizados devem cobrir casos de alteração de payload.”
• “Campos cpf e cartao devem ser criptografados antes de persistir; uma consulta direta ao banco não deve revelar valores em claro.”
• “Chaves de criptografia devem ser rotacionadas sem indisponibilidade; deve existir procedimento de recriptografia gradual e teste de rollback.”
• “Mensagens entre serviços A e B devem incluir proteção contra replay; testes devem simular reenvio e garantir rejeição/idempotência.”

Critérios de aceite conectam segurança ao ciclo de entrega: sem isso, a criptografia vira “intenção” e não implementação verificável.

Modelos de ameaça comuns e como eles mudam escolhas

Modelo 1: “Atacante na rede” (MITM e manipulação de tráfego)

Se você assume que o atacante pode observar e alterar tráfego, seus objetivos mínimos em trânsito são confidencialidade e integridade, além de autenticar o servidor (e às vezes o cliente). Decisões típicas:

• Garantir autenticação do endpoint e integridade do canal.
• Evitar “protocolos caseiros” para troca de chaves.
• Considerar autenticação mútua em comunicações internas sensíveis.

Requisito derivado: “Qualquer dado sensível em trânsito deve estar em canal autenticado; falhas de validação de certificado devem ser tratadas como erro.”

Modelo 2: “Banco de dados pode vazar” (exfiltração em repouso)

Se o banco pode ser copiado, criptografia em repouso passa a ser central. A pergunta vira: quem pode descriptografar? Se a ameaça inclui insiders com acesso ao banco, criptografia transparente do storage pode não ser suficiente, porque o serviço ainda consegue ler e um insider com acesso ao serviço pode abusar. Decisões típicas:

• Criptografia no nível da aplicação para campos sensíveis.
• Chaves gerenciadas separadamente e com políticas restritas.
• Separação de ambientes e de domínios de chave (por tipo de dado/tenant).

Requisito derivado: “Acesso ao dado em claro deve ser limitado a serviços específicos; consultas administrativas ao banco não devem revelar campos sensíveis.”

Modelo 3: “Cliente pode ser comprometido” (endpoint hostil)

Quando o endpoint é hostil, criptografia não impede que o atacante leia dados após a descriptografia no próprio dispositivo. O foco muda para reduzir o valor do que é roubado e limitar persistência:

• Tokens de curta duração e revogação.
• Segredos não persistidos quando possível; proteção de armazenamento local.
• Detecção de anomalias e step-up authentication.

Requisito derivado: “Credenciais de sessão devem expirar rapidamente e ser vinculadas a contexto; ações de alto risco exigem reautenticação.”

Modelo 4: “Servidor não é totalmente confiável” (redução de confiança no backend)

Se você assume que o servidor pode ser comprometido ou que operadores não devem ter acesso ao conteúdo, você pode precisar de criptografia ponta a ponta ou de arquitetura que mantenha chaves fora do servidor. Isso impacta busca, moderação, recuperação de conta e observabilidade. Decisões típicas:

• Chaves geradas e mantidas no cliente; servidor armazena apenas ciphertext.
• Troca de chaves e verificação de identidade entre usuários/dispositivos.
• Estratégias de backup de chaves e recuperação (com trade-offs).

Requisito derivado: “O servidor não deve ter acesso às chaves de conteúdo; deve armazenar apenas dados cifrados e metadados mínimos.”

Exemplos guiados: do objetivo ao requisito

Exemplo A — API de criação de transações

Fluxo: cliente envia valor, destinatario, idempotency_key; servidor valida e grava; serviço antifraude consulta.

Objetivos:

• Integridade: valor e destinatário não podem ser alterados em trânsito.
• Autenticidade: somente cliente autenticado pode criar transação.
• Anti-replay: reenvio não pode duplicar cobrança.

Ameaças:

• Atacante na rede tenta modificar destinatario.
• Atacante tenta repetir requisição capturada.

Requisitos derivados:

• “Requisições devem ser autenticadas e protegidas por canal com integridade; alterações no payload devem resultar em falha.”
• “Servidor deve implementar idempotência por idempotency_key com janela definida; reenvios devem retornar o mesmo resultado sem duplicar efeitos.”

Exemplo B — Armazenamento de documento sensível

Fluxo: usuário envia documento; backend processa; armazena em objeto; grava metadados no banco; equipe de suporte acessa metadados.

Objetivos:

• Confidencialidade em repouso: documento não pode ser lido por quem só tem acesso ao storage/banco.
• Segregação: suporte não deve ler conteúdo, apenas status.

Ameaças:

• Snapshot do storage exposto.
• Insider com acesso ao banco e ao painel de suporte.

Requisitos derivados:

• “Documento deve ser armazenado cifrado; chaves devem ser separadas do storage e acessíveis apenas ao serviço de processamento.”
• “Painel de suporte deve operar apenas com metadados; não deve haver endpoint que retorne o documento em claro para perfis de suporte.”

Checklist operacional: perguntas que evitam decisões criptográficas erradas

• Qual é o objetivo principal: confidencialidade, integridade, autenticidade, não repúdio, disponibilidade?
• O que acontece se o banco vazar? E se logs vazarem? E se backups vazarem?
• Quem precisa ler o dado em claro? Onde isso acontece?
• Quais fronteiras de confiança existem no fluxo?
• O adversário pode modificar mensagens (não apenas observar)?
• Há risco de replay? Há operações não idempotentes?
• Como chaves são geradas, armazenadas, rotacionadas e revogadas?
• O que quebra se uma chave for perdida? Existe plano de recuperação?
• Quais requisitos são testáveis automaticamente (CI) e quais exigem auditoria/processo?

Template prático (preenchível) de mini modelo de ameaça

Use este template para documentar rapidamente um fluxo e derivar decisões criptográficas.

Fluxo: [nome do fluxo]  Versão: [data/commit]  Dono: [time]  Escopo: [componentes incluídos/excluídos]  Suposições: [ex.: servidor confiável? cliente confiável?]  Ativos: - [ativo 1] (sensibilidade: alta/média/baixa) - [ativo 2] ...  Fronteiras de confiança: - [cliente → backend] - [backend → banco] - [backend → serviço X]  Adversários relevantes: - [perfil] capacidades: [listar] - [perfil] capacidades: [listar]  Ameaças prioritárias (top 5): 1) [ameaça] impacto: [alto/médio/baixo] 2) ...  Objetivos por ativo: - [ativo] em trânsito: [C/I/A] em repouso: [C/I] em uso: [limitações]  Controles/decisões: - [controle] cobre ameaças: [1,3] - [controle] ...  Requisitos testáveis: - [requisito] validação: [teste/monitoramento/auditoria] - [requisito] ...