以下、本発明の実施の形態を図面に基づいて説明する。
本発明の一実施例に係るアクセス制御判断システムをセキュリティサーバとして適応した本システムは、例えば、図1に示すようなシステムを構成する。図1は、本発明の一実施例に係るシステム構成を示す図である。図1において、電子文書又は紙文書に対するアクセス制御を行うセキュリティサーバ200は、電子文書を管理する文書管理システム100と、コピー、ファクス、プリンタ、スキャナなど複数の異なる画像形成機能を搭載したデジタル複合機70と、電子文書をユーザの端末51に表示するドキュメントビューア53とネットワークを介して接続する。
図1において、ドキュメントビューア53は、端末51上で動作する所定のアプリケーションである。また、端末51は、ネットワークを介して、文書管理システム100に保管されている目的文書へのアクセスを行う。また、ユーザ52は、持ち込んだ紙文書をデジタル複合機70でコピー等を行う。図1中、端末51及びユーザ52は、夫々複数であっても良い。
文書管理システム100で管理され、電子文書そのものへのアクセスが制御されているような電子文書を以下、サーバドキュメント61と言う。デジタル複合機70で取り扱う紙文書を以下、ペーパードキュメント62と言う。文書管理システム100等からダウンロードして端末51のローカルストレージに保持し、ドキュメントビューア53で開いて参照する電子文書を以下、ポータブルドキュメント63と言う。
ユーザ52が端末51を用いて、文書管理システム100に接続し、サーバドキュメント61に対してアクセスすると、文書管理システム100は、ユーザ52から認証情報を取得し、ユーザ管理サーバ300へユーザ認証の問い合わせを行う。文書管理システム100は、ユーザ管理サーバ300からの認証結果に基づいて、セキュリティサーバ200へアクセス制御の問い合せを行う。文書管理システム100は、セキュリティサーバ200から通知されるアクセス制御情報に基づいて、サーバドキュメント61に対するアクセスを行う。
同様に、ユーザ52がデジタル複合機70でペーパードキュメント62を複写する際、デジタル複合機70は、ユーザ52から認証情報を取得し、ユーザ管理サーバ300へユーザ認証の問い合わせを行う。デジタル複合機70は、ユーザ管理サーバ300からの認証結果に基づいて、セキュリティサーバ200へアクセス制御の問い合せを行う。デジタル複合機70は、セキュリティサーバ200から通知されるアクセス制御情報に基づいて、ペーパードキュメント62の複写を行う。
同様に、ユーザ52が端末51にてドキュメントビューア53を起動して、ポータブルドキュメント63を表示する際、ドキュメントビューア53は、ユーザ52から認証情報を取得し、ユーザ管理サーバ300へユーザ認証の問い合わせを行う。ドキュメントビューア53は、ユーザ管理サーバ300からの認証結果に基づいて、セキュリティサーバ200へアクセス制御の問い合せを行う。ドキュメントビューア53は、セキュリティサーバ200から通知されるアクセス制御情報に基づいて、ポータブルドキュメント63の表示、又は、表示したポータブルドキュメント63の出力等を行う。
ユーザ管理サーバ300は、文書管理システム100、デジタル複合機70、又は、ドキュメントビューア53からユーザ52の認証情報を受信すると、ユーザ52毎に認証情報を含むユーザ52のユーザ情報を管理するユーザ管理テーブル310を参照して、ユーザ52の認証を行う。ユーザ管理サーバ300は、その認証結果をユーザ認証の問い合わせをした文書管理システム100、デジタル複合機70、又は、ドキュメントビューア53へ送信する。
セキュリティサーバ200は、組織におけるアクセス制御ルールが記載されたポリシーファイル240と、ユーザ52毎にユーザ権限を管理するユーザ権限管理レベルテーブル250と、ドキュメント毎にそのプロファイルを管理するドキュメントプロファイル260と、ゾーン毎にアクセス制御を管理するゾーン管理テーブル270と、印刷毎に印刷に関する情報を管理するプリントプロファイル管理テーブル280とを有する。セキュリティサーバ200は、ポリシーファイル240とこれらテーブル250から280を用いて、文書管理システム100、デジタル複合機70、及び、ドキュメントビューア53からのアクセス制御の問い合わせに応じる。
ポリシーファイル240には「関係者のみアクセス許可」などの規定ができるが、どの文書については誰が関係者なのか、その関係を管理できなければならない。そういったポリシーを補足するテーブルは、ポリシーとは別にセキュリティサーバ内で管理する。ポリシーにそのような関係者を記載してしまうと汎用性に欠けたポリシーになってしまうためである。つまり、組織の企業秘密管理規則のような「ルール」として規定できる部分のみポリシーとして規定し、ドキュメントごと、ユーザごとに様々に設定すべきものはテーブルで管理する。そして、その「ルール」は組織によって様々に異なるため、ポリシーファイル240という形にすることによって、入れ替え可能となる。
以下、サーバドキュメント61、ペーパードキュメント62、及びポータブルドキュメント63を総称してドキュメント60(図2)と言う。
端末51及びユーザ52を含め、ドキュメント60に対してアクセスするものをイニシエータ50と言う。
また、文書管理システム100、デジタル複合機70、ドキュメントビューア53等を総称してアプリシステム400と言う。
システム1000では、セキュリティサーバ200とユーザ管理サーバ300とを分けて構成しているが、1つのサーバでセキュリティサーバ200の機能とユーザ管理サーバ300の機能とを有するように構成しても良い。
アクセス制御の概要を、ISO/IEC 10181-3に従って記述したアクセス制御モデルを示す図2を参照しつつ説明する。図2は、アクセス制御モデルを示す図である。
図2において、アプリシステム400は、イニシエータ50からドキュメント60に対してアクセスを要求されると、ユーザ認証後にアクセスを許可するか否かをセキュリティサーバ200に許可の判断を要求する。特に、ユーザ認証を必要としない場合には、anonymous(匿名)ユーザ又はguest(ゲスト)ユーザとしてアクセス許可を問い合わせるようにしても良い。
セキュリティサーバは、そのユーザがそのドキュメントにアクセスする権限があるかどうかを内部に保持しているセキュリティファイル240に記述されるアクセス制御ルール(ポリシー)に従って判断し、許可されているか、禁止されているか、許可されている場合に満たさなければならない要件は何か、を判断結果としてアプリシステムに返す。
アプリシステム400は、判断結果を受け取り、許可されている場合にはユーザから要求されたアクセスを処理する。その際、判断結果として要件が指定されていれば、その要件を満たすようにドキュメント60を処理する。禁止されている、要件が満たせない等の場合にはアクセスを拒否する。
次に、セキュリティサーバ200のハードウェア構成及び機能構成について説明する。図3は、本発明の一実施例に係るセキュリティサーバのハードウェア構成を示す図である。
図3において、セキュリティサーバ200は、サーバコンピュータであって、CPU(中央処理装置)41と、メモリユニット42と、表示ユニット43と、入力ユニット44と、通信ユニット45と、記憶装置46とを有し、各ユニット41から46はシステムバスB2に接続される。
CPU41は、メモリユニット42に格納されたプログラムに従ってストレージ200を制御する。メモリユニット42は、RAM(Random Access Memory)及びROM(Read-Only Memory)等にて構成され、CPU41にて実行されるプログラム、CPU41での処理に必要なデータ、CPU41での処理にて得られたデータ等を格納する。また、メモリユニット42の一部の領域が、CPU41での処理に利用されるワークエリアとして割り付けられている。
表示ユニット43は、CPU41の制御のもとに必要な各種情報を表示する。通信ユニット45は、アプリシステム400と例えばLAN(Local Area Network)等で接続される場合に、アプリシステム400との間で通信制御をするためのユニットである。記憶装置46は、例えば、ハードディスクユニットにて構成され、ポリシーファイル240と、ユーザ権限レベルテーブル250、ドキュメントプロファイル管理テーブル260、ゾーン管理テーブル270、プリントプロファイル管理テーブル290等の管理テーブルとを保存する。
セキュリティサーバ200を制御するプログラムは、予め、記憶装置46にインストールされている。
図4は、セキュリティサーバの機能構成を示す図である。図4において、セキュリティサーバ200は、主に、アプリシステム400から提供される情報等を企業のセキュリティポリシーに対応させるために抽象化を行う抽象化処理部231と、抽象化処理部231によって抽象化された情報に基づいてアクセス制御を判断するポリシーベースアクセス制御判断部241とを有する。
抽象化処理部231は、更に、ユーザ権限レベルマッピング部232と、ユーザ区分マッピング233と、ゾーンマッピング部234と、ドキュメントセキュリティ属性マッピング部235とを有する。
抽象化処理部231において、アプリシステム400からユーザ識別情報と、アクセス種別情報と、ドキュメント識別情報と、コンテキスト情報とを受信すると、ユーザ権限レベルマッピング部232は、ユーザ識別情報に基づいてユーザ権限レベルテーブル250を参照して抽象化した権限レベルを取得し(1)、ユーザ区分マッピング233は、ユーザ識別情報に基づいてドキュメントプロファイル管理テーブル260を参照して抽象化した関係者又は非限定を示す関係者区分を取得し(2)、アクセス種別情報はそのままとし(3)、ゾーンマッピング部234は、コンテキスト情報に基づいてドキュメントプロファイル管理テーブル260とゾーン管理テーブル270とを参照して抽象化したゾーン内又はゾーン外を示すゾーン区分を取得し(4)、ドキュメントセキュリティ属性マッピング部235は、ドキュメント識別情報に基づいてドキュメントプロファイル管理テーブル260とプリントプロファイル管理テーブル280とを参照して抽象化した機密レベルと文書カテゴリとを取得する(5)。
上記において、コンテキスト情報にて時間帯が設定されるように構成し、所定時間内又は所定時間外を示す時間区分を取得するようにしても良い。
マッピング部232から235の夫々を1つの抽象化処理部として構成しても良い。この場合、1つの抽象化処理部は、1つ以上の管理テーブルを参照する構成となる。
或いは、権限レベルと関係者区分とをユーザセキュリティ属性、機密レベルと文書カテゴリとをドキュメントセキュリティ属性、そして、ゾーン区分をアクセス環境属性等の3種類の属性に分類することができるため、属性毎に抽象化処理部を構成するようにしても良い。この場合、抽象化処理部は、1つ以上のマッピング処理部を有し、各マッピング処理部は、1つ以上のテーブルを参照する構成となる。
ポリシーベースアクセス制御判断部241は、抽象化処理部231によって抽象化された情報をパラメータとして受信し、ポリシーファイル240に記載されたアクセス制御ルール(ポリシー)に従ってアクセス制御を判断する。ポリシーファイル240は、外部から設定可能である。従って、企業のセキュリティポリシーに応じて変更が容易となる。
本実施例では、抽象化処理部231とポリシーベースアクセス制御判断部241との2段階による処理によって、汎用的なセキュリティポリシーに従いながら、また、セキュリティポリシーの変更にも柔軟に対応しつつアクセス制御判断を行うことができる。
また、抽象化処理部231を備えることによって、セキュリティポリシーの変更によって、アプリシステム400が提供する情報の形式を変更する必要がない。セキュリティポリシーの変更に応じたアプリシステム400側のソフトウェアを変更する必要がないため、メンテナンスが容易となる。
各ドキュメントに対してACL(Access Control List)というものを管理して、どのユーザにはどのようなアクセスを許可或いは禁止する、というアクセス制御を行うことは可能である。そして、そのようなACLをセキュリティポリシーと呼んでいる従来システムもある(米国特許第6、289、450号)。しかしながら、従来システムでは、ドキュメント毎にポリシーを設定してしまっているようなもので、「マル秘は関係者のみアクセス可能」、いうような「組織」の企業秘密管理規則(ポリシー)通りに適用されているかどうかが分からないという問題がある。
本発明に係るアクセス制御を判断するセキュリティサーバ200は、アクセス制御のための汎用的な判断ルールと、各ドキュメントの詳細なセキュリティ設定とを分離して、ドキュメントやユーザの属性を抽象的なセキュリティ属性にマッピングした上でアクセス判断をする。また、その汎用的な判断ルールをポリシーファイルとして記述できるようにすることでルールが固定されているのではなく入れ替えが可能である。
判断ルールをソフトウェアのロジックとしてプログラミングしている例は他にもあるであろうが、その判断ルールを組織のセキュリティポリシーに応じて様々に定義して設定できるようにしている例はない。
セキュリティサーバ200によって管理されるテーブルのデータ構造について説明する。
図5は、ユーザ権限レベルテーブルのデータ構造を示す図である。図5において、ユーザ権限レベルテーブル250のデータ構造251は、「UserMapList{userMap[] userMap;};」を示すコード252により、ユーザ毎にユーザの権限を示すuserMapを配列によって管理して複数のユーザを管理するUserMapListで構成される。
このuserMapは、「String principalId;」を示すコード253−1により文字列で示されるユーザID又はグループIDと、「String entryType;」を示すコード253−2によりユーザ又はグループ等の文字列で示されるエントリのタイプと、「String leveleId;」を示すコード253−3により文字列で示される権限レベルとで構成される。
アプリシステム400を利用するユーザ52毎にuserMapのエントリをUserMapListに作成して、ユーザ52を登録する。
図6は、ドキュメントプロファイル管理テーブルのデータ構造を示す図である。図6において、ドキュメントプロファイル管理テーブル260のデータ構造261は、「DocProfileTable{DocProfile[] docProfiles;};」を示すコード262により、電子文書毎にその電子文書に対するセキュリティポリシーを示すdocProfileを配列によって管理して複数の電子文書を管理するDocProfileTableで構成される。
このdocProfileは、「String docId;」を示すコード263−1により文字列で示される電子文書と、「String DocCategory;」を示すコード263−2により文字列で示される文書カテゴリと、「String docLevel;」を示すコード263−3により文字列で示される機密レベルと、「String[] relatedPersons;」を示すコード263−4により文字列で示される関係者の配列によって構成される複数の関係者のリストと、「String[] zones;」を示すコード263−5により文字列で示されるゾーンIDの配列によって構成される複数のゾーンIDのリストと、「Date nondisclosure;」を示すコード263−6により日付で示される秘密保持期間と、「Date retention;」を示すコード263−7により日付で示される保存期限と、「Date validity;」を示すコード263−8により日付で示される有効期限とで構成される。
アクセス制御する電子文書毎にDocProfileのエントリをDocProfileTableに作成して、電子文書を登録する。文書IDは、電子文書毎に一意に示される識別情報である。文書カテゴリ及び機密レベルはセキュリティポリシーによって使用される文書カテゴリ及び機密レベルの識別情報を指定する。
関係者リストには、その電子文書の関係者のユーザID又はグループIDが列挙される。ゾーンには、その電子文書へのアクセスが許可されるゾーンを特定するゾーンIDのリストが指定される。
図7は、ゾーン管理テーブルのデータ構造を示す図である。図7において、ゾーン管理テーブル270のデータ構造271は、「ZoneInfo Table{ZoneInfo[] zones};」を示すコード272により、ゾーン毎にゾーンを特定する情報を示すZoneInfoを配列によって管理して複数のゾーンを管理するZoneInfoTableで構成される。
このZoneInfoは、「String id;」を示すコード273−1により文字列で示されるゾーンIDと、「String name;」を示すコード273−2により文字列で示されるゾーン名と、「AddressInfo[] addresses;」を示すコード273−3によりAddressInfo[]の配列によって示されるゾーンのアドレスとで構成される。
コード273−3によって記述されるAddressInfoのデータ構造は、「String address;」を示すコード275−1により文字列で示されるIPアドレス又はMACアドレスと、「String addressType;」を示すコード275−2により文字列で示される「IP」又は「MAC」と、「String netmask;」を示すコード275−3によりIPアドレスの場合に「255.255.255.0」等の文字列で示されるサブネットマスクとで構成される。
ゾーン管理テーブル270は、アクセスを許可するゾーンをアドレスのリストによって管理するテーブルである。一つのゾーンIDに対して複数のIPアドレス又はMACアドレスを列挙して割り当てて管理する。
図8は、プリントプロファイル管理テーブルのデータ構造を示す図である。図8において、プリントプロファイル管理テーブル280のデータ構造281は、「PrintProfileTable{PrintProfile[] printprofiles;};」を示すコード281により、プリント毎にプリントに関するプロファイルを示すPrintProfileを配列によって管理して複数のプリントプロファイルを管理するPrintProfileTableで構成される。
PrintProfileは、「String printId;」を示すコード283−1により文字列で示されるプリントIDと、「String docId;」を示すコード283−2により文字列で示される電子文書の文書IDと、「Date printedDate;」を示すコード283−3により日付で示されるプリント日時と、「String printedUserId;」を示すコード283−4により文字列で示されるプリントユーザIDと、「String printedUserName;」を示す283−5により文字列で示されるプリントユーザ名とで構成される。
アクセス制御されている電子文書がプリントされる毎に、PrintProfileのエントリをPrintProfileTableに作成することによって登録する。プリントIDは、プリント毎に一意に特定される識別情報である。文書IDは、プリントした文書の文書IDである。
以下に具体的なアクセス制御のシーケンスを説明する。文書管理システム100、デジタル複合機70、ドキュメントビューア53の夫々について説明する。
[文書管理システムでのアクセス制御]
文書管理システム100でのアクセス制御について、図9を参照しつつ図10で説明する。
図9は、文書管理システムでのアクセス制御シーケンスを示す図である。図10は、文書管理システムでのアクセス制御処理を説明するためのフローチャート図である。図9及び図10中、図9に示すアクセス制御シーケンスにおける各処理と、図10の各処理の説明と同一符号によって対応付けられる。
図9及び図10において、文書管理システム100は、端末51からユーザ52のログインの要求と共に、ユーザIDとパスワードとを受け取る(S1001)。
文書管理システム100は、受け取ったユーザIDとパスワードとをユーザ管理サーバ300に送信して認証要求を行う(S1002)。ユーザ管理サーバ300は、受け取ったユーザIDとパスワードとで認証処理を行う(S1003)。ユーザ管理サーバ300は、認証の成功又は失敗を示す認証結果情報を文書管理システム100に返す(S1004)。認証結果情報では、ユーザを識別するユーザ識別情報と、認証の成功又は失敗を示す情報とが含まれる。
文書管理システム100は、認証結果情報に応じた処理を行う(S1005)。認証結果情報が認証の成功を示す場合、文書管理システム100は、ユーザ管理サーバ300から受け取った認証結果情報を端末51へ送信し、S1006へ進む。一方、認証結果情報が認証の失敗を示す場合、文書管理システム100は、アクセス制御処理を終了する。
端末51は、文書管理システム100に保管されているサーバドキュメント61に対する文書読込要求を文書IDを指定することによって、文書管理システム100に対して行う(S1006)。
文書管理システム100は、そのユーザ52の認証結果情報とサーバドキュメント61の文書ID、アクセス種別、クライアントのコンテキスト情報をセキュリティサーバ200に送信して、サーバドキュメント61に対するアクセス制御を問い合わせる(S1007)。アクセス種別には、例えば、文書読込要求に応じた読込アクセスが指定される。
セキュリティサーバ200は、受け取った情報に基づいてアクセスを許可するか否かを判断する(S1008)。
セキュリティサーバ200は、判断結果を文書管理システム100に返す(S1009)。文書管理システム100は、セキュリティサーバ200から受信した判断結果に応じた処理を行う(S1009)。判断結果が「許可」を示す場合、文書管理システム100は、判断結果で指定される要件を処理し、S1011へ進む。一方、判断結果が「禁止」を示す場合、アクセスは禁止され、アクセス制御処理を終了する。
文書管理システム100は、端末51から要求されたアクセス要求に応じた処理を行い、サーバドキュメント61を端末51に送信し、アクセス制御処理を正常に終了する(S1011)。
S1002でのユーザ認証の問い合わせをセキュリティサーバ200を経由して行っても良い。ユーザ52を認証する方法は、ユーザIDとパスワードとによって認証する方法に限定されるものではない。より高度なバイオメトリック認証、又は、スマートカードを用いたチャレンジ・レスポンス認証等を適用しても良い。
次に、ユーザ管理サーバ300で行われる認証処理について図11で説明する。図11は、ユーザ管理サーバでの認証処理を説明する図である。図11において、ユーザ管理サーバ300は、文書管理システム100から受け取ったユーザIDとパスワードとをユーザ管理310と照合してユーザ52に対する認証を行う(L0011)。
ユーザ52の認証が成功したか否かを判断する(L0012)。ユーザ52の認証が成功した場合、ユーザ管理サーバ300は、そのユーザ52が所属しているグループIDのリストを取得して(L0013)、ユーザIDと、ユーザ名と、所属するグループIDのリストとによって認証結果情報を作成する(L0014)。認証結果情報には、ユーザを識別するユーザ識別情報と、認証の成功を示す情報とが含まれる。
ユーザ管理サーバ300は、作成した認証結果情報を文書管理システム100へ返し(L0015)、ユーザ52の認証が成功した場合の処理を終了する(L0016)。そして、認証処理を終了する(L0020)。
一方、ユーザ52の認証が失敗した場合(L0017)、ユーザ管理サーバ300は、認証の失敗を示す認証結果情報を作成し文書管理システム100へ返し(L0018)、ユーザ52の認証が失敗した場合の処理を終了すると共に(L0019)、認証処理を終了する(L0020)。
図12は、認証結果情報のデータ構造を示す図である。図12において、認証結果情報のデータ構造501は、例えば、構造体AuthInfoで定義され、「String userId;」を示すコード502−1により文字列で示されるユーザIDと、「String username;」を示すコード502−2により文字列で示されるユーザ名と、「String[] groups;」を示すコード502−3により文字列で示されるユーザ52が所属するグループのグループIDの配列によって構成される複数のグループIDのリストとで構成される。
次に、S1008でのセキュリティサーバ200によって行われる許可処理について図13、図14及び図15で説明する。図13、図14及び図15は、文書管理システムからの問い合わせに応じたセキュリティサーバでの許可処理を説明する図である。
図13、図14及び図15では、端末51で文書管理システム100のサーバドキュメント61を読み込むオペレーションがユーザ52によって行われたことによって、端末51から文書読込要求が文書管理システム100へ送信された場合の処理を例示している。端末51での他のオペレーションとして、例えば、プロパティ参照、オリジナル参照、改訂、削除、保存等があり、夫々、プロパティ参照要求、オリジナル参照要求、改訂要求、削除要求、保存要求等として文書管理システム100からセキュリティサーバ100へ送信される。
オリジナル参照のオペレーションは、文書管理システム100に管理されているオリジナルのサーバドキュメント61を取得するアクセスである。また、例示される文書読込のオペレーションは、オリジナルのサーバドキュメント61を特別なドキュメントビューア53でしか開くことができないように変換したサーバドキュメント61を取得するアクセスである。
また、夫々の要求に対するセキュリティサーバ100での許可処理は同様である。
図13において、セキュリティサーバ200は、認証結果情報、文書ID、アクセス種別、コンテキスト情報を判断要求をした文書管理システム100から受け取る(L0031)。例えば、アクセス種別には、「サーバドキュメントに対する文書読込」が指定される。アクセス種別によって、ドキュメント60の種別(つまり、サーバドキュメント61)と、オペレーションの種別(つまり、文書読込)とが特定される。
セキュリティサーバ200は、文書管理システム100から受け取った文書ID(docid)に該当するドキュメントプロファイル(docProfile)をドキュメントプロファイル管理テーブル260から取得する(L0032)。
セキュリティサーバ200は、ドキュメントプロファイル(docProfile)を参照して文書カテゴリ(docCategory)と機密レベル(docLevel)とを取得する(L0033)。
セキュリティサーバ200は、ドキュメントプロファイル(docProfile)を参照して関係者リスト(relatedPersons)を取得する(L0034)。
セキュリティサーバ200は、関係者リスト(relatedPersons)に認証結果情報(authInfo)のユーザID(userId)または所属グループ(groups)が含まれているか否かを判別する(L0035)。
含まれている場合、セキュリティサーバ200は、ユーザカテゴリ(userCategory)に 関係者(RELATED_PERSONS)を設定する(L0036)。一方、含まれていない場合、セキュリティサーバ200は、ユーザカテゴリ(userCategory)に非限定(ANY)を設定する(L0037)。
セキュリティサーバ200は、ユーザ権限レベルテーブル(UserMapTable)を参照して、 ユーザID又はグループID(principalId)に対応するレベルを権限レベル(userLevel)に格納する(L0038)。
セキュリティサーバ200は、ドキュメントプロファイル(docProfile)を参照してゾーンIDリスト(zones)を取得する(L0039)。
セキュリティサーバ200は、ゾーン管理テーブル(ZoneInfoTable)を参照してゾーンIDリスト(zones)に対応するIPアドレス及びMACアドレスを取得して、許可アドレスリストを作成する(L0040)。
セキュリティサーバ200は、コンテキスト情報に含まれているアドレスが、作成した許可アドレスリストに含まれるか否かを判別する(L0041)。
含まれている場合、セキュリティサーバ200は、ゾーン(zone)に限定(RESTRICTED)を設定する(L0042)。一方、含まれていない場合、セキュリティサーバ200は、ゾーン(zone)に非限定(ANY)を設定する(L0043)。
セキュリティサーバ200は、セキュリティポリシーファイルをメモリにロードしてアクセス制限ルール(rule)の配列を取得する(L0044)。
セキュリティサーバ200は、個々のアクセス制御ルール(rule)について、以下のL0046からL0071までの処理を繰り返す(L0045)。
セキュリティサーバ200は、アクセス制御ルール(rule)の文書カテゴリ(docCategory)が非限定(ANY)又は文書カテゴリ(docCategory)と一致し、且つ、アクセス制御ルール(rule)の文書レベル(docLevel)が非限定(ANY)又は文書レベル(docLevel)と一致するか否かを判断する(L0046)。アクセス制御ルール(rule)の文書カテゴリ(docCategory)が非限定(ANY)又は文書カテゴリ(docCategory)と一致し、且つ、アクセス制御ルール(rule)の文書レベル(docLevel)が非限定(ANY)又は文書レベル(docLevel)と一致する場合、セキュリティサーバ200は、更にそのアクセス制御ルール(rule)の各アクセス制御リスト(Ace)について、以下のL0049からL0064までの処理を繰り返す(L0048)。
一方、一致しない場合(L0070及びL0071)、セキュリティサーバ200は、L0045に戻り、次のアクセス制御ルール(rule)について上記処理を繰り返す。
セキュリティサーバ200は、一致する場合に、アクセス制御リスト(Ace)のユーザカテゴリ(userCategory)が非限定(ANY)又はユーザカテゴリ(userCategory)と一致し、且つ、アクセス制御リスト(Ace)のユーザレベル(UserLevel)が非限定(ANY)又はユーザレベル(userLevel)と一致し、且つ、アクセス制御リスト(Ace)のゾーン(Zone)が非限定(ANY)又はゾーン(zone)と一致するか否かを判断する(L0049、L0050及びL0051)。アクセス制御リスト(Ace)のユーザカテゴリ(userCategory)が非限定(ANY)又はユーザカテゴリ(userCategory)と一致し、且つ、アクセス制御リスト(Ace)のユーザレベル(UserLevel)が非限定(ANY)又はユーザレベル(userLevel)と一致し、且つ、アクセス制御リスト(Ace)のゾーン(Zone)が非限定(ANY)又はソーン(zone)と一致する場合、セキュリティサーバ200は、アクセス制御リスト(Ace)の各オペレーション(Operation)について、以下のL0053からL0058を繰り返す(L0052)。
一方、一致しない場合(L0064及びL0065)、セキュリティサーバ200は、L0048に戻り、アクセス制御ルール(rule)の次のアクセス制御リスト(Ace)について上記処理を繰り返す。
セキュリティサーバ200は、L0049、L0050及びL0051での判断において一致すると判断した場合に、そのオペレーションのID(Operation.Id)がオペレーション(operation)と一致するか否かを判断する(L0053)。一致する場合、判断結果情報(decisionInfo)の許可(allowed)に許可(true)を格納する(L0054)。また、セキュリティサーバ200は、そのオペレーション(operation)に指定されている要件(requirement)を全て判断結果情報に格納し(L0055)、L0072へと進む(L0056)。一方、一致しない場合(L0058及びL0059)、セキュリティサーバ200は、L0052に戻り、アクセス制御リスト(Ace)の次の各オペレーション(Operation)について上記処理を繰り返す。
アクセス制御リスト(Ace)の各オペレーション(Operation)に対する処理が終了すると、セキュリティサーバ200は、該当するオペレーション(Operation)がなかったか否かを判断する(L0060)。なかった場合、セキュリティサーバ200は、判断結果情報(decisionInfo)の許可(allowed)に不許可(false)を格納し(L0061)、L0072へと進む(L0063)。一方、あった場合、セキュリティサーバ200は、そのままL0072へと進む(L0063)。
L0048におけるアクセス制御ルール(rule)の各アクセス制御リスト(Ace)に対する処理が終了すると、セキュリティサーバ200は、該当する各アクセス制御リスト(Ace)がなかったか否かを判断する(L0066)。なかった場合、セキュリティサーバ200は、判断結果情報(decisionInfo)の許可(allowed)に不許可(false)を格納し(L0067)、L0072へと進む(L0063)。一方、あった場合、セキュリティサーバ200は、そのままL0072へと進む(L0069)。
L0045において、個々のアクセス制御ルール(rule)に対する処理が終了すると、セキュリティサーバ200は、該当するアクセス制御ルール(rule)があったか否かを判断する(L0072)。なかった場合、セキュリティサーバ200は、判断結果情報(decisionInfo)の許可(allowed)に不許可(false)を格納し(L0073)、L0075へと進む。一方、あった場合、セキュリティサーバ200は、そのままL0075へと進む。
セキュリティサーバ200は、判断結果情報(decisionInfo)の許可(allowed)が不許可(false)であるか否かを判断する(L0075)。判断結果情報(decisionInfo)の許可(allowed)が不許可(false)である場合、その判断結果情報(decisionInfo)を判断要求をした文書管理システム100に返し(L0076)、許可処理を終了する(L0082)。
一方、判断結果情報(decisionInfo)の許可(allowed)が不許可(false)でない場合(L0078)、その判断結果(decisionInfo)に含まれる要件(requirement)の補正処理を行い(L0079)、その判断結果情報(decisionInfo)を判断要求をした文書管理システム100に返し(L0080)、許可処理を終了する(L0082)。
文書管理システム100からセキュリティサーバ200へ送信されるコンテキスト情報のデータ構造について図16で説明する。図16は、コンテキスト情報のデータ構造を示す図である。
図16において、コンテキスト情報は、ユーザ52が使用している端末51のアドレスを示す情報であって、コンテキスト情報のデータ構造511は、例えば、構造体ContextInfoで定義され、「String ipAddress;」を示すコード513−1により文字列で示されるIPアドレスと、「String macAddress;」を示すコード513−2により文字列で示されるMACアドレスとで構成される。
セキュリティサーバ200から文書管理システム100へ送信される判断結果情報(decisionInfo)について図17で説明する。図17は、判断結果情報のデータ構造を示す図である。
図17において、判断結果情報は、アクセス制御の判断結果を示す情報であって、判断結果情報のデータ構造521は、例えば、構造体DecisionInfoで定義され、「Boolean allowed;」を示すコード523−1により真偽で示される許可情報と、「Requirement[] requirements;」を示すコード523−2により要件の配列によって構成される複数の要件とで構成される。
更に、個々の要件は、構造体Requirementで定義され、「String requirement;」を示すコード525−1により文字列で示される要件を識別する要件IDと、「Property[] supplements;」を示すコード525−2により補足情報の配列によって構成される複数の補足情報と、「byte[] data;」を示すコード525−3によりバイトの配列によって構成される補足データと、「Requirement[] alternatives;」を示すコード525−4により要件の配列によって構成される複数の代替要件とで構成される。
補足情報は、構造体Propertyで定義され、「String name;」を示すコード527−1により文字列で示される名前と、「String value;」を示すコード527−2により文字列で示される値とを構成される。
次に文書管理システム100での要件の補正処理について図18で説明する。図18は、文書管理システムでの用件の補正処理を説明するためのフローチャート図である。
図18において、文書管理システム100は、判断結果情報(decisionInfo)の要件(requirement)に含まれる各補足情報(supplement)について、L1102からL1110まで繰り返す(L1101)。
文書管理システム100は、補足情報のプロパティ(Property)の名前(name)に固定画像(static_image)が指定されているか否かを判断する(L1102)。固定画像(static_image)が指定されている場合、文書管理システム100は、補足情報のプロパティ(Property)の値(value)に指定されているスタンプ画像ファイルのデータをローカルハードディスクから読み出して要件(requirement)の補足データ(data)に格納し(L1103)、L1105へ進む。
一方、固定画像(static_image)が指定されていない場合、文書管理システム100は、そのままL1105へ進む。
ここで、固定画像とは、例えば、スタンプ画像等である。
文書管理システム100は、補足情報のプロパティ(Property)の名前(name)に動的画像(dynamic_image)が指定され、 且つ 、オペレーション(operation)が"プリント"であるか否かを判断する(L1105)。補足情報のプロパティ(Property)の名前(name)に動的画像(dynamic_image)が指定され、 且つ 、オペレーション(operation)が"プリント"である場合、新しいプリントプロファイル(printProfile)を作成する(L1106)。また、文書管理システム100は、プリントプロファイル(printProfile)のプリントID(printId)を識別画像データにエンコードして(L1107)、識別画像データを要件(requirement)の補足データ(data)に格納する(L1108)。そして、文書管理システム100は、要件の補正処理を終了する。
一方、補足情報のプロパティ(Property)の名前(name)に動的画像(dynamic_image)が指定されていない、又は 、オペレーション(operation)が"プリント"でない場合、文書管理システム100は、そのまま要件の補正処理を終了する。
ここで、動的画像とは、バーコード画像又は識別パターン画像等である。
次に、文書管理システム100での要件処理について図19及び図20で説明する。図19及び図20は、文書管理システムでの要件処理を説明するためのフローチャート図である。
図19において、文書管理システム100は、判断結果情報(decisionInfo)の許可(allowed)が不許可(false)を示しているか否かを判断する(L1121)。不許可を示している場合、文書管理システム100は、アクセスを拒否して要件処理を終了する(L1122)。
一方、不許可を示していない場合、判断結果情報(decisionInfo)の各要件(requirement)について、L1125からL1160までを繰り返す(L1124)。
文書管理システム100は、文書管理システム100がサポートしていない要件(requirement)が指定されているか否かを判断する(L1125)。文書管理システム100がサポートしていない要件(requirement)が指定されていない場合、文書管理システム100は、L1131へ進む。
一方、文書管理システム100がサポートしていない要件(requirement)が指定されている場合、文書管理システム100は、更に、要件(requirement)の代替要件(alternative)にサポートしていないものが指定されているか否かを判断する(L1126)。要件(requirement)の代替要件(alternative)にサポートしていないものが指定されている場合、文書管理システム100は、アクセスを拒否して要件処理を終了する(L1127)。
一方、要件(requirement)の代替要件(alternative)にサポートしていないものが指定されていない場合、文書管理システム100は、要件(requirement)の代替要件(alternative)を処理する。
続けて、文書管理システム100は、要件(requirement)にログの記録(record_andit_data)が指定されているか否かを判断する(L1131)。ログの記録(record_andit_data)が指定されている場合、文書管理システム100は、ユーザID(userid)と、文書ID(docid)と、オペレーション(operation)と、日時と、コンテキスト情報(contextInfo)とを含むログデータを生成する(L1132)。
そして、文書管理システム100は、ログデータをセキュリティサーバに送信する(L1133)。文書管理システム100は、ログデータの送信に失敗したか否かを判断する(L1134)。ログデータの送信に失敗した場合、文書管理システム100は、アクセスを拒否して要件処理を終了する(L1135)。一方、ログデータの送信に成功した場合、文書管理システム100は、そのままL1138へ進む。
更に、文書管理システム100は、要件(requirement)に暗号化(encryption)が指定されているか否かを判断する(L1138)。暗号化(encryption)が指定されている場合、文書管理システム100は、保存しているドキュメントを暗号化する(L1139)。一方、暗号化(encryption)が指定されていない場合、文書管理システム100は、そのままL1141へ進む。
続けて、文書管理システム100は、要件(requirement)に電子文書の原本性の確保(integrity_protection)が指定されているか否かを判断する(L1141)。電子文書の原本性の確保(integrity_protection)が指定されている場合、文書管理システム100は、ドキュメントを原本性確保支援システムに転送して保存する。原本性確保支援システムは、例えば、特開2000−285024号で開示されているようなシステムであれば良い。また、文書管理システム100内にこのような原本性確保支援システムを構成しても良い。
一方、要件(requirement)に電子文書の原本性の確保(integrity_protection)が指定されていない場合、文書管理システム100は、そのままL1144へ進む。
更に、文書管理システム100は、要件(requirement)に電子文書へのアクセスに多段階認証を認めること(multi_authentication)が指定されているか否かを判断する(L1144)。指定されていない場合、文書管理システム100は、そのままL1150へ進む。
一方、指定されている場合、文書管理システム100は、端末52を使用しているユーザ52に厳密なユーザ認証(指紋認証など)を要求する(L1145)。厳密なユーザ認証後、文書管理システム100は、厳密な認証に失敗したか否かを判断する(L1146)。失敗した場合、文書管理システム100は、アクセスを拒否して要件処理を終了する(L1147)。一方、失敗でない場合、文書管理システム100は、そのまあL1150へ進む。
続けて、文書管理システム100は、要件(requirement)に電子文書のバーション管理(versioning)が指定されているか否かを判断する(L1150)。指定されている場合、文書管理システム100は、改訂されたドキュメントを新しい版として保存して(L1151)、L1153へ進む。一方、指定されていない場合、文書管理システム100は、そのままL1153へ進む。
更に、文書管理システム100は、要件(requirement)に電子文書の完全削除(complete_deletion)が指定されているか否かを判断する(L1153)。指定されている場合、文書管理システム100は、削除したドキュメントに対して完全削除処理を実行して(L1154)、L1156へ進む。一方、指定されていない場合、文書管理システム100は、そのままL1156へ進む。
続けて、文書管理システム100は、要件(requirement)に警告の表示(show_alarm)が指定されているか否かを判断する(L1156)。指定されている場合、文書管理システム100は、要件(requirement)の補足情報(supplement)に指定されている文字列フォーマットで警告文字列を作成し(L1157)、警告文字列をダイアログボックスでユーザ52に表示する(L1168)。そして、次の要件(requirement)に付いて上記同様の処理を繰り返すため、L1124へ戻る。一方、指定されていない場合、文書管理システム100は、そのままL1124へ戻る。
全ての要件(requirement)について上記処理が行われた後、文書管理システム100は、端末51から要求されたアクセス処理を行い(L1161)、要件処理を終了する(L1162)。
図19及び図20での説明において、判断結果情報(decisionInfo)の要件(requirement)について並列に処理しているが、対応しなければならない要件(requirement)はオペレーション(operation)毎に決まっているので上記のようにすべての要件(requirement)のパターンに対する処理を行わなくても良い。例えば、電子文書の完全削除(complete_deletion)が要件(requirement)として指定されるのはサーバドキュメント61に対してなされるときだけである。説明を簡単にするために上記のような処理例とした。文書管理システム100は、代替要件の処理についても上記と同様の処理を実行する。
このように、文書管理システム100はセキュリティサーバ200に設定されたセキュリティポリシーに従ってアクセス制御を行うことができる。その際に、セキュリティポリシーで規定された許可要件を適用することができる。また、許可要件を満たすために必要となる補足情報の処理及び代替要件の処理を盛り込むことで柔軟な処理が可能となる。
[デジタル複合機でのアクセス制御]
デジタル複合機70でのアクセス制御について、図21を参照しつつ図22で説明する。
図21は、デジタル複合機でのアクセス制御シーケンスを示す図である。図22は、デジタル複合機でのアクセス制御処理を説明するためのフローチャート図である。図21及び図22中、図21に示すアクセス制御シーケンスにおける各処理と、図22の各処理の説明とが同一符号によって対応付けられる。
図21及び図22において、デジタル複合機70は、ユーザ52のログインの要求と共に、ユーザIDとパスワードとを受け取る(S2001)。
デジタル複合機70は、受け取ったユーザIDとパスワードとをユーザ管理サーバ300に送信して認証要求を行う(S2002)。ユーザ管理サーバ300は、受け取ったユーザIDとパスワードとで認証処理を行う(S2003)。ユーザ管理サーバ300は、認証の成功又は失敗を示す認証結果情報をデジタル複合機70に返す(S2004)。
デジタル複合機70は、認証結果情報に応じた処理を行う(S2005)。認証結果情報が認証の成功を示す場合、デジタル複合機70は、ユーザ管理サーバ300から受け取った認証結果情報を端末51へ送信し、S2006へ進む。一方、認証結果情報が認証の失敗を示す場合、デジタル複合機70は、アクセス制御処理を終了する。
ユーザ52がデジタル複合機70で紙原稿の複写を要求する(S2006)。
デジタル複合機70は、紙原稿の複写の要求を受信すると、紙原稿を識別するために、紙原稿をスキャンした画像データから識別用の領域を切り出す(S2007)。
そのユーザ52の認証情報と、切り出し画像と、アクセス種別と、コンテキスト情報とをセキュリティサーバ200に送って、アクセス制御を問い合わせる(S2008)。アクセス種別には、例えば、複写要求に応じた複写アクセスが指定される。
セキュリティサーバ200は受け取った情報に基づいて、アクセスを許可するか否かを判断する(S2009)。セキュリティサーバ200は、判断結果をデジタル複合機に返す(S2010)。
デジタル複合機70は、セキュリティサーバ200から受信した判断結果に応じた処理を行う(S2011)。判断結果が「許可」を示す場合、デジタル複合機70は、判断結果に含まれる要件を処理する。一方、判断結果が「禁止」を示す場合、デジタル複合機70は、アクセスを行わずアクセス制御処理を終了する。
デジタル複合機70は、ユーザに要求されたにアクセス要求(複写要求)を処理して、複写した紙を出力し、アクセス制御処理を終了する(S2012)。
上記例では、アクセス要求が複写要求である場合について説明したが、スキャン要求、ファックス送信要求等についても同様の処理を行い、例えば、アクセス要求がスキャン要求である場合、スキャンした画像データを所定の記憶領域に格納し、アクセス要求がファックス送信要求である場合、ユーザ52によって指定された相手先へスキャンした画像データをファックス送信する。
S2002でのユーザ認証の問い合わせをセキュリティサーバ200を経由して行っても良い。ユーザを認証する方法は、ユーザIDとパスワードとによって認証する方法に限定されるものではない。より高度なバイオメトリック認証、又は、スマートカードを用いたチャレンジ・レスポンス認証等を適用しても良い。
S2003でのユーザ管理サーバ300による認証処理は、文書管理システム100におけるアクセス制御の場合と同様であるので、その説明を省略する。また、認証結果情報のデータ構造についても、文書管理システム100におけるアクセス制御の場合と同様であるので、その説明を省略する。
S2009でのセキュリティサーバ200によって行われる許可処理について図23、図24及び図25で説明する。図23、図24及び図25は、デジタル複合機からの問い合わせに応じたセキュリティサーバでの許可処理を説明する図である。
図23、図24及び図25では、ユーザ52がデジタル複合機70でペーパードキュメント62を複写する複写要求を行った場合の処理を例示している。デジタル複合機70での他のオペレーションとして、例えば、ファックス送信、スキャン等があり、夫々、ファックス送信要求、スキャン要求等としてデジタル複合機70からセキュリティサーバ100へ送信される。
ファックス送信のオペレーションは、デジタル複合機70でスキャンしたペーパードキュメント62をユーザ52が指定した宛先へファックス送信するアクセスである。また、スキャンのオペレーションは、ペーパードキュメント62をスキャンし、所定の記憶領域に画像データを格納するオペレーションである。
また、夫々の要求に対するセキュリティサーバ100での許可処理は同様である。
図23において、セキュリティサーバ200は、認証結果情報と、文書IDと、アクセス種別と、コンテキスト情報とを判断要求をした文書管理システム100から受け取る(L2031)。例えば、アクセス種別には、「ペーパードキュメントに対する複写」が指定される。アクセス種別によって、ドキュメント60の種別(つまり、ペーパードキュメント62)と、オペレーションの種別(つまり、複写)とが特定される。
セキュリティサーバ200は、受け取った切り出し画像をデコードしてプリントID(printId)を得る(L2032)。
セキュリティサーバ200は、デコードできないか否かを判断する(L2033)。デコードできない場合、セキュリティサーバ200は、文書カテゴリ(docCategory)に不明(UNKNOWN)を設定し(L2034)、文書レベル(docLevel)に不明(UNKNOWN)を設定し(L2035)、ユーザカテゴリ(userCategory)に非限定(ANY)を設定し(L2036)、ゾーン(zone)に非限定(ANY)を設定する(L2037)。
一方、デコードできた場合、セキュリティサーバ200は、プリントプロファイル管理テーブルを参照してプリントID(printId)に該当するプリントプロファイル(printProfile)を取得する(L2040)。
そして、セキュリティサーバ200は、該当するプリントプロファイルが存在しないか否かを判断する(L2041)。存在しない場合、セキュリティサーバ200は、文書カテゴリ(docCategory)に不明(UNKNOWN)を設定し(L2042)、文書レベル(docLevel)に不明(UNKNOWN)を設定し(L2043)、ユーザカテゴリ(userCategory)に非限定(ANY)を設定し(L2044)、ゾーン(zone)に非限定(ANY)を設定する(L2045)。
一方、該当するプリントプロファイルが存在する場合(L2047)、セキュリティサーバ200は、プリントプロファイル(printProfile)から文書ID(docid)を取得し(L2048)、ドキュメントプロファイル管理テーブルを参照して文書ID(docid)に該当するドキュメントプロファイル(docProfile)を取得し(L2049)、ドキュメントプロファイル(docProfile)を参照して文書カテゴリ(docCategory)と機密レベル(docLevel)とを取得し(L2050)、ドキュメントプロファイル(docProfile)を参照して関係者リスト(relatedPersons)を取得する(L2051)。
セキュリティサーバ200は、更に、関係者(relatedPersons)に認証情報のユーザID(userId)又は所属グループ(groups)が含まれているか否かを判別する(L2052)。含まれている場合、セキュリティサーバ200は、ユーザカテゴリ(userCategory)に関係者(RELATED_PERSONS)に設定し(L2053)、L2055へ進む。一方、含まれていない場合、セキュリティサーバ200は、ユーザカテゴリ(userCategory)に非限定(ANY)を設定し(L2054)、L2055へ進む。
セキュリティサーバ200は、ドキュメントプロファイル(docProfile)を参照してゾーンIDリスト(zones)を取得する(L2055)。セキュリティサーバ200は、ゾーン管理テーブル(ZoneInfoTable)を参照してゾーンIDリストに該当するIPアドレス、MACアドレスを取得する(許可アドレスリスト)(L2056)。
セキュリティサーバ200は、コンテキスト情報に含まれているアドレスが、上記許可アドレスリストに含まれるか否かを判別する(L2057)。含まれる場合、セキュリティサーバ200は、ゾーン(zone)に限定(RESTRICTED)を設定し(L2058)、L2062へ進む。一方、含まない場合、セキュリティサーバ200は、ゾーン(zone)に非限定(ANY)を設定する(L2059)し、L2062へ進む。
セキュリティサーバ200は、ユーザ権限レベルテーブル(UserMapTable)を参照して、ユーザID(userId)又は所属グループ(groups)が該当するレベルをユーザレベル(userLevel)に格納する(L2062)。
セキュリティサーバ200は、セキュリティポリシーファイルをメモリにロードしてアクセス制御ルール(rule)の配列を取得する(L2063)。
セキュリティサーバ200は、個々のアクセス制御ルール(rule)について以下のL2065からL2068までの処理を繰り返す(L0064)。
セキュリティサーバ200は、アクセス制御ルール(rule)の文書カテゴリ(docCategory)が非限定(ANY)又は文書カテゴリ(docCategory)と一致し、且つ、アクセス制御ルール(rule)の文書レベル(docLevel)が非限定(ANY)又は文書レベル(docLevel)と一致するか否かを判断する(L0065及びL2066)。一致する場合、セキュリティサーバ200は、更に、そのアクセス制御ルール(rule)の各アクセス制御リスト(Ace)について、以下のL2068からL2083までの処理を繰り返す(L2067)。
一方、一致しない場合(L2088及びL2089)、セキュリティサーバ200は、L2064に戻り、次のアクセス制御ルール(rule)について上記処理を繰り返す。
セキュリティサーバ200は、L0065及びL2066において一致する場合に、アクセス制御リスト(Ace)のユーザカテゴリ(userCategory)が非限定(ANY)又はユーザカテゴリ(userCategory)と一致し、且つ、アクセス制御リスト(Ace)のユーザレベル(UserLevel)が非限定(ANY)又はユーザレベル(userLevel)と一致し、且つ、アクセス制御リスト(Ace)のソーン(Zone)が非限定(ANY)又はゾーン(zone)と一致するか否かを判断する(L2068、L2069及びL2070)。アクセス制御リスト(Ace)のユーザカテゴリ(userCategory)が非限定(ANY)又はユーザカテゴリ(userCategory)と一致し、且つ、アクセス制御リスト(Ace)のユーザレベル(UserLevel)が非限定(ANY)又はユーザレベル(userLevel)と一致し、且つ、アクセス制御リスト(Ace)のソーン(Zone)が非限定(ANY)又はソーン(zone)と一致する場合、セキュリティサーバ200は、アクセス制御リスト(Ace)の各オペレーション(Operation)について、以下のL2072からL2077を繰り返す(L2071)。
一方、一致しない場合(L0082及びL0083)、セキュリティサーバ200は、L2067に戻り、アクセス制御ルール(rule)の次のアクセス制御リスト(Ace)について上記処理を繰り返す。
セキュリティサーバ200は、L2068、L2069及びL2070での判断において一致すると判断した場合に、そのオペレーションのID(Operation.Id)がオペレーション(operation)と一致するか否かを判断する(L2072)。一致する場合、判断結果情報(decisionInfo)の許可(allowed)に許可(true)を格納する(L2073)。また、セキュリティサーバ200は、そのオペレーション(operation)に指定されている要件(requirement)を全て判断結果情報に格納し(L2074)、L2098へと進む(L2081)。
一方、一致しない場合(L2076及びL2077)、セキュリティサーバ200は、L2071に戻り、アクセス制御リスト(Ace)の次の各オペレーション(Operation)について上記処理を繰り返す。
L2071において、アクセス制御リスト(Ace)の各オペレーション(Operation)に対する処理が終了すると、セキュリティサーバ200は、該当するオペレーション(Operation)がなかったか否かを判断する(L2078)。なかった場合、セキュリティサーバ200は、判断結果情報(decisionInfo)の許可(allowed)に不許可(false)を格納し(L2079)、L2090へと進む(L2081)。
一方、あった場合、セキュリティサーバ200は、そのままL2090へと進む(L2081)。
L2067において、個々のアクセス制御ルール(rule)に対する処理が終了すると、セキュリティサーバ200は、該当するアクセス制御ルール(rule)があったか否かを判断する(L2090)。なかった場合、セキュリティサーバ200は、判断結果情報(decisionInfo)の許可(allowed)に不許可(false)を格納し(L2091)、L2093へと進む。一方、あった場合、セキュリティサーバ200は、そのままL2093へと進む。
セキュリティサーバ200は、判断結果情報(decisionInfo)の許可(allowed)が不許可(false)であるか否かを判断する(L2093)。判断結果情報(decisionInfo)の許可(allowed)が不許可(false)である場合、その判断結果情報(decisionInfo)を判断要求をしたデジタル複合機70に返し(L2094)、許可処理を終了する(L2100)。
一方、判断結果情報(decisionInfo)の許可(allowed)が不許可(false)でない場合(L2096)、その判断結果(decisionInfo)に含まれる要件(requirement)の補正処理を行い(L2097)、その判断結果情報(decisionInfo)を判断要求をした文書管理システム100に返し(L2098)、許可処理を終了する(L2100)。
デジタル複合機70からセキュリティサーバ200へ送信されるコンテキスト情報のデータ構造は、文書管理システム100からセキュリティサーバ200へ送信されるコンテキスト情報のデータ構造と同様であるので、その説明を省略する。
セキュリティサーバ200からデジタル複合機70からへ送信される判断結果情報のデータ構造は、セキュリティサーバ200から文書管理システム100へ送信される判断結果情報のデータ構造と同様であるので、その説明を省略する。
デジタル複合機70での要件の補正処理は、文書管理システム100での要件の補正処理と同様であるので、その説明を省略する。
次に、デジタル複合機70での要件処理について図26、図27及び図28で説明する。図26、図27及び図28は、デジタル複合機での要件処理を説明するためのフローチャート図である。
図26において、デジタル複合機70は、判断結果情報(decisionInfo)の許可(allowed)が不許可(false)を示しているか否かを判断する(L2121)。不許可を示している場合、アクセスを拒否して終了する(L2122)。
一方、不許可を示していない場合、判断結果情報(decisionInfo)の各要件(requirement)について、L2125からL2178までを繰り返す(L2124)。
デジタル複合機70は、デジタル複合機70がサポートしていない要件(requirement)が指定されているか否かを判断する(L2125)。デジタル複合機70がサポートしていない要件(requirement)が指定されていない場合、デジタル複合機70は、L2131へ進む。
一方、デジタル複合機70がサポートしていない要件(requirement)が指定されている場合、デジタル複合機70は、更に、要件(requirement)の代替要件(alternative)にサポートしていないものが指定されているか否かを判断する(L2126)。要件(requirement)の代替要件(alternative)にサポートしていないものが指定されている場合、デジタル複合機70は、アクセスを拒否して要件処理を終了する(L2127)。
一方、要件(requirement)の代替要件(alternative)にサポートしていないものが指定されていない場合、デジタル複合機70は、要件(requirement)の代替要件(alternative)を処理する(L2128)。
続けて、デジタル複合機70は、要件(requirement)にログの記録(record_andit_data)が指定されているか否かを判断する(L2131)。ログの記録(record_andit_data)が指定されている場合、デジタル複合機70は、ユーザID(userid)と、文書ID(docid)と、オペレーション(operation)と、日時と、コンテキスト情報(contextInfo)とを含むログデータを生成する(L2132)。
そして、デジタル複合機70は、ログデータをセキュリティサーバ200に送信する(L2133)。デジタル複合機70は、ログデータの送信に失敗したか否かを判断する(L2134)。ログデータの送信に失敗した場合、デジタル複合機70は、アクセスを拒否して要件処理を終了する(L2135)。一方、ログデータの送信に成功した場合、デジタル複合機70は、そのままL2138へ進む。
更に、デジタル複合機70は、ラベルの印刷(show_label)が指定されているか否かを判断する(L2138)。指定されている場合、デジタル複合機70は、その要件(requirement)の補足情報(supplement)に指定されているスタンプ画像をドキュメントに印字して埋め込む(L2139)。一方、指定されていない場合、デジタル複合機70は、そのままL2141へ進む。
続けて、デジタル複合機70は、ユーザ名の印刷(show_operator)が指定されているか否かを判断する(L2141)。指定されている場合、デジタル複合機70は、ドキュメントに操作者名(operator)を印字して埋め込む(L2142)。一方、指定されていない場合、デジタル複合機70は、そのままL2144へ進む。
更に、デジタル複合機70は、イメージログの記録(record_image_data)が指定されているか否かを判断する(L2144)。指定されている場合、デジタル複合機70は、ユーザID(userid)と、文書ID(docid)と、オペレーション(operation)と、日時と、コンテキスト情報(contextInfo)と、ドキュメントデータ(スキャンデータ)とを含むイメージログデータを生成する(L2145)。続けて、デジタル複合機70は、イメージログデータをデジタル複合機の内部ハードディスクに保存する(L2146)。一方、指定されていない場合、デジタル複合機70は、そのままL2148へ進む。
続けて、デジタル複合機70は、警告の表示(show_alarm)が指定されているか否かを判断する(L2148)。指定されている場合、デジタル複合機70は、その要件(requirement)の補足情報(supplement)に指定されている文字列フォーマットで警告文字列を作成し(L2149)、警告文字列をオペパネ上でユーザに表示する(L2150)。一方、指定されていない場合、デジタル複合機70は、そのままL2152へ進む。
更に、デジタル複合機70は、警告の印刷(print_alarm)が指定されているか否かを判断する(L2152)。指定されている場合、デジタル複合機70は、その要件(requirement)の補足情報(supplement)に指定されている文字列フォーマットで警告文字列を作成し(L2153)、警告文字列をドキュメントに印字して埋め込む(L2154)。一方、指定されていない場合、デジタル複合機70は、そのままL2156へ進む。
続けて、デジタル複合機70は、ファックス送信の宛先制限(address_restriction)が指定されているか否かを判断する(L2156)。指定されている場合、デジタル複合機70は、その要件(requirement)の補足情報(supplement)に指定されている宛先条件で、ユーザが指定した宛先をチェックする(L2157)。更に、デジタル複合機70は、宛先条件にマッチしないか否かを判断する(L2158)。マッチしない場合、デジタル複合機70は、宛先が条件にマッチしないことをオペパネ上でユーザに通知して(L2159)、アクセスを拒否して終了する(L2160)。一方、マッチする場合、デジタル複合機70は、そのままL2162へ進む。
L2156での判断によって指定されていないと判断した場合、デジタル複合機70は、そのままL2162へ進む。
更に、デジタル複合機70は、親展送信モードの使用(private_send)が指定されているか否かを判断する(L2163)。指定されている場合、デジタル複合機70は、送信条件を親展送信モードに設定する(L2164)。そして、デジタル複合機70は、親展送信モードに設定できないかを判断する(L2165)。設定できない場合、デジタル複合機70は、相手が親展送信を受け付けられないことをオペパネ上でユーザに通知して(L2166)、アクセスを拒否して要件処理終了する(L2167)。一方、設定できる場合、デジタル複合機70は、そのままL2170へ進む。
L2163での判断によって指定されていないと判断した場合、デジタル複合機70は、そのままL2170へ進む。
続けて、デジタル複合機70は、目に見える透かし文字の印刷(visible_watermark)が指定されているか否かを判断する(L2170)。指定されている場合、デジタル複合機70は、その要件(requirement)の補足情報(supplement)に指定されている文字列フォーマットで文字列を作成し(L2171)、その文字列をウォーターマークとしてドキュメントに埋め込む(L2172)。一方、指定されていない場合、デジタル複合機70は、そのままL2174へ進む。
更に、デジタル複合機70は、電子透かしの埋め込み(digital_watermark)が指定されているか否かを判断する(L2174)。指定されている場合、デジタル複合機70は、その要件(requirement)の補足情報(supplement)に指定されている文字列フォーマットで文字列を作成し(L2175)、その文字列を電子透かしとしてスキャンしたデータに埋め込む(L2176)。そして、次の要件(requirement)について上記同様の処理を繰り返すため、L2124へ戻る。一方、指定されていない場合、デジタル複合機70は、そのままL2124へ戻る。
全ての要件(requirement)について上記処理が行われた後、デジタル複合機70は、端末51から要求されたアクセス処理を行い(L2179)、要件処理を終了する(L2180)。
上記より、デジタル複合機70はセキュリティサーバ200に設定されたセキュリティポリシーに従ってアクセス制御を行うことができる。その際に、セキュリティポリシーで規定された許可要件を適用することができる。また、許可要件を満たすために必要となる補足情報の処理や、代替要件の処理を盛り込むことで柔軟な処理が可能となる。
ペーパードキュメント62の識別は100%完全であるわけではないため、識別エラーが発生することもある。デジタル複合機70で紙文書を複写する際にその紙文書が識別できなかった場合、基本的にはセキュリティ保護されていない一般の紙文書として複写できなければならない。そのような事情があるため、識別できなかったときにも何らかのセキュリティ処理を働かせられるようにする必要がある。そのようなケースも考え、識別できなかった原稿(UNKNOWNという文書カテゴリになる)の処理もポリシーに従って実行できるようにしている。
[ドキュメントビューアでのアクセス制御]
ドキュメントビューア53でのアクセス制御について、図29を参照しつつ図30及び図31で説明する。
図29は、ドキュメントビューアでのアクセス制御シーケンスを示す図である。図30及び図31は、ドキュメントビューアでのアクセス制御処理を説明するためのフローチャート図である。図29、図30及び図31中、図29に示すアクセス制御シーケンスにおける各処理と、図30及び図31の各処理の説明と同一符号によって対応付けられる。
図29及び図30において、ドキュメントビューア53は、ユーザ52からファイル(ポータブルドキュメント63)をオープンするオープン要求を受け取る(S3001)。
ドキュメントビューア53は、ポータブルドキュメント63がセキュリティで保護されているかどうか確認する(S3002)。ドキュメントビューア53は、ポータブルドキュメント63に対する保護の有無に応じた処理を行う(S3003)。ポータブルドキュメント63が保護されていない場合、ドキュメントビューア53は、ポータブルドキュメント63の内容を表示して、アクセス制御処理を終了する。一方、ポータブルドキュメント63が保護されている場合、ドキュメントビューア53は、そのままS3004へ進む。
ドキュメントビューア53は、ユーザにユーザIDとパスワードとの入力を求めて、それらを受け取る(S3004)。
ドキュメントビューア53は、受け取ったユーザIDとパスワードとをユーザ管理サーバに送信してユーザ認証を行う(S3005)。
ユーザ管理サーバ300は、受け取ったユーザIDとパスワードでユーザ認証処理を行い(S3006)、認証結果情報をドキュメントビューア53に返す(S3007)。
ドキュメントビューア53は、ユーザ管理サーバ300から認証結果情報を受信すると、認証結果情報に応じた処理を行う(S3008)。認証が失敗した場合、ドキュメントビューア53は、ユーザ52に認証エラーを通知して、アクセス制御処理を終了する。認証が成功した場合、ドキュメントビューア53は、そのままS3009へ進む。
ドキュメントビューア53は、ポータブルドキュメント63の中から文書IDを取り出す(S3009)。そして、ドキュメントビューア53は、認証結果情報、文書ID、アクセス種別、ドキュメントビューア53が動作している端末52のコンテキスト情報をセキュリティサーバ200に送信して、アクセス制御を問い合わせる(S3010)。アクセス種別は、例えば、オープン要求に応じた読込アクセスが指定される。
セキュリティサーバ200は、受け取った情報に基づいてアクセスを許可するかどうか判断する(S3011)。セキュリティサーバ200は、判断結果をドキュメントビューア53に返す(S3012)。
判断結果が「許可」を示す場合、ドキュメントビューア53は、判断結果に含まれる要件を処理する(S3013)。判断結果が「禁止」を示す場合は、アクセスは禁止され、アクセス制御処理を終了する。
ドキュメントビューア53は、ユーザ52に要求されたアクセス(ファイルオープン)を処理して、ポータブルドキュメント63の内容を表示する(S3014)。
ドキュメントビューア53は、ユーザ52からポータブルドキュメント63の印刷要求を受け取る(S3015)。
ドキュメントビューア53は、認証結果情報、文書ID、アクセス種別、ドキュメントビューアが動作している端末のコンテキスト情報をセキュリティサーバに送信して、アクセス制御を問い合わせる(S3016)。アクセス種別は、例えば、印刷要求に応じた印刷アクセスが指定される。
セキュリティサーバ200は、受け取った情報に基づいてアクセスを許可するかどうか判断し(S3017)、判断結果をドキュメントビューアに返す(S3018)。
判断結果が「許可」を示す場合、ドキュメントビューア53は。判断結果に含まれる要件を処理する(S3019)。判断結果が「禁止」を示す場合は、アクセスは禁止され、アクセス制御処理を終了する。
ドキュメントビューア53は、ユーザに要求されたアクセス(印刷)を処理して、ポータブルドキュメント63の内容を印刷出力する(S3020)。
S3005でのユーザ認証の問い合わせをセキュリティサーバ200を経由して行っても良い。ユーザ52を認証する方法は、ユーザIDとパスワードとによって認証する方法に限定されるものではない。より高度なバイオメトリック認証、又は、スマートカードを用いたチャレンジ・レスポンス認証等を適用しても良い。
S3006でのユーザ管理サーバ300による認証処理は、文書管理システム100におけるアクセス制御の場合と同様であるので、その説明を省略する。また、認証結果情報のデータ構造についても、文書管理システム100におけるアクセス制御の場合と同様であるので、その説明を省略する。
S3011及びS3017でのセキュリティサーバ200によって行われる許可処理は、文書管理システム100におけるアクセス制御の場合と同様であるので、その説明を省略する。また、判断結果情報のデータ構造についても、文書管理システム100におけるアクセス制御の場合と同様であるので、その説明を省略する。
ドキュメントビューア53での要件の補正処理は、文書管理システム100での要件の補正処理と同様であるので、その説明を省略する。
次に、ドキュメントビューア53での要件処理について図32から図36で説明する。図32から図36は、ドキュメントビューアでの要件処理を説明するためのフローチャート図である。
図32において、ドキュメントビューア53は、判断結果情報(decisionInfo)の許可(allowed)が不許可(false)を示しているか否かを判断する(L3121)。不許可を示している場合、アクセスを拒否して終了する(L3122)。
一方、不許可を示していない場合、判断結果情報(decisionInfo)の各要件(requirement)について、L3125からL3243までを繰り返す(L3124)。
ドキュメントビューア53は、ドキュメントビューア53がサポートしていない要件(requirement)が指定されているか否かを判断する(L3125)。ドキュメントビューア53がサポートしていない要件(requirement)が指定されていない場合、ドキュメントビューア53は、L3131へ進む。
一方、ドキュメントビューア53がサポートしていない要件(requirement)が指定されている場合、ドキュメントビューア53は、更に、要件(requirement)の代替要件(alternative)にサポートしていないものが指定されているか否かを判断する(L3126)。要件(requirement)の代替要件(alternative)にサポートしていないものが指定されている場合、ドキュメントビューア53は、アクセスを拒否して要件処理を終了する(L3127)。
一方、要件(requirement)の代替要件(alternative)にサポートしていないものが指定されていない場合、ドキュメントビューア53は、要件(requirement)の代替要件(alternative)を処理する(L3128)。
続けて、ドキュメントビューア53は、要件(requirement)にログの記録(record_andit_data)が指定されているか否かを判断する(L3131)。ログの記録(record_andit_data)が指定されている場合、ドキュメントビューア53は、ユーザID(userid)と、文書ID(docid)と、オペレーション(operation)と、日時と、コンテキスト情報(contextInfo)とを含むログデータを生成する(L3132)。
そして、ドキュメントビューア53は、ログデータをセキュリティサーバ200に送信する(L3133)。ドキュメントビューア53は、ログデータの送信に失敗したか否かを判断する(L3134)。ログデータの送信に失敗した場合、ドキュメントビューア53は、アクセスを拒否して要件処理を終了する(L3135)。一方、ログデータの送信に成功した場合、ドキュメントビューア53は、そのままL3138へ進む。
更に、ドキュメントビューア53は、電子文書へのアクセスに多段階認証を認めること(multi_authentication)が指定されているか否かを判断する(L3138)。指定されている場合、ドキュメントビューア53は、ユーザ52に厳密なユーザ認証(指紋認証など)を要求する(L3139)。ドキュメントビューア53は、更に、厳密な認証に失敗したか否かを判断する(L3140)。失敗した場合、アクセスを拒否して終了する(L3141)。一方、多段階認証が指定されていない場合及び厳密な認証に成功した場合、ドキュメントビューア53は、そのままL3144へ進む。
続けて、ドキュメントビューア53は、警告の表示(show_alarm)が指定されているか否かを判断する(L3144)。指定されている場合、ドキュメントビューア53は、その要件(requirement)の補足情報(supplement)に指定されている文字列フォーマットで警告文字列を作成し(L3145)、警告文字列をオペパネ上でユーザに表示する(L3146)。一方、指定されていない場合、ドキュメントビューア53は、そのままL3148へ進む。
更に、ドキュメントビューア53は、機密印刷モード(private_access)が指定されているか否かを判断する(L3148)。指定されていない場合、ドキュメントビューア53は、そのままL3160へ進む。
一方、指定されている場合、ドキュメントビューア53は、印刷先プリンタが機密印刷をサポートしていないか否かを判断する(L3149)。サポートしていない場合、ドキュメントビューア53は、その要件(requirement)の代替要件(alternative)を処理する(L3150)。そして、ドキュメントビューア53は、代替要件(alternative)が処理できなかったか否かを判断する(L3151)。処理できなかった場合、ドキュメントビューア53は、アクセスを拒否して終了する(L3152)。一方、代替要件(alternative)が処理できた場合、ドキュメントビューア53は、そのままL3160へ進む。
一方、機密印刷をサポートしている場合(L3155)、ドキュメントビューア53は、ユーザ52にパスワードを入力するダイアログを表示し(L3156)、ユーザ52から入力されたパスワードをプリンタドライバにセットして機密印刷モードにする(L3157)。そして、ドキュメントビューア53は、L3160へ進む。
続けて、ドキュメントビューア53は、イメージログの記録(record_image_data)が指定されているか否かを判断する(L3160)。指定されている場合、ドキュメントビューア53は、更に、印刷先プリンタがイメージログ記録をサポートしていないか否かを判断する(L3161)。サポートしていない場合、ドキュメントビューア53は、その要件(requirement)の代替要件(alternative)を処理する(L3162)。そして、ドキュメントビューア53は、代替要件(alternative)が処理できなかったか否かを判断する(L3163)。処理できなかった場合、ドキュメントビューア53は、アクセスを拒否して終了する(L3164)。一方、代替要件(alternative)が処理できた場合、ドキュメントビューア53は、そのままL3173へ進む。
一方、イメージログ記録をサポートしている場合(L3167)、ドキュメントビューア53は、ユーザID(userid)と、文書ID(docid)と、オペレーション(operation)と、日時と、コンテキスト情報(contextInfo)とを含むログデータを生成する(L3168)。ドキュメントビューア53は、イメージログ書誌事項をプリンタドライバに設定し(L3169)、イメージログ記録モードをプリンタドライバに設定する(L3170)。そして、ドキュメントビューア53は、L3173へ進む。
更に、ドキュメントビューア53は、追跡情報の埋め込み(embed_trace_info)が指定されているか否かを判断する(L3173)。指定されていない場合、ドキュメントビューア53は、そのままL3187へ進む。
追跡情報の埋め込みが指定されている場合、ドキュメントビューア53は、更に、印刷先プリンタのドライバがスタンプ印字をサポートしているか否かを判断する(L3174)。サポートしている場合、ドキュメントビューア53は、その要件(requirement)の補足情報(supplement)に指定されているバーコード画像をプリンタドライバにセットしてスタンプ印字モードにする(L3175)。そして、ドキュメントビューア53は、L3187へ進む。
一方、印刷先プリンタのドライバがスタンプ印字をサポートしていない場合、ドキュメントビューア53は、更に、ドキュメントビューア53がドキュメント編集をサポートしているか否かを判断する(L3177)。指定されている場合、ドキュメントビューア53は、ドキュメントを編集してその要件(requirement)の補足情報(supplement)に指定されているバーコード画像を印刷する各ページに埋め込む(L3178)。一方、指定されている場合(L3180)、ドキュメントビューア53は、その要件(requirement)の代替要件(alternative)を処理する(L3181)。ドキュメントビューア53は、代替要件(alternative)が処理できなかった否かを判断する(L3182)。処理できなかった場合、ドキュメントビューア53は、アクセスを拒否して、要件処理を終了する(L3183)。処理できた場合、ドキュメントビューア53は、そのままL3187へ進む。
続けて、ドキュメントビューア53は、ラベルをスタンプとして印刷すること(show_label)が指定されているか否かを判断する(L3187)。指定されていない場合、ドキュメントビューア53は、そのままL3201へ進む。指定されている場合、ドキュメントビューア53は、更に、印刷先プリンタのドライバがスタンプ印字をサポートしているか否かを判断する(L3188)。スタンプ印字をサポートしている場合、ドキュメントビューア53は、その要件(requirement)の補足情報(supplement)に指定されているスタンプ画像をプリンタドライバにセットしてスタンプ印字モードにする(埋め込み位置はその要件(requirement)の補足情報(supplement)に指定されている「埋め込み位置」)(L3189)。そして、ドキュメントビューア53は、L3201へ進む。
一方、スタンプ印字をサポートしていない場合(L3191)、ドキュメントビューア53は、ドキュメントビューア53がドキュメント編集をサポートしているか否かを判断する(L3191)。ドキュメント編集をサポートしている場合、ドキュメントビューア53は、ドキュメントを編集してその要件(requirement)の補足情報(supplement)に指定されているスタンプ画像を印刷する各ページに埋め込む(埋め込み位置はその要件(requirement)の補足情報(supplement)に指定されている「埋め込み位置」)(L3192)。
一方、ドキュメント編集をサポートしていない場合、ドキュメントビューア53は、その要件(requirement)の代替要件(alternative)を処理する(L3195)。そして、ドキュメントビューア53は、代替要件(alternative)が処理できなかったか否かを判断する(L3196)。処理できなかった場合、ドキュメントビューア53は、アクセスを拒否して要件処理を終了する(L3197)。一方、処理できた場合、ドキュメントビューア53は、そのままL3201へ進む。
更に、ドキュメントビューア53は、目に見える透かし文字の印刷(visible_watermark)が指定されているか否かを判断する(L3201)。指定されていない場合、ドキュメントビューア53は、そのままL3216へ進む。
一方、指定されている場合、ドキュメントビューア53は、その要件(requirement)の補足情報(supplement)に指定されている文字列フォーマットで背景文字列を作成する(L3202)。そして、ドキュメントビューア53は、更に、印刷先プリンタのドライバが合成印刷をサポートしているか否かを判断する(L3203)。サポートしている場合、ドキュメントビューア53は、その背景文字列を合成文字列としてプリンタドライバにセットする(L3204)。そして、ドキュメントビューア53は、L3216へ進む。
一方、印刷先プリンタのドライバが合成印刷をサポートしていない場合、ドキュメントビューア53は、ドキュメントビューア53がドキュメント編集をサポートしているか否かを判断する(L3206)。サポートしている場合、ドキュメントを編集してその背景文字列をドキュメントの背景に埋め込む(L3207)。そして、ドキュメントビューア53は、L3216へ進む。
一方、ドキュメント編集をサポートしていない場合、ドキュメントビューア53は、その要件(requirement)の代替要件(alternative)処理する(L3200)。そして、ドキュメントビューア53は、更に、代替要件(alternative)が処理できないか否かを判断する(L3211)。ドキュメントビューア53は、アクセスを拒否して、要件処理を終了する(L3212)。
続けて、ドキュメントビューア53は、浮き出る透かし文字の印刷(anti_copy_watermark)が指定されているか否かを判断する(L3216)。指定されていない場合、ドキュメントビューア53は、L3232へ進む。
一方、指定されている場合、ドキュメントビューア53は、その要件(requirement)の補足情報(supplement)に指定されている文字列フォーマットで地紋文字列を作成する(L3217)。ドキュメントビューア53は、更に、印刷先プリンタのドライバが地紋印刷をサポートしているか否かを判断する(L3218)。サポートしている場合、ドキュメントビューア53は、その地紋文字列をプリンタドライバにセットする(L3219)。そして、ドキュメントビューア53は、L3232へ進む。
一方、地紋印刷をサポートしていない場合、ドキュメントビューア53は、ドキュメントビューア53がドキュメント編集をサポートしているか否かを判断する(L3221)。サポートしている場合、ドキュメントビューア53は、地紋文字列に基づいて地紋画像を生成し(L3222)、ドキュメントを編集してその地紋画像をドキュメントの背景に埋め込む(L3223)。
一方、ドキュメント編集をサポートしていない場合(L3225)、ドキュメントビューア53は、その要件(requirement)の代替要件(alternative)を処理する(L3226)。そして、ドキュメントビューア53は、代替要件(alternative)が処理できないか否かを判断する(L3227)。処理できなかった場合、ドキュメントビューア53は、アクセスを拒否して、要件処理を終了する(L3228)。一方、処理できた場合、ドキュメントビューア53は、そのままL3232へ進む。
更に、ドキュメントビューア53は、識別パターンの印刷(identifiable_bg_pattern)が指定されているか否かを判断する(L3232)。指定されていない場合、ドキュメントビューア53は、L3247へ進む。
識別パターンの印刷が指定されている場合、ドキュメントビューア53は、その要件(requirement)の補足情報(supplement)に指定されている識別パターン画像で地紋文字列を作成する(L3233)。そして、ドキュメントビューア53は、更に、印刷先プリンタのドライバが繰り返しスタンプ印刷をサポートしているか否かを判断する(L3234)。サポートしている場合、ドキュメントビューア53は、その要件(requirement)の補足情報(supplement)に指定されている識別パターン画像をプリンタドライバにセットして繰り返しスタンプ印刷モードにする(L3235)。そして、ドキュメントビューア53は、L3247へ進む。
一方、繰り返しスタンプ印刷をサポートしていない場合(L3237)、ドキュメントビューア53は、更に、ドキュメントビューアがドキュメント編集をサポートしているか否かを判断する(L3237)。サポートしている場合、ドキュメントビューア53は、ドキュメントを編集して、その要件(requirement)の補足情報(supplement)に指定されている識別パターン画像をドキュメントの背景に繰り返し埋め込む(L3238)。そして、ドキュメントビューア53は、L3247へ進む。
一方、ドキュメント編集をサポートしていない場合(L3240)、ドキュメントビューア53は、その要件(requirement)の代替要件(alternative)を処理する(L3241)。そして、ドキュメントビューア53は、代替要件(alternative)が処理できないか否かを判断する(L3242)。処理できなかった場合、ドキュメントビューア53は、アクセスを拒否して要件処理を終了する(L3243)。一方、処理できた場合、ドキュメントビューア53は、L3247へ進む。
続けて、ドキュメントビューア53は、警告の印刷(print_alarm)が指定されているか否かを判断する(L3247)。指定されていない場合、ドキュメントビューア53は、そのままL3124へ戻る。
一方、指定されている場合、ドキュメントビューア53は、その要件(requirement)の補足情報(supplement)に指定されている文字列フォーマットで警告文字列を作成する(L3248)。そして、ドキュメントビューア53は、更に、印刷先プリンタのドライバがヘッダー/フッター印刷をサポートしているか否かを判断する(L3249)。サポートしている場合、ドキュメントビューア53は、その警告文字列をプリンタドライバにヘッダー/フッターとしてセットする(L3250)。
一方、ヘッダー/フッター印刷をサポートしていない場合、ドキュメントビューア53は、更に、ドキュメントビューア53がドキュメント編集をサポートしているか否かを判断する(L3252)。サポートしている場合、ドキュメントビューア53は、警告文字列をドキュメントのヘッダー/フッターに埋め込む(L3253)。
一方、ドキュメント編集をサポートしていない場合(L3255)、ドキュメントビューア53は、その要件(requirement)の代替要件(alternative)を処理する(L3256)。そして、ドキュメントビューア53は、更に、代替要件(alternative)が処理できなかったか否かを判断する(L3257)。処理できなかった場合、ドキュメントビューア53は、アクセスを拒否して、要件処理を終了する(L3258)。
一方、代替要件の処理ができた場合、ドキュメントビューア53は、次の要件(requirement)について上記同様の処理を繰り返すため、L2124へ戻る。
全ての要件(requirement)について上記処理が行われた後、ドキュメントビューア53は、ユーザ52から要求されたアクセス処理を行い(L3263)、要件処理を終了する(L3264)。
上記より、ドキュメントビューア53はセキュリティサーバ200に設定されたセキュリティポリシーに従ってアクセス制御を行うことができる。その際に、セキュリティポリシーで規定された許可要件を適用することができる。また、許可要件を満たすために必要となる補足情報の処理や、代替要件の処理を盛り込むことで柔軟な処理が可能となる。
上記において、ドキュメントビューア53が編集機能をサポートしているか否かの判断が行われる要件処理では、指定されている要件が実現できない場合においても、ポータブルドキュメント63の内容を一時的に編集して必要な情報をポータブルドキュメント63中に埋め込んだ上で処理を行うことができる。
上記のようなアクセス制御を実現するドキュメントビューア53でしかポータブルドキュメント63を開くことができないように、ポータブルドキュメント63は暗号化しておく必要がある。
暗号化/復号に使用する鍵は、上記アクセス制御を実現できる特殊なドキュメントビューア53に組み込んでおいても良いし、アクセス制御を執行できる特殊なドキュメントビューア53であることが確認できた場合にだけ、セキュリティサーバ200側からドキュメントビューア53側に復号鍵を転送するようにしても良い。
そのようにしておくことでアクセス制御を実現することのできない一般のドキュメントビューア53でポータブルドキュメント63を開かれてしまうのを防ぐことができる.
上記のようにセキュリティポリシーに基づいて、印刷要求に対するアクセス制御が行われる場合に、ドキュメントビューア53を表示している端末51に表示される画面例を図37から図41で説明する。ユーザ52は、以下に説明されるような画面にてどのような要件が処理されるのかを知ることができる。
図37は、要件として警告の印刷が指定された場合の画面例を示す図である。図37(A)は、警告の印刷のための設定がなされている画面例を示す図である。図37(B)は、警告の印刷のための詳細が設定されている画面例を示す図である。
図37(A)において、画面600は、要件として警告の印刷が指定された場合の画面であって、画面600の設定域601は、本来、ユーザ52によってヘッダー又はフッターに印字するための設定域である。警告の印刷がユーザ62の印刷要求を実行するための要件として処理される場合、ドキュメントビューア53による要件処理によって強制的にヘッダー又はフッターへの印字が設定されると共に、グレー表示され、ユーザ52によってその設定を変更することができないように制御される。
ユーザ52が、設定域601内の詳細ボタンをクリックすると図37(B)のような画面が表示される。
図37(B)において、画面605は、要件として警告の印刷が指定された場合の詳細な設定を示す画面であって、画面605の設定域606は、本来、ユーザ52によってヘッダー又はフッターに印字するための文字列の配置位置及び書式を設定するための設定域である。警告の印刷がユーザ62の印刷要求を実行するための要件として処理される場合、ドキュメントビューア53による要件処理によって強制的に文字列の配置位置及び書式が設定されると共に、グレー表示され、ユーザ52によってその設定を変更することができないように制御される。
ユーザ52は、設定を変更することは禁止されるが、警告の印刷が要件であることを印刷する前に確認することができる。この確認によって、ユーザ52は、実際に印刷を実行するかキャンセルするかを判断することもできる。
図38は、要件として機密印刷が指定された場合の画面例を示す図である。図38(A)は、機密印刷のための設定がなされている画面例を示す図である。図38(B)は、機密印刷のための認証情報を設定するための画面例を示す図である。
図38(A)において、画面610は、要件として機密印刷が指定された場合の画面であって、画面610の印刷方法を選択する選択域611は、本来、ユーザ52によって選択される選択域である。機密印刷がユーザ62の印刷要求を実行するための要件として処理される場合、ドキュメントビューア53による要件処理によって強制的に機密印刷が
選択されると共に、グレー表示され、ユーザ52によってその選択を変更することができないように制御される。
ユーザ52によってその設定を変更することができないように制御される。ユーザ52が、設定域611内の詳細ボタンをクリックすると図38(B)のような画面が表示される。
図38(B)において、画面613は、要件として機密印刷が指定された場合の詳細な設定を示す画面であって、画面613の入力域614及び615は、本来、ユーザ52によって認証情報を設定するための入力域である。入力域614は、ユーザ52がユーザIDを入力する領域で、入力域615は、ユーザ52がパスワードを入力する領域である。ユーザ52は、プリンタとしてのデジタル複合機70にて、この画面613で入力したユーザID及びパスワードを入力することによって、印刷されたポータブルドキュメント63をデジタル複合機70から出力させることができる。
ユーザ52は、機密印刷によってポータブルドキュメント63が印刷されることを知ることができる。
図39は、要件としてラベルをスタンプとして印刷することが指定された場合の画面例を示す図である。図39において、画面620は、要件としてラベルをスタンプとして印刷することが指定された場合の画面であって、画面620の設定域621は、本来、ユーザ52によってスタンプを設定するための設定域である。ラベルをスタンプとして印刷することがユーザ62の印刷要求を実行するための要件として処理される場合、ドキュメントビューア53による要件処理によって強制的にスタンプの印字が設定されると共に、グレー表示され、ユーザ52によってその設定を変更することができないように制御される。
ユーザ52は、設定を変更することは禁止されるが、スタンプの印字が要件であることを印刷する前に確認することができる。この確認によって、ユーザ52は、実際に印刷を実行するかキャンセルするかを判断することもできる。
図40は、要件として目に見える透かし文字の印刷が指定された場合の画面例を示す図である。図40において、画面630は、要件として目に見える透かし文字の印刷が指定された場合の画面であって、画面630の設定域631は、本来、ユーザ52によって目に見える透かし文字の印刷を設定するための設定域である。目に見える透かし文字の印刷がユーザ62の印刷要求を実行するための要件として処理される場合、ドキュメントビューア53による要件処理によって強制的に目に見える透かし文字の印刷が設定されると共に、グレー表示され、ユーザ52によってその設定を変更することができないように制御される。
ユーザ52は、設定を変更することは禁止されるが、目に見える透かし文字の印刷が要件であることを印刷する前に確認することができる。この確認によって、ユーザ52は、実際に印刷を実行するかキャンセルするかを判断することもできる。
ユーザ52が、表示された画面630の設定域631のイメージスタンプの詳細を示すボタン632をクリックすると、図41で示されるような画面が表示される。
図41は、要件として識別パターンの印刷が指定された場合の画面例を示す図である。図41(A)は、要件として識別パターンの印刷が指定された場合の詳細を表示する画面例を示す図である。
図41(A)において、画面640の表示域641には識別パターンが印刷された場合のイメージ図が表示される。ユーザ52は、画面640での設定を変更することは禁止されるが、識別パターンの印刷要件であることを印刷する前に確認することができる。この確認によって、ユーザ52は、実際に印刷を実行するかキャンセルするかを判断することもできる。
識別パターンは、例えば、図41(B)に示すようなドットで印字される。図41(B)は、識別パターンを拡大した例を示す図である。図41(B)において、識別パターン646は、例えば、縦12ドット、横8ドットを間隔3ドット(つまり画像サイズは48pixel × 32pixel)の識別画像データである。
上下左右を識別するために右1列と下1行はすべてドットを打っておき、その他の11×7=77ドットに77ビットのコードをエンコードするようにすれば良い。ビットの値が1であればドットを打ち、0であればドットを打たないという単純なルールでこれを実現することができる。
図41(C)は、図41(B)に示す識別パターンのエンコードの例を示す図である。図41(C)において、図41(B)に示す識別パターン646は、上記エンコードによってビットパターン647となる。ドットが乱れたときに識別エラーが発生するため、誤り訂正符号を入れるようにしても良い。
例えば、ユーザ52がデジタル複合機70のプリンタ機能を利用して、ドキュメントビューア53からポータブルドキュメントを印刷する場合に、印刷の要件として機密印刷モードが指定される場合の図29のS3019での要件処理のシーケンスについて図42で詳細に説明する。図42は、機密印刷モードの要件処理シーケンスを示す図である。
図42において、ユーザ52がドキュメントビューア53に表示したポータブルドキュメント63に対して印刷要求をすると、ドキュメントビューア53は、ユーザ52に対してパスワードを要求する(S4001)。ユーザ52がパスワードを入力すると(S4002)、ドキュメントビューア53は、ユーザ52の端末51にインストールされているプリンタドライバ54に機密印刷モード及びパスワードを設定する(S4003)。そして、ドキュメントビューア53は、プリンタドライバ54に印刷指示を行う(S4004)。
プリンタドライバ54は、ドキュメントビューア53による印刷指示に応じて、PDL(Page Description Language)を生成して(S4005)、PDL(例えば、RPCS又はポストスクリプト)と、機密印刷モードと、パスワードとがデジタル複合機70へ送信する(S4006)。その後、プリンタドライバ54は、ドキュメントビューア53に対して印刷終了を通知する(S4007)。
一方、デジタル複合機70は、プリンタドライバ54から受信したPDLと、機密印刷モードと、パスワードとを一時的に内部のハードディスクに保存し(S4008)、ユーザ52によるパスワードの入力を待つ。
ユーザ52は、ポータブルドキュメント63をデジタル複合機70から出力させるために、デジタル複合機70にパスワードを入力する(S4009)。
デジタル複合機70は、ユーザ52から入力されたパスワードとプリンタドライバ54から受信したパスワードとを照合して、一致した場合に印刷処理を実行する(S4010)。一致しない場合、デジタル複合機70は、印刷処理を行わない。印刷処理の実行によって、ポータブルドキュメント63が印刷されたペーパードキュメント62が、デジタル複合機70から出力される(S4011)。
このような機密印刷モードの処理シーケンスによって、ユーザ52以外の他のユーザに、デジタル複合機70にて出力されたペーパードキュメント62を見られること、また、持って行かれることを防止することができる。
また、ユーザ52がデジタル複合機70のプリンタ機能を利用して、ドキュメントビューア53からポータブルドキュメントを印刷する場合に、印刷の要件として地紋印刷モードが指定される場合の図29のS3019での要件処理のシーケンスについて図42で詳細に説明する。図43は、地紋印刷モードの要件処理シーケンスを示す図である。
図43において、ドキュメントユーア53は、ユーザ52の端末51にインストールされているプリンタドライバ54に地紋印刷が可能か否かを確認する(S5001)。確認後、ドキュメントユーア53は、プリンタドライバ54に対して、地紋印刷モードと指定文字列とを送信し(S5002)、そして、印刷指示を行う(S5003)。
プリンタドライバ54は、地紋印刷モードと指定文字列とを受信し、印刷指示をドキュメントビューア53から受信すると、指定文字列に従った地紋入りPDLを生成する(S5004)。そして、プリンタドライバ54は、デジタル複合機70へ地紋入りのPDLを送信する(S5005)。
以下、セキュリティサーバ200によってアプリシステム400から提供される情報を企業のセキュリティポリシーに対応させる抽象化処理について詳述する。
[セキュリティサーバによる抽象化処理]
セキュリティサーバ200による抽象化処理を説明するために、各テーブル250から270は、図44から図48に示すようなデータを管理していると仮定する。
図44は、ユーザ権限レベルテーブルで管理されるデータ例を示す図である。図44において、ユーザ権限レベルテーブル250は、図5に示す構造体UserMapに従ってデータを管理する。例えば、「principalId」としての「GroupLeaders/Sales/Com」は、「entryType」が「group」であり、「levelId」が「manager」であることが示される。このように、他のデータについても同様に示される。
このようなユーザ管理レベルテーブル250は、例えば、XML(eXtensible Markup Language)で記述することによって、図45に示すようなXMLファイルでデータを管理しても良い。図45は、ユーザ権限レベルテーブルのXMLファイルを示す図である。
図45において、ユーザ権限レベルテーブル250は、図5に示すデータ構造251に従って、データ構造251に示す構造体名及び要素名がタグで示された階層的なデータ構造でユーザ権限レベルテーブル250のデータが記述される。例えば、<UserMapList>タグの下位層には、並列に<UserMap>タグによって複数のユーザに関するデータが記述され、各<UserMap>タグの下位層には、<principalId>タグと、<EntryType>タグと、<LevelId>タグとによって要素に対応させたデータが記述される。
図46は、ドキュメントプロファイル管理テーブルで管理されるデータ例を示す図である。図46において、ドキュメントプロファイル管理テーブル260は、図6に示す構造体データ261に従って、データ構造261に示す構造体名及び要素名がタグで示された階層的なデータ構造でドキュメントプロファイル管理テーブル260のデータが記述される。例えば、「docId」としての「0000000001」は、「docCategory」が「development」であり、「docLevel」が「secret」であり、「relatedPersons」が「Members/Dev/Com」であり、「zones」が「ANY」であり、「nondisclosure」が「2005/04/01」であり、「retention」が「2010/04/01」であり、「validity」が空欄であることが示される。このように、他のデータについても同様に示される。
このようなドキュメントプロファイル管理テーブル26は、ユーザ管理レベルテーブル250のようにXMLファイルとすることができるが、ドキュメント毎にテーブルのエントリを作成するため、テーブルの規模が大きくなるため、データベースで管理する方が良い。
図47は、ゾーン管理テーブルで管理されるデータ例を示す図である。図47において、ゾーン管理テーブル270は、図7に示す構造体データ271に従って、データ構造271に示す構造体名及び要素名がタグで示された階層的なデータ構造でゾーン管理テーブル270のデータが記述される。例えば、「id」としての「saleszone01」は、「name」が「Sales (Yokohama)」であり、「addressInfo」の「address」が「192.207.138.1」であり、「addressesInfo」の「addressType」が「IP」であり、「addressesInfo」の「netmask」が「255.255.255.0」であることが示される。更に、1つに「id」に対して複数の「addressInfo」を管理することができるため、「saleszone01」に対して更に、addressInfo」の「address」が「192.207.139.1」であり、「addressesInfo」の「addressType」が「IP」であり、「addressesInfo」の「netmask」が「255.255.255.0」であることが示される。このように、他のデータについても同様に示される。
このようなゾーン管理テーブル270は、例えば、XMLで記述することによって、図48に示すようなXMLファイルでデータを管理しても良い。図48は、ゾーン管理テーブルのXMLファイルを示す図である。
図48において、ゾーン管理テーブル270は、図7に示すデータ構造271に従って、データ構造271に示す構造体名及び要素名がタグで示された階層的なゾーン管理テーブル270のデータが記述される。例えば、<ZoneInfoTable>タグの下位層には、並列に<ZoneInfo>タグによって複数のゾーンに関するデータが記述され、各<ZoneInfo>タグの下位層には、<Id>タグと、<Name>タグと、<AddressInfo>タグとによって要素に対応させたデータが記述される。<AddressInfo>タグでは、更に、下位層を構成し、<Address>タグと、<AddressType>タグと、<Netmask>タグとによって要素に対応させたデータが記述される。<AddressInfo>タグは、<AddressInfo>タグの配下に複数構成しても良い。
そして、例えば、ポリシーファイル240には、図49及び図50に示されるようにアクセス制御ルールが記述される。図49及び図50は、ポリシーファイルに記述されるアクセス制御ルールを示す図である。
図49及び図50において、ポリシーファイル240では、<Policy>タグの記述701から</Policy>タグの記述702までにドキュメント毎にアクセス制御ルールが規定される。例えば、ポリシーファイル240では、<Rule>タグの記述703から</Rule>タグの記述704で文書属性に応じたルール1が示され、他<Rule>タグから</Rule>タグによって他の文書属性に応じたルール2及びルール3が示される。
ルール1の記述について説明し、ルール2及びルール3は、同様の記述方法であるためその説明を省略する。
ルール1は、<DocCategory>sales</DocCategory>及び<DocLevel>topsecret</DocLevel>の記述705は、文書カテゴリが「sales(販売部門)」であって、かつ、文書レベルが「topsecret(極秘文書)」である文書属性に対するアクセス制御ルールが規定されていることを示している。次に、記述705による文書属性において、<Ace>タグから</Ace>タグまでの記述710及び720において、ユーザ属性に応じたアクセス制御ルールが複数記述される。
記述710では、<UserCategory>RELATED_PERSON</UserCategory>、 <UserLevel>manager</UserLevel>及び<Zone>RESTRICTED</Zone>の記述711は、ユーザカテゴリが「RELATED_PERSON(関係者)」であって、かつ、ユーザレベルが「manager(管理者)」であって、かつ、ゾーンが「RESTRICTED(制限される)」であるユーザ属性に対するアクセス制御ルールが記述される。更に、記述720では、<UserCategory>RELATED_PERSON</UserCategory>及び<UserLevel>ANY</UserLevel>の記述721は、ユーザカテゴリが「RELATED_PERSON(関係者)」であって、かつ、ユーザレベルが「ANY(非限定)」であるユーザ属性に対するアクセス制御ルールが記述される。記述721ではゾーンは特に指定されない。このように、1つの文書属性に対して、複数のユーザ属性毎にアクセス制御ルールが記述される。
記述710では、<Operation>から</Operation>の記述712及び713は、アクセス制御ルールが適応されるオペレーションが示される。
記述712では、<id>read</id>の記述により、記述705に属するドキュメントが、記述711に属するユーザ52に対してそのドキュメントの読込(read)を許可することを示している。
また、記述713では、<id>print</id>の記述により、記述705に属するドキュメントが、記述711に属するユーザ52に対してそのドキュメントの印刷(print)を続いて記述される要件を処理することによって許可することを示している。
この記述713では、ドキュメントの印刷(print)時の要件として3つの要件が指定されている。<Requirement>、<id>private_access</id>及び</Requirement>の記述714により、印刷時の要件として「private_access(機密印刷モード)」が指定される。
また、<Requirement>、<id>print_alarm</id>及び<Supplement>"Printed by %u"</Supplement>の記述715により、印刷時の要件として、「print_alarm(警告の印刷)」が「Printed by %u」で指定される文字フォーマットによる警告文字で行われることが指定される。
更に、<id>identifiable_bg_pattern</id>及び<Supplement>dynamic_image</Supplement> の記述716により、印刷時の要件として、「identifiable_bg_pattern(識別パターンの印刷)」が「dynamic_image(動的画像)」で指定される識別パターン画像で地紋文字列によって行われることが指定される。
さて、上記したようなデータを前提として、例えば、「Com」会社の「Sales」部門の「Marketing」グループのリーダである「Taro Yamada」がIPアドレス「192.207.138.64」のPCから文書IDが「0000000003」の文書を印刷する場合、例えば、図51に示すような認証結果情報が、ユーザ管理サーバ300によってアプリシステム400に対して提供される。図51は、認証結果情報の一例を示す図である。
図51において、認証結果情報は、図12に示すデータ構造501に従って、例えば、「userId」として「Taro Yamada/Sales/Com」、「userName」として「Taro Yamada」、「groups」として「Members/Sales/Com」、「Marketing/Sales/Com」、「Employee/Com」、そして「GroupLeaders/Sales/Com」が示される。
「Taro Yamda」はこのような認証結果情報によって特定され、セキュリティサーバ200は許可処理を実行する。セキュリティサーバ200において、ユーザ権限レベルマッピング部232は、認証結果情報の「Taro Yamda」と、図44に示すユーザ権限レベルテーブル250とを照合する。「userId」又は「groups」の中で「GroupLeaders/Sales/Com」が最初に一致し、「manager」にマッピングされる(図4の(1))。
そして、ユーザ区分マッピング部233は、図46に示すドキュメントプロファイル管理テーブル260を参照して、「0000000003」の文書の「relatedPersons」の「Members/Sales/Com」と照らし合わせて関係者か否かを判定する。ユーザ区分マッピング部233は、「Taro Yamada」は「Members/Sales/Com」に所属しているため、関係者であると判定する(図4の(2))。
アクセス種別は、印刷(print)である(図4の(3))。
ゾーンマッピング部234は、例えば、図52に示すようなコンテキスト情報を受信する。図52は、コンテキスト情報の一例を示す図である。図52において、コンテキスト情報には、「ipAddress」として「192.207.138.64」、及び、「macAddress」として「02-36-55-22-78-01」が指定される。
ゾーンマッピング部234は、ドキュメントプロファイル管理テーブル160を参照して、「0000000003」の文書の「zones」として「saleszone01」と「saleszone02」を取得する。ゾーンマッピング部234は、更に、ゾーン管理テーブル270を参照して、「saleszone01」と「saleszone02」とに含まれるIPアドレス及びMACアドレスのリストを取得する。図52に示すコンテキスト情報のIPアドレス「192.207.138.64」が「saleszone01」に含まれるため、ゾーン内と判定する(図4の(4))。
ドキュメントセキュリティ属性マッピング部235は、例えば、図53に示すようなドキュメント識別情報を受信する。図53は、ドキュメント識別情報の一例を示す図である。図53において、ドキュメント識別情報には、「docId」として「0000000003」が指定される。この場合、「printId」及び「image」は指定されない。
ドキュメントセキュリティ属性マッピング部235は、ドキュメントプロファイル管理テーブル260を参照して、「0000000003」の文書の文書カテゴリが「sales」で、機密レベルが「topsecret」であると判定する(図4の(5))。
上記のような各マッピング部232、233及び234でのマッピング処理によって、ユーザ権限レベルとして「manager」、関係者区分として「関係者」、アクセス種別として「print」、ゾーン区分として「ゾーン内」、文書カテゴリとして「sales」、機密レベルとして「topsecret」という抽象的なパラメータにマッピングすることができる。
この抽象的なパラメータに基づいて、ポリシーベースアクセス制御判断部241が、図49に示されるポリシーファイル240で記述されるアクセス制御ルール(ポリシー)に従って、許可されるか否かを判定すると、記述711及び713により、「sales」の「topsecret」は関係者の「manager」クラスに「print」を許可している。ただし、「private_access(機密印刷モード)」と、「print_alarm(警告の印刷)」と、「identifiable_bg_pattern(識別パターンの印刷)」とが要件として規定されているため、図54に示すようなアクセス制御判断結果を返す。
図54は、判断結果情報の一例を示す図である。図54において、判断結果情報では、「allowed」として「true(許可)」が設定され、「requirements」には、「requirement」として「private_access(機密印刷モード)」が指定され、この要件に対する「supplements(補足情報)」、「data」及び「alternatives」は指定されない。また、「requirement」として「print_alarm(警告の印刷)」が指定され、この要件に対する「supplements(補足情報)」として「"Printed by Taro Yamda"」が指定され、「data」及び「alternatives」は指定されない。更に、「requirement」として「identifiable_bg_pattern(識別パターンの印刷)」が指定され、この要件に対する「supplements(補足情報)」として「dynamic_image(動的画像)」及び「data」として[binary image data](バイナリデータによる実際の動的画像)が指定され、「alternatives」は指定されない。
ここで、ポリシーファイル240のアクセス制御ルールでは、「Printed by %u」と記述されているが、補正処理により%uの部分がTaro Yamadaに置き換えられる。
また、ポリシーファイル240のアクセス制御ルールにおいて「dynamic_image」と記述されていて、アクセス種別が「print」の場合には、図55に示すようなプリントプロファイル管理テーブル280に新しいプリントプロファイルのエントリを作成する。図55は、プリントプロファイル管理テーブルの一例を示す図である。図55において、新しいプリントプロファイルのエントリを作成することによって、「printId」を取得する。そして、その「printId」をエンコードして識別画像データにする.その識別画像データを上記の「data」に[binary image data]として格納する。
識別画像データは、例えば、印刷時に紙面に重ねて印刷され、後で識別したり追跡したりするために利用することができる。図56は、印刷された識別パターンの例を示す図である。図56に示すように、例えば、図41(B)に示されるような識別パターン646が重ねられて印刷される。
もしも同じ文書に同じ端末51から別のユーザ52、例えば、図57に示すような認証結果情報によって特定される「Hanako Satoh」が印刷を要求した場合について説明する。図57は、認証結果情報のその他の例を示す図である。
図57において、認証結果情報は、図12に示すデータ構造501に従って、例えば、「userId」として「Hanako Satoh/Sales/Com」、「userName」として「Hanako Satoh」、「groups」として「Members/Sales/Com」、「Marketing/Sales/Com」、そして「Employee/Com」が示される。
「Hanako Satoh」はこのような認証結果情報によって特定され、セキュリティサーバ200は許可処理を実行する。許可処理の実行によって、ユーザ権限レベルは「regular」、関係者区分は「関係者」、アクセス種別は「print」、ゾーン区分は「ゾーン内」、文書カテゴリは「sales」、機密レベルは「topsecret」となり、図49に示されるポリシーファイル240で記述されるアクセス制御ルール(ポリシー)に従って判定すると、アクセス制御判断結果は、許可されないことになる。
また、もしも「Taro Yamada」が「0000000001」の文書を参照(read)しようとしたとすると、該当するポリシーが規定されておらず、アクセス制御判断結果は、許可されないことになる。
また、先に「Taro Yamada」が印刷した紙をデジタル複合機70で複写する場合、デジタル複合機70は、紙面をスキャンした画像データに基づいて、セキュリティサーバ200に対してアクセス制御の問い合わせを行う。
セキュリティサーバ200は、デジタル複合機70から図58(A)又は図58(B)に示すようなドキュメント識別情報を受信する。
図58は、ドキュメント識別情報の例を示す図である。図58(A)は、画像データそのものをセキュリティサーバへ送信する場合のドキュメント識別情報の一例を示す図である。図58(A)において、「docId」及び「printId」は指定されず、「image」に画像データがバイナリ([binary image data])が設定される。
図58(B)は、画像データをデコードしてセキュリティサーバへ送信する場合のドキュメント識別情報の一例を示す図である。図58(B)において、「docId」及び「image」は指定されず、「printId」にデジタル複合機70でエンコードされたバイナリの画像データ([binary image data])が設定される。
セキュリティサーバ200は、図58(A)に示すようなバイナリの画像データをデジタル複合機70から受信した場合、「printId」として「p000000001」を取得する。その「printId」に基づいて、プリントプロファイルを参照して、「docId」として「0000000003」を取得する。そして、セキュリティサーバ200は、「Taro Yamada」による「print」の場合と同様に、アクセス種別が「copy」を示す場合のポリシーに従ってアクセス制御判断を行う。
本発明によれば、例えば、ポータブルドキュメント63を印刷する際に、印刷したユーザ52の名前を印字することを要件とするようなポリシーの記述において、つまり、その印刷というオペレーションを行うことによって、ポータブルドキュメント63がドキュメントビューア53の管理下から紙への出力されてしまう際に、その出力後も印刷しようとするユーザ52に対して情報漏洩の抑止効果を高めるように規定することによりポータブルドキュメント63のセキュリティを維持することができる。
また、ポリシーの記述において、紙を複写する際に、複写しようとするユーザ52のユーザ名を印字するという要件を規定することができるため、複写したユーザ52のユーザ名を紙に入れることによりデジタル複合機70から出力されてしまう複製されたペーパードキュメント62のセキュリティを維持することができる。
また、ポリシーの記述において、サーバドキュメント61を文書管理システム100から読み出す際にログを記録するような要件を規定できるため、読み出した記録を残すことができる。従って、読み出したユーザ52に対して情報漏洩の抑止をしてセキュリティを維持することができる。
このようなオペレーションを許可するための要件として、ポリシーの記述において、そのオペレーションを行った後もセキュリティの維持を可能とするような処理を行わせるように規定することができるため、ドキュメント60に対するオペレーションの前後で一貫したセキュリティの確保を実現できる。
従来のドキュメント60に対するセキュリティでは、ドキュメント60に対してオペレーションを行った後では、セキュリティの維持をすることができなかった。
しかしながら、本発明によれば、ドキュメント60に対してオペレーションを行った後においても、セキュリティを一貫して維持することができる。
以下に、ポリシーファイル240で規定されるアクセス制御ルールにおけるオペレーション、要件、補足情報について詳述する。
[オペレーション、要件、補足情報に関する詳細]
[1 オペレーション詳細]
サーバドキュメント61、ペーパードキュメント62、ポータブルドキュメント63について同じ名称のオペレーションが存在することがあるため、オペレーション識別子の先頭には以下のプレフィックスをつけて区別するようにする。
・サーバドキュメント61のオペレーション: sdOpe_xxxx
・ペーパードキュメント62のオペレーション: ppOpe_xxxx
・ポータブルドキュメント63のオペレーション: pdOpe_xxxx
xxxxはオペレーションの意味をあらわす英単語とする。以下、各節のタイトルはオペレーションの識別子である。
[1−1 sdOpe_store]
例えば、文書管理サーバ100へのドキュメントの保存を要求するオペレーションである。文書管理サーバ100、デジタル複合機70等のドキュメントボックスなど、ドキュメントファイルのセキュリティ管理が可能なリポジトリ(格納庫)にドキュメントを保存するオペレーションである(新規作成又は新規登録と呼ばれることもある)。
適用可能な要件として record_audit_data、 explicit_authorization、 encryption、 integrity_protection、 show_alarm等がある。各要件の詳細は後述される。
[1−2 sdOpe_prop_read]
例えば、文書管理サーバ100に保存されているドキュメントのプロパティ参照を要求するオペレーションである。ドキュメントのコンテンツを参照(取得)するのではなく、ドキュメントのファイルサイズや作成日時、所有者といった属性情報を参照するオペレーションである。このオペレーションが許可されない場合、ドキュメントの存在そのものを知ることができない。
適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 show_alarm等がある。各要件の詳細は後述される。
[1−3 sdOpe_read]
例えば、文書管理サーバ100に保存されているドキュメントの参照(読み取り)を要求するオペレーションである。文書管理サーバ100のドキュメントファイルのコンテンツを参照(ダウンロード)するオペレーションである。プロテクトされたドキュメントファイルをダウンロードすることに相当する。
適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 show_alarm等がある。各要件の詳細は後述される。
このオペレーションに対して以下を補足する。
ダウンロードされたドキュメントファイルのことをポータブルドキュメント63と呼ぶ。ポータブルドキュメント63へのアクセスをコントロールする必要があるため、sdOpe_readというオペレーションでダウンロードされるポータブルドキュメント63は、
プロテクトされたドキュメントファイルとなる。
[1−4 sdOpe_get_org]
例えば、文書管理サーバ100に保存されているドキュメントのオリジナルファイルの参照(読み取り)を要求するオペレーションである。sdOpe_readはプロテクトされたドキュメントファイルのダウンロードに相当し、このsdOpe_get_orgはプロテクトされていないオリジナルのドキュメントファイルのダウンロードに相当する。
適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 show_alarm等がある。各要件の詳細は後述される。
[1−5 sdOpe_revise]
例えば、文書管理サーバ100に保存されているドキュメントの改訂を要求するオペレーションである。文書管理サーバ100に保存されているドキュメントをエディタで開いて編集し改訂するオペレーションや、文書管理サーバ100に保存されているドキュメントを差し替える(保存しなおす)オペレーションである。
適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 versioning、 show_alarm等がある。各要件の詳細は後述される。
[1−6 sdOpe_delete]
例えば、文書管理サーバ100に保存されているドキュメントの削除を要求するオペレーションである。文書管理サーバ100に保存されているドキュメントを削除するオペレーションである。
適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 complete_deletion、 show_alarm等がある。各要件の詳細は後述される。
[1−7 pdOpe_read]
ポータブルドキュメント63の参照(オープン)を要求するオペレーションである。ポータブルドキュメント63のファイルを開くオペレーションである。
適用可能な要件としてrecord_audit_data、 explicit_authorization、 multi_authentication、 show_alarm等がある。各要件の詳細は後述される。
[1−8 pdOpe_print]
ポータブルドキュメント63の印刷を要求するオペレーションである。ファイルの内容を印刷するオペレーションである。
適用可能な要件としてrecord_audit_data、 explicit_authorization、 private_access、 record_image_data、 embed_trace_info、 show_label、 visible_watermark、 anti_copy_watermark、 trusted_bg_pattern、 identifiable_bg_pattern、 show_alarm、 print_alarm等がある。各要件の詳細は後述される。
[1−9 pdOpe_send_fax]
ポータブルドキュメントのファクス送信を要求するオペレーションである。ファイルの内容を直接ファクスで送信するオペレーションである。ファクスに対応するプリンタオブジェクトで印刷する処理に相当する。
適用可能な要件としてrecord_audit_data、 explicit_authorization、 address_restriction、 private_send、 record_image_data、 show_label、 visible_watermark、 show_alarm、 print_alarm等がある。各要件の詳細は後述される。
[1−10 ppOpe_copy]
ペーパードキュメントの複写を要求するオペレーションである。紙のドキュメントを複写機で複写するオペレーションである。
適用可能な要件としてrecord_audit_data、 explicit_authorization、 show_label、 show_operator、 owner_only、 record_image_data、 show_alarm、 print_alarm等がある。各要件の詳細は後述される。
[1−11 ppOpe_send_fax]
ペーパードキュメントのファクス送信を要求するオペレーションである。紙のドキュメントをファクスで送信するオペレーションである。
適用可能な要件としてrecord_audit_data、 explicit_authorization、 address_restriction、 private_send、 record_image_data、 show_label、 visible_watermark、 show_alarm、 print_alarm等がある。各要件の詳細は後述される。
[1−12 ppOpe_scan]
ペーパードキュメントのスキャンを要求するオペレーションである。紙のドキュメントをスキャナで読み取り、電子ファイル化するオペレーションである。
適用可能な要件としてrecord_audit_data、 explicit_authorization、 record_image_data、 digital_watermark等がある。各要件の詳細は後述される。
[2 要件詳細]
以下に各要件について説明する。各節のタイトルは要件の識別子である。
要件によって処理の仕方が異なる。要件の処理は、アプリシステム400が行うことになる。
[2−1 record_audit_data]
ログを記録する。例えば、デジタル複合機70でコピーをする際にページごとにログを記録するようにしてもよいし、コピーした原稿についてセキュリティIDごとにまとめてログを記録するようにしてもよい。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
[2−2 explicit_authorization]
文書管理責任者による許可を必要とする。この要件がポリシーで規定されている場合、このオペレーションに対する明示的な許可がセキュリティサーバ200に対して行われていなければ「不許可」となる。セキュリティサーバ200は、許可処理の処理中に取得した判断結果にこの要件が規定されていることを識別したら、許可証が発行されているか否かを確認し、発行されていれば要件の中からexplicit_authorizationを取り除いて、allowed = trueと他の要件を判断結果としてアプリシステム400に返す。許可証が発行されていなければ、allowed = falseをアプリシステム400に返す。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
[2−3 encryption]
電子文書を暗号化する。この要件がポリシーで規定されている場合、サーバ管理者にその電子文書の内容を読まれては困るということを意味している。したがって、アプリシステム400はサーバ管理者でも解読できないように暗号化しなければならない。つまり、暗号を解く復号鍵はアプリシステム400のサーバ管理者に利用されないように格納しなければならない。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
[2−4 integrity_protection]
電子文書の完全性を確保する(原本性を保障する)。この要件がポリシーで規定されている場合、アプリシステム400は、電子文書の原本が改ざんされないように保護しなければならない。アプリシステム400が独自に文書保護領域に保存してもよいが、セキュリティサーバ200に原本の保存を任せるようにしても良い。
セキュリティサーバ200は、受け取った原本(PDFに変換する前のファイル)と変換した保護PDFファイルを文書保護領域へ保存する。保存した原本IDは、ドキュメントプロファイル管理テーブル260のアプリデータとして記録しておく。
セキュリティサーバ200に文書保護領域がセットアップされていない場合、文書保護領域への保存はエラーとなる。セキュリティサーバ200は、深刻なエラーが発生したとして、セキュリティレベルの高いログを記録する。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
要件の処理では、アプリシステム400が文書保護領域への保存をセキュリティサーバ200に要求する。セキュリティサーバ200は、要求されたら文書保護領域へ保存する。
[2−5 multi_authentication]
電子文書へのアクセスに多段階認証を求める。
この要件がポリシーで規定されている場合、アプリシステム400は通常のユーザ認証に加えて、例えば指紋認証や虹彩認証などの、多段階のユーザ認証を行わなければならない。どのような認証方式を用いるかはアプリシステム400に任せられる。あらかじめもう一段の認証をパスしていなければアクセス不許可とするか、もしくはこの要件が返されたらもう一段の認証をユーザに求めるようにするか、タイミングはどちらでも良い。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
[2−6 versioning]
電子文書のバージョン管理を行う。
この要件がポリシーで規定されている場合、アプリシステム400は電子文書を改訂する際に上書き保存はせず、バージョン(版)管理を行わなければならない。アプリシステム400がバージョン管理の機能を提供していない場合には要件が満たせないものとして文書の改訂を行ってはならない。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
[2−7 complete_deletion]
電子文書の完全削除を行う。
この要件がポリシーで規定されている場合、アプリシステム400は電子文書のエントリをただ単に削除するだけでなく、その電子文書が記録されていたディスク領域にランダムなデータを上書きするなどして完全消去処理を行わなければならない。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
[2−8 private_access]
機密印刷モードを使用する。
印刷出力された紙を他人に持ち去られないよう、印刷した本人であることをプリンタのオペパネで確認した上で印刷出力する。
この要件がポリシーで規定されている場合、アプリシステム400は機密印刷モードを使用して印刷しなければならない。機密印刷モードをサポートしていないプリンタが相手の場合には印刷させない。
機密印刷モードをサポートしていないプリンタでも、他人に印刷文書が持ち去られる可能性が低い環境では印刷できるようにしたいと考えるかもしれない。そのようなポリシーにしたい場合にはprivate_accessの代替要件としてshow_alarmを指定するようにして、警告だけした上で印刷させるようにすると良い。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
[2−9 record_image_data]
イメージログの記録を行う。
印刷イメージ、複写イメージをそのまま記録して保持する。
この要件が印刷の要件としてポリシーで規定されている場合、アプリシステム400はイメージデータの記録を印刷出力先のプリンタアダプタに指示して印刷する。
複写の要件としてポリシーで規定されている場合、複写した原稿のイメージをデジタル複合機70内のハードディスク(ドキュメントボックス)に格納する。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
[2−10 embed_trace_info]
追跡情報を埋め込んで印刷する。印刷する際に、その印刷物の識別情報を紙面に埋め込んで出力する。追跡情報としては、現状は二次元バーコードを利用する。
この要件がポリシーで規定されている場合、セキュリティサーバ200は許可処理でembed_trace_infoの要件とともに追跡情報を動的に生成しなければならないことを示す補足情報(supplement)を返す。つまり、dynamic_imageを指定する補足情報(supplement)を返す。セキュリティサーバ200は、このdynamic_imageの補足情報が指定されていることを識別すると、ドキュメントプロファイル管理テーブル260から埋め込み用イメージを取得し、セキュリティサーバ200の許可処理の戻り値で、embed_trace_infoの要件とともに、その埋め込みイメージを補足情報(supplement)として返す。補足情報のdynamic_imageの節を参照のこと。
アプリシステム400は受け取った埋め込みイメージを印刷紙面上に埋め込む。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
要件の処理では、セキュリティサーバ200がドキュメントプロファイル管理テーブル260から埋め込みイメージを取得し、アプリシステム400が実際に埋め込みイメージを印刷時に埋め込む。
[2−11 show_label]
「秘」などのラベルをスタンプとして印刷する。この要件がポリシーで規定されている場合、セキュリティサーバ200は許可処理の戻り値でshow_labelの要件とともにラベルスタンプのビットマップデータを補足情報(supplement)として返す。どういうドキュメントにはどのようなスタンプを印刷するのか、セキュリティサーバ200にあらかじめ設定しておかなければならない。ポリシーにはラベルスタンプのID、スタンプを押す位置、に関する情報が要件の補足情報(supplement)として規定されており、そのIDに対応するビットマップファイルがセキュリティサーバ200のローカルハードディスクに保存されている。セキュリティサーバ200はビットマップファイルを読み出してバイト配列の補足情報(supplement)にして上位に渡す。
ポリシーに規定されているラベルスタンプIDに対応するビットマップファイルが存在しない場合には、ラベルIDのみ要件の補足情報(supplement)に含め、ビットマップデータなしで要件が返される。補足情報のstatic_imageの節を参照のこと。
スタンプイメージは動的に生成されることを想定していない。セキュリティサーバ200は受け取った要件と補足情報(supplement)をそのままアプリシステム400に渡す。アプリシステム400は、受け取ったスタンプイメージを重ねて印刷する。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
要件の処理では、スタンプイメージをセキュリティサーバ200が提供し、アプリシステム400(デジタル複合機70)が紙にラベルスタンプを押す。
[2−12 visible_watermark]
紙面の背景に目に見える形で透かし文字を印刷する。この要件がポリシーで規定されて
いる場合、セキュリティサーバ200は許可処理の戻り値でvisible_watermarkの要件とともに透かしとして印刷する文字列フォーマットを補足情報(supplement)として返す。どういうドキュメントにはどのような文字列フォーマットとするのか、ポリシーの中で要件の補足情報(supplement)として規定しておかなければならない。セキュリティサーバ200は受け取った要件、補足情報(supplement)をそのままアプリシステム400に渡す。アプリシステム400は受け取った文字列フォーマットに従って透かし文字列を生成し、印刷する。補足情報のstring_formatの節を参照のこと。
必要な補足情報は、 string_format、colorである。
同時に指定できない要件(競合する要件)は、 anti_copy_watermark、 trusted_bg_pattern、 identifiable_bg_patternである。
要件の処理では、文字列フォーマットをセキュリティサーバ200が提供し、アプリシステム400(デジタル複合機70)が紙に文字列を印字する。
[2−13 anti_copy_watermark]
紙面の背景に複写すると浮き出る形で透かし文字を印刷する。この要件がポリシーで規
定されている場合、セキュリティサーバ200は許可処理の戻り値でanti_copy_watermarkの要件とともに透かしとして印刷する文字列フォーマットを補足情報(supplement)として返す。どういうドキュメントにはどのような文字列フォーマットとするのか、ポリシーの中で要件の補足情報(supplement)として規定しておかなければならない。セキュリティサーバ200は受け取った要件、補足情報(supplement)をそのままアプリシステム400に渡す。アプリシステム400は受け取った文字列フォーマットに従って透かし文字列を生成し、印刷する。補足情報のstring_formatの節を参照のこと。
必要な補足情報は string_format、colorである。
同時に指定できない要件(競合する要件)は、 visible_watermark、 trusted_bg_pattern、 identifiable_bg_patternである。
要件の処理では、文字列フォーマットをセキュリティサーバ200が提供し、アプリシステム400が紙に文字列を印字する。
[2−14 trusted_bg_pattern]
改ざん検出用背景パターンを印刷する。
[2−15 identifiable_bg_pattern]
紙面の背景に識別パターンを印刷する。識別パターンは開発中の背景ドットパターンを想定している。
この要件がポリシーで規定されている場合、セキュリティサーバ200は許可処理でidentifiable_bg_patternの要件と補足情報として動的に情報を生成しなければならないという情報を返す。セキュリティサーバ200は動的イメージ生成(補足情報 dynamic_image)が指定されていることを識別すると、ドキュメントプロファイル管理テーブル260から識別パターンを取得し、許可処理の戻り値で、identifiable_bg_patternの要件とともに、その識別パターンを補足情報(supplement)として返す。補足情報のdynamic_imageの節を参照のこと。
アプリシステム400は受け取った識別パターンを印刷紙面上に背景として印刷する。
必要な補足情報はdynamic_imageである。
同時に指定できない要件(競合する要件)は、visible_watermark、anti_copy_watermark、 trusted_bg_patternである。
要件の処理では、セキュリティサーバ200がドキュメントプロファイル管理テーブル260から識別パターンを取得し、アプリシステム400が実際に識別パターンを印刷時に背景に入れる。
[2−16 show_alarm]
警告を表示する。「極秘文書のため取り扱いに注意すること」というような警告を表示してユーザに意識付けをする。この要件はディスプレイやオペパネに表示することを意図している。印刷する紙の上に表示する場合には別の要件print_alarmを使用する。どういうドキュメントにはどのような文字列を表示するのか、ポリシーの中で要件の補足情報(supplement)として規定しておかなければならない。セキュリティサーバ200は、受け取った要件及び補足情報(supplement)をそのままアプリシステム400に渡す。アプリシステム400は受け取った文字列フォーマットに従って文字列を生成し、表示する。
必要な補足情報は、 string_formatである。
同時に指定できない要件(競合する要件)はない。
要件の処理では、セキュリティサーバ200が表示する文字列フォーマットを提供し、アプリシステム400が表示する。
[2−17 print_alarm]
警告を印刷する。「RRR Internal Use Only」というような警告を印刷してユーザに意識付けをする。この要件は紙に印刷することを意図している。ディスプレイやオペパネに表示する場合には別の要件show_alarmを使用する。
どういうドキュメントにはどのような文字列を印刷するのか、ポリシーの中で要件の補足情報(supplement)として規定しておかなければならない。が表示する文字列フォーマットを提供し、アプリシステム400が表示する。は受け取った要件、補足情報(supplement)をそのままアプリシステム400に渡す。アプリシステム400は受け取った文字列フォーマットに従って文字列を生成し、印刷する。
必要な補足情報は、 string_format、 string_positionである。
同時に指定できない要件(競合する要件)はない。
要件の処理では、セキュリティサーバ200が印刷する文字列フォーマットを提供し、アプリシステム400が印刷する。
[2−18 private_send]
親展送信モードを使用する。ファクスで送信した紙を他人に持ち去られないよう、ファクスの親展送信モードを使用する。親展モードをサポートしていないファクスに対しては送信処理を行わない。
親展モードをサポートしていないファクスでも、他人にファクス文書が持ち去られる可能性が低い環境では送信できるようにしたいと考えるかもしれない。そのようなポリシーにしたい場合にはprivate_receiveの代替要件としてshow_alarmを指定するようにして、警告だけした上で送信させるようにすると良い。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
[2−19 address_restriction]
ファクスで送信できる宛先を制限する。
[identifiable_bg_pattern]
[2−20 show_operator]
[identifiable_bg_pattern]
複写したユーザ名を複写した紙の余白に印字する。この要件がポリシーで規定されている場合、セキュリティサーバ200は許可処理の戻り値でshow_operatorの要件とともに印字する文字列フォーマットを補足情報(supplement)として返す。どういうドキュメントにはどのような文字列を印字するのか、ポリシーの中で要件の補足情報(supplement)として規定しておかなければならない。
セキュリティサーバ200は、受け取った要件と補足情報(supplement)をそのままアプリシステム400に渡す。アプリシステム400は、受け取った文字列フォーマットに従って文字列を生成し、複写した紙に印字する。
必要な補足情報は、string_formatである。
同時に指定できない要件(競合する要件)はない。
要件の処理では、印字文字列フォーマットはポリシーに規定されているものをセキュリティサーバ200が提供し、アプリシステム400がそのフォーマットに従って複写時に印字する。
[2−21 owner_only]
印刷した本人のみ複写可能にする。この要件がポリシーで規定されている場合、セキュリティサーバ200は許可処理の戻り値でowner_onlyの要件を返す。セキュリティサーバ200は、この要件を識別すると、複写原稿を印刷したユーザのIDをドキュメントプロファイル管理テーブル260から取得し、複写しようとしているユーザと印刷したユーザとが一致しているかどうか確認する。一致していれば、owner_onlyの要件を取り除いてセキュリティサーバ200の許可処理の結果として返す。一致していない場合にはセキュリティサーバ200の許可処理の結果としてallowed = falseを返す。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない。
要件の処理では、セキュリティサーバ200によって本人でなければ「不許可」が返される。
[2−22 unreadable_mask]
読めないようにマスクする。複写したときに、その紙が複写してはならないものであったことを利用者に気づかせるために、読めないように全面にグレーでマスクして複写出力する要件。
必要な補足情報はない。
同時に指定できない要件(競合する要件)はない(ただし指定してもshow_labelなど無意味になることがある)。
[2−23 digital_watermark]
画像データに電子透かしを入れる。この要件がポリシーで規定されている場合、セキュリティサーバ200は許可処理の戻り値でdigital_watermarkの要件とともに電子透かしとして埋め込む文字列フォーマットを補足情報(supplement)として返す。どういうドキュメントにはどのような文字列フォーマットとするのか、ポリシーの中で要件の補足情報(supplement)として規定しておかなければならない。セキュリティサーバ200は補足情報(supplement)をそのままアプリシステム400に渡す。アプリシステム400は受け取った文字列フォーマットに従って埋め込む文字列を生成し、電子透かしとしてドキュメントの画像データに印刷する。
補足情報のstring_format、watermark_typeの節を参照のこと。
必要な補足情報は string_format, watermark_typeである。
同時に指定できない要件(競合する要件)は anti_copy_watermark, trusted_bg_pattern, identifiable_bg_patternである。
要件の処理では、文字列フォーマットをセキュリティサーバ200が提供し、アプリシステム400がそのフォーマットに従って電子透かしを埋め込む。
[3 補足情報詳細]
要件には補足情報が必要となることがある。補足情報の指定の仕方を以下に定義する。各節のタイトルは補足情報の識別子である。
[3−1 static_image]
補足情報として固定画像データを指定する場合に使用する。固定画像データとしては例えばラベル表示要件("show_label")に使用するスタンプ画像などがある。
データそのものはポリシーファイル240に格納されないため、固定画像データファイルを特定する識別ラベルをポリシーファイル240内で指定する。識別ラベルの指定は先頭に"ref:"をつける。
補足情報の書式はref:[file_id]である。
例えば、ポリシーファイル240内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>show_label</Id>
<Supplement>
<Id>static_image</Id>
<Data>ref:STAMP_IMAGE_01</Data>
</Supplement>
上記のようにポリシーファイル240で指定されているとき、セキュリティサーバ200の許可処理メソッドでポリシー判定結果を返す際には以下のようにして返す。
DecisionInfo.requirements[x].requirement = "show_label";
DecisionInfo.requirements[x].supplements[y].name = "static_image";
DecisionInfo.requirements[x].supplements[y].value = "z";
DecisionInfo.requirements[x].dataz = STAMP_IMAGE_01に対応する画像データ(バイナリデータ);
ただしx、y、zは数字である。
上記のように、セキュリティサーバ200は補足情報として"ref:"が指定されると、そこに記載されている識別ラベルに対応するファイルを読み出してバイナリデータとして補足情報として組み込む処理を行う。
[3−2 dynamic_image]
補足情報として動的な画像データを指定する場合に使用する。動的に生成される画像データとしては例えば追跡情報埋め込み要件("embed_trace_info")に使用するバーコード画像や、識別パターン要件("identifiable_bg_pattern")に使用する識別パターン画像などがある。
これらは対象となっている文書によって動的に画像データが生成されるため、ポリシーファイル240の中でその内容を記述することはできない。ポリシーファイル240では補足情報として動的に生成する情報のタイプ(例えば文書ID、ユーザIDといった情報のタイプ)を指定する。
補足情報の書式は dyn:[info_type]である。info_typeには"SecId"のみ指定可能である。
例えば、ポリシーファイル240内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>embed_trace_info</Id>
<Supplement>
<Id>dynamic_image</Id>
<Data>dyn:SecId</Data>
</Supplement>
上記のようにポリシーファイル240で指定されているとき、セキュリティサーバ200の許可処理メソッドでポリシー判定結果を返す際には何も処理せず、以下のようにして返す。
DecisionInfo.requirements[x].requirement = "embed_trace_info";
DecisionInfo.requirements[x].supplements[y].name = "dynamic_image";
DecisionInfo.requirements[x].supplements[y].value = "dyn:SecId";
ただしx、yは数字である。
そして、判断結果情報を受け取ったセキュリティサーバ200は、必要な画像データを動的に生成し、セキュリティサーバ200の許可処理の結果として以下を返す。
DecisionInfo.requirements[x].requirement = "embed_trace_info";
DecisionInfo.requirements[x].supplements[y].name = "dynamic_image";
DecisionInfo.requirements[x].supplements[y].value = "z";
DecisionInfo.requirements[x].dataz = 動的に生成した画像データ(バイナリデータ);
ただしx、y、zは数字である。
[3−3 image_position]
補足情報として画像の埋め込み位置を指定する場合に使用する。画像を全面に埋め込むのではなく、一部に埋め込む要件("show_label"など)で指定する。全面に埋め込む場合(タイル形式で埋め込む場合)は要件が異なる("identifiable_bg_pattern"など)ものとなる。
ポリシーファイル240では埋め込み位置を識別ラベルで指定する。
補足情報の書式は [position_id]である。position_idはupper_right、lower_right、upper_left、lower_left、centerの5種類である。
例えば、ポリシーファイル240内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>show_label</Id>
<Supplement>
<Id>image_position</Id>
<Data>upper_right</Data>
</Supplement>
セキュリティサーバ200は、この補足情報をそのまま判断結果情報に格納して返す。
[3−4 string_format]
補足情報として文字列の書式を指定する場合に使用する。ウォーターマーク("visible_watermark")などの要件で指定する。
ポリシーファイル240内では書式を以下のようにして指定する。
補足情報の書式: ["format_string"]
format_stringは以下の組み合わせと任意の文字列で指定する。
"%da" IPアドレス(10進数表記 133.139.208.69等)
"%ha" IPアドレス(16進数表記 BEAC143F等)
"%8u" ユーザ名(アカウント名)、数字で桁数を指定することができる(数字は無指定でも良い)。
"%d1" 日時(YYMMDD)
"%d2" 日時(YYMMDD HH:mm)
"%d3" 日時(YYMMDD HH:mm:ss)
"%id" 文書ID(未サポート)
"%lv" 機密レベルID(未サポート)
"%ca" 文書カテゴリID(未サポート)
例えば、ポリシーファイル240内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>visible_watermark</Id>
<Supplement>
<Id>string_format</Id>
<Data>%8u %d2 DO NOT COPY</Data>
</Supplement>
セキュリティサーバ200は、この補足情報をそのまま判断結果情報に格納して返す。
要件によっては最大文字数に制限がある(例えばvisible_watermarkは32文字)。最大文字数を超えた分の文字は使用されない。
[3−5 string_position]
補足情報として文字列の埋め込み位置を指定する場合に使用する。文字列を背景に埋め込むのではなく、一部に埋め込む要件("print_alarm"など)で指定する。背景に埋め込む場合は要件が異なるもの("visible_watermark"など)となる。
ポリシーファイル240内では埋め込み位置を識別ラベルで指定する。
補足情報の書式は [position_id]である。position_idは upper_right、lower_right、upper_left、lower_left、upper_center、 lower_center、 upper_lower_centerの6種類である。
例えば、ポリシーファイル240内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>print_alarm</Id>
<Supplement>
<Id>string_position</Id>
<Data>upper_lower_center</Data>
</Supplement>
セキュリティサーバ200は、この補足情報をそのまま判断結果情報に格納して返す。
[3−6 color]
補足情報として色の指定をする場合に使用する。複写抑止地紋("anti_copy_watermark")などの要件で指定する。
ポリシーファイル240内では以下のようにして指定する。
補足情報の書式は [color_id]である。color_idは cyan、magentaのいずれかを指定する。
例えば、ポリシーファイル240内では以下のように指定する。
<Ace>
<Operation>
<Id>pd_print</Id>
<Requirement>
<Id>anti_copy_watermark</Id>
<Supplement>
<Id>color</Id>
<Data>cyan</Data>
</Supplement>
セキュリティサーバ200は、この補足情報をそのまま判断結果情報に格納して返す。
[3−7 watermark_type]
補足情報として透かしの種別の指定をする場合に使用する。電子透かし("digital_watermark")などの要件で指定する。
ポリシーファイル240内では以下のようにして指定する。
補足情報の書式は、 [watermak_type_id]である。watermark_type_idは、traceability、 integrity、 steganographyを指定する。traceabilityは追跡目的での電子透かしを指定し、integrityは改ざん検出目的での電子透かしを指定し、steganographyは情報を伝達する目的での電子透かしを指定する。
例えば、ポリシーファイル240内では以下のように指定する。
<DspAce>
<DspOperation>
<Id>pp_scan</Id>
<DspRequirement>
<Id>digital_watermark</Id>
<DspSupplement>
<Id>string_format</Id>
<Data>%u %d</Data>
</DspSupplement>
<DspSupplement>
<Id>watermark_type</Id>
<Data>traceability</Data>
</DspSupplement>
セキュリティサーバ200は、この補足情報をそのまま判断結果情報に設定して返す。
上記より、本発明によれば、セキュリティサーバ200がアプリシステム400から提供される情報等を企業のセキュリティポリシーに対応させるために抽象化することができる。つまり、アプリシステム400から提供される抽象度の低い情報を抽象度の高いセキュリティポリシーに対応させるために抽象度を上げることができる。従って、組織のセキュリティポリシーに従って、電子文書のみならず紙文書のセキュリティを確保することができる。
文書管理サーバとドキュメントビューア53とが、サーバドキュメント61及びポータブルドキュメント等の電子文書に対するアクセス制御を組織のセキュリティポリシーに従って行い、ドキュメントユーバ53からポータブルドキュメント63を印刷する際に、ポリシーに従ってセキュリティ処理を行うことで、印刷者本人に印刷された紙文書をポリシーに従って適切に扱わせることができる。
また、印刷されたペーパードキュメント62をデジタル複合機70で複写する際にもポリシーに従って、その処理をコントロールすることができる。
従って、一般オフィスにおいて、紙文書と電子文書のセキュリティを十分確保可能となる。