認可 (セキュリティ)
情報セキュリティおよびコンピュータセキュリティに関するリソースへのアクセス権限を指定する機能
From Wikipedia, the free encyclopedia
概要
コンピュータシステムやネットワークにおけるアクセス制御はアクセスポリシーに基づいている。 アクセス制御処理は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つの概念は密接に連携する。
認可クレデンシャル
認可クレデンシャル（にんかくれでんしゃる、英: authorization credential）はアクセス時の認可検証に利用される、認可を表現した可搬なデータオブジェクトである[7]。
日常における「許可証」とよく似た概念である。目に見えない「権利」を「証書」という有形物に記すことで、証書の検証により権利の存在を確認できる。アクセス制御では、目に見えない「認可」を「認可クレデンシャル」というデータオブジェクトに対応づけて認可検証を可能にしている。ゆえに保護リソースへのアクセス時、認可クレデンシャルを提示してこれが正当だと検証（verify）されれば「適切な認可がある」としてアクセス制御を通過できる[7]。
混同
認可という用語は、間違ってポリシー施行段階の機能として使われることが多い。この混同はシスコシステムズのAAAサーバの導入に遡る。例えば RFC 2904 [9]や Cisco AAA[10] で混同されている。認可 (authorization) の正しい基本的意味は、これらの用法と互換ではない。例えば、セキュリティサービスの基本的な機密性 (Confidentiality)、完全性 (integrity)、可用性(Availability)は、認可を使って定義される[11]。
「機密性」は国際標準化機構 (ISO) の定義によれば「その情報に対してアクセスを認可された者のみがアクセス可能であることを保証すること」であり、明らかにここでの「認可」はポリシー定義段階の機能である。この機密性の定義を「その情報に対してアクセスを要求されたとき、許可された者にのみアクセス可能であることを保証すること」と解釈するのは不合理で、例えば許可されていない者がパスワードを盗んでアクセスした場合、「認可された」ことになってしまう。ログオン画面で「認可されたユーザーのみがこのシステムにアクセスできる」というような警告を表示することがよくある（例えば、こちら[12]）。認可という用語を間違った意味で使っていると、この警告に対して盗んだパスワードを持つ攻撃者が「認可されているからログオンできたのだ」と主張することを許すことになり、警告を無効にすることになる。
認可という言葉を両方の意味（ポリシー定義段階とポリシー施行段階）で同じ文書内で使っている例もよくある（例えば、こちら[13]）。
認可の概念を正しく使っている例としては、Karp (2006)[14]や Jøsang et al. (2006)[15]がある。