Compliance as Code: Automating SOC 2, ISO 27001 e LGPD

Compliance costuma ser tratado como um evento: chega a auditoria, monta-se a evidência, corrige-se o que está fora do lugar e o ciclo recomeça meses depois. O problema dessa abordagem não é só o esforço concentrado, mas o intervalo cego entre uma auditoria e a próxima, em que o estado real do ambiente pode ter derivado muito do que foi declarado.

Compliance as Code parte de uma premissa diferente: os controles exigidos por SOC 2, ISO 27001 ou LGPD podem ser expressos como políticas em código, versionadas no repositório, testadas em pipeline e executadas de forma contínua. A evidência deixa de ser uma planilha preenchida às pressas e passa a ser o log de execução de uma política que roda toda vez que algo muda na infraestrutura.

O que muda na prática

O modelo tradicional funciona com checklists e revisões periódicas. Alguém verifica se os buckets S3 estão privados, se o MFA está habilitado nos acessos privilegiados, se os logs estão retidos pelo período exigido. A verificação é manual e pontual.

Quando esses mesmos requisitos são expressos como código, a lógica é outra. Uma política define o estado esperado de um recurso. A ferramenta de policy enforcement avalia continuamente se o estado real corresponde ao declarado. Qualquer desvio (drift) gera um alerta, bloqueia uma mudança ou produz um registro rastreável, dependendo do modo de operação configurado.

Para o time de engenharia, as restrições chegam mais cedo no ciclo, muitas vezes no próprio pull request. Para o auditor, a evidência é um relatório gerado pelo sistema, com timestamp, recurso e resultado de cada verificação, não um screenshot tirado na semana anterior.

Ferramentas que fazem o trabalho

Algumas ferramentas são referência consolidada nesse espaço.

O Open Policy Agent (OPA) é um motor de políticas de propósito geral. As políticas são escritas em Rego e avaliadas contra dados em JSON. Funciona para validar configuração de Kubernetes (via Gatekeeper), bloquear chamadas de API ou verificar infraestrutura antes do apply, e é agnóstico à tecnologia avaliada.

O AWS Config monitora recursos na conta AWS e verifica conformidade com regras predefinidas ou customizadas. Os Conformance Packs agrupam regras alinhadas a frameworks conhecidos: existem packs públicos para benchmarks como CIS AWS Foundations, e é possível montar packs customizados para cobrir controles específicos de SOC 2 ou ISO 27001.

O Chef InSpec trata testes de compliance como código Ruby. Um perfil descreve o estado esperado de um servidor, container ou serviço de nuvem, e o framework executa e reporta o resultado. Há uma coleção pública de perfis para frameworks comuns no repositório da Dev-Sec.io.

O Checkov analisa código de infraestrutura (Terraform, CloudFormation, Kubernetes manifests) em busca de configurações problemáticas. Integra-se em CI e retorna resultados por arquivo e linha.

O kube-bench implementa os benchmarks CIS para Kubernetes, verificando configuração de nós, API server e etcd. O Cloud Custodian usa políticas em YAML para avaliar e, opcionalmente, remediar recursos de nuvem automaticamente.

Mapeando frameworks para verificações

Os três frameworks mencionados têm naturezas distintas, mas todos têm controles técnicos que se traduzem razoavelmente bem em código.

SOC 2 se organiza em torno dos Trust Services Criteria. Os controles de disponibilidade, confidencialidade e segurança lógica (acesso, criptografia, monitoramento de mudanças) têm equivalentes diretos em verificações automatizáveis: MFA habilitado em contas privilegiadas, criptografia em repouso ativa nos volumes, logs de acesso retidos. A ideia não é cobrir todo o criterio com uma regra, mas identificar quais partes de cada criterio têm uma verificação técnica objetiva.

ISO 27001 tem um Anexo A com controles distribuídos em domínios como controle de acesso, gestão de ativos, operações de segurança e criptografia. A lógica é a mesma: cada controle tem uma parte técnica (estado de configuração verificável) e uma parte organizacional (processos, treinamento, aprovações). A automação cobre a parte técnica.

LGPD não é um framework de controles técnicos no mesmo sentido, mas exige que as organizações adotem medidas técnicas e administrativas para proteger dados pessoais. Para o lado técnico, isso se traduz em verificações de acesso a bancos de dados com dados pessoais, criptografia, segregação de ambientes e registro de operações de tratamento. O mapeamento é menos prescritivo, mas possível.

Em todos os casos, o trabalho começa por identificar quais controles têm uma expressão técnica objetiva. Pacotes prontos são pontos de partida, não respostas completas.

Geração de evidência

Um dos ganhos concretos da abordagem é a evidência gerada como subproduto da execução normal. Quando AWS Config avalia uma regra e registra o resultado, esse log é uma evidência de auditoria com timestamp, recurso, regra avaliada e resultado. Quando um Conformance Pack gera um relatório, ele lista o estado de cada recurso em relação a cada regra no momento da avaliação.

Isso não elimina o trabalho de auditoria, mas muda sua natureza. Em vez de reconstruir o passado manualmente, o auditor recebe uma trilha contínua de verificações. A equipe interna passa menos tempo reunindo evidências e mais tempo explicando o contexto e tratando exceções.

O que compliance as code não cobre

Esse ponto merece clareza. Compliance as code cobre controles técnicos verificáveis em código: estado de configuração, permissões, criptografia, logs, regras de rede. Não cobre, e provavelmente nunca vai cobrir, uma parte significativa do que os frameworks exigem.

Políticas organizacionais, processos de contratação e desligamento, treinamento de equipe, gestão de fornecedores, planos de resposta a incidentes, revisões de risco: esses controles dependem de pessoas, processos e decisões que não existem em um arquivo de configuração. A automação reduz a carga sobre os controles técnicos e libera atenção para o restante, mas não substitui a governança.

Como começar

O ponto de entrada mais direto é pegar um framework que já está no radar da organização e listar quais controles técnicos estão sendo verificados manualmente hoje. Esses são os candidatos naturais para automação.

A escolha da ferramenta depende do que já está em uso: quem tem infraestrutura majoritariamente em AWS começa com Config rules. Quem usa Terraform como IaC tem Checkov como opção óbvia para o pipeline. Quem roda Kubernetes vai querer kube-bench e alguma forma de policy enforcement nos manifests.

O fluxo típico é escrever a política, validá-la contra o ambiente atual (esperando encontrar desvios), corrigir o que está fora do estado declarado e, em seguida, ativar o monitoramento contínuo. As primeiras execuções revelam divergências acumuladas que um checklist manual não teria detectado entre ciclos de auditoria.

Maturidade nessa área não é ter todas as políticas escritas no primeiro dia. É incorporar o processo de transformar requisitos de compliance em código ao fluxo normal de trabalho, da mesma forma que uma nova funcionalidade passa por revisão antes de ir para produção.