Conexión segura a los recursos de back-end desde App Service Environment
Importante
Este artículo trata sobre App Service Environment v1. App Service Environment v1 y v2 se han retirado desde el 31 de agosto de 2024. Hay una nueva versión de App Service Environment que resulta más fácil de usar y se ejecuta en una infraestructura más eficaz. Para aprender más sobre la nueva versión, empiece por consultar la Introducción a App Service Environment. Si actualmente usa App Service Environment v1, siga los pasos descritos en este artículo para migrar a la nueva versión.
A partir del 31 de agosto de 2024, el Acuerdo de Nivel de Servicio (SLA) y los créditos de servicio ya no se aplican a las cargas de trabajo de App Service Environment v1 y v2 que siguen en producción, ya que son productos retirados. Se ha iniciado la retirada del hardware de App Service Environment v1 y v2, lo que puede afectar a la disponibilidad y el rendimiento de las aplicaciones y los datos.
Debe completar la migración a App Service Environment v3 inmediatamente o las aplicaciones y los recursos podrían ser eliminados. Intentaremos migrar automáticamente cualquier instancia restante de App Service Environment v1 y v2 en la medida de lo posible mediante la característica de migración local, pero Microsoft no ofrece ninguna garantía sobre la disponibilidad de la aplicación después de la migración automática. Es posible que tenga que realizar la configuración manual para completar la migración y optimizar la opción de SKU del plan de App Service para satisfacer sus necesidades. Si la migración automática no es factible, se eliminarán los recursos y los datos de la aplicación asociados. Le instamos encarecidamente a que actúe ahora para evitar cualquiera de estos escenarios extremos.
Si necesita más tiempo, podemos ofrecerle un único periodo de gracia de 30 días para que complete la migración. Para obtener más información y solicitar este período de gracia, consulte la información general del período de gracia, y a continuación, vaya a Azure Portal y visite la hoja Migración para cada uno de los entornos de App Service.
Para obtener la información más actualizada sobre la retirada de App Service Environment v1/v2, consulte la Actualización de retirada de App Service Environment v1 y v2.
Dado que una instancia de App Service Environment siempre se crea o bien en una red virtual de Azure Resource Manager o en una red virtual del modelo de implementación clásica, las conexiones salientes de dicho entorno a otros recursos de back-end solo pueden fluir a través de la red virtual. A partir de junio de 2016, las instancias de ASE también se pueden implementar en redes virtuales que usen intervalos de direcciones públicas o espacios de direcciones RFC1918 (direcciones privadas).
Por ejemplo, puede haber un servidor SQL Server que se ejecute en un clúster de máquinas virtuales con el puerto 1433 bloqueado. En el extremo puede incluirse una lista de control de acceso para permitir únicamente el acceso de otros recursos de la misma red virtual.
Otro ejemplo: los puntos de conexión con información confidencial pueden ejecutarse localmente y conectarse a Azure mediante conexiones Sitio a sitio o Azure ExpressRoute. Como resultado, solo los recursos de las redes virtuales conectadas a túneles ExpressRoute o De sitio a sitio podrían tener acceso a los extremos locales.
En todos estos escenarios, las aplicaciones que se ejecutan en App Service Environment pueden conectarse de forma segura a los distintos servidores y recursos. Si el tráfico saliente de las aplicaciones se ejecuta en App Service Environment hacia puntos de conexión privados de la misma red virtual (o conectados a la misma red virtual) solamente fluirá por la red virtual. El tráfico saliente hacia puntos de conexión privados no fluirá por la red pública de Internet.
Un problema se aplica al tráfico saliente desde una instancia de App Service Environment hacia los puntos de conexión de una red virtual. Las instancias de App Service Environment no pueden acceder a los puntos de conexión de máquinas virtuales ubicadas en la misma subred que el App Service Environment. Normalmente, esta limitación no debería suponer ningún problema, siempre y cuando App Service Environment se implemente en una subred reservada para su uso exclusivo.
Nota
Aunque este artículo se refiere a las aplicaciones web, también se aplica a las aplicaciones de API y las aplicaciones móviles.
Requisitos de DNS y conectividad saliente
Para que un Entorno de App Service funcione correctamente, necesita acceso de salida a varios puntos de conexión. Una lista completa de los puntos de conexión externos utilizados por un ASE en la sección "Conectividad de red necesaria" del artículo Detalles de configuración de red para entornos del Servicio de aplicaciones con ExpressRoute .
Los Entornos de App Service requieren una infraestructura DNS válida configurada para la red virtual. Si se cambia la configuración de DNS después de crear una instancia de App Service Environment, los desarrolladores pueden forzar que una instancia aplique la nueva configuración de DNS. En la parte superior de la hoja de administración de App Service Environment del portal, seleccione el icono Reiniciar para desencadenar el reinicio gradual del entorno, lo que provoca que el entorno aplique la nueva configuración de DNS.
También se recomienda configurar de antemano los servidores DNS personalizados de la red virtual antes de crear una instancia de App Service Environment. Si se cambia la configuración de DNS de una red virtual al crear una instancia de App Service Environment, se generará un error en el proceso de creación. En el otro extremo de una puerta de enlace de VPN, si hay un servidor DNS personalizado que no está accesible o disponible, también se generará un error al crear la instancia de App Service Environment.
Conexión a un servidor SQL Server
Una configuración común de SQL Server tiene un extremo que escucha en el puerto 1433:
Existen dos formas de restringir el tráfico a este extremo:
Restricción del acceso con una lista de control de acceso de red
El puerto 1433 se puede proteger mediante una lista de control de acceso de red. En el ejemplo siguiente se incluyen en los permisos de la asignación las direcciones de cliente que proceden de una red virtual y se bloquea el acceso al resto de clientes.
Cualquier aplicación que se ejecute en App Service Environment, en la misma red virtual que SQL Server, puede conectarse a la instancia de SQL Server. Use la dirección IP interna de la red virtual para la máquina virtual de SQL Server.
La cadena de conexión de ejemplo siguiente hace referencia a SQL Server mediante su dirección IP privada.
Server=tcp:10.0.1.6;Database=MyDatabase;User ID=MyUser;Password=PasswordHere;provider=System.Data.SqlClient
Aunque la máquina virtual también tiene un punto de conexión público, los intentos de conexión para usar la dirección IP pública se rechazarán debido a la ACL de red.
Restricción del acceso con un grupo de seguridad de red
Un enfoque alternativo para proteger el acceso consiste en usar un grupo de seguridad de red. Los grupos de seguridad de red pueden aplicarse a máquinas virtuales individuales o a una subred que contenga máquinas virtuales.
En primer lugar, deberá crear un grupo de seguridad de red:
New-AzureNetworkSecurityGroup -Name "testNSGexample" -Location "South Central US" -Label "Example network security group for an app service environment"
Restringir el acceso exclusivamente al tráfico interno de la red virtual es sencillo con un grupo de seguridad de red. Las reglas predeterminadas de un grupo de este tipo solo permiten el acceso de otros clientes de la misma red virtual.
Como resultado, el bloqueo del acceso a SQL Server es sencillo. Solo tiene que aplicar un grupo de seguridad de red con sus reglas predeterminadas a las máquinas virtuales que ejecutan SQL Server o a la subred que contiene las máquinas virtuales.
En el ejemplo siguiente se aplica un grupo de seguridad de red a la subred contenedora:
Get-AzureNetworkSecurityGroup -Name "testNSGExample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-1'
El resultado final es un conjunto de reglas de seguridad que bloquean el acceso externo y permiten el acceso interno a la red virtual:
Introducción
Para empezar a trabajar con los entornos de App Service, consulte Introducción al entorno de App Service
Para más información sobre cómo controlar el tráfico entrante en App Service Environment, consulte el artículo sobre el control del tráfico entrante en una instancia de App Service Environment.
Nota
Si desea empezar a trabajar con Azure App Service antes de inscribirse para abrir una cuenta de Azure, vaya a Prueba de App Service, donde podrá crear inmediatamente una aplicación web de inicio de corta duración en App Service. No es necesario proporcionar ninguna tarjeta de crédito ni asumir ningún compromiso.