Как подключить собственный домен в SaaS-платформах?

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

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

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

Анализ проблемы

Вы можете задаться вопросом: Разве пользователи не могут достичь этой функциональности, просто указав DNS CNAME-запись домена на случайный домен, предоставленный платформой? На самом деле, проблема более сложная и в основном сосредоточена на следующих двух аспектах:

1. Современные интернет-услуги используют протокол HTTPS для обеспечения безопасности связи. Когда конечные пользователи пытаются получить доступ к сайту, предоставленному SaaS-платформой, использование случайного поддомена, предоставленного платформой, позволяет напрямую использовать wildcard TLS-сертификат, что гарантирует отсутствие проблем с управлением сертификатами. В этот момент рукопожатие между пользователями и HTTPS-сервисом SaaS-платформы является доверенным. Однако при использовании пользовательского домена SaaS-платформа должна обладать доверенным сертификатом для этого домена, чтобы браузер конечного пользователя мог установить правильное соединение, что требует от платформы либо принятия сертификатов, загруженных пользователями, либо предоставления услуг управления сертификатами.

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

Управление TLS-сертификатами

Ведущие облачные сервисы

Крупные поставщики облачных услуг, такие как AWS (Amazon Web Services) и GCP (Google Cloud Platform), предлагают комплексные услуги управления сертификатами и соответствующие API-интерфейсы, а Cloudflare даже запустил специализированное решение Cloudflare for SaaS, ориентированное на SaaS-услуги.

На примере AWS, его сервис AWS Certificate Manager позволяет SaaS-платформам легко выпускать доверенные сертификаты для пользовательских доменов через API. Как сервис в экосистеме AWS, он легко интегрируется с другими ключевыми функциями, такими как Elastic Load Balancer и CloudFront, позволяя сертификатам, выпущенным ACM, напрямую использоваться для завершения TLS.

С этими облачными сервисами платформы могут управлять TLS-сертификатами в одном месте, что действительно звучит привлекательно. На ранних этапах SaaS-услуг использование этих облачных сервисов может значительно облегчить нагрузку на разработчиков, позволяя им сосредоточиться на реализации бизнес-логики. Однако в погоне за единообразным пользовательским опытом эти облачные сервисы также выявляют некоторые потенциальные проблемы.

На примере AWS Certificate Manager, при выпуске сертификатов требуется проверка владения доменом. Этот процесс требует от владельцев доменов установки определенных CNAME-записей в их DNS-записях, указывающих на адрес acm-validations.aws. Более того, эта запись должна поддерживаться в течение длительного времени для последующих операций обновления сертификатов. Это означает, что SaaS-платформы должны раскрывать пользователям специфические детали реализации, характерные для облачной платформы. Кроме того, этот механизм не соответствует никаким общим стандартам автоматизации сертификатов, таким как протокол ACME. Поэтому SaaS-платформы могут стать тесно связанными с облачными сервисами AWS. Когда у SaaS-платформы большое количество пользователей, миграция (требующая от каждого пользователя повторной настройки DNS-записей) становится практически невозможной задачей.

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

Автоматизированное управление сертификатами

С появлением Let's Encrypt и других центров сертификации (CA), основанных на протоколе Automatic Certificate Management Environment (ACME, RFC8555), автоматизированное управление сертификатами больше не является исключительной прерогативой облачных сервисов. Сегодня любой разработчик может легко реализовать автоматическую выдачу и обновление сертификатов, значительно повышая удобство и безопасность сервисов.

Спецификация ACME определяет различные механизмы проверки владения доменом, включая, но не ограничиваясь, DNS TXT, HTTP, TLS ALPN и другие, предоставляя заявителям сертификатов гибкие и разнообразные варианты. В сценарии SaaS метод HTTP-аутентификации особенно подходит. Пользователям нужно только настроить DNS CNAME-записи для своих пользовательских доменов, указывая их на случайный домен, выделенный платформой, или на единую точку доступа CNAME. Например, платформа может потребовать от пользователей разрешить example.com на cname.contoso.com, и эта точка доступа CNAME указывает на HTTP-сервис, самостоятельно развернутый платформой. Этот дизайн упрощает процесс выдачи сертификатов, делая его более лаконичным и эффективным.

Как только конфигурация домена выполнена правильно, платформа может вызвать API CA для создания заказов на сертификаты. CA затем получит доступ к домену пользователя через HTTP. Поскольку домен уже указывает на точку доступа платформы в этот момент, платформа может легко удовлетворить конкретные условия проверки случайной строки CA, завершив проверку владения доменом и загрузив сертификат.

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

Кроме того, использование этого механизма не означает, что нельзя использовать CDN или услуги балансировки нагрузки для завершения TLS в облаке. На самом деле, услуги управления сертификатами, предоставляемые облачными провайдерами, такими как AWS, поддерживают разработчиков в импорте самостоятельно управляемых сертификатов через API для доступа к трафику. Разработчикам нужно только завершить выдачу сертификатов в своих программах, а затем импортировать сертификат в услугу управления сертификатами облачного провайдера, достигая таким образом бесшовной интеграции и эффективного использования облачных ресурсов.

Мультитенантные системы

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

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

Заключение

Пользовательские домены — это ключевая функция на SaaS-платформах, направленная на предоставление пользователям более персонализированного и гибкого опыта доступа. В процессе реализации функциональности пользовательских доменов необходимо решить две ключевые проблемы: управление TLS-сертификатами и управление мультитенантностью.

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