Acelera la adopción de PCI DSS con MongoDB Atlas

Cómo es PCI DSS y dónde está la división de las capas

El Consejo de Estándares de Seguridad de PCI mantiene PCI DSS y organiza un conjunto de requisitos agrupados bajo objetivos de control:

Bajo el modelo de responsabilidad compartida, estos requisitos son una división en estas capas:

• Capa de infraestructura (responsabilidad del proveedor): Comprende seguridad física, controles de red, aplicación de parches en la plataforma y cifrado en reposo del almacenamiento subyacente. MongoDB nube es un proveedor de servicios certificado por PCI DSS, validado por un QSA, Coalfire Systems. Para el entorno CHD en MongoDB Cloud, un QSA puede confiar en el AOC de MongoDB Cloud, disponible bajo solicitud a través del Centro de Confianza de MongoDB. Esta capa prevalidada elimina la necesidad de que los clientes vuelvan a auditar la infraestructura subyacente.

• Capa de aplicación (responsabilidad del cliente): Comprende cómo el producto almacenar, protege, query, enmascara y auditar CHD, y quién está autorizado a leer la información. Esta capa sigue siendo una decisión de diseño del cliente.

Figura 1. Modelo de responsabilidad compartida en capas de PCI DSS

haga clic para ampliar

El Proyecto PSP llena la capa de aplicación. Comprende una arquitectura de referencia y un conjunto de mejores prácticas. Muestra cómo usar MongoDB para alinear la capa de aplicación con los objetivos de control de PCI DSS para proteger los datos almacenados, restringir el acceso, su supervisión y reducir el alcance al auditar. Este proyecto constituye un punto de partida para acelerar la adopción de PCI DSS.

La Propuesta Arquitectónica

El Proyecto PSP es una plataforma PSP alineada con PCI DSS. Ejecuta el ciclo de vida de los pagos en MongoDB Atlas: pago con tarjeta y autorización, puntuación de fraude automatizada e investigación de analistas de varios niveles. Muestra cómo los analistas pueden buscar datos cifrados con una filosofía de diseño clara:

Cifre todo. Query cualquier cosa. Las claves son suyas.

Con la capa de infraestructura heredada de Atlas (consulte la Figura 1), el trabajo restante se realiza en la capa de aplicación. Atlas ofrece diversas funcionalidades para respaldar este trabajo, siendo Queryable Encryption la principal. El conjunto completo de funcionalidades se enumera en la sección de capacidad de MongoDB.

Queryable Encryption en el punto de mira

Con un enfoque convencional, un campo se mantiene en texto sin formato para que se pueda buscar (legible por cualquier persona con acceso a la base de datos), o se cifra para que esté protegido (pero ya no se puede buscar). Queryable Encryption elimina esa disyuntiva para los tipos de query que admite.

Figura 2. Arquitectura de cifrado de MongoDB: Queryable Encryption, gestión de claves y capas de protección de datos

haga clic para ampliar

Para un campo que permite búsquedas de igualdad, el flujo es el siguiente:

• El driver cifra el valor de búsqueda en el lado del cliente, utilizando el DEK del campo.

• El servidor compara ese valor cifrado con un índice cifrado. Compara texto cifrado con texto cifrado y no descifra el campo.

• Cuando los documentos coincidentes regresan al proceso de la aplicación, el driver descifra los campos de destino en memoria. MongoDB Atlas solo almacena y procesa texto cifrado, guardado como subtipo binario BSON 06; como resultado, un administrador de base de datos con acceso total al clúster solo ve bytes opacos.

El efecto concreto en el Proyecto PSP: un analista de fraudes busca un cliente por correo electrónico cifrado, teléfono o referencia de cuenta y recupera el registro, mientras que el valor de texto sin formato no llega a Atlas. Esta capacidad mantiene la PII confidencial cifrada en reposo y disponible por valor, sin el descifrado masivo que amplía el CDE.

Los campos que necesitan protección pero no búsqueda utilizan un modo no buscable, descifrado solo para una solicitud autorizada y escalada. La sección del modelo de datos cubre ambos modos y los campos que protegen.

Capacidades de MongoDB para la capa de aplicación

El Proyecto PSP combina varias capacidades de MongoDB y Atlas. Cada una corresponde a una parte específica del trabajo de la capa de aplicación de PCI DSS:

Casos de uso adyacentes

Los principios fundamentales de esta solución, incluidos un límite de API estable, Queryable Encryption a nivel de campo y un modelo de DEK por nivel de acceso, se pueden aplicar a otros casos de uso:

• Finanzas abiertas: Acceso a los datos basado en el consentimiento que restringe a un tercero a los campos que un cliente autorizó, como PSD2 y el derecho de los consumidores a los datos.

• Salud: Información de salud protegida según la HIPAA.

• Seguros y patrimonio: Plataformas que gestionan identificadores gubernamentales y datos de cuentas financieras bajo el GDPR.

Componentes de arquitectura

La arquitectura utiliza los siguientes componentes:

• Tablero de PSP (Interfaz de usuario): La capa de presentación. No se comunica con la base de datos directamente. Al pagar, tokeniza el PAN para que el PAN completo no sea transmitido ni almacenado por el núcleo del PSP.

• PSP API gateway (backend): El único punto de entrada y el único componente que puede descifrar campos protegidos. Contiene el cliente de Queryable Encryption, resuelve el rol del emisor y selecciona el nivel de clave correcto por solicitud. Todas las entidades que llaman, incluyendo la interfaz de usuario, las cuentas de servicio y las integraciones, pasan por la misma API y están sujetas a las mismas reglas de RBAC y de clave.

• MongoDB Atlas (M10 o superior) con Queryable Encryption: almacena solo texto cifrado (subtipo binario 06) para cada campo protegido. Un administrador de base de datos con acceso total al clúster ve bytes opacos. TLS 1.3 protege todos los datos en tránsito. El Proyecto PSP se basa en la búsqueda por igualdad, que es compatible en producción.

• AWS KMS: Contiene la llave maestra de cliente que cifra y descifra las llaves de cifrado de datos. La llave maestra de cliente permanece en KMS, y MongoDB no tiene acceso a ella. Un proveedor de claves local está disponible como alternativa sin conexión para demostraciones.

Tipos de query y cómo el Proyecto los aplica

MongoDB Queryable Encryption mantiene un campo cifrado en el lado del cliente y permite que el servidor consulte el texto cifrado. El Proyecto PSP utiliza estos tipos de query:

• Igualdad (producción): El modo de búsqueda para las claves de búsqueda con alcance PCI DSS. El driver cifra el valor de query y lo compara con un índice cifrado, por lo que el servidor no descifra el campo. Esta funcionalidad permite a un analista de fraude encontrar un registro por correo electrónico, teléfono o referencia de cuenta sin exponer texto sin cifrar.

• Sin query (solo recuperación): La modalidad sin capacidad de búsqueda para los campos de mayor sensibilidad, incluida la dirección residencial, el identificador del gobierno y las cargas útiles sin procesar de la puerta de enlace. Un cliente autorizado descifra estos campos justo a tiempo únicamente.

• Rango (producción): Se utiliza para búsquedas de bandas de valores, como el filtro por un rango de cantidades. Mantiene la cantidad cifrada.

• Prefijo, sufijo y subcadena (vista previa pública): Demostrado para búsquedas de coincidencia parcial de estilo KYC en campos de identidad cifrados.

Para los campos de tarjeta y PII con alcance PCI DSS siguientes, el diseño de acceso se reduce a las siguientes categorías:

Las opciones de diseño que mantienen los datos del titular de la tarjeta fuera del alcance siempre que sea posible incluyen:

• Tokenización de PAN: La aplicación reemplaza el PAN completo con un token sustituto tok_<uuid> y conserva solo los últimos cuatro dígitos para fines de visualización.

• Captura cero de SAD: Los puntos de conexión nunca capturan SAD como CVV o PIN.

Reducir el alcance mediante segmentación y tokenización

Una práctica común de PCI DSS mantiene los datos de los titulares de tarjetas fuera de los sistemas que no los necesitan, de modo que la mayor parte de la plataforma queda fuera del CDE. Estas técnicas aplican la segmentación, que aísla el CDE del resto del sistema, y la tokenización, que reemplaza el número de cuenta principal con un token sustituto almacenado en una bóveda de tokenización dedicada. La segmentación no es un requisito de PCI DSS, pero saca los sistemas del alcance y reduce el costo de la evaluación; cuando se utiliza, debe documentarse, justificarse y validarse.

El Proyecto PSP aplica estas técnicas en la capa de datos:

• El PAN completo nunca reside en el núcleo del PSP: El núcleo solo almacena el token sustituto, el BIN y los últimos cuatro dígitos. La mayor parte de la plataforma no contiene datos de titulares de tarjetas y queda fuera del alcance. El PAN completo pertenece al subsistema emisor de tarjetas, que es externo en producción. En la demostración, una funcionalidad incorporada de módulo emisor reemplazable actúa como sustituto y almacena el PAN en su propia bóveda aislada, cifrado con QE:equality. Este campo se puede hacer coincidir para una búsqueda exacta y la detección de duplicados sin descifrarlo.

• La PII está centralizada: Los campos de identidad, como el correo electrónico o el teléfono, residen en una única colección de partes BIAN SD-13 a la que hacen referencia el acuerdo, la tarjeta y los registros de transacciones. Un único lugar para proteger y procesar una solicitud de borrado de datos del interesado.

• Los campos confidenciales se encuentran detrás de un nivel de clave independiente: QE:none campos utilizan un nivel de llave de cifrado de datos diferente al de los campos QE:equality que admiten búsquedas, por lo que el límite entre los datos sensibles y los no sensibles se aplica mediante las llaves.

Este es un patrón de referencia, no una certificación. La definición de CDE y su validación siguen siendo responsabilidad del cliente y el evaluador debe confirmarlas.

Claves aplicadas por el control de acceso, no código de aplicación

Volver a separar el DEK de los niveles de cifrado:

• Nivel de búsqueda: QE:equality Las claves están disponibles para todos los roles de analista autenticados para la búsqueda.

• Nivel confidencial: QE:none Las claves están disponibles únicamente para un investigador de nivel 2 que posea un token de escalada válido y de corta duración, y para un auditor de seguridad de solo lectura.

• El núcleo del diseño: El mapa de campos cifrados de un cliente de nivel 1 omite las claves confidenciales, por lo que el driver no puede descifrar esos campos y los devuelve como texto cifrado. El control de acceso a nivel de campo aquí es criptográfico en lugar de una proyección en el código de la aplicación, lo que reduce el riesgo de una fuga accidental a través de un error de query. Cuando un analista escala un caso y un investigador de nivel 2 lo aprueba, el investigador recibe un token de escalada que activa el grupo de clientes de nivel confidencial para esa solicitud.