Microsoft Entra ID（旧Azure AD）でユーザーとグループの管理にひととおり慣れると、次に必ずぶつかるのが「じゃあ、その先どうやって安全に運用するの？」という壁です。ログインさせるだけなら簡単。でも実務では「怪しいアクセスは弾きたい」「パスワードやシークレットを持ち歩きたくない」「強すぎる管理者権限を常時付けっぱなしにしたくない」といった、一歩上の要求が出てきます。
ところが、この領域のMicrosoft Learnを開くと、条件付きアクセス・マネージドID・PIMといった聞き慣れない名前がいきなり並んでいて、しかもライセンス（P1/P2）の話まで絡んでくる。私自身、Azureの資格勉強で最初にここへ来たとき、「名前は覚えたけど、結局それぞれ何が嬉しいのか腹落ちしない」という状態でしばらく足踏みしました。
「条件付きアクセス、マネージドID、PIM……名前は資格の勉強で出てきたけど、それぞれ何が便利で、どれにお金がかかるの？」
この記事では、初心者が「次に進む」ときに知っておきたい実務の要所として、条件付きアクセス（特定条件でMFAを要求する）・マネージドID（シークレット無しでAzureリソースへ認証する）・PIM（特権を必要なときだけ時間制限付きで持つ）の3つを、概念と「なぜ嬉しいか」を厚めに、手順は入口まで噛み砕いて解説します。あわせて、初心者が必ず引っかかるどのライセンス（無料／P1／P2）で使えるのかも各所で明記します。読み終わるころには、この3機能の使いどころと違いが自分の言葉で説明できるようになります。
なお、Entra IDそのものの全体像があやふやな方は、先に Microsoft Entra IDの基本機能と活用方法 に目を通しておくと、この記事の位置づけがはっきりします。本記事はその中の「実務でよく使う一歩上の機能」を深掘りする子記事です。ユーザー・グループの土台がまだの方は、先に ユーザー・グループ管理の記事 から入ると流れがつながります。
条件付きアクセス：状況に応じてアクセスの許可を変える
まず1つ目、条件付きアクセス（Conditional Access）です。前回のユーザー・グループ管理の記事の最後で「動的グループとP1はセットで出てくる」「アクセス制御は別記事で」と予告した、その本命がこれです。
ひとことで言うと、条件付きアクセスは「誰が・どこから・何を使って・何にアクセスしようとしているか」に応じて、通す／MFAを要求する／ブロックする、を自動で判断する仕組みです。ビルの入口に立つ、賢い警備員をイメージしてください。社員証（ユーザー）を持っているだけで無条件に通すのではなく、「社内から来た人はそのまま通す」「社外から来た人には追加で本人確認（MFA）を求める」「管理不明の端末は入れない」——そんなふうに、状況を見て対応を変えるわけです。
「もし〜なら、〜する」で覚えると簡単
条件付きアクセスのポリシーは、構造としては非常にシンプルで、「割り当て（条件）」＋「アクセス制御（結果）」の組み合わせでしかありません。プログラミングの if 文とまったく同じ発想です。
- 割り当て（もし〜なら）：対象ユーザー／グループ、対象アプリ（例：Azureポータル）、条件（場所・デバイス・サインインリスクなど）を指定する
- アクセス制御（〜する）：アクセスをブロックする／許可するがMFAを要求する／管理された端末のみ許可する、などを指定する
たとえば「もし 管理者グループの人が 信頼できる社内ネットワーク以外から Azureポータルにアクセスしてきた なら、MFAを要求する」。これを日本語で言葉にできれば、ポリシーはもう半分できたようなものです。あとはEntra管理センターの「保護」→「条件付きアクセス」→「新しいポリシー」で、その日本語をGUIの各欄に置き換えていくだけです。
迷ったら「もし〜なら、〜する」を声に出して言ってみる。その文がそのまま画面の設定項目に対応します。
最初のつまずき：自分をロックアウトする
条件付きアクセスで初心者が最もやりがちな事故が、ポリシーで自分自身を締め出す（ロックアウト）ことです。「すべてのユーザーに厳しい条件を適用」といったポリシーをいきなり有効にすると、その中に管理者である自分も含まれてしまい、次のサインインで自分がログインできなくなる、という笑えない事態が起きます。
これを防ぐための定石が2つあります。1つは、ポリシーをいきなり「オン」にせず、まず「レポート専用モード」で作ること。これは実際にはブロックせず、「もしこのポリシーが有効だったら誰が影響を受けたか」をログで確認できるモードで、いわば予行演習です。もう1つは、緊急アクセス用の管理者アカウント（ブレークグラスアカウント）を作り、そのアカウントだけは条件付きアクセスの対象から除外しておくこと。何かあったときの「非常口」を必ず1つ確保しておく、という発想です。
ライセンス：条件付きアクセスは「P1」
ここが実務上とても大事なので明記します。条件付きアクセスはMicrosoft Entra ID P1以上で使える有償機能です。無料版のEntra IDには条件付きアクセスのポリシー作成機能はありません。前回の記事で触れた動的グループもP1でしたが、両者は同じP1ライセンスに含まれており、「動的グループで対象者を自動的にまとめ、そのグループを条件付きアクセスの対象にする」という合わせ技が定番、というのはこういう理由です。学習で試すだけなら、期間限定の評価版テナントでP1機能を触れます。
なお、MFA（多要素認証）そのものはセキュリティ既定値群（Security Defaults）という形で無料版でも一律に有効化できますが、「この条件のときだけMFA」といったきめ細かい制御ができるのは条件付きアクセス＝P1からだ、と整理しておくと混乱しません。詳しい前提はMicrosoft Learnの 条件付きアクセスの概要 でも確認できます。
マネージドID：シークレットを持たずにAzureリソースへ認証する
2つ目はマネージドID（Managed Identity）です。こちらは人間のログインの話ではなく、アプリやサービス同士が互いに認証するときの機能で、開発をする人にとってはとくにありがたい存在です。
「シークレットの持ち歩き」という悩みを消す
たとえば、Azure上で動くアプリ（App Service上のWebアプリなど）から、別のリソースであるKey VaultやStorage、データベースに接続したいとします。ふつうに考えると、接続用のパスワードや接続文字列、APIキーといったシークレットをアプリの設定に書いておく必要があります。ところがこれ、実務では悩みの種です。シークレットが漏れれば即アウトですし、定期的にローテーション（差し替え）しなければならず、うっかりコードにベタ書きしてGitに上げてしまう事故も後を絶ちません。
マネージドIDは、この「シークレットを人間が管理する」という営みそのものをなくす機能です。仕組みをたとえるなら、社員が取引先ビルに入るのに毎回「合鍵」を持ち歩くのをやめて、ビルの受付（Azure）が本人確認をして自動で通してくれるようにするイメージ。アプリには「私はこのリソースのマネージドIDです」という身分がAzure側から自動で付与され、パスワードのやり取りなしに他のAzureリソースへ認証できます。裏側でトークンの発行や更新はAzureが勝手にやってくれるので、開発者はシークレットの存在を意識しなくて済みます。
システム割り当てとユーザー割り当ての2種類
マネージドIDには2種類あり、ここも最初に迷うところなので違いを押さえておきましょう。
- システム割り当て（System-assigned）：特定のリソース（例：あるApp Service）に1対1で紐づくID。そのリソースを消すと、IDも一緒に消える。手軽で、まずはこちら。
- ユーザー割り当て（User-assigned）：独立した部品としてIDを先に作り、複数のリソースで共有できる。「同じ権限を持つアプリが何個もある」ようなときに便利。
使い始めはシンプルなシステム割り当てで十分です。App Serviceなら「設定」→「ID」タブでシステム割り当てを「オン」にするだけで、そのアプリ専用のマネージドIDが1つ生まれます。あとは、接続先のリソース（例：Key Vault）側で、そのIDに対して必要なロール（アクセス権）をRBACで割り当てる——ここで前回学んだ「権限はグループやIDに付ける」考え方がそのまま生きてきます。
ライセンス：マネージドIDは「無料」
うれしいことに、マネージドID自体の利用に追加料金はかかりません。P1やP2は不要で、Azureサブスクリプションがあれば無料で使えます（接続先リソースの利用料は当然かかりますが、マネージドIDという機能自体が有償なわけではない、という意味です）。3機能の中では最もハードルが低く、それでいて開発の安全性を大きく上げてくれるので、Azure上でアプリを作るなら真っ先に取り入れたい機能です。概要はMicrosoft Learnの マネージドIDの概要 にまとまっています。
なお、外部SaaSなどにアプリを登録してSSO連携する「アプリの登録」は別テーマなので、そちらに踏み込みたい方は アプリの登録の記事 を参照してください。マネージドIDは「Azureリソース同士」の認証に絞って理解しておけば混乱しません。
PIM：特権は「常時」ではなく「必要なときだけ」持つ
3つ目はPrivileged Identity Management（PIM／特権ID管理）です。3機能の中では最も上級寄りですが、考え方はとても分かりやすく、セキュリティの世界で近年とても重視されている発想を体現しています。
「強い権限を常時付けっぱなし」の危うさ
グローバル管理者のような強力なロールは、テナント全体をどうにでもできる強い権限です。便利だからと、担当者に常時付けたままにしがちですが、これはリスクの塊です。もしそのアカウントが乗っ取られれば、攻撃者はいつでもフル権限を使えてしまう。使う頻度は月に数回なのに、権限だけは24時間365日オンになっている——この「使っていない時間の権限」がまるごと攻撃対象になるわけです。
PIMは、この状態を「必要なときだけ、時間を区切って権限を持つ」形に変える機能です。たとえるなら、金庫の鍵を全員に配りっぱなしにするのをやめて、使うたびに受付で申請して鍵を借り、用が済んだら自動で返却される運用にするイメージです。
キーワードは「適格（Eligible）」と「アクティブ化」
PIMを理解するうえで外せない言葉が2つあります。
- 適格割り当て（Eligible）：「その人はこのロールを使う資格があるが、今この瞬間は権限がオフ」の状態。いわば「鍵を借りる資格がある人リスト」に載っている状態。
- アクティブ化（Activation）：必要になったときに本人が申請し、権限を一時的にオンにする操作。多くの場合、理由の入力やMFA、承認者の許可が求められ、指定した時間（例：8時間）が過ぎると自動でオフに戻る。
つまりPIMを入れると、管理者ロールは「常時オン」ではなく「ふだんは適格（オフ）、作業するときだけアクティブ化して時間限定でオン」という運用になります。これにより、乗っ取られても権限がオフの時間帯なら被害を防げますし、「いつ・誰が・なぜ特権を使ったか」がすべてログに残るため、監査の観点でも非常に強くなります。この「必要最小限の権限を必要な時だけ」という考え方は、ゼロトラストと呼ばれる現代のセキュリティ設計の中核でもあります。
「適格＝資格はあるが今はオフ」「アクティブ化＝時間限定でオンにする」。この2語だけ押さえれば、PIMの試験問題はだいたい解けます。
入口の操作とライセンス：PIMは「P2」
設定の入口は、Entra管理センターの「ID ガバナンス」→「Privileged Identity Management」です。ここで対象のロール（例：グローバル管理者）を選び、担当者を「適格」割り当てとして登録し、アクティブ化の最大時間やMFA必須・承認要否といったポリシーを決めます。実際に使う側は、必要になったら「マイロール」からロールをアクティブ化して作業する、という流れです。
そしてライセンスです。PIMはMicrosoft Entra ID P2（3機能の中で唯一のP2）で提供される機能です。条件付きアクセス（P1）よりさらに上位のライセンスが必要、と覚えてください。整理すると次のようになります。
- 無料：マネージドID（Azureリソース同士の認証）
- P1：条件付きアクセス／動的グループ
- P2：PIM（特権の適格割り当てとアクティブ化）
資格試験でも実務でも、この「どの機能がどのライセンス層か」は頻出かつ間違えやすいポイントなので、上の3行はそのまま暗記して損はありません。PIMの詳細な前提や手順はMicrosoft Learnの PIMの構成ガイド で確認できます。
まとめ
この記事では、ユーザー・グループ管理の「次」に来る、Entra ID実務の要所3つを入口まで見てきました。最後に要点を振り返ります。
- 条件付きアクセス（P1）：「もし〜なら、〜する」でアクセスを制御する。特定条件のときだけMFAを要求できる。まずレポート専用モードで試し、緊急用アカウントを除外してロックアウトを防ぐ。
- マネージドID（無料）：シークレットを持たずにAzureリソース同士を認証する。まずはシステム割り当てから。接続先ではRBACで権限を付ける。
- PIM（P2）：特権を「常時オン」から「適格＝ふだんオフ、アクティブ化で時間限定オン」へ。乗っ取り被害を抑え、監査にも強い。
3つとも、根っこにあるのは「必要な人に、必要なときだけ、必要な分の権限を渡す」という同じ思想です。ここが腹落ちすると、Entra ID全体の設計が一本の筋で見えてきます。まずは無料で試せるマネージドIDから手を動かし、評価版テナントでP1・P2の機能を触ってみるのがおすすめです。
あわせて読みたい：
