(57)【要約】【課題】  個々の監査イベントに対して精細な度合いの制御を実行する能力を設けることにより、システム性能を最適化し、無関係の監査ノイズを低減することを可能にする。【解決手段】  個々の監査イベントに関心がある監査者のようなユーザは、所望の結果を得ることができるが、個々の監査イベントを内包するカテゴリにおけるその他の個々の監査イベント全ての結果を得なくても済む。加えて、ユーザ毎、またはシステム全体に対して監査を行うことができる。このように、監査者は、システムの他のユーザに対して確立された監査イベントには関係なく、監査イベントを自らに合わせて作成することができる。このように、システム全体に対する監査方針を確立する能力があり、その場合、システムのユーザは全て、システム全体の監査結果を得ることができる。【選択図】      図２
2009500769.tif 000002
【特許請求の範囲】
【請求項１】
プログラム・コードが格納されているコンピュータ読み取り可能媒体であって、該プログラムコードが計算機環境によって実行されると、前記計算機環境に以下のことを行わせる、即ち、
第１監査イベントと関連のある監査機能の実行のために、リモート・プロシージャ・コールを受信し、前記第１監査イベントを、複数の監査イベントから選択し、前記リモート・プロシージャ・コールを、前記計算機環境のエンティティによって、前記第１監査イベントを選択した結果として実行すること、および
前記監査機能を実行することによって、前記監査機能を、複数の監査サブカテゴリから成る監査カテゴリの第１監査サブカテゴリに適用すること、
を行わせる、コンピュータ読み取り可能媒体。
【請求項２】
請求項１記載のコンピュータ読み取り可能媒体であって、更に、プログラム・コードが格納され、該プログラムコードが計算機環境によって実行されると、前記計算機環境に、前記監査機能を実行した結果を前記エンティティに戻すこと、を行わせるコンピュータ読み取り可能媒体。
【請求項３】
請求項１記載のコンピュータ読み取り可能媒体において、前記第１監査サブカテゴリは、個別の監査イベントである、コンピュータ読み取り可能媒体。
【請求項４】
請求項１記載のコンピュータ読み取り可能媒体において、前記監査機能は、監査方針を設定し、前記監査機能を実行することにより、前記第１監査サブカテゴリを監査する、コンピュータ読み取り可能媒体。
【請求項５】
請求項１記載のコンピュータ読み取り可能媒体において、前記監査機能は監査方針を問い合わせ、前記監査機能を実行することにより、前記第１監査サブカテゴリの監査結果が得られる、コンピュータ読み取り可能媒体。
【請求項６】
請求項１記載のコンピュータ読み取り可能媒体において、前記監査機能を実行することにより、前記第１監査サブカテゴリの名称が得られる、コンピュータ読み取り可能媒体。
【請求項７】
請求項１記載のコンピュータ読み取り可能媒体であって、更に、プログラム・コードが格納され、該プログラムコードが計算機環境によって実行されると、前記計算機環境に以下のことを行わせる、即ち、
第２監査イベントと関連のある監査機能の実行のために、第２リモート・プロシージャ・コールを受信し、前記第２監査イベントを、前記複数の監査イベントから選択し、前記第２リモート・プロシージャ・コールを、前記計算機環境のエンティティによって、前記第２監査イベントを選択した結果として実行すること、および
前記第２監査イベントと関連のある監査機能を実行することにより、前記第２監査イベントと関連のある監査機能を、前記監査カテゴリの複数の監査サブカテゴリの各監査サブカテゴリに適用すること、
を行わせる、コンピュータ読み取り可能媒体。
【請求項８】
請求項７記載のコンピュータ読み取り可能媒体において、前記第２監査イベントと関連のある監査機能を実行することにより、前記監査カテゴリの監査サブカテゴリのリストが得られる、コンピュータ読み取り可能媒体。
【請求項９】
プログラム・コードが格納されているコンピュータ読み取り可能媒体であって、該プログラムコードが計算機環境によって実行されると、前記計算機環境に、
第１監査イベントと関連のある監査機能の実行のために、リモート・プロシージャ・コールを受信し、前記第１監査イベントを、複数の監査イベントから選択すること、および
前記監査機能を実行すること、
を行わせ、
前記複数の監査イベントは、前記計算機環境の第１ユーザのみと関連のあるユーザ毎監査イベントと、前記第１ユーザ、および前記コンピュータ環境のその他のユーザがいるのであれば、その各々と関連のあるシステム監査イベントとから成り、
前記リモート・プロシージャ・コールを、前記第１監査を選択した結果として実行する、コンピュータ読み取り可能媒体。
【請求項１０】
請求項９記載のコンピュータ読み取り可能媒体であって、更に、プログラム・コードが格納され、該プログラムコードが計算機環境によって実行されると、前記計算機環境に、前記監査機能を実行した結果を前記エンティティに戻すこと、を行わせる、コンピュータ読み取り可能媒体。
【請求項１１】
請求項９記載のコンピュータ読み取り可能媒体において、前記監査機能を実行することにより、一監査カテゴリにおける第１監査サブカテゴリに前記監査機能を適用させ、前記監査カテゴリが複数の監査サブカテゴリから成る、コンピュータ読み取り可能媒体。
【請求項１２】
請求項１１記載のコンピュータ読み取り可能媒体において、前記第１監査サブカテゴリは個別の監査詭弁とである、コンピュータ読み取り可能媒体。
【請求項１３】
請求項１１記載のコンピュータ読み取り可能媒体において、前記監査機能は、監査方針を設定し、前記監査機能を実行することにより、ユーザ毎に前記第１監査サブカテゴリを監査する、コンピュータ読み取り可能媒体。
【請求項１４】
請求項１１記載のコンピュータ読み取り可能媒体において、前記監査機能は監査方針を問い合わせ、前記監査機能を実行することにより、システム毎に前記第１監査サブカテゴリを監査する、コンピュータ読み取り可能媒体。
【請求項１５】
請求項１１記載のコンピュータ読み取り可能媒体において、前記監査機能は監査方針を問い合わせ、前記監査機能を実行することにより、ユーザ毎に前記第１監査サブカテゴリの監査の結果が得られる、コンピュータ読み取り可能媒体。
【請求項１６】
請求項１１記載のコンピュータ読み取り可能媒体において、前記監査機能は監査方針を問い合わせ、前記監査機能を実行することにより、システム毎に前記第１監査サブカテゴリの監査の結果が得られる、コンピュータ読み取り可能媒体。
【請求項１７】
請求項１１記載のコンピュータ読み取り可能媒体において、前記監査機能を実行することにより、前記第１監査サブカテゴリの名称が得られる、コンピュータ読み取り可能媒体。  
【請求項１８】
請求項９記載のコンピュータ読み取り可能媒体において、前記監査機能を実行することにより、ユーザ毎の方針を定義した前記計算機環境の各ユーザの一覧表が得られる、コンピュータ読み取り可能媒体。
【請求項１９】
計算機環境の第１ユーザに複数の監査イベントを公開するステップであって、前記複数の監査イベントは、前記計算機環境の第１ユーザのみと関連のあるユーザ毎監査イベントと、前記第１ユーザ、および前記コンピュータ環境のその他のユーザがいるのであれば、その各々と関連のあるシステム監査イベントとから成る、ステップと、
前記複数の監査イベントからの第１監査イベントの選択を受信するステップと、
前記第１監査イベントと関連のある監査機能の実行のために、リモート・プロシージャ・コールを実行するステップと、
前記リモート・プロシージャ・コールの実行に応答して、前記監査機能の実行結果を受信するステップと、
から成る、方法。
【請求項２０】
請求項１９記載の方法において、前記監査機能を実行することにより、複数の監査サブカテゴリから成る監査カテゴリの内第１監査サブカテゴリに前記監査機能を適用させる、方法。
【発明の詳細な説明】
【背景技術】
【０００１】
コンピュータ・システムは、その情報やサービス資源を不正なアクセスから保護するために、セキュリティ・ポリシーを実施する場合がある。このようなシステムは、例えば、ディレクトリやファイルへのアクセスまたはサーバ・イベントを監査し、このようなイベントをセキュリティ・ログに記録する。ログを見直すことにより、セキュリティ侵害を禁ずるのに役立つことがある。このようなシステムのユーザは、ある種のイベントを追跡するために、セキュリティ監査を構成することができ、他のイベントの追跡に先行することを決定することもできる。
【０００２】
セキュリティ・ポリシーは、複数のグループに分割することができ、各グループを以降「カテゴリ」と呼ぶことにする。セキュリティ・ポリシーの各カテゴリは、個々の監査イベントを含む。例えば、セキュリティ・ポリシーの１つのカテゴリは、オブジェクト・アクセス監査カテゴリとすることができる。オブジェクト・アクセス監査カテゴリは、例えば、ファイル・システム、レジストリ、およびカーネル・オブジェクトへのアクセスの個々のセキュリティ監査を含むことができる。このようなシステムでは、ユーザが個々の監査イベントの結果を欲しい場合、コンピュータ・システムにカテゴリ全体の監査を実行するように指令すればよく、その結果、当該カテゴリにおける各セキュリティ・イベントの監査が行われる。例えば、ユーザがファイル・システムへのアクセスを監査したい場合、ユーザはオブジェクト・アクセス・カテゴリの監査を教唆し、ファイル・システムならびにレジストリおよびカーネルへのアクセスの結果を得る。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
このようなシステムでは、ユーザがセキュリティ監査を細分して制御を実行することができない。即ち、ユーザは、レジストリやカーネル・アクセスのセキュリティ監査の結果には関心がなくても、ファイル・システムのセキュリティ監査だけを教唆することができない場合がある。この無関係のノイズは、望みもしないレジストリおよびカーネル・アクセスのセキュリティ監査を行うという形態をなし、不必要にシステム資源を消費し、最適なシステム性能を阻害する。
【課題を解決するための手段】
【０００４】
個々の監査イベントに対して精細な度合いの制御を実行する能力を設けることにより、システム性能を最適化し、無関係の監査ノイズを低減することができる。即ち、監査者(auditor)には、カテゴリ・レベルまたは個別監査イベント・レベルでセキュリティ監査を実行する選択肢を提供することができる。このようなシステムでは、例えば、ファイルシステムアクセスのような個々の監査イベントに関心がある監査者は、ファイルシステムアクセスの監査を内包するカテゴリにおけるその他の個々の監査イベント全ての結果を得なくても、所望の結果を得ることができる。
【０００５】
加えて、ユーザ毎またはシステム全体に対して監査を行うことができる。即ち、多数のユーザがある計算機環境では、監査者は、システム上で他のユーザの活動に対して生成した監査イベントには関係なく、個々のユーザに必要な特定の監視レベルに適した監査イベントを自らに合わせて作成することができる。このような計算機環境では、システム全体に対する監査方針を確立する能力が残っており、その場合、システムのユーザは全て、システム全体の監査結果を得ることができる。
【０００６】
監査方針は、ローカル・セキュリティ・オーソリティによって確立し実施することができる。監査者は、例えば、ユーザ公開アプリケーション・プログラミング・インターフェースにアクセスすることによって、監査方針を設定するかまたはこれに問い合わせることができる。このインターフェースは、各カテゴリ、サブカテゴリ、および利用可能な個々の監査イベントの設定、問い合わせ、および表示というような、全ての監査機能をユーザに表示することができる。監査者が機能および個々の監査イベント、サブカテゴリ、またはカテゴリを選択した後、リモート・プロシージャ・コールを実行し、ローカル・セキュリティ・オーソリティの安全環境にコールすることができる。ローカル・セキュリティ・オーソリティにおける監査機能を実行し、例えば、表示および監査者による検討のために結果を送ることができる。
【０００７】
以上の摘要および以下の詳細な説明を添付図面と関連付けて読むことにより、理解が深まる。図面に実施形態を示すが、特許請求の範囲は、図面に示す特定的な方法や手段に限定されるのではないことは言うまでもない。
【発明を実施するための最良の形態】
【０００８】
図１および以下の論述は、実施形態例を実施することができる、適した計算機環境１００について端的な全体的説明を行うことを意図している。ここで用いる場合、「計算機システム」、「コンピュータ・システム」、および「コンピュータ」という用語は、プログラム・コードおよび／またはデータを実行する、または、そうでなければ処理することができるプロセッサを備えている、いずれの機械、システム、またはデバイスをも指すこととする。計算機システムの例には、パーソナル・コンピュータ（ＰＣ）、ミニコンピュータ、メインフレーム・コンピュータ、シン・クライアント(thin client)、ネットワークＰＣ、サーバ、ワークステーション、ラップトップ・コンピュータ、ハンドヘルド・コンピュータ、プログラマブル消費者電子機器、マルチメディア・コンソール、ゲーム・コンソール、衛星受信機、セット・トップ・ボックス、自動現金預け払い機、アーケード・ゲーム、移動体電話機、パーソナル・ディジタル・アシスタント（ＰＤＡ）、およびその他のあらゆるプロセッサに基づくシステムまたは機械が含まれるが、限定の意図は全くない。「データ」という用語は、いずれの形式のいずれの情報をも意味し、コマンド、転送、通知、または要求が含まれる。「プログラム・コード」および「コード」という用語は、プロセッサによって実行またはそうでなければ処理されるあらゆる命令集合を意味する。プロセッサは、例えば、Ｊａｖａ仮想マシンのような、ランタイムまたは仮想マシンを含むことができる。
【０００９】
以下では汎用コンピュータについて説明するが、これは単なる一例に過ぎない。本発明は、ネットワーク・サーバ相互動作性(interoperability)および相互作用を有するシン・クライアント(thin client)上で動作することもできる。つまり、実施形態の例の中には、非常に少数または最少数のクライアント資源だけが設けられネットワーク形態でサービスに対応する環境、例えば、クライアント・デバイスが単にワールド・ワイド・ウェブに対するブラウザまたはインターフェースとして役割を果たすに過ぎないネットワーク状環境において実施できる場合もある。
【００１０】
必須ではないが、実施形態は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を通じて実施することができる。ＡＰＩは、開発者または検査者が用いるためにあり、および／またはネットワーク閲覧ソフトウェアに含まれている。ネットワーク閲覧ソフトウェアは、１つ又は２つ以上のコンピュータ（例えば、クライアント・ワークステーション、サーバ、またはその他のデバイス）によって実行するプログラム・モジュールのような、コンピュータ実行可能命令に関して記述されるのが一般的である。一般に、プログラム・モジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含み、特定のタスクを実行するか、または特定の抽象的データ・タイプを実現する。更に、機構は、ハンドヘルド・デバイス、マイクロプロセッサ・システム、マイクロプロセッサに基づくまたはプログラマブル消費者用電子機器、ミニコンピュータ、メインフレーム・コンピュータ等含む種々のコンピュータ・システム構成を用いて実用化できることは当業者には認められよう。また、本発明は、通信ネットワークを通じてリンクされているリモート処理デバイスがタスクを実行する分散型計算機環境においても実用可能である。分散型計算機環境では、プログラム・モジュールは、メモリ記憶装置を含むローカルおよびリモート・コンピュータ記憶媒体双方に配することができる。
【００１１】
図１は、本発明を実施することができる、適した計算機システム環境１００の一例を示すが、先に明らかにしたように、計算機システム環境１００は、適した計算機環境の一例に過ぎず、本発明の使用範囲や機能性について限定を示唆する意図は全くない。また、計算機環境１００は、動作環境例１００に示す構成要素のいずれの１つまたは組み合わせに関しても、何らかの依存性や必須要件を有するという解釈は行わないこととする。
【００１２】
図１を参照すると、本発明を実施するシステム例は、コンピュータ１１０の形態とした汎用計算機を含む。コンピュータ１１０の構成要素は、限定ではなく、演算装置１２０、システム・メモリ１３０、およびシステム・バス１２１を含むことができる。システム・バス１２１は、システム・メモリを含む種々のシステム構成要素を演算装置１２０に結合する。システム・バス１２１は、数種類のバス構造のいずれでもよく、メモリ・バスまたはメモリ・コントローラ、周辺バス、および種々のバス構造のいずれかを用いるローカル・バスを含む。限定ではなく一例として、このような構造には、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、改良ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子規格連合（ＶＥＳＡ）ローカル・バス、先進グラフィックス・ポート（ＡＧＰ）、および（Mezzanine バスとしても知られている）周辺素子相互接続（ＰＣＩ）バスが含まれる。
【００１３】
コンピュータ１１０は、通例、種々のコンピュータ読み取り可能媒体を含む。コンピュータ読み取り可能媒体は、コンピュータ１１０がアクセス可能な入手可能な媒体であればいずれでも可能であり、揮発性および不揮発性の双方、リムーバブル、および非リムーバブル媒体を含む。限定ではない一例をあげると、コンピュータ読み取り可能媒体は、コンピュータ記憶媒体および通信媒体から成ると考えられる。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、またはその他のデータというような情報の格納のために、あらゆる方法または技術で実施される、揮発性および不揮発性の双方、リムーバブル、および非リムーバブル媒体を含む。コンピュータ記憶媒体は、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、電気的消去可能プログラマブル・リード・オンリ・メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリまたはその他のメモリ技術、コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ−ＲＯＭ）、ディジタル・バーサタイル・ディスク（ＤＶＤ）またはその他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望の情報を格納するために用いることができしかもコンピュータ１１０がアクセス可能なその他のいずれの媒体も含むが、これらに限定されるのではない。通信媒体は、通例、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、またはその他のデータを、搬送波またはその他の移送機構のような変調データ信号において具体化し、あらゆる情報配信媒体を含む。「変調データ信号」という用語は、その特性集合の１つ又は２つ以上が、情報を信号内にエンコードするようなやり方で、変化している信号を意味する。限定ではなく、一例として、通信媒体は、有線ネットワークまたは直接有線接続というような有線媒体、ならびに音響、無線周波数（ＲＦ）、赤外線、およびその他のワイヤレス媒体というようなワイヤレス媒体を含む。前述のいずれの組み合わせも、コンピュータ読み取り可能媒体の範囲に当然含まれるものとする。
【００１４】
システム・メモリ１３０は、ＲＯＭ１３１およびＲＡＭ１３２のような揮発性および／または不揮発性メモリの形態で、コンピュータ記憶媒体を含む。基本入出力システム１３３（ＢＩＯＳ）は、起動中のように、コンピュータ２０内のエレメント間におけるデータ転送を補助する基本的なルーチンを含み、通例ＲＯＭ１３１内に格納されている。ＲＡＭ１３２は、通例、演算装置１２０が直ちにアクセス可能であるデータおよび／またはプログラム・モジュール、または現在これによって処理されているデータおよび／またはプログラム・モジュールを収容する。一例として、そして限定ではなく、図１は、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７を示す。ＲＡＭ１３２は、その他のデータおよび／またはプログラム・モジュールを収容することもできる。
【００１５】
また、コンピュータ１１０は、その他のリムーバブル／非リムーバブル揮発性／不揮発性コンピュータ記憶媒体も含むことができる。一例としてのみ、図１は、非リムーバブル不揮発性磁気媒体からの読み取りおよびこれへの書き込みを行なうハード・ディスク・ドライブ１４１、リムーバブル不揮発性磁気ディスク１５２からの読み取りおよびこれへの書き込みを行なう磁気ディスク・ドライブ１５１、ならびにＣＤ  ＲＯＭまたはその他の光媒体のようなリムーバブル不揮発性光ディスク１５６からの読み取りおよびこれへの書き込みを行なう光ディスク・ドライブ１５５を示す。動作環境の一例において使用可能なその他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶媒体には、限定する訳ではないが、磁気テープ・カセット、フラッシュ・メモリ・カード、ディジタル・バーサタイル・ディスク、ディジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭ等が含まれる。ハード・ディスク・ドライブ１４１は、通例、インターフェース１４０のような非リムーバブル・メモリ・インターフェースを介してシステム・バス１２１に接続され、磁気ディスク・ドライバ１５１および光ディスク・ドライブ１５５は、通例、インターフェース１５０のようなリムーバブル・メモリ・インターフェースによって、システム・バス１２１に接続する。
【００１６】
先に論じ図１に示すドライブおよびそれらと連動するコンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、およびコンピュータ１１０のその他のデータを格納する。図１では、例えば、ハード・ディスク・ドライブ１４１は、オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７を格納するように示されている。尚、これらの構成要素は、オペレーティング・システム１３４、アプリケーション・プログラム１３５、その他のプログラム・モジュール１３６、およびプログラム・データ１３７と同じでも異なっていても可能であることを注記しておく。オペレーティング・システム１４４、アプリケーション・プログラム１４５、その他のプログラム・モジュール１４６、およびプログラム・データ１４７は、ここで、少なくともこれらが異なるコピーであることを示すために、異なる番号が与えられている。ユーザは、キーボード１６２、および一般にマウス、トラックボールまたはタッチ・パッドと呼ばれているポインティング・デバイス１６１によって、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナ等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、ユーザ入力インターフェース１６０を介して、演算装置１２０に接続されている。ユーザ入力インターフェース１６０は、システム・バス１２１に結合されているが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）のようなその他のインターフェースおよびバス構造によって接続することも可能である。
【００１７】
モニタ１９１またはその他の形式の表示装置も、ビデオ・インターフェース１９０のようなインターフェースを介して、システム・バス１２１に接続されている。モニタに加えて、コンピュータは、スピーカ１９７およびプリンタ１９６のような、その他の周辺出力装置も含むことができ、これらは出力周辺インターフェース１９５を通じて接続することができる。
【００１８】
コンピュータ１１０は、リモート・コンピュータ１８０のような１つ又は２つ以上のリモート・コンピュータへの論理接続を用いて、ネットワーク環境において動作することも可能である。リモート・コンピュータ１８０は、パーソナル・コンピュータ、ハンドヘルド・デバイス、サーバ、ルータ、ネットワークＰＣ、ピア・デバイス、またはその他の共通ネットワーク・ノードとすることができ、通例、コンピュータ１１０に関して先に説明したエレメントの多くまたは全てを含むが、図１にはメモリ記憶装置１８１のみを示す。図１に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）１７１およびワイド・エリア・ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含むことができる。このようなネットワーク環境は、事務所、企業規模のコンピュータ・ネットワーク、イントラネットおよびインターネットにおいては、一般的である。
【００１９】
ＬＡＮネットワーク環境で用いる場合、コンピュータ１１０は、ネットワーク・インターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続する。ＷＡＮネットワーク環境で用いる場合、コンピュータ１１０は、通例、モデム１７２、またはインターネットのようなＷＡＮ１７３を通じて通信を確立するその他の手段を含む。モデム１７２は、内蔵でも外付けでもよく、ユーザ入力インターフェース１６０またはその他の適切な機構を介してシステム・バス１２１に接続することができる。ネットワーク環境では、コンピュータ１１０に関して図示したプログラム・モジュール、またはその一部は、リモート・メモリ記憶装置に格納することもできる。一例として、そして限定ではなく、図１は、リモート・アプリケーション・プログラム１８５がメモリ素子１８１上に常駐するものとして示している。尚、図示のネットワーク接続は一例であり、コンピュータ間で通信リンクを確立する他の手段も使用可能であることは認められよう。
【００２０】
コンピュータ１１０またはその他のクライアント・デバイスは、コンピュータ・ネットワークの一部として展開することができる。これに関して、本発明は、いずれの数のメモリまたは記憶ユニット、ならびにいずれの数の記憶ユニットまたはボリュームを跨って実行するいずれの数のアプリケーションおよびプロセスを有する、あらゆるコンピュータ・システムに関する。本発明の実施形態は、ネットワーク環境において展開され、外部または内部ストレージを有するサーバ・コンピュータおよびクライアント・コンピュータを備えている環境にも適用することができる。また、本発明は、プログラミング言語機能性、解釈、および実行機能を有する、単体の計算機にも適用することができる。
実施形態例
図２は、詳細監査方針(granular audit policy)を実施するコンピュータ２００のブロック図である。コンピュータ２００は、図１において記載したコンピュータ１１０または計算機環境１００とすることができる。加えて、コンピュータ２００はローカル・セキュリティ・オーソリティ(local security authority)２１０を含むことができる。ローカル・セキュリティ・オーソリティ２１０は、コンピュータ２００においてユーザの認証やログ・インを行うというような、セキュリティ機能を実行するサブシステムであって、保護されているのであればいずれでもよい。加えて、ローカル・セキュリティ・オーソリティ２１０は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）２２０を含むこともできる。ＡＰＩ２２０は、コンピュータ２００のユーザ、およびローカル・セキュリティ・オーソリティ２１０外部のコンピュータ２００上で走っているアプリケーションが直接非公開ＡＰＩ２２０にアクセスすることができないという意味では、「非公開」であると言える。非公開ＡＰＩ２２０は、監査関連リモート・プロシージャ・コール（ＲＰＣ：remote procedure call）インターフェース２２５を含むことができる。ＲＰＣインターフェース２２５は、インターフェースを、例えば、コンピュータ２００のオペレーティング・システムに公開するＡＰＩとすることができる。このように、ローカル・セキュリティ・オーソリティの監査方針の変更、問い合わせ、またはその他の機能は、監査関連ＲＰＣインターフェース２２５の公開によって実行することができる。
【００２１】
ローカル・セキュリティ・オーソリティ２１０に加えて、コンピュータ２００は、ユーザ公開（user-exposed）監査ＡＰＩ２５０を含む。ユーザ公開監査ＡＰＩ２５０は、ユーザ毎監査ＡＰＩ２６０およびシステム監査ＡＰＩ２７０の双方を含む。コンピュータ２００の監査者(auditor)は、ユーザ公開監査ＡＰＩ２５０を通じて、ローカル・セキュリティ・オーソリティ２１０内においてユーザ毎またはシステム監査方針を設定するまたは問い合わせるというような機能の実行を教唆することができる。加えて、コンピュータ２００では、ユーザ公開監査ＡＰＩ２５０を、ローカル・セキュリティ・オーソリティ２１０とは別個のエンティティとして示すが、代わりに、ユーザ公開監査ＡＰＩは、ローカル・セキュリティ・オーソリティ２１０ないに収容されるＡＰＩを取り囲むラッパ(wrapper)としてもよい。
【００２２】
監査者が、例えば、システム監査ＡＰＩ２７０から設定システム監査ＡＰＩをコールすると、オペレーティング・システムのようなコンピュータ２００上のエンティティが、このコールをローカル・セキュリティ・オーソリティ２１０に送ることができる。非公開ＡＰＩ２２０の１つ、更に具体的には、監査関連ＲＰＣインターフェース２２５の１つにアクセスして、監査者が望む監査設定を実施することができる。
【００２３】
ローカル・セキュリティ・オーソリティ２１０およびユーザ公開監査ＡＰＩについて、ここで更に詳しく説明する。
【００２４】
図３は、非公開ＡＰＩ２２０内に含めることができるローカル・セキュリティ・オーソリティ２１０および監査関連ＰＲＣインターフェース２２５のブロック図である。監査関連ＲＰＣインターフェース２２５は、設定セキュリティ監査方針ＲＰＣインターフェース２２６を含むことができる。設定セキュリティ監査方針ＲＰＣインターフェース２２６は、カテゴリ、サブカテゴリ、または個別監査イベント・レベルで、システムおよびユーザ毎監査方針双方の設定を可能にする。以下に、設定セキュリティ監査方針ＲＰＣインターフェース２２６の一例を示す。
【００２５】
【表１】
2009500769.tif 000003
監査関連ＲＰＣインターフェース２２５は、監査方針問い合わせＲＰＣインターフェース２２７を含むことができる。監査方針問い合わせＲＰＣインターフェース２２７は、カテゴリ、サブカテゴリ、または個別監査イベント・レベルで、システムまたはユーザ毎監査方針に問い合わせることを可能にする。監査方針問い合わせＲＰＣインターフェース２２７の一例を以下に示す。
【００２６】
【表２】
2009500769.tif 000004
監査関連ＲＰＣインターフェース２２５は、ユーザ毎方針を定義するユーザを列挙するＲＰＣインターフェース２２８を含むことができる。その一例を以下に示す。
【００２７】
【表３】
2009500769.tif 000005
監査関連ＲＰＣ２２５は、カテゴリ列挙ＲＰＣインターフェース２２９を含むことができる。カテゴリ列挙ＲＰＣインターフェース２２９は、例えば、オペレーティング・システムによって理解されるカテゴリのリストを列挙することを可能にする。カテゴリ列挙ＲＰＣインターフェース２２９の一例を以下に示す。
【００２８】
【表４】
2009500769.tif 000006
監査関連ＲＰＣ２２５は、サブカテゴリ列挙ＲＰＣインターフェース２３０を含むことができる。サブカテゴリ列挙ＲＰＣインターフェース２３０は、例えば、オペレーティング・システムによって理解されるサブカテゴリのリストを列挙することを可能にする。
【００２９】
【表５】
2009500769.tif 000007
監査関連ＲＰＣ２２５は、監査カテゴリの名称を調べるためのＲＰＣインターフェース２３１を含むことができる。その一例を以下に示す。
【００３０】
【表６】
2009500769.tif 000008
監査関連ＲＰＣ２２５は、監査サブカテゴリの名称を調べるためのＲＰＣインターフェース２３２を含むことができる。これは、個別の監査イベントとすることができ、その一例を以下に示す。
【００３１】
【表７】
2009500769.tif 000009
尚、監査関連ＲＰＣインターフェース２２５は、追加のＲＰＣインターフェースまたは代わりのＲＰＣインターフェースを含んでもよく、ここに記載し図３に示すものはこのようなインターフェースの例に過ぎないことは言うまでもない。例えば、監査関連ＲＰＣインターフェース２２５は、有効な監査方針にユーザについて問い合わせるＲＰＣインターフェース２３３を含むこともできる。即ち、このようなインターフェースは、個々のユーザについて、ユーザ毎およびシステムに対して設定した方針を考慮に入れて、有効な監査方針を示すことができる。
【００３２】
図４は、ユーザ公開監査ＡＰＩ２５０のブロック図である。既に説明したように、このようなＡＰＩは、ユーザ毎監査ＡＰＩ２６０およびシステム監査ＡＰＩ２７０を含むことができる。ユーザ毎監査ＡＰＩ２６０は、コンピュータ２００のようなシステムの監査者が、例えば、システムに対して設定した監査方針を有することなく、特定のユーザに望ましい監査方針を設定することを可能にする監査ＡＰＩである。このようなＡＰＩは、コンピュータ２００のような同じコンピュータの異なるユーザが、他のユーザに適用される監査方針には無関係に、監査者が選択した異なる監査方針を有することを可能とする。
【００３３】
ユーザ毎監査ＡＰＩ２６０の１つは、ユーザ毎設定監査方針２６１とすることができる。これは、指定したセキュリティ主導者(security principal)のために、１つ又は２つ以上のカテゴリ、サブカテゴリ、または個別監査イベントに対する監査方針を設定する。このようなＡＰＩのコール元即ちユーザは、本文書では「監査者」と呼び、監査方針を設定するアクセス特権を強調させることを監査者に要求してもよい。以下に、ユーザ毎設定監査方針２６１の一例を示す。
【００３４】
【表８】
2009500769.tif 000010
このＡＰＩのパラメータは下記を含む。
【００３５】
pSid: [in]  この関数が監査方針を設定する主導者のＳＩＤ（セキュリティ・アイデンティティ）へのポインタ。
【００３６】
pAuditPolicy: [in]  AUDIT_POLICY_INFORMATION構造のアレイへのポインタ。この構造のAUDITCATEGORYGUIDメンバは、無視してもよい。ユーザ毎監査方針は、このパラメータを通じて指定した全てのサブカテゴリまたは個々の監査イベントについて設定することができる。
【００３７】
PolicyCount: [in]  pAuditPolicyアレイにおける要素数を示す。
【００３８】
このＡＰＩに対する戻り値は、成功の場合にはTRUE、失敗の場合にはFALSEを含むことができる。加えて、GetLastError()関数を用いると、更に特定的なステータス・コードを得ることもできる。以下のステータス・コードを戻すことができる。
【００３９】
ERROR_NO_SUCH_USER:  特定のＳＩＤを有するユーザが存在しない。
【００４０】
ERRROR_INVALID_PARAMETER:  パラメータの形成が正しくない。pAuditPolicy情報構造における要素の内いずれの１つでも無効である場合、監査方針を設定しない。
【００４１】
ERROR_ACCESS_DENIED:  この動作を実行するために必要な特権またはアクセスが存在しない。
【００４２】
別のユーザ毎監査ＡＰＩ２６０は、ユーザ毎監査方針問い合わせ２６２としてもよい。これは、指定したセキュリティ主導者のために、１つ又は２つ以上のカテゴリ、サブカテゴリ、または個々の監査イベントに対して、監査方針に問い合わせる。このようなＡＰＩのコール元即ちユーザに、監査方針を設定するアクセス特権を強調させることを要求してもよい。以下に、ユーザ毎監査方針問い合わせ２６２の一例を示す。
【００４３】
【表９】
2009500769.tif 000011
ユーザ毎監査方針問い合わせ２６２のパラメータは下記を含む。
【００４４】
pSid: [in]  この関数が監査方針を問い合わせる主導者のＳＩＤ（セキュリティ・アイデンティティ）へのポインタ。
【００４５】
pSubCategoriesGuids: [in]  ユーザ毎監査方針を検索しなければならないSubCategoryGuidesのアレイへのポインタ。指し示すGUIDSの総数はPolicyCountである。
【００４６】
PolicyCount: [in]   pSubCategoriesGuidesによって指し示されるGUID要素の計数から成るULONG。これは、ppAuditPolicyから戻されるAUDIT_POLICY_INFORMATION要素の数でもある。
【００４７】
ppAuditPolicy: [out]   AUDIT_POLICY_INFORMATION構造のアレイを戻すために割り当てられた１つのブロック・バッファへのポインタ。要素の総数はPolicyCountである。ユーザ毎監査方針を検索して、pSubCategoryGuidsを通じて指定したサブカテゴリ全てを求める。各サブカテゴリと関連があるカテゴリも、AuditCategoryGuidを通じて検索し、受け渡す。バッファ内のポインタは、割り当てられた１つのブロック内部の位置へのポインタである。AuditFreeをコールすることにより、戻された１つのバッファを解放することができる。
【００４８】
このＡＰＩに対する戻り値は、成功の場合TRUE、失敗の場合FALSEを含むことができる。GetLastError()関数を用いれば、更に特定的なステータス・コードを得ることができる。以下のステータス・コードを戻すことができる。
【００４９】
ERROR_ACCESS_DENIED:  この動作を実行するために必要な特権またはアクセスが存在しない。
【００５０】
ERROR_INVALID_PARAMETER:  パラメータの形成が正しくない。
【００５１】
ERROR_FILE_NOT_FOUND；pSidが指定したユーザに対して、ユーザ毎方針が存在しない。
【００５２】
別のユーザ毎監査ＡＰＩ２６０は、有効方針算出２６３としてもよく、これは、システム監査方針をユーザ毎方針と組み合わせることによって、セキュリティ主導者のために、１つ又は２つ以上のカテゴリ、サブカテゴリ、または個々の監査イベントに対する有効な監査方針を算定する。このようなＡＰＩのコール元即ちユーザに、監査方針を設定するアクセス特権を強調させることを要求してもよい。以下に、有効方針算出２６３の一例を示す。
【００５３】
【表１０】
2009500769.tif 000012
このＡＰＩのパラメータは下記を含む。
【００５４】
pSid: [in]  この関数が有効な監査方針を問い合わせる主導社のＳＩＤ（セキュリティ・アイデンティティ）へのポインタ。
【００５５】
pSubCategoriesGuids: [in]  有効監査方針を検索しなければならないSubCategoryGuidesのアレイへのポインタ。指し示すGUIDSの総数はPolicyCountである。
【００５６】
PolicyCount: [in]   pSubCategoriesGuidesによって指し示されるGUID要素の計数から成るULONG。これは、ppAuditPolicyから戻されるAUDIT_POLICY_INFORMATION要素の数でもある。
【００５７】
ppAuditPolicy: [out]   AUDIT_POLICY_INFORMATION構造のアレイを戻すために割り当てられた１つのブロック・バッファへのポインタ。要素の総数はPolicyCountである。ユーザ毎監査方針を検索して、pSubCategoryGuidsを通じて指定した全てのサブカテゴリ、または個々の監査イベントを求める。各サブカテゴリと関連があるカテゴリも、AuditCategoryGuidを通じて検索し、受け渡す。バッファ内のポインタは、割り当てられた１つのブロック内部の位置へのポインタである。AuditFreeをコールすることにより、戻された１つのバッファを解放することができる。
【００５８】
このＡＰＩに対する戻り値は、成功の場合TRUE、失敗の場合FALSEを含むことができる。GetLastError()関数を用いれば、更に特定的なステータス・コードを得ることができる。以下のステータス・コードを戻すことができる。
【００５９】
ERROR_ACCESS_DENIED:  この動作を実行するために必要な特権またはアクセスが存在しない。
【００６０】
ERROR_INVALID_PARAMETER:  パラメータの形成が正しくない。
【００６１】
ERROR_FILE_NOT_FOUND；pSidが指定したユーザに対して、ユーザ毎方針が存在しない。
【００６２】
別のユーザ毎監査ＡＰＩ２６０は、ユーザ毎監査を指定したユーザを列挙するＡＰＩ２６４としてもよい。このようなＡＰＩのコール元即ちユーザに、監査方針を設定するアクセス特権を強調させることを要求してもよい。以下に、一例を示す。
【００６３】
【表１１】
2009500769.tif 000013
ＡＰＩ２６４のパラメータは以下を含むことができる。
【００６４】
ppAuditSidArray: [out]  sidsのアレイを戻すために割り当てられた１つのブロック・バッファへのポインタ。バッファ内のポインタは、割り当てられた１つのブロック内部の位置へのポインタである。AuditFreeをコールすることにより、戻された１つのバッファを解放しなければならない。この構造のUsersCountメンバは、UserSidArrayによって指し示されたsidの数を収容する。
【００６５】
【表１２】
2009500769.tif 000014
このＡＰＩに対する戻り値は、成功の場合にはTRUE、失敗の場合にはFALSEを含む。GetLastError()関数を用いれば、更に特定的なステータス・コードを得ることができる。以下のステータス・コードを戻すことができる。
【００６６】
ERROR_INVALID_PARAMETER:  パラメータの形成が正しくない。
【００６７】
ERROR_ACCESS_DENIED:  この動作を実行するために必要な特権またはアクセスが存在しない。
【００６８】
ユーザ公開監査ＡＰＩ２５０は、システム監査ＡＰＩ２７０、またはコンピュータ２００のようなシステムに適用可能な監査機能を実行することができるＡＰＩを含む。システム監査ＡＰＩ２７０は、システム監査方針２７１を設定するＡＰＩを含むことができる。このようなＡＰＩのコール元即ちユーザに、監査方針を設定するアクセス特権を強調させることを要求してもよい。以下に、このようなＡＰＩの一例を示す。
【００６９】
【表１３】
2009500769.tif 000015
システム設定監査方針ＡＰＩ２７１のパラメータは以下を含むことができる。
【００７０】
pAuditPolicy: [in]  AUDIT_POLICY_INFORMATION構造のアレイへのポインタ。システム監査方針は、このパラメータを通じて指定された全てのサブカテゴリに対して設定することができる。
【００７１】
PolicyCount: [in]  pAuditPolicyアレイにおける要素の数を示す。
【００７２】
このＡＰＩに対する戻り値は、成功の場合にはTRUE、失敗の場合にはFALSEを含む。GetLastError()関数を用いれば、更に特定的なステータス・コードを得ることができる。以下のステータス・コードを戻すことができる。
【００７３】
ERROR_INVALID_PARAMETER:  パラメータの形成が正しくない。pAuditPolicyInformation王増における要素のいずれか１つでも無効である場合、監査方針を設定しない。
【００７４】
ERROR_ACCESS_DENIED:  この動作を実行するために必要な特権またはアクセスが存在しない。
【００７５】
システム監査ＡＰＩ２７０は、システム監査方針に問い合わせるＡＰＩ２７２を含むことができる。ステム監査方針に問い合わせるＡＰＩ２７２のコール元即ちユーザに、監査方針を設定するアクセス特権を強調させることを要求してもよい。以下に、有効方針算出２６３の一例を示す。
【００７６】
【表１４】
2009500769.tif 000016
このＡＰＩのパラメータは下記を含む。
【００７７】
pSubCategoriesGuids: [in]  システム監査方針を検索しなければならないSubCategoryGuidesのアレイへのポインタ。指し示すGUIDSの総数はPolicyCountである。
【００７８】
PolicyCount: [in]   pSubCategoriesGuidesによって指し示されるGUID要素の計数から成るULONG。これは、ppAuditPolicyから戻されるAUDIT_POLICY_INFORMATION要素の数でもある。
【００７９】
ppAuditPolicy: [out]   AUDIT_POLICY_INFORMATION構造のアレイを戻すために割り当てられた１つのブロック・バッファへのポインタ。要素の総数はPolicyCountである。システム監査方針を検索して、pSubCategoryGuidsを通じて指定した全てのサブカテゴリ、または個々の監査イベントを求める。各サブカテゴリと関連があるカテゴリも、AuditCategoryGuidを通じて検索し、受け渡す。バッファ内のポインタは、割り当てられた１つのブロック内部の位置へのポインタである。AuditFreeをコールすることにより、戻された１つのバッファを解放することができる。
【００８０】
このＡＰＩに対する戻り値は、成功の場合TRUE、失敗の場合FALSEを含むことができる。GetLastError()関数を用いれば、更に特定的なステータス・コードを得ることができる。以下のステータス・コードを戻すことができる。
【００８１】
ERROR_ACCESS_DENIED:  この動作を実行するために必要な特権またはアクセスが存在しない。
【００８２】
ERROR_INVALID_PARAMETER:  パラメータの形成が正しくない。
【００８３】
システム監査ＡＰＩ２７０の内２つは、カテゴリを列挙するＡＰＩ２７３、およびサブカテゴリを列挙するＡＰＩ２７４とすることができる。カテゴリを列挙するＡＰＩ２７３の一例を以下に示す。
【００８４】
【表１５】
2009500769.tif 000017
このＡＰＩのパラメータは以下を含むことができる。
【００８５】
ppAuditCategoriesArray: [out]  ＯＳによって理解されるカテゴリのアレイを戻すために割り当てられた１つのブロック・バッファへのポインタ。バッファ内のポインタは、割り当てられた１つのブロック内部の位置へのポインタである。AuditFreeをコールすることにより、戻された１つのバッファを解放することができる。
【００８６】
pCountReturned: [out]  ppAuditCategoriesArrayアレイ内の要素数を収容する変数へのポインタ。
【００８７】
このＡＰＩに対する戻り値は、成功の場合TRUE、失敗の場合FALSEを含むことができる。GetLastError()関数を用いれば、更に特定的なステータス・コードを得ることができる。以下のステータス・コードを戻すことができる。
【００８８】
ERROR_INVALID_PARAMETER:  パラメータの形成が正しくない。
【００８９】
サブカテゴリを列挙するＡＰＩ２７４の一例を以下に示す。
【００９０】
【表１６】
2009500769.tif 000018
このＡＰＩのパラメータは以下を含むことができる。
【００９１】
pAuditCategory:[in]  サブカテゴリ全てのリストを列挙すべき監査カテゴリ。
【００９２】
bRetrieveAllSubCategories: [in]  TRUEの場合、pAuditCategoryパラメータは無視され、システムによって理解される全てのサブカテゴリは、ppAuditSubCategoriesArrayパラメータを通じて戻される。このパラメータがFALSEの場合、pAuditCategoryパラメータを用いて、pAuditCategoryと関連のある監査サブカテゴリ全てを検索する。
【００９３】
ppAuditCategoriesArray: [out]  ＯＳによって理解されるカテゴリのアレイを戻すために割り当てられた１つのブロック・バッファへのポインタ。バッファ内のポインタは、割り当てられた１つのブロック内部の位置へのポインタである。AuditFreeをコールすることにより、戻された１つのバッファを解放することができる。
【００９４】
pCountReturned: [out]  ppAuditCategoriesArrayアレイ内の要素数を収容する変数へのポインタ。
【００９５】
このＡＰＩに対する戻り値は、成功の場合TRUE、失敗の場合FALSEを含むことができる。GetLastError()関数を用いれば、更に特定的なステータス・コードを得ることができる。以下のステータス・コードを戻すことができる。
【００９６】
ERROR_INVALID_PARAMETER:  パラメータの形成が正しくない。
【００９７】
システム監査ＡＰＩ２７０の内２つは、カテゴリ名称調査ＡＰＩ２７５、およびサブカテゴリ名称調査ＡＰＩ２７６とすることができる。カテゴリ名称調査ＡＰＩ２７５の一例を以下に示す。
【００９８】
【表１７】
2009500769.tif 000019
カテゴリ名称調査ＡＰＩ２７５のパラメータは以下を含むことができる。
【００９９】
pAuditCategory: [in]  表示名称を検索すべき監査カテゴリ。
【０１００】
ppszCategoryName: [out]  カテゴリの名称を受け取る。これは、AuditFreeをコールすることによって、解放しなければならない。
【０１０１】
このＡＰＩに対する戻り値は、成功の場合TRUE、失敗の場合FALSEを含むことができる。GetLastError()関数を用いれば、更に特定的なステータス・コードを得ることができる。以下のステータス・コードを戻すことができる。
【０１０２】
ERROR_INVALID_PARAMETER:  パラメータの形成が正しくない。
【０１０３】
サブカテゴリ名称調査ＡＰＩ２７６の一例を以下に示す。
【０１０４】
【表１８】
2009500769.tif 000020
このＡＰＩのパラメータは以下を含むことができる。
【０１０５】
pAuditCategory:[in]  サブカテゴリを識別するＧＵＩＤへのポインタ。
【０１０６】
ppszSubCategoryName: [out]  サブカテゴリの名称を受け取る。AuditFreeをコールすることにより、これを解放することができる。
【０１０７】
サブカテゴリ名称調査ＡＰＩ２７６に対する戻り値は、成功の場合TRUE、失敗の場合FALSEを含むことができる。GetLastError()関数を用いれば、更に特定的なステータス・コードを得ることができる。以下のステータス・コードを戻すことができる。
【０１０８】
ERROR_INVALID_PARAMETER:  パラメータの形成が正しくない。
【０１０９】
図５は、ローカル・セキュリティ・オーソリティ２１０の監査方針ストア２１５内に収容することができる監査カテゴリの例、および監査サブカテゴリの例のブロック図である。監査カテゴリの例および監査サブカテゴリの例３００は、前述のユーザ公開または非公開ＡＰＩを用いて、詳細レベルで、ユーザ毎またはシステム毎にアクセスすることができる形式の監査カテゴリおよびサブカテゴリである。図５に例示したサブカテゴリは、個別の監査イベントとすることができるが、代替実施形態では、サブカテゴリは個別監査イベントの集合体としてもよいことは、認められて当然である。
【０１１０】
アカウント管理監査カテゴリ３０１は、監査サブカテゴリ３０２を含むことができる。サブカテゴリ３０２の一部は、ユーザ・アカウント作成および削除サブカテゴリ、グループ作成および削除サブカテゴリ、パスワード管理サブカテゴリ、アカウント変更サブカテゴリ、ならびに信頼管理(trust management)サブカテゴリとすることができる。
【０１１１】
認証用監査カテゴリ３１１は、監査サブカテゴリ３１２を含むことができる。サブカテゴリ３１２の一部は、証明書有効性判断サブカテゴリ、Kerberosサブカテゴリ、およびその他の認証活動サブカテゴリとすることができる。
【０１１２】
ログオン／ログオフ監査カテゴリ３２１は、監査サブカテゴリ３２２を含むことができる。サブカテゴリ３２２の一部は、ログオン・サブカテゴリ、ログオフ・サブカテゴリ、アカウント・ログアウト、ＩＰＳｅｃサブカテゴリ、特殊ログオン識別サブカテゴリ、およびその他のログオン活動サブカテゴリを含むことができる。
【０１１３】
方針変更監査カテゴリ３１１は、監査サブカテゴリ３３２を含むことができる。カテゴリ３３２の一部は、監査方針変更サブカテゴリ、アカウント方針変更サブカテゴリ、パスワード方針変更サブカテゴリ、およびその他の方針変更サブカテゴリを含むことができる。
【０１１４】
オブジェクト・アクセス監査カテゴリ３４１は、監査サブカテゴリ３４２を含むことができる。このようなサブカテゴリ３４２は、ファイル・システム・サブカテゴリ、レジストリ・サブカテゴリ、カーネル・サブカテゴリ、ＳＡＭサブカテゴリ、その他のオブジェクト・アクセス・サブカテゴリ、証明サービス・サブカテゴリ、アプリケーション発生監査サブカテゴリ、およびソフトパッチング(softpatching)サブカテゴリを含むことができる。
【０１１５】
特権使用監査サブカテゴリ３５１は、監査サブカテゴリ３５２を含むことができる。このようなサブカテゴリ３５２は、機密(sensitive)特権サブカテゴリ、非機密特権サブカテゴリ、およびその他の特権使用活動サブカテゴリを含むことができる。
【０１１６】
プロセス追跡監査カテゴリ３６１は、監査サブカテゴリ３６２を含むことができる。このようなサブカテゴリ３６２は、プロセス作成サブカテゴリ、プロセス終了サブカテゴリ、ＤＰＡＰＩ活動サブカテゴリ、およびその他のプロセス活動サブカテゴリを含むことができる。
【０１１７】
ＤＳオブジェクト・アクセス監査カテゴリ３７１は、ＤＳオブジェクト・アクセス監査サブカテゴリ３７１を含むことができる。
【０１１８】
システム監査カテゴリ３８１は、監査サブカテゴリ３８２を含むことができる。このようなサブカテゴリ３８２は、セキュリティ・システム状態サブカテゴリ、セキュリティ・モジュール・ロード・サブカテゴリ(security module load subcategory)、およびその他のセキュリティ・システム活動サブカテゴリを含むことができる。
【０１１９】
図６は、コンピュータ４００のブロック図であり、これは図１において記載したコンピュータ１１０または計算機環境１００とすることができる。コンピュータ４００は、図２から図５に関して説明したような、ローカル・セキュリティ・オーソリティおよびユーザ公開監査ＡＰＩを含むことができる。コンピュータ４００は、第１ユーザ４１１および第２ユーザ４３１によるアクセスが可能とするとよい。例えば、第１ユーザ４１１は、第２ユーザがコンピュータ４００にログオンするやり方とは異なるやり方でコンピュータ４００にログオンしてもよい。このように、コンピュータ４００、したがってコンピュータ４００の監査者は、第１および第２ユーザ４１１、４３１のどちらがそれを使用しているか確認することができる。
【０１２０】
前述のように、監査カテゴリにおける個々のサブカテゴリ監査の実行を許容することによって詳細監査が行えることに加えて、コンピュータ４００またはローカル・セキュリティ・オーソリティは、第１ユーザ４１１および第２ユーザ４３１のような各ユーザがユーザ毎の監査を実施することを可能にする。即ち、第１ユーザ４１１に対する監査カテゴリまたはサブカテゴリは、第２ユーザ４３１に対して簡さカテゴリおよびサブカテゴリがイネーブルされているかまたはディスエーブルされているかには関係なく、イネーブルおよびディスエーブルすることができる。ユーザ毎監査方針は、システム監査方針と関連があってもよい。システム監査方針の一例が、１つのサブブカテゴリであってもよく、それをイネーブルまたはディスエーブルできるように設定することもできる。同じサブカテゴリに対するユーザ毎監査方針をユーザ毎に確立し、それをイネーブルまたはディスエーブルするようにしてもよい。システムが監査をディスエーブルした場合、ユーザはその監査をイネーブルするために包含(inclusion)を設定することができる。システムが監査をイネーブルした場合、ユーザが監査をディスエーブルするのを妨げることができる。代替実施形態では、システムが監査をイネーブルしても、ユーザ毎に監査をディスエーブルすることができる。
【０１２１】
例えば、コンピュータは、第１および第２監査カテゴリ４１２、４２２を含むことができ、その各々は図５において記載したカテゴリとすることができる。第１および第２監査カテゴリ４１２、４２２の各々は、第１、第２、および第３監査サブカテゴリ４１４〜４１６、４２４〜４２６を含むことができる。サブカテゴリ４１４〜４１６、４２４〜４２６は、図５において記載したように、個別の監査イベントとすることができ、あるいはカテゴリ４１２、４２２の各々における個々の監査イベントの集合体とすることもできる。
【０１２２】
監査者は、第１監査カテゴリ４１２の第１および第２監査サブカテゴリ４１４、４１６をイネーブルすることができ、第１ユーザ４１１と関連のある第２監査サブカテゴリをディスエーブルする、即ち、イネーブルしない、または選択することができる。サブカテゴリが個々の監査イベントの集合体である場合、このサブカテゴリをイネーブルまたはディスエーブルすると、それぞれ、当該サブカテゴリにおける個々の監査イベントの全てをイネーブルまたはディスエーブルすることになる。
【０１２３】
これらのカテゴリ４１２、４２２またはサブカテゴリ４１４〜４１６、４２４〜４２６が第１ユーザに対してイネーブルされているか否かには関係なく、監査者は、第１監査カテゴリ４１２の第１監査サブカテゴリ４１４をイネーブルし、第２ユーザ４３１と関連のある第１監査カテゴリ４１２の第２および第３監査サブカテゴリ４１５、４１６をイネーブルしないことも可能である。加えて、監査者は、第２ユーザ４３１と関連のある第２監査カテゴリ４２２のサブカテゴリ４２４〜４２６全てをイネーブルすることもできる。つまり、監査者は、一人のユーザと関連のある監査カテゴリにおける個々の監査イベントまたはサブカテゴリを、他のユーザに対してイネーブルされているか否かには関係なく、イネーブルすることができる。
【０１２４】
図７は、ユーザ毎またはシステム毎に詳細監査方針を実施する方法例５００のフロー図を示す。方法５００は、ステップ５１０において開始し、図４において例示の目的で記載したＡＰＩのような、該当するユーザ公開ＡＰＩにコールする。このようなコールは監査者によって行うことができる。ステップ５１５において、リモート・プロシージャ・コールをローカル・セキュリティ・オーソリティまたはコンピュータ上におけるその他のしかるべきエンティティに対して行うことができる。このようなコールは、例えば、コンピュータのオペレーティング・システムによって行うことができ、選択のために、ユーザ監査機能に公開することができる。例えば、このコールにより、ユーザは「監査設定」または「監査問い合わせ」機能を選択することが可能となる機能例を図３において記載したが、ユーザにはその他のこのような機能を装備してもよい。
【０１２５】
監査者は、ステップ５２０において、機能を選択することができる。ステップ５２５において、監査者は、監査カテゴリまたはサブカテゴリを選択し、これに対してその機能を実行することができる。サブカテゴリは、個別監査イベントであってもよい。カテゴリおよびサブカテゴリの例を図５において記載したが、代替実施形態では、その他のカテゴリ、サブカテゴリ、または個別の監査イベントも利用可能としてもよい。非公開ＡＰＩリモート・プロシージャ・コール・インターフェースの例を図３において記載したが、代替実施形態ではその他のこのようなインターフェースを設けてもよい。ステップ５３５において、機能を完了し、しかるべき応答をユーザに与えることができる。
【０１２６】
図８は、ＡＰＩ内外に受け渡すことができ、監査サブカテゴリまたは監査カテゴリに付随する監査方針情報を提供する構造６００の例である。各監査カテゴリ、笹部カテゴリ、および個々の監査イベントは、全域一意識別し（ＧＵＩＤ）によって、一意に識別することができる。このため、各監査サブカテゴリは、構造６００の行６０５に示すように、AuditSubCategoryGuidと呼ぶことができる。サブカテゴリにＧＵＩＤを使用することにより、アプリケーション特定の拡張しを監査方針に将来追加することが可能となる。監査情報は、構造６００の行６１０におけるAuditinformationメンバにて指定することができる。方針を問い合わせる場合、行６１５のAuditCategoryGuidが、AuditSubCategoryGuid６０５が属するカテゴリを表すことができる。これによって、アプリケーションが、ＧＵＩＤによって祖機別した監査サブカテゴリをカテゴリと関連付けることが可能となる。
【０１２７】
このようにサブカテゴリを用いて監査方針を指定することにより、サブカテゴリを２つ以上のサブカテゴリに今後細分化することが可能となる場合がある。例えば、古いアプリケーションがあるサブカテゴリに対して監査方針を設定し、このサブカテゴリが後に２つのサブカテゴリに分割される場合、最初のサブカテゴリが分割された後のサブカテゴリ全てを変更することもできる。更に、サブカテゴリ・レベルで方針を確立することができるようにすることにより、今後あるサブカテゴリを別のサブカテゴリ内に移動させることが可能となる場合もある。
【０１２８】
図９は、ＳＩＤ即ちセキュリティ識別子で識別されるユーザに対して確立した監査方針を規定するデータ構造７００の一例を示す。図１０および図１１は、それぞれ、利用可能なローカル・セキュリティ・オーソリティの方針ストアにおいて利用可能な監査カテゴリおよび監査サブカテゴリを規定するデータ構造８００、９００の例を示す。
【０１２９】
本発明の方法は、ハードウェア、ソフトウェア、または、双方の組み合わせが適している場合は、組み合わせで実施することができる。つまり、本発明の方法および装置、あるいはそのある種の態様または部分は、コンピュータ読み取り可能媒体に具体化したプログラム・コードの形態をなすことができる。図２から図１１に記載し特許請求する実施形態の方法のステップを実行するプログラム・コードを実行するプロセッサは、本発明を具体化する計算機環境を構成する。プログラマブル・コンピュータ飢えにおけるプログラム・コードの実行の場合、計算機環境は、一般に、プロセッサ、当該プロセッサによって読み取り可能な記憶媒体（揮発性および不揮発性メモリ、および／または記憶エレメントを含む）、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含む。１つ又は２つ以上のプログラムは、好ましくは、計算機環境と通信するために、上位手続きプログラミング言語またはオブジェクト指向プログラミング言語で実施する。しかしながら、望ましければ、プログラムは、アセンブリまたは機械語で実施することもできる。いずれの場合でも、言語は、コンパイルまたはインタプリタ言語とすることや、あるいはハードウェア実施態様と組み合わせることもできる。
【０１３０】
以上、種々の図と関連付けて、具体的な例に関して本発明を説明したが、本発明から逸脱することなく、その他の実施形態を使用すること、または本発明の同じ機能を実行するために、記載した実施形態に変更や追加を行うことも可能あることは言うまでもない。例は、説明のために提示したのであり、特許請求の範囲に定義する本発明の範囲を限定することは全く意図していない。要約すれば、本発明は、本明細書において提示し記載した例には全く限定されることはない。したがって、本発明は、いずれの一実施形態にも限定されず、添付した特許請求の範囲にしたがってその広さおよび範囲を解釈することとする。
【図面の簡単な説明】
【０１３１】
【図１】図１は、態様を実施することができる計算機環境例を示すブロック図である。
【図２】図２は、詳細監査方針を実施するコンピュータのブロック図である。
【図３】図３は、ローカル・セキュリティ・オーソリティに含むことができる監査関連リモート・プロシージャ・コールのブロック図である。
【図４】図４は、ユーザ公開監査アプリケーション・プログラミング・インターフェースのブロック図である。
【図５】図５は、監査カテゴリ例および監査サブカテゴリ例のブロック図である。
【図６】図６は、ユーザ毎監査方針を実施するコンピュータのブロック図である。
【図７】図７は、ユーザ毎またはシステム毎に詳細監査方針を実施する方法の一例のフロー図を示す。
【図８】図８は、アプリケーション・プログラミング・インターフェースに対して双方向に受け渡すことができ、監査サブカテゴリまたは監査カテゴリに付随する監査方針情報を提供することができる構造の一例である。
【図９】図９は、セキュリティ識別子によって識別された、ユーザに対して確立した監査方針を規定するデータ構造の一例を示す。
【図１０】図１０は、ローカル・セキュリティ・オーソリティにおいて利用可能な監査カテゴリおよび監査サブカテゴリを規定するデータ構造の一例を示す。
【図１１】図１１は、ローカル・セキュリティ・オーソリティにおいて利用可能な監査カテゴリおよび監査サブカテゴリを規定するデータ構造の一例を示す。
【図１】
2009500769.tif 000021
【図２】
2009500769.tif 000022
【図３】
2009500769.tif 000023
【図４】
2009500769.tif 000024
【図５】
2009500769.tif 000025
【図６】
2009500769.tif 000026
【図７】
2009500769.tif 000027
【図８】
2009500769.tif 000028
【図９】
2009500769.tif 000029
【図１０】
2009500769.tif 000030
【図１１】
2009500769.tif 000031
【国際調査報告】
2009500769.tif 000032