JP5593370B2 - アクセス履歴提供システム及びアクセス履歴提供方法 - Google Patents

アクセス履歴提供システム及びアクセス履歴提供方法 Download PDF

Info

Publication number
JP5593370B2
JP5593370B2 JP2012250005A JP2012250005A JP5593370B2 JP 5593370 B2 JP5593370 B2 JP 5593370B2 JP 2012250005 A JP2012250005 A JP 2012250005A JP 2012250005 A JP2012250005 A JP 2012250005A JP 5593370 B2 JP5593370 B2 JP 5593370B2
Authority
JP
Japan
Prior art keywords
server
access
log
access history
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2012250005A
Other languages
English (en)
Other versions
JP2014099017A (ja
Inventor
恒子 倉
芳浩 吉田
麻美 宮島
順子 橋本
一雄 森村
裕二 前田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2012250005A priority Critical patent/JP5593370B2/ja
Publication of JP2014099017A publication Critical patent/JP2014099017A/ja
Application granted granted Critical
Publication of JP5593370B2 publication Critical patent/JP5593370B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Storage Device Security (AREA)

Description

この発明は、例えば、各サーバに蓄積されているアクセスログを収集して、アクセス履歴検索・閲覧サービスを行うアクセス履歴提供システム及びアクセス履歴提供方法に関する。
アクセスログは、ユーザの利便性向上や、オンラインサイトの利用状況に関する統計、分析などに活用されている。例えば、Webブラウザを使ったサービスにおけるアクセスログは、Webサービスの運営者のために用いられている(非特許文献1を参照)。また、mixiには、自分のページに誰がアクセスしたのかを見せる「足跡」機能がある(非特許文献2を参照)。
また、特許文献1には、利用者からリクエストがあった場合にアクセス制御ポリシーを確認し、利用者を特定するアクセス元認識情報がない場合にアクセス履歴情報データベースに記録するアクセス管理手段を有するWebコンテンツ提供システムが提案されている。
特許文献2には、検索要求に基づいてユーザが過去に閲覧したファイルの格納場所を取得し、ユーザの記憶にあるキーワードやファイル属性から検索し、ファイル毎に検索要求への適合度を表すファイル適合スコアを算出し、経験スコアを算出し、操作履歴情報を利用して、ファイル毎のファイル適合スコアと、コンテンツ毎の経験スコアを統合した統合適合スコアを算出し、該統合スコアを利用して、検索要求を満たす期間オブジェクトを抽出し、期間オブジェクトの検索結果を検索要求元に送信する機能を有する操作検索装置が提案されている。
特許文献3には、利用者が電子私書箱サーバを経由して各々の情報保有機関が提供する情報提供サーバへの問い合わせをしたときの履歴情報を求めたときに、電子私書箱サーバから各情報提供サーバに問い合わせるために、電子私書箱サーバ利用者IDから情報提供サーバの利用者IDへ置き換えて申請書を作成して各情報提供サーバに履歴情報を要求する。履歴情報を受け取った電子私書箱サーバは各履歴情報を利用者ごと、情報保有機関ごと、かつ時系列に並べて利用者に提示する履歴収集システムが提案されている。
ところで、医療機関で取り扱う患者に関する情報は、極めて機微度が高い個人情報であり、これらへのアクセスを監査することが義務付けられている(例えば、非特許文献3を参照)。また、上記ガイドラインにおいて求められている業務アプリケーションの監査ログについては、ログメッセージ規約が規定されている(例えば、非特許文献4を参照)。
特開2011−186849号公報 特開2007−148689号公報 特開2010−224593号公報
「ゼンリンオンラインショップ」、[online]、[平成24年10月05日検索]、インターネット〈URL:http://shop.zenrin.co.jp/shop/customer_param/actionNameTxt/policy〉 「訪問者とはなんですか?」、[online]、[平成24年10月05日検索]、インターネット〈URL:http://mixi.jp/help.pl?mode=item&item=295〉 厚生労働省、「医療情報システムの安全管理に関するガイドライン 第4.1版」、平成22年2月、[online]、インターネット〈URL:http://www.mhlw.go.jp/shingi/2010/02/dl/s0202-4a.pdf〉 保健医療福祉情報システム工業会(JAHIS)、「ヘルスケア分野における監査証跡のメッセージ標準規約Ver1.1」、2010年02月、[online]、インターネット〈URL:http://www.jahis.jp/wp-content/uploads/st09-003.pdf〉
ところが、例えば、医療情報部門を運営する人は、内部監査として、患者の個人情報への不正アクセス有無の確認、業務に関わりのない個人情報にアクセスしていないかどうかといった目的外アクセスの有無の確認などを行ない、情報システムの適正な運営を維持することと、患者から問い合わせがあったときにきちんと説明できる必要があるが、上記のような技術では、これらに対応することができない。
特許文献1では、アクセス履歴情報は、あくまでもアクセス元認識情報を格納するものにすぎない。また、特許文献2は、利用者がPCの操作履歴を使用しているPCに蓄積しているため、アクセスログを自分のために使うことはできるが、他者からのアクセスに対するログではないため、アクセスした人を知ることはできない。また特許文献3は、あくまでも一般市民を対象としたサービスにおける履歴情報提供に関する技術であり、医療機関全体での履歴情報提供は考慮されていない。
一方、非特許文献1のように、Webブラウザを使ったサービスにおけるアクセスログとは、あくまでもWebサービスの運営者のために用いられるものであり、その結果が利用者に提供されることはないため、どのように使われたかを知るすべがない。また、非特許文献2の機能は、あくまでも利用者の知り合いがアクセスした履歴であり、赤の他人がアクセスした結果は残らないようになっている。これでは、不正な手段で自分のデータを見たかどうかを把握することができない。
この発明は上記事情に着目してなされたもので、その目的とするところは、複数のサーバに蓄積されたアクセスログを安全に管理し、検索する人の立場に応じて簡単に閲覧できるようにするアクセス履歴提供システム及びアクセス履歴提供方法を提供することにある。
上記目的を達成するためにこの発明に係るアクセス履歴提供システム及びアクセス履歴提供方法の第1の態様は、複数のデータサーバと、連携サーバと、アクセス履歴提供サービスサーバとがネットワークを介して接続されるアクセス履歴提供システムにおいて、前記データサーバは、当該データサーバへのデータアクセス者のユーザ識別子と仮名とサーバ識別子とを含むアクセスログを出力し、前記連携サーバは、各サーバ毎に管理されるユーザ識別子を仮名を介して連携させる。前記アクセス履歴提供サービスサーバは、前記データサーバから前記アクセスログを収集し、前記アクセスログに含まれる仮名とサーバ識別子と、自サーバのサーバ識別子とに基づいて前記連携サーバから自サーバにおけるユーザの仮名を取得し、取得した仮名に対応する自サーバのユーザ識別子と、前記アクセスログを収集したデータサーバのユーザ識別子およびサーバ識別子とを対応付けて登録し、前記アクセスログに前記自サーバのユーザ識別子を追加してアクセス履歴ログへ変換し、前記アクセス履歴ログに対するアクセス権限を前記自サーバのユーザ識別子に付与し、自サーバにログインするユーザ識別子をもとに前記アクセス履歴ログを検索するものである。
上記第1の態様によれば、アクセス履歴検索・閲覧サービスを提供するにあたり、提供サービスにわざわざユーザ登録をしなくても、アクセスログから自動的に登録すべきユーザを抽出し、かつ本人しかアクセスできないようにアクセス制御も設定することが可能となる。これによりユーザは特別な手続きをせずに自分のデータへのアクセス状況をいつでも確認することが可能となる。
この発明の第2の態様は、上記第1の態様において、前記アクセス履歴提供サービスサーバは、前記アクセスログに含まれる識別子に対応する説明文をマスタ情報として格納し、前記変換において、前記マスタ情報をもとに前記アクセスログに含まれる識別子に対応する前記説明文を前記アクセス履歴ログに追加するものである。
上記第2の態様によれば、アクセスログに出力される様々な情報が数字や英語等の識別子で記載されている場合でも、利用者が理解しやすい表記でアクセス履歴を閲覧・検索結果を提供することが可能となる。
この発明の第3の態様は、上記第1又は第2の態様において、前記検索において、自サーバにログインするユーザ識別子に複数の組織又は資格が対応付けられている場合は、前記組織又は資格の少なくとも1つを選択させ、前記組織又は資格の組み合わせに対応する前記アクセス履歴ログを検索するものである。
上記第3の態様によれば、例えば、複数の病院に従事している医療従事者が市民(患者)の医療情報を閲覧する際には、組織を一意に特定し、どの立場で閲覧したのかを明確に示すことが可能となる。また、病院の内部監査実施のために、ある資格を有する操作者に対しては、市民(患者)の医療情報へのアクセスを特定の組織で絞り込んで検索できるようになる。
この発明の第4の態様は、上記第1又は第2の態様において、前記検索において、自サーバにログインするユーザ識別子が他のユーザから代理人として前記アクセス履歴ログへのアクセス権限の委託を受けている場合は、前記ログインしたユーザ識別子又は前記委託を受けた他のユーザのユーザ識別子をもとに前記アクセス履歴ログを検索するものである。
上記第4の態様によれば、代理人の場合は、自分自身のアクセス履歴ログを検索するか、委託を受けた患者のアクセス履歴ログを検索するかの2パターンを実行することが可能となる。
すなわちこの発明によれば、複数のサーバに蓄積されたアクセスログを安全に管理し、検索する人の立場に応じて簡単に閲覧できるようにするアクセス履歴提供システム及びアクセス履歴提供方法を提供することができる。
本発明の一実施形態に係るアクセス履歴提供システムを構成する各サーバの機能構成図。 サーバに蓄積されるアクセスログの一例を示す図。 アクセス履歴提供サービスサーバから提供されるアクセス履歴ログの一例を示す図。 各サーバのユーザIDとアクセス履歴提供サービスサーバのユーザIDとの対応関係を示す図。 アクセス履歴ログ検索画面の一例を示す図。 アクセス履歴ログ検索結果画面の一例を示す図。 アクセス履歴ログ検索処理の一例を示すシーケンス図。 アクセス履歴ログ検索処理の一例を示すシーケンス図。
以下、図面を参照してこの発明に係る実施の形態について詳細に説明する。
図1は、本発明の一実施形態に係るアクセス履歴提供システムを構成する各サーバの機能構成図である。クライアント端末1、要求側サーバ2、提供側サーバ3、連携サーバ4、およびアクセス履歴提供サービス5は、ネットワークを介して接続されている。また、各サーバ2〜5はトラストサークルでID連携されている。要求側サーバ2、提供側サーバ3の基本構成は同じである。要求側サーバ2は、他のサーバからの問い合わせに対応するときは、情報を提供するため、提供側サーバとして振る舞う。逆に提供側サーバ3は、他のサーバに問い合わせるときは要求側サーバとして振る舞うためである。
このアクセス履歴提供システムは、例えば、トラストサークル上で動作する医療分野における情報システムを使用する状況において、各サーバに格納される電子カルテや検査結果といった患者の医療情報に対するアクセスログを、検索する人に分かりやすい表記に置き換えたものをアクセス履歴ログとして保存し、アクセスログに出力されているユーザを抽出して、アクセス履歴ログが検索できるように、アクセス制御ルールを自動登録し、かつ検索する立場の違いによるアクセス制御を適用して、アクセス履歴ログを検索した結果を提示する。
[クライアント端末の構成]
クライアント端末1はWebブラウザ110を有する。ユーザは、クライアント端末1にインストールされているWebブラウザ110を使って要求側サーバ2にアクセスする。要求側サーバ2は、クライアント端末1からの要求を受け付ける。要求側サーバ2は、自サーバ内で解決できればサービスを提供するが、解決できない場合は、該当する提供側サーバ3にサービス提供を依頼する。
[各サーバの基本構成]
各サーバ2〜5は、例えば、ID管理プログラム100、コアモジュール部200、アプリケーションプログラム格納部300の3つの部を有するものとする。ID管理プログラム100は、SAML(Security Assertion Markup Language)101やID−WSF(Identity Web Service Framework)102の機能を有する。
ID管理プログラム100を実行することにより、SAML101で認証されたユーザが、ID−WSF102でユーザの属性情報を交換して、要求するデータにアクセスできるかどうかを判断し、アクセス可能であれば、要求するデータに関する情報をID−WSF102で問い合わせ、検索結果をID−WSF102を使ってユーザに提示する。なお、SAMLとは、インターネット経由でセキュリティ情報を交換するためのXMLベースのフレームワーク、ID−WSFとは、Liberty Alliance Projectによって策定された、異なるサイト間でユーザの意思に基づき属性情報を安全に流通するための仕様である。
SAML101によるID連携では、ユーザ情報を扱う1つのアイデンティティプロバイダ(IdP: Identity Provider)と、複数のサービスプロバイダ(SP: Service Provider)との間のトラストサークルに基づいて行なわれる。本実施形態では、IdPを連携サーバ4、SPを要求側サーバ2、提供側サーバ3と呼んでいる。ID連携の実現方法として、仮名(かめい)を採用する。仮名を使うのは、実ユーザのIDが漏れるのを防ぐのと、別々のサーバのユーザIDを直接対応付けないことで、個人情報が漏れるのを防ぐ役割を果たす。ID管理プログラム100は、自サーバが管理するユーザIDと仮名とを対応付けた「サーバユーザID/仮名マッピングデータ」を有する。
コアモジュール部200は、認証連携部201、ID連携部202、Webアクセス受付部203、アクセス制御判定部204、ユーザアクセス制御リスト格納部205、ローカルデータアクセス部206、ユーザ情報格納部207、アプリケーションデータ格納部208、リモートデータアクセス部209、情報流通部210、ログ出力部211、監査ログ212、及びアクセスログ213を有する。
認証連携部201は、シングルサインオン(SSO: Single Sign-On)、シングルログアウト(SLO: Single Log-Out)など、用途に応じたユーザ認証を実施する。ID連携部202は、各サーバで提供されるサービスのユーザIDを仮名を介して紐付ける。Webアクセス受付部203は、Webブラウザから要求されたHTTPリクエストを受け付けて解析を行なう。アクセス制御判定部204は、ユーザアクセス制御リスト格納部205に設定されるアクセス制御ルールにしたがってユーザのデータへのアクセス可否を判断する。
ローカルデータアクセス部206は、要求側サーバ(自サーバ)のユーザ情報格納部207及びアプリケーションデータ格納部208が保有するテーブルへのデータのアクセスを実施する。リモートデータアクセス部209は、提供側サーバ(他のサーバ)にあるデータへのアクセスを実施し、他のサーバに問い合わせるための通信データを作成し、情報流通部210に渡す。情報流通部210は、受け取った通信データを暗号化して、ID管理プログラム100のID−WSF102に依頼して、他のサーバに送信する。
リモートデータアクセス部209は、ローカルデータアクセス部206の機能のうち、テーブル操作およびファイル操作を除いた機能である、リモートデータの検索・削除・取得・登録・更新の機能に加え、他サーバとのやり取りのための機能として、リモートデータアクセス要求・応答機能を有する。ローカルデータアクセス部206と同じく、これらの機能を実現するためのアプリケーションインタフェースが規定されている。また、リモートデータアクセス部209を使って、他のシステムのリモートデータアクセス部209を呼び出した後は、その中でローカルデータアクセス部206を呼び出すため、呼び出す操作や形式を統一しているので、ローカルデータアクセス部206と同じやり方を用いて、具体的な値を入力パラメータとして外部から指定させることで、上記機能を実現することができるようになっている。
各々のサーバにおいて、ユーザが存在するかどうかを確認するために、ローカルデータアクセス部206を通してユーザ情報格納部207へ問い合わせる。自サーバでユーザが存在しない場合は、他のサーバにリモートデータアクセス部209を経由して他のサーバのユーザ情報格納部207へ問い合わせる。アプリケーションデータ格納部208には、各々のサーバ上で動作するアプリケーションが用いる設定ファイルや個別データが格納される。サーバで提供されるサービスを利用する場合は、ユーザ情報をユーザ情報格納部207に登録する。
ログ出力部211は、上記のユーザ情報格納部207への問い合わせといった、サーバが有する個人情報等のデータへのアクセスがあった場合に、非特許文献4のログメッセージ規約等に従った監査ログ212を出力すると共に、アクセスログ213として情報を記録する。データはローカルデータアクセス部206を通じてアクセスされるので、ローカルアクセス部206からログ出力部211に必要な情報を渡し、ログ出力部211でアクセスログ213としてファイルに出力する。
図2に、アクセスログに出力される項目例を示す。斜線パターンが付されている項目(No.1、No.2、No.3、No.4、No.6、No.7)は、非特許文献4のログメッセージ規約で出力すべき項目として決められているものである。医師などの医療従事者が複数の病院に勤務していることはよくあることである。そこで、どの病院に勤務しているときに、市民(患者)の医療情報を見たかを特定するために、医療情報を閲覧するサービスにログインするタイミングで、所属する組織を選択させる。これにより、医師の所属組織を一意に決定することができるため、アクセスログの図2のNo.11にも所属組織が1つだけ出力されるようになる。
アプリケーションプログラム格納部300には、特定のサービスを実現させるために必要となるアプリケーションが格納される。認証APL301は、すべてのサーバに格納されているアプリケーションプログラムである。コアモジュール部200に格納されている部品で特定のサービスを実現できないときには、必要な部品が追加される。
[連携サーバの構成]
連携サーバ4は、上記機能に加え、各サーバが有するサーバに関する情報や使用する認証方式が格納されているサーバ情報格納部215と、ユーザが所属する組織や資格に関する情報を格納するマスタ情報格納部214とを有する。なお、資格とは、例えば、ISO17090で定義された医療従事者の資格や、国家資格名である「医師」「看護師」「救急救命士」などや、医療機関の管理責任者である「病院長」「保険薬局の管理責任者」などである。新しく組織を追加したい場合には、マスタ情報格納部214にアクセスして新規組織名を登録する。組織情報は、マスタ情報格納部214で一意に区別できる組織IDと、その説明文の組み合わせで登録される。例えば、新規組織IDとして「A_GenHos」、説明文として「A総合病院」として登録される。サーバ間でやり取りされる情報は組織IDとなる。
[アクセス履歴提供サービスサーバの構成]
アクセス履歴提供サービスサーバ5は、要求側サーバ2の構成に加え、さらにアクセス履歴提供サービスに必要となる構成を追加している。アプリケーションプログラム格納部300には、ユーザへの画面表示の制御を実施するアクセス履歴ログ検索アプリケーション302が格納される。コアモジュール部200には、アクセスログ収集部221、アクセスログ登録部222、アクセス履歴ログ格納部223、及びアクセス履歴ログ検索部224が追加され、連携サーバ4に格納されているマスタ情報格納部214とサーバ情報格納部215が保存される。
アクセスログ収集部221は、サーバ情報格納部215に格納される情報をもとに各々のサーバで出力されたアクセスログを収集する。アクセスログ登録部222は、アクセスログ収集部221により収集されたアクセスログを解析して、英数字で記載された文字列やIDといった識別子のうち、説明文を保有しているものは、新たにその説明文を追加してアクセス履歴ログとして保存し、アクセス履歴ログ格納部223に登録する。図3にアクセス履歴ログの項目例を示す。図3の斜線パターンの部分が、識別子の説明文を追加した項目となる。また、アクセスログ登録部222は、登録されたアクセス履歴ログをユーザが検索できるようにするために、ユーザアクセス制御リスト格納部205にアクセス制御ルールを設定する。
アクセス履歴ログ検索部224は、市民(患者や代理人)が自己のデータのアクセス履歴を検索する、あるいは内部監査のため医療機関である特定の権限を持った人がアクセス履歴を検索して結果を表示するための機能を提供する。アクセス履歴提供サービスサーバ5は、アクセスログに含まれる識別子のうち、説明文を保有しているものがあるかどうかを検索するために、連携サーバ4に格納されているマスタ情報格納部214を保存している。図2のNo.5,6,11,12,13,15が該当する。
次に、アクセス履歴提供サービスサーバ5の動作について説明する。図4には、アクセスログ収集からアクセスログ登録までの処理の流れを示す。
[アクセスログ収集]
アクセス履歴提供サービスサーバ5のアクセスログ収集部221は、図4の(1)の矢印に示すように、各サーバに蓄積されているアクセスログを収集する。収集方法として、例えば、手動でサーバからサーバにコピーする方法、該当するファイルをメールでアクセス履歴提供サービスサーバ5の運用者に送る方法などいくつか考えられる。アクセス履歴を閲覧するサービスを利用するためには、アクセスログを提供することが必要であることから、アクセス履歴提供サービスサーバ5からSCP(Secure Copy)などのセキュリティの高いファイル転送を行なう方法もある。これは認証情報ややり取りされるデータが暗号化されてネットワーク上を流れるため、アクセス履歴提供サービスサーバ5の特定のユーザのみアクセス許可を出すことにより、各サーバのアクセスログを安全に収集することが可能となる。前回の収集日付を記録しておくことで、前回からの差分となるアクセスログを収集できるため、効率よく作業を行なうことができる。なお、複数のサーバで同じログファイル名がついている可能性もあることから、収集したアクセスログを保存するディレクトリ名に、収集するサーバを一意に特定する名称を付けて区別できるようにしておく必要がある。
[アクセスログ登録]
アクセスログ登録部222は、アクセスログ収集部221から収集完了通知を受けると、アクセスログ213を解析してアクセス履歴ログに変換して、アクセス履歴ログ格納部223に登録する処理を実施する。
アクセスログ213に出力される様々な情報が、数字や英語(文字の省略も含む)といった、コンピュータが処理しやすい文字列で記載されており、人が見てわかりやすい表記にはなっていない場合がある。そのためには、マスタ情報格納部214に登録されている識別子と説明文とを対応付けて、識別子と説明文の両方を格納する。従って、アクセスログ登録の準備として、マスタ情報格納部214に格納されているデータをメモリ上に保持しておく。
次に、アクセスログ登録部222は、アクセスログ収集で得られたアクセスログファイルを解析し、図2のアクセスログのNo.8とNo.9の組である「アクセスされたデータが表す患者の仮名とログ出力サーバの識別子」のリスト、No.5とNo.9の組である「データアクセス者の仮名とログ出力サーバの識別子」リストを作成する。これは、アクセス履歴提供サービスサーバ5のユーザIDとアクセスログを収集する各サーバのユーザIDとの対応付けをすることで、アクセス履歴提供サービスサーバ5のユーザIDでログインしても、ログインしたユーザに関係するすべてのサーバのアクセスログ213を検索できるようにするためである。
アクセス履歴提供サービスサーバ5は、自サーバにおけるユーザの仮名を取得するために、作成されたリストに記載されている仮名とログ出力サーバの識別子であるプロバイダIDを連携サーバ4に送信する。連携サーバ4は、受け取った仮名とプロバイダIDに基づき、連携サーバ4のユーザIDを検索する。得られたユーザIDとアクセス履歴提供サービスサーバ5の識別子をもとに、アクセス履歴提供サービスサーバ5の仮名を検索し、結果をアクセス履歴提供サービスサーバ5に返す。
図4の(2)の矢印を用いて処理の流れを示す。ここでは、サーバの識別子としてプロバイダIDを用いている。アクセス履歴提供サービスサーバ5は、A病院サーバのアクセスログ213から市民Xの仮名“4SG3H”を取り出したとすると、連携サーバ4には、“4SG3H”とA病院サーバのプロバイダIDが送られる。連携サーバ4は、ID管理プログラム100が有する「サーバユーザID/仮名マッピングデータ」を検索し、“4SG3H”の連携サーバ4でのユーザIDである“MES_x”を見つける。次に“MES_x”とアクセス履歴提供サービスサーバ5のプロバイダIDを用いて「サーバユーザID/仮名マッピングデータ」を検索し、アクセス履歴提供サービスサーバ5の仮名である“abcdefg”を取得する。取得した仮名をアクセス履歴提供サービスサーバ5に返す。
そうすると、図4の(3)の矢印に示すように、アクセス履歴提供サービスサーバ5は、受け取った仮名“abcdefg”でサーバユーザID/仮名マッピングデータ」を検索し、自サーバのユーザID“rireki_001”を取得する。
この後、アクセスログ登録部222は、図4の(4)の矢印に示すように、アクセスログを収集したサーバでのユーザIDと、アクセス履歴提供サービスサーバ5のユーザIDとの対応付けを、アクセス履歴ログ格納部223のアクセス履歴テーブルに格納する。
アクセスログ213に記載されている各サーバのユーザIDと合わせて、アクセス履歴提供サービスサーバ5のユーザIDを、新たに変換するアクセス履歴ログに書き加える。医療従事者の場合は、図2のアクセスログのNo.5に対して、図3のアクセス履歴ログのNo.8が追加された項目となる。市民(患者)の場合は、図2のアクセスログのNo.8に対して、図3のアクセス履歴ログのNo.12が追加された項目となる。この処理を実施することで、アクセス履歴提供サービスサーバ5のユーザIDを指定すれば、複数のサーバで出力されたアクセスログを検索できるようになる。
次に、ユーザIDのユーザデータを取得するため、アクセス履歴提供サービスサーバ5から連携サーバ4に問い合わせる。検索結果としてユーザの漢字氏名やカナ氏名が返ってくるので、これらをアクセス履歴ログに書き加える。図2のアクセスログのNo.4に対して、図3のアクセス履歴ログのNo.6およびNo.7が追加された項目となる。
マスタ情報格納部214には、所属組織、資格、認証方式の各々の識別子であるIDに対する説明文を保持している。従って、アクセス履歴提供サービスサーバ5のマスタデータを検索し、説明文を、ユーザの情報と同じくアクセス履歴ログに書き加える。図2のアクセスログのNo.11、No.12、No.13に対して、図3のアクセス履歴ログのNo.14、No.16、No.18が追加された項目となる。
アクセス制御ルールも、所属組織、資格などの識別子であるIDで書かれているので、マスタ情報格納部214を参照して該当する説明文をアクセス履歴ログに書き加える。図2のアクセスログのNo.16に対して、図3のアクセス履歴ログのNo.21が追加された項目となる。
上記のように作成したアクセス履歴テーブルに新規に登録されたユーザは、アクセス履歴ログにアクセスする権限を持たない。そこで、アクセス履歴ログをアクセス履歴ログ格納部223に登録するときに、新規登録ユーザがアクセスできるように、自動的にユーザアクセス制御リスト格納部205にアクセス制御ルールを追加し、新規登録ユーザにアクセス権限を付与する。
代理人は、事前に患者の申請に基づき決定されるものである。すなわち、患者自身が、患者に関するデータやログを誰に閲覧させるかを決めて、その人に対して、アクセス権限を与えることになる。従って、代理人の場合は、自分自身のアクセス履歴ログを検索するか、委託を受けた患者のアクセス履歴ログを検索するかの2パターンを実行することができる。
[アクセスログ検索]
アクセス履歴ログ検索部224は、上記のアクセスログ登録処理で登録されたアクセス履歴ログに対して検索処理を実施する。図5に、アクセス履歴ログ検索画面を示し、図6には、アクセス履歴ログ検索結果画面を示す。これらの画面は、アクセス履歴ログ検索アプリケーション302により出力される。
利用者は、この検索サービスを使うためにアクセス履歴ログ検索アプリケーション302にアクセスする。このアプリケーションからログインするときに、複数の組織に所属する利用者がログインする場合は、上記と同じく必ず組織を選択させるようにする。なお、市民(患者)や代理人は組織に属さないため、組織を選択する必要がない。一方、操作者も市民であるが、業務用のログインIDと市民として使うときのログインIDは異なるものとしている。これにより、操作者が自分の医療情報のアクセス履歴ログを検索したい場合は、市民のログインIDを指定して検索すればよい。
市民(患者)が自分のアクセス履歴ログを検索するときは、検索対象は「検索結果に自分を含める」ものとなる。代理人が委託を受けた市民(患者)のアクセス履歴ログを検索するときは、検索対象は「検索結果に自分を含めない」ものとし、かつ「対象ユーザログインID」に、市民(患者)のIDを入力することになる。
一方、病院の内部監査実施のために、ある組織に所属し、かつある資格を有する操作者がアクセス履歴ログを検索するときは、検索対象は「検索結果に自分を含めない」ものとなる。これは、操作者は医療従事者ではなく、その病院のサーバを円滑に運営するための業務を行なっている人であり、市民(患者)の医療情報を見ることはもともと認められない立場にあるからである。アクセス制御ルールに、特定の組織名と特定の資格を有する人のみ、アクセス履歴ログを検索できるように記載することで、病院関係者の限られた人だけしか検索できないようにすることができる。
図5にある「対象ユーザログインID」、「データアクセス者漢字氏名」、「データアクセス者カナ氏名」、「ログ出力サーバ識別子」および「対象期間」は、アクセス履歴ログを検索するための絞り込み要素である。この画面は、利用者がログインできたときに、アクセス履歴ログ検索アプリケーション302により出力される。
図7A、図7Bは、アクセス履歴ログを検索するときの処理フローを示したものである。実施中には、結果がNGの場合もありうるが、ここではすべての処理が成功した例を示す。なお、図7Aにおいて、アクセス履歴提供サービスサーバ5のアクセス履歴ログ検索部224にのみ、サーバ起動時に各種設定ファイルをメモリ上に読み込むとしているが、アクセス履歴提供サービスサーバ5の他の部分や、連携サーバ4でも同様の処理が実施される。
市民(患者)、代理人または操作者は、クライアント端末1のWebブラウザ110にアクセス履歴ログを検索するページのURLを入力し、アクセス履歴提供サービスサーバ5のアクセス履歴ログ検索アプリケーション302に認証要求(S1)を送信する。アクセス履歴提供サービスサーバ5の認証連携部201は、アクセス履歴ログ検索アプリケーション302からSSOを受け付けると(S2)、連携サーバ4にSSOリダイレクト(S3)を行う。連携サーバ4の認証APL301は、SSOリダイレクトによる認証を受け付け、ID/パスワード認証実行(S4)を行い、ID/パスワード入力要求(S5)をクライアント端末1へ送信する。クライアント端末1は、市民(患者)、代理人または操作者によりログインIDとパスワードが入力されると(S6)、連携サーバ4へログインIDおよびパスワードを送信する(S7)。
連携サーバ4の認証APL301は、ログインIDおよびパスワードの認証についてOK/NG判定(S8)を行い、OKならば次の処理を行う。操作者と、市民(患者)や代理人との違いは、ログインIDおよびパスワードを連携サーバ4の認証APL301に送信した際、所属組織を選択させる画面が出力されるか否かである。操作者の場合は、1つもしくは2つ以上の組織に所属することが考えられる。所属組織を一意に決定するため、当該ログインユーザについて所属組織が見つかった場合は、組織選択要求(S9)を実施し、クライアント端末1に組織を選択させる画面を表示する。クライアント端末1は、操作者により組織の選択が行われると(S10)、選択した組織を連携サーバ4に返信(S11)する。認証APL301は、組織選択についてOK/NG判定(S12)を行い、OKであれば、SSO応答リダイレクト(S13)を実施する。一方、市民(患者)や代理人の場合は、連携サーバ4の認証APL301のログインID/パスワードの判定結果がOKであれば、SSO応答リダイレクト(S13)を実施する。
アクセス履歴提供サービスサーバ5の認証連携部201は、SSO結果を受け取ると(S14)、遷移すべきURL(アクセス履歴ログ検索)をクライアント端末1に送付する(S15)。ログインユーザによりアクセス履歴ログ検索画面の表示依頼があると(S16)、アクセス履歴ログ検索アプリケーション302は、クライアント端末1にアクセス履歴ログ検索画面(図5)を表示する(S17)。図7Bにおいて、ユーザが図5の画面で検索条件として必要な項目を入力して、検索実行ボタンを押下すると(S18)、クライアント端末1のWebブラウザ110により、検索条件がアクセス履歴提供サービスサーバ5に送信される(S19)。
アクセス履歴ログ検索アプリケーション302は、ユーザ情報や検索条件を含むアクセス履歴ログ検索依頼(S20)をアクセス履歴ログ検索部224に送信する。アクセス履歴ログ検索部224は、アクセス履歴ログ検索依頼を受け取ると、ローカルデータアクセス部206に対してアクセス履歴ログ検索(S21)を実施する。アクセス制御ルール判定(S22)では、アクセス履歴ログを検索する利用者が、アクセス履歴ログに対する検索操作権限があるか否かを、ユーザアクセス制御リスト格納部205のアクセス制御ルールに基づいて判定する。アクセス履歴ログに対する検索操作権限がない場合は、サービスが提供できないメッセージを表示して処理を終了する。アクセス履歴ログに対する検索操作権限がある場合は、検索条件に基づきアクセス履歴ログ格納部223からアクセス履歴ログを検索し(S23)、検索した結果をアクセス履歴ログ検索部224を経由してアクセス履歴ログ検索アプリケーション302に返す(S24,S25)。アクセス履歴ログ検索アプリケーション302は、検索結果に基づいてアクセス履歴ログ検索結果画面(図6)を作成し、クライアント端末1に表示する(S26)。
図6は、市民(患者)が検索したアクセス履歴ログ検索結果を示したものである。図3に示したアクセス履歴ログに書かれている項目のうち、No.11の「アクセスされたデータが表す患者の識別子」と市民(患者)のログインIDが一致するものが検索結果として抽出され、画面に表示される。また、アクセスログ登録の過程で名称変更された項目については、説明文で表示されるようになる。
以上述べたように、本実施形態によれば、市民(患者)はアクセスログから自動登録され、かつアクセス履歴ログへのアクセス制御ルールも自動的に書き加えられるため、特別な手続きをせずに、自分のデータへのアクセス状況をいつでも確認することができる。
複数の医療従事者に対しては、どの病院の医師として患者のデータを閲覧するかを明示する方法として、事前に組織を選択させることにより、患者にどの病院のどの医師が自分のデータを見たかを提示することができる。
また、本実施形態で実現することは、市民(患者)に関係するデータへのアクセスの状況をアクセスログから抽出して表示することであり、アクセス者のデータ閲覧の成功/失敗にかかわらず結果を確認できる。これにより、市民(患者)に関するデータが許可していない人に見えていないか、あるいは不正なアクセス行為をされていないかを確認することができる。
さらに、病院の内部監査実施のために、ある資格を有する操作者に対しては、市民(患者)の医療情報へのアクセスを特定の組織で絞り込んで検索できるようにする。これにより、ある特定の医療機関の組織名とアクセス者の資格情報の両方を組み合わせることにより、他の医療機関の医師がアクセスしたログは排除し、自分の所属する医療機関における内部監査を実施することが可能となる。
なお、この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
1…クライアント端末、2…要求側サーバ、3…提供側サーバ、4…連携サーバ、5…アクセス履歴提供サービスサーバ、110…Webブラウザ、100…ID管理プログラム、101…SAML、102…ID−WSF、200…コアモジュール部、201…認証連携部、202…ID連携部、203…Webアクセス受付部、204…アクセス制御判定部、205…ユーザアクセス制御リスト格納部、206…ローカルデータアクセス部、207…ユーザ情報格納部、208…アプリケーションデータ格納部、209…リモートデータアクセス部、210…情報流通部、211…ログ出力部、212…監査ログ、213…アクセスログ、214…マスタ情報格納部、215…サーバ情報格納部、221…アクセスログ収集部、222…アクセスログ登録部、223…アクセス履歴ログ格納部、224…アクセス履歴ログ検索部、300…アプリケーションプログラム格納部、301…認証APL、302…アクセス履歴ログ検索アプリケーション。

Claims (8)

  1. 複数のデータサーバと、連携サーバと、アクセス履歴提供サービスサーバとがネットワークを介して接続されるアクセス履歴提供システムであって、
    前記データサーバは、
    当該データサーバへのデータアクセス者のユーザ識別子と仮名とサーバ識別子とを含むアクセスログを出力するログ出力手段を具備し、
    前記連携サーバは、
    各サーバ毎に管理されるユーザ識別子を仮名を介して連携させる連携手段を具備し、
    前記アクセス履歴提供サービスサーバは、
    前記データサーバから前記アクセスログを収集する収集手段と、
    前記アクセスログに含まれる仮名とサーバ識別子と、自サーバのサーバ識別子とに基づいて前記連携サーバから自サーバにおけるユーザの仮名を取得し、取得した仮名に対応する自サーバのユーザ識別子と、前記アクセスログを収集したデータサーバのユーザ識別子およびサーバ識別子とを対応付けて登録する登録手段と、
    前記アクセスログに前記自サーバのユーザ識別子を追加してアクセス履歴ログへ変換する変換手段と、
    前記アクセス履歴ログに対するアクセス権限を前記自サーバのユーザ識別子に付与する付与手段と、
    自サーバにログインするユーザ識別子をもとに前記アクセス履歴ログを検索する検索手段と
    を具備することを特徴とするアクセス履歴提供システム。
  2. 前記アクセス履歴提供サービスサーバは、前記アクセスログに含まれる識別子に対応する説明文をマスタ情報として格納するマスタ情報格納手段をさらに具備し、
    前記変換手段は、前記マスタ情報をもとに前記アクセスログに含まれる識別子に対応する前記説明文を前記アクセス履歴ログに追加することを特徴とする請求項1に記載のアクセス履歴提供システム。
  3. 前記検索手段は、自サーバにログインするユーザ識別子に複数の組織又は資格が対応付けられている場合は、前記組織又は資格の少なくとも1つを選択させ、前記組織又は資格の組み合わせに対応する前記アクセス履歴ログを検索することを特徴とする請求項1又は2に記載のアクセス履歴提供システム。
  4. 前記検索手段は、自サーバにログインするユーザ識別子が他のユーザから代理人として前記アクセス履歴ログへのアクセス権限の委託を受けている場合は、前記ログインしたユーザ識別子又は前記委託を受けた他のユーザのユーザ識別子をもとに前記アクセス履歴ログを検索することを特徴とする請求項1又は2に記載のアクセス履歴提供システム。
  5. 複数のデータサーバと、連携サーバと、アクセス履歴提供サービスサーバとがネットワークを介して接続されるアクセス履歴提供システムに用いられる方法であって、
    前記データサーバにおいて、
    当該データサーバへのデータアクセス者のユーザ識別子と仮名とサーバ識別子とを含むアクセスログを出力するログ出力ステップを有し、
    前記連携サーバにおいて、
    各サーバ毎に管理されるユーザ識別子を仮名を介して連携させる連携ステップを有し、
    前記アクセス履歴提供サービスサーバにおいて、
    前記データサーバから前記アクセスログを収集する収集ステップと、
    前記アクセスログに含まれる仮名とサーバ識別子と、自サーバのサーバ識別子とに基づいて前記連携サーバから自サーバにおけるユーザの仮名を取得し、取得した仮名に対応する自サーバのユーザ識別子と、前記アクセスログを収集したデータサーバのユーザ識別子およびサーバ識別子とを対応付けて登録する登録ステップと、
    前記アクセスログに前記自サーバのユーザ識別子を追加してアクセス履歴ログへ変換する変換ステップと、
    前記アクセス履歴ログに対するアクセス権限を前記自サーバのユーザ識別子に付与する付与ステップと、
    自サーバにログインするユーザ識別子をもとに前記アクセス履歴ログを検索する検索ステップと
    を具備することを特徴とするアクセス履歴提供方法。
  6. 前記アクセス履歴提供サービスサーバは、前記アクセスログに含まれる識別子に対応する説明文をマスタ情報として格納し、
    前記変換ステップは、前記マスタ情報をもとに前記アクセスログに含まれる識別子に対応する前記説明文を前記アクセス履歴ログに追加することを特徴とする請求項5に記載のアクセス履歴提供方法。
  7. 前記検索ステップは、自サーバにログインするユーザ識別子に複数の組織又は資格が対応付けられている場合は、前記組織又は資格の少なくとも1つを選択させ、前記組織又は資格の組み合わせに対応する前記アクセス履歴ログを検索することを特徴とする請求項5又は6に記載のアクセス履歴提供方法。
  8. 前記検索ステップは、自サーバにログインするユーザ識別子が他のユーザから代理人として前記アクセス履歴ログへのアクセス権限の委託を受けている場合は、前記ログインしたユーザ識別子又は前記委託を受けた他のユーザのユーザ識別子をもとに前記アクセス履歴ログを検索することを特徴とする請求項5又は6に記載のアクセス履歴提供方法。
JP2012250005A 2012-11-14 2012-11-14 アクセス履歴提供システム及びアクセス履歴提供方法 Active JP5593370B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012250005A JP5593370B2 (ja) 2012-11-14 2012-11-14 アクセス履歴提供システム及びアクセス履歴提供方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012250005A JP5593370B2 (ja) 2012-11-14 2012-11-14 アクセス履歴提供システム及びアクセス履歴提供方法

Publications (2)

Publication Number Publication Date
JP2014099017A JP2014099017A (ja) 2014-05-29
JP5593370B2 true JP5593370B2 (ja) 2014-09-24

Family

ID=50940990

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012250005A Active JP5593370B2 (ja) 2012-11-14 2012-11-14 アクセス履歴提供システム及びアクセス履歴提供方法

Country Status (1)

Country Link
JP (1) JP5593370B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11216584B2 (en) 2017-07-18 2022-01-04 Fujifilm Business Innovation Corp. Management server, data viewing system, and non-transitory computer readable medium

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018136626A (ja) * 2017-02-20 2018-08-30 Kddi株式会社 アクセス制御装置、アクセス制御方法及びアクセス制御プログラム
JP7238498B2 (ja) * 2019-03-13 2023-03-14 富士フイルムビジネスイノベーション株式会社 情報処理装置及びプログラム
CN111352552B (zh) * 2020-03-30 2021-09-10 北京达佳互联信息技术有限公司 一种应用登录方法、装置、电子设备及存储介质
JP7458270B2 (ja) 2020-08-24 2024-03-29 株式会社日立製作所 ユーザ認証支援装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2491748C2 (ru) * 2006-06-22 2013-08-27 Конинклейке Филипс Электроникс, Н.В. Иерархическая детерминированная схема предварительного распределения парных ключей
JP4847483B2 (ja) * 2008-03-10 2011-12-28 日本電信電話株式会社 個人属性情報提供システムおよび個人属性情報提供方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11216584B2 (en) 2017-07-18 2022-01-04 Fujifilm Business Innovation Corp. Management server, data viewing system, and non-transitory computer readable medium

Also Published As

Publication number Publication date
JP2014099017A (ja) 2014-05-29

Similar Documents

Publication Publication Date Title
JP7335943B2 (ja) Bcn(ブロックチェーンネットワーク)を使用したデータ利用方法、システムおよびそのプログラム
JP5669250B2 (ja) 情報アクセス制御システムとそのサーバ装置及び情報アクセス制御方法
CN104255007B (zh) Oauth框架
JP4848407B2 (ja) 分散情報連携システム及び分散情報連携方法
US20070016450A1 (en) Global health information system
TWI700707B (zh) 取得電子醫療健康記錄的方法與系統
JP5593370B2 (ja) アクセス履歴提供システム及びアクセス履歴提供方法
US20110112970A1 (en) System and method for securely managing and storing individually identifiable information in web-based and alliance-based networks using a token mechanism
RU2510968C2 (ru) Способ доступа к персональным данным, таким как индивидуальный медицинский файл, с использованием локального формирующего компонента
CA2455970A1 (en) Web-based security with controlled access to data and resources
JP4871991B2 (ja) 情報アクセス制御システムとそのサーバ装置、情報アクセス制御方法、アクセス制御ルール設定制御方法
JP2010186249A (ja) 分散情報アクセスシステム、分散情報アクセス方法及びプログラム
JP5090425B2 (ja) 情報アクセス制御システム及び方法
JP2008225573A (ja) 代理サーバ、代理サーバのためのプログラム及び代理アクセス方法
Yongjoh et al. Development of an internet-of-healthcare system using blockchain
JP5777666B2 (ja) 医療関連データの統合情報処理システム
KR20200062058A (ko) 데이터 관리 시스템 및 데이터 관리 방법
JP5433647B2 (ja) ユーザ認証システム、方法、プログラムおよび装置
Ma et al. An agent-based infrastructure for secure medical imaging system integration
JP6118128B2 (ja) 認証システム
JP2005284353A (ja) 個人情報利用システム、個人情報利用システムの制御方法、マップファイル生成装置、及びアクセス制御ポリシファイル生成装置
Abdeen et al. Fusing identity management, HL7 and Blockchain into a global healthcare record sharing architecture
JP5616293B2 (ja) 情報流通システム及び情報流通制御方法
JP6078459B2 (ja) 情報管理システムとそのデータ連携方法
JP5641175B2 (ja) 検索対象管理システム及び検索対象管理方法

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140729

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140804

R150 Certificate of patent or registration of utility model

Ref document number: 5593370

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150