認可（にんか、英: authorization, AuthZ）はある者に付与された、リソースへのアクセス許可である[1]。許可（きょか、英: permission）、権限（けんげん、英: privilege）、アクセス権（あくせすけん、英: access right）とも呼ばれる[2][3]。
また、「認可を付与するプロセス」を「認可」と呼ぶ場合もある[1]。明示的に使い分ける場合、認可を付与することを「認可する（にんかする、英: authorize / 英: grant an authorization）」と言う[4]。
概要
コンピュータシステムやネットワークにおけるアクセス制御はアクセスポリシーに基づいている。
アクセス制御処理は2段階に分けられ、第1段階は「ポリシー定義段階」、第2段階は「ポリシー施行段階」である。認可はポリシー定義段階の機能であり、その後ポリシー施行段階で事前に定義された認可に基づき、アクセス要求を受け入れるか拒否するかを決定する。
例えば、人事部門のスタッフは従業員の記録にアクセスする権限を与えられており、このポリシーはコンピュータシステム内のアクセス制御規則として定式化されているのが普通である。システムはそのアクセス制御規則を使って、（認証された）利用者のアクセス要求を受け入れるか拒否するかを決定する。リソースには、個々のファイルやアイテムのデータ、プログラム、コンピュータハードウェア、コンピュータアプリケーションが提供する機能が含まれる。利用者とは例えば、コンピュータユーザー、プログラム、コンピュータ上のその他の機器を指す。
最近のマルチユーザー型オペレーティングシステムの多くはアクセス制御を行っており、したがって認可に基づいて動作している。アクセス制御は利用者のアイデンティティの検証に認証を利用する。利用者がリソースにアクセスしようとしたとき、アクセス制御処理でその利用者がそのリソースの使用を認可されているかを調べる。認可は、アプリケーションの領域では部門の長など責任者 (authority) が決定するものだが、システムアドミニストレータなどの管理者にその権限が委託されていることが多い。認可はアクセスポリシーとして表現され、それは例えばアクセス制御リストやcapabilityの形をとり、「最小権限の原則」を基礎とする。「最小権限の原則」とは、利用者は自身の仕事に必要な場合だけアクセスを認可される、というものである。古いオペレーティングシステムや単一ユーザーのオペレーティングシステムでは認可の概念が弱いか全く存在せず、アクセス制御システムも同様のことが多い。
「無名の利用者」または「ゲスト」とは、認証を必要としない利用者であり、権限も限られていることが多い。分散システムでは、一意なアイデンティティを要求せずにアクセスを認めることが多い。例えば、鍵やチケットなどのアクセストークンが例として挙げられる。鍵やチケットを持っていれば、アイデンティティを証明しなくともアクセスを許可される。
信頼された (trusted) 利用者とは認証された利用者であり、リソースへの無制限のアクセス権限（認可）を与えられていることが多い。部分的に信頼された利用者やゲストは、不正なアクセスや使用を防ぐため、アクセス権限（認可）が制限されていることが多い。一部のオペレーティングシステムのアクセスポリシーでは、デフォルトで全利用者に全てのリソースへの完全なアクセスを許している。もちろん多くの場合は逆で、管理者が個々の利用者に対して個々のリソースの使用を明示的に認可する必要がある。
認可とアクセス制御リストの組み合わせを通してアクセスを制御するとしても、認可データの保守は容易ではなく、管理業務の大きな負担となっている。ユーザーへの認可を変更したり取り消したりする必要はよく生じる。その場合、システム上の対応するアクセス規則を変更したり消去したりする。従来のシステム毎の認可管理の代替として、信頼できる第三者が認可情報を安全に配布する en:Atomic Authorization もある。
認可クレデンシャル
認可クレデンシャル（にんかくれでんしゃる、英: authorization credential）はアクセス時の認可検証に利用される、認可を表現した可搬なデータオブジェクトである[5]。
日常における「許可証」とよく似た概念である。目に見えない「権利」を「証書」という有形物に記すことで、証書の検証により権利の存在を確認できる。アクセス制御では、目に見えない「認可」を「認可クレデンシャル」というデータオブジェクトに対応づけて認可検証を可能にしている。ゆえに保護リソースへのアクセス時、認可クレデンシャルを提示してこれが正当だと検証（verify）されれば「適切な認可がある」としてアクセス制御を通過できる[5]。
OAuth 2.0 におけるアクセストークンが認可クレデンシャルの一例として挙げられる[6]。
混同
認可という用語は、間違ってポリシー施行段階の機能として使われることが多い。この混同はシスコシステムズのAAAサーバの導入に遡る。例えば RFC 2904 [7]や Cisco AAA[8] で混同されている。認可 (authorization) の正しい基本的意味は、これらの用法と互換ではない。例えば、セキュリティサービスの基本的な機密性、完全性 (integrity)、可用性は、認可を使って定義される[9]。「機密性」は国際標準化機構 (ISO) の定義によれば「その情報に対してアクセスを認可された者のみがアクセス可能であることを保証すること」であり、明らかにここでの「認可」はポリシー定義段階の機能である。この機密性の定義を「その情報に対してアクセスを要求されたとき、許可された者にのみアクセス可能であることを保証すること」と解釈するのは不合理で、例えば許可されていない者がパスワードを盗んでアクセスした場合、「認可された」ことになってしまう。ログオン画面で「認可されたユーザーのみがこのシステムにアクセスできる」というような警告を表示することがよくある（例えば、こちら[10]）。認可という用語を間違った意味で使っていると、この警告に対して盗んだパスワードを持つ攻撃者が「認可されているからログオンできたのだ」と主張することを許すことになり、警告を無効にすることになる。
認可という言葉を両方の意味（ポリシー定義段階とポリシー施行段階）で同じ文書内で使っている例もよくある（例えば、こちら[11]）。
認可の概念を正しく使っている例としては、Karp (2006)[12]や Jøsang et al. (2006)[13]がある。
関連項目
脚注・出典
- ^ 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 より引用
- ^ 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
