Protección de datos en un clúster regulado de AKS para PCI-DSS 3.2.1 (parte 4 de 9)

En este artículo, se describen las consideraciones para un clúster de Azure Kubernetes Service (AKS) que ejecuta una carga de trabajo que cumple el Estándar de seguridad de datos del sector de tarjetas de pago (PCI-DSS 3.2.1).

Este artículo forma parte de una serie. Consulte la introducción.

Esta arquitectura y la implementación se centran en la infraestructura y no en la carga de trabajo. En este artículo, se proporcionan consideraciones generales y procedimientos recomendados para ayudarle a tomar decisiones de diseño. Siga los requisitos del estándar PCI-DSS 3.2.1 oficial y use este artículo como información adicional, donde proceda.

Clúster regulado de AKS para PCI-DSS 3.2.1: protección de datos

Requisito 3: Protección de los datos de titulares de tarjetas almacenados

Sus responsabilidades

Requisito 3.1

Almacene la mínima cantidad de datos de titulares de tarjetas e implemente procedimientos, procesos y directivas de retención y eliminación de datos que contemplen, como mínimo, las siguientes especificaciones para todo el almacenamiento de datos de titulares de tarjetas (CHD):

• La cantidad de almacenamiento de datos y el período de retención deben limitarse a lo estipulado por la legislación, la normativa aplicable o los requisitos del negocio.
• Deben aplicarse procesos para eliminar los datos de forma segura cuando ya no resulten necesarios.
• Deben aplicarse requisitos de retención específicos para los datos de los titulares de tarjeta.
• Debe aplicarse un proceso trimestral para identificar y eliminar con seguridad los datos de titulares de tarjeta almacenados que sobrepasen los plazos de retención estipulados.

Sus responsabilidades

No almacene el estado en el clúster de AKS. Si decide almacenar CHD, explore las opciones de almacenamiento seguro. Entre las opciones, se encuentran Azure Storage para el almacenamiento de archivos o bases de datos como Azure SQL Database o Azure Cosmos DB.

Siga estrictamente las instrucciones del Estándar sobre qué tipo de CHD se puede almacenar. Defina directivas de retención de datos en función de los requisitos empresariales y el tipo de almacenamiento utilizado. Estas son algunas consideraciones clave:

• ¿Cómo y dónde se almacenan los datos?
• ¿Se cifran los datos almacenados?
• ¿Cuál es el período de retención?
• ¿Qué acciones se permiten durante el período de retención?
• ¿Cómo se eliminan los datos almacenados una vez expirado el período de retención?

Disponga de directivas de gobernanza en torno a algunas de esas opciones. Las directivas integradas de Azure aplican esas opciones. Por ejemplo, puede restringir los tipos de volumen en los pods del clúster o denegar las operaciones de escritura en el sistema de archivos raíz.

Revise esta lista de definiciones de directivas y aplíquelas al clúster, si procede.

Es posible que tenga que almacenar temporalmente en caché los datos. Se recomienda proteger los datos almacenados en caché mientras se mueven a una solución de almacenamiento. Considere la posibilidad de habilitar la característica de cifrado basado en host en AKS. Esto cifrará los datos almacenados en máquinas virtuales de los nodos. Para más información, consulte Cifrado basado en host en Azure Kubernetes Service (AKS). Además, habilite una directiva integrada de Azure que requiera el cifrado de los discos temporales y el almacenamiento en caché para los grupos de nodos.

Al elegir una tecnología de almacenamiento, explore las características de retención. Por ejemplo, Azure Blob Storage proporciona directivas de retención basadas en tiempo. Otra opción es implementar una solución personalizada que elimine los datos según las directivas de retención. Un ejemplo es la Administración del ciclo de vida de los datos (DLM), que administra las actividades del ciclo de vida de los datos. La solución se ha diseñado con servicios como Azure Data Factory, Microsoft Entra ID y Azure Key Vault.

Para más información, consulte Administración del ciclo de vida de los datos con Azure Data Factory.

Requisito 3.2

No almacene datos de autenticación confidenciales después de la autorización (aunque estén cifrados). Si recibe datos de autenticación confidenciales, procéselos de forma que, una que se complete el proceso de autorización, resulten irrecuperables.

Sus responsabilidades

(SE APLICA A: Requisito 3.2.1, Requisito 3.2.2 y Requisito 3.2.3)

El procesamiento y la protección de los datos es una cuestión de carga de trabajo que está fuera del ámbito de esta arquitectura. A continuación, se indican algunas consideraciones generales.

Según el estándar, los datos de autenticación confidenciales constan de los datos de seguimiento completos, el código o valor de validación de la tarjeta y los datos del PIN. Como parte del procesamiento de CHD, asegúrese de que los datos de autenticación no se exponen en orígenes como:

• Registros que se emiten desde los pods.
• Rutinas para el control de excepciones.
• Nombres de archivos.
• Cachés.

Como guía general, los comerciantes no deben almacenar esta información. Si hay una necesidad, documente la justificación comercial.

Requisito 3.3

Enmascare el número PAN cuando se muestre en la pantalla (lo máximo que debe mostrarse son los seis primeros dígitos y los cuatro últimos), de forma que solo el personal que lo necesite por un motivo comercial legítimo pueda ver el número PAN completo.

Sus responsabilidades

El número de cuenta principal (PAN) se considera información confidencial y se debe evitar la exposición de estos datos. Una manera es reducir los dígitos mostrados mediante el enmascaramiento.

No implemente el enmascaramiento de datos en la carga de trabajo. En su lugar, use construcciones de nivel de base de datos. La línea de servicios de Azure SQL, incluido Azure Synapse Analytics, admite el enmascaramiento dinámico de datos, lo que reduce la exposición en el nivel de aplicación. Se trata de una característica de seguridad basada en directivas que define quién puede ver los datos sin máscara y cuántos datos se exponen mediante el enmascaramiento. El método de enmascaramiento de tarjetas de crédito integrado expone los últimos cuatro dígitos de los campos designados y agrega una cadena constante como prefijo con el formato de una tarjeta de crédito.

Para más información, consulte Enmascaramiento dinámico de datos.

Si necesita traer datos sin enmascarar al clúster, enmascárelos lo antes posible.

Requisito 3.4

Procese los números PAN para que resulten ilegibles en cualquier lugar donde estén almacenados (incluidos los medios digitales portátiles, los soportes físicos de copia de seguridad y los registros) mediante cualquiera de los enfoques siguientes:

• Algoritmos hash unidireccionales basados en una criptografía segura (el hash debe abarcar todo el número PAN)
• Truncamiento (no se puede utilizar un algoritmo hash para reemplazar el segmento truncado del número PAN)
• Tokens y almohadillas de índice (las almohadillas deben guardarse de forma segura)
• Criptografía segura con procesos y procedimientos asociados para la administración de claves

Sus responsabilidades

Para este requisito, es posible que tenga que usar criptografía directa en la carga de trabajo. La guía de PCI DSS recomienda el uso de algoritmos probados por el sector para que puedan hacer frente a ataques reales. Evite el uso de algoritmos de cifrado personalizados.

Las técnicas adecuadas de enmascaramiento de datos también cumplen este requisito. Es responsable de enmascarar todos los datos del número de cuenta principal (PAN). La línea de servicios de Azure SQL, incluido Azure Synapse Analytics, admite el enmascaramiento dinámico de datos. Consulte Requisito 3.3.

Asegúrese de que el número PAN no se exponga como parte de los procesos del flujo de trabajo. A continuación, se indican algunas consideraciones:

• No incluya el número PAN en los registros, tanto los registros del flujo de trabajo como los registros del control de excepciones (esperadas e inesperadas). Además, los flujos de datos de diagnóstico, como los encabezados HTTP, no deben exponer estos datos.

• No use el número PAN como clave de búsqueda de caché ni como parte de ningún nombre de archivo generado por este proceso.

• Es posible que los clientes proporcionen el número PAN en campos de texto de forma libre sin ser solicitado. Asegúrese de que estén en funcionamiento procesos de validación y detección de contenido para los campos de texto de forma libre, limpiando todo el contenido similar a los datos de un número PAN.

Requisito 3.4.1

Si se utiliza el cifrado de disco (en lugar del cifrado de base de datos en el nivel de archivo o columna), el acceso lógico debe administrarse con independencia de los mecanismos nativos de autenticación y control de acceso del sistema operativo (por ejemplo, sin utilizar credenciales de inicio de sesión en la red general o bases de datos de cuentas de usuario locales). Las claves de descifrado no deben estar vinculadas con las cuentas de usuario.

Sus responsabilidades

Como regla general, no almacene el estado en el clúster de AKS. Use un almacenamiento de datos externo que admita el cifrado de nivel de motor de almacenamiento.

Todos los datos almacenados en Azure Storage se cifran y descifran mediante criptografía segura. Microsoft administra las claves asociadas. Se prefieren las claves de cifrado autoadministradas. Cifre siempre fuera de la capa de almacenamiento y escriba solo los datos cifrados en el medio de almacenamiento, lo que garantiza que las claves nunca son adyacentes a la capa de almacenamiento.

Con Azure Storage, también puede usar claves autoadministradas. Para más información, consulte Claves administradas por el cliente para el cifrado de Azure Storage.

Hay funcionalidades similares disponibles para las bases de datos. Para conocer la opciones de Azure SQL, consulte Cifrado de datos transparente de Azure SQL con una clave administrada por el cliente.

Asegúrese de almacenar las claves en un almacén de claves administrado, como Azure Key Vault, HSM administrado de Azure o una solución de administración de claves de terceros.

Si tiene que almacenar datos temporalmente, habilite la característica de cifrado de host de AKS para asegurarse de que los datos almacenados en los nodos de máquina virtual estén cifrados.

Requisito 3.5

Documente e implemente procedimientos para proteger las claves que se utilizan para guardar los datos de los titulares de tarjetas de forma segura y evitar su divulgación y uso indebido-

Sus responsabilidades

Estos puntos se describen en las subsecciones:

• Mantenga la práctica de acceso con privilegios mínimos para las claves criptográficas.
• Azure Key Vault y Microsoft Entra ID están diseñados para admitir los requisitos de registro de autorización y auditoría. Para más información, consulte Solicitud de autenticación para Azure Key Vault.
• Proteja todas las claves de cifrado de datos con una clave de cifrado de claves almacenada en un dispositivo criptográfico.
• Si usa claves autoadministradas (en lugar de claves administradas por Microsoft), disponga de un proceso y documentación para mantener las tareas relacionadas con la administración de claves.

Requisito 3.5.1

Requisito adicional exclusivo para proveedores de servicios: mantenga una descripción documentada de la arquitectura de cifrado que incluya:

• Detalles de todos los algoritmos, claves y protocolos utilizados para la protección de los datos de los titulares de tarjeta, incluida la fecha de caducidad y el nivel de seguridad de la clave
• Descripción del uso de cada clave
• Inventario de los HSM y otras DVL que se utilizan para la administración de claves

Sus responsabilidades

Una manera de almacenar información confidencial (claves, cadenas de conexión, etc.) es usar el recurso Secret nativo de Kubernetes. Debe habilitar explícitamente el cifrado en reposo. Como alternativa, almacénelos en un almacén administrado, como Azure Key Vault. De los dos enfoques, se recomienda usar un servicio de almacén administrado. Una ventaja es la reducción de la sobrecarga en las tareas relacionadas con la administración de claves, como la rotación de claves.

De manera predeterminada, Azure usa claves administradas por Microsoft para todos los datos cifrados, por cada cliente. Sin embargo, algunos servicios también admiten claves autoadministradas para el cifrado. Si usa claves autoadministradas para el cifrado en reposo, asegúrese de tener en cuenta un proceso y una estrategia que controle las tareas de administración de claves.

Como parte de la documentación, incluya información relacionada con la administración de claves, como la expiración, la ubicación y los detalles del plan de mantenimiento.

Requisito 3.5.2

Restrinja el acceso a las claves criptográficas al menor número de administradores necesario.

Sus responsabilidades

Minimice el número de personas que tienen acceso a las claves. Si usa asignaciones de roles basadas en grupos, configure un proceso de auditoría periódico para revisar los roles que tienen acceso. Cuando los miembros del equipo del proyecto cambien, se deben quitar los permisos de las cuentas que ya no son pertinentes. Solo las personas correctas deben tener acceso. Use las revisiones de acceso de Microsoft Entra ID para revisar periódicamente las pertenencias a grupos.

Considere la posibilidad de quitar los permisos permanentes en favor de asignaciones de roles Just-In-Time (JIT), la activación de roles basados en tiempo y la activación de roles basada en aprobación. Por ejemplo, considere la posibilidad de usar Privileged Identity Management.

Requisito 3.5.3

Guarde en todo momento las claves secretas y privadas que se utilizan para cifrar o descifrar los datos de los titulares de tarjetas mediante uno (o varios) de los siguientes mecanismos:

• Los datos deben cifrarse con una clave de cifrado de claves que sea al menos tan segura como la clave de cifrado de datos y que esté guardada en un lugar diferente al de la clave de cifrado de datos.
• Los datos deben guardarse en un dispositivo de cifrado seguro; por ejemplo, un módulo de seguridad (host) de hardware (HSM) o un dispositivo de punto de interacción aprobado por PTS.
• Los datos deben guardarse en al menos dos componentes o recursos compartidos de claves que se ajusten a un método aceptado por el sector.

Sus responsabilidades

Una carga de trabajo PCI-DSS 3.2.1 deberá usar más de una clave de cifrado como parte de la estrategia de protección de datos en reposo. Se usa una clave de cifrado de datos (DEK) para cifrar y descifrar los CHD, pero usted es responsable de una clave de cifrado de claves (KEK) adicional para proteger esa DEK. También es responsable de garantizar que la KEK se almacene en un dispositivo criptográfico.

Puede usar Azure Key Vault para almacenar la DEK y usar Azure Dedicated HSM para almacenar la KEK. Para obtener información sobre la administración de claves con HSM, consulte ¿Qué es Azure Dedicated HSM?

Requisito 3.6

Documente e implemente completamente todos los procedimientos y procesos de administración de las claves criptográficas que se utilizan para cifrar los datos de los titulares de tarjetas, incluidos los siguientes:

Sus responsabilidades

(SE APLICA A: Requisito 3.6.1, Requisito 3.6.2, Requisito 3.6.3 y Requisito 3.2.4)

Si usa Azure Key Vault para almacenar secretos como claves, certificados y cadenas de conexión, protéjalo frente a accesos no autorizados. Microsoft Defender para Key Vault detecta intentos de acceso sospechosos y genera alertas. Puede ver estas alertas en Microsoft Defender for Cloud. Para más información, consulte Microsoft Defender para Key Vault.

Siga las guía de NIST sobre la administración de claves. Para obtener detalles, consulte:

• Administración de claves criptográficas.
• SP 800-133 Rev. 2, Recomendación para la generación de claves criptográficas
• SP 800-57 Parte 1 Rev. 5, Recomendación para la administración de claves

Habilite Microsoft Defender para Key Vault.

Requisito 3.6.7

Prevención de la sustitución no autorizada de claves criptográficas.

Sus responsabilidades

• Habilite los diagnósticos en todos los almacenes de claves. Utilice Azure Monitor para Key Vault. Recopila registros y métricas y los envía a Azure Monitor. Para más información, consulte Supervisión del servicio Key Vault con Azure Monitor para Key Vault.
• Conceda permisos de solo lectura a todos los consumidores.
• No tenga permisos permanentes para todos los usuarios o entidades de administración. En su lugar, use asignaciones de roles Just-In-Time (JIT), activación de roles basada en tiempo y activación de roles basada en aprobación.
• Cree una vista centralizada mediante la integración de los registros y las alertas en soluciones de Administración de eventos e información de seguridad (SIEM), como Microsoft Sentinel.
• Tome medidas para las alertas y las notificaciones, especialmente en los cambios inesperados.

Requisito 3.6.8

Es obligatorio que los administradores de las claves criptográficas confirmen formalmente que conocen y aceptan las responsabilidades de los administradores de claves.

Sus responsabilidades

Mantenga documentación que describa las responsabilidades de las partes responsables de las operaciones de administración de claves.

Requisito 3.7

Asegúrese de que las directivas de seguridad y los procedimientos operativos para proteger los datos de titulares de tarjetas queden documentados y que todas las partes afectadas los conozcan y los usen.

Sus responsabilidades

Cree documentación en forma de unas instrucciones generales más una serie de guías de roles actualizadas para todos los roles. Lleve a cabo la formación para las nuevas contrataciones y una formación continua.

Es fundamental mantener una documentación exhaustiva sobre los procesos y las directivas. Participan varios equipos para asegurarse de que los datos estén protegidos en reposo y en tránsito. En la documentación, proporcione instrucciones de rol para todos los roles. Los roles deben incluir SRE, soporte al cliente, ventas, operaciones de red, operaciones de seguridad, ingenieros de software, administradores de bases de datos y otros. El personal debe tener formación en la guía de NIST y las estrategias sobre datos en reposo para mantener actualizado el conjunto de aptitudes. Los requisitos de entrenamiento se tratan en el Requisito 6.5 y el Requisito 12.6.

Requisito 4: Cifrado de la transmisión de datos de titulares de tarjetas en las redes abiertas y públicas

Sus responsabilidades

Requisito 4.1

Use protocolos seguros de criptografía y seguridad (por ejemplo, TLS, IPSEC, SSH, etc.) para proteger la información confidencial de los titulares de tarjetas durante la transmisión mediante redes públicas y abiertas, incluidos los siguientes casos:

Sus responsabilidades

Se deben cifrar los datos del titular de la tarjeta (CHD) que transitan en la red pública de Internet. Los datos se deben cifrar con TLS 1.2 (o posterior), con compatibilidad de cifrado reducido para todas las transmisiones. No se admiten redireccionamientos de no TLS a TLS en ningún servicio de transmisión de datos.

El diseño debe tener una cadena estratégica de puntos de terminación TLS. A medida que los datos viajan por los saltos de red, mantenga TLS en los saltos que requieran inspección de paquetes. Como mínimo, tenga el punto de terminación TLS final en el recurso de entrada del clúster. Considere la posibilidad de continuar dentro de los recursos del clúster.

Use Azure Policy para gobernar la creación de recursos:

• Deniegue la creación de cualquier recurso de entrada que no sea HTTPS.
• Deniegue la creación de cualquier dirección IP pública o de cualquier equilibrador de carga público en el clúster para asegurarse de que el tráfico web se tunelice mediante la puerta de enlace.

Para más información, consulte Información general del cifrado de Azure.

Requisito 4.1.1

Asegúrese de que las redes inalámbricas que transmitan los datos de titulares de tarjetas o que estén conectadas con el entorno de datos de titulares de tarjetas usen los procedimientos recomendados del sector (por ejemplo, IEEE 802.11i) para implementar el cifrado seguro para la autenticación y la transmisión.

Sus responsabilidades

Esta arquitectura y la implementación no están diseñadas para realizar transacciones de la red local o corporativa a la nube mediante conexiones inalámbricas. Para conocer las consideraciones, consulte la guía del Estándar PCI-DSS 3.2.1 oficial.

Requisito 4.2

No enviar nunca números PAN sin protección mediante tecnologías de mensajería del usuario final (por ejemplo, correo electrónico, mensajería instantánea, SMS, chat, etc.).

Sus responsabilidades

Si la carga de trabajo requiere enviar correos electrónicos, considere la posibilidad de crear una puerta de cuarentena de correo electrónico. Esta validación le permitirá examinar todos los mensajes salientes para comprobar el cumplimiento y comprobar que no se incluya información confidencial. Idealmente, también debe tener en cuenta este enfoque para los mensajes de soporte técnico al cliente.

La validación se debe realizar en el nivel de carga de trabajo y el proceso de control de cambios. Las puertas de aprobación deben ser conscientes del requisito.

Para conocer las consideraciones, consulte la guía del Estándar PCI-DSS 3.2.1 oficial.

Requisito 4.3

Asegúrese de que las directivas de seguridad y los procedimientos operativos para cifrar las transmisiones de los datos de titulares de tarjetas estén documentados, en uso y que todas las partes afectadas los conozcan.

Sus responsabilidades

Es fundamental mantener una documentación exhaustiva sobre los procesos y las directivas. Esto es especialmente cierto cuando se administran directivas sobre Seguridad de la capa de transporte (TLS). Estas son algunas de las áreas:

• Puntos de entrada de la red pública de Internet. Un ejemplo es la compatibilidad de Azure Application Gateway con los cifrados TLS.
• Saltos de red entre la red perimetral y los pods de la carga de trabajo.
• Cifrado de pod a pod (si se implementa). Esto puede incluir detalles sobre la configuración de una malla de servicio.
• De los pods al almacenamiento (si forma parte de la arquitectura).
• De los pods a servicios externos, servicios PaaS de Azure que usan TLS, una puerta de enlace de pago o un sistema de detección de fraudes.

Las personas que operan en entornos regulados deben estar formadas e informadas y se les debe incentivar para respaldar las garantías de seguridad. Esto es especialmente importante para las personas que forman parte del proceso de aprobación desde una perspectiva de directiva.

Pasos siguientes

Proteja todos los sistemas frente al malware y actualice frecuentemente los programas o software antivirus. Desarrolle y mantenga aplicaciones y sistemas seguros.