ArcGIS Online がファイアウォールの許可リストに必要とするドメインは？

DNS の応答が示すのは、問い合わせた瞬間にホスト名がどのアドレスに解決されたかだけです。アドレスが恒久的であることも、マップが接続するすべてを網羅していることも意味しません。この違いが最も重要になるのは、外向き通信が、一度の検索結果から誰かが入力した短い許可リストに制限されている場合です。まずワークフローから始め、そこからプロバイダーの現在の要件に基づいてリストを導きます。繰り返し登場する例は、制限された VPN 出口から ArcGIS Online に到達する企業向け GIS クライアントです。

マップ操作が接続するすべてのコンポーネントを列挙する

操作を部品に分けます。組織のポータルとアイテムへのアクセス、ベースマップのタイル、ホストされたフィーチャサービスまたは解析サービス、そしてアイテムのダウンロードです。それぞれが別のエンドポイントの背後にある可能性があります。外部の ArcGIS Enterprise サービスや OGC エンドポイントを参照するマップは、ネットワークチームが聞いたこともない依存関係を追加します。誰かが許可リストの申請を出す前に、すべてを書き出してください。その一覧から漏れたコンポーネントは、後になって認証情報の問題のように見える形で失敗します。

The Domain and FQDN Requirements document is where those families come from, and two of them carry most of the workflow: *.arcgis.com covers the organization portal, its items and the hosted services behind them, while *.arcgisonline.com serves basemaps and static tiles. Everything else is organization-specific, because an ArcGIS Enterprise service you host, an OGC endpoint or a custom domain in front of the portal has to be added by name. Take those entries from the same revision you read, since the regional storage hosts change between versions.

ポータルへのサインインが成功しても、証拠としては弱いものです。承認された経路からポータルのエンドポイントに到達できることを示すだけで、タイル、解析、ダウンロードについては何も示しません。

現在のドキュメントから wildcard か FQDN を選ぶ

Esri は Domain and FQDN Requirements を公開しており、リージョン別ストレージの項目はバージョン間で変わるため、版が重要です。現在のドキュメントは、ドメインレベルの wildcard 方式と、より厳格なホスト名レベルの一覧の両方を示しています。また、リージョン別ストレージのホストを挙げ、外部システムやカスタムドメインが組織固有の項目を追加することも警告しています。実際に読んだ版を、日付を含めて変更記録にコピーしてください。

厳格なリストは保守の時間を要し、広い許可はセキュリティの範囲を要します。このトレードオフはネットワークの所有者に属し、ドキュメントに照らして決めるべきで、誰かが作業中に一度だけ取得したアドレスの集合に照らして決めるべきではありません。

静的ベースマップの選択肢は狭く保つ

Esri のファイアウォール FAQ は、高速化されたベースマップ配信が動的なアドレスを返す場合があると述べています。同じ項目は、ベースマップ専用の静的 IP の取り決めも文書化しており、これは高速化の経路を離れるためパフォーマンスが低下する可能性があります。どちらの記述も、ポータル、ホストされたデータ、ストレージのホストを一つの静的アドレスにするものではありません。IP のみを許可するポリシーが必須なら、推測した範囲を広げるのではなく、Esri からサポートされた取り決めを取得してください。

古い DNS の応答はサポートされた取り決めではなく、やがて腐ります。

経路と許可を分けて考える

VPN の経路は道筋を選び、出口のルールはその道筋が宛先に到達してよいかを決めます。これらは別の制御であり、健全なトンネルは二つ目について何も語りません。だからこそ、あるネットワークの一人のユーザーではマップが失敗し、同じアカウントの別のユーザーでは動作することがあります。サービスを責める前に、ルールと経路を別々に確認してください。

一覧が不完全であれば、両方が正しくてもワークフローは失敗し続けます。

コンポーネントごとに検証し、その後リストに所有者を決める

失敗する操作を再現し、どのコンポーネントが失敗したかを記録します。ポータル、タイル、フィーチャサービス、ダウンロード、外部サービスのいずれかです。次にポリシーの要素を一つ変えて繰り返します。タイルを直す変更は、解析サービスについて何も教えてくれません。このコンポーネントごとの記録こそが、次のリージョン更新を推測のもう一巡ではなく依存関係の変更に変えます。診断用の URL は、クエリ文字列がトークンやアイテム識別子を運ぶことがあるため、どこかに貼り付ける前に確認してください。

要件リストに所有者と、ドキュメントの版に紐づくレビュー日を設定します。Esri がストレージのリージョンやサービスのホストを追加したら、その所有者が一覧を再実行し、インシデントの最中に欠落を発見する事態を避けます。