(57)【要約】【課題】認証処理を効率良く行うこと。【解決手段】認証装置１０は、デバイス３０から個人識別情報を受信した場合に、デバイス３０の識別番号それぞれに対応づけた個人識別情報を記憶した複数のデータベースから、個人識別情報を受信したデバイス３０の識別番号と一致するデバイス３０の識別番号に対応付けた個人識別情報を特定し、特定した個人識別情報とデバイス３０から受信した個人識別情報との比較結果に基づいて認証を行う。【選択図】図３
2020013288.tif 000002
【特許請求の範囲】
【請求項１】
端末から受信した個人識別情報を利用した認証をサーバ上で行う認証プログラムであって、
前記端末から個人識別情報を受信した場合に、端末の識別番号それぞれに対応づけた個人識別情報を記憶した複数のデータベースから、前記個人識別情報を受信した端末の識別番号と一致する端末の識別番号に対応付けた個人識別情報を特定し、
特定した前記個人識別情報と端末から受信した個人識別情報との比較結果に基づいて認証を行う処理をコンピュータに実行させることを特徴とする認証プログラム。
【請求項２】
前記個人識別情報は生体情報であることを特徴とする請求項１に記載の認証プログラム。
【請求項３】
前記認証が成功した後に前記端末のセッション情報を生成するとともに、
前記セッション情報に対応付けて前記セッション情報を生成した際の前記端末のＩＰアドレスを記憶し
前記端末に対し送信した前記セッション情報を前記端末から受信した際に、前記端末から受信したＩＰアドレスと、前記セッション情報を生成した際の前記端末のＩＰアドレスとが一致するか否かに応じて前記セッション情報の利用を制御する処理をコンピュータに実行させることを特徴とする請求項１または２に記載の認証プログラム。
【請求項４】
前記認証が成功した後に前記端末のセッション情報を生成するとともに、
前記セッション情報に対応付けて、前記認証の際に前記端末で利用されたアプリケーションの情報を取得し、
記憶部に記憶したアプリケーションそれぞれに対応付けた前記アプリケーションのセッション情報を利用可能な領域の情報及び前記アプリケーションを利用した前記端末の移動があった際における前記セッション情報の継続時間との情報に基づいて前記端末のセッション情報の利用を制御する処理をコンピュータに実行させることを特徴とする請求項１乃至３のいずれか一項に記載の認証プログラム。
【請求項５】
端末から受信した個人識別情報を利用した認証をサーバ上で行う認証方法であって、
前記端末から個人識別情報を受信した場合に、端末の識別番号それぞれに対応づけた個人識別情報を記憶した複数のデータベースから、前記個人識別情報を受信した端末の識別番号と一致する端末の識別番号に対応付けた個人識別情報を特定し、
特定した前記個人識別情報と端末から受信した個人識別情報との比較結果に基づいて認証を行う処理を前記サーバが実行することを特徴とする認証方法。
【請求項６】
端末から受信した個人識別情報を利用した認証を行う認証装置であって、
前記端末から個人識別情報を受信した場合に、端末の識別番号それぞれに対応づけた個人識別情報を記憶した複数のデータベースから、前記個人識別情報を受信した端末の識別番号と一致する端末の識別番号に対応付けた個人識別情報を特定する特定部と、
特定した前記個人識別情報と端末から受信した個人識別情報との比較結果に基づいて認証を行う認証部と、
を有することを特徴とする認証装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証プログラム、認証方法及び認証装置に関する。
【背景技術】
【０００２】
本人認証の一例として、静脈や指紋、手形、顔、声紋、虹彩といった各種の生体認証が用いられる。このような生体認証の認証方式の１つとして、「１：１認証」と「１：Ｎ認証」が挙げられる。すなわち、１：１認証とは、利用者からＩＤ（IDentification）等の識別情報と生体情報の入力を受け付け、入力を受け付けた生体情報とＩＤに対応付けられた生体情報とを照合する方式を指す。また、１：Ｎ認証とは、入力を受け付けた生体情報と、登録が行われたＮ個の生体情報とを照合する方式を指す。
【０００３】
これら１：１認証及び１：Ｎ認証のうち、１：１認証には、利用者の生体情報と共にＩＤ等の入力を受け付ける手間がある一方で、１：Ｎ認証には、そのような手間がない。このため、１：Ｎ認証は、１：１認証よりも利便性という側面で有利な一面を持つ。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−１９８１７０号公報
【特許文献２】特開２００１−３５０７１８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記の１：Ｎ認証では、生体情報の登録数Ｎが多いほど認証の処理量が増大するので、認証処理を効率良く行うことが困難であるという一面がある。
【０００６】
１つの側面では、本発明は、認証処理を効率良く行うことができる認証プログラム、認証方法及び認証装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
一態様では、認証プログラムは、端末から受信した個人識別情報を利用した認証をサーバ上で行う認証プログラムであって、前記端末から個人識別情報を受信した場合に、端末の識別番号それぞれに対応づけた個人識別情報を記憶した複数のデータベースから、前記個人識別情報を受信した端末の識別番号と一致する端末の識別番号に対応付けた個人識別情報を特定し、特定した前記個人識別情報と端末から受信した個人識別情報との比較結果に基づいて認証を行う処理をコンピュータに実行させる。
【発明の効果】
【０００８】
認証処理を効率良く行うことができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、実施例１に係る認証システムの構成例を示す図である。
【図２】図２は、課題解決のアプローチの一側面を示す図である。
【図３】図３は、実施例１に係る認証装置の機能的構成の一例を示すブロック図である。
【図４】図４は、利用者マスタのデータ構造の一例を示す図である。
【図５】図５は、認証候補リストのデータ構造の一例を示す図である。
【図６】図６は、実施例１に係る認証処理の手順を示すフローチャートである。
【図７】図７は、実施例２に係る認証装置の機能的構成の一例を示すブロック図である。
【図８】図８は、セッションＩＤの生成方法の一例を示す図である。
【図９】図９は、セッション情報の一例を示す図である。
【図１０】図１０は、ポリシー設定の一例を示す図である。
【図１１】図１１は、エリアおよびＮＷセグメントの対応関係の一例を示す図である。
【図１２】図１２は、実施例２に係る認証処理の手順を示すフローチャートである。
【図１３】図１３は、実施例２に係る判定処理の手順を示すフローチャートである。
【図１４】図１４は、実施例１〜実施例２に係る認証プログラムを実行するコンピュータのハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１０】
以下に添付図面を参照して本願に係る認証プログラム、認証方法及び認証装置について説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【実施例１】
【００１１】
［システム構成］
図１は、実施例１に係る認証システムの構成例を示す図である。図１に示す認証システム１は、デバイス３０Ａ〜３０Ｋにおけるユーザ認証を１：Ｎの生体認証によって実現する認証サービスを提供するものである。以下、デバイス３０Ａ〜３０Ｋのことを総称して「デバイス３０」と記載する場合がある。
【００１２】
このようなユーザ認証のユースケースの一例として、デバイス３０へのログインを始め、アプリケーションやリソースへのアクセスなどの個別のサービスを一度のユーザ認証で横断的に使用させる仕組み、いわゆるＳＳＯ（Single  Sign-On）を提供する例が示されている。ここで挙げるユースケースはあくまで一例であり、施設、部屋やブースなどのエリアの出入口への入退室管理等にも上記のユーザ認証を適用することもできるのは言うまでもない。
【００１３】
図１に示すように、認証システム１には、認証装置１０と、デバイス３０Ａ〜３０Ｋとが含まれる。なお、図１には、あくまで一例として、３つのデバイス３０Ａ〜３０Ｋを例示したが、１つの認証装置１０に任意の台数のデバイス３０が含まれることとしてもかまわない。
【００１４】
これら認証装置１０及びデバイス３０は、所定のネットワークＮＷを介して、通信可能に接続される。このようなネットワークＮＷには、有線または無線を問わず、ＬＡＮ（Local  Area  Network）などの構内回線網、インターネットやなどの公衆回線、あるいはモバイルネットワークなどの任意の通信網が対応する。
【００１５】
認証装置１０は、上記の認証サービスを提供するコンピュータである。
【００１６】
一実施形態として、認証装置１０は、パッケージソフトウェア又はオンラインソフトウェアとして、上記の認証サービスに対応する機能を実現する認証プログラムを任意のコンピュータにインストールさせることによって実装できる。例えば、認証装置１０は、上記の認証サービスをオンプレミスで提供するサーバ装置として実装することとしてもよいし、上記の認証サービスをアウトソーシングで提供するクラウドとして実装することとしてもかまわない。
【００１７】
デバイス３０は、上記の認証サービスの提供を受けるクライアントに対応する。このデバイス３０は「端末」の一例に対応する。例えば、デバイス３０Ａとして図示する通り、ノート型のパーソナルコンピュータであってもよいし、デバイス３０Ｂとして図示する通り、スマートフォンであってもよいし、あるいは、デバイス３０Ｋとして図示する通り、ウェアラブル端末であってもよい。ここで挙げる以外の他のコンピュータ、例えばラップトップ型のパーソナルコンピュータやタブレット端末がクライアントであってもかまわない。
【００１８】
デバイス３０には、図示しない生体センサが内蔵または付属される。生体センサは、認証システム１に採用される生体認証の種類に相応しい実装を選択することができる。あくまで一例として、生体認証として静脈認証が実施される場合、生体センサは、手のひらの内部に存在する静脈の血管パターンを映すのに適切な波長を持つ赤外光、例えば近赤外光を照射する照明と、赤外光を捉えることができるカメラとを含むセンサユニットとして実装することができる。このような実装の下、手のひらが所定の撮影位置に載置されると、照明によって赤外光が手のひらに照射される。この赤外光の照射に連動して起動されたカメラによって手のひらの内部から反射して戻ってきた赤外光が撮影される。このような撮影によって、静脈中の赤血球によって赤外光が吸収される結果、手のひらの静脈の血管パターンが撮像された静脈画像が生体画像として得られる。
【００１９】
なお、ここでは、一例として、静脈画像が生体画像として撮影される場合を例示したが、認証装置１０に適用可能な生体認証の種類はこれに限定されない。例えば、指紋認証が実施される場合には指紋画像、掌紋認証が実施される場合には掌紋画像、あるいは虹彩認証が実施される場合には虹彩画像を生体画像として撮影できる。
【００２０】
このように生体画像が取得された後、デバイス３０もしくはデバイス３０に内蔵または付属の生体センサは、生体画像から生体認証時の照合に用いる生体情報を生成する。この生体情報は、個人識別情報の一例である。ここでも、認証システム１に採用される生体認証の種類に相応しい特徴量を生体画像から生成することができる。例えば、生体認証として静脈認証が実施される場合、生体センサによって取得された静脈画像から血管部分を取り出した上で細線化し、血管における分岐点の座標、分岐点間の長さ、分岐点の分岐角度などの特徴量が生体情報として抽出される。その上で、デバイス３０は、上記の生体情報を所定の暗号方式、例えば公開鍵暗号などのアルゴリズムにしたがって暗号化した上で暗号化された生体情報を認証装置１０へ伝送することにより、認証リクエストを認証装置１０に行う。
【００２１】
なお、ここでは、生体センサにより生体画像が取得される例を説明したが、生体センサがセンシング可能な情報は画像に限定されない。例えば、声紋認証が実施される場合、マイクロフォン等を生体センサとして実装することにより、音声データから音響または言語に関する特徴を生体情報として生成することができる。
【００２２】
［課題の一側面］
上記の背景技術の欄等でも説明した通り、１：Ｎ認証には、１：１認証に比べて、利用者の生体情報と共にＩＤ等の入力を受け付ける手間がないので、利便性の一面で有利である。その一方で、１：Ｎ認証では、生体情報の登録数Ｎが多いほど認証の処理量が増大するので、認証処理を効率良く行うことが困難であるという一面がある。
【００２３】
［課題解決のアプローチの一側面］
そこで、本実施例に係る認証装置１０は、デバイス３０から認証リクエストを受け付けた生体情報と照合する生体情報を全ての利用者Ｎ人の生体情報よりも絞り込む仕組みに創作の困難性がある。すなわち、本実施例に係る認証装置１０は、デバイス３０ごとに過去にデバイス３０から認証リクエストを受け付けた生体情報のうち認証に成功した利用者の識別情報が認証候補としてリスト化された認証候補リストを絞り込みに用いる。
【００２４】
このような認証候補リストが生成された状況の下、本実施例に係る認証装置１０は、デバイス３０から認証リクエストを受け付けた場合、全ての利用者Ｎ人の識別情報および生体情報が管理された利用者マスタのうち、認証リクエストの発行元のデバイス３０に対応する認証候補リストにエントリがある利用者ｍ人の識別情報に対応するｍ個の生体情報を特定する。
【００２５】
その上で、本実施例に係る認証装置１０は、デバイス３０から認証リクエストを受け付けた生体情報と、ｍ個の生体情報との間で照合を行うことにより、１：ｍの生体認証を実行する。このｍ個の生体情報の中に認証リクエストを受け付けた生体情報と一致する生体情報が存在する場合、すなわち認証に成功した場合、本実施例に係る認証装置１０は、認証結果として認証ＯＫを認証リクエストの発行元のデバイス３０へ伝送する。
【００２６】
図２は、課題解決のアプローチの一側面を示す図である。図２には、利用者の識別情報の一例として、ユーザＩＤが示されると共に、利用者の生体情報の一例として、指紋画像が模式化されたアイコンが示されている。これらはあくまで説明の便宜上模式化されているに過ぎず、ユーザＩＤに用いる文字の種類やＩＤの桁数は任意のものであってよく、また、実際の生体情報が生体画像以外の情報であることを妨げない。
【００２７】
図２に示すように、認証装置１０には、全ての利用者Ｎ人のユーザＩＤおよび生体情報が管理された利用者マスタ１３Ｍの他にも、デバイス３０ごとに過去にデバイス３０から認証リクエストを受け付けた生体情報のうち認証に成功した利用者のユーザＩＤがリスト化された認証候補リスト１４Ａ〜１４Ｋが保存される。以下、認証候補リスト１４Ａ〜１４Ｋのことを総称して「認証候補リスト１４」と記載する場合がある。
【００２８】
これら利用者マスタ１３Ｍおよび認証候補リスト１４の管理の下、認証装置１０は、デバイス３０Ｂから認証リクエストを受け付ける（ステップＳ１）。この認証リクエストには、一例として、認証リクエストの発行元のデバイス３０の識別情報、例えばデバイスＩＤ「３０Ｂ」と共に、デバイス３０Ｂの生体センサにより取得された生体画像から生成された生体情報とが含まれる。
【００２９】
このように認証リクエストを受け付けると、認証装置１０は、認証候補リスト１４Ａ〜１４Ｋのうち、認証リクエストの発行元であるデバイス３０ＢのデバイスＩＤ「３０Ｂ」に対応する認証候補リスト１４Ｂを認証候補の絞り込みに用いる。すなわち、認証装置１０は、利用者マスタ１３Ｍに含まれるＮ個の生体情報のうち、認証候補リスト１４Ｂにエントリがある利用者ｍ人のユーザＩＤに対応するｍ個の生体情報、すなわち図中で反転表示が行われたユーザＩＤに紐付けられた生体情報を特定する（ステップＳ２）。
【００３０】
その上で、認証装置１０は、デバイス３０Ｂから認証リクエストを受け付けた生体情報と、ｍ個の生体情報との間で照合を行うことにより、１：ｍの生体認証を実行する（ステップＳ３）。このとき、認証候補リスト１４のエントリの上限をＭ個、例えば１００個に制限しておくことにより、絞り込み時に認証が実行される回数を最大でＭ回に制限することもできる。
【００３１】
ここで、ｍ個の生体情報の中に認証リクエストを受け付けた生体情報と一致する生体情報が存在する場合、認証装置１０は、認証結果として認証ＯＫを認証リクエストの発行元のデバイス３０Ｂへ伝送する（ステップＳ４）。
【００３２】
なお、ｍ個の生体情報の中に認証リクエストを受け付けた生体情報と一致する生体情報が存在しない場合、デバイス３０Ｂから認証リクエストを受け付けた生体情報と、利用者マスタ１３Ｍに登録されたＮ個の生体情報との間で照合を行うことにより、１：Ｎの生体認証がリトライされる。この１：Ｎ認証のリトライで認証に成功した場合、認証に成功した利用者のユーザＩＤを認証リクエストの発行元であるデバイス３０の認証候補リスト１４のエントリに追加することができる。なお、１：Ｎの生体認証がリトライされる場合、認証候補リスト１４Ｂにエントリがある利用者ｍ人のユーザＩＤに対応するｍ個の生体情報を除外して実行することができるのは言うまでもない。
【００３３】
図２を用いて説明した通り、本実施例に係る認証装置１０は、認証候補リスト１４を生体認証の対象とする生体情報の絞り込みに用いる。すなわち、利用者がデバイス３０で１：Ｎの生体認証に１度成功することにより当該利用者のユーザＩＤのエントリが認証候補リスト１４に生成されれば、二度目以降の認証リクエストでは、デバイス３０から認証リクエストを受け付けた生体情報と照合する生体情報の数を全ての利用者に対応するＮ個から認証候補リスト１４にエントリがあるｍ個まで絞り込むことができる。これによって、たとえ利用者マスタ１３Ｍに登録される生体情報の登録数Ｎが増加したとしても、過去にデバイス３０を利用した履歴がある利用者の数まで生体認証時に生体情報を照合する回数を低減できるので、認証の処理量が増大するのを抑制することができる。
【００３４】
したがって、本実施例に係る認証装置１０によれば、認証処理を効率良く行うことが可能になる。例えば、生体認証時に照合される生体情報の数が低減される結果、認証処理の所要時間を短縮したり、認証装置１０の処理負荷を軽減したりといったことが可能である。
【００３５】
また、本実施例に係る認証装置１０は、１台のデバイス３０が複数の利用者によって共用されるユースケースで有用である。例えば、スマートフォンやウェアラブル端末、シンクライアント端末、ゼロクライアント端末などのデバイス３０の多様化が進んでいる。このようなデバイス３０の多様化に伴って、１つのデバイス３０が１人の利用者によって専用の端末として利用されるとは限らず、数人から数十人によって共用のデバイス３０として利用される場面も増加している。現状、組織に所属する個人が専用するデバイス３０に対する認証サービスの普及は進んでいるが、共用のデバイス３０に対する認証サービスの普及は必ずしも個人のデバイス３０ほど進んでいるとは言えない。すなわち、共用のデバイス３０では、共用のデバイス３０の個々にアクセスを許可する利用者の生体情報を登録しておき、個々の共用のデバイス３０が登録済みの生体情報と認証リクエストを受け付けた生体情報とを照合する生体認証をスタンドアローンで行う運用の方が一般的である。このような運用が行われる場合、利用者が利用する全ての共用のデバイス３０に生体情報を事前に登録する手間が生じるので、利便性が損なわれる。この現状に対し、本実施例に係る認証装置１０では、利用者が共用のデバイス３０で１：Ｎの生体認証に１度成功することにより認証候補リスト１４に当該利用者のユーザＩＤのエントリが生成されるので、利用者が利用する全ての共用のデバイス３０に生体情報を事前に登録せずともよく、利便性を高めることが可能である。
【００３６】
さらに、本実施例に係る認証装置１０では、利用者マスタ１３Ｍに加えて各デバイス３０の認証候補リスト１４がアドオンされるが、この認証候補リスト１４にはユーザＩＤを保持するだけでよく、生体情報は保持せずともよい。このため、１：ｍの生体認証を実現するために用いる記憶容量を最小限にとどめることができる。
【００３７】
［認証装置１０の構成］
図３は、実施例１に係る認証装置１０の機能的構成の一例を示すブロック図である。図３に示すように、通信Ｉ／Ｆ（InterFace）部１１と、記憶部１３と、制御部１５とを有する。図３には、データの授受の関係を表す実線が示されているが、説明の便宜上、最小限の部分について示されているに過ぎない。すなわち、各処理部に関するデータの入出力は、図示の例に限定されず、図示以外のデータの入出力、例えば処理部及び処理部の間、処理部及びデータの間、並びに、処理部及び外部装置の間のデータの入出力が行われることとしてもかまわない。
【００３８】
通信Ｉ／Ｆ部１１は、他の装置、例えばデバイス３０などとの間で通信制御を行うインタフェースに対応する機能部である。
【００３９】
一実施形態として、通信Ｉ／Ｆ部１１には、ＬＡＮカードなどのネットワークインタフェースカードなどが対応する。例えば、通信Ｉ／Ｆ部１１は、デバイス３０から認証リクエストを受け付けたり、認証リクエストに対する認証結果、例えば認証ＯＫまたは認証ＮＧをデバイス３０へ出力したりする。
【００４０】
記憶部１３は、制御部１５で実行されるＯＳ（Operating  System）を始め、上記の認証プログラムを始めとするアプリケーションプログラムなどの各種プログラムに用いられるデータを記憶する機能部である。
【００４１】
一実施形態として、記憶部１３は、認証装置１０における補助記憶装置として実装することができる。例えば、記憶部１３には、ＨＤＤ（Hard  Disk  Drive）、光ディスクやＳＳＤ（Solid  State  Drive）などを採用できる。なお、記憶部１３は、必ずしも補助記憶装置として実装されずともよく、認証装置１０における主記憶装置として実装することもできる。この場合、記憶部１３には、各種の半導体メモリ素子、例えばＲＡＭ（Random  Access  Memory)やフラッシュメモリを採用できる。
【００４２】
記憶部１３は、制御部１５で実行されるプログラムに用いられるデータの一例として、利用者マスタ１３Ｍと、認証候補リスト１４Ａ〜１４Ｋとを記憶する。これらのデータ以外にも、記憶部１３には、他の電子データ、例えば利用者のアクセス権などが記憶されることとしてもかまわない。
【００４３】
利用者マスタ１３Ｍは、利用者のマスタデータである。
【００４４】
一実施形態として、利用者マスタ１３Ｍには、ユーザＩＤおよび生体情報が対応付けられたデータを採用できる。図４は、利用者マスタ１３Ｍのデータ構造の一例を示す図である。図４に示すように、利用者マスタ１３Ｍには、全ての利用者Ｎ人分のエントリ、すなわち利用者＃１情報〜利用者＃Ｎ情報が含まれる。さらに、図４には、利用者＃１情報〜利用者＃Ｎ情報のうち利用者＃１情報に含まれるデータの詳細がピックアップして示されている。すなわち、図４に示すように、利用者＃１情報には、利用者を識別するユーザＩＤ、利用者の属性情報、例えば氏名や所属など、利用者マスタ１３Ｍへの登録日、利用者＃１情報の有効期限、利用者の生体情報などが含まれる。
【００４５】
認証候補リスト１４Ａ〜１４Ｋは、生体認証時に認証候補として生体情報の絞り込みに用いるユーザＩＤがリスト化されたデータである。これら認証候補リスト１４Ａ〜１４Ｋは、デバイス３０Ａ〜３０Ｋごとに生成される。
【００４６】
図５は、認証候補リスト１４Ａのデータ構造の一例を示す図である。図５には、認証候補リスト１４Ａ〜１４Ｋのうち認証候補リスト１４Ａが抜粋して示されているが、各認証候補リスト１４が持つ項目の値は異なれども項目そのものに違いはない。図５に示すように、認証候補リスト１４Ａには、デバイス３０Ａから認証リクエストを受け付けた生体情報のうち認証に成功した生体情報に対応する利用者ｍ人分のエントリ、すなわち使用者＃１情報〜使用者＃ｍ情報が含まれる。さらに、図５には、使用者＃１情報〜使用者＃ｍ情報のうち使用者＃１情報に含まれるデータの詳細がピックアップして示されている。すなわち、図５に示すように、使用者＃１情報には、ユーザＩＤや認証日時などが含まれる。なお、認証日時には、最後に認証に成功した日時が格納されることとしてもよいし、最初に認証に成功した日時が格納されることとしてもかまわない。
【００４７】
制御部１５は、認証装置１０の全体制御を行う処理部である。
【００４８】
一実施形態として、制御部１５は、ＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）などのハードウェアプロセッサにより実装することができる。ここでは、プロセッサの一例として、ＣＰＵやＭＰＵを例示したが、汎用型および特化型を問わず、任意のプロセッサ、例えばＧＰＵ（Graphics  Processing  Unit）やＤＳＰ（Digital  Signal  Processor）の他、ＧＰＧＰＵ（General-Purpose  computing  on  Graphics  Processing  Units）により実装することができる。この他、制御部１５は、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）などのハードワイヤードロジックによって実現されることとしてもかまわない。
【００４９】
制御部１５は、図示しない主記憶装置として実装されるＲＡＭのワークエリア上に、上記の認証プログラムを展開することにより、下記の処理部を仮想的に実現する。
【００５０】
図３に示すように、制御部１５は、受付部１５ａと、特定部１５ｂと、認証部１５ｃと、出力部１５ｄと、登録部１５ｅとを有する。
【００５１】
受付部１５ａは、デバイス３０から各種のリクエストを受け付ける処理部である。一側面として、受付部１５ａは、デバイス３０からデバイスＩＤおよび生体情報を含む認証リクエストを受け付ける。
【００５２】
特定部１５ｂは、生体認証時に認証リクエストを受け付けた生体情報と照合する生体情報を特定する処理部である。
【００５３】
一実施形態として、特定部１５ｂは、受付部１５ａにより認証リクエストが受け付けられた場合、当該認証リクエストに含まれるデバイスＩＤに対応する認証候補リスト１４を参照する。このとき、認証候補リスト１４にエントリが存在しない場合、現時点で認証リクエストの発行元のデバイス３０が未使用であることが判明する。この場合、特定部１５ｂは、利用者マスタ１３Ｍから全ての利用者Ｎ人分の生体情報を特定する。一方、認証候補リスト１４にエントリが存在する場合、１：Ｎの生体認証の実行に先立って、認証候補リスト１４にエントリがあるｍ人の利用者の生体情報を用いて１：ｍの生体認証を実行できる環境にあることが判明する。この場合、特定部１５ｂは、利用者マスタ１３Ｍに含まれるＮ人の生体情報のうち、認証候補リスト１４にあるｍ個のエントリのユーザＩＤに対応する生体情報を特定する。
【００５４】
認証部１５ｃは、生体認証を実行する処理部である。
【００５５】
一実施形態として、認証部１５ｃは、受付部１５ａが認証リクエストを受け付けた生体情報と、特定部１５ｂにより特定された生体情報との間で特徴の相関または形状の相関が指標化された類似度を算出する。その上で、認証部１５ｃは、特定部１５ｂにより特定された生体情報の中に、受付部１５ａが認証リクエストを受け付けた生体情報との類似度が所定の閾値以上である生体情報が存在する場合、認証成功、すなわち認証ＯＫと判定する。一方、認証部１５ｃは、特定部１５ｂにより特定された生体情報の中に、受付部１５ａが認証リクエストを受け付けた生体情報との類似度が所定の閾値以上である生体情報が存在しない場合、認証失敗、すなわち認証ＮＧと判定する。
【００５６】
出力部１５ｄは、デバイス３０に対するデータの出力を制御する処理部である。一側面として、出力部１５ｄは、認証部１５ｃによる認証が実行された場合、認証リクエストの発行元のデバイス３０に当該認証リクエストに対する認証結果を出力する。
【００５７】
登録部１５ｅは、認証候補リスト１４にユーザＩＤを登録する処理部である。
【００５８】
一実施形態として、登録部１５ｅは、認証部１５ｃにより１：Ｎの生体認証に成功した場合、１：Ｎの生体認証に成功した生体情報に対応付けられたユーザＩＤを利用者マスタ１３Ｍから検索する。その上で、登録部１５ｅは、利用者マスタ１３Ｍから検索されたユーザＩＤのエントリを認証リクエストの発行元のデバイス３０に対応する認証候補リスト１４に追加する。このとき、登録部１５ｅは、利用者マスタ１３Ｍから検索されたユーザＩＤのエントリが認証候補リスト１４に存在する場合、認証候補リスト１４への重複登録を避ける側面から、当該エントリを認証候補リスト１４に追加せずともかまわない。この場合、登録部１５ｅは、利用者マスタ１３Ｍから検索されたユーザＩＤのエントリの認証日時を最新の日時に更新することができる。
【００５９】
［処理の流れ］
図６は、実施例１に係る認証処理の手順を示すフローチャートである。この処理は、一例として、デバイス３０から認証リクエストを受け付けた場合に開始される。図６に示すように、受付部１５ａが認証リクエストを受け付けた場合（ステップＳ１０１）、特定部１５ｂは、ステップＳ１０１で受け付けた認証リクエストに含まれるデバイスＩＤに対応する認証候補リスト１４を参照する（ステップＳ１０２）。
【００６０】
このとき、認証候補リスト１４にエントリが存在する場合（ステップＳ１０３Ｙｅｓ）、特定部１５ｂは、利用者マスタ１３Ｍに含まれるＮ人の生体情報のうち、ステップＳ１０２で参照された認証候補リスト１４に存在するｍ個のエントリのユーザＩＤに対応する生体情報を特定する（ステップＳ１０４）。そして、認証部１５ｃは、ステップＳ１０１で認証リクエストを受け付けた生体情報と、ステップＳ１０４で特定されたｍ個の生体情報との間で１：ｍの生体認証を実行する（ステップＳ１０５）。
【００６１】
ここで、１：ｍの生体認証に成功した場合（ステップＳ１０６Ｙｅｓ）、出力部１５ｄは、認証リクエストの発行元のデバイス３０に認証結果として認証ＯＫを出力し（ステップＳ１１１）、処理を終了する。
【００６２】
一方、１：ｍの生体認証に成功しなかった場合（ステップＳ１０６Ｎｏ）、デバイス３０を使用したことがない人物による認証リクエストであると判明する。また、認証候補リスト１４にエントリが存在しない場合（ステップＳ１０３Ｎｏ）、現時点で認証リクエストの発行元のデバイス３０が未使用であることが判明する。
【００６３】
これらのケースに該当する場合（ステップＳ１０３ＮｏまたはステップＳ１０６Ｎｏ）、特定部１５ｂは、利用者マスタ１３Ｍから全ての利用者Ｎ人分の生体情報を特定する（ステップＳ１０７）。その上で、認証部１５ｃは、ステップＳ１０１で認証リクエストを受け付けた生体情報と、ステップＳ１０７で特定された全ての利用者Ｎ人分の生体情報との間で１：Ｎの生体認証を実行する（ステップＳ１０８）。
【００６４】
ここで、１：Ｎの生体認証に成功した場合（ステップＳ１０９Ｙｅｓ）、登録部１５ｅは、１：Ｎの生体認証に成功した生体情報に対応付けられたユーザＩＤを利用者マスタ１３Ｍから検索してそのユーザＩＤのエントリを認証リクエストの発行元のデバイス３０に対応する認証候補リスト１４に追加する（ステップＳ１１０）。そして、出力部１５ｄは、認証リクエストの発行元のデバイス３０に認証結果として認証ＯＫを出力し（ステップＳ１１１）、処理を終了する。
【００６５】
一方、１：Ｎの生体認証に成功しなかった場合（ステップＳ１０９Ｎｏ）、ステップＳ１０１で受け付けた認証リクエストを行う人物が利用者マスタ１３Ｍに生体情報の登録がない人物であると判明する。この場合、出力部１５ｄは、認証リクエストの発行元のデバイス３０に認証結果として認証ＮＧを出力し（ステップＳ１１２）、処理を終了する。
【００６６】
［効果の一側面］
上述してきたように、本実施例に係る認証装置１０は、認証リクエストを受け付けた生体情報と照合する生体情報の数をマスタ登録された全ての利用者Ｎ人から認証リクエストの発行元のデバイス３０で認証成功の実績があるｍ人へ絞り込んで１：ｍの生体認証を実行する。これによって、たとえ利用者マスタ１３Ｍに登録される生体情報の登録数Ｎが増加したとしても、認証の処理量が増大するのを抑制することができる。したがって、本実施例に係る認証装置１０によれば、認証処理を効率良く行うことが可能である。
【実施例２】
【００６７】
さて、本実施例では、上記の実施例１に係る認証装置１０に比べて、生体認証の成功後にデバイス３０が利用者の持ち運び等により移動し得る状況下でもセキュリティが低下するのを抑制する機能がアドオンされた認証装置２０について説明する。
【００６８】
図７は、実施例２に係る認証装置２０の機能的構成の一例を示すブロック図である。図７には、図３に示す認証装置１０にはない機能部、さらには、図３に示す認証装置１０が有する機能部と同一のラベルの機能部ではあるが、一部の機能が異なる機能部に対応するブロックがハッチングで示されている。
【００６９】
図７に示すように、認証装置２０は、図３に示す認証装置１０に比べて、セッション情報＃１〜＃ｎおよびポリシー設定２３ｂが記憶部２３に記憶される点が異なる。さらに、認証装置２０は、制御部２５が生成部２５ａおよび判定部２５ｂをさらに有する点が異なる。なお、セッション情報＃１〜＃ｎおよびポリシー設定２３ｂの説明は、セッション情報２３ａ１〜２３ａｎが生成される場面およびポリシー設定２３ｂが参照される場面に合わせて後述する。
【００７０】
生成部２５ａは、セッション情報を生成する処理部である。
【００７１】
一実施形態として、生成部２５ａは、認証部１５ｃによる認証結果が認証成功である場合、例えば１：ｍの生体認証または１：Ｎの生体認証に成功した場合、セッションＩＤを生成する。図８は、セッションＩＤの生成方法の一例を示す図である。図８に示すように、セッションＩＤの生成には、デバイスＩＤ、ユーザＩＤ、アプリケーションＩＤおよび現在時刻が用いられる。ここで言う「デバイスＩＤ」は、生体認証に成功したデバイス３０のデバイスＩＤに対応する。また、「ユーザＩＤ」は、利用者マスタ１３ＭのユーザＩＤの中で生体認証に成功したユーザＩＤに対応する。また、「アプリケーションＩＤ」は、認証リクエストの発行元であるデバイス３０で実行中であるアプリケーションのアプリケーションＩＤに対応する。さらに、「現在時刻」は、生体認証に成功した時刻に対応する。これらデバイスＩＤ、ユーザＩＤ、アプリケーションＩＤおよび現在時刻がハッシュ化されることにより生成されたハッシュ値が「セッションＩＤ」として用いられる。
【００７２】
ここで、セッションＩＤの生成に現在時刻を用いるのは、第三者によってセッションＩＤが偽造されるのを抑止する側面がある。すなわち、現在時刻以外のデバイスＩＤ、ユーザＩＤおよびアプリケーションＩＤは、採番等で定義された後に変更されづらい固定文字列であることが多い。このような固定文字列だけをセッションＩＤの生成に用いたのでは、デバイスＩＤ、ユーザＩＤおよびアプリケーションＩＤが漏えい、あるいは推測されてしまうと、セッションＩＤが偽造される可能性が高まる。このことから、時間経過によって変化する時刻の文字列をセッションＩＤの生成に用いることで、固定文字列の部分が漏えい、あるいは推測された場合でも、セッションＩＤの偽造を抑止する。
【００７３】
このようにしてセッションＩＤが生成された後、生成部２５ａは、当該セッションＩＤを含むセッション情報を記憶部２３に保存する。
【００７４】
図９は、セッション情報の一例を示す図である。図９には、あくまで一例として、ｎ個のセッションが認証装置１０およびｎ個のデバイス３０の間で成立中である例が示されている。この場合、記憶部２３には、図９に示すように、セッション情報＃１〜セッション情報＃ｎが格納される。さらに、図９には、セッション情報＃１〜セッション情報＃ｎのうちセッション情報＃１に含まれるデータの詳細がピックアップして示されている。すなわち、図９に示すように、セッション情報＃１には、上記のセッションＩＤの他にも、デバイスＩＤ、ユーザＩＤ、ＩＰアドレス、セッション生成時刻などが含まれる。ここで言う「デバイスＩＤ」は、生体認証に成功したデバイス３０のデバイスＩＤに対応する。また、「ユーザＩＤ」は、利用者マスタ１３ＭのユーザＩＤの中で生体認証に成功したユーザＩＤに対応する。また、「ＩＰアドレス」は、セッション成立時、すなわち生体認証の成功時にデバイス３０に割り当てられているＩＰアドレスに対応する。また、「セッション成立日時」は、生体認証の成功によってセッションが成立した日時に対応する。なお、図示は省略したが、セッション情報＃２〜セッション情報＃ｎにおいても、セッションＩＤ、デバイスＩＤ、ユーザＩＤ、ＩＰアドレス及びセッション生成時刻の項目の値は異なれども項目そのものはかわらない。
【００７５】
このように認証装置１０との間でセッションが成立したデバイス３０は、セッションが有効に継続される限り、デバイス３０へのログインを始め、アプリケーションやリソースへのアクセスなどの各サービスが利用者のアカウントに付与された権限の範囲で許可される。その一方で、セッションが無制限に継続されることとしたのでは、セキュリティの低下をまねく場合があるので、セッション継続には、セキュリティの側面から一定の制限を課すことができる。
【００７６】
すなわち、セッションの成立後には、所定の周期、例えば１０分間の経過やスタンバイモードからの復帰、アプリケーションの起動などを条件とし、デバイス３０は、セッション継続のリクエストを認証装置１０に伝送する。このとき、セッション継続のリクエストの発行時には、セッションＩＤを始め、デバイスＩＤやユーザＩＤ、アプリケーションＩＤ、ＩＰアドレスなどを含めて認証装置１０に送信することができる。このようにセッション継続のリクエスト時にデバイス３０から認証装置１０へ伝送される情報を用いて、セキュリティの面から設定された基準、いわゆるポリシーに適合するか否かが判定される。
【００７７】
判定部２５ｂは、セッション継続を承認するか否かを判定する処理部である。この判定部は、制御部の一例である。
【００７８】
一実施形態として、判定部２５ｂは、受付部１５ａがデバイス３０からセッション継続のリクエストを受け付けた場合、次のように動作する。すなわち、判定部２５ｂは、記憶部２３に記憶されたセッション情報＃１〜セッション情報＃ｎの中に、セッション継続のリクエストで受け付けたセッションＩＤと一致するセッションＩＤが存在するか否かを判定する。このとき、セッション情報＃１〜セッション情報＃ｎの中にセッション継続のリクエストで受け付けたセッションＩＤと一致するセッションＩＤが存在しない場合、デバイス３０が継続をリクエストするセッションが正規のセッションでないと判明する。この場合、判定部２５ｂは、デバイス３０が保持するセッションＩＤをデバイス３０に削除させることにより、セッションを破棄する。一方、セッション情報＃１〜セッション情報＃ｎの中にセッション継続のリクエストで受け付けたセッションＩＤと一致するセッションＩＤが存在する場合、判定部２５ｂは、上記のポリシーに適合するか否かを判定する側面から、記憶部２３に記憶されたポリシー設定２３ｂを取得する。
【００７９】
図１０は、ポリシー設定２３ｂの一例を示す図である。図１０に記載の「アプリ」は、アプリケーションの略称である。図１０に示すように、アプリα〜アプリγの３つのアプリケーションの利用に課す条件の一例として、時間および場所に関する条件が例示されている。ここでは、一例として、セキュリティのレベルがアプリα、アプリβ、アプリγの順に高くなることとして以下の説明を行う。例えば、アプリαには、社外での閲覧も想定されたメールシステムなどが対応し、アプリβには、社外秘の文書が管理された文書管理システムなどが対応し、また、アプリγには、生産部門以外の他部門への秘匿、いわゆる部外秘が想定された生産機器管理システムなどが対応する。これらの例は、アプリごとに異なるポリシーを設定することを明らかにする趣旨の例示であり、例示以外のアプリケーションにポリシーが設定されることを妨げない。
【００８０】
アプリα〜アプリγの利用に課す時間条件の一例として、図１０の１行目に示すように、セッションの有効期限が設定されている。すなわち、デバイス３０でアプリαが利用される場合、セッションが成立した時点から８時間にわたってセッションが有効であることを意味する。また、デバイス３０でアプリβが利用される場合、セッションが成立した時点から１時間にわたってセッションが有効であることを意味する。さらに、デバイス３０でアプリγが利用される場合、セッションが成立した時点から３０分間にわたってセッションが有効であることを意味する。このようにセッションの有効期限をアプリごとに個別に設定できる他、セキュリティのレベルが高くなるにつれて長期間の有効期限を自動的に設定することができる。
【００８１】
さらに、アプリα〜アプリγの利用に課す場所条件の一例として、図１０の２行目に示すように、アプリケーションの利用が許可されるエリア、以下「許可エリア」が設定されている。この許可エリアは、図示の通り、一例として、ネットワークセグメント、以下「ＮＷセグメント」により定義される。さらに、図１０の３行目には、許可エリアから許可エリア外への移動がある場合にセッションを継続するか、あるいは破棄するかの設定が定義されている。
【００８２】
ここで、図１１にエリアおよびＮＷセグメントの対応関係の一例を示す。図１１は、エリアおよびＮＷセグメントの対応関係の一例を示す図である。図１１には、図１０に示す許可エリアを定義するＮＷセグメントに対応する社内および生産フロアの２つのエリアが模式的に示されている。図１１に示すように、社内のエリアには、生産フロアのエリアが含まれることがわかる。さらに、社内のエリアでは、ＮＷセグメント「１７２．１６．１．＊／２４〜１７２．１６．３１．＊／２４」の範囲のＩＰアドレスが用いられると共に、生産フロアのエリアでは、「１７２．１６．３１．＊／２４」の範囲のＩＰアドレスが用いられることを意味する。
【００８３】
このような対応関係の下で許可エリアのＮＷセグメントを見れば、図１０に示すアプリαの許可エリアには、ＮＷセグメントに制限がない。つまり、デバイス３０のＩＰアドレスがグローバルＩＰアドレスまたはプライベートＩＰアドレスのいずれであってもアプリαの利用が許可されることを意味する。また、図１０に示すアプリβの許可エリアは、ＮＷセグメント「１７２．１６．０．０／１６」の範囲のＩＰアドレスであるので、生産フロアを含む社内のエリアでアプリβの利用が許可されることを意味する。さらに、図１０に示すアプリγの許可エリアは、ＮＷセグメント「１７２．１６．３１．０／２４」の範囲のＩＰアドレスであるので、生産フロアのエリアでアプリγの利用が許可されることを意味する。さらに、アプリβの利用中にデバイス３０が許可エリア外へ移動した場合、並びに、アプリγの利用中にデバイス３０が許可エリア外へ移動した場合、いずれもセッションが破棄されることを意味する。
【００８４】
このようにしてポリシー設定２３ｂが取得された後、判定部２５ｂは、セッション継続のリクエストで受け付けたデバイス３０のＩＰアドレスと、セッション継続のリクエストで受け付けたセッションＩＤと一致するセッション情報のエントリ内のＩＰアドレスとが一致するか否かを判定する。これは機能的に言い換えれば、判定部２５ｂは、セッション成立時およびセッション継続のリクエスト時の間でデバイス３０のＩＰアドレスが一致するか否かを判定することと等価である。このような判定により、セッション成立時およびセッション継続のリクエスト時の間でデバイス３０の移動があるか否かを判定できる。
【００８５】
これら両者のＩＰアドレスが一致しない場合、デバイス３０の移動があることが判明する。この場合、判定部２５ｂは、ポリシー設定２３ｂに定義された許可エリアのうちセッション継続のリクエストで受け付けたアプリケーションＩＤに対応する許可エリアのＮＷセグメントの範囲に、セッション継続のリクエストで受け付けたデバイス３０のＩＰアドレスが含まれるか否かをさらに判定する。このような判定を行うのは、デバイス３０が所属するＮＷセグメントが変わったからといって必ずしも許可エリアの外へ移動したとは限らないからである。つまり、デバイスの移動が許可エリア内での移動であるのか、あるいは許可エリア外への移動であるのかが確認される。
【００８６】
ここで、ＩＰアドレスが一致する場合、あるいはＩＰアドレスが一致せずともデバイス３０が許可エリア内である場合、アプリの利用がポリシーに適合する場所で行われていることが判明する。この場合、判定部２５ｂは、セッション継続のリクエストで受け付けたセッションＩＤと一致するセッション情報のエントリ内のセッション成立時刻に基づいて、ポリシー設定２３ｂに定義されたセッションの有効期限のうちセッション継続のリクエストで受け付けたアプリケーションＩＤに対応するセッションの有効期限内であるか否かをさらに判定する。
【００８７】
そして、セッションの有効期限内である場合、アプリの利用が場所および時間の両面でポリシーに適合することが判明する。この場合、判定部２５ｂは、セッション継続を承認し、生体認証を省略して認証結果として認証ＯＫをデバイス３０へ出力する。
【００８８】
一方、デバイス３０が許可エリア外である場合、あるいはセッションの有効期限内でない場合、アプリの利用が場所または時間のいずれかでポリシーに反することが判明する。この場合、判定部２５ｂは、セッション継続を拒否し、記憶部２３に記憶されたセッション情報を破棄する。このとき、デバイス３０が許可エリア外である場合、改めて生体認証が実行されてもポリシーに反する。このため、判定部２５ｂは、アプリの実行そのものが許可されていない旨のアラートをデバイス３０に出力する制御を出力部１５ｄに実行させることができる。また、セッションの有効期限内でない場合、改めてセッションを確立する余地がある。このため、判定部２５ｂは、デバイス３０の生体認証を再実行するために、認証リクエストの実行をデバイス３０に要求する。
【００８９】
［処理の流れ］
次に、本実施例に係る認証装置２０の処理の流れについて説明する。ここでは、認証装置２０により実行される（１）認証処理、（２）判定処理の順に説明する。
【００９０】
（１）認証処理
図１２は、実施例２に係る認証処理の手順を示すフローチャートである。図１２には、図６に示す認証処理と同一の処理が行われる手順に同一のステップ番号を付与する一方で、図６に示す認証処理に追加された手順に異なるステップ番号を付与すると共に当該手順の部分がハッチングで示されている。
【００９１】
図１２に示す認証処理は、図６に示す認証処理と同様、一例として、デバイス３０から認証リクエストを受け付けた場合に開始される。図１２に示す認証処理は、図６に示す認証処理に比べて、ステップＳ１０６Ｎｏの分岐後またはステップＳ１１０の実行後に、下記のステップＳ２０１の手順が追加されている点が異なる。
【００９２】
つまり、１：ｍの生体認証または１：Ｎの生体認証が成功である場合、下記のステップＳ２０１の手順が実行される。すなわち、生成部２５ａは、生体認証に成功したデバイス３０のデバイスＩＤ、利用者マスタ１３ＭのユーザＩＤの中で生体認証に成功したユーザＩＤ、認証リクエストの発行元であるデバイス３０で実行中であるアプリケーションのアプリケーションＩＤ、さらに、生体認証に成功した時刻に基づいて、セッションＩＤを生成する（ステップＳ２０１）。
【００９３】
このように生成されたセッションＩＤは、上記のデバイスＩＤ、上記のユーザＩＤ、上記の時刻に加えて、セッション成立時にデバイス３０に割り当てられているＩＰアドレスを含むセッション情報として記憶部２３に保存される。
【００９４】
（２）判定処理
図１３は、実施例２に係る判定処理の手順を示すフローチャートである。この処理は、一例として、受付部１５ａがデバイス３０からセッション継続のリクエストを受け付けた場合に実行される。
【００９５】
図１３に示すように、デバイス３０からセッション継続のリクエストを受け付けると（ステップＳ３０１）、判定部２５ｂは、記憶部２３に記憶されたセッション情報＃１〜セッション情報＃ｎの中に、ステップＳ３０１で受け付けたセッションＩＤと一致するセッションＩＤが存在するか否かを判定する（ステップＳ３０２）。
【００９６】
このとき、セッション情報＃１〜セッション情報＃ｎの中にステップＳ３０１で受け付けたセッションＩＤと一致するセッションＩＤが存在する場合（ステップＳ３０２Ｙｅｓ）、判定部２５ｂは、記憶部２３に記憶されたポリシー設定２３ｂを取得する（ステップＳ３０３）。
【００９７】
そして、判定部２５ｂは、ステップＳ３０１で受け付けたデバイス３０のＩＰアドレスと、ステップＳ３０１で受け付けたセッションＩＤと一致するセッション情報のエントリ内のＩＰアドレスとが一致するか否かを判定する（ステップＳ３０４）。このステップＳ３０４によって、セッション成立時およびセッション継続のリクエスト時の間でデバイス３０の移動があるか否かが判明する。
【００９８】
これら両者のＩＰアドレスが一致しない場合（ステップＳ３０４Ｎｏ）、デバイス３０の移動があることが判明する。この場合、判定部２５ｂは、ポリシー設定２３ｂに定義された許可エリアのうちステップＳ３０１で受け付けたアプリケーションＩＤに対応する許可エリアのＮＷセグメントの範囲に、ステップＳ３０１で受け付けたデバイス３０のＩＰアドレスが含まれるか否かをさらに判定する（ステップＳ３０５）。
【００９９】
ここで、ＩＰアドレスが一致する場合、あるいはＩＰアドレスが一致せずともデバイス３０が許可エリア内である場合（ステップＳ３０４ＹｅｓまたはステップＳ３０５Ｙｅｓ）、アプリの利用がポリシーに適合する場所で行われていることが判明する。この場合、判定部２５ｂは、ステップＳ３０１で受け付けたセッションＩＤと一致するセッション情報のエントリ内のセッション成立時刻に基づいて、ポリシー設定２３ｂに定義されたセッションの有効期限のうちステップＳ３０１で受け付けたアプリケーションＩＤに対応するセッションの有効期限内であるか否かをさらに判定する（ステップＳ３０６）。
【０１００】
そして、セッションの有効期限内である場合（ステップＳ３０６Ｙｅｓ）、アプリの利用が場所および時間の両面でポリシーに適合することが判明する。この場合、判定部２５ｂは、セッション継続を承認し（ステップＳ３０７）、生体認証を省略して認証結果として認証ＯＫをデバイス３０へ出力し（ステップＳ３０８）、処理を終了する。
【０１０１】
また、セッション情報＃１〜セッション情報＃ｎの中にステップＳ３０１で受け付けたセッションＩＤと一致するセッションＩＤが存在しない場合、あるいはセッションの有効期限内でない場合（ステップＳ３０２ＮｏまたはステップＳ３０６Ｎｏ）、セッション継続は拒否される。この場合、判定部２５ｂは、記憶部２３に記憶されたセッション情報を破棄する（ステップＳ３０９）。これと共に、デバイス３０の生体認証を再実行するために、出力部１５ｄは、認証リクエストの実行をデバイス３０に要求し（ステップＳ３１０）、処理を終了する。
【０１０２】
また、デバイス３０が許可エリア外である場合（ステップＳ３０５Ｎｏ）、アプリの利用がポリシーに適合する場所で行われていることが判明する。この場合、セッション継続は拒否される。この場合、判定部２５ｂは、記憶部２３に記憶されたセッション情報を破棄し（ステップＳ３１１）、処理を終了する。
【０１０３】
なお、図１３に示すフローチャートでは、ＩＰアドレスが一致しない場合でも、デバイス３０が許可エリア内であれば（ステップＳ３０４ＮｏかつステップＳ３０５Ｙｅｓ）、ポリシーに適合すると判定する場合を例示したが、ＩＰアドレスが一致しない場合、改めてセッションを確立させる観点から、現状のセッションを破棄し、認証リクエストの実行をデバイス３０へ要求することとしてもかまわない。
【０１０４】
［効果の一側面］
上述してきたように、本実施例に係る認証装置２０は、上記の実施例１と同様、認証リクエストを受け付けた生体情報と照合する生体情報の数をマスタ登録された全ての利用者Ｎ人から認証リクエストの発行元のデバイス３０で認証成功の実績があるｍ人へ絞り込んで１：ｍの生体認証を実行する。したがって、本実施例に係る認証装置２０においても、上記の実施例１と同様、認証処理を効率良く行うことが可能である。
【０１０５】
さらに、本実施例に係る認証装置２０は、生体認証の成功時にデバイス３０との間でセッションを確立してＩＰアドレスを保存しておき、セッション確立後にセッション継続のリクエストを受け付けた場合、セッション確立時およびセッション継続のリクエスト時の間でＩＰアドレスが一致するか否かによりセッション継続を承認するか否かを判定する。これによって、本実施例に係る認証装置２０は、デバイス３０の移動がない場合にセッションを継続する一方で、デバイス３０の移動がある場合にセッションを破棄することができる。したがって、本実施例に係る認証装置２０によれば、デバイス３０が利用者の持ち運び等により移動し得る状況下でもセキュリティが低下するのを抑制できる。
【０１０６】
加えて、本実施例に係る認証装置２０は、デバイス３０で実行されるアプリケーションごとに異なる許可エリアおよびセッションの有効期限が設定されたポリシーにしたがってセッション継続を承認するか否かを判定できる。これによって、本実施例に係る認証装置２０は、アプリケーションの利用が場所および時間の両面でポリシーに適合する場合に絞ってセッション継続を承認できる。したがって、本実施例に係る認証装置２０によれば、ポリシーに反してアプリケーションが利用されることによりセキュリティが低下するのを抑制できる。
【実施例３】
【０１０７】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【０１０８】
［認証候補リストの細分化］
上記の実施例１および上記の実施例２では、デバイス３０ごとに認証候補リストが保持される例を説明したが、同一のデバイス３０でも曜日や時間帯でさらに細分化して曜日別および／または時間帯別に認証候補リストを保持することもできる。
【０１０９】
［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されておらずともよい。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、受付部１５ａ、特定部１５ｂ、認証部１５ｃまたは出力部１５ｄを認証装置１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、受付部１５ａ、特定部１５ｂ、認証部１５ｃ、出力部１５ｄ、生成部２５ａまたは判定部２５ｂを認証装置２０の外部装置としてネットワーク経由で接続するようにしてもよい。また、受付部１５ａ、特定部１５ｂ、認証部１５ｃまたは出力部１５ｄを別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記の認証装置１０の機能を実現するようにしてもよい。また、受付部１５ａ、特定部１５ｂ、認証部１５ｃ、出力部１５ｄ、生成部２５ａまたは判定部２５ｂを別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記の認証装置２０の機能を実現するようにしてもよい。
【０１１０】
［認証プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１４を用いて、上記の実施例と同様の機能を有する認証プログラムを実行するコンピュータの一例について説明する。
【０１１１】
図１４は、実施例１〜実施例２に係る認証プログラムを実行するコンピュータのハードウェア構成例を示す図である。図１４に示すように、コンピュータ１００は、操作部１１０ａと、スピーカ１１０ｂと、カメラ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ１７０と、ＲＡＭ１８０とを有する。これら１１０〜１８０の各部はバス１４０を介して接続される。
【０１１２】
ＨＤＤ１７０には、図１４に示すように、上記の実施例１で示した受付部１５ａ、特定部１５ｂ、認証部１５ｃ及び出力部１５ｄと同様の機能を発揮する認証プログラム１７０ａが記憶される。また、ＨＤＤ１７０には、上記の実施例２で示した受付部１５ａ、特定部１５ｂ、認証部１５ｃ、出力部１５ｄ、生成部２５ａ及び判定部２５ｂと同様の機能を発揮する認証プログラム１７０ａが記憶されることとしてもかまわない。この認証プログラム１７０ａは、図３または図７に示す各構成要素と同様、統合又は分離してもかまわない。すなわち、ＨＤＤ１７０には、必ずしも上記の実施例１で示した全てのデータが格納されずともよく、処理に用いるデータがＨＤＤ１７０に格納されればよい。
【０１１３】
このような環境の下、ＣＰＵ１５０は、ＨＤＤ１７０から認証プログラム１７０ａを読み出した上でＲＡＭ１８０へ展開する。この結果、認証プログラム１７０ａは、図１４に示すように、認証プロセス１８０ａとして機能する。この認証プロセス１８０ａは、ＲＡＭ１８０が有する記憶領域のうち認証プロセス１８０ａに割り当てられた領域にＨＤＤ１７０から読み出した各種データを展開し、この展開した各種データを用いて各種の処理を実行する。例えば、認証プロセス１８０ａが実行する処理の一例として、図６に示す処理、あるいは図１２や図１３に示す処理などが含まれる。なお、ＣＰＵ１５０では、必ずしも上記の実施例１で示した全ての処理部が動作せずともよく、実行対象とする処理に対応する処理部が仮想的に実現されればよい。
【０１１４】
なお、上記の認証プログラム１７０ａは、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶されておらずともかまわない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に認証プログラム１７０ａを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から認証プログラム１７０ａを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに認証プログラム１７０ａを記憶させておき、コンピュータ１００がこれらから認証プログラム１７０ａを取得して実行するようにしてもよい。
【０１１５】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【０１１６】
（付記１）端末から受信した個人識別情報を利用した認証をサーバ上で行う認証プログラムであって、
前記端末から個人識別情報を受信した場合に、端末の識別番号それぞれに対応づけた個人識別情報を記憶した複数のデータベースから、前記個人識別情報を受信した端末の識別番号と一致する端末の識別番号に対応付けた個人識別情報を特定し、
特定した前記個人識別情報と端末から受信した個人識別情報との比較結果に基づいて認証を行う処理をコンピュータに実行させることを特徴とする認証プログラム。
【０１１７】
（付記２）前記個人識別情報は生体情報であることを特徴とする付記１に記載の認証プログラム。
【０１１８】
（付記３）前記認証が成功した後に前記端末のセッション情報を生成するとともに、
前記セッション情報に対応付けて前記セッション情報を生成した際の前記端末のＩＰアドレスを記憶し
前記端末に対し送信した前記セッション情報を前記端末から受信した際に、前記端末から受信したＩＰアドレスと、前記セッション情報を生成した際の前記端末のＩＰアドレスとが一致するか否かに応じて前記セッション情報の利用を制御する処理をコンピュータに実行させることを特徴とする付記１に記載の認証プログラム。
【０１１９】
（付記４）前記認証が成功した後に前記端末のセッション情報を生成するとともに、
前記セッション情報に対応付けて、前記認証の際に前記端末で利用されたアプリケーションの情報を取得し、
記憶部に記憶したアプリケーションそれぞれに対応付けた前記アプリケーションのセッション情報を利用可能な領域の情報及び前記アプリケーションを利用した前記端末の移動があった際における前記セッション情報の継続時間との情報に基づいて前記端末のセッション情報の利用を制御する処理をコンピュータに実行させることを特徴とする付記１に記載の認証プログラム。
【０１２０】
（付記５）端末から受信した個人識別情報を利用した認証をサーバ上で行う認証方法であって、
前記端末から個人識別情報を受信した場合に、端末の識別番号それぞれに対応づけた個人識別情報を記憶した複数のデータベースから、前記個人識別情報を受信した端末の識別番号と一致する端末の識別番号に対応付けた個人識別情報を特定し、
特定した前記個人識別情報と端末から受信した個人識別情報との比較結果に基づいて認証を行う処理を前記サーバが実行することを特徴とする認証方法。
【０１２１】
（付記６）前記個人識別情報は生体情報であることを特徴とする付記５に記載の認証方法。
【０１２２】
（付記７）前記認証が成功した後に前記端末のセッション情報を生成するとともに、
前記セッション情報に対応付けて前記セッション情報を生成した際の前記端末のＩＰアドレスを記憶し
前記端末に対し送信した前記セッション情報を前記端末から受信した際に、前記端末から受信したＩＰアドレスと、前記セッション情報を生成した際の前記端末のＩＰアドレスとが一致するか否かに応じて前記セッション情報の利用を制御する処理を前記サーバが実行することを特徴とする付記５に記載の認証方法。
【０１２３】
（付記８）前記認証が成功した後に前記端末のセッション情報を生成するとともに、
前記セッション情報に対応付けて、前記認証の際に前記端末で利用されたアプリケーションの情報を取得し、
記憶部に記憶したアプリケーションそれぞれに対応付けた前記アプリケーションのセッション情報を利用可能な領域の情報及び前記アプリケーションを利用した前記端末の移動があった際における前記セッション情報の継続時間との情報に基づいて前記端末のセッション情報の利用を制御する処理を前記コンピュータが実行することを特徴とする付記５に記載の認証方法。
【０１２４】
（付記９）端末から受信した個人識別情報を利用した認証を行う認証装置であって、
前記端末から個人識別情報を受信した場合に、端末の識別番号それぞれに対応づけた個人識別情報を記憶した複数のデータベースから、前記個人識別情報を受信した端末の識別番号と一致する端末の識別番号に対応付けた個人識別情報を特定する特定部と、
特定した前記個人識別情報と端末から受信した個人識別情報との比較結果に基づいて認証を行う認証部と、
を有することを特徴とする認証装置。
【０１２５】
（付記１０）前記個人識別情報は生体情報であることを特徴とする付記９に記載の認証装置。
【０１２６】
（付記１１）前記認証が成功した後に前記端末のセッション情報を生成するとともに、前記セッション情報に対応付けて前記セッション情報を生成した際の前記端末のＩＰアドレスを記憶する生成部と、
前記端末に対し送信した前記セッション情報を前記端末から受信した際に、前記端末から受信したＩＰアドレスと、前記セッション情報を生成した際の前記端末のＩＰアドレスとが一致するか否かに応じて前記セッション情報の利用を制御する制御部とを有することを特徴とする付記９に記載の認証装置。
【０１２７】
（付記１２）前記認証が成功した後に前記端末のセッション情報を生成するとともに、
前記セッション情報に対応付けて、前記認証の際に前記端末で利用されたアプリケーションの情報を取得し、
記憶部に記憶したアプリケーションそれぞれに対応付けた前記アプリケーションのセッション情報を利用可能な領域の情報及び前記アプリケーションを利用した前記端末の移動があった際における前記セッション情報の継続時間との情報に基づいて前記端末のセッション情報の利用を制御する制御部を有することを特徴とする付記９に記載の認証装置。
【符号の説明】
【０１２８】
１    認証システム
１０    認証装置
１１    通信Ｉ／Ｆ部
１３    記憶部
１３Ｍ  利用者マスタ
１４Ａ〜１４Ｋ    認証候補リスト
１５    制御部
１５ａ  受付部
１５ｂ  特定部
１５ｃ  認証部
１５ｄ  出力部
３０    デバイス
【図１】
2020013288.tif 000003
【図２】
2020013288.tif 000004
【図３】
2020013288.tif 000005
【図４】
2020013288.tif 000006
【図５】
2020013288.tif 000007
【図６】
2020013288.tif 000008
【図７】
2020013288.tif 000009
【図８】
2020013288.tif 000010
【図９】
2020013288.tif 000011
【図１０】
2020013288.tif 000012
【図１１】
2020013288.tif 000013
【図１２】
2020013288.tif 000014
【図１３】
2020013288.tif 000015
【図１４】
2020013288.tif 000016