PCI DSS

Alterações PCI DSS v4.0 e o que significam para comerciantes europeus

5 de janeiro de 2025 10 min de leitura

O PCI DSS v4.0 representa a revisão mais significativa do Payment Card Industry Data Security Standard desde a sua criação. Publicada pelo PCI Security Standards Council em março de 2022, esta versão introduz 64 novos requisitos, 13 dos quais se aplicam a todas as entidades e 51 especificamente aos fornecedores de serviços. Após um período de transição de dois anos, a v3.2.1 foi oficialmente retirada em 31 de março de 2024, e os requisitos restantes com data futura tornaram-se obrigatórios em 31 de março de 2025. Para os comerciantes europeus, esta atualização chega num momento em que o panorama normativo já é complexo, com RGPD, PSD2 e leis nacionais de proteção de dados em evolução que se cruzam com as obrigações de segurança dos pagamentos.

Pontos-chave
  • O PCI DSS v4.0 introduziu 64 novos requisitos: todos obrigatórios desde 31 de março de 2025, com a v3.2.1 retirada em março de 2024.
  • A MFA é agora obrigatória para todos os acessos ao CDE (não apenas remotos), e os scripts de e-commerce devem ser inventariados e monitorizados para verificar a sua integridade.
  • Os comerciantes europeus enfrentam uma dupla exposição: os requisitos do PCI DSS v4.0 acrescem às obrigações RGPD, PSD2 e SCA já existentes.

Visão geral do PCI DSS v4.0

O PCI Security Standards Council concebeu a v4.0 em torno de quatro objetivos principais: garantir que o padrão continue a satisfazer as necessidades de segurança do setor dos pagamentos, adicionar flexibilidade para as organizações que utilizam métodos distintos para alcançar a segurança, promover a segurança como processo contínuo em vez de exercício pontual, e melhorar os métodos e procedimentos de validação. O padrão contém agora 12 requisitos principais (inalterados em relação à v3.2.1), mas com sub-requisitos substancialmente alargados, orientações mais prescritivas e novas áreas de atenção que refletem a evolução da tecnologia dos pagamentos desde a última versão principal publicada em 2016.

Uma das alterações estruturais mais importantes é a introdução da Abordagem Personalizada (Customized Approach), que se junta à Abordagem Definida tradicional. Em vez de prescrever controlos específicos, a Abordagem Personalizada permite às organizações definir os seus próprios controlos de segurança, desde que possam demonstrar que esses controlos cumprem o objetivo de segurança declarado de cada requisito. Isto é poderoso, mas exige documentação, testes e participação do avaliador significativamente maiores.

Alterações Principais que Afetam os Comerciantes Europeus

1. Abordagem Personalizada versus Abordagem Definida

Com a v3.2.1, todas as organizações seguiam o mesmo conjunto de controlos prescritivos. A v4.0 introduz uma bifurcação: pode-se continuar com a Abordagem Definida (o método tradicional, com controlos específicos a implementar) ou optar pela Abordagem Personalizada, onde se concebem controlos que alcançam o mesmo resultado de segurança, mas de forma adaptada ao ambiente específico. A Abordagem Personalizada exige uma Análise de Risco Específica para cada controlo personalizado, evidências documentadas de que o controlo cumpre o objetivo do requisito, e a validação por parte de um Qualified Security Assessor (QSA) com experiência nesta metodologia. Para a maioria dos comerciantes europeus de média dimensão, a Abordagem Definida continua a ser a opção prática.

2. Requisitos de Autenticação Reforçados

A Autenticação Multifator (MFA) é agora obrigatória para todos os acessos ao Cardholder Data Environment (CDE), não apenas para o acesso remoto. Com a v3.2.1, a MFA era apenas obrigatória para o acesso administrativo não de consola e para o acesso remoto ao CDE. A v4.0 alarga isto a todas as contas que podem aceder ao CDE, incluindo o acesso local à consola e as contas de serviço onde seja tecnicamente viável. Para os comerciantes europeus, isto significa rever cada sistema com acesso aos dados dos cartões e assegurar que a MFA está implementada de forma completa. Os requisitos de palavra-passe também foram reforçados: o comprimento mínimo aumenta de 7 para 12 caracteres, e as palavras-passe devem ser alteradas a cada 90 dias ou as organizações devem implementar uma análise dinâmica de segurança da conta.

3. Novos Requisitos para o E-Commerce e a Integridade dos Scripts

O Requisito 6.4.3 é uma das adições mais impactantes para os comerciantes de e-commerce. Impõe que todos os scripts das páginas de pagamento carregados e executados no navegador do consumidor devem ser geridos, ou seja, autorizados, com integridade verificada e inventariados. Isto visa diretamente ataques à cadeia de fornecimento como o Magecart, onde JavaScript malicioso é injetado nas páginas de pagamento para roubar dados dos cartões. Os comerciantes de e-commerce europeus devem implementar cabeçalhos Content Security Policy (CSP) ou uma solução de gestão de scripts que monitorize as alterações nos scripts das páginas de pagamento e alerte sobre modificações não autorizadas. O Requisito 11.6.1 complementa isto ao exigir mecanismos de deteção de alterações e manipulações nas páginas de pagamento que avisem em caso de modificações não autorizadas nos cabeçalhos HTTP e no conteúdo dos scripts.

Requisito de alto impacto

Os Requisitos 6.4.3 e 11.6.1 sobre a integridade dos scripts são uma das alterações tecnicamente mais exigentes para os comerciantes de e-commerce. Muitas organizações ainda não estão preparadas para inventariar e monitorizar todos os JavaScript que são executados nas suas páginas de pagamento. Comece a planear com antecedência; a implementação retroativa sob pressão temporal é dispendiosa e propensa a erros.

4. Requisitos de Análise de Risco Específica

A v4.0 substitui a avaliação de risco geral anual por uma Análise de Risco Específica (Targeted Risk Analysis, TRA) mais estruturada. Em vez de uma única avaliação monolítica do risco, os comerciantes realizam agora análises específicas para requisitos concretos: determinar a frequência das revisões de registos, o intervalo para as análises de vulnerabilidades ou o calendário de rotação de chaves criptográficas. Cada TRA deve documentar o panorama específico de ameaças, os ativos em risco, a probabilidade e impacto de uma violação, e a lógica por detrás da frequência ou configuração do controlo escolhido. Os resultados da TRA devem ser revistos pelo menos anualmente e atualizados quando o ambiente de ameaças mudar.

5. Padrões de Encriptação Atualizados

O PCI DSS v4.0 reforça os requisitos relativos aos protocolos criptográficos e aos conjuntos de encriptação. TLS 1.0 e 1.1, que já eram desaconselhados, estão agora explicitamente proibidos. Todas as ligações cifradas devem utilizar TLS 1.2 ou superior com conjuntos de encriptação robustos. Os certificados devem ser válidos e de confiança, e os certificados wildcard devem ser justificados. Os requisitos de gestão de chaves incluem agora procedimentos documentados de rotação de chaves criptográficas, e as organizações devem ser capazes de demonstrar que dispõem de um inventário de todas as chaves criptográficas utilizadas para proteger os dados dos titulares de cartões, incluindo as datas de vencimento e os calendários de renovação.

6. Registo e Monitorização Alargados

Os requisitos de registo foram substancialmente alargados. As organizações devem agora implementar mecanismos de revisão automatizada dos registos de auditoria; as revisões manuais por si só já não são aceitáveis para cumprir o Requisito 10. As entradas de registo devem capturar campos adicionais, incluindo a identidade do utilizador, o tipo de evento, a data e hora, a indicação de sucesso ou falha, a origem do evento e a identidade ou nome do dado, componente do sistema ou recurso afetado. A geração de alertas em tempo real é obrigatória para eventos críticos, e os registos devem estar protegidos de modificações não autorizadas através de mecanismos de monitorização da integridade.

A Dimensão Europeia: a Interseção com o RGPD

Os comerciantes europeus operam sob um duplo quadro normativo: PCI DSS para a segurança dos cartões de pagamento e RGPD para a proteção de dados pessoais. O PCI DSS v4.0 cria vários pontos de alinhamento e ocasionais tensões com o RGPD. No lado positivo, os requisitos melhorados de registo e monitorização apoiam a obrigação de notificação de violação em 72 horas do RGPD ao melhorar as capacidades de deteção. A ênfase no acesso baseado em funções, o princípio do menor privilégio e a minimização de dados alinha-se bem com os princípios de proteção de dados do RGPD.

No entanto, podem surgir fricções em torno da retenção de dados. O PCI DSS impõe a conservação dos registos de auditoria durante pelo menos 12 meses, enquanto o RGPD exige que os dados pessoais não sejam conservados por mais tempo do que o necessário. Se os registos de auditoria contiverem dados pessoais (nomes de utilizador, endereços IP, identificadores de transações), as organizações devem reconciliar estes requisitos concorrentes, tipicamente através da classificação de dados e políticas de retenção específicas que satisfaçam ambos os padrões.

Prazos e Datas-Limite

A transição para o PCI DSS v4.0 seguiu um calendário estruturado. A v4.0 foi publicada em março de 2022. A partir desse momento, as organizações podiam validar-se tanto com a v3.2.1 como com a v4.0. Em 31 de março de 2024, a v3.2.1 foi oficialmente retirada; todas as avaliações desde essa data devem utilizar a v4.0. No entanto, reconhecendo o âmbito de algumas alterações, o Council designou 51 requisitos como "com data futura", ou seja, eram boas práticas durante 2024, mas tornaram-se obrigatórios em 31 de março de 2025.

Datas-chave

  • Março 2022: PCI DSS v4.0 publicado
  • 31 de março de 2024: v3.2.1 retirada, v4.0 obrigatória para todas as avaliações
  • 31 de março de 2025: Todos os requisitos com data futura passam a ser obrigatórios

Como a PCI Proxy Ajuda com a Conformidade v4.0

A estratégia mais eficaz para gerir a complexidade do PCI DSS v4.0 é minimizar o ambiente que entra em âmbito. PCI Proxy consegue isso eliminando completamente os dados dos cartões da sua infraestrutura. Quando os PAN não processados nunca entram nos seus servidores, bases de dados ou registos de aplicações, a grande maioria dos requisitos v4.0 simplesmente não se aplica ao seu ambiente. Os novos requisitos sobre integridade de scripts (6.4.3 e 11.6.1) tornam-se significativamente mais fáceis de gerir quando as suas páginas de pagamento utilizam os secure fields da PCI Proxy: os dados do cartão são capturados num iframe isolado alojado no ambiente da PCI Proxy, o que significa que os scripts da sua página nunca têm acesso aos números de cartão não processados.

Os requisitos de autenticação reforçados tornam-se mais limitados em âmbito porque menos sistemas têm acesso aos dados dos titulares de cartões. As obrigações de registo e monitorização simplificam-se porque há menos sistemas a monitorizar; o vault da PCI Proxy gere o seu próprio registo de auditoria dentro de um ambiente certificado de Nível 1. Em termos práticos, a tokenização através da PCI Proxy pode reduzir o seu âmbito de avaliação de SAQ D (mais de 300 controlos) para SAQ A ou SAQ A-EP (menos de 30 controlos), tornando a conformidade v4.0 alcançável mesmo para organizações com recursos de segurança limitados.

Checklist de Preparação para Comerciantes

Os comerciantes europeus devem utilizar a seguinte checklist para avaliar a sua preparação para o PCI DSS v4.0:

Realizar uma análise de lacunas comparando os controlos atuais com os requisitos v4.0

Determinar se a Abordagem Definida ou a Personalizada é a adequada para a sua organização

Implementar MFA para todos os acessos ao CDE, incluindo a consola local e as contas de serviço

Inventariar e autorizar todos os scripts nas páginas de pagamento; implementar cabeçalhos CSP ou monitorização equivalente

Atualizar as políticas de palavras-passe para um mínimo de 12 caracteres e implementar a revisão automatizada de registos

Completar as Análises de Risco Específicas para todos os requisitos que fazem referência à TRA

Assegurar que todas as ligações cifradas utilizem TLS 1.2+ e inventariar todas as chaves criptográficas

Avaliar a redução do âmbito mediante tokenização: mover os dados dos cartões completamente para fora do seu ambiente

Conclusão

O PCI DSS v4.0 é a atualização mais substancial do padrão na sua história. Para os comerciantes europeus, a combinação de novos requisitos técnicos, a interseção com o RGPD e a viragem para a monitorização contínua da segurança cria um panorama de conformidade complexo. No entanto, o passo mais impactante que qualquer comerciante pode dar é reduzir o âmbito do seu Cardholder Data Environment. Ao eliminar os dados não processados dos cartões da sua infraestrutura através da tokenização, elimina-se o ambiente em que se aplica a maioria dos requisitos v4.0, transformando uma avaliação de mais de 300 controlos numa de 30 controlos gerível.

Os prazos de transição já passaram e a conformidade deixou de ser opcional. Quer esteja a iniciar o seu caminho para a v4.0 ou a aperfeiçoar um programa existente, o momento de agir é agora. Avalie o seu âmbito atual, identifique as lacunas e considere se uma arquitetura PCI Proxy pode simplificar o seu caminho para a conformidade.


Precisa de apoio na conformidade PCI?

A nossa equipa ajuda a mapear o seu CDE, escolher o SAQ adequado e implementar tokenização com residência de dados na UE.

Contacte-nos

Simplifique a conformidade PCI DSS hoje

Reduza o seu CDE, simplifique o SAQ e proteja os dados de cartão dos clientes com a PCI Proxy EU.