(57)【要約】    【課題】シングルサインオンによるセキュリティ上の脅威を緩和するシングルサインオンサーバ技術を提供する。    【解決手段】ログイン画面生成部１０２は、ＳＳＯサーバ１０のポータルのログイン画面を生成する。認証部１０３はユーザから入力されたユーザ名およびパスワードを用いてＳＳＯ自体のユーザ認証を行う。ＳＳＯサーバ１０は、認証データ保持部１０５に保持されているマップデータを用いてアプリケーションにおけるユーザ認証を代行する。不正アクセス検知部１０７は、「不正アクセス」の可能性のあるアクセス挙動を検知する。ＳＳＯサーバ１０は「不正アクセス」の可能性がある場合にはアクセス機能をダウングレードする【選択図】図３
2009003559.tif 000002
【特許請求の範囲】
【請求項１】
ユーザアカウント識別子およびユーザ認証用情報を伴う認証要求をクライアント端末から受け取ってユーザ認証を行ない、ユーザ認証に成功したユーザアカウントのバックエンドサーバコンピュータのアプリケーションサービスへのアクセスを中継する際に当該バックエンドサーバコンピュータのアプリケーションサービスとの間の認証手続を当該ユーザアカウントのユーザ情報に基づいて代理するシングルサインオンサーバ用コンピュータシステムにおいて、上記認証要求を受け取ったときの要求状況が所定の条件を充足する場合に上記バックエンドサーバコンピュータのアプリケーションサービスへのアクセスを制限するアクセス制限手段を有することを特徴とするシングルサインオンサーバ用コンピュータシステム。
【請求項２】
上記所定の条件は、
（１）認証要求を送信するクライアント端末が同一のユーザアカウントを使用した所定の過去の認証要求を送信したクライアント端末と異なるという条件、
（２）認証要求がインターネットを介して行われるという条件、
（３）ユーザ認証が成功するまでの間に行われたユーザ認証用情報の入力ミスの回数が設定値を越えているという条件、
（４）ユーザ認証が成功するまでの間に行われたユーザ認証用情報の入力ミスのパターンが過去に他のユーザアカウントに対して行われた入力ミスのパターンと一致するという条件、
（５）ユーザ認証が成功するまでの間に行われたユーザ認証用情報の入力ミスを構成するユーザ認証情報がユーザ名と一致するという条件、
（６）同一のクライアント端末から所定数以上のユーザアカウントのユーザ認証要求が行われるという条件、
（７）同一のクライアント端末からの最後のアクセスがあってから所定時間経過した後に再度アクセスがあるという条件、
（８）通常と異なる時間帯に認証要求が行われるという条件、
（９）当該ユーザアカウントのユーザが常時使用しているクライアント端末と異なるクライアント端末からユーザ認証要求が行われるという条件
のうちの少なくとも１つである請求項１記載のシングルサインオンサーバ用コンピュータシステム。
【請求項３】
ユーザアカウントごと予め登録されている中継可能なアプリケーションサービスへのアクセスのみを中継可能にする請求項１または２に記載のシングルサインオンサーバ用コンピュータシステム。
【請求項４】
上記アクセス制限手段が、予め登録されているアプリケーションサービスに対してのみアクセスを制限する請求項１から３のいずれかに記載のシングルサインオンサーバ用コンピュータシステム。
【請求項５】
上記アクセス制限手段は、
（１）ユーザ認証に成功したユーザアカウントのバックエンドサーバコンピュータのアプリケーションサービスへのアクセスを中継する際に、当該バックエンドサーバコンピュータのアプリケーションサービスとの間の認証手続を当該ユーザアカウントのユーザ情報に基づいて代理することなく、上記クライアント端末から少なくとも当該バックエンドコンピュータのアプリケーションサービスに対する当該ユーザアカウントの真正な認証情報が供給されて初めて当該アプリケーションサービスに対するアクセスが許可される制限処理、
（２）予め登録されているバックエンドサーバコンピュータのアプリケーションサービスへのアクセスを拒否する制限処理、
のいずれかを実行する請求項１から４のいずれかに記載のシングルサインオンサーバ用コンピュータシステム。
【請求項６】
ユーザアカウント識別子およびユーザ認証用情報を伴う認証要求をクライアント端末から受け取ってユーザ認証を行ない、ユーザ認証に成功したユーザアカウントのバックエンドサーバコンピュータのアプリケーションサービスへのアクセスを中継する際に当該バックエンドサーバコンピュータのアプリケーションサービスとの間の認証手続を当該ユーザアカウントのユーザ情報に基づいて代理するシングルサインオンサーバ用のプログラムにおいて、サーバコンピュータを、上記認証要求を受け取ったときの要求状況が所定の条件を充足する場合に上記バックエンドサーバコンピュータのアプリケーションサービスへのアクセスを制限するアクセス制限手段として機能させることを特徴とするシングルサインオンサーバ用のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、シングルサインオンサーバ用コンピュータシステム及びプログラムの技術に関する。
【背景技術】
【０００２】
シングルサインオン（ＳＳＯともいう）はユーザの利便性を向上させる反面、パスワードが漏洩した場合には、１回のログインですべてのシステムが使用できてしまうので、セキュリティ上の脅威が増すという問題がある。不正に取得したパスワードを使用した攻撃者からのアクセスに対して、同一アカウントによる同時アクセスの禁止のような対策も考えられるが、一方のアクセスが正規のユーザからのアクセスだった場合は、逆に利便性を損ねることになる。
【０００３】
なお、本発明と関連する先行技術としては特許文献１がある。この特許文献は、自身が管理するユーザと、バックエンドのサーバコンピュータで動作するアプリケーションのユーザとのマップ情報に基づいて代理認証を行う、リバースプロシキ型のＳＳＯを開示している。
【０００４】
なお、上述の背景技術および先行技術は、本発明の背景の一部を説明するためにのみ説明されている。本発明は上述の背景技術や問題点に限定されるものではない点に留意されたい。
【特許文献１】特開２００５−３２１９７０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は、シングルサインオンによるセキュリティ上の脅威を緩和するシングルサインオンサーバ技術を提供することを、目的としている。
【課題を解決するための手段】
【０００６】
請求項１に記載の発明は、ユーザアカウント識別子およびユーザ認証用情報を伴う認証要求をクライアント端末から受け取ってユーザ認証を行ない、ユーザ認証に成功したユーザアカウントのバックエンドサーバコンピュータのアプリケーションサービスへのアクセスを中継する際に当該バックエンドサーバコンピュータのアプリケーションサービスとの間の認証手続を当該ユーザアカウントのユーザ情報に基づいて代理するシングルサインオンサーバ用コンピュータシステムにおいて、上記認証要求を受け取ったときの要求状況が所定の条件を充足する場合に上記バックエンドサーバコンピュータのアプリケーションサービスへのアクセスを制限するアクセス制限手段を有することを特徴とする。
【０００７】
請求項２に記載に発明は、請求項１に記載の発明において、上記所定の条件は、（１）認証要求を送信するクライアント端末が同一のユーザアカウントを使用した所定の過去の認証要求を送信したクライアント端末と異なるという条件、（２）認証要求がインターネットを介して行われるという条件、（３）ユーザ認証が成功するまでの間に行われたユーザ認証用情報の入力ミスの回数が設定値を越えているという条件、（４）ユーザ認証が成功するまでの間に行われたユーザ認証用情報の入力ミスのパターンが過去に他のユーザアカウントに対して行われた入力ミスのパターンと一致するという条件、（５）ユーザ認証が成功するまでの間に行われたユーザ認証用情報の入力ミスを構成するユーザ認証情報がユーザ名と一致するという条件、（６）同一のクライアント端末から所定数以上のユーザアカウントのユーザ認証要求が行われるという条件、（７）同一のクライアント端末からの最後のアクセスがあってから所定時間経過した後に再度アクセスがあるという条件、（８）通常と異なる時間帯に認証要求が行われるという条件、（９）当該ユーザアカウントのユーザが常時使用しているクライアント端末と異なるクライアント端末からユーザ認証要求が行われるという条件のうちの少なくとも１つであることを特徴とする。
【０００８】
請求項３に記載の発明は、請求項１または２に記載の発明において、ユーザアカウントごと予め登録されている中継可能なアプリケーションサービスへのアクセスのみを中継可能にすることを特徴とする。
【０００９】
請求項４に記載の発明は、請求項１から３のいずれかに記載の発明において、上記アクセス制限手段が、予め登録されているアプリケーションサービスに対してのみアクセスを制限することを特徴とする。
【００１０】
請求項５に記載の発明は、請求項１から４のいずれかに記載の発明において、  上記アクセス制限手段は、（１）ユーザ認証に成功したユーザアカウントのバックエンドサーバコンピュータのアプリケーションサービスへのアクセスを中継する際に、当該バックエンドサーバコンピュータのアプリケーションサービスとの間の認証手続を当該ユーザアカウントのユーザ情報に基づいて代理することなく、上記クライアント端末から少なくとも当該バックエンドコンピュータのアプリケーションサービスに対する当該ユーザアカウントの真正な認証情報が供給されて初めて当該アプリケーションサービスに対するアクセスが許可される制限処理、（２）予め登録されているバックエンドサーバコンピュータのアプリケーションサービスへのアクセスを拒否する制限処理、のいずれかを実行することを特徴とする。
【００１１】
請求項６に記載の発明は、ユーザアカウント識別子およびユーザ認証用情報を伴う認証要求をクライアント端末から受け取ってユーザ認証を行ない、ユーザ認証に成功したユーザアカウントのバックエンドサーバコンピュータのアプリケーションサービスへのアクセスを中継する際に当該バックエンドサーバコンピュータのアプリケーションサービスとの間の認証手続を当該ユーザアカウントのユーザ情報に基づいて代理するシングルサインオンサーバ用のプログラムにおいて、サーバコンピュータを、上記認証要求を受け取ったときの要求状況が所定の条件を充足する場合に上記バックエンドサーバコンピュータのアプリケーションサービスへのアクセスを制限するアクセス制限手段として機能させることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、認証要求時の要求状況が所定の条件を充足するときには、アプリケーションサービスへのアクセスを制限して、シングルサインオンによるセキュリティへの脅威を緩和できる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施例について説明する。
【００１４】
図１は、本発明の実施例のＳＳＯサーバを用いたサービス提供システムのネットワーク構成の例を示しており、図２はこのサービス提供システムの模式的な構成の例を示しており、図３は、ＳＳＯサーバ１０の機能構成の例を示している。
【００１５】
図１において、ＳＳＯ（シングルサインオン）サーバ１０、複数のクライアント（クライアント端末ともいう）２０、複数のＷＥＢサーバ３０が通信ネットワーク４０を介して接続され、サービス提供システムを構築している。サービス提供システム５０はこの実施例ではウェブサービスであるが、これに限定されない。
【００１６】
図１に示すサービス提供システム５０は模式的には図２に示すようにクライアント２０上のウェブブラウザ２０ａがＳＳＯサーバ１０を中継してＷＥＢサーバ３０からサービスを受けるようになっている。
【００１７】
図３において、ＳＳＯサーバ１０は、機能ユニットとして制御部１０１、ログイン画面生成部１０２、認証部１０３、アプリケーション用認証データ取得部１０４、認証データ保持部１０５、リクエスト転送部１０６、不正アクセス検知部、検知モジュール１０８、不正アクセス通知部１０９等を含んで構成されている。
【００１８】
ＳＳＯサーバ１０は、周知のとおり、ＣＰＵ、主メモリ、バス、補助記憶装置、各種入出力装置等のハードウェア資源、システムソフトウェア等のソフトウェア資源から構成され、ＳＳＯの機能ユニットは、これらハードウェア資源、ソフトウェア資源およびアプリケーションプログラム等を協働させて構成される。
【００１９】
制御部１０１は、各機能ユニットを制御するものであり、例えば、後述するような処理フロー（図５、図６および図８参照）を全体として制御するものである。
【００２０】
ログイン画面生成部１０２は、ＳＳＯサーバ１０のポータルのログイン画面を生成するものである。クライアント２０がＳＳＯのポータルをアクセスするとクライアント２０にログイン画面のページが供給される。ユーザはログイン画面を用いて例えばユーザ名およびパスワードを入力してサブミットする。
【００２１】
認証部１０３はユーザから入力されたユーザ名およびパスワードを用いてＳＳＯ自体のユーザ認証を行う。認証データ保持部１０５は、ＳＳＯ自体のユーザ名およびパスワードを関連付けて保持し（データベース）、認証部１０３はこのＳＳＯ自体のユーザ認証用データを用いて認証を行う。認証データ保持部１０５はＳＳＯ自体のユーザ認証用データの他に、アプリケーションごとのユーザ名およびパスワードのマップデータ（図４参照）を保持している。ＳＳＯサーバ１０は、このマップデータを用いてアプリケーションにおけるユーザ認証を代行する。
【００２２】
アプリケーション用認証データ取得部１０４は、ＳＳＯサーバ１０がアプリケーションにおけるユーザ認証を代行するときにＳＳＯのユーザ名に基づいて認証データ保持部１０５からアプリケーション用のユーザ名およびパスワードを取得するものである。
【００２３】
リクエスト転送部１０６は、クライアント２０からのリクエスト（ＨＴＴＰリクエスト）をＷＥＢサーバ３０に転送するものである。このリクエスト転送部１０６は、アプリケーションにおけるユーザ認証要求の際にアプリケーションにおけるユーザ名およびパスワードをＷＥＢサーバに送信する。ＷＥＢサーバ３０は、自らの認証用アプリケーションプログラムや外部の認証サーバを用いてユーザ認証を行う。
【００２４】
不正アクセス検知部１０７は、「不正アクセス」の可能性のあるアクセス挙動を検知するものである。「不正アクセス」の可能性のある疑わしいアクセスについては、種々の規則で判別を行える。
【００２５】
検知モジュール１０８は、種々の検知規則を実装するものである。あらかじめ複数の検知モジュールを用意しておき、どれを採用するかを設定することができる。スクリプト言語によって判定基準をプログラミングしてもよい。また、判定処理をプラガブルにすることにより、プラグインモジュールとして追加してもよい。
【００２６】
不正アクセス通知部１０９は、「不正アクセス」すなわち疑わしいアクセスを検知後、その旨をログに出力するとともに、あらかじめ設定されたユーザ（当該アカウントを持つユーザ、管理ユーザなど）に電子メールで通知するものである（メールクライアント）。
【００２７】
判定基準としては、以下のようなものが、これに限定されない。これらの判定基準は、同時に設定してもよい。
【００２８】
まず、同一アカウントを使用したログインの要求が、最初のアクセス時と異なるマシンからなされた場合に、疑わしいと判断する。
【００２９】
第２に、インターネット経由のリモートアクセスは、なりすましの可能性が高いとみなし、疑わしいと判断する。
【００３０】
また、ログインに成功するまでに、パスワードの入力ミスの回数が設定値を越える場合には、攻撃者が試行錯誤の結果、ログインに成功した可能性があり、疑わしいと判断する。
【００３１】
また、ログインに成功するまでに、複数回のパスワードの入力ミスがあり、そのミスのパターンが過去に他のアカウントに対しても試されていたことがある場合には、攻撃者が複数のアカウントに対して、次々にログインを試みている可能性があり、疑わしいと判断する。
【００３２】
また、ログインに成功するまでに、複数回のパスワードの入力ミスがあり、そのミスの中に、ユーザ名と同じパスワードを指定したものが含まれていた場合、攻撃者が、最も単純なパスワード（ユーザ名と同一）を使ってログインを試みた可能性があり、疑わしいと判断する。
【００３３】
さらに、同一端末から、一定時間の間に複数のアカウントが使用された場合、攻撃者が、複数のアカウントを次々に攻撃している可能性があるので、疑わしいと判断する。
【００３４】
また、ある端末からの最後のアクセスがあってから一定時間経過した後に、再度アクセスがあった場合、正規のユーザが離席中に、悪意のあるユーザがなりすましでアクセスしている可能性があるので、疑わしいと判断する。
【００３５】
また、通常と異なるパターンのアクセス、例えば、休日もしくは深夜・早朝にアクセスがあった場合、攻撃者が、オフィスに忍び込んで使用している可能性があるので、疑わしいと判断する。
【００３６】
また、あるユーザが、いつも使用している端末とは異なる端末からアクセスしてきた場合、アクセスしているのが正規のユーザではない可能性があるので、疑わしいと判断する。
【００３７】
つぎに実施例の動作例について説明する。ここでは、代理認証の処理をスキップしてアクセス制限を行ない場合と、登録されたアプリケーションへのアクセス拒否によりアクセス制限を行う場合について説明する。登録されたアプリケーションのアクセスについて代理認証の処理をスキップしてアクセス制限を行うようにしても良い。
【００３８】
まず、代理認証の処理をスキップしてアクセス制限を行なう場合について説明する。
□前提となる処理では、ＳＳＯサーバ１０が管理するユーザと、連携対象となる各アプリケーションのユーザのマップをＳＳＯサーバが保持しており、ＳＳＯへのログインが成功すると、アクセス先のアプリケーションの対応するユーザのユーザ名とパスワードを取得して、アプリケーションのログインフォームに自動的に埋め込んでサブミットする。
【００３９】
ユーザのマップは例えば図４に示すものである。
【００４０】
この処理は例えば図５に示すとおりであり、その内容は以下のとおりである。
【００４１】
［ステップＳ１０］：クライアント２０から、ＳＳＯサーバ１０のポータルのＵＲＬにアクセスする。
［ステップＳ１１］：ログインフォームを表示する。
［ステップＳ１２］：ユーザはユーザ名とパスワードを入力しログインボタンをクリックする。
［ステップＳ１３］：ＳＳＯサーバ１０でログイン処理を行う。
［ステップＳ１４］：ＳＳＯサーバ１０での認証に成功したらステップ１６ヘ進み、失敗したらステップＳ１５へ進む。
［ステップＳ１５］：ＳＳＯサーバ１０の認証で失敗したらエラーをユーザに表示する。エラーログをとり、また管理者にエラーをメール等で通知しても良い。
［ステップＳ１６］：ステップＳ１４の認証が成功したら、アプリケーションの一覧画面を表示する。
［ステップＳ１７］：ステップＳ１６で表示された一覧画面で、ユーザが利用したいアプリケーションを選択する。
［ステップＳ１８］：制限処理を行うかどうかを判別する。この例では、「不正なアクセス」の可能性があるかどうかだけを判別する。「不正なアクセス」がある場合には、自動的に制限処理を行うと判別する。なお、併せて、対象アプリケーションが制限対象として登録されているかどうかを判別して、両者が満たされる場合に制限処理を行うと判別しても良い。「不正なアクセス」かどうかの判別基準は先に説明したものを利用できる。制限処理でない場合にはステップＳ１９へ進み、制限処理の場合にはステップＳ２１へ進む。
［ステップＳ１９］：ユーザのマップから、ステップＳ１７で選択されたアプリケーションでの、アクセス中のユーザのユーザ名とパスワードを取得する。
［ステップＳ２０］：アプリケーションが表示するログインフォームに、ステップＳ１７で取得したユーザ名とパスワードを自動的に埋め込んでサブミットする。
［ステップＳ２１］：選択されたアプリケーションのログインフォームをそのまま表示して、ユーザにユーザ名とパスワードの入力をさせる。エラーログを残し、管理者等にエラーをメールで通知しても良い。
【００４２】
つぎに、登録されたアプリケーションへのアクセス拒否によりアクセス制限を行う場合について説明する。
□前提として、疑わしいアクセスの場合に利用不可としたいアプリケーションのＵＲＬのリストを、あらかじめ登録しておく。
【００４３】
この場合の処理の例を図６に示す。なお、図６において図５と対応する箇所には対応する符号を付した。
【００４４】
図６の処理は以下のとおりである。
【００４５】
［ステップＳ１０］：クライアント２０から、ＳＳＯサーバ１０のポータルのＵＲＬにアクセスする。
［ステップＳ１１］：ログインフォームを表示する。
［ステップＳ１２］：ユーザはユーザ名とパスワードを入力しログインボタンをクリックする。
［ステップＳ１３］：ＳＳＯサーバ１０でログイン処理を行う。
［ステップＳ１４］：ＳＳＯサーバ１０での認証に成功したらステップ１６ヘ進み、失敗したらステップＳ１５へ進む。
［ステップＳ１５］：ＳＳＯサーバ１０の認証で失敗したらエラーをユーザに表示する。エラーログをとり、また管理者にエラーをメール等で通知しても良い。
［ステップＳ１６］：ステップＳ１４の認証が成功したら、アプリケーションの一覧画面を表示する。
［ステップＳ１７］：ステップＳ１６で表示された一覧画面で、ユーザが利用したいアプリケーションを選択する。
［ステップＳ１８］：「不正なアクセス」の可能性があり、かつ対象アプリケーションが制限対象として登録されているかどうかを判別する。両者が満たされる場合に制限処理を行うと判別する。「不正なアクセス」かどうかの判別基準は先に説明したものを利用できる。制限処理でない場合にはステップＳ１９へ進み、制限処理の場合にはステップＳ２３へ進む。
［ステップＳ１９］：ユーザのマップから、ステップＳ１７で選択されたアプリケーションでの、アクセス中のユーザのユーザ名とパスワードを取得する。
［ステップＳ２０］：アプリケーションが表示するログインフォームに、ステップＳ１７で取得したユーザ名とパスワードを自動的に埋め込んでサブミットする。
［ステップＳ２３］：アクセスを拒否してエラーを表示する。エラーログを残し、管理者等にエラーをメールで通知しても良い。
【００４６】
なお、ステップＳ１７で一覧を表示する際に、利用不可としたいＵＲＬを除外して表示してもよい。この場合、「不正なアクセス」かどうかをステップＳ１７よりまえに判別しておく必要がある。
【００４７】
この実施例によれば、不正な手段でパスワードを取得した攻撃者からのアクセスによる被害を最小限に抑えることができる。疑わしいと判断されたアクセスが、正規のユーザからのものであった場合でも、若干の利便性を損ねるだけであって、システムの利用に支障をきたすことがないようにする運用も可能となる。また、判定基準の種類によっては、正規のユーザからのアクセスが疑わしいと判断されたことにより、当該アカウントが何らかの攻撃を受けていると思われるケースがあるため、そのことを事前にユーザに周知しておくことにより、攻撃者による不正アクセスの早期検出を促進することができる。疑わしいと判断された後に、バックエンドのアプリケーションで認証を行う場合であっても、ＳＳＯサーバを経由するため、ログを１箇所にまとめて出力できるため、監査の観点からも好ましい。
【００４８】
つぎに上述の実施例を、アクセスチケットを用いるＳＳＯ技術に適用した変形例について説明する。
【００４９】
この変形例では、前提として、ユーザごとに利用可能なアプリケーションをあらかじめ定義しておく。この定義は例えば図７に示すようなテーブルを用いる。また、疑わしいアクセスの場合に利用不可としたいアプリケーションのＵＲＬのリストを、あらかじめ登録しておく。これはユーザごとに登録しても良いし、グループ、またはシステム全体の定義として登録しても良い。
【００５０】
図８はこの変形例の処理を示しており、この図において図６と対応する箇所には対応する符号を付した。この例ではステップＳ１６Ａにおいて、ユーザの利用可能なアプリケーションの一覧画面を図７のテーブルを参照して表示する点が図６の処理と異なる。ステップＳ１７Ａで一覧を表示する際に、利用不可としたいＵＲＬを除外して表示してもよい。
【００５１】
なお、本発明は特許請求の範囲の記載に基づいて決定されるものであり、実施例の具体的な構成、課題、および効果には限定されない。本発明は上述の実施例に限定されるものではなくその趣旨を逸脱しない範囲で種々変更が可能である。
【図面の簡単な説明】
【００５２】
【図１】本発明の実施例のネットワーク構成を説明するブロック図である。
【図２】本発明の実施例を模式的に説明するブロック図である。
【図３】本発明の実施例のＳＳＯサーバの構成を説明するブロック図である。
【図４】本発明の実施例で用いるマップデータを説明する図である。
【図５】本発明の実施例の動作例を説明するフローチャートである。
【図６】本発明の実施例の他の動作例を説明するフローチャートである。
【図７】本発明の実施例の変形例を説明する図である。
【図８】上述変形例の動作例を説明するフローチャートである。
【符号の説明】
【００５３】
１０    ＳＳＯサーバ
２０    クライアント
２０ａ    ウェブブラウザ
３０    ＷＥＢサーバ
４０    通信ネットワーク
５０    サービス提供システム
１０１    制御部
１０２    ログイン画面生成部
１０３    認証部
１０４    アプリケーション用認証データ取得部
１０５    認証データ保持部
１０６    リクエスト転送部
１０７    不正アクセス検知部
１０８    検知モジュール
１０９    不正アクセス通知部
【図１】
2009003559.tif 000003
【図２】
2009003559.tif 000004
【図３】
2009003559.tif 000005
【図４】
2009003559.tif 000006
【図７】
2009003559.tif 000007
【図５】
2009003559.tif 000008
【図６】
2009003559.tif 000009
【図８】
2009003559.tif 000010