HULFT-WebConnect 設定ガイド【その他設定上の考慮ポイント】（6/6）

# WebConnect 設定上の考慮ポイント
前回までは、主にWebConnectの各転送方式ごとの設定手順や考慮ポイントを中心に解説してきました。今回は、WebConnectを利用する上で技術的に押さえておきたいポイントをいくつか解説いたします。

アジェンダは、以下の4つになります。（そのうち、こっそり書き足すかもしれません）
**1. 転送方式による機能差と使い分けの考え方**
**2. IPフィルターの考え方**
**3. HULFTとAgentのサーバを分ける構成の考え方**
**4. コネクションIDを複数使い分ける理由と設定の考え方**

## 1. 転送方式による機能差と使い分けの考え方
まず、各転送方式の技術面や機能面の違いを理解した上で、改めて各業務にどの方式が適切なのかを考えてみましょう。
![webcon3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/16ff1193-6be5-40c4-8fd4-ce643266a59d.png)

最初に注目すべき点は**通信方式**です。TLSによる暗号セッションを利用して通信安全性を担保する点は共通していますが、TLSの中で行うプロトコルはHULFTとHTTPの2つがあるのがわかります。HTTPは単純なテキストデータの授受に最適化された仕組みですが、HULFTは**安全・確実なファイル授受**と**システム間連携のしやすさ**の両面を押さえた仕組みなので、図の機能差に表れてきます。
HULFTとHTTPの違いは下表のように理解しておけばいいと思います。
![082_HULFTvsHTTP.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/488607db-356d-4e8d-9119-097c20a85f0a.png)

次に着目する点は**自動運用**しやすいかどうかです。自動運用のイメージは**一度仕掛けておけば人手の作業は不要**で、**異常が起きたときだけ通知できる仕組み**が備わっていることになります。もちろんRPAツールを導入したり新たに自動化の仕組みを作り込むことで一定の自動運用を実現できるかもしれませんが、人手の操作を前提とした方式を自動運用できるようにするのはコスト・時間・根性が必要で、現実的には割に合わない選択肢となっています。
自動運用に向かないWebブラウザ方式、D-Client方式が自動運用に向かなり理由は下表のように理解しておけば良いです。
![083_Webブラウザ方式vsD-Client方式.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/1051faa0-cfbe-363d-f3f6-b51cb323221b.png)
D-Client方式はコマンド利用ができるため、全自動運用は難しいかもしれませんが一部操作の自動化はできるかもしれませんね。

## 2. IPフィルターの考え方
IPフィルターとはWebConnectのセキュリティ対応機能の一つで、意図しないIPアドレスからのWebConnectへのアクセスを制限する機能になります。設定の考え方は下図の通りで、コネクションIDとアカウントに紐づけて**アクセス可能なIP**を指定します。要するに**ホワイトリスト**方式になります。
![084_IPフィルターイメージ.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/39e686a4-b8b8-36a3-1e51-19cee69ef019.png)
ちなみに、アカウントに関してはパスワード変更時（パスワード再設定案内メールに記載されるURL接続時）にもIP制限が適用されます。

## 3. HULFTとAgentのサーバを分ける構成の考え方
WebConnectを導入する際に通常はHULFTと同一サーバにAgentを導入すれば十分なのですが、幾つかの理由で別サーバに導入したいというケースがあります。よくあるケースとしてセキュリティポリシーで **イントラ上のサーバは直接インターネットに接続禁止** というものがあります。AgentにはHTTP PROXY経由でインターネット接続できる機能が標準で備わっているのでこの機能を利用すれば良いのですが、ファイル転送業務でHTTP PROXYに負荷をかけたくないという要望が出てくることもあります。その際に、**Agent自体をHULFTのPROXYとして扱う**分離構成をとる場合があります。
![085_Agent分離構成.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/afa0b4a2-8c4d-385e-5473-633a8a21a29a.png)
分離構成では、同居構成では発生しなかったハマりポイントがあります。それは**名前解決**問題です。
HULFTとAgentは独立した機能として動作するため、異なるサーバで動作させるときにホスト名とIPアドレスが正しく紐付けていないと接続できない問題がありがちです。
![086_Agent分離構成_ハマるポイント.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/cfd2fddd-515b-3941-c2b0-086f7bf15030.png)
下図はWebConnectの各モジュールから別モジュールへ接続する際の設定項目と注意点（特に**名前解決**部分）をまとめたものになります。特に**集信側のAgentがHULFTのホスト名とIPアドレスを解決できない**ケースが多いので注意が必要です。
![086_Agent分離構成_設定ポイント.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/b47dc18d-8754-e8f3-8397-a6a0bed4cbc4.png)

## 4. コネクションIDを複数使い分ける理由と設定の考え方
WebConnectにおけるコネクションIDはWebConnectサービスへ接続するためのゲートウェイとしての認証機能がまず思いつくと思います。もう一つ重要な役割として他のコネクションIDへ中継する**ルーターとしての役割**があります。

### IP-VPNを利用する場合のイメージ
下図は企業がIP-VPN網につないで別の企業（別拠点と読み替えても可）と通信するイメージ図です。IP-VPNでは特定の端末（ルーター）だけが通信できるプライベートネットワークを構成する仕組みですから、ルーターにはルーティング可能な端末が設定されるイメージとなります。（実際のIP-VPNではこんなにシンプルな仕組みではありませんが、イメージとして捉えてください。）
![087_コネクションIDの考え方（IP-VPN）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/38cc4f23-368e-9ecb-cbd3-e4e06ed1d5e9.png)

### WebConnectを利用する場合のイメージ
下図はIP-VPN部分をWebConnectサービスに置き換えたイメージとなります。ルーター部分をコネクションIDに替わっただけで全く同じです。つまり、お互いのコネクションIDが相手のコネクションIDに**それぞれ通信許可を与える**ことによりHULFTネットワークがつながるという考え方になります。ですから、**自分のコネクションIDにだけ通信許可を与えても相手のコネクションIDに通信許可が無ければつながりません。**
![088_コネクションIDの考え方（WebCon）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/ba46b75b-0491-3291-b4d9-99b6fc7399fa.png)

### 具体的なコネクションIDの使用例
#### A社とB社で別々にWebConnect Base契約をしているケース
このケースでは、A社、B社それぞれが自社の契約アカウントでコネクションIDを設定します。
* A社：コネクションID：Aに設定（コネクションID：Bとの接続を許可）
* B社：コネクションID：Bに設定（コネクションID：Aとの接続を許可）

![089_コネクションIDの考え方（Base契約×2）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/eae29a91-2acd-fb54-30fa-fe5350dbff91.png)
#### A社がWebConnect Base契約をして、B社・C社とそれぞれ通信するケース
このケースでは、A社が全てのコネクションIDの設定をします。
* コネクションID：Aに設定（コネクションID：BとCに接続を許可）
* コネクションID：Bに設定（コネクションID：Aにのみ接続を許可）
* コネクションID：Cに設定（コネクションID：Aにのみ接続を許可）

::: note warn
**注意ポイント**
B社とC社は無関係なので**互いに通信できる状態にしてはならない**ことです。
:::

![090_コネクションIDの考え方（Base契約×1）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/4f65e1fb-2b45-221e-1bbf-8aaf2b97a3b7.png)

### まとめ
コネクションIDは、互いに異なるネットワークを持つ**組織単位（通常は企業単位）に割り当てる**とシンプル・柔軟・わかりやすい構成がとれるのでお勧めです。

### おまけ（その他の構成例）
実は、コネクションIDに接続許可をしなくても企業単位にセキュアな通信ができる構成方法があります。この構成は、目的によってあまりお勧めできないケースもありますので、そのメリット・デメリットを良く考えて選択してください。


#### 1つのAgentだけ起動し2つのコネクションIDを同時に持たせる構成
![091_コネクションIDの考え方（ConID節約-1Ag）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/aa153787-4034-dfa7-5392-84bd0d08e1bb.png)
この構成は、コネクションID認証ファイル（connection.keystore.filepath）にID/PWの設定を2つ記述する（2行にそれぞれのID/PWを記述）ことで実現できます。
このケースでは、コネクションIDの追加・削除する際にAgentを再起動させる必要がある（**ダウンタイムが発生**）というデメリットがある反面、メリットはほとんど見当たりませんので、あまりお勧めできる方法ではありません。

::: note info
実は、WebConnect Ver.2 まではコネクションIDを増やす場合は有償オプションの購入が必要でした。そのためコネクションIDを節約するためにこのような構成をとることがありました。WebConnect Ver.3 からはコネクションIDに対する追加課金が必要なくなったので、Agentごとに1つのコネクションIDを割り当てた方が**運用上の制約もなく**設定の考え方も**シンプル**なため合理的な方法といえます
:::

#### 2つのAgentを起動しそれぞれに別のコネクションIDを持たせる構成
![092_コネクションIDの考え方（ConID節約-2Ag）.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/458288/ed9223fd-1e56-1139-efc2-84dda09748a2.png)
この構成は、Agentを別々に2環境用意して異なる設定値（異なるコネクションID）で起動させることで実現できます。
このケースでは、運用管理の手間とマシンリソースを余計に消費する（相手先コネクションIDが増えるたびにAgentも別に用意する）という大きなデメリットがあります。一方で、Agentの多重度制約（20多重/Agent）を緩和する手段としてはメリットは確かにあります。ただし、20多重を超える状況ではCPU使用率がかなり高まることが予想されるため、**安定した転送を実現する**にはAgentごとにサーバを分ける方が良いかもしれません。

::: note info
**設定のポイント**
Agentは以下の3点を分けることで同一サーバ上に複数の環境を持つことが可能です。
* 導入先ディレクトリ
* 使用するTCPポート
* Agent ID
:::

::: note warn
**注意ポイント**
AgentはHULFTに比べてCPU使用率が高い傾向があります。その理由は暗号通信処理（TLS）をAgentが担っているためです。このためAgentを経由したHULFT**高多重**通信を行う場合はサーバへ高負荷がかかることが予想されるので、サーバのスペックには注意が必要です。このあたりは、無償の評価版を申し込んで事前に検証した方が良いと思います。
なお、HULFT単体でも特にAES暗号オプションを用いた転送はCPU負荷が高いので、**多重**転送する場合は同様にサーバスペックに注意が必要となります。
:::

---
以上、WebConnectをより深くご理解いただけたでしょうか？

これで全6回のHULFT-WebConnect設定ガイドを終了します。

***
**HULFT-WebConnect 設定ガイド** は、全6回のシリーズで公開予定しています。

1. [４つの転送方式の違い](https://qiita.com/sugimon/items/1492714fb668e9a0c910)
2. [Agent方式の設定ポイント](https://qiita.com/sugimon/items/071693e248014505c8f3)
3. [CLI方式の設定ポイント](https://qiita.com/sugimon/items/aed0713cf56dbd0de063)
4. [Webブラウザ方式の設定ポイント](URL)
5. [D-Client方式の設定ポイント](URL)
6. **その他設定上の考慮ポイント**（本記事）

***
本記事は、[HULFT-WebConnect V3 マニュアル](https://www.hulft.com/help/ja-jp/WebConnect-V3/index.htm)を参考にしています。