JP4152099B2 - アクセス制御履歴保証方法 - Google Patents
アクセス制御履歴保証方法 Download PDFInfo
- Publication number
- JP4152099B2 JP4152099B2 JP2001376606A JP2001376606A JP4152099B2 JP 4152099 B2 JP4152099 B2 JP 4152099B2 JP 2001376606 A JP2001376606 A JP 2001376606A JP 2001376606 A JP2001376606 A JP 2001376606A JP 4152099 B2 JP4152099 B2 JP 4152099B2
- Authority
- JP
- Japan
- Prior art keywords
- access control
- access
- history
- history data
- account
- 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 - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、アクセス制御履歴保証方法、より詳細には、ファイルに対するアクセス制御が適切に実施されていたことを保証するアクセス制御履歴保証方法に関する。
【０００２】
【従来の技術】
ＵＮＩＸ（登録商標）やＷｉｎｄｏｗｓ（登録商標）のようなオペレーティングシステム（ＯＳ）や、電子文書管理システムでは、その制御下に置かれているファイル、電子文書といったものに対して正当なユーザのみがアクセスできるようにアクセス制御を行うのが一般的である。そのようにアクセス制御されるオブジェクト（ファイル、電子文書）に対して、実際にどのようなアクセスがあったのか、不正なアクセスがなかったか、を後で調べられるようにするために、各オブジェクトに対するアクセス履歴（アクセスログ）を記録しておくのが一般的である。
【０００３】
システムの安全運用監査などを行う際には、上記のようにして記録されたアクセス履歴を参照・確認することになる。しかし、オブジェクトの個数が多くなると、各オブジェクトにどのようなアクセスがあったかを監査するのは非常に手間がかかることになり、実際には例えばサンプリング監査をすることになる。サンプリング監査を行った場合には、サンプリングの対象とならなかったオブジェクトへの不正アクセスがなかったかどうかについては、確認することができない。
【０００４】
しかし、その一方で、アクセス制御に使用された設定情報というものはそれほど頻繁に変更することはなく、また、各オブジェクトについてばらばらなアクセス制御を行うことは稀であって、例えばあるフォルダとその下位のファイルにはすべて同じアクセス権を付与する、というような運用を行うのが一般的である。
【０００５】
そのため、システムの監査を考えれば、各オブジェクトへのアクセス履歴を記録しておくよりも、適切なアクセス制御設定を実行していたことの履歴を記録しておいて、その履歴を監査するようにすればオブジェクトをサンプリングして監査するよりも、広い範囲のオブジェクトについて満遍のない監査を行うことができる。
【０００６】
【発明が解決しようとする課題】
本発明は、上述のごとき実情に鑑みてなされたもので、ファイルに対するアクセス制御が適切に実施されていたことを保証するアクセス制御履歴保証方法を提供することを目的とするものである。
【０００７】
【課題を解決するための手段】
請求項１の発明は、サブジェクトがオブジェクトへアクセスする際に、サブジェクトに付与されたアクセス権に応じて、サブジェクトからオブジェクトへのアクセスを制御するシステムに適用され、該アクセスの制御履歴を保証できるようにしたアクセス制御履歴保証方法において、前記アクセスを制御するシステムは、オブジェクトごとに設定されているサブジェクトのアクセス権の変遷の履歴を、前記システムが備えるデータベースにアクセス制御履歴データとして記録しておき、記録した該アクセス制御履歴データに対して、後で改ざん検知が可能なように処理しておくことを特徴としたものである。
【０００８】
請求項２の発明は、請求項１の発明において、前記アクセス権は、オブジェクトごとに設定されたアクセス制御リストによって指示されていることを特徴としたものである。
【０００９】
請求項３の発明は、請求項１または２の発明において、前記アクセスを制御するシステムは、前記アクセス制御履歴データの改ざんを検知するために、該アクセス制御履歴データに対してメッセージ認証子を計算して該アクセス制御履歴データとともに前記データベースに記録しておくことを特徴としたものである。
【００１０】
請求項４の発明は、請求項１または２の発明において、前記アクセスを制御するシステムは、前記アクセス制御履歴データの改ざんを検知するために、該アクセス制御履歴データに対して電子署名を計算して該アクセス制御履歴データとともに前記データベースに記録しておくことを特徴としたものである。
【００１１】
請求項５の発明は、サブジェクトがオブジェクトへアクセスする際に、サブジェクトに付与されたアクセス権に応じて、サブジェクトからオブジェクトへのアクセスを制御するシステムに適用され、該アクセスの制御履歴を保証できるようにしたアクセス制御履歴保証方法において、前記アクセスを制御するシステムは、サブジェクトを構成する要素を示すアカウントの変遷の履歴を、前記システムが備えるデータベースにアカウント構成履歴データとして、記録しておき、記録した該アカウント構成履歴データに対して、後で改ざん検知が可能なように処理しておくことを特徴としたものである。
【００１２】
請求項６の発明は、請求項５の発明において、前記サブジェクトは、システムのユーザアカウントとグループアカウントとにより示される要素によって構成されることを特徴としたものである。
【００１３】
請求項７の発明は、請求項５または６の発明において、前記アクセスを制御するシステムは、前記アカウント構成履歴データの改ざんを検知するために、アカウント構成履歴データに対してメッセージ認証子を計算して該アカウント構成履歴データとともに前記データベースに記録しておくことを特徴としたものである。
【００１４】
請求項８の発明は、請求項５または６の発明において、前記アクセスを制御するシステムは、前記アカウント構成履歴データの改ざんを検出するために、該アカウント構成履歴データに対して電子署名を計算して該アカウント構成履歴データとともに前記データベースに記録しておくことを特徴としたものである。
【００１５】
請求項９の発明は、サブジェクトがオブジェクトへアクセスする際に、サブジェクトに付与されたアクセス権に応じて、サブジェクトからオブジェクトへのアクセスを制御するシステムに適用され、該アクセスの制御履歴を保証できるようにしたアクセス制御履歴保証方法において、前記アクセスを制御するシステムは、オブジェクトごとに設定されているサブジェクトのアクセス権の変遷の履歴を、前記システムが備えるデータベースにアクセス制御履歴データとして記録しておき、記録した該アクセス制御履歴データに対して、後で改ざん検知が可能なように処理しておき、さらに前記アクセスを制御するシステムは、サブジェクトを構成する要素を示すアカウントの変遷の履歴を、前記システムが備える他のデータベースにアカウント構成履歴データとして記録しておき、記録した該アカウント構成履歴データに対して、後で改ざん検知が可能なように処理しておくことを特徴としたものである。
【００１６】
請求項１０の発明は、請求項９の発明において、前記アクセス権は、オブジェクトごとに設定されたアクセス制御リストによって指示されていることを特徴としたものである。
【００１７】
請求項１１の発明は、請求項９の発明において、サブジェクトは、システムのユーザアカウントとグループアカウントとにより示される要素によって構成されることを特徴としたものである。
【００１８】
請求項１２の発明は、請求項９ないし１１のいずれか１の発明おいて、前記アクセスを制御するシステムは、前記アクセス制御履歴データと前記アカウント構成履歴データの改ざんを検出するために、該アクセス制御履歴データと該アカウント構成履歴データそれぞれに対してメッセージ認証子を計算して該アクセス制御履歴データと該アカウント構成履歴データをそれぞれ前記データベース及び前記他のデータベースに記録しておくことを特徴としたものである。
【００１９】
【発明の実施の形態】
図１は、本発明のアクセス制御履歴保証方法を適用可能な電子文書管理システムの一例を説明するためのブロック図である。ここでは本発明の実施の形態を電子文書管理システムを例にして説明する。電子文書管理システム１０は、電子文書ＤＢ１５を内部に備え、ユーザから電子文書へのアクセスの要求が入力されると、ユーザ認証手段１１によってそのユーザの認証を行い、アクセス権検証手段１３が文書へのアクセス権の有無をチェックした上で、アクセス権がある場合に限り、文書アクセス処理手段１２によってユーザから要求されたアクセス処理を実行するシステムである。
【００２０】
図２は、図１に示すごとくの電子文書管理システムにおけるユーザ認証手段１１の処理例について説明するためのフローチャートである。以下にユーザ認証手段１１の処理例を図２のフローチャートに従って、図１を参照しながら説明する。ユーザ認証処理手段１１は、ユーザから文書アクセス要求（アカウント名，パスワード，文書ＩＤ，及びアクセス種別）を受け取った際（ステップＳ１）、アカウント名に対応するパスワードハッシュ値をユーザ管理ＤＢ１４から取得し（ステップＳ２）、さらにアクセス要求に含まれるパスワードのハッシュ値を計算する（ステップＳ３）。次いでステップＳ２で先に取り出したパスワードハッシュ値と、ステップＳ３で計算したハッシュ値とを比較する（ステップＳ４）。
【００２１】
比較した結果、上記二つのハッシュ値が一致するか判断し（ステップＳ５）、一致しなけければエラーで処理を終了する（ステップＳ９）。またハッシュ値が一致すれば、ユーザ管理ＤＢ１４から、アカウント名に対応するユーザが所属しているグループのリストを取得する（ステップＳ６）。そして文書アクセス処理手段１２にアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別のデータを渡し（ステップＳ７）、正常に処理を終了する（ステップＳ８）。上記ハッシュ値は、例えば米国標準技術局による規格であるＳＨＡ−１のようなアルゴリズムを用いて計算することができる。
【００２２】
図３は、文書アクセス要求データの一例を示す図である。電子文書管理システムに入力する文書アクセス要求は、上述のようにアカウント名，パスワード，文書ＩＤ，及びアクセス種別を示すデータが含まれる。これらデータは、例えば、図３に示すごとくのものである。
【００２３】
図４は、ユーザ管理ＤＢ１４で管理されるアカウント管理ファイルの一例を示す図である。ユーザ管理ＤＢ１４では、各アカウント毎に、図４に示すごとくの情報を管理する。図４に示すように、アカウントが抹消された場合でもアカウントのエントリが削除されるのではなく、抹消（“ｄｅｌｅｔｅ”）の日時が記録される。図４に示すように、ユーザ管理ＤＢ１４では、該ユーザ管理ＤＢ１４をのぞき見られた際にパスワードが暴露しないよう、パスワードそのものをユーザ管理ＤＢ１４に保存するのではなく、パスワードのハッシュ値を保存している。
【００２４】
図５は、ユーザ管理ＤＢ１４に保持されるグループリストに係わるデータの一例を示す図である。ユーザ管理ＤＢ１４には、上記のアカウント管理フィル以外にも、図５に示すようなグループリストが例えばｇｒｏｕｐ.ｌｉｓｔというファイル名でグループ管理ファイルとして記録されている。
【００２５】
図５において、例えば“ｔａｒｏ”が所属するグループを検索する場合、まず、メンバ情報に“ｔａｒｏ”が含まれるグループ名で且つグループが削除されていないものを検索し、さらにここで検索されたグループ名情報がメンバ情報として含まれるグループ名を検索する。このようにして、所属グループリストとして“ｌａｂ１”及び“ｌａｂ＿ａｌｌ”を得る。グループ設定履歴については後で詳しく説明する。
【００２６】
電子文書管理システム１０における文書アクセス処理手段１２は、ユーザ認証手段１１から受け取った情報（アカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別）をもとに、対象ユーザに対してアクセスが許可されているかどうか検証した上で、要求された電子文書へのアクセス処理を行う。
【００２７】
図６は、上記文書アクセス処理手段１２の処理の一例を説明するためのフローチャートである。文書アクセス処理手段１２では、まずユーザ認証手段１１からアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別のデータを受け取る（ステップＳ１１）。そしてアクセス権検証手段１３に、上記のアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別のデータを渡す（ステップＳ１２）。そしてアクセス権検証手段１３による検証結果に従ってアクセス権がなければエラーで処理を終了する（ステップＳ１３，Ｓ１７）。また上記検証結果においてアクセス権があることが検証されたならば、文書アクセス処理手段１２は、文書ＩＤで指定された電子文書に対してアクセス種別で指定されたアクセスを行い（ステップＳ１３，Ｓ１４）、処理結果をユーザに返してから（ステップＳ１５）、正常に処理を終了する（ステップＳ１６）。
【００２８】
図７は、電子文書管理システム１０におけるアクセス権検証手段１３の処理の一例を説明するためのフローチャートである。アクセス権検証手段１３では、文書アクセス処理手段１２からアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別のデータを受け取った際（ステップＳ２１）、アクセス権ＤＢ１６から、文書ＩＤに該当するアクセス制御リスト（ＡＣＬ）を取得する（ステップＳ２２）。そして渡されたアカウント名または所属グループリストに、指定されたアクセス種別におけるアクセス権限があるか確認し（ステップＳ２３）、権限がない場合は、権限がないことを文書アクセス処理手段１２に通知し（ステップＳ２４）、権限が有る場合は権限があることを文書アクセス処理手段１２に通知して（ステップＳ２５）、処理を終了する。
【００２９】
図８は、アクセス権ＤＢ１６に記録されたアクセス制御リスト（ＡＣＬ）の例を示す図である。アクセス権ＤＢ１６には、例えばアクセス制御リスト（ＡＣＬ）が文書ＩＤごとにファイルとして記録されている。例えば文書ＩＤが“Ｒ０１００４３９８６２４９”のＡＣＬは、“Ｒ０１００４３９８６２４９.ａｃｌ”というファイル名で記録される。そしてユーザ名／グループ名毎にアクセス権の種類（ここではｒｅａｄ，ｗｒｉｔｅ，ｅｘｅｃｕｔｅ，及びｏｗｎｅｒ）が設定される。
【００３０】
アクセス権の更新処理に関しては後で詳しく説明するが、アクセス権ＤＢ１６にはＡＣＬファイルとともに以下のようなファイルが保存されている。まず、ＡＣＬファイルの設定を変更するたびに履歴ファイルが保存される。履歴ファイルとしては、例えば、“Ｒ０１００４３９８６２４９.ａｃｌ.１”、“Ｒ０１００４３９８６２４９.ａｃｌ.２”のごとくのファイル名で記録される。また、設定の変更に関する変更履歴を管理するファイル（ＡＣＬヒストリファイル）も記録する。ＡＣＬヒストリファイルは、例えば、“Ｒ０１００４３９８６２４９.ａｃｌ.ｈｉｓｔｏｒｙ”のごとくのファイル名で記録される。
【００３１】
図９は、ＡＣＬヒストリファイルの例を示す図である。ＡＣＬヒストリファイルの内容としては、図９に示すように、過去のＡＣＬファイル名、変更日時（履歴データの作成日時）、及びハッシュ値が設定されている。ハッシュ値は、対応する過去のＡＣＬファイル（例えば、“Ｒ０１００４３９８６２４９.ａｃｌ.１”）に対するハッシュ値である。ハッシュ値の計算には例えばＳＨＡ−１などのアルゴリズムを使用する。
【００３２】
ＡＣＬヒストリファイルについては、メッセージ認証子である改ざん検知コード（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ： ＭＡＣ）が計算され、改ざん検知コードファイルとして記録される。改ざん検知コードファイルは、例えば“Ｒ０１００４３９８６２４９.ａｃｌ.ｈｉｓｔｏｒｙ.ｍａｃ”というファイル名で記録される。また上記ＭＡＣは、ＳＨＡ−１とＴｒｉｐｌｅ ＤＥＳ（米国商務省標準局が交付したデータ暗号化規格）を組み合わせるなどして計算する。
【００３３】
上記のような電子文書管理システムに本発明によるアクセス制御履歴保証方法を適用したときの実施の形態を説明する。まず電子文書に対してアクセス権の設定（変更）を行う処理について説明する。図１０は、本発明が適用される電子文書管理システムにおけるアクセス権設定に係わる構成例について説明するための図である。
【００３４】
電子文書管理システム１０’は、ユーザからのアクセス権設定要求を受け取ると、上述したごとくの通常の文書へのアクセス要求と同じようにユーザ認証手段１１によりユーザの認証が行われ、その後アクセス権設定手段１７により、要求されたアクセス権の設定を行う。アクセス権設定手段１７は、要求してきたユーザが対象文書のアクセス権設定の権限をもっているかどうかを確認する。
【００３５】
図１１は、アクセス権設定要求データの一例を示す図である。電子文書管理システムに入力するアクセス権設定要求データには、アカウント名，パスワード、文書ＩＤ，及びアクセス種別を示すデータが含まれる。これらデータは、例えば、図１１に示すごとくのものである。図１１の例は、文書Ｒ０１００４３９８６２４９にｈａｎａｋｏの書き込み権限を追加する要求を示すものである。
【００３６】
図１２及び図１３は、アクセス権設定手段１７の処理の一例を説明するためのフローチャートである。アクセス権設定手段１７は、アカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別（アクセス権設定種別）のデータをユーザ認証手段１１から受け取った際（ステップＳ３１）、それらアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別（アクセス権設定種別）のデータをアクセス権検証手段１３に渡す（ステップＳ３２）。アクセス権検証手段１３でアクセス権があるかどうかを検証し（ステップＳ３３）、検証結果をアクセス権設定手段１７に返す。例えば、ＡＣＬにｏｗｎｅｒ権限がついていればアクセス権があると判断できる。アクセス権設定手段１７は、アクセス権がなければエラーで処理を終了する（ステップＳ５３）。
【００３７】
またアクセス権がある場合、アクセス権設定手段１７では、アクセス権ＤＢ１６から、文書ＩＤで指定された電子文書に該当するＡＣＬヒストリファイルを読み出し（ステップＳ３４）、そのＡＣＬヒストリファイルに該当する改ざん検知コードファイルから改ざん検知コード（ＭＡＣ）を読み出す（ステップＳ３５）。そしてＡＣＬヒストリファイルの正当性をＭＡＣで検証し（ステップＳ３６）、ＡＣＬヒストリファイルが改ざんされているかどうかを判別する（ステップＳ３７）。
【００３８】
上記ステップＳ３７でＡＣＬヒストリが改ざんされていればエラーで処理を終了し（ステップＳ５３）、ＡＣＬヒストリが改ざんされていなければ、ＡＣＬファイルを読み出し（ステップＳ３８）、ＡＣＬファイルのハッシュ値を計算する（ステップＳ３９）。そして計算したハッシュ値と、ＡＣＬヒストリファイルの中の最新エントリに記録されているハッシュ値とを比較し（ステップＳ４０）、ハッシュ値が一致するかどうかを判別する（ステップＳ４１）。ここでハッシュ値が一致しない場合はＡＣＬファイルが改ざんされていると見なされるため、エラーで処理を終了する（ステップＳ５３）。
【００３９】
上記ステップＳ４１でハッシュ値が一致すれば、次いでＡＣＬファイルに要求されたアクセス権を設定し（ステップＳ４２）、新しくなったＡＣＬファイルのハッシュ値を計算して（ステップＳ４３）、ＡＣＬファイルを上書き保存する（ステップＳ４４）。次いでＡＣＬヒストリファイルの中の最新エントリ番号を取得し（ステップＳ４５）、ＡＣＬファイルをコピーしてファイル名の末尾に最新エントリ番号をつけ（ステップＳ４６）、さらに現在日時をＯＳから取得する（ステップＳ４７）。そして読み出したＡＣＬヒストリファイルの中に新しいエントリ（ＡＣＬファイル名，日時，新しいハッシュ値）を加え（ステップＳ４８）、エントリを加えた後のＡＣＬヒストリファイルに対してＭＡＣを計算する（ステップＳ４９）。そして新しいＡＣＬヒストリファイルを保存し（ステップＳ５０）、新しいＭＡＣをＡＣＬヒストリファイルとともに保存して（ステップＳ５１）、正常に処理を終了する（ステップＳ５２）。
【００４０】
図１４は、アクセス権設定処理前のＡＣＬファイルの例を示す図で、図１５はアクセス権の設定処理後のＡＣＬファイルの例を示す図である。アクセス権設定処理前のＡＣＬファイルが図１４に示すごとくであり、先のアクセス権設定要求の例を適用すると、その設定処理後のＡＣＬファイルは図１５に示すようになる。
【００４１】
ＭＡＣの生成方法は、対象データのハッシュ値を例えばＳＨＡ−１のアルゴリズムで計算し、そのハッシュ値を例えばＴｒｉｐｌｅ ＤＥＳのアルゴリズムで暗号化する。暗号化に使う鍵は、アクセス権設定手段１７の内部に秘密に保持している鍵（例えばプログラムにハードコーディングされている鍵や、ＩＣチップに埋め込まれている鍵など）を使用する。
【００４２】
上記のようにＭＡＣをつけておけば、ＡＣＬヒストリが改ざんされていないことを確認しながらＡＣＬの更新処理を行うことができるが、ＡＣＬヒストリが改ざんされていないことを他人（例えばシステム監査者）に示すことが難しい可能性がある。例えば、ＡＣＬヒストリファイルをシステム監査者に見せても、システム監査者はＭＡＣの生成に使用した秘密の鍵を知らないため、それが改ざんされていないことを確認することはできない。
【００４３】
図１６ないし図１８は、アクセス権設定手段１７の処理の他の例を説明するためのフローチャートである。以下に示す実施例によれば、上記のごとくのシステム監査者でもＡＣＬヒストリファイルが正しいかどうかを確認することができる。まずアクセス権設定手段１７は、アカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別（アクセス権設定種別）のデータをユーザ認証手段１１から受け取った際（ステップＳ６１）、それらアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別（アクセス権設定種別）のデータをアクセス権検証手段１３に渡す（ステップＳ６２）。アクセス権検証手段１３でアクセス権があるかどうかを検証し（ステップＳ６３）、検証結果をアクセス権設定手段１７に返す。例えば、ＡＣＬにｏｗｎｅｒ権限がついていればアクセス権があると判断できる。アクセス権設定手段１７は、アクセス権がなければエラーで処理を終了する（ステップＳ８５）。
【００４４】
またアクセス権がある場合、アクセス権設定手段１７は、アクセス権ＤＢ１６から、文書ＩＤで指定された電子文書に該当するＡＣＬヒストリファイルを読み出し（ステップＳ６４）、そのＡＣＬヒストリファイルに該当する改ざん検知コードファイルから改ざん検知コード（ＭＡＣ）を読み出す（ステップＳ６５）。そしてＡＣＬヒストリファイルの正当性をＭＡＣで検証し（ステップＳ６６）、ＡＣＬヒストリファイルが改ざんされているかどうかを判別する（ステップＳ６７）。
【００４５】
上記ステップＳ６７でＡＣＬヒストリが改ざんされていればエラーで処理を終了し（ステップＳ８５）、改ざんされていなければ、ＡＣＬファイルを読み出し（ステップＳ６８）、ＡＣＬファイルのハッシュ値を計算する（ステップＳ６９）。そして計算したハッシュ値と、ＡＣＬヒストリファイルの中の最新エントリに記録されているハッシュ値とを比較し（ステップＳ７０）、ハッシュ値が一致するかどうかを判別する（ステップＳ７１）。ここでハッシュ値が一致しない場合はＡＣＬファイルが改ざんされていると見なされるため、エラーで処理を終了する（ステップＳ８５）。
【００４６】
上記ステップＳ７１でハッシュ値が一致すれば、次いでＡＣＬファイルに要求されたアクセス権を設定し（ステップＳ７２）、新しくなったＡＣＬファイルのハッシュ値を計算して（ステップＳ７３）、ＡＣＬファイルを上書き保存する（ステップＳ７４）。次いでＡＣＬヒストリファイルの中の最新エントリ番号を取得し（ステップＳ７５）、ＡＣＬファイルをコピーしてファイル名の末尾に最新エントリ番号をつけ（ステップＳ７６）、さらに現在日時をＯＳから取得する（ステップＳ７７）。
【００４７】
そして読み出したＡＣＬヒストリファイルの中に新しいエントリ（ＡＣＬファイル名，日時，新しいハッシュ値）を加え（ステップＳ７８）、エントリを加えた後のＡＣＬヒストリファイルに対してＭＡＣを計算し（ステップＳ７９）、エントリを加えたＡＣＬヒストリファイルに対して電子署名を計算する（ステップＳ８０）。そして新しいＡＣＬヒストリファイルを保存し（ステップＳ８１）、新しいＭＡＣをＡＣＬヒストリファイルとともに保存して（ステップＳ８２）、さらに新しい電子署名をＡＣＬヒストリファイルとともに保存して（ステップＳ８３）、正常に処理を終了する（ステップＳ８４）。
【００４８】
上記の処理において、ＭＡＣの生成・検証の処理をすべて電子署名の生成・検証に変更しても良いが、電子署名の生成・検証はＭＡＣの生成・検証に比べて非常に時間がかかるため、パフォーマンスに影響が出る可能性がある。そのため、上記の実施例は、基本的にＭＡＣを使ってＡＣＬヒストリファイルの正当性の検証を行いつつ、後でシステム監査者も正当性を検証できるように最後に電子署名も同時に付与している、という仕組みを有するものである。このような仕組みであればパフォーマンスを落とすことなく、システム監査者でも電子署名に使ったプライベートキーに対応するパブリックキーを手に入れれば正当性検証を可能にすることができる。
【００４９】
電子署名は、例えば、“Ｒ０１００４３９８６２４９.ａｃｌ.ｈｉｓｔｏｒｙ.ｓｉｇｎ”というファイル名で記録される。また電子署名は、ＳＨＡ−１とＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ ｓｃｈｅｍｅ）を組み合わせるなどして計算し、例えばＰＫＣＳ（ｐｕｂｌｉｃ−ｋｅｙ ｃｒｙｐｔｏｓｙｓｔｅｍ）＃７のフォーマットで記録される。
【００５０】
上記のようにアクセス権の変遷を記録しておき、それを改ざんできないように保護することで、確かに文書に対してそのようなアクセス制御が行われてきた、ということを保証することができる。しかし、ＡＣＬファイルにはグループに対する権限も載っているため、グループのメンバを入れ替えられていると、一体誰にアクセス権が付与されていたのか後で分からなくなってしまう。
【００５１】
そこで、本発明ではさらに以下のアカウント設定に関する手段を提供する。図１９は、本発明が適用される電子文書管理システムにおけるアカウント設定手段に係わる構成例について説明するための図である。図２０は、電子文書管理システムが受け取るアカウント設定要求の一例を示す図で、ｙｏｉｃｈｉというアカウントをｌａｂ２グループに追加する要求の例を示す図である。
【００５２】
電子文書管理システム１０″では、ユーザからアカウント設定要求を受けると、ユーザ認証手段１１によってユーザ認証が行われ、アカウント設定手段１８がユーザ管理ＤＢ１４に対するアカウント設定処理を行う。アカウント設定手段１８は、ユーザがアカウント設定を行う権限をもっているかどうかをアクセス権検証手段１３により確認する。ここでは説明を簡単にするためにrootアカウントであればアカウント設定の権限があるものとする。
【００５３】
図２１ないし図２３は、アカウント設定手段１８の処理の例を説明するためのフローチャートである。アカウント設定手段１８は、ユーザ認証手段１１からアカウント名，所属グループリスト，パラメータ，及びアクセス種別のデータを受け取ると（ステップＳ９１）、アクセス権検証手段１３にアカウント名，所属グループリスト，パラメータ，及びアクセス種別のデータを渡す（ステップＳ９２）。アクセス権検証手段１３ではアクセス権を検証し、検証結果をアカウント設定手段１８に返す。例えば、アクセス権検証手段１３では、ｒｏｏｔであればアクセス権ありと判断する。アカウント設定手段１８では、アクセス権の検証結果においてアクセス権がなければ、エラーで処理を終了する（ステップＳ９３，Ｓ１２１）。
【００５４】
アクセス権がある場合、さらに入力したアカウント設定要求のアクセス種別がグループに対する設定要求であるかどうかを判別し（ステップＳ９４）、グループ設定要求であれば、ユーザ管理ＤＢ１４のグループ管理ファイルからグループリストを読み出し（ステップＳ９５）、グループリストの改ざん検知コードファイルから改ざん検知コード（ＭＡＣ）を読み出す（ステップＳ９６）。そしてグループリストの正当性をＭＡＣで検証し（ステップＳ９７）、グループリストが改ざんされているかどうかを判別する（ステップＳ９８）。ここでグループリストが改ざんされていれば、エラーで終了を終了する（ステップＳ１２１）。
【００５５】
グループリストが改ざんされていなければ、グループリストに対して要求された設定処理を行う（ステップＳ９９）。そして現在日時をＯＳから取得し（ステップＳ１００）、設定処理を行ったグループリストのエントリに設定処理の履歴（日時，設定内容）を追加する（ステップＳ１０１）。次いで新しくなったグループリストに対してＭＡＣを計算し（ステップＳ１０２）、さらに新しくなったグループリストに対して電子署名を計算し（ステップＳ１０３）、新しいグループリストをグループ管理ファイルに保存する（ステップＳ１０４）。さらに新しいＭＡＣをグループ管理ファイルとともに保存し（ステップＳ１０５）、新しい電子署名をグループ管理ファイルとともに保存して（ステップＳ１０６）、正常に処理を終了する。
【００５６】
上記ステップＳ９４においてグループに対する設定要求ではない場合、アカウントに対する設定要求であるかどうかを判別し（ステップＳ１０７）、アカウントに対する設定でなければエラーで処理を終了し（ステップＳ１２１）、アカウントに対する設定であれば、まずユーザ管理ＤＢ１４のアカウント管理ファイルからアカウントリストを読み出し（ステップＳ１０８）、アカウントリストの改ざん検知コードファイルから改ざん検知コード（ＭＡＣ）を読み出して（ステップＳ１０９）、アカウントリストの正当性をＭＡＣで検証してアカウントリストが改ざんされているかどうかを判別する（ステップＳ１１０，Ｓ１１１）。ここでアカウントリストが改ざんされていれば、エラーで処理を終了する（ステップＳ１２１）。
【００５７】
アカウントリストが改ざんされていなければ、アカウントリストに対して要求された設定処理を行う（ステップＳ１１２）。そして現在日時をＯＳから取得し（ステップＳ１１３）、設定処理を行ったアカウントリストのエントリに設定処理の履歴（日時，設定内容）を追加する（ステップＳ１１４）。そして新しくなったアカウントリストに対してＭＡＣを計算し（ステップＳ１１５）、新しくなったアカウントリストに対して電子署名を計算して（ステップＳ１１６）、新しいアカウントリストをアカウント管理ファイルに保存する（ステップＳ１１７）。そして新しいＭＡＣをアカウント管理ファイルとともに保存し（ステップＳ１１８）、新しい電子署名をアカウント管理ファイルとともに保存して（ステップＳ１１９）、正常に終了を終了する（ステップＳ１２０）。
【００５８】
先のＡＣＬの履歴管理ではＡＣＬファイルの版を管理する方式をとった。アカウント設定手段１８でも同じようにアカウント管理ファイルやグループ管理ファイルの版管理を行うこともできるが、敢えて別の方式を示すために、版管理ではなく、アカウント設定操作の履歴をファイル内に記録する方式とした。この場合も、履歴が改ざんされていないことを保証するため、ＭＡＣを生成・検証するようにし、システム監査者が確認できるように電子署名も生成して保存している。ＭＡＣを記録するファイルは例えばａｃｃｏｕｎｔ.ｌｉｓｔ.ｍａｃやｇｒｏｕｐ.ｌｉｓｔ.ｍａｃというファイル名のファイルとして記録しておき、電子署名についてはａｃｃｏｕｎｔ.ｌｉｓｔ.ｓｉｇｎやｇｒｏｕｐ.ｌｉｓｔ.ｓｉｇｎというファイル名のファイルに記録しておけばよい。
【００５９】
上記のように、ＡＣＬの変遷とアカウント管理の変遷とがすべて記録されており、その上、その記録が改ざんされないように保護されていることにより、どのようなアクセス制御が行われてきたのかシステム監査者に証拠として提示することができる。このような機能を利用すれば、普段から適切なアクセス制御をしておくことにより、アクセス制御を適切に実施していたことを保証することができるようになる。
【００６０】
上記の実施例では、ＡＣＬの変遷を各文書に対して記録しているように記述しているが、冒頭にも少し述べたように、多くの場合は文書ごとに個別にアクセス権を設定するのではなく、例えばあるフォルダに保存されているものはすべてこのアクセス権を付与するといった形で設定されることが多い。その場合、例えば、上位フォルダと同じアクセス権を付与する下位の文書のＡＣＬファイルには、その上位フォルダのＡＣＬファイル名を記録しておく、といった方法をとればよい。
【００６１】
上記の実施例で説明したアクセス権設定手段１７、及びアカウント設定手段１８はコンピュータプログラムとして実現することができる。他のユーザ認証手段１１やアクセス権検証手段１３、文書アクセス処理手段１２と合わせることでアクセス制御が適切に実施されていたことを保証する電子文書管理のためのコンピュータプログラムとなる。そのコンピュータプログラムを例えばＦＤやＣＤ−ＲＯＭに記録することで、アクセス制御が適切に実施されていたことを保証する電子文書管理プログラム記録媒体となる。そしてその記録媒体からコンピュータプログラムを読み出してコンピュータ上で実行することで、アクセス制御が適切に行われていたことを保証する文書管理システムとなる。
【００６２】
【発明の効果】
以上の説明から明らかなように、本発明によれば、サブジェクトがオブジェクトへアクセスする際に、サブジェクトに付与されたアクセス権に応じてサブジェクトからオブジェクトへのアクセスを制御するシステムにおいて、アクセス制御が適切に実施されていたことを保証することにより、信頼性及び実用性の高いシステムを運用できるアクセス制御履歴保証方法を提供することができる。
【図面の簡単な説明】
【図１】 本発明のアクセス制御履歴保証方法を適用可能な電子文書管理システムの一例を説明するためのブロック図である。
【図２】 電子文書管理システムにおけるユーザ認証手段の処理例について説明するためのフローチャートである。
【図３】 文書アクセス要求データの一例を示す図である。
【図４】 ユーザ管理ＤＢで管理されるアカウント管理ファイルの一例を示す図である。
【図５】 ユーザ管理ＤＢに保持されるグループリストに係わるデータの一例を示す図である。
【図６】 文書アクセス処理手段の処理の一例を説明するためのフローチャートである。
【図７】 電子文書管理システムにおけるアクセス権検証手段の処理の一例を説明するためのフローチャートである。
【図８】 アクセス権ＤＢに記録されらアクセス制御リスト（ＡＣＬ）の例を示す図である。
【図９】 ＡＣＬヒストリファイルの例を示す図である。
【図１０】 本発明が適用される電子文書管理システムにおけるアクセス権設定に係わる構成例について説明するための図である。
【図１１】 アクセス権設定要求データの一例を示す図である。
【図１２】 アクセス権設定手段の処理の一例を説明するためのフローチャートである。
【図１３】 アクセス権設定手段の処理の一例を説明するための図１２に続くフローチャートである。
【図１４】 アクセス権設定処理前のＡＣＬファイルの例を示す図である。
【図１５】 アクセス権の設定処理後のＡＣＬファイルの例を示す図である。
【図１６】 アクセス権設定手段の処理の他の例を説明するためのフローチャートである。
【図１７】 アクセス権設定手段の処理の他の例を説明するための図１６に続くフローチャートである。
【図１８】 アクセス権設定手段の処理の他の例を説明するための図１７に続くフローチャートである。
【図１９】 本発明が適用される電子文書管理システムにおけるアカウント設定手段に係わる構成例について説明するための図である。
【図２０】 電子文書管理システムが受け取るアカウント設定要求の一例を示す図である。
【図２１】 アカウント設定手段の処理の例を説明するためのフローチャートである。
【図２２】 アカウント設定手段の処理の例を説明するための図２１に続くフローチャートである。
【図２３】 アカウント設定手段の処理の例を説明するための図２２に続くフローチャートである。
【符号の説明】
１０，１０’，１０″…電子文書管理システム、１１…ユーザ認証手段、１２…文書アクセス処理手段、１３…アクセス権検証手段、１４…ユーザ管理ＤＢ、１５…電子文書ＤＢ、１６…アクセス権ＤＢ、１７…アクセス権設定手段、１８…アカウント設定手段。
【発明の属する技術分野】
本発明は、アクセス制御履歴保証方法、より詳細には、ファイルに対するアクセス制御が適切に実施されていたことを保証するアクセス制御履歴保証方法に関する。
【０００２】
【従来の技術】
ＵＮＩＸ（登録商標）やＷｉｎｄｏｗｓ（登録商標）のようなオペレーティングシステム（ＯＳ）や、電子文書管理システムでは、その制御下に置かれているファイル、電子文書といったものに対して正当なユーザのみがアクセスできるようにアクセス制御を行うのが一般的である。そのようにアクセス制御されるオブジェクト（ファイル、電子文書）に対して、実際にどのようなアクセスがあったのか、不正なアクセスがなかったか、を後で調べられるようにするために、各オブジェクトに対するアクセス履歴（アクセスログ）を記録しておくのが一般的である。
【０００３】
システムの安全運用監査などを行う際には、上記のようにして記録されたアクセス履歴を参照・確認することになる。しかし、オブジェクトの個数が多くなると、各オブジェクトにどのようなアクセスがあったかを監査するのは非常に手間がかかることになり、実際には例えばサンプリング監査をすることになる。サンプリング監査を行った場合には、サンプリングの対象とならなかったオブジェクトへの不正アクセスがなかったかどうかについては、確認することができない。
【０００４】
しかし、その一方で、アクセス制御に使用された設定情報というものはそれほど頻繁に変更することはなく、また、各オブジェクトについてばらばらなアクセス制御を行うことは稀であって、例えばあるフォルダとその下位のファイルにはすべて同じアクセス権を付与する、というような運用を行うのが一般的である。
【０００５】
そのため、システムの監査を考えれば、各オブジェクトへのアクセス履歴を記録しておくよりも、適切なアクセス制御設定を実行していたことの履歴を記録しておいて、その履歴を監査するようにすればオブジェクトをサンプリングして監査するよりも、広い範囲のオブジェクトについて満遍のない監査を行うことができる。
【０００６】
【発明が解決しようとする課題】
本発明は、上述のごとき実情に鑑みてなされたもので、ファイルに対するアクセス制御が適切に実施されていたことを保証するアクセス制御履歴保証方法を提供することを目的とするものである。
【０００７】
【課題を解決するための手段】
請求項１の発明は、サブジェクトがオブジェクトへアクセスする際に、サブジェクトに付与されたアクセス権に応じて、サブジェクトからオブジェクトへのアクセスを制御するシステムに適用され、該アクセスの制御履歴を保証できるようにしたアクセス制御履歴保証方法において、前記アクセスを制御するシステムは、オブジェクトごとに設定されているサブジェクトのアクセス権の変遷の履歴を、前記システムが備えるデータベースにアクセス制御履歴データとして記録しておき、記録した該アクセス制御履歴データに対して、後で改ざん検知が可能なように処理しておくことを特徴としたものである。
【０００８】
請求項２の発明は、請求項１の発明において、前記アクセス権は、オブジェクトごとに設定されたアクセス制御リストによって指示されていることを特徴としたものである。
【０００９】
請求項３の発明は、請求項１または２の発明において、前記アクセスを制御するシステムは、前記アクセス制御履歴データの改ざんを検知するために、該アクセス制御履歴データに対してメッセージ認証子を計算して該アクセス制御履歴データとともに前記データベースに記録しておくことを特徴としたものである。
【００１０】
請求項４の発明は、請求項１または２の発明において、前記アクセスを制御するシステムは、前記アクセス制御履歴データの改ざんを検知するために、該アクセス制御履歴データに対して電子署名を計算して該アクセス制御履歴データとともに前記データベースに記録しておくことを特徴としたものである。
【００１１】
請求項５の発明は、サブジェクトがオブジェクトへアクセスする際に、サブジェクトに付与されたアクセス権に応じて、サブジェクトからオブジェクトへのアクセスを制御するシステムに適用され、該アクセスの制御履歴を保証できるようにしたアクセス制御履歴保証方法において、前記アクセスを制御するシステムは、サブジェクトを構成する要素を示すアカウントの変遷の履歴を、前記システムが備えるデータベースにアカウント構成履歴データとして、記録しておき、記録した該アカウント構成履歴データに対して、後で改ざん検知が可能なように処理しておくことを特徴としたものである。
【００１２】
請求項６の発明は、請求項５の発明において、前記サブジェクトは、システムのユーザアカウントとグループアカウントとにより示される要素によって構成されることを特徴としたものである。
【００１３】
請求項７の発明は、請求項５または６の発明において、前記アクセスを制御するシステムは、前記アカウント構成履歴データの改ざんを検知するために、アカウント構成履歴データに対してメッセージ認証子を計算して該アカウント構成履歴データとともに前記データベースに記録しておくことを特徴としたものである。
【００１４】
請求項８の発明は、請求項５または６の発明において、前記アクセスを制御するシステムは、前記アカウント構成履歴データの改ざんを検出するために、該アカウント構成履歴データに対して電子署名を計算して該アカウント構成履歴データとともに前記データベースに記録しておくことを特徴としたものである。
【００１５】
請求項９の発明は、サブジェクトがオブジェクトへアクセスする際に、サブジェクトに付与されたアクセス権に応じて、サブジェクトからオブジェクトへのアクセスを制御するシステムに適用され、該アクセスの制御履歴を保証できるようにしたアクセス制御履歴保証方法において、前記アクセスを制御するシステムは、オブジェクトごとに設定されているサブジェクトのアクセス権の変遷の履歴を、前記システムが備えるデータベースにアクセス制御履歴データとして記録しておき、記録した該アクセス制御履歴データに対して、後で改ざん検知が可能なように処理しておき、さらに前記アクセスを制御するシステムは、サブジェクトを構成する要素を示すアカウントの変遷の履歴を、前記システムが備える他のデータベースにアカウント構成履歴データとして記録しておき、記録した該アカウント構成履歴データに対して、後で改ざん検知が可能なように処理しておくことを特徴としたものである。
【００１６】
請求項１０の発明は、請求項９の発明において、前記アクセス権は、オブジェクトごとに設定されたアクセス制御リストによって指示されていることを特徴としたものである。
【００１７】
請求項１１の発明は、請求項９の発明において、サブジェクトは、システムのユーザアカウントとグループアカウントとにより示される要素によって構成されることを特徴としたものである。
【００１８】
請求項１２の発明は、請求項９ないし１１のいずれか１の発明おいて、前記アクセスを制御するシステムは、前記アクセス制御履歴データと前記アカウント構成履歴データの改ざんを検出するために、該アクセス制御履歴データと該アカウント構成履歴データそれぞれに対してメッセージ認証子を計算して該アクセス制御履歴データと該アカウント構成履歴データをそれぞれ前記データベース及び前記他のデータベースに記録しておくことを特徴としたものである。
【００１９】
【発明の実施の形態】
図１は、本発明のアクセス制御履歴保証方法を適用可能な電子文書管理システムの一例を説明するためのブロック図である。ここでは本発明の実施の形態を電子文書管理システムを例にして説明する。電子文書管理システム１０は、電子文書ＤＢ１５を内部に備え、ユーザから電子文書へのアクセスの要求が入力されると、ユーザ認証手段１１によってそのユーザの認証を行い、アクセス権検証手段１３が文書へのアクセス権の有無をチェックした上で、アクセス権がある場合に限り、文書アクセス処理手段１２によってユーザから要求されたアクセス処理を実行するシステムである。
【００２０】
図２は、図１に示すごとくの電子文書管理システムにおけるユーザ認証手段１１の処理例について説明するためのフローチャートである。以下にユーザ認証手段１１の処理例を図２のフローチャートに従って、図１を参照しながら説明する。ユーザ認証処理手段１１は、ユーザから文書アクセス要求（アカウント名，パスワード，文書ＩＤ，及びアクセス種別）を受け取った際（ステップＳ１）、アカウント名に対応するパスワードハッシュ値をユーザ管理ＤＢ１４から取得し（ステップＳ２）、さらにアクセス要求に含まれるパスワードのハッシュ値を計算する（ステップＳ３）。次いでステップＳ２で先に取り出したパスワードハッシュ値と、ステップＳ３で計算したハッシュ値とを比較する（ステップＳ４）。
【００２１】
比較した結果、上記二つのハッシュ値が一致するか判断し（ステップＳ５）、一致しなけければエラーで処理を終了する（ステップＳ９）。またハッシュ値が一致すれば、ユーザ管理ＤＢ１４から、アカウント名に対応するユーザが所属しているグループのリストを取得する（ステップＳ６）。そして文書アクセス処理手段１２にアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別のデータを渡し（ステップＳ７）、正常に処理を終了する（ステップＳ８）。上記ハッシュ値は、例えば米国標準技術局による規格であるＳＨＡ−１のようなアルゴリズムを用いて計算することができる。
【００２２】
図３は、文書アクセス要求データの一例を示す図である。電子文書管理システムに入力する文書アクセス要求は、上述のようにアカウント名，パスワード，文書ＩＤ，及びアクセス種別を示すデータが含まれる。これらデータは、例えば、図３に示すごとくのものである。
【００２３】
図４は、ユーザ管理ＤＢ１４で管理されるアカウント管理ファイルの一例を示す図である。ユーザ管理ＤＢ１４では、各アカウント毎に、図４に示すごとくの情報を管理する。図４に示すように、アカウントが抹消された場合でもアカウントのエントリが削除されるのではなく、抹消（“ｄｅｌｅｔｅ”）の日時が記録される。図４に示すように、ユーザ管理ＤＢ１４では、該ユーザ管理ＤＢ１４をのぞき見られた際にパスワードが暴露しないよう、パスワードそのものをユーザ管理ＤＢ１４に保存するのではなく、パスワードのハッシュ値を保存している。
【００２４】
図５は、ユーザ管理ＤＢ１４に保持されるグループリストに係わるデータの一例を示す図である。ユーザ管理ＤＢ１４には、上記のアカウント管理フィル以外にも、図５に示すようなグループリストが例えばｇｒｏｕｐ.ｌｉｓｔというファイル名でグループ管理ファイルとして記録されている。
【００２５】
図５において、例えば“ｔａｒｏ”が所属するグループを検索する場合、まず、メンバ情報に“ｔａｒｏ”が含まれるグループ名で且つグループが削除されていないものを検索し、さらにここで検索されたグループ名情報がメンバ情報として含まれるグループ名を検索する。このようにして、所属グループリストとして“ｌａｂ１”及び“ｌａｂ＿ａｌｌ”を得る。グループ設定履歴については後で詳しく説明する。
【００２６】
電子文書管理システム１０における文書アクセス処理手段１２は、ユーザ認証手段１１から受け取った情報（アカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別）をもとに、対象ユーザに対してアクセスが許可されているかどうか検証した上で、要求された電子文書へのアクセス処理を行う。
【００２７】
図６は、上記文書アクセス処理手段１２の処理の一例を説明するためのフローチャートである。文書アクセス処理手段１２では、まずユーザ認証手段１１からアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別のデータを受け取る（ステップＳ１１）。そしてアクセス権検証手段１３に、上記のアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別のデータを渡す（ステップＳ１２）。そしてアクセス権検証手段１３による検証結果に従ってアクセス権がなければエラーで処理を終了する（ステップＳ１３，Ｓ１７）。また上記検証結果においてアクセス権があることが検証されたならば、文書アクセス処理手段１２は、文書ＩＤで指定された電子文書に対してアクセス種別で指定されたアクセスを行い（ステップＳ１３，Ｓ１４）、処理結果をユーザに返してから（ステップＳ１５）、正常に処理を終了する（ステップＳ１６）。
【００２８】
図７は、電子文書管理システム１０におけるアクセス権検証手段１３の処理の一例を説明するためのフローチャートである。アクセス権検証手段１３では、文書アクセス処理手段１２からアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別のデータを受け取った際（ステップＳ２１）、アクセス権ＤＢ１６から、文書ＩＤに該当するアクセス制御リスト（ＡＣＬ）を取得する（ステップＳ２２）。そして渡されたアカウント名または所属グループリストに、指定されたアクセス種別におけるアクセス権限があるか確認し（ステップＳ２３）、権限がない場合は、権限がないことを文書アクセス処理手段１２に通知し（ステップＳ２４）、権限が有る場合は権限があることを文書アクセス処理手段１２に通知して（ステップＳ２５）、処理を終了する。
【００２９】
図８は、アクセス権ＤＢ１６に記録されたアクセス制御リスト（ＡＣＬ）の例を示す図である。アクセス権ＤＢ１６には、例えばアクセス制御リスト（ＡＣＬ）が文書ＩＤごとにファイルとして記録されている。例えば文書ＩＤが“Ｒ０１００４３９８６２４９”のＡＣＬは、“Ｒ０１００４３９８６２４９.ａｃｌ”というファイル名で記録される。そしてユーザ名／グループ名毎にアクセス権の種類（ここではｒｅａｄ，ｗｒｉｔｅ，ｅｘｅｃｕｔｅ，及びｏｗｎｅｒ）が設定される。
【００３０】
アクセス権の更新処理に関しては後で詳しく説明するが、アクセス権ＤＢ１６にはＡＣＬファイルとともに以下のようなファイルが保存されている。まず、ＡＣＬファイルの設定を変更するたびに履歴ファイルが保存される。履歴ファイルとしては、例えば、“Ｒ０１００４３９８６２４９.ａｃｌ.１”、“Ｒ０１００４３９８６２４９.ａｃｌ.２”のごとくのファイル名で記録される。また、設定の変更に関する変更履歴を管理するファイル（ＡＣＬヒストリファイル）も記録する。ＡＣＬヒストリファイルは、例えば、“Ｒ０１００４３９８６２４９.ａｃｌ.ｈｉｓｔｏｒｙ”のごとくのファイル名で記録される。
【００３１】
図９は、ＡＣＬヒストリファイルの例を示す図である。ＡＣＬヒストリファイルの内容としては、図９に示すように、過去のＡＣＬファイル名、変更日時（履歴データの作成日時）、及びハッシュ値が設定されている。ハッシュ値は、対応する過去のＡＣＬファイル（例えば、“Ｒ０１００４３９８６２４９.ａｃｌ.１”）に対するハッシュ値である。ハッシュ値の計算には例えばＳＨＡ−１などのアルゴリズムを使用する。
【００３２】
ＡＣＬヒストリファイルについては、メッセージ認証子である改ざん検知コード（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ： ＭＡＣ）が計算され、改ざん検知コードファイルとして記録される。改ざん検知コードファイルは、例えば“Ｒ０１００４３９８６２４９.ａｃｌ.ｈｉｓｔｏｒｙ.ｍａｃ”というファイル名で記録される。また上記ＭＡＣは、ＳＨＡ−１とＴｒｉｐｌｅ ＤＥＳ（米国商務省標準局が交付したデータ暗号化規格）を組み合わせるなどして計算する。
【００３３】
上記のような電子文書管理システムに本発明によるアクセス制御履歴保証方法を適用したときの実施の形態を説明する。まず電子文書に対してアクセス権の設定（変更）を行う処理について説明する。図１０は、本発明が適用される電子文書管理システムにおけるアクセス権設定に係わる構成例について説明するための図である。
【００３４】
電子文書管理システム１０’は、ユーザからのアクセス権設定要求を受け取ると、上述したごとくの通常の文書へのアクセス要求と同じようにユーザ認証手段１１によりユーザの認証が行われ、その後アクセス権設定手段１７により、要求されたアクセス権の設定を行う。アクセス権設定手段１７は、要求してきたユーザが対象文書のアクセス権設定の権限をもっているかどうかを確認する。
【００３５】
図１１は、アクセス権設定要求データの一例を示す図である。電子文書管理システムに入力するアクセス権設定要求データには、アカウント名，パスワード、文書ＩＤ，及びアクセス種別を示すデータが含まれる。これらデータは、例えば、図１１に示すごとくのものである。図１１の例は、文書Ｒ０１００４３９８６２４９にｈａｎａｋｏの書き込み権限を追加する要求を示すものである。
【００３６】
図１２及び図１３は、アクセス権設定手段１７の処理の一例を説明するためのフローチャートである。アクセス権設定手段１７は、アカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別（アクセス権設定種別）のデータをユーザ認証手段１１から受け取った際（ステップＳ３１）、それらアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別（アクセス権設定種別）のデータをアクセス権検証手段１３に渡す（ステップＳ３２）。アクセス権検証手段１３でアクセス権があるかどうかを検証し（ステップＳ３３）、検証結果をアクセス権設定手段１７に返す。例えば、ＡＣＬにｏｗｎｅｒ権限がついていればアクセス権があると判断できる。アクセス権設定手段１７は、アクセス権がなければエラーで処理を終了する（ステップＳ５３）。
【００３７】
またアクセス権がある場合、アクセス権設定手段１７では、アクセス権ＤＢ１６から、文書ＩＤで指定された電子文書に該当するＡＣＬヒストリファイルを読み出し（ステップＳ３４）、そのＡＣＬヒストリファイルに該当する改ざん検知コードファイルから改ざん検知コード（ＭＡＣ）を読み出す（ステップＳ３５）。そしてＡＣＬヒストリファイルの正当性をＭＡＣで検証し（ステップＳ３６）、ＡＣＬヒストリファイルが改ざんされているかどうかを判別する（ステップＳ３７）。
【００３８】
上記ステップＳ３７でＡＣＬヒストリが改ざんされていればエラーで処理を終了し（ステップＳ５３）、ＡＣＬヒストリが改ざんされていなければ、ＡＣＬファイルを読み出し（ステップＳ３８）、ＡＣＬファイルのハッシュ値を計算する（ステップＳ３９）。そして計算したハッシュ値と、ＡＣＬヒストリファイルの中の最新エントリに記録されているハッシュ値とを比較し（ステップＳ４０）、ハッシュ値が一致するかどうかを判別する（ステップＳ４１）。ここでハッシュ値が一致しない場合はＡＣＬファイルが改ざんされていると見なされるため、エラーで処理を終了する（ステップＳ５３）。
【００３９】
上記ステップＳ４１でハッシュ値が一致すれば、次いでＡＣＬファイルに要求されたアクセス権を設定し（ステップＳ４２）、新しくなったＡＣＬファイルのハッシュ値を計算して（ステップＳ４３）、ＡＣＬファイルを上書き保存する（ステップＳ４４）。次いでＡＣＬヒストリファイルの中の最新エントリ番号を取得し（ステップＳ４５）、ＡＣＬファイルをコピーしてファイル名の末尾に最新エントリ番号をつけ（ステップＳ４６）、さらに現在日時をＯＳから取得する（ステップＳ４７）。そして読み出したＡＣＬヒストリファイルの中に新しいエントリ（ＡＣＬファイル名，日時，新しいハッシュ値）を加え（ステップＳ４８）、エントリを加えた後のＡＣＬヒストリファイルに対してＭＡＣを計算する（ステップＳ４９）。そして新しいＡＣＬヒストリファイルを保存し（ステップＳ５０）、新しいＭＡＣをＡＣＬヒストリファイルとともに保存して（ステップＳ５１）、正常に処理を終了する（ステップＳ５２）。
【００４０】
図１４は、アクセス権設定処理前のＡＣＬファイルの例を示す図で、図１５はアクセス権の設定処理後のＡＣＬファイルの例を示す図である。アクセス権設定処理前のＡＣＬファイルが図１４に示すごとくであり、先のアクセス権設定要求の例を適用すると、その設定処理後のＡＣＬファイルは図１５に示すようになる。
【００４１】
ＭＡＣの生成方法は、対象データのハッシュ値を例えばＳＨＡ−１のアルゴリズムで計算し、そのハッシュ値を例えばＴｒｉｐｌｅ ＤＥＳのアルゴリズムで暗号化する。暗号化に使う鍵は、アクセス権設定手段１７の内部に秘密に保持している鍵（例えばプログラムにハードコーディングされている鍵や、ＩＣチップに埋め込まれている鍵など）を使用する。
【００４２】
上記のようにＭＡＣをつけておけば、ＡＣＬヒストリが改ざんされていないことを確認しながらＡＣＬの更新処理を行うことができるが、ＡＣＬヒストリが改ざんされていないことを他人（例えばシステム監査者）に示すことが難しい可能性がある。例えば、ＡＣＬヒストリファイルをシステム監査者に見せても、システム監査者はＭＡＣの生成に使用した秘密の鍵を知らないため、それが改ざんされていないことを確認することはできない。
【００４３】
図１６ないし図１８は、アクセス権設定手段１７の処理の他の例を説明するためのフローチャートである。以下に示す実施例によれば、上記のごとくのシステム監査者でもＡＣＬヒストリファイルが正しいかどうかを確認することができる。まずアクセス権設定手段１７は、アカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別（アクセス権設定種別）のデータをユーザ認証手段１１から受け取った際（ステップＳ６１）、それらアカウント名，所属グループリスト，文書ＩＤ，及びアクセス種別（アクセス権設定種別）のデータをアクセス権検証手段１３に渡す（ステップＳ６２）。アクセス権検証手段１３でアクセス権があるかどうかを検証し（ステップＳ６３）、検証結果をアクセス権設定手段１７に返す。例えば、ＡＣＬにｏｗｎｅｒ権限がついていればアクセス権があると判断できる。アクセス権設定手段１７は、アクセス権がなければエラーで処理を終了する（ステップＳ８５）。
【００４４】
またアクセス権がある場合、アクセス権設定手段１７は、アクセス権ＤＢ１６から、文書ＩＤで指定された電子文書に該当するＡＣＬヒストリファイルを読み出し（ステップＳ６４）、そのＡＣＬヒストリファイルに該当する改ざん検知コードファイルから改ざん検知コード（ＭＡＣ）を読み出す（ステップＳ６５）。そしてＡＣＬヒストリファイルの正当性をＭＡＣで検証し（ステップＳ６６）、ＡＣＬヒストリファイルが改ざんされているかどうかを判別する（ステップＳ６７）。
【００４５】
上記ステップＳ６７でＡＣＬヒストリが改ざんされていればエラーで処理を終了し（ステップＳ８５）、改ざんされていなければ、ＡＣＬファイルを読み出し（ステップＳ６８）、ＡＣＬファイルのハッシュ値を計算する（ステップＳ６９）。そして計算したハッシュ値と、ＡＣＬヒストリファイルの中の最新エントリに記録されているハッシュ値とを比較し（ステップＳ７０）、ハッシュ値が一致するかどうかを判別する（ステップＳ７１）。ここでハッシュ値が一致しない場合はＡＣＬファイルが改ざんされていると見なされるため、エラーで処理を終了する（ステップＳ８５）。
【００４６】
上記ステップＳ７１でハッシュ値が一致すれば、次いでＡＣＬファイルに要求されたアクセス権を設定し（ステップＳ７２）、新しくなったＡＣＬファイルのハッシュ値を計算して（ステップＳ７３）、ＡＣＬファイルを上書き保存する（ステップＳ７４）。次いでＡＣＬヒストリファイルの中の最新エントリ番号を取得し（ステップＳ７５）、ＡＣＬファイルをコピーしてファイル名の末尾に最新エントリ番号をつけ（ステップＳ７６）、さらに現在日時をＯＳから取得する（ステップＳ７７）。
【００４７】
そして読み出したＡＣＬヒストリファイルの中に新しいエントリ（ＡＣＬファイル名，日時，新しいハッシュ値）を加え（ステップＳ７８）、エントリを加えた後のＡＣＬヒストリファイルに対してＭＡＣを計算し（ステップＳ７９）、エントリを加えたＡＣＬヒストリファイルに対して電子署名を計算する（ステップＳ８０）。そして新しいＡＣＬヒストリファイルを保存し（ステップＳ８１）、新しいＭＡＣをＡＣＬヒストリファイルとともに保存して（ステップＳ８２）、さらに新しい電子署名をＡＣＬヒストリファイルとともに保存して（ステップＳ８３）、正常に処理を終了する（ステップＳ８４）。
【００４８】
上記の処理において、ＭＡＣの生成・検証の処理をすべて電子署名の生成・検証に変更しても良いが、電子署名の生成・検証はＭＡＣの生成・検証に比べて非常に時間がかかるため、パフォーマンスに影響が出る可能性がある。そのため、上記の実施例は、基本的にＭＡＣを使ってＡＣＬヒストリファイルの正当性の検証を行いつつ、後でシステム監査者も正当性を検証できるように最後に電子署名も同時に付与している、という仕組みを有するものである。このような仕組みであればパフォーマンスを落とすことなく、システム監査者でも電子署名に使ったプライベートキーに対応するパブリックキーを手に入れれば正当性検証を可能にすることができる。
【００４９】
電子署名は、例えば、“Ｒ０１００４３９８６２４９.ａｃｌ.ｈｉｓｔｏｒｙ.ｓｉｇｎ”というファイル名で記録される。また電子署名は、ＳＨＡ−１とＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ ｓｃｈｅｍｅ）を組み合わせるなどして計算し、例えばＰＫＣＳ（ｐｕｂｌｉｃ−ｋｅｙ ｃｒｙｐｔｏｓｙｓｔｅｍ）＃７のフォーマットで記録される。
【００５０】
上記のようにアクセス権の変遷を記録しておき、それを改ざんできないように保護することで、確かに文書に対してそのようなアクセス制御が行われてきた、ということを保証することができる。しかし、ＡＣＬファイルにはグループに対する権限も載っているため、グループのメンバを入れ替えられていると、一体誰にアクセス権が付与されていたのか後で分からなくなってしまう。
【００５１】
そこで、本発明ではさらに以下のアカウント設定に関する手段を提供する。図１９は、本発明が適用される電子文書管理システムにおけるアカウント設定手段に係わる構成例について説明するための図である。図２０は、電子文書管理システムが受け取るアカウント設定要求の一例を示す図で、ｙｏｉｃｈｉというアカウントをｌａｂ２グループに追加する要求の例を示す図である。
【００５２】
電子文書管理システム１０″では、ユーザからアカウント設定要求を受けると、ユーザ認証手段１１によってユーザ認証が行われ、アカウント設定手段１８がユーザ管理ＤＢ１４に対するアカウント設定処理を行う。アカウント設定手段１８は、ユーザがアカウント設定を行う権限をもっているかどうかをアクセス権検証手段１３により確認する。ここでは説明を簡単にするためにrootアカウントであればアカウント設定の権限があるものとする。
【００５３】
図２１ないし図２３は、アカウント設定手段１８の処理の例を説明するためのフローチャートである。アカウント設定手段１８は、ユーザ認証手段１１からアカウント名，所属グループリスト，パラメータ，及びアクセス種別のデータを受け取ると（ステップＳ９１）、アクセス権検証手段１３にアカウント名，所属グループリスト，パラメータ，及びアクセス種別のデータを渡す（ステップＳ９２）。アクセス権検証手段１３ではアクセス権を検証し、検証結果をアカウント設定手段１８に返す。例えば、アクセス権検証手段１３では、ｒｏｏｔであればアクセス権ありと判断する。アカウント設定手段１８では、アクセス権の検証結果においてアクセス権がなければ、エラーで処理を終了する（ステップＳ９３，Ｓ１２１）。
【００５４】
アクセス権がある場合、さらに入力したアカウント設定要求のアクセス種別がグループに対する設定要求であるかどうかを判別し（ステップＳ９４）、グループ設定要求であれば、ユーザ管理ＤＢ１４のグループ管理ファイルからグループリストを読み出し（ステップＳ９５）、グループリストの改ざん検知コードファイルから改ざん検知コード（ＭＡＣ）を読み出す（ステップＳ９６）。そしてグループリストの正当性をＭＡＣで検証し（ステップＳ９７）、グループリストが改ざんされているかどうかを判別する（ステップＳ９８）。ここでグループリストが改ざんされていれば、エラーで終了を終了する（ステップＳ１２１）。
【００５５】
グループリストが改ざんされていなければ、グループリストに対して要求された設定処理を行う（ステップＳ９９）。そして現在日時をＯＳから取得し（ステップＳ１００）、設定処理を行ったグループリストのエントリに設定処理の履歴（日時，設定内容）を追加する（ステップＳ１０１）。次いで新しくなったグループリストに対してＭＡＣを計算し（ステップＳ１０２）、さらに新しくなったグループリストに対して電子署名を計算し（ステップＳ１０３）、新しいグループリストをグループ管理ファイルに保存する（ステップＳ１０４）。さらに新しいＭＡＣをグループ管理ファイルとともに保存し（ステップＳ１０５）、新しい電子署名をグループ管理ファイルとともに保存して（ステップＳ１０６）、正常に処理を終了する。
【００５６】
上記ステップＳ９４においてグループに対する設定要求ではない場合、アカウントに対する設定要求であるかどうかを判別し（ステップＳ１０７）、アカウントに対する設定でなければエラーで処理を終了し（ステップＳ１２１）、アカウントに対する設定であれば、まずユーザ管理ＤＢ１４のアカウント管理ファイルからアカウントリストを読み出し（ステップＳ１０８）、アカウントリストの改ざん検知コードファイルから改ざん検知コード（ＭＡＣ）を読み出して（ステップＳ１０９）、アカウントリストの正当性をＭＡＣで検証してアカウントリストが改ざんされているかどうかを判別する（ステップＳ１１０，Ｓ１１１）。ここでアカウントリストが改ざんされていれば、エラーで処理を終了する（ステップＳ１２１）。
【００５７】
アカウントリストが改ざんされていなければ、アカウントリストに対して要求された設定処理を行う（ステップＳ１１２）。そして現在日時をＯＳから取得し（ステップＳ１１３）、設定処理を行ったアカウントリストのエントリに設定処理の履歴（日時，設定内容）を追加する（ステップＳ１１４）。そして新しくなったアカウントリストに対してＭＡＣを計算し（ステップＳ１１５）、新しくなったアカウントリストに対して電子署名を計算して（ステップＳ１１６）、新しいアカウントリストをアカウント管理ファイルに保存する（ステップＳ１１７）。そして新しいＭＡＣをアカウント管理ファイルとともに保存し（ステップＳ１１８）、新しい電子署名をアカウント管理ファイルとともに保存して（ステップＳ１１９）、正常に終了を終了する（ステップＳ１２０）。
【００５８】
先のＡＣＬの履歴管理ではＡＣＬファイルの版を管理する方式をとった。アカウント設定手段１８でも同じようにアカウント管理ファイルやグループ管理ファイルの版管理を行うこともできるが、敢えて別の方式を示すために、版管理ではなく、アカウント設定操作の履歴をファイル内に記録する方式とした。この場合も、履歴が改ざんされていないことを保証するため、ＭＡＣを生成・検証するようにし、システム監査者が確認できるように電子署名も生成して保存している。ＭＡＣを記録するファイルは例えばａｃｃｏｕｎｔ.ｌｉｓｔ.ｍａｃやｇｒｏｕｐ.ｌｉｓｔ.ｍａｃというファイル名のファイルとして記録しておき、電子署名についてはａｃｃｏｕｎｔ.ｌｉｓｔ.ｓｉｇｎやｇｒｏｕｐ.ｌｉｓｔ.ｓｉｇｎというファイル名のファイルに記録しておけばよい。
【００５９】
上記のように、ＡＣＬの変遷とアカウント管理の変遷とがすべて記録されており、その上、その記録が改ざんされないように保護されていることにより、どのようなアクセス制御が行われてきたのかシステム監査者に証拠として提示することができる。このような機能を利用すれば、普段から適切なアクセス制御をしておくことにより、アクセス制御を適切に実施していたことを保証することができるようになる。
【００６０】
上記の実施例では、ＡＣＬの変遷を各文書に対して記録しているように記述しているが、冒頭にも少し述べたように、多くの場合は文書ごとに個別にアクセス権を設定するのではなく、例えばあるフォルダに保存されているものはすべてこのアクセス権を付与するといった形で設定されることが多い。その場合、例えば、上位フォルダと同じアクセス権を付与する下位の文書のＡＣＬファイルには、その上位フォルダのＡＣＬファイル名を記録しておく、といった方法をとればよい。
【００６１】
上記の実施例で説明したアクセス権設定手段１７、及びアカウント設定手段１８はコンピュータプログラムとして実現することができる。他のユーザ認証手段１１やアクセス権検証手段１３、文書アクセス処理手段１２と合わせることでアクセス制御が適切に実施されていたことを保証する電子文書管理のためのコンピュータプログラムとなる。そのコンピュータプログラムを例えばＦＤやＣＤ−ＲＯＭに記録することで、アクセス制御が適切に実施されていたことを保証する電子文書管理プログラム記録媒体となる。そしてその記録媒体からコンピュータプログラムを読み出してコンピュータ上で実行することで、アクセス制御が適切に行われていたことを保証する文書管理システムとなる。
【００６２】
【発明の効果】
以上の説明から明らかなように、本発明によれば、サブジェクトがオブジェクトへアクセスする際に、サブジェクトに付与されたアクセス権に応じてサブジェクトからオブジェクトへのアクセスを制御するシステムにおいて、アクセス制御が適切に実施されていたことを保証することにより、信頼性及び実用性の高いシステムを運用できるアクセス制御履歴保証方法を提供することができる。
【図面の簡単な説明】
【図１】 本発明のアクセス制御履歴保証方法を適用可能な電子文書管理システムの一例を説明するためのブロック図である。
【図２】 電子文書管理システムにおけるユーザ認証手段の処理例について説明するためのフローチャートである。
【図３】 文書アクセス要求データの一例を示す図である。
【図４】 ユーザ管理ＤＢで管理されるアカウント管理ファイルの一例を示す図である。
【図５】 ユーザ管理ＤＢに保持されるグループリストに係わるデータの一例を示す図である。
【図６】 文書アクセス処理手段の処理の一例を説明するためのフローチャートである。
【図７】 電子文書管理システムにおけるアクセス権検証手段の処理の一例を説明するためのフローチャートである。
【図８】 アクセス権ＤＢに記録されらアクセス制御リスト（ＡＣＬ）の例を示す図である。
【図９】 ＡＣＬヒストリファイルの例を示す図である。
【図１０】 本発明が適用される電子文書管理システムにおけるアクセス権設定に係わる構成例について説明するための図である。
【図１１】 アクセス権設定要求データの一例を示す図である。
【図１２】 アクセス権設定手段の処理の一例を説明するためのフローチャートである。
【図１３】 アクセス権設定手段の処理の一例を説明するための図１２に続くフローチャートである。
【図１４】 アクセス権設定処理前のＡＣＬファイルの例を示す図である。
【図１５】 アクセス権の設定処理後のＡＣＬファイルの例を示す図である。
【図１６】 アクセス権設定手段の処理の他の例を説明するためのフローチャートである。
【図１７】 アクセス権設定手段の処理の他の例を説明するための図１６に続くフローチャートである。
【図１８】 アクセス権設定手段の処理の他の例を説明するための図１７に続くフローチャートである。
【図１９】 本発明が適用される電子文書管理システムにおけるアカウント設定手段に係わる構成例について説明するための図である。
【図２０】 電子文書管理システムが受け取るアカウント設定要求の一例を示す図である。
【図２１】 アカウント設定手段の処理の例を説明するためのフローチャートである。
【図２２】 アカウント設定手段の処理の例を説明するための図２１に続くフローチャートである。
【図２３】 アカウント設定手段の処理の例を説明するための図２２に続くフローチャートである。
【符号の説明】
１０，１０’，１０″…電子文書管理システム、１１…ユーザ認証手段、１２…文書アクセス処理手段、１３…アクセス権検証手段、１４…ユーザ管理ＤＢ、１５…電子文書ＤＢ、１６…アクセス権ＤＢ、１７…アクセス権設定手段、１８…アカウント設定手段。
Claims (12)
- サブジェクトがオブジェクトへアクセスする際に、サブジェクトに付与されたアクセス権に応じて、サブジェクトからオブジェクトへのアクセスを制御するシステムに適用され、該アクセスの制御履歴を保証できるようにしたアクセス制御履歴保証方法において、
前記アクセスを制御するシステムは、オブジェクトごとに設定されているサブジェクトのアクセス権の変遷の履歴を、前記システムが備えるデータベースにアクセス制御履歴データとして記録しておき、記録した該アクセス制御履歴データに対して、後で改ざん検知が可能なように処理しておくことを特徴とするアクセス制御履歴保証方法。 - 請求項１に記載のアクセス制御履歴保証方法において、前記アクセス権は、オブジェクトごとに設定されたアクセス制御リストによって指示されていることを特徴とするアクセス制御履歴保証方法。
- 請求項１または２に記載のアクセス制御履歴保証方法において、前記アクセスを制御するシステムは、前記アクセス制御履歴データの改ざんを検知するために、該アクセス制御履歴データに対してメッセージ認証子を計算して該アクセス制御履歴データとともに前記データベースに記録しておくことを特徴とするアクセス制御履歴保証方法。
- 請求項１または２に記載のアクセス制御履歴保証方法において、前記アクセスを制御するシステムは、前記アクセス制御履歴データの改ざんを検知するために、該アクセス制御履歴データに対して電子署名を計算して該アクセス制御履歴データとともに前記データベースに記録しておくことを特徴とするアクセス制御履歴保証方法。
- サブジェクトがオブジェクトへアクセスする際に、サブジェクトに付与されたアクセス権に応じて、サブジェクトからオブジェクトへのアクセスを制御するシステムに適用され、該アクセスの制御履歴を保証できるようにしたアクセス制御履歴保証方法において、
前記アクセスを制御するシステムは、サブジェクトを構成する要素を示すアカウントの変遷の履歴を、前記システムが備えるデータベースにアカウント構成履歴データとして、記録しておき、記録した該アカウント構成履歴データに対して、後で改ざん検知が可能なように処理しておくことを特徴とするアクセス制御履歴保証方法。 - 請求項５に記載のアクセス制御履歴保証方法おいて、前記サブジェクトは、システムのユーザアカウントとグループアカウントとにより示される要素によって構成されることを特徴とするアクセス制御履歴保証方法。
- 請求項５または６に記載のアクセス制御履歴保証方法において、前記アクセスを制御するシステムは、前記アカウント構成履歴データの改ざんを検知するために、アカウント構成履歴データに対してメッセージ認証子を計算して該アカウント構成履歴データとともに前記データベースに記録しておくことを特徴とするアクセス制御履歴保証方法。
- 請求項５または６に記載のアクセス制御履歴保証方法において、前記アクセスを制御するシステムは、前記アカウント構成履歴データの改ざんを検出するために、該アカウント構成履歴データに対して電子署名を計算して該アカウント構成履歴データとともに前記データベースに記録しておくことを特徴とするアクセス制御履歴保証方法。
- サブジェクトがオブジェクトへアクセスする際に、サブジェクトに付与されたアクセス権に応じて、サブジェクトからオブジェクトへのアクセスを制御するシステムに適用され、該アクセスの制御履歴を保証できるようにしたアクセス制御履歴保証方法において、
前記アクセスを制御するシステムは、オブジェクトごとに設定されているサブジェクトのアクセス権の変遷の履歴を、前記システムが備えるデータベースにアクセス制御履歴データとして記録しておき、記録した該アクセス制御履歴データに対して、後で改ざん検知が可能なように処理しておき、
さらに前記アクセスを制御するシステムは、サブジェクトを構成する要素を示すアカウントの変遷の履歴を、前記システムが備える他のデータベースにアカウント構成履歴データとして記録しておき、記録した該アカウント構成履歴データに対して、後で改ざん検知が可能なように処理しておくことを特徴とするアクセス制御履歴保証方法。 - 請求項９に記載のアクセス制御履歴保証方法おいて、前記アクセス権は、オブジェクトごとに設定されたアクセス制御リストによって指示されていることを特徴とするアクセス制御履歴保証方法。
- 請求項９に記載のアクセス制御履歴保証方法おいて、サブジェクトは、システムのユーザアカウントとグループアカウントとにより示される要素によって構成されることを特徴とするアクセス制御履歴保証方法。
- 請求項９ないし１１のいずれか１に記載のアクセス制御履歴保証方法おいて、前記アクセスを制御するシステムは、前記アクセス制御履歴データと前記アカウント構成履歴データの改ざんを検出するために、該アクセス制御履歴データと該アカウント構成履歴データそれぞれに対してメッセージ認証子を計算して該アクセス制御履歴データと該アカウント構成履歴データをそれぞれ前記データベース及び前記他のデータベースに記録しておくことを特徴とするアクセス制御履歴保証方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001376606A JP4152099B2 (ja) | 2001-12-11 | 2001-12-11 | アクセス制御履歴保証方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001376606A JP4152099B2 (ja) | 2001-12-11 | 2001-12-11 | アクセス制御履歴保証方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003177967A JP2003177967A (ja) | 2003-06-27 |
| JP4152099B2 true JP4152099B2 (ja) | 2008-09-17 |
Family
ID=19184760
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001376606A Expired - Fee Related JP4152099B2 (ja) | 2001-12-11 | 2001-12-11 | アクセス制御履歴保証方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4152099B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4680543B2 (ja) * | 2004-07-06 | 2011-05-11 | 三菱電機株式会社 | ログ作成システム及びログ作成方法 |
| JP2007274253A (ja) * | 2006-03-31 | 2007-10-18 | Kenwood Corp | 認証装置及び方法 |
| JP4838631B2 (ja) * | 2006-05-17 | 2011-12-14 | 富士通株式会社 | 文書アクセス管理プログラム、文書アクセス管理装置および文書アクセス管理方法 |
| JP5614073B2 (ja) * | 2010-03-29 | 2014-10-29 | ヤマハ株式会社 | 中継装置 |
| JP6040102B2 (ja) * | 2013-06-04 | 2016-12-07 | 株式会社日立製作所 | 不正情報検知方法および不正情報検知装置 |
| US10116442B2 (en) | 2015-02-20 | 2018-10-30 | Mitsubishi Electric Corporation | Data storage apparatus, data updating system, data processing method, and computer readable medium |
| US10592682B2 (en) | 2015-02-20 | 2020-03-17 | Mitsubishi Electric Corporation | Data storage apparatus, data processing method, and computer readable medium adding a user attribute of a revoked user to an embedded decryption condition while encrypted data remains in an encrypted state |
| CN110837647B (zh) * | 2018-08-16 | 2022-11-08 | 迈普通信技术股份有限公司 | 管理访问控制列表的方法及装置 |
-
2001
- 2001-12-11 JP JP2001376606A patent/JP4152099B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003177967A (ja) | 2003-06-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7526654B2 (en) | Method and system for detecting a secure state of a computer system | |
| US6694434B1 (en) | Method and apparatus for controlling program execution and program distribution | |
| JP3748155B2 (ja) | 改ざん防止／検出機能を有するファイル管理システム | |
| US6671804B1 (en) | Method and apparatus for supporting authorities in a public key infrastructure | |
| US7328341B1 (en) | Method and apparatus for protecting file system based on digital signature certificate | |
| US20030217275A1 (en) | Method and system for digital rights management and digital signatures | |
| JPH11143361A (ja) | 電子データ保管装置、保管システム、および保管方法 | |
| US20240022571A1 (en) | Blockchain folding | |
| JP2017225054A (ja) | プロファイルデータ配信制御装置、プロファイルデータ配信制御方法およびプロファイルデータ配信制御プログラム | |
| CN110826092A (zh) | 一种文件签名处理系统 | |
| KR100908100B1 (ko) | 마트로시카 구조를 갖는 암호화 이미지를 이용한 상호 동기 인증 시스템 및 방법 | |
| JP4152099B2 (ja) | アクセス制御履歴保証方法 | |
| JP2004072290A (ja) | 証明書管理環境の管理方法、プログラム及び装置 | |
| JP2000285024A (ja) | 原本性保証電子保存方法およびその方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| JP4208082B2 (ja) | データ改ざん検出方法、データ改ざん検出装置及びデータ改ざん検出プログラム | |
| JP2001337600A (ja) | 電子データ保管システム、履歴検証装置、電子データ保管方法及び記録媒体 | |
| JP2004213265A (ja) | 電子文書管理装置、文書作成者装置、文書閲覧者装置、電子文書管理方法及び電子文書管理システム | |
| JP2005506623A (ja) | データ保護方法と装置 | |
| JP2000235569A (ja) | 電子文書の管理方法及び文書管理システム | |
| JP4885168B2 (ja) | 外部メディア制御方法、システム及び装置 | |
| JP4245917B2 (ja) | ソフトウェアの不正使用防止システム | |
| JP2002229451A (ja) | データ作成日時保証システム、データ作成日時保証方法、及びデータ作成日時保証プログラム | |
| JP6464544B1 (ja) | 情報処理装置、情報処理方法、情報処理プログラム、及び情報処理システム | |
| KR100386853B1 (ko) | 전자서명 인증을 이용한 역할기반 보안커널 시스템 | |
| JP2002132145A (ja) | 認証方法、認証システム、記録媒体及び情報処理装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041029 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20071218 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080108 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080204 |
|
| 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: 20080701 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080701 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110711 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120711 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120711 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130711 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |