Consideraciones al usar nombres de dominio en una solución multiinquilino

En muchas aplicaciones web multiinquilino, se puede usar un nombre de dominio como una manera de identificar un inquilino, para ayudar a enrutar las solicitudes a la infraestructura correcta y para proporcionar una experiencia de marca a los clientes. Dos enfoques comunes son usar subdominios y nombres de dominio personalizados. En esta página, se proporcionan instrucciones para los responsables de la toma de decisiones técnicas sobre los enfoques que puede tener en cuenta y sus soluciones.

Subdominios

Cada inquilino podría obtener un subdominio único con un nombre de dominio compartido común, con un formato como tenant.provider.com.

Veamos un ejemplo de una solución multiinquilino creada por Contoso. Los clientes compran el producto de Contoso para ayudar a administrar la generación de facturas. Se podría asignar su propio subdominio a todos los inquilinos de Contoso, bajo el nombre de dominio contoso.com. O bien, si Contoso usa implementaciones regionales, cada inquilino podría asignar subdominios en los dominios us.contoso.com y eu.contoso.com. En este artículo, nos referimos a ellos como dominios troncales. Cada cliente obtiene su propio subdominio en el dominio troncal. Por ejemplo, Tailwind Toys podría tener asignado tailwind.contoso.com y Adventure Works podría tener asignado adventureworks.contoso.com.

Administración del espacio de nombres del dominio

Al crear subdominios en su propio nombre de dominio, debe tener en cuenta que podría tener varios clientes con nombres similares. Dado que comparten un único dominio raíz, el primer cliente en obtener un dominio determinado obtendrá su nombre preferido. A continuación, los clientes subsiguientes tienen que usar nombres de subdominios alternativos, ya que los nombres de dominio completos deben ser únicos globalmente.

DNS con caracteres comodín

Considere la posibilidad de usar entradas DNS con caracteres comodín para simplificar la administración de subdominios. En lugar de crear entradas DNS para tailwind.contoso.com, adventureworks.contoso.com, etc., podría crear en su lugar una entrada con caracteres comodín para *.contoso.com y dirigir todos los subdominios a una única dirección IP (registro A) o un nombre canónico (registro CNAME).

Subdominios con dominios troncales de varias partes

Muchas soluciones multiinquilino se reparten entre varias implementaciones físicas. Este es un enfoque común cuando es necesario cumplir los requisitos de residencia de datos o cuando quiere proporcionar un mejor rendimiento mediante la implementación de recursos más cercanos geográficamente a los usuarios.

Incluso dentro de una sola región, es posible que también tenga que repartir los inquilinos entre implementaciones independientes, para respaldar la estrategia de escalado. Si planea usar subdominios para cada inquilino, puede considerar una estructura de subdominios de varias partes.

Este es un ejemplo: Contoso publica una aplicación multiinquilino para sus cuatro clientes. Adventure Works y Tailwind Traders están en la Estados Unidos y sus datos se almacenan en una instancia compartida de EE. UU. de la plataforma de Contoso. Fabrikam y Worldwide Importers están en Europa y sus datos se almacenan en una instancia europea.

Si Contoso decide usar un único dominio troncal, contoso.com, para todos sus clientes, este es el aspecto que podría tener:

Las entradas DNS (necesarias para admitir esta configuración) pueden tener este aspecto:

Cada nuevo cliente que se incorpora requiere un nuevo subdominio y el número de subdominios crece con cada cliente.

Como alternativa, Contoso podría usar dominios troncales específicos de la región o la implementación, como se muestra a continuación:

A continuación, mediante el uso de DNS con caracteres comodín, las entradas DNS de esta implementación podrían tener este aspecto:

Contoso no necesita crear registros de subdominio para cada cliente. En su lugar, tienen un único registro DNS con caracteres comodín para la implementación de cada zona geográfica y los clientes nuevos que se agregan debajo de ese dominio troncal heredan automáticamente el registro CNAME.

Cada enfoque tiene ventajas y desventajas. Al usar un único dominio troncal, cada inquilino que incorpore requiere que se cree un nuevo registro DNS, lo que introduce una mayor sobrecarga operativa. Sin embargo, tiene más flexibilidad si necesita mover inquilinos entre implementaciones, ya que puede cambiar el registro CNAME para dirigir el tráfico a otra implementación. Este cambio no afectará a ningún otro inquilino. Al usar varios dominios troncales, hay una menor sobrecarga de administración. Además, puede reutilizar nombres de clientes entre varios dominios troncales regionales, ya que cada uno representa eficazmente su propio espacio de nombres.

Nombres de dominio personalizados

Es posible que quiera permitir que los clientes traigan sus propios nombres de dominio. Algunos clientes ven esto como un aspecto importante de su personalización de marca. También pueden ser necesarios nombres de dominio personalizados para cumplir los requisitos de seguridad de los clientes, especialmente si necesitan suministrar sus propios certificados TLS. Aunque puede parecer trivial permitir que los clientes traigan sus propios nombres de dominio, hay algunas complejidades ocultas en este enfoque y requiere una consideración cuidadosa.

Resolución de nombres

En última instancia, cada nombre de dominio se debe resolver en una dirección IP. Como ha visto, el enfoque mediante el cual se produce la resolución de nombres puede depender de si implementa una o varias instancias de su solución.

Volvamos a nuestro ejemplo. Uno de los clientes de Contoso, Fabrikam, ha pedido usar invoices.fabrikam.com como nombre de dominio personalizado para acceder al servicio de Contoso. Dado que Contoso tiene varias implementaciones de su plataforma, decide usar subdominios y registros CNAME para alcanzar sus requisitos de enrutamiento. Contoso y Fabrikam configuran los siguientes registros DNS:

Desde la perspectiva de la resolución de nombres, esta cadena de registros resuelve con precisión las solicitudes de invoices.fabrikam.com en la dirección IP de la implementación europea de Contoso.

Resolución de encabezados de host

La resolución de nombres es solo la mitad del problema. Todos los componentes web dentro de la implementación europea de Contoso deben saber cómo controlar las solicitudes que llegan con el nombre de dominio de Fabrikam en el encabezado de la solicitud Host. En función de las tecnologías web específicas que use Contoso, podría ser necesaria una configuración adicional del nombre de dominio de cada inquilino, lo que agrega una sobrecarga operativa adicional a la incorporación de inquilinos.

También puede considerar la posibilidad de volver a escribir los encabezados de host para que, independientemente del encabezado Host de la solicitud entrante, el servidor web vea un valor de encabezado coherente. Por ejemplo, Azure Front Door permite volver a escribir los encabezados Host para que, independientemente de la solicitud, el servidor de aplicaciones reciba un solo encabezado Host. Azure Front Door propaga el encabezado host original en el encabezado X-Forwarded-Host, de modo que la aplicación pueda inspeccionarlo y, luego, consultar el inquilino. Sin embargo, la reescritura de un encabezado Host puede causar otros problemas. Para más información, consulte Conservación del nombre de host HTTP original entre un proxy inverso y su aplicación web de back-end.

Validación del dominio

Es importante validar la propiedad de los dominios personalizados antes de incorporarlos. De lo contrario, corre el riesgo de que un cliente aparque un nombre de dominio de forma accidental o malintencionada.

Veamos el proceso de incorporación de Contoso para Adventure Works, que ha pedido usar invoices.adventureworks.com como nombre de dominio personalizado. Desafortunadamente, alguien cometió un error tipográfico cuando intentó incorporar el nombre de dominio personalizado y olvidó escribir la letra s. Por lo tanto, lo configuraron como invoices.adventurework.com. No solo el tráfico no fluye correctamente en Adventure Works, sino que cuando otra empresa llamada Adventure Work intente agregar su dominio personalizado a la plataforma de Contoso, se le indicará que el nombre de dominio ya está en uso.

Cuando se trabaja con dominios personalizados, especialmente dentro de un proceso de autoservicio o automatizado, es habitual requerir un paso de comprobación del dominio. Esto puede requerir que los registros CNAME se configuren antes de que se pueda agregar el dominio. Como alternativa, Contoso podría generar una cadena aleatoria y pedir a Adventure Works que agregue un registro TXT de DNS con el valor de la cadena. Esto impediría que se agregue el nombre de dominio hasta que se complete la comprobación.

Ataques de DNS pendiente y toma de control de subdominio

Cuando se trabaja con nombres de dominio personalizados, es posible que sea vulnerable a una clase de ataque llamada DNS pendiente o toma de control de subdominio. Este ataque se produce cuando los clientes desasocian su nombre de dominio personalizado del servicio, pero no eliminan el registro de su servidor DNS. En ese caso, esta entrada DNS apunta a un recurso inexistente y es vulnerable a una toma de control.

Veamos cómo podría cambiar la relación de Fabrikam con Contoso:

1. Fabrikam ha decidido dejar de trabajar con Contoso, por lo que han terminado su relación comercial.
2. Contoso ha desactivado el inquilino de Fabrikam y ha solicitado que fabrikam.contoso.com ya no funcione. Sin embargo, Fabrikam olvidó eliminar el registro CNAME para invoices.fabrikam.com.
3. Un actor malintencionado crea una nueva cuenta de Contoso y le asigna el nombre fabrikam.
4. El atacante incorpora el nombre de dominio personalizado invoices.fabrikam.com a su nuevo inquilino. Puesto que Contoso realiza la validación de dominio basada en CNAME, comprueba el servidor DNS de Fabrikam. Ven que el servidor DNS devuelve un registro CNAME para invoices.fabrikam.com que apunta a fabrikam.contoso.com. Contoso considera que la validación del dominio personalizado es correcta.
5. Si algún empleado de Fabrikam intentara acceder al sitio, las solicitudes parecerán funcionar. Si el atacante configura su inquilino de Contoso con la personalización de marca de Fabrikam, es posible que los empleados accedan engañados al sitio y proporcionen datos confidenciales a los que el atacante pueda acceder.

Las estrategias comunes para protegerse frente a ataques DNS pendientes son:

• Exigir que se elimine el registro CNAME antes de que el nombre de dominio se pueda quitar de la cuenta del inquilino.
• Prohibir la reutilización de los identificadores de inquilino y también exigir que el inquilino cree un registro TXT con un nombre que coincida con el nombre de dominio y un valor generado aleatoriamente, que cambia con cada intento de incorporación.

Certificados TLS/SSL

Seguridad de la capa de transporte (TLS) es un componente esencial cuando se trabaja con aplicaciones modernas. Proporciona confianza y seguridad a las aplicaciones web. La propiedad y administración de certificados TLS es algo que se debe tener en cuenta cuidadosamente en las aplicaciones multiinquilino.

Normalmente, el propietario de un nombre de dominio será responsable de emitir y renovar sus certificados. Por ejemplo, Contoso es responsable de emitir y renovar los certificados TLS para us.contoso.com, así como de un certificado con caracteres comodín para *.contoso.com. De forma similar, Fabrikam suele ser responsable de administrar los registros del dominio fabrikam.com, incluido invoices.fabrikam.com. El tipo de registro DNS de CAA (Autorización de la entidad de certificación) lo puede usar un propietario de dominio. Los registros CAA garantizan que solo determinadas entidades puedan crear certificados para el dominio.

Si planea permitir que los clientes traigan sus propios dominios, considere si planea emitir el certificado en nombre del cliente o si los clientes deben traer sus propios certificados. Cada opción tiene ventajas y desventajas.

• Si emite un certificado para un cliente, puede controlar la renovación del certificado, por lo que el cliente no tiene que recordar mantenerlo actualizado. Sin embargo, si los clientes tienen registros CAA en sus nombres de dominio, es posible que deban autorizarle para emitir certificados en su nombre.
• Si espera que los clientes emitan y proporcionen sus propios certificados, usted es responsable de recibir y administrar las claves privadas de forma segura, y es posible que tenga que recordar a los clientes que renueven el certificado antes de que expire, para evitar una interrupción en su servicio.

Varios servicios de Azure admiten la administración automática de certificados para dominios personalizados. Por ejemplo, Azure Front Door y App Service proporcionan certificados para dominios personalizados y controlan automáticamente el proceso de renovación. Esto elimina la carga de administrar certificados por parte del equipo de operaciones. Sin embargo, todavía debe tener en cuenta la cuestión de la propiedad y la autoridad, por ejemplo, si los registros CAA están en vigor y configurados correctamente. Además, debe asegurarse de que los dominios de los clientes están configurados para permitir los certificados administrados por la plataforma.

Colaboradores

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

Autor principal:

• John Downs | Ingeniero de clientes principal, FastTrack for Azure

Otros colaboradores:

• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

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

Pasos siguientes

Vuelva a Consideraciones de arquitectura para una solución multiinquilino. O bien, consulte Marco de buena arquitectura de Microsoft Azure.