(57)【要約】【課題】接続点からストアのユーザ単位抽象を生成するシステムを提供すること。【解決手段】プリンシパルのアクセス許可に基づいて、階層的にセキュリティ保護された包含階層のビューセットをフィルタリングすることは、本発明の新規な特徴の１つである。本発明は、潜在的に異種のセキュリティ記述子を伴う複数のコンテナ階層に渡るこの集約体に対して操作し得るプリミティブの集まりを提供し得る。このモデルは、ドメイン内のすべてのアクセス可能アイテムを発見するためにコンテナ階層をトラバースする必要性を低減し得る。【選択図】図１
2006244485.tif 000002
【特許請求の範囲】
【請求項１】
データアクセスを容易にするシステムであって、
接続点からデータストアの抽象を生成するクエリコンポーネントと、
少なくとも１つの行レベルアクセス許可に基づいて抽象を制限する行レベルセキュリティコンポーネントと
を備えることを特徴とするシステム。
【請求項２】
前記データストアは階層に編成され、前記クエリコンポーネントは前記階層を超越することを特徴とする請求項１に記載のシステム。
【請求項３】
アクセス制御実施ポリシーに関連して使用される信頼できる識別確立システムを提供するコンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
【請求項４】
前記制限された抽象をレンダリングするレンダリングコンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
【請求項５】
前記行レベルセキュリティコンポーネントは、セキュリティポリシーを前記データストア内の少なくとも１つの行に関連付けることを特徴とする請求項１に記載のシステム。
【請求項６】
前記データストア内の各列は単一のオブジェクトを含むことを特徴とする請求項５に記載のシステム。
【請求項７】
前記セキュリティポリシーは、アクセス制御リスト（ＡＣＬ）およびセキュリティ記述子のうちの少なくとも１つであることを特徴とする請求項６に記載のシステム。
【請求項８】
前記オブジェクトは、階層構造に編成されたデータ要素およびコンテナのうちの少なくとも１つであることを特徴とする請求項７に記載のシステム。
【請求項９】
伝播が適切かどうか判断し、必要であれば前記セキュリティポリシーを前記階層のルートに設定し、前記階層内の少なくとも１つの子に前記セキュリティポリシーを伝播するコンポーネントをさらに備えることを特徴とする請求項８に記載のシステム。
【請求項１０】
前記セキュリティポリシーを伝播する前記コンポーネントは、前記オブジェクトに有効なセキュリティ記述子を計算するために、親のセキュリティ記述子および前記オブジェクトを知的に使用することを特徴とする請求項９に記載のシステム。
【請求項１１】
前記行レベルセキュリティコンポーネントはさらに、
セキュリティ記述子をセキュリティ記述子識別子（ＳＤＩＤ）にマップするセキュリティ記述子テーブルと、
前記ＳＤＩＤを前記ＳＤＩＤのハッシュ値にマップする単一インスタンステーブルと
をさらに備えることを特徴とする請求項１に記載のシステム。
【請求項１２】
前記ＳＤＩＤは、前記セキュリティ記述子を指す整数値であることを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記ハッシュ値はＳＨＡ−１ハッシュアルゴリズムを介して生成されることを特徴とする請求項１１に記載のシステム。
【請求項１４】
ユーザが自動的に実施されることを望む動作を診断しまたは推論するために確率的および／または統計ベースの分析を使用する人工知能（ＡＩ）コンポーネントをさらに備えることを特徴とする請求項１に記載のシステム。
【請求項１５】
請求項１に記載のシステムを実施するためのコンピュータ実行可能命令がその上に格納されたコンピュータ読取り可能媒体。
【請求項１６】
データストア内のデータにアクセス制御を提供するための方法であって、
前記データを階層構造に編成することと、
前記階層構造を超越することと、
前記階層構造のルートにセキュリティポリシーを設定することと、
親のセキュリティ記述子に少なくとも一部基づいて前記階層構造内の少なくとも１つの子に前記セキュリティポリシーを知的に伝播することと、
前記データストアの接続点抽象を生成することと、
前記抽象を前記行レベルセキュリティポリシーに少なくとも一部基づく前記データのサブセットに制限するように行レベルセキュリティポリシーを適用することであって、前記行レベルセキュリティポリシーは、ＡＣＬおよびセキュリティ記述子のうちの少なくとも１つを前記データストア内の少なくとも１つの行に関連付けることと
を備えることを特徴とする方法。
【請求項１７】
前記行レベルセキュリティポリシーを適用することに関連して使用される信頼できる識別確立システムを確立することをさらに備えることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記制限された抽象をレンダリングすることをさらに備えることを特徴とする請求項１７に記載の方法。
【請求項１９】
データストア内のデータのアクセス制御を容易にするシステムであって、
前記データをツリー状構造に編成する手段と、
前記ツリー状構造を超越する手段と、
前記ツリー状構造のルートにセキュリティポリシーを設定する手段と、
前記セキュリティポリシーを前記ツリー状構造内の少なくとも１つの子に知的に伝播する手段と、
親のセキュリティポリシーおよび前記子のセキュリティポリシーに少なくとも一部基づいて前記伝播されたセキュリティポリシーを適用する手段と、
１つまたは複数のセキュリティポリシーに少なくとも一部基づいて前記データストアの接続点抽象をフィルタリングする手段であって、前記１つまたは複数のセキュリティポリシーは前記データストア内の少なくとも１つの列に関連する手段と
を備えることを特徴とするシステム。
【請求項２０】
前記行レベルセキュリティポリシーの適用に関連して使用される信頼できる識別確立システムを確立するための手段をさらに備えることを特徴とする請求項１９に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムに関し、より具体的には、階層的に安全なストレージシステム内に維持されたデータの発見可能性に関する。
【背景技術】
【０００２】
ストレージシステムは従来、格納の単位を編成するために包含の階層を使用する。これらのシステムによれば、コンテナ、およびしたがって本質的にはコンテナ内に維持されるデータの単位は、プリンシパルへのアクセス提供を容易にするために独立にセキュリティ保護することができる。従来のシステムは、プリンシパルへアクセスできないコンテナに遭遇するとデータへのアクセスを制限し得るトラバーサルによって発見可能性を提供する。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
これらのシステムには、少なくとも以下の制限がある。１つの制限は、プリンシパルが、それがアクセスを有するデータのグローバルなセットを視覚化できないことである。換言すると、データのグローバルセットをレンダリングすると、ユーザがアクセスをもたないコンテナに遭遇する場合には、このコンテナのコンテンツ（データ単位など）はレンダリングされ得ない。サブフォルダまたはサブコンテナが、プリンシパルにアクセス制限が課されているコンテナ内に存在している状況について考慮されたい。このシナリオでは、プリンシパルは、十分な許可が整っている場合でも、そのサブフォルダのコンテンツを視覚化し（たとえば発見し）またはそれにアクセスし得ない。この制限的な発見可能性は、親フォルダにアクセスするのに十分な許可が欠如しているためである。
【０００４】
従来システムの別の制限は、プリンシパルがすべてのデータに対して一度に操作を行うことができないことである。たとえば、「所与のノードにルートをもつツリー状構造内のすべてのデータについてFABRIKAM＼aliceへのアクセスを許可する」などの操作についての制約は、ツリー状構造内のデータの一部へのアクセスを制限する制約が存在し得るので不可能である。従来のシステムによっては、こうした操作は、システムのコンテキストではなく、ユーザのコンテキストで行われる。
【０００５】
また、一部の従来システムの別の制限は、データにアクセスするには、格納単位へのアクセス許可に加えて、データ単位の直接の親への接続点からのすべてコンテナについて十分な許可が整っていることが必要であることである。換言すると、システムによっては、データの直接のファイルパスが知られている場合でも、接続点から、データが格納されている直接の親へのアクセス許可が存在しないならば、そのデータへのアクセス許可は制限され得る。
【０００６】
さらに、別の制限は、既存のファイルシステムモデル上の有効な列挙について従来のストレージシステムは、データとメタデータを区別することである。豊富なエンドユーザ型では、この分離は、メタデータとデータの間の区別を認識することの難しさをもたらす。
【課題を解決するための手段】
【０００７】
以下は、本発明のいくつかの態様についての基本的な理解をもたらすために、本発明についての簡略化された要約を提示している。この要約は、本発明についての広範な概要ではない。本発明の重要な／重大な要素を識別し、または本発明の範囲を示すためのものではない。その唯一の目的は、後に提示されるより詳細な説明への前置きとして、本発明のいくつかの概念を簡略化された形で提示することである。
【０００８】
本明細書で開示され、特許請求される本発明は、その一態様では、接続点からストアのユーザ単位の抽象を生成するシステムを備える。この抽象は、適用可能な許可に従って、階層的に安全なストレージシステム内に維持されたデータの発見可能性を促進し得る。プリンシパルのアクセス許可に基づいて、階層的にセキュリティ保護された包含構造からビューセットをフィルタリングすることは、本発明の新規な特徴の１つである。本発明は、潜在的に異種のセキュリティポリシー（セキュリティ記述子など）を伴う複数のコンテナ階層に渡るこの集約体に作用し得るプリミティブの集まりを提供することができる。このモデルは、ドメイン内のすべての読取りアクセス可能アイテムを発見するためにコンテナ階層をトラバースする必要性を低減させ得る。
【０００９】
また、別の態様では、人工知能（ＡＩ：ａｒｔｉｆｉｃｉａｌ  ｉｎｔｅｌｌｉｇｅｎｔ）コンポーネントが提供され、この人工知能コンポーネントは、ユーザが自動的に実施されることを望む動作を診断しまたは推論するために確率的および／または統計ベースの分析を使用する。
【００１０】
上記および関連の目的を達成するために、本発明の特定の例示的な態様について、以下の説明および添付の図面に関連して本明細書で述べる。しかし、これらの態様は、本発明の原理が使用され得る様々なやり方のうちのいくつか示唆するものにすぎず、本発明は、すべてのこうした態様およびその等価物を含むものである。本発明の他の利点および新規な特徴は、図面と併せて考慮すれば、本発明についての以下の詳細な説明から明らかになる。
【発明を実施するための最良の形態】
【００１１】
本発明について、次に図面を参照して述べる。図面では、同じ参照番号は、全体を通して同様の要素について言及するために使用されている。以下の説明では、説明の目的により、本発明についての完全な理解をもたらすため、複数の具体的な詳細について述べられている。しかし、本発明は、これらの具体的な詳細なしに実施され得ることが明らかであり得る。他の場合では、本発明についての説明を容易にするために、よく知られている構造および装置がブロック図の形で示されている。
【００１２】
本出願では、用語「コンポーネント」および「システム」は、コンピュータ関連のエンティティ、ハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアを指すものである。たとえば、コンポーネントは、それだけに限らないが、プロセッサ上で実行されるプロセス、プロセッサ、オブジェクト、実行可能物、実行スレッド、プログラムおよび／またはコンピュータであり得る。例を挙げると、サーバ上で実行されるアプリケーションとサーバの両方がコンポーネントであり得る。１つまたは複数のコンポーネントはプロセスおよび／または実行スレッド内に常駐することができ、コンポーネントは、１つのコンピュータ上でローカライズされ、および／または２つ以上のコンピュータ間で分散され得る。
【００１３】
本明細書では、用語「推論する」または「推論」は一般に、イベントおよび／またはデータを介して捕捉される１組の観察から、システム、環境および／またはユーザの状態について考えまたは推論するプロセスを指す。推論は、特定のコンテキストまたは動作を識別するために使用されることができ、あるいはたとえば状態に関する確率分布を生成することができる。推論は、確率的であり、すなわちデータおよびイベントについての考慮に基づく興味の状態に関する確率分布の計算であり得る。推論は、１組のイベントおよび／またはデータからより高いレベルのイベントを構成するために使用される技術をも指し得る。こうした推論は、イベントが一時的な極めて近くで相関するかしないかに拘らず、またイベントおよびデータが１つまたは複数のイベントおよびデータソースから生じるかどうかに拘らず、１組の観察されたイベント、および／または格納されたイベントデータからの新しいイベントまたは動作の構成をもたらす。
【００１４】
本発明の態様は、コンピュータシステムに関し、より具体的には、階層的に安全なストレージシステム内に維持されたデータの発見可能性に関する。上述したように、従来のストレージシステムには、セキュリティ関連の発見可能性の機構に関して制限がある。このため、新しいデータベース指向のファイルシステムは、豊富なクエリをサポートし、共通のデータ単位（連絡先など）についての体系化されたエンドユーザ型を提供し得る。これらの体系化されたエンドユーザ型は、データに関するアプリケーションの相互運用性を促進し、またそれを向上させ得る。
【００１５】
本発明は、データの階層表現を考慮に入れる。より具体的には、本発明は、データがそれぞれ異なるフォルダ内に「バケット化」され（ｂｕｃｋｅｔｉｚｅｄ）、その後にそれぞれ異なるコンテナ内に置かれ得ることを考慮に入れる。ユーザは、そのデータを編成するために、これらのコンテナを使用することができる。たとえば、データは、ピクチャ、音楽、文書などのカテゴリに編成（たとえばバケット化）され得る。さらに、これらのカテゴリは、コンテナにさらに編成され、それによってデータの階層表現を確立し得る。例を挙げると、ピクチャ内には、「マイファミリ」、「マイバケーション」、「マイウエディング」などが存在し得る。さらに、階層に従って、サブカテゴリも存在し得る。
【００１６】
この階層表現によれば、本発明は、セキュリティポリシー（セキュリティ記述子など）を各オブジェクトに関連付けることを容易にし得る。オブジェクトは、コンテナ内に含まれる任意のデータ要素、またコンテナ自体でもあり得ることが理解されよう。さらに、それぞれのオブジェクトは、テーブルの個々の行で表現され得る。この行ベースの表現は、以下の諸図面についての議論をもとによりよく理解されよう。
【００１７】
ある態様では、セキュリティ記述子は、データアクセスのためにこれらのオブジェクトの提供を可能にし得る。例を挙げると、本発明のある態様によれば、セキュリティポリシーは、グループ、「マイファミリ」内の任意の者によるアクセスを許可するように「マイバケーション」フォルダを設定することを容易にし得る。さらに、「マイバケーション」内でユーザは、サブフォルダ（「マイシアトル旅行」など）へのアクセスのため「マイファミリ」の特定のメンバにアクセスすることをさらに制限し得る。
【００１８】
従来のシステムによれば、ユーザが列挙アクセスを有していないフォルダに達するときに、データストアのアクセス可能な探索は、いずれの点でも終了する。Ｆ１がＦ２を含み、このＦ２がＦ３を含む階層について考慮されたい。すなわちユーザは、許可を与えられていないＦ２に達するときには、Ｆ３内のデータを見ることができない。ユーザはＦ３へのアクセスを有し得るとしても、Ｆ３は許可が整っていないＦ２内に含まれているので、従来システムは発見可能性を妨げる。すなわちこれは制限である。本発明は、ユーザが、許可が与えられ整っているデータストア内のすべてのデータを探索し（たとえば発見し）および／またはレンダリングするための統一的なアクセスを有することを可能にし、それによってその使用を可能にする。上述したように、この統一的なアクセスは、データストア内の各オブジェクトに関連するセキュリティポリシーを介して容易にされ得る。理解されるように、それぞれのセキュリティポリシーは、行レベルのアイテムに関連付けられ得る。
【００１９】
従来のファイルシステムは、ファイルを取り出すために２つのアクセスモードを使用する。まず、これらのシステムは、ユーザが十分なセキュリティ許可が存在するデータ要素を発見するための制限された発見方法を容易にする。もう一方は、完全な経路が知られており、アクセス許可が整っている場合にユーザがファイルにアクセスするための直接アクセス機構である。
【００２０】
２つの異種のモードに加えて、本発明は、セキュリティ信用証明書に基づくアクセスおよび発見を可能にするクエリモード（データストアフィルタリングなど）である第３のモードを使用し得る。従来のシステムとは異なり、本発明は、定義された、指定されたプロパティに基づいてすべてのデータに問合せを行い、またそのデータに対して操作を行うための機構を提供し得る。本発明を用いると、アクセス信用証明書が整っている限り、データは発見され、望まれるように操作され得る。
【００２１】
それによれば、本発明は、ツリー状構造（階層的なデータ編成など）のルートに設定され、ツリー状構造全体に渡って構造内のすべての子に伝播され得るセキュリティポリシー（セキュリティ記述子など）を可能にし得る。伝播されるセキュリティ記述子は、親のセキュリティポリシー、子のセキュリティポリシー、および／またはオブジェクトの型に基づき得ることに理解されたい。セキュリティポリシーの生成、およびツリー状構造全体に渡るその伝播をもたらす論理が使用され得る。以下に述べるように、規則ベースの論理および／または人工知能が、セキュリティポリシーの伝播のために使用され得る。
【００２２】
ユーザが新しいアイテムを作成するシナリオについて考慮されたい。このシナリオでは、継承され、子へと組み合わせられ得る親の特定のセキュリティポリシー（記述子など）が存在する。ある態様では、ユーザは、許可を伴うフォルダ（コンテナなど）を有することができ、オブジェクトが作成されるときに、そのオブジェクトについての許可は、同じであると見なされ得る。あるいは、新しく作成されたオブジェクトに伝播される許可は、そのフォルダについての許可、およびそのオブジェクトについての許可の両方に基づいて知的に判断され得る。上記内容は、新規革新の態様による継承の例である。
【００２３】
従来のファイルシステムでは、この伝播は不可能であることが理解されよう。そうではなく、従来のシステムによる許可を変更するために、管理者は、ツリー状構造のそれぞれの子をウォークスルーし、許可を適用可能として変更しなければならない。それとは異なり、本発明の態様によれば、ルートの許可が変更され（または確立され）るときに、許可は、子を含めて、ツリー状構造のすべてに自動的に伝播され得る。
【００２４】
一部の従来システムでは、セキュリティ許可は、更新時に「ユーザのコンテキスト」で伝播され得るにすぎないことに留意されたい。許可が後に変化する状況があるにも拘らず、従来システムは、これらの許可を自動的に更新し得ない。
【００２５】
本発明は、「システムのコンテキスト」で許可を伝播することができる。したがって、ユーザが、介入するフォルダへの許可を有していない場合でも、下位、下位の下位など、ツリー状構造について許可が整っているならば、これらの許可は本発明に従って伝播され得る。この態様は、上述のＦ１、Ｆ２およびＦ３の実施例について考慮することによってよりよく理解される。
【００２６】
実施例について続けると、Ｆ２について許可が整っていない場合でも、Ｆ３について許可が存在するならば、許可はＦ１からＦ３に伝播され得る。属性（ファイル名、サイズ、作成日など）とデータ（ファイルのコンテンツなど）の間を区別する以前のファイルシステムとは異なり、豊富なデータのシステム内では、属性とデータの間の判断は難しい。したがって、属性またはデータであるデータ要素に関係なく「アイテム」が作成され、「アイテム」単位にアクセス許可を与えるために使用される。したがって、本発明に関して、システムは２つの別個のセキュリティ許可を追跡する必要がないので、セキュリティモデルの管理は特に簡略化され得る。そうではなく、ある態様では、アイテム単位に２つの「読出し」許可および２つの「書込み」許可を使用するのではなく、１つだけの「読出し」許可または１つだけの「書込み」許可が使用される。
【００２７】
結果として、本発明は、許可が整っているすべてのデータの抽象をユーザが表示することを容易にし得る。このビューは、ストア全体に渡って定義され、引き続いてユーザにレンダリングされることができる。ビューは、接続点から見えるアイテムと、認められたセキュリティ許可のセットの交差部分として定義され得る。結果として、ユーザは、表示しおよび／またはアクセスするセキュリティ許可を有する対象の接続点より下のアイテムを表示しおよび／またはアクセスすることができる。
【００２８】
最初に図１を参照すると、ファイルストアのコンテンツ表現のレンダリングを容易にするシステム１００が示されている。一般にシステム１００は、クエリコンポーネント１０２と、行レベルセキュリティコンポーネント１０４とを含み得る。動作において、クエリコンポーネント１０２は、行レベルセキュリティコンポーネント１０４と共に、セキュリティポリシーまたは許可を満たすデータコンポーネント１０６内のアイテムを識別し得る。識別されると、結果として生じるデータセットは、ユーザおよび／またはアプリケーションにレンダリングされ得る。たとえば、上述したように、本発明は、ユーザへの表示を介して、結果として生じるセットをレンダリングし得る。
【００２９】
次に図２を参照すると、行レベルセキュリティコンポーネント１０４についてのより詳細なブロック図が示されている。具体的には、行レベルセキュリティコンポーネント１０４は、セキュリティ記述子テーブル２０２と、単一のインスタンステーブル２０４とを含み得る。これらの各テーブルについて、以下でより詳細に述べる。
【００３０】
セキュリティコンポーネント１０４は、行レベルセキュリティの実現をもたらし得る。ユーザがあるシェア（データコンポーネント１０６など）に接続するときに、それぞれのデータ型についての暗黙的なビュー定義が、接続の範囲内で定義され得る。本発明に文脈を追加するため、以下は、「連絡先」型についての例示的なビュー定義である。
【００３１】
【表１】
2006244485.tif 000003
【００３２】
それぞれのアイテムは、エンティティテーブル（２０２、２０４）内の行として格納される。上記の例示的な表現は、ストア内のアイテムのグローバルスコープから連絡先型のフィルタリングを行い得る。ユーザが対応する行内のセキュリティ記述子に従って読取り可能なアイテムだけを見るアクセス制御の次元は、フィルタリングに対して暗黙的である。
【００３３】
この実施例では、ビュー定義は、上記で識別される、連絡先であるアイテムにビューを制限する「ＷＨＥＲＥ」句を含み得る。この実施例の残りの部分は、接続点からのアイテムにアクセスを制限し得る。上記のビュー定義は、セキュリティ定義を含まないことを理解されたい。
【００３４】
上述したように、セキュリティ機構は、テーブル（２０２、２０４）内に格納された行レベルセキュリティの関数である。この機構は、ビューの下位のテーブルレベルで適用され、ビューに対する伝播効果をもつ。セキュリティが行単位でイネーブルされる場合、ユーザが読出しアクセスをもたない行は、クエリコンポーネント１０２によって提供される、結果として生じるセット内に現れない。
【００３５】
ファイルシステムモデルでは、それぞれの「アイテム」は行内にあり、それぞれの行は、それに関連するセキュリティを有する。行レベルのセキュリティ機構１０４は、ユーザが読出しアクセスをもたない行については、結果内に行が現れないように制限する。ビューは、クエリコンポーネント１０２に伝えられた定義が与えられると、（上記実施例と同様に）接続点に少なくとも一部基づいてレンダリング（ビュー表示など）を制限し得る。したがって、結果として生じるセットは、これら２つの制限の交差部分であり得る。これらのセキュリティ機構は、クエリの定義に対して暗黙的に行われ得ることが理解されよう。結果として、ユーザは、諸操作のいずれかからも保護され得る。
【００３６】
本発明は、テーブル（２０４など）内の各行のセキュリティ記述子をチェックする単一のインスタンス化機構を使用する。この単一のインスタンス化機構は、システムが各行を越えてチェックを実施しているように見えることを可能にする。行を越えたセキュリティ記述子の単一のインスタンス化は、この機構のチェックを効率的にし得る。例示的なセキュリティ記述子の代わりにセキュリティポリシー（アクセス制御リストなど）が使用され得ることが理解されよう。したがって、これらの追加の新規な態様は、本発明、およびそれに添付された特許請求の範囲の範囲内に含まれるものであることを理解されたい。さらに、上記でＡＣＬについて言及しているが、異質のセキュリティポリシーを使用する他の態様が存在することを理解されたい。これらの異質のセキュリティポリシーは、本開示、およびそれに添付された特許請求の範囲の範囲内に含まれるものである。
【００３７】
操作において、２つのテーブル（２０２、２０４）が維持される。すなわちセキュリティ記述子のテーブル２０２、およびセキュリティ記述子のハッシュ（ＳＨＡ−１など）とセキュリティ記述子定義（ＳＤＩＤ：ｓｅｃｕｒｉｔｙ  ｄｅｓｃｒｉｐｔｏｒ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）の間のマッピングの単一のインスタンステーブル。このＳＤＩＤは、一意の値であることが理解されよう。本発明によれば、単一のインスタンス化は、ストア内の各一意のセキュリティ記述子についてシステムがＳＤＩＤとセキュリティ記述子のハッシュの間のマップを維持する機構を指す。
【００３８】
したがって、それぞれの行について、セキュリティ記述子を格納するのではなく、それに対応するＳＤＩＤが格納される。ある態様では、ユーザは、アイテムを作成するときに、セキュリティ記述子を提供し、またはそれを空のままにしておく選択肢を有する。空のままにされる場合、セキュリティ記述子は、作成されるアイテムからの親から継承され得る。ユーザがセキュリティ記述子を明示的に提供することを選択する場合、システムは、アイテムを作成するため、明示的に定義された記述子を親のセキュリティ記述子とマージし得る。
【００３９】
新しいセキュリティアイテムのセキュリティ記述子が何であるか判断されると、それが既に存在するかどうか判断される。それが存在する場合は、既存の記述子が使用される。それが存在しない場合は、新しい記述子が保存される。
【００４０】
セキュリティ記述子が存在するかどうか判断するために、本発明は単一インスタンステーブル２０４を含み、このインスタンステーブルは、セキュリティ記述子の、セキュリティ記述子のハッシュ（ＳＨＡ−１ハッシュなど）へのマッピングを含む。したがって、同じセキュリティ記述子を伴う別のアイテムが存在するかどうか判断するために、その対象のセキュリティ記述子のハッシュが計算される。次いで、システムは、いずれかの行がセキュリティ記述子の同じハッシュ（ＳＨＡ−１など）を含むかどうか見るために、行を求めて単一のインスタンス化テーブル２０４に問合せを行う。一致が見られる場合、それが存在する確率は高い。
【００４１】
次いで、セキュリティ記述子が存在するかどうか確認するために、実際のセキュリティ記述子の比較が行われる。実際のセキュリティ記述子が同じでない場合、システムは、セキュリティ記述子を独立に格納する。非一意性を保証するため、システムはハッシュアルゴリズム（ＳＨＡ−１など）だけに依存することを理解されたい。換言すると、ハッシュ値が単一インスタンステーブル２０４内のハッシュ値に一致しない場合、セキュリティ記述子は存在しないと判断され得る。
【００４２】
セキュリティ記述子の３つのプロパティが存在する。すなわちハッシュ（セキュリティ記述子のバイナリに基づいて数学的に計算される値）、セキュリティ記述子自体（バイナリ）およびＳＤＩＤ（セキュリティ記述子を指す整数値）。それぞれの行について、システムは、セキュリティ記述子が関係する対象の特定の行のＩＤを格納する。次いで、単一インスタンステーブル２０４では、システムは、ハッシュ（ＳＨＡ−１など）とＳＤＩＤの間でマップする。セキュリティ記述子テーブル２０２では、システムは、ＳＤＩＤとバイナリの間でマップする。
【００４３】
したがって、単一インスタンステーブル２０４とセキュリティ記述子テーブル２０２が合わさって、ＳＨＡ−１からＳＤＩＤへ、バイナリへの完全なマッピングを提供する。事実上、これらの２つのテーブル（２０２、２０４）は、単一のインスタンス化チェックを行うために使用され得る。
【００４４】
セキュリティ記述子は、以下の論理形を有し得る。
【００４５】
【表２】
2006244485.tif 000004
【００４６】
上記の例では、Ｏ：は所有者を識別し、Ｇ：はグループを識別し、Ｄ：は任意アクセス制御リスト（ＤＡＣＬ：Ｄｉｓｃｒｅｔｉｏｎａｒｙ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  ｌｉｓｔ）（本開示の範囲内のセキュリティ記述子のセクション）を識別し、Ｓ：はシステムアクセス制御リスト（ＳＡＣＬ：Ｓｙｓｔｅｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｌｉｓｔ）を識別する。ＤＡＣＬは、それぞれが以下の形をとり得るアクセス制御エントリ（ＡＣＥ：Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｅｎｔｒｉｅｓ）の集まりである。
【００４７】
【表３】
2006244485.tif 000005
【００４８】
所与のプリンシパルは、特定のアイテムへのアクセスが許可され、または拒否され得る。したがって、拒否されたアイテムは、ユーザビューから暗黙的にフィルタリング除去され得る。フィルタリングエンジンまたはクエリコンポーネント１０２は、いずれのコンテナ意味論をも知り得ないストア内のすべてのアイテムをスキャンし、統一的なセットを生成し、それによって従来のファイルシステム内のトラバーサルの制限を回避し得る。
【００４９】
２つの内部テーブル（２０２、２０４）は、システム内の格納およびアクセス制御を容易するために使用され得る。例示的な態様では、システムは、[System.Storage.Store].[Table!SecurityDescriptorSingleInstance]テーブル２０４（インスタンステーブルなど）およびSys.Security_descriptorsテーブル２０２（セキュリティ記述子テーブルなど）を使用し得る。Sys.Security_descriptorsテーブル２０２は、セキュリティ記述子のカタログビューである。これらの記述子は、ＳＱＬサーバによって提供されるデータ定義言語（ＤＤＬ：ｄａｔａ  ｄｅｆｉｎｉｔｉｏｎ  ｌａｎｇｕａｇｅ）プリミティブを使用して作成され、または削除され得る。単一インスタンステーブル２０４は、システム内の中央処理装置ＣＰＵ（ｃｅｎｔｒａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）およびメモリ最適化に合わせ得る（ｋｅｙ  ｔｏ）。
【００５０】
ある態様によれば、かなりの数のアイテムが同じセキュリティポリシーまたは記述子を共有することは一般的であり得る。ある実施例では、アクセス制御リスト（ＡＣＬ）の最大サイズは６４ＫＢであり、したがって、所与のセキュリティ記述子は、約１２８ＫＢである。その共通性の度合いが潜在的に高いことを考慮すれば、このサイズの値を各アイテムと共に格納することは、非効率的であり得ることが理解されよう。したがって、各一意のセキュリティ記述子は、Sys.Security_descriptorsテーブル２０２内に格納されることができ、記述子とＳＨＡ−１ハッシュの間のマッピングは、単一インスタンステーブル２０４内に格納され得る。上述したように、ＳＨＡ−１は、出力の一意性を保証しないが、その大きい出力範囲（２160など）を考慮すれば、衝突の可能性は極めて低い。インスタンステーブル２０４は自己回復の性質を有するので、それは、システムが破損または不整合から自動的に回復し得ることを保証することができる。
【００５１】
アイテム／拡張／フラグメント／リンクテーブルは、ＳＥＣＵＲＩＴＹ属性でマーク付けされ得るＳＤＩＤのエントリを有する。これは、これらのテーブルへのすべての読出しアクセス、ならびにこれらのビューの上に作られる任意のビューが、（FILE_READ_DATA|FILE_READ_ATTRIBUTES）を要求するアクセスチェックの対象となることを保証し得る。アイテム拡張、リンク、およびアイテムフラグメントテーブルにおける行は、アイテムテーブル内の対応する行と同じセキュリティ記述子を有する。
【００５２】
上述の機構は、新しいファイルシステムの読出しパス内の許可モデルの中核にあると見なされ得る。いずれの許可モデルもが、認証モデルに本質的に依存し得る。ある実施例では、ユーザは、ストアに接続するときに、好ましいオペレーティングシステム認証機構（ＮＴＬＭ（ＮＴ  ＬＡＮマネージャ）、ケルベロスなど）を使用して認証され（たとえば信頼できると見なされ）得る。認証の最終結果は、ファイルシステムにアクセスしているユーザを表すセキュリティトークンであり得る。このトークンは、プリンシパルについての認証判断を行うために引き続き使用され得る。
【００５３】
本発明の別の態様によれば、行またはレコードレベルセキュリティ（ＲＬＳ：ｒｅｃｏｒｄ  ｌｅｖｅｌ  ｓｅｃｕｒｉｔｙ）を使用してセキュリティ保護されたアイテムは、ストレージサービスアカウントからも同様に保護され得る。セキュリティ評価のため、サービスアカウントは、他の任意のＮＴ−ブランドのアカウントと同様に見なされ得る。これは具体的には統一的なセキュリティ意味論を保証するが、それは、更新パスにおける興味深い問題を引き出す。たとえば、所与の名前空間名をもつアイテムを作成しようと試みるユーザについて考慮されたい。新しいファイルシステム内の名前空間名は、その包含フォルダにおいて一意であることが保証され、明白な名前付けシステムを提供する。作成操作の間、システムは、同じ名前空間名をもつ、同じフォルダ内の他のアイテムの非存在性を保証することによってこの一意性を保証する。
【００５４】
このシナリオでは、サービスアカウントへのアクセス許可が拒否されたフォルダ内にアイテムが既に存在することがある。本発明は、署名機構を使用することによってこの問題に対処し得る。ストアへのグローバルアクセスを必要とする更新プリミティブは、「ＲＬＳ免除」特権が与えられる証明書で署名され得る。こうしたプリミティブのコンテキスト内から、システムはストアに問合せを行うことができ、この場合には、行レベルセキュリティはバイパスされる。
【００５５】
上述したように、従来のファイルシステムは、トラバーサルの意味論を可能にするために、属性とデータの間の区別を行ってきた。発見可能性の欠如およびクエリベースの意味論は、アクセス制御決定のために属性とデータが区別されるモデルをもたらした。本発明は、型システム上の全か無かの意味論を促すことによって、データおよび属性へのシームレスなアクセスを提供する。
【００５６】
以下は、例示的なファイルシステムセキュリティモデルについての詳細な議論である。以下の議論は、複数の異種のシナリオにおけるコンポーネント機能について述べている。説明されるこれらのシナリオは、本発明に文脈を提供するために示されるものにすぎず、本発明、およびそれに添付された特許請求の範囲を決して限定するものではないことを理解されたい。
【００５７】
まずファイルシステムセキュリティモデルを参照すると、ある態様では、データは、ファイルシステム内の整合性の最小単を指し得る「アイテム」としてストア内に編成され得る。「アイテム」は、独立にセキュリティ保護され、シリアライズされ、同期され、コピーされ、バックアップされ／復元などされ得る。ファイルシステムアイテムはある型のインスタンスとして表されることができ、この型の祖先は、エンティティ型である型System.Storage.Itemであることが理解されよう。ファイルシステム内のすべてのアイテムは、アイテムの単一のグローバル範囲内に格納され得る。さらに、それぞれのアイテムは、所与のファイルシステムストア内のすべてのアイテムについて一意であることを保証される一意の識別子を有し得る。
【００５８】
次に図３を参照すると、システム３００が示されている。システム３００はこのセキュリティ議論の文脈に従うものであり、型システム３０２内のアイテムは、汎用コンテナ型（ｇｅｎｅｒｉｃ  ｃｏｎｔａｉｎｅｒ  ｔｙｐｅ）３０４、および複合アイテム型３０６のインスタンスとして分類され得る。汎用コンテナ３０４は、フォルダ、および他の任意の階層データの収集バケットをモデル化するために使用され得る。複合アイテム型３０６は、アプリケーションのデータの単一の論理単位をモデル化するために使用され得る。この型のインスタンスは、コピー、移動、同期などのような典型的なデータ操作のための全か無かの意味論を提供することができる。後者の例には、それだけに限らないが、メールメッセージ、ピクチャ、連絡先などが含まれる。（破線で示す）複合アイテム型３０６のインスタンスは、ファイルバックアイテム（ＦＢＩ：ｆｉｌｅ  ｂａｃｋｅｄ  ｉｔｅｍｓ）３０８および非ファイルバックアイテム（ｎＦＢＩ：ｎｏｎ−ｆｉｌｅ  ｂａｃｋｅｄ  ｉｔｅｍ）３１０としてさらに分類され得る。Ｗｉｎ３２ブランドアクセスは意味論的に、ＦＢＩおよび汎用コンテナに限定されることが理解されよう。
【００５９】
以下の包含階層（ツリー状の階層など）は、アイテムに適用される。汎用コンテナ３０４および複合アイテム３０６は、汎用コンテナを含めて、他の任意のアイテム型を含み得る。これらの追加の汎用コンテナ内のアイテムは、独立にセキュリティ保護されることもできる。ＦＢＩ３０８は、他のアイテムを含まず、したがって階層内の葉ノードを形成し得る。
【００６０】
次に図４を参照すると、ファイルシステム４００は、信頼の境界４０２の反対側に２つの主要コンポーネントすなわちストアコンポーネント４０４とクライアントコンポーネント４０６とを含み得ることが理解されよう。図示するように、ストアコンポーネント４０４は、Ｎを整数として、１からＮのオブジェクトコンポーネントを含み得る。オブジェクトコンポーネント１からＮは、個々に、または総称してオブジェクトコンポーネント４０８と称され得る。オブジェクト４０８の格納および取出しに対処するストアコンポーネント４０４は、ストアコンポーネント４０４とクライアントコンポーネント４０６の間の信頼できるファイルシステムのサブシステムを形成し得る。
【００６１】
プラットフォームにプログラミング意味論を提供し得るクライアントコンポーネント４０６は通常、ユーザプロセス内で実行される。ユーザは、接続時に認証され得ることが理解されよう。取り出されたオブジェクト４０８（アイテムなど）は、クライアント空間で具現化され得る。ある態様では、クライアントによるこれらのオブジェクト４０８へのセキュリティチェックまたはアクセス制約は実施されない。本発明によれば、ストアコンポーネント４０４は、コンポーネント４０４を格納するためにプログラミングコンテキストが持続される場合に、（アクセス制御コンポーネント４１０を介して）アクセス制御を実施することができる。以下は、ユーザ認証についての議論である。
【００６２】
ファイルシステム４００は、ファイルシステムストア４０４内に含まれるアイテム４０８に対して動作を実施し得るセキュリティプリンシパルの概念を公開し得る。本発明の態様では、セキュリティプリンシパルは、ユーザまたはセキュリティグループであり得る。したがって、セキュリティプリンシパルは、セキュリティ識別子（ＳＩＤ：ｓｅｃｕｒｉｔｙ  ｉｄｅｎｔｉｆｉｅｒ）によって表され得る。
【００６３】
図４に示すように、ファイルシステムサービスへの接続は、アクセス制御コンポーネント４１０によってうまく認証されるセキュリティプリンシパルのコンテキストにある。（たとえばアクセス制御コンポーネント４１０を介した）ファイルシステム認証は、オペレーティングシステム認証機構からの派生物であり得ることが理解されよう。たとえば、ファイルシステム認証は、ＳＱＬ（構造化照会言語：ｓｔｒｕｃｔｕｒｅｄ  ｑｕｅｒｙ  ｌａｎｇｕａｇｅ）セキュリティモデルで使用可能なＷｉｎｄｏｗｓ（登録商標）ブランド認証の派生物であり得る。たとえば、ＳＱＬは、ファイルシステム４００内でサポートされ得ないＳＱＬ認証と呼ばれる別の組込み型の認証機構を提供することが理解されよう。
【００６４】
この実施例について続けると、Ｗｉｎｄｏｗｓ（登録商標）ブランドユーザによって試みられる接続は、Ｗｉｎｄｏｗｓ（登録商標）ブランドによって提供されるケルベロス、ＮＴＬＭなどの認証サービスを利用しながら、ファイルシステム４００によって認証されることができる。この実施例では、認証されたユーザは、ストア４０４内の許可決定のために使用される、ＳＱＬ内の「パブリック」ロールにマップされる。ある態様では、組込み型アドミニストレータ（ＢＡ：ｂｕｉｌｔ−ｉｎ  ａｄｍｉｎｉｓｔｒａｔｏｒ）は、ＢＡにＳＱＬ管理特権を与えるＳＱＬアドミニストレータにマップされる。代替の態様では、ファイルシステム管理は、単にファイルシステムプリミティブを使用して構築され得る。したがって、代替の態様では、ＢＡはＳＬＱアドミニストレータのメンバではない。
【００６５】
認証の最終結果は、ファイルシステム４００にアクセスするプリンシパルを表すセキュリティトークンである。このデータ構造は、入りプリンシパルのＳＩＤ、およびプリンシパルがメンバであるすべてのグループのＳＩＤを含み得る。さらに、ユーザによって保持されるすべての特権は既定により、ファイルシステム４００に接続する間イネーブルされ得る。以下の議論を追いよりよく理解されるように、このトークンは引き続いて、許可決定を行うために使用され得る。
【００６６】
次に認証についての議論に移ると、上述したようにファイルシステム許可は、シェアレベルセキュリティおよびアイテムレベルセキュリティ上に構築され得る。この説明では、
「シェア」は、ストア４１０内のアイテム４０８のエイリアスを指し得る。ストア４１０が作成されるときに、既定のシェアは、ルートアイテムにエイリアスされて作成される。十分な特権を有するユーザは、ストア４１０内の任意の汎用コンテナ（アイテム４０８など）にエイリアスされたシェアを作成し得る。
【００６７】
ファイルシステムは、名前空間をローカルにまたはリモートに公開するために、普遍的な名前付け規則パスを使用し得る。したがって、ファイルシステムのクライアントはシェアに接続し、それによって、接続点は、名前の相対階層と共に、ファイルシステムオブジェクト４０８へのアドレッシング機構を構成する。
【００６８】
例を挙げると、ユーザがfooにアクセスするためにルートシェアに接続すると仮定する。したがって、アクセスは、＼＼MachineName＼StoreName＼RootShare＼...＼fooと現れる。同様に、AliceShareと呼ばれるシェアに接続されたユーザは、＼＼MachineName＼AliceShare＼...＼fooと同じオブジェクトにアクセスする。この実施例では、アイテム上の有効な許可は、接続されたシェアおよびアイテム上のセキュリティ記述子の関数であり得る。前者はシェアレベルのセキュリティを定義し、後者はアイテムレベルのセキュリティを定義することを理解されたい。これらの各セキュリティ機構に関する詳細、および有効なセキュリティ記述子を構成するための規則について以下で述べる。
【００６９】
シェアレベルセキュリティについての議論から始めると、本発明によるファイルシステムシェアは、Ｗｉｎｄｏｗｓ（登録商標）ブランドのシェアにいくらか類似する。ローカルおよびリモートアクセスについて統一的な意味論を提供するために、作成されるあらゆるファイルシステムシェアについて、ミラーリングシェアも作成され得る。シェアは、カタログストア内にアイテムとして格納されることができ、次の主題であるアイテムセキュリティを使用してセキュリティ保護可能であり得る。これらのアイテムおよびシェアに関する許可は、ローカルとリモートの両方のアクセスについての同じ統一的アクセス付与の意味論であり得る。
【００７０】
既定の許可は、アイテムに関して望まれるように付与され得る。たとえば、シェア内の異質のアイテムは、ユーザ特性（ローカルシステム組込み型アドミニストレータ、認証済み、インタラクティブなど）に関して適用されるそれぞれ異なる既定の許可を有し得る。
【００７１】
Ｗｉｎｄｏｗｓ（登録商標）ブランドのシェアに類似して、シェアセキュリティ記述子の既定の値は、LanManServer＼DefaultSecurity＼SrvsvcDefaultShareInfoのレジストリ設定を使用して構成可能である。
【００７２】
アイテムセキュリティ機構は、アクセス制御を行うためにセキュリティ記述子を使用し得る。したがって、ある態様では、セキュリティ記述子は、ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｇｒａｍ  ｉｎｔｅｒｆａｃｅ：アプリケーションプログラムインターフェース）によって、セキュリティ記述子定義言語の文字列形式で通信され、Sys.Security_Descriptors、セキュリティ記述子テーブル（図２の２０２）のＶＡＲＢＩＮＡＲＹカラムのもとに、パックされたバイナリ形式でデータベースに格納され得る。
【００７３】
上述したように、図２の２０２の新しいセキュリティ記述子テーブル、Sys.Security_Descriptorsは、ファイルシステム基本テーブル内の外部キーとして使用するための一意のＩＤ（ＳＤＩＤ）を有する、パックされたバイナリセキュリティ記述子として格納された各一意のセキュリティ記述子を保持するために存在する。たとえば、セキュリティ記述子テーブルは、以下のように現れ得る。
【００７４】
【表４】
2006244485.tif 000006
【００７５】
上記のセキュリティ記述子テーブルはセキュリティ記述子のバイナリ表現を使用しているが、本発明、およびそれに添付された特許請求の精神および範囲から逸脱せずに、適切な任意の表現が使用され得ることを理解されたい。
【００７６】
次にセキュリティ記述子および関連データの表現および格納についての議論を参照すると、上述したように、本発明はセキュリティ記述子関連の情報を保持し得る２つの内部テーブル−セキュリティ記述子テーブル（sys.security_descriptorsなど）、および単一インスタンステーブル（[System.Storage.Store].[Table!SecurityDescriptorSingleInstance]など）を使用する。
【００７７】
この実施例について続けると、Sys.security_descriptorsは、ＳＱＬによって維持されるカタログビューである。このバイナリは、ＳＤＩＤをもつ対応する行内に格納される。
【００７８】
単一インスタンステーブルは、ファイルシステムによって維持され得る。それは、バイナリセキュリティ記述子のハッシュの、上記のSys.security_descriptorsビューまたはテーブル内で識別されるＳＤＩＤへのマップを含む。ある実施例では、ＳＨＡ−１ハッシュが使用され得る。ある態様では、同じセキュリティ記述子を含む複数のアイテムが作成される場合、単一のエントリが両方のテーブル内に存在し得る。
【００７９】
上述したように、本発明の別の新規な特徴は、単一インスタンステーブルがかつて破損されている場合に、それは自己回復テーブルなので、破壊され得ることである。換言すると、破損が生じる場合、新しいテーブルが、単に新しいハッシュ値を作成し、それを適切なＳＤＩＤに関連付けることによって作成され得る。
【００８０】
ある態様では、アイテム／拡張／フラグメント／リンクテーブルは、「セキュリティ」属性でマーク付けされるＳＤＩＤのエントリを有し得る。これは、これらのテーブルへの任意の読出しアクセスし、ならびにこれらのビューの上に作られる任意のビューが、（FILE_READ_DATA|FILE_READ_ATTRIBUTES）を求めるアクセスチェックの対象となり得ることを保証することが理解されよう。アイテム拡張、リンク、およびアイテムフラグメントテーブルは、アイテムテーブルと同じセキュリティ記述子テーブルをもたなければならないことがさらに理解されよう。
【００８１】
図５は、本発明の態様による初期化の方法論を示している。説明を簡単にするために、本明細書でたとえばフローチャートの形で示された１つまたは複数の方法論は一連の行為として示され述べられているが、一部の行為は本発明に従って、本明細書で示し述べるものとは異なる順序で、および／またはそれと同時に生じ得るので、本発明は行為の順序によって制限されないことを理解されたい（ｕｎｄｅｒｓｔａｎｄ  ａｎｄ  ａｐｐｒｅｃｉａｔｅ）。たとえば、方法論は別法として、状態図でなど、相互に関連する一連の状態またはイベントとして表され得ることが当業者には理解されよう。さらに、図示されるすべての行為が、本発明による方法論を実施することを必要とされ得るとは限らない。
【００８２】
構築プロセス中にモデルデータベースを構築する間、セキュリティデータ構造体が初期化される。５０２で、テーブルが設定される。ある実施例では、テーブルの設定は、Sys.server_principals、Sys.database_principals、Sys.server_role_membersおよびSys.database_role_membersの設定を含み得る。５０４で、単一のインスタンステーブルが作成される。この実施例によれば、５０４で、[System.Storage.Store].[Table!SecurityDescriptorSingleInstance]が作成され得る。
【００８３】
５０６で、ルートセキュリティ記述子が作成される。このルートセキュリティ記述子は、ストアのルートに対応する（たとえばアドミニストレータは完全な制御を有する）。５０８で、アイテムレベルセキュリティ記述子が作成される。たとえば５０８で、墓石アイテム（ｔｏｍｂｓｔｏｎｅ  ｉｔｅｍ）のためのセキュリティ記述子が、管理者が完全な制御を有し、また認証ユーザが読出しアクセスを有するように作成され得る。５１０で、これらのエントリは、単一インスタンステーブルに追加される。
【００８４】
ファイルシステムは、ＡＣＬの継承をサポートし得る。たとえば、アイテム作成（CreateItemまたはCreateComplexItemなど）のときから、そのアイテムのセキュリティ記述子は、（もしあれば）供給されたセキュリティ記述子、親のセキュリティ記述子、アイテムの型、および呼出し側のトークン（ＮＴブランドトークンなど）を使用して作成され得る。
【００８５】
次にアクセスチェックについての議論を参照すると、すべての更新ＡＰＩは、[System.Storage.Store].[HasSecurityAccess]を呼び出すことによって適切なアクセスチェックを実施する。ＡＰＩは、呼出し側が、シェアレベルと、セキュリティ記述子（アイテム、レコードなど）レベルの両方で要求許可ビットを与えられることを保証する。ある具体的な態様では、（親の）セキュリティ記述子に対して実施されるアクセスチェックは、シェアに対して実施されるアクセスチェック（ＤＥＬＥＴＥ）とは異なる（FILE_DELETE_CHILD）。他の場合では、２つのアクセスチェックは、整合性があり得る。
【００８６】
この実施例について続けると、ツリー状構造全体に渡るＡＣＬ伝播は、（新しいＤＡＣＬまたはＳＡＣＬを伴う）SetItemSecurity、または新しい親を伴うMoveItemが呼び出されるときに実施され得る。呼出し側が操作の実施を許可されていることを保証するため適切なアクセスチェックが実施された後に、ＡＣＬ伝播は、ファイルシステムのコンテキストで行われ得る。ＡＣＬが更新されているサブツリー状構造に対しては、アクセスチェックは行われない。
【００８７】
本発明は、非同期および／または同期伝播を使用し得ることを理解されたい。以下は、同期伝播についての議論である。サブツリー状構造のルートは、複合アイテムとは無関係であることを理解されたい。そうではなく、サブツリー状構造のルートは、SetItemSecurityまたはMoveItemが呼び出されるノードを表す一般名称であることを理解されたい。
【００８８】
同期伝播によれば、ルートアイテムの新しいセキュリティ記述子が計算される。ＤＡＣＬまたはＳＡＣＬが更新されない場合、アイテム、拡張、フラグメントおよびリンクテーブルについてＳＤＩＤが更新され、システムは戻る。アイテムのサブツリー状構造全体が、そのアイテムから開始してロックされる。この実施例では、他のテーブル（拡張、フラグメント、リンク）をロックする必要はない。
【００８９】
次いで、上記行為内のすべてのアイテムを含む一時テーブルが作成され得る。一時テーブルは、以下の特性を有し得る。一時テーブルは、ContainerId、ItemIdおよびNewSdIdを含み得る。さらに、NewSdIdは最初に、サブツリー状構造のルートを除いて、すべてについてＮＵＬＬであり得る。
【００９０】
一時テーブル内の各エントリについて、新しい親ＳＤ、アイテムの型、および既存のアイテムＳＤを使用して、新しいＳＤが計算され得る。この実施例では、CreatePrivateObjectSecurityEx(SEF_AVOID_PRIVILEGE_CHECK|SEF_AVOID_OWNER_CHECK)が使用され得る。したがって、その新しい親ＳＤが計算されており、アイテムの新しいＳＤＩＤがＮＵＬＬである行を処理するたびに、一時テーブルは１レベルずつトラバースされ得る。この実施例によれば、これは、テーブルを一度に１レベル移動する。
【００９１】
反復の数は０（たとえばツリー状構造の深さ）である。２つの問題が考慮され得る。第１に、新しいセキュリティ記述子の計算が考慮され得る。第２に、すべての子についてのセキュリティ記述子の更新が考慮され得る。第２のシナリオでは、論理上の限界は０（たとえば子の数）である。第１のシナリオでは、必ずしもそうでないが、それは通常０（ツリーの深さ）である。必要であれば、新しいセキュリティ記述子が（単一インスタンスおよびSys.security_descriptorsテーブル内に）作成され得る。次いで、一時ＳＤＩＤテーブルは、一時テーブル内で更新される。最後に、アイテム、拡張、リンクおよびフラグメントテーブルが、一時テーブル内で計算されたデータを使用して更新され得る。
【００９２】
図６は、マスタテーブルビューに問合せを行うＴ／ＳＱＬ操作が、行レベルセキュリティによってＳＥＬＥＣＴステートメントのアクセス制御が実施されるユーザコンテキストで動作することを示している。さらに、ファイルシステムストア更新ＡＰＩへの呼出しは、ユーザコンテキストで行われ、しかし、システムコンテキストで実行される。したがって、この実装は、呼出し側の許可チェックを実施し得る。
【００９３】
図７は、本発明による１つまたは複数の特徴の自動化を容易にする人工知能（ＡＩ）を使用するシステム７００を示している。本発明は、（たとえばセキュリティポリシーの実施に関連して）その様々な態様を実施するために様々なＡＩベースの方式を使用し得る。たとえば、セキュリティ記述子が設定されるべきかどうか、およびそうである場合の使用するセキュリティのレベルを判断するためのプロセスは、自動の分類器システムおよびプロセスを介して容易にされ得る。さらに、単一のインスタンスおよびセキュリティ記述子テーブル（図２からの２０２、２０４）が複数の位置にリモートに配置される場合、比較のためどの位置が選択されるか判断するために、分類器が使用され得る。
【００９４】
分類器は、入力属性ベクトル、Ｘ＝（ｘ１，ｘ２，ｘ３，ｘ４，ｘｎ）を、入力があるクラスに属するという信頼度にマップする関数、すなわちｆ（ｘ）＝信頼度（クラス）である。こうした分類は、ユーザが自動的に実施されることを望む動作を診断しまたは推論するために、（たとえば分析の有用性およびコストを考慮する）確率的および／または統計ベースの分析を使用し得る。
【００９５】
サポートベクトルマシン（ＳＶＭ：ｓｕｐｐｏｒｔ  ｖｅｃｔｏｒ  ｍａｃｈｉｎｅ）は、使用され得る分類器の一例である。ＳＶＭは、可能な入力の空間内に、非トリガイベントからトリガ基準を分離しようとする超曲面を見つけることによって動作する。直感的にこれは、訓練データに近いがそれと同一ではないデータをテストするため、分類を正確なものにする。他の有向および無向モデルの分類手法には、たとえばナイーブベイズ、ベイジアンネットワーク、決定木、ニューラルネットワーク、ファジー論理モデルが含まれ、それぞれ異なる独立パターンを提供する確率的分類モデルが使用され得る。本明細書で分類は、優先度のモデルを開発するために使用される統計回帰をも包含する。
【００９６】
本明細書から容易に理解されるように、本発明は、（たとえば一般的な訓練データによって）明示的に訓練され、また（ユーザ振舞いを観察し、外因性の情報を受信することによって）暗黙的に訓練される分類子を使用し得る。たとえば、ＳＶＭは、分類器コンストラクタおよび特徴選択モジュール内の学習または訓練フェーズを介して構成される。したがって、分類子は、それだけに限らないが、所定の基準に従って判断することを含めて、複数の関数を自動的に学習し実施するために使用され得る。
【００９７】
次に図８を参照すると、開示されるアーキテクチャを実行するのに動作可能なコンピュータのブロック図が示されている。本発明の様々な態様についての追加の文脈を提供するために、図８および以下の議論は、本発明の様々な態様が実施され得る適切なコンピューティング環境８００についての簡潔で一般的な説明を提供するためのものである。本発明について１つまたは複数のコンピュータ上で実行され得るコンピュータ実行可能命令の一般的な文脈で上記で述べたが、本発明は、他のプログラムモジュールとの組合せ、および／またはハードウェアとソフトウェアの組合わせとして実施されることもできることが当業者には理解されよう。
【００９８】
一般にプログラムモジュールは、特定のタスクを実装し、または特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造体などを含む。さらに、本発明の方法は、それぞれが１つまたは複数の関連する装置に動作可能に結合され得る、単一のプロセッサまたはマルチプロセッサコンピュータシステム、ミニコンピュータ、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティング装置、マイクロプロセッサベースまたはプログラマブル家電などを含めて、他のコンピュータシステム構成で実施され得ることが当業者には理解されよう。
【００９９】
図示する本発明の諸態様は、通信ネットワークを介してリンクされたリモート処理装置によって特定のタスクが実施される分散コンピューティング環境内で実施されることもできる。分散コンピューティング環境内では、プログラムモジュールは、ローカルとリモートの両方のメモリ記憶装置内に置かれ得る。
【０１００】
コンピュータは一般に、様々なコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体は、コンピュータによってアクセスされ得る任意の使用可能な媒体とすることができ、揮発性と不揮発性、着脱式と固定式の両方の媒体を含む。限定するためではなく、例を挙げると、コンピュータ読取り可能媒体は、コンピュータ記憶媒体および通信媒体を備え得る。コンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造体、プログラムモジュールまたは他のデータなどの情報を格納するための任意の方法または技術で実装された揮発性と不揮発性、着脱式と固定式の両方の媒体を含む。コンピュータ記憶媒体には、それだけに限らないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタルビデオディスク（ＤＶＤ：ｄｉｇｉｔａｌ  ｖｉｄｅｏ  ｄｉｓｋ）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、あるいは所望の情報を格納するために使用されることができ、またコンピュータによってアクセスされることができる他の任意の媒体が含まれる。
【０１０１】
通信媒体は一般に、コンピュータ読取り可能命令、データ構造体、プログラムモジュールまたは他のデータを搬送波や他のトランスポート機構などの変調されたデータ信号として実施し、また任意の情報送達媒体を含む。用語「変調されたデータ信号」は、信号の情報を符号化するなどのやり方でその特性の１つまたは複数が設定されまたは変更された信号を意味する。限定のためではなく、例を挙げると、通信媒体には、有線ネットワークや直接有線接続などの有線媒体、ならびに音響、ＲＦ、赤外線などの無線媒体、および他の無線媒体が含まれる。上記内容のいずれかの組合せもまた、コンピュータ読取り可能媒体の範囲内に含まれるべきである。
【０１０２】
図８を再び参照すると、本発明の様々な態様を実施するための例示的な環境８００がコンピュータ８０２を含んでおり、コンピュータ８０２は、処理装置８０４と、システムメモリ８０６と、システムバス８０８とを含む。システムバス８０８は、それだけに限らないが、システムメモリ８０６を含めてシステム構成要素を処理装置８０４に結合する。処理装置８０４は、市販の様々なプロセッサのいずれかであり得る。デュアルマイクロプロセッサ、および他のマルチプロセッサアーキテクチュアもまた、処理装置８４０として使用され得る。
【０１０３】
システムバス８０８は、（メモリコントローラ付きのまたは無しの）メモリバス、周辺バス、および市販されている様々なバスアーキテクチュアのいずれかを使用したローカルバスにさらに相互接続され得る複数タイプのバス構造のいずれかであり得る。システムメモリ８０６は、読出し専用メモリ（ＲＯＭ：ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）８１０およびランダムアクセスメモリ（ＲＡＭ：ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）８１２を含む。起動時などにコンピュータ８０２内の要素間で情報を転送するのに役立つ基本のルーチンを含む基本入出力システム（ＢＩＯＳ：ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）はＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの不揮発性メモリ８１０内に格納される。ＲＡＭ８１２は、データをキャッシュするための静的ＲＡＭなどの高速ＲＡＭをも含み得る。
【０１０４】
コンピュータ８０２はさらに、内部ハードディスクドライブ（ＨＤＤ：ｈａｒｄ  ｄｉｓｋ  ｄｒｉｖｅ）８１４（ＥＩＤＥ、ＳＡＴＡなど）を含み、この内部ハードディスクドライブ８１４は、適切なシャーシ（図示せず）、（たとえば着脱式なディスケット８１８から読み出しまたはそこに書き込む）磁気フロッピー（登録商標）ディスクドライブ（ＦＤＤ：ｆｌｏｐｐｙ  ｄｉｓｋ  ｄｒｉｖｅ）８１６、および（たとえばＣＤ−ＲＯＭディスク８２２を読み出し、またはＤＶＤなどの他の高容量光媒体から読み出しまたはそこに書き込む）光ディスクドライブ８２０で外部使用するように構成されることもできる。ハードディスクドライブ８１４、磁気ディスクドライブ８１６および光ディスクドライブ８２０は、それぞれハードディスクドライブインターフェース８２４、磁気ディスクドライブインターフェース８２６および光ドライブインターフェース８２８によってシステムバス８０８に接続され得る。外部ドライブ実装のためのインターフェース８２４は、ユニバーサルシリアルバス（ＵＳＢ：Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）およびＩＥＥＥ１３９４インターフェース技術のうちの少なくとも１つまたは両方を含む。他の外部ドライブ接続技術は、本発明の企図の範囲内である。
【０１０５】
ドライブおよびその関連のコンピュータ記憶媒体は、データ、データ構造体、コンピュータ実行可能命令などの不揮発性記憶域を提供する。コンピュータ８０２では、ドライブおよび媒体は、任意のデータを適切なデジタル形式で格納することに対処できる。上記のコンピュータ読取り可能媒体についての説明は、ＨＤＤ、着脱式磁気ディスケット、およびＣＤやＤＶＤなどの着脱式光媒体に言及しているが、たとえばｚｉｐドライブ、磁気カセット、フラッシュメモリカード、カートリッジなど、コンピュータによって読出し可能な他のタイプの媒体もこの例示的なオペレーティング環境内で使用されることができ、またさらに、こうした媒体のいずれもが、本発明の諸方法を実施するためのコンピュータ実行可能命令を含み得ることを当業者には理解されたい。
【０１０６】
オペレーティングシステム８３０、１つまたは複数のアプリケーションプログラム８３２、他のプログラムモジュール８３４およびプログラムデータ８３６を含めて、複数のプログラムモジュールがドライブおよびＲＡＭ８１２内に格納され得る。オペレーティングシステム、アプリケーション、モジュールおよび／またはデータのすべてまたは一部は、ＲＡＭ８１２内にキャッシュされることもできる。本発明は、様々な市販のオペレーティングシステムまたはオペレーティングシステムの組合わせで実装され得ることが理解されよう。
【０１０７】
ユーザは、１つまたは複数の有線／無線入力装置、たとえばキーボード８３８、マウス８４０などの入力装置を介して、コンピュータ８０２にコマンドおよび情報を入力し得る。他の入力装置（図示せず）には、マイク、ＩＲリモート制御、ジョイスティック、ゲームパッド、スタイラスペン、タッチスクリーンなどが含まれ得る。これらのおよび他の入力装置はしばしば、システムバス８０８に結合された入力装置インターフェース８４２を介して処理装置８０４に接続されるが、たとえばパラレルポート、ＩＥＥＥ１３９４シリアルポート、ゲームポート、ＵＳＢポート、ＩＲインターフェースなどの他のインターフェースによって接続され得る。
【０１０８】
モニタ８４４または他のタイプの表示装置もまた、ビデオアダプタ８４６などのインターフェースを介してシステムバス８０８に接続される。モニタ８４４に加えて、コンピュータは、たとえばスピーカ、プリンタなど、他の周辺出力装置（図示せず）を一般に含む。
【０１０９】
コンピュータ８０２は、リモートコンピュータ８４８などの１つまたは複数のリモートコンピュータへの、有線および／または無線通信を介した論理接続を使用して、ネットワーク化された環境内で動作することができる。リモートコンピュータ８４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースの娯楽機器、ピアデバイス、または他の一般的なネットワークノードとすることができ、また簡略にするためにメモリ／記憶装置８５０だけが示されているが、コンピュータ８０２に関して上記で述べた要素の多くまたはすべてを一般に含む。図示する論理接続は、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ  ａｒｅａ  ｎｅｔｗｏｒｋ）８５２、および／またはより大規模なネットワーク、たとえば広域ネットワーク（ＷＡＮ：ｗｉｄｅ  ａｒｅａ  ｎｅｔｗｏｒｋ）８５４への有線／無線接続性を含む。こうしたＬＡＮおよびＷＡＮネットワーキング環境は、オフィス、企業では一般的であり、またすべてがグローバルな通信ネットワーク、たとえばインターネットに接続され得るイントラネットなどの企業規模のコンピュータネットワークを容易にする。
【０１１０】
ＬＡＮネットワーキング環境内で使用される場合、コンピュータ８０２は、有線および／または無線通信ネットワークインターフェースまたはアダプタ８５６を介してローカルネットワーク８５２に接続される。アダプタ８５６はＬＡＮ８５２への有線または無線通信を容易にすることができ、このＬＡＮは、無線アダプタ８５６と通信するためにその上に配置された無線アクセスポイントをも含み得る。
【０１１１】
ＷＡＮネットワーキング環境内で使用される場合、コンピュータ８０２はモデム８５８を含むことができ、またはＷＡＮ８５４上の通信サーバに接続され、あるいはインターネットによってなど、ＷＡＮ８５４を介して通信を確立するための他の手段を含む。内部または外部の、また有線または無線の装置であり得るモデム８５８は、シリアルポートインターフェース８４２を介してシステムバス８０８に接続される。ネットワーク環境内では、コンピュータ８０２に関して示したプログラムモジュール、またはその一部は、リモートメモリ／記憶装置８５０内に格納され得る。図示するネットワーク接続は例示的であり、コンピュータ間の通信リンクを確立する他の手段が使用され得ることが理解されよう。
【０１１２】
コンピュータ８０２は、無線通信内に動作可能に配置された任意の無線装置またはエンティティ、たとえばプリンタ、スキャナ、デスクトップおよび／またはポータブルコンピュータ、携帯情報端末、通信衛星、無線検出可能なタグに関連付けられた任意の装置または場所（キオスク、新聞売店、お手洗いなど）、および電話と通信するように動作可能である。これは、少なくともＷｉ−ＦｉおよびＢｌｕｅｔｏｏｔｈ（商標）無線技術を含む。したがって、通信は、従来のネットワークと同様に事前定義された構造、または単純に少なくとも２つの装置間のアドホック通信であり得る。
【０１１３】
Ｗｉ−Ｆｉすなわちワイヤレスフィデリティは、自宅のソファー、ホテルのベッド、または職場の会議室から無線でインターネットに接続することを可能にする。Ｗｉ−Ｆｉは、携帯電話で使用されるものと類似の無線技術であり、この無線技術は、たとえばコンピューティングなどの装置が基地局の範囲内のどこでも、戸内または戸外でデータを送受信することを可能にする。Ｗｉ−Ｆｉネットワークは、安全で信頼できる高速無線接続性を提供するために、ＩＥＥＥ８０２．１１（ａ，ｂ，ｇなど）と呼ばれる無線技術を使用する。Ｗｉ−Ｆｉネットワークは、コンピュータを互いに、インターネットに、また（ＩＥＥＥ８０２．３またはイーサネット（登録商標）を使用する）有線ネットワークに接続するために使用され得る。Ｗｉ−Ｆｉネットワークは、無免許の２．４および５ＧＨｚ無線帯域内で、たとえば１１Ｍｂｐｓ（８０２．１１ａ）または５４Ｍｂｐｓ（８０２．１１ｂ）データ転送速度で、あるいは両方の帯域（デュアルバンド）を含む製品と共に動作し、したがってネットワークは、多くのオフィスで使用される基本の１０ＢａｓｅＴ有線イーサネット（登録商標）ネットワークに類似の実世界のパフォーマンスを提供し得る。
【０１１４】
次に図９を参照すると、本発明による例示的なコンピューティング環境９００の概略ブロック図が示されている。システム９００は、１つまたは複数のクライアント９０２を含む。クライアント９０２は、ハードウェアおよび／またはソフトウェア（スレッド、プロセス、コンピューティング装置など）であり得る。クライアント９０２は、たとえば本発明を使用することによってクッキーおよび／または関連のコンテキスト情報を収容することができる。
【０１１５】
システム９００は、１つまたは複数のサーバ９０４をも含む。またサーバ９０４は、ハードウェアおよび／またはソフトウェア（スレッド、プロセス、コンピューティング装置など）であり得る。サーバ９０４は、たとえば本発明を使用することによって、変換を実施するためのスレッドを収容することができる。クライアント９０２とサーバ９０４の間の可能な１つの通信は、２つ以上のコンピュータプロセス間で送信されるように適応されたデータパケットの形であり得る。データパケットは、たとえばクッキーおよび／または関連のコンテキスト情報を含み得る。システム９００は、クライアント９０２とサーバ９０４の間の通信を容易にするために使用され得る通信フレームワーク９０６（たとえばインターネットなどのグローバル通信ネットワーク）を含む。
【０１１６】
通信は、（光ファイバを含めて）有線および／または無線技術を介して容易にされ得る。クライアント９０２は、クライアント９０２にとってローカルな情報（クッキーおよび／または関連のコンテキスト情報など）を格納するために使用され得る１つまたは複数のクライアントデータストア９０８に動作可能に接続される。同様に、サーバ９０４は、サーバ９０４にとってローカルな情報を格納するために使用され得る１つまたは複数のサーバデータストア９１０に動作可能に接続される。上記で述べた内容は、本発明の実施例を含む。もちろん、本発明について述べるため構成要素または方法論の考えられるあらゆる組合せについて述べることは不可能であるが、本発明のさらなる多くの組合せおよび置換えが可能であることが当業者には理解されよう。したがって、本発明は、添付の特許請求の範囲の精神および範囲内に含まれるこうしたすべての変更、修正および変形を包含するものである。
【図面の簡単な説明】
【０１１７】
【図１】本発明の一態様による、階層的な安全なストレージシステム内のデータの発見可能性を促進するシステムの一般的なコンポーネントブロック図である。
【図２】本発明の一態様による、単一のインスタンステーブルおよびセキュリティ記述子テーブルを含むシステムのブロック図である。
【図３】一態様による、型システム内のアイテムを汎用コンテナ型および複合アイテム型のインスタンスとして分類するシステムを示す図である。
【図４】本発明の一態様による、ストアコンポーネント、および信頼の境界の反対側のクライアントコンポーネントを含むシステムのブロック図である。
【図５】本発明の一態様による、初期化の方法論を示す図である。
【図６】本発明の一態様による、ビューに問い合わせる操作が、行レベルセキュリティによって選択ステートメントのアクセス制御が実施され得るユーザコンテキストで動作し得ることを示す関係図である。
【図７】本発明の一態様による、人工知能ベースの機構を使用するシステムのブロック図である。
【図８】開示されるアーキテクチュアを実行するように動作可能なコンピュータのブロック図である。
【図９】本発明による、例示的なコンピューティング環境の概略ブロック図である。
【符号の説明】
【０１１８】
１０２  クエリコンポーネント
１０４  行レベルセキュリティコンポーネント
１０６  データコンポーネント
【図１】
2006244485.tif 000007
【図２】
2006244485.tif 000008
【図３】
2006244485.tif 000009
【図４】
2006244485.tif 000010
【図５】
2006244485.tif 000011
【図６】
2006244485.tif 000012
【図７】
2006244485.tif 000013
【図８】
2006244485.tif 000014
【図９】
2006244485.tif 000015