Azure
Whenever a request arrives into your application, you need to determine the tenant context, which is the tenant that is making the request. 異なる地理的リージョンでホストされる可能性があるテナント固有のインフラストラクチャがある場合は、テナントへの受信要求を照合する必要があります。 次に、次に示すように、そのテナントのリソースをホストする物理インフラストラクチャに要求を転送する必要があります。
多くのマルチテナント アプリケーションにも、ユーザー ベースのアクセス許可があります。 テナント マッピングは別のアクティビティです。 要求を行っているユーザーと、そのユーザーが作業しているテナントの両方を知っている必要があります。
この記事では、要求を適切なテナントにマップすることを検討できるアプローチと、そのアプローチに関連するトレードオフについて、技術的な意思決定者向けのガイダンスを提供します。
Note
このページでは、ほとんどの場合、Web サイトや API などの HTTP ベースのアプリケーションについて説明します。 ただし、同じ基本原則の多くは、他の通信プロトコルを使用するマルチテナント アプリケーションに適用されます。
テナントを識別する方法
受信要求のテナントを識別するには、複数の方法があります。 各方法では、受信要求の一部の側面を調べる必要があります。
Domain names
テナント固有のドメイン名またはサブドメイン名を使用する場合、Host ヘッダー、X-Forwarded-Host ヘッダー、または各要求の元のホスト名を含む別の HTTP ヘッダーを使用して、要求をテナントに簡単にマップできる可能性があります。
ただし、次の点を考慮してください。
- サービスへのアクセスに使用するドメイン名をユーザーが知る方法
- ランディング ページやログイン ページなど、すべてのテナントが使用する中央のエントリ ポイントはありますか。 その場合、ユーザーは、使用しているテナントをどのように選択しますか?
- 承認トークンなど、テナントのリソースへのアクセスを確認するために使用しているその他の情報は何ですか? 承認トークンにはテナント固有のドメイン名が含まれていますか?
HTTP 要求のプロパティ
テナント固有のドメイン名を使用しない場合でも、HTTP 要求の側面を使用して、特定の要求の対象となるテナントを識別できる場合があります。 たとえば、テナント名を tailwindtradersとして識別する HTTP 要求があるとします。 これは、次のいずれかの方法を使用して伝達される場合があります。
- 。
- URL 内のクエリ文字列 (
https://contoso.com/app?tenant=tailwindtradersなど)。 - 。
Important
カスタム HTTP 要求ヘッダーは、WEB ブラウザーから HTTP GET 要求が発行される場合や、要求が一部の種類の Web プロキシによって処理される場合には役立ちません。 GET 操作には、カスタム HTTP ヘッダーを使用する必要があるのは、API を構築している場合、または要求を発行するクライアントを制御していて、ヘッダーを変更または削除する可能性のある Web プロキシが要求処理チェーンに含まれていない場合のみです。
この方法を使用する場合は、次の質問を考慮する必要があります。
- ユーザーはサービスにアクセスする方法を知っていますか? たとえば、クエリ文字列を使用してテナントを識別する場合、中央のランディング ページでは、クエリ文字列を追加してユーザーを適切なテナントのページに誘導する必要がありますか。
- ランディング ページやログイン ページなど、すべてのテナントが使用する中央のエントリ ポイントはありますか? その場合、ユーザーはアクセスする必要があるテナントをどのように選択しますか?
- アプリケーションは API を提供していますか? たとえば、Web アプリケーションはシングルページ アプリケーション (SPA) か、API バックエンドを持つモバイル アプリケーションですか? If it is, you might be able to use an API gateway or reverse proxy to perform tenant mapping.
Token claims
多くのアプリケーションでは、OAuth 2.0 や SAML などのクレーム ベースの認証と承認プロトコルが使用されます。 これらのプロトコルは、クライアントに承認トークンを提供します。 A token contains a set of claims, which are pieces of information about the client application or user. 要求は、ユーザーのメール アドレスなどの情報を伝達するために使用できます。 その後、システムにユーザーのメール アドレスを含め、ユーザーからテナントへのマッピングを検索し、要求を適切なデプロイに転送できます。 または、ID システムにテナント マッピングを含め、テナント ID 要求をトークンに追加することもできます。
要求を使用して要求をテナントにマップする場合は、次の質問を考慮する必要があります。
- 要求を使用してテナントを識別しますか? どの要求を使用しますか?
- ユーザーを複数のテナントのメンバーにすることはできますか? これが可能な場合、ユーザーは特定の要求に対して操作するテナントをどのように選択しますか?
- すべてのテナントに対して中央認証と承認システムはありますか? そうでない場合、すべてのトークン機関が一貫したトークンと要求を発行するようにするにはどうすればよいですか?
API keys
多くのアプリケーションで API が公開されています。 これらは、組織内での内部使用、またはパートナーや顧客による外部使用の場合があります。 A common method of authentication for APIs is to use an API key. API キーは各要求で提供されます。 キーが発行されたテナント ID を記録した場合は、キーが使用されたときにテナント ID を検索できます。
Note
API キーは、手動で作成および管理する必要があり、有効期間が長く、頻繁に再利用されるため、およびクレームが含まれていないため、高レベルのセキュリティを提供しません。 より最新で安全な方法は、OAuth 2.0 や OpenID Connect などの有効期間の短いトークンでクレームベースの承認メカニズムを使用することです。
API キーは、いくつかの方法で生成できます。 2 つの一般的な方法を次に示します。
- 暗号化されたランダムな値を生成し、テナント ID と共に参照テーブルに格納します。 要求が受信されると、システムは参照テーブルで API キーを検索し、テナント ID と一致します。
- テナント ID を含む意味のある文字列を作成します。 Digitally sign the key by using an approach like HMAC. 各要求を処理するときは、署名を確認し、テナント ID を抽出します。
次の質問について考えてみましょう。
- API キーを生成して発行する方法
- API クライアントが API キーを安全に受け取って格納する方法
- 一定期間後に API キーの有効期限が切れる必要がありますか? ダウンタイムを発生させることなく、クライアントの API キーをどのようにローテーションしますか?
- 顧客が生成した API キーは、API に適切なレベルのセキュリティを提供しますか?
Note
API キーはパスワードと同じではありません。 API キーはシステムによって生成される必要があり、各 API キーを 1 つのテナントに一意にマップできるように、すべてのテナントで一意である必要があります。 Azure API Management などの API ゲートウェイでは、API キーの生成と管理、受信要求のキーの検証、個々の API サブスクライバーへのキーのマップを行うことができます。
Client certificates
クライアント証明書認証 (相互 TLS (mTLS) とも呼ばれる) は、サービス間通信や、認証されていないユーザーが使用する無人デバイスまたはキオスクでよく使用されます。 クライアント証明書は、クライアントを認証するための安全な方法を提供します。 Similarly to tokens and claims, client certificates provide attributes that can be used to determine the tenant. For example, the subject of the certificate may contain the email address of the user, which can be used to look up the tenant.
テナント マッピングにクライアント証明書を使用する場合は、次の点を考慮してください。
- サービスによって信頼されているクライアント証明書を安全に発行して更新するにはどうすればよいですか? クライアント証明書は、証明書の管理と発行に特別なインフラストラクチャを必要とするため、操作が複雑になる場合があります。 If handled improperly, these complexities can reduce your security instead of increasing it.
- クライアント証明書は、最初のログイン要求にのみ使用されるか、サービスへのすべての要求にアタッチされますか?
- 多数のクライアントがある場合、証明書の発行と管理のプロセスは管理できなくなりますか?
- クライアント証明書とテナントの間のマッピングはどのように実装しますか?
Reverse proxies
リバース プロキシ (アプリケーション プロキシとも呼ばれます) を使用して、HTTP 要求をルーティングできます。 リバース プロキシは、イングレス エンドポイントからの要求を受け入れ、多数のバックエンド エンドポイントのいずれかに要求を転送できます。 リバース プロキシは、要求情報の一部間のマッピングを実行し、アプリケーション インフラストラクチャからタスクをオフロードできるため、マルチテナント アプリケーションに役立ちます。
多くのリバース プロキシでは、要求のプロパティを使用して、テナントのルーティングに関する決定を行うことができます。 宛先ドメイン名、URL パス、クエリ文字列、HTTP ヘッダー、要求本文のトークンまたは一部内の要求を検査できます。
Azure では、次の一般的なリバース プロキシが使用されます。
- Azure Front Door は、グローバル ロード バランサーと Web アプリケーション ファイアウォールです。 Microsoft グローバル エッジ ネットワークを使用して、高速でセキュリティで保護された高度にスケーラブルな Web アプリケーションを作成します。 You can use rule sets to extract tenant identifiers and put them into another part of the request.
- Azure Application Gateway は、バックエンド サービスと同じ物理リージョンにデプロイするマネージド Web トラフィック ロード バランサーです。
- Azure API Management は API トラフィック用に最適化されています。 Azure API Management provides a comprehensive policy engine that provides a great deal of flexibility for extracting tenant information from requests.
- 商用およびオープンソースのテクノロジ (自分でホストする) には、nginx、Traefik、HAProxy が含まれます。
Request validation
アプリケーションで、受信した要求がテナントに対して承認されていることを検証することが重要です。 たとえば、アプリケーションでカスタム ドメイン名を使用して要求をテナントにマップする場合、アプリケーションは、アプリケーションが受信した各要求がそのテナントに対して承認されていることを確認する必要があります。 要求にドメイン名またはその他のテナント識別子が含まれている場合でも、アクセス権を自動的に付与する必要があるわけではありません。 When you use OAuth 2.0, you perform the validation by inspecting the audience and scope claims.
Note
これは、Microsoft Azure Well-Architected Framework のゼロ トラスト セキュリティ設計原則の一部です。
要求の検証を実装する場合は、次の点を考慮する必要があります。
- アプリケーションに対するすべての要求をどのように承認しますか? 要求を物理インフラストラクチャにマップするために使用する方法に関係なく、要求を承認する必要があります。
- すべての検証ロジックを自分で実装する代わりに、信頼された、広く使用され、よく維持されている認証と承認フレームワークとミドルウェアを使用します。 たとえば、トークン署名検証ロジックやクライアント証明書暗号化ライブラリを構築しないでください。 代わりに、検証およびテストされたアプリケーション プラットフォーム (または既知の信頼済みパッケージ) の機能を使用してください。
Performance
テナント マッピング ロジックは、アプリケーションに対するすべての要求で実行される可能性があります。 ソリューションの拡大に合わせて、テナント マッピング プロセスがどの程度適切にスケーリングされるかを検討します。 たとえば、テナント マッピングの一部としてデータベース テーブルに対してクエリを実行した場合、データベースは大量の負荷をサポートしますか? テナント マッピングでトークンの暗号化を解除する必要がある場合、計算要件は時間の経過と同時に高くなりすぎますか? トラフィックが非常に控えめであれば、全体的なパフォーマンスに影響を与える可能性はありません。 ただし、大規模なアプリケーションがある場合、このマッピングに伴うオーバーヘッドが大きくなる可能性があります。
Session cookies
One approach to reducing the performance overhead of tenant mapping logic is to use session cookies. すべての要求でマッピングを実行するのではなく、各セッションの最初の要求についてのみ情報を計算することを検討してください。 その後、アプリケーションはセッション Cookie をクライアントに提供します。 クライアントはセッション Cookie をサービスに渡し、そのセッション内の後続のすべてのクライアント要求を受け取ります。
Note
Azure の多くのネットワークおよびアプリケーション サービスでは、セッション Cookie を発行できます。
次の質問について考えてみましょう。
- セッション Cookie を使用して、要求をテナントにマッピングするオーバーヘッドを減らすことができますか?
- 各テナントの物理デプロイに要求をルーティングするには、どのようなサービスを使用しますか? これらのサービスは Cookie ベースのセッションをサポートしていますか?
Tenant migration
Tenants often need to be moved to new infrastructure as part of the tenant lifecycle. テナントが新しいデプロイに移動されると、アクセスする HTTP エンドポイントが変更される可能性があります。 このような場合は、テナント マッピング プロセスを変更する必要があることを検討してください。 次の要因を考慮する必要がある場合があります。
- アプリケーションでマッピング要求にドメイン名を使用している場合は、移行時に DNS の変更が必要になる場合もあります。 DNS サービスの DNS エントリの有効期間 (TTL) によっては、DNS の変更がクライアントに反映されるまでに時間がかかる場合があります。
- 移行プロセス中に移行によってエンドポイントのアドレスが変更される場合は、テナントの要求を自動的に更新されるメンテナンス ページに一時的にリダイレクトすることを検討してください。
Contributors
この記事は Microsoft によって管理されています。 当初の寄稿者は以下のとおりです。
Principal author:
- Daniel Scott-Raynsford | Partner Technology Strategist
Other contributors:
- John Downs | Principal Software Engineer, Azure Patterns & Practices
- Paolo Salvatori | Principal Customer Engineer, FastTrack for Azure
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
Next steps
マルチテナント アプリケーションでドメイン名を操作する場合の考慮事項について説明します。