Resumen del clúster regulado de AKS para PCI DSS 4.0.1

La guía proporcionada en esta serie incorpora principios bien diseñados en todas las opciones de diseño. En este artículo se resumen esas opciones.

Con este artículo finaliza esta serie. Lea la introducción.

Implementación de referencia del logotipo de GitHub próximamente: el clúster de línea base de Azure Kubernetes Service (AKS) para la implementación de referencia de cargas de trabajo reguladas para PCI DSS 4.0.1 se está actualizando y estará disponible pronto. Esta implementación demostrará una infraestructura regulada que ilustra el uso de varios controles de red y seguridad dentro del CDE. Esto incluye los controles de red nativos de Azure y los controles nativos de Kubernetes. También incluirá una aplicación para mostrar las interacciones entre el entorno y una carga de trabajo de ejemplo. El enfoque de este artículo es la infraestructura. El ejemplo no será indicativo de una carga de trabajo real PCI-DSS 4.0.1.

Marco bien diseñado

El Microsoft Azure Well-Architected Framework es un conjunto de principios rectores que se pueden usar para evaluar una solución a través de los pilares de calidad de excelencia de la arquitectura:

Las cargas de trabajo de PCI DSS 4.0.1 exigen el rigor de ser una solución bien diseñada. Aunque la alineación de la infraestructura con los requisitos de PCI es crítica, el cumplimiento no se detiene en la infraestructura de hospedaje. No abordar los pilares de calidad, específicamente la seguridad, puede poner en peligro el cumplimiento. Las soluciones con buena arquitectura combinan las perspectivas de infraestructura y de carga de trabajo para alcanzar el rigor necesario para lograr resultados conformes. PCI DSS 4.0.1 presenta nuevos requisitos para el cumplimiento continuo, el ámbito basado en riesgos, la supervisión mejorada y el desarrollo de software seguro, que se abordan en esta guía.

Entre las mejoras clave de PCI DSS 4.0.1 relevantes para los entornos de nube y contenedor se incluyen:

  • Enfoque personalizado: flexibilidad para cumplir los objetivos de seguridad mediante controles alternativos adecuados para arquitecturas nativas de nube.
  • Autenticación mejorada: se reforzaron los requisitos de autenticación multifactor para todo el acceso al entorno de datos de titulares de tarjetas.
  • Validación continua: supervisión y validación continuas de controles de seguridad en lugar de evaluaciones a un momento dado.
  • Seguridad automatizada: integración de la seguridad en canalizaciones de DevSecOps con análisis automatizado de vulnerabilidades y pruebas de seguridad.
  • Seguridad de los contenedores: guía específica para cargas de trabajo en contenedores y infraestructura efímera.
  • Principios de confianza cero: énfasis en los enfoques de comprobación y acceso con privilegios mínimos.

Fiabilidad

La confiabilidad de los entornos regulados debe ser predecible para que se puedan explicar de forma coherente en la auditoría. Siga la guía fundamental proporcionada en los principios de confiabilidad. En las secciones siguientes se resumen los procedimientos recomendados de confiabilidad para un entorno regulado.

Destinos de recuperación y recuperación ante desastres

Debido a la naturaleza confidencial de los datos que se manejan en las cargas de trabajo reguladas, es fundamental la definición de los objetivos de recuperación y los objetivos de punto de recuperación (RPO). ¿Cuál es la pérdida aceptable de CHD? Los esfuerzos de recuperación dentro del CDE siguen sujetos a los requisitos estándar. Espere errores y disponga de un plan de recuperación claro que se alinee con los roles, las responsabilidades y el acceso a datos justificado. Los problemas del sitio en directo no son justificación para desviarse de ninguna normativa. Esto es especialmente importante en una situación de recuperación ante desastres completa. Tenga documentación clara de recuperación ante desastres que se ajuste a los requisitos y minimice el acceso inesperado a CDE o CHD. Después de la recuperación, revise siempre los pasos del proceso de recuperación para asegurarse de que no se ha producido ningún acceso inesperado. Documente las justificaciones empresariales de esas instancias.

Recuperación

Agregar estrategias de resistencia y recuperación a la arquitectura puede evitar la necesidad de acceso ad hoc al CDE. El sistema debe ser capaz de recuperarse por sí mismo en el RPO definido sin necesidad de intervención humana directa. De este modo, puede eliminar la exposición innecesaria de CHD, incluso a aquellas personas que están autorizadas a tener acceso de emergencia. El proceso de recuperación debe ser auditable.

Revise los riesgos de seguridad porque pueden ser un origen de tiempo de inactividad y pérdida de datos de la carga de trabajo. Las inversiones en seguridad también afectan a la confiabilidad de las cargas de trabajo.

Procesos operativos

La confiabilidad se extiende a todos los procesos operativos y adyacentes del CDE. Procesos bien definidos, automatizados y probados para cuestiones como la creación de imágenes y la administración de jumpbox se incluyen una solución con buena arquitectura.

Seguridad

Siga la guía fundamental proporcionada en los principios de diseño de seguridad. En las secciones siguientes se resumen los procedimientos recomendados de seguridad para un entorno regulado.

Gobernanza

La implementación de gobernanza se basa en los requisitos de cumplimiento de PCI DSS 4.0.1. Esto influye en los controles técnicos para mantener la segmentación, el acceso a los recursos, la detección de vulnerabilidades y, lo que es más importante, la protección de los datos de los clientes. PCI DSS 4.0.1 destaca la responsabilidad compartida, la supervisión continua y el uso de herramientas automatizadas para la administración de inventario y configuración en entornos de nube y contenedor.

Supervisión continua de cumplimiento: a diferencia del enfoque de evaluación periódica de versiones anteriores, PCI DSS 4.0.1 requiere la validación continua de los controles de seguridad. Esto se alinea bien con las funcionalidades de supervisión nativas de la nube, como Azure Monitor, Microsoft Defender for Cloud y la aplicación automatizada de directivas a través de Azure Policy.

Ámbito basado en riesgos: el estándar ahora permite un ámbito más dinámico en función de los flujos de datos reales y las evaluaciones de riesgos, lo que es especialmente relevante para las cargas de trabajo en contenedores en las que los componentes pueden ser efímeros y orquestados dinámicamente.

Estrategia de segmentación empresarial

Para mantener el aislamiento completo, se recomienda implementar la infraestructura regulada en una suscripción independiente. Si tiene varias suscripciones necesarias para el cumplimiento, considere la posibilidad de agruparlas en una jerarquía de grupos de administración que aplique uniformemente las directivas de Azure pertinentes en las suscripciones dentro del ámbito. Dentro de la suscripción, aplique las directivas de Azure relacionadas en un nivel de suscripción para capturar las directivas generales que se deben aplicar a todos los clústeres del entorno de datos de los titulares de las tarjetas (CDE). Aplique las directivas de Azure relacionadas en el nivel de grupo de recursos para capturar las directivas que se aplican a una instancia específica de clúster. Estas directivas crean las barreras de protección principales de una zona de aterrizaje.

Aísle la carga de trabajo de PCI (dentro del ámbito) de otras cargas de trabajo (fuera del ámbito) en términos de operaciones y conectividad. Puede crear aislamiento mediante la implementación de clústeres independientes o usar estrategias de segmentación para mantener la separación. Por ejemplo, los clústeres usan grupos de nodos independientes para que las cargas de trabajo nunca compartan una máquina virtual (VM) de nodo.

Aplicación de directivas

Aplique controles de seguridad mediante la habilitación de directivas de Azure. Por ejemplo, en esta arquitectura reglada, puede evitar la configuración incorrecta del entorno de datos de los titulares de las tarjetas. Puede aplicar una directiva de Azure que no permita asignaciones de direcciones IP públicas en los nodos de máquina virtual. Estas asignaciones se detectan y notifican o bloquean.

Para obtener información sobre las directivas que puede habilitar para AKS, consulte Definiciones integradas de Azure Policy para Azure Kubernetes Service (AKS).

Azure proporciona varias directivas integradas para la mayoría de los servicios. Revise las definiciones de directivas integradas de Azure Policy y aplíquelas según corresponda.

Supervisión del cumplimiento

El cumplimiento debe supervisarse y mantenerse sistemáticamente. Se realizan atestaciones de cumplimiento periódicas. Saber si los recursos en la nube son conformes le ayudará a prepararse para las atestaciones y la auditoría.

Aproveche el panel de cumplimiento normativo de Microsoft Defender for Cloud. Al supervisar continuamente el panel, puede realizar un seguimiento del estado de cumplimiento de la carga de trabajo.

Captura de pantalla de un panel de supervisión de cumplimiento de ejemplo en Azure Portal.

Seguridad de red

En una topología en estrella tipo hub-and-spoke, tener redes virtuales independientes para cada entidad proporciona una segmentación básica en la superficie de la red. Cada red se segmenta más en subredes.

El clúster de AKS forma el núcleo del CDE. No debe ser accesible desde direcciones IP públicas y se debe proteger la conectividad. Los flujos típicos dentro y fuera de CDE se pueden clasificar como:

  • Tráfico entrante al clúster.
  • Tráfico saliente del clúster.
  • Tráfico dentro del clúster entre pods.

Para cumplir los requisitos de un entorno regulado, el clúster se implementa como un clúster privado. En este modo, el tráfico hacia y desde la red pública de Internet está restringido. Incluso la comunicación con el servidor de API de Kubernetes administrado por AKS es privada. La seguridad se mejora aún más con controles de red estrictos y reglas de firewall IP:

  • Grupos de seguridad de red (NSG) para ayudar a proteger la comunicación entre los recursos de una red.
  • Azure Firewall para filtrar el tráfico saliente entre los recursos en la nube, Internet y el entorno local.
  • Azure Application Gateway integrado en el marco de trabajo de la aplicación web de Azure para filtrar todo el tráfico entrante desde Internet que Azure Application Gateway intercepta.
  • Kubernetes NetworkPolicy para permitir solo determinadas rutas de acceso entre los pods del clúster.
  • Azure Private Link para conectarse a otros servicios de plataforma como servicio (PaaS) de Azure, como Azure Key Vault y Azure Container Registry, para tareas operativas.

Los procesos de supervisión están preparados para asegurarse de que el tráfico fluya según lo previsto y de que se detecte y notifique cualquier anomalía.

Para obtener más información sobre la seguridad de red, consulte Segmentación de red.

Seguridad de datos

PCI DSS 4.0.1 requiere que todos los datos de titulares de tarjetas (CHD) nunca estén claros, ya sea en tránsito o en almacenamiento.

Dado que esta arquitectura y la implementación se centran en la infraestructura y no en la carga de trabajo, no se muestra la administración de datos. En las secciones siguientes se describen algunas recomendaciones bien diseñadas.

Datos en reposo

Los datos deben cifrarse a través de algoritmos de cifrado estándar del sector.

  • No almacene datos en el entorno de los titulares de las tarjetas.
  • Cífrelos fuera de la capa de almacenamiento.
  • Escriba solo datos cifrados en el medio de almacenamiento.
  • No almacene las claves en la capa de almacenamiento.

Todos los datos de Azure Storage se cifran y descifran mediante criptografía segura. Se prefieren las claves de cifrado autoadministradas.

Si necesita almacenar datos temporalmente, aplique las mismas consideraciones a dichos datos. Se recomienda encarecidamente habilitar la característica de cifrado de host de AKS. Puede forzar el cifrado de datos temporales con directivas de Azure integradas.

Al elegir una tecnología de almacenamiento, explore las características de retención. Asegúrese de que todos los datos se quitan de forma segura cuando expire el tiempo configurado.

El estándar también requiere que no se almacenen datos de autenticación confidenciales (SAD). Asegúrese de que los datos no se exponen en registros, nombres de archivo, caché y otros datos.

Datos en tránsito

Toda la comunicación con entidades que interactúan con el CDE debe realizarse a través de canales cifrados. PCI DSS 4.0.1 refuerza los requisitos de cifrado con los conjuntos de cifrado y los estándares de protocolo actualizados.

  • Solo se debe permitir que fluya al CDE tráfico HTTPS. En esta arquitectura, Azure Application Gateway deniega todo el tráfico a través del puerto 80.
  • Preferiblemente, no cifre y descifre los datos fuera del CDE. Si lo hace, considere que esa entidad forma parte del CDE.
  • Dentro del CDE, proporcione una comunicación segura entre pods con mTLS. Puede optar por implementar una malla de servicio para este propósito.
  • Permita solo cifrados seguros y TLS 1.2 o versiones posteriores. PCI DSS 4.0.1 proporciona instrucciones actualizadas sobre protocolos de cifrado aceptables y conjuntos de cifrado.
  • PCI DSS 4.0.1 requiere una administración más rigurosa del ciclo de vida de las claves, incluida la rotación automatizada de claves y la integración del módulo de seguridad de hardware (HSM), si procede.

identidad

Siga estos principios de seguridad al diseñar directivas de acceso:

  • Comience con directivas de confianza cero. Realice las excepciones que necesite.
  • Conceda los privilegios mínimos: basta con completar una tarea.
  • Minimice el acceso permanente.

PCI DSS 4.0.1 refuerza significativamente los requisitos de autenticación, lo que exige la autenticación multifactor (MFA) para todo el acceso al entorno de datos de titular de tarjetas, incluido el acceso administrativo y todo el acceso que no sea de consola.

El control de acceso basado en rol (RBAC) de Kubernetes administra los permisos para la API de Kubernetes. AKS admite esos roles de Kubernetes. AKS está totalmente integrado con Microsoft Entra ID. Puede asignar identidades de Microsoft Entra a los roles y aprovechar también otras funcionalidades.

Acceso de confianza cero

RBAC de Kubernetes, Azure RBAC y los servicios de Azure implementan Denegar todo de forma predeterminada. Reemplace esta configuración con precaución, permitiendo el acceso solo a las entidades que lo necesiten. Otro área para implementar confianza cero es deshabilitar el acceso SSH a los nodos del clúster.

Privilegios mínimos

Puede usar identidades administradas para los recursos y pods de Azure y establecer su ámbito en las tareas previstas. Por ejemplo, Azure Application Gateway debe tener permisos para obtener secretos (certificados TLS) de Azure Key Vault. No debe tener permisos para modificar los secretos.

Minimización del acceso permanente

Minimice el acceso permanente utilizando la pertenencia grupal de Microsoft Entra just-In-Time. Proteja el control con directivas de acceso condicional en Microsoft Entra ID. Esta opción admite muchos casos de uso, como la autenticación multifactor, restringir la autenticación a dispositivos administrados por su inquilino de Microsoft Entra o bloquear intentos de inicio de sesión atípicos.

Administración de secretos

Almacene los secretos, los certificados, las claves y las contraseñas fuera del CDE. Puede usar los objetos de secretos nativos de Kubernetes o un almacén de claves administrado, como Azure Key Vault. El uso de un almacén administrado le ayudará en las tareas de administración de secretos, como la rotación de claves y la renovación de certificados.

Asegúrese de que el acceso al almacén de claves tiene una combinación de controles de acceso y red. Al habilitar identidades administradas, el clúster tiene que autenticarse en Key Vault para obtener acceso. Además, la conectividad con el almacén de claves no debe ser a través de la red pública de Internet. Use una red privada, como Private Link.

Optimización de costos

Siga las instrucciones fundamentales proporcionadas en los principios de optimización de costes.

Una clara contrapartida a los requisitos de cumplimiento y a los estrictos controles de seguridad es el coste. Se recomienda establecer estimaciones iniciales mediante la Calculadora de precios.

En el diagrama siguiente se proporciona una representación de alto nivel del impacto en el costo de los principales recursos que usa esta arquitectura:

Diagrama de administración de costes en la arquitectura.

Los controladores principales son los conjuntos de escalado de máquinas virtuales que son los grupos de nodos y Azure Firewall. Otro colaborador es Log Analytics. También hay costes incrementales asociados a Microsoft Defender for Cloud, en función de la elección de planes.

Tenga una clara comprensión de lo que constituye el precio de un servicio. Azure realiza un seguimiento del uso medido. En el diagrama siguiente se proporciona un desglose de Azure Firewall para esta arquitectura:

Diagrama que muestra la administración de costes en un ejemplo de Azure Firewall.

El coste asociado a algunos recursos, como Azure Firewall, se puede extender a varias unidades de negocio o aplicaciones. Otra manera de optimizar el coste puede ser hospedar un clúster multiinquilino dentro de una organización, maximizando la densidad con diversidad de cargas de trabajo. Sin embargo, no se recomienda este enfoque para cargas de trabajo reguladas. Priorice siempre el cumplimiento y la segmentación sobre las ventajas de costes.

Para mantener dentro de las restricciones presupuestarias, algunas maneras de controlar el costo son ajustar la infraestructura de Azure Application Gateway, establecer el recuento de instancias para el escalado automático y reducir la salida del registro siempre que sigan cumpliendo la pista de auditoría requerida por PCI DSS 4.0.1. Evalúe siempre esas opciones con las contrapartidas de otros aspectos del diseño que le permitan cumplir el Acuerdo de Nivel de Servicio. Por ejemplo, ¿todavía puede escalar correctamente para satisfacer los picos de tráfico?

A medida que cree grupos de recursos de Azure, aplique etiquetas para que se pueda realizar un seguimiento de los costes. Use herramientas de administración de costes como Azure Advisor y Microsoft Cost Management para realizar un seguimiento y analizar los costes.

Considere la posibilidad de habilitar el análisis de costos de AKS para la asignación de costos de infraestructura de clúster pormenorizadas mediante construcciones específicas de Kubernetes.

Excelencia operativa

Siga las instrucciones fundamentales proporcionadas en los principios de excelencia operativa. En las secciones siguientes se resumen los procedimientos recomendados de excelencia operativa para un entorno regulado.

Separación de roles

Es fundamental aplicar una segregación clara de las obligaciones para entornos regulados. Cree definiciones de roles y responsabilidades en función de las necesidades de la carga de trabajo y la interacción con el CDE. Por ejemplo, puede que necesite un rol de operador de infraestructura o de ingeniero de confiabilidad de sitios (SRE) para las operaciones relacionadas con el clúster y los servicios dependientes. El rol es responsable de mantener la seguridad, el aislamiento, la implementación y la observabilidad. Formalice esas definiciones y decida los permisos que necesitan esos roles. Por ejemplo, los SRE tienen privilegios elevados para el acceso al clúster, pero necesitan acceso de lectura para los espacios de nombres de carga de trabajo.

Aislamiento de cargas de trabajo

PCI DSS 4.0.1 requiere el aislamiento de la carga de trabajo PCI de otras cargas de trabajo en términos de operaciones. En esta implementación, las cargas de trabajo dentro y fuera del ámbito se segmentan en dos grupos de nodos de usuarios independientes. Los desarrolladores de aplicaciones para dentro del ámbito y los desarrolladores para cargas de trabajo fuera del ámbito pueden tener distintos conjuntos de permisos. Además, habrá puertas de calidad independientes. Por ejemplo, el código dentro del ámbito está sujeto a cumplimiento y atestación, mientras que el código fuera del ámbito no lo está. También es necesario tener canalizaciones de compilación y procesos de administración de versiones independientes.

PCI DSS 4.0.1 presenta requisitos completos para el desarrollo seguro de software, entre los que se incluyen:

  • Pruebas automatizadas de seguridad integradas en canalizaciones de CI/CD.
  • Pruebas de seguridad de aplicaciones estáticas y dinámicas (SAST/DAST).
  • Examen de vulnerabilidades de la imagen de contenedor antes de la implementación.
  • Examen de dependencias para componentes de terceros.
  • Procesos de revisión de código con enfoque de seguridad.
  • Entrenamiento de codificación segura para equipos de desarrollo.

Metadatos operativos

El requisito 12 del estándar PCI DSS 4.0.1 requiere que mantenga información sobre el inventario de cargas de trabajo y la documentación de acceso al personal. Se recomienda encarecidamente usar etiquetas de Azure porque puede intercalar información de entorno con recursos, grupos de recursos y suscripciones de Azure.

Mantenga información sobre las soluciones aprobadas que forman parte de la infraestructura y la carga de trabajo. Esto incluye una lista de imágenes de máquina virtual, bases de datos y soluciones de terceros de su elección que traiga al CDE. Incluso puede automatizar ese proceso mediante la creación de un catálogo de servicios. Proporciona una implementación de autoservicio mediante las soluciones aprobadas en una configuración específica, que se ajusta a las operaciones en curso de la plataforma.

Observabilidad

Para cumplir el requisito 10, la observabilidad del CDE es fundamental para el cumplimiento. Los registros de actividad proporcionan información sobre las operaciones relacionadas con la administración de cuentas y secretos, la administración de la configuración de diagnóstico, la administración del servidor y otras operaciones de acceso a recursos. Todos los registros se registran con la fecha, la hora, la identidad y otra información detallada. Conserve los registros hasta un año mediante la configuración de directivas de archivado y retención de datos en los registros de Azure Monitor.

Asegúrese de que solo accedan a los registros los roles que los necesiten. Log Analytics y Microsoft Sentinel admiten varios controles de acceso basados en roles para administrar el acceso al registro de auditoría.

Respuesta y corrección

Los servicios de supervisión de Azure, Azure Monitor y Microsoft Defender pueden generar notificaciones o alertas cuando detecten actividad anómala. Estas alertas incluyen información de contexto, como la gravedad, el estado y el tiempo de actividad. A medida que se generan alertas, tenga una estrategia de corrección y revise el progreso. Se recomienda centralizar los datos en una solución de administración de eventos e información de seguridad (SIEM), ya que la integración de datos puede proporcionar un contexto de alertas enriquecido.

Desde la vista Alertas de seguridad de Microsoft Defender para la nube, tiene acceso a todas las alertas que Microsoft Defender para la nube detecta en los recursos. Disponga de un proceso de evaluación de prioridades para solucionar el problema. Trabaje con el equipo de seguridad para comprender cómo se pondrán las alertas pertinentes a disposición de los propietarios de las cargas de trabajo.

Eficiencia del rendimiento

Siga las instrucciones fundamentales proporcionadas en los principios de eficiencia del rendimiento. En las secciones siguientes se resumen los procedimientos recomendados de eficiencia del rendimiento para un entorno regulado.

Ampliación

Observar cómo se ajusta el entorno a las demandas cambiantes indicará el comportamiento esperado del runtime del entorno con una carga elevada. El escalado automático de los recursos de la carga de trabajo minimizará la interacción humana en el CDE. Una ventaja de seguridad adicional es la reducción de la superficie de ataque en todo momento. Puede maximizar la ventaja aprovechando los recursos que admiten el enfoque de escalado a cero. Por ejemplo, AKS admite la reducción vertical de los grupos de nodos de usuario a 0. Para más información, consulte Escalado de grupos de nodos de usuario a 0.

Partición

La creación de particiones es un factor clave para la eficiencia del rendimiento en las cargas de trabajo reguladas. Tener componentes discretos permite definir claramente la responsabilidad y ayuda en la precisión de los controles, como las directivas de red. De forma similar a cualquier estrategia de segmentación, la creación de particiones aísla los componentes y controla el impacto de la onda expansiva de errores inesperados o del peligro del sistema.

Arquitectura sin ningún recurso compartido

La arquitectura sin ningún recurso compartido está diseñada para eliminar la contención entre cargas de trabajo colocadas. Además, se trata de una estrategia para quitar únicos puntos de error. En un entorno regulado, los componentes deben aislarse mediante límites lógicos o físicos. Esto se alinea con la arquitectura sin ningún recurso compartido, lo que genera ventajas de escalabilidad. Permite dirigirse a los controles de seguridad pertinentes y a las funcionalidades de auditoría más estrictas de los distintos componentes.

Cargas de trabajo ligeras

La complejidad de las cargas de trabajo es difícil de documentar y auditar. Procure lograr simplicidad ya que obtendrá ventajas de rendimiento y facilidad de auditoría de los requisitos normativos. Replantéese las opciones que conlleven más dificultades de las necesarias, ya que aumenta el área de superficie de ataque y la posibilidad de un uso o una configuración incorrectos.

Reunirlo todo

La implementación del cumplimiento de PCI DSS 4.0.1 en Azure Kubernetes Service requiere un enfoque completo que aborda todos los aspectos del marco bien diseñado al tiempo que cumple los requisitos específicos del estándar. Esta serie ha proporcionado instrucciones detalladas entre varios dominios, desde la seguridad de red y la protección de datos hasta la administración de identidades y la supervisión continua.

Conclusiones clave

El recorrido al cumplimiento de PCI DSS 4.0.1 en AKS implica varias consideraciones críticas:

  • Infraestructura como base: una infraestructura de AKS segura y compatible es esencial, pero no suficiente. La arquitectura debe admitir los controles de seguridad, las funcionalidades de supervisión y los procesos operativos requeridos por el estándar.
  • Cumplimiento continuo: a diferencia de las versiones anteriores, PCI DSS 4.0.1 enfatiza la validación continua y la supervisión en lugar de las evaluaciones a un momento dado. Esto requiere herramientas automatizadas, alertas en tiempo real y medidas de seguridad proactivas.
  • Responsabilidad compartida: aunque Azure proporciona una plataforma segura, su organización sigue siendo responsable de configurar y mantener correctamente los controles de seguridad, implementar las directivas de acceso adecuadas y garantizar el cumplimiento continuo.
  • Principios bien diseñados: la seguridad, la confiabilidad, la optimización de costos, la excelencia operativa y la eficiencia del rendimiento deben considerarse conjuntamente para crear una solución sostenible y compatible.

Puntos de integración

Los distintos componentes descritos en esta serie funcionan conjuntamente para crear un marco de cumplimiento completo:

  • La seguridad de red proporciona la base para aislar el entorno de datos de los titulares de tarjetas.
  • La protección de datos garantiza que CHD se cifre y administre correctamente a lo largo de su ciclo de vida.
  • La criptografía y la administración de claves permiten el almacenamiento seguro y la transmisión de datos confidenciales.
  • Administración de identidades y acceso con controles MFA mejorados que pueden acceder al CDE.
  • La protección contra malware protege contra amenazas que podrían poner en peligro el entorno.
  • La supervisión y el registro proporcionan visibilidad de todas las actividades del CDE.
  • La supervisión continua de la seguridad permite la detección y respuesta de amenazas en tiempo real.
  • Las directivas de seguridad establecen el marco de gobernanza para el cumplimiento continuo.

Pasos siguientes

Para empezar a implementar el cumplimiento de PCI DSS 4.0.1 en AKS, siga estos pasos recomendados:

Fase 1: Fundación y planificación (Semanas 1-4)

  1. Evaluar el estado actual: evalúe la infraestructura de AKS existente con los requisitos de PCI DSS 4.0.1.
  2. Definir ámbito: identifique claramente qué componentes están en el ámbito de cumplimiento de PCI DSS.
  3. Revise la guía de implementación: estudie las instrucciones detalladas proporcionadas en cada artículo de esta serie.
  4. Planear la arquitectura: diseñe la topología de red en estrella tipo hub-spoke y los controles de seguridad.
  5. Establecer gobernanza: defina roles, responsabilidades y procesos de aprobación.

Fase 2: Implementación de la infraestructura (semanas 5-12)

  1. Implementación de la arquitectura de referencia: comience con la arquitectura de línea base de AKS y aplique mejoras de PCI DSS.
  2. Implementar la seguridad de red: configure clústeres privados, firewalls y directivas de red.
  3. Configuración de la administración de identidades: configure la integración de Azure AD y los requisitos de MFA.
  4. Implementación de la infraestructura de supervisión: configure Azure Monitor, Log Analytics y Microsoft Defender for Cloud.
  5. Implementar la protección de datos: configure el cifrado en reposo y en tránsito.

Fase 3: Seguridad y cumplimiento (semanas 13-20)

  1. Configuración de directivas de seguridad: aplique directivas de Azure Policy y Kubernetes para el cumplimiento.
  2. Implementación de la administración de claves: configure Azure Key Vault y controles criptográficos.
  3. Implementar la protección contra malware: configure el examen de seguridad y la detección de amenazas.
  4. Establecer supervisión: implemente la supervisión continua de la seguridad y las alertas.
  5. Probar controles de seguridad: valide que todas las medidas de seguridad funcionan correctamente.

Fase 4: Validación y mantenimiento (Semanas 21-24)

  1. Realizar pruebas de seguridad: realice pruebas de penetración y evaluaciones de vulnerabilidades.
  2. Validar el cumplimiento: asegúrese de que se cumplen todos los requisitos de PCI DSS 4.0.1.
  3. Documente todo: cree documentación completa con fines de auditoría.
  4. Entrenamiento del personal: asegúrese de que todo el personal comprenda sus roles y responsabilidades.
  5. Establecer procesos en curso: implemente procedimientos de mantenimiento y supervisión continuos.

Operaciones en curso

Después de la implementación inicial, mantenga el cumplimiento mediante:

  • Evaluaciones de seguridad periódicas: realice revisiones trimestrales de seguridad y evaluaciones de cumplimiento anual.
  • Supervisión continua: supervise todos los controles de seguridad y responda a las alertas rápidamente.
  • Administración de actualizaciones: mantenga actualizados todos los sistemas y controles de seguridad.
  • Respuesta a incidentes: mantenimiento y prueba de procedimientos de respuesta a incidentes.
  • Mantenimiento de documentación: mantenga toda la documentación actualizada y accesible.

Obtención de ayuda

Para obtener compatibilidad adicional con la implementación del cumplimiento de PCI DSS 4.0.1 en AKS:

  • Microsoft FastTrack: póngase en contacto con Microsoft FastTrack para Azure para obtener instrucciones de implementación.
  • Asociados de Microsoft: trabaje con asociados certificados de Microsoft que se especializan en el cumplimiento.
  • Servicios profesionales: considere la posibilidad de contratar servicios profesionales para implementaciones complejas.
  • Recursos de la comunidad: aproveche las comunidades de Azure y Kubernetes para conocer los procedimientos recomendados.

Mantenerte al día

Los estándares de PCI DSS evolucionan con el tiempo. Manténgase informado sobre las actualizaciones y los cambios:

  • Suscríbase a las comunicaciones de PCI SSC: siga el Consejo de estándares de seguridad de PCI para obtener actualizaciones.
  • Supervisión de las actualizaciones de Azure: manténgase al día con las nuevas características y funcionalidades de seguridad de Azure.
  • Interactuar con la comunidad: participar en foros de seguridad y cumplimiento.
  • Entrenamiento normal: asegúrese de que el equipo se mantiene al día con los procedimientos recomendados de seguridad.

Esta serie proporciona una guía completa para implementar el cumplimiento de PCI DSS 4.0.1 en AKS. Para información adicional:

Artículos de la serie PCI DSS 4.0.1:

Documentación de Azure:

Recursos de cumplimiento:

Recuerde que lograr y mantener el cumplimiento de PCI DSS 4.0.1 es un proceso continuo que requiere atención continua a la seguridad, la supervisión y la excelencia operativa. Las instrucciones de esta serie proporcionan una base, pero su implementación específica puede requerir consideraciones adicionales basadas en sus requisitos y entornos únicos.

  • Se actualizó por última vez el