Microsoft Entra ID（旧Azure AD）でユーザーとグループを作れるようになると、次に必ずぶつかるのが「じゃあ、この人にどこまで操作を許すか」という話です。いわゆるアクセス制御ですね。誰に管理者権限を渡すのか、その人がいつ・どこから・何を変えたのかをどう追うのか。ここを雑にやると、あとで「気づいたら全員が全体管理者になっていた」という笑えない事態になります。
ところが、いざ公式のMicrosoft Learnを開くと、「Entraロール」と「Azureロール」がどちらも”ロール”という同じ言葉で登場して、機械翻訳まじりの説明も相まって頭がこんがらがります。私自身、学びはじめの頃にこの2つを完全に混同していて、「Azureのリソースにアクセスできない、なぜだ」と半日ハマったことがあります。原因は、付けるべきロールの種類を間違えていただけでした。
「RBACって何？EntraロールとAzureロールって何が違うの？どのログを見れば『誰が何をしたか』が分かるの？」
この記事では、Entra IDのRBAC（ロールベースアクセス制御）でのロール割り当て、初心者が最も混乱するEntraロールとAzureロールの違い、事故を防ぐ最小特権の原則、そしてサインインログ・監査ログの見方までを、公式の正確さは押さえつつ、つまずく所を日本語で噛み砕いて解説します。読み終わるころには、「誰にどのロールを、どの範囲で渡すか」を自分で判断でき、「誰が何をしたか」をログで追えるようになります。
なお、Entra IDの全体像があやふやな方は、先に Microsoft Entra IDの基本機能と活用方法 に目を通しておくと、この記事の位置づけがはっきりします。本記事はその中の「アクセス制御とログ」を深掘りする子記事です。ユーザーやグループの作り方がまだの方は、先に Entra IDのユーザー・グループ管理 を読んでおくと、この記事の「誰に権限を渡すか」がすっと入ってきます。
RBAC（ロールベースアクセス制御）でロールを割り当てる
まずRBACという言葉から。Role-Based Access Controlの略で、直訳すると「役割にもとづくアクセス制御」です。要するに、人に権限を直接ばらまくのではなく、「役割（ロール）」という束にして渡す仕組みのことです。
会社にたとえると分かりやすいです。新しく入った人に「この部屋の鍵、あの倉庫の鍵、金庫の鍵……」と鍵を1本ずつ手渡していったら、管理も回収も大変ですよね。代わりに「経理担当」という役職を与えれば、その役職に必要な鍵一式がまとめて付いてくる。この「役職＝ロール」という考え方がRBACです。異動や退職のときも、役職を付け替える／外すだけで済みます。
実際にEntraロールを割り当ててみる
操作の入り口は Microsoft Entra管理センター（entra.microsoft.com）です。左メニューの「ロールと管理者」→「すべてのロール」を開くと、あらかじめ用意された組み込みロールがずらっと並んでいます。「ユーザー管理者」「ヘルプデスク管理者」「グローバル閲覧者」など、名前を見れば役割の見当がつくものが多いはずです。
割り当ての流れはシンプルです。付けたいロール（たとえば「ユーザー管理者」）を開き、「割り当ての追加」から対象のユーザーを選ぶだけ。逆に、特定のユーザーが今どんなロールを持っているかを確認したいときは、そのユーザーを開いて「割り当てられたロール」を見ればひと目で分かります。
試しに、あるユーザーに「ユーザー管理者」を割り当ててみましょう。すると、そのユーザーは他のユーザーの作成・パスワードのリセット・プロパティ編集ができるようになります。一方で、Entra IDの設定全体をいじる権限は付いていません。「ユーザー管理に必要なことだけができる」——この”ちょうどいい狭さ”がロールの肝です。付与した直後にそのユーザーで実際にユーザー作成を試すと、ちゃんと操作が通ることが確認できます。逆に権限外の操作をしようとすると、はじかれます。
公式の手順は Microsoft Learn: ポータルでのロール割り当て にまとまっています。画面はアップデートで少しずつ変わりますが、「ロールを選ぶ→対象ユーザーを選ぶ」という骨格は同じです。
【最重要】Entraロールと Azureロール（RBAC）の違い
さて、ここが本記事の山場です。冒頭で私が半日ハマったと書いた、初心者が最もつまずくポイント。Entraには”ロール”が2種類あって、それぞれ効く範囲がまったく違うのです。名前が似ているせいで混同しますが、一度整理すれば二度と迷いません。
ざっくり言うと、こうです。
- Entraロール（ディレクトリロール）：「人・グループ・テナントの設定」を管理する権限。例＝ユーザーを作る、パスワードをリセットする、アプリを登録する、条件付きアクセスを設定する。管理する対象はEntra ID（ディレクトリ）そのもの。
- Azureロール（Azure RBAC）：「Azureのリソース」を操作する権限。例＝仮想マシンを作る・削除する、ストレージを読む、リソースグループを管理する。管理する対象はサブスクリプションの中のリソース。
建物のたとえで続けましょう。Entraロールは「社員名簿と入館証システムを管理する権限」です。誰を社員として登録するか、誰にどの入館証を発行するか、を決められる。一方Azureロールは「建物の中の各部屋の使用権」です。この会議室を予約できる、あの機材室に入れる、といった、実際の”モノ”を扱う権限ですね。名簿を管理できる人が、必ずしも全部屋に入れるわけではない——これが2つのロールが別物である理由です。
具体例で違いを噛み締めてみます。ある人にEntraの「ユーザー管理者」を付けても、その人はAzureの仮想マシンを1台も作れません。ユーザー管理はディレクトリの話であって、リソース操作（Azure RBAC）の権限は含まれていないからです。逆に、Azureの「共同作成者（Contributor）」を付けた人は仮想マシンを自由に作れますが、他人のパスワードはリセットできません。それはEntra側の権限だからです。私がハマったのはまさにこれで、「Entraで管理者ロールを付けたのにVMが作れない」と混乱していたわけです。付けるべきはAzureロールでした。
合言葉は「ID・人まわりの管理＝Entraロール、リソース・モノの操作＝Azureロール」。迷ったらこれを唱えてください。
もう一つ、地味に大事な違いが「範囲（スコープ）」です。Entraロールは基本的にテナント（ディレクトリ）全体に効きます。「ユーザー管理者」なら、そのテナントの全ユーザーが対象です。対してAzureロールはスコープを絞れるのが特徴で、「このサブスクリプション全体」「このリソースグループだけ」「この1台の仮想マシンだけ」といった具合に、効かせる範囲を階層で指定できます。範囲を狭く指定できるかどうかも、2つを見分ける手がかりになります。
操作画面も別です。EntraロールはEntra管理センターの「ロールと管理者」で、Azureロールは各リソース（またはサブスクリプション／リソースグループ）の「アクセス制御（IAM）」から割り当てます。「IAM」というタブが出てきたら、それはAzureロールの世界だと思ってください。より詳しい定義は Microsoft Learn: ロールの理解 にありますが、まずは「対象がIDかリソースか」「テナント全体か範囲を絞れるか」「操作画面はロールと管理者かIAMか」の3点で見分けられれば十分です。
最小特権の原則：全体管理者を乱発しない
ロールの割り当て方が分かると、次に効いてくるのが「どのロールを渡すか」の設計思想です。ここで絶対に押さえたいのが最小特権の原則（Least Privilege）。ひとことで言えば、「その人が仕事をするのに必要な、最小限の権限だけを渡す」という考え方です。
初心者がやりがちなのが、とりあえず全体管理者（グローバル管理者）を配ってしまうことです。全体管理者はEntra IDの何でもできる最上位ロールなので、これを付けておけば「権限が足りなくて操作できない」というエラーは確かに起きません。ラクなんです。でも、これは家の合鍵を全社員に配るようなもの。誰か一人のアカウントが乗っ取られただけで、テナント全体が丸ごと乗っ取られます。
だから実務では、「ユーザーのパスワードをリセットするのが仕事」の人にはヘルプデスク管理者、「ユーザーの作成・管理が仕事」の人にはユーザー管理者、「見るだけでいい」人にはグローバル閲覧者、というように、仕事の内容にぴったり合う狭いロールを選びます。組み込みロールは細かく用意されているので、「全体管理者じゃないとできない」というケースは、実は思っているよりずっと少ないです。
Microsoftも公式に「全体管理者は必要最小限の人数に絞る（少数の緊急用アカウントを含め、目安として数名程度）」ことを推奨しています。全員が最上位を持っている状態は、攻撃者にとって”当たり”のアカウントが増えるということ。逆に権限を絞っておけば、万一どれか一つが侵害されても被害範囲が限定されます。詳しい指針は Microsoft Learn: ロールのベストプラクティス にまとまっています。
ここで前の記事とつながります。権限は個人ではなくグループに付けるのが定石でしたね。最小特権も同じで、「ヘルプデスクグループ」に狭いロールを割り当てておき、担当者をそのグループに出し入れする、という運用にすると、「誰がどの権限を持っているか」が一覧で見渡せて、権限の付けすぎにも気づきやすくなります。狭いロール × グループ運用、これが事故を防ぐ黄金パターンです。
サインインログ・監査ログで「誰が何をしたか」を追う
ロールを適切に割り当てても、それだけでは片手落ちです。「実際に誰が、いつ、何をしたのか」を後から追えなければ、事故が起きたときに原因を突き止められません。そのための記録がログです。Entra IDには大きく2種類のログがあり、これも役割がはっきり分かれています。
場所はどちらもEntra管理センターの「ID」→「監視と正常性（Monitoring & health）」の中にあります。防犯カメラにたとえると、片方は「入退室の記録」、もう片方は「室内で何が動かされたかの記録」だとイメージすると分かりやすいです。
サインインログ：認証の成否・場所を見る
サインインログは、「誰が、いつ、どこから、どうやってログインしたか」の記録です。先ほどのたとえで言う「入退室の記録」ですね。一覧を開くと、ユーザー名・日時・ステータス（成功／失敗）・IPアドレス・場所（国・都市）・使ったアプリ・デバイス情報などが並びます。
これが効いてくる場面はたとえばこうです。ある日、あるユーザーのサインインログに「失敗」が短時間に何十件も並び、しかもアクセス元の場所が普段と違う海外になっていたら——これはパスワードを総当たりで狙われている（あるいは漏れたパスワードで侵入を試されている）強いサインです。ステータスと場所の2列を見るだけで、こうした異常にいち早く気づけます。失敗した行を開くと、なぜ失敗したのか（パスワード違い、MFA未完了など）の理由コードも確認できます。
私も運用で、深夜帯に見慣れない国からのサインイン成功を見つけてヒヤッとしたことがあります（結果的には本人の出張でしたが）。日頃からサインインログをざっと眺めるクセをつけておくと、こうした”異変の芽”を早い段階で拾えます。各項目の詳しい意味は Microsoft Learn: サインインログの概念 に整理されています。
監査ログ：ディレクトリの「変更履歴」を見る
もう一つの監査ログ（Audit logs）は、「ディレクトリの中で何が変更されたか」の記録です。「室内で何が動かされたか」のほうですね。具体的には、ユーザーが作成／削除された、グループにメンバーが追加された、ロールが割り当てられた、アプリが登録された——こうした”設定変更”の一つひとつが、いつ・誰の操作で行われたかとともに残ります。
この記事のテーマとの相性が抜群なのがここです。前半で「ロールを割り当てる」「最小特権で権限を絞る」という話をしましたが、「誰かが勝手に全体管理者ロールを付けていないか」を後から検証できるのが、まさにこの監査ログなんです。監査ログで操作の種類を「Add member to role（ロールへのメンバー追加）」で絞り込めば、いつ・誰が・誰に管理者ロールを与えたかが一覧で追えます。権限まわりの棚卸しは、この監査ログとセットで初めて回るわけです。
2つのログの覚え方はシンプルです。「ログインの話ならサインインログ、設定変更の話なら監査ログ」。認証の成否や不審なアクセスを追うのが前者、ディレクトリの変更履歴を追うのが後者です。
つまずきポイント：保存期間とライセンス
ログで一つ知っておくべき落とし穴が保存期間です。Entraのポータル上でログをさかのぼれる期間には上限があり、無料版では短め（サインインログで数日程度）、有料版でも標準では30日分までです。「半年前のあの操作を確認したい」と思っても、そのままでは残っていません。
長期保存したい場合は、ログをAzure Monitor（Log Analytics）やストレージアカウントへ転送（診断設定）しておく、というのが実務の定番です。監査対応で何ヶ月・何年分の履歴が要る現場では、まずこの転送設定を入れておきます。学習段階では「ポータルの標準保持は30日」という感覚だけ持っておき、長期保存が要るなら診断設定という選択肢がある、と覚えておけば十分です。
まとめ
この記事では、Entra IDのアクセス制御とログを、実務でつまずく順に見てきました。要点を振り返っておきます。
- RBAC：人に権限を直付けせず「ロール（役割）」の束で渡す仕組み。Entra管理センターの「ロールと管理者」から割り当てる。
- EntraロールとAzureロールの違い（最重要）：Entraロール＝ID・人・テナント設定の管理（対象はディレクトリ全体）。Azureロール＝Azureリソースの操作（範囲を絞れる／画面はIAM）。「人まわりはEntra、モノまわりはAzure」。
- 最小特権の原則：全体管理者を乱発しない。仕事に合う狭いロールを選ぶ。狭いロール × グループ運用が事故を防ぐ。
- ログ：ログインの成否・場所はサインインログ、ディレクトリの変更履歴は監査ログ。標準の保持は30日、長期保存は診断設定で転送。
ここまでできれば、「誰にどこまで権限を渡し、その操作をどう追うか」というアクセス制御の土台は固まりました。次のステップは、そもそも不正なサインインをどう防ぐか——多要素認証（MFA）や条件付きアクセスの世界です。サインインログで見つけた”異変の芽”を、そもそも入り口で止めるための仕組みですね。そちらは別記事で扱います。
あわせて読みたい：
