はじめに
こんにちは！kenkenです。最近はどんどん新しいメンバーが増えていくので、名前と顔を覚えるのに一杯一杯になっています。記憶力って、本当に年齢に従って衰えていくんですね。
前回、認証まわりの略語を整理した記事を書きました。認証の言葉が分かってくると、打ち合わせの会話が少しずつ聞き取れるようになってきます。ところが安心したのも束の間、今度は「で、この人に何をどこまで許すの？」という権限の議論が始まって、また置いていかれました。
「そこはロールで制御しよう」「管理者アカウントは分けて」「そのフォルダの権限、どうなってる？」
ログイン（認証）の壁を越えた先には、権限の言葉という二つ目の壁が待っているんですよね。
今回はその権限の議論で出てくる言葉を5つ（IAM／ACL／RBAC／ABAC／PAM）、それぞれ「何か」から自分の言葉で整理します。前回と同じく、会議やドキュメントで出てきたときの手がかりになれば、という記事です。
読む順番として、以下の「役割」で並べると見通しが良くなります。
- 管理のしくみ全体 → IAM（IDと権限の管理をまとめて指す総称）
- 許し方の設計 → ACL・RBAC・ABAC（権限をどう割り当てるか）
- 特別な権限の扱い → PAM（管理者などの特権を分けて守る）
それでは、1つずつ見ていきます。
この記事の背骨：最小権限の原則
個別の言葉に入る前に、ひとつだけ先に押さえておきたい考え方があります。最小権限の原則（Principle of Least Privilege）です。
ひとことで言えば「業務に必要な、最小限の権限だけを与える」という考え方です。NISTの用語集でも、対象は人だけでなく、その人の代わりに動くプログラムやサービスアカウントも含むと定義されています。当たり前のようですが、これが権限まわりのほぼすべての議論の土台になっています。
なぜかというと、権限は持っているだけでリスクになるからです。使っていない権限でも、そのアカウントが乗っ取られれば攻撃者に使われますし、操作ミスの影響範囲も広がります。「念のため広めに付けておく」が、そのまま事故のときの被害範囲になるわけです。
この原則を実現するための具体的な手段が、この記事で扱う言葉たちです。
- 権限を配りすぎないように、割り当て方を設計する → ACL・RBAC・ABAC
- とくに危険な管理者権限を、常時持たせない → PAM
- 使われなくなったアカウントや、不要になった権限を放置しない → アカウントライフサイクル管理（プロビジョニング／デプロビジョニング）
「なぜこんなに面倒なことをするのか」と思ったときは、この原則に立ち返ると腑に落ちます。
そのほかの前提用語
あと2つだけ、後の説明に出てくる言葉を押さえておきます。
- プロビジョニング
- アカウントのライフサイクル（作成から停止まで）を管理する作業のこと。入社でアカウントを作り、異動で所属や役割を変更し、退職で停止・削除する、というように人の動きに合わせて発生します。
- 作成時には所属や役割（グループ・ロール）もあわせて設定するため、そのアカウントで何ができるかの土台になります。Microsoftも、アプリのプロビジョニングを「ユーザーIDとロールを自動的に作成すること」と説明しています（Microsoft Learn）。
- 退職や異動でアカウントを停止・削除する側の作業は、デプロビジョニングと呼びます。退職者のアカウントが残り続けると、使われないまま権限だけが放置されることになるため、配る側と同じくらい重要な作業です。
- ロール
- 「役割」ごとに権限をまとめた束のこと。人に権限を1つずつ付けていくと、人数が増えるほど管理しきれなくなります。
- そこで「経理担当」「システム管理者」のような役割の単位でまとめておき、人にはその役割を割り当てる、という考え方が生まれました。後で出てくるRBACは、この仕組みを使った方式です。
IDと権限の管理全体：IAM
- IAM（アイアム、Identity and Access Management、ID・アクセス管理）
- 「誰が（ID）」「何にアクセスできるか」を管理する取り組み全体を指す、最上位のカテゴリにあたる言葉です。特定の製品や技術を指すのではなく、認証も、権限の割り当ても、アカウントの管理も、すべてこの中に含まれます。前回の記事で整理したIdPやSSOも、大きく見ればIAMの一部です。
- 出てくる場面：ID管理の話をひとまとめに扱うときに使われます。「ID基盤をどう設計するか」「ID管理をどう見直すか」といった、全体の方針を議論する場面で登場します。
なお、IAMは「誰のIDを扱うか」で呼び分けられることもあります。
- EIAM（Employee／Enterprise Identity and Access Management、従業員向けID管理）
- IAMのうち、社員・組織内のユーザーを対象にしたもの。単に「IAM」と言えばこちらを指していることも多く、特にCIAMと区別したいときに使われることが多い呼び名です。フルスペルはEmployee／Enterpriseの両方の説明があり、EIAMを使わず「ワークフォースID（Workforce Identity）」と呼ぶベンダーもあります。
- 統制や業務効率が重視されます。
- CIAM（Customer Identity and Access Management、顧客ID・アクセス管理）
- IAMのうち、顧客・サービス利用者を対象にしたもの。自社サービスの会員登録やログインなどが対象になります（詳しくはCIAMとは？認証基盤での役割と、パブリッククラウド付随のCIAM機能／独立CIAMの選び方）。
- 使いやすさや、大規模なユーザー数への対応が重視されます。
対象が変わると求められるものも変わるため、「社員向けの仕組みを顧客にもそのまま使えるか」は立ち止まって考えるポイントになります。
⚠️ 混同しやすい語：IAM と IdP
| 語 | 位置づけ |
|---|---|
| IAM | IDとアクセスの管理全体を指す総称。認証も権限もアカウント管理も含む |
| IdP | そのうち認証（誰かを確かめる）を担う部品 |
並列の関係ではなく、IAMという枠の中にIdPがある、という包含関係です。「IdPを入れればID管理は完了」とはならず、権限の設計やアカウントの管理は別途必要になります。
権限の割り当て方：ACL・RBAC・ABAC
権限を「どう割り当てるか」の設計方式です。古い順に、代表的な3つを押さえておきます。
- ACL（Access Control List、アクセス制御リスト）
- 「誰が何をできるか」を、対象（ファイルやフォルダ、通信経路など）ごとに一覧（リスト）で持つ、最も古典的な制御方式です。
- 出てくる場面：新しいアプリケーションの権限設計ではRBACやABACが選ばれることが多くなりましたが、ファイルサーバのフォルダ権限やネットワーク機器の通信制御では、今も日常的に使われる言葉です。既存環境の棚卸しや移行の場面でよく出会います（【Entra ID】GPO・ACL の知識は、どこまで通じるか｜前編）。
- RBAC（アールバック、Role-Based Access Control、ロールベースアクセス制御）
- 前提用語で触れた「ロール（役割ごとの権限の束）」を使う方式です。権限をロールにまとめておき、人にはロールを割り当てることでアクセスを制御します。
- 出てくる場面：「誰にどの権限を付けるか」を役職・職務ベースで整理する、権限設計の定番として登場します。
- ABAC（エーバック、Attribute-Based Access Control、属性ベースアクセス制御）
- 部署・役職・場所・時間・端末の状態といった属性の組み合わせを条件にして、アクセスの可否をルールで判定する方式です。NIST SP 800-162の定義では、人（主体）側の属性だけでなく、アクセスされる対象（オブジェクト）側の属性や環境条件もあわせて評価します。
- 出てくる場面：「営業部かつ社給端末のときだけ許可」のように、役割だけでは表現しきれない細かい条件を扱いたいときに登場します。属性や状況で判定するこの発想は、次回扱うゼロトラストの考え方にもつながっていきます（実装のイメージは業務委託・パートナーが混在する組織のABAC実装が参考になります）。
⚠️ 混同しやすい語：RBAC と ABAC
| 語 | 割り当て方 |
|---|---|
| RBAC | 役割（ロール）に権限を束ね、人にロールを割り当てる |
| ABAC | 属性の組み合わせを条件に、可否をルールで判定する |
対象ごとのリスト（ACL）から、役割で束ねる（RBAC）、属性で判定する（ABAC）へと、管理をまとめる方向に進化してきた、と捉えると3つの関係が整理できます。RBACはシンプルで運用しやすい一方、例外対応のためにロールが増えすぎて管理しきれなくなることがあります。NISTはこの状態を「ロール爆発（role explosion）」と呼んでいます。ABACは柔軟な反面、条件のルールが複雑になりがちです。どちらか一方を選ぶというより、実際には組み合わせて使われることも多く、NISTも属性とルールを足すことでRBACをより簡潔で柔軟にできると整理しています。
特別な権限の扱い：PAM
- PAM（パム、Privileged Access Management、特権アクセス管理）
- 管理者権限のような「特権」を、通常の権限と分けて厳格に管理する仕組みです。特権は通常より広い操作ができる権限なので、乗っ取られたときの被害も大きくなります。だから通常のアカウントとは別枠で、貸し出しや操作の記録などを厳しく統制します。
- 出てくる場面：「管理者アカウントを複数人で使い回している」状態の見直しや、監査対応の文脈で登場します。
⚠️ 混同しやすい語：PAM と PIM
| 語 | 意味 |
|---|---|
| PAM | 実際のアクセスをどう制御・記録するか（アクセス側） |
| PIM（ピム、Privileged Identity Management） | 誰が特権を持つか、その権限をどう適正に保つか（ID側）。常時ではなく必要な時だけ権限を有効化する（Just-In-Timeアクセス）といった考え方が中心で、実務ではMicrosoft Entra IDの機能名として見ることが多い言葉です |
多くのベンダーの説明では、PIMは「誰が特権を持つか」というID側、PAMは「実際のアクセスをどう制御・記録するか」というアクセス側とされます。ただしこの切り分けは統一されておらず、逆向きに説明するベンダーもあります。階層関係も、PAMがPIMを含むとする説明、どちらもIAMの一部として並列に置く説明、両者の線引きは曖昧になってきているとする説明が混在しています。厳密な区別を暗記するより、「特権は普通の権限と分けて管理する話をしている」と捉えるのが実用的です。
まとめ：5語のおさらい
アクセス・権限まわりでよく出る略語を、1行ずつでおさらいします。困ったときはここだけ見返せば大丈夫です。
- IAM：組織のIDとアクセスの管理を指す総称（認証・権限・アカウント管理を含む）
- ACL：対象ごとに「誰が何をできるか」を一覧で持つ、古典的な制御方式
- RBAC：役割（ロール）に権限を束ねて割り当てる方式
- ABAC：属性の組み合わせでアクセス可否を判定する方式
- PAM：管理者などの特権を、通常の権限と分けて管理する仕組み
とくに紛らわしい定番ペアだけ、区別を添えておきます。
IAM ↔ IdP ＝ 管理全体の総称 ↔ 認証を担う部品
RBAC ↔ ABAC ＝ 役割で束ねる ↔ 属性で判定する
ここが分かれば、権限まわりの会話でつまずくことはかなり減ります。
このシリーズについて
この連載では、ID・セキュリティの略語を「守る対象」で3つの棚に分けて、順に整理していきます。今回は、Ⅰの「アクセス・権限」の回でした。
| 棚 | 守る対象 | 扱う回 |
|---|---|---|
| Ⅰ. ID・アクセス管理 | 人と権限 | 認証の基礎（前回）・アクセス・権限（本記事） |
| Ⅱ. ネットワーク防御・境界／検知 | 通信と侵入 | 今後の回 |
| Ⅲ. クラウド／デバイス統制 | 環境と端末 | 今後の回 |
次回は、守る対象を「通信」に移して、境界の考え方の話に進みます。
本記事の定義は、各標準・公式資料（ANSI/INCITS 359-2012（RBAC）、NIST SP 800-162（ABAC）、RFC 7644（SCIM）、NIST用語集（最小権限）、NIST用語集（ACL）、Microsoft Learn（Entra PIM）、AWSドキュメント（IAM） ほか）に基づいています。
