Domanda

Ho questa idea, ma non sono sicuro che sia compatibile PCI.Sono nuovo nell'arena della conformità PCI e sono curioso di sapere se questo scenario viola il PCI.

Quindi, prepariamo lo scenario.L'azienda A è conforme PCI e dispone di un servizio Web su https che espone parti di funzionalità relative all'elaborazione dei pagamenti.L'azienda B non è conforme, ma il suo sito web è sicuro.

Ecco i passaggi dello scenario.

  1. Il sito Web di B contatta il servizio Web di A tramite il codice lato server.Questo servizio restituisce un token di autenticazione crittografato.
  2. B inserisce questo token in una pagina contenente un modulo per accettare i dati della carta di credito.
  3. L'utente inserisce i dati della propria carta di credito sul sito web di B.
  4. Le informazioni sul modulo, insieme al token, vengono inviate tramite una chiamata Ajax al servizio web di A.
  5. Il servizio web di A elabora i dati e restituisce uno stato (Approvato/Rifiutato/ecc.)

La domanda è: poiché Javascript va direttamente dalla macchina dell'utente ai server conformi dell'azienda A, è conforme PCI?Sono molto interessato a sapere cosa pensano gli esperti in questo campo.

È stato utile?

Soluzione

Opuscolo su PCI DSS Tutti di Standard PCI

PCI DSS (Payment Card Industry Data Security Standard) ha il concetto di "Scoping": determina quali sistemi rientrano sotto l'ombrello PCI.

Sei un commerciante o un fornitore di software?Se il PAN (Primary Account Number), il lungo numero della carta di credito, non viene mai inviato al tuo sito web, di solito il tuo sito web non rientra nell'ambito PCI.-- Supponendo che tu sia il commerciante.Se sei un fornitore di software, il tuo software rientrerà probabilmente nell'ambito del PA-DSS (vedi sotto).

PAN in transito sul tuo serverLa vecchia idea era che il PAN sarebbe stato inviato al tuo sito web (tramite l'invio di un modulo nel browser), quindi il tuo sito web sarebbe tornato indietro e lo avrebbe inviato a un gateway di pagamento (ad esempio Authorize.Net).In questo scenario, il PAN non è mai stato archiviato sul server, ma lo è stato transito il tuo server.Ciò significava che i tuoi sistemi commerciali non rientravano nell'ambito PCI DSS poiché non memorizzavano mai il PAN.Ma quei giorni stanno finendo velocemente o sono già passati.(Che dipende da quanto aggressivo è il tuo acquirente/fornitore del conto commerciante nei confronti del PCI.)

Controllare la tua pagina web Poiché la tua pagina web non trasmette alcun PAN al tuo server, non sei nell'ambito PCI.Ma come fai a sapere che qualcuno non ha modificato la tua pagina web per ritrasmettere il PAN al tuo server (o altrove, utilizzando tecniche JSONP)?La risposta è che devi assicurarti che nessuno manometterà la pagina dei moduli di pagamento.

Il modo in cui ti assicuri di questo dipende da te.Potresti utilizzare le tecniche PCI o altre tecniche.È una questione di sicurezza e controllo del computer interno.

Standard di sicurezza dei dati delle applicazioni di pagamento (PA-DSS) Se vendi il tuo software ai commercianti, probabilmente rientrerà nell'ambito dello standard PA-DSS.Vedi il standard.

Il PCI è politico, non tecnico Ricorda che l'ambito PCI dipende da te.Se sei un commerciante abbastanza grande, dovrai anche collaborare con un QSA (valutatore qualificato della sicurezza) che esaminerà e approverà la conformità PCI e il piano di definizione dell'ambito.

È certamente possibile che un QSA possa dire che, poiché controlli la tua pagina web, questa deve essere sotto PCI poiché potrebbe essere danneggiata da qualcuno.Ma questo sarebbe un argomento invadente.Dopotutto, si potrebbe quindi dire che ogni pagina web di qualsiasi commerciante su Internet deve essere sotto PCI poiché qualsiasi pagina web potrebbe essere danneggiata per chiedere alle persone un PAN e poi farne qualcosa di brutto.D’altra parte, questo è esattamente il tipo di argomento che Visa sta utilizzando per aumentare la portata del PCI per i franchisor aziendali. Articolo.

La certificazione PCI non è una scusa Tieni inoltre presente che le associazioni delle carte si riservano il diritto di espellerti in caso di effrazione, anche se eri conforme PCI.Quindi vuoi essere sicuro di essere un bersaglio molto più difficile di chiunque altro nel tuo quartiere.

Aggiunto: Altro sull'ambito Come si può capire da quanto sopra, una questione chiave è quali sistemi siano dentro o fuori dall'ambito PCI.Il Consiglio del PCI ha ora un Gruppo di Interesse Speciale (SIG) che esamina l’intera questione di cosa rientra e cosa è fuori dall’ambito del PCI.E la mia ipotesi è che vorranno che l'involucro cresca, non che si riduca.

Aggiunto: È una cosa tra te e il tuo avvocato Il tuo scenario prevede l'avvio dell'elaborazione PAN sui browser dei tuoi clienti.Il PAN non raggiunge mai i vostri sistemi, nemmeno per un istante.Quindi la mia interpretazione è che sei fuori dall'ambito PCI DSS del commerciante.Ma sei tu a firmare la dichiarazione di conformità PCI che è un contratto tra te e il tuo acquirente.Quindi spetta a te e al tuo avvocato interpretare lo standard PCI DSS, non a me.

Linea di fondo Non dovresti mai e poi mai archiviare dati PAN sui tuoi sistemi.Non dovresti nemmeno farlo transitare nei tuoi sistemi.I nuovi protocolli Payment Gateway di Authorize.Net e Braintree abilitano la tecnica di divieto di transito.A seconda del volume delle transazioni con carta di credito, la conformità PCI varia da una lista di controllo autogestita a un progetto di grandi dimensioni.

Per ulteriori storie di guerra del PCI, controlla il Vetrina del negozioBacktalk blog e il loro Copertura PCI.

Altri suggerimenti

La risposta di Larry K è buona. È principalmente una cosa / strato di politica.

Sembra che l'utilizzo di un iframe per la pubblicazione da B ad A è una soluzione accettata, durante l'utilizzo di Ajax - con CORS o JSONP - è un po 'più discutibile, ma ancora, almeno per alcuni grandi giocatori, accettabile

.

Il Informazioni Supplemento: Linee guida PCI DSS e-commerce cuciture v2 a dire che questa soluzione (-post diretta API) è OK, ma che voi dovrebbe permettono di scrivere codice in modo sicuro (anche se PCI DSS non prescrive concreto tutto ciò che avrebbe bisogno di fare) - vedere la sezione API 3.4.3.1 di terze parti integrati con GDF Messaggio ed i relativi 3.4.3.4 Considerazioni di sicurezza per le implementazioni Shared-Management e-commerce , che recita:

  

diretto post API Approach : Con l'approccio diretto-post API, il   mercante è ancora responsabile della pagina web che si presenta a   il consumatore, ed i padroni di casa mercantili i campi della pagina di pagamento   che accettano i dati-solo i dati dei titolari di carta è pubblicato direttamente da   il consumatore al fornitore del servizio. Dal momento che le pagine di pagamento sono   ospitata dal commerciante, le pagine di pagamento sono solo sicuro come il   sito web del commerciante, e un compromesso del sistema del commerciante poteva   portare ad un compromesso di dati di carte di pagamento.   ...   Specificamente, per tutti gli scenari di cui sopra, il commerciante dovrebbe   monitorare qualsiasi prova che i sistemi sono cambiati e rispondere rapidamente   di ripristinare i sistemi a uno stato di fiducia quando sono modifiche non autorizzate   rilevato. I commercianti che adottano questi-gestione condivisa esternalizzati   modelli applicabili per ridurre al minimo i requisiti PCI DSS devono essere consapevoli di   i potenziali rischi inerenti a questo tipo di sistema   architettura. Per ridurre al minimo la probabilità di un attacco in questi scenari,   i commercianti dovrebbero applicare la dovuta diligenza supplementare per garantire il web   applicazione è sviluppata in modo sicuro e subisce penetrazione profonda   test.

Ad esempio il Stripe gateway di pagamento utilizza diretta post corso JSONP dal 2012 al posto dell'approccio iframe hanno usato prima.

D'altra parte, WePay fornisce anche un'API diretta-post, ma iframe raccomanda di eliminare completamente i requisiti PCI [WP] (sostenendo che con l'API diretta-post " [..] Sei ancora necessaria per essere compatibile con il pagamento con carta Industry Data Security Standard (PCI-DSS) e il Payment Application Data Security Standard (PA-DSS) ogni volta applicabile. "(senza specificare che cosa esattamente "ogni volta che modo appropriato").

[WP] WePay link: https://www.wepay.com/developer/tutorial/tokenization

Ho recentemente passato attraverso un lavoro PCI rispetto per i nostri server, quindi questo è proprio di fronte a me. La risposta breve è no.

conformità PCI richiede che ogni passo del percorso attraverso il quale passa le informazioni sensibili soddisfa i requisiti PCI in sé. Qualcosa può essere sicuro, ma non è conforme, come avrete notato quanto riguarda società B. Perché si è già detto che la società B non è PCI-compliant, eppure la società B sta raccogliendo le informazioni della carta di credito tramite il proprio sito web, quindi l'intero processo, logicamente è non conforme.

Se un servizio di PCI-conformità collega effettivamente questi punti e il modo in cui avrebbe certificarlo come il passaggio o, in mancanza può essere un'altra questione.

A prescindere dal fatto che sia "tecnicamente" soddisfa gli standard PCI (o non), non vorrei mettere la mia fiducia in questo modo di fare le cose.

Se il modulo si trova su una pagina all'interno hostname di B, B ha accesso completo a ciò che è nei campi del modulo. (Assistente di B è in grado di inviare l'utente malintenzionato JavaScript se vuole.)

Il modo più sicuro di farlo (in termini di tutela numeri di carta di credito) è quello di mettere il modulo, entro il nome host del sistema di pagamento, piuttosto che su un nome host non attendibile.

Questa è la PCI Sito

In sostanza, se si possa vedere il numero di carta o le informazioni di identificazione sulla carta, sarà necessario soddisfare i requisiti PCI. Non sono sicuro che essi sono necessariamente un documento legale 'ancora', ma se si sono trovati in violazione, la capacità di processo, o essere parte di un processo di transazione può essere revocato. Inoltre come un mercante di firmare un accordo sulla vostra responsabilità e opt-in un processo in cui le società di carte di credito possono multare voi. Tutto per il privilegio di accettare carte di credito.

Per il divertimento: ecco un (pdf) link alla pagina 38 'rapida' Guide .

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top