JP6572750B2 - 認証制御プログラム、認証制御装置、及び認証制御方法 - Google Patents

Description

本発明は、認証制御プログラム、認証制御装置、及び認証制御方法に関する。

企業内の業務システムを新たにモバイル端末から活用することで、ワークスタイル変革を行うニーズがある。このような場合、社外のモバイル端末からの企業内の業務システムへの新たなアクセス経路を用意することになる。

今まで社内の閉じた環境、すなわち安全なネットワーク内で利用されていた業務システムに、新たにインターネット等の外部に公開されたネットワークからアクセスされる経路を設けることで、社外の攻撃者からの攻撃に遭うリスクが増える。その結果、業務システムの情報が露出されるリスクが高くなってしまう。

国際公開第２００９／００１４４７号

モバイル端末と外部に非公開の業務システムとの間に、利用者認証やアクセスログ採取等の機能を有する中間サーバを配置し、中間サーバを経由しないと業務システムへアクセスできない構成を導入することで、上記の業務システムを保護する方法が考えられる。

しかしながら、その中間サーバはインターネット等のネットワーク上で公開され、外部の攻撃者から不正なアクセスを受ける可能性があるため、不正なアクセスに対する考慮が必要となる。

例えば、攻撃者が不正なアクセスをして、そのアクセスが業務システム側の認証機構で許可されない場合、アクセス元にエラー情報が返信される。しかしながら、例えば、エラー情報にセキュリティに関して攻撃者を利するような情報が含まれている場合、攻撃者はその情報を手がかりに認証機構を通過してしまうおそれがある。このように、不正なアクセスに対し認証機構がエラー情報を送信して、アクセスを拒否したとしても、エラー情報に含まれる情報を用いて、攻撃者がさらなる攻撃を実行するおそれがある。

本発明の一側面では、不正なアクセスに対するレスポンスにおいて攻撃者を利する情報の提供を抑止することを目的とする。

本発明の一態様では、コンピュータに、以下の処理を実行させる。すなわち、コンピュータは、アプリケーションソフトウェアの機能またはデータを呼び出すインターフェースの利用を要求するリクエスト情報を受信した際に、第１の判定処理と第２の判定処理とを実行する。第１の判定処理は、リクエスト情報に含まれるインターフェースの識別情報に基づいてリクエスト情報の正当性を判定する処理である。第２の判定処理は、リクエスト情報に含まれるインターフェースについてのキー情報または認証トークン情報の少なくとも１つに基づいてリクエスト情報の正当性を判定する処理である。キー情報は、インターフェースの利用申請に対して申請したユーザのインターフェースの利用を許可する情報である。認証トークン情報は、ユーザの正当性を判定する情報である。コンピュータは、第２の判定処理の結果、リクエスト情報が正当でないと判定された場合、第１の判定処理の結果によらず、リクエスト情報の送信元に対してアクセスが許容されない旨を示すエラー情報を送信する。

本発明の一側面によれば、不正なアクセスに対するレスポンスにおいて攻撃者を利する情報の提供を抑止することができる。

中間サーバを介して、クライアント端末と業務サーバとが通信を行う業務システムにおけるクライアント端末から業務サーバへのアクセスのシーケンスを示す。 本実施形態における認証制御装置の一例を示す。 本実施形態におけるネットワーク構成の一例を示す。 本実施形態における中間サーバの一例を示す。 本実施形態におけるクライアント端末から送信されるリクエスト情報の一例を示す。 本実施形態におけるＳ１１及びＳ１２の検証処理のフロー（その１）を示す。 本実施形態におけるＳ１１及びＳ１２の検証処理のフロー（その２）を示す。 本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。

不正なアクセスに対する考慮が必要となる例としては、例えば、以下のことが考えられる。

図１は、中間サーバを介して、クライアント端末と業務サーバとが通信を行う業務システムにおけるクライアント端末から業務サーバへのアクセスのシーケンスを示す。

図１の業務システムでは、クライアント端末１０１で利用できる業務サーバ１０３と通信可能なアプリケーションプログラムについて予め登録されたＡＰＩ（Application Program Interface）しか利用することができない仕組みであるとする。

この場合、クライアント端末１０１のユーザ（例えば、呼び出し元プログラムの開発者）が、ＡＰＩ管理者に対して、事前に、利用するＡＰＩの利用申請をする必要がある。すると、ＡＰＩ管理者は、そのＡＰＩについての定義（ＡＰＩ定義）を、例えば中間サーバ１０２の記憶装置に登録する。

さらに、ＡＰＩ管理者は、ＡＰＩキーと、そのＡＰＩを利用する際のそのＡＰＩの参照先を示すＵＲＬ（Uniform Resource Locator）を、クライアント端末１０１のユーザに対して発行する。ＡＰＩキーとは、呼び出し元プログラムが、登録したＡＰＩ定義に対応するＡＰＩを利用する利用権限を有していることを示す鍵情報である。

クライアント端末１０１でそのＡＰＩを利用する場合であって、ＡＰＩ定義においてＡＰＩキーの指定が要求されている場合には、図１に示すように、クライアン端末１０１は、中間サーバ１０２に、そのＡＰＩキーと、そのＵＲＬとを送る必要がある。

図１では、クライアント端末１０１対して、利用するアプリケーションプログラム（以下、「アプリケーション」と称する）のＡＰＩキーと、そのＵＲＬとは既に発行されているものとする。

まず、クライアント端末１０１から業務サーバ１０３へのリクエスト情報の送信（すなわち、リクエスト）の際、クライアント端末１０１は、中間サーバ１０２に対して、認証トークンの発行を要求する（Ｓ１）。すると、中間サーバ１０２は、クライアント端末１０１に対して、認証トークンを発行する（Ｓ２）。認証トークンは、ユーザの正当性を判定するための情報である。本実施形態において、認証トークンとは、コンピュータサービスの利用権限のある利用者を判定するための情報であって、サーバ側での認証処理において、アクセスしたユーザが予め利用権限が与えられた正当なユーザかを判定するための情報である。

クライアント端末１０１は、業務サーバ１０３にアクセスするために中間サーバ１０２に対してリクエスト情報（以下、「リクエスト」と称する）を送信する（Ｓ１３）。このリクエストは、例えば、ＨＴＴＰ（Hypertext Transfer Protocol）リクエストメッセージであり、クライアント端末１０１において予め保持しているＡＰＩキー及びＵＲＬと、Ｓ２で取得した認証トークンを含む。

中間サーバ１０２は、クライアント端末１０１からリクエストを取得すると、リクエストに含まれるＡＰＩキー、認証トークン、ＵＲＬを抽出する。中間サーバ１０２は、ＡＰＩキー、認証トークン、ＵＲＬに基づいて、ユーザの正当性の検証と、要求されたＡＰＩの正当性の検証を行う（Ｓ４）。

要求されたＡＰＩの正当性の検証では、ＡＰＩ定義１０４に基づいて、リクエストに含まれるＡＰＩキーが正当であるかの確認と、ＵＲＬ内にて指定されたＡＰＩ名が存在するかの確認が行われる。

ユーザの正当性の検証とＡＰＩの正当性の検証に成功した場合（Ｓ５で「ＹＥＳ」）、中間サーバ１０２は、暗号化通信により、クライアント端末１０１からのリクエストに基づいて、業務サーバ３へアクセスする（Ｓ６）。

ユーザの正当性の検証とＡＰＩの正当性の検証に失敗した場合（Ｓ５で「ＮＯ」）、中間サーバ１０２は、クライアント端末１０１にエラー通知を行う（Ｓ７）。このとき、リクエストで指定されているＡＰＩキーが正当でないかまたはＡＰＩキーが指定されていない場合において、ＵＲＬで指定されたＡＰＩ名が存在しない場合、中間サーバ１０２は、ＡＰＩ定義取得失敗エラーをクライアント端末１０１に通知する。

このように、不用意なレスポンスとして、ＡＰＩ定義取得失敗エラーを返した場合、攻撃者に対し、指定したＡＰＩ名が「正しい」「正しくない」という情報を返してしまうことになる。そのような情報が攻撃者側で蓄積されると、セキュリティ面にて懸念が生じることになる。

そこで、本実施形態では、中間サーバへの不正アクセスに対し、不用意なレスポンスを返さない仕組みを導入する。これにより、業務サーバのクライアント端末の活用における中間サーバ１０２への不正アクセスに対し、攻撃者を利する情報の露出を抑えることができる。

図２は、本実施形態における認証制御装置の一例を示す。認証制御装置１は、判定実行部２と、送信部３とを含む。

判定実行部２は、アプリケーションソフトウェアの機能またはデータを呼び出すインターフェースの利用を要求するリクエスト情報を受信した際に、第１の判定処理と第２の判定処理とを実行する。判定実行部２の一例として、後述する制御部２２が挙げられる。

第１の判定処理では、判定実行部２は、リクエスト情報に含まれるインターフェースの識別情報に基づいてリクエスト情報の正当性を判定する。第１の判定処理の一例として、後述するＳ２２の処理が挙げられる。

第２の判定処理では、判定実行部２は、リクエスト情報に含まれるインターフェースについてのキー情報または認証トークン情報の少なくとも１つに基づいてリクエスト情報の正当性を判定する。キー情報は、インターフェースの利用申請に対して申請したユーザのインターフェースの利用を許可する情報である。認証トークン情報は、ユーザの正当性を判定する情報である。第２の判定処理の一例として、後述するＳ２５、Ｓ２８の処理が挙げられる。

送信部３は、第２の判定処理の結果、リクエスト情報が正当でないと判定された場合、第１の判定処理の結果によらず、リクエスト情報の送信元に対してアクセスが許容されない旨を示すエラー情報を送信する。エラー情報は、エラーの原因を特定する情報を含まず、アクセスが許容されないことのみを通知する情報である。送信部２の一例として、後述する制御部２２によるＳ３７，Ｓ３８の処理が挙げられる。

このように構成することにより、不正なアクセスに対するレスポンスにおいて攻撃者を利する情報の提供を抑止することができる。

以下では、本実施形態について、さらに詳述する。
図３は、本実施形態におけるネットワーク構成の一例を示す。インターネット等の公開されたネットワーク１４，１４’に、クライアント端末１１、中間サーバ１２、及び業務サーバ１３が接続されている。なお、ネットワーク１４，１４’は、同一のネットワークであるが説明の便宜上分けてある。

業務サーバ１３は、企業内で利用されるサーバ（またはサーバシステム）である。業務サーバ１３は、ネットワーク１４’に接続に接続されている。しかしながら、業務サーバ１３は、業務サーバ１３を除いて、ネットワーク１４’から直接アクセスすることができない。すなわち、業務サーバ１３は、後述するように、中間サーバ１２を介してのみ、外部よりアクセスすることができる。

クライアント端末１１は、例えば、その企業に属するユーザが利用する情報通信端末であり、ネットワークを介して通信することができる。なお、情報通信端末は、無線または有線によりネットワーク１４と接続されてもよい。

中間サーバ１２は、論理的に、クライアント端末１１と業務サーバ１３との間の通信経路に設けられ、ユーザの認証やアクセスログ採取等の機能を有するゲートウェイサーバである。中間サーバ１２と業務サーバ１３との間では、暗号化通信１５が行われる。

また、本実施形態では、図１で説明したように、クライアント端末１１で利用できる業務サーバ１３と通信可能なアプリケーションプログラムについて予め登録されたＡＰＩ（Application Program Interface）しか利用することができない仕組みであるとする。

また、本実施形態では、クライアント端末１１対して、利用するアプリケーションのＡＰＩキーと、そのＵＲＬとは既に発行されているものとする。

図４は、本実施形態における中間サーバの一例を示す。中間サーバ１２は、通信インターフェース（I／Ｆ）２１、制御部２２、記憶部２３を含む。

クライアント端末１１は、リクエストを中間サーバ１２に送信する。リクエストは、ＡＰＩキー、認証トークン、ＵＲＬについての情報を含む。

通信Ｉ／Ｆ２１は、ネットワーク１４と接続するためのインターフェースである。通信Ｉ／Ｆ２１は、クライアント端末１１から送信されたリクエストを取得したり、クライアント端末１１へレスポンスを送信する。

記憶部２３は、ＡＰＩ定義２４を格納する。ＡＰＩ定義２４は、上述したようにＡＰＩ利用申請に応じて事前に登録された各ＡＰＩに対応する定義についての情報である。

制御部２２は、中間サーバ１２の動作全体を制御するプロセッサである。制御部２２は、ＡＰＩキー検証処理（Ｓ１１）、認証トークンの検証処理（Ｓ１２）を実行する。

ＡＰＩキー検証処理（Ｓ１１）では、制御部２２は、クライアント端末１１から送信されたリクエストに含まれるＡＰＩキーが有効なものかの検証を行う。ＡＰＩ定義においてＡＰＩキーの検証を行う設定となっている場合、および、ＡＰＩ定義を取得できない場合は、制御部２２は、Ｓ１１の検証を行う。ＡＰＩ定義においてＡＰＩキーの検証を行わない設定である場合、制御部２２は、認証トークンの検証処理（Ｓ１２）を行う。

なお、ＡＰＩ定義を取得できなかった場合に検証を行うのは以下の理由のためである。
・ＡＰＩ定義が取得できない場合であっても、ＡＰＩキーがリクエストに設定されている可能性があるため。
・ＡＰＩキーの検証エラー時には、ＵＲＩ（Uniform Resource Identifier）保護の観点から、ＡＰＩ定義取得失敗エラーではなく、認可エラーとする必要があるため。

制御部２２は、ＡＰＩキーの検証を行う場合、ＡＰＩのリクエストがあった場合（ＡＰＩ呼び出し時）に、リクエストにＡＰＩキーが設定されているかの確認処理と、設定されたＡＰＩキーが正常であるかの確認を行う。

認証トークンの検証処理（Ｓ１２）では、クライアント端末１１から送信されたリクエストに含まれる認証トークンが有効であるか、認証サーバ（不図示）に問い合わせて検証を行う。なお、認証サーバは、中間サーバ１２に含まれていてもよいし、外部のサーバであってもよい。

ＡＰＩ定義２４において認証トークンの検証を行う設定となっている場合、および、ＡＰＩ定義２４を取得できなかった場合は、制御部２２は、Ｓ１２の検証を行う。

なお、ＡＰＩ定義２４を取得できなかった場合に検証を行うのは以下の理由のためである。
・ＡＰＩ定義が取得できない場合であっても、認証トークンがリクエストに設定されている可能性があるため。
・認証トークンの検証エラー時には、ＵＲＩ保護の観点から、ＡＰＩ定義取得失敗エラーではなく、認証エラーとする必要があるため。

認証トークンの検証を行う設定の場合、制御部２２は、ＡＰＩのリクエストがあった場合（ＡＰＩ呼び出し時）に、リクエストに認証トークンが設定されているかの確認処理と、認証トークンの検証とユーザ情報の確認処理とを行う。

制御部２２は、Ｓ１１とＳ１２の検証処理が成功した場合、暗号化通信により、クライアント端末１１からのリクエストに基づいて、業務サーバ１３へアクセスする。

図５は、本実施形態におけるクライアント端末から送信されるリクエスト情報の一例を示す。図５では、ＨＴＴＰリクエストメッセージを例に説明する。

図５（Ａ）は、クライアント端末１１から送信されるリクエストに含まれるＵＲＬの形式例を示す。ここで、“<tenantkey>”は、マルチテナント環境において、各テナント（例えば、企業ユーザ等）を識別する情報である。“<apiname>”は、ＡＰＩ名である。“<resource>”は、参照先の所在を示す情報である。なお、ＦＱＤＮは、Fully Qualified Domain Nameの略称である。

中間サーバ１２の処理では、上記のＵＲＬフォーマットのうち、<apiname>に該当する部分からＡＰＩ名を取得する。

図５（Ｂ）は、クライアント端末１１から送信されるリクエストに含まれるヘッダ情報（リクエストヘッダ）を示す。

ＡＰＩキーは、制御部２２により、例えば、リクエストヘッダに含まれる項目「X- API-Key」から取得される。ＡＰＩキーは、業務サーバ１３の利用に際して事前に申請して発行された一意の情報である。例えば、業務サーバの呼び出し元プログラムの開発者は、事前にＡＰＩ管理ポータルサーバからＡＰＩキーを取得し、呼び出し元プログラムに組み込む。例えば、ＡＰＩ定義にてＡＰＩキーの検証を行う定義がされている場合、リクエストヘッダにはＡＰＩキーが指定されている必要がある。

認証トークンは、制御部２２により、例えば、リクエストヘッダに含まれる項目「X-Token」から取得される。認証トークンは、ユーザ認証に用いる一意の情報である。認証トークンは、ＡＰＩを呼び出す前に認証サーバにログインして取得される。例えば、ＡＰＩ定義にて認証トークンの検証を行う定義がされている場合、リクエストヘッダには認証トークンが指定されている必要がある。

図６Ａ及び図６Ｂは、本実施形態におけるＳ１１及びＳ１２の検証処理のフローを示す。クライアント端末１１からリクエストを受信すると、制御部２２は、以下の処理を行う。

まず、制御部２２は、受信したリクエストからＵＲＬを抽出し、ＵＲＬからＡＰＩ名に相当する部分を取り出す。また、制御部２２は、受信したリクエストのリクエストヘッダから、ＡＰＩキーに相当する部分と認証トークンに相当する部分を取り出す（Ｓ２１）。

制御部２２は、取り出したＡＰＩ名に基づいて、ＵＲＬにて指定されたＡＰＩ名に対応するＡＰＩ定義が存在するかを判定する（Ｓ２２）。

ＵＲＬにて指定されたＡＰＩ名に対応するＡＰＩ定義が存在する場合（Ｓ２２で「ＹＥＳ」）、制御部２２は、ＡＰＩ定義において、ＡＰＩキーを検証するように設定されているかを判定する（Ｓ２３）。

ＡＰＩ定義において、ＡＰＩキーを検証するように設定されていない場合（Ｓ２３で「ＮＯ」）、制御部２２は、Ｓ２６の処理を行う。ＡＰＩ定義において、ＡＰＩキーを検証するように設定されている場合（Ｓ２３で「ＹＥＳ」）、制御部２２は、リクエストヘッダにＡＰＩキーが指定されているかを判定する（Ｓ２４）。制御部２２は、Ｓ２１においてＡＰＩキーに相当する部分を取り出している場合、リクエストヘッダにＡＰＩキーが指定されていると判定する。

リクエストヘッダにＡＰＩキーが指定されていない場合（Ｓ２４で「ＮＯ」）、制御部２２は、クライアント端末１１に対して、認可エラー（４０３）を応答する（Ｓ３８）。

リクエストヘッダにＡＰＩキーが指定されている場合（Ｓ２４で「ＹＥＳ」）、制御部２２は、指定されたＡＰＩキーが正しいかを判定する（Ｓ２５）。ここでは、制御部２２は、指定されたＡＰＩキーをキーとして管理ＤＢからＡＰＩキー情報が取得できた場合に、ＵＲＬに設定されている”<tenantkey>/<apiname>”とその取得したＡＰＩキー情報の”<tenantkey>/<apiname>”とが一致するかを判定する。ＵＲＬに設定されている”<tenantkey>/<apiname>”とその取得したＡＰＩキー情報の”<tenantkey>/<apiname>”とが一致する場合、制御部２２は、指定されたＡＰＩキーが正しいと判定する。

なお、管理ＤＢとは、ユーザに発行したＡＰＩキーを管理するデータベースであり、中間サーバ１２の記憶装置２３または外部のサーバに格納されている。

指定されたＡＰＩキーが正しい場合（Ｓ２５で「ＹＥＳ」）、制御部２２は、Ｓ２６の処理を行う。指定されたＡＰＩキーが正しくない場合（Ｓ２５で「ＮＯ」）、制御部２２は、クライアント端末１１に対して、認可エラー（４０３）を応答する（Ｓ３８）。

Ｓ２５で「ＹＥＳ」またはＳ２３で「ＮＯ」の場合、制御部２２は、ＡＰＩ定義において、認証トークンを検証するように設定されているかを判定する（Ｓ２６）。ＡＰＩ定義において、認証トークンを検証するように設定されていない場合（Ｓ２３で「ＮＯ」）、制御部２２は、Ｓ２９の処理を行う。

ＡＰＩ定義において、ＡＰＩキーを検証するように設定されている場合（Ｓ２６で「ＹＥＳ」）、制御部２２は、リクエストヘッダに認証トークンが指定されているかを判定する（Ｓ２７）。制御部２２は、Ｓ２１において認証トークンに相当する部分を取り出している場合、リクエストヘッダに認証トークンが指定されていると判定する。

リクエストヘッダに認証トークンが指定されていない場合（Ｓ２７で「ＮＯ」）、制御部２２は、クライアント端末１１に対して、認証エラー（４０１）を応答する（Ｓ３７）。

リクエストヘッダに認証トークンが指定されている場合（Ｓ２７で「ＹＥＳ」）、制御部２２は、認証サーバに問い合わせて、指定された認証トークンが正しいか否かを判定する（Ｓ２８）。

指定された認証トークンが正しくない場合（Ｓ２８で「ＮＯ」）、制御部２２は、クライアント端末１１に対して、認証エラー（４０１）を応答する（Ｓ３７）。指定された認証トークンが正しい場合（Ｓ２８で「ＹＥＳ」）、制御部２２は、業務サーバを呼び出す（Ｓ２９）。業務サーバは、その呼び出しに応じて、ステータスコードを返却する（Ｓ３０）。

Ｓ２２において、ＵＲＬにて指定されたＡＰＩ名に対応するＡＰＩ定義が存在しない場合（Ｓ２２で「ＮＯ」）、制御部２２は、リクエストヘッダにＡＰＩキーが指定されているかを判定する（Ｓ３１）。制御部２２は、Ｓ２１においてＡＰＩキーに相当する部分を取り出している場合、リクエストヘッダにＡＰＩキーが指定されていると判定する。

リクエストヘッダにＡＰＩキーが指定されていない場合（Ｓ３１で「ＮＯ」）、制御部２２は、リクエストヘッダに認証トークンが指定されているかを判定する（Ｓ３５）。制御部２２は、Ｓ２１において認証トークンに相当する部分を取り出している場合、リクエストヘッダに認証トークンが指定されていると判定する。

リクエストヘッダに認証トークンが指定されていない場合（Ｓ３５で「ＮＯ」）、制御部２２は、クライアント端末１１に対して、認可エラー（４０３）を応答する（Ｓ３８）。

リクエストヘッダに認証トークンが指定されている場合（Ｓ３５で「ＹＥＳ」）、制御部２２は、認証サーバに問い合わせて、指定された認証トークンが正しいか否かを判定する（Ｓ３６）。

指定された認証トークンが正しくない場合（Ｓ３６で「ＮＯ」）、制御部２２は、クライアント端末１１に対して、認証エラー（４０１）を応答する（Ｓ３７）。指定された認証トークンが正しい場合（Ｓ３６で「ＹＥＳ」）、制御部２２は、クライアント端末１１に対してＡＰＩ定義取得失敗エラー（４０４）を応答する（Ｓ３４）。このように、ＡＰＩキーや認証トークンが正しい場合のみ、制御部２２は、クライアント端末１１に対して、エラーの原因を示す詳細なエラー情報を応答する。

Ｓ３１において、リクエストヘッダにＡＰＩキーが指定されている場合（Ｓ３１で「ＹＥＳ」）、制御部２２は、指定されたＡＰＩキーが管理ＤＢに存在するかを判定する（Ｓ３２）。

指定されたＡＰＩキーが管理ＤＢに存在しない場合（Ｓ３２で「ＮＯ」）、制御部２２は、クライアント端末１１に対して、認可エラー（４０３）を応答する（Ｓ３８）。

指定されたＡＰＩキーが管理ＤＢに存在する場合（Ｓ３２で「ＹＥＳ」）、制御部２２は、リクエストヘッダに認証トークンが指定されているかを判定する（Ｓ３３）。制御部２２は、Ｓ２１において認証トークンに相当する部分を取り出している場合、リクエストヘッダに認証トークンが指定されていると判定する。

リクエストヘッダに認証トークンが指定されていない場合（Ｓ３３で「ＮＯ」）、制御部２２は、クライアント端末１１に対してＡＰＩ定義取得失敗エラー（４０４）を応答する（Ｓ３４）。このように、ＡＰＩキーや認証トークンが正しい場合のみ、制御部２２は、クライアント端末１１に対して、エラーの原因を示す詳細なエラー情報を応答する。

リクエストヘッダに認証トークンが指定されている場合（Ｓ３３で「ＹＥＳ」）、制御部２２は、クライアント端末１１に対して、認可エラー（４０３）を応答する（Ｓ３８）。

Ｓ３７，Ｓ３８において、仮に、不用意なレスポンスとして、「ＡＰＩ定義取得失敗エラー」を返した場合、攻撃者に対し、指定したＡＰＩ名が正しい／正しくないの情報を返してしまうことになる。それに対し、本実施形態のレスポンスでは、認可エラーあるいは認証エラーを返すため、指定したＡＰＩ名が正しいかどうかの情報を攻撃者に提供することを抑止することができる。

なお、Ｓ３４では、ＡＰＩキーが正しいことを確認できているので、エラーの原因を示す適切なエラーを返す。

図７は、本実施形態におけるプログラムを実行するコンピュータのハードウェア環境の構成ブロック図の一例である。コンピュータ３０は、中継サーバ１２として機能する。コンピュータ３０は、ＣＰＵ３２、ＲＯＭ３３、ＲＡＭ３６、通信Ｉ／Ｆ３４、記憶装置３７、出力Ｉ／Ｆ３１、入力Ｉ／Ｆ３５、読取装置３８、バス３９、出力装置４１、入力装置４２によって構成されている。

ここで、ＣＰＵは、中央演算装置を示す。ＲＯＭは、リードオンリメモリを示す。ＲＡＭは、ランダムアクセスメモリを示す。Ｉ／Ｆは、インターフェースを示す。バス３９には、ＣＰＵ３２、ＲＯＭ３３、ＲＡＭ３６、通信Ｉ／Ｆ３４、記憶装置３７、出力Ｉ／Ｆ３１、入力Ｉ／Ｆ３５、及び読取装置３８が接続されている。読取装置３８は、可搬型記録媒体を読み出す装置である。出力装置４１は、出力Ｉ／Ｆ３１に接続されている。入力装置４２は、入力Ｉ／Ｆ３５に接続されている。

記憶装置３７としては、ハードディスク、フラッシュメモリカードなど様々な形式の記憶装置を使用することができる。記憶装置３７またはＲＯＭ３３には、ＣＰＵ３２を判定実行部２、送信部３として機能させる本実施形態に係るプログラムが格納されている。

ＣＰＵ３２は、制御部２２として、記憶装置３７またはＲＯＭ３３から本実施形態に係るプログラムを読み出し、当該プログラムを実行する。

通信Ｉ／Ｆ３４は、ネットワークと接続して他の装置と通信するためのポート等のインターフェースである。

上記実施形態で説明した処理を実現するプログラムは、プログラム提供者側から通信ネットワーク７０、および通信Ｉ／Ｆ３４を介して、例えば記憶装置３７に格納されてもよい。また、上記実施形態で説明した処理を実現するプログラムは、市販され、流通している可搬型記憶媒体に格納されていてもよい。この場合、この可搬型記憶媒体は読取装置３８にセットされて、ＣＰＵ３２によってそのプログラムが読み出されて、実行されてもよい。可搬型記憶媒体としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＩＣカード、ＵＳＢメモリ装置、半導体メモリカードなど様々な形式の記憶媒体を使用することができる。このような記憶媒体に格納されたプログラムが読取装置３８によって読み取られる。

入力装置４２には、キーボード、マウス、電子カメラ、ウェブカメラ、マイク、スキャナ、センサ、タブレット、タッチパネルなどを用いることが可能である。また、出力装置４１には、ディスプレイ、プリンタ、スピーカなどを用いることが可能である。

ネットワーク４０は、インターネット、ＬＡＮ、ＷＡＮ、専用線、有線、無線等の通信網であってよい。

本実施形態によれば、中間サーバ１２への不正なアクセスに対し、不用意なレスポンス情報を返さないようにすることができる。その結果、不正なアクセスを行う攻撃者へ、不正アクセスを有利にする情報の露出を抑えることができる。

なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。

１ 認証制御装置
２ 判定実行部
３ 送信部
１１ クライアント端末
１２ 中間サーバ
１３ 業務サーバ１３
１４，１４’ インターネット
１５ 暗号化通信
２１ 通信Ｉ／Ｆ
２２ 制御部
２３ 記憶部
２４ ＡＰＩ定義

Claims (4)

1. コンピュータに、
   アプリケーションソフトウェアの機能またはデータを呼び出すインターフェースの利用を要求するリクエスト情報を受信した際に、該リクエスト情報に含まれる該インターフェースの識別情報に基づいて前記リクエスト情報の正当性を判定する第１の判定処理と、該リクエスト情報に含まれるインターフェースについてのキー情報または認証トークン情報であって該インターフェースの利用申請に対して申請したユーザの該インターフェースの利用を許可する該キー情報または該ユーザの正当性を判定する該認証トークン情報の少なくとも１つに基づいて前記リクエスト情報の正当性を判定する第２の判定処理と、を実行し、
   前記第２の判定処理の結果、前記リクエスト情報が正当でないと判定された場合、前記第１の判定処理の結果によらず、前記リクエスト情報の送信元に対してアクセスが許容されない旨を示すエラー情報を送信する、
   処理を実行させることを特徴とする認証制御プログラム。
2. 前記エラー情報は、エラーの原因を特定する情報を含まず、前記アクセスが許容されないことのみを通知する情報である
   ことを特徴とする請求項１に記載の認証制御プログラム。
3. アプリケーションソフトウェアの機能またはデータを呼び出すインターフェースの利用を要求するリクエスト情報を受信した際に、該リクエスト情報に含まれる該インターフェースの識別情報に基づいて前記リクエスト情報の正当性を判定する第１の判定処理と、該リクエスト情報に含まれるインターフェースについてのキー情報または認証トークン情報であって該インターフェースの利用申請に対して申請したユーザの該インターフェースの利用を許可する該キー情報または該ユーザの正当性を判定する該認証トークン情報の少なくとも１つに基づいて前記リクエスト情報の正当性を判定する第２の判定処理と、を実行する判定実行部と、
   前記第２の判定処理の結果、前記リクエスト情報が正当でないと判定された場合、前記第１の判定処理の結果によらず、前記リクエスト情報の送信元に対してアクセスが許容されない旨を示すエラー情報を送信する送信部と、
   を備えることを特徴とする認証制御装置。
4. コンピュータが、
   アプリケーションソフトウェアの機能またはデータを呼び出すインターフェースの利用を要求するリクエスト情報を受信した際に、該リクエスト情報に含まれる該インターフェースの識別情報に基づいて前記リクエスト情報の正当性を判定する第１の判定処理と、該リクエスト情報に含まれるインターフェースについてのキー情報または認証トークン情報であって該インターフェースの利用申請に対して申請したユーザの該インターフェースの利用を許可する該キー情報または該ユーザの正当性を判定する該認証トークン情報の少なくとも１つに基づいて前記リクエスト情報の正当性を判定する第２の判定処理と、を実行し、
   前記第２の判定処理の結果、前記リクエスト情報が正当でないと判定された場合、前記第１の判定処理の結果によらず、前記リクエスト情報の送信元に対してアクセスが許容されない旨を示すエラー情報を送信する、
   処理を実行させることを特徴とする認証制御方法。

Images