コンピュータセキュリティにおいて、一般的なアクセス制御には、識別、認可、認証、アクセス承認、および監査が含まれます。アクセス制御のより狭義の定義では、アクセス承認のみが対象となり、システムは、既に認証された主体からのアクセス要求を、その主体がアクセスを許可されている内容に基づいて許可するか拒否するかを決定します。認証とアクセス制御は、多くの場合、単一の操作に統合され、認証の成功または匿名アクセストークンに基づいてアクセスが承認されます。認証方法とトークンには、パスワード、生体認証スキャン、物理キー、電子キーおよびデバイス、隠された経路、社会的障壁、および人間と自動システムによる監視が含まれます。
アクセス制御モデルでは、システム上で操作を実行できるエンティティを「主体」、アクセス制御が必要なリソースを表すエンティティを「オブジェクト」と呼びます(アクセス制御マトリックスも参照)。主体とオブジェクトは、人間ユーザーではなく、ソフトウェアエンティティとして捉えるべきです。人間ユーザーは、自身が制御するソフトウェアエンティティを介してのみ、システムに影響を与えることができます。
システムによっては、主体をユーザー IDと同一視し、ユーザーが開始したすべてのプロセスがデフォルトで同じ権限を持つようにしているものもありますが、このレベルの制御は最小権限の原則を満たすほどきめ細かくなく、おそらくこのようなシステムにおけるマルウェアの蔓延の原因となっていると考えられます(コンピュータのセキュリティ上の問題を参照)。
オブジェクト機能モデルなど、一部のモデルでは、あらゆるソフトウェアエンティティが主体と客体の両方として機能する可能性がある。
2014年現在アクセス制御モデルは、大きく分けて2つの種類に分類される傾向がある。すなわち、機能に基づくものと、アクセス制御リスト(ACL)に基づくものである。
能力ベースモデルとACLベースモデルの両方には、主体グループ(多くの場合、グループ自体が主体としてモデル化される)のすべてのメンバーにアクセス権限を付与できるメカニズムが備わっています。
アクセス制御システムは、以下の場合に、認可、識別および認証(I&A)、アクセス承認、および説明責任という不可欠なサービスを提供します。
認可とは、主体に対するアクセス権限を定義する行為である。認可ポリシーは、主体がシステム内で実行を許可される操作を規定する。
ほとんどの最新のオペレーティングシステムは、認可ポリシーを、3つの基本的なアクセスタイプのバリエーションまたは拡張である正式な権限セットとして実装しています。
これらの権利と許可は、裁量アクセス制御(DAC)に基づくシステムと強制アクセス制御(MAC)に基づくシステムでは異なる方法で実装されます。
識別と認証(I&A)とは、身元を主張または表明するエンティティに、その身元が紐づいていることを検証するプロセスです。I&Aプロセスは、身元の初期検証(一般に身元証明と呼ばれる)が既に行われていることを前提としています。身元証明には、政府発行の身分証明書を用いた対面検証から、申請者が匿名性を維持しつつ、再申請時にシステムに認識される匿名方式まで、さまざまな方法があります。身元証明と検証に使用される方法は、システム内での身元の意図された用途に見合った保証レベルを提供する必要があります。その後、エンティティは認証手段として、認証情報とともに身元を主張します。識別子に対する唯一の要件は、そのセキュリティドメイン内で一意であることです。
認証システムは一般的に、以下の4つの要素のうち少なくとも1つに基づいています。
アクセス承認とは、操作中に実際にアクセスを許可または拒否する機能です。[ 2 ]
アクセス承認の際、システムは認証ポリシーの形式表現とアクセス要求を比較し、要求を許可するか拒否するかを決定します。さらに、アクセス評価はオンライン/継続的に行うことができます。[ 3 ]
説明責任は、監査証跡(記録)やログなどのシステムコンポーネントを使用して、対象と行動を関連付けます。記録された情報は、対象を管理ユーザーにマッピングするのに十分である必要があります。監査証跡とログは、
ログが定期的に確認されておらず、安全かつ一貫した方法で管理されていない場合、証拠として認められない可能性があります。
多くのシステムは、クリッピングレベルと呼ばれる特定の事前定義された基準またはしきい値に基づいて、自動レポートを生成できます。たとえば、クリッピングレベルは、次のようなレポートを生成するように設定できます。
これらのレポートは、システム管理者やセキュリティ管理者が侵入の試みをより簡単に特定するのに役立ちます。 – クリッピングレベルの定義: [ 4 ]ディスクが磁気特性を維持し、その内容を保持する能力。高品質レベルの範囲は 65~70%、低品質は 55% 未満です。
アクセス制御モデルは、任意型と非任意型に分類されることがあります。最も広く認知されているモデルは、任意型アクセス制御(DAC)、強制型アクセス制御(MAC)、およびロールベースアクセス制御(RBAC)の3つです。MACは非任意型です。
裁量アクセス制御(DAC)とは、オブジェクトの所有者によって決定されるポリシーです。所有者は、誰がオブジェクトにアクセスできるか、また、アクセスを許可する権限は何かを決定します。
DACにおける2つの重要な概念は
アクセス制御は、ACLベースまたはケーパビリティベースのアクセス制御システムにおいて、任意に行える場合があります。(ケーパビリティベースのシステムでは、通常「所有者」という概念は明示的に存在しませんが、オブジェクトの作成者は、そのアクセスポリシーに対して同様の制御権限を持ちます。)
強制アクセス制御とは、特定のユーザーがリソースにアクセスすることを許可するルールが存在する場合に限り、そのリソースへのアクセスを許可する方式を指します。管理は困難ですが、機密性の高い情報を保護する場合には、その使用は通常正当化されます。例えば、政府や軍事関連の情報などが挙げられます。階層型アクセス制御や機密性ラベルの実装によって情報を保護できる場合、管理は(必要以上に)簡素化されることがよくあります。この方式が「強制」となるのは、ルールまたは機密性ラベルのいずれかを使用するからです。
強制アクセス制御を適用するには、一般的に2つの方法が用いられます。
ロールベースアクセス制御(RBAC) は、所有者ではなくシステムによって決定されるアクセス ポリシーです。RBAC は商用アプリケーションだけでなく、多層セキュリティ要件が存在する可能性のある軍事システムでも使用されています。RBAC は、DAC ではユーザーがリソースへのアクセスを制御できるのに対し、RBAC ではアクセスがユーザーの制御外のシステム レベルで制御されるという点で DAC とは異なります。RBAC は非裁量的ですが、主に権限の処理方法において MAC と区別できます。MAC は、ユーザーのクリアランス レベルと追加のラベルに基づいて読み取りおよび書き込み権限を制御します。RBAC は、電子商取引トランザクションなどの複雑な操作を含む権限の集合、または読み取りや書き込みといった単純な権限の集合を制御します。RBAC におけるロールは、権限の集合と見なすことができます。
RBACには、主に3つのルールが定められています。
さらに追加の制約が適用される場合もあり、上位レベルの役割が下位レベルのサブロールが持つ権限を包含する階層構造で役割を組み合わせることも可能です。
ほとんどのITベンダーは、1つ以上の製品でRBAC(ロールベースアクセス制御)を提供しています。
属性ベースアクセス制御(ABAC)では、 [ 5 ] [ 6 ]アクセスは、認証後にユーザーに関連付けられた主体の権利に基づいて許可されるのではなく、特定の属性セットに対して許可される操作を記述するポリシー、ルール、または関係に対する主体、オブジェクト、要求された操作、および環境条件の属性に基づいて許可されます。[ 7 ]ユーザーは、アクセス制御エンジンに対して、自身の属性に関するいわゆるクレームを証明する必要があります。属性ベースアクセス制御ポリシーは、オブジェクトへのアクセスを許可するために満たす必要があるクレームを指定します。たとえば、クレームは「18 歳以上」である可能性があります。このクレームを証明できるユーザーにはアクセスが許可されます。認証と識別が厳密に要求されない場合、ユーザーは匿名にすることができます。ただし、クレームを匿名で証明する手段が必要です。これはたとえば、匿名資格情報を使用して実現できます。XACML (拡張可能なアクセス制御マークアップ言語) は、属性ベースアクセス制御の標準です。XACML 3.0 は 2013 年 1 月に標準化されました。[ 8 ]
従来、アクセスの目的はアクセスを制限することであり、そのためほとんどのアクセス制御モデルは「デフォルト拒否の原則」に従っています。つまり、特定のアクセス要求が明示的に許可されていない場合は拒否されます。この動作は、システムの通常の運用と矛盾する可能性があります。特定の状況では、人間は、達成できる潜在的な利益がリスクを上回る場合、アクセス制御ポリシーに違反することに伴うリスクを負うことをいとわない場合があります。このニーズは、患者の記録へのアクセスが拒否されると患者の死につながる可能性がある医療分野で特に顕著です。ブレイクグラス(またはブレイク・ザ・グラス)は、ユーザーがアクセス制御の決定を上書きできるようにすることで、このリスクを軽減しようとします。ブレイクグラスは、アクセス制御固有の方法(たとえば、RBAC内)[ 9 ] 、または汎用的(つまり、基盤となるアクセス制御モデルとは独立) [ 10 ]で実装できます。
HBACは「ホストベースアクセス制御」の頭文字をとったものです。[ 11 ]
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)IdMでは、任意のPAMサービスをホストベースアクセス制御(HBAC)システムとして識別できます。