情報セキュリティ、コンピュータセキュリティ、IAM(アイデンティティおよびアクセス管理)[ 1 ]における認可または承認(スペルの違いを参照)は、ほとんどの場合アクセスポリシーを通じてリソースにアクセスするための権利/特権を指定し、特定のサブジェクトが特定のリソースにアクセスする権限を持っているかどうかを決定する機能です。サブジェクトの例には、人間のユーザー、コンピュータソフトウェア、コンピュータ上のその他のハードウェアが含まれます。リソースの例には、個々のファイルまたはアイテムのデータ、コンピュータプログラム、コンピュータデバイス、コンピュータアプリケーションによって提供される機能が含まれます。たとえば、人事スタッフのユーザーアカウントは通常、従業員レコードにアクセスするための承認が設定されています。
認可はアクセス制御と密接に関連しており、アクセス制御は(認証された)消費者からのリソースへのアクセス要求を承認(許可)するか、不承認(拒否)するかを決定することによって認可ポリシーを実施するものです。[ 2 ]
承認は、誰かの身元を確認するプロセスである 認証と混同しないでください。
IAMは、ユーザーアカウントを作成し、それに対応するアクセス承認ポリシーを定義する設定フェーズと、ユーザー認証とアクセス制御を行う使用フェーズの2つのフェーズで構成されます。使用フェーズでは、ユーザー/消費者が承認されたリソースにのみアクセスできるようにします。したがって、コンピュータシステムおよびネットワークにおけるアクセス制御は、設定時に指定されたアクセス承認に依存します。
認可は、アプリケーションドメイン内の部門管理者などの権限を持つ者の責任ですが、多くの場合、システム管理者などの管理者に委任されます。認可は、一部の「ポリシー定義アプリケーション」ではアクセスポリシーとして表現されます。例えば、アクセス制御リストや機能、あるいはXACMLなどのポリシー管理ポイントの形式です。
不正な認証は、Webアプリケーションにおける最大のリスクとして挙げられることが多い。[ 3 ] 「最小権限の原則」に基づき、利用者は業務を遂行するために必要なアクセス権限のみを付与されるべきであり、それ以上のアクセス権限は付与されるべきではない。[ 4 ]
「匿名消費者」または「ゲスト」とは、認証を要求されていない消費者のことです。多くの場合、これらの消費者には限定的な権限が与えられています。分散システムでは、一意のIDを要求せずにアクセスを許可することが望ましい場合が多くあります。アクセストークンの一般的な例としては、鍵、証明書、チケットなどが挙げられます。これらはIDを証明せずにアクセスを許可します。
アプリケーション認証に広く利用されているフレームワークはOAuth 2です。これは、サードパーティのアプリケーションがユーザーの資格情報を公開することなく、ユーザーのリソースへの限定的なアクセスを取得するための標準化された方法を提供します。[ 5 ]
現代のシステムでは、広く使用されている認可モデルはロールベースのアクセス制御(RBAC)であり、これは主体に1つ以上のロールを付与し、アクセスされるリソースにそれらのロールの少なくとも1つが割り当てられているかどうかを確認することによって認可が定義される。[ 5 ]しかし、ソーシャルメディアの台頭により、関係性ベースのアクセス制御がより重要になってきている。[ 6 ]
認証とアクセス制御リストの組み合わせによってアクセスを制御する場合でも、認可データの維持管理の問題は容易ではなく、認証資格情報の管理と同じくらい大きな管理負担となることがよくあります。ユーザーの認可を変更または削除する必要が生じることも少なくありません。これは、システム上の対応するアクセスルールを変更または削除することで実現されます。アトミック認可は、信頼できる第三者機関が認可情報を安全に配布するシステムごとの認可管理の代替手段となります。
公共政策において、認可はセキュリティや社会統制のために使用される信頼できるシステムの機能です。
銀行業務において、承認とは、デビット カードまたはクレジットカードを使用して購入が行われたときに顧客の口座に課される保留を指します。
出版においては、公開講演やその他の無料テキストが著者の許可なく出版されることがあります。これらは無許可テキストと呼ばれます。例えば、2002年に出版された『万物の理論:宇宙の起源と運命』は、スティーブン・ホーキング博士の講演を収録したもので、著作権法に定められた許可なく出版されました。