Editar

Aplicación web redundante por zonas de alta disponibilidad de línea de base

Azure App Service
Azure Application Gateway
Azure Storage
Azure SQL Database
Azure Private Link
Azure Virtual Network
Azure Monitor

En este artículo se proporciona una arquitectura de base de referencia para ejecutar aplicaciones web en Azure App Service en una única región. Detalla las directrices para diseñar una aplicación web segura, con redundancia de zona y de alta disponibilidad en Azure. La arquitectura expone un punto de conexión público a través de Azure Application Gateway con Web Application Firewall. Enruta las solicitudes a Azure App Service a través de Private Link. La aplicación App Service utiliza la integración de red virtual y Private Link para comunicarse de forma segura con los servicios PaaS de Azure, como Azure Key Vault y Azure SQL Database.

Importante

Logotipo de GitHub La guía está respaldada por un ejemplo de implementación que muestra una implementación de base de referencia de App Service en Azure. Esta implementación se puede usar como base para el desarrollo de soluciones adicionales en el primer paso hacia la producción.

Arquitectura

Diagrama que muestra una arquitectura con base de referencia de App Service con redundancia de zonas y alta disponibilidad.

Figura 1: Arquitectura con base de referencia de Azure App Service

Descargue un archivo Visio de esta arquitectura.

Componentes

  • Microsoft Entra ID es un servicio de administración de identidades y accesos basado en la nube. Proporciona un único plano de control de identidades para administrar los permisos y roles de los usuarios que acceden a su aplicación web. Se integra con App Service y simplifica la autenticación y autorización para aplicaciones web.
  • Application Gateway es un equilibrador de carga y administrador de tráfico web de capa 7 (HTTP/S). Utiliza el enrutamiento basado en rutas URL para distribuir el tráfico entrante por zonas de disponibilidad y descarga el cifrado para mejorar el rendimiento de las aplicaciones.
  • Web Application Firewall (WAF) es un servicio nativo de la nube que protege las aplicaciones web de vulnerabilidad de seguridad comunes como SQL injection y scripting entre sitios. WAF proporciona visibilidad del tráfico hacia y desde su aplicación web, permitiéndole supervisar y proteger su aplicación.
  • App Service es una plataforma totalmente administrada para crear, implementar y escalar aplicaciones web.
  • Azure Key Vault es un servicio que almacena y administra de forma segura secretos, claves de cifrado y certificados. Centraliza la administración de la información confidencial.
  • Azure Monitor es un servicio de supervisión que recopila, analiza y actúa sobre los datos de telemetría en toda la implementación.
  • Azure virtual network es un servicio que permite crear redes virtuales privadas aisladas y seguras en Azure. Para una aplicación web en App Service, necesita una subred de red virtual para utilizar puntos de conexión privados para la comunicación segura de red entre recursos.
  • Private Link permite a los clientes acceder a los servicios de la plataforma Azure como servicio (PaaS) directamente desde redes virtuales privadas sin utilizar direcciones IP públicas.
  • Azure DNS es un servicio de hospedaje de dominios DNS que proporciona resolución de nombres utilizando la infraestructura de Microsoft Azure. Las zonas DNS privadas permiten asignar el nombre de dominio completo (FQDN) de un servicio a la dirección IP de un punto de conexión privado.
  • Azure SQL Database es un servicio de base de datos relacional administrado para datos relacionales.

Redes

La seguridad de la red es el núcleo de la arquitectura básica de App Services (ver Figura 2). Desde un alto nivel, la arquitectura de red garantiza lo siguiente:

  1. Un único punto de entrada seguro para el tráfico de clientes
  2. El tráfico de red se filtra
  3. Los datos en tránsito se cifran de extremo a extremo con TLS
  4. La filtración de datos se minimiza manteniendo el tráfico en Azure mediante el uso de Private Link
  5. Los recursos de red se agrupan y aíslan lógicamente entre sí mediante la segmentación de la red.

Flujos de red

Diagrama que muestra una arquitectura de red App Service de base de referencia.

Figura 2: Arquitectura de red de la línea de base de aplicación Azure App Service

A continuación se describen el flujo entrante de tráfico de Internet a la instancia de App Service y el flujo desde App Service a los servicios Azure.

Flujo entrante

  1. El usuario emite una solicitud a la IP pública del Application Gateway.
  2. Se evalúan las reglas de WAF. Las reglas WAF afectan positivamente a la fiabilidad del sistema protegiéndolo contra varios ataques, como scripting entre sitios (XSS) e inyección SQL. Azure Application Gateway devuelve un error al solicitante si se infringe una regla WAF y el procesamiento se detiene. Si no se infringe ninguna regla WAF, Application Gateway enruta la solicitud al grupo de back-end, que en este caso es el dominio predeterminado de App Service.
  3. La zona DNS privada privatelink.azurewebsites.net está vinculada a la red virtual. La zona DNS tiene un registro A que asigna el dominio predeterminado de App Service a la dirección IP privada del punto de conexión privado de App Service. Esta zona DNS privada vinculada permite a Azure DNS resolver el dominio predeterminado a la dirección IP del punto de conexión privado.
  4. La solicitud se enruta a una instancia de App Service a través del punto de conexión privado.

Flujo de servicios de App Service a Azure PaaS

  1. App Service realiza una solicitud al nombre DNS del servicio Azure requerido. La solicitud podría ser a Azure Key Vault para obtener un secreto, Azure Storage para obtener un archivo zip de publicación, Azure SQL Database o cualquier otro servicio Azure que admita Private Link. La función de integración de red virtual de App Service enruta la solicitud a través de la red virtual.
  2. Al igual que en el paso 3 del flujo de entrada, la zona DNS privada vinculada tiene un registro A que asigna el dominio del servicio Azure a la dirección IP privada del punto de conexión privado. Una vez más, esta zona DNS privada vinculada permite a Azure DNS resolver el dominio a la dirección IP del punto de conexión privado del servicio.
  3. La solicitud se enruta al servicio a través del punto de conexión privado.

Entrada a App Services

Application Gateway es un recurso regional que cumple los requisitos de esta arquitectura de línea de base. Application Gateway es un equilibrador de carga de capa 7 regional y escalable que admite funciones como el firewall de aplicaciones Web y la descarga TLS. Tenga en cuenta los puntos siguientes al implementar Application Gateway para la entrada a Azure App Services.

  • Implemente Application Gateway y configure una directiva WAF con un conjunto de reglas administrado por Microsoft. Use el modo de prevención para mitigar los ataques web que puedan provocar que un servicio de origen (App Service en la arquitectura) deje de estar disponible.
  • Implementar encriptación TLS de un extremo a otro.
  • Utilice puntos de conexión privados para implementar el acceso privado entrante a su App Service.
  • Considere la posibilidad de implementar el escalado automático para que Application Gateway se ajuste fácilmente a los flujos de tráfico dinámicos.
  • Considere la posibilidad de utilizar un número mínimo de instancias de escalado no inferior a tres y utilice siempre todas las zonas de disponibilidad que admita su región. Aunque Application Gateway se implementa de forma altamente disponible, incluso para una única instancia de escalado, la creación de una nueva instancia tras un error puede tardar hasta siete minutos. La implementación de varias instancias en zonas de disponibilidad ayuda a garantizar que, en caso de error, se ejecute una instancia mientras se crea una nueva.
  • Deshabilitar el acceso a la red pública en el App Service para garantizar el aislamiento de la red. En Bicep, esto se consigue mediante la configuración publicNetworkAccess: 'Disabled' en properties/siteConfig.

Flujo desde App Services a servicios Azure

Esta arquitectura utiliza integración de red virtual para el App Service, específicamente para enrutar el tráfico a puntos de conexión privados a través de la red virtual. La arquitectura básica no habilita enrutamiento de todo el tráfico para forzar todo el tráfico saliente a través de la red virtual, solo el tráfico interno, como el tráfico destinado a puntos de conexión privados.

Los servicios Azure que no requieren acceso desde la Internet pública deben tener habilitados los puntos de conexión privados y deshabilitados los puntos de conexión públicos. Los puntos de conexión privados se utilizan en toda esta arquitectura para mejorar la seguridad al permitir que su servicio de aplicaciones se conecte a los servicios de Private Link directamente desde su red virtual privada sin utilizar direcciones IP públicas.

En esta arquitectura, Azure SQL Database, Azure Storage y Key Vault tienen deshabilitados los puntos de conexión públicos. Los firewalls de servicio de Azure solo se usan para permitir el tráfico de otros servicios autorizados de Azure. Debería configurar otros servicios Azure con puntos de conexión privados, como Azure Cosmos DB y Azure Redis Cache. En esta arquitectura, Azure Monitor no utiliza un punto de conexión privado, pero podría hacerlo.

La arquitectura de línea de base implementa una zona DNS privada para cada servicio. La zona DNS privada contiene un registro A que asigna el nombre de dominio completo del servicio a la dirección IP privada del punto de conexión privado. Las zonas están vinculadas a la red virtual. Los grupos de zonas DNS privadas garantizan que los registros DNS de vínculo privado se creen y actualicen automáticamente.

Tenga en cuenta los siguientes puntos al implementar la integración de redes virtuales y puntos de conexión privados.

Segmentación y seguridad de la red virtual

La red en esta arquitectura tiene subredes separadas para el Application Gateway, los componentes de integración del App Service y los puntos de conexión privados. Cada subred tiene un grupo de seguridad de red que limita el tráfico entrante y saliente de esas subredes a lo estrictamente necesario. La siguiente tabla muestra una vista simplificada de las reglas NSG que la línea de base añade a cada subred. La tabla indica el nombre de la regla y su función.

Subnet Entrada Salida
snet-AppGateway AppGw.In.Allow.ControlPlane: permitir acceso entrante al plano de control

AppGw.In.Allow443.Internet: permitir acceso HTTPS entrante a Internet		 AppGw.Out.Allow.AppServices: permitir acceso saliente a AppServicesSubnet

AppGw.Out.Allow.PrivateEndpoints: permitir acceso saliente a PrivateEndpointsSubnet

AppPlan.Out.Allow.AzureMonitor: permitir acceso saliente a Azure Monitor
snet-PrivateEndpoints Reglas predeterminadas: permitir entrada desde red virtual Reglas predeterminadas: permitir salida a red virtual
snet-AppService Reglas predeterminadas: permitir entrada desde red virtual AppPlan.Out.Allow.PrivateEndpoints: permitir acceso saliente a PrivateEndpointsSubnet

AppPlan.Out.Allow.AzureMonitor: permitir acceso saliente a Azure Monitor

Tenga en cuenta los siguientes puntos al implementar la segmentación y seguridad de la red virtual.

  • Habilite Protección contra DDoS para la red virtual con una subred que forme parte de una pasarela de aplicaciones con una IP pública.
  • Añada una NSG a cada subred siempre que sea posible. Debe utilizar las reglas más estrictas que permitan la funcionalidad completa de la solución.
  • Utilice grupos de seguridad de aplicaciones. Los grupos de seguridad de aplicaciones permiten agrupar las NSG, lo que facilita la creación de reglas para entornos complejos.

Un ejemplo de un esquema de subred virtual podría ser:

Tipo Nombre Intervalo de direcciones
Virtual Network Prefijo de dirección 10.0.0.0/16
Subnet GatewaySubnet 10.0.1.0/24
Subnet AppServicesSubnet 10.0.0.0/24
Subnet PrivateEndpointsSubnet 10.0.2.0/27
Subnet AgentsSubject 10.0.2.32/27

Referencia Azure-Samples\app-service-baseline-implementation

Confiabilidad

La arquitectura de línea base de App Services se centra en la redundancia zonal para los servicios regionales clave. Las zonas de disponibilidad son ubicaciones físicamente separadas dentro de una región. Proporcionan redundancia zonal para servicios de soporte cuando se implementan dos o más instancias en regiones de soporte. Cuando una zona experimenta un tiempo de inactividad, las otras zonas pueden no verse afectadas.

La arquitectura también garantiza suficientes instancias de los servicios Azure para satisfacer la demanda. Las siguientes secciones proporcionan orientación sobre la fiabilidad de los servicios clave de la arquitectura. De este modo, las zonas de disponibilidad le ayudan a conseguir fiabilidad proporcionando alta disponibilidad y tolerancia a errores.

Application Gateway

Implementa Azure Application Gateway v2 en una configuración de zona redundante. Considera la posibilidad de utilizar un recuento de instancias de escala mínima no inferior a tres para evitar el tiempo de inicio de seis a siete minutos para una instancia de Application Gateway si se produce un error.

Servicios de aplicaciones

  • Implementa un mínimo de tres instancias de App Services con compatibilidad de zona de disponibilidad.
  • Implemente puntos de conexión de comprobación de estado en las aplicaciones y configure la característica de comprobación de estado de App Service para volver a enrutar las solicitudes de las instancias incorrectas. Para obtener más información sobre la comprobación de App Service Health, consulte Supervisión de instancias de App Service mediante la comprobación de estado. Para obtener más información sobre la implementación de puntos de conexión de comprobación de estado en aplicaciones ASP.NET, consulte Comprobaciones de estado en ASP.NET Core.
  • Sobreaprovisiona la capacidad para poder solucionar los errores de zona.

SQL Database

  • Implementa las versiones De uso general, Premium o Crítico para la empresa de la base de datos de Azure SQL con redundancia de zona habilitada. Los niveles General Purpose, Premium y Business Critical admiten redundancia de zonas en Azure SQL DB.
  • Configura las copias de seguridad de SQL DB para utilizar el almacenamiento redundante en zonas (ZRS) o el almacenamiento de redundancia de zonas geográficas (GZRS).

Blob Storage

  • Azure Zone-Redundant Storage (ZRS) replica sus datos de forma sincrónica en tres zonas de disponibilidad de la región. Crea cuentas de almacenamiento de ZRS estándar o GZRS estándar para garantizar que los datos se replican entre zonas de disponibilidad.
  • Crea cuentas de almacenamiento separadas para implementaciones, activos web y otros datos, de modo que pueda administrar y configurar las cuentas por separado.

Escalabilidad

La escalabilidad permite que las aplicaciones gestionen aumentos y disminuciones de la demanda al tiempo que optimizan el rendimiento y el coste. En las secciones siguientes se analiza la escalabilidad de los componentes clave de esta arquitectura.

Application Gateway

  • Implemente el escalado automático para Application Gateway escalar o reducir horizontalmente para satisfacer la demanda.
  • Establezca el recuento máximo de instancias en un número superior a sus necesidades previstas. Solo se le cobrarán las unidades de capacidad que utilice.
  • Establezca un número mínimo de instancias que pueda gestionar pequeños picos de tráfico. Puede utilizar el uso medio de Unidades de proceso para calcular su número mínimo de instancias.
  • Siga la guía de dimensionamiento de la subred de Application Gateway.

App Service

SQL Server

El escalado de recursos de base de datos es un tema complejo que queda fuera del alcance de esta arquitectura. Tenga en cuenta los siguientes recursos a la hora de escalar su base de datos,

Otros consejos sobre escalabilidad

  • Revise los límites y las cuotas de la suscripción para garantizar que los servicios se adapten a la demanda.
  • Considere el almacenamiento en caché de los siguientes tipos de datos para aumentar el rendimiento y la escalabilidad:
    • Datos de transacción parcialmente estáticos
    • Estado de sesión
    • Salida HTML Esto puede ser útil en aplicaciones que representan la salida HTML compleja.

Seguridad

La arquitectura de línea de base de App Service se centra en recomendaciones de seguridad esenciales para su aplicación web. Comprender cómo funcionan el cifrado y la identidad en cada capa es fundamental para proteger su carga de trabajo.

App Service

  • Desactiva los métodos de autenticación local para las implementaciones de sitios FTP y SCM.
  • Desactiva la depuración remota.
  • Utiliza la última versión de TLS.
  • Habilita Microsoft Defender para App Service.
  • Use las versiones más recientes de las plataformas compatibles, los lenguajes de programación, los protocolos y los marcos.
  • Considere Entorno de App Service si necesita un mayor aislamiento o un acceso seguro a la red.

Cifrado

Una aplicación web de producción necesita cifrar los datos en tránsito utilizando HTTPS. El protocolo HTTPS se basa en Transport Layer Security (TLS) y utiliza claves públicas y privadas para el cifrado. Debe almacenar un certificado (X.509) en Key Vault y dar permiso a Application Gateway para recuperar la clave privada. Para los datos en reposo, algunos servicios cifran los datos automáticamente y otros permiten personalizarlos.

Datos en tránsito

En la arquitectura de línea de base los datos en tránsito se cifran desde el usuario hasta la aplicación web en App Service. Este flujo de trabajo describe cómo funciona el cifrado a alto nivel.

Diagrama que muestra un flujo de cifrado de App Service de línea de base.

  1. El usuario envía una solicitud HTTPS a la aplicación web.
  2. La solicitud HTTPS llega a la puerta de enlace de la aplicación.
  3. La puerta de enlace de aplicaciones utiliza un certificado (X.509) en Key Vault para crear una conexión TLS segura con el navegador web del usuario. La puerta de enlace de aplicaciones descifra la solicitud HTTPS para que el firewall de aplicaciones web pueda inspeccionarla.
  4. La puerta de enlace de la aplicación crea una conexión TLS con App Service para volver a cifrar la solicitud del usuario. App Service ofrece compatibilidad nativa con HTTPS, por lo que no es necesario agregar un certificado a App Service. La puerta de enlace de aplicaciones envía el tráfico cifrado a App Service. App Service descifra el tráfico y la aplicación Web procesa la solicitud.

Tenga en cuenta las siguientes recomendaciones a la hora de configurar el cifrado de datos en tránsito.

Datos en reposo

  • Cifrar datos confidenciales en Azure SQL Database mediante cifrado de datos transparente. Los datos transparentes cifran toda la base de datos, las copias de seguridad y los archivos de registro de transacciones y no requieren cambios en su aplicación web.
  • Minimizar la latencia del cifrado de la base de datos. Para minimizar la latencia del cifrado, coloque los datos que necesita proteger en su propia base de datos y active el cifrado solo para esa base de datos.
  • Comprende el soporte de cifrado integrado. Azure Storage cifra automáticamente los datos en reposo mediante cifrado del lado del servidor (AES de 256 bits). Azure Monitor cifra automáticamente los datos en reposo mediante claves administradas por Microsoft (MMK).

Administración de identidades y acceso

La línea de base de App Service configura la autenticación y autorización para identidades de usuario (usuarios) e identidades de carga de trabajo (recursos Azure) e implementa el principio de mínimo privilegio.

Identidades de usuarios

  • Utiliza el mecanismo de autenticación integrado para App Service ("EasyAuth"). EasyAuth simplifica el proceso de integración de proveedores de identidad en su aplicación web. Gestiona la autenticación fuera de su aplicación web, por lo que no tiene que realizar cambios significativos en el código.
  • Configura la URL de respuesta para el dominio personalizado. Debe redirigir la aplicación web a https://<application-gateway-endpoint>/.auth/login/<provider>/callback. Reemplace <application-gateway-endpoint> por la dirección IP pública o el nombre de dominio personalizado asociado con la puerta de enlace de su aplicación. Reemplace <provider> por el proveedor de autenticación que esté usando, como "aad" para Microsoft Entra ID. Puede utilizar la documentación de Azure Front para configurar este flujo con Application Gateway o Configuración de Application Gateway.

Identidades de cargas de trabajo

  • Utiliza identidad gestionada para las identidades de carga de trabajo. La identidad administrada elimina la necesidad de que los desarrolladores administren las credenciales de autenticación.
  • Utiliza identidades gestionadas asignadas por el usuario. Una identidad asignada por el sistema puede hacer que las implementaciones de infraestructura como código no funcionen debido a las condiciones de carrera y al orden de las operaciones. Puede utilizar identidades gestionadas asignadas por el usuario para evitar algunas de estas situaciones de error de implementación. Para más información, consulte Identidades administradas.

Implementación

La implementación de la aplicación App Service de referencia sigue las directrices de CI/CD para Azure Web Apps con Azure Pipelines. Además de esa orientación, la arquitectura de referencia de App Services tiene en cuenta que la aplicación y la cuenta de almacenamiento de implementación están protegidas por la red. La arquitectura deniega el acceso público a App Service. Esto significa que no se puede implementar desde fuera de la red virtual. La línea de base muestra cómo implementar el código de la aplicación dentro de la red virtual mediante agentes de implementación autoalojados. La siguiente guía de implementación se centra en la implementación del código de la aplicación y no en la implementación de cambios en la infraestructura o la base de datos.

Diagrama que muestra una arquitectura de implementación básica de App Service.

Figura 3: Implementación de aplicaciones Azure App Service

Flujo de implementación

  1. Como parte de la canalización de lanzamiento, la canalización publica una solicitud de trabajo para los agentes autohospedados en la cola de trabajos. La solicitud de trabajo es para que el agente cargue el archivo zip de publicación artefacto de compilación en una cuenta de almacenamiento de Azure.

  2. El agente de implementación autohospedado recoge la nueva solicitud de trabajo mediante sondeo. Descarga el trabajo y el artefacto de compilación.

  3. El agente de implementación autohospedado carga el archivo zip en la cuenta de almacenamiento mediante el punto de conexión privado de la cuenta de almacenamiento.

  4. La canalización continúa y un agente administrado recoge un trabajo posterior. El agente administrado realiza una llamada CLI para actualizar el appSetting WEBSITE_RUN_FROM_PACKAGE con el nombre del nuevo archivo zip de publicación para el espacio de ensayo.

    az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip

  5. Azure App Service extrae el nuevo archivo zip de publicación del almacenamiento a través del punto de conexión privado de la cuenta de almacenamiento. La instancia de puesta en escena se reinicia con el nuevo paquete porque WEBSITE_RUN_FROM_PACKAGE se configuró con un nombre de archivo diferente.

  6. La canalización se reanuda y ejecuta cualquier prueba de aceptación de la compilación o espera la aprobación. Si se superan las pruebas o se obtiene aprobación, la canalización intercambia los espacios de montaje y producción.

Guía para la implementación

A continuación se destacan las principales directrices de implementación para la arquitectura de referencia.

  • Utilice la opción Ejecutar desde un paquete para evitar conflictos entre las implementaciones. Cuando ejecuta su aplicación directamente desde un paquete en Azure App Service, los archivos del paquete no se copian en el directorio wwwroot. En su lugar, el propio paquete ZIP se monta directamente como directorio wwwroot de solo lectura. Esto elimina los conflictos de bloqueo de archivos entre la implementación y el tiempo de ejecución y garantiza que solo se ejecuten aplicaciones completamente implementadas en cualquier momento.
  • Incluya números de versión en los archivos zip del paquete implementado. La actualización del WEBSITE_RUN_FROM_PACKAGE appSetting en el paquete de implementación con un nombre de archivo diferente hace que App Services recoja automáticamente la nueva versión y reinicie el servicio.
  • Utilice las ranuras de implementación para realizar implementaciones de código resistentes.
  • Considere la posibilidad de utilizar una combinación de agentes administrados y autohospedados.
  • Automatice la implementación de la infraestructura con Infrastructure as Code (IaC).
  • Valide continuamente la carga de trabajo para probar el rendimiento y la resistencia de toda la solución mediante servicios como Azure Load Testing y Azure Chaos Studio.

Configuración

Las aplicaciones requieren tanto valores de configuración como secretos. Utilice la siguiente guía para la administración de configuraciones y secretos.

  • Nunca compruebe secretos como contraseñas o claves de acceso en el control de código fuente.
  • Utilice Azure Key Vault para almacenar secretos.
  • Utilice Configuración de App Service para la configuración de su aplicación. Si necesita externalizar la configuración desde la configuración de su aplicación o necesita compatibilidad con indicadores de funciones, considere la posibilidad de utilizar Azure App Configuration.
  • Utilice referencias a Key Vault en la configuración de App Service para exponer secretos de forma segura en su aplicación.
  • Cree configuraciones de aplicaciones que se mantengan en un espacio y no se intercambien si necesita diferentes configuraciones de producción y puesta en escena. Cuando intercambia una ranura de implementación, los valores de configuración de la aplicación se intercambian de forma predeterminada.
  • Establezca variables de entorno locales para el desarrollo local o aproveche las funciones de la plataforma de aplicaciones. La configuración de App Services expone los ajustes de la aplicación como variables de entorno. Visual Studio, por ejemplo, permite establecer variables de entorno en perfiles de lanzamiento. También permite utilizar App Settings y secretos de usuario para almacenar la configuración y los secretos locales de la aplicación.

Supervisión

La supervisión es la recopilación y el análisis de datos de los sistemas informáticos. El objetivo de la supervisión es la observabilidad en múltiples capas para realizar un seguimiento del estado y la seguridad de las aplicaciones web. La observabilidad es una faceta clave de la arquitectura básica de App Service.

Para supervisar su aplicación web, debe recopilar y analizar métricas y registros del código de la aplicación, la infraestructura (tiempo de ejecución) y la plataforma (recursos Azure). Para más información, consulte Registro de actividad de Azure, Registros de recursos de Azure y registros de aplicaciones.

Supervisar la plataforma

La supervisión de la plataforma es la recopilación de datos de los servicios Azure en su arquitectura. Tenga en cuenta la siguiente orientación en relación con la supervisión de la plataforma.

Application Gateway

Application Gateway supervisa el estado de los recursos de su grupo backend. Utilice los registros de acceso de Application Gateway para obtener información como la marca de tiempo, el código de respuesta HTTP y la ruta de acceso de la dirección URL. Para más información, consulte Sonda de estado predeterminada de Application Gateway y Registros de diagnóstico y estado de backend.

App Service

App Service cuenta con herramientas de supervisión integradas que debería activar para mejorar la capacidad de observación. Si su aplicación web ya dispone de funciones de telemetría y supervisión ("instrumentación en proceso"), debería seguir funcionando en App Service.

  • Habilite la autoinstrumentación. App Service tiene una extensión de instrumentación que puede activar sin cambios en el código. Obtendrá visibilidad de la supervisión del rendimiento de las aplicaciones (APM). Para más información, consulte Supervisar el rendimiento de Azure App Service.
  • Habilite el seguimiento distribuido. La instrumentación automática ofrece una forma de supervisar los sistemas distribuidos en la nube a través del seguimiento distribuido y un perfilador de rendimiento.
  • Utilice instrumentación basada en código para telemetría personalizada. Azure Application Insights también admite la instrumentación basada en código para la telemetría de aplicaciones personalizadas. Añada el SDK de Application Insights a su código y utilice la API de Application Insights.
  • Habilitar registros de App Service. La plataforma App Service admite cuatro registros adicionales que debería habilitar para ayudar a la resolución de problemas. Estos registros son registros de aplicaciones, registros de servidores web, mensajes de error detallados y seguimiento de solicitudes fallidas.
  • Utilice registros estructurados. Añada una biblioteca de registro estructurado al código de su aplicación. Actualice su código para usar pares clave-valor y habilite Registros de aplicaciones en App Service para almacenar estos registros en su área de trabajo de Log Analytics.
  • Active la comprobación de estado de App Service. La comprobación del estado redirige las solicitudes lejos de las instancias incorrectas y sustituye las instancias incorrectas. Su plan de App Service debe utilizar dos o más instancias para que funcionen las comprobaciones de estado.

Base de datos

  • Base de datos de usuario Insights. Para las bases de datos Azure SQL, debe configurar SQL Insights en Azure Monitor. Database Insights utiliza vistas de administración dinámicas para exponer los datos que necesita para supervisar el estado, diagnosticar problemas y ajustar el rendimiento. Para más información, consulte Supervisión de Azure SQL Database con Azure Monitor.
  • Si la arquitectura incluye Cosmos DB, no es necesario habilitar ni configurar nada para utilizar Cosmos DB insights.

Gobernanza

Las aplicaciones web se benefician de Azure Policy al imponer decisiones arquitectónicas y de seguridad. Azure Policy puede hacer (1) imposible la implementación (denegación) o (2) fácil de detectar (auditoría) el desfase de la configuración del estado deseado. Esto le ayuda a detectar implementaciones de Infraestructura como código (IaC) o cambios en Azure Portal que se desvían de la arquitectura acordada. Debe colocar todos los recursos de su arquitectura en la gobernanza de las directivas de Azure. Use directivas integradas o iniciativas de directivas siempre que sea posible para hacer cumplir la topología de red esencial, la característica de servicio, la seguridad y las decisiones de supervisión, por ejemplo las siguientes:

  • App Service debe deshabilitar el acceso a la red pública
  • App Service debe utilizar integración de red virtual
  • App Service debe usar Azure Private Link para conectarse a los servicios PaaS
  • App Service debe tener desactivados los métodos de autenticación local para las implementaciones de sitios FTP y SCM
  • App Service debe tener desactivada la depuración remota
  • Las aplicaciones de App Service deben usar la última versión de TLS
  • Se debe habilitar Microsoft Defender para App Service
  • El firewall de aplicaciones web (WAF) debe estar habilitado para Application Gateway

Consulte más directivas integradas para servicios clave como Application Gateway y componentes de red, App Service, Key Vault y Supervisión. Es posible crear directivas personalizadas o utilizar directivas comunitarias (como las zona de aterrizaje de Azure) si las directivas integradas no cubren totalmente sus necesidades. Prefiera las directivas integradas cuando estén disponibles.

Pasos siguientes

Leer Aplicación web multirregión de alta disponibilidad