Compartir a través de

Arquitectura de referencia de Azure Spring Apps

  • Artículo

Nota:

Azure Spring Apps es el nuevo nombre del servicio Azure Spring Cloud. Aunque el servicio tiene un nuevo nombre, verá el nombre antiguo en algunos lugares durante un tiempo mientras trabajamos para actualizar recursos, como capturas de pantalla, vídeos y diagramas.

La información de este artículo puede ponerse en práctica en:✔️ Estándar ✔️ Enterprise

Esta arquitectura de referencia es una base que usa un diseño empresarial típico de concentrador y radio (hub-and-spoke) para el uso de Azure Spring Apps. En el diseño, Azure Spring Apps se implementa en un único radio que depende de los servicios compartidos hospedados en el concentrador. La arquitectura se crea con componentes para lograr los principios del Marco de buena arquitectura de Microsoft Azure.

Hay dos tipos de Azure Spring Apps: Plan estándar y Plan Enterprise.

El plan Estándar de Azure Spring Apps se compone de Spring Cloud Config Server, Spring Cloud Service Registry y el servicio de compilación kpack.

El plan Enterprise de Azure Spring Apps se compone del servicio de compilación de VMware Tanzu®, el servicio de configuración de aplicaciones para VMware Tanzu®, el registro del servicio VMware Tanzu®, Spring Cloud Gateway para VMware Tanzu® y el portal de API para VMware Tanzu®.™

Para obtener una implementación de esta arquitectura, consulte Arquitectura de referencia de Azure Spring Apps en GitHub.

Las opciones de implementación para esta arquitectura son Azure Resource Manager (ARM), Terraform, la CLI de Azure y Bicep. Los artefactos de este repositorio ofrecen una base que se puede personalizar para su entorno. Puede agrupar recursos, como Azure Firewall o Application Gateway, en diferentes grupos de recursos o suscripciones. Esta agrupación ayuda a mantener independientes diferentes funciones, como la infraestructura de TI, la seguridad, los equipos de aplicaciones empresariales, etc.

Planeación del espacio de direcciones

Azure Spring Apps requiere dos subredes dedicadas:

  • Entorno de ejecución del servicio
  • Aplicaciones de Spring Boot

Cada una de estas subredes requiere un clúster dedicado de Azure Spring Apps. Varios clústeres no pueden compartir las mismas subredes. El tamaño mínimo de cada subred es /28. El número de instancias de la aplicación que Azure Spring Apps puede admitir varía en función del tamaño de la subred. Puede encontrar los requisitos detallados de la red virtual en la sección Requisitos de red virtual de Implementación de Azure Spring Apps en una red virtual.

Advertencia

El tamaño de subred seleccionado no puede superponerse con el espacio de direcciones de la red virtual existente, y no debe superponerse con ningún intervalo de direcciones de subred emparejada ni local.

Casos de uso

Los usos habituales de esta arquitectura incluyen:

  • Aplicaciones privadas: aplicaciones internas implementadas en entornos de nube híbrida
  • Aplicaciones públicas: aplicaciones orientadas al exterior

Estos casos de uso son similares, excepto en lo que refiere a la seguridad y las reglas de tráfico de red. Esta arquitectura está diseñada para admitir los matices de cada uno.

Aplicaciones privadas

En la lista siguiente se describen los requisitos de infraestructura para las aplicaciones privadas. Estos requisitos son habituales en entornos altamente regulados.

  • Una subred solo debe tener una instancia de Azure Spring Apps.
  • Debe cumplirse al menos una prueba comparativa de seguridad.
  • Los registros del servicio de nombres de dominio (DNS) del host de aplicación se deben almacenar en el DNS privado de Azure.
  • Las dependencias de los servicios de Azure se deben comunicar a través de puntos de conexión de servicio o Private Link.
  • Los datos en reposo deben estar cifrados.
  • Los datos en tránsito deben estar cifrados.
  • Se pueden usar canalizaciones de implementación de DevOps (por ejemplo, Azure DevOps) y requerir conectividad de red a Azure Spring Apps.
  • El tráfico de salida debe viajar a través de una aplicación virtual de red (NVA) central (por ejemplo, Azure Firewall).
  • Si se usa Config Server de Azure Spring Apps para cargar las propiedades de configuración desde un repositorio, el repositorio debe ser privado.
  • El enfoque de seguridad de Confianza cero de Microsoft requiere que los secretos, los certificados y las credenciales se conserven en un almacén seguro. El servicio recomendado es Azure Key Vault.
  • La resolución de nombres de hosts en el entorno local y en la nube debe ser bidireccional.
  • No hay una salida directa a la red pública de Internet, excepto por el tráfico del plano de control.
  • Los grupos de recursos administrados por la implementación de Azure Spring Apps no se deben modificar.
  • Las subredes administradas por la implementación de Azure Spring Apps no se deben modificar.

En la lista siguiente se muestran los componentes que componen el diseño:

  • Red local
    • Servicio de nombres de dominio (DNS)
    • Puerta de enlace
  • Suscripción al centro
    • Subred de Application Gateway
    • Subred de Azure Firewall
    • Subred de servicios compartidos
  • Suscripción conectada
    • Subred de Azure Bastion
    • Redes virtuales del mismo nivel

En la lista siguiente se describen los servicios de Azure en esta arquitectura de referencia:

  • Azure Key Vault: Servicio de administración de credenciales con respaldo de hardware, que tiene una estrecha integración con los servicios de identidad de Microsoft y los recursos de proceso.

  • Azure Monitor: Conjunto de servicios de supervisión global para aplicaciones que se implementan en Azure y en el entorno local.

  • Azure Pipelines: Servicio completo de integración continua y desarrollo continuo (CI/CD) que puede implementar automáticamente aplicaciones de Spring Boot actualizadas en Azure Spring Apps.

  • Microsoft Defender for Cloud: sistema unificado de protección contra amenazas y administración de seguridad para cargas de trabajo en entornos locales, varias nubes y Azure.

  • Azure Spring Apps: Servicio administrado diseñado y optimizado específicamente para aplicaciones de Spring Boot basadas en Java y aplicaciones de Steeltoe basadas en .NET.

En el diagrama siguiente se representa un diseño en estrella tipo hub-and-spoke bien estructurado que aborda los requisitos anteriores:

Aplicaciones públicas

En la lista siguiente se describen los requisitos de infraestructura para las aplicaciones públicas. Estos requisitos son habituales en entornos altamente regulados.

  • Una subred solo debe tener una instancia de Azure Spring Apps.
  • Debe cumplirse al menos una prueba comparativa de seguridad.
  • Los registros del servicio de nombres de dominio (DNS) del host de aplicación se deben almacenar en el DNS privado de Azure.
  • Azure DDoS Protection debe estar habilitado.
  • Las dependencias de los servicios de Azure se deben comunicar a través de puntos de conexión de servicio o Private Link.
  • Los datos en reposo deben estar cifrados.
  • Los datos en tránsito deben estar cifrados.
  • Se pueden usar canalizaciones de implementación de DevOps (por ejemplo, Azure DevOps) y requerir conectividad de red a Azure Spring Apps.
  • El tráfico de salida debe viajar a través de una aplicación virtual de red (NVA) central (por ejemplo, Azure Firewall).
  • El tráfico de entrada debe estar administrado por al menos Application Gateway o Azure Front Door.
  • Las direcciones enrutables a Internet deben almacenarse en el DNS público de Azure.
  • El enfoque de seguridad de Confianza cero de Microsoft requiere que los secretos, los certificados y las credenciales se conserven en un almacén seguro. El servicio recomendado es Azure Key Vault.
  • La resolución de nombres de hosts en el entorno local y en la nube debe ser bidireccional.
  • No hay una salida directa a la red pública de Internet, excepto por el tráfico del plano de control.
  • Los grupos de recursos administrados por la implementación de Azure Spring Apps no se deben modificar.
  • Las subredes administradas por la implementación de Azure Spring Apps no se deben modificar.

En la lista siguiente se muestran los componentes que componen el diseño:

  • Red local
    • Servicio de nombres de dominio (DNS)
    • Puerta de enlace
  • Suscripción al centro
    • Subred de Application Gateway
    • Subred de Azure Firewall
    • Subred de servicios compartidos
  • Suscripción conectada
    • Subred de Azure Bastion
    • Redes virtuales del mismo nivel

En la lista siguiente se describen los servicios de Azure en esta arquitectura de referencia:

  • Azure Application Firewall: Característica de Azure Application Gateway que proporciona a las aplicaciones una protección centralizada contra vulnerabilidades de seguridad comunes.

  • Azure Application Gateway: Equilibrador de carga responsable del tráfico de aplicaciones con la descarga de Seguridad de la capa de transporte (TLS) en el nivel 7.

  • Azure Key Vault: Servicio de administración de credenciales con respaldo de hardware, que tiene una estrecha integración con los servicios de identidad de Microsoft y los recursos de proceso.

  • Azure Monitor: Conjunto de servicios de supervisión global para aplicaciones que se implementan en Azure y en el entorno local.

  • Azure Pipelines: Servicio completo de integración continua y desarrollo continuo (CI/CD) que puede implementar automáticamente aplicaciones de Spring Boot actualizadas en Azure Spring Apps.

  • Microsoft Defender for Cloud: sistema unificado de protección contra amenazas y administración de seguridad para cargas de trabajo en entornos locales, varias nubes y Azure.

  • Azure Spring Apps: Servicio administrado diseñado y optimizado específicamente para aplicaciones de Spring Boot basadas en Java y aplicaciones de Steeltoe basadas en .NET.

En el diagrama siguiente se representa un diseño en estrella tipo hub-and-spoke bien estructurado que aborda los requisitos anteriores. Solo la red virtual del centro se comunica con Internet:

Conectividad local de Azure Spring Apps

Las aplicaciones de Azure Spring Apps pueden comunicarse con varios recursos locales, externos y de Azure. Mediante el diseño de concentrador y radio, las aplicaciones pueden enrutar el tráfico externamente o a la red local mediante ExpressRoute o una red privada virtual (VPN) de sitio a sitio.

Consideraciones sobre el Marco de buena arquitectura de Azure

El Marco de buena arquitectura de Azure es un conjunto de principios rectores que se deben seguir para establecer una base sólida para la infraestructura. El marco consta de las siguientes categorías: optimización de costos, excelencia operativa, eficiencia de rendimiento, confiabilidad y seguridad.

Optimización de costos

Debido a la naturaleza del diseño como sistema distribuido, la expansión de la infraestructura es una realidad. Esta realidad genera costos inesperados e incontrolables. Azure Spring Apps se ha creado con componentes que se escalan para poder satisfacer la demanda y optimizar el costo. El centro de esta arquitectura es Azure Kubernetes Service (AKS). El servicio está diseñado para reducir la complejidad y la sobrecarga operativa de la administración de Kubernetes, lo que incluye las eficiencias en el costo operativo del clúster.

Puede implementar diferentes aplicaciones y tipos de aplicación en una sola instancia de Azure Spring Apps. El servicio admite el escalado automático de aplicaciones desencadenado por métricas o programaciones que pueden mejorar el uso y la rentabilidad.

También puede usar Application Insights y Azure Monitor para reducir los costos operativos. Con la visibilidad proporcionada por la solución de registro completa, puede implementar la automatización para escalar los componentes del sistema en tiempo real. También puede analizar los datos de registro para revelar ineficiencias en el código de la aplicación, que se pueden abordar para mejorar el costo y el rendimiento generales del sistema.

Excelencia operativa

Azure Spring Apps aborda varios aspectos de la excelencia operativa. Puede combinar estos aspectos para asegurarse de que el servicio se ejecute de manera eficaz en entornos de producción, como se describe en la lista siguiente:

  • Puede usar Azure Pipelines para asegurarse de que las implementaciones sean confiables y coherentes, al tiempo que le ayuda a evitar errores humanos.
  • Puede usar Azure Monitor y Application Insights para almacenar datos de registro y de telemetría. Puede evaluar los datos recopilados de registros y de métricas para garantizar el mantenimiento y el rendimiento de las aplicaciones. La Supervisión de rendimiento de aplicaciones (APM) se encuentra totalmente integrada en el servicio a través de un agente de Java. Este agente proporciona visibilidad en todas las aplicaciones y dependencias implementadas sin necesidad de código adicional. Para obtener más información, consulte la entrada de blog sobre Supervisión sencilla de aplicaciones y dependencias en Azure Spring Apps.
  • Puede usar Microsoft Defender for Cloud para asegurarse de que las aplicaciones mantengan la seguridad; para ello puede brindar una plataforma para analizar y evaluar los datos proporcionados.
  • El servicio admite varios patrones de implementación. Para más información, consulte Configuración de un entorno de ensayo en Azure Spring Apps.

Confiabilidad

Azure Spring Apps se basa en AKS. Aunque AKS proporciona un nivel de resistencia mediante la agrupación en clústeres, esta arquitectura de referencia va más allá, ya que incorpora servicios y consideraciones arquitectónicas para aumentar la disponibilidad de la aplicación si se produce un error en el componente.

Al basarse en un diseño de concentrador y radio bien definido, la base de esta arquitectura garantiza que se puede implementar en varias regiones. En el caso de uso de las aplicaciones privadas, la arquitectura utiliza DNS privado de Azure para garantizar la disponibilidad continuada durante un error geográfico. Para el caso de uso de las aplicaciones públicas, Azure Front Door y Azure Application Gateway garantizan la disponibilidad.

Seguridad

La seguridad de esta arquitectura se aborda por su cumplimiento de los controles y pruebas comparativas definidos por el sector. En este contexto, «control» significa un procedimiento recomendado conciso y bien definido, como «Emplear el principio de privilegios mínimos al implementar el acceso al sistema de información». IAM-05" Los controles de esta arquitectura provienen de Cloud Controls Matrix (CCM) de Cloud Security Alliance (CSA) y Microsoft Azure Foundations Benchmark (MAFB) de Center for Internet Security (CIS). En los controles aplicados, el enfoque se centra en los principios de diseño de seguridad principales relativos a la gobernanza, las conexiones de red y seguridad de las aplicaciones. Es su responsabilidad administrar los principios de diseño de identidad, administración de acceso y almacenamiento, en la medida en que se relacionen con su infraestructura de destino.

Gobernanza

El aspecto principal de la gobernanza que aborda esta arquitectura es la segregación a través del aislamiento de los recursos de red. En CCM, DCS-08 recomienda el control de entrada y salida para el centro de datos. Para satisfacer el control, la arquitectura usa un diseño de concentrador y radio con grupos de seguridad de red (NSG) para filtrar el tráfico de Este a Oeste entre los recursos. La arquitectura también filtra el tráfico entre los servicios centrales en el concentrador y los recursos en el radio. La arquitectura usa una instancia de Azure Firewall para administrar el tráfico entre Internet y los recursos de la arquitectura.

En la siguiente lista se muestra el control que aborda la seguridad del centro de datos en esta referencia:

Id. de control de CCM de CSA Dominio de control de CCM de CSA
DCS-08 Seguridad del centro de datos: entrada de personas no autorizadas

Red

El diseño de red que admite esta arquitectura se obtiene del modelo tradicional de concentrador y radio. Esta decisión garantiza que el aislamiento de red sea una construcción fundamental. El control IV-06 de CCM recomienda que el tráfico entre las redes y las máquinas virtuales esté restringido y supervisado entre los entornos de confianza y los que no son de confianza. Esta arquitectura adopta el control mediante la implementación de los NSG para el tráfico de este a oeste (dentro del "centro de datos"), y Azure Firewall para el tráfico de norte a sur (fuera del "centro de datos"). El control IPY-04 de CCM recomienda que la infraestructura use protocolos de red seguros para el intercambio de datos entre servicios. Todos los servicios de Azure que admiten esta arquitectura usan protocolos seguros estándar, como TLS para HTTP y SQL.

En la siguiente lista se muestran los controles de CCM que abordan la seguridad de red en esta referencia:

Id. de control de CCM de CSA Dominio de control de CCM de CSA
IPY-04 Protocolos de red
IV-06 Seguridad de redes

Además, la implementación de red se protege mediante la definición de controles de MAFB. Los controles garantizan que el tráfico en el entorno esté restringido desde la red pública de Internet.

En la siguiente lista se muestran los controles de CIS que abordan la seguridad de red en esta referencia:

Id. de control de CIS Descripción del control de CIS
6.2 Asegúrese de que el acceso SSH está restringido desde Internet.
6.3 Asegúrese de que ninguna instancia de SQL Database permita la entrada 0.0.0.0/0 (cualquier IP).
6.5 Asegúrese de que Network Watcher esté "Habilitado".
6.6 Asegúrese de que la entrada mediante UDP esté restringida desde Internet.

Azure Spring Apps requiere tráfico de administración para la salida de Azure cuando se implementa en un entorno seguro. Debe permitir las reglas de red y de aplicación enumeradas en Responsabilidades del cliente para ejecutar Azure Spring Apps en una red virtual.

Seguridad de la aplicación

Este principio de diseño abarca los componentes fundamentales de identidad, protección de datos, administración de claves y configuración de aplicaciones. Por diseño, una aplicación implementada en Azure Spring Apps se ejecuta con los privilegios mínimos necesarios para funcionar. El conjunto de controles de autorización está directamente relacionado con la protección de datos cuando se usa el servicio. La administración de claves fortalece este enfoque de seguridad de aplicaciones por capas.

En la siguiente lista se muestran los controles de CCM que abordan la administración de claves en esta referencia:

Id. de control de CCM de CSA Dominio de control de CCM de CSA
EKM-01 Cifrado y administración de claves: derecho
EKM-02 Cifrado y administración de claves: generación de claves
EKM-03 Cifrado y administración de claves: protección de datos confidenciales
EKM-04 Cifrado y administración de claves: almacenamiento y acceso

A partir de CCM, EKM-02 y EKM-03 recomiendan las directivas y los procedimientos para administrar las claves y para usar los protocolos de cifrado para proteger los datos confidenciales. EKM-01 recomienda que todas las claves criptográficas tengan propietarios identificables para que puedan administrarse. EKM-04 recomienda el uso de algoritmos estándar.

En la siguiente lista se muestran los controles de CIS que abordan la administración de claves en esta referencia:

Id. de control de CIS Descripción del control de CIS
8.1 Asegúrese de que la fecha de expiración se haya establecido en todas las claves.
8,2 Asegúrese de que la fecha de expiración se haya establecido en todos los secretos.
8,4 Asegúrese de que el almacén de claves se pueda recuperar.

Los controles 8.1 y 8.2 de CIS recomiendan que se establezcan fechas de expiración para las credenciales con el fin de garantizar que se aplique la rotación. El control 8.4 de CIS garantiza que el contenido del almacén de claves se pueda restaurar para mantener la continuidad empresarial.

Los aspectos de seguridad de las aplicaciones establecen una base para el uso de esta arquitectura de referencia a los efectos de admitir una carga de trabajo de Spring en Azure.

Pasos siguientes

Explore esta arquitectura de referencia a través de las implementaciones ARM, Terraform y la CLI de Azure disponibles en el repositorio Arquitectura de referencia de Azure Spring Apps.