マルチテナント認証を許可するアプリケーション

LOW

説明

サインインを容易にするための Microsoft Entra ID に登録されたアプリケーションは、シングルテナントまたはマルチテナント認証 (「サインインオーディエンス」としても知られる) のどちらかをリクエストできます。シングルテナント認証では同じテナント内のユーザーだけにアクセスが限定されます。一方、マルチテナント認証では、任意の Entra テナントのユーザーにアクセスが許可されます。このシングルテナントとマルチテナントアプリの違いは、セキュリティに影響を与える可能性があります。その影響を十分に認識せず、必要な予防措置を講じないまま、アプリケーションをマルチテナントとして設定してしまうと、セキュリティリスクが生じる可能性があります。

マルチテナントアプリのエクスポージャーは、いずれかのテナントの悪意のある Entra ユーザーがアプリケーションを検出してアクセスする可能性があるため、より高くなります。アプリケーションのコードがこの設定を考慮しない場合 (ユーザーのソーステナントを承認済みのテナントリストと照合しない、など)、不正アクセスにつながる可能性があります。脆弱なアプリとは、認証が正当であると見なし、追加のチェックを実行することなく、有効なトークンがあるというだけでアクセスを許可するアプリです。このタイプの脆弱性は、「認証 (AuthN) と認可 (AuthZ)」の欠陥の領域に分類されます。「責任共有モデル」では、Entra ID がユーザー認証を処理し、認可はアプリの責任になります。

Microsoft でさえ、「BingBang」ケーススタディで詳述されているように、2023 年 3 月にこの混乱の被害者となりました。この設定ミスはセキュリティエンジニアに悪用され、Bing 検索エンジンの管理ポータルを含めた複数の Microsoft アプリケーションが侵害されました。Microsoft は当該脆弱性を修正済みですが、同様の問題は貴社アプリケーションでも発生し得るため、必要に応じて確認と修正を行うことが重要です。

マルチテナントアプリでは、nOAuth 欠陥など、他の認証の混乱の影響も受けやすくなります。

特に所属組織がホストしているアプリケーションが、他の組織によるアクセスを意図している場合 (例: ソフトウェアベンダーとして、または組織間のコラボレーションのため)、あるいは同一組織内の別のテナントからのユーザーによるアクセスを意図している場合 (例: 子会社ごとに 1 つのテナント) は、マルチテナントアプリを使用する妥当なユースケースとなります。このようなアプリケーションは、追加の承認チェックを実施せずに認証の成功だけに依存している場合にのみ脆弱になります。 この露出インジケーター (IoE) は、アプリケーションがパブリックにする予定であるかどうかや、マルチテナント認証が意図的に有効にされたかどうかは判断できません。また、マルチテナントが本当に必要かどうかも判断できません。アプリケーションコードにアクセスできないので、必要な認証チェックが実装されているかどうかも検証できません。これらの理由で、この露出インジケーター (IoE) はすべてのマルチテナントアプリケーションに検出結果としてフラグを立てます。必ず個別にレビューしてください。確認後は、それらを無視できるものとしてマークできます。

ソリューション

所有者の支援を受けてアプリケーションを確認し、アプリのマルチテナントの性質が想定と一致していることを確認します。この設定が、シングルテナントアプリとマルチテナントアプリの違いを十分に認識した上で有効にされていることを確認します。アプリケーションが、自身が登録されているテナント以外の他のテナントのユーザーを受け入れられることを確認します。

アプリケーションがパブリックにするためのものである場合は、この露出インジケーター (IoE) で無視されるように指定することもできます。

アプリケーションにマルチテナント認証が必要でない場合、シングルテナントモードに戻すことができます。ただし、Entra ID は、サポートされているアカウントの種類に応じて異なる検証ルールをアプリに適用することに注意してください。そのため、他のパラメーターを調整しないまま、シングルテナントモードに必ずしも切り替えられるわけではありません。慎重に作業を進め、変更した場合の影響を注意深く確認してください。 対象ユーザーを更新するための Microsoft の手順に従うか、次の手順を実行できます。

  1. アプリケーションを所有する Entra ユーザーとして、またはアプリケーション管理者/クラウドアプリケーション管理者などの Entra ロールを持つ Entra ユーザーとして、Azure ポータル / Entra 管理センターに対して認証します (正確に必要な Entra アクセス許可は microsoft.directory/applications/audence/update)。
  2. [アプリの登録] メニューを開きます。
  3. アプリケーションを検索します (アプリ名または検出結果に表示されるオブジェクト ID を使用)。
  4. [概要] ページの [サポートされているアカウントの種類] セクションには、現在、[複数の組織] または [すべての Microsoft アカウントユーザー] が表示されているはずです。
  5. [認証] メニューをクリックし、指示に従ってアプリケーションを [シングルテナント] に切り替えます。

一方、アプリケーションがマルチテナント認証を必要とする場合は、受信した認証トークンに対する追加の承認チェック (クレーム検証) がコードに含まれていることを開発者に確認します。

  • 可能であれば、テナント ID クレームに基づいて、組織の子会社のテナントなど、指定された Entra テナントの事前定義リストに載っているユーザーからのトークンのみをアプリケーションが受け入れようにしてください。
  • 可能であれば、オブジェクト ID クレームに基づいて予め知っている特定のユーザーからのトークンを受け入れることをアプリケーションが考慮するようにもしてください。
  • アプリケーションは、Entra アプリロール、Entra グループ、または独自のデータストアなどさまざまな方法を使用してロールベースのアクセス制御 (RBAC) モデルを実装することができます。

これらのチェックが実装されていることを確認したら、またはアプリケーションがパブリックにするためのものである場合は、この露出インジケーター (IoE) で無視されるようにアプリケーションをマークできます。

注意: 条件付きアクセスポリシーは、同じテナント内のユーザーにのみ適用されます。その結果、他のテナントからのユーザーによるマルチテナントアプリケーションへのアクセスを制限できません。

さらに、Entra ID を使用するマルチテナントアプリケーションの認証の潜在的な設定ミスに対する Microsoft の公式ガイダンスに従うことを推奨します。このガイダンスには追加の具体的な推奨事項が含まれています。

最後に、Entra および Azure の管理者の意識を高め、Entra アプリ登録ページからまたは Azure App Service の作成でアプリケーションを作成する際に、シングルテナント設定とマルチテナント設定を賢明に選択できるようにします。

インジケーターの詳細

名前: マルチテナント認証を許可するアプリケーション

コード名: APPLICATION-ALLOWING-MULTI-TENANT-AUTHENTICATION

深刻度: Low

タイプ: Microsoft Entra ID Indicator of Exposure

MITRE ATT&CK 情報: