Proteside Evidencias PCI DSS
Sigue los requisitos 6.4.3 y 11.6.1, autoriza los headers de seguridad, genera reportes y entrega las evidencias a tu QSA.
La pantalla Evidencias PCI DSS, en el grupo Cumplimiento del menú, reúne lo que Proteside registra sobre las páginas de pago para los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0. Muestra el estado de cada requisito, los headers de seguridad, los reportes para descargar y las verificaciones periódicas.
Disponible a partir del plan Standard
En el plan Essential y en la prueba gratuita sin plan, la pantalla aparece bloqueada, con el botón Ver planes. Consulta Facturación.
Proteside genera evidencia de soporte. La propia pantalla advierte que "no es una certificación de cumplimiento": quien evalúa el cumplimiento es tu QSA, o tu equipo, en el cuestionario de autoevaluación.
Qué piden los requisitos
| Requisito | En lenguaje simple | Cómo genera Proteside la evidencia |
|---|---|---|
| PCI DSS 4.0, requisito 6.4.3 | Todo script que se ejecuta en la página de pago tiene que estar inventariado, tener una justificación de por qué está ahí y estar autorizado. También tienes que garantizar que el script no se modificó. | El SDK arma el inventario de scripts por sí solo. Cada autorización en Scripts registra quién decidió, cuándo y por qué. El hash del contenido se fija en la autorización, y cualquier cambio devuelve el script a revisión. |
| PCI DSS 4.0, requisito 11.6.1 | Necesitas un mecanismo que detecte cambios no autorizados en los headers HTTP y en el contenido de la página de pago, evaluado al menos cada 7 días. | El SDK observa cada visita al checkout. Un verificador en el servidor revisa el contenido de los scripts cada 6 horas, y un verificador sintético abre las páginas monitoreadas cada semana. Los cambios generan alertas. |
Resumen
Las pestañas Resumen, Cabeceras, Informes y Verificaciones (1) organizan la pantalla. El número en rojo de la pestaña Resumen cuenta las alertas de manipulación abiertas: divergencia de integridad, script modificado o inyectado y header modificado.
La tarjeta Requisito 6.4.3 — Integridad de scripts en la página de pago (2) y la tarjeta Requisito 11.6.1 — Detección de cambios y manipulación (3) muestran uno de estos estados:
| Estado | 6.4.3 | 11.6.1 |
|---|---|---|
| Evidencia completa | Todos los scripts tienen una decisión y ninguna autorización venció. | Hubo actividad del SDK o una verificación en los últimos 7 días y no hay ninguna alerta de manipulación abierta. |
| Atención | El inventario todavía está vacío. | No se usa. |
| Acción requerida | Hay un script Requiere revisión, una autorización vencida o un script bloqueado que sigue cargando. | No hubo eventos del SDK ni verificaciones en los últimos 7 días, o hay una alerta de manipulación abierta. |
Debajo de cada tarjeta aparecen los números y los atajos para resolver:
- Scripts esperando decisión (4): haz clic en Revisar scripts y autoriza o bloquea cada uno.
- Autorizaciones vencidas: reautoriza los scripts en Scripts.
- Scripts bloqueados que siguen cargando: el bloqueo solo funciona para scripts insertados por JavaScript. Quita la etiqueta del HTML de la página.
- Sin eventos del SDK ni verificaciones: haz clic en Verificar instalación y revisa el snippet.
- Alertas de manipulación abiertas: haz clic en Ver alertas y atiende cada una en Alertas.
Los scripts con la revisión programada vencida solo generan un aviso y no cambian el estado del 6.4.3.
El Registro de autorización de scripts (5) es el historial de las decisiones: Cuándo, Script, Revisor, Método, Justificación y Decisión. El revisor aparece por su nombre, nunca por su correo. Las decisiones automáticas aparecen como Sistema, Política: … o Token de API …. Haz clic en Mostrar más para ver las decisiones más antiguas.
Cabeceras
El requisito 11.6.1 también pide que detectes cambios en los headers HTTP de seguridad. La pestaña Cabeceras (1)
lista los 12 headers que el SDK observa en las páginas de pago, como Content-Security-Policy,
Strict-Transport-Security y X-Frame-Options, más cualquier otro header que encuentre.
Las columnas Presente y Estado (2) muestran si se vio el header y cómo está con respecto a la referencia:
| Estado | Significado |
|---|---|
| Sin cambios | El valor es igual a la referencia. |
| Modificada | El valor cambió. Se abrió una alerta Header de Seguridad Modificado (HEADER_CHANGED). |
| Ausente | La página no envía ese header. |
| No recolectable | El navegador no permite leer ese header. Set-Cookie siempre aparece así, y es lo esperado. |
| Esperando observación | El SDK todavía no visitó la página con ese header. |
Mientras no autorices nada, la referencia es el primer valor observado (el baseline). Para fijar el valor de hoy como referencia:
Haz clic en Autorizar valor actual
En la fila del header, haz clic en Autorizar valor actual (3).
Escribe la justificación
Explica de dónde viene el valor, con al menos 10 caracteres. Ejemplo: "nueva CSP publicada el 12/09 por el equipo de plataforma (ticket #123)".
Confirma
Haz clic en Confirmar. La tabla pasa a mostrar quién autorizó y cuándo. A partir de ahí, cualquier cambio en el
valor genera la alerta HEADER_CHANGED.
Cuando cambias un header a propósito, el estado queda como Modificada y el botón pasa a ser Aceptar nuevo valor. Úsalo, con justificación, para registrar el cambio como autorizado. Quitar autorización hace que la comparación vuelva al baseline.
Solo el Propietario y el Administrador autorizan headers. Las demás personas ven la tabla sin la columna Acciones.
Informes
Cada reporte es una fotografía inmutable de las evidencias de un período, en PDF, JSON y CSV.
Generar un reporte ahora
Elige el idioma y el período
En Idioma y Período (1), elige Português (Brasil) o English y los últimos 7, 30 o 90 días.
Genera
Haz clic en Generar ahora (2). En pocos segundos aparece "Informe generado con éxito." y el reporte entra arriba del historial, como Bajo demanda.
Solo el Propietario y el Administrador generan reportes, hasta 5 por hora por tienda. Las demás personas pueden descargar los que ya existen.
Reporte semanal automático
El aviso (3) lo explica: cada lunes a las 09:00 UTC (06:00 en Brasilia), Proteside genera el reporte de los últimos 7 días y lo envía a los canales de notificación de la tienda. El correo trae un enlace al PDF, válido por 7 días, y un enlace al reporte en el dashboard. El canal E-mail (padrão) ("Correo (predeterminado)"), creado con la tienda, ya recibe este envío. En un canal con eventos filtrados, marca el evento Reporte listo.
Lo que el aviso semanal no dice
- Las tiendas sin ningún evento del SDK en los últimos 30 días no reciben el reporte semanal.
- No hay una pantalla para cambiar la frecuencia o el idioma, ni para desactivar el envío. Eso solo se hace por la API, que también permite un reporte mensual en lugar del semanal. Consulta las recetas de la API. Cuando la programación se cambia por la API, el aviso sigue hablando de un reporte semanal.
- No hay una lista de destinatarios propia: el reporte va a los canales de notificación activos.
- Los reportes solo salen en portugués o en inglés, incluso con el dashboard en español.
- El historial de la pantalla muestra los 30 reportes más recientes. Los más antiguos siguen disponibles por la API.
Descargar y verificar
En la columna Descargas (4) de cada reporte:
| Archivo | Contenido |
|---|---|
| El reporte para leer: alcance y limitaciones, requisito 6.4.3, requisito 11.6.1, evaluación periódica, headers, políticas de autorización vigentes, inventario de scripts, registro de alertas y aviso legal. Si aparece PDF no disponible, usa el JSON o genera el reporte de nuevo. | |
| JSON | Los mismos datos en formato estructurado, con el identificador y el SHA-256 del reporte. |
| CSV · Scripts, CSV · Headers, CSV · Alertas | Las tablas para hoja de cálculo, con encabezados en inglés. |
El SHA-256 (5) es la huella digital del reporte: pasa el mouse para ver el valor completo. Se calcula sobre los
datos del reporte (el campo data del JSON, con las claves en orden alfabético y sin espacios), no sobre el archivo
PDF. Si alguien modifica los datos, el hash recalculado deja de coincidir. El PDF trae el ID del reporte en el pie
de página, que vincula el documento con la fila del historial.
Verificaciones
La pestaña Verificaciones (1) muestra las ejecuciones periódicas que complementan el monitoreo continuo del SDK. Son evidencia independiente para el 11.6.1, porque no dependen de que los clientes visiten el checkout.
Los dos verificadores (2):
- Sintética: abre las páginas monitoreadas en un navegador automatizado, ejecuta el SDK y envía las observaciones. Se ejecuta todos los lunes.
- Verificador: vuelve a descargar, en el servidor, los scripts externos autorizados o en revisión, calcula el hash y lo compara con el hash autorizado. Se ejecuta cada 6 horas. Una divergencia abre una alerta de integridad y devuelve el script a revisión.
La columna Resultado (3) muestra OK, Parcial (falló una parte de las páginas o de los scripts), Falló o En ejecución. La columna Resumen trae los conteos, como scripts verificados y modificados. La columna Origen (4) indica quién la disparó: Programada, Verificador sintético, Manual o API.
Si la tabla muestra Falló en varias ejecuciones seguidas, verifica que las páginas de checkout estén en línea y accesibles.
Entregar las evidencias al QSA
Deja el Resumen en Evidencia completa
Antes de generar el reporte final, resuelve lo pendiente: scripts sin decisión, autorizaciones vencidas, alertas de manipulación abiertas y headers sin autorización.
Elige los reportes del período evaluado
Usa los reportes semanales del período o genera un reporte Bajo demanda de 90 días. Para un período cerrado distinto, como el año de la evaluación, genéralo por la API con fechas fijas. Consulta las recetas de la API.
Descarga los archivos
Descarga el PDF y el JSON de cada reporte y, si el evaluador pide hojas de cálculo, los tres CSV. Anota el SHA-256 de cada uno.
Envíalos con el contexto
Envía los archivos junto con la descripción del alcance: qué dominios y páginas de pago tienen el snippet instalado. El PDF lista las páginas monitoreadas y las limitaciones de la cobertura. Si el evaluador quiere comprobar la integridad, puede recalcular el SHA-256 a partir del JSON.
El reporte cubre los requisitos 6.4.3 y 11.6.1 en las páginas en las que está instalado el SDK. No reemplaza el escaneo externo de vulnerabilidades que hace el ASV (requisito 11.3.2) ni los demás requisitos de PCI DSS. Si el ASV o el adquirente piden evidencia sobre los scripts de la página de pago, sirve el mismo PDF.