はじめに
セキュリティはエンタープライズアーキテクチャ設計プロセスにおいて重要な役割を果たします。セキュリティポリシーは組織ごとに異なり、それらの要件や制約を満たすために異なる展開パターンが必要です。本投稿では、より一般的なセキュリティ制約のいくつかに対処し、それらを満たすための展開パターンを提案します。
これは利用可能なすべてのセキュリティ要件およびセキュリティアーキテクチャパターンの網羅的なリストではありません。
本投稿は、ArcGIS Enterpriseの保護されたリソースを外部クライアント、つまり組織の内部ネットワーク外からアクセスする必要があるシステム（例：VPNなしでフィールドワーカーがアクセスするためのDMZ経由）に公開するためのアーキテクチャパターンに焦点を当てます。
どのパターンを使用するかの決定には、ここで扱わない追加の考慮事項もあります。例えば、各パターンに必要なリソース（ハードウェア、ライセンス、スタッフなど）の数などです。
アーキテクチャパターンのセキュリティ面に集中して簡素化するため、本投稿内のすべてのアーキテクチャは高可用性ではありませんが、それぞれはパターンを変更せずに高可用性アーキテクチャに調整可能です。
DMZリバースプロキシ
最も一般的な外部向けArcGIS Enterpriseシステム展開パターンである、DMZ内でのリバースプロキシ使用から始めましょう。
図 1 - DMZリバースプロキシ
このパターンでは、すべてのArcGIS Enterpriseコンポーネントはファイアウォール内側の内部ネットワークにホストされ、リバースプロキシ（F5やNetScalerなどの商用リバースプロキシ、NginxやHAProxyなどのオープンソースリバースプロキシ、または2セット目のArcGIS Web Adaptors）がDMZに配置され、外部からの要求をArcGIS Enterpriseへ中継します。
ArcGIS Enterpriseポータルは公開ポータルURL（WebコンテキストURL）として一つのDNSのみをサポートしており、外部アクセスをサポートするためには、ポータルのWebコンテキストURL用に外部から解決可能なDNS名（例：https://gis.company.com/portal）を使用する必要があります。
多くの場合、このパターンではSplit Domain Name System（Split DNS）が実装されます。つまり、ArcGIS Enterprise DNS（例：gis.company.com）への内部要求は内部Web AdaptorsマシンIPへ解決されるため、内部ユーザーはファイアウォール内側に留まり、外部要求はDMZリバースプロキシIPへ解決されます。
DMZリバースプロキシ前にWeb Application Firewall（WAF）を使用することは追加のセキュリティ制御を提供するためセキュリティ上推奨されます。Esriはドキュメント（組織ログインが必要）をhttps://trust.arcgis.comで管理しており、ArcGIS Enterpriseサイト内の潜在的に機密性の高いリソースへの外部アクセスを拒否するため安全にフィルタリング可能なエンドポイント一覧が記載されています。
特別なセキュリティ制約
内部ネットワークへの未認証アクセス禁止
フェデレーションされたArcGIS Enterpriseシステムでは、ポータルがユーザー認証と認可を担当します。上記パターンでは、ユーザーがArcGIS Enterpriseへ要求するとき、ArcGIS Enterpriseはまず保護されたリソース（例：サービス）への要求が有効な認証情報を含むか確認し、不足している場合は設定されたIDプロバイダー（例：SAMLまたはOpenID Connect）で認証するようクライアントへリダイレクト応答を返します。
上記アーキテクチャでは、未認証要求が外部クライアントからDMZリバースプロキシ経由で内部Web Adaptorsへ渡され、その後Web AdaptorsからArcGIS Enterpriseポータルまたはサーバーへ渡されてからArcGIS Enterpriseがクライアントへリダイレクト応答を返します。
一部のセキュリティポリシーではイントラネットゾーンへの未認証アクセスを禁止しているため、このアーキテクチャはその制約を満たしません。
DMZから内部ネットワークへのHTTPSアクセス禁止／データベースアクセスのみ許可
多くのセキュリティポリシーではDMZから内部ネットワークへのインバウンドアクセスを許可していますが、許可されるアクセス種別をプロトコルやポートで制限する場合があります。例えば、DMZからイントラネットへのHTTPS（Hypertext Transfer Protocol Secure）アクセスは禁止しカスタムポート経由でデータベースアクセスのみ許可するといったケースです。
上記アーキテクチャではDMZリバースプロキシがHTTPS（ポート443）経由でArcGIS Enterpriseへ要求を中継しているため、この制約には適合しません。
DMZから内部ネットワークへのインバウンドアクセス禁止
場合によってはセキュリティポリシーでDMZから内部ネットワークへのあらゆる種類のインバウンドアクセスが禁止されており、イントラネットからDMZへの非永続的接続のみ許可されています。
セキュリティアーキテクチャパターン
以下のセキュリティアーキテクチャパターンについて検討し、それぞれが上記でレビューしたいくつかまたはすべてのセキュリティ制約にどのように対応しているか見ていきましょう。
DMZ ArcGIS Enterprise Portalと登録サービス
図 2 - ArcGIS Enterprise Portal Proxy
Proxy.PNG" style="width: 628px;">
<\/span><\/P>
<\/DIV>
上記の図2では、DMZにArcGIS Enterpriseポータルがあり、内部ネットワークにArcGIS Enterpriseサーバーがあります。内部のスタンドアロン・サーバーはポータルとフェデレーションされておらず、サービスは直接スタンドアロン・サーバーに公開され、アプリケーションアカウント（ArcGIS Enterpriseサーバー組み込みアプリケーションアカウントまたはActive Directory / LDAPサービスアカウント）を使用してサーバーでセキュリティ設定され、その後ウェブからのアイテムとしてポータルに追加され、資格情報が保存されます。ArcGIS Enterpriseサーバーのセキュリティ保護されたサービスが保存された資格情報でポータルに登録されると、ポータルはそのサービス用のプロキシURLを作成し、そのサービスへのすべてのリクエストはポータルを経由してから内部のスタンドアロン・サーバーに転送されます。ArcGIS Enterpriseポータルでは、レート制限や特定のリファラーを定義してサービスへのアクセスを制御することも可能です。<\/P>
上記のパターンを使用すると、内部ネットワークへの未認証アクセスがないという制約を満たします。すべての外部リクエストはDMZ内のポータルを通過し、最初にユーザー認証と承認が行われ、その後に内部ネットワーク内のサービスへリクエストが送信されます。ただし、ポータルからサーバーへのすべてのリクエストは保存された資格情報を使用して行われるため、編集者追跡機能は失われることに注意してください。<\/P>
このパターンのアーキテクチャは、図3に示すように、ポータル、ホスティングサーバー、およびフェデレーションされたサーバーを含む内部向けフェデレーションシステムのArcGIS Enterpriseを含むように拡張できます。<\/P>
<\/P>
図3 - ArcGIS Enterprise Portal Proxy 詳細化<\/H3> <\/P>
<\/span><\/P>内部レプリケートジオデータベース<\/H2> <\/P>一部の組織のセキュリティポリシーでは、DMZからイントラネットへのHTTPSアクセスを許可せず、通常は非標準ポート経由でデータベースアクセスのみを許可し、多くの場合プライマリ本番データベースへの外部アクセスも許可せず、別のデータベースの使用を要求しています。<\/P>下記図4では、ArcGIS EnterpriseがDMZに展開されており、内部レプリケートされたエンタープライズジオデータベースがマッピングサーバー用の登録済みデータソースとして使用されています。EsriジオデータベースレプリケーションまたはRDBMSレプリケーションのいずれかを使用できます。<\/P> <\/P>図4 - データベースレプリケーション<\/H3> <\/P>
<\/span><\/P> <\/DIV>下記図5は、内部ネットワーク内の内部向けArcGIS EnterpriseシステムとDMZ内の外部向けArcGIS Enterpriseシステムを含む詳細なアーキテクチャを示しています。<\/P> <\/P>図5 - データベースレプリケーション 詳細化<\/H3> <\/P>
<\/span><\/P> <\/DIV>サービス公開とコラボレーション<\/H2> <\/P>最後に、DMZからイントラネットへのインバウンドアクセスを一切許可しない場合について、下記図6はDMZ内の外部向けArcGIS Enterpriseとイントラネット内の内部向けArcGIS Enterpriseがあり:<\/P>サービスはDMZ ArcGIS Enterpriseシステムにホストレイヤーとして公開され、自動化タスクがスケジュール（例：毎晩または毎週）で実行されて内部ArcGIS Enterpriseシステムから更新データでホストデータを上書きします。<\/LI>フィーチャーレイヤーは双方向共有編集による分散コラボレーション(バージョン10.9で導入)を介して内部ArcGIS EnterpriseシステムからDMZ ArcGIS Enterpriseシステムへコピー共有されます。<\/LI><\/OL> <\/P>図6 - サービス公開とコラボレーション<\/H3> <\/P>
<\/span><\/P> <\/DIV>外部アプリケーションによる ArcGIS Enterprise アクセス制限<\/H1> <\/P>場合によっては、組織が外部統合アプリケーションをサポートするために ArcGIS Enterprise を使用し、特定のIPリストまたは範囲や特定ドメインからのみリクエストを許可するなど外部リクエストをフィルタリングして外部アプリケーションアクセスを制限したい場合があります。<\/P> <\/P>ArcGIS Online プロキシ<\/H2> <\/P>上記図2のDMZ ArcGIS Enterprise ポータルと登録済みサービスパターンと同様に、ArcGIS Onlineもスタンドアロン ArcGIS Enterprise サーバーまたはフェデレーション ArcGIS Enterprise システムからセキュリティ保護されたサービスを登録するとプロキシとして機能します。下記図7では、内部 ArcGIS Enterprise システムからのサービスが保存された資格情報で ArcGIS Online に登録されており、ArcGIS Online は DMZ リバースプロキシ経由でサービスにアクセスできます。このリバースプロキシは ArcGIS Online ドメインからのみリクエストを許可し、それ以外からのリクエストはブロックします。統合システムのウェブまたはモバイルアプリはOAuth 2.0 と ArcGIS Identity を使って ArcGIS Online に登録できるため、認証・承認されたユーザーのみが登録済みサービスへアクセス可能です。ArcGIS Online は保存された資格情報でサービスへアクセスするため編集者追跡機能は動作しません。ポータル同様にレート制限や特定リファラーも定義可能です。<\/P> <\/P>図7 - ArcGIS Online と登録済みサービス<\/H3> <\/P>
<\/span><\/P> <\/P>サーバープロキシ<\/H2> <\/P>もう一つの方法として、スタンドアロン ArcGIS Enterprise サーバーサイトとサーバープロキシを使って統合ウェブアプリからセキュリティ保護されたサービスへアクセスする方法があります。<\/P>下記図8では統合システムウェブアプリクライアントが統合システムアプリケーションサーバー上でホストされるプロキシへ GIS リクエストを送信するよう設定されています。統合アプリケーションサーバーはプロキシへのアクセス制御（つまりアプリ認証ユーザーのみプロキシへアクセス許可）と ArcGIS Enterprise サーバー資格情報の保護（暗号化）を担当します。プロキシはクライアントに代わり ArcGIS Enterprise サーバートークンセキュリティを処理し、サーバー組み込みアプリケーションアカウントまたは Active Directory / LDAP サービスアカウントを使い DMZ リバースプロキシ経由で内部スタンドアロン ArcGIS Enterprise サーバーサイトへリクエスト送信します。このリバースプロキシは統合アプリサーバーIP（リストまたは範囲）のみからのリクエスト許可し、それ以外からのリクエストはブロックします。<\/P> <\/P>図8 - 統合ウェブアプリ サーバープロキシ <\/H3> <\/P>
<\/span><\/P> <\/P>
.png)
