PCI-DSS — Segurança de Dados do Cartão

O que é PCI DSS e para quem se aplica

PCI DSS é um padrão criado pelas principais bandeiras (Visa, Mastercard, American Express, Discover, JCB) para proteger dados de portadores de cartão. Se sua empresa toca dados de cartão de qualquer forma — mesmo que seja só repassar para um gateway — você está no escopo.

No escopo PCI DSS:
  - Lojistas que aceitam cartão (físico ou online)
  - Processadoras de pagamento
  - Bancos emissores e adquirentes
  - Gateways de pagamento
  - Provedores de serviço que armazenam/processam CHD

Dados protegidos (CHD — Cardholder Data):
  - PAN (Primary Account Number) — número do cartão
  - Nome do portador
  - Data de expiração
  - Código de serviço

Dados de autenticação sensível (SAD — nunca armazenar após autorização):
  - CVV/CVC/CID (código de segurança)
  - Dados completos da tarja magnética
  - PIN e PIN blocks

Os 12 Requisitos PCI DSS v4.0

CONSTRUIR E MANTER REDE SEGURA:
  1. Instalar e manter controles de segurança de rede
     - Firewall configurado, regras documentadas
     - Segmentar o CDE (Cardholder Data Environment)

  2. Não usar padrões fornecidos pelo fornecedor
     - Trocar TODAS as senhas padrão
     - Configuração hardened em todos os componentes

PROTEGER DADOS DO PORTADOR:
  3. Proteger dados armazenados do portador
     - Não armazenar SAD após autorização
     - Criptografar PAN se armazenado (AES-256)
     - Mascarar PAN em displays (mostrar só últimos 4 dígitos)
     - Inventário de locais onde PAN é armazenado

  4. Proteger dados em transmissão em redes abertas
     - TLS 1.2 ou 1.3 (desabilitar SSL, TLS 1.0, 1.1)
     - Certificados válidos e confiáveis
     - Nunca transmitir PAN não criptografado

PROGRAMA DE GESTÃO DE VULNERABILIDADES:
  5. Proteger todos os sistemas contra malware
     - Antimalware em todos os componentes
     - Anti-phishing
     - Revisão periódica de sistemas sem antimalware

  6. Desenvolver e manter sistemas e software seguros
     - Patches críticos em 30 dias, outros em 90 dias
     - Desenvolvimento seguro (OWASP, SAST, DAST)
     - WAF para aplicações web públicas
     - NOVO v4.0: gerenciar scripts em páginas de pagamento

IMPLEMENTAR CONTROLES DE ACESSO FORTE:
  7. Restringir acesso a componentes por necessidade
     - Least privilege
     - Controle de acesso baseado em função (RBAC)

  8. Identificar e autenticar acesso a componentes
     - ID único para cada usuário
     - MFA obrigatório para todo acesso ao CDE
     - MFA para todo acesso administrativo remoto
     - Senhas mínimo 12 caracteres (v4.0)

  9. Restringir acesso físico a dados do portador
     - Controle de entrada física ao CDE
     - Câmeras em áreas de acesso
     - Proteção de dispositivos de POS

MONITORAR E TESTAR REDES:
  10. Registrar e monitorar todo acesso a recursos da rede
      - Logs de todos os componentes do CDE
      - Retenção: 12 meses (3 meses imediatamente disponíveis)
      - SIEM para correlação de eventos
      - NOVO v4.0: monitoramento automatizado de anomalias

  11. Testar segurança de sistemas e redes regularmente
      - Scan de vulnerabilidades ASV trimestralmente
      - Pentest anual (rede e aplicação)
      - Detecção de pontos de acesso sem fio
      - File integrity monitoring no CDE

MANTER POLÍTICA DE SEGURANÇA:
  12. Apoiar segurança com políticas e programas
      - Política de segurança da informação
      - Programa de conscientização anual
      - Gestão de risco documentada
      - Gestão de provedores de serviço terceiros

Níveis de Conformidade e SAQ

Nível 1: > 6 milhões de transações/ano
  - Auditoria por QSA (Qualified Security Assessor) anual
  - ROC (Report on Compliance)
  - Scan ASV trimestral

Nível 2: 1-6 milhões de transações/ano
  - SAQ anual ou auditoria QSA
  - Scan ASV trimestral

Nível 3: 20.000-1.000.000 transações online/ano
  - SAQ anual
  - Scan ASV trimestral

Nível 4: < 20.000 transações online ou < 1M outras
  - SAQ anual (recomendado)
  - Scan ASV trimestral (recomendado)

SAQ — Self-Assessment Questionnaire (tipos):
  SAQ A:    e-commerce que terceiriza processamento totalmente
             Iframe do gateway / redirect total
  SAQ A-EP: e-commerce com scripts no site que afetam pagamento
  SAQ B:    terminais físicos sem armazenamento eletrônico
  SAQ C:    sistemas com aplicação de pagamento conectada à internet
  SAQ D:    todos os outros lojistas
  SAQ D-SP: provedores de serviço

Reduzir Escopo — Estratégias Chave

TOKENIZAÇÃO:
  Substituir PAN por token não sensível
  Token gerado pelo gateway — só ele pode reverter
  PAN nunca entra nos sistemas do lojista
  Reduz escopo drasticamente

P2PE — Point-to-Point Encryption:
  Dispositivo de pagamento criptografa imediatamente
  PAN nunca viaja em claro pela rede do lojista
  Solução P2PE validada = redução máxima de escopo

CHAMADA DIRETA AO GATEWAY:
  JavaScript do gateway captura dados diretamente
  Dados vão do browser → gateway (nunca → servidor lojista)
  Ex: Stripe.js, Checkout.com, PagSeguro

SEGMENTAÇÃO DE REDE:
  CDE (sistemas que tocam dados de cartão) isolado
  Firewall entre CDE e resto da rede
  Validar segmentação com pentest anual
  Sem segmentação = toda a rede está no escopo

NOVO — Requisitos v4.0 (2024)

Req 6.4.3 — Scripts em páginas de pagamento:
  Inventário de todos os scripts em páginas de checkout
  Método para confirmar integridade de cada script
  Justificativa documentada para cada script presente
  Prevenção contra Magecart / skimming de cartão

Req 8.3.6 — Complexidade de senha:
  Mínimo 12 caracteres (era 7)
  Se não suportar 12: mínimo 8 com complexidade

Req 8.4.2 — MFA para todos os acessos ao CDE:
  Não só acesso remoto — TODO acesso
  Inclui acessos de dentro da rede

Req 10.7 — Falhas em controles críticos:
  Detectar e reportar falhas em:
  - Controles de segurança críticos
  - Firewalls, IDS, FIM, antimalware, audit logging
  - Prazo de resposta para falhas críticas: 15 dias

Customized Approach (novo em v4.0):
  Alternativa a controles prescritivos
  Definir controle customizado que atinge o objetivo
  Documentar e validar com QSA

Magecart — Ameaça Principal para E-commerce

-- Ataque de skimming de cartão via JavaScript
-- Injetar código malicioso em página de checkout
-- Capturar dados digitados antes de enviar ao gateway

-- Vetores de injeção:
-- Comprometer o CMS (WordPress, Magento, PrestaShop)
-- Comprometer biblioteca JavaScript de terceiro
-- Supply chain: biblioteca legítima comprometida

-- Casos reais:
-- British Airways (2018): 500k clientes, multa £20M
-- Ticketmaster (2018): 9.4M clientes
-- Magento: centenas de lojas simultâneas

-- Defesa:
-- CSP (Content-Security-Policy) com hash/nonce dos scripts
-- Inventário e integridade de scripts (Req 6.4.3 v4.0)
-- Subresource Integrity (SRI) em scripts externos
-- Monitoramento de mudanças em páginas de checkout
-- Solução P2PE ou tokenização total

Penalidades por Não Conformidade

• Multas das bandeiras — US$5.000 a US$100.000 por mês até conformidade
• Perda do direito de aceitar cartões — a penalidade mais grave para e-commerce
• Custo pós-breach — em caso de vazamento: forense obrigatória, notificação de titulares, monitoria de crédito = média de US$3.86M por incidente
• Responsabilidade de chargebacks — lojistas não conformes assumem 100% dos chargebacks fraudulentos