PCI-DSS: o que é compliance de verdade quando o dinheiro de todo mundo depende do seu sistema
Compliance parece burocracia até você entender o que está protegendo. Aqui está o que aprendi trabalhando em ambiente financeiro regulado.
Antes de trabalhar em ambiente financeiro, eu achava que compliance era uma camada burocrática que as empresas adicionavam por obrigação legal — algo que tornava o trabalho mais lento sem benefício real.
Depois de trabalhar com PCI-DSS, entendo que é proteção. A burocracia existe porque alguém, em algum momento, não fez a coisa certa, e isso afetou pessoas reais.
PCI-DSS é Payment Card Industry Data Security Standard — um conjunto de requerimentos de segurança para organizações que processam pagamentos com cartão. Em termos práticos: se seu sistema toca dados de cartão de crédito em qualquer forma — transmite, processa, armazena — você está em escopo de PCI-DSS.
O que isso significa tecnicamente é extenso. Criptografia em trânsito e em repouso. Controles de acesso rigorosos. Logs de auditoria de toda ação em sistemas sensíveis. Segmentação de rede entre ambiente de cardholder data e o restante. Varredura de vulnerabilidades em intervalos regulares. Testes de penetração anuais.
E tudo isso precisa ser demonstrável para um auditor.
A parte que mais muda a forma de trabalhar é que cada mudança em sistema em escopo precisa de rastro. Não só um commit — documentação do quê mudou, quem aprovou, qual foi o teste realizado. Em ambiente não regulado, você pode fazer uma mudança, testar rapidamente e fazer deploy. Em ambiente PCI-DSS, há um processo que precisa ser seguido, e o processo existe por uma razão.
No início isso me frustrava. Com o tempo entendi que o processo me protegia também — não só como empresa, mas como engenheiro. Se algo der errado num deploy em ambiente regulado, você quer ter documentação mostrando que seguiu o processo correto. Sem ela, a responsabilidade é muito menos clara.
Acesso mínimo necessário é o princípio mais importante de PCI-DSS na prática. Cada pessoa, serviço ou sistema tem acesso apenas ao que precisa para sua função específica. Não mais. Isso parece óbvio dito assim, mas implementar significa auditoria contínua de permissões, revisão periódica de acessos, e resistência ativa a pedidos de "dá acesso temporário pra facilitar" que acabam se tornando permanentes.
Quando você opera com esse princípio por tempo suficiente, ele contamina positivamente como você pensa sobre arquitetura em geral. Sistemas com escopo mínimo são mais fáceis de auditar, mais fáceis de entender, e mais fáceis de proteger.
A parte que mais aprendi foi sobre gestão de segredos. Em ambiente PCI-DSS, chave de API e credenciais de banco não existem em arquivos de configuração no repositório — nunca, sem exceção. Elas existem em sistemas dedicados de gestão de segredos, com auditoria de acesso, rotação automática, e proteção específica.
Implementar isso corretamente é trabalho de plataforma: você constrói o mecanismo uma vez para que cada serviço o use automaticamente. Quando o golden path inclui gestão segura de segredos, os desenvolvedores usam o caminho correto sem precisar pensar sobre isso.
O que compliance me ensinou sobre engenharia em geral: rastreabilidade importa. Saber o quê mudou, quando, por quem, e por quê é valioso mesmo em sistemas que não são regulados. Incidents são resolvidos mais rápido quando você pode traçar o caminho de volta. Onboarding é mais fácil quando decisões de design têm contexto documentado. Post-mortems têm mais valor quando há linha do tempo clara do que aconteceu.
Compliance força essas práticas por obrigação. Mas as melhores equipes as adotam porque as práticas têm valor intrínseco.
Essa semana: olha para um serviço que você mantém e faz a pergunta: se alguém precisasse auditar esse serviço amanhã — entender quem tem acesso, o que pode fazer com esse acesso, e como rastrear qualquer ação — o que você teria que explicar que não está documentado? Esse exercício revela débito técnico de segurança que costuma ficar invisível até virar problema.