Los datos de tarjeta que no debes almacenar.
El Requisito 3 trata sobre la protección de los datos de cuentas almacenados y establece una línea clara. El número de cuenta principal, donde se almacene, debe ser ilegible. Los datos de autenticación sensibles, como el código de verificación de la tarjeta (los tres o cuatro dígitos), los datos completos de la banda magnética o el chip, y el PIN, no deben almacenarse después de que se autorice un pago. Para los flujos de aceptación de pagos que la mayoría de las aplicaciones implementan, esto significa: no los guardes, ni siquiera cifrados. (Los emisores de tarjetas tienen excepciones estrechas y controladas; la mayoría de los equipos no son emisores.) La distinción se decide en el código, en lo que tus controladores persisten.
The shapes the same control failure takes.
El Requisito 3 se incumple cuando un cambio almacena datos de cuentas que no debería o los almacena en texto claro. Las formas recurrentes:
Se almacenan datos de autenticación sensibles
El código de verificación de la tarjeta, los datos completos de la pista o el PIN se escriben en una base de datos, caché o cola después de la autorización, algo que un flujo de aceptación de pagos no debe hacer, ni siquiera cifrado.
Un PAN se almacena sin ser ilegible
Un número de cuenta principal se persiste sin cifrado, truncamiento ni tokenización, por lo que permanece legible en reposo.
Los datos de la cuenta terminan en un nuevo almacenamiento
Los datos de la tarjeta comienzan a escribirse en un lugar no diseñado para protegerlos (un registro, un evento de análisis, una tabla de depuración), lo que incluye ese almacenamiento en el alcance.
Se elimina un paso de enmascaramiento o tokenización
Se suprime un paso que truncaba o tokenizaba el PAN antes del almacenamiento, por lo que ahora se conserva el número completo.
Los datos de la tarjeta se conservan más tiempo del necesario
Se elimina una retención o purgado que limitaba el tiempo de conservación de los datos de la cuenta, por lo que se acumulan más allá de su necesidad comercial.
Guardar el código de verificación de la tarjeta para reintentos.
A veces un pago necesita un reintento, y sería conveniente volver a enviar los detalles originales. Por lo tanto, un cambio guarda toda la carga útil del pago, incluido el código de verificación de la tarjeta, en la tabla de pedidos. Facilita los reintentos, pero almacena datos que nunca deben conservarse después de la autorización.
- await orders.insert({ id, amount, last4: card.last4 })+ await orders.insert({ id, amount, card }) // full card incl. cvcreturn orderPersistir el objeto completo de la tarjeta almacena el código de verificación de la tarjeta después de la autorización, lo que el Requisito 3 prohíbe para un flujo de aceptación de pagos, incluso si la columna está cifrada. Almacena solo lo que está permitido conservar (en este caso, los últimos cuatro dígitos y un token de tu procesador), no el código de verificación, la pista completa ni el PIN.
Los datos de cuentas almacenados se buscan, no solo se preguntan.
Una evaluación de PCI DSS revisa qué datos de cuentas se almacenan realmente y dónde: verifica que los datos de autenticación sensibles no se conserven después de la autorización y que cualquier PAN almacenado sea ilegible. Un cambio que comienza a persistir el código de verificación o un PAN sin enmascarar es exactamente el hallazgo que aparece, e incluye en el alcance cualquier almacenamiento que haya tocado. El diff del controlador es el lugar más económico para detectarlo.
Una revisión, no una QSA.
heygrc marca los cambios que afectan al Requisito 3 y cita el requisito para que la corrección se realice en la solicitud de extracción. No realiza tu evaluación ni completa tu Cuestionario de Autoevaluación. Detecta el momento en que un cambio almacena datos de cuentas que no debería, en el diff.