Conformidade com PCI DSS para comércio eletrônico: Guia de segurança de pagamento

Cada transação de comércio eletrônico que envolve um cartão de pagamento cria uma obrigação de conformidade sob o PCI DSS – o padrão de segurança de dados da indústria de cartões de pagamento. O não cumprimento não é um risco teórico: as bandeiras de cartões (Visa, Mastercard, Amex) podem cobrar multas de US$ 5.000 a US$ 100.000 por mês aos bancos adquirentes, que repassam a responsabilidade diretamente aos comerciantes por meio de seus acordos de processamento de pagamentos. Após uma violação, os comerciantes não conformes enfrentam multas de US$ 50 a US$ 90 por cartão comprometido, custos de investigação forense da marca do cartão e – nos casos mais graves – encerramento de sua conta de comerciante.

O PCI DSS v4.0, lançado em março de 2022 com conformidade obrigatória a partir de março de 2025, introduziu mudanças significativas nos requisitos criptográficos, nos padrões de autenticação e no tratamento de scripts nas páginas de pagamento. Este guia fornece às equipes de comércio eletrônico um roteiro de implementação completo.

Principais conclusões

• PCI DSS v4.0 é obrigatório a partir de 31 de março de 2025 — todos os comerciantes de comércio eletrônico devem estar em conformidade com a nova versão
• A definição do escopo é o primeiro passo mais crítico: reduza o ambiente de dados do titular do cartão (CDE) tanto quanto possível
• Usar uma página de pagamento hospedada por um processador de pagamento (Stripe, Braintree, Adyen) reduz drasticamente o escopo
• O SAQ A aplica-se à maioria dos comerciantes com páginas de pagamento hospedadas, mas somente se nenhum dado do titular do cartão chegar aos seus servidores
• Os novos requisitos da versão 4.0 incluem MFA para todos os acessos CDE, controles de integridade de script em páginas de pagamento e análise de risco direcionada
• Web skimming (ataques Magecart) é abordado pelo novo Requisito 6.4.3 no inventário de script de página de pagamento
• Os testes de penetração anuais e as verificações de vulnerabilidade trimestrais permanecem obrigatórios
• As penalidades por não conformidade são repassadas das bandeiras de cartão → bancos adquirentes → comerciantes

---

Fundamentos da estrutura PCI DSS

O PCI DSS é mantido pelo Payment Card Industry Security Standards Council (PCI SSC), um órgão fundado pela American Express, Discover, JCB, Mastercard e Visa. O padrão atual é PCI DSS v4.0.

O padrão está organizado em 12 requisitos em 6 objetivos:

A conformidade se aplica a qualquer entidade que armazene, processe ou transmita dados do titular do cartão — ou que possa afetar a segurança dos dados do titular do cartão. Isso inclui comerciantes, processadores de pagamento, adquirentes, emissores e prestadores de serviços.

---

Etapa 1 — Defina e reduza seu escopo

O ambiente de dados do titular do cartão (CDE) é qualquer sistema que armazena, processa ou transmite dados do titular do cartão (CHD) ou dados de autenticação confidenciais (SAD). Minimizar o escopo é a etapa mais impactante que você pode realizar.

Dados do titular do cartão versus dados de autenticação confidenciais:

Estratégias de redução de escopo para comércio eletrônico:

1. Use uma página de pagamento hospedada: redirecione os clientes para a página de pagamento hospedada do seu processador de pagamento (Stripe Checkout, Braintree Hosted Fields, Adyen Drop-in). Nenhum dado do titular do cartão chega aos seus servidores e você se qualifica para o SAQ A — o questionário de autoavaliação mais simples.

2. Tokenização: Substitua os números dos cartões por tokens gerados pelo processador imediatamente após a autorização. Armazene apenas o token, que é inútil para invasores sem acesso ao cofre de tokenização do processador.

3. Formulários de pagamento baseados em iFrame: incorpore o formulário renderizado em JavaScript do processador de pagamento em sua página de checkout. Os dados do cartão são inseridos diretamente em um formulário hospedado no domínio do processador, não no seu.

4. Segmentação de rede: Isole sistemas CDE (servidores de processamento de pagamentos, bancos de dados) de sistemas fora do escopo usando firewalls. Redes adequadamente segmentadas reduzem drasticamente o escopo da auditoria.

---

Etapa 2 — Identifique seu tipo de SAQ

O Questionário de Autoavaliação (SAQ) é uma ferramenta de validação para comerciantes e prestadores de serviços que não exigem uma avaliação no local de um Avaliador de Segurança Qualificado (QSA). O tipo de SAQ é determinado pela forma como você aceita pagamentos:

SAQ A — Aplicável a comerciantes sem cartão presente (comércio eletrônico) que terceirizam totalmente o processamento de pagamentos para terceiros em conformidade com PCI DSS. Nenhum dado eletrônico do titular do cartão é armazenado, processado ou transmitido em seus sistemas ou instalações. Sua página de pagamento é entregue inteiramente pelo seu processador de pagamentos. Aproximadamente 22 requisitos.

SAQ A-EP — Para comerciantes de comércio eletrônico que terceirizam parcialmente o processamento de pagamentos, mas ainda têm uma página de pagamento hospedada em seu próprio servidor, que incorpora um iframe de pagamento de terceiros. Seu servidor web afeta indiretamente a segurança do processamento de pagamentos. Mais requisitos que o SAQ A. Criticamente afetado pelo novo Requisito v4.0 6.4.3.

SAQ D — Para estabelecimentos comerciais que não atendem aos critérios de nenhum outro tipo de SAQ ou que armazenam dados do titular do cartão. Abrange todos os 12 requisitos. Obrigatório para comerciantes que executam sua própria infraestrutura de processamento de pagamentos. Normalmente cerca de 300+ subrequisitos.

Níveis de nível (padrão Mastercard/Visa):

---

Etapa 3 — Principais alterações do PCI DSS v4.0 para comércio eletrônico

O PCI DSS v4.0 introduziu vários requisitos que afetam especificamente os comerciantes de comércio eletrônico. Todas eram obrigatórias a partir de 31 de março de 2025.

Requisito 6.4.3 — Gerenciamento de script da página de pagamento

Este requisito visa diretamente ataques Magecart/web skimming – onde os invasores injetam JavaScript malicioso em páginas de pagamento de comércio eletrônico para roubar dados do titular do cartão em tempo real. De acordo com 6.4.3, os comerciantes que usam SAQ A-EP ou superior devem:

• Manter um inventário de todos os scripts autorizados a serem executados nas páginas de pagamento
• Justificar a necessidade comercial ou técnica de cada script
• Implementar um método para confirmar a integridade de cada script (hashes de integridade de sub-recursos para scripts de terceiros ou diretivas de política de segurança de conteúdo)

Para comerciantes SAQ A com uma página de pagamento totalmente terceirizada, este requisito se aplica às páginas do seu processador de pagamento – eles devem demonstrar conformidade em seu nome.

Requisito 11.6.1 — Detecção de alterações e adulterações em páginas de pagamento

Os comerciantes devem implantar um mecanismo (por exemplo, Política de Segurança de Conteúdo, serviço de monitoramento de script) para detectar modificações não autorizadas em cabeçalhos HTTP e conteúdos de script em páginas de pagamento. Os alertas devem ser gerados no prazo de 7 dias após quaisquer alterações não aprovadas.

Requisito 8.4.2 — MFA para todo acesso ao CDE

A autenticação multifator agora é necessária para todas as contas de usuário com acesso ao CDE – não apenas para acesso remoto. Isto inclui usuários internos que acessam sistemas de pagamento de produção dentro da rede corporativa.

Requisito 3.3.1.1 — O SAD não pode ser retido após autorização

Proíbe explicitamente o armazenamento de dados de autenticação confidenciais (dados completos de rastreamento, CVV, PIN) após autorização. Isso sempre foi proibido, mas agora é formulado com mais precisão para fechar lacunas na forma como alguns sistemas registravam o SAD nas saídas de depuração/diagnóstico.

Análise de Risco Direcionada (TRA)

A v4.0 introduz o conceito de Análise de Risco Direcionada — os comerciantes podem demonstrar abordagens alternativas para alguns requisitos se realizarem uma análise de risco documentada mostrando proteção equivalente. Isso fornece flexibilidade para ambientes maiores e mais complexos.

---

Etapa 4 — Arquitetura de segurança de rede

Para comerciantes com sistemas com escopo além do SAQ A, a segurança da rede é um domínio central de conformidade.

Requisito 1 — Instalar e manter controles de segurança de rede:

• Implementar um firewall entre redes não confiáveis (internet) e o CDE
• Implementar firewall entre CDE e outras redes internas (segmentação)
• Documente todas as regras de firewall com justificativa comercial
• Revise as regras de firewall pelo menos a cada 6 meses
• Negar todo o tráfego não explicitamente exigido (postura de negação padrão)
• Para comércio eletrônico: implemente WAF (Web Application Firewall) na frente de servidores web

Teste de segmentação de rede:

Um equívoco comum é que a segmentação da rede reduz o escopo automaticamente. O PCI SSC exige que você teste se a segmentação é eficaz – os testes de penetração devem incluir tentativas de cruzar os limites da segmentação. Se um testador de penetração puder alcançar sistemas CDE a partir de redes fora do escopo, a segmentação não será eficaz e o ambiente mais amplo entrará no escopo.

Arquitetura DMZ para comércio eletrônico:

Internet → WAF/Load Balancer → DMZ (Web Servers) → Internal Firewall → CDE (Payment Servers, DB) → Internal Network

Os servidores Web na DMZ atendem à sua loja. Somente tráfego específico e documentado (HTTPS para API de pagamento, SQL em porta específica para banco de dados específico) passa de DMZ para CDE. Todo o outro tráfego está bloqueado.

---

Etapa 5 — Requisitos de segurança do aplicativo

Requisito 6 — Desenvolver e manter sistemas e software seguros:

• Manter um inventário de todos os softwares personalizados e de terceiros no escopo
• Abordar vulnerabilidades como parte de um processo formal de gerenciamento de vulnerabilidades
• Proteja aplicativos voltados para a Web contra ataques conhecidos (OWASP Top 10)
• Realizar revisões de código de segurança ou testes de penetração de aplicativos antes da implantação em produção de mudanças significativas
• Use apenas software de fornecedores confiáveis com processos de patch de segurança comprometidos

Firewall de aplicativo Web (WAF) — Requisito 6.3.2 e 6.4.2:

O WAF é obrigatório para todos os aplicativos da web voltados ao público, configurados para bloquear ataques ou gerar alertas e revisão dentro de 1 hora. Para comércio eletrônico, o WAF deve cobrir:

• Prevenção de injeção SQL
• Proteção de script entre sites (XSS)
• Proteção contra falsificação de solicitação entre sites (CSRF)
• Detecção de bot malicioso
• Limitação de taxa para prevenção de força bruta

Gerenciamento de dependências e software de terceiros:

As plataformas de comércio eletrônico (personalizações WooCommerce, Magento, Shopify) dependem fortemente de plug-ins e extensões. Cada plugin no escopo deve ser avaliado quanto à segurança. Mantenha um inventário e aplique patches dentro do seu SLA de patches (crítico: 7 dias a partir do lançamento do patch do fornecedor).

---

Etapa 6 — Controle de acesso e autenticação

Requisito 7 — Restringir o acesso aos componentes do sistema e aos dados do titular do cartão:

• Implementar controle de acesso baseado em função com base no menor privilégio
• Padrão de todo o acesso para "negar tudo" com concessões explícitas documentadas
• Revise os direitos de acesso do usuário pelo menos a cada 6 meses

Requisito 8 — Identificar usuários e autenticar o acesso:

• Atribuir um ID único a cada pessoa com acesso ao CDE
• Senhas com mínimo de 12 caracteres (v4.0 aumenta de 7 na v3.2.1), requisitos de complexidade
• Bloquear contas após no máximo 10 tentativas inválidas (padrão v4.0 ou por TRA)
• Tempo limite da sessão após no máximo 15 minutos de inatividade para sessões CDE
• MFA necessário para todos os acessos CDE (expansão v4.0 somente remota)
• Contas de serviço e contas de sistema devem ser gerenciadas separadamente das contas de usuário

---

Etapa 7 — Gerenciamento e teste de vulnerabilidades

Requisito 11 — Testar a segurança de sistemas e redes:

Verificações trimestrais de vulnerabilidades internas: verifica todos os sistemas no escopo. Corrija todas as vulnerabilidades críticas e de alta gravidade antes da próxima verificação. As varreduras podem ser realizadas por equipe interna usando ferramentas aprovadas (Nessus, Qualys, OpenVAS).

Verificações trimestrais de vulnerabilidades externas por um fornecedor de verificação aprovado (ASV): verificações externas de todos os sistemas acessíveis externamente devem ser conduzidas por um ASV aprovado pelo PCI SSC. A verificação deve ser aprovada (sem vulnerabilidades altas/críticas abertas) antes que você possa atestar a conformidade.

Testes de penetração anuais: conduzidos por um recurso interno qualificado ou por uma empresa externa confiável. Deve cobrir:

• Todos os sistemas e redes no escopo
• Controles de segmentação (verifique se o CDE está devidamente isolado)
• OWASP Top 10 para aplicativos voltados para a web
• Engenharia social (para ambientes de maior risco)

Corrija todas as descobertas dos testes de penetração e realize testes de verificação para confirmar a correção.

Monitoramento de integridade de arquivos (FIM): implante o FIM em todos os arquivos críticos do sistema, arquivos de configuração e arquivos de conteúdo. Alerta dentro de 1 hora (v4.0) sobre quaisquer alterações não autorizadas.

---

Lista de verificação de conformidade do PCI DSS para comércio eletrônico

• [] Escopo de processamento de pagamento definido e reduzido (página de pagamento hospedada ou tokenização usada sempre que possível)
• [] Tipo de SAQ identificado com base no método de aceitação de pagamento
• [] Segmentação de rede implementada e documentada
• [] Inventário de dados do titular do cartão concluído - nenhum SAD armazenado em qualquer lugar
• [] Todo o armazenamento de dados do titular do cartão é criptografado (AES-256 ou equivalente)
• [] TLS 1.2+ aplicado para todas as transmissões de dados de pagamento
• [] Inventário de script de página de pagamento documentado (Requisito 6.4.3)
• [] Detecção de alteração/violação implantada em páginas de pagamento (Requisito 11.6.1)
• [] WAF implantado na frente de todos os aplicativos da web voltados ao público
• MFA aplicada para todos os acessos CDE (Requisito 8.4.2)
• [] IDs de usuário exclusivos, senhas fortes, bloqueio de conta configurado
• [] Varreduras de vulnerabilidade trimestrais (internas + ASV externas) concluídas
• [] Teste de penetração anual concluído, descobertas corrigidas
• [] Monitoramento de integridade de arquivos implantado em sistemas CDE
• [] Regras de firewall revisadas nos últimos 6 meses
• [] Treinamento de conscientização de segurança concluído para todos os funcionários envolvidos no CDE
• [] O plano de resposta a incidentes cobre cenários de violação de cartão de pagamento
• [] Conformidade do fornecedor/provedor de serviços com PCI DSS verificada

---

Perguntas frequentes

Usamos o Shopify em nossa loja. Ainda precisamos de conformidade com o PCI DSS?

Shopify é um provedor de serviços certificado PCI DSS Nível 1. Se você usar o processamento de pagamento padrão do Shopify (Shopify Payments ou checkout hospedado pelo Shopify), seu escopo de conformidade será drasticamente reduzido. Você ainda tem obrigações — principalmente SAQ A — que cobrem o uso dos serviços da Shopify. Se você adicionar JavaScript personalizado ao checkout do Shopify ou usar aplicativos de pagamento de terceiros que processam dados de cartão fora do ambiente do Shopify, o escopo se expande.

Qual é a diferença entre conformidade com PCI DSS e certificação PCI DSS?

Não existe uma “certificação PCI DSS” formal para comerciantes. Os comerciantes atestam a conformidade por meio de questionários de autoavaliação ou (comerciantes de nível 1) por meio de um relatório de conformidade (RoC) conduzido por um QSA. Os prestadores de serviços podem ser listados no Registro Global de Provedores de Serviços da Visa. Os termos “certificado” e “conforme” são frequentemente usados ​​indistintamente nas comunicações de mercado, mas tecnicamente os comerciantes auto-atestam ou têm conformidade atestada pelo QSA.

Quais penalidades os comerciantes enfrentam por não conformidade?

As penalidades não vêm diretamente do PCI SSC – elas fluem das bandeiras de cartão até os bancos adquirentes. As multas mensais normalmente variam de US$ 5.000 a US$ 100.000, dependendo do nível do comerciante e da duração da não conformidade. Após uma violação, as marcas de cartão podem impor multas por cartão (US$ 50 a US$ 90 por cartão Visa, semelhante para Mastercard), custos de investigação forense (US$ 20.000 a US$ 200.000 ou mais) e custos obrigatórios de reemissão de cartão. Em casos graves, os comerciantes perdem totalmente a capacidade de aceitar pagamentos com cartão. Ofensores reincidentes ou comerciantes com grandes impactos de violação enfrentam as penalidades mais altas.

O que é um ataque Magecart e como o PCI DSS v4.0 resolve isso?

Magecart refere-se a ataques em que JavaScript malicioso é injetado em páginas de checkout de comércio eletrônico para interceptar os dados do titular do cartão em tempo real enquanto os clientes os digitam. Esses ataques exploram scripts de terceiros (análises, widgets de chat, gerenciadores de tags) que os comerciantes incluem nas páginas de pagamento. Os requisitos 6.4.3 e 11.6.1 do PCI DSS v4.0 abordam diretamente isso: os comerciantes devem inventariar e verificar a integridade de todos os scripts nas páginas de pagamento e implantar monitoramento para detectar alterações não autorizadas no código da página de pagamento.

Como lidamos com o PCI DSS para uma arquitetura de comércio eletrônico headless?

O comércio eletrônico sem cabeça separa a camada de apresentação de front-end do mecanismo de comércio de back-end. Para fins de PCI DSS, o que importa é para onde fluem os dados do titular do cartão. Se o seu frontend headless usa Stripe Elements ou uma solução semelhante baseada em iFrame, os dados do cartão vão diretamente do navegador para o processador de pagamento sem tocar nos servidores frontend – este é o território SAQ A. Se sua arquitetura headless envolver processamento de pagamento personalizado no servidor, o escopo se expandirá significativamente e você deverá contratar um QSA para obter orientação sobre o escopo.

Precisamos de um QSA para nossa avaliação do PCI DSS?

Apenas os comerciantes de Nível 1 (mais de 6 milhões de transações/ano para Visa/Mastercard) são obrigados a contratar um QSA para um Relatório de Conformidade (RoC) anual. Os comerciantes de nível 2 a 4 podem se autoatestar via SAQ. No entanto, muitos comerciantes contratam voluntariamente um QSA ou uma Empresa Avaliadora de Segurança Qualificada (QSAC) para orientação, mesmo quando não são necessários, especialmente quando não têm certeza do seu escopo ou possuem infraestrutura complexa.

---

Próximas etapas

A conformidade com o PCI DSS protege os dados de pagamento dos seus clientes, limita a sua exposição a responsabilidades e é um pré-requisito para manter a aceitação do cartão. Para empresas de comércio eletrônico no Shopify ou em plataformas personalizadas, o primeiro passo é sempre a redução do escopo – chegar ao SAQ A por meio do uso adequado de páginas de pagamento hospedadas é o caminho mais rápido e econômico.

A equipe de implementação de comércio eletrônico da ECOSIRE tem ampla experiência na construção de lojas Shopify compatíveis com PCI DSS e plataformas de comércio personalizadas, com arquitetura de pagamento projetada desde o início para minimizar o escopo do CDE.

Começar: Serviços ECOSIRE Shopify

Isenção de responsabilidade: este guia é apenas para fins informativos e não constitui aconselhamento jurídico ou de conformidade. Os requisitos do PCI DSS podem mudar e variar de acordo com a marca da placa e o adquirente. Contrate um QSA para obter orientações de conformidade definitivas específicas para seu ambiente.