Compliance e auditoria: evidência como efeito colateral

SchemaBridge Team · 2026-01-24 · Compliance, SOC2, GDPR, Security

Facilitar a coleta de evidências SOC2 e o apagamento GDPR com um histórico de execução registrado, sendo preciso sobre o que ele não garante.

O imposto da compliance: por que auditorias atrasam você

Se você já passou por uma auditoria SOC2, ISO27001 ou HIPAA, conhece a dor. O auditor pergunta: "Mostre-me evidências de que cada solicitação de desligamento de usuário foi processada em até 24 horas."

Em um sistema tradicional, isso desencadeia uma caça ao tesouro frenética.

Você vasculha logs de e-mail.
Você faz grep no Splunk atrás de alguma mensagem de "Deleted User".
Você tira capturas de tela de um ticket do JIRA.
Você cruza timestamps em uma planilha.

Essa coleta manual de evidências pode consumir semanas de tempo de engenharia. É o imposto da compliance. Ele desvia suas melhores pessoas da construção de funcionalidades. E, pior, a evidência costuma ser circunstancial. Você consegue provar que um script rodou, mas consegue provar exatamente quais dados ele tocou?

A trilha de auditoria: evidência como efeito colateral

Na SchemaBridge, acreditamos que a evidência deve ser um efeito colateral da execução, e não uma atividade separada. O motor escreve uma trilha de auditoria enquanto trabalha: inícios, replays e resoluções por operador das execuções, alterações em workflows, vértices e arestas, deploys, mudanças de configuração e de retenção, mudanças de permissões e papéis, e decisões de aprovação.

O que a trilha oferece

Transições de estado registradas: o estado da execução fica no PostgreSQL e é atualizado à medida que a execução avança; ao lado dele, cada transição de estado é anexada a um trace de execução, de modo que "como chegamos aqui" pode ser respondido depois. A trilha de auditoria registra o início da execução e qualquer ação de operador sobre ela, não cada transição.
Rastreabilidade: para qualquer execução, você pode inspecionar a entrada e a saída registradas de cada etapa (dentro da sua janela de retenção). Observe a distinção: na SchemaBridge, Replay executa novamente um workflow sob uma nova execução, incluindo efeitos colaterais; não é uma reprodução histórica somente leitura.
Histórico consultável: a trilha de auditoria pode ser consultada por workspace e por workflow pela API, e fica em um armazenamento colunar dedicado (ClickHouse, atrás de um serviço interno de auditoria), separado do banco de dados operacional.

O que ela não é

Seja preciso com seu auditor sobre as garantias. A trilha de auditoria é append-only no nível da aplicação, mas não é à prova de adulteração: não há cadeia de hashes nem assinatura, e as gravações de auditoria são best-effort, de modo que uma falha de gravação não aparece como uma lacuna detectável. Se você precisa de evidências de nível WORM, exporte a trilha para um armazenamento de gravação única que você controle.

GDPR e o "direito ao esquecimento"

Um dos desafios mais difíceis em qualquer sistema que mantém histórico é o "direito ao esquecimento" (Artigo 17 do GDPR). Se você mantém um histórico, como apaga as PII (informações de identificação pessoal) de um usuário?

Apagamento e retenção

A SchemaBridge aborda isso com caminhos de apagamento e janelas de retenção.

1. Apagamento: excluir um workspace aciona um caminho de apagamento dedicado, apoiado por um registro de obrigações que é gravado antes da exclusão irreversível e verificado depois; um caminho separado apaga os dados de um usuário individual.

2. Expurgo automatizado: as janelas de retenção são definidas por workspace (ou herdadas do seu plano). Linhas de execução, traces e payloads antigos são excluídos automaticamente.

3. Mascaramento de credenciais: campos com formato de credencial (chaves de API, segredos, tokens) são mascarados como nos logs de execução. O mascaramento de PII não* é automático, então a melhor defesa é não fazer dados pessoais passarem por etapas que não precisam deles.

Automatizando a coleta de evidências SOC2

Você pode usar workflows da SchemaBridge para automatizar partes da própria auditoria.

O "Robô Auditor"

Em vez de coletar capturas de tela manualmente, você cria um workflow especializado de "Coleta de Evidências" que roda em um agendamento cron toda segunda-feira.

1. Varrer: ele consulta a API do GitHub para listar todos os PRs mesclados na semana anterior.

2. Verificar: ele confere se cada PR tem uma revisão "Approved" de um code owner.

3. Snapshot: ele gera um snapshot JSON do status de compliance.

4. Arquivar: ele grava o snapshot em um armazenamento que seus auditores possam ler (por meio de um endpoint HTTP que você controla — idealmente, armazenamento de gravação única).

Quando o auditor chegar, você o direciona ao arquivo em vez de a uma pilha de capturas de tela, e o tempo de preparação da auditoria encolhe na mesma proporção.

{
  "week": "2026-W03",
  "mergedPullRequests": 42,
  "withCodeOwnerApproval": 42,
  "exceptions": []
}

Cenário ilustrativo: admissão de pacientes em um ambiente regulado

Considere uma startup hipotética de HealthTech que precisa automatizar formulários de admissão de pacientes.

O desafio

Ela precisa demonstrar que:

1. Apenas pessoal autorizado podia alterar ou executar o workflow de admissão.

2. Toda alteração no workflow e todo resultado de execução foram registrados.

3. Os dados nunca foram expostos a ferramentas de logging de terceiros (Splunk/Datadog).

A abordagem

1. Acesso baseado em papéis: papéis de workspace (admin, writer, reader) e escopos de permissão limitam quem pode editar, fazer deploy e executar o workflow, e toda mudança de papel vai para a trilha de auditoria.

2. Execuções registradas: o início de cada execução de admissão e qualquer resolução por operador estão na trilha de auditoria, o histórico completo de status fica no histórico de execuções, e o payload de cada etapa pode ser inspecionado dentro da plataforma em vez de ser impresso no stdout.

3. As lacunas que continuariam sendo delas: a SchemaBridge não registra quem visualizou um payload, não tem um papel específico para HIPAA e não possui certificação HIPAA. O registro de acessos por visualização e a papelada regulatória continuariam sob a responsabilidade delas.

O provável retorno

Uma configuração como essa tornaria muito menos dolorosas as partes de uma auditoria referentes a gestão de mudanças e histórico de execuções, sendo honesta sobre as partes que a plataforma não cobre.

Comparação: logging tradicional vs. trilha de auditoria da SchemaBridge

| :--- | :--- | :--- | :--- |

Checklist de especialista para arquitetura de compliance

1. Não registre PII em log: cuidado com o que você imprime no stdout e com o que passa entre etapas. Mantenha dados pessoais fora de payloads que não precisam deles.

2. Automatize as evidências: se fizer manualmente, você vai errar. Automatize a auditoria com scripts.

3. Separe funções: quem escreve o workflow não deve ser quem detém as chaves de administrador.

4. Teste a exclusão: execute regularmente "solicitações GDPR simuladas" para verificar se seus caminhos de apagamento e retenção estão realmente funcionando.

5. Conheça os limites da sua plataforma: pergunte a cada fornecedor — incluindo nós — exatamente o que é registrado, por quanto tempo e se é à prova de adulteração. Escreva as respostas na descrição dos seus controles.

Conclusão: confiança é uma API

Compliance não é sobre papelada; é sobre confiança. Ao construir seus sistemas sobre uma base de histórico registrado e consultável — e ao ser preciso sobre o que esse histórico garante e o que não garante —, você passa de "Confie em mim, sou um bom engenheiro" para "Aqui está a evidência."

Parte da nossa série Building the Bridge. Veja também: O futuro da integração.