Рекомендации по использованию доменных имен в мультитенантном решении

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

Поддомены

Каждый клиент может получить уникальный поддомен поддомен под общим доменным именем, используя такой 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 для всех своих клиентов, это может выглядеть следующим образом:

Записи 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 были настроены перед добавлением домена. Кроме того, Компания Contoso может создать случайную строку и попросить Adventure Works добавить запись DNS TXT со значением строки. Это позволит предотвратить добавление доменного имени до завершения проверки.

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

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

Давайте рассмотрим, как связь Fabrikam с Contoso может измениться:

1. Fabrikam решил больше не работать с Contoso, и поэтому они прекратили свои деловые отношения.
2. Компания Contoso отключила клиент Fabrikam, и они попросили fabrikam.contoso.com больше не работать. Однако Fabrikam забыл удалить запись CNAME для invoices.fabrikam.com.
3. Злоумышленник создает новую учетную запись Contoso и присваивает ей имя fabrikam.
4. Злоумышленник подключен к новому клиенту имя invoices.fabrikam.com личного домена. Так как Компания Contoso выполняет проверку домена на основе CNAME, они проверяют DNS-сервер Fabrikam. Они видят, что DNS-сервер возвращает запись CNAME для invoices.fabrikam.com, на которую указывает fabrikam.contoso.com. Компания Contoso считает, что проверка личного домена выполнена успешно.
5. Если какие-либо сотрудники Fabrikam пытались получить доступ к сайту, запросы, как представляется, будут работать. Если злоумышленник настраивает свой клиент Contoso с фирменной символикой Fabrikam, сотрудники могут быть обмануты в доступе к сайту и предоставлении конфиденциальных данных, к которым злоумышленник может получить доступ.

Распространенные стратегии защиты от атак DNS:

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

TLS/SSL-сертификаты

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

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

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

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

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

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

• Джон Даунс | Главный инженер программного обеспечения

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

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

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

Следующие шаги

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