Ambito PCI quando si inseriscono i dettagli della carta nel browser

Question

Ambito PCI quando si inseriscono i dettagli della carta nel browser

#1 da (2 voti)

3

Supponiamo di avere un sito Web di e-commerce, ospitato in Azure (o AWS). Userò un gateway di pagamento di terze parti completamente certificato come livello PCI 1. Tutte le comunicazioni avvengono con TLS 1.1 o versioni successive.

Scenario A : durante il checkout viene presentata una pagina che richiede all'utente i suoi dettagli, inclusa la carta di credito. Questo modulo browser è servito dal server mio in Azure. Quando l'utente preme PAY, utilizzando JavaScript, inviamo i dettagli della carta al gateway di terze parti per elaborare il pagamento e attendere la risposta. In nessun momento i dettagli della carta di credito vengono inviati al mio server in Azure.

Scenario B : anziché utilizzare un modulo di carta di credito dal mio sito, utilizziamo invece la pagina di pagamento ospitata dal gateway di terze parti. Ciò significa che eseguiamo un reindirizzamento al sito del gateway, in cui l'utente inserisce i dettagli della carta, quindi il browser reindirizza alla pagina di pagamento completa.

Scenario C : ordinamento di un ibrido, viene visualizzata la pagina di pagamento ospitata dal gateway in un iframe all'interno di una pagina servita dal mio server in Azure.

Domande:

In questi tre scenari, c'è una differenza nell'ambito PCI per il server in esecuzione in Azure? Qual è lo scopo? La nostra infrastruttura di Azure deve essere sottoposta a un audit annuale?
Fa la differenza se I sono un commerciante (quindi il gateway di terze parti utilizza il mio account commerciante per mio conto) rispetto a un gateway che elabora le transazioni con il proprio account commerciante , e poi mi rimborserà più tardi.

Sono portato a credere che ci sia una differenza nello scope PCI tra questi scenari, ma non riesco davvero a capire perché. Se il server Azure viene compromesso, un utente malintenzionato può pubblicare pagine dannose e acquisire la scheda dell'utente indipendentemente dall'approccio utilizzato.

Vedo siti di e-commerce che utilizzano sempre lo scenario A, ma sono sicuro che molti di essi sono in esecuzione in ambienti conformi PCI.

pci-dss pci-scope

posta richb 28.03.2017 - 12:12

fonte

1 risposta

Leggi altre domande sui tag pci-dss pci-scope

Se vi è un pacchetto TCP non crittografato inviato all'APP crittografata e dati che cosa accadrebbe? Come identificare un dispositivo utente

score 2 · Accepted Answer

Caveat IANAQSA

In these three scenarios, is there a difference in PCI scope for the server running in Azure? What is the scope? Does our Azure infrastructure need to undergo an annual audit?

L'ambito qui dovrebbe essere misurato come una cosa per mercante, non come un server. Sì, i tuoi server Azure saranno coperti dal tuo ambito (il livello di cui discuterò di seguito). AWS è lo standard d'oro per i fornitori di servizi cloud che ti aiuta a capire quali problemi di ambito sono tuoi contro il loro. Azure sembra essere meno utile in questo senso; ti indicano PCI, ma almeno hanno una Matrice di conformità .

(mancano altri dettagli), lo scenario A verrebbe considerato come un ambito SAQ A-EP e gli scenari B e C sarebbero SAQ A. Ecco un buona descrizione da PCIComplianceGuide.org :

the Council says that a merchant can still use SAQ A if:

Merchant website provides an inline frame (iframe) to a PCI DSS compliant third-party processor facilitating the payment process.

Merchant website contains a URL link redirecting users from merchant website to a PCI DSS compliant third-party processor facilitating the payment process. (Source: Understanding SAQs for PCI DSS Version 3, p. 5)

...

Does it make a difference if I am a merchant myself (so the third party gateway is using my merchant account on my behalf) vs a gateway that processes transactions with their own merchant account, and then reimburses me later.

Non ci credo. I clienti visitano il tuo sito; i clienti tirano fuori la propria carta e digitano i numeri; i clienti si aspettano in cambio beni o servizi. Sei un commerciante, indipendentemente dal fatto che gestisci il tuo account con l'elaboratore di pagamenti o tramite un agevolatore di pagamento.

I'm led to believe there is a difference in PCI scope between these scenarios, but I can't really see why. If the Azure server is compromised, an attacker could serve malicious pages and capture the user's card regardless of which approach is used.

C'è una differenza tra gli ambiti SAQ A e A-EP; il primo è di 14 domande; il secondo è più vicino a 100 e richiede scansioni.

In i termini di sicurezza attuali c'è una differenza trascurabile. Per quanto mi riguarda, penso che il ragionamento che suggerisce gli ifram siano più sicuri laddove javascript sia meno sicuro sono specioso e non guidato dalla tecnologia. Entrambi sono ugualmente vulnerabili a un utente malintenzionato che compromette il server Web e sostituisce {iframe, javascript} con il proprio.

I see ecommerce sites using scenario A all the time, but I'm quite sure very few of them are running in PCI compliant environments.

Sono sicuro che alcuni di loro hanno compilato correttamente i questionari SAQ.

Alcuni sottoinsiemi sono in realtà conformi allo standard PCI.

Alcuni sottoinsiemi sono effettivamente sicuri.