PCI-DSS (Pagamentos)

O PCI-DSS, Payment Card Industry Data Security Standard, é o padrão de segurança imposto pelas bandeiras de cartão para qualquer sistema que armazene, processe ou transmita dados de titularidade de cartão, os dados do titular do cartão, o CHD. Diferente de leis de proteção de dados, o PCI-DSS nasce de contrato entre redes de cartão, adquirentes e comerciantes, e o descumprimento custa multas, perda de capacidade de aceitar cartão e responsabilidade ampliada em caso de vazamento. Para a arquitetura, o padrão é famoso pela exigência mais dura do ecossistema: os dados de autenticação sensíveis do cartão não podem ser armazenados de forma alguma, nem cifrados. A forma profissional de cumprir o PCI-DSS é reduzir escopo: tocar o mínimo possível de dados de cartão, em um ambiente isolado e pequeno, com o resto do sistema operando apenas com tokens. Este arquivo cobre escopo, os 12 requisitos, regras de armazenamento, tokenização, segmentação, validação e as implicações arquiteturais diretas.

Conceito e escopo do padrão

O escopo do PCI-DSS é definido pelo ambiente de dados do titular do cartão, o CDE, Cardholder Data Environment: todo sistema, rede, aplicação, pessoa e processo que toca dado de cartão. O padrão aplica-se a essa fronteira, e o esforço de conformidade é proporcional ao tamanho do CDE, não ao tamanho da empresa. O dado que define o CDE é o PAN, o Primary Account Number, o número do cartão; qualquer componente que veja, processe ou decifre PAN entra no escopo integralmente. A versão vigente, a 4.0 com revisão 4.0.1, elevou exigências de autenticação, monitoramento e ciberseturança, com prazos de transição já vencidos para a maioria dos requisitos.

A validação é dividida por volume de transações e modelo do comerciante. Níveis maiores são auditados por QSA, Qualified Security Assessor, com relatório ROC, Report on Compliance; níveis menores se autodeclaram por questionários SAQ, Self-Assessment Questionnaire, com variantes cujo conteúdo varia conforme o modelo de integração. Todos os níveis precisam também de varredura externa trimestral por ASV, Approved Scanning Vendor, sobre endereços expostos à internet.

Os 12 requisitos principais

Os requisitos do PCI-DSS se organizam em seis grupos de objetivo, cobrindo do perímetro de rede até a governança documental.

Cada requisito tem subcontroles com critérios de teste objetivos, e a auditoria caminha exatamente por essa estrutura: o auditor escolhe amostras, pede evidência e testa. Os requisitos com maior impacto arquitetural são o 3, que restringe armazenamento de dado de cartão, o 4, que exige cifragem em trânsito em redes públicas, e o 10, que obriga logging completo com trilha de auditoria dentro do CDE.

O que pode e o que não pode ser armazenado

A regra de armazenamento é o coração técnico do padrão e divide os dados do cartão em duas categorias com tratamento radicalmente diferente. O PAN pode ser armazenado desde que ilegível, com cifragem forte, truncamento ou hash; os dados de autenticação sensíveis, o código de verificação, o CVV ou CVC, o dado completo da trilha magnética e o PIN, não podem ser armazenados após a autorização, sem exceção, nem cifrados.

O requisito de máscara na exibição limita a leitura de PAN em interface a no máximo os seis primeiros e quatro últimos dígitos, e o acesso a PAN completo fica restrito a papéis justificados. Em código, a consequência é direta: serializers, logs, caches e mensagens de erro não podem carregar PAN sem proteção, e a detecção de PAN em campos inesperados entra na esteira com varredura de dados sensíveis.

Tokenização e redução de escopo

Tokenização substitui o PAN por token sem valor, gerado por um serviço que guarda a relação token e PAN dentro do CDE, em um cofre isolado. O resto do sistema, pedidos, CRM, analytics, suporte, opera apenas com token, e por isso sai do escopo, porque nunca vê dado de cartão. A redução de escopo é o argumento econômico central do PCI-DSS: cada componente dentro do CDE paga o custo em controles, logging, teste e auditoria, e encolher o CDE é mais barato que blindar tudo. O caminho máximo de redução é não receber PAN em absoluto, com campos hospedados ou redirecionamento do gateway, em que o navegador do cliente fala direto com o provedor de pagamento e o comerciante chega ao nível de SAQ mais leve.

{
  "requisicao": {
    "token": "tok_1a2b3c4d5e6f",        // PAN nunca chega ao serviço de pedidos
    "valor_centavos": 12990,
    "moeda": "BRL"
  },
  "resposta": {
    "status": "autorizado",
    "codigo_autorizacao": "AUTH-90210",
    "cartao_mascarado": "**** **** **** 4242"   // Apenas máscara, sem PAN
  }
}

O desenho do serviço tokenizador é decisão arquitetural de alto risco, e três propriedades são obrigatórias: o cofre token e PAN vive em ambiente isolado, com rede restrita e acesso auditado; a destokenização, o caminho de volta para o PAN, existe apenas para fluxos que de fato precisam, como cobrança recorrente no adquirente; e a rotação de token por contexto, como token por assinatura, reduz o valor do token vazado. Gateways e adquirentes oferecem tokenização gerenciada, e usá-la transfere a maior parte do CDE para fornecedor especializado, o que costuma ser a decisão correta.

Segmentação de rede

A segmentação não é obrigatória pelo texto do padrão, mas é o mecanismo prático que separa o CDE do resto da rede, e auditoria assume que sem segmentação toda a rede entra no escopo. Os métodos aceitos incluem firewalls com regras explícitas, sub-redes isoladas, VLANs e grupos de segurança, com o princípio de negar por padrão e permitir por exceção documentada. Dentro do desenho, o CDE não fala direto com a internet, o tráfego entre CDE e o resto da rede passa por pontos controlados, e cada regra de firewall tem justificativa ligada a um fluxo de negócio documentado.

# Grupo de segurança do serviço tokenizador: negar por padrão
resource "aws_security_group" "tokenizador" {
  name   = "cde-tokenizador"
  vpc_id = aws_vpc.cde.id

  # Ingresso apenas do serviço de checkout, na porta do protocolo interno
  ingress {
    from_port       = 8443
    to_port         = 8443
    protocol        = "tcp"
    security_groups = [aws_security_group.checkout.id]
  }

  # Saída apenas para o cofre de chaves e para o adquirente
  egress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = [var.cidr_adquirente, var.cidr_kms]
  }
}

A segmentação precisa ser testada: o padrão exige teste de penetração de segmentação em cadência definida, provando que o CDE é inalcançável a partir de redes fora dele. O teste vale mais que o diagrama, porque diagrama desatualizado é a justificativa mais comum para achado de auditoria em ambiente com fluxo que ninguém lembra ter aberto.

Criptografia de PAN e gestão de chaves

Quando o armazenamento de PAN é inevitável, o padrão exige criptografia forte, com algoritmo reconhecido, chave gerida fora do sistema que cifra e controles de acesso à chave separados do acesso ao dado. Na prática, a implementação usa KMS ou HSM com envelope encryption, como coberto nos arquivos de criptografia em repouso e de gerenciamento de chaves, e o requisito específico do PCI é a governança: quem pode usar a chave não é quem acessa a tabela, a rotação é documentada e a trilha de uso existe. Hash e truncamento entram como mecanismos complementares, com hash e sal para lookup por PAN sem armazenar o número, e truncamento para exibição e referência humana.

Em trânsito, o PAN deve ser cifrado em qualquer rede pública, com TLS forte conforme os requisitos de cifra do padrão, e a transmissão interna dentro do CDE também deve ser avaliada, porque tráfego plano dentro do escopo amplia exposição. O requisito de não armazenar dado sensível de autenticação após autorização vale inclusive para logs, snapshots e réplicas: o ambiente que viola isso falha no requisito 3 independente de quão bem cifrou o resto.

Validação: QSA, ASV e SAQ

O sistema de validação combina três instrumentos, e conhecê-los evita planejar o ciclo errado.

A variante do SAQ depende do modelo de integração de pagamento: quem não toca dado de cartão, usando iframe ou redirecionamento completo do provedor, chega ao questionário mais enxuto; quem roda CDE próprio, com armazenamento de PAN, cai no questionário integral, o mais pesado do conjunto. A implicação direta para o time de produto é que a decisão de como integrar o gateway define o questionário por anos, e vale tratá-la como decisão arquitetural de longo prazo.

Implicações arquiteturais

O desenho arquitetural de um ambiente de pagamento maduro segue o princípio do CDE mínimo: um serviço de pagamento isolado, em conta ou VPC própria, que é o único componente que toca PAN; um serviço tokenizador que devolve tokens para o resto do domínio; integração com gateway ou adquirente que absorve a autorização; e nenhuma rota direta da internet ao CDE. Logs de todos os componentes do CDE vão para armazenamento central com acesso restrito e trilha imutável, porque o requisito 10 exige correlação de eventos dentro do escopo. Mudanças no CDE passam por processo formal com avaliação de impacto no escopo, porque um novo campo de log com PAN reabre achado que levaria meses para sanar.

A conta isolada tem efeito colateral positivo: limita o raio de erro de IAM, evita que credenciais de outros domínios alcancem dados de cartão e cria fronteira natural de faturamento e alarme. Quem opera com prestador de serviços de pagamento precisa ainda gerir o programa do fornecedor, com due diligence, responsabilidade em contrato e verificação anual, porque a responsabilidade perante as bandeiras permanece do comerciante ou prestador que contratou.

Erros comuns

• Armazenar CVV "só por garantia" de retentativa: dado sensível de autenticação não pode ser armazenado de forma alguma.
• Logar PAN em middleware, gateway ou APM: o log entra no escopo e transforma componentes em sistemas de cartão.
• Manter PAN em planilhas, exports e ambientes de teste fora do controle do padrão: achado recorrente e de correção caríssima.
• Cifrar PAN com chave no mesmo sistema que acessa o dado: a gestão de chave precisa ser separada do acesso ao dado.
• Expandir o CDE por conveniência, colocando serviços gerais dentro do escopo: cada componente novo custa controles permanentes.
• Deixar varreduras ASV falharem por endereços esquecidos, como VPN exposta e painel administrativo público.
• Tratar o teste de segmentação como formalidade: fluxo aberto entre redes anula a redução de escopo declarada.

Boas práticas

• Reduzir escopo primeiro: tokenização com cofre isolado, ou campos hospedados do gateway, antes de investir em blindar um CDE grande.
• Isolar o ambiente de pagamento em conta e VPC próprias, com rede restrita, egresso controlado e conta dedicada de IAM.
• Centralizar logging do CDE com retenção e trilha protegidas, alimentando detecção de acesso anômalo aos dados de cartão.
• Proibir PAN e dado sensível por política de código, com varredura automatizada de dados sensíveis em código, log e repositório.
• Documentar todo fluxo de rede do CDE com justificativa, e revisar o diagrama em cada mudança, já que o auditor testa contra a realidade.
• Rodar varreduras ASV trimestrais com calendário fixo e plano de correção antes da janela oficial.
• Tratar mudança no CDE como mudança de escopo, com avaliação de impacto no programa de conformidade no design review.