マルチテナント ソリューションでテナントに要求をマップする

要求がアプリケーションに到着するたびに、要求の対象となっているテナントを特定する必要があります。 異なる地理的リージョンでホストされている場合もあるテナント固有のインフラストラクチャがある場合は、受信要求をテナントに一致させる必要があります。 その後、次に示すように、そのテナントのリソースをホストしている物理インフラストラクチャに要求を転送する必要があります。

このページでは、要求を適切なテナントにマップするために検討できるアプローチと、そのアプローチに関係するトレードオフについて、技術的な意思決定者向けのガイダンスを提供します。

テナントを識別する方法

受信要求のテナントを識別する方法は複数あります。

ドメイン名

テナント固有のドメイン名またはサブドメイン名を使用する場合は、Host ヘッダーまたは各要求の元のホスト名を含む別の HTTP ヘッダーを使用して、要求をテナントに簡単にマップできる可能性があります。

ただし、以下の点を考慮してください。

• ユーザーはサービスへのアクセスに使用するドメイン名をどのように把握するか。
• すべてのテナントで使用する、ランディング ページやログイン ページのような中央のエントリ ポイントがあるか。 ある場合、ユーザーはアクセスする必要があるテナントをどのように識別するか。
• テナントへのアクセスを検証するために、他にどのような情報を使用するか (認可トークンなど)。 その認可トークンにはテナント固有のドメイン名が含まれているか。

HTTP 要求のプロパティ

テナント固有のドメイン名を使用しない場合でも、HTTP 要求のいくつかの側面を使用して、特定の要求の対象となるテナントを識別できます。 たとえば、テナント名が tailwindtraders として識別される HTTP 要求について考えてみます。 これは次を使用して伝達することができます。

• URL パスの構造 (https://app.contoso.com/tailwindtraders/ など)。
• URL 内のクエリ文字列 (https://contoso.com/app?tenant=tailwindtraders など)。
• カスタム HTTP 要求ヘッダー (Tenant-Id: tailwindtraders など)。

この方法を使用する場合は、次の点を考慮する必要があります。

• サービスへのアクセス方法がユーザーに認識されるか。 たとえば、クエリ文字列を使用してテナントを識別する場合は、中央のランディング ページで、クエリ文字列を追加することで適切なテナントにユーザーを誘導する必要があるか。
• すべてのテナントで使用する、ランディング ページやログイン ページのような中央のエントリ ポイントがあるか。 ある場合、ユーザーはアクセスする必要があるテナントをどのように識別するか。
• アプリケーションから API が提供されるか。 たとえば、使用する Web アプリケーションはシングルページ アプリケーション (SPA) か、または API バックエンドを使用したモバイル アプリケーションか。 そうである場合は、API ゲートウェイまたはリバース プロキシを使用してテナントのマップを実行できる可能性があります。

トークン要求

多くのアプリケーションでは、OAuth 2.0 や SAML などのクレームベース認証および認可プロトコルが使用されます。 これらのプロトコルでは、クライアントに認可トークンが提供されます。 トークンには "クレーム" のセットが含まれています。これはクライアント アプリケーションまたはユーザーに関する一部の情報です。 クレームは、ユーザーのメール アドレスなどの情報を伝達するために使用できます。 システムは、ユーザーのメール アドレスを含め、ユーザーからテナントへのマッピングを参照し、適切なデプロイに要求を転送することができます。 または、テナント マッピングを ID システムに含め、テナント ID クレームをトークンに追加することもできます。

要求をテナントにマップするためにクレームを使用する場合は、次の点を考慮する必要があります。

• テナントを識別するためにクレームを使用するか。 どのクレームを使用するか。
• ユーザーは複数のテナントのメンバーになれるか。 なれる場合、ユーザーは使用するテナントをどのように選択するか。
• すべてのテナントに対する中央の認証および認可システムがあるか。 ない場合は、どのようにすべてのトークン機関で一貫性のあるトークンとクレームが発行されるようにするか。

API キー

多くのアプリケーションでは API が公開されます。 これらは組織内で内部的に使用したり、パートナーや顧客が外部で使用したりするためのものです。 API 用の一般的な認証方法は、"API キー" を使用することです。 API キーは要求ごとに提供され、テナントを参照するために使用できます。

API キーは、いくつかの方法で生成できます。 一般的な方法は、暗号化されたランダムな値を生成し、それをテナント ID と共にルックアップ テーブルに格納することです。 要求を受信すると、システムではルックアップ テーブル内の API キーを検索し、テナント ID と照合します。 もう 1 つの方法は、テナント ID を含んだ意味のある文字列を作成し、HMAC などの方法を使用して、キーにデジタル署名することです。 各要求を処理するときに、署名を確認してから、テナント ID を抽出します。

以下の質問を検討します。

• API キーをどのように生成して発行するか。
• API クライアントでは、API キーの安全な受け取りと格納をどのように行うか。
• API キーは一定期間後に期限切れにする必要があるか。 ダウンタイムを発生させずに、クライアントの API キーをどのようにローテーションするか。
• 顧客がロールした API キーを信頼するだけで、API に関して適切なレベルのセキュリティが提供されるか。

クライアント証明書

クライアント証明書の認証 (相互 TLS (mTLS) とも呼ばれます) は、一般にサービス間の通信に使用されます。 クライアント証明書では、クライアントを認証するための安全な方法が提供されます。 トークンおよびクレームと同様に、クライアント証明書には、テナントの識別に使用できる "属性" が用意されています。 たとえば、証明書の "サブジェクト" にはユーザーのメール アドレスを含めることができます。これはテナントの参照に使用できます。

テナント マッピングにクライアント証明書を使用することを計画する際は、次の点を考慮してください。

• サービスによって信頼されるクライアント証明書を、どのように安全に発行および更新するか。 クライアント証明書の操作は複雑になる場合があります。証明書の管理と発行に特別なインフラストラクチャが必要になるためです。
• クライアント証明書は最初のログイン要求に対してのみ使用されるか、またはサービスへのすべての要求に添付されるか。
• 大量のクライアントがあった場合、証明書を発行および管理するプロセスは管理できなくなるか。
• クライアント証明書とテナントの間のマッピングをどのように実装するか。

リバース プロキシ

リバース プロキシ (アプリケーション プロキシとも呼ばれます) を使用して、HTTP 要求をルーティングできます。 リバース プロキシはイングレス エンドポイントからの要求を受け入れ、多数のバックエンド エンドポイントのいずれかにその要求を転送できます。 リバース プロキシでは、一部の要求情報間のマッピングを実行し、アプリケーション インフラストラクチャからタスクをオフロードできるため、マルチテナント アプリケーションに便利です。

多くのリバース プロキシでは、要求のプロパティを使用してテナントのルーティングに関する決定を行うことができます。 宛先のドメイン名、URL パス、クエリ文字列、HTTP ヘッダーや、トークン内のクレームも検査できます。

Azure では、次の一般的なリバース プロキシが使用されます。

• Azure Front Door は、グローバル ロード バランサーと Web アプリケーション ファイアウォールです。 Microsoft グローバル エッジ ネットワークを使用して、高速かつ安全で、高度にスケーラブルな Web アプリケーションを作成します。
• Azure Application Gateway は、バックエンド サービスと同じ物理リージョンにデプロイする、マネージド Web トラフィック ロード バランサーです。
• Azure API Management は API トラフィック用に最適化されています。
• (自分でホストする) 商用およびオープンソースのテクノロジには、nginx、Traefik、HAProxy などがあります。

要求の検証

アプリケーションでは、受信したすべての要求がテナントに対して認可されていることを検証することが重要です。 たとえば、アプリケーションでカスタム ドメイン名を使用して要求をテナントにマップする場合でも、アプリケーションで受信した各要求がそのテナントに対して認可されていることを、アプリケーションで確認する必要があります。 要求にドメイン名または他のテナント識別子が含まれていても、アクセス権を自動的に付与すべきというわけではありません。 OAuth 2.0 を使用する場合は、audience クレームと scope クレームを調べることで検証を実行します。

要求の検証を実装する場合は、次の点を考慮する必要があります。

• アプリケーションに対するすべての要求をどのように認可するか。 要求を物理インフラストラクチャにマップするために使用する方法に関係なく、要求を認可する必要があります。
• すべての検証ロジックを自分で実装するのではなく、信頼され広く使用され適切に管理されている認証および認可フレームワークとミドルウェアを使用する。 たとえば、トークン署名の検証ロジックやクライアント証明書の暗号化ライブラリを作成しないでください。 代わりに、検証およびテスト済みである、アプリケーション プラットフォーム (または既知の信頼されたパッケージ) の機能を使用してください。

パフォーマンス

テナント マッピングのロジックは、アプリケーションへのすべての要求に対して実行される可能性があります。 ソリューションの拡大に合わせて、テナント マッピングのプロセスがどの程度スケーリングされるかを考慮してください。 たとえば、テナント マッピングの一部としてデータベース テーブルに対してクエリを実行する場合、データベースでは大きな負荷がサポートされていますか。 テナント マッピングでトークンの暗号化解除が必要な場合、時間の経過と共に計算の要件が高くなりすぎることはありませんか。 トラフィックがかなり少ない場合は、全体的なパフォーマンスに影響を与えることはほとんどありません。 ただし、大規模なアプリケーションの場合、このマッピングに伴うオーバーヘッドは大きくなる可能性があります。

セッション アフィニティ

テナント マッピング ロジックのパフォーマンス オーバーヘッドを低減するための方法の 1 つは、"セッション アフィニティ" を使用することです。 すべての要求に対してマッピングを実行するのではなく、各セッションの最初の要求でのみ情報を計算することを検討してください。 その後、アプリケーションはクライアントにセッション Cookie を提供します。 クライアントは、そのセッション内のすべての後続のクライアント要求を使用して、セッション Cookie をサービスに返します。

以下の質問を検討します。

• セッション アフィニティを使用して、テナントに要求をマップするオーバーヘッドを減らすことができるか。
• 各テナントの物理的なデプロイに要求をルーティングするために、どのようなサービスを使用するか。 それらのサービスでは Cookie ベースのセッション アフィニティがサポートされているか。

テナントの移行

テナントのライフサイクルの一環として、テナントを新しいインフラストラクチャに移動する必要があることがよくあります。 テナントが新しいデプロイに移動されると、アクセスする HTTP エンドポイントが変更される可能性があります。 この状況が発生した場合は、テナント マッピング プロセスを更新する必要があることを考慮してください。 以下の点を考慮する必要があります。

• アプリケーションで要求のマッピングにドメイン名が使用される場合は、移行時に DNS の変更も必要になることがあります。 使用する DNS サービスの DNS エントリの有効期限によっては、DNS の変更がクライアントに反映されるまでに時間がかかることがあります。
• 移行プロセス中に移行によってエンドポイントのアドレスが変更される場合は、そのテナントに対する要求を、自動的に更新されるメンテナンス ページに一時的にリダイレクトすることを検討してください。

共同作成者

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

プリンシパル作成者:

• Daniel Scott-Raynsford |パートナー テクノロジ ストラテジスト

その他の共同作成者:

• John Downs | プリンシパル ソフトウェア エンジニア
• Paolo Salvator | FastTrack for Azure のプリンシパル カスタマー エンジニア
• Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア

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

次のステップ

マルチテナント アプリケーションでドメイン名を使用する場合の考慮事項について説明します。