Configuración de redes de un clúster regulado de AKS para PCI-DSS 3.2.1 (parte 3 de 9)

En este artículo se describen las consideraciones de red para un clúster de Azure Kubernetes Service (AKS) configurado de acuerdo con 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.

El tema principal del estándar PCI-DSS 3.2.1 es la seguridad. La topología radial es una opción natural para configurar un entorno de red regulado. Es más fácil crear una infraestructura que permita comunicaciones seguras. Los controles de red se colocan en ambas redes de tipo hub-and-spoke y siguen el modelo de confianza cero de Microsoft. Los controles se pueden ajustar con privilegios mínimos para proteger el tráfico, lo que proporciona acceso según lo que se necesite saber. Además, puede aplicar varios enfoques de defensa en profundidad agregando controles en cada salto de red y capa.

Cuando se hospeda una carga de trabajo en Kubernetes, no es suficiente confiar en construcciones de red tradicionales, como las reglas de firewall. También hay construcciones nativas de Kubernetes que controlan el flujo del tráfico en el clúster, como el recurso NetworkPolicy. Se recomienda consultar la documentación de Kubernetes para comprender los conceptos básicos sobre los pods aislados y las directivas de entrada y salida.

Creación y mantenimiento de sistemas y redes seguros

Requisito 1: Instalación y mantenimiento de una configuración de firewall para proteger los datos de titulares de tarjetas

Compatibilidad de características de AKS

AKS admite la implementación de un clúster en una red virtual privada como un clúster privado. La comunicación entre el clúster y el servidor de API de Kubernetes administrado por AKS se realiza mediante una red de confianza. Con un clúster privado, puede usar las redes virtuales de Azure, los grupos de seguridad de red (NSG) y otros controles de red integrados para proteger todo el entorno de datos de titulares de tarjetas (CDE). Esa configuración prohíbe cualquier acceso público no autorizado entre Internet y el entorno. Para más información sobre cómo aprovisionar este tipo de clúster, consulte Creación de un clúster privado de Azure Kubernetes Service.

Azure Firewall se puede integrar con AKS y puede limitar el tráfico saliente desde el clúster, que es un componente clave del CDE. La configuración se facilita con una etiqueta de FQDN de AKS. El proceso recomendado se proporciona en Uso de Azure Firewall para proteger las implementaciones de Azure Kubernetes Service (AKS).

Los clústeres de AKS requieren acceso a Internet público. Limite el tráfico saliente a Internet mediante Azure Firewall y los NSG en la subred del clúster. Para más información, consulte Control del tráfico de salida de los nodos de clúster en Azure Kubernetes Service (AKS).

Opcionalmente, AKS admite la posibilidad de definir un proxy HTTP, que se puede usar a fin de obtener mayor control y supervisión del tráfico de salida para el clúster. Los nodos del clúster usan la configuración de proxy HTTP especificada para enrutar el tráfico saliente. Además, se registra MutatingWebhook para insertar la información del proxy en los pods en el momento de la creación, por lo que se recomienda que las cargas de trabajo puedan heredar la misma información del proxy. Los pods pueden invalidar la información del proxy, por lo que se recomienda usar un proxy HTTP además de una instancia de Azure Firewall.

Los clústeres de AKS deben crearse con el complemento NetworkPolicy. En AKS, tiene varias opciones para el complemento de directiva de red, como Calico, Azure Network Policy Management y Cilium. Con la directiva de red de Calico, puede usar Kubenet o Azure CNI. Para Azure Network Policy Management, solo puede usar Azure CNI (no Kubenet). Tanto los complementos de las directivas de red de Azure como de Calico son de código abierto. Para obtener más información sobre el proyecto Calico, consulte las notas completas de la solución PCI, que abordan muchos de los requisitos de firewall siguientes.

Sus responsabilidades

Requisito	Responsabilidad
Requisito 1.1	Establezca e implemente estándares de configuración de firewalls y enrutadores.
Requisito 1.2	Cree configuraciones de firewall y enrutador que restrinjan las conexiones entre las redes que no sean de confianza y cualquier componente del sistema del entorno de datos de titulares de tarjetas.
Requisito 1.3	Prohíba el acceso público directo entre Internet y cualquier componente del sistema del entorno de datos de titulares de tarjetas.
Requisito 1.4	Instale software de firewall personal o una funcionalidad equivalente en todos los dispositivos informáticos portátiles (incluidos los que pertenecen a la organización y a los empleados) que se conectan a Internet cuando están fuera de la red (por ejemplo, los equipos portátiles que usan los empleados), y que también se usan para acceder al CDE.
Requisito 1.5	Asegúrese de que las directivas de seguridad y los procedimientos operativos para administrar los firewalls estén documentados, en uso y sean conocidos por todas las partes afectadas.

Requisito 1.1

Establezca e implemente estándares de configuración de firewall y enrutador que incluyan lo siguiente:

Requisito 1.1.1

Un proceso formal para aprobar y probar todas las conexiones de red y los cambios en las configuraciones de firewall y enrutador.

Sus responsabilidades

No implemente configuraciones manualmente, por ejemplo, mediante Azure Portal o la CLI de Azure directamente. Se recomienda usar Infraestructura como código (IaC). Con IaC, la infraestructura se administra mediante un modelo descriptivo que usa un sistema de control de versiones. El modelo de IaC genera el mismo entorno cada vez que se aplica. Algunos ejemplos comunes de IaC son plantillas de Bicep, Azure Resource Manager (ARM) o Terraform. Si IaC no es una opción, tenga un proceso bien documentado para realizar un seguimiento e implementar de forma segura los cambios de reglas de firewall. Se proporcionan más detalles como parte del Requisito 11.2.

Deberá usar una combinación de varios controles de red, incluidos Azure Firewall, los grupos de seguridad de red (NSG) y el recurso NetworkPolicy de Kubernetes.

Minimice el número de personas que pueden acceder a los controles de red y modificarlos. Defina roles y responsabilidades claras para los equipos. Por ejemplo, el equipo de red de una organización validará los cambios según las directivas de gobernanza establecidas por los equipos de TI. Tener un proceso de aprobación cerrado que implique a personas y procesos para aprobar los cambios de cualquier configuración de red. El proceso debe incluir un paso para probar todos los controles de red. Disponga de documentación detallada que describa el proceso.

Requisito 1.1.2

Cree un diagrama de red actual que identifique todas las conexiones entre el entorno de datos de titulares de tarjetas y otras redes, incluidas las inalámbricas.

Sus responsabilidades

Como parte de la documentación, mantenga un diagrama de flujo de red que muestre el tráfico entrante y saliente con los controles de seguridad. Esto incluye el flujo de tráfico al CDE desde otras redes, incluida cualquier red inalámbrica. El diagrama también debe mostrar los flujos dentro del clúster. Existen algunos requisitos específicos para los diagramas, incluido que deben mostrar sensores de intrusión y los controles aplicados.

Esta imagen muestra el diagrama de red de la implementación de referencia.

Descargue un archivo de Visio de este diagrama.

Figura 1.1.2: flujo de red

La descripción de este flujo se encuentra en las secciones siguientes.

Puede ver la topología de una red virtual de Azure si tiene Azure Network Watcher. Puede ver todos los recursos de una red virtual, los recursos asociados a los recursos de una red virtual y las relaciones entre los recursos.

Requisito 1.1.3

Cree un diagrama actual que muestre todos los flujos de datos de los titulares de tarjetas entre sistemas y redes.

Sus responsabilidades

Como parte de la documentación, incluya un diagrama de flujo de datos que muestre cómo se protegen los datos en reposo y en tránsito.

El diagrama debe mostrar cómo fluyen los datos hacia y desde la carga de trabajo y qué información se pasa de un recurso a otro. Asegúrese de que el diagrama se mantenga actualizado. Agregue un paso como parte del proceso de administración de cambios para actualizar el diagrama de flujo de datos.

Dado que esta arquitectura se centra en la infraestructura y no en la carga de trabajo, aquí se omiten las ilustraciones.

Requisito 1.1.4

Establezca requisitos de firewall en cada conexión a Internet y entre cualquier red perimetral (DMZ) y la zona de red interna.

Sus responsabilidades

Tener una definición clara de lo que define el límite de una red perimetral. Por ejemplo, el entorno de datos de titulares de tarjetas (CDE) podría estar dentro de una red perimetral protegida por un firewall, directivas de red y otros controles. Para más información, consulte Red definida por software: Red perimetral en la nube.

Para una infraestructura de PCI DSS, usted es responsable de proteger el CDE mediante el uso de controles de red para bloquear el acceso no autorizado dentro y fuera de la red que contiene el CDE. Los controles de red se deben configurar adecuadamente para tener una posición de seguridad correcta y se deben aplicar a:

• Comunicación entre los componentes colocados dentro del clúster.
• Comunicación entre la carga de trabajo y otros componentes de redes de confianza.
• Comunicación entre la carga de trabajo e Internet pública.

Esta arquitectura usa diferentes tecnologías de firewall para inspeccionar el tráfico que fluye en ambas direcciones, hacia y desde el clúster que hospeda el CDE:

• Azure Application Gateway se utiliza como enrutador de tráfico y su firewall de aplicaciones web (WAF) integrado se usa para proteger el tráfico entrante (entrada) al clúster.

• Azure Firewall se usa para proteger todo el tráfico saliente (salida) desde cualquier red y sus subredes.

  Como parte del procesamiento de una transacción u operaciones de administración, el clúster deberá comunicarse con puntos de conexión externos. Por ejemplo, el clúster podría requerir comunicación con el plano de control de AKS, comunicación con el sistema operativo y los sistemas de actualización de paquetes, y muchas cargas de trabajo interactúan con API externas. Algunas de esas interacciones pueden ser mediante HTTP y se deben considerar vectores de ataque. Esos vectores son objetivos de un ataque de tipo "Man in the middle" que puede dar lugar a una filtración de datos. Agregar un firewall al tráfico de salida mitiga esa amenaza.

  Se recomienda que incluso la comunicación de pod a pod esté cifrada con TLS. Esta práctica se muestra en la implementación de referencia con el uso de la autenticación TLS mutua (mTLS).

• Los grupos de seguridad de red se agregan para proteger el tráfico entre el clúster y otros componentes dentro de la infraestructura. Por ejemplo, en la implementación de referencia, hay grupos de seguridad de red en la subred con grupos de nodos que bloquean los intentos de acceso SSH. Solo se permite el tráfico desde dentro de la red virtual.

  A medida que agregue componentes a la arquitectura, considere la posibilidad de agregar más NSG que permitan o denieguen tipos de tráfico en los límites de la subred. Dado que cada grupo de nodos está en una subred dedicada, aplique reglas más específicas en función de los patrones de tráfico esperados de la carga de trabajo.

• Los objetos de Kubernetes NetworkPolicy se usan para controlar las comunicaciones en clúster.

  De manera predeterminada, no hay restricciones en la comunicación de pod a pod. Debe aplicar NetworkPolicy en las comunicaciones dentro del clúster, empezando por una red de confianza cero y abriendo rutas de acceso según sea necesario. La implementación de referencia muestra las redes de confianza cero de los espacios de nombres a0005-i y a0005-o. Se aplican de forma restrictiva directivas de red a todos los espacios de nombres (excepto kube-system, gatekeeper-system y otros espacios de nombres proporcionados por AKS). Las definiciones de directiva dependen de los pods que se ejecuten en esos espacios de nombres. Asegúrese de abrir las rutas de acceso para los sondeos de preparación, disponibilidad e inicio. Además, abra la ruta de acceso a oms-agent para que se puedan enviar métricas de nivel de nodo. Considere la posibilidad de estandarizar los puertos de las cargas de trabajo para que pueda proporcionar un elemento NetworkPolicy coherente y Azure Policy para los puertos de contenedor permitidos.

Requisito 1.1.5

Establezca una descripción de grupos, roles y responsabilidades para la administración de los componentes de red.

Sus responsabilidades

Deberá proporcionar controles sobre los flujos de red y los componentes implicados. La infraestructura resultante tendrá varios segmentos de red, cada uno con muchos controles y cada control con un propósito. Asegúrese de que su documentación tenga una amplia cobertura, desde la planificación de la red hasta todas las configuraciones aplicadas. También debe incluir detalles sobre la propiedad, con líneas claras de responsabilidad y los roles responsables.

Por ejemplo, saber quién es responsable de la gobernanza de la protección de las redes entre Azure e Internet. En una empresa, el equipo de TI suele ser responsable de la configuración y el mantenimiento de las reglas de Azure Firewall, Web Application Firewall (WAF), los NSG y otro tráfico entre redes. También pueden ser responsables de la asignación de subredes y redes virtuales en toda la empresa, así como del planeamiento de direcciones IP.

En el nivel de carga de trabajo, el operador de clúster es responsable de mantener la confianza cero mediante directivas de red. Además, las responsabilidades pueden incluir la comunicación con el plano de control de Azure, las API de Kubernetes y las tecnologías de supervisión.

Comience siempre con una estrategia de denegar todo. Conceda permiso solo cuando haya una necesidad empresarial o una justificación de rol.

Requisito 1.1.6

Documentación de justificación y aprobación comercial del uso de todos los servicios, protocolos y puertos permitidos, también sobre las características de seguridad implementadas para los protocolos que se consideren no seguros.

Sus responsabilidades

Disponga de documentación detallada que describa los servicios, protocolos y puertos usados en los controles de red. Deniegue todos excepto los puertos permitidos explícitamente. Documente la justificación comercial y las características de seguridad documentadas si no se puede evitar el uso de protocolos no seguros. Estos son algunos ejemplos de la implementación de referencia para Azure Firewall. Las reglas de firewall deben tener un ámbito exclusivo para sus recursos relacionados. Es decir, solo el tráfico de orígenes específicos puede ir a destinos FQDN específicos.

Estos son algunos ejemplos en los que podría permitir el tráfico:

Regla	Protocolo:Puerto	Source	Destination	Justificación
Permitir la comunicación segura entre los nodos y el plano de control.	HTTPS:443	Intervalos de direcciones IP autorizados asignados a los grupos de nodos del clúster	Lista de destinos FQDN en el plano de control de AKS. Esto se especifica con la etiqueta de FQDN AzureKubernetesService.	Los nodos necesitan acceso al plano de control para las herramientas de administración, la información de estado y configuración e información sobre qué nodos se pueden escalar.
Permitir una comunicación segura entre Flux y GitHub.	HTTPS:443	Grupos de nodos de AKS	github.com, api.github.com	Flux es una integración de terceros que se ejecuta en los nodos. Sincroniza la configuración del clúster con un repositorio de GitHub privado.

Requisito 1.1.7

Establezca un requisito para revisar los conjuntos de reglas de firewall y enrutador al menos cada seis meses.

Sus responsabilidades

Disponga de procesos al menos cada seis meses para revisar las configuraciones de red y las reglas con ámbito. Esto garantizará que las garantías de seguridad sean actuales y válidas. Asegúrese de revisar estas configuraciones:

• Reglas de Azure Firewall.
• Reglas de grupo de seguridad de red.
• Reglas de Azure Application Gateway y WAF.
• Directivas de red nativas de Kubernetes.
• Controles de firewall en los recursos de Azure aplicables. Por ejemplo, esta arquitectura usa una regla en Azure Container Registry que solo permite el tráfico desde un punto de conexión privado.
• Cualquier otro control de red que haya agregado a la arquitectura.

Si ha retirado las cargas de trabajo o ha cambiado la configuración del clúster desde la revisión anterior, es importante comprobar que las suposiciones realizadas sobre las excepciones de firewall necesarias o las reglas de NSG siguen siendo válidas.

Requisito 1.2

Cree configuraciones de firewall y enrutador que restrinjan las conexiones entre las redes que no sean de confianza y cualquier componente del sistema del entorno de datos de titulares de tarjetas.

Sus responsabilidades

En esta arquitectura, el clúster de AKS es un componente clave del entorno de datos de titulares de tarjetas (CDE). Se recomienda que el clúster se implemente como un clúster privado para mejorar la seguridad. En un clúster privado, el tráfico de red entre el servidor de API de Kubernetes administrado por AKS y los grupos de nodos es privado. El servidor de API se expone mediante un punto de conexión privado en la red del clúster.

También puede elegir un clúster público, pero este diseño no se recomienda para los clústeres que contienen cargas de trabajo reguladas. El servidor de API se expone a Internet. El registro DNS siempre será reconocible. Por lo tanto, debe tener controles para proteger la API del clúster del acceso público. Si se requiere usar un clúster público, el enfoque recomendado es tener controles estrictos mediante los controles de acceso basado en rol (RBAC) de Kubernetes, emparejados con la característica de intervalos IP autorizados de AKS para restringir quién puede acceder al servidor de la API de AKS. Sin embargo, no se recomienda esta solución para los clústeres que contienen cargas de trabajo reguladas.

Al procesar los datos del titular de la tarjeta (CHD), el clúster debe interactuar con redes que se consideran de confianza y de no confianza. En esta arquitectura, se considera que ambas redes en estrella tipo hub-and-spoke dentro del perímetro de la carga de trabajo PCI-DSS 3.2.1 son redes de confianza.

Las redes que no son de confianza son redes fuera de ese perímetro. Las redes que no son de confianza incluyen:

• Los demás concentradores y radios que podrían estar en la misma infraestructura, pero están fuera del perímetro de la carga de trabajo.
• Red pública de Internet.
• La red corporativa.
• Otras redes virtuales en Azure u otra plataforma en la nube.

En esta arquitectura, la red virtual que hospeda el generador de imágenes no es de confianza porque no tiene ningún papel en el control de CHD. La interacción del CDE con dichas redes se debe proteger según los requisitos. Con este clúster privado, puede usar redes virtuales, NSG y otras características integradas para proteger todo el entorno.

Para obtener información sobre los clústeres privados, consulte Creación de un clúster privado de Azure Kubernetes Service.

Requisito 1.2.1

Restrinja el tráfico de entrada y de salida al necesario para el entorno de datos de titulares de tarjetas y deniegue todo el tráfico restante de forma específica.

Sus responsabilidades

Por diseño, no se puede acceder directamente a redes virtuales de Azure desde la red pública de Internet. Todo el tráfico entrante (o de entrada) debe pasar por un enrutador de tráfico intermedio. Sin embargo, de forma predeterminada, todos los componentes de la red pueden acceder a los puntos de conexión públicos. Puede deshabilitar ese comportamiento configurando una subred privada o usando una UDR para enviar todo el tráfico saliente a través de un firewall. Ese tráfico saliente (o de salida) se debe proteger explícitamente para permitir únicamente cifrados seguros y TLS 1.2 o posterior.

• El WAF integrado de Azure Application Gateway intercepta todo el tráfico de entrada HTTP(S) y enruta el tráfico inspeccionado al clúster.

  Este tráfico puede originarse en redes de confianza o que no son de confianza. Application Gateway se aprovisiona en una subred de la red de los radios y se protege mediante un NSG. A medida que fluye el tráfico, las reglas de WAF permiten o deniegan, y Application Gateway enruta el tráfico al back-end configurado. Por ejemplo, Application Gateway protege el CDE al denegar este tipo de tráfico:

  • Todo el tráfico que no está cifrado con TLS.
  • El tráfico fuera del intervalo de puertos para la comunicación del plano de control desde la infraestructura de Azure.
  • Las solicitudes de sondeo de estado enviadas por entidades que no sean el equilibrador de carga interno del clúster.

• Azure Firewall se usa para proteger todo el tráfico saliente (salida) desde redes de confianza y que no son de confianza.

  Azure Firewall se aprovisiona en una subred de la red del concentrador. Para aplicar Azure Firewall como punto de salida único, se usan rutas definidas por el usuario (UDR) en las subredes que son capaces de generar tráfico de salida. Esto incluye las subredes de redes que no son de confianza, como la red virtual del generador de imágenes. Una vez que el tráfico llega a Azure Firewall, se aplican varias reglas con ámbito que permiten que el tráfico procedente de orígenes específicos vaya a destinos específicos.

  Para más información, consulte Uso de Azure Firewall para proteger las implementaciones de Azure Kubernetes Service (AKS).

• Opcionalmente, es posible usar un proxy HTTP para supervisar y proteger el tráfico saliente (de salida), desde el clúster a recursos externos.

  Además de un firewall, es posible que algunas organizaciones usen un proxy HTTP para tener un mayor número de controles sobre la salida. Se recomienda que las rutas definidas por el usuario vayan al firewall y limitar el tráfico de salida para que vaya solo al proxy HTTP. Con esta configuración, si un pod intenta invalidar el proxy, el firewall puede bloquear el tráfico de salida.

  Para más información, consulte Compatibilidad con proxy HTTP en Azure Kubernetes Service.

Es posible que el clúster requiera acceso a otros servicios mediante la red pública de Internet. Por ejemplo, si usa un software antimalware de terceros, este deberá obtener las definiciones de virus de un servidor mediante la red pública de Internet.

Las interacciones con los puntos de conexión de otros servicios de Azure se realizan mediante la red troncal de Azure. Por ejemplo, como parte de las operaciones normales, el clúster deberá obtener certificados del almacén de claves administradas, extraer imágenes de un registro de contenedor, etc. Asegúrese de que esas interacciones sean privadas y seguras mediante Azure Private Link.

Además de las reglas de firewall y las redes privadas, los flujos de tráfico también se protegen mediante reglas de NSG. Aquí se muestran algunos ejemplos de esta arquitectura, en la que el CDE está protegido mediante la denegación del tráfico:

• Los NSG en subredes que tienen grupos de nodos deniegan cualquier acceso SSH a los nodos. Asegúrese de que dispone la puesta en marcha de un proceso para el acceso de emergencia Just-In-Time mientras se mantiene el principio de denegar todo.
• Un NSG en la subred que tiene el jumpbox para ejecutar las herramientas de administración deniega todo el tráfico excepto el procedente de Azure Bastion en la red del concentrador.
• Los NSG en las subredes que tienen los puntos de conexión privados para Azure Key Vault y Azure Container Registry deniegan todo el tráfico excepto el procedente del equilibrador de carga interno y el tráfico mediante Azure Private Link.

Requisito 1.2.2

Proteja y sincronice los archivos de configuración del enrutador.

Sus responsabilidades

Disponga de un mecanismo para detectar la diferencia entre el estado implementado real y el estado deseado. La infraestructura como código (IaC) es una excelente opción para ese propósito. Por ejemplo, los archivos de Bicep o las plantillas de Azure Resource Manager (plantillas de ARM) mantienen un registro del estado deseado.

Los recursos de implementación, como archivos de Bicep, deben estar controlados por el control de código fuente para que tenga el historial de todos los cambios. Recopile información de los registros de actividad de Azure, los registros de la canalización de implementación y los registros de implementación de Azure. Estos orígenes le ayudarán a mantener un registro de los recursos implementados.

En el clúster, los controles de red como las directivas de red de Kubernetes también deben seguir el flujo de control de código fuente. En esta implementación, se usa Flux como operador de GitOps. Al sincronizar una configuración de clúster, como las directivas de red, el historial de Git combinado con y los registros de Flux y la API puede ser un origen del historial de configuración.

Requisito 1.2.3

Instale firewalls perimetrales entre todas las redes inalámbricas y el entorno de datos de titulares de tarjetas, y configure estos firewalls para denegar o, si el tráfico es necesario con fines comerciales, permitir solo el tráfico autorizado entre el entorno inalámbrico y el entorno de datos de titulares de tarjetas.

Sus responsabilidades

Los nodos de AKS y los grupos de nodos no deben ser accesibles desde redes inalámbricas. Además, se deben denegar las solicitudes al servidor de API de Kubernetes. El acceso a esos componentes está restringido a subredes autorizadas y protegidas.

En general, limite el acceso desde el tráfico local a la red de los radios.

Requisito 1.3

Prohíba el acceso público directo entre Internet y cualquier componente del sistema del entorno de datos de titulares de tarjetas.

Sus responsabilidades

Los grupos de nodos del clúster de AKS funcionan dentro de la red virtual y están aislados de redes públicas como Internet. Mantenga el aislamiento evitando la asociación de direcciones IP públicas a los nodos del clúster y aplicando reglas de NSG en las subredes del clúster para asegurarse de que el tráfico de Internet esté bloqueado. Para obtener información sobre el acceso controlado, consulte la sección sobre redes perimetrales.

El clúster de AKS tiene grupos de nodos del sistema que hospedan pods del sistema críticos. Incluso en los grupos de nodos de usuario, hay pods que ejecutan otros servicios que participan en las operaciones del clúster. Por ejemplo, los pods pueden ejecutar Flux para sincronizar la configuración del clúster con un repositorio GitHub, o el controlador de entrada para enrutar el tráfico a los pods de la carga de trabajo. Independientemente del tipo de grupo de nodos, todos los nodos deben estar protegidos.

Otro componente crítico del sistema es el servidor de API que se usa para realizar tareas nativas de Kubernetes, como mantener el estado y la configuración del clúster. Una ventaja de usar un clúster privado es que el punto de conexión del servidor de API no se expone de manera predeterminada. Para obtener información sobre los clústeres privados, consulte Creación de un clúster privado de Azure Kubernetes Service.

También se deben proteger las interacciones con otros puntos de conexión. Una manera es restringir las comunicaciones mediante una red privada. Por ejemplo, haga que el clúster extraiga las imágenes de Azure Container Registry mediante un vínculo privado.

Requisito 1.3.1

Implemente una red perimetral para limitar el tráfico de entrada solo a los componentes del sistema que proporcionen servicios protocolos y puertos de acceso público autorizados.

Sus responsabilidades

Estos son algunos procedimientos recomendados:

• No configure direcciones IP públicas en los nodos del grupo de nodos.
• Use Azure Policy para asegurarse de que Kubernetes no expone un equilibrador de carga público. El tráfico dentro del clúster se debe enrutar mediante equilibradores de carga internos.
• Exponga solo los equilibradores de carga internos a Azure Application Gateway integrado con WAF.
• Todos los controles de red deben especificar restricciones de origen, destino, puerto y protocolo, si procede.
• No exponga el servidor de API a Internet. Al ejecutar el clúster en modo privado, no se expone el punto de conexión y la comunicación entre los grupos de nodos y el servidor de API se realiza mediante una red privada.

Los usuarios pueden implementar una red perimetral para proteger los clústeres de AKS. Para más información, consulte Red definida por software: Red perimetral en la nube.

Requisito 1.3.2

Limite el tráfico de entrada de Internet a las direcciones IP dentro de la red perimetral.

Sus responsabilidades

En la red del clúster, disponga un NSG en la subred con el equilibrador de carga interno. Configure reglas para que solo se acepte el tráfico procedente de la subred que tiene Azure Application Gateway integrado con WAF. En el clúster de AKS, use NetworkPolicies de Kubernetes para restringir el tráfico de entrada a los pods.

Requisito 1.3.3

Implemente medidas contra la suplantación de identidad para detectar direcciones IP de origen falsificadas y bloquear su entrada a la red.

Responsabilidades de Azure

Azure implementa filtrado de red para impedir tráfico falsificado y restringe el tráfico entrante y saliente a los componentes de plataforma segura.

Requisito 1.3.4

No permita el tráfico de salida no autorizado desde el entorno de datos de titulares de tarjetas a Internet.

Sus responsabilidades

Estas son algunas formas para bloquear el tráfico de salida no autorizado:

• Exija que todo el tráfico de salida del clúster de AKS recorra Azure Firewall mediante rutas definidas por el usuario (UDR) en todas las subredes del clúster. Esto incluye las subredes con grupos de nodos de usuario y del sistema.
• Limite el tráfico saliente mediante la adición de grupos de seguridad de red en las subredes con grupos de nodos.
• Use NetworkPolicies de Kubernetes para restringir el tráfico de salida de los pods.
• Use una malla de servicio para controlar directivas adicionales. Por ejemplo, si solo permite el tráfico cifrado con TLS entre los pods, el servidor proxy de la malla de servicio puede controlar la comprobación de TLS. Ese ejemplo se muestra en esta implementación. Se implementa Envoy como servidor proxy.
• Evite la adición de direcciones IP públicas a las redes dentro del CDE salvo las subredes explícitamente autorizadas, como las subredes del firewall.
• Use un proxy HTTP, además de Azure Firewall, para limitar el tráfico saliente (de salida) desde el clúster de AKS a Internet.
• Use el Servicio Private Link de Azure Monitor (AMPLS) para que los registros de Container Insights se envíen mediante una conexión privada segura a Azure Monitor. Entienda el impacto de habilitar AMPLS.

Para más información, consulte Control del tráfico de salida de los nodos de clúster en Azure Kubernetes Service (AKS).

Requisito 1.3.5

Permita solo conexiones "establecidas" a la red.

Responsabilidades de Azure

Azure implementa filtrado de red para impedir tráfico falsificado y restringe el tráfico entrante y saliente a los componentes de plataforma segura. La red de Azure está segregada para separar el tráfico de clientes del tráfico de administración.

Requisito 1.3.6

Coloque los componentes del sistema en los que se almacenan datos de titulares de tarjetas (por ejemplo, una base de datos) en una zona de la red interna, segregada de la red perimetral y otras redes que no sean de confianza.

Sus responsabilidades

Exponga los sistemas de almacenamiento solo mediante una red privada, por ejemplo, mediante Private Link. Además, restrinja el acceso desde las subredes del grupo de nodos que lo requieran. Mantenga el estado fuera del clúster y en su propia zona de seguridad dedicada.

Requisito 1.3.7

No divulgue direcciones IP privadas ni la información de enrutamiento a partes no autorizadas.

Sus responsabilidades

Para cumplir este requisito, no es opción elegir un clúster de AKS público. Un clúster privado mantiene los registros DNS fuera de la red pública de Internet mediante una zona DNS privada. Sin embargo, aún es posible crear un clúster de AKS privado con una dirección de DNS público. Por lo tanto, se recomienda deshabilitar explícitamente esta característica al establecer enablePrivateClusterPublicFQDN en false para evitar la divulgación de la dirección IP privada del plano de control. Considere la posibilidad de usar Azure Policy para aplicar el uso de clústeres privados sin registros DNS públicos.

Además, use una zona DNS privada para el enrutamiento entre la subred que tiene Azure Application Gateway integrado con WAF y la subred que tiene el equilibrador de carga interno. Asegúrese de que ninguna respuesta HTTP incluya información de dirección IP privada en los encabezados o el cuerpo. Asegúrese de que los registros que puedan contener direcciones IP y registros DNS no se expongan fuera de las necesidades operativas.

Un servicio de Azure conectado mediante Private Link no tiene un registro DNS público que exponga las direcciones IP privadas. La infraestructura debe hacer un uso óptimo de Private Link.

Requisito 1.4

Instale software de firewall personal o una funcionalidad equivalente en todos los dispositivos informáticos portátiles que se conectan a Internet cuando están fuera de la red y que también se usan para tener acceso al CDE.

Sus responsabilidades

El plano de control de AKS administra el clúster privado. No tiene acceso directo a los nodos. Para realizar tareas administrativas, deberá usar herramientas de administración como kubectl desde un recurso de proceso independiente. Una opción es usar un jumpbox aislado donde puede ejecutar los comandos. Además, el tráfico entrante y saliente desde el jumpbox se debe proteger y restringir. Si se usa VPN para el acceso, asegúrese de que la directiva corporativa administre la máquina cliente y que todas las directivas de acceso condicional estén en vigor.

En esta arquitectura, ese jumpbox está en una subred independiente de la red de los radios. El acceso entrante al jumpbox está restringido mediante un NSG que solo permite el acceso mediante Azure Bastion sobre SSH.

Para ejecutar determinados comandos en el jumpbox, deberá acceder a puntos de conexión públicos. Por ejemplo, los puntos de conexión administrados por el plano de administración de Azure. Ese tráfico de salida se debe proteger. De forma similar a otros componentes de la red de los radios, el tráfico saliente desde el jumpbox está restringido mediante una UDR que obliga al tráfico HTTPs a pasar por Azure Firewall.

Requisito 1.5

Asegúrese de que las directivas de seguridad y los procedimientos operativos para administrar los firewalls estén documentados, en uso y sean conocidos por todas las partes afectadas.

Sus responsabilidades

Es fundamental mantener una documentación exhaustiva sobre el proceso y las directivas. Esto es especialmente cierto cuando se administran reglas de Azure Firewall que segmentan el clúster de AKS. 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 con cuentas que tienen concedidos amplios privilegios administrativos.

Requisito 2: No usar valores predeterminados proporcionados por el proveedor para contraseñas del sistema y otros parámetros de seguridad

Sus responsabilidades

Requisito	Responsabilidad
Requisito 2.1	Cambie siempre los valores predeterminados proporcionados por el proveedor y elimine o deshabilite las cuentas predeterminadas innecesarias antes de instalar un sistema en la red.
Requisito 2.2	Desarrolle estándares de configuración para todos los componentes del sistema. Asegúrese de que estos estándares abordan todas las vulnerabilidades de seguridad conocidas y son coherentes con los estándares de protección de sistemas aceptados en el sector.
Requisito 2.3	Cifre todo el acceso administrativo que no sea de la consola con criptografía segura.
Requisito 2.4	Mantenga un inventario de los componentes del sistema que pertenecen al ámbito de PCI DSS.
Requisito 2.5	Asegúrese de que las directivas de seguridad y los procedimientos operativos para administrar los valores predeterminados del proveedor y otros parámetros de seguridad estén documentados, en uso y que todas las partes afectadas los conocen.
Requisito 2.6	Los proveedores de hospedaje compartido deben proteger los datos de titulares de tarjetas y del entorno hospedado de cada entidad.

No usar valores predeterminados proporcionados por el proveedor para contraseñas de sistemas y otros parámetros de seguridad

Requisito 2.1

Cambie siempre los valores predeterminados proporcionados por el proveedor y elimine o deshabilite las cuentas predeterminadas innecesarias antes de instalar un sistema en la red.

Sus responsabilidades

Se deben cambiar los valores predeterminados proporcionados por los proveedores. Los valores predeterminados son vectores de ataque comunes y hacen que el sistema sea propenso a ataques. A continuación, se indican algunas consideraciones:

• Deshabilite el acceso de administrador en el registro de contenedor.
• Asegúrese de que los jumpboxes y los agentes de compilación sigan los procedimientos de administración de usuarios y elimine los usuarios del sistema innecesarios.
• No genere ni proporcione acceso de clave SSH a los nodos a los usuarios administradores. Si se necesita acceso de emergencia, use el proceso de recuperación de Azure para obtener acceso Just-In-Time.

Responsabilidades de Azure

Microsoft Entra ID tiene directivas de contraseña que se aplican a las nuevas contraseñas proporcionadas por los usuarios. Si cambia una contraseña, se requiere la validación de la contraseña anterior. Una contraseña que ha restablecido un administrador debe cambiarse cuando el usuario inicie sesión a continuación.

Requisito 2.1.1

En el caso de los entornos inalámbricos conectados al entorno de datos de titulares de tarjetas o que transmiten este tipo de datos, cambie TODOS los valores predeterminados del proveedor inalámbrico durante la instalación, incluidas, entre otras, las claves de cifrado inalámbrico predeterminadas, las contraseñas y las cadenas de comunidad SNMP.

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 2.2

Desarrolle estándares de configuración para todos los componentes del sistema.

Sus responsabilidades

Implemente las recomendaciones del punto de referencia de seguridad en la nube de Microsoft. Proporciona una vista única y consolidada de las recomendaciones de seguridad de Azure, que abarca marcos del sector como CIS, NIST, PCI-DSS 3.2.1 y otros. Use las características de Microsoft Defender for Cloud y Azure Policy para ayudar a realizar un seguimiento de los estándares. Azure Security Benchmark es la iniciativa predeterminada para Microsoft Defender for Cloud. Considere la posibilidad de crear comprobaciones automatizadas adicionales en Azure Policy y la solución de seguridad del inquilino de Azure (AzTS).

Documente el estado de configuración deseado de todos los componentes del CDE, especialmente los nodos de AKS, el jumpbox, los agentes de compilación y otros componentes que interactúan con el clúster.

Para obtener más información, consulte Microsoft Cloud Security Benchmark.

Responsabilidad de Azure

Azure proporciona estándares de configuraciones de seguridad que son coherentes con los estándares de protección aceptados por el sector. Los estándares se revisan al menos anualmente.

Requisito 2.2.1

Implemente solo una función principal por servidor para evitar que funciones que requieran diferentes niveles de seguridad coexistan en el mismo servidor. (Por ejemplo, los servidores web, los servidores de base de datos y DNS deben implementarse en servidores diferentes).

Sus responsabilidades

La estrategia principal es proporcionar el nivel de segmentación necesario. Una manera es implementar componentes de dentro y fuera del ámbito en distintos clústeres. Tenga en cuenta que esto da como resultado un aumento de los costos de la infraestructura agregada y una sobrecarga de mantenimiento. Otro enfoque es colocar todos los componentes en un clúster compartido. Use estrategias de segmentación para mantener la separación. Por ejemplo, tener grupos de nodos independientes dentro de un clúster.

En la implementación de referencia, se demuestra el segundo enfoque con una aplicación de microservicios implementada en un único clúster. La aplicación tiene dos conjuntos de servicios: un conjunto tiene pods de dentro del ámbito y el otro está fuera del ámbito. Ambos conjuntos se reparten entre dos grupos de nodos de usuario. Con el uso de marcas de Kubernetes, los pods de dentro y fuera del ámbito se implementan en grupos de nodos distintos y nunca comparten una máquina virtual de nodo.

En el caso de las tecnologías de contenedor, esa segmentación se proporciona de manera predeterminada porque solo una instancia de un contenedor es responsable de una función del sistema.

Cada pod de carga de trabajo debe usar su propia identidad. No debe heredar ninguna identidad de nivel de clúster o de nivel de nodo.

Use almacenamiento externo en lugar del almacenamiento del nodo (en el clúster) siempre que sea posible. Mantenga los pods del clúster reservados exclusivamente para el trabajo que se debe realizar como parte del funcionamiento del procesamiento de datos de titulares de tarjetas. Traslade las operaciones fuera del ámbito fuera del clúster. Esta guía se aplica a agentes de compilación, cargas de trabajo no relacionadas o actividades como tener un jumpbox dentro del clúster.

Requisito 2.2.2

Habilite solo los servicios, protocolos, demonios, etc. necesarios según se requiera para la función del sistema.

Sus responsabilidades

Revise las características y las implicaciones antes de habilitarlas. La configuración predeterminada puede incluir características que no necesita y esas características pueden necesitar visibilidad sobre la carga de trabajo. Un ejemplo de esto son los cifrados de la directiva de SSL predeterminada para Azure Application Gateway. Compruebe si la directiva es muy permisiva. La recomendación es crear una directiva personalizada seleccionando solo los cifrados que necesite.

En el caso de los componentes sobre los que tiene el control total, elimine todos los servicios del sistema innecesarios de las imágenes. Por ejemplo, revise las imágenes de los jumpboxes y los agentes de compilación y quite los componentes que no sean necesarios.

Para los componentes en los que solo tenga visibilidad, como los nodos de AKS, documente lo que instala Azure en los nodos. Considere la posibilidad de usar DaemonSets para proporcionar cualquier auditoría adicional necesaria para estos componentes controlados por la nube.

Requisito 2.2.3

Implemente funciones de seguridad adicionales para los servicios, protocolos o demonios necesarios que se consideren inseguros.

Sus responsabilidades

Application Gateway tiene un WAF integrado y negocia el protocolo de enlace TLS para la solicitud enviada a su punto de conexión público, lo que permite solo cifrados seguros. La implementación de referencia solo admite TLS 1.2 y cifrados aprobados.

Supongamos que tiene un dispositivo heredado que tiene que interactuar con el CDE mediante Azure Application Gateway. Para cumplir este requisito, Application Gateway debe habilitar un protocolo no seguro. Documente esa excepción y supervise si ese protocolo se usa más allá de ese dispositivo heredado. Deshabilite ese protocolo inmediatamente después de que se interrumpa esa interacción heredada.

Application Gateway no debe responder a las solicitudes en el puerto 80. No realice redirecciones en el nivel de aplicación. Esta implementación de referencia tiene una regla de NSG activa que bloquea el tráfico del puerto 80. La regla está en la subred con Application Gateway.

Si una carga de trabajo del clúster no puede cumplir la directiva de la organización en torno a los perfiles de cumplimiento de seguridad u otros controles (por ejemplo, límites y cuotas), asegúrese de que la excepción esté documentada. Debe supervisar para asegurarse de que solo se realice la funcionalidad esperada.

Requisito 2.2.4

Configure los parámetros de seguridad del sistema para evitar un uso incorrecto.

Sus responsabilidades

Todos los servicios de Azure usados en la arquitectura deben seguir las recomendaciones proporcionadas por el punto de referencia de seguridad en la nube de Azure. Estas recomendaciones le dan un punto de partida para seleccionar opciones de configuración de seguridad específicas. Además, compare la configuración con la implementación de línea base para ese servicio. Para más información sobre las líneas base de seguridad, consulte Líneas base de seguridad para Azure.

El controlador de admisión de Open Policy Agent funciona junto con Azure Policy para detectar y evitar errores de configuración en el clúster. Supongamos que hay una directiva de la organización que no permite asignaciones de direcciones IP públicas en los nodos. Cuando se detecta dicha asignación, se marca para auditoría o se deniega en función de la acción especificada en la definición de directiva.

En el nivel de infraestructura, puede aplicar restricciones en el tipo y la configuración de los recursos de Azure. Use Azure Policy para evitar configuraciones incorrectas. En esta implementación de referencia, hay una directiva que deniega la creación de clústeres de AKS que no sean privados.

Asegúrese de que todas las excepciones se documentan y revisan de forma periódica.

Responsabilidades de Azure

Azure garantiza que solo el personal autorizado puede configurar los controles de seguridad de la plataforma Azure mediante controles de acceso multifactor y una necesidad empresarial documentada.

Requisito 2.2.5

Quite todas las funcionalidades innecesarias, como scripts, controladores, características, subsistemas, sistemas de archivos y servidores web innecesarios.

Sus responsabilidades

No instale software en los jumpboxes y agentes de compilación que no participen en el procesamiento de una transacción ni proporcionen observabilidad para los requisitos de cumplimiento, como los agentes de seguridad. Esta recomendación también se aplica a las entidades del clúster, como los DaemonSet y los pods. Asegúrese de que se detecten y registren todas las instalaciones.

Requisito 2.3

Cifre todo el acceso administrativo que no sea de la consola con criptografía segura.

Sus responsabilidades

Todo el acceso administrativo al clúster se debe realizar mediante la consola. No exponga el plano de control del clúster.

Responsabilidades de Azure

Azure garantiza que se exija el uso de criptografía segura al acceder a la infraestructura del hipervisor. Esto garantiza que los clientes que usan Azure Portal puedan tener acceso a sus consolas de servicio y host con criptografía segura.

Requisito 2.4

Mantenga un inventario de los componentes del sistema que pertenecen al ámbito de PCI DSS.

Sus responsabilidades

Todos los recursos de Azure usados en la arquitectura se deben etiquetar correctamente. Las etiquetas ayudan en la clasificación de datos e indican si el servicio está dentro o fuera del ámbito. Un etiquetado meticuloso le permitirá consultar los recursos, mantener un inventario, ayudar a realizar un seguimiento de los costos y establecer alertas. Mantenga también una instantánea de esa documentación periódicamente.

Evite etiquetar los recursos como dentro o fuera del ámbito en un nivel detallado. A medida que la solución evoluciona, los recursos de fuera del ámbito se pueden convertir en recursos de dentro del ámbito incluso si interactúan indirectamente o son adyacentes a los datos de titulares de tarjetas. Estos recursos están sujetos a auditoría y podrían formar parte de una muestra representativa durante la auditoría. Considere la posibilidad de etiquetar en un nivel superior, en el nivel de suscripción y de clúster.

Para más información sobre las consideraciones de etiquetado, consulte Guía de decisiones de nomenclatura y etiquetado de recursos.

Etiquete los objetos del clúster aplicando etiquetas de Kubernetes. De este modo, puede organizar objetos, seleccionar una colección de objetos e informar del inventario.

Requisito 2.5

Asegúrese de que las directivas de seguridad y los procedimientos operativos para administrar los valores predeterminados del proveedor y otros parámetros de seguridad estén documentados, en uso y que todas las partes afectadas los conocen.

Sus responsabilidades

Es fundamental mantener una documentación exhaustiva sobre los procesos y las directivas. El personal debe estar formado en las características de seguridad y los valores de configuración de cada recurso de Azure. Las personas que operan en entornos regulados deben estar formadas e informadas y se les debe incentivar para respaldar las garantías de seguridad. Estos pasos son especialmente importante para las personas con cuentas que tienen concedidos amplios privilegios administrativos.

Requisito 2.6

Los proveedores de hospedaje compartido deben proteger los datos de titulares de tarjetas y del entorno hospedado de cada entidad.

Sus responsabilidades

Azure proporciona garantías de seguridad para cualesquiera componentes del entorno hospedado que se comparten. Se recomienda encarecidamente tratar los nodos de AKS como un host dedicado para esta carga de trabajo. Es decir, todo el proceso debe estar en un único modelo de suscriptor y no compartirse con otras cargas de trabajo que pueda operar.

Si se desea un aislamiento de proceso completo en el nivel de infraestructura de Azure, puede agregar Azure Dedicated Host a un clúster de Azure Kubernetes Service (AKS). Esta oferta proporciona servidores físicos dedicados a la carga de trabajo, lo que le permite colocar nodos de AKS directamente en estos hosts aprovisionados. Esta elección de arquitectura tiene implicaciones de costes importantes y requiere una planificación cuidadosa de la capacidad. No es habitual para la mayoría de los escenarios.

Pasos siguientes

Proteja los datos de titulares de tarjetas almacenados. Cifre la transmisión de datos de titulares de tarjetas en redes abiertas y públicas.

Recursos relacionados

• Diseño de la arquitectura de Azure Kubernetes Service (AKS)
• Introducción de un clúster regulado de AKS para PCI-DSS 3.2.1 (parte 1 de 9)
• Arquitectura de un clúster regulado de AKS para PCI-DSS 3.2.1 (parte 2 de 9)
• Arquitectura de línea de base en un clúster de Azure Kubernetes Service (AKS)
• Línea base de AKS para clústeres de varias regiones