Parte de ambas respuestas:
Descargo de responsabilidad: no soy un QSA. Y me estoy desviando de la opinión aquí más de lo que prefiero, así que aplico sal en forma de grano.
Nueva respuesta después de la edición de la pregunta:
Hay dos cambios con el DSS 3 que se relacionan con lo que parece estar flirteando con
- la adición de la nueva categoría SAQ A-EP.
- la pelea de callejón que ha sido iframes versus javascript
que sigue amenazando con romper en alguna forma de
orientación oficial.
Ambos de estos elementos se refieren a la procedencia del flujo de transacciones de tarjetas de crédito. Si voy al sitio web X y hago clic en "Pagar" en su carrito de compras, voy a algún lugar para ingresar los detalles de mi tarjeta de crédito. ¿Dónde está eso en alguna parte? ¿Cómo sé que es donde debo estar? ¿Cómo puedo saber que no es el enrutamiento de mi tráfico a través de Bulgaria primero?
Su negocio parece ser un intermediario de tráfico. Voila, eres exactamente a lo que se dirige PCI para evitar, o al menos asegurar. Desea que sus clientes envíen el tráfico a la perfección y proporcionará un valor X. Pero PCI no quiere que el tráfico sea redirigido a la perfección a menos que haya suficiente seguridad; para asegurarse, por ejemplo, nadie puede editar el proceso para usar un sistema diferente ( página de pago malicioso).
Usted enruta el tráfico basado en el análisis. ¡Genial! Eso significa que un atacante puede usarlo para desviar el tráfico. En términos de PCI, eso significa que estás dentro del alcance o no permitido. Y como proveedor de servicios que se ha mantenido fuera del alcance en el pasado, eso significa que es probable que algo cambie.
Ahora, los problemas de procedencia no se presentan claramente. No puedo apuntar a la sección 13.7 del DSS 3 que dice que lo que estás haciendo está abordado. Pero puedo decirle que los QSA comenzarán a hacer preguntas como "¿Y esta compañía hace qué? ¿Intervienen en su tráfico HTTP, incluido el tráfico que envía a las personas al carrito de compras y al pago?" Entonces querrán ver la certificación de su proveedor de servicios, ya que según la definición de Proveedor de servicios :
Esto también incluye a las empresas que prestan servicios que controlan o
podría afectar la seguridad de los datos del titular de la tarjeta.
Entonces, sí, podría terminar con problemas a medida que avanza el cambio a DSS 3. Todavía no me siento confiado. Entiendo su negocio, por lo que no puedo decir nada con seguridad, pero si está en medio del tráfico, está en la lista y puede perder clientes si no es un proveedor de servicios certificado. (Prolexic no lo es. Akamai es. ¿Quién puede decirlo?)
Respuesta original a continuación:
Recientemente realicé una comparación línea por línea de PCI DSS v2 frente a v3, y no recuerdo nada dentro del propio DSS que pudiera afectar el tránsito del tráfico HTTPS a través de un proveedor. La Sección 4 trata sobre el cifrado de "datos de titulares de tarjetas a través de redes abiertas y públicas" y sería el lugar obvio para buscar, y eso apenas ha cambiado.
Dicho esto, dos advertencias:
1) El DSS no es lo único a lo que se debe prestar atención. La redacción de los SAQ, si se aplican a las empresas en cuestión, y otros documentos de orientación que explican el significado de los QSA también son importantes.
2) No me queda completamente claro que su servicio es simplemente un conducto de tráfico cifrado. Usted declara que sus clientes "vuelven a apuntar su DNS a la dirección IP de nuestra aplicación y nuestra aplicación analizará el tráfico y luego lo enrutará según corresponda". La frase "analizar el tráfico" atraerá a cualquier QSA para una mirada más profunda. No debería tener mucho con qué trabajar para el análisis, en el caso de HTTPS; tendría que permitir que la negociación de SSL a través del verdadero backend para establecer HTTPS antes de que el canal estuviera seguro de usted, y si eso es todo lo que está haciendo, su servicio no está haciendo mucho. En resumen, no creo que tengamos suficientes detalles sobre su servicio para brindarle consejos sólidos.