JP2006502472A

JP2006502472A - リレーショナル・データベースへのアクセスを制御する方法

Info

Publication number: JP2006502472A
Application number: JP2004533614A
Authority: JP
Inventors: コンター、カート; ミラー、ロジャー、リー
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2002-09-04
Filing date: 2003-09-02
Publication date: 2006-01-19
Anticipated expiration: 2023-09-02
Also published as: US20070244898A1; CN100444180C; US7464080B2; WO2004023375A8; AU2003260770A1; US20090030907A1; US20170053133A1; US9514328B2; US20090043775A1; AU2003260770A8; TWI249111B; JP4398371B2; CN1729469A; US8478713B2; WO2004023375A1; US7240046B2; US20040044655A1; TW200412515A; US9870483B2

Abstract

【課題】データベース管理システム用の多レベル的かつ強制的なアクセス制御を実現するアクセス制御システムとアクセス制御方法を提供する。
【解決手段】このアクセス制御手法はリレーショナル・データベースのテーブル中に行レベルのアクセス制御を実現する。このデータベース・テーブルはセキュリティ・ラベル列を備えている。その中には階層型セキュリティ機構中において定義されているセキュリティ・ラベルが記録されている。一方、ユーザのセキュリティ・ラベルは当該ユーザに関するセキュリティ情報を用いて符号化されている。ユーザがある行へのアクセスを要求すると、セキュリティ機構は当該ユーザのセキュリティ情報と当該行中のセキュリティ情報とを比較する。当該ユーザのセキュリティが当該行のセキュリティを上回っていれば、当該ユーザに当該行へアクセスを許可する。

Description

本発明は情報処理システムに関し、特にデータベース管理システムにおけるアクセス制御を実現することに関する。

ワールド・ワイド・ウェブ（「ウェブ」）とｅビジネス・ソリューションが拡大するのにつれ、データベースのセキュリティとプライバシとがますます重要になりつつある。データベースのセキュリティの重要性を際立たせている別の動きが、（ウェブ・ホスティングとも呼ばれる）サーバ上でウェブ・サイトをホスティングすることである。ウェブ・サーバは顧客のデータを多数の関係テーブル中に格納するリレーショナル・データベースを備えている。ウェブ・ホスティングを行う会社はその出費を最小化するために、多数の顧客に由来するデータを単一のデータベース管理システムに格納しようとする。しかし、顧客数が増大するとウェブ・ホスティングを行う会社が従来使用していたデータベース管理システムで得られるセキュリティよりも高度のセキュリティが必要になる。このことは、複数の顧客のウェブ・サイトとデータをホストするためにデータベース管理システムを使用する場合に特に顕著である。

顧客の中にはデータ項目（たとえばデータベースの行）へのアクセスをすべて制御する強制アクセス制御を必要とするものもいる。また、多レベルのアクセス制御を同時にサポートする階層型セキュリティ機構を使用する必要のある顧客も多数存在する。強制アクセス制御と階層型セキュリティ機構についてのこれらの概念は周知である。たとえば、それらは国防総省標準ＤｏＤ５２００．２８−ＳＴＤ（国防総省高信頼コンピュータ・システム評価基準〔１９８５年１２月〕）（DoD 5200.28-STD, Department of Defense Trusted Computer System Evaluation Criteria, December 1985.）に記載されている。

既存のデータベース（たとえばトムソン（Thomson)らの米国特許第５７５１９４９号に記載されているデータベース）では、テーブルと当該テーブルのビュー（view）とに基づいてセキュリティを実現している。少なくとも１つのデータベース・テーブル中の選択済みの行と列へのアクセスを制限するのにビューを使用することができる。たとえばトムソンらの特許では、ユーザの認証情報を格納したセキュリティ・テーブルとデータ・テーブルとを結合するのにビューを使用している。しかし、一部のユーザ（たとえばシステム管理者など）はビューを迂回してテーブルに直接にアクセスすることにより、ビューが提供するアクセス制御を回避することができる。また多くの場合、所望のレベルの細分度を有するビューを構築するのはデータベース管理者とアプリケーション・プログラマにとって煩瑣（はんさ）である。ビューは読み出し専用（read-only)アクセスの場合には効率的になる可能性があるが、更新、挿入、および削除の場合にはそれを定義するのが困難である。更新を制御するには、トリガを準備すること、データベースを制約すること、手順を格納しておくことが必要になる場合が多い。
米国特許第５７５１９４９号米国防総省標準ＤｏＤ５２００．２８−ＳＴＤ（国防総省高信頼コンピュータ・システム評価基準〔１９８５年１２月〕）（DoD 5200.28-STD, Department of Defense Trusted Computer System Evaluation Criteria, December 1985.）

個別のユーザ・アクセスを特定の行の組に限定しうるように、多くのアプリケーションはリレーショナル・データベース中に行レベルのセキュリティを備える必要があるが、そのセキュリティ制御を強制することが求められている。アクセス制御を強制すれば、ユーザ、アプリケーションのプログラマ、およびデータベース管理者は行レベルのセキュリティ機構を迂回することができなくなる。

本発明によれば、次に示す方法が実現される。
リレーショナル・データベースへのアクセスを制御する方法であって、
前記データベースに属すデータを求めるユーザの要求を受領するステップであって、前記要求はデータベース操作を実行する要求およびユーザのセキュリティ・ラベルを含んでいる、ステップと、
前記ユーザのセキュリティ・ラベルに基づいてユーザのセキュリティ情報を確認するステップと、
前記ユーザの要求に応答して、前記データベース中のテーブルから、データから成る少なくとも１つの行を検索・取得するステップであって、前記少なくとも１つの行はセキュリティ・ラベルを備えている、ステップと、
前記少なくとも１つの検索・取得した行のセキュリティ・ラベルに基づいて前記少なくとも１つの検索・取得した行用の行のセキュリティ情報を確認するステップと、
前記少なくとも１つの検索・取得した行につき、前記ユーザのセキュリティ情報および前記行のセキュリティ情報に基づいて前記ユーザが前記行にアクセスするのを許可されているか否かを判断するステップと、
前記ユーザがアクセスするのを許可されていると判断した場合、前記少なくとも１つの行を返すステップと
を備えた
方法。

前記要求はビューのクエリを含んでいないのが望ましい。前記要求は前記データベースへのユーザのアクセスを制限するアクセス制御情報を含むテーブルの結合を要求しないのが、さらに望ましい。好適な一実例では、前記データベース操作はクエリである。別の好適な実例では、前記データベース操作は行の更新を含んでいる。

行のセキュリティ情報を確認する前記ステップが、前記行のセキュリティ・ラベルに対応する行のセキュリティ情報用のキャッシュを検査するステップを含んでいるのが好適である。各ユーザのセキュリティ・ラベルまたは各行のセキュリティ・ラベルが、セキュリティ・レベル群から成る階層中にそれぞれ配置された複数のユーザのセキュリティ・ラベルまたは複数の行のセキュリティ・ラベルのうちの１つであるのがより好適である。前記ユーザのセキュリティ・ラベルが、前記検索・取得した行のセキュリティ・ラベルが示しているセキュリティ・レベル以上のアクセスの程度を有するセキュリティ・レベルに対応している場合にだけ、前記ユーザは前記検索・取得した行にアクセスしうるように許可されていると判断するのがさらにより好適である。

好適な実例では、前記検索・取得した行のセキュリティ・ラベルが、前記ユーザのセキュリティ・ラベルに対応するセキュリティ・カテゴリ群の適正なサブセットであるセキュリティ・カテゴリ群に対応している場合にだけ、前記ユーザは前記検索・取得した行にアクセスしうるように許可されていると判断する。

望ましいことに、次に示す装置が実現される。
データ・マネージャおよびデータベースを備えたデータベース管理システム中で使用する装置であり、前記装置はユーザが、前記データベース中に保持されているデータから成る行について要求した操作を実行しうるように許可さているか否かを判断し、前記ユーザはユーザのセキュリティ・ラベルに関連付けられており、前記行は行のセキュリティ・ラベルを備えている、装置であって、
セキュリティ・ラベル群から成る階層をその中に記録したユーザ・セキュリティ・ユニットと、
前記ユーザ・セキュリティ・ユニットに接続され、かつ、前記データ・マネージャと前記データベースとの間に接続された読み取りセキュリティ・ユニットであって、前記ユーザのセキュリティ・ラベルが、前記行のセキュリティ・ラベルの配置先である、前記階層中のレベル用の特権以上である特権を有する、前記階層中のレベルに配置されている場合にだけ、前記データベースから前記データ・マネージャに前記行を返すように構成された読み取りセキュリティ・ユニットと
を備えた
装置。

一実例では、前記セキュリティ階層中の前記セキュリティ・ラベルは前記セキュリティ・ラベルに付随するセキュリティ・カテゴリを表している。そして、前記読み取りセキュリティ・ユニットは前記行のセキュリティ・ラベルに付随するセキュリティ・カテゴリ群が、前記ユーザのセキュリティ・ラベルに付随するセキュリティ・カテゴリ群の適正なサブセットである場合にだけ、前記データベースに属す前記要求された行を前記データ・マネージャに返すように構成されている。

さらに、前記装置は前記データ・セキュリティ・ユニットに接続され、かつ、前記データ・マネージャと前記データベースとの間に接続されているとともに、前記要求された操作が行を更新する操作である場合に前記行のセキュリティ・ラベルを前記ユーザのセキュリティ・ラベルと同一の値に設定するように構成された書き込みセキュリティ・ユニットを備えているのが望ましい。また、前記書き込みセキュリティ・ユニットは前記ユーザがより低いレベルのセキュリティ・ラベルを備えた行を更新するしうるように許可されている場合であり、かつ、前記より低いレベルのセキュリティ・ラベル用に指定されたセキュリティ・カテゴリ群が、前記ユーザのセキュリティ・ラベルに付随するセキュリティ・カテゴリ群の適正なサブセットである場合に前記行のセキュリティ・ラベルを前記ユーザのセキュリティ・レベルよりも低いレベルに設定するように構成されているのがさらに望ましい。

好適なことに、次に示すプログラム製品が実現される。
リレーショナル・データベースへのアクセスを制御する、コンピュータ読み取り可能な媒体に記録したプログラム製品であって、
前記データベースに属すデータを求めるユーザの要求を受領するプログラム命令であって、前記要求はデータベース操作を実行する要求およびユーザのセキュリティ・ラベルを含んでいる、プログラム命令と、
前記ユーザのセキュリティ・ラベルからユーザのセキュリティ情報を確認するプログラム命令と、
前記ユーザの要求に応答して、前記データベース中のテーブルから、データから成る行を検索・取得するプログラム命令であって、前記行は各々、セキュリティ・ラベルを備えている、プログラム命令と、
前記検索・取得済みの行の各々につき、前記ユーザのセキュリティ情報および前記行のセキュリティ情報に基づいて前記ユーザが前記行にアクセスするのを許可されているか否かを判断するプログラム命令と、
前記ユーザがアクセスするのを許可されている、と判断されたアクセス先の行だけを返すプログラム命令と
を備えた
プログラム製品。

好適な実例では、次に示す方法が実現される。
データベースの少なくとも１つの行中のデータへのアクセスを制御する方法であり、前記少なくとも１つの行は行レベルのアクセス制御情報に関連付けられている、方法であって、
前記データベースを操作する要求をユーザから受領するステップと、
前記要求に合致する、前記データベースの行の各々につき、前記ユーザに付随するセキュリティ・レベルと前記行に付随するセキュリティ・レベルとを比較することにより、前記要求に合致する、前記データベースの行に強制アクセス制御の規則を適用するステップと
前記行に付随する前記セキュリティ・レベルが前記ユーザのセキュリティ・レベルの少なくともサブセットである場合、前記行に属すデータを返すステップと
を備えた
方法。

前記要求は前記データベースの前記少なくとも１つの行へのアクセスを制限する、前記データベースの事前に定義されたビューを求める要求ではないのが望ましい。前記方法は前記データベースの前記少なくとも１つの行へのアクセスを制限するために前記受領した要求を変更しないのが望ましい。前記要求はＳＱＬ（Structured Query Language)クエリであるのがさらに望ましい。好適な実例では、前記データベースは複数のテーブルから成る。そして、前記受領した要求には前記複数のテーブルへのアクセスを求める要求が含まれる。

望ましいことに、次に示す方法が実現される。
データベースの行中のデータへのユーザのアクセスを制御する方法であり、各行はアクセス・レベルの階層中の第１のアクセス・レベルに関連付けられており、前記ユーザは前記アクセス・レベルの階層中の第２のアクセス・レベルに関連付けられており、各アクセス・レベルは少なくとも１つの特権に関連付けられており、これらのアクセス・レベルは階層的な態様で関連している、方法であって、
前記データベースを操作する要求を前記ユーザから受領するステップと、
前記第１のアクセス・レベルに付随する特権が、前記第２のアクセス・レベルに付随する特権に含まれるか否かを判断することにより、前記ユーザが、前記要求に合致する、前記データベース中の行を操作しうるように許可されているか否かを判断するステップと、
前記ユーザが前記行を操作しうるように許可されている、と判断した場合にだけ、前記行に属すデータを返すステップとを備えた方法。

ここで説明するシステムと手法はリレーショナル・データベース中に行レベルの強制セキュリティを実現するものである。それらには、今日入手できる既存のデータベース・システムを超える多くの利点がある。それらによって、次に示す特徴を有するセキュリティ実行機構を実現することができる。すなわち、強制的かつ自動的であること、既存のＳＱＬ（Structured Query Language)ビューまたはＳＱＬクエリでは表現するのが困難であろうセキュリティ機構を実現できること、および、行レベルのセキュリティ検査を行うことに付随する処理上の制約と所要時間のオーバーヘッドを最小化する、パフォーマンスの最適化を行うことができることである。また、ここで説明するシステムと手法は行レベルのセキュリティ制御を実現するのに特別のビューまたはデータベースのセッション変数に依存する必要のないセキュリティ実行機構をも実現する。

本発明の一実例はリレーショナル・データベースへのアクセスを制御する方法に関する。前記方法は前記データベースに属すデータを求めるユーザの要求を受領するステップであって、前記要求はデータベース操作を実行する要求およびユーザのセキュリティ・ラベルを含んでいる、ステップを備えている。前記ユーザのセキュリティ・ラベルからユーザのセキュリティ情報を確認する。前記ユーザの要求に応答して、前記データベース操作に合致する、データから成る行を前記データベース中のテーブルから検索・取得する。前記行は各々、セキュリティ・ラベルを備えている。前記方法はさらに、前記検索・取得した行の各々用の、行のセキュリティ情報を当該行のセキュリティ・ラベルに基づいて確認するステップを備えている。前記検索・取得した行の各々について、前記方法は前記ユーザが、前記行にアクセスしうるように許可されているか否かを前記ユーザのセキュリティ情報および前記行のセキュリティ情報に基づいて判断する。前記ユーザがアクセスするのを許可されている、そのアクセス対象の行だけを返す。

さらに別の実例では、データ・マネージャおよびデータベースを備えたデータベース管理システム中で使用する装置が、ユーザが、前記データベース中に保持されているデータから成る行に対する、要求された操作を実行しうるように許可されているか否かを判断する。前記ユーザはユーザのセキュリティ・ラベルに関連付けられており、前記行は行のセキュリティ・ラベルを備えている。前記装置はセキュリティ・ラベル群から成る階層を内蔵したユーザ・セキュリティ・ユニットを備えている。それは前記ユーザ・セキュリティ・ユニットに接続され、かつ、前記データ・マネージャと前記データベースとの間に接続された読み取りセキュリティ・ユニットをも備えている。前記読み取りセキュリティ・ユニットは前記ユーザのセキュリティ・ラベルが前記階層において、前記行のセキュリティ・ラベルが配置されている、前記階層中のレベル用の特権以上である特権を有するレベルに配置されている場合にだけ前記データベースから前記データ・マネージャに前記行を返すように構成されている。

ユーザが発行する要求はビューのクエリを含んでいる必要はない。また、それは前記データベースへのユーザのアクセスを制限するのに、アクセス制御情報を含んだテーブルを結合することも必要としない。

本発明の特徴および利点は次に示す記述、およびその特定の実施形態を説明する図面を考察することにより明らかになる。それらの記述は本発明の特定の細部にわたっているけれども、理解すべき点を挙げると、諸変形例はありうるし現にあるが、ここにおける記述に基づいて当業者にとって明らかであろう。

下で説明する実施形態は図面を参照して記述されている。図中、同一の参照符号は同一の構成要素を表す。

既存のデータベース管理システム（ＤＢＭＳ）の中にはデータベース中の行へのアクセスを制限する機能をいくつか備えたものがある。しかし、そのような既存のシステムはアクセスを必要な行に制限するビューの作成をデータベース管理者に任せている。したがって、アプリケーションのプログラマはそれら特別のビューを使用してセキュリティ制御を実現しなければならない。したがって多くの場合、アプリケーションのプログラマはデータ行へのアクセスを制御するのにそれらのビューが使用する値をセッション変数に代入しなければならない。そのような既存のシステムでもプログラマはデータへのアクセスを制御することができるが、それらのシステムにはいくつかの不都合がある。

たとえば、既存のＤＢＭＳでは、データベースへのアクセスを制御するのにビューを使用している。データベースへのアクセスを制御するのにビューを使用することは、データベース管理者とアプリケーションのプログラマにとって実現するのが面倒である。たとえば、セキュリティ機構における各セキュリティ・レベル（たとえば TOP＿SECRET VIEW 、SECRET VIEW など）ごとに個別のビューを生成する必要がある、というのが普通ではある。

また、アクセスを制御するのにビューを使用すると、誤りが発生しやすくなる。というのは、ビューを不正確に実現すること、および、間違ったデータ行へのアクセスをうっかり許可してしまうことが起こりがちだからである。さらに、セキュリティ機構の中にはビューすなわちユーザのクエリ上で追加の述語（predicate)として表現するのが困難なものがある。ユーザ・アプリケーションの論理すなわちビューの変更を不要にしてデータへのアクセスを自動的に実行しうるようにすることが求められている。

ビューを用いて達成されるセキュリティ・ポリシは強制的なものではなく、単に自由裁量的であるに過ぎない。人はデータベース管理者の権限を備えれば、セキュリティ機構を実現する特別のビューを使用することなくデータベース中のデータを閲覧することができる。エンド・ユーザ、アプリケーションのプログラマ、およびデータベース管理者による無許可のアクセスを避けうる強制的なセキュリティ制御を実現することが求められている。データベース中のデータへのアクセス権を用いてユーザの活動領域を制限するには、データへの無制限のアクセス権を有する個人をシステムのセキュリティ管理者にだけする必要がある。

図１は複数のウェブ・サイト（すなわちウェブ・サイト１２ａ、ウェブ・サイト１２ｂ、ウェブ・サイト１２ｃ）をホストするウェブ・サーバ１０を備えた既存のデータベース・アプリケーションをシステム・レベルで示す図である。ウェブ・サーバは複数のクライアント（たとえばクライアント１６ａ、１６ｂ）との接続を提供するデータ通信ネットワーク１４（たとえばインターネット）に接続されている。ウェブ・サーバは各ウェブ・サイトにサービスを提供する単一のＤＢＭＳ１８を備えている。このＤＢＭＳは複数のウェブ・サイトが使用するデータを管理している。上記ウェブ・サーバは多くのウェブ・サイトをホストし、しかも単一のＤＢＭＳがこれら多くのウェブ・サイトにサービスを提供しているから、ある個人が、ウェブ・サーバ１０がホストしているあるウェブ・サイトを使用して、別のウェブ・サイトに属すデータに無許可のアクセスを行うのを防止するためにセキュリティを備える必要がある。既存のウェブ・サーバでは、ＤＢＭＳはクエリ・プロセッサ２０とデータ・マネージャ２２を備えている。ＤＢＭＳ１８は当該ＤＢＭＳが管理しているデータを保持するデータ・リポジトリ２４に接続されている。

クエリ・プロセッサ２０はウェブ・サイトにおいてクライアントから受信する、クエリを含む要求を処理する。たとえば、典型的なクエリはウェブ・サイトにおいて受信するＳＱＬ（Structured Query Language)クエリである。このＳＱＬクエリはクエリ・プロセッサ２０に渡し、ＤＢＭＳによる解析と実行の用に供する。このクエリに基づき、クエリ・プロセッサ２０はデータ・マネージャ２２がデータ・リポジトリ２４と対話して適切なデータ処理を行い当該クエリを満足させるように制御する。

図２（ａ）は図１に示すＤＢＭＳ中に保持されている既存のユーザ・テーブル（USER.TABLE) ２６の一例を示す図である。このテーブルは様々なデータの列（図２（ａ）ではＣＯＬ１、ＣＯＬ２、ＣＯＬ３とラベル付けして示されている）を備えている。このユーザ・テーブルはセキュリティ・ラベル（SECLABEL）の列も備えている。各行は特定のセキュリティ・ラベルに関連付けられている。ここでは、セキュリティ・ラベルとして様々な色（たとえばRED （赤) 、BLUE（青) 、YELLOW（黄）、GREEN （緑) など）の名前を用いている。各色の名前はユーザ・テーブルの行に関連付けられたセキュリティ上の特権の特定の組を表している。たとえば、「RED 」なるセキュリティ・ラベルは当該ラベルに関連付けられたアクセス特権から成る１つの組を有する。一方、別のセキュリティ・ラベル（たとえば「BLUE」なるセキュリティ・ラベル）は別の特権から成る組に関連付けられている。

既存のＤＢＭＳては、USER.TABLEへのアクセスはデータベースのビューがが制御している。システム管理者はユーザのセキュリティ・ラベルに基づいてアクセスを制限するために、データベース中の関連するテーブルから成るビューを作成する。

システム管理者はたとえば図２（ｂ）に示すＳＱＬステートメントを用いてテーブルを作成する。ここでは、システム管理者はUSER.VIEW （２８ａ）と呼ぶビューを作成する。この場合、当該ビューは３つの列（すなわちＵ．ＣＯＬ１、Ｕ．ＣＯＬ２、Ｕ．ＣＯＬ３）から選択する（図２のライン２８ｂ参照）。これらの列は図２（ａ）に示すUSER.TABLEから選択する。セキュリティ・テーブル（SECURITY.TABLE) ３０はユーザＩＤ（USERID）とセキュリティ・ラベル（SECLABEL) （たとえばセキュリティ・ラベル「RED 」「BLUE」「GREEN 」など）とを関係付けている。図２（ｂ）のライン２８ｄが要求しているのは、ユーザのセキュリティ・ラベルがセキュリティ・テーブル中で定義されているセキュリティ・ラベルに等しいこと、および、セキュリティ・テーブル中のユーザＩＤが現在のユーザに等しいことである。これにより、現在のユーザのセキュリティ・ラベルに等しいセキュリティ・ラベルを有する、図２（ａ）のUSER.TABLE中にある行にだけにアクセスを限定することが可能になる。この既存のアクセス制御機構によってもアクセス制御をある程度行いうるが、それは階層的なセキュリティ機構をサポートしていない。

図２（ｃ）はセキュリティ・テーブル３０と、図２（ｂ）のＳＱＬステートメントをUSER.VIEW （３２）に適用すると得られるビューとの間の関係を示す図である。ユーザ「SALLY 」がUSER.TABLE（２６）にアクセスするために図２（ｂ）のビューを適用する場合、その結果を図２（ｃ）に示す。この場合、図２（ｃ）において、ユーザSALLY がUSER.TABLEへのアクセスを要求すると、図２（ｂ）のビューはテーブル２６のSALLY のビューを図２（ｃ）に示すUSER.VIEW(３２）に限定する。このビューをテーブル２６に適用すると、USER.TABLE（２６）にSECURITY.TABLE（３０）が結合されてUSER.VIEW （３２）が得られる。

図２（ｄ）はユーザSALLY が要求するクエリの一例３４を示す図である。SALLY のクエリにはUSER.VIEW からすべての行を選択する「選択」ＳＱＬ文節が含まれている。既存のＤＢＭＳシステムは図２（ｂ）に示すビューを図２（ａ）に示すUSER.TABLE（２６）に適用することにより動作している。図２（ｃ）のSECURITY.TABLE（３０）に示すように、SALLY のセキュリティ・ラベルは「BLUE」である。したがって、結果として得られるユーザ・ビュー３２は「BLUE」なるセキュリティ・ラベルに等しいセキュリティ・ラベルを有する、USER.TABLE（２６）中の行だけを含んでいる。このように、既存のＤＢＭＳはユーザのアクセスを一部の行だけに制限している。しかし、既存のアクセス制御手法は階層型のセキュリティ機構をサポートしていないから、アクセスを制限するのにビューを使用する必要がある。

既存のデータベース管理システムに付随するこれらの課題（problem)は行レベルのセキュリティを実現する次に示す概念を用いることにより克服することができる。

（１）データベース管理システムの各エンド・ユーザにSECURITY＿LABEL を割り当てる。このラベルは多レベル型セキュリティ機構中における当該ユーザ用のセキュリティ・レベルを定義するとともに、データベース中のデータにアクセスするための特権をいくつか定義している。また、このセキュリティ・ラベルは当該ユーザがアクセスしうる、上記セキュリティ・レベル中のセキュリティ・カテゴリも特定している。セキュリティ・カテゴリの例としては、上記ユーザが従事するのを許可されたソフトウェア開発プロジェクトが挙げられる。たとえば、所定のユーザはあるセキュリティ・レベル（たとえば次に示すようなセキュリティ・レベル：TOP SECRET、SECRET、UNCLASSIFIED）によって指定されているデータを閲覧することができる。また当該ユーザには、数個のカテゴリ（たとえばプロジェクトABC 、DEF 、XYZ ）に属すデータにアクセスすることを許可してもよい。セキュリティ・ラベルのもとに格納する値はセキュリティ・レベルとセキュリティ・カテゴリの情報を、セキュリティ体系を形成するように表現する態様で符号化する。このような符号化の一例としてラベルSECRETABC が挙げられる。ただし、「SECRET」はセキュリティ・レベルを特定しており、「ABC 」はセキュリティ・カテゴリＡ、Ｂ、Ｃを特定している。セキュリティ・カテゴリＡ、Ｂ、Ｃには、ユーザが従事するように割り当てられたプロジェクトの識別子を用いることができる。

ユーザのセキュリティ・ラベルは様々な手法を用いて決めることができる。たとえば、ユーザのセキュリティ・ラベルは関係ＤＢＭＳのカタログを使用する探索（lookup）によって、外部のセキュリティ・マネージャに対してセキュリティ呼び出しを行うことにより、あるいは、信頼できるインストール出口ルーチンを呼び出すことにより決めることができる。理解しうるように、ユーザのセキュリティ・ラベルを決めるのに他の手法を用いてもよい。

（２）セキュア・テーブル（secure table）中の各行とセキュリティ・ラベルとを関連付ける。このセキュリティ・ラベルには上記セキュリティ・テーブル（security table）中の列を使用することができる。たとえば、上記列には事前に定めた名前（たとえばSECURITY＿LABEL)を付与することができる。あるいは、上記列は上記テーブルを特定するときにＳＱＬ文節によって（たとえば、CREATE TABLE列定義におけるSECURITY LABLEとして）特定することができる。理解しうるように、セキュリティ・ラベルと行とを関連付けるのに他の手法を用いてもよい。

行中のSECURITY＿LABEL 列は当該行に含まれるデータのセキュリティ・レベルを特定するとともに、当該行の適用先であるセキュリティ・カテゴリを特定している。たとえば、行にはプロジェクトABC （なるセキュリティ・カテゴリ）およびプロジェクトXYZ （なるセキュリティ・カテゴリ）に属し、「SECRET」なるセキュリティ・レベルを有するデータを含めることができる。SECURITY＿LABEL のもとに格納する値はセキュリティ・レベルとセキュリティ・カテゴリの情報を、セキュリティ体系を形成するように表現する態様で符号化する。

（３）強制セキュリティ執行機構がセキュアなデータ行に対する読み取りアクセスを制御する。この機構はリレーショナル・データベースのテーブルがSECURITY＿LABEL 列を含んでいることが判明したら自動的に起動する。この読み取りセキュリティ執行機構は当該ユーザのセキュリティ・ラベルと当該行のセキュリティ・ラベルとを比較してアクセスを許可すべきか否かを判断する。読み取りアクセスが許可されるのは当該ユーザのセキュリティが当該行のセキュリティを上回っている場合だけである。その場合、次に示す条件の双方が真になる。
（ａ）当該ユーザのセキュリティ・ラベルが示すセキュリティ・レベルが当該行のセキュリティ・ラベルが示すセキュリティ・レベル以上である。
（ｂ）当該行のセキュリティ・ラベルに付随するセキュリティ・カテゴリが当該ユーザのセキュリティ・ラベルに付随するセキュリティ・カテゴリの適正なサブセットである。

書き込みアクセスを別に制御しているから、ユーザに、当該ユーザよりもセキュリティ・レベルの高い行から読み出さない、あるいは、当該ユーザよりもセキュリティ・レベルの低い行に書き込まない、という一般的な規則を遵守（じゅんしゅ）することを強制することができる。

読み出しアクセス・セキュリティ機構と書き込みアクセス・セキュリティ機構は次に示すような様々な手法を用いてアクセス機構を実現することができる。たとえば、リレーショナルＤＢＭＳのカタログを用いた探索を使用する手法、外部のセキュリティ・マネージャのセキュリティ呼び出しを使用する手法、あるいは、信頼できるインストール出口ルーチンに対する呼び出しを使用する手法などである。

（４）強制セキュリティ執行機構がセキュアなデータ行に対する書き込みアクセスを制御する。この機構はリレーショナル・データベースのテーブルが特定の列名を含んでいることが判明したら自動的に起動する。この機構はデータベースに書き込むべき更新済みのデータ行に記録するセキュリティ・ラベルを決める。この書き込みアクセス・セキュリティ機構はそれら更新済みの行の各々が次に示す、とりうる値群のうちの１つを含むように強制する。すなわち、
（ａ）更新済みの行用のセキュリティ・ラベルとして、ユーザのセキュリティ・ラベルと同一であるセキュリティ・ラベルを使用する。
（ｂ）あるユーザが特に権限を付与されている場合、当該ユーザは当該ユーザの現在のセキュリティ・ラベルが示すレベルよりも低いレベルを有する、行のセキュリティ・ラベルを用いて行を更新することができる。
書き込みアクセス・セキュリティ機構は当該ユーザのセキュリティが行のセキュリティを上回っているか否かを検査して次に示す条件がすべて真であることを確認した後、当該行の更新を許可する。
（ｉ）当該ユーザは、当該ユーザのセキュリティ・ラベルに付随するセキュリティ・レベルよりも低いセキュリティ・レベル用に指定されたセキュリティ・ラベルを備えた行にデータを書き込みうるように特に権限を付与されている。
（ii) 当該行用に指定されたセキュリティ・ラベルのセキュリティ・レベルは当該ユーザのセキュリティ・ラベルに付随するセキュリティ・レベル以下である。
（iii)当該行用に指定されたセキュリティ・ラベル用のセキュリティ・カテゴリは当該ユーザのセキュリティ・ラベルに付随するセキュリティ・カテゴリの適正なサブセットである。すなわち、当該行のラベルに付随するすべてのセキュリティ・カテゴリは当該ユーザのセキュリティ・ラベルにも関連付けられている。

書き込みアクセス・セキュリティ機構は様々な手法を用いてアクセス方式を実装している。たとえば、それは、リレーショナルＤＢＭＳのカタログを用いて探索を実行しうるし、外部のセキュリティ・マネージャをセキュリティ呼び出しすることができるし、あるいは、信頼できるインストール出口ルーチンに対する呼び出しを行うことができる。

強制アクセス制御を行レベルでサポートするＤＢＭＳを図３に示す。ここでは、ＤＢＭＳ１８はクエリ・マネージャ２０およびデータ・マネージャ２２に加え、読み取り強制セキュリティ・ユニット３６および書き込み強制セキュリティ・ユニット３８も備えている。ＤＢＭＳ１８の典型的な実施形態はオペレーティング・システムｚ／ＯＳ(R) 用のＤＢ２(R) である。（ＤＢ２(R) およびｚ／ＯＳ(R) はインターナショナル・ビジネス・マシーンズ・コーポレーション（International Business Machines Corporation)の登録商標である。）各強制セキュリティ・ユニットはデータ・マネージャ２２およびデータ記憶ユニット２４に接続されている。両強制セキュリティ・ユニットはユーザ（またはウェブ・サイトなどのアプリケーション・プログラム４０）によるデータへのアクセスを階層型セキュリティ機構に従って制御するように動作する。

強制アクセス制御は、データ・マネージャ２２とデータ・リポジトリ２４との間に強制セキュリティ・ユニットを配置することにより行う。データ・マネージャ２２がデータ記憶ユニット２４から１行のデータを読み取ろうとすると、その要求は読み取り強制セキュリティ・ユニット３６に送付される。このセキュリティ・ユニットはデータ・マネージャから渡されたユーザのセキュリティ・ラベルとデータ記憶ユニット２４中にある要求されたデータ行に付随するセキュリティ・ラベルとを比較する。上記条件が合致したら、当該行へのアクセスを許可する。すなわち、読み取り強制セキュリティ・ユニット３６はユーザのセキュリティ・ラベルから当該ユーザのセキュリティ・レベルとセキュリティ・カテゴリを確認する。それは行のセキュリティ・ラベルから当該行のセキュリティ・レベルと当該行のセキュリティ・カテゴリを確認することも行う。ユーザのセキュリティ・レベルが行に付随するセキュリティ・カテゴリ以上であり、かつ、当該行に付随するセキュリティ・カテゴリが当該ユーザに付随するセキュリティ・カテゴリの適正なサブセットである場合、読み取りアクセスを許可する。データに対する読み取りアクセスの試みはすべて読み取り強制セキュリティ・ユニットに渡されるから、強制アクセス制御が達成される。

同様に、更新済みの行をデータベースに書き込む場合には、書き込み強制セキュリティ・ユニット３８がデータ・マネージャ２２からその要求を受領し、当該行をデータ記憶ユニット２４に格納する。書き込み強制セキュリティ・ユニット３８によって、上記条件が合致した後に、データ記憶ユニット２４中の当該行を更新することが許される、ということが保証される。つまり、書き込み強制セキュリティ・ユニットによって、次に示す事項が保証される。すなわち、ユーザのセキュリティ・ラベルは、当該ユーザのセキュリティ・レベルおよびセキュリティ・カテゴリの双方が、更新すべき行のセキュリティ・ラベルが示しているセキュリティ・レベルおよびセキュリティ・カテゴリと合致することを示している。

図４に、階層型セキュリティ機構を概念的に示す。ここでは、このセキュリティ機構は色の名前を用いてラベル付けしたセキュリティ・レベルを表している。たとえば、セキュリティ・レベル４２はラベル「RED(赤) 」を担持し、セキュリティ・レベル４４はラベル「ORANGE( 橙〔だいだい〕) 」を担持し、セキュリティ・レベル４６はラベル「YELLOW (黄) 」を担持している。同様に、セキュリティ・レベル４８はラベル「GREEN(緑) 」を担持し、セキュリティ・レベル５０はラベル「BLUE (青) 」を担持し、セキュリティ・レベル５２はラベル「INDIGO (藍) 」を担持し、セキュリティ・レベル５４はラベル「VIOLET (菫〔すみれ〕) 」を担持している。これらのセキュリティ・レベル（すなわち色の名前）は既存のデータベースで使用している、図２（ａ）に示すセキュリティ・ラベルに似ている。しかし、図４に示す機構は階層型セキュリティ機構であり、そこではセキュリティ・レベル群はグループ化され多レベル・セキュリティ体系における、セキュリティの様々なレベルを創成している。たとえば、ラベル「SUNSET (茜〔あかね〕) 」を担持するセキュリティ・レベル５６はその分岐中のより低レベルのセキュリティ・ラベル（すなわちRED 、ORANGE、YELLOW）用のアクセス特権をすべて含んでいる。したがって、セキュリティ体系において、セキュリティ・ラベル「SUNSET」はセキュリティ・ラベル「RED 」「ORANGE」「YELLOW」よりも高いレベルに配置されている。同様に、「PASTEL (パステル) 」とラベル付けされたセキュリティ・レベル５８はその分岐中のより低いレベルのセキュリティ・ラベル、すなわちセキュリティ・ラベル「BLUE」「INDIGO」「VIOLET」の特権をすべて含んでいる。このように、この階層型セキュリティ機構においては、セキュリティ・ラベル「PASTEL」はセキュリティ・ラベル「BLUE」「INDIGO」「VIOLET」よりも高いレベルに配置されている。

「RAINBOW(虹) 」とラベル付けされたセキュリティ・レベル６０はこのセキュリティ階層の最高のレベルに配置されている。図４に示すように、ラベル「RAINBOW 」は図４に示すツリー構造中にあるすべてのセキュリティ・ラベルの特権をすべて含んでいる。この階層型セキュリティ機構は多レベルのアクセス制御をサポートしている。

ここで説明した強制セキュリティ・アクセス制御を使用するＤＢＭＳでは、ユーザはＤＢＭＳのテーブルに直接に照会することができるが、強制アクセス制御が自動的に実行される。これにより、既存のＤＢＭＳの場合と異なり、アクセスを制御するビューを使用する必要なく、クエリ（たとえば図５（ａ）に示すクエリ６２）をＤＢＭＳに適用することが可能になる。ここでは、図５（ａ）に示す「BOSS 2」が出すクエリはSELECT文節６２を含んでいる。このSELECT文節はユーザ・テーブル「USER.TABLE」に属すデータをすべて選択することを意図している。ＤＢＭＳがアクセス制御をまったく備えていないと、ユーザのセキュリティ・レベルとは無関係にテーブル全体の内容を返すことになる。しかし、このクエリを強制アクセス制御を備えたＤＢＭＳに適用すると、返されるデータの行はユーザがアクセスするのを許可されている行だけになる。

この制御の側面を図５（ｂ）示す。ここでは、ユーザ・テーブル２６は各々がセキュリティ・ラベル（すなわちセキュリティ・ラベル「RED 」「BLUE」「YELLOW」など）を担持する行群を備えている。ユーザまたはアプリケーション４０が出す、図５（ａ）に示すクエリをＤＢＭＳが受領すると、クエリ・プロセッサ２０は当該クエリを処理し、USER.TABLE（２６）の行をすべて選択する要求をデータ・マネージャ２２に送付する。しかし、読み取りセキュリティ・ユニット３６が、返される、ユーザ・テーブルの行をセキュリティ機構６４に基づいて制限するように動作している。ユーザＩＤと当該ユーザ用のセキュリティ・ラベルとを関係付ける様々なセキュリティ機構、たとえば、図５（ｂ）に示すテーブルなどを使用することができる。しかし、理解しうる点を挙げると、ユーザに付随するセキュリティ・ラベルを決めるのに他のセキュリティ機構を使用してもよい。

特定のセキュリティ・ラベルは図４に示す階層中のリーフ・ノードにあるセキュリティ・レベル（level)（たとえばセキュリティ・ラベル「RED 」）であるかもしれない。あるいは、特定のセキュリティ・ラベルはより高いレベルのラベル（たとえばセキュリティ機構６４の行６４ｂに示すセキュリティ・レベル（level)「RAINBOW 」）であるかもしれない。たとえば、ユーザ「BOSS 1」はテーブル６４において、行６４ｂ中のラベル「RAINBOW 」によって定義されるアクセス特権を有している。これにより、当該ユーザには高度のアクセス権が与えられている。同様に、別のユーザ（たとえば「BIG BOSS」）も同じ高レベルのラベル（たとえば行６４ｃに示すセキュリティ・レベル（level)「RAINBOW 」）を使用することができる。

階層型セキュリティ・レベルの別の例がユーザＩＤ「BOSS 2」用の行６４ｄに示されている。BOSS 2のセキュリティ・ラベルは「SUNSET」である。図４に示すように、セキュリティ・ラベル「SUNSET」を有するBOSS 2はセキュリティ・ラベル「RED 」「ORANGE」「YELLOW」の特権をすべて含むアクセス特権を有する。したがって、BOSS 2が、図５（ａ）に示すクエリを発行すると、読み取り強制セキュリティ・ユニットはBOSS 2用のセキュリティ・ラベルとUSER.TABLE（２６）中の各行用のセキュリティ・ラベルとを比較する。ラベル「SUNSET」はセキュリティ・ラベル「RED 」「ORANGE」「YELLOW」の特権をすべて含んでいるから、読み取り強制セキュリティ・ユニット３６はセキュリティ・ラベル「RED 」を備えた行２６ａ、セキュリティ・ラベル「YELLOW」を備えた行２６ｃ、およびセキュリティ・ラベル「RED 」を備えた行２６ｇを返す。図４に示すように、これらのセキュリティ・ラベルは階層中でラベル「SUNSET」に従属しているから、他の行、すなわち行２６ｂ、２６ｄ、２６ｅ、２６ｆ、および２６ｈは返さない。なぜなら、こらの行用のセキュリティ・ラベルは図４に示す階層の「SUNSET」なる分岐中に存在しないからである。このように、ユーザBOSS 2はBOSS 2に付随するセキュリティ・ラベルのレベル以下のセキュリティ・レベルを有する行だけにアクセスを制限するビューを使用することなく、図５（ａ）に示すクエリ６２を発行することができる。

図６は図３に示したＤＢＭＳシステムの別の実施形態を示す図である。ここでは、キャッシュを用いて性能を向上させている。キャッシュはセキュリティ・ラベルの情報を容易に利用できるメモリに格納するように動作する。この結果、行にアクセスするたびに、特定のセキュリティ・ラベルに付随するセキュリティ・レベルおよび付随する特権ならびにカテゴリを確認するために外部のルーチンを呼び出したり、探索を実行してセキュリティ・ラベルを解釈する必要がなくなる。ここでは、ＤＢＭＳは特定のユーザ用に処理する各クエリ用に定めたセキュリティ・ラベルの情報を保持するキャッシュ６６を備えている。

図６に示す実施形態において、ユーザはＤＢＭＳにＳＱＬクエリ６８を発行する。クエリ・プロセッサ２０は受領したクエリを既存の方法で処理する。図６に示すように、クエリはカーソルをオープンし、ループを実行することにより開始する。このループには図６に示すデータ・マネージャ／強制セキュリティ・ユニット７０との相互作用を惹起する、次行を取得することが含まれている。データ・マネージャ／強制セキュリティ・ユニット７０には図３に示したデータ・マネージャ、ならびに、読み取り強制セキュリティ・ユニット３６および書き込み強制セキュリティ・ユニット３８の双方の機能を、個別にあるいは組み合わせて含めることができる。ここでは、図６において、これらのものは同じユニットに存在するように示してある。以下、説明を簡易にするために、データ・マネージャ／強制セキュリティ・ユニット７０を単に「データ・マネージャ」７０と呼ぶ。

データ・マネージャ７０はデータ記憶ユニット２４から次行を検索・取得（retrieve）する。データ記憶ユニット２４から行を検索・取得すると、データ・マネージャ７０は強制セキュリティ機能を実行し、返された行がセキュリティ・ラベルを備えているか否かを検査する。ＹＥＳなら、キャッシュ６６を検索して当該セキュリティ・ラベルに付随する情報が当該キャッシュにすでに存在するか否かを判断する。ＹＥＳなら、当該キャッシュ中の当該セキュリティ情報を用いてユーザのセキュリティ・レベルと検索・取得した行に付随するセキュリティ・レベルとを比較する。当該キャッシュ中に当該セキュリティ・レベルが存在しない場合には、データ・マネージャ７０は当該セキュリティ・ラベルに付随する情報を決める。これは様々な方法で、たとえば図６に示すようにセキュリティ層を呼び出すことにより実行することができる。このセキュリティ・ラベル情報の決定の結果はキャッシュ６６に格納する。これにより、セキュリティ・ラベル呼び出しの結果をキャッシュすることが可能になる。

セキュリティ情報が得られたら、検索・取得した行に付随するセキュリティ・レベルおよびカテゴリとユーザのセキュリティ・ラベルに付随するセキュリティ・レベルおよびカテゴリとを比較する。次いで、ユーザが当該行へアクセスするのを許可するか否かを決定する。

比較の結果が当該ユーザにアクセス権を付与すべきであるというものなら、当該行をクエリ・プロセッサ２０に戻し当該ユーザへの返還の用に供する。次いで、クエリ・プロセッサ２０中に示すループを当該クエリが完了するまで繰り返す。

クエリが完了したら、クエリ・プロセッサはデータ・マネージャに通知し、当該データ・マネージャはキャッシュをパージ（消去）する。このように、キャッシュの情報が使用されるのは単一のユーザによる単一のクエリのためだけである。換言すると、１人のユーザが行う１つのクエリごとに、キャッシュに保持されているセキュリティ・ラベルの情報をリフレッシュするから、当該キャッシュ中に当該情報が存在するのは当該ユーザのクエリを処理している間だけである。ユーザのセキュリティ・レベルと行のセキュリティ・レベルはクエリを実行している間は不変のままであると仮定している。しかし、各クエリの後にキャッシュをパージしているから、ユーザのセキュリティ・レベルおよびデータ中の行のセキュリティ・レベルの双方を変更することができるので、当該キャッシュに保持されている情報を無効する必要はない。

次に示すのは、強制アクセス制御を用いて行レベルのセキュリティを実現するために使用しうるプロセスの例である。

データベースの管理者が図３に示したＤＢＭＳ中にテーブルを作成するとき、当該管理者は当該テーブルにSECURITY＿LABEL 列を含める。当該管理者は保護すべきテーブルにもSECURITY＿LABEL 列を付加することができる。ＤＢＭＳはSECURITY＿LABEL 列が存在することを用いて行レベルのセキュリティを自動的に起動させている。したがって、行レベルのセキュリティ機構はSECURITY＿LABEL 列が存在すること、およびデータ行の内容によって起動される。SECURITY＿LABEL 列によって、各ユーザがアクセスするのを許可されている行を特定する特別のビューをデータベースの管理者が作成するか否かとは無関係に、データベース中の行群用にセキュリティ制御を使用することが可能になる。そのようなセキュリティ制御によって、セキュリティ・テーブルが存在するときは常に行レベルのセキュリティを強制することが可能になる。そして、このようなセキュリティ制御は直接に上記テーブルにアクセスしても（すなわち行へのアクセスを制御する特別のビューを使用しても、あるいは、それを回避しても）迂回することができない。各行に格納されているセキュリティ・ラベルは次に示す２つの特定の情報片をカプセル化した符号化済みの値を備えている。

（ａ）行に含まれているデータのセキュリティ・レベル。これにより、多レベルかつ階層型のセキュリティ機構（たとえばTOP SECRET、SECRET、UNCLASSIFIEDなど）を実現することが可能になる。

（ｂ）データから成る当該行の適用先であるセキュリティ・カテゴリ。たとえば、１行のデータは６つのセキュリティ・カテゴリ（たとえば、当該行を使用する基盤をなすプロジェクトＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ）に関連付けることができる。セキュリティ・ラベルは、データから成る当該行の所属先になる可能性のあるセキュリティ・カテゴリのサブセットをセキュリティ機構が決めるのを可能にしうるように符号化することができる。

エンド・ユーザがＤＢＭＳにログオンするとき、当該ユーザは当該ＤＢＭＳに対して当該ユーザを特定する認証トークン（たとえば、ユーザＩＤ／パスワード、KERBEROSチケット、など）を提示する。ユーザのＩＤが確認されたら、ＤＢＭＳは当該エンド・ユーザに関連付けるセキュリティ・ラベルを決める。これは次に示すような様々な手法を用いて行うことができる。たとえば、ＤＢＭＳの許可テーブル群中の１つのテーブルを探索する手法、外部のセキュリティ製品にセキュリティ検査を依頼する手法、信頼できるユーザ出口ルーチンを使用する手法などである。行用のセキュリティ・ラベルの場合と同様に、ユーザのセキュリティ・ラベルも次に示す情報をカプセル化しうるように符号化する。

（ａ）当該ユーザがアクセスするのを許可されているデータのセキュリティ・レベル。これにより、多レベルかつ階層型のセキュリティ機構（たとえばTOP SECRETレベル、SECRETレベル、UNCLASSIFIEDレベルなど）を実現することが可能になる。

（ｂ）当該ユーザが関連付けられているとともにアクセスするのを許可されているセキュリティ・カテゴリ。たとえば、１人のユーザを３つの異なるプロジェクト（たとえば、セキュリティ・カテゴリとして各々指定しうるプロジェクトＡ、Ｂ、Ｃ）に関連付けることができる。

図７はユーザが、強制アクセス制御が存在するデータベースに照会するプロセスを示す図である。操作７２において、あるユーザが、SECURITY＿LABEL 列を有するテーブルを備えたＤＢＭＳに対して発行するクエリを準備する。当該ユーザは当該ＤＢＭＳにログオンすることにより、あるいは別の方法により、自身を当該ＤＢＭＳに識別させる。操作７４において、当該ユーザのセキュリティ・レベルとセキュリティ・カテゴリを上述した手法を用いて確認する。操作７６において、たとえばクライアント／サーバ・システムにおけるクライアントが、当該ユーザのクエリを備えた要求を準備する。この要求は当該ユーザの上記クエリに加え、当該ユーザのセキュリティ・レベルとセキュリティ・カテゴリを用いて符号化したユーザ・セキュリティ・ラベルも含んでいる。操作７８において、この要求を上記ＤＢＭＳに送付する。

図８を参照する。操作８０において、ＤＢＭＳがユーザの要求を受領する。操作８２において、当該ＤＢＭＳはクエリ・プロセッサとデータ・マネージャを用いて当該要求を処理し、当該ユーザのクエリの述語に合致する行を発見すべく、要求されたテーブルを走査する。当該ユーザのアプリケーションにデータを返す前に、当該ＤＢＭＳはセキュリティ機構を呼び出して当該ユーザが当該データを閲覧するのを許可されているか否かを判断する。最初の判断は操作８４においてデータベースのテーブルがSECURITY＿LABEL 列を有するか否かを判断することである。当該テーブルがSECURITY＿LABEL 列を有さない場合、操作８６において当該クエリを既存の方法で処理し、操作８８において当該クエリの結果を当該ユーザに返す。

上記テーブルがSECURITY＿LABEL 列を有する場合、操作９０においてセキュリティ機構を呼び出し、上記ユーザのセキュリティ・ラベルを復号することにより当該ユーザのセキュリティ・レベルとセキュリティ・カテゴリを確認する。次いで、行のセキュリティ・ラベルをSECURITY＿LABEL 列から検索・取得して復号する。セキュリティ機構は次に示すような多くの方法で実現することができる。たとえば、ＤＢＭＳの許可テーブル内を探索する方法、外部のセキュリティ製品を呼び出す方法、インストール出口ルーチンによる方法、などである。セキュリティ機構は行のセキュリティ・ラベルを検査して当該ユーザが当該特定の行を検索・取得しうるように許可されているか否かを判断する任に当たる。これは操作９２において当該ユーザのセキュリティ・レベルと当該行のセキュリティ・レベルとを比較することにより行う。各行がとっている可能性のある状況には２つのものがある。

（ａ）当該行のセキュリティ・ラベル（label)の値が、当該ユーザがアクセス可能な値の範囲内である。これが成立するのは当該ユーザのセキュリティが当該行のセキュリティを上回っている場合であり、次に示す条件の双方が真の場合である。

（ｉ）当該ユーザのセキュリティ・ラベルが示すセキュリティ・レベルが、当該行のセキュリティ・ラベルが示すセキュリティ・レベル以上である。これは操作９４において判断する。ＮＯなら、操作９６において当該ユーザが当該行にアクセスするのを拒否する。ＹＥＳなら、操作９８において次の条件を検査する。

（ii) 当該行のセキュリティ・ラベルに付随するセキュリティ・カテゴリが、当該ユーザのセキュリティ・ラベルに付随するセキュリティ・カテゴリの適正なサブセットである。これは操作９８において判断する。それが真なら、ＤＢＭＳは当該行を処理し、要求されたデータ値を検索・取得し、その結果を当該ユーザに返す（操作１０２）。真でないなら、当該ユーザが当該行にアクセスするのを拒否する（操作１００）。

（ｂ）当該行に付随するセキュリティ・ラベル（label)が、当該ユーザのセキュリティ・ラベルに対応する値の範囲外である。この場合、ＤＢＭＳは当該データベース管理システム用に採用しているセキュリティ・ポリシに従い、当該行を無視する、あるいは、セキュリティの破壊が試みられたことを宣言する。したがって、操作９６と操作１００に示すように、ユーザが、保護されている行にアクセスするのを拒否する。

行レベルのセキュリティ検査に付随するコンピュータ・プロセッサの使用率と所要時間を最小化するために、ＤＢＭＳはユーザのトランザクションを処理する間に、当該トランザクションの実行中に認証に成功した行のセキュリティ・ラベル値を図６に示したキャッシュ６６にキャッシュすることができる。引き続く行中に当該ユーザのキャッシュ中にすでに存在するセキュリティ・ラベル値が出現したら、そのセキュリティ検査を回避してもよい。なぜなら、当該特定のセキュリティ・ラベル値はセキュリティ検査にすでに合格しているからである。確認済みのセキュリティ・ラベル値のキャッシュはデータベースのコミット境界とロールバック境界において破棄するから、セキュリティ・ポリシのその後の変更は次の作業単位において反映させる。

セキュリティ機構にセキュリティ・レベルおよびセキュリティ・カテゴリの双方を検査させると、様々なセキュリティ・ポリシをサポートする際に、当該セキュリティ機構の柔軟性が大幅に向上する。このことの数例として、次に示すものがある。

（ａ）インストール時に、正確に一致した場合にだけアクセスを許可するように選定する（ユーザのセキュリティ・ラベル＝「RED 」、かつ、行のセキュリティ・ラベル＝「RED 」）。
（ｂ）インストール時に、行のセキュリティ・ラベルがユーザのセキュリティ・ラベルの適正なサブセットである場合にだけアクセスを許可するように選定する（ユーザのセキュリティ・ラベル＝「RAINBOW 」。これは「RED 」「ORANGE」「YELLOW」「GREEN 」「BLUE」「INDIGO」「VIOLET」が当該ユーザ用の行のセキュリティ・ラベルに許される値であることを意味する）。
（ｃ）インストール時に、階層に基づいてアクセスを許可するように選定する。たとえば、ユーザ用のセキュリティ・ラベル「TOP SECRET」はそれ以下のレベル（すなわち、「TOP SECRET」「SECRET」「UNCLASSIFIED」なる行のセキュリティ・レベル値）にあるすべてのセキュリティ・レベルへのアクセスを許可する。
（ｄ）用途によっては、上述した機構を組み合わせたものを使用してもよい。

図９を参照する。操作１０４においてユーザがデータベース・テーブルの行中のデータの更新（行中のデータの変更または行の挿入）を要求したら、操作１０６において当該ユーザを特定し、当該ユーザのセキュリティ・レベルとセキュリティ・カテゴリを確認する。次いで、操作１０８において当該ユーザのセキュリティ・レベルとセキュリティ・カテゴリに加え当該行の更新を含む要求を準備する。次いで、操作１１０において、当該要求をＤＢＭＳに送付する。

図１０を参照する。ユーザが更新要求（たとえば、データを更新するＳＱＬ要求〔INSERT、UPDATEなど〕）を発行すると、操作１１２においてＤＢＭＳは当該要求を受領する。当該要求には行中のデータの更新依頼と、当該ユーザのセキュリティ・レベルおよびセキュリティ・カテゴリを表す当該ユーザのセキュリティ・ラベルとが含まれている。次いで操作１１４において、セキュリティ機構が更新対象の行に付随するセキュリティ・ラベルを確認する。この実施形態では、更新対象の行用のセキュリティ・ラベルとして当該ユーザのセキュリティ・ラベルを使用する。あるいは、用途および動作環境にとって適切な基準に基づいて、異なるセキュリティ・ラベルを選定してもよい。次いで操作１１６において、セキュリティ機構は更新すべき行がSECURITY＿LABEL 列を含んでいるか否かを判断する。ＮＯなら、操作１１８において既存の方法で更新を処理する。

当該行がSECURITY＿LABEL 列を含んでいる場合、当該ユーザのセキュリティ・ラベル（label)が当該行用のセキュリティ・ラベル（label)と等しいか否かを判断する操作１２０を実行する。ＹＥＳなら、操作１２２において更新を実行した後、当該行のセキュリティ・ラベルを当該ユーザのセキュリティ・ラベルと等しくなるように設定する。

当該ユーザのセキュリティ・ラベル（label)が当該行のセキュリティ・ラベル（label)と等しくない場合、操作１２４において当該ユーザが当該ユーザのセキュリティ・レベルとは異なるセキュリティ・レベルを備えた更新情報を記録しうるように特別に許可されているか否かを判断する。当該ユーザが特別に許可されていない場合、操作１２６において、更新するために当該テーブルにアクセスすることを拒否する。しかし、当該ユーザが特別に許可されている場合には、当該ユーザのセキュリティ・ラベルから確認される当該ユーザのセキュリティ・レベルと更新すべき行用のセキュリティ・レベルとを比較し、操作１２８において、当該ユーザのセキュリティが当該行のセキュリティを上回っているか否かを判断する。この操作では、当該ユーザのセキュリティ・ラベルと当該行のセキュリティ・ラベルを復号し、その中に符号化されているセキュリティ情報を確認する。この復号操作は次に示す異なる多くの手法を用いて実現することができる。たとえば、ＤＢＭＳの許可テーブル群内を探索する手法、外部のセキュリティ製品を呼び出す手法、インストール出口ルーチンを使用する手法などである。次いで操作１２８において、復号済みのセキュリティ・ラベルに属す情報（たとえば、セキュリティ・レベル情報など）を比較する。

図１１への結合子「Ａ」に続き操作１３０において、上記比較に基づき当該ユーザのセキュリティ・レベルが当該行用のセキュリティ・レベル以上であるか否かを判断する。ＮＯの場合、操作１３２において、更新を行うために当該ユーザが当該行にアクセスするのを拒否する。しかし、当該ユーザのセキュリティ・レベルが当該行のセキュリティ・レベル以上である場合には、セキュリティ・カテゴリ群を比較する操作１３４を実行する。

操作１３４において、更新すべき行のセキュリティ・カテゴリが当該ユーザのセキュリティ・カテゴリの適正なサブセットを形成している場合、操作１３６において、更新済みの行をデータベースに記録する。ある行用のセキュリティ・カテゴリがあるユーザ用のセキュリティ・カテゴリの適正なサブセット（部分集合）を形成するのは、当該行のすべてのセキュリティ・カテゴリが当該ユーザ用のセキュリティ・カテゴリの組（セット、集合）に含まれている場合である。しかし、ある行用のセキュリティ・カテゴリがあるユーザのセキュリティ・カテゴリの適正なサブセットを形成していない場合には、操作１３８において、当該ユーザが当該行を更新するためにアクセスするのを拒否する。

ある行を更新する際、セキュリティ機構（たとえば、図３に示す書き込み強制セキュリティ・ユニット３８）は当該ユーザのセキュリティ・ラベル値だけでなく、当該行のセキュリティ・レベルの値案を備えてもよい。この値案はたとえば、当該ユーザのＳＱＬ更新操作によって得ることができる。セキュリティ機構は当該行のセキュリティ・ラベルを、変更することなく記録しうるように選定してもよいし、あるいは、インストール時のセキュリティ・ポリシに基づいて、当該行のセキュリティ・ラベルに異なる値を強制的に代入するように選定してもよい。これにより、所望する任意のセキュリティ・ポリシをインストール時に採用することが可能になる。たとえば、更新情報をすべて、被変更行のセキュリティ・ラベル（更新を行ったユーザのセキュリティ・ラベル）に強制的に記録するようにセキュリティ・ポリシを選定することができる。また、所定のユーザが当該ユーザのセキュリティ・ラベルとは異なる、行のセキュリティ・ラベル値を用いて更新を行うのを可能にする別のセキュリティ・ポリシを選定してもよい。このようなセキュリティ・ラベル値の例としては、当該ユーザのセキュリティ・ラベル値の適正なサブセットである値、および、当該ユーザのセキュリティ・レベル以下である値が挙げられる。

強制セキュリティ・ユニットの諸機能を実行するのに使用しうる製品の一例として、ＲＡＦＣ(R) (Resource Access Control Facility ）（ＲＡＦＣ(R) はインターナショナル・ビジネス・マシーンズ・コーポレーション（International Business Machines Corporation)の登録商標である）が挙げられる。一実施形態によると、データベース・テーブルはセキュリティ・ラベルとして機能する特別に名付けられた列を付加することにより、行レベルのセキュリティ・サポートを起動することができる。ＲＡＦＣ(R) の出口（exit）を使用すると、カーソルに付随する各セキュリティ・ラベル値を検査することができるとともに、ＳＱＬクエリを発行したＳＱＬクエリの要求者が当該データ行にアクセスするのを許可されているか否かを判断することができる。ＲＡＦＣ(R) 中のセキュリティ層は階層関係（たとえば、図４に示す虹の色群を表す階層など）認識することができる。

ＲＡＦＣ(R) 中に確立されるこの階層によって、ＤＢＭＳには、情報「PASTEL」にアクセスする権限を有するユーザは「BLUE」「INDIGO」「VIOLET」または「PASTEL」に付随する任意の行にアクセスしうるということが分かる。これらの機能によって、この種のセキュリティ機構は特別のビューまたは述語を用いてデータにアクセスするアプリケーション・プログラムを必要とすることなく実現することが可能になる。

以上、リレーショナル・データベース管理システムにおいて行レベルのセキュリティを実現する装置、製品、および方法を説明した。信ずべき点を挙げると、ここに開示した教示に鑑み、当業者は他の変更例、変形例、および置換例を想到しうる。したがって、理解すべき点を挙げると、そのような変更例、変形例、および置換例はすべて特許請求の範囲によって定義した本発明の範囲内のものであると信じる。また、ここでは特定の用語を使用したが、それらはここで明示的に別様に定義した場合を除き、その通常の、かつ慣例的な態様でのみ使用しており、限定を目的としていない。

複数のウェブ・サイト用のデータを管理する既存のデータベース管理システムを備えたウェブ・ホストを示す図である。データベース・テーブル中のデータから成るある行へのユーザのアクセスを制限する既存の方法で使用するデータベース・テーブル、ビューを作成するためのＳＱＬステートメント、そのビュー、およびクエリをそれぞれ示す図である。強制アクセス制御を可能にする行レベルのアクセス制御をサポートする読み取り強制セキュリティ実行ユニットと書き込み強制セキュリティ実行ユニットを有するデータベース管理システムを備えたアクセス制御システムを示すブロック図である。図３に示すアクセス制御システムがサポートしている階層型のセキュリティ機構の一例を示す図である。図４に示すセキュリティ階層を採用した、クエリ、データベース・テーブル、およびセキュリティ機構を示す図である。行レベルの強制アクセス制御を実現する際に、図３に示すデータベース管理システムにおいてキャッシュを使用して性能を改善する様子を示す図である。行レベルの強制アクセス制御を実現しているデータベース管理システムに照会するフローチャートを示す図である。行レベルの強制アクセス制御を実現しているデータベース管理システムに照会するフローチャートを示す図である。行を更新する要求を送付し、行レベルの強制アクセス制御を実現しているデータベース管理システムにおいて当該行を更新するフローチャートを示す図である。行を更新する要求を送付し、行レベルの強制アクセス制御を実現しているデータベース管理システムにおいて当該行を更新するフローチャートを示す図である。行を更新する要求を送付し、行レベルの強制アクセス制御を実現しているデータベース管理システムにおいて当該行を更新するフローチャートを示す図である。

符号の説明

１０ウェブ・サーバ
１２ウェブ・サイト
１４ネットワーク
１６クライアント
１８ＤＢＭＳ
２０クエリ・プロセッサ
２２データ・マネージャ
２４データ
２６ユーザ・テーブル（USER.TABLE）
２８ライン
３０セキュリティ・テーブル（SECURITY.TABLE)
３２ユーザ・ビュー（USER.VIEW ）
３４クエリの一例
３６読み取り強制セキュリティ・ユニット
３８書き込み強制セキュリティ・ユニット
４０アプリケーション
４２ RED
４４ ORANGE
４６ YELLOW
４８ GREEN
５０ BLUE
５２ INDIGO
５４ VIOLET
５６ SUNSET
５８ PASTEL
６０ RAINBOW
６２クエリ
６４セキュリティ機構
６６キャッシュ
６８ユーザが出すＳＱＬクエリ
７０データ・マネージャ／強制セキュリティ・ユニット

Claims

リレーショナル・データベースへのアクセスを制御する方法であって、
前記データベースに属すデータを求めるユーザの要求を受領するステップであって、前記要求はデータベース操作を実行する要求およびユーザのセキュリティ・ラベルを含んでいる、ステップと、
前記ユーザのセキュリティ・ラベルに基づいてユーザのセキュリティ情報を確認するステップと、
前記ユーザの要求に応答して、前記データベース中のテーブルから、データから成る少なくとも１つの行を検索・取得するステップであって、前記少なくとも１つの行はセキュリティ・ラベルを備えている、ステップと、
前記少なくとも１つの検索・取得済みの行のセキュリティ・ラベルに基づいて前記少なくとも１つの検索・取得済みの行用の行のセキュリティ情報を確認するステップと、
前記少なくとも１つの検索・取得済みの行につき、前記ユーザのセキュリティ情報および前記行のセキュリティ情報に基づいて前記ユーザが前記行にアクセスするのを許可されているか否かを判断するステップと、
前記ユーザがアクセスするのを許可されていると判断した場合、前記少なくとも１つの行を返すステップと
を備えた
方法。
各ユーザのセキュリティ・ラベルまたは各行のセキュリティ・ラベルがそれぞれ、セキュリティ・レベル群から成る階層中に配置された複数のユーザのセキュリティ・ラベルのうちの１つ、または複数の行のセキュリティ・ラベルのうちの１つである、
請求項１に記載の方法。
前記ユーザのセキュリティ・ラベルが、前記検索・取得済みの行のセキュリティ・ラベルが示しているセキュリティ・レベル以上のアクセスの程度を有するセキュリティ・レベルに対応している場合にだけ、前記ユーザは前記検索・取得済みの行にアクセスしうるように許可されていると判断する、
請求項２に記載の方法。
各ユーザのセキュリティ・ラベルまたは各行のセキュリティ・ラベルが少なくとも１つのセキュリティ・カテゴリを示している、
請求項１〜３のうちの１項に記載の方法。
さらに、
前記検索・取得済みの行のセキュリティ・ラベルが、前記ユーザのセキュリティ・ラベルに対応するセキュリティ・カテゴリ群の適正なサブセットであるセキュリティ・カテゴリ群に対応している場合にだけ、前記ユーザは前記検索・取得済みの行にアクセスしうるように許可されていると判断する、
請求項４に記載の方法。
さらに、
前記要求された操作が行の更新操作である場合、前記行のセキュリティ・ラベルを前記ユーザのセキュリティ・ラベルと同一の値にセットするステップを備えた、
請求項１〜５のうちの１項に記載の方法。
さらに、
前記ユーザがより低レベルの行のセキュリティ・ラベルを備えた行を更新しうるように許可されている場合であり、かつ、前記より低レベルの行のセキュリティ・ラベル用に指定されたセキュリティ・カテゴリ群が、前記ユーザに付随するセキュリティ・カテゴリ群の適正なサブセットである場合、前記ユーザのセキュリティ・レベルよりも低いレベルを前記行のセキュリティ・ラベルに設定するステップを備えた、
請求項４〜６のうちの１項に記載の方法。
コンピュータ・プログラムであって、前記コンピュータ・プログラムをコンピュータで実行したときに、請求項１〜７のうちの１項に記載のステップ群を実行しうるように適合したプログラム・コード手段を備えたコンピュータ・プログラム。