Regras de Engajamento e Segurança em Produção para Testes de Invasão em Blockchain Institucional

Os dois primeiros artigos desta série explicaram por que as instituições de criptomoedas precisam de testes de penetração em blockchain (Parte 1) e o que é essa disciplina (Parte 2). Este artigo aborda como um engajamento institucional é preparado e executado 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 a seguir.

A Web3 eleva os riscos dos testes em produção de uma maneira específica: as ações on-chain são normalmente irreversíveis, a atividade de teste costuma ser publicamente visível on-chain, e os sistemas em escopo podem movimentar fundos reais. Por isso, as salvaguardas abaixo dão mais peso à escolha do ambiente, aos limites de valor, ao tratamento de chaves e à reconciliação do que um engajamento convencional.

RoE como autoridade operacional

Segundo o National Institute of Standards and Technology (NIST) dos EUA, o RoE estabelece as diretrizes e restrições para testes de segurança [1]. Em um engajamento institucional, ele transforma uma decisão de testar em um mandato autorizado: um objetivo definido, um escopo definido e uma autoridade nomeada para agir.

Esse mandato importa porque uma equipe de teste não pode inferir com segurança sua autoridade a partir de um contrato ou de uma 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 de interfaces de programação de aplicações (API), ou na acessibilidade de sistemas privilegiados de nuvem e operacionais. Também pode testar um fluxo de assinatura ou retirada, ou avaliar uma integração com terceiros. Esse objetivo identifica os sistemas relevantes, o risco a ser reduzido e o resultado de 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 criptomoedas, isso geralmente inclui serviços web, mobile e de interface de programação de aplicações (API) voltados ao cliente; contas de nuvem e gerenciamento de identidade e acesso (IAM); sistemas e segredos de integração contínua e entrega contínua (CI/CD); consoles operacionais; carteiras e fluxos de aprovação; sistemas de assinatura; serviços de ledger e retirada; e os fornecedores que os conectam. Juntos, esses componentes governam 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 acordar a perspectiva relevante: um atacante externo, um usuário normal, um parceiro, um funcionário com baixo privilégio, ou uma identidade presumidamente comprometida.

Cada sistema, conta, interface e atividade em escopo deve ter um proprietário nomeado e um caminho de autorização claro. O mesmo se aplica a dependências de terceiros, incluindo provedores de custódia, interfaces de carteira, provedores de chamada de procedimento remoto (RPC), plataformas de software como serviço (SaaS), provedores de identidade, hospedagens 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 por si só 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á em escopo do que a atividade é permitida: um serviço de retirada em produção pode estar em escopo para validação do caminho de autorização, enquanto retiradas reais de clientes, extração de chave privada, alterações 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 ser interrompida, quem pode tomar essa decisão e como as evidências podem ser tratadas. Caso contrário, mesmo um teste autorizado pode causar impacto evitável em serviços ou clientes.

O RoE deve registrar essas decisões antes do início do teste. 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 resolvidas 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 ser copiada sem alterações; os valores registrados devem refletir o modelo operacional da instituição, a perspectiva do teste e o risco em produção.

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 do serviço em produção

O ambiente operacional é o sistema implantado e a atividade de negócio em torno dele: 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 importa porque a mesma fragilidade técnica pode ter consequências muito diferentes. Um problema de API, uma permissão de nuvem ou uma fragilidade no fluxo de aprovação podem afetar dados de clientes, operações internas, autoridade de assinatura, alterações de saldo ou retiradas. Para uma corretora, empresa de pagamentos, custodiante ou provedor de carteira em operação, o teste também precisa coexistir com operações de negociação, pagamento, depósito, retirada, liquidação e suporte.

Uma visão atual deve abranger 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 carteira. 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 retirada, e as salvaguardas que se aplicam a qualquer cenário de validação controlada. 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 ambiente de alta regulação. Para entidades financeiras selecionadas para testes de penetração orientados por 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 suportam, incluindo serviços terceirizados relevantes de tecnologia da informação e comunicação (TIC) [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 referência 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 retirada, acesso privilegiado à produção, tratamento de dados de clientes e operações de ledger.

Esses fluxos de trabalho precisam de limites mais estritos porque, do contrário, um teste realista pode passar de validar um controle para alterar um resultado de cliente ou financeiro. O risco não é apenas disrupçã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. Quando 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 retirada exigem cenários controlados que validem como a instituição autentica uma solicitação, aplica a política, encaminha aprovações e reconcilia o resultado. O RoE identifica contas de teste designadas, participantes autorizados, o comportamento esperado da política, um limite superior para o cenário e as evidências necessárias para validar o fluxo de trabalho. Em seguida, registra a etapa mais avançada permitida no fluxo de trabalho: 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 desativadas 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 às operações e à equipe de teste uma base comum para coordenar a atividade em tempo real.

Teste e coordenação

Teste e coordenação são o modelo operacional em tempo real do engajamento. Eles conectam o proprietário do 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 se parecer. Se o monitoramento, as notificações ou as decisões de pausa não estiverem claras, o teste pode atrasar a resposta a incidentes ou criar incerteza sobre a necessidade de ação em produção.

O modelo de comunicação 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 alcança as pessoas certas. Quando um cenário controlado exercita um fluxo de trabalho relacionado a transações, o plano também abrange notificações relevantes e alertas esperados de provedores de custódia, carteira, triagem de transações e monitoramento. Um contato de segurança separado e uma autoridade nomeada para pausa permanecem acessíveis em todos os momentos. O proprietário do 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 da fila, atividade suspeita de conta ou carteira, discrepâncias relevantes de reconciliação, ou um alerta de segurança não planejado.

Essa preparação também fortalece a resiliência operacional. A Securities and Futures Commission (SFC) de Hong Kong espera que os operadores de plataformas de negociação de ativos virtuais mantenham monitoramento 24/7 e procedimentos de escalonamento documentados, e realizem 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 em tempo real, e não à definição anterior do escopo ou à preparação da produção.

O mesmo modelo governa 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 relevante para um serviço crítico. O caminho de resposta deve identificar o limite 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 sobre 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 de um registro escrito acordado que não exponha detalhes de exploração desnecessários.

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 verificada.

Remediação, reteste e retorno à normalidade

A remediação e o 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 um novo risco de longa duração.

Essa etapa final determina se o engajamento reduz o risco ou apenas produz um relatório. Uma descoberta sem proprietário, 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 do teste, é preciso identificar como as descobertas entram nos fluxos de trabalho de engenharia, nuvem, operações de carteira ou controle de negócio; quem é responsável pela remediação; e quais descobertas exigem reteste. No encerramento, identidades de teste temporárias, permissões e cenários controlados retornam à sua configuração pretendida, e os proprietários dos serviços confirmam que os indicadores de saúde relevantes permanecem dentro da faixa esperada. O registro final vincula cada descoberta à sua evidência, impacto, proprietário, 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 timestamp, o registro de aprovação e o lançamento resultante no ledger; qualquer acesso temporário, aprovação ou configuração de teste criada para o cenário é desativada. As evidências são retidas apenas pelo período acordado, e então destruídas com segurança ou devolvidas.

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. Ele se torna uma maneira controlada de entender como os sistemas implantados, as pessoas e os processos da instituição resistem a ataques.

A BlockSec ajuda instituições a preparar e executar 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 seu próximo teste, solicite uma conversa de escopo; mais informações estão disponíveis sob solicitação.

Continue com a série:

• Parte 4: Superfícies de Ataque na Web3: Uma Visão Geral do Teste de Penetração

Também nesta série, publicação em breve:

• Parte 5: Segurança de Autorização e Assinatura: Web, dApps e Mobile
• Parte 6: Segurança de Nuvem e CI/CD: Superfícies de Ataque em Operações Automatizadas
• Parte 7: Segurança do Plano de Controle de Tesouraria: Aprovações de Assinatura e Retirada
• Parte 8: Segurança do Ledger de Corretoras: Caminhos de Roubo e Lógica do Plano de Dados

A página pilar de Blockchain Penetration Testing oferece a visão em nível de engajamento.

Referências

Numeradas em ordem de primeira aparição.

1. National Institute of Standards and Technology, Rules of Engagement (ROE), CSRC Glossary.
2. União Europeia, Regulamento (UE) 2022/2554 — Digital Operational Resilience Act (DORA), Artigo 26.
3. Hong Kong Securities and Futures Commission, Circular to Licensed Virtual Asset Trading Platform Operators on Custody of Virtual Assets (15 de agosto de 2025).