Os dois primeiros artigos desta série explicaram por que as instituições de criptoativos precisam de testes de penetração em blockchain (Parte 1) e o que é essa disciplina (Parte 2). Este artigo trata de como um engajamento institucional é preparado e conduzido com segurança: as regras de engajamento, as salvaguardas de segurança em produção, e a remediação e o reteste que transformam descobertas em correções — o ciclo de vida do engajamento mostrado abaixo.
A Web3 eleva os riscos dos testes em produção de uma maneira específica: as ações on-chain costumam ser irreversíveis, a atividade de teste é frequentemente visível publicamente on-chain, e os sistemas dentro do escopo podem movimentar fundos reais. As salvaguardas abaixo, portanto, dão mais peso à escolha do ambiente, aos limites de valor, ao manuseio de chaves e à reconciliação do que um engajamento convencional.
RoE como a autoridade operacional
De acordo com o National Institute of Standards and Technology (NIST) dos EUA, o RoE estabelece as diretrizes e restrições para testes de segurança [1]. Para um engajamento institucional, ele transforma a decisão de testar em um mandato autorizado: um objetivo definido, um escopo definido e uma autoridade nomeada para agir.
Esse mandato é importante porque uma equipe de teste não pode inferir autoridade com segurança a partir de um contrato ou lista de ativos. Sem uma decisão compartilhada sobre o risco a ser avaliado, os sistemas envolvidos e as pessoas responsáveis por eles, a equipe pode testar o caminho errado, excluir uma dependência crítica ou não ter autoridade para validar uma descoberta relevante.
O ponto de partida é a decisão de negócio que o teste pretende apoiar. Um objetivo pode dizer respeito à exposição pública antes do lançamento. Pode focar na autorização de clientes e da interface de programação de aplicações (API), ou na acessibilidade de sistemas privilegiados em nuvem e operacionais. Pode também testar um fluxo de assinatura ou saque, ou avaliar uma integração de terceiros. Esse objetivo identifica os sistemas que importam, o risco a ser reduzido e o resultado que a gestão precisa para tomar uma decisão.
O objetivo deve se traduzir em um escopo que siga o modelo operacional. Em uma instituição de criptoativos, isso comumente inclui serviços web, mobile e de interface de programação de aplicações (API) voltados ao cliente; contas em nuvem e gerenciamento de identidade e acesso (IAM); sistemas e segredos de integração contínua e entrega contínua (CI/CD); consoles operacionais; wallets e fluxos de aprovação; sistemas de assinatura; serviços de ledger e saque; e os fornecedores que os conectam. Juntos, esses componentes regem como clientes e equipes internas iniciam, aprovam, assinam, liberam e reconciliam ações relacionadas a fundos. A instituição e a equipe de teste também devem concordar sobre a perspectiva relevante: um atacante externo, um usuário comum, um parceiro, um funcionário com baixo privilégio ou uma identidade presumidamente comprometida.
Cada sistema, conta, interface e atividade dentro do escopo deve ter um responsável nomeado e um caminho de autorização claro. O mesmo se aplica a dependências de terceiros, incluindo provedores de custódia, interfaces de wallet, provedores de remote procedure call (RPC), plataformas de software como serviço (SaaS), provedores de identidade, hospedeiros de código e serviços gerenciados. Testar um ambiente de propriedade de um provedor requer a permissão por escrito desse provedor; a autorização da instituição sozinha pode não autorizar atividade contra os sistemas do provedor.
Juntos, o objetivo, o escopo e o caminho de autorização estabelecem o que a equipe pode avaliar. A próxima etapa registra como a equipe pode realizar essa avaliação.
Limites operacionais
Os limites operacionais são as restrições escritas que regem a execução após o mandato ser acordado. Eles distinguem o que está dentro do escopo do que é permitido: um serviço de saque em produção pode estar dentro do escopo para validação do caminho de autorização, enquanto saques reais de clientes, extração de chave privada, mudanças de persistência e ataques geradores de carga permanecem proibidos.
Essa distinção evita que a incerteza se transforme em risco operacional. Durante um engajamento em produção, a instituição e a equipe de teste precisam saber com antecedência quais técnicas são permitidas, quando a atividade deve parar, quem pode tomar essa decisão e como as evidências podem ser tratadas. Caso contrário, mesmo um teste autorizado pode criar impacto evitável em serviços ou clientes.
O RoE deve registrar essas decisões antes do início dos testes. Além disso, o documento deve ser preciso o suficiente para que ambas as partes possam agir sem reabrir questões fundamentais durante o engajamento.
A tabela abaixo traduz o mandato de teste estabelecido acima em um registro prático de RoE. Ela agrupa as decisões que devem ser definidas antes do teste: o que está sendo avaliado, quem está autorizado, quais atividades e limites se aplicam, como as partes se coordenam e como as evidências são tratadas. Não é uma lista de verificação genérica para copiar sem alterações; os valores registrados devem refletir o modelo operacional da instituição, a perspectiva do teste e o risco de produção.
| Tópico do RoE | Decisão a registrar antes do teste |
|---|---|
| Objetivo e escopo | A decisão de negócio, os sistemas e interfaces dentro do escopo, os responsáveis e as perspectivas de atacante a serem testadas. |
| Autorização | Autoridade por escrito, identidades de teste, caminhos de acesso aprovados e aprovações de provedores para ambientes de terceiros. |
| Método de teste e conclusão | Técnicas permitidas e o ponto em que a equipe deve parar, como acesso demonstrado, escalonamento de privilégios ou uma simulação controlada de fluxo de trabalho. |
| Limites operacionais | Janelas de teste, limites de taxa de requisições e concorrência, limites de operação de conta, limites de acesso a dados, períodos de congelamento de mudanças e, quando um cenário aprovado usar uma transação, a rede permitida, os endereços de teste, os tipos de transação, o valor máximo de teste e o orçamento de gas. |
| Atividade proibida | Exemplos incluem testes de negação de serviço, engenharia social, movimentações reais de ativos de clientes, exportação de chave privada, persistência ou mudanças de produção não aprovadas. |
| Fluxos de trabalho sensíveis | Wallets e contas designadas, destinos em lista de permissão, valor máximo de teste, participantes da aprovação, comportamento de política esperado, etapas de reconciliação e o ponto mais avançado na cadeia de controle de transação que a validação pode alcançar. |
| Comunicações e pausa | Modelo de aviso de rotina, canal de segurança protegido, contatos de escalonamento, limiar de descoberta relevante, autoridade nomeada para pausar ou retomar o teste, e a observabilidade e o tratamento de alertas esperados para uma transmissão pública de transação aprovada. |
| Tratamento de evidências | Evidência mínima necessária, minimização e redação de dados, criptografia, destinatários aprovados, período de retenção, confirmação de destruição e hash de transação e metadados de rede vinculados à aprovação interna e à evidência de ledger para uma transação de teste aprovada. |
Com os limites de execução acordados, a instituição pode preparar os sistemas implantados e as condições operacionais que o teste encontrará.
Ambiente operacional e proteção de serviços ativos
O ambiente operacional é o sistema implantado e a atividade de negócio ao seu redor: limites de confiança, fluxos de fundos, dependências de serviço, fluxos de trabalho operacionais e as pessoas responsáveis por cada componente. É o contexto no qual uma descoberta de teste adquire seu real significado.
Esse contexto é importante porque a mesma fragilidade técnica pode ter consequências muito diferentes. Um problema de API, uma permissão em nuvem ou uma fragilidade no fluxo de aprovação pode afetar dados de clientes, operações internas, autoridade de assinatura, alterações de saldo ou saques. Para uma exchange, empresa de pagamentos, custodiante ou provedor de wallet em operação, o teste também deve coexistir com operações de negociação, pagamento, depósito, saque, liquidação e suporte.
Uma visão atualizada deve cobrir o inventário de ativos e serviços, a arquitetura e os pontos de integração, o modelo de nuvem e identidade, os fluxos de trabalho operacionais e as dependências de terceiros. O planejamento também deve identificar janelas de negócio relevantes, lançamentos planejados, congelamentos de mudanças, períodos de alto volume, atividade de hot wallet e outros eventos operacionais. Os sinais de saúde do serviço observados durante o teste devem incluir volumes de transações e de API, tempos de resposta, taxas de erro, profundidade de fila, saúde do serviço de assinatura e disponibilidade do serviço de wallet. O ambiente operacional inclui os serviços de produção, as identidades, os fluxos de trabalho operacionais e as dependências externas usadas para iniciar e controlar transações. O RoE registra o ambiente de teste aprovado, as identidades de teste, as etapas permitidas dentro de um fluxo de assinatura ou saque, e as salvaguardas que se aplicam a qualquer cenário de validação controlado. Esses parâmetros mantêm a avaliação focada nos controles da instituição, ao mesmo tempo em que protegem a atividade normal de clientes e operações.
O Digital Operational Resilience Act (DORA) da União Europeia oferece um ponto de referência útil em um contexto de alta regulação. Para entidades financeiras selecionadas para testes de penetração orientados a ameaças, o Artigo 26 exige que o teste cubra funções críticas ou importantes e seja realizado nos sistemas de produção que as sustentam, incluindo serviços relevantes de tecnologia da informação e comunicação (TIC) terceirizados [2]. Isso não é uma autorização geral para testes em produção; cada instituição ainda precisa de sua própria autoridade, salvaguardas e aprovações legais e contratuais aplicáveis.
Essa base de produção permite que a instituição aplique salvaguardas mais específicas aos fluxos de trabalho que podem afetar diretamente fundos ou o acesso de clientes.
Limites para fluxos de trabalho sensíveis
Fluxos de trabalho sensíveis são os sistemas e ações cuja operação normal pode afetar diretamente fundos, o acesso de clientes ou a integridade dos registros. Eles incluem fluxos de assinatura e saque, acesso privilegiado em produção, tratamento de dados de clientes e operações de ledger.
Esses fluxos de trabalho precisam de limites mais rígidos porque um teste realista pode, do contrário, passar de validar um controle para alterar um resultado de cliente ou financeiro. O risco não é apenas de interrupção técnica: pode incluir movimentação não autorizada de fundos, saldos incorretos, exposição de dados sensíveis ou confusão entre a atividade de teste e um incidente real. Onde uma falha de controle pode afetar fundos, a reversão pode ser difícil ou impossível, portanto esses limites devem impedir que um teste produza qualquer movimentação de fundos não intencional ou não autorizada.
Os fluxos de assinatura e saque exigem cenários controlados que validem como a instituição autentica uma solicitação, aplica política, roteia aprovações e reconcilia o resultado. O RoE identifica contas de teste designadas, participantes autorizados, comportamento de política esperado, um limite superior para o cenário e a evidência necessária para validar o fluxo de trabalho. Em seguida, registra a etapa de fluxo de trabalho mais avançada permitida: criação da solicitação, decisão de política, exibição de aprovação, solicitação de assinatura, decisão de liberação ou reconciliação. As identidades de teste são provisionadas, usadas e retiradas por meio do processo de acesso acordado. A mesma disciplina se aplica ao acesso privilegiado, aos dados de clientes e às operações de ledger: o modelo de acesso, o comportamento esperado do sistema e o limite de evidência são acordados antes do início do teste; os dados de clientes são acessados apenas quando necessário, minimizados e redigidos nas evidências, e mantidos dentro do repositório de evidências aprovado.
Esses controles tornam possível testar caminhos sensíveis em produção sem tratá-los como funções comuns de aplicação. Eles também dão à equipe de operações e à equipe de teste uma base comum para coordenar a atividade ao vivo.
Testes e coordenação
Testes e coordenação são o modelo operacional ao vivo para o engajamento. Eles conectam o responsável pelo serviço, a equipe de operações de segurança, a função de resposta a incidentes e o líder do teste enquanto o teste está em andamento.
Esse modelo é necessário porque a atividade de teste esperada e um evento de segurança genuíno podem parecer semelhantes. Se o monitoramento, as notificações ou as decisões de pausa não forem claras, os testes podem atrasar a resposta a incidentes ou criar incerteza sobre se uma ação de produção é necessária.
O modelo de comunicações identifica quem conhece o plano de teste completo, quem recebe avisos sensíveis ao tempo e quem pode pausar ou retomar a atividade. Ele varia de acordo com o objetivo: alguns testes exigem coordenação estreita com o centro de operações de segurança (SOC) em torno de sistemas sensíveis, enquanto testes de divulgação limitada avaliam se o monitoramento detecta a atividade e se o escalonamento chega às pessoas certas. Quando um cenário controlado exercita um fluxo de trabalho relacionado a transações, o plano também cobre notificações relevantes e alertas esperados de provedores de custódia, wallet, triagem de transações e monitoramento. Um contato de segurança separado e uma autoridade nomeada para pausar permanecem acessíveis a todo momento. O responsável pelo serviço e a equipe de teste acordam critérios de parada mensuráveis, como desvio do orçamento de erro, aumentos inesperados no tempo de resposta do percentil 95 (p95) ou na profundidade de fila, atividade suspeita de conta ou wallet, discrepâncias materiais de reconciliação, ou um alerta de segurança não planejado.
Essa preparação também fortalece a resiliência operacional. A Hong Kong Securities and Futures Commission (SFC) espera que os operadores de plataformas de negociação de ativos virtuais mantenham monitoramento 24/7 e procedimentos de escalonamento documentados, e conduzam simulações de emergência e continuidade de negócios com terceiros relevantes [3]. Essas referências regulatórias são ilustrativas, não constituem aconselhamento jurídico; a aplicabilidade é específica de cada jurisdição e deve ser confirmada com assessoria jurídica.
O diagrama mostra o ciclo de controle que se aplica enquanto o teste está em andamento. Seu ponto central é que os limites do RoE não terminam na autorização: o monitoramento e o canal de segurança transformam esses limites em decisões de retomar, pausar, conter ou encaminhar uma descoberta verificada para remediação. Ele aparece aqui porque essas decisões pertencem à coordenação ao vivo, e não à definição anterior de escopo ou à preparação de produção.
O mesmo modelo rege as descobertas críticas: um caminho demonstrado para movimentação não autorizada de fundos, comprometimento da autoridade de assinatura ou de um plano de controle de produção, exposição de dados de clientes altamente sensíveis, ou risco material para um serviço crítico. O caminho de resposta deve identificar o limiar de escalonamento, as pessoas que classificam a descoberta, a autoridade para pausar a atividade relevante e o processo de contenção, remediação e validação. A equipe de teste de penetração demonstra e relata o problema; a instituição mantém a autoridade para decisões de produção, comunicações com clientes e remediação. Uma notificação de descoberta relevante deve usar primeiro o canal de segurança protegido, seguida por um registro escrito acordado que não exponha detalhes desnecessários de exploração.
Uma vez que uma descoberta é contida e atribuída, o valor do engajamento depende de a instituição conseguir transformar esse resultado em uma melhoria de controle validada.
Remediação, reteste e retorno à normalidade
Remediação e reteste são o processo de encerramento que converte uma fragilidade demonstrada em uma melhoria validada. O retorno à normalidade faz parte do mesmo processo: o acesso de teste, os cenários controlados e as evidências coletadas não devem se tornar novos riscos de longa duração.
Essa etapa final determina se o engajamento reduz o risco ou apenas produz um relatório. Uma descoberta sem responsável, caminho de remediação e condição de validação pode permanecer aberta enquanto o mesmo caminho de ataque persiste em produção.
Antes do início dos testes, identifique como as descobertas entram nos fluxos de trabalho de engenharia, nuvem, operações de wallet ou controle de negócios; quem é o responsável pela remediação; e quais descobertas exigem reteste. No encerramento, as identidades de teste temporárias, permissões e cenários controlados retornam à sua configuração pretendida, e os responsáveis pelo serviço confirmam que os indicadores de saúde relevantes permanecem dentro da faixa esperada. O registro final vincula cada descoberta à sua evidência, impacto, responsável, plano de remediação e condição de reteste. Para um cenário controlado relacionado a transações, ele também vincula a referência do fluxo de trabalho, a identidade de teste, o carimbo de data/hora, o registro de aprovação e a entrada resultante no ledger; qualquer acesso, aprovação ou configuração de teste temporária criada para o cenário é retirada. As evidências são retidas apenas pelo período acordado, e então destruídas ou devolvidas com segurança.
O resultado não é uma lista de vulnerabilidades, mas um conjunto de controles testado, remediado e retestado que pode apoiar a próxima decisão operacional da instituição.
Conclusão
Preparar-se para o teste de penetração em blockchain é uma tarefa institucional. A instituição define o objetivo, o contexto operacional, a autoridade, as restrições de serviço e o modelo de resposta; a equipe de teste aplica validação adversarial a esse ambiente preparado.
Com esses elementos em vigor, um engajamento de teste de penetração se torna mais do que um exercício técnico. Torna-se uma forma controlada de entender como os sistemas implantados, as pessoas e os processos da instituição se sustentam sob ataque.
A BlockSec ajuda instituições a preparar e conduzir esse processo: definir o escopo, mapear o ambiente operacional, estabelecer o RoE e as salvaguardas de produção, e transformar descobertas em controles remediados e retestados. Para planejar as regras de engajamento e os controles de segurança de produção para o seu próximo teste, solicite uma conversa de definição de escopo; mais informações estão disponíveis mediante solicitação.
Continue com a série:
Também nesta série, publicação em breve:
- Parte 5: Segurança de Autorização e Assinatura: Web, dApps, e
- Parte 6: Segurança de Nuvem e CI/CD: Superfícies de Ataque de Operações Automatizadas
- Parte 7: Segurança do Plano de Controle de Tesouraria: Aprovações de Assinatura e Saque
- Parte 8: Segurança do Ledger de Exchange: Caminhos de Roubo e Lógica do Plano de Dados
A página principal sobre Teste de Penetração em Blockchain oferece a visão em nível de engajamento.
Referências
Numeradas na ordem da primeira aparição.
- National Institute of Standards and Technology, Rules of Engagement (ROE), CSRC Glossary.
- União Europeia, Regulamento (UE) 2022/2554 — Digital Operational Resilience Act (DORA), Artigo 26.
- Hong Kong Securities and Futures Commission, Circular to Licensed Virtual Asset Trading Platform Operators on Custody of Virtual Assets (15 de agosto de 2025).
