認可
認証された主体に、どの資源に対して、どんな操作を許すかを決めることです（英語では authorization）。
定義
NIST の用語集には、次のような定義が載っています。
- 利用者・プログラム・プロセスに与えられるアクセスの特権、またはその特権を与える行為（CNSSI 4009-2022）
- 個人のアクセスの特権を最初に定め、その後、アクセスの求めが受け入れられるかを確かめる手順（NISTIR 4734）
認証が「誰か」を確かめるのに対し、認可は「何をしてよいか」を決めます。認証に成功しても、認可されていない操作はできません。
認可には、権限を前もって与えること（付与）と、アクセスのたびに許すかを判断すること（判断）の2つの面があります。
認可の流れ
- 主体（利用者や、その代わりに動くプログラム）が認証される
- 主体が資源へのアクセスを求める
- アクセス制御のポリシーに照らして、許すかを判断する
- 判断に従って、許す・拒む（判断と施行を別の部品が担う設計もある。ゼロトラストでは、ポリシーエンジンが判断し、ポリシー管理者がポリシー施行点（PEP）に指示して施行する）
主なモデル
認可のモデル（DAC・MAC・
RBAC・
ABAC）は、
アクセス制御のページにまとめています。資源ごとに使ってよい利用者やグループを並べるアクセス制御リスト（ACL）は、資源の持ち主が権限を決める方式（DAC）を、ファイルなどで実装する典型の形です。ACL は資源ごとに個別に決めやすい一方、利用者と資源が増えると、誰が何にアクセスできるかを横断して見直すのが難しくなります。
どのモデルでも、
最小権限の原則と
職務の分離が基本です。
OAuth 2.0
RFC 6749 は、OAuth 2.0 を、第三者のアプリケーションが、資源の持ち主の承認を得て、またはアプリケーション自身の権限で、HTTP のサービスへの限られたアクセスを得るための
認可の枠組みとしています。アプリケーションは、持ち主のパスワードではなく、範囲と期限を限ったアクセスの証（アクセストークン）を受け取ります。利用者が誰かを確かめる（認証する）ための仕組みではないので、ログインに使うときは、その上に作られた OpenID Connect などを使います（
認証）。
運用の要点
- 権限は、付けるときより外すときに漏れやすい。異動や退職のときに外す手順と、定期的な棚卸しを決める
- 一時的に広い権限を付けたら、期限を決めて戻す
関連するページ
出典
確認日：2026年10月16日
最終更新：2026年10月16日 17:53
