LASSIC Media らしくメディア
セキュアファイル転送(MFT)｜大容量データを安全に外注
LASSIC IT事業部｜元請（プライムベンダー）として大容量・機密データのセキュアファイル転送(MFT)基盤の開発・運用を受託
この記事のポイント
- セキュアファイル転送(MFT)とは、大容量・機密のファイルを企業間・システム間でセキュアに受け渡す基盤です。手作業のメール添付やFTPから脱却し、通信の暗号化・送受信者の認証・転送の監査を伴います。AWS Transfer FamilyはSFTP・FTPS・FTP・AS2やブラウザー経由の転送に対応するマネージドサービスです。
- 核となるのは、(1)暗号化(転送中/保存時)と認証、(2)監査ログと可視化、(3)再送・エラー処理、(4)自動化・ジョブ化の4点です。iPaaS(システム連携)や単純なファイル共有とは、扱う対象と粒度が異なります。
- 外注では、対応プロトコルと既存取引先クライアントの互換性、暗号化・認証・鍵運用、監査ログと再送設計、自動化とコンプライアンス要件まで、一貫して担える体制かどうかが確認の軸になるでしょう。
目次
メール添付・FTPの手作業が抱えるリスク——大容量・機密ファイルの授受はなぜ危ういのか
取引先へ渡す大容量の設計データ、金融機関とやり取りする明細ファイル、医療や人事にかかわる機密情報——。企業間・システム間のファイル授受は、事業の根幹を支える日常業務です。ところが、その多くはいまだにメール添付や旧来のFTP、手作業の運用に頼っているのが実情でしょう。
手作業のファイル授受には、いくつもの弱点が潜んでいます。たとえばメール添付には容量の上限があり、大容量ファイルは分割や別サービスへの退避を迫られがちです。旧来のFTPには通信を暗号化しない構成も残り、経路上でファイルを覗き見られるリスクがつきまといます。そして厄介なのが、誰がいつ何を送受信したのかという証跡の乏しさでしょう。送信ミスや宛先の誤りに後から気づけないまま、機密情報が外部へ流れてしまう事故につながりかねません。
こうした運用は、担当者個人の注意力と経験に依存しがちです。手順が属人化すると、担当者の異動や退職で運用が揺らぎ、監査対応を求められた際に「いつ・誰が・何を」を示せない事態も起こります。ファイルの本数や取引先が増えるほど、この綻びは広がっていくのです。だからこそ、暗号化・認証・監査・自動化を一貫して備えたファイル転送の基盤——セキュアファイル転送、いわゆるMFT(Managed File Transfer)が必要になります。
本稿では、MFTとは何をする基盤なのか、当サイトで別途扱うiPaaS(システム連携)やオンラインストレージ的なファイル共有とどう違うのか、そして開発・運用を外注する際にどこを確認すべきかを、公式情報に基づいて整理していきます。想定する読者は、ファイル転送基盤の発注を検討するIT部門の意思決定層の方々です。
セキュアファイル転送(MFT)とは、大容量・機密ファイルを暗号化して受け渡す転送基盤
MFT(Managed File Transfer)とは、大容量・機密のファイルを企業間やシステム間でセキュアに受け渡し、その転送を一元的に管理する基盤を指します。単にファイルを送るだけでなく、通信の暗号化、送受信者の認証、転送の証跡(監査ログ)、失敗時の再送やエラー処理までを含めて「管理された(Managed)」転送を実現する点が特徴でしょう。
こうしたファイル転送を支えるのが、標準化された転送プロトコルです。AWSのマネージドサービスであるAWS Transfer Familyは、SFTP、AS2、FTPS、FTP、およびWebブラウザー経由の転送に対応すると説明しています*1。中心となるSFTP(SSH File Transfer Protocol)は、マイクロソフトによればSFTPクライアントでストレージへセキュアに接続し、ファイルのアクセス・転送・管理を行える仕組みです*2。いずれも、公衆網を越えるファイル授受を暗号化された経路で担うための土台になります。
AWSは、こうしたファイル転送のワークフローが金融、ヘルスケア、広告、小売など幅広い業界のデータ交換で使われていると述べています*1。とりわけAS2は、データ保護とセキュリティをプロトコルに組み込んだ、コンプライアンス要件を伴うB2B(企業間)取引やサプライチェーン、決済のワークフローで用いられます*1。取引先との継続的なファイル授受を、標準に沿ってセキュアに回し続けることがMFTの狙いなのです。
MFTを「単なる送信ツール」と捉えると、その価値を見誤ります。要は、転送そのものを統制し、暗号化・認証・監査・再送・自動化までを一つの運用として束ねる基盤である、という理解が出発点になるでしょう。
iPaaS(システム連携)・ファイル共有との違い——MFTが担う「管理された転送」
MFTを検討する際に混同されやすいのが、iPaaS(システム連携)やオンラインストレージ的なファイル共有との違いです。当サイトでもiPaaSによるシステム連携やファイル共有は別途取り上げていますが、MFTが担う領域はそれらとは異なります。ここで境界を整理しておきましょう。
iPaaS(Integration Platform as a Service)が主に相手にするのは、業務システム同士のAPI連携やデータ連携です。SaaSと基幹システムをつなぎ、受注や在庫といったデータ・イベントをレコード単位で同期・変換する領域に強みがあります。一方のMFTが扱うのは、レコードではなくファイルそのもの——それも大容量・機密のファイルを、まとまりとしてセキュアに運ぶことです。連携の粒度と対象が異なるわけです。
オンラインストレージ的なファイル共有は、人と人が資料を置いて共有する用途に向いています。リンクを配ってダウンロードしてもらう手軽さが持ち味です。ただし、取引先システムとの自動連携、通信経路の暗号化方式の指定、送受信の詳細な監査ログ、失敗時の再送といった「管理された転送」の要件までは、十分に満たすとは限りません。MFTは、この管理・統制の部分に重心を置く点で一線を画すのです。
3者の違いを整理すると、次の通りです。
| 観点 | MFT(セキュアファイル転送) | iPaaS(システム連携) | ファイル共有(オンラインストレージ) |
|---|---|---|---|
| 主な対象 | 大容量・機密ファイルの転送*1 | システム間のAPI・データ連携 | 人と人の資料共有 |
| 主な目的 | 暗号化・認証・監査を伴うセキュアな受け渡し*1 | データ・イベントの同期と変換 | 保管とダウンロード共有 |
| 転送の単位 | ファイル(まとまり) | レコード・メッセージ | ファイル(手動共有が中心) |
| 改ざん・証跡対策 | 暗号化・監査ログ・再送*2*3 | 連携ログが中心 | 共有履歴が中心 |
要件定義の段階で「どの基盤に何を任せるか」を先に切り分けておくと、機能の重複投資や責任の空白を避けやすくなります。MFTは、大容量・機密ファイルのセキュアな転送と、その統制に特化した領域だと押さえておきましょう。
MFTの機能要素——暗号化と認証・監査ログ・再送・自動化
MFT基盤の中身を、機能要素に分解して見ていきます。ここを理解しておくと、外注時の要件定義でどこに工数がかかるかを判断しやすくなるでしょう。核となるのは、暗号化と認証、監査ログ、再送・エラー処理、自動化・ジョブ化の4点です。
暗号化と認証——転送中・保存時の保護と、送受信者の確認
第一の要素は、通信の暗号化と、送受信者の認証です。SFTPはSSH(Secure Shell)の上でファイルを転送するため、経路上の通信が暗号化されます。マイクロソフトのAzure Blob StorageのSFTP実装では、認証にパスワードまたはSSHの公開鍵・秘密鍵ペアを用い、暗号方式としてaes256-gcmやaes256-ctrといった強度の高い暗号が使われると示されています*2。
暗号化は転送中(通信経路)だけでなく、保存時(サーバー上のファイル)にも及ぶ点が重要でしょう。AWS Transfer Familyは、転送したファイルを耐久性の高いAmazon S3ストレージに保存でき、保存後はAWSのサービスで処理・分析・監査・アーカイブに活用できると説明しています*1。暗号の強度そのものも、年々更新されているのが実態です。AWSは、将来の量子コンピューターによる解読にも耐えるよう設計されたポスト量子暗号を含む、強力な暗号スイートを提供していると述べています*4。加えて同社の資料では、SOC・PCI・HIPAA・FedRAMPといった規制の枠組みへの準拠にも触れられています*4。認証と暗号の強度、そして規制対応こそが、機密ファイルを扱う基盤の土台になるのです。
監査ログと可視化——「いつ・誰が・何を」を追跡できる証跡
第二の要素は、監査ログと可視化です。誰がいつ何を送受信したのかを記録し、後から追跡できることは、機密ファイルを扱ううえで欠かせない要件でしょう。この点でAWS Transfer Familyのマネージドワークフローは、B2Bのファイル交換のコンプライアンス要件を満たしつつ、エンドツーエンドの監査と可視性を提供するとされています*3。実際、各ワークフローのステップは詳細なログを出力し、データの来歴(リネージ)を追跡できると記されています*3。転送そのものが証跡として残るため、監査対応や事故時の原因追跡がしやすくなるわけです。
再送・エラー処理——失敗を検知し、取りこぼしを防ぐ
第三の要素は、再送とエラー処理です。通信断や不正な形式のファイルは、現場では避けて通れないものでしょう。AWS Transfer Familyのマネージドワークフローには組み込みの例外処理があり、ファイル処理の結果に応じて指定した例外ステップを実行できます*3。たとえば想定した形式でないファイルがアップロードされた際に、管理者へメールで通知するといった処理を組めるとされています*3。セッションの途中切断で部分的にしかアップロードされなかったファイルには、アップロードが完了したファイルとは別のワークフローを割り当てられる点も特徴でしょう*3。こうした仕組みが、転送の失敗を検知して次の手を打つ運用を支えるのです。
自動化・ジョブ化——転送後の処理を人手を介さず流す
第四の要素は、自動化とジョブ化です。手作業の授受から脱却する肝は、転送後の処理を人手を介さずに流せるかどうかでしょう。AWS Transfer Familyのマネージドワークフローは、SFTP・FTPS・FTPでファイルが転送された後にワークフローを起動できると説明しています*3。処理の例として、ファイルの移動、復号、タグ付け、AWS Lambda関数による独自処理、転送成功時の通知などが挙げられています*3。つまり「受け取ったら所定のフォルダーへ移し、復号し、後続システムへ渡す」といった一連の流れをジョブとして定義し、標準化できるわけです。メール受信を人が待って手作業で捌く運用と比べれば、再現性も監査性も大きく変わってきます。
MFT基盤の構築・運用を外注する際に確認したい4つの点
MFTは、ツールを導入すれば完結する性格のものではありません。自社のファイル授受の実態を棚卸しし、暗号化と認証を設計し、監査と再送を運用に組み込み、自動化までを描く設計に成否がかかっています。外注を検討する際は、次の4点を委託先と確認しておくとよいでしょう。
第一に、対応プロトコルと既存取引先クライアントとの互換性です。SFTP・FTPS・AS2のどれを使うのか、取引先が既に使っているクライアントや認証・アクセス・ファイアウォールの設定を変えずに移行できるのかを確認します*1。AWSは、既存のクライアント側の設定を維持したまま移行・自動化・監視ができると述べており、取引先への影響を抑える設計が現実的でしょう*1。
第二に、暗号化・認証・鍵運用まで担えるかです。転送中と保存時の暗号化方式、SSH公開鍵やパスワードによる認証、そしてPGPなどの鍵の管理・更新まで、運用として回せるかを見ます*2*4。鍵の取り違えや期限切れは転送停止に直結するため、鍵運用の設計力が問われるところでしょう。
第三に、監査ログと再送・エラー処理を運用に落とし込めるかです。誰がいつ何を送受信したかの記録、失敗時の再送や例外処理、部分アップロードへの対応までを設計できるかを確認します*3。監査対応やインシデント時の原因追跡を見据え、ログの取得範囲と保管方針を先に決めておくことが望まれます。
第四に、自動化・ジョブ化とコンプライアンス要件への適合です。転送後の移動・復号・通知といった処理をジョブとして標準化できるか、そして扱う情報の機密区分に応じた統制を組み込めるかを見ます*3。IPA(情報処理推進機構)の「中小企業の情報セキュリティ対策ガイドライン」でも、顧客情報や機密情報など漏えい時の影響が大きい情報は暗号化して保存・通信することが求められています*5。これらは、複数の専門領域にまたがる取り組みです。プロトコル対応から暗号・鍵運用、監査・再送設計、自動化までを一貫して担える体制が前提になります。現状のファイル授受を診断したうえで、内製と外注の切り分けを検討することが実務的でしょう。
まとめ：セキュアファイル転送(MFT)で押さえる3つの要点
本稿では、セキュアファイル転送(MFT)の仕組みと外注時の確認点を、公式情報をもとに整理しました。要点は3つに集約できます。第一に、MFTとは大容量・機密のファイルを企業間・システム間でセキュアに受け渡し、暗号化・認証・監査・再送・自動化までを一元管理する基盤です。AWS Transfer FamilyはSFTP・FTPS・AS2などに対応するマネージドサービスとして提供されています*1。第二に、iPaaS(システム連携)や単純なファイル共有とは対象が異なり、MFTは大容量・機密ファイルのセキュアな転送とその統制に特化します*2*3。第三に、暗号化と認証・監査ログ・再送とエラー処理・自動化という4つの機能要素を一貫して回せる体制かどうかが、外注の分かれ目になるでしょう*3*4。ファイル授受は事業の信頼を支える土台だけに、統制の質がそのまま情報漏えいリスクの低減につながります。
よくある質問
MFTは、iPaaSやオンラインストレージのファイル共有と何が違うのですか。
対象が異なります。iPaaS(システム連携)は業務システム同士のAPI・データ連携を、ファイル共有は人と人の資料共有を主に担います。これに対しMFTは、大容量・機密のファイルを企業間・システム間でセキュアに受け渡し、暗号化・認証・監査・再送・自動化まで一元管理する基盤です。AWS Transfer FamilyはSFTP・FTPS・FTP・AS2やブラウザー経由の転送に対応します*1。3者は競合ではなく、扱う対象と粒度で棲み分けるものと整理できます。
SFTPとはどのようなプロトコルですか。盗み見を防げるのでしょうか。
SFTP(SSH File Transfer Protocol)は、SSHの上でファイルにアクセス・転送・管理を行うプロトコルです。マイクロソフトは、SFTPクライアントでBlob Storageへセキュアに接続してファイルを扱える仕組みだと説明しています*2。認証はパスワードまたはSSHの公開鍵・秘密鍵ペアで行うのが基本です。通信の暗号にはaes256-gcmやaes256-ctrといった強度の高い方式が使われます*2。経路上の通信が暗号化されるぶん、旧来の平文FTPに比べ盗み見のリスクを抑えられます。ただし鍵やパスワードの管理を誤ればセキュリティは損なわれるため、認証情報の運用設計もあわせて重要になるでしょう。
大容量ファイルの授受でメール添付やFTPを続けると、何が問題になりますか。
メール添付には容量の上限があり、大容量ファイルの授受には向きません。旧来のFTPには通信を暗号化しない構成も残るため、経路上でファイルを覗き見られるリスクを抱えます。さらに、送受信の詳細な証跡が残りにくく、誰がいつ何を送ったのかを後から追えないことも少なくないでしょう。MFTは、暗号化・認証に加え、エンドツーエンドの監査と可視性を備えることで、これらの弱点を補います*3。
MFTでは、ファイルを受け取った後の処理を自動化できますか。
はい、可能です。AWS Transfer Familyのマネージドワークフローは、SFTP・FTPS・FTPでファイルが転送された後に処理を起動できると説明しています*3。処理の例として、ファイルの移動、復号、タグ付け、AWS Lambda関数による独自処理、転送成功時の通知などが挙げられています*3。失敗時には組み込みの例外処理が働き、指定した例外ステップが実行されるのも特徴です*3。手作業の授受をジョブとして標準化でき、再現性と監査性を高められる点が利点でしょう。
MFT基盤の構築・運用を外注する場合、何を基準に委託先を選べばよいですか。
対応プロトコルと既存取引先クライアントとの互換性、転送中と保存時の暗号化と鍵運用、監査ログと再送・エラー処理の運用設計、自動化・ジョブ化とコンプライアンス要件への適合——この4点を確認するとよいでしょう*1*2*3。MFTは、暗号や鍵、監査、自動化など複数領域にまたがるため、これらを一貫して担える体制が前提になります。IPAのガイドラインが示すとおり、機密情報は暗号化して保存・通信することが求められる以上、扱う情報の機密区分に応じた統制まで提案できる委託先が望ましいといえます*5。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Amazon Web Services「What is AWS Transfer Family?」（AWS Transfer Family User Guide）（https://docs.aws.amazon.com/transfer/latest/userguide/what-is-aws-transfer-family.html）
- *2 出典：Microsoft「SFTP support for Azure Blob Storage」（Azure Storage ドキュメント）（https://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support）
- *3 出典：Amazon Web Services「AWS Transfer Family managed workflows」（AWS Transfer Family User Guide）（https://docs.aws.amazon.com/transfer/latest/userguide/transfer-workflows.html）
- *4 出典：Amazon Web Services「How Transfer Family can help you build a secure, compliant managed file transfer solution」（AWS Security Blog、2024年1月3日）（https://aws.amazon.com/blogs/security/how-transfer-family-can-help-you-build-a-secure-compliant-managed-file-transfer-solution/）
- *5 出典：独立行政法人情報処理推進機構(IPA)「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（https://www.ipa.go.jp/security/guide/sme/ug65p90000019cbk-att/sme_guideline_v4.0.pdf ）
