Evaluación de riesgos y recursos de código para un clúster regulado de AKS para PCI DSS 4.0.1

En este artículo se describen las consideraciones sobre la evaluación de riesgos y los recursos de código para un clúster de Azure Kubernetes Service (AKS) que ejecuta una carga de trabajo conforme al estándar de seguridad de datos del sector de tarjetas de pago (PCI DSS 4.0.1).

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

Las recomendaciones y los ejemplos se han extraído de esta implementación de referencia complementaria:

Descargue un archivo de Visio de esta arquitectura.

Descargue un archivo de Visio de esta arquitectura.

Componentes

En esta sección, resaltaremos las diferencias entre las dos arquitecturas y las actualizaciones necesarias para PCI DSS 4.0.1, incluida la segmentación mejorada, la supervisión continua y las prácticas de desarrollo de software seguras. Si no está familiarizado con los componentes de líneas base, consulte los servicios de Azure relacionados para obtener vínculos a la documentación del producto.

Configuración del clúster

En las secciones siguientes se resaltan los cambios significativos de la arquitectura de línea base.

Segmentación del grupo de nodos

En esta arquitectura, el clúster tiene dos grupos de nodos de usuario y un grupo de nodos de sistema. La elección de proceso para los grupos de nodos sigue siendo la misma que en la arquitectura de línea base. A diferencia de la arquitectura de línea base, cada grupo de nodos reside en una subred dedicada para proporcionar un límite de aislamiento de red adicional entre los niveles de proceso.

PCI DSS 4.0.1 requiere el aislamiento de la carga de trabajo PCI de otras cargas de trabajo en términos de operaciones y conectividad.

• Dentro del ámbito: la carga de trabajo de PCI, el entorno en el que reside y las operaciones.
• Fuera del ámbito: otras cargas de trabajo que pueden compartir servicios, pero están aisladas de los componentes de dentro del ámbito.

La principal estrategia es proporcionar el nivel de separación adecuado. El método preferido es implementar componentes de dentro y fuera del ámbito en distintos clústeres. La desventaja de usar varios clústeres son los costes más altos de la infraestructura adicional y la sobrecarga de mantenimiento. Esta implementación ubica conjuntamente todos los componentes en un clúster compartido por razones de simplicidad. Si decide seguir el modelo de clúster único, use una rigurosa estrategia de segmentación dentro del clúster. Con independencia de cómo decida mantener la separación, tenga en cuenta que, a medida que evoluciona la solución, es posible que algunos componentes de fuera del ámbito pasen a estar dentro del ámbito.

En la implementación de referencia, se demuestra el enfoque de clúster compartido implementando una aplicación de microservicios en un único clúster. Las cargas de trabajo de dentro y fuera del ámbito se segmentan en dos grupos de nodos de usuario distintos. La aplicación tiene dos conjuntos de servicios: un conjunto tiene pods dentro del alcance y el otro está fuera del alcance. Ambos conjuntos se reparten entre dos grupos de nodos de usuario. Con el uso de contaminaciones de Kubernetes, los pods de dentro y fuera del ámbito se implementan en nodos distintos y nunca comparten una máquina virtual de nodo o el espacio IP de red.

Controlador de entrada

La arquitectura de línea base usó Traefik para el control de entrada. En esta arquitectura de referencia, en su lugar usamos Nginx. Este cambio muestra que este componente se puede cambiar en función de los requisitos de la carga de trabajo.

Servidor privado de la API de Kubernetes

En la arquitectura de línea de base se implementaba el clúster de AKS en modo público. Esto significa que toda la comunicación con el servidor de API de Kubernetes administrado por AKS se realiza a través de la red pública de Internet. Esto no es aceptable en esta arquitectura porque PCI DSS 4.0.1 prohíbe la exposición pública a los componentes del sistema. En esta arquitectura regulada, el clúster se implementa como un clúster privado. El tráfico de red al servidor de API de Kubernetes se limita a la red privada. El servidor de API se expone a través de un punto de conexión privado en la red del clúster. La seguridad se mejora aún más con el uso de grupos de seguridad de red y otras características integradas. Estas se describen en Configuración de red.

Seguridad de pod

Al describir las necesidades de seguridad de la carga de trabajo, use la configuración de securityContext pertinente para los contenedores. Aquí se incluye la configuración básica, como fsGroup, runAsUser / runAsGroup y la configuración de allowPrivilegeEscalation como false (a menos que se requiera). Tenga claro cómo definir y quitar funcionalidades de Linux y definir las opciones de SELinux en seLinuxOptions.

Evite hacer referencia a imágenes por sus etiquetas en los manifiestos de implementación. En su lugar, use el identificador de imagen real. De este modo, puede asignar de forma confiable los resultados del examen del contenedor con el contenido real que se ejecuta en el clúster. Puede exigir en Azure Policy que el nombre de imagen incluya el patrón del identificador de imagen en la expresión regular permitida. Siga también esta guía cuando use la instrucción FROM de Dockerfile.

Configuración de red

Las redes de centro y radio se implementan en redes virtuales independientes, cada una en su espacio de direcciones privado. De forma predeterminada, no se permite el tráfico entre dos redes virtuales cualesquiera. Dentro de la red, la segmentación se aplica mediante la creación de subredes.

Una combinación de varios servicios y características de Azure y construcciones nativas de Kubernetes proporcionan el nivel de control necesario. Estas son algunas opciones que se usan en esta arquitectura:

Seguridad de subred mediante grupos de seguridad de red (NSG)

Hay varios grupos de seguridad de red que controlan el flujo dentro y fuera del clúster. Estos son algunos ejemplos:

• Los grupos de nodos del clúster se colocan en subredes dedicadas. En cada subred, hay grupos de seguridad de red que bloquean cualquier acceso mediante SSH a las máquinas virtuales de nodo y permiten el tráfico desde la red virtual. El tráfico desde los grupos de nodos está restringido a la red virtual.
• Todo el tráfico que procede de Internet se intercepta en Azure Application Gateway. Por ejemplo, las reglas de NSG aseguran que:
  • Solo se permite la entrada de tráfico HTTPS.
  • El tráfico desde el plano de control de Azure se permite mediante etiquetas de servicio. Para más información, consulte Permiso de acceso a unas cuentas IP de origen.
• En las subredes que tienen agentes de Azure Container Registry, los grupos de seguridad de red solo permiten el tráfico saliente necesario. Por ejemplo, se permite el tráfico a Azure Key Vault, Microsoft Entra ID, Azure Monitor y otros servicios con los que el registro de contenedor necesite comunicarse.
• La subred con el JumpBox está concebida para operaciones de administración. La regla de NSG en la subred del jumpbox solo permite el acceso mediante SSH desde Azure Bastion en el centro y conexiones salientes limitadas. Los jump boxes no tienen acceso universal a Internet y están controlados tanto por el Grupo de Seguridad de Red (NSG) de la subred como por el Firewall de Azure.

A medida que se implementan las cargas de trabajo, los agentes de seguridad del sistema y otros componentes, agregue más reglas de NSG que ayuden a definir el tipo de tráfico que se debe permitir. El tráfico no debe atravesar esos límites de subred. Dado que cada grupo de nodos reside en su propia subred, observe los patrones del tráfico y, luego, aplique reglas más específicas.

Seguridad pod a pod con directivas de red

Esta arquitectura intenta implementar los principios de "confianza cero" de Microsoft en la medida de lo posible.

Los ejemplos de redes de confianza cero como concepto se muestran en la implementación dentro de los espacios de nombres proporcionados por el usuario a0005-i y a0005-o. Cada espacio de nombres de carga de trabajo debe tener aplicado un restrictivo NetworkPolicy . Las definiciones de directiva dependerán de los pods que se ejecuten en esos espacios de nombres. Asegúrese de tener en cuenta la preparación, la agilidad y los sondeos de inicio, y permita que se recopilen métricas mediante el agente de Log Analytics. Considere la posibilidad de estandarizar los puertos en sus cargas de trabajo para que pueda proporcionar una directiva coherente y una política de Azure para los puertos de contenedor permitidos.

En algunos casos, esto no es práctico para la comunicación dentro del clúster. No todos los espacios de nombres proporcionados por el usuario pueden usar una red de confianza cero (por ejemplo, cluster-baseline-settings no puede usar una).

Cifrado TLS

En la arquitectura de línea de base se proporciona tráfico cifrado con TLS hasta el controlador de entrada del clúster, pero la comunicación pod a pod está en la zona segura. En esta arquitectura, TLS se extiende al tráfico de pod a pod, con la validación de la entidad de certificación (CA). Una malla de servicio, que exige las conexiones mTLS y la comprobación antes de permitir la comunicación, proporciona ese TLS.

La implementación usa mTLS. La compatibilidad con mTLS se puede implementar con o sin una malla de servicio. Si usa una malla, asegúrese de que sea compatible con el emisor de certificados de su elección. Esta implementación usa Open Service Mesh.

El controlador de entrada de esta implementación usa un certificado comodín para controlar el tráfico predeterminado cuando un recurso de entrada no contiene un certificado concreto. Esta opción puede ser aceptable, pero si la directiva organizativa no permite el uso de certificados comodín, es posible que tenga que ajustar el controlador de entrada para que no los use.

Restricciones de red de Azure Key Vault

Todos los secretos, claves y certificados se almacenan en Azure Key Vault. Key Vault administra las tareas de administración de certificados, como la rotación. La comunicación con Key Vault se realiza a través de Azure Private Link. El registro DNS asociado a Key Vault está en una zona DNS privada para que no se pueda resolver desde Internet. Aunque esto mejora la seguridad, hay algunas restricciones.

Azure Application Gateway no admite la obtención de certificados TLS para el agente de escucha HTTP de instancias de Key Vault que se encuentran expuestas mediante Private Link, por lo que se despliega Key Vault en un modelo híbrido. Aunque todavía se usa Private Link para las conexiones que lo admiten, también se permite el acceso público para la integración con Application Gateway. Si este enfoque híbrido no es adecuado para su implementación, mueva el proceso de administración de certificados a Application Gateway. Aunque esta solución agrega sobrecarga de administración, la instancia de Key Vault estará completamente aislada.

Para obtener más información, consulte los siguientes recursos:

• Integración de Azure Application Gateway y Key Vault
• Creación de una puerta de enlace de aplicaciones con terminación TLS mediante la CLI de Azure

DDoS protection

Si tiene redes virtuales con direcciones IP públicas, habilite Azure DDoS Network Protection. En esta arquitectura de referencia, la subred que contiene Application Gateway tiene una dirección IP pública asociada, por lo que está en el ámbito de DDoS Protection.

Azure DDoS Network Protection protege la infraestructura y la carga de trabajo de solicitudes fraudulentas masivas. Estas solicitudes pueden provocar una interrupción del servicio o enmascarar otro ataque simultáneo. Azure DDoS Network Protection conlleva un costo significativo y normalmente se amortiza en muchas cargas de trabajo que abarcan muchas direcciones IP. Trabaje con el equipo de redes para coordinar la cobertura de las cargas de trabajo.

Administración de identidades y acceso

Defina roles y establezca controles de acceso según los requisitos del rol. Asigne roles a acciones de Kubernetes con un ámbito tan reducido como práctico. Evite roles que abarquen varias funciones. Si una sola persona desempeña varios roles, asígnele todos los roles pertinentes para las funciones de trabajo equivalentes. Incluso si una persona es directamente responsable del clúster y de la carga de trabajo, cree las instancias de Kubernetes ClusterRolecomo si hubiera usuarios independientes y, a continuación, asigne a ese único individuo todos los roles pertinentes.

Minimice el acceso permanente, especialmente para las cuentas de alto impacto, como las interacciones de SRE/Ops con el clúster. El plano de control de AKS admite Privileged Access Management (PAM) Just-In-Time (JIT) de Microsoft Entra ID y directivas de acceso condicional, que proporcionan una capa adicional de validación de autenticación necesaria para el acceso con privilegios, en función de las reglas que cree.

Para obtener más información sobre el uso de PowerShell para configurar el acceso condicional, consulte New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicyy Remove-MgIdentityConditionalAccessPolicy.

Cifrado de discos

Al diseñar el cifrado de datos en reposo, considere el uso de discos de almacenamiento, máquinas virtuales de nodo de agente de AKS, otras máquinas virtuales y cualquier disco temporal y del sistema operativo.

Discos de almacenamiento

De forma predeterminada, los discos de Azure Storage se cifran en reposo con claves administradas por Microsoft. Si usa discos de sistema operativo no efímeros o agrega discos de datos, se recomienda usar claves administradas por el cliente para controlar las claves de cifrado. Realice el cifrado fuera de la capa de almacenamiento y escriba solo datos cifrados en el medio de almacenamiento. Además, asegúrese de que las claves nunca sean adyacentes a la capa de almacenamiento. Para más información, consulte Traiga sus propias claves (BYOK) con discos de Azure.

Considere la posibilidad de usar BYOK con cualquier otro disco que pueda interactuar con el clúster, como las instancias de JumpBox dirigidas por Azure Bastion. Si elige BYOK, la opción de SKU para las máquinas virtuales y la disponibilidad regional se limitará porque esta característica no se admite en todas las SKU o regiones.

Hosts de máquina virtual

Se recomienda habilitar la característica de cifrado en host. Esta característica cifra el host de máquina virtual y cualquier sistema operativo temporal, o los discos de datos almacenados en caché, en un host de máquina virtual. Para más información, consulte Compatibilidad de máquinas virtuales con cifrado basado en host.

Esa característica se extiende a los datos almacenados en el host de máquina virtual de los nodos agente de AKS mediante la característica Cifrado basado en host. De forma similar a BYOK, esta característica podría limitar las opciones de SKU y región de la máquina virtual.

Puede aplicar esas características mediante Azure Policy.

Copias de seguridad del clúster (estado y recursos)

Si la carga de trabajo requiere almacenamiento dentro del clúster, disponga de un proceso sólido y seguro para la copia de seguridad y la recuperación. Considere servicios, como Azure Backup (para Azure Disks y Azure Files), para la copia de seguridad y recuperación de cualquier PersistentVolumeClaim. Hay ventajas si el sistema de copia de seguridad admite recursos nativos de Kubernetes. Puede complementar el método principal que devuelve el clúster a un estado conocido con el sistema de copia de seguridad para disponer de técnicas de recuperación de sistemas críticos. Así, por ejemplo, se puede detectar el desfase y catalogar los cambios de estado del sistema a lo largo del tiempo en el nivel de recurso de Kubernetes.

Los procesos de copia de seguridad deben clasificar los datos de la copia de seguridad, independientemente de si los datos proceden del clúster o son externos al mismo. Si los datos están en el ámbito de PCI DSS 4.0.1, amplíe los límites de cumplimiento para incluir el ciclo de vida y el destino de la copia de seguridad, que estará fuera del clúster. Las copias de seguridad pueden ser un vector de ataque. Al diseñar la copia de seguridad, tenga en cuenta las restricciones geográficas, el cifrado en reposo, los controles de acceso, los roles y las responsabilidades, la auditoría, el período de vida y la prevención contra alteraciones.

Se espera que los sistemas de copia de seguridad dentro del clúster se ejecuten con privilegios elevados durante sus operaciones. Evalúe el riesgo y la ventaja de incorporar un agente de copia de seguridad al clúster. ¿La funcionalidad del agente se solapa con otra solución de administración del clúster? ¿Cuál es el conjunto mínimo de herramientas que necesita para realizar esta tarea sin expandir la superficie expuesta a ataques?

Consideraciones sobre Azure Policy

Las directivas de Azure aplicadas normalmente no tienen una configuración optimizada para cargas de trabajo. En la implementación, aplicamos la iniciativa de los estándares restringidos de seguridad de pods de clúster de Kubernetes para cargas de trabajo basadas en Linux, que es una de las iniciativas de directiva integradas. Esta iniciativa no permite la optimización de la configuración. Considere la posibilidad de exportar esta iniciativa y personalizar sus valores para la carga de trabajo específica. Puede incluir todas las directivas de Azure de Gatekeeper deny en una iniciativa personalizada y todas las audit directivas de Azure en otra iniciativa. Al hacerlo, se clasifican las acciones de bloqueo de las directivas de solo información.

Considere la posibilidad de incluir los espacios de nombres kube-system y gatekeeper-system en las directivas de kube-system para una mayor visibilidad. La inclusión de esos espacios de nombres en las directivas deny podría provocar un error en el clúster debido a una configuración no admitida.

Puede exigir el cifrado de datos estableciendo algunas alertas de Azure Policy. Por ejemplo, puede exigir BYOK con una alerta que detecte los clústeres que no tienen diskEncryptionSetID en el recurso de clúster. Otra directiva puede detectar si el cifrado basado en host está habilitado en agentPoolProfiles. En la implementación de referencia no se usa ningún disco del clúster y el disco del sistema operativo es efímero. Ambas directivas de ejemplo existen como recordatorio de la característica de seguridad. Las directivas se establecen en audit, no en block.

Administrar imágenes

Use imágenes base sin distribución para las cargas de trabajo. Con estas imágenes, el área de superficie de seguridad se reduce porque se quitan imágenes adicionales, como shells y administradores de paquetes. Una ventaja es la reducción de las tasas de impacto de CVE.

Azure Container Registry admite imágenes que cumplen la especificación de formato de imagen de Open Container Initiative (OCI). Esto, junto con un controlador de admisión que permite la validación de firmas, puede garantizar que solo se ejecuten imágenes que se han firmado con las claves privadas. Existen soluciones de código abierto, como SSE Connaisseur o IBM Portieris, que integran esos procesos.

Proteja las imágenes de contenedor y otros artefactos de OCI, ya que contienen la propiedad intelectual de la organización. Use claves administradas por el cliente y cifre el contenido de los registros. De manera predeterminada, los datos se cifran en reposo con claves administradas por el servicio, pero suelen ser necesarias claves administradas por el cliente para satisfacer los estándares de cumplimiento normativo. Almacene la clave en un almacén de claves administrado, como Azure Key Vault. Dado que crea y posee la clave, es responsable de las operaciones relacionadas con el ciclo de vida de las claves, incluida la rotación y la administración. Para más información, consulte Cifrado del registro con una clave administrada por el cliente.

Acceso operativo al servidor de API de Kubernetes

Puede limitar los comandos ejecutados en el clúster sin crear necesariamente un proceso operativo basado en los jump boxes. Si tiene una plataforma de automatización de TI canalizada por IAM, use las acciones predefinidas para controlar y auditar el tipo de acciones.

Compilación de agentes

Los agentes de canalización deben estar fuera del ámbito del clúster regulado porque los procesos de compilación pueden ser vectores de amenazas. Por ejemplo, los procesos de compilación suelen trabajar con componentes no probados y que no son de confianza.

Aunque es habitual usar Kubernetes como una infraestructura de agente de compilación elástica, no ejecute ese proceso dentro de los límites de tiempo de ejecución de las cargas de trabajo reguladas. Los agentes de compilación no deben tener acceso directo al clúster. Por ejemplo, solo proporciona acceso a la red de agentes de compilación a Azure Container Registry para insertar imágenes de contenedor, gráficos de Helm, etc. Luego, realice la implementación mediante GitOps. Como práctica habitual, los flujos de trabajo de compilación y versión no deben tener acceso directo a la API de clúster de Kubernetes (ni a sus nodos).

Supervisión de operaciones

Actividades dentro del clúster

Los pods omsagent dentro del clúster que se ejecutan en kube-system son el agente de recopilación de Log Analytics. Estos recopilan telemetría, registros stdout y stderr y métricas de Prometheus. Puede ajustar la configuración de su recopilación actualizando el archivo de ConfigMap container-azm-ms-agentconfig.yaml. En esta implementación de referencia, el registro está habilitado en kube-system y en todas las cargas de trabajo. De forma predeterminada, kube-system se excluye del registro. Asegúrese de ajustar el proceso de recopilación de registros para lograr los objetivos de equilibrio de costos, la eficiencia de SRE al revisar los registros y las necesidades de cumplimiento.

Supervisión de seguridad

Use Defender para contenedores en Microsoft Defender for Cloud para ver y corregir las recomendaciones de seguridad y para ver las alertas de seguridad en los recursos de contenedor. Habilite planes de Microsoft Defender a medida que se aplican a varios componentes del entorno de datos de los titulares de tarjetas.

Integre los registros para poder revisar, analizar y consultar datos de forma eficaz. Azure proporciona varias opciones. Puede activar los registros de diagnóstico de AKS y enviarlos a un área de trabajo de Log Analytics que forme parte de Azure Monitor. Otra opción consiste en integrar los datos en soluciones de administración de eventos e información de seguridad (SIEM), como Microsoft Sentinel.

Si así lo requiere la norma, todas las áreas de trabajo de Log Analytics se establecen en un período de retención de 90 días. Considere la posibilidad de configurar la exportación continua para el almacenamiento a largo plazo. No almacene información confidencial en los datos de registro y asegúrese de que el acceso a los datos de registro archivados está sujeto a los mismos niveles de controles de acceso que los datos de registro recientes.

Para tener una perspectiva completa, consulte Guía de incorporación empresarial de Microsoft Defender for Cloud. En esta guía se aborda la inscripción, las exportaciones de datos a las soluciones SIEM, la respuesta a las alertas y la creación de automatización del flujo de trabajo.

Servicios de Azure relacionados

Estos son vínculos a la documentación de características de algunos componentes clave de esta arquitectura:

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Conjuntos de escalado de máquinas virtuales de Azure
• Azure Application Gateway con Web Application Firewall (WAF) integrado
• Tareas de Azure Container Registry
• Azure Key Vault

Pasos siguientes

Instalar y mantener una configuración de firewall para proteger los datos de los titulares de las tarjetas. No use los valores predeterminados proporcionados por el proveedor para las contraseñas del sistema y otros parámetros de seguridad.