Entra ID 自動化 #3 グループ設計 — 動的グループ、グループベースライセンス、アクセスパッケージ

前回、「ユーザー自動化の仕事は正しいグループに入れること」と書きました。今回はそのグループ側の話です。グループをうまく設計すればライセンス、アプリアクセス、権限がグループ構造に沿って自然に流れ、設計を誤れば数百のグループを手で管理するという新しいトイルが生まれます。

2 種類のグループ — セキュリティグループと Microsoft 365 グループ #

Entra ID のグループは大きく 2 つです。

自動化設計の観点での基準はシンプルです。アクセス制御が目的ならセキュリティグループ、コラボレーション空間が目的なら M365 グループ。 メンバー構成のルールも違います。セキュリティグループにはユーザーのほかデバイス、サービスプリンシパル、別のセキュリティグループ(ネスト)が入れられますが、M365 グループのメンバーはユーザーのみです。

Graph では POST /groups で作成し、POST /groups/{id}/members/$ref でメンバーを入れます。ただし、この「メンバーを入れるコード」を書く前に、次の節から見る 2 つの仕組みでそのコード自体をなくせないかを、まず問うべきです。

動的グループ — メンバーシップをコードではなくルールで #

動的グループ(dynamic membership group)はメンバー一覧を人が管理しません。属性ベースのルールを定義すれば、Entra ID がルールに合うユーザーを自動で入れて外します。

// 部署が Engineering の正社員
(user.department -eq "Engineering") and (user.employeeType -eq "Employee")

// メンバーのみ、有効なアカウント
(user.userType -eq "Member") and (user.accountEnabled -eq true)

第 2 回で属性の標準化を強調した理由がここで回収されます。department の値に「Engineering」と「エンジニアリング」が混在していれば、動的グループは半分しか捕まえられません。動的グループの品質はルールではなく属性データの品質です。

運用特性を 3 つ知っておく必要があります。

• ライセンス: 動的グループの一意のメンバー 1 人につき Entra ID P1 が必要です。
• 上限と対象: テナントあたり動的グループは最大 15,000 個で、メンバーになれるのはユーザーとデバイスだけです。
• 遅延: メンバーシップの再計算は即時ではありません。属性変更から反映まで時差があるので、「今すぐこの人を入れたい」流れには静的グループ + API が合います。

基準を要約するとこうです。属性で表現できる所属(部署、職種、勤務地)は動的グループ、承認が必要な選択的アクセスは静的グループ(または後述のアクセスパッケージ)、即時性が必要な処理だけ API の直接操作。

グループベースライセンス — 入場が割り当て、退場が回収 #

グループへのライセンス付与は Graph の POST /groups/{id}/assignLicense(または管理センター)で設定します。以降はグループメンバーシップがそのままライセンス状態になります。入れば割り当てられ、出れば回収されます。

動的グループと組み合わせると強力です。「Engineering 部署」の動的グループに開発ツールのライセンスを付けておけば、部署異動(HR → 属性変更 → 動的グループ再計算 → ライセンス移動)が人の手なしで完結します。JML の Mover 処理がこの組み合わせの最大の受益者です。

運用で見るべきは割り当てエラーの監視です。ライセンスの在庫が足りない、サービスプランが競合する、といった場合、グループ割り当てが特定ユーザーで失敗したまま残ります。グループのライセンスエラー状態を定期的に照会して通知するスクリプトが、この構成の相棒です。

ロール割り当て可能グループ — 管理者権限の境界 #

グループに Entra ID の管理者ロールを付けるには、通常のグループでは足りず、作成時に isAssignableToRole: true としたロール割り当て可能グループである必要があります。このグループは通常のグループと扱いが違います。動的メンバーシップは使えず、メンバー管理の権限が上位ロールに制限されます。属性変更ひとつで管理者権限が付与される経路を遮断するための設計です。このグループは第 5 回の PIM と組み合わさり、「グループに入れば管理者候補になり、アクティブ化して初めて権限が点く」構造の材料になります。

アクセスパッケージ — セルフサービスのアクセス申請を製品化 #

グループ設計でなくせない最後の手作業が「アクセス申請チケット」です。プロジェクト X に参加することになったので関連グループ 3 つ、SharePoint サイト、アプリ 2 つに入れてほしい、という類の依頼です。Entra のエンタイトルメント管理(entitlement management)はこれを製品化しました。Governance ライセンスの機能です。

• アクセスパッケージ(access package): グループ、アプリ、サイトのアクセスをひとつの申請単位に束ねます。
• 申請 → 承認フロー(上司または指定承認者)→ 自動付与 → 期限と更新(期限切れで自動回収、延長申請)までが製品機能です。
• 外部協力者(ゲスト)に特に有効です。パッケージの期限がそのままゲストアクセスの終了になるので、「プロジェクトが終わった外部アカウントが永遠に残る」問題が構造的に消えます。

IT チーム視点の効果は明確です。アクセス申請チケットがセルフサービスの申請に変わり、付与だけでなく回収まで自動になります。SRE 実践 #6 で述べたセルフサービス段階の、ID 管理版です。

まとめ #

• アクセス制御はセキュリティグループ、コラボレーションは M365 グループです。メンバーを入れるコードを書く前に、動的グループとアクセスパッケージでそのコードをなくせないか先に確認します。
• 動的グループは属性ベースのルールでメンバーシップを自動化します(P1、ユーザー・デバイスのみ、反映遅延あり)。品質はルールではなく属性データが決めます。
• グループベースライセンスは入場 = 割り当て、退場 = 回収を作ります。動的グループと組み合わせれば部署異動が無人で処理されます。割り当てエラーの監視が相棒です。
• 管理者ロールはロール割り当て可能グループでのみ扱い、このグループは動的メンバーシップが禁止された別のセキュリティ境界です。
• 選択的・期間限定のアクセスはアクセスパッケージでセルフサービス化します。付与より価値があるのは自動回収です。
• 次回はログインの瞬間の防衛線、条件付きアクセスポリシーをコードで管理する方法です。