FTPのままで大丈夫？ファイル転送のプロトコルと暗号化方式の決め方
GoAnywhere2026.11.16
長年利用してきたFTPによるファイル転送について、取引先から「SFTPに変更してほしい」と求められたり、監査で通信方式を問われて現状の見直しが必要になることがあります。特にインターネット経由でFTPを使い続けている場合、情報漏洩リスクや監査指摘の対象になりやすく、対応を先送りにしにくい状況が増えています。
本コラムでは、FTPとSFTPの違いや平文通信のリスク、監査対応に向けて優先的に点検すべき観点などを整理します。
基幹システムの刷新や取引先の追加に合わせて、個別スクリプトでファイル転送を実装してきた企業は少なくありません。 当初はシンプルな1対1の連携として作られたものが、年数を重ねるうちに本数が増え、プロトコルや認証方式が混在した状態になっていることがあります。
そうした環境では、以下のような状況となることがあります。
こうした状態は、処理として正常に動いているうちは見過ごされがちです。しかし、取引先からの要請や監査指摘が入った段階で、対応に時間を要する場面につながります。
FTPは、ファイル転送のための代表的なプロトコルですが、通信内容を暗号化しない仕様です。認証情報や転送するファイルの内容が平文のままネットワーク上を流れるため、通信経路の途中で傍受された場合に情報漏洩へつながる可能性があります。
一方のSFTPは、SSHの仕組みを利用して通信全体を暗号化するプロトコルです。認証情報と転送データの両方が保護されるため、インターネット経由のファイル授受でも利用しやすい方式です。
社内ネットワーク内であっても平文通信が望ましいわけではありませんが、特に監査で指摘を受けやすいのはインターネット経由でFTPを使っているケースです。取引先から「FTPはセキュリティ上使用できないためSFTPへ変更してほしい」と要請されるパターンも実際に発生しており、通信方式の見直しは取引継続に関わる論点にもなり得ます。
平文通信によるリスクは情報漏洩だけにとどまらず、認証情報が漏れた場合の不正アクセスや、改ざんの検知が難しいという課題にもつながります。
SFTPへの対応が必要になった際、既存の個別スクリプトを一つずつ改修していく方法と、SFTPに標準対応した製品へ移行する方法があります。どちらを選ぶかは、連携本数と運用上の課題の深さによって変わってきます。
判断の目安として、次のような観点が挙げられます。
連携本数が少なく、担当者が仕様を把握している場合は個別改修で対応できることもあります。 一方、本数が増えてきている場合や、スクリプトの作成者がすでにいない場合には、改修のたびに要件確認からやり直す負荷が発生します。 そうした状況では、SFTP対応と同時に管理ポイントを集約できる製品への移行を検討する判断が現実的になります。
GoAnywhere MFTのような統合基盤へ移行する場合でも、既存のすべてを置き換える必要はありません。管理が煩雑になっている部分から段階的に集約していく進め方が可能です。
セキュリティ監査で指摘を受ける前に、自社の現状を点検するためのチェック項目を整理しておくと、対応の優先順位をつけやすくなります。
個別スクリプトでの運用では、エラーハンドリングや通知機能が十分に組み込まれていないケースや、エラーをテキストログに記録するだけでアラートが発報されないケースも見られます。権限設計も後回しになりがちで、必要以上の権限で動作している処理が残っていることがあります。
監査対応は、通信プロトコルの変更だけで完結するものではなく、ログ・権限・運用手順を含めた全体の点検として捉える必要があります。
インターネット経由でFTPを使い続けている状態は、情報漏洩のリスクと監査指摘のリスクを抱えやすい運用です。 取引先からSFTPへの切り替えを求められてから対応に動くのではなく、現状の通信方式を棚卸しし、優先度の高い連携から見直しを進める姿勢が求められます。
連携本数が増え、スクリプトの作成者がすでにいない状況では、個別改修を重ねるよりも、SFTP対応と管理の集約を同時に進められる製品への移行が選択肢になります。GoAnywhere MFTは、通信プロトコルの標準対応に加えて、ログ管理、権限管理、エラー通知などの運用要件を一つの基盤で管理できる仕組みを備えています。
SOLPACでは、既存の個別スクリプトの棚卸しや要件整理の段階から支援を行い、現状の運用に合わせた移行の進め方をご提案しています。FTPの見直しや監査対応のご検討がありましたら、お気軽にご相談ください。
ご要望に合わせて御見積もりを作成します。 サービスの詳細資料もこちらからお問い合わせください。