多様なセキュリティ操作を考慮したオブジェクト指向データベースの構造
安東学

松浦 幹太

馬場章

東京大学大学院 情報学環・学際情報学府〒 113-0033 東京都文京区本郷 7-3-1

E-mail: qq16206@iii.u-tokyo.ac.jp, kanta@iis.u-tokyo.ac.jp, baba@hi.u-tokyo.ac.jp
近年、データベースのコンテンツは多様化し、多階層化している。このようなコンテンツには、著作権等の問題が生じることもあり、不正使用によるトラブルも多様化する傾向にある。本稿では、秘匿性の保証だけでなく、多様なセキュリティ操作に適したデータベース構造を考察する。

Object-oriented Databases for Wide Range ofSecurity Management
Manabu ANDO

Kanta MATSUURA

Akira BABA

Interfaculty Initiative in Information Studies,
Graduate School of Interdisciplinary Information Studies,
The University of Tokyo,
7-3-1 Hongo, Bunkyo-ku, Tokyo, 113-0033, Japan
E-mail: qq16206@iii.u-tokyo.ac.jp, kanta@iis.u-tokyo.ac.jp, baba@hi.u-tokyo.ac.jp
When the databases have various and hierarchical contents, it also varies the problems by frauds. In
some application, intricate problems, such as infringement of copyright, can occur. In order to solvethese problems, we describe the structure of database for wide range of security management.

1

はじめにが必要となる。従来のデータベースセキュリティの研究では、アクセス制御を中心としたものが多数を近年、データベースに格納されるコンテンツの形 占めている ([1][2][3][4][5])。つまり、データの秘匿性
態は多様化している。テキストだけではなく、画像 を重視した立場の研究が大部分である。しかし、多や音声、動画を含むデータベースが増加する傾向に 様な形態のコンテンツを保護するには、単純なアクある。また、単一の対象を格納するデータベースで セス制御だけでは不十分である。
あっても、それを様々な手法でデジタル化し格納す

また、セキュリティポリシー設定のための研究も行るデータベースが増加している。つまり、コンテン われているが、これらも大部分は秘匿性を確保するたツが階層構造をもつようになっている。
めの研究である。また、これらは一つのセキュリティアプリケーションによっては、著作権や特許権な ポリシーに各データを適用するものである ([2][3])。
どの問題が生じることもあり、不正使用によるトラ しかし、[6][7] ではデータ形態に応じたセキュリティブルも多様化する傾向にある。そこで、要求される 操作のためのポリシー設定を考察している。この研セキュリティ管理は秘匿性の保証だけでなく、著作権 究からも、多様な形態をもつコンテンツには、各形管理など多様化している。この問題を解決するため 態に応じたセキュリティが必要であるということがには、コンテンツの形態に応じたセキュリティ操作 わかる。

以上のことから、本稿では、各種セキュリティ操Product作に適したデータベースの構造について考察する。
ID
Developers
Product_Information

対象とするデータベースと2

Contents(Image,Text)

要求されるセキュリティ操作

図 1: 製品情報データベース

対象とするデータベース

2.1

対象とするデータベースは、多様な形態を格納す

Product_Info

2.2

要求されるセキュリティ操作例

るものであり、また単一の対象を様々な形態で格納多様な形態をもつオブジェクトに要求されるセキュしているデータベースである。このような条件を満たすデータベースとして、オブジェクト指向データリティ操作の具体例を以下に列挙する。

ベースを取り上げる。以下にオブジェクト指向デー

1. 暗号化
オブジェクトがテキスト形態のとき、暗号化すタベースの概要を述べる ([8])。

ることが必要になる。また、暗号鍵と復号鍵の2.1.1管理についても考慮するべきである。さらに、鍵構成要素管理を徹底することができれば、「内容が見えな• 主体い」という意味でのアクセス制御も実現できる。

2. 認証子
オブジェクトがテキスト形態のとき、そのテキオブジェクトに対し何らかの操作を行う要素を主体と呼ぶ。主体の例は、ユーザやプロセスなストが改竄されていないことを証明するためのどである。

認証子が必要である。電子署名や鍵付き MAC• オブジェクトを使用するのであれば、鍵管理も必要である。

オブジェクト指向データベースにおける客体の3. 電子透かしことであり、主体に操作される要素である。オ

オブジェクトが画像、音声、動画のとき、不正ブジェクトは複雑な構造をもつデータや参照構

コピーの抑止と証拠を残すために、電子透かし造をもつデータなど、様々な形態のデータを扱を埋め込む場合がある。

うことができる。また、オブジェクトは属性と4. ログ
各オブジェクトのメソッドを実行する際には、ロメソッドをもつ。主体はメソッドによってオブジェクトの属性値にアクセスする。

グを取る必要がある。これにより、不正使用を早期に検知することができ、また後々の検証時• 関連に証拠とすることができる。
5. 時間情報の保証

オブジェクト間の何らかの結びつきを関連という。オブジェクト間のメッセージのやり取りに更新時間が正確であることを保証する必要があ

よって処理が進むオブジェクト指向システムでる。また、これを保証することにより、異常なは、関連が重要な役割を担う。

更新時間の発見から不正使用を検知することができる。

2.1.2

具体例

具体例として、製品情報データベースを取り上げる (図 1)。これは単一の製品に関する情報を格納したデータベースの例である。単一の製品情報ではあるが、形態としては「画像」型、「テキスト」型を含んでいる。

3

セキュリティ操作に適したデータベースの構造
多様な構造に応じたセキュリティ操作を可能にするデータベース構造を考えるために、本稿では各セキュリティ操作をメソッドとして定義する。また、セのコンテンツに対し、暗号化と認証子を定義するこ「暗号化コンテンツ」と「認キュリティ操作のためのルールを客体の一つとして とを考える。このとき、扱う。これにより、客体の形態に応じた柔軟なセキュ 証子付きコンテンツ」という二種類のオブジェクトリティ操作を行うことができる。このような構造を が定義されることになる (図 4)。これを一つにして前提として、各種セキュリティ操作に適したデータ しまうのでは、柔軟なセキュリティ操作に適していベースの構造について考察する。

るとはいえない。よって、オブジェクト定義の場合、オブジェクトの増加が問題となる。

3.1

セキュリティ対象となるコンテンツの扱い

Product_Info

Encrypted_Content

Contents

Encrypted_Text

図 1 の例において、Product Info オブジェクトはContents という属性をもつ。この属性は画像型とテ

Authenticated_Content

キスト型をもっている。両者は単一の対象を示すもAuthenticated_Codeのであるが、別の形態になっている。そのため、要図 4: オブジェクトの増加求されるセキュリティ操作は異なる。柔軟なセキュリティ操作を可能にするためには、これらを別のオブジェクトとして表す方法 (図 2) と、別の属性として表す方法 (図 3) が考えられる。

Product_Info

Image_Content
ImageContents

しかし、セキュリティ操作をメソッドで定義するため、各オブジェクトのメソッド数は増加しない。また、セキュリティ操作を増加させるとき、他のオブジェクトに影響を与えることなく定義することができる。
欠点としては、図 4 に見られるように、セキュリティ対象となるコンテンツが分散してしまうことでText_Contentある。

Text

3.1.2

属性定義

図 2: オブジェクト定義
異なる形態の対象を別の属性として定義するとき、3.1.1 の欠点を補うことができる。図 3 に見られるよ

Product_Info
Image
Text

うに、セキュリティ対象となるコンテンツを一元的に管理することができる。また、オブジェクトが増加することもない。セキュリティ操作を増加させたとしても、オブジェクト内の属性が増加するだけである (図 5)。

図 3: 属性定義

3.1.1

オブジェクト定義

Product_Info
Encrypted_
Text
Authenticated_
Code
Watermarked_
Image

異なる形態の対象を別のオブジェクトとして定義するとき、オブジェクトの増加が問題となる。形態

図 5: 属性の増加が増加すれば、それだけオブジェクトも増加するからである。さらに、セキュリティ操作を考慮すると、しかし、逆にメソッドが増加することになる。セ形態の数だけでは収まらない。例えば、テキスト型 キュリティ操作をメソッドで定義するため、それぞれの操作に対する定義が膨大になってしまう。さら 主体が必要以上の権限をもってしまう。オブジェクに、セキュリティ操作を増加させるときにも、メソッ ト定義であれば、更新対象オブジェクト以外のオブドと属性を改めて定義する必要があり、オブジェク ジェクトには影響を与えずに更新作業を行える。よって、更新作業中の不正使用を防ぐことができる。しト全体に影響を与えることになる。

たがって、セキュリティ管理面からはオブジェクト3.1.3

定義が優れているといえる。

比較と分析

以上のことから、多様な形態をもつオブジェクト以上の特徴を踏まえ、両者を比較する。第一に、セ指向データベースには、セキュリティ操作の数だけキュリティ操作を増加させたときのオブジェクト数 オブジェクトを定義する構造が適していると考えらとメソッド数について比較する。オブジェクト定義 れる。のとき、オブジェクト数とメソッド数は必要なセキュリティ操作の数に等しい。一方、属性定義のとき、オブジェクト数は常に一つであるが、メソッド数はセ3.2キュリティ操作の数に等しい。ただし、ここでは一つのセキュリティ操作に対しメソッド数を一つと仮

セキュリティ操作に関するルールの記述

本稿で対象としているデータベースでは、セキュ定する。セキュリティ操作の数が n 倍になったときリティ操作はメソッドで定義する。また、前述したの比例係数を表 1 に示す。

ように、セキュリティ操作を実行するためのルールを客体の一つとしている。ここでは、このルールを定義形態

オブジェクト数

メソッド数

オブジェクトnn

Status と呼ぶ。各種メソッドを実行する際には、必ず Status を参照し、実行する。Status の具体的な内属性1n容を以下に挙げる。

表 1: オブジェクト数とメソッド数の比較

また、オブジェクト定義のとき、オブジェクト数対メソッド数の比は 1 : 1 であるが、属性定義のとき• 各種セキュリティ操作を実行するときの方式やプロトコル• セキュリティ操作に伴う条件
多様なセキュリティ操作を必要とするデータベー

は 1 : n となる。オブジェクト定義においてセキュリ スにおいては、各セキュリティ操作を独自に行うだ
ティ操作数を増やしたとき、オブジェクト数は増加 けでは十分な管理ができない。いくつかのセキュリするが、メソッドは増加させたオブジェクトに対し ティ操作を関連させることによって、必要とされる管てのみ追加すればよい。一方属性定義のとき、オブ 理を実行できる。後者はそのための条件である。こジェクト数に変化はないが、そのオブジェクトのメ れには、[6][7] における必須処理の記述を適用するこ
ソッド数が増加し、一つのオブジェクトに対する負 とができる。例えば、テキスト型のコンテンツを更荷が増加する。この結果から、オブジェクト数とメ 新するとき、「データは暗号化し、認証子を更新しなソッド数に関してはどちらが優れているとはいえな ければならない」というルールを設定することによい。アプリケーションの方針によって決定すること り、データの秘匿性と真正性を保証することができになる。

る。また、Status を管理するためには「Status を更次に、セキュリティ管理面について更新作業の点 新するためのルール」も必要となる。このような内から比較する。更新作業の回数が増えると、対象が 容をもつ Status をどのように定義するかについて考危険な状態にある回数も増える。更新作業中に不正 察する。
使用される可能性もあるということである。このとき、属性定義のような構造であれば更新する必要のない属性が脅威にさらされることもあり得る。図 5の例でいうと、Encrypted Text の更新時にはその他3.2.1

Status オブジェクト定義

Status をオブジェクトとして定義する例を図 6 にの属性も危険な状態になる。また、更新を実行する 示す。この構造では、ルールを一元管理することができる。Status の内容はここで対象とするデータベー散されている Status が適切なものであるかどうか、スにおいて非常に重要な役割を果たすものであるた 常に確認する必要があり、管理が困難となる。
め、一元管理はセキュリティ管理を容易にすると考えられる。また、他にも Status オブジェクトを定義しておけば、参照先を変更するだけで異なるセキュリティ操作を行うこともできる。つまり、拡張性がある。

3.2.3

比較と分析

以上のことを踏まえ、Status のオブジェクト定義と属性定義を比較・分析する。第一に、データ更新への対応について考える。対象とするデータベースにEncrypted_Content

おいて、更新量が最も多いと考えられる客体は、En-

Encrypted_Text
StatusAuthenticated_Content

StatusStatus for Status

Rules

Rules for StatusAuthenticated_Code
Statuscrypted Text のような普通のコンテンツである。逆に、Status for Status は更新の可能性が低い。Statusは更新する可能性はあっても頻繁ではない。このような更新量を仮定するとき、Status を属性定義すると、普通のコンテンツの更新作業中に Status が漏洩

図 6: Status オブジェクト定義

する可能性がある。Status が漏洩すると、無差別改ざんなどの脅威にさらされることも考えられる。ししかし、Status の記述は複雑になってしまう。前たがって、Status を普通のデータと同レベルで管理述したような、数種のセキュリティ操作を関連付け することは、Status の管理に適していないと考えらるための内容を、一つのオブジェクトに記述するの れる。Status は対象とするデータベースにおけるセは困難であると考えられる。

キュリティ操作に対して重要な役割を果たすため、属性定義ではセキュリティ管理に不適当である。

3.2.2

第二に、アクセス要求時の処理について考える。ア

Status 属性定義

クセス要求時には必ず Status を参照することを仮定

Status を属性として定義する例を図 7 に示す。属 する。Encrypted Text の更新を要求すれば、Status性定義にすると、ルールが分散してしまうが、セキュ を参照して「暗号化と認証子の更新」が求められるリティ対象となるデータの形態に応じたセキュリティ ことになる。ここで、不適切な Status があると、要操作が容易である。また、それぞれの記述も容易に 求されるセキュリティ操作を満たすことができない。
オブジェクト定義であっても、属性定義であっても、なる。
不適切な Status があることは、セキュリティ管理にEncrypted_Content

Authenticated_Content

おいて大きな欠陥となり得る。しかし、前述したよう

Encrypted_Text

Authenticated_Codeに両者とも Status の記述が複雑になることは不可避

StatusStatusStatus for Status

Status for Statusである。よって、不適切な Status を早期に発見できるような構造が求められる。Status を一元管理する
ことは、不適切な Status の発見を容易にするため、オブジェクト定義が適当な構造である。
第三に、Status の拡張性について考える。属性定

図 7: Status 属性定義

義のとき、Status を変更・拡張する際に、不整合が生じないようにする必要がある。そのため、一つのしかし、数種のセキュリティ操作の関連付けを考え Status を変更するごとに、全ての Status を変更しなると、属性定義は困難である。セキュリティ操作を関ければならない、という状況も考えられる。これに連付けるためには、適切な Status の記述が必要であより、Status が漏洩してしまったり、新たな不適切るからだ。例えば、図 7 において、Encrypted Textな Status が生じるなど、セキュリティ管理上不適当の更新を認められている主体が Authenticated Code な状態になることもあると考えられる。一方、オブの更新を認められていなければ、このコンテンツの ジェクト定義では、数種の Status オブジェクトを定真正性を保証することはできない。したがって、分義しておけば、参照先を変更するだけで内容を更新することができる。よって、多様なセキュリティ操

teroperable Environments,” Database security

作に対応することができる。

IX : status and prospects : proceedings of theNinth Annual IFIP TC11 Working Conference

以上の比較結果から、Status はオブジェクト定義にしたほうが多様なセキュリティ操作に対応できると考えられる。

on Database Security, pp.43-60. Chapman &Hall, 1996.
[4] 木下宏揚: “データベースのアクセス制御に関す

4る考察, ” 1996 年暗号と情報セキュリティシンポ

おわりにジウム予稿集, 電子情報通信学会, SCIS’96-10D,

多様なセキュリティ操作に適したデータベースの構造について考察し、以下の二点の結論を得た。(1)要求されるセキュリティ操作数のオブジェクトを定義し、コンテンツの各形態を独自に保護する構造が必要である。更新作業中に関係のないコンテンツを保護するということからも、セキュリティ操作に応1996 年 1 月.
[5] 多田共行, 今井秀樹: “オブジェクト指向アクセス制御モデルの考察,” 1998 年暗号と情報セキュリティシンポジウム予稿集, 電子情報通信学会,SCIS’98-4.3.D, 1998 年 1 月.

じたオブジェクトの定義が必要である。(2) セキュリ [6] 工藤道治, 羽田知史: “必須処理付きセキュリティ
ティ操作に関するルールを記述する Status は非常にポリシーのためのアクセス制御モデル,” コンピ
重要な役割を果たすため、オブジェクトとして定義

ュータセキュリティ研究会予稿集, 情報処理学会,

する。これにより、普通のコンテンツの更新時におけpp.149-156. 2001 年 7 月.

る Status の漏洩を防止することができる。また、多[7] Michiharu Kudo and Satoshi Hada: “AccessControl Model with Provisional Actions,” IEリティ操作を関連付けると、Status は複雑な記述にICE Transactions on Fundamentals of Electronなりがちであるが、Status オブジェクト定義で一元階層的なコンテンツを保護するために複数のセキュ管理しておけば不適切な記述を早期に発見することができる。以上の二点が本稿における結論である。今後の課題は、Status の記述方法と記述内容についての考察である。

[1] Eduardo B. Fernandez, Ehud Gudes, andHaiyan Song: “A Model for Evaluation andAdministration of Security in Object-Oriented
Databases,” IEEE Transactions on Knowledge
and Data Engineering, Vol.6, No.2, pp275-292.
IEEE, April, 1994.
Jajodia,[8] 石塚圭樹: オブジェクト指向データベース, アスキー, 1996 年.

参考文献[2] Sushil

ics, Communications and Computer Sciences,
E84-A, pp295-302. January, 2001.

Pierangela

Samarati,V.S.Subrahmanian, and Elisa Bertino:“AUnified Framework for Enforcing Multiple
Access Control Policies,” Proceedings of International Conference on Management of Data,
pp.474-486. ACM SIGMOD, May, 1997.
[3] Dirk Jonscher and Klaus R. Dittrich: “Argos–A Configurable Access Control System for In-