アカウント管理システム
【課題】 職制改正、人事異動時に伴うネットワーク上の資源をアクセスするためのアカウント変更作業のミスを減らし、容易に短時間でタイムリーに変更できる管理方法と正しく管理されていることを証明するための監査証跡を出力することができるアカウント管理システムを提供すること。
【解決手段】 前記アカウント管理装置が、予め組織内の部署及び役職により特定される所属に対応したユーザアカウントを設定すると共に、各ユーザアカウントについて、対応する所属に配置された職員の職員識別情報とユーザアカウント有効期限の割当処理を行う手段と、配置変更情報格納手段に登録された各所属の配置変更情報に基づき、各ユーザアカウントに対して職員識別情報の割当変更処理を行う手段と、前記ユーザアカウント有効期限に達したユーザアカウントを無効にする手段とを備える。
【解決手段】 前記アカウント管理装置が、予め組織内の部署及び役職により特定される所属に対応したユーザアカウントを設定すると共に、各ユーザアカウントについて、対応する所属に配置された職員の職員識別情報とユーザアカウント有効期限の割当処理を行う手段と、配置変更情報格納手段に登録された各所属の配置変更情報に基づき、各ユーザアカウントに対して職員識別情報の割当変更処理を行う手段と、前記ユーザアカウント有効期限に達したユーザアカウントを無効にする手段とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上に分散しているコンピュータ、フォルダ、ファイルなどの資源を利用する場合のユーザアカウントを管理するアカウント管理システムに関する。
【背景技術】
【０００２】
一般に、企業や役所などの組織においては上司と部下の関係が成り立ち、ツリー構造の職制となっている。企業の職制で考えると事業部−本部−部−課−係のような構造となっている。
上位の役職の人は下位の人を統括し同じ層の部署間は独立し基本的に権限が及ばない構造になっている。コンピュータについて考えるとネットワーク上には個々のクライアントＰＣ（パーソナルコンピュータ）と各種のサーバが繋がっており、同じ部署内で共有するサーバ上のフォルダ、ファイルやプリンタが管理されている。
クライアントＰＣからネットワーク内に入るにはサーバ上に登録されたユーザＩＤ、パスワードなどのアカウントが必要であり、部外者などの不正なアクセスを排除し、アカウントに応じたファイル権限でアクセスコントロールしている。
下記の特許文献１は認証者と被認証者の関係をマトリックス上のチェックボックスのオン・オフで関係付けるものである。
【０００３】
【特許文献１】特開２００２−１６９９３６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
職制改正や人事異動があったとき、関係する所属部門の全てについてアカウントの変更が必要になる。
具体的には所属が変わったことでこれまで参照可能であった旧所属のサーバ上に共有されているファイルは参照・更新できなくすることや、これまで利用できていたプリンタは利用できないようにすることが必要となる。また、逆に新所属のサーバ上に共有されているファイルが参照・更新できるようにしたり、新所属のプリンタが利用できるようする必要がある。
部署の新設や部署の名前が変わる場合は、サーバ上に管理しているフォルダの作成やフォルダ名の変更が必要になる。
また、職員が昇格した場合、配下の部署のフォルダやファイルの参照・更新ができるようにアクセス権限の変更が必要になる。
また、パートやアルバイトなどの臨時的に就業する人にアカウントを追加する場合は、セキュリティ面からも厳密な管理を行わないと、退社した人のアカウントを使って不正なアクセスが行われるリスクがある。
【０００５】
一般にアカウントは各職場単位でのローカルな管理で行っていることが多く、全社統一したアカウント管理は行われていない場合が多い。
一方、職制改正、人事異動は全社レベルで一斉に行われる。各職場で職制改正、人事異動に応じたアカウントの変更作業は全社的なレベルで見ると膨大な作業量になる。
また、何月何日付けで職制改正、人事異動当日の作業開始時点から新しいアカウントで作業が開始できるようにすることは難しく、アカウントの変更作業に数日の期間を要することが多い。この期間、職員の作業効率が低下したり、アカウント変更が完了するまで作業がストップするケースもある。また、このような煩わしさのために厳密なアカウント管理をあきらめ、共有ディレクトリの管理は行わず、部署や個人任せの放任した運用を行っている場合が多い。
また、アカウントの変更作業を人手で行うことで、変更作業のミスの発生する可能性が高い。ミスがあっても、変更作業を行った管理者はその場で気が付かず、エンドユーザからの問い合わせがあって初めてミスに気が付くことが一般的である。場合によっては、エンドユーザ自身も自分自身のアクセス権の状態が正しいか否かが分からず、設定ミスが埋もれたままになってしまうことも考えられる。
【０００６】
最近では、内部統制の厳密なコントロールにおいて、誰がどのような権限を保有し、それが正しくタイムリーに管理されているかが、重要なテーマとなっている。また、監査などで、正しく管理されていることを第三者にも証明するためのエビデンス（監査証跡）が必要である。
【０００７】
本発明の目的は、職制改正、人事異動時に伴うネットワーク上の資源をアクセスするためのアカウント変更作業のミスを減らし、容易に短時間でタイムリーに変更できる管理方法と正しく管理されていることを証明するための監査証跡を出力することができるアカウント管理方法及びシステムを提供することである。
【課題を解決するための手段】
【０００８】
上記目的を達成するために、本発明は、組織内ネットワーク上の共有資源へのアクセス認証に用いるユーザアカウントを設定・管理するアカウント管理装置を備えたアカウント管理システムであって、
前記アカウント管理装置が、
予め組織内の部署及び役職により特定される所属に対応したユーザアカウントを設定すると共に、各ユーザアカウントについて、対応する所属に配置された職員の職員識別情報とユーザアカウント有効期限の割当処理を行う手段と、配置変更情報格納手段に登録された各所属の配置変更情報に基づき、各ユーザアカウントに対して職員識別情報の割当変更処理を行う手段と、前記ユーザアカウント有効期限に達したユーザアカウントを無効にする手段とを備えることを特徴とする。
また、前記アカウント管理装置が、
配置変更情報格納手段に登録された各所属の配置変更情報の適用時期を基に、その適用時期に配置変更情報を適用した場合に有効となっている各職員のユーザアカウント及び氏名を表示すると共に、内部統制の監査のための監査証跡を所定の形式で出力する手段をさらに備えることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ネットワーク上のユーザ管理、コンピュータ情報、フォルダ、ファイル、セキュリティなどの資源を利用するユーザアカウントの管理が簡単になり、人事異動の際のアカウント変更作業が短期間に正確にできるようになる。
また、変更内容を事前に確認することができ、変更内容を帳票に出力することで監査資料を残すことができる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明を実施する場合の一形態を図面を参照して具体的に説明する。
図１は、本発明の実施の一形態に係るアカウント管理システムを含む組織内ネットワークの構成例を示すシステム構成図である。
組織内ネットワークは、アカウント管理サーバ１、メールサーバ２、ＤＢサーバ３、ファイルサーバ７、クライアントＡ８、クライアントＢ９、プリンタ１０はネットワーク１１上で接続されている。
ＤＢサーバ３にはユーザデータ４、職員データ５、変更データ６のデータベースが構築されている。
アカウント管理サーバ１は、全職員のアカウントを管理しており、基本的な管理はＯＳが提供するものである。本発明ではＯＳの機能をカスタマイズする形で構築する。
【００１１】
図２は、一般的な企業の職制の組織体系とアカウント管理サーバ１により付与する識別子との関係を示した説明図である。
各ボックスの上段は組織や部署であり、下段が組織や部署に対応する管理者や職員である。
この例の組織体系では、会社−社長２１の下には事業部Ａ−事業部長Ａ２２、事業部Ｂ−事業部長Ｂ２３がある。さらに、事業部Ａ−事業部長Ａ２２の下には部Ａ１−部長Ａ１２４、部Ａ２−部長Ａ２２５があり、以下同様に担当Ａ２１２１−担当Ａ２１２１３０、担当Ａ２１２２−担当Ａ２１２２３１のように階層的に構成されている。
このような構成に対応したディレクトリ構成をファイルサーバ７上に構成した場合、組織や部署内で共有するファイルを該当するディレクトリ直下に置くと、その組織や部署の構成員は自分に関係するファイルのみにアクセスでき、所属しない部署の共有ファイルはアクセスできないという仕組みにすることができる。
このようなアクセスコントロールを実現するためには、ネットワークに入った職員のアカウントに対応したアクセス権限でコントロールすることになる。
【００１２】
図３は、上記のアクセスコントロールを行うときのアカウントの主キーであるユーザＩＤの付与方法の例を示す図である。
ここでは、例えば事業部Ｗ、課部門１１１、役職９１の一職員には、「Ｗ１１１９１０１」というユーザＩＤを付与することで、当該職員に応じたアクセス権を与えることが可能となる。
ユーザＩＤは役職に付与し、一職員個人に付与する訳ではないので、職制改正、人事異動の際は対応する職員が変わるだけである。
【００１３】
図４は、ユーザデータテーブル４１の一形態を示す図であり、ユーザＩＤ別に、部署コード、係コード、職員番号、アクセス権レベルが登録されている。
【００１４】
図５は、職員データテーブル５１の一形態を示す図であり、職員番号別に、氏名、メールＩＤ、アカウント開始時期、アカウント終了時期が登録されている。
【００１５】
図６は、職制改正、人事異動時の変更内容を登録する変更データテーブル６１の一形態を示す図であり、変更を実行する実行日、変更内容を示す処理区分、対応するユーザＩＤ、職員番号、氏名、メールＩＤと実行結果の状態を示すフラグで構成されている。
ユーザデータテーブル４１、職員データテーブル５１の最初の構築もこの変更データテーブルに登録する。
処理区分が「ユーザ作成」である場合には、ユーザデータテーブル４１にユーザを追加する。処理区分が「職員作成」である場合には、職員データテーブル５１に職員を追加する。処理区分が「職員割当」の場合には、ユーザデータテーブル４１に対応する職員の割当を行う。
人事異動の際に役職に対応する職員が変わる場合は、処理区分に「職員解除」を指定し、ユーザデータテーブル４１の該当するユーザＩＤの職員を解除する。なお、この状態は、該当するユーザＩＤの使用者はなしの状態になる。
その後、処理区分に「職員割当」を指定し、該当するユーザＩＤの職員を割当てる。
職制改正、人事異動時には、変更となるデータを職員データテーブル５１に登録することで事前に手続き化することができ、過去の履歴も管理することができる。
また、ＯＳやシステムに依存するアカウント管理に詳しくない人事課の職員であっても、本テーブル５１のデータを作成することは可能である。
【００１６】
図７は、アカウント管理サーバ１及びＤＢサーバ３が行うアカウント設定変更処理の手順を示すフロ−チャ−トである。
本処理は、職制改正、人事異動の有無に関わらず、スケジュール設定された時刻（例えば毎日ＡＭ０：００）に実行するものである。
まず、スケジュール設定された時刻にアカウント管理サーバ１は、ＤＢサーバ３に変更データ問合せを行う（ステップ７１）。
ＤＢサーバ３は、変更データテーブル７１の実行日エントリから実行日の変更データを抽出する（ステップ７２）。この際、職員データテーブル５１からアカウント終了時期となっている職員については、当該職員を無効にする変更データを自動的に作成する。そして、変更データをアカウント管理サーバ１に送信する。
アカウント管理サーバ１は、抽出された変更データの全てに対して処理区分に対応する処理（ユーザ削除、職員作成、職員削除、職員情報変更、職員割当、職員解除）を実行し、（ステップ７３）、その実行結果をＤＢサーバ３へ送信する（ステップ７４）。
【００１７】
ＤＢサーバ３ではユーザデータ反映（ステップ７５）、職員データ反映（ステップ７６）、該当の変更データの結果設定を行い（ステップ７７）、アカウント情報を更新する。
【００１８】
図８は、組織の階層、職員の一覧、個人単位の属性を画面上に表示した一形態を示す図である。
領域８２ではツリー形式で組織の状態を示している。このツリーから特定の組織を選択すると、領域８３にその組織内に所属する職員の一覧を表示する。この一覧から特定の職員を選択すると、領域８４にその職員の詳細な属性を表示する。
選択する組織、職員を変えることで組織全体の職員の属性を画面上に表示することができる。
適用日８５の拡大したものを図９に示す。
適用日９１は右に付属するボタンを押下することでカレンダー形式の画面が表示され、そこから特定の日付を選択することで日付を変更することができる。
図８の画面８１が表示された時点では適用日９１は、当日を示しており、領域８２、領域８３、領域８４で表示される内容は当日の状態のものである。適用日９１で将来の日付を指定した場合、変更データテーブル６１の内容で登録された変更処理を内部的に行い、領域８２、領域８３、領域８４に表示される情報を変更する。
【００１９】
図１０は、異動内容の一覧の帳票イメージを表した一形態である。
当日から適用日までの間に行われる異動内容が発令日毎に移動前、移動後、氏名、移動後のアクセスレベルなどの情報を帳票イメージ形式で表示する。
【００２０】
図１１は、適用日９１で指定された日付までの変更データを抽出し、変更データのエントリを全て処理区分に対応する処理を実行する場合のアカウント管理サーバ１とＤＢサーバ３の処理手順を示すフローチャートである。
まず、アカウント管理サーバ１は、適用日９１で指定された日付までの変更データの問い合わせを行う（ステップ１１１）。
これに対して、ＤＢサーバ３は、適用日９１で指定された日付までの変更データを変更データテーブル６１から抽出し、その結果をアカウント管理サーバ１に返信する（ステップ１１２）。
アカウント管理サーバ１は、返信された変更データについて、処理区分に対応する処理（ユーザ削除、職員作成、職員削除、職員情報変更、職員割当、職員解除）を実行し、（ステップ１１３）、実行結果を基に、図１０に例示したような帳票イメージを表示またはプリンタ１０から印刷出力させる。
【図面の簡単な説明】
【００２１】
【図１】本発明の一実施の形態を示すシステム構成図である。
【図２】一般的な企業の職制の組織体系とアカウント管理サーバにより付与する識別子との関係を示した説明図である。
【図３】アカウントの主キーであるユーザＩＤの付与方法の例を示す図である。
【図４】ユーザデータテーブルの一形態を示す図である。
【図５】職員データテーブルの一形態を示す図である。
【図６】職制改正、人事異動時の変更内容を登録する変更データテーブルの一形態を示す図である。
【図７】アカウント管理サーバ及びＤＢサーバが行うアカウント設定変更処理の手順を示すフロ−チャ−トである。
【図８】組織の階層、職員の一覧、個人単位の属性を表示した管理画面の例を示す図である。
【図９】適用日を指定する画面の例を示す図である。
【図１０】異動内容の一覧の帳票イメージの例を示す図である。
【図１１】適用日で指定された日付までの変更データを抽出し、変更データのエントリを全て処理区分に対応する処理を実行する場合のアカウント管理サーバとＤＢサーバの処理手順を示すフローチャートである。
【符号の説明】
【００２２】
１…アカウント管理サーバ、２…メールサーバ、３…ＤＢサーバ、４…ユーザデータ、５…職員データ、６…変更データ、７…ファイルサーバ、８…クライアントＡ、９…クライアントＢ、１０…ネットワーク、４１…ユーザデータテーブル、５１…職員データテーブル、６１…変更データテーブル、１０１…異動内容一覧帳票イメージ。
【技術分野】
【０００１】
本発明は、ネットワーク上に分散しているコンピュータ、フォルダ、ファイルなどの資源を利用する場合のユーザアカウントを管理するアカウント管理システムに関する。
【背景技術】
【０００２】
一般に、企業や役所などの組織においては上司と部下の関係が成り立ち、ツリー構造の職制となっている。企業の職制で考えると事業部−本部−部−課−係のような構造となっている。
上位の役職の人は下位の人を統括し同じ層の部署間は独立し基本的に権限が及ばない構造になっている。コンピュータについて考えるとネットワーク上には個々のクライアントＰＣ（パーソナルコンピュータ）と各種のサーバが繋がっており、同じ部署内で共有するサーバ上のフォルダ、ファイルやプリンタが管理されている。
クライアントＰＣからネットワーク内に入るにはサーバ上に登録されたユーザＩＤ、パスワードなどのアカウントが必要であり、部外者などの不正なアクセスを排除し、アカウントに応じたファイル権限でアクセスコントロールしている。
下記の特許文献１は認証者と被認証者の関係をマトリックス上のチェックボックスのオン・オフで関係付けるものである。
【０００３】
【特許文献１】特開２００２−１６９９３６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
職制改正や人事異動があったとき、関係する所属部門の全てについてアカウントの変更が必要になる。
具体的には所属が変わったことでこれまで参照可能であった旧所属のサーバ上に共有されているファイルは参照・更新できなくすることや、これまで利用できていたプリンタは利用できないようにすることが必要となる。また、逆に新所属のサーバ上に共有されているファイルが参照・更新できるようにしたり、新所属のプリンタが利用できるようする必要がある。
部署の新設や部署の名前が変わる場合は、サーバ上に管理しているフォルダの作成やフォルダ名の変更が必要になる。
また、職員が昇格した場合、配下の部署のフォルダやファイルの参照・更新ができるようにアクセス権限の変更が必要になる。
また、パートやアルバイトなどの臨時的に就業する人にアカウントを追加する場合は、セキュリティ面からも厳密な管理を行わないと、退社した人のアカウントを使って不正なアクセスが行われるリスクがある。
【０００５】
一般にアカウントは各職場単位でのローカルな管理で行っていることが多く、全社統一したアカウント管理は行われていない場合が多い。
一方、職制改正、人事異動は全社レベルで一斉に行われる。各職場で職制改正、人事異動に応じたアカウントの変更作業は全社的なレベルで見ると膨大な作業量になる。
また、何月何日付けで職制改正、人事異動当日の作業開始時点から新しいアカウントで作業が開始できるようにすることは難しく、アカウントの変更作業に数日の期間を要することが多い。この期間、職員の作業効率が低下したり、アカウント変更が完了するまで作業がストップするケースもある。また、このような煩わしさのために厳密なアカウント管理をあきらめ、共有ディレクトリの管理は行わず、部署や個人任せの放任した運用を行っている場合が多い。
また、アカウントの変更作業を人手で行うことで、変更作業のミスの発生する可能性が高い。ミスがあっても、変更作業を行った管理者はその場で気が付かず、エンドユーザからの問い合わせがあって初めてミスに気が付くことが一般的である。場合によっては、エンドユーザ自身も自分自身のアクセス権の状態が正しいか否かが分からず、設定ミスが埋もれたままになってしまうことも考えられる。
【０００６】
最近では、内部統制の厳密なコントロールにおいて、誰がどのような権限を保有し、それが正しくタイムリーに管理されているかが、重要なテーマとなっている。また、監査などで、正しく管理されていることを第三者にも証明するためのエビデンス（監査証跡）が必要である。
【０００７】
本発明の目的は、職制改正、人事異動時に伴うネットワーク上の資源をアクセスするためのアカウント変更作業のミスを減らし、容易に短時間でタイムリーに変更できる管理方法と正しく管理されていることを証明するための監査証跡を出力することができるアカウント管理方法及びシステムを提供することである。
【課題を解決するための手段】
【０００８】
上記目的を達成するために、本発明は、組織内ネットワーク上の共有資源へのアクセス認証に用いるユーザアカウントを設定・管理するアカウント管理装置を備えたアカウント管理システムであって、
前記アカウント管理装置が、
予め組織内の部署及び役職により特定される所属に対応したユーザアカウントを設定すると共に、各ユーザアカウントについて、対応する所属に配置された職員の職員識別情報とユーザアカウント有効期限の割当処理を行う手段と、配置変更情報格納手段に登録された各所属の配置変更情報に基づき、各ユーザアカウントに対して職員識別情報の割当変更処理を行う手段と、前記ユーザアカウント有効期限に達したユーザアカウントを無効にする手段とを備えることを特徴とする。
また、前記アカウント管理装置が、
配置変更情報格納手段に登録された各所属の配置変更情報の適用時期を基に、その適用時期に配置変更情報を適用した場合に有効となっている各職員のユーザアカウント及び氏名を表示すると共に、内部統制の監査のための監査証跡を所定の形式で出力する手段をさらに備えることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ネットワーク上のユーザ管理、コンピュータ情報、フォルダ、ファイル、セキュリティなどの資源を利用するユーザアカウントの管理が簡単になり、人事異動の際のアカウント変更作業が短期間に正確にできるようになる。
また、変更内容を事前に確認することができ、変更内容を帳票に出力することで監査資料を残すことができる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明を実施する場合の一形態を図面を参照して具体的に説明する。
図１は、本発明の実施の一形態に係るアカウント管理システムを含む組織内ネットワークの構成例を示すシステム構成図である。
組織内ネットワークは、アカウント管理サーバ１、メールサーバ２、ＤＢサーバ３、ファイルサーバ７、クライアントＡ８、クライアントＢ９、プリンタ１０はネットワーク１１上で接続されている。
ＤＢサーバ３にはユーザデータ４、職員データ５、変更データ６のデータベースが構築されている。
アカウント管理サーバ１は、全職員のアカウントを管理しており、基本的な管理はＯＳが提供するものである。本発明ではＯＳの機能をカスタマイズする形で構築する。
【００１１】
図２は、一般的な企業の職制の組織体系とアカウント管理サーバ１により付与する識別子との関係を示した説明図である。
各ボックスの上段は組織や部署であり、下段が組織や部署に対応する管理者や職員である。
この例の組織体系では、会社−社長２１の下には事業部Ａ−事業部長Ａ２２、事業部Ｂ−事業部長Ｂ２３がある。さらに、事業部Ａ−事業部長Ａ２２の下には部Ａ１−部長Ａ１２４、部Ａ２−部長Ａ２２５があり、以下同様に担当Ａ２１２１−担当Ａ２１２１３０、担当Ａ２１２２−担当Ａ２１２２３１のように階層的に構成されている。
このような構成に対応したディレクトリ構成をファイルサーバ７上に構成した場合、組織や部署内で共有するファイルを該当するディレクトリ直下に置くと、その組織や部署の構成員は自分に関係するファイルのみにアクセスでき、所属しない部署の共有ファイルはアクセスできないという仕組みにすることができる。
このようなアクセスコントロールを実現するためには、ネットワークに入った職員のアカウントに対応したアクセス権限でコントロールすることになる。
【００１２】
図３は、上記のアクセスコントロールを行うときのアカウントの主キーであるユーザＩＤの付与方法の例を示す図である。
ここでは、例えば事業部Ｗ、課部門１１１、役職９１の一職員には、「Ｗ１１１９１０１」というユーザＩＤを付与することで、当該職員に応じたアクセス権を与えることが可能となる。
ユーザＩＤは役職に付与し、一職員個人に付与する訳ではないので、職制改正、人事異動の際は対応する職員が変わるだけである。
【００１３】
図４は、ユーザデータテーブル４１の一形態を示す図であり、ユーザＩＤ別に、部署コード、係コード、職員番号、アクセス権レベルが登録されている。
【００１４】
図５は、職員データテーブル５１の一形態を示す図であり、職員番号別に、氏名、メールＩＤ、アカウント開始時期、アカウント終了時期が登録されている。
【００１５】
図６は、職制改正、人事異動時の変更内容を登録する変更データテーブル６１の一形態を示す図であり、変更を実行する実行日、変更内容を示す処理区分、対応するユーザＩＤ、職員番号、氏名、メールＩＤと実行結果の状態を示すフラグで構成されている。
ユーザデータテーブル４１、職員データテーブル５１の最初の構築もこの変更データテーブルに登録する。
処理区分が「ユーザ作成」である場合には、ユーザデータテーブル４１にユーザを追加する。処理区分が「職員作成」である場合には、職員データテーブル５１に職員を追加する。処理区分が「職員割当」の場合には、ユーザデータテーブル４１に対応する職員の割当を行う。
人事異動の際に役職に対応する職員が変わる場合は、処理区分に「職員解除」を指定し、ユーザデータテーブル４１の該当するユーザＩＤの職員を解除する。なお、この状態は、該当するユーザＩＤの使用者はなしの状態になる。
その後、処理区分に「職員割当」を指定し、該当するユーザＩＤの職員を割当てる。
職制改正、人事異動時には、変更となるデータを職員データテーブル５１に登録することで事前に手続き化することができ、過去の履歴も管理することができる。
また、ＯＳやシステムに依存するアカウント管理に詳しくない人事課の職員であっても、本テーブル５１のデータを作成することは可能である。
【００１６】
図７は、アカウント管理サーバ１及びＤＢサーバ３が行うアカウント設定変更処理の手順を示すフロ−チャ−トである。
本処理は、職制改正、人事異動の有無に関わらず、スケジュール設定された時刻（例えば毎日ＡＭ０：００）に実行するものである。
まず、スケジュール設定された時刻にアカウント管理サーバ１は、ＤＢサーバ３に変更データ問合せを行う（ステップ７１）。
ＤＢサーバ３は、変更データテーブル７１の実行日エントリから実行日の変更データを抽出する（ステップ７２）。この際、職員データテーブル５１からアカウント終了時期となっている職員については、当該職員を無効にする変更データを自動的に作成する。そして、変更データをアカウント管理サーバ１に送信する。
アカウント管理サーバ１は、抽出された変更データの全てに対して処理区分に対応する処理（ユーザ削除、職員作成、職員削除、職員情報変更、職員割当、職員解除）を実行し、（ステップ７３）、その実行結果をＤＢサーバ３へ送信する（ステップ７４）。
【００１７】
ＤＢサーバ３ではユーザデータ反映（ステップ７５）、職員データ反映（ステップ７６）、該当の変更データの結果設定を行い（ステップ７７）、アカウント情報を更新する。
【００１８】
図８は、組織の階層、職員の一覧、個人単位の属性を画面上に表示した一形態を示す図である。
領域８２ではツリー形式で組織の状態を示している。このツリーから特定の組織を選択すると、領域８３にその組織内に所属する職員の一覧を表示する。この一覧から特定の職員を選択すると、領域８４にその職員の詳細な属性を表示する。
選択する組織、職員を変えることで組織全体の職員の属性を画面上に表示することができる。
適用日８５の拡大したものを図９に示す。
適用日９１は右に付属するボタンを押下することでカレンダー形式の画面が表示され、そこから特定の日付を選択することで日付を変更することができる。
図８の画面８１が表示された時点では適用日９１は、当日を示しており、領域８２、領域８３、領域８４で表示される内容は当日の状態のものである。適用日９１で将来の日付を指定した場合、変更データテーブル６１の内容で登録された変更処理を内部的に行い、領域８２、領域８３、領域８４に表示される情報を変更する。
【００１９】
図１０は、異動内容の一覧の帳票イメージを表した一形態である。
当日から適用日までの間に行われる異動内容が発令日毎に移動前、移動後、氏名、移動後のアクセスレベルなどの情報を帳票イメージ形式で表示する。
【００２０】
図１１は、適用日９１で指定された日付までの変更データを抽出し、変更データのエントリを全て処理区分に対応する処理を実行する場合のアカウント管理サーバ１とＤＢサーバ３の処理手順を示すフローチャートである。
まず、アカウント管理サーバ１は、適用日９１で指定された日付までの変更データの問い合わせを行う（ステップ１１１）。
これに対して、ＤＢサーバ３は、適用日９１で指定された日付までの変更データを変更データテーブル６１から抽出し、その結果をアカウント管理サーバ１に返信する（ステップ１１２）。
アカウント管理サーバ１は、返信された変更データについて、処理区分に対応する処理（ユーザ削除、職員作成、職員削除、職員情報変更、職員割当、職員解除）を実行し、（ステップ１１３）、実行結果を基に、図１０に例示したような帳票イメージを表示またはプリンタ１０から印刷出力させる。
【図面の簡単な説明】
【００２１】
【図１】本発明の一実施の形態を示すシステム構成図である。
【図２】一般的な企業の職制の組織体系とアカウント管理サーバにより付与する識別子との関係を示した説明図である。
【図３】アカウントの主キーであるユーザＩＤの付与方法の例を示す図である。
【図４】ユーザデータテーブルの一形態を示す図である。
【図５】職員データテーブルの一形態を示す図である。
【図６】職制改正、人事異動時の変更内容を登録する変更データテーブルの一形態を示す図である。
【図７】アカウント管理サーバ及びＤＢサーバが行うアカウント設定変更処理の手順を示すフロ−チャ−トである。
【図８】組織の階層、職員の一覧、個人単位の属性を表示した管理画面の例を示す図である。
【図９】適用日を指定する画面の例を示す図である。
【図１０】異動内容の一覧の帳票イメージの例を示す図である。
【図１１】適用日で指定された日付までの変更データを抽出し、変更データのエントリを全て処理区分に対応する処理を実行する場合のアカウント管理サーバとＤＢサーバの処理手順を示すフローチャートである。
【符号の説明】
【００２２】
１…アカウント管理サーバ、２…メールサーバ、３…ＤＢサーバ、４…ユーザデータ、５…職員データ、６…変更データ、７…ファイルサーバ、８…クライアントＡ、９…クライアントＢ、１０…ネットワーク、４１…ユーザデータテーブル、５１…職員データテーブル、６１…変更データテーブル、１０１…異動内容一覧帳票イメージ。
【特許請求の範囲】
【請求項１】
組織内ネットワーク上の共有資源へのアクセス認証に用いるユーザアカウントを設定・管理するアカウント管理装置を備えたアカウント管理システムであって、
前記アカウント管理装置が、
予め組織内の部署及び役職により特定される所属に対応したユーザアカウントを設定すると共に、各ユーザアカウントについて、対応する所属に配置された職員の職員識別情報とユーザアカウント有効期限の割当処理を行う手段と、配置変更情報格納手段に登録された各所属の配置変更情報に基づき、各ユーザアカウントに対して職員識別情報の割当変更処理を行う手段と、前記ユーザアカウント有効期限に達したユーザアカウントを無効にする手段とを備えることを特徴とするアカウント管理システム。
【請求項２】
前記アカウント管理装置が、
配置変更情報格納手段に登録された各所属の配置変更情報の適用時期を基に、その適用時期に配置変更情報を適用した場合に有効となっている各職員のユーザアカウント及び氏名を表示すると共に、内部統制の監査のための監査証跡を所定の形式で出力する手段をさらに備えることを特徴とする請求項１に記載のアカウント管理システム。
【請求項１】
組織内ネットワーク上の共有資源へのアクセス認証に用いるユーザアカウントを設定・管理するアカウント管理装置を備えたアカウント管理システムであって、
前記アカウント管理装置が、
予め組織内の部署及び役職により特定される所属に対応したユーザアカウントを設定すると共に、各ユーザアカウントについて、対応する所属に配置された職員の職員識別情報とユーザアカウント有効期限の割当処理を行う手段と、配置変更情報格納手段に登録された各所属の配置変更情報に基づき、各ユーザアカウントに対して職員識別情報の割当変更処理を行う手段と、前記ユーザアカウント有効期限に達したユーザアカウントを無効にする手段とを備えることを特徴とするアカウント管理システム。
【請求項２】
前記アカウント管理装置が、
配置変更情報格納手段に登録された各所属の配置変更情報の適用時期を基に、その適用時期に配置変更情報を適用した場合に有効となっている各職員のユーザアカウント及び氏名を表示すると共に、内部統制の監査のための監査証跡を所定の形式で出力する手段をさらに備えることを特徴とする請求項１に記載のアカウント管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２００８−２０３９０９（Ｐ２００８−２０３９０９Ａ）
【公開日】平成２０年９月４日（２００８．９．４）
【国際特許分類】
【出願番号】特願２００７−３５７７５（Ｐ２００７−３５７７５）
【出願日】平成１９年２月１６日（２００７．２．１６）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
【公開日】平成２０年９月４日（２００８．９．４）
【国際特許分類】
【出願日】平成１９年２月１６日（２００７．２．１６）
【出願人】（０００２３３０５５）日立ソフトウエアエンジニアリング株式会社 (1,610)
【Ｆターム（参考）】
[ Back to top ]