Parte di entrambe le risposte:
Dichiarazione di non responsabilità: non sono un QSA. E qui mi sto allontanando dall'opinione di quanto preferisco, quindi applica il sale in grana.
Nuova risposta dopo la modifica della domanda:
Ci sono due modifiche con DSS 3 che si basano su ciò con cui sembri flirtare
- l'aggiunta della nuova categoria SAQ A-EP.
- il litigio sul retro che è stato iframe contro javascript
che continua a minacciare di scoppiare in una qualche forma di
guida ufficiale.
Entrambe queste voci riguardano la provenienza del flusso delle transazioni con carta di credito. Se vado sul sito X, e clicco su "Check out" dal loro carrello, vado da qualche parte per inserire i dettagli della mia carta di credito. Dov'è da qualche parte? Come faccio a sapere che è dove sono destinato a essere? Come faccio a sapere che non instrado il mio traffico attraverso la Bulgaria per primo?
La tua attività sembra essere un intermediario del traffico. Voilà, sei esattamente ciò che il PCI si sta muovendo per evitare, o almeno per assicurare. Desiderate che i vostri clienti inviino senza problemi il traffico e fornirete il valore X. Ma PCI non vuole che il traffico venga reindirizzato senza problemi a meno che non ci sia una sicurezza sufficiente: per esempio, nessuno può modificare il processo per utilizzare un altro ( malevola) pagina di checkout.
Si indirizza il traffico in base all'analisi. Grande! Ciò significa che un utente malintenzionato può utilizzarti per reindirizzare il traffico. In termini PCI, significa che sei nell'ambito o non autorizzato. E come fornitore di servizi che è rimasto fuori dal campo di applicazione in passato, significa che è probabile che qualcosa cambi.
Ora, i problemi di provenienza non sono chiaramente definiti. Non posso puntare a DSS 3 sezione 13.7 che dice che quello che stai facendo è indirizzato. Ma posso dirti che i QSA inizieranno a fare domande del tipo "E questa azienda fa cosa? Intermedia tutto il tuo traffico HTTP, incluso il traffico che manda le persone al carrello della spesa e alla cassa?" Quindi vorranno vedere la certificazione del fornitore di servizi, in base alla definizione del fornitore di servizi :
This also includes companies that provide services that control or
could impact the security of cardholder data.
Quindi, sì, potresti avere problemi con il passaggio al DSS 3. Non mi sento ancora sicuro di aver capito la tua attività, quindi non posso dire nulla di sicuro, ma il tuo traffico è mediocre, sei nella lista e potresti perdere clienti se non sei un fornitore di servizi certificato. (Prolexic is not. Akamai is. Chi può dire?)
Risposta originale di seguito:
Recentemente ho eseguito un confronto riga-per-riga di PCI DSS v2 rispetto a v3 e non ricordo nulla all'interno del DSS stesso che possa influire sulla traversata del traffico HTTPS attraverso un provider. La sezione 4 riguarda la crittografia dei "dati dei titolari di carta su reti pubbliche aperte" e sarebbe il posto più ovvio da guardare, e questo è appena cambiato.
Detto questo, due avvertimenti:
1) Il DSS non è l'unica cosa a cui prestare attenzione. Anche la formulazione dei questionari SAQ, se si applicano alle attività in questione, e vari altri documenti di orientamento che elaborano il significato dei QSA sono importanti.
2) Non è del tutto chiaro per me che il tuo servizio sia semplicemente un canale di traffico crittografato. Dichiari che i tuoi clienti "reindirizzano il loro DNS all'indirizzo IP della nostra applicazione e la nostra applicazione analizzerà il traffico e quindi instraderà come appropriato". La frase "analizza il traffico" attirerà qualsiasi QSA per un aspetto più approfondito. Non dovresti avere molto da lavorare per l'analisi, nel caso di HTTPS; dovresti consentire la negoziazione SSL attraverso il vero back-end per inchiodare HTTPS prima che il canale fosse al sicuro da te, e se questo è tutto ciò che stai facendo, il tuo servizio non sta facendo molto. In breve, non credo che abbiamo abbastanza dettagli sul tuo servizio per darti consigli solidi.