マルチテナント ソリューションの ID アーキテクチャに関する考慮事項

  • [アーティクル]

ID は、あらゆるマルチテナント ソリューションの重要な要素です。 次の 2 つの点はどちらも、アプリケーションの ID コンポーネントが担います。

  • ユーザーの本人確認をする ("認証")。
  • テナントのスコープ内でユーザーのアクセス許可を適用する ("認可")。

ソリューションの利用者がそのデータへのアクセス、つまりそのソリューションへの統合を外部アプリケーションに認可したいと考える場合もあるでしょう。 ユーザーまたはサービスがアクセスできる範囲は、ユーザーの ID によって決まります。 アプリケーションおよびデータをテナントごとに分離するためには ID 要件を考慮することが大切です。

注意事項

マルチテナント型や SaaS 型のアプリケーションでは通常、認証サービスと認可サービスがサードパーティの ID プロバイダー (IdP) によって提供されます。 一般に ID プロバイダーは、IDaaS (IDentity as a Service) プラットフォームの要となる要素です。

独自に IdP を構築するのは複雑でコストがかかるうえ、安全に構築するのは困難です。 独自 ID プロバイダーの構築は避けるべきです。 それは推奨されません。

マルチテナント型の ID 戦略を定義する前にまず、サービスの全体的な ID 要件を考慮する必要があります。たとえば、次の要件が該当します。

  • ユーザーまたはワークロードの ID を使用してアクセスするのは、1 つのアプリケーションか、それとも同じ製品ファミリ内の複数のアプリケーションか。 たとえば小売製品ファミリには、販売時点情報管理アプリケーションと在庫管理アプリケーションがあって、どちらも同じ ID ソリューションを共有することが考えられます。
  • 先進の認証と認可を実装する予定はあるか (OAuth2 と OpenID Connect など)。
  • ソリューションで提供する認証の対象は、UI ベースのアプリケーションだけか。 それとも、テナントやサード パーティに API アクセスも提供するか。
  • テナントがその独自の IdP とのフェデレーションを必要としていて、テナントごとに複数の異なる ID プロバイダーをサポートする必要はあるか。 たとえば、Microsoft Entra ID を使うテナント、Auth0 を使用するテナント、Active Directory フェデレーション サービス (ADFS) を使うテナントがいて、それぞれがあなたのソリューションとのフェデレーションを希望するケースが考えられます。 また、テナントの IdP のフェデレーション プロトコルのうちどれをサポートするかを把握することも必要です。それらのプロトコルによって、皆さん自身の IdP の要件が左右されるからです。
  • 満たすべき具体的なコンプライアンス要件はあるか (GDPR など)。
  • テナントに、その ID 情報が特定の地域内に保管されていなければならないという要件はあるか。
  • ソリューションのユーザーがアプリケーション内でアクセスする必要のあるデータは、1 つのテナントのデータか、それとも複数のテナントのデータか。 テナントをすばやく切り替えたり、複数のテナントから統合された情報を確認したりする必要はあるか。 たとえば、Azure portal にサインインしたユーザーは、自分にアクセス権があるさまざまな Azure Active Directory とサブスクリプションを簡単に切り替えることができます。

全体的な要件が明確になったら、ユーザー ディレクトリのソースやサインアップとサインインのフローなど、より具体的な内容と要件の計画に着手できます。

ID ディレクトリ

マルチテナント ソリューションでユーザーまたはサービスの認証と認可を行うには、ID 情報を格納するための場所が必要です。 "ディレクトリ" には、各 ID の信頼できるレコードを追加できるほか、別の ID プロバイダーのディレクトリに格納されている外部 ID への参照を含む場合もあります。

マルチテナント ソリューションの ID システムを設計するときは、次の種類の IdP のうち、実際のテナントと顧客に必要なのは、どれであるかを考える必要があります。

  • ローカル ID プロバイダー。 ユーザーは、ローカル ID プロバイダーを通じて自分でサービスにサインアップすることができます。 ユーザーは、ユーザー名、メール アドレス、ID (ポイント カード番号など) を指定します。 パスワードなどの資格情報も指定します。 この IdP には、ユーザー識別子と資格情報の両方が格納されます。
  • ソーシャル ID プロバイダー。 ユーザーは、ソーシャル ネットワークをはじめとするパブリック ID プロバイダー (Facebook、Google、個人用 Microsoft アカウントなど) の ID を使用できます。
  • テナントの Microsoft Entra ID または Microsoft 365 ディレクトリを使います。 テナントはその独自の Microsoft Entra ID ディレクトリまたは Microsoft 365 ディレクトリを既に保有していて、そのディレクトリをソリューションにアクセスするための IdP として使うことを希望するかもしれません。 このアプローチは、ソリューションがマルチテナント Microsoft Entra アプリケーションとして構築されている場合に可能となります。
  • テナントの ID プロバイダーとのフェデレーション。 テナントには Microsoft Entra ID や Microsoft 365 ではない独自の IdP があり、あなたのソリューションとのフェデレーションを希望する場合があります。 フェデレーションによってシングル サインオン (SSO) エクスペリエンスが可能になり、テナントは、そのユーザーのライフサイクルとセキュリティ ポリシーをソリューションとは無関係に管理できます。

自分のテナントで複数の ID プロバイダーをサポートする必要があるかどうかを検討する必要があります。 たとえば、ローカル ID、ソーシャル ID、フェデレーション ID をすべて 1 つのテナント内でサポートしなければならない場合もあります。 これは企業で使用しているソリューションが、その社員と請負業者の両方を対象としている場合に一般的な要件です。 ソリューションへの社員のアクセスにはフェデレーションを使用する一方、フェデレーションされた IdP にアカウントを持たない請負業者やゲスト ユーザーにもアクセスを許可します。

認証情報とテナント認可情報を保存する

マルチテナント ソリューションでは、複数の種類の ID 情報をどこに格納するかを検討する必要があります。そうした情報の種類の例を次に示します。

  • ユーザーとサービス アカウントの詳細。たとえば、テナントで要求される名前などの情報が該当します。
  • ユーザーを安全に認証するために必要な情報。たとえば、多要素認証 (MFA) を提供するために必要な情報が該当します。
  • テナント固有の情報。たとえば、テナントのロールやアクセス許可が該当します。 この情報が認可に使用されます。

注意事項

認証プロセスを自前で構築することはお勧めしません。 最近の IdP は、アプリケーションのために、これらの認証サービスを提供しており、また、MFA や条件付きアクセスなど他の重要な機能も備えています。 独自 ID プロバイダーの構築は避けるべきです。 それは推奨されません。

ID 情報の保存については、次の選択肢を検討してください。

  • すべての ID 情報と認可情報を IdP ディレクトリに格納し、それを複数のテナント間で共有する。
  • ユーザーの資格情報は IdP ディレクトリに格納し、認可情報はアプリケーション層にテナント情報と一緒に格納する。

ユーザーに使用する ID の数を決める

マルチテナント ソリューションでは、1 つのユーザー ID またはワークロード ID に複数テナントのデータとアプリケーションへのアクセスを許可するのが一般的です。 このアプローチが実際のソリューションに必要かどうかを考え、 必要な場合は、次の点を考慮してください。

  • ユーザー ID は 1 人につき 1 つ作成すべきか、それともテナントとユーザーの組み合わせごとに別個の ID を作成すべきか。
    • 可能な限り、ID は 1 人につき 1 つ使用するのが理想です。 複数のユーザー アカウントを管理するのは、ソリューション ベンダーである皆さんにとっても、ユーザーにとっても難しくなります。 また、最近の IdP が脅威への対策として提供するインテリジェント保護の多くは、1 人のユーザーが 1 つのユーザー アカウントを保有することを前提としています。
    • ただし、1 人のユーザーに複数の異なる ID が必要になる場合もあります。 たとえば、仕事上の目的と私的な目的の両方にあなたのシステムを使用するユーザーは、そのアカウントを区別したいと考えるでしょう。 また、厳しい規制や地理的データ ストレージ要件が課せられているテナントのユーザーには、規制や法令に準拠するために複数の ID を所持することが求められる可能性があります。
  • テナントごとの ID を使用する場合、資格情報を複数回保存することは避けてください。 ユーザーの資格情報は、1 つの ID に対して保存する必要があります。ゲスト ID などの機能を使用して、複数テナントの ID レコードから同じユーザーの資格情報を参照するようにしてください。

テナント データへのアクセス権をユーザーに付与する

ユーザーをテナントにマッピングする方法を検討します。 たとえば、テナントへの初回アクセス時に入力する一意の招待コードをサインアップ プロセス中に使用することが考えられます。 ソリューションによっては、ユーザーのサインアップ メール アドレスのドメイン名をテナントの識別手段として使用できるでしょう。 または、ユーザーの ID レコードにある別の属性を使って、ユーザーをテナントにマッピングしてもいいでしょう。 そのマッピングは、基になる不変の一意識別子に基づき、テナントとユーザーの両方で保存する必要があります。

1 人のユーザーが 1 つのテナントのデータにしかアクセスしないように設計されているソリューションでは、次の事柄を考慮してください。

  • ユーザーがアクセスしているテナントを IdP がどのように検出するか。
  • IdP からアプリケーションにテナント識別子をどのように伝えるか。 一般に、テナント識別子クレームがトークンに追加されます。

1 人のユーザーに複数のテナントへのアクセス権を付与する必要がある場合、次の事柄を考慮する必要があります。

  • 複数のテナントへのアクセス権を持つユーザーをどのようにソリューションで識別し、アクセス許可を与えるか。 たとえば、トレーニング テナントの管理者であるユーザーに、運用テナントに対しては読み取り専用アクセス権を与えることはできるでしょうか。 または、組織内の部署ごとにテナントが分かれているとき、すべてのテナント間で一貫したユーザー ID を維持する必要はあるでしょうか。
  • ユーザーがどのようにしてテナントを切り替えるか。
  • ワークロード ID を使用する場合、アクセスする必要のあるテナントをワークロード ID でどのように指定するか。
  • テナント間の情報漏えいにつながるテナント固有の情報はユーザーの ID レコードに格納されるか。 たとえば、あるユーザーがソーシャル ID でサインアップし、2 つのテナントへのアクセスを許可されているとします。 テナント A で、ユーザーの ID が補足情報を使用してエンリッチされた場合、 このエンリッチされた情報へのアクセスをテナント B に許可すべきでしょうか。

ローカル ID またはソーシャル ID のユーザー サインアップ プロセス

一部のテナントでは、ユーザーが各自でサインアップしてソリューション内での ID を取得できることが求められます。 テナントの ID プロバイダーとのフェデレーションが不要である場合、セルフサービスのサインアップが必要になると考えられます。 セルフサインアップ プロセスが必要な場合は、次の点を考慮してください。

  • どの ID ソースのユーザーにサインアップを許可するか。 たとえば、ローカル ID の作成に加え、ソーシャル ID プロバイダーの使用もユーザーに許可するかどうかを検討します。
  • ローカル ID のみを許可する場合、特定の電子メール ドメインに限定するか。 たとえば、メール アドレスが @contoso.com のユーザーにのみサインアップを許可するようテナントで指定できるようにするかどうかを検討します。
  • サインイン プロセス中、各ローカル ID を一意に識別するために、どのようなユーザー プリンシパル名 (UPN) を使用するか。 たとえば、電子メール アドレス、ユーザー名、電話番号、ポイント カード番号は、いずれも UPN の候補として一般的です。 ただし、UPN は時間の経過に伴って変化する可能性があります。 アプリケーションの認可規則または監査ログで ID を参照するときは、ID の基になる不変の一意識別子を使用することをお勧めします。 Microsoft Entra ID には、不変の識別子であるオブジェクト ID (OID) が用意されています。
  • ユーザーがその UPN を検証する必要はあるか。 たとえば、ユーザーのメール アドレスまたは電話番号が UPN として使用されている場合、その情報が正確であることはどのように確認すればよいでしょうか。
  • テナント管理者がサインアップを承認する必要はあるか。
  • テナント固有のサインアップ エクスペリエンスまたは URL は必要か。 たとえば、ユーザーがテナントにサインアップするときにブランド化されたサインアップ エクスペリエンスを提供する必要があるかどうかを検討します。 サインアップ要求をインターセプトし、別途検証を実行したうえで続行する機能はテナントに必要でしょうか。

セルフ サインアップ ユーザーのテナント アクセス

ユーザーが各自でサインアップして ID を取得できるようにする場合、テナントへのアクセス権を付与するプロセスが必要です。 アクセス権付与プロセスは、サインアップ フローに組み込むか、ユーザーの情報 (メール アドレスなど) に基づいて自動化することが考えられます。 このプロセスについて計画を立てることが大切です。次の点を考慮してください。

  • 特定テナントへのアクセス権をユーザーに付与すべきかどうかの判断をサインアップ フローでどのように行うか。
  • テナントを利用しなくなったユーザーのアクセス権をソリューションで自動的に取り消す必要はあるか。 たとえば、ユーザーが組織を退社した場合、そのアクセス権をテナントから削除する手動または自動のプロセスを設ける必要はあるでしょうか。
  • テナントを利用できるユーザーとそのアクセス許可を監査するための手段をテナントに提供すべきか。

アカウント ライフサイクル管理の自動化

アカウントのオンボーディングとオフボーディングを自動的に行う一連の機能は、ソリューションの企業顧客が抱える一般的な要件です。 クロスドメイン ID 管理システム (SCIM) などのオープン プロトコルは、自動化のための業界標準のアプローチを提供します。 通常、この自動化されたプロセスには、ID レコードの作成と削除だけでなく、テナントのアクセス許可管理も含まれます。 自動化されたアカウント ライフサイクル管理をマルチテナント ソリューションに実装する際は、次の点を考慮してください。

  • 自動化されたライフサイクル プロセスを顧客がテナントごとに構成して管理する必要はあるか。 たとえば、あなたのアプリケーションで、ユーザーのオンボード時に、複数のテナント内に ID を作成する必要があるものの、テナントごとに一連のアクセス許可が異なる場合があります。
  • ローカル ユーザーを管理するのではなく、ユーザーの信頼できる情報源をテナントの管理下に置くため、SCIM を実装する必要はあるか、または、テナントのフェデレーションを提供できるか。

ユーザー認証プロセス

ユーザーがマルチテナント アプリケーションにサインインするとき、そのユーザーは ID システムによって認証されます。 認証プロセスを計画するときは、次の点を考慮する必要があります。

  • テナントが独自の多要素認証 (MFA) ポリシーを構成する必要はあるか。 たとえば、テナントが金融サービス業界のユーザーである場合、厳しい MFA ポリシーを実装する必要があります。一方、小規模のオンライン小売業者の場合、同じ要件は該当しないと考えられます。
  • テナントが独自の条件付きアクセス規則を構成する必要はあるか。 たとえば、各テナントが特定の地域からのサインイン試行をブロックするケースが考えられます。
  • 各テナントのサインイン プロセスをテナントがカスタマイズする必要はあるか。 たとえば、顧客のロゴを表示する必要があるかどうかを考えます。 または、各ユーザーについての情報 (ポイントカード番号など) を別のシステムから抽出し、ID プロバイダーに返してユーザー プロファイルに追加する必要はあるでしょうか。
  • ユーザーが他のユーザーを偽装する必要はあるか。 たとえば、サポート チームのメンバーは、他のユーザーが抱える問題を調査する際に、そのユーザーのアカウントを偽装します。実際にそのユーザーとして認証される必要はありません。
  • ユーザーがソリューションの API にアクセスする必要はあるか。 たとえば、ユーザーまたはサードパーティのアプリケーションは、ソリューションを拡張する際、認証フローを提供するユーザー インターフェイスを介さずに直接 API を呼び出す必要があるでしょう。

ワークロード ID

ほとんどのソリューションでは、ID といえば通常、ユーザーを表します。 一部のマルチテナント型システムでは、"サービス" や "アプリケーション" がアプリケーションのリソースにアクセスするために、"ワークロード ID" も使用されます。 たとえば、テナントは、いくつかの管理タスクを自動化するために、ソリューションに用意されている API にアクセスする場合があります。

ワークロード ID はユーザー ID と似ています。ただしワークロード ID では、異なる認証方法、たとえばキーや証明書が使用されるのが一般的です。 ワークロード ID では MFA は使用されません。 定期的なキーの交換、証明書の有効期限など、通常、他のセキュリティ コントロールが必要となります。

テナントがワークロード ID でマルチテナント ソリューションにアクセスできるようにしたければ、次の点を考慮する必要があります。

  • ワークロード ID をどのように各テナントで作成して管理するか。
  • ワークロード ID の要求の範囲をどのようにして、特定のテナントに限定するか。
  • 各テナントによって作成されるワークロード ID の数を制限する必要はあるか。
  • 各テナントのワークロード ID に対して条件付きアクセス制御を提供する必要はあるか。 たとえば、テナントは、特定のリージョン以外からのワークロード ID が認証されないよう制限したい場合があります。
  • ワークロード ID のセキュリティを確保するために、どのようなセキュリティ コントロールをテナントに提供するか。 たとえば、自動化されたキーのローリング、キーの有効期限、証明書の有効期限、サインイン リスクの監視はいずれも、ワークロード ID が悪用されるリスクを軽減するための手段です。

ID プロバイダーとのフェデレーションによるシングル サインオン (SSO)

既に独自のユーザー ディレクトリを所有しているテナントは、あなたのソリューションに、それらのディレクトリとの "フェデレーション" を期待する可能性があります。 フェデレーションを利用すれば、別個の ID を含んだディレクトリを別途管理しなくても、ソリューションは既存のディレクトリにある ID を使用することができます。

一部のテナントが独自の ID ポリシーを規定したいと考えている場合や、シングル サインオン (SSO) エクスペリエンスを実現したいと考えている場合、フェデレーションは特に重要です。

テナントがソリューションとフェデレーションすることを想定している場合は、次の点を考慮する必要があります。

  • テナントのフェデレーションを構成する手順はどのようなものか。 テナントが各自でフェデレーションを構成できるようにするのか、それとも、あなたのチームによる手動構成とメンテナンスが必要かを考えます。
  • どのフェデレーション プロトコルをサポートするか。
  • フェデレーションの構成ミスによって別のテナントにアクセス権を与えてしまうことを防ぐために、どのようなプロセスを設けるか。
  • 1 つのテナントの ID プロバイダーを、ソリューションの複数のテナントとフェデレーションさせる必要はあるか。 たとえば、トレーニングと運用の両方のテナントが顧客にある場合、その両方のテナントに同じ ID プロバイダーをフェデレーションさせる必要があるでしょう。

認可モデル

ソリューションにとって最も理にかなった認可モデルを決定します。 一般に、認可のアプローチには次の 2 つがあります。

  • ロールベースの認可。 ユーザーはロールに割り当てられます。 アプリケーションの一部の機能は、特定のロールに制限されます。 たとえば、管理者ロールのユーザーはすべての操作を実行できるのに対し、それよりも下位のロールのユーザーには、システム全体にわたるアクセス許可の一部のみが与えられます。
  • リソースベースの認可。 ソリューションには一連の個別のリソースが用意されており、それぞれに独自のアクセス許可のセットがあります。 あるリソースの管理者になっている特定のユーザーが、別のリソースにはアクセスできないこともあります。

これらのモデルは明確に区別されており、選択したアプローチによって実装が変わり、また実装できる認可ポリシーの複雑さも変わります。

詳細については、「ロールベースおよびリソースベースの承認」を参照してください。

エンタイトルメントとライセンス

ソリューションによっては、商用価格モデルとしてユーザー数によるライセンスを使用できます。 その場合、機能が異なるさまざまなレベルのユーザー ライセンスを提供することになります。 たとえば、あるライセンスを持つユーザーには、アプリケーションが備えている機能の一部のみ使用が許可されます。 特定のユーザーにそのライセンスに応じてアクセスが許可される機能は、"エンタイトルメント" と呼ばれることがあります。

エンタイトルメントの追跡と適用は認可と似ていますが、通常、ID システムによって管理されるのではなく、アプリケーション コードまたは専用のエンタイトルメント システムによって処理されます。

ID のスケールと認証のボリューム

マルチテナント ソリューションが増えるにつれて、ソリューションで処理すべきユーザーとサインイン要求の数が増えます。 次の点を考慮する必要があります。

  • 必要なユーザーの数に合わせてユーザー ディレクトリをスケーリングするか。
  • 認証プロセスは、想定される数のサインインとサインアップに対応しているか。
  • 認証システムで処理できないスパイクはあるか。 たとえば、太平洋標準時の午前 9 時に、米国西部 リージョンのすべてのユーザーが始業と共にソリューションにサインインすることで、サインイン要求が急増する可能性があります。 このような状況は、"ログイン ストーム" と呼ばれることがあります。
  • ソリューションの他の部分の負荷が上がることで、認証プロセスのパフォーマンスに影響が生じる可能性はあるか。 たとえば、認証プロセスでアプリケーション層の API を呼び出す必要がある場合、認証要求の数が増えることで、ソリューションの他の領域に問題が生じる可能性はあるでしょうか。
  • IdP が利用できなくなった場合はどうなるか。 IdP が利用できない間、処理を引き継いでビジネス継続性を提供するバックアップ認証サービスはあるでしょうか。

共同作成者

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

プリンシパルの作成者:

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

その他の共同作成者:

  • Jelle Druyts | FastTrack for Azure のプリンシパル カスタマー エンジニア
  • Sander van den Hoven | シニア パートナー テクノロジ ストラテジスト
  • Nick Ward | シニア クラウド ソリューション アーキテクト

次の手順

「マルチテナント ソリューションにおける ID のアーキテクチャに関するアプローチ」を参照してください。