ID は、あらゆるマルチテナント ソリューションの重要な要素です。 アプリケーションの ID コンポーネントは、次のタスクを担当します。
ユーザーの ID を確認することは、認証と呼ばれます。
テナントのスコープ内でユーザーのアクセス許可を適用する (承認と呼ばれます)
顧客は、外部アプリケーションがデータにアクセスしたり、ソリューションと統合したりすることを承認することもできます。 ユーザーの ID によって、ユーザーまたはサービスがアクセスできる情報が決まります。 テナント間でアプリケーションとデータを分離するための ID 要件を考慮することが重要です。
注意事項
マルチテナントおよびサービスとしてのソフトウェア (SaaS) アプリケーション内の認証および承認サービスは、通常、外部 ID プロバイダー (IdP) によって提供されます。 IdP は、通常、マネージド ID プラットフォームの不可欠な部分です。
独自の IdP の構築は、複雑でコストがかかり、セキュリティ保護が困難です。 アンチ パターンと見なされ、お勧めしません。
マルチテナント ID 戦略を定義する前に、まず、サービスの次の高レベルの ID 要件を考慮してください。
ユーザーまたは ワークロード ID が 、製品ファミリ内の 1 つのアプリケーションまたは複数のアプリケーションにアクセスするかどうかを決定します。 一部の製品ファミリには、POS システムや在庫管理プラットフォームなど、同じ ID インフラストラクチャを共有する個別のアプリケーションが含まれる場合があります。
ソリューションで OAuth2 や OpenID Connect などの先進認証と承認の標準が実装されているかどうかを検討します。
認証が UI ベースのアプリケーションに制限されているかどうか、または API アクセスがテナントやサード パーティのシステムにも適用されるかどうかを評価します。
テナントが独自の IdP とフェデレーションする必要があるかどうか、およびテナントごとに複数の IdP をサポートする必要があるかどうかを判断します。 たとえば、Microsoft Entra ID、Auth0、Active Directory フェデレーション サービスを持つテナントがあり、各テナントがソリューションとフェデレーションしている場合です。 IdP でサポートする必要がある内容がこれらのプロトコルによって決まるため、IdP で使用するフェデレーション プロトコルを特定します。
関連するコンプライアンス要件を確認してください。これには、ID 戦略に影響を与える 一般データ保護規則 (GDPR) などの要件が含まれます。
法律、コンプライアンス、運用のニーズを満たすために、テナントが特定の地理的リージョンに ID データを格納する必要があるかどうかを判断します。
ユーザーがアプリケーション内の複数のテナントのデータにアクセスするかどうかを評価します。 その場合は、シームレスなテナント切り替えをサポートするか、特定のユーザーのテナント間で統合ビューを提供することが必要になる場合があります。 たとえば、Azure portal にサインインするユーザーは、アクセスできるさまざまな Microsoft Entra ID ディレクトリとサブスクリプションを簡単に切り替えることができます。
高度な要件を確立したら、ユーザー ディレクトリ ソースやサインアップとサインイン フローなど、より具体的な詳細と要件の計画を開始できます。
ID ディレクトリ
マルチテナント ソリューションでユーザーまたはサービスの認証と認可を行うには、ID 情報を格納するための場所が必要です。 ディレクトリには、各 ID の権限のあるレコードを含めることができます。 または、別の IdP のディレクトリに格納されている外部 ID への参照が含まれている場合もあります。
マルチテナント ソリューションの ID システムを設計するときは、次の種類の IdP のうち、実際のテナントと顧客に必要なのは、どれであるかを考える必要があります。
ローカル IdP: ローカル IdP を使用すると、ユーザーは自分でサービスにサインアップできます。 ユーザーは、ユーザー名、メール アドレス、ID (ポイント カード番号など) を指定します。 パスワードなどの資格情報も指定します。 この IdP には、ユーザー識別子と資格情報の両方が格納されます。
Social IdP: ソーシャル IdP を使用すると、ユーザーはソーシャル ネットワーク上にある ID や、Facebook、Google、個人の Microsoft アカウントなどの他のパブリック IdP を使用できます。 ソーシャル IDP は、企業間 (B2C) SaaS ソリューションでよく使用されます。
テナントの Microsoft Entra ID ディレクトリ: 多くの企業間 (B2B) SaaS ソリューションでは、テナントに既に独自の Microsoft Entra ID ディレクトリがあり、ソリューションにアクセスするための IdP として自分のディレクトリを使用することが必要な場合があります。 このアプローチは、ソリューションが マルチテナント Microsoft Entra アプリケーションとして構築されている場合に可能です。
テナントの IdP とのフェデレーション: 一部の B2B SaaS ソリューションでは、テナントに Microsoft Entra ID 以外の独自の IdP があり、ソリューションとフェデレーションすることが必要な場合があります。 フェデレーションを使用すると、シングル サインオン (SSO) が有効になります。 また、テナントは、ソリューションとは別に、ユーザーのライフ サイクルとセキュリティ ポリシーを管理することもできます。
テナントが複数の IdP をサポートする必要があるかどうかを検討する必要があります。 たとえば、1 つのテナントでローカル ID、ソーシャル ID、フェデレーション ID をサポートする必要がある場合があります。 この要件は、企業が従業員と請負業者の両方を対象としたソリューションを使用する場合に一般的です。 フェデレーションを使用して従業員にアクセス権を付与すると同時に、フェデレーション IdP にアカウントを持たない請負業者またはユーザーにアクセスを許可することもできます。
認証情報とテナント認可情報を保存する
マルチテナント ソリューションでは、複数の種類の ID 情報をどこに格納するかを検討する必要があります。そうした情報の種類の例を次に示します。
ユーザーアカウントとサービス アカウントに関する詳細(テナントに必要な名前やその他の情報など)。
多要素認証 (MFA) の情報など、ユーザーを安全に認証するために必要な情報。
承認のためのテナント固有の情報 (テナント ロールやアクセス許可など)。
注意事項
認証プロセスを自前で構築することはお勧めしません。 最近の IdP は、アプリケーションのために、これらの認証サービスを提供しており、また、MFA や条件付きアクセスなど他の重要な機能も備えています。 独自 ID プロバイダーの構築は避けるべきです。 それは推奨されません。
ID 情報の保存については、次の選択肢を検討してください。
すべての ID 情報と認可情報を IdP ディレクトリに格納し、それを複数のテナント間で共有する。
IdP ディレクトリにユーザー資格情報を格納します。 テナント情報と共に、承認データをアプリケーション層に格納します。
ユーザーに使用する ID の数を決める
マルチテナント ソリューションでは、多くの場合、ユーザーまたはワークロード ID が複数のテナント間でアプリケーション リソースとデータにアクセスできます。 この方法が必要な場合は、次の要因を考慮してください。
ユーザーごとに 1 つのユーザー ID を作成するか、テナントとユーザーの組み合わせごとに個別の ID を作成するかを決定します。
可能な場合は、各ユーザーに対して 1 つの ID を使用します。 これにより、ソリューション プロバイダーとユーザーの両方のアカウント管理が簡略化されます。 また、最新の IdP が提供するインテリジェントな脅威保護の多くは、1 つのユーザー アカウントを持つ各ユーザーに依存します。
一部のシナリオでは、複数の個別の ID を使用します。 たとえば、仕事上の目的と私的な目的の両方にあなたのシステムを使用するユーザーは、そのアカウントを区別したいと考えるでしょう。 または、テナントに厳密な規制または地理的なデータ ストレージ要件がある場合は、規制や法律に準拠できるように、複数の ID を持つ必要がある場合があります。
テナントごとの ID を使用する場合は、資格情報を複数回保存しないでください。 ユーザーの資格情報は、1 つの ID に対して保存する必要があります。ゲスト ID などの機能を使用して、複数テナントの ID レコードから同じユーザーの資格情報を参照するようにしてください。
テナント データへのアクセス権をユーザーに付与する
ユーザーをテナントにマップする方法を検討します。 たとえば、サインアップ プロセス中に、ユーザーがテナントに初めてアクセスするときに入力する一意の招待コードを提供できます。 一部のソリューションでは、ユーザーのサインアップ メール アドレスのドメイン名で、関連付けられているテナントを識別できます。 または、ユーザーの ID レコードの別の属性を使用して、テナント マッピングを決定することもできます。 この関連付けは、テナントとユーザーの両方の不変で一意の識別子に基づいて格納する必要があります。
ソリューションで、各ユーザーが 1 つのテナントのデータにアクセスすることを制限している場合は、次の決定事項を検討してください。
IdP がユーザーがアクセスするテナントを検出する方法を決定します。
IdP がテナント識別子をアプリケーションと通信する方法について説明します。 通常、テナント識別子要求がトークンに追加されます。
1 人のユーザーに複数のテナントへのアクセス権を付与する必要がある場合は、次の決定事項を検討してください。
このソリューションでは、ユーザーを識別し、テナント間で適切なアクセス許可を付与するためのロジックをサポートする必要があります。 たとえば、あるテナントではユーザーが管理者権限を持っていても、別のテナントではアクセスが制限されている場合があります。 たとえば、あるユーザーがソーシャル ID でサインアップし、2 つのテナントへのアクセスを許可されているとします。 テナント A は、ユーザーの ID にさらに情報を追加して充実させました。 このエンリッチされた情報へのアクセスをテナント B に許可すべきでしょうか。
明確なメカニズムにより、ユーザーはテナントを切り替えることができます。 このアプローチにより、スムーズなユーザー エクスペリエンスが確保され、テナント間の偶発的なアクセスを防ぐことができます。
ワークロード ID を使用する場合は、アクセスしようとしているテナントを指定する必要があります。 この要件には、認証要求へのテナント固有のコンテキストの埋め込みなどがあります。
ユーザーの ID レコードに格納されているテナント固有の情報が、テナント間で意図せず漏えいする可能性があるかどうかを検討します。 たとえば、ユーザーがソーシャル ID でサインアップして 2 つのテナントにアクセスし、テナント A がユーザー プロファイルを強化する場合は、テナント B がそのエンリッチされた情報にアクセスできる必要があるかどうかを判断します。
ローカル ID またはソーシャル ID のユーザー サインアップ プロセス
一部のテナントでは、ユーザーが各自でサインアップしてソリューション内での ID を取得できることが求められます。 テナントの IdP とのフェデレーションを必要としない場合は、セルフサービス サインアップが必要になる場合があります。 セルフサインアップ プロセスが必要な場合は、次の要因を考慮する必要があります。
ユーザーがサインアップを許可する ID ソースを定義します。 たとえば、ユーザーがローカル ID を作成し、ソーシャル IdP も使用できるかどうかを判断します。
ローカル ID が使用されている場合に、ソリューションで特定の電子メール ドメインのみを許可するかどうかを指定します。 たとえば、テナントが
@contoso.comメール アドレスを持つユーザーへのサインアップを制限できるかどうかを判断します。ローカル ID の識別に使用されるユーザー プリンシパル名 (UPN) を明確に確立する必要があります。 一般的な UPN には、電子メール アドレス、ユーザー名、電話番号、またはメンバーシップ識別子が含まれます。 UPN は変更される可能性があるため、承認と監査の目的では、基になる変更不可能な一意の識別子を参照することが推奨されます。 たとえば、Microsoft Entra ID のオブジェクト ID (OID) です。
UPN の精度を確保するために、UPN の検証が必要になる場合があります。 このプロセスには、アクセス権を付与する前に、電子メール アドレスまたは電話番号の所有権の検証が含まれる場合があります。
一部のソリューションでは、テナント管理者がユーザーのサインアップを承認する必要があります。 この承認プロセスにより、テナントに参加するユーザーを管理できます。
テナントにテナント固有のサインアップ エクスペリエンスまたは URL が必要かどうかを決定します。 たとえば、テナントがユーザーのサインアップ時にブランド化されたサインアップ エクスペリエンスを必要とするか、サインアップ要求をインターセプトし、続行する前に追加の検証を実行する機能を決定します。
セルフ サインアップ ユーザーのテナント アクセス
ユーザーが ID にサインアップできる場合は、テナントへのアクセス権を付与するプロセスを定義します。 サインアップ フローには、ユーザーの電子メール アドレスなど、ユーザーに関する情報に基づく手動アクセス許可プロセスまたは自動化されたプロセスが含まれる場合があります。 このプロセスを計画し、次の要因を考慮することが重要です。
サインアップ フローで、特定のテナントへのアクセス権がユーザーに付与されることを決定する方法を定義します。
ソリューションが必要に応じてテナントへのユーザー アクセスを自動的に取り消すかどうかを定義します。 たとえば、ユーザーが組織を離れるとき、アクセス権を削除するための手動または自動化されたプロセスが存在する必要があります。
テナントが自分の環境にアクセスできるユーザーを確認し、割り当てられたアクセス許可を理解できるように、ユーザー監査機能を提供します。
アカウント自動ライフサイクル管理
法人のお客様にとっての一般的な要件は、アカウントの導入および退職手続きの自動化を可能にする機能のセットです。 System for Cross-Domain Identity Management (SCIM) などのオープン プロトコルは、自動化に業界標準のアプローチを提供します。 この自動化されたプロセスには、通常、ID レコードの作成と削除、およびテナントのアクセス許可の管理が含まれます。 マルチテナント ソリューションで自動アカウント ライフサイクル管理を実装する場合は、次の要因を考慮してください。
顧客が各テナントの自動ライフサイクル プロセスを構成および管理する必要があるかどうかを判断します。 たとえば、あなたのアプリケーションで、ユーザーのオンボード時に、複数のテナント内に ID を作成する必要があるものの、テナントごとに一連のアクセス許可が異なる場合があります。
SCIM を実装するか、フェデレーションを提供する必要があるかを判断します。 フェデレーションを使用すると、テナントは、ソリューション内のローカル ユーザーを管理する代わりに、独自のシステム内で信頼できるソースを保持することで、ユーザー管理の制御を維持できます。
ユーザー認証プロセス
ユーザーがマルチテナント アプリケーションにサインインするとき、そのユーザーは ID システムによって認証されます。 認証プロセスを計画するときは、次の要因を考慮してください。
一部のテナントでは、独自の MFA ポリシーを構成する機能が必要になる場合があります。 たとえば、テナントが金融サービス業界のユーザーである場合、厳しい MFA ポリシーを実装する必要があります。一方、小規模のオンライン小売業者の場合、同じ要件は該当しないと考えられます。
カスタム条件付きアクセス規則を定義するオプションは、テナントにとって重要な場合があります。 たとえば、各テナントが特定の地域からのサインイン試行をブロックするケースが考えられます。
テナントがサインイン プロセスを個別にカスタマイズする必要があるかどうかを判断します。 たとえば、ソリューションで顧客のロゴを表示する必要がある場合があります。 または、報酬番号などのユーザー情報を別のシステムから取得し、IdP に返してユーザー プロファイルを強化する必要がある場合があります。
一部のユーザーは、他のユーザーを偽装する必要があります。 たとえば、サポート チーム メンバーは、ユーザーとして認証しなくても、ユーザー アカウントを偽装することで、別のユーザーが抱える問題を調査できます。
一部のユーザーまたは外部アプリケーションには API アクセスが必要な場合があります。 これらのシナリオには、標準のユーザー認証フローをバイパスするソリューションの API を直接呼び出す場合があります。
ワークロード ID
ほとんどのソリューションでは、ID といえば通常、ユーザーを表します。 一部のマルチテナント システムでは、ワークロード ID をサービスやアプリケーションで使用して、アプリケーション リソースにアクセスすることもできます。 たとえば、テナントが管理タスクを自動化できるように、ソリューションが提供する API にアクセスする必要がある場合があります。
Microsoft Entra はワークロード ID をサポートしており、他の IdP も一般的にサポートしています。
ワークロード ID はユーザー ID と似ています。ただしワークロード ID では、異なる認証方法、たとえばキーや証明書が使用されるのが一般的です。 ワークロード ID では MFA は使用されません。 代わりに、ワークロードアイデンティティは通常、定期的なキーのローテーションや証明書の有効期限など、ほかのセキュリティコントロールを必要とします。
テナントがマルチテナント ソリューションへのワークロード ID アクセスを有効にできる場合は、次の要因を考慮する必要があります。
各テナントでワークロード ID を作成および管理する方法を決定します。
ワークロードアイデンティティリクエストのスコープをテナントに設定する方法を決定します。
各テナントが作成するワークロード ID の数を制限する必要があるかどうかを評価します。
各テナントのワークロード ID に条件付きアクセス制御が必要かどうかを判断します。 たとえば、テナントは、特定のリージョン以外からのワークロード ID が認証されないよう制限したい場合があります。
ワークロード ID をセキュリティで保護するためにテナントに提供するセキュリティコントロールを特定します。 たとえば、キーの自動ローリング、キーの有効期限、証明書の有効期限、サインイン リスクの監視は、ワークロード ID の誤用のリスクを軽減するのに役立ちます。
SSOのためにアイデンティティプロバイダーとフェデレーションする
既に独自のユーザー ディレクトリを持っているテナントは、ソリューションを自分のディレクトリに フェデレーション する必要がある場合があります。 フェデレーションを使用すると、ソリューションでは、個別の ID を持つ別のディレクトリを管理する代わりに、ディレクトリ内の ID を使用できます。
フェデレーションは、一部のテナントが独自の ID ポリシーを指定したり、SSO エクスペリエンスを有効にしたりする場合に特に重要です。
テナントがソリューションとフェデレーションすることが予想される場合は、次の要因を考慮してください。
テナントのフェデレーションを構成するプロセスを検討してください。 テナントがフェデレーション自体を構成するかどうか、またはプロセスでチームによる手動の構成とメンテナンスが必要かどうかを判断します。
ソリューションがサポートするフェデレーション プロトコルを定義します。
フェデレーションの構成ミスによって意図しないテナントへのアクセスが許可されないようにするプロセスを確立します。
1 つのテナントの IdP をソリューション内の複数のテナントにフェデレーションする必要があるかどうかを計画します。 たとえば、トレーニングテナントと運用テナントの両方をお持ちのお客様は、各テナントと同じ IdP をフェデレーションする必要がある場合があります。
認可モデル
ソリューションにとって最も理にかなった認可モデルを決定します。 次の一般的な承認方法を検討してください。
ロールベースの承認: ユーザーはロールに割り当てられます。 アプリケーションの一部の機能は、特定のロールに制限されます。 たとえば、管理者ロールのユーザーはすべての操作を実行できるのに対し、それよりも下位のロールのユーザーには、システム全体にわたるアクセス許可の一部のみが与えられます。
リソース ベースの承認: ソリューションには一連の個別のリソースが用意されており、それぞれに独自のアクセス許可セットがあります。 あるリソースの管理者になっている特定のユーザーが、別のリソースにはアクセスできないこともあります。
これらのモデルは異なり、選択したアプローチは実装に影響し、実装できる承認ポリシーの複雑さに影響します。
権利とライセンス
ソリューションによっては、商用価格モデルとしてユーザー数によるライセンスを使用できます。 このシナリオでは、さまざまな機能を持つさまざまなレベルのユーザー ライセンスを提供します。 たとえば、あるライセンスを持つユーザーには、アプリケーションが備えている機能の一部のみ使用が許可されます。 特定のユーザーにそのライセンスに応じてアクセスが許可される機能は、"エンタイトルメント" と呼ばれることがあります。
通常、アプリケーション コードまたは専用のエンタイトルメント システムは、ID システムではなく権利を追跡して適用します。 このプロセスは承認に似ていますが、ID 管理レイヤーの外部で発生します。
ID のスケールと認証のボリューム
マルチテナント ソリューションの増加に伴い、ソリューションで処理する必要があるユーザーとサインイン要求の数が増えます。 次の要因について検討します。
ユーザー ディレクトリが必要なユーザー数をサポートするようにスケーリングするかどうかを評価します。
認証プロセスが予想されるサインイン数とサインアップ数を処理するかどうかを評価します。
認証システムで処理できないスパイクがあるかどうかを判断します。 たとえば、太平洋太平洋時間の午前 9 時に、米国西部のすべてのユーザーが作業を開始し、ソリューションにサインインすると、サインイン要求が急増します。 これらのシナリオは、 ログイン ストームと呼ばれることもあります。
ソリューションの一部で高負荷が認証プロセスのパフォーマンスに影響するかどうかを判断します。 たとえば、認証でアプリケーション層 API の呼び出しが必要な場合、認証要求の急増がシステムの全体的なパフォーマンスに影響する可能性があります。
IdP が使用できなくなった場合のソリューションの動作を定義します。 ビジネス継続性を維持するためにバックアップ認証サービスを含める必要があるかどうかを検討します。
貢献者
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主な著者
- John Downs | プリンシパル ソフトウェア エンジニア
- Daniel Scott-Raynsford |パートナー テクノロジ ストラテジスト
- Arsen Vladimirskiy | FastTrack for Azure のプリンシパル カスタマー エンジニア
その他の共同作成者:
- Jelle Druyts | FastTrack for Azure のプリンシパル カスタマー エンジニア
- Landon Pierce | シニア カスタマー エンジニア
- Sander van den Hoven | シニア パートナー テクノロジ ストラテジスト
- Nick Ward | シニア クラウド ソリューション アーキテクト
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。