Protegendo o pipeline: Zero-Trust na camada de eventos

SchemaBridge Team · 2026-01-03 · Security, Zero Trust

Como proteger workflows de longa duração: segredos apenas por referência, injeção just-in-time e identidade zero-trust.

O perímetro invisível: por que a segurança tradicional falha na camada de eventos

No mundo das aplicações monolíticas, segurança era algo simples. Você construía uma "fortaleza" — um firewall ao redor dos seus servidores. Você controlava a rede, o hardware e o software. Usava um provedor de identidade (IdP) na entrada e, uma vez que uma requisição estava lá dentro, ela era "confiável". Esse é o modelo de segurança Castle-and-Moat (castelo e fosso).

Mas, à medida que entramos na era dos ciclos de negócio distribuídos e de longa duração — o que chamamos de camada de eventos —, as muralhas do castelo ruíram. Sua aplicação não vive mais em um só lugar. Ela é um enxame de microsserviços, APIs SaaS de terceiros e workers headless disparados por webhooks vindos do mundo externo. Não existe perímetro. Os dados estão constantemente em trânsito, sendo transformados por código que você não escreveu e armazenados em bancos de dados que você não controla totalmente.

Nesse cenário fragmentado, os antigos fossos são inúteis. Precisamos de um novo paradigma de segurança, embutido no conjunto de instruções do próprio motor. Nós o chamamos de Zero-Trust transacional.

O pesadelo de segurança: vazamento de credenciais

Como arquiteto, você enfrenta ameaças existenciais fundamentais na camada de eventos. Uma das mais críticas é o vazamento de credenciais.

Integração exige chaves de API. Você tem chaves do Stripe, tokens do Salesforce e senhas de bancos de dados internos. Em um script de "código cola", esses segredos costumam ficar em variáveis de ambiente ou ser repassados em payloads JSON. Se um desenvolvedor adiciona por engano um console.log(payload) para depurar, ou se o seu sistema de logs for comprometido, seus segredos de produção essenciais ficam expostos ao mundo. Credenciais vazadas e mal gerenciadas estão entre as principais causas de incidentes de segurança na nuvem.

A pilha de segurança do SchemaBridge: isolamento no nível da infraestrutura

No SchemaBridge, construímos nosso modelo de segurança para enfrentar essas ameaças com restrições de infraestrutura, e não apenas com "boas práticas de programação". Os scripts dos tenants, por exemplo, rodam em GraalVM em um script runner isolado, sem credenciais e sem saída de rede, de modo que um script não consegue alcançar seus segredos nem o banco de dados da plataforma, mesmo que tente.

Identidade zero-trust: além das chaves de API

Em uma jornada distribuída, a identidade precisa ser dinâmica e delimitada. Usar uma única chave de API "root" para todos os seus workers é um risco catastrófico.

O SchemaBridge usa um modelo de credenciais apenas por referência:

1. Cofre de segredos criptografado: suas chaves de API de produção nunca são armazenadas na configuração do workflow nem no seu estado. Elas ficam em um cofre de segredos criptografado (nosso EntitySecretRepository), criptografado em repouso com AES-256-GCM e com suporte a rotação de chaves.

2. Apenas referência: no grafo visual, você vê somente uma referência ao segredo pelo nome (por exemplo, {{ secrets.STRIPE_KEY }}). Os nomes são estáticos de propósito: não há suporte a expressões, porque um nome calculado permitiria que um payload escolhesse qual credencial é lida.

3. Injeção just-in-time: somente quando um Gateway Vertex envia sua requisição HTTP o motor resolve a referência, descriptografa o token e o substitui nos cabeçalhos ou no corpo de saída. Os segredos não podem ser lidos a partir de expressões de configuração nem de scripts, e um segredo nomeado nunca é copiado para a configuração do vertex nem para o estado do workflow.

{
  "type": "GATEWAY",
  "config": {
    "url": "https://api.stripe.com/v1/refunds",
    "method": "POST",
    "headers": {
      "Authorization": "Bearer {{ secrets.STRIPE_KEY }}"
    }
  }
}

Algumas proteções adicionais se aplicam: apenas segredos do tipo bearer, chave de API e mapa de cabeçalhos podem sair da plataforma (chaves de assinatura HMAC, nunca), e segredos gerenciados pela plataforma não podem ser injetados por autores de workflows.

Uma ilustração: um agregador de pagamentos com menos vazamento de segredos

Considere um agregador de pagamentos hipotético que processa transferências para uma grande base de lojistas e se integra a um punhado de provedores de pagamento.

O desafio

Imagine o sistema antigo, construído sobre Kubernetes Secrets, com cada chave de provedor carregada como variável de ambiente nos workers Node.js. Um dia, um desenvolvedor adiciona um log de depuração que, por engano, imprime o objeto process.env de uma requisição com falha. Em uma configuração como essa, chaves de provedores podem vazar para uma stack ELK acessível a todo o time de engenharia — uma falha de segurança crítica que exigiria uma operação massiva de rotação e um relatório formal aos órgãos reguladores.

A abordagem com o SchemaBridge

Agora imagine o mesmo time migrando seus fluxos de pagamento para o SchemaBridge.

1. Migração para o cofre de segredos: o time move suas chaves de provedores para o cofre de segredos do SchemaBridge, um segredo nomeado por credencial.

2. Referência por nome: cada vertex Gateway referencia sua credencial pelo nome ({{ secrets.stripe-key }}), nunca pelo valor.

3. Logs mais limpos: como o Gateway substitui o valor apenas na saída, os logs mostram somente a referência ao segredo. Mesmo que um desenvolvedor registre o payload inteiro de uma etapa, o valor do segredo nunca esteve lá.

O resultado provável

O futuro: orquestração zero-trust como padrão

Na próxima década, esperamos que o modelo "Castle-and-Moat" desapareça por completo. Cada vertex de um sistema distribuído será tratado como seu próprio microperímetro. A segurança deixará de ser uma "camada" para se tornar uma propriedade da instrução.

Estamos construindo o SchemaBridge nessa direção. Ao combinar o isolamento de código não confiável (scripts dos tenants rodam em um runner isolado, sem credenciais e sem saída de rede) com a injeção de segredos apenas por referência, nosso objetivo é permitir que você construa integrações complexas sem entregar credenciais em texto puro a cada componente que as manipula.

Checklist de especialista para orquestração segura

Para construir uma camada de eventos "testada em batalha", siga estas três regras inegociáveis:

1. Inverta seus segredos: segredos nunca devem ficar no código nem nos payloads do workflow. Resolva-os no último momento possível e mantenha-os fora de tudo o que é registrado em log.

2. Acesso com privilégio mínimo: um worker que processa uma etiqueta de envio não deveria ter a chave de API do seu gateway de cobrança. Restrinja o escopo das credenciais tanto quanto sua plataforma permitir. (No SchemaBridge, os segredos têm escopo de workspace; portanto, use workspaces separados para separar funções que não podem compartilhar credenciais.)

3. Audite cada acesso: como prática geral, registre quem acessou qual segredo e por quê; trilhas de auditoria imutáveis são sua melhor defesa em uma investigação forense. Atualmente, o SchemaBridge não emite um evento de auditoria por acesso a segredo; por isso, combine-o com seus próprios controles se precisar disso.

Conclusão: confiança se constrói com infraestrutura, não com intenção

Não dá para chegar a um sistema seguro só com "treinamento". O erro humano é inevitável. Segurança de verdade se apoia em restrições estruturais que tornam difícil fazer a coisa errada por acidente. O SchemaBridge oferece várias dessas restrições, para que você possa se concentrar em construir funcionalidades com menos caminhos pelos quais uma credencial possa escapar.

Veja também: Atrasos duráveis — gerenciando ciclos de negócio baseados em tempo ao longo de semanas e meses.

Explorar