De kaartgegevens die je niet mag opslaan.
Vereiste 3 gaat over het beschermen van opgeslagen accountgegevens en trekt een harde grens. Het primaire accountnummer, waar je het wél opslaat, moet onleesbaar worden gemaakt. En gevoelige authenticatiegegevens, zoals de kaartverificatiecode (de drie of vier cijfers), de volledige magnetische strip- of chipgegevens en de PIN, mogen niet worden opgeslagen na autorisatie van een betaling. Voor de betalingsacceptatieprocessen die de meeste applicaties bouwen, betekent dit: je bewaart het niet, zelfs niet versleuteld. (Kaartuitgevers hebben smalle, gecontroleerde uitzonderingen; de meeste teams zijn geen uitgevers.) Het onderscheid wordt gemaakt in de code, in wat je handlers opslaan.
The shapes the same control failure takes.
Vereiste 3 wordt geschonden wanneer een wijziging accountgegevens opslaat die niet mogen worden opgeslagen, of deze onversleuteld opslaat. De terugkerende patronen:
Gevoelige authenticatiegegevens worden opgeslagen
De kaartverificatiecode, volledige trackgegevens of PIN wordt geschreven naar een database, cache of wachtrij na autorisatie, wat een betalingsacceptatieproces niet mag doen, zelfs niet versleuteld.
Een PAN wordt opgeslagen zonder onleesbaar te zijn
Een primair accountnummer wordt opgeslagen zonder versleuteling, afkapping of tokenisatie, waardoor het leesbaar in rust blijft.
Accountgegevens belanden in een nieuwe opslaglocatie
Kaartgegevens beginnen te worden geschreven naar een locatie die niet is ontworpen om deze te beschermen (een log, een analytische gebeurtenis, een debug-tabel), waardoor die opslaglocatie in scope komt.
Een maskerings- of tokenisatiestap wordt verwijderd
Een stap die het PAN afkapte of tokeniseerde voor opslag wordt verwijderd, waardoor het volledige nummer nu wordt bewaard.
Kaartgegevens worden langer bewaard dan nodig
Een bewaartermijn of verwijdering die beperkte hoe lang accountgegevens werden bewaard, wordt verwijderd, waardoor deze zich ophoopt buiten de bedrijfsbehoefte.
De kaartverificatiecode opslaan voor herhalingen.
Een betaling heeft soms een herhaling nodig, en het zou handig zijn om de oorspronkelijke details opnieuw in te dienen. Een wijziging slaat daarom de volledige betalingspayload, inclusief de kaartverificatiecode, op in de orders-tabel. Het maakt herhalingen eenvoudig, maar slaat gegevens op die nooit mogen worden bewaard na autorisatie.
- await orders.insert({ id, amount, last4: card.last4 })+ await orders.insert({ id, amount, card }) // full card incl. cvcreturn orderHet opslaan van het volledige kaartobject slaat de kaartverificatiecode op na autorisatie, wat Vereiste 3 verbiedt voor een betalingsacceptatieproces, zelfs als de kolom is versleuteld. Sla alleen op wat je mag bewaren (hier: de laatste vier cijfers en een token van je verwerker), niet de verificatiecode, volledige track of PIN.
Opgeslagen accountgegevens worden doorzocht, niet alleen gevraagd.
Een PCI-assessment kijkt naar welke accountgegevens daadwerkelijk worden opgeslagen en waar: het controleert of gevoelige authenticatiegegevens niet worden bewaard na autorisatie en of elk opgeslagen PAN onleesbaar is. Een wijziging die de verificatiecode of een ongemaskeerd PAN begint op te slaan, is precies de bevinding die naar voren komt, en het brengt elke opslaglocatie die het aanraakt in scope. De diff naar de handler is de goedkoopste plek om dit op te vangen.
Een review, geen QSA.
heygrc markeert wijzigingen die Vereiste 3 raken en citeert de vereiste, zodat de correctie in de pull request plaatsvindt. Het voert geen assessment uit of voltooit je Self-Assessment Questionnaire. Het vangt het moment op waarop een wijziging accountgegevens opslaat die niet mogen worden opgeslagen, in de diff.