JP4716729B2 - データに関するセキュリティを提供する方法、及びそのコンピュータ・プログラム - Google Patents

データに関するセキュリティを提供する方法、及びそのコンピュータ・プログラム Download PDF

Info

Publication number
JP4716729B2
JP4716729B2 JP2004543023A JP2004543023A JP4716729B2 JP 4716729 B2 JP4716729 B2 JP 4716729B2 JP 2004543023 A JP2004543023 A JP 2004543023A JP 2004543023 A JP2004543023 A JP 2004543023A JP 4716729 B2 JP4716729 B2 JP 4716729B2
Authority
JP
Japan
Prior art keywords
field
security
query
user
value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004543023A
Other languages
English (en)
Other versions
JP2006502494A (ja
JP2006502494A5 (ja
Inventor
デッティンガー、リチャード、ディーン
スティーブンス、リチャード、ジョゼフ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2006502494A publication Critical patent/JP2006502494A/ja
Publication of JP2006502494A5 publication Critical patent/JP2006502494A5/ja
Application granted granted Critical
Publication of JP4716729B2 publication Critical patent/JP4716729B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Bioethics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Description

本発明は、一般には、データ処理に関し、より詳細には、データを物理的に表現する特定の様式とは独立にデータにアクセスすることに関する。
データベースは、コンピュータ化された情報格納／取り出しシステム（informationstorage and retrieval system）である。リレーショナル・データベース管理システムは、データを格納し取り出すのにリレーショナル（relational）技法を使用するコンピュータ・データベース管理システム（ＤＢＭＳ、databasemanagement system）である。最も優勢なタイプのデータベースは、リレーショナル・データベース、すなわちデータを多くの異なるやり方で再編成しアクセスできるように定義した表形式の（tabular）データベースである。
具体的なアーキテクチャによらず、ＤＢＭＳでは、要求側エンティティ（たとえば、アプリケーションまたはオペレーティング・システム）が、指定したデータベースへのアクセスを要求を、データベース・アクセス要求を発行することによって行う。そのような要求は、たとえば、単純なカタログ・ルックアップまたはデータベース内の指定したレコードを読み出し、変更し、追加するように動作するトランザクション、およびトランザクションの組合せを含むことができる。こうした要求は、ＳＱＬ（Structured Query Language、構造化問い合わせ言語）などの高水準問い合わせ言語を用いて行われる。例示すると、ＳＱＬは、インターナショナル・ビジネス・マシーンズ（ＩＢＭ、InternationalBusiness Machines）社のＤＢ２、マイクロソフト（Microsoft）社のＳＱＬ Ｓｅｒｖｅｒや、オラクル（Oracle）社、サイベース（Sybase）社、およびコンピュータ・アソシエーツ（ComputerAssociates）社製のデータベース製品などのデータベースから情報を得て更新するために対話的な問い合わせを行うのに使用される。「問い合わせ」という用語は、保管されているデータベースからデータを取り出すための１組のコマンドの名称である。問い合わせは、プログラマおよびプログラムに、選択、挿入、更新、データのロケーションの発見などをさせるコマンド言語の形をとっている。
データベースの文脈における１つの顕著な問題はセキュリティである。データベースは、しばしば、アクセスから保護すべきほどにセキュリティの必要な、秘密の（confidential）、そうでなければ慎重さを要する（sensitive）資料を含んでいる。たとえば、医療記録は個人性および秘密性が高いと考えられている。したがって、医療記録へのアクセスは、通常、選ばれたユーザに制限される。このために、従来のデータベース管理システムでは、認可のレベルを指定するユーザ・プロファイルを実装する場合がある。ユーザがある特定のデータにアクセスしてよいかどうかは、それぞれのプロファイルに指定されたそのユーザの認可のレベルに依存する。
しかし、以上のアプローチは、きわめて柔軟性に乏しく静的である。他方、データは、きわめて動的である（すなわち、時間とともに変化する）。その結果、ユーザの従来のデータベースに課されたセキュリティは、そのユーザがアクセスしようと試みるデータに関して適切であることも、そうでないこともある。たとえば、ＨＩＶテストの結果にアクセスしようと試みるあるユーザを考えよう。このユーザがＨＩＶテストの結果にアクセスさせないようにするのを、その値（すなわち、ポジティブかネガティブか）にかかわらず、このユーザ自身の医療記録に、このユーザがＨＩＶテストを受けたことが反映されている場合だけにすることが望ましいことがある。第１のアクセスの試行中に、このユーザの医療記録がＨＩＶテストを反映していない場合には、このユーザは、ＨＩＶテストの結果について医療記録の問い合わせを行うことが許される。同じユーザが、引き続いてＨＩＶテストを受け、それが次いでこのユーザの医療記録に反映された場合には、これに引き続くＨＩＶテストの結果にアクセスする試行は許されないはずである。あるいは、このユーザがＨＩＶテストの結果にアクセスさせないようにするのを、このユーザ自身の医療記録に、ポジティブというＨＩＶテストの結果が反映されている場合だけにすることが望ましいこともある。いずれの場合でも、従来のデータベース管理システムでは、このレベルの柔軟性が可能ではない。
したがって、データベースのための改良されたセキュリティ機構が必要とされている。
本発明は、一般に、データベース・セキュリティのための方法、システム、および製造物を対象とする。
一実施形態では、データに関するセキュリティを提供する方法が提供される。この方法は、ユーザがデータベースに対して発行した、少なくとも１つのフィールドおよび前記少なくとも１つのフィールドに関連する値で構成される問い合わせを受け取ること、および、前記少なくとも１つのフィールドについての前記ユーザに固有のデータの存在に基づいて、前記少なくとも１つのフィールドについて前記ユーザ向けに指定されたセキュリティ規則を呼び出さなければならないかどうかを判断することを含む。
データに関してセキュリティを提供する別の方法は、所与のユーザについてデータが存在する複数のフィールドのそれぞれを反映する少なくとも１つのセキュリティ・リストを生成し、前記複数のフィールドのそれぞれは前記所与のユーザについての定義済みセキュリティ規則を有しており、前記所与のユーザがデータベースに対して発行した問い合わせを受け取り、前記問い合わせは、少なくとも１つのフィールドおよび前記少なくとも１つのフィールドに関連する値で構成されており、前記問い合わせの前記少なくとも１つのフィールドが前記少なくとも１つのセキュリティ・リストに反映されているかどうかを判断するために、前記少なくとも１つのセキュリティ・リストにアクセスし、前記問い合わせの前記少なくとも１つのフィールドが前記少なくとも１つのセキュリティ・リストに反映されている場合に、前記セキュリティ規則を実施する（enforce）ことを含む。
別の実施形態では、特定の物理データ表現を有するデータにセキュリティを提供する方法は、抽象的問い合わせを定義するために複数の論理フィールドを含む問い合わせ仕様を提供し、前記複数の論理フィールドを前記データの物理エンティティに対応付ける対応付け規則を提供し、前記複数の論理フィールドについてユーザ固有のセキュリティ規則を提供し、ユーザが前記データに対して発行した抽象的問い合わせを受け取り、前記抽象的問い合わせは、前記問い合わせ仕様に従って定義され、少なくとも１つの論理フィールドおよび前記少なくとも１つの論理フィールドに関連する値で構成されており、前記少なくとも１つの論理フィールドについての前記ユーザに固有のデータの存在に基づいて、前記少なくとも１つの論理フィールドについて前記ユーザ向けに指定されたセキュリティ規則を呼び出さなければならないかどうかを判断することを含む。
別の実施形態では、ユーザがデータベースに対して発行した、少なくとも１つのフィールドおよび前記少なくとも１つのフィールドに関連する値で構成される問い合わせを受け取り、前記少なくとも１つのフィールドについての前記ユーザに固有のデータの存在に基づいて、前記少なくとも１つのフィールドについて前記ユーザ向けに指定されたセキュリティ規則を呼び出さなければならないかどうかを判断することを含むセキュリティ検証動作を、実行時にコンピュータに行わせるセキュリティ検証命令を含む、コンピュータ可読媒体が提供される。
別の実施形態では、セキュリティ検証動作を、実行時にコンピュータに行わせるセキュリティ検証命令を含む、コンピュータ可読媒体が提供される。前記セキュリティ検証動作は、所与のユーザについてデータが存在する複数のフィールドのそれぞれを反映する少なくとも１つのセキュリティ・リストを生成し、前記複数のフィールドのそれぞれは、前記所与のユーザについての定義済みルールを有し、前記所与のユーザがデータベースに対して発行した問い合わせを受け取り、前記問い合わせは、少なくとも１つのフィールドおよび前記少なくとも１つのフィールドに関連する値で構成されており、前記問い合わせの前記少なくとも１つのフィールドが前記少なくとも１つのセキュリティ・リストに反映されているかどうかを判断するために、前記少なくとも１つのセキュリティ・リストにアクセスし、前記問い合わせの前記少なくとも１つのフィールドが、前記少なくとも１つのセキュリティ・リストに反映されている場合に、前記セキュリティ規則を実施することを含む。
別の実施形態では、格納された情報をその媒体上に含む、コンピュータ可読媒体であって、前記情報が、抽象的な問い合わせを定義するために複数の論理フィールドを含む問い合わせ仕様と、前記複数の論理フィールドを前記データの物理エンティティに対応付ける複数の対応付け規則と、前記複数の論理フィールドについての複数のユーザ固有のセキュリティ規則と、ユーザが前記データに対して発行した抽象的問い合わせを受け取るのに応答してセキュリティ検証動作をコンピュータに行わせるように実行可能なランタイム・コンポーネントとを含み、前記抽象的問い合わせは前記問い合わせ仕様に従って定義され、少なくとも１つの論理フィールドおよび前記少なくとも１つの論理フィールドに関連する値で構成される。前記セキュリティ検証動作は、前記少なくとも１つの論理フィールドについての前記ユーザに固有のデータの存在に基づいて、前記少なくとも１つの論理フィールドについて前記ユーザ向けに指定されたセキュリティ規則を呼び出さなければならないかどうかを判断することを含む。
本発明の上に挙げた諸特徴を達成する態様を詳細に理解できるように、上で簡潔に要約した本発明のより具体的な説明を、添付の図面に示すその実施形態への参照によって得ることができる。
しかし、本発明には他の均等に効果的な実施形態を許すことができるため、添付の図面には、本発明の典型的な実施形態のみを示しており、したがってその範囲を限定するものと見なすべきでないことに留意されたい。
導入
本発明は、一般には、データへのアクセスを制限するためのシステム、方法、および製品（articleof manufacture）を対象とする。一般に、データ・アクセスの制限は、問い合わせ内で要求中のデータとその問い合わせを発行するユーザとの間の関連付けに従って行う。
一実施形態では、セキュリティ規則を、データの論理モデルの一部としてインプリメントする。論理モデルは、下位にある（underlying）データ・リポジトリの論理ビュー（logical view）を提供する、データ・リポジトリ抽象化（datarepository abstraction）レイヤとしてインプリメントする。このようにして、データを、そのデータを物理的に表現する特定の様式とは独立させる。また、問い合わせ抽象化レイヤ（queryabstraction layer）も提供するが、これはデータ・リポジトリ抽象化レイヤに基づく。ランタイム・コンポーネントは、抽象的問い合わせを、特定の物理データ表現と突き合わせて使用できる形への翻訳を行う。
本発明の一実施形態は、たとえば図１に示し以下で説明するコンピュータ・システムなどのコンピュータ・システムとともに使用するためのプログラム製品として実装する。このプログラム製品のプログラムは、（本明細書で説明する諸方法を含む）諸実施形態の機能を定義するものであり、また様々な信号担持媒体上に収容することができる。例示的な信号担持媒体は、（ｉ）非書き込み可能なストレージ・メディア（たとえば、ＣＤ−ＲＯＭドライブが読み取り可能なＣＤ−ＲＯＭディスクなどコンピュータ内部の読み取り専用記憶装置）上に永続的に格納した情報、（ｉｉ）書き込み可能なストレージ・メディア（たとえば、ディスケット・ドライブ内部のフロッピー（Ｒ）・ディスクやハードディスク・ドライブ）上に格納した変更可能な情報、または（ｉｉｉ）無線通信を含めて、コンピュータ・ネットワークや電話網を通してなどの、通信媒体がコンピュータへと運ぶ情報を含むが、これに限定されるものではない。最後の実施形態は、インターネットおよび他のネットワークからダウンロードした情報を特に含む。そのような信号担持媒体は、本発明の機能を支持するコンピュータ可読命令を担うとき、本発明の諸実施形態に相当する。
一般に、本発明の諸実施形態をインプリメントするために実行するルーチンは、オペレーティング・システムの一部、あるいは、特定のアプリケーション、コンポーネント、プログラム、モジュール、オブジェクト、または命令の系列とすることができる。本発明のソフトウェアは、通常、ネイティブ（native）コンピュータが機械可読フォーマット、したがって実行可能命令へと翻訳することになる数多くの命令からなる。また、プログラムは、そのプログラムにローカルに存在する、あるいは、メモリ内またはストレージ装置上に見出される変数およびデータ構造からなる。さらに、本明細書でこの後説明する様々なプログラムは、本発明の特定の実施形態でそれらプログラムを実装する目的となる適用によって特定することができる。しかし、以下のどのような特定の命名法も便宜的に用いるものに過ぎず、したがって本発明は、そのような命名法の特定しまたは示唆する、あるいはその双方に相当する任意の特定の適用のみにおける使用に限定されるべきでないことを理解されたい。
環境の物理ビュー（physical view）
図１には、本発明の諸実施形態を実装できるネットワーク化システム１００の構成図を示している。一般に、ネットワーク化システム１００は、クライアント（たとえば、ユーザの）コンピュータ１０２（そのようなクライアント・コンピュータ１０２ ３台を示す）および少なくとも１つのサーバ１０４（そのようなサーバ１０４ １台を示す）を含む。クライアント・コンピュータ１０２およびサーバ・コンピュータ１０４は、ネットワーク１２６を介して接続されている。一般に、ネットワーク１２６は、ＬＡＮ（local area network、構内通信網）またはＷＡＮ（wide area network、広域通信網）あるいはそれらの組合せであってよい。特定の実施形態では、ネットワーク１２６はインターネットである。
クライアント・コンピュータ１０２は、バス１３０を介してメモリ１１２、ストレージ１１４、入力装置１１６、出力装置１１９、およびネットワーク・インターフェース装置１１８に接続される中央処理装置（ＣＰＵ、Central Processing Unit）１１０を含む。入力装置１１６は、クライアント・コンピュータ１０２に入力を与えるためのどのような装置とすることもできる。たとえば、キーボード、キーパッド、ライト・ペン、タッチ・スクリーン、トラック・ボール、または音声認識ユニット、オーディオ／ビデオ・プレイヤーなどを使用することもできる。出力装置１１９は、ユーザに出力を与えるどのような装置、たとえば、従来のどのようなディスプレイ画面とすることもできる。入力装置１１６とは別個に示しているが、出力装置１１９と入力装置１１６を組み合わせることもできる。たとえば、タッチ・スクリーンを組み込んだディスプレイ画面、キーボードを組み込んだディスプレイ、またはテキスト・スピーチ変換器を組み合わせた音声認識ユニットを使用することもできる。
ネットワーク・インターフェース装置１１８は、クライアント・コンピュータ１０２とサーバ・コンピュータ１０４の間のネットワーク１２６を介したネットワーク通信を可能にするように構成されたどのような入口／出口装置（entry/exit device）であってもよい。たとえば、ネットワーク・インターフェース装置１１８は、ネットワーク・アダプタまたは他のネットワーク・インターフェース・カード（ＮＩＣ、networkinterface card）とすることもできる。
ストレージ１１４は、好ましくは、ＤＡＳＤ（Direct Access StorageDevice、直接アクセス記憶装置）である。これは単一のユニットとして示しているが、固定ディスク・ドライブ（fixed disc drives）、フロッピー（Ｒ）・ディスク・ドライブ、テープ・ドライブ、リムーバブル・メモリ・カード、または光ストレージなど、固定またはリムーバブル記憶装置あるいはその両方の組合せとすることもできる。メモリ１１２およびストレージ１１４は、複数の１次および２次ストレージ装置にまたがる１つの仮想アドレス空間の一部とすることもできる。
メモリ１１２は、好ましくは、本発明の必要なプログラミングおよびデータ構造を保持するのに十分な大きさのＲＡＭ（random access memory、ランダム・アクセス・メモリ）である。メモリ１１２を単一のエンティティとして示しているが、メモリ１１２は、実際には複数のモジュールを含むことができ、メモリ１１２は、高速のレジスタおよびキャッシュから低速ながらより大きなＤＲＡＭチップに至る、複数のレベルで存在することができることを理解されたい。
例示的に、メモリ１１２は、オペレーティング・システム１２４を収容している。有利になるよう使用してよい、例示的なオペレーティング・システムとしては、Ｌｉｎｕｘおよびマイクロソフト社（Microsoft）のＷｉｎｄｏｗｓ（登録商標）がある。より一般には、本明細書に開示する機能をサポートするどのようなオペレーティング・システムを使用してもよい。
また、メモリ１１２は、ＣＰＵ１１０上で実行すると、様々なサーバ１０４の間をナビゲートし（navigating）、サーバ１０４の１つまたは複数にあるネットワーク・アドレスを見出すためのサポートを提供する、ブラウザ・プログラム１２２を収容するものとして示している。一実施形態では、ブラウザ・プログラム１２２は、ＷｅｂベースのＧＵＩ（GraphicalUser Interface、グラフィカル・ユーザ・インターフェース）を含み、これにより、ユーザはＨＴＭＬ（HyperText Markup Language、ハイパーテキスト記述言語）情報を表示することができるようになる。しかし、より一般には、ブラウザ・プログラム１２２は、サーバ・コンピュータ１０４から送信される情報をレンダリングする能力のある（好ましくはＧＵＩベースの）どのようなプログラムであってもよい。
サーバ・コンピュータ１０４は、クライアント・コンピュータ１０２と類似のやり方で物理的に配置することができる。したがって、サーバ・コンピュータ１０４を、バス１３６が互いに結合するＣＰＵ１３０、メモリ１３２、およびストレージ装置１３４を含むものとして一般的に示している。メモリ１３２は、サーバ・コンピュータ１０４上に配置された必要なプログラミングおよびデータ構造を保持するのに十分な大きさのＲＡＭ（random access memory、ランダム・アクセス・メモリ）とすることができる。
サーバ・コンピュータ１０４は、一般に、メモリ１３２内にあるように示したオペレーティング・システム１３８の制御下にある。オペレーティング・システム１３８の例は、ＩＢＭ ＯＳ／４００（登録商標）、ＵＮＩＸ（登録商標）、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）などである。より一般に、本明細書に記載の機能をサポートする能力のあるどのようなオペレーティング・システムを使用するのでもよい。
メモリ１３２は、１つまたは複数のアプリケーション１４０および抽象的問い合わせインターフェース（abstract query interface）１４６をさらに含む。アプリケーション１４０および抽象的問い合わせインターフェース１４６は、コンピュータ・システム１００内の様々なメモリおよびストレージ装置に様々なときに常駐する複数の命令を含むソフトウェア製品である。サーバ１０４内の１つまたは複数のプロセッサ１３０により読み込まれ実行されると、アプリケーション１４０および抽象的問い合わせインターフェース１４６は、コンピュータ・システム１００に、本発明の様々な態様を実施する諸ステップおよび諸要素を実行するのに必要な諸ステップを実行させる。アプリケーション１４０（ならびに、より一般には、オペレーティング・システム１３８および最も高水準ではユーザを含めて、どのような要求側エンティティ（requestingentity）も）データベース（たとえば、まとめてデータベース１５６と呼ぶデータベース１５６１．．．１５６Ｎ）に対して問い合わせを発行する。例示的に、データベース１５６を、ストレージ１３４内のＤＢＭＳ（databasemanagement system、データベース管理システム）の一部として示している。データベース１５６により、特定の物理表現によらず、どのようなデータの集まりも代表させている。例示として、データベース１５６は、（ＳＱＬ問い合わせによってアクセス可能な）リレーショナル・スキーマに従って、または（ＸＭＬ問い合わせによってアクセス可能な）ＸＭＬスキーマに従って編成することができる。しかし、本発明は、特定のスキーマに限定されるものではなく、現在知られていないスキーマへの拡張を企図するものである。本明細書で使用するように、「スキーマ」という用語は、データのある特定の構成を総称的に指すものとする。
一実施形態では、アプリケーション１４０の発行する問い合わせの定義は、アプリケーション１４０のそれぞれとともに含まれるアプリケーション問い合わせ仕様１４２に従って行う。アプリケーション１４０の発行する問い合わせは、あらかじめ定義する（すなわち、アプリケーション１４０の一部としてハード・コードする）のでもよく、または入力（たとえば、ユーザ入力）に応答して生成するのでもよい。どちらの場合でも、問い合わせ（本明細書では「抽象的問い合わせ」（abstract query）と呼ぶ）の作成／実行は、抽象的問い合わせインターフェース１４６の定義する論理フィールドを用いて行う。具体的には、抽象的問い合わせで使用する論理フィールドを、抽象的問い合わせインターフェース１４６のデータ・リポジトリ抽象化コンポーネント（datarepository abstraction component）１４８によって定義する。抽象的問い合わせの実行は、ランタイム・コンポーネント１５０が行い、これはまず、抽象的問い合わせを、ＤＢＭＳ１５４に含まれるデータの物理表現と一貫性のある形式へと変換する。
一実施形態では、データ・リポジトリ抽象化コンポーネント１４８は、セキュリティ情報１６２で構成される。セキュリティ情報１６２は、一般に、ユーザまたは複数のユーザの選択されたデータに対するアクセス特権を定義するセキュリティ規則を含む。ランタイム・コンポーネント１５０は、問い合わせを発行する特定のユーザ、およびその問い合わせの実行によってアクセスされる／返されることになる特定のデータに応じて、セキュリティ情報１６２をエンフォースする（enforce）ように動作する。一般に、セキュリティ規則は、特定のユーザ、ユーザのグループ、またはすべてのユーザに対して定義することができる。あるユーザが１人または複数の他のユーザと関連をもっているかどうかは、プロファイル１５８に定義する。したがって、プロファイル１５８は、データベース１５６にアクセスを試みるユーザそれぞれに対して存在する可能性がある。
一実施形態では、問い合わせの諸要素の指定は、ユーザがＧＵＩ（graphicaluser interface）によって行う。ＧＵＩの内容は、アプリケーション１４０によって生成される。特定の実施形態では、ＧＵＩの内容は、クライアント・コンピュータ・システム１０２上でブラウザ・プログラム１２２によってレンダリングすることのできるＨＴＭＬ（hypertextmarkup language）コンテンツである。したがって、メモリ１３２は、クライアント・コンピュータ１０２からの要求を処理するように適合されたＨＴＴＰ（HypertextTransfer Protocol、ハイパーテキスト転送プロトコル）サーバ・プロセス１５２（たとえば、Ｗｅｂサーバ）を含む。たとえば、サーバ・プロセス１５２は、例示的にサーバ１０４上に常駐している、データベース１５６にアクセスする要求に応答することができる。データベース１５６から来る、データに対するクライアント要求により、アプリケーション１４０が呼び出される。アプリケーション１４０は、プロセッサ１３０によって実行されると、サーバ・コンピュータ１０４に、データベース１５６にアクセスすることを含めて、本発明の様々な態様を実施する諸ステップまたは諸要素を実行させる。一実施形態では、アプリケーション１４０は、ブラウザ・プログラム１２２によってレンダリングされるＧＵＩ要素を作成するように構成された複数のサーブレットを含む。
図１は、ネットワーク接続したクライアント・コンピュータ（networkedclient computer）１０２およびサーバ・コンピュータ１０４のためのあるハードウェア／ソフトウェア構成に過ぎない。本発明の実施形態は、コンピュータ・システムが、複雑なマルチ・ユーザのコンピューティング装置、シングル・ユーザのワークステーション、またはそれ自体に不揮発性ストレージのないネットワーク・アプライアンスであるのを問わず、類似のどのようなハードウェア構成にも適用可能である。さらに、ＨＴＭＬを含めて、特定の記述言語（markuplanguage）に言及しているが、本発明は、標準であれ変形であれ、特定の言語に限定されるものではないことが理解されている。したがって、本発明が他の記述言語ならびに非記述言語に適合可能であること、および、本発明が特定の記述言語における変更ならびに現在知られていない他の言語にも適合可能であることが当業者には理解されよう。同様に、図１に示すＨＴＴＰサーバ・プロセス１５２は、例示的なものに過ぎず、知られているおよび知られていないどのようなプロトコルをサポートするように適合された他の実施形態をも企図するものである。
環境の論理／ランタイムビュー（logical/runtime view）
図２〜３に、本発明のコンポーネントの例示的な関係図２００を示している。要求側エンティティ（たとえば、アプリケーション１４０のうちの１つ）により、その要求側エンティティのそれぞれのアプリケーション問い合わせ仕様１４２の定義する問い合わせ２０２が発行される。その結果である問い合わせ２０２を、本明細書では一般に「抽象的問い合わせ」と呼ぶが、これは、その問い合わせの作成を、ＤＢＭＳ１５４内の下位にある物理データ・エンティティを直接参照することによるのではなく、抽象的な（すなわち、論理的な）フィールドに従って行うためである。その結果、使用される特定の下位にあるデータ表現とは独立な抽象的問い合わせを定義することができる。一実施形態では、アプリケーション問い合わせ仕様１４２は、データ選択に使用する基準（選択基準２０４）と、選択基準２０４に基づく、返すべきフィールドの明示的指定（返却データ指定２０６）のどちらも含むことができる。
図３に示す抽象的問い合わせ２０２に対応する例示的な抽象的問い合わせを、下の表Ｉに示す。例示として、抽象的問い合わせ２０２はＸＭＬを用いて定義している。しかし、有利になるように他のどのような言語を使用してもよい。
表Ｉ−問い合わせの例
001 <?xmlversion="1.0"?>
002 <!--Query string representation:(FirstName = "Mary" AND LastName =
003 "McGoon") OR State= "NC"-->
004 <QueryAbstraction>
005 <Selection>
006 <ConditioninternalID="4">
007<Condition field="FirstName" operator="EQ"value="Mary"
008 internalID="1"/>
009<Condition field="LastName" operator="EQ"value="McGoon"
010 internalID="3"relOperator="AND"></Condition>
011</Condition>
012 <Conditionfield="State" operator="EQ" value="NC"internalID="2"
013relOperator="OR"></Condition>
014 </Selection>
015 <Results>
016<Field name="FirstName"/>
017<Field name="LastName"/>
018<Field name="State"/>
019 </Results>
020 </QueryAbstraction>
例示的には、表１に示す抽象的問い合わせは、選択基準を含む選択指定（００５〜０１４行）および結果仕様（０１５〜０１９行）を含む。一実施形態では、１つの選択基準は、（論理フィールドに対する）フィールド名、比較演算子（＝、＞、＜など）および値の式（value expression）（そのフィールドを比較する相手）からなる。一実施形態では、結果仕様は、問い合わせ実行の結果として返されることになっている抽象的フィールドのリストである。抽象的問い合わせ内の結果仕様は、フィールド名および整列基準からなるものとすることができる。
アプリケーション問い合わせ仕様１４２により指定し、抽象的問い合わせ２０２を作成するのに使用する論理フィールドの定義は、データ・リポジトリ抽象化コンポーネント１４８によって行う。一般に、データ・リポジトリ抽象化コンポーネント１４８では、情報を１組の論理フィールドとして公開しており、これは（ユーザ入力問い合わせ条件に応答する状態にあるのでもよい）アプリケーション１４０の発行する問い合わせ（たとえば、抽象問い合わせ２０２）の内部でデータ選択のための基準を指定し、問い合わせ動作から返される結果のデータの形式を指定するのに使用することができる。論理フィールドは、ＤＢＭＳ１５４内で使用中の下位にあるデータ表現とは独立に定義し、それにより、下位のデータ表現と緩やかに結合する問い合わせを形成することができるようになる。
一般に、データ・リポジトリ抽象化コンポーネント１４８は、まとめてフィールド仕様（fieldspecification）２０８として参照する、複数のフィールド仕様２０８１、２０８２、．．．（例として２つを示す）を含む。特に、フィールド仕様は、抽象的問い合わせの作成のために利用可能な論理フィールドのそれぞれに対して提供される。一実施形態では、フィールド仕様２０８は、論理フィールド名２１０１、２１０２（まとめて、フィールド名２１０）および関連するアクセス・メソッド（accessmethod）２１２１、２１２２（まとめて、アクセス・メソッド２１２）を含む。また、この例示的な実施形態では、フィールド仕様２０８は、１つまたは複数のカテゴリ名２１６１、２１６２（まとめて、カテゴリ名２１６）を含む。カテゴリ名により、あるグループの論理フィールド名が関連付けられる。たとえば、図３では、フィールド仕様２０８１と２０８２のどちらでも、人口統計（demographic）カテゴリ２１６１と個人（person）カテゴリ２１６２が指定されている。しかし、このカテゴリの使用は、特定の実施形態を代表させているものに過ぎず、他の実施形態ではカテゴリは利用されていない。
アクセス・メソッド２１２により、論理フィールド名が、データベース（たとえば、データベース１５６のうちの１つ）内の特定の物理データ表現２１４１、２１４２、．．．２１４Ｎと関連付けられる。例示として、図２には、２つのデータ表現、すなわちＸＭＬデータ表現２１４１およびリレーショナル・データ表現２１４２を示している。しかし、物理データ表現２１４Ｎでは、知られているものにせよ知られていないものにせよ、他のどのようなデータ表現も企図されていることを示している。
一実施形態では、単一のデータ・リポジトリ抽象化コンポーネント１４８が、２つ以上の物理データ表現２１４に関する（関連するアクセス・メソッドをともなう）フィールド仕様を含む。一代替実施形態では、異なる単一のデータ・リポジトリ抽象化コンポーネント１４８が別個の物理データ表現２１４ごとに提供されている。また別の実施形態では、複数のデータ・リポジトリ抽象化コンポーネント１４８が提供され、ここでは、データ・リポジトリ抽象化コンポーネント１４８のそれぞれにより、（１つまたは複数の物理データ表現２１４を含む可能性のある）同じ下位の物理データの異なる部分を露出（expose）する。このようにして、単一のアプリケーション１４０を複数のユーザで同時に使用して、同じ下位データにアクセスを行い、ただしそのアプリケーションに露出されている下位データの特定の部分はそれぞれのデータ・リポジトリ抽象化コンポーネント１４８が決定するようにすることができる。
サポートすべき論理フィールドの異なるタイプの数に応じて、任意の数のアクセスが企図されている。一実施形態では、単純（simple）フィールド、フィルタされた（filtered）フィールド、および合成（composed）フィールド用のアクセス・メソッドが提供される。フィールド仕様２０８１および２０８２ではそれぞれ、単純フィールド・アクセス・メソッド２１２１および２１２２を例示している。単純フィールドは、下位の物理データ表現内の特定のエンティティに直接に対応付けられる（たとえば、所与のデータベースの表（table）および列（column）に対応付けられたフィールド）。例示として、図３に示す単純フィールド・アクセス・メソッド２１２１は、論理フィールド名２１０１（「FirstName」（ファースト・ネーム））を「contact」（連絡先）という名前の表の中の「f_name」という名前の列に対応付ける。フィルタされたフィールド（図２〜３には例を示していない）は、関連する物理エンティティを識別し、物理データ表現内部の項目の特定のサブセットを定義するのに使用する規則を提供する。フィルタされたフィールドの例は、ニューヨーク郵便番号（ZIPcode）フィールドであり、このフィールドは郵便番号の物理表現に対応し、データをニューヨーク州に対して定義されている郵便番号だけに制限するものである。合成アクセス・メソッド（図２〜３には例を示していない）では、アクセス・メソッド定義の一部として与えられる式を用いて１つまたは複数の物理フィールドから論理フィールドを計算する。このようにして、下位のデータ表現内に存在しない情報を計算することができる。１つの例は、売上税（salestax）フィールドであり、このフィールドは、販売価格フィールドに売上税率を乗じることによって合成される。
下位データのどのような所与のデータ型（たとえば、日付、十進数など）に対するフォーマットも、変わる可能性があることを企図している。したがって、一実施形態では、フィールド仕様２０８は、下位データのフォーマットを反映する型属性を含む。しかし、別の実施形態では、フィールド仕様２０８のデータ・フォーマットは、関連する下位の物理データとは異なり、その場合、データを要求側エンティティの仮定する正しいフォーマットで返すのはアクセス・メソッドの役目である。このため、アクセス・メソッドは、下位の物理データの実際のフォーマットだけでなく、データのどのようなフォーマットが仮定されているか（すなわち、論理フィールドに従って）について情報を持っていなければならない。そうして、アクセス・メソッドは下位の物理データを論理フィールドのフォーマットへと変換することができる。
例として、図２〜３に示すデータ・リポジトリ抽象化コンポーネント１４８のフィールド仕様２０８により、リレーショナル・データ表現２１４２で表現されたデータに対応付けられた論理フィールドを代表させている。しかし、データ・リポジトリ抽象化コンポーネント１４８の他のインスタンスでは、論理フィールドを、ＸＭＬなどの、他の物理データ表現に対応付けている。
一実施形態では、１つまたは複数のフィールド仕様２０８は、図１を参照して上で手短かに説明したセキュリティ情報１６２付きで構成される。例示しているこの実施形態では、カテゴリ定義とフィールド定義のどちらにも、関連するセキュリティ情報１６２がある。しかし、すべてのカテゴリ定義およびすべてのフィールド定義が、必ずしもセキュリティ情報を含む必要はないことを理解されたい。カテゴリは２つ以上の論理フィールドの間の関連を定義するものなので、同じカテゴリに属する論理フィールドは、同じカテゴリからのセキュリティ情報を継承する。たとえば、フィールド定義２０８１および２０８２はDemographic（人口統計）カテゴリ２１６１およびPerson（個人）カテゴリ２１６２にそれぞれ属しており、したがって、それぞれのセキュリティ情報１６２１および１６２２を継承する。
セキュリティ情報１６２のさらなる諸態様を表ＩＩを参照して説明することができるが、この表には、図３に示すデータ・リポジトリ抽象化コンポーネント１４８に対応する、ある例示的なデータ・リポジトリ抽象化コンポーネントを示している。例示として、データ・リポジトリ抽象化１４８はＸＭＬを用いて定義されている。しかし、有利になるように他のどのような言語を使用してもよい。
表ＩＩ−データ・リポジトリ抽象化の例
001 <?xmlversion="1.0"?>
002 <DataAbstractionversion="1.0"
003xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
004xsi:noNamespaceSchemaLocation="DataAbstraction.xsd">
005
006 <Categoryname="Person">
007
008 <Securitytype="value">
009 <SecurityRule>
010<User>All</User>
011 <Action>NoRunAndLog</Action>
012</SecurityRule>
013 </Security>
014
015<Field name="First Name">
016<AccessMethod>
017<Simple attrName="FNAME" entityName="PERSONINFO"/>
018</AccessMethod>
019<Type baseType="char"></Type>
020</Field>
021
022<Field name="Last Name">
023<AccessMethod>
024<Simple attrName="LNAME" entityName="PERSONINFO"/>
025</AccessMethod>
026<Type baseType="char"></Type>
027<Security type="value">
028 <SecurityRule>
029<User>All</User>
030<Action> RunAndLog</Action>
031</SecurityRule>
032<SecurityRule>
033<User> securityOfficers </User>
034<Action> RunAndLog </Action>
035</SecurityRule>
036<SecurityRule>
037<User> Mary_McGoon </User>
038<Action> NoAction </Action>
039</SecurityRule>
040</Security>
041 </Field>
042 </Category>
043
044 <Category name="Test">
045 <Field name="HIVTest">
046<AccessMethod>
047<Simple attrName="RESULTS" entityName="TESTS"/>
048</AccessMethod>
049<Type baseType="char"></Type>
050 <Securitytype="access">
051 <SecurityRule>
052<User>All</User>
053<Action> RunAndLog</Action>
054</SecurityRule>
055<SecurityRule>
056<User> securityOfficers </User>
057<Action> RunAndLog </Action>
058</SecurityRule>
059<SecurityRule>
060<User> Mary_McGoon </User>
061<Action> LogAndDoNotRun </Action>
062 </SecurityRule>
063</Security>
064 </Field>
065 </Category>
066</DataRepository>
表ＩＩからわかるように、それぞれのカテゴリ定義およびフィールド定義と関連付けられたセキュリティ情報は、一般に、セキュリティ型（security type）およびセキュリティ規則を含む。セキュリティ規則では、その規則が適用されるユーザまたは複数のユーザ、および規則が呼び出されたときに取るべき特定のアクションを指定している。例示的なアクションは、問い合わせの実行をさせずその試行をログに記録すること、問い合わせを実行しその実行をログに記録すること、またはアクションを取らないことを含む。もちろん、他のアクションも企図するものである。
一実施形態では、セキュリティ型は「値」型、「アクセス」型、またはその両方とすることができる。本例では、「Last Name」フィールド定義で値型（value type）セキュリティを例示し、「HIV Test」フィールド定義でアクセス型（accesstype）セキュリティを例示している。本明細書に定義するように、値型セキュリティ規則では、アクセスをユーザ固有の情報および特定のフィールド値に基づいて制限する（フィールド値の例としては、Mary、McGoon、1111Easy Streetがある）。対照的に、アクセス型セキュリティ規則では、フィールド値によらず、ユーザおよびフィールド型に基づいてどのようなアクセスも制限する（フィールド型の例としては、ファースト・ネーム（firstname）、ラスト・ネーム（last name）、住所がある）。例示の目的で、「Last Name」（ラスト・ネーム）フィールドを考える。ユーザが自分自身のラスト・ネームにアクセスしないようにすることが望ましいが、他のどのラスト・ネームについてもその限りではないと仮定する。この場合、値型セキュリティ規則を「LastName」フィールドに関してすべてのユーザについてインプリメントするが、これは表ＩＩの例示的なデータ・リポジトリ抽象化で行っている通りである（０２８〜０３１行を参照されたい）。セキュリティ情報をこのように付加することにより、ランタイム・コンポーネント１５０は、ユーザが「LastName」フィールドにアクセスしようと試みたときに、あらかじめ定義したセキュリティ・アルゴリズム１５１（図１）を実施しなければならないことを（ランタイム時に）気付かされる。ランタイム・コンポーネントの様々な態様は、以下でより詳細に説明を行う。
別の例示として、「HIV Test」フィールドの場合を考える。このフィールドに含まれる情報が広範囲で慎重さを要するものであることを考えると、特定のユーザがこのフィールドにまったくアクセスしないようにするのが望ましいこともあろう。たとえば、本人がＨＩＶポジティブであるユーザが「HIVTest」フィールドにアクセスしないようにするのが望ましいとしよう。この場合、セキュリティ情報は、アクセス型セキュリティ制限を含む（０４５〜０６４行を参照されたい）。ランタイム中、ランタイム・コンポーネント１５０のセキュリティ・アルゴリズム１５１により、「HIVTest」フィールドにアクセスしようと試みるあるユーザをそうすることから制限するかどうか、または、より一般に、（そのユーザがＨＩＶポジティブであるかどうかに従って）なにかセキュリティ・アクションを取らなければならないかどうかを判断する。したがって、アクセス型制限の場合、要求されている「HIVTest」フィールドにある特定の値は、関係がない。
表ＩＩ（０２２〜０４１行）の論理の「Last Name」フィールドで示しているように、所与のフィールド／カテゴリ定義のためのセキュリティ情報は、セキュリティ規則を２つ以上含んでもよい。特に、異なるセキュリティ規則を、ユーザの異なるクラスに適用することができる。論理「LastName」フィールドのための定義では、ユーザすべてに対する第１のセキュリティ規則、あるグループのユーザに対する第２のセキュリティ規則、ある１人のユーザに対する第３のセキュリティ規則を例示している。一実施形態では、（アプリケーション１４０（図１）の一部であってもよい）最適適合（best-fit）アルゴリズムを使用して、特定のユーザ・クラスにどの制限をかけるかを判断する。たとえば、ユーザMary_McGoonが「LastName」フィールドにアクセスしようと試みた場合、ユーザ・プロファイルMary_McGoonに関する規則を使用する。より的確な（exact）規則指定が見つかったため（すなわち、ユーザMary_McGoonに固有のセキュリティ規則）、「all」（すべて）ユーザおよび「securityofficer」（セキュリティ責任者）に対する規則は無視される。
しかし、一実施形態では、最適適合アルゴリズムによって判断した規則をオーバーライドすることがある。表ＩＩが実例となっている通り、データ・リポジトリ抽象化コンポーネント１４８は、階層的ツリー構造をもつことができる。表ＩＩの例示的なデータ・リポジトリ抽象化では、提示してある最も上位のノードは人口統計カテゴリである。次に上位のノードは個人カテゴリであり、これには子としてファースト・ネーム・フィールドおよびラスト・ネーム・フィールドがある。したがって、一実施形態では、最厳格規則（the strictest rule）は、ツリーの中の最上位ノードに関連付けられている規則である。この例では、最厳格規則は、人口統計カテゴリのセキュリティ情報に関連付けられている規則である。したがって、ユーザMary_McGoonに固有のセキュリティ規則は、人口統計カテゴリの規則によってオーバーライドされるのである。
ここで図４を参照すると、アプリケーション１４０の初期プログラム・ロードおよび動作を例示する方法３００が示してある。（たとえば、管理者が）アプリケーション１４０を起動すると、この方法に入る。ステップ３０２で、データ・リポジトリ抽象化コンポーネントのロード／取り出しを行う。複数のデータ・リポジトリ抽象化コンポーネントが利用可能な一実施形態では、取り出すべきデータ・リポジトリ抽象化コンポーネントは、アプリケーション１４０によって指定する。ステップ３０４で、データ・リポジトリ抽象化コンポーネントのツリー構造ごとにループに入る。ステップ３０６で、ツリー構造にある最厳格規則の識別を行う。これを行うには、そのツリーを最下位ノードから最上位ノードへと「たどって」上に行き（"walking" up）、関連付けられているセキュリティ規則のある最も上位のノードを識別する。最厳格規則の識別が済むと、アプリケーション１４０により、その規則がアクセス型であるかどうかを（ステップ３０８で）判断する。そうである場合、ステップ３１０で、その規則に関連付けられたフィールドを、ユーザ固有アクセス型セキュリティ・リスト３１２に入れる。次いで、方法３００はステップ３０４へと戻って、そのデータ・リポジトリ抽象化コンポーネントにある次のツリー構造のための処理を始める。
ステップ３０８の答えが「いいえ」である場合、処理はステップ３１４へと進み、ここで方法３００は、その規則が値型の規則であるかどうかを判断する。そうである場合、この規則に関連付けられているフィールドを、ステップ３１６でユーザ固有値型セキュリティ・リスト３１８に入れる。次いで、方法３００はステップ３０４へと戻って、データ・リポジトリ抽象化コンポーネントにある次のツリー構造のための処理を始める。
ステップ３１４の答えが「いいえ」である場合、処理はステップ３２０へと進み、ここでその規則に関連付けられたフィールドを適切なセキュリティ・リストに入れる。ステップ３２０は、方法３００を他の型のセキュリティ規則に拡張することに相当する。次いで、方法３００はステップ３０４へと戻って、データ・リポジトリ抽象化コンポーネントにある次のツリー構造のための処理を始める。
方法３００は、データ・リポジトリ抽象化コンポーネントにあるツリー構造のそれぞれを処理してしまうまで続く。すると、アプリケーション１４０が要求の受理を始める準備ができる。
図５に、アプリケーション１４０のログオン検証アルゴリズム１６０の実行するログオン検証方法４００の一実施形態を示している。ログオン検証方法４００は、アプリケーション１４０の使用のためにユーザがサイン・オンするたびに実行される。ステップ４０２で、ログオン検証アルゴリズム１６０は、サイン・オンを行っているユーザに関するアクセス型セキュリティ・リスト３１２を取り出す。ステップ４０４で、検証方法４００は、セキュリティ・リスト３１２のフィールドごとにループを開始する。ステップ４０６で、検証アルゴリズム１６０は、ユーザ・データ（すなわち、データベース１５６の物理データにあるもの）の対応するフィールド（すなわち、処理中のセキュリティ・リスト・フィールドに対応するフィールド）内のエントリについて検査する。対応するエントリが見当たらない場合（ステップ４０８）、処理中のフィールドをセキュリティ・リスト３１２から取り除く。こうして、取り除いたフィールドは、ランタイム中、セキュリティ目的では考慮しないことにするのである。対応するフィールドが見つかった場合（ステップ４０８）、特にアクションを取る必要はなく処理はステップ４０４へと戻って、セキュリティ・リスト３１２の次のフィールドの処理を始める。セキュリティ・リスト３１２の各フィールドの処理が済むと、ログオン検証メソッド４００はステップ４１２へと進む。
ステップ４１２で、サイン・オンを行っているユーザについて値型セキュリティ・リスト３１８を検索する。セキュリティ・リストのフィールドごとに実行するループに、ステップ４１４で入る。ステップ４１６で、検証アルゴリズム１６０がユーザ・データ（すなわち、データベース１５６の物理データ内のもの）の対応するフィールド（すなわち、処理中のセキュリティ・リスト・フィールドに対応するフィールド）内のエントリについて検査を行う。対応するエントリが見当たらない場合（ステップ４１８）、処理中のフィールドをセキュリティ・リスト３１８から取り除く。そうでない場合（すなわち、エントリがステップ４１８で見つかった場合）、対応するユーザ固有エントリの値を値型セキュリティ・リスト３１８に（または何か他のセキュリティ・データ構造に）格納する。どちらの場合も、処理はステップ４１４へと戻る。セキュリティ・リスト３１８の各フィールドを処理してしまうと、ログオン検証アルゴリズム１６０を抜け、ここでユーザは問い合わせの発行を開始してよいことになる。
図６〜７には、ランタイム・コンポーネント１５０の動作の一実施形態を例示する、例示的なランタイム方法５００を示している。特に、ランタイム方法５００の諸態様は、セキュリティ・アルゴリズム１５１（図１）によってインプリメントすることができる。方法５００にステップ５０２で入るのは、ランタイム・コンポーネント１５０が入力として（図２〜３に示す抽象的問い合わせ２０２などの）抽象的問い合わせのインスタンスを受け取るときである。ステップ５０４で、ランタイム・コンポーネント１５０は、抽象的問い合わせのインスタンスを読み込み、構文解析（parse）し、個々の選択基準および所望の結果フィールド（result fields）を見出す。ステップ５０６で、ランタイム・コンポーネント１５０、その抽象的問い合わせに存在する各問い合わせ選択基準ステートメントの処理のためにループに入り、それにより、具体的問い合わせ（ConcreteQuery）のデータ選択部分を作成する。一実施形態では、選択基準は（論理フィールドについて）フィールド名、比較演算子（＝、＞、＜など）、および値の式（そのフィールドを比較する相手）からなる。ステップ５０８で、ランタイム・コンポーネント１５０は、その抽象的問い合わせの選択基準からのフィールド名を使用して、データ・リポジトリ抽象化１４８内のフィールドの指定のルック・アップを行う。上で触れたように、フィールド仕様は、そのフィールドに関連付けられている物理データをアクセスするために使用するアクセス・メソッドの定義を含む。さらに、フィールド仕様は、セキュリティ情報１６２を含むことができる。したがって、ランタイム・コンポーネント１５０は、その取り出した問い合わせフィールド仕様に対して、その特定のユーザ（すなわち、その問い合わせを発行しているユーザ）についてのセキュリティ規則があるかどうかを判断する（ステップ５１０）。すなわち、ランタイム・コンポーネント１５０は、アクセス型セキュリティ・リスト３１２および値型セキュリティ・リスト３１８を参照して、そのフィールド仕様に対応するフィールド名の存在を判断する。どちらのリストにもそのフィールド仕様に関するセキュリティ規則が見当たらない場合、処理はステップ５１６へと進む。セキュリティ規則があった場合には、ランタイム・コンポーネント１５０は、その規則の指定するセキュリティ・アクションを取らなければならないかどうかを判断する（ステップ５１２）。アクセス型制限の場合、規則の指定するセキュリティ・アクションを取らなければならないのは、そのフィールド仕様の論理フィールドに対応するフィールド・エントリが、ステップ５１０でアクセス型セキュリティ・リスト３１２内に見つかった場合であり、これはそのフィールド・エントリの値によらない。値型制限の場合は、規則の指定するセキュリティ・アクションを取らなければならないのは、分析中の論理問い合わせコンポーネント／基準内の論理フィールド値に対応するフィールド値が、ステップ５１０で値型セキュリティ・リスト３１８内に見つかった場合である。ステップ５１２の答えが「はい」である場合は、ランタイム・コンポーネント１５０は、そのアクションを取らなければならないことを（ステップ５１４で）記録する。次いで、処理はステップ５１６へと進む。
次いで、ランタイム・コンポーネント１５０は、処理中の論理フィールドに関する具体的問い合わせ寄与（Concrete Query Contribution）を作成する。本明細書で定義するように、具体的問い合わせ寄与とは、データ選択の実行に使用する具体的問い合わせの、現在の（current）論理フィールドに基づく部分である。具体的問い合わせは、ＳＱＬやＸＱｕｅｒｙなどで表現した問い合わせであり、所与の物理データ・リポジトリ（たとえば、リレーショナル・データベースまたはＸＭＬリポジトリ）のデータと一貫性がある。したがって、具体的問い合わせは、図１に示すＤＢＭＳ１５４の表す、物理データ・リポジトリからデータを見出し、取り出すのに使用される。次いで、現在のフィールド用に生成した具体的問い合わせ寄与を、具体的問い合わせステートメント（ConcreteQuery Statement）に追加する（ステップ５１８）。次いで、方法５００はステップ５０６へと戻って、抽象的問い合わせの次のフィールドのための処理を始める。したがって、ステップ５０６で入ったプロセスを、その抽象的問い合わせないのデータ選択フィールドごとに繰り返して、それにより、実行すべき最終的な問い合わせに追加の内容の寄与を行う。
具体的問い合わせのデータ選択部分を作成した後、ランタイム・コンポーネント１５０は、問い合わせ実行の結果として返すべき情報を識別する。上で説明したように、一実施形態では、抽象的問い合わせは、本明細書で結果仕様（result specification）と呼ぶ、問い合わせ実行の結果として返すべき抽象的フィールドのリストを定義する。抽象的問い合わせ内の結果仕様は、フィールド名および整列基準からなる。一実施形態では、結果仕様はセキュリティ情報１６２をも含み、これは表ＩＩを参照して上で説明したセキュリティ情報と同一にまたは類似に定義することができる。結果仕様を扱うために、方法５００はステップ５２０でループに入って、結果フィールド定義を生成中の具体的問い合わせに追加する。ステップ５２２で、ランタイム・コンポーネント１５０は、データ・リポジトリ抽象化コンポーネント１４８内の（その抽象的問い合わせの結果仕様からの）結果フィールド名のルック・アップを行い、次いでデータ・リポジトリ抽象化コンポーネント１４８から結果フィールド定義を取り出して、現在の論理結果フィールドに関して返すべきデータの物理ロケーションを識別する。ステップ５２４で、ランタイム・コンポーネント１５０は、処理中の特定の結果フィールド定義に関してこの特定のユーザについてセキュリティ規則が存在するかどうかについて判断する。すなわち、ランタイム・コンポーネント１５０がアクセス型セキュリティ・リスト３１２を参照して結果仕様に対応するフィールド名の存在を判断する（値型セキュリティ・リスト３１８は、結果の場合、値が利用可能でないため、検査を行わない）。結果仕様に関するセキュリティ規則が、リスト３１２内に見当たらない場合は、処理はステップ５３０へと進む。そうでない場合、ランタイム・コンポーネント１５０は、その結果フィールドのために定義した規則で取らなければならないアクションが指定されているかどうかを判断する（ステップ５２６）。これは、ステップ５１２に関して説明したのと同様のしかたで実行することができる。ステップ５２６の答えが「はい」である場合、ランタイム・コンポーネント１５０は、そのアクションを取らなければならないことを記録する（ステップ５２８）。どちらの場合にも、処理はステップ５３０へと進む。
ステップ５３０で、ランタイム・コンポーネント１５０は、論理結果フィールドに対する（返すべきデータの物理ロケーションを識別する具体的問い合わせの）具体的問い合わせ寄与を作成する。次いで、ステップ５３２で、具体的問い合わせ寄与を具体的問い合わせステートメントに追加する。
抽象的問い合わせ内の結果仕様のそれぞれの処理が済むと、ランタイム・コンポーネント１５０は、（上で説明したやり方で何かアクションが記録されているかどうかに従って）何かセキュリティ・アクションを取らなければならないかどうかを判断する（ステップ５３４）。そうしなくてよい場合、問い合わせをステップ５４２で実行する。しかし、セキュリティ・アクションを取らなければならない場合は、記録されているアクションを検討して（ステップ５３６）、最厳格のアクションを判断する。一実施形態では、各アクションには、厳しいほど大きくなる数値を割り当ててある。ステップ５３８で、ランタイム・コンポーネント１５０は、そのアクションが致命的（すなわち、問い合わせを実行させない）かどうかを判断する。そうでない場合、問い合わせをステップ５４２で実行する。アクションが致命的である場合は、問い合わせを実行せず、ユーザにセキュリティ違反（security violation）を通知する（ステップ５４０）。そうして、方法５００は終わる。
セキュリティ・アルゴリズム１５１によって実行する上述の問い合わせ検証は、一般に、２つの時点のどちらかで実行できることに留意されたい。一実施形態では、検証は、問い合わせ条件のそれぞれの作成次第起きることにしてよい。そのようなアプローチでは、ユーザへのセキュリティ違反の通知が迅速化されるはずである。しかし、このアプローチの不利な点は、実施中のセキュリティ制限の破壊を試みるユーザの実験（たとえば、問い合わせを修正しながら徐々に増やす）を容易にしてしまうことである。このため、代替アプローチでは、問い合わせ検証の実行を、ユーザが問い合わせ全体を入力し発行してしまってからに限っている。後者のアプローチでは、ランタイム・コンポーネント１５０は、違反がないかを検査する前に問い合わせの全体図が得られることにもなり、それにより、ユーザの意図は単一の条件の場合より、より明確になる。
値型制限についてのランタイム方法５００は、表ＩＩの「Last Name」フィールドおよびデータ・リポジトリ抽象化に関する上の例を参照して例示することができる。ユーザがメアリー・マグーン（MaryMcGoon）であると仮定すると、ラスト・ネームの列（column）にある「McGoon」という値に対するエントリが、ログオン（ログオン検証方法３００）中に値型セキュリティ・リスト３１８に入れられているはずである。ここで、メアリー・マグーンが、McGoonという値を「LastName」フィールドに含む論理問い合わせを発行し、ランタイム・コンポーネント１５０が、アクセス型セキュリティ・リスト３１２と値型セキュリティ・リスト３１８（メアリー・マグーンに対して、この人のログオン時に生成済み）のどちらかが「LastName」フィールドに関するセキュリティ規則を含むかどうかを検査する（ステップ５１０および５２４）。値型セキュリティ・リスト３１８が「Last Name」フィールドに関するセキュリティ規則を含むと判断した後、セキュリティ・アルゴリズム１５１により、その規則では、試みられたアクセスに応答してアクションが要求されているかどうかを判断する（ステップ５１２および５２６）。本例では、分析中の論理的問い合わせ基準が「McGoon」という値を含み、その規則がメアリー・マグーンというユーザに関するアクションを指定する値型規則であるので、アクションが要求されていることになる。表ＩＩのデータ・リポジトリ抽象化コンポーネントによって指定された（また値型セキュリティ・リスト３１８に記録された）アクションは、「NoAction」である。試みられたアクセスがアクションを要求する場合には、セキュリティ・アルゴリズム１５１で、セキュリティ情報１６２で定義するアクションを取らなければならないことが記録される（ステップ５１４および５２８）。
本例では、指定したセキュリティ・アクション（これは、メアリー・マグーンの場合では、NoActionである）が、指定したユーザが問い合わせを特定の値で発行したときに実行される。もちろん、セキュリティ規則の論理をＮＯＴ演算子を用いて構成することもできることが当業者には理解されよう。たとえば、セキュリティ規則を、ユーザ（たとえば、メアリー・マグーン）が問い合わせ内に他の誰かの氏名（name）を入力した場合には実行してログを記録する（RunAndLog）ように構成してよいが、同じユーザが自分の氏名を入力した場合には、何らアクションを取らない（NoAction）ように構成することができ、この逆も可能である。
メアリー・マグーンの例を続けて、メアリーの記録が、この人がＨＩＶ検査を実施してもらったことを示していると仮定する。したがって、アクセス型セキュリティ・リストは、（ログオン検証方法３００の結果として）ＨＩＶ検査フィールドのための列を含むはずである。さらに、メアリーが、ＨＩＶ検査フィールドを参照する問い合わせを発行すると仮定する。
ランタイム・コンポーネント１５０は、アクセス型セキュリティ・リスト３１２と値型セキュリティ・リスト３１８（メアリー・マグーンに対して、この人のログオン時に生成済み）が「HIV Test」フィールドに関するセキュリティ規則を含むかどうかを検査する（ステップ５１０および５２４）。アクセス型セキュリティ・リスト３１２が「HIVTest」フィールドに関するセキュリティ規則を含むかどうかを判断した後で、セキュリティ・アルゴリズム１５１は、その規則が試みられたアクセスに応答してアクションを要求するかどうかを判断している（ステップ５１２および５２６）。これは、アクセス型制限の場合には、問い合わせ内に指定されているフィールドの値は関係がなく、したがって、ＨＩＶ検査フィールドがアクセス型セキュリティ・リスト３１２にあるだけでセキュリティ規則が存在しておりそれを実施しなければならないことが示されるためである。本例のそれぞれにおいて、規則が「アクション」を要求することの判断は、単にある規則が指定されていること、およびその規則を実施するための条件が満たされていることの判断に過ぎないことに留意されたい。もちろん、これまでの実施形態で触れたように、その規則を、「NoAction」規則（たとえば、表ＩＩ、０３８行を参照されたい）として、その「何もしないアクション」（NoAction）を取るべきことを指定することもできる。本例では、取るべきアクションは「LogAndDoNotRun」（ログに記録し実行しない）である。
一実施形態では、アクセス型セキュリティ・リスト３１２および値型セキュリティ・リスト３１８は単にパフォーマンスを高めるために提供しているのに過ぎないことを明確にしておきたい。別の実施形態では、リスト３１２、３１８は使用せず、ランタイム・コンポーネント１５０が、問い合わせを検証するために、データ・リポジトリ抽象化コンポーネント１４８に直接にアクセスする。
ステップ５１６および５３０に従って、論理フィールドのための具体的問い合わせ寄与（ConcreteQuery Contribution）を作成するための方法６００の一実施形態を、図８を参照して説明する。ステップ６０２で、方法６００は、現在の論理フィールドに関連付けられているアクセス・メソッドが単純アクセス・メソッドであるかどうかを問い合わせる。そうである場合、具体的問い合わせ寄与を、物理データ・ロケーション情報に基づいて作成し（ステップ６０４）、次いで処理は上に説明した方法５００に従って続く。そうでない場合、処理はステップ６０６へと進んで、現在の論理フィールドに関連付けられているアクセス・メソッドがフィルタされた（filtered）アクセス・メソッドであるかどうかを問い合わせる。そうである場合、具体的問い合わせ寄与を、一部の物理データ・エンティティに関する物理データ・ロケーション情報に基づいて作成する（ステップ６０８）。ステップ６１０で、具体的問い合わせ寄与の拡張を、物理データ・エンティティに関連付けられているデータからサブセットを作る（subset）のに使用する追加の論理（フィルタ選択）によって行う。次いで、処理は上で説明した方法５００に従って続く。
アクセス・メソッドがフィルタされたアクセス・メソッドではなかった場合、処理はステップ６０６からステップ６１２へと進んで、ここで方法６００は、そのアクセス・メソッドが合成アクセス・メソッドであるかどうかを問い合わせる。そのアクセス・メソッドが合成アクセス・メソッドである場合、合成フィールド式にあるサブ・フィールド参照のそれぞれに対する物理データ・ロケーションを、ステップ６１４で見出し、取り出す。ステップ６１６で、合成フィールド式の物理フィールド・ロケーション情報を、合成フィールド式の論理フィールド参照に代入し、これにより、具体的問い合わせ寄与を生成する。次いで、処理は上で説明した方法５００に従って続く。
アクセス・メソッドが合成アクセス・メソッドでなかった場合、処理はステップ６１２からステップ６１８へと進む。ステップ６１８は、本発明の諸実施形態として企図されている他のどのようなアクセス・メソッドのタイプをも表わす。しかし、全部に満たない利用可能なアクセス・メソッドが実施される実施形態が企図されていることを理解されたい。たとえば、ある特定の実施形態では、使用するのは単純アクセス・メソッドだけである。別の実施形態では、使用するのは単純アクセス・メソッドおよびフィルタされたアクセス・メソッドだけである。
上で説明したように、論理フィールドで、下位の物理データとは異なるデータ・フォーマットが指定されている場合には、データ変換の実行が必要となることがある。一実施形態では、初期変換の実行を、それぞれのアクセス・メソッドごとに、方法６００に従って論理フィールドに対する具体的問い合わせ寄与を作成するときに行う。たとえば、この変換は、ステップ６０４、６０８、および６１６の一部として、またはその直後に実行することができる。それに続く物理データのフォーマットから論理フィールドのフォーマットへの変換の実行は、ステップ５４２で問い合わせを実行した後になる。もちろん、論理フィールド定義のフォーマットが下位の物理データと同じである場合には、変換は必要ではない。
以上の例示では、問い合わせを発行するユーザに対する表の中の列と、別の人物に対する同じ列の間の関連付けを確立することを、セキュリティ条件は前提としている。すなわち、たとえば、値型制限では、ユーザ固有の値（たとえば、ラスト・ネーム）と別の人物に関する（そのユーザがアクセスしようと試みている）同じ値との比較が要求される。もちろん、他の実施形態では、セキュリティ制限を、（その問い合わせを発行している特定のユーザの視点から）他のどのような「慎重さを要する」（sensitive）情報も含むように拡張することができる。たとえば、ユーザが前の配偶者のラスト・ネームにアクセスしないようにすることが望ましいこともあろう。正確にどの値／フィールドを制限するかは、アプリケーション１４０のセキュリティ・アルゴリズムの中で指定することができる。
一実施形態では、セキュリティ制限を他のどのような「慎重さを要する」情報も含むように拡張するという以上の態様を、フィールド相関（field correlation）によって達成することができる。フィールド相関により、特定のフィールドに関するセキュリティを別のフィールド内の値と関係させることができるようになる。たとえば、「LastName」フィールドを「address」フィールドと関連付けて、その同じ住所に住んでいる、またはその問い合わせを発行中のユーザがその住所に住んでいたのと同じ時に、その以前の住所にいた、他の人物の氏名を取り出すことができる。すると、これらの氏名があると、そのユーザの氏名の履歴（namehistory）を検査して、氏名の広範囲のリストを生成し、それにそのユーザがアクセスしないようにすることができる。別の例示としては、データベースに家系情報（genealogicalinformation）があると、規則を書いて家計図をたどり、過去Ｎ世代にわたって複雑な氏名のリストを作成することができる（ここで、たとえば、Ｎは整数とする）。また別の例示としては、ある医者の今の（active）患者のリストがあると（データ・ウェアハウスから容易に利用可能である）、他のすべての氏名に関して、その医者にある程度のセキュリティ制限を課すことができる。
上で説明したように、セキュリティ・アクションには試みられたアクセスのログの記録を含むものがある。より一般には、セキュリティ規則が呼び出されたときには、どのような形（variety）の応答も取ることができることが当業者には理解されよう。たとえば、システム管理者への（たとえば、電子メールによる）通知を発行するのでもよい。
上で触れたように、データ・リポジトリ抽象化コンポーネント１４８は、単に様々な利点を提供する一実施形態を例示するものに過ぎない。一態様では、諸利点の達成を、アプリケーション問い合わせ仕様と下位のデータ表現との緩やかな結合を定義することによって行う。ＳＱＬを使用する際にそうであるように、アプリケーションを特定の表、列およびリレーションシップ情報でエンコードするのではなく、アプリケーションでは、データ問い合わせ要件の定義をより抽象的に行い、次いで、このデータ問い合わせ要件をランタイム時に特定の物理データ表現にバインドする。本発明の緩やかな問い合わせ／データ結合により、要求側エンティティ（たとえば、アプリケーション）を機能させることが、下位のデータ表現が変更された場合、または要求側エンティティを、開発したときに使用したものに比べまったく新しい物理データ表現とともに使用することになる場合でも、可能になる。所与の物理データ表現を変更または再構成する場合には、対応するデータ・リポジトリ抽象化を更新して下位の物理データ・モデルに行われた変更を反映させる。同じ組の論理フィールドが問い合わせによる使用のために利用可能であり、単に物理データ・モデル内の異なるエンティティまたはロケーションにバインドされていたのに過ぎない。その結果、抽象的問い合わせインターフェースに書かれている要求側エンティティは、対応する物理データ・モデルがかなりの変更を受けた場合でも、変更なしで機能し続ける。要求側エンティティが開発したときに使用したものに比べまったく新しい物理データ表現とともに使用することになる場合には、新しい物理データ・モデルの実装を、同じ技術（たとえば、リレーショナル・データベース）を用いながら、異なる情報を命名し編成する方策（たとえば、異なるスキーマ）に従って行うことができる。この新しいスキーマは、アプリケーションの要求する１組の論理フィールドへの対応付けを単純、フィルタ済み、および合成フィールド・アクセス・メソッド技法を用いて行うことのできる情報を含むことになる。あるいは、新しい物理表現では、類似の情報を表現するのに代替的な技術を使用することができる（たとえば、リレーショナル・データベース・システムの使用に対するＸＭＬベースのデータ・リポジトリの使用）。どちらの場合でも、抽象的問い合わせインターフェースを使用するように書かれている既存の要求側エンティティを、容易に、新しい物理データ表現を使用するように移行させる（migrate）ことは、問い合わせ内で参照されるフィールドを、新しい物理データ・モデル内のロケーションおよび物理表現と対応付ける代替的なデータ・リポジトリ抽象化の提供のもとで可能となる。
エンド・ユーザに関して述べると、データ・リポジトリ抽象化により、関係するデータを公開し、選択された内容へのアクセスをさせない、データ・フィルタリング機構が提供される。しかし、データ・リポジトリ抽象化は、単に本発明の一実施形態に過ぎないことを理解されたい。より一般には、本発明はユーザ／データ依存性（user-data dependency）に応じて問い合わせの実行（または非実行）に対する必要を提供するどのようなやり方でも実装される。すなわち、問い合わせ実行は、エンド・ユーザおよびその問い合わせの実行後にアクセスされる／返されるはずの特定のデータに依存させてある。
しかし、本発明のセキュリティ機能および機構を、データ・リポジトリ阻害コンポーネントとは別個に実装できることは、当業者には容易に理解されることを強調しておきたい。たとえば、従来のリレーショナル・データベースの状況で、ある実施形態では、表および列をセキュリティ規則に関連付ける情報を格納するための追加のデータベース表が数多く提供される。セキュリティ規則の適用は、表／列内の情報にアクセスしようとする試みに対して行われる。この場合、セキュリティ・コンポーネントの役目は、問い合わせ言語（たとえば、ＳＱＬ）で書かれた問い合わせを分析すること、および適用される１組のセキュリティ規則の決定を、問い合わせ術語内部で参照される、または特定の問い合わせに対する結果の組のメンバとして返される１組の表／列に基づいて行うことである。
本明細書における特定の値、定義、プログラミング言語および例への参照は、例示の目的に過ぎないことに留意されたい。したがって、本発明は、どのような特定の例示および例によっても限定されるものではない。さらに、本発明の諸態様は選択（SELECTION）操作に関して説明しているが、追加（ADD）、変更（MODIFY）、挿入（INSERT）、削除（DELETE）など、よく知られている操作を含めて、他の入出力操作も企図するものである。もちろん、一部のアクセス・メソッドでは、その特定のアクセス・メソッドを利用するフィールドを用いて定義できる抽象的問い合わせ関数のタイプに制限が生じることもある。たとえば、合成アクセス・メソッドを含むフィールドは、変更、挿入、および削除の実行可能なターゲットではない。
以上は本発明の諸実施形態を対象としているが、本発明の他のおよびさらなる実施形態を、本発明の基本的な範囲から逸脱することなく考案することができ、本発明の範囲は以下の特許請求の範囲によって定めるものとする。
コンピュータ・システムの一実施形態の図である。 本発明の一実施形態のソフトウェア・コンポーネントの論理／物理ビュー（logical/physicalview）である。 抽象的問い合わせおよび抽象化のデータ・リポジトリの論理ビューである。 アプリケーションの開始および動作を示す流れ図である。 ユーザ・ログオン検証シーケンスを示す流れ図である。 ランタイム・コンポーネントの動作を示す流れ図である。 ランタイム・コンポーネントの動作を示す流れ図である。 ランタイム・コンポーネントの動作を示す流れ図である。

Claims (7)

  1. ユーザ・データに関するセキュリティを提供する方法であって、
    前記ユーザ・データを含むデータベースにアクセス可能なサーバ・コンピュータが、
    前記サーバ・コンピュータにネットワークを介して接続されたクライアント・コンピュータの所与のユーザについてのユーザ・データが存在する複数のフィールドのそれぞれを反映する少なくとも１つのセキュリティ・リストを生成するステップであって、前記複数のフィールドのそれぞれは前記所与のユーザについての定義済みセキュリティ規則を有している、前記生成するステップと、
    前記所与のユーザについて、前記少なくとも１つのセキュリティ・リストのユーザ固有インスタンスを生成するステップであって、
    ａ）前記セキュリティ・リストにおける各エントリの各フィールドについて、ユーザ・データが前記所定のユーザに固有であるフィールドについて存在するかどうかを決定するステップと、
    ｂ）存在しない場合に、前記セキュリティ・リストから前記エントリを取り除くステップと
    を含む、前記生成するステップと、
    前記ユーザ固有インスタンスの生成後に、前記データベースに対して発行された前記所与のユーザからのクエリを受信するステップであって、前記クエリが少なくとも１つのフィールドと当該少なくとも１つのフィールドに関連付けられた値とを有する、前記受信するステップと、
    前記セキュリティ・リストが前記クエリの前記少なくとも１つのフィールドに対応するエントリを含むかどうかを決定するために前記セキュリティ・リストにアクセスするステップと、
    前記セキュリティ・リストが前記クエリの前記少なくとも１つのフィールドに対応するエントリを含むことに応じて、前記クエリの前記少なくとも１つのフィールドに関連付けられたセキュリティ規則を実施するステップであって、前記クエリ中のフィールドについて特定されたセキュリティ規則が前記ユーザ・データの存在に基づいて実施されて、前記クエリの実行をさせないこと又は前記クエリの発行のログを記録することが行われる、前記実施するステップと
    を実行することを含む、前記方法。
  2. 前記クエリがＳＱＬクエリである、請求項１に記載の方法。
  3. 前記サーバ・コンピュータが、前記セキュリティ規則を呼び出すステップをさらに実行することを含み、当該呼び出しが、前記クエリを実行すべきかどうかを判断することを含む、請求項１に記載の方法。
  4. 前記サーバ・コンピュータが、前記クエリの前記少なくとも１つのフィールドについて前記ユーザ・データの値にかかわらず、前記クエリの前記少なくとも１つのフィールドについて前記ユーザ・データの存在を判断した後、前記セキュリティ規則を呼び出さなければならないかどうかを判断するステップをさらに実行すること含む、請求項１に記載の方法。
  5. 前記ユーザ固有インスタンスを生成するステップが、前記所与のユーザがログオンする時に実行される、請求項１に記載の方法。
  6. 前記サーバ・コンピュータが、
    前記サーバに接続されたクライアントのユーザからのサインオンに応じて、当該ユーザに関するアクセス型のセキュリティ・リストを取り出すステップであって、当該アクセス型はセキュリティ型の一つであり、当該アクセス型のセキュリティ・リストは、フィールド型の値であるフィールド値によらず、当該セキュリティ・リストにおいて定義されたユーザ及びフィールド型に基づいてアクセスを制限するために使用され、前記フィールド型はファースト・ネーム、ラスト・ネーム又は住所を包含する、前記取り出すステップと、
    前記取り出されたアクセス型のセキュリティ・リストのフィールドごとにループを開始するステップであって、
    ユーザ・データの対応するフィールド内にエントリが存在するかどうかを検査するステップと、
    前記エントリが存在しない場合に、前記アクセス型のセキュリティ・リストから処理中のフィールドを取り除くステップと、
    前記エントリが存在する場合に、前記検査するステップに戻り、別のフィールド内のエントリについて検査するステップと
    を含む、前記開始するステップと、
    前記フィールドごとの前記検査が終了したことに応じて、値型のセキュリティ・リストを検索するステップであって、当該値型はセキュリティ型の一つであり、当該値型のセキュリティ・リストは、当該値型のセキュリティ・リストにおいて定義されたユーザに関する情報及びフィールド型の値である特定のフィールド値に基づいてアクセスを制限するために使用される、前記検索するステップと、
    前記検索された値型のセキュリティ・リストのフィールドごとにループを開始するステップであって、
    ユーザ・データの対応するフィールド内にエントリが存在するかどうかを決定するステップと、
    前記エントリが存在しない場合に、前記値型のセキュリティ・リストから処理中のフィールドを取り除くステップと、
    前記エントリが存在する場合に、対応するユーザ固有エントリの値を前記値型のセキュリティ・リストに格納するステップと、
    を含む、前記開始するステップと
    をさらに実行することを含む、請求項１に記載の方法。
  7. ユーザ・データに関するセキュリティを提供するコンピュータ・プログラムであって、サーバ・コンピュータに、請求項１〜６のいずれか一項に記載の方法の各ステップを実行させるコンピュータ・プログラム。
JP2004543023A 2002-10-03 2003-09-25 データに関するセキュリティを提供する方法、及びそのコンピュータ・プログラム Expired - Fee Related JP4716729B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/264,243 2002-10-03
US10/264,243 US7698441B2 (en) 2002-10-03 2002-10-03 Intelligent use of user data to pre-emptively prevent execution of a query violating access controls
PCT/US2003/030337 WO2004034186A2 (en) 2002-10-03 2003-09-25 Intelligent use of user data to pre-emptively prevent execution of a query violating access controls

Publications (3)

Publication Number Publication Date
JP2006502494A JP2006502494A (ja) 2006-01-19
JP2006502494A5 JP2006502494A5 (ja) 2006-11-09
JP4716729B2 true JP4716729B2 (ja) 2011-07-06

Family

ID=32042191

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004543023A Expired - Fee Related JP4716729B2 (ja) 2002-10-03 2003-09-25 データに関するセキュリティを提供する方法、及びそのコンピュータ・プログラム

Country Status (9)

Country Link
US (1) US7698441B2 (ja)
EP (1) EP1550038A4 (ja)
JP (1) JP4716729B2 (ja)
KR (1) KR100737300B1 (ja)
CN (1) CN100336059C (ja)
AU (1) AU2003278954A1 (ja)
CA (1) CA2498708C (ja)
TW (1) TWI234379B (ja)
WO (1) WO2004034186A2 (ja)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6996558B2 (en) 2002-02-26 2006-02-07 International Business Machines Corporation Application portability and extensibility through database schema and query abstraction
US7900133B2 (en) 2003-12-09 2011-03-01 International Business Machines Corporation Annotation structure type determination
US7661141B2 (en) * 2004-02-11 2010-02-09 Microsoft Corporation Systems and methods that optimize row level database security
US7711750B1 (en) * 2004-02-11 2010-05-04 Microsoft Corporation Systems and methods that specify row level database security
US20050289342A1 (en) * 2004-06-28 2005-12-29 Oracle International Corporation Column relevant data security label
US20060294066A1 (en) * 2005-06-23 2006-12-28 International Business Machines Corporation Visual display of information using historical condition support and event profiles
US8577684B2 (en) 2005-07-13 2013-11-05 Intellisist, Inc. Selective security masking within recorded speech utilizing speech recognition techniques
US8321387B2 (en) * 2005-07-28 2012-11-27 International Business Machines Corporation Restricting access to sensitive data
US7444332B2 (en) * 2005-11-10 2008-10-28 International Business Machines Corporation Strict validation of inference rule based on abstraction environment
US7440945B2 (en) 2005-11-10 2008-10-21 International Business Machines Corporation Dynamic discovery of abstract rule set required inputs
US7756843B1 (en) * 2006-05-25 2010-07-13 Juniper Networks, Inc. Identifying and processing confidential information on network endpoints
US8433915B2 (en) 2006-06-28 2013-04-30 Intellisist, Inc. Selective security masking within recorded speech
GB0625641D0 (en) * 2006-12-21 2007-01-31 Symbian Software Ltd Dynamic filtering for partially trusted servers
TWI382319B (zh) * 2006-12-22 2013-01-11 Hon Hai Prec Ind Co Ltd 多任務解析系統及方法
US20090019424A1 (en) * 2007-07-12 2009-01-15 Sap Ag System and method of application context driven access restriction
KR101039698B1 (ko) * 2009-06-12 2011-06-08 (주)소만사 애플리케이션을 경유한 ｄｂ접근을 보호하기 위한 데이터베이스 보안 시스템, 서버 및 방법
US10162851B2 (en) * 2010-04-19 2018-12-25 Salesforce.Com, Inc. Methods and systems for performing cross store joins in a multi-tenant store
US20110264688A1 (en) * 2010-04-26 2011-10-27 International Business Machines Corporation Peer to peer (p2p) data licensing model in a distributed abstract query environment
US8266170B2 (en) 2010-04-26 2012-09-11 International Business Machines Corporation Peer to peer (P2P) missing fields and field valuation feedback
KR101104845B1 (ko) * 2010-09-08 2012-01-16 (주)소만사 데이터베이스와 클라이언트 간 ｄｂ ｖｐｎ을 이용한 안전 통신 시스템 및 방법
KR101143998B1 (ko) * 2011-09-20 2012-05-09 주식회사 안철수연구소 데이터베이스 보안 장치 및 방법
US9819798B2 (en) 2013-03-14 2017-11-14 Intellisist, Inc. Computer-implemented system and method for efficiently facilitating appointments within a call center via an automatic call distributor
CN104516882B (zh) 2013-09-26 2018-02-06 国际商业机器公司 确定sql语句的危害度的方法和设备
US9619581B2 (en) * 2013-12-20 2017-04-11 Microsoft Technology Licensing, Llc Constructing queries for execution over multi-dimensional data structures
US10769122B2 (en) * 2014-03-13 2020-09-08 Ab Initio Technology Llc Specifying and applying logical validation rules to data
US9251221B1 (en) * 2014-07-21 2016-02-02 Splunk Inc. Assigning scores to objects based on search query results
EP3256949B1 (en) * 2015-02-12 2021-12-15 Visa International Service Association Multi-party encryption cube processing apparatuses, methods and systems
US10754978B2 (en) 2016-07-29 2020-08-25 Intellisist Inc. Computer-implemented system and method for storing and retrieving sensitive information
CN109582691B (zh) * 2018-11-15 2023-04-07 百度在线网络技术（北京）有限公司 用于控制数据查询的方法和装置
US11106679B2 (en) * 2019-10-30 2021-08-31 Ocient Holdings LLC Enforcement of sets of query rules for access to data supplied by a plurality of data providers
US11768916B2 (en) 2019-12-11 2023-09-26 Paypal, Inc. Detection of sensitive database information
US11379601B2 (en) * 2019-12-11 2022-07-05 Paypal, Inc. Detection of sensitive database information

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000035949A (ja) * 1997-10-31 2000-02-02 Sun Microsyst Inc セキュア分散型ネットワークにおけるデータベースアクセス制御を供給するシステム及び方法
JP2001092844A (ja) * 1999-09-24 2001-04-06 Nippon Telegr & Teleph Corp <Ntt> 異種情報源問い合わせ変換方法及び装置及び異種情報源問い合わせ変換プログラムを格納した記憶媒体
JP2001344147A (ja) * 2000-05-31 2001-12-14 Dainippon Printing Co Ltd 汎用データベースアクセス装置
JP2005524138A (ja) * 2002-04-25 2005-08-11 インターナショナル・ビジネス・マシーンズ・コーポレーション 複数データ・リポジトリーの環境にあるデータにアクセスする方法、コンピュータ・プログラム、およびコンピュータ

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5560008A (en) 1989-05-15 1996-09-24 International Business Machines Corporation Remote authentication and authorization in a distributed data processing system
JPH087709B2 (ja) 1989-05-15 1996-01-29 インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン アクセス特権制御方法及びシステム
US5204961A (en) 1990-06-25 1993-04-20 Digital Equipment Corporation Computer network operating with multilevel hierarchical security with selectable common trust realms and corresponding security protocols
US5023765A (en) 1990-12-03 1991-06-11 Barton Daniel W Pivotable lamp bracket for linear lighting fixture
JPH0799497B2 (ja) 1990-12-14 1995-10-25 インターナショナル・ビジネス・マシーンズ・コーポレイション ソフトウェアの使用を管理するための装置及び方法
US5577209A (en) 1991-07-11 1996-11-19 Itt Corporation Apparatus and method for providing multi-level security for communication among computers and terminals on a network
US5355474A (en) 1991-09-27 1994-10-11 Thuraisngham Bhavani M System for multilevel secure database management using a knowledge base with release-based and other security constraints for query, response and update modification
US5481700A (en) 1991-09-27 1996-01-02 The Mitre Corporation Apparatus for design of a multilevel secure database management system based on a multilevel logic programming system
US5572673A (en) 1993-12-01 1996-11-05 Sybase, Inc. Secure multi-level system for executing stored procedures
US5751949A (en) 1995-05-23 1998-05-12 Mci Corporation Data security system and method
US5859966A (en) 1995-10-10 1999-01-12 Data General Corporation Security system for computer systems
US5768532A (en) 1996-06-17 1998-06-16 International Business Machines Corporation Method and distributed database file system for implementing self-describing distributed file objects
US6226745B1 (en) * 1997-03-21 2001-05-01 Gio Wiederhold Information sharing system and method with requester dependent sharing and security rules
AU9604598A (en) * 1997-10-10 1999-05-03 Rambus Incorporated Apparatus and method for device timing compensation
US6038563A (en) * 1997-10-31 2000-03-14 Sun Microsystems, Inc. System and method for restricting database access to managed object information using a permissions table that specifies access rights corresponding to user access rights to the managed objects
US6112181A (en) 1997-11-06 2000-08-29 Intertrust Technologies Corporation Systems and methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information
US6141754A (en) * 1997-11-28 2000-10-31 International Business Machines Corporation Integrated method and system for controlling information access and distribution
US6272488B1 (en) 1998-04-01 2001-08-07 International Business Machines Corporation Managing results of federated searches across heterogeneous datastores with a federated collection object
US6578037B1 (en) * 1998-10-05 2003-06-10 Oracle Corporation Partitioned access control to a database
US6487552B1 (en) * 1998-10-05 2002-11-26 Oracle Corporation Database fine-grained access control
WO2000026750A1 (en) * 1998-11-05 2000-05-11 NEUVIS, Inc Method for controlling access to information
US6237003B1 (en) * 1998-11-30 2001-05-22 Platinum Technology Ip, Inc. Method and apparatus for supporting dynamic run-time object definition in a relational database management system
US6745332B1 (en) 1999-06-29 2004-06-01 Oracle International Corporation Method and apparatus for enabling database privileges
US7089588B2 (en) 2000-01-19 2006-08-08 Reynolds And Reynolds Holdings, Inc. Performance path method and apparatus for exchanging data among systems using different data formats

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000035949A (ja) * 1997-10-31 2000-02-02 Sun Microsyst Inc セキュア分散型ネットワークにおけるデータベースアクセス制御を供給するシステム及び方法
JP2001092844A (ja) * 1999-09-24 2001-04-06 Nippon Telegr & Teleph Corp <Ntt> 異種情報源問い合わせ変換方法及び装置及び異種情報源問い合わせ変換プログラムを格納した記憶媒体
JP2001344147A (ja) * 2000-05-31 2001-12-14 Dainippon Printing Co Ltd 汎用データベースアクセス装置
JP2005524138A (ja) * 2002-04-25 2005-08-11 インターナショナル・ビジネス・マシーンズ・コーポレーション 複数データ・リポジトリーの環境にあるデータにアクセスする方法、コンピュータ・プログラム、およびコンピュータ

Also Published As

Publication number Publication date
CA2498708A1 (en) 2004-04-22
KR20050069995A (ko) 2005-07-05
EP1550038A2 (en) 2005-07-06
AU2003278954A8 (en) 2004-05-04
US20040068661A1 (en) 2004-04-08
WO2004034186A2 (en) 2004-04-22
WO2004034186A3 (en) 2004-06-24
AU2003278954A1 (en) 2004-05-04
CN100336059C (zh) 2007-09-05
KR100737300B1 (ko) 2007-07-09
US7698441B2 (en) 2010-04-13
JP2006502494A (ja) 2006-01-19
TW200406113A (en) 2004-04-16
TWI234379B (en) 2005-06-11
CN1688977A (zh) 2005-10-26
CA2498708C (en) 2011-03-22
EP1550038A4 (en) 2009-04-01

Similar Documents

Publication Publication Date Title
JP4716729B2 (ja) データに関するセキュリティを提供する方法、及びそのコンピュータ・プログラム
US6954748B2 (en) Remote data access and integration of distributed data sources through data schema and query abstraction
US7089235B2 (en) Method for restricting queryable data in an abstract database
US6928431B2 (en) Dynamic end user specific customization of an application&#39;s physical data layer through a data repository abstraction layer
US8165989B2 (en) Automated data model extension through data crawler approach
US7096229B2 (en) Dynamic content generation/regeneration for a database schema abstraction
JP4378288B2 (ja) データに対してセキュリティを実現する方法
US20040080549A1 (en) Data referencing within a database graph
US7836071B2 (en) Displaying relevant abstract database elements
US7228307B2 (en) Security model using security domains in a security model applied to abstract database
US20080319968A1 (en) Processing query conditions having filtered fields within a data abstraction environment
US20070050323A1 (en) Abstractly mapped physical data fields
US9031924B2 (en) Query conditions having filtered fields within a data abstraction environment
US9679031B2 (en) Composing abstract queries for delegated user roles
US7089232B2 (en) Method of synchronizing distributed but interconnected data repositories
US20060074873A1 (en) Extending data access and analysis capabilities via abstract, polymorphic functions

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060922

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060922

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20090206

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100208

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100223

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100423

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20100423

RD12 Notification of acceptance of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7432

Effective date: 20100423

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20100426

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101124

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110223

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20110223

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110315

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20110315

RD14 Notification of resignation of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7434

Effective date: 20110315

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110329

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140408

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees