Proteside Evidências PCI DSS
Acompanhe os requisitos 6.4.3 e 11.6.1, autorize os headers de segurança, gere relatórios e entregue as evidências ao seu QSA.
A tela Evidências PCI DSS, no grupo Compliance do menu, reúne o que o Proteside registra sobre as páginas de pagamento para os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0. Ela mostra o status de cada requisito, os headers de segurança, os relatórios para download e as verificações periódicas.
Disponível a partir do plano Standard
Nos planos Essential e trial sem plano, a tela aparece bloqueada, com o botão Ver planos. Veja Cobrança.
O Proteside gera evidência de suporte. A própria tela avisa que ela "não é uma certificação de conformidade": quem avalia a conformidade é o seu QSA, ou a sua equipe, no questionário de autoavaliação.
O que os requisitos pedem
| Requisito | Em linguagem simples | Como o Proteside gera a evidência |
|---|---|---|
| PCI DSS 4.0, requisito 6.4.3 | Todo script que roda na página de pagamento precisa estar inventariado, ter uma justificativa de por que está ali e ser autorizado. Você precisa também garantir que o script não foi alterado. | O SDK monta o inventário de scripts sozinho. Cada autorização em Scripts registra quem decidiu, quando e por quê. O hash do conteúdo é fixado na autorização, e qualquer mudança devolve o script para revisão. |
| PCI DSS 4.0, requisito 11.6.1 | Você precisa de um mecanismo que detecte mudanças não autorizadas nos headers HTTP e no conteúdo da página de pagamento, avaliado ao menos a cada 7 dias. | O SDK observa cada visita ao checkout. Um verificador no servidor confere o conteúdo dos scripts a cada 6 horas, e um verificador sintético abre as páginas monitoradas toda semana. Mudanças geram alertas. |
Resumo
As abas Resumo, Headers, Relatórios e Verificações (1) organizam a tela. O número em vermelho na aba Resumo conta os alertas de adulteração abertos: divergência de integridade, script modificado ou injetado e header alterado.
O cartão Requisito 6.4.3 — Integridade de scripts (2) e o cartão Requisito 11.6.1 — Detecção de mudança (3) mostram um destes status:
| Status | 6.4.3 | 11.6.1 |
|---|---|---|
| Evidência completa | Todos os scripts têm decisão e nenhuma autorização venceu. | Houve atividade do SDK ou verificação nos últimos 7 dias e não há alerta de adulteração aberto. |
| Atenção | O inventário ainda está vazio. | Não usado. |
| Ação necessária | Há script Precisa revisão, autorização vencida ou script bloqueado que continua carregando. | Não houve eventos do SDK nem verificações nos últimos 7 dias, ou há alerta de adulteração aberto. |
Abaixo de cada cartão aparecem os números e os atalhos para resolver:
- Scripts aguardando decisão (4): clique em Revisar scripts e autorize ou bloqueie cada um.
- Autorizações vencidas: reautorize os scripts em Scripts.
- Scripts bloqueados que continuam carregando: o bloqueio só funciona para scripts inseridos por JavaScript. Remova a tag do HTML da página.
- Sem eventos do SDK nem verificações: clique em Verificar instalação e confira o snippet.
- Alertas de adulteração abertos: clique em Ver alertas e trate cada um em Alertas.
Scripts com revisão programada vencida geram só um aviso e não mudam o status do 6.4.3.
O Log de autorização de scripts (5) é o histórico das decisões: Quando, Script, Revisor, Método, Justificativa e Decisão. O revisor aparece pelo nome, nunca pelo e-mail. Decisões automáticas aparecem como Sistema, Política: … ou Token de API …. Clique em Mostrar mais para ver as decisões mais antigas.
Headers
O requisito 11.6.1 também pede que você detecte mudanças nos headers HTTP de segurança. A aba Headers (1) lista
os 12 headers que o SDK observa nas páginas de pagamento, como Content-Security-Policy, Strict-Transport-Security
e X-Frame-Options, mais qualquer outro header que ele encontrar.
As colunas Presente e Status (2) mostram se o header foi visto e como está em relação à referência:
| Status | Significado |
|---|---|
| Inalterado | O valor é igual à referência. |
| Alterado | O valor mudou. Um alerta Header de segurança alterado (HEADER_CHANGED) foi aberto. |
| Ausente | A página não envia esse header. |
| Não coletável | O navegador não permite ler esse header. Set-Cookie sempre aparece assim, e isso é esperado. |
| Aguardando observação | O SDK ainda não visitou a página com esse header. |
Enquanto você não autoriza nada, a referência é o primeiro valor observado (o baseline). Para fixar o valor de hoje como referência:
Clique em Autorizar valor atual
Na linha do header, clique em Autorizar valor atual (3).
Escreva a justificativa
Explique de onde vem o valor, com pelo menos 10 caracteres. Exemplo: "nova CSP publicada em 12/09 pela equipe de plataforma (chamado #123)".
Confirme
Clique em Confirmar. A tabela passa a mostrar quem autorizou e quando. A partir daí, qualquer mudança no valor
gera o alerta HEADER_CHANGED.
Quando você muda um header de propósito, o status fica Alterado e o botão vira Aceitar novo valor. Use-o, com justificativa, para registrar a mudança como autorizada. Remover autorização volta a comparação para o baseline.
Só Proprietário e Administrador autorizam headers. As outras pessoas veem a tabela sem a coluna Ações.
Relatórios
Cada relatório é uma fotografia imutável das evidências de um período, em PDF, JSON e CSV.
Gerar um relatório agora
Escolha idioma e período
Em Idioma e Período (1), escolha Português (Brasil) ou English e os últimos 7, 30 ou 90 dias.
Gere
Clique em Gerar agora (2). Em alguns segundos aparece "Relatório gerado com sucesso." e o relatório entra no topo do histórico, como Sob demanda.
Só Proprietário e Administrador geram relatórios, até 5 por hora por loja. As outras pessoas podem baixar os que já existem.
Relatório semanal automático
O aviso (3) explica: toda segunda-feira às 09:00 UTC (06:00 em Brasília), o Proteside gera o relatório dos últimos 7 dias e o envia aos canais de notificação da loja. O e-mail traz um link para o PDF, válido por 7 dias, e um link para o relatório no dashboard. O canal E-mail (padrão), criado com a loja, já recebe esse envio. Num canal com eventos filtrados, marque o evento Relatório pronto.
O que o aviso semanal não diz
- Lojas sem nenhum evento do SDK nos últimos 30 dias não recebem o relatório semanal.
- Não há tela para mudar a frequência, o idioma ou desligar o envio. Isso é feito só pela API, que também permite um relatório mensal no lugar do semanal. Veja as receitas da API. Quando a agenda é mudada pela API, o aviso continua falando em relatório semanal.
- Não há lista de destinatários própria: o relatório vai para os canais de notificação ativos.
- Os relatórios só saem em português ou inglês, mesmo com o dashboard em espanhol.
- O histórico da tela mostra os 30 relatórios mais recentes. Os mais antigos continuam disponíveis pela API.
Baixar e verificar
Na coluna Downloads (4) de cada relatório:
| Arquivo | Conteúdo |
|---|---|
| O relatório para leitura: escopo e limitações, requisito 6.4.3, requisito 11.6.1, avaliação periódica, headers, políticas de autorização vigentes, inventário de scripts, log de alertas e aviso legal. Se aparecer PDF indisponível, use o JSON ou gere o relatório de novo. | |
| JSON | Os mesmos dados em formato estruturado, com o identificador e o SHA-256 do relatório. |
| CSV · Scripts, CSV · Headers, CSV · Alertas | As tabelas para planilha, com cabeçalhos em inglês. |
O SHA-256 (5) é a impressão digital do relatório: passe o mouse para ver o valor completo. Ele é calculado sobre os
dados do relatório (o campo data do JSON, com as chaves em ordem alfabética e sem espaços), não sobre o arquivo PDF.
Se alguém alterar os dados, o hash recalculado deixa de bater. O PDF traz o ID do relatório no rodapé, que liga o
documento à linha do histórico.
Verificações
A aba Verificações (1) mostra as execuções periódicas que complementam o monitoramento contínuo do SDK. Elas são evidência independente para o 11.6.1, porque não dependem de clientes visitarem o checkout.
Os dois verificadores (2):
- Sintética: abre as páginas monitoradas num navegador automatizado, executa o SDK e envia as observações. Roda toda segunda-feira.
- Verificador: baixa de novo, no servidor, os scripts externos autorizados ou em revisão, calcula o hash e compara com o hash autorizado. Roda a cada 6 horas. Uma divergência abre um alerta de integridade e devolve o script para revisão.
A coluna Resultado (3) mostra OK, Parcial (parte das páginas ou scripts falhou), Falhou ou Em execução. A coluna Resumo traz as contagens, como scripts verificados e alterados. A coluna Origem (4) diz quem disparou: Agendada, Verificador sintético, Manual ou API.
Se a tabela mostrar Falhou em várias execuções seguidas, confira se as páginas de checkout estão no ar e acessíveis.
Entregar as evidências ao QSA
Deixe o Resumo em Evidência completa
Antes de gerar o relatório final, resolva os pendentes: scripts sem decisão, autorizações vencidas, alertas de adulteração abertos e headers sem autorização.
Escolha os relatórios do período avaliado
Use os relatórios semanais do período ou gere um relatório Sob demanda de 90 dias. Para um período fechado diferente, como o ano da avaliação, gere pela API com datas fixas. Veja as receitas da API.
Baixe os arquivos
Baixe o PDF e o JSON de cada relatório e, se o avaliador pedir planilhas, os três CSV. Anote o SHA-256 de cada um.
Envie com o contexto
Envie os arquivos junto com a descrição do escopo: quais domínios e páginas de pagamento têm o snippet instalado. O PDF lista as páginas monitoradas e as limitações da cobertura. Se o avaliador quiser conferir a integridade, ele pode recalcular o SHA-256 a partir do JSON.
O relatório cobre os requisitos 6.4.3 e 11.6.1 nas páginas em que o SDK está instalado. Ele não substitui a varredura externa de vulnerabilidades feita pelo ASV (requisito 11.3.2) nem os demais requisitos do PCI DSS. Se o ASV ou o adquirente pedirem evidência sobre os scripts da página de pagamento, o mesmo PDF serve.