条件付きアクセスを使用してMicrosoft Teamsデバイスのデバイス コード フローを制限する

デバイス コード フローを使用すると、ユーザーはブラウザーや豊富な入力エクスペリエンスを持たないデバイスにサインインできます。 一部のMicrosoft Teamsデバイスは、初回登録、再プロビジョニング、および一部の再認証シナリオでデバイス コード フローを使用します。

デバイス コード フローは、リスクの高い認証フローでもあります。 攻撃者はフローを開始し、ユーザーにコードを送信し、正当なMicrosoftサインイン ページでそのコードを入力するようユーザーに依頼することができます。 サインイン ページは実際のページであるため、この攻撃はユーザーが認識するのが難しくなる可能性があります。

Microsoft は、可能な限りデバイス コード フローをブロックすることを推奨しています。 組織でデバイス コード フローを必要とする Teams デバイスを使用している場合は、例外のスコープを特定の Teams デバイス リソース アカウントに設定し、条件付きアクセス ポリシーから Device Registration Service リソースを除外します。

このガイダンスを使用する必要があるユーザー

お客様の組織が次のいずれかに該当する場合は、この記事を参照してください:

• Teams Rooms、Teams Android デバイス、共有 Teams デバイス、またはデバイス コード フローを必要とするその他の Teams デバイス エクスペリエンスを使用します。
• 条件付きアクセスを使用してデバイス コード フローを制限したいと考えています。
• テナント全体のデバイス コード フローの露出を減らしながら、Teams デバイスの登録を機能させ続ける必要があります。

この記事では、Teams デバイスのシナリオについて説明します。 組織で、Azure CLIや開発者のコマンド ライン ツールなどの他のツールにデバイス コード フローを使用している場合は、ブロック ポリシーを適用する前に、この記事の追加のガイダンスを確認してください。

始める前の準備

必要なもの:

• 条件付きアクセス管理者やセキュリティ管理者など、条件付きアクセスを管理できるロール。
• 対象ユーザーに対する Microsoft Entra ID P1 以上のライセンス。 詳細については、「 条件付きアクセス ライセンスの要件」を参照してください。
• 会議室アカウントや共有デバイス アカウントなどの Teams デバイス リソース アカウントの一覧。
• Microsoft Entraサインイン ログへのアクセス。
• 条件付きアクセス ポリシーから除外される緊急アクセス アカウント。 詳細については、「Microsoft Entra ID の緊急アクセス アカウントの管理」<を参照>。

レポート専用モードから開始します。 ポリシーを有効にする前に、想定される Teams デバイスの動作を検証します。

推奨される方法

この記事では、2 つの階層化された例外を含む既定のブロック アプローチを使用します。

• デバイス コード フローを必要とする Teams デバイス リソース アカウントを含む永続的なセキュリティ グループ。
• デバイス登録サービス リソースの除外。そのため、デバイス コード フローを介したデバイス登録はポリシーによってブロックされません。

ポリシーを段階的にロールアウトします。

1. サインイン ログでのデバイス コード フローの使用状況のインベントリ。

2. 例外グループを作成します。

   • Teams デバイスに割り当てられたリソース アカウントを含む永続的な Teams デバイス例外グループ。
   • Teams 以外のデバイス コード フロー シナリオを承認している場合は、永続的に承認された Teams 以外のグループ。

3. デバイス コード フローをブロックし、それらのグループを除外し、Device Registration Service リソースを除外する条件付きアクセス ポリシーを作成します。

4. 選択したアカウントと Teams デバイスをレポート専用モードで使用して、ポリシーをパイロットします。

5. レポートのみの結果とサインイン ログを確認します。

6. ポリシーを有効にします。

7. デバイスが展開されると、新しい Teams デバイス リソース アカウントを例外グループに追加します。

8. ブロックされたサインインと例外グループのメンバーシップを監視します。

Teams デバイスには、初期サインインと、パスワードの変更や条件付きアクセス ポリシーの変更などの再認証シナリオの両方にデバイス コード フローが必要です。 Teams デバイス リソース アカウントの例外は永続的であり、タイム ボックス化されません。 パスワードレス認証を使用する Teams リソース アカウントは、再認証要件の例外です。最初のプロビジョニング時にのみデバイス コード フローが必要です。 再プロビジョニングと回復のシナリオがブロックされないように、これらのアカウントを永続的な例外グループに保持します。

例外はアカウント スコープです。 例外のスコープを 1 つのリソースまたはシナリオに限定する方法はありません。 例外の間、除外されたアカウントは、ポリシーのスコープ内の任意のアプリまたはリソースに対してデバイス コード フローを使用できます。 例外メンバーシップは、正規の Teams デバイス リソース アカウント、監視対象、所有者承認アカウントに制限します。

ユーザーの除外

条件付きアクセス ポリシーは強力なツールです。 ポリシーから次のアカウントを除外することをお勧めします。

• ポリシー構成の誤りによるロックアウトを防ぐための緊急アクセスアカウントまたはブレークグラスアカウント。 すべての管理者がロックアウトされる可能性が低いシナリオでは、緊急アクセス管理者アカウントを使用してサインインし、アクセスを回復できます。
  • 詳細は、「Microsoft Entra ID で緊急アクセス用アカウントの管理」の記事を参照してください。
• サービス アカウント と サービス プリンシパル (Microsoft Entra Connect 同期アカウントなど)。 サービス アカウントは、特定のユーザーに関連付けられていない非対話型アカウントです。 通常、アプリケーションへのプログラムによるアクセスを許可するためにバックエンド サービスによって使用されますが、管理目的でシステムにサインインするためにも使用されます。 サービス プリンシパルによって行われた呼び出しは、ユーザーを対象とする条件付きアクセス ポリシーによってブロックされません。 ワークロード ID の条件付きアクセスを使用して、サービス プリンシパルを対象とするポリシーを定義します。
  • 組織がスクリプトまたはコードでこれらのアカウントを使用している場合は、 それらをマネージド ID に置き換えます。

条件付きアクセス ポリシーを作成する

既定でデバイス コード フローをブロックするポリシーを 1 つ作成します。

1. Microsoft Entra 管理センターに、少なくとも条件付きアクセス管理者としてサインインします。
2. Entra ID>Conditional Access>Policies に移動します。
3. [新しいポリシー] を選択します。
4. ポリシーの名前を設定してください。 ポリシーの名前にわかりやすい標準を作成します。
5. [割り当て] で、 [ユーザーまたはワークロード ID] を選択します。
   1. [ 含める] で、ポリシーのスコープに含めるユーザーを選択します (すべてのユーザー が推奨されます)。
   2. [除外] で、次のようにします。
      • ユーザーとグループ を選択し、組織の緊急アクセス アカウントまたはブレークグラス アカウントと、承認済みのデバイス コード フローの例外グループを選択します。 この除外リストを定期的に監査します。
6. [ ターゲット リソース>リソース (以前のクラウド アプリ):
   1. [ 含める] で、組織がシナリオのより狭いリソース スコープを検証しない限り、[ すべてのリソース ( 以前の "すべてのクラウド アプリ" ) を選択します。
   2. [ 除外] で、[ 除外するクラウド アプリの選択 ] を選択し、 デバイス登録サービスを追加します。 この除外は、デバイス コード フローを介したデバイス登録がポリシーによってブロックされないようにする必要があります。 詳細については、「 Device Registration Service リソースに対する認証フロー ポリシーの適用」を参照してください。
7. [ 条件>認証フロー] で、[ 構成] を [はい] に設定します。
   1. [デバイス コード フロー] を選択します。
   2. 完了を選択します。
8. [ アクセス制御>許可] で、[ アクセスのブロック] を選択します。
   • [選択]
9. 設定を確認し、 [ポリシーの有効化] を [レポート専用] に設定します。
10. [作成] を選択して、ポリシーを有効化します。

ポリシーの影響モードまたはレポート専用モードを使用して設定を確認したら、[ポリシーの有効化] トグルを [レポートのみ] から [オン] に移動します。

Teams デバイス リソース アカウントの例外を管理する

デバイスが展開されると、永続的な例外グループに Teams デバイス リソース アカウントを追加します。 デバイスがインベントリから削除されるか、リソース アカウントが使用されなくなった場合にのみ、アカウントを削除します。

1. デバイスに割り当てられている Teams デバイス リソース アカウントを特定します。
2. 永続的な Teams デバイス例外グループにリソース アカウントを追加します。
3. 所有者、デバイス、および監査用の変更またはチケット ID を記録します。
4. デバイス コード フローを使用して Teams デバイスを登録または再プロビジョニングします。
5. デバイスがプロビジョニングを完了し、想定どおりにサインインすることを確認します。

Teams デバイスをインベントリから削除するには:

1. 例外グループからリソース アカウントを削除します。
2. リソース アカウントを無効または削除します。
3. 廃止を記録します。

適用前に検証する

ポリシーを有効にする前に、レポートのみの結果とサインイン ログを使用して、次の内容を確認します。

• Teams デバイスの登録は予想どおり成功します。
• リソース アカウントの例外が発生しても、登録はデバイス コード フロー ポリシーによってブロックされません。
• デバイス登録サービスはポリシーから除外されます。
• Teams デバイスは、パスワードの変更や条件付きアクセス ポリシーの変更などの再認証シナリオを含め、登録後も引き続きサインインします。
• 承認された Teams 以外のデバイス コード フロー シナリオは、明示的な例外グループによって表されます。
• 不明または不当なデバイス コード フローの使用がブロックされます。
• 緊急アクセスアカウントは除外されたままです。

ロールアウト前にアクティブなデバイス コード フローの使用状況をインベントリする場合は、認証プロトコル = デバイス コード フロー を使用します。 後のサインインまたはトークン更新がまだ以前 のデバイス コード フロー セッションに関連付けられているかどうかを理解する必要がある場合は、元の転送方法 = デバイス コード フローを使用します。

デバイス コード フローで開始されたセッションは、現在のサインイン イベントに認証プロトコルとしてデバイス コード フローが表示されない場合でも、後のトークン更新時にプロトコル追跡を維持できます。 詳細については、「 プロトコルの追跡」を参照してください。

Troubleshooting

Teams デバイスが予期せずブロックされる

リソース アカウントが例外グループ内にあり、デバイス登録サービスがポリシーから除外されている場合は、条件付きアクセス ポリシーによって Teams デバイスをブロックしないでください。

Teams デバイスが予期せずブロックされた場合:

1. リソース アカウントが永続的な例外グループに含まれているかどうかを確認します。
2. デバイス登録サービスがポリシーの ターゲット リソース から除外されていることを確認します。
3. サインイン ログを確認します。 元の転送方法にデバイス コード フローが表示されている場合、現在の認証プロトコル値がデバイス コード フローでない場合でも、セッションは以前の認証からプロトコル追跡される可能性があります。

これらのチェックの後もデバイスがブロックされている場合は、サポート チケットを開いて調査します。

個人用 Teams デバイスにはデバイス コード フローが必要

個人用 Teams のデバイス シナリオでは、ユーザー アカウントが Teams 以外のシナリオでもデバイス コード フローを使用できる可能性があるため、スコープが難しくなります。 広範なユーザー除外は避けてください。 ユーザーベースの例外が必要な場合は、リスクを文書化し、使用状況を監視し、例外を定期的に確認します。

Teams デバイスの外部でデバイス コード フローを使用する場合

一部の組織では、Azure CLI、開発者ツール、管理ツール、従来のコマンド ライン エクスペリエンスなど、他のシナリオでデバイス コード フローを使用します。 影響を回避するために、構成済みのポリシーの一部としてこれらのシナリオを考慮します。

テナント全体のデバイス コード フロー ブロックを適用する前に、次の手順を実行します。

1. 認証プロトコル = デバイス コード フロー でフィルター処理されたサインイン ログと、元の転送方法 = デバイス コード フロー であるサインインを確認します。
2. 依存関係ごとに、ユーザー、アプリまたはリソース、場所、デバイス コンテキスト、およびビジネス所有者を特定します。
3. 可能な場合は、シナリオをより安全な認証方法に移行します。 ユーザーに対して、ブラウザー ベースまたは仲介型のサインインを優先します。 自動化の場合は、マネージド ID またはワークロード ID フェデレーションを優先します。
4. 承認されたデバイス コード フローの依存関係に対してのみ例外グループを作成します。
5. Teams 以外の例外が残っている場合は、所有者と共に文書化されたリスク受け入れとして扱い、周期を確認します。

例外グループに広範なユーザー集団を追加しないでください。 広範なユーザー例外により、目的のツールやシナリオを超えたデバイス コード フローが可能になります。

適用後にポリシーを維持する

ポリシーが適用されたら、引き続きデバイス コード フローの使用状況を監視し、例外を最新の状態に保ちます。

関連するコンテンツ

• 条件付きアクセス: 認証フロー
• 条件付きアクセス ポリシーを使用して認証フローをブロックする
• Microsoft Teams Rooms でサポートされている条件付きアクセス ポリシー
• Microsoft Entra ID で緊急アクセス アカウントを管理する
• Microsoft Entra サインイン ログ
• Microsoft Teams Rooms をデプロイする
• Android で Teams 電話、Teams ディスプレイ、Teams パネル、Microsoft Teams Rooms を展開する