En este artículo se muestra cómo configurar la conectividad privada con seguridad mejorada a una aplicación web multiinquilino o a una aplicación de funciones desde una red local o desde una red virtual de Azure. También se muestra cómo configurar la conectividad con seguridad mejorada entre la aplicación y otros servicios PaaS de Azure a través de Azure Private Link, sin usar la red pública de Internet.
Architecture
Descargue un archivo Visio de esta arquitectura.
Flujo de datos
Gracias a la integración con redes virtuales regionales de Azure App Service, la aplicación web se conecta a los servicios de Azure mediante una subred delegada, Subred de integración de red virtual, de una red virtual de Azure.
- Las redes Subred de integración con la red virtual y Subred de punto de conexión privado están en redes virtuales distintas. Ambas redes se emparejan con la Red virtual de centro como parte de una configuración de red en estrella tipo hub-and-spoke. Para la integración con redes virtuales regionales, las redes virtuales emparejadas deben estar en la misma región de Azure.
El servicio Azure Private Link configura un punto de conexión privado para los servicios PaaS, las aplicaciones web, la base de datos Azure SQL, la cuenta de Azure Storage y Azure Key Vault en Red virtual de punto de conexión privado.
En este ejemplo, esta red virtual se dedica solo a la implementación de puntos de conexión privados. Ningún otro recurso, como las máquinas virtuales, se implementará en esta red virtual. La demanda futura para agregar puntos de conexión privados se tuvo en cuenta cuando se seleccionó el tamaño de la subred.
La red local y las redes virtuales de Azure se pueden conectar a través de VPN de sitio a sitio (S2S) o emparejamiento privado de Azure ExpressRoute. Los usuarios de la red local acceden a la aplicación de forma privada y con seguridad mejorada solo a través de la red privada.
En este ejemplo, la red local y las redes virtuales de Azure se conectan a través del emparejamiento privado de ExpressRoute.
En el caso de una red local que ya tiene una solución del sistema de nombres de dominio (DNS) implementada, la solución DNS local se configura para reenviar el tráfico DNS a un registro DNS privado de Azure (por ejemplo, azurewebsites.net) a través de un reenviador condicional que reenvía la solicitud al punto de conexión de entrada del servicio DNS Private Resolver que se implementa en Azure. DNS Private Resolver consulta a Azure DNS y recibe información sobre un vínculo de red virtual de Azure DNS privado. Después, la resolución se realiza mediante una zona DNS privada vinculada a la red virtual.
Las zonas DNS privadas se implementan también en la misma suscripción que la red virtual de punto de conexión privado.
En este ejemplo, un equipo reenviador DNS en la dirección IP 192.168.0.254 de la red local reenvía todas las solicitudes de resolución DNS al nombre de host azurewebsites.net al punto de conexión de entrada del servicio DNS Private Resolver en Azure en la dirección 10.0.0.132. A continuación, el servicio DNS proporcionado por Azure resuelve las solicitudes, que tiene la dirección IP 168.63.129.16, a través de la zona de Azure DNS privado que está vinculada a la red virtual.
Se requiere un punto de conexión de salida para habilitar la resolución de nombres de reenvío condicional desde Azure a un entorno local, a otros proveedores de nube o a servidores DNS externos, mediante un conjunto de reglas de reenvío condicional.
No es necesario configurar un conjunto de reglas de reenvío DNS para este escenario.
Esta configuración de App Service debe estar presente:
Clave Value WEBSITE_DNS_SERVER 168.63.129.16 Las redes virtuales están vinculadas a todas las zonas DNS privadas de Azure.
- La red virtual que tiene puntos de conexión privados se vincula automáticamente a las zonas DNS privadas. Debe vincular las otras redes virtuales por separado.
La aplicación web se comunica con los puntos de conexión privados de los servicios PaaS en la Red virtual de punto de conexión privado a través Azure Firewall.
En Azure Firewall, las reglas de aplicación se configuran para permitir la comunicación entre la Subred de integración con la red virtual y los puntos de conexión privados de los recursos de PaaS. Los nombres de dominio completos (FQDN) de destino son:
*.azurewebsites.net*.database.windows.net*.core.windows.net*.vaultcore.azure.net
La configuración de firewall y red virtual para Azure SQL, la cuenta de Azure Storage y Azure Key Vault permite el tráfico solo desde la Subred de integración con la red virtual. La configuración no permite la comunicación con ninguna otra red virtual ni con la red pública de Internet.
Componentes
- Azure App Service hospeda las aplicaciones web y las aplicaciones de funciones, lo que permite escalabilidad automática y alta disponibilidad sin tener que administrar la infraestructura.
- Azure SQL Database es un servicio administrado de base de datos relacional de uso general que admite datos relacionales, datos espaciales, JSON y XML.
- La cuenta de Azure Storage proporciona un espacio de nombres único para los datos de Azure Storage que es accesible desde cualquier lugar del mundo mediante HTTP o HTTPS. Contiene todos los objetos de datos de Azure Storage: blobs, recursos compartidos de archivos, colas, tablas y discos.
- Azure Key Vault es un servicio para almacenar y acceder de forma segura a claves de API, contraseñas, certificados, claves criptográficas o cualquier otro secreto usado por servicios y aplicaciones en la nube.
- Azure Virtual Network es el bloque de creación fundamental para las redes privadas en Azure. Los recursos de Azure, como las máquinas virtuales, se pueden comunicar entre sí, con Internet y con redes del entorno local de forma segura a través de Virtual Network.
- Azure Private Link proporciona un punto de conexión privado en una red virtual para la conectividad con servicios PaaS de Azure, como Azure Storage y SQL Database, o con servicios de clientes o asociados.
- El emparejamiento privado de Azure ExpressRoute amplía las redes locales a la nube de Microsoft a través de una conexión privada. También puede establecer una VPN de sitio a sitio entre el entorno local y la red de Azure en lugar de usar Azure ExpressRoute.
- Azure Firewall es un servicio de seguridad de red administrado y basado en la nube que protege los recursos de red virtual de Azure.
- La zona DNS privada proporciona un servicio DNS confiable y seguro para administrar y resolver nombres de dominio en la red virtual.
- DNS Private Resolver permite consultar zonas privadas de Azure DNS desde un entorno local, y viceversa, sin implementar servidores DNS basados en máquina virtual.
Alternativas
Para la conectividad privada, un enfoque alternativo es usar App Service Environment para hospedar la aplicación web en un entorno aislado. Para la base de datos, puede implementar Azure SQL Managed Instance de forma nativa en una red virtual, por lo que no necesita la integración con la red virtual ni con puntos de conexión privados. Estas ofertas suelen ser más costosas porque proporcionan una implementación aislada de un solo inquilino y otras características.
Si tiene un entorno de App Service Environment pero no usa SQL Managed Instance, puede seguir usando un punto de conexión privado para la conectividad privada a una base de datos de Azure SQL. Si ya tiene SQL Managed Instance, pero usa App Service multiinquilino, puede seguir usando la integración con la red virtual regional para conectarse a la dirección privada de SQL Managed Instance.
En el caso de algunos otros servicios de Azure, como Key Vault o Storage, no hay ninguna alternativa al uso de puntos de conexión privados para conexiones privadas y muy seguras desde Web Apps.
Posibles casos de uso
- Acceda a una aplicación web multiinquilino o a una aplicación de funciones de forma privada con seguridad mejorada a través de su punto de conexión privado desde una red local o desde redes virtuales de Azure.
- Conéctese desde una aplicación web o una aplicación de funciones a ofertas de plataforma como servicio (PaaS) de Azure:
- Otra aplicación web
- SQL Database
- Azure Storage
- Key Vault
- Cualquier otro servicio que admita puntos de conexión privados de Azure para la conectividad entrante.
Consideraciones
Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.
El uso de un punto de conexión privado para la aplicación web le permite:
- Proteger la aplicación web mediante la configuración del punto de conexión privado, lo que elimina la exposición pública.
- Conectarse con seguridad mejorada a Web Apps desde redes locales que se conectan a la red virtual mediante un emparejamiento privado de VPN o ExpressRoute. Las conexiones entrantes a la aplicación web se permiten desde la red local o solo desde la red virtual de Azure.
- Evite la filtración de datos de la red virtual.
Puede seguir mejorando la seguridad de la conexión entrante a la aplicación web poniendo delante de la aplicación un servicio como Azure Application Gateway o Azure Front Door, opcionalmente con Azure Web Application Firewall. Al permitir un punto de conexión privado en la aplicación web, no se evalúa la configuración de las restricciones de acceso de la aplicación web.
Este escenario también mejora la seguridad de la conexión saliente desde una aplicación web de App Service a una dependencia de nivel inferior, como una base de datos, Storage o Key Vault.
Puede configurar el enrutamiento de aplicaciones para enrutar todo el tráfico o solo el tráfico privado (también conocido como tráfico RFC1918) a su red virtual. Este comportamiento se configura mediante la opción Route All (Enrutar todo). Si la opción Enrutar todo (Enrutar todo) está deshabilitada, la aplicación solo enruta el tráfico privado a la red virtual. Para bloquear el tráfico a las direcciones públicas, habilite Route All (Enrutar todo) en la red virtual. También puede usar un grupo de seguridad de red para bloquear el tráfico saliente a los recursos de la red virtual o Internet. Cuando Route All (Enrutar todo) no está habilitado, los grupos de seguridad de red solo se aplican al tráfico RFC1918.
En este ejemplo, la aplicación web no necesita comunicarse con ningún servicio que no esté en la red virtual, por lo que Route All (Enrutar todo) está habilitado.
Una consideración de seguridad importante en este escenario es la configuración del firewall para los recursos de PaaS.
Opciones de firewall de SQL Database
Sin usar conectividad privada, puede agregar reglas de firewall que permitan el tráfico de entrada solo desde los intervalos de direcciones IP especificados. Otro enfoque es permitir que el servicio de Azure acceda al servidor. Este enfoque bloquea el firewall para permitir solo el tráfico desde Azure. Sin embargo, este tráfico incluye todas las regiones de Azure y otros clientes.
También puede agregar una regla de firewall más restrictiva para permitir que solo las direcciones IP de salida de la aplicación tengan acceso a la base de datos. No obstante, dado que App Service es un servicio multiinquilino, estas direcciones IP se comparten con otros clientes y permiten el tráfico de estos en el mismo stamp de implementación, que usa las mismas direcciones IP de salida.
El uso de conectividad privada a través de la red virtual proporciona estas opciones de firewall para ayudar a evitar que otros usuarios accedan a la base de datos:
- Crear una regla de red virtual que permita el tráfico solo desde la subred regional delegada mediante la integración con la red virtual, Subred de integración con la red virtual en este ejemplo. La subred delegada debe tener un punto de conexión de servicio configurado para Microsoft.Sql para que la base de datos pueda identificar el tráfico de la subred.
- Configurar el firewall para denegar el acceso a la red pública. Al hacerlo, se desactivan todas las demás reglas de firewall y la base de datos se vuelve accesible solo a través de su punto de conexión privado.
La opción de denegar el acceso a la red pública es la configuración más segura. Pero, si usa esta opción, el acceso a la base de datos solo es posible a través de la red virtual que hospeda el punto de conexión privado. Para conectarse a la base de datos, cualquier cosa que no sea la aplicación web debe tener conectividad directa con la red virtual.
Por ejemplo, las implementaciones o las conexiones manuales de urgencia desde SQL Server Management Studio (SSMS) en las máquinas locales no pueden acceder a la base de datos excepto mediante la conectividad de VPN o ExpressRoute en la red virtual. También puede conectarse de forma remota a una máquina virtual de la red virtual y usar SSMS desde allí. En situaciones excepcionales, puede permitir temporalmente el acceso a la red pública y reducir el riesgo mediante el uso de otras opciones de configuración.
Opciones de firewall de la cuenta de Storage y Key Vault
Las cuentas de Storage y los almacenes de claves tienen un punto de conexión público al que se puede acceder desde Internet. También puede crear puntos de conexión privados para la cuenta de almacenamiento y el almacén de claves. Al hacerlo, asigna a estos servicios una dirección IP privada de la red virtual y ayuda a proteger todo el tráfico entre la red virtual y el servicio correspondiente a través de un vínculo privado.
Al crear un punto de conexión privado, la Subred de integración con la red virtual puede acceder al servicio de forma privada y con seguridad mejorada a través de un vínculo privado. Sin embargo, la cuenta de almacenamiento y el almacén de claves siguen siendo accesibles desde otras redes virtuales de Azure. Para bloquear el acceso desde cualquier otra red virtual, cree el punto de conexión de servicio para esta subred delegada.
Disponibilidad
Private Link admite App Service, Azure SQL Database, Azure Storage y Azure Key Vault está disponible en todas las regiones públicas. Para comprobar la disponibilidad en otras regiones, consulte Disponibilidad de Azure Private Link.
Private Link presenta otro componente y una consideración de disponibilidad en la arquitectura. El servicio Private Link tiene un Acuerdo de Nivel de Servicio de alta disponibilidad. Debe tener en cuenta este Acuerdo de Nivel de Servicio al calcular el Acuerdo de Nivel de Servicio compuesto de toda la solución.
Escalabilidad
Para información sobre la integración de Azure Private Link para servicios PaaS con zonas DNS privadas de Azure en arquitecturas de red de tipo hub-and-spoke, consulte Integración de Private Link y DNS a gran escala.
Emparejamiento global
Cualquier servicio de cualquier región de Azure que se pueda conectar mediante la red virtual puede alcanzar los puntos de conexión privados de los servicios PaaS, por ejemplo, mediante el emparejamiento de red virtual en topologías en estrella de tipo hub-and-spoke. Sin embargo, para la integración con la red virtual regional de App Service, las redes virtuales emparejadas deben estar en la misma región de Azure.
La falta de compatibilidad con el emparejamiento global significa que no se puede usar esta solución para la conectividad entre regiones desde App Service a una base de datos u otro punto de conexión privado de otra región de Azure. Por ejemplo, esta solución no funcionaría con implementaciones de varias regiones para permitir una conmutación por error parcial, en la que la aplicación web permanece activa en una región, pero debe conectarse a una base de datos conmutada por error en otra región, o viceversa. Pero existen otras soluciones para esta situación.
Si necesita conectar Web Apps a una red virtual de otra región, puede configurar la integración con la red virtual necesaria para la puerta de enlace. La limitación es que la integración con la red virtual necesaria para la puerta de enlace no se puede usar con una red virtual conectada con Azure ExpressRoute.
Registro y supervisión
Azure Private Link se integra con Azure Monitor, que permite ver si los datos fluyen.
También puede usar el servicio de solución de problemas de conexión de Azure Network Watcher para realizar un seguimiento de la conectividad desde una máquina virtual de una red virtual hasta el FQDN del recurso de punto de conexión privado.
Optimización de costos
La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.
No hay ningún costo adicional para la integración con red virtual regional de App Service en planes de tarifa compatibles en planes de tarifa Básico, Estándar, Premium v2, Premium v3, App Service aislado v2 y planes Premium de Azure Functions.
El punto de conexión privado está disponible para las aplicaciones web de Windows y las aplicaciones web Linux, en contenedores o no, hospedadas en planes de App Service Básico, Estándar, Premium v2, Premium v3 y Aislado, y también para las aplicaciones de funciones implementadas en un plan Premium.
El servicio Azure Private Link que habilita los puntos de conexión privados para los servicios PaaS tiene un costo asociado que se basa en una tarifa por hora más una premium sobre el ancho de banda. Consulte la página Precios de Private Link para más información. Las conexiones desde una red virtual de cliente hasta Azure Firewall en la red virtual de centro tienen un costo. No se le cobra por las conexiones de Azure Firewall en la red virtual de centro a los puntos de conexión privados de una red virtual emparejada.
Los costos de la zona DNS privada de Azure se basan en el número de zonas DNS hospedadas en Azure y en el número de consultas de DNS recibidas.
Para explorar el costo de ejecutar este escenario, use la calculadora de precios de Azure. Todos los servicios descritos en este artículo están preconfigurados con valores predeterminados razonables para una aplicación a pequeña escala. Para ver cómo cambiarían los precios en su caso de uso, cambie las variables apropiadas para que coincidan con el uso esperado.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribió el siguiente colaborador.
Autor principal:
- Ankit Singhal | Arquitecto de soluciones en la nube
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
- Consulte las instrucciones paso a paso sobre cómo integrar Azure Functions con una red virtual de Azure mediante puntos de conexión privados.
- Consulte los pasos para configurar las reglas de aplicación de Azure Firewall para inspeccionar el tráfico destinado a los puntos de conexión privados en varias topologías de red.
- Para más información sobre los escenarios de entrada y salida para App Service y las características que se van a usar en cada caso, consulte la introducción a las características de red de App Service.
- Para más información sobre los puntos de conexión privados de Azure Web Apps, consulte Uso de puntos de conexión privados para Azure Web Apps.
- Para más información sobre la integración de aplicaciones web multiinquilino con la red virtual de Azure, consulte Integración de una aplicación con una red virtual de Azure.
- El FQDN de algunos de los servicios PaaS podría resolverse automáticamente en una dirección IP pública. Para información sobre cómo invalidar la configuración de DNS para conectarse al punto de conexión privado, consulte Configuración de DNS del punto de conexión privado de Azure.
Recursos relacionados
- Conectividad privada de una aplicación web a Azure SQL Database
- Tutorial: Integración de Azure Functions con una red virtual de Azure mediante puntos de conexión privados
- Tutorial: Establecimiento del acceso a un sitio privado de Azure Functions
- Uso de referencias de Key Vault para App Service y Azure Functions