「アプリには Group 1 しか割り当てていないのに、Entitlement Management のアクセスパッケージ経由で Group 2 のユーザーもアプリに現れ、外部 SaaS にプロビジョニングされた」――この挙動は誤動作ではありません。Microsoft Entra ID（旧 Azure AD）の割り当てとプロビジョニングの仕組みを理解すれば、理由と対策は明確です。本記事では、設計の原理、再現手順、運用の落とし穴、実務的なガバナンスまでを一気に整理します。
目次
この記事のゴールと前提
- ゴール：Microsoft Entra ID の「エンタープライズ アプリ」へのユーザー プロビジョニング条件と、Entitlement Management（以下 EM）のアクセスパッケージが関与するワークフローを正しく理解し、設計・運用の指針を示す。
- 対象読者：SaaS 連携・ID ガバナンス・ゼロトラストを担当する情報システム部門/セキュリティ部門。
- 前提：アプリ A はエンタープライズ アプリ（ギャラリー/非ギャラリー問わず）として登録済み。自動プロビジョニング（SCIM 等）が有効化されている想定。
シナリオの整理
| 前提 | 実施内容 | 観測された事象 |
|---|---|---|
アプリ A の「ユーザーとグループ」には Group 1 のみを割り当て。 | EM のアクセスパッケージで Group 2 のユーザーに「アプリ A」を付与。 | Group 2 のユーザーもアプリ A にプロビジョニングされ、「ユーザーとグループ」一覧に個別ユーザーとして出現。 |
結論（要点）
| 結論 | 説明 |
|---|---|
| される（仕様どおり） | アクセスパッケージがアプリ A をリソースとして直接含む場合、パッケージの対象ユーザーはグループに属していなくても個別ユーザー割り当てとして登録される。結果、アプリの「ユーザーとグループ」画面には「Group 1（グループ割り当て）」と「ユーザー X（個別割り当て）」が並ぶ。プロビジョニング エンジンは割り当ての結果を入力として処理するため、当該ユーザーは外部 SaaS 側に作成/更新される。 |
なぜそうなるのか：割り当てとプロビジョニングの関係
用語の整理
| 用語 | 意味 | 主な設定箇所 |
|---|---|---|
| 割り当て（Assignment） | 「誰にアプリ（またはアプリロール）を使わせるか」を Entra ID に記録する操作。対象はグループまたはユーザー。 | エンタープライズ アプリ > ユーザーとグループ / EM のアクセスパッケージ |
| プロビジョニング（Provisioning） | 割り当てをもとに外部 SaaS 側のユーザー・グループ・ロールを作成・更新・無効化する自動処理（SCIM など）。 | エンタープライズ アプリ > プロビジョニング |
| ユーザーとグループ | アプリに対する割り当ての結果一覧。グループ割り当てと個別ユーザー割り当てが混在して表示される。 | エンタープライズ アプリ > ユーザーとグループ |
重要な観点：表示は「結果」、プロビジョニングは「入力」
- 「ユーザーとグループ」一覧は各種経路から生まれた割り当ての総和（＝結果）を表示する。
- プロビジョニングはこの「総和」を入力として解釈し、外部 SaaS 側へ反映する。
- EM のアクセスパッケージがアプリを直接含むと、EM は個別ユーザー割り当てを生成するため、当該ユーザーは一覧にユーザー行として現れる。
Entitlement Management のワークフロー
ケースA：アクセスパッケージに「アプリ A」を直接含める
- ユーザーがパッケージをリクエストし、承認される。
- EM は対象ユーザーに対し、アプリ A のアプリロールを個別付与（＝個別割り当て）。
- アプリ A の「ユーザーとグループ」に当該ユーザーが行として追加される。
- プロビジョニング サービスは「新規に割り当てられたユーザー」を検出し、SaaS 側にユーザーを作成/更新。
ケースB：アクセスパッケージに「Group 1」を含める
- ユーザーがパッケージで
Group 1に参加（動的/手動いずれでも）。 - アプリ A は
Group 1に対してグループ割り当て済みであるため、当該ユーザーはグループ経由で権限を得る。 - 「ユーザーとグループ」には
Group 1のみが表示され、ユーザー個別行は追加されない。 - プロビジョニング サービスは
Group 1のメンバーシップを展開し、SaaS 側にユーザーを作成/更新。
プロビジョニング エンジンが評価する対象
| 割り当て形態 | プロビジョニングの実施対象 | 備考 |
|---|---|---|
| グループ割り当て | グループの現在メンバー（動的メンバーも評価）。 | 大規模環境では評価や差分検出の安定性・運用性に利点。 |
| 個別ユーザー割り当て | 当該ユーザーのみ。 | EM がアプリを直接含む場合に生成されやすい。 |
再現テストの手順（検証用）
- エンタープライズ アプリ「アプリ A」を用意し、
Group 1のみを割り当てる。 - EM でアクセスパッケージ P を作成し、リソースとして「アプリ A のアプリロール」を追加する。
- リクエストポリシーを設定し、
Group 2のユーザーが申請できるようにする。 Group 2のユーザーで申請 → 承認。- アプリ A の「ユーザーとグループ」を確認すると、
Group 1に加えて当該ユーザーが個別ユーザーとして追加されている。 - プロビジョニング ログ/アプリ監査ログを確認すると、外部 SaaS への作成/更新が実行されている。
「特定グループだけ」に制限したい場合の設計パターン
| 対策 | 実装のポイント | メリット | 留意点 |
|---|---|---|---|
| ① アプリを直接含めず、グループを含める | アクセスパッケージのリソースは「Group 1」に限定。アプリ A は Group 1 にのみ割り当てる。 | 「ユーザーとグループ」に個別ユーザーが混在せず、権限経路が一元化。 | グループ設計（命名・階層・動的ルール）を最初に整備する必要。 |
| ② 個別割り当てを運用ポリシーで禁止 | パッケージのリソース選定ルールとして「アプリは直接追加しない」を徹底。レビューで違反パッケージを検知。 | 誤った個別付与の増殖を防止。 | 製品設定による強制ではないため、運用ガイド・監査の両輪が必要。 |
| ③ 動的グループで属性制御 | 例：(user.department -eq "Sales") などで Group 1 を維持。 | 人事異動と連動し、自動的に付与・剥奪が可能。 | 属性の鮮度・正規化・人事連携の品質が鍵。 |
| ④ プロビジョニング/監査ログの定期レビュー | 「グループ外個別ユーザー」が存在しないかレポート化し、是正フローを定義。 | ドリフト（設計からの逸脱）を早期検知。 | レポートの粒度・保管期間・担当責任分界の明確化が必要。 |
ベストプラクティス（運用を安定させる設計原則）
- 割り当て経路はできるだけ一本化：アプリごとに「グループ経由」に統一し、個別割り当ては例外承認制。
- 最小権限原則の徹底：アプリロールごとにグループを分割（例：
AppA_Readers/AppA_Editors）。 - 動的グループ + 属性管理：部門・雇用区分・勤務地などの属性を正規化し、動的ルールの依存を明確化。
- EM はグループのライフサイクル管理に専念：パッケージは「グループ参加の入り口」として設計し、アプリはグループに割り当て。
- ロールとライセンスの分離：アプリの権限（ロール）と Microsoft 365/Entra のライセンス付与は責務を分ける。
- 可観測性：プロビジョニング・監査ログ・アクセス レビューを定期運用。
よくある誤解と落とし穴
| 誤解 | 実際 | 影響/対処 |
|---|---|---|
| 「ユーザーとグループ」の表示にユーザーが出た＝手動で足された。 | EM がアプリを直接含むパッケージを通じて自動的に個別割り当てが作成されることがある。 | 設計通りか設計逸脱かをログで判定。逸脱ならパッケージ設計を是正。 |
| グループ割り当てにしていれば、個別ユーザーは絶対に発生しない。 | 別経路（他パッケージ・手動・API）で個別割り当てが混在し得る。 | 定期レポートで「個別割り当て」を棚卸しし、グループへ統合。 |
| EM を入れれば勝手に最小権限が実現する。 | EM は入口を整えるツール。権限スコープの設計は別途必要。 | グループ設計・ロール設計・承認フローの整合性を先に定義。 |
ライセンスと前提条件
- EM（アクセスパッケージ、カタログ、ライフサイクル、アクセス レビュー等）を利用するには、Microsoft Entra ID Governance のライセンスが必要。
- 自動プロビジョニングを行うアプリは、SCIM 等のコネクタ設定（ターゲット URL、シークレット、属性マッピング）が正しく構成されていること。
- アプリ側の「ユーザー割り当てが必要」設定を理解：Yes なら割り当てがないユーザーはサインイン不可。EM で直接/間接のいずれかの割り当てを作る設計を選ぶ。
設計チェックリスト
- アプリごとに「割り当て方式（グループ/個別）」を定義し、逸脱を禁止する運用ルールがある。
- アクセスパッケージのリソースは可能な限りグループのみ。アプリを直接含める場合は特別な理由を記録。
- 動的グループのルールは人事属性と合致し、退職・異動時の剥奪が自動化されている。
- アプリロールとグループの1対1/1対多のマッピング方針が明確。
- プロビジョニングのスコープ（「割り当て済みユーザーのみ」など）と差分間隔を把握し、SaaS 側のライセンス消費を予測。
- 監査レポートで「個別ユーザー割り当て」を検出できる。
具体例：安全なアサイン設計
グループ中心の設計
- アプリ A の各アプリロールに対応するグループを作成（例：
AppA_Role_Reader/AppA_Role_Admin）。 - アプリ A には上記グループのみを割り当て、ユーザーの直接割り当ては禁止（運用ポリシー）。
- EM のアクセスパッケージにはアプリではなく、これらグループをリソースとして追加。
- リクエスト承認後、ユーザーは該当グループに参加し、アプリ権限はグループ経由で付与。
動的グループのルール例
(user.department -eq "Sales") and (user.accountEnabled -eq true)上記のようなルールを AppA_Role_Reader に適用すれば、部門異動で自動的に権限が更新されます。承認フローは EM が担い、プロビジョニングはアプリ設定が担うため、責務が明確になります。
プロビジョニングと外部 SaaS の整合
- 属性マッピング：
userPrincipalName/mail/employeeIdなど、SaaS 側の一意キーと整合させる。重複や変更頻度の高い属性を主キーにしない。 - ロール/グループの表現：SaaS 側がロールをネイティブに持つ場合はロールへ、グループ主体ならグループへ同期。片側だけで完結しない設計を避ける。
- 無効化戦略：剥奪時は「SaaS の無効化」か「削除」か、保持期間と復旧方針を決めておく。
監査とガバナンスの実践
定期レビュー
- アクセス レビュー：アプリ ロールごとに所有者レビューを四半期実施。グループ経由でないユーザーが残っていないか確認。
- ドリフト検出：「ユーザーとグループ」に個別ユーザーが現れたら、発生経路（別パッケージ/手動/スクリプト）を追跡。
- 職責分掌：パッケージ所有者とアプリ所有者の役割を分け、相互承認を必須化。
トラブルシューティング（よくある症状と対処）
| 症状 | 原因の典型 | 一次切り分け | 対処 |
|---|---|---|---|
| Group 2 ユーザーがアプリに突然現れた。 | EM パッケージにアプリが直接追加され、個別割り当てが生成。 | 当該ユーザーのアクセス履歴・パッケージ承認記録・監査ログを確認。 | パッケージを「グループ追加」のみに修正し、個別割り当てはグループへ移行。 |
| 外部 SaaS 側で権限が過剰。 | アプリロールのマッピング過多、複数グループ重複。 | ロール/グループ対応表を作成し、重複を洗い出し。 | 役割単位でグループを分離、最小権限へ再設計。 |
| 退職者が SaaS に残存。 | 無効化イベント未同期、割り当てスコープが「全ユーザー」。 | プロビジョニング設定のスコープとスケジュールを点検。 | 「割り当て済みユーザーのみ」に変更し、オフボーディング動線を標準化。 |
実務ノウハウ：移行時の手堅い進め方
- 現状把握：各アプリの「ユーザーとグループ」をエクスポートし、個別ユーザーの件数と発生源を分類。
- グループ設計：アプリロール ↔ グループの対応表を作成。命名規則・所有者・承認者を定義。
- パッケージ整流化：アプリが直接含まれたパッケージは段階的に「グループ」に置換。
- SaaS 側の確認：ロール・グループ・ライセンスの自動付与/剥奪の整合性を検証。
- モニタリング：プロビジョニング実行の失敗・スロットリング・属性不整合をアラート化。
セキュリティ視点の補足
- 最小公開：パッケージの対象者スコープは「必要最小のディレクトリ ロール/グループ」に限定。
- 二段階承認：特権ロールを付与するアプリロールは二者承認＋有効期限＋アクセス レビューを必須化。
- 期限付きアクセス：パッケージ側で有効期限・再承認を設定。期限切れで自動剥奪。
FAQ
Q1. EM を使わずに手動で割り当てても同じですか？
A1. はい。個別ユーザー割り当てを作れば同じくプロビジョニング対象になります。EM は「その個別割り当てを作る便利な経路」の一つです。
Q2. 個別割り当てを技術的に禁止できますか？
A2. 製品の標準機能だけで全面禁止は困難です。実務では「パッケージはグループのみ」「アプリ所有者が定期棚卸し」の運用統制で抑止します。
Q3. グループ割り当てと個別割り当てが混在すると何が困る？
A3. 監査コストが上がり、権限の剥奪漏れが発生しやすくなります。原因経路が複数あると是正が遅れます。
Q4. プロビジョニングのスコープ設定は影響しますか？
A4. 「割り当て済みユーザーとグループのみ」を選ぶと、割り当て結果に基づいてのみ同期します。スコープを広げると予期せぬ作成が増える可能性があります。
Q5. 旧 Azure AD と Entra ID の表記差は設計に影響しますか？
A5. 名称の変更で動作が変わることはありません。設計意図（割り当て経路の一元化）を守ることが重要です。
まとめ
- アクセスパッケージがアプリを直接含むと、対象ユーザーには個別割り当てが自動作成され、プロビジョニングされる。これは仕様どおり。
- 「ユーザーとグループ」は結果表示であり、グループ/個別の両方が並ぶ。プロビジョニングはその総和を入力とする。
- 「特定グループだけ」に制限したいなら、アプリはグループにのみ割り当て、EM のパッケージにはグループだけを含める方針が最良。
- 動的グループ・アクセス レビュー・監査レポートを組み合わせ、設計ドリフトを継続的に是正する。
付録：運用テンプレート（例）
| 項目 | テンプレート |
|---|---|
| 命名規則 | AppA_Role_{Reader|Editor|Admin}、SEC_ プレフィックスで特権識別 |
| 所有者 | アプリ所有者（一次）＋情報シス（二次） |
| 承認 | 通常ロール＝一次承認、特権ロール＝二次承認＋有効期限 |
| パッケージ | 含めるリソースはグループのみ。アプリを直接含めない。 |
| レビュー | 四半期ごとにアクセス レビュー＋「個別割り当て」棚卸し |
| プロビジョニング | スコープは「割り当て済みのみ」。属性マッピングは一意キーを厳選。 |
要点の再掲：本件は不具合ではなく「EM がアプリを直接含んだときに個別割り当てを生成する」という仕様の表れです。設計段階でグループ中心に寄せ、アクセスパッケージはグループ加入の入口に限定する――これが、権限経路のシンプルさと監査容易性を両立する最短ルートです。
コメント