(57)【要約】  保護されたデータリソースへのユーザアクセスを制御するための、コンピュータによって実現される方法は、保護されるべきデータリソースの一覧表を作成するステップを含む。その後、一覧表が作成されたデータリソースの各々にマッピングされる１つの要素を含む要求データ構造を生成することができ、各要素は、マッピングされるデータリソースにアクセスするために必要な許可レベルに従って設定される要求値を格納するよう構成される。各ユーザが、一覧表が作成されたデータリソースのいずれかにアクセスできるようにするために、複数のデータリソースの各々にマッピングされる１つの要素を含む権限付与データ構造を定義でき、各要素は、マッピングされるデータリソースにアクセスするためにユーザに付与される許可に従って設定される付与値を格納するよう構成される。保護されたデータリソースのうち少なくとも１つへのユーザのアクセス要求が受取られると、権限付与データ構造と要求データ構造とを比較するためにステップが実行され得る。次いで、要求値が権限付与データ構造の対応する要素の付与値よりも大きい要求データ構造の任意の要素にマッピングされる任意の保護されたデータリソースへのアクセスを、受取られたユーザ要求によって認めないことが可能である。比較するステップによって、権限付与および要求データ構造は、ユーザ要求がアクセスを要求する一覧表が作成されたデータリソースにマッピングされる要素のみを含むように切捨てられることができる。
2008546114.tif 000002
【特許請求の範囲】
【請求項１】
データリソースへのユーザアクセスを制御するための、コンピュータによって実現される方法であって、
保護されるべき前記データリソースの一覧表を作成するステップと、
前記一覧表が作成されたデータリソースの各々にマッピングされる１つの要素を含む要求データ構造を生成するステップとを備え、各要素は、マッピングされるデータリソースにアクセスするために必要な許可レベルに従って設定される要求値を格納するよう構成されており、前記方法はさらに、
各ユーザが、前記一覧表が作成されたデータリソースのいずれかにアクセスできるようにするために、複数のデータリソースの各々にマッピングされる１つの要素を含む権限付与データ構造を定義および格納するステップを備え、各要素は、マッピングされるデータリソースにアクセスするために前記ユーザに付与される許可に従って設定される付与値を格納するよう構成されており、前記方法はさらに、
前記保護されたデータリソースのうち少なくとも１つへのユーザのアクセス要求を受取るステップと、
前記権限付与データ構造と要求データ構造とを比較し、要求値が前記権限付与データ構造の対応する要素の前記付与値よりも大きい前記要求データ構造の任意の要素にマッピングされる任意の保護されたデータリソースへのアクセスを前記受取られたユーザ要求によって認めないステップとを備える、方法。
【請求項２】
前記比較するステップは、ユーザ要求がアクセスを要求する一覧表が作成されたデータリソースにマッピングされる要素のみを含むように前記権限付与および要求データ構造を切捨てるステップを含む、請求項１に記載のコンピュータによって実現される方法。
【請求項３】
要求値が前記権限付与データ構造の対応する要素の前記付与値未満であるかまたは前記付与値と等しい前記要求データ構造の任意の要素にマッピングされる任意の保護されたデータリソースへのアクセスを前記受取られたユーザ要求によって認めるステップをさらに含む、請求項１に記載のコンピュータによって実現される方法。
【請求項４】
前記受取るステップは、データベースクエリーを含むユーザ要求で実行される、請求項１に記載のコンピュータによって実現される方法。
【請求項５】
前記アクセスを認めないステップは、前記データベースクエリーのコンパイルおよび実行を認めないステップを含む、請求項４に記載のコンピュータによって実現される方法。
【請求項６】
前記受取るステップは、ＳＱＬクエリーを含むユーザ要求で実行される、請求項１に記載のコンピュータによって実現される方法。
【請求項７】
前記定義および生成するステップは、ユーザを固有に識別する値を格納するよう構成されるユーザ識別フィールドを含む前記権限付与および要求データ構造で実行される、請求項１に記載のコンピュータによって実現される方法。
【請求項８】
前記比較するステップは、値が、前記生成される要求データ構造におけるユーザ識別フィールドの値と一致する前記ユーザ識別フィールドを含む権限付与データ構造を検索するステップを含む、請求項７に記載のコンピュータによって実現される方法。
【請求項９】
前記比較するステップは、権限付与データ構造の要素の値によって集合的に形成される付与二進数が要求データ構造の要素の値によって集合的に形成される要求二進数よりも大きくない限り、前記受取られたユーザ要求の実行を認めないステップを含む、請求項１に
記載のコンピュータによって実現される方法。
【請求項１０】
前記要求データ構造のどの要素が前記権限付与データ構造の対応する要素未満である値を有するかを判断するステップをさらに含む、請求項９に記載のコンピュータによって実現される方法。
【請求項１１】
前記判断するステップは、前記要求データ構造の要素の値および前記権限付与データ構造の対応する要素の値に基づいてＸＯＲ演算を実行するステップを含む、請求項１０に記載のコンピュータによって実現される方法。
【請求項１２】
任意のデータ構造への認められないアクセスの各インスタンスをログするためのロギングステップをさらに含む、請求項１に記載のコンピュータによって実現される方法。
【請求項１３】
前記保護されたデータリソースへのアクセスが認められないときにより大きな許可を要求するためのメッセージを生成するステップをさらに含む、請求項１に記載のコンピュータによって実現される方法。
【請求項１４】
より大きな許可を要求するための前記メッセージが、選択された要素に対してより大きな権限が付与された状態で応答されるときに、前記権限付与データ構造における前記選択された要素の値をアップデートするステップをさらに含む、請求項１３に記載のコンピュータによって実現される方法。
【請求項１５】
前記保護されたデータリソースは、データ構造およびアプリケーションのうち少なくとも１つを含む、請求項１に記載のコンピュータによって実現される方法。
【請求項１６】
前記定義および格納するステップは、ディレクトリ・サービス・マークアップ言語（Directory Services Markup Language）（ＤＳＭＬ）の形態で前記権限付与データ構造を表わすことによっておよびユーザデータとして前記権限付与データ構造を前記ユーザのデジタル証明書に入力することによって実行される、請求項１に記載のコンピュータによって実現される方法。
【請求項１７】
ユーザアクセスが制御されるべき複数の保護されたデータリソースを格納するデータベースを含むコンピュータシステムであって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサによって生成される複数のプロセスとを備え、前記プロセスは、
保護されるべきデータリソースの一覧表を作成するための処理論理と、
前記一覧表が作成されたデータリソースの各々にマッピングされる１つの要素を含む要求データ構造を生成するための処理論理とを含み、各要素は、マッピングされるデータリソースにアクセスするために必要な許可レベルに従って設定される要求値を格納するよう構成されており、前記プロセスはさらに、
各ユーザが、前記一覧表が作成されたデータリソースのいずれかにアクセスできるようにするために、複数のデータリソースの各々にマッピングされる１つの要素を含む権限付与データ構造を定義および格納するための処理論理を含み、各要素は、マッピングされるデータリソースにアクセスするために前記ユーザに付与される許可に従って設定される付与値を格納するよう構成されており、前記プロセスはさらに、
前記保護されたデータリソースのうち少なくとも１つへのユーザのアクセス要求を受取るための処理論理と、
前記権限付与データ構造と要求データ構造とを比較し、要求値が前記権限付与データ構造の対応する要素の前記付与値よりも大きい前記要求データ構造の任意の要素にマッピン
グされる任意の保護されたデータリソースへのアクセスを前記受取られたユーザ要求によって認めないための処理論理とを含む、コンピュータシステム。
【請求項１８】
前記比較するステップは、ユーザ要求がアクセスを要求する一覧表が作成されたデータリソースにマッピングされる要素のみを含むように前記権限付与および要求データ構造を切捨てるステップを含む、請求項１７に記載のコンピュータシステム。
【請求項１９】
機械読み取り可能な媒体であって、その上に命令のシーケンスを表わすデータを格納しており、前記命令のシーケンスは計算装置によって実行されると、前記計算装置に対して複数のステップを実行することにより複数の保護されたデータリソースへのユーザアクセスを制御させ、
前記複数のステップは、
保護されるべきデータリソースの一覧表を作成するステップと、
前記一覧表が作成されたデータリソースの各々にマッピングされる１つの要素を含む要求データ構造を生成するステップとを含み、各要素は、マッピングされるデータリソースにアクセスするために必要な許可レベルに従って設定される要求値を格納するよう構成されており、前記複数のステップはさらに、
各ユーザが、前記一覧表が作成されたデータリソースのいずれかにアクセスできるようにするために、複数のデータリソースの各々にマッピングされる１つの要素を含む権限付与データ構造を定義および格納するステップを含み、各要素は、マッピングされるデータリソースにアクセスするために前記ユーザに付与される許可に従って設定される付与値を格納するよう構成されており、前記複数のステップはさらに、
前記保護されたデータリソースのうち少なくとも１つへのユーザのアクセス要求を受取るステップと、
前記権限付与データ構造と要求データ構造とを比較し、要求値が前記権限付与データ構造の対応する要素の前記付与値よりも大きい前記要求データ構造の任意の要素にマッピングされる任意の保護されたデータリソースへのアクセスを前記受取られたユーザ要求によって認めないステップとを含む、機械読み取り可能な媒体。
【請求項２０】
企業のデータリソースへのユーザアクセスを制御するための、コンピュータによって実現される方法であって、
保護されるべきデータリソースの一覧表を作成するステップと、
一覧表が作成されたデータリソースごとに、前記データリソースにアクセスするために必要な許可レベルを定義する要求値を割当てるステップと、
一覧表が作成されたデータリソースごとの前記要求値を要求データ構造に格納するステップと、
各ユーザが、前記一覧表が作成されたデータリソースのいずれかにアクセスできるようにするために、前記一覧表が作成されたデータリソースの各々の付与値を含む権限付与データ構造を定義するステップとを備え、各付与値は、対応する保護されたデータリソースへのアクセスを前記ユーザが認められるかどうかを規定しており、前記方法はさらに、
前記一覧表が作成されたデータリソースのうちの１つへのアクセス要求がユーザから受取られると、前記要求データ構造を前記ユーザの権限付与データ構造と比較し、アクセスが要求される前記データリソースの前記付与値が少なくとも対応する要求値と同じぐらい大きいときにのみ前記アクセス要求の実行を認めるステップを備える、コンピュータによって実現される方法。
【請求項２１】
選択されたユーザが、委任された権限付与データ構造を定義し、委任された権限付与データ構造を前記企業の中の階層的に下位のユーザに割当てることを可能にするステップをさらに含み、前記定義されかつ割当てられる、委任された権限付与データ構造は、前記委任された権限付与データ構造を定義しかつ割当てた前記ユーザの前記権限付与データ構造
の付与値よりも大きくない付与値を格納する、請求項２０に記載のコンピュータによって実現される方法。
【請求項２２】
前記可能にするステップは、各ユーザの権限付与データ構造の各付与値が、階層的により高いユーザに割当てられる権限付与データ構造の対応する付与値よりも大きくないように実行される、請求項２１に記載のコンピュータによって実現される方法。
【請求項２３】
選択されたデータリソースにアクセスするために許可レベルを上げるユーザの要求を付与し、対応して、前記要求を行なった前記ユーザの前記権限付与データ構造における前記選択されたデータリソースの付与値を上げるステップをさらに含む、請求項２０に記載のコンピュータによって実現される方法。
【請求項２４】
前記ユーザが前記企業を去ったときにユーザの権限付与データ構造を取消すステップをさらに含む、請求項２０に記載のコンピュータによって実現される方法。
【請求項２５】
最初はデフォルトで、ユーザごとの権限付与データ構造の付与値を、可能な限り低い許可レベルを示す最低値にするステップをさらに含む、請求項２０に記載のコンピュータによって実現される方法。
【請求項２６】
ユーザごとの権限付与データ構造の付与値を、前記企業におけるユーザの地位の新しい状態を示しかつ新しい状態に適切な値にリセットするステップをさらに含む、請求項２０に記載のコンピュータによって実現される方法。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の背景
発明の分野
この発明は、ユーザの許可レベルにわたって企業データ、アプリケーションおよび他のオブジェクトに対するアクセス権および許可権を制御するための、コンピュータによって実現される方法ならびにシステムに関する。
【背景技術】
【０００２】
関連技術の説明
多くの場合、企業データおよび／または他の電子リソース（すべての下位区分を含む、多様な特権およびアクセス権を有するデータならびにプログラム）にアクセスするユーザの権利の制御は、ユーザ認証（その人またはメカニズムが確実に想定される人またはものであるようにするためにユーザのアイデンティティを確認すること）に全面的に依存している。パスワード、スマートカード、証明書、および網膜走査または音声認識などのバイオメトリック測定さえ含む認証を保護する手段がいくつか存在する。これらのうち、証明書およびデジタル署名、スマートカードならびにバイオメトリクスの使用は「強い」レベルのセキュリティと称される一方で、通常のパスワードによって保護されるアクセスについては典型的な金融機関およびセキュリティの専門家は「弱い」と考えている。現在の認証プロトコルは堅固なものであり、ほとんどまたは全く曖昧さの余地がないが、認証だけでは、このようなリソースに対して個人が有し得る権利を規定および行使するのに十分ではない。その一方で、アプリケーションが頻繁に互いに矛盾することを防ぐことができるだけ十分に、またはアプリケーションが所与のデータまたは他のプログラムリソースの会社のセキュリティプロトコルに対する所与のユーザの認証について食い違うことを防ぐことができるだけ十分に認証は処理されない。
【０００３】
その上、ユーザの許可レベルは静的ではない。しばしば、このような許可レベルは、昇進、降格、停職もしくは解雇の結果、または特定のプロジェクトに取組んでいる間の従業員の「必知事項」の結果、変化する。認証および許可は、支払いの許可または会社を拘束するように作用する契約の締結という文脈の中で重要であるばかりでない。実際、データ、プログラムおよび他の電子リソースへのより日常的な日々のアクセスは、会社内でのユーザの役割および階層的地位に従うべきである。すなわち、会社はしばしば、選択されたデータリソースへのアクセスを、予め定められたユーザまたは予め定められたユーザのクラスに制限したいと考える。たとえば、割当てられた製品ラインまたはクライアントに関するデータにアクセスする正当な必要性を有し得るユーザは、自分の責任の範囲外の製品ラインおよび／または顧客に関するデータにアクセスするこのような正当な必要性を持ち得ない。さらに、特定のデータリソースにアクセスする正当な必要性を有し得る、適切に認証されたユーザでさえ、データを見ることにだけは正当な関心を持ち得るが、新しいデータの入力または既存のデータの変更には相応の正当な関心を持ち得ない。最後に、個々のユーザは、会社での在職期間が長くても短くても、異なる許可レベルを必要とするように会社のセキュリティプロトコルを導くであろう特性を有する可能性がある。この非常に重要な例はセキュリティクリアランスであり、これは他の許可要素の値から類推できない。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
したがって、必要なものは、強い許可を保証するための方法およびシステムである。特
に、必要なものは、会社のセキュリティプロトコルに従って、このような電子リソースにアクセスしようとする人が実際にこのようなアクションを始める権限およびこのようなリソースにアクセスする権限を確実に与えられるようにするための、およびこのようなアクセスが確実に適切なものであるようにするための方法およびシステムである。さらに必要なものは、分散したネットワークコンピューティング環境において作動可能な強くかつ定量化できる許可のための方法およびシステムである。
【課題を解決するための手段】
【０００５】
発明の概要
この発明の実施例に従うと、この発明は、保護されたデータリソースへのアクセスを制御するための、コンピュータによって実現される方法である。この方法は、保護されるべきデータリソースの一覧表（inventory）を作成するステップと、一覧表が作成されたデータリソースの各々にマッピングされる１つの要素を含む要求データ構造を生成するステップとを含むことができ、各要素はマッピングされるデータリソースにアクセスするために必要な許可レベルに従って設定される要求値を格納するよう構成されており、上記方法はさらに、各ユーザが、一覧表が作成されたデータリソースのいずれかにアクセスできるようにするために、複数のデータリソースの各々にマッピングされる１つの要素を含む権限付与データ構造を定義および格納するステップを含むことができ、各要素は、マッピングされるデータリソースにアクセスするためにユーザに付与される許可に従って設定される付与値を格納するよう構成されており、上記方法はさらに、保護されたデータリソースのうち少なくとも１つへのユーザのアクセス要求を受取るステップと、権限付与データ構造と要求データ構造とを比較し、要求値が権限付与データ構造の対応する要素の付与値よりも大きい要求データ構造の任意の要素にマッピングされる任意の保護されたデータリソースへのアクセスを、受取られたユーザ要求によって認めないステップとを含む。
【０００６】
比較するステップは、ユーザ要求がアクセスを要求する一覧表が作成されたデータリソースにマッピングされる要素のみを含むように権限付与および要求データ構造を切捨てるステップを含み得る。この方法は、要求値が権限付与データ構造の対応する要素の付与値未満であるかまたは付与値と等しい要求データ構造の任意の要素にマッピングされる任意の保護されたデータリソースへのアクセスを、受取られたユーザ要求によって認めるステップを含み得る。受取るステップは、データベースクエリーを含むユーザ要求で実行されることができる。アクセスを認めないステップは、データベースクエリーのコンパイルおよび実行を認めないステップを含み得る。受取るステップは、ＳＱＬクエリーを含むユーザ要求で実行されることができる。定義および生成するステップは、ユーザを固有に識別する値を格納するよう構成されるユーザ識別フィールドを含む権限付与および要求データ構造で実行されることができる。比較するステップは、値が、生成される要求データ構造におけるユーザ識別フィールドの値と一致するユーザ識別フィールドを含む権限付与データ構造を検索するステップを含み得る。比較するステップは、権限付与データ構造の要素の値によって集合的に形成される付与二進数が、要求データ構造の要素の値によって集合的に形成される要求二進数よりも大きくない限り、受取られたユーザ要求の実行を認めないステップを含み得る。ステップは、要求データ構造のどの要素が権限付与データ構造の対応する要素未満である値を有するかを判断するために実行され得る。判断するステップは、要求データ構造の要素の値および権限付与データ構造の対応する要素の値に基づいてＸＯＲ演算を実行するステップを含み得る。ロギングステップは、任意のデータ構造への認められないアクセスの各インスタンスをログするためにも実行され得る。ステップは、保護されたデータリソースへのアクセスが認められないときにより大きな許可を要求するためのメッセージを生成するようにも実行され得る。上記方法は、より大きな許可を要求するためのメッセージが、選択された要素に対してより大きな権限が付与された状態で応答されるときに、権限付与データ構造における選択された要素の値をアップデートするステップも含み得る。保護されたデータリソースは、データ構造およびアプリケーションの
うち少なくとも１つを含み得る。定義および格納するステップは、ディレクトリ・サービス・マークアップ言語（Directory Services Markup Language）（ＤＳＭＬ）の形態で権限付与データ構造を表わすことによっておよびユーザデータとして権限付与データ構造をユーザのデジタル証明書に入力することによって実行され得る。
【０００７】
この発明は、その別の実施例に従うと、ユーザアクセスが制御されるべき複数の保護されたデータリソースを格納するデータベースを含むコンピュータシステムである。このコンピュータシステムは、少なくとも１つのプロセッサと、上記少なくとも１つのプロセッサによって生成される複数のプロセスとを含むことができ、上記プロセスは、保護されるべきデータリソースの一覧表を作成するための処理論理と、一覧表が作成されたデータリソースの各々にマッピングされる１つの要素を含む要求データ構造を生成するための処理論理とを含み、各要素は、マッピングされるデータリソースにアクセスするために必要な許可レベルに従って設定される要求値を格納するよう構成されており、上記プロセスはさらに、各ユーザが、一覧表が作成されたデータリソースのいずれかにアクセスできるようにするために、複数のデータリソースの各々にマッピングされる１つの要素を含む権限付与データ構造を定義および格納するための処理論理を含み、各要素は、マッピングされるデータリソースにアクセスするためにユーザに付与される許可に従って設定される付与値を格納するよう構成されており、上記プロセスはさらに、保護されたデータリソースのうち少なくとも１つへのユーザのアクセス要求を受取るための処理論理と、権限付与データ構造と要求データ構造とを比較し、要求値が権限付与データ構造の対応する要素の付与値よりも大きい要求データ構造の任意の要素にマッピングされる任意の保護されたデータリソースへのアクセスを、受取られたユーザ要求によって認めないための処理論理とを含む。
【０００８】
この発明は機械読み取り可能な媒体であるととらえることもでき、その上に命令のシーケンスを表わすデータを格納しており、上記命令のシーケンスは計算装置によって実行されると、計算装置に対して複数のステップを実行することにより複数の保護されたデータリソースへのユーザアクセスを制御させ、上記複数のステップは、保護されるべきデータリソースの一覧表を作成するステップと、一覧表が作成されたデータリソースの各々にマッピングされる１つの要素を含む要求データ構造を生成するステップとを含み、各要素は、マッピングされるデータリソースにアクセスするために必要な許可レベルに従って設定される要求値を格納するよう構成されており、上記複数のステップはさらに、各ユーザが、一覧表が作成されたデータリソースのいずれかにアクセスできるようにするために、複数のデータリソースの各々にマッピングされる１つの要素を含む権限付与データ構造を定義および格納するステップを含み、各要素は、マッピングされるデータリソースにアクセスするためにユーザに付与される許可に従って設定される付与値を格納するよう構成されており、上記複数のステップはさらに、保護されたデータリソースのうち少なくとも１つへのユーザのアクセス要求を受取るステップと、権限付与データ構造と要求データ構造とを比較し、要求値が権限付与データ構造の対応する要素の付与値よりも大きい要求データ構造の任意の要素にマッピングされる任意の保護されたデータリソースへのアクセスを、受取られたユーザ要求によって認めないステップとを含む。
【０００９】
この発明の別の実施例に従うと、この発明は、企業のデータリソースへのユーザアクセスを制御するための、コンピュータによって実現される方法である。このような方法は、保護されるべきデータリソースの一覧表を作成するステップと、一覧表が作成されたデータリソースごとに、データリソースにアクセスするために必要な許可レベルを定義する要求値を割当てるステップと、一覧表が作成されたデータリソースごとの要求値を要求データ構造に格納するステップと、各ユーザが、一覧表が作成されたデータリソースのいずれかにアクセスできるようにするために、一覧表が作成されたデータリソースの各々の付与値を含む権限付与データ構造を定義するステップとを含むことができ、各付与値は対応す
る保護されたデータリソースへのアクセスをユーザが認められるかどうかを規定しており、上記方法はさらに、一覧表が作成されたデータリソースのうちの１つへのアクセス要求がユーザから受取られると、要求データ構造をユーザの権限付与データ構造と比較し、アクセスが要求されるデータリソースの付与値が少なくとも対応する要求値と同じぐらい大きいときにのみアクセス要求の実行を認めるステップを含み得る。
【００１０】
上記方法は、選択されたユーザが、委任された権限付与データ構造を定義し、委任された権限付与データ構造を企業の中の階層的に下位のユーザに割当てることを可能にするステップも含むことができ、定義されかつ割当てられる、委任された権限付与データ構造は、委任された権限付与データ構造を定義しかつ割当てたユーザの権限付与データ構造の付与値よりも大きくない付与値を格納する。可能にするステップは、各ユーザの権限付与データ構造の各付与値が、階層的により高いユーザに割当てられる権限付与データ構造の対応する付与値よりも大きくないように実行され得る。上記方法は、選択されたデータリソースにアクセスするために許可レベルを上げるユーザの要求を付与し、対応して、要求を行なったユーザの権限付与データ構造における選択されたデータリソースの付与値を上げるステップをさらに含み得る。ユーザが企業を去ったときにユーザの権限付与データ構造を取消すステップも実行され得る。ユーザごとの権限付与データ構造の付与値は最初はデフォルトで、可能な限り低い許可レベルを示す最低値にされることができ、要素ごとの権限付与データ構造の値は、上司によって指定される事象（昇進など）または企業のセキュリティプロトコルによって示される事象において手動で、任意にまたは自動的にリセットされることができる。
【発明を実施するための最良の形態】
【００１１】
発明の説明
保護されたデータリソースへのアクセスを定義、保護および制御するための、このコンピュータによって実現される方法の実施例は、５つのモジュールを含み得る。その５つのモジュールとは、セットアップ・リソース・一覧表・モジュール（Setup Resource Inventory module）、セットアップ付与モジュール（Setup Grants module）、ＳＱＬコンパイルモジュール（SQL Compilation module）、コア機能モジュール（Core Function module）、ならびにアップグレードおよびアップデートモジュール（Upgrade and Update module）である。これらのモジュールの、以下に記載する機能性は、さまざまなデータベースをセットアップおよび実装することから、ユーザが認証され、そうするように適切に権限が与えられたかどうかに応じて、保護されたデータリソースに関するＳＱＬ（または他の構造化）クエリーまたは保護されたデータリソースへの他のアクセス要求をユーザが実行することを可能にするまたは防ぐことに及ぶ。
【００１２】
この発明の実施例に従うと、保護されたデータリソースまたはプログラムに対してユーザがアクセスまたは他の特権を拒否されると、このような拒否は、ＳＱＬクエリーの対象である保護されたデータリソースにアクセスするために不十分な権利もしくは権限またはデータリソースへの他のアクセス要求を付与されたユーザによってもたらされたものとして解釈される。この発明の実施例に従うと、ＳＱＬクエリーによってアクセスされようとした保護されたデータリソースに対して権利が不十分であるためにユーザのクエリーを実行できないと、ユーザは自分の上司にメッセージを送信する機会を与えられ得る。（たとえばｅメールまたは他の形態の電子メッセージなどの）このようなメッセージは、自動的にフォーマットされることができ、具体的な要求されるアクセス特権、アクセスが求められる保護されたデータリソースに対して現在保持されているアクセス特権のユーザの現在のレベル、およびユーザのＳＱＬクエリーを満たすために必要なアクセス特権レベルを示し得る。メッセージはさらに、保護されたデータリソースへのアクセスが試みられたことに関して、上司または組織の中の何らかの任命された（好ましくは、階層的により高い）人に警告するために、自動的におよびユーザから独立して生成され得る。この発明の実施
例に従うと、リレーショナルデータベース管理システム（relational database management system）（ＲＤＢＭ）に関してユーザが試みるアクションはすべて、ＳＱＬまたは同様の構造の命令文であると理解される。任意のプログラミング言語またはシェルスクリプト／他のスクリプトにおける命令文または機能はいずれも（たとえばオラクル・コーポレイションの）ＲＤＢＭに格納されることができ、その使用は安全に制御されることができる。
【００１３】
その後、上司が十分なアクセス特権を有する場合、上司は要求される追加のアクセス特権を委任または付与でき、ユーザは、今回は成功するであろうと期待して、クエリーを再試行する機会を与えられ得る。この発明の実施例に従うと、ユーザは、ユーザに付与される１組の特権と等しいかまたはそれに劣るアクセス特権のみを委任または付与できる。この態様で、ユーザに現在割当てられているアクセス特権よりも大きな、保護されたデータリソースのアクセス特権を付与または委任できるユーザはいない。この発明に従うと、ユーザは、示されるクエリーを実行するために必要なアクセス特権と等しいかまたはそれよりも大きなアクセス特権をユーザが有することがわかったときにのみクエリーを実行させることができる。
【００１４】
データリソースに対する制御を確立し、データリソースへのアクセスを制御するのに好適なアーキテクチャ、方法およびシステムについて以下で詳述する。本明細書において使用する「保護されたデータリソース」という語句は、アクセス、実行および（たとえば）ＳＱＬコマンドを介する他の特権について制御されるべきすべてのデータ、データベース、ファイル、プログラム、アプリケーションおよび他のアイテムを包含するように意図される。セットアップ・リソース・一覧表・モジュール、セットアップ付与モジュール、ＳＱＬコンパイルモジュール、コア機能モジュール、ならびにアップグレードおよびアップデートモジュールについて、ほぼそれらの実行順に以下で説明する。
【００１５】
セットアップ・リソース・一覧表
セットアップ・リソース・一覧表・モジュール１０２は、すべての保護されたデータリソースを登録するように、および一覧表が作成された保護されたデータリソースにアクセスするために必要なアクセス特権のレベルを格納するよう構成され得る。保護されたデータリソースの登録およびアクセス特権（または権限。２つの用語は本明細書において区別なく使用される）のそれぞれのレベルは、図１に１０４で示すように、保護されたデータリソースデータベースに格納され得る。一覧表は、一旦生成されると、フレームワークとして使用されることができ、そのフレームワークからセキュリティデータ構造（Security
Data Structure）（ＳＤＳ）が添付され得る。例示的なＳＤＳは図４に参照数字４００で示される。
【００１６】
この発明の実施例に従うと、保護されたデータリソースにアクセスすることを望む各ユーザは、たとえば６４ビットの固有の識別番号を発行されることができる。示されるように、ＳＤＳ４００は、（１）認証されたユーザのＵＳＥＲ＿ＩＤ  ４１２を保持するためのダミー要素を含み得る。このダミー要素は、ＳＤＳ４００において最下位の位置を占め得る。ＳＤＳ４００は、（２）（確保された許可を被る、保護されたデータリソースごとに１つの要素を含む）会社のセキュリティプロトコルにマッピングするために必要とされ得るのと同じぐらい多くの要素もＳＤＳ４００に含むことができ、（３）各ＳＤＳ要素に格納された値を表わすために必要とされ得るのと同じぐらい多くのビット、ニブルまたはバイトも含み得る。ＳＤＳ４００の要素４０２の各々は、要素識別子（図４に示す例ではａ〜ｎ）で識別されることができる。たとえば、ＳＤＳ４００における要素ｅにアクセスするために必要なアクセス特権は、単一のビットによって表わされ、格納されてもよい。たとえば、認証されたユーザは、要素ｅに対応する保護されたデータリソースにアクセスするのに十分なアクセス特権を有するか、またはユーザは十分なアクセス特権を持たない
かのいずれかである。したがって、要素ｅの大きさ４０６は１ビットであってもよく、これはその２つの値４０６、つまり、許可（ｅ＝１）または無許可（ｅ＝０）を表わすのに十分である。ＳＤＳ４００は、４０４において示すように、各要素の判読可能な説明も含み得る。この例では、要素の値が「０」である場合、ユーザは、要素ｅにマッピングされる保護されたデータリソースにアクセスする権限を与えられない。逆に、要素の値が「１」である場合、認証されたユーザは実際に、要素ｅにマッピングされる保護されたデータリソースにアクセスする権限を与えられる。この発明の実施例に従うと、ユーザが少なくとも要素ｅにアクセスするために必要なアクセス特権と同じぐらい大きな要素ｅについてのアクセス特権を有すると決定された場合、ユーザは要素ｅに対応する保護されたデータリソースにアクセスできる。ユーザが少なくとも要素ｅにアクセスするために必要なアクセス特権と同じぐらい大きな要素ｅについてのアクセス特権を持たないと決定された場合、ユーザは要素ｅに対応する保護されたデータリソースにアクセスできない（または、アクセスする権限を与えられない）。すなわち、要素ｅに対応する保護されたデータリソースにアクセスしようとするＳＱＬクエリーは、その要素についてのユーザのアクセス特権が少なくともその要素についての保護されたリソースデータベース１０４に格納されたアクセス特権と同じぐらい大きい場合にのみ、コンパイルおよび実行を認められることになる。ユーザのアクセス特権はクエリーごとにアクセス要件を満たさなければならず、そうでなければユーザのクエリーは実行を拒否されることになる。これによって、保護されたデータリソースへのアクセスに対する非常に優れた制御が可能になる。
【００１７】
非常に多数の保護されたデータリソースが存在し得るので、ＳＤＳ４００は対応して多数の要素を含むよう構成されることができ、その要素へのアクセス特権は要素当たり１つ以上のビットの状態で格納されることができる。要素の大きさは非常に異なっている可能性があることに注目されたい。このようなＳＤＳ４００に格納されるアクセス特権は、たとえば配備している会社の人事（Human Resources）（ＨＲ）部によって定義されてもよい。これらのアクセス特権は、ＨＲ部長が個々の従業員について知っていることならびにＨＲによって指定されるルールおよび値の両方を反映する。ＨＲは、請負業者、請負業者の従業員、下請業者、パートナー、パートナーの従業員、供給業者、供給業者の従業員、および企業の保護されたデータリソースの注意深く制御されるサブセットへの正当なアクセスを必要とし得るすべての人に関する基本的な企業ルールの通常の管理人でもある。このような人はすべて、一覧表が作成された保護されたデータリソースのうちの１つ以上へのアクセス特権を必要とする可能性があり、現在所有している特権よりも大きな特権を付与できないときに、ＨＲまたは十分なアクセス特権を有する任意の適切な関係者から、企業の保護されたデータリソースへの基本的なアクセス特権を与えられる必要がある。
【００１８】
たとえば、ＨＲおよび／または法務部が、任意の認証された個人の地位、およびその地位から生じる、保護されたデータリソースへのアクセス特権を決定してもよい。次いで、各々の認証された個人を担当する上司は、一旦ＨＲが従業員、請負業者またはその他としての地位を伝えると、自分自身のアクセス特権のサブセットを、報告してきた人に委譲できる。
【００１９】
ＨＲは、ＨＲ自体のデータを保護することにも関心を有し得る。リソースの管理者は、直接的であろうと、拡張された承認プロセスを介してであろうと、企業のセキュリティモデル全体のうち一部を行なうために、アクセス特権を決定し、一覧表の要素および値を割当てる。
【００２０】
たとえば、アクセス特権または権限は、セキュリティクリアランスレベルに従って定義されてもよい（たとえば、配布制限＝１、機密＝２、トップシークレット＝３、役員のみ閲覧可＝４）。しかしながら、いずれの場合にも、要素ごとにアクセス特権を格納する二進数は、（たとえば）数字が高くなれば、要素によって示される保護されたデータリソー
スにリンクまたはマッピングされる特権の序列がより高くなることを表わすようにアクセス特権の順位を表わすはずである。なお、多くの保護されたデータリソースは多くの異なるアプリケーションによってアクセスされる可能性があり、これらのアプリケーションによってまたは異なる上司によって推奨または指定されるアクセス特権は異なっている可能性がある。したがって、複数のアプリケーションにわたってアクセスされる可能性があるこのような保護されたデータリソースについてのアクセス特権が、複数のアプリケーションのうちいずれか１つによって必要とされる最高レベルに設定されることが重要である。その目的は、そうでなければ必要とされるであろうよりも小さなアクセス特権を使用して、予め定められた保護されたデータリソースへのアクセスを見つけるために、ユーザがアプリケーションを物色することを防ぐことである。本明細書に記載するこの発明のアプリケーションはその原理を組入れる。
【００２１】
実現可能であれば、ここでルールが実行され、その結果、このルールの製品は、名付けられ、割当てられる要素４０２において二進数として表わされる。それが実現可能でなければ、このルールが必要とするすべての必要情報は、問題の要素に入れられるようにＳＱＬコンパイラが適切な二進数を生成するようにユーザがＳＱＬコマンドを発行したときに利用可能でなければならない。
【００２２】
この時点で、セットアップ・リソース・一覧表・モジュール１０２は、アクセスが制御されるべきでありかつ各ユーザが保護されたデータリソースにアクセスできるようにするいくつかの保護されたデータ要素の各々に対応するいくつかの要素の各々について必要なレベルのアクセス特権を取得している。この発明の譲受人から入手可能なオラクル登録機能（Oracle Registration Facility）（ＯＲＦ）が、保護されたリソースデータベース１０４において保護されるべき特定の保護されたデータリソースに要素および値を添付するためにデータリソースの所有者によってツールとして使用されてもよい（が、使用される必要はない）。ＳＤＳは、図４に４００で示すように、ダミーのユーザＩＤ要素とともに、異なる大きさの要素の公知の構造を有する二進列またはビット列として表わされることができる。ＵＳＥＲ＿ＩＤも、含まれる（以下に記載される）ＧＳＤＳおよびＲＳＤＳなどのすべてのＳＤＳ構造に付加され得る。
【００２３】
ＳＤＳビット列においていくつのビットを扱うことができるかという問題については、ＩＡ−３２インテル・アーキテクチャ・ソフトウェア・ディベロッパーズ・マニュアルの巻２Ａ（IA-32 Intel Architecture Software Developer's Manual Volume 2A）：命令セットリファレンスＡ−Ｍ（Instruction Set Reference A-M）に少なくとも部分的に説明している。そこでは、３頁〜７頁に、「ビット（BitBase、BitOffset）はビット列内のビットの値を返し、これはメモリまたはレジスタにおけるビットのシーケンスである。BitBaseがメモリアドレスであれば、BitOffsetは−２ＧＢｉｔから＋２ＧＢｉｔの範囲にわたる可能性がある。」と書いてある。要するに、あるビット列またはいくつかのビット列は利用可能な空いたメモリを占有する可能性がある。プログラマーは、必要なメモリを確保するために整数のアレイを宣言でき、次いで、適宜ＳＤＳ構造を初期化できる。個々のビットを設定することは、ＳＤＳ構造３００のフォーマットを考慮すると、困難な提案ではなく、権限付与等価物（本明細書において以下に記載するＧＳＤＳ）はメモリへの同一のアクセスを可能にする。たとえ実行時に利用可能である量と同じ量のメモリを使用することが実現可能であるはずだとしても、２ＧＢｉｔという大きさは符号なしビット列の可能な最大の大きさであると理解されるべきである。
【００２４】
２ＧＢｉｔという利用可能な大きさは十分に大きく、均した合計で１ビットごとに２，０００，０００，０００個の要素、または２×１０００×１０００×１０００個を保持するであろう。どれほどこの量のメモリ、すなわち２５０メガバイトを割当てたとしても、各構造はさらに適度に強力なデスクトップコンピュータで利用可能なメモリの一部しか占
めないであろう。さらに、ＳＤＳ構造および比較演算（これも本明細書において以下に記載する）のために割当てられるメモリは、比較の結果が処理されるとすぐに容易に解放され得る。ビット列の最大範囲に関するこの同一の推理は、以下に記載する付与構造（Grant structure）（ＧＳＤＳ）にも当てはまる。以下に記載するメカニズムが完全なＳＤＳの短縮したサブセットを含み得ることにも注目されたい。リソースＳＤＳ（Resource SDS）（以下、ＲＳＤＳ）は、保護されたデータリソースのすべてに対応する要素の各々についてビット値を含むように構成される場合もあれば、ＳＱＬクエリーにおいてユーザが要求するリソースのみを含むよう構成され、実際に評価されることになる、保護されるべきコンパイラ機能によって発見される場合もあり、これはメモリの使用量の点でより経済的な提案である。
【００２５】
セットアップ付与
制御されるべき各データリソースの一覧表が作成され、ＳＤＳ構造内で位置および値を割当てられると、それらの一覧表が作成された保護されたデータリソースへのアクセス権は選択的にユーザに付与され得る。ここで図１に戻って、セットアップ付与モジュール１０６は、モジュール１０２によって一覧表が作成されかつ保護されたリソースデータベース１０４に格納される保護されたデータリソースに対してアクセスおよび操作上の特権または権限を有するように人々のリストを処理することに関与する。セットアップ付与モジュール１０６では、例示的な図４に示す形態のＲＳＤＳ構造が複製され、その構成要素３０２の値はデフォルトで０になる。この理由としては、好ましくはできる限り高いアクセスのデフォルト要件と比較して、アクセス付与のデフォルト値をできる限り低く設定するということがある。この態様で、アクセス付与および操作特権が設定される前に、付与ＳＤＳまたはＧＳＤＳはデフォルトの０に設定されるのに対して、要素ごとのアクセス付与および操作特権の要件は最大値に設定される。これらの値は次いで、要素ごとの所望のアクセスレベルおよび保護されたデータリソースにアクセスするために各ユーザに付与されるべきアクセスのレベルに従って変更される可能性がある。アクセス特権を表わすＧＳＤＳ構造は同一のデータ構造および要素（であるが、必ずしも要素の値ではない）を有し、これによって、特定の認証されたユーザが特定の保護されたデータリソースへのアクセスを付与されるかどうかを決定するためにＲＳＤＳとＧＳＤＳとを互いに容易に比較できる。
【００２６】
セットアップ付与モジュール１０６は、保護されたデータリソースに対して、従業員の地位、階層的身分および権利について、従業員についての基本情報をＨＲから収集および／または受取るよう構成され得る。セットアップ付与モジュール１０６は、各人が保護されたデータリソースのいずれかにアクセスできるようにＧＳＤＳを生成するよう構成され得る。各人がこのようにアクセスできるようにするためのＧＳＤＳは、図４に示すものと同一の構造を有し、その人のアクセス権に従って適切に設定されたさまざまな要素のビット値を有する。各人のＧＳＤＳは、ＧＳＤＳ構造の最下位部分にその人のＵＳＥＲ＿ＩＤを含むことになる。
【００２７】
このようなアクセス特権を設定するために、（たとえば）ＨＲ部は、ＨＲ部が制御するリソースへの特権を付与でき、その権利に従ってセキュリティルールを入力することもできる。次のステップは、人々の各上司が保護されたデータリソースのいずれかにアクセスできるようにして（おそらくＣＥＯ以外は、すべての従業員にはこのような上司がいる）、上司に報告してくる各人に対して特定のレベルの特権を付与することであってもよく、上司の上司、会社におけるセキュリティ職員、ＨＲ、または会社が選択した任意の審査エージェントからの承認ステップを任意に被る。この特徴は、配備している会社が適当であると思うときに特権の割当てを点検できるように意図される。
【００２８】
モデルまたはテンプレートを使用することによって、上司から付与を受取る個人にとっ
てアクセス権のこの割当ては非常にすばやいものになり得る。このようなモデルまたはテンプレートは、保護されたデータリソースへの所与の組の権利（所有する権利のサブセット）を報告に割当てるために上司によって使用され得る。このプロセスの終わりに、すべての従業員または他の認証された個人は、保護されたデータリソースへの任意のレベルのアクセスを有するように、会社での地位と一致するおよび／または会社内での責任の範囲と一致するＧＳＤＳ要素の各々に関して特定のレベルの特権を割当てられることになる。会社の方針は、第１のレベルの上司からのいくつかのまたはすべての付与を第２のレベルの上司が承認する必要があるかどうかを判断し得る。個人に関係のない要素の値はデフォルトで０にされ、これはアクセスがないことを意味する。この態様で、各人のＧＳＤＳによって、従業員の仕事または契約したタスクを行なうために必要なそれらの保護されたデータリソースのみに従業員がアクセス可能になる。同様の統合された制御は、請負業者およびその従業員、ならびにパートナーおよびその従業員、ならびに企業の保護されたデータリソースのいずれかにアクセスすることになる仕入先および顧客およびその従業員にも利用可能である。
【００２９】
特権を付与するためのツールとしてこのモジュールを使用するすべての上司の最終結果は、すべての適切な要素が特定の認証された関係者についての特権のレベルを示す値を割当てられるＧＳＤＳ構造である。認証された関係者のＧＳＤＳは、ディレクトリ・サービス・マークアップ言語（ＤＳＭＬ）の形態で表わされることができ、認証された関係者の証明書にユーザデータとして入力されることができる。ＧＳＤＳ  ＤＳＭＬは、（たとえば）オラクルのアプリケーションサーバのデータベースに格納されてもよく、オラクルセキュリティサーバに格納されてもよい。
【００３０】
この態様で、配備している会社は、会社の保護されたデータリソースのいずれかへの任意のアクセスを有するようにすべての認証された関係者のアクセス権を十分に指定することができ、このような関係者ごとに別個のＧＳＤＳにこれらのアクセス権を格納できる。これによって、ＲＳＤＳで表わされるリソースセキュリティ要件と個々のＧＳＤＳを比較することが可能になる。いずれの場合にも、想定されるリソースの所有者である上司は、（会社の方針および手順によって必要に応じて他の企業の関係者の同意を得て）証明書を持っている人をユーザＩＤにおよびその人自身のＧＳＤＳに指名すべきである。次のモジュールは、（たとえば公開鍵基盤（Public Key Infrastructure）またはＰＫＩ）証明書を備えた状態でユーザがログインした後のユーザのＳＱＬクエリーに対する機能的な反応について記載する。（たとえばＵＳＥＲ＿ＩＤを含む）証明書番号はここでは、ＲＳＤＳおよびＧＳＤＳの両方における最下位桁にロードされ得る。
【００３１】
保護されたリソースデータベース１０４に対する一覧表に追加すること（すなわち、アクセスが制御されるように、保護されたデータリソースを追加すること）は、保護されたデータリソースを保護されたリソースデータベース１０４に登録するためにセットアップ・リソース・一覧表・モジュール１０２に戻る必要がある場合があることにも注目されたい。新しく追加された保護されたデータリソースに対応する要素を追加するためにユーザまたはユーザのＧＳＤＳを修正することも必要であろう。次いで、ユーザのＧＳＤＳごとに新しく追加された保護されたデータリソースに対応する要素のビット値を好適に設定するために、セットアップ付与モジュール１０６を呼出すことができる。通常の使用中は（たとえば、図１に１１０で示すように、保護されたデータリソースに対してユーザがＳＱＬクエリーを構築している間は）、（付与データベース１０８は使用可能であるが）セットアップ・リソース・一覧表・モジュール１０２およびセットアップ付与モジュール１０６は使用できない。さらに、保護された一覧表への任意の新しい追加を尊重する任意のユーザのデフォルト特権は、デフォルトで０になるかまたはアクセスされない。
【００３２】
ＳＱＬプリコンパイル
プリコンパイラモジュール１１２の機能は、ユーザの要求されるクエリーまたはセッションに特有のクエリーの組またはアクセス要求をパーズおよび走査すること、ならびにクエリーを実行するために必要な保護されたリソースを選択しかつクエリーのためにＲＳＤＳを構築することを含む。ＲＳＤＳにおける要素のビット値は常にデフォルトで、要素の大きさと一致する最高数字にされる一方で、デフォルトユーザ付与は０であることに注目されたい。したがって、２ビットの大きさを有する要素識別子に対応するデフォルトビット値は「１１」になり、１ビットの大きさを有する要素識別子に対応するデフォルトビット値は「１」になる。これは、偶然によってまたは任意の他の理由で要素が特定の数字のビット値を割当てられない場合に、利用可能な最高の特権を持たない人を締め出すことになる。
【００３３】
プリコンパイラモジュール１１２の重要な機能性は、（１）あるセッションにおいて累積したクエリーからの特定のＳＱＬの保護されたデータリソースの呼出を、要素識別子、およびその保護されたデータリソースについてのセキュリティ許可レベル（およびセキュリティが重要なサブセットまたは関連付けられるルールのうちいずれか）を特徴付ける要素識別子に対応するビット値とリンクさせること、（２）（以下に記載する）コア機能モジュール１１４がユーザ自身のＧＳＤＳ構造に対して認証されたユーザの許可特権を適切にテストするように特定のビット値をＲＳＤＳ構造に書込むこと、および（３）オーバーラップおよび不等なセキュリティ要求がいくつかのソースからなされる場合に、任意の要素識別子に対応する所与のビット値について任意の許可ソースから要求される最高値を常に支持および行使することである。第３の項目（３）項目は、異なるアプリケーションによって同一の情報を不等に保護するという現在の問題に対する重要な保護である。
【００３４】
プリコンパイルプロセスの終わりには、１つ以上のビットを含むｎ＋１の寸法（要素）のデータ構造ＳＤＳが存在し、ｎ要素を有するデータ構造ＳＤＳは、認証されたユーザＩＤを表わす付加された下位の二進数を有する。デフォルト値は、ＩＤ要素の大きさによって到達可能な最高数字に設定され、ユーザＩＤは認証されたログインによってこの要素に置かれることができる。要素は、ユーザＩＤを除いてすべて、数字順に格納されることができ、これは、要素をリソースに割当てかつ値をアクセスレベルに割当てることから導き出される最上位の数字を左側に配置でき、最下位の数字を右側に配置できることを意味する。
【００３５】
ＳＱＬプリコンパイルは、確保される要素の最新の決定されたルールの値を処理すると、このルールを適用した結果を、確保される要素の値として割当てなければならないだけでなく、（ユーザＩＤを最下位桁に残して）一覧表セキュリティＳＤＳにおいて要素をソートし直すこともしなければならない。以下に見ることができるように、セットアップ付与では、一覧表リソースにセキュリティ値を添付することから発生する要素と同一のソート順序を持たなければならない要素の一致する組が存在することになる。これら２つのＳＤＳインスタンスを区別するために、それぞれにリソースセキュリティデータ構造（Resource Security Data Structure）（ＲＳＤＳ）および付与セキュリティデータ構造（Grant Security Data Structure）（ＧＳＤＳ）と名付けられる。Ｕｓｅｒ＿ＩＤのＲＳＤＳのデフォルト値は、割当てられる大きさで利用可能な最高値である。Ｕｓｅｒ＿ＩＤのＧＳＤＳのデフォルト値は、０に設定される。したがって、認証されたログインがなければ、以下に記載するコア操作は常に失敗するに違いない。
【００３６】
コア機能モジュール１１４は、ユーザの直接的または間接的なＳＱＬクエリーが前進およびコンパイルおよび実行できるようにするのにユーザの特権が十分であるかどうかを判断することを担当する。現在作動している原理は、範囲クエリー、オープンクエリーまたはブラインドクエリーを要求して、ユーザが十分な特権を保持する任意の情報を返す。この発明の実施例は、この原理を継続させてもよいが、必須のレベルの特権または権限なし
にユーザが保護されたリソースを直接的に要求する場合には任意のメッセージを特徴としてもよい。この発明の実施例は、ユーザが十分な特権を保持しない保護された情報が存在する状態でユーザが推測しているかどうかを見るためにチェックすることも可能である。たとえば、あるセッション内での失敗した特定のリソース参照の特定の数字は、ユーザに対して、ユーザの上司に対して、および／またはアクセスの試みの失敗に左右されるリソースの所有者に対してメッセージを生成してもよい。これらのメッセージの形態は、構成可能であってもよく、無許可のデータへのアクセスに関して現在実現されているセキュリティ方針を辿るべきである。
【００３７】
プリコンパイルの効率
この発明の実施例は２つのプリコンパイラを含み得る。プリコンパイラ１１２を最初に作動させることができ、次いで組込まれたまたは特別のＳＱＬ命令文を変換するために第２のプリコンパイラを作動させることができる。多くの顧客は、現在のところ、セキュリティの増大と引換えに性能の劣化を許容している。しかしながら、この発明の実施例は、クエリーの所与の組について、性能を劣化させるのではなく高めることができる。実際、許可されるそれらのクエリーのみを選択する（無許可の命令文または命令文のセグメントを取除く）ことによって、実質的により小さなクエリーがコンパイラに送られ得る。さらに、格納されたプリコンパイラの結果は、（１）ＳＱＬ命令文の許可される部分のさらに迅速な決定および（２）期間内またはセッション内での反復クエリーのためのプリコンパイラ機能の代案さえ可能にし得る。
【００３８】
一般的な「where*」ＳＱＬ句を、要求される「where」項目の特定の組に変換することは、所与のクエリーの範囲および実行時間も実質的に低減し得る。項目の閉集合を処理することは、ある範囲のまたは一般化されたグローバルな分類よりもはるかに早く、この項目の閉集合は必然的に、このような情報を組立てるためにデータベーステーブルの中でサーチおよび処理されなければならない。この発明の実施例に従うプリコンパイラモジュール１１２は、特権のテストがなされなければならない項目のみを含む修正されたクエリーを伝えることができ、コア機能１１４は、特権が不十分である場合に、クエリーの任意の部分を取除き、コンパイラは縮小したクエリーをコンパイルするだけでよい。
【００３９】
この発明の実施例に従うと、すべてのクエリーは要求されるクエリーおよびそのいくつかの部分のために許可のテストを準備するように１１２においてプリコンパイルされるべきであり、その代案は、この発明の実施例によってもたらされる効率の節約のいずれも差し控える（たとえば、性能をさらに犠牲にして結果を達成できなくするために、たとえばすべてをコンパイルし、他の下位レベルのセキュリティ対策を待つ）か、または減少したもしくは矛盾するセキュリティプロトコルおよび実施スキームに甘んじるかのいずれかである。さらに他の選択肢は、セキュリティを最適化し、性能を制限することである。もちろん、セキュリティを排除することによって性能を得ることも可能であろう。しかしながら、この発明の実施例によって、特定のアプリケーションセキュリティ規定を組織のセキュリティプロトコルに適合させるように顧客の分かりやすい目標に対して十分に計画を立てて、性能および許可セキュリティの両方を有することが可能になる。
【００４０】
この発明の実施例に従うと、生成されるすべての報告、検索される情報のすべてのビット、すべての編集またはアップデート、データおよび操作のセキュリティを呼出すすべての時は、好ましくは、データベースにおいて（たとえば）ＳＱＬクエリーとして表わされる。形態およびテンプレート、データ収集ページ、他のグラフィカルユーザインターフェイスならびに同様の構造は、ＳＱＬ命令文を中に組込ませることができる。開発者および会社のリソースにプログラム的にアクセスできる他の人も許可セキュリティに関して制御され得る。場合によっては、ＳＱＬでないコンパイラまたは実行環境ツールの向上が必要である場合がある。
【００４１】
ＳＱＬプリコンパイラは、現在のところ、組込まれたＳＱＬ命令文を、サポートされるプログラミング言語のうちの１つでコンパイラによって処理され得る命令文に変換するために存在する。このようなプリコンパイラは、入ってくるＳＱＬクエリーをパーズおよび走査するため、およびアクセスが求められる保護されたデータリソースを認識するため、およびこのような保護されたデータリソースへのアクセスに必要な許可レベルが符号化されるＲＳＤＳデータベースから関連付けられる要素および要素の値を検索するために本明細書において使用され得る。これらの材料は次いでＲＳＤＳ構造に組立てられることができる。ＲＳＤＳ構造は次いで、同一の要素が同一の順序になった状態で、対応する個々のユーザのＧＳＤＳ構造とともに複製され得る。その結果、ＧＳＤＳ構造およびＲＳＤＳ構造は、この時点で、図２において１１４で示すコア機能プロセスに移る準備が整っているであろう。
【００４２】
アクセスされようとする保護されたデータリソースについて十分に大きな許可をユーザのＧＳＤＳが指定しないためにユーザのクエリーが失敗した場合、ユーザは保護されたデータリソースへのアクセスを得るべきではない。たとえば、範囲を伴うブラインドクエリーまたは特定的でないクエリーは容易に検出され、阻止され得る。発見されれば、クエリーが失敗したという通知がユーザの上司に送られ得る。しかしながら、このような通知は、ユーザのＳＱＬクエリーの試みを介してアクセスを試みた保護されたオブジェクトに対して十分な特権を有する上司にのみ送られるべきである。発見されなければ、失敗は保護されたオブジェクトの所有者に通達として送られることができ、保護されたオブジェクトの所有者は次いで、ユーザの上司と連絡をとるべきかどうかおよび／または（おそらく）上司に特権を付与すべきかどうかを決定し得る。同一のセッションにおいて失敗が繰返されることによって印が付いた無許可の変数の名前を推測することは大半の会社のセキュリティ方針の違反であり、ユーザの上司は適切なメッセージによって通知されることができる。このような保護されたリソースの所有者は試行の回数を定義でき、その後、システムはこのようなアクセスの試みの繰返しをセキュリティ方針の違反であると解釈し得る。推測違反の通達は、適切な特権、つまり、保護されたデータリソースにアクセスするのに十分に高い特権を保持しない任意の上司に対して、保護されたデータリソースの存在を開示することを要求する必要はない。
【００４３】
ＳＱＬプリコンパイラ１１２の重要な機能は、ユーザのクエリー要求からリソースセキュリティ要件についての入力を受取ることと、このような入力を、所与のＳＱＬ命令文とその命令文を実行する際に利用される関連する保護されたデータリソースとの間の関連性に翻訳することとである。この発明の実施例に従うと、次いで、クエリーのプリコンパイルは全体として、クエリーのセキュリティ値を反映させるためにユーザのＲＳＤＳのいくつかの要素の値の各々において必要とされるビットの設定に繋がり得る。したがって、クエリーに応じて、それぞれの値が設定されるＲＳＤＳの要素の数は変化し得る。いずれの場合においても、ＳＱＬプリコンパイラ１１２は、試みられるクエリーについてユーザのＲＳＤＳ構造内で適切なビットを設定して、ユーザ自身のＧＳＤＳが満たさなければならない課題を提起するので、セキュリティゲートキーパーの役割を果たす。最終結果は、無許可のユーザが保護されたデータリソースに接近することに成功する前に、パスにおいて無許可のユーザを阻止することである。
【００４４】
ＳＱＬプリコンパイルプロセスは最初に、ユーザのＧＳＤＳ構造を持つ特権の記憶装置における値と等しくなるようにすべてのＧＳＤＳの要素を設定し得る。これは、割当てられた特権以外の特権をユーザが有しているように見えないようになされ得る。未使用の、要求されないリソースは、ユーザのクエリーがこれらのリソースを引用しなければ、その他の方法で許可される保護されたデータリソースへの所与のユーザのアクセスを阻止することはない。したがって、代替的に、ＲＳＤＳおよびＧＳＤＳ構造は、現在のセッション
のクエリーに関連するそれらの要素にのみ切捨てられてもよい。
【００４５】
ＳＱＬプリコンパイラ１１２は、この特定のセッションにおける問題の特定の特権の名前の組およびそのクエリーも有利に格納でき、その結果これらの名前は、以下に詳述するコア機能１１４の操作の終わりに生成され得るメッセージに挿入される。
【００４６】
クエリーは、ＳＱＬプリコンパイラ１１２が決定するようにアップデートされるＲＳＤＳの要素の値とともに局所的に格納され得る。時間が経てば、セッション内でおよびセッション間で、ユーザの反復クエリーは各インスタンスにおいて計算される代わりにこのような局部記憶装置から検索され得ることが期待される。
【００４７】
コア機能
この発明の実施例に従うと、コア機能は、ユーザが実行したいクエリーについて生成されるユーザのＲＳＤＳをユーザのＧＳＤＳと比較するためにコア機能モジュール１１４によって実行されることができ、これは、保護されたデータリソースに対して以前に付与されたユーザの許可を設定する。コア機能は、提出されたクエリーについて生成されるユーザのＲＳＤＳを、ユーザ自身の以前に生成されたＧＳＤＳと比較し得る。このような比較は、この発明の実施例に従って、以下のとおりに実行され得る。
【００４８】
１．ＧＳＤＳ≧ＲＳＤＳであるかどうかを判断する。
２．結果（ＲＥＳＵＬＴ）は１または０（論理的に真（ＴＲＵＥ）または論理的に偽（ＦＡＬＳＥ））である。
【００４９】
３．結果が真である場合、ユーザはクエリーを実行可能にするのに十分な許可を以前に付与されており、クエリーはコンパイルおよび実行することが認められ得る。
【００５０】
４．結果が偽である場合、すなわち、ＧＳＤＳ＜ＲＳＤＳである場合、ビット単位の演算ＧＳＤＳ  ＸＯＲ  ＲＳＤＳは、ＧＳＤＳにおける対応する要素よりも大きなＲＳＤＳの要素を示す固有の数字を生み出し、ユーザのクエリーは（少なくともユーザが不十分な権限を有する保護されたデータリソースにアクセスするであろう任意の演算に関して）実行が妨げられる。
【００５１】
５．上の♯４の固有の数字の出力は、許可が失敗した要素識別子の組合せを生み出す。
６．この発明の実施例は、ユーザが不十分な許可を有する保護されたデータリソースにアクセスしようとするクエリーおよび／または十分な権限の付与をセットアップ付与モジュール１０６から要求しようとするクエリーを認めないよう構成され得る。アクセスの試みが不成功に終わったことを（たとえば）保護されたリソースの所有者に警告するためにメッセージも生成され得る。ブラインド、範囲または予め定められた回数の推測の反復によっても、１つ以上のメッセージが、最初の２つに関してはリソースの所有者（および、ユーザの上司が特権を有する場合にはユーザの上司）に対して生成され、送られることができ、最後の１つは会社のセキュリティ方針の違反であると考えられることができ、リソースの所有者および／または任命されたセキュリティ担当者（構成項目）に対してメッセージが生成され、送られることができる。
【００５２】
７．ユーザが、失敗したクエリーを完成させるために（または、ユーザから独立して）十分な権限の付与を要求することを選択した場合、この方法はセットアップ付与モジュール１０６に関して概説するプロセスに戻ることが可能である。
【００５３】
８．許可が付与されると、ユーザの許可されるクエリー、格納されるクエリーおよびリンクされるクエリーは次いで、無許可の部分および実行された許可されるクエリー、およ
びアクセスされるクエリーが参照する保護されたデータリソースを剥奪され得る。ユーザは、他の方法で構成されない限り、クエリーにおけるリソースの特定の引用から直接に許可の失敗を知ることができるだけである。代替的に、このシステムは、無許可の要素およびそれらの対応するリソースをクエリーから取除くように設定されてもよく、引き続きクエリーの許可される部分のみをコンパイルおよび実行することに移る。
【００５４】
上の番号４および５に対して、以下のとおりに固有の数字を導き出すことができる。＞＝テストに関する偽の結果を考慮すると、テストされている要素のうち少なくとも１つは失敗したに違いない。すなわち、少なくとも１つのインスタンスにおいて、要素は特権（ＧＳＤＳ側）よりも大きな要件（ＲＳＤＳ側）を有していたに違いない。一旦要素がソートされ、ＧＳＤＳおよびＲＳＤＳの両方について整列されると、要素の失敗はいずれも、失敗した要素の各々において設定される少なくとも１つの最上位ビットをＲＳＤＳが有することを意味するに違いない。ＧＳＤＳにおける０およびＲＳＤＳにおける１というＸＯＲの結果が等価の要素について１である一方で、ＧＳＤＳにおける０およびＲＳＤＳにおける０が対応する要素について０としてＸＯＲを出すことに注目されたい。これは、いずれか１つであるが両方ではないものの「排他的なｏｒ」ＸＯＲメカニズムである。差がある場合、それは、要素が＞＝テストに失敗した場合に失敗した要素内の最上位桁における１が結果となるに違いない。
【００５５】
要素が順序付けられ、すべて公知であるので、ｎ要素は以下のとおりに失敗の組合せを有するに違いない。
【００５６】
たとえば、ｎ＝５である場合、５つの異なる要素が存在し、その各々またはそのすべてが失敗する可能性があるだろう。組合せは以下のとおりである（要素の失敗においては順序は重要ではない）
Ａ＝１つの要素の失敗については５！／１！（５−１）！（これは５である）
Ｂ＝２つの要素の失敗については５！／２！（５−２）！（これは１０である）
Ｃ＝３つの要素の失敗については５！／３！（５−３）！（これは１０である）
Ｄ＝４つの要素の失敗については５！／４！（５−４）！（これは５である）
Ｅ＝５つの要素の失敗については５！／５！（５−５）！（これは１である）
これは、ｎ＝５の場合、３１個の可能なセルの索引付けされたアレイが５つのこのような要素の組について失敗した要素の異なる組合せをすべて保持するであろうということを暗に意味している。失敗した要素の各組合せによって表わされる数字は、１から３１の間の何らかの数字であるだろう（０は失敗がないことを意味し、したがってアレイの一部ではないことに注目されたい）。Ａ＋Ｂ＋Ｃ＋Ｄ＋Ｅのアレイは、失敗の起こり得る組合せをすべて保持するであろう。このアレイは、ＧＳＤＳの順序付けられた要素が公知であるときはいつでも生成され得る。次いで、アレイは、各々の失敗した要素がＧＳＤＳおよびＲＳＤＳをＸＯＲすることによって生成された固有の数字から類推されるように索引付けされ得る。したがって、失敗した要素を含むアレイへの索引は、ＸＯＲコア操作によって生じる固有の数字から導き出されることができる。
【００５７】
結果は、コア機能のセットアップがＲＳＤＳおよびＧＳＤＳをＸＯＲすることによって生じる固有の数字を利用してアクセスされるべき失敗した要素の組合せのアレイを生成することを含み得るというものである。どの要素が承認され、どの要素が認められなかったかについての情報を伝えるコア機能によって、ユーザの提出されたクエリーは、ユーザが十分な付与された権利を有していたそれらのリソースでのみ実行可能になり得る。
【００５８】
メッセージのユーティリティは、ユーザのユーザＩＤを知っており、ユーザの上司について必要とする情報にアクセスできる。メッセージは最終的には、クエリーを実行するのに十分な権利を上司が付与するようにこのメッセージを上司に転送してほしいかどうかを
ユーザにたずねることができる。次いで、ユーザはクエリーを再構築するかまたは必要な特権を要求できる。上司は、たとえ十分な付与する特権を所有していたとしても、メッセージ上での承認をチェックすることを選択する場合もあれば、選択しない場合もあり、このメッセージに関する他の承認ワークフローについても対応がなされ得る。この発明の実現される実施例の最終結果は、系統的で、堅固でかつ実行する態様でセキュリティ要件を扱う、準備の整った手段が会社にもたらされることである。
【００５９】
ユーザが、許可されたものもあれば許可されていないものもある、ある範囲の値を求めた場合は、（Ａ）コンパイラによって、すべての示された許可される項目の要求に変換されてもよく、（Ｂ）ユーザが追加の特権を要求する際にメッセージが上司に送られる時であってもよく、（Ｃ）上司によって承認され、問題のリソースの所有者に送られる追加の特権の要求をもたらしてもよく、または（Ｄ）これらのいくつかの組合せであってもよく、このシステムをセットアップする、許可されたユーザによって選択される構成によって決定される。
【００６０】
ユーザが繰返し異なる変数を試行し、その変数のうちどれもがユーザのために許可されない、または存在さえしない場合は、少なくともいくつかのセキュリティルールの違反である。この実施は、試行を繰返すことによってパスワードを推測することに類似している。この発明の実施例は、顧客の会社のセキュリティ方針において適切であると決定されたメッセージを送るよう構成され得る。
【００６１】
アップデートおよびアップグレード
アップグレードおよびアップデートモジュールは、既存のセキュリティ規定を適切なＲＳＤＳ構造に転送するように、およびユーザのオプションにおけるさらに他の修正を可能にするように設けられ得る。同様に、アプリケーションおよび外部における既存のルールは、ＲＳＤＳの要素を生成するように処理され得る。次いで、ユーザプロファイルの自動的な処理によって、ＧＳＤＳの等価の要素が適切な値を保持できるはずである。この観点から、ユーザは既存のデータベースシステムのセキュリティ特性とともに十分に機能するシステムを有することになる。次いで、ユーザは任意の所望の追加の粒度を有する既存のセキュリティパラメータを具体化することに進むことができる。このモジュールは、このプロセスで必要な情報を収集するのに適切な形態を与えることが可能である。このモジュールは、昇進、ならびに職務、雇用もしくは契約状態のいずれかもしくはすべてに影響を及ぼすシステムユーザの地位または特定の情報を知る必要性（したがってそれらの許可）の他の変化を処理するために、形態および自動化された手順も与えることになる。
【００６２】
図２は、この発明の実施例に従う、クエリーの実行を認めるかまたはクエリーの実行を認めないように実行され得るステップを示すフローチャートである。図２は、ユーザのために格納されたＧＳＤＳ構造が既に存在すると仮定する。ＧＳＤＳ構造は、保護されたデータリソースに対するユーザの許可を体系化する。保護されていないデータリソースは、定義によれば、少なくとも適切に認証された人員による、保護されていないデータリソースへのアクセスに関して制限されない。操作上、この方法はＳ２１で開始し、その後、ステップＳ２２において要求されるように、クエリーは、実行のために構築および提出されるときに分析され、クエリーを提出した人に特有のおよび提出されたクエリーがアクセスしようとする保護されたデータリソースに特有のＲＳＤＳ構造が生成される。Ｓ２３において示すように、ＧＳＤＳとユーザおよびユーザのクエリーに特有のＲＳＤＳとを比較することによって、提出されたクエリーが参照する保護されたデータリソースにアクセスするユーザの権限に対して判断がなされ得る。たとえば、ＧＳＤＳがＲＳＤＳよりも大きいかまたはそれと等しい場合、Ｓ２４およびＳ２５において示すように、提出されたクエリーは実行を認められることができる。ＧＳＤＳ（の値）がＲＳＤＳ（の値）よりも小さい場合には、Ｓ２６において示すように、ユーザのクエリーは認められないであろう（たと
えば、実行を妨げられるであろう）。この方法はＳ２７において終了し得る。失敗の場合、ＲＳＤＳにおけるどの要素がユーザのＧＳＤＳにおける相当する要素よりも小さい値に設定されたかを厳密に判断するために（たとえばＸＯＲ演算などの）追加のステップが実行され得る。ＧＳＤＳおよびＲＳＤＳ構造の大きさを縮小するために、ＧＳＤＳおよびＲＳＤＳ構造は必要に応じて選択的に切捨てられるおよび／またはマスキングされてもよい。
【００６３】
図３は、この発明の他の実施例に従う、保護されたデータリソースへのアクセスを制御するために実行され得る拡張されたステップを示す。図３に示す方法はＳ３１において開始し、その後、Ｓ３２において示すように、保護されるべきすべてのデータリソースの一覧表が実行され得る。その後、Ｓ３２において示すように、それぞれのアクセス権を定義するために、予め定められた数のビットを、保護されるべき各々の一覧表が作成されたデータリソースに割当てることができる。アクセスへの許可が付与されるかまたは付与されない場合には単一のビットで十分であるかもしれず、ビットがより多くなればより細かい粒状の制御（たとえば、読取のみ、読取／修正、削除など）が可能になる。次いで、これらのビットを保持するために、セキュリティデータ構造（ＳＤＳ）フレームワークを定義でき、その一例が図４に示される。ステップＳ３５およびＳ３６は、保護されたデータリソースへのアクセス、および構造の各要素についての権限レベルに対応するビットを選択的に設定することによって符号化されるそれぞれの付与される権限を要求し得るユーザごとに定義されるように１つのこのようなＳＤＳ構造を要求して、そのユーザについてのＧＳＤＳ構造を形成する。Ｓ３７において示すように、参照するまたはそうでなければ保護されたデータリソースにアクセスしようとするクエリーが受取られると、ＲＳＤＳ構造はクエリーを提出したユーザのために生成され、ＲＳＤＳはユーザのＧＳＤＳと同一の構造を有する。しかしながら、ＲＳＤＳは、ユーザのクエリーがアクセスしようとする保護されたデータリソースにマッピングされる構成要素ごとにビット値を含み、各々のこのような要素に格納された値はユーザのＧＳＤＳにおける相当物未満である場合もあれば、相当物未満でない場合もある。ＧＳＤＳおよびＲＳＤＳ構造（または、特定のクエリーによって決定される、一致するサブセット）が、提出されたクエリーの実行を認めるかどうかを判断するために比較されるとき、ＧＳＤＳ＞＝ＲＳＤＳであるかどうかが判断され得る。もしそうであれば、ユーザのクエリーは実行を認められる。ＧＳＤＳ＜ＲＳＤＳである場合には、ステップＳ３８によって要求されるように、ユーザは許可が不十分なクエリーを提出しており、ユーザのクエリーは（少なくとも最初は）実行を拒否される。クエリーのどの要素が失敗したのかを厳密に判断するために（すなわち、ＲＳＤＳの要素が対応するＧＳＤＳの要素よりも大きかったことに対して）（たとえばＸＯＲ演算などの）さらに他の演算が実行され得る。次いで、保護されたデータリソースへのアクセスの試みの失敗のロギング、ならびに／またはクエリーがうまく実行できるように上司に警告するおよび／もしくは十分な権限の付与を要求するためのメッセージ送信ステップなどの追加のステップ（図３には図示せず）がセキュリティの目的で実行され得る。
【００６４】
動作例
以下では、コンピュータによって実現される許可のための上述の方法の一例が提示される。以下の例は、ビジネスプロセス、および本明細書に記載するセキュリティ方法がこのようなビジネスプロセスの構成要素に影響を及ぼす態様を示す。単に例示の目的で、この例は３つの部署、つまり、エントラダ（ENTRADA）部、ファンダス（FUNDUS）部およびゴルゴン（GORGON）部を有する架空のＸ社（X Company）（以下、ＸＣＯ）を取上げる。ＸＣＯはさらに、２つの階層レベル、つまり、記帳係（Entry Clerk）階層レベルおよび請求書承認者（Invoice Approver）階層レベル、ならびに１つの集中支払部ファンダスを特徴とする。この例は５人のユーザを含み、そのうち３人が請求書係であり（ジョーンズ（JONES）、スミス（SMITH）およびブラウン（BROWN））、２人が上司／請求書承認者である（ディザーズ（DITHERS）およびスミザーズ（SMITHERS））。この例では、これら５人
のユーザは２つの製品群、つまり、ギズモ（GIZMO）製品群およびガジェット（GADGET）製品群を扱うことになる。従来から、各部署は、当然のセキュリティ規定を有する別個のオペレーティングユニット（Operating Unit）（ＯＵ）として編成されているだろう。しかしながら、この発明の実施例に従うと、このようなＯＵは、ユーザ定義ルールにおいてならびに／または特権、権利および役割をユーザに割当てるための基礎として使用され得る以外はいかなる重要性も持つ必要がない。
【００６５】
この例において適用される許可セキュリティルール（Authorization Security Rules）
すべての支払は、ＸＣＯの集中支払部であるファンダス部からなされることになる。
【００６６】
ジョーンズは、エントラダ部についての請求書しか記帳できない。しかしながら、ジョーンズはファンダス部の請求書も参照できる。
【００６７】
スミスは、ファンダス部についての請求書しか記帳できない。
ブラウンは、エントラダ部およびゴルゴン部についての請求書を記帳できる。
【００６８】
ディザーズは、エントラダ部、ファンダス部およびゴルゴン部の請求書を参照でき、ディザーズは支払のためにこれらの請求書を承認／アップデートすることも可能である。
【００６９】
ディザーズは、（製品群にかかわらず）ファンダス部における支払を参照、作成およびアップデートできる。
【００７０】
スミザーズは、エントラダ部、ファンダス部およびゴルゴン部のガジェット製品群の請求書を参照できる。スミザーズは、これらの請求書がガジェット製品群からのアイテムしか含まない場合に、これらの請求書をアップデートでき（請求書支払方法）、支払実行のために提出されるようにこれらの請求書を承認できる。スミザーズは、ギズモ製品群の支払を承認できない。
【００７１】
スミザーズは、ファンダス部における支払を参照およびアップデートでき、エントラダ部およびファンダス部から生じる請求書の支払のみを承認できる。
【００７２】
ディザーズは、ギズモ製品群のみについて記帳されたいずれの請求書も支払のために監査（参照）でき、承認（アップデート）できる。
【００７３】
したがって、請求書係および上司／請求書承認者は両方とも、記録をアップデート、承認、および監査または参照しさえするための権限が限られている。上で定義されたＸＣＯの買掛金勘定および売掛金勘定のルールは、製品群（ガジェットまたはギズモのいずれか）による財務記録にアクセスするためおよびそれをアップデートするための要件、またはＸＣＯの３つの部署（エントラダ、ファンダスおよびゴルゴン）からの請求書の支払を承認するための要件を設定する。ガジェットおよびギズモラインのアイテムを両方含む請求書は、部分的請求書を参照できない限り、ガジェット製品群についての監査特権しか持たない人またはギズモ製品群についての監査特権しか持たない人に対しては禁じられるであろうということに注目されたい。
【００７４】
ディザーズは、セットアップ・リソース・一覧表およびセットアップ付与段階におけるのと同様に十分に簡単に製品群ギズモのアイテムについて受取られた請求書を参照できることになり、最初にギズモの所有者はＲＳＤＳの適切な要素において要求特権を設定し、次いでセットアップ付与段階では、ギズモの所有者は特権の付与を行ない、対応する要素が適切な特権レベルで設定される。ギズモ製品群のリソースの所有者は、ＧＳＤＳにおいて適切な要素を確立して、望んだすべてのギズモリソースを保護するであろう。次いで、
その所有者はディザーズを付与し得るであろう（ならびに、委任によっておよびＨＲガイドラインの範囲内で、ディザーズは報告に特権を付与し得るであろう）。これは、これらのアクセスがガジェットの所有者によってまたは十分なガジェット特権の保持者によって付与されない限り、ディザーズはガジェット製品群のアイテムについての請求書にアクセスできないであろうということを意味する。
【００７５】
ディザーズは、必要な権限の付与なしには、混在した請求書ライン（たとえば、製品群ギズモのアイテムについての第１の請求書ラインおよびガジェット製品群のアイテムについての第２の請求書ライン）を有する請求書へのアクセスもないであろう。
【００７６】
以下では、この発明の実施例によっていかにこれらのセキュリティ規定が実現され得るかについて詳述する。（たとえば）人事（ＨＲ）部は、どの従業員が会社の帳簿および他の保護されたデータリソースにアクセスできるかを判断する責任を与えられる、ＸＣＯ内のエンティティ(entity）であり得る。したがって、３つの部署について、ＸＣＯが維持する財務アプリケーションでは、スミス、ジョーンズおよびブラウン（請求書係）ならびにディザーズおよびスミザーズ（上司／請求書承認者）しか、いずれの特権も全く持たないはずである。さらに、これら５人のうち少なくとも１人がログインされかつ認証されたユーザでなければならない。請求書係は仕事を行なう必要性および必知事項によって制約され、これら２つは上司によって請求書係に割当てられる特権の基礎である。
【００７７】
ＸＣＯの保護されたデータリソースはすべて、図１における１０４で示すようなデータベースに登録され得る。この発明の実施例に従うと、保護されたデータリソースは、アクセスが制御されるべき、ＸＣＯに属しているすべてのデータ、プログラムまたは電子記録を含む。したがって、すべてのこのようなデータリソースの一覧表が実行されるはずであり、一覧表の結果は登録データベースに登録されるはずである。各人がこのような保護されたデータリソースにアクセスできるようにするためにリソースセキュリティデータ構造（ＲＳＤＳ）が作成され得るのは、この登録データベースからである。ＲＳＤＳデータベースは、これらのＲＳＤＳ構造を格納するために作成され得る。
【００７８】
ＲＳＤＳは、この態様で、クエリーがアクセスを求める一覧表が作成された保護されたデータリソースを編集または承認するために任意のアクセス、表示または能力を得るようにＲＳＤＳが割当てられる固有に識別される人について満たされなければならない許可レベルを定義する。保護されたデータリソースの所有者は、要素ごとに、固有に識別されるユーザに付与するためのアクセスの所望のレベルに従って、構成要素に対応するＲＳＤＳビットを選択的に設定することに繋がる態様で、セットアップ保護リソース一覧表モジュール１０２からのプロンプトに応答することになる。ＴＳＤＳ構造における要素の各々についてアルファベット順の要素識別子を使用して、以下が得られるであろう。
【００７９】
【数１】
2008546114.tif 000003
【００８０】
初期のＲＳＤＳ構造（すなわち、アクセスの所望のレベルに対応するいかなるビット値もセットされる前のＲＳＤＳの初期状態）は、要素識別子ａ、ｂ、ｃ…ｍのビット値を１
１という最大値（１１は３の二進数である）に設定させることに注目されたい。この例では、図３に示すように、要素ａ、ｂ、ｃは、ビット値００（アクセスなし）、０１（参照／監査）および１０（記帳）に対応する、要素に関連付けられる３つのレベルの許可権を有する。ユーザを固有に識別するＵｓｅｒ＿ＩＤについて（たとえば）６４ビット列を示すためにＵｓｅｒ＿ＩＤ８８８８８８８が使用されることにも注目されたい。これらの要素はさらに、最下位桁におけるＵｓｅｒ＿ＩＤのみを除いて、最大値のソート順になっている。
【００８１】
セットアップ付与
付与セキュリティデータ構造（ＧＳＤＳ）はＲＳＤＳ構造の鏡像であり、その初期の要素のビット値は０、すなわちデフォルト特権に設定される。
【００８２】
【数２】
2008546114.tif 000004
【００８３】
これは、ユーザごとのデフォルトがクエリーにおけるすべてのまたは任意の保護されたデータリソースにおいて特権ではないことを暗に意味している。ユーザのクエリーが任意の保護されていないオブジェクトについてうまくいく可能性があることに注目されたい。ユーザがブラインドクエリーを起動した場合、ユーザは、ユーザが実際に必須の特権を有するそれらのオブジェクトしか参照しないことになる。この発明の実施例は、ユーザが十分な許可を付与されなかった保護されたデータオブジェクトへのアクセスを認めない。
【００８４】
ＳＱＬコンパイル
ここで、本明細書において展開される具体的な例に戻って、ギズモ製品群からの情報を含むいずれの請求書も参照または監査する特権を持たないスミザーズは、なんとしてもギズモ製品群をチェックする決心をする。スミザーズは、他の情報源から製品名を知り、適切なＷＨＥＲＥ句を推測する。ここで、ユーザであるスミザーズがログインされ、認証されると、スミザーズは、図１において参照数字１１０で示すような、単一のセッションで保護されたデータリソースにアクセスするよう構成された財務アプリケーションから一連のクエリーを起動する。このクエリーは、ギズモおよびガジェット製品群からの売上報告の要求およびガジェット製品群およびギズモ製品群を両方含む、ゴルゴン部からの特定の請求書の支払承認の別の要求を含む。このユーザについての許可セキュリティルールを想起されたい。スミザーズはエントラダ部、ファンダス部およびゴルゴン部のガジェット製品群の請求書を参照できる。スミザーズは、これらの請求書がガジェット製品群からのアイテムしか含まない場合に、これらの請求書をアップデートでき（請求書支払方法）、支払実行のために提出されるようにこれらの請求書を承認できる。スミザーズは、ギズモ製品群の支払を承認できない。さらに、許可セキュリティルールは、スミザーズがファンダス部における支払を参照およびアップデートでき、エントラダ部およびファンダス部から生じる請求書の支払のみを承認し得るとも述べている。
【００８５】
（図１において１１２で示す）コンパイラ（またはプリコンパイラ）モジュールは、関連する保護されたデータリソースの要素が要素識別子ｆ（ゴルゴン部からの請求書の承認）、ｊ（ガジェット製品群の監査）、ｋ（ギズモ製品群の監査）、ｌ（ガジェット製品群の請求書の承認）、およびｍ（ギズモ製品群の請求書の承認）にマッピングされるスミザーズのクエリーから類推することになる。スミザーズのクエリーについてのこれらの保護されたデータリソースへの要求されるアクセスに従って要素識別子のビット値を設定する
ことによってＲＳＤＳがもたらされ、そのビット値は以下のとおりである。
【００８６】
【数３】
2008546114.tif 000005
【００８７】
したがって、図４に提示するＳＤＳ４００の構造に続いて、スミザーズのＲＳＤＳは以下のフォーマット：００  ００  ００  ０  ０  １  ０  ０  ０  １  １  １  １を有する可能性があり、その後に、最下位桁において後尾のスミザーズの６４ビットのＵｓｅｒ＿ＩＤが続く。スミザーズがクエリーを介してアクセスすることを望むそれらの保護されたデータリソースのビット値のみを含むようにこの構造を切捨てることは、以下のとおりにこれらのクエリーについてのスミザーズのＲＳＤＳのための構造に繋がる。
【００８８】
【数４】
2008546114.tif 000006
【００８９】
示されるように、スミザーズがクエリーにおいてアクセスしようとする各々の保護されたデータリソースは、対応するビット値を「１」に設定させる。スミザーズについて上の許可セキュリティルールに定義されるスミザーズについての許可に従って要素識別子のビット値を設定することによって、スミザーズについてのＧＳＤＳがもたらされ、そのビット値は以下のとおりである。
【００９０】
【数５】
2008546114.tif 000007
【００９１】
ユーザのＧＳＤＳのビット値はこのようなユーザによって任意のクエリーに先立って定義され得ることに注目されたい。したがって、図４に提示するＳＤＳ４００の構造に続いて、スミザーズのＧＳＤＳは以下のフォーマット：００  ００  ００  ０  ０  １  ０  ０  ０  １  ０  １  ０を有する可能性があり、その後に、最下位桁において後尾のスミザーズの６４ビットのＵｓｅｒ＿ＩＤが続く。（要素識別子ｆ、ｊ、ｋ、ｌ、ｍのビット値およびＵｓｅｒ＿ＩＤのみを含むように）上の生成されたＲＳＤＳに対応するビット値のみを含むようにこの構造を切捨てることによって、スミザーズがクエリーを介してアクセスすることを望むそれらの保護されたデータリソースについての以下の切捨てられたＧＳＤＳがもたらされる。
【００９２】
【数６】
2008546114.tif 000008
【００９３】
Ｕｓｅｒ＿ＩＤのために６４ビットが使用されることに加えて、付与および要求される許可を定義するために５ビットしか使用されないことに注目されたい。ＲＳＤＳおよびＲＳＤＳ構造の両方についての切捨てられていないビット列を全部使用できるが、これは必要ではない。なぜなら、大半のクエリーは、すべての一覧表が作成された保護されたデータリソースへのアクセスを伴わないかまたは必要としないためである。切捨てることは有利にＲＳＤＳおよびＧＳＤＳの両方で実行され得る。なぜなら、順にユーザクエリーから導き出されるＲＳＤＳのビット値のサブセットに一致するビット値を除いていかなるＧＳＤＳのビット値も評価する必要がないためである。
【００９４】
コア機能
機能的におよびこの例を参照して、図１において１１４で示すコア機能モジュールは、スミザーズがギズモ売上報告およびガジェット売上報告を参照するようになるかどうか、ならびにスミザーズがガジェット製品群およびギズモ製品群を両方含む、ゴルゴン部からの特定の請求書の支払を承認するようになるかどうかをテストする。このテストは、ＧＳＤＳビット列とＲＳＤＳビット列との比較を含み得る。この比較の最終結果は、スミザーズが適切な許可を持たない保護されたデータリソースを伴うスミザーズの（たとえば）ＳＱＬクエリーのいずれかの実行を選択的に妨げること、またはこのようなＳＱＬクエリー
の実行を認めることを含み得る。この発明の実施例に従うと、この比較は、ＧＳＤＳ＞＝ＲＳＤＳが真であるかどうかを判断する第１のステップを含み得る。もしそうであれば、スミザーズのクエリーは実行を認められることになる。ＧＳＤＳ＞＝ＲＳＤＳの結果が偽である場合には、（任意に切捨てられた）ＲＳＤＳおよびＧＳＤＳの両方のビット列をオペランドとして使用して、排他的ＯＲ演算（以下、ＸＯＲ）または他のテストが実行され得る。
【００９５】
ＧＳＤＳおよびＲＳＤＳの値を代入すると、ＧＳＤＳ＞＝ＲＳＤＳ演算は、１１０１０
ＳＭＩＴＨＥＲＳ  ＵＳＥＲ＿ＩＤ＞＝１１１１１  ＳＭＩＴＨＥＲＳ  ＵＳＥＲ＿ＩＤ＝ＦＡＬＳＥになる。ここから、ＲＳＤＳの少なくとも１つの要素が、対応するＧＳＤＳの要素よりも大きい最上位ビットを有することが類推され得る。したがって、ＲＳＤＳのどの要素が対応するＧＳＤＳの要素よりも大きいかを判断するために、コア機能モジュール１１４は、以下のＸＯＲ演算を実行し得る。
【００９６】
【数７】
2008546114.tif 000009
【００９７】
したがって、ＸＯＲ演算の結果は以下のとおりである。
【００９８】
【数８】
2008546114.tif 000010
【００９９】
ＳＭＩＴＨＥＲＳ  Ｕｓｅｒ＿ＩＤの必ず同一の２つのインスタンスをＸＯＲすることによって得られる後尾の「０」を無視すると、結果の値は００１０１であり、これは５という十進数の値に対応し、要素ｋおよびｍ（ギズモ製品群の監査および支払承認）に関する許可が失敗したことを示す。代替的に、ＲＳＤＳおよびＧＳＤＳ構造の各要素について別個のＸＯＲ演算が実行されてもよく、その結果において設定される任意のビットは次いで格納されてもよく、その対応する失敗した要素と関連付けられてもよい。その結果、コア機能モジュール１１４は、図１において１２２で示すように、スミザーズが任意のまたは十分な許可を付与されなかった保護されたデータリソースにアクセスする試みの実行を認めないことになる。具体的には、要素識別子ｋおよびｍにマッピングされた保護されたデータリソースにアクセスするスミザーズのＳＱＬクエリーは実行を拒否されることになる。機能的に、これは、スミザーズがギズモ製品群の監査および支払承認に関連する保護されたデータリソースにアクセスできないことを意味する。
【０１００】
より詳細には、ＧＳＤＳとＲＳＤＳとの間のＸＯＲ演算の０でない結果を考慮して、要素（ｆ、ｊ、ｋ、ｌ、ｍ）のうち少なくとも１つは失敗していたに違いない。すなわち、少なくとも１つのインスタンスにおいて、要素は特権（ＧＳＤＳ側）よりも大きな要件（ＲＳＤＳ側）を有していたに違いない。２つの間に差がある場合、その要素がＸＯＲテストに失敗していれば、失敗した要素内の最上位桁における１が結果として生じることになる。
【０１０１】
ＸＯＲ演算の結果を考慮して、不十分な特権を示す論理１をどの要素がもたらしたかを判断するために使用され得る多くの方法が存在する。５つの異なる要素（ｆ、ｊ、ｋ、ｌ、ｍ）に関して、これらの要素のうちいずれか１つまたはすべてが失敗する可能性がある
だろう。組合せは以下のとおりである（要素の失敗においては順序は重要ではない）。
【０１０２】
Ａ＝１つの要素の失敗については５！／１！（５−１）！（これは５である）
Ｂ＝２つの要素の失敗については５！／２！（５−２）！（これは１０である）
Ｃ＝３つの要素の失敗については５！／３！（５−３）！（これは１０である）
Ｄ＝４つの要素の失敗については５！／４！（５−４）！（これは５である）
Ｅ＝５つの要素の失敗については５！／５！（５−５）！（すべての要素ｆ、ｊ、ｋ、ｌ、ｍの失敗については組合せ１１１１１が１つしか存在しないので、これは１である）
これは、３１個の可能なセルの索引付けされたアレイが５つのこのような要素の組について失敗した要素の異なる組合せをすべて保持するであろうということを暗に意味している。失敗した要素の各組合せによって表わされる数字は、ちょうど５桁の二進数が０から３１の範囲であるのと同様に、１から３１の間の何らかの数字であるだろう（０は失敗がないことを意味し、したがってアレイの一部ではないことに注目されたい）。
【０１０３】
Ａ＋Ｂ＋Ｃ＋Ｄ＋Ｅのアレイは、失敗の起こり得る組合せをすべて保持するであろう。このアレイは、ＧＳＤＳの順序付けられた要素が公知であるときはいつでも生成され得るであろう。次いで、アレイは、（失敗した要素の組についての情報を含む）各失敗セルがＧＳＤＳおよびＲＳＤＳをＸＯＲすることによって生成された固有の数字から類推され得るように索引付けされ得るであろう。次いで、失敗した要素の名称を含むアレイのセルへの索引は、ＸＯＲ演算によって生じる固有の数字から導き出されることができる。
【０１０４】
結果は、コア機能１１４のセットアップがＲＳＤＳおよびＧＳＤＳをＸＯＲした結果からの数字を利用してアクセスされるべき失敗した要素の組合せのアレイを生成することを含み得るというものである。図１において１１６および１１８で示すように、どの要素が承認されたかについての情報を伝えるコア機能１１４によって、コンパイラは、ユーザが十分な付与された権利を有していたそれらのリソースでのみ実行し続けることが可能になるだろう。
【０１０５】
コア機能１１４が任意の要素について失敗する（たとえば、論理１を設定する）と、この発明の実施例に従って、図１において１２２および１２４で示すように、スミザーズの上司へのメッセージが構築され、生成され、送られることができる。このメッセージは、１）ギズモ製品群の監査および支払に関連する保護されたデータリソースへのアクセスの試みをスミザーズの上司に伝えることができ、および／または２）図１において１２６で示すように、たとえば適切なＳＱＬクエリーを介してスミザーズの上司がギズモの請求書の記載事項にアクセスでき、ギズモの支払を承認できるのに十分な許可を付与する要求であり得る。たとえば、通常はギズモ製品群を扱う上司であるディザーズが病気で休む場合がある。その場合に、スミザーズの上司は、情報が欲しければ、ギズモ製品群の上司と連絡を取ることができ、ギズモ製品群にアクセスするための適切な許可が付与されることを要求できる。ここで適切な許可を備えるスミザーズの上司は次いで、等しいかまたはそれより小さなアクセス権をスミザーズに付与でき、それによって、ギズモ製品群にアクセスする権限をスミザーズに与える。スミザーズの許可の増大は、アップグレードおよびアップデートモジュール１２８の機能性を通じて実行され得る。
【０１０６】
アップグレードおよびアップデート
スミザーズがギズモ製品群の監査および請求書承認に関する保護されたデータリソースにアクセスできるようにするために、スミザーズの上司は、これらの保護されたデータリソースに対して十分な許可を付与されている場合に、要素ｆ、ｊ、ｋ、ｌ、ｍについてのスミザーズのＧＳＤＳ構造を
【０１０７】
【数９】
2008546114.tif 000011
【０１０８】
から
【０１０９】
【数１０】
2008546114.tif 000012
【０１１０】
にリセットするためにアップグレード機能１２８を利用し得る。
ｋおよびｍ要素識別子のビット値が二進数「０」から二進数「１」に設定されたことに注目されたい。これは、Ｕｓｅｒ＿ＩＤに対応するユーザが、これらの要素識別子にマッピングされる保護されたデータリソースにアクセスする権限を与えられることを示している。この場合、スミザーズのＧＳＤＳはここで、要素識別子ｋについて「１」を格納し、ギズモ製品群を監査する権限をスミザーズに与え、要素識別子ｍについて「１」を格納し、ギズモ製品群の支払を承認する権限をスミザーズに与える。スミザーズのアップグレードされたＧＳＤＳは付与データベース１０８に格納され得る。ここで、このプロセスを通じて再利用して、スミザーズは次いで、ギズモ製品群の監査および承認に関連する保護されたデータリソースにアクセスするよう構成される（たとえば）ＳＱＬクエリーを構築でき、このようなＳＱＬクエリーは実行が認められるであろうと期待する。ＳＱＬプリコンパイルモジュール１１２が実行した後、コア機能モジュール１１４が実行して、スミザーズのアップデートされたＧＳＤＳを、スミザーズのＳＱＬクエリーから得られる（好ましくは切捨てられた）ＲＳＤＳと比較する。今回は、ＲＳＤＳ構造における関連する要素識別子に対応するビット値は、スミザーズのＧＳＤＳにおける対応する要素識別子のビット値と厳密に等しい。この場合、スミザーズのＲＳＤＳがスミザーズのＧＳＤＳと等しいので、ギズモ製品群の監査および承認に関連する保護されたデータリソースについてスミザーズのＳＱＬクエリーを認めることが１１６において決定され得る。次いで、スミザーズのＳＱＬクエリーは、１１８において示すようにコンパイルおよび実行されることができ、この方法は１２０において終了する。ＳＱＬコマンドを実行するさらに他の試みはすべて、結果として生じるＲＳＤＳと付与データベース１０８におけるユーザのＧＳＤＳとの間の同一の比較を被ることになる。
【０１１１】
この例は、ユーザであるスミザーズが既に、クエリーに含まれる保護されたデータリソースをすべて知っていると仮定する。スミザーズがブラインドクエリー、ある範囲の値または勘の的中を使用する場合、スミザーズは、ユーザとしてスミザーズが特権を持たないオブジェクトについての情報を得るであろう。この発明の実施例は、任意のこのようなブラインドクエリー、範囲、またはクエリーにおける特定的でない参照を（たとえばＳＱＬプリコンパイラモジュール１１２において）検出するよう構成され得る。任意のこのようなクエリーのコンパイルおよび／または実行は認められない可能性があり、スミザーズの上司が適切な特権を有する場合には（たとえば）スミザーズの上司に直接にメッセージを送ることが可能であり、またはスミザーズの上司が適切な特権を持たない場合にはスミザーズがアクセスしようとした保護されたデータリソースの所有者にメッセージを送ることが可能である。この発明の実施例は、いずれの範囲またはオープンクエリーも要素の集まりに拡張し、ユーザが特権を持たない要素はアクセス／実行を禁じられる。許可を通すための要素は、対応するリソースが、認められる最終的なＳＱＬの結果を計算に入れる要素である。この保護されたデータリソースの所有者は次いで、このような保護されたデータリソースへのアクセス特権をスミザーズの上司に自由に付与でき、スミザーズの上司はそ
の後、一般的に保持される任意の特権および特にこの特権を自由に委任できる。現在所有している許可のレベルと等しいかまたはそれ未満の許可のみを委任できることが注目されるべきである。そうでなければ、スミザーズまたはスミザーズの上司は、特権がなかったオブジェクトについて知ることによって必知事項／仕事を行なう必要性の指針に違反することになるであろう。
【０１１２】
これは、勘が的中する見込みを残す。ギズモはギズモ製品群の明らかな修飾子であり、スミザーズは既にギズモが存在することを知っている。しかしながら、単なる推測のいずれのインスタンスについても、試行が繰り返される可能性があり、このような試行は監視され得る。この発明の実施例に従うと、失敗の繰返しは（たとえば）スミザーズの第１および第２のラインの上司に報告されるべきセキュリティ方針の違反に相当し得る。勘が的中する場合および試行が繰返される場合であっても、この発明の実施例が、無許可のアクセスを可能にする場合はない。
【０１１３】
図５は、この発明の実施例が実現され得るコンピュータシステム５００のブロック図を示す。コンピュータシステム５００は、情報を通信するためのバス５０１または他の通信メカニズムと、バス５０１と結合されて情報を処理するための１つ以上のプロセッサ５０２とを含む。コンピュータシステム５００は、バス５０１に結合されて、プロセッサ５０２によって実行されるべき情報および命令を格納するための（メインメモリと称される）ランダムアクセスメモリ（random access memory）（ＲＡＭ）または他の動的記憶装置５０４をさらに備える。プロセッサ５０２が命令を実行する間一時的な変数または他の中間情報を格納するためにメインメモリ５０４も使用されてもよい。コンピュータシステム５００は、バス５０１に結合されてプロセッサ５０２のための静的情報および命令を格納するためのリードオンリメモリ（read only memory）（ＲＯＭ）および／または他の静的記憶装置５０６も含む。磁気ディスクまたは光ディスクなどのデータ記憶装置５０７は、バス５０１に結合されて情報および命令を格納するためのものである。コンピュータシステム５００はさらに、バス５０１を介して、コンピュータユーザに情報を表示するためのディスプレイ装置５２１に結合され得る。英数字キーおよび他のキーを含む英数字入力装置５２２は典型的には、バス５０１に結合されて、情報およびコマンド選択をプロセッサ５０２に通信するためのものである。別のタイプのユーザ入力装置は、方向情報およびコマンド選択をプロセッサ５０２に通信するためおよびディスプレイ５２１上でカーソルの動きを制御するための、マウス、トラックボールまたはカーソル方向キーなどのカーソル制御装置５２３である。５２５において示すように、口頭入力を与えるためにマイクロフォンが使用されてもよく、ユーザのジェスチャーまたは手話を入力するためにカメラが使用されてもよい。
【０１１４】
この発明の実施例は、コンピュータシステム５００の使用ならびに／または本明細書において記載され、示されおよび主張される認証および許可を実現するための方法およびシステムを可能にする複数のこのようなコンピュータシステムに関連する。一実施例に従うと、本明細書に記載する方法およびシステムは、メモリ５０４に含まれる命令のシーケンスを実行するプロセッサ５０２に応答して１つ以上のコンピュータシステム５００によって与えられることができる。このような命令は、データ記憶装置５０７などの別のコンピュータ読み取り可能な媒体からメモリ５０４に読取られてもよい。メモリ５０４に含まれる命令のシーケンスを実行することによって、プロセッサ５０２はステップを実行し、本明細書に記載する機能性を有する。代替的な実施例では、この発明を実現するために、ソフトウェア命令の代わりにまたはソフトウェア命令と組合せられてハードワイヤード回路が使用されてもよい。したがって、この発明は、ハードウェア回路およびソフトウェアのいずれの具体的な組合せにも限定されない。
【０１１５】
先の詳細な説明はこの発明の好ましい実施例について記載してきたが、上の説明は単に
例示的なものであり、開示される発明を限定するものではないことが理解されるべきである。当業者は他の代替的な実施例を認識でき、すべてのこのような実施例はこの発明の範囲内に包含されると考えられる。
【図面の簡単な説明】
【０１１６】
【図１】この発明の実施例に従う、保護されたデータリソースへのアクセスを制御するための、コンピュータによって実現される方法の局面のフローチャートである。
【図２】この発明の実施例に従う、クエリーの実行を認めるためまたはクエリーの実行を拒否するために実行され得るステップを示すフローチャートである。
【図３】この発明の実施例に従う、保護されたデータリソースへのアクセスを制御するために実行され得る追加のおよび拡張されたステップを示す。
【図４】以下の「作業例」に従いかつこの発明の実施例に従う、ＧＳＤＳおよびＲＳＤＳデータ構造が基礎とし得る例示的なセキュリティデータ構造を示す。
【図５】この発明の実施例が実施され得る例示的なコンピュータのブロック図である。
【図１】
2008546114.tif 000013
【図２】
2008546114.tif 000014
【図３】
2008546114.tif 000015
【図４】
2008546114.tif 000016
【図５】
2008546114.tif 000017
【手続補正書】
【提出日】平成19年12月27日(2007.12.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データリソースへのユーザアクセスを制御するための、コンピュータによって実現される方法であって、
保護されるべき前記データリソースの一覧表を作成するステップを備え、前記保護されたデータリソースは少なくともファイルおよびプログラムを含み、前記方法はさらに、
各々の一覧表が作成されたファイルおよび各々の一覧表が作成されたプログラムにマッピングされる１つの要素を含む要求データ構造を生成するステップを備え、各要素は、前記一覧表が作成されたデータリソースにアクセスしかつ前記一覧表が作成されたデータリソースを使用するために必要な許可レベルに従って設定される要求値を格納するよう構成されており、前記方法はさらに、
各ユーザが、前記一覧表が作成されたデータリソースのいずれかにアクセスできるようにするために、複数のデータリソースの各々にマッピングされる１つの要素を含む権限付与データ構造を定義および格納するステップを備え、各要素は、前記一覧表が作成されたデータリソースにアクセスしかつ前記一覧表が作成されたデータリソースを使用するために前記ユーザに付与される複数の許可レベルのうちの１つに従って設定される付与値を格納するよう構成されており、前記複数の許可レベルは少なくとも使用、表示、修正および削除を含み、前記方法はさらに、
前記保護されたデータリソースのうち少なくとも１つへのユーザのアクセス要求を受取るステップと、
前記受取られたユーザのアクセス要求に応答して、前記権限付与データ構造と要求データ構造とを比較し、任意の一覧表が作成されたファイルへのアクセスおよび任意の一覧表が作成されたファイルの使用を制御し、要求値が前記権限付与データ構造の対応する要素の前記付与値よりも大きい前記要求データ構造の任意の要素にマッピングされる任意の一覧表が作成されたプログラムの使用を防ぐステップとを備える、方法。
【請求項２】
前記比較するステップは、ユーザ要求がアクセスを要求する一覧表が作成されたデータリソースにマッピングされる要素のみを含むように前記権限付与および要求データ構造を切捨てるステップを含む、請求項１に記載のコンピュータによって実現される方法。
【請求項３】
要求値が前記権限付与データ構造の対応する要素の前記付与値未満であるかまたは前記付与値と等しい前記要求データ構造の任意の要素にマッピングされる任意の保護されたデータリソースへのアクセスを前記受取られたユーザ要求によって認めるステップをさらに含む、請求項１に記載のコンピュータによって実現される方法。
【請求項４】
前記受取るステップは、データベースクエリーを含むユーザ要求で実行される、請求項１に記載のコンピュータによって実現される方法。
【請求項５】
前記アクセスを認めないステップは、前記データベースクエリーのコンパイルおよび実行を認めないステップを含む、請求項４に記載のコンピュータによって実現される方法。
【請求項６】
前記受取るステップは、ＳＱＬクエリーを含むユーザ要求で実行される、請求項１に記載のコンピュータによって実現される方法。
【請求項７】
前記定義および生成するステップは、ユーザを固有に識別する値を格納するよう構成されるユーザ識別フィールドを含む前記権限付与および要求データ構造で実行される、請求項１に記載のコンピュータによって実現される方法。
【請求項８】
前記比較するステップは、値が、前記生成される要求データ構造におけるユーザ識別フィールドの値と一致する前記ユーザ識別フィールドを含む権限付与データ構造を検索するステップを含む、請求項７に記載のコンピュータによって実現される方法。
【請求項９】
前記比較するステップは、権限付与データ構造の要素の値によって集合的に形成される付与二進数が要求データ構造の要素の値によって集合的に形成される要求二進数よりも大きくない限り、前記受取られたユーザ要求の実行を認めないステップを含む、請求項１に記載のコンピュータによって実現される方法。
【請求項１０】
前記要求データ構造のどの要素が前記権限付与データ構造の対応する要素未満である値を有するかを判断するステップをさらに含む、請求項９に記載のコンピュータによって実現される方法。
【請求項１１】
前記判断するステップは、前記要求データ構造の要素の値および前記権限付与データ構造の対応する要素の値に基づいてＸＯＲ演算を実行するステップを含む、請求項１０に記載のコンピュータによって実現される方法。
【請求項１２】
任意のデータ構造への認められないアクセスの各インスタンスをログするためのロギングステップをさらに含む、請求項１に記載のコンピュータによって実現される方法。
【請求項１３】
前記保護されたデータリソースへのアクセスが認められないときにより大きな許可を要求するためのメッセージを生成するステップをさらに含む、請求項１に記載のコンピュータによって実現される方法。
【請求項１４】
より大きな許可を要求するための前記メッセージが、選択された要素に対してより大きな権限が付与された状態で応答されるときに、前記権限付与データ構造における前記選択された要素の値をアップデートするステップをさらに含む、請求項１３に記載のコンピュータによって実現される方法。
【請求項１５】
前記定義および格納するステップは、ディレクトリ・サービス・マークアップ言語（Directory Services Markup Language）（ＤＳＭＬ）の形態で前記権限付与データ構造を表わすことによっておよびユーザデータとして前記権限付与データ構造を前記ユーザのデジ
タル証明書に入力することによって実行される、請求項１に記載のコンピュータによって実現される方法。
【請求項１６】
ユーザアクセスが制御されるべき複数の保護されたデータリソースを格納するデータベースを含むコンピュータシステムであって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサによって生成される複数のプロセスとを備え、前記プロセスは、
保護されるべきデータリソースの一覧表を作成するための処理論理を含み、前記保護されたデータリソースは少なくともファイルおよびプログラムを含み、前記プロセスはさらに、
各々の一覧表が作成されたファイルおよび各々の一覧表が作成されたプログラムにマッピングされる１つの要素を含む要求データ構造を生成するための処理論理を含み、各要素は、前記一覧表が作成されたデータリソースにアクセスしかつ前記一覧表が作成されたデータリソースを使用するために必要な許可レベルに従って設定される要求値を格納するよう構成されており、前記プロセスはさらに、
各ユーザが、前記一覧表が作成されたデータリソースのいずれかにアクセスできるようにするために、複数のデータリソースの各々にマッピングされる１つの要素を含む権限付与データ構造を定義および格納するための処理論理を含み、各要素は、前記一覧表が作成されたデータリソースにアクセスしかつ前記一覧表が作成されたデータリソースを使用するために前記ユーザに付与される複数の許可レベルのうちの１つに従って設定される付与値を格納するよう構成されており、前記複数の許可レベルは少なくとも使用、表示、修正および削除を含み、前記プロセスはさらに、
前記保護されたデータリソースのうち少なくとも１つへのユーザのアクセス要求を受取るための処理論理と、
前記受取られたユーザのアクセス要求に応答して、前記権限付与データ構造と要求データ構造とを比較し、任意の一覧表が作成されたファイルへのアクセスおよび任意の一覧表が作成されたファイルの使用を制御し、要求値が前記権限付与データ構造の対応する要素の前記付与値よりも大きい前記要求データ構造の任意の要素にマッピングされる任意の一覧表が作成されたプログラムの使用を防ぐための処理論理とを含む、コンピュータシステム。
【請求項１７】
前記比較するステップは、ユーザ要求がアクセスを要求する一覧表が作成されたデータリソースにマッピングされる要素のみを含むように前記権限付与および要求データ構造を切捨てるステップを含む、請求項１６に記載のコンピュータシステム。
【請求項１８】
機械読み取り可能な媒体であって、その上に命令のシーケンスを表わすデータを格納しており、前記命令のシーケンスは計算装置によって実行されると、前記計算装置に対して複数のステップを実行することにより複数の保護されたデータリソースへのユーザアクセスを制御させ、
前記複数のステップは、
保護されるべきデータリソースの一覧表を作成するステップを含み、前記保護されたデータリソースは少なくともファイルおよびプログラムを含み、前記複数のステップはさらに、
各々の一覧表が作成されたファイルおよび各々の一覧表が作成されたプログラムにマッピングされる１つの要素を含む要求データ構造を生成するステップを含み、各要素は、前記一覧表が作成されたデータリソースにアクセスしかつ前記一覧表が作成されたデータリソースを使用するために必要な許可レベルに従って設定される要求値を格納するよう構成されており、前記複数のステップはさらに、
各ユーザが、前記一覧表が作成されたデータリソースのいずれかにアクセスできるよう
にするために、複数のデータリソースの各々にマッピングされる１つの要素を含む権限付与データ構造を定義および格納するステップを含み、各要素は、前記一覧表が作成されたデータリソースにアクセスしかつ前記一覧表が作成されたデータリソースを使用するために前記ユーザに付与される複数の許可レベルのうちの１つに従って設定される付与値を格納するよう構成されており、前記複数の許可レベルは少なくとも使用、表示、修正および削除を含み、前記複数のステップはさらに、
前記保護されたデータリソースのうち少なくとも１つへのユーザのアクセス要求を受取るステップと、
前記受取られたユーザのアクセス要求に応答して、前記権限付与データ構造と要求データ構造とを比較し、任意の一覧表が作成されたファイルへのアクセスおよび任意の一覧表が作成されたファイルの使用を制御し、要求値が前記権限付与データ構造の対応する要素の前記付与値よりも大きい前記要求データ構造の任意の要素にマッピングされる任意の一覧表が作成されたプログラムの使用を防ぐステップとを含む、機械読み取り可能な媒体。
【請求項１９】
企業のデータリソースへのユーザアクセスを制御するための、コンピュータによって実現される方法であって、
保護されるべきデータリソースの一覧表を作成するステップを備え、前記保護されたデータリソースは少なくともファイルおよびプログラムを含み、前記方法はさらに、
一覧表が作成されたファイルごとおよび一覧表が作成されたプログラムごとに、前記一覧表が作成されたデータリソースにアクセスしかつ前記一覧表が作成されたデータリソースを使用するために必要な許可レベルを定義する要求値を割当てるステップと、
一覧表が作成されたファイルごとおよび一覧表が作成されたプログラムごとの前記要求値を要求データ構造に格納するステップと、
各ユーザが、前記一覧表が作成されたファイルおよびプログラムのいずれかにアクセスできるようにするおよび／または前記一覧表が作成されたファイルおよびプログラムのいずれかを使用できるようにするために、前記一覧表が作成されたファイルおよびプログラムの各々の付与値を含む権限付与データ構造を定義するステップとを備え、各付与値は複数の値の中から選択され、複数の値の各々は、前記一覧表が作成されたファイルおよびプログラムにアクセスしかつ前記一覧表が作成されたファイルおよびプログラムを使用する予め定められた権利を規定しており、前記方法はさらに、
前記一覧表が作成されたファイルおよびプログラムのうちの１つへのアクセス要求がユーザから受取られると、前記要求データ構造を前記ユーザの権限付与データ構造と比較し、アクセスが要求される前記データリソースの前記付与値が少なくとも対応する要求値と同じぐらい大きいときにのみ前記一覧表が作成されたファイルおよびプログラムのうちの１つへの前記アクセス要求の実行を認めるステップを備える、コンピュータによって実現される方法。
【請求項２０】
選択されたユーザが、委任された権限付与データ構造を定義し、委任された権限付与データ構造を前記企業の中の階層的に下位のユーザに割当てることを可能にするステップをさらに含み、前記定義されかつ割当てられる、委任された権限付与データ構造は、前記委任された権限付与データ構造を定義しかつ割当てた前記ユーザの前記権限付与データ構造の付与値よりも大きくない付与値を格納する、請求項１９に記載のコンピュータによって実現される方法。
【請求項２１】
前記可能にするステップは、各ユーザの権限付与データ構造の各付与値が、階層的により高いユーザに割当てられる権限付与データ構造の対応する付与値よりも大きくないように実行される、請求項２０に記載のコンピュータによって実現される方法。
【請求項２２】
選択されたデータリソースにアクセスするために許可レベルを上げるユーザの要求を付与し、対応して、前記要求を行なった前記ユーザの前記権限付与データ構造における前記
選択されたデータリソースの付与値を上げるステップをさらに含む、請求項１９に記載のコンピュータによって実現される方法。
【請求項２３】
前記ユーザが前記企業を去ったときにユーザの権限付与データ構造を取消すステップをさらに含む、請求項１９に記載のコンピュータによって実現される方法。
【請求項２４】
最初はデフォルトで、ユーザごとの権限付与データ構造の付与値を、可能な限り低い許可レベルを示す最低値にするステップをさらに含む、請求項１９に記載のコンピュータによって実現される方法。
【請求項２５】
ユーザごとの権限付与データ構造の付与値を、前記企業におけるユーザの地位の新しい状態を示しかつ新しい状態に適切な値にリセットするステップをさらに含む、請求項１９に記載のコンピュータによって実現される方法。
【国際調査報告】
2008546114.tif 000018
2008546114.tif 000019
2008546114.tif 000020
2008546114.tif 000021
2008546114.tif 000022