設計が重要な理由
Entra IDは「とりあえずユーザーを作ってMFAを有効化する」だけでも使い始められますが、組織が成長すると管理が破綻します。最初に設計を決めておくことで、ユーザー追加・権限変更・セキュリティ強化をスムーズに行えます。
テナント構成
中小企業ではシングルテナントが基本です。M&Aでグループ企業が増えた場合でも、可能な限り1テナントに統合することで管理の一元化とセキュリティポリシーの統一を実現します。
- シングルテナント（推奨）：1つのEntra IDテナントで全社員を管理
- マルチテナント（例外的）：法規制でデータ分離が必要な場合、Entra ID B2Bで連携
ユーザー属性設計
| 属性 | 設計ルール例 | 用途 |
|---|---|---|
| UPN（サインインID） | firstname.lastname@example.co.jp | サインイン、メールアドレスと統一 |
| 表示名 | 姓 名（漢字） | Teams、Outlook上の表示 |
| 部署（Department） | 営業部、開発部 等 | 動的グループの条件、アドレス帳検索 |
| 役職（JobTitle） | 部長、課長、一般 等 | 条件付きアクセス、PIM対象の判定 |
| 利用場所（UsageLocation） | JP | ライセンス割り当てに必須 |
グループ設計
| グループ種別 | 命名規則例 | 用途 |
|---|---|---|
| セキュリティグループ | SG-部門名（SG-Sales） | アクセス権の付与、条件付きアクセスの対象 |
| Microsoft 365グループ | M365-プロジェクト名 | Teams/SharePointサイトの自動作成 |
| 配布リスト | DL-部門名（DL-AllStaff） | メール配信 |
| 動的グループ | DYN-部門名 | 部門属性に基づく自動メンバー管理（P1） |
命名規則を統一することでグループの種類と目的が一目でわかり、管理が容易になります。
条件付きアクセス設計
条件付きアクセスの設計パターンは別記事で6パターンを詳しく解説していますが、最低限以下の3ポリシーを設定します。
- 全ユーザーにMFAを要求：すべてのクラウドアプリへのアクセスにMFAを要求
- レガシー認証のブロック：POP3/IMAP/SMTP等のMFAバイパス可能なプロトコルをブロック
- 管理者への追加制御：管理者ロール保持者に対して、準拠デバイスからのみアクセスを許可
緊急アクセスアカウント
条件付きアクセスの設定ミスで全管理者がロックアウトされる事態に備え、緊急アクセスアカウント（Break Glass Account）を必ず1つ用意します。グローバル管理者権限を付与し、条件付きアクセスから除外し、長く複雑なパスワードを金庫に保管します。
まとめ
Entra IDの設計はテナント構成→ユーザー属性→グループ→条件付きアクセス→緊急アクセスの順に進めます。最初に命名規則を決めておくことで、その後の運用が格段に楽になります。