(57)【要約】【課題】  クライアントアプリケーションから直接データベースへの接続を行う形式のクライアントサーバーシステムにおいて、安全なデータベースアクセスの仕組みを実現する。【解決手段】  システムのユーザをデータベースアクセスアカウントとは別に抽象化した形で管理した上で、テーブルに直接アクセス不可能なデータベースアクセスアカウントを用意し、プロシージャ経由でデータアクセスする。【選択図】  図１
2009098792.tif 000002
【特許請求の範囲】
【請求項１】
文書を格納管理するデータベースと、データベース内に、文書を参照するためのDocumentテーブルと、アカウントを管理するためのAccountテーブルと、
各アカウントに対する権限を管理するためのRightsテーブルと、システムへの認証と接続の確立を行い、認証された接続の証明書を返却するConnectプロシージャと、指定された接続の証明書に従ってDocumentテーブルへのアクセスを行うDocument Accessプロシージャと、全てのテーブルには直接アクセスできないが、各プロシージャは実行可能な低権限のデータベースアカウントとを有し、この低権限のデータベースアカウントによりデータベースアクセスを行うクライアントアプリケーションとを有することを特徴とする文書管理サーバへのアクセス装置。
【請求項２】
データベースアクセスするためのアカウント情報を保存・管理しておく、データベースアクセスアカウント管理部とクライアントからの要求に応じて、データベースアクセスアカウント管理部で管理されているデータベースアクセスアカウントを配信するアクセスアカウント配信部を有することを特徴とする請求項１に記載の文書管理サーバへのアクセス装置。
【請求項３】
データベース内に、アクセスアカウントの権限を一時的に上昇させる権限上昇プロシージャを有することを特徴とする請求項１に記載の文書管理サーバへのアクセス装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文書をシステム内に保存して複数のユーザで共有するための文書管理システムに関するもので、特に文書システムのユーザごとアクセス権限を制御する機構を備えた装置、及び、それらの制御方法、プログラム、記憶媒体に関するものである。
【背景技術】
【０００２】
かかるオフィス環境では、文書を読み取り可能なデバイスと、文書を管理するサーバー、それらを利用するためのPCなどのクライアントが同一ネットワーク上に配置され、文書管理システムが構築されている。
【０００３】
各クライアントPCにインストールされたクライアントアプリケーションは、文書サーバーに格納された文書へアクセスするのに次のいずれかの方法が用いられる。
【０００４】
(1)サーバー上でクライアントからのリクエストを受け付けるサーバープロセスを起動し、このサーバープロセスがデータベースへのアクセスを行うことで、間接的に文書データへアクセスする
(2)クライアントアプリケーションが直接データベースへ直接接続し、その中に格納されている文書データに対してアクセスを行う
また、(2)に関しては、認証の方法としてさらに以下の2通りに分類できる。
【０００５】
(A)データベースに直接エンドユーザのアカウントを作成し、そのアカウントとパスワードをエンドユーザがクライアントアプリケーションで入力することで、アカウントの認証およびシステムとクライアントアプリケーションの接続を確立する。
【０００６】
(B)データベース内にデータベースのアカウントとは別にシステムのアカウント管理テーブルを作成し、抽象化したシステムのアカウントを管理する。
【０００７】
エンドユーザは、各クライアントアプリケーションで接続時にこのシステムのアカウントとパスワードを入力する。
【０００８】
各クライアントアプリケーションはまず共通のデータベースアカウントを使用して、データベースへ接続したあと、アカウント管理テーブル内のデータとエンドユーザが入力したシステムアカウントのユーザ名やID、パスワードなどのデータを比較することでアカウントの認証およびシステムとクライアントアプリケーションの接続を確立する。
【０００９】
上記(B)の例としては特許文献１にあるように、セキュリティ情報テーブルで、各ユーザ・グループについてデータベース、表、表中の列、列中の特定のデータに至るまでのアクセス権を設定しておき、セキュリティサーバへ特定のユーザについてアクセス可能なデータベース、表一覧又は列一覧を照会し、Clientへアクセス可能なデータベースの範囲を通知するものも存在する。この場合、Clientはアクセス可能な範囲内でデータベースサーバに検索要求を行う事でアクセス制御を行う。
【特許文献１】特開平１０−２３２８１１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、上述した従来の技術には以下のような問題点がある。
【００１１】
背景技術(1)の場合には、クライアントアプリケーションからのリクエストに従って、サーバープロセスがデータベースサーバーからデータセットを取得して、クライアントへ返す。このため、データベース上だけでなく、一旦サーバープロセス上でデータセットを一時的に作成しなければならない。
【００１２】
取得するデータセットのデータ容量によっては、サーバー側における大きな負荷になる。特に複数のクライアントから同時期にアクセスを受け付ける場合には大きな問題となる。
【００１３】
背景技術(2)の場合には、データベースへの直接アクセスを行うため、上述したような使用メモリ量の制約は緩和されるが、(2)の(A)と(B)それぞれにおいて、以下のような課題が存在する。
【００１４】
(A)全てのアカウントがデータベース自身のアカウントとして作成されるため、このアカウントを使用して直接データベースへアクセスすることにより権限のないデータへのアクセスなど、不正なアクセスが行われる可能性がある。
【００１５】
また、アカウントを抽象化せず、データベースのアカウントを直に使用するために、他のシステムとのアカウントの共通化や、認証の共通化などで連携したシステムの構築をするのが困難である。
【００１６】
多くのシステムとの連携が求められるオフィス環境ではこれは大きなデメリットである。
【００１７】
(B)共通のデータベースアカウントとパスワードを使用するが、パスワードはデータベース側で定期的に変更される可能性があるため、クライアントアプリケーションがデータベースへ接続する際に、サーバーに登録してある共通アカウントのパスワードを取得する必要がある。このとき、サーバー側からクライアント側へネットワーク上にパスワードを流すことになるため、パケット解析などで読み取られる可能性もあり、セキュリティ上問題である。
【課題を解決するための手段】
【００１８】
本発明は、上記問題を解決するためになされたもので、文書を格納管理するデータベースと、データベース内に、
文書を参照するためのDocumentテーブルと、
アカウントを管理するためのAccountテーブルと、
各アカウントに対する権限を管理するためのRightsテーブルと、
システムへの認証と接続の確立を行い、認証された接続の証明書を返却するConnectプロシージャと、
指定された接続の証明書に従ってDocumentテーブルへのアクセスを行うDocument Accessプロシージャと、
全てのテーブルには直接アクセスできないが、各プロシージャは実行可能な低権限のデータベースアカウントとを有し、
この低権限のデータベースアカウントによりデータベースアクセスを行うクライアントアプリケーションとを有することを特徴とする。
【発明の効果】
【００１９】
クライアントアプリケーションから直接データベースへの接続を行う形式のクライアントサーバーシステムにおいて、システムのユーザをデータベースアクセスアカウントとは別に抽象化した形で管理した上で、テーブルに直接アクセス不可能なデータベースアクセスアカウントのみを使用する安全なデータベースアクセスの仕組みを実現することでき、データベースアクセスアカウントが漏洩した場合にも不正なアクセスやデータの改竄が防止できるため、システムのセキュリティを向上させることができる。
【発明を実施するための最良の形態】
【００２０】
次に、本発明の詳細を実施例の記述に従って説明する。
【実施例１】
【００２１】
以下、本発明に係わる一実施形態について図面を参照して説明する。
【００２２】
図１は、本発明の特徴を最もよく表わす図面であり、本実施形態における構成の一例を示している。
【００２３】
本実施例における文書管理システムはパーソナルコンピュータのOS上で動作するクライアント（1000）・文書サーバ（1100）型のアプリケーションであり、スキャナなどのデバイスや、OS上のファイルから文書を取り込み、文書を複数のユーザで管理することを目的としている。
【００２４】
図２は、本実施例において、クライアント1000が文書データにアクセスするためのフローを表した図である。図２の(1)、(2)、(3)の処理は、それぞれ図１の(1)、(2)、(3)の処理に該当する。
【００２５】
クライアント1000は、ユーザからの操作を受け付けるU/I部1001と、U/I部1001での操作を受けて内部的な処理を制御する制御部1002と、外部のサーバやサービスとの通信を担う通信部1003とをもつ。
【００２６】
（(1)：データベースアクセスアカウントの取得処理）
クライアント1000を用いて文書サーバ1100にアクセスする場合には、ユーザはまずU/I部にてユーザ名とパスワードを入力する。
【００２７】
ただし、このユーザ名とパスワードは本システムが独自に定義・管理しているユーザ情報（※１）であり、文書サーバ1100にインストールされているデータベースサーバ1101そのものへのアクセスアカウント（※２）とは異なる。
【００２８】
よって、クライアント1000が、データベースサーバ1101へアクセスを行うためには、データベースサーバ1101自体のアクセスアカウントを取得する必要がある。
【００２９】
そのため、クライアント1000は、サーバ1100上に公開されているアカウント配信サービス1102に対して、アクセスアカウントのリクエストを行う。クライアントからのリクエストをうけたアカウント配信サービス1102は、サーバ1100内に管理されているアクセスアカウント管理部1103からアクセスアカウント名とパスワードを取得し、クライアント1000へ送る。
【００３０】
このアクセスアカウント管理部1103に管理されているアカウントは、データベース1101のアカウントであるが、データベース内の公開プロシージャ（1104や1106など：後述）に対しては実行権限があるものの、各テーブル（1105,1107,1108など）に対してはアクセスできないよう制限がかけられていることが前提となっている。（よって、このアカウント情報はネットワーク経由で配信されるが、ネットワーク上で第三者に漏洩したとしても、このアカウントを使用してデータベーステーブルの操作や不正な閲覧は行うことができない。）
本システムの管理者は定期的にデータベースのパスワードを変更することが考えられるが、その場合には、このアクセスアカウント管理部1103に管理されているアカウントのパスワードも同時に変更されるものとする。
【００３１】
（(2)：ユーザ情報を用いたシステムへのログイン処理）
アカウント配信サービス1102からアクセスアカウントを受け取ったクライアント1000は、このアクセスアカウントを使用して、データベースサーバ1101へと接続し、ログインプロシージャ1104を実行する。
【００３２】
ログインプロシージャは、システムのユーザ情報を受け取り、データベースサーバ内で管理しているユーザ情報との比較を行い、アクセスを許可すべきユーザであることが確認できれば、認証された証として、認証情報をクライアント1000へ返す役割を担う。
【００３３】
たとえば、ログインプロシージャ1104のI/Fが次のように定義されているとする。
【００３４】
Credential SP_Login(User, Pass);
この場合、クライアント1000は、U/I部でユーザが入力したユーザ名とパスワードをそれぞれ、User, Passとして引数に指定し、SP_Login関数を呼び出す。SP_Login関数内では、認証処理として、引数として受け取ったUser、Passをデータベースサーバ1101内でユーザ情報を管理しているユーザ情報テーブル1103と比較を行い（※３）、システムへのログインを許可できるユーザかどうかの判断を行う。
【００３５】
指定されたユーザ情報がログインを許可できるユーザ情報ではなかった場合、ログインプロシージャ1104は、認証不許可を意味するNULLを戻り値としてクライアント1000へ返す。指定されたユーザ情報がログインを許可できるユーザ情報であった場合には、ログインプロシージャ1104は、認証が許可された証として、認証情報（Credential）を内部的に生成し、ユーザ情報テーブルへ格納すると共に、クライアント1000へ返す。
【００３６】
図３の3001は、図１におけるユーザ情報テーブル1105のデータテーブル構造の一例を示したものである。3001に示すように、ログインプロシージャ1105にて生成された認証情報は、指定されたユーザ情報と関連付けた形でユーザ情報テーブル1105へ格納される。この認証情報はデータへアクセスする際に指定され、指定された認証情報を元にアクセス権やログイン状態をシステムが判断するための基準になるものなので、ログインプロシージャ1104はユーザ情報テーブル1105内で一意に定まるようにこの認証情報を生成する。
【００３７】
（(3)：文書データへのアクセス処理）
ログインプロシージャ1104から認証情報を受け取ったクライアント1000は、この認証情報を使用して、データベースサーバ1101で公開している文書データアクセスプロシージャ1106を実行する。
【００３８】
文書データアクセスプロシージャ1106は、認証情報とアクセス対象の文書を特定する情報を受け取り、ユーザ情報テーブル1105で管理されている認証情報と比較して、文書へのアクセスしているユーザを特定する。
【００３９】
特定されたユーザがアクセス対象の文書に対してアクセス権を持つかどうかは、文書データテーブル1107およびアクセス権管理テーブル1108で管理されている情報から判断できる（※３）。文書データアクセスプロシージャ内でこの判断が行われ、対象文書に対してアクセス権があれば、文書に対するアクセス処理を実行する。
【００４０】
たとえば、文書データアクセスプロシージャ1106の一つとして次のようなI/Fが定義されているとする。
【００４１】
RecordSet SP_GetDocuments(Credential, DocIds);
この場合、クライアント1000は、U/I部でユーザが指定した文書群のID配列をDocIdsとして、処理(2)で取得した認証情報をCredentialとして引数に指定し、SP_GetDocuments関数を呼び出す。SP_GetDocuments関数内で、アクセス可能な文書の確認が行われ、指定したCredentialに対応するユーザに対してアクセス権のある文書のID配列のみRecordSetという形でクライアント1000へ返信される。クライアントはこの結果を受けてUIを制御する。
【００４２】
図３の3002、3003はそれぞれ、図１の文書データテーブル1107およびアクセス権管理テーブル1108の一例を示したものである。
【００４３】
本実施例によれば、クライアントアプリケーションから直接データベースへの接続を行う形式のクライアントサーバーシステムにおいて、システムのユーザをデータベースアクセスアカウントとは別に抽象化した形で管理した上で、テーブルに直接アクセス不可能なデータベースアクセスアカウントのみを使用する安全なデータベースアクセスの仕組みを実現することでき、データベースアクセスアカウントが漏洩した場合にも不正なアクセスやデータの改竄が防止できるため、システムのセキュリティを向上させることができる。
【００４４】
※１「本システムのユーザ情報」：
本システムがデータベースサーバ1101内のユーザ管理テーブル1105にて独自に定義・管理されている各ユーザの情報であり、文書へのアクセス権などはこのユーザ情報に対して割り当てられている。
【００４５】
※２「データベースサーバのアクセスアカウント」：
データベースサーバ1101自身で定義・管理されている、データベースサーバ1101へのアクセスを行うためだけに利用するアカウント。
【００４６】
※３：
通常はプロシージャの実行権限さえあれば、プロシージャを実行しているデータベースアカウントにテーブルアクセス権限がなくとも、プロシージャ内ではテーブルアクセスを行うことが可能である。
【００４７】
ただし、データベースサーバの種類によっては、プロシージャを実行しているデータベースアカウントにテーブルアクセス権限がないとプロシージャ内でもテーブルアクセスが拒否される場合もある。この場合には、プロシージャ内でテーブルアクセスを行う前に一時的にアクセスアカウントの権限を上昇させる必要がある。
【００４８】
例えば、サーバ内にあらかじめ保持しておいたデータベースの管理者アカウント情報をプロシージャが参照し、一時的に権限を上昇させる権限上昇プロシージャを定義しておいて、ログインプロシージャや文書データアクセスプロシージャ内で、テーブルアクセスの直前に権限上昇プロシージャを呼び出し、テーブルアクセス後にもとの権限にもどす、などの方法をとってもよい。
【図面の簡単な説明】
【００４９】
【図１】文書データアクセスのシステムブロック図。
【図２】クライアントアプリケーションでの文書データアクセスのフロー図。
【図３】実施例１のデータベースサーバ内で管理されるテーブルデータの一例。
【符号の説明】
【００５０】
1000  クライアント
1001  U/I部
1002  制御部
1003  通信部
1100  文書サーバ
1101  データベースサーバ
1102  アカウント配信サービス
1103  アクセスアカウント管理部
1104  ログインプロシージャ
1105  ユーザ情報テーブル
1106  文書データアクセスプロシージャ
1107  文書データテーブル
1108  アクセス権管理テーブル
3001  実施例１のユーザ情報テーブルの一例
3002  実施例１の文書データテーブルの一例
3003  実施例１のアクセス権管理テーブルの一例
【図１】
2009098792.tif 000003
【図２】
2009098792.tif 000004
【図３】
2009098792.tif 000005