今日の IT 業界では、ZTA (ゼロ トラスト アーキテクチャー) の定義、実装パターン、および影響が数多くあります。 Esri は、特定の組織に対して ZTA 戦略を定義または実装する立場にはありませんが、ArcGIS は IT 環境内で動作するソフトウェアおよびツールのスイートであり、ZTA が実装する可能性のある制約、ルール、およびポリシーの影響を大きく受けるようになっています。 ArcGIS と ZTA を併用する場合の考慮事項の一部を以下に示します。
ArcGIS システムは、ソフトウェア アーキテクチャーの観点から、ネットワーク アクセス、オープン性、および互換性に関する特定の前提条件 (暗黙の信頼とも呼ばれるアプローチ) に依存するように設計されています。 この設計アプローチでは、組織の ZTA 戦略を慎重に理解し、明確な計画と実装のアプローチがなければ、ArcGIS を ZTA 環境にデプロイする際に困難が伴うか、機能的な制限が生じる可能性があります。
Esri は、これまでと同様、各ソフトウェア リリースにおいて ZTA 対応のデプロイメント パターンの需要に応えるべく取り組みを続けていきます。 現在、ArcGIS は、多くの点で ZTA に似たセキュリティー ポスチャーをサポートしています。すべてのユーザーに認証を要求するよう構成し、権限を慎重に管理し、リモート アプリケーションまたはクライアントのすべてのユーザーがデータの表示やアクセスを行う前に認証を行えるからです。 この既存のセキュリティー ポスチャーが、特定の組織のセキュリティー要件を十分に満たしているかどうかは、組織が慎重に検討した上で決定する必要があります。
実際には、ほとんどの組織は、新しいポリシー、新しいテクノロジー、新しいネットワーク アーキテクチャーを組み合わせて ZTA を実装しています。 一般に、同じネットワーク上のシステム間の通信がほぼオープンで制限されておらず、認証がアプリケーション固有のプロトコルとツールで管理されている WAN (ワイド エリア ネットワーク) スタイルのネットワーク デプロイメントから逸脱することを意味します。 この従来のネットワーキング方式は、ネットワークの境界を保護することに依存しています。これは特定の脅威に対しては効果的ですが、安全な境界を突破した外部の攻撃者に対しては、ネットワークの他の部分が脆弱な状態になる可能性があります。
ZTA は、大部分がオープンなネットワーク アクセスの従来のパターンは基本的に安全ではないという前提に基づいて運用されています。 ユーザー、デバイス、アプリケーション、およびサービスを、これまで以上に頻繁に、より慎重に、より多くの場所で認証する必要があることを提案しています。 ZTA の一般的な目標は、システムの 2 つのコンポーネントまたはユーザー間で発生するネットワーク アクティビティーに対して、限られた期間で最小特権セッションを提供することです。 この目標を達成するために、さまざまなポリシーや技術的アプローチを使用できます。最終的には、各組織が ZTA の独自の設計を定義し、その設計に準拠するように再設計し、コンプライアンスを経時的に監視する責任を負います。
ArcGIS Online は、SaaS 製品として提供されており、一般的には ZTA の定義の範囲外に位置付けられています。 これは、そのシステムのセキュリティーと制御はベンダーである Esri の責任であり、このシステムのユーザーは、これらの目標を達成するために Esri との信頼と合意に依存しているためです。
SaaS システムでは、すべてのユーザーは、セキュリティー保護された既知の REST エンドポイントへの HTTPS リクエストを使用して ArcGIS Online に排他的にアクセスし、バックエンド システム、それらをホストしているネットワーク、またはその他のセキュリティー保護されたリソースにはアクセスしません。 Esri は ArcGIS Online のセキュリティー ベースラインに加え、各組織の SaaS システムに対するセキュリティー ニーズに合わせて構成できるさまざまなセキュリティー設定や権限の設定 (デフォルトのユーザー アクセスの制限、権限の制御、コンテンツの共有など) も提供します。
ArcGIS Pro は、さまざまなデータ解析、編集、視覚化のワークフローに使用される Windows デスクトップ アプリケーションです。 これらのワークフロー全体を通じて、ArcGIS Pro は通常、次の 3 つのカテゴリーに分類されるデータセットに接続します。
これらの接続で認証が必要な場合、ArcGIS Pro は認証標準を認識し、ユーザーがそのデータの場所に接続できるように具体的にサポートする必要があります。 現在、このソフトウェアは、データベース ユーザーからエンタープライズ アイデンティティーまたはオペレーティング システム認証、アクセス キーとシークレット、サービス アカウントの認証情報など、さまざまな認証パターンをサポートしています。 ZTA は、ストレージ システムに対して、多要素ユーザー認証や、ヘッドレス サービス アカウントや専用データ アクセス アカウントのサポートを削除するなど、新しくより複雑な認証要件を実装することがよくあります。 データベース、ファイル システム、Web サービス、またはその他のデータ ストレージ システムに対する ZTA セキュリティー制御の実装は、ArcGIS ユーザーへの潜在的な影響を考慮して慎重に検討する必要があります。
ArcGIS Pro は、ArcGIS Enterprise、ArcGIS Online、またはその他の外部 Web サービスと通信する際にも HTTPS リクエストを行います。 これらのリクエストが予期しない方法で保護されていたり、ブラウザーのような ZTA 適用パターン (Cookie ベースのセッション管理など) を使用している場合、ArcGIS Pro はこれらのエンドポイントに接続できない可能性があります。ArcGIS Pro では現在、HTTPS リクエストに対し、既知の慎重にテストされた一連のセキュリティー アクセス パターンのみをサポートしています。
ArcGIS Drone2Map、ArcGIS Earth、ArcGIS AllSource、Survey123、Insights Desktop などの他の ArcGIS デスクトップ アプリケーションも、ZTA アーキテクチャーの決定の影響を受ける可能性があります。 これらの各アプリケーションは、HTTPS ベースの接続を使用してデータのクエリーと視覚化を行うため、同じ注意点や懸念事項が当てはまります。
モバイル デバイスとアプリケーションのセキュリティーは、サイバーセキュリティー分野において、多様かつ複雑、そして課題が多い領域です。 モバイル アプリ ワークフローが主流となり、エンタープライズ環境における従業員やメンバーによる個人使用が増加するにつれ、その重要性は高まっています。 一般的なモバイル セキュリティーのトピックには、EMM (エンタープライズ モビリティー管理)、デバイス登録、エンドポイント管理、トラフィック管理、MDM (モバイル デバイス管理)、MAM (モバイル アプリケーション管理) などがあります。 さまざまなベンダーのソリューションも、モバイル ワークフローのセキュリティーの強化や、これらの問題の防止に役立つユーザーベースおよび行動ベースの制御の向上に対して貢献したり、サポートすることを目指しています。
モバイル デバイスはデバイスレベルやアプリレベルの VPN や、それに似たものをサポートできますが、サイバーセキュリティーのソリューションとしての VPN の概念は ZTA では疑問視されており、多くのモバイル アプリはインターネットに接続されたサービスが存在することを前提としています。そのため、公共の無線信号やさまざまな場所からアクセスできます。
ZTA は、デバイスベースの認証、デバイス登録、および継続的なアクセス監視の組み合わせを要求することで、モバイル デバイスのワークフローに実装されることがよくあります。 これらのコントロールは、モバイル オペレーティング システム レベルで実装されることが多いため、ArcGIS モバイル アプリケーションからアクセスできる場合とできない場合があります。 たとえば、デバイスを Azure Entra ID に登録し、それを Azure AD による認証を許可する前の条件付きチェックとして使用できますが、ArcGIS モバイル アプリケーションが要件を認識していない場合や、デバイス登録情報へのアクセス方法を知らない場合、Entra ID エンドポイントに送信されず、認証が失敗することがあります。
ArcGIS Enterprise は、ユーザーがクライアントからの HTTPS リクエストを通じてアクセスする、サーバーベースの Web アプリケーションと Web サービスのセットです。クライアントには、ブラウザー、モバイル アプリ、デスクトップ アプリケーションのどれでも使用できます。 これらのクライアントへの影響については前のセクションで説明しましたが、ArcGIS Enterprise 自体も ZTA 構成の影響を受ける可能性があります。 たとえば、システム ポリシーですべての内部ネットワーク リクエストが認証される必要がある場合、そのポリシーには、ArcGIS が管理するトークンとキー、またはユーザー名とパスワードの認証によって保護されている、すべての ArcGIS Enterprise コンポーネント間リクエストを含めることができます。 ネットワークがすべての内部ネットワーク リクエストをフィルターし、特定の証明書、キー、またはヘッダーを要求するよう設計されている場合、これらの内部コンポーネント リクエストはブロックされ、失敗する可能性があります。
上記の影響は、ArcGIS コンポーネントへの潜在的な影響に備えるために、ゼロ トラスト実装の具体的な内容を理解することの重要性を浮き彫りにしています。 ArcGIS でゼロ トラスト要件を満たすためのアプローチの 1 つとして、システムの既存のセキュリティー ポスチャーを考慮することが挙げられます。すべてのユーザー リクエストは ArcGIS トークンによって個別に認証され (これは強力なメカニズムである)、この標準を達成するためにユーザー アクティビティーを十分に検証することが求められます。
ゼロ トラスト アーキテクチャー制御の一部として使用される一般的なテクノロジーは、アイデンティティー認識型プロキシーです。 このパターンは、ブラウザーベースのトラフィックのいくつかの目標を達成するかもしれませんが、ArcGIS Pro やモバイル アプリケーションから ArcGIS Enterprise へのアクセスに支障をきたす可能性があります。