アクセス制御とABACの概要

アクセス制御の一般論

ゼロトラストアーキテクチャの適用に関わらず、管理者は業務やセキュリティ要件に基づき、リソースを不正アクセスから保護しなければならない。アクセス管理のうち、リソース間で実行される操作を決定・施行する一連の処理を持つ機能がアクセス制御である。これは主に認証、認可、認可結果の施行の順に実行される。このプロセスに必要となる、主なコンポーネントを次の図に示し、解説する。

2.1.1 Policy Decision Point(PDP)とPolicy Information Point(PIP)

サブジェクトからオブジェクトへのアクセスを確立する、あるいは有効なセッション中にアクセスの維持を試みる際、管理者や管理機能は正当なアクセスであるか検証・評価し、その結果を反映させねばならない。このうちアクセスを評価するのがPDPである。アクセスにかかわるリソースの情報がPDPの入力値となり、その内容をPDPのポリシーが評価する。

リソースに関する情報源はリソース自体であることもあれば、外部システムからの提供、あるいは外部システムへの取得であることもある。このコンポーネントがPIPである。PIPはディレクトリサービスなどの外部システムを指すこともある。PIPからの情報でPDPはアクセス可否を決定する。PDPは更に別のアクセス制御を適用することも可能である。PDPは一連のアクセス制御の結果を何らかのデータに整形して発行する役割も負う。

2.1.2 Policy Enforcement Point(PEP)

PDPの結果を、実際の処理に対して施行するコンポーネントがPolicy Enforcement Point（PEP）である。PEPはゲートウェイ的なトポロジー構成をとることもあれば、サブジェクトのエージェントとして動作することもありうる。

なお、PDPもPEPも概念的なコンポーネントである。そのため、導入するサービスや実際に動作するソフトウェアではPDPとPEPを兼ねるようなものや、それぞれが独立しているものなど、多種多様である。

ABACを含む既存のアクセス制御モデル

アクセス制御モデルで特に普及しているものに、任意アクセス制御（Discretionary Access Control, DAC）、強制アクセス制御（Mandatory Access Control、MAC）、役割ベースアクセス制御（Role-Based Access Control、RBAC）があげられる。それらと本ガイドラインの焦点である属性ベースアクセス制御（Attribute-Based Access Control, ABAC）を本章で取り上げる。

2.2.1 Discretionary Access Control (DAC)

DACは情報システム内のオブジェクトに設定されるアクセス制御ポリシーで、オブジェクトの所有者がサブジェクトの操作可能な範囲を指定する。例えば、UNIX/Linux上のファイルやフォルダの所有者は、各ファイルやフォルダに対する権限（読み出し、書き込み、実行）を組み合わせて各ユーザーやグループに付与している[^1]。

2.2.2 Mandatory Access Control (MAC)

MACは、情報システム内にあるすべてのサブジェクトとオブジェクトに対して一律に適用されるポリシーによる制御モデルである。オブジェクトに機密性を指定し、サブジェクトに許可された権限をもって、操作可能な範囲を指定する。例えばSELinuxでは、サブジェクトおよびオブジェクトにsensitivityとcategoryからなるセキュリティレベルを付与し、それとポリシーを用いて、アクセス制御が適用される。DAC単体と大きく異なる点としては、リソースに名前や識別子以外にレベルという属性を一元管理的に付与し、その属性をベースにしたポリシーもさらに一元管理化したことである。

2.2.3 Role-Based Access Control (RBAC)

RBACは、サブジェクトあるいはオブジェクトに付与するロール（役割）による制御モデルである。ここでのロールは、組織図を反映した階層構造上で表現される職種や役職のような情報を指す。これらの情報がリソースのロールという属性に設定される。PDPがロールの情報を参照する方法は、処理要求時のリクエストにアクセストークンのような形で含まれるpush型や、ディレクトリ等のPIPから取得するpull型といったケースに大別できる。

ロールと認可される処理の紐づけは、事前にポリシーとして定義されており、処理の要求が発生した際にPDPによって照合される。ロールを使うことでリソースそのものの情報をポリシーに記述する必要がなくなり、管理が効率化される。一方、特定の情報を定数としてポリシーに記述することから、RBACはDACやMACと同様に静的なアクセス制御モデルとなる。この場合、異動や命名変更が頻繁におこらない比較的不変性の強い組織に有効なモデルとなる。

2.2.4 Attribute-Based Access Control (ABAC)

ABACは、サブジェクトやオブジェクトの属性に設定された情報や周辺の環境情報をもとにアクセス制御をするモデルである。属性情報を入手する経路としては、RBACと同様に、リソース自体が提示する場合とPIPから取得する場合が考えられる。RBACのようにロールのような属性の値を基にする点でも類似しているが、ロール以外の複数種別の属性情報や環境情報を使った複雑なポリシーを定義できる点が最大の特徴になる。

ABACの特性

DAC, MAC, RBACはリソースの識別子、機密性の分類、ロールといった情報を用いたアクセス制御モデルである。これらの情報はリソースに属する情報、つまり属性情報である。したがって、これらアクセス制御モデルは簡易的なABACといえる。しかし、先述したとおりABAC最大の性質は、複数の属性および属性情報、そして処理をとりまく環境情報など、より広範囲で多様な値を使ったアクセス制御にある。その特性を次のように応用することで、柔軟な運用が可能になる。

2.3.1 属性の加工・変換

図 3: 属性の変換・加工

ABACは特定の属性を組み合わせる、グルーピングする、変換するなど行うことで、新たな属性を導き出し、それをアクセス制御に活用できる。例えば、特定の業務契約で日中時間帯以外のアクセスを想定しないユーザーには、ログイン時間のような属性の値を日中時間帯と比較し、true/falseのような値をもつ属性を付与できる。また、利用者の情報、通信環境やデータ保護の構成情報などからリスクスコアを算出する常時リスク診断・対処（CRSA）も１つの例である。

ロールのような単一の属性に依拠する制御モデルの場合、運用が進むにつれ属性情報の複雑性も増し、同時に管理も困難になる。ABACは柔軟な属性の定義のみならず、運用の複雑性への対処にも寄与する。

2.3.2 外部情報の活用

ABACはリソースの属性情報だけではなく、外部システムから取得した情報を制御に活用できる。

境界防御の観点では外部通信先のドメインやIPアドレスの妥当性を確認し、アクセス可否を決定したいことがしばしばある。ABACであれば、アクセス先すなわちオブジェクトのドメインやIPアドレスを属性情報とみなし、それらに関する追加的な情報を脅威インテリジェンスサービスから得るといったモデルを構築できる。