📁

そうだ、SFTPを作ろう(要件定義編)

2024/10/22に公開

はじめに

こんにちわ。
先日 SFTP (SSH File Transfer Protocol) を社内でホスティングする要件があり、その際にメンバーと色々と議論しましたので、今回はそれを要件定義という内容で共有させていただきます。

SFTPとはなんだろう

簡単に言うと「ファイル転送システム」のことです。
私がエンジニアデビューした頃はFTPが主流でしたが今はSSH化された「SFTP」しか無いですよね。(と思っていたらFTPの案件も、まだまだメインフレームやオンプレ環境だとあるようですね。。。大変そう。)
https://ja.wikipedia.org/wiki/SSH_File_Transfer_Protocol

SFTP共通サービス要件定義書

以下、ざざっと本文になります。

Title 表題

SFTP共通サービス要件定義書

概要 (Executive Summary)

本文書は、当社が構築を予定しているSFTP共通サービスの要件を記述したものです。このサービスは、社内外のパートナーとの安全かつ効率的なファイル転送を実現し、データセキュリティを強化しつつ業務プロセスを最適化することを目的としています。

企画背景・目的 (Background / Purposes)

近年、データセキュリティの重要性が増す中、従来の物理デバイスでの受け渡し、FTPやメール添付によるファイル転送では、セキュリティリスクが高まっています。また、大容量ファイルの転送やファイル転送の自動化など、より高度なニーズも発生しています。
また、それ以外にも弊社の現状課題として以下の点が挙げられます:

  • リクエストの都度、専用インスタンスを構築しており、構築時間や運用コストが大きな負担となっています。
  • 手順がマニュアル化されておらず、開発リスクが発生しています。
  • 共通化や型化が行われておらず、効率的な量産ができていません。

これらの課題を踏まえ、本プロジェクトの目的を以下とします:

  1. セキュアなファイル転送環境の提供
  2. 大容量ファイル転送の実現
  3. ファイル転送プロセスの自動化と効率化
  4. セキュリティ / コンプライアンス要件への対応
  5. 統一されたファイル転送プラットフォームの構築
  6. SFTPサービスの共通化と型化による効率的な量産体制の確立
  7. 構築時間と運用コストの大幅な削減
  8. 標準化されたプロセスとマニュアルの整備による開発リスクの低減

ユースケース (Use case)

  1. 外部パートナーとの機密データの安全な送受信
  2. 定期的な大容量データファイルの自動転送
  3. コンプライアンス監査のためのログ記録と管理
  4. クラウドストレージサービスとの連携によるハイブリッドストレージソリューション (送受信と保管の分離)

解決したい顧客の課題 / 提供したい顧客価値 (Problems to solve / Values for clients)

解決したい課題:

  1. セキュリティリスクの軽減
  2. 複雑なファイル共有システムの管理負担
  3. コンプライアンス要件への対応の困難さ
  4. リクエストの都度、新しい専用インスタンスを構築していたため、提供までに長い待ち時間が発生
  5. 個別構築によるコスト高
  6. 標準化されていない手順による開発リスクと品質のばらつき

提供したい顧客価値:

  1. 安全で信頼性の高いファイル転送環境
  2. コスト削減
    -- 統合されたプラットフォームによる管理コスト削減
    -- 共通化による構築・運用コストの大幅な削減
  3. スケーラブルで将来性のあるファイル転送ソリューション
  4. 迅速なSFTPサービスの提供
    -- 事前に構築された共通プラットフォームによる即時利用の可能性
  5. 柔軟なカスタマイズオプション
    -- 共通基盤をベースとしたカスタマイズの容易さ

ビジネスの成果、ゴールまたは指標 (KGI / KPI)

KGI (Key Goal Indicator):

  1. セキュリティインシデントの100%削減、コンプライアンス違反の完全撲滅
  2. ファイル転送関連の業務効率を50%向上
  3. SFTP構築・運用コストの60%削減
  4. SFTPサービス提供までのリードタイムを80%短縮

KPI (Key Performance Indicator):

  1. システム稼働率 99.99%以上
  2. ファイル転送速度 100Mbps以上 (仮)
  3. 月間アクティブユーザー数 100以上 (仮)
  4. SFTP共通サービスの利用率 90%以上(新規要求の内)
  5. SFTPサービスの平均構築時間 8時間以内(従来の数日〜2週間からの大幅短縮)
  6. 開発・運用担当者の工数 40%削減

ユースケース&実現方法のイメージ (Use cases & expected outcomes)

  1. 外部ユーザ企業とのデータ共有
    -- 実現方法:強固な暗号化とアクセス制御を備えた共通SFTPプラットフォームの利用
    -- 期待される成果:データ漏洩リスクの低減、セキュアな情報共有の実現、設定時間の短縮
  2. 大容量データファイルの自動転送
    -- 実現方法:スケジューリング機能とクラウドストレージ連携した高速ファイル転送システムの導入
    -- 期待される成果:人的ミスの削減、業務効率の向上、運用コストの削減、インフラ構築の簡素化
  3. コンプライアンス対応
    -- 実現方法:詳細なログ記録と分析ツールの導入、標準化された監査プロセスの確立
    -- 期待される成果:監査対応の簡素化、コンプライアンスリスクの低減、報告作業の効率化
  4. 迅速なSFTP環境の提供
    -- 実現方法:事前構築された共通SFTPプラットフォームとテンプレート化されたセットアッププロセス
    -- 期待される成果:サービス提供までのリードタイム短縮、一貫した品質の確保、リソース利用の最適化
  5. 集中管理による効率的な運用
    -- 実現方法:統合管理コンソールの導入と自動化ツールの活用
    -- 期待される成果:運用負荷の軽減、障害対応時間の短縮、リソース利用の可視化
  6. 開発プロセスの標準化
    -- 実現方法:詳細なドキュメンテーションと標準化されたワークフローの確立
    -- 期待される成果:開発リスクの低減、品質の均一化、知識移転の円滑化

機能要件 (Functional Requirements)

  1. ファイル転送機能
    -- アップロード/ダウンロード
    -- 大容量ファイル対応
    -- 自動保管(転送機能と保管ストレージの分離)と管理(期限や自動圧縮)

  2. 認証・アクセス制御
    -- SSHキー認証
    -- ディレクトリ別アクセス権限設定
    -- IPアドレスベースのアクセス制限と固定IPでの提供
    -- 再発行と失効

  3. 暗号化
    -- アクセスキー
    -- 転送時のSSL通信の暗号化
    -- 保存データの暗号化

  4. ログ管理
    -- 詳細なアクセスログ記録
    -- ログの暗号化と改ざん検知

  5. 自動化・連携
    -- ファイル転送のスケジューリング
    -- クラウドストレージ連携

  6. 管理機能
    -- ユーザー/グループ管理
    -- クォータ設定
    -- システム状態監視

非機能要件 (Non-Functional Requirements)

  1. 性能
    -- 同時接続数:100 endpoints
    -- ファイル転送速度:最低50M bps
    -- 大容量ファイル:1ファイル 500G Byte 以上

  2. 可用性
    -- システム稼働率:99.99%以上
    -- 障害時の自動フェイルオーバー
    -- バックアップと災害復旧対策

  3. セキュリティ
    -- 最新の暗号化プロトコル対応
    -- 定期的なセキュリティ監査
    -- コンプライアンス対応

  4. 拡張性
    -- ユーザー数とストレージの柔軟な拡張
    -- クラウドサービスとの連携

  5. 運用・保守
    -- 24h/365d 監視体制と通知機能
    -- 自動スケーリング

課題 / 事業リスク (Issues/Business risks)

  1. 既存システムからの移行に伴う業務中断のリスク
  2. クラウドサービス利用に関するデータ所在地の問題 (海外へのデータ持ち出し禁止)
  3. エンドポイントの集約によるサイバー攻撃の脅威増大

未決定事項 (Undecided Matters)

  1. 具体的なソフトウェア選定 / アーキテクチャ構成
  2. ユーザートレーニングプログラムの詳細
  3. サービスの原価設定(1社あたりのコストと運用費を含む)
  4. 既存構築済みSFTPサーバの段階的ロールアウトのスケジュール

さいごに

最後に、実際にはこの要件定義書を作成する前に課題抽出を行っています。課題やゴールを立てておかないと、プロダクトがぶれてしまい、評価が出来ないからです。
また、初回の作成で完璧を目指すのではなく、チームメンバーとテーマごとにディスカッションをしてフィードバックを受けながら継続的に改善していくことが、より良い設計と理解につながると思います。

Discussion