2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

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

Posted at

WebConnect 設定上の考慮ポイント

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

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

1. 転送方式による機能差と使い分けの考え方

まず、各転送方式の技術面や機能面の違いを理解した上で、改めて各業務にどの方式が適切なのかを考えてみましょう。
081_転送方式の機能差.png
最初に注目すべき点は通信方式です。TLSによる暗号セッションを利用して通信安全性を担保する点は共通していますが、TLSの中で行うプロトコルはHULFTとHTTPの2つがあるのがわかります。HTTPは単純なテキストデータの授受に最適化された仕組みですが、HULFTは安全・確実なファイル授受システム間連携のしやすさの両面を押さえた仕組みなので、図の機能差に表れてきます。
HULFTとHTTPの違いは下表のように理解しておけばいいと思います。
082_HULFTvsHTTP.png

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

2. IPフィルターの考え方

IPフィルターとはWebConnectのセキュリティ対応機能の一つで、意図しないIPアドレスからのWebConnectへのアクセスを制限する機能になります。設定の考え方は下図の通りで、コネクションIDとアカウントに紐づけてアクセス可能なIPを指定します。要するにホワイトリスト方式になります。
084_IPフィルターイメージ.png
ちなみに、アカウントに関してはパスワード変更時(パスワード再設定案内メールに記載されるURL接続時)にもIP制限が適用されます。

3. HULFTとAgentのサーバを分ける構成の考え方

WebConnectを導入する際に通常はHULFTと同一サーバにAgentを導入すれば十分なのですが、幾つかの理由で別サーバに導入したいというケースがあります。よくあるケースとしてセキュリティポリシーで イントラ上のサーバは直接インターネットに接続禁止 というものがあります。AgentにはHTTP PROXY経由でインターネット接続できる機能が標準で備わっているのでこの機能を利用すれば良いのですが、ファイル転送業務でHTTP PROXYに負荷をかけたくないという要望が出てくることもあります。その際に、Agent自体をHULFTのPROXYとして扱う分離構成をとる場合があります。
085_Agent分離構成.png
分離構成では、同居構成では発生しなかったハマりポイントがあります。それは名前解決問題です。
HULFTとAgentは独立した機能として動作するため、異なるサーバで動作させるときにホスト名とIPアドレスが正しく紐付けていないと接続できない問題がありがちです。
086_Agent分離構成_ハマるポイント.png
下図はWebConnectの各モジュールから別モジュールへ接続する際の設定項目と注意点(特に名前解決部分)をまとめたものになります。特に集信側のAgentがHULFTのホスト名とIPアドレスを解決できないケースが多いので注意が必要です。
086_Agent分離構成_設定ポイント.png

4. コネクションIDを複数使い分ける理由と設定の考え方

WebConnectにおけるコネクションIDはWebConnectサービスへ接続するためのゲートウェイとしての認証機能がまず思いつくと思います。もう一つ重要な役割として他のコネクションIDへ中継するルーターとしての役割があります。

IP-VPNを利用する場合のイメージ

下図は企業がIP-VPN網につないで別の企業(別拠点と読み替えても可)と通信するイメージ図です。IP-VPNでは特定の端末(ルーター)だけが通信できるプライベートネットワークを構成する仕組みですから、ルーターにはルーティング可能な端末が設定されるイメージとなります。(実際のIP-VPNではこんなにシンプルな仕組みではありませんが、イメージとして捉えてください。)
087_コネクションIDの考え方(IP-VPN).png

WebConnectを利用する場合のイメージ

下図はIP-VPN部分をWebConnectサービスに置き換えたイメージとなります。ルーター部分をコネクションIDに替わっただけで全く同じです。つまり、お互いのコネクションIDが相手のコネクションIDにそれぞれ通信許可を与えることによりHULFTネットワークがつながるという考え方になります。ですから、自分のコネクションIDにだけ通信許可を与えても相手のコネクションIDに通信許可が無ければつながりません。
088_コネクションIDの考え方(WebCon).png

具体的なコネクションIDの使用例

A社とB社で別々にWebConnect Base契約をしているケース

このケースでは、A社、B社それぞれが自社の契約アカウントでコネクションIDを設定します。

  • A社:コネクションID:Aに設定(コネクションID:Bとの接続を許可)
  • B社:コネクションID:Bに設定(コネクションID:Aとの接続を許可)

089_コネクションIDの考え方(Base契約×2).png

A社がWebConnect Base契約をして、B社・C社とそれぞれ通信するケース

このケースでは、A社が全てのコネクションIDの設定をします。

  • コネクションID:Aに設定(コネクションID:BとCに接続を許可)
  • コネクションID:Bに設定(コネクションID:Aにのみ接続を許可)
  • コネクションID:Cに設定(コネクションID:Aにのみ接続を許可)

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

090_コネクションIDの考え方(Base契約×1).png

まとめ

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

おまけ(その他の構成例)

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

1つのAgentだけ起動し2つのコネクションIDを同時に持たせる構成

091_コネクションIDの考え方(ConID節約-1Ag).png
この構成は、コネクションID認証ファイル(connection.keystore.filepath)にID/PWの設定を2つ記述する(2行にそれぞれのID/PWを記述)ことで実現できます。
このケースでは、コネクションIDの追加・削除する際にAgentを再起動させる必要がある(ダウンタイムが発生)というデメリットがある反面、メリットはほとんど見当たりませんので、あまりお勧めできる方法ではありません。

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

2つのAgentを起動しそれぞれに別のコネクションIDを持たせる構成

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

設定のポイント
Agentは以下の3点を分けることで同一サーバ上に複数の環境を持つことが可能です。

  • 導入先ディレクトリ
  • 使用するTCPポート
  • Agent ID

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


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

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


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

  1. 4つの転送方式の違い
  2. Agent方式の設定ポイント
  3. CLI方式の設定ポイント
  4. Webブラウザ方式の設定ポイント
  5. D-Client方式の設定ポイント
  6. その他設定上の考慮ポイント(本記事)

本記事は、HULFT-WebConnect V3 マニュアルを参考にしています。

2
1
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?