Blast Radius Review: conter o incidente antes que ele se espalhe
Índice
- O risco também depende do alcance
- Como executar a revisão
- Priorizando o que reduzir primeiro
- Agentes de IA tornam as capacidades parte do perímetro
- Onde a revisão entra no Secure SDLC
- Uma versão de 30 minutos
- Limitações
- Referências
Uma análise de segurança costuma começar pela possibilidade de uma aplicação, credencial ou dependência ser comprometida. A Blast Radius Review acrescenta outra pergunta à revisão arquitetural:
Se este componente for completamente comprometido, até onde o problema consegue chegar?
A pergunta não substitui prevenção, correção de vulnerabilidades ou detecção. Ela expõe uma dimensão diferente do risco: o alcance que a arquitetura concede a um componente depois da primeira falha.
Neste documento, Blast Radius Review é o nome operacional de uma prática proposta. Não se trata de um padrão formal. A prática aplica uma hipótese de comprometimento para percorrer identidades, dados, conexões e ações, localizar o próximo salto possível e decidir onde a arquitetura precisa de uma barreira.
O risco também depende do alcance
Considere duas APIs com a mesma vulnerabilidade. A primeira consulta uma tabela com uma identidade somente de leitura. A segunda usa uma conta administrativa, alcança serviços internos e mantém uma credencial compartilhada com o pipeline de implantação.
A vulnerabilidade pode ser igual, mas os incidentes possíveis são diferentes. Para estimar o alcance, é necessário observar pelo menos:
- as identidades disponíveis ao componente;
- os dados que essas identidades podem ler, alterar ou excluir;
- os sistemas alcançáveis pela rede e pelas integrações;
- as ações destrutivas, irreversíveis ou externamente visíveis;
- as credenciais e relações de confiança que permitem um próximo salto.
Essa leitura é compatível com princípios de zero trust. A arquitetura descrita no NIST SP 800-207 não concede confiança implícita a uma conta ou ativo apenas por sua localização na rede ou por pertencer à organização. Para uma Blast Radius Review, isso significa não tratar a rede interna, uma service account ou um serviço conhecido como uma barreira suficiente por si só.
Como executar a revisão
1. Escolha um componente e uma fronteira
Comece por um componente exposto, privilegiado ou difícil de recuperar: uma aplicação web, API, worker, pipeline, serviço de identidade, automação ou agente de IA.
Defina também a fronteira da análise. Em um sistema menor, ela pode cobrir toda a arquitetura. Em uma plataforma extensa, pode ser mais útil revisar um fluxo crítico, um domínio ou um ambiente por vez.
O diagrama usado deve representar o estado implantado, não apenas a arquitetura pretendida. Uma conexão esquecida ou uma permissão temporária que permaneceu em produção faz parte do raio real.
2. Assuma o comprometimento
Durante a revisão, aceite a hipótese:
O atacante controla o componente e pode usar tudo o que está disponível para ele.
Não é necessário decidir nesse momento se a entrada seria uma injeção de SQL, execução remota de código, dependência comprometida, roubo de credencial, prompt injection ou erro operacional. A técnica de entrada volta a importar em outras análises. Aqui, o objetivo é descobrir o que acontece depois.
3. Levante as capacidades efetivas
Registre capacidades verificáveis, não descrições genéricas como “acessa o banco” ou “integra com o storage”. Para cada relação, detalhe:
| Dimensão | Pergunta | Evidência útil |
|---|---|---|
| Identidade | Quais tokens, chaves, certificados, papéis e service accounts ficam disponíveis? | Configuração de workload, cofre de secrets, política IAM, conteúdo efetivo do token |
| Dados | Quais registros, tenants, arquivos, backups e logs podem ser lidos ou alterados? | Grants do banco, políticas por linha, políticas do bucket, teste com a identidade real |
| Alcance | Quais destinos aceitam conexão a partir desse componente? | Política de rede, regras de firewall, rotas, teste de conectividade |
| Ações | O que pode ser criado, enviado, aprovado, modificado ou excluído? | Escopos da API, papéis, allowlists, teste de autorização |
| Próximo salto | Qual acesso obtido aqui permite comprometer outro sistema? | Credencial compartilhada, impersonação, API administrativa, caminho para secrets |
Configuração declarada é um ponto de partida. Quando o risco for relevante, a evidência deve incluir um teste de permissão permitida e outro de permissão negada.
4. Siga cada próximo salto
O caminho não termina no primeiro banco ou serviço alcançado. Pergunte o que o atacante obtém ali e repita a análise até encontrar uma barreira verificável ou chegar ao limite definido para a revisão.
flowchart LR
internet["Internet"] --> app["Web App comprometida"]
app --> db["Banco: leitura e escrita amplas"]
app --> storage["Storage: acesso a todo o bucket"]
app --> api["API interna"]
api --> token["Token administrativo compartilhado"]
token --> admin["Serviços administrativos"]
Nesse exemplo, corrigir uma vulnerabilidade na Web App continua necessário, mas não resolve o privilégio amplo nem a credencial compartilhada. A revisão torna visível que uma única entrada pode alcançar serviços administrativos.
5. Registre barreiras, lacunas e decisões
Para cada caminho, classifique o que interrompe ou reduz a propagação:
- identidade exclusiva e com escopo mínimo;
- separação entre leitura, escrita e administração;
- isolamento por tenant ou por conjunto de dados;
- segmentação de rede com negação por padrão;
- credenciais curtas e não compartilhadas;
- aprovação independente para ações irreversíveis;
- limites de volume, custo, frequência ou duração;
- logs e alertas que permitam detectar e conter o uso indevido;
- recuperação testada para o recurso afetado.
Uma barreira não deve ser registrada como eficaz apenas porque existe no diagrama. A revisão precisa indicar como ela foi ou será validada.
Priorizando o que reduzir primeiro
Nem todo caminho encontrado exige a mesma resposta. Uma priorização prática pode considerar:
- quantidade e sensibilidade dos dados expostos;
- possibilidade de alteração, exclusão ou ação externa;
- número e criticidade dos próximos saltos;
- capacidade de detectar o abuso durante sua execução;
- tempo e evidência necessários para conter e recuperar;
- custo e impacto operacional da barreira proposta.
Credenciais compartilhadas, acesso administrativo desnecessário e caminhos que atravessam ambientes diferentes merecem atenção porque dificultam atribuição, revogação e contenção. A correção, porém, precisa respeitar o contexto. Dividir uma identidade pode aumentar a carga operacional; segmentar a rede pode quebrar fluxos pouco documentados; exigir aprovação humana em toda ação pode tornar o sistema inutilizável.
A decisão deve registrar qual incidente possível será reduzido, como o controle será testado e qual risco continuará aceito.
Agentes de IA tornam as capacidades parte do perímetro
Um agente pode receber acesso a documentos, e-mail, CRM, navegador, banco de dados e APIs internas para completar uma tarefa. O valor operacional vem dessas capacidades; o risco também.
A OWASP AI Agent Security Cheat Sheet recomenda conceder apenas as ferramentas necessárias, separar leitura de escrita, limitar recursos acessíveis e exigir autorização explícita para ações sensíveis. Ela também orienta tratar documentos, páginas, e-mails e respostas de APIs como entradas não confiáveis.
Em uma Blast Radius Review de um agente, não basta revisar o prompt. É preciso examinar os controles aplicados fora do modelo:
- o agente que consulta pedidos também pode cancelar ou reembolsar?
- a ferramenta de banco conecta com uma identidade mais privilegiada que a operação pretendida?
- um documento recuperado pode induzir uma chamada de ferramenta com efeito externo?
- a aprovação está vinculada à ação e aos parâmetros que serão executados?
- memória e contexto estão isolados entre usuários e tenants?
- uma falha em um agente pode delegar trabalho ou credenciais a outro?
Prompt injection é uma forma possível de iniciar o abuso, mas o tamanho do incidente depende das capacidades que continuarem disponíveis. Instruções no prompt podem orientar o comportamento; não devem ser o único mecanismo de autorização.
Onde a revisão entra no Secure SDLC
O Secure Software Development Framework do NIST recomenda integrar práticas de segurança ao SDLC e usar modelagem de risco durante o design. A Blast Radius Review pode funcionar como uma análise complementar dentro dessa etapa:
flowchart LR
req["Requisitos e dados"] --> arch["Arquitetura e threat modeling"]
arch --> blast["Blast Radius Review"]
blast --> controls["Controles e decisões"]
controls --> tests["Testes de permissão e contenção"]
tests --> deploy["Deploy"]
deploy --> observe["Observação e nova revisão"]
Além da primeira revisão de arquitetura, vale repeti-la quando houver:
- nova integração, identidade, ferramenta ou fonte de dados;
- mudança de escopos, papéis ou políticas de rede;
- inclusão de uma ação irreversível;
- alteração relevante em um agente, sua memória ou suas ferramentas;
- incidente que revele um caminho não modelado;
- divergência entre o diagrama e o ambiente implantado.
O resultado mínimo é um conjunto de caminhos de propagação, as barreiras já validadas, as lacunas priorizadas, seus responsáveis e a data de revisão. Sem esses artefatos, a conversa pode ser útil, mas será difícil verificar se o raio foi reduzido depois.
Uma versão de 30 minutos
Para uma primeira aplicação, reúna o diagrama atual e escolha um componente crítico. Diante dele, responda:
- Quais credenciais e identidades ele possui?
- Quais dados consegue ler, alterar ou excluir?
- Quais sistemas consegue alcançar?
- Quais ações destrutivas, irreversíveis ou externas consegue executar?
- Qual é o próximo sistema que poderia ser comprometido a partir dele?
- Qual evidência demonstra que cada barreira realmente interrompe o caminho?
Se a análise atravessar vários sistemas sem encontrar uma negação de acesso, uma identidade separada, uma aprovação independente ou outro limite testável, ela encontrou um candidato concreto para redução de risco.
Limitações
Blast Radius Review não identifica todas as formas de entrada, não calcula a probabilidade de exploração e não prova que um sistema é seguro. Ela não substitui threat modeling, revisão de código, análise de dependências, testes de segurança, observabilidade, resposta a incidentes ou recuperação de desastre.
O resultado também perde validade quando inventários, diagramas e políticas não representam a implantação real. A prática é mais útil como revisão repetível de contenção do que como checklist executado uma única vez.
Referências
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Zero Trust Architecture. NIST SP 800-207, 2020. Disponível em: https://csrc.nist.gov/pubs/sp/800/207/final.
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Secure Software Development Framework (SSDF) Version 1.1. NIST SP 800-218, 2022. Disponível em: https://csrc.nist.gov/pubs/sp/800/218/final.
OWASP FOUNDATION. AI Agent Security Cheat Sheet. Disponível em: https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html.