PCI DSS 4.0.1 e risco de terceiros: como proteger a cadeia de pagamentos
O prazo para a entrada em vigor dos requisitos futuros do PCI DSS 4.x terminou em 31 de março de 2025. Desde então, nas avaliações aplicáveis, esses controles passaram a fazer parte do padrão exigido. Para empresas que vendem pela internet, a mudança amplia a atenção sobre elementos que nem sempre recebem o mesmo cuidado que servidores e bancos de dados: páginas de pagamento, scripts executados no navegador e serviços prestados por terceiros.
Com o PCI DSS 4.0.1, a questão já não é apenas confirmar se a organização está preparada para uma avaliação. O desafio é manter controles eficazes em uma operação que depende de plataformas, integrações e componentes externos. A cadeia de pagamentos pode envolver diversos fornecedores, e cada conexão autorizada precisa ser entendida e acompanhada.
Quando o navegador se torna parte da superfície de ataque
Uma página de checkout pode parecer íntegra no servidor e, ainda assim, colocar os dados dos clientes em risco. Isso pode acontecer se um script externo, uma ferramenta de análise de audiência, uma tag de marketing ou outro componente carregado no navegador for alterado sem autorização.
Nesse cenário, o criminoso não precisa necessariamente invadir a infraestrutura da loja pelo caminho tradicional. Ele pode explorar a confiança depositada em um recurso legítimo que já tem permissão para ser executado na página. Se o código malicioso conseguir observar ou modificar elementos do checkout, poderá capturar informações digitadas pelo consumidor. Esse tipo de ataque é conhecido como e-skimming.
A complexidade do comércio eletrônico torna o problema mais difícil de administrar. Uma página pode carregar componentes de diferentes domínios e fornecedores, muitas vezes sem que as equipes tenham uma visão atualizada de todos eles. Por isso, proteger o pagamento exige olhar para o que o navegador efetivamente recebe e executa, não apenas para o código mantido nos servidores da empresa.
O que exigem os requisitos 6.4.3 e 11.6.1
Em março de 2025, o PCI Security Standards Council publicou orientações sobre a segurança de páginas de pagamento e a prevenção de e-skimming. O material destaca, entre outros pontos, os requisitos 6.4.3 e 11.6.1.
O requisito 6.4.3 trata da administração dos scripts presentes nas páginas de pagamento. Na prática, a organização precisa saber quais códigos podem ser executados, justificar sua presença e adotar meios para verificar sua integridade. Manter uma lista de scripts sem avaliar se eles continuam necessários ou se foram modificados não é suficiente para controlar o risco.
Já o requisito 11.6.1 aborda a detecção de alterações e adulterações capazes de afetar a página de pagamento e os cabeçalhos HTTP relacionados à segurança. Em conjunto, os dois requisitos ampliam a perspectiva da defesa: não basta examinar o servidor; é necessário monitorar mudanças no conteúdo que chega ao navegador e identificar desvios em relação ao comportamento esperado.
Responsabilidade compartilhada com fornecedores
A terceirização de uma etapa do pagamento não transfere automaticamente toda a responsabilidade pela segurança. Processadores, gateways, provedores de hospedagem, plataformas de comércio eletrônico e outros prestadores podem participar do ambiente de dados do cartão ou influenciar sua proteção. O risco aumenta quando a empresa conhece as condições comerciais do contrato, mas não sabe com clareza quais sistemas e responsabilidades estão envolvidos.
O requisito 12.8 do PCI DSS orienta a gestão das relações com terceiros. Isso inclui avaliar fornecedores antes da contratação, formalizar acordos adequados, definir quem responde por cada controle e acompanhar periodicamente a situação de conformidade dos prestadores relevantes. Essas informações precisam ser suficientemente claras para que a organização consiga demonstrar como a segurança é mantida ao longo da cadeia.
Nem todo fornecedor que disponibiliza código deve ser automaticamente classificado como provedor de serviços de terceiros – TPSP. Conforme o PCI SSC esclarece, fornecer apenas um script não relacionado ao processamento de pagamentos não torna, por si só, um prestador um TPSP. É preciso considerar o serviço oferecido e sua capacidade real de afetar a segurança dos dados do cartão ou das informações de autenticação.
Essa distinção, porém, não elimina a necessidade de avaliar scripts externos. Mesmo quando um fornecedor não se enquadra como TPSP, seu componente pode influenciar o funcionamento da página de pagamento. A análise deve levar em conta tanto o papel formal do prestador quanto o impacto técnico do recurso que ele fornece.
Como transformar os requisitos em rotina operacional
O primeiro passo é inventariar os scripts que podem ser executados nas páginas de pagamento. Para cada item, convém registrar sua finalidade, origem, responsável interno, fornecedor associado e necessidade de acesso. Componentes sem justificativa clara devem ser removidos ou submetidos a uma análise adicional.
Em seguida, a empresa precisa estabelecer um processo para aprovar novos scripts e mudanças nos já existentes. Uma alteração feita por uma equipe de marketing, produto ou desenvolvimento pode modificar o risco do checkout, mesmo que não pareça relacionada a pagamentos. Por isso, as áreas envolvidas devem saber como solicitar mudanças e quem deve avaliar seus efeitos de segurança.
Também é importante monitorar as páginas e os cabeçalhos HTTP para identificar modificações inesperadas. O monitoramento precisa permitir que a equipe investigue o que mudou, determine se a alteração foi autorizada e tome providências diante de um comportamento suspeito. Um alerta sem responsáveis, procedimento de resposta e critérios de escalonamento tende a ter pouco valor prático.
A gestão dos fornecedores deve acompanhar esse mesmo nível de rigor. Uma organização pode manter registros de prestadores relevantes, revisar periodicamente evidências de conformidade e confirmar se as responsabilidades continuam válidas quando o serviço ou a integração muda. A avaliação não deve ficar restrita ao momento da contratação: alterações na arquitetura, nos dados tratados ou nas permissões concedidas podem mudar a exposição ao risco.
Outro cuidado é limitar a quantidade de código de terceiros carregado no checkout. Cada dependência adicional pode ampliar a superfície de ataque e dificultar a investigação de incidentes. A equipe deve avaliar se determinado componente é realmente necessário, se existe uma alternativa menos arriscada e se suas permissões podem ser reduzidas.
Por fim, tecnologia e governança precisam funcionar em conjunto. Ferramentas de detecção ajudam a identificar alterações, mas não substituem inventários confiáveis, decisões documentadas e responsabilidades bem definidas. Da mesma forma, contratos e políticas não impedem, sozinhos, que um script seja adulterado ou que uma mudança passe despercebida.
Conformidade como capacidade contínua
O PCI DSS 4.0.1 deve ser tratado como parte da operação diária, não como uma tarefa concentrada na época da auditoria. A cadeia de pagamentos muda quando a empresa adiciona fornecedores, atualiza integrações ou altera páginas de compra. Cada mudança pode modificar a forma como dados e códigos circulam.
Proteger o checkout exige visibilidade sobre os scripts, controle sobre as alterações, acompanhamento dos prestadores e capacidade de responder a sinais de comprometimento. Quando esses processos estão integrados, a organização reduz a dependência de verificações pontuais e consegue administrar melhor os riscos que surgem fora de sua infraestrutura direta.