Acelere la adopción de PCI DSS con MongoDB Atlas

Cómo se ve PCI DSS y dónde se dividen las capas

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

Según el modelo de responsabilidad compartida, estos requisitos se dividen entre las siguientes capas:

• Capa de infraestructura (responsabilidad del proveedor): Comprende la seguridad física, los controles de red, la aplicación de parches a la plataforma y el cifrado del almacenamiento subyacente. MongoDB Cloud es un proveedor de servicios certificado por PCI DSS, validado por Coalfire Systems, una QSA. Para el entorno CHD en MongoDB Cloud, una QSA puede basarse en el Certificado de Cumplimiento Autorizado (AOC) de MongoDB Cloud, disponible previa 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 almacena, protege, consulta, enmascara y audita los datos de seguridad de los datos, y quién tiene permiso para leer la información. Esta capa sigue siendo una decisión de diseño del cliente.

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

haga clic para ampliar

El proyecto PSP se centra en la capa de aplicación. Incluye una arquitectura de referencia y un conjunto de buenas 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, monitorizarlos y reducir el alcance de la auditoría. 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. Gestiona el ciclo de vida del pago en MongoDB Atlas: verificación y autorización de tarjetas, puntuación automatizada de fraude e investigación de analistas en múltiples niveles. Muestra cómo los analistas pueden buscar datos cifrados con una filosofía de diseño clara:

Encripta todo. Consulta lo que quieras. Las claves son tuyas.

Con la capa de infraestructura heredada de Atlas (véase la figura 1), el resto del trabajo se realiza en la capa de aplicación. Atlas proporciona diversas funcionalidades para respaldar este trabajo, siendo el cifrado consultable la principal. El conjunto completo de funcionalidades se detalla en la sección de capacidades de MongoDB.

El cifrado consultable en primer plano

Con un enfoque convencional, un campo se mantiene en texto plano para que pueda buscarse (legible para cualquier persona con acceso a la base de datos) o se cifra para protegerse (pero ya no se puede buscar). El cifrado consultable elimina esta disyuntiva para los tipos de consulta que admite.

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

haga clic para ampliar

Para un campo que admite búsqueda por igualdad, el flujo procede de la siguiente manera:

• El controlador cifra el valor de búsqueda en el lado del cliente, utilizando la clave de cifrado de dominio (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 controlador descifra los campos de destino en la memoria. MongoDB Atlas almacena y procesa únicamente texto cifrado, mantenido como subtipo binario 06 BSON; como resultado, un administrador de base de datos con acceso completo al clúster solo ve bytes opacos.

El efecto concreto en el proyecto PSP: un analista de fraude busca a un cliente mediante correo electrónico, teléfono o referencia de cuenta cifrados y recupera el registro, mientras que el valor en texto plano no llega a Atlas. Esta capacidad mantiene la información personal sensible cifrada en reposo y disponible por valor, sin el descifrado masivo que amplía el CDE.

Los campos que requieren protección pero no búsqueda utilizan un modo no indexable, que solo se descifra para solicitudes autorizadas y con prioridad. La sección del modelo de datos abarca ambos modos y los campos que protegen.

Capacidades de MongoDB para la capa de aplicación

El proyecto PSP combina varias funcionalidades de MongoDB y Atlas. Cada una se corresponde con 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, que incluyen un límite de API estable, cifrado consultable a nivel de campo y un modelo DEK por nivel de acceso, pueden aplicarse a otros casos de uso:

• Finanzas abiertas: Acceso a datos con alcance de consentimiento que restringe a un tercero a los campos que un cliente autorizó, como PSD2 y el derecho de datos del consumidor.

• Atención médica: Información de salud protegida según la HIPAA.

• Seguros y patrimonio: Plataformas que gestionan identificadores gubernamentales y datos de cuentas financieras en virtud del RGPD.

Componentes de la arquitectura

La arquitectura utiliza los siguientes componentes:

• Panel de control de PSP (Frontend): La capa de presentación. No se comunica directamente con la base de datos. Al finalizar la compra, tokeniza el PAN, por lo que el núcleo de PSP no transmite ni almacena el PAN completo.

• Puerta de enlace API de PSP (Backend): El único punto de entrada y el único componente capaz de descifrar campos protegidos. Alberga el cliente de cifrado consultable, resuelve el rol del solicitante y selecciona el nivel de clave correcto para cada solicitud. Todos los solicitantes, incluyendo la interfaz de usuario, las cuentas de servicio y las integraciones, utilizan la misma API y están sujetos a las mismas reglas de control de acceso basado en roles (RBAC) y de claves.

• MongoDB Atlas (M10 o superior) con cifrado consultable: Almacena únicamente texto cifrado (subtipo 06 binario) para cada campo protegido. Un administrador de base de datos con acceso completo 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 de igualdad, que se admite en producción.

• AWS KMS: Almacena la clave maestra de cliente (CMK) que encapsula y descifra las claves de cifrado de datos. La CMK permanece en KMS y MongoDB no tiene acceso a ella. Se puede utilizar un proveedor de claves local como alternativa sin conexión para las demostraciones.

Tipos de consultas y cómo se aplican en el proyecto.

El cifrado consultable de MongoDB mantiene un campo cifrado en el lado del cliente, al tiempo que permite al servidor consultar el texto cifrado. El proyecto PSP utiliza estos tipos de consulta:

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

• Sin consulta (solo recuperación): Modo no consultable para los campos de mayor sensibilidad, incluidos la dirección residencial, el identificador gubernamental y las cargas útiles de la puerta de enlace sin procesar. Un cliente autorizado descifra estos campos solo en el momento preciso.

• Rango (producción): Se utiliza para búsquedas de rangos de valores, como el filtrado por un rango de importe. Mantiene el importe cifrado.

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

Para los campos de tarjeta y PII incluidos en el ámbito de PCI DSS que se detallan a continuación, el diseño de acceso se reduce a las siguientes categorías:

Entre las opciones de diseño que, en la medida de lo posible, mantienen los datos del titular de la tarjeta fuera del alcance de la investigación, se incluyen:

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

• Captura cero de SAD: Los puntos finales nunca capturan SAD como CVV o PIN.

Reduzca el alcance mediante la segmentación y la tokenización.

Una práctica común de PCI DSS evita que los datos de los titulares de tarjetas se almacenen en sistemas que no los necesitan, de modo que la mayor parte de la plataforma queda fuera del Entorno de Datos del Tarjeta (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 excluye 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 de 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 del titular de la tarjeta y queda fuera del alcance. El PAN completo pertenece al subsistema del emisor de la tarjeta, que es externo en producción. En la demostración, un módulo emisor integrado reemplazable actúa como tal y almacena el PAN en su propia bóveda aislada, cifrada QE:equality con. Este campo se puede cotejar para una búsqueda exacta y detección de duplicados sin necesidad de descifrarlo.

• La información de identificación personal (PII) está centralizada: los campos de identidad, como el correo electrónico o el teléfono, se almacenan en una única colección de partes BIAN SD- a la13 que hacen referencia los registros de acuerdos, tarjetas y transacciones. Un único lugar para proteger y procesar las solicitudes de eliminación de datos personales.

• Los campos sensibles se encuentran detrás de un nivel de clave separado: QE:none Los campos utilizan un nivel de clave de cifrado de datos diferente al de los campos QE:equality que se pueden buscar, por lo que el límite entre los datos sensibles y los no sensibles se aplica mediante las claves.

Se trata de un patrón de referencia, no de una certificación. La definición del CDE y su validación son responsabilidad del cliente y del evaluador, quien debe confirmarlas.

El control de acceso se aplica mediante claves, no mediante código de aplicación.

Separe DEK para respaldar los niveles de cifrado:

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

• Nivel sensible: QE:none Las claves solo están disponibles 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: 1 El mapa de campos cifrados de un cliente de nivel omite las claves confidenciales, por lo que el controlador no puede descifrar esos campos y los devuelve como texto cifrado. El control de acceso a nivel de campo 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 consulta. Cuando un analista escala un caso y un investigador de nivel 2 lo aprueba, el investigador recibe un token de escalamiento que activa el grupo de clientes de nivel confidencial para esa solicitud.