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 y para proporcionar una experiencia de marca a los clientes. Dos enfoques comunes son usar subdominios y nombres de dominio personalizados.

Subdominios

Cada inquilino podría obtener un subdominio único bajo un nombre de dominio compartido común. 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 usa implementaciones regionales, 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. Puesto que comparten un único dominio troncal, el primer cliente que obtenga un dominio determinado tendrá su nombre preferido y los clientes posteriores tendrán que usar nombres de subdominio 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. Esto es habitual cuando se necesita cumplir los requisitos de residencia de datos o cuando desea 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, como parte de 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:

Las entradas DNS para esta implementación podrían tener el siguiente 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 heredarán 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. Esto no afectará a ningún otro inquilino. Al usar varios dominios troncales, hay una menor sobrecarga de administración y puede reutilizar los nombres de cliente en 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 podría ser necesario cumplir los requisitos de seguridad de los clientes, especialmente si deben proporcionar 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 por el que esto sucede puede depender de si implementa una sola instancia o varias instancias de la 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 lograr 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 para 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 ser conscientes de cómo controlar las solicitudes que llegan con el nombre de dominio de Fabrikam en el encabezado Host de la solicitud. En función de las tecnologías web específicas que use Contoso, esto puede requerir una configuración adicional para el 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 de host original en el encabezado X-Forwarded-Host, de modo que la aplicación pueda inspeccionarlo para resolver el inquilino.

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, 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.

Una estrategia común para protegerse frente a ataques de DNS pendiente es exigir que se elimine el registro CNAME antes de que el nombre de dominio se pueda quitar de la cuenta del inquilino. También podría considerar la posibilidad de prohibir la reutilización de identificadores de inquilino y, a continuación, puede reforzar el proceso de incorporación de dominios personalizados mediante un registro TXT generado aleatoriamente (que es diferente para 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 los certificados TLS es algo que se debe tener en cuenta cuidadosamente para 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. Un propietario de dominio puede usar el tipo de registro DNS CAA (autorización de entidad de certificación) para asegurarse de que solo las autoridades específicas puedan crear certificados para su 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.

Pasos siguientes

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