Compliance & Auditing: O Ledger Imutável
SchemaBridge Team · 2026-01-24 · Compliance, SOC2, GDPR, Security
Alcançando conformidade com SOC2 e GDPR por padrão. Histórico de execução rastreável.
O Imposto de Compliance: Por Que as Auditorias Te Atrasam
Se você já passou por uma auditoria SOC2, ISO27001 ou HIPAA, conhece a dor. O auditor pergunta: "Mostre-me evidências de que toda solicitação de offboarding 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 "Usuário Excluído".
- Você tira screenshots de um ticket do JIRA.
- Você faz referência cruzada de timestamps em uma planilha.
Essa coleta manual de evidências consome semanas de tempo de engenharia. É o Imposto de Compliance. Ele distrai seus melhores profissionais da construção de funcionalidades. E, pior, a evidência costuma ser circunstancial. Você pode provar que um script rodou, mas consegue provar exatamente quais dados ele tocou?
O Ledger Imutável: Auditoria por Padrão
Na SchemaBridge, acreditamos que Compliance deve ser um efeito colateral da Execução, não uma atividade separada. Como nosso engine é baseado em um Log de Eventos Somente-Anexação (Parte 1), cada ação, decisão e mudança de variável é registrada em um histórico imutável.
O Poder do Event Sourcing
Não armazenamos apenas o estado atual; armazenamos o histórico completo de como chegamos até ele.
- Somente-Anexação: Nunca sobrescrevemos um registro na tabela de histórico. Cada mudança de estado é uma nova linha.
- Rastreabilidade: Você pode reproduzir um Workflow do início ao fim e ver exatamente quais eram as entradas, o que a lógica decidiu e quais eram as saídas em cada etapa.
- Evidência de Adulteração: Como o log é sequencial e imutável, qualquer lacuna ou modificação se destaca imediatamente.
GDPR e o "Direito ao Esquecimento"
Um dos desafios mais difíceis no event sourcing é o "Direito ao Esquecimento" (Artigo 17 do GDPR). Se o seu log é imutável, como você exclui os dados de PII (Informações Pessoalmente Identificáveis) de um usuário?
Mascaramento de Campos e Políticas de Retenção
A SchemaBridge resolve isso com Políticas de Retenção Estritas.
1. Isolamento de PII: Incentivamos os desenvolvedores a sinalizar campos sensíveis no contexto do Workflow.
2. Purga Automatizada: Você pode definir políticas de retenção (ex.: "Manter logs por 30 dias") no nível do Workflow. O engine purga automaticamente dados antigos de histórico do DynamoDB para atender aos requisitos de privacidade.
3. Mascaramento de Campos: Nos logs expostos aos desenvolvedores, campos sensíveis podem ser mascarados (***) por padrão, garantindo que a PII não seja vista casualmente durante sessões de depuração.
Automatizando a Coleta de Evidências para SOC2
Você pode usar Workflows da SchemaBridge para automatizar a própria auditoria.
O "Bot Auditor"
Em vez de coletar screenshots manualmente, você cria um Workflow especializado de "Coleta de Evidências" que roda toda segunda-feira.
1. Varredura: Ele consulta a API do GitHub para listar todos os PRs mesclados na semana anterior.
2. Verificação: Ele verifica se cada PR tem uma revisão "Aprovada" de um code owner.
3. Snapshot: Ele tira um snapshot JSON do status de compliance.
4. Arquivamento: Ele escreve um relatório assinado em um bucket S3 WORM (Write Once, Read Many).
Quando o auditor chega, você simplesmente dá a ele Acesso de Leitura ao bucket S3. Seu tempo de preparação para auditoria cai de semanas para zero.
Estudo de Caso: Onboarding de Pacientes em Conformidade com HIPAA
Trabalhamos com uma startup de HealthTech que precisava automatizar formulários de admissão de pacientes.
O Desafio
Eles precisavam provar que:
1. Apenas médicos autorizados viam o histórico do paciente.
2. Todo acesso era registrado.
3. Os dados nunca eram expostos a ferramentas de log de terceiros (Splunk/Datadog).
A Solução SchemaBridge
1. Logs de Acesso: Toda vez que um Vértice de Workflow acessava a variável do paciente, um "Evento de Acesso" genérico era gravado no ledger.
2. Log em Cofre: Os dados brutos nunca eram enviados para o stdout. Eles só ficavam visíveis no dashboard da SchemaBridge para usuários com o papel HIPAA_OFFICER e, mesmo assim, toda visualização era registrada.
O Resultado
Eles passaram em sua auditoria HIPAA com zero não-conformidades. O auditor ficou impressionado com a capacidade de reproduzir o histórico exato de acesso aos dados de um paciente sem expor os dados em si.
Comparação: Logging Tradicional vs. Compliance SchemaBridge
| Recurso | Syslog / Splunk | Tabelas de Auditoria de Banco de Dados | Ledger SchemaBridge |
| :--- | :--- | :--- | :--- |
| Imutabilidade | Baixa (pode ser excluído) | Média (DBA pode editar) | Alta (Somente-Anexação) |
| Contexto | Linha única | Mudança de linha | Contexto Completo do Workflow |
| Tratamento de PII | Mascaramento manual | Criptografia de coluna | Auto-Mascaramento |
| Retenção | Limitada (custosa) | Limitada (performance) | Políticas Configuráveis |
Checklist de Especialista para Arquitetura de Compliance
1. Não Registre PII: Tenha cuidado com o que você imprime no stdout. Deixe o engine cuidar da persistência de estado com segurança.
2. Automatize Evidências: Se você fizer isso manualmente, cometerá um erro. Script a auditoria.
3. Separe Responsabilidades: A pessoa que escreve o Workflow não deve ser a pessoa que detém as chaves de administrador.
4. Teste a Exclusão: Execute regularmente "Solicitações Simuladas de GDPR" para verificar se suas políticas de retenção realmente funcionam.
Conclusão: Confiança é uma API
Compliance não é sobre papelada; é sobre Confiança. Ao construir seus sistemas sobre uma base de histórico verificável e imutável, você deixa de dizer "Confie em mim, sou um bom engenheiro" e passa a dizer "Confie no Sistema".
Na Parte 15, encerraremos nossa série analisando o "Futuro da Integração" e como agentes de IA em breve estarão escrevendo e gerenciando esses Workflows para nós.