O Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS) exige que as empresas protejam os dados do titular do cartão quando armazenados e em movimento em uma rede. Isso significa exigir criptografia forte, além de um conjunto de regras de suporte que abrangem desde a força do certificado até a geração, o armazenamento e a remoção de chaves criptográficas.

O cumprimento desses requisitos de criptografia do PCI afeta mais do que sua lista de verificação de conformidade. Ele pode ajudar a reduzir a superfície de ataque e a definir como a empresa será exposta se ocorrer uma violação. O custo médio de uma violação de dados chegou a US$ 4,44 milhões globalmente em 2025, ressaltando a importância de proteger registros confidenciais. A seguir, abordamos o que o PCI DSS realmente exige para criptografia, quais algoritmos e protocolos atendem a esse limite atualmente e como a criptografia interage com estratégias relacionadas, como tokenização e segmentação de rede.

Principais conclusões

• O PCI DSS exige criptografia forte para dados do titular do cartão, tanto em repouso quanto em trânsito, tendo o Padrão Avançado de Criptografia (AES) com uma chave de 256 bits e o Transport Layer Security (TLS) 1.2 ou superior como bases aceitas.

• Como a criptografia e a tokenização resolvem problemas diferentes, você pode reduzir o escopo de conformidade com o PCI combinando criptografia de ponta a ponta (P2PE) com tokenização.

• Uma gestão deficiente de chaves é um dos motivos mais comuns de falha das empresas em uma avaliação do PCI DSS, apesar da solidez dos algoritmos criptográficos.

Quais são os requisitos de criptografia de PCI?

As regras de criptografia do PCI DSS são definidas no Requisito 3 da lista de verificação de conformidade, que abrange dados armazenados do titular do cartão, e no Requisito 4, que abrange dados em movimento em redes. Os auditores de PCI verificam essas duas áreas ao avaliar como as informações do cartão são tratadas.

De acordo com o Requisito 3, se você armazenar o número da conta principal (PAN), deverá torná-lo ilegível onde quer que apareça, seja em um banco de dados, arquivo de log ou backup. Embora a criptografia forte seja o principal método de proteção, truncamento e hash também são opções, especialmente para mascarar PANs em recibos ou telas voltadas para o cliente. O Requisito 4 afirma que todos os dados do cartão que cruzam redes públicas e abertas devem ser criptografados de ponta a ponta. Não há exceções para conveniência interna ou ambientes legados anteriores ao padrão.

Os dados confidenciais de autenticação (SAD) adotam uma abordagem diferente que inclui todos os dados da tarja magnética ou do chip, o valor de verificação do cartão (CVV) e o bloco do PIN. O PCI DSS não permite armazenar nada disso após a conclusão da autorização, independentemente do status da criptografia.

Quais padrões e protocolos criptográficos o PCI DSS aprova para criptografia?

O PCI DSS exige "criptografia forte", definida pelo Conselho de Padrões de Segurança do PCI como qualquer método que forneça pelo menos 112 bits de força efetiva de chave. Na prática, essa definição aponta para uma pequena lista de opções aceitas:

• Dados inativos: o AES-256 é o padrão comum. Ele atende ao limite de força e tem amplo suporte entre provedores de nuvem e infraestrutura de pagamentos. O Triple DES (3DES) ainda se qualifica tecnicamente em algumas configurações, mas o Conselho de Padrões de Segurança do PCI o sinalizou para descontinuação, e a maioria dos novos sistemas o ignora totalmente.

• Criptografia assimétrica: usada para troca de chaves simétricas ou assinatura de certificados, o que geralmente significa Rivest–Shamir–Adleman (RSA) em 2048 bits ou superior, ou criptografia de curva elíptica (ECC) em 224 bits ou superior.

• Dados em trânsito: o TLS 1.2 é o mínimo aceitável, e o TLS 1.3 é cada vez mais considerado o padrão na prática. O SSL, em todas as versões, e as primeiras versões do TLS (1.0 e 1.1) não são permitidos expressamente.

• Pacotes de criptografia: os pacotes de qualificação não podem ter vulnerabilidades conhecidas, o que exclui o RC4 (Rivest Cipher 4) e quaisquer cifras de nível de exportação remanescentes de configurações mais antigas.

• Força do certificado: os certificados voltados ao público precisam de RSA de 2048 bits ou mais forte, datas de validade atuais e emissão de uma autoridade de certificação confiável.

• Negociação de protocolos: os servidores devem rejeitar tentativas de conexão que retornem a versões de protocolos não permitidas em vez de permiti-las silenciosamente.

Como a criptografia reduz o escopo de conformidade com o PCI?

Em termos de PCI DSS, o escopo de conformidade significa cada sistema que armazena, processa ou transmite dados do titular do cartão, além de qualquer coisa conectada a esses ativos que possa afetar sua segurança. Isso é conhecido coletivamente como ambiente de dados do titular do cartão (CDE).

Se um sistema lida com dados criptografados do titular do cartão sem acesso aos meios para descriptografá-los, o Conselho de Padrões de Segurança do PCI os trata como fora do escopo ou, pelo menos, em uma categoria de escopo reduzido. É aqui que entra o P2PE. Uma solução P2PE listada no PCI criptografa os dados do cartão no ponto de interação, dentro de um hardware validado. A descriptografia fica confinada ao ambiente seguro do provedor de soluções P2PE, e não à infraestrutura da empresa.

Uma solução P2PE validada geralmente se qualifica para um Questionário de Autoavaliação (SAQ) P2PE, um dos SAQs de PCI mais curtos, já que o P2PE restringe substancialmente o escopo da avaliação. A segmentação o restringe ainda mais. Quando os sistemas de dados de cartão são isolados em seu próprio segmento de rede, separados dos sistemas gerais de negócios, isso permite que sistemas que nunca veem dados do titular do cartão fiquem totalmente de fora da avaliação.

Criptografia ou tokenização: qual estratégia atende melhor às suas necessidades de criptografia de PCI?

A criptografia transforma o PAN em texto cifrado ilegível, mas o número original ainda existe em algum lugar. Qualquer pessoa com a chave certa pode reverter o processo. A tokenização remove totalmente o PAN do ambiente da empresa e o substitui por um token que não tem relação matemática com o número original e não tem valor se for roubado.

Quando há necessidade de consultar a forma de pagamento de um cliente após a transação inicial, como em assinaturas, formas de pagamento salvas ou checkout em um clique, a tokenização faz diferença. Se um PAN criptografado for armazenado internamente, você ainda manterá um número de cartão completo e tudo o que o acompanha, incluindo funções de gestão de chaves, escopo ampliado de auditoria e exposição se a chave associada for comprometida. Mas se você armazenar um token gerado e mantido por um provedor de pagamentos, como a Stripe, o valor confidencial nunca chegará aos seus sistemas. Muitas configurações combinam os dois, com a tokenização usada para tudo o que é armazenado a longo prazo e a criptografia usada para tudo o que se move em uma rede.

Por que a gestão de chaves é uma parte negligenciada da criptografia de PCI?

A criptografia depende de como as chaves são protegidas, e essas práticas são frequentemente negligenciadas. Lembre-se do seguinte:

• Conhecimento dividido e controle duplo: uma chave criptográfica completa não precisa estar acessível a uma única pessoa. Dividir componentes de chaves entre várias pessoas e exigir que mais de uma pessoa reconstrua uma chave impede que um único indivíduo comprometa o ambiente sozinho.

• Armazenamento seguro de chaves: as chaves precisam ser armazenadas separadamente dos dados que protegem, geralmente em um módulo de segurança de hardware (HSM) ou em um sistema de gestão de chaves equivalente; elas não devem ser mantidas no mesmo banco de dados ou sistema de arquivos que os valores criptografados.

• Períodos de criptografia definidos: toda chave precisa de uma vida útil documentada, após a qual é retirada e substituída, com base em fatores como a quantidade de dados que protege e com que frequência é usada.

• Responsabilidades documentadas dos guardiões de chaves: procedimentos escritos precisam identificar os responsáveis por tarefas de gestão de chaves; esses guardiões devem reconhecer formalmente a responsabilidade.

No PCI DSS 4.0, as empresas devem revisar sua arquitetura criptográfica pelo menos uma vez a cada 12 meses para confirmar que os algoritmos, protocolos e tamanhos de chaves usados ainda atendem aos padrões atuais e não estão desatualizados.

O que acontece se a sua empresa não cumprir os requisitos de criptografia de PCI?

O não cumprimento dos requisitos de criptografia do PCI DSS muda o que acontece antes e depois de uma violação. Antes de qualquer incidente, a não conformidade aparece no processo de revisão anual. Bancos adquirentes e bandeiras de cartão podem sinalizar uma empresa como não conforme, afetando sua capacidade de continuar a processar pagamentos com cartão e gerando um monitoramento mais rigoroso ou requisitos adicionais de revisão no futuro.

As consequências se agravam se ocorrer uma violação e uma investigação descobrir que esses controles não foram atendidos no momento. Uma investigação forense geralmente é necessária após uma violação confirmada envolvendo dados do titular do cartão. Ela examinará especificamente se o PAN foi criptografado adequadamente no armazenamento e em trânsito. Se não for o caso, a responsabilidade não será compartilhada com o provedor de pagamentos ou banco adquirente, mas recairá mais sobre a empresa.

Pode ser difícil reconstruir a confiança com um banco adquirente ou um provedor de pagamentos depois de uma descoberta como essa. Como falhas criptográficas também tendem a revelar outros pontos fracos no tratamento interno de dados, é provável que um banco não fique satisfeito com a correção de um único controle isoladamente quando encontrar brechas em outros.

Como o Stripe Payments pode ajudar

O Stripe Payments oferece uma solução global e unificada de pagamentos que ajuda qualquer empresa — de startups em crescimento a corporações globais — a aceitar pagamentos online, presenciais e em todo o mundo.

O Stripe Payments pode ajudar você a:

• Otimize sua experiência de checkout: Crie uma experiência de cliente sem atritos e economize o tempo dos engenheiros com interfaces do usuário de pagamento pré-criadas, acesso a mais de 125 formas de pagamento e Link, uma carteira criada pela Stripe.

• Expanda para novos mercados mais rapidamente: alcance clientes em todo o mundo e reduza a complexidade e o custo da gestão multimoedas com opções de pagamento internacional, disponíveis em 195 países e mais de 135 moedas.

• Unifique pagamentos presenciais e online: desenvolva uma experiência de unified commerce entre canais online e presenciais para personalizar interações, recompensar a fidelidade e aumentar a receita.

• Melhorar o desempenho dos pagamentos: aumente a receita com ferramentas configuráveis, proteção contra fraudes no-code e recursos avançados que elevam as taxas de autorização.

• Avançar mais rápido com uma plataforma flexível e confiável para crescer: desenvolva sobre uma plataforma projetada para crescer junto com o seu negócio, com 99,999% de disponibilidade histórica e confiabilidade líder do setor.

Saiba mais sobre como o Stripe Payments pode potencializar seus pagamentos presenciais e online ou comece já.