El marco de buena arquitectura de Azure es un conjunto de principios orientativos que se pueden usar para evaluar una solución a través de la excelencia de los pilares de calidad de la arquitectura:
Con este artículo finaliza esta serie. Lea la introducción.
Las instrucciones proporcionadas en esta serie incorporan los principios de buena arquitectura en todas las opciones de diseño. En este artículo se resumen esas opciones. La implementación de GitHub: Cluster de línea base de Azure Kubernetes Service (AKS) para cargas de trabajo reguladas muestra esos principios, según corresponda.
Las cargas de trabajo de PCI DSS 3.2.1 exigen el rigor de ser una solución con buena arquitectura. Aunque la alineación de la infraestructura con los requisitos de PCI es crítica, el cumplimiento no se detiene en la infraestructura de hospedaje. No abordar los pilares de calidad, específicamente la seguridad, puede poner en peligro el cumplimiento. Las soluciones con buena arquitectura combinan las perspectivas de infraestructura y de carga de trabajo para alcanzar el rigor necesario para lograr resultados conformes.
Seguridad
Siga la guía fundamental proporcionada en los principios de diseño de seguridad. En estas secciones se resumen los procedimientos recomendados para un entorno regulado.
Gobernanza
La implementación de la gobernanza se controla por los requisitos de cumplimiento de PCI-DSS 3.2.1. Esto influye en los controles técnicos para mantener la segmentación, el acceso a los recursos, la detección de vulnerabilidades y, lo que es más importante, la protección de los datos de los clientes.
Estrategia de segmentación empresarial
Para mantener el aislamiento completo, se recomienda implementar la infraestructura regulada en una suscripción independiente. Si tiene varias suscripciones que son necesarias para el cumplimiento, considere la posibilidad de agruparlas en una jerarquía de grupos de administración que aplique las directivas de Azure pertinentes uniformemente en todas las suscripciones dentro del ámbito. Dentro de la suscripción, aplique las directivas de Azure relacionadas en un nivel de suscripción para capturar las directivas generales que se deben aplicar a todos los clústeres del entorno de datos de los titulares de las tarjetas (CDE). Aplique las directivas de Azure relacionadas en el nivel de grupo de recursos para capturar las directivas que se aplican a una instancia específica de clúster. Estas directivas crean las barreras de protección principales de una zona de aterrizaje.
Aísle la carga de trabajo de PCI (dentro del ámbito) de otras cargas de trabajo (fuera del ámbito) en términos de operaciones y conectividad. Puede crear aislamiento mediante la implementación de clústeres independientes. O bien, use estrategias de segmentación para mantener la separación. Por ejemplo, los clústeres usan grupos de nodos independientes para que las cargas de trabajo nunca compartan una máquina virtual (VM) de nodo.
Cumplimiento de directivas
Aplique controles de seguridad mediante la habilitación de directivas de Azure. Por ejemplo, en esta arquitectura reglada, puede evitar la configuración incorrecta del entorno de datos de los titulares de las tarjetas. Puede aplicar una directiva de Azure que no permita asignaciones de direcciones IP públicas en los nodos de máquina virtual. Estas asignaciones se detectan y notifican o bloquean.
Para información sobre las directivas que puede habilitar para AKS, consulte Definiciones integradas de Azure Policy para Azure Kubernetes Service.
Azure proporciona varias directivas integradas para la mayoría de los servicios. Revise estas Definiciones de directivas integradas de Azure Policy y aplíquelas según corresponda.
Supervisión del cumplimiento
El cumplimiento debe supervisarse y mantenerse sistemáticamente. Se realizan atestaciones de cumplimiento periódicas. Saber si los recursos en la nube son conformes le ayudará a prepararse para las atestaciones y la auditoría.
Aproveche el panel de cumplimiento normativo de Microsoft Defender for Cloud. Al supervisar continuamente el panel, puede realizar un seguimiento del estado de cumplimiento de la carga de trabajo.
Seguridad de las redes
En una topología en estrella tipo hub-and-spoke, tener redes virtuales independientes para cada entidad proporciona una segmentación básica en la superficie de la red. Cada red se segmenta más en subredes.
El clúster de AKS forma el núcleo del CDE. No debe ser accesible desde direcciones IP públicas y se debe proteger la conectividad. Los flujos típicos dentro y fuera de CDE se pueden clasificar como:
- Tráfico entrante al clúster.
- Tráfico saliente del clúster.
- Tráfico dentro del clúster entre pods.
Para cumplir los requisitos de un entorno regulado, el clúster se implementa como un clúster privado. En este modo, el tráfico hacia y desde la red pública de Internet está restringido. Incluso la comunicación con el servidor de API de Kubernetes administrado por AKS es privada. La seguridad se mejora aún más con controles de red estrictos y reglas de firewall de IP.
- Grupos de seguridad de red (NSG) para ayudar a proteger la comunicación entre los recursos de una red.
- Azure Firewall para filtrar el tráfico saliente entre los recursos en la nube, Internet y el entorno local.
- Azure Application Gateway integrado en el marco de trabajo de la aplicación web de Azure para filtrar todo el tráfico entrante desde Internet que Azure Application Gateway intercepta.
- NetworkPolicy de Kubernetes para permitir solo determinadas rutas de acceso entre los pods del clúster.
- Azure Private Link para conectarse a otros servicios de plataforma como servicio (PaaS) de Azure, como Azure Key Vault y Azure Container Registry para tareas operativas.
Los procesos de supervisión están preparados para asegurarse de que el tráfico fluya según lo previsto y de que se detecte y notifique cualquier anomalía.
Para detalles sobre la seguridad de red, consulte Segmentación de red.
Seguridad de los datos
PCI-DSS 3.2.1 requiere que todos los datos de los titulares de las tarjetas (CHD) nunca sean evidentes, ya sea en tránsito o en almacenamiento.
Dado que esta arquitectura y la implementación se centran en la infraestructura y no en la carga de trabajo, no se muestra la administración de datos. Estas son algunas recomendaciones de buena arquitectura.
Datos en reposo
Los datos deben cifrarse a través de algoritmos de cifrado estándar del sector.
- No almacene datos en el entorno de los titulares de las tarjetas.
- Cífrelos fuera de la capa de almacenamiento.
- Escriba solo datos cifrados en el medio de almacenamiento.
- No almacene las claves en la capa de almacenamiento.
Todos los datos de Azure Storage se cifran y descifran mediante criptografía segura. Se prefieren las claves de cifrado autoadministradas.
Si necesita almacenar datos temporalmente, aplique las mismas consideraciones a dichos datos. Se recomienda encarecidamente habilitar la característica de cifrado de host de AKS. Puede forzar el cifrado de datos temporales con directivas de Azure integradas.
Al elegir una tecnología de almacenamiento, explore las características de retención. Asegúrese de que todos los datos se quitan de forma segura cuando expire el tiempo configurado.
El estándar también requiere que no se almacenen datos de autenticación confidenciales (SAD). Asegúrese de que los datos no se exponen en registros, nombres de archivo, caché y otros datos.
Datos en tránsito
Toda la comunicación con entidades que interactúan con el CDE debe realizarse a través de canales cifrados.
- Solo se debe permitir que fluya al CDE tráfico HTTPS. En esta arquitectura, Azure Application Gateway deniega todo el tráfico a través del puerto 80.
- Preferiblemente, no cifre y descifre los datos fuera del CDE. Si lo hace, considere que esa entidad forma parte del CDE.
- Dentro del CDE, proporcione una comunicación segura entre pods con mTLS. Puede optar por implementar una malla de servicio para este propósito.
- Permita solo cifrados seguros y TLS 1.2 o versiones posteriores.
Identidad
Siga estos principios de seguridad al diseñar directivas de acceso:
- Comience con directivas de Confianza cero. Realice las excepciones que necesite.
- Conceda privilegios mínimos, los suficientes para completar una tarea.
- Minimice el acceso permanente.
El control de acceso basado en rol (RBAC) de Kubernetes administra los permisos para la API de Kubernetes. AKS admite esos roles de Kubernetes. AKS está totalmente integrado con Microsoft Entra ID. Puede asignar identidades de Microsoft Entra a los roles y aprovechar también otras funcionalidades.
Acceso de Confianza cero
RBAC de Kubernetes, Azure RBAC y los servicios de Azure implementan Denegar todo de forma predeterminada. Reemplace esta configuración con precaución, permitiendo el acceso solo a las entidades que lo necesiten. Otra área para implementar Confianza cero es deshabilitar el acceso SSH a los nodos del clúster.
Privilegios mínimos
Puede usar identidades administradas para los recursos y pods de Azure y establecer su ámbito en las tareas previstas. Por ejemplo, Azure Application Gateway debe tener permisos para obtener secretos (certificados TLS) de Azure Key Vault. No debe tener permisos para modificar los secretos.
Minimización del acceso permanente
Minimice el acceso permanente utilizando la pertenencia grupal de Microsoft Entra just-In-Time. Proteja el control con directivas de acceso condicional en Microsoft Entra ID. Esta opción admite muchos casos de uso, como la autenticación multifactor, restringir la autenticación a dispositivos administrados por su inquilino de Microsoft Entra o bloquear intentos de inicio de sesión atípicos.
Administración de secretos
Almacene los secretos, los certificados, las claves y las contraseñas fuera del CDE. Puede usar los objetos de secretos nativos de Kubernetes o un almacén de claves administrado, como Azure Key Vault. El uso de un almacén administrado le ayudará en las tareas de administración de secretos, como la rotación de claves y la renovación de certificados.
Asegúrese de que el acceso al almacén de claves tiene una combinación de controles de acceso y red. Al habilitar identidades administradas, el clúster tiene que autenticarse en Key Vault para obtener acceso. Además, la conectividad con el almacén de claves no debe ser a través de la red pública de Internet. Use una red privada, como Private Link.
Excelencia operativa
Siga las instrucciones fundamentales proporcionadas en los Principios de excelencia operativa. En estas secciones se resumen los procedimientos recomendados para un entorno regulado.
Separación de roles
Es fundamental aplicar una segregación clara de las obligaciones para entornos regulados. Cree definiciones de roles y responsabilidades en función de las necesidades de la carga de trabajo y la interacción con el CDE. Por ejemplo, puede que necesite un rol de operador de infraestructura o de ingeniero de confiabilidad de sitios (SRE) para las operaciones relacionadas con el clúster y los servicios dependientes. El rol es responsable de mantener la seguridad, el aislamiento, la implementación y la observabilidad. Formalice esas definiciones y decida los permisos que necesitan esos roles. Por ejemplo, los SRE tienen privilegios elevados para el acceso al clúster, pero necesitan acceso de lectura para los espacios de nombres de carga de trabajo.
Aislamiento de cargas de trabajo
PCI-DSS 3.2.1 requiere el aislamiento de la carga de trabajo de PCI de las otras cargas de trabajo en términos de operaciones. En esta implementación, las cargas de trabajo dentro y fuera del ámbito se segmentan en dos grupos de nodos de usuarios independientes. Los desarrolladores de aplicaciones para dentro del ámbito y los desarrolladores para cargas de trabajo fuera del ámbito pueden tener distintos conjuntos de permisos. Además, habrá puertas de calidad independientes. Por ejemplo, el código dentro del ámbito está sujeto a cumplimiento y atestación, mientras que el código fuera del ámbito no lo está. También es necesario tener canalizaciones de compilación y procesos de administración de versiones independientes.
Metadatos operativos
El requisito 12 del estándar PCI DSS 3.2.1 requiere que mantenga información sobre el inventario de cargas de trabajo y documentación de acceso del personal. Se recomienda encarecidamente usar etiquetas de Azure porque puede intercalar información de entorno con recursos, grupos de recursos y suscripciones de Azure.
Mantenga información sobre las soluciones aprobadas que forman parte de la infraestructura y la carga de trabajo. Esto incluye una lista de imágenes de máquina virtual, bases de datos y soluciones de terceros de su elección que traiga al CDE. Incluso puede automatizar ese proceso mediante la creación de un catálogo de servicios. Proporciona una implementación de autoservicio mediante las soluciones aprobadas en una configuración específica, que se ajusta a las operaciones en curso de la plataforma.
Observabilidad
Para cumplir el requisito 10, la observabilidad del CDE es fundamental para el cumplimiento. Los registros de actividad proporcionan información sobre las operaciones relacionadas con la administración de cuentas y secretos, la administración de la configuración de diagnóstico, la administración del servidor y otras operaciones de acceso a recursos. Todos los registros se registran con la fecha, la hora, la identidad y otra información detallada. Conserve los registros hasta un año mediante la configuración de directivas de archivado y retención de datos en los registros de Azure Monitor.
Asegúrese de que solo accedan a los registros los roles que los necesiten. Log Analytics y Microsoft Sentinel admiten varios controles de acceso basados en roles para administrar el acceso al registro de auditoría.
Respuesta y corrección
Los servicios de supervisión de Azure, Azure Monitor y Microsoft Defender pueden generar notificaciones o alertas cuando detecten actividad anómala. Estas alertas incluyen información de contexto, como la gravedad, el estado y el tiempo de actividad. A medida que se generan alertas, tenga una estrategia de corrección y revise el progreso. Se recomienda centralizar los datos en una solución de administración de eventos e información de seguridad (SIEM), ya que la integración de datos puede proporcionar un contexto de alertas enriquecido.
Desde la vista Alertas de seguridad de Microsoft Defender para la nube, tiene acceso a todas las alertas que Microsoft Defender para la nube detecta en los recursos. Disponga de un proceso de evaluación de prioridades para solucionar el problema. Trabaje con el equipo de seguridad para comprender cómo se pondrán las alertas pertinentes a disposición de los propietarios de las cargas de trabajo.
Eficiencia del rendimiento
Siga las instrucciones fundamentales proporcionadas en los Principios de eficiencia del rendimiento. En estas secciones se resumen los procedimientos recomendados para un entorno regulado.
Ampliación
Observar cómo se ajusta el entorno a las demandas cambiantes indicará el comportamiento esperado del runtime del entorno con una carga elevada. El escalado automático de los recursos de la carga de trabajo minimizará la interacción humana en el CDE. Una ventaja de seguridad adicional es la reducción de la superficie de ataque en todo momento. Puede maximizar la ventaja aprovechando los recursos que admiten el enfoque de escalado a cero. Por ejemplo, AKS admite la reducción vertical de los grupos de nodos de usuario a 0. Para más información, consulte Escalado de grupos de nodos de usuario a 0.
Creación de particiones
La creación de particiones es un factor clave para la eficiencia del rendimiento en las cargas de trabajo reguladas. Tener componentes discretos permite definir claramente la responsabilidad y ayuda en la precisión de los controles, como las directivas de red. De forma similar a cualquier estrategia de segmentación, la creación de particiones aísla los componentes y controla el impacto de la onda expansiva de errores inesperados o del peligro del sistema.
Arquitectura sin ningún recurso compartido
La arquitectura sin ningún recurso compartido está diseñada para eliminar la contención entre cargas de trabajo colocadas. Además, se trata de una estrategia para quitar únicos puntos de error. En un entorno regulado, los componentes deben aislarse mediante límites lógicos o físicos. Esto se alinea con la arquitectura sin ningún recurso compartido, lo que genera ventajas de escalabilidad. Además, permite establecer como destino los controles de seguridad relevantes y las funcionalidades de auditoría más estrictas de los distintos componentes.
Cargas de trabajo ligeras
La complejidad de las cargas de trabajo es difícil de documentar y auditar. Procure lograr simplicidad ya que obtendrá ventajas de rendimiento y facilidad de auditoría de los requisitos normativos. Replantéese las opciones que conlleven más dificultades de las necesarias, ya que aumenta el área de superficie de ataque y la posibilidad de un uso o una configuración incorrectos.
Confiabilidad
La confiabilidad de los entornos regulados debe ser predecible para que se puedan explicar de forma coherente en la auditoría. Siga la guía fundamental proporcionada en los principios de confiabilidad. En estas secciones se resumen los procedimientos recomendados para un entorno regulado.
Destinos de recuperación y recuperación ante desastres
Debido a la naturaleza confidencial de los datos que se manejan en las cargas de trabajo reguladas, es fundamental la definición de los objetivos de recuperación y los objetivos de punto de recuperación (RPO). ¿Qué es la pérdida aceptable de CHD? Los esfuerzos de recuperación dentro del CDE siguen sujetos a los requisitos estándar. Espere errores y disponga de un plan de recuperación claro que se alinee con los roles, las responsabilidades y el acceso a datos justificado. Los problemas de sitios activos no son una justificación para desviarse de ninguna normativa. Esto es especialmente importante en una situación de recuperación ante desastres completa. Tenga documentación clara de recuperación ante desastres que se ajuste a los requisitos y minimice el acceso inesperado a CDE o CHD. Después de la recuperación, revise siempre los pasos del proceso de recuperación para asegurarse de que no se ha producido ningún acceso inesperado. Documente las justificaciones empresariales de esas instancias.
Recuperación
Agregar estrategias de resistencia y recuperación a la arquitectura puede evitar la necesidad de acceso ad hoc al CDE. El sistema debe ser capaz de recuperarse por sí mismo en el RPO definido sin necesidad de intervención humana directa. De este modo, puede eliminar la exposición innecesaria de CHD, incluso a aquellas personas que están autorizadas a tener acceso de emergencia. El proceso de recuperación debe ser auditable.
Enfoque de los riesgos relacionados con la seguridad
Revise los riesgos de seguridad porque pueden ser un origen de tiempo de inactividad y pérdida de datos de la carga de trabajo. Las inversiones en seguridad también afectan a la confiabilidad de las cargas de trabajo.
Procesos operativos
La confiabilidad se extiende a todos los procesos operativos y adyacentes del CDE. Procesos bien definidos, automatizados y probados para cuestiones como la creación de imágenes y la administración de jumpbox se incluyen una solución con buena arquitectura.
Optimización de costos
Siga las instrucciones fundamentales proporcionadas en los principios de optimización de costes.
Una clara contrapartida a los requisitos de cumplimiento y a los estrictos controles de seguridad es el coste. Se recomienda establecer estimaciones iniciales mediante la Calculadora de precios.
Esta es una representación de alto nivel del impacto en el coste de los principales recursos que usa esta arquitectura.
Los controladores principales son los conjuntos de escalado de máquinas virtuales que son los grupos de nodos y Azure Firewall. Otro colaborador es Log Analytics. También hay costes incrementales asociados a Microsoft Defender for Cloud, en función de la elección de planes.
Tenga una clara comprensión de lo que constituye el precio de un servicio. Azure realiza un seguimiento del uso medido. Esta es una exploración en profundidad de Azure Firewall para esta arquitectura.
El coste asociado a algunos recursos, como Azure Firewall, se puede extender a varias unidades de negocio o aplicaciones. Otra manera de optimizar el coste puede ser hospedar un clúster multiinquilino dentro de una organización, maximizando la densidad con diversidad de cargas de trabajo. Sin embargo, no se recomienda este enfoque para cargas de trabajo reguladas. Priorice siempre el cumplimiento y la segmentación sobre las ventajas de costes.
Para mantenerse dentro de las restricciones del presupuesto, algunas maneras de controlar el coste son ajustar la infraestructura de Azure Application Gateway, establecer el recuento de instancias para el escalado automático y reducir la salida del registro siempre y cuando cumplan el registro de auditoría requerido por PCI-DSS 3.2.1. Evalúe siempre esas opciones con las contrapartidas de otros aspectos del diseño que le permitan cumplir el Acuerdo de Nivel de Servicio. Por ejemplo, ¿todavía puede escalar correctamente para satisfacer los picos de tráfico?
A medida que cree grupos de recursos de Azure, aplique etiquetas para que se pueda realizar un seguimiento de los costes. Use herramientas de administración de costes como Azure Advisor y Microsoft Cost Management para realizar un seguimiento y analizar los costes.
Considere la posibilidad de habilitar el análisis de costos de AKS para la asignación de costos de infraestructura de clúster pormenorizadas mediante construcciones específicas de Kubernetes.