JP2017504092A - クラウド・サービス・セキュリティ・ブローカおよびプロキシ - Google Patents

Abstract

本出願は、一般に、ネットワークベースのサービス型ソフトウェア（ＳａａＳ）プロバイダとクライアントとの間のネットワークトラフィックに対して動作するシステムに関する。システムは、マネージド通信ネットワーク・プロキシとして構成され、事前に定められたポリシおよびルールに基づいて、ネットワークトラフィックに対してアクションを取ることができる。システムは、ファイルタイプおよび応答タイプに応じて以降の要求がサフィックスプロキシによって取り扱われるようにＳａａＳサーバ応答を処理することによって、捕捉ページ処理のために構成されたサフィックスプロキシを含むことができる。

Description

[1]関連出願の相互参照
[2]本出願は、２０１３年１１月１１日に出願された「Ｃｌｏｕｄ Ｓｅｒｖｉｃｅ Ｓｅｃｕｒｉｔｙ Ｂｒｏｋｅｒ ａｎｄ Ｐｒｏｘｙ（クラウド・サービス・セキュリティ・ブローカおよびプロキシ）」と題する米国仮特許出願第６１／９０２７８６号、２０１３年１１月１１日に出願された「Ｃｌｏｕｄ Ｓｅｒｖｉｃｅ Ｒｉｓｋ Ａｎａｌｙｓｉｓ ａｎｄ Ｔｈｒｅａｔ Ｄｅｔｅｃｔｉｏｎ（クラウド・サービス・リスク分析および脅威検出）」と題する米国仮特許出願第６１／９０２７８７号、２０１３年１１月１１日に出願された「Ｃｌｏｕｄ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ（クラウド・サービス発見）」と題する米国仮特許出願第６１／９０２７８９号、および２０１４年９月１２日に出願された「Ｃｌｏｕｄ Ｓｅｒｖｉｃｅ Ｓｕｆｆｉｘ Ｐｒｏｘｙ（クラウド・サービス・サフィックスプロキシ）」と題する米国仮特許出願第６２／０４９４７３号の優先権を主張し、それらの各々の内容は、その全体が、参照によって本明細書に組み込まれる。

[4]本出願は、一般に、通信をモニタリングおよび保護することによって、特にサフィックスプロキシの使用によって、通信ネットワークおよびシステムを保護することに関する。

[6]企業は、クラウドベースのサービス型ソフトウェア（ｓｏｆｔｗａｒｅ−ａｓ−ａ−ｓｅｒｖｉｃｅ）の提供をますます採用しつつある。これらのサービスは、多様なネットワークセキュリティリスクにさらされる。これらのネットワークを保護するための知られたシステムは、サービス型ソフトウェアを運用するサーバと、ユーザによって運用されるエンドポイントとの間のトラフィックを検査することによって動作する。

これらの知られたネットワークセキュリティシステムは、一般に、システムの複雑さを高めるエンドポイントの複雑な構成を必要とする。さらに、多くのケースでは、エンドポイントは、企業の完全な制御下にないことがあり、まったく管理されないこと、またはさもなければ構成可能でないことがある。ユーザ制御のエンドポイントを構成および管理することに内在する困難に加えて、ネットワークアドレスが動的に生成される場合、セッション全体にわたるトラフィック捕捉を保証することは困難である。

[8]例示的なアーキテクチャおよび方法の動作についての例示的な概要を示す図である。 [9]複数のプロキシノードを有する例示的なアーキテクチャを示す図である。 [10]ＳＡＭＬを使用する例示的な認証方法を示す図である。 [11]待ち時間短縮のために世界中に分散されたプロキシノードを含む、複数の異なるネットワークの例を示す図である。 [12]フェイルオープンルーティングを示す例示的なネットワーク・プロキシ・アーキテクチャを示す図である。 [13]ロードバランサのクラスタおよび複数のプロキシノードから構成される例示的なプロキシノードを示す図である。 [14]例示的なユーザインターフェースを示す図である。 [15]例示的なユーザインターフェースを示す図である。 [16]例示的なユーザインターフェースを示す図である。 [17]例示的なユーザインターフェースを示す図である。 [18]脅威検出のための例示的な方法を示す図である。 [19]例示的なパラメータセットを示す図である。 [20]サービス型ソフトウェア（ＳａａＳ）環境の発見についての例示的な方法を示す図である。 [21]キャッシュされないサフィックスプロキシ動作についての例示的な方法を示す図である。 [22]キャッシュされるサフィックスプロキシ動作についての例示的な方法を示す図である。

[24]通信をモニタリングおよび保護するためのアーキテクチャが、本明細書で説明される。本明細書で説明されるシステムおよび方法は、ユーザのためのクラウド・トラフィック・セキュリティおよび制御をどこででも透過的に可能にするために使用され得る。システムは、会社のクラウド・サービス・アカウント内のいずれかまたはすべてのトラフィックおよびアクティビティを保護するように構成され得る。いくつかの実施形態では、システムは、それがいかなるクライアント側またはネットワークインストールも必要としないように構成され得る。システムは、世界中の複数のロケーションに分散された独立の自律ネットワーク・プロキシから構成される非常に回復力に富んだ仮想ネットワークを含むことができる。

[25]マネージド通信ネットワーク・プロキシ・サービスが、ユーザとネットワークベースのソフトウェアサービスプロバイダとの間のネットワーク通信トラフィックを途中で捕え、モニタリングし、変更し、転送するために使用され得る。マネージド・ネットワーク・プロキシ・サービスは、ネットワーク脅威を検出および軽減するために動作するように構成され得る。非限定的な例として、サービスは、アプリケーション・ファイアウォール・モード、疑わしいネットワークトラフィックおよび挙動について通知するための受動的な侵入検出（ＩＤＳ）モード、または脅威をブロックするための侵入防止システム（ＩＰＳ）モードを含む、様々なモードで動作するように構成され得る。システムは、ネットワークトラフィックに対してアプリケーション制御、ＵＲＬフィルタリング、およびマルウェア防御を実行するようにも構成され得る。

[26]アーキテクチャ
[27]本明細書で説明されるシステムは、ネットワークベースのサービス型ソフトウェア（ＳａａＳ）プロバイダとクライアントとの間のネットワークトラフィックに対して動作するように構成され得る。いくつかの実施形態では、システムは、クライアントデバイスまたはネットワークに対して行われていたいかなる制御または制限も行われずに、クライアントコンピューティングデバイスが、（インターネットなどの）公衆ネットワークを通してＳａａＳプロバイダに接続される場合、ＳａａＳプロバイダとクライアントコンピューティングデバイスとの間のそのようなトラフィックに対して動作するように構成されることが可能である。いくつかの実施形態では、クライアントデバイスの構成は必要ではない。

[28]アーキテクチャ設計
[29]システムの構成要素は、マネージド通信ネットワーク・プロキシの形態で具体化され得る。本明細書では、プロキシに対する言及が行われることがあるが、プロキシは１つまたは複数のネットワークデバイスにおいて具体化され得ることが理解される。さらに、マネージド・ネットワーク・プロキシは、非集中化され得、マネージド・ネットワーク・プロキシの機能は、様々な地理的地域にある複数のマシンにわたって分散され得る。

[30]いくつかの実施形態では、ネットワーク・プロキシは、クライアントデバイスとＳａａＳプロバイダとの間のトラフィックが、ネットワーク・プロキシを通過するように構成され得る。ネットワーク・プロキシが通信を仲介するので、それは、これらのポイント間のネットワークトラフィックをモニタリングし、事前に定められたポリシおよびルールに基づいて、ネットワークトラフィックに対してアクションを取るために使用され得る。例示的なアーキテクチャおよび方法の動作についての概要が、図１に示されている。プロキシ・ネットワークは、回復力について最適化され得、プロキシ・ネットワークが障害を起こした場合、ユーザのトラフィックを再ルーティングするために、フェイルオープン制御が使用され得る。以下でより詳細に論じられるように、配備上、ＳａａＳトラフィックの一般的フローは、以下の通りである。

[31]任意のロケーションから、任意のデバイス上で、ユーザは、組織のクラウド・サービスにアクセスする。トラフィックは、最も近いマネージド・ネットワーク・プロキシノードを通してルーティングされる。ノードは、ポリシ実施ノードとして機能し、クラウドアクティビティの完全な監査を提供することができる。プロキシ・ネットワーク・データセンタにおいて、イベントは、トークン化され、中央データセンタにある各テナント用の別々のデータベース内に収集される。イベント処理が行われ、インシデント（例えば、「未知のデバイスが機密データにアクセスした」）が報告される。ユーザインターフェースが提供され得、それによって、管理者は、コンソールにアクセスし、クラウドアクティビティに対する可視性を有することができる。さらに、ポリシが定められ、プロキシノードによって実施され得る。複数のプロキシノードを有する例示的なアーキテクチャが、図２に示されている。

[32]プロキシは、自律的に動作するように構成され得、異なるインターネットサービスプロバイダ（ＩＳＰ）および地理にわたって回復力および高可用性を保証する。いくつかの実施形態では、すべてのノードが中央データセンタに向かって（一方向に）情報を送信する、スター型アーキテクチャが利用され得る。

[33]システムは、フェイルセキュアまたはフェイルオープンであるように構成され得る。外部ホスティングソリューションが使用される場合、他の手段が障害を起こすと、ユーザは、元のＳａａＳプロバイダにルーティングされ得る。これは、ユーザに対してシームレスなエクスペリエンスを保証する。

[34]パブリッククラウドおよびプライベートクラウド
[35]プライベートクラウド配備：会社データに対するさらなるセキュリティのために、プロキシサーバが、会社のプライベートクラウド内に配備され得る。この構成では、ネットワークトラフィックは、組織のネットワーク内に閉じ込められるが、メタデータ・ログが、依然として組織境界の外部に送信されることがある。

[36]パブリッククラウド配備：プロキシサーバが、会社のプライベートクラウドの外に配備される。クラウド自体は、パブリッククラウドまたはプライベートクラウドとすることができる。

[37]マネージド・ネットワーク・プロキシ・サービス・インフラストラクチャ
[38]本明細書で説明されるマネージド通信ネットワーク・プロキシは、非限定的な例として、フォワードプロキシ、サフィックスプロキシ、またはリバースプロキシを含む、様々なプロキシモードで構成され得る。

[39]フォワードプロキシとして構成される場合、ネットワーク・プロキシは、プロキシ自動構成（ＰＡＣ）ファイルを使用することができ、および／またはプロキシ・チェイニングにおいて既存のネットワーク・プロキシに接続され得る。リバースプロキシとして構成される場合、配備は、組織のＤＮＳサーバを通して行われ得る。

[40]好ましい実施形態では、マネージド・ネットワーク・プロキシは、サフィックスプロキシとして構成され得る。例えば、サフィックスプロキシとして、ｈｔｔｐ：／／ｗｗｗ．ｓａｌｅｓｆｏｒｃｅ．ｃｏｍは、ｈｔｔｐ：／／ｗｗｗ．ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ．ｎｅｔｗｏｒｋ−ｐｒｏｘｙ−ｓｅｒｖｉｃｅ．ｃｏｍを通してアクセスされ、ここで、ｎｅｔｗｏｒｋ−ｐｒｏｘｙ−ｓｅｒｖｉｃｅ．ｃｏｍは、マネージド・ネットワーク・プロキシ・サービスのために使用されるドメイン名である。いくつかの実施形態では、サフィックスプロキシは、サフィックスプロキシにある認証センタと、ＳａａＳプロバイダの両方に対する認証である、２要素認証を使用することができる。

[41]プロトコルサポート
[42]マネージド・ネットワーク・プロキシは、いずれの任意のアプリケーションまたはプロトコルもサポートするように構成され得る。非限定的な例として、以下のプロトコル、すなわち、ＨＴＴＰおよびＨＴＴＰＳ、ＲＰＣオーバＨＴＴＰ、Ｏｕｔｌｏｏｋ ａｎｙｗｈｅｒｅ、ＷｅｂＤＡＶ、ＦＴＰ、ならびに独自仕様のベンダプロトコルがサポートされ得る。

[43]セキュリティ：ＳａａＳトラフィック捕捉
[44]マネージド・ネットワーク・プロキシは、トラフィックを検査し、ＳａａＳインターネットアドレスを検出するように構成され得る。いくつかの実施形態では、マネージド・ネットワーク・プロキシは、（ユニフォーム・リソース・ロケータ、ユニフォーム・リソース・アイデンティファイアなどの）インターネットアドレスを求めてネットワークトラフィックを検査するように構成され得る。非限定的な例として、ネットワーク・プロキシは、検査のために、ネットワークトラフィックを逆コンパイルし、分解し、または逆アセンブルすることができる。マネージド・ネットワーク・プロキシは、ＳａａＳリソースに直接的にアクセスして、マネージド・ネットワーク・プロキシをバイパスするようにクライアントデバイスに指示するユーザデバイスに、ネットワークアドレスが提供されないように、クライアントデバイスとＳａａＳプロバイダとの間のネットワークトラフィックを変更するように構成され得る。ＳａａＳインターネットアドレスが検出された場合、そのアドレスは、ネットワーク・プロキシ・サービスのためのドメイン名を元のネットワークアドレスに追加することによって、ネットワーク・プロキシにおいて、あるアドレスに書き換えられ得る。

[45]サフィックスプロキシは、以降の要求がサフィックスプロキシによって取り扱われるようにＳａａＳサーバ応答を処理することによって、捕捉ページ処理のために構成され得る。処理は、ファイルタイプおよび応答タイプに依存し得る。非限定的な例として、処理されるファイルタイプは、ＨＴＭＬまたはＪａｖａＳｃｒｉｐｔを含むことができ、応答は、ｇｚｉｐ圧縮された応答またはチャンク化された応答を含むことができる。サフィックスプロキシは、ＳａａＳプロバイダから送信された、ウェブページを含む、任意のコンテンツをエミュレートするように構成され得る。サフィックスプロキシは、任意のコンテンツを検査および／または逆コンパイルして、コンテンツ内に存在する任意の参照ページおよび／またはＵＲＬを識別し、それらのＵＲＬを書き換えるように構成され得る。

[46]いくつかのケースでは、検査は、クライアントとＳａａＳプロバイダとの間で転送されるコードまたはスクリプトを実行することを必要とする。例えば、ＳａａＳプロバイダに直接的にアクセスするネットワークアドレスの生成を検出するために、ＪａｖａＳｃｒｉｐｔが、ネットワーク・プロキシにおいてエミュレートされ得る。コンテンツ内で直接アクセスアドレスが識別された場合、ネットワーク・プロキシを参照するようにアドレスを書き換えるために、コンテンツが変更され得る。

[47]セキュリティ：ＳａａＳサービスロックダウン
[48]システムは、ＳａａＳサービスへのアクセスを、マネージド・ネットワーク・プロキシを通したものだけに制限するように構成され得る。システムは、このロックダウンのための複数の技法を含むことができ、選択された技法は、以下でより詳細に説明される配備方法に依存し得る。ネットワークトラフィックは、セッションが生成された時に、またはその後の任意の時にロックダウンされ得る。セッション開始は、以下でより詳細に説明される。

[49]ロックダウン方法１：証明書の置換
[50]いくつかの環境では、ＳａａＳプロバイダは、セキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）を使用することができる。それらの環境では、ネットワーク接続をロックダウンするために、ＳＡＭＬトークン置換が使用され得る。例えば、ＳＡＭＬトークンは、５分間にわたって有効とすることができる。ＳＡＭＬプロキシが構成される場合、ユーザは、マネージド・ネットワークＳＡＭＬプロキシを通してのみ、サービスにアクセスすることができる。

[51]接続をロックダウンするために、ブラウザクッキー置換が使用され得る。ユーザがＳａａＳプロバイダに対して認証を行う場合、ＳａａＳプロバイダは、ユーザにクッキーを送信する。送信されたクッキーは、ユーザがログインさせられたかどうか、およびユーザがどのアカウントを用いてログインさせられたかを示すためにＳａａＳプロバイダによって使用される、認証クッキーとすることができる。マネージド・ネットワーク・プロキシは、ユーザとＳａａＳプロバイダとの間に存在するので、ＳａａＳプロバイダによって送信されたユーザブラウザクッキーを途中で捕え、暗号化することができる。その後、マネージド・ネットワーク・プロキシは、ユーザのデバイス上に記憶するために、暗号化されたクッキーをユーザに送信することができる。したがって、ユーザは、元のＳａａＳサイト上のクライアントによって直接的に使用され得ないクッキーの暗号化されたコピーのみを保持する。マネージド・プロキシ・ネットワークを通して使用される場合、クッキーは、クライアントデバイスからプロキシ・ネットワークに送信され、プロキシ・ネットワーク内で暗号解除され、送信元サイトに送信される。いくつかのケースでは、ＳａａＳプロバイダによって生成されたクッキーは、暗号化され得、または暗号化されたコンテンツを含むことができる。これらのケースでは、マネージド・ネットワーク・プロキシは、暗号化のさらなるレイヤをクッキーに追加してから、それをクライアントに送信することができる。

[52]ブラウザクッキーが置換され得る方法と同様に、ＯＡｕｔｈトークン（または他の任意の持続的なＡＰＩトークン）も、インラインで置換され得る。マネージド・ネットワーク・プロキシは、クライアントによるトークン（例えば、モバイルアプリケーションによって使用されるＯＡｕｔｈトークン）を求める要求を追跡し、それらを暗号化されたバージョンで置換することができる。これは、さらなる認証シナリオにわたるサービスロックダウンの実施を可能にする。

[53]マネージド・ネットワーク・プロキシは、ユーザパスワードもプロキシすることができる。この技法は、任意のＳａａＳサービスに適用され得る。いくつかの実施形態では、パスワード・プロキシは、ＳＡＭＬがサポートされない場合に使用され得る。これを実装するために、ＳａａＳサービスパスワードは、２つ以上のパーツに分割され得る。ユーザは、パスワードのパーツをすべては知らない。マネージド・ネットワーク・プロキシ・サービスは、パスワードの残りを記憶する。この構成では、ユーザがマネージド・ネットワーク・プロキシ・サービスを通してＳａａＳサービスにアクセスした場合にのみ、完全なパスワードが構成され得る。この技法は、マネージド・ネットワーク・プロキシ・サービスがユーザパスワードを記憶することを必要としない。例えば、ハッシュサフィックスをすべてのパスワードに追加することは、単一のハッシュキーのみを記憶することを必要とする。

[54]ＳａａＳアプリケーションにおいてパスワードを変更するためのユーザによるいかなる試みも、マネージド・ネットワーク・プロキシ・サービスを通してモニタリングされ得、ユーザは、パスワードの一部を設定することを許可され得る。いくつかの実施形態では、ユーザは、パスワードの半分を設定することを可能にされるだけである。パスワード・プロキシが構成される場合、パスワード変更を求めるいずれの要求（例えば、「パスワードを忘れた」リンク）も、ネットワーク・プロキシによってモニタリングされ得、ネットワーク・プロキシは、新しいパスワードにハッシュを適用するように構成され得る。

[55]ロックダウン方法２：アクセス制限
[56]いくつかのケースでは、ＳａａＳアプリケーションは、インターネットプロトコル（ＩＰ）アドレス制限機能を可能にし、それによって、ネットワーク・プロキシ・サービスと関連付けられたインターネットプロトコル（ＩＰ）アドレスのみにアクセスを制限するように構成され得る。

[57]さらなるセキュリティ機能
[58]マネージド・ネットワーク・プロキシ・サービスは、さらなるセキュリティ機能をサポートするように構成され得る。非限定的な例として、ネットワーク・プロキシは、ユーザアクティビティの監査を実行するために使用され得、それによって、いずれのユーザアクションも、トラフィックストリームから解析および／または監査され得る。ネットワーク・プロキシは、ポリシ実施において使用され得る。例えば、プロキシ・サービスは、特定の動作を禁止するためのアクセス制御のために、ユーザ、デバイス、ロケーション、アクション、コンテンツ、および／または速度といった状況に基づいてＤＬＰポリシを実装することによるデータ紛失防止（ＤＬＰ）のために、動的マスキングのために、ならびに透かしのために使用され得る。ネットワーク脅威も、脅威特徴付けロジックを使用して検出および／またはブロックされ得る。

[59]マネージド・ネットワーク・プロキシ・サービスは、強化されたファイル保護サービスを提供するように構成され得る。いくつかの実施形態では、ネットワーク・プロキシ・サービスは、ネットワークベースのファイル記憶サービスとの統合をサポートすることができる。これらのタイプのサービスの非限定的な例は、Ｇｏｏｇｌｅ（商標）Ｄｒｉｖｅ、Ｄｒｏｐｂｏｘ（商標）などを含む。ネットワーク・プロキシは、ユーザがＳａａＳプロバイダからファイルを取り出し、それらをユーザのデバイス上にローカルに記憶することを防止するように構成され得る。これは、「常時クラウド内（ａｌｗａｙｓ ｉｎ ｔｈｅ ｃｌｏｕｄ）」ポリシと呼ばれることがある。いくつかの実施形態では、これは、ファイルがＳａａＳアプリケーションとユーザのデバイスとの間で、またはＳａａＳアプリケーションどうしの間で転送されないように、ユーザセッション中に情報フローを動的に変更およびリダイレクトするように構成され得る。いくつかのケースでは、ファイルをダウンロードする代わりに、ファイルのバージョンが、ユーザに表示され得る。

[60]ＶＰＮオーバウェブ
[61]プロキシ・サービスは、企業イントラネットへの安全なアクセスを可能にするように構成され得る。ネットワーク・プロキシ・サービスにおいてユーザがひとたび認証されると、ユーザは、（例えば、ＨＴＴＰ（Ｓ）を使用して）ウェブ上でイントラネットサイトにアクセスすることができる。この方法は、デバイス上に専用ＶＰＮクライアントを必要としない。接続がひとたび開始されると、ネットワーク・プロキシ・サービスは、ＶＰＮ接続をオープンし、ＨＴＴＰ（Ｓ）イントラネットサイトのためのリバースプロキシとして機能する。ユーザ監査、警告、およびファイル保護などの他の機能は、ＶＰＮ接続上で実施され得る。

[62]配備方法
[63]システムは、単独のまたは組み合わされた様々な手段のいずれかによって配備され得る。いくつかの構成では、システムは、クライアントのいかなる構成も行わずに配備され得る。他の構成では、ＳａａＳにおける構成の代わりに、またはそれに加えて、クライアントが構成され得る。

[64]透過的な配備方法
[65]システムは、マネージド・ネットワーク・プロキシを通してユーザとＳａａＳプロバイダとの間でトラフィックを透過的に転送するための技法を含むことができる。これらの実施形態では、ＳａａＳアプリケーションへのアクセスは、プロキシのユーザのみに制限され得る。これらの技法は、ユーザデバイスまたはユーザのローカルネットワーク上でいかなるインストールも行わずに、セキュリティ制御の運用を可能にする。この技法は、ＳａａＳプロバイダによってホストされるすべてのアプリケーションに対してグローバルベースで使用され得る。

[66]Ａ．透過的な認証プロキシ（認証レイヤ）
[67]クラウド・サービスにおけるセキュリティ・アサーション・マークアップ言語（ＳＡＭＬ）または類似のプロトコルのためのビルトインサポートを利用することによって、クライアント側においていかなる構成も行わずに、ユーザは、マネージド・ネットワーク・プロキシ・サーバに自動的にリダイレクトされ得る。例えば、ＳＡＭＬは、安全なウェブドメインが、ユーザ認証および認可データを交換することを可能にするＸＭＬ標準である。ＳＡＭＬを使用して、オンラインサービスプロバイダは、安全なコンテンツにアクセスしようと試みるユーザを認証するために、別のオンライン識別情報プロバイダと連絡を取ることができる。

[68]非限定的な例として、この技法は、ＳＡＭＬをサポートするＳａａＳサービス、および外部ＳＡＭＬプロバイダをすでに有する組織とともに使用され得る。これらのケースでは、マネージド通信ネットワーク・プロキシは、ＳＡＭＬプロバイダとして構成され、その場合、プロキシ・サービスは、認証を実行するために、元のＳＡＭＬプロバイダを使用する。認証に成功すると、ユーザは、ネットワーク・プロキシ・サービスによって提供されるサフィックスプロキシを通して、ＳａａＳプロバイダにリダイレクトされる。（サフィックスプロキシ・サービスは、以下でより詳細に説明される）。

[69]アクセスをサフィックスプロキシのユーザに制限するために、ＳａａＳアプリケーションのアクセス制御機能が使用され得る。ＳＡＭＬプロキシは、サフィックスプロキシにリダイレクトする代わりに、ブラウザアドオンをインストールするためにも使用され得る。このケースでは、アドオンは、トラフィックを透過的にネットワーク・プロキシ・サービスに向かわせ、サフィックスプロキシの代わりに、リバースプロキシが使用されることになる。ＳＡＭＬに加えて、マネージド通信ネットワーク・プロキシは、類似の機能を有する他のプロトコルと相互運用性があるように構成され得る。例えば、ＷＳ−Ｆｅｄｅｒａｔｉｏｎ（商標）は、Ｏｆｆｉｃｅ３６５（商標）サービスに関連して使用され得る。

[70]ＳＡＭＬを使用する例示的な認証方法が、図３に示され、説明される。

[71]Ｂ．透過的な自己ＩＤＰプロビジョニング（認証レイヤ）
[72]シングルサインオン・ソリューションの代わりに、自己ＩＤＰプロビジョニングが使用され得る。これは、ユーザがマネージドＳＡＭＬプロキシ・サービスにリダイレクトされるＳＡＭＬプロキシ方法の変形であるが、認証プロセスは、マネージド通信ネットワーク・プロキシ・サービスによって実行される。ログイン・プロキシが使用され得る。ユーザのログイン要求時に、マネージド・ネットワークＳＡＭＬプロキシは、ユーザ証明書を検証するために、元のＳａａＳサービスに問い合わせを行う。パスワード同期を使用する場合、ネットワーク・プロキシ・サービスは、アクティブディレクトリ（または他の任意のＬＤＡＰディレクトリ）からのユーザパスワードをマネージド・ネットワークＳＡＭＬプロキシに同期させるパスワード同期ツールをインストールすることによって、アドホックＳＡＭＬプロバイダとして機能することができる。

[73]Ｃ．透過的なゲートウェイ・プロキシ（トラフィックレイヤ）
[74]この技法は、任意のＳａａＳサービスに適用され得、ＳＡＭＬがＳａａＳサービスによってサポートされない場合に特に適用可能であり得る。ユーザは、ＳａａＳサービスにアクセスするとき、異なるＵＲＬを使用するように命令され得る。そのＵＲＬは、マネージド・ネットワーク・プロキシ・サービスを通してユーザをリダイレクトする。この構成は、アクセスをサフィックスプロキシのユーザに制限するために、ＳａａＳアプリケーションのアクセス制御機能を使用することができる。ＩＰ制限機能は、マネージド通信ネットワーク・プロキシ・サービス内に配置されたＩＰアドレスのみにアクセスを制限することを可能にすることができる。

[75]非透過的な配備方法
[76]モバイルおよびデスクトップアプリケーションは、トラフィックをマネージド通信ネットワーク・プロキシ・サービスを通してリダイレクトするために、ユーザのデバイスに対するインストールまたは構成変更を使用することによって個別に構成され得る。

[77]Ａ．ＳＡＭＬプロキシ：上で説明されたＳＡＭＬプロキシを使用して、ユーザは、マネージド通信ネットワーク・プロキシ・サービスと通信するようにユーザがデバイスをインストールおよび／または構成することを要求するページにリダイレクトされ得る。

[78]Ｂ．デスクトップアプリケーション（トラフィックレイヤ）：ほとんどのデスクトップアプリケーションは、システム・プロキシ構成をサポートする。ＰＡＣファイルは、マネージド・デバイスについては自動構成され得、アンマネージド・デバイスについてはユーザ構成され得る。ＰＡＣは、主要なオペレーティングシステム（ＯＳ）、ブラウザ、およびアプリケーションによってサポートされ、グループ・ポリシ・オブジェクト（ＧＰＯ）を使用して、Ｗｉｎｄｏｗｓドメイン環境内に配備され得る。ＰＡＣファイルは、ＳａａＳトラフィックのみがマネージド・プロキシ・ネットワーク・プラットフォームを通ることを可能にするように構成され得、ユーザのインターネットトラフィックの残りは、変わることなく直接的にルーティングされ得る。

[79]Ｃ．モバイルアプリケーション（トラフィックレイヤ）：マネージド・デバイスのためのＰＡＣ方法と同様に、モバイル・デバイスは、デバイス上へのＶＰＮまたはＡＰＮのインストール、およびマネージド・プロキシ・ネットワーク証明書を必要とし得る。

[80]アプリケーション固有のソリューション：いくつかのアプリケーションは、シームレスなリダイレクションを可能にする特定の構成オプションを有する。例えば、Ｏｕｔｌｏｏｋ自動発見機能を使用して、Ｏｕｔｌｏｏｋクライアントは、マネージド・プロキシ・ネットワークＯｕｔｌｏｏｋプロキシに自動的にリダイレクトされる。

[81]マネージド・ネットワークおよびデバイスのための配備方法
[82]いくつかの実施形態では、マネージド・ネットワーク・プロキシは、ユーザの敷地上の設備内で具体化され得る。他の実施形態では、マネージド・ネットワーク・プロキシ機能は、ウェブブラウザアドオンを通して達成され得る。ブラウザアドオンは、ＳａａＳアプリケーションがひとたびブラウザ内で検出されると、トラフィックがマネージド・プロキシ・ネットワークにリダイレクトされる点で、ＰＡＣファイルのように動作するように構成され得る。

[83]いくつかの実施形態は、プロキシ・チェイニングを使用するように構成され得、それによって、既存の組織プロキシは、ＳａａＳ行きの要求をマネージド通信ネットワーク・プロキシ・サービス・インフラストラクチャを通して転送するように構成される。これらの実施形態は、転送される要求とともに、組織識別子（ユーザ名および／またはＩＰ）を任意選択で含むことができる。

[84]いくつかの実施形態では、ＰＡＣファイルが使用され得る。ＰＡＣは、組織のいたるところに配備され得る。ＳａａＳアプリケーションをマネージド通信ネットワーク・プロキシ・サービスにリダイレクトするために、ＰＡＣが使用され得る。これは、ＳａａＳプロバイダのデータベースに基づくことができる。ドメイン名に基づいてツリーに編集されたドメインのリストを有する効率的なＰＡＣが使用され得る。

[85]上で説明されたこれらの構成のいずれでも、特定のユーザまたはユーザのグループ上にプラットフォームが動的に配備され得、それによって、漸進的な配備を可能にする。これは、ＳＡＭＬプロキシに基づいて、例えば、ユーザのいくつかのみを再ルーティングすることによって行われ得る。

[86]システム可用性
[87]図４に示されるように、プラットフォームは、複数の異なるネットワークを含むことができ、待ち時間短縮のために世界中に（例えば、示されるように５つのセンタに）分散されたプロキシノードを含む。ユーザは、最も近いノードまたは別の最適なノードにルーティングされ得る。システムは、ノード間に自動ＤＮＳフェイルオーバを含むことができる。ノードのいずれかが、ポリシ実施ポイントとして機能し、監査ログを生成することができる。非限定的な例として、バックエンド・ネットワークは、中央データベースおよびバックエンドサーバを含むＡＷＳ仮想プライベートクラウド（ＶＰＣ）とすることができる。

[88]ＤＮＳ高可用性
[89]フェイルオープンルーティングを示す例示的なネットワーク・プロキシ・アーキテクチャが、図５に示されている。プロキシノード・ネットワークは、高可用性を実装するために、ＤＮＳサーバを使用することができる。ＤＮＳ記録は、非常に短い有効期間（ＴＴＬ）（例えば、３０秒）に設定され得、定期的に更新のためにＤＮＳサーバに問い合わせを行うようにクライアントに強制する（問い合わせ時間は、ブラウザのキャッシュ設定に応じて変わり得る）。サーバは、利用可能な最も近いノードにクライアントを向かわせ（Ｇｅｏ−ＤＮＳ）、ノード障害の場合、問題を検出し、クライアントを他の利用可能なノードにシームレスにリダイレクトすることができる。

[90]ＤＮＳサーバ自体の可用性が、説明された挙動に影響し得る。例えば、ＡｍａｚｏｎによるＲｏｕｔｅ５３は、高可用性を保証する成熟した高度に利用可能なシステムであると考えられる。ＤＮＳサーバ自体がダウンした場合、システムは、フェイルオープンするように構成され得る。

[91]自律ノード
[92]プロキシノードは、様々な世界中の地域において、クラスタ化して構築され得る。ノードのいくつかまたはすべてが、同時にオンラインになり、顧客にサービスすることができる。障害の場合、ノードは、ステートレスであり、いかなるサービス中断も引き起こさずに、システムがユーザをノード間で移動させることを可能にする。

[93]ノードは、自律的で回復力を有することができる。図６に示されるように、プロキシノードは、ロードバランサのクラスタと、複数の（例えば、２つまたは３つの）プロキシノードとから構成され得る。中央ノードのいくつかは、クラウド・プロバイダ自体（例えば、ＥＬＢおよびＲａｃｋＳｐａｃｅ）によって提供される外部ロードバランサに依存することができ、さらに大きい回復力を可能にする。各ノードは、プラットフォームの他の部分にいかなる依存もせずに、自律的に機能することができる。バックエンド・ネットワークとの通信は、ブローカ・メッセージを使用して実行され、完全に非同期とすることができる。バックエンド障害の場合、メッセージは、サイズに上限のある待ち行列内に内部的に記憶され、ノード自体の動作は、影響を受けない。図６に示される例示的な実施形態では、各ノードは、ロードバランサのクラスタと、いくつかのプロキシサーバとから構成され得る。ビルトイン分散型サービス妨害（ＤＤｏＳ）防御を備えた（ＡＷＳおよびＲａｃｋｓｐａｃｅロードバランサなどの）外部ロードバランサを使用する（ロードバランサはトラフィックをルーティングし、ＳＳＬターミネーションを実行しなくてもよい）、（米国西部、米国東部、ヨーロッパ、および中東など）複数の中央ノードが存在し得る。ＤＤｏＳ攻撃の場合、トラフィックは、最も近い中央ノードに自動的にルーティングされ得る。

[94]フェイルオーバ・シナリオ
[95]システムは、多くの異なるフェイルオーバ・シナリオを取り扱うように構成され得る。いくつかの可能なシナリオおよび解決が、以下で説明される。

[96]単一マシン・フェイルオーバ：この場合、ＤＮＳは、要求を最も近いノードにルーティングする。各ノードは、独立に動作し、内部的にフェイルオーバを取り扱う。

[97]内部プロセスの障害：十分な冗長性は、マシンレベルから開始し、そこでは、各クリティカルプロセスは、ウォッチドッグによって監視され、直ちに再開される。クリティカルプロセスは、常に動作中のいくつかのインスタンスを有する。すべての非クリティカル動作は、非同期に実行される。

[98]プロキシサーバの障害：これは、トラフィックをノード内の他のプロキシに向かわせる。

[99]ロードバランサ・サーバの障害：これは、すべてのトラフィックがクラスタ内の第２のロードバランサを通過するようにさせる。

[100]単一プロキシノード・フェイルオーバ：単一ノード障害は、データセンタ停電またはＩＳＰ接続性問題によって引き起こされ得る。ノードが応答できない場合、ＤＮＳフェイルオーバは、ユーザに混乱を与えずに、トラフィックを次の利用可能なノードにルーティングする。

[101]地域的フェイルオーバ：複数のノードに影響する地域的な問題の場合でさえも、システムは、通常動作を続行する。ＤＮＳフェイルオーバは、トラフィックを他の地域内の残りの機能中ノードにルーティングする。影響を受ける地域のユーザは、通常よりも長い待ち時間を経験することがあるが、僅かな程度である。

[102]中央ノード・フェイルオーバ：ＤＮＳサーバは、利用可能なノード間のロード・バランシングを実行するが、異常な急上昇が、補助ノードに影響する連鎖反応を引き起こすことがある。この理由で、複数の障害の場合、トラフィックは、異常なトラフィック急上昇を取り扱うように特に設計された中央ノードにルーティングされる。

[103]さらなる特徴
[104]マネージド・ネットワーク・プロキシ・サービスは、非限定的な例として、ビジネスアナリティクス、アドプション統計、フィーチャ使用、ライセンス利用、ユーザエンゲージメント、およびサービスレベル・アグリーメント（ＳＬＡ）モニタリングに関連するメトリックをさらに提供するように構成され得る。

[105]サービスは、ＳａａＳサービスのための指令および制御センタ、警告センタ、ならびに使用統計センタも含むことができる。サービスは、ユーザのロールおよびレルムに従って、各ユーザをデータにアクセス可能にすることを実施する、ロール実施を実行することができる。サービスは、事前決定された日次使用パターンに従って、ＳａａＳプロバイダへのいくつかのバックエンド接続を維持するために、動的ＳＳＬプーリングを実行することができる。

[106]マネージド・ネットワーク・プロキシ・サービスおよび他の機能のための例示的な管理コンソールが、図７〜図１０に示されている。

[107]脅威検出ロジック
[108]上で説明されたシステムおよび方法を使用して、ネットワーク接続されたＳａａＳプロバイダとクライアントデバイスとの間のネットワークトラフィックは、プロキシノードにおいて途中で捕えられ得る。プロキシノードは、脅威検出ロジックを使用して、様々な脅威インジケータについてトラフィックを分析するようにさらに構成され得る。

[109]脅威検出についての方法の概要が、図１１に示されている。セキュリティゲートウェイ（１０１１）は、ユーザのネットワークトラフィックがそれを通して搬送されるプロキシノード（１０１０）の１つまたは複数におけるアルゴリズムルーチンとして実装され得る。代替として、セキュリティゲートウェイは、トラフィックがそれを通して搬送される別個のデバイスにおいて具体化され得る。ユーザトラフィックは、プロキシノードに接続された任意の送信元と送信先との間に存在し得る。ユーザの非限定的な例は、オンプレミスユーザ、インターネットユーザ、パートナユーザ、またはモバイルユーザとすることができる。

[110]セキュリティゲートウェイ（１０１１）は、ユーザトラフィックから様々なパラメータを抽出するように構成され得る。以下の非限定的な例が提供される。セキュリティゲートウェイは、ユーザデバイスを記述する情報を抽出するように構成され得る。非限定的な例として、デバイスパラメータは、ｉＰａｄもしくはＳｕｒｆａｃｅタブレットなどのデバイスのタイプ、Ｗｉｎｄｏｗｓ ＲＴもしくはｉＯＳなどのデバイスのオペレーティングシステム、および／またはＣｈｒｏｍｅもしくはＥｘｐｌｏｒｅｒなどの使用されるウェブブラウザを含むことができる。セキュリティゲートウェイは、ユーザのデバイスのロケーションを記述する情報を抽出するように構成され得る。ロケーション情報は、物理的／地理的ロケーション、および／またはネットワーク上の論理的ロケーションを記述することができる。セキュリティゲートウェイは、ユーザによって取られるアクション（例えば、データを求める要求）、および／またはＳａａＳプラットフォームによる応答（例えば、要求されたデータの送信）に関する情報を抽出するように構成され得る。セキュリティゲートウェイは、（タイプに加えて）ユーザのデバイスの識別情報、ユーザのアクティビティの時間、およびユーザのアクションによって消費される帯域幅に関する情報を抽出するようにも構成され得る。

[111]セキュリティゲートウェイは、ＳａａＳプロバイダに接続するためにユーザによって使用される任意の通信デバイスを検出および識別するようにも構成され得る。個々のＳａａＳセッションがそのセッションのために使用される特定のデバイスと関連付けられ得るように、デバイス識別情報が、ユーザのアクセス履歴と関連して記録され得る。記憶される識別情報は、国際モバイル機器識別番号（ＩＭＥＩ）、電話番号、媒体アクセス制御（ＭＡＣ）アドレス、インターネット（ＩＰ）プロトコルアドレス、または他の一意的もしくは実質的に一意的な識別情報を含むことができる。このデバイス識別情報は、複数のユーザセッションにわたって追跡され、および／または関連付けられたユーザプロファイルと関連して記憶される。その後、以降の問い合わせは、単一のセッションにおいて、または複数のセッションにわたって、与えられたＳａａＳサービスにアクセスするために与えられたユーザによってどのデバイスが使用されたかを決定するために実行され得る。

[112]トラフィックパラメータが、検出モジュール（１０１２）に入力され得る。検出モジュールは、ユーザプロファイル・データストアから、ユーザプロファイル情報に基づいた入力を受け取ることもできる。ユーザプロファイル情報は、そのトラフィックが分析されるユーザについての情報を含むことができる。非限定的な例として、ユーザ情報は、検出モジュールから供給され得る。検出モジュールは、特定のセキュリティ脅威についての情報などの他の情報を含む知識ベースから入力を受け取ることもできる。好ましい実施形態では、知識ベースは、構成要素としてクラウド・サービス・インデックス（１０１５）を含むことができる。いくつかの実施形態では、検出モジュール（１０１２）は、セキュリティゲートウェイ（１０１１）の構成要素として含まれ得る。代替的な実施形態では、検出モジュール（１０１２）は、セキュリティゲートウェイ（１０１１）と通信する別個の構成要素とすることができる。

[113]脅威検出モジュール（１０１２）は、プロファイリングエンジン、距離ベースの異常エンジン、および統計ベースの異常エンジンを含むことができる。統計的異常エンジンは、短期および／または長期統計情報の組合せに基づいて、脅威評価を行うように構成され得る。各エンジンは、上で説明されたトラフィックパラメータのいずれかまたはすべてを受け取ることができる。エンジンの各々は、他のエンジンから引き出された入力を受け取ることもできる。

[114]異常エンジン
[115]異常エンジンは、特定の異常動作、一連の異常動作、および／または異常動作のパターンを検出するように構成され得る。例えば、エンジンは、ユーザまたはＳａａＳプロバイダによって実行される特定の動作が疑わしいかどうかを、学習時間にわたって獲得された履歴データが予想するそれの実行よりも高頻度でそれが実行されること（例えば、より高い動作率など）、または接続が新しい送信元もしくは送信先ロケーションを有することに基づいて決定するように構成され得る。異常エンジンは、ユーザによる一連の操作が疑わしいかどうかを決定するようにも構成され得る。いくつかのケースでは、個々の操作は疑わしくないことがある。しかしながら、その操作が別の操作と一連で実行される場合、その１組の操作が疑わしいことがある。例えば、ユーザは、ＳａａＳプロバイダに対して認証を行い、その後、システムの外にファイルを転送し始めることがある。例として、異常エンジンは、このシーケンスを疑わしいとして識別するように構成され得る。したがって、疑わしいトラフィックの異常検出は、いくつかの操作から構成され得る一連のアクティビティに基づくことができる。異常エンジンは、シーケンス通りでない操作のパターンが疑わしいかどうかを決定するようにも構成され得る。疑わしいパターンの検出において、異常エンジンは、シーケンスを外れて任意の時間期間にわたって取られたアクションを検査するように構成され得る。個々の操作、一連の操作、および操作のパターンの疑わしさは、本明細書で説明されるパラメータのいずれかに基づいて決定され得る。

[116]異常は、１つまたは複数のパラメータを以前に記憶されたプロファイル情報と比較することに基づいて検出され得る。非限定的な例として、プロファイル情報は、ロケーション、アクティビティの時間（１日の時間、曜日など）、デバイス使用、ユーザエージェント（タイプおよびバージョン）、アクション／要求の頻度、実行されるアクションのタイプ、実行されるアクションの順序、アクセスされる情報のタイプ、トラフィック帯域幅、セッション特徴（長さ、アイドル時間など）、ならびに／またはＨＴＴＰ要求特徴（どのリソースがアクセスされるか、方法、ヘッダ、大文字表記など）を含むことができる。

[117]クラウド・サービス・インデックス
[118]脅威検出ロジックは、任意の与えられたＳａａＳプロバイダについてのＳａａＳアプリケーション・リスク因子を組み合わせた１組のパラメータを含む、クラウド・サービス・インデックス（１０１５）を含むことができる。例示的なパラメータセットが、図１２に示されている。リスクレベル評価は、限定することなく、以下のものを含む、ソースのいくつかまたはすべてからの情報に基づくことができる。

[119]１．非限定的な例として、白書、認証などから供給される、そのセキュリティポリシに関する、ＳａａＳプロバイダによって提供される情報。

[120]２．ＳａａＳプロバイダ、クライアント、および他の環境因子に関する独自研究。ならびに／または
[121]３．セキュリティゲートウェイによって途中で捕えられたトラフィックの分析に基づいた、検出モジュールによって識別された、脆弱性および／もしくはクライアントのＳａａＳアプリケーションに対する攻撃の履歴。

[122]リスクは、限定することなく、以下のものを含む、１つまたは複数の軸に関して測定され得る。

[123]１．データリスク：マルチテナントおよび非暗号化データの使用など、ＳａａＳが保有するデータに課されるリスク。

[124]２．ユーザ／デバイスリスク：例えば、認証品質、匿名使用能力などを含む、接続されたユーザおよびデバイスによって課されるリスク。

[125]３．サービスリスク：プロバイダが実行するように主張するセキュリティ実施の品質、ウェブアプリケーション・セキュリティレベル、脆弱性管理など、サービスプロバイダのネットワークに課されるリスク。ならびに
[126]４．ビジネスリスク：プロバイダがそのクライアントに許可する制御、および例えば、監査能力、企業管理制御、および運用実施を含む、サービスの使用を保護するためのこれらの制御手段の能力。

[127]例示的なリスク因子のリストが、図１２に提供されている。表に示されるように、いずれのリスクも、その軸、カテゴリ、属性、記述、属性値、および／または（スコアもしくは重み付けなどの）インデックス値に基づいて識別され得る。

[128]識別およびプロファイリングエンジン
[129]脅威検出ロジックは、ユーザおよびデバイスの識別およびプロファイリングのためのモジュール（１０１３）を含むことができる。プロファイリングモジュールは、現在のユーザを識別するために、途中で捕えられた証明書を使用することができる。モジュールは、以下の特徴のいくつかまたはすべてを識別するために、受動トラフィック記録に基づいた、組織およびユーザプロファイリングを実行することができる。

[130]単一ユーザ使用パターンを含む、組織階層および挙動。

[131]管理者、経営者、および／または異なる部門を検出する、会社ロール。

[132]異なる支店および／もしくは事務所ロケーション、ならびに／または従業員の自宅ロケーションを検出する、会社ロケーション。

[133]会社レベルおよび／または単一ユーザレベルについての、１日の時間、曜日、１年の月、および特別な場合におけるユーザアクティビティの分布。ならびに
[134]日常のロケーション、アクティビティ時間、アプリケーション、および使用パターンを含む、日常のユーザ慣例。

[135]デバイス識別およびプロファイリングモジュールは、以下のものから引き出される情報に基づいて、セッションおよびブラウザにわたってユーザデバイスを区別および識別するようにも構成され得る。

[136]デバイス識別情報、ユーザ識別情報、およびユーザがログインした任意のＳａａＳアプリケーションについてのセッション情報を保有する指定されたセッションクッキーを用いてセッションを追跡すること。

[137]プロキシを通してアクセスするデバイスを識別するためのページへのＪａｖａＳｃｒｉｐｔインジェクション。

[138]同じデバイス上の異なるブラウザから管理されるセッションを結び付けるためのクロスブラウザ・ストレージ。ならびに
[139]セッション、デバイス、およびそれらの間のリンクを追跡し続けるための統合識別情報データベース。

[140]フィードバック
[141]脅威特徴付けロジックは、セキュリティ警告のための監視された学習モデルを構築するための方法を含むことができる。システムは、警告上でフィードバックを収集し、ＩＴおよび従業員の両方を関与させ、疑わしいパターンについてユーザに問い合わせを行うことによって動的にユーザプロファイルを構築し、および／またはユーザが疑わしく（例えば、不正ユーザと）思える場合、監視者を関与させることができる。

[142]仮想ネットワーク
[143]好ましい実施形態では、上で説明されたシステムは、模擬組織が様々なＳａａＳアプリケーション上でアクティビティを実行し、セキュリティゲートウェイによってモニタリングされる、別個の仮想ネットワーク（１０２０）と通信することができる。その実施形態では、仮想ネットワークは、研究およびテスト目的で維持される孤立ネットワークとすることができる。他の実施形態では、仮想ネットワークは、組織ネットワークモニタリングおよび脅威検出システムに組み込まれ得る。模擬組織の特徴および使用パターンは、本当の組織からの情報を用いて較正され得、その後、それらは、セキュリティゲートウェイによって記録される。検出モジュールをテストするために、異常が模擬トラフィック内にランダムに挿入され得る。異常は、疑わしい挙動パターンまたは攻撃を表すことができる。異常は、セキュリティゲートウェイによって記録された実際の異常、および自然に存在し、独自研究によって発見される異常を含む、様々なソースから収集され得る。

[144]仮想ネットワークは、ストレス下のシステムの異なる構成要素をテストし、フォールスポジティブ率およびフォールスネガティブ率を測定するためばかりでなく、将来のセキュリティ機能についての研究を実行するためにも使用され得る。

[145]仮想ネットワークは、仮想クライアント（１０２１）、ならびにセキュリティゲートウェイ（１０２２）、検出モジュール（１０２３）、および警告エンジン（１０２４）の別々のインスタンス化を含むことができる。警告エンジン（１０１４）において行われるべき変更は、最初に仮想警告エンジン（１０２４）上でテストされ得る。

[146]リスク／脅威重み付け
[147]図１２に提供される例に示されるように、識別されたリスクは、クラウド・サービス・インデックス（１０１５）内のインデックス値と関連付けられ得る。このインデックス値は、各々に関連するリスク因子に重み付けするために使用され得る。いくつかの実施形態では、複数のリスク因子が一緒に評価され得る。非限定的な例として、ネットワークトラフィックにおいてある時間期間にわたって識別された脅威についてのインデックス値は、数値脅威インジケータを提供するために合算され得る。

[148]応答アクション
[149]リスク重み付けが、検出モジュール（１０１２）および／または警告エンジン（１０１４）に提供され得る。その後、検出モジュールは、重み付けされた脅威情報に全面的または部分的に基づいて、ネットワークトラフィックに対してアクションを取ることができ、その後、警告エンジンは、クライアント（１００１）またはＳａａＳプロバイダ（１０３０）に警告を行うことができる。いくつかの実施形態では、検出モジュールは、検出モジュール（１０１２）の出力に基づいて、ＳａａＳプロバイダ（１０３０）からクライアント（１００１）に送信されたパケットをドロップするように命じる命令をセキュリティゲートウェイ（１０１１）に提供することができる。

[150]発見モジュールアーキテクチャ
[151]いくつかの実施形態では、発見モジュールは、ネットワークベースのサービス型ソフトウェア（ＳａａＳ）プロバイダとクライアントとの間のネットワークトラフィックを検査するように構成され得る。これらの実施形態では、システムは、クライアントデバイスまたはネットワークに対して行われていたいかなる制御または制限も行われずに、クライアントコンピューティングデバイスが（インターネットなどの）公衆ネットワークを通してＳａａＳプロバイダに接続される場合、ＳａａＳプロバイダとそのコンピューティングデバイスとの間のそのようなトラフィックに対して動作するように構成されることが可能である。これらの実施形態のいくつかでは、クライアントデバイスの構成は必要ではない。発見モジュールは、ＳａａＳアプリケーションデータベースを含むことができ、その内容は、以下でより詳細に説明される。

[152]それらの実施形態のいくつかでは、発見モジュールは、マネージド通信ネットワーク・プロキシ内で具体化され得る。本明細書では、プロキシに対して言及されることがあるが、プロキシは、１つまたは複数のネットワークデバイスにおいて具体化され得ることが理解される。さらに、マネージド・ネットワーク・プロキシは、非集中化され得、マネージド・ネットワーク・プロキシの機能は、様々な地理的地域にある複数のマシンにわたって分散され得る。

[153]他の実施形態では、発見モジュールは、ネットワークベースのサービス型ソフトウェア（ＳａａＳ）プロバイダとクライアントとの間を通るネットワークトラフィックを直接的に検査するようには構成されない。これらの実施形態では、発見モジュールは、ネットワーク上の任意のデバイスからＳａａＳ発見アクティビティを開始することができる。発見モジュールは、アプレットサーバおよびＳａａＳアプリケーションデータベースを含むことができ、それらの内容は、以下でより詳細に説明される。

[154]ＳａａＳ環境の発見
[155]発見モジュールは、独立デバイス上に常駐するか、それともネットワーク・プロキシ内に常駐するかにかかわらず、任意のＳａａＳ環境についてのアクセスおよび使用パターンを識別するように構成され得る。本明細書で使用される場合、ＳａａＳ環境は、ＳａａＳプラットフォーム、プラットフォーム上で実行もしくはインストールされる任意のアプリケーション、プラットフォーム上に記憶されるデータ、および／または単独のもしくは他の因子と組み合わされる構成パラメータを含むことができる。

[156]ＳａａＳ環境の発見についての例示的なシステムおよび方法が、図１３に示されている。示されるように、クライアントコンピュータは、発見機能を実行するための十分な特権を有する管理者または類似のタイプのユーザとすることができる。発見モジュールは、アプリケーション、アプレット、プラグイン、または他の形態のコードなど、クライアントデバイス上の実行可能命令として具体化され得る。いくつかの実施形態では、クライアントは、任意の組織コンピュータ上で動作し、スナップショットレポートを生成するように構成された（Ｊａｖａアプレットなどの）アプリケーションをダウンロードおよび実行することができる。加えて、システムは、組織コンピュータまたはクライアントコンピュータのバックグラウンドで動作し、ＳａａＳの連続モニタリングを可能にするサービスを使用する、連続発見のために構成され得る。

[157]システムは、任意の数の広範なＳａａＳアプリケーションおよびそれらの特徴を表すデータを記憶するためのＳａａＳアプリケーションデータベースを含むことができる。非限定的な例として、アプリケーションデータベースは、記録の中でもとりわけ、任意のプラットフォーム上で使用されることが知られている任意のＳａａＳアプリケーションについての記録を含むことができる。記録は、複数のデータソースから定期的に（例えば、毎日）更新され得る。

[158]ＳａａＳアプリケーション記録は、特定のＳａａＳおよび／またはＳａａＳアプリケーションのセキュリティレベルを定める様々なメトリックを含むことができる。非限定的な例として、記録されたメトリックは、データが暗号化されて記憶されるかどうか、ＳＳＬ暗号化レベル、ビルトインセキュリティ機能の存在の有無、データベースおよびデータセンタのロケーションなどを含むことができる。

[159]システムは、上で説明されたメトリックのいずれかに基づいて、与えられたＳａａＳプラットフォームまたはアプリケーションについてのリスク評価発見を自動的に実行するように構成され得る。クラウド・サービス・リスク発見プロセスは、ＳａａＳ環境の受動的発見および／または能動的発見を実行するための手順を実行することができる。

[160]受動的発見
[161]いくつかの実施形態では、受動的発見プロセスは、どのＳａａＳアプリケーションおよび／またはデータストアが、ユーザによってアクセスされたか、またはユーザによってアクセスされることを引き起こしたかを決定するために使用され得る。

[162]システムは、ローカル構成ドメインネームシステム（ＤＮＳ）サーバが、公的か、それとも組織的かを（パブリックＤＮＳサーバのオープンリストに基づいて）決定するように構成され得る。組織的である場合、システムは、特定のＳａａＳドメインについて企業ＤＮＳサーバに（非反復的に）問い合わせを行うことができる。応答に基づいて、システムは、特定のアプリケーション、ファイル、またはデータセットがその企業ネットワークの内部から最近アクセスされたかどうかを決定することができる。問い合わせが成功した場合、システムは、企業から最近アクセスが行われたと決定することができる。そうではなく、問い合わせが成功しなかった場合、システムは、企業から最近のアクセスが行われなかったと決定することができる。

[163]能動的発見
[164]システムは、あるＳａａＳがある組織ネットワーク内で利用可能であるかどうかをテストし、それによって、特定のＳａａＳが組織ネットワーク内でブロックされるかどうかを決定するために、ターゲットを絞った問い合わせを使用するように構成され得る。例えば、発見モジュールは、ＳａａＳ上で事前に定められたＵＲＬをフェッチしようと試みることができる。フェッチの試みが成功した場合、ＳａａＳは、ブロックされていないと標識付けされ得る。フェッチの試みが成功しなかった場合、ＳａａＳは、ブロックされていると標識付けされ得る。

[165]いくつかの実施形態では、能動的発見は、構成問題についてチェックするために使用され得る。例えば、管理者がＳａａＳストレージを構成していないことがあるにもかかわらず、ストレージが消費される。

[166]警告
[167]受動的および／または能動的発見プロセスの結果は、発見サーバまたは電子的記憶のための他のロケーションに送信され得る。結果は、自動的および／または手動分析にかけられ得る。

[168]発見プロセスの結果に基づいて、自動的警告およびクラウド使用レポートが生成され得る。例えば、週次および／または月次クラウド使用レポートが、データベース内に記憶された使用データに基づいて自動的に生成され得る。使用された新しいおよびトレンドのクラウド・サービスが、単独で、または詳細なリスク分析と一緒に示され得る。いくつかの実施形態では、高リスクのＳａａＳアプリケーション使用は、電子メールまたは他の手段による自動警告をトリガすることができる。

[169]ＳａａＳトラフィック捕捉
[170]サフィックスプロキシ実装は、クライアント側でコンテンツが動的に生成されるという問題に直面する。Ｇｏｏｇｌｅ Ａｐｐｓプラットフォームなどの最新のウェブアプリケーションは、大量のクライアント側コード（ＪａｖａＳｃｒｉｐｔ）を利用する。基本的なプロキシ機能は不十分であり、クライアント側コードにさらなる介入が必要とされるので、これは、サフィックスプロキシ実装をより一層難しくし得る。

[171]本明細書で説明されるように、サフィックスプロキシは、プロキシされたウェブページのＵＲＬおよびウェブアクセスをプロキシの保有内に保持するために使用され得る。これは、ページ上のＵＲＬにサフィックスを追加することによって行われる。静的ページ（例えば、クライアント実行可能なＪａｖａＳｃｒｉｐｔコードを含まないページ）の状況では、これは、プロキシによってサーバ側で行われ得る。方法は、ＨＴＭＬを解析し、ページ上のＵＲＬを置き換えるために正規表現を使用することを伴う。

[172]マネージド・ネットワーク・プロキシは、トラフィックを検査し、ＳａａＳインターネットアドレスを検出するように構成され得る。いくつかの実施形態では、マネージド・ネットワーク・プロキシは、（ユニフォーム・リソース・ロケータ、ユニフォーム・リソース・アイデンティファイアなどの）インターネットアドレスについてネットワークトラフィックを検査するように構成され得る。非限定的な例として、ネットワーク・プロキシは、検査のために、ネットワークトラフィックを逆コンパイルし、分解し、または逆アセンブルすることができる。マネージド・ネットワーク・プロキシは、ＳａａＳリソースに直接的にアクセスして、マネージド・ネットワーク・プロキシをバイパスするようにクライアントデバイスに指示するユーザデバイスに、ネットワークアドレスが提供されないように、クライアントデバイスとＳａａＳプロバイダとの間のネットワークトラフィックを変更するように構成され得る。ＳａａＳインターネットアドレスが検出された場合、そのアドレスは、ネットワーク・プロキシ・サービスのためのドメイン名を元のネットワークアドレスに追加することによって、ネットワーク・プロキシにおいて、あるアドレスに書き換えられ得る。

[173]サフィックスプロキシは、以降の要求がサフィックスプロキシによって取り扱われるように、ＳａａＳサーバ応答を処理することによって、捕捉ページ処理のために構成され得る。処理は、ファイルタイプおよび応答タイプに依存し得る。非限定的な例として、処理されるファイルタイプは、ＨＴＭＬまたはＪａｖａＳｃｒｉｐｔを含むことができ、応答は、ｇｚｉｐ圧縮された応答またはチャンク化された応答を含むことができる。サフィックスプロキシは、ＳａａＳプロバイダから送信された、ウェブページを含む、任意のコンテンツをエミュレートするように構成され得る。サフィックスプロキシは、任意のコンテンツを検査および／または逆コンパイルして、コンテンツ内に存在する任意の参照ページおよび／またはＵＲＬを識別し、それらのＵＲＬを書き換えるように構成され得る。

[174]いくつかのケースでは、検査は、クライアントとＳａａＳプロバイダとの間で転送されるコードまたはスクリプトを実行することを必要とする。例えば、ＳａａＳプロバイダに直接的にアクセスするネットワークアドレスの生成を検出するために、ＪａｖａＳｃｒｉｐｔが、ネットワーク・プロキシにおいてエミュレートされ得る。コンテンツ内で直接アクセスアドレスが識別された場合、ネットワーク・プロキシを参照するようにアドレスを書き換えるために、コンテンツが変更され得る。

[175]インタイムＪａｖａＳｃｒｉｐｔ変換を使用するプロキシ
[176]クライアント側ＪａｖａＳｃｒｉｐｔを用いて、ページのドキュメント・オブジェクト・モデル（ＤＯＭ）に対するランタイム変更が可能であり、結果として、クライアントブラウザが、サフィックス付けされないＵＲＬを有する（サーバ側プロキシはそれらを置き換える機会を有さないので）ＤＯＭ要素を生成または変更することが可能である。ウェブアプリケーションのＪａｖａＳｃｒｉｐｔコードがＤＯＭにアクセスすることを制限するためのシステムおよび方法が、以下で説明される。

[177]制限の性質は、ＤＯＭ内のウェブＵＲＬに対する元のＪａｖａＳｃｒｉｐｔコードからの変更が、プロキシのランタイム構成要素によって監視されるようなものとすることができる。キャッシングを用いて、ＪａｖａＳｃｒｉｐｔコードのランタイム実行に対するどのような影響も低減され得る。

[178]ＵＲＬのＤＯＭへの書き込みはサフィックス付けされ、ＵＲＬのＤＯＭからの読み取りはサフィックス付けされないような、ＤＯＭ要素に対する読み取りおよび書き込みアクセスのために、モニタリングコードが起動され得る。結果として、「ユーザ」ＪａｖａＳｃｒｉｐｔコード（例えば、ウェブアプリケーション・コード）によって見られるＵＲＬと、ブラウザ自体（ＤＯＭおよびそれを表すＪａｖａＳｃｒｉｐｔ）によって見られるＵＲＬとの間に分離が存在し得る。結果として、元のＪａｖａＳｃｒｉｐｔコードは、（プロキシを迂回する）元のサーバとの通信が阻止されるように、プロキシ環境内で効果的に維持され得る。

[179]サーバ側プロキシ実装
[180]ウェブアプリケーションの一部としてロードされるＪａｖａＳｃｒｉｐｔコードは、（通常はコンテンツ・タイプが「ｔｅｘｔ／ｊａｖａｓｃｒｉｐｔ」である）ＨＴＭＬページおよびＪａｖａＳｃｒｉｐｔファイル内部のインラインスクリプトを含むいくつかの形式のいずれかで、元のサーバから獲得され得る。本明細書で説明されるシステムは、ＣＳＳなどの他のタイプのコード、スクリプト、またはコンテンツ上で動作するようにも構成され得る。

[181]一般に、ブラウザは、最初に、メインＨＴＭＬページをロードし、次に続いて、すべての参照およびインラインスクリプトをロードする。さらなるＪａｖａＳｃｒｉｐｔ（またはスクリプトを含むＨＴＭＬ）も、例えば、「ｅｖａｌ」ステートメントを使用して、ウェブアプリケーションによって動的にロードされ得る。

[182]動的コードローディングは、静的にロードされたコード（またはかつてロードされた他の動的コード）によって最初に実行されるので、システムは、プロキシサーバ上でページ・ダウンロード・ステージの間に静的ＪａｖａＳｃｒｉｐｔコードを変更することによって、実行の制御を行うことができる。コードに対する変更は、上述されたルールを実施するために、途中で捕えられ得るＤＯＭに対するランタイムおよび特定の変更の間に、将来動的にロードされるコードが変更されるように実行され得、それが、ページをプロキシの制御下にとどめることを可能にする。

[183]動的にロードされるコードの変更は、動的に評価されたコードをプロキシに送信し、または動的に評価されたコードを処理のためにプロキシにおいて受信し、その後、新しいコードがクライアントブラウザにおいてロードされることを可能にすることによって達成され得る。キャッシュが行われない動作の例示的な方法が、図１４に示されている。いくつかの実施形態では、以下でより詳細に説明され、図１５に示されるように、性能を改善するために、キャッシングが利用され得る。

[184]非限定的な例として、少なくとも以下のＤＯＭ要素およびプロパティがラップされ得る。

[185]１．ＵＲＬを含むＨＴＭＬ要素のプロパティ：
ａ．要素：「ＩＦＲＡＭＥ」、「ＳＴＹＬＥ」、「ＬＩＮＫ」、「ＩＭＧ」、「ＡＵＤＩＯ」、「Ａ」、「ＦＯＲＭ」、「ＢＡＳＥ」、および「ＳＣＲＩＰＴ」。

ｂ．それらが適用される場合、各１つについて、プロパティ：「ｓｒｃ」、「ｈｒｅｆ」、「ａｃｔｉｏｎ」。

ｃ．上述されたプロパティを設定するために、これらの要素のｇｅｔＡｔｔｒｉｂｕｔｅおよびｓｅｔＡｔｔｒｉｂｕｔｅメソッドも使用され得る。

[186]２．ＤＯＭサブツリーを含み得るＨＴＭＬ要素のプロパティ（すなわち、さらなるＨＴＭＬ）：
ａ．要素（およびコード）を動的に追加するために、「ａｐｐｅｎｄＣｈｉｌｄ」メソッドが使用され得る。

ｂ．追加のコードを追加するために、「ｉｎｎｅｒＨＴＭＬ」プロパティが使用され得る。

[187]３．ＵＲＬまたはホスト名を含む「ｄｏｃｕｍｅｎｔ」オブジェクトのプロパティ：
ａ．「ｃｏｏｋｉｅ」、「ｄｏｍａｉｎ」−両方ともウィンドウの原領域を含むことができる。

ｂ．要素およびコードをページに追加するために、「ｗｒｉｔｅ」メソッドが使用され得る。

[188]４．ＸＭＬＨｔｔｐＲｅｑｕｅｓｔオブジェクトの「ｏｐｅｎ」メソッドは、要求ＵＲＬを含む。

[189]５．「ＭｅｓｓａｇｅＥｖｅｎｔ」オブジェクトの「ｏｒｉｇｉｎ」プロパティは、原ホスト名を含む。

[190]６．「Ｗｉｎｄｏｗ」オブジェクトのメソッドおよびプロパティ：
ａ．「ｌｏｃａｔｉｏｎ」−フレームを別のＵＲＬにリダイレクトすること、またはフレームの現在のロケーションを決定することができる。

ｂ．「ｐｏｓｔＭｅｓｓａｇｅ」メソッド−原引数を有する。

ｃ．「ｅｖａｌ」および「ｅｘｅｃＳｃｒｉｐｔ」−コードを動的にロードするために使用される。

[191]他のそのような要素およびプロパティが存在し、それらのいずれかまたはすべてがラップされ得る。

[192]ＪａｖａＳｃｒｉｐｔコードの静的フッキング
[193]インラインスクリプトおよびファイルを含む複数のタイプのコンテンツのために、静的フッキングが使用され得る。プロキシサーバでは、プロキシされたＪａｖａＳｃｒｉｐｔコードが、以下のように処理され得る。

[194]１．ＨＴＭＬ内のインラインスクリプトが抽出および処理される。

[195]２．オープンソースの解析ライブラリを使用するＭｏｚｉｌｌａパーサＡＰＩ仕様に従って、コードが抽象シンタックスツリー（ＡＳＴ）に変換される。

[196]３．ＡＳＴが再帰的に走査され、フッキングを可能にするためにＡＳＴのあるノードの周辺にラッパに対する呼び出しが挿入される。

[197]４．コードが、パッチされたＡＳＴから再構築され、クライアントブラウザに送信され得る。

[198]５．結果の処理されたコードのキャッシングが実行され得る。

[199]挿入されたラッパは、ＤＯＭ変更がランタイム中に捕えられることを可能にし得る。ラッパは、いずれかまたはすべての潜在的なＤＯＭアクセスを覆うように適用され得る。

[200]非限定的な例として、ラッパは、以下のＡＳＴノードのいくつかまたはすべてに適用され得る。

[201]１．ＭｅｍｂｅｒＥｘｐｒｅｓｓｉｏｎ：
ａ．ＤＯＭオブジェクトのオブジェクトプロパティに対する潜在的なアクセスがラップされる。

ｂ．非リテラルキーを用いるサブスクリプション操作がラップされる。

ｃ．プロパティ名が「興味深い」プロパティのホワイトリストに一致する場合、特定のプロパティ（例えば、ｏｂｊ．ｓｒｃ）に対するアクセスがラップされる。

ｄ．最終的に、ランタイムラッパは、いずれかの変更が必要であるかどうかを決定する。ほとんどの場合、例えば、「フォールスポジティブ」の場合、ラッパは、何もしないと決定する。

[202]２．Ｉｄｅｎｔｉｆｉｅｒ：
ａ．（ｗｉｎｄｏｗ ＤＯＭオブジェクトのプロパティ、例えば、「ｌｏｃａｔｉｏｎ」である）グローバルＩｄｅｎｔｉｆｉｅｒのホワイトリストに対する潜在的なアクセスがラップされる。

ｂ．Ｉｄｅｎｔｉｆｉｅｒ ＡＳＴノードは、ツリー内の多くの無関係の論理位置に出現し得る。Ｉｄｅｎｔｉｆｉｅｒがグローバル変数に対するアクセスを表すインスタンスがラップされる。これは、ペアレントノードをチェックし、他のすべてのケースを排除することによって、走査ステージ中に決定される。

[203]３．ＡｓｓｉｇｎｍｅｎｔＥｘｐｒｅｓｓｉｏｎ：
ａ．それまでに「標識付けされた」ＭｅｍｂｅｒＥｘｐｒｅｓｓｉｏｎおよびＩｄｅｎｔｉｆｉｅｒに対する代入が、「ｓｅｔ」アクセスを特に取り扱う別のラッパによって取り扱われる。

ｂ．関連するＤＯＭプロパティは文字列（ＵＲＬ）であり得るので、「＝」および「＋＝」代入演算子がラップされる。

[204]４．ＣａｌｌＥｘｐｒｅｓｓｉｏｎ：
ａ．それまでに「標識付けされた」ＭｅｍｂｅｒＥｘｐｒｅｓｓｉｏｎまたはＩｄｅｎｔｉｆｉｅｒが呼び出される側である場合のＣａｌｌＥｘｐｒｅｓｓｉｏｎが、関数呼び出しを特に取り扱う別のラッパによって取り扱われる。

ｂ．ステートメントのように振る舞うが、ＡＳＴ内で関数呼び出しとして表される、「ｅｖａｌ」に対する呼び出しを有する特別なケースが存在する。

[205]ラッピング前後の例示的なコード：

[206]ラッパのランタイム挙動
[207]いくつかの異なるラッパ機能が、（ＡＳＴ走査フェーズ中の異なるラッピングケースに従って）定義され得る。

[208]１．ｗｒａｐｐｅｄ＿ｇｅｔ、ｗｒａｐｐｅｄ＿ｓｅｔ、ｗｒａｐｐｅｄ＿ｃａｌｌ−異なる使用ケースに従ったＭｅｍｂｅｒＥｘｐｒｅｓｓｉｏｎへのアクセスをラップする。

[209]２．ｗｒａｐｐｅｄ＿ｎａｍｅ＿ｇｅｔ、ｗｒａｐｐｅｄ＿ｎａｍｅ＿ｓｅｔ、ｗｒａｐｐｅｄ＿ｎａｍｅ＿ｃａｌｌ−異なる使用ケースに従ったグローバルＩｄｅｎｔｉｆｉｅｒへのアクセスをラップする。

[210]３．ｗｒａｐｐｅｄ＿ｅｖａｌ＿ｐａｒａｍ−（ローカル範囲に影響し得る）「ｅｖａｌ」呼び出しのパラメータとして渡されるコードを特に取り扱う。

[211]いくつかの実施形態では、システムは、関連するオブジェクトまたはプロパティに対してラッパが起動されたかどうかを最初に検出することができる。

[212]１．「ＭｅｍｂｅｒＥｘｐｒｅｓｓｉｏｎ」ラッパでは、サブスクリプトされたオブジェクトばかりでなく、プロパティ名もホワイトリストと照合される。

[213]２．「Ｉｄｅｎｔｉｆｉｅｒ」ラッパを用いる場合も、ホワイトリストが同様に調べられる。

[214]３．オブジェクトは、あるタイプ（「Ｄｏｃｕｍｅｎｔ」、「Ｗｉｎｄｏｗ」、およびＨＴＭＬ要素など）に属することが決定され、適用可能な場合、グローバルインスタンスとも比較される。

[215]これらの比較および検索は、多くの場合、性能に著しい影響を与えずに、効率的に実行され得る。

[216]ラッパ呼び出しは、非限定的な例として、以下のものを含む、様々な手順のいずれか１つを使用して処理され得る。

[217]１．動的にロードされるコードを処理する。

ａ．以下で説明されるように、変換およびキャッシングのために、新しいＪａｖａＳｃｒｉｐｔコードが、プロキシの特別なＲＥＳＴ ＡＰＩエンドポイントに送信される。

ｂ．これは、「ａｐｐｅｎｄＣｈｉｌｄ」、「ｉｎｎｅｒＨＴＭＬ」、「ｅｖａｌ」、「ｅｘｅｃＳｃｒｉｐｔ」、および「ｗｒｉｔｅ」のラッパにおいて発生し得る。

[218]２．ＵＲＬまたはホスト名にサフィックス付けする、またはサフィックス付けしない。

[219]３．フォールスポジティブなラッパ起動を検出し、通常実行を再開する。

[220]ＵＲＬ関連のプロパティまたはメソッドに対するＤＯＭアクセスを取り扱うことを担うラッパハンドラは、例えば、以下の論理グループに分類され得る。

[221]１．ｇｅｔｔｅｒ−「ｇｅｔ」ラッパを取り扱う。これらは、取り扱われるＵＲＬにサフィックス付けしない。

ａ．メソッド（ＪａｖａＳｃｒｉｐｔタイプの「関数」）がアクセスされる場合、「ｄｅｃｏｒａｔｏｒ」が返される（以下を参照）。

[222]２．ｓｅｔｔｅｒ−これらは、「ｓｅｔ」ラッパを取り扱う。それらは、割り当てられたＵＲＬにサフィックス付けする。

[223]３．ｄｅｃｏｒａｔｏｒ−これらは、「ｃａｌｌ」ラッパを取り扱う。それらは、デコレートされるメソッドが何であるかに従って、ＵＲＬにサフィックス付けする、またはサフィックス付けしない、ラップされたメソッドのための一致するｄｅｃｏｒａｔｏｒ関数を返す。

ａ．このｄｅｃｏｒａｔｏｒは、ＪａｖａＳｃｒｉｐｔの「ｂｉｎｄ」メソッドを使用して、正しいオブジェクトにバインドされ得る。「Ｉｄｅｎｔｉｆｉｅｒ」ラッパの場合、正しいオブジェクトは、グローバルオブジェクト（いくつかのケースでは、ｗｉｎｄｏｗ）である。「ＭｅｍｂｅｒＥｘｐｒｅｓｓｉｏｎ」ラッパの場合、これは、サブスクリプトされるオブジェクトである。

[224]性能上の影響および最適化
[225]いくつかのケースでは、ＪａｖａＳｃｒｉｐｔ ＪＩＴコンパイラがブラウザにおいてコードを最適化することを妨げる、大きなスクリプトおよびランタイムラッパ上でのＪａｖａＳｃｒｉｐｔ変換およびＡＳＴ走査に起因する、そのいくつかがプロキシされたウェブアプリケーションのユーザによって経験され得る、本明細書で説明されるプロセスの実行からこうむる性能上の影響が存在し得る。

[226]変換フェーズのオーバヘッドを改善するために、キャッシュが実装され得る。

[227]１．サーバ側では、変換されたＪａｖａＳｃｒｉｐｔコードの要素（例えば、インラインスクリプト、ファイル、または動的変換要求）が、サーバ毎にローカルにキャッシュされる。

[228]２．エントリは、元のコードの暗号ハッシュによって鍵をかけられる。

[229]３．したがって、キャッシュは、プロキシのユーザの間で共用される。このようにすることで、サーバ毎に最初のユーザだけが、共通でロードされるスクリプトのための変換フェーズの影響を経験する。

[230]４．動的スクリプト変換ＲＥＳＴエンドポイントは、クライアント側で計算されたハッシュを受け入れ、それを使用してキャッシュ内での検索を実行するようにも構成され得る。これは、プロキシのユーザのためのアップロード帯域幅の使用を低減することができる。この構成では、動的に生成されるスクリプトは、（初回を除いて）実際にはほとんどプロキシに送信されなくてよい。

[231]５．加えて、（ハッシュ毎の）動的変換要求に対する応答が、結果がクライアントのブラウザによってキャッシュされるように、「Ｃａｃｈｅ−Ｃｏｎｔｒｏｌ」および「Ｅｘｐｉｒｅｓ」ＨＴＴＰヘッダを用いて返される。この方法では、クライアントが、同じ動的に生成されたスクリプトを求めて、プロキシサーバに２回以上の問い合わせを行う必要が生じる可能性は低い。

[232]上の最適化が与えられた場合、変換フェーズの影響は、通常の使用ケースから大幅に低減させることができる。

[233]ラッパのランタイム実行の影響は、以下のいくつかまたはすべてによって軽減され得る。

[234]１．（コードレベルで）無関係／フォールスポジティブなラッパ起動についての最適化された高速経路を作成すること。これは、ブラウザのＪＩＴコンパイラによって容易に最適化されるＪａｖａＳｃｒｉｐｔの制限されたサブセットを用いて基本ラッパ機能を書くことによって達成される。

[235]２．最多のキャッシュヒットを有するコード経路のプロファイリングおよび検出を可能にし、プロキシの内部キャッシュ内の変換されたコードからあるラッパを（手動で）取り除くことを可能にする人的保守インターフェース。

[236]システム実施
[237]本明細書で説明されるシステムおよび方法は、ソフトウェア、ハードウェア、またはそれらの任意の組合せで実装され得る。本明細書で説明されるシステムおよび方法は、物理的または論理的に互いに分離されてもよく、または分離されなくてもよい、１つまたは複数のコンピューティングデバイスを使用して実施され得る。加えて、本明細書で説明される方法の様々な態様は、他の機能に組み合わされても、または合併されてもよい。

[238]いくつかの実施形態では、システム要素は、組み合わせて単一のハードウェアデバイスにすること、または分離して複数のハードウェアデバイスにすることができる。複数のハードウェアデバイスが使用される場合、ハードウェアデバイスは、物理的に互いに近接して、または互いに遠く離して配置され得る。

[239]方法は、コンピュータまたは任意の命令実行システムによって使用するための、またはそれらと関連があるプログラムコードを提供する、コンピュータ使用可能またはコンピュータ可読記憶媒体から入手可能なコンピュータプログラム製品において実装され得る。コンピュータ使用可能またはコンピュータ可読記憶媒体は、コンピュータ、または命令実行システム、装置、もしくはデバイスによって使用するための、またはそれらと関連があるプログラムを格納または記憶することができる、任意の装置とすることができる。

[240]対応するプログラムコードを記憶および／または実行するのに適したデータ処理システムは、メモリ要素などのコンピュータ制御のデータ記憶デバイスに直接的または間接的に結合された、少なくとも１つのプロセッサを含むことができる。（限定することなく、キーボード、ディスプレイ、ポインティングデバイスなどを含む）入力／出力（Ｉ／Ｏ）デバイスが、システムに結合され得る。データ処理システムが、介在するプライベートまたはパブリックネットワークを通して、他のデータ処理システム、またはリモートプリンタもしくは記憶デバイスに結合されることを可能にするために、ネットワークアダプタも、システムに結合され得る。ユーザとの対話を可能にするために、ＣＲＴ（ブラウン管）、ＬＣＤ（液晶ディスプレイ）、またはユーザに情報を表示するための別のタイプのモニタなどの表示デバイス、キーボード、およびユーザがそれによってコンピュータに入力を提供することができるマウスまたはトラックボールなどの入力デバイスを用いる機能が、コンピュータ上で実装され得る。

[241]コンピュータプログラムは、コンピュータ内で直接的または間接的に使用され得る１組の命令とすることができる。本明細書で説明されるシステムおよび方法は、Ｐｅｒｌ、Ｐｙｔｈｏｎ、ＪＡＶＡ（商標）、Ｃ＋＋、Ｃ、Ｃ＃、Ｖｉｓｕａｌ Ｂａｓｉｃ（商標）、ＪａｖａＳｃｒｉｐｔ（商標）、ＰＨＰ、Ｆｌａｓｈ（商標）、ＸＭＬ、ＨＴＭＬなどのプログラミングおよび／もしくはマークアップ言語、またはコンパイル型もしくはインタープリタ型言語を含むプログラミングおよび／もしくはマークアップ言語の組合せを使用して実装され得、スタンドアロンプログラム、またはモジュール、コンポーネント、サブルーチン、もしくはコンピューティング環境における使用に適した他のユニットを含む任意の形態で配備され得る。ソフトウェアは、限定することなく、ファームウェア、常駐ソフトウェア、マイクロコード、などを含むことができる。プログラミングモジュール間のインターフェースを実装する際には、ＳＯＡＰ／ＨＴＴＰ、ＪＳＯＮ、ＳＱＬなどのプロトコルおよび規格が使用され得る。本明細書で説明されるコンポーネントおよび機能は、限定することなく、Ｍｉｃｒｏｓｏｆｔ（商標） Ｗｉｎｄｏｗｓ（商標）、Ａｐｐｌｅ（商標） Ｍａｃ（商標）、ｉＯＳ（商標）、Ｕｎｉｘ（商標）／Ｘ−Ｗｉｎｄｏｗｓ（商標）、Ｌｉｎｕｘ（商標）などの様々なバージョンを含む、ソフトウェア開発に適した任意のプログラミング言語を使用して、仮想または非仮想環境において動作する任意のデスクトップまたはサーバのオペレーティングシステム上で実装され得る。

[242]いくつかの実施形態では、１つまたは複数のサーバは、ファイルサーバとして機能することができ、ならびに／またはユーザコンピュータおよび／もしくは別のサーバ上で動作するアプリケーションによって具体化される本発明の方法を実装するために使用されるファイルの１つもしくは複数を含むことができる。代替として、ファイルサーバは、いくつかのまたはすべての必要なファイルを含むことができ、そのようなアプリケーションが、ユーザコンピュータおよび／またはサーバによってリモート起動されることを可能にする。本明細書で様々なサーバ（例えば、アプリケーションサーバ、データベースサーバ、ウェブサーバ、ファイルサーバなど）に関して説明される機能は、実装固有の必要性およびパラメータに応じて、単一のサーバおよび／または複数の専門サーバによって実行され得る。

[243]いくつかの実施形態では、システムは、１つまたは複数のデータベースを含むことができる。データベースのロケーションは、任意に決定することができる。非限定的な例として、データベースは、サーバ（および／またはユーザコンピュータ）から見てローカルな（および／またはその中に常駐する）記憶媒体上に常駐することができる。代替として、データベースは、コンピューティングデバイスのいずれかまたはすべてから見て、これらの１つまたは複数と（例えば、ネットワークを介して）通信することができる限り、リモートとすることができる。いくつかの実施形態では、データベースは、ストレージエリアネットワーク（ＳＡＮ）内に常駐することができる。ＳＡＮは、コンピュータ制御のデータ記憶デバイスのグループとして実装され得る。コンピュータに帰せられる機能を実行するために必要なファイルのいくつかまたはすべては、適宜、それぞれのコンピュータ上にローカルに、および／またはリモートに記憶され得る。いくつかの実施形態では、データベースは、ＳＱＬ形式のコマンドに応答してデータを記憶し、更新し、検索するように適合された、Ｏｒａｃｌｅデータベースなどのリレーショナルデータベースとすることができる。データベースは、データベースサーバによって制御および／または維持され得る。

[244]命令からなるプログラムの実行のために適したプロセッサは、限定することなく、任意の種類のコンピュータの汎用および専用マイクロプロセッサ、ならびに単一のプロセッサ、または複数のプロセッサもしくはコアのうちの１つを含む。プロセッサは、リードオンリーメモリ、ランダムアクセスメモリ、両方、または本明細書で説明されるデータ記憶デバイスの任意の組合せなどの、コンピュータ制御のデータ記憶デバイスから命令およびデータを受け取り、記憶することができる。プロセッサは、電子デバイスの動作および実行を制御するように動作可能な任意の処理回路または制御回路を含むことができる。

[245]プロセッサは、データを記憶するための１つまたは複数のデータ記憶デバイスも含むことができ、またはそれらと通信するように動作可能に結合され得る。そのようなデータ記憶デバイスは、非限定的な例として、（内蔵ハードディスクおよび着脱可能ディスクを含む）磁気ディスク、光磁気ディスク、光ディスク、リードオンリーメモリ、ランダムアクセスメモリ、ならびに／またはフラッシュ記憶を含むことができる。コンピュータプログラム命令およびデータを有形に具体化するのに適した記憶デバイスは、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイスなどの半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気ディスク、光磁気ディスク、ならびに／またはＣＤ−ＲＯＭおよびＤＶＤ−ＲＯＭディスクを含む、不揮発性メモリのすべての形態も含むことができる。プロセッサおよびメモリは、ＡＳＩＣ（特定用途向け集積回路）によって補完され、またはその中に組み込まれ得る。

[246]本明細書で説明されるシステム、モジュール、および方法は、ソフトウェア要素またはハードウェア要素の任意の組合せを使用して実装され得る。本明細書で説明されるシステム、モジュール、および方法は、単独でまたは互いに組み合わさって動作する１つまたは複数の仮想マシンを使用して実装され得る。物理コンピューティング・マシン・プラットフォームをカプセル化して、ハードウェア・コンピューティング・プラットフォームまたはホスト上で動作する仮想化ソフトウェアの制御下で実行される仮想マシンにするために、任意の適用可能な仮想化ソリューションが使用され得る。仮想マシンは、仮想システム・ハードウェアとゲスト・オペレーティングシステム・ソフトウェアの両方を有することができる。

[247]本明細書で説明されるシステムおよび方法は、データサーバなどのバックエンドコンポーネントを含む、またはアプリケーションサーバもしくはインターネットサーバなどのミドルウェアコンポーネントを含む、またはグラフィカルユーザインターフェースを有するクライアントコンピュータ、もしくはインターネットブラウザ、もしくはそれらの任意の組合せなどのフロントエンドコンポーネントを含む、コンピュータシステムにおいて実装され得る。システムのコンポーネントは、通信ネットワークなど、任意の形態または媒体のデジタルデータ通信によって接続され得る。通信ネットワークの例は、限定することなく、ＬＡＮ、ＷＡＮ、またはインターネットを形成するネットワークのいずれかを含む。

[248]本発明の１つまたは複数の実施形態は、ハンドヘルドデバイス、マイクロプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な家電製品、ミニコンピュータ、メインフレームコンピュータなどを含む、他のコンピュータシステム構成を用いて実践され得る。本発明は、ネットワークを通して結び付けられたリモート処理デバイスによってタスクが実行される、分散コンピューティング環境においても実践され得る。

[249]本発明の１つまたは複数の実施形態が説明されたが、それらの様々な代替、追加、置換、および均等物が、本発明の範囲内に含まれる。

Claims (4)

1. コンテンツを求める将来の要求を変更するために命令を処理するための方法であって、
   プロキシサーバにおいて、コンテンツを求める要求を受信するステップであって、前記コンテンツは実行可能命令を含む、ステップと、
   要求された前記コンテンツをサーバから取り出し、要求された前記コンテンツを前記プロキシサーバに記憶するステップと、
   ＵＲＬを生成するように構成された実行可能命令を識別するために、要求された前記コンテンツを解析するステップと、
   代替命令を呼び出すために、識別された前記命令をラップすることによって、要求された前記コンテンツを変更するステップであって、前記代替命令は、サフィックスプロキシの識別情報を生成された前記ＵＲＬに追加するように構成された、ステップと、
   前記プロキシサーバにおいて、ラップされた前記命令を含む変更された前記コンテンツを記憶するステップと、
   ラップされた前記命令を含む変更された前記コンテンツをクライアントデバイスに送信するステップと
   を含む方法。
2. 請求項１に記載の方法であって、前記プロキシサーバは、サフィックスプロキシとして構成された、方法。
3. 請求項１に記載の方法であって、前記コンテンツは、ＪａｖａＳｃｒｉｐｔを含む、方法。
4. 請求項１に記載の方法であって、
   ラップされた前記命令を含むように変更された、要求された前記コンテンツが、前記プロキシサーバに記憶されているかどうかを判定するステップと、
   ラップされた前記命令を含むように変更された、要求された前記コンテンツが、前記プロキシサーバに記憶されている場合、要求された前記コンテンツを前記サーバから取り出すことなく、変更された前記コンテンツを前記クライアントデバイスに送信するステップと
   をさらに含む方法。