Proteside Glossário
Os termos do Proteside e do PCI DSS usados nesta documentação, em ordem alfabética.
Os nomes em negrito são os que aparecem no dashboard. Quando um termo tem uma página própria, o link está no fim da definição.
A
Alerta: Aviso de que o SDK ou um verificador encontrou algo suspeito, como um script injetado, um Pix adulterado ou um header alterado. Cada alerta tem severidade, tipo e origem, e fica aberto até ser resolvido. Veja Alertas.
ASV: Approved Scanning Vendor, a empresa aprovada pelo PCI SSC para fazer varreduras externas de vulnerabilidades (requisito 11.3.2). O Proteside não substitui essa varredura.
Autorização: A decisão registrada de que um script pode rodar na página de pagamento. Exige justificativa e pode ter validade de 90, 180 ou 365 dias, ou nenhuma. Ao autorizar, o Proteside fixa o hash do conteúdo do script. Veja Scripts.
Autorização vencida: Autorização cuja validade terminou. O script volta para Precisa revisão e o requisito 6.4.3 passa a pedir ação.
B
Baseline: O primeiro valor observado de um header de segurança. Serve de referência até você autorizar outro valor em Evidências PCI DSS → Headers. Veja Evidências PCI DSS.
Bloqueio: A decisão de impedir que um script rode. Bloquear um script externo cria uma regra que barra o domínio inteiro dele, com subdomínios. O bloqueio só funciona para scripts inseridos por JavaScript: uma tag escrita direto no HTML da página continua carregando até ser removida na origem.
Bootstrapper: A primeira parte do snippet, colada direto no HTML. Roda antes de qualquer outro script e aplica as regras de bloqueio antes que os scripts entrem na página. Veja Integração.
C
Canal de release: A versão do SDK que a loja usa: stable (padrão, versões validadas) ou latest (cada publicação). O canal é
definido pelo endereço do SDK no snippet. Veja Canais stable e latest.
Chave do SDK: O identificador público da loja, no formato pk_live_3f9c…. Vai dentro do snippet e fica em
Configurações → Páginas e Domínios. Não é um segredo, mas identifica a sua loja.
Container GTM: Um contêiner do Google Tag Manager, identificado por GTM-…. Em Proteção do pagamento você pode listar os
contêineres permitidos; os demais são barrados.
CSP: Content Security Policy, o header HTTP que diz ao navegador de onde a página pode carregar scripts e outros recursos. É um dos headers que o Proteside acompanha. Veja CSP e headers.
D
Divergente: Status de integridade de um script cujo conteúdo atual não bate com o hash autorizado. Gera alerta e devolve o script para revisão.
E
Evidência: O registro que mostra ao avaliador que um controle do PCI DSS funciona: inventário, autorizações com justificativa, alertas, verificações e relatórios. O Proteside gera evidência de suporte para os requisitos 6.4.3 e 11.6.1; não é uma certificação. Veja Evidências PCI DSS.
H
Hash: Uma impressão digital do conteúdo, calculada com SHA-256. Qualquer mudança no conteúdo gera outro hash. O Proteside usa hashes para comparar scripts e headers com a versão autorizada e para provar que um relatório não foi alterado.
Header de segurança: Cabeçalho HTTP enviado pelo servidor que reforça a segurança da página, como Content-Security-Policy e
Strict-Transport-Security. O requisito 11.6.1 pede a detecção de mudanças nesses headers.
I
Integridade: A garantia de que um script continua igual ao que foi autorizado. Os status são Íntegro (igual), Divergente (mudou), Pendente (ainda sem hash) e Monitorado (o conteúdo não pode ser lido, então o SDK acompanha o comportamento). Veja Scripts.
Integridade de pagamento: A conferência de que os dados de pagamento exibidos no checkout, como a chave Pix, o QR code e o boleto, são os da sua loja. Veja Integridade de pagamento.
Inventário: A lista de todos os scripts que o SDK viu nas páginas da loja, com tipo, status e histórico. É a base do requisito 6.4.3.
M
Magecart: Nome dado aos grupos e às técnicas de skimming em lojas virtuais. Veja Skimming.
Modo de proteção: Como o SDK reage a uma ameaça. Em Monitorar, ele detecta e alerta. Em Bloquear, ele também tenta desfazer a adulteração, por exemplo restaurando a chave Pix original. As regras de bloqueio valem nos dois modos. Veja Configuração.
Modo desenvolvedor: Pausa o SDK na loja: ele deixa de proteger e a Saúde do SDK mostra o SDK como pausado. Use só durante testes e lembre de desligar.
O
Organização: A sua conta no Proteside. Tem o plano, a cobrança e as lojas. Quem criou a organização é o único que consegue assinar ou trocar de plano.
Origem de iframe esperada: Domínio que pode exibir um iframe no checkout, normalmente o do seu PSP. Um iframe de outra origem gera alerta.
P
Página de pagamento: Qualquer página em que o cliente vê ou informa dados de pagamento, como checkout, carrinho com pagamento e página do Pix. O snippet precisa estar em todas elas para que a cobertura seja completa.
Papel: O nível de acesso de uma pessoa numa loja. Proprietário e Administrador podem alterar dados; Membro e Visualizador só consultam. Veja Equipe.
PCI DSS: O padrão de segurança de dados da indústria de cartões. A versão 4.0 incluiu os requisitos 6.4.3 e 11.6.1, sobre os scripts e a detecção de mudanças nas páginas de pagamento.
Política: Um critério que decide scripts automaticamente, como "autorizar os arquivos do build do site" ou "bloquear ameaças conhecidas". Pode agir sozinha (Automático) ou só sugerir a decisão (Recomendar). Veja Políticas.
PSP: Provedor de serviços de pagamento, como gateway ou subadquirente, que processa o pagamento no checkout.
Q
QSA: Qualified Security Assessor, o auditor qualificado pelo PCI SSC que avalia a conformidade da loja. É a quem você entrega os relatórios de evidência.
R
Re-revisão: Situação de um script que já tinha decisão e voltou para Precisa revisão porque o conteúdo mudou. Aparece na aba Re-revisão de Scripts.
Recebedor confiável: Uma chave Pix, endereço de criptomoeda, VPA UPI ou banco de boleto que pertence à sua loja. O SDK compara o recebedor exibido no checkout com essa lista e alerta na primeira divergência. O Proteside guarda só o hash da chave. Veja Proteção do pagamento.
Regra: Uma ordem direta ao SDK para Bloquear ou Permitir scripts de um domínio ou de uma URL. Uma regra de permissão vence as de bloqueio. Veja Regras.
Relatório: Uma fotografia imutável das evidências de um período, em PDF, JSON e CSV, com SHA-256 para conferência. Gerado toda semana ou sob demanda.
S
SDK: O código do Proteside que roda no navegador do cliente e observa a página de pagamento. Veja Integração.
Script: Um arquivo ou trecho de JavaScript executado na página. Pode ser externo, carregado de um endereço, ou inline, escrito direto no HTML.
Script desconhecido: Script de terceiro cujo domínio não está no catálogo de fornecedores do Proteside. Merece atenção redobrada na revisão.
Script próprio: Script inline ou servido pelo domínio da loja ou por um subdomínio dele.
Script terceiro: Script servido por um fornecedor conhecido do catálogo do Proteside, como um PSP ou uma ferramenta de analytics.
Severidade: A gravidade de um alerta: Crítico, Alto, Médio, Baixo ou Info.
Silenciar: Esconder um alerta aberto por 1, 7 ou 30 dias sem resolvê-lo. O alerta continua aberto e volta a aparecer depois do prazo.
Skimming: O roubo de dados de cartão por um script malicioso inserido na página de pagamento, que copia o que o cliente digita e envia para o atacante. É o principal ataque que os requisitos 6.4.3 e 11.6.1 combatem.
Snippet: O trecho de código que você cola no <head> das páginas de pagamento para carregar o SDK. Fica em
Configurações → Páginas e Domínios. Veja Instalação do snippet.
SRI: Subresource Integrity, o atributo integrity de uma tag <script> que faz o navegador recusar o arquivo se o
conteúdo mudar. O Proteside sugere o valor do atributo nos detalhes de um script.
V
Verificação sintética: Uma visita automática que o Proteside faz às páginas monitoradas, num navegador sem pessoa, para gerar evidência mesmo sem tráfego de clientes.
Verificador: O processo que, a cada 6 horas, baixa de novo no servidor os scripts externos da loja e compara o hash com o autorizado.