Compartir a través de


Implementación de una arquitectura de seguridad por capas con entornos de App Service

Importante

Este artículo trata sobre App Service Environment v1. App Service Environment v1 y v2 se retiran a partir del 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, revise 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.

Como los entornos de App Service proporcionan un entorno de tiempo de ejecución aislado que está implementado en una red virtual, los desarrolladores pueden crear una arquitectura de seguridad por capas que proporcione diferentes niveles de acceso a la red para cada capa de aplicación física.

Un objetivo común es ocultar los back-ends de API al acceso general desde Internet y permitir que solo las aplicaciones web ascendentes puedan llamar a las API. Los grupos de seguridad de red (NSG) pueden usarse para restringir el acceso público a aplicaciones API en subredes que contengan App Service Environment.

El diagrama a continuación muestra una arquitectura de ejemplo con una aplicación basada en WebAPI, implementada en un entorno de App Service. Tres instancias de aplicación web independiente, implementadas en tres entornos de App Service independientes, realizan llamadas de back-end a la misma aplicación WebAPI.

Arquitectura conceptual

El signo más de color verde indica que el grupo de seguridad de red en la subred que contiene "apiase" permite llamadas entrantes desde las aplicaciones web ascendentes, así como llamadas de sí mismo. Sin embargo el mismo grupo de seguridad de red deniega explícitamente el acceso al tráfico general de entrada desde Internet.

El resto de este artículo le guiará por los pasos necesarios para configurar el grupo de seguridad de red en la subred que contiene el valor "apiase".

Determinación del comportamiento de la red

Para saber qué reglas de seguridad de red se necesitan, debe determinar qué clientes de red podrán acceder a App Service Environment que contiene la aplicación de API y qué clientes están bloqueados.

Puesto que los grupos de seguridad de red (NSG) se aplican a las subredes y App Service Environment se implementa en las subredes, las reglas contenidas en un NSG se aplican a todas las aplicaciones que se ejecutan en App Service Environment. En la arquitectura de ejemplo de este artículo, una vez que un grupo de seguridad de red se aplica a la subred que contiene "apiase", todas las aplicaciones que se ejecuten en el entorno de App Service "apiase" estarán protegidas por el mismo conjunto de reglas de seguridad.

  • Determinar la dirección IP saliente de los autores de las llamadas ascendentes: ¿cuál es la dirección o direcciones IP de los autores de las llamadas ascendentes? Es necesario permitir de forma explícita el acceso a estas direcciones en la NSG. Dado que las llamadas entre los entornos de App Service se consideran llamadas de "Internet", se tiene que permitir el acceso en el NSG correspondiente a la dirección IP saliente asignada a cada uno de los tres entornos de App Service ascendentes para la subred "apiase". Para más información sobre cómo determinar la dirección IP de salida para las aplicaciones que se ejecutan en App Service Environment, consulte el artículo Información general sobre la arquitectura de red.
  • ¿Tiene la aplicación de API de back-end que llamarse a sí misma? Un punto sutil que a veces se pasa por alto es el escenario en el que la aplicación back-end tiene que llamarse a sí misma. Si una aplicación de API de back-end en una instancia de App Service Environment debe llamarse a sí misma, también se trata como una llamada a "Internet". En la arquitectura de ejemplo, esto requiere que se permita también el acceso desde la dirección IP saliente del entorno de App Service "apiase".

Creación del grupo de seguridad de red

Una vez que se conozca el conjunto de direcciones IP salientes, el siguiente paso es crear un grupo de seguridad de red. Los grupos de seguridad de red se pueden crear para redes virtuales basadas en Resource Manager y redes virtuales clásicas. En los ejemplos siguientes se muestra cómo crear y configurar un NSG en una red virtual clásica mediante PowerShell.

Para la arquitectura del ejemplo, los entornos se encuentran en "Centro-sur de EE. UU.", por lo que se crea un NSG vacío en esa región:

New-AzureNetworkSecurityGroup -Name "RestrictBackendApi" -Location "South Central US" 
-Label "Only allow web frontend and loopback traffic"

En primer lugar, se agrega una regla de permiso explícito para la infraestructura de administración de Azure como se indica en el artículo sobre el tráfico de entrada para App Service Environment.

#Open ports for access by Azure management infrastructure
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW AzureMngmt" 
-Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix 'INTERNET' -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '454-455' -Protocol TCP

A continuación, se agregan dos reglas para permitir las llamadas HTTP y HTTPS desde el primer entorno de App Service ascendente ("fe1ase").

#Grant access to requests from the first upstream web front-end
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP fe1ase" 
-Type Inbound -Priority 200 -Action Allow -SourceAddressPrefix '65.52.xx.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS fe1ase" 
-Type Inbound -Priority 300 -Action Allow -SourceAddressPrefix '65.52.xx.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Se aclara y se repite para el segundo y tercer entorno de App Service ascendente ("fe2ase" y "fe3ase").

#Grant access to requests from the second upstream web front-end
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP fe2ase" 
-Type Inbound -Priority 400 -Action Allow -SourceAddressPrefix '191.238.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS fe2ase" 
-Type Inbound -Priority 500 -Action Allow -SourceAddressPrefix '191.238.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

#Grant access to requests from the third upstream web front-end
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP fe3ase" 
-Type Inbound -Priority 600 -Action Allow -SourceAddressPrefix '23.98.abc.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS fe3ase" 
-Type Inbound -Priority 700 -Action Allow -SourceAddressPrefix '23.98.abc.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Por último, conceder acceso a la dirección IP saliente del entorno de App Service de la API de back-end para que puede devolverse la llamada a sí misma.

#Allow apps on the apiase environment to call back into itself
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP apiase" 
-Type Inbound -Priority 800 -Action Allow -SourceAddressPrefix '70.37.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS apiase" 
-Type Inbound -Priority 900 -Action Allow -SourceAddressPrefix '70.37.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

No se requiere ninguna otra regla de seguridad de red, porque cada NSG tiene un conjunto de reglas predeterminadas que bloquean el acceso de entrada desde Internet de forma predeterminada.

Se muestra la lista completa de reglas del grupo de seguridad de red. Observe cómo se resalta la última regla, que está resaltada, bloquea el acceso entrante de todos los autores de llamadas, excepto los llamadores a los que se concede acceso explícitamente.

Configuración NSG

El último paso es aplicar el NSG a la subred que contiene el entorno de App Service "apiase".

#Apply the NSG to the backend API subnet
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityGroupToSubnet 
-VirtualNetworkName 'yourvnetnamehere' -SubnetName 'API-ASE-Subnet'

Con el NSG aplicado a la subred, solo los tres entornos de App Service y el entorno de App Service que contiene el back-end de API tienen permitido llamar en el entorno de "apiase".

Información acerca de los grupos de seguridad de red.

Descripción de las direcciones IP salientes y App Service Environment.

Puertos de red usados en 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.