Editar

Compartir vía

Aplicaciones web administradas de forma segura

Azure App Service
Azure Application Gateway
Azure SQL Database
Azure VPN Gateway
Firewall de aplicaciones web de Azure

En este artículo se proporciona información general sobre la implementación de aplicaciones seguras con App Service Environment. Para restringir el acceso a la aplicación desde Internet, se usan el servicio de Azure Application Gateway y Azure Web Application Firewall. En este artículo también se proporcionan instrucciones sobre la integración y la implementación continuas (CI/CD) para instancias de App Service Environment mediante Azure DevOps.

Este escenario se implementa normalmente en sectores como banca y seguros, en los que los clientes son conscientes de la seguridad de nivel de plataforma, además de la seguridad de nivel de aplicación. Para demostrar estos conceptos, usaremos una aplicación que permita a los usuarios enviar informes de gastos.

Posibles casos de uso

Tenga en cuenta este escenario para los casos de uso siguientes:

  • Compilación de una aplicación web de Azure en la que se requiere seguridad adicional.
  • Provisión de inquilinos dedicados, en lugar de planes de App Service de inquilinos compartidos.
  • Uso de Azure DevOps con una instancia de Application Service Environment de carga equilibrada internamente (ILB).

Architecture

Diagrama que muestra la arquitectura del escenario de ejemplo para la implementación segura de App Service Environment de ILB.

Descargue un archivo Visio de esta arquitectura.

Flujo de datos

  1. Las solicitudes HTTP/HTTPS alcanzan primero Application Gateway.
  2. Opcionalmente (no se muestra en el diagrama), puede tener habilitada la autenticación de Microsoft Entra para la aplicación web. Después de que el tráfico llegue a Application Gateway, se solicitaría al usuario que proporcione credenciales para autenticarse con la aplicación.
  3. Las solicitudes de usuario fluyen a través del equilibrador de carga interno (ILB) del entorno, que a su vez redirige el tráfico a la aplicación web de gastos.
  4. A continuación, el usuario continúa con la creación de un informe de gastos.
  5. Como parte de la creación del informe de gastos, se invoca la aplicación de API implementada para recuperar el nombre de administrador y el correo electrónico del usuario.
  6. El informe de gastos creado se almacena en Azure SQL Database.
  7. Para facilitar la implementación continua, el código se registra en la instancia de Azure DevOps.
  8. La máquina virtual de compilación tiene instalado el agente de Azure DevOps, lo que permite que la máquina virtual de compilación extraiga los bits de la aplicación web que se va a implementar en App Service Environment (puesto que la máquina virtual de compilación se implementa en una subred dentro de la misma red virtual).

Componentes

  • App Service Environment proporciona un entorno completamente aislado y dedicado para la ejecución de la aplicación a gran escala de forma segura. Además, como App Service Environment y las cargas de trabajo que se ejecutan en él están detrás de una red virtual, también proporciona una capa adicional de seguridad y aislamiento. El requisito de gran escala y aislamiento produjeron la selección del App Service Environment de ILB.
  • Esta carga de trabajo usa el plan de tarifa de App Service aislado, por lo que la aplicación se ejecuta en un entorno dedicado privado en un centro de datos de Azure mediante procesadores más rápidos, almacenamiento en unidad de estado sólido (SSD) y el doble de relación entre memoria y núcleo en comparación con el estándar.
  • API de RESTful y aplicaciones web de host de aplicación web y aplicación de API de Azure App Service. Estas aplicaciones y API se hospedan en el plan de servicio aislado, que también ofrece escalado automático, dominios personalizados, etc., pero en un nivel dedicado.
  • Azure Application Gateway es un equilibrador de carga de tráfico web que funciona en el nivel 7 y administra el tráfico a la aplicación web. Ofrece descarga SSL, lo que elimina la sobrecarga adicional de los servidores web que hospedan la aplicación web para descifrar el tráfico de nuevo.
  • El Web Application Firewall es una característica de Application Gateway. La habilitación del firewall de aplicaciones web en la puerta de enlace de aplicaciones mejora aún más la seguridad. El firewall de aplicaciones web usa reglas de Open Worldwide Application Security Project (OWASP) para proteger la aplicación web frente a ataques como el scripting entre sitios, los secuestros de sesión y la inyección de SQL.
  • Se seleccionó Azure SQL Database porque la mayoría de los datos de esta aplicación son datos relacionales, con algunos datos como documentos y blobs.
  • Redes de Azure proporciona una variedad de funcionalidades de red en Azure, y las redes que se pueden emparejar con otras redes virtuales en Azure. También se pueden establecer conexiones con centros de datos locales a través de ExpressRoute o de sitio a sitio. En este caso, se habilita un punto de conexión de servicio en la red virtual para asegurarse de que los datos solo fluyen entre la red virtual de Azure y la instancia de SQL Database.
  • Azure DevOps se usa para ayudar a los equipos a colaborar durante sprints, mediante características que admiten Agile Development, así como para crear canalizaciones de versión y compilación.
  • Se creó una máquina virtual de compilación de Azure para que el agente instalado pueda desplegar la compilación correspondiente e implementar la aplicación web en el entorno.

Alternativas

App Service Environment puede ejecutar aplicaciones web normales en Windows o, como en este ejemplo, aplicaciones web implementadas dentro del entorno que se ejecutan como contenedores de Linux. App Service Environment se seleccionó para hospedar estas aplicaciones en contenedores de una sola instancia. Hay alternativas disponibles; revise las consideraciones siguientes al diseñar la solución.

  • Azure Service Fabric: Si el entorno está basado principalmente en Windows y las cargas de trabajo se basan principalmente en .NET Framework y aún no piensa en rediseñar .NET Core, use Service Fabric para admitir e implementar contenedores de Windows Server. Además, Service Fabric admite las API de programación de Java y C# y, para desarrollar microservicios nativos, los clústeres se pueden aprovisionar en Windows o Linux.
  • Azure Kubernetes Service (AKS) es un proyecto de código abierto y una plataforma de orquestación más adecuada para hospedar aplicaciones complejas de varios contenedores que normalmente usan una arquitectura basada en microservicios. AKS es un servicio administrado de Azure que abstrae las complejidades del aprovisionamiento y la configuración de un clúster de Kubernetes. Sin embargo, el conocimiento significativo de la plataforma de Kubernetes es necesario para admitirlo y mantenerlo, por lo que hospedar una serie de aplicaciones web en contenedores de una sola instancia puede no ser la mejor opción.

Otras opciones de la capa de datos incluyen:

  • Azure Cosmos DB: si la mayoría de los datos está en formato no relacional, Azure Cosmos DB es una buena alternativa. Este servicio proporciona una plataforma para ejecutar otros modelos de datos, como datos de Mongo DB, Cassandra, Graph o almacenamiento de tablas simple.

Consideraciones

Hay algunas consideraciones que deben tenerse en cuenta cuando se trabaja con certificados en App Service Environment de ILB. Debe generar un certificado que esté encadenado a una raíz de confianza sin necesidad de una solicitud de firma de certificado generada por el servidor donde finalmente se almacenará el certificado. Con Internet Information Services (IIS), por ejemplo, el primer paso es generar una solicitud de firma de certificado (CSR) desde el servidor IIS y enviarlo a la entidad emisora de certificados SSL.

No se puede emitir un CSR desde el equilibrador de carga interno (ILB) de una instancia de App Service Environment. La manera de sortear esta limitación consiste en usar el procedimiento comodín.

El procedimiento comodín le permite usar la prueba de la propiedad del nombre DNS en lugar de un CSR. Si posee un espacio de nombres DNS, puede colocar un registro TXT de DNS especial, el procedimiento comodín comprueba que el registro está allí y, si lo encuentra, sabe que posee el servidor DNS porque tiene el registro correcto. En función de esa información, emite un certificado que se ha registrado en una raíz de confianza, que puede cargar en el ILB. No es necesario hacer nada con los almacenes de certificados individuales en Web Apps porque tiene un certificado SSL raíz de confianza en el ILB.

Haga que el certificado SSL autofirmado o emitido internamente funcione si quiere realizar llamadas seguras entre los servicios que se ejecutan en un App Service Environment de ILB. Otra solución para considerar cómo hacer que App Service Environment de ILB funcione con el certificado SSL emitido internamente y cómo cargar la CA interna en el almacén raíz de confianza.

Al aprovisionar App Service Environment, tenga en cuenta las siguientes limitaciones al elegir un nombre de dominio para el entorno. Los nombres de dominio no pueden ser:

  • net
  • azurewebsites.net
  • p.azurewebsites.net
  • nameofthease.p.azurewebsites.net

Además, el nombre de dominio personalizado usado para las aplicaciones y el nombre de dominio que utiliza la instancia de App Service Environment de ILB no se pueden superponer. Para una instancia de App Service Environment de ILB con el nombre de dominio contoso.com, no puede usar nombres de dominio personalizados para aplicaciones como:

  • www.contoso.com
  • abcd.def.contoso.com
  • abcd.contoso.com

Elija un dominio para el App Service Environment de ILB que no tenga ningún conflicto con esos nombres de dominio personalizados. Puede usar algo como contoso-internal.com para el dominio de su entorno en este ejemplo, porque no entrará en conflicto con los nombres de dominio personalizados que terminan en .contoso.com.

Otro aspecto a tener en cuenta es DNS. Con el fin de permitir que las aplicaciones dentro del App Service Environment se comuniquen entre sí, por ejemplo, que una aplicación web se comunique con una API, debe tener configurado DNS para la red virtual que contiene el entorno. Puede traer su propio DNS o usar zonas privadas de Azure DNS.

Disponibilidad

Escalabilidad

Seguridad

Resistencia

Implementación de este escenario

Para implementar este escenario, siga este tutorial detallado que muestra cómo implementar manualmente cada componente. Seleccione App Service Environment v3 en lugar de v2, al seguir el tutorial. Este tutorial también proporciona una aplicación de ejemplo de .NET que ejecuta una aplicación simple de informes de gastos de Contoso.

Precios

Explore el costo de ejecutar este escenario. Se han preconfigurado todos los servicios en la calculadora de costos. Para ver cómo cambiarían los precios en su caso concreto, cambie las variables pertinentes para que coincidan con el tráfico esperado.

Hemos proporcionado tres ejemplos de perfiles de costo según la cantidad de tráfico que se espera obtener:

  • Pequeño: este ejemplo de precios representa los componentes necesarios para una instancia de nivel de producción mínimo que atiende a unos miles de usuarios al mes. La aplicación usa una sola instancia de una aplicación web estándar que será suficiente para habilitar el escalado automático. Cada uno de los demás componentes se escala a un nivel básico que minimizará el costo pero garantizará un soporte según el acuerdo de nivel de servicio (SLA) y suficiente capacidad para controlar una carga de trabajo de nivel de producción.
  • Mediano: representa los componentes necesarios para una implementación de tamaño moderado. En este caso, se calculan aproximadamente 100 000 usuarios en el transcurso de un mes. El tráfico esperado se controla con una instancia de App Service simple con un nivel estándar moderado. También se agregan a la calculadora los niveles moderados de Cognitive Services y Search Service.
  • Grande: representa una aplicación diseñada para operaciones a gran escala, con millones de usuarios al mes y movimientos de terabytes de datos. En este nivel de uso, se requieren aplicaciones web de alto rendimiento y de nivel premium implementadas en varias regiones y dirigidas por un administrador de tráfico. Los datos se conservan en diversos componentes: almacenamiento, bases de datos y CDN, y están configurados para alcanzar terabytes de tamaño.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

  • Faisal Mustafa | Ingeniero sénior de clientes

Pasos siguientes