JP4089171B2 - 計算機システム - Google Patents
計算機システム Download PDFInfo
- Publication number
- JP4089171B2 JP4089171B2 JP2001125224A JP2001125224A JP4089171B2 JP 4089171 B2 JP4089171 B2 JP 4089171B2 JP 2001125224 A JP2001125224 A JP 2001125224A JP 2001125224 A JP2001125224 A JP 2001125224A JP 4089171 B2 JP4089171 B2 JP 4089171B2
- Authority
- JP
- Japan
- Prior art keywords
- file
- access
- access control
- computer system
- unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2211/00—Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
- G06F2211/009—Trust
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2113—Multi-level security, e.g. mandatory access control
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Storage Device Security (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は情報処理システムに保管されているファイルへの不正アクセスを防止し、高い安全性を確保するための技術に関する。
【０００２】
【従来の技術】
計算機を用いた情報処理システムにおいては、多くのアプリケーションプログラムを実行させるための基本的な仕組みを提供するOS (Oprerating System)を用いてハードウェア資源の有効活用を図るのが一般的である。
【０００３】
さらに、当該情報処理システムでのファイルの保護は、主として、上記OSが備える一機能であるファイルアクセス制御機能を用いて実現している。
現在、広範に利用されているOSでは、ファイルアクセス制御を、任意アクセス制御(Discretionary Access Control、DACとも記す)に基づいて行うことが多い。これは、ファイルの所有者(一般には、ファイルの作成者と一致する)であるユーザが、当該ファイルに対して、アクセスできるユーザ、および、アクセスの種類（読み取りのみ、読み取りと変更など）を任意に設定し、それに基づいてアクセス制御を行うものである。
また、通常このようなOSでは、システム管理者と呼ばれる特殊な権限をもつユーザは、当該情報処理システム内のすべての設定を変更することが可能である。
【０００４】
一方、高いセキュリティが要求される場面での利用を想定して作られた専用OSの中には、より厳格なアクセス制御方法である、強制アクセス制御(必須アクセス制御とも言う)(Mandatory Access Control、MACとも記す)に基づくファイルアクセス制御機能を備えたものがある。たとえば、セキュアシステムの評価基準のひとつである米国のTCSEC(Trusted ComputerSystem Evaluation Criteria)に定められたクラスのうち、クラスB1以上に認定されるためには、強制アクセス制御機能を備えなければならない。
TCSECおよび強制アクセス制御については、
文献[TCSEC]：「Department of Defense Trusted Computer System Evaluation Criteria」アメリカ国防総省標準（DOD 5200.28-STD）
に詳しい。
【０００５】
強制アクセス制御を備えた情報処理システムにおいては、すべてのファイルには、セキュリティレベル(例えば、高い方から「機密 (top secret)」「極秘 (secret)」「秘密 (confidential)」「一般 (unclassified)」など)が設定され、また、すべてのユーザに対し、信頼度、すなわち、アクセスできるファイルのセキュリティレベルを示す許可レベル(クリアランス(clearance)という。例えば、高い方から「機密」「極秘」「秘密」「一般」など))が設定される。システムは、これらの情報に基づいて強制的にアクセス制御を行う。
【０００６】
上記のような専用OSでは、システム管理者とは異なる、セキュリティ管理者とよばれるユーザによって、ファイルのセキュリティレベルや他のユーザのクリアランスなど、セキュリティに関わる機能が管理されていることが多い。これにより、ファイル作成者だけでなくシステム管理者であっても当該情報処理システムのセキュリティを下げることができないようになり、より安全なシステムの運用が可能となる。
【０００７】
【発明が解決しようとする課題】
ファイルへの不正アクセスを防ぐ仕組みを任意アクセス制御に基づくアクセス制御機能を備えたOSに依存している情報処理システムでは、各ファイルの所有者であるユーザが、当該ファイルのアクセス可能な範囲を設定できてしまうため、ユーザの故意、または、不注意により、重要な情報が漏洩してしまう恐れがある。
【０００８】
一方、強制アクセス制御機能を備えたOSを利用した情報処理システムでは、当該OSが一般的ではないため、ユーザが利用するアプリケーションプログラムを独自に開発する必要があり、コストがかさむ上、ユーザの利便性が失われる。
上記背景の元、コストがかからず、安全性を高められる技術が求められている。
【０００９】
【課題を解決するための手段】
本発明は、情報処理システムの情報セキュリティに関する安全性を、利用者の利便性を損なうことなく、向上させる技術を提供する。
本発明は、また、情報処理システム内にシステム管理者とは異なる、資格を持つユーザだけが利用できる機能・領域を設けるための方法、および、装置を提供する。
本発明は、また、上記技術を適用した情報処理システムに対する、起動時における不正を防止するための方法、および、装置を提供する。
【００１０】
より具体的には、既存のアプリケーションプログラムを利用可能な状態を保ちつつ、情報処理システムに強制アクセス制御機能を付加する技術と、その技術を適用した情報処理システムを提供する。
また、強制アクセス制御機能をもたないOSの管理の元で既存のアプリケーションプログラムが動作する情報処理システムに、強制アクセス制御機能を付加する技術と、その技術を適用した情報処理システムを提供する。
【００１１】
本発明の一態様によれば、ユーザが直接利用する、アプリケーションプログラムを動作させるためのOS(ホストOSという)と、セキュリティ強化のためのOS(ゲストOSという)の２つのOSを、複数OS制御技術を利用することにより動作させる。複数OS制御技術は、たとえば、特開平11-149385号公報に開示されている。
本発明に従えば、上記専用OSを用いることなく、ホストOS上で動作するファイル作成者だけでなく、システム管理者であっても、セキュリティレベルを変えることが非常に困難になる。
【００１２】
より具体的には、アクセス監視処理プログラムはホストOS管理下で行われるファイルアクセスを監視し、ゲストOS上のファイルアクセス制御プログラムは、アクセス監視処理プログラムが検知したファイルアクセスの正当性を、ファイルのセキュリティレベルと、ユーザのクリアランスに従って判断し、不正アクセスを許さない。
また、ホストOSの各種設定を行うシステム管理者とは、別に、セキュリティ管理者を設け、システム管理者であっても、セキュリティレベルを変更できないようにする。システム全体のセキュリティポリシーとして、システム管理者が、セキュリティ管理者の権限を有することが許される場合には、これら２つの管理者を同一人が兼任してもよい。
【００１３】
本発明の他の一態様によれば、ゲストOS上に、アクセス制御機能を設けることにより、アクセス制御機能に対する不正操作を防止する。
また、本発明の他の一態様によれば、ホストOS側の多機能化・高機能化等の改良が行われても、強制アクセス制御が可能な環境を維持することを可能とする。さらに、ユーザのクリアランスやファイルのセキュリティレベルの設定にあたっては、セキュリティ管理者の認証を行うことにより、ホストOS側の管理者による不正の脅威を減らすことができるようになる。
【００１４】
なお、本発明におけるOSとは、ユーザーまたはプログラムからの要求に応じて記憶媒体中のデータ、ファイルへのアクセスを実行する機能と、アクセス要求元のユーザーやプログラムを識別する機能と、排他制御機能により占有する記憶部を有するプログラムモジュールを意味しており、
（１）ファイルアクセスを管理しており、検知が可能である。
（２）アクセス要求元のユーザーを識別できる。
（３）アクセス要求元のアプリケーションプログラムを識別できる。
といった特徴を持つ。したがって、上記特徴を持つものであれば、本発明のOSに含めることが可能である。
【００１５】
【発明の実施の形態】
図１は、本実施例による情報処理システムの構成例である。コンピュータ１００１内には、コンピュータ内の各OSや各プログラム（処理部とも言う）を実行するCPU１００３、ホストOS１０１７が管理するメモリA１００５、および、ゲストOS１０１９が管理するメモリB１００７があり、さらに、キーボード１０１１、マウスなどの入力装置、ディスプレイ１００９などの出力装置、ホストOS１０１７の管理下にあるハードディスクA１０１３、ゲストOS１０１９の管理下にあるハードディスクB１０１５などの記憶装置がつながっている。なお、記憶装置は、ハードディスクの他、フラッシュメモリや、EEPROMなど書き換え可能な不揮発性メモリであってもよい。さらには、ハードウェア的な耐タンパ性を持っているほうが望ましい。
【００１６】
メモリA１００５内には、ホストOS１０１７と、さらにホストOS１０１７管理下で動作する一般のアプリケーションプログラム１０２１の他、本実施例では、ユーザのクリアランスを定義するラベル付けを行うユーザラベル設定プログラム１０２３、各ファイルのセキュリティレベルを定義するラベル付けを行うファイルラベル設定プログラム１０２５が、ハードディスクＡ１０１３からロードされる。また、ホストOS１０１７内には、ファイル管理を行う部分として、I/Oマネージャ１０２７、ファイルシステムドライバ１０３１、デバイスドライバ１０３３がある他、本実施例では、さらに、アプリケーションからハードディスクA１０１３内のファイル１０４５へのアクセスをフックする、ファイルアクセスフックプログラム１０２９が設けられる。
【００１７】
ファイルへのアクセスをフックするとは、ハードディスクA１０１３等の記憶媒体内のファイルへのアクセスが発生しようとしていることを、何らかの方法によって検知することである。
ファイルアクセスのフックは、たとえば、あらかじめOSによって用意されたインターフェイス、たとえばファイルシステムドライバ１０３１やデバイスドライバ１０３３などの各種ドライバ用に用意されたインターフェイスを利用することが可能である。
すなわち、本実施例のように、I/Oマネージャ１０２７と、ファイルシステムドライバ１０３１との間に、I/Oマネージャ１０２７からは、ファイルシステムドライバ１０３１に対して命令するように見え、また逆に、ファイルシステムドライバ１０３１からは、I/Oマネージャ１０２７から命令されたかのように見える、ファイルアクセスフックプログラム１０２９を設ければ、ファイルアクセスが発生していることを、I/Oマネージャ１０２７による命令によって認識することができる。一般的に、OSには、各種デバイスを統一的に管理し、また、様々な機能拡張に対応することができるように、このようなインターフェイスが用意されているし、さらに、ファイルアクセスフックのための専用のインターフェイスが用意されていることもある。
この他、図示されていないが、ホストOS１０１７は、一般にOSが備える機能を実現する部分、すなわち、プロセス管理、メモリ管理などを担う部分を備える。
【００１８】
メモリB１００７内には、ゲストOS１０１９と、さらにゲストOS１０１９管理下で動作する、アクセス制御プログラム１０３５、ユーザリスト管理プログラム１０３７、ファイルリスト管理プログラム１０３９が、ハードディスクＢ１０１５からロードされる。ゲストOS１０１９の管理下にあるハードディスクB１０１５には、ユーザリスト管理プログラム１０３７が利用するユーザリスト１０４１、ファイルリスト管理プログラム１０３９が利用するファイルリスト１０４３が含まれている。
【００１９】
本実施例においては、ホストOS１０１７上のアプリケーションプログラム１０２１によるファイルアクセスは、ファイルアクセスフックプログラム１０２９によりフックされる。
アプリケーションプログラム１０２１から発行されたファイルアクセスを受けたI/Oマネージャ１０２７は、ファイルシステムドライバ１０３１に対してファイルアクセス命令を発行する。ファイルアクセスフックプログラム１０２９は、ファイルシステムドライバ１０３１の代わりにこの命令を受け取り、そのファイルアクセス命令をファイルシステムドライバ１０３１に渡す前に、複数OS制御プログラム１０４９内のOS間通信プログラム１０５１を用いて、ゲストOS１０１９上のアクセス制御プログラム１０３５に渡す。
【００２０】
アクセス制御プログラム１０３５は、当該ファイルアクセスが正当なものか否かを、ユーザリスト１０４１、および、ファイルリスト１０４３を元に判定し判定結果を返す。ファイルアクセスフックプログラム１０２９は、ファイルアクセスが不当であれば、当該ファイルアクセスを失敗させ、正当であれば要求どおりのファイルアクセス命令をファイルシステムドライバ１０３１に渡す。
【００２１】
本実施例では、アクセス制御プログラム１０３５を、ユーザがログインするホストOS１０１７管理下でなく、ゲストOS１０１９管理下で実行することにより、
（１）アクセス制御プログラム１０３５が不正な改変にさらされる脅威が少ない
（２）アクセス制御に関するプログラムのバグ等によるセキュリティホールがあるかどうかをチェックすべき範囲を限定できるため、メンテナンスが容易になる
（３）OSの多機能化・高機能化などによりホストOS１０１７が改良された場合にも、基本的な枠組みを変えることなく、アクセス制御を行うことができるため、OSの開発コストの削減が可能
などの利点が得られる。
【００２２】
本実施例においては、ファイルのセキュリティレベルとして「一般」、「秘密」、「極秘」、「機密」の４段階あり、この順に機密度合いが高くなる。また、対応するユーザのクリアランスとして、同様に「一般」、「秘密」、「極秘」、「機密」の４段階あり、この順に信頼度が高くなる。ファイルアクセスが正当であるか否かは、ファイルのセキュリティレベルとユーザのクリアランスとに基づいて判断される。
【００２３】
セキュリティレベルを何段階設けるかは、システムごとに自由に設定できる。ただし、ファイルのセキュリティレベルとユーザのクリアランスとは1対1に対応するように設定する。
【００２４】
さらに、それぞれのファイルとユーザは「人事部門」、「営業部門」、「企画部門」、「研究部門」の４つの区画(compartment)に所属させることができる。なお、区画の数はシステムごとに自由に設定できる。特に区画が１つの場合は、区画を設けなくてもよい。
【００２５】
各ユーザは、与えられたクリアランスと区画が同じで、かつ、機密度合いが同じか低いセキュリティレベルのファイルは、読み出し可能であり、与えられたクリアランスと区画が同じで、かつ、機密度合いが同じか高いセキュリティレベルのファイルは、書き込み、または、作成可能である。
見方を変えると、各ファイルは、与えられたセキュリティレベルと機密度合いが同じか低いクリアランスのユーザによる書き込みまたは作成は可能であり、機密度合いが同じか高いクリアランスのユーザによる読み出しは可能である。
【００２６】
強制アクセス制御においては、「極秘」のクリアランスを持つユーザAは、「一般」または「秘密」または「極秘」のセキュリティレベルのファイルを読むことはできるが、「機密」のセキュリティレベルのファイルを読むことはできない。また、ユーザAは、「機密」または「極秘」のセキュリティレベルのファイルに書き込むはできるが、「一般」または「秘密」のファイルに書き込むことはできない。
【００２７】
このように、読み取りが許可されるファイルのセキュリティレベルと、書き込みが許可されるファイルのセキュリティレベルが異なるのは、情報(ファイル)に設定されたセキュリティレベルが下げられてしまうことを防ぐためである。仮に、ユーザAが「一般」のファイルに書き込むことができてしまうとすると、もともと「極秘」であったファイルを、「一般」のファイルとして保存することができてしまい、結果的に、本来「一般」のクリアランスしか持たないユーザに「極秘」の情報が漏洩してしまう。強制アクセス制御では、このような危険性を防止できる。
【００２８】
本実施例の強制アクセス制御におけるファイルアクセスの種類（アクセスタイプという）として、ファイルを開いて内容を読み出すこと、ファイルの情報を書き換えること、新たにファイルを作成すること、を定義する。
ファイルの情報の書き換えにおいて、ファイルを開くかどうかは問わない。すなわち、「書き換えること」ができても「読み出すこと」ができないことがあり得る。つまり、読み取りできない(内容のわからない)ファイルの内容を書き換えることができる権利をもつことがありえる。これによって、クリアランスの低いユーザが高いセキュリティレベルのファイルを書き換える際に、情報が漏れることを防ぐ。
【００２９】
さらに、書き換えについては、ファイルのセキュリティレベルを下げられないようにするという目的を達成するためであれば、元のファイル情報の書き換えを含む書き込みを許してもよいが、クリアランスの低いユーザによって、高いセキュリティレベルの情報を書き換えられることを避けるという観点からは、たとえば追記のみを許すようにしてもよい。
【００３０】
すなわち、ファイル内の情報を減らすようなファイルアクセスを「削除」と呼び、ファイル内の情報を増やすようなファイルアクセスを「追記」と呼ぶとすると、情報の不正な漏洩を防ぐという目的だけであれば、与えられたクリアランスと区画が同じで、かつ、機密度合いが同じか高いセキュリティレベルのファイルに対して、「削除」と「追記」の両方を許すようにしてもよいし、情報の改竄を防ぐという目的からは、「削除」は許さず「追記」を許すようにしてもよい(この場合、たとえば、機密度合いが同じ場合のみ「削除」を許すようにしてもよい)。
【００３１】
ユーザのクリアランスは、セキュリティ管理者がユーザラベル設定プログラム１０２３を利用することによって、たとえば、ホストOS１０１７上で最初にユーザ登録を行うときに設定する。あるいは、当該ユーザが最初に何らかのファイルアクセスを行おうとしたときに、当該ファイルアクセスをフックすることにより、ユーザラベル設定プログラム１０２３を自動的に起動するようにしてもよい。ユーザラベル設定プログラム１０２３の起動が設定されていない場合には、ユーザのクリアランスが設定されていない状態で(すなわち、ゲストOS１０１９側で管理されているユーザリスト１０４１に当該ユーザに関するクリアランスが登録されていない状態で)、ファイルアクセスが発生する可能性があるが、この場合には、システムのセキュリティポリシーにあわせて、たとえば、いかなるファイルアクセスも許さないようにしてもよいし、あるいは、最も低いクリアランス（本実施例の場合は「一般」）が与えられているものとみなしてもよい。
【００３２】
ファイルのセキュリティレベルは、ユーザが当該ファイルを作成したときに、たとえばユーザが明示的に設定する。設定可能なセキュリティレベルは、当該ユーザのクリアランスによって決まる。すなわち、当該ユーザのクリアランスと同じかそれより高いセキュリティレベルを設定可能である。また、一度設定されたセキュリティレベルは、一般には、後から下げることはできないようにしたほうがセキュリティの観点からは望ましい。但し、利便性向上等の目的で、特別の権限を持つユーザ、例えばセキュリティ管理者、がファイルラベル設定プログラム１０２５を利用することにより、セキュリティレベルを下げられるようにしてもよい。
【００３３】
ユーザのクリアランスを設定するセキュリティ管理者と、ファイルのセキュリティレベルを設定するセキュリティ管理者は同一でもよいし、異なっていてもよい。さらには、それぞれの管理者は信頼できる複数の人であってもよい。たとえば、各区画ごとにユーザのクリアランスおよびファイルのセキュリティレベルを設定するセキュリティ管理者を設けてもよい。
【００３４】
図２を用いて、本実施例におけるファイルアクセス制御の処理フロー(読み出し、書き込み)を詳細に説明する。
ステップ２００１：はじめ
ステップ２００２：アプリケーションプログラム１０２１は、I/Oマネージャ１０２７を通じ、ファイルアクセスフックプログラム１０２９に対し、ファイルアクセスを要求
ステップ２００３：ファイルアクセスフックプログラム１０２９は、OS間通信プログラム１０５１を利用し、アクセス制御プログラム１０３５に、ユーザ名、ファイル名、アクセスの種類を送る。ユーザ名は、たとえば、アプリケーションプログラム１０２１に関するプロセスとそのプロセスを実行したユーザ名との対応情報を参照することによって取得できる。この対応情報は、ホストOS自身の持つ機能のひとつであるプロセス管理機能を実現するために使われるもので、ホストOSが保持している。
ステップ２００４：アクセス制御プログラム１０３５は、ユーザリスト１０４１およびファイルリスト１０４３を参照し、当該ユーザのクリアランス、および、当該ファイルのセキュリティレベルを調べる
ステップ２００５：アクセス制御プログラム１０３５は、正当なアクセスか否かを判定する。正当なアクセスであれば、ステップ２００８へ。不当なアクセスであれば、ステップ２００６へ
ステップ２００６：アクセス制御プログラム１０３５は「アクセス不可」を出力する。この判定結果はファイルフックプログラム１０２９、I/Oマネージャ１０２７を通じて、アプリケーションプログラム１０２１に伝えられる
ステップ２００７：おわり（アクセス不可）
ステップ２００８：アクセス制御プログラム１０３５は、ファイルフックプログラム１０２９を通じて、ファイルシステムドライバ１０３１に、ファイル名、アクセスの種類(アクセスタイプ)を送る
ステップ２００９：ファイルシステムドライバ１０３１は、デバイスドライバ１０３３に、対象となるファイル名に応じたハードディスクＡ１０１３内のアドレス、および、アクセスの種類を送る
ステップ２０１０：デバイスドライバ１０３３は、ハードディスクＡ１０１３から読み込み対象となっているファイルを読み出してアプリケーションプログラム１０２１に送る（読み込み時）、あるいは、ハードディスクＡ１０１３にアプリケーションプログラム１０２１が書き込もうとしている情報を書き込む（書き込み時）ステップ２０１１：おわり（アクセス成功）。
【００３５】
図３を用いて、本実施例におけるファイルアクセス制御の処理フロー(ファイル作成)を詳細に説明する。
ステップ３００１：はじめ
ステップ３００２：アプリケーションプログラム１０２１は、I/Oマネージャ１０２７を通じ、ファイルアクセスフックプログラム１０２９に対し、ファイルアクセス(ファイル作成)を要求
ステップ３００３：ファイルアクセスフックプログラム１０２９は、アプリケーションプログラム１０２１のユーザに対し、作成するファイルに設定するセキュリティレベルの入力を、そのためのユーザインタフェースを用いて、求める
ステップ３００４：ファイルアクセスフックプログラム１０２９は、OS間通信プログラム１０５１を利用し、アクセス制御プログラム１０３５に、ユーザ名、ファイル名、アクセスの種類(ファイル作成)、設定セキュリティレベルを送る。ユーザ名は、ステップ２００３と同様に取得できる。
ステップ３００５：アクセス制御プログラム１０３５は、ユーザリスト１０４１を参照し、当該ユーザのクリアランスを調べる
ステップ３００６：アクセス制御プログラム１０３５は、設定しようとしているセキュリティレベルが正当か否かを判定する。正当であれば、ステップ３００９へ。不当なアクセスであれば、ステップ３００７へ
ステップ３００７：アクセス制御プログラム１０３５は「アクセス不可」を出力する。この判定結果はファイルフックプログラム１０２９、I/Oマネージャ１０２７を通じて、アプリケーションプログラム１０２１に伝えられる
ステップ３００８：おわり（アクセス不可）
ステップ３００９：アクセス制御プログラム１０３５は、ゲストOS１０１９管理下のファイルリスト１０４３を更新し、I/Oマネージャ１０２７を通じて、ファイルシステムドライバ１０３１に、ファイル名、アクセスの種類(ファイル作成)を送る
ステップ３０１０：ファイルシステムドライバ１０３１は、ファイル名に応じたハードディスクＡ１０１３内のアドレスを割り当て、デバイスドライバ１０３３に、当該アドレスとアクセスの種類を送る
ステップ３０１１：デバイスドライバ１０３３は、ハードディスクＡ１０１３にアプリケーションプログラム１０２１が保存しようとしている情報を書き込む
ステップ３０１２：おわり（アクセス成功）。
【００３６】
図６は、本実施例におけるユーザリスト１０４１の一例である。１列目にファイル名６００１が示されており、２列目に当該ファイルのセキュリティレベル６００３が示されている。
【００３７】
図７は、本実施例におけるファイルリスト１０４３の一例である。１列目にユーザ名７００１が示されており、２列目に当該ユーザのクリアランス７００３が示されている。
【００３８】
図８は、上述の強制アクセス制御の考え方に基づき、本実施例におけるユーザ”researcher”がアクセスすることが許されるファイルのセキュリティレベルを示したものである。２列目から５列目までが、区画（人事部門８００１、８０２１、営業部門８００３、８０２３、企画部門８００５、８０２５、研究部門８００７、８０２７）を、２行目から５行目目がセキュリティレベル（機密８００９、８０２９、極秘８０１１、８０３１、秘密８０１３、８０３３、一般８０１５、８０３５）を示している。
【００３９】
図７に示すように”researcher”に与えられたクリアランスは、「研究部門・極秘」および「企画部門・秘密」であるので、上述の強制アクセス制御の考え方に基づくと、読み取りについては、「研究部門・極秘、秘密、一般」「企画部門・秘密、一般」のファイルにアクセスできる。また、書き込み、または、作成については、「研究部門・機密、極秘」「企画部門・機密、極秘、秘密」のファイルにアクセスできる。したがって、たとえば、ファイル”C:\home\user2\research_report.doc”のセキュリティレベルは、「研究部門・極秘」であるので、読み書き可能であるが、ファイル” C:\home\user1\secret.txt” のセキュリティレベルは、「営業部門・極秘、企画部門・極秘」であるので、書き込みのみ可能である。
【００４０】
アクセス制御プログラム１０３５は、図8に示す内容をルール化、あるいは、テーブル化したものをあらかじめ備え、その内容を参照しつつ、アクセス制御を行う。
図8の表では、特定のユーザがアクセス可能なファイルのセキュリティレベルを示しているが、特定のファイルへのアクセス可能なユーザを示すように作成してもよい。
【００４１】
以上に示したとおり、本実施例は、ホストOS１０１７に、アプリケーションプログラムに優先して働く強制アクセス制御機能を付加するものである。したがって、本実施例によって、ホストOS１０１７上で動作するアプリケーションプログラムにもともと許されていたファイルアクセスが禁止される可能性があるが、当該アプリケーションプログラムを変更する必要はなく、そのまま使用できる。
【００４２】
一例として、ホストOS１０１７管理下で、テキストエディタプログラムを実行させた場合の動作を述べると次のようになる。ここでは、ユーザUのクリアランスが、「研究部門」の「極秘」であるとし、ファイルF1のセキュリティレベルが「研究部門」の「機密」、ファイルF2のセキュリティレベルが「研究部門」の「秘密」であるとする。ユーザUは、テキストエディタプログラムを実行し、当該テキストエディタプログラムの「ファイルを開く」という機能を用い、ファイル名「F1」を指定し、ファイルの内容を読み込もうとした場合、これは、強制アクセス制御によれば許されないアクセスであるので、本実施例に示した機能によりこのアクセスは禁じられ、ユーザには、ファイルを開けない旨、伝えられる(表示される)。
【００４３】
このユーザへの表示は、たとえば、ホストOS１０１７自体が備える機能を利用して行えばよい。すなわち、本実施例によるアクセス制御とは別に、ホストOS１０１７自体が備えるファイルアクセス制御機能において、「読み込み禁止」となっているファイルを読み出そうとしたときの表示を利用すればよい。
同様に、「ファイルを開く」機能によってファイル名「F2」を指定し、ファイルの内容を読み込もうとした場合には、許されるアクセスであるので、ファイルの内容がテキストエディタプログラムに読み込まれる(ユーザから見ると通常のOS上での動作と同じに見える)。
さらにこのファイルを編集したのち、やはりテキストエディタに備えられた「上書き保存」機能を利用して、ファイル名「F2」として上書きしようとすると、これは許されないアクセスであるので、このアクセスは禁じられ、ユーザにはファイルが保存できない旨、伝えられる(表示される)。読み込みの場合と同様に、このユーザへの表示は、たとえば、ホストOS１０１７自体が備える機能を利用して行えばよい。
【００４４】
本実施例を「追記」のみを許すように設定し、このテキストエディタプログラムが、ファイルを開くことなく追記する、ことに対応しているときには、ユーザUはファイルF1に追記可能である。しかし、一旦ファイルの内容を読み込んでからでないと、編集(この場合は追記)できないテキストエディタプログラムの場合には、ファイルを読み込む(開く)ことが許可されないため、結果的に追記できない。
【００４５】
同一ハードディスク内でのファイル移動のように、ハードディスクＡ１０１３内のデータをメモリA１００５内に読み込むことなく、(パス情報を含むファイル名の書き換えを行うだけ、すなわち、ファイルそのものを移動せず、ファイル名とそのファイルがハードディスク上のどこにかかれているか、を示す対応表の部分だけを書き換えることで実現できる場合がある。このようなファイルアクセスについては、任意のユーザが行えるようにしてもよい。ただし、このとき、ファイルリスト１０４３の整合性を保つために、ファイルリスト１０４３内のファイル名６００１の部分を、当該ファイル移動に合わせて書き換えるようにする。
【００４６】
また、ファイルのコピーについても、コピーの途中で当該ファイルのデータを不正に読み取られる危険性がない場合、たとえば、ハードディスク自体がファイルコピーの機能を持っているような場合には、任意のユーザが行えるようにしてもよい。ただし、このときファイルのセキュリティレベルも同時にコピーする。すなわち、ファイルリスト１０４３内に、当該ファイルに関するエントリを追加して、コピー元と同じセキュリティレベルを設定する必要がある。
また、フロッピーディスクなどの取り外し可能な可搬型記憶媒体に移動またはコピーする場合には、ファイル移動（またはコピー）時に、当該ファイルのセキュリティレベルに合わせて暗号化するようにすればよい。さらに、ファイルリスト１０４３内の当該ファイルに関する情報も、可搬型記憶媒体に書き込むようにしてもよい。
これらの処理は、たとえば、アクセス制御プログラム１０３５に機能を追加することによって、実現可能である。
【００４７】
図４を用いて、本実施例におけるユーザラベル設定時における処理フローを説明する。
(ユーザラベル設定プログラム１０２３(ホストOS１０１７上)の動作)
ステップ４００１：はじめ
(ユーザリスト管理プログラム１０３７(ゲストOS１０１９上)の処理)
ステップ４００２：ホストOS１０１７上の起動中のプロセスチェックを行う。信頼できないプロセスが起動している場合は、ステップ４００３へ。そうでなければステップ４００４へ
ステップ４００３：おわり(設定失敗)
ステップ４００４：乱数Rを生成し、ホスト側へ送信する
(ユーザラベル設定プログラム１０２３(ホストOS１０１７上)の動作)
ステップ４００５：設定情報Cu（ユーザ名、当該ユーザのクリアランスレベルなど）の入力を求める
ステップ４００６：セキュリティ管理者のパスワードPの入力を求める
ステップ４００７：乱数Rと設定情報Cuを結合(concatinate)したものを、入力されたパスワードを鍵として暗号化し、ゲスト側へ送信する
(ユーザリスト管理プログラム１０３７(ゲストOS１０１９上)の処理)
ステップ４００８：あらかじめゲストOS１０１９側で管理・保持されていたセキュリティ管理者のパスワードを用い、ゲスト側から送られてきた暗号文を復号する。復号した情報に含まれている乱数が、ステップ４００４で生成した乱数Rと等しくなければ、ステップ４００９へ。等しければ、ステップ４０１０へ
ステップ４００９：おわり(設定失敗)
ステップ４０１０：ユーザリスト１０４１にステップ４００８で復号された設定情報を反映させる
ステップ４０１１：おわり(設定成功)。
【００４８】
図５を用いて、本実施例におけるファイルラベル設定時における処理フローを説明する。
(ファイルラベル設定プログラム１０２５(ホストOS１０１７上)の動作)
ステップ５００１：はじめ
(ファイルリスト管理プログラム１０３９(ゲストOS１０１９上)の処理)
ステップ５００２：ホストOS１０１７上の起動中のプロセスチェックを行う。信頼できないプロセスが起動している場合は、ステップ５００３へ。そうでなければステップ５００４へ
ステップ５００３：おわり(設定失敗)
ステップ５００４：乱数Rを生成し、ホスト側へ送信する
(ファイルラベル設定プログラム１０２５(ホストOS１０１７上)の動作)
ステップ５００５：設定情報Cf（ファイル名、当該ファイルのセキュリティレベルなど）の入力を求める
ステップ５００６：セキュリティ管理者のパスワードPの入力を求める
ステップ５００７：乱数Rと設定情報Cfを結合(concatinate)したものを、入力されたパスワードを鍵として暗号化し、ゲスト側へ送信する
(ファイルリスト管理プログラム１０３９(ゲストOS１０１９上)の処理)
ステップ５００８：あらかじめゲストOS１０１９側で管理・保持されていたセキュリティ管理者のパスワードを用い、ゲスト側から送られてきた暗号文を復号する。復号した情報に含まれている乱数が、ステップ５００４で生成した乱数Rと等しくなければ、ステップ５００９へ。等しければ、ステップ５０１０へ
ステップ５００９：おわり(設定失敗)
ステップ５０１０：ファイルリスト１０４３にステップ５００８で復号された設定情報を反映させる
ステップ５０１１：おわり(設定成功)。
【００４９】
本実施例においては、ユーザラベルまたはファイルのセキュリティレベルの設定を行うときに、ゲストOS１０１９側のユーザリスト管理プログラム１０３７またはファイルリスト管理プログラム１０３９とセキュリティ管理者との間の認証を、チャレンジレスポンス認証(challenge-response identification)と呼ばれる方法を用いておこなっている。さらに、認証と設定情報の受け渡しを同時に行うことにより、認証処理をバイパスする等の不正を防ぎ、かつ、メッセージのやりとりの回数を減らすことができる。
【００５０】
チャレンジレスポンス認証については、
文献[HAC]：Alfred J.Menezes, Paul C. van Oorschot, Scott A. Vanstone, “Handbook of Applied Cryptography”, CRC Press
に詳しい。なお、チャレンジレスポンス認証で利用する、暗号化処理は、たとえばDES(The Data Encryption Standard)
をCBCモード(Cipher-block chaining mode)で利用することによって行えばよい(文献[HAC]参照)。DES以外の共通鍵暗号を用いてもよい。本実施例では、上記文献[HAC]に開示されたチャレンジレスポンス認証以外の認証方法(たとえば公開鍵暗号に基づく方法)を利用することも可能である。
【００５１】
以上のように、本実施例は、ユーザが直接利用する一般的なOSであるホストOS１０１７とは異なるゲストOS１０１９上に、強制アクセス制御機能を設けることにより、ホストOS１０１７上のアプリケーションプログラム１０２１に改変を加えることなく強制アクセス制御機能を実現可能にしつつ、さらに強制アクセス制御機能に対する不正を防止する。
また、ホストOS１０１７の多機能化・高機能化等の改良が行われた際にも、構成を変えることなく強制アクセス制御を可能とする。
さらに、ユーザのクリアランスやファイルのセキュリティレベルの設定にあたっては、(一般にはホストOS１０１７側の管理者とは異なる)セキュリティ管理者の認証を行うことにより、ホストOS１０１７側の管理者による不正の脅威を減らすことができるようになる。
【００５２】
（第２の実施例）
本発明の他の実施の形態を、以下、図を用いて説明する。
【００５３】
前述したように、第１の実施例に開示したシステムが正常に起動した場合、ファイルへの不正アクセスは非常に困難になり、システムを安全に運用することが可能となる。このシステムに対して考えられる更なる脅威として、たとえば、システム起動以前にホストOSのプログラムが記述されたファイルを改竄し、第１の実施例に示したゲストOS側のアクセス制御機能を回避するという不正行為が考えられる。本実施例はこの不正行為を防止する方法を提供する。
【００５４】
図９は、本実施例におけるコンピュータシステムの構成例である。図１と同じであるが、ホストOS１０１７管理下のハードディスクA１０１３内のファイルが暗号化されている点（暗号化されたファイル９００１）、および、ゲストOS１０１９管理下に、暗号プログラム９００３、復号プログラム９００５、および、暗復号化鍵(対称鍵(symmetric key)ともいう)９００７が追加されている点が異なる。
【００５５】
本実施例においては、ファイル書き込み時には、まず、第１の実施例と同様にしてアクセス制御を行い、さらに、正当なアクセスであった場合には、ゲストOS側の暗号プログラム９００３によって暗号化されてから、ホストOS１０１７側のハードディスクＡ１０１３内に保存される。
ファイル読み込み時には、まず、第１の実施例と同様にしてアクセス制御を行い、さらに、正当なアクセスであった場合には、ホストOS１０１７側のハードディスクＡ１０１３に保存された当該ファイル(暗号化されたファイル)はゲストOS側の復号プログラム９００５によって復号されたのち、ホストOS１０１７側のアプリケーションプログラム１０２１に渡される。
【００５６】
この結果、ホストOS側のファイルアクセスが、ゲストOS側のアクセス制御プログラムを利用するようになっている場合には(すなわち、ホストOS側のアクセス制御プログラムをバイパスしていないときには)、ハードディスクA１０１３内のファイルは、常に暗号化された状態でありながら、アプリケーションプログラム１０２１は、正当なアクセスである限り、暗号化されていることを意識することなく、透過的に利用可能となる。
【００５７】
一方、たとえば、ホストOSがメモリにロードされるより前に、ホストOSのプログラムが記述されたファイルを改竄することにより、不正なホストOSを起動し、ゲストOS側のアクセス制御機能を回避するという不正行為を行った場合には、読み出されたファイルは暗号化されているため、実際上意味をなさない(情報の流出はおこらない)。したがって、結果的には、ゲストOS、および、当該OS上のアクセス制御機能の起動が保証される。さらには、これにより、たとえハードディスク装置ごと取り外し、別のコンピュータに接続してファイルを解析しようとしても、ファイルが暗号化されているため解析できないという効果もある。
【００５８】
なお、さらにホストOSの不正がないことを、より確実に確認するために、ゲストOS上に、ホストOSの検証機能を設けてもよい。これは、たとえば、ゲストOSの管理下に、あらかじめ、改竄されていないホストOSプログラムのディジタル署名を保持しておき、ホストOSの起動時に、ゲストOS側において、実際に起動されるホストOSプログラムが改竄されていないことを、当該ディジタル署名の検証手続きによって確認する入出力処理監査処理部をゲストOS側に設ければよい。また、入出力処理監査処理部が、ホストOS側のプロセス管理機能を利用し、ホストOS管理で不正なプロセスが実行されていないことを監査してもよい。
【００５９】
もしホストOSプログラムが改竄されている場合には、ゲストOSに指示して、あらゆるファイルアクセスを禁止する、あるいは、ホストOSの実行を止める、などにより、ホストOSの機能を無効化すればよい。このとき、さらにコンピュータに接続されたディスプレイ上への表示、あるいは、コンピュータに接続されたスピーカーを利用した警告音、あるいは、その他の外部装置を利用したメッセージ等により、ホストOSが改竄されているために起動できない旨、ユーザに伝えるようにしてもよい。
【００６０】
図１０を用いて、本実施例におけるファイルアクセス制御フロー（読み出し）を説明する。
ステップ１０００１：はじめ
ステップ１０００２：ステップ２００２〜２００４と同様
ステップ１０００３：アクセス制御プログラムは、正当なアクセスか否かを判定する（ステップ２００５と同様）。正当であればステップ１０００６へ。そうでなければステップ１０００４へ
ステップ１０００４：ステップ２００６と同様
ステップ１０００５：おわり（アクセス不可）
ステップ１０００６：ステップ２００８〜２００９と同様
ステップ１０００７：デバイスドライバは、ハードディスクから
暗号化されたファイルの読み出しを行いファイルフックプログラムに送る
ステップ１０００８：ファイルアクセスフックプログラムは、OS間通信プログラムを利用し、復号プログラムに、暗号化されたファイルを送る
ステップ１０００９：復号プログラムは、ゲストOS側で管理された暗復号化鍵を用いて、暗号化されたファイルを復号し、OS間通信プログラム、ファイルアクセスフックプログラムを通じて、アプリケーションプログラムに送る
ステップ１００１０：おわり（アクセス成功）。
【００６１】
図１１を用いて、本実施例における、ファイルアクセス制御フロー（書き込み）を説明する。
ステップ１１００１：はじめ
ステップ１１００２：ステップ２００２〜２００４と同様
ステップ１１００３：アクセス制御プログラムは、正当なアクセスか否かを判定する（ステップ２００５と同様）。正当であればステップ１１００６へ。そうでなければステップ１１００４へ
ステップ１１００４：ステップ２００６と同様
ステップ１１００５：おわり（アクセス不可）
ステップ１１００６：ゲストOS上の暗号プログラムは、ゲストOS側で管理された暗復号化鍵を用いて、アプリケーションプログラム１０２１が書き込もうとしている情報を暗号化する
ステップ１１００７：ステップ２００８〜２０１０と同様
ステップ１１００８：おわり（アクセス成功）
ファイル生成時におけるファイルアクセス制御の処理フローは、図１１に示したファイルアクセス制御フロー（書き込み）と基本的に同様であるが、ステップ１１００２が、
ステップ１１００２‘：ステップ３００２〜３００５と同様
となる点が異なる。
【００６２】
ステップ１０００９の復号化処理、および、ステップ１１００６の暗号化処理では、たとえばDES(The Data Encryption Standard)をCBCモード(Cipher-block chaining mode)で利用すればよい(文献[HAC]参照)。ただし、CBCモードを利用する場合であっても、最初のブロック長(DESの場合であれば64-bit)分については、同じ平文を同じ鍵で暗号化すると、同じ暗号文となってしまう。これを避けるためには、CBCモードで利用される初期値IVをファイルごとに異なるようにすればよい。たとえば、ステップ１１００６で暗号化をする際に64-bitの乱数を生成し、それをIVとして暗号化時に利用するとともに、このIVをファイルリストに項目を追加して保存する。ステップ１０００９中の復号化処理では、ファイルリストから復号対象ファイルに対応するIVを読み出し復号時に利用すればよい。
【００６３】
本実施例では、ひとつの暗復号化鍵を用いて、暗復号化を行っていたが、複数の暗復号化鍵を用いてもよい。たとえば、ファイルのセキュリティレベル・区画ごとに異なる鍵、あるいは、異なる暗号方法を用いてもよい。本実施例を、このように変更した場合、セキュリティレベルが４段階あり、区画が４区画あるので、全部で１６個の異なる暗復号化鍵を用いることになる。これらの鍵はゲストOS側で管理すればよい。さらには、ファイルのセキュリティレベルに応じて、暗号方法、あるいは、鍵として、安全性が異なるものを用いてもよい。(たとえば、セキュリティレベルが高いファイルに対しては、長い鍵長の暗号化鍵を用いてもよい)。
【００６４】
また、本実施例で用いる暗復号化鍵は、ハードディスクB１０１５とは異なるハードウェアモジュール（例：ICカードなど）に格納しておくようにしてもよい。この場合、さらに当該ハードウェアモジュール内に、ゲストOS１０１９およびその上で動作する各種プログラム（アクセス制御プログラム１０３５など）が改変されていないことを検証する機能を持たせておき、正当であると確認されたときに限り、暗復号化鍵が利用可能になるように（たとえば、メモリB１００７内にロードされるように）しておくと、ゲストOS側の改ざんという脅威にも対抗できるため、より効果的である。
【００６５】
また、本実施例では、ファイルの内容自体を暗号化していたが、そうではなく、ファイルの管理テーブル部を暗号化するようにしてもよい。ファイルの管理テーブルは、通常ハードディスク内の、ファイルとは別領域に記憶されており、ファイル名と、ハードディスク内のどの部分に当該ファイルが保存されているかを示すアドレス情報との対応が、記述されている。したがって、このアドレス情報部分を暗号化することにより、ディスク内のどこにファイル情報が保存されているか調べることが困難になるため、ファイル情報漏洩の防止に効果がある。また、暗号化する対象となるデータサイズが小さいため、暗復号化にかかる処理量が少なくてすむ、という利点がある。
【００６６】
なお、本実施例でも、第１の実施例と同様、ファイルアクセスフックプログラム１０２９が、I/Oマネージャ１０２７のファイルシステムドライバ１０３１に対するファイルアクセス命令を検知し、そのファイルアクセス命令をファイルシステムドライバ１０３１に渡す前に、ゲストOS１０１９上のアクセス制御プログラム１０３５に渡す例を示した。しかし、これとは異なっていてもよい。たとえば、ファイルアクセスフックプログラム１０２９は、ファイルアクセス（例えば、読み出し）命令を、ファイルシステムドライバ１０３１に渡すのと同時、あるいは後に、アクセス制御プログラム１０３５に渡すようにし、当該ファイルアクセスが正当なものでなかったときは、ステップ１０００９の復号化処理を行わないようにしてもよい。このようにしても、不当な読み出し処理をしようとすると、アプリケーションプログラムにとっては、暗号化されたままのファイルが読み込まれることになるため、情報の漏洩はおこらない。
【００６７】
ゲストＯＳに対しては、上記第１、２の実施例による強制アクセス制御機能だけでなく、さらに別の機能を追加してもよい。
たとえば、ホストOS側でどのようなファイルアクセスがあったか（アクセス時刻、アクセスしようとしたユーザ名・プログラム名、アクセス対象ファイル名、アクセスの種類、ファイルになされた変更内容など）を記録し、保持する機能（ファイルアクセスログ管理機能）をゲストOS側が備えてもよい。
ゲストOS側で実現することにより、ホストOS、および、ホストOS上で動作するアプリケーションプログラムを改変することなく、ファイルアクセスを記録することができるようになり、さらに、記録されたファイルアクセスログが、ホストOS側から改竄、または、消去される危険性がなくなる。
【００６８】
また、ホストOS上のコンピュータウィルスを検知、あるいは、駆除するコンピュータウィルス対策プログラムをゲストOS側に設けてもよい。さらには、検知したウィルスに関する情報をネットワークを通じて、他のコンピュータとの間で送受信する機能をゲストOSに設けてもよい。
【００６９】
あるいはまた、ホストOS側のアプリケーションプログラムから明示的に実行が要求される機能を実現してもよい。たとえば、ディジタル署名生成機能または公開鍵暗号の復号機能などの暗号機能、および、これらの機能において利用される秘密鍵情報の管理などが挙げられる。さらには、発明者等が特願2000-313123号に開示した、ディジタル署名生成時に、その時点での署名履歴を利用する署名方法、および、署名履歴管理方法を実現してもよい。
この場合は、上述のファイルアクセス制御機能や、ファイルアクセスログ管理機能などとは異なり、ホストOS側アプリケーションプログラムが、あらかじめ、このゲストOS側で実現された機能に対応している必要がある。ただし、実行にあたっては、上記のユーザラベル設定フローやファイルラベル設定フローと同様の方法によって、固有のユーザ認証を行うことにより、ホストOS側のシステム管理者による不正利用を防ぐことができる。したがって、前述のディジタル署名生成機能や、公開鍵暗号の復号機能のような、各ユーザの秘密鍵情報を利用する機能を実現するためには、特に適している。あるいは、上記のコンピュータウィルス対策プログラムをホストOS側のアプリケーションプログラムから明示的に実行が要求される機能として実現してもよい。
【００７０】
上記各実施例においては、複数OS制御技術を利用し、ユーザが直接利用するホストOS上のファイルアクセス制御を、ホストOSとは異なるゲストOS管理下のソフトウェアが実現していた。しかし、本発明はこれに限定されない。たとえば、ゲストOSとゲストOS上に設けられた機能（処理部）のいずれか一つ以上を、ハードウェアとして実現してもよい。この場合、さらに、このハードウェア内に、ユーザリスト、ファイルリスト、セキュリティ管理者のパスワード、ファイル暗号用の暗号化鍵等を記憶するようにしてもよい。
【００７１】
【発明の効果】
本発明によれば、情報処理システムの情報セキュリティに関する安全性を、利用者の利便性を損なうことなく、向上させることが可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施例を実現する計算機の概略構成図である。
【図２】第１の実施例におけるファイルアクセス(読み出し、書き込み)制御の処理フロー図である。
【図３】第１の実施例におけるファイルアクセス(ファイル作成)制御の処理フロー図である。
【図４】第１の実施例におけるファイルアクセス(読み出し、書き込み)制御の処理フロー図である。
【図５】第１の実施例におけるファイルラベル設定時における処理フロー図である。
【図６】第１の実施例におけるユーザリストユーザリストの一例である。
【図７】第１の実施例におけるファイルリストファイルリストの一例である。
【図８】第１の実施例におけるユーザ”researcher”がアクセスすることが許されるファイルのセキュリティレベルを示したものである。
【図９】第２の実施例を実現する計算機の概略構成図である。
【図１０】第２の実施例におけるファイルアクセス(読み出し)制御の処理フロー図である。
【図１１】第２の実施例におけるファイルアクセス(書き込み)制御の処理フロー図である。
【符号の説明】
１００１：コンピュータ
１００３：CPU
１００５：メモリA
１００７：メモリB
１００９：ディスプレイ
１０１１：キーボード
１０１３：ハードディスクA
１０１５：ハードディスクB
１０１７：ホストOS
１０１９：ゲストOS
１０２１：アプリケーションプログラム
１０２３：ユーザラベル設定プログラム
１０２５：ファイルラベル設定プログラム
１０２７：I/Oマネージャ
１０２９：ファイルアクセスフックプログラム
１０３１：ファイルシステムドライバ
１０３３：デバイスドライバ
１０３５：アクセス制御プログラム
１０３７：ユーザリスト管理プログラム
１０３９：ファイルリスト管理プログラム
１０４１：ユーザリスト
１０４３：ファイルリスト
１０４５：ファイル
１０４７：セキュリティ管理者のパスワード
１０４９：複数OS制御プログラム
１０５１：OS間通信プログラム
９００１：暗号化されたファイル
９００３：暗号プログラム
９００５：復号プログラム
９００７：暗号化鍵
【発明の属する技術分野】
本発明は情報処理システムに保管されているファイルへの不正アクセスを防止し、高い安全性を確保するための技術に関する。
【０００２】
【従来の技術】
計算機を用いた情報処理システムにおいては、多くのアプリケーションプログラムを実行させるための基本的な仕組みを提供するOS (Oprerating System)を用いてハードウェア資源の有効活用を図るのが一般的である。
【０００３】
さらに、当該情報処理システムでのファイルの保護は、主として、上記OSが備える一機能であるファイルアクセス制御機能を用いて実現している。
現在、広範に利用されているOSでは、ファイルアクセス制御を、任意アクセス制御(Discretionary Access Control、DACとも記す)に基づいて行うことが多い。これは、ファイルの所有者(一般には、ファイルの作成者と一致する)であるユーザが、当該ファイルに対して、アクセスできるユーザ、および、アクセスの種類（読み取りのみ、読み取りと変更など）を任意に設定し、それに基づいてアクセス制御を行うものである。
また、通常このようなOSでは、システム管理者と呼ばれる特殊な権限をもつユーザは、当該情報処理システム内のすべての設定を変更することが可能である。
【０００４】
一方、高いセキュリティが要求される場面での利用を想定して作られた専用OSの中には、より厳格なアクセス制御方法である、強制アクセス制御(必須アクセス制御とも言う)(Mandatory Access Control、MACとも記す)に基づくファイルアクセス制御機能を備えたものがある。たとえば、セキュアシステムの評価基準のひとつである米国のTCSEC(Trusted ComputerSystem Evaluation Criteria)に定められたクラスのうち、クラスB1以上に認定されるためには、強制アクセス制御機能を備えなければならない。
TCSECおよび強制アクセス制御については、
文献[TCSEC]：「Department of Defense Trusted Computer System Evaluation Criteria」アメリカ国防総省標準（DOD 5200.28-STD）
に詳しい。
【０００５】
強制アクセス制御を備えた情報処理システムにおいては、すべてのファイルには、セキュリティレベル(例えば、高い方から「機密 (top secret)」「極秘 (secret)」「秘密 (confidential)」「一般 (unclassified)」など)が設定され、また、すべてのユーザに対し、信頼度、すなわち、アクセスできるファイルのセキュリティレベルを示す許可レベル(クリアランス(clearance)という。例えば、高い方から「機密」「極秘」「秘密」「一般」など))が設定される。システムは、これらの情報に基づいて強制的にアクセス制御を行う。
【０００６】
上記のような専用OSでは、システム管理者とは異なる、セキュリティ管理者とよばれるユーザによって、ファイルのセキュリティレベルや他のユーザのクリアランスなど、セキュリティに関わる機能が管理されていることが多い。これにより、ファイル作成者だけでなくシステム管理者であっても当該情報処理システムのセキュリティを下げることができないようになり、より安全なシステムの運用が可能となる。
【０００７】
【発明が解決しようとする課題】
ファイルへの不正アクセスを防ぐ仕組みを任意アクセス制御に基づくアクセス制御機能を備えたOSに依存している情報処理システムでは、各ファイルの所有者であるユーザが、当該ファイルのアクセス可能な範囲を設定できてしまうため、ユーザの故意、または、不注意により、重要な情報が漏洩してしまう恐れがある。
【０００８】
一方、強制アクセス制御機能を備えたOSを利用した情報処理システムでは、当該OSが一般的ではないため、ユーザが利用するアプリケーションプログラムを独自に開発する必要があり、コストがかさむ上、ユーザの利便性が失われる。
上記背景の元、コストがかからず、安全性を高められる技術が求められている。
【０００９】
【課題を解決するための手段】
本発明は、情報処理システムの情報セキュリティに関する安全性を、利用者の利便性を損なうことなく、向上させる技術を提供する。
本発明は、また、情報処理システム内にシステム管理者とは異なる、資格を持つユーザだけが利用できる機能・領域を設けるための方法、および、装置を提供する。
本発明は、また、上記技術を適用した情報処理システムに対する、起動時における不正を防止するための方法、および、装置を提供する。
【００１０】
より具体的には、既存のアプリケーションプログラムを利用可能な状態を保ちつつ、情報処理システムに強制アクセス制御機能を付加する技術と、その技術を適用した情報処理システムを提供する。
また、強制アクセス制御機能をもたないOSの管理の元で既存のアプリケーションプログラムが動作する情報処理システムに、強制アクセス制御機能を付加する技術と、その技術を適用した情報処理システムを提供する。
【００１１】
本発明の一態様によれば、ユーザが直接利用する、アプリケーションプログラムを動作させるためのOS(ホストOSという)と、セキュリティ強化のためのOS(ゲストOSという)の２つのOSを、複数OS制御技術を利用することにより動作させる。複数OS制御技術は、たとえば、特開平11-149385号公報に開示されている。
本発明に従えば、上記専用OSを用いることなく、ホストOS上で動作するファイル作成者だけでなく、システム管理者であっても、セキュリティレベルを変えることが非常に困難になる。
【００１２】
より具体的には、アクセス監視処理プログラムはホストOS管理下で行われるファイルアクセスを監視し、ゲストOS上のファイルアクセス制御プログラムは、アクセス監視処理プログラムが検知したファイルアクセスの正当性を、ファイルのセキュリティレベルと、ユーザのクリアランスに従って判断し、不正アクセスを許さない。
また、ホストOSの各種設定を行うシステム管理者とは、別に、セキュリティ管理者を設け、システム管理者であっても、セキュリティレベルを変更できないようにする。システム全体のセキュリティポリシーとして、システム管理者が、セキュリティ管理者の権限を有することが許される場合には、これら２つの管理者を同一人が兼任してもよい。
【００１３】
本発明の他の一態様によれば、ゲストOS上に、アクセス制御機能を設けることにより、アクセス制御機能に対する不正操作を防止する。
また、本発明の他の一態様によれば、ホストOS側の多機能化・高機能化等の改良が行われても、強制アクセス制御が可能な環境を維持することを可能とする。さらに、ユーザのクリアランスやファイルのセキュリティレベルの設定にあたっては、セキュリティ管理者の認証を行うことにより、ホストOS側の管理者による不正の脅威を減らすことができるようになる。
【００１４】
なお、本発明におけるOSとは、ユーザーまたはプログラムからの要求に応じて記憶媒体中のデータ、ファイルへのアクセスを実行する機能と、アクセス要求元のユーザーやプログラムを識別する機能と、排他制御機能により占有する記憶部を有するプログラムモジュールを意味しており、
（１）ファイルアクセスを管理しており、検知が可能である。
（２）アクセス要求元のユーザーを識別できる。
（３）アクセス要求元のアプリケーションプログラムを識別できる。
といった特徴を持つ。したがって、上記特徴を持つものであれば、本発明のOSに含めることが可能である。
【００１５】
【発明の実施の形態】
図１は、本実施例による情報処理システムの構成例である。コンピュータ１００１内には、コンピュータ内の各OSや各プログラム（処理部とも言う）を実行するCPU１００３、ホストOS１０１７が管理するメモリA１００５、および、ゲストOS１０１９が管理するメモリB１００７があり、さらに、キーボード１０１１、マウスなどの入力装置、ディスプレイ１００９などの出力装置、ホストOS１０１７の管理下にあるハードディスクA１０１３、ゲストOS１０１９の管理下にあるハードディスクB１０１５などの記憶装置がつながっている。なお、記憶装置は、ハードディスクの他、フラッシュメモリや、EEPROMなど書き換え可能な不揮発性メモリであってもよい。さらには、ハードウェア的な耐タンパ性を持っているほうが望ましい。
【００１６】
メモリA１００５内には、ホストOS１０１７と、さらにホストOS１０１７管理下で動作する一般のアプリケーションプログラム１０２１の他、本実施例では、ユーザのクリアランスを定義するラベル付けを行うユーザラベル設定プログラム１０２３、各ファイルのセキュリティレベルを定義するラベル付けを行うファイルラベル設定プログラム１０２５が、ハードディスクＡ１０１３からロードされる。また、ホストOS１０１７内には、ファイル管理を行う部分として、I/Oマネージャ１０２７、ファイルシステムドライバ１０３１、デバイスドライバ１０３３がある他、本実施例では、さらに、アプリケーションからハードディスクA１０１３内のファイル１０４５へのアクセスをフックする、ファイルアクセスフックプログラム１０２９が設けられる。
【００１７】
ファイルへのアクセスをフックするとは、ハードディスクA１０１３等の記憶媒体内のファイルへのアクセスが発生しようとしていることを、何らかの方法によって検知することである。
ファイルアクセスのフックは、たとえば、あらかじめOSによって用意されたインターフェイス、たとえばファイルシステムドライバ１０３１やデバイスドライバ１０３３などの各種ドライバ用に用意されたインターフェイスを利用することが可能である。
すなわち、本実施例のように、I/Oマネージャ１０２７と、ファイルシステムドライバ１０３１との間に、I/Oマネージャ１０２７からは、ファイルシステムドライバ１０３１に対して命令するように見え、また逆に、ファイルシステムドライバ１０３１からは、I/Oマネージャ１０２７から命令されたかのように見える、ファイルアクセスフックプログラム１０２９を設ければ、ファイルアクセスが発生していることを、I/Oマネージャ１０２７による命令によって認識することができる。一般的に、OSには、各種デバイスを統一的に管理し、また、様々な機能拡張に対応することができるように、このようなインターフェイスが用意されているし、さらに、ファイルアクセスフックのための専用のインターフェイスが用意されていることもある。
この他、図示されていないが、ホストOS１０１７は、一般にOSが備える機能を実現する部分、すなわち、プロセス管理、メモリ管理などを担う部分を備える。
【００１８】
メモリB１００７内には、ゲストOS１０１９と、さらにゲストOS１０１９管理下で動作する、アクセス制御プログラム１０３５、ユーザリスト管理プログラム１０３７、ファイルリスト管理プログラム１０３９が、ハードディスクＢ１０１５からロードされる。ゲストOS１０１９の管理下にあるハードディスクB１０１５には、ユーザリスト管理プログラム１０３７が利用するユーザリスト１０４１、ファイルリスト管理プログラム１０３９が利用するファイルリスト１０４３が含まれている。
【００１９】
本実施例においては、ホストOS１０１７上のアプリケーションプログラム１０２１によるファイルアクセスは、ファイルアクセスフックプログラム１０２９によりフックされる。
アプリケーションプログラム１０２１から発行されたファイルアクセスを受けたI/Oマネージャ１０２７は、ファイルシステムドライバ１０３１に対してファイルアクセス命令を発行する。ファイルアクセスフックプログラム１０２９は、ファイルシステムドライバ１０３１の代わりにこの命令を受け取り、そのファイルアクセス命令をファイルシステムドライバ１０３１に渡す前に、複数OS制御プログラム１０４９内のOS間通信プログラム１０５１を用いて、ゲストOS１０１９上のアクセス制御プログラム１０３５に渡す。
【００２０】
アクセス制御プログラム１０３５は、当該ファイルアクセスが正当なものか否かを、ユーザリスト１０４１、および、ファイルリスト１０４３を元に判定し判定結果を返す。ファイルアクセスフックプログラム１０２９は、ファイルアクセスが不当であれば、当該ファイルアクセスを失敗させ、正当であれば要求どおりのファイルアクセス命令をファイルシステムドライバ１０３１に渡す。
【００２１】
本実施例では、アクセス制御プログラム１０３５を、ユーザがログインするホストOS１０１７管理下でなく、ゲストOS１０１９管理下で実行することにより、
（１）アクセス制御プログラム１０３５が不正な改変にさらされる脅威が少ない
（２）アクセス制御に関するプログラムのバグ等によるセキュリティホールがあるかどうかをチェックすべき範囲を限定できるため、メンテナンスが容易になる
（３）OSの多機能化・高機能化などによりホストOS１０１７が改良された場合にも、基本的な枠組みを変えることなく、アクセス制御を行うことができるため、OSの開発コストの削減が可能
などの利点が得られる。
【００２２】
本実施例においては、ファイルのセキュリティレベルとして「一般」、「秘密」、「極秘」、「機密」の４段階あり、この順に機密度合いが高くなる。また、対応するユーザのクリアランスとして、同様に「一般」、「秘密」、「極秘」、「機密」の４段階あり、この順に信頼度が高くなる。ファイルアクセスが正当であるか否かは、ファイルのセキュリティレベルとユーザのクリアランスとに基づいて判断される。
【００２３】
セキュリティレベルを何段階設けるかは、システムごとに自由に設定できる。ただし、ファイルのセキュリティレベルとユーザのクリアランスとは1対1に対応するように設定する。
【００２４】
さらに、それぞれのファイルとユーザは「人事部門」、「営業部門」、「企画部門」、「研究部門」の４つの区画(compartment)に所属させることができる。なお、区画の数はシステムごとに自由に設定できる。特に区画が１つの場合は、区画を設けなくてもよい。
【００２５】
各ユーザは、与えられたクリアランスと区画が同じで、かつ、機密度合いが同じか低いセキュリティレベルのファイルは、読み出し可能であり、与えられたクリアランスと区画が同じで、かつ、機密度合いが同じか高いセキュリティレベルのファイルは、書き込み、または、作成可能である。
見方を変えると、各ファイルは、与えられたセキュリティレベルと機密度合いが同じか低いクリアランスのユーザによる書き込みまたは作成は可能であり、機密度合いが同じか高いクリアランスのユーザによる読み出しは可能である。
【００２６】
強制アクセス制御においては、「極秘」のクリアランスを持つユーザAは、「一般」または「秘密」または「極秘」のセキュリティレベルのファイルを読むことはできるが、「機密」のセキュリティレベルのファイルを読むことはできない。また、ユーザAは、「機密」または「極秘」のセキュリティレベルのファイルに書き込むはできるが、「一般」または「秘密」のファイルに書き込むことはできない。
【００２７】
このように、読み取りが許可されるファイルのセキュリティレベルと、書き込みが許可されるファイルのセキュリティレベルが異なるのは、情報(ファイル)に設定されたセキュリティレベルが下げられてしまうことを防ぐためである。仮に、ユーザAが「一般」のファイルに書き込むことができてしまうとすると、もともと「極秘」であったファイルを、「一般」のファイルとして保存することができてしまい、結果的に、本来「一般」のクリアランスしか持たないユーザに「極秘」の情報が漏洩してしまう。強制アクセス制御では、このような危険性を防止できる。
【００２８】
本実施例の強制アクセス制御におけるファイルアクセスの種類（アクセスタイプという）として、ファイルを開いて内容を読み出すこと、ファイルの情報を書き換えること、新たにファイルを作成すること、を定義する。
ファイルの情報の書き換えにおいて、ファイルを開くかどうかは問わない。すなわち、「書き換えること」ができても「読み出すこと」ができないことがあり得る。つまり、読み取りできない(内容のわからない)ファイルの内容を書き換えることができる権利をもつことがありえる。これによって、クリアランスの低いユーザが高いセキュリティレベルのファイルを書き換える際に、情報が漏れることを防ぐ。
【００２９】
さらに、書き換えについては、ファイルのセキュリティレベルを下げられないようにするという目的を達成するためであれば、元のファイル情報の書き換えを含む書き込みを許してもよいが、クリアランスの低いユーザによって、高いセキュリティレベルの情報を書き換えられることを避けるという観点からは、たとえば追記のみを許すようにしてもよい。
【００３０】
すなわち、ファイル内の情報を減らすようなファイルアクセスを「削除」と呼び、ファイル内の情報を増やすようなファイルアクセスを「追記」と呼ぶとすると、情報の不正な漏洩を防ぐという目的だけであれば、与えられたクリアランスと区画が同じで、かつ、機密度合いが同じか高いセキュリティレベルのファイルに対して、「削除」と「追記」の両方を許すようにしてもよいし、情報の改竄を防ぐという目的からは、「削除」は許さず「追記」を許すようにしてもよい(この場合、たとえば、機密度合いが同じ場合のみ「削除」を許すようにしてもよい)。
【００３１】
ユーザのクリアランスは、セキュリティ管理者がユーザラベル設定プログラム１０２３を利用することによって、たとえば、ホストOS１０１７上で最初にユーザ登録を行うときに設定する。あるいは、当該ユーザが最初に何らかのファイルアクセスを行おうとしたときに、当該ファイルアクセスをフックすることにより、ユーザラベル設定プログラム１０２３を自動的に起動するようにしてもよい。ユーザラベル設定プログラム１０２３の起動が設定されていない場合には、ユーザのクリアランスが設定されていない状態で(すなわち、ゲストOS１０１９側で管理されているユーザリスト１０４１に当該ユーザに関するクリアランスが登録されていない状態で)、ファイルアクセスが発生する可能性があるが、この場合には、システムのセキュリティポリシーにあわせて、たとえば、いかなるファイルアクセスも許さないようにしてもよいし、あるいは、最も低いクリアランス（本実施例の場合は「一般」）が与えられているものとみなしてもよい。
【００３２】
ファイルのセキュリティレベルは、ユーザが当該ファイルを作成したときに、たとえばユーザが明示的に設定する。設定可能なセキュリティレベルは、当該ユーザのクリアランスによって決まる。すなわち、当該ユーザのクリアランスと同じかそれより高いセキュリティレベルを設定可能である。また、一度設定されたセキュリティレベルは、一般には、後から下げることはできないようにしたほうがセキュリティの観点からは望ましい。但し、利便性向上等の目的で、特別の権限を持つユーザ、例えばセキュリティ管理者、がファイルラベル設定プログラム１０２５を利用することにより、セキュリティレベルを下げられるようにしてもよい。
【００３３】
ユーザのクリアランスを設定するセキュリティ管理者と、ファイルのセキュリティレベルを設定するセキュリティ管理者は同一でもよいし、異なっていてもよい。さらには、それぞれの管理者は信頼できる複数の人であってもよい。たとえば、各区画ごとにユーザのクリアランスおよびファイルのセキュリティレベルを設定するセキュリティ管理者を設けてもよい。
【００３４】
図２を用いて、本実施例におけるファイルアクセス制御の処理フロー(読み出し、書き込み)を詳細に説明する。
ステップ２００１：はじめ
ステップ２００２：アプリケーションプログラム１０２１は、I/Oマネージャ１０２７を通じ、ファイルアクセスフックプログラム１０２９に対し、ファイルアクセスを要求
ステップ２００３：ファイルアクセスフックプログラム１０２９は、OS間通信プログラム１０５１を利用し、アクセス制御プログラム１０３５に、ユーザ名、ファイル名、アクセスの種類を送る。ユーザ名は、たとえば、アプリケーションプログラム１０２１に関するプロセスとそのプロセスを実行したユーザ名との対応情報を参照することによって取得できる。この対応情報は、ホストOS自身の持つ機能のひとつであるプロセス管理機能を実現するために使われるもので、ホストOSが保持している。
ステップ２００４：アクセス制御プログラム１０３５は、ユーザリスト１０４１およびファイルリスト１０４３を参照し、当該ユーザのクリアランス、および、当該ファイルのセキュリティレベルを調べる
ステップ２００５：アクセス制御プログラム１０３５は、正当なアクセスか否かを判定する。正当なアクセスであれば、ステップ２００８へ。不当なアクセスであれば、ステップ２００６へ
ステップ２００６：アクセス制御プログラム１０３５は「アクセス不可」を出力する。この判定結果はファイルフックプログラム１０２９、I/Oマネージャ１０２７を通じて、アプリケーションプログラム１０２１に伝えられる
ステップ２００７：おわり（アクセス不可）
ステップ２００８：アクセス制御プログラム１０３５は、ファイルフックプログラム１０２９を通じて、ファイルシステムドライバ１０３１に、ファイル名、アクセスの種類(アクセスタイプ)を送る
ステップ２００９：ファイルシステムドライバ１０３１は、デバイスドライバ１０３３に、対象となるファイル名に応じたハードディスクＡ１０１３内のアドレス、および、アクセスの種類を送る
ステップ２０１０：デバイスドライバ１０３３は、ハードディスクＡ１０１３から読み込み対象となっているファイルを読み出してアプリケーションプログラム１０２１に送る（読み込み時）、あるいは、ハードディスクＡ１０１３にアプリケーションプログラム１０２１が書き込もうとしている情報を書き込む（書き込み時）ステップ２０１１：おわり（アクセス成功）。
【００３５】
図３を用いて、本実施例におけるファイルアクセス制御の処理フロー(ファイル作成)を詳細に説明する。
ステップ３００１：はじめ
ステップ３００２：アプリケーションプログラム１０２１は、I/Oマネージャ１０２７を通じ、ファイルアクセスフックプログラム１０２９に対し、ファイルアクセス(ファイル作成)を要求
ステップ３００３：ファイルアクセスフックプログラム１０２９は、アプリケーションプログラム１０２１のユーザに対し、作成するファイルに設定するセキュリティレベルの入力を、そのためのユーザインタフェースを用いて、求める
ステップ３００４：ファイルアクセスフックプログラム１０２９は、OS間通信プログラム１０５１を利用し、アクセス制御プログラム１０３５に、ユーザ名、ファイル名、アクセスの種類(ファイル作成)、設定セキュリティレベルを送る。ユーザ名は、ステップ２００３と同様に取得できる。
ステップ３００５：アクセス制御プログラム１０３５は、ユーザリスト１０４１を参照し、当該ユーザのクリアランスを調べる
ステップ３００６：アクセス制御プログラム１０３５は、設定しようとしているセキュリティレベルが正当か否かを判定する。正当であれば、ステップ３００９へ。不当なアクセスであれば、ステップ３００７へ
ステップ３００７：アクセス制御プログラム１０３５は「アクセス不可」を出力する。この判定結果はファイルフックプログラム１０２９、I/Oマネージャ１０２７を通じて、アプリケーションプログラム１０２１に伝えられる
ステップ３００８：おわり（アクセス不可）
ステップ３００９：アクセス制御プログラム１０３５は、ゲストOS１０１９管理下のファイルリスト１０４３を更新し、I/Oマネージャ１０２７を通じて、ファイルシステムドライバ１０３１に、ファイル名、アクセスの種類(ファイル作成)を送る
ステップ３０１０：ファイルシステムドライバ１０３１は、ファイル名に応じたハードディスクＡ１０１３内のアドレスを割り当て、デバイスドライバ１０３３に、当該アドレスとアクセスの種類を送る
ステップ３０１１：デバイスドライバ１０３３は、ハードディスクＡ１０１３にアプリケーションプログラム１０２１が保存しようとしている情報を書き込む
ステップ３０１２：おわり（アクセス成功）。
【００３６】
図６は、本実施例におけるユーザリスト１０４１の一例である。１列目にファイル名６００１が示されており、２列目に当該ファイルのセキュリティレベル６００３が示されている。
【００３７】
図７は、本実施例におけるファイルリスト１０４３の一例である。１列目にユーザ名７００１が示されており、２列目に当該ユーザのクリアランス７００３が示されている。
【００３８】
図８は、上述の強制アクセス制御の考え方に基づき、本実施例におけるユーザ”researcher”がアクセスすることが許されるファイルのセキュリティレベルを示したものである。２列目から５列目までが、区画（人事部門８００１、８０２１、営業部門８００３、８０２３、企画部門８００５、８０２５、研究部門８００７、８０２７）を、２行目から５行目目がセキュリティレベル（機密８００９、８０２９、極秘８０１１、８０３１、秘密８０１３、８０３３、一般８０１５、８０３５）を示している。
【００３９】
図７に示すように”researcher”に与えられたクリアランスは、「研究部門・極秘」および「企画部門・秘密」であるので、上述の強制アクセス制御の考え方に基づくと、読み取りについては、「研究部門・極秘、秘密、一般」「企画部門・秘密、一般」のファイルにアクセスできる。また、書き込み、または、作成については、「研究部門・機密、極秘」「企画部門・機密、極秘、秘密」のファイルにアクセスできる。したがって、たとえば、ファイル”C:\home\user2\research_report.doc”のセキュリティレベルは、「研究部門・極秘」であるので、読み書き可能であるが、ファイル” C:\home\user1\secret.txt” のセキュリティレベルは、「営業部門・極秘、企画部門・極秘」であるので、書き込みのみ可能である。
【００４０】
アクセス制御プログラム１０３５は、図8に示す内容をルール化、あるいは、テーブル化したものをあらかじめ備え、その内容を参照しつつ、アクセス制御を行う。
図8の表では、特定のユーザがアクセス可能なファイルのセキュリティレベルを示しているが、特定のファイルへのアクセス可能なユーザを示すように作成してもよい。
【００４１】
以上に示したとおり、本実施例は、ホストOS１０１７に、アプリケーションプログラムに優先して働く強制アクセス制御機能を付加するものである。したがって、本実施例によって、ホストOS１０１７上で動作するアプリケーションプログラムにもともと許されていたファイルアクセスが禁止される可能性があるが、当該アプリケーションプログラムを変更する必要はなく、そのまま使用できる。
【００４２】
一例として、ホストOS１０１７管理下で、テキストエディタプログラムを実行させた場合の動作を述べると次のようになる。ここでは、ユーザUのクリアランスが、「研究部門」の「極秘」であるとし、ファイルF1のセキュリティレベルが「研究部門」の「機密」、ファイルF2のセキュリティレベルが「研究部門」の「秘密」であるとする。ユーザUは、テキストエディタプログラムを実行し、当該テキストエディタプログラムの「ファイルを開く」という機能を用い、ファイル名「F1」を指定し、ファイルの内容を読み込もうとした場合、これは、強制アクセス制御によれば許されないアクセスであるので、本実施例に示した機能によりこのアクセスは禁じられ、ユーザには、ファイルを開けない旨、伝えられる(表示される)。
【００４３】
このユーザへの表示は、たとえば、ホストOS１０１７自体が備える機能を利用して行えばよい。すなわち、本実施例によるアクセス制御とは別に、ホストOS１０１７自体が備えるファイルアクセス制御機能において、「読み込み禁止」となっているファイルを読み出そうとしたときの表示を利用すればよい。
同様に、「ファイルを開く」機能によってファイル名「F2」を指定し、ファイルの内容を読み込もうとした場合には、許されるアクセスであるので、ファイルの内容がテキストエディタプログラムに読み込まれる(ユーザから見ると通常のOS上での動作と同じに見える)。
さらにこのファイルを編集したのち、やはりテキストエディタに備えられた「上書き保存」機能を利用して、ファイル名「F2」として上書きしようとすると、これは許されないアクセスであるので、このアクセスは禁じられ、ユーザにはファイルが保存できない旨、伝えられる(表示される)。読み込みの場合と同様に、このユーザへの表示は、たとえば、ホストOS１０１７自体が備える機能を利用して行えばよい。
【００４４】
本実施例を「追記」のみを許すように設定し、このテキストエディタプログラムが、ファイルを開くことなく追記する、ことに対応しているときには、ユーザUはファイルF1に追記可能である。しかし、一旦ファイルの内容を読み込んでからでないと、編集(この場合は追記)できないテキストエディタプログラムの場合には、ファイルを読み込む(開く)ことが許可されないため、結果的に追記できない。
【００４５】
同一ハードディスク内でのファイル移動のように、ハードディスクＡ１０１３内のデータをメモリA１００５内に読み込むことなく、(パス情報を含むファイル名の書き換えを行うだけ、すなわち、ファイルそのものを移動せず、ファイル名とそのファイルがハードディスク上のどこにかかれているか、を示す対応表の部分だけを書き換えることで実現できる場合がある。このようなファイルアクセスについては、任意のユーザが行えるようにしてもよい。ただし、このとき、ファイルリスト１０４３の整合性を保つために、ファイルリスト１０４３内のファイル名６００１の部分を、当該ファイル移動に合わせて書き換えるようにする。
【００４６】
また、ファイルのコピーについても、コピーの途中で当該ファイルのデータを不正に読み取られる危険性がない場合、たとえば、ハードディスク自体がファイルコピーの機能を持っているような場合には、任意のユーザが行えるようにしてもよい。ただし、このときファイルのセキュリティレベルも同時にコピーする。すなわち、ファイルリスト１０４３内に、当該ファイルに関するエントリを追加して、コピー元と同じセキュリティレベルを設定する必要がある。
また、フロッピーディスクなどの取り外し可能な可搬型記憶媒体に移動またはコピーする場合には、ファイル移動（またはコピー）時に、当該ファイルのセキュリティレベルに合わせて暗号化するようにすればよい。さらに、ファイルリスト１０４３内の当該ファイルに関する情報も、可搬型記憶媒体に書き込むようにしてもよい。
これらの処理は、たとえば、アクセス制御プログラム１０３５に機能を追加することによって、実現可能である。
【００４７】
図４を用いて、本実施例におけるユーザラベル設定時における処理フローを説明する。
(ユーザラベル設定プログラム１０２３(ホストOS１０１７上)の動作)
ステップ４００１：はじめ
(ユーザリスト管理プログラム１０３７(ゲストOS１０１９上)の処理)
ステップ４００２：ホストOS１０１７上の起動中のプロセスチェックを行う。信頼できないプロセスが起動している場合は、ステップ４００３へ。そうでなければステップ４００４へ
ステップ４００３：おわり(設定失敗)
ステップ４００４：乱数Rを生成し、ホスト側へ送信する
(ユーザラベル設定プログラム１０２３(ホストOS１０１７上)の動作)
ステップ４００５：設定情報Cu（ユーザ名、当該ユーザのクリアランスレベルなど）の入力を求める
ステップ４００６：セキュリティ管理者のパスワードPの入力を求める
ステップ４００７：乱数Rと設定情報Cuを結合(concatinate)したものを、入力されたパスワードを鍵として暗号化し、ゲスト側へ送信する
(ユーザリスト管理プログラム１０３７(ゲストOS１０１９上)の処理)
ステップ４００８：あらかじめゲストOS１０１９側で管理・保持されていたセキュリティ管理者のパスワードを用い、ゲスト側から送られてきた暗号文を復号する。復号した情報に含まれている乱数が、ステップ４００４で生成した乱数Rと等しくなければ、ステップ４００９へ。等しければ、ステップ４０１０へ
ステップ４００９：おわり(設定失敗)
ステップ４０１０：ユーザリスト１０４１にステップ４００８で復号された設定情報を反映させる
ステップ４０１１：おわり(設定成功)。
【００４８】
図５を用いて、本実施例におけるファイルラベル設定時における処理フローを説明する。
(ファイルラベル設定プログラム１０２５(ホストOS１０１７上)の動作)
ステップ５００１：はじめ
(ファイルリスト管理プログラム１０３９(ゲストOS１０１９上)の処理)
ステップ５００２：ホストOS１０１７上の起動中のプロセスチェックを行う。信頼できないプロセスが起動している場合は、ステップ５００３へ。そうでなければステップ５００４へ
ステップ５００３：おわり(設定失敗)
ステップ５００４：乱数Rを生成し、ホスト側へ送信する
(ファイルラベル設定プログラム１０２５(ホストOS１０１７上)の動作)
ステップ５００５：設定情報Cf（ファイル名、当該ファイルのセキュリティレベルなど）の入力を求める
ステップ５００６：セキュリティ管理者のパスワードPの入力を求める
ステップ５００７：乱数Rと設定情報Cfを結合(concatinate)したものを、入力されたパスワードを鍵として暗号化し、ゲスト側へ送信する
(ファイルリスト管理プログラム１０３９(ゲストOS１０１９上)の処理)
ステップ５００８：あらかじめゲストOS１０１９側で管理・保持されていたセキュリティ管理者のパスワードを用い、ゲスト側から送られてきた暗号文を復号する。復号した情報に含まれている乱数が、ステップ５００４で生成した乱数Rと等しくなければ、ステップ５００９へ。等しければ、ステップ５０１０へ
ステップ５００９：おわり(設定失敗)
ステップ５０１０：ファイルリスト１０４３にステップ５００８で復号された設定情報を反映させる
ステップ５０１１：おわり(設定成功)。
【００４９】
本実施例においては、ユーザラベルまたはファイルのセキュリティレベルの設定を行うときに、ゲストOS１０１９側のユーザリスト管理プログラム１０３７またはファイルリスト管理プログラム１０３９とセキュリティ管理者との間の認証を、チャレンジレスポンス認証(challenge-response identification)と呼ばれる方法を用いておこなっている。さらに、認証と設定情報の受け渡しを同時に行うことにより、認証処理をバイパスする等の不正を防ぎ、かつ、メッセージのやりとりの回数を減らすことができる。
【００５０】
チャレンジレスポンス認証については、
文献[HAC]：Alfred J.Menezes, Paul C. van Oorschot, Scott A. Vanstone, “Handbook of Applied Cryptography”, CRC Press
に詳しい。なお、チャレンジレスポンス認証で利用する、暗号化処理は、たとえばDES(The Data Encryption Standard)
をCBCモード(Cipher-block chaining mode)で利用することによって行えばよい(文献[HAC]参照)。DES以外の共通鍵暗号を用いてもよい。本実施例では、上記文献[HAC]に開示されたチャレンジレスポンス認証以外の認証方法(たとえば公開鍵暗号に基づく方法)を利用することも可能である。
【００５１】
以上のように、本実施例は、ユーザが直接利用する一般的なOSであるホストOS１０１７とは異なるゲストOS１０１９上に、強制アクセス制御機能を設けることにより、ホストOS１０１７上のアプリケーションプログラム１０２１に改変を加えることなく強制アクセス制御機能を実現可能にしつつ、さらに強制アクセス制御機能に対する不正を防止する。
また、ホストOS１０１７の多機能化・高機能化等の改良が行われた際にも、構成を変えることなく強制アクセス制御を可能とする。
さらに、ユーザのクリアランスやファイルのセキュリティレベルの設定にあたっては、(一般にはホストOS１０１７側の管理者とは異なる)セキュリティ管理者の認証を行うことにより、ホストOS１０１７側の管理者による不正の脅威を減らすことができるようになる。
【００５２】
（第２の実施例）
本発明の他の実施の形態を、以下、図を用いて説明する。
【００５３】
前述したように、第１の実施例に開示したシステムが正常に起動した場合、ファイルへの不正アクセスは非常に困難になり、システムを安全に運用することが可能となる。このシステムに対して考えられる更なる脅威として、たとえば、システム起動以前にホストOSのプログラムが記述されたファイルを改竄し、第１の実施例に示したゲストOS側のアクセス制御機能を回避するという不正行為が考えられる。本実施例はこの不正行為を防止する方法を提供する。
【００５４】
図９は、本実施例におけるコンピュータシステムの構成例である。図１と同じであるが、ホストOS１０１７管理下のハードディスクA１０１３内のファイルが暗号化されている点（暗号化されたファイル９００１）、および、ゲストOS１０１９管理下に、暗号プログラム９００３、復号プログラム９００５、および、暗復号化鍵(対称鍵(symmetric key)ともいう)９００７が追加されている点が異なる。
【００５５】
本実施例においては、ファイル書き込み時には、まず、第１の実施例と同様にしてアクセス制御を行い、さらに、正当なアクセスであった場合には、ゲストOS側の暗号プログラム９００３によって暗号化されてから、ホストOS１０１７側のハードディスクＡ１０１３内に保存される。
ファイル読み込み時には、まず、第１の実施例と同様にしてアクセス制御を行い、さらに、正当なアクセスであった場合には、ホストOS１０１７側のハードディスクＡ１０１３に保存された当該ファイル(暗号化されたファイル)はゲストOS側の復号プログラム９００５によって復号されたのち、ホストOS１０１７側のアプリケーションプログラム１０２１に渡される。
【００５６】
この結果、ホストOS側のファイルアクセスが、ゲストOS側のアクセス制御プログラムを利用するようになっている場合には(すなわち、ホストOS側のアクセス制御プログラムをバイパスしていないときには)、ハードディスクA１０１３内のファイルは、常に暗号化された状態でありながら、アプリケーションプログラム１０２１は、正当なアクセスである限り、暗号化されていることを意識することなく、透過的に利用可能となる。
【００５７】
一方、たとえば、ホストOSがメモリにロードされるより前に、ホストOSのプログラムが記述されたファイルを改竄することにより、不正なホストOSを起動し、ゲストOS側のアクセス制御機能を回避するという不正行為を行った場合には、読み出されたファイルは暗号化されているため、実際上意味をなさない(情報の流出はおこらない)。したがって、結果的には、ゲストOS、および、当該OS上のアクセス制御機能の起動が保証される。さらには、これにより、たとえハードディスク装置ごと取り外し、別のコンピュータに接続してファイルを解析しようとしても、ファイルが暗号化されているため解析できないという効果もある。
【００５８】
なお、さらにホストOSの不正がないことを、より確実に確認するために、ゲストOS上に、ホストOSの検証機能を設けてもよい。これは、たとえば、ゲストOSの管理下に、あらかじめ、改竄されていないホストOSプログラムのディジタル署名を保持しておき、ホストOSの起動時に、ゲストOS側において、実際に起動されるホストOSプログラムが改竄されていないことを、当該ディジタル署名の検証手続きによって確認する入出力処理監査処理部をゲストOS側に設ければよい。また、入出力処理監査処理部が、ホストOS側のプロセス管理機能を利用し、ホストOS管理で不正なプロセスが実行されていないことを監査してもよい。
【００５９】
もしホストOSプログラムが改竄されている場合には、ゲストOSに指示して、あらゆるファイルアクセスを禁止する、あるいは、ホストOSの実行を止める、などにより、ホストOSの機能を無効化すればよい。このとき、さらにコンピュータに接続されたディスプレイ上への表示、あるいは、コンピュータに接続されたスピーカーを利用した警告音、あるいは、その他の外部装置を利用したメッセージ等により、ホストOSが改竄されているために起動できない旨、ユーザに伝えるようにしてもよい。
【００６０】
図１０を用いて、本実施例におけるファイルアクセス制御フロー（読み出し）を説明する。
ステップ１０００１：はじめ
ステップ１０００２：ステップ２００２〜２００４と同様
ステップ１０００３：アクセス制御プログラムは、正当なアクセスか否かを判定する（ステップ２００５と同様）。正当であればステップ１０００６へ。そうでなければステップ１０００４へ
ステップ１０００４：ステップ２００６と同様
ステップ１０００５：おわり（アクセス不可）
ステップ１０００６：ステップ２００８〜２００９と同様
ステップ１０００７：デバイスドライバは、ハードディスクから
暗号化されたファイルの読み出しを行いファイルフックプログラムに送る
ステップ１０００８：ファイルアクセスフックプログラムは、OS間通信プログラムを利用し、復号プログラムに、暗号化されたファイルを送る
ステップ１０００９：復号プログラムは、ゲストOS側で管理された暗復号化鍵を用いて、暗号化されたファイルを復号し、OS間通信プログラム、ファイルアクセスフックプログラムを通じて、アプリケーションプログラムに送る
ステップ１００１０：おわり（アクセス成功）。
【００６１】
図１１を用いて、本実施例における、ファイルアクセス制御フロー（書き込み）を説明する。
ステップ１１００１：はじめ
ステップ１１００２：ステップ２００２〜２００４と同様
ステップ１１００３：アクセス制御プログラムは、正当なアクセスか否かを判定する（ステップ２００５と同様）。正当であればステップ１１００６へ。そうでなければステップ１１００４へ
ステップ１１００４：ステップ２００６と同様
ステップ１１００５：おわり（アクセス不可）
ステップ１１００６：ゲストOS上の暗号プログラムは、ゲストOS側で管理された暗復号化鍵を用いて、アプリケーションプログラム１０２１が書き込もうとしている情報を暗号化する
ステップ１１００７：ステップ２００８〜２０１０と同様
ステップ１１００８：おわり（アクセス成功）
ファイル生成時におけるファイルアクセス制御の処理フローは、図１１に示したファイルアクセス制御フロー（書き込み）と基本的に同様であるが、ステップ１１００２が、
ステップ１１００２‘：ステップ３００２〜３００５と同様
となる点が異なる。
【００６２】
ステップ１０００９の復号化処理、および、ステップ１１００６の暗号化処理では、たとえばDES(The Data Encryption Standard)をCBCモード(Cipher-block chaining mode)で利用すればよい(文献[HAC]参照)。ただし、CBCモードを利用する場合であっても、最初のブロック長(DESの場合であれば64-bit)分については、同じ平文を同じ鍵で暗号化すると、同じ暗号文となってしまう。これを避けるためには、CBCモードで利用される初期値IVをファイルごとに異なるようにすればよい。たとえば、ステップ１１００６で暗号化をする際に64-bitの乱数を生成し、それをIVとして暗号化時に利用するとともに、このIVをファイルリストに項目を追加して保存する。ステップ１０００９中の復号化処理では、ファイルリストから復号対象ファイルに対応するIVを読み出し復号時に利用すればよい。
【００６３】
本実施例では、ひとつの暗復号化鍵を用いて、暗復号化を行っていたが、複数の暗復号化鍵を用いてもよい。たとえば、ファイルのセキュリティレベル・区画ごとに異なる鍵、あるいは、異なる暗号方法を用いてもよい。本実施例を、このように変更した場合、セキュリティレベルが４段階あり、区画が４区画あるので、全部で１６個の異なる暗復号化鍵を用いることになる。これらの鍵はゲストOS側で管理すればよい。さらには、ファイルのセキュリティレベルに応じて、暗号方法、あるいは、鍵として、安全性が異なるものを用いてもよい。(たとえば、セキュリティレベルが高いファイルに対しては、長い鍵長の暗号化鍵を用いてもよい)。
【００６４】
また、本実施例で用いる暗復号化鍵は、ハードディスクB１０１５とは異なるハードウェアモジュール（例：ICカードなど）に格納しておくようにしてもよい。この場合、さらに当該ハードウェアモジュール内に、ゲストOS１０１９およびその上で動作する各種プログラム（アクセス制御プログラム１０３５など）が改変されていないことを検証する機能を持たせておき、正当であると確認されたときに限り、暗復号化鍵が利用可能になるように（たとえば、メモリB１００７内にロードされるように）しておくと、ゲストOS側の改ざんという脅威にも対抗できるため、より効果的である。
【００６５】
また、本実施例では、ファイルの内容自体を暗号化していたが、そうではなく、ファイルの管理テーブル部を暗号化するようにしてもよい。ファイルの管理テーブルは、通常ハードディスク内の、ファイルとは別領域に記憶されており、ファイル名と、ハードディスク内のどの部分に当該ファイルが保存されているかを示すアドレス情報との対応が、記述されている。したがって、このアドレス情報部分を暗号化することにより、ディスク内のどこにファイル情報が保存されているか調べることが困難になるため、ファイル情報漏洩の防止に効果がある。また、暗号化する対象となるデータサイズが小さいため、暗復号化にかかる処理量が少なくてすむ、という利点がある。
【００６６】
なお、本実施例でも、第１の実施例と同様、ファイルアクセスフックプログラム１０２９が、I/Oマネージャ１０２７のファイルシステムドライバ１０３１に対するファイルアクセス命令を検知し、そのファイルアクセス命令をファイルシステムドライバ１０３１に渡す前に、ゲストOS１０１９上のアクセス制御プログラム１０３５に渡す例を示した。しかし、これとは異なっていてもよい。たとえば、ファイルアクセスフックプログラム１０２９は、ファイルアクセス（例えば、読み出し）命令を、ファイルシステムドライバ１０３１に渡すのと同時、あるいは後に、アクセス制御プログラム１０３５に渡すようにし、当該ファイルアクセスが正当なものでなかったときは、ステップ１０００９の復号化処理を行わないようにしてもよい。このようにしても、不当な読み出し処理をしようとすると、アプリケーションプログラムにとっては、暗号化されたままのファイルが読み込まれることになるため、情報の漏洩はおこらない。
【００６７】
ゲストＯＳに対しては、上記第１、２の実施例による強制アクセス制御機能だけでなく、さらに別の機能を追加してもよい。
たとえば、ホストOS側でどのようなファイルアクセスがあったか（アクセス時刻、アクセスしようとしたユーザ名・プログラム名、アクセス対象ファイル名、アクセスの種類、ファイルになされた変更内容など）を記録し、保持する機能（ファイルアクセスログ管理機能）をゲストOS側が備えてもよい。
ゲストOS側で実現することにより、ホストOS、および、ホストOS上で動作するアプリケーションプログラムを改変することなく、ファイルアクセスを記録することができるようになり、さらに、記録されたファイルアクセスログが、ホストOS側から改竄、または、消去される危険性がなくなる。
【００６８】
また、ホストOS上のコンピュータウィルスを検知、あるいは、駆除するコンピュータウィルス対策プログラムをゲストOS側に設けてもよい。さらには、検知したウィルスに関する情報をネットワークを通じて、他のコンピュータとの間で送受信する機能をゲストOSに設けてもよい。
【００６９】
あるいはまた、ホストOS側のアプリケーションプログラムから明示的に実行が要求される機能を実現してもよい。たとえば、ディジタル署名生成機能または公開鍵暗号の復号機能などの暗号機能、および、これらの機能において利用される秘密鍵情報の管理などが挙げられる。さらには、発明者等が特願2000-313123号に開示した、ディジタル署名生成時に、その時点での署名履歴を利用する署名方法、および、署名履歴管理方法を実現してもよい。
この場合は、上述のファイルアクセス制御機能や、ファイルアクセスログ管理機能などとは異なり、ホストOS側アプリケーションプログラムが、あらかじめ、このゲストOS側で実現された機能に対応している必要がある。ただし、実行にあたっては、上記のユーザラベル設定フローやファイルラベル設定フローと同様の方法によって、固有のユーザ認証を行うことにより、ホストOS側のシステム管理者による不正利用を防ぐことができる。したがって、前述のディジタル署名生成機能や、公開鍵暗号の復号機能のような、各ユーザの秘密鍵情報を利用する機能を実現するためには、特に適している。あるいは、上記のコンピュータウィルス対策プログラムをホストOS側のアプリケーションプログラムから明示的に実行が要求される機能として実現してもよい。
【００７０】
上記各実施例においては、複数OS制御技術を利用し、ユーザが直接利用するホストOS上のファイルアクセス制御を、ホストOSとは異なるゲストOS管理下のソフトウェアが実現していた。しかし、本発明はこれに限定されない。たとえば、ゲストOSとゲストOS上に設けられた機能（処理部）のいずれか一つ以上を、ハードウェアとして実現してもよい。この場合、さらに、このハードウェア内に、ユーザリスト、ファイルリスト、セキュリティ管理者のパスワード、ファイル暗号用の暗号化鍵等を記憶するようにしてもよい。
【００７１】
【発明の効果】
本発明によれば、情報処理システムの情報セキュリティに関する安全性を、利用者の利便性を損なうことなく、向上させることが可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施例を実現する計算機の概略構成図である。
【図２】第１の実施例におけるファイルアクセス(読み出し、書き込み)制御の処理フロー図である。
【図３】第１の実施例におけるファイルアクセス(ファイル作成)制御の処理フロー図である。
【図４】第１の実施例におけるファイルアクセス(読み出し、書き込み)制御の処理フロー図である。
【図５】第１の実施例におけるファイルラベル設定時における処理フロー図である。
【図６】第１の実施例におけるユーザリストユーザリストの一例である。
【図７】第１の実施例におけるファイルリストファイルリストの一例である。
【図８】第１の実施例におけるユーザ”researcher”がアクセスすることが許されるファイルのセキュリティレベルを示したものである。
【図９】第２の実施例を実現する計算機の概略構成図である。
【図１０】第２の実施例におけるファイルアクセス(読み出し)制御の処理フロー図である。
【図１１】第２の実施例におけるファイルアクセス(書き込み)制御の処理フロー図である。
【符号の説明】
１００１：コンピュータ
１００３：CPU
１００５：メモリA
１００７：メモリB
１００９：ディスプレイ
１０１１：キーボード
１０１３：ハードディスクA
１０１５：ハードディスクB
１０１７：ホストOS
１０１９：ゲストOS
１０２１：アプリケーションプログラム
１０２３：ユーザラベル設定プログラム
１０２５：ファイルラベル設定プログラム
１０２７：I/Oマネージャ
１０２９：ファイルアクセスフックプログラム
１０３１：ファイルシステムドライバ
１０３３：デバイスドライバ
１０３５：アクセス制御プログラム
１０３７：ユーザリスト管理プログラム
１０３９：ファイルリスト管理プログラム
１０４１：ユーザリスト
１０４３：ファイルリスト
１０４５：ファイル
１０４７：セキュリティ管理者のパスワード
１０４９：複数OS制御プログラム
１０５１：OS間通信プログラム
９００１：暗号化されたファイル
９００３：暗号プログラム
９００５：復号プログラム
９００７：暗号化鍵
Claims (12)
- ファイルアクセスとして記憶装置に格納されたファイルの読み出し，または，前記記憶装置へのファイルの書き込みを実行するドライバ部と，プログラム処理により，前記ドライバ部へ前記ファイルアクセスを命令するアクセス実行命令部と，前記アクセス実行命令部が前記ドライバ部へ命令するファイルアクセスを監視するアクセス監視処理部と，前記ファイルアクセス実行時にアクセス制御を行うアクセス制御部と，を備える計算機システムであって，
前記記憶装置と，前記ドライバ部と，前記アクセス実行命令部と，前記アクセス監視処理部は，第一の管理者権限により管理され，
前記アクセス制御部は，前記第一の管理者権限とは異なる第二の管理者権限により管理され，前記ファイルアクセスの対象となるファイルのセキュリティレベルを記述した，ファイルリストと，ユーザのクリアランスを記述した，ユーザリストと，復号化プログラムと，復号化鍵と，アクセス制御処理部と，を備え，
前記アクセス監視処理部は，
前記アクセス実行命令部に対するインターフェイスとして，前記ドライバ部が前記アクセス実行命令部に対して備えるインターフェイスを備え，
前記ドライバ部に対するインターフェイスとして，前記アクセス実行命令部が前記ドライバ部に対して備えるインターフェイスを備え，
前記アクセス実行命令部に対する前記インターフェイスを介して受信する，前記ドライバ部へのファイル読み出し命令に基づき，ファイル読み出しというアクセスタイプと，ファイルを特定する情報と，当該計算機システムを利用するユーザを特定する情報と，を含む，前記ファイル読み出し命令の正当性判定に必要な情報を前記アクセス制御処理部に送り，
前記ファイル読み出し命令の正当性判定結果を前記アクセス制御処理部から受け取り，前記ファイル読み出し命令が正当であれば，前記ファイル読み出し命令を，前記ドライバ部に対する前記インターフェイスを介して前記ドライバ部に送信して実行させ，
読み出された暗号化ファイルを，前記ドライバ部に対する前記インターフェイスを介して受信して，前記アクセス制御処理部に送信し，前記アクセス制御処理部から復号化ファイルを受信して，前記アクセス実行命令部に対する前記インターフェイスを介して，前記アクセス実行命令部に送信し，
前記アクセス制御処理部は，
前記ファイル読み出し命令の正当性を，前記ファイルリストと，前記ユーザリストと，前記アクセスタイプと，前記ファイルを特定する情報と，前記ユーザを特定する情報と，に基づき判定し，
前記アクセス監視処理部から暗号化ファイルを受信し，受信した前記暗号化ファイルを前記復号プログラムと前記復号化鍵を用いて復号し，復号化ファイルを前記アクセス監視処理部に送信する
ことを特徴とする計算機システム。 - 請求項１に記載の計算機システムであって，
前記アクセス制御部は，さらに，
暗号化プログラムと，暗号化鍵と，を備え，
前記アクセス監視処理部は，
前記アクセス実行命令部に対する前記インターフェイスを介して受信する，前記ドライバ部へのファイル書き込み命令に基づき，ファイル書き込みというアクセスタイプと，ファイルを特定する情報と，当該計算機システムを利用するユーザを特定する情報と，を含む，前記ファイル書き込み命令の正当性判定と書き込みファイルの暗号化とに必要な情報を前記アクセス制御処理部に送り，
前記ファイル書き込み命令の正当性判定結果を前記アクセス制御処理部から受け取り， 前記ファイル書き込み命令が正当であれば，前記アクセス制御処理部が作成する，前記書き込みファイルの暗号化ファイルを取得し，
前記暗号化ファイルを対象とする前記ファイル書き込み命令を，前記ドライバ部に対する前記インターフェイスを介して前記ドライバ部に送信して実行させ，
前記アクセス制御処理部は，
前記ファイル書き込み命令の正当性を，前記ファイルリストと，前記ユーザリストと，前記アクセスタイプと，前記ファイルを特定する情報と，前記ユーザを特定する情報と，に基づき判定し，
前記アクセス監視処理部から受信する，前記書き込みファイルの暗号化に必要な前記情報と，前記暗号プログラムと前記暗号化鍵とを用いて，前記暗号化ファイルを作成し，前記アクセス管理処理部に送信する
ことを特徴とする計算機システム。 - 請求項１または２に記載の計算機システムであって，
アクセス制御処理部は，前記ファイルリストに記述された，前記ファイルアクセスの対象となるファイルの前記セキュリティレベルごとに，異なる暗号方法，または，異なる鍵を用いる
ことを特徴とする計算機システム。 - 請求項１ないし３いずれか一に記載の計算機システムであって，
アクセス制御処理部は，前記ファイルアクセスの対象となるファイルが属する区画ごとに，異なる暗号方法，または，異なる鍵を用いる
ことを特徴とする計算機システム。 - 請求項１ないし４いずれか一に記載の計算機システムであって，
前記アクセス制御部は，さらに，
前記ユーザリストの設定と管理を行うためのユーザリスト設定管理処理部を備える
ことを特徴とする計算機システム。 - 請求項５記載の計算機システムであって，
前記アクセス制御部は，さらに，
前記ユーザリスト設定処理部は，前記第二の管理者の認証処理部を備える
ことを特徴とする計算機システム。 - 請求項１ないし６いずれか一に記載の計算機システムであって，
前記アクセス制御部は，さらに，
前記ファイルリストの設定と管理を行うためのファイルリスト設定管理処理部を備える
ことを特徴とする計算機システム。 - 請求項７記載の計算機システムであって，
前記アクセス制御部は，さらに，
前記ファイルリスト設定管理処理部は，前記第二の管理者の認証処理部を備える
ことを特徴とする計算機システム。 - 請求項１ないし８いずれか一に記載の計算機システムであって，
前記アクセス制御部は，さらに，
前記ドライバ部またはアクセス監視処理部が，改ざんされていないこと，あるいはあらかじめ定められた動作をしていることを監査し，
前記ドライバ部またはアクセス監視処理部が，改ざんされている場合，あるいはあらかじめ定められた動作と異なる動作をしている場合には，ファイルアクセスの中止を指示する監査処理部を備える
ことを特徴とする計算機システム。 - 請求項１ないし９いずれか一に記載の計算機システムであって，
前記アクセス制御部は，さらに，
前記アクセス制御処理部に伝えられた前記ファイル読み出し命令または前記ファイル書き込み命令に関する情報を記録し，保持するファイルアクセスログ管理部を備える
ことを特徴とする計算機システム。 - 請求項１ないし１０いずれか一に記載の計算機システムであって，
前記計算機システムは，ＣＰＵを備え，
前記アクセス制御部は，前記ＣＰＵがソフトウェアモジュールを実行することにより実現される
ことを特徴とする計算機システム。 - 請求項１ないし１０いずれか一に記載の計算機システムであって，
前記アクセス制御部は，さらに，
前記アクセス制御部は，前記計算機システムが備えるハードウェアモジュールとして実現される
ことを特徴とする計算機システム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001125224A JP4089171B2 (ja) | 2001-04-24 | 2001-04-24 | 計算機システム |
| EP02003596A EP1253502A3 (en) | 2001-04-24 | 2002-02-15 | Trusted computer system |
| US10/081,061 US7210043B2 (en) | 2001-04-24 | 2002-02-20 | Trusted computer system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001125224A JP4089171B2 (ja) | 2001-04-24 | 2001-04-24 | 計算機システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002318719A JP2002318719A (ja) | 2002-10-31 |
| JP4089171B2 true JP4089171B2 (ja) | 2008-05-28 |
Family
ID=18974481
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001125224A Expired - Lifetime JP4089171B2 (ja) | 2001-04-24 | 2001-04-24 | 計算機システム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7210043B2 (ja) |
| EP (1) | EP1253502A3 (ja) |
| JP (1) | JP4089171B2 (ja) |
Families Citing this family (65)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9928508B2 (en) | 2000-08-04 | 2018-03-27 | Intellectual Ventures I Llc | Single sign-on for access to a central data repository |
| US8566248B1 (en) | 2000-08-04 | 2013-10-22 | Grdn. Net Solutions, Llc | Initiation of an information transaction over a network via a wireless device |
| US7257581B1 (en) | 2000-08-04 | 2007-08-14 | Guardian Networks, Llc | Storage, management and distribution of consumer information |
| JP3755415B2 (ja) * | 2001-04-04 | 2006-03-15 | 株式会社デンソー | 処理実行装置、当該処理実行装置に搭載される処理プログラム、及び記録媒体 |
| US7640582B2 (en) * | 2003-04-16 | 2009-12-29 | Silicon Graphics International | Clustered filesystem for mix of trusted and untrusted nodes |
| US8010558B2 (en) | 2001-06-05 | 2011-08-30 | Silicon Graphics International | Relocation of metadata server with outstanding DMAPI requests |
| US20040139125A1 (en) | 2001-06-05 | 2004-07-15 | Roger Strassburg | Snapshot copy of data volume during data access |
| US7617292B2 (en) | 2001-06-05 | 2009-11-10 | Silicon Graphics International | Multi-class heterogeneous clients in a clustered filesystem |
| WO2003104947A2 (en) | 2002-06-06 | 2003-12-18 | Hardt Dick C | Distributed hierarchical identity management |
| JP2004021516A (ja) * | 2002-06-14 | 2004-01-22 | Mori Seiki Co Ltd | データ通信可能な制御装置及びこれを備えたデータ伝送システム |
| US7958351B2 (en) * | 2002-08-29 | 2011-06-07 | Wisterium Development Llc | Method and apparatus for multi-level security implementation |
| US7814021B2 (en) * | 2003-01-23 | 2010-10-12 | Verdasys, Inc. | Managed distribution of digital assets |
| US7472272B2 (en) * | 2003-01-23 | 2008-12-30 | Verdasys, Inc. | Digital asset usage accountability via event journaling |
| JP4265915B2 (ja) * | 2003-01-29 | 2009-05-20 | シャープ株式会社 | 電子機器ネットワークシステムおよび電子機器ネットワークシステムによるデータ送信先検索方法 |
| JP2004234390A (ja) * | 2003-01-30 | 2004-08-19 | Fujitsu Ltd | 情報管理方法、情報管理システム、中央装置、端末装置及びコンピュータプログラム |
| GB2399902A (en) * | 2003-03-28 | 2004-09-29 | Hewlett Packard Development Co | Security in trusted computing systems |
| US20050021522A1 (en) * | 2003-05-16 | 2005-01-27 | Mark Herman | Apparatus, method and computer readable medium for evaluating a network of entities and assets |
| US20050021980A1 (en) | 2003-06-23 | 2005-01-27 | Yoichi Kanai | Access control decision system, access control enforcing system, and security policy |
| JP4954254B2 (ja) * | 2003-06-23 | 2012-06-13 | 株式会社リコー | セキュリティポリシー |
| US7398390B2 (en) * | 2003-08-08 | 2008-07-08 | Hewlett-Packard Development Company, L.P. | Method and system for securing a computer system |
| US7302569B2 (en) * | 2003-08-19 | 2007-11-27 | International Business Machines Corporation | Implementation and use of a PII data access control facility employing personally identifying information labels and purpose serving functions sets |
| US7464412B2 (en) | 2003-10-24 | 2008-12-09 | Microsoft Corporation | Providing secure input to a system with a high-assurance execution environment |
| JP2005140823A (ja) | 2003-11-04 | 2005-06-02 | Sony Corp | 情報処理装置、制御方法、プログラム、並びに記録媒体 |
| JP2005182747A (ja) * | 2003-11-27 | 2005-07-07 | Ricoh Co Ltd | 文書管理装置、システム、方法及びプログラム |
| US7330981B2 (en) * | 2004-04-23 | 2008-02-12 | Microsoft Corporation | File locker and mechanisms for providing and using same |
| US9245266B2 (en) | 2004-06-16 | 2016-01-26 | Callahan Cellular L.L.C. | Auditable privacy policies in a distributed hierarchical identity management system |
| US8527752B2 (en) * | 2004-06-16 | 2013-09-03 | Dormarke Assets Limited Liability | Graduated authentication in an identity management system |
| US8504704B2 (en) | 2004-06-16 | 2013-08-06 | Dormarke Assets Limited Liability Company | Distributed contact information management |
| JP4720136B2 (ja) * | 2004-09-24 | 2011-07-13 | 富士ゼロックス株式会社 | 暗号化装置、暗号化方法およびプログラム |
| JP4239950B2 (ja) | 2004-10-29 | 2009-03-18 | コニカミノルタビジネステクノロジーズ株式会社 | デバイスとその管理方法及び管理プログラム |
| US8831115B2 (en) * | 2004-12-22 | 2014-09-09 | Qualcomm Incorporated | MC-CDMA multiplexing in an orthogonal uplink |
| JP4853671B2 (ja) * | 2005-03-24 | 2012-01-11 | 日本電気株式会社 | アクセス権限判定システム、アクセス権限判定方法及びアクセス権限判定プログラム |
| JP4636607B2 (ja) * | 2005-06-29 | 2011-02-23 | 株式会社日立ソリューションズ | セキュリティ対策アプリケーションの機密ファイル保護方法 |
| JP4738412B2 (ja) * | 2005-07-12 | 2011-08-03 | 富士通株式会社 | 共用管理プログラム、共用管理方法、端末装置、及び共用管理システム |
| US7565685B2 (en) * | 2005-11-12 | 2009-07-21 | Intel Corporation | Operating system independent data management |
| JP2007179130A (ja) * | 2005-12-27 | 2007-07-12 | Kokuyo Co Ltd | 分類管理装置及びそのプログラム |
| JP2008117316A (ja) * | 2006-11-07 | 2008-05-22 | Nomura Research Institute Ltd | 業務情報防護装置 |
| JP2008117317A (ja) * | 2006-11-07 | 2008-05-22 | Nomura Research Institute Ltd | 業務情報防護装置 |
| US8484309B2 (en) * | 2007-02-20 | 2013-07-09 | International Business Machines Corporation | Owner controlled access to shared data resource |
| JP4963982B2 (ja) * | 2007-02-22 | 2012-06-27 | 三菱電機インフォメーションシステムズ株式会社 | 自己解凍形式のデータ構造、自己解凍プログラム、およびコンピュータ |
| US20080244738A1 (en) * | 2007-03-28 | 2008-10-02 | Fujitsu Limited | Access control |
| US9461819B2 (en) | 2007-05-23 | 2016-10-04 | Nec Corporation | Information sharing system, computer, project managing server, and information sharing method used in them |
| JP4857201B2 (ja) * | 2007-06-20 | 2012-01-18 | キヤノン株式会社 | 情報処理装置 |
| JP4287485B2 (ja) * | 2007-07-30 | 2009-07-01 | 日立ソフトウエアエンジニアリング株式会社 | 情報処理装置及び方法、コンピュータ読み取り可能な記録媒体、並びに、外部記憶媒体 |
| JP4782871B2 (ja) * | 2007-10-03 | 2011-09-28 | 富士通株式会社 | デバイスアクセス制御プログラム、デバイスアクセス制御方法および情報処理装置 |
| JP2009105566A (ja) * | 2007-10-22 | 2009-05-14 | Sky Kk | 配布管理装置及び配布管理プログラム |
| CN101925913A (zh) * | 2008-01-31 | 2010-12-22 | 国际商业机器公司 | 加密文件访问的方法和系统 |
| US20110035783A1 (en) * | 2008-03-03 | 2011-02-10 | Hiroshi Terasaki | Confidential information leak prevention system and confidential information leak prevention method |
| WO2009113071A2 (en) * | 2008-03-12 | 2009-09-17 | Safend Ltd. | System and method for enforcing data encryption on removable media devices |
| US7529932B1 (en) * | 2008-03-31 | 2009-05-05 | International Business Machines Corporation | Removable medium and system and method for writing data to same |
| JP2009252034A (ja) * | 2008-04-08 | 2009-10-29 | Nec Corp | アクセス制御システム及びアクセス制御方法 |
| US20100122313A1 (en) * | 2008-11-09 | 2010-05-13 | Aspect9, Inc. | Method and system for restricting file access in a computer system |
| JP5282879B2 (ja) * | 2008-12-05 | 2013-09-04 | 日本電気株式会社 | プライバシ情報保護システムとその方法 |
| US8239395B2 (en) * | 2008-12-26 | 2012-08-07 | Sandisk Il Ltd. | Storage device presenting to hosts only files compatible with a defined host capability |
| US8166067B2 (en) * | 2008-12-26 | 2012-04-24 | Sandisk Il Ltd. | Method and apparatus for providing access to files based on user identity |
| US20100169395A1 (en) * | 2008-12-26 | 2010-07-01 | Sandisk Il Ltd. | Device and method for filtering a file system |
| US8943409B2 (en) * | 2008-12-26 | 2015-01-27 | Sandisk Il Ltd. | Storage device managing playable content |
| JP5564968B2 (ja) * | 2010-02-05 | 2014-08-06 | 富士ゼロックス株式会社 | 情報処理装置及び情報処理プログラム |
| US8813255B2 (en) * | 2011-01-28 | 2014-08-19 | International Business Machines Corporation | Security classification applying social norming |
| US8448258B2 (en) * | 2011-01-28 | 2013-05-21 | International Business Machines Corporation | Security classification based on user interaction |
| JP2013092960A (ja) * | 2011-10-27 | 2013-05-16 | Ntt Electornics Corp | 情報処理装置及び情報処理方法 |
| US8418230B1 (en) * | 2012-08-28 | 2013-04-09 | Netcomm Wireless Limited | Apparatus and method for mobile communications and computing |
| JP6092057B2 (ja) * | 2013-09-13 | 2017-03-08 | 株式会社日立ソリューションズ | ファイルアクセス制御装置、ファイルアクセス制御プログラム及びファイルアクセス制御方法 |
| GB2558918B (en) * | 2017-01-19 | 2020-01-29 | Exacttrak Ltd | Security Device |
| JPWO2022172578A1 (ja) * | 2021-02-12 | 2022-08-18 |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4713753A (en) * | 1985-02-21 | 1987-12-15 | Honeywell Inc. | Secure data processing system architecture with format control |
| JPH0388052A (ja) * | 1989-08-31 | 1991-04-12 | Toshiba Corp | 機密保護処理方式 |
| US5263157A (en) * | 1990-02-15 | 1993-11-16 | International Business Machines Corporation | Method and system for providing user access control within a distributed data processing system by the exchange of access control profiles |
| JPH06175842A (ja) * | 1992-12-07 | 1994-06-24 | Ricoh Co Ltd | 統合文書処理装置 |
| JP3302086B2 (ja) * | 1993-03-31 | 2002-07-15 | 富士通エフ・アイ・ピー株式会社 | 圧縮暗号化装置 |
| JP3453842B2 (ja) * | 1994-04-26 | 2003-10-06 | 三菱電機株式会社 | セキュアシステム |
| JPH0926916A (ja) * | 1995-07-12 | 1997-01-28 | Oki Electric Ind Co Ltd | 非破壊ディスク装置 |
| US5771379A (en) * | 1995-11-01 | 1998-06-23 | International Business Machines Corporation | File system and method for file system object customization which automatically invokes procedures in response to accessing an inode |
| JP3684266B2 (ja) * | 1996-04-26 | 2005-08-17 | 株式会社日立製作所 | 暗号化された共有データのアクセス制御方法及びシステム |
| JPH10149207A (ja) * | 1996-11-19 | 1998-06-02 | Toshiba Corp | マンマシンインタフェース装置 |
| US6006228A (en) * | 1996-12-11 | 1999-12-21 | Ncr Corporation | Assigning security levels to particular documents on a document by document basis in a database |
| JP3293760B2 (ja) * | 1997-05-27 | 2002-06-17 | 株式会社エヌイーシー情報システムズ | 改ざん検知機能付きコンピュータシステム |
| JP3546678B2 (ja) * | 1997-09-12 | 2004-07-28 | 株式会社日立製作所 | マルチｏｓ構成方法 |
| US6249866B1 (en) * | 1997-09-16 | 2001-06-19 | Microsoft Corporation | Encrypting file system and method |
| US6754820B1 (en) * | 2001-01-30 | 2004-06-22 | Tecsec, Inc. | Multiple level access system |
| JP4116137B2 (ja) * | 1998-03-06 | 2008-07-09 | 富士通株式会社 | 電子データ交換システムにおけるデータ保護装置及び方法及び当該方法を実現するプログラムを記録した記録媒体 |
| US6356863B1 (en) * | 1998-09-08 | 2002-03-12 | Metaphorics Llc | Virtual network file server |
| JP2000235569A (ja) * | 1999-02-17 | 2000-08-29 | Ntt Data Corp | 電子文書の管理方法及び文書管理システム |
| JP2000313123A (ja) | 1999-04-28 | 2000-11-14 | Canon Inc | インクジェット記録ヘッド、インクジェット記録装置、およびインクジェット記録ヘッドの吐出回復方法 |
| US7346570B2 (en) * | 2000-07-14 | 2008-03-18 | R&R Consulting Limited | Structured finance performance monitoring index |
| US6947556B1 (en) * | 2000-08-21 | 2005-09-20 | International Business Machines Corporation | Secure data storage and retrieval with key management and user authentication |
| US20020099666A1 (en) * | 2000-11-22 | 2002-07-25 | Dryer Joseph E. | System for maintaining the security of client files |
| US20040111353A1 (en) * | 2002-12-03 | 2004-06-10 | Ellis Robert A. | System and method for managing investment information |
-
2001
- 2001-04-24 JP JP2001125224A patent/JP4089171B2/ja not_active Expired - Lifetime
-
2002
- 2002-02-15 EP EP02003596A patent/EP1253502A3/en not_active Withdrawn
- 2002-02-20 US US10/081,061 patent/US7210043B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002318719A (ja) | 2002-10-31 |
| US20020174369A1 (en) | 2002-11-21 |
| US7210043B2 (en) | 2007-04-24 |
| EP1253502A3 (en) | 2008-12-24 |
| EP1253502A2 (en) | 2002-10-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4089171B2 (ja) | 計算機システム | |
| EP2583410B1 (en) | Single-use authentication methods for accessing encrypted data | |
| EP1391802B1 (en) | Saving and retrieving data based on symmetric key encryption | |
| AU2007252841B2 (en) | Method and system for defending security application in a user's computer | |
| US7765397B2 (en) | Generating, migrating or exporting bound keys | |
| JP4278327B2 (ja) | コンピュータ・プラットフォームおよびその運用方法 | |
| JP4392241B2 (ja) | 付属記憶装置を採用したコンピュータ・システム内の安全保護を促進するための方法ならびにシステム | |
| US20050060568A1 (en) | Controlling access to data | |
| US20030221115A1 (en) | Data protection system | |
| US20050060561A1 (en) | Protection of data | |
| US20060174352A1 (en) | Method and apparatus for providing versatile services on storage devices | |
| EP1840786B1 (en) | Computer architecture for an electronic device providing single-level secure access to multi-level secure file system | |
| JP2005310122A (ja) | ファイルロッカー、およびファイルロッカーを提供し使用するための機構 | |
| KR20140051350A (ko) | 디지털 서명 권한자 의존형 플랫폼 기밀 생성 기법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040323 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060418 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071012 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071113 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080115 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080205 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080218 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110307 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110307 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120307 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130307 Year of fee payment: 5 |