AWS Transfer Family のよくある質問

Q: AWS Transfer Family とは何ですか?

A: AWS Transfer Family は、フルマネージド型のサービスです。SFTP、AS2、FTPS、FTP 経由で Amazon S3 または Amazon EFS と直接ファイル転送できます。クライアント側の既存の認証、アクセス、ファイアウォールの設定を維持することで、ファイル転送ワークフローをシームレスに移行、自動化、モニタリングできます。そのためお客様、パートナー、内部のチームやそのアプリケーションにとって、何も変更はありません。

Q: SFTP とは何ですか?

A: SFTP は Secure Shell (SSH) File Transfer Protocol の略称で、インターネット経由の安全なデータ転送に使用されるネットワークプロトコルです。このプロトコルは、SSH のセキュリティ機能と認証機能に完全対応し、金融サービス、医療、メディアと娯楽、小売り、広告など、多種多様な業界のビジネスパートナー間のデータ交換で幅広く使用されています。

Q: FTP とは何ですか？

A: FTP は File Transfer Protocol の略称で、データ転送に使用されるネットワークプロトコルです。FTP は制御とデータ転送に別のチャネルを使用します。制御チャネルは終了するまで、または非アクティブな状態のタイムアウトまで、オープンです。データチャネルは転送の期間を通じてアクティブです。FTP はクリアテキストを使用し、トラフィックの暗号化はサポートしていません。

Q: FTPS とは何ですか？

A: FTPS は File Transfer Protocol over SSL の略称で、FTP の拡張版です。Transport Layer Security (TLS) および Secure Sockets Layer (SSL) 暗号化プロトコルを使用して、トラフィックを暗号化します。FTPS を利用すると、制御チャネルとデータチャネルの接続の両方を同時に、または個別に暗号化できます。

Q: AS2 とは何ですか?

AS2 は Applicability Statement 2 の略で、パブリックインターネット上で HTTP/HTTPS (または任意の TCP/IP ネットワーク) を介してビジネス間データを安全かつ確実に転送するために使用されるネットワークプロトコルです。

Q: なぜ AWS Transfer Family を使用する必要がありますか?

A: AWS Transfer Family は、企業間 (B2B) のファイル転送のための複数のプロトコルをサポートしているため、ステークホルダー、サードパーティーベンダー、ビジネスパートナー、お客様間でデータを簡単かつ安全に交換することができます。Transfer Family を利用しない場合は、独自のファイル転送サービスをホストして管理する必要があり、インフラストラクチャの運用と管理、サーバーのパッチング、アップタイムや可用性のモニタリング、ユーザーのプロビジョニングとアクティビティの監査を行うための 1 回限りの仕組みの構築に投資する必要があります。AWS Transfer Family は、エンドユーザーのために既存の転送ワークフローを保ちながら、操作負担を軽減させるフルマネージド型の SFTP、FTPS、FTP のサポートを提供することで、これらの課題を解決します。AWS Transfer Family マネージドファイル処理ワークフローは、独自のコードやインフラストラクチャを維持することなく、ファイル転送やデータ処理の作成、自動化、モニタリングを可能にします。このサービスでは、転送されたデータがオブジェクトとして Simple Storage Service (Amazon S3) バケットに、またはファイルとして Amazon EFS ファイルシステムに格納されます。そのため、データレイクでファイルから値を抽出できます。Customer Relationship Management (CRM) または Enterprise Resource Planning (ERP) ワークフローで使用したり、AWS でのアーカイブ化に使用したりすることもできます。

Q: AWS Transfer Family を使用するメリットは何ですか?

A: AWS Transfer Family では、高可用性のフルマネージド型のファイル転送サービスを利用できます。自動スケーリング機能が組み込まれているため、ファイル転送関連インフラストラクチャを管理する必要がなくなります。エンドユーザーのワークフローは変わらず、選択したプロトコル経由でアップロードまたはダウンロードしたデータは Amazon S3 バケットまたは Amazon EFS ファイルシステムに保存されます。データは AWS 内にあるため、コンプライアンス要件を満たす環境で、データ処理、コンテンツ管理、分析、機械学習、およびアーカイブのために、AWS の幅広いサービスとあわせて簡単に使用できるようになりました。

Q: SFTP、 FTPS、 FTP 用の AWS Transfer の使用を開始するにはどうしたらいいですか?

A: 3 つの簡単なステップで、常時稼働する SFTP、FTPS、FTP のサーバーエンドポイントを利用できます。まず、エンドユーザーがエンドポイントに接続するためのプロトコルを選択します。次に、ユーザーアクセスを設定します。これを行うには、AWS Transfer Family 組み込み型認証マネージャー (サービスマネージド)、Microsoft Active Directory (AD) を使用するか、自社の ID プロバイダー、または Okta や Microsoft AzureAD といったサード パーティーの ID プロバイダーを統合します (「BYO」認証)。最後に、S3 バケットまたは EFS ファイルシステムにアクセスするサーバーを選択します。プロトコル、ID プロバイダー、およびファイルシステムへのアクセスが有効になると、ユーザーは既存の SFTP、FTPS、または FTP クライアントと設定を引き続き使用できます。ユーザーがアクセスするデータは選択したファイルシステムに保存されます。 

Q: どうすれば AS2 用の AWS Transfe の使用を開始できますか?

A: 3 つの簡単なステップで、トレーディングパートナーとメッセージを交換するために AS2 を使い始めることができます。まず、お客様の証明書と秘密キー、トレーディングパートナーの証明書と証明書チェーンをインポートします。次に、お客様とパートナーの AS2 ID を使用してプロファイルを作成します。最後に、データ受信用のアグリーメントとデータ送信用のコネクタを使用して、お客様とパートナーのプロファイル情報をペアリングします。この時点で、トレーディングパートナーの AS2 サーバーとメッセージを交換する準備が整いました。

Q: SFTP と FTPS にはどのような違いがありますか? どのような場合に、どちらを使用するべきですか?

A: FTPS と SFTP はどちらも安全なデータ転送に利用できます。この 2 つは異なるプロトコルであるため、異なるクライアントとテクノロジーを使用して、コマンドとデータを送信するための安全なトンネルを提供しています。SFTP はより新しいプロトコルであり、コマンドとデータに単一のチャネルを使用し、必要とするオープンなポートは FTPS よりも少ないです。

Q: SFTP、FTPS、AS2 プロトコルの違いは何ですか? また、どのような場合に AS2 プロトコルを使用すべきですか?

A: SFTP、FTPS、および AS2 はすべて安全なデータ転送に利用できます。それぞれ異なるプロトコルであるため、異なるクライアントとテクノロジーを使用して、安全なデータ通信を実現します。暗号化されたメッセージや署名されたメッセージのサポートの他に、AS2 に組み込まれた Message Disposition Notification (MDN) のメカニズムは、メッセージが受信者によって正常に受信され復号化されたことを送信者にアラートします。これにより、送信者は、メッセージが転送中に改ざんされることなく配信されたことの証明が得られます。AS2 の利用は、小売、電子商取引、決済、サプライチェーンなど、ビジネスパートナーとのやり取りを行うワークフローで普及しており、ビジネスパートナーも AS2 を利用して、安全に送信、配送されるようにメッセージをやり取りすることができます。AS2 は、送信者と受信者の ID、メッセージの整合性、およびメッセージが正常に送信され、受信者によって復号化されたかどうかを確認するためのオプションを提供します。

Q: ユーザーは既存のファイル転送クライアントやアプリケーションを引き続き使用できますか?

A: はい。選択したプロトコルに対してエンドポイントを有効化すれば、既存のすべてのファイル転送クライアントアプリケーションをそのまま使用できます。よく使用される SFTP/FTPS/FTP クライアントの例として、WinSCP、FileZilla、CyberDuck、lftp、OpenSSH などのクライアントがあります。 

Q: CloudFormation を使用し、サーバーやユーザーのデプロイを自動化できますか?

A: はい。CloudFormation テンプレートをデプロイすることで、サーバー/ユーザーの作成を自動化したり、ID プロバイダーを統合したりできます。AWS Transfer リソースを CloudFormation テンプレートで使用する方法については、利用ガイドをご覧ください。

Q: ユーザーは SCP または HTTPS を使用して、このサービスを使用してファイルを転送できますか?

A: いいえ、ユーザーはファイル転送に SFTP、AS2、FTPS、FTP を使用する必要があります。ほとんどのファイル転送クライアントでは、認証時に選択するオプションとして、これらのプロトコルが提供されています。AWS Supportまたは AWS アカウントチームを通じて、サポートを希望する特定のプロトコルをお知らせください。

Q: 企業ドメイン名 (sftp.mydomainname.com) を使用してエンドポイントにアクセスできますか?

A: はい。ドメイン名を既にお持ちの場合、Amazon Route 53 または任意の DNS サービスを使用して、登録済みのドメインから AWS のサーバーエンドポイントにユーザーのトラフィックをルーティングできます。(インターネット転送エンドポイントにのみ適用可能な) カスタムドメイン名について、AWS Transfer Family が Amazon Route 53 を使用する方法に関するドキュメントを参照してください。

Q: ドメイン名を持っていなくてもこのサービスを使用できますか?

A: はい。ドメイン名をお持ちでない場合、ユーザーはこのサービスで提供されるホスト名を使用してエンドポイントにアクセスできます。別の方法として、Amazon Route 53 コンソールまたは API を使用して新しいドメインを登録し、このドメインからサービスが提供するエンドポイントのホスト名にトラフィックをルーティングできます。

Q: 既にパブリックゾーンがあるドメインを使用できますか?

A: はい。サービスが提供するエンドポイントのホスト名にそのドメインを CNAME として登録する必要があります。

Q: サーバーを VPC 内のリソースのみがアクセスできるように設定できますか?

A: はい。サーバーを作成する際、または既存のサーバーを更新する際に、エンドポイントをパブリックインターネット上でアクセス可能にするか、または自分の VPC 内にホストするか、いずれかを指定することができます。VPC にホストしたエンドポイントをサーバーとして使用すると、同じ VPC にあるクライアント、指定したその他の VPC のクライアント、または AWS Direct Connect、AWS VPN、VPC ピアリングなど、VPC を拡張するネットワーク技術を使用するオンプレミス環境にあるクライアントのみにアクセスを制限できます。サブネットのネットワークアクセスコントロールリスト (NACL) またはセキュリティグループを使用して、さらに VPC 内の特定のサブネットのリソースにアクセスを制限できます。詳細は、AWS PrivateLink を使った VPC 内におけるサーバーエンドポイントの作成についてのドキュメントをご覧ください。

Q: インターネットに直接接続したエンドポイントを使って FTP を使用できますか?

A: いいえ。FTP を有効化する場合は、VPC にホストしたエンドポイントの内部アクセスオプションのみを使用できます。トラフィックがパブリックネットワークを経由する場合は、SFTP や FTPS のようなセキュアなプロトコルを使用する必要があります。

Q: パブリックインターネットを使用する転送で FTP を使用する必要がある場合はどうなりますか?

A: このサービスでは FTP をパブリックインターネットで使用することは許可されていません。FTP 用に有効化されたサーバーを作成する場合、サーバーエンドポイントにアクセスできるのは VPC 内のリソースのみです。パブリックインターネットでデータを交換するために FTP を使用する必要がある場合は、サーバーの VPC エンドポイントをインターネット向け Network Load Balancer (NLB) に接続させることができます。 この設定では動作しない可能性のある FTP クライアントをサポートするために、サーバーを PASV モードで使用してください。

Q: VPC なしで FTP を使用できますか?

A: いいえ。FTP サーバーエンドポイントをホストするためには VPC が必須です。CloudFormation テンプレートのドキュメントを参照して、サーバー作成時にエンドポイントをホストする VPC リソースの作成を自動化してください。

Q: エンドユーザーは、固定 IP アドレスを使用して、ファイアウォール内のサーバーのエンドポイントに対するアクセスを許可リストに登録できますか?

A: はい。サーバーの VPC にホストされたエンドポイントを選択し、インターネットに直接接続するオプションを選択すると、サーバーエンドポイントの固定 IP を有効にできます。これにより、エンドポイントの IP アドレスとして割り当てられているエンドポイントに Elastic IP (BYO IP を含む) を直接接続できるようになります。インターネットに面したエンドポイントの作成に関しては、ドキュメントの「VPC 内でのサーバーエンドポイントの作成」セクションを参照してください。

Q: エンドユーザーのソース IP アドレスによって着信トラフィックを制限できますか?

A: はい。ユーザーのソース IP アドレスによって着信トラフィックを制限するには、3 つのオプションがあります。VPC 内でサーバーのエンドポイントをホストしている場合は、セキュリティグループを使用してリストのソース IP アドレスを許可することについてのこのブログ投稿を参照するか、AWS Network Firewall サービスを使用してください。パブリック EndpointType Transfer サーバーと API Gateway を使用して ID 管理システムを統合している場合は、AWS WAF を使用して、エンドユーザーのソース IP アドレスによってアクセスを許可、ブロック、またはレート制限することもできます。

Q: サーバーのエンドポイントを共有 VPC 環境でホストできますか?

A: はい。共有 VPC 環境を使用して、サーバーエンドポイントをデプロイできます。この環境は、セキュリティ、コスト監視、スケーラビリティのために AWS Landing Zone などのツールを使用して AWS 環境をセグメント化するときに通常使われます。AWS Transfer Family の共有 VPC 環境で VPC ホストエンドポイントを使用することに関するこちらのブログ記事を参照してください。

Q: 外部の SFTP または FTPS サイトに保存されているファイルにアクセスするにはどうすればよいですか?

A: AWS Fargate を使って外部の SFTP/FTPS サイトに接続し、AWS Transfer Family を使ってデータにアクセスする方法については、こちらのブログをご参照ください。外部サイトに接続するためのフルマネージドソリューションをお探しの場合は、AWS Support または AWS アカウントチームを通じて、私たちに連絡してください。

Q: 遠隔地にいるエンドユーザーのファイル転送のパフォーマンスを向上させるにはどうすればよいですか?

A: Transfer サーバーのエンドポイントに AWS Global Accelerator を使用することで、ファイル転送のスループットとラウンドトリップタイムを改善することができます。詳細については、こちらのブログ投稿をご覧ください。

Q: エンドユーザーのクライアントがサーバーエンドポイントに接続するときに使用できる暗号化アルゴリズムを選択できますか?

A: はい。お客様のセキュリティとコンプライアンスの要件に従って、次の 3 つのセキュリティポリシーから 1 つを選択し、サーバーのエンドポイントがアドバタイズする暗号化アルゴリズムを制御できます: Transfer-Security-Policy-2018-11 (デフォルト)、Transfer-Security-Policy-2020-06 (制限的 – SHA-1 アルゴリズムなし)、Transfer-FIPS-2020-06 (FIPS 準拠のアルゴリズム)。エンドユーザーのファイル転送クライアントがお使いのサーバーへの接続を試みる場合、接続の交渉にはポリシーで指定されたアルゴリズムのみが使用されます。事前定義されたセキュリティポリシーに関するドキュメントを参照してください。

Q: エンドユーザーは固定 IP アドレスを使用して、エンドポイントの種類が PUBLIC のサーバーにアクセスできますか?

A: いいえ。ファイアウォールのホワイトリストに登録する目的で一般的に使用される固定 IP アドレスは、種類が PUBLIC のエンドポイントでは現在サポートされていません。 VPC でホストされているエンドポイントを使用して、エンドポイントに静的 IP アドレスを割り当ててください。

Q: PUBLIC である SFTP サーバーのエンドポイントタイプにアクセスするには、エンドユーザーはどの IP 範囲を許可リストに登録する必要がありますか?

A: PUBLIC エンドポイントタイプをご使用の場合、ユーザーはここで公開されている AWS IP アドレス範囲を許可リストに登録する必要があります。AWS IP Address Ranges の詳細についての最新情報はドキュメントをご覧ください。

Q: サーバーを作成した後に、AWS Transfer for SFTP サーバーのホストキーが変更されることはありますか?

A: いいえ。サーバーを作成したときに割り当てられたサーバーのホストキーは、新しいホストキーを追加して元のキーを手動で削除しない限り、同じままです。

Q: どのような種類の SFTP サーバーのホストキーがサポートされていますか?

A: SFTP サーバーのホストキーは、RSA、ED25519、ECDSA のキータイプがサポートされています。

Q: 私のユーザーが再度サーバーの真偽を検証しなくても済むように、現在の SFTP サーバーからキーをインポートできますか?

A: はい。サーバー作成時にホストキーをインポートしたり、サーバーの更新時に複数のホストキーをインポートすることができます。SFTP 対応サーバーのホストキーの管理に関するドキュメントを参照してください。

Q: SFTP サーバーにはいくつのホストキーを関連付けることができますか?

A: SFTP サーバー 1 台につき 10 個までホストキーを関連付けることができます。ただし、エンドユーザーのクライアントが 1 回のセッションで SFTP サーバーの真正性を検証するために使用できるのは、キータイプごとに 1 つのホストキーのみです。

Q: 複数のホストキーはどのように識別できますか?

A: 複数のホストキーは、説明とタグを使用して識別することができ、ホストキーを作成または更新するときに追加または編集できます。また、各ホストキーには一意のホストキー ID と、ホストキーの識別と追跡に使用できる Amazon リソースネーム (ARN) があります。

Q: SFTP サーバーの真正性を検証するために、複数のホストキーを使用できますか?

A: はい。各キー種の最も古いホストキーを使用して、SFTP サーバーの真正性を検証することができます。RSA、ED25519、ECDSA のホストキーを追加することで、3 つの別個のホストキーを使用して SFTP サーバーを識別することができます。

Q: SFTP サーバーの真正性を検証するために、どのホストキーが使用されますか?

A: SFTP サーバーの真正性を検証するために、各キータイプの中で最も古いホストキーが使用されます。

Q: 安全な接続を確保するために、SFTP サーバーのホストキーをローテーションさせることができますか?

A: はい。A: SFTP サーバーのホストキーのローテーションは、ホストキーの追加と削除によりいつでも行うことができます。SFTP 対応サーバーのホストキーの管理に関するドキュメントを参照してください。

Q: エンドユーザーの FTPS クライアントは、どのように FTPS サーバーの ID を確認しますか?

A: FTPS アクセスを有効化する際に、Amazon Certificate Manager (ACM) から取得した証明書を支給する必要があります。この証明書を使用して、エンドユーザークライアントは FTPS サーバーの ID を確認します。新しい証明書のリクエストまたは既存の証明書の ACM へのインポートについては ACM ドキュメントを参照してください。

Q: FTPS および FTP のアクティブモードとパッシブモードをサポートしていますか?

A: パッシブモードのみをサポートしています。パッシブモードでは、エンドユーザーのクライアントがサーバーとの接続を開始できます。パッシブモードではクライアント側で必要なオープンなポートの数が少なく、サーバーエンドポイントの、保護されたファイアウォールの後ろにいるエンドユーザーとの互換性が高まります。

Q: FTPS の明示的な、および黙示的なモードをサポートしていますか?

A: 明示的な FTPS モードのみをサポートしています。

Q: クライアントとサーバーの間にファイアウォールやルーターが設定されていても、FTPS/FTP プロトコルでファイルを転送できますか?

A: はい。ファイアウォールやルーターを経由するファイル転送は、デフォルトでは EPSV (extended passive connection mode) を使用してサポートされています。EPSV モードをサポートしていない FTPS/FTP クライアントを使用している場合は、こちらのブログ投稿を参照して、PASV モードでサーバーを設定することで、幅広いクライアントに対するサーバーの互換性を高めることができます。

Q: Transfer Family サーバーに接続するユーザーのログインバナーをカスタマイズすることはできますか?

A: はい。組織ポリシーや利用規約など、カスタマイズしたバナーをユーザーに表示するよう、Transfer Family サーバーを設定することができます。また、認証に成功したユーザーに対して、カスタマイズした本日のメッセージ (MOTD) を表示することも可能です。詳細については、ドキュメントをご覧ください。

Q: 1 つのエンドポイントで複数のプロトコルを有効にすることはできますか?

はい。設定中に、クライアントがエンドポイントに接続するために有効化したいプロトコル (複数可) を選択できます。サーバーホスト名、IP アドレス、および ID プロバイダーが選択されたプロトコル全体で共有されます。同様に、エンドポイントの設定が使用する予定のすべてのプロトコルの要件を満たしている限り、既存の AWS Transfer Family エンドポイントに追加のプロトコルサポートを有効にすることも可能です。

Q: どのような場合にプロトコルごとに別のサーバーエンドポイントを作成し、どのような場合に複数のプロトコルに 1 つのエンドポイントを有効化するべきですか?

A: FTP (VPC 内のアクセスのみがサポートされています) を使用する必要があり、かつ SFTP、AS2、または FTPS でインターネットをサポートする必要がある場合、FTP に独立したサーバーエンドポイントが必要です。複数のプロトコルに 1 つのエンドポイントを使用できるのは、そのエンドポイントのホスト名と IP アドレスを、複数のプロトコルにわたって接続するクライアントに使用する場合です。さらに 1 つの認証情報を SFTP と FTPS に使用したい場合は、単一の ID プロバイダーを設定して使用して、両方のプロトコルにわたって接続するクライアントを認証できます。

Q: 1 人のエンドユーザーを、複数のプロトコルにわたるエンドポイントにアクセスするように設定できますか?

A: はい。1 人のユーザーに複数のプロトコルにわたるアクセスを設定できます。これは ID プロバイダーにプロトコルに固有の認証情報が設定されている場合に可能です。FTP を有効化している場合は、FTP には別の認証情報を使用することを推奨します。FTP に別の認証情報を設定する方法については、ドキュメントを参照してください。

Q: FTP ユーザーに別の認証情報を使用する必要があるのはどうしてですか?

A: SFTP および FTPS と異なり、FTP は認証情報をクリアテキストで送信します。FTP の認証情報を SFTP または FTPS から隔離することを推奨します。そうすれば、もし不注意により FTP の認証情報が共有または公開されても、SFTP または FTPS を使用しているワークロードは引き続き安全だからです。

Q: ユーザーはブラウザを使って AWS Transfer Family SFTP エンドポイントにアクセスできますか?

A: はい、このオープンソースのソリューションをデプロイすることで、AWS Transfer Family SFTP エンドポイントを使ってブラウザベースのインターフェイスを提供することができます。

Q: このサービスでは、どのような ID プロバイダーオプションがサポートされていますか?

A: このサービスでは 3 つの ID プロバイダーがサポートされています。サービス内にユーザー ID を格納するサービスマネージド型認証、Microsoft Active Directory による認証、任意の ID プロバイダーを統合できるカスタム ID プロバイダー認証です。サービスマネージド型認証は、SFTP のみに有効化されたサーバーエンドポイントをサポートしています。

Q: どのようにサービスマネージド型の認証機能を使用してユーザー認証できますか?

A: サービスマネージド型認証では、SSH キーを使用して SFTP ユーザーを認証できます。

Q: SFTP ユーザー 1 人につき、いくつの SSH キーをアップロードできますか? どのようなキーの種類がサポートされていますか?

A: ユーザー 1 人につきアップロードできる SSH キーの数は最大 10 個です。RSA、ED25519、ECDSA のキーがサポートされています。

Q:サービスマネージド型認証で SSH キーのローテーションはサポートされていますか?

A: はい。SFTP ユーザーにキーのローテーションを設定する方法の詳細については、ドキュメントをご覧ください。

Q:パスワード認証にサービスマネージド型オプションを使用できますか?

A: いいえ。認証のためにサービス内にパスワードを保存する機能は現在サポートされていません。パスワード認証が必要な場合、AWS Directory Service でディレクトリを選択してアクティブディレクトリを使用するか、Secrets Manager を使用してパスワード認証を有効にするのブログ記事に記載されたアーキテクチャに従ってください。

Q: Microsoft AD の使用を開始するにはどうしたらよいですか?

A: サーバーを構築するときに、AWS Managed Microsoft AD、お客様のオンプレミス環境、または Amazon EC2 のセルフマネージド AD のディレクトリを ID プロバイダーとして選択します。次に、セキュリティ識別子 (SID) によるアクセスを有効にする AD グループを指定する必要があります。AD グループを、IAM ロール、スコープダウンポリシー (S3 のみ)、POSIX プロファイル (EFS のみ)、ホームディレクトリの場所、論理ディレクトリマッピングといったアクセスコントロール情報に関連付けると、そのグループのメンバーは、自分の AD 認証情報を使用して認証を行い、有効なプロトコル (SFTP、FTPS、FTP) でファイルを転送できるようになります。

Q: S3 バケットのさまざまな部分へのアクセス権をユーザー別に指定するには、AD ユーザーをどのように設定すればよいですか?

A: ユーザー設定の際に、ユーザー名などのユーザー情報に基づいて実行時間で評価されるスコープダウンポリシーを作成します。すべてのユーザーに同じスコープダウンポリシーを使用して、バケットの一意のプレフィックスに対するアクセス権を、ユーザー名を基に付与できます。ユーザー名は論理ディレクトリマッピングの評価にも使用できます。これを行うには、S3 バケットまたは EFS ファイルシステムの内容をユーザーに表示する方法を、標準化されたテンプレートで指定します。詳細については、AD グループへのアクセス権の付与に関するドキュメントを参照してください。

Q: Microsoft AD を、サポート対象のすべてのプロトコルに ID プロバイダーオプションとして使用できますか?

A: はい。SFTP、FTPS、FTP を介したアクセスに対し、Microsoft AD を使用してユーザーを認証できます。

Q: 有効な AD グループのアクセス権を取り消すことはできますか?

はい。個々の AD グループに付与されたファイル転送のアクセス権は取り消すことができます。アクセス権を取り消された AD グループのメンバーは、AD の認証情報を使用したファイル転送を行えなくなります。

Q: 個々の AD ユーザー、または、あるディレクトリ内のすべてのユーザーにアクセス権を付与することはできますか?

A: いいえ。AD グループ単位でのアクセス権設定のみサポートされています。

Q: AD を使用して、SSH キーを使用するユーザーを認証できますか?

A: いいえ。AWS Transfer Family でパスワードベースの認証がサポートされているのは Microsoft AD のみです。認証モードを混在させて使用する場合は、カスタムオーソライザーオプションを選択してください。

Q:カスタム認証モードを使用する必要があるのはどうしてですか?

A: カスタムモード (「BYO」認証) を使用すると、既存の ID プロバイダーを利用して、すべてのプロトコルタイプ (SFTP、FTPS、FTP) についてエンドユーザーを管理でき、ユーザーの簡単でシームレスな移行が可能です。認証情報は社内ディレクトリまたは社内の ID データストアに格納して、エンドユーザー認証のために統合できます。ID プロバイダーの例には、Okta、Microsoft AzureAD のほか、カスタム構築され全般的なプロビジョニングポータルの一部として利用されている ID プロバイダーなどがあります。

Q: 自分の ID プロバイダーと AWS Transfer Family サーバーを統合するには、どのようなオプションがありますか?

A: ID プロバイダーを AWS Transfer Family サーバーと統合するには、AWS Lambda 関数、または Amazon API Gateway エンドポイントを使用できます。ID プロバイダーに接続するための RESTful API が必要な場合や、AWS WAF の地理的ブロックおよびレート制限機能を利用する場合は、Amazon API Gateway を使用してください。AWS Cognito、Okta、および AWS Secrets Manager などの一般的な ID プロバイダーの統合の詳細については、ドキュメントをご覧ください。

Q:既存の ID プロバイダーをカスタム認証に統合するには、まずどうすればよいですか?

A: まず 利用ガイドの AWS CloudFormation テンプレートを使用して、ユーザー認証とアクセスに必要な情報を提供します。詳細については、カスタム ID プロバイダーに関するウェブサイトをご覧ください。

Q: カスタム ID プロバイダー経由でユーザーを設定するとき、ユーザーへのアクセスを有効にするためにどの情報が使用されますか?

A: ユーザーは認証に使用されるユーザー名とパスワード (または SSH キー) を指定する必要があります。データへのアクセスは、ID プロバイダーへの接続用の AWS Lambda 関数、または API Gateway により提供される AWS IAM ロールで決定されます。ホームディレクトリ情報も指定する必要があります。セキュリティを強化し、使い勝手をよくするため、お客様のユーザーを指定のホームフォルダに固定することをお勧めします。AWS SFTP でカスタム ID プロバイダーを使用する際は、エンドユーザー体験をシンプルにする方法に関するブログ記事をご覧ください。

Q: クライアントのソース IP に基づいてアクセス制御を適用できますか?

A: はい。AWS Lambda または API Gateway を使用してカスタム ID プロバイダーを接続する際に、クライアントソース IP がお客様の ID プロバイダーに渡されます。これにより、クライアントの IP アドレスに基づいてアクセスを許可、拒否、制限することができ、信頼できると指定した IP アドレスからのみデータにアクセスできるようになります。

Q:匿名ユーザーはサポートされていますか?

A: いいえ。匿名ユーザーはどのプロトコルについても現在サポートされていません。

Q: AS2 トレーディングパートナーを一意に特定するにはどうすればよいですか?

A: トレーディングパートナーは、AS2 識別子 (AS2 ID) を使用して一意に特定されます。同様に、トレーディングパートナーは AS2 ID を使用してメッセージを特定します。

Q: AWS Transfer Family のどの既存機能が、AS2 で利用できますか? どの機能が利用できないのですか?

A: AWS Transfer Family の既存の Amazon S3、ネットワーク機能 (VPC エンドポイント、セキュリティグループ、Elastic IP)、アクセス制御 (AWS IAM) のサポートは、SFTP、FTPS、FTP と同様に AS2 でも使用することが可能です。ユーザー認証、論理ディレクトリ、カスタムバナー、ストレージバックエンドとしての Amazon EFS は、AS2 ではサポートされていません。

Q: 否認防止とは何ですか、そしてなぜそれが重要なのですか?

A: AS2 独自の否認防止は、2 つの当事者間でメッセージが正常に交換されたことを検証します。AS2 における否認防止は、Message Disposition Notifications (MDN) を使用して達成されます。MDN がトランザクションでリクエストされた場合、送信者がメッセージを送信し、受信者がそれを正常に受信し、送信者が送信したメッセージが受信者によって受信されたものと同じメッセージであることを確認します。

Q: AS2 プロトコルを使用したメッセージ送信には、どのようなステップがありますか?

A: メッセージの送信には、送信者からのものと受信者からのものの 2 つの側面があります。送信者が送信するメッセージを決定すると、メッセージは (送信者の秘密キーを使用して) 署名され、(受信者の証明書を使用して) 暗号化され、ハッシュを使用してメッセージの整合性が計算されます。この署名され暗号化されたメッセージは、電信で受信者に送信されます。メッセージが受信されると、(受信者の秘密キーを使用して) 復号化され、(送信者の公開キーを使用して) 検証され、処理され、リクエストがあれば署名された Message Disposition Notifications (MDN) が送信者に送り返され、メッセージの配信が成功したことを確認します。AS2 がどのようにメッセージ送信を処理するかについては、ドキュメントを参照してください。

Q: メッセージ送信で利用可能なオプションは何ですか?

A: 可能なオプションの組み合わせは、送信者の立場から駆動されます。送信者は、データの暗号化のみ、署名のみ (または両方) を選択し、Message Disposition Notifications (MDN) をリクエストすることを選択できます。送信者が MDN をリクエストすることを選択した場合、署名付きまたは未署名の MDN をリクエストすることができます。受信者はこれらのオプションを尊重することが期待されます。

Q: Message Disposition Notifications (MDN) のリクエストは任意ですか?

A: はい、送信者は MDN をリクエストするかどうか、署名付きまたは未署名の MDN をリクエストするかどうか、また MDN に署名するために使用すべき署名アルゴリズムを、選択することができます。

Q: 同期 (Sync) と非同期 (Async) の MDN はサポートされていますか? また、どのような場合にどちらのオプションを使用すればよいですか?

A: 現在のところ、同期型 MDN のみサポートしています。同期型 MDN は、メッセージと同じ接続チャネルで送信されるため、よりシンプルであり、推奨されるオプションです。MDN を送信する前にメッセージの処理に時間が必要な場合は、非同期型 MDN をお勧めします。非同期型 MDN のサポートが必要な場合は、AWS サポートまたはアカウントマネージャーを通じてお問い合わせください。

Q: 送受信されたペイロードや MDN を追跡および検索する方法はありますか?

A: AWS Transfer Family は、交換されたペイロードと MDN から主要な AS2 情報を抽出し、JSON ファイルとして Amazon S3 バケットに保存します。これらの JSON ファイルは、S3 Select や Amazon Athena でクエリしたり、Amazon OpenSearch や Amazon DocumentDB を使用してファイルのインデックスを作成して分析することができます。

Q: 受信した MDN を (リクエストした送信者として) アーカイブすることはできますか?

A: はい、トレーディングパートナーから MDN を受信すると、サービスはお客様の証明書を使用して MDN を検証し、お客様の Amazon S3 バケットにメッセージを保存します。S3 ライフサイクルポリシーを活用することで、メッセージをアーカイブすることを選択できます。

Q: トレーディングパートナーのエンドポイントにメッセージを配信する準備ができた場合、どのように AWS Transfer Family に通知すればよいですか?

A: データが配信可能な状態になったら、サービス提供の API を呼び出し、配信する準備ができていることを通知するコネクタを関連付け、受信者の情報を提供する必要があります。これにより、トレーディングパートナーのエンドポイントにメッセージを送信するようサービスに通知されます。AS2 上でトレーディングパートナーにメッセージを送信するには、コネクタに関するドキュメントを参照してください。

Q: メッセージのインバウンドとアウトバウンドの場所を使い分けるために、それぞれのトレーディングパートナーを分離することはできますか?

A: はい、トレーディングパートナーのプロファイルをセットアップする際に、トレーディングパートナーごとに異なるフォルダを使用することができます。

Q: トレーディングパートナーの既存のキーや証明書を AWS Transfer Family AS2 エンドポイントで使用することは可能ですか?

A: はい、パートナーの既存のキーと証明書をインポートし、更新とローテーションを管理することができます。証明書のインポートに関するドキュメントを参照してください。

Q: トレーディングパートナーの証明書の有効期限はどのように知ることができますか?

A: AWS Transfer Family のコンソールを使用すると、有効期限でソートされた証明書のダッシュボードを表示することができます。また、証明書の有効期限が切れる前に通知を受け取るように設定することができますので、運用の中断を防ぐために十分な時間をかけて証明書をローテーションすることができます。

Q: AWS Transfer Family は AS2 Drummond Certified をサポートしていますか?

A: いいえ。AWS Transfer Family の AS2 のサポートは現在、Drummond Pre-Certified であり、2023 年に Drummond Certified となる予定です。詳細については、このお知らせをご覧ください。

Q: AS3 および AS4 はサポートされていますか?

A: いいえ。

Q: アップロード後の処理のためのマネージドワークフローとは何ですか?

A: AWS Transfer Family マネージドワークフローは、SFTP、FTPS、FTP によるファイル転送のアップロード後の処理の作成、実行、モニタリングをより容易にします。この機能を使用すると、ファイルのコピー、タグ付け、複号などの必要なタスクをすべて調整するローコードのオートメーションによって時間を節約できます。また、PII、ウイルス/マルウェア、またはファイルの形式やタイプが正しくないなどのエラーをスキャンするようにカスタマイズすることもできます。これにより、異常を迅速に検出してコンプライアンス要件を満たすことができます。

Q: なぜマネージドワークフローが必要なのですか?

A: ビジネスパートナーとやり取りするファイルを AWS Transfer Family を使用して処理する必要がある場合、カスタムコードを実行し、実行時のエラーや異常を継続的にモニタリングし、データに対するすべての変更と変換を監査してログに残すためのインフラストラクチャを設定する必要があります。さらに、技術的なものとビジネス的なものの両方のエラーシナリオを考慮し、フェイルセーフモードが適切にトリガーされるようにする必要があります。また、トレーサビリティーが必要な場合は、データがシステムのさまざまなコンポーネントを通過する際に、データの系統を追跡する必要があります。ファイル処理ワークフローの個別のコンポーネントを維持することは、ビジネスのためにできるであろう差別化のための仕事に集中する時間を奪うことになります。マネージドワークフローは、複数のタスクを管理する複雑さを取り除き、組織全体で複製可能な標準化されたファイル処理ソリューションを提供します。また、各ステップで例外処理とファイルのトレーサビリティが組み込まれており、ビジネス要件と法的要件を満たすのに役立ちます。

Q: マネージドワークフローを使用することの利点は何ですか?

A: マネージドワークフローでは、ユーザー固有のフォルダへのファイルの移動、転送中のファイルの暗号化、マルウェアスキャン、タグ付けなどのファイル処理タスクをオーケストレートし、下流のアプリケーションで使用される前にデータを簡単に前処理することが可能です。Infrastructure as Code (IaC) を使用してワークフローをデプロイすることで、組織内の複数のビジネスユニットにまたがる共通のアップロード後ファイル処理タスクを迅速に複製し、標準化することができます。 完全にアップロードされたファイルにのみトリガーされるマネージドワークフローを定義して、データ品質を確実に維持したり、部分的にアップロードされたファイルにトリガーされるマネージドワークフローを定義して、不完全なアップロードに対する処理を設定することにより、きめ細かい制御を行うことができます。例外処理が組み込まれているため、ワークフローの実行中にエラーや例外が発生した場合、ファイル処理の結果に迅速に対応でき、ビジネスおよび技術的な SLA を維持しながら、障害を処理する方法を制御することができます。最後に、ワークフローの各ステップは詳細なログを生成し、これを監査することでデータ系統をたどることができます。

Q: ワークフローの使用を開始するにはどうすればよいですか?

A: まず、コピーやタグ付けなどのアクションや、要件に応じて独自のカスタムステップを含む一連のアクションを含めることができるように、ワークフローを設定します。次に、ワークフローをサーバーにマッピングすることで、ファイルの到着時に、このワークフローで指定されたアクションがリアルタイムで評価され、トリガーされます。詳細については、ドキュメントを参照するか、マネージドワークフローを始めるためのこのデモを見るか、このブログポストを使用してクラウドネイティブのファイル転送プラットフォームをデプロイしてください。

Q: 同じワークフローの設定を複数のサーバーで使用できますか?

A: はい。同じワークフローを複数のサーバーに割り当てることができますので、設定の維持や標準化が容易になります。

Q: ワークフローを使って、ファイルにどのようなアクションを起こせますか?

A: 転送サーバーがクライアントからファイルを受け取った後、次の一般的なアクションが可能です。

• PGP キーを使用したファイルの復号
• 到達した場所から消費されるべき場所にデータを移動またはコピーする。
• アーカイブまたは新しい場所にコピーした後、元のファイルを削除してください。
• ファイルの内容に応じてタグ付けし、下流のサービス (S3 のみ) でインデックスを付けて検索できるようにする
• 独自の Lambda 関数をワークフローのカスタムステップとして提供することによる、任意のカスタムファイル処理ロジック。例えば、データ分析にファイルを取り込む前に、ファイルタイプの互換性チェック、ファイルのマルウェアスキャン、個人を特定できる情報 (PII) の検出、メタデータの抽出を実行するなどです。

Q: ワークフローを使用して、PGP を使用したファイルを自動的に復号することはできますか?

A: はい。ファイルの PGP 復号には、事前構築済みのフルマネージドワークフローステップを使用できます。詳細については、マネージドワークフローのドキュメントを参照してください。

Q: ワークフローの各ステップで処理するファイルを選択することはできますか?

A: はい。当初アップロードされたファイルまたは前のワークフローステップの出力ファイルのいずれかを処理するようにワークフローステップを設定することができます。これにより、Simple Storage Service (Amazon S3) にアップロードされた後のファイルの移動や名前の変更を簡単に自動化することができます。例えば、ファイルのアーカイブや保持のためにファイルを別の場所に移動するには、ワークフローで 2 つのステップを構成します。最初のステップは、ファイルを別の Simple Storage Service (Amazon S3) の場所にコピーすることであり、2 番目のステップは、当初アップロードされたファイルを削除することです。ワークフローステップのファイルロケーションの選択に関する詳細は、ドキュメントをお読みください。

Q: レコード保持のために、当初アップロードされたファイルを保存することはできますか?

A: はい。ワークフローを使用すると、レコード保持のためにオリジナルファイルを保存しながら、オリジナルファイルの複数のコピーを作成することができます。

Q: ワークフローを使用して、ユーザー固有の Simple Storage Service (Amazon S3) フォルダにファイルを動的にルーティングできますか?

A: はい。ワークフローのコピー手順でユーザーネームを変数として利用できます。これにより、Simple Storage Service (Amazon S3) のユーザー固有のフォルダにファイルを動的にルーティングできます。これは、ファイルをコピーするときに宛先フォルダの場所をハードコーディングする必要性を排除し、Simple Storage Service (Amazon S3) でのユーザー固有のフォルダの作成が自動化するため、ファイルオートメーションワークフローをスケールすることを可能にします。詳細については、ドキュメントをご覧ください。

Q: ワークフローはどのようにモニタリングしますか?

A: ワークフローの実行は、ワークフローの実行数、成功した実行数、失敗した実行数の合計などの AWS CloudWatch メトリクスを使用してモニタリングすることができます。AWS マネジメントコンソールを使って、進行中のワークフローの実行状況を検索し、リアルタイムで確認することもできます。ワークフローの実行の詳細なログを取得するには、CloudWatch Logs を使用します。

Q: どのような種類の通知を受け取ることができますか?

A: カスタム処理ステップを使用して、EventBridge または Simple Notification Service (SNS) への通知をトリガーし、ファイルの処理が完了したときに通知を受けることができます。さらに、Lambda 実行時の CloudWatch Logs を利用して通知を受けることもできます。

Q: AWS Step Functions を使って、ファイル処理ステップをオーケストレートしています。AWS Transfer Family マネージドワークフローは、現在の AWS Step Functions のセットアップとどのように異なりますか?

A: AWS Step Functions はサーバーレスのオーケストレーションサービスで、AWS Lambda と他のサービスを組み合わせて、ビジネスアプリケーションの実行をシンプルなステップで定義することができます。AWS Step Functions を使用してファイル処理のステップを実行するには、AWS Lambda 関数と Amazon S3 のイベントトリガーを使用して、お客様独自のワークフローを組み立てます。マネージドワークフローは、直線的な一連の処理を簡単にオーケストレートするためのフレームワークを提供し、以下の点で既存のソリューションとは異なります。1) 完全なファイルのアップロード時のみ実行するワークフローと、部分的なファイルのアップロード時のみ実行するワークフローをきめ細かく定義できる、2) ワークフローは S3 だけでなく EFS (アップロード後のイベントを提供しない) に対しても自動的にトリガーされる、3) お客様は CloudWatch Logs でファイルの転送と処理をエンドツーエンドで可視化できる、という点です。

Q: ファイル検証チェックが失敗した場合、通知を送ることはできますか?

A: はい。事前に設定された検証ステップに対してファイル検証チェックが失敗した場合、例外ハンドラーを使用して、Amazon SNS トピックを介してモニタリングシステムまたはチームメンバーを呼び出すことができます。

Q: ワークフローは、部分的なアップロードに対してトリガーされますか?

A: はい。ワークフローは、完全なファイルおよび部分的なファイルのアップロードの両方でトリガーされるように定義することができます。

Q: AS2 経由のメッセージ交換に基づいて、ワークフローのアクションをトリガーすることはできますか?

A: いいえ、現在 AS2 でマネージドワークフローを使用することはできません。

Q: ユーザーのダウンロードに対してワークフローのアクションをトリガーすることはできますか?

A: いいえ。処理は、インバウンドエンドポイントを使用したファイル到着時にのみ起動できます。

Q: セッション内のファイルのバッチに対して同じワークフローをトリガーできますか?

A: いいえ。ワークフローは現在、1 回の実行につき 1 つのファイルを処理します。

Q: AWS Transfer Family と Simple Storage Service (Amazon S3) はどのように通信するのですか?

A: AWS Transfer Family のサーバーと Simple Storage Service (Amazon S3) 間のデータ転送は、AWS の内部ネットワーク上で行われ、パブリックインターネットを通過することはありません。このため、AWS Transfer Family サーバーから Simple Storage Service (Amazon S3) へ転送するデータには、AWS PrivateLink を使用する必要はありません。Transfer Family サービスは、トラフィックがインターネットを経由しないようにするために Simple Storage Service (Amazon S3) 用の AWS PrivateLink エンドポイントを必要としないので、ストレージサービスとの通信にそれらを使用することはできません。これはすべて、AWS のストレージサービスと Transfer Family サーバーが同じリージョンにあると仮定します。

Q: AWS IAM ロールを提供する必要がある理由を教えてください。また、AWS IAM ロールはどのように使用されるのですか?

A: AWS IAM を使用して、ユーザーに提供するアクセスのレベルを指定します。これには、クライアントで有効にする操作、ユーザーにアクセス権を付与する Amazon S3 バケット (バケット全体、バケットの一部を問わない) が含まれます。

Q: ホームディレクトリ情報を提供する必要がある理由を教えてください。また、ホームディレクトリ情報はどのように使用されるのですか?

A: ユーザーに設定するホームディレクトリで、ユーザーのログインディレクトリを指定します。これが、サーバーへの認証が成功すると、ユーザーのクライアントが位置するディレクトリパスになります。与えられたIAMロールにより、必ずユーザーがホームディレクトリへアクセスできるようにしなければなりません。

Q: 数百人規模のユーザーがいます。ユーザーのアクセス設定は類似していますが、アクセスするバケットの部分は異なります。同じ IAM ロールとポリシーを使用してアクセスを有効にするようユーザーを設定することはできますか?

A: はい。単一の IAM ロールをすべてのユーザーにアサインし、ディレクトリの論理マッピングを使用できます。このマッピングで、Amazon S3 のどの絶対パスがエンドユーザーに表示されるか、またクライアントがどのようにこれらのパスをエンドユーザーに表示するかを指定できます。chroot と論理ディレクトリで AWS SFTP/FTPS/FTP 構造をシンプルにする方法に関するこちらのブログをご覧ください。

Q: AWS Transfer を使って転送されたファイルは、Amazon S3 バケットにどのように保存されるのですか?

A: サポート対象のプロトコルを介して転送されたファイルは、オブジェクトとして Amazon S3 バケットに保存されます。ファイルとオブジェクト間は 1 対 1 でマッピングされるため、処理や分析用の AWS のサービスを使用して、これらのオブジェクトにネイティブにアクセスすることが可能となります。

Q: バケットに保存されている Amazon S3 オブジェクトは、ユーザーにどのように表示されるのですか?

A: ユーザーの認証情報に基づき認証が成功した後、サービスでは Amazon S3 のオブジェクトとフォルダがファイルとディレクトリとしてユーザーの転送アプリケーションに表示されます。

Q: どのようなファイル操作がサポートされていますか? また、サポートされていないのはどのような操作ですか?

A: ファイルやディレクトリの作成、読み取り、更新、削除などの一般的なコマンドがサポートされています。ファイルは Amazon S3 バケットに個々のオブジェクトとして保存されます。ディレクトリは S3 コンソールと同じ構文を使用して、S3 内のフォルダオブジェクトとして管理されます。

ディレクトリのリネーム操作、追加操作、所有権、許可、タイムスタンプの変更、シンボリックリンクとハードリンクの使用は、現在サポートされていません。

Q: どの操作の実行をユーザーに許可するか、制御することはできますか?

A: はい。ユーザー名にマッピングしている AWS IAM ロールを使用して、ファイル操作を有効/無効にできます。「エンドユーザーを制御するための IAM ポリシーとロールの作成」についてのドキュメントをご参照ください。

Q: エンドユーザーに、2 つ以上の Amazon S3 バケットへのアクセスを付与することはできますか?

A: はい。ユーザーがアクセスできるバケットは、AWS IAM ロールと、そのユーザーに割り当てたオプションの scope-down policy によって決定されます。そのユーザーのホームディレクトリとして使用できるバケットは 1 つのみです。

Q: S3 アクセスポイントを AWS Transfer Family と併用して、共有データセットへのユーザーアクセスを簡素化することはできますか?

A: はい。S3 アクセスポイントのエイリアスを AWS Transfer Family と併用することで、単一のバケットポリシーを管理することなく、大規模なデータセットへのきめ細かなアクセスを提供することができます。S3 アクセスポイントのエイリアスと AWS Transfer Family 論理ディレクトリを組み合わせることで、バケットポリシーの管理にかかるオーバーヘッドを軽減しつつ、異なるアプリケーション、チーム、部門に対するきめ細かいアクセスコントロールを実現することができます。詳細および開始するには、AWS Transfer Family と Simple Storage Service (Amazon S3) アクセスポイントによるデータアクセスコントロールの強化に関するブログ投稿をご覧ください。

Q: AWS アカウント A を使ってサーバーを作成し、AWS アカウント B が所有している Amazon S3 バケットにユーザーをマッピングすることは可能ですか?

A: はい。CLI と API を使用して、サポート対象のプロトコルで送信されたファイルを格納するバケットとサーバー間のクロスアカウントアクセスを設定できます。コンソールのドロップダウンには、アカウント A にあるバケットしか表示されません。さらに、ロールが、アカウント A に属しているユーザーに割り当てられていることを確認する必要もあります。

Q: Simple Storage Service (Amazon S3) にアップロードされたファイルの処理を自動化できますか?

A: はい、AWS Transfer Family マネージドワークフローを使用して、Simple Storage Service (Amazon S3) にファイルがアップロードされた後のファイル処理を作成、自動化、モニタリングすることができます。マネージドワークフローを使用することで、独自のカスタムコードやインフラストラクチャを管理するオーバーヘッドなしに、データ分析や処理システムに取り込む前にファイルを前処理することができます。 AWS Transfer Family マネージドワークフローについては、ドキュメントをご覧ください。

Q: ファイルをアップロードしたユーザーに基づいて、処理ルールをカスタマイズできますか?

A: はい。ユーザーがファイルをアップロードすると、アップロードに使用されたユーザー名とサーバー ID が、関連する S3 オブジェクトのメタデータの一部として格納されます。この情報をアップロード後の処理に利用できます。 アップロード後の処理に使用する情報については、ドキュメントを参照してください。

Q: AWS Transfer Family と連携するように EFS ファイルシステムを設定するにはどうすればよいですか?

A: Amazon EFS ファイルシステムで動作するように AWS Transfer Family を設定する前に、AWS Transfer Family ユーザーに割り当てる予定のと同じ POSIX ID (ユーザー ID/グループ ID) を使用してファイルとフォルダの所有権を設定する必要があります。さらに、別のアカウントのファイルシステムにアクセスする場合は、アカウント間のアクセスを有効にするために、ファイルシステムでリソースポリシーも設定する必要があります。 EFS で AWS Transfer Family を使用するためのステップバイステップの手順については、このブログ投稿を参照してください。

Q: AWS Transfer Family と Amazon EFS はどのように通信するのですか?

A: AWS Transfer Family サーバーと Amazon EFS 間のデータ転送は、AWS の内部ネットワーク上で行われ、パブリックインターネットを通過することはありません。このため、AWS Transfer Family サーバーから Amazon EFS に転送するデータには、AWS PrivateLink を使用する必要はありません。Transfer Family サービスは、トラフィックがインターネットを経由しないようにするために Amazon EFS 用の AWS PrivateLink エンドポイントを必要としないので、ストレージサービスとの通信にそれらを使用することはできません。これはすべて、AWS のストレージサービスと Transfer Family サーバーが同じリージョンにあると仮定します。

Q: ファイルシステムとの間でファイルをアップロード/ダウンロードするためのアクセス権をユーザーに付与するにはどうすればよいですか?

A: Amazon EFS は、オペレーティングシステムのユーザー ID、グループ ID、およびセカンダリグループ ID で構成される POSIX ID を使用して、ファイルシステムへのアクセスを制御します。AWS Transfer Family コンソール/CLI /API でユーザーを設定するときは、EFS ファイルシステムにアクセスするためにユーザー名、ユーザーの POSIX 設定、IAM ロールを指定する必要があります。また、EFS ファイルシステム ID と、オプションでそのファイルシステム内のディレクトリをユーザーのランディングディレクトリとして指定する必要があります。AWS Transfer Family ユーザーがファイル転送クライアントを使用して正常に認証されると、指定されたホームディレクトリ、または指定された EFS ファイルシステムのルート内に直接配置されます。オペレーティングシステムの POSIX ID は、ファイル転送クライアントを介して行われるすべてのリクエストに適用されます。EFS 管理者は、AWS Transfer Family ユーザーにアクセスさせたいファイルとディレクトリが、EFS ファイルシステム内の対応する POSIX ID によって所有されていることを確認する必要があります。EFS でのサブディレクトリの所有権の設定の詳細については、ドキュメントを参照してください。

Q: Amazon EFS ファイルシステムに保存されているプロトコルを介してファイルを転送するにはどうすればよいですか?

A: 有効化されたプロトコルを介して転送されたファイルは、Amazon EFS ファイルシステムに直接保存され、標準のファイルシステムインターフェイスを介して、または Amazon EFS ファイルシステムにアクセスできる AWS のサービスからアクセスできます。

Q: Amazon S3 と Amazon EFS を使用する場合、プロトコル上でサポートされるファイル操作は何ですか?

A: ファイル、ディレクトリ、およびシンボリックリンクを作成、読み取り、更新、および削除するための SFTP/FTPS/FTP コマンドがサポートされています。EFS および S3 でサポートされているコマンドについては、以下の表を参照してください。

1. ファイルの名前変更のみがサポートされています。ディレクトリの名前変更および既存のファイルを上書きするためのファイルの名前変更はサポートされていません。

2. root、つまり uid=0 のユーザーのみが、ファイルとディレクトリの所有権と権限を変更できます。

3. ルート (例: uid=0)、またはファイルのグループをセカンダリグループの 1 つに変更することしかできないファイルの所有者向けにサポートされています。

4. 空でないフォルダでのみサポートされています。

Q: ユーザーがアクセスできるファイルとフォルダ、および実行を許可されている操作と許可されていない操作を制御するにはどうすればよいですか?

A: AWS Transfer Family ユーザーに提供する IAM ポリシーにより、ユーザーがファイルシステムへの読み取り専用、読み取り/書き込み、およびルートアクセス権を持っているかが決まります。さらに、ファイルシステム管理者は、ユーザー ID とグループ ID を使用して、ファイルシステム内のファイルとディレクトリにアクセスするための所有権と許可を設定できます。これは、ID がサービス内に保管されているか (サービス管理)、ID 管理システム内に保管されているか (「BYO 認証」) にかかわらず、ユーザーに適用されます。

Q: 各ユーザーがファイルシステム内の異なるディレクトリにアクセスし、それらのディレクトリ内のファイルにのみアクセスするように制限できますか?

A: はい。ユーザーを設定するときに、ユーザーごとに異なるファイルシステムとディレクトリを指定できます。認証が成功すると、EFS は、有効化されたプロトコルを使用して行われたすべてのファイルシステムリクエストに対してディレクトリを適用します。

Q: ファイルシステムの名前がユーザーに公開されないように隠すことはできますか?

A: はい。AWS Transfer Family 論理ディレクトリマッピングを使用すると、絶対パスをエンドユーザーに表示されるパス名にマッピングすることで、エンドユーザーにファイルシステム内のディレクトリが表示されないようにすることができます。これには、指定されたホームディレクトリにユーザーを「chroot」できることも含まれます。

Q: シンボリックリンクはサポートされていますか?

A: はい。ユーザーがアクセスできるディレクトリにシンボリックリンクが存在し、ユーザーがそれらにアクセスしようとすると、リンクはターゲットに解決されます。論理ディレクトリマッピングを使用してユーザーのアクセスを設定する場合、シンボリックリンクはサポートされません。

Q: 複数のファイルシステムへの SFTP/FTPS/FTP ユーザーアクセス権を個別に提供できますか?

A: はい。AWS Transfer Family ユーザーを設定する際、ユーザー設定の一部として提供する IAM ポリシーで 1 つ以上のファイルシステムを指定することで、複数のファイルシステムへのアクセスを許可できます。

Q: AWS Transfer Family を介して EFS ファイルシステムにアクセスするために使用できるオペレーティングシステムは何ですか?

A: Microsoft Windows、Linux、macOS、または SFTP/FTPS/FTP をサポートする任意のオペレーティングシステム向けに構築されたクライアントとアプリケーションを使用して、EFS ファイルシステムに保存されているファイルをアップロードおよびアクセスできます。すべてのオペレーティングシステムでファイルシステムにアクセスできるようにするには、サーバーと、EFS ファイルシステムへの適切なアクセス許可を持つユーザーを設定するだけです。

Q: ファイルが EFS にアップロードされた後のファイル処理ステップを自動化してモニタリングするにはどうすればよいですか?

A: AWS Transfer Family マネージドワークフローを作成して、ファイルが EFS にアップロードされた後のファイル処理を自動的にトリガーすることができます。ワークフローには、タグ付け、コピー、ビジネス要件に基づいてファイルに実行したい任意のカスタム処理ステップを含むものを設定できます。詳細は AWS Transfer Family マネージドワークフローのドキュメントをご覧ください。

Q: ファイルをアップロードしたユーザーを確認するにはどうすればよいですか?

A: 新しいファイルの場合、ファイルをアップロードするユーザーに関連付けられた POSIX ユーザー ID が、EFS ファイルシステム内のファイルの所有者として設定されます。さらに、Amazon CloudWatch を使用して、ファイルの作成、更新、削除、および読み取り操作に関するユーザーのアクティビティを追跡できます。Amazon CloudWatch のログ記録を有効にする方法の詳細については、ドキュメントをご覧ください。

Q: 有効化されたプロトコルを介してアップロードおよびダウンロードされたデータの量を表示できますか?

A: はい。サーバーを使用してアップロードおよびダウンロードされたデータのメトリクスは、AWS Transfer Family 名前空間内の Amazon CloudWatch に公開されます。トラッキングとモニタリングに使用できる指標を表示する方法については、こちらのドキュメントをご覧ください。

Q: AWS Transfer Family を使用して別のアカウントのファイルシステムにアクセスできますか?

A: はい。CLI と API を使用して、AWS Transfer Family リソースと EFS ファイルシステム間のクロスアカウントアクセスを設定できます。AWS Transfer Family コンソールは、同じアカウントのファイルシステムのみを一覧表示します。さらに、ファイルシステムにアクセスするためにユーザーに割り当てられた IAM ロールがアカウント A に属していることを確認する必要があります。

Q: EFSファイルシステムでクロスアカウントアクセスに対して適切なポリシーが有効になっていない場合はどうなりますか?

A: クロスアカウントアクセスが有効になっていないクロスアカウント EFS ファイルシステムにアクセスするように AWS Transfer Family サーバーを設定した場合、SFTP/FTP/FTPS ユーザーによりファイルシステムへのアクセスは拒否されます。サーバーで CloudWatch ログ記録を有効にしている場合、クロスアカウントアクセスエラーは CloudWatch Logs に記録されます。

Q: AWS Transfer Family を使用して別の AWS リージョンの EFS ファイルシステムにアクセスできますか?

A: いいえ。AWS Transfer Family を使用してアクセスできるのは、同じ AWS リージョン内の EFS ファイルシステムのみです。

Q: すべての EFS ストレージクラスで AWS Transfer Family を使用できますか?

A: はい。AWS Transfer を使用してファイルを EFS に書き込み、EFS Lifecycle Management を設定して、一定期間アクセスされていないファイルを低頻度アクセス (IA) ストレージクラスに移行できます。

Q: アプリケーションで SFTP/FTPS/FTP を使用して、同じファイルとの間でデータの読み取りと書き込みを同時に行うことはできますか?

A: はい。Amazon EFS にはファイルシステムインターフェイスとファイルシステムのアクセスセマンティクス (強い整合性やファイルのロックなど) が用意されており、最大数千の NFS/SFTP/FTPS/FTP クライアントからの同時アクセスが可能なストレージが提供されます。

Q: AWS Transfer Family を使用してファイルシステムにアクセスすると、EFS バーストクレジットが消費されますか?

A: はい。AWS Transfer Family サーバーを使用して EFS ファイルシステムにアクセスすると、スループットモードに関係なく、EFS バーストクレジットが消費されます。 使用可能なパフォーマンスモードとスループットモードに関するドキュメントを参照し、いくつかの役立つパフォーマンスのヒントをご覧ください。

Q: パブリックネットワーク上で送信中のデータのセキュリティのために使用するべきプロトコルはどれですか?

A: パブリックネットワーク上でのセキュアな送信のためには、SFTP または FTPS を使用する必要があります。SSH および TLS 暗号化アルゴリズムに基づくプロトコルの基盤となるセキュリティにより、データとコマンドはセキュアな暗号化されたチャネルを通して送信されます。

Q: 保管時のデータを暗号化するためのオプションは何ですか?

A: バケット保管されたファイルを暗号化するには、Amazon S3 Server-Side Encryption (SSE-S3) または Amazon KMS (SSE-KMS) を使用できます。 EFS に保管されているファイルの場合、保管中のファイルの暗号化に AWS またはカスタマーマネージド CMK を選択できます。Amazon EFS を使用したファイルデータとメタデータの保存時暗号化のオプションの詳細については、ドキュメントを参照してください。

Q: AWS Transfer Family はどのコンプライアンスプログラムをサポートしていますか?

A: AWS Transfer Family は、PCI-DSS、GDPR、FedRAMP、SOC 1、2、および 3 に準拠しています。このサービスは HIPPA 二も準拠しています。コンプライアンスプログラム別の対象範囲内のサービスをご確認ください。

Q: AWS Transfer Family は FISMA に準拠していますか?

A: AWS の East/West リージョンと GovCloud (米国) リージョンは FISMA に準拠しています。FedRAMP の認定を受けた AWS Transfer Family は、該当リージョン内で FISMA への準拠が認められます。この 2 つのリージョンの FedRAMP Authorization により、FedRAMP 中および FedRAMP 高のコンプライアンスが証明されています。コンプライアンスは、システムセキュリティ計画の範囲に含まれる NIST SP 800-53 による毎年の評価と記録により証明されています。アーティファクトではテンプレートと CRM (Customer Responsibility Matrix) を使用できます。CRM は、FedRAMP で要求されているこうした NIST の規制を満たすための基準や責任を示すものです。アーティファクトは、East/West と GovCloud の両方の AWS アカウントでアクセスできるマネジメントコンソールから使用できます。このトピックについての疑問点があれば、コンソールでご確認ください。

Q: サービスでは、アップロードしたファイルの整合性をどのように確保していますか?

A: サービスからアップロードされたすべてのファイルは、ファイルのアップロード前とアップロード後の MD5 チェックサムを比較することで検証されます。

Q: エンドユーザーのアクティビティをどのように監視できますか?

A: Amazon CloudWatch と CloudTrail ログを使用して、エンドユーザーのアクティビティをモニタリングすることができます。また、AWS Transfer Family Management Console で、転送されたファイル数やバイト数などのメトリクスの CloudWatch グラフにアクセスできるようになったため、一元化されたダッシュボードを使用してファイル転送をモニタリングすることができます。AWS CloudTrail ログを使用して、エンドユーザーのデータリクエストを処理するためにサーバーから呼び出されたすべての API 操作のレコードにアクセスします。詳細については、ドキュメントをご覧ください。

Q: 転送のためにファイルを暗号化/復号するオプションにはどのようなものがありますか?

A: AWS Transfer Family マネージドワークフローで PGP キーを使用して、AWS Transfer Family のリソースにアップロードされたファイルを自動的に復号できます。詳細については、マネージドワークフローのドキュメントを参照してください。PGP 暗号化のサポートをお求めの場合は、AWS サポートまたは AWS アカウントチームを通じてお問い合わせください。

Q: このサービスを使用すると請求はどうなりますか?

A: 有効にした各プロトコルについて、サーバーエンドポイントを作成および設定してから削除するまでの間、1 時間単位で課金されます。また、SFTP、FTPS、または FTP 経由でアップロードおよびダウンロードされたデータの量、AS2 経由でやり取りされたメッセージの数、および Decrypt ワークフローステップを使用して処理されたデータの量に基づいて請求されます。詳細については、料金ページをご覧ください。

Q: 複数のプロトコルに 1 つのサーバーエンドポイントを使用する場合と、プロトコルごとに異なるエンドポイントを使用する場合では、請求は異なりますか?

A: いいえ。有効化したプロトコルごとの時間数と、各プロトコルを介して送信したデータ量に基づき請求されます。複数のプロトコルに対して 1 つのエンドポイントが有効であるか、プロトコルごとに異なるエンドポイントを使用しているかは請求にかかわりません。

Q: サーバーを停止しました。停止している間も料金が発生しますか？

A: はい。サーバーの停止は料金には影響しません。これは停止にコンソールを使用した場合でも、CLI コマンド「stop-server」または API コマンド「StopServer」を実行した場合でも同様です。サーバーエンドポイントを作成しアクセスを構成してから削除するまでの間、各プロトコルに対して、1 時間単位で課金されます。

Q: マネージドワークフローを利用した場合、どのように請求されますか?

A: PGP キーを使用して復号するデータの量に基づいて、Decrypt ワークフローステップの料金が請求されます。マネージドワークフローを使用するためのその他の追加料金はありません。ワークフローの設定に応じて、Amazon S3、Amazon EFS、AWS Secrets Manager、AWS Lambda の使用についても課金されます。