Los requisitos para un hosting compatible con PCI DSS

El alojamiento compatible con PCI es una infraestructura de alojamiento cuyos servicios evaluados y controles de seguridad pueden ayudar a un comerciante o proveedor de servicios a trabajar para cumplir con PCI DSS. Puede cubrir el centro de datos, el hardware, el hipervisor, la red y servicios gestionados seleccionados. No hace que el sitio web, la aplicación o el proceso de pago del cliente cumplan automáticamente.

Esa distinción cambia la forma en que se debe seleccionar un proveedor. Una larga lista de características de seguridad es menos útil que tres respuestas precisas: ¿Qué evaluó el proveedor? ¿Cuál de esos servicios usaremos realmente? ¿A quién pertenece cada control que queda?

PrivaLex aborda el alojamiento PCI como una decisión de arquitectura y garantía del proveedor. El objetivo no es encontrar un servidor que lleve una etiqueta PCI. Se trata de crear un entorno de pago en el que los controles validados del proveedor y los controles del cliente se encuentren sin espacios no asignados.

Alojamiento compatible con PCI en un minuto

El estándar actual es PCI DSS v4.0.1, disponible a través del Biblioteca de documentos del PCI Security Standards Council oficial. Establece requisitos técnicos y operativos para proteger los datos de las cuentas de pago.

Un servicio de alojamiento adquiere relevancia cuando almacena, procesa o transmite datos de cuentas, proporciona controles utilizados para cumplir con PCI DSS o puede afectar la seguridad del entorno de datos del titular de la tarjeta.

El proveedor puede asumir la responsabilidad de la seguridad física, el aislamiento de la plataforma o un firewall administrado. El cliente aún puede ser responsable de:

• Código de página de pago y scripts de terceros.
• Vulnerabilidades de aplicaciones y lanzamientos de software seguros.
• Grupos de seguridad en la nube y configuración de inquilinos.
• Cuentas de usuario, acceso privilegiado y autenticación multifactor.
• Selección de registros, manejo y retención de alertas.
• Corrección de vulnerabilidades y pruebas de penetración.
• Decisiones de incidentes, notificaciones y coordinación forense.
• Validación PCI DSS a través de la vía requerida por su adquirente o marca de pago.

La frase PCI-ready no tiene valor sin alcance y evidencia. Puede describir características técnicas útiles, pero no nos dice si una evaluación independiente cubrió el servicio que se vende.

Primero identifica tu modelo de pago

La pregunta sobre alojamiento no se puede responder antes de que se mapee el proceso de pago. Dos comerciantes que utilizan el mismo proveedor de nube pueden tener una exposición completamente diferente porque sus implementaciones de pago difieren.

Redirigir a una página alojada por el proveedor: el cliente abandona el sitio del comerciante para ingresar los detalles de pago. El alcance del comerciante puede ser menor, pero el sitio web que inicia la redirección y la supervisión del proveedor de pagos siguen siendo importantes.

Formulario de proveedor integrado o iframe: los campos de pago los proporciona un tercero dentro de la experiencia del comerciante. La página circundante aún puede influir en la seguridad de los pagos mediante scripts, contenido comprometido o cambios no autorizados.

API directa o procesamiento de aplicaciones: los datos de la tarjeta pasan a través de componentes de aplicaciones controlados por el comerciante. Por lo tanto, la seguridad de las aplicaciones, la configuración del alojamiento, el acceso, el registro y las pruebas técnicas se vuelven fundamentales para el entorno.

Datos de cuenta almacenados: la empresa conserva los datos de los titulares de tarjetas permitidos para un propósito definido. El almacenamiento, la retención, el cifrado, el acceso a claves, las copias de seguridad y la eliminación verificada requieren un análisis minucioso.

Antes de comprar alojamiento especializado, pregunte si la arquitectura puede eliminar los datos de la tarjeta. Una página alojada en un procesador, la tokenización o el rediseño de una integración pueden reducir el alcance de manera más efectiva que agregar controles a un entorno grande.

La subcontratación no elimina las responsabilidades PCI DSS del comerciante. PCI SSC explica que un comerciante subcontratado aún tiene que asegurarse de que el proveedor cumpla con los servicios ofrecidos, mantener acuerdos de responsabilidad por escrito, monitorear el estado del proveedor y comprender las responsabilidades compartidas.

El orientación sobre procesamiento de pagos subcontratados del Consejo también aconseja a los comerciantes que confirmen sus obligaciones de validación con el adquirente o la marca de pago correspondiente.

No te quedes con el sello: pide el paquete de evidencias

La cuestión decisiva no es si en el sitio web del proveedor aparece «compatible con PCI». Es si el proveedor puede suministrar documentos que apliquen al servicio contratado.

La certificación de cumplimiento

Solicite la Declaración de Cumplimiento del proveedor de servicios actual, o AOC. Revisar la entidad evaluada, fecha de validación, descripción del servicio, ubicaciones, exclusiones y resultado.

Un AOC para una entidad corporativa no cubre necesariamente a todas las subsidiarias. Una plataforma en la nube evaluada no incluye necesariamente sistemas operativos administrados, copias de seguridad, entrega de contenido, administración de soporte o una región separada vendida bajo la misma marca.

Registre el aniversario de la evaluación de la AOC. Es posible que un documento que era válido durante la adquisición ya no proporcione garantía actual cuando comience la evaluación del propio cliente.

La descripción del servicio

Haga coincidir el AOC con el formulario de pedido y el diseño técnico. La denominación del producto es a menudo el punto donde falla la seguridad. El contrato puede hacer referencia a un paquete gestionado premium, mientras que el AOC describe sólo la infraestructura subyacente.

• Cree una breve conciliación que muestre:
• Nivel de producto y servicio contratado.
• Región de alojamiento y ubicaciones físicas.
• Componentes gestionados incluidos en el pedido.
• Los subcontratistas solían entregar esos componentes.
• Idioma correspondiente en la AOC.
• Diferencias no resueltas que requieren confirmación por escrito.

La matriz de responsabilidad

El proveedor debe indicar qué requisitos PCI DSS cumple, cuáles son compartidos y cuáles permanecen con el cliente. La matriz debe ser específica del servicio y ser utilizable por los propietarios del control.

PrivaLex prueba estas matrices solicitando evidencia detrás de una muestra de responsabilidades de proveedores y clientes. Esto es similar a documentar los controles de seguridad para que se mantengan en la auditoría: una declaración de control solo es útil cuando apunta a un sistema, propietario y registro real.

Construya el mapa de responsabilidades antes de comparar proveedores

Un mapa de responsabilidad práctico debería ir más allá de “proveedor” y “cliente”. Debe explicar qué hace cada parte y qué puede conservar el cliente como prueba.

• Seguridad física. El proveedor podrá operar el acceso a las instalaciones, la vigilancia y la protección de equipos. El cliente aún debe confirmar que la instalación contratada aparece dentro del alcance evaluado y conservar el AOC correspondiente.
• Protección de red. El proveedor puede proteger el perímetro de la plataforma o proporcionar funciones de aislamiento y firewall administrado. El cliente debe configurar las reglas del inquilino, documentar los flujos de pago y conservar los cambios y revisiones de las reglas aprobadas.
• Endurecimiento del sistema. El proveedor puede reforzar el hipervisor o un sistema operativo administrado. El cliente sigue siendo responsable de los sistemas, aplicaciones y servicios innecesarios no administrados, respaldados por una línea base de configuración y resultados de revisión.
• Identidad y acceso administrativo. La plataforma puede ofrecer capacidades de IAM y controles de fuerza laboral de proveedores. El cliente debe hacer cumplir las cuentas individuales, MFA, privilegios mínimos y revisiones periódicas mientras conserva las listas de acceso y las aprobaciones.
• Cifrado y claves. El proveedor puede ofrecer servicios de cifrado y claves administradas. El cliente decide qué datos están cubiertos, quién puede usar las claves y cómo se manejan la rotación, las copias de seguridad y las réplicas.
• Registro y seguimiento. El proveedor puede generar o almacenar registros de la plataforma. El cliente elige las fuentes relevantes, la retención y el manejo de alertas, luego retiene la evidencia de las investigaciones y las decisiones de respuesta.
• Gestión de vulnerabilidades. El proveedor puede parchear la plataforma y admitir el escaneo. El cliente debe corregir los hallazgos de la aplicación y administrados por el cliente y documentar cualquier excepción de tiempo limitado.
• Respuesta al incidente. El proveedor investiga su entorno y notifica al cliente en virtud del contrato. El cliente activa su propio plan, conserva pruebas y coordina con tasadores, adquirentes y otras partes del pago.

Ninguna responsabilidad debería quedar simplemente marcada como “compartida”. Compartido debe descomponerse en acción del proveedor, acción del cliente y evidencia de transferencia.

Compare los modelos de hosting por responsabilidad, no por prestigio

La infraestructura dedicada no es automáticamente más compatible que el alojamiento en la nube. Un mayor control también puede crear una mayor responsabilidad operativa.

El alojamiento compartido puede funcionar en un entorno de baja complejidad cuando el proveedor puede demostrar un aislamiento eficaz de los inquilinos y proporcionar pruebas utilizables. La cuestión decisiva es si el proveedor puede demostrar la separación y satisfacer las expectativas PCI DSS aplicables a su modelo de servicio.

Un VPS administrado puede proporcionar aislamiento sin que el cliente opere todas las capas del sistema. El contrato aún debe identificar exactamente dónde termina la administración y quién parchea la aplicación, las dependencias y los componentes no compatibles.

El hosting dedicado o bare-metal proporciona un fuerte aislamiento y control arquitectónico. También le brinda al cliente más opciones para reforzar, monitorear, parchear y recuperar. Elíjalo sólo cuando la organización pueda operar esas responsabilidades de manera consistente.

La nube pública puede soportar servicios de seguridad escalables y automatización. Su principal riesgo no es el modelo de nube en sí, sino los límites poco claros de los servicios administrados y la configuración del cliente que varía después de la implementación.

Una nube privada administrada puede adaptarse a entornos complejos que necesitan soporte personalizado. A medida no significa evaluado, por lo que cada servicio, ubicación y función administrativa aún debe conciliarse con el AOC.

La opción correcta depende del modelo de pago, la capacidad de ingeniería interna, la evidencia requerida y el costo total de operar los controles del lado del cliente.

Utilice preguntas consistentes con los proveedores durante la adquisición

Las comparaciones de proveedores a menudo fallan porque una cotización incluye seguridad administrada mientras que otra cotiza solo la infraestructura. Hacer las mismas preguntas a todos los proveedores expone esas diferencias.

• ¿Puede mostrar dónde aparece exactamente este producto, región y nivel de servicio en el AOC?
• ¿Proporciona una matriz de responsabilidad a nivel de requisitos para este servicio?
• ¿Cómo se implementa y prueba la separación de clientes?
• ¿Cuándo puede el personal de soporte acceder al entorno y cómo se aprueba y registra ese acceso?
• ¿Qué capas de sistema y productos parchean y a qué nivel de servicio?
• ¿Qué registros podemos exportar y cuánto tiempo se conservan?
• ¿Se pueden realizar escaneos ASV, pruebas de penetración y pruebas de segmentación sin obstáculos contractuales?
• ¿Qué aviso de incidente, pruebas y asistencia forense proporcionarán?
• ¿Qué subcontratistas y ubicaciones respaldan el servicio y cómo se comunicarán los cambios?
• ¿Cómo se devolverán o destruirán los datos de la cuenta, las instantáneas, las copias de seguridad y las claves al salir?

Trate el lenguaje vago como un hallazgo. “Nosotros manejamos la infraestructura”, “totalmente administrada” y “asistencia comercialmente razonable” no establecen límites. Pídale al proveedor que nombre el componente, la acción, la evidencia y el momento.

La calidad de la evidencia también debería afectar la evaluación. El “Sí” respaldado por la AOC y el contrato es más fuerte que el “sí” declarado durante una llamada de ventas.

Recoge las garantías clave en el contrato

Los documentos del proveedor describen el estado actual. El contrato determina qué sucede cuando ese estado o servicio cambia.

Las disposiciones pertinentes pueden incluir:

• Reconocimiento de las responsabilidades PCI DSS del proveedor.
• Entrega de AOC vigente y matriz de responsabilidades.
• Notificación anual o evidencia de estatus de cumplimiento renovado.
• Aviso de cambios en el alcance material, región, subcontratista o servicio.
• Tiempos de notificación de incidentes de seguridad e información mínima.
• Acceso a registros, informes y otras pruebas necesarias para la validación.
• Cooperación con el tasador, adquirente o investigador forense del cliente.
• Expectativas de remediación cuando fallan los controles del proveedor.
• Devolución, eliminación y confirmación seguras al finalizar el contrato.

El contrato no debe prometer que el proveedor “hará que el cliente cumpla con PCI”. Debe definir los controles y las pruebas que el proveedor se compromete a ofrecer.

Trata el onboarding como una transferencia de garantías

La adquisición se completa sólo cuando las pruebas y las responsabilidades han llegado a los equipos que las operarán.

Antes de firmar el contrato

Complete el mapa de flujo de pagos, concilie el AOC con el servicio propuesto e identifique los controles propiedad del cliente. Intensifique cualquier ambigüedad que pueda cambiar materialmente el alcance, el costo o la validación.

Antes de que comience el tráfico de producción

Fortalezca las capas administradas por el cliente, configure MFA y privilegios mínimos, pruebe el registro, confirme los objetivos de escaneo y valide los supuestos de segmentación. Actualice el inventario del sistema y el diagrama de flujo de datos para que coincidan con el entorno implementado en lugar de con la propuesta de diseño.

Cuando los datos confidenciales de la nube y los activos no administrados son difíciles de localizar, plataforma de seguridad de datos en la nube de PrivaLex puede proporcionar visibilidad adicional. No reemplaza la evaluación PCI DSS, pero puede ayudar a los equipos a encontrar la exposición que un diagrama estático pasa por alto.

Una vez que el servicio esté activo

Colocar la garantía del proveedor en el calendario operativo. Realice un seguimiento del aniversario de AOC, acceda a revisiones, resultados de análisis, vulnerabilidades, cambios de script, incidentes y notificaciones contractuales.

La automatización puede recopilar evidencia y señalar cambios en la configuración, pero necesita un propietario de control acordado y una ruta de escalada. Automatización del cumplimiento normativo explica brevemente por qué conectar herramientas antes de definir el modelo de control simplemente digitaliza la incertidumbre.

Entiende qué determina el coste real

El precio mensual del servidor es sólo una parte del alojamiento compatible con PCI. Compare el costo operativo total dentro del mismo límite de responsabilidad.

Los principales generadores de costos son:

• Capas administradas versus no administradas. Los sistemas no administrados requieren refuerzo interno, parches, monitoreo y evidencia.
• Modelo de aislamiento. Las redes dedicadas, los hosts o los entornos privados pueden aumentar el costo de la infraestructura.
• Registro y retención. El seguimiento central, la exportación y la retención más prolongada se pueden cotizar por separado.
• Servicios de vulnerabilidad. Es posible que no se incluyan escaneos ASV, escaneos internos, pruebas de penetración y soporte de remediación.
• Disponibilidad y recuperación. Las réplicas, las copias de seguridad cifradas, los ejercicios de recuperación y las regiones secundarias añaden controles y costos.
• Evidencia y apoyo del evaluador. La preparación de documentos y la participación técnica pueden ser un nivel de servicio separado.
• Migración y salida. La transferencia segura de datos, la operación paralela y la eliminación verificada pueden requerir trabajo de proyecto.

Solicite a cada proveedor que fije el precio del mismo diseño objetivo y enumere las exclusiones. Un presupuesto de infraestructura más económico puede convertirse en la opción más cara cuando el cliente tiene que suministrar varios controles faltantes.

10 señales de advertencia en una propuesta de alojamiento PCI

Detén el proceso de selección si encuentras alguna de estas señales:

• El proveedor no compartirá un AOC ni explicará una ruta de evaluación alternativa.
• El AOC no se puede relacionar con el servicio o región exactos.
• Preparado para PCI y compatible con PCI se utilizan indistintamente.
• La matriz de responsabilidades contiene grandes áreas “compartidas” sin tareas.
• Los límites del servicio administrado no se reflejan en el contrato.
• El proveedor no puede explicar el acceso administrativo ni la disponibilidad de registros.
• Las pruebas de seguridad están restringidas sin un proceso de coordinación viable.
• La asistencia en caso de incidentes se describe únicamente como comercialmente razonable.
• No existe ningún proceso para notificar a los clientes sobre cambios en el estado de cumplimiento.
• Los términos de salida no dicen nada sobre copias de seguridad, claves y pruebas de eliminación.

Estos signos no siempre descalifican a un proveedor, pero cada uno crea incertidumbre que debe resolverse antes de confiar.

Lo que ofrece una revisión de alojamiento PrivaLex PCI

Una revisión de alojamiento PrivaLex PCI está diseñada en torno a un problema específico de decisión, migración o validación de un proveedor. No reproduce el programa PCI DSS completo de la organización en un informe de madurez genérico.

Mapa de límites de la ruta de pago: el equipo puede ver qué páginas de comerciantes, aplicaciones, integraciones y servicios de alojamiento pueden afectar los datos de la cuenta.

Conciliación entre AOC y contrato: los servicios, regiones o componentes administrados que la garantía actual del proveedor no cubre claramente se identifican antes de la confianza.

Matriz de responsabilidad ejecutable: cada actividad propiedad del cliente recibe un operador designado, una fuente de evidencia y un cronograma en lugar de permanecer en una categoría compartida amplia.

Hoja de normalización de cotizaciones: los proveedores se pueden comparar con los mismos límites técnicos y de garantía en lugar de los precios principales de los servidores.

Paquete de remediación y validación: las brechas de prioridad se organizan en torno al SAQ acordado, la ruta de revisión del evaluador o del cliente para que el equipo sepa qué se debe resolver antes de la validación.

PrivaLex también puede unirse a las llamadas de proveedores para probar afirmaciones poco claras sobre la arquitectura y los documentos. Cuando se requiere una evaluación formal, el adquirente, la marca de pago, el asesor de seguridad calificado u otro profesional autorizado de PCI conserva la responsabilidad de la ruta de validación y la conclusión independiente.

Esta revisión es particularmente útil para las empresas de comercio electrónico que cambian el diseño de pago, los proveedores de SaaS que ingresan a los flujos de pago, las plataformas que reemplazan a un proveedor de nube y las organizaciones cuyo host existente ya no puede demostrar que el servicio implementado se encuentra dentro de su alcance evaluado.

Conclusión

La decisión de hospedaje debe finalizar con tres documentos que coincidan: el mapa de flujo de pagos, el alcance de garantía actual del proveedor y la matriz de responsabilidad del cliente. Si un servicio aparece en la arquitectura pero no en el AOC, o un requisito aparece en la matriz sin un propietario, el entorno no está listo para confiar en él.

El alojamiento compatible con PCI admite la validación cuando los controles del proveedor y del cliente cubren la ruta de pago completa, siguen siendo comprobables después de cambios en el servicio y producen evidencia con la frecuencia requerida. Se trata de un estándar de compra más estricto que seleccionar el proveedor con la lista de funciones más larga o la insignia de cumplimiento más destacada.

Si desea probar si un modelo de hosting actual o propuesto puede soportar sus obligaciones PCI DSS, Solicite su evaluación de riesgos gratuita o reservar una sesión de revisión de proveedores con nuestro equipo.

Preguntas frecuentes (FAQs)