JP4698243B2

JP4698243B2 - 行レベルのデータベースセキュリティを最適化するシステムおよび方法

Info

Publication number: JP4698243B2
Application number: JP2005026874A
Authority: JP
Inventors: チャンデルギリシュ; アール．ハミルトンジェームズ; ビー．クリストファラウレンチウ; エヌ．クラインロジャー; ダッタタンモイ
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2004-02-11
Filing date: 2005-02-02
Publication date: 2011-06-08
Anticipated expiration: 2025-02-02
Also published as: US7661141B2; US20050177570A1; CN100492357C; KR20050081164A; EP1564620A1; JP2005228312A; CN1655145A; KR101120814B1

Description

本発明は一般にデータベースに関し、より詳細には、クエリを行レベルのセキュリティ式で増補して、性能を最適化しデータ漏洩を軽減するシステムおよび方法に関する。

コンピュータハードウェア、ソフトウェア、ネットワーキングにおける技術的進歩は、例えば紙や電話による通信などの従来技法を介してではない、電子的な情報交換の需要の増大につながった。このような電子通信は、全世界のほぼ任意の２つの位置間で、瞬間的かつ信頼性のあるデータ転送を提供することができる。多くの産業および消費者は、このような技術を活用して、ウェブベースの（例えばオンライン）サービスを介して効率を高め、コストを削減している。例えば消費者は、家で都合のよい時にマウスのクリックで商品を購入したり、銀行明細を見たり、製品および会社を調査したり、リアルタイムの株相場を得たり、パンフレットをダウンロードしたりすることができる。

利用可能な電子データの量が増加するにつれて、このようなデータを、ユーザフレンドリで素早いデータ検索および取出しを容易にする管理可能な方式で記憶することがより重要になる。今日、一般的な手法の１つは、電子データを１つまたは複数のデータベースに記憶することである。一般に、典型的なデータベースの１つは、例えばコンピュータプログラムがデータを素早く検索および選択できるように構築された、組織的な情報の集合である。従来、データベース内に記憶されたデータは１つまたは複数のテーブルによって構成され、各テーブルはレコードのセットを含み、レコードはフィールドのセットを含む。レコードは一般にテーブル内の行として索引付けされ、レコードフィールドは一般に列として索引付けされ、それにより、行／列の対はテーブル内の特定データを参照することができる。

データベースに記憶されたデータは、しばしば個人情報（例えば銀行口座や社会保障番号）および機密情報（例えば医療記録）を含み、ハードコピーによってバックアップされないことがある。したがって、データベースおよびそれに記憶されたデータに関するセキュリティの重要性が高まっている。しかし、現在のデータベースセキュリティ技法の多くは、例えばソフトウェアホールおよび／または悪意あるソフトウェアハッカーによって破られる可能性があるか、あるいは包括的なレベルのセキュリティを提供しないものである。

本発明のいくつかの態様の基本的な理解を提供するために、以下に本発明の簡単な概要を提示する。この概要は、本発明の広範な概観ではない。また、本発明の鍵となる要素またはクリティカルな要素を識別するものでもなく、本発明の範囲を線引きするものでもない。この概要の唯一の目的は、後で提示するより詳細な記述への前置きとして、本発明のいくつかの概念を簡単な形で提示することだけである。

本発明のシステムおよび方法は、向上した構文を提供することによってデータベースの行レベルのセキュリティを容易にするものであり、向上した構文を利用して、名前付きセキュリティ式を作成してそれらを１つまたは複数のクエリ開始元に関連付けることができる。このような式は、データがクエリ開始元からアクセス可能になるためにはそのデータ行によって満たされなければならない、任意のブール式として表される述語を含むことができる。一般に、行レベルのセキュリティが有効になっているとき、受け取ったクエリは、クエリ開始元に関連するセキュリティ式で増補される。これらの式は、データ行を照会する間に利用され、これらのセキュリティ式を満たす（または「真」に評価される）行は、クエリ開始元からアクセス可能になる。特定の一実施例では、受け取ったクエリは、満たされるときに行アクセスを許可するブール式の離接と、満たされるときに行アクセスを拒否するブール式の補集合の合接との合接からなる式を接合することによって増補される。言い換えれば、少なくとも１つの許可式が満たされるときであってどの拒否式も満たされないときに集約的なセキュリティ式を行データが満たすように、クエリは増補される。

このシステムおよび方法は、クエリ性能を最適化するために、セキュリティ式を含めた式をクエリ内で様々に配置および移動することができる。従来の技法は、１つまたは複数のセキュリティ式を他の式よりも先に評価すべきかどうかを考慮しない。したがって、従来のシステムは漏洩を被りやすく、その場合ユーザは、ユーザに見えるべきでないデータへのアクセスを得ることができる。本発明はこのような漏洩を軽減する。通常これは、セキュリティ式を特別にタグ付けして、セキュリティ式と非セキュリティ式を区別することによって達成される。次いで、述語移動規則を利用して、データ漏洩の軽減を容易にすることができる。これらの規則は、制限された状況下でのみ、非セキュリティ式がセキュリティ式よりも上または下にくることができるようにするものである。多くの場合、コンパイル時に静的分析を実施して、式が「安全な」式かどうか、または情報開示のリスクなしに実行できる式かどうかを判定することができる。他の場合では、別法としてまたは追加で実行時に動的分析を実施して、式が「安全な」式かどうかを判定することができる。動的分析では、通常、セキュリティ述語がうまく実行されたときに、かつ／または安全違反（例えばエラー条件、割込み、イベントなど）が起こらないときに、結果が返され、変更が加えられる。静的と動的の両方の分析で、安全違反が見つからなかった場合は、性能を向上させるように式の配置順序を決定することができる。しかし、安全違反が検出された場合は、クエリをアボートするか、または「セーフ」モードで実行することができ、その場合、セキュリティ式は非セキュリティ式が実行される前に評価される。一般に、論理演算は「安全」とみなされる。

セキュリティ式は、ＳＱＬなどのデータベース言語を介してクエリ開始元に関連付けることができる。例えば、セキュリティ式はＳＱＬＣＲＥＡＴＥユーティリティを使用して作成することができる。作成されたセキュリティ式は、ＳＱＬＧＲＡＮＴまたはＳＱＬＤＥＮＹユーティリティを介してクエリ開始元に関連付けることができる。許可および／または拒否セキュリティ式はＳＱＬＲＥＶＯＫＥユーティリティを介して取り消すことができ、セキュリティ式はＳＱＬＤＲＯＰユーティリティを介して削除することができる。このようなセキュリティ式は通常、クエリに組み込まれ、データを照会するときに利用される。一般に、許可セキュリティ式は、行が許可セキュリティ式を満たすときにデータ行へのアクセスを提供するセキュリティ式であり、拒否セキュリティ式は、行が拒否セキュリティ式を満たすときにデータ行へのアクセスを禁止するセキュリティ式である。前述のように、複数のセキュリティ式を１つのクエリ開始元に関連付けることができ、したがって、許可と拒否の両方のセキュリティ式をユーザに関連付けることができる。通常、拒否セキュリティ式は許可よりも優先され、したがって、両方のタイプのセキュリティ式を満たす行は、クエリ開始元に利用可能にはならない。加えて、拒否セキュリティ式の補集合を利用することもでき、それにより、データ行を複数のセキュリティ式で評価することから得られる集約的な結果は、少なくとも１つの許可セキュリティ式が満たされるときであってどの拒否セキュリティ式も満たされないときに「真」になる。

従来、セキュリティを行に関連付けるためには、各行を識別する必要があった。しかし、多くのデータベースプログラミング言語は、テーブル中の各行をアドレスで識別することを含まない。場合により、主キーをテーブルに対するアドレスとして利用することはできる。しかし、あらゆるテーブルに主キーが関連付けられているわけではない。さらに、テーブル中には多くの行がある場合があるので、テーブル中の各行を個々に識別できるようにセキュリティを関連付けることは、データ管理問題につながる可能性がある。さらに、セキュリティ情報を各行に記憶することは非効率的であって空間を消費する可能性があり、特に、各行に記憶される値があまり大きくない場合はそうである。加えて、多くのデータベースプログラミング言語は、セキュリティを指定できるための構文を規定しているが、これはテーブル、あるいはテーブルを構成する１つまたは複数の列に対するセキュリティ指定であり、各行に対するものではない。本発明の新規なシステムおよび方法を利用して、向上したＳＱＬ構文を介して前述の欠点を緩和することができる。

以下の記述および添付の図面に、本発明のいくつかの例示的な態様を詳細に示す。ただし、これらの態様は、本発明の原理を採用することのできる様々な方法のいくつかだけを示すものであり、本発明はこのような態様およびその均等物すべてを含むものとする。本発明のその他の利点および新規な特徴は、以下の本発明の詳細な記述を図面と共に考察したときに明らかになるであろう。

本明細書で使用する用語「コンポーネント」「システム」「マネージャ」などは、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかであるコンピュータ関連エンティティを指すものとする。例えばコンポーネントは、限定しないが、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行ファイル、実行のスレッド、プログラム、および／またはコンピュータとすることができる。例として、サーバ上で実行されているアプリケーションもサーバも両方とも、コンポーネントとすることができる。１つまたは複数のコンポーネントが１つのプロセスおよび／または実行スレッド内にあるものとすることができ、また、１つのコンポーネントは１つのコンピュータ上に局所化されてもよく、複数のコンピュータ間で分散されてもよい。

本発明は、行レベルのデータベースセキュリティを実施するためのシステムおよび方法に関する。このようなセキュリティは、同様のセキュリティ特性を有する行の１つまたは複数のセットを論理的にクラスタ化して、これらを、テーブルおよび／またはコンテキストデータ（これらに限定しない）に対して定義されたブール式などの１つまたは複数のプログラミングステートメントを含む名前付き式として共に扱うことを可能にする。クエリの述語を構成して性能を最適化しセキュリティ漏洩を軽減するために、セキュリティ式を様々な形でクエリに増補することができる。加えて、セキュリティ式は集約することができ、それにより、集約が満たされる（例えば「真」を返す）場合はデータ行へのアクセスが提供され、集約が満たされない（例えば「偽」を返す）場合はデータ行へのアクセスが制限されるようにすることができる。

本発明について図面を参照して述べるが、図面を通して、同じ要素を参照するのには同じ参照番号を使用する。以下の記述では、説明の目的で、本発明の完全な理解を提供するための多くの具体的な詳細を示す。ただし、本発明はこれらの具体的な詳細がなくても実施できることは明白であろう。他の場合では、本発明の記述を容易にするために、周知の構造およびデバイスはブロック図の形で示す。

図１に、データ照会時のデータアクセスセキュリティを容易にするシステム１００を示す。システム１００は、入力コンポーネント１１０、クエリマネージャ１２０、出力コンポーネント１３０を備える。入力コンポーネント１１０はクエリを受け取る。このようなクエリは、例えばＳＱＬなど、ほぼ任意のデータベースプログラミング言語から開始することができ、１つまたは複数のデータベース、テーブル、コンテキスト情報などを含むデータリポジトリを対象とすることができる。

クエリマネージャ１２０は、受け取ったクエリを増補して、それにデータセキュリティを組み込むことができる。このようなセキュリティは、データリポジトリ内のデータの所有者が作成することができ、作成されたセキュリティは、この所有者のデータにセキュリティをもたらす。セキュリティは、データの様々なフォーマットまたは構造に適用することができる。例えば、データが行、テーブル、および／または列に関連する場合、セキュリティはこれらのどれにも適用しないこともでき、すべてに適用することもでき、任意の組合せに対して適用することもできる。加えて、セキュリティが満たされるとデータへのアクセスが提供されるか、またはセキュリティが満たされるとデータへのアクセスが禁止されるように、セキュリティを構築することができる。セキュリティは複数の異なるセキュリティで構成されるものとすることができ、そのいくつかはアクセスを提供することができ、そのいくつかはアクセスを禁止することができることを理解されたい。

さらに、テーブルの作成者は、１つまたは複数のセキュリティ式を１つまたは複数の照会元にリンクすることができる。一般に、セキュリティがリンクされていない場合、照会元はどんなデータも見ることができない。セキュリティが照会元にリンクされている場合、照会元は、データが、そのデータへのアクセスを提供する少なくとも１つのセキュリティ式を満たすときであって、そのデータへのアクセスを拒否するセキュリティをどれも満たさないときにのみ、そのデータにアクセスすることができる。通常、アクセス拒否セキュリティはアクセス許可セキュリティよりも優先され、したがって、データが両方のタイプのセキュリティを満たすときは、アクセスは拒否される。加えて、許可と拒否のセキュリティは両方とも、取り消すことができる。以上により、データ所有者は、自分のデータのどの部分に誰がアクセスできるかを選択的に決定することができる。加えて、照会元には免除ステータスの属性を与えることができ、したがってこの照会元にはセキュリティは適用されず、照会元は本質的にすべてのデータにアクセスすることができる。通常、テーブルの所有者は、このようにしてすべての行レベルのセキュリティ制限から免除される。

増補されたクエリは、出力コンポーネント１３０に搬送することができる。出力コンポーネント１３０はこのようなクエリを、次の処理に向けて提供することもでき、あるいは、それ自体を含めたデータ照会元コンポーネントに提供することもできる。

図２にデータセキュリティシステム１００を示すが、このデータセキュリティシステム１００は、入力コンポーネント１１０、クエリマネージャ１２０、出力コンポーネント１３０を備え、さらにオプティマイザ２１０も備える。前述のように、入力コンポーネント１１０は、様々に構築されたデータのデータリポジトリに対するクエリの要求を受け取る。クエリマネージャ１２０は、要求を増補して、それにデータセキュリティ式を組み込む。このようなセキュリティは、データリポジトリ内のデータの所有者が作成することができ、作成されたセキュリティは、この所有者のデータにセキュリティをもたらす。セキュリティは、「真」「偽」や「０」「１」等の２進数値に評価されるブール式など、秘密情報使用許可(security clearance)および制限付きアクセスを示すために定義することのできる式によって規定することができる。

複数の式が利用されるときは、各式を連続的にまたは同時に評価し、個々の結果を集約して（例えば共に論理積および論理和をとって）、判定を下すことができる。先に簡単に示したように、満たされるときにデータへのアクセスを明白に許容（例えば許可）または禁止（例えば拒否）する式を生成することができる。このような式を禁止するデータが満たされると「真」が得られるので、このような式が満たされると「偽」が得られるように補集合を利用することができる。したがって、少なくとも１つの許可式が満たされるときであってどの拒否式も「真」に評価されないときに「真」を返す集約的な式を作成することができる。ブール式を採用することができるが、本発明の一態様により他の技法を利用することもできることを理解されたい。そのような技法は、確率および／または信頼度レベルを提供することができる場合があり、カットオフ点を定義するための調整可能しきい値を組み込むことができる場合がある。

オプティマイザ２１０は、クエリを最適化するために、セキュリティ式を含めた式をクエリ内に組み込むことおよび移動することができる。従来の技法は、正しく接合された１つまたは複数のセキュリティ式を他の式よりも先に評価すべきかどうかを考慮しない。したがって、従来のシステムは漏洩を被りやすく、その場合ユーザは、ユーザに見えるべきでないデータへのアクセスを得る。本発明はこのような漏洩を軽減する。通常これは、セキュリティ式をクエリに接合するときにセキュリティ式にタグ付けして、セキュリティ式と非セキュリティ式を区別することによって達成される。次いで、オプティマイザ２１０によって述語移動規則を利用して、情報漏洩の軽減を容易にすることができる。これらの規則により、オプティマイザ２１０は、制限された種類の非セキュリティ式だけをセキュリティ式よりも上にするか、または制限された種類の非セキュリティ式だけをセキュリティ式よりも下にすることができる。

多くの場合、コンパイル時に静的分析を実施して、式が「安全な」式かどうか、または情報開示のリスクなしに実行できる式かどうかを判定することができる。他の場合では、別法としてまたは追加で実行時に動的分析を実施して、式が本当に「安全な」式かどうかを判定することができる。動的分析では、通常、実行中に安全違反（例えばエラー条件、割込み、イベントなど）を起こさずにクエリがうまく完了したときに、結果が返され、変更が加えられる。静的と動的の両方の分析で、安全違反が見つからなかった場合は、オプティマイザ２１０は、性能を向上させるように式の配列順序を決定することができる。しかし、安全違反が検出された場合は、クエリをアボートするか、または「セーフ」モードで実行することができ、その場合、セキュリティ式は非セキュリティ式が実行される前に評価される。セキュリティ述語をクエリ中で特別にタグ付けすることによって、このような実行計画が可能である。静的分析では一般に、論理演算は普通「安全」とみなされる。クエリをセキュリティ式で増補してクエリ内の式を最適化すると、クエリを出力コンポーネント１３０に搬送することができる。出力コンポーネント１３０は、増補されたクエリを、次の処理またはデータ照会のために提供することができる。

図３にデータセキュリティシステム１００を示すが、このデータセキュリティシステム１００は、入力コンポーネント１１０、クエリマネージャ１２０、出力コンポーネント１３０、オプティマイザ２１０を備え、さらに式バンク３１０も備える。入力コンポーネント１１０は、連続的におよび／または同時に１つまたは複数のクエリからデータ要求を受け取ることができ、複数の要求は、データリポジトリ内の類似のおよび／または異なるデータに関連するものとすることができる。加えて、複数の要求を連続的におよび／または同時に扱うことができる。多くの場合、要求をキューに入れるために、バッファ（図示せず）などのメモリを利用して、要求関連の情報を一時的に記憶することができる。例えば、優先度のより低い要求を処理している間に、高優先度の符号の付いた要求を受け取ることができ、その場合、優先度のより高い要求がサービスされるまで、優先度のより低い要求をキャッシュしておくことができる。

式バンク３１０は、１つまたは複数のセキュリティ式ならびに非セキュリティ式を記憶するのに利用することができる。このような式は、１つまたは複数の要求元および／または１つまたは複数の要求元グループに関連付けることができる。式は、要求元を識別したときに式バンク３１０から取り出すことができる。例えば、受け取ったクエリは、要求元（例えばユーザ、アプリケーションなど）または要求を送ったマシンに関連付けられている、固有の識別子を含む場合がある。別の例では、そのような情報がクエリの前および／または後にくる場合がある。他の例では、インテリジェンスを利用して、要求元および／または適したセキュリティ式のセットを決定することができる。要求に対する取り出したセキュリティ式は、データリポジトリを検索する間に利用することができる。

データ管理者がアプリケーションプログラミングインタフェース（ＡＰＩ）（図示せず）を利用して、自分のデータに関係するセキュリティ式を式バンク３１０中に作成することができることを理解されたい。例えば、ＳＱＬプログラミング言語のＣＲＥＡＴＥユーティリティを利用して、セキュリティ式を作成することができる。例えば以下のＳＱＬ構文を利用してセキュリティ式を作成することができる。
CREATE EXPRESSION<expression_name>ON<data_name>AS(<expression>)
上の構文で、＜ｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅ＞は式の名前を指定し、＜ｄａｔａ＿ｎａｍｅ＞はソース（例えば１つまたは複数のテーブル名やそのサブセット）を指定し、＜ｅｘｐｒｅｓｓｉｏｎ＞は、行中のデータへのアクセスを得るためにその行によって満たされなければならないセキュリティ式である。前述のように、このような式を特定の要求元および／または要求元グループにリンクすることができる。例えば、ＳＱＬを利用するとき、データ管理者は、ＧＲＡＮＴ、ＲＥＶＯＫＥ、ＤＥＮＹユーティリティを介して、特定のデータソースに対して作成されたセキュリティ式をユーザおよび／またはユーザグループにリンクすることができ、かつ／または、ＤＲＯＰユーティリティを介してセキュリティ式を削除することができる。これについては後で詳細に述べる。

ある特定の実施例では、クエリマネージャ１２０は、許可ブール式を離接し（例えば論理和をとり）（各式は許可対象である関連するセキュリティプリンシパル（例えばセキュリティ識別）と合接される（例えば論理積がとられる））、得られた離接と、拒否ブール式それぞれの補集合の合接（例えば論理積）（各式は拒否対象であるセキュリティプリンシパルと合接される）とを合接する（例えば論理積をとる）ことで構成された式を接合することによって、クエリを増補することができる。言い換えれば、クエリマネージャは、少なくとも１つの許可式が満たされるときであってどの拒否式も満たされないときにデータがクエリを満たすことができるように、クエリを増補することができる。このような増補済みクエリは、出力コンポーネント１３０に搬送することができ、データ照会を容易にするのに利用することができる。

図４に、データベースセキュリティを容易にするシステム４００を示す。システム４００は、データベースへのユーザアクセスポイント４０５を備える。図示のように、ユーザアクセスポイント４０５はデスクトップコンピュータである。ただし、ポータブルコンピュータ（例えばラップトップ、タブレットＰＣなど）、ハンドヘルドコンピュータ（例えばＰＤＡ）、ワークステーション、携帯電話機など、任意のマイクロプロセッサベースのデバイスを本発明の一態様により利用することができることは理解できるであろう。

多くの場合、ユーザアクセスポイント４０５は、より大きいネットワーク／バス（例えばプラント全体または会社全体）内のサブネットワーク／バスに結合されており、サブネットワーク／バスにアカウントを有するユーザは、ユーザアクセスポイント４０５にログインして、ユーザに与えられた特権（例えば権利、所有権など）の範囲内で、内部にあるエンティティおよびアプリケーションにアクセスすることができる。通常、より細かいレベルの区別が利用され、ネットワークに関連するユーザは、ドメイン、グループ、プロジェクト、仕事の種類、作業グループ、課、部門、ステータスなどに区分され、これらにはそれぞれ、異なる特権を関連付けることができる。加えて、いずれかの同様の区分内のユーザに異なる特権を関連付けることもできる。例えば、複数のユーザをグループ化して、ユーザのうちの１人に、残りのユーザに対する監督者のステータスを与えることができる。このようなユーザは普通、他のユーザを制限する特権を有する。例えば監督者は、別のユーザの、読取りや書込みや実行の特権、特定の情報を閲覧する能力、および／またはインターネット機能を修正することができる。

この実施例では、ユーザはＬ個のこのようなグループに区分されており、Ｌは１以上の整数である。Ｌ個のグループは、グループ_１４１０_１、グループ_２４１０_２からグループ_Ｌ４１０_３までを含み、グループ４１０と総称することができる。グループ４１０は、異なるユーザおよび／または同様のユーザを含むことができる。したがって、ある特定のユーザが複数のグループに関連付けられていてもよい。グループ_１４１０_１はＭ人のユーザを含むものとして示されており、Ｍは１以上の整数である。Ｍ人のユーザは、ユーザ_１４２０_１、ユーザ_２４２０_２からユーザ_Ｍ４２０_３までを含む。このようなユーザをユーザ４２０と総称することができる。ユーザ４２０のうちの１人がアクセスポイント４０５にログインすると、ユーザ識別（例えば固有ＩＤ、通称など）、グループ名、ドメイン名、作業グループなどを決定することができ、これらを利用してユーザの環境を構成することができる。このような構成には、カスタマイズされたインタフェースを実行することや、データを隠蔽することや、データを公開することや、読取り、書込み、および／または実行の特権を設定することを含めることができる。

このユーザは、クエリマネージャ１１０を介してデータベース４３０と通信することができる。例えば、データベース４３０に対するクエリを送ると、このクエリはクエリマネージャ１１０が受け取ることができる。クエリマネージャ１１０は、クエリのソースを得ることができ、かつ／または、ユーザ識別および／またはグループ識別など、その他の様々な特性を得ることができる。クエリマネージャ１１０は、この情報を利用して、適したセキュリティ式を入手して適用することができる。前述のように、このようなセキュリティは１つまたは複数のブール式を含むことができ、これらの式は、データが基準を満たすときにデータアクセスを可能にする基準、またはデータが基準を満たすときにデータアクセスを緩和する基準に関係するものとすることができる。

セキュリティ式は、式バンク３１０から得ることができる。このような式は、１つまたは複数の要求元、および／あるいは１つまたは複数の要求元グループに関連するものとすることができ、要求を式に関連付けると、式を取り出すことができる。例えば、受け取ったクエリは、要求元（例えばユーザ、アプリケーションなど）または要求を送ったマシンに関連付けられている、固有の識別子を含む場合がある。別の例では、そのような情報がクエリの前および／または後にくる場合がある。他の例では、インテリジェンスを利用して、要求元および／または適したセキュリティ式のセットを決定することができる。

セキュリティ式は、ＳＱＬプログラミング言語を介して作成することができる。例えば、ＳＱＬＣＲＥＡＴＥユーティリティを利用して、テーブルに対する名前付き式を作成することができ、この名前付き式は、データへのアクセスを得るためにデータによって満たされなければならないブール式を指定する。データセキュリティを利用するために、このような式を特定の要求元および／または要求元グループにリンクすることができる。例えば、ＳＱＬを利用するとき、データ管理者は、ＧＲＡＮＴ、ＲＥＶＯＫＥ、ＤＥＮＹユーティリティを介して、特定のデータソースに対するセキュリティ式をユーザおよび／またはユーザグループにリンクすることができ、かつ／またはＤＲＯＰユーティリティを介してセキュリティ式を削除することができる。これについては後で詳細に述べる。一般に、名前付き式は、その式を満たすほぼすべての行の代理として挙動する。したがって、この技法を利用することにより、テーブル中のすべての行を表現することができ、かつ／または、テーブル上に主キーが存在するときは個々の行を表現することができる。加えて、ほぼ任意の数のセキュリティ式をテーブルに対して定義することができ、テーブルに対して定義された複数の式によって単一の行を満たすことができる。以上のことは、同様のセキュリティ特性を有する行のセットを論理的にクラスタ化してこのセットを名前付き式として扱うための機構を提供する。

クエリマネージャ２１０は、許可ブール式を離接し（各式は許可対象である関連セキュリティプリンシパルと合接される）、得られた離接と、拒否ブール式それぞれの補集合の合接（各式は拒否対象であるセキュリティプリンシパルと合接される）とを合接することで構成された式を接合することによって、クエリを増補することができる。言い換えれば、クエリマネージャは、少なくとも１つの許可式が満たされるときであってどの拒否式も満たされないときにデータがクエリを満たすことができるように、クエリを増補することができる。

データベース４３０中のデータに対するセキュリティ式は、データの所有者または管理者が作成することができ、１人または複数のユーザにリンクすることができることを理解されたい。このリンクは、ユーザに直接付与する結果として確立することもでき、あるいは１つまたは複数のユーザロール、サーバ、グループなどを介して間接的にユーザに付与することもできる。例えば、以下のようにテーブルを定義することができる。
Emp(id int,salary float)

上の定義で、Ｅｍｐはテーブル名であり、ｉｄは型ｉｎｔｅｇｅｒの変数であり、ｓａｌａｒｙは型ｆｌｏａｔの変数である。テーブルに対する式は、ＳＱＬＣｒｅａｔｅ式を介して作成することができる。例えば、以下の式を実行して、このテーブルに対する式を作成することができる。
CREATE EXPRESSION SalLimit ON Emp AS(salary<X)

上式で、ＳａｌＬｉｍｉｔは式の名前であり、ｓａｌａｒｙはテストすべきフィールドであり、Ｘ（例えば１０００００）は、行データがセキュリティ式を満たすかどうかを判定する変数である。拒否および／または取消しステートメントなど、その他の様々なステートメントも同様に、対応する式を介して採用できることに留意されたい。

ＳａｌＬｉｍｉｔセキュリティ式は、以下の許可式構文を介してユーザにリンクすることができる。
GRANT SELECT(where SalLimit)ON Emp TO User1

上の構文で、Ｕｓｅｒ１は、ＳａｌＬｉｍｉｔを満たすテーブル行にあるデータへの権限が許可されるユーザである。このようなステートメントは、ＳａｌＬｉｍｉｔ式を満たすＥｍｐテーブル中の行を見ることがＵｓｅｒ１に許可されていることを示唆することができる。

上の例のような許可セキュリティ式がなければ、行中のデータが式を満たすことができず、したがってユーザにはどの行中のデータへのアクセスも提供されないことになる。加えて、このような条件を満たさない行はどれも、ユーザには見えなくなる。さらに、拒否セキュリティ式が満たされる場合、ユーザはそのデータを見ることが禁止される。

前述のように、セキュリティは追加で、列に基づくこともできる。例えば、以下のステートメントは、行レベルと列レベルの両方のセキュリティを許可することができる。
GRANT SELECT(where SalLimit,Col1)ON Emp TO User1

上のステートメントで、追加の引数Ｃｏｌ１を利用して、テーブルＥｍｐ内の列を指定する。さらに、同じテーブルに対して複数の許可、拒否、および／または取消しステートメントがあってもよい。通常は拒否ステートメントが許可ステートメントよりも優先されるが、そうでない方法でシステムを構成することもできる。このようなステートメントの許可対象は、データベースシステム中で認可された任意のプリンシパルとすることができ、例えば仕様によって定義されたものとすることができる。

同様に、行、列、および／またはテーブルレベルのセキュリティのための拒否式と、許可または拒否を取り消すための取消し式が提供される。以下により、例示的なＳＱＬ拒否構文を示す。
DENY SELECT(WHERE<expression_name>)ON<data_name>TO(<user_name>)

上の構文で、＜ｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅ＞はセキュリティ式を指定し、＜ｄａｔａ＿ｎａｍｅ＞は、セキュリティ式に対して評価すべきソースデータを指定し、＜ｕｓｅｒ＿ｎａｍｅ＞は、名前付きセキュリティ式に関連付けるべきユーザまたはユーザグループを指定する。以下により、例示的なＳＱＬ取消し構文を示す。
REVOKE SELECT(WHERE<expression_name>)ON<data_name>FROM(<user_name>)

上の構文で、＜ｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅ＞は取り消すべきセキュリティ式を指定し、＜ｄａｔａ＿ｎａｍｅ＞はソースデータを指定し、＜ｕｓｅｒ＿ｎａｍｅ＞は、名前付きセキュリティ式から分離すべきユーザまたはユーザグループを指定する。

オプティマイザ２１０は、性能を最適化するために、受け取ったクエリ内で、セキュリティ式を含めた式を移動することができる。一般に、セキュリティ式は、セキュリティ式と非セキュリティ式を区別するためにタグ付けされ、述語規則を利用して、どのようにセキュリティ式をクエリ内に組み込むかに関する範囲が定義される。述語規則により、オプティマイザ２１０は、セキュリティ式の実行前に安全でない式を利用してデータを返すことができないことを確認した後でのみ、非セキュリティ式をセキュリティ式よりも上にするか、または非セキュリティ式をセキュリティ式よりも下にすることができる。通常、論理演算は普通「安全」とみなされ、オプティマイザ２１０はそのような演算をセキュリティ式よりも上または下に順序付けることができる。

多くの場合、ユーザ定義の式などの式が分析されて、安全かどうかが判定される。一般に、論理演算は普通「安全」とみなされる。このような分析は静的に実施することができる。前述のように、静的分析はコンパイル時に実施される。対照的に、動的分析は実行時に実施される。動的分析では、安全違反が検出された場合、そのクエリはアボートするか、または「セーフ」モードで実行することができ、その場合、セキュリティ式は非セキュリティ式が実行される前に評価される。

クエリマネージャ１１０は、セキュリティ式を適用して基準を満たすデータだけを返すことにより、照会を容易にすることができる。図示のように、照会は、テーブル_１４４０_１、テーブル_２４４０_２からテーブル_Ｎ４４０_３までのＮ個のテーブル（Ｎは１以上の整数）と、データ４５０とを含むデータベース４３０に対して実施される。テーブル_１４４０_１、テーブル_２４４０_２からテーブル_Ｎ４４０_３までを、テーブル４４０と総称することができることに留意されたい。一般に、テーブル４４０は、データを構造化フォーマットで記憶することができる。このような構造化フォーマットは、同様の構造を有するエンティティの１つまたは複数のセットを含むことができ、各エンティティは行と呼ぶことができる。各行は、列と呼ぶことのできるフィールドに関連付けることができる。

図５〜８に、本発明による方法を示す。説明を簡単にするために、本方法を一連の動作として図示および記述する。本発明は、例示する動作および／または動作順序によって限定されないことを認識および理解されたい。例えば、動作は様々な順序で、かつ／または同時に実施することができ、また本明細書に提示しない他の動作と共に実施することができる。さらに、本発明による方法を実施するのに、例示する動作すべてが必要とは限らない。加えて、本方法は別法として、状態図またはイベントによって一連の相関状態として表すこともできることは、当業者なら理解および認識するであろう。

図５に進むと、行レベルのデータベースセキュリティを実施する方法５００が示されている。参照番号５１０で、１人または複数のユーザからの１つまたは複数のクエリを受け取る。このようなクエリは、連続的および／または同時に受け取ることができ、データベース中の同様のおよび／または異なるデータに関連するものとすることができる。加えて、クエリは、デスクトップコンピュータ、ポータブルコンピュータ、ハンドヘルドコンピュータ、ワークステーション、携帯電話機などのデータベースアクセスポイントから送ることができる。クエリを受け取ると、クエリのソースを決定することができる。多くの場合、ソースは、ユーザを識別するのに利用することのできるユーザの名前、住所、ネットワーク、サブネットワーク、ドメイン、グループ、プロジェクト、仕事の種類、作業グループ、課、部門、ステータスなどに関連し、個々のユーザには異なる特権を関連付けることができる。同様の区分内のユーザに、同様のまたは異なる特権を関連付けることができることに留意されたい。

参照番号５２０で、ユーザに対するセキュリティ式を得ることができる。例えば、データベース中のデータの所有者は、自分のデータのための１つまたは複数のセキュリティ式を作成して、このような式をユーザにリンクすることができる。１つまたは複数のセキュリティ式を、１つまたは複数のテーブルに対して作成することができ、１人または複数のユーザに提供することができることを理解されたい。したがって、データは複数のユーザに対する複数のセキュリティ式を同時に満たして、データへの同時アクセスを可能にすることができる。ソースを識別することができない場合、インテリジェンスを利用してセキュリティ式を推論することができ、かつ／またはデフォルトのセキュリティ式を適用することができる。

５３０で、クエリをセキュリティ式で増補することができる。複数の式が利用されるときは、各式を論理積および／または論理和によって論理ステートメントに集約して、判定を提供することができる。加えて、満たされるときにデータへのアクセスを明白に許容（例えば許可）または禁止（例えば拒否）する式を作成することができる。このような式を禁止するデータが満たされると「真」が得られるので、このような式が満たされると「偽」が得られるように補集合を利用することができる。したがって、少なくとも１つの許可式が満たされるときであってどの拒否式も「真」に評価されないときに「真」を返す集約的な式を作成することができる。ブール式を採用することができるが、本発明の一態様により他の技法を利用することもできることを理解されたい。

例えば、クエリは、許可ブール式の離接（各式は許可対象である関連セキュリティプリンシパルと合接される）を、拒否ブール式それぞれの補集合の合接（各式は拒否対象であるセキュリティプリンシパルと合接される）と合接することによって、増補することができる。したがって、少なくとも１つの許可式が満たされるときであってどの拒否式も満たされないときにデータがクエリを満たすことができるように、クエリを増補することができる。

参照番号５４０で、クエリを最適化することができ、セキュリティ式をクエリ内で移動して性能を最適化することができる。このような最適化は、メモリ漏洩の軽減を容易にする述語規則によって導かれる。これらの規則は、非セキュリティ式が「安全」かどうかに応じて、非セキュリティ式がセキュリティ式よりも上または下にくることができるようにする。多くの場合、コンパイル時に静的分析を実施して、式が「安全な」式かどうか、または情報開示のリスクなしに実行できる式かどうかを判定することができる。他の場合では、別法としてまたは追加で実行時に動的分析を実施して、式が「安全な」式かどうかを判定することができる。動的分析では、通常、セキュリティ述語がうまく実行されたときに、かつ／または安全違反（例えばエラー条件、割込み、イベントなど）が起こらないときに、結果が返され、変更が加えられる。静的と動的の両方の分析で、安全違反が見つからなかった場合は、性能を向上させるように式の配置順序を定義することができる。しかし、安全違反が検出された場合は、クエリをアボートするか、または「セーフ」モードで実行することができ、その場合、セキュリティ式は非セキュリティ式が実行される前に評価される。一般に、論理演算は普通「安全」とみなされる。

増補されたクエリは、データベース照会の間に利用することができる。例えば、照会を実施する間にデータベースのデータを評価して、データがセキュリティを満たすかどうかを判定することができる。データがセキュリティを満たす場合は、データを要求元に利用可能にすることができ、したがって例えば、要求元はデータを閲覧、ダウンロード、および／または操作することができる。

図６に、行レベルのアクセスを提供するための行レベルのデータベースセキュリティをイネーブルにする方法６００を示す。参照番号６１０で、行レベルのセキュリティをイネーブルにする。例えば、ＡＬＴＥＲＴＡＢＬＥＯｒｄｅｒｓＳＥＴＲＯＷ＿ＳＥＣＵＲＩＴＹ＝ＯＮというＳＱＬステートメントを利用して、テーブルに対する行レベルのアクセスを有効にすることができる。通常、行レベルのアクセスを有効にしない場合、ユーザはどの行にもアクセス可能でないか、またはすべての行にアクセス可能である。参照番号６２０で、ＧＲＡＮＴＳＥＬＥＣＴコマンドを介してユーザに権限を許可する。６３０で、ＣＲＥＡＴＥＥＸＰＲＥＳＳＩＯＮコマンドを介してユーザ制限をユーザに関連付ける。６４０で、ＧＲＡＮＴ”ｗｈｅｒｅ”ステートメントを介して、１つまたは複数のテーブルに対する関連するロールに述語を関連付ける。６５０で、クエリを述語で増補することができ、増補済みクエリを利用することができ、セキュリティ式を満たすデータがユーザに提供される。本明細書に述べる複数の許可セキュリティ式ならびに拒否セキュリティ式をクエリ内に組み込んで、データ照会の間に利用することができることを理解されたい。

図７に、行レベルのアクセスを拒否するための行レベルのデータベースセキュリティをイネーブルにする方法７００を示す。参照番号７１０で、行レベルのセキュリティをイネーブルにする（例えばＡＬＴＥＲＴＡＢＬＥＯｒｄｅｒｓＳＥＴＲＯＷ＿ＳＥＣＵＲＩＴＹ＝ＯＮ）。７２０で、ＳＱＬＤＥＮＹＥＸＰＲＥＳＳＩＯＮコマンドを利用して、ユーザに対するデータ権限を拒否することができる。参照番号７３０で、セキュリティステートメント（例えばブール式）を、１つまたは複数のテーブルに対する関連するロールに関連付ける。７４０で、セキュリティステートメントをクエリに挿入し、照会の間に利用する。セキュリティステートメントで評価されたデータが拒否式を満たす場合は、データはユーザから隠蔽される。一般に、拒否セキュリティ式は許可セキュリティ式よりも優先され、したがって、データが両方のタイプの式を満たす場合は、ユーザは許可式および拒否式に関連するデータにアクセスできないことになる。通常、拒否式の補集合が許可式と集約され、したがって、集約的な式が満たされる場合はデータへのアクセスが提供される。

図８に、行レベルのデータベースセキュリティを取り消す方法８００を示す。参照番号８１０で、クエリを受け取り、クエリ開始元を識別する。参照番号８２０で、データ管理者は、ユーザに関連するセキュリティ式を確認し、もはやユーザが自分に関連付けられることを望んでいないセキュリティ式を選択する。前述のように、ユーザには、許可と拒否の両方のセキュリティ式を関連付けることができる。８３０で、ＲＥＶＯＫＥコマンドを利用して、ユーザに対する選択した許可および／または拒否セキュリティ式関連付けを分断または終了することができる。

図９に、例示的なＳＱＬクエリ管理システム９００を示す。ＳＱＬクエリ管理システム９００は、データに対するクエリを受け入れる入力コンポーネント９１０と、このようなクエリをセキュリティ式で増補するのを容易にするＳＱＬクエリマネージャ９２０と、結果をユーザに提供する出力コンポーネント９３０とを備える。システム９００は、ＣＲＥＡＴＥ、ＤＲＯＰ、ＧＲＡＮＴ、ＲＥＶＯＫＥ、ＤＥＮＹなどのＳＱＬユーティリティを利用して行レベルのアクセス制御を容易にすることができ、これらはとりわけ、テーブルに対してＳＥＬＥＣＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ、および／またはＩＮＳＥＲＴアクションを採用するときに有利である。以下に、本発明の一態様による、例示的なＣＲＥＡＴＥ、ＤＲＯＰ、ＧＲＡＮＴ、ＲＥＶＯＫＥ、ＤＥＮＹ構文ならびに対応する説明および例と、ＳＥＬＥＣＴ、ＵＰＤＡＴＥ、ＤＥＬＥＴＥ、ＩＮＳＥＲＴの例を提供する。

（ＣＲＥＡＴＥ）
行レベルのアクセス制御（例えばセキュリティ）を有効にするためにテーブルに適用される述語は、ＤＤＬＣＲＥＡＴＥＥＸＰＲＥＳＳＩＯＮを使用して作成することができる。このような述語は、名前を与えられることができ、式の名前を含む構文（例えばＧＤＲ）を利用してテーブルに適用される。
構文：
CREATE EXPRESSION<expression_name>ON<tablename>AS(<expression>)
ＣＲＥＡＴＥユーティリティは、＜ｅｘｐｒｅｓｓｉｏｎ＞中に明記された式をテーブル＜ｔａｂｌｅｎａｍｅ＞に対して作成することができ、それに＜ｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅ＞と呼ばれる名前を割り当てることができる。
制限：
・通常はサブクエリを含めることはできない。
・式が関数への参照とそれらの関数に対する作成者参照許可とを含んでいる場合は、関数呼出しを含めることができる。
・式には名前を与えるべきである（ｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅ）。
・ｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅは固有であるべきである。
権限：
ｄｂ＿ｄｄｌａｄｍｉｎ、ｄｂ＿ｏｗｎｅｒロール、ｓｙｓａｄｍｉｎロールのメンバと、テーブル所有者と、データベース、スキーマ、および／またはテーブルレベルのＦＵＬＬＣＯＮＴＲＯＬ権限を有するユーザとは、そのテーブルに対する式を作成する権限を有することができる。加えて、テーブルに対するＡＬＴＥＲＡＮＹＴＡＢＬＥおよび／またはＡＬＴＥＲを有するユーザも、そのテーブルに対する式を作成する権限を有する。
例：
CREATE EXPRESSION My_Filter ON shipTable AS(ship_city='redmond'and order_num>35)

（ＤＲＯＰ）
ＣＲＥＡＴＥＥＸＰＲＥＳＳＩＯＮステートメントを使用して作成された述語は、後でＤＲＯＰＥＸＰＲＥＳＳＩＯＮステートメントを使用して削除することができる。
構文：
DROP EXPRESSION<expression_name>ON<Tablename>
制限：
・指定されたｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅは通常、すでに存在していなければならない。
・現ユーザは通常、ｄｂ＿ｄｄｌａｄｍｉｎ、ｄｂ＿ｏｗｎｅｒ、および／またはｓｙｓａｄｍｉｎロールのメンバ、ならびに式が識別されるテーブルの所有者である必要があり、かつ／あるいは、式を削除するテーブルに対するＦＵＬＬＣＯＮＴＲＯＬおよび／またはＡＬＴＥＲ権限を有する必要がある。
・式は通常、テーブルに対する行レベルのセキュリティを確立するのに現在利用されていない場合にのみ削除することができる。
・いずれかの制限に違反した場合は、エラー（例えば「式が存在しないか使用中の可能性があります。あるいはこのステートメントを実行する権限がありません。」）を返すことができる。

（ＧＲＡＮＴ）
構文：

ＵＰＤＡＴＥ権限には、ＢＥＦＯＲＥまたはＡＦＴＥＲを接頭辞として付けることができる。ＢＥＦＯＲＥまたはＡＦＴＥＲは通常、行レベルのセキュリティが指定されている場合にのみ指定することができる。一般に、ＢＥＦＯＲＥは、述語が行の前イメージに適用されることを示唆し、セキュリティは行中の現在値に基づく。ＡＦＴＥＲは、セキュリティが後イメージに基づくことを示唆し、これらの値を利用して行が更新される。＜ｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅ＞は、セキュリティ制限を開始するのに使用される式（例えばＣＲＥＡＴＥＥＸＰＲＥＳＳＩＯＮ構文を介して前に作成されたもの）の名前である。
制限：
・ＧＲＡＮＴは通常、テーブルに対してでなければならない。
・権限は通常、テーブルレベルで適用される。
・ＷＩＴＨＧＲＡＮＴＯＰＴＩＯＮは通常、行レベルの制限を指定するときに可能になる。それ以上の許可は一般に、この式の許可対象が行うことができる。
・＜ｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅ＞は通常、ＣＲＥＡＴＥＥＸＰＲＥＳＳＩＯＮステートメントを介してすでに指定された有効な式名でなければならない。
・ＧＲＡＮＴを発行するユーザは通常、テーブルの所有者であるか、あるいはテーブル、ｄｂ＿ｏｗｎｅｒ、ｄｂ＿ｓｅｃｕｒｉｔｙａｄｍｉｎ、および／またはｓｙｓａｄｍｉｎロールのメンバに対してＦＵＬＬＣＯＮＴＲＯＬ権限を有する必要がある。
例：
GRANT SELECT WHERE(Myfilter)ON Table1 TO RedMgrs
GRANT BEFORE UPDATE WHERE(Filter2)ON Table2 TO public

（ＲＥＶＯＫＥ）
構文：

ＲＥＶＯＫＥは、すでにＧＲＡＮＴまたはＤＥＮＹを介して適用されたセキュリティ権限を取り消すのに使用することができる。
制限：
・＜ｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅ＞は通常、取り消される特定の権限に対してすでに前のＧＲＡＮＴまたはＤＥＮＹを使用してテーブルに対して指定された有効な式名でなければならない。
・通常、列名または取り消す式を指定することができる。
・通常、ＧＲＡＮＴまたはＤＥＮＹに基づいて、ＣＡＳＣＡＤＥオプションがＲＥＶＯＫＥの式に適用されることになる。これは通常、前のＧＲＡＮＴまたはＤＥＮＹ中で指定されたのと同じ式でなければならず、すでに許可された式によって定義される行のサブセットは取り消すことができない。
・ＲＥＶＯＫＥが成功するためには、ユーザは通常、テーブル所有者である必要があるか、あるいはテーブル、ｄｂ＿ｓｅｃｕｒｉｔｙａｄｍｉｎ、ｄｂ＿ｏｗｎｅｒ、および／またはｓｙｓａｄｍｉｎロールのメンバに対してＦＵＬＬＣＯＮＴＲＯＬ権限を有さなければならない。
例：
REVOKE SELECT WHERE(MyFilter)ON Table1 TO RedMgrs

ＤＥＮＹ
構文：

＜ｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅ＞は、セキュリティ制限を実施するのに使用される式（前のＣＲＥＡＴＥＥＸＰＲＥＳＳＩＯＮ構文を介して作成されたもの）の名前である。
制限：
・ＤＥＮＹは通常、テーブルに対してである。
・権限は通常、テーブルレベルで適用される。
・ＣＡＳＣＡＤＥオプションは通常、行レベルの制限を指定するときに可能であり、これは、許可された場合は全く同じ式を第１レベルで拒否してより低いレベルで取り消すことになるが、そのサブセットについてはそうしない。
・＜ｅｘｐｒｅｓｓｉｏｎ＿ｎａｍｅ＞は通常、すでにＣＲＥＡＴＥＥＸＰＲＥＳＳＩＯＮステートメントを介して指定された有効な式名でなければならない。
・ＤＥＮＹを発行するユーザは通常、テーブルの所有者であるか、ｄｂ＿ｏｗｎｅｒ、ｄｂ＿ｓｅｃｕｒｉｔｙａｄｍｉｎ、および／またはｓｙｓａｄｍｉｎロールのメンバである必要がある。
例：
DENY SELECT WHERE(MyFilter)ON Table1 TO BelvMgrs
これらの式は、ｓｙｓｏｂｊｅｃｔｓオブジェクトに含めることができる。加えて、対応するカタログビューがｓｙｓ．ｏｂｊｅｃｔｓ中にあってよい。テーブル所有者と、ＦＵＬＬＣＯＮＴＲＯＬおよび／またはＶＩＥＷＤＥＦＩＮＩＴＩＯＮ権限を有するユーザは、テーブルに適用される式を見ることができる。

クエリがテーブルに対して発行されると、クエリは、必要なセキュリティ制限を呼び出すためにテーブルレベルで適用された述語で増補される。ＳＥＬＥＣＴがテーブルに対して発行されると、クエリは、ＧＲＡＮＴＳＥＬＥＣＴまたはＤＥＮＹＳＥＬＥＣＴステートメントによってテーブルに適用されたすべての述語で内部増補される。ＵＰＤＡＴＥがテーブルに対して発行されると、クエリは、ＧＲＡＮＴ／ＤＥＮＹ、ＢＥＦＯＲＥの場合のＵＰＤＡＴＥ、ＳＥＬＥＣＴステートメントによってテーブルに適用されたすべてのＢＥＦＯＲＥおよびＵＰＤＡＴＥ述語で内部増補される。ＢＥＦＯＲＥＵＰＤＡＴＥの場合、述語中で指定される制限は、行中の更新後の値ではなく現在値に基づく。ＡＦＴＥＲＵＰＤＡＴＥ、ＩＮＳＥＲＴ制限は、制約のように挙動する。すなわち、これらは更新の後イメージに作用する。選択するためのアクセスをユーザが現在有する行だけしか更新することはできない。ＤＥＬＥＴＥが発行されると、クエリは、ＧＲＡＮＴ／ＤＥＮＹＳＥＬＥＣＴおよびＤＥＬＥＴＥステートメントによってテーブルに適用された述語で増補される。ユーザは、現在選択されている行だけしか削除することができない。テーブルに対して定義されたセキュリティ式は、他のどんな述語が適用されるよりも前に適用される。すなわち、ユーザ述語は、評価ツリー中のすべてのセキュリティ述語よりも下になる。

複数のセキュリティ述語がある場合は、ＧＲＡＮＴ中で指定された述語の論理和がとられ、ＤＥＮＹによって指定された各述語の否定と、それらとの論理積がとられる。加えて、行レベルのセキュリティなしで、テーブルレベルまたは列レベルの権限を設定することもできる。行レベルのセキュリティが導入された場合、ユーザは、明示的なアクセスが許可された行へのアクセスを有する。したがって、ユーザが特定のテーブル中で見るのは、列レベルと行レベルの権限の共通部分である。行レベルのセキュリティを可能にするには、最初にテーブルにそのように符号を付けなければならない。これは、ＣＲＥＡＴＥ／ＡＬＴＥＲＴＡＢＬＥ構文中でＲＯＷ＿ＳＥＣＵＲＩＴＹフラグを使用して行うことができる（例えばＡＬＴＥＲＴＡＢＬＥＳＥＴＲＯＷ＿ＳＥＣＵＲＩＴＹ＝ＯＮ）。

テーブルの行レベルのセキュリティがイネーブルになると、所有者は、行レベルのセキュリティがいくつかの個別の行に適用されるかどうかを判定することができる。これは、１つまたは複数の行へのアクセスを許可する述語を利用して行うことができる。ＥｘｅｍｐｔＲｏｗＳｅｃｕｒｉｔｙ権限を利用しても、同じ効果を達成することができる。この権限は、許可対象がテーブルに対してこれを発行したときにはどのセキュリティ述語もクエリに適用されないようにすることができ、行レベルのセキュリティはこれらの述語を介してのみ適用されるので、これによって行レベルのセキュリティを適用しない効果が達成される。ＥｘｅｍｐｔＲｏｗＳｅｃｕｒｉｔｙ権限はまた、誰が行レベルのセキュリティを受け取るべきかを所有者が選択的に決定することができるという点でも有用である。述語はいつでもテーブルに適用することができるが、これらはＥｘｅｍｐｔＲｏｗＳｅｃ権限を有さないユーザのクエリに増補されるだけであることを理解されたい。

前述のように、クエリに述語を増補せずにテーブル照会能力を特定のユーザに許可することが有用な可能性がある。加えて、いくつかまたはすべての述語を追加、削除、および／または改変する必要なしに、行レベルのセキュリティを一時的にディセーブルにすることが有用な可能性もある。これは、ＥｘｅｍｐｔＲｏｗＳｅｃ権限を許可することによって行うことができる。ＴａｂｌｅＯｗｎｅｒと、ｄｂ＿ｏｗｎｅｒおよびｓｙｓａｄｍｉｎロールのメンバと、ＣＯＮＴＲＯＬ権限を有するユーザは、この権限をデフォルトで有する。例えば、テーブルＴに対する行レベルのセキュリティチェックからユーザ１を免除するには、以下のステートメントを利用することができる。
GRANT ExemptRowSec ON T TO<user1>
このステートメントが発行されると、テーブルＴに対するユーザ１のクエリにはどんな述語も増補されない。この権限はテーブルレベルでのみ許可することができ、列レベルでは許可されない。

述語には、やはり述語が定義されている可能性のある他のテーブルを呼び出す関数への呼出しを含むことがあり得るので、循環ループがあるかもしれないケースをトラップすることが重要である。例えば、本質的に関数Ｆへの呼出しである述語がテーブルＴに対して定義されており、関数ＦはテーブルＴおよびテーブルＳに照会する場合、述語はテーブルＳには適用できるが、テーブルＴには適用できない（というのは、そうでなければ後者は無限ループを引き起こすからである）。したがって、このような循環述語のケースをトラップするが、ただしこれは、循環中のホップの数がｎ未満のときだけであって、ｎはビューの循環依存をトラップするのに使用されるのと同じ数である。監査トレイルでは、特権を与えられたユーザは増補済みクエリを見ることができる。

以下に例示的なＳＱＬＣＲＥＡＴＥＴＡＢＬＥおよびＡＬＴＥＲＴＡＢＬＥユーティリティを示す。

ＣＲＥＡＴＥＴＡＢＬＥ
構文：

ＡＬＴＥＲＴＡＢＬＥ
構文：

表１および以下の実施例を利用して、本発明の様々な例示的態様を示す。

この実施例の目的は、以下の制限を伴った、Ｏｒｄｅｒｓテーブルに対するＧＲＡＮＴＳＥＬＥＣＴである。すなわち、ＦｒａｎｃｅＭｇｒロールのメンバであるユーザはその国の注文しか見ることができず、ＳｐａｉｎＭｇｒロールのメンバであるユーザはその国の注文しか見ることができず、Ｄｉｒｅｃｔｏｒロールのメンバであるユーザはすべての行を見ることができる。

表１に対する行レベルのセキュリティは、ＡＬＴＥＲＴＡＢＬＥＯｒｄｅｒｓＳＥＴＲＯＷ＿ＳＥＣＵＲＩＴＹ＝ＯＮを介してイネーブルになる。権限は、それぞれＧＲＡＮＴＳＥＬＥＣＴＯＮＯｒｄｅｒｓＴＯｄｉｒｅｃｔｏｒｓ、ＧＲＡＮＴＳＥＬＥＣＴＯＮＯｒｄｅｒｓＴＯＦｒａｎｃｅＭｇｒ、ＧＲＡＮＴＳＥＬＥＣＴＯＮＯｒｄｅｒｓＴＯＳｐａｉｎＭｇｒを介して、Ｄｉｒｅｃｔｏｒ、ＦｒａｎｃｅＭｇｒ、ＳｐａｉｎＭｇｒに許可される。制限は、それぞれＣＲＥＡＴＥＥＸＰＲＥＳＳＩＯＮＳｅｅＡｌｌＯＮＯｒｄｅｒｓＡＳ１＝１、ＣＲＥＡＴＥＥＸＰＲＥＳＳＩＯＮＳｐａｉｎＦｉｌｔｅｒＯＮＯｒｄｅｒｓＡＳ（Ｏｒｄｅｒｓ．ＳｈｉｐＣｏｕｎｔｒｙ＝’Ｓｐａｉｎ’）、ＣＲＥＡＴＥＥＸＰＲＥＳＳＩＯＮＦｒａｎｃｅＦｉｌｔｅｒＯＮＯｒｄｅｒｓＡＳ（Ｏｒｄｅｒｓ．ＳｈｉｐＣｏｕｎｔｒｙ＝’Ｆｒａｎｃｅ’）を介して、Ｄｉｒｅｃｔｏｒ、ＦｒａｎｃｅＭｇｒ、ＳｐａｉｎＭｇｒに関連付けられる。述語は、ＧＲＡＮＴＳＥＬＥＣＴＯＮＯｒｄｅｒｓＴＯＤｉｒｅｃｔｏｒｓＷｈｅｒｅＳｅｅＡｌｌ、ＧＲＡＮＴＳＥＬＥＣＴＷＨＥＲＥ（ＳｐａｉｎＦｉｌｔｅｒ）ＯＮＯｒｄｅｒｓｔｏＳｐａｉｎＭｇｒｓ、ＧＲＡＮＴＳＥＬＥＣＴＷＨＥＲＥ（ＦｒａｎｃｅＦｉｌｔｅｒ）ＯＮＯｒｄｅｒｓｔｏＦｒａｎｃｅＭｇｒｓを介して、Ｏｒｄｅｒｓテーブルに対する適切なロールに関連付けられる。あるいは、ＧｒａｎｔＥｘｅｍｐｔＲｏｗＳｅｃｔｏＤｉｒｅｃｔｏｒｓを利用して、Ｄｉｒｅｃｔｏｒｓロールのメンバを行レベルの述語のどんな増補からも免除することができ、したがって、Ｄｉｒｅｃｔｏｒｓロールのメンバがテーブルに照会しても、クエリにはどんな述語も増補されない。

述語を照会することができ、テーブルには述語Ｄｉｒｅｃｔｏｒｓ、ＳｐａｉｎＦｉｌｔｅｒ、ＦｒａｎｃｅＦｉｌｔｅｒが関連付けられる。照会時、これらの述語でクエリを増補することができ、それにより、ＳＥＬＥＣＴ＊ＦＲＯＭＯｒｄｅｒｓによって定義された元のクエリは増補されてＳＥＬＥＣＴ＊ＦＲＯＭＯｒｄｅｒｓＷＨＥＲＥ（（ＩＳ＿ＭＥＭＢＥＲ（’Ｄｉｒｅｃｔｏｒｓ’）＝１ＡＮＤ１＝１）ＯＲ（ＩＳ＿ＭＥＭＢＥＲ（’ＳｐａｉｎＭｇｒｓ’）＝１ＡＮＤＯｒｄｅｒｓ．Ｓｈｉｐｃｏｕｎｔｒｙ＝’Ｓｐａｉｎ’）ＯＲ（ＩＳ＿ＭＥＭＢＥＲ（’ＦｒａｎｃｅＭｇｒｓ’）＝１ＡＮＤＯｒｄｅｒｓ．Ｓｈｉｐｃｏｕｎｔｒｙ＝’Ｆｒａｎｃｅ’））になる。

この増補済みクエリは、必要とされるセキュリティ制限をもたらすことになる。したがってこの場合、Ｄｉｒｅｃｔｏｒｓ、ＦｒａｎｃｅＭｇｒｓ、またはＳｐａｉｎＭｇｒｓロールのメンバが以下のクエリを実施した場合、このメンバは、２００２年１月１日よりも後に出された注文であって、配送国がそれぞれフランスとスペインのいずれかの国である注文だけを得ることになる。
元のクエリ
SELECT*FROM ORDERS
WHERE OrderDate>'1/1/02
増補済みクエリ
SELECT*FROM ORDERS
WHERE OrderDate>'1/1/02'
AND
(
(IS_MEMBER('Director')=1 AND 1=1)
OR
(IS MEMBER('SpainMgrs')=1 AND Orders.Shipcountry='Spain')
OR
(IS_MEMBER('FranceMgrs')=1 AND Orders.Shipcountry='France')
)

本発明の様々な態様を実施するための追加のコンテキストを提供するために、図１０〜１１および以下の考察で、本発明の様々な態様を実施するのに適したコンピューティング環境に関する簡単で一般的な記述を提供する。ローカルコンピュータおよび／またはリモートコンピュータ上で稼動するコンピュータプログラムのコンピュータ実行可能命令の一般的なコンテキストで本発明を上に述べてきたが、本発明はその他のプログラムモジュールと共に実施することもできることは、当業者なら理解するであろう。一般にプログラムモジュールは、特定のタスクを実施する、かつ／または特定の抽象データ型を実装する、ルーチン、プログラム、コンポーネント、データ構造などを含む。

さらに、本発明の方法はその他のコンピュータシステム構成でも実施できることは、当業者なら理解するであろう。その他のコンピュータシステム構成としては、それぞれ１つまたは複数の関連デバイスと動作可能に通信することのできる、シングルプロセッサまたはマルチプロセッサのコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースのおよび／またはプログラム可能な消費者電子機器などが含まれる。本発明の例示の態様はまた、通信ネットワークを介してリンクされたリモート処理デバイスによっていくつかのタスクが実施される分散コンピューティング環境で実施することもできる。しかし、本発明のすべてとは言わないまでもいくつかの態様は、スタンドアロンコンピュータ上で実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルおよび／またはリモートのメモリ記憶デバイスに位置することができる。

図１０は、本発明が対話することのできる例示的なコンピューティング環境１０００の概略ブロック図である。システム１０００は、１つまたは複数のクライアント１０１０を含む。クライアント１０１０は、ハードウェアおよび／またはソフトウェア（例えばスレッド、プロセス、コンピューティングデバイス）とすることができる。システム１０００は、１つまたは複数のサーバ１０２０も含む。サーバ１０２０は、ハードウェアおよび／またはソフトウェア（例えばスレッド、プロセス、コンピューティングデバイス）とすることができる。サーバ１０２０は、例えば、本発明を利用して変換を実施するためのスレッドを格納することができる。

クライアント１０１０とサーバ１０２０との間における可能な通信の１つは、複数のコンピュータプロセス間で伝送されるように適合されたデータパケットの形とすることができる。システム１０００は、クライアント１０１０とサーバ１０２０との間の通信を容易にするのに利用できる通信フレームワーク１０４０を含む。クライアント１０１０は、クライアント１０１０にとってローカルな情報を記憶するのに利用できる１つまたは複数のクライアントデータストア１０５０に動作可能に接続される。同様に、サーバ１０２０は、サーバ１０２０にとってローカルな情報を記憶するのに利用できる１つまたは複数のサーバデータストア１０３０に動作可能に接続される。

図１１を参照すると、本発明の様々な態様を実施するための例示的な環境１１００は、コンピュータ１１１２を含む。コンピュータ１１１２は、処理ユニット１１１４、システムメモリ１１１６、システムバス１１１８を備える。システムバス１１１８は、限定しないがシステムメモリ１１１６を含めたシステムコンポーネントを、処理ユニット１１１４に結合する。処理ユニット１１１４は、様々な利用可能なプロセッサのいずれかとすることができる。デュアルマイクロプロセッサおよびその他のマルチプロセッサアーキテクチャを処理ユニット１１１４として採用することもできる。

システムバス１１１８は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、周辺バスまたは外部バス、および／あるいはローカルバスを含めて、いくつかのタイプのバス構造のいずれかとすることができる。限定しないがこのようなバスアーキテクチャには、ＩＳＡ（ＩｎｄｕｓｔｒｉａｌＳｔａｎｄａｒｄＡｒｃｈｉｔｅｃｔｕｒｅ）、ＭＣＡ（Ｍｉｃｒｏ−ＣｈａｎｎｅｌＡｒｃｈｉｔｅｃｔｕｒｅ）、ＥＩＳＡ（ＥｘｔｅｎｄｅｄＩＳＡ）、ＩＤＥ（ＩｎｔｅｌｌｉｇｅｎｔＤｒｉｖｅＥｌｅｃｔｒｏｎｉｃｓ）、ＶＬＢ（ＶＥＳＡＬｏｃａｌＢｕｓ）、ＰＣＩ（ＰｅｒｉｐｈｅｒａｌＣｏｍｐｏｎｅｎｔＩｎｔｅｒｃｏｎｎｅｃｔ）、ＣａｒｄＢｕｓ、ＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）、ＡＧＰ（ＡｄｖａｎｃｅｄＧｒａｐｈｉｃｓＰｏｒｔ）、ＰＣＭＣＩＡ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒＭｅｍｏｒｙＣａｒｄＩｎｔｅｒｎａｔｉｏｎａｌＡｓｓｏｃｉａｔｉｏｎ）バス、Ｆｉｒｅｗｉｒｅ（ＩＥＥＥ１３９４）、ＳＣＳＩ（ＳｍａｌｌＣｏｍｐｕｔｅｒＳｙｓｔｅｍｓＩｎｔｅｒｆａｃｅ）が含まれる。

システムメモリ１１１６は、揮発性メモリ１１２０および不揮発性メモリ１１２２を含む。不揮発性メモリ１１２２には、起動中などにコンピュータ１１１２内の要素間で情報を転送するための基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃｉｎｐｕｔ／ｏｕｔｐｕｔｓｙｓｔｅｍ）が記憶されている。限定ではなく例示として、不揮発性メモリ１１２２には、読取り専用メモリ（ＲＯＭ）、プログラム可能ＲＯＭ（ＰＲＯＭ）、電気的プログラム可能ＲＯＭ（ＥＰＲＯＭ）、電気的消去可能ＲＯＭ（ＥＥＰＲＯＭ）、またはフラッシュメモリを含めることができる。揮発性メモリ１１２０にはランダムアクセスメモリ（ＲＡＭ）が含まれ、これは外部キャッシュメモリとして働く。限定ではなく例示として、ＲＡＭは、同期ＲＡＭ（ＳＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、同期ＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（ＤＤＲＳＤＲＡＭ）、エンハンスドＳＤＲＡＭ（ＥＳＤＲＡＭ）、ＳｙｎｃｈｌｉｎｋＤＲＡＭ（ＳＬＤＲＡＭ）、ダイレクトＲａｍｂｕｓＲＡＭ（ＤＲＲＡＭ）など、多くの形で入手可能である。

コンピュータ１１１２は、取外し可能／固定式、揮発性／不揮発性コンピュータ記憶媒体も備える。図１１には、例としてディスク記憶装置１１２４を示す。ディスク記憶装置１１２４には、限定しないが磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、メモリスティックなどのデバイスが含まれる。加えて、ディスク記憶装置１１２４には、限定しないがコンパクトディスクＲＯＭデバイス（ＣＤ−ＲＯＭ）、ＣＤ記録可能ドライブ（ＣＤ−Ｒドライブ）、ＣＤ書換え可能ドライブ（ＣＤ−ＲＷドライブ）、ディジタル多用途ディスクＲＯＭドライブ（ＤＶＤ−ＲＯＭ）などの光ディスクドライブを含めて、他の記憶媒体と別々または一緒の記憶媒体を含めることもできる。ディスク記憶デバイス１１２４をシステムバス１１１８に接続するのを容易にするために、通常はインタフェース１１２６などの取外し可能または固定式インタフェースが使用される。

図１１には、ユーザと、適した動作環境１１００で述べた基本的なコンピュータリソースとの間の媒介として働くソフトウェアも記述されていることを理解されたい。このようなソフトウェアには、オペレーティングシステム１１２８が含まれる。オペレーティングシステム１１２８は、ディスク記憶装置１１２４に記憶されているものとすることができ、コンピュータシステム１１１２のリソースを制御および割振りする働きをする。システムアプリケーション１１３０が、システムメモリ１１１６とディスク記憶装置１１２４のいずれかに記憶されたプログラムモジュール１１３２およびプログラムデータ１１３４を介して、オペレーティングシステム１１２８によるリソース管理を利用する。本発明は、様々なオペレーティングシステム、またはオペレーティングシステムの組合せを使用して実施できることを理解されたい。

ユーザは、入力デバイス１１３６を介してコンピュータ１１１２にコマンドまたは情報を入力する。入力デバイス１１３６には、限定しないが、マウスなどのポインティングデバイス、トラックボール、スタイラス、タッチパッド、キーボード、マイクロホン、ジョイスティック、ゲームパッド、衛星受信アンテナ、スキャナ、ＴＶチューナカード、ディジタルカメラ、ディジタルビデオカメラ、ウェブカメラなどが含まれる。これらおよび他の入力デバイスは、インタフェースポート１１３８を介してシステムバス１１１８を通り処理ユニット１１１４に接続する。インタフェースポート１１３８には、例えばシリアルポート、パラレルポート、ゲームポート、ユニバーサルシリアルバス（「ＵＳＢ」）が含まれる。出力デバイス１１４０は、入力デバイス１１３６と同じタイプのポートのいくつかを使用する。したがって例えば、ＵＳＢポートは、コンピュータ１１１２への入力を提供するのにも使用することができ、コンピュータ１１１２から出力デバイス１１４０に情報を出力するのにも使用することができる。出力デバイス１１４０の中でもとりわけ、モニタ、スピーカ、プリンタなど、特別なアダプタを必要とするいくつかの出力デバイス１１４０があることを例示するために、出力アダプタ１１４２が提供されている。出力アダプタ１１４２には、限定ではなく例示として、出力デバイス１１４０とシステムバス１１１８との間の接続手段を提供するビデオカードおよびサウンドカードが含まれる。リモートコンピュータ１１４４など、その他のデバイス、および／またはデバイスのシステムも、入力と出力の両方の機能を提供することに留意されたい。

コンピュータ１１１２は、リモートコンピュータ１１４４など１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ１１４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの機器、ピアデバイス、またはその他の一般的なネットワークノードなどとすることができ、通常はコンピュータ１１１２に関して述べた要素の多くまたはすべてを備える。簡単にするために、メモリ記憶デバイス１１４６だけがリモートコンピュータ１１４４と共に示されている。リモートコンピュータ１１４４は、ネットワークインタフェース１１４８を介してコンピュータ１１１２に論理接続され、次いで通信接続１１５０を介して物理接続される。ネットワークインタフェース１１４８は、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）などの通信ネットワークを含む。ＬＡＮ技術には、ファイバ分散データインタフェース（ＦＤＤＩ）、銅分散データインタフェース（ＣＤＤＩ）、イーサネット（登録商標）、トークンリングなどが含まれる。ＷＡＮ技術には、限定しないがポイントツーポイントリンク、統合ディジタルサービス通信網（ＩＳＤＮ）やその変形などの回路交換ネットワーク、パケット交換ネットワーク、ディジタル加入者線（ＤＳＬ）が含まれる。

通信接続１１５０は、ネットワークインタフェース１１４８とバス１１１８を接続するのに利用されるハードウェア／ソフトウェアを指す。通信接続１１５０は、図示をわかりやすくするためにコンピュータ１１１２の内部に示してあるが、コンピュータ１１１２の外部にあってもよい。ネットワークインタフェース１１４８への接続に必要なハードウェア／ソフトウェアには、例示にすぎないが、通常の電話グレードモデムやケーブルモデムやＤＳＬモデムを含めたモデム、ＩＳＤＮアダプタ、イーサネット（登録商標）カードなどの、内部技術および外部技術が含まれる。

以上の記述は、本発明の実施例を含む。当然、本発明を記述するために、考えられるあらゆる組合せのコンポーネントおよび方法について述べることは不可能である。しかし、本発明のその他多くの組合せおよび置換が可能であることは、当業者なら理解するであろう。したがって本発明は、添付の特許請求の趣旨および範囲に含まれるすべての改変、修正、変形を含むものとする。

特に、上述したコンポーネント、デバイス、回路、システムなどによって実施される様々な機能に関して、このようなコンポーネントについて述べるために使用した用語（「手段」への言及を含む）は、特に指示がない限り、本明細書に示した本発明の例示的な態様における機能を実施する開示した構造と構造的に等価でなくても、述べたコンポーネントの指定の機能を実施する任意のコンポーネント（例えば機能的な均等物）に対応するものとする。これに関して、本発明は、システムを含むとともに、本発明の様々な方法の動作および／またはイベントを実施するためのコンピュータ実行可能命令を有するコンピュータ可読媒体も含むことは理解されるであろう。

さらに、いくつかの実装形態のうちの１つだけに関して本発明の特定の特徴を開示したが、このような特徴は、所与のまたは特定の適用例で望まれるように、かつ有利なように、他の実装形態における他の１つまたは複数の特徴と組み合わせることもできる。

クエリをセキュリティ式で増補することによってデータアクセスセキュリティを容易にするシステムを示す図である。セキュリティ増補されたクエリを性能のために最適化するデータセキュリティシステムを示す図である。データ管理者によって式バンクに記憶されたセキュリティ式でクエリを増補するデータセキュリティシステムを示す図である。セキュリティ増補されたクエリを利用してデータベースに照会するシステムを示す図である。行レベルのデータベースセキュリティを実施する方法を示す図である。テーブル行に対する行レベルのセキュリティ権限を許可する方法を示す図である。テーブル行に対する行レベルのセキュリティ権限を拒否する方法を示す図である。テーブル行に対する行レベルのセキュリティ権限の許可および／または拒否を取り消す方法を示す図である。例示的なＳＱＬクエリ管理システムを示す図である。本発明の新規な態様を採用することのできる例示的なネットワーキング環境を示す図である。本発明の新規な態様を採用することのできる例示的な動作環境を示す図である。

符号の説明

１１０入力コンポーネント
１２０クエリマネージャ
１３０出力コンポーネント
２１０オプティマイザ
３１０式バンク
９１０入力コンポーネント
９２０ＳＱＬクエリマネージャ
９３０出力コンポーネント
１０１０クライアント
１０２０サーバ
１０３０サーバデータストア
１０４０通信フレームワーク
１０５０クライアントデータストア
１１１４処理ユニット
１１１６システムメモリ
１１１８バス
１１２０揮発性
１１２２不揮発性
１１２４ディスク記憶装置
１１２６インタフェース
１１２８オペレーティングシステム
１１３０アプリケーション
１１３２モジュール
１１３４データ
１１３６入力デバイス
１１３８インタフェースポート
１１４０出力デバイス
１１４２出力アダプタ
１１４４リモートコンピュータ
１１４６メモリ記憶装置
１１４８ネットワークインタフェース
１１５０通信接続

Claims

データベースセキュリティのためのシステムであって、
クエリを受け取る入力コンポーネントであって、前記クエリは、前記クエリを生成したユーザを特定するための固有の識別子を含む、入力コンポーネントと、
データベースの管理者によって定義された複数の行レベルのセキュリティ式を記憶した式バンクであって、複数の行レベルのセキュリティ式のうちの少なくとも１つは、前記単一のデータベーステーブルに記録されたデータに対するユーザアクセスを許可するためのセキュリティ式であり、複数の行レベルのセキュリティ式のうちの他の少なくとも１つは、前記ユーザアクセスを拒否するためのセキュリティ式である、式バンクと、
前記固有の識別子に関連付けられた１又は複数の行レベルのセキュリティ式を前記式バンクから取り出して、受け取ったクエリに前記関連付けられた１又は複数の行レベルのセキュリティ式を挿入することにより、増補したクエリを生成するクエリ管理コンポーネントであって、前記増補したクエリは、データを検索するために前記データベースで使用され、前記クエリ管理コンポーネントは、データを検索してデータ行を評価することにより、アクセスを許可する前記少なくとも１つの行レベルのセキュリティ式が満たされ、アクセスを拒否する前記少なくとも１つの行レベルのセキュリティ式が満たされないように、前記増補したクエリに挿入された前記行レベルのセキュリティ式の集約を少なくとも満たす前記単一のデータベーステーブルのデータ行を返す、クエリ管理コンポーネントと、
セキュリティ式および非セキュリティ式がクエリに挿入される順序を定義した述語規則を利用して、データ行を評価する際に、前記非セキュリティ式の評価を実行する前に前記行レベルのセキュリティ式の評価を実行するように、前記クエリにおける行レベルセキュリティ式と非セキュリティ式とを順序付けるオプティマイザと
を備えることを特徴とするシステム。
前記クエリは、
満たされるときに行アクセスを許可するブール式の離接と、
満たされるときに行アクセスを拒否するブール式それぞれの補集合の合接と
の合接からなる式を挿入することによって増補されることを特徴とする請求項１に記載のシステム。
前記行レベルのセキュリティ式は、セキュリティ式と非セキュリティ式を区別するために特別にタグ付けされることを特徴とする請求項１に記載のシステム。
コンパイル時に静的分析を実施して、前記クエリ中の非セキュリティ式が安全な式かどうかを判定するコンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
安全な式は、セキュリティ違反による情報開示のリスクなしに実行される式であることを特徴とする請求項４に記載のシステム。
実行時に動的分析を実施して、非セキュリティ式が安全な式かどうかを判定するコンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
前記動的分析は、すべてのセキュリティ式がうまく実行された場合にデータを返すことを特徴とする請求項６に記載のシステム。
安全違反を検出し、前記クエリをアボートするか、または前記クエリをセーフモードで再開始するコンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
前記セーフモードは、非セキュリティ式が利用される前にセキュリティ式がデータ行の評価に利用されるようにすることを特徴とする請求項８に記載のシステム。
前記セキュリティ式はブール式であることを特徴とする請求項１に記載のシステム。
データの行に対して１つまたは複数のセキュリティ式が前記データの管理者によってＳＱＬステートメントを介して作成されることを特徴とする請求項１に記載のシステム。
データの行のセットに対する１つまたは複数のセキュリティ式が前記データの管理者によって１つまたは複数のクエリ開始元に関連付けられることを特徴とする請求項１に記載のシステム。
行レベルのデータベースセキュリティを利用する方法であって、
入力コンポーネントが、クエリを受け取るステップであって、前記クエリは、前記クエリを生成したユーザを特定するための固有の識別子を含む、ステップと、
クエリマネージャが、前記固有の識別子に関連付けられた１又は複数の行レベルのセキュリティ式を式バンクから取り出すステップであって、前記式バンクは、データベースの管理者によって定義された複数の行レベルのセキュリティ式を記憶し、複数の行レベルのセキュリティ式のうちの少なくとも１つは、前記単一のデータベーステーブルに記録されたデータに対するユーザアクセスを許可するためのセキュリティ式であり、複数の行レベルのセキュリティ式のうちの他の少なくとも１つは、前記ユーザアクセスを拒否するためのセキュリティ式である、ステップと、
前記クエリマネージャが、受け取ったクエリに前記関連付けられた１又は複数の行レベルのセキュリティ式を挿入することにより、増補したクエリを生成するステップであって、前記増補したクエリは、データを検索するために前記データベースで使用される、ステップと、
前記クエリマネージャが、前記増補したクエリを使用して、データを検索してデータ行を評価することにより、アクセスを許可する前記少なくとも１つの行レベルのセキュリティ式が満たされ、アクセスを拒否する前記少なくとも１つの行レベルのセキュリティ式が満たされないように、前記増補したクエリに挿入された前記行レベルのセキュリティ式の集約を少なくとも満たす前記単一のデータベーステーブルのデータ行を返すステップと、
オプティマイザが、セキュリティ式および非セキュリティ式がクエリに挿入される順序を定義した述語規則を利用して、データ行を評価する際に、前記非セキュリティ式の評価を実行する前に前記行レベルのセキュリティ式の評価を実行するように、前記クエリにおける行レベルセキュリティ式と非セキュリティ式とを順序付けるステップと
を含むことを特徴とする方法。
前記クエリマネージャが、満たされるときに行アクセスを許可するブール式の離接と、満たされるときに行アクセスを拒否するブール式それぞれの補集合の合接との合接からなる式を接合し、前記接合した式を前記クエリに挿入するステップをさらに含むことを特徴とする請求項１３に記載の方法。
前記クエリマネージャが、安全でない非セキュリティ式を前記クエリが含まないとき、前記１つまたは複数の行レベルのセキュリティ式を前記クエリに挿入するステップをさらに含むことを特徴とする請求項１３に記載の方法。
前記オプティマイザが、静的分析を実施して、非セキュリティ式が安全でないかどうかを判定するステップをさらに含むことを特徴とする請求項１３に記載の方法。
前記オプティマイザが、動的分析を実施して、非セキュリティ式が安全でないかどうかを判定するステップをさらに含むことを特徴とする請求項１３に記載の方法。
前記オプティマイザが、安全違反が検出されたときは前記クエリをセーフモードで再開始するステップをさらに含み、セーフモードは、セキュリティ式が非セキュリティ式よりも前に行データの評価に利用されるようにすることを特徴とする請求項１３に記載の方法。