認可（にんか、英: authorization, AuthZ）はある者に付与された、リソースへのアクセス許可である[1]。許可（きょか、英: permission）、権限（けんげん、英: privilege）、アクセス権（あくせすけん、英: access right）とも呼ばれる[2][3]。
また、「認可を付与するプロセス」を「認可」と呼ぶ場合もある[1]。明示的に使い分ける場合、認可を付与することを「認可する（にんかする、英: authorize / 英: grant an authorization）」と言う[4]。
概要
編集コンピュータシステムやネットワークにおけるアクセス制御はアクセスポリシーに基づいている。 アクセス制御処理は2段階に分けられ、第1段階は「ポリシー定義段階」、第2段階は「ポリシー施行段階」である。認可はポリシー定義段階の機能であり、その後ポリシー施行段階で事前に定義された認可に基づき、アクセス要求を受け入れるか拒否するかを決定する。
例えば、人事部門のスタッフは従業員の記録にアクセスする権限を与えられており、このポリシーはコンピュータシステム内のアクセス制御規則として定式化されているのが普通である。システムはそのアクセス制御規則を使って、（認証された）利用者のアクセス要求を受け入れるか拒否するかを決定する。リソースには、個々のファイルやアイテムのデータ、プログラム、コンピュータハードウェア、コンピュータアプリケーションが提供する機能が含まれる。利用者とは例えば、コンピュータユーザー、プログラム、コンピュータ上のその他の機器を指す。
最近のマルチユーザー型オペレーティングシステムの多くはアクセス制御を行っており、したがって認可に基づいて動作している。アクセス制御は利用者のアイデンティティの検証に認証を利用する。利用者がリソースにアクセスしようとしたとき、アクセス制御処理でその利用者がそのリソースの使用を認可されているかを調べる。認可は、アプリケーションの領域では部門の長など責任者 (authority) が決定するものだが、システムアドミニストレータなどの管理者にその権限が委託されていることが多い。認可はアクセスポリシーとして表現され、それは例えばアクセス制御リストやcapabilityの形をとり、「最小権限の原則」を基礎とする。「最小権限の原則」とは、利用者は自身の仕事に必要な場合だけアクセスを認可される、というものである。古いオペレーティングシステムや単一ユーザーのオペレーティングシステムでは認可の概念が弱いか全く存在せず、アクセス制御システムも同様のことが多い。
「無名の利用者」または「ゲスト」とは、認証を必要としない利用者であり、権限も限られていることが多い。分散システムでは、一意なアイデンティティを要求せずにアクセスを認めることが多い。例えば、鍵やチケットなどのアクセストークンが例として挙げられる。鍵やチケットを持っていれば、アイデンティティを証明しなくともアクセスを許可される。
信頼された (trusted) 利用者とは認証された利用者であり、リソースへの無制限のアクセス権限（認可）を与えられていることが多い。部分的に信頼された利用者やゲストは、不正なアクセスや使用を防ぐため、アクセス権限（認可）が制限されていることが多い。一部のオペレーティングシステムのアクセスポリシーでは、デフォルトで全利用者に全てのリソースへの完全なアクセスを許している。もちろん多くの場合は逆で、管理者が個々の利用者に対して個々のリソースの使用を明示的に認可する必要がある。
認可とアクセス制御リストの組み合わせを通してアクセスを制御するとしても、認可データの保守は容易ではなく、管理業務の大きな負担となっている。ユーザーへの認可を変更したり取り消したりする必要はよく生じる。その場合、システム上の対応するアクセス規則を変更したり消去したりする。
従来のシステム毎の認可管理の代替として、信頼できる第三者が認可情報を安全に配布する en:Atomic Authorization もある。
証明・認証・認可との違い
編集Certification (証明)、Authentication (認証)、Authorization (認可)との基本的な概念の違いを以下にまとめる。
| Certification (証明) | Authentication (認証) | Authorization (認可) | |
|---|---|---|---|
| 日本語 | 証明 | 認証 | 認可 |
| 目的 | 第三者による正当性の保証 | 当事者間での本人性の検証 | 権限の付与 |
| 主体 | 信頼された第三者機関(例: 認証局) | 利用者本人とシステム | システム (管理者) |
| 問い | 「それは、信頼できる第三者から見て本物ですか？」 | 「あなたは本当にAさんですか？」 | 「Aさんはこのファイルにアクセスできますか？」 |
| 関係者 | 三者間 | 二者間 | 二者間 |
| 実行タイミング | システム利用前の事前準備 | システムへのアクセス時 | システムへのアクセス後 |
| 例 | SSL/TLSサーバー証明書
クライアント証明書 公開鍵証明書 (PKI) 時刻認証 (タイムスタンプ) |
知識要素認証
パスワード認証 物理的認証 通信・データの認証 リスクベース認証 |
アクセスコントロールリスト (ACL)
ロールベースアクセス制御 (RBAC) 権限管理 |
なお、この3つの概念が密接に連携しており、独立した分類が難しい例もある。
- 「クライアント証明書」のように、Certification (証明書) を使って Authentication (認証) を行う技術もある。この場合、「証明は認証の手段」となり、2つの概念は密接に連携する。
- 「時刻認証」のように、「認証」という名前だが、その仕組みは「信頼できる第三者（時刻認証局）が時刻という事実を保証する」というCertification (証明) の考え方に基づいているものもある[5]。
- 「分散型ID (DID)」のように、特定の第三者機関に依存しない自己主権型のアイデンティティ証明方法もある[6]。
認可クレデンシャル
編集認可クレデンシャル（にんかくれでんしゃる、英: authorization credential）はアクセス時の認可検証に利用される、認可を表現した可搬なデータオブジェクトである[7]。
日常における「許可証」とよく似た概念である。目に見えない「権利」を「証書」という有形物に記すことで、証書の検証により権利の存在を確認できる。アクセス制御では、目に見えない「認可」を「認可クレデンシャル」というデータオブジェクトに対応づけて認可検証を可能にしている。ゆえに保護リソースへのアクセス時、認可クレデンシャルを提示してこれが正当だと検証（verify）されれば「適切な認可がある」としてアクセス制御を通過できる[7]。
OAuth 2.0 におけるアクセストークンが認可クレデンシャルの一例として挙げられる[8]。
混同
編集認可という用語は、間違ってポリシー施行段階の機能として使われることが多い。この混同はシスコシステムズのAAAサーバの導入に遡る。例えば RFC 2904 [9]や Cisco AAA[10] で混同されている。認可 (authorization) の正しい基本的意味は、これらの用法と互換ではない。例えば、セキュリティサービスの基本的な機密性 (Confidentiality)、完全性 (integrity)、可用性(Availability)は、認可を使って定義される[11]。
「機密性」は国際標準化機構 (ISO) の定義によれば「その情報に対してアクセスを認可された者のみがアクセス可能であることを保証すること」であり、明らかにここでの「認可」はポリシー定義段階の機能である。この機密性の定義を「その情報に対してアクセスを要求されたとき、許可された者にのみアクセス可能であることを保証すること」と解釈するのは不合理で、例えば許可されていない者がパスワードを盗んでアクセスした場合、「認可された」ことになってしまう。ログオン画面で「認可されたユーザーのみがこのシステムにアクセスできる」というような警告を表示することがよくある（例えば、こちら[12]）。認可という用語を間違った意味で使っていると、この警告に対して盗んだパスワードを持つ攻撃者が「認可されているからログオンできたのだ」と主張することを許すことになり、警告を無効にすることになる。
認可という言葉を両方の意味（ポリシー定義段階とポリシー施行段階）で同じ文書内で使っている例もよくある（例えば、こちら[13]）。
認可の概念を正しく使っている例としては、Karp (2006)[14]や Jøsang et al. (2006)[15]がある。
関連項目
編集脚注・出典
編集- ^ a b "$ authorization 1a. (I) An approval that is granted to a system entity to access a system resource. ... 1b. (I) A process for granting approval to a system entity to access a system resource." RFC4949 より引用
- ^ "$ authorization ... Compare: permission, privilege. ... Some synonyms are "permission" and "privilege"." RFC4949 より引用
- ^ "$ access right (I) Synonym for "authorization"; emphasizes the possession of the authorization by a system entity." RFC4949 より引用
- ^ "$ authorize (I) Grant an authorization to a system entity." RFC4949 より引用
- ^ “認定タイムスタンプを利用する事業者に関する登録制度 | デ協”. www.dekyo.or.jp. 2025年8月26日閲覧。
- ^ “分散型ID（DID）とは”. WOR(L)D ワード｜大和総研の用語解説サイト (2023年7月21日). 2025年8月26日閲覧。
- ^ a b ""authorization credential": A data object that is a portable representation of the association between an identifier and one or more access authorizations, and that can be presented for use in verifying those authorizations for an entity that attempts such access." RFC4949 より引用
- ^ "1.4. Access Token Access tokens are credentials used to access protected resources." RFC6749 より引用
- ^ J. Vollbrecht et al. AAA Authorization Framework. IETF, 2000 txt.
- ^ B.J. Caroll. Cisco Access Control Security: AAA Administration Services. Cisco Press, 2004
- ^ ISO 7498-2 Information Processing Systems - Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture. ISO/IEC 1989
- ^ Access Warning Statements, University of California, Berkeley [1]
- ^ Understanding SOA Security Design and Implementation. IBM Redbook 2007 PDF
- ^ A. H. Karp. Authorization-Based Access Control for the Services Oriented Architecture. Proceedings of the Fourth International Conference on Creating, Connecting, and Collaborating through Computing (C5), 26-27 January 2006, Berkeley, CA, USA.PDF
- ^ A. Jøsang, D. Gollmann, R. Au. A Method for Access Authorisation Through Delegation Networks. Proceedings of the Australasian Information Security Workshop (AISW'06), Hobart, January 2006. PDF
