次の方法で共有

条件付きアクセス: ユーザー、グループ、ワークロード ID

  • [アーティクル]

条件付きアクセス ポリシーには、決定プロセスのシグナルの 1 つとしてユーザー、グループ、ワークロード ID のいずれかの割り当てが含まれている必要があります。 これらの ID は条件付きアクセス ポリシーに含めることもポリシーから除外することもできます。 すべてのポリシーが Microsoft Entra ID によって評価され、すべての要件が満たされていることを確認したうえで、アクセスが許可されます。

ユーザーを含める

このユーザーの一覧には、通常、組織が条件付きアクセス ポリシーの対象としているすべてのユーザーが含まれます。

条件付きアクセス ポリシーの作成時には、含めるために以下のオプションを使用できます。

  • なし
    • どのユーザーも選択されていません
  • すべてのユーザー
    • ディレクトリ内に存在するすべてのユーザー (B2B ゲストを含む)。
  • ユーザーとグループを選択
    • ゲストまたは外部ユーザー
      • この選択では、特定のゲスト ユーザーまたは外部ユーザーの種類と、それらの種類のユーザーを含む特定のテナントを、条件付きアクセス ポリシーの対象とするために使用できるいくつかの選択肢を示します。 選択できるゲスト ユーザーまたは外部ユーザーにはいくつか種類があり、複数の選択を行うことができます。
        • B2B コラボレーション ゲスト ユーザー
        • B2B コラボレーション メンバー ユーザー
        • B2B 直接接続ユーザー
        • ローカル ゲスト ユーザー (たとえば、ユーザーの種類の属性がゲストに設定されているホーム テナントに属するすべてのユーザー)
        • サービス プロバイダー ユーザー (クラウド ソリューション プロバイダー (CSP) など)
        • 他の外部ユーザー、または他のユーザーの種類の選択で表現されないユーザー
      • 選択したユーザーの種類に対して 1 つまたは複数のテナントを指定することも、すべてのテナントを指定することもできます。
    • ディレクトリ ロール
      • 管理者は、ポリシー割り当てを決定するために使用される特定の組み込みディレクトリ ロールを選択できます。 たとえば、組織で、特権ロールをアクティブに割り当てられるユーザーに対し、より制限の厳しいポリシーを作成する場合があります。 管理単位スコープのロールやカスタム ロールなど、その他のロールの種類はサポートされていません。
    • ユーザーとグループ
      • 特定のユーザーのセットを対象にできます。 たとえば組織で人事部アプリがクラウド アプリとして選択されている場合は、人事部のすべてのメンバーを含むグループを選択できます。 Microsoft Entra ID 内の任意の種類のユーザー グループを指定できます。これには、動的なグループや、割り当て済みのセキュリティ グループおよび配布グループが含まれます。 ポリシーは、入れ子になったユーザーおよびグループに適用されます。

重要

条件付きアクセス ポリシーに含めるユーザーとグループを選択する際には、条件付きアクセス ポリシーに直接追加できるユーザーの数に制限があります。 条件付きアクセス ポリシーに直接追加する必要があるユーザーの数が多い場合は、それらのユーザーを 1 つのグループに配置し、そのグループを条件付きアクセス ポリシーに割り当てることをお勧めします。

ユーザーまたはグループが 2048 を超えるグループのメンバーである場合、そのアクセスはブロックされる可能性があります。 この制限は、直接と入れ子の両方のグループ メンバーシップに適用されます。

警告

条件付きアクセス ポリシーは、管理単位にスコープ指定されているディレクトリ ロール、または (カスタム ロール経由などで) オブジェクトに直接スコープ指定されているディレクトリ ロールが割り当てられているユーザーをサポートしません。

Note

B2B 直接接続外部ユーザーにポリシーを対象とする場合、これらのポリシーは、B2B 直接接続の対象となる Teams または SharePoint Online にアクセスする B2B コラボレーション ユーザーにも適用されます。 B2B コラボレーション外部ユーザーを対象とするポリシーにも同じことが適用されます。つまり、Teams 共有チャネルにアクセスするユーザーには、テナントにゲスト ユーザーが存在する場合にも B2B コラボレーション ポリシーが適用されます。

ユーザーを除外する

組織がユーザーまたはグループの追加と除外の両方を実行すると、ユーザーまたはグループがポリシーから除外されます。 除外アクションは、ポリシー内の追加アクションをオーバーライドします。 除外は一般的に、緊急アクセス アカウントや非常用アカウントのために使用されます。 緊急アクセス アカウントとそれが重要である理由の詳細については、以下の記事を参照してください。

条件付きアクセス ポリシーの作成時には、除外するために以下のオプションを使用できます。

  • ゲストまたは外部ユーザー
    • この選択では、特定のゲスト ユーザーまたは外部ユーザーの種類と、それらの種類のユーザーを含む特定のテナントを、条件付きアクセス ポリシーの対象とするために使用できるいくつかの選択肢を示します。 選択できるゲスト ユーザーまたは外部ユーザーにはいくつか種類があり、複数の選択を行うことができます。
      • B2B コラボレーション ゲスト ユーザー
      • B2B コラボレーション メンバー ユーザー
      • B2B 直接接続ユーザー
      • ローカル ゲスト ユーザー (たとえば、ユーザーの種類の属性がゲストに設定されているホーム テナントに属するすべてのユーザー)
      • サービス プロバイダー ユーザー (クラウド ソリューション プロバイダー (CSP) など)
      • 他の外部ユーザー、または他のユーザーの種類の選択で表現されないユーザー
    • 選択したユーザーの種類に対して 1 つまたは複数のテナントを指定することも、すべてのテナントを指定することもできます。
  • ディレクトリ ロール
  • ユーザーとグループ
    • 特定のユーザーのセットを対象にできます。 たとえば組織で人事部アプリがクラウド アプリとして選択されている場合は、人事部のすべてのメンバーを含むグループを選択できます。 Microsoft Entra ID 内の任意の種類のグループを指定できます。これには、動的なグループや、割り当て済みのセキュリティ グループおよび配布グループが含まれます。 ポリシーは、入れ子になったユーザーおよびグループに適用されます。

管理者のロックアウトを防ぐ

管理者のロックアウトを防ぐため、すべてのユーザーとすべてのアプリに適用されるポリシーを作成すると、次の警告が表示されます。

自分自身をロックアウトしないでください。 まずは少数のユーザーにポリシーを適用して、想定どおりに動作するかどうかを確認することをお勧めします。 また、このポリシーから少なくとも 1 人の管理者を除外することをお勧めします。 こうすることで、アクセス権を保持し、変更が必要な場合にポリシーを更新できます。 影響を受けるユーザーとアプリを確認してください。

既定では、ポリシーに現在のユーザーをポリシーから除外するオプションが用意されていますが、次の図に示すように、管理者はオーバーライドできます。

警告。自分自身をロックアウトしないでください。

Azure portal からロックアウトされた場合は、「ロックアウトされた場合はどのように対処すればよいですか」参照してください。

外部パートナー アクセス

外部ユーザーを対象とする条件付きアクセス ポリシーは、詳細な委任された管理者特権など、サービス プロバイダーのアクセスを妨げる可能性があります (「詳細な委任された管理者特権 (GDAP) の概要」)。 サービス プロバイダー テナントを対象とするポリシーの場合は、「ゲスト ユーザーまたは外部ユーザー」の選択オプションで選択できる外部ユーザーの種類であるサービス プロバイダー ユーザーを使用します。

ワークロード ID

ワークロード ID とは、アプリケーションまたはサービス プリンシパルが (場合によってはユーザーのコンテキストにある) リソースにアクセスすることを可能にする ID です。 条件付きアクセス ポリシーは、テナントに登録されているシングル テナント サービス プリンシパルに適用できます。 サード パーティの SaaS およびマルチテナント アプリは、対象外です。 マネージド ID は、ポリシーの対象にはなりません。

組織は、特定のワークロード ID を対象として、ポリシーに含めることもポリシーから除外することもできます。

詳細については、「ワークロード ID 用の条件付きアクセス」を参照してください。

次のステップ