PCI DSS - Porque você deveria conhecer antes de desenvolver qualquer aplicação com transações financeiras | Michel Oliveira | Arquiteto de Software Especialista Microsoft

Sumário

Mostrar/Ocultar

Introdução

Se você já trabalhou em um sistema que processa pagamentos (cartão de crédito, débito, wallets, etc.), provavelmente já esbarrou em termos como PCI DSS, compliance PCI e tokenização.

O problema é que muitos times de desenvolvimento desconhecem esse universo e/ou não são orientados a entendê-lo, até o dia em que alguém do time de segurança, gateway de pagamento ou do parceiro adquirente pergunta:

Vocês já estão em conformidade com o PCI DSS?

Esse é o momento em que muita gente percebe: não dá para brincar quando o assunto é dados financeiros. Neste post, vou trazer uma visão prática do que é o PCI DSS, por que ele existe, sua relação com legislações como a LGPD e o impacto direto no design de sistemas e código.

O que é PCI DSS?

PCI DSS significa Payment Card Industry Data Security Standard. É um conjunto de requisitos de segurança criado pelas principais bandeiras de cartões (Visa, Mastercard, American Express, Discover e JCB) para garantir que toda empresa que armazene, processe ou transmita dados de cartão mantenha um nível mínimo de proteção.

Em outras palavras: é um manual de boas práticas obrigatórias para qualquer sistema que lide com cartões.

PCI DSS e o nível de exigência

Nem toda empresa precisa passar por auditoria e certificação formal de PCI DSS. O nível de exigência de validação depende do volume de transações processadas e do tipo de integração.

Instituições financeiras, adquirentes e processadores de alto volume são obrigados a manter certificação formal, com auditorias externas e relatórios detalhados.

Empresas e aplicações menores continuam obrigadas a estar em conformidade com o PCI DSS, mas geralmente apenas via questionários de autoavaliação (SAQ), especialmente quando usam serviços externos já PCI DSS compliant.

Isso não significa que possam ignorar o PCI DSS: a forma como sua aplicação coleta, transmite e armazena dados de cartão pode aumentar ou reduzir o escopo e o nível de auditoria exigido.

Relação entre PCI DSS e LGPD

No Brasil, além do PCI DSS, há uma camada legal que não pode ser ignorada: a Lei Geral de Proteção de Dados (LGPD).

Enquanto o PCI DSS foca em requisitos técnicos para proteger dados de cartão, a LGPD estabelece obrigações legais sobre o tratamento de qualquer dado pessoal, incluindo os financeiros.

Podemos pontuar que:

Incidentes de segurança: se houver vazamento de dados de cartão, a empresa pode ser responsabilizada não apenas pelo descumprimento do PCI DSS, mas também pela violação da LGPD.
Responsabilidade legal: a LGPD obriga que incidentes relevantes sejam comunicados à Autoridade Nacional de Proteção de Dados (ANPD) e aos titulares.
Sanções: multas que podem chegar a 2% do faturamento da empresa (limitadas a R$ 50 milhões por infração), além de restrições de operação.
Princípio da minimização: quanto menos dados sensíveis você armazenar, menor será seu risco de descumprir tanto PCI DSS quanto LGPD.

Em resumo: se um incidente de segurança expõe informações de cartão, você terá que responder em dois níveis - o técnico, perante bandeiras e adquirentes (PCI DSS), e o legal, perante o Estado e os clientes (LGPD).

Uso apenas PIX e boleto, preciso me preocupar com PCI DSS?

Se sua aplicação não armazena, processa ou transmite dados de cartão de crédito/débito e utiliza apenas PIX ou boletos, o escopo do PCI DSS não se aplica diretamente, pois o padrão é específico para dados de cartões de pagamento.

No entanto, ainda é importante:

Entender o PCI DSS como referência de segurança: mesmo que não aplicável, seus princípios podem orientar boas práticas de proteção de dados e arquitetura segura.
Garantir proteção de dados pessoais segundo a LGPD.
Manter boas práticas de segurança em transações financeiras sensíveis (TLS/HTTPS, logs seguros, autenticação forte).
Avaliar se algum gateway ou serviço intermediário eventualmente manipula cartões por exemplo para algum tipo de validação, pois o escopo pode aumentar.

Ou seja: você pode não precisar seguir PCI DSS, mas segurança e conformidade legal continuam essenciais.

Os dados do titular do cartão - CHD (Cardholder Data)

PAN (Primary Account Number): número do cartão, identifica a conta do titular; considerado dado sensível e protegido pelo PCI DSS.
Nome do titular: dado pessoal do proprietário do cartão; deve ser protegido.
Data de validade: combinado com o PAN, pode permitir fraudes; classificado como dado sensível.
Código de segurança (CVV/CVC): código de 3 ou 4 dígitos; extremamente sensível, não deve ser armazenado após a autorização e, preferencialmente, não deve trafegar entre o cliente e o seu servidor.

Em uma representação simplificada, o ideal seria

sequenceDiagram title Diagrama de Sequência - Checkout transparente com tokenização de cartão client side participant User as Seu Usuário (usando Navegador/App) participant Gateway as Gateway de Pagamento (suportando Tokenização client side) participant Merchant as Sua API User->>Gateway: Envia dados do cartão note over User,Gateway: Dados do cartão trafegam apenas no ambiente PCI DSS Gateway-->>User: Retorna Token no frontend User->>Merchant: Envia apenas o Token note over User,Merchant: A aplicação nunca vê os dados reais do cartão Merchant->>Gateway: Solicita autorização usando o Token Gateway-->>Merchant: Retorna resultado (aprovado/negado) Merchant-->>User: Exibe confirmação da transação

Os requisitos do PCI DSS

O padrão completo é extenso, mas os 12 requisitos principais podem ser agrupados em seis objetivos:

Construir e manter uma rede segura: Firewalls, segmentação de redes, hardening.
Proteger os dados do cartão: Criptografia forte, mascaramento de PAN (Primary Account Number).
Manter um programa de gestão de vulnerabilidades: Patches aplicados, antivírus atualizado.
Implementar controles de acesso robustos: Princípio do menor privilégio, autenticação multifator.
Monitorar e testar redes regularmente: Logs, SIEM, testes de penetração periódicos.
Manter uma política de segurança da informação: Documentação, treinamento, cultura organizacional.

O impacto para desenvolvedores

Agora o ponto mais crítico: o que isso muda na vida de quem escreve código?

Reduza ao mínimo a manipulação de dados de cartão: A regra de ouro é: não armazene dados sensíveis do titular. PAN, CVV e data de expiração colocam seu sistema em um escopo delicado.
Prefira tokenização client-side: Muitos gateways oferecem SDKs que capturam o cartão no browser do cliente, enviam direto para os servidores do gateway (que já são PCI DSS compliant) e retornam um token.
Esse token pode ser usado pelo seu back-end para processar a transação, sem nunca ter contato com os dados reais do cartão.
Transmissão de dados deve ser criptografada: HTTPS/TLS é obrigatório. Nunca registre números de cartão em logs, nem em staging. Um simples log acidental pode gerar não conformidade em PCI DSS e ainda se enquadrar como incidente de segurança sob a LGPD.
Arquitetura define seu escopo PCI: Quanto mais seu sistema vê dados sensíveis, maior o custo de compliance. Se o navegador do cliente conversa direto com o gateway e seu servidor recebe apenas tokens, o escopo de auditoria é reduzido, mas não anulado.
Auditoria e rastreabilidade: Mesmo não sendo obrigado a certificar, você precisará manter logging estruturado e rastreabilidade. Se houver um incidente, a LGPD exige que você prove como tratou os dados e quando detectou o problema.

Gateways brasileiros com APIs PCI DSS compliant

No Brasil, os principais gateways de pagamento já oferecem SDKs e APIs compatíveis com PCI DSS. Alguns exemplos:

Pagar.me (do grupo Stone): SDKs em várias linguagens, coleta de cartão direto no navegador via checkout.js.
Cielo: APIs REST, soluções como Cielo e-commerce e Cielo Checkout com tokenização.
Rede (Itaú): APIs com suporte a captura e tokenização de cartões.

Checklist prático dos itens que os times de desenvolvimento devem garantir

Nunca armazene o CVV após a autorização, preferencialmente nem trafegue essa informação para o seu servidor e utilize tokenização diretamente no navegador do cliente.
Use tokenização (token irreversível) quando possível - o token também não deve permitir derivar o PAN.
HTTPS/TLS 1.2+ em todas as comunicações; rejeitar protocolos e ciphers obsoletos.
Criptografia de ponta a ponta (E2EE): se necessário, considere criptografar campos sensíveis (como PAN) no front-end antes do envio, garantindo que apenas o back-end ou gateway autorizado possa descriptografar (via public/private key ou mecanismo seguro fornecido pelo gateway).
Segmentar a rede: isolar o Cardholder Data Environment (CDE) para reduzir escopo, quando aplicável.
MFA para acesso administrativo e para acesso a ambientes que contenham CDE, quando aplicável.
Scans trimestrais (ASV) para perímetros externos e pentests anuais + após mudanças significativas.
Não registrar PAN/CVV em logs, stacks de erro, analytics, screenshots ou backups.
Contratos com gateways/serviços devem requerer AoC/ROC e evidências de conformidade.
Rastreabilidade: manter logs de acesso/alteração com retenção suficiente para auditoria.
Treinamento: time de dev/ops precisa entender o que configura exposição de cartão (ex.: inserir string de cartão em um campo exposto = risco).

Conclusão

O PCI DSS não é apenas para bancos e grandes processadores. Mesmo aplicações menores precisam conhecer e respeitar os conceitos, já que qualquer integração com um gateway de pagamento PCI DSS compliant exige responsabilidade na manipulação de dados.

E no Brasil, não se trata apenas de boas práticas técnicas. A LGPD adiciona uma camada legal, responsabilizando empresas por qualquer incidente de segurança da informação que exponha dados pessoais. Isso significa que, além de comprometer a confiança do cliente, uma falha pode trazer multas e sanções regulatórias sérias.

Conhecer PCI DSS e LGPD antes de escrever a primeira linha de código é um investimento que reduz riscos, evita retrabalho e garante que seu sistema não se torne o elo fraco na cadeia de pagamentos.

Você já integrou algum gateway e percebeu a diferença entre manipular cartão de forma aberta e usar tokenização direta? Essa decisão pode mudar completamente o escopo técnico e a responsabilidade legal do seu sistema.