Implementación empresarial mediante Azure App Service Environment

Azure Active Directory
Application Gateway
App Service
Firewall
Virtual Network

Esta arquitectura de referencia muestra una carga de trabajo empresarial común con App Service Environment (ASE) y procedimientos recomendados para reforzar la seguridad de esta carga de trabajo.

GitHub logoHay disponible una implementación de referencia de esta arquitectura en GitHub.

Architecture

Diagrama que muestra la arquitectura de la implementación de App Service Environment estándar.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

El componente principal de esta arquitectura es el entorno de App Service. Un ASE se puede implementar como ASE externo con una dirección IP pública, o bien como ASE interno con una dirección IP interna que pertenece al equilibrador de carga interno (ILB) . Esta arquitectura de referencia implementa una aplicación web empresarial en un ASE interno, también denominado ASE de ILB. Use un ASE de ILB cuando su escenario requiera:

  • Hospedar aplicaciones de intranet de forma segura en la nube a las que se accede a través de una conexión de sitio a sitio o ExpressRoute
  • Proteger aplicaciones con un dispositivo WAF
  • Hospedar aplicaciones en la nube que no se muestran en los servidores DNS públicos.
  • Crear aplicaciones de back-end aisladas de Internet con las que pueden integrarse de forma segura sus aplicaciones de front-end.

Un ASE siempre debe implementarse en su propia subred dentro de la red virtual de la empresa, lo que permite un control estricto del tráfico entrante y saliente. Dentro de esta subred, las aplicaciones de App Service se implementan en uno o varios planes de App Service, que son una colección de recursos físicos necesarios para ejecutar la aplicación. En función de la complejidad y los requisitos de recursos, se puede compartir un plan de App Service entre varias aplicaciones. Esta implementación de referencia implementa una aplicación web denominada Aplicación de votación, que interactúa con una API web privada y una función. También implementa una aplicación web ficticia denominada Aplicación de prueba para demostrar implementaciones de varias aplicaciones. Cada aplicación de App Service se hospeda en su propio plan de App Service, lo que permite escalar cada una de ellas de forma independiente si es necesario. Todos los recursos necesarios para estas aplicaciones hospedadas, como el almacenamiento y el proceso, así como las necesidades de escalado, están totalmente administrados por la infraestructura de App Service Environment.

La aplicación de votación sencilla de esta implementación permite a los usuarios ver las entradas existentes o crear otras, así como votar sobre las entradas existentes. La API web se usa para crear y recuperar entradas y votos. Los propios datos se almacenan en una base de datos de SQL Server. Para mostrar las actualizaciones de datos asincrónicas, la aplicación web pone en cola los votos recién agregados en una instancia de Service Bus. La función selecciona los votos en cola y actualiza la base de datos SQL. Azure Cosmos DB se usa para almacenar un boceto de anuncio que la aplicación web recupera para que se muestre en el explorador. La aplicación usa Azure Cache for Redis para la administración de la memoria caché. Se usa el nivel Prémium de Azure Cache for Redis, que permite la configuración en la misma red virtual que el ASE, en su propia subred. Esto proporciona una seguridad y un aislamiento mejorados a la memoria caché.

Las aplicaciones web son los únicos componentes accesibles a través de Internet mediante App Gateway. No se puede obtener acceso a la API ni a la función desde un cliente de Internet. El tráfico entrante está protegido por un firewall de aplicaciones web configurado en App Gateway.

Componentes

Los siguientes servicios son fundamentales para bloquear el ASE en esta arquitectura:

Azure Virtual Network o VNet es una red privada en la nube de Azure que pertenece a la empresa. Proporciona seguridad y aislamiento basados en red. ASE es una implementación de App Service en una subred de la red virtual propiedad de la empresa. Permite a la empresa controlar de forma estricta el espacio de red y los recursos a los que accede, mediante grupos de seguridad de red y puntos de conexión de servicio.

Application Gateway es un equilibrador de carga de tráfico web de nivel de aplicación, con descarga TLS/SSL y protección del firewall de aplicaciones web (WAF). Escucha en una dirección IP pública y enruta el tráfico al punto de conexión de la aplicación en el ASE de ILB. Como se trata de un enrutamiento de nivel de aplicación, puede enrutar el tráfico a varias aplicaciones en el mismo ASE de ILB. Vea Hospedaje de varios sitios de Application Gateway para obtener información sobre cómo App Gateway es compatible con varios sitios.

Azure Firewall se utiliza para restringir el tráfico saliente de la aplicación web. El tráfico saliente que no atraviesa los canales de punto de conexión de servicio y una tabla de rutas requerida por ASE se dirige a la subred de firewall. Aunque se recomienda que los puntos de conexión de servicio se configuren en la subred de firewall para la rastreabilidad, puede que no siempre sea factible. Por ejemplo, algunos puntos de conexión de servicio son necesarios para que la infraestructura de ASE esté en la subred de ASE. Para simplificar, esta arquitectura configura todos los puntos de conexión de servicio en la subred de ASE.

Azure Active Directory o Azure AD proporciona derechos de acceso y administración de permisos a los recursos y servicios de Azure. Las Identidades administradas asignan identidades a servicios y aplicaciones, administrados automáticamente por Azure AD. Estas identidades se pueden usar para autenticarse en cualquier servicio que admita la autenticación de Azure AD. Esto elimina la necesidad de configurar explícitamente las credenciales para estas aplicaciones. Esta arquitectura asigna una identidad administrada a la aplicación web.

Key Vault almacena cualquier secreto y credencial que las aplicaciones necesiten. Use esta opción para almacenar secretos directamente en la aplicación.

Azure Pipelines proporciona funcionalidades de integración continua e implementación continua en esta arquitectura. Puesto que el ASE es interno de la red virtual, una máquina virtual se usa como un jumpbox dentro de la red virtual para implementar aplicaciones en los planes de App Service. La canalización compila las aplicaciones fuera de la red virtual. Para mejorar la seguridad y la conectividad de RDP/SSH sin problemas, considere la posibilidad de usar el servicio Azure Bastion lanzado recientemente como el jumpbox.

Configuración multisitio

Diagrama que muestra la implementación multisitio.

Descargue un archivo de Visio de este diagrama.

El ASE interno puede hospedar varias aplicaciones web y API con puntos de conexión HTTP. Estas aplicaciones se bloquean desde la red pública de Internet, ya que solo se puede acceder a la dirección IP de ILB desde dentro de la red virtual. Application Gateway se usa para exponer selectivamente estas aplicaciones a Internet. ASE asigna una dirección URL predeterminada a cada aplicación de App Service como <default-appName>.<ASE-domain>.appserviceenvironment.net. Se crea una zona DNS privada que asigna el nombre de dominio de ASE a la dirección IP del ILB de ASE. Esto evita el uso de un DNS personalizado para acceder a las aplicaciones dentro de la red virtual.

App Gateway está configurado para que un agente de escucha escuche en el puerto HTTP las solicitudes a la dirección IP de Gateway. Para simplificar, esta implementación no usa un registro de nombres DNS público y requiere que modifique el archivo localhost en el equipo para que una dirección URL seleccionada arbitrariamente apunte a la dirección IP de App Gateway. Para simplificar, el agente de escucha usa un certificado autofirmado para procesar estas solicitudes. App Gateway tiene grupos de back-end para cada dirección URL predeterminada de la aplicación de App Service. Una regla de enrutamiento está configurada para conectar el agente de escucha al grupo de back-end. Se crean configuraciones HTTP que determina si se cifrará la conexión entre la puerta de enlace y el ASE. Esta configuración también se usa para invalidar el encabezado de host HTTP de entrada con un nombre de host seleccionado del grupo de back-end. Esta implementación usa los certificados predeterminados creados para las direcciones URL de la aplicación de ASE predeterminada, que son de confianza para la puerta de enlace. La solicitud se redirige a la dirección URL predeterminada de la aplicación correspondiente. El DNS privado vinculado a la red virtual reenvía esta solicitud a la dirección IP del ILB. A continuación, el ASE la reenvía a la instancia de App Service solicitada. Cualquier comunicación HTTP dentro de las aplicaciones de ASE pasa por el DNS privado. Tenga en cuenta que el agente de escucha, el grupo de back-end, la regla de enrutamiento y la configuración HTTP deben configurarse en App Gateway para cada aplicación de ASE.

Explore appgw.json y dns.json para saber cómo se realizan estas configuraciones para permitir varios sitios. La aplicación web denominada testapp es una aplicación vacía creada para mostrar esta configuración. Se accede a estos archivos JSON desde el script de implementación deploy_std.sh. También se accede a ellos mediante deploy_ha.sh, que se usa para una implementación de ASE de varios sitios y de alta disponibilidad.

Detalles del escenario

Azure App Service es un servicio de PaaS que se usa para hospedar una variedad de aplicaciones en Azure: Web Apps, API Apps, Functions y Mobile Apps. App Service Environment o ASE permite a las empresas implementar las aplicaciones de App Service en una subred en su propia red virtual de Azure, lo que proporciona un entorno aislado, de alta escalabilidad y dedicado para sus cargas de trabajo en la nube.

Consideraciones

Seguridad

Entorno de App Service

Un ASE interno se implementa en la red virtual de la empresa, oculto en la red pública de Internet. Permite a la empresa bloquear sus servicios de back-end, como las API web y las funciones, en el nivel de red. Se puede acceder a cualquier aplicación de ASE con un punto de conexión HTTP a través de ILB, desde dentro de la red virtual. App Gateway está configurado para reenviar solicitudes a la aplicación web a través de ILB. La propia aplicación web pasa por el ILB para acceder a la API. Los componentes críticos de back-end, es decir, la API y la función, son realmente inaccesibles desde la red pública de Internet.

Se crean certificados predeterminados para cada instancia de App Service en el nombre de dominio predeterminado asignado por ASE. Este certificado puede reforzar la seguridad del tráfico entre la puerta de enlace y la aplicación, y puede ser necesario en ciertos escenarios. Estos certificados no serán visibles en el explorador del cliente; solo pueden responder a los certificados configurados en App Gateway.

Puerta de enlace de aplicaciones

La implementación de referencia configura App Gateway mediante programación en appgw.json. El archivo deploy_std.sh usa esta configuración al implementar la puerta de enlace:

az deployment group create --resource-group $RGNAME --template-file templates/appgw.json --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)
Cifrado

Como se describe en Introducción a la terminación TLS y a TLS de extremo a extremo con Application Gateway, App Gateway puede usar la Seguridad de la capa de transporte (TLS) y la Capa de sockets seguros (SSL) para cifrar y proteger todo el tráfico de los exploradores web. El cifrado se puede configurar de las siguientes maneras:

  1. Cifrado finalizado en la puerta de enlace. Los grupos de back-end en este caso están configurados para HTTP. El cifrado se detiene en la puerta de enlace, y el tráfico entre la puerta de enlace y App Service no está cifrado. Dado que el cifrado conlleva un uso intensivo de la CPU, el tráfico sin cifrar en el back-end mejora el rendimiento y permite una administración de certificados más sencilla. Esto proporciona un nivel de seguridad razonable, ya que el back-end está protegido según la configuración de red.

  2. Cifrado de un extremo a otro. En algunos escenarios, como requisitos de seguridad o de cumplimiento específicos, es posible que sea necesario cifrar el tráfico entre la puerta de enlace y la aplicación. Esto se logra mediante el uso de la conexión HTTPS y la configuración de certificados en el grupo de back-end.

Esta implementación de referencia usa certificados autofirmados para App Gateway. Para el código de producción, se debe usar un certificado emitido por una entidad de certificación. Para obtener una lista de los tipos de certificados compatibles, lea Certificados compatibles con la terminación de TLS. Lea Configuración de una puerta de enlace de aplicaciones con terminación TLS mediante Azure Portal para obtener información sobre cómo crear el cifrado con la terminación de puerta de enlace. Las siguientes líneas de código de appgw.json realizan esta configuración mediante programación:

          {
            "name": "httpListeners",
            "count": "[length(parameters('appgwApplications'))]",
            "input": {
              "name": "[concat(variables('appgwListenerName'), parameters('appgwApplications')[copyIndex('httpListeners')].name)]",
              "properties": {
                "frontendIPConfiguration": {
                  "id": "[concat(variables('appgwId'), '/frontendIPConfigurations/', variables('appgwFrontendName'))]"
                },
                "frontendPort": {
                  "id": "[concat(variables('appgwId'), '/frontendPorts/port_443')]"
                },
                "protocol": "Https",
                "sslCertificate": {
                  "id": "[concat(variables('appgwId'), '/sslCertificates/', variables('appgwSslCertificateName'), parameters('appgwApplications')[copyIndex('httpListeners')].name)]"
                },
                "hostName": "[parameters('appgwApplications')[copyIndex('httpListeners')].hostName]",
                "requireServerNameIndication": true
              }
            }
          },

Para el tráfico entre las aplicaciones web en el ASE y la puerta de enlace, se usan los certificados SSL predeterminados. Los grupos de back-end de esta implementación se configuran para redirigir el tráfico HTTPS con el nombre de host invalidado por los nombres de dominio predeterminados asociados a las aplicaciones web. App Gateway confía en los certificados SSL predeterminados, ya que los emite Microsoft. Lea Configuración de App Service con Application Gateway para saber cómo se realizan estas configuraciones. Las siguientes líneas de appgw.json muestran cómo se realiza esta configuración en la implementación de referencia:

         {
            "name": "backendHttpSettingsCollection",
            "count": "[length(parameters('appgwApplications'))]",
            "input": {
              "name": "[concat(variables('appgwHttpSettingsName'), parameters('appgwApplications')[copyIndex('backendHttpSettingsCollection')].name)]",
              "properties": {
                "Port": 443,
                "Protocol": "Https",
                "cookieBasedAffinity": "Disabled",
                "pickHostNameFromBackendAddress": true,
                "requestTimeout": 20,
                "probe": {
                  "id": "[concat(variables('appgwId'), '/probes/', variables('appgwHealthProbeName'), parameters('appgwApplications')[copyIndex('backendHttpSettingsCollection')].name)]"
                }
              }
            }
          },
Firewall de aplicaciones web

El firewall de aplicaciones web (WAF) de Application Gateway protege las aplicaciones web frente a ataques malintencionados, como la inyección de código SQL. También se integra con Azure Monitor, para supervisar los ataques mediante un registro en tiempo real. Es necesario que WAF se habilite en la puerta de enlace, como se describe en Creación de una puerta de enlace de aplicaciones con un firewall de aplicaciones web mediante Azure Portal. La implementación de referencia habilita WAF mediante programación en el archivo appgw.json con el siguiente fragmento de código:

        "webApplicationFirewallConfiguration": {
          "enabled": true,
          "firewallMode": "Detection",
          "ruleSetType": "OWASP",
          "ruleSetVersion": "3.0"
        },

Virtual Network

Los grupos de seguridad de red pueden estar asociados a una o varias subredes de la red virtual. Se trata de reglas de seguridad que permiten o deniegan el tráfico entre distintos recursos de Azure. Esta arquitectura asocia un NSG independiente para cada subred. Esto permite la optimización de estas reglas por subred, según los servicios contenidos en esa subred. Por ejemplo, explore la configuración de "type": "Microsoft.Network/networkSecurityGroups" en el archivo ase.json de NSG para la subred de ASE y en el archivo appgw.json para el NSG de la subred de App Gateway.

Los puntos de conexión de servicio amplían el espacio de direcciones privadas de la red virtual y la identidad para admitir los servicios de Azure, restringiendo el acceso a estos servicios solo a la red virtual. Para mejorar la seguridad, los puntos de conexión de servicio deben estar habilitados en la subred de ASE para cualquier servicio de Azure que lo admita. Después, el servicio se puede proteger en la red virtual de la empresa mediante la configuración de reglas de red virtual en el servicio, con un bloqueo efectivo desde la red pública de Internet. La infraestructura de ASE configura puntos de conexión de servicio para el centro de eventos, SQL Server y almacenamiento para su propia administración, incluso si la propia arquitectura no puede usarlos, como se mencionó en la sección sobre la arquitectura del sistema de este artículo. Esta arquitectura configura los puntos de conexión de servicio para los servicios utilizados, que son compatibles con: Service Bus, SQL Server, Key Vault y Azure Cosmos DB. Explore esta configuración en ase.json, como "type": "Microsoft.Network/virtualNetworks/subnets" -->"properties" -->"serviceEndpoints".

La habilitación de puntos de conexión de servicio en una subred es un proceso de dos pasos. Los propios recursos deben configurarse para recibir tráfico en los puntos de conexión de servicio de esta red virtual. Para más información, lea Restricción del acceso de la red a un recurso.

Firewall

Azure Firewall y los puntos de conexión de servicio se complementan entre sí. Aunque los puntos de conexión de servicio protegen los recursos mediante la restricción del tráfico entrante para que se origine en la red virtual, Azure Firewall le permite restringir el tráfico saliente de las aplicaciones. Se recomienda permitir que todo el tráfico saliente pase a través de la subred del firewall, incluido el tráfico del punto de conexión de servicio. Esto permite una mejor supervisión del tráfico saliente. Sin embargo, la infraestructura de ASE requiere puntos de conexión de servicio para la configuración de SQL Server, Storage y Event Hubs en la subred de ASE. Vea Bloqueo de una instancia de App Service Environment para obtener información sobre la integración del firewall. Además, esta implementación usa Azure Cosmos DB en el modo de conexión directa, que requiere que se abra un intervalo de puertos. Esto puede complicar la configuración del firewall. Para simplificar, esta arquitectura de referencia configura todos los puntos de conexión de servicio en la subred de ASE, en lugar de en la subred del firewall. Esto incluye los puntos de conexión de Service Bus, Azure Cosmos DB y Key Vault, además de los necesarios para la infraestructura de ASE.

Vea Configuración de Azure Firewall con App Service aislado para obtener información sobre cómo se integra el firewall con el ASE. El firewall supervisará y validará todo el tráfico que no pase por los puntos de conexión de servicio y la tabla de enrutamiento de la red virtual. La necesidad de la tabla de enrutamiento se describe en la sección siguiente.

Direcciones IP de administración de ASE

El tráfico de administración del ASE fluye a través de la red virtual de la empresa. Este tráfico se debe enrutar directamente a las direcciones IP dedicadas fuera de la red virtual, evitando el firewall. Esto se logra mediante la creación de una tabla de enrutamiento de red virtual definida por el usuario. En el artículo Direcciones de administración de App Service Environment se enumeran estas direcciones IP. Esta lista puede tardar demasiado en configurarse manualmente en el firewall. Esta implementación muestra cómo se puede rellenar mediante programación. La línea siguiente de deploy_std.sh obtiene esta lista con la CLI de Azure y jq, un analizador JSON de la línea de comandos:

ENDPOINTS_LIST=$(az rest --method get --uri $ASE_ID/inboundnetworkdependenciesendpoints?api-version=2016-09-01 | jq '.value[0].endpoints | join(", ")' -j)

Es equivalente al método documentado para obtener las direcciones de administración de la API.

Los siguientes comandos de deploy_std.sh crean la red virtual junto con la tabla de enrutamiento, tal y como se ha configurado en network.json:

VNET_NAME=$(az network vnet list -g $RGNAME --query "[?contains(addressSpace.addressPrefixes, '${NET_PREFIX}')]" --query [0].name -o tsv)
az deployment group create --resource-group $RGNAME --template-file templates/network.json --parameters existentVnetName=$VNET_NAME vnetAddressPrefix=$NET_PREFIX
VNET_NAME=$(az deployment group show -g $RGNAME -n network --query properties.outputs.vnetName.value -o tsv)
VNET_ROUTE_NAME=$(az deployment group show -g $RGNAME -n network --query properties.outputs.vnetRouteName.value -o tsv)

Cuando se crea la subred de ASE, la tabla de enrutamiento se asocia con ella:

az deployment group create --resource-group $RGNAME --template-file templates/ase.json -n ase --parameters vnetName=$VNET_NAME vnetRouteName=$VNET_ROUTE_NAME aseSubnetAddressPrefix=$ASE_PREFIX

Cuando se crea el firewall, el archivo de configuración firewall.json actualiza esta tabla de enrutamiento con las direcciones IP de administración de ASE, seguidas de la dirección IP del firewall. Esto dirige el tráfico restante a través de la dirección IP del firewall:

{
  "variables": {
    "firewallSubnetName": "AzureFirewallSubnet",
    "firewallPublicIpName": "[concat('firewallIp', '-', uniqueString(resourceGroup().id))]",
    "firewallName": "[concat('firewall', '-', uniqueString(resourceGroup().id))]",
    "aseManagementEndpoints": "[split(replace(parameters('aseManagementEndpointsList') ,' ', ''), ',')]",
    "copy": [
      {
        "name": "aseManagementIpRoutes",
        "count": "[length(variables('aseManagementEndpoints'))]",
        "input": {
          "name": "[replace(variables('aseManagementEndpoints')[copyIndex('aseManagementIpRoutes')], '/', '-')]",
          "properties": {
            "addressPrefix": "[variables('aseManagementEndpoints')[copyIndex('aseManagementIpRoutes')]]",
            "nextHopType": "Internet"
          }
        }
      }
    ]
  },
  "resources": [
    {
      "type": "Microsoft.Network/routeTables",
      "apiVersion": "2019-11-01",
      "name": "[parameters('vnetRouteName')]",
      "location": "[parameters('location')]",
      "tags": {
        "displayName": "UDR - Subnet"
      },
      "dependsOn": [
        "[resourceId('Microsoft.Network/azureFirewalls', variables('firewallName'))]"
      ],
      "properties": {
        "routes": "[concat(variables('aseManagementIpRoutes'), array(json(concat('{ \"name\": \"Firewall\", \"properties\": { \"addressPrefix\": \"0.0.0.0/0\", \"nextHopType\": \"VirtualAppliance\", \"nextHopIpAddress\": \"', reference(concat('Microsoft.Network/azureFirewalls/', variables('firewallName')),'2019-09-01','Full').properties.ipConfigurations[0].properties.privateIPAddress, '\" } }'))))]"
      }
    }
...
...
  ]
...
...
}

La lista de direcciones IP de administración puede cambiar una vez implementada la tabla de enrutamiento, en cuyo caso será necesario volver a implementar dicha tabla.

Azure Active Directory

Azure Active Directory proporciona características de seguridad para autenticar aplicaciones y autorizar el acceso a los recursos. Esta arquitectura de referencia usa dos características clave de Azure Active Directory: identidades administradas y control de acceso basado en roles de Azure.

Al compilar aplicaciones en la nube, deben protegerse las credenciales necesarias para autenticarse en los servicios en la nube. Lo ideal sería que las credenciales nunca aparecieran en las estaciones de trabajo de los desarrolladores o que se protegieran en el control de código fuente. Azure Key Vault proporciona una manera de almacenar de forma segura credenciales y secretos, pero la aplicación todavía tiene que autenticarse en Key Vault para recuperarlos. Las identidades administradas para los recursos de Azure proporcionan a los servicios de Azure una identidad administrada automáticamente en Azure AD. Esta identidad puede usarse para autenticarse en cualquier servicio que admita la autenticación de Azure AD, incluido Key Vault, sin necesidad de credenciales en la aplicación.

El control de acceso basado en roles de Azure (RBAC de Azure) administra el acceso a los recursos de Azure. Esto incluye:

  • Qué entidad tiene acceso: usuario, identidad administrada o entidad de seguridad.
  • Qué tipo de acceso tiene: propietario, colaborador, lector o administrador.
  • Ámbito del acceso: recurso, grupo de recursos, suscripción o grupo de administración.

Puede bloquear el acceso a las aplicaciones de ASE mediante el control estricto del rol requerido y el tipo de acceso de cada aplicación. De este modo, se pueden implementar varias aplicaciones en el mismo ASE desde distintos equipos de desarrollo. Por ejemplo, un equipo podría controlar el front-end y otro equipo, el back-end. RBAC de Azure se puede usar para limitar el acceso de cada equipo a las aplicaciones en las que se está trabajando. Explore Roles personalizados de Azure para crear roles adecuados para su organización.

Key Vault

Algunos servicios admiten identidades administradas, pero usan RBAC de Azure para configurar los permisos de la aplicación. Por ejemplo, vea los roles integrados de Service Bus, así como RBAC de Azure en Azure Cosmos DB. Se requiere el acceso de Propietario a la suscripción para conceder estos permisos, aunque el personal con acceso de Colaborador puede implementar estos servicios. Para permitir que un equipo más amplio de desarrolladores pueda ejecutar los scripts de implementación, la siguiente mejor opción es usar las directivas de control de acceso nativo del servicio:

Las cadenas de conexión para estas directivas de control de acceso se almacenan en Key Vault. Se accede al almacén mediante identidades administradas, lo que no requiere RBAC de Azure. Establezca la directiva de acceso para estas cadenas de conexión de forma adecuada. Por ejemplo, solo lectura para el back-end, solo escritura para el front-end, etc., en lugar de usar la directiva de acceso raíz predeterminada.

En el siguiente fragmento de código de services.json se muestra la configuración de Key Vault para estos servicios:

    {
      "type": "Microsoft.KeyVault/vaults/secrets",
      "name": "[concat(variables('keyVaultName'), '/CosmosKey')]",
      "apiVersion": "2015-06-01",
      "dependsOn": [
        "[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
        "[resourceId('Microsoft.DocumentDB/databaseAccounts', variables('cosmosName'))]"
      ],
      "properties": {
        "value": "[listKeys(resourceId('Microsoft.DocumentDB/databaseAccounts',variables('cosmosName')),'2015-04-08').primaryMasterKey]"
      }
    },
    {
      "type": "Microsoft.KeyVault/vaults/secrets",
      "name": "[concat(variables('keyVaultName'), '/ServiceBusListenerConnectionString')]",
      "apiVersion": "2015-06-01",
      "dependsOn": [
        "[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
        "[resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules', variables('serviceBusName'), 'ListenerSharedAccessKey')]"
      ],
      "properties": {
        "value": "[listKeys(resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules',variables('serviceBusName'),'ListenerSharedAccessKey'),'2015-08-01').primaryConnectionString]"
      }
    },
    {
      "type": "Microsoft.KeyVault/vaults/secrets",
      "name": "[concat(variables('keyVaultName'), '/ServiceBusSenderConnectionString')]",
      "apiVersion": "2015-06-01",
      "dependsOn": [
        "[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
        "[resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules', variables('serviceBusName'), 'SenderSharedAccessKey')]"
      ],
      "properties": {
        "value": "[listKeys(resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules',variables('serviceBusName'),'SenderSharedAccessKey'),'2015-08-01').primaryConnectionString]"
      }
    },

Las aplicaciones acceden a estos valores de la cadena de conexión; para ello, hacen referencia al par clave-valor de Key Vault. Esto se hace en el archivo sites.json como se muestra en el siguiente fragmento de código para la aplicación de votación:

{
  "properties": {
    "enabled": true,
    "name": "[variables('votingWebName')]",
    "hostingEnvironment": "[variables('aseId')]",
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('votingWebPlanName'))]",
    "siteConfig": {
      "appSettings": [
        {
            "name": "ConnectionStrings:sbConnectionString",
            "value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('serviceBusSenderConnectionStringSecretName')), '2016-10-01').secretUriWithVersion, ')')]"
        },
        {
            "name": "ConnectionStrings:RedisConnectionString",
            "value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('redisSecretName')), '2016-10-01').secretUriWithVersion, ')')]"
        },
        {
            "name": "ConnectionStrings:CosmosKey",
            "value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('cosmosKeySecretName')), '2016-10-01').secretUriWithVersion, ')')]"
        }
      ]
    }
  }
}

La función también tiene acceso a la cadena de conexión del agente de escucha de Service Bus de una manera similar.

Escalabilidad

Diseño de aplicaciones escalables

La aplicación de esta arquitectura de referencia está estructurada para que se puedan escalar componentes individuales en función del uso. Cada aplicación web, API y función se implementa en su propio plan de App Service. Puede supervisar cada aplicación en busca de cuellos de botella de rendimiento y, a continuación, escalarla verticalmente si es necesario. Lea Mejora de la escalabilidad en una aplicación web de Azure para aprender a diseñar aplicaciones web escalables mediante Azure App Service.

Escalado automático de App Gateway

El escalado automático se puede habilitar en la versión 2 de Azure Application Gateway. Esto permite a App Gateway escalar o reducir verticalmente en función de los patrones de carga de tráfico. Esta arquitectura de referencia configura autoscaleConfiguration en el archivo appgw.json para escalar entre cero y diez instancias adicionales. Vea Escalado de Application Gateway y WAF v2 para más información.

Implementación

Los scripts de implementación de esta arquitectura de referencia se usan para implementar ASE, otros servicios y las aplicaciones dentro del ASE. Una vez implementadas estas aplicaciones, es posible que las empresas deseen tener un plan de integración e implementación continuas para las actualizaciones y el mantenimiento de las aplicaciones. En esta sección se muestran algunos de los métodos comunes que los desarrolladores usan para la CI/CD de aplicaciones de ASE.

Las aplicaciones se pueden implementar en un ASE interno solo desde dentro de la red virtual. Los tres métodos siguientes se usan con frecuencia para implementar aplicaciones de ASE:

  1. Manualmente en la red virtual: Cree una máquina virtual dentro de la red virtual de ASE con las herramientas necesarias para la implementación. Abra la conexión RDP a la máquina virtual con una configuración de NSG. Copie los artefactos de código en la máquina virtual, y compile e implemente en la subred de ASE. Se trata de una manera sencilla de configurar un entorno de desarrollo de prueba y compilación inicial. No obstante, no se recomienda para el entorno de producción, ya que no puede escalar el rendimiento de implementación requerido.

  2. Conexión de punto a sitio desde la estación de trabajo local: Permite ampliar la red virtual de ASE a su equipo de desarrollo e implementar desde allí. Esta es otra manera de configurar un entorno de desarrollo inicial, que no se recomienda para producción.

  3. Mediante Azure Pipelines: Implementa una canalización de CI/CD completa, y finaliza en un agente ubicado dentro de la red virtual. Esto es ideal para entornos de producción que requieren un alto rendimiento de implementación. La canalización de compilación permanece completamente fuera de la red virtual. La canalización de implementación copia los objetos compilados en el agente de compilación dentro de la red virtual y, a continuación, se implementa en la subred de ASE. Para más información, lea este debate sobre el agente de compilación autohospedado entre Pipelines y la red virtual de ASE.

Se recomienda usar Azure Pipelines para entornos de producción. La creación de scripts de CI/CD con la ayuda del esquema de YAML de Azure Pipelines permite automatizar los procesos de compilación e implementación. azure-pipelines.yml implementa una canalización de CI/CD para la aplicación web en esta implementación de referencia. Hay scripts de CI/CD similares para la API web y para la función. Lea Uso de Azure Pipelines para obtener información sobre cómo se usan para automatizar CI/CD para cada aplicación.

Es posible que algunas empresas no quieran mantener un agente de compilación permanente dentro de la red virtual. En ese caso, puede elegir crear un agente de compilación dentro de la canalización de DevOps y anularlo una vez completada la implementación. Esto agrega otro paso en DevOps, pero reduce la complejidad del mantenimiento de la máquina virtual. Incluso puede considerar el uso de contenedores como agentes de compilación, en lugar de máquinas virtuales. Los agentes de compilación también se pueden evitar por completo mediante la implementación desde un archivo ZIP situado fuera de la red virtual, normalmente en una cuenta de almacenamiento. La cuenta de almacenamiento deberá ser accesible desde el ASE. La canalización debe ser capaz de acceder al almacenamiento. Al final de la canalización de versión, se puede colocar un archivo ZIP en el almacenamiento de blobs. A continuación, el ASE puede seleccionarlo e implementarlo. Tenga en cuenta las siguientes limitaciones de este enfoque:

  • Existe una desconexión entre DevOps y el proceso de implementación real, lo que provoca dificultades en la supervisión y el seguimiento de cualquier problema de implementación.
  • En un entorno bloqueado con tráfico protegido, puede que tenga que cambiar las reglas para acceder al archivo ZIP en el almacenamiento.
  • Tendrá que instalar extensiones y herramientas específicas en el ASE para poder realizar la implementación desde el archivo ZIP.

Para conocer otras formas de implementar las aplicaciones en los planes de App Service, lea los artículos de App Service que se centran en las estrategias de implementación.

Optimización de costos

Puede usar la calculadora de precios de Azure para calcular los costos. Otras consideraciones se describen en la sección Costo de Marco de buena arquitectura de Microsoft Azure. Las reservas de Azure le ayudan a ahorrar dinero, ya que se compromete a planes de uno o tres años para muchos productos de Azure. Lea más en el artículo Adquisición de una reserva.

Estos son algunos puntos que se deben tener en cuenta para algunos de los servicios clave que se usan en esta arquitectura.

Entorno de App Service

Hay varias opciones de precios disponibles para App Service. Un entorno de App Service se implementa mediante el plan de servicio aislado. Dentro de este plan, hay tres opciones para los tamaños de CPU: I1, I2 e I3. Esta implementación de referencia usa tres I1 por instancia.

Application Gateway

Los precios de Application Gateway ofrecen varias opciones de precios para App Gateway. Se usan las SKU Standard_v2 y WAF_v2 de Application Gateway, que admite el escalado automático y la redundancia de zona. Lea este artículo para saber más sobre el modelo de precios que se usa para esta SKU.

Azure Cache for Redis

Los precios de Azure Cache for Redis proporcionan las diversas opciones de precios para este servicio. Esta arquitectura usa la SKU Prémium para la compatibilidad con la red virtual.

A continuación se muestran las páginas de precios para otros servicios que se usan para bloquear el ASE:

Implementación de este escenario

Para realizar la implementación de referencia de esta arquitectura, consulte el archivo Léame de GitHub y siga el script para implementaciones estándar.

Colaboradores

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

Creadores de entidad de seguridad:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Para obtener información sobre cómo ampliar esta arquitectura para admitir la alta disponibilidad, lea Implementación de aplicaciones de alta disponibilidad en Azure App Service Environment.