コンピュータの画面の情報を保護するシステム、方法、及びプログラム
【課題】 表示されるウインドウの属性、描画結果などを考慮して、柔軟且つ効果的な表示情報のセキュリティ管理を実現すること。
【解決手段】 マルチウインドウ・システムなどのグラフィック・ユーザ・インターフェースをもつコンピュータ・システムにおいて、描画命令が実行されるたびに、どのような情報が描画結果に継承されるかを、好適には画像処理などの複雑なステップを経ないで、描画命令の論理演算パターンから判断し、それと同時に、画面やメモリ上の画像と一対一に対応するラベル付けされた領域マップを管理することで、画面に出力された画像の情報フロー制御を実施する。
【解決手段】 マルチウインドウ・システムなどのグラフィック・ユーザ・インターフェースをもつコンピュータ・システムにおいて、描画命令が実行されるたびに、どのような情報が描画結果に継承されるかを、好適には画像処理などの複雑なステップを経ないで、描画命令の論理演算パターンから判断し、それと同時に、画面やメモリ上の画像と一対一に対応するラベル付けされた領域マップを管理することで、画面に出力された画像の情報フロー制御を実施する。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、一般的には、コンピュータのセキュリティ管理に関し、より詳しくは、コンピュータに接続された画面における出力情報を保護するための技術に関するものである。
【背景技術】
【0002】
近年、コンプライアンス強化や個人情報保護のために、コンピュータリソースに対するアクセス制御をきめ細かく行う必要性が増大している。そのために、機密情報を含んだファイルへのアクセス制御や、クリップボードやプロセス間通信を介した機密情報のフロー制御を行う様々な方法が実用化されている。
【0003】
しかし、ファイルのアクセス権やクリップボードの情報の管理をするだけでは、情報の最終的な出力デバイスである画面上の情報セキュリティ管理を効果的に行うことはできない。
【0004】
すなわち、画面上に出力された画像データを保護するための確実な手法がないと、折角、機密情報を含んだファイルそのもののアクセス権を設定しても、機密情報を含んだ画面上ののデータを、どのプロセスからでも自由に読み込みを許してしまうことになる。
【0005】
VMWareやVirtual PCなどのコンピュータ仮想技術により、ゲストOS間の画面情報の隔離を行うことは可能である。しかし、この技術では、ホストOSからはゲストOSの画面を自由に読むことを許してしまうため、ホストOSに悪意あるソフトウェアが潜んでいると、ゲストOSの画面上の機密情報が不正に持ち出される危険性を防ぎきれない。
【0006】
また、NSA(米国国家安全保障局)のSecured X Window Systemは、独立した仮想デスクトップ画面上に機密情報を表示することで、他のデスクトップ画面内のプロセスと、画面を分離することを可能ならしめる。但し、この技術では、ビデオメモリ上の画像データは保護されないので、バックグラウンドプロセスが自由に画像情報を読み取ることを許してしまう。
【0007】
特開平11−249965は、ビデオメモリに格納したビデオデータに従ってディスプレイ装置の表示画面上に表示処理を行なうコンピュータシステムにおいて、表示画面上に表示するウインドウ単位の画面情報を管理するためのウインドウ管理テーブルを設け、ウインドウ単位の画面情報の表示指示に応じてウインドウ管理テーブルを更新すると共に、当該画面情報のコピー処理のプロテクトを指示するためのコピープロテクト情報を前記ウインドウ管理テーブルに設定し、表示画面上に表示処理されたウインドウ単位の画面情報に対するコピー要求を受けたときに、ウインドウ管理テーブルを参照してコピー要求対象の画面情報に対してコピープロテクト情報が設定されている場合にはビデオメモリから画面情報に対応するビデオデータのコピー処理を禁止するようにすることを開示する。
【0008】
特開2007−34685は、電子ペーパに表示する各コンテンツの機密性保持等を実現するためのシステムであって、このシステムは、利用制限記憶手段をもち、この利用制限記憶手段がコンテンツ毎の利用制限情報を保持し、表示制御手段が表示部へコンテンツの表示内容を利用制限情報に応じた態様で書き込む。そうして、利用制限情報に応じて、表示部に表示するドキュメント中の或るコンテンツを表示する又は表示しない等の態様とすることにより、コンテンツの機密性保持や同一性維持等をコンテンツの利用を制限することで実現する。また、ユーザからの確認要求に応じて、利用制限記憶手段に保持した利用制限情報を表示部2に書き込んでユーザに提示する。
【0009】
特開2007−52655は、予め規定されている範囲内に立ち入る利用者に関連付けられている認証情報を取得する手段と、前記取得された認証情報が、前記ドキュメントに関連付けられている表示許可条件を満たすか否かを判断する手段と、前記認証情報が前記表示許可条件を満たさない場合に、前記ドキュメントの前記表示部への表示を制限する制限手段と、を含むドキュメント表示制御装置を開示する。
【0010】
特開2007−65846は、本出願人と同一の出願人に係る発明であり、オペレーティングシステム上で第1および第2アプリケーションプログラムを含む複数のアプリケーションプログラムを並行に動作させる情報処理装置であって、第1アプリケーションプログラムからオペレーティングシステムに対する関数呼び出し、または、第1アプリケーションプログラムおよびオペレーティングシステム間で送受信されるメッセージを監視する監視部と、監視部による監視結果に基づいて、第2アプリケーションプログラムからオペレーティングシステムに対する関数呼び出し、若しくは、第2アプリケーションプログラムおよびオペレーティングシステム間のメッセージ送受信の処理を変更または禁止する制御部とを備える情報処理装置を開示する。本願発明の1つの背景技術として参考までに示す。
【0011】
これらの従来技術によれば、特定の目的に対しては、有効に画面のセキュリティ保護が達成される。しかし、これらの従来技術では、最近になって、GUI環境で採用されつつある半透明ウインドウに適切に対処できないし、表示されている文字列情報やフォントサイズなどに応じた、柔軟なセキュリティ管理も難しい。
【特許文献1】特開平11−249965
【特許文献2】特開2007−34685
【特許文献3】特開2007−52655
【特許文献4】特開2007−65846
【発明の開示】
【発明が解決しようとする課題】
【0012】
この発明は、上記問題点を解決するためになされたものであり、表示されるウインドウの属性、描画結果などを考慮して、柔軟且つ効果的な表示情報のセキュリティ管理を実現することを可能とする技術を提供ことを目的とする。
【課題を解決するための手段】
【0013】
上記目的は、マルチウインドウ・システムなどのグラフィック・ユーザ・インターフェースをもつコンピュータ・システムにおいて、描画命令が実行されるたびに、どのような情報が描画結果に継承されるかを、好適には画像処理などの複雑なステップを経ないで、描画命令の論理演算パターンから判断し、それと同時に、画面やメモリ上の画像と一対一に対応するラベル付けされた領域マップを管理することで、画面に出力された画像の情報フロー制御を実施することによって、達成される。
【0014】
本発明は、各プロセスによるグラフィクスデバイスへの描画命令実行を検出する描画命令実行検出部と、前記描画命令実行検出部が検出した描画命令の種別およびパラメータを解析することにより描画命令実行後の画像状態を判定する描画命令解析部と、描画命令解析部の判定結果に基づき描画領域にラベル付けを行うラベル割り当て部と、画面およびオフスクリーンバッファのラベルを管理するラベルマップ管理部と、実際に描画命令を実行する描画命令実行部と、さらに、描画命令実行検出部が画面またはオフスクリーンバッファからの画像読み込みを検出したときに、読み込み元領域のラベルに応じて読み込み元の画像を処理する画像処理制御部で構成される。
【0015】
本発明によれば、先ず、各プロセス内に監視モジュールが常駐させられる。そうして、監視モジュールは、プロセスによるグラフィックスデバイスに対する描画命令を監視する。
【0016】
監視モジュールは、プロセスが画像データを書き込む際に、描画プロセスの属性や描画命令の内容に応じて、描画領域に対してセキュリティラベルを割り当てる。描画領域には、画面上の可視領域のほかに、オフスクリーンバッファ上の不可視領域も含む。本発明は、ここで、描画命令種別およびパラメータを解析し、描画領域の既存画像(Destination)、描画演算の処理対象画像(Source)、パラメータで指定された画像要素(Pattern)の論理演算の結果、描画命令実行後にどの画像情報が残されるかを判定し、その結果に応じてセキュリティラベルを割り当てる。
【0017】
一方、監視モジュールは、プロセスが画面上またはオフスクリーンバッファ上の画像データを読み込む際に、プロセスのセキュリティラベルと、読み込もうとする画面領域のセキュリティラベルとを比較し、読み込み命令の可否を判定する。画面領域のセキュリティラベルが、読み込みプロセスのセキュリティラベルより高い場合は、読み込み命令を失敗させるか、あるいは、領域内の画像情報が、セキュリティラベルの低いプロセスに伝わらないように、墨塗りやマスク処理した画像データを返す。
【0018】
本発明により、画面上に出力された機密情報は、適切なセキュリティラベルを割り当てたプロセスしか読み出せなくなるため、悪意あるプログラムや一般プログラムは、画面上の機密情報画像を取得できない。その結果、画面スナップショットを取得されて機密情報が漏洩する危険性が避けられる。
【発明の効果】
【0019】
この発明によれば、描画命令が実行されるたびに、どのような情報が描画結果に継承されるかを、描画命令の論理演算パターンから判断して、アクセス制御するので、悪意あるプログラムや一般プログラムからの画面上の機密情報画像へのアクセスを効果的に禁止できるとともに、半透明ウインドウなどの場合にも、適切なセキュリティラベルを割り当てることによって、柔軟にアクセス制御を行うことができる。
【発明を実施するための最良の形態】
【0020】
以下、図面を参照して、本発明の一実施例の構成及び処理を説明する。以下の記述では、特に断わらない限り、図面に亘って、同一の要素は同一の符号で参照されるものとする。なお、ここで説明する構成と処理は、一実施例として説明するものであり、本発明の技術的範囲をこの実施例に限定して解釈する意図はないことを理解されたい。
【0021】
図1を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータ・ハードウェアのブロック図が示されている。図1において、システム・パス102には、CPU104と、主記憶(RAM)106と、ビデオメモリ(VRAM)108と、ハードディスク・ドライブ(HDD)110と、キーボード112と、マウス114と、ディスプレイ116が接続されている。CPU104は、好適には、32ビットまたは64ビットのアーキテクチャに基づくものであり、例えば、インテル社のPentium(商標) 4、AMD社のAthlon(商標)などを使用することができる。主記憶106は、好適には、512KB以上の容量をもつものである。ビデオメモリ108は、ディスプレイ116に画面出力するためのイメージを保持するために使用される。
【0022】
ハードディスク・ドライブ110には、個々に図示しないが、オペレーティング・システム及び本発明に係る処理プログラム、及びそのワードプロセッサ、表計算プログラム、プレゼンテーション作成プログラム、データベース・プログラムなどのアプリケーション・プログラムが、予め格納されている。オペレーティング・システムは、Linux(商標)、マイクロソフト社のWindows XP(商標)、Windows(商標)2000、アップルコンピュータのMac OS(商標)などの、マルチウインドウのグラフィック・ユーザー・インターフェースをサポートし、CPU104に適合する任意のものでよい。なお、以下の説明では、便宜上、オペレーティング・システムとして、Windows XP(商標)を使用し、APIとしてWin32 APIを使用するものとして説明する。しかし、この分野の当業者なら、Linux(商標)などの他のオペレーティング・システムでも、同等のAPIを具備していることを理解するであろう。
【0023】
ハードディスク・ドライブ110にはまた、後述する本発明に係るセキュリティ管理プログラムが格納されている。このセキュリティ管理プログラムは、オペレーティング・システムのグラフィックス・ライブラリの呼び出しを監視し得る機能を記述可能な、C、C++、C#、Java(商標)などの任意のプログラム言語処理系で書かれている。
【0024】
ディスプレイ116は、これには限定されないが、好適には、1024×768以上の解像度をもち、32ビットtrue colorのLCDモニタである。
【0025】
キーボード110及びマウス112は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、ディスプレイ116に表示されたアイコン、タスクバー、ウインドウなどのグラフィック・オブジェクトを操作するために使用される。
【0026】
図2は、この実施例の論理構成のブロック図である。図2において、VRAM108中には、画面表示領域108aと、複数のオフスクリーン・バッファ108b、オフスクリーン・バッファ108c、オフスクリーン・バッファ108d・・・が存在する。個々のオフスクリーン・バッファは、アプリケーション・プログラムによって、作成、変更またはクリアされる。但し、アプリケーション・プログラムがオフスクリーン・バッファを作成しただけでは、それは、ディスプレイ116(図1)の画面には反映されず、画面表示領域108aにコピーされてはじめて、画面に見える状態となる。例えば、ウインドウが最小化された、あるアプリケーション・プログラムが、画像を作成する命令を実行し、その結果がオフスクリーン・バッファの変更をもたらすことがあり得る。しかし、そのようなオフスクリーン・バッファの変更は、最小化されたアプリケーション・プログラムのウインドウが復元、あるいは最大化されるまで、画面表示領域108aには反映されず、すなわち、それまではユーザーに見えない。
【0027】
オフスクリーン・バッファ108b、オフスクリーン・バッファ108c、108d・・・は、基本的に、VRAM108中に確保されるが、VRAM108に十分な空き領域がなくなったなどの場合、主記憶106中に確保される。
【0028】
ラベル・マップ・テーブル210は、本発明で利用される特徴的な構成の1つであり、好適には、VRAM108中に、CreateBitmap、CreateCompatibleBitmapなどのAPI関数を呼び出すなどして、確保される。主記憶106中に確保する場合は、通常のGlobalAllocのようなAPI関数を用いることができる。ラベル・マップ・テーブル210は、画面ラベルマップ210aと、オフスクリーン・バッファ・ラベルマップ210b、210c、210d・・・とからなり、それぞれ、画面表示領域108a、複数のオフスクリーン・バッファ108b、108c、108d・・・に個別に対応している。しかし、オフスクリーン・バッファに格納されているのは、画面に対する描画内容であるが、オフスクリーン・バッファ・ラベルマップに格納されているのは、セキュリティ・レベルである。各々のオフスクリーン・バッファ・ラベルマップには、単一のセキュリティラベルを割り当てることができる。セキュリティラベルを割り当てるとは、この実施例では、オフスクリーン・バッファ・ラベルマップとして、CreateBitmapなどのAPI関数により割り当てられたビットマップ領域全体に、セキュリティラベル(例えば、1)を書き込むことである。本発明では、画面ラベルマップ210a上での、オフスクリーン・バッファ・ラベルマップの論理演算に基づき、アクセス制御が行われるが、その詳細は動作は、後で説明する。
【0029】
図2の上方を参照すると、複数のアプリケーション・プログラム220a、220b、220c・・・が示されている。これらのアプリケーション・プログラムは、一般的には、ディスク110に保存され、キーボード112及びマウス114の操作に応答して、オペレーティング・システムの機能によって、ディスク110から主記憶106にロードされ、実行される。
【0030】
本発明によれば、複数のアプリケーション・プログラム220a、220b、220cには、1〜3のようなセキュリティ・ラベルが付与される。ここでは、その数字が多いほど、セキュリティ・ラベルが高いとする。アプリケーション・プログラム、あるいはアプリケーション・プログラムが生成するプロセスにセキュリティ・レベルを付与する技術としては、例えば、特開2007−65846に記載されている技術がある。これにより開示される技術は、オペレーティング・システム上で、アプリケーション・プログラム間で送受信されるメッセージを監視し、別途記述されているポリシーに基づき、処理の変更、禁止などを行う。なお、以下の説明では、特開2007−65846の文脈におけるセキュリティ・レベルと、ここでアプリケーション・プログラムに付与されるセキュリティ・ラベルを同一視する。
【0031】
下記は、ファイル毎にセキュリティ・ラベルを設定するポリシーの例であり、<Rule RuleId="urn:rule1">が、設定されるセキュリティ・レベルを記述する。すなわち、urn:rule1以外に、"urn:rule0, "urn:rule2など複数用意しておく。また、<AttributeValue DataType="file:path"> 〜 </AttributeValue>のところで、そのセキュリティ・ラベルが適用されるアプリケーション・プログラムを記述する。
<!-- Group 1 -->
<Rule RuleId="urn:rule1">
<Description>Deny clipboad copy and print by notepad and calc</Description>
<Subjects>
<Subject>
<AttributeValue DataType="file:path">calc.exe</AttributeValue>
</Subject>
<Subject>
<AttributeValue DataType="file:path">notepad.exe</AttributeValue>
</Subject>
</Subjects>
<Resources>
<Resource DataType="clipboard" Lib="SBLCLIP">
<!-- クリップボードへのコピー禁止 -->
<AttributeValue DataType="clipboard:type">
<AnyClipboardDataType/>
</AttributeValue>
<Actions>
<Action Effect="Deny">write</Action>
</Actions>
</Resource>
...........
...........
</Rule>
【0032】
同様に、アプリケーション・プログラムによって生成されるプロセス毎に、セキュリティ・レベルを設定することが可能であるが、このような機能自体、本発明の要旨ではないので、これ以上の詳しい説明は省略する。必要に応じて、特開2007−65846その他の従来技術を参照されたい。なお、上記ポリシーには明示していないが、セキュリティ・ラベルを指定していないアプリケーション・プログラムには、最低レベルのセキュリティ・ラベルを付与するのが望ましい。これによって、素性の分からないアプリケーション・プログラムが、意図しない状況でビデオ・メモリから機密情報を取得することが防止される。
【0033】
さて、図2に戻って、描画命令実行機能検出部222は、上述のような機能を使用して、アプリケーション・プログラム220a、220b、220cが発行する描画命令を監視する。併せて、それらのアプリケーション・プログラムがそれらの描画命令を発行したプロセスのセキュリティ・レベルを取得する。そのような典型的な描画命令として、BitBlt、及びStretchBltがある。
【0034】
描画命令解析部224は、描画命令実行機能検出部222が検出した描画命令の種別やパラメータを解析し、描画命令実行の結果、どのような画像が、画面に残るかを判別する。
【0035】
ラベル割り当て部226は、アプリケーション・プログラムまたはプロセスに割り当てられたセキュリティ・レベルを参照して、画面ラベルマップ210a上に割り当てられるラベル値を決定する。なお、この実施例の説明では、アプリケーション・プログラムのセキュリティ・レベルと、それに対応するラベルマップのラベルとを同一のものとして説明することに留意されたい。
【0036】
ラベルマップ管理部228は、VRAM108の空き領域、または主記憶106などで、画面やオフスクリーンのラベルを管理する。
【0037】
画像処理制御部230は、ラベルマップを参照しながら、読み込みの可否を判断して、マスク処理などを実施する。
【0038】
描画命令実行部232は、描画を行う機能部であり、一つの実施例では、描画が実際に行われるように、オペレーティング・システムに、描画API関数を引き渡す。
【0039】
図3は、本発明が利用可能な、アプリケーション・プログラム監視の仕組みの概要を示す図である。一番下のレイヤ302は、グラフィックス・デバイスのハードウェアであり、その上に、グラフィックス・デバイスのハードウェアのメーカから提供される、グラフィックス・ドライバのレイヤ304がある。レイヤ304の上には、Win32グラフィックサブシステムを実現するWin32k.sysデバイス・ドライバのレイヤ306があり、その上に、具体的なグラフィック関係のAPI関数呼び出しを含む、GDI32.DLLのレイヤ308がある。そうして、GDI32.DLLと各アプリケーション・プログラムの間に、API監視モジュール310が介在し、アプリケーション・プログラムが発行するグラフィック関係のAPI関数呼び出しを監視する。このような監視機能は、図2の描画命令実行検出部232が行う。この監視モジュールの技法は、基本的に、本出願人に係る特開2007−65846で開示されているものである。
【0040】
図4は、本発明が利用可能な、アプリケーション・プログラム監視の別の仕組みの概要を示す図である。図4の実施例の、図3の実施例との違いは、アプリケーション・プログラム個別のAPI監視モジュール310を、GDI32.DLLとアプリケーション・プログラムの間に介在させることなく、その代わりに、グラフィックス・ドライバのレイヤ304と、Win32k.sysデバイス・ドライバのレイヤ306の間に、DDI監視ドライバのレイヤ402を置くことで、GDI32.DLLからグラフィックス・ドライバに送られる描画命令を、DDI監視ドライバが監視する。このような監視機能は、図2の描画命令実行検出部232が行う。この監視モジュールの技法は、基本的に、本出願人に係る特開2002−278526で開示されているものである。
【0041】
図3の監視機構の場合、ウインドウのクリッピング処理を、API監視モジュール310が行う必要があるが、図4の監視機構の場合、DDI監視ドライバに、クリッピング処理された可視領域情報が伝わるため、クリッピング処理する手間が省ける。
【0042】
次に、図2の描画命令実行検出部222が利用する、描画命令監視モジュールの機能について説明する。この描画命令監視モジュールは、この実施例では、図3のAPI監視モジュール310または、図4のDDI監視ドライバ402である。
【0043】
先ず、前提として、各プロセスには、適当なセキュリティ・レベルとしてのラベルが割り当られる。ここでは、ラベル値が高いほど機密性の高い情報を扱うと仮定する。そのとき、例えば特開2007−65846に記載されている方法で、管理者が事前にプロセスごとに割り当ててもよい。あるいは、本出願人に係る、2007年5月31日に出願の米国特許出願第11/755769号に記載されている技法により、開いているファイルやネットワークアドレス、画面出力文字情報などのコンテキストに応じて動的に割り当ててもよい。
【0044】
一方、描画命令監視モジュールは、各プロセスによって描画命令が発行されるたびに、画面上およびオフスクリーンバッファ上の描画領域に対して、描画プロセスの属性や描画命令の内容に応じたセキュリティ・ラベルの割り当てを行う。
【0045】
描画命令監視モジュールは、まず、描画命令の種別およびパラメータを解析し、描画命令を以下の演算式に抽象化する。
out = OP(src, dst, pat)
ここで、OPは描画命令種別(Operation)、srcは処理対象画像(Source)、dstは描画領域既存画像(Destination)、patは演算に用いる画像要素(Pattern)を意味する。また、outは、描画命令実行後の画像を意味する。srcとdstは、画面上の可視領域(Screen)の場合もあるし、VRAM108または主記憶106(memory)上のオフスクリーンバッファの場合もある。
【0046】
例えば、画面上の画像を別領域に移動する命令は、
OP = SourceCopy
src = Screen
dst = Screen
pat = NULL
out = src
と表現する。
【0047】
特定の画面領域を黒く塗りつぶすときは、
OP = PatternCopy
src = NULL
dst = Screen
pat = Black
out = pat
と表現する。
【0048】
オフスクリーンバッファから画面へのビットマップ半透明描画命令は、
OP = AlphaBlend
src = Memory
dst = Screen
pat = NULL
out = (src OR dst)
と表現する。
【0049】
特定の画面領域の反転表示は、
OP = DestInvert
src = NULL
dst = Screen
pat = NULL
out = (NOT dst)
と表現する。
【0050】
描画命令種別は、src, dst, patの論理演算パターンに応じて256種類存在する。さらに、描画を行わない命令として、オフスクリーンメモリの作成命令 CreateBitmap等も含む。描画命令監視モジュールは、このように描画命令を抽象化した上で、描画先領域の既存画像(Destination)が、描画命令によりどのように処理されるかを判定する。そうして、描画命令監視モジュールは、判定結果により、以下のように、描画先領域のセキュリティ・ラベルを決める。
【0051】
描画命令実行により、描画先領域の既存画像が塗りつぶされる場合、描画命令発行元のプロセスのセキュリティ・ラベルまたはソース領域のセキュリティ・ラベルを割り当てる。この種の命令の例として、ビットブロック転送を行うBitBltがあり、下記のような引数をとる。
BOOL BitBlt(HDC hdcDest, int nXDest, int nYDest, int nWidth, int nHeight,
HDC hdcSrc, int nXSrc, int nYSrc, DWORD dwRop);
ここで、hdcDestはコピー先のデバイスコンテキストのハンドル、nXDestはコピー先の左上隅の論理単位のx座標、nYDestはコピー先の左上隅の論理単位のy座標、nWidthはコピー先の長方形の論理単位の幅、nHeightはコピー先の長方形の論理単位の高さ、hdcSrcはコピー元のデバイスコンテキストのハンドル、nXSrcはコピー元の左上隅の論理単位のx座標、nYSrcはコピー元の左上隅の論理単位のy座標、dwRopは、ラスターオペレーションコードである。dwRop = SRCCOPYの場合、コピー元の長方形を、コピー先の長方形としてそのままコピーする処理が行われる。この場合、out = OP(src, dst, pat)の形に抽象化したとき、指定したパターンで埋める訳ではないので、pat = NULLである。また、dwRop = SRCCOPYとすることにより、画面から画面へのブロック転送であるので、OP = SourceCopyで、src = Screen、 dst = Screen、out = srcである。オフスクリーンバッファから画面に書く場合は、src = Memoryとなる。また、dstとして、オフスクリーンバッファを選ぶこともでき、その場合は、dst = Memoryとなる。
【0052】
別の例として、ブラシを使って長方形領域を描画するPatBltを挙げてみると、
BOOL PatBlt(HDC hdc, int nXLeft, int nYLeft, int nWidth,
int nHeight, DWORD dwRop);
ここで、hdcはデバイスコンテキストのハンドル、nXLeftは長方形領域の左上隅の論理単位のx座標、nYLeftは長方形領域の左上隅の論理単位のy座標で、out = OP(src, dst, pat)の形に抽象化したとき、
dwRop = PATCOPYとすることにより、src = NULL、 dst = Screen、OP = PatternCopyで、out = patである。ここで、patとは、デバイスコンテキストで現在選択されているブラシによるパターンである。
【0053】
描画命令実行により、描画先領域の既存画像情報がそのまま残る場合は、既存ラベルを継承する。この種の命令の例として、ラスターオペレーションコードにDSTINVERT(デスティネーション反転)を指定したBitBltがある。この場合、src = NULL、dst = Screen、pat = NULL、out = NOT (dst) となる。
【0054】
描画命令実行により、既存画像と新規画像の合成結果が表示される場合は、既存ラベルと新規ラベルの高いほうを割り当てる。この種の命令の例として、ラスターオペレーションコードにMERGECOPY(コピー元とコピー先のAND演算)を指定したBitBltや、AlphaBlend(半透明描画)が挙げられる。なお、AlphaBlendは、次のとおりである。
BOOL AlphaBlend(HDC hdcDest, int nXDest, int nYDest, int nDestWidth,
int nDestHeight, HDC hdcSrc, int nXSrc, int nYSrc,
int nSrcWidth, int nSrcHeight, BLENDFUNCTION BlendFunction);
ここで、hdcDestはコピー先のデバイスコンテキストのハンドル、nXDestはコピー先の左上隅の論理単位のx座標、nYDestはコピー先の左上隅の論理単位のy座標、nDestWidthはコピー先の長方形の論理単位の幅、nDestHeightはコピー先の長方形の論理単位の高さ、hdcSrcはコピー元のデバイスコンテキストのハンドル、nXSrcはコピー元の左上隅の論理単位のx座標、nYSrcはコピー元の左上隅の論理単位のy座標、nSrcWidthはコピー元の長方形の論理単位の幅、nSrcHeightはコピー元の長方形の論理単位の高さ、BlendFunctionはAlphaBlendを行う関数を指定する構造体である。この場合、out = OP(src, dst, pat)の形に抽象化したとき、src = Screen、dst = Screen、pat = NULLである。また、out = (src OR dst)であるが、ここのORは、論理OR演算ではなく、BlendFunctionに基づく、AlphaBlendの結果である。オフスクリーンバッファから画面にAlphaBlendする場合は、src = Memoryとなる。
以上、いくつかの代表的な描画用API関数の抽象化について説明したが、この分野の当業者であれば、他の描画用API関数についても、同様の取り扱いが可能であることを理解するであろう。
【0055】
図2に戻って、画面表示領域108a内で新たな描画が行われ、または、オフスクリーンバッファ108bなどが画面表示領域108a内にコピーされて、新たな描画が発生するときは、それに対応して、画面ラベルマップ210aに対して、対応するセキュリティ・ラベルの領域の書き込みが行われる。ラベルマップ・テーブル210を主記憶106で管理する場合には、このコピーとして、memcpyなどの周期のコピー関数を用いることがだきる。また、ラベルマップ・テーブル210を、画像バッファ108の一部として管理する場合は、上述したBitBltを使うこともできる。
【0056】
このような度重なる画面ラベルマップ210aに対する書き込みで、ある領域のラベルが隣接する領域とラベルが一致した場合は、処理の便宜上、それらの領域は、統合される。これらのことは、後で、具体例に基づき説明することで、一層理解が深められるであろう。
【0057】
図5は、本発明のこの実施例に係る、ラベル割り当て処理のフローチャートである。このフローチャートは、図2の描画命令実行検出部222が、任意のアプリケーション・プログラム220a、220b、・・・において、描画命令を検出したときに開始される。ステップ502では、検出された描画命令が、上述したようにout = OP(src, dst, pat)の形式に抽象化される。
【0058】
尚、out = OP(src, dst, pat)によって、outの領域を考えたとき、それが描かれる元の画面ラベルマップ210aのラベルの分布によって、outはさまざまな条件の領域に分かれ得る。図5の様々な判断ステップは、そのようなoutの異なる条件の領域毎に判断と処理を行うものであることを理解されたい。
【0059】
ステップ504では、outにおいて、実行プロセスよりも高いラベルのsrcが、描画命令実行後に残るかどうかが判断される。これは、言い換えると、描画命令が、srcの上書き、またはsrcとpatの合成、またはsrcとdstの合成、またはsrc、dst及びpatの全ての合成であり、且つsrc領域のラベルとして実行プロセスのラベルより高いものが含まれていた場合である。
【0060】
ステップ504の判断がYesであると、ステップ506で、実行プロセスより高いラベルのsrc領域をマスク処理する描画命令に変換される。このことは、具体的には、実行プロセスより高いラベルのsrc領域の座標を検出して、その検出した座標範囲は、例えば、PatBltにより、黒塗りにするなどの方法をとる。この黒塗りの領域に対応する描画命令は、ラベル1のプロセスとして処理を行うようにする。これによって、outに対応するラベルマップ・テーブル領域には、ラベル1が書き込まれることになる。こうしておくことにより、再度ステップ502からステップ504の判断ステップに来たとき、その判断がyesにならないので、ステップ506には進まない。なお、検出した座標範囲のラベル値は、「1」にリセットする代わりに、実行プロセスと同じラベル値に設定してもよい。さらに、上記黒塗り処理は、要するに、その領域の画面情報を無意味なものにすればよいので、オリジナルの情報を隠蔽する、網掛け、白抜きなど任意の画面処理をもちいることができる。
【0061】
ステップ504での判断がNoであると、ステップ508で、outがpatで上書きまたは、srcとpatの合成かどうかが判断される。もしその判断がYesなら、ステップ510で、outの領域に、実行プロセスのラベルを割り当てる。
【0062】
ステップ508での判断がNoであると、ステップ512で、outがdstとpatの合成、または、srcとdstとpatの合成かが判断される。もしその判断がyesなら、ステップ514で、outにおいて、dstのラベルと、実行プロセスのラベルの高い方が割り当てる。
【0063】
ステップ512での判断がNoであると、ステップ516で、outがsrcで上書きかどうかが判断される。もしその判断がYesなら、ステップ518で、outにsrc領域のラベルを割り当て、そうでないなら、ステップ520で、outにdstの領域を割り当てる。
【0064】
次に、画面の図に従い、本発明の実施例の処理をより具体的に説明する。
【0065】
図6は、図1に示すハードウェア構成のコンピュータの起動直後の様子を示す。以下の図面では、画面表示領域108aと、それに対応する画面ラベルマップ210aを並置して示す。画面ラベルマップ210aとして、VRAM領域を使う場合、画面ラベルマップ210aの領域確保には、CreateBitmapなどのAPI関数を使用することができる。画面ラベルマップ210aとして、主記憶を使う場合、GlobalAllocなどのAPI関数を使用することができる。図6では、起動直後なので、画面表示領域108aには、何も表示されていないとする。一方、画面ラベルマップ210aには、デフォールトのセキュリティ・ラベル値として、全ビットマップに1が埋められる。このコピーには、画面ラベルマップ210aがVRAM領域を使う場合、BitBltを使用することができる。画面ラベルマップ210aが主記憶106にある場合は、memcpyなどを使用することができる。
【0066】
次に、図7に示すように、ラベル3のプロセスが、オフスクリーン・バッファに領域108bを確保し、そこにグラフを描画しようとする。これに従って、図2の描画命令実行検出部222が、そのラベル3のプロセスの描画命令を検出し、それに従って、描画命令解析部224が、ラベル割り当て部226に作用して、3という数字が埋められたオフスクリーン・ラベルマップ領域210bがラベルマップ・テーブル210に確保される。そして、画像処理制御部230が描画命令実行部232に作用し、これにより、画像命令実行検出部222が検出した描画命令を描画実行部232に引渡す。こうして、実際のグラフの描画が領域108bで行われるが、この段階では、オフスクリーン・バッファ領域108bに描かれたグラフは、まだ画面には見えない。
【0067】
次に、図8に示すように、ラベル3のプロセスが、グラフが描画されたオフスクリーン・バッファ領域108bを、BitBltを使って画面表示領域108aにコピーしようとする。すると、この描画命令は、描画命令実行検出部222により検出され、それに従って、描画命令解析部224が、ラベル割り当て部226に作用して、結果画像を計算する。その結果、実行プロセスよりも高レベルのsrcは残らないのでステップ504はNo、Patで上書きでもsrcとpatの合成でもないのでステップ508もNo、dstとpatの合成でもないのでステップ512もNoで、ステップ516で、srcで上書きかどうかの判断で初めてYesになる。従って、ステップ518で、srcのラベル3が割り当てられて、図8に示すように、画面ラベルマップ210aに、オフスクリーン・ラベルマップ領域210bがコピーされ、領域802となる。これに従い、画像処理制御部230が描画命令実行部232に作用し、これにより、画像命令実行検出部222が検出した描画命令を描画実行部232に引渡す。このことは、オフスクリーン・バッファ領域108bの画面ラベルマップ210aへのコピーをもたらし、そうしてコピーされた画像804は、ユーザーに見えるようになる。
【0068】
図9では、ラベル2を割り当てられた別のプロセスが、ラベル3の領域の一部を上書きするように別のグラフ904を表示することを試みる。このとき、このラベル2を割り当てられたプロセスによって表示されるoutの中に、ラベル2よりもラベルが高い領域は残されないので、ステップ504はNoになって、ステップ508もステップ512もNoで、ステップ516でのsrcで上書きかどうかの判断がyesになり、ステップ518で、オフスクリーン・ラベルマップ領域210bにおいて、outの領域902でのラベル2の割り当てが行われる。このことにより、実際の画面ラベルマップ210aで、画像904が、ラベル3の領域の一部を上書きするように表示する、ということが許可される。
【0069】
図10では、ラベル2を割り当てられたさらに別のプロセスが、既に描かれているラベル3の領域804の一部と、既に描かれているラベル2の領域904の両方を上書きするように、半透明の領域1006を表示することを試みる。このとき、このラベル2を割り当てられたプロセスによって表示されるoutの中に、ラベル2よりもラベルが高い領域は残されないので、ステップ504はNoであり、patで上書きでもなく、srcとpatの合成でもないのでステップ508もNoであるが、ステップ512での、srcとdstの合成か、という判断が、領域804と領域1006との重なりの部分でYesになり、その部分については、ステップ514が適用されて、すなわち、dst領域のラベルと、実行プロセスのラベルの高い方が割り当てられるので、領域804と領域1006との重なりの部分のラベルは3となる。また、領域1006に対応するラベルも、領域904に対応するラベルもともに2なので、それらは、ラベルマップ領域210aではマージされて、図10に示すようになる。
【0070】
次に、図11に示すように、ラベル2を割り当てられた、またさらに別のプロセスが、オフスクリーンバッファ上に、空白の領域1102を確保する。これに対応して、ラベルマップ・テーブル210に、ラベル2の領域1104が、ラベル割り当て部226によって確保される。
【0071】
次に、図12に示すように、空白の領域1102を確保したのと同一のラベル2のプロセスが、破線で示す領域1202領域を、領域1102にコピーしようと試みたとする。そのようなコピーは、BitBltのような描画命令を発行するので、描画命令実行検出部222により検出され、図5のフローチャートの判断が行われる。
【0072】
そこで、領域1202の、領域1102へのコピーを想定してみると、典型的には図12の画面ラペルマップ210aを参照すると見て取れるように、outとなるべきラベル2の領域1104に、ラベル3の領域1004が入ってくることになる。このことは、実行プロセスにより高ラベルのsrcが描画命令に残ることを意味するので、領域1004に対応して、ステップ504での判断でのYesを引き起こし、それにより、ステップ506では、画像処理制御部230によって、画面ラペルマップ210aのラベル3の領域1004に対応する画像表示領域からの、オフスクリーンバッファ1102へのコピーが、BitBltではなく、PatBltの黒の塗りつぶしに置き換えられる。従って、図12に示すように、オフスクリーン・バッファ1102にコピーされてきたときは、ラベル3の領域の見えている部分が、黒塗りでコピーされて、そこだけ見えなくなっている。これによって、ラベルが相対的に低いプロセスに、ラベルが相対的に高いプロセスの内容がコピーされるのが防げるので、セキュリティ的な保護が提供される。なお、図5のステップ506に関連して説明したように、黒の塗りつぶしは、ラベル1の描画プロセスに置き換えられるので、オフスクリーン・ラベルマップ1104は、図12に示すように、画面ラペルマップ210aの対応src領域において、ラベル3の領域を、ラベル1に書き換えた状態になる。
【0073】
尚、図10で表示した半透明の領域には、「XYZ Confidential」という文字が入っている。ウインドウへの文字の表示は、TextOutというAPI関数を使って行うことができるので、このようの文字列出力自体を、図2の描画命令実行検出部222は検出可能である。従って、"xxx confidential"のような特定の文字列出力を含むAPI関数を検出することに応答して、そのプロセスのラベルを1つ増やすか、あるいは、ある既定の絶対値に設定するようにしてもよい。
【0074】
また、背景のにじみ処理を伴う半透明合成処理の場合は、にじみの度合いとフォントサイズのパラメータの一方または両方に基づき、可読性が低下したと判断して、そのプロセスのラベルを1つ減らしてもよい。このような検出処理を行う処理ブロックは、図2には明示的に示されていないが、にじみの度合いもフォントサイズも、適当なAPI関数で取得できるので、そのような機能を追加することは可能である。
【0075】
このようなラベルの変更処理は、図2の描画命令解析部224の機能を拡張することによって行うことができる。
【0076】
また、上記実施例では、オペレーティング・システム上で走る監視プログラムより描画命令を監視することによって、ラベルマップを操作し、以って所望の画面のセキュリティ管理機能を達成しているが、オペレーティング・システムのソースコードを作成・編集できる権限を有し、またはその立場にある場合は、本発明の機能を、オペレーティング・システムのネイティブな機能として、実装するようにしてもよい。
【図面の簡単な説明】
【0077】
【図1】本発明を実施するためのコンピュータのハードウェアのブロック図である。
【図2】本発明の実施例に係るラベルマップ管理機構の機能ブロック図である。
【図3】描画監視の機能を実現するための構成の1つの例を示すブロック図である。
【図4】描画監視の機能を実現するための構成の別の例を示すブロック図である。
【図5】本発明の実施例に係るラベルマップ管理処理のフローチャートである。
【図6】画面領域と画面ラベルマップの対応を示す図である。
【図7】画面領域と画面ラベルマップの対応を示す図である。
【図8】画面領域と画面ラベルマップの対応を示す図である。
【図9】画面領域と画面ラベルマップの対応を示す図である。
【図10】画面領域と画面ラベルマップの対応を示す図である。
【図11】画面領域と画面ラベルマップの対応を示す図である。
【図12】画面領域と画面ラベルマップの対応を示す図である。
【技術分野】
【0001】
この発明は、一般的には、コンピュータのセキュリティ管理に関し、より詳しくは、コンピュータに接続された画面における出力情報を保護するための技術に関するものである。
【背景技術】
【0002】
近年、コンプライアンス強化や個人情報保護のために、コンピュータリソースに対するアクセス制御をきめ細かく行う必要性が増大している。そのために、機密情報を含んだファイルへのアクセス制御や、クリップボードやプロセス間通信を介した機密情報のフロー制御を行う様々な方法が実用化されている。
【0003】
しかし、ファイルのアクセス権やクリップボードの情報の管理をするだけでは、情報の最終的な出力デバイスである画面上の情報セキュリティ管理を効果的に行うことはできない。
【0004】
すなわち、画面上に出力された画像データを保護するための確実な手法がないと、折角、機密情報を含んだファイルそのもののアクセス権を設定しても、機密情報を含んだ画面上ののデータを、どのプロセスからでも自由に読み込みを許してしまうことになる。
【0005】
VMWareやVirtual PCなどのコンピュータ仮想技術により、ゲストOS間の画面情報の隔離を行うことは可能である。しかし、この技術では、ホストOSからはゲストOSの画面を自由に読むことを許してしまうため、ホストOSに悪意あるソフトウェアが潜んでいると、ゲストOSの画面上の機密情報が不正に持ち出される危険性を防ぎきれない。
【0006】
また、NSA(米国国家安全保障局)のSecured X Window Systemは、独立した仮想デスクトップ画面上に機密情報を表示することで、他のデスクトップ画面内のプロセスと、画面を分離することを可能ならしめる。但し、この技術では、ビデオメモリ上の画像データは保護されないので、バックグラウンドプロセスが自由に画像情報を読み取ることを許してしまう。
【0007】
特開平11−249965は、ビデオメモリに格納したビデオデータに従ってディスプレイ装置の表示画面上に表示処理を行なうコンピュータシステムにおいて、表示画面上に表示するウインドウ単位の画面情報を管理するためのウインドウ管理テーブルを設け、ウインドウ単位の画面情報の表示指示に応じてウインドウ管理テーブルを更新すると共に、当該画面情報のコピー処理のプロテクトを指示するためのコピープロテクト情報を前記ウインドウ管理テーブルに設定し、表示画面上に表示処理されたウインドウ単位の画面情報に対するコピー要求を受けたときに、ウインドウ管理テーブルを参照してコピー要求対象の画面情報に対してコピープロテクト情報が設定されている場合にはビデオメモリから画面情報に対応するビデオデータのコピー処理を禁止するようにすることを開示する。
【0008】
特開2007−34685は、電子ペーパに表示する各コンテンツの機密性保持等を実現するためのシステムであって、このシステムは、利用制限記憶手段をもち、この利用制限記憶手段がコンテンツ毎の利用制限情報を保持し、表示制御手段が表示部へコンテンツの表示内容を利用制限情報に応じた態様で書き込む。そうして、利用制限情報に応じて、表示部に表示するドキュメント中の或るコンテンツを表示する又は表示しない等の態様とすることにより、コンテンツの機密性保持や同一性維持等をコンテンツの利用を制限することで実現する。また、ユーザからの確認要求に応じて、利用制限記憶手段に保持した利用制限情報を表示部2に書き込んでユーザに提示する。
【0009】
特開2007−52655は、予め規定されている範囲内に立ち入る利用者に関連付けられている認証情報を取得する手段と、前記取得された認証情報が、前記ドキュメントに関連付けられている表示許可条件を満たすか否かを判断する手段と、前記認証情報が前記表示許可条件を満たさない場合に、前記ドキュメントの前記表示部への表示を制限する制限手段と、を含むドキュメント表示制御装置を開示する。
【0010】
特開2007−65846は、本出願人と同一の出願人に係る発明であり、オペレーティングシステム上で第1および第2アプリケーションプログラムを含む複数のアプリケーションプログラムを並行に動作させる情報処理装置であって、第1アプリケーションプログラムからオペレーティングシステムに対する関数呼び出し、または、第1アプリケーションプログラムおよびオペレーティングシステム間で送受信されるメッセージを監視する監視部と、監視部による監視結果に基づいて、第2アプリケーションプログラムからオペレーティングシステムに対する関数呼び出し、若しくは、第2アプリケーションプログラムおよびオペレーティングシステム間のメッセージ送受信の処理を変更または禁止する制御部とを備える情報処理装置を開示する。本願発明の1つの背景技術として参考までに示す。
【0011】
これらの従来技術によれば、特定の目的に対しては、有効に画面のセキュリティ保護が達成される。しかし、これらの従来技術では、最近になって、GUI環境で採用されつつある半透明ウインドウに適切に対処できないし、表示されている文字列情報やフォントサイズなどに応じた、柔軟なセキュリティ管理も難しい。
【特許文献1】特開平11−249965
【特許文献2】特開2007−34685
【特許文献3】特開2007−52655
【特許文献4】特開2007−65846
【発明の開示】
【発明が解決しようとする課題】
【0012】
この発明は、上記問題点を解決するためになされたものであり、表示されるウインドウの属性、描画結果などを考慮して、柔軟且つ効果的な表示情報のセキュリティ管理を実現することを可能とする技術を提供ことを目的とする。
【課題を解決するための手段】
【0013】
上記目的は、マルチウインドウ・システムなどのグラフィック・ユーザ・インターフェースをもつコンピュータ・システムにおいて、描画命令が実行されるたびに、どのような情報が描画結果に継承されるかを、好適には画像処理などの複雑なステップを経ないで、描画命令の論理演算パターンから判断し、それと同時に、画面やメモリ上の画像と一対一に対応するラベル付けされた領域マップを管理することで、画面に出力された画像の情報フロー制御を実施することによって、達成される。
【0014】
本発明は、各プロセスによるグラフィクスデバイスへの描画命令実行を検出する描画命令実行検出部と、前記描画命令実行検出部が検出した描画命令の種別およびパラメータを解析することにより描画命令実行後の画像状態を判定する描画命令解析部と、描画命令解析部の判定結果に基づき描画領域にラベル付けを行うラベル割り当て部と、画面およびオフスクリーンバッファのラベルを管理するラベルマップ管理部と、実際に描画命令を実行する描画命令実行部と、さらに、描画命令実行検出部が画面またはオフスクリーンバッファからの画像読み込みを検出したときに、読み込み元領域のラベルに応じて読み込み元の画像を処理する画像処理制御部で構成される。
【0015】
本発明によれば、先ず、各プロセス内に監視モジュールが常駐させられる。そうして、監視モジュールは、プロセスによるグラフィックスデバイスに対する描画命令を監視する。
【0016】
監視モジュールは、プロセスが画像データを書き込む際に、描画プロセスの属性や描画命令の内容に応じて、描画領域に対してセキュリティラベルを割り当てる。描画領域には、画面上の可視領域のほかに、オフスクリーンバッファ上の不可視領域も含む。本発明は、ここで、描画命令種別およびパラメータを解析し、描画領域の既存画像(Destination)、描画演算の処理対象画像(Source)、パラメータで指定された画像要素(Pattern)の論理演算の結果、描画命令実行後にどの画像情報が残されるかを判定し、その結果に応じてセキュリティラベルを割り当てる。
【0017】
一方、監視モジュールは、プロセスが画面上またはオフスクリーンバッファ上の画像データを読み込む際に、プロセスのセキュリティラベルと、読み込もうとする画面領域のセキュリティラベルとを比較し、読み込み命令の可否を判定する。画面領域のセキュリティラベルが、読み込みプロセスのセキュリティラベルより高い場合は、読み込み命令を失敗させるか、あるいは、領域内の画像情報が、セキュリティラベルの低いプロセスに伝わらないように、墨塗りやマスク処理した画像データを返す。
【0018】
本発明により、画面上に出力された機密情報は、適切なセキュリティラベルを割り当てたプロセスしか読み出せなくなるため、悪意あるプログラムや一般プログラムは、画面上の機密情報画像を取得できない。その結果、画面スナップショットを取得されて機密情報が漏洩する危険性が避けられる。
【発明の効果】
【0019】
この発明によれば、描画命令が実行されるたびに、どのような情報が描画結果に継承されるかを、描画命令の論理演算パターンから判断して、アクセス制御するので、悪意あるプログラムや一般プログラムからの画面上の機密情報画像へのアクセスを効果的に禁止できるとともに、半透明ウインドウなどの場合にも、適切なセキュリティラベルを割り当てることによって、柔軟にアクセス制御を行うことができる。
【発明を実施するための最良の形態】
【0020】
以下、図面を参照して、本発明の一実施例の構成及び処理を説明する。以下の記述では、特に断わらない限り、図面に亘って、同一の要素は同一の符号で参照されるものとする。なお、ここで説明する構成と処理は、一実施例として説明するものであり、本発明の技術的範囲をこの実施例に限定して解釈する意図はないことを理解されたい。
【0021】
図1を参照すると、本発明の一実施例に係るシステム構成及び処理を実現するためのコンピュータ・ハードウェアのブロック図が示されている。図1において、システム・パス102には、CPU104と、主記憶(RAM)106と、ビデオメモリ(VRAM)108と、ハードディスク・ドライブ(HDD)110と、キーボード112と、マウス114と、ディスプレイ116が接続されている。CPU104は、好適には、32ビットまたは64ビットのアーキテクチャに基づくものであり、例えば、インテル社のPentium(商標) 4、AMD社のAthlon(商標)などを使用することができる。主記憶106は、好適には、512KB以上の容量をもつものである。ビデオメモリ108は、ディスプレイ116に画面出力するためのイメージを保持するために使用される。
【0022】
ハードディスク・ドライブ110には、個々に図示しないが、オペレーティング・システム及び本発明に係る処理プログラム、及びそのワードプロセッサ、表計算プログラム、プレゼンテーション作成プログラム、データベース・プログラムなどのアプリケーション・プログラムが、予め格納されている。オペレーティング・システムは、Linux(商標)、マイクロソフト社のWindows XP(商標)、Windows(商標)2000、アップルコンピュータのMac OS(商標)などの、マルチウインドウのグラフィック・ユーザー・インターフェースをサポートし、CPU104に適合する任意のものでよい。なお、以下の説明では、便宜上、オペレーティング・システムとして、Windows XP(商標)を使用し、APIとしてWin32 APIを使用するものとして説明する。しかし、この分野の当業者なら、Linux(商標)などの他のオペレーティング・システムでも、同等のAPIを具備していることを理解するであろう。
【0023】
ハードディスク・ドライブ110にはまた、後述する本発明に係るセキュリティ管理プログラムが格納されている。このセキュリティ管理プログラムは、オペレーティング・システムのグラフィックス・ライブラリの呼び出しを監視し得る機能を記述可能な、C、C++、C#、Java(商標)などの任意のプログラム言語処理系で書かれている。
【0024】
ディスプレイ116は、これには限定されないが、好適には、1024×768以上の解像度をもち、32ビットtrue colorのLCDモニタである。
【0025】
キーボード110及びマウス112は、オペレーティング・システムが提供するグラフィック・ユーザ・インターフェースに従い、ディスプレイ116に表示されたアイコン、タスクバー、ウインドウなどのグラフィック・オブジェクトを操作するために使用される。
【0026】
図2は、この実施例の論理構成のブロック図である。図2において、VRAM108中には、画面表示領域108aと、複数のオフスクリーン・バッファ108b、オフスクリーン・バッファ108c、オフスクリーン・バッファ108d・・・が存在する。個々のオフスクリーン・バッファは、アプリケーション・プログラムによって、作成、変更またはクリアされる。但し、アプリケーション・プログラムがオフスクリーン・バッファを作成しただけでは、それは、ディスプレイ116(図1)の画面には反映されず、画面表示領域108aにコピーされてはじめて、画面に見える状態となる。例えば、ウインドウが最小化された、あるアプリケーション・プログラムが、画像を作成する命令を実行し、その結果がオフスクリーン・バッファの変更をもたらすことがあり得る。しかし、そのようなオフスクリーン・バッファの変更は、最小化されたアプリケーション・プログラムのウインドウが復元、あるいは最大化されるまで、画面表示領域108aには反映されず、すなわち、それまではユーザーに見えない。
【0027】
オフスクリーン・バッファ108b、オフスクリーン・バッファ108c、108d・・・は、基本的に、VRAM108中に確保されるが、VRAM108に十分な空き領域がなくなったなどの場合、主記憶106中に確保される。
【0028】
ラベル・マップ・テーブル210は、本発明で利用される特徴的な構成の1つであり、好適には、VRAM108中に、CreateBitmap、CreateCompatibleBitmapなどのAPI関数を呼び出すなどして、確保される。主記憶106中に確保する場合は、通常のGlobalAllocのようなAPI関数を用いることができる。ラベル・マップ・テーブル210は、画面ラベルマップ210aと、オフスクリーン・バッファ・ラベルマップ210b、210c、210d・・・とからなり、それぞれ、画面表示領域108a、複数のオフスクリーン・バッファ108b、108c、108d・・・に個別に対応している。しかし、オフスクリーン・バッファに格納されているのは、画面に対する描画内容であるが、オフスクリーン・バッファ・ラベルマップに格納されているのは、セキュリティ・レベルである。各々のオフスクリーン・バッファ・ラベルマップには、単一のセキュリティラベルを割り当てることができる。セキュリティラベルを割り当てるとは、この実施例では、オフスクリーン・バッファ・ラベルマップとして、CreateBitmapなどのAPI関数により割り当てられたビットマップ領域全体に、セキュリティラベル(例えば、1)を書き込むことである。本発明では、画面ラベルマップ210a上での、オフスクリーン・バッファ・ラベルマップの論理演算に基づき、アクセス制御が行われるが、その詳細は動作は、後で説明する。
【0029】
図2の上方を参照すると、複数のアプリケーション・プログラム220a、220b、220c・・・が示されている。これらのアプリケーション・プログラムは、一般的には、ディスク110に保存され、キーボード112及びマウス114の操作に応答して、オペレーティング・システムの機能によって、ディスク110から主記憶106にロードされ、実行される。
【0030】
本発明によれば、複数のアプリケーション・プログラム220a、220b、220cには、1〜3のようなセキュリティ・ラベルが付与される。ここでは、その数字が多いほど、セキュリティ・ラベルが高いとする。アプリケーション・プログラム、あるいはアプリケーション・プログラムが生成するプロセスにセキュリティ・レベルを付与する技術としては、例えば、特開2007−65846に記載されている技術がある。これにより開示される技術は、オペレーティング・システム上で、アプリケーション・プログラム間で送受信されるメッセージを監視し、別途記述されているポリシーに基づき、処理の変更、禁止などを行う。なお、以下の説明では、特開2007−65846の文脈におけるセキュリティ・レベルと、ここでアプリケーション・プログラムに付与されるセキュリティ・ラベルを同一視する。
【0031】
下記は、ファイル毎にセキュリティ・ラベルを設定するポリシーの例であり、<Rule RuleId="urn:rule1">が、設定されるセキュリティ・レベルを記述する。すなわち、urn:rule1以外に、"urn:rule0, "urn:rule2など複数用意しておく。また、<AttributeValue DataType="file:path"> 〜 </AttributeValue>のところで、そのセキュリティ・ラベルが適用されるアプリケーション・プログラムを記述する。
<!-- Group 1 -->
<Rule RuleId="urn:rule1">
<Description>Deny clipboad copy and print by notepad and calc</Description>
<Subjects>
<Subject>
<AttributeValue DataType="file:path">calc.exe</AttributeValue>
</Subject>
<Subject>
<AttributeValue DataType="file:path">notepad.exe</AttributeValue>
</Subject>
</Subjects>
<Resources>
<Resource DataType="clipboard" Lib="SBLCLIP">
<!-- クリップボードへのコピー禁止 -->
<AttributeValue DataType="clipboard:type">
<AnyClipboardDataType/>
</AttributeValue>
<Actions>
<Action Effect="Deny">write</Action>
</Actions>
</Resource>
...........
...........
</Rule>
【0032】
同様に、アプリケーション・プログラムによって生成されるプロセス毎に、セキュリティ・レベルを設定することが可能であるが、このような機能自体、本発明の要旨ではないので、これ以上の詳しい説明は省略する。必要に応じて、特開2007−65846その他の従来技術を参照されたい。なお、上記ポリシーには明示していないが、セキュリティ・ラベルを指定していないアプリケーション・プログラムには、最低レベルのセキュリティ・ラベルを付与するのが望ましい。これによって、素性の分からないアプリケーション・プログラムが、意図しない状況でビデオ・メモリから機密情報を取得することが防止される。
【0033】
さて、図2に戻って、描画命令実行機能検出部222は、上述のような機能を使用して、アプリケーション・プログラム220a、220b、220cが発行する描画命令を監視する。併せて、それらのアプリケーション・プログラムがそれらの描画命令を発行したプロセスのセキュリティ・レベルを取得する。そのような典型的な描画命令として、BitBlt、及びStretchBltがある。
【0034】
描画命令解析部224は、描画命令実行機能検出部222が検出した描画命令の種別やパラメータを解析し、描画命令実行の結果、どのような画像が、画面に残るかを判別する。
【0035】
ラベル割り当て部226は、アプリケーション・プログラムまたはプロセスに割り当てられたセキュリティ・レベルを参照して、画面ラベルマップ210a上に割り当てられるラベル値を決定する。なお、この実施例の説明では、アプリケーション・プログラムのセキュリティ・レベルと、それに対応するラベルマップのラベルとを同一のものとして説明することに留意されたい。
【0036】
ラベルマップ管理部228は、VRAM108の空き領域、または主記憶106などで、画面やオフスクリーンのラベルを管理する。
【0037】
画像処理制御部230は、ラベルマップを参照しながら、読み込みの可否を判断して、マスク処理などを実施する。
【0038】
描画命令実行部232は、描画を行う機能部であり、一つの実施例では、描画が実際に行われるように、オペレーティング・システムに、描画API関数を引き渡す。
【0039】
図3は、本発明が利用可能な、アプリケーション・プログラム監視の仕組みの概要を示す図である。一番下のレイヤ302は、グラフィックス・デバイスのハードウェアであり、その上に、グラフィックス・デバイスのハードウェアのメーカから提供される、グラフィックス・ドライバのレイヤ304がある。レイヤ304の上には、Win32グラフィックサブシステムを実現するWin32k.sysデバイス・ドライバのレイヤ306があり、その上に、具体的なグラフィック関係のAPI関数呼び出しを含む、GDI32.DLLのレイヤ308がある。そうして、GDI32.DLLと各アプリケーション・プログラムの間に、API監視モジュール310が介在し、アプリケーション・プログラムが発行するグラフィック関係のAPI関数呼び出しを監視する。このような監視機能は、図2の描画命令実行検出部232が行う。この監視モジュールの技法は、基本的に、本出願人に係る特開2007−65846で開示されているものである。
【0040】
図4は、本発明が利用可能な、アプリケーション・プログラム監視の別の仕組みの概要を示す図である。図4の実施例の、図3の実施例との違いは、アプリケーション・プログラム個別のAPI監視モジュール310を、GDI32.DLLとアプリケーション・プログラムの間に介在させることなく、その代わりに、グラフィックス・ドライバのレイヤ304と、Win32k.sysデバイス・ドライバのレイヤ306の間に、DDI監視ドライバのレイヤ402を置くことで、GDI32.DLLからグラフィックス・ドライバに送られる描画命令を、DDI監視ドライバが監視する。このような監視機能は、図2の描画命令実行検出部232が行う。この監視モジュールの技法は、基本的に、本出願人に係る特開2002−278526で開示されているものである。
【0041】
図3の監視機構の場合、ウインドウのクリッピング処理を、API監視モジュール310が行う必要があるが、図4の監視機構の場合、DDI監視ドライバに、クリッピング処理された可視領域情報が伝わるため、クリッピング処理する手間が省ける。
【0042】
次に、図2の描画命令実行検出部222が利用する、描画命令監視モジュールの機能について説明する。この描画命令監視モジュールは、この実施例では、図3のAPI監視モジュール310または、図4のDDI監視ドライバ402である。
【0043】
先ず、前提として、各プロセスには、適当なセキュリティ・レベルとしてのラベルが割り当られる。ここでは、ラベル値が高いほど機密性の高い情報を扱うと仮定する。そのとき、例えば特開2007−65846に記載されている方法で、管理者が事前にプロセスごとに割り当ててもよい。あるいは、本出願人に係る、2007年5月31日に出願の米国特許出願第11/755769号に記載されている技法により、開いているファイルやネットワークアドレス、画面出力文字情報などのコンテキストに応じて動的に割り当ててもよい。
【0044】
一方、描画命令監視モジュールは、各プロセスによって描画命令が発行されるたびに、画面上およびオフスクリーンバッファ上の描画領域に対して、描画プロセスの属性や描画命令の内容に応じたセキュリティ・ラベルの割り当てを行う。
【0045】
描画命令監視モジュールは、まず、描画命令の種別およびパラメータを解析し、描画命令を以下の演算式に抽象化する。
out = OP(src, dst, pat)
ここで、OPは描画命令種別(Operation)、srcは処理対象画像(Source)、dstは描画領域既存画像(Destination)、patは演算に用いる画像要素(Pattern)を意味する。また、outは、描画命令実行後の画像を意味する。srcとdstは、画面上の可視領域(Screen)の場合もあるし、VRAM108または主記憶106(memory)上のオフスクリーンバッファの場合もある。
【0046】
例えば、画面上の画像を別領域に移動する命令は、
OP = SourceCopy
src = Screen
dst = Screen
pat = NULL
out = src
と表現する。
【0047】
特定の画面領域を黒く塗りつぶすときは、
OP = PatternCopy
src = NULL
dst = Screen
pat = Black
out = pat
と表現する。
【0048】
オフスクリーンバッファから画面へのビットマップ半透明描画命令は、
OP = AlphaBlend
src = Memory
dst = Screen
pat = NULL
out = (src OR dst)
と表現する。
【0049】
特定の画面領域の反転表示は、
OP = DestInvert
src = NULL
dst = Screen
pat = NULL
out = (NOT dst)
と表現する。
【0050】
描画命令種別は、src, dst, patの論理演算パターンに応じて256種類存在する。さらに、描画を行わない命令として、オフスクリーンメモリの作成命令 CreateBitmap等も含む。描画命令監視モジュールは、このように描画命令を抽象化した上で、描画先領域の既存画像(Destination)が、描画命令によりどのように処理されるかを判定する。そうして、描画命令監視モジュールは、判定結果により、以下のように、描画先領域のセキュリティ・ラベルを決める。
【0051】
描画命令実行により、描画先領域の既存画像が塗りつぶされる場合、描画命令発行元のプロセスのセキュリティ・ラベルまたはソース領域のセキュリティ・ラベルを割り当てる。この種の命令の例として、ビットブロック転送を行うBitBltがあり、下記のような引数をとる。
BOOL BitBlt(HDC hdcDest, int nXDest, int nYDest, int nWidth, int nHeight,
HDC hdcSrc, int nXSrc, int nYSrc, DWORD dwRop);
ここで、hdcDestはコピー先のデバイスコンテキストのハンドル、nXDestはコピー先の左上隅の論理単位のx座標、nYDestはコピー先の左上隅の論理単位のy座標、nWidthはコピー先の長方形の論理単位の幅、nHeightはコピー先の長方形の論理単位の高さ、hdcSrcはコピー元のデバイスコンテキストのハンドル、nXSrcはコピー元の左上隅の論理単位のx座標、nYSrcはコピー元の左上隅の論理単位のy座標、dwRopは、ラスターオペレーションコードである。dwRop = SRCCOPYの場合、コピー元の長方形を、コピー先の長方形としてそのままコピーする処理が行われる。この場合、out = OP(src, dst, pat)の形に抽象化したとき、指定したパターンで埋める訳ではないので、pat = NULLである。また、dwRop = SRCCOPYとすることにより、画面から画面へのブロック転送であるので、OP = SourceCopyで、src = Screen、 dst = Screen、out = srcである。オフスクリーンバッファから画面に書く場合は、src = Memoryとなる。また、dstとして、オフスクリーンバッファを選ぶこともでき、その場合は、dst = Memoryとなる。
【0052】
別の例として、ブラシを使って長方形領域を描画するPatBltを挙げてみると、
BOOL PatBlt(HDC hdc, int nXLeft, int nYLeft, int nWidth,
int nHeight, DWORD dwRop);
ここで、hdcはデバイスコンテキストのハンドル、nXLeftは長方形領域の左上隅の論理単位のx座標、nYLeftは長方形領域の左上隅の論理単位のy座標で、out = OP(src, dst, pat)の形に抽象化したとき、
dwRop = PATCOPYとすることにより、src = NULL、 dst = Screen、OP = PatternCopyで、out = patである。ここで、patとは、デバイスコンテキストで現在選択されているブラシによるパターンである。
【0053】
描画命令実行により、描画先領域の既存画像情報がそのまま残る場合は、既存ラベルを継承する。この種の命令の例として、ラスターオペレーションコードにDSTINVERT(デスティネーション反転)を指定したBitBltがある。この場合、src = NULL、dst = Screen、pat = NULL、out = NOT (dst) となる。
【0054】
描画命令実行により、既存画像と新規画像の合成結果が表示される場合は、既存ラベルと新規ラベルの高いほうを割り当てる。この種の命令の例として、ラスターオペレーションコードにMERGECOPY(コピー元とコピー先のAND演算)を指定したBitBltや、AlphaBlend(半透明描画)が挙げられる。なお、AlphaBlendは、次のとおりである。
BOOL AlphaBlend(HDC hdcDest, int nXDest, int nYDest, int nDestWidth,
int nDestHeight, HDC hdcSrc, int nXSrc, int nYSrc,
int nSrcWidth, int nSrcHeight, BLENDFUNCTION BlendFunction);
ここで、hdcDestはコピー先のデバイスコンテキストのハンドル、nXDestはコピー先の左上隅の論理単位のx座標、nYDestはコピー先の左上隅の論理単位のy座標、nDestWidthはコピー先の長方形の論理単位の幅、nDestHeightはコピー先の長方形の論理単位の高さ、hdcSrcはコピー元のデバイスコンテキストのハンドル、nXSrcはコピー元の左上隅の論理単位のx座標、nYSrcはコピー元の左上隅の論理単位のy座標、nSrcWidthはコピー元の長方形の論理単位の幅、nSrcHeightはコピー元の長方形の論理単位の高さ、BlendFunctionはAlphaBlendを行う関数を指定する構造体である。この場合、out = OP(src, dst, pat)の形に抽象化したとき、src = Screen、dst = Screen、pat = NULLである。また、out = (src OR dst)であるが、ここのORは、論理OR演算ではなく、BlendFunctionに基づく、AlphaBlendの結果である。オフスクリーンバッファから画面にAlphaBlendする場合は、src = Memoryとなる。
以上、いくつかの代表的な描画用API関数の抽象化について説明したが、この分野の当業者であれば、他の描画用API関数についても、同様の取り扱いが可能であることを理解するであろう。
【0055】
図2に戻って、画面表示領域108a内で新たな描画が行われ、または、オフスクリーンバッファ108bなどが画面表示領域108a内にコピーされて、新たな描画が発生するときは、それに対応して、画面ラベルマップ210aに対して、対応するセキュリティ・ラベルの領域の書き込みが行われる。ラベルマップ・テーブル210を主記憶106で管理する場合には、このコピーとして、memcpyなどの周期のコピー関数を用いることがだきる。また、ラベルマップ・テーブル210を、画像バッファ108の一部として管理する場合は、上述したBitBltを使うこともできる。
【0056】
このような度重なる画面ラベルマップ210aに対する書き込みで、ある領域のラベルが隣接する領域とラベルが一致した場合は、処理の便宜上、それらの領域は、統合される。これらのことは、後で、具体例に基づき説明することで、一層理解が深められるであろう。
【0057】
図5は、本発明のこの実施例に係る、ラベル割り当て処理のフローチャートである。このフローチャートは、図2の描画命令実行検出部222が、任意のアプリケーション・プログラム220a、220b、・・・において、描画命令を検出したときに開始される。ステップ502では、検出された描画命令が、上述したようにout = OP(src, dst, pat)の形式に抽象化される。
【0058】
尚、out = OP(src, dst, pat)によって、outの領域を考えたとき、それが描かれる元の画面ラベルマップ210aのラベルの分布によって、outはさまざまな条件の領域に分かれ得る。図5の様々な判断ステップは、そのようなoutの異なる条件の領域毎に判断と処理を行うものであることを理解されたい。
【0059】
ステップ504では、outにおいて、実行プロセスよりも高いラベルのsrcが、描画命令実行後に残るかどうかが判断される。これは、言い換えると、描画命令が、srcの上書き、またはsrcとpatの合成、またはsrcとdstの合成、またはsrc、dst及びpatの全ての合成であり、且つsrc領域のラベルとして実行プロセスのラベルより高いものが含まれていた場合である。
【0060】
ステップ504の判断がYesであると、ステップ506で、実行プロセスより高いラベルのsrc領域をマスク処理する描画命令に変換される。このことは、具体的には、実行プロセスより高いラベルのsrc領域の座標を検出して、その検出した座標範囲は、例えば、PatBltにより、黒塗りにするなどの方法をとる。この黒塗りの領域に対応する描画命令は、ラベル1のプロセスとして処理を行うようにする。これによって、outに対応するラベルマップ・テーブル領域には、ラベル1が書き込まれることになる。こうしておくことにより、再度ステップ502からステップ504の判断ステップに来たとき、その判断がyesにならないので、ステップ506には進まない。なお、検出した座標範囲のラベル値は、「1」にリセットする代わりに、実行プロセスと同じラベル値に設定してもよい。さらに、上記黒塗り処理は、要するに、その領域の画面情報を無意味なものにすればよいので、オリジナルの情報を隠蔽する、網掛け、白抜きなど任意の画面処理をもちいることができる。
【0061】
ステップ504での判断がNoであると、ステップ508で、outがpatで上書きまたは、srcとpatの合成かどうかが判断される。もしその判断がYesなら、ステップ510で、outの領域に、実行プロセスのラベルを割り当てる。
【0062】
ステップ508での判断がNoであると、ステップ512で、outがdstとpatの合成、または、srcとdstとpatの合成かが判断される。もしその判断がyesなら、ステップ514で、outにおいて、dstのラベルと、実行プロセスのラベルの高い方が割り当てる。
【0063】
ステップ512での判断がNoであると、ステップ516で、outがsrcで上書きかどうかが判断される。もしその判断がYesなら、ステップ518で、outにsrc領域のラベルを割り当て、そうでないなら、ステップ520で、outにdstの領域を割り当てる。
【0064】
次に、画面の図に従い、本発明の実施例の処理をより具体的に説明する。
【0065】
図6は、図1に示すハードウェア構成のコンピュータの起動直後の様子を示す。以下の図面では、画面表示領域108aと、それに対応する画面ラベルマップ210aを並置して示す。画面ラベルマップ210aとして、VRAM領域を使う場合、画面ラベルマップ210aの領域確保には、CreateBitmapなどのAPI関数を使用することができる。画面ラベルマップ210aとして、主記憶を使う場合、GlobalAllocなどのAPI関数を使用することができる。図6では、起動直後なので、画面表示領域108aには、何も表示されていないとする。一方、画面ラベルマップ210aには、デフォールトのセキュリティ・ラベル値として、全ビットマップに1が埋められる。このコピーには、画面ラベルマップ210aがVRAM領域を使う場合、BitBltを使用することができる。画面ラベルマップ210aが主記憶106にある場合は、memcpyなどを使用することができる。
【0066】
次に、図7に示すように、ラベル3のプロセスが、オフスクリーン・バッファに領域108bを確保し、そこにグラフを描画しようとする。これに従って、図2の描画命令実行検出部222が、そのラベル3のプロセスの描画命令を検出し、それに従って、描画命令解析部224が、ラベル割り当て部226に作用して、3という数字が埋められたオフスクリーン・ラベルマップ領域210bがラベルマップ・テーブル210に確保される。そして、画像処理制御部230が描画命令実行部232に作用し、これにより、画像命令実行検出部222が検出した描画命令を描画実行部232に引渡す。こうして、実際のグラフの描画が領域108bで行われるが、この段階では、オフスクリーン・バッファ領域108bに描かれたグラフは、まだ画面には見えない。
【0067】
次に、図8に示すように、ラベル3のプロセスが、グラフが描画されたオフスクリーン・バッファ領域108bを、BitBltを使って画面表示領域108aにコピーしようとする。すると、この描画命令は、描画命令実行検出部222により検出され、それに従って、描画命令解析部224が、ラベル割り当て部226に作用して、結果画像を計算する。その結果、実行プロセスよりも高レベルのsrcは残らないのでステップ504はNo、Patで上書きでもsrcとpatの合成でもないのでステップ508もNo、dstとpatの合成でもないのでステップ512もNoで、ステップ516で、srcで上書きかどうかの判断で初めてYesになる。従って、ステップ518で、srcのラベル3が割り当てられて、図8に示すように、画面ラベルマップ210aに、オフスクリーン・ラベルマップ領域210bがコピーされ、領域802となる。これに従い、画像処理制御部230が描画命令実行部232に作用し、これにより、画像命令実行検出部222が検出した描画命令を描画実行部232に引渡す。このことは、オフスクリーン・バッファ領域108bの画面ラベルマップ210aへのコピーをもたらし、そうしてコピーされた画像804は、ユーザーに見えるようになる。
【0068】
図9では、ラベル2を割り当てられた別のプロセスが、ラベル3の領域の一部を上書きするように別のグラフ904を表示することを試みる。このとき、このラベル2を割り当てられたプロセスによって表示されるoutの中に、ラベル2よりもラベルが高い領域は残されないので、ステップ504はNoになって、ステップ508もステップ512もNoで、ステップ516でのsrcで上書きかどうかの判断がyesになり、ステップ518で、オフスクリーン・ラベルマップ領域210bにおいて、outの領域902でのラベル2の割り当てが行われる。このことにより、実際の画面ラベルマップ210aで、画像904が、ラベル3の領域の一部を上書きするように表示する、ということが許可される。
【0069】
図10では、ラベル2を割り当てられたさらに別のプロセスが、既に描かれているラベル3の領域804の一部と、既に描かれているラベル2の領域904の両方を上書きするように、半透明の領域1006を表示することを試みる。このとき、このラベル2を割り当てられたプロセスによって表示されるoutの中に、ラベル2よりもラベルが高い領域は残されないので、ステップ504はNoであり、patで上書きでもなく、srcとpatの合成でもないのでステップ508もNoであるが、ステップ512での、srcとdstの合成か、という判断が、領域804と領域1006との重なりの部分でYesになり、その部分については、ステップ514が適用されて、すなわち、dst領域のラベルと、実行プロセスのラベルの高い方が割り当てられるので、領域804と領域1006との重なりの部分のラベルは3となる。また、領域1006に対応するラベルも、領域904に対応するラベルもともに2なので、それらは、ラベルマップ領域210aではマージされて、図10に示すようになる。
【0070】
次に、図11に示すように、ラベル2を割り当てられた、またさらに別のプロセスが、オフスクリーンバッファ上に、空白の領域1102を確保する。これに対応して、ラベルマップ・テーブル210に、ラベル2の領域1104が、ラベル割り当て部226によって確保される。
【0071】
次に、図12に示すように、空白の領域1102を確保したのと同一のラベル2のプロセスが、破線で示す領域1202領域を、領域1102にコピーしようと試みたとする。そのようなコピーは、BitBltのような描画命令を発行するので、描画命令実行検出部222により検出され、図5のフローチャートの判断が行われる。
【0072】
そこで、領域1202の、領域1102へのコピーを想定してみると、典型的には図12の画面ラペルマップ210aを参照すると見て取れるように、outとなるべきラベル2の領域1104に、ラベル3の領域1004が入ってくることになる。このことは、実行プロセスにより高ラベルのsrcが描画命令に残ることを意味するので、領域1004に対応して、ステップ504での判断でのYesを引き起こし、それにより、ステップ506では、画像処理制御部230によって、画面ラペルマップ210aのラベル3の領域1004に対応する画像表示領域からの、オフスクリーンバッファ1102へのコピーが、BitBltではなく、PatBltの黒の塗りつぶしに置き換えられる。従って、図12に示すように、オフスクリーン・バッファ1102にコピーされてきたときは、ラベル3の領域の見えている部分が、黒塗りでコピーされて、そこだけ見えなくなっている。これによって、ラベルが相対的に低いプロセスに、ラベルが相対的に高いプロセスの内容がコピーされるのが防げるので、セキュリティ的な保護が提供される。なお、図5のステップ506に関連して説明したように、黒の塗りつぶしは、ラベル1の描画プロセスに置き換えられるので、オフスクリーン・ラベルマップ1104は、図12に示すように、画面ラペルマップ210aの対応src領域において、ラベル3の領域を、ラベル1に書き換えた状態になる。
【0073】
尚、図10で表示した半透明の領域には、「XYZ Confidential」という文字が入っている。ウインドウへの文字の表示は、TextOutというAPI関数を使って行うことができるので、このようの文字列出力自体を、図2の描画命令実行検出部222は検出可能である。従って、"xxx confidential"のような特定の文字列出力を含むAPI関数を検出することに応答して、そのプロセスのラベルを1つ増やすか、あるいは、ある既定の絶対値に設定するようにしてもよい。
【0074】
また、背景のにじみ処理を伴う半透明合成処理の場合は、にじみの度合いとフォントサイズのパラメータの一方または両方に基づき、可読性が低下したと判断して、そのプロセスのラベルを1つ減らしてもよい。このような検出処理を行う処理ブロックは、図2には明示的に示されていないが、にじみの度合いもフォントサイズも、適当なAPI関数で取得できるので、そのような機能を追加することは可能である。
【0075】
このようなラベルの変更処理は、図2の描画命令解析部224の機能を拡張することによって行うことができる。
【0076】
また、上記実施例では、オペレーティング・システム上で走る監視プログラムより描画命令を監視することによって、ラベルマップを操作し、以って所望の画面のセキュリティ管理機能を達成しているが、オペレーティング・システムのソースコードを作成・編集できる権限を有し、またはその立場にある場合は、本発明の機能を、オペレーティング・システムのネイティブな機能として、実装するようにしてもよい。
【図面の簡単な説明】
【0077】
【図1】本発明を実施するためのコンピュータのハードウェアのブロック図である。
【図2】本発明の実施例に係るラベルマップ管理機構の機能ブロック図である。
【図3】描画監視の機能を実現するための構成の1つの例を示すブロック図である。
【図4】描画監視の機能を実現するための構成の別の例を示すブロック図である。
【図5】本発明の実施例に係るラベルマップ管理処理のフローチャートである。
【図6】画面領域と画面ラベルマップの対応を示す図である。
【図7】画面領域と画面ラベルマップの対応を示す図である。
【図8】画面領域と画面ラベルマップの対応を示す図である。
【図9】画面領域と画面ラベルマップの対応を示す図である。
【図10】画面領域と画面ラベルマップの対応を示す図である。
【図11】画面領域と画面ラベルマップの対応を示す図である。
【図12】画面領域と画面ラベルマップの対応を示す図である。
【特許請求の範囲】
【請求項1】
画像データを読み書き可能なメモリをもつコンピュータにおいて、セキュリティ・ラベルを関連付けられたアプリケーション・プログラムの描画命令によって、前記メモリ上の画像データを画面に表示する際に、画面の情報を保護するシステムであって、
前記画面に対応するセキュリティ・ラベル・マップ情報を、前記メモリ上にもつラベル・マップ記憶手段と、
前記アプリケーション・プログラムが前記メモリ上の読取領域を指定して前記メモリから画像データを読取る命令を検出する検出手段と、
前記検出手段の検出に応答して、前記読取領域に対応するセキュリティ・ラベル・マップ情報を、前記ラベルマップ記憶手段上で確認し、前記アプリケーション・プログラムのセキュリティ・ラベルが、前記読取領域のセキュリティ・ラベルより低いことに応答して、前記アプリケーション・プログラムの、前記読取領域からの情報の読取動作を禁止する制御手段とを有する、
画面情報保護システム。
【請求項2】
前記読取領域からの情報の読取動作の禁止は、該読取り情報の宛先への書込み命令を、塗りつぶしの命令に書き換えることによって行われる、請求項1に記載の画面情報保護システム。
【請求項3】
前記アプリケーション・プログラムによる、前記ビデオメモリの領域への書込み命令に応答して、前記ラベルマップ記憶手段の対応する領域に、該セキュリティラベルの情報を書き込む手段をさらに有する、請求項1に記載の画面情報保護システム。
【請求項4】
前記ラベルマップ記憶手段は、前記メモリの、前記画面に対応しない領域に配置される、請求項1に記載の画面情報保護システム。
【請求項5】
前記読取領域に特定の文字があることに応答して、前記読取領域のセキュリティ・ラベルを変更する手段をさらに有する請求項1に記載の画面情報保護システム。
【請求項6】
前記読取領域のフォントサイズ、にじみ度の一方または両方に応答して、前記読取領域のセキュリティ・ラベルを変更する手段をさらに有する請求項1に記載の画面情報保護システム。
【請求項7】
画像データを読み書き可能なメモリをもつコンピュータにおいて、セキュリティ・ラベルを関連付けられたアプリケーション・プログラムの描画命令によって、前記メモリ上の画像データを画面に表示するシステムにおいて、前記画面の情報を保護する方法であって、
前記画面に対応するセキュリティラベルマップ情報を、ラベルマップ記憶手段に書き込むステップと、
前記アプリケーション・プログラムが前記メモリ上の読取領域を指定して前記メモリから画像データを読取る命令を検出するステップと、
前記検出に応答して、前記読取領域に対応するセキュリティラベルマップ情報を、前記ラベルマップ記憶手段上で確認するステップと、
前記アプリケーション・プログラムのセキュリティラベルが、前記読取領域のセキュリティラベルより低いことに応答して、前記アプリケーション・プログラムの、前記読取領域からの読取動作を禁止するステップを有する、
コンピュータの画面の情報の保護方法。
【請求項8】
前記書き込むステップは、前記アプリケーション・プログラムによる、前記ビデオメモリの領域への書き込み命令に応答して行われ、前記ラベルマップ記憶手段に書き込まれるセキュリティラベルは、該アプリケーション・プログラムのセキュリティラベルに関連付けられている、請求項7の方法。
【請求項9】
前記禁止するステップは、前記読取領域から読み取られる情報が宛先領域に書き込まれる際に、該書込み命令を予定の描画パターン書込み命令に置き換えるステップを含む、請求項7の方法。
【請求項10】
前記読取領域に特定の文字があることに応答して、前記読取領域のセキュリティ・ラベルを変更するステップをさらに有する請求項7に記載の方法。
【請求項11】
前記読取領域のフォントサイズ、にじみ度の一方または両方に応答して、前記読取領域のセキュリティ・ラベルを変更するステップをさらに有する請求項7に記載の方法。
【請求項12】
画像データを読み書き可能なメモリをもつコンピュータにおいて、セキュリティ・ラベルを関連付けられたアプリケーション・プログラムの描画命令によって、前記のメモリ上の画像データを画面に表示するためのシステムにおいて、前記画面の情報を保護するように前記コンピュータを動作させるプログラムであって、
前記コンピュータをして、
前記画面に対応するセキュリティラベルマップ情報を、前記メモリ上のラベルマップ記憶手段に書き込むステップと、
前記アプリケーション・プログラムが前記メモリ上の読取領域を指定して前記メモリから画像データを読取る命令を検出するステップと、
前記検出に応答して、前記読取領域に対応するセキュリティラベルマップ情報を、前記ラベルマップ記憶手段上で確認するステップと、
前記アプリケーション・プログラムのセキュリティラベルが、前記読取領域のセキュリティラベルより低いことに応答して、前記アプリケーション・プログラムの、前記読取領域からの読取動作を禁止するステップを実行させる、
プログラム。
【請求項13】
前記書き込むステップは、前記アプリケーション・プログラムによる、前記ビデオメモリの領域への書き込み命令に応答して行われ、前記ラベルマップ記憶手段に書き込まれるセキュリティラベルは、該アプリケーション・プログラムのセキュリティラベルに関連付けられている、請求項12のプログラム。
【請求項14】
前記禁止するステップは、前記読取領域から読み取られる情報が宛先領域に書き込まれる際に、該書込み命令を、予定の描画パターン書込み命令に置き換えるステップを含む、請求項12のプログラム。
【請求項15】
前記読取領域に特定の文字があることに応答して、前記読取領域のセキュリティ・ラベルを変更するステップをさらに有する請求項12に記載のプログラム。
【請求項16】
前記読取領域のフォントサイズ、にじみ度の一方または両方に応答して、前記読取領域のセキュリティ・ラベルを変更するステップをさらに有する請求項12に記載のプログラム。
【請求項1】
画像データを読み書き可能なメモリをもつコンピュータにおいて、セキュリティ・ラベルを関連付けられたアプリケーション・プログラムの描画命令によって、前記メモリ上の画像データを画面に表示する際に、画面の情報を保護するシステムであって、
前記画面に対応するセキュリティ・ラベル・マップ情報を、前記メモリ上にもつラベル・マップ記憶手段と、
前記アプリケーション・プログラムが前記メモリ上の読取領域を指定して前記メモリから画像データを読取る命令を検出する検出手段と、
前記検出手段の検出に応答して、前記読取領域に対応するセキュリティ・ラベル・マップ情報を、前記ラベルマップ記憶手段上で確認し、前記アプリケーション・プログラムのセキュリティ・ラベルが、前記読取領域のセキュリティ・ラベルより低いことに応答して、前記アプリケーション・プログラムの、前記読取領域からの情報の読取動作を禁止する制御手段とを有する、
画面情報保護システム。
【請求項2】
前記読取領域からの情報の読取動作の禁止は、該読取り情報の宛先への書込み命令を、塗りつぶしの命令に書き換えることによって行われる、請求項1に記載の画面情報保護システム。
【請求項3】
前記アプリケーション・プログラムによる、前記ビデオメモリの領域への書込み命令に応答して、前記ラベルマップ記憶手段の対応する領域に、該セキュリティラベルの情報を書き込む手段をさらに有する、請求項1に記載の画面情報保護システム。
【請求項4】
前記ラベルマップ記憶手段は、前記メモリの、前記画面に対応しない領域に配置される、請求項1に記載の画面情報保護システム。
【請求項5】
前記読取領域に特定の文字があることに応答して、前記読取領域のセキュリティ・ラベルを変更する手段をさらに有する請求項1に記載の画面情報保護システム。
【請求項6】
前記読取領域のフォントサイズ、にじみ度の一方または両方に応答して、前記読取領域のセキュリティ・ラベルを変更する手段をさらに有する請求項1に記載の画面情報保護システム。
【請求項7】
画像データを読み書き可能なメモリをもつコンピュータにおいて、セキュリティ・ラベルを関連付けられたアプリケーション・プログラムの描画命令によって、前記メモリ上の画像データを画面に表示するシステムにおいて、前記画面の情報を保護する方法であって、
前記画面に対応するセキュリティラベルマップ情報を、ラベルマップ記憶手段に書き込むステップと、
前記アプリケーション・プログラムが前記メモリ上の読取領域を指定して前記メモリから画像データを読取る命令を検出するステップと、
前記検出に応答して、前記読取領域に対応するセキュリティラベルマップ情報を、前記ラベルマップ記憶手段上で確認するステップと、
前記アプリケーション・プログラムのセキュリティラベルが、前記読取領域のセキュリティラベルより低いことに応答して、前記アプリケーション・プログラムの、前記読取領域からの読取動作を禁止するステップを有する、
コンピュータの画面の情報の保護方法。
【請求項8】
前記書き込むステップは、前記アプリケーション・プログラムによる、前記ビデオメモリの領域への書き込み命令に応答して行われ、前記ラベルマップ記憶手段に書き込まれるセキュリティラベルは、該アプリケーション・プログラムのセキュリティラベルに関連付けられている、請求項7の方法。
【請求項9】
前記禁止するステップは、前記読取領域から読み取られる情報が宛先領域に書き込まれる際に、該書込み命令を予定の描画パターン書込み命令に置き換えるステップを含む、請求項7の方法。
【請求項10】
前記読取領域に特定の文字があることに応答して、前記読取領域のセキュリティ・ラベルを変更するステップをさらに有する請求項7に記載の方法。
【請求項11】
前記読取領域のフォントサイズ、にじみ度の一方または両方に応答して、前記読取領域のセキュリティ・ラベルを変更するステップをさらに有する請求項7に記載の方法。
【請求項12】
画像データを読み書き可能なメモリをもつコンピュータにおいて、セキュリティ・ラベルを関連付けられたアプリケーション・プログラムの描画命令によって、前記のメモリ上の画像データを画面に表示するためのシステムにおいて、前記画面の情報を保護するように前記コンピュータを動作させるプログラムであって、
前記コンピュータをして、
前記画面に対応するセキュリティラベルマップ情報を、前記メモリ上のラベルマップ記憶手段に書き込むステップと、
前記アプリケーション・プログラムが前記メモリ上の読取領域を指定して前記メモリから画像データを読取る命令を検出するステップと、
前記検出に応答して、前記読取領域に対応するセキュリティラベルマップ情報を、前記ラベルマップ記憶手段上で確認するステップと、
前記アプリケーション・プログラムのセキュリティラベルが、前記読取領域のセキュリティラベルより低いことに応答して、前記アプリケーション・プログラムの、前記読取領域からの読取動作を禁止するステップを実行させる、
プログラム。
【請求項13】
前記書き込むステップは、前記アプリケーション・プログラムによる、前記ビデオメモリの領域への書き込み命令に応答して行われ、前記ラベルマップ記憶手段に書き込まれるセキュリティラベルは、該アプリケーション・プログラムのセキュリティラベルに関連付けられている、請求項12のプログラム。
【請求項14】
前記禁止するステップは、前記読取領域から読み取られる情報が宛先領域に書き込まれる際に、該書込み命令を、予定の描画パターン書込み命令に置き換えるステップを含む、請求項12のプログラム。
【請求項15】
前記読取領域に特定の文字があることに応答して、前記読取領域のセキュリティ・ラベルを変更するステップをさらに有する請求項12に記載のプログラム。
【請求項16】
前記読取領域のフォントサイズ、にじみ度の一方または両方に応答して、前記読取領域のセキュリティ・ラベルを変更するステップをさらに有する請求項12に記載のプログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公開番号】特開2009−59038(P2009−59038A)
【公開日】平成21年3月19日(2009.3.19)
【国際特許分類】
【出願番号】特願2007−223850(P2007−223850)
【出願日】平成19年8月30日(2007.8.30)
【出願人】(390009531)インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】INTERNATIONAL BUSINESS MASCHINES CORPORATION
【Fターム(参考)】
【公開日】平成21年3月19日(2009.3.19)
【国際特許分類】
【出願日】平成19年8月30日(2007.8.30)
【出願人】(390009531)インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】INTERNATIONAL BUSINESS MASCHINES CORPORATION
【Fターム(参考)】
[ Back to top ]