Microsoft Entra ID（旧Azure AD）テナントで「管理者ロールも特権グループも付与していない標準ユーザーが、Azure PortalやIntune管理センターにサインインできてしまう」と不安になることがあります。本記事では、それが“想定動作”である理由と、確実にアクセスを止める現実的な方法、ディレクトリ可視性の考え方をわかりやすく整理します。
標準ユーザーがAzure Portal／Intune管理センターに入れてしまう現象とは
グローバル管理者（Global Administrator）の視点で見ると、次の挙動が起きると「権限設定が漏れているのでは？」と疑いたくなります。
- 管理者ロールを一切付与していない“標準ユーザー”が Azure Portal（portal.azure.com） にサインインできる
- Microsoft Intune 管理センター にもサインインできる
- さらに、ディレクトリ内の他ユーザー情報（ユーザー一覧など）が閲覧できる
- 検証で新規ユーザー（ロール／ライセンス／特別なグループなし）を作っても同様
結論から言うと、多くのテナントでこの挙動は「設定ミス」ではなく、“ポータルに入れること”と“管理操作できること”が別という前提で設計された仕様に沿ったものです。
結論：標準ユーザーがポータルにサインインできるのは基本的に“仕様”
Azure PortalやIntune管理センターは、管理者だけの“完全に閉じた画面”ではなく、Entra ID（Azure AD）にサインインできる組織ユーザーが到達できる入口として提供されている側面があります。
ただし、ここで重要なのは「入口に入れる」＝「管理できる」ではないという点です。標準ユーザーは、通常以下のように閲覧や限定的な自己サービスの範囲に留まり、テナント全体を変える操作はできません（できてしまう場合は、ロール付与・グループ経由の権限・カスタムロールなどを疑うべきです）。
| 観点 | 標準ユーザーで起こりがち | 管理者ロールが必要 |
|---|---|---|
| Azure Portalにサインイン | 可能（画面表示はされる） | 不要 |
| Intune管理センターにサインイン | 可能（ただし機能は制限されがち） | 不要 |
| ディレクトリ内ユーザーの検索・基本情報の参照 | 可能なことが多い | 不要（テナント設定に依存） |
| ユーザーの作成・削除、ロール付与、ポリシー変更 | 不可 | 必要 |
| Intuneの構成プロファイル／コンプライアンスポリシー編集 | 不可 | 必要 |
| Azureサブスクリプションのリソース作成（VMなど） | 不可（RBACで権限が無い） | 必要（適切なRBAC） |
「画面が見える」こと自体は珍しくありません。問題は、“見せたくない入口”を、どう閉じるかです。
なぜ他ユーザー情報（ディレクトリ）が見えてしまうのか
標準ユーザーがユーザー一覧やプロフィールをある程度見られるのは、多くの組織で次のような業務要件があるためです。
- Outlookで宛先候補を出す（連絡先検索）
- Teamsで相手を検索してチャット・会議招待する
- 社内の人名検索（表示名、部署、役職、メールアドレスなど）
つまり、ディレクトリ情報の一定の公開は、コラボレーションの利便性を支える土台になっています。そのため、「標準ユーザーは誰も見えないようにする」という方向に極端に振ると、メール・Teams・各種アプリのユーザー検索が崩れやすく、結果として現場の生産性が落ちることがあります。
このジレンマがあるため、実務では“ディレクトリを完全に隠す”よりも、“管理ポータルへの入口を閉じる”ほうが現実的で効果が高いケースが多いです。
まず整理したい：対策は「入口」「権限」「可視性」の三層で考える
今回の相談は、ひとことで言うと「標準ユーザーに管理画面を見せたくない」「他ユーザー一覧を見せたくない」です。これを一発で解決する魔法のスイッチはあまりなく、次の三層で設計すると判断がしやすくなります。
| 層 | 狙い | 主な手段 | 効果 | 注意点 |
|---|---|---|---|---|
| 入口（アクセス） | 管理ポータルに入れない | 条件付きアクセスでブロック、ポータルアクセス制限 | 即効性が高い | 対象アプリの選定を誤ると業務アプリまで巻き込む |
| 権限（操作） | 管理操作をできなくする | ロール最小化、RBAC、PIM | 本質的な安全性向上 | 「入口が見える」こと自体は残ることがある |
| 可視性（表示） | ユーザー一覧などを見せない | ユーザー設定（読み取り制限）、表示/アドレス帳設計 | 情報露出の抑制 | Teams/Outlookの検索や連携に影響しやすい |
多くの組織で最初に効果を出しやすいのは入口（アクセス）です。次に、運用の成熟度に合わせて権限（操作）と可視性（表示）を詰めます。
対策：標準ユーザーをAzure／Intune管理ポータルにアクセスさせない方法
方法A：Entra ID（ディレクトリ）側の設定でポータルアクセスを制限する
テナント設定（ユーザー設定）側に、標準ユーザーの管理ポータルへのアクセスを制御する項目が用意されていることがあります。これを有効にすると、管理者以外のユーザーが特定の管理センターに到達しづらくなります。
ただし、現場では次の理由で「これだけでは足りない」「期待通りに止まらない」ことがあります。
- UIや設定項目の名称・場所が更新で変わる
- “完全ブロック”ではなく“管理機能の抑制”に近い挙動になるケースがある
- ポータルや管理センターが複数あり、入口が一つではない
そのため、確実に“アクセス不可”にしたい場合は、次の条件付きアクセスがより実務的です。
方法B：条件付きアクセス（Conditional Access）で管理ポータルをブロックする（推奨）
「標準ユーザーは管理ポータルに入れない」「管理者だけは入れる」を最短で実現しやすいのが、条件付きアクセス（CA）によるブロックです。ポイントは、対象クラウドアプリを正しく選び、除外（例外）を適切に設けることです。
狙うべきクラウドアプリ（例）
- Microsoft Azure Management（Azure Portal／Azure Resource Manager相当）
- Microsoft Intune（Intune管理センター相当）
これらを対象に、標準ユーザーのアクセスをブロックし、管理者・運用担当のグループのみ例外として許可します。
推奨構成の全体像
| 項目 | 推奨例 | 意図 |
|---|---|---|
| 対象ユーザー | すべてのユーザー | 抜け漏れを防ぐ |
| 除外ユーザー | 管理者・運用担当のグループ、緊急用アカウント | 運用継続と事故防止 |
| 対象クラウドアプリ | Microsoft Azure Management / Microsoft Intune | 管理ポータルの入口を狙い撃ち |
| アクセス制御 | アクセスをブロック | 標準ユーザーは到達不可にする |
実務での手順（失敗しにくい進め方）
WordPressの記事としてもそのまま使えるよう、実装の流れを“作業チェックリスト”としてまとめます。
- 許可する人のグループを作る
例：SG-Portal-Admins（Azure Portal／Intune管理センターへのアクセスを許可したい管理者・運用担当だけ入れる） - 緊急用（ブレークグラス）アカウントを準備する
CAの設定ミスで管理者が全員締め出される事故を防ぐため、普段使わないが確実にログインできるアカウントを用意し、CAポリシーから除外します。 - 条件付きアクセスで「ブロック」ポリシーを作る
対象：すべてのユーザー（除外：SG-Portal-Admins と緊急用アカウント）
アプリ：Microsoft Azure Management（必要に応じて Microsoft Intune も追加）
制御：アクセスをブロック - 最初は影響を見える化してから本番適用する
いきなり有効化せず、テストユーザーでサインイン確認を行い、想定どおりブロックされるか・管理者は入れるかを検証します。 - サインインログで監視する
ブロックされたサインインが想定通りか、例外ユーザーに漏れがないかを定期的に確認します。
よくある設計の落とし穴
- 「すべてのクラウドアプリ」をブロック対象にしない
管理ポータルだけ止めたいのに、業務アプリ（Outlook、Teams、SharePointなど）まで巻き込む事故につながります。あくまで Microsoft Azure Management と Microsoft Intune など、狙う入口を絞ります。 - Intuneの“管理センター”と“デバイス登録”は別物として扱う
端末登録（Enrollment）に関わるアプリまでブロックしてしまうと、BYODや新規PC展開で詰みます。ポリシーの対象アプリ選定は慎重に行います。 - 管理者はPIM（特権ID管理）と組み合わせる
常時特権ロールを持たせるより、必要な時だけ昇格する運用にすることで、万一アカウントが侵害された際の被害面積を小さくできます。
ポイント：「標準ユーザーを管理ポータルに入れない」を最短で実現したいなら、条件付きアクセスで Microsoft Azure Management と Microsoft Intune をブロックし、管理者グループだけ除外する構成が現実的です。
ディレクトリ（ユーザー一覧など）を非管理者に見せないための考え方
「標準ユーザーが他のユーザー情報を閲覧できる」点は、セキュリティ観点で気になります。特に、ユーザー一覧やメールアドレスが分かると、社内を装ったフィッシングの精度が上がるためです。
一方で、前述のとおり業務アプリはディレクトリ参照に依存します。そこで、ベストプラクティスとしては“目的別に、制限の強さを調整する”のが堅実です。
ベストプラクティス：最初に「管理ポータルの入口」を閉じる
ディレクトリ情報の露出が気になる場合でも、まずはAzure Portal／Intune管理センターといった「管理者向け入口」を閉じるのが効果的です。ここを閉じるだけで、標準ユーザーが“わざわざ管理画面に入り、ユーザー一覧を眺める”行為を大きく減らせます。
また、標準ユーザーが日常的にアクセスする必要があるのは、通常は以下のようなエンドユーザー向けページです。
- アカウント情報の確認・更新（プロフィール、パスワード変更など）
- MFA（多要素認証）の登録・更新
- セルフサービスパスワードリセット（SSPR）
- 自分のデバイスやサインイン履歴の確認
これらは管理ポータルとは別の導線で提供されることが多く、管理ポータルをブロックしても業務影響を抑えやすいという利点があります。
「ディレクトリ閲覧権限そのもの」を強く絞る場合の注意点
非管理者にユーザー一覧を極力見せたくない場合、テナントのユーザー設定（ユーザーが他ユーザー情報を読み取れるか、管理センターへアクセスできるか等）を見直すという選択肢があります。
ただし、強い制限は次のような影響が出やすいことを理解した上で判断するのが安全です。
| 制限を強くした場合に起きがちな影響 | 現場で困ること | 回避策の例 |
|---|---|---|
| Teams／Outlookの人名検索が弱くなる | 宛先が出ない、チャット相手を探せない | 制限を最小限にする／対象ユーザーを限定する |
| グループベースの運用が複雑化 | 申請・承認やメンバー管理が回らない | 管理者・運用担当だけが管理する設計へ寄せる |
| アプリ連携が想定外に失敗 | 名寄せ・ユーザー参照ができずエラー | 事前検証、段階的適用 |
そのため多くの組織では、次の落としどころにします。
- 管理ポータル（Azure Portal／Intune管理センター）へのアクセスはCAで閉じる
- ディレクトリ可視性は「業務が成立する最低限」は維持する
- どうしても見せたくない対象（役員、特権ID、VIP等）だけを個別に扱う
「見せたくないユーザー」だけを守る実務的アプローチ
全員を不可視にするのではなく、特にリスクが高いアカウントだけ露出を抑えるのは現実的です。例えば、次のような対象です。
- ブレークグラス（緊急用）アカウント
- 特権管理に使う管理者アカウント（普段ログインしない）
- 役員・重要部門・特定プロジェクトのメンバー
この場合は、メール/Teamsの運用要件も踏まえつつ、対象者の公開情報（表示名・部署・電話番号など）を必要最小限にするといった調整が取りやすくなります。
「本当に標準ユーザーなのか？」を確認するチェックポイント
今回のように「新規ユーザーでも同じ」とのことなので仕様の可能性が高い一方、念のため以下は確認しておくと安心です。運用で“いつの間にか権限が付いていた”は珍しくありません。
| 確認ポイント | 見るべき観点 | よくある見落とし |
|---|---|---|
| ロールの直接付与 | Entra IDのロール（管理者ロール）が付与されていないか | ヘルプデスク系ロールが想定外に強い権限を持つことがある |
| グループ経由のロール | グループにロールが割り当てられ、ユーザーがそのグループに入っていないか | 動的グループで自動加入している |
| IntuneのRBAC | Intuneロール（読み取りなど）が付いていないか | 検証用グループに過去付与したロールが残っている |
| Azure RBAC（サブスクリプション） | サブスクリプション／管理グループ／リソースグループで権限がないか | 「共同作成者」などが付いているとAzureリソース操作が可能になる |
| ゲスト／外部ユーザー設定 | ゲストの権限制御が想定と一致しているか | 外部共有の設定と混同している |
おすすめの最終形：セキュリティと運用を両立するテンプレ構成
「標準ユーザーに管理ポータルは見せない」「管理者は必要なときだけ安全に使う」「業務アプリは壊さない」を狙うなら、次の形がわかりやすく、運用にも乗りやすいです。
推奨テンプレ
- CAで Azure Portal（Microsoft Azure Management）をブロック（除外：管理者グループ＋緊急用）
- CAで Intune管理センター（Microsoft Intune）をブロック（除外：Intune運用グループ＋緊急用）
- 管理者ロールは常時付与ではなく、可能ならPIMで必要時だけ昇格
- ディレクトリ可視性は、まずは現状維持しつつ、必要に応じて“守るべき対象だけ”段階的に調整
この構成が強い理由
- 入口が閉じるため、標準ユーザーが管理画面を触る導線が消える
- 除外グループ運用で、例外管理がしやすい（退職・異動時もグループから抜くだけ）
- 業務アプリへの影響が限定的（狙うクラウドアプリを絞るため）
- 「見せない」より先に「触らせない」を実現でき、セキュリティ投資対効果が高い
FAQ：よくある質問
標準ユーザーがポータルに入れても、放置して大丈夫？
管理操作ができない限り直ちに重大インシデントになるわけではありませんが、ユーザー一覧などの情報露出が気になる場合は、条件付きアクセスで入口を閉じるのが早くて確実です。特に、標準ユーザーに管理画面が見えるだけでヘルプデスクへの問い合わせが増える組織では、運用コスト削減にもつながります。
Intune管理センターをブロックすると端末登録に影響する？
影響するかどうかは、ブロック対象に含めたクラウドアプリの選び方次第です。管理センターだけ止めたいのに、登録系のアプリまで対象にしてしまうと端末展開に影響が出ます。「管理」だけ止めるのか、「登録」も止めるのかを先に決め、対象アプリを丁寧に選びます。
ユーザー一覧を完全に見えなくしたい
可能な範囲はありますが、Teams/Outlookなど日常業務の人名検索が成り立たなくなる恐れがあります。まずは管理ポータルの入口を閉じる、次に「守るべきアカウントだけ」公開情報を絞る、という順序で進めるほうが失敗しにくいです。
まとめ
- 標準ユーザーがAzure Portal／Intune管理センターにサインインできること自体は想定動作であるケースが多い
- 「ポータルに入れる」と「管理操作できる」は別で、ロールが無いユーザーは通常閲覧・限定的な範囲に留まる
- それでも管理ポータルを見せたくないなら、条件付きアクセスで Microsoft Azure Management／Microsoft Intune をブロックし、管理者グループのみ除外が実務的で強い
- ディレクトリ可視性を極端に絞ると業務影響が出やすいため、まずは入口（管理ポータル）を閉じるのが現実的なベストプラクティス
コメント