Azure Entra IDユーザー・グループ管理｜動的グループによる運用自動化の術

1. Microsoft Entra IDとグループ管理の基本

1. Microsoft Entra IDとグループ管理の基本

まず、基本となる用語を整理しましょう。かつて「Azure Active Directory（アジュール・アクティブ・ディレクトリ）」と呼ばれていたサービスは、現在「Microsoft Entra ID（マイクロソフト・エントラ・アイディー）」へと名称が変更されました。これは、クラウド上での本人確認（認証）やアクセス許可（認可）を司るアイデンティティ基盤です。

企業でクラウドサービスを利用する際、個別に権限を割り当てるのは非効率です。そこで「グループ」という箱を作り、その箱に権限を付与して、ユーザーをその箱に入れるという運用が一般的です。しかし、手作業でメンバーを追加・削除する「割り当て済み」グループでは、退職者の消し忘れや新入社員の追加漏れといったミスが発生しやすくなります。これを解決するのが「動的グループ」です。

2. 動的グループとは？仕組みを優しく解説

2. 動的グループとは？仕組みを優しく解説

動的グループ（ダイナミック・グループ）とは、特定の条件（ルール）をあらかじめ決めておき、その条件に合致するユーザーをシステムが自動的にメンバーとして抽出する機能です。例えば、「部署（Department）という項目が『販売』であること」というルールを作ると、プロフィールに「販売」と入力されている人は、自動的にそのグループのメンバーになります。逆に、部署が変わってプロフィールを「人事」に書き換えると、即座に販売グループから外れます。

この仕組みにより、管理者はユーザーのプロフィール情報を正しく更新するだけで、メーリングリストの追加や、特定のアプリケーションへのアクセス権限、さらにはライセンスの割り当てまでを自動化することが可能になります。まさに運用自動化（うんようじどうか）の要と言えるでしょう。

3. 動的グループ作成のためのルール構文

3. 動的グループ作成のためのルール構文

動的グループを動かすには、「ルール」を書く必要があります。これは少しプログラミングに似ていますが、規則性は非常にシンプルです。基本的には「どの項目が」「どんな値か」を指定するだけです。Entra IDでは、GUI（画面操作）でルールを作成できるほか、高度な設定が必要な場合は直接「ルール構文」を記述することもできます。

例えば、「部署が営業部で、かつ役職が部長」といった複数の条件を組み合わせることも可能です。ここでは、最も基本的なルールの書き方の例を見てみましょう。以下は、部署プロパティに基づいた判定のイメージです。

(user.department -eq "Sales") -and (user.jobTitle -contains "Manager")

このコードは「部署がSales（セールス）であり、かつ役職名にManager（マネージャー）が含まれている場合」という条件を示しています。-eqは「一致する」、-containsは「含む」という意味になります。

4. 属性情報の重要性とデータベース的な考え方

4. 属性情報の重要性とデータベース的な考え方

動的グループを正しく機能させるためには、ユーザー一人ひとりの「属性情報（プロパティ）」が正確に入力されている必要があります。これはデータベースのテーブルをイメージすると分かりやすいでしょう。Entra IDの内部では、以下のようなデータが管理されています。

id | displayName | department | jobTitle      | city
---+-------------+------------+---------------+-------
1  | 田中一郎    | Sales      | Sales Manager | Tokyo
2  | 佐藤花子    | HR         | Specialist    | Osaka
3  | 鈴木次郎    | Sales      | Consultant    | Tokyo
4  | 高橋愛美    | IT         | Engineer      | Nagoya
5  | 伊藤健一    | Sales      | Director      | Tokyo

もし「部署がSalesの人だけを集めたグループ」を作りたい場合、システムはこのテーブルをスキャンし、ID 1, 3, 5のユーザーを自動でピックアップします。もし後からID 2の佐藤さんが営業部に異動になり、管理者が属性を「HR」から「Sales」に変更すると、システムがそれを検知して佐藤さんをグループに追加します。

5. 動的グループ設定の具体的な手順

5. 動的グループ設定の具体的な手順

実際にMicrosoft Entra管理センターで動的グループを作成する手順は以下の通りです。

• 「グループ」メニューから「すべてのグループ」を選択し、「新しいグループ」をクリックします。
• グループの種類を「セキュリティ」または「Microsoft 365」から選びます。
• 「メンバーシップの種類」という項目で、デフォルトの「割り当て済み」から「動的ユーザー」に変更します。
• 「動的クエリの追加」をクリックし、条件を設定します。

ここで、特定のドメイン名を持つユーザーだけを抽出するルールの例を紹介します。外部パートナーと社内メンバーを区別する際などに非常に役立ちます。

user.userPrincipalName -match "@example.com$"

このルールは、ユーザープリンシパル名（ログインIDのようなもの）が「@example.com」で終わる人だけを対象にするという意味になります。-matchを使うことで、柔軟な文字列検索が可能になります。

6. 動的グループを活用したライセンスの自動割り当て

6. 動的グループを活用したライセンスの自動割り当て

動的グループの真価を発揮するのが「グループベースのライセンス付与」です。通常、Microsoft 365 E3やE5といったライセンスは、ユーザーごとに手動でチェックを入れて割り当てますが、動的グループを使えば「正社員属性がついたら自動でライセンス付与」といった運用が可能です。

以下のルールは、会社の社員番号（employeeId）が空（ヌル）ではない、つまり何らかの番号が振られている社員全員を対象にする例です。これにより、「社員」という身分があれば即座に業務ツールが使えるようになります。

user.employeeId -ne null

-neは「Not Equal（一致しない）」の略で、ここでは「空ではない」ことを指します。このように、特定の値が入っているかどうかだけで判断するのも、シンプルで強力な自動化手法です。

7. 動的グループ利用時の注意点とコスト

7. 動的グループ利用時の注意点とコスト

非常に便利な動的グループですが、いくつか注意点があります。まず、この機能を利用するには「Microsoft Entra ID P1」以上のライセンスが必要です。無料版や基本的なライセンスでは利用できないため、コスト計算に含めておく必要があります。

また、ルールの反映には少し時間がかかることがあります。ユーザー属性を変更してからグループに反映されるまで、数分から数十分程度のタイムラグが発生する場合があるため、「変更したのにすぐ入らない！」と焦らず、少し待つ余裕を持つことが大切です。また、ルールが複雑すぎると計算に負荷がかかるため、できるだけシンプルな条件で構成するのが運用のコツです。

8. 動的デバイスグループによる端末管理

8. 動的デバイスグループによる端末管理

ここまでは「ユーザー」を対象にしてきましたが、実は「デバイス（PCやスマホ）」も動的にグループ化できます。例えば、「Windows 10のPCだけ」や「特定のメーカーの端末だけ」を自動でグループにまとめることができます。これにより、OSの種類に応じたセキュリティポリシーを自動で適用できるようになります。

(device.deviceOS -eq "Windows") -and (device.deviceOSVersion -startsWith "10.0")

このように、device.から始まるプロパティを使うことで、端末管理（Intuneなど）の自動化も一気に進みます。ユーザー管理とデバイス管理の両輪で動的グループを活用することで、企業のIT管理コストは劇的に削減されるでしょう。

まとめ

まとめ

これまでに解説してきたように、Microsoft Entra ID（旧称：Azure Active Directory）における動的グループ（ダイナミック・グループ）の活用は、現代のクラウド管理において欠かせない要素です。手作業によるユーザー追加や削除という「アナログな運用」から脱却し、属性情報に基づいた「自動化された運用」へとシフトすることで、管理ミスを劇的に減らすことが可能になります。

動的グループ運用の重要ポイント

動的グループを成功させる鍵は、何よりも「ユーザー属性（プロパティ）の正確性」にあります。データベースに登録されている部署名、役職、居住地などの情報が正しく入力されていなければ、自動化の歯車は狂ってしまいます。例えば、以下のSQLクエリのような考え方で、システムは常にディレクトリ内をスキャンし、条件に合致するユーザーを抽出しています。

-- 動的グループの論理的な抽出イメージ
SELECT displayName, userPrincipalName
FROM EntraIDUsers
WHERE department = 'Sales' 
  AND jobTitle LIKE '%Manager%'
  AND accountEnabled = true;

このように、SQLで特定のレコードを抽出するように、Entra ID内でもルール構文（クエリ）が実行されています。管理者は、この「ルール」を定義するだけで、あとはシステムが24時間体制でメンバーシップを最新の状態に保ってくれるのです。

動的グループのメリットと活用の幅

動的グループのメリットは単なる「手間削減」に留まりません。セキュリティの向上という側面も非常に大きいです。例えば、プロジェクトを離脱したユーザーが、属性変更と同時にアクセス権限を持つグループから自動的に除外されるため、権限の「消し忘れ」による情報漏えいリスクを最小限に抑えることができます。

また、ライセンス管理においてもその威力は絶大です。特定の役職や雇用形態に応じて、Microsoft 365のライセンスを自動付与・剥奪する設定を行えば、無駄なライセンスコストを削減しつつ、必要な人に必要なツールを即座に提供できる環境が整います。

実践的なルール構文の応用

より実践的な場面では、複数の条件を組み合わせた複雑なルールが必要になることもあります。以下に、特定の条件に基づいた高度なルール構成の例をいくつか挙げます。

• 正社員かつ特定の拠点に所属するユーザーを抽出： (user.employeeType -eq "FullTime") -and (user.city -eq "Tokyo")
• 特定のドメイン以外の外部ユーザーをすべて抽出： user.userPrincipalName -notContains "@yourcompany.com"
• 特定のセキュリティタグが付与されたデバイスを抽出： device.devicePhysicalIds -any (_ -contains "OrderPurchase")

運用のためのベストプラクティス

動的グループを導入する際は、以下のステップを意識することをお勧めします。

1. 属性の標準化： 「営業部」「Sales」「営業」など、表記揺れを防ぐための運用ルールを策定する。
2. ルールのテスト： 本番環境に適応する前に、プレビュー機能を使って期待通りのメンバーが抽出されるか確認する。
3. モニタリング： 属性変更が反映されるまでのタイムラグ（最大24時間程度かかる場合もありますが、通常は数分から数十分）を理解し、定期的にログを確認する。

動的グループは、Microsoft Entra ID P1以上のライセンスを必要とする投資ではありますが、それによって得られる運用の安定性とスピード、そして人的リソースの解放を考えれば、非常にコストパフォーマンスの高い機能と言えるでしょう。

// 動的グループの内部的な判定ロジックをC#で表現した例
var members = allUsers.Where(u => u.Department == "Sales" && u.IsActive == true).ToList();

foreach (var user in members)
{
    Console.WriteLine($"{user.DisplayName} を営業グループに自動追加しました。");
}

id | name     | department | groupName
---+----------+------------+-----------
1  | 山田太郎 | Sales      | Sales_Group
2  | 佐藤花子 | IT         | IT_Group
3  | 鈴木一郎 | Sales      | Sales_Group

UPDATE EntraIDUsers 
SET department = 'Sales' 
WHERE id = 2;

id | name     | department | groupName
---+----------+------------+-----------
1  | 山田太郎 | Sales      | Sales_Group
2  | 佐藤花子 | Sales      | Sales_Group
3  | 鈴木一郎 | Sales      | Sales_Group

sudo usermod -aG sales_group hanako
groups hanako
hanako : hanako sales_group