HULFTへの理解を整理する

HULFTの基本的な知識と、HULFT8・10・WebConnectの違いを整理する。

代表的なファイル転送プロトコルの整理
HULFTの前に、代表的なプロトコルの特徴をおさらいする。
FTP、FTPS、SFTP、SCPの違い
FTP、FTPS、SFTP、SCPの完全ガイド
ファイル転送に使われるプロトコルの役割と種類を理解する
TP、FTPS、SFTP、SCPの違いとは?WEB制作のプロが解説
特徴 | FTP (File Transfer Protocol) | FTPS (FTP Secure) | SFTP (SSH File Transfer Protocol) | SCP (Secure Copy Protocol) |
---|---|---|---|---|
プロトコル | TCP/IP | TCP/IP | SSH (Secure Shell) | SSH (Secure Shell) |
暗号化 | なし | TLS/SSLによる暗号化 | SSHによる暗号化 | SSHによる暗号化 |
認証方法 | ユーザー名・パスワード | ユーザー名・パスワード、証明書 | SSH鍵認証またはパスワード | SSH鍵認証またはパスワード |
セキュリティ | 低い(暗号化なし) | 高い(TLS/SSL暗号化あり) | 非常に高い(SSH暗号化あり) | 非常に高い(SSH暗号化あり) |
ポート番号 | 21番 (デフォルト) | 21番 (Explicit) または 990番 (Implicit) | 22番 (デフォルト) | 22番 (デフォルト) |
通信の方式 | クライアント・サーバー間の平文通信 | クライアント・サーバー間で暗号化された通信 | SSHを介して暗号化された通信 | SSHを介して暗号化された通信 |
転送の効率 | 高速 | FTPと同様 | SCPより遅い | SFTPより速い |
転送の再開 | 可能 | 可能 | 可能 | 不可 |

HULFTの特徴
DMS Cube 第1回:HULFTの基本機能
- HULFTはP2Pで転送を行う
- 配信=ファイルを送る、集信=ファイルを受け取る
- ホスト = HULFTが搭載されたプラットフォーム
- 2種類のポートがある
- 集信ポート:ファイル転送用のポート
- 要求受付ポート:命令を受け取るためのポート
- 集配ホストにはそれぞれファイルIDに紐付けた転送情報を設定する
- 両ホストでファイルIDが一致していないと転送できない

HULFTの具体的な転送の仕組み
HULFTとは|ファイル転送の具体的な仕組みを見てみよう(前編)
HULFTとは|ファイル転送の具体的な仕組みを見てみよう(後編)
1. TCP接続と初期設定
配信側ホストは、集信側ホストへとTCP SYNパケットを送信し、集信側ホストはTCP SYN+ACKパケットを返します。
集信側ホストからのTCP SYN+ACKを受け取った配信側ホストはTCP ACKを返し、TCPの3 way handshakeが完了します。
TCP 3 way handshake でコネクションを確立する。
SSL/TLSハンドシェイクとは異なるので注意。SSL/TLSはTCPコネクションの確立後に実施される「セキュアな通信」のためのハンドシェイクで、TCP接続が基本的な通信路を提供した後、SSL/TLSはその上に暗号化と認証を追加する。
SSL/TLSハンドシェイクは実施しないので、送受信するデータは平文のままネットワーク上を流れることになるため、第三者による盗聴や改ざんのリスクがある。(HULFTでの暗号化はしているけど)
集信側ホストは、TCP接続を要求してきた配信側ホストが接続許可リストに登録された相手であるかどうかを確認します。接続許可リストに登録されていない相手からのTCP接続は、TCP接続確立直後に切断されます。
意図しない相手からのTCP接続は切断する機能がある。
2. TCP接続によるファイル転送処理
TCPセッション確立後に、配信側から集信側へとファイルが転送されていきます。
ここでも、HULFTの工夫があります。
HULFTは、TCPを利用たセッションのうえで、ファイルを小分けにして送信しています。小分けにされたファイルデータが集信側に届くと、集信側はどこまで受信完了したのかに関する情報を、配信側に通知しています。
ネットワークを通じてデータが届いたかどうかを知るには、通信相手が「どこまで届いたか」に関する通知を戻すようなプログラムを作成する必要がありますが、HULFTでは、そういった機能が最初から組み込まれています。
「どこまで送ったか」ではなく、「どこまで相手が受け取ったか」を配信側で確認できる機能がある。
3. ファイル転送の完了とTCP接続の終了
配信側は、ファイルのすべてのデータを集信側へと送信後に、「これでファイルをすべて送信しました」という通知を送ります。その通知を受けた集信側は、受け取ったファイルサイズなどをチェックすることによって、ファイルが正しく転送されたかを確認します。
集信側は、ファイルに対する書き込みを終了後に、ファイル転送が正常に終了したことを配信側に伝えます。
ファイル転送前後に行われる処理
配信側で行われる転送前処理は、ファイル入力、コード変換、圧縮、暗号化、転送の順番で配信が行われます。
コード変換、圧縮、暗号化のファイル転送に付随する処理は、すべてのファイル転送でこれらが必ず行われるわけではありません。管理者は、どのファイル転送に対してどのような前後処理が行われるのかを設定可能です。たとえば、ある特定の種類のファイルに対しては転送前にコード変換を行ったり、他のファイルには圧縮や暗号化を行うといった設定も可能です。

HULFTを使ったインターネット通信のセキュリティ
疑問
HULFTで暗号化を実施してインターネット経由で転送した場合、
FTP, FTPS, SFTP&SCP と比較してどれくらいセキュアと言えるのか。
予想:TCP/IPプロトコルで独自の暗号化を施しているので、TLS/SSL暗号化したFTPSと同程度のセキュリティレベルと言える。
インターネット経由での転送について
非推奨。
ホスト名の解決、TCP/IPでの通信という条件を満たせば通信可能ですが、
HULFTには通信経路をセキュアに保つ機能がございませんので利用をご推奨できません。
通信経路をセキュアに保つ機能 = SSL/TLS とか SSHとかを指していると解釈。
ホスト名の解決とは、以下のことっぽい。
HULFTはやり取りするHULFT同士で「ホスト名」にて互いを認識している状態(pingがホスト名で通る状態)が利用の前提
自前でDNSサーバを建てる(大規模)、 もしくはhostsファイルの編集が必要。
IPが変わらない限り、相手方のホスト名は任意に設定が可能。
つまり、サーバー更改でサーバ名が変更になっても、IPさえ変わらなければ相手方の名前解決手段も修正不要。
HULFTの暗号化方式
暗号化方式は結論3種類。
HULFTではファイル転送の中で暗号化・復号化を行うことができます。
選択可能な暗号化方式は、下記の通りです。(1)HULFT暗号化方式HULFT独自の手法による暗号化(SSLやHTTP-Sは使用しておりません。)
20byteの共通キー(ユーザー指定)を基に160bitの秘密キーで暗号・複合化する共通鍵方式(2)C4Sによる暗号化方式(暗号オプションにて提供)
シーフォーテクノロジー社の暗号化機能「C4S」の利用が可能です。(3)AES暗号による暗号化方式(暗号オプションにて提供)
AES(Advanced Encryption Standard)はFIPS197として規定された暗号アルゴリズムであり、日本の電子政府推奨暗号にも選ばれています。
どの方法でも恐らく仕組みは同じ。
配信ホストのHULFTが暗号化 → 転送 → 集信ホストのHULFTが複合化。
TLSとの比較
- データの秘匿性は同様に確保できるので、傍受されても内容を解読されるリスクは低い。
- データ改ざんの防止はできない。受け取った後の検知はHULFTの機能とで可能
- 暗号化の範囲がデータのみ。通信プロトコル全体は暗号化されない。
項目 | HULFTの暗号化 | TLS |
---|---|---|
暗号化の範囲 | ファイルやデータ全体を暗号化 | 通信プロトコル(セッション)全体を暗号化 |
通信中の保護 | データが暗号化されるため、傍受されても読めない | 全通信が暗号化され、改ざん防止も可能 |
改ざん検出 | データの改ざん検出はHULFT機能として可能 | 改ざん防止機能あり |
相互認証の有無 | ホワイトリスト形式 | TLS証明書によるサーバー・クライアント認証 |
暗号化対象の管理 | ファイルごと(HULFT内部のデータ) | セッション全体(すべての通信内容) |
結論
FTP < FPTS =< HULFT < FPTS&SCP
以下の理由で、FTPSと同程度もしくは少しセキュア(データの秘匿性がある)と考える。
SSH接続と比べると、セキュリティの度合いは下がる。
- データ転送がファイル単位で暗号化され、通信経路上で平文が露出しない。
- ホワイトリスト形式による厳格な相互認証。
- セッション自体は暗号化されない。

セキュアなインターネット転送
セキュアにインターネット経由の転送を行うための手段として、推奨されている製品が2つある。
HULFT10 Smart Proxy
データ連携の中継機能に特化したインターネット対応プロキシです。
オンプレミスに導入されるHULFTと各種クラウドサービスを中継することで、安全に接続します。
HULFT転送を中継し、WSS(WebSocket over SSL/TLS) 技術にてインターネットのセキュア転送を実現する「HULFT10 Smart Proxy」が登場
HULFT10のラインナップ
「HULFT」をメジャーバージョンアップ 12月10日から提供開始
HULFT転送を中継し、WSS(WebSocket over SSL/TLS) 技術にてインターネットのセキュア転送を実現する「HULFT10 Smart Proxy」が登場
WSS技術でセキュア転送を実現するっぽい。
ここで言っているセキュア転送はSSL/TLSのことだと思うので、従来のTCPセッション自体を暗号化できるようにしたと。
HULFT-WebConnect
こちらもTLS暗号経路で通信をできるようにしたもの。
HULFT-WebConnectは、HULFT専用のインターネットVPN(TLS暗号経路)を提供するクラウドサービスです。
HULFT自体が備えるファイル暗号化や検証機能などの機能に加え、通信経路でのTLS通信の常時適用や、転送経路でディスクにデータを残さないオンメモリ中継など、インターネットを経由した利用でも安全・安心のセキュリティ機能を提供します。
結局こっちも WebSocketで繋いでいるみたい。
インターネット経由での転送に絞って見れば、中継サーバをオンプレとクラウドのどちらで使用するかの違いに見える。
HULFT-WebConnectは、WebSocketを利用しています。
HULFTは独自プロトコルを利用しており、HULFTプロトコルを直接扱えないファイアウォールなどのセキュリティ機器がありますが、WebSocketを利用するHULFT-WebConnectであれば、ファイアウォールなどで設定を行いやすくなっています。
ファイアウォールにとっては、HULFT-WebConnectの通信はWebSocketによるHTTPSとして扱えるのです。
パブリックなインターネットを介してHULFTを利用できるHULFT-WebFileTransferとHULFT-WebConnect

VPNとTLSとWebsocketの関係性
VPNとTLSとWebsocketの整理でVPN(TLS暗号経路)やWebSocketの関係を整理した。

WebConnectは何をやっているのか
WSS通信を両ホストからWebSocketサーバに対して確立して、WebSocketサーバを中継してファイルの授受を行う。
WSS通信なのでSSL暗号化されており、WebSocketコネクションが実質SSL-VPNのように振る舞う。
HULFT-WebConnectでは、ファイアウォール内のエージェントがHULFT-WebConnectの中継サービスへWebSocketによる接続を行います。そのエージェントが確立したWebSocketでの接続を通じてHULFT同士が双方向で通信できるようになります。
HULFT-WebConnectとエージェントの間がTLSで暗号化され、そこを通過するデータもHULFT暗号で暗号化されるため、2重の暗号化が行われることになります。
パブリックなインターネットを介してHULFTを利用できるHULFT-WebFileTransferとHULFT-WebConnect

SmartProxyは何をやっているのか
やっていることはWebConnectと同じで、WSS通信でクライアント間のファイル授受を行う。
WebSocketサーバをオンプレミスで建てる部分が異なる。
機能
- REST API でHULFTの集配信をキックできる
- WSSでHULFTの通信を中継する(WebConnectと同じことができる)
HULFT10 Smart Proxyのサーバーモジュールで、HULFT間の通信を中継する機能
主に、HULFTをインターネット経由でご使用になる場合の機能です。
詳細は、「WebSocket Secure(WSS)でHULFTへの通信を中継する」を参照してください。
構成
NginxのWebサーバ上でSmart Proxyは動作する。
APIサーバ、WSSサーバーとしての役割がある。
HULFT10 Smart Proxyをご使用いただくには、図1.1 のとおり、HULFT10 Smart Proxyの他にNginxとPostgreSQLのインストールが必要です。
WSSサーバー:HULFT10 Smart Proxy(WSS)
HULFT間の通信を中継するサーバーモジュールです。
インターネット経由でファイルを転送するために使用します。

疑問点
- SmartProxyやWebConnectを経由しない場合、TLS通信できないためセキュリティが担保されないという意味か。
- その場合、一般的にTLS通信で担保される以下の3要素に対しては以下の認識であっているか
- 盗聴防止: セッション自体は暗号化されないが、データ本体はHULFT暗号化される。
- 改竄防止: 防止機能はないが、HULFT機能で最終的に改ざんを検知できる。
- なりすまし防止: TCP接続時にホワイトリスト形式で相手ホストのサーバを確認する。
- その場合、一般的にTLS通信で担保される以下の3要素に対しては以下の認識であっているか
- SmartProxyやWebConnectも、WebSocket中継サーバを経由したWSSコネクションを貼ることでホスト間のTLS通信を確立し、SSL-VPNのような振る舞いを可能にする認識で良いか。
- セキュアなインターネット通信に絞れば、SmartProxyやWebConnectはWSSサーバがオンプレかクラウドかの違いと解釈できるか
- SmartProxyをDMZに1つ建てておけば、2拠点間で双方のファイル授受をWSSで中継できるのか
- ファイル授受を行うクライアントはSmartProxy(Nginx)とのWebSocketハンドシェイクを貼りっぱなしにしておく必要があるのか。タイムアウトした場合の再接続は必要になるのか。
- HULFT10 → SmartProxy or WebConnect → HULFT8 の接続は可能か。