Entra ID 自動化 #1 全体像 — テナント、ディレクトリオブジェクト、JML ライフサイクル
Microsoft Graph 実務入門シリーズでは、メール、ファイル、Teams をコードで扱いました。今回のトラックはその土台にある層、つまり ID(アイデンティティ)管理そのものを自動化する話です。アカウント作成、グループ管理、アクセスポリシー、権限付与。組織の IT 運用で最も反復的で、最もミスのコストが大きい領域であり、だからこそ自動化の投資対効果が最も確実な領域でもあります。
Entra ID — Azure AD の現在の名前 #
まず名前の整理から。Microsoft Entra ID は Azure Active Directory(Azure AD)の現在の名前です。 2023 年に改名され、製品自体は連続しています。古いドキュメントやツール名(AzureAD PowerShell モジュールなど)には旧名が残っているので、検索するときは両方の名前を知っておく必要があります。
Entra ID の仕事は一文に要約できます。「誰が(認証)何をできるか(認可)を組織単位で管理するクラウドディレクトリ」。 Microsoft 365 のすべてのログインがここを通り、社内 SaaS の SSO も、自分たちが作るアプリのログインもここにつなげられます。なお、オンプレミスの Active Directory(AD DS)とは別の製品です。多くの組織が両者を同期して併用していますが、このシリーズはクラウド側の Entra ID を扱います。
ディレクトリの構造 — テナントと 4 種類のオブジェクト #
自動化の対象を正確に知るには、構造から押さえます。
- テナント(tenant): 組織ひとつのディレクトリインスタンスです。会社が Microsoft 365 を契約するとテナントがひとつ作られ、その中のすべてがこの境界の中で管理されます。
- ユーザー(user): 従業員アカウントと外部協力者(ゲスト)アカウントです。
userPrincipalName、employeeId、departmentといった属性を持ち、この属性が後で扱う自動化の燃料になります。 - グループ(group): 権限、ライセンス、アプリアクセスをまとめて配布する単位です。セキュリティグループと Microsoft 365 グループの 2 種類があります。
- アプリケーション(アプリ登録 / サービスプリンシパル): 人ではない主体です。私たちが作る自動化スクリプトも、ここに登録されたアプリの ID で動きます。
- デバイス(device): 組織に登録された PC とモバイル端末です。条件付きアクセスで「会社管理のデバイスか」を判断する根拠になります。
自動化の観点でこの構造が意味することはひとつです。すべてのオブジェクトが API で照会・作成・更新できるリソースだということ。 管理ポータルでクリックして行うすべての作業に、対応する Graph API エンドポイントがあります。
JML — アカウント自動化の骨格モデル #
アカウント管理の業務は 3 つに整理できます。業界標準の用語で JML(Joiner-Mover-Leaver)と呼びます。
| 段階 | 状況 | やるべきこと |
|---|---|---|
| Joiner(入社) | 新メンバーの合流 | アカウント作成、ライセンス割り当て、グループ配置、初期資格情報の受け渡し |
| Mover(異動) | 部署・職務の変更 | 旧アクセスの回収、新アクセスの付与、属性の更新 |
| Leaver(退職) | メンバーの離脱 | アクセス遮断、ライセンス回収、データ移管、アカウント整理 |
この 3 つの流れを手作業でやるとどうなるかは、誰もが知っています。入社者は最初の週に権限がなくて待ちぼうけ、異動者は前の部署の権限を持ち歩き、退職者のアカウントが何か月も生きています。最後のものは単なる非効率ではなく、セキュリティ事故の定番シナリオです。このシリーズの第 2 回(ユーザーライフサイクル)と第 3 回(グループ)が、この JML をコードにする方法を扱います。
ツールの地形 — 何で自動化するか #
Entra ID の自動化ツールは 3 層に整理できます。
- Microsoft Graph API: すべての基盤です。REST エンドポイント(
https://graph.microsoft.com/v1.0/...)と言語別 SDK があり、このシリーズのコードも Graph 基準です。Python SDK のセットアップは Graph 実務入門 #3 で扱いました。 - Microsoft Graph PowerShell: 管理作業の実務標準です。
Connect-MgGraphで始まるコマンドレット群が Graph API のラッパーとして動きます。一回きりの整理作業や IT 管理者のスクリプトにはこちらが速いです。旧 AzureAD・MSOnline モジュールは廃止の流れなので、新しいスクリプトには使いません。 - IaC(Terraform など): グループ、条件付きアクセスポリシー、アプリ登録のような「構成」に当たるものは、コードで宣言してレビューを経て適用する方式が合います。ポリシーをコードで管理するアプローチは第 4 回で再登場します。
基準はこう置けば大丈夫です。繰り返し実行されるライフサイクル処理は Graph API(スクリプト・サービス)、一回きりの管理作業は PowerShell、状態を持つ構成は IaC。
ライセンス — 機能はティアに紐付いています #
Entra ID の自動化を設計するときにライセンスを知らないと、「作ったのにうちのテナントでは動かない」事態に出会います。大枠だけ整理します。
| ティア | このシリーズに関係する機能 |
|---|---|
| Free(M365 に基本付属) | ユーザー・グループの CRUD、基本 SSO |
| P1 | 動的グループ、条件付きアクセス、セルフサービスグループ管理 |
| P2 | P1 + PIM(主要機能)、Identity Protection、アクセスレビュー |
| Entra ID Governance | ライフサイクルワークフロー、高度なエンタイトルメント管理 |
シリーズで各機能を扱うたびに、必要なティアをその都度明記します。設計段階で「この自動化が要求する最低ライセンス」を確認する習慣が必要です。
準備 — 自動化用のアプリ ID #
このシリーズのコードは、人のログインなしで動く自動化を前提とするので、アプリケーション権限(application permission)で動くアプリ登録が必要です。作成手順と delegated vs application 権限の区別は Graph 実務入門 #2 で詳しく扱ったので、そのまま従えば大丈夫です。このトラックで追加で強調するのは 2 つです。
- 権限は目的別に最小で。 ユーザー管理の自動化には
User.ReadWrite.Allが必要ですが、読み取りだけのレポートスクリプトにその権限を与えてはいけません。自動化の用途別にアプリを分けることが、事故の半径を小さくします。 - 資格情報はシークレットより証明書、可能ならマネージド ID(managed identity)。 Azure の中で動く自動化なら、シークレットそのものをなくせます。
このシリーズの地図 #
| 回 | テーマ |
|---|---|
| 1(この記事) | 構造、JML、ツール、ライセンス |
| 2 | ユーザーライフサイクル: 作成、無効化、ライセンス、ライフサイクルワークフロー |
| 3 | グループ: 動的グループ、グループベースライセンス、アクセス管理 |
| 4 | 条件付きアクセス: ポリシーをコードで管理する |
| 5 | PIM と監査: 常時管理者をなくす、ログの自動化 |
まとめ #
- Entra ID は Azure AD の現在の名前で、組織の認証と認可を管理するクラウドディレクトリです。オンプレミスの AD とは別製品です。
- テナントの中のユーザー、グループ、アプリ、デバイスが自動化の対象で、ポータルのすべての操作に対応する Graph API があります。
- アカウント管理の自動化の骨格は JML(入社・異動・退職)モデルです。退職処理の漏れは非効率ではなくセキュリティ事故です。
- ツールは、繰り返し処理 = Graph API、一回きりの管理 = PowerShell、構成 = IaC と分けて考えます。
- 動的グループと条件付きアクセスは P1、PIM とアクセスレビューは P2、ライフサイクルワークフローは Governance ライセンスが必要です。設計の前に確認すべきです。