認可（にんか、, AuthZ）はある者に付与された、リソースへのアクセス許可である"$ 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 より引用。

概要 コンピュータシステムやネットワークにおけるアクセス制御はアクセスポリシーに基づいている。 アクセス制御処理は2段階に分けられ、第1段階は「ポリシー定義段階」、第2段階は「ポリシー施行段階」である。認可はポリシー定義段階の機能であり、その後ポリシー施行段階で事前に定義された認可に基づき、アクセス要求を受け入れるか拒否するかを決定する。

例えば、人事部門のスタッフは従業員の記録にアクセスする権限を与えられており、このポリシーはコンピュータシステム内のアクセス制御規則として定式化されているのが普通である。システムはそのアクセス制御規則を使って、（認証された）利用者のアクセス要求を受け入れるか拒否するかを決定する。リソースには、個々のファイルやアイテムのデータ、プログラム、コンピュータハードウェア、コンピュータアプリケーションが提供する機能が含まれる。利用者とは例えば、コンピュータユーザー、プログラム、コンピュータ上のその他の機器を指す。

最近のマルチユーザー型オペレーティングシステムの多くはアクセス制御を行っており、したがって認可に基づいて動作している。アクセス制御は利用者のアイデンティティの検証に認証を利用する。利用者がリソースにアクセスしようとしたとき、アクセス制御処理でその利用者がそのリソースの使用を認可されているかを調べる。認可は、アプリケーションの領域では部門の長など責任者 (authority) が決定するものだが、システムアドミニストレータなどの管理者にその権限が委託されていることが多い。認可はアクセスポリシーとして表現され、それは例えばアクセス制御リストやcapabilityの形をとり、「最小権限の原則」を基礎とする。「最小権限の原則」とは、利用者は自身の仕事に必要な場合だけアクセスを認可される、というものである。古いオペレーティングシステムや単一ユーザーのオペレーティングシステムでは認可の概念が弱いか全く存在せず、アクセス制御システムも同様のことが多い。

「無名の利用者」または「ゲスト」とは、認証を必要としない利用者であり、権限も限られていることが多い。分散システムでは、一意なアイデンティティを要求せずにアクセスを認めることが多い。例えば、鍵やチケットなどのアクセストークンが例として挙げられる。鍵やチケットを持っていれば、アイデンティティを証明しなくともアクセスを許可される。

信頼された (trusted) 利用者とは認証された利用者であり、リソースへの無制限のアクセス権限（認可）を与えられていることが多い。部分的に信頼された利用者やゲストは、不正なアクセスや使用を防ぐため、アクセス権限（認可）が制限されていることが多い。一部のオペレーティングシステムのアクセスポリシーでは、デフォルトで全利用者に全てのリソースへの完全なアクセスを許している。もちろん多くの場合は逆で、管理者が個々の利用者に対して個々のリソースの使用を明示的に認可する必要がある。

認可とアクセス制御リストの組み合わせを通してアクセスを制御するとしても、認可データの保守は容易ではなく、管理業務の大きな負担となっている。ユーザーへの認可を変更したり取り消したりする必要はよく生じる。その場合、システム上の対応するアクセス規則を変更したり消去したりする。

従来のシステム毎の認可管理の代替として、信頼できる第三者が認可情報を安全に配布する :en:Atomic Authorization もある。

証明・認証・認可との違い Certification (証明)、Authentication (認証)、Authorization (認可)との基本的な概念の違いを以下にまとめる。 Certification (証明)Authentication (認証)Authorization (認可)日本語証明認証認可目的第三者による正当性の保証当事者間での本人性の検証権限の付与主体信頼された第三者機関(例: 認証局)利用者本人とシステムシステム (管理者)問い「それは、信頼できる第三者から見て本物ですか？」「あなたは本当にAさんですか？」「Aさんはこのファイルにアクセスできますか？」関係者三者間二者間二者間実行タイミングシステム利用前の事前準備システムへのアクセス時システムへのアクセス後例SSL/TLSサーバー証明書

クライアント証明書

電子署名

公開鍵証明書 (PKI)

時刻認証 (タイムスタンプ)知識要素認証 パスワード認証

物理的認証

ワンタイムパスワード

生体認証

通信・データの認証

メッセージ認証

リスクベース認証

多要素認証 (MFA)アクセスコントロールリスト (ACL)

ロールベースアクセス制御 (RBAC)

権限管理

OAuth なお、この3つの概念が密接に連携しており、独立した分類が難しい例もある。

「クライアント証明書」のように、Certification (証明書) を使って Authentication (認証) を行う技術もある。この場合、「証明は認証の手段」となり、2つの概念は密接に連携する。

「時刻認証」のように、「認証」という名前だが、その仕組みは「信頼できる第三者（時刻認証局）が時刻という事実を保証する」というCertification (証明) の考え方に基づいているものもある。 「分散型ID (DID)」のように、特定の第三者機関に依存しない自己主権型のアイデンティティ証明方法もある。

認可クレデンシャル 認可クレデンシャル（にんかくれでんしゃる、）はアクセス時の認可検証に利用される、認可を表現した可搬なデータオブジェクトである""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 より引用。

日常における「許可証」とよく似た概念である。目に見えない「権利」を「証書」という有形物に記すことで、証書の検証により権利の存在を確認できる。アクセス制御では、目に見えない「認可」を「認可クレデンシャル」というデータオブジェクトに対応づけて認可検証を可能にしている。ゆえに保護リソースへのアクセス時、認可クレデンシャルを提示してこれが正当だと検証（verify）されれば「適切な認可がある」としてアクセス制御を通過できる。

OAuth 2.0 におけるアクセストークンが認可クレデンシャルの一例として挙げられる"1.4.  Access Token Access tokens are credentials used to access protected resources." RFC6749 より引用。

混同 認可という用語は、間違ってポリシー施行段階の機能として使われることが多い。この混同はシスコシステムズのAAAサーバの導入に遡る。例えば J. Vollbrecht et al. AAA Authorization Framework. IETF, 2000 txt.や Cisco AAA B.J. Caroll. Cisco Access Control Security: AAA Administration Services. Cisco Press, 2004 で混同されている。認可 (authorization) の正しい基本的意味は、これらの用法と互換ではない。例えば、セキュリティサービスの基本的な機密性 (Confidentiality)、完全性 (integrity)、可用性(Availability)は、認可を使って定義される ISO 7498-2 Information Processing Systems - Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture. ISO/IEC 1989。

「機密性」は国際標準化機構 (ISO) の定義によれば「その情報に対してアクセスを認可された者のみがアクセス可能であることを保証すること」であり、明らかにここでの「認可」はポリシー定義段階の機能である。この機密性の定義を「その情報に対してアクセスを要求されたとき、許可された者にのみアクセス可能であることを保証すること」と解釈するのは不合理で、例えば許可されていない者がパスワードを盗んでアクセスした場合、「認可された」ことになってしまう。ログオン画面で「認可されたユーザーのみがこのシステムにアクセスできる」というような警告を表示することがよくある（例えば、こちら Access Warning Statements, University of California, Berkeley ）。認可という用語を間違った意味で使っていると、この警告に対して盗んだパスワードを持つ攻撃者が「認可されているからログオンできたのだ」と主張することを許すことになり、警告を無効にすることになる。

認可という言葉を両方の意味（ポリシー定義段階とポリシー施行段階）で同じ文書内で使っている例もよくある（例えば、こちら Understanding SOA Security Design and Implementation. IBM Redbook 2007 PDF ）。

認可の概念を正しく使っている例としては、Karp (2006) 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や Jøsang et al. (2006)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がある。

関連項目 情報セキュリティ コンピュータセキュリティ アクセス制御 認可 認証 ケルベロス認証 OAuth

脚注・出典