Acceso remoto PCI DSS: Secciones 8 y 12 explicadas

Necesitas proporcionar soporte remoto a sistemas que manejan datos de titulares de tarjeta y demostrar a un auditor que cumples con PCI DSS. Eso normalmente implica probar quién se conectó, que estaba autorizado, que se usó autenticación multifactor y privilegios mínimos, y que la sesión y su alcance fueron registrados y aprobados. Este artículo cita los títulos relevantes de los requisitos de PCI DSS, explica qué significan para una sesión de soporte típica y ofrece una lista práctica de controles que puedes presentar a un auditor.

Títulos de requisito citados (líneas cortas)

Aquí están los títulos exactos, de una sola línea, de PCI DSS v4.0 que usaremos como ancla para el resto del artículo:

• "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema."
• "Requisito 12: Mantener una política que aborde la seguridad de la información para empleados y contratistas."

Esos títulos son las líneas oficiales y breves. Ambos conjuntos de requisitos tienen muchas sub‑exigencias; más abajo traduzco las partes de 8 y 12 que realmente aplican cuando un proveedor o técnico de soporte se conecta de forma remota.

Qué exige el Requisito 8 para una sesión de soporte remoto

El Requisito 8 trata sobre identidad y autenticación. Para una sesión de soporte remoto, las implicaciones prácticas son:

• Solo cuentas únicas y atribuibles — no inicios de sesión compartidos. Cada técnico que intervenga un sistema debe usar una cuenta individual y auditable. Si permites que un proveedor use una cuenta compartida para soporte, incumples el Requisito 8.
• Autenticación fuerte y MFA cuando corresponda. PCI exige autenticación multifactor para el acceso al entorno de datos de titulares de tarjeta (CDE) desde redes externas o para acceso administrativo. En la práctica eso significa que el técnico de soporte debe autenticarse con una contraseña más un segundo factor (TOTP, push o token hardware) antes de que la herramienta de soporte abra una sesión hacia sistemas del CDE.
• Acceso con tiempo limitado y privilegios mínimos. Las cuentas o autorizaciones usadas para soporte de proveedores deben limitarse solo a los sistemas y comandos necesarios, y deben ser temporales — creadas o habilitadas únicamente por la ventana de trabajo y revocadas inmediatamente después.
• Flujos de acceso aprobados y registros de inicio de sesión. La organización debe tener un paso de aprobación documentado y auditable (una aprobación por correo o un ticket con firma del responsable/proveedor) que vincule la sesión a una justificación empresarial y a un propietario.
• Reglas de manejo de credenciales. Las credenciales compartidas o codificadas no deben incrustarse en scripts; los secretos usados por el personal de soporte deben emitirse o almacenarse en un vault según su política de credenciales y rotarse al terminar el compromiso.

En otras palabras: el Requisito 8 convierte la pregunta "¿quién se conectó y cómo fue autenticado?" en una serie de comprobaciones binarias — ID única, MFA (cuando se requiera) y una ventana de acceso — que debes mostrar al auditor.

Qué exige el Requisito 12 para una sesión de soporte remoto

El Requisito 12 obliga a las organizaciones a codificar cómo gestionan la seguridad, incluido el acceso de terceros y remoto. Para las sesiones de soporte, las partes que importan son:

• Políticas y procedimientos documentados de acceso remoto. Debes tener una política escrita que defina los métodos de acceso remoto aprobados, el flujo de aprobación, los controles de autenticación requeridos y las expectativas de retención de evidencias para el acceso de proveedores.
• Controles de gestión de terceros/proveedores. Los contratos o Statement of Work deben especificar las obligaciones de seguridad para cualquier proveedor que acceda a sistemas CDE: herramientas aceptables, métodos de autenticación, SLAs de reporte de incidentes y retención de registros de auditoría.
• Aprobaciones de acceso y revisiones periódicas. La política debe exigir que el acceso de proveedores sea aprobado por un propietario autorizado y que los derechos de acceso se revisen periódicamente y se revoquen si ya no son necesarios.
• Respuesta a incidentes y preparación forense. Si una sesión de soporte genera actividad sospechosa, tu plan de IR debe cubrir cómo preservar los registros de sesión, grabaciones y artefactos relevantes para que los investigadores puedan reconstruir el evento.
• Capacitación y concientización. El personal que autoriza o supervisa sesiones de proveedores debe estar capacitado en la política y en cómo validar la identidad del proveedor y el alcance del trabajo.

El Requisito 12 trata, esencialmente, de gobernanza: reglas escritas, herramientas aceptadas, obligaciones contractuales y un proceso repetible de aprobación y auditoría. Un auditor querrá ver la política y la evidencia de que se siguió.

Lista concreta: una sesión de soporte remoto amigable para el auditor

A continuación hay una lista práctica que puedes seguir para cada sesión de soporte remoto que toque el CDE. Mantén los artefactos juntos en el ticket o en el registro de cambio — eso es lo que los auditores esperan revisar.

• Artefacto de autorización: un ticket, un correo firmado o una aprobación de cambio que nombre al solicitante, al aprobador, el alcance y la justificación comercial antes de que comience la sesión.
• Prueba de identidad del usuario: el nombre de cuenta único del técnico y una marca de tiempo de autenticación que muestre el éxito de la MFA. Capturas de pantalla o registros que muestren el éxito del MFA son evidencia aceptable.
• Ventana de tiempo y alcance: marcas de tiempo de inicio y fin de la sesión; lista de hosts objetivo y el trabajo específico realizado (comandos ejecutados o archivos modificados).
• Aplicación de privilegios mínimos: prueba de que la cuenta usada tenía solo los privilegios requeridos (pertenencia a rol o instantánea de privilegios) o que la elevación se concedió explícitamente y con ventana de tiempo.
• Grabación de sesión y registro de auditoría: registros de conexión (IP de origen, host de destino, versión del cliente), un rastro de auditoría de acciones y, cuando tu política lo requiera, una grabación de la sesión o un registro de pulsaciones. Almacena esto en un repositorio resistente a manipulaciones.
• Cambio y rotación de credenciales: si el acceso del proveedor requirió credenciales compartidas o contraseñas privilegiadas, rótalas inmediatamente después del compromiso y registra el evento de rotación.
• Revisión post‑sesión: un gerente o propietario del sistema verifica que el trabajo se completó y certifica que no ocurrieron cambios inesperados; una nota breve post‑soporte añadida al ticket es ideal.
• Nota de retención: almacena la autorización, los registros y las grabaciones según tu política de retención (ver tu política PCI). Hazlos buscables por ticket o identificador de activo para que un auditor pueda reconstruir la sesión en minutos, no semanas.

Esa lista responde tanto al Requisito 8 (quién se autenticó y cómo) como al Requisito 12 (existía un proceso aprobado y documentado y cobertura contractual?).

Dónde encaja el relay o servicio en la nube — el posicionamiento de Tenvo

Si tu herramienta de soporte usa un relay —ya sea operado por un proveedor o propio— debes entender dos hechos contundentes. Primero, las conexiones directas peer‑to‑peer son end‑to‑end entre los dos endpoints. Segundo, cuando el tráfico cae a un relay, la conexión TLS termina en el relay, por lo que quien opere ese relay puede técnicamente acceder al tráfico de la sesión. Esa es una realidad para cualquier servicio de escritorio remoto con relay gestionado; no deberías afirmar que el relay "no puede descifrar" a menos que operes el relay y controles las claves tú mismo.

En Tenvo recomendamos nuestro relay gestionado multi‑región como predeterminado para la mayoría de clientes porque reduce el trabajo operativo: no hay on‑call para los servidores relay, no hay carga de renovación de certificados, y Tenvo proporciona clientes nativos para Windows, macOS y Linux además de un cliente en navegador en beta pública. Nuestras tarifas son Free $0, Lite $2.99/mo, y Pro $7.99/mo. Usa el relay gestionado a menos que tengas un requisito de cumplimiento escrito que prohíba infraestructura de terceros. Si existe tal requisito —mandatos de residencia de datos, una red aislada air‑gapped, o una cláusula contractual que prohíba el hosting por terceros— el auto‑hosting es la elección correcta, pero conlleva los costos de mantenimiento que el auditor esperará que demuestres.

Si eliges el relay gestionado de Tenvo, documenta esa elección en tus artefactos de gestión de proveedores y añade al operador del relay a la lista de partes en el lenguaje contractual de terceros. Esa transparencia es lo que los auditores buscan bajo el Requisito 12.

Paquete de evidencias de ejemplo (qué entregar al auditor)

Cuando un auditor solicite pruebas de una sesión de soporte, entrégale una sola carpeta zip (o un ticket con enlaces) que contenga:

• Extracto de la política: la cláusula de acceso remoto que define aprobaciones, MFA y registro (evidencia del Requisito 12).
• Artefacto de aprobación: el ticket o la aprobación de cambio firmada referenciada en la lista anterior.
• Registros de autenticación: una exportación única que muestre el ID único del técnico, el evento MFA y las marcas de tiempo (evidencia del Requisito 8).
• Registros y grabación de sesión: registro de conexión, registro de acciones y la grabación de la sesión si tu política lo requiere (o la razón por la que no se usó grabación, con controles compensatorios).
• Instantánea de privilegios: el rol o ACL que se aplicó a la cuenta del técnico durante la sesión y una declaración de que el acceso fue con límite de tiempo.
• Lenguaje contractual: acuerdo con el proveedor o SOW que establezca requisitos de seguridad y obligaciones de reporte de incidentes (evidencia del Requisito 12).
• Atestación post‑sesión: confirmación del gerente o propietario del activo de que el trabajo realizado coincidió con el alcance y que las credenciales fueron rotadas si fue necesario.

Entrega estos artefactos con nombres de archivo claros y un documento índice breve que relacione cada archivo con los elementos de la lista — los auditores agradecen el ahorro de tiempo.

Errores comunes y factores que activan al auditor

Estos son errores que vemos regularmente y que al instante alargan el compromiso del auditor:

• Cuentas compartidas. Si varios técnicos usan el mismo inicio de sesión, no puedes atribuir acciones y el auditor te reprobará en el Requisito 8.
• Sin MFA para acceso externo. Si el técnico se autentica desde una red externa y no se usó MFA para entrar al CDE, eso es un hallazgo claro.
• Falta de aprobación previa. Permitir aprobaciones espontáneas y a posteriori ("los dejamos entrar y luego lo documentamos") incumple las expectativas del Requisito 12 sobre proceso documentado.
• Sin registros o marcas de tiempo incompletas. Registros con huecos, relojes inconsistentes o marcas de inicio/fin ausentes obligarán al auditor a solicitar más evidencia.
• Uso no rastreado de herramientas de proveedores. Si un proveedor se conecta con una herramienta que no figura en tu política y no está cubierta por el contrato, el auditor elevará preguntas sobre la gestión de proveedores.

Corrige esto antes de la evaluación: elimina cuentas compartidas, exige MFA para cada conexión remota al CDE, formaliza ventanas de acceso pre‑aprobadas para proveedores y centraliza la recopilación de registros.

Cuándo auto‑hostear un relay — y por qué no es la opción por defecto

Auto‑hostear tu relay (o usar un broker on‑prem) es válido cuando tienes una restricción formal: un lenguaje de cumplimiento escrito que prohíbe infraestructura de terceros; operas en una red aislada; o una ley de residencia de datos te obliga a mantener relays dentro de una región que controlas. Si auto‑hosteas, el auditor esperará que demuestres que operas el relay de forma segura: cadencia de parches, ciclo de vida de certificados, alta disponibilidad, respaldo y un plan de respuesta a incidentes que incluya el relay.

Para la mayoría de las organizaciones, un relay gestionado cuesta menos en total si consideras el tiempo on‑call, el parcheo, la custodia de claves, la renovación de certificados y el riesgo de una sola región sin conmutación por error. El relay gestionado de Tenvo reduce esa carga operativa —pero documenta la elección e incluye al operador del relay en tus controles de terceros.

Lecturas adicionales y guías relacionadas

Si necesitas guías prácticas y referencias de configuración, comienza con estos artículos de Tenvo: Registro de auditoría de Escritorio Remoto para formatos de registro y retención; Cómo darle a alguien acceso remoto para flujos de trabajo seguros de sesión; y Seguridad de Escritorio Remoto: Lo que necesitas saber para el modelo de amenazas general y las opciones de MFA.

Estos te ayudarán a construir los artefactos que los auditores esperan y los hábitos operativos que necesita tu equipo de seguridad.

Conclusión y siguientes pasos

El Requisito 8 de PCI DSS te obliga a demostrar identidad, MFA y privilegios mínimos para cada sesión de soporte. El Requisito 12 te obliga a tener una política escrita y aplicada que rija esas sesiones y a tus proveedores. Combina un flujo de aprobación aplicado, cuentas individuales con MFA, privilegios limitados en el tiempo, registro/grabación de sesiones y controles contractuales para proveedores, y cubrirás las áreas en las que los auditores se enfocan para el soporte remoto.

Si quieres un punto de partida práctico: documenta tu flujo de aprobación, exige cuentas únicas + MFA para todo acceso remoto a sistemas CDE, centraliza los registros de sesión en un repositorio resistente a manipulaciones y registra una atestación después de cada sesión. Usa un relay gestionado como Tenvo para reducir la carga operativa, a menos que una regla escrita te obligue a auto‑hostear.

Descarga Tenvo para probar un flujo de trabajo compatible: Descargar.