Uso de Azure Front Door en una solución multiinquilino

Azure Front Door es una nube moderna de red de entrega de contenido (CDN) que proporciona acceso rápido y confiable entre los usuarios y el contenido web estático y dinámico de las aplicaciones en todo el mundo. En este artículo se describen algunas de las características de Azure Front Door que son útiles al trabajar en sistemas multiinquilino. También proporciona vínculos a instrucciones y ejemplos adicionales.

Al usar Azure Front Door como parte de una solución multiinquilino, debe tomar algunas decisiones en función del diseño y los requisitos de la solución. Debe tener en cuenta los siguientes factores:

• ¿Cuántos inquilinos tiene y cuántos espera tener en el futuro?
• ¿Comparte el nivel de aplicación entre varios inquilinos, implementa muchas instancias de aplicación de inquilino único o implementa stamps de implementación independientes compartidas por varios inquilinos?
• ¿Los inquilinos quieren traer sus propios nombres de dominio?
• ¿Usará dominios con caracteres comodín?
• ¿Necesita usar sus propios certificados TLS o Microsoft administrará los certificados TLS?
• ¿Ha considerado las cuotas y los límites que se aplican a Azure Front Door? ¿Sabe a qué límites se aproximará a medida que crezca? Si sospecha que se aproximará a estos límites, considere la posibilidad de usar varios perfiles de Azure Front Door. O considere si puede cambiar la forma en que usa Azure Front Door para evitar los límites. Tenga en cuenta que la SKU Premium tiene límites más altos que la SKU estándar.
• ¿Tiene usted o sus inquilinos requisitos para el filtrado de direcciones IP, el bloqueo geográfico o la personalización de reglas de WAF?
• ¿Todos los servidores de aplicaciones de los inquilinos son accesibles desde Internet?

Características de Azure Front Door que admiten multiinquilinato

En esta sección se describen varias características clave de Azure Front Door que son útiles para las soluciones multiinquilino. Describe cómo Azure Front Door puede ayudarle a configurar dominios personalizados, incluida información sobre dominios con caracteres comodín y certificados TLS. También resume cómo puede usar las funcionalidades de enrutamiento de Azure Front Door para admitir multiinquilinato.

Dominios personalizados

Azure Front Door proporciona un nombre de host predeterminado para cada punto de conexión que cree, por ejemplo, contoso.z01.azurefd.net. En la mayoría de las soluciones, asociará su propio nombre de dominio con el punto de conexión de Azure Front Door. Los nombres de dominio personalizados le permiten usar su propia personalización de marca y configurar el enrutamiento en función del nombre de host que se proporciona en la solicitud de un cliente.

En una solución multiinquilino, puede usar nombres de dominio o subdominios específicos del inquilino y configurar Azure Front Door para enrutar el tráfico del inquilino al grupo de origen correcto para la carga de trabajo de ese inquilino. Por ejemplo, puede configurar un nombre de dominio personalizado como tenant1.app.contoso.com. Con Azure Front Door, puede configurar varios dominios personalizados en un único perfil de Azure Front Door.

Para obtener más información, consulte Adición de un dominio personalizado a una instancia de Front Door.

Dominios con caracteres comodín

Los dominios con caracteres comodín simplifican la configuración de registros DNS y la configuración de enrutamiento del tráfico de Azure Front Door cuando se usa un dominio troncal compartido y subdominios específicos del inquilino. Por ejemplo, suponga que los inquilinos acceden a sus aplicaciones mediante subdominios como tenant1.app.contoso.com y tenant2.app.contoso.com. Puede configurar un dominio con caracteres comodín, *.app.contoso.com, en lugar de configurar individualmente cada dominio específico del inquilino.

Azure Front Door admite la creación de dominios personalizados que usan caracteres comodín. Puede entonces configurar una ruta para las solicitudes que llegan al dominio con caracteres comodín. Al incorporar un nuevo inquilino, no es necesario volver a configurar los servidores DNS, emitir nuevos certificados TLS ni actualizar la configuración del perfil de Azure Front Door.

Los dominios con caracteres comodín funcionan bien si envía todo el tráfico a un único grupo de origen. Pero si tiene stamps independientes de la solución, un dominio con caracteres comodín de nivel único no es suficiente. Debe usar dominios troncales de varios niveles o proporcionar una configuración adicional, por ejemplo, invalidando las rutas que se van a usar para el subdominio de cada inquilino. Para obtener más información, consulte Consideraciones al usar nombres de dominio en una solución multiinquilino.

Azure Front Door no emite certificados TLS administrados para dominios con caracteres comodín, por lo que debe comprar y proporcionar su propio certificado.

Para obtener más información, consulte Dominios con caracteres comodín.

Certificados TLS administrados

La adquisición e instalación de certificados TLS puede ser compleja y propensa a errores. Y los certificados TLS expiran después de un período de tiempo, normalmente un año, y deben volver a emitirse e instalarse para evitar interrupciones en el tráfico de la aplicación. Cuando se usan certificados TLS administrados por Azure Front Door, Microsoft es responsable de emitir, instalar y renovar certificados para el dominio personalizado.

La aplicación de origen podría hospedarse en otro servicio de Azure que también proporciona certificados TLS administrados, como Azure App Service. Azure Front Door funciona de forma transparente con el otro servicio para sincronizar los certificados TLS.

Si permite que los inquilinos proporcionen sus propios dominios personalizados y quiere que Azure Front Door emita certificados para estos nombres de dominio, los inquilinos no deben configurar registros CAA en sus servidores DNS que podrían impedir que Azure Front Door emita certificados en su nombre. Para obtener más información, consulte Certificados TLS/SSL.

Para obtener más información sobre los certificados TLS, consulte TLS de extremo a extremo con Azure Front Door.

Enrutamiento

Una aplicación multiinquilino puede tener uno o varios stamps de aplicación que atienden a los inquilinos. Los stamp se usan con frecuencia para habilitar implementaciones de varias regiones y para admitir el escalado de una solución a un gran número de inquilinos.

Azure Front Door tiene un conjunto eficaz de funcionalidades de enrutamiento que pueden admitir una serie de arquitecturas multiinquilino. Puede usar el enrutamiento para distribuir el tráfico entre orígenes dentro de un stamp o para enviar tráfico al sello correcto para un inquilino específico. Puede configurar el enrutamiento en función de nombres de dominio individuales, nombres de dominio con caracteres comodín y rutas de acceso de dirección URL. Y puede usar el motor de reglas para personalizar aún más el comportamiento de enrutamiento.

Para más información, vea Introducción a la arquitectura de enrutamiento.

Motor de reglas

Puede usar el motor de reglas de Azure Front Door para personalizar el modo en que Azure Front Door procesa las solicitudes en el perímetro de red. El motor de reglas permite ejecutar pequeños bloques de lógica dentro de la canalización de procesamiento de solicitudes de Azure Front Door. Puede usar el motor de reglas para una variedad de tareas, incluidas las siguientes:

• Recuperar información sobre la solicitud HTTP, incluidos los segmentos de la dirección URL y la ruta de acceso, y propagar la información a otra parte de la solicitud.
• Modificar los elementos de la solicitud HTTP antes de enviarlos al origen.
• Modificar algunas partes de la respuesta HTTP antes de que se devuelva al cliente.
• Invalidar la configuración de enrutamiento de una solicitud, por ejemplo, cambiando el grupo de origen al que se debe enviar una solicitud.

Estos son algunos ejemplos de cómo usar el motor de reglas Azure Front Door en una solución multiusuario:

• Supongamos que implementa una capa de aplicación multiinquilino en la que también usa subdominios con caracteres comodín específicos del inquilino, como se describe en los escenarios de ejemplo siguientes. Puede usar el motor de reglas para extraer el identificador de inquilino del subdominio de solicitud y agregarlo a un encabezado de solicitud. Esta regla podría ayudar a la capa de aplicación a determinar de qué inquilino procede la solicitud.
• Supongamos que implementa un nivel de aplicación multiinquilino y usa el enrutamiento basado en rutas de acceso (por ejemplo, https://application.contoso.com/tenant1/welcome y https://application.contoso.com/tenant2/welcome para los inquilinos 1 y 2, respectivamente). Puede usar el motor de reglas para extraer el segmento del identificador de inquilino del segmento de la ruta URL y reescribir la URL para incluir el identificador de inquilino en un parámetro de cadena de consulta o encabezado de solicitud para que la aplicación lo consuma.

Para obtener más información, consulte ¿Qué es el motor de reglas de Azure Front Door?.

Escenarios de ejemplo

En los escenarios de ejemplo siguientes se muestra cómo puede configurar varias arquitecturas multiinquilino en Azure Front Door y cómo las decisiones que tome pueden afectar a la configuración de DNS y TLS.

Muchas soluciones multiinquilino implementan el patrón de stamps de implementación. Cuando se usa este enfoque de implementación, normalmente se implementa un único perfil compartido de Azure Front Door y se usa Azure Front Door para enrutar el tráfico entrante al stamp adecuado. Este modelo de implementación es el más común y los escenarios del 1 al 4 de este artículo muestran cómo se puede usar para cumplir una serie de requisitos.

Sin embargo, en algunas situaciones, puede implementar un perfil de Azure Front Door en cada stamp de la solución. En el escenario 5 se describe este modelo de implementación.

Escenario 1: dominio con caracteres comodín administrado por el proveedor, stamp único

Contoso está creando una solución multiinquilino pequeña. La empresa implementa un único stamp en una sola región y ese stamp atiende a todos sus inquilinos. Todas las solicitudes se enrutan al mismo servidor de aplicaciones. Contoso decidió usar dominios con caracteres comodín para todos los inquilinos, como tenant1.contoso.com y tenant2.contoso.com.

Contoso implementa Azure Front Door mediante esta configuración:

Configuración de DNS

Configuración única: Contoso configura dos entradas DNS:

• Un registro TXT con caracteres comodín para *.contoso.com. Se establece en el valor especificado por Azure Front Door durante el proceso de incorporación de dominio personalizado.
• Un registro CNAME con caracteres comodín, *.contoso.com, que es un alias para el punto de conexión de Azure Front Door de Contoso: contoso.z01.azurefd.net.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de TLS

Configuración única: Contoso compra un certificado TLS con caracteres comodín, lo agrega a un almacén de claves y concede a Azure Front Door acceso al almacén.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de Azure Front Door

Configuración única: Contoso crea un perfil de Azure Front Door y un único punto de conexión. Agregan un dominio personalizado con el nombre *.contoso.com y asocian su certificado TLS con caracteres comodín con el recurso de dominio personalizado. Después, configuran un único grupo de origen que contiene un único origen para su servidor de aplicaciones. Por último, configuran una ruta para conectar el dominio personalizado al grupo de origen.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Ventajas

• Esta configuración es relativamente fácil de configurar y proporciona a los clientes direcciones URL con marca Contoso.
• El enfoque admite un gran número de inquilinos.
• Cuando se incorpora un nuevo inquilino, Contoso no necesita realizar cambios en los certificados de Azure Front Door, DNS o TLS.

Inconvenientes

• Este enfoque no se escala fácilmente más allá de un solo stamp de aplicación o región.
• Contoso debe comprar un certificado TLS con caracteres comodín y renovarlo e instalarlo cuando expire.

Escenario 2: dominio con caracteres comodín administrado por el proveedor, varios stamps

Proseware está creando una solución multiinquilino en varios stamps que se implementan en Australia y Europa. Todas las solicitudes dentro de una sola región las atiende el stamp de esa región. Al igual que Contoso, Proseware decidió usar dominios con caracteres comodín para todos los inquilinos, como tenant1.proseware.com y tenant2.proseware.com.

Proseware implementa Azure Front Door mediante esta configuración:

Configuración de DNS

Configuración única: Proseware configura dos entradas DNS:

• Un registro TXT con caracteres comodín para *.proseware.com. Se establece en el valor especificado por Azure Front Door durante el proceso de incorporación de dominio personalizado.
• Un registro CNAME con caracteres comodín, *.proseware.com, que es un alias para el punto de conexión de Azure Front Door de Proseware: proseware.z01.azurefd.net.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de TLS

Configuración única: Proseware compra un certificado TLS con caracteres comodín, lo agrega a un almacén de claves y concede a Azure Front Door acceso al almacén.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de Azure Front Door

Configuración única: Proseware crea un perfil de Azure Front Door y un único punto de conexión. La empresa configura varios grupos de origen, uno por stamp de aplicación o servidor en cada región.

Cuando se incorpora un nuevo inquilino: Proseware agrega un recurso de dominio personalizado a Azure Front Door. Usan el nombre *.proseware.com y asocian su certificado TLS con caracteres comodín con el recurso de dominio personalizado. A continuación, crean una ruta para especificar a qué grupo de origen (stamp) se deben dirigir las solicitudes del inquilino. En el diagrama anterior, tenant1.proseware.com se enruta al grupo de origen de la región de Australia y tenant2.proseware.com se enruta al grupo de origen de la región de Europa.

Ventajas

• Cuando se incorporan nuevos inquilinos, no se requieren cambios de configuración de DNS o TLS.
• Proseware mantiene una única instancia de Azure Front Door para enrutar el tráfico a varios stamps entre varias regiones.

Inconvenientes

• Proseware debe volver a configurar Azure Front Door cada vez que se incorpora un nuevo inquilino.
• Proseware debe prestar atención a las cuotas y límites de Azure Front Door, especialmente en cuanto al número de rutas y dominios personalizados, y el límite de enrutamiento compuesto.
• Proseware debe comprar un certificado TLS con caracteres comodín.
• Proseware es responsable de renovar e instalar el certificado cuando expire.

Escenario 3: subdominios de caracteres comodín administrados por el proveedor y basados en stamps

Fabrikam está creando una solución multiinquilino. La empresa implementa stamps en Australia y Estados Unidos. Todas las solicitudes dentro de una sola región serán atendidas por el stamp de esa región. Fabrikam usará dominios troncales basados en stamps, como tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.com y tenant3.us.fabrikam.com.

La empresa implementa Azure Front Door mediante esta configuración:

Configuración de DNS

Configuración única: Fabrikam configura las dos entradas DNS con caracteres comodín siguientes para cada stamp.

• Un registro TXT con caracteres comodín para cada stamp: *.australia.fabrikam.com y *.us.fabrikam.com. Se establecen en los valores especificados por Azure Front Door durante el proceso de incorporación de dominio personalizado.
• Un registro CNAME con caracteres comodín para cada stamp, *.australia.fabrikam.com y *.us.fabrikam.com, que son alias para el punto de conexión de Azure Front Door: fabrikam.z01.azurefd.net.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de TLS

Configuración única: Fabrikam compra un certificado TLS con caracteres comodín para cada stamp, los agrega a un almacén de claves y concede a Azure Front Door acceso al almacén.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Configuración de Azure Front Door

Configuración única: Fabrikam crea un perfil de Azure Front Door y un único punto de conexión. Configuran un grupo de origen para cada stamp. Crean dominios personalizados, mediante un carácter comodín, para cada subdominio basado en stamps: *.australia.fabrikam.com y *.us.fabrikam.com. Crean una ruta para el dominio personalizado de cada stamp para enviar tráfico al grupo de origen adecuado.

Cuando se incorpora un nuevo inquilino: No se requiere ninguna configuración adicional.

Ventajas

• Este enfoque permite que Fabrikam se escale a un gran número de inquilinos en varios stamps.
• Cuando se incorporan nuevos inquilinos, no se requieren cambios de configuración de DNS o TLS.
• Fabrikam mantiene una única instancia de Azure Front Door para enrutar el tráfico a varios stamps entre varias regiones.

Inconvenientes

• Dado que las direcciones URL usan una estructura de dominio troncal de varias partes, las direcciones URL pueden ser más complejas para que los usuarios trabajen con ellas.
• Fabrikam debe comprar varios certificados TLS con caracteres comodín.
• Fabrikam es responsable de renovar e instalar los certificados TLS cuando expiren.

Escenario 4: dominios personales

Adventure Works Cycles está creando una solución multiinquilino. La empresa implementa stamps en varias regiones, como Australia y Estados Unidos. Todas las solicitudes dentro de una sola región serán atendidas por el stamp de esa región. Adventure Works permitirá que sus inquilinos traigan sus propios nombres de dominio. Por ejemplo, el inquilino 1 podría configurar un nombre de dominio personalizado como tenant1app.tenant1.com.

La empresa implementa Azure Front Door mediante esta configuración:

Configuración de DNS

Configuración única: ninguna.

Cuando se incorpora un nuevo inquilino: el inquilino debe crear dos registros en su propio servidor DNS:

• Un registro TXT para la validación de dominio. Por ejemplo, el inquilino 1 debe configurar un registro TXT denominado tenant1app.tenant1.com y establecerlo en el valor especificado por Azure Front Door durante el proceso de incorporación de dominio personalizado.
• Un registro CNAME con alias en el punto de conexión de Azure Front Door de Adventure Works. Por ejemplo, el inquilino 1 debe configurar un registro CNAME denominado tenant1app.tenant1.com y asignarlo a adventureworks.z01.azurefd.net.

Configuración de TLS

Adventure Works y sus inquilinos deben decidir quién emite certificados TLS:

• La opción más fácil es usar Azure Front Door para emitir y administrar los certificados, pero los inquilinos no deben configurar registros CCA en sus servidores DNS. Si lo hacen, los registros podrían impedir que la entidad de certificación de Azure Front Door emita certificados.
• Como alternativa, los inquilinos pueden proporcionar sus propios certificados. Deben trabajar con Adventure Works para cargar el certificado en un almacén de claves y proporcionar acceso a Azure Front Door.

Configuración de Azure Front Door

Configuración única: Adventure Works crea un perfil de Azure Front Door y un único punto de conexión. Configuran un grupo de origen para cada stamp. No crean recursos ni rutas de dominio personalizados.

Cuando se incorpora un nuevo inquilino: Adventure Works agrega un recurso de dominio personalizado a Azure Front Door. Usan el nombre de dominio proporcionado por el inquilino y asocian el certificado TLS adecuado con el recurso de dominio personalizado. A continuación, crean una ruta para especificar a qué grupo de origen (stamp) se deben dirigir las solicitudes del inquilino. En el diagrama anterior, tenant1app.tenant1.com se enruta al grupo de origen de la región de Australia y tenant2app.tenant3.com se enruta al grupo de origen de la región de EE. UU.

Ventajas

• Los clientes pueden proporcionar sus propios nombres de dominio. Azure Front Door enruta de forma transparente las solicitudes a la solución multiinquilino.
• Adventure Works mantiene una única instancia de Azure Front Door para enrutar el tráfico a varios stamps entre varias regiones.

Inconvenientes

• Adventure Works debe volver a configurar Azure Front Door cada vez que se incorpore un nuevo inquilino.
• Los inquilinos deben participar en el proceso de incorporación. Deben realizar cambios en DNS y, posiblemente, emitir certificados TLS.
• Los inquilinos controlan sus registros DNS. Los cambios en los registros DNS pueden afectar a su capacidad de acceder a la solución de Adventure Works.
• Adventure Works debe prestar atención a las cuotas y límites de Azure Front Door, especialmente en cuanto al número de rutas y dominios personalizados, y el límite de enrutamiento compuesto.

Escenario 5: perfil de Azure Front Door por stamp

Puede implementar un perfil de Azure Front Door para cada stamp. Si tiene 10 stamps, implementará 10 instancias de Azure Front Door. Este enfoque puede ser útil si necesita restringir el acceso de administración de la configuración de Azure Front Door de cada stamp. También puede ser útil si necesita usar varios perfiles de Azure Front Door para evitar superar las cuotas o límites de recursos.

Sugerencia

Azure Front Door es un recurso global. Incluso si implementa stamps de ámbito regional, cada perfil de Azure Front Door se distribuye globalmente. Debe considerar si realmente necesita implementar varios perfiles de Azure Front Door y las ventajas que obtiene al hacerlo.

Si tiene un stamp que sirve a varios inquilinos, debe tener en cuenta cómo enruta el tráfico a cada inquilino. Revise los enfoques descritos en los escenarios anteriores y considere la posibilidad de combinar enfoques para satisfacer sus requisitos.

Ventajas

• Si amplía la configuración en varios perfiles, es menos probable que alcance los límites de recursos de Azure Front Door. Por ejemplo, si necesita admitir un gran número de dominios personalizados, puede dividir los dominios entre varios perfiles de Azure Front Door y no superar los límites de cada perfil.
• Este enfoque le permite definir el ámbito de los permisos de administración de recursos de Azure Front Door. Puede usar el control de acceso basado en rol (RBAC) de Azure para conceder a los administradores acceso a un perfil de stamp único.

Inconvenientes

• Este enfoque suele suponer un alto costo porque se implementan más perfiles. Para obtener más información, consulte Descripción de la facturación de Front Door.
• Hay un límite en el número de perfiles de Azure Front Door que puede implementar en una sola suscripción de Azure. Para obtener más información, consulte Cuotas y límites de Front Door.
• Debe configurar el perfil de Azure Front Door de cada stamp por separado y debe administrar la configuración de DNS, los certificados TLS y la configuración de TLS para cada stamp.

Colaboradores

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

Creadores de entidad de seguridad:

• Raj Nemani | Director y creador de estrategias de tecnología de asociados
• John Downs | Ingeniero principal de software

Otros colaboradores:

• Mick Alberts | Escritor técnico
• Fernando Antivero | Desarrollador de pila completa e ingeniero de plataforma en la nube
• Duong Au | Desarrollador de contenido sénior, C+E Skilling Content RD
• Harikrishnan M B (HARI) | Administrador de productos 2, Redes de Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

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

Pasos siguientes

• Curso: Introducción a Azure Front Door
• Introducción a Azure Front Door
• ¿Qué es Azure Front Door?

Recursos relacionados

• Diseño de soluciones multiinquilino en Azure
• Lista de comprobación para la arquitectura y la creación de soluciones de multiinquilino en Azure
• Modelos de inquilinato que se deben tener en cuenta para una solución multiinquilino