アプリケーション、マップ、または Web サービスが、パブリック (インターネットに接続され、匿名でアクセス可能な) Web サイトまたはアプリケーションを通じて (通常はパブリック ユーザーに対して) 利用可能になる場合、このアクセスを適切にセキュリティーで保護する方法が問題になります。 組織では、認証や設定済みのアカウントを必要としない簡単なアクセスを、一般ユーザーに提供したいと考えています。 当然のことながら、これらのエンド ユーザーがデータを誤用、不正アクセス、維持しないようにもしたいはずです。
ほとんどの Web ベースのワークフローでは、クライアント (多くの場合は Web ブラウザー) は Web サーバーの情報を要求します。通常はマップ イメージ、空間フィーチャと属性のセット、ラスターまたはベクター マップ タイルなどの情報です。 これらのリクエストでは、クライアントに送り返される応答が生成されます。このデータの一部または全体がユーザーのクライアント デバイスに移動し、インジケーターや画像のレンダリング、目的のマップ エクスペリエンスの提供に使用されます。 データ アクセスに関する検討事項は、一般的なサービスの種類に沿って提供されます。
マップ イメージ レイヤー (ダイナミック マップ サービスとも呼ばれる) にアクセスする場合、応答の画像には、特定のカートグラフィック構成のデータを表すピクセルのみが含まれます。 これはサーバー上で生成され、画像としてクライアントに返されます。 マップ サービスは、このタイプのダイナミック マップ イメージのみを許可するように構成できます。 これは、マップ サービスのクエリー機能を無効にすることで行われます。 これによって、個々のデータ レコードがクライアントに共有されるのを防ぐことができます。 ただし、この構成では機能が低下する可能性があるため、単純なマップ表示で十分な場合にのみ考慮する必要があります。
フィーチャ レイヤーは、マップまたはフィーチャ サービスから作成できます。 これらは、ジオメトリーや属性などのフィーチャ データをサーバーからクライアントに返し、クライアント ブラウザーでレンダリングする必要があるという点で、マップ イメージ レイヤーとは異なります。 パブリックにアクセス可能なフィーチャ レイヤーは、データのチャンクをクライアントに絶えず送信しています。これは、サーバーからの特定の地理的範囲またはフィーチャのセットに対するリクエストである場合があります。 アプリケーションがフィーチャ レイヤーを使用する場合、データは適切にレンダリングするためにクライアントによってダウンロードされます。 フィーチャ レイヤーは、このクライアントへのデータ転送に_依存_しているため、「ユーザーがデータをダウンロードしないようにしたい」などの要件は、フィーチャ レイヤーに依存するアプリやワークフローと機能的に互換性がありません。
イメージ サービスを使用すると、ユーザーは特定の範囲を動的にリクエストしてイメージを生成できます。 元のイメージ解像度は、サービスが許可するイメージの最大サイズまで、データの実際のラスター表現を返すことができます。 これらのイメージは、Web、デスクトップ、モバイル クライアントなどのクライアントにもダウンロードされ、実際には、データのサブセットをクライアントに直接共有します。 イメージ サービスは、デフォルトでは有効になっていないダウンロード機能もサポートしており、元のイメージまたは変換された形式でのダウンロードを許可できます。 この機能は、アプリの機能に特に必要でない限り、通常は無効にする必要があります。
上記のサービス タイプでは、マップ イメージ レイヤーのシナリオでのみ、データをユーザー アクセスに真に制限できます。 データの送信はレンダリングされたイメージを介して行われるため、属性や特定のジオメトリーは使用できません。
データやサービスが公開されるときに、ユーザー数や公開範囲を減らすために、サービスにある程度の制限を適用する方法があります。
リファラーベースの制限は、データ使用量を制限するための一般的なパターンの 1 つです。 これには、リバース プロキシーか、他のタイプのプロキシー (サービスに対する個々の HTTP リクエストを検査し、許可リストに一致する値を持つ Referrer HTTP リクエスト ヘッダーを提供しないリクエストを拒否できるプロキシー) が必要です。 慣例により、すべてのブラウザーは、別のドメインからリソースを要求するアプリケーションからこのリクエスト ヘッダーを生成して送信します。そのため、ブラウザーベースのトラフィックを信頼性の高い方法で制御することができます。
これは一部の誤用を阻止するには効果的な方法ですが、データを完全に_セキュリティー保護_することはできません。参照元ヘッダーは意図を持った当事者によって簡単に偽装されたり、スクリプト化されたリクエストやプログラムによるリクエストに追加され、リクエストがプロキシーを通過することがあるからです。 ArcGIS Location Platform API キーは、リファラー ヘッダー内の特定のドメインのみをサポートするようにスコープを設定できます。同様に、そのドメイン上のアプリケーションや、そのヘッダー値を偽装できる、意図を持つ当事者によってのみ使用されるよう制限することができます。
アクセスを保護するには、ソース IP 範囲に基づいてリクエストを制限する方法もあります。 リソースを匿名で要求することも許可できますが、リクエストの発信元 IP が組織のローカル エリア ネットワークや NAT ベースの外部 IP など、想定範囲内にある場合に限ります。 これらの制限は、Web サーバー、ロード バランサー、またはリバース プロキシー レベルで適用できます。 IP ベースのフィルターは、特定の国や地域からのアクセスをフィルターしたり、固定の外部 IP アドレスを持つ特定のシステムからのアクセスを許可する場合にも役立ちます。
パブリック レイヤーの再利用を制限するには、API キーを使用する方法もあります。 この方法では、各リクエストに API キーを追加します。API キーは、API 管理またはリバース プロキシー レイヤーによって検証され、有効な API キーが含まれていないリクエストは拒否されます。 これによって単純な誤用は防ぐことができますが、意図を持つユーザーであれば、使用されている API キーを特定し、それを自分のアプリケーションやサービスで再利用してリクエストを行うことは比較的簡単です。 API キーはブラウザーまたはクライアント アプリケーションからサーバーに送信されるため、常にクライアントから参照でき、抽出して他の目的に再利用される可能性があります。 このリスクを軽減する最善の方法は、許可されたリファラーをキーごとに強制し、予期しない使用や悪意のある使用がないかキーを監視することです。
アプリケーションやサービスの適切なユーザーがパブリック ユーザーである場合、そのアプリケーションでアクセス可能なすべてのデータは_完全に公開されている_と見なすのが妥当です。 上記で提案した制限を設けても、意図を持つ当事者はそれを回避して、再利用のためにデータのコピーを抽出する方法を見つけることができます。 アクセスの適切な管理、免責事項の提示、公開データ サイトを通じてデータを利用できるようにすることは、データをパブリックに共有する際の懸念を軽減する手段です。これらの実践を通じて、不適切な使用に関する懸念は部分的に軽減できる可能性があります。