Microsoft Entra IDの「Default user permissions」は、一般ユーザーやゲストが最初から何をできるかを決める重要な設定です。結論から言うと、管理者がまず確認すべきなのは、アプリ登録、グループ作成、テナント作成、ゲストアクセス、ユーザー同意、所有オブジェクトの権限です。既定のままでも業務は進めやすい一方、放置すると不要なアプリ登録、ゲスト招待、グループ乱立、外部ユーザーからのディレクトリ参照といったリスクにつながります。
Microsoft Learnの公式情報では、Microsoft Entra IDのユーザー権限は「ユーザーの種類」「ロール割り当て」「個々のオブジェクトの所有権」で構成され、既定のユーザー アクセス許可はMicrosoft Entra IDのユーザー設定で変更できると説明されています。(Microsoft Learn) 2026年5月上旬の更新で特に注目すべき点は、既定権限表に「Agents」領域が追加され、メンバー ユーザーがエージェント関連オブジェクトを列挙・読み取り、所有する対象を管理できることが明確化された点です。(GitHub)
Microsoft Entraの既定のユーザー アクセス許可とは
Microsoft Entra IDでは、ユーザーを作成しただけでも一定の操作権限が付与されます。これは管理者ロールとは別の「既定のユーザー権限」であり、管理者でないユーザーにも影響します。
重要なのは、Microsoft Entraの既定権限は「何もできない状態」ではないことです。メンバー ユーザーは、自分のプロフィールやパスワード変更だけでなく、アプリケーション登録、B2Bゲスト招待、ディレクトリ情報の読み取りなど、組織によっては制限したい操作を既定で実行できます。(Microsoft Learn)
| ユーザー種別 | 既定でできる主なこと | 管理上の見方 |
|---|---|---|
| メンバー ユーザー | アプリケーション登録、プロフィール写真・携帯電話番号の管理、パスワード変更、B2Bゲスト招待、ディレクトリ情報の読み取り | 社内ユーザー向けの標準権限。開発や共同作業には便利だが、アプリ・グループ・ゲストの増加を招きやすい |
| 既定のゲスト ユーザー | 自分のプロフィール管理、パスワード変更、他のユーザー・グループ・アプリの一部情報の取得 | 外部コラボレーション向け。全ディレクトリ情報は読めないが、参照可能な情報の範囲を確認すべき |
| 制限されたゲスト ユーザー | 自分のプロパティ読み取り、パスワード変更、携帯電話番号の管理など | 委託先・一時利用者・最小権限を重視する外部ユーザー向け |
Microsoftの公式ドキュメントでは、ゲスト ユーザーはすべてのユーザー、グループ、その他のディレクトリ オブジェクト一覧を列挙できない一方、管理者ロールに追加すれば読み取り・書き込み権限を持てることも説明されています。(Microsoft Learn) つまり、「ゲストだから安全」と考えるのではなく、ゲストに付与したロールとアクセス先アプリまで含めて確認する必要があります。
2026年5月上旬の更新で注目すべき変更点
Microsoft Learn日本語版の該当ページでは、ページ下部に2026年5月4日更新と表示されています。また、MicrosoftDocsのGitHub履歴では、2026年5月8日に同ドキュメントを含む関連コミットが確認できます。(Microsoft Learn) 権限表そのものの実務上の注目点は、5月4日のコミットで「Agents」行が追加されたことです。(GitHub)
Agents権限の追加で何を見るべきか
追加された「Agents」領域では、メンバー ユーザーに対して、ブループリント、ブループリント プリンシパル、エージェントIDの一覧表示・プロパティ読み取り・所有対象の管理などが記載されています。一方、既定のゲスト ユーザーと制限されたゲスト ユーザーは、この領域で「None」とされています。(Microsoft Learn)
ここで注意したいのは、これを単なる表の追加として見ないことです。エージェント関連機能を利用している、または検証している組織では、次の観点で棚卸しが必要です。
| 確認項目 | 見落としやすいポイント | 実務での対応 |
|---|---|---|
| エージェント関連オブジェクトの所有者 | 所有者になっている一般ユーザーが、資格情報や割り当てを管理できる可能性がある | 所有者を定期レビューし、退職者・異動者・不要な所有者を削除する |
| アプリ登録・サービス プリンシパルとの関係 | エージェント関連機能がアプリ権限や資格情報と結び付く場合がある | アプリ所有者、証明書、シークレット、有効期限、APIアクセス許可を同時に確認する |
| ゲスト利用 | Agents領域ではゲストに権限がないが、別のアプリやロール経由でアクセスできる場合がある | ゲストのロール割り当て、アプリ割り当て、グループ経由のアクセスを確認する |
影響範囲は管理者・開発者・外部ユーザー管理に及ぶ
Microsoft Entraの既定のユーザー権限は、単に「ユーザー設定」の話ではありません。影響は、ID管理、アプリ開発、ゲスト招待、監査、ヘルプデスク運用まで広がります。
管理者への影響
管理者が最初に見るべきなのは、一般ユーザーに許可している操作の範囲です。特に、アプリケーション登録、セキュリティグループ作成、Microsoft 365グループ作成、テナント作成、ゲスト招待は、組織の統制に直結します。
たとえば、管理者以外のユーザーによるテナント作成を許可している場合、ユーザーはMicrosoft Entra管理ポータルの「テナントの管理」からテナントを作成できます。公式ドキュメントでは、作成は監査ログに記録され、新しく作成されたテナントは設定や構成を継承しないと説明されています。(Microsoft Learn) これは、会社の標準ポリシーや条件付きアクセスが自動的に反映されるわけではない、という意味です。
開発者への影響
開発者にとって最も大きいのは、アプリケーション登録の制限です。ユーザーによるアプリ登録を「いいえ」にすると、一般ユーザーはアプリ登録を作成できなくなります。ただし、必要なユーザーにはアプリケーション開発者ロールを付与することで、例外的に権限を戻せます。(Microsoft Learn)
この設定をいきなり本番テナントで変更すると、次のような問題が起きやすくなります。
| 起きやすい問題 | 原因 | 事前対策 |
|---|---|---|
| 社内アプリの検証が止まる | 開発者がアプリ登録を作成できない | 開発者用グループを作り、必要な人にアプリケーション開発者ロールを付与する |
| CI/CDや検証環境の認証設定が壊れる | 既存の所有者・資格情報管理の責任者が曖昧 | アプリ所有者、証明書、シークレットを棚卸しする |
| 管理者にアプリ登録依頼が集中する | 例外申請フローがない | 申請テンプレート、承認者、命名規則、期限を決める |
アプリケーション登録やエンタープライズ アプリケーションでは、ユーザーがアプリを登録・追加すると所有者として自動的に追加され、所有者はメタデータ、要求する権限、SSO構成、ユーザー割り当てなどを管理できます。(Microsoft Learn) そのため、アプリ登録を許可する場合でも、所有者レビューと資格情報レビューは必須です。
外部ユーザー管理への影響
ゲストアクセスの設定は、社外との共同作業に直接影響します。Microsoft Entra External IDの外部コラボレーション設定では、ゲストがディレクトリ内で何を見られるか、誰がゲストを招待できるか、セルフサービスサインアップを許可するか、特定ドメインを許可・ブロックするかを構成できます。(Microsoft Learn)
特に注意すべきなのは、ゲストアクセスを最も制限しても、Microsoft Teamsなど一部のMicrosoft 365サービスでは参加済みグループへのアクセスが完全には禁止されない場合がある点です。(Microsoft Learn) ゲスト制限を強める場合は、Teams、SharePoint、社内アプリ、Power BIなど、実際の利用シナリオでテストしてから展開するべきです。
管理者が優先して確認すべき設定
Microsoft Entraの既定ユーザー権限を見直すときは、すべてを一度に変更するのではなく、業務影響が大きい順に確認します。
| 確認項目 | リスク | 推奨される判断基準 |
|---|---|---|
| ユーザーによるアプリケーション登録 | 不要なアプリ、未管理の資格情報、過剰なAPIアクセス許可が増える | 一般ユーザーは不可にし、必要な開発者にロールで付与する |
| セキュリティグループ作成 | 用途不明のグループが増え、アクセス管理が複雑化する | 作成権限を限定し、命名規則・所有者・棚卸しをセットで運用する |
| Microsoft 365グループ作成 | TeamsやSharePointサイトの乱立につながる | 全社許可ではなく、必要なユーザーまたはグループに限定する |
| Microsoft Entra管理ポータルへのアクセス制限 | 設定を有効にしてもセキュリティ制御にはならない | 「見に行きにくくする」用途に限定し、本格制御は条件付きアクセスを使う |
| 管理者以外のテナント作成 | 組織ポリシーを継承しないテナントが作成される | 原則制限し、例外はテナント作成者ロールで管理する |
| 所有デバイスのBitLockerキー回復 | ユーザーが自分で回復キーを取得できる | ヘルプデスク負荷と情報保護要件を比較して判断する |
| 他のユーザー情報の読み取り | ディレクトリ情報の参照範囲が広い | 特別な事情がない限り安易に無効化しない。Teamsなどへの影響を検証する |
| ゲストアクセス制限 | 外部ユーザーが不要な情報を参照する可能性 | 委託先・一時利用者は最も制限された設定を基本にする |
| ゲスト招待 | 社外ユーザー追加が統制されない | 招待可能なロールを限定し、Guest Inviterの利用を検討する |
| ユーザー同意 | 悪意あるアプリへの同意リスクがある | 検証済み発行元や低リスク権限に限定し、必要に応じて管理者同意ワークフローを使う |
Microsoftは、管理ポータルへのアクセス制限について「一般的にアクセスされる管理センターページへのアクセスを制限するが、セキュリティ対策ではない」と明記しています。PowerShell、Microsoft Graph API、Visual Studioなどによるプログラム的アクセスもブロックしません。(Microsoft Learn) 本格的にAzure管理エンドポイントへの非管理者アクセスを制御したい場合は、Windows Azure Service Management APIを対象にした条件付きアクセスの利用を検討します。(Microsoft Learn)
Microsoft GraphとPowerShellで現状を確認する
ポータル画面だけでなく、Microsoft GraphやPowerShellで現在の設定を取得しておくと、変更前後の比較や監査に使えます。Microsoft GraphのdefaultUserRolePermissionsには、既定のユーザー ロールに含まれるカスタマイズ可能な権限が定義されています。(Microsoft Learn)
確認用の例は次の通りです。
Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes "Policy.Read.All"
$policy = Get-MgPolicyAuthorizationPolicy -Property DefaultUserRolePermissions
$policy.DefaultUserRolePermissions | Format-ListGet-MgPolicyAuthorizationPolicyはauthorizationPolicyオブジェクトのプロパティを取得するコマンドレットで、読み取りにはPolicy.Read.Allが最小権限として示されています。(Microsoft Learn) Graph APIで確認する場合は、GET /policies/authorizationPolicyでauthorizationPolicyを取得できます。(Microsoft Learn)
設定を更新する場合は、現在の値を必ず取得してから変更します。Microsoft Graphの更新APIでは、要求本文には更新するプロパティのみを指定し、含まれない既存プロパティは以前の値を維持するか、他の変更に基づいて再計算されると説明されています。(Microsoft Learn) 特にユーザー同意設定では、既存のpermissionGrantPoliciesAssignedを意図せず削除しないよう、現在のauthorizationPolicyを確認してから更新することが重要です。(Microsoft Learn)
ユーザー同意とアプリ権限もセットで見直す
Microsoft Entraの既定ユーザー権限を見直すとき、アプリ登録だけを止めても十分ではありません。ユーザーがアプリケーションに同意できる範囲も確認する必要があります。
Microsoftの公式情報では、既定ではすべてのユーザーが、管理者の同意を必要としないアクセス許可のアプリケーションに同意できると説明されています。悪意あるアプリによる組織データへのアクセス許可リスクを下げるには、検証済みの発行元によって発行されたアプリに対してのみユーザー同意を許可することが推奨されています。(Microsoft Learn)
実務では、次のように分けると判断しやすくなります。
| 組織の状況 | ユーザー同意の考え方 |
|---|---|
| 小規模でIT管理者が少ない | 原則としてユーザー同意を制限し、必要なアプリは管理者が確認して許可する |
| SaaS利用が多い中堅企業 | 検証済み発行元・低リスク権限に限定し、管理者同意ワークフローを整備する |
| 開発部門が多い企業 | 開発者向けの例外ルールを設け、アプリ登録・同意・所有者レビューをプロセス化する |
| 規制業種・高セキュリティ環境 | ユーザー同意を厳格に制限し、管理者同意・アプリ審査・ログ監視を必須にする |
移行・展開で失敗しやすいポイント
Microsoft Entraの既定ユーザー権限を強化する場合、セキュリティだけを見て一気に制限すると、現場の業務や開発が止まることがあります。特に次の失敗はよく起きます。
| 失敗パターン | 何が起きるか | 回避策 |
|---|---|---|
| アプリ登録を全員禁止にした | 開発者が検証用アプリを作成できず、管理者への依頼が急増する | 開発者ロール、申請フロー、開発用テナントを事前に用意する |
| 管理ポータル制限をセキュリティ対策と誤解した | Graph APIやPowerShell経由のアクセスが残る | 条件付きアクセス、ロール管理、Graph権限管理を併用する |
AllowedToReadOtherUsersを安易に無効化した | Teamsや社内アプリのユーザー検索、人物情報参照に影響する可能性がある | テストユーザーでMicrosoft 365、業務アプリ、Graph連携を検証する |
| ゲストアクセスを厳しくしすぎた | 外部共同作業やTeams参加に支障が出る | ゲスト種別ごとにポリシーを分け、代表的な共同作業シナリオで確認する |
| 所有者レビューをしなかった | 退職者や異動者がアプリ・グループ・エージェント関連オブジェクトの所有者に残る | 月次または四半期ごとに所有者を棚卸しする |
| テナント作成制限を後回しにした | 標準ポリシーを継承しないテナントが作られる | 管理者以外のテナント作成を制限し、例外はロールで管理する |
推奨される運用モデル
多くの組織では、次のような方針から始めるとバランスを取りやすくなります。
| 領域 | 推奨方針 |
|---|---|
| 一般ユーザー | 必要最小限の既定権限にし、アプリ登録・グループ作成・テナント作成は原則制限する |
| 開発者 | アプリケーション開発者ロールや専用グループで例外管理する |
| ゲスト | 最小権限を基本にし、招待可能なユーザーを限定する |
| アプリ同意 | 検証済み発行元や低リスク権限に限定し、管理者同意ワークフローを整える |
| 所有オブジェクト | アプリ、エンタープライズ アプリ、グループ、エージェント関連オブジェクトの所有者を定期レビューする |
| 変更管理 | 変更前にGraphで設定を取得し、テストユーザーで業務影響を検証してから段階展開する |
セキュリティを強める目的であっても、すべてのユーザーに一律で制限をかけるのは得策ではありません。業務部門、開発部門、外部協力会社で必要な操作は異なります。重要なのは、「誰に何を許可するか」を既定権限に任せず、ロール、グループ、申請フロー、監査ログで管理することです。
まず実施すべき確認手順
最初に、現在のauthorizationPolicyとdefaultUserRolePermissionsを取得し、アプリ登録、グループ作成、テナント作成、ユーザー同意の状態を記録します。次に、一般ユーザー、開発者、ゲスト、制限付きゲストのテストアカウントで、Microsoft Entra管理センター、Teams、SharePoint、社内アプリ、Graph連携アプリの動作を確認します。
そのうえで、不要なアプリ登録とテナント作成を制限し、ゲスト招待とゲスト参照範囲を見直します。開発者には例外ロールを付与し、アプリ所有者やエージェント関連オブジェクトの所有者を定期レビューの対象にします。
Microsoft Entraの既定ユーザー権限は、初期状態の利便性とセキュリティ統制のバランスを決める設定です。読者が次に取るべき行動は明確です。まず現在の設定を棚卸しし、業務に必要な例外を整理したうえで、アプリ登録・グループ作成・テナント作成・ゲストアクセス・ユーザー同意を段階的に見直してください。
コメント