次の方法で共有

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

  • [アーティクル]

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

注意

マルチテナント ソリューションの ID システム構築に着手する前に、重要な要件と必要な決定事項を「マルチテナント ソリューションにおける ID のアーキテクチャに関する考慮事項」で確認しておいてください。

認証

認証は、ユーザーの ID が確立されるプロセスです。 マルチテナント ソリューションを構築する際は、認証プロセスのいくつかのポイントに関して特殊な考慮事項とアプローチがあります。

フェデレーション

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

  • ソーシャル ログイン。たとえば、Google、Facebook、GitHub、個人用 Microsoft アカウントを使用してユーザーがログインできるようにします。
  • テナント固有のディレクトリ。たとえば、アプリケーションとテナント固有の ID プロバイダーとの連携を有効にすれば、複数の場所のアカウントを管理する必要はありません。

フェデレーション全般の情報については、「フェデレーション ID パターン」を参照してください。

テナント固有の ID プロバイダーをサポートする場合は、サポートすべきサービスとプロトコルを明確にしておいてください。 たとえば、OpenID Connect プロトコルと Security Assertion Markup Language (SAML) プロトコルはサポートしますか? それとも、サポートするのは、Microsoft Entra インスタンスとのフェデレーションのみでしょうか。

いずれかの ID プロバイダーを導入するときは、適用するスケールと制限を考慮してください。 たとえば、Azure Active Directory (Azure AD) B2C を独自の ID プロバイダーとして使用する場合、特定の種類のテナント ID プロバイダーと連携するためにはカスタム ポリシーのデプロイが必要となります。 Azure AD B2C では、デプロイできる カスタム ポリシーの数に上限 があるため、連携できるテナント固有の ID プロバイダーの数が制限される場合があります。

特定の 製品レベルを超える顧客にのみ適用される機能としてフェデレーションを検討することもできます。

シングル サイン オン

シングル サインオン エクスペリエンスを使用すると、ユーザーはアプリケーションをシームレスに切り替えることができ、各ポイントで再認証を求められることがありません。

アプリケーションにアクセスしたユーザーは、そのアプリケーションによって IdP に誘導されます。 既存のセッションの存在が確認された場合、IdP はユーザーにログイン プロセスとの対話を要求せずに、新しいトークンを発行します。 フェデレーション ID モデルは、ユーザーが 1 つの ID を複数のアプリケーションに使用できるシングル サインオン エクスペリエンスをサポートします。

マルチテナント ソリューションでは、さらに別の形態のシングル サインオンを実現することもできます。 複数テナントのデータの使用がユーザーに認可されている場合、ユーザーのコンテキストが別のテナントに切り替わったときにシームレスなエクスペリエンスを提供することが必要でしょう。 シームレスなテナント切り替えをサポートする必要があるかどうか、またその必要がある場合、ID プロバイダーから特定のテナント クレームを含んだトークンを再発行する必要があるかどうかを検討してください。 たとえば、Azure portal にサインインしたユーザーが別の Microsoft Entra ディレクトリに切り替えることができる場合、それによって再認証が引き起こされ、新しく選択された Microsoft Entra インスタンスからトークンが再発行されます。

サインインのリスク評価

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

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

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

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

または、テナント独自の ID プロバイダーと連携すれば、危険なサインインに対してテナント独自の軽減ポリシーを適用することができ、適用すべきポリシーとコントロールもテナントで制御することができます。 ただし、2 つの MFA チャレンジ (ユーザーのホーム ID プロバイダーのものと独自のもの) を課すなど、不要な負担を意図せずユーザーに追加することは避けてください。 各テナントの ID プロバイダーとのフェデレーションに伴う対話および適用されるポリシーはしっかり理解しておく必要があります。

偽装

ユーザーは偽装を通じて、別のユーザーの ID を装うことができます。そのユーザーの資格情報を使用する必要はありません。

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

偽装を導入する場合は、その使用を監査する方法を検討してください。 実際に操作を行ったユーザーと偽装されたユーザー ID の両方が必ずログに記録されるようにします。

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

Authorization

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

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

  • ID プロバイダー内。 たとえば、Microsoft Entra ID を ID プロバイダーとして使用する場合は、 アプリ ロール や グループ などの機能を使用して認可情報を格納できます。 そのうえでアプリケーションは、関連付けられているトークン クレームを使用して認可規則を適用できます。
  • アプリケーションで、 独自の認可ロジックを作成したうえで、データベースや同様のストレージ システム内で各ユーザーが実行できる操作についての情報を格納できます。 これによってロールベースまたはリソースレベルの認可を行う、きめ細かな制御を設計できます。

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

詳細については、「アプリケーション ロール」を参照してください。

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

ソリューションのどの部分で認可要求を実行すべきかを、ユーザーが特定のテナントのデータを使用できるかどうかの判断も含め検討します。

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

ただし、1 人のユーザーが複数のテナントへのアクセスを許可されている場合は、どのテナントが操作対象であるかを、ログイン プロセス中に知らせる手段がユーザーに必要となります。 そこでアクティブなテナントが選択されれば、IdP は、発行するトークン内に適切なテナント ID クレームとそのテナントのロールを追加できます。 加えて、ユーザーによるテナントの切り替え方法も検討する必要があり、テナントが切り替われば、新しいトークンの発行が必要となります。

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

別のアプローチとして、テナントの ID やロールを ID システム以外で管理する方法もあります。 ユーザーはその資格情報またはフェデレーション関係を使用して識別され、トークンには、テナント ID クレームは追加されません。 どのユーザーに各テナントへのアクセスが許可されているかは、別個のリストやデータベースに格納されます。 そのうえで、アプリケーション層がそのリストを検索することにより、特定のテナントのデータに対するアクセスを特定のユーザーに許可すべきかどうかが確認されます。

Microsoft Entra ID または Azure AD B2C を使用する

Microsoft では、Microsoft Entra ID、Microsoft Entra External ID、Azure AD B2C を提供しています。これらは独自のマルチテナント ソリューション内で使用できるマネージド ID プラットフォームです。

マルチテナント ソリューションは、その多くが SaaS (サービスとしてのソフトウェア) です。 Microsoft Entra ID、Microsoft Entra External ID、Azure AD B2C のうちどれを使用するかは、テナントまたは顧客ベースをどのように定義するかによってある程度異なります。

  • テナントまたは顧客が組織である場合、Office 365、Microsoft Teams などのサービスやその独自の Azure 環境に以前から Microsoft Entra ID が使用されている可能性があります。 独自の Microsoft Entra ディレクトリに マルチテナント アプリケーション を作成することで、他の Microsoft Entra ディレクトリからソリューションを利用できるようになります。 自分のソリューションを Azure Marketplace に登録して、Microsoft Entra ID を使用する組織が簡単に利用できるようにすることも可能です。
  • テナントまたは顧客が Microsoft Entra ID を使用していない場合、または組織ではなく個人である場合は、Microsoft Entra External ID または Azure AD B2C の使用を検討してください。 Microsoft Entra External ID と Azure AD B2C のどちらにも、ユーザーのサインアップとサインインの方法を制御する一連の機能が用意されています。 たとえば、ソリューションへのアクセスを招待済みのユーザーに限定したり、セルフサービス サインアップに対応したりできます。 ID プラットフォームに対するユーザーの対話方法を詳細に制御するには、Azure AD B2C の カスタム ポリシー を使用します。 カスタム ブランドを使用できるほか、 Azure AD B2C と独自所有の Microsoft Entra テナントとの間にフェデレーションを設定することで、自社のスタッフにサインインを提供することもできます。 Azure AD B2C は、 他の ID プロバイダーとのフェデレーションにも対応しています。
  • 中には、上記の両方の状況を意図したマルチテナント ソリューションもあります。 Microsoft Entra テナントを独自に所有するテナントと、そうでないテナントが混在するケースです。 このシナリオにも Azure AD B2C を使用でき、 カスタム ポリシーを使用することで、テナントの Microsoft Entra ディレクトリからユーザーをサインインさせることができます。 ただし、カスタム ポリシーを使用してテナント間のフェデレーションを確立する場合は、1 つの Azure AD B2C ディレクトリで使用できる カスタム ポリシー数の上限に注意 してください。

詳細については、「マルチテナント アーキテクチャでの Azure Active Directory B2C の使用に関する考慮事項」を参照してください。

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

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

最近の ID プラットフォームは、構築が複雑化しています。 サポートすべきプロトコルと標準が多岐にわたり、プロトコルが適切に実装されずにセキュリティ上の脆弱性につながるリスクが高くなります。 また、標準やプロトコルは変化するものなので、攻撃を緩和したり最新のセキュリティ機能をサポートしたりするために、自前の ID システムを絶えず更新しなければなりません。 ダウンタイムは他のソリューションに深刻な影響をもたらす可能性があるため、ID システムの回復性を確保することも重要になります。 しかも、ほとんどの場合、ID プロバイダーの実装は、マルチテナント サービスの実装に必要な要素というだけで、企業にとってそれ以上のメリットはありません。 それよりも、エキスパートによって構築され、運用され、そしてセキュリティが確保される専用の ID システムを使用した方が賢明です。

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

ID システムを運用するとなれば、MFA やワンタイム パスワード (OTP) コードの生成と配布も自前で行う必要があります。 これらの要件は、SMS やメールでコードを配布するためのメカニズムが必要になることを意味します。 さらに、標的型攻撃とブルート フォース攻撃の検出、サインイン試行のスロットル、監査なども担う必要があります。

独自の ID システムを構築、運用するのではなく、市販のサービスまたはコンポーネントを使用することをお勧めします。 たとえば、マネージド ID プラットフォームである Microsoft Entra ID や Azure AD B2C の使用を検討してください。 マネージド ID プラットフォームのインフラストラクチャは、そのプラットフォームのベンダーが運用を担当し、通常、ID と認証に関する最新の標準をサポートしています。

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

テナントは多くの場合、自分たちが使うソリューションの ID 管理の在り方について、はっきりとした意見を持っています。 たとえば、多くの企業顧客は、シングル サインオン エクスペリエンスを実現し、複数の資格情報を管理する手間をなくすために、その独自の ID プロバイダーとのフェデレーションを必要としています。 多要素認証など、サインイン プロセス周りの保護形態を必要とするテナントもあるでしょう。 これらの要件に沿った設計になっていない場合、後から変更するのは難しい場合があります。

ID システムの設計について最終決定を行う前に、テナントの ID 要件を確実に把握しておいてください。 一般的に見られる具体的な要件については、「マルチテナント ソリューションにおける ID のアーキテクチャに関する考慮事項」を参照してください。

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

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

アプリケーションや要求の中で、テナントのコンテキストを追跡するための明確なプロセスを確保してください。 状況によっては、このプロセスですべてのアクセス トークンにテナント ID を追加し、各要求のテナント ID を自分で検証する必要があります。 また、テナントの認可情報をユーザー ID とは別に保管しておき、どのテナントに対し、どのユーザーがどの操作を実行できるかを、より複雑な認可システムを使用して管理する状況もあります。

ユーザーまたはトークンのテナント コンテキストを追跡することは、あらゆる テナント モデルに適用されます。マルチテナント ソリューションでは、ユーザー ID に常にテナント コンテキストが伴うからです。 また、1 つのテナントに対して独立したスタンプをデプロイする場合であっても、テナントのコンテキストを追跡することは有効な手法です。コードベースを将来的に他の形態のマルチテナント機能に対応させることにもつながります。

ロールとリソースの認可を結び付ける

自分のソリューションに対して適切な認可モデルを選ぶことが大切です。 ロール ベース セキュリティは実装しやすいアプローチですが、きめ細かな制御という点では、リソースベースの認可の方に分があります。 テナントの要件を考慮すると共に、そのテナントでソリューションの特定の部分へのアクセスを一部のユーザーに限定して認可する必要があるかどうかを考慮してください。

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

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

共同作成者

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

プリンシパルの作成者:

その他の共同作成者:

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

次の手順

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