El enmascaramiento y la tokenización de datos protegen la información confidencial, pero resuelven problemas distintos. El enmascaramiento sustituye un valor real por uno ficticio que no permite recuperar el original. Esto es útil para las pruebas, el desarrollo y la analítica. La tokenización sustituye el valor real por un token que permite recuperar el original mediante un almacén seguro. De este modo se convierte en el estándar para gestionar los datos de las tarjetas en sistemas de pago activos.
Confundir ambos o usar uno donde corresponde el otro puede generar la interrupción de flujos de trabajo, por una parte, y una exposición innecesaria, por otra. Peor aún, las prácticas ineficientes en seguridad de datos pueden contribuir a que se produzcan filtraciones, lo que puede suponer un coste medio de 5 millones de dólares y tardar más de 280 días en solucionarse.
A continuación te explicaremos cómo funciona cada método, en qué se diferencian en la reversibilidad y los casos de uso, y cómo averiguar cuál necesita tu empresa para un conjunto de datos concreto.
De un vistazo
El enmascaramiento de datos sustituye de forma permanente valores confidenciales por otros valores ficticios realistas. Esto lo hace muy adecuado para entornos que no son de producción, como pruebas y analítica.
La tokenización sustituye valores confidenciales por tokens que permiten recuperar el original mediante un almacén seguro. De este modo, se convierte en el estándar para proteger los datos de tarjetas en las transacciones activas.
Si se elige el método equivocado para un determinado conjunto de datos se pueden interrumpir funciones o crear riesgos de cumplimiento de la normativa innecesarios. La elección correcta depende de si se debe recuperar el valor real o no.
¿Qué es el enmascaramiento de datos frente a la tokenización?
El enmascaramiento de datos cambia un valor real por otro falso que parece y se comporta como el original, pero no tiene ninguna conexión con él. En el contexto de la seguridad de los pagos, el enmascaramiento de datos oculta los detalles del titular de la tarjeta y otros datos confidenciales.
La tokenización sustituye un valor confidencial por un token generado de forma aleatoria; luego, almacena la asignación entre el token y el original en un almacén aparte estrechamente controlado. El token no tiene ninguna relación matemática con el valor original. Alguien que robe un token no obtendrá nada que pueda usar sin acceso al almacén.
¿Cuáles son las diferencias entre enmascaramiento de datos y tokenización?
La distinción se reduce a si el valor real necesita existir en algún sitio recuperable para que el sistema siga funcionando.
Aquí tienes las funciones que determinan cuál es el adecuado:
Reversibilidad: Los datos enmascarados no pueden recuperar su valor original. Los datos tokenizados sí, a través del almacén que emitió el token.
Caso de uso: El enmascaramiento se adapta a entornos que no son de producción, como pruebas, desarrollo y analítica. La tokenización se adapta a flujos de trabajo de producción activos, en los que una empresa debe usar datos reales sin guardarlos directamente.
Alcance de la protección: El enmascaramiento protege datos que ya no necesitan ser reales. La tokenización protege datos que aún tienen que funcionar como si fuesen reales, pero sin que estén almacenados en los propios sistemas de la empresa.
Aplicabilidad reguladora: El enmascaramiento ayuda a satisfacer los principios de minimización de datos en el marco del Reglamento General de Protección de Datos (RGPD) en la UE eliminando los datos personales reales de los entornos que no los necesitan. La tokenización es el mecanismo que el Payment Card Industry Data Security Standard (PCI DSS) acredita de forma explícita para reducir el alcance de la evaluación de cumplimiento de la normativa de una empresa.
¿Cuándo debes usar el enmascaramiento de datos frente a la tokenización?
Usa el enmascaramiento cuando un valor real no desempeñe ninguna función en el entorno en el que se usa. Un desarrollador que está probando una nueva página del proceso de compra, un analista que está creando un modelo de abandono de clientes y un ingeniero de control de calidad que está ejecutando grupos de pruebas automatizados, todos ellos necesitan datos que se comporten como los reales, sin serlo. El enmascaramiento les da precisamente esto, y elimina el riesgo por completo, porque no queda nada que exponer.
Usa la tokenización cuando la empresa necesite, de hecho, el valor confidencial en un momento posterior. Esta necesidad se hace evidente en algunos escenarios:
Facturación recurrente: una empresa basada en suscripciones que procesa cargos mensuales necesita un modo de cobrar con la misma tarjeta en cada ciclo sin guardar el número de la tarjeta.
Reembolsos y disputas: un equipo del servicio de atención al cliente que esté efectuando un reembolso necesita acceder a una transacción específica sin ver el número de cuenta principal (PAN).
Proceso de compra con tarjeta registrada: un cliente recurrente espera una experiencia de compra en un solo clic. Esto solo funciona si se asigna un token al número de la tarjeta, en vez de que la empresa lo guarde.
En ninguno de estos casos funcionaría el enmascaramiento, ya que un valor enmascarado no puede desenmascararse para completar el pago.
¿Cuáles son los riesgos de elegir el método equivocado para proteger datos confidenciales?
Usar el enmascaramiento cuando debería aplicarse la tokenización afecta a las funciones de inmediato. Un sistema de facturación recurrente basado en datos de tarjetas enmascarados no tiene forma de cobrar al cliente el mes siguiente, porque el valor que lo permitiría ya no existe en ninguna parte.
Usar la tokenización cuando debería aplicarse el enmascaramiento genera un tipo de problema diferente: exposición innecesaria. Si un sistema de prueba toma datos de producción tokenizados en lugar de datos enmascarados, y dicho entorno no tiene los mismos controles de acceso que el de producción, la empresa amplía los datos reales de los titulares de la tarjeta a un entorno de menor seguridad sin que le reporte ninguna ventaja. Los auditores de cumplimiento de la normativa pueden señalar este comportamiento, porque arrastra al alcance de PCI a sistemas que no tenían por qué estar ahí.
¿Cómo puedes decidir qué método se adapta a tu empresa?
Empieza con una sola pregunta para cada conjunto de datos: ¿hay algo en un punto posterior del proceso que necesite recuperar el valor real? Si la respuesta es no, el enmascaramiento es la herramienta más sencilla y adecuada. Si la respuesta es sí, vale la pena invertir en la infraestructura que requiere la tokenización, porque la reversibilidad es un requisito inevitable.
Una serie de comprobaciones puede ayudarte a confirmar la decisión:
Rastrea el uso de los datos: Enumera todos los sistemas que intervienen y valora si cada uno de ellos necesita los datos reales o simplemente algo que se les parezca.
Comprueba la normativa de cumplimiento de la normativa: Si el objetivo es reducir el alcance del PCI DSS, la tokenización de pagos es el mecanismo que reconocen los reguladores. En cambio, para la minimización de datos estilo RGPD en los entornos de prueba, lo más recomendable es el enmascaramiento.
Examina la separación del entorno: Los sistemas de producción que procesan transacciones reales normalmente exigen tokenización. Por lo general, los entornos que no son de producción requieren enmascaramiento. Mezclar ambos sin un motivo claro tiende a generar más riesgos de los que elimina.
Las empresas que usan Stripe ya tienen parte de esta decisión tomada sobre los datos de pago que recopilan a través de las integraciones de Stripe. El PAN se tokeniza durante la recopilación y la empresa nunca tiene que encargarse de desarrollar esta fase de forma interna. La empresa solo tiene que decidir qué hacer con el resto de sus datos confidenciales (por ejemplo, registros de clientes internos que se usan en las pruebas o en la analítica), para los que el enmascaramiento suele ser suficiente.
Cómo puede ayudarte Stripe Payments
Stripe Payments proporciona una solución de pagos unificada y global que ayuda a cualquier empresa —desde startups en expansión hasta empresas globales— a aceptar pagos en línea, en persona y en todo el mundo.
Stripe Payments puede ayudarte a:
Optimiza la experiencia de tu proceso de compra: Crea una experiencia de cliente fluida y ahorra miles de horas de ingeniería con interfaces de usuario de pago prediseñadas, acceso a más de 125 métodos de pago y Link, un monedero digital desarrollado por Stripe.
Expandirte a nuevos mercados más rápido: llega a clientes de todo el mundo y simplifica la gestión de los tipos de intercambio gracias a las opciones para pagar internacionales, que admiten 195 países y más de 135 divisas.
Unificar los pagos en línea y en persona: crea una experiencia de comercio unificado entre tus canales en línea y presenciales para personalizar la relación con tus clientes, fomentar su fidelidad y aumentar tus ingresos.
Mejorar el rendimiento de tus pagos: aumenta tus ingresos con herramientas para pagar configurables y fáciles de implementar, que incluyen soluciones sin programación de protección antifraude y funciones avanzadas para mejorar las tasas de autorización.
Muévete más rápido con una plataforma flexible y fiable para el crecimiento: construye sobre una plataforma diseñada para escalar contigo, con un tiempo de actividad del 99,999 % y una fiabilidad líder en el sector.
Obtén más información sobre cómo Stripe Payments puede impulsar tus pagos en línea y en persona, o empieza hoy mismo.
El contenido de este artículo tiene solo fines informativos y educativos generales y no debe interpretarse como asesoramiento legal o fiscal. Stripe no garantiza la exactitud, la integridad, la adecuación o la vigencia de la información incluida en el artículo. Busca un abogado o un asesor fiscal profesional y con licencia para ejercer en tu jurisdicción si necesitas asesoramiento para tu situación particular.