SprocketテックブログPublicationへの投稿
🔐

AWS Transfer Family Toolkitを使ってユーザー個別IP制限付きSFTPサーバーを効率的に構築する

kasumi
に公開
AWS
Security
infrastructure
SFTP
tech

AWS Transfer Familyを使用したファイル転送において、セキュリティ要件として、ユーザーごとに異なるアクセス元IPアドレス制限を設けたいケースがあります。

本記事では、ユーザー単位でのアクセス元IPアドレス制限を効率的に実現する手法について、複数のアプローチを比較検討した結果をご紹介します。特に、AWS Transfer Family Toolkitを用いた開発・運用コストの削減方法に焦点を当てます。

AWS Transfer Family Toolkitによるセキュリティ強化

課題設定

ユーザー単位でのアクセス元IPアドレス制限を持つTransfer Familyサーバーの構築において、以下の要件を満たす効率的な実装方法を検討します。

  • ユーザーごとに個別のアクセス元IPアドレス制限機能
  • SSH公開鍵認証との組み合わせによるセキュリティ強化
  • Terraformによるインフラ管理との親和性

実装アプローチの比較検討

ユーザー単位でのアクセス元IPアドレス制限を実現するため、複数のアプローチを比較検討しました。それぞれの手法について採用可否を判断し、実際に動作検証を行った結果をご紹介します。

検討したアプローチ一覧

アプローチ 採用理由・不採用理由 アプリケーション開発要否 インフラテンプレート有無
1. VPCセキュリティグループによるアクセス元IP制限 ユーザーが増えた場合にコストが増大 不要 未確認
2. AWS公式CloudFormation アクセス元IP制限ロジック実装でLambdaのカスタマイズが必要 要 有
3. カスタムIDプロバイダー実装 Lambda実装で開発・管理コストが高い 要 無
4. AWS Transfer Family Toolkit (AWS SAMによるデプロイ) SAMとTerraform両運用の複雑さ 不要 有
5. AWS Transfer Family Toolkit (Lambdaソースのみ) 採用：アプリケーション開発運用コスト削減とTerraformのみによる管理 不要 無

各アプローチについて、実装の詳細と課題を詳しく見ていきましょう。

アプローチ1: VPCセキュリティグループによるアクセス元IP制限

最初に検討した手法は、VPCのセキュリティグループを使用してサーバーレベルでアクセス元IP制限を実装する方法です。

セキュリティグループによる制限方法

AWS Transfer FamilyサーバーをVPC内に配置し、セキュリティグループでアクセス元IPアドレスを制限します。この手法については、以下の資料で詳しく説明されています。

課題と制約

この手法には重要な制約があります。セキュリティグループによるアクセス元IP制限は、サーバー全体に適用されます。複数のユーザーが異なるアクセス元IPアドレス制限を必要とする場合、各ユーザーごとに専用のTransfer Familyサーバーを構築する必要があります。

AWS Transfer Familyの料金体系では、サーバーエンドポイントが有効な時間に基づいて課金されます。公式料金表によると、1台のサーバーで月額$200強のコストが発生します。

複数のユーザーが異なるアクセス元IP制限要件を持つ場合、この方式ではユーザー数に比例して月額$200強のコストが積み重なってしまうため、スケーラブルな運用には適していないと判断しました。

アプローチ2: AWS公式CloudFormation

次に検討したのは、AWSが公式に提供するCloudFormationテンプレートを活用する手法です。

CloudFormationテンプレートについて

AWSドキュメントでは、API Gatewayを利用したカスタム認証の実装方法が説明されています。公式からBasic stack templateやAWS Secrets Manager stack templateなどのCloudFormationテンプレートが提供されています。これらはAWSドキュメント内で参照できます。

実装上の課題

これらのテンプレートは、認証リクエストでsourceIPパラメータを受信する機能は提供していますが、実際のアクセス元IP制限ロジックは実装されていません。ドキュメントにも以下のような記述があります。

By default, your API Gateway method authenticates against an entry in Secrets Manager... After deployment, you can modify the Lambda function code to do something different.

つまり、アクセス元IP制限を実現するためには、デプロイ後にLambda関数のコードを修正する必要があります。テンプレートを活用しても、結果的にAWS公式ガイドに基づく認証ロジックの実装と保守が必要となるため、開発・運用コストの削減効果は限定的と判断しました。

実際の検証においても、CloudFormationテンプレートをそのまま適用するだけでは、アクセス元IP制限機能を実現できないことを確認しました。

アプローチ3: カスタムIDプロバイダー実装

3つ目の選択肢として、AWS Transfer FamilyサーバーとカスタムIDプロバイダー実装を組み合わせた認証システムを検討しました。

実装概要

AWS公式ガイドに従い、Lambda関数を使用したカスタムIDプロバイダーを実装します。認証情報の永続化にはDynamoDB、Secrets Manager等を使用できます。

実装結果と課題

実際に検証環境で動作確認を行った結果、アクセス元IP制限機能を含む認証システムの実装に成功しました。

しかし、このアプローチでは以下の課題があります。

  • AWS公式ガイドに基づくLambda関数の認証ロジック実装が必要
    • アクセス元IP制限ロジックの実装とテスト
    • Lambda関数の継続的なメンテナンス

これらのアプリケーション開発・運用コストを考慮すると、より効率的な手法があるのではないかと考え、さらなる検討を進めました。

アプローチ4: AWS Transfer Family Toolkit (AWS SAMによるデプロイ)

4つ目の選択肢として、AWS Transfer Family Toolkitを検討しました。このToolkitは、これまでの課題を解決する可能性を持つソリューションです。

AWS Transfer Family Toolkitとは

AWS Transfer Family Toolkitは、カスタムIDプロバイダーの実装を簡素化するためのAWS公式ソリューションです。

ドキュメントでは以下のような記述があります。

If you have previously used custom identity provider templates and examples, consider adopting this solution instead. Moving forward, provider-specific modules will standardize on this solution.

つまり、従来のテンプレートやサンプルを使用していた場合は、このToolkitの採用を推奨しており、今後の機能拡張やメンテナンスもこのソリューションに集約されるということです。

SAM版の課題

ToolkitはAWS SAMを使用したデプロイ方式を公式に提供しています。しかし、既存のTerraformベースのインフラ管理と併用する場合、以下の課題があります。

  • AWS SAMとTerraformでリソース管理が分断される
  • CI/CDパイプラインが複雑化（sam deploy + terraform apply）

SAM Terraform Supportによる連携も技術的には可能ですが、運用の複雑さが今回の要件に見合っていないと判断しました。

アプローチ5: AWS Transfer Family Toolkit (Lambdaソースのみ)

アプローチ4の課題を解決する手法として、ToolkitのSAMテンプレートは使用せず、Lambdaのソースコードのみを利用してTerraformでインフラを構築するアプローチを検討しました。

手法の概要

この手法では、AWS Transfer Family ToolkitのLambdaソースコードを活用し、インフラ管理はTerraformで統一します。Git SubmoduleでToolkitを統合し、Container Image方式でLambdaをデプロイすることで、既存のTerraformベースの運用と親和性の高い構成を実現できます。

主な利点

アプリケーション開発においては、カスタムIDプロバイダーとして実装済みのLambdaコードを活用することで開発工数を削減できます。運用面では自作Lambdaのメンテナンスが不要となり、AWSが公式にメンテナンスする実装の恩恵を継続的に受けることが可能です。また、Terraformによる統一的なインフラ管理により、管理ツールの一貫性を保てます。

認証情報の永続化のためにDynamoDBなどを構築する必要はありますが、追加で必要となるインフラはその程度であり、インフラテンプレートを使用しないことのデメリットは小さいと考えました。

まとめ

ユーザー単位でのアクセス元IPアドレス制限を持つTransfer Familyサーバーの構築において、複数のアプローチを比較検討しました。その結果、AWS Transfer Family ToolkitのLambdaソースコードを活用する手法が最も効率的であると判断しました。

他のアプローチと比較して、以下の点で優位性があると考えました。

  • アプリケーション開発面では、アクセス元IP制限ロジックの実装が不要となり、実装済みの認証システムを活用することで認証部分の開発工数を削減できる
  • 運用効率性については、AWSが公式にメンテナンスする実装を使用するため、セキュリティアップデートや機能拡張の恩恵を継続的に受けることが可能である。また、Terraformによる統一的なインフラ管理により、運用の一貫性を保てる
  • コスト効率性の観点では、複数のユーザーを1台のサーバーで処理することで、サーバーエンドポイント数を削減できる。Lambda実行時間課金による従量制のコスト構造と合わせて、長期的な保守コストの最適化を図れる

AWS Transfer Family ToolkitのLambdaソースコードのみを活用してTerraformで管理する手法は、インフラ管理の一貫性と開発効率性を両立したアプローチです。このアプローチにより、セキュリティ要件を満たしながら、効率的なTransfer Familyサーバー運用を実現できます。

参考資料

GitHubで編集を提案
Sprocketテックブログ
SprocketテックブログPublication

株式会社Sprocketのテックブログです。

Discussion