Diagrama de fluxo de dados PCI DSS: mapeando dados de titulares de cartão e reduzindo o escopo

Uma avaliação PCI DSS costuma começar com o mesmo pedido: mostre para onde vão os dados do cartão. O diagrama do seu wiki mostra serviços e setas, mas não quais setas carregam um número de cartão, quais carregam só um token, nem por que o armazém de analytics está fora do escopo. Sem isso, todo sistema vira uma discussão de escopo.

Este post cobre o que o PCI DSS v4.0.1 exige, as categorias de escopo, um checkout detalhado com campos de pagamento hospedados, tokens, segmentação, tipos de SAQ e manutenção. Não é aconselhamento jurídico nem de conformidade: seu adquirente ou avaliador decide o que se aplica, e os textos oficiais estão na PCI SSC Document Library.

O que o PCI DSS v4.0.1 exige

O PCI DSS v4.0.1, publicado em junho de 2024, é a versão vigente no momento da escrita (novembro de 2026). Seus requisitos com data futura tornaram-se obrigatórios em 31 de março de 2025. Três requisitos moldam seus diagramas:

Dados de conta incluem dados do titular do cartão (PAN, nome do titular, data de validade, código de serviço) e dados de autenticação sensíveis (dados completos da tarja, código de verificação do cartão, PINs e blocos de PIN). O PAN é o elemento definidor: se você o armazena, processa ou transmite, você tem um ambiente de dados do titular do cartão (CDE).

O SAQ A não contém nem o requisito 1 nem o 12.5.2, o SAQ A-EP inclui 1.2.3 e 1.2.4, e o SAQ D e as avaliações completas incluem os três. Mesmo com o SAQ A, o diagrama continua sendo sua evidência mais clara de elegibilidade.

Três tipos de sistemas

A seção 4 aplica os requisitos ao CDE e a tudo que «possa impactar a segurança dos dados do titular do cartão e/ou dos dados de autenticação sensíveis», redação que a v4.0.1 introduziu no lugar de «a segurança do CDE». O exemplo do próprio padrão é «um servidor web que controla a geração de um formulário ou página de pagamento». O guia de escopo do PCI SSC classifica os sistemas em três categorias, verificadas de cima para baixo:

Um sistema pertence à categoria mais alta que ele atende. A segmentação é opcional, mas sem ela toda a «rede plana» está no escopo, e a criptografia sozinha em geral não tira os dados do cartão do escopo.

O exemplo: um checkout com campos de pagamento hospedados

Um aplicativo web de loja serve a página de checkout; seus campos de cartão são um iframe do provedor de pagamento, muitas vezes chamados de campos hospedados (hosted fields). Um serviço de pedidos cobra os pagamentos, o Postgres armazena os pedidos, um job noturno alimenta um armazém e o CI/CD faz o deploy da loja:

1. O navegador carrega a página de checkout; o script do provedor renderiza os campos de cartão em seu próprio iframe.
2. O cliente digita o PAN, a validade e o CVC, e o navegador os envia por TLS direto ao provedor. A política de mesma origem mantém os scripts da página do lojista fora do iframe.
3. O provedor armazena o PAN em seu vault e devolve um token.
4. A página envia o pedido e o token ao serviço de pedidos.
5. O serviço de pedidos cobra o token pela API do provedor com uma chave secreta, e o provedor solicita a autorização pela rede de cartões.
6. Um webhook confirma o resultado. O serviço de pedidos armazena o ID do token, a bandeira do cartão e os quatro últimos dígitos.

Nenhum sistema do lojista armazena, processa ou transmite o PAN, então o lojista não tem CDE; você gerencia o provedor, que tem sua própria avaliação, pelo requisito 12.8. O diagrama de integração de gateway de pagamento mostra o mesmo checkout como sequência, e o diagrama da plataforma de e-commerce o situa entre os serviços de catálogo, carrinho e pedidos.

O aplicativo web continua no escopo: um atacante que o altere, ou altere um script que ele carrega, pode trocar o iframe por um formulário falso. Esse ataque, o e-skimming, é o motivo pelo qual a v4.0 acrescentou 6.4.3 (autorizar, verificar a integridade e inventariar os scripts das páginas de pagamento) e 11.6.1 (detectar alterações nas páginas de pagamento). O CI/CD também está no escopo, já que o padrão conta as ferramentas de deploy como componentes do sistema.

Tokens e o que eles deixam no escopo

As diretrizes de tokenização do PCI SSC colocam o sistema de tokenização, incluindo a destokenização e o armazenamento do PAN, no CDE. Sistemas que guardam apenas tokens podem ficar fora do escopo se o PAN não puder ser recuperado a partir dos tokens, se eles não puderem solicitar destokenização nem alcançar o vault e se estiverem segmentados do CDE.

O provedor é dono do vault, então o serviço de pedidos e o banco de dados podem se qualificar, com uma ressalva: um token reutilizável mais a chave secreta da API pode criar cobranças. O guia diz que tokens capazes de iniciar uma transação «podem estar no escopo do PCI DSS» e orienta os lojistas a consultar seu adquirente. Proteja a chave como qualquer segredo de produção.

Segmentação e como ela é testada

Segmentação normalmente significa regras de firewall, security groups ou contas de nuvem separadas. Se ela isola um CDE, o requisito 11.4.5 exige testes de intrusão desses controles pelo menos a cada 12 meses e após mudanças (a cada seis meses para provedores de serviços), feitos por um testador qualificado e independente. No diagrama de rede de 1.2.3, desenhe cada segmento e os controles entre eles, como em uma topologia de rede lógica.

Sem CDE do lojista, o limite que importa envolve tudo que pode alterar a página de checkout: o serviço de pedidos, o armazém e suas credenciais não devem conseguir fazer deploy na loja.

Escolhas de arquitetura e tipos de SAQ

O design do seu checkout decide em grande parte o questionário de autoavaliação (SAQ); seu adquirente o confirma:

A revisão de janeiro de 2025 do SAQ A removeu 6.4.3 e 11.6.1 do questionário e acrescentou um critério de elegibilidade: o lojista confirma que «seu site não é suscetível a ataques de scripts que possam afetar o(s) sistema(s) de comércio eletrônico do lojista». A FAQ 1588 permite dois caminhos: proteger sua página com técnicas como as de 6.4.3 e 11.6.1, ou obter a confirmação do seu provedor de que a solução dele faz isso, quando implementada conforme as instruções. O critério vale para iframes incorporados, não para redirecionamentos, e ambos ainda exigem varreduras trimestrais por um Approved Scanning Vendor (FAQ 1604). Um único campo de cartão renderizado pela sua própria página exclui o SAQ A.

Mantendo o diagrama atualizado

O padrão considera «quaisquer mudanças no fluxo ou no armazenamento de dados de conta» potencialmente significativas. Atualize o diagrama sempre que adicionar uma forma de pagamento, um provedor ou canal, um script de checkout, ou uma exportação, um pipeline de logs ou uma ferramenta de suporte que toque em dados de pagamento.

Fique atento a números de cartão em tickets de suporte e chats: para um canal não intencional assim, a v4.0.1 diz para trazê-lo ao CDE ou apagar os dados com segurança e impedir que o canal seja usado para isso. Coloque data, autor e aprovador no diagrama; o fluxo de documentação viva trata de responsáveis e gatilhos de atualização.

O diagrama de fluxo de dados do titular do cartão

Como ler:

• Três zonas. O vermelho é o CDE do provedor, o âmbar reúne os sistemas do lojista que podem alterar a página de checkout, e o turquesa reúne os sistemas que só manipulam tokens.
• As cores seguem os dados: vermelho para dados de cartão, turquesa para tokens, cinza para nenhum dos dois; tracejado significa assíncrono.
• Os números seguem uma compra. O caminho vermelho nunca entra em uma moldura do lojista.
• Duas notas marcam os riscos restantes: scripts da página e tokens reutilizáveis.
• A legenda resume as classes de dados e o escopo.

Desenhando diagramas de fluxo de dados PCI DSS com clareza

Rotule cada fluxo e cada armazenamento:

• Desenhe o escopo como molduras e sombreie as áreas fora do escopo, como sugere o guia de 1.2.3.
• Desenhe um diagrama por canal: e-commerce, telefone e terminais são diferentes.
• Inclua os caminhos silenciosos: reembolsos, chargebacks, backups, logs e ferramentas de suporte.
• Faça coincidir com o diagrama de rede, que o diagrama de fluxo de dados deve complementar.
• Deixe de fora chamadas sem dados de conta nem tokens.

Um erro comum é uma linha de PAN atravessando sistemas que só guardam tokens, o que os puxa para o escopo no papel. Veja os exemplos de diagrama de fluxo de dados para a notação, o guia de modelagem de ameaças para os limites de confiança e o mapa de dados GDPR para um inventário parecido.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione uma Pessoa do pacote Modelo C4 para o navegador do cliente.
3. Adicione três nós Moldura do pacote Básico para o provedor (vermelho), o lojista no escopo (âmbar) e o lojista fora do escopo (turquesa).
4. Na moldura do provedor, adicione dois nós Sistema externo do pacote Modelo C4 para os campos hospedados e a API de pagamento, e um Cofre do pacote Segurança. Coloque um Sistema externo para as redes de cartões abaixo da moldura.
5. Na moldura âmbar, adicione um Contêiner do pacote Modelo C4 para o aplicativo web e um Pipeline de CI/CD do pacote DevOps.
6. Na moldura turquesa, adicione um Contêiner para o serviço de pedidos e nós Postgres e Armazém de dados do pacote Dados.
7. Desenhe arestas rotuladas: vermelho para dados de cartão, turquesa para tokens, cinza nos demais casos, tracejadas para o webhook e a exportação.
8. Adicione uma legenda Markdown do pacote Básico e duas notas Texto do pacote Básico.

Para o diagrama de rede de 1.2.3, o conversor de Terraform gera um primeiro rascunho a partir dos seus arquivos .tf; a página de diagrama de fluxo de pagamento mostra visões de sequência.

O exemplo usa 14 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

O PCI DSS exige um diagrama de fluxo de dados? Sim. O requisito 1.2.4 da v4.0.1 pede um diagrama de fluxo de dados preciso de todos os fluxos de dados de conta, mantido atualizado. O SAQ A o omite; o SAQ A-EP, o SAQ D e as avaliações completas o incluem.

Qual é a diferença entre o diagrama de rede PCI e o diagrama de fluxo de dados? O diagrama de rede (1.2.3) mostra as conexões entre o CDE e outras redes. O diagrama de fluxo de dados (1.2.4) mostra para onde os dados de conta viajam e onde são armazenados. Os dois devem concordar.

Um iframe ou uma página de pagamento hospedada tira meu site do escopo do PCI? Não. Ele mantém os dados do cartão fora dos seus sistemas, mas a página que incorpora o iframe ainda pode ser atacada, por isso o SAQ A pede varreduras ASV trimestrais e, para iframes, proteção contra ataques de scripts.

Sistemas que armazenam apenas tokens ficam fora do escopo do PCI DSS? Podem ficar, se o PAN não puder ser recuperado a partir dos tokens e os sistemas estiverem segmentados do sistema de tokenização. Tokens capazes de iniciar uma transação ainda podem estar no escopo.

Com que frequência o escopo PCI e os diagramas devem ser revisados? Atualize o diagrama de fluxo de dados sempre que os fluxos de dados de conta mudarem, e confirme o escopo pelo menos a cada 12 meses e após mudanças significativas (12.5.2), ou a cada seis meses para provedores de serviços.

Comece grátis — um assento, sem cartão de crédito.