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

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

Подобласти

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

Рассмотрим пример мультитенантного решения, созданного компанией Contoso. Клиенты приобретают продукт Contoso для управления созданием счетов. Всем клиентам Contoso может быть назначен собственный поддомен под доменным contoso.com именем. Или, если contoso использует региональные развертывания, они могут назначать поддомены в us.contoso.com доменах и eu.contoso.com . В этой статье мы называем их стволовыми доменами. Каждый клиент получает собственный поддомен в вашем домене ствола. Например, tailwind Toys можно назначить tailwind.contoso.com, а Adventure Works — adventureworks.contoso.com.

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

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

DNS с подстановочным знаком

Рассмотрите возможность использования записей DNS с подстановочными знаками, чтобы упростить управление поддоменами. Вместо создания записей DNS для tailwind.contoso.com, adventureworks.contoso.comи т. д. можно создать запись с подстановочными знаками для *.contoso.com и направить все поддомены на один IP-адрес (запись A) или каноническое имя (запись CNAME).

Поддомены с многокомпонентными стволовыми доменами

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

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

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

Если 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 гарантируют, что только определенные центры могут создавать сертификаты для домена.

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

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

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

Соавторы

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

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

• Джон Даусс | Главный инженер-клиент, FastTrack для Azure

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

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

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

Дальнейшие действия

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