次の方法で共有

マルチテナント ソリューションにおける ID のアーキテクチャに関するアプローチ

ID システムは、ほぼすべてのマルチテナント ソリューションで必要となります。 この記事では、認証や承認など、ID の一般的なコンポーネントと、マルチテナント ソリューションでこれらのコンポーネントを適用する方法について説明します。

注意

マルチテナント ソリューションの ID システムの構築を開始する前に、マルチテナント ソリューション での ID のアーキテクチャに関する考慮事項を参照してください。

認証

認証は、ユーザーの ID を確立するプロセスです。 マルチテナント ソリューションを構築する場合は、認証プロセスのさまざまな側面に対するさまざまなアプローチを検討してください。

フェデレーション

外部 ID プロバイダー (IdP) とのフェデレーションが必要になる場合があります。 フェデレーションを使用して、次のシナリオを有効にすることができます。

  • ソーシャル ログイン。ユーザーは Google、Facebook、GitHub、または個人の Microsoft アカウントでサインインできます

  • テナント固有のディレクトリ。テナントは、複数の場所でアカウントを管理する必要がないように、アプリケーションを独自の IdP とフェデレーションできます。

詳細については、 フェデレーション ID パターンを参照してください。

テナント固有の IdP をサポートする場合は、アプリケーションでサポートされているサービスとプロトコルを明確にしてください。 たとえば、OpenID Connect プロトコルと Security Assertion Markup Language プロトコルをサポートするかどうか、またはフェデレーションを Microsoft Entra ID インスタンスに制限するかどうかを決定します。

IdP を実装する場合は、適用される可能性があるスケールと制限を検討してください。 たとえば、IdP は限られた数の他の IdP とのみフェデレーションできる場合があります。

また、上位 の製品レベルのお客様にのみ適用される機能としてフェデレーションを提供することも検討してください。

シングル サインオン

シングル サインオンを使用すると、ユーザーは各時点で再認証を求められることなく、アプリケーションをシームレスに切り替えることができます。

アプリケーションにアクセスしたユーザーは、そのアプリケーションによって IdP に誘導されます。 IdP は、既存のセッションを検出した場合、ユーザーがサインイン プロセスを操作する必要なく、新しいトークンを発行します。 フェデレーション ID モデルでは、ユーザーが複数のアプリケーションで 1 つの ID を使用できるようにすることで、シングル サインオンがサポートされます。

マルチテナント ソリューションでは、別の形式のシングル サインオンを有効にすることができます。 ユーザーが複数のテナント間でデータにアクセスする権限を持っている場合は、ユーザーが自分のコンテキストをあるテナントから別のテナントに変更するときに、シームレスなエクスペリエンスを提供することが必要になる場合があります。 ソリューションでテナント間のシームレスな移行をサポートする必要があるかどうかを検討します。 その場合は、IdP が特定のテナント要求でトークンを再発行する必要があるかどうかを検討してください。 たとえば、ユーザーが Azure portal にサインインすると、異なる Microsoft Entra ID ディレクトリを切り替えることができます。 この移行により、再認証がトリガーされ、新しく選択された Microsoft Entra ID インスタンスから新しいトークンが生成されます。

ログインのリスク評価

最近の ID プラットフォームは、サインイン プロセス中のリスク評価をサポートしています。 たとえば、ユーザーが通常とは異なる場所やデバイスからサインインした場合、認証システムは、サインイン要求の続行を許可する前に、多要素認証 (MFA) などの特別な ID チェックを課す必要があるでしょう。

認証プロセス中に適用すべきリスク ポリシーが、テナントによって異なるかどうかを考慮します。 たとえば、規制の厳しい業界にテナントがある場合、規制の厳しい環境で作業するテナントとは異なるリスク プロファイルと要件を持つ可能性があります。 または、より高い価格レベルのテナントが、サービスの下位レベルを購入するテナントよりも制限の厳しいサインイン ポリシーを指定できるようにすることもできます。

テナントごとに異なるリスク ポリシーをサポートする必要がある場合は、正しいポリシーを適用できるように、ユーザーがサインインしているテナントを認証システムで認識する必要があります。

ご利用の IdP にこれらの機能が備わっている場合は、IdP のネイティブのサインイン リスク評価機能を使用することを検討してください。 これらの機能は複雑であるため、独自に実装するとエラーの原因になります。

または、テナントの IdP にフェデレーションする場合は、リスクの高いサインイン軽減ポリシーを適用して、強制ポリシーと制御を制御できます。 たとえば、2 つの MFA チャレンジ (1 つはユーザーのホーム IdP から、もう 1 つは独自のもの) を要求すると、サインイン プロセスがより困難になる可能性があります。 フェデレーションがテナントの各 IdP と対話する方法と、それらが設定されているポリシーを理解していることを確認します。

偽装

偽装を使用すると、ユーザーは、そのユーザーの資格情報を使用せずに、別のユーザーの ID を想定できます。

偽装は一般に危険であり、実装と制御が困難な場合があります。 ただし、一部のシナリオでは、偽装が必要です。 たとえば、サービスとしてのソフトウェア (SaaS) 環境で運用している場合、ヘルプ デスクの担当者は、ユーザーがユーザーとしてサインインして問題のトラブルシューティングを行えるように、ユーザーの ID を想定する必要がある場合があります。

偽装を実装する場合は、その使用を監査する方法を検討してください。 アクションを実行したユーザーと偽装したユーザーの識別子の両方がログに含まれるようにします。

一部の ID プラットフォームでは、偽装が組み込み機能として、またはカスタム コードを使用してサポートされています。 たとえば、偽装されたユーザー ID のカスタム要求を Microsoft Entra External ID に追加 したり、発行されたトークンのサブジェクト識別子要求を置き換えたりすることができます。

認可

認可は、ユーザーに許可される操作を決定するプロセスです。

認可データはいくつかの場所に格納できます。格納場所の例を次に示します。

  • IdP 上での設定: たとえば、IdP として Microsoft Entra ID を使用する場合、アプリロール や グループ などの機能を利用して認可情報を格納できます。 そのうえでアプリケーションは、関連付けられているトークン クレームを使用して認可規則を適用できます。

  • アプリケーションで次の手順を実行します。 独自の承認ロジックを構築し、各ユーザーが実行できる操作に関する情報をデータベースまたは同様のストレージ システムに格納できます。 これによってロールベースまたはリソースレベルの認可を行う、きめ細かな制御を設計できます。

ほとんどのマルチテナント ソリューションでは、マルチテナント システムのベンダーではなく、顧客またはテナントがロールとアクセス許可の割り当てを管理します。

テナント ID とロールの情報をトークンに追加する

承認要求を処理するソリューションの部分を決定します。 特定のテナントからのデータへのアクセスをユーザーに許可するかどうかを評価します。

一般的には、ID システムでテナント ID クレームをトークンに埋め込む方法が用いられます。 アプリケーションは、この方法でクレームを検査することにより、ユーザーによって使用されているテナントが、そのユーザーにアクセスが許可されたテナントであることを確認できます。 ロールベースのセキュリティ モデルを使用する場合は、テナント内のユーザーのロールに関する情報を含むようにトークンを拡張できます。

ただし、1 人のユーザーが複数のテナントへのアクセスを許可されている場合は、サインイン プロセス中に使用する予定のテナントをユーザーが通知する方法が必要になる場合があります。 ユーザーがアクティブなテナントを選択すると、IdP は、そのテナントの正しいテナント識別子の要求とロールを含むトークンを発行できます。 加えて、ユーザーによるテナントの切り替え方法も検討する必要があり、テナントが切り替われば、新しいトークンの発行が必要となります。

アプリケーションベースの認可

別のアプローチとして、ID システムがテナントの識別子やロールに依存しないようにする方法があります。 ユーザーは資格情報またはフェデレーション関係を通じて識別され、トークンにはテナント識別子の要求は含まれません。 個別のリストまたはデータベースでは、各テナントへのアクセス権がユーザーに付与されているレコードが保持されます。 その後、アプリケーション層は、指定されたユーザーがそのリストに基づいて特定のテナントのデータにアクセスする権限を持っているかどうかを確認します。

Microsoft Entra ID または外部 ID を使用する

Microsoft Entra ID と外部 ID は、独自のマルチテナント ソリューション内で使用できるマネージド ID プラットフォームです。

多くのマルチテナント ソリューションは SaaS として動作します。 Microsoft Entra ID または外部 ID の使用の選択は、テナントまたは顧客ベースの定義方法によって一部異なります。

Von Bedeutung

Azure AD B2C では、この記事のシナリオの多くもサポートされています。 ただし、2025 年 5 月 1 日の時点で、新しい顧客向けに購入することはできなくなります。そのため、新しいソリューションにはお勧めしません。 詳細については、 Azure AD B2C に関する FAQ を参照してください。

回避すべきアンチパターン

独自の ID システムを構築または運用する

最近の ID プラットフォームは、構築が複雑化しています。 これには、さまざまなプロトコルと標準のサポートが必要であり、不適切な実装によってセキュリティの脆弱性が発生する可能性があります。 標準とプロトコルが変更されるため、攻撃を軽減し、最新のセキュリティ機能を組み込むために、ID システムを継続的に更新する必要があります。 また、ダウンタイムがソリューションの残りの部分に重大な影響を与える可能性があるため、ID システムの回復性を確保することも重要です。 ほとんどのシナリオでは、IdP の実装はビジネスに直接役立つわけではありませんが、マルチテナント サービスを実装するために必要です。 専門家が構築、運用、セキュリティで保護する特殊な ID システムを使用することをお勧めします。

独自の ID システムを運用する場合、パスワード ハッシュやその他の形式の資格情報を保管する必要があり、それが攻撃者にとって格好の標的になります。 パスワードのハッシュと塩分けでさえ、攻撃者がこれらの資格情報を侵害する可能性のある十分な計算能力を持っているため、保護が不十分であることがよくあります。

ID システムを実行する場合は、MFA またはワンタイム パスワード コードを生成して配布する必要があります。 SMS または電子メールでこれらのコードを送信するメカニズムが必要です。 また、標的型攻撃とブルート フォース攻撃の検出、サインイン試行の調整、監査ログの維持も担当します。

独自の ID システムを構築または管理する代わりに、事前構築済みのサービスまたはコンポーネントを使用することをお勧めします。 たとえば、Microsoft Entra ID や外部 ID などのマネージド ID プラットフォームを考えてみましょう。 これらのプラットフォームのベンダーは、インフラストラクチャの運用を担当し、通常は現在の ID および認証標準のサポートを確保します。

テナントの要件を考慮に入れなかった場合

テナントには、多くの場合、使用するソリューションで ID を管理する方法に関する強い優先順位があります。 たとえば、多くの企業のお客様は、シングル サインオンを有効にし、複数の資格情報セットの管理を回避するために、独自の IdP とのフェデレーションを必要とします。 他のテナントでは、サインイン プロセスに MFA または追加のセキュリティ対策が必要になる場合があります。 設計時にこれらの要件を考慮しない場合は、後で追加するのが難しい場合があります。

ID システムの設計を完了する前に、テナントの ID 要件を理解していることを確認してください。 特定の要件の詳細については、「 マルチテナント ソリューションでの ID のアーキテクチャに関する考慮事項」を参照してください。

ユーザーとテナントを結び付ける

ソリューションにおけるユーザーとテナントをどう定義するかを明確に検討することが大切です。 多くのシナリオでは、リレーションシップが複雑になる可能性があります。 たとえば、1 つのテナントに複数のユーザーが存在する場合もあれば、1 人のユーザーが複数のテナントに参加する場合もあるでしょう。

アプリケーションと要求内でテナント コンテキストを追跡するための明確なプロセスがあることを確認します。 一部のシナリオでは、このプロセスでは、すべてのアクセス トークンにテナント識別子を含め、各要求で検証する必要があります。 それ以外の場合は、テナントの承認情報がユーザー ID とは別に格納されます。 この方法では、各テナント内で特定の操作を実行できるユーザーを管理するために、より複雑な承認システムが必要です。

ユーザー ID にはマルチテナント ソリューション内に常にテナント コンテキストがあるため、ユーザーまたはトークンのテナント コンテキストの追跡は、任意の テナント モデル に適用できます。 1 つのテナントに対して独立したスタンプをデプロイする場合は、テナント コンテキストを追跡することをお勧めします。これは、将来、他の形式のマルチテナントに対してコードベースを証明します。

ロールとリソースの権限を混同する

ソリューションに適した承認モデルを選択することが重要です。 ロールベースのセキュリティは簡単に実装できますが、リソースベースの承認ではよりきめ細かな制御が提供されます。 テナントの要件を評価し、一部のユーザーがソリューションの特定の部分にのみアクセスすることを承認する必要があるかどうかを判断します。

監査ログの書き込みに失敗する

監査ログは、環境とユーザーがシステムを実装する方法を理解するための重要なツールです。 ID に関連したイベントをすべて監査することで、ご利用の ID システムが攻撃にさらされているかどうかを特定できる場合も少なくありません。自分のシステムがどう使用されているかを綿密に調べることもできます。 ID システム内で監査ログを書き込み、格納していることを確認します。 ソリューションの ID 監査ログを、調査用にテナントに提供すべきかどうかも考慮しましょう。

寄稿者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主な著者

その他の共同作成者:

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

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。