A melhor ferramenta de deteção de Magecart para PCI DSS é aquela cuja saída um QSA aceitará como evidência. A deteção que só bloqueia ou só alerta não chega. Os requisitos 6.4.3 e 11.6.1 pedem-lhe para provar quatro coisas ao longo do tempo: que conhece cada script na sua página de pagamento, que cada um está autorizado, que é alertado quando um muda sem aprovação e que consegue mostrar o histórico.
Isso reenquadra a decisão de compra. Procure um sistema de registo que transforme um evento da camada do navegador numa entrada de inventário, numa decisão de autorização, num alerta de manipulação e num registo de alterações retido, não apenas o alarme de skimmer mais barulhento. A maior parte do marketing de "deteção de Magecart" fala da captura. A auditoria pede o rasto documental por trás da captura.
Este artigo avalia ferramentas de deteção através dessa lente de evidência PCI. Não classifica fornecedores por nome nem cita especificações. Diz-lhe que artefacto de evidência cada categoria de capacidade produz, que lacuna cada uma deixa e o que exigir num trial. O PCI DSS 4.0.1 tornou 6.4.3 e 11.6.1 obrigatórios em 2025-03-31, por isso a questão da evidência está viva agora, não na próxima renovação. Se a sua stack já cobre as ameaças conhecidas, a lacuna costuma ser a documentação, razão pela qual a prevenção de Magecart e a evidência PCI são agora a mesma tarefa.
Que evidência quer realmente um QSA da deteção de Magecart?
Mapeie o texto do requisito ao artefacto que a sua ferramenta deve produzir. Estas são as coisas que um avaliador abre durante uma revisão de 6.4.3/11.6.1.
| Artefacto de evidência PCI | Requisito que responde | Como é que "bom" parece |
|---|---|---|
| Inventário de scripts | 6.4.3 (saber o que corre) | Cada script na página de pagamento, incluindo scripts injetados dinamicamente e de CDN de terceiros, capturado como o navegador os vê |
| Registo de autorização | 6.4.3 (justificar cada script) | Uma justificação e um estado de aprovação por script, com quem decidiu e quando |
| Alerta de integridade / manipulação | 11.6.1 (detetar alteração) | Um alerta sobre alteração não autorizada ao conteúdo de scripts e aos cabeçalhos HTTP da página de pagamento, com um diff |
| Histórico de alterações | 6.4.3 + 11.6.1 (provar ao longo do tempo) | Um registo duradouro e com carimbo de data de cada adição, alteração e remoção de script, mais a resolução de cada alerta |
A armadilha é tratar a deteção de Magecart como uma funcionalidade de segurança e o PCI como uma caixa separada. São o mesmo controlo. Se a ferramenta apanha um skimmer mas não consegue mostrar ao avaliador a entrada de inventário a que esse script pertencia, o estado de autorização que violou e o registo datado do alerta e do seu fecho, apanhou o ataque e mesmo assim falhou a auditoria em documentação.
Porque é que uma comparação de assinaturas de malware falha a questão PCI
A maioria das listas de "melhores ferramentas de deteção" compara cobertura de ameaças: assinaturas conhecidas, blocklists, feeds de domínios maliciosos. Isso importa para bloquear. Não satisfaz 6.4.3 nem 11.6.1.
O Magecart de cadeia de fornecimento chega através de um script em que já confia. O CDN do fornecedor serve uma versão nova, a origem está na sua allowlist e o hash muda por uma razão aparentemente legítima. Um motor de assinaturas não vê nada porque o payload é novo e a fonte é permitida. O controlo PCI é desenhado exatamente para isto: 6.4.3 obriga-o a inventariar e autorizar esse script antecipadamente, e 11.6.1 obriga-o a alertar quando o seu conteúdo muda sem aprovação. A evidência, não a assinatura, é o que prova que teria apanhado a troca.
Por isso, avalie a deteção por se produz o registo de autorização e alteração, não só por se reconhece os skimmers conhecidos de hoje.
Como avaliar deteção de Magecart por categoria de capacidade
As ferramentas de deteção dividem-se em algumas categorias arquitetónicas. Cada uma produz evidência diferente e deixa uma lacuna diferente. Pontue-as pelo que entregam ao avaliador.
| Categoria de capacidade | Inventário | Registo de autorização | Alerta de manipulação (conteúdo + cabeçalhos) | Histórico de alterações | Principal lacuna de evidência |
|---|---|---|---|---|---|
| Scanner externo (rastreia a partir de IPs cloud) | Parcial, vê só o que o seu crawler carrega | Normalmente manual, aparafusado por cima | Periódico, pode perder entre scans | Baseado em snapshots | Perde scripts por sessão, por geografia e pós-interação |
| CSP + SRI (política imposta pelo navegador) | Não, restringe em vez de enumerar | Não | Só política de cabeçalho; SRI parte-se em scripts dinâmicos | Relatórios de violação, não registo de auditoria | Gera controlo, não o inventário nem a documentação de autorização |
| Visibilidade de scripts na rede/WAF | Parcial, o que atravessa o edge | Não | Cabeçalhos e bloqueio de conhecidos maliciosos | Registos de edge, não histórico por script | Sem estado de autorização por script para o QSA |
| Monitorização de runtime no navegador (agente na página) | Sim, captura scripts à medida que o navegador os executa | Sim, quando a plataforma modela o estado de aprovação | Sim, alteração de conteúdo e cabeçalho, com diff | Sim, registo duradouro e datado por script | Requer uma tag na página de pagamento |
Leia a tabela como uma checklist de evidência, não como um concurso de popularidade. Um scanner é rápido de implementar e útil para uma linha de base, mas um skimmer que só se ativa para compradores reais num país pode servir uma página limpa ao IP do crawler. CSP e SRI são controlos reais que o PCI SSC nomeia como mecanismos válidos, mas produzem política e relatórios de violação, não o inventário de scripts e os registos de autorização que 6.4.3 exige, e os hashes do SRI partem-se com os scripts dinâmicos de que muitos checkouts dependem. Essa mesma fragilidade é uma das razões pelas quais a Content Security Policy não funciona como resposta PCI autónoma. A monitorização de runtime no navegador é a única categoria que produz por si só os quatro artefactos, porque observa o script da forma que o navegador da vítima o faz.
Um plano de aquisição que testa evidência, não funcionalidades
Não deixe que uma demo termine em "olhe, apanhou o script mau". Faça a ferramenta provar o rasto documental.
- Levante uma cópia de staging de uma página de pagamento real e ligue a ferramenta.
- Publique uma alteração benigna num script, como adicionar um comentário ou subir uma versão, e confirme que a ferramenta a sinaliza com um diff antes/depois, a página afetada e um carimbo de data.
- Modifique um cabeçalho HTTP da página de pagamento e confirme que a deteção de alteração de cabeçalho de 11.6.1 dispara, não só a deteção de conteúdo de script.
- Registe uma decisão de autorização (aprovar um script, rejeitar a alteração) e confirme que esse estado é armazenado, atribuído e datado.
- Adicione um script que só carrega para uma sessão ou geografia específica e verifique se o inventário da ferramenta o captura. É aqui que a cobertura de scanner externo falha, e boa parte da razão pela qual os crawlers não ajudam na conformidade PCI por si sós.
- Exporte o inventário, os registos de autorização e o registo de alterações. Leia a exportação como o avaliador fará. Se forem capturas de ecrã ou um feed de alertas sem etiquetas, não é evidência.
Se uma ferramenta passar os passos 2 a 6, produz documentação 6.4.3/11.6.1 pronta para auditoria. Se parar no passo 2, comprou monitorização, não conformidade.
Onde a cside se encaixa no modelo de evidência
A cside é uma plataforma de client-side security construída para a categoria de monitorização de runtime no navegador, e especificamente para a evidência que um QSA abre. Não faz proxy do tráfego. Uma tag na página de pagamento captura scripts à medida que o navegador real os executa, o que fecha a lacuna do scanner em orientação por sessão e geografia.
Para 6.4.3, a PCI Shield mantém um inventário vivo de cada script da página de pagamento, incluindo scripts injetados dinamicamente e de CDN de terceiros, com um estado de autorização por script. Para 11.6.1, alerta sobre alterações não autorizadas ao conteúdo de scripts e aos cabeçalhos HTTP da página de pagamento, com um diff que mostra exatamente o que mudou. Cada adição, alteração, remoção e resolução de alerta cai num registo de alterações datado que pode exportar. A cside passou por uma avaliação QSA independente da VikingCloud para 6.4.3 e 11.6.1, por isso o modelo de evidência foi avaliado, não apenas afirmado. Para além do requisito, a plataforma adiciona monitorização de comportamento do navegador e deteção de bots/agentes IA, de modo que a mesma instrumentação que produz o seu registo PCI também traz à superfície as anomalias comportamentais que um skimmer novo cria.
A partir de 2026-06-18, trate isto como orientação operacional, não como aconselhamento jurídico. Confirme o texto exato dos controlos e o que o seu avaliador aceitará como evidência com o seu QSA, conselheiro jurídico ou responsável de risco.
