Vol. 0

情報処理学会論文誌

No. 0

1959

ポリシーに基づく分散処理向けアクセス制御モデルの初期的検討
橋 本 正 樹†金美 羅†
辻秀 典†,†† 田 中 英 彦†
情報システムにおけるセキュリティ確保は必須である．近年の情報システムは，ネットワークを介して複数の処理要素が連携処理を行う分散システムが基本である．従って本稿では，分散システムにおけるセキュリティ確保基盤をアプリケーションプラットフォームとしての OS 内で行なうことを目的とし，そのために必要となる OS の機能を検討した上で，中核機能に位置づけられるアクセス制御
モデルを提案し検討する．特に本稿においては，ポリシーの記述法とそれを正しく強制するためのア
クセス制御機構に焦点をあてて検討する．

Preliminary Studies of Policy-Based Access Control Modelfor Distributed Environment
Masaki HASHIMOTO,† Mira KIM,† Hidenori TSUJI†,††and Hidehiko TANAKA†
This paper describes the use of operating system for the realization of distributed securecomputing infrastructure. In particular, it describes a few resource management schemes for
distributed environment, addressing the policy expression and the access control mechanism
based on the policy. The access control is ﬁne grained so as to realize the appropriate accessgranularity at distributed environment, and forced mandatory through mechanism such as
reference monitor, secure channel, authorization and naming. Finally, we suggest a prototype
of our system and the future plan.

より，情報システム一般のセキュリティレベルを標準

1. は じ め に化することが必要不可欠と考える．

情報システムにおけるセキュリティ確保は必須であ

本稿では，分散システムにおけるセキュリティ確保

る．特に，近年の情報システムは，ネットワークを介し基盤をアプリケーションプラットフォームたる OS でて複数の処理要素が連携処理を行う分散システムが基行なうことを目的とし，そのために必要となる OS の本である．しかしながら，現状の分散処理におけるセ機能を検討した上で，中核機能に位置づけられるアク

キュリティ確保は個々のアプリケーションの実装方式，

セス制御モデルを提案し検討する．

もしくは一部のミドルウェア機能に依存しており，共

2. 背景と関連研究

通のセキュリティプラットフォームが確立されているとは言いがたい．そのため，アプリケーション開発者

本節では，分散システムにおけるアクセス制御の問に対してセキュリティ確保のための負担を強いるとと題を簡単に整理した後，セキュア OS では志向の違い

もに，情報システムのセキュリティレベルが個々のシにより解決が難しいことを述べる．そして分散システ

ステムによって異なる要因となる．本来であれば，情ムに適合したプラットフォームの必要性と提案する方報システムのセキュリティ確保は共通化されたプラッ法について述べる．

2.1 分散システムにおける問題認識

トフォームで行うべきであるので，これを個々のアプ
リケーションレベルではなく OS レベルで行うことに

OS は計算機においてアプリケーションを動作させるための資源管理を行うプラットフォームであり，下† 情報セキュリティ大学院大学
Institute of Information Security†† 株式会社情報技研
Institute of Information Technology, Inc.

位層のハードウェアを管理し，上位層のアプリケーションに対して，資源を利用するための機能であるシステ
ムコールを提供する．しかしながら，TCP/IP ネット1

2

情報処理学会論文誌

1959

ワークの普及により，むしろアーキテクチャやプラッ

2.3 分散システムに適合したプラットフォーム要件

トフォームの差異をアプリケーションが通信を介する分散システムに適合したプラットフォームの要件をことにより吸収している．そのため，分散システム

ひとことでいうと，必要十分な粒度によってシステムのセキュリティ確保は，プラットフォームより上位層全体で透過的なアクセス制御が可能となることである．

のソフトウェア階層で行われることが一般的となってそのために必要となる要件は以下のとおりとなる3) ．

いる．セキュリティに限らず，SOA（service-oriented• ローカルノードにおいても，ネットワーク経由のarchitecture）に代表されるように，アプリケーション

別ノードにおいても，OS がアクセス主体を透過

階層で分散システムの標準化を行なう志向が近年強い．

的に扱える必要がある．

アプリケーション階層でアクセス制御を行なおうと• 透過的扱いとは，分散システム内のアクセス主体

した場合には，アクセス制御に関する情報は TCP/IPの共通化もしくは，各ノードにおけるアクセス主

等による通信のペイロードの中に，アプリケーション

体同士の権限の継承をさす．

階層の情報（トークン等）として埋め込まれている．

• アクセス主体は分散システム内において，許可さそのため，アプリケーションより下位のソフトウェア

れたオブジェクトにしかアクセスできないこと．

層において，処理内容に応じた権限の制御を行うこと• オブジェクトに対するアクセス主体のアクセス制

はできず，その判断はすべてアプリケーションに委ね

御情報は，分散システム内で共有化されている

るしかない．しかしながらアプリケーションそのもの

こと．

は，OS レベルではプロセス等の非常に粗い粒度でし• OS が識別できるアクセス主体およびオブジェク

か管理されておらず，アプリケーションレベルにおけトに対するアクセス制御情報を，アプリケーショ

るセキュリティホールが OS レベルにおいて大きな問ンに対しても提供できること．

題に拡大してしまう原因となっている．

2.2 セキュア OS と分散システムの適合性

2.4 分散システムに適合した提案モデル
先に述べたプラットフォーム要件のうち，分散シス

最小特権のセキュリティ原則1) は，情報システム内

テム内で透過的なアクセス制御を行うためのモデルをの実体が必要以上の権限を有することによって起きる

本稿にて提案する．分散処理に対する共通の枠組みを問題を防ぐために考案された．これは，セキュアなシ実現するためには，分散処理が複数ノード／複数アプ

ステムを構成するための指針となる概念であり，要素

リケーションの連携によって仕事を行うことを考慮す技術としてポリシーの記述法や細粒度の強制アクセス

ると，この枠組みはそれらすべてから等しく利用可能

制御2) （Mandatory Access Control : MAC）機構，である必要がある．加えて，アクセス制御を行うコン

アクセス制御対象となる実体の識別／認証を必要とす

ポーネントとしての観点からすると改ざんに強く，さる．ここで MAC とは，任意アクセス制御（Discre-

らにアクセス制御の対象を確実に捕捉できることが期

tionary Access Control : DAC）と対をなす概念であ待される4) ．そのため，提案モデルでは OS で分散処

り，DAC がリソースの所有者にアクセス権限の管理

理のアクセス制御を行う．複数ノード／複数応用からを一任するのに対して，MAC ではポリシーに基づい利用可能であると言う点では，ミドルウェアやライブてシステムがアクセス権限を一元的に管理する．

ラリによってアクセス制御を実現する方法もあり，こプラットフォームにおける粗粒度アクセスが，分散の場合は OS 層以下の差異を吸収できる利点があるが，システムのセキュリティ確保において問題であるとす

一方でセキュリティの観点からすると改竄防止や確実るならば，それが細粒度アクセス制御が可能なセキュな実施という点において，より下位の OS で実現した

ア OS にて解決されるのかを考えたとき，以下の理方が有利である．このため，近年における情報システ

由により解決は難しいと考える．まず，現在のセキュ

ムのセキュリティ強化に対する要請を考慮すると，応ア OS が単一システム志向であることがあげられる．

用の実行環境としての OS がより安全な分散処理志向

MAC による細粒度アクセス制御はあくまでセキュアのアクセス制御機能を備えるべきである．

OS が稼動しているシステム内にしか及ばず，分散シ

次に，セキュリティ管理の方法を述べる．分散処理

ステムとの親和性が低い．さらに，アクセス制御が細は単一システムでの処理と比較して複雑であり，潜在

粒度すぎることも問題である．細粒度すぎるがゆえ，的に多数のアクセス制御対象を含む可能性があるた

これを単純に分散システム拡張した場合，複雑性が爆め，アクセス制御情報を規則として記述する負担を軽発してしまい非現実的となる．

減し，全体を把握しやすい仕組みが必要となる．そのため，提案モデルでは分散システム全体にまたがったVol. 0No. 0

ポリシーに基づく分散処理向けアクセス制御モデルの初期的検討

3

ポリシーによるアクセス制御情報を記述する．リソー

セス権限はタスク毎に異なる可能性がある．一般

スの所有者がアクセス制御情報を個別に設定してい的な手法では，サブタスクにも親となるタスクかくような方法は，非常に単純で管理者の負担を軽減でらアクセス権限が引き継がれるが，この方法ではきるが，全体として要求するアクセス制御を処理毎にサブタスク毎に異なるアクセス権限を付与するこ

強制できないため，統一的なセキュリティ管理が難しとができない．そのため，提案モデルにおいてはい．一方で，ポリシーによるアクセス制御情報の記述

サブタスク毎に独立したアクセス権限を付与するは，複雑な処理を必要とする上，管理者にはポリシー
記述の負担をかけるが，システム全体としてのセキュ
リティレベルの平均化と向上が期待できる．

ような記述ができる必要がある．

3.2 アクセス制御機構
ポリシーに基づいたアクセス権限管理を OS で実施するためには，ポリシーで表現されたアクセス制御情3. 提案モデルの概要

報を実際のアクセス制御機構が実施できる必要がある．

本節では，分散処理のアクセス制御を共通の枠組み

そのためには，ポリシーで表現されたアクセス制御情で実現するモデルの基本構成について述べる．提案す

報を過不足なく柔軟に強制できる仕組みが必要となるるモデルはポリシー記述とアクセス制御機構が中核でため，提案モデルではアクセス制御機構に関して，以あり，アクセス制御機構は Capability を用いてアク下のような機能を必要とする．

セス制御を行なう．次にこれらの 3 点について述べる．

認可情報の関連付け 提案モデルのアクセス制御機

3.1 ポリシー記述

構は認可情報を Initiator に関連付ける．分散処理

ポリシーは個々の分散処理に関して，必要十分な権ではアクセス主体となるインスタンス (Initiator )限付与を表現できる必要がある．一方で，分散処理のの頻繁な生成／削除を考慮する必要があるが，認複雑さに対応するために，ポリシー記述の負担を軽減

可情報をアクセス対象のインスタンス (Target)

し，ポリシー全体を把握しやすくするような仕組みがに関連付ける仕組み5) では Initiator の情報が別求められる．そのためポリシー記述に関しては，以下に管理されるので，認可情報と Initiator の関連のような機能を必要とする．
細粒度の記述と粒度の制御付けに関する整合性を保つのが難しい．
個々の分散処理を正参照情報と認可情報の不可分

Target に関する参照

しく記述するためには，プロセスやノードといっ

情報と認可情報は不可分に扱う．参照情報と認可

た粗い粒度によるものでは不十分であり，トラン

情報を別々に扱ってアクセス制御の際に統合するザクション下で実際にアクティビティを行う実体

ような仕組みでは Confused Deputy Problem6)（インスタンス）を記述できる必要がある．一方を防ぐのが難しい．参照情報と認可情報が不可分で，ポリシー記述による管理者の負担を軽減するであれば，Initiator は常に特定の目的の基に参照

ためには，任意のインスタンスを含むグループをを行うため，そのような問題が起こりにくくなる．

構成し，それに対するアクセス制御を記述できる

認可情報の委譲 新しく生成／削除されるインスタ必要がある．インスタンス毎にアクセス制御を記

ンスに対して，Initiator が認可情報を委譲できる

述できると同時にグループ化をサポートすることようにする．これは，分散処理における権限遷移

によって，必要に応じた粒度の制御が可能となる．

やサブタスクへの認可情報設定のためであり，ま権限遷移の記述 分散処理においては，ひとつのイたアクセス制御の柔軟性を保つためには Initiator

ンスタンスがトランザクション内で複数の仕事をに関する動作をあらかじめ固定できないので，認行う場合があるので，仕事毎にアクセス権限を付

可情報をアクセス主体毎に委譲できるようにする．

与できるのが望ましい．しかし，トランザクショ

アプリケーションとの連携 アクセス制御機構がポンで必要とされるすべてのアクセス権限をインスリシーに基づいた制御を行うためには，制御対象

タンスに付与するのは過剰であり，仕事毎に付与のインスタンスを適切に扱う必要がある．そのたするアクセス権限を切り替えるような仕組みが必め，アクセス制御機構はノードやアプリケーショ

要となる．そのため，提案モデルではアクセス権

ン内で生成されるソフトウェアコンポーネントを限の遷移を適切に記述できる必要がある．

確実に捕捉してポリシーに従ったアクセス権限のサブタスクの記述 分散処理においては，あるタス付与を行い，強制できなければならない．

クが別のサブタスクを生成することによって仕事

3.3 Capabilityを処理する場合があるが，仕事に必要十分なアク

Capability 7),8) は，オブジェクトの識別子とそれに情報処理学会論文誌

4

1959

対する許可された操作を表す偽装不可能な対として構成される．UNIX システムのファイル記述子

9)は，

ActivityTemplate Course
Role Assistant

Bulletin Board

Role Examinee

Role Approver

ActivityTemplate Examination

Capability と類似したものである．Capability によるシステムは，各々のプロセスに Capability が関連付

Role Student

Role Instructor

Role Grader

Role Examiner
ExamPaper

けられ，Capability に定義された操作を実行すること

ActivityTemplate ExamSessionができる．Capability をアクセス制御の基礎とするシ

Role Checker

ステムのセキュリティは，以下の３つによって担保さ

ExamPaper

AnswerBook

Role Candidate

れる．

Role Reflection
Dynamic Role Assignment
Parameter Object

1. Capability には耐タンパ性があり，偽装不可能
図 1 階層化された処理の記述
Fig. 1 Activity Templateである．

2. プロセスは，認められた特定の手続きによってのみ Capability を獲得する．

3. Capability は，認められたプロセスにのみ与えができる11) ．雛形は，以下のような項目を含む．

• Role の設定

られる．
保護ドメインは，アクセス可能なサブシステムを定• Role 毎に関連付けた処理

義した Capability のセットであり，Capability シス• 生成／アクセスされるオブジェクトタイプ

テムの基本的な発想は，アプリケーションと OS がそ• 生成される子アクティビティの雛形

れぞれの保護ドメインに明確に分離されていることに• ライフサイクル内で生成される動的なイベン
トの設定

よって可能となる．

Role

4. 提案モデルの構成

Role は許可された処理を関連付けられた保護ドメインであり，アクティビティの雛形で定

本節では，提案モデルを構成する各コンポーネント

義されたオブジェクトに対して所定の処理を行う．

についての概要を示す．提案モデルは，分散処理に関Role の定義は，当該 Role に対するセキュリティ

わるアクセス制御情報を記述したポリシー部とそれにドメインの参加可否／ Role に許可された処理／基づいて実際のアクセス制御を実施するアクセス制御

処理が実行されるために必要となる Role の状態に関する三つの定義を含む．

機構部から構成される．

処理の定義

4.1 ポ リ シ ーRole 毎に関連付けられる処理の定義

ポリシーは，あらかじめ定義された構文に基づいてには，事前状態と実際の処理内容が記述される．

アクセス制御情報が記述され，所定の処理を経てアク事前状態の定義は，当該処理を行うために必ず満セス制御機構に権限付与に関する規則を与える．アク

たしていなければならない状態を示し，アクティ

セス制御情報は，{Initiator : Target : Operation} とビティの雛形で定義されるイベントを用いて記述

して記述されるが，提案モデルではアクセス制御情報

する．実際の処理内容は，オブジェクト毎に提供10)される操作や新しいオブジェクトの生成，子アクを AHMED らによる CSCW システム向けの手法

によってグループ化し，動的な権限の付与を実現する．

ティビティの生成を記述する．

また，AHMED らの手法ではユーザに対して Role をセキュリティドメイン 提案モデルにおいては，セ割り当てるが，提案モデルにおいてはあらかじめ粒度

キュリティドメインを定義し，同様のアクセス権が制御されたセキュリティドメインに対して Role の限を必要とするようなインスタンスのグループ化

割り当てを行う．ポリシーのグループ化と動的な権限を行う12) ．Role の割り当ては，セキュリティド

付与は以下の情報を利用して行われる．

メインに対して行われる．

アクティビティの雛形 提案モデルにおいては，アイベント 分散処理の動的な特性を扱うために，イクティビティに応じた雛形を定義し，それに基づ

ベントとイベントカウンター13) を利用する．イベ

いたアクセス制御情報の記述を行う．雛形には，ントは，処理の定義内で記述されることによって分散処理における Role を基礎とした規則の記述

Role の動作を規定するものであるが，具体的にはがなされており，個々のインスタンスに対してはRole によって実行される処理名や子アクティビ

動的に Role を割り当てることによって，雛形にティの生成／削除によって記述される．また，Role

対するインスタンスの割り当てを柔軟に行うことによって実行される各処理には少なくとも startVol. 0ポリシーに基づく分散処理向けアクセス制御モデルの初期的検討

No. 0

された場合は Access Reject を受け取る．

Decision
Information
ADFA

Decision
Request

Env.A

Env.B

SubmitAccessRequestRemoteAccessRequestADFB

TargetInformation
DecisionTargetInformation
Decision

AEFA

5AgentA

SubmitProxy
AccessRequestTCB Boundary

AgentB

SubmitAccessRequestService

Service は，提供する機能単位にオブジェクトをグループ化したインスタンスである．
Decision
RequestAEFB

Present
AccessRequestTCB BoundaryService は AEF からアクセス要求を受け取り，レ
スポンスを返す．Service は複数のオブジェクトが連携することによって機能するものであり，Ser-vice Table Directory に登録されることによってリモートノードからの利用が可能となる．Service

Initiator

SystemA

SystemB

Target

図 2 アーキテクチャ概要
Fig. 2 Architectural Overview

が受け入れ可能な操作は，ポリシーに基づいてService 毎に設定される．
Access Enforcement Function

Access En-

forcement Function(AEF ) は，アクセス制御対と ﬁnish の二つのイベントが関連付けられる．

象へのアクセスを仲介するコンポーネントであり，子アクティビティ アクティビティは，あるサブタ

アクセス制御機構による認可決定を Initiator にスクを行うために子アクティビティを利用するこ強制する．AEF は OS のコンポーネントとしてとができる．子アクティビティは，親アクティビ

実装され，アプリケーション層に定型化された手

ティの制限下で定義され，独立した雛形によって続きを提供する．Initiator は，AEF から提供さ記述される．子アクティビティによって，階層化しれる手続きに Service と操作の名前を含む変数をた処理を記述することが可能であり，子アクティ渡すことによってのみ Service にアクセス可能でビティは親アクティビティの制限下でオブジェク

あり，AEF は Service へのアクセスに関わる詳細

トにアクセスする．

な手続きとデータを隠蔽する役割を果たす．また，

図 1 では，アクティビティと Role による処理の記

AEF は ADF から受け取った情報を元に Service

述例を説明する．この例では，アクティビティcourseの場所を特定し，それがリモートノードであったに instructor ，assistant ，student の３つの Role と場合は Agent に代理アクセスを依頼する．ロー子アクティビティexamination が定義されており，こカルノードであった場合は，Initiator に代わってれには grader ，examiner ，examinee ，approver がRole として設定されている．また，course は，化学Service へのアクセスを行う．
Access Decision Function

Access Decision

や物理などの科目毎に生成することが可能であり，そFunction(ADF ) は認可決定を行うコンポーネン

れぞれで任意の数の examination を生成することが

トであり，AEF からの認可決定要求に対して認できる．さらに examination では，イベント Exam-

可決定と，アクセス許可の場合は Service の場所

Session をトリガーに子アクティビティExamSessionを示す情報を返す．ADF は OS のコンポーネンが生成され，candidate と checker の２つ Role が設トとして実装され，AEF に対するインターフェー定される．メンバーの設定方法は２種類あり，この例
では，role reﬂection によって instructor と assistant

スのみを提供する．

Agent

Agent は分散処理に関わる各ノードに存のメンバーがそのまま grader に，student のメンバー

在し，相互にネットワーク通信を行うコンポーネがそのまま examinee にそれぞれ設定されているが，ントである．各 Agent は互いを識別することがでdynamic role assignment によって変則的にメンバー

き，各 Agent 間は安全な通信を行うことができの設定を行うことできる．

る．Agent はローカルノードの AEF からリモー

4.2 アクセス制御機構

トノードに存在する Service へのアクセス要求をアクセス制御機構のアーキテクチャを図 2 に示す．

受け取り，リモートノードの Agent に代理アクセ

以下に，各コンポーネントについて詳細を述べる．

スを依頼する．代理アクセスを依頼された Agent

Initiator はアクセス要求を発行するイは，サブタスクを生成することによって，あらた

ンスタンスであり，その際はサービス提供を希望

めて Initiator として当該オブジェクト対するア

する Service とそれに対する操作の名前を指定す

クセス要求を発行し，レスポンスを元の Agent にる．また，アクセス要求が許可された場合は AEF

返す．レスポンスを受け取った元 Agent は，ローを仲介したアクセスレスポンスを受け取り，拒否

カルノードの AEF にそれを中継する．

Initiator

情報処理学会論文誌

6
DomainB
Initiator2

DomainA
Initiator1 Initiator2
Initiator3

RoleA

DomainC
Initiator1 Initiator4
Initiator5 Initiator8

RoleB

RoleC

DomainD
Initiator4 Initiator7

RoleD

1959
Decision Request

Initiator

Env.

Submit Access Request[service name : op. name :params]AEF[initiator name : service name :op. name]

Decision

ADF[dir. index : table index]

C-List Lookup [initiator name]

Initiator Table C-List [pointer to capability segment]
Capability Lookup [service name : op. name]

TypeA
Operation1 {Service, Operation, Precondition}
Operation2 {Service, Operation, Precondition}

TypeB
Operation1 {Service, Operation, Precondition}
Operation4 {Service, Operation, Precondition}

図 3 アクセス制御粒度の制御
Fig. 3 Granularity Control

Environment

Environment は OS 内部で保持

Capability List Capability [data structure of capability]
図 4 認可決定の手順
Fig. 4 Decision Making Procedure

提案モデルでは，Role とセキュリティドメインにされる属性情報の集合であり，インスタンス毎によってアクセス制御粒度の制御を行う．図 3 にその様関連付けられた Instance Table と Capability の子を示す．提案モデルにおけるアクセス制御粒度の制リスト (C-List) を含む．Instance Table は，C-

御は，分散処理を構成する最も小さなアクセス制御単List と共にサブタスクの情報を記述するために利位であるインスタンスを段階的にグループ化すること用され階層構造をとることが可能である．Capa-

によって実現される．

bility は，アクセス権限を含む Service の参照情

はじめに，同様のアクセス権限付与が期待されるイ

報であり，アクセス制御機構は Initiator に割り

ンスタンスはセキュリティドメインにグループ化する当てられた Capability を検査することによってアことが可能である．ひとつのインスタンスは複数のセクセス制御を行う．Environment は分散処理に

キュリティドメインに所属することができ，ひとつの関わる各ノード毎に設定され，アクセス制御の際

セキュリティドメインには複数のインスタンスが所属に各コンポーネントから利用される．

することができる．また，ひとつのセキュリティドメ

Capability は，Service の参照情報

インにひとつのインスタンスのみを所属させることにとそれに対する操作を対で記述することによって，よって，細かい粒度のアクセス制御単位を構成するこCapability

Service の参照先を指定するものである．図 2 では，ともできる．また，同様の権限によってアクセスされる

Decision Information と Target Information がことが期待される処理はセキュリティタイプにグルー

Capability から提供される．提案モデルでは，ポプ化することが可能である．セキュリティドメインとリシーに基づいて Capability が生成され，それをセキュリティタイプは，グループ化する対象によってInitiator 毎に関連づける．Initiator は，関連付

名前が異なるが同様の性質を有する．セキュリティタ

けられた Capability に基づいてアクセス対象を

イプは Service への参照情報と操作種別，実行に必要

参照するので，ある Initiator に関連付けられたな状態の組み合わせの集合として構成される．

Capability の集合は，その Initiator がアクセス提案モデルでは，セキュリティドメインとセキュリ

可能な参照先と操作の対の集合である．提案モデティタイプを Role として統合することによって，任意

ルでは，この集合を Capability List(C-List) と呼の粒度でアクセス制御を行うことが可能となる．Role

び，認可決定の際は ADF によって該当アクセス

は，セキュリティドメインとセキュリティタイプをさに必要な Capability の存在を検査される．また，らに上位レベルで抽象的にグループ化するものであ

実際に Service のアクセスを行う際には AEF にり，分散処理でのアクセス権限付与やアクセス権限のよって参照先の指定に利用される．

遷移は Role の付与／変更によって行われる．実際に4.3 アクセス制御粒度の制御

5. プロトコル概要

アクセス制御機構に制御情報を設定する際は，Role
によってグループ化されたインスタンスを再び展開
し，個々の処理を Service と操作の対によって表現し

本節では，提案モデルが動作する仕組みについて，た Capability を生成した上で，Initiator 毎に関連づ

各コンポーネントが連携する手順を示す．特に，アクける．Initiator 毎の C-List は，Initiator に割り当て

セス制御の粒度を制御する手順とアクセス権限の遷る可能性がある Role 単位に生成され，あらかじめア

移を実現する手順，認可決定とそれに基づいて対象リ

クティビティの雛形で定義されたポリシーに基づき，ソースにアクセスする手順に焦点を当てて説明する．

処理の過程で切り替えられていく．

Vol. 0ポリシーに基づく分散処理向けアクセス制御モデルの初期的検討

No. 0

Decision

ADF[dir. index : table index]

AEF

Service Table Lookup [dir. index]

Env.

Service Table
Directory

述子を見つける．この記述子には Service が存在する
ノードの識別子とそのノードの主記憶領域内で Ser-vice Table が存在するベースアドレスが記述されており，AEF はまずノードの識別子から Service がロー

Service Table Location[ip address : base address of service table]

Service Object Lookup [table index]

Service Table

7

Service Object Location[base address of service object]

図 5 参照先特定の手順
Fig. 5 Location Looking up Procedure

カルノードで提供されているのか否かを判定する．

Service の参照先がローカルノードであった場合，
AEF は Service Table Directory 内の記述子から読み込んだ Service Table のベースアドレスを利用してService Table の主記憶内でのベースアドレスを特定
5.1 認 可 決 定

し，ADF から参照情報として渡された Table Index

提案モデルでは，ADF で Capability の検査を行い，を基に特定の記述子を見つける．この記述子には Ser-

それに基づいた認可決定が実施される．図 4 に認可決

vice の最終的な参照先が記述されており，これに基づ

定時に各コンポーネントが連携する様子を示す．

いて AEF が Service へのアクセスを行った後，アクはじめに，Initiator が AEF によって提供される手セスレスポンスを受け取って Initiator へ渡す．

続きに則って Service の名前と操作の名前，パラメー

Service の参照先がリモートノードであった場合，

タによるアクセス要求を行う．AEF は，アクセス要

AEF は Agent にリモートノードへのアクセスを依頼

求を発行した Initiator の名前を特定した上で，受けし，これを受け取った Agent は，該当ノードの Agent

取った Service の名前と操作の名前と共に ADF に渡に代理アクセス要求を発行する．代理アクセス要求をし，認可可否の判定を求める．

受け取った該当ノードの Agent は，自身を Initiator

Initiator ，Service ，操作の名前を受け取った ADFとして，通常のアクセス要求手続きを開始し，アクセ

は，まず Initiator の名前を基に Environment 内のスレスポンスを受け取った上でそれを代理アクセス要

Initiator Table を検索し，該当 Initiator の記述子か求を行った Agent に返す．アクセスレスポンスを受ら C-List を見つける．その後，Service と操作の名前

け取ったローカルノードの Agent は，それを AEF にを基に C-List から，該当 Service 名と操作名を含む

中継し，AEF が Initiator にアクセスレスポンスを記述子によって構成される Capability を検索し，認可返す．

可否の判定を行う．

ADF による認可可否は Capability の有無によって

6. 提案システム評価検討され，Capability がある場合はアクセス許可であ

本節では，提案モデルのセキュリティに関する特性

り，ない場合はアクセス拒否となる．アクセス許可でについて考察する．はじめに，第 3 節で述べたようなあった場合は，同時に該当 Capability から Service へ設計要求を満たすことによって，提案モデルが分散処の参照情報を抽出し，それを AEF に渡すことによっ理におけるアクセス権限の管理を適切に扱えているのてアクセス許可判定とする．アクセス拒否の場合は，かどうかを評価する．その後，いくつかの問題点に対Service への参照情報の代わりに Access Reject が返する提案モデルの有効性を検証する．

される．

5.2 Service の参照

6.1 設計要求評価
第 3 節において，分散処理のアクセス権限管理を共提案モデルでは，ADF による認可決定と同時に Ser-通の枠組みで行うために必要となる特性について検討

vice への参照情報が AEF に提供される．AEF は，こし，７つの機能（細粒度の記述と粒度の制御，権限遷れに基づいて Service の参照先を特定し，それがロー移の記述，サブタスクの記述，認可情報の関連付け，

カルノードであった場合は指定された操作によるアク認可情報と参照情報の不可分，認可情報の委譲，アプ

セスを行う．また，Service の参照先がリモートノー

リケーションとの連携）を導き出した．提案モデルとドであった場合は，Agent に代理アクセスを要求する．

プロトコルは，これらの要求に基づいて設計されて

図 5 に参照先特定時に各コンポーネントが連携する様

いる．

子を示す．

細粒度の記述と粒度の制御は，任意の粒度で記述しはじめに，ADF から Service への参照情報を受けたインスタンスを Role とセキュリティドメインを利取った AEF は，参照情報として渡された Directory

用してグループ化することにより実現される．最上位

Index を基に Service Table Directory から特定の記レベルで抽象化されたアクセス制御情報は，セキュリ情報処理学会論文誌

8

1959

ティドメインとセキュリティタイプを Role として統Capability によるアクセス制御情報を受け渡すことに合することによって表現される．これによって提案モ

よってノード間を移動するインスタンスに対するアクデルは，粒度を適切に調整した上でアクセス制御を行

セス制御を可能としているが，一方でプロセス内のうことができる．

インスタンスの捕捉に関しては，当該プロセスが OS

次に，権限遷移の記述とサブタスクの記述であるが，カーネルから提供される手続きを適切に利用すること

これはイベントと子アクティビティによって実現され，を期待している．これはプロセスに Reference Moni-

特定の処理をトリガーにした権限の遷移やサブタスク

tor の役割を委譲しているものであり，提案モデルはの生成による新たなアクティビティの初期化を制御す

階層的な Reference Monitor 構造をとっているとみることが可能になる．これによって提案モデルは，分ることができる．それぞれの Reference Monitor は散処理における特定の状況化でインスタンスに与える

上位の Reference Monitor の制限内で委譲された範アクセス権限を必要十分なものに変更していくことが囲のアクセス権限管理を行うため，必ずしも最上位のできる．

Reference Monitor である OS カーネルとポリシーがまた，認可情報の関連付け，認可情報と参照情報のすべての処理のアクセス制御ができるとはいえない．

不可分，認可情報の委譲については Capability を利

しかし，そもそもひとつの Reference Monitor が用することによって実現しており，提案モデルのアク

複数ノード間のすべてのアクセスを捕捉するために

セス制御機構は Role 単位に C-List を設定した上では，ローカル／リモートによらず，すべてのアクセス

Initiator に関連付けてアクセス権限を制御する．こが迂回不可能なポイントに Reference Monitor を置く

れによって提案モデルは，ポリシーで記述されたアク必要があるが，一方で，そのようなポイントを設ける

セス権限付与に関する規則に基づいたアクセス制御をのは困難である．そのため，いずれにせよ Reference

適切に強制することが可能になる．

Monitor の階層化を避けることはできない．そのため，最後にアプリケーションとの連携であるが，これはここで重要になるのは上位階層の Reference Monitor

アクセス制御機構がアプリケーション向けにいくつかが下位階層を可能な限り制限して制御することであり，の手続きを提供し，それをアプリケーションが利用す提案モデルにおいてはそれが可能である．

ることによって実現される．

6.2 セキュリティ評価

6.2.2 Confused Deputy Problem
deputy とは，複数のインスタンスから来るアクセ

提案モデルは，第 3 節に挙げたような７つの機能的ス制御要求の認可判断を管理するプログラムである．

な要求に焦点を当てて設計されているが，本節では分

confused deputy は，不適切な認可判断をしてしまう

散処理におけるセキュリティ管理に関して特に考慮すdeputy であり，コンピュータセキュリティにおけるひべき点について検証する．

とつの大きな課題はこれを防ぐことにある．confused

6.2.1 情報フロー制御と Reference Monitor

deputy problem は，World-Wide Web を含む多くの情報フローの制御は，ポリシーに基づいたアクセスシステムにおいて一般的なセキュリティインシデント

制御を強制するために必須であり，これを行うためには Reference Monitor

14)を起こす原因となっている．

がアクセス制御対象となる

一般的な confused deputy problem について，コン

インスタンスをすべて捕捉できなければならない．逆パイラを例に説明する．ここに，課金情報を蓄積するにいうと，Reference Monitor が捕捉できないインス

ための BILL というファイルに書き込み許可されたタンスにアクセス制御を強制するのは不可能であるとコンパイラを仮定する．このコンパイラを実行すると言える．一般的な単一システムにおいては，管理する資き，ユーザはデバッグ情報を出力するファイルを指定

源へのすべてのアクセスに対してシステムコールの利できる．この時，仮にユーザが BILL をデバッグファ

用を強制することによって，OS カーネルが Reference

イル名として指定すると，コンパイラは誤って課金情

Monitor の役割を果たす．これによって，OS カーネ

報をデバッグ情報で上書きしてしまう．このような動ルは，あらかじめ決められたアクセス制御規則を適用

作は，コンパイラに与えられた書き込み権限が誤ったすることが可能になる．

目的に利用されたことによって起こる．仮に，コンパ提案モデルは分散処理に対してアクセス制御を行う

イラが課金情報を書き込む権限とデバッグ情報を書きものであるが，複数ノード間で流動的に移動し，OS込む権限を別々に保有することができれば，BILL へ

カーネルから捕捉不可能なプロセス内のインスタンのアクセス権限はあいまいでなくなる．その上で，コスをアクセス制御対象としている．提案モデルでは，

ンパイラが意図した目的の元に権限を使い分ければ，

Vol. 0ポリシーに基づく分散処理向けアクセス制御モデルの初期的検討

No. 0

confused deputy problem が起こることはない．つまり，アクセス主体が与えられた権限を認識し，それを使い分ければ confused deputy problem を防ぐことが可能になる．
このような目的のために，提案モデルではアクセス権限を capability として Initiator に関連付けているが，一方でこれによって完全に confused deputy を防げるものではない．confused deputy problem を完全に防止するためには，Initiator が目的に基づいて適切
な capability を選択し，利用することが期待される．
提案モデルにおいては，ポリシーに基づいて Initiatorの C-List を切り替えるので，ポリシーが正しく記述されていればこれが可能となる．

7. 結論と今後の課題
本稿においては，分散システムにおける権限管理を適切に行うためのモデルを提案した．提案モデルは，分散処理の権限管理を記述するポリシーの記述法と，これを強制するためのアクセス制御機構から構成される．提案モデルにおいては，アクティビティに応じた雛形を定義し，それに基づいた分散処理の記述を行う．
雛形には，Role を基礎とした規則の記述がなされており，個々のインスタンスに対してはこの規則に基づいて動的に Role を割り当てるので，アクセス権限に対するインスタンスの設定を柔軟に行うことができる．
また，記述されたポリシーを適切に強制するために，提案モデルにおいては Capability を利用したアクセス制御を行う．アクセス制御の際には，各々のインスタンスに設定された Capability の集合である C-Listを検査することによって，認可決定が行われる．また，動的な権限の変更は，C-List をポリシーに基づいて適切に変更することによって実現される．
今後は，実際のシステムに対する提案モデルの実装を検討すると同時に，第 6 節で示した階層的な Refer-ence Monitor について，下位の Reference Monitor
をより細かく制限する手法について検討する．また，分散処理を行う各ノードの Agent 間で安全に情報を交換する手法についても検討していく．加えて，ポリ
シーを各ノードで管理されるテーブルに適切に設定していく手順についても今後の課題とする．

参 考 文 献1) Peter J. Denning, “Fault Tolerant Operating
Systems”, ACM Computing Surveys (CSUR),
v.8 n.4, p.359-389, December 1976.
2) Jonathan M. McCune, Stefan Berger, Ramon

9

Caceres, Trent Jaeger, Reiner Sailer, ”Bridging
Mandatory Access Control Across Machines”,
November 4, 2005.
3) 辻 秀典, 橋本 正樹, 金 美羅, 田中 英彦. “アプリケーション・プラットフォームとしてのセキュア
OS に関する初期的検討”. 情報処理学会 第 38 回
コンピュータセキュリティ研究会, 2007 年 7 月.
4) U. S. Dept. of Defence. ”Department of Defence trusted computer system evaluation criteria,” Dept. of Defence, December 1985.
5) Jerome H. Saltzer, “Protection and the control of information sharing in Multics”, Comm.
ACM, 1974.
6) N. Hardy. “The Confused Deputy (or why capabilities might have been invented)”. Operating Systems Review 22(4), October 1988, pp.
36 - 38.
7) Jerome H. Saltzer, and Michael D. Schroeder.
“The Protection of Information in Computer
Systems”. In Proceedings of the IEEE 63, 9
pp. 1278 - 1308. September 1975.
8) J. B. Dennis and E. C. Van Horn, “Programming Semantics for Multiprogrammed Computations”, Comm. ACM, 1966.
9) K.Tompson, “UNIX implementation”, The
Bell System Technical Journal, 57(6):19311946, July 1978.
10) Ahmed, T. and Tripathi, “Speciﬁcation andveriﬁcation of security requirements in a programming model for decentralized CSCW systems”, ACM Trans. Inf. Syst. Secur. 10, 2(May. 2007), 7.
11) Barkley. J, “Implementing role-based access
control using object technology”, In Proceedings of the First ACM Workshop on RoleBased Access Control (Gaithersburg, Maryland, United States, November 30 - December
02, 1995). C. E. Youman, R. S. Sandhu, andE. J. Coyne, Eds. RBAC ’95. ACM Press, New
York, NY, 20.
12) P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell, “The Inevitability of Failure: The Flawed
Assumption of Security in Modern Computing Environments”, In Proceedings of the 21st
National Information Systems Security Conference, pages 303-314, Oct. 1998.
13) Roberts, P. and Verjus, J.-P, “Toward autonomous descriptions of synchronization modules”, In Proceedings of IFIP Congress, NorthHolland, Amsterdam, 981-986, 1977.
14) J. Anderson, ‘Computer Security Technology
Planning Study” , Air Force Elect. Systems
Div., ESD-TR-73-51, October 1972.