〔第1の実施形態〕
以下、図面を参照して本発明の実施形態を詳細に説明する。
図1は、本発明の実施形態における認証システム100の構成の一例を示す図である。
本発明においては、クラウドセキュリティ認証局004のような組織が設置されると仮定する。クラウドセキュリティ認証局004は、API提供業の認証を人的に確認し、クラウドセキュリティ認証局の公開鍵141の発効と、その認証サービスの提供を行う。
情報処理装置101は、Webサービス利用者001が利用する端末であり、インターネットに繋がった端末である。
SaaSサーバ102は、WebAPI利用者002(つまり、Webサービス(SaaS)提供者)が、Webサービス利用者001に対して、Webサービスを提供するサーバである。本実施形態において、Webサービスとは、Web上で提供されるアプリケーションのことを意味し、SaaSサーバ102は、いわゆるアプリケーションサーバである。
WebAPIサーバ103は、WebAPI提供者003が、WebAPI利用者002に対して、WebAPIを提供するサーバであり、公開鍵暗号方式を使って、クラウドセキュリティ認証局004の証明を受ける。
認証サーバ104は、クラウドセキュリティ認証局004が、WebAPIの認証をおこなうためのサーバである。
ISMS認証機関005は、認証そのものに関する文書を提供する。なお、ISMS認証機関005が、クラウドセキュリティ認証局004の役割を担う構成であってもよい。ISMS認証サーバ105は、ISMS認証に関する申請情報や文書を記憶する。
情報処理装置101、SaaSサーバ102、WebAPIサーバ103、認証サーバ104、およびISMS認証サーバ105は、ネットワーク106上に通信可能に接続されている。なお、ネットワーク106は、インターネットとして説明する。
以下、図2を用いて、図1に示した情報処理装置101、SaaSサーバ102、WebAPIサーバ103、認証サーバ104、およびISMS認証サーバ105に適用可能なハードウエア構成の一例について説明する。
図2において、201はCPUで、システムバス204に接続される各デバイスやコントローラを統括的に制御する。また、ROM203あるいは外部メモリ211には、CPU201の制御プログラムであるBIOS(Basic Input / Output System)やオペレーティングシステムプログラム(以下、OS)や、各サーバ或いは各PCの実行する機能を実現するために必要な各種プログラム等が記憶されている。
202はRAMで、CPU201の主メモリ、ワークエリア等として機能する。CPU201は、処理の実行に際して必要なプログラム等をROM203あるいは外部メモリ211からRAM202にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。
また、205は入力コントローラで、入力装置209等からの入力を制御する。206はビデオコントローラで、液晶ディスプレイ等のディスプレイ装置210への表示を制御する。なお、ディスプレイ装置は、液晶ディスプレイに限られず、CRTディスプレイなどであっても良い。これらは必要に応じてクライアントが使用するものである。
207はメモリコントローラで、ブートプログラム,各種のアプリケーション,フォントデータ,ユーザファイル,編集ファイル,各種データ等を記憶するハードディスク(HD)や、フレキシブルディスク(FD)、或いはPCMCIAカードスロットにアダプタを介して接続されるコンパクトフラッシュ(登録商標)メモリ等の外部メモリ211へのアクセスを制御する。
208は通信I/Fコントローラで、ネットワーク106を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、TCP/IPを用いた通信等が可能である。
なお、CPU201は、例えばRAM202内の表示情報用領域へアウトラインフォントの展開(ラスタライズ)処理を実行することにより、ディスプレイ装置210上での表示を可能としている。また、CPU201は、ディスプレイ装置210上の不図示のマウスカーソル等でのユーザ指示を可能とする。
ハードウエア上で動作する各種プログラムは、外部メモリ211に記録されており、必要に応じてRAM202にロードされることによりCPU201によって実行されるものである。
なお、全ての装置がこれらの構成を備えているわけではなく、必要なものを夫々備えていればよい。
図3は、SaaSサーバ102および認証サーバ104の機能構成の一例を示すブロック図である。
SaaSサーバ102上のAPI識別情報記憶部301は、SaaSサーバ102で利用されるAPI識別情報を記憶する機能部である。
SaaSサーバ102上のAPI認証情報取得部302は、API識別情報記憶部301により記憶されたAPI識別情報を用いて、認証サーバからAPIの認証情報を取得する機能部である。
SaaSサーバ102上のAPI認証判定部303は、API認証情報取得部302により取得した認証情報に基づいて、API識別情報記憶部301により記憶されたAPIが認証サーバにおいて認証されているか否かを判定する機能部である。
SaaSサーバ102上の実行制御部304は、API認証判定部303によりAPIが認証されていると判定された場合、アプリケーションを実行させるように制御し、API認証判定部303によりAPIが認証されていないと判定された場合、アプリケーションの実行を抑止させるように制御する機能部である。
SaaSサーバ102上のアプリケーション実行可否判定部305は、アプリケーションの実行の可否を判定する機能部である。
SaaSサーバ102上の実行制御部304は、アプリケーション実行可否判定部305により、アプリケーションを実行すると判定された場合、アプリケーションを実行し、アプリケーションを実行しないと判定された場合、アプリケーションの実行を抑止させるべくアプリケーションを実行させるように制御する機能部である。
SaaSサーバ102上のAPI利用可否判定部306は、APIの利用可否を判定する機能部である。
SaaSサーバ102上の実行制御部304は、API利用可否判定部306により、APIを利用すると判定された場合、APIを利用してアプリケーションを実行させるように制御し、APIを利用しないと判定された場合、APIを利用せずにアプリケーションを実行させるように制御する機能部である。
SaaSサーバ102上の非認証API通知部307は、API認証情報取得部302により取得した認証情報を用いて、認証されているAPIと認証されていないAPIとを識別可能に通知する機能部である。
SaaSサーバ102上のAPI有効期限判定部308は、有効期限が切れているか否かを判定する機能部である。
SaaSサーバ102上の実行制御部304は、API有効期限判定部308により有効期限が切れているAPIが存在すると判定した場合であっても、APIを利用してアプリケーションを実行させるように制御する機能部である。
SaaSサーバ102上のAPI認証情報取得部302は、認証サーバが持つ公開鍵を取得する機能部である。
SaaSサーバ102上のAPI認証判定部303は、公開鍵を用いて、API識別情報記憶部301により記憶されたAPIが認証サーバにおいて認証されているか否かを判定する機能部である。
SaaSサーバ102上の連絡先情報記憶部309は、APIを提供する提供者の連絡先情報を記憶する機能部である。
SaaSサーバ102上の認証結果通知部310は、API認証判定部303により判定されたAPIの認証結果を、連絡先情報記憶部309により記憶されたAPIを提供する提供者の連絡先情報を用いて通知する機能部である。
SaaSサーバ102上の画面情報生成部311は、API認証判定部303により認証されていると判定されたAPIと、API認証判定部303により認証されていないと判定されたAPIとを識別して表示する画面情報を生成する機能部である。
認証サーバ104上の認証情報取得部312は、SaaSサーバ102から受信したAPI識別情報を用いて、SaaSサーバ102から要求されたAPIの認証情報を取得する機能部である。
認証サーバ104上の認証情報送信部313は、認証情報取得部312により取得したAPIの認証情報をSaaSサーバ102に送信する機能部である。
図4は、クラウドセキュリティ認証の処理概要の一例を示す図である。
Webサービス利用者001は、WebAPI利用者(SaaS提供者)002より、Webサービス(SaaS)の提供を受ける。
WebAPI利用者002は、WebAPI提供者003からWebAPIの提供を受けると同時に、クラウドセキュリティ認証局004に認証確認を要求し、認証可否情報を受信する。
クラウドセキュリティ認証局004は、ISMS認証機関005に対して、WebAPI提供者003の認証確認を要求し、それを示す認証文書を受け取る。
なお、WebAPI提供者003は、WebAPI提供者003が提供する業務スコープについて、事前にISMS認証機関005に対して、ISMSの審査申請を行い、審査および認証を受けておくことを前提とする。
図5、図6、図7、図8は、クラウドセキュリティ認証処理の一例を示す図である。
以下において、図5、図6、図7、図8の各ステップを参照しながら、必要に応じて、図9〜図17のフローチャート、図18〜22の画面およびデータについて説明する。なお、以下における、情報処理装置101、SaaSサーバ102、WebAPIサーバ103、認証サーバ104、およびISMS認証サーバ105が行う処理は、それぞれの装置、サーバのCPU201が行うものとする。
図5は、クラウドセキュリティ認証処理1の一例を示す図である。
ステップ501において、WebAPIサーバ103は、WebAPI提供者003の操作に基づき、ISMS認証サーバ105に対して、WebAPI提供者003が提供する業務スコープに係るISMS審査情報を送信して申請する。
ステップ502において、ISMS認証サーバ105は、WebAPIサーバ103から申請されたISMS審査情報をチェックし、審査および認証処理を行う。
ステップ503において、ISMS認証サーバ105は、ISMS認証機関005の操作に基づき、WebAPIサーバ103に対して、認証結果情報を送信する。
ステップ504において、WebAPIサーバ103は、ISMS認証サーバ105から送信されたISMS認証結果を受信する。
ステップ505において、WebAPIサーバ103は、ISMS認証を受けることができた場合、公開鍵暗号方式を使用するツール(例えば、ssh−keygen)によって、WebAPIサーバ103にて提供するWebAPIの公開鍵131とWebAPIの秘密鍵132を作成する。
ステップ506において、WebAPIサーバ103は、認証サーバ104に対して、WebAPIの認証申請情報と、ステップ505にて作成したWebAPIの公開鍵131とを送信する。
ステップ507において、認証サーバ104は、WebAPIサーバ103から送信されたWebAPIの認証申請情報と公開鍵131を受信する。
ステップ508において、認証サーバ104は、ISMS認証サーバ105に対して、WebAPIの認証申請情報を送信し、対象のWebAPIがWebAPI提供者003に係るISMS認証の業務スコープ範囲内であるか否かの判定を要求する。
ステップ509において、ISMS認証サーバ105は、認証サーバ104からの要求を受け、対象のWebAPIがISMS認証の業務スコープ範囲内であるか否かを判定し、認証サーバ104に対して、判定結果を送信する。この判定結果の送信方法は、ISMS認証文書のPDFファイルを電子メールで送信する方法、ISMS認証文書を表示するWebページへのURLを電子メールで送信する方法などが挙げられる。
以上で、図5の説明を終了する。
図6は、クラウドセキュリティ認証処理2の一例を示す図である。
ステップ601において、認証サーバ104は、ISMS認証サーバ105から送信された判定結果を受信し、WebAPIサーバ103から認証を申請されたWebAPIがISMS認証の登録範囲内であることを確認する。
ステップ602において、認証サーバ104は、WebAPIサーバ103から認証を申請されたWebAPIがISMS認証の登録範囲内である場合、WebAPIサーバ103から申請されたWebAPI認証情報を、図19のWebAPI提供者テーブル1910、ISMS認証テーブル1920に登録する。具体的な登録方法としては、認証サーバ104は、ディスプレイ装置210にWebAPI認証情報登録画面1800(図18)を表示し、クラウドセキュリティ認証局004の操作によって、WebAPI認証情報登録画面1800に入力された情報をWebAPI提供者テーブル1910、ISMS認証テーブル1920に登録する。
図18は認証サーバ104におけるWebAPI認証情報登録画面の一例を示す図、図19は認証サーバ104において管理するテーブルの一例を示す図である。WebAPI提供者テーブル1910では認証を申請してきたWebAPI提供者の情報を、ISMS認証テーブル1920では、認証申請の対象となるWebAPIの情報を管理する。例えば、ある会社がWebAPIを提供する場合、WebAPIの登録数は必ずしも会社で1つに限定されるものではなく、事業毎にWebAPIを登録することがある。よって、ISMS認証テーブル1920は、会社毎に1レコードとするのではなく、ISO27001の登録範囲であるWebAPI毎に1レコードとして管理する。つまり、ISMS認証テーブル1920は、WebAPI名を主キーとする。
なお、この実施形態においては、ISMS認証テーブル1920はWebAPI名を主キーとしWebAPI毎に1レコードとして管理するとしたが、これに限定するものではなく、例えば、ISO27001の登録範囲である複数のWebAPIをWebAPI群としてまとめ、そのWebAPI群名を主キーとしWebAPI群毎に1レコードとして管理してもよい。
図9は、WebAPI認証情報登録処理の一例を示すフローチャートである。以下、図9について説明する。
ステップS901において、認証サーバ104は、クラウドセキュリティ認証局004によってWebAPI認証情報登録画面1800(図18)に入力された、WebAPI提供者に関する情報を取得し、WebAPI提供者テーブル1910に記憶する。具体的には、「WebAPI提供会社ID」「WebAPI提供会社名」「WebAPI提供会社代表部門名」「代表部門担当者名」「代表部門担当者連絡先」を取得し、WebAPI提供者テーブル1910に記憶する。
また、認証サーバ104は、クラウドセキュリティ認証局004によってWebAPI認証情報登録画面1800(図18)に入力された、WebAPI認証情報を取得し、ISMS認証テーブル1920に記憶する。具体的には、「WebAPI名」「認証機関名」「認証基準」「所在地」「組織名」「部門名」「初回登録日」「有効期限」「登録範囲」「認証登録番号」「WebAPIの公開鍵131」を取得し、ISMS認証テーブル1920に記憶する。
ステップS902において、認証サーバ104は、ステップS902にて取得した、WebAPI認証情報をハッシュ化し、得られたハッシュ値をRAM202に記憶する。本実施形態においては、ハッシュ化する情報を「認証機関名」「認証基準」「所在地」「組織名」「部門名」「初回登録日」「有効期限」「登録範囲」「認証登録番号」「WebAPI名」「WebAPIの公開鍵131」としたが、これらに限定するものではなく、WebAPI毎にユニークなハッシュ値が生成されるのであれば、その他の情報を含めても、これらから一部の情報を除外してもよい。
以上で、図9の説明を終了する。
次に、ステップ603において、認証サーバ104は、WebAPI提供者電子証明書を生成する。図20は、WebAPI認証情報の一例を示す図である。2001〜2010は、WebAPI提供者003がISO27001の認証を取得すれば、その認証に関する文書から確認できる情報である。2011は、図5のステップ507にて、クラウドセキュリティ認証局004がWebAPI提供者003から受信した、WebAPIの公開鍵131である。2012は、図9のS902において算出したハッシュ値である。
具体的には、図10のWebAPI提供者電子証明書生成処理の一例を示すフローチャートを用いて説明する。
ステップS1001において、認証サーバ104は、ステップS901およびステップS902にて取得したWebAPI認証情報をRAM202から取得し、クラウドセキュリティ認証局の秘密鍵142を用いて暗号化する。
ステップS1002において、認証サーバ104は、ステップS1001にて暗号化したWebAPI認証情報を用いて、WebAPI提供者電子証明書を生成する。具体的には、WebAPI提供者電子証明書には、暗号化していないWebAPI認証情報、暗号化したWebAPI認証情報、WebAPIの公開鍵131が含まれる。
ステップS1003において、認証サーバ104は、WebAPI名を検索キーとしてISMS認証テーブル1920を検索し、ステップS1002にて生成されたWebAPI提供者電子証明書を登録する。
以上で、図10の説明を終了する。
ステップ604において、認証サーバ104は、ステップ603にて生成されたWebAPI提供者電子証明書をWebAPIサーバ103に送信する。なお、WebAPI提供者電子証明書は、WebAPI提供者003にとって重要な情報であるため、WebAPI提供者電子証明書にパスワードをかけて電子メールで送信するなど、セキュアな方法で送信する。
ステップ605において、WebAPIサーバ103は、認証サーバ104から受信したWebAPI提供者電子証明書を外部メモリ211に記憶する。具体的には、図11のWebAPI提供者電子証明書登録処理の一例を示すフローチャートを用いて説明する。
ステップS1101において、WebAPIサーバ103は、認証サーバ104から受信したWebAPI提供者電子証明書を外部メモリ211に記憶する。このステップの具体的な方法としては、WebAPIサーバ103において用意されている、電子証明書登録用のコマンドや電子証明書登録画面(不図示)等を用いて、外部メモリ211に登録する。
以上で、図11、図6の説明を終了する。
図7は、クラウドセキュリティ認証処理3の一例を示す図である。図21は、SaaSサーバ102において管理するWebAPIリストの一例を示す図である。実際にWebAPIを呼び出すために必要な、URLや、その形式、呼び出しに必要なID、パスワードなどがSaaSのサービスの中で利用される。以下、図7について説明する。
ステップ701において、SaaSサーバ102は、WebAPI提供者003からWebAPIの提供を受ける前に、WebAPI利用者002の操作に基づき、提供するWebサービスにおいて利用するWebAPIが認証を受けている認証サーバ104に対して、クラウドセキュリティ認証局電子証明書の要求を行う。要求の具体的な方法としては、認証サーバ104に対し、HTTPプロトコルのRequest電文や、電子メールなどを送信して、クラウドセキュリティ認証局電子証明書を要求する。
なお、この実施形態においては、クラウドセキュリティ認証局004および認証サーバ104はそれぞれ1つとしたが、今後、クラウドセキュリティ認証局004が世界中に複数局設置されることも考えられ、WebAPI毎に認証を担当したクラウドセキュリティ認証局が異なることが考えられる。その場合、WebAPI利用者002は、利用するWebAPIの認証がどのクラウドセキュリティ認証局で行われたのかについて、WebAPI提供者003から情報を入手し、ステップ701にて、利用するWebAPIの認証が行われたクラウドセキュリティ認証局の認証サーバ104に対して、クラウドセキュリティ認証局電子証明書の要求を行う。
なお、その際、SaaSサーバ102は、提供するWebサービスで利用するWebAPIのリストを、SaaSサーバ102の外部メモリ211上の利用WebAPIテーブル2100(図21)として記憶する。すなわち、利用WebAPIテーブル2100は、アプリケーションサーバで利用されるAPI識別情報を記憶する手段の一例を示すステップである。具体的には、利用WebAPIテーブル2100に、「WebAPI名」「提供会社名」「URL」「形式」「ID」「PASSWORD」を登録しておく。また、この時点では、「認証結果」「利用可否」カラムはNULLである。この2つのカラムについては、後ほど説明する。
なお、利用WebAPIテーブル2100は、SaaSサーバ102で動作するアプリケーションのソースファイルや設定ファイルを検索して、SaaSサーバ102が自動で作成するとしてもよいし、WebAPI利用者002の操作に基づいて、SaaSサーバ102が作成するとしてもよい。
なお、本実施形態においては、Webサービスで利用するWebAPIのリストを利用WebAPIテーブル2100に登録しておくとしたが、この方法に限定するものではなく、Webサービスで利用するWebAPIのリストをアプリケーションサーバにおけるweb.xmlファイルのような設定ファイルに「WebAPI名」「提供会社名」「URL」「形式」「ID」「PASSWORD」「認証結果」「利用可否」の値を記憶するとしてもよい。
ステップ702において、認証サーバ104は、SaaSサーバ102からの送信された、クラウドセキュリティ認証局電子証明書の要求を受信する。
ステップ703において、認証サーバ104は、外部メモリ211に記憶されたクラウドセキュリティ認証局電子証明書を取得し、SaaSサーバ102に送信する。この送付方法については、クラウドセキュリティ認証局電子証明書にパスワードをかけて電子メールで送信する、SSLなどのセキュアな通信によってクラウドセキュリティ認証局電子証明書を送信する、パスワードが必要なWebサイトのURLを電子メールで通知し、WebAPI利用者002にダウンロードさせるなどの方法等がある。
ステップ704において、SaaSサーバ102は、クラウドセキュリティ認証局004から送付されたクラウドセキュリティ認証局電子証明書を受信し、SaaSサーバ102の利用WebAPIテーブル2100に記憶する。具体的には、図12のクラウドセキュリティ認証局電子証明書取得処理のフローチャートを用いて説明する。
ステップS1201において、SaaSサーバ102は、WebAPI名を検索キーとして利用WebAPIテーブル2100を検索し、クラウドセキュリティ認証局電子証明書を登録する。この登録の具体的な方法としては、SaaSサーバ102において用意されている、電子証明書登録コマンドや電子証明書登録画面(不図示)等を用いて登録する。
以上で、図12、図7の説明を終了する。
図8は、クラウドセキュリティ認証処理4の一例を示す図である。以下、図8について説明する。
ステップ801において、SaaSサーバ102は、提供するWebサービスを起動する。なお、Webサービスの起動方法は、SaaSサーバ102のOSが起動した際に自動でWebサービスを起動する方法、WebAPI利用者002の操作に基づいて起動する方法、WebAPI利用者002によって事前に設定されたタイマーやバッチによって起動する、としてもよい。
ステップ802において、SaaSサーバ102は、Webサービスの起動するにあたって、SaaSマネジメントコンソールを起動し、Webサービスで利用するWebAPIがISMS認証の登録範囲内であるか否かをディスプレイ装置210に表示する。本実施形態においては、Webサービスの起動に応じて、SaaSマネジメントコンソールを起動するとしたが、Webサービスの起動とは無関係に、WebAPI利用者002がコマンドや実行ファイルによりSaaSマネジメントコンソールを起動するとしてもよい。また、バッチなどによりSaaSマネジメントコンソールを定期的に起動し、WebAPIの認証結果をWebAPI利用者002にメール通知する方法をとってもよい。
SaaSマネジメントコンソールは、WebAPI提供者003のWebAPI電子証明書を要求して、その結果を取得する。つまり、SaaSサーバ102から、WebAPIサーバ103へRequest電文を送信し、WebAPI電子証明書を含むResponse電文を受信する。
つまり、SaaSサーバ102は、SaaSマネジメントコンソールにWebAPI提供者003のWebAPI電子証明書認証の確認結果を表示する。このSaaSマネジメントコンソールに関するフローを図13、図14、図15、図16に示す。つまり、図13から図16の処理を行うことによって、SaaSマネジメントコンソール画面2200が表示される。
また、図22は、SaaSサーバ102が出力するSaaSマネジメントコンソール画面2200の一例を示す図である。2201〜2203にはWebサービスで利用するWebAPIの名称を、2211〜2213には認証結果、2222〜2223には認証エラーになったWebAPIの利用可否を決定するチェックボックスを表示する。
図13はSaaSマネジメントコンソールに係る処理の一例を示すフローチャートを示す図である。以下、図13について説明する。
ステップS1301において、SaaSサーバ102は、提供するWebサービスで利用するWebAPIのリストを取得する。具体的には、図14のWebAPIリスト取得処理の一例を示すフローチャートを用いて説明する。
ステップS1401において、SaaSサーバ102は、変数nに1を代入する。
ステップS1402において、SaaSサーバ102は、提供するWebサービスで利用するWebAPIのリストを利用WebAPIテーブル2100からn件目のWebAPIレコードを取得する。具体的には、「URL」「形式」「ID」「PASSWORD」の値を取得する。
ステップS1403において、SaaSサーバ102は、n件目のWebAPIレコードの有無を判定し、無の場合(n件目のWebAPIレコードが取得できなかった場合)、ステップS1301のWebAPIリスト取得処理を終了する。有の場合(n件目のWebAPIレコードが取得できた場合)、ステップS1404に進む。
ステップS1404において、SaaSサーバ102は、配列WebAPI(n)に取得したi件目のWebAPIレコードを代入し、RAM202に記憶する。
ステップS1405において、SaaSサーバ102は、変数nの値を1インクリメントし、ステップS1402に戻る。
以上で、図14の説明を終了する。
ステップS1302において、SaaSサーバ102は、利用するWebAPIに係る認証を確認する。具体的には、図15の認証確認処理の一例を示すフローチャートを用いて説明する。
ステップS1501において、SaaSサーバ102は、変数iに1を代入し、WebAPI利用個数分だけステップS1502〜ステップS1513をループする。
ステップS1502において、SaaSサーバ102は、変数エラーフラグに0を設定する。
ステップS1503において、SaaSサーバ102は、WebAPIサーバ103に対して、WebAPI提供者電子証明書を要求し、WebAPIサーバ103はWebAPI提供者電子証明書を送信する(図8の803)。具体的には、SaaSサーバ102は、ステップS1404にてRAM202に記憶した「形式」「ID」「PASSWORD」を用いてWebAPI提供者電子証明書を取得するための認証情報を作成し、WebAPIサーバ103の「URL」に対して、作成した認証情報を送信する(図8の802から803へのRequest)。その認証情報を受信したWebAPIサーバ103は、認証情報が正しい場合、SaaSサーバ102に対して、WebAPI提供者電子証明書を送信する(図8の803から802へのResponse)。
ステップS1504において、SaaSサーバ102は、WebAPIサーバ103から送信されたWebAPI提供者WebAPI電子証明書を受信し、WebAPI提供者WebAPI電子証明書を取得できたか否かを判定する。すなわち、ステップS1503、ステップS1504は、記憶されたAPI識別情報を用いて、認証サーバからAPIの認証情報を取得する処理の一例を示すステップである。取得できなかった場合は、ステップS1505に進み、取得できた場合は、ステップS1506に進む。
ステップS1505において、SaaSサーバ102は、変数エラーフラグに1を設定し、ステップS1513に進む。
ステップS1506において、SaaSサーバ102は、ステップ704にて取得したクラウドセキュリティ認証局電子証明書からクラウドセキュリティ認証局の公開鍵141を取得する。すなわち、ステップS1506は、認証サーバが持つ公開鍵を取得する処理の一例を示すステップである。
ステップS1507において、SaaSサーバ102は、ステップS1506にて取得したクラウドセキュリティ認証局の公開鍵141を用いて、ステップS1504にて取得したWebAPI提供者電子証明書を復号化する。
ステップS1508において、SaaSサーバ102は、復号化されたWebAPI提供者電子証明書に含まれる「認証機関名2001」「認証基準2002」「所在地2003」「組織名2004」「部門名2005」「初回登録日2006」「有効期限2007」「登録範囲2008」「認証登録番号2009」「公開鍵2010」をハッシュ化し、算出されたハッシュ値をRAM202に記憶する。
ステップS1509において、SaaSサーバ102は、ステップS1507にて復号化されたWebAPI提供者電子証明書に含まれている「ハッシュ値2012」が、ステップS1508にてRAM202に記憶されたハッシュ値と同じ値か否かを判定する。異なる値の場合は、ステップS1510に進み、同じ値の場合は、ステップS1511に進む。すなわち、ステップS1509は、取得した認証情報(例えば、ハッシュ値)に基づいて、そのAPIが認証サーバにおいて認証されているか否かを判定する処理の一例を示すステップである。また、ステップS1507〜S1509は、公開鍵を用いて、APIが認証サーバにおいて認証されているか否かを判定する処理の一例を示すステップである。なお、本実施形態ではハッシュ値を用いて説明したが、改竄されていないことが特定できれば、ハッシュ値に限ることはない。
ステップS1510において、SaaSサーバ102は、変数エラーフラグに2を設定する。
ステップS1511において、SaaSサーバ102は、現在日付がステップS1507にて復号化されたWebAPI提供者電子証明書に含まれる「有効期限2007」の範囲内にあるか否かを判定する。範囲外の場合は、ステップS1512に進み、範囲内の場合は、ステップS1513に進む。すなわち、ステップS1511は、有効期限が切れているか否かを判定する処理の一例を示すステップである。
ステップS1512において、SaaSサーバ102は、変数エラーフラグに3を設定する。
ステップS1513において、SaaSサーバ102は、配列 認証結果のi番目の値として、エラーフラグの値を設定する。また、このエラーフラグの値を、Webサービスの「WebAPI名」を検索キーにして、利用WebAPIテーブル2100を検索し、「認証結果」の値として更新する。これにより、SaaSマネジメントコンソールの画面を終了後も、各WebAPIの認証結果を保持することができる。これにより、WebAPI利用者002は、SaaSマネジメントコンソールを起動した時だけでなく、利用WebAPIテーブル2100を確認することで、利用するWebAPIの認証状況を確認することができる。
ステップS1514において、SaaSサーバ102は、変数iの値を1インクリメントし、変数iの値がWebAPI利用個数を超えない場合は、ステップS1502に戻り、超えた場合は、図15の認証確認処理の一例を示すフローチャートを終了する。
以上で、図15の説明を終了する。
ステップS1303において、SaaSサーバ102は、SaaSマネジメントコンソールにWebサービスで利用するWebAPIのリストを表示する。具体的には、図16のWebAPIリスト表示処理の一例を示すフローチャートを用いて説明する。
ステップS1601において、SaaSサーバ102は、変数iに1を代入し、WebAPI利用個数分だけステップS1602〜ステップS1606をループする。
ステップS1602において、SaaSサーバ102は、配列 認証結果のi番目の値を取得し、値が0の場合はステップS1603に進み、値が1の場合はステップS1604に進み、値が2の場合はステップS1605に進み、値が3の場合はステップS1606に進む。
ステップS1603において、SaaSサーバ102は、ディスプレイ装置210にWebAPI名と「認証OK」のメッセージを表示する。(図22の2201と2211)
ステップS1604において、SaaSサーバ102は、ディスプレイ装置210にWebAPI名と「電子証明書を取得できませんでした」のメッセージを表示する(不図示)。また、メッセージの右には、利用可否チェックボックスを表示する。
ステップS1605において、SaaSサーバ102は、ディスプレイ装置210にWebAPI名と「電子証明書が不正です」のメッセージを表示する(図22の2202と2212)。また、メッセージの右には、利用可否チェックボックス2222を表示する。
ステップS1606において、SaaSサーバ102は、ディスプレイ装置210にWebAPI名と「有効期限が切れています」のメッセージを表示する(図22の2203と2213)。また、メッセージの右には、利用可否チェックボックス2223を表示する。すなわち、ステップS1604〜ステップS1606は、取得した認証情報を用いて、認証されているAPIと認証されていないAPIとを識別可能に通知する処理の一例を示すステップである。
ステップS1607において、SaaSサーバ102は、変数iの値を1インクリメントし、変数iの値がWebAPI利用個数を超えない場合は、ステップS1602に戻り、超えた場合は、図16のWebAPIリスト表示処理を終了する。
本実施形態においては、SaaSマネジメントコンソール(図22)をディスプレイ装置210に表示することで、WebAPIの認証結果をWebAPI利用者002に通知するとしたが、メールや運用監視のアラート等による通知であってもよい。言い換えれば、WebAPI利用者002がWebAPIの認証結果を識別可能にする方法であればよい。
また、本実施形態においては、認証結果を0〜3の4種類としたが、これに限定するものではなく、より少なくても多くてもよい。当然、多い方が、認証エラー発生後、WebAPI提供者003への問い合わせする際において問題の切分けを迅速に行うことが可能になる。
以上により、インターネット上で提供されるAPIの認証に従って、アプリケーションの実行を適切に制御する仕組みを提供することができる。
ステップS1304において、SaaSサーバ102は、配列 認証結果の値がすべて0の場合は、ステップS1307に進み、0以外の値がある場合は、認証エラーのWebAPIが存在するため、ステップS1305に進む。つまり、利用するAPIの認証がすべて正常に行われた場合は、ステップS1305のダイアログ2230を表示することなく、自動的にWebサービスの実行が開始される。
ステップS1305において、SaaSサーバ102は、ディスプレイ装置210にWebサービスの提供を行うか否かを判断するダイアログ2230を表示する。すなわち、ステップS1305は、アプリケーションの実行の可否を判定する処理の一例を示すステップである。なお、バッチによりSaaSマネジメントコンソールを起動する場合、ダイアログ2230を表示するのではなく、認証エラーが発生した場合、Webサービスを実行するか否か、認証エラーが発生したWebAPIを利用するか否かについて、WebAPI利用者002が設定ファイルなどに「利用可否フラグ」として設定しておき、ステップS1305において、「利用可否フラグ」を参照することで、Webサービスの実行の可否、認証エラーが発生したWebAPIの利用可否を決定するとしてもよい。
ステップS1306において、SaaSサーバ102は、ダイアログ2230のボタン押下を受け付け、はいボタン2231が押下された場合は、ステップS1307に進み、いいえボタン2232が押下された場合は、図13のSaaSマネジメントコンソールに係る処理を終了する。
すなわち、ステップS1306は、APIが認証されていると判定された場合、アプリケーションを実行させるように制御し、APIが認証されていないと判定された場合、アプリケーションの実行を抑止させるように制御する処理の一例を示すステップである。
例えば、図22において、WebAPI A2201、WebAPI B2202およびWebAPI C2203が認証されている場合に、アプリケーション(Webサービス)を実行するよう制御することが、「APIが認証されていると判定された場合、アプリケーションを実行させるように制御する処理」の一例であり、WebAPI A2201、WebAPI B2202またはWebAPI C2203のうち認証されていないWebAPIが存在する場合、アプリケーションの実行を抑止するよう制御することが、「APIが認証されていないと判定された場合、アプリケーションの実行を抑止させるように制御する処理」の一例である。
また、ステップS1306は、アプリケーションの実行の可否を判定する処理の一例を示すステップである。また、ステップS1306は、APIの利用可否を判定する処理の一例を示すステップである。また、ステップS1306は、APIを利用すると判定された場合、APIを利用して前記アプリケーションを実行させるように制御し、APIを利用しないと判定された場合、APIを利用せずに前記アプリケーションを実行させるように制御する処理の一例を示すステップである。
つまり、図22のように、利用可否チェックボックス2222がチェックされているWebAPI C2203を利用してアプリケーション(Webサービス)を実行することが、「APIを利用すると判定された場合、前記APIを利用してアプリケーションを実行させるように制御する処理」の一例であり、利用可否チェックボックス2222がチェックされているWebAPI B2202を利用せずにアプリケーションを実行することが、「APIを利用しないと判定された場合、APIを利用せずにアプリケーションを実行させるように制御する処理」の一例である。
以上により、認証されていないWebAPIが存在する場合は、ダイアログを表示し、Webサービスの実行を抑止させるように制御することができるため、Webサービスのセキュリティを確保することができる。
ステップS1307において、SaaSサーバ102は、利用可否チェックボックス(図22の2222と2223)の値を、利用WebAPIテーブル2100の「利用可否」の値として登録する。具体的には、Webサービスの「WebAPI名」を検索キーにして、利用WebAPIテーブル2100を検索し「利用可否」の値を、利用可否チェックボックスがチェックされている場合は「OK」、チェックされていない場合は「NG」に更新する。なお、認証が正常に行われたWebAPI(例えば、WebAPI A)については、「利用可否」の値を「OK」に更新する。
これにより、WebAPI利用者002(つまり、SaaS(Webサービス)提供者)の判断によって、認証エラーのWebAPIの利用を個々に設定することが可能になる。例えば、図22の2223は、WebAPI利用者002が、認証エラー「有効期限が切れています」であるWebAPI Cを利用すると判断した、ということである。つまり、有効期限が切れているAPIであった場合、そのAPIを利用できなくするのではなく、WebAPI利用者002の判断によって、そのAPIを利用することができる。すなわち、ステップS1307は、有効期限が切れているAPIが存在すると判定した場合であっても、そのAPIを利用してアプリケーションを実行させるように制御する処理の一例を示すステップである。
以上により、認証されていないWebAPIが存在する場合においても、WebAPI毎に利用可否を設定することができるため、Webサービスの実行について、柔軟性を持った制御を行うことができる。具体的には、不動産情報検索Webサイトにおいて、地図表示APIの認証有効期限が切れている場合も、Webサイト運営会社は、地図表示APIの利用可否チェックボックスをチェックすることで、地図表示APIを引き続き利用し、エンドユーザに地図表示のサービスを提供することもできる。また、地図表示APIの利用可否チェックボックスのチェックを外すことで、地図表示APIを利用せず、エンドユーザに地図表示のサービスを提供しないようにすることができる。なお、地図表示APIを利用しない場合は、不動産情報検索Webサイトにおいては、地図表示APIを利用する情報を提供することができないため、地図表示ボタンをクリックできないように無効化したり(不図示)、地図表示エリアに「現在、地図表示サービスは停止しております。」などのメッセージを表示したりする(不図示)などの対応が必要になる。
ステップS1308において、SaaSサーバ102は、Webサービスを実行する(図8の804)。具体的には、図17のWebサービス実行処理の一例を示すフローチャートを用いて説明する。
ステップS1701において、SaaSサーバ102は、Webサービスを起動する。具体的には、Webサービスを実行するために必要な初期処理を実行する。なお、本実施形態においては、ステップS1304のWebAPI認証を確認し、Webサービスの提供開始を決定した後に、ステップS1701にてWebサービスを起動するとしたが、この処理順序に限定するものではなく、例えば、ステップS1301の前にWebサービスを起動しておき、WebAPIの認証に従って、利用するWebAPIを制限する処理順序としてもよい。
ステップS1702において、SaaSサーバ102は、Webサービス利用者001が利用する情報処理装置101から送信されたRequest電文を受信する(図8の806)。
ステップS1703において、SaaSサーバ102は、受信したRequest電文を解析し、どのWebAPIを利用するRequestかを特定する。このステップにより、利用するWebAPIの識別情報(本実施形態においては、WebAPI名)が特定できたとする。なお、本実施形態においては、受信したRequest電文から利用するWebAPIを特定するとしたが、この方法に限定するものではなく、RequestのURLによってWebAPIを特定する方法、Request電文に含まれる引数の値でWebAPIを特定する方法、HTTPセッションやクッキーに含まれる値でWebAPIを特定する方法、アクセスするWebページの識別情報によってWebAPIを特定する方法などの方法であってもよい。
ステップS1704において、SaaSサーバ102は、特定したWebサービスの「WebAPI名」を検索キーにして、利用WebAPIテーブル2100を検索し、「URL」「形式」「ID」「PASSWORD」「利用可否」を取得し、RAM202に記憶する。
ステップS1705において、SaaSサーバ102は、取得した「利用可否」の値がOKの場合はステップS1706に進み、NGの場合はステップS1709に進む。
なお、「利用可否」の値がNGのWebAPIについては、ステップS1709に進み、WebAPIは実行されないため、利用者側の端末では、このWebAPIに対応する実行結果画面の全体またはその一部について表示がされないように構成される(図26の2620)。
なお、実行結果画面には、「セキュリティを維持するため現在サービス停止中」など、Webサービスの一部が実行できない旨を表示させるようにすることで、よりセキュリティ(ISO27017)に準拠したシステムを提供することが可能となる。
なお、本実施形態においては、「利用可否」により対象のWebAPIの利用を制御するとしたが、「認証結果」に従って対象のWebAPIの利用を制御するとしてもよい。具体的には、ステップS1704において、「認証結果」が“0”の場合は認証OKのためステップS1706に進み、対象のWebAPIを利用し、「認証結果」が“0”以外の場合は認証エラーのためステップS1709に進み、対象のWebAPIを利用しないとする。なお、「認証結果」によってWebAPIの利用を制御すると、認証エラーの場合は利用が不可能になってしまうため、「利用可否」によってWebAPIの利用を制御する方が、より柔軟性を持ったWebサービスの実行が可能になる。
ステップS1706において、SaaSサーバ102は、ステップS1704にてRAM202に記憶した「URL」に対して、ステップS1704にてRAM202に記憶した「形式」に則って、WebAPIへのRequest電文を送信する。また、Request電文には、ステップS1704にてRAM202に記憶した「ID」「PASSWORD」を含めるとしてもよい。
なお、この実施形態においては、WebAPIを利用するためのRequest電文の送信先「URL」を、ステップS1503のWebAPI提供者電子証明書を取得するためのRequest電文の送信先「URL」と同一としたが、これはあくまで例であって、同一の「URL」に限定するものではない。つまり、WebAPIを利用するためのRequest電文の送信先「URL」と、WebAPI提供者電子証明書を取得するためのRequest電文の送信先「URL」とは、異なるURLであってもよい。
また、WebAPIを利用するためのRequest電文の送信先「URL」と、WebAPI提供者電子証明書を取得するためのRequest電文の送信先「URL」とが同一のURLである場合は、Request電文の中に引数として、WebAPIを利用するための引数やWebAPI提供者電子証明書を取得するための引数を付加する等によって、どちらのRequest電文かを区別するとしてもよい。
ステップS1707において、WebAPIサーバ103は、対応するWebAPIを実行して、受信したRequest電文を処理し、SaaSサーバ102に対して、WebAPI処理結果としてResponse電文を送信する。(図8の805)
ステップS1708において、SaaSサーバ102は、WebAPIサーバ103から送信されたResponse電文を受信する。
ステップS1709において、SaaSサーバ102は、当該WebAPIを利用しない処理を実行する。なお、この処理は、ステップS1708にて受信したResponse電文を利用する場合も、利用しない場合もある。
ステップS1710において、SaaSサーバ102は、情報処理装置101に対して、ステップS1708にて受信したResponse電文、およびステップS1709にて実行した処理結果をResponse電文として送信する(図8の806)。
以上で、図17、図13、図8の説明を終了する。
以上により、インターネット上で提供されるAPIの認証に従って、アプリケーションの実行を適切に制御する仕組みを提供することができる。
なお、本実施形態においては、公開鍵暗号方式を利用し、インターネット上で提供されるAPIの認証を行うとしたが、例えば、公開鍵暗号方式を利用せずに、SaaSサーバ102から認証サーバ104にWebAPI名で認証確認要求を行い、その返信をもってAPIが認証されているとしてもよい。そうすることで、本実施形態よりも、簡易なシステムでAPIの認証を行うことができる。また、その際、認証サーバ104は、SaaSサーバ102からの認証確認要求をトリガーにして、WebAPIサーバ103に認証情報を要求して、認証サーバ104が認証確認するとしてもよい。
より好適な例として説明した本実施形態のように、公開鍵暗号方式を利用することで、WebAPIサーバ103が提供するAPIが、認証サーバ104が認証したAPIと同一であることを証明することができるため、より強固な認証システムを構築することができるため、より厳重な認証を行うためには、本実施形態のように公開鍵暗号方式のような方式を利用する仕組みであることが求められる。なお、本実施形態では、公開鍵暗号方式を利用するとしたが、公開鍵暗号方式に限定するものではなく、WebAPIサーバ103が提供するAPIが、認証サーバ104が認証したAPIと同一であることを証明することができるのであれば、公開鍵暗号方式でない他の方式を利用してもよい。
以上により、インターネット上で提供されるAPIについて、セキュリティが確保された認証を効率的に行う仕組みを提供することができる。また、これにより、インターネット上で提供されるAPIを利用するアプリケーションについて、セキュリティが確保された状態を効率的に維持する仕組みを提供することができる。
〔第2の実施形態〕
次に、図23〜図27を用いて、第2の実施形態について説明する。
なお、第2の実施形態では、第1の実施形態における図16のフローチャートを図25に、第1の実施形態における図17のフローチャートを図27にそれぞれ置き換え、第1の実施形態のステップと同じ処理については、同じステップ番号を付与し説明を省略する。
図23は、第2の実施形態に係るSaaSサーバ102が出力するSaaSマネジメントコンソール画面の一例を示す図である。図24は、第2の実施形態に係るSaaSサーバ102において管理するWebAPIリストの一例を示す図である。図25は、第2の実施形態に係るSaaSマネジメントコンソール表示処理の一例を示すフローチャートである。
図25のステップS2501において、SaaSサーバ102は、ステップS1604〜ステップS1606にてディスプレイ装置210に表示されたメッセージの近傍に「WebAPI提供者に通知」ボタン(図23の2301、2302)を表示する。
ステップS2502において、SaaSサーバ102は、「WebAPI提供者に通知」ボタンの押下を受け付けたか否かを判定する。受け付けた場合、ステップS2503に進む。受け付けなかった場合、ステップS1607に進む。
ステップS2503において、SaaSサーバ102は、WebAPIの認証結果(ステップS1604〜ステップS1606にてディスプレイ装置210に表示されたメッセージの内容)をWebAPI提供者に通知する。すなわち、ステップS2503は、判定されたAPIの認証結果を、APIを提供する提供者の連絡先情報を用いて通知する処理の一例を示すステップである。
具体的には、「電子証明書を取得できませんでした」「電子証明書が不正です」「有効期限が切れています」などのWebAPI認証結果を、WebAPI提供者003に通知する。WebAPI提供者003の連絡先は、図24の利用WebAPIテーブル2400の連絡先2401から取得する。
以上により、WebAPI利用者002が、WebAPI提供者003にWebAPIの認証結果を簡単に通知することができるため、認証エラーとなったWebAPIの提供するWebAPI提供者003に対処してもらうことが簡単にできるようになり、WebAPI利用者002による利用するWebAPIの管理を容易にすることができる。
図26は、第2の実施形態に係る情報処理装置101に出力されるWebページの一例を示す図である。図27は、第2の実施形態に係るWebサービス実行処理の一例を示すフローチャートである。
SaaSサーバ102で実行するWebサービスにおいて利用するWebAPIが利用可能な(図27のステップS1705において「OK」)場合は、SaaSサーバ102は、情報処理装置101にWebページ2610(図26)のように、利用するWebAPIの実行結果(図27のステップS1708で受信した、図26の2611〜2613を出力する電文)を含む画面情報(例えばHTML)を送信する(図27のステップS1710)。
一方、SaaSサーバ102で実行するWebサービスにおいて利用するWebAPIが利用不可能な(図27のステップS1705において「NG」)場合は、SaaSサーバ102は、情報処理装置101にWebページ2620(図26)のように、利用できないWebAPIについて、「WebAPIを利用できない」旨のメッセージ(図27のステップS2701で作成した、図26のメッセージ2622)を含む画面情報を送信する(図27のステップS1710)。この場合、利用できるWebAPIについては、Webページ2610のWebAPI A実行結果2611・WebAPI C実行結果2613と同様、Webページ2620のWebAPI A実行結果2621・WebAPI C実行結果2623を出力する。
また、WebAPI Cは、有効期限が切れているため、WebAPI C実行結果2623には、実行結果とともに「有効期限が切れています」のような警告メッセージを表示するとしてもよい。
すなわち、ステップS2701は、認証されていると判定されたAPIと、認証されていないと判定されたAPIとを識別して表示する画面情報を生成する処理の一例を示すステップである。
以上により、利用するWebサービスのうち一部が実行できない旨を表示させることで、セキュリティ(ISO27017)に準拠した、かつ柔軟なシステムを提供することが可能となる。
以上により、インターネット上で提供されるAPIについて、セキュリティが確保された認証を効率的に行う仕組みを提供することができる。また、これにより、インターネット上で提供されるAPIを利用するアプリケーションについて、セキュリティが確保された状態を効率的に維持する仕組みを提供することができる。
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ(またはCPUやMPU)が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD−ROM、CD−R、DVD−ROM、磁気テープ、不揮発性のメモリカード、ROM、EEPROM、シリコンディスク等を用いることが出来る。
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、OS(オペレーティングシステム)に供給されるスクリプトデータ等の形態から成ってもよい。
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。