Tokenização vs. Criptografia no PCI DSS: qual protege mais o seu negócio?

Neste artigo:

• O que é criptografia de dados de cartão?
• O que é tokenização e como ela funciona?
• Diferenças práticas no escopo do PCI DSS
• Comparativo técnico: tokenização vs. criptografia
• Quando usar cada abordagem?
• Impacto nos níveis de conformidade PCI
• Conclusão

A criptografia é o processo de transformar dados legíveis em um formato codificado usando algoritmos matemáticos e chaves criptográficas. No contexto do PCI DSS, ela é exigida para proteger dados de titulares de cartão (CHD) em trânsito e em repouso — e está presente em múltiplos requisitos, especialmente nos Requisitos 3 e 4.

Como funciona na prática

Quando um número de cartão (PAN) é criptografado, ele se torna uma sequência de caracteres aparentemente aleatória. Para reverter esse processo — ou seja, recuperar o PAN original —, é necessário ter acesso à chave criptográfica. Isso significa que:

• O dado original continua existindo no seu ambiente
• A chave de descriptografia precisa ser armazenada e gerenciada com segurança
• O ambiente onde a chave é gerenciada permanece dentro do escopo CDE (Cardholder Data Environment)

O PCI DSS aceita algoritmos como AES-256, RSA-2048 e outros considerados "strong cryptography". A norma, contudo, não elimina a responsabilidade sobre os dados — apenas exige que eles estejam protegidos enquanto armazenados ou transmitidos.

A tokenização substitui o dado sensível — no caso, o PAN — por um valor substituto chamado token. Esse token não tem relação matemática com o dado original e, por si só, não pode ser revertido ao PAN sem acesso ao cofre de tokens (token vault), que fica isolado do restante do ambiente.

Tipos de tokenização no mercado

Existem dois modelos principais utilizados no contexto de pagamentos:

Tokenização de rede (network tokenization): realizada pelas bandeiras (Visa, Mastercard), substitui o PAN por um token específico para aquele canal de pagamento. É amplamente usada em carteiras digitais como Apple Pay e Google Pay.

Tokenização de adquirente/gateway: realizada pelo provedor de pagamento, gera um token que representa o PAN no ambiente do comerciante. O comerciante armazena apenas o token, nunca o PAN real.

Esta é a distinção mais crítica para quem está buscando a certificação PCI DSS: o impacto de cada abordagem no tamanho do seu CDE.

Criptografia e o escopo

Com criptografia, os dados de cartão continuam presentes no ambiente — apenas protegidos. Isso significa que:

• Todos os sistemas que processam, armazenam ou transmitem esses dados (mesmo criptografados) estão dentro do escopo
• A infraestrutura de gestão de chaves também é parte do CDE
• A organização precisa demonstrar conformidade para esses ambientes em todos os 12 requisitos do PCI DSS

Tokenização e a redução de escopo

A tokenização, quando implementada corretamente, pode retirar sistemas inteiros do escopo PCI DSS. Se uma empresa substitui o PAN por um token antes que o dado entre em seus servidores, esses servidores nunca veem dados reais de cartão — e, portanto, podem ser excluídos do CDE.

Segundo o PCI SSC Tokenization Guidelines, para que a tokenização efetivamente reduza escopo, ela deve ser implementada de forma que:

1. O token não seja reversível sem o cofre
2. O cofre de tokens esteja fora do ambiente do comerciante (ou isolado de forma robusta)
3. Os sistemas que recebem apenas tokens não tenham acesso ao cofre

A escolha entre tokenização e criptografia depende do contexto operacional, da infraestrutura existente e dos objetivos de conformidade da organização.

Use criptografia quando:

• Precisar manter o PAN acessível internamente para processos de negócio (ex: estornos, recorrência sem gateway)
• Trabalhar com sistemas legados que não suportam integração com cofres de token
• O requisito for proteger dados em trânsito (neste caso, TLS é obrigatório pelo PCI DSS de qualquer forma)
• Precisar de uma solução de conformidade rápida enquanto planeja uma arquitetura de tokenização

Use tokenização quando:

• O objetivo for reduzir ao máximo o escopo do CDE
• Trabalhar com e-commerce ou plataformas que aceitam pagamentos recorrentes
• Quiser simplificar auditorias PCI DSS futuras
• O gateway ou adquirente já oferecer tokenização como serviço (o que é cada vez mais comum)

Para entender melhor como o escopo afeta a auditoria, veja nosso artigo sobre como funciona uma auditoria PCI DSS.

O PCI DSS classifica comerciantes em níveis de conformidade com base no volume de transações anuais. A tokenização pode ter impacto direto no tipo de questionário que a empresa precisa responder.

SAQ A — O caso mais favorável

Comerciantes de e-commerce que terceirizam completamente o processamento de pagamento para um provedor certificado PCI (incluindo a tokenização) podem se qualificar para o SAQ A — o questionário de autoavaliação mais simplificado, com apenas 22 requisitos.

Isso é possível porque, nesses casos, o site do comerciante não recebe, processa, armazena nem transmite dados de cartão — apenas redireciona o cliente para uma página do provedor ou exibe um iframe. Para entender quando essa simplificação se aplica, veja nosso conteúdo sobre SAQ: quando conveniência se torna multa.

SAQ D — O mais abrangente

Empresas que mantêm dados de cartão internamente — mesmo criptografados — geralmente precisam responder ao SAQ D, que cobre todos os 12 requisitos e suas centenas de subcontroles. A criptografia, nesses casos, é um controle obrigatório, mas não simplifica o questionário.

Tokenização e criptografia não são concorrentes — são ferramentas complementares dentro de uma estratégia de segurança de dados de pagamento. A diferença fundamental está no que cada abordagem faz com o dado: a criptografia o protege dentro do seu ambiente; a tokenização o remove do seu ambiente.

Para empresas que buscam simplificar a certificação PCI DSS, reduzir custos de auditoria e minimizar o risco de exposição de dados de cartão, a tokenização — especialmente quando oferecida pelo gateway ou adquirente — é a abordagem mais eficiente. A criptografia, por sua vez, continua sendo indispensável para proteger dados em trânsito e em cenários onde o PAN precisa estar acessível internamente.

A decisão ideal combina as duas abordagens com base na arquitetura do negócio e nos objetivos de conformidade. Essa avaliação é parte fundamental de uma gestão de vulnerabilidades e conformidade PCI DSS bem estruturada.

Leia também:

• Como Funciona uma Auditoria PCI DSS
• Os 12 Requisitos do PCI DSS
• SAQ por Conveniência, Multa por Consequência