特開 2023-70406 サーバ、ユーザ端末、システム、及びアクセス制御方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023070406

(43)【公開日】2023-05-19

(54)【発明の名称】サーバ、ユーザ端末、システム、及びアクセス制御方法

(51)【国際特許分類】

   G06F 21/62 20130101AFI20230512BHJP

【ＦＩ】

G06F21/62 318

【審査請求】有

【請求項の数】12

【出願形態】ＯＬ

(21)【出願番号】P 2021182555

(22)【出願日】2021-11-09

(71)【出願人】

【識別番号】501440684

【氏名又は名称】ソフトバンク株式会社

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100123582

【弁理士】

【氏名又は名称】三橋 真二

(74)【代理人】

【識別番号】100114018

【弁理士】

【氏名又は名称】南山 知広

(74)【代理人】

【識別番号】100180806

【弁理士】

【氏名又は名称】三浦 剛

(74)【代理人】

【識別番号】100151459

【弁理士】

【氏名又は名称】中村 健一

(72)【発明者】

【氏名】北澤 勝也

(72)【発明者】

【氏名】鈴木 雄児

(72)【発明者】

【氏名】黒澤 裕治

(72)【発明者】

【氏名】遠藤 真明

(72)【発明者】

【氏名】増田 奈央

(72)【発明者】

【氏名】森 龍也

(72)【発明者】

【氏名】榎 剛志

(72)【発明者】

【氏名】吉成 恵一

(72)【発明者】

【氏名】小林 真之介

(72)【発明者】

【氏名】町野 洋輔

(57)【要約】

【課題】従来技術によっては、ユーザがサーバにアクセスする際の場所や、ユーザの職務等の様々なユーザの状態に応じて、所定のリソースへのアクセス可否を動的に制御することが難しいという問題があった。
【解決手段】本開示の一実施形態に係るサーバは、ユーザ端末から所定のリソースへのアクセスを要求しているユーザのアカウント情報を取得するアカウント情報取得部と、ユーザの状態に関するユーザ状態情報を取得するユーザ状態情報取得部と、アカウント情報及びユーザ状態情報と、ユーザの所定のリソースへのアクセス権限との関係を規定するポリシーを記憶したポリシー記憶部と、ポリシーを参照して、アカウント情報及びユーザ状態情報に基づいて、ユーザの所定のリソースへのアクセスの可否を分析する分析部と、分析部による分析結果に基づいて、ユーザによる所定のリソースへのアクセスを制御するアクセス制御部と、を有することを特徴とする。
【選択図】図１

【特許請求の範囲】

【請求項1】

所定のリソースへのアクセスを要求しているユーザのアカウント情報を、ユーザ端末から取得するアカウント情報取得部と、
前記ユーザの状態に関するユーザ状態情報を取得するユーザ状態情報取得部と、
前記アカウント情報及び前記ユーザ状態情報と、前記ユーザの所定のリソースへのアクセス権限との関係を規定するポリシーを記憶したポリシー記憶部と、
前記ポリシーを参照して、前記アカウント情報及び前記ユーザ状態情報に基づいて、前記ユーザの前記所定のリソースへのアクセスの可否を分析する分析部と、
前記分析部による分析結果に基づいて、前記ユーザによる前記所定のリソースへのアクセスを制御するアクセス制御部と、
を有することを特徴とするサーバ。

【請求項2】

前記ユーザ状態情報取得部は、前記ユーザがアクセスを要求している時間に関するアクセス時間情報を取得するアクセス時間情報取得部を含む、請求項１に記載のサーバ。

【請求項3】

前記ユーザ状態情報取得部は、前記ユーザが存在する位置に関する位置情報を取得する位置情報取得部を含む、請求項１または２に記載のサーバ。

【請求項4】

前記ユーザ状態情報取得部は、前記ユーザの職務上または業務上の状態に関する人事情報を取得する人事情報取得部を含む、請求項１乃至３のいずれか一項に記載のサーバ。

【請求項5】

前記ユーザ状態情報取得部は、前記ユーザの行動履歴に関する履歴情報を取得する履歴情報取得部を含む、請求項１乃至４のいずれか一項に記載のサーバ。

【請求項6】

前記ユーザ状態情報取得部は、前記ユーザが使用する端末に関する端末情報を取得する端末情報取得部を含む、請求項１乃至５のいずれか一項に記載のサーバ。

【請求項7】

前記分析部は、
複数のユーザの行動履歴に関する履歴情報と、各履歴情報が前記ポリシーに適合するか否かを示すデータとを学習データとして学習された学習モデルであって、リソースへのアクセスを試みたユーザの行動履歴を入力として、前記行動履歴が前記ポリシーに適合するか否かを出力する学習モデルを有する、
請求項１乃至６のいずれか一項に記載のサーバ。

【請求項8】

前記分析部は、
複数のユーザ状態情報のそれぞれの重要性に応じて、複数のユーザ状態情報のそれぞれがアクセス許可条件を満たさなかった場合に積算する値の重み付けを行い、
前記複数のユーザ状態情報のそれぞれが前記アクセス許可条件を満たすか否かを判断し、
前記値の積算値が所定の閾値を超えるか否かに基づいて、アクセス可否を判断する、
請求項１乃至７のいずれか一項に記載のサーバ。

【請求項9】

前記アクセス制御部は、複数の追加認証方式のうちから、前記値に応じて適切なレベルの認証方式を選択して、アクセス許可の追加認証を行う、請求項８に記載のサーバ。

【請求項10】

アクセスを要求しているユーザのアカウント情報を入力する入力部と、
所定のリソースへのアクセスを要求する信号を送信し、かつ、前記アカウント情報、及び前記ユーザの状態に関するユーザ状態情報と、前記ユーザの前記所定のリソースへのアクセス権限との関係を規定するポリシーを参照して、前記アカウント情報及び前記ユーザ状態情報に基づいて、前記ユーザの前記所定のリソースへのアクセスの可否を分析した分析結果に基づいて、前記ユーザによる前記所定のリソースへのアクセスの可否に関する情報を受信する送受信部と、
を有することを特徴とするユーザ端末。

【請求項11】

ユーザ端末と、サーバと、を有するシステムであって、
前記ユーザ端末は、
アクセスを要求しているユーザのアカウント情報を入力する入力部と、
所定のリソースへのアクセスを要求する信号を送信し、かつ、前記アカウント情報、及び前記ユーザの状態に関するユーザ状態情報と、前記ユーザの前記所定のリソースへのアクセス権限との関係を規定するポリシーを参照して、前記アカウント情報及び前記ユーザ状態情報に基づいて、前記ユーザの前記所定のリソースへのアクセスの可否を分析した分析結果に基づいて、前記ユーザによる前記所定のリソースへのアクセスの可否に関する情報を受信する送受信部と、
を有し、
前記サーバは、
ユーザ端末から所定のリソースへのアクセスを要求している前記ユーザのアカウント情報を取得するアカウント情報取得部と、
前記ユーザの状態に関するユーザ状態情報を取得するユーザ状態情報取得部と、
前記アカウント情報及び前記ユーザ状態情報と、前記ユーザの所定のリソースへのアクセス権限との関係を規定するポリシーを記憶したポリシー記憶部と、
前記ポリシーを参照して、前記アカウント情報及び前記ユーザ状態情報に基づいて、前記ユーザの前記所定のリソースへのアクセスの可否を分析する分析部と、
前記分析部による分析結果に基づいて、前記ユーザによる前記所定のリソースへのアクセスを制御するアクセス制御部と、
を有することを特徴とするシステム。

【請求項12】

サーバが、
ユーザ端末から所定のリソースへのアクセスを要求しているユーザのアカウント情報を取得し、
前記ユーザの状態に関するユーザ状態情報を取得し、
前記アカウント情報及び前記ユーザ状態情報と、前記ユーザの所定のリソースへのアクセス権限との関係を規定するポリシーを記憶し、
前記ポリシーを参照して、前記アカウント情報及び前記ユーザ状態情報に基づいて、前記ユーザの前記所定のリソースへのアクセスの可否を分析し、
分析結果に基づいて、前記ユーザによる前記所定のリソースへのアクセスを制御する、
ことを特徴とするアクセス制御方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サーバ、ユーザ端末、システム、及びアクセス制御方法に関する。

【背景技術】

【0002】

ユーザが、オフィス等のサーバにアクセスし、機密情報を扱う業務が多く存在する。現状では、機密情報の漏洩を防止するために、端末、ネットワーク、アプリケーション等の機密情報専用のネットワーク環境を種々の業務毎に個別に構築している。従って、ユーザは個々の業務に応じてネットワーク環境、業務場所等の業務環境を使い分ける必要があり、業務効率や運用効率が悪いという問題がある。

【0003】

また、これまでに、ユーザのサーバ等へのアクセスを制御する方法が報告されている（例えば、特許文献１、２）。特許文献１には、事前に文書およびフォルダに対してデフォルトアクセス権設定条件を記憶部に記憶しておき、人事組織情報に基づくユーザ及びグループ変更時に、新規に作成されるユーザ及びグループや異動先のユーザ及びグループに対して、デフォルトアクセス権設定条件情報に基づき文書及びフォルダに対するアクセス権が設定される文書管理サーバと人事組織管理サーバとクライアントから構成されるシステムが開示されている。特許文献１には、人事組織異動が発生した場合において、管理ユーザが、フォルダに対して、デフォルトのアクセス権設定条件を設定するだけで、管理ユーザが手作業で運用ルールにあわせた個別のアクセス権を設定する必要が無く、管理ユーザの負担を軽減することができる点が開示されている。

【0004】

特許文献２には、ユーザがログイン操作を行った場合、管理用データベースに格納されている所属ユーザグループの情報をチェックし、利用時間設定を所定の優先順位に従ってチェックし、現在時間に該当する利用時間設定の中で最も優先度の高いものを基にログイン可・不可の判定を行うシステム利用時間管理装置が開示されている。特許文献２には、ユーザの不正アクセスを防止することができるだけでなく、システムの利用時間の設定を管理するための作業負荷を軽減し且つ当該設定の管理の利便性を向上させることができる点が開示されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２００７－３２３３５７号公報

【特許文献2】特開２０１３－１３１２５４号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

しかしながら、従来技術によっては、ユーザがサーバにアクセスする際の場所や、ユーザの職務内容等の様々なユーザの状態に応じて、所定のリソースへのアクセス可否を動的に制御することが難しいという問題があった。

【課題を解決するための手段】

【0007】

本開示の一実施形態に係るサーバは、ユーザ端末から所定のリソースへのアクセスを要求しているユーザのアカウント情報を取得するアカウント情報取得部と、ユーザの状態に関するユーザ状態情報を取得するユーザ状態情報取得部と、アカウント情報及びユーザ状態情報と、ユーザの所定のリソースへのアクセス権限との関係を規定するポリシーを記憶したポリシー記憶部と、ポリシーを参照して、アカウント情報及びユーザ状態情報に基づいて、ユーザの所定のリソースへのアクセスの可否を分析する分析部と、分析部による分析結果に基づいて、ユーザによる所定のリソースへのアクセスを制御するアクセス制御部と、を有することを特徴とする。

【0008】

本開示の一実施形態に係るサーバにおいて、ユーザ状態情報取得部は、ユーザがアクセスを要求している時間に関するアクセス時間情報を取得するアクセス時間情報取得部を含んでよい。

【0009】

本開示の一実施形態に係るサーバにおいて、ユーザ状態情報取得部は、ユーザが存在する位置に関する位置情報を取得する位置情報取得部を含んでよい。

【0010】

本開示の一実施形態に係るサーバにおいて、ユーザ状態情報取得部は、ユーザの職務上または業務上の状態に関する人事情報を取得する人事情報取得部を含んでよい。

【0011】

本開示の一実施形態に係るサーバにおいて、ユーザ状態情報取得部は、ユーザの行動履歴に関する履歴情報を取得する履歴情報取得部を含んでよい。

【0012】

本開示の一実施形態に係るサーバにおいて、ユーザ状態情報取得部は、ユーザが使用する端末に関する端末情報を取得する端末情報取得部を含んでよい。

【0013】

本開示の一実施形態に係るサーバにおいて、分析部は、複数のユーザの行動履歴に関する履歴情報と、各履歴情報がポリシーに適合するか否かを示すデータとを学習データとして学習された学習モデルであって、リソースへのアクセスを試みたユーザの行動履歴を入力として、行動履歴がポリシーに適合するか否かを出力する学習モデルを有してよい。

【0014】

本開示の一実施形態に係るサーバにおいて、分析部は、複数のユーザ状態情報のそれぞれの重要性に応じて、複数のユーザ状態情報のそれぞれがアクセス許可条件を満たさなかった場合に積算する値の重み付けを行い、複数のユーザ状態情報のそれぞれがアクセス許可条件を満たすか否かを判断し、上記の値の積算値が所定の閾値を超えるか否かに基づいて、アクセス可否を判断してよい。

【0015】

本開示の一実施形態に係るサーバにおいて、アクセス制御部は、複数の追加認証方式のうちから、上記の値に応じて適切なレベルの認証方式を選択して、アクセス許可の追加認証を行ってよい。

【0016】

本開示の一実施形態に係るユーザ端末は、アクセスを要求しているユーザのアカウント情報を入力する入力部と、所定のリソースへのアクセスを要求する信号を送信し、かつ、アカウント情報、及びユーザの状態に関するユーザ状態情報と、ユーザの所定のリソースへのアクセス権限との関係を規定するポリシーを参照して、アカウント情報及びユーザ状態情報に基づいて、ユーザの所定のリソースへのアクセスの可否を分析した分析結果に基づいて、ユーザによる所定のリソースへのアクセスの可否に関する情報を受信する送受信部と、を有することを特徴とする。

【0017】

本開示の一実施形態に係るシステムは、ユーザ端末と、サーバと、を有するシステムであって、ユーザ端末は、アクセスを要求しているユーザのアカウント情報を入力する入力部と、所定のリソースへのアクセスを要求する信号を送信し、かつ、アカウント情報、及びユーザの状態に関するユーザ状態情報と、ユーザの所定のリソースへのアクセス権限との関係を規定するポリシーを参照して、アカウント情報及びユーザ状態情報に基づいて、ユーザの所定のリソースへのアクセスの可否を分析した分析結果に基づいて、ユーザによる所定のリソースへのアクセスの可否に関する情報を受信する送受信部と、を有し、サーバは、ユーザ端末から所定のリソースへのアクセスを要求しているユーザのアカウント情報を取得するアカウント情報取得部と、ユーザの状態に関するユーザ状態情報を取得するユーザ状態情報取得部と、アカウント情報及びユーザ状態情報と、ユーザの所定のリソースへのアクセス権限との関係を規定するポリシーを記憶したポリシー記憶部と、ポリシーを参照して、アカウント情報及びユーザ状態情報に基づいて、ユーザの所定のリソースへのアクセスの可否を分析する分析部と、分析部による分析結果に基づいて、ユーザによる所定のリソースへのアクセスを制御するアクセス制御部と、を有することを特徴とする。

【0018】

本開示の一実施形態に係るアクセス制御方法は、サーバが、ユーザ端末から所定のリソースへのアクセスを要求しているユーザのアカウント情報を取得し、ユーザの状態に関するユーザ状態情報を取得し、アカウント情報及びユーザ状態情報と、ユーザの所定のリソースへのアクセス権限との関係を規定するポリシーを記憶し、ポリシーを参照して、アカウント情報及びユーザ状態情報に基づいて、ユーザの所定のリソースへのアクセスの可否を分析し、分析結果に基づいて、ユーザによる所定のリソースへのアクセスを制御する、ことを特徴とする。

【発明の効果】

【0019】

本発明のサーバ、ユーザ端末、システム、及びアクセス制御方法によれば、ユーザがサーバにアクセスする際の場所や、ユーザの職務内容等の様々なユーザの状態に応じて、所定のリソースへのアクセス可否を動的に制御することができる。

【図面の簡単な説明】

【0020】

【図1】本開示の一実施形態に係るシステムの構成概念図である。

【図2】本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第１の例である。

【図3】本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第２の例である。

【図4】本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第３の例である。

【図5】本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第４の例である。

【図6】本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第５の例である。

【図7】本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第６の例である。

【図8】本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートであって、複数のユーザ状態情報の重み付けによるアクセス制御を実行する場合のフローチャートの例である。

【図9】本開示の一実施形態に係るサーバにおいて、ＮＧ要素とＮＧ値重みの例を示す表である。

【図10】本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートであって、複数のユーザ状態情報の重み付けによるアクセス制御を実行する場合のフローチャートの例である。

【図11】本開示の一実施形態に係るサーバにおいて、ＮＧ値範囲と追加認証の例を示す表である。

【発明を実施するための形態】

【0021】

以下、図面を参照して、本発明に係るサーバ、ユーザ端末、システム、及びアクセス制御方法について説明する。ただし、本発明の技術的範囲はそれらの実施の形態には限定されず、特許請求の範囲に記載された発明とその均等物に及ぶ点に留意されたい。

【0022】

（本開示の実施形態に係るシステムの概要）
図１に、本開示の一実施形態に係るシステムの構成概念図を示す。ユーザはユーザ端末２００を用いてネットワーク３００を介してサーバ１００を経由してリソース４００にアクセスする。サーバ１００はユーザ端末２００からユーザの状態情報を取得し、予め規定されたポリシーに従って、ユーザによる所定のリソースへのアクセスを許可すべきか否かを動的に制御する。ユーザが所定のリソースにアクセス可能であるか否かを、ユーザの状態に基づいてサーバ１００が判断するため、ユーザは、種々のリソースへアクセスするためのネットワーク環境を個別に用意する必要がなくなり、業務効率や運用効率を向上させることができる。

【0023】

リソース４００は、例えば、機密情報を含むデータ、あるいは、それらを保存するサーバ、クラウドサービスであってよい。また、リソース４００は、例えば、機密情報を取り扱う業務システム、もしくは、それらのシステムを提供するサーバ、クラウドサービスであってよい。

【0024】

例えば、ポリシーに、ユーザが所定の場所に存在していることを条件として所定のリソースへのアクセスが許可されると規定されている場合を例にとって説明する。この場合、従来は、ユーザは、所定の場所に入場し、所定の場所に設置された端末を利用して、所定のリソースにアクセスする必要があった。これに対して、本開示の実施形態に係るシステムにおいては、サーバ１００が、ユーザが所定の場所に存在しているか否かに関する情報を取得することができる。サーバ１００は、予め規定されたポリシーを参照して、ユーザが所定の場所に存在しているか否かに関する情報に基づいて、ユーザによる所定のリソースへのアクセスを許可すべきか否かを判断することができる。サーバ１００は、アクセス可否の判断結果に基づいて、ユーザによる所定のリソースへのアクセスを制御する。

【0025】

上記の例においては、サーバは、ユーザが所定の場所に存在しているとの情報に基づいて、ユーザによる所定のリソース４００へのアクセスを許可するように制御する。従って、所定の場所に存在していれば、任意のユーザ端末を利用することができ、ユーザは利用する端末を選択する等、所定のリソースにアクセスするためのネットワーク環境を個別に整えることなく、所定のリソースへのアクセスを行うことができる。

【0026】

（サーバの構成）
サーバ１００は、アカウント情報取得部１と、ユーザ状態情報取得部２と、ポリシー記憶部３と、分析部４と、アクセス制御部５と、を有している。これらの各部は、サーバ１００が備えるプロセッサで実行されるプログラムにより実現される機能モジュールである。あるいは、これらの各部は、ファームウェアとしてサーバ１００に実装されてもよい。また、サーバ１００は、さらに、ユーザによる過去のアクセスログを記憶したアクセスログ記憶部６、及び送受信部７を備えてよい。なお、サーバ１００は、オフィスまたは、データセンター等に設置された情報処理装置、あるいは、クラウドサービス上に仮想的に定義された仮想サーバであってもよい。

【0027】

アカウント情報取得部１は、所定のリソース４００へのアクセスを要求しているユーザのアカウント情報をユーザ端末２００から取得する。アカウント情報には、所定のリソースへのアクセス権、及び、そのアクセス権の所持者を一意に識別するためのユーザ情報が含まれてよい。例えば、アカウント情報には、ユーザ識別情報（ＩＤ）、パスワード、メールアドレス等が含まれてよい。

【0028】

ユーザ状態情報取得部２は、ユーザの状態に関するユーザ状態情報を取得する。ユーザ状態情報には、例えば、ユーザがアクセス要求をしている時間（アクセス時刻）に関する情報、位置に関する情報（以下、位置情報）、ユーザの職務上または業務上の状態に関する情報（以下、「人事情報」ともいう。）、ユーザの行動履歴に関する情報等が含まれてよい。ユーザ状態情報取得部２は、アクセス時間情報取得部２１、位置情報取得部２２、人事情報取得部２３、履歴情報取得部２４、及び、端末情報取得部２５のうちの少なくとも１つを有してよい。

【0029】

アクセス時間情報取得部２１は、ユーザがアクセスを要求している時間に関するアクセス時間情報を取得する。アクセス時間情報取得部２１は、例えば、ユーザ端末２００からアクセスがあった時間をユーザ端末２００から取得してよい。あるいは、アクセス時間情報取得部２１は、ユーザ端末２００からアクセスを検知した時に、計時部１３を参照してアクセスがあった時間に関する情報を計時部１３から取得してもよい。

【0030】

位置情報取得部２２は、ユーザの位置情報を取得する。位置情報取得部２２は、例えば、ユーザが、入場状態検出部１２が設けられた所定のエリアに入場した際に、入場状態検出部１２からユーザが存在する位置に関する位置情報を取得してよい。即ち、位置情報は、所定の施設への入退場に関する情報を含んでよい。あるいは、位置情報取得部２２は、例えば、ユーザ端末２００に設けられたＧＰＳ等を利用した位置情報取得部（図示せず）からユーザ端末２００の位置に関する情報を取得してよい。もしくは、位置情報取得部２２は、例えば、無線ＬＡＮアクセスポイント、移動体基地局、ネットワークスイッチなどのユーザ端末２００が接続しているネットワークの情報を取得してよい。

【0031】

人事情報取得部２３は、ユーザの人事情報を取得する。人事情報には、例えば、属性情報（例えば、ユーザの所属する部署の情報、職位に関する情報、ユーザが休職中であるか否かに関する情報、秘密保持契約（ＮＤＡ）の締結状況に関する情報、セキュリティ管理者が指定したアクセス許可／禁止に関する情報等）、業務情報（ユーザの担当業務に関する情報）、経歴情報（例えば、ユーザが有するスキルに関する情報、過去の担当業務の情報、取得した資格に関する情報、研修の受講履歴に関する情報、ユーザの職場内での昇格・異動・降格に関する情報等）、ユーザの同意に基づいて開示された健康情報（例えば、法定健康診断・ワクチン接種・抗原検査等の受診状況または結果に関する情報等）、あるいは、勤怠情報（例えば、勤務時間、シフト、休暇情報、ユーザによる時間外労働、休暇、退職届、国内外への出張などの勤務に関する届出の提出の有無に関する情報、所定期間における累積労働時間情報等）、などが含まれてよい。

【0032】

履歴情報取得部２４は、ユーザの行動履歴に関する履歴情報を取得する。ユーザの行動履歴に関する履歴情報には、例えば、ユーザの行動に職務規定に違反する点があるか否かに関する情報、あるいは、アクセスログ記憶部６に記憶されたユーザの過去のログに問題点があるか否かに関する情報が含まれてよい。その他、ユーザの行動履歴に関する履歴情報には、例えば、ユーザが認証に失敗した回数に関する情報や、直近の顧客応対の履歴に関する情報等が含まれてよい。

【0033】

端末情報取得部２５は、ユーザが使用する端末に関する端末情報を取得する。ユーザが使用する端末に関する端末情報には、例えば、ユーザがアクセスを実行しているユーザ端末２００の識別情報（ＩＭＳＩ（International Mobile Subscription Identity）、ＩＭＥＩ（International Mobile Equipment Identifier）、ＭＡＣアドレスなど）、接続しているネットワークの情報（ＩＰアドレス、ＰＬＭＮ（Public Land Mobile Network）、全１０桁の電話番号の形式である０ＡＢＪ番号など）、端末の状況に関する情報（セキュリティパッチの適用状況、アクセス証明書の設定状況、セキュリティソフトウェアのインストール状況など）、クライアント証明書に関する情報が含まれてよい。また、ユーザが使用する端末に関する端末情報には、ユーザがアクセスを実行しているユーザ端末２００が許可された端末であるか否かに関する情報が含まれてよい。さらに、ユーザが使用する端末に関する端末情報には、ユーザがアクセスを試みているユーザ端末が、ユーザが通常使用している端末と同一であるか否かに関する情報、及び端末とユーザの組み合わせに関する情報が含まれてよい。

【0034】

ポリシー記憶部３は、アカウント情報及びユーザ状態情報と、ユーザの所定のリソースへのアクセス権限との関係を規定するポリシーを記憶している。ポリシー記憶部３には、ハードディスク、あるいは、ＲＯＭやＲＡＭ等の半導体メモリ素子等の記憶装置を用いてよい。ポリシー記憶部３に記憶されているポリシーには、ユーザの状態とアクセスを許可するか否かに関する情報との対応関係が規定されている。例えば、所定の業務を遂行するユーザが、所定の場所で、所定の時間帯において、所定のリソースにアクセス可能であるか否かが規定されてよい。あるいは、所定の職責のユーザが、所定の時間帯に、所定の場所に入場可能か否かを規定してよい。

【0035】

分析部４は、ポリシーを参照して、アカウント情報及びユーザ状態情報に基づいて、ユーザの所定のリソースへのアクセスの可否を分析する。例えば、分析部４は、ユーザの状態が、ポリシーに規定された、所定のリソースへのアクセスを許可するための条件を満たしているか否かを分析する。

【0036】

アクセス制御部５は、分析部４による分析結果に基づいて、ユーザによる所定のリソース４００へのアクセスを制御する。

【0037】

（ユーザ端末の構成）
ユーザ端末２００は、入力部２０１と、表示部２０２と、送受信部２０３と、を有している。入力部２０１には、キーボードやマウス等の入力装置を用いることができる。表示部２０２には、液晶表示装置や有機ＥＬ表示装置等の表示装置を用いることができる。送受信部２０３は、ネットワーク３００と接続され、サーバ１００との間でデータを送受信することができる。ユーザ端末２００には、上記のような物理端末だけでなく、仮想端末を用いてよい。仮想端末を用いることにより、サーバにアプリケーションやデータを集約させることができ、端末にデータを残さないようにすることができるため、情報漏洩を防止することができる。

【0038】

入力部２０１は、アクセスを要求しているユーザのアカウント情報を入力する。

【0039】

送受信部２０３は、所定のリソースへのアクセスを要求する信号を送信し、かつ、アカウント情報、及びユーザの状態に関するユーザ状態情報と、ユーザの所定のリソースへのアクセス権限との関係を規定するポリシーを参照して、アカウント情報及びユーザ状態情報に基づいて、ユーザの所定のリソースへのアクセスの可否を分析した分析結果に基づいて、ユーザによる所定のリソースへのアクセスの可否に関する情報を受信する。

【0040】

（リソースの構成）
所定のリソース４００の例として、例えば、ＳａａＳ（Software as a Service）４０１、社内システム４０２、ファイルサーバ４０３、インターネット接続４０４等が挙げられるが、これらの例には限られず、サーバ１００によって、ユーザからのアクセスを制御することが可能な種々のリソースを利用することができる。

【0041】

次に、ユーザ状態情報についての例を挙げながら、サーバの動作手順に説明する。

【0042】

（第１の例：アクセス時間に基づくアクセス制御）
図２に、本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第１の例を示す。まず、ステップＳ１０１において、ユーザがユーザ端末２００の入力部２０１を用いてユーザのアカウント情報を入力すると、サーバ１００のアカウント情報取得部１がネットワーク３００を介してユーザのアカウント情報を取得する。ユーザのアカウント情報には、ユーザの識別情報、パスワード、所属する部署に関する情報、職位に関する情報、使用する端末の識別情報、勤怠情報等が含まれてよい。なお、アカウント情報は、平文形式で送信されてもよいし、または、それらにバイナリ符号化・暗号化・データ圧縮などの処理を施した形式でサーバ１００と、ユーザ端末２００との間で送受信されてよい。

【0043】

次に、ステップＳ１０２において、ユーザが所定のリソース４００へのアクセスを試みると、アクセス時間情報取得部２１が、ユーザによる所定のリソース４００へのアクセス時間情報を取得する。例えば、アクセス時間情報取得部２１は、ユーザがユーザ端末２００を用いて所定のリソースにアクセスを試みた時刻に関する情報を計時部１３から取得することができる。また、アクセス時間情報には、例えば、サーバ１００およびユーザ端末２００のタイムゾーンの情報、曜日の情報、タイムゾーンに基づく祝祭日の情報などが含まれてよい。

【0044】

次に、ステップＳ１０３において、分析部４がポリシー記憶部３に記憶されたポリシーを参照する。ここで、例えば、ポリシーには、ユーザがリソース４００のうちの所定のリソースにアクセス可能な時間帯に関する情報が予め規定されているものとする。例えば、ポリシーには、リソース４００のうちの社内システム４０２にアクセス可能な時間帯は、午前９時から午後５時までの時間帯に限定される旨が規定されてよい。なお、アクセス可能な時間帯は、例えば、ユーザの勤務時間、シフト、休暇情報などを含む勤怠情報に基づいて、ユーザ毎に個別の値が設定されてよい。例えば、ユーザＡの勤怠情報が、２０２１年１０月１８日は、０９時００分から１７時４５分まで勤務する予定となっており、２０２１年１０月１９日は、１７時００分から翌朝の１０時３０分まで勤務する予定となっているものとする。この場合、ポリシー記憶部３は、２０２１年１０月１８日の０９時００分から１７時４５分の期間と、２０２１年１０月１９日の１７時００から２３時５９分の期間と、２０２１年１０月２０日の００時００分から１０時３０分の期間において、ユーザＡがリソース４００にアクセスすることを許可するポリシーを記憶してよい。

【0045】

次に、ステップＳ１０４において、分析部４が、ポリシーを参照して、ユーザによる所定のリソースへのアクセスを許可すべきか否かを分析する。例えば、分析部４は、ポリシーを参照して、ユーザによる社内システム４０２へのアクセスが行われた時間が、ポリシーに規定された所定の時間帯に含まれているか否かに基づいて、ユーザによる所定のリソースへのアクセスを許可すべきか否かを分析する。

【0046】

ステップＳ１０４において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきと分析した場合は、ステップＳ１０５において、アクセス制御部５が、ユーザによる所定のリソースへのアクセスを許可する。例えば、ユーザが社内システム４０２にアクセスした時間が午前１０時である場合は、ポリシーで規定された時間帯（午前９時から午後５時までの時間帯）に含まれているため、アクセス制御部５は、ユーザによる社内システム４０２へのアクセスを許可し、ユーザは社内システム４０２にアクセスすることができる。

【0047】

一方、ステップＳ１０４において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきではないと分析した場合は、ステップＳ１０６において、アクセス制御部５は、ユーザによる所定のリソースへのアクセスを許可しない。例えば、ユーザが社内システム４０２にアクセスした時間が午後６時である場合は、ポリシーで規定された時間帯（午前９時から午後５時までの時間帯）に含まれていないため、アクセス制御部５は、ユーザによる社内システム４０２へのアクセスを許可せず、ユーザは社内システム４０２へのアクセスが制限される。

【0048】

以上のようにして、ユーザが所定のリソース４００へのアクセスを試みた時間がポリシーに規定された時間帯に含まれているか否かに応じて、サーバ１００は、ユーザによる所定のリソース４００へのアクセスを制御することができる。サーバ１００による、アクセス可否の判断結果は、サーバ１００の送受信部７によってユーザ端末２００の送受信部２０３に送信される。ユーザは、ユーザ端末２００の表示部２０２に表示されたアクセス可否の判断結果に基づいて、所定のリソース４００へのアクセスが許可されたか否かを認識することができる。

【0049】

なお、ユーザによる所定のリソース４００へのアクセスが試みられた時間及び、アクセス可否の判断結果に関する情報をアクセスログ記憶部６に記憶してよい。アクセスログ記憶部６に記憶されたアクセスログに関する情報は、ユーザの行動履歴として利用することができる。

【0050】

（第２の例：ユーザの所定エリアへの入退場に基づくアクセス制御）
図３に、本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第２の例を示す。まず、ステップＳ２０１において、ユーザがユーザ端末２００の入力部２０１を用いてユーザのアカウント情報を入力すると、サーバ１００のアカウント情報取得部１がネットワーク３００を介してユーザのアカウント情報を取得する。

【0051】

次に、ステップＳ２０２において、ユーザが所定のリソース４００へのアクセスを試みると、位置情報取得部２２が、ユーザによる所定のリソース４００へのアクセスが行われた時点におけるユーザの位置情報を取得する。例えば、位置情報取得部２２は、ユーザが所属する企業の社屋の入場ゲートに設置された社員証認識装置や、ユーザの顔の画像を画像認識により識別する顔認識装置からの情報に基づいて、ユーザが社屋に入場したか否かに関する情報を取得してよい。あるいは、例えば、ユーザが社屋内の所定の部屋の出入口に設置されたＩＤカード読取装置にＩＤカードを近づけて所定の部屋の鍵を開錠したことを検出した旨の情報を取得することにより、ユーザが所定の部屋に入場しているとの情報を取得することができる。

【0052】

次に、ステップＳ２０３において、分析部４がポリシー記憶部３に記憶されたポリシーを参照する。ここで、例えば、ポリシーには、ユーザによる所定のリソースへのアクセスを許可するための条件として、ユーザが所定の部屋に存在していることが必要である旨規定されているものとする。例えば、ポリシーには、ユーザがリソース４００のうちの機密情報を格納したファイルサーバ４０３にアクセスするためには、ユーザが、ファイルサーバ４０３が設置された部屋（機密エリア）に入室している場合に限定される旨が規定されているものとする。

【0053】

次に、ステップＳ２０４において、分析部４が、ポリシーを参照して、ユーザによる所定のリソースへのアクセスを許可すべきか否かを分析する。例えば、分析部４は、ポリシーを参照して、ユーザによるファイルサーバ４０３へのアクセスが行われた際において、ユーザがポリシーに規定された所定の部屋に入室しているか否かに基づいてアクセスの可否を分析する。

【0054】

ステップＳ２０４において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきと分析した場合は、ステップＳ２０５において、アクセス制御部５が、ユーザによる所定のリソースへのアクセスを許可する。例えば、ユーザがファイルサーバ４０３にアクセスした際に、ユーザが、ファイルサーバ４０３が設置された部屋に入室している場合は、ポリシーで規定された条件である、ファイルサーバ４０３が設置された部屋に入室しているとの条件を満たしているため、ユーザはファイルサーバ４０３にアクセスすることができる。

【0055】

一方、ステップＳ２０４において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきではないと分析した場合は、ステップＳ２０６において、アクセス制御部５は、ユーザによる所定のリソースへのアクセスを許可しない。例えば、ユーザがファイルサーバ４０３にアクセスした際に、ユーザが、ファイルサーバ４０３が設置された部屋に入室していない場合は、ポリシーで規定された条件である、ファイルサーバ４０３が設置された部屋に入室しているとの条件を満たしていないため、ユーザはファイルサーバ４０３へのアクセスが制限される。

【0056】

以上のようにして、ユーザが所定のリソース４００へのアクセスを試みた際に、ユーザが所定の場所に存在しているか否かに応じて、サーバ１００は、ユーザによる所定のリソース４００へのアクセスを制御することができる。サーバ１００による、アクセス可否の判断結果は、サーバ１００の送受信部７によってユーザ端末２００の送受信部２０３に送信される。ユーザは、ユーザ端末２００の表示部２０２に表示されたアクセス可否の判断結果に基づいて、所定のリソース４００へのアクセスが許可されたか否かを認識することができる。

【0057】

なお、ユーザによる所定のリソース４００へのアクセスが試みられた際にユーザが存在した場所及び、アクセス可否の判断結果に関する情報をアクセスログ記憶部６に記憶してよい。アクセスログ記憶部６に記憶されたアクセスログに関する情報は、ユーザの行動履歴として利用することができる。例えば、ユーザが、ポリシーにおいてアクセスが許可されていない場所から、機密情報等が格納された所定のリソースへアクセスを試みたような場合は、不正なアクセスとしてログを記録することができる。

【0058】

（第３の例：ユーザの状態に基づくアクセス制御）
図４に、本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第３の例を示す。まず、ステップＳ３０１において、ユーザがユーザ端末２００の入力部２０１を用いてユーザのアカウント情報を入力すると、サーバ１００のアカウント情報取得部１がネットワーク３００を介してユーザのアカウント情報を取得する。

【0059】

次に、ステップＳ３０２において、ユーザが所定のリソース４００へのアクセスを試みると、人事情報取得部２３が、所定のリソース４００へのアクセスを試みたユーザの人事情報を取得する。例えば、人事情報取得部２３は、ユーザが所属する部署及び部署間の異動に関する情報、ユーザの経歴情報、ユーザの現在の業務内容に関する情報、ユーザの現在の職位及び職位の変動に関する情報、ユーザが現在休暇中であるか否かに関する情報、秘密保持契約の締結状況に関する情報、健康情報あるいは、ユーザが退職届を提出したか否かに関する情報等のユーザの状態に関する情報を、これらの情報が記憶された人事情報記憶部１１から取得してよい。

【0060】

次に、ステップＳ３０３において、分析部４がポリシー記憶部３に記憶されたポリシーを参照する。ここで、例えば、ポリシーには、ユーザによる所定のリソースへのアクセスを許可するための条件として、ユーザが所定の部署に所属していること、ユーザが所定の研修の受講を完了していること、ユーザが所定の業務に携わっていること、ユーザが所定の職位以上であること、ユーザが休暇中ではないこと、あるいは、ユーザが退職届を提出していないこと等が必要である旨規定されてよい。一例として、例えば、ポリシーには、ユーザがリソース４００のうちの所定の社内システム４０２にアクセスするためには、ユーザが、所定の研修の受講を完了していることが規定されていることを条件とする旨規定されている場合を例にとって説明する。

【0061】

次に、ステップＳ３０４において、分析部４が、ポリシーを参照して、ユーザによる所定のリソースへのアクセスを許可すべきか否かを分析する。例えば、分析部４は、ポリシーを参照して、ユーザによる所定の社内システム４０２へのアクセスが行われた時点において、ユーザが、ポリシーに規定された所定の研修の受講を完了させているか否かに基づいてアクセスの可否を分析する。

【0062】

ステップＳ３０４において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきと分析した場合は、ステップＳ３０５において、アクセス制御部５が、ユーザによる所定のリソースへのアクセスを許可する。例えば、ユーザが所定の社内システム４０２にアクセスした時点において、ユーザが所定の研修の受講を完了させている場合は、ポリシーで規定された条件である、所定の研修の受講が完了していることとの条件を満たしているため、ユーザは所定の社内システム４０２にアクセスすることができる。

【0063】

一方、ステップＳ３０４において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきではないと分析した場合は、ステップＳ３０６において、アクセス制御部５は、ユーザによる所定のリソースへのアクセスを許可しない。例えば、ユーザが所定の社内システム４０２にアクセスした時点において、ユーザが、所定の研修の受講を開始したものの、受講を完了させていない場合や、所定の研修の受講を開始していない場合は、ポリシーで規定された条件である、所定の研修の受講が完了していることとの条件を満たしていないため、ユーザは所定の社内システム４０２へのアクセスが制限される。

【0064】

以上のようにして、ユーザが所定のリソース４００へのアクセスを試みた際に、ユーザが、所定の研修の受講が完了しているか否かに応じて、サーバ１００は、ユーザによる所定のリソース４００へのアクセスを制御することができる。サーバ１００による、アクセス可否の判断結果は、サーバ１００の送受信部７によってユーザ端末２００の送受信部２０３に送信される。ユーザは、ユーザ端末２００の表示部２０２に表示されたアクセス可否の判断結果に基づいて、所定のリソース４００へのアクセスが許可されたか否かを認識することができる。

【0065】

なお、ユーザによる所定のリソース４００へのアクセスが試みられた時点において、ユーザによる所定の研修の受講の申し込み状況や、所定の研修の受講の進捗状況、及び、アクセス可否の判断結果に関する情報をアクセスログ記憶部６に記憶してよい。アクセスログ記憶部６に記憶されたアクセスログに関する情報は、ユーザの行動履歴として利用することができる。例えば、ユーザによる所定のリソースへのアクセスの条件として所定の研修の受講を完了させていることがポリシーに規定されているにも関わらず、所定の研修の受講の申し込みすら行っていないような場合は、ユーザに対する監視を強化するか否かを判断する上で参考にすることができる。

【0066】

その他、例えば、ユーザが所定の部署に所属しており、所定のリソースに対するアクセス権を有していたところ、当該ユーザが他の部署に異動した場合は、アクセス制御部５は、ユーザが元の部署に在籍していた際に与えられていたアクセス権限を制限するように制御してよい。

【0067】

また、例えば、降格されたユーザは職場に対して良いイメージを持たない場合があり、降格されたユーザに対しては、監視を強化する必要があるため、ユーザの職位が降格された場合は、アクセス制御部５は、降格前にユーザに与えられていた所定のリソースへのアクセス権限を制限するように制御してよい。

【0068】

また、例えば、ユーザが休職中であって、通常の業務を遂行することが難しいと判断することができる場合は、アクセス制御部５は、ユーザによる所定のリソースへのアクセス権限を制限するように制御してよい。

【0069】

また、例えば、ユーザが退職届を提出した場合には、当該ユーザは他社に転籍する可能性があるため、アクセス制御部５は、退職届を申請する前にユーザに与えられていた所定のリソースに対するアクセス権限を制限するように制御してよい。

【0070】

（第４の例：ユーザの行動履歴等に基づくアクセス制御）
図５に、本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第４の例を示す。まず、ステップＳ４０１において、ユーザがユーザ端末２００の入力部２０１を用いてユーザのアカウント情報を入力すると、サーバ１００のアカウント情報取得部１がネットワーク３００を介してユーザのアカウント情報を取得する。

【0071】

次に、ステップＳ４０２において、ユーザが所定のリソース４００へのアクセスを試みると、履歴情報取得部２４が、ユーザによる所定のリソース４００へのアクセスが行われた時点までの所定の期間における、ユーザの履歴情報を取得する。例えば、履歴情報取得部２４は、ユーザが所定のリソースにアクセスする時点より前のある時点から、ユーザが所定のリソースにアクセスする時点までの所定の期間におけるユーザの行動履歴に関する履歴情報を取得する。例えば、ユーザの行動履歴に関する履歴情報には、ユーザが現在勤務している企業に入社してから、ユーザが所定のリソースにアクセスする時点までにユーザが行った行動の履歴に関する情報が含まれてよい。例えば、履歴情報取得部２４は、ユーザの行動履歴に関する履歴情報として、アクセスログ記憶部６から、ユーザが所定の期間内にどのようなサイトにアクセスしたかを記録したアクセスログに関する情報を取得することができる。

【0072】

次に、ステップＳ４０３において、分析部４がポリシー記憶部３に記憶されたポリシーを参照する。ここで、例えば、ポリシーには、ユーザによる所定のリソースへのアクセスを許可するための条件として、ユーザが過去に社内規定に違反する行動をとっていないことが必要である旨規定されているものとする。例えば、ポリシーには、ユーザがリソース４００のうちのファイルサーバ４０３にアクセスするためには、ユーザが過去に社内規定に違反する行動を１度もとっていない場合に限定される旨が規定されているものとする。

【0073】

分析部４は、人工知能を用いて、ポリシーに合致するか否かの分析を行うこともできる。例えば、一実施形態に係る分析部４は、複数のユーザの行動履歴に関する履歴情報と、各履歴情報がポリシーに適合するか否かを示すデータとを学習データとして学習された学習モデルであって、リソースへのアクセスを試みたユーザの行動履歴を入力データとし、ユーザの行動履歴がポリシーに合致するか否かを出力とする学習モデルを有してよい。学習モデルは、任意の機械学習手法により学習されてよい。例えば、学習モデルは、過去の全社員の行動履歴と、各行動履歴がポリシーに違反するか否かを示すデータを学習データとする教師あり機械学習により学習されてよい。

【0074】

次に、ステップＳ４０４において、分析部４が、ポリシーを参照して、ユーザによる所定のリソースへのアクセスを許可すべきか否かを分析する。例えば、分析部４は、ポリシーを参照して、ユーザによるファイルサーバ４０３へのアクセスが行われる前の所定の期間において、ユーザがポリシーに規定された、社内規定に違反する行動を１度もとっていないか否かに基づいてアクセスの可否を分析する。

【0075】

ステップＳ４０４において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきと分析した場合は、ステップＳ４０５において、アクセス制御部５が、ユーザによる所定のリソースへのアクセスを許可する。例えば、ユーザがファイルサーバ４０３にアクセスするまでの所定の期間において、ユーザが、社内規定に違反する行動を１度もとっていない場合は、ポリシーで規定された条件である、所定期間において社内規定に違反する行動を１度もとっていないとの条件を満たしているため、ユーザはファイルサーバ４０３にアクセスすることができる。

【0076】

一方、ステップＳ４０４において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきではないと分析した場合は、ステップＳ４０６において、アクセス制御部５は、ユーザによる所定のリソースへのアクセスを許可しない。例えば、ユーザがファイルサーバ４０３にアクセスするまでの所定の期間において、ユーザが、社内規定に違反する行動を１度または複数回とっていた場合には、ポリシーで規定された条件である、所定期間において社内規定に違反する行動を１度もとっていないとの条件を満たしていないため、ユーザはファイルサーバ４０３へのアクセスが制限される。

【0077】

以上のようにして、ユーザが所定のリソース４００へのアクセスを試みた際に、ユーザが所定期間において社内規定に違反する行動をとったことがあるか否か否かに応じて、サーバ１００は、ユーザによる所定のリソース４００へのアクセスを制御することができる。サーバ１００による、アクセス可否の判断結果は、サーバ１００の送受信部７によってユーザ端末２００の送受信部２０３に送信される。ユーザは、ユーザ端末２００の表示部２０２に表示されたアクセス可否の判断結果に基づいて、所定のリソース４００へのアクセスが許可されたか否かを認識することができる。

【0078】

なお、ユーザによる所定のリソース４００へのアクセスが試みられた時点までの所定の期間におけるユーザの行動履歴に関する情報や、ユーザのサイトへのアクセス履歴に関する情報、及び、アクセス可否の判断結果に関する情報等をアクセスログ記憶部６に記憶してよい。アクセスログ記憶部６に記憶されたアクセスログに関する情報は、ユーザの行動を監視すべきか否かの判断材料とすることができる。例えば、ユーザが過去に社内規定に違反する行動をとっているにも関わらず、社内の機密情報を格納したファイルサーバにアクセスを試みたような場合には、今後、ユーザに対する監視をさらに強化するか否かを判断する上で参考にすることができる。

【0079】

その他、例えば、ユーザの行動に職務規定に違反する点があると疑われる場合には、アクセス制御部５は、ユーザによる所定のリソースへのアクセス権限を制限するように制御してよい。また、アクセスログ記憶部６に記憶されたユーザの過去のアクセス履歴を記録したログに不正なサイトへのアクセスした記録が見つかった場合には、アクセス制御部５は、ユーザによる所定のリソースへのアクセス権限を制限するように制御してよい。

【0080】

（第５の例：ユーザが使用する端末の機種に基づくアクセス制御）
図６に、本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第５の例を示す。まず、ステップＳ５０１において、ユーザがユーザ端末２００の入力部２０１を用いてユーザのアカウント情報を入力すると、サーバ１００のアカウント情報取得部１がネットワーク３００を介してユーザのアカウント情報を取得する。

【0081】

次に、ステップＳ５０２において、ユーザが所定のリソース４００へのアクセスを試みると、端末情報取得部２５が、ユーザによる所定のリソース４００へのアクセスが行われた時点において、ユーザが使用する端末に関する端末情報を取得する。例えば、端末情報取得部２５は、アカウント情報取得部１が取得したユーザのアカウント情報の中に、ユーザが使用しているユーザ端末２００の識別情報が含まれている場合には、ユーザが使用する端末に関する端末情報をアカウント情報取得部１から取得してよい。あるいは、例えば、ユーザが使用しているユーザ端末２００の識別情報がユーザの識別情報と関連付けて、人事情報記憶部１１に記憶されている場合は、端末情報取得部２５は、ユーザが使用しているユーザ端末２００の識別情報を人事情報記憶部１１から取得してよい。

【0082】

次に、ステップＳ５０３において、分析部４がポリシー記憶部３に記憶されたポリシーを参照する。ここで、例えば、ポリシーには、ユーザによる所定のリソースへのアクセスを許可するための条件として、ユーザは、予め決められた所定のユーザ端末を用いることが必要である旨規定されているものとする。ここでは、一例として、ポリシーには、ユーザがリソース４００のうちのファイルサーバ４０３にアクセスするためには、ユーザが、所定の機能を備えたユーザ端末を用いる場合に限定される旨が規定されている場合を例にとって説明する。

【0083】

次に、ステップＳ５０４において、分析部４が、ポリシーを参照して、ユーザによる所定のリソースへのアクセスを許可すべきか否かを分析する。例えば、分析部４は、ポリシーを参照して、ユーザによるファイルサーバ４０３へのアクセスが行われた際において、ユーザが使用しているユーザ端末２００が、ポリシーに規定された所定のユーザ端末であるか否かに基づいてアクセスの可否を分析する。

【0084】

ステップＳ５０４において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきと分析した場合は、ステップＳ５０５において、アクセス制御部５が、ユーザによる所定のリソースへのアクセスを許可する。例えば、ユーザがファイルサーバ４０３にアクセスした際に使用しているユーザ端末２００が、ポリシーで規定された所定の機能を備えたユーザ端末である場合には、ポリシーで規定された条件である、所定の機能を備えたユーザ端末であるとの条件を満たしているため、ユーザはファイルサーバ４０３にアクセスすることができる。

【0085】

一方、ステップＳ５０４において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきではないと分析した場合は、ステップＳ５０６において、アクセス制御部５は、ユーザによる所定のリソースへのアクセスを許可しない。例えば、ユーザがファイルサーバ４０３にアクセスした際に使用しているユーザ端末２００が、ポリシーで規定された所定の機能を備えていない場合には、ポリシーで規定された条件である、所定の機能を備えたユーザ端末であるとの条件を満たしていないため、ユーザはファイルサーバ４０３へのアクセスが制限される。

【0086】

以上のようにして、ユーザが所定のリソース４００へのアクセスを試みた際に使用しているユーザ端末が、ポリシーで規定された所定の機能を有するか否かに応じて、サーバ１００は、ユーザによる所定のリソース４００へのアクセスを制御することができる。サーバ１００による、アクセス可否の判断結果は、サーバ１００の送受信部７によってユーザ端末２００の送受信部２０３に送信される。ユーザは、ユーザ端末２００の表示部２０２に表示されたアクセス可否の判断結果に基づいて、所定のリソース４００へのアクセスが許可されたか否かを認識することができる。

【0087】

なお、ユーザによる所定のリソース４００へのアクセスが試みられた際にユーザが使用したユーザ端末の識別情報、及び、アクセス可否の判断結果に関する情報をアクセスログ記憶部６に記憶してよい。アクセスログ記憶部６に記憶されたアクセスログに関する情報は、ユーザの行動履歴として利用することができる。例えば、ポリシーにおいて、アクセスが許可されていない、ユーザが個人で所有しているユーザ端末を用いて、機密情報等が格納された所定のリソースへアクセスを試みたような場合は、不正なアクセスとしてログを記録することができる。

【0088】

（第６の例：複合的なユーザ状態情報に基づくアクセス制御）
図７に、本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートの第６の例を示す。上記の第１の例から第５の例においては、１つのユーザの状態情報に基づいてアクセス制御を行う例について説明したが、このような例には限られず、複数のユーザ状態情報に基づいてアクセス制御を行うようにしてよい。

【0089】

例えば、ステップＳ６０１において、アカウント情報取得部１がユーザのアカウント情報を取得した後、ステップＳ６０２においてアクセス時間情報取得部２１が、ユーザによる所定のリソースへのアクセス時間に関する情報を取得し、ステップＳ６０３において、位置情報取得部２２が、ユーザによる所定のリソースへのアクセスが試みられた際に、ユーザが存在する位置に関する位置情報を取得する。

【0090】

次に、ステップＳ６０４において、分析部４がポリシー記憶部３に記憶されたポリシーを参照する。ここで、例えば、ポリシーには、ユーザがリソース４００のうちの所定のリソースにアクセスすることができるのは、アクセスを行う時間帯が所定の時間帯であるという第１条件、及び、アクセスを試みるユーザが所定の場所に存在するという第２の条件の両者を満たす必要がある旨規定されているものとする。例えば、ポリシーには、リソース４００のうちの社内システム４０２にアクセス可能な時間帯は、午前９時から午後５時までの時間帯であって、かつ、ユーザが所定の部屋に入室している場合に限定される旨が規定されているものとする。なお、サーバ１００と、ユーザ端末２００とが、異なるタイムゾーンの地域に位置する場合、アクセス時間に関する情報に含まれるタイムゾーンの情報に基づいて、サーバ１００もしくはユーザ端末２００の一方にタイムゾーンを合わせて判定を行ってもよい。具体的には、例えば、日本国外にある事業所に居るユーザが、日本国内のリソース４００にアクセスを行う場合、日本時間に基づくアクセス許可時間で判定を行ってもよいし、ユーザが所在する国の標準時で判定を行ってもよい。

【0091】

次に、ステップＳ６０５において、分析部４が、ポリシーを参照して、ユーザによる所定のリソースへのアクセスを許可すべきか否かを分析する。例えば、分析部４は、ポリシーを参照して、ユーザによる社内システム４０２へのアクセスが行われた時間が、ポリシーに規定された所定の時間帯に含まれているという第１の条件を満たしており、かつ、ユーザによる社内システム４０２へのアクセスが試みられた際にユーザが所定の部屋に入室しているという第２の条件を満たしているか否かに基づいてアクセスの可否を分析する。

【0092】

ステップＳ６０５において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきと分析した場合は、ステップＳ６０６において、アクセス制御部５が、ユーザによる所定のリソースへのアクセスを許可する。例えば、ユーザが社内システム４０２にアクセスした時間が午前１０時である場合は、ポリシーで規定された時間帯（午前９時から午後５時までの時間帯）に含まれているため、ユーザは社内システム４０２にアクセスするための第１の条件を満たしている。また、ユーザが社内システム４０２にアクセスを試みた際に、ユーザが所定の部屋に入室していた場合には、ユーザは社内システム４０２にアクセスするための第２の条件を満たしている。従って、このように、第１の条件と第２の条件の両者を満たしている場合には、アクセス制御部５が、ユーザによる所定のリソースへのアクセスを許可する。

【0093】

一方、ステップＳ６０５において、分析部４が、ユーザによる所定のリソースへのアクセスを許可すべきではないと分析した場合は、ステップＳ６０７において、アクセス制御部５は、ユーザによる所定のリソースへのアクセスを許可しない。例えば、ユーザが社内システム４０２にアクセスした時間が午後６時である場合は、ポリシーで規定された時間帯（午前９時から午後５時までの時間帯）に含まれていないため、分析部４は、ユーザが社内システム４０２にアクセスするための第１の条件を満たしていないと分析し、ユーザは社内システム４０２へのアクセスが制限される。なお、ユーザが社内システム４０２にアクセスした時間が午前１０時である場合は、ポリシーで規定された時間帯（午前９時から午後５時までの時間帯）に含まれているため、分析部４は、ユーザが社内システム４０２にアクセスするための第１の条件を満たしていると分析するが、この場合であっても、ユーザが社内システム４０２にアクセスを試みた際に、ユーザが所定の部屋に入室していなかった場合には、分析部４は、ユーザが社内システム４０２にアクセスするための第２の条件を満たしていないと分析し、ユーザは社内システム４０２へのアクセスが制限される。

【0094】

以上のようにして、ユーザが所定のリソース４００へのアクセスを試みた時間及び場所がポリシーに規定された複合的な条件を満たしているか否かに応じて、サーバ１００は、ユーザによる所定のリソース４００へのアクセスを制御することができる。サーバ１００による、アクセス可否の判断結果は、サーバ１００の送受信部７によってユーザ端末２００の送受信部２０３に送信される。ユーザは、ユーザ端末２００の表示部２０２に表示されたアクセス可否の判断結果に基づいて、所定のリソース４００へのアクセスが許可されたか否かを認識することができる。

【0095】

なお、上記の例では、ユーザによる所定のリソース４００へのアクセスを制御するための条件として、ユーザが所定のリソースへのアクセスを試みた時間、及び、ユーザが所定のリソースへのアクセスを試みた際の場所の２つのユーザ状態情報に基づいてアクセス制御を行う例について示したが、これらのユーザ状態情報には限定されず、他の複数のユーザ状態情報に基づいてアクセス制御を行うようにしてもよい。アクセス制御を行うためのユーザ状態情報の数を増やすことにより、より厳密にアクセス制御を実行することができる。

【0096】

また、複数のユーザ状態情報に基づいて、ユーザによる所定のリソースへのアクセス制御を行う例として、例えば、ユーザの識別情報と、ユーザの業務内容に関する情報の２つの情報に基づいて、アクセス制御を行ってもよい。例えば、カスタマーサポート（ＣＳ）業務を行っているユーザである担当者が、問合せ対応中に、ユーザが担当している顧客のみに対してメール送信を許可するようにして、アクセス制御を行ってよい。

【0097】

また、複数のユーザ状態情報に基づいて、ユーザによる所定のリソースへのアクセス制御を行う他の例として、例えば、ユーザの識別情報と、ユーザの勤務時間に関する情報の２つの情報に基づいて、アクセス制御を行ってもよい。例えば、ユーザである社員が、勤務時間外における、社外から社内システムへのアクセス回数が所定の閾値を超えた場合にアクセスを制限するようにしてよい。

【0098】

また、複数のユーザ状態情報に基づいて、ユーザによる所定のリソースへのアクセス制御を行うさらに他の例として、例えば、ユーザが所定の部屋へ入室しているか否かに関する情報と、所定の部屋への入室が所定の時間帯に行われているかに関する情報の２つの情報に基づいて、アクセス制御を行ってもよい。例えば、ユーザが許可された時間帯においてのみ、限られたエリアに立ち入ることを許可するように、入室管理システムを制御するようにしてよい。

【0099】

また、複数のユーザ状態情報に基づいて、ユーザによる所定のリソースへのアクセス制御を行うさらに他の例として、例えば、所定の施設、あるいは、所定の部屋への入場に関する情報と、ユーザの健康情報との２つの情報に基づいて、アクセス制御を行ってもよい。例えば、ユーザがアクセスを行っている場所が、ポリシーで定められたアクセスを許可する場所である場合あっても、ユーザの健康情報に所定のハイリスク疾患が含まれる場合には、分析部４は社内システムへの不正アクセスと判定し、アクセス制御部５はアクセスを制限するようにしてよい。

【0100】

（複数のユーザ状態情報の重み付けによるアクセス制御）
上記の複数のユーザ状態情報に基づくアクセス制御においては、各ユーザ状態情報の重みについては考慮されていない。しかしながら、複数のユーザ状態情報には、重要度に応じて重み付けを行ってもよい。そこで、複数のユーザ状態情報の重み付けを行って、アクセス制御を行う例について説明する。

【0101】

図８に、本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートであって、複数のユーザ状態情報の重み付けによるアクセス制御を実行する場合のフローチャートの例を示す。本開示の一実施形態に係るサーバの分析部は、複数のユーザ状態情報のそれぞれの重要性に応じて、複数のユーザ状態情報のそれぞれがアクセス許可条件を満たさなかった場合に積算する値の重み付けを行い、複数のユーザ状態情報のそれぞれがアクセス許可条件を満たすか否かを判断し、値の積算値が所定の閾値を超えるか否かに基づいて、アクセス可否を判断してよい。

【0102】

まず、ステップＳ７０１において、分析部４は、ユーザの個人認証を行う。個人認証では、アカウント情報が、ポリシーに規定された所定の条件（以下、「アクセス許可条件」ともいう。）を満たすか否かを判定する。アクセス許可条件とは、例えば、ユーザによって入力されたユーザ識別情報とパスワードとの組み合わせが、アカウント情報と一致することであってよい。個人認証の結果、アクセス許可条件を満たさない場合（ＮＧ）、ステップＳ７１６において、アクセス制御部５は、ユーザによるアクセスを拒否する。

【0103】

一方、ステップＳ７０１において、個人認証の結果、アクセス許可条件を満たす場合（ＯＫ）、ステップＳ７０２において、分析部４が、リクエスト先のアクセス許可条件を取得する。アクセス許可条件はポリシー記憶部３に記憶されたポリシーであってよい。

【0104】

次に、ステップＳ７０３において、ユーザ状態情報取得部２が、ユーザの状態を示す情報を取得する。ユーザの状態を示す情報には、個人認証に関する情報、アクセスを実行する「人」、「場所」、「時間」、「業務」のそれぞれに関する情報、及び「行動履歴」に関する情報が含まれてよい。

【0105】

次に、ステップＳ７０４において、分析部４が、ユーザ状態情報に含まれる属性情報が、アクセス許可条件を満たすか否か（以下、「人」の整合性ともいう）を判定する。

【0106】

ステップＳ７０４において、「人」の整合性の条件を満たさない場合（ＮＧ）は、ステップＳ７０５において、ＮＧ値が１加算される。具体的には、例えば、アクセス許可条件として、「人事部に所属するユーザであること」が定められており、属性情報に含まれるユーザの所属する部署の情報が「法務部」である場合は、分析部４はＮＧと判定してよい。その他、分析部４は、ユーザの業務情報、経歴情報、健康情報、勤怠情報が、「人」の整合性の条件を満たすか否かを判断してよい。なお、ＮＧ値の初期値は０としてよい。ここで、「ＮＧ値」とは、整合性の判断要素の重要性に応じて決められた値であって、後述する追加認証を行う場合に場合分けをするために用いる値である。

【0107】

一方、ステップＳ７０４において、ユーザの状態を示す情報が、「人」の整合性の条件を満たす場合（ＯＫ）は、ＮＧ値は加算されずに、ステップＳ７０６において、分析部４が、ユーザ状態情報に含まれる位置情報が、アクセス許可条件を満たすか否か（以下、「場所」の整合性ともいう）を判定する。

【0108】

ステップＳ７０６において、ユーザの状態を示す情報が、「場所」の整合性の条件を満たさない場合（ＮＧ）は、ステップＳ７０７において、ＮＧ値が２加算される。具体的には、例えば、アクセス許可条件として、「オペレーションルームに入室していること」が定められており、ユーザの位置情報は「会議室」に入室している場合、分析部４はＮＧと判定してよい。

【0109】

一方、ステップＳ７０６において、ユーザの状態を示す情報が、「場所」の整合性の条件を満たす場合（ＯＫ）は、ＮＧ値は加算されずに、ステップＳ７０８において、分析部４が、ユーザ状態情報に含まれるアクセス時間情報が、アクセス許可条件を満たすか否か（以下、「時間」の整合性ともいう）を判定する。

【0110】

ステップＳ７０８において、ユーザの状態を示す情報が、「時間」の整合性の条件を満たさない場合（ＮＧ）は、ステップＳ７０９において、ＮＧ値が４加算される。具体的には、例えば、アクセス許可条件として、「平日０９時００分から１７時４５分まで」が定められており、アクセス時間情報は、「平日２２時００分」である場合、分析部４はＮＧと判定してよい。

【0111】

一方、ステップＳ７０８において、ユーザ状態情報が、「時間」の整合性の条件を満たす場合（ＯＫ）は、ＮＧ値は加算されずに、ステップＳ７１０において、分析部４が、ユーザ状態情報に含まれる業務情報が、アクセス許可条件を満たすか否か（以下、「業務」の整合性ともいう）を判定する。

【0112】

ステップＳ７１０において、ユーザ状態情報が、「業務」の整合性の条件を満たさない場合（ＮＧ）は、ステップＳ７１１において、ＮＧ値が８加算される。具体的には、例えば、アクセス許可条件として、「顧客対応」が定められており、業務情報は、「経理」である場合、分析部４はＮＧと判定してよい。

【0113】

一方、ステップＳ７１０において、ユーザの状態を示す情報が、「業務」の整合性の条件を満たす場合（ＯＫ）は、ＮＧ値は加算されずに、ステップＳ７１２において、分析部４が、ユーザの行動履歴がアクセス許可条件を満たすか否か（以下、「行動履歴」の整合性ともいう）を判定する。

【0114】

ステップＳ７１２において、ユーザの行動履歴がアクセス許可条件を満たさない場合（ＮＧ）は、ステップＳ７１３において、ＮＧ値が１６加算される。具体的には、例えば、アクセス許可条件として、「アクセス権限を持たないシステムへのログイン試行が一度もないこと」が定められており、行動履歴には、「アクセス権限を持たないシステムへのログイン試行があること」が記録されている場合、分析部４はＮＧと判定してよい。

【0115】

一方、ステップＳ７１２において、ユーザの行動履歴が所定の条件を満たす場合（ＯＫ）は、ＮＧ値は加算されずに、ステップＳ７１４において、ＮＧ値が閾値を超えているか否かが判定される。

【0116】

ステップＳ７１４において、ＮＧ値が所定の閾値（例えば、１）以下である場合（Ｎｏ）は、ステップＳ７１５において、アクセス制御部５は、ユーザによるリクエスト先へのアクセスを許可する。

【0117】

一方、ステップＳ７１４において、ＮＧ値が所定の閾値を超えている場合（Ｙｅｓ）は、後述するように、図１０に示すフローチャートにおいて、続けて処理が行われる。本実施例では閾値を１とした例について説明するが、このような例には限定されず、閾値は２以上であってもよい。また、閾値は、全てのリソースに対して共通の値であってもよいし、各リソースに対してそれぞれ異なる値が設定されてもよい。なお、図８では、Ｓ７０３からＳ７１２までの６段階で認証を行う例を示したが、用いる認証の段階は、全てのリソースに対して共通する必要はない。具体的には、例えば、リソースＡに対しては、Ｓ７０３で示した個人認証と、Ｓ７０４の「人」の整合性の２段階のみの確認とし、リソースＢについては、Ｓ７０３からＳ７１２までの全ての段階の確認を行ってよい。アクセス許可の判定に用いる要素は、例えば、リソースの重要度、個人認証の結果、即ち、ユーザに応じた条件等で変更されてよい。

【0118】

図８に示した認証フローでは、「人」の整合性、「場所」の整合性、「時間」の整合性、「業務」の整合性、「行動履歴」の整合性の順でＮＧ値が大きな値となるように設定されている。例えば、図８において、「人」の整合性、「場所」の整合性、「時間」の整合性、「業務」の整合性の４項目がＮＧで、「行動履歴」の整合性がＯＫである場合、ＮＧ値は、１５となり、「人」の整合性、「場所」の整合性、「時間」の整合性、「業務」の整合性の４項目がＯＫで、「行動履歴」の整合性の１項目がＮＧである場合、ＮＧ値は１６となる。すなわち、ＮＧ値は、整合性がＮＧである項目の数ではなく、整合性がＮＧであった項目の内容に応じて、変化する値であってよい。言い換えると、アクセス制御対象のリソースへのアクセス制御において、重要な項目のＮＧ値を大きくしてよい。例えば、図８に示した認証フローにおいては、「行動履歴」の整合性が最も重要な認証項目と言える。このように各認証項目に対して、異なるＮＧ値を設定することで、認証項目の重要度を考慮した認証が可能となる。

【0119】

ここで、ユーザの状態を示す情報が、「人」、「場所」、「時間」、「業務」、「行動履歴」のそれぞれの整合性の条件（アクセス許可条件）を満たさない場合に積算するＮＧ値について、図９に示すように、各要素の重要性に基づいて、重み付けを行ってよい。図９において、ＮＧ要素が、「人」、「場所」、「時間」、「業務」、「行動履歴」である場合における、それぞれのＮＧ値重みを、「１」、「２」、「４」、「８」、「１６」とした例を示しているが、このような例には限られず、他の値となるように設定してよい。また、各要素の重み付けは、全てのリソースに対して共通の値であってもよいし、各リソースに対して、それぞれ異なる値が設定されてもよい。

【0120】

図８に示したフローチャートにおいて、ＮＧ値が閾値を超えている場合において、ＮＧ値の大きさに応じて追加認証を行ってアクセスを許可するようにしてよい。即ち、アクセス制御部５は、複数の追加認証方式のうちから、値に応じて適切なレベルの認証方式を選択して、アクセス許可の追加認証を行ってよい。上記の通り、ユーザの状態を示す情報が、「人」、「場所」、「時間」、「業務」、「行動履歴」のそれぞれの整合性の条件を満たさない場合に加算されるＮＧ値（合計値）が所定の閾値を超えた場合には、リクエスト先へのアクセスが許可されないが、セキュリティを担保する等の他の手段により、追加的に認証を行ってアクセスを許容することが好ましい場合があり得る。そこで、ＮＧ値の合計値が所定の閾値を超えている場合に追加認証を行うことによりアクセスを許容する例について説明する。なお、ＮＧ値の合計値が大きい程、アクセスを許可するための追加認証をより慎重に行う必要があると考えられるため、ＮＧ値の合計値の大きさに応じて、追加認証の内容を調整してよい。

【0121】

図１０に、本開示の一実施形態に係るサーバの動作手順を説明するためのフローチャートであって、複数のユーザ状態情報の重み付けによるアクセス制御を実行する場合のフローチャートの例を示す。図８に示したステップＳ７１４において、ＮＧ値が所定の閾値を超えている場合は、ＮＧ値の大きさに応じて場合分けがなされる。

【0122】

ステップＳ７１７において、分析部４は、ＮＧ値が１５より大きいか否かを判定する。ステップＳ７１７において、ＮＧ値が１５より大きい場合（ＮＧ値＞１５）は、ステップＳ７１８において、アクセス制御部５が追加認証（４）を行う。追加認証（４）は、例えば、ワンタイムパスワードの入力、メールリンク押下により上長の承認を得ること、及びパスワードを強制的にリセットすることであってよい。

【0123】

次に、ステップＳ７１９において、分析部４は、追加認証（４）がＯＫであるか否か、即ち、追加認証（４）が適切に行われたか否かを判定する。追加認証（４）がＯＫである場合（Ｙｅｓ）は、ステップＳ７２０において、アクセス制御部５がアクセスを許可する。一方、追加認証（４）がＯＫではない場合（Ｎｏ）は、ステップＳ７２１において、アクセス制御部５がアクセスを拒否する。

【0124】

ステップＳ７１７において、ＮＧ値が１５以下である場合、ステップＳ７２２において、分析部４は、ＮＧ値が７より大きいか否かを判定する。ステップＳ７２２において、ＮＧ値が７より大きい場合（７＜ＮＧ値≦１５）は、ステップＳ７２３において、アクセス制御部５が追加認証（３）を行う。追加認証（３）は、例えば、ワンタイムパスワードを入力すること、及びメールリンク押下により上長の承認を得ることであってよい。

【0125】

次に、ステップＳ７２４において、分析部４は、追加認証（３）がＯＫであるか否か、即ち、追加認証（３）が適切に行われたか否かを判定する。追加認証（３）がＯＫである場合（Ｙｅｓ）は、ステップＳ７２５において、アクセス制御部５がアクセスを許可する。一方、追加認証（３）がＯＫではない場合（Ｎｏ）は、ステップＳ７２６において、アクセス制御部５がアクセスを拒否する。

【0126】

ステップＳ７２２において、ＮＧ値が７以下である場合、ステップＳ７２７において、分析部４は、ＮＧ値が３より大きいか否かを判定する。ステップＳ７２７において、ＮＧ値が３より大きい場合（３＜ＮＧ値≦７）は、ステップＳ７２８において、アクセス制御部５が追加認証（２）を行う。追加認証（２）は、例えば、ワンタイムパスワードを入力することであってよい。

【0127】

次に、ステップＳ７２９において、分析部４は、追加認証（２）がＯＫであるか否か、即ち、追加認証（２）が適切に行われたか否かを判定する。追加認証（２）がＯＫである場合（Ｙｅｓ）は、ステップＳ７３０において、アクセス制御部５がアクセスを許可する。一方、追加認証（２）がＯＫではない場合（Ｎｏ）は、ステップＳ７３１において、アクセス制御部５がアクセスを拒否する。

【0128】

ステップＳ７２７において、ＮＧ値が３以下である場合（１＜ＮＧ値≦３）は、ステップＳ７３２において、アクセス制御部５が追加認証（１）を行う。追加認証（１）は、例えば、メールリンクを押下することであってよい。

【0129】

次に、ステップＳ７３３において、分析部４は、追加認証（１）がＯＫであるか否か、即ち、追加認証（１）が適切に行われたか否かを判定する。追加認証（１）がＯＫである場合（Ｙｅｓ）は、ステップＳ７３４において、アクセス制御部５がアクセスを許可する。一方、追加認証（１）がＯＫではない場合（Ｎｏ）は、ステップＳ７３５において、アクセス制御部５がアクセスを拒否する。

【0130】

図１１に、本開示の一実施形態に係るサーバにおいて、ＮＧ値範囲と追加認証の例を示す。ＮＧ値は、認証フローにおいて満たさなかった整合性が多いほど、大きな値となってよい。この場合、ＮＧ値が大きいほど、リソースへアクセスを試みているユーザが正規のユーザでない可能性が高くなる。すなわち、認証フローにおいて、ＮＧ値の値が大きくなるほど、追加認証がより厳しい方法で行われてよい。例えば、ＮＧ値が３以下の場合と、ＮＧ値が３より大きく７以下の場合とでは、前者の場合よりも後者の場合の方が厳しい方法によって追加認証が実行されてよい。ここでは、４通りの追加認証を行う例を示したが、追加認証の種類は４通りには限られない。ＮＧ値が、０以上、１以下である場合（０≦ＮＧ値≦１）は、ＮＧ値が閾値（＝１）以下であるため、追加認証無しでアクセスが許可される。

【0131】

図１１に示すように、ＮＧ値の大きさに応じて、追加認証の内容を調整することにより、アクセス可否を判断するためのユーザ状態情報の重要度に従って、アクセス権限の制御を適切に実行することができる。

【0132】

以上の説明において、サーバが、ユーザの状態情報の分析の結果に基づいて、ユーザの所定のリソースへのアクセスを許可するか否かを制御する例について説明したが、このような例には限られず、アクセス制御部５は、分析部４による分析結果に基づいて、ユーザがアクセス可能なリソースを切り替えるように制御してよい。例えば、ユーザの状態情報が、ポリシーに規定された所定の第１条件を満たしている場合には、第１のリソースへのアクセスを許可し、ユーザの状態情報が、ポリシーに規定された所定の第２条件を満たしている場合には、第２のリソースへのアクセスを許可するようにして、ユーザがアクセス可能なリソースを切り替えるように制御してよい。具体的には、例えば、ユーザが機密情報を格納したファイルサーバ４０３にアクセスしようとした場合に、ユーザの状態情報の分析の結果、機密情報を格納したファイルサーバ４０３へのアクセスを許可できないと分析した場合に、機密情報を含まない他のファイルサーバへのアクセスを許可するように、アクセス可能なリソースを切り替えるように制御してよい。このようにすることで、ユーザの状態情報に基づいて、ユーザがアクセス可能なリソースを適切に切り替えることができる。

【符号の説明】

【0133】

１ アカウント情報取得部
２ ユーザ状態情報取得部
３ ポリシー記憶部
４ 分析部
５ アクセス制御部
６ アクセスログ記憶部
７ 送受信部
２１ アクセス時間情報取得部
２２ 位置情報取得部
２３ 人事情報取得部
２４ 履歴情報取得部
２５ 端末情報取得部
１００ サーバ
２００ ユーザ端末
２０１ 入力部
２０２ 表示部
２０３ 送受信部
３００ ネットワーク
４００ リソース
４０１ ＳａａＳ
４０２ 社内システム
４０３ ファイルサーバ
４０４ インターネット接続

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】