I dati della carta che non devono essere memorizzati.
Il Requisito 3 riguarda la protezione dei dati dell'account memorizzati e traccia un confine netto. Il numero di account primario, dove lo memorizzi, deve essere reso illeggibile. I dati di autenticazione sensibili, come il codice di verifica della carta (le tre o quattro cifre), i dati completi della banda magnetica o del chip e il PIN, non devono essere memorizzati dopo l'autorizzazione di un pagamento. Per la maggior parte delle applicazioni che gestiscono flussi di accettazione pagamenti, considera questo: non li conservi, neanche crittografati. (Gli emittenti di carte hanno eccezioni strette e controllate; la maggior parte dei team non sono emittenti.) La decisione si prende nel codice, in ciò che i tuoi handler memorizzano.
The shapes the same control failure takes.
Il Requisito 3 viene violato quando una modifica memorizza dati dell'account che non dovrebbe, o li memorizza in chiaro. Le forme ricorrenti:
I dati di autenticazione sensibili vengono memorizzati
Il codice di verifica della carta, i dati completi della banda magnetica o il PIN vengono scritti in un database, cache o coda dopo l'autorizzazione, cosa che un flusso di accettazione pagamenti non deve fare, neanche crittografati.
Un PAN viene memorizzato senza essere illeggibile
Un numero di account primario viene memorizzato senza crittografia, troncamento o tokenizzazione, quindi rimane leggibile a riposo.
I dati dell'account finiscono in un nuovo archivio
I dati della carta iniziano a essere scritti in un luogo non progettato per proteggerli (un log, un evento di analisi, una tabella di debug), portando quell'archivio nell'ambito di applicazione.
Viene rimosso un passaggio di mascheramento o tokenizzazione
Un passaggio che troncava o tokenizzava il PAN prima della memorizzazione viene eliminato, quindi ora il numero completo viene conservato.
I dati della carta vengono conservati più a lungo del necessario
Un periodo di conservazione o una cancellazione che limitava la durata di memorizzazione dei dati dell'account viene rimosso, quindi si accumulano oltre il bisogno aziendale.
Salvataggio del codice di verifica della carta per i tentativi di riprova.
Un pagamento a volte richiede un tentativo di riprova, e sarebbe comodo reinviare i dettagli originali. Quindi una modifica salva l'intero payload di pagamento, incluso il codice di verifica della carta, nella tabella degli ordini. Semplifica i tentativi di riprova, ma memorizza dati che non devono mai essere conservati dopo l'autorizzazione.
- await orders.insert({ id, amount, last4: card.last4 })+ await orders.insert({ id, amount, card }) // full card incl. cvcreturn orderMemorizzare l'oggetto carta completo memorizza il codice di verifica della carta dopo l'autorizzazione, cosa che il Requisito 3 vieta per un flusso di accettazione pagamenti, anche se la colonna è crittografata. Memorizza solo ciò che è consentito conservare (qui, le ultime quattro cifre e un token dal tuo processore), non il codice di verifica, i dati completi della banda magnetica o il PIN.
I dati dell'account memorizzati vengono cercati, non solo richiesti.
Un assessment PCI verifica quali dati dell'account vengono effettivamente memorizzati e dove: controlla che i dati di autenticazione sensibili non vengano conservati dopo l'autorizzazione e che qualsiasi PAN memorizzato sia illeggibile. Una modifica che inizia a memorizzare il codice di verifica o un PAN non mascherato è esattamente il riscontro che emerge, e porta qualsiasi archivio interessato nell'ambito di applicazione. Il diff del gestore è il luogo più economico per coglierlo.
Una revisione, non un QSA.
heygrc segnalerà le modifiche che interessano il Requisito 3 e citerà il requisito in modo che la correzione avvenga nella pull request. Non esegue il tuo assessment né compila il tuo Questionario di Auto-Valutazione. Individua il momento in cui una modifica memorizza dati dell'account che non dovrebbe, direttamente nel diff.