🗃️
そうだ、SFTPを作ろう（技術選定編）
はじめに
こんにちわ。
先日 SFTP (SSH File Transfer Protocol) を社内でホスティングする要件があり、その際にメンバーと色々と議論しましたので、今回はそれの技術選定をADRという内容で共有させていただきます。
ADRとはなんだろう
詳しくはこちらをどうぞ。今回のフォーマットもここから転用します。
前提
今回はブログ用にAWSを使用する前提とさせて頂きます（実際に弊社で採用したのはGCPでしたが、同じだと執筆するモチベーションが出なかったので変更させてください）。
COMMON-SFTP-001: AWSを使用したSFTP共通サービスアーキテクチャの設計
ラベル
- アーキテクチャ
- セキュリティ
- インフラストラクチャ
- ファイル転送
ステータス
- Proposed, As of 2024/10/25
- Approved, As of 2024/10/29
関係するチームやメンバー
- チーム: インフラストラクチャーチーム
- メンバー: アーキテクト、インフラエンジニア、セキュリティエンジニア
コンテキスト
現状、外部とのファイル転送において以下の課題が存在します：
- リクエストごとの専用インスタンス構築による時間とコストの浪費
- 標準化されていない手順による開発リスク
- セキュリティとコンプライアンスへの懸念
- 運用効率の低さ
これらの課題を解決するため、AWS上で統一されたSFTP共通サービスを構築する必要があります。
意思決定内容
AWS Transfer Family（AWS SFTP）を中心としたマネージドサービスを活用し、以下のアーキテクチャを採用します：
- 基本構成
- AWS Transfer Family: SFTPサーバーの提供
- Amazon S3: ファイルストレージ
- AWS Lambda: ユーザー認証、自動処理
- Amazon CloudWatch: モニタリングとログ管理
- AWS KMS: 暗号化キー管理
- セキュリティ設計
- VPC内での構築
- AWS PrivateLink活用による専用エンドポイント提供
- AWS WAF統合によるセキュリティ強化
- AWS KMSによる暗号化
- 運用自動化
- AWS CloudFormation: インフラのコード化
- AWS EventBridge: 自動処理のスケジューリング
- AWS Backup: バックアップ管理
検討された選択肢
（箇条書き版）
- EC2ベースの独自SFTP実装
- 利点：
- カスタマイズの自由度が高い
- 初期コストが低い
- 欠点：
- 運用負荷が高い
- スケーラビリティに課題
- セキュリティ管理が複雑
- AWS Transfer Family活用（採用）
- 利点：
- フルマネージド
- 高可用性と自動スケーリング
- セキュリティ機能の充実
- 運用負荷の大幅削減
- 欠点：
- コストがやや高い
- カスタマイズの制限
- サードパーティSFTPサービス (Marketplace)
- 利点：
- 導入が容易
- 機能が充実
- 欠点：
- AWS統合の制限
- データ所在地の制御が困難
（表形式版、こちらの方が見やすいか？）
| 選択肢 | メリット | デメリット | 概算コスト | 運用負荷 | セキュリティ | スケーラビリティ |
|---|---|---|---|---|---|---|
| EC2ベースの独自SFTP実装 | ・カスタマイズの自由度が高い ・初期コストが低い ・細かな制御が可能 ・ライセンスコストなし |
・運用負荷が高い ・スケーラビリティに課題 ・セキュリティ管理が複雑 ・高可用性の実現に追加工数が必要 ・監視・バックアップの個別実装が必要 |
低 （EC2インスタンス費用のみ） |
高 （構築・運用・保守すべて自前） |
中 （自前での実装・管理が必要） |
低 （手動でのスケーリングが必要） |
| AWS Transfer Family （採用） |
・フルマネージド ・高可用性が標準装備 ・自動スケーリング ・AWSサービスとの容易な統合 ・セキュリティ機能が充実 ・運用負荷の大幅削減 ・コンプライアンス対応が容易 |
・コストがやや高い ・カスタマイズに一部制限あり ・AWS環境に依存 |
中〜高 （転送時間と データ量に応じた課金） |
低 （AWSによるマネージド） |
高 （AWSのセキュリティ機能を活用可能） |
高 （自動スケーリング対応） |
| サードパーティSFTPサービス(Marketplace) | ・導入が容易 ・豊富な機能 ・ベンダーサポートあり ・マルチクラウド対応の可能性 |
・AWS統合の制限 ・データ所在地の制御が困難 ・ベンダーロックイン ・カスタマイズの制限 ・追加ライセンス費用 |
高 （ライセンス費用＋ 利用料金） |
中 （ベンダー依存） |
中〜高 （ベンダー依存） |
中 （サービス依存） |
決定の理由
優先すべき採用基準を "今後の拡張性と量産" とし、以下の理由で決定した。
- AWS Transfer Familyを選択した主な理由：
- フルマネージドサービスによる運用負荷の削減
- AWSネイティブサービスとの優れた統合性
- エンタープライズグレードのセキュリティ機能
- 自動スケーリングと高可用性の実現
- コンプライアンス要件への適合
- アーキテクチャ上の具体的なメリット：
- S3との直接統合による効率的なストレージ管理
- IAMによる細かな権限制御
- CloudWatchによる包括的な監視
- PrivateLinkによるセキュアな接続性
予期される結果
- 定量的な改善 (サンプルを構築した実績より)：
- サービス提供までの時間を80%短縮
- 運用コストを60%削減
- システム稼働率99.99%以上の達成
- セキュリティインシデントの100%削減
- 定性的な改善：
- 標準化されたSFTP環境の提供
- セキュリティとコンプライアンスの強化
- 運用効率の向上
- スケーラブルなインフラストラクチャの実現
参照
- AWS Transfer Family ドキュメント https://docs.aws.amazon.com/ja_jp/transfer/
- AWS セキュリティベストプラクティス https://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/security.html
コンセンサス
- セキュリティチームによるセキュリティ設計の承認
- インフラチームによる運用性の確認
- コストセンターによる費用対効果の承認
後続のアクション
- 実装フェーズ
- AWS CloudFormationテンプレートの作成
- セキュリティ設定の実装
- 監視・アラート設定の構築
- 検証フェーズ
- セキュリティ評価の実施
- パフォーマンステストの実行
- 運用手順の確立
- 展開フェーズ
- パイロットユーザーによる検証
- 段階的な移行計画の策定
- ドキュメント作成と教育実施
レビュー記録
レビュー用に今回のシステム構成図をMermaid形式で記述してみました。
こうやって見ると、いくつか疑わしいものが見えてくるので設計段階で要調査とします。
- Conditional Approval, As of 2024/10/30, WAFの必要性 (SFTP Protocol に対して有効なのか)を確認すること
- Conditional Approval, As of 2024/10/30, Bucketに対してのBackupの必要性を確認すること （BCP/DR目的であれば、遠方のリージョンにて保管するなどの考慮が必要かどうか。またその保管日数はどうするべきか）
さいごに
AWSの場合は、AWS Transfer Family がありますので最初からこれ一択な気がします。時間がある時にGCPの場合も書いていきたいと思います。
Discussion