Microsoft Entra ID は、2026年9月 の幕開けに、今年最大級の月次アップデートのひとつを迎えました。ガバナンス関連の2機能が一般提供(GA)となり、Teams デバイスでのパスワードレス対応がさらに広がり、ハイブリッド ID を双方向に拡張する2つのパブリックプレビューと、セキュリティ関連の変更告知が2件発表されています。大規模な ID 環境を管理しているなら、今月はロードマップの見直しどきです。
今回の7項目すべてに共通するテーマは「統合」です。アクセスレビューの実施方法の統合、共有デバイスの認証方法の統合、ID プロビジョニングの統合、そしてインシデント対応に携われるロールの統合です。
何が変わったのか、なぜ重要なのか、どう対応すべきなのかを、以下で解説します。
1. ユーザー中心のアクセスレビュー — 一般提供(GA)
ステータス: GA 必要なアクション: アクセスレビュープログラムへの採用を検討する
Access Reviews は、レビュー担当者が実際に考える方法——リソース単位ではなくユーザー単位——で機能するようになりました。ユーザー中心のアクセスレビュー(UAR)では、レビュー担当者はグループやアプリケーションごとに個別のレビューを実行する代わりに、1人のユーザーがアクセスできるすべてのリソースを1つのレビューで確認できます。
含まれる内容
- 統合ビュー: グループ、接続済みアプリケーション、未接続(カスタムデータ提供)のアプリケーションを1つのレビュースコープで確認可能
- 未接続アプリのサポート: CSV アクセスデータをアップロードすることで、Entra ID と統合されたことのないアプリケーションでもガバナンスの対象にできる
- レビュー担当者のエクスペリエンス: My Access ポータルで、ユーザー中心のリソース一覧に対して決定を行う
- ライセンス: Microsoft Entra ID Governance または Entra Suite が必要
なぜ重要か
従来のアクセスレビューはリソース中心です。グループを選んでメンバーをレビューし、それをすべてのグループとアプリに対して繰り返します。30個のリソースにアクセスできるユーザーなら、そのアクセスは30人の異なるレビュー担当者によって30回評価される——あるいは、実際には、包括的にレビューされることはほとんどない——ことになります。
ユーザー中心のレビューはこのモデルを逆転させます。あるユーザーを担当する1人のレビュー担当者が、そのユーザーのすべてのアクセスを1回で評価できます。ここでの隠れた注目機能は未接続アプリケーションのサポートです。統合コードを1行も書かずに、シャドウ IT や非統合 SaaS をガバナンスプログラムに組み込めます。
管理者がすべきこと
- 最もリスクの高いユーザーを特定する — アクセスが最も蓄積されがちな特権ユーザーやベンダーユーザーから UAR を開始する
- 未接続アプリ用の CSV データを準備する — Entra ID の外部にあるアプリを棚卸しし、誰がアクセス権を持つかをマッピングする
- 所有者を割り当てる — すべてのカタログリソースとユーザーに明確なレビュー担当者を置く
- パイロット UAR を既存のレビューと並行して実行する — プログラム全体を再構成する前に検証する
2. Lifecycle Workflows でのワークフロー複製 — 一般提供(GA)
ステータス: GA 必要なアクション: ワークフローポートフォリオを整理する
Lifecycle Workflows の管理者は、既存のワークフローを複製して、新しいワークフローの開始点として使えるようになりました。すべての構成、タスク、実行条件、設定がコピーされ、複製したワークフローは [レビューと作成] ページで開きます。保存前に任意の項目を調整できます。
含まれる内容
- 2つの入口: ワークフロー一覧の [複製] アクション、またはワークフロー作成時の [既存のワークフローを複製] カード
- 完全な忠実度: タスク、トリガー、設定がすべて引き継がれる
- 対象範囲: Entra 管理センターで利用可能(Microsoft Graph では不可)
- 必要なロール: Lifecycle Workflows Administrator
なぜ重要か
多くのテナントでは、1つか2つのパラメータが異なるだけの Lifecycle Workflows を何十件も運用しています。部署が違う、トリガーが違う、タスクの順序が違う——といった具合です。従来はそれぞれをゼロから、またはテンプレートから構築する必要がありました。複製機能があれば、テスト済みの既存ワークフローを開始点にでき、構成時間を数時間から数分に短縮し、複雑なタスクロジックを手作業で作り直す際に起きがちなエラーも減らせます。
管理者がすべきこと
- 既存のワークフローを監査する — 単一のソースから再生成できる、ほぼ重複したワークフローを見つける
- 複製の規約を定める — 命名規則とドキュメント化の基準を決め、複製を管理しやすい状態に保つ
- ステージングテナントで複製をテストする — 本番スケジュールに適用する前に検証する
3. Teams デバイス向け Entra リソースアカウント — 一般提供(GA)
ステータス: Teams Rooms、Panels、Common Area Phones で GA 必要なアクション: 共有デバイスアカウントの移行を計画する
Teams 共有デバイスのパスワードレス認証が、デバイスの全ラインアップで一般提供になりました。Microsoft Entra リソースアカウントは、従来のパスワードベースのサインインを、ハードウェアで保護されたデバイスバインド資格情報に置き換えます。これは Windows 版 Teams Rooms のパスワードレスリソースアカウントで Microsoft が採用しているモデルと同じもので、今回その対象が大幅に拡大されました。
含まれる内容
| デバイスの種類 | サポート状況 |
|---|---|
| Windows 版 Teams Rooms | GA(Windows 11 24H2 build 26100.8655 以降、Entra ID 参加) |
| Android 版 Teams Rooms | GA |
| Teams Panels | GA |
| Common Area Phones | GA |
- 移行パス: Teams Rooms Pro 管理ポータル → [計画] → [リソースアカウント] → [移行] タブ
- ライセンス: Teams Rooms または Teams Shared Space ライセンスが必要
- ID: リソースアカウントは Entra ID のみ、AD からの同期、またはサードパーティのフェデレーション IdP によるバックアップに対応
- 既知の制限: 交換用デバイスは最初にパスワードでセットアップし、その後移行する必要がある
なぜ重要か
共有デバイスのパスワードは慢性的なセキュリティ問題です。本質的に共有されるもので、ローテーションもまれで、漏えいしやすい場所に保管されます。Teams Room のパスワードが一度でも侵害されると、攻撃者はライセンスを持つユーザーとして、管理者の制御が及ばないハードウェア上で対話的にサインインできてしまいます。デバイスバインド資格情報はパスワードを完全に排除するため、フィッシングも、パスワードスプレー攻撃も、窃取も成立しません。さらに、古くなったパスワードが最悪のタイミングでルームのサインインを妨げるといったサポート負荷も軽減されます。
管理者がすべきこと
- 共有デバイスアカウントを棚卸しする — パスワードベースのアカウントを持つすべての Teams Room、Panel、電話機が移行候補
- デバイスの準備状況を確認する — Windows ビルド、Android バージョン、Teams アプリのバージョンを要件と照合する
- 移行を段階的に進める — まずパイロットルームで Pro 管理ポータルの移行ツールを使う
- パスワードボールトを更新する — 移行後はシークレット管理から共有デバイスの資格情報を削除する
4. Entra Domain Services での sAMAccountName 同期 — パブリックプレビュー
ステータス: パブリックプレビュー 必要なアクション: レガシーアプリケーションとの互換性の観点で評価する
Entra Domain Services のマネージドドメインは、Entra ID 内の onPremisesSamAccountName 属性から sAMAccountName の値を同期できるようになりました。これにより、sAMAccountName に依存するレガシーアプリケーションは、ワークロードを Azure に移行しても動作し続けられます。
含まれる内容
- 新しいドメイン: 既定で有効
- 既存のドメイン: Domain Services のセキュリティ設定からオプトイン
- 要件: Enterprise または Premium SKU(Standard は対象外)。設定の変更には Application Administrator と Groups Administrator のロールが必要
- クラウド専用ユーザー: onPremisesSamAccountName が存在しない場合は、従来どおり mailNickname ベースの生成を継続
- 制約: sAMAccountName は一意であること、20文字以下であること、サポートされない特殊文字を含まないこと
なぜ重要か
オンプレミスのアプリケーションの多くは、UPN が普及する前に作られました。それらは sAMAccountName に対して認証・認可を行います。そのようなワークロードを Entra Domain Services とともに Azure へ移行すると、アカウント名の不一致によってファイル共有、SQL ログイン、サービスアカウントが壊れます。Entra DS が実際の sAMAccountName を尊重することで、「オンプレミスでは動いていたのに」という類の移行失敗が一掃されます。
管理者がすべきこと
- SKU を確認する — このプレビューは Standard 階層のマネージドドメインには適用されない
- onPremisesSamAccountName のカバレッジを確認する — 同期ユーザーは Entra ID 内で属性が設定されている必要がある
- まず非本番ドメインでテストする — 広く有効化する前にレガシーアプリの認証を検証する
5. Cloud Sync: クラウドから ID ライフサイクルを管理 — パブリックプレビュー
ステータス: グループプロビジョニングは GA。ユーザープロビジョニングはパブリックプレビュー 必要なアクション: Connect Sync からの移行パスとして評価する
Entra Cloud Sync が双方向に対応しました。AD から Entra ID へのプロビジョニングに加え、Cloud Sync はユーザー、グループ、グループメンバーシップを Entra ID からオンプレミスの Active Directory へ逆方向にプロビジョニングできます。クラウドファーストの組織は、レガシーアプリケーション、ファイルサーバー、Kerberos 依存システムのために AD を更新し続けながら、Entra ID を権威あるソース(Source of Authority)として維持できるようになりました。
含まれる内容
| 機能 | ステータス |
|---|---|
| AD DS へのセキュリティグループとメンバーシップのプロビジョニング | GA |
| AD DS へのユーザープロビジョニング | パブリックプレビュー |
| ユーザーとグループを組み合わせたプロビジョニング | パブリックプレビュー |
- サポートされる ID: クラウドネイティブユーザー、Source of Authority 変換済みユーザー、B2B ゲスト、セキュリティグループ
- 前提条件: プロビジョニングエージェント v1.1.3730.0 以降、msDS-ExternalDirectoryObjectId を含む AD DS スキーマ(Windows Server 2016 以降)、Entra ID P1
- 制限: メンバーが50,000人を超えるグループと、オブジェクトが150,000を超えるテナントはサポート対象外
- 同期頻度: グループプロビジョニングは20分ごとに実行
- SoA 変換の注意点: グループ SID を保持し、元の OU パスを維持できる
なぜ重要か
これは Connect Sync → Cloud Sync 移行ストーリーに欠けていたピースです。多くのテナントが Connect Sync を使い続けた理由は、同期エンジン自体ではなく、ディレクトリから AD への依存関係でした。Cloud Sync の逆方向プロビジョニングはそのブロッカーを取り除きます。これまでのリリースと組み合わせれば、真のクラウドファースト ID ライフサイクルを実現できます。HR が Entra ID に書き込み、Entra ID がユーザーをプロビジョニングし、AD にはオンプレミスのワークロードが必要とするアカウントだけが作成されます。経路上に Connect Sync サーバーはありません。
管理者がすべきこと
- AD 依存のアプリケーションをマッピングする — 移行前に、オンプレミスアカウントがまだ必要なものを正確に把握する
- エージェントのフットプリントを計画する — このモデルではプロビジョニングエージェントが Connect Sync サーバーを置き換える
- B2B ゲストのプロビジョニングをテストする — 外部ユーザーが AD に流れ込むのは強力だが、スコープの慎重な管理が必要
- オブジェクト数の上限に注意する — 非常に大規模なテナントでは引き続き Connect Sync が必要
6. Security Administrator ロールの拡張 — 変更のお知らせ
ステータス: 順次展開中。2026年9月末までに完了予定 必要なアクション: ロールの割り当てと SOC ランブックを見直す
組み込みの Security Administrator ロールが拡張され、非特権ユーザーに対する ID インシデント対応アクション(ユーザーアカウントの無効化・有効化、アクティブセッションの失効、パスワードリセットの強制)を含むようになります。
含まれる内容
- 新しいアクセス許可: ユーザーの無効化、ユーザーの有効化、セッションの失効、パスワードリセットの強制
- 対象範囲: 非特権ユーザーのみ — Global Administrator やその他の高特権アカウントは対象外
- ガバナンス: 既存の監査と最小特権の制御は引き続き適用される
- 位置づけ: SOC Identity Responder ロール(2026年6月プレビュー)と、今年前半に拡張された Security Operator に続くもの
なぜ重要か
多くの組織では、ID インシデント対応に2つか3つのロールが必要です。トリアージには Security Administrator、封じ込めアクションには Identity Administrator または User Administrator、という具合です。インシデントの真っ最中に、その引き継ぎは数分を費やします。そして、アカウントが侵害されているとき、数分は大きな違いを生みます。今回の拡張により、Security Administrator を使う SOC チームは ID インシデントを直接封じ込められます。非特権ユーザーに限定されたスコープのおかげで、ロール自体の爆発半径は抑えられたままです。監査証跡にはすべてのアクションが記録され続けます。
管理者がすべきこと
- Security Administrator の割り当てをレビューする — このロールはより強力になるため、保持者を再検証する
- SOC ランブックを更新する — 非特権ユーザー向けの封じ込めアクションにエスカレーションが不要になったことを明記する
- 監査カバレッジを確認する — SIEM が無効化、セッション失効、パスワードリセットの各イベントを取り込んでいることを確認する
7. User.ReadBasic.All アクセス許可スコープの更新 — セキュリティ修正
ステータス: 順次展開中 必要なアクション: User.ReadBasic.All を使用するアプリケーションを監査する
Microsoft は Microsoft Graph の情報漏えいの問題を修正しています。User.ReadBasic.All アクセス許可は、スコープされている基本的なプロファイルプロパティだけでなく、アプリロールの割り当てやライセンスの詳細までアプリが読み取れる状態を意図せず許容していました。
含まれる内容
- 修正内容: appRoleAssignments と licenseDetails への意図しないアクセスを削除
- 意図されたスコープは変更なし: displayName、givenName、id、mail、photo、securityIdentifier、surname、userPrincipalName
- より多くの情報が必要なアプリの場合: アプリロールの割り当てには User.Read.All を、ライセンスの詳細には LicenseAssignment.Read.All を使用する(User.Read.All は両方をカバー)
- 影響: 意図した用途でアクセス許可を使用しているアプリにとって、破壊的な変更ではない
なぜ重要か
これは、めったに見出しにならないものの、静かに影響を及ぼすタイプの脆弱性です。最小限の特権——名前とメールアドレスの読み取り——だけでプロビジョニングされたアプリが、すべてのユーザーが保持するロールやライセンスを列挙できてしまう可能性がありました。つまり、低特権のアプリが特権昇格を計画するための偵察ツールになり得たのです。この修正は正しい判断であり、委任アクセス許可とアプリケーションアクセス許可が実際に何を公開しているかを定期的に再検証する必要性を思い出させてくれます。
管理者がすべきこと
- User.ReadBasic.All を持つアプリを監査する — 付与されているすべてのアプリと、それが正当に必要とするデータをリストアップする
- 必要な箇所はアップグレードする — 割り当て情報やライセンス情報が本当に必要なアプリには User.Read.All または LicenseAssignment.Read.All を申請する
- 同意と付与の履歴をレビューする — 意図しないアクセスを悪用していた可能性のあるアプリを探す
- 変更を文書化する — 修正がテナントに到達する前に、アプリケーションのアクセス許可マトリックスを更新する
9月のラウンドアップで紹介されたその他の項目
Microsoft の 2026年9月 ラウンドアップで取り上げられた3項目は、このシリーズで既に紹介済みです:
- Tenant Governance GA(2026年8月10日)— テナント全体のガバナンス設定が一般提供に
- MCP Firewall プレビュー(2026年8月6日)— エージェンティック AI 時代の Model Context Protocol サーバー向けアクセス制御
- MemberOf の廃止(MC1448379)— 動的グループ、管理単位、エンタイトルメント管理の MemberOf ルール演算子は 2026年11月3日 に廃止。移行ガイダンスはメッセージセンターで提供
注目の日程
- 2026年9月末: Security Administrator ロールの拡張が完全に展開
- 2026年10月1日: Entra ID Protection のレガシーリスクポリシーが廃止
- 2026年11月3日: 動的グループ、管理単位(AU)、エンタイトルメント管理で MemberOf ルール演算子が廃止
Kevin を X (https://x.com/kkaminsk) でフォローして、Microsoft Entra の毎日の最新情報と分析をチェックしてください。