SaaSプラットフォームで独自ドメインを持ち込む方法

ユーザー定義ドメインは、SaaSサービスプラットフォームで広く使用されている機能です。Shopifyなどの有名なプラットフォームは、ユーザーによりパーソナライズされた柔軟な体験を提供するためにこのサービスを提供しています。

従来の運用モデルでは、SaaSプラットフォームのユーザーは、プラットフォームが提供するソフトウェアサービスを購入して、エンドユーザーにサービスを提供するための独自のユーザー体験を作成します。サービスの起点として、SaaSプラットフォームは通常、各ユーザーにランダムに生成されたサブドメインをデフォルトのアクセスポイントとして割り当てます。しかし、パーソナライズされたアクセスアドレスの需要を満たすために、プラットフォームはユーザーが独自のドメイン名をアクセスポイントとして設定することをサポートし、ブランド認知度とユーザーアクセシビリティを向上させます。

この記事では、実際の製品開発においてユーザーカスタムドメイン機能を効果的に実装する方法について掘り下げ、開発者にとって貴重な洞察と参考資料を提供することを目的としています。

SaaS

問題分析

あなたは疑問に思うかもしれません：ユーザーがドメインのDNS CNAMEレコードをプラットフォームが提供するランダムなドメインにポイントするだけで、この機能を実現できないのでしょうか？実際には、問題はより複雑で、主に以下の2つの側面に焦点が当てられます：

現代のインターネットサービスはすべてHTTPSプロトコルを使用して通信の安全性を確保しています。エンドユーザーがSaaSプラットフォームが提供するサイトにアクセスしようとする際、プラットフォームが提供するランダムなサブドメインをエントリーポイントとして使用すると、ワイルドカードTLS証明書を直接使用できるため、証明書管理に問題はありません。この時点で、ユーザーとSaaSプラットフォームのHTTPSサービス間のハンドシェイクは信頼できます。しかし、ユーザーカスタムドメインを使用する場合、SaaSプラットフォームはそのドメインの信頼された証明書を持っている必要があり、エンドユーザーのブラウザが正しい接続を確立するために、プラットフォームはユーザーがアップロードした証明書を受け入れるか、ホストされた証明書管理サービスを提供する必要があります。
安全な接続が確立された後、SaaSプラットフォームは、エンドユーザーがプラットフォーム上のどのテナントにアクセスしようとしているかを識別する必要があります。これには、プラットフォームがドメインとテナント識別子のマッピングテーブルを維持し、受信リクエスト（Hostリクエストヘッダーなど）から特定のテナント情報を抽出し、マッピングテーブルをクエリしてテナントIDを見つけ、リクエスタに必要なデータを返す必要があります。

TLS証明書管理

主要なクラウドサービス

AWS（Amazon Web Services）やGCP（Google Cloud Platform）などの主要なクラウドサービスプロバイダーは、包括的な証明書管理サービスと対応するAPIインターフェースを提供しており、CloudflareはSaaSサービス専用のソリューションであるCloudflare for SaaSを立ち上げています。

AWSを例にとると、そのAWS Certificate Managerサービスにより、SaaSプラットフォームはAPIを通じてユーザーが設定したカスタムドメインの信頼された証明書を簡単に発行できます。AWSエコシステム内のサービスとして、Elastic Load BalancerやCloudFrontなどの他のコア機能とシームレスに統合され、ACMが発行した証明書を直接TLS終端に使用できます。

これらのクラウドサービスを使用することで、プラットフォームはTLS証明書を一元的に管理できます。これは確かに魅力的に聞こえます。SaaSサービスの初期段階では、これらのクラウドサービスを使用することで、開発者の負担を大幅に軽減し、ビジネスロジックの実装に集中できるようになります。しかし、一貫したユーザー体験を追求する中で、これらのクラウドサービスはいくつかの潜在的な問題も露呈します。

SaaSプラットフォームのクラウド

AWS Certificate Managerを例にとると、証明書を発行する際にドメインの所有権検証が必要です。このプロセスでは、ドメイン所有者がDNSレコードに特定のCNAMEレコードを設定し、acm-validations.awsのアドレスをポイントする必要があります。さらに、このレコードは、後続の証明書更新操作のために長期間維持する必要があります。これは、SaaSプラットフォームがクラウドプラットフォーム固有の実装詳細をユーザーに公開する必要があることを意味します。さらに、このメカニズムはACMEプロトコルのような一般的な証明書自動化標準に準拠していません。そのため、SaaSプラットフォームはAWSクラウドサービスに強く結びつく可能性があります。SaaSプラットフォームに多数のユーザーがいる場合、移行（各ユーザーがDNSレコードを再調整する必要がある）はほぼ不可能な作業になります。

さらに、ACMサービスが発行する信頼された証明書はダウンロードをサポートしていないため、これらの証明書はAWSエコシステム内の他のサービスでのみ使用でき、他のクラウドプロバイダーに簡単に拡張することが難しく、マルチクラウドの柔軟性が制限されます。

自動化された証明書管理

Let's EncryptやAutomatic Certificate Management Environment（ACME、RFC8555）プロトコルに基づく他の証明機関（CA）が主流になるにつれ、自動化された証明書管理はもはやクラウドサービスの独占物ではなくなりました。現在、どの開発者でも簡単に自動証明書の発行と更新を実装でき、サービスの使いやすさとセキュリティが大幅に向上します。

ACME仕様は、DNS TXT、HTTP、TLS ALPNなど、さまざまなドメイン所有権検証メカニズムを定義しており、証明書申請者に柔軟で多様な選択肢を提供します。SaaSシナリオでは、HTTP認証方式が特に適しています。ユーザーはカスタムドメインのDNS CNAMEレコードを設定し、プラットフォームが割り当てたランダムなドメインまたは統一されたCNAMEアクセスポイントにポイントするだけで済みます。例えば、プラットフォームはユーザーにexample.comをcname.contoso.comに解決するよう要求し、このCNAMEアクセスポイントはプラットフォームが自己展開したHTTPサービスをポイントします。この設計により、証明書発行プロセスが簡素化され、より簡潔で効率的になります。

ドメイン設定が正しく行われた後、プラットフォームはCAのAPIを呼び出して証明書注文を作成できます。CAはその後、HTTP経由でユーザーのドメインにアクセスします。この時点でドメインはすでにプラットフォームのアクセスポイントをポイントしているため、プラットフォームはCAの特定のランダム文字列検証条件を簡単に満たすことができ、ドメイン所有権検証を完了し、証明書をダウンロードできます。

このメカニズムは、ユーザーの設定プロセスを簡素化するだけでなく、頻繁にDNSレコードを変更する手間を避けることができます。さらに重要なのは、プラットフォームが特定のクラウドサービスプロバイダーに縛られず、SaaSプラットフォームがよりフレンドリーで一貫したユーザー体験を提供できるようになることです。

また、このメカニズムを使用しても、クラウドでのTLS終端にCDNやロードバランシングサービスを利用できないわけではありません。実際、AWSなどのクラウドサービスプロバイダーが提供する証明書管理サービスは、開発者がAPI経由で自己管理証明書をインポートしてトラフィックアクセスを実現することをサポートしています。開発者は自分のプログラムで証明書発行を完了し、その証明書をクラウドサービスプロバイダーの証明書管理サービスにインポートするだけで、クラウドリソースのシームレスな統合と効率的な利用を実現できます。

マルチテナントシステム

TLS証明書の処理に成功した後、次の課題はSaaSプラットフォーム上のマルチテナンシーロジックの管理です。SaaSプラットフォームは少数のユーザーの特定のニーズにのみ対応するのではなく、広範なユーザーに統一された機能セットを提供することを目指しているため、そのシステムアーキテクチャは通常、マルチテナント設計を採用しています。この設計では、プラットフォームは一意のテナントIDを通じて異なるテナントを識別し、それぞれのエンドユーザーに対応するサービスを提供します。

マルチテナント管理

テナント識別メカニズムの実装は比較的簡単です。ドメイン所有権検証と証明書管理が必要なため、ユーザーはSaaSプラットフォームのコンソールでカスタムドメインを設定し、システムの指示に従ってDNS解決を設定する必要があります。システムが証明書設定を完了すると、カスタムドメインの記録がシステムに保存され、現在のテナントに関連付けられます。したがって、システムがリクエストを受信するたびに、HTTPリクエストヘッダーからHostフィールドを抽出して、クライアントのブラウザが使用しているアクセスドメインを判断できます。その後、このドメインに対応するテナント記録をクエリすることで、テナント識別子を迅速に特定できます。テナント識別子が取得されると、システムは対応するテナントのデータを正確にクエリしてアクセスできます。

結論

カスタムドメインは、SaaSプラットフォームのコア機能であり、ユーザーによりパーソナライズされた柔軟なアクセス体験を提供することを目的としています。カスタムドメイン機能を実装する過程では、TLS証明書管理とマルチテナント管理という2つの重要な問題に対処する必要があります。

これらの2つの問題を解決することで、通信の安全性とテナント識別におけるパーソナライズされたサービスを確保し、SaaSプラットフォームのサービス品質とユーザー体験を大幅に向上させることができます。これにより、ユーザーのプラットフォームに対する信頼と満足度が強化され、持続可能な発展が促進されます。