Особенности доменных имен в мультитенантных решениях

Во многих мультитенантных веб-приложениях можно использовать доменное имя для предоставления следующих возможностей:

• Чтобы отличить один клиент от другого

• Чтобы помочь с маршрутизацией запросов на правильную инфраструктуру

• Предоставление фирменного интерфейса клиентам

Вы можете использовать поддомены или пользовательские доменные имена. В этой статье приводятся рекомендации для технических лиц, принимающих решения о подходах к доменным именам и их компромиссах.

Поддомены

Вы можете назначить каждому клиенту уникальный поддомен с общим доменным именем, используя такой формат tenant.provider.com.

Рассмотрим пример мультитенантного решения, созданного Contoso. Клиенты покупают продукт Contoso для управления созданием счетов. Contoso назначает всем арендаторам собственный поддомен в рамках доменного имени contoso.com. Если компания Contoso использует региональные развертывания, то она может назначать поддомены в доменах us.contoso.com и eu.contoso.com.

Эта статья относится к этим региональным доменам как к стержневым доменам. Каждый клиент получает собственный поддомен поддомен вашего домена. Например, Tailwind Toys может получить tailwind.contoso.com. Если вы используете модель регионального развертывания, Adventure Works может получить adventureworks.us.contoso.com.

Управление пространством имен домена

При создании субдоменов под вашим доменным именем у вас может быть несколько клиентов с похожими именами. Они используют единый главный домен, поэтому первый клиент, который зарегистрирует конкретный домен, получает предпочитаемое имя. Последующие клиенты должны использовать альтернативные поддоменные имена, так как полные доменные имена должны оставаться глобально уникальными.

Подстановочный знак DNS

Используйте подстановочные записи системы доменных имен (DNS), чтобы упростить управление поддоменами. Вместо создания записей DNS для tailwind.contoso.com или adventureworks.contoso.com можно создать подстановочную запись для *.contoso.com. Направляйте все поддомены на один и тот же IP-адрес с помощью записи A или на каноническое имя с помощью записи CNAME. Если вы используете региональные домены стволовых элементов, может потребоваться несколько подстановочных знаков, например *.us.contoso.com и *.eu.contoso.com.

Поддомены на основе доменов с многосоставной основой

Многие мультитенантные решения охватывают несколько физических развертываний. Этот подход часто возникает, если необходимо соответствовать требованиям к месту расположения данных или повысить производительность, развертывая ресурсы географически ближе к пользователям.

Даже в одном регионе вы можете распределить арендаторы между независимыми развертываниями для поддержки стратегии масштабирования. Если вы планируете использовать поддомены для каждого клиента, рассмотрите структуру поддомена с несколькими компонентами.

Например, Компания Contoso публикует мультитенантное приложение для четырех клиентов. Adventure Works и Tailwind Traders находятся в США, и их данные хранятся в общем экземпляре платформы Contoso в США. Fabrikam и Мировые импортеры находятся в Европе, и их данные хранятся в европейском экземпляре.

На следующей схеме показан пример использования Contoso одноствольного домена contoso.com для всех своих клиентов.

Компания Contoso может использовать следующие записи DNS для поддержки этой конфигурации.

Для каждого нового подключенного клиента требуется новый поддомен. Число поддоменов увеличивается с каждым клиентом.

Кроме того, компания Contoso может использовать основные домены для специфического развертывания или региона.

Используя подстановочный знак DNS, записи DNS для этого развертывания могут выглядеть следующим образом.

Компании Contoso не нужно создавать записи поддомена для каждого клиента. Вместо этого одна подстановочная запись DNS для развертывания в каждом географическом регионе позволяет новым клиентам, находящимся под этим началом, автоматически наследовать запись CNAME.

Каждый подход имеет преимущества и недостатки. При использовании одноосновного домена необходимо создать запись DNS для каждого клиента, которого вы подключаете, что увеличивает операционные расходы. Однако у вас есть больше гибкости для переноса клиентов между различными развертываниями. Запись CNAME можно изменить, чтобы направить трафик в другое развертывание. Это изменение не влияет на другие клиенты.

Домены с несколькими стволовыми областями имеют более низкую нагрузку на управление. Вы можете повторно использовать имена клиентов в нескольких региональных доменах, так как каждый домен стволовых объектов фактически представляет свое собственное пространство имен.

Личные доменные имена

Возможно, вам потребуется предоставить клиентам собственные доменные имена. Некоторые клиенты видят эту функцию как важный аспект их фирменной символики. Клиентам также могут потребоваться пользовательские доменные имена для удовлетворения требований безопасности, особенно если им нужно предоставить собственные сертификаты TLS. Этот подход может показаться простым, но некоторые скрытые сложности требуют тщательного рассмотрения.

Разрешение имен

В конечном счете, каждое доменное имя должно разрешаться в IP-адрес. Как показано ранее, процесс разрешения имен зависит от того, развертываете ли вы один или несколько экземпляров вашего решения.

Чтобы вернуться к примеру, один из клиентов Contoso, Fabrikam, запрашивает использовать invoices.fabrikam.com в качестве имени личного домена для доступа к службе Contoso. Компания Contoso имеет несколько развертываний своей мультитенантной платформы, поэтому они решили использовать поддомены и записи CNAME для достижения требований к маршрутизации. Contoso и Fabrikam настраивают следующие записи DNS.

С точки зрения разрешения имен эта цепочка записей точно разрешает запросы invoices.fabrikam.com на IP-адрес европейского развертывания Contoso.

Разрешение заголовка узла

Разрешение имен является лишь частью проблемы. Все веб-компоненты в европейском развертывании Contoso должны знать, как обрабатывать запросы, содержащие доменное имя Fabrikam в заголовке Host запроса. В зависимости от конкретных веб-технологий, которые использует Компания Contoso, доменное имя каждого клиента может потребовать дополнительной настройки, что добавляет дополнительные операционные издержки на подключение клиента.

Вы также можете переписать заголовки хоста так, чтобы независимо от заголовка входящего запроса Host веб-сервер видел единообразное значение заголовка. Например, Azure Front Door позволяет переписать Host заголовки, чтобы независимо от запроса сервер приложений получил один Host заголовок. Azure Front Door распространяет исходный заголовок узла в заголовке X-Forwarded-Host, чтобы ваше приложение могло его проверить, а затем найти арендатора. Однако перезапись заголовка Host может вызвать другие проблемы. Дополнительные сведения см. в разделе "Сохранение имени узла".

Проверка домена

Перед подключением к ним необходимо проверить владение пользовательскими доменами. В противном случае клиент может случайно или злонамеренно зарегистрировать доменное имя, что иногда называется парковкой доменного имени.

Рассмотрим процесс интеграции Contoso для Adventure Works, который запросил использовать invoices.adventureworks.com в качестве их пользовательского доменного имени. К сожалению, кто-то сделал опечатку, когда они пытались подключить имя личного домена, и они пропустили s. Поэтому они настраивают его как invoices.adventurework.com. В результате трафик для Adventure Works не обрабатывается правильно. Но когда другая компания с именем Adventure Work пытается добавить свой личный домен на платформу Contoso, они говорят, что доменное имя уже используется.

Чтобы предотвратить эту проблему, особенно в самостоятельном или автоматизированном процессе, можно выполнить шаг проверки домена. Перед добавлением домена может потребоваться, чтобы клиент мог создать запись CNAME. Кроме того, можно создать случайную строку и попросить клиента добавить запись DNS TXT, содержащую строковое значение. Доменное имя нельзя добавить до тех пор, пока проверка не завершится успешно.

Переключение атак DNS и поддомена

При работе с пользовательскими доменными именами вы подвергаете вашу платформу атакам класса, называемым подвешенный DNS или захват поддомена. Эти атаки возникают, когда клиенты отсоединяют свое имя личного домена от службы, но они не удаляют запись с DNS-сервера. Затем эта запись DNS указывает на несуществующий ресурс и уязвим для захвата.

Рассмотрим, как связь Fabrikam с Contoso может измениться, если происходит следующий сценарий:

1. Fabrikam решает больше не работать с Contoso, поэтому они завершают свои деловые отношения.

2. Компания Contoso завершает обслуживание клиента Fabrikam и отключает fabrikam.contoso.com.

3. Fabrikam забывает удалить запись CNAME для invoices.fabrikam.com.

4. Злоумышленник создает новую учетную запись Contoso и присваивает ей имя fabrikam.

5. Злоумышленник подключен к новому клиенту имя invoices.fabrikam.com личного домена.

6. Contoso проверяет DNS-сервер Fabrikam во время проверки домена на основе CNAME. Они видят, что DNS-сервер возвращает запись CNAME для invoices.fabrikam.com, на которую указывает fabrikam.contoso.com. Компания Contoso считает, что проверка личного домена выполнена успешно.

7. Если сотрудники Fabrikam пытаются получить доступ к сайту, кажется, что запросы работают. Если злоумышленник настраивает свой клиент Contoso с фирменной символикой Fabrikam, сотрудники могут быть обмануты в доступе к сайту и предоставлении конфиденциальных данных, к которым злоумышленник может получить доступ.

Используйте следующие стратегии для защиты от висячих атак DNS.

• Перед удалением доменного имени из учетной записи арендатора необходимо удалить запись CNAME.

• Запретить повторное использование идентификаторов клиента. И требует, чтобы каждый клиент создал запись TXT с именем, соответствующим доменному имени и случайно созданному значению, которое изменяется для каждой попытки подключения.

Сертификаты TLS

TLS является важным компонентом современных приложений. Он обеспечивает доверие и безопасность веб-приложений. Внимательно рассмотрим владение и управление сертификатами TLS для мультитенантных приложений.

Как правило, владелец доменного имени выдает и обновляет свои сертификаты. Например, Contoso выдает и обновляет сертификаты TLS для us.contoso.com и подстановочный сертификат для *.contoso.com. Аналогичным образом Fabrikam управляет записями для домена fabrikam.com, включая invoices.fabrikam.com.

Владелец домена может использовать тип записи DNS авторизации центра сертификации (CAA). Записи CAA гарантируют, что только определенные центры могут создавать сертификаты для домена.

Если вы разрешаете клиентам использовать собственные домены, рассмотрите, планируете ли вы выдавать для них сертификаты или требовать, чтобы они обеспечили наличие своих собственных. Каждый вариант имеет преимущества и недостатки:

• Если вы выдаете сертификат для клиента, вы можете обработать продление сертификата, чтобы клиент не должен его поддерживать. Однако если у клиентов есть записи CAA в доменных именах, им может потребоваться авторизовать выдачу сертификатов от их имени.

• Если клиенты выдает и предоставляют собственные сертификаты, вы безопасно получаете закрытые ключи и управляете ими. Чтобы избежать прерывания работы службы, может потребоваться напомнить клиентам, чтобы продлить сертификат до истечения срока его действия.

Несколько служб Azure поддерживают автоматическое управление сертификатами для пользовательских доменов. Например, Azure Front Door и Служба приложений предоставляют сертификаты для пользовательских доменов, и они автоматически обрабатывают процесс продления. Эта функция удаляет бремя управления сертификатами из вашей группы операций. Тем не менее, вам по-прежнему необходимо рассмотреть вопросы владения и полномочий. Убедитесь, что записи CAA установлены и настроены правильно. Кроме того, убедитесь, что домены ваших клиентов допускают сертификаты, управляемые платформой.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основной автор:

• Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure

Другие участники:

• Даниэль Скотт-Райнсфорд | Стратег технологий партнеров
• Арсен Владимирский | Главный инженер по работе с клиентами, FastTrack для Azure

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

Дальнейшие шаги

Многие службы используют Azure Front Door для управления доменными именами. Дополнительные сведения см. в статье Об использовании Azure Front Door в мультитенантном решении.

Вернитесь к обзору архитектуры. Или просмотрите Azure Well-Architected Framework.