ArcGIS Architecture シリーズ: Security Architecture Pattern

1 はじめに
2 アーキテクチャの設計
3 Security Architecture Patterns
4 参考

はじめに

GIS は、コンピューターが空間機能を提供するという課題に取り組んで以来、急速に進化してきました。 GIS がマップ作成プラットフォームから Location Intelligence プラットフォームに進化すると、ビジネスの成功に必要なソリューションをホストするために利用されるため、堅牢性、信頼性、柔軟性に優れたシステムを構築する必要が生じます。 GIS は、従来のデータセンター内で実行されているサーバー、クラウド、モバイルおよび IoT デバイスからどこでも実行されています。このような多様な環境をサポートすると、独特の構築する上での課題が生じ、GIS を設計するための体系的なアプローチが必要になります。

アーキテクチャの設計

Esri システムアーキテクチャの設計は、複数の層、つまりクライアント/アプリケーション層、プレゼンテーション層、サービス層、サポート層、およびデータ層を中心とした従来のアーキテクチャパターンに基づいています。以下の論理アーキテクチャの例に示すように、各層は Esri 製品およびソリューションコンポーネントと連携しています。このブログシリーズでは、体系的なアプローチに従って、今日のビジネスとロケーションインテリジェンスのニーズを満たす最新の GIS プラットフォームの構築をサポートするさまざまなアーキテクチャ層とそれに関連するソリューションコンポーネントを検討します。

特別なセキュリティ制約内部ネットワークへの非認証アクセスの禁止

フェデレーション ArcGIS Enterprise システムでは、ポータルがユーザーの認証と認可を担当します。

上記のパターンでは、ユーザーが ArcGIS Enterprise にリクエストを行うと、ArcGIS Enterprise はまずセキュリティで保護されたリソース (サービスなど) へのリクエストに有効な認証情報が含まれているかどうかを確認し、含まれていない場合は、設定されたアイデンティティプロバイダーで認証するため、リダイレクト応答をクライアントに返します。（SAML または OpenID Connectなど。）

リバースプロキシのアーキテクチャ（DMZでリバースプロキシを使用するパターン）では、外部クライアントからの未認証リクエストは、ArcGIS Enterprise がクライアントにリダイレクト応答を返す前に、DMZ リバースプロキシから内部 Web アダプターに渡され、Web アダプターから ArcGIS Enterprise ポータルまたはサーバーに渡されます。

一部のセキュリティポリシーでは、イントラネットゾーンへの認証されていないアクセスが禁止されているため、リバースプロキシのアーキテクチャ（DMZでリバースプロキシを使用するパターン）はこの制約を満たしていません。

HTTPS アクセスなし / DMZ から内部ネットワークへのデータベースアクセスのみが許可されています

ほとんどのセキュリティポリシーでは、DMZから内部ネットワークへのインバウンドアクセスを許可しますが、プロトコルやポートによるアクセスの種類を制限することがあります。例えば、DMZからイントラネットへの HTTPS（ハイパーテキスト転送プロトコルセキュア）アクセスを許可しない、またはカスタムポートを介したデータベースアクセスのみを許可するといった制限があります。

上記のアーキテクチャでは、DMZのリバースプロキシはポート443を介して HTTPS 経由で ArcGIS Enterprise へのリクエストを転送しますが、これは制約を満たしていません。

DMZ から内部ネットワークへの受信アクセスは禁止

場合によっては、セキュリティポリシーによって、DMZ から内部ネットワークへのあらゆるタイプの受信アクセスが禁止され、イントラネットから DMZ への非永続的な接続のみが許可されることがあります。

Security Architecture Patterns

以下のセキュリティアーキテクチャパターンを検討し、各パターンが上で確認したセキュリティ制約の一部またはすべてにどのように対処するかを確認してみましょう。

DMZ ArcGIS Enterprise ポータルと登録サービス

図１（ArcGIS Enterprise Portal Proxy）です。

上の図 1では、DMZ 内に ArcGIS Enterprise ポータルがあり、内部ネットワーク内に ArcGIS Enterprise サーバーがあります。内部スタンドアロンサーバーはポータルとフェデレートされていません。サービスはスタンドアロンサーバーに直接公開され、アプリケーションアカウント (ArcGIS Enterprise サーバーの組み込みアプリケーションアカウントまたは Active Directory / LDAP サービスアカウント) を使用してサーバー内で保護されるように構成され、保存された資格情報を持つ Web からのアイテムとしてポータルに追加されます。

ArcGIS Enterprise サーバーで保護されたサービスが、保存された認証情報を使用してポータルに登録されると、ポータルはそのサービスのプロキシ URL を作成し、そのサービスへのすべてのリクエストは内部スタンドアロンサーバーに転送される前にポータルを経由します。 ArcGIS Enterprise ポータルでは、サービスにアクセスできるレート制限と特定のリファラーを定義することもできます。

上記のパターンを使用することで、内部ネットワークへの認証されていないアクセスを防ぐ制約が満たされます。外部からのすべてのリクエストは、まずDMZ内のポータルを経由してユーザーの認証と承認を行い、その後に内部ネットワークのサービスにリクエストが行われます。ただし、ポータルからサーバーへのすべてのリクエストは、保存された認証情報を使用して行われるため、エディタのトラッキング機能が失われることに注意してください。このパターンのアーキテクチャは、図２に示されているように、ポータル、ホスティングサーバー、およびフェデレーションサーバーからなる内部向きのArcGIS Enterpriseの連携システムを含めて詳細に説明することができます。

図２（ArcGIS Enterprise Portal Proxyの詳細）です。

内部複製ジオデータベース

一部の組織のセキュリティポリシーでは、DMZからイントラネットへのHTTPSアクセスを許可せず、通常は非デフォルトのポートを介したデータベースアクセスのみを許可しており、多くの場合、主要な本番データベースへの外部アクセスも許可せず、別個のデータベースの使用を要求します。

以下の図３では、ArcGIS EnterpriseがDMZに展開され、内部複製エンタープライズジオデータベースがマッピングサーバーの登録データソースとして使用されています。EsriジオデータベースのレプリケーションまたはRDBMSのレプリケーションのいずれかを使用することができます。

図３（データベース複製）です。

以下の図４は、内部ネットワークにおける内部向きのArcGIS EnterpriseシステムとDMZにおける外部向きのArcGIS Enterpriseシステムを含む詳細なアーキテクチャを示しています。

サービスの公開と共有

最後に、DMZからイントラネットへのすべてのインバウンドアクセスを許可しない場合、図6は以下の構成を示しています：

– DMZ内のArcGIS Enterpriseを外部向きとし、イントラネット内のArcGIS Enterpriseを内部向きとします。

– ホストされたレイヤーとしてDMZのArcGIS Enterpriseシステムにサービスを公開し、定期的なタスク（例：夜間または週次）を実行して、内部のArcGIS Enterpriseシステムからの更新されたデータでホストされたデータを上書きします。

– フィーチャレイヤーは、内部のArcGIS EnterpriseシステムからDMZのArcGIS Enterpriseシステムへのコピー共有を通じて、2方向の共有編集によって配布されたコラボレーションを介して共有されます（バージョン10.9で導入）。

ArcGIS Enterprise の配置パターンを理解することで、セキュリティに配慮した設計を進めていくことが可能になります。GIS活用の中でのDX推進のヒントにしてみてください。

参考

本記事の内容に関して具体的なご相談につきましては、お問い合わせよりご連絡ください。