マルチテナント ソリューションでのドメイン名に関する考慮事項

多くのマルチテナント Web アプリケーションでは、ドメイン名を使用して次の機能を提供できます。

• あるテナントを別のテナントと区別するには

• 適切なインフラストラクチャへの要求のルーティングに役立つ

• ブランド化されたエクスペリエンスを顧客に提供するには

サブドメインまたはカスタム ドメイン名を使用できます。 この記事では、ドメイン名のアプローチとそのトレードオフに関する技術的な意思決定者向けのガイダンスを提供します。

サブドメイン

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を受け取る可能性があります。

注

多くの Azure サービスではこのアプローチが使用されています。 たとえば、Azure ストレージ アカウントを作成すると、Azure は一連のサブドメイン ( <your account name>.blob.core.windows.netなど) を割り当てます。

ドメインの名前空間を管理する

独自のドメイン名でサブドメインを作成する場合は、同じ名前の複数の顧客を持つことができます。 1 つのステム ドメインを共有するため、特定のドメインを要求した最初の顧客は優先名を受け取ります。 完全なドメイン名はグローバルに一意である必要があるため、後続の顧客は代替サブドメイン名を使用する必要があります。

ワイルドカード DNS

ワイルドカード ドメイン ネーム システム (DNS) エントリを使用して、サブドメインの管理を簡略化します。 tailwind.contoso.comまたはadventureworks.contoso.comの DNS エントリを作成する代わりに、*.contoso.comのワイルドカード エントリを作成できます。 A レコードを使用してすべてのサブドメインを 1 つの IP アドレスに転送するか、CNAME レコードを使用して正規名に転送します。 リージョン ステム ドメインを使用する場合は、 *.us.contoso.com や *.eu.contoso.comなど、複数のワイルドカード エントリが必要になる場合があります。

注

この機能を使用する予定の場合は、Web 層サービスでワイルドカード DNS がサポートされていることを確認します。 Azure Front Door や Azure App Service など、多くの Azure サービスでは、DNS エントリがサポートされています。

複数部分のステム ドメインに基づくサブドメイン

多くのマルチテナント ソリューションは、複数の物理デプロイにまたがる。 このアプローチは、ユーザーに地理的に近い場所にリソースをデプロイすることで、データ所在地の要件に準拠したり、パフォーマンスを向上させたりする必要がある場合に一般的です。

1 つのリージョン内であっても、テナントを独立したデプロイに分散してスケーリング戦略をサポートする場合があります。 テナントごとにサブドメインを使用する予定の場合は、複数部分のサブドメイン構造を検討してください。

たとえば、Contoso は 4 人の顧客にマルチテナント アプリケーションを発行します。 Adventure Works と Tailwind Traders は米国にあり、そのデータは Contoso プラットフォームの共有 US インスタンスに格納されています。 Fabrikam と Worldwide Importers はヨーロッパにあり、そのデータはヨーロッパのインスタンスに格納されます。

次の図は、すべての顧客に対して単一ステム ドメイン contoso.com を使用する Contoso の例を示しています。

Web アプリ 1 の場合、adventureworks.us.contoso.com と tailwind.us.contoso.com は web アプリ 1 を指す us.contoso.com を指します。 Web アプリ 2 の場合、fabrikam.contoso.com と worldwideimporters.contoso.com は web アプリ 2 を指す eu.contoso.com をポイントします。

Contoso は、次の DNS エントリを使用して、この構成をサポートできます。

サブドメイン	CNAME
adventureworks.contoso.com	us.contoso.com
tailwind.contoso.com	us.contoso.com
fabrikam.contoso.com	eu.contoso.com
worldwideimporters.contoso.com	eu.contoso.com

オンボードされた新しい顧客ごとに、新しいサブドメインが必要です。 サブドメインの数は、顧客ごとに増加します。

または、Contoso はデプロイ固有またはリージョン固有のステム ドメインを使用できます。

Web アプリ 1 の場合、adventureworks.us.contoso.com と tailwind.us.contoso.com は web アプリ 1 を指す us.contoso.com を指します。 Web アプリ 2 の場合、fabrikam.eu.contoso.com と worldwideimporters.eu.contoso.com は web アプリ 2 を指す eu.contoso.com をポイントします。

ワイルドカード DNS を使用すると、このデプロイの DNS エントリは次のエントリのようになります。

サブドメイン	CNAME
*.us.contoso.com	us.contoso.com
*.eu.contoso.com	eu.contoso.com

Contoso は、すべての顧客のサブドメイン レコードを作成する必要はありません。 代わりに、各地域のデプロイに対して 1 つのワイルドカード DNS レコードを使用すると、そのステムの下に新しい顧客が自動的に CNAME レコードを継承できます。

各アプローチには、利点と欠点があります。 単一ステム ドメインを使用する場合は、オンボードするテナントごとに DNS レコードを作成する必要があり、運用オーバーヘッドが増加します。 ただし、デプロイ間でテナントを移動する柔軟性が高くなります。 CNAME レコードを変更して、トラフィックを別のデプロイに転送できます。 この変更は、他のテナントには影響しません。

複数のステム ドメインでは、管理オーバーヘッドが低くなります。 各ステム ドメインは効果的に独自の名前空間を表しているため、複数のリージョンのステム ドメイン間で顧客名を再利用できます。

カスタム ドメイン名

顧客が独自のドメイン名を持ち込むことができるようにすることがあります。 一部のお客様は、この機能をブランド化の重要な側面と見なしています。 お客様は、特に独自のトランスポート層セキュリティ (TLS) 証明書を提供する必要がある場合に、セキュリティ要件を満たすためにカスタム ドメイン名が必要になる場合もあります。 このアプローチは簡単に見えるかもしれませんが、一部の隠れた複雑さには思慮深い考慮事項が必要です。

名前解決

最終的には、各ドメイン名は IP アドレスに解決されなければなりません。 前述のように、名前解決プロセスは、ソリューションの 1 つのインスタンスと複数のインスタンスのどちらをデプロイするかによって異なります。

この例を見直すために、Contoso の顧客の 1 人である Fabrikam は、カスタム ドメイン名として invoices.fabrikam.com を使用して Contoso のサービスにアクセスするよう要求しています。 Contoso にはマルチテナント プラットフォームの複数のデプロイがあるため、サブドメインと CNAME レコードを使用してルーティング要件を満たすことにしました。 Contoso と Fabrikam は、次の DNS レコードを構成します。

名前	レコード タイプ	価値	構成を行うプログラム
invoices.fabrikam.com	CNAME	fabrikam.eu.contoso.com	Fabrikam
*.eu.contoso.com	CNAME	eu.contoso.com	Contoso
eu.contoso.com	A	(Contoso の IP アドレス)	Contoso

名前解決の観点から、このレコード チェーンにより、invoices.fabrikam.com に対する要求は、Contoso のヨーロッパでのデプロイの IP アドレスに正確に解決されます。

ホスト ヘッダーの解決

名前解決は問題の一部に過ぎません。 Contoso のヨーロッパ展開内のすべての Web コンポーネントは、 Host 要求ヘッダーに Fabrikam のドメイン名を含む要求を処理する方法を認識している必要があります。 Contoso が使用する特定の Web テクノロジによっては、各テナントのドメイン名に追加の構成が必要になる場合があり、テナントのオンボードに追加の運用オーバーヘッドが追加されます。

また、受信要求の Host ヘッダーに関係なく、Web サーバーに一貫性のあるヘッダー値が表示されるように、ホスト ヘッダーを書き換えることもできます。 たとえば、Azure Front Door では、要求に関係なく、アプリケーション サーバーが 1 つのHost ヘッダーを受け取るように、Host ヘッダーを書き換えることができます。 Azure Front Door は、元のホスト ヘッダーを X-Forwarded-Host ヘッダーに伝達して、アプリケーションで検査し、テナントを検索できるようにします。 ただし、Host ヘッダーを書き換えると他の問題が発生する可能性があります。 詳細については、「ホスト名の保存」を参照してください。

ドメインの検証

カスタム ドメインをオンボードする前に、その所有権を検証する必要があります。 検証を行わないと、顧客が誤って、あるいは悪意を持ってドメイン名を取得してしまう可能性があります (この行為はドメイン名のパーキングと呼ばれることもあります)。

カスタム ドメイン名として invoices.adventureworks.com を使用することを要求した、Contoso の Adventure Works のオンボード プロセスについて考えてみましょう。 カスタム ドメイン名のオンボードで入力ミスが発生し、"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 は、 invoices.fabrikam.comの CNAME レコードを削除することを忘れます。

4. 悪意のあるアクターが新しい Contoso アカウントを作成し、fabrikam という名前を付けます。

5. 攻撃者がカスタム ドメイン名 invoices.fabrikam.com を新しいテナントにオンボードします。

6. Contoso は、CNAME ベースのドメイン検証中に Fabrikam の DNS サーバーを確認します。 DNS サーバーが、fabrikam.contoso.com を指す invoices.fabrikam.com の CNAME レコードを返すことを確認しました。 Contoso は、カスタム ドメインの検証が成功したと見なします。

7. Fabrikam の従業員がサイトにアクセスしようとすると、要求が機能しているように見えます。 攻撃者が Fabrikam のブランドを使用して Contoso テナントを設定している場合、従業員は騙されてサイトにアクセスし、機密データを入力する可能性があり、この場合攻撃者がそのデータにアクセスできることになります。

未解決の DNS 攻撃から保護するには、次の戦略を使用します。

• ドメイン名をテナントのアカウントから削除する 前に 、CNAME レコードを削除する必要があります。

• テナント識別子の再利用を禁止します。 また、各テナントは、ドメイン名と一致する名前と、オンボーディングの試行ごとに変更されるランダムに生成された値を持つ TXT レコードを作成する必要があります。

TLS 証明書

TLS は、最新のアプリケーションに不可欠なコンポーネントです。 これにより、Web アプリケーションに信頼とセキュリティが備わります。 マルチテナント アプリケーションの TLS 証明書の所有権と管理を慎重に検討してください。

通常、ドメイン名の所有者は証明書を発行して更新します。 たとえば、Contoso は、 us.contoso.com の TLS 証明書と、 *.contoso.comのワイルドカード証明書を発行して更新します。 同様に、Fabrikam は、invoices.fabrikam.comを含むfabrikam.com ドメインのレコードを管理します。

ドメイン所有者は、証明機関承認 (CAA) DNS レコードの種類を使用できます。 CAA レコードを使用すると、特定の機関のみがドメインの証明書を作成できます。

顧客が独自のドメインを持ち込むことを許可する場合は、自分の代わりに証明書を発行する予定か、または証明書を持ち込む必要があるかを検討してください。 いずれの方法でも利点と欠点があります。

• 顧客の証明書を発行する場合は、証明書の更新を処理できるため、顧客はそれを維持する必要はありません。 ただし、顧客が各自のドメイン名の CAA レコードを持っている場合は、顧客の代理として証明書を発行することを顧客から承認してもらう必要がある場合があります。

• 顧客が発行し、独自の証明書を提供すると、秘密キーを安全に受け取って管理できます。 サービスの中断を回避するために、有効期限が切れる前に証明書を更新するよう顧客に通知する必要がある場合があります。

複数の Azure サービスで、カスタム ドメインの証明書の自動管理がサポートされています。 たとえば、Azure Front Door と App Service ではカスタム ドメインの証明書が提供され、更新プロセスが自動的に処理されます。 この機能により、運用チームから証明書を管理する負担が軽減されます。 ただし、引き続き所有権と権限を考慮する必要があります。 CAA レコードが配置され、正しく構成されていることを確認します。 また、プラットフォームが管理する証明書が顧客のドメインで許可されていることを確認します。

貢献者達

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要著者:

• John Downs | プリンシパル ソフトウェア エンジニア

その他の共同作成者:

• Daniel Scott-Raynsford |パートナー テクノロジ ストラテジスト
• Arsen Vladimirskiy | FastTrack for Azure の主任顧客エンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

多くのサービスでは、Azure Front Door を使用してドメイン名を管理しています。 詳細については、「マルチテナント ソリューションで Azure Front Door を使用する」を参照してください。

アーキテクチャに関する考慮事項の概要の記事に戻ります。 または、 Azure Well-Architected Framework を確認します。