概要

ArcGIS Server では、Web 層での認証（統合 Windows 認証、PKI、HTTP 基本認証／ダイジェスト認証）と、GIS 層での認証（ArcGIS Server トークン認証）をサポートします。Web 層または GIS 層の認証は、どちらか一つを選ぶ必要があり、両者を組み合わせて使用することはできません。

より高度なセキュリティが要求される場合には Web 層での認証方式が推奨されます。GIS 層の認証は、Web Adaptor ではないロード バランサを必要とする構成や、Web サーバに組み込むことができないユーザ ストア（ArcGIS Server 組み込みのユーザ ストアなど）を使用する場合など、よりセキュアではない環境下でも使うことができます。

この FAQ では、GIS 層で使われるトークン認証がどのように機能するか、どのように構成するべきかを説明します。

ArcGIS Server トークン認証について

ArcGIS Server で GIS 層の認証を利用する設定を行った場合、クライアント アプリケーションは入力ダイアログなどを通してユーザからユーザ名とパスワードを取得します。次にクライアント アプリケーションは ArcGIS Server にユーザ名／パスワードを送信し、代わりにトークンを受け取ります。それ以降の ArcGIS Server へのリクエストにはトークンを付与し、ユーザ名／パスワードは不要となります。

ArcGIS Server が適切に構成されていない場合、トークンの使用にはセキュリティ リスクが生じます。以下に、それらのリスクおよび対応策を示します。

• リスク 1 : ユーザ名／パスワードの漏洩
  Esri のクライアント アプリケーションや API は、HTTPS が有効にされていればユーザ名およびパスワードを HTTPS で送信します。HTTPS が有効になっていない場合、ユーザ名／パスワードは平文のままネットワーク上を送信されてしまいます。GIS 層の認証を行う場合、ArcGIS Server で HTTPS を有効にすることを強く推奨します。HTTPS はデフォルトでは有効になっていません。
• リスク 2 : リプレイ攻撃
  リプレイ攻撃はネットワーク トラフィックを盗聴し、不正に取得したトークンなどの情報を再利用し、悪意ある接続に使用する攻撃方法です。ArcGIS Server トークンを盗聴した攻撃者は、（トークンの有効期限の間）トークンを生成したユーザになりすますことができてしまいます。
  
  リプレイ攻撃への対応策として最も強力なのは、すべての通信に HTTPS を用いることです。HTTPS では、ArcGIS Server とのすべての通信が暗号化されます。
  
  他に、ArcGIS Server の設定でリプレイ攻撃によるリスクを低減させる方法もあります。ArcGIS Server は短期あるいは長期のトークンを発行できます。長期トークンは HTTP リファラや特定の IP アドレスに紐付けられたものとなります。トークンが IP アドレスに紐づいている場合、その IP アドレスからのリクエストでなければリクエストは受け入れられません。つまり、異なる IP アドレスを持つ別のマシンから発行されたリプレイ攻撃は失敗することになります。トークンがリファラに紐付けられている場合は、リクエストの HTTP ヘッダに特定のリファラが設定されていなければトークンが拒否されます。クライアント アプリケーションはリファラか IP アドレスのどちらかを使うことができますが、リファラの場合はセキュリティが低下する場合があるので推奨されません。
  
  短期トークンでは、有効期間の短さがリプレイ攻撃を難しくするため、IP アドレスやリファラとの紐付けが不要です。短期トークンで作成可能な有効期間の最大値はデフォルト 60 分ですが、ArcGIS Server の設定で変更可能です。
• リスク 3 : トークンの取得方法にまつわるリスク
  トークンは HTTP GET もしくは HTTP POST によって取得できます。POST の利用は GET よりもセキュリティが高くなります。GET によるリクエストは、ネットワーク機器のログやブラウザの履歴にユーザ名／パスワードを残すためです。ArcGIS API はトークンの取得に POST を使います。しかし、スクリプトからの利用など利便性のために、トークンは GET でも取得できるようになっています。トークンの取得に GET を用いる場合は、その取得を事体をセキュリティの確保された環境で実施することを推奨します。