承認

情報セキュリティ、コンピュータセキュリティ、IAM (アイデンティティおよびアクセス管理) ^{[ 1 ]}における認可または承認(綴りの違いを参照) は、ほとんどの場合アクセス ポリシーを通じてリソースにアクセスするための権利/特権を指定し、特定の主体が特定のリソースにアクセスする特権を持っているかどうかを決定する機能です。主体の例には、人間のユーザー、コンピュータソフトウェア、コンピュータ上のその他のハードウェアが含まれます。リソースの例には、個々のファイルまたはアイテムのデータ、コンピュータ プログラム、コンピュータデバイス、コンピュータ アプリケーションによって提供される機能が含まれます。たとえば、人事スタッフのユーザー アカウントは、通常、従業員記録にアクセスするための認可で構成されます。

認可はアクセス制御と密接に関連しており、アクセス制御は、(認証された)消費者からのリソースへのアクセス要求を承認(許可)するか拒否(却下)するかを決定することによって認可ポリシーを強制するものです。^{[ 2 ]}

認可は認証と混同してはならない。認証とは、他者の身元を確認するプロセスである。

IAMは、以下の2つのフェーズで構成されます。1つ目は、ユーザーアカウントを作成し、それに対応するアクセス認証ポリシーを定義する構成フェーズです。2つ目は、ユーザー認証が行われ、その後アクセス制御が行われて、ユーザー/コンシューマーが認証されたリソースにのみアクセスできるようにする使用フェーズです。したがって、コンピュータシステムおよびネットワークにおけるアクセス制御は、構成時に指定されたアクセス認証に依存します。

承認は、アプリケーションドメイン内の部門マネージャーなどの権限者の責任ですが、システム管理者などの管理者に委任されることもよくあります。承認は、アクセス制御リストや機能などの形式、またはXACMLなどのポリシー管理ポイントといった、一部の「ポリシー定義アプリケーション」におけるアクセス ポリシーとして表現されます。

認証の不備は、Webアプリケーションにおける最大の危険として挙げられることが多い。^{[ 3 ]} 「最小権限の原則」に基づき、利用者は業務に必要なものへのアクセスのみを許可されるべきであり、それ以上のアクセスは許可されるべきではない。^{[ 4 ]}

「匿名ユーザー」または「ゲスト」とは、認証を必要としないユーザーのことです。多くの場合、彼らの権限は限定的です。分散システムでは、固有のIDを要求せずにアクセスを許可することが望ましい場合がよくあります。アクセストークンの身近な例としては、鍵、証明書、チケットなどがあります。これらは、IDを証明することなくアクセスを許可します。

アプリケーションの認証に広く使用されているフレームワークはOAuth 2です。これは、サードパーティアプリケーションがユーザーの認証情報を公開することなく、ユーザーのリソースへの限定的なアクセスを取得するための標準化された方法を提供します。^{[ 5 ]}

現代のシステムでは、認可のモデルとしてロールベースアクセス制御（RBAC）が広く用いられており、認可は主体に1つ以上のロールを付与し、アクセスされるリソースにそれらのロールの少なくとも1つが割り当てられていることを確認することによって定義されます。^{[ 5 ]}しかし、ソーシャルメディアの台頭に伴い、関係ベースアクセス制御がより注目を集めています。^{[ 6 ]}

認証とアクセス制御リストの組み合わせによってアクセスが制御されている場合でも、認可データの維持管理は容易ではなく、認証資格情報の管理と同程度の管理負担となることがよくあります。ユーザーの認可を変更または削除する必要が生じる場合が多く、これはシステム上の対応するアクセスルールを変更または削除することによって行われます。アトミック認可は、システムごとの認可管理の代替手段であり、信頼できる第三者が認可情報を安全に配布します。