Arquitectura de un clúster regulado de AKS para PCI-DSS 3.2.1 (parte 2 de 9)

En este artículo se describe una arquitectura de referencia para un clúster de Azure Kubernetes Service (AKS) que ejecuta una carga de trabajo que cumple el Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI-DSS 3.2.1). Esta arquitectura se centra en la infraestructura y no en la carga de trabajo de PCI-DSS 3.2.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:

GitHub: Clúster de línea base de Azure Kubernetes Service (AKS) para cargas de trabajo reguladas muestra una infraestructura regulada. Esta implementación proporciona una aplicación de microservicios. Se incluye para ayudarle a experimentar la infraestructura e ilustrar los controles de red y de seguridad. La aplicación no representa ni implementa una carga de trabajo de PCI DSS real.

Descargue un archivo Visio de esta arquitectura.

Esa arquitectura de red se basa en una topología de red en estrella tipo hub-and-spoke. La red virtual del centro contiene el firewall para controlar el tráfico de salida y el tráfico de puerta de enlace de las redes locales y una tercera red para el acceso al clúster de SRE (ingeniero de confiabilidad del sitio). Hay dos redes virtuales de radio. Un radio contiene el clúster de AKS que es un componente del entorno de titulares de tarjetas (CDE) y hospeda la carga de trabajo de PCI DSS. El otro radio compila las imágenes de máquina virtual usadas para el acceso controlado de SRE al entorno.

Componentes

Estos son los componentes principales que se usan en esta arquitectura. Si no está familiarizado con estos servicios, consulte Servicios de Azure relacionados para obtener vínculos a la documentación del producto.

Azure Firewall

La instancia de firewall protege el tráfico de red saliente. Sin este nivel de seguridad, el flujo puede comunicarse con un servicio malintencionado de terceros que podría exfiltrar los datos confidenciales de la empresa.

Azure Bastion

La arquitectura de línea de base proporcionaba una subred para Azure Bastion, pero no aprovisionaba el recurso. Esta arquitectura agrega Azure Bastion en la subred y proporciona acceso seguro a un jumpbox.

Azure Image Builder

Aprovisionado en una red virtual independiente, crea imágenes de máquina virtual con seguridad y configuración básicas. En esta arquitectura, se personaliza para compilar imágenes de nodo seguras con herramientas de administración, como la CLI de Azure, kubectl y la CLI de Flux preinstalados.

Azure Virtual Machine Scale Sets para instancias de JumpBox

La red de radio tiene proceso adicional para un JumpBox. Este conjunto de escalado está destinado a ser el punto de acceso regulado para ejecutar herramientas en el clúster de AKS, como kubectl, según sea necesario.

Azure Application Gateway con Web Application Firewall (WAF) integrado

Azure Application Gateway equilibra la carga en la capa 7. WAF protege el tráfico entrante frente a los ataques de tráfico web comunes. La instancia tiene una configuración de IP de front-end pública que recibe las solicitudes del usuario.

Azure Kubernetes Service (AKS)

La infraestructura de hospedaje, que es una parte principal del entorno de datos de titulares de tarjetas (CDE). El clúster de AKS se implementa como un clúster privado. Por lo tanto, el servidor de API de Kubernetes no se expone a la red pública de Internet y el tráfico al servidor de API se limita a la red privada.

ACR Tasks

Proporciona una manera automatizada de crear y mantener imágenes de contenedor.

Azure Key Vault

Almacena y administra los secretos necesarios para las operaciones del clúster, como certificados y claves de cifrado.

Configuración del clúster

Estos son algunos cambios importantes con respecto a la arquitectura de línea de 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 opción de proceso para los grupos de nodos permanece igual. 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 3.2.1 requiere que la carga de trabajo de PCI se aísle 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. El lado negativo es el aumento de los costos por la infraestructura agregada 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 ese modelo, 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 segundo enfoque con una aplicación de microservicios implementada 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 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 taints 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

El controlador de entrada de Kubernetes dentro del clúster se ha cambiado a NGINX. En la arquitectura de línea de base, se usaba Traefik. Este cambio demuestra que este componente se puede cambiar en función de los requisitos de las cargas 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. Esta opción no es aceptable en esta arquitectura porque PCI-DSS 3.2.1 prohíbe la exposición pública a cualquier componente 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. Estos son los componentes principales 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 garantizan lo siguiente:

  • Solo se permite la entrada de tráfico HTTPS.
  • Se permite el tráfico procedente del plano de control de Azure. 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 solo permite el acceso mediante SSH desde Azure Bastion en el centro y conexiones salientes limitadas. Las instancias de JumpBox no tienen acceso universal a Internet y se controlan tanto en el grupo de seguridad de red de la subred como en Azure Firewall.

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.

Se muestran ejemplos de redes de Confianza cero como concepto en la implementación de los espacios de nombres proporcionados por el usuario a0005-i y a0005-o. A todos los espacios de nombres de la carga de trabajo se les debe aplicar NetworkPolicy de forma restrictiva. 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, así como la asignación de métricas recopiladas por el agente de Log Analytics. Considere la posibilidad de estandarizar los puertos de las cargas de trabajo para que pueda proporcionar un valor de NetworkPolicy coherente y Azure Policy para los puertos de contenedor permitidos.

En algunos casos, esta solución no es práctica 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 procedencia de certificados TLS para el cliente de escucha HTTP desde instancias de Key Vault que se exponen con Private Link. Por lo tanto, la implementación de Key Vault se realiza 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 información, consulte:

• 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

Protección contra DDOS

Habilite la Protección de red contra DDoS de Azure en redes virtuales con una subred que contenga Application Gateway con una dirección IP pública. Con ello se protege la infraestructura y la carga de trabajo frente a solicitudes fraudulentas masivas. Estas solicitudes pueden provocar una interrupción del servicio o enmascarar otro ataque simultáneo. Azure DDoS tiene un costo considerable y normalmente se amortiza con muchas cargas de trabajo que abarcan muchas direcciones IP. Trabaje con el equipo de redes para coordinar la cobertura de la carga de trabajo.

Administración de identidad 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. Por lo tanto, incluso si una persona es directamente responsable del clúster y de la carga de trabajo, cree su valor de ClusterRoles de Kubernetes como si fueran individuos distintos. Luego, 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-MgIdentityConditionalAccessPolicy y 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 estará limitada 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. Más información sobre la compatibilidad de máquinas virtuales con el 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 PersistantVolumeClaim. 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 dentro o fuera del clúster. Si los datos están dentro del ámbito de PCI DSS 3.2.1, extienda los límites de cumplimiento para incluir el ciclo de vida y el destino de la copia de seguridad, que estarán 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

Normalmente, las directivas de Azure aplicadas no tienen una configuración optimizada para cargas de trabajo. En la implementación, se aplica la iniciativa de estándares restringidos de seguridad de pods de clúster de Kubernetes para cargas de trabajo basadas en Linux, que no permite el ajuste 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 deny de Azure de Gatekeeper en una iniciativa personalizada y todas las directivas audit de Azure en otra. 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.

Administración de 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 usted crea y posee la clave, es responsable de las operaciones relacionadas con su ciclo de vida, incluidas 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 necesidad de crear un proceso operativo basado en instancias de JumpBox. Si tiene una plataforma de automatización de TI canalizada por IAM, use las acciones predefinidas para controlar y auditar el tipo de acciones.

Agentes de compilación

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. 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, únicamente proporcione a los agentes de compilación acceso de red 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 la 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 de los componentes principales de esta arquitectura.

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Azure Virtual Machine Scale Sets
• 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 con las contraseñas del sistema y otros parámetros de seguridad.