マルチテナント ソリューションでドメイン名を使用する場合の考慮事項

多くのマルチテナント Web アプリケーションでは、テナントを識別し、正しいインフラストラクチャへの要求のルーティングを支援し、ブランド化されたエクスペリエンスを顧客に提供する方法として、ドメイン名を使用できます。 2 つの一般的な方法は、サブドメインとカスタム ドメイン名を使用する方法です。 このページでは、検討できるアプローチとそのトレードオフに関する技術的な意思決定者向けのガイダンスを提供します。

サブドメイン

各テナントは、 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 が割り当てられている場合などです。

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

独自のドメイン名の下にサブドメインを作成する場合は、複数の顧客の名前が類似している可能性に注意する必要があります。 1 つのステム ドメインが共有されるため、特定のドメインを取得した最初の顧客が優先名を取得します。 その後、後続の顧客は代替サブドメイン名を使用する必要があります。完全なドメイン名はグローバルに一意でなければならないからです。

ワイルドカード DNS

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

マルチパート ステム ドメインのサブドメイン

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

1 つのリージョン内でも、スケーリング戦略をサポートするために、複数の独立したデプロイにテナントを分散する必要がある場合があります。 各テナントにサブドメインを使用する場合は、マルチパート サブドメイン構造を検討できます。

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

Contoso がすべての顧客に対して 1 つのステム ドメイン (contoso.com) を使用する場合は、次のようになります。

この構成をサポートするために必要な DNS エントリは、次のようになります。

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

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

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

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

各アプローチにはそれぞれの利点と欠点があります。 1 つのステム ドメインを使用する場合は、オンボードするテナントごとに新しい DNS レコードを作成する必要があります。この場合、運用オーバーヘッドが増加します。 ただし、デプロイ間でテナントを移動する場合は、トラフィックを別のデプロイに送信するように CNAME レコードを変更できるので、柔軟性が向上します。 この変更は、他のテナントには影響しません。 複数のステム ドメインを使用している場合、管理オーバーヘッドが低下します。 また、各ステム ドメインは独自の名前空間を効果的に表現しているため、複数のリージョン ステム ドメインで顧客名を再使用できます。

カスタム ドメイン名

顧客が独自のドメイン名を持ち込むことができるようにすることがあります。 一部の顧客はこの点をブランド化の重要な側面として考えています。 また、顧客のセキュリティ要件を満たすためにカスタム ドメイン名が必要な場合もあります。特に、独自の TLS 証明書を提供する必要がある場合です。 顧客が独自のドメイン名を持ち込むことができるようにするのは簡単に見えますが、このアプローチには一見して分からない複雑さがあるため、慎重に検討する必要があります。

名前解決

最終的には、各ドメイン名は IP アドレスに解決される必要があります。 これまで見たとおり、名前解決が行われるアプローチは、ソリューションの 1 つのインスタンスをデプロイするか複数のインスタンスをデプロイするかによって決まります。

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

名前解決の観点から、このレコード チェーンにより、 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 レコードを設定することを必須にする場合があります。 または、Contoso がランダムな文字列を生成し、Adventure Works に対しこの文字列値を含む DNS TXT レコードを追加するように指示します。 これにより、検証が完了するまではドメイン名が追加されることがありません。

ダングリング DNS およびサブドメイン乗っ取り攻撃

カスタム ドメイン名を使用する場合は、 "ダングリング DNS" または "サブドメインの乗っ取り"と呼ばれる攻撃クラスに対して脆弱になる可能性があります。 この攻撃は、顧客がサービスとカスタム ドメイン名の関連付けを解除したが、DNS サーバーからレコードを削除しない場合に発生します。 その後、この DNS エントリは存在しないリソースをポイントすることになり、乗っ取りに対して脆弱になります。

Fabrikam と Contoso の関係の変化を例に説明します。

1. Fabrikam は今後 Contoso を使用しないことを決定し、業務提携関係を終了しました。
2. Contoso は Fabrikam テナントをオフボードし、 fabrikam.contoso.com がこれ以降機能しないようにすることを要求しました。 ただし、Fabrikam が invoices.fabrikam.com の CNAME レコードを削除し忘れていました。
3. 悪意のあるアクターが新しい Contoso アカウントを作成し、 fabrikamという名前を付けます。
4. 攻撃者がカスタム ドメイン名 invoices.fabrikam.com を新しいテナントにオンボードします。 Contoso は CNAME ベースのドメイン検証を実施しているため、Fabrikam の DNS サーバーを確認します。 DNS サーバーが、 fabrikam.contoso.comを指す invoices.fabrikam.comの CNAME レコードを返すことを確認しました。 Contoso は、カスタム ドメインの検証が正常に完了したと判断します。
5. Fabrikam の従業員がこのサイトにアクセスしようとすると、要求が適切に処理されているように見えます。 攻撃者が Fabrikam のブランドを使用して Contoso テナントを設定している場合、従業員は騙されてサイトにアクセスし、機密データを入力する可能性があり、この場合攻撃者がそのデータにアクセスできることになります。

ダングリング DNS 攻撃から保護するための一般的な戦略は次のとおりです。

• テナントのアカウントからドメイン名を削除する "前" に、CNAME レコードの削除を要求します。
• テナント識別子の再使用を禁止します。また、さらにテナントに対して、ドメイン名と一致する名前と、オンボードが試行されるたびに変わるランダムに生成された値を使用して TXT レコードを作成することを要求します。

TLS/SSL 証明書

トランスポート層セキュリティ (TLS) は、最新のアプリケーションを操作する場合に不可欠なコンポーネントです。 これにより、Web アプリケーションに信頼とセキュリティが備わります。 TLS 証明書の所有権と管理は、マルチテナント アプリケーションでは慎重に検討する必要があります。

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

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

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

• 顧客に代わって証明書を発行する場合は、 証明書の更新を処理できます。そのため、証明書を常に更新しておくことを顧客が覚えておく必要はありません。 ただし、顧客が各自のドメイン名の CAA レコードを持っている場合は、顧客の代理として証明書を発行することを顧客から承認してもらう必要がある場合があります。
• 顧客が独自の証明書を発行して提供する場合は、 安全な方法で秘密鍵を受信、管理する責任があります。またサービスの中断を避けるために、有効期限が切れる前に証明書を更新するように顧客に注意を促す必要があります。

複数の Azure サービスで、カスタム ドメインの証明書の自動管理がサポートされています。 たとえば、Azure Front Door と App Service ではカスタム ドメインの証明書が提供され、更新プロセスが自動的に処理されます。 これにより、運用チームにかかる証明書管理作業の負担を解消できます。 ただし、所有権と権限 (CAA レコードが有効であり正しく構成されているかどうかなど) については検討する必要があります。 また、プラットフォームにより管理される証明書を許可するように顧客のドメインが構成されていることを確認する必要もあります。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

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

その他の共同作成者:

• Daniel Scott-Raynsford |パートナー テクノロジ ストラテジスト
• Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

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