AS2 メッセージの送受信

このセクションでは、AS2 メッセージを送受信するプロセスについて説明します。また、AS2 メッセージに関連付けられたファイル名と場所に関する詳細も提供します。

次の表に、AS2 メッセージで使用できる暗号化アルゴリズムと、それらを使用できるタイミングを示します。

暗号化アルゴリズム	HTTP	HTTPS	メモ
AES128_CBC	はい	あり
AES192_CBC	はい	あり
AES256_CBC	はい	あり
DES_EDE3_CBC	はい	あり	このアルゴリズムは弱い暗号化アルゴリズムであるため、それを必要とするレガシークライアントをサポートする必要がある場合のみ使用してください。
なし	なし	あり	Transfer Family サーバーにメッセージを送信する場合は、Application Load Balancer (ALB) NONEを使用している場合にのみ選択できます。

AS2 メッセージプロセスの送信

アウトバウンドプロセスは、 から外部クライアントまたはサービス AWS に送信されるメッセージまたはファイルとして定義されます。アウトバウンドメッセージのシーケンスは以下の通りである：

1. 管理者は start-file-transfer AWS Command Line Interface （AWS CLI) コマンドまたは StartFileTransfer API オペレーションを呼び出します。この操作は connector 設定を参照します。

2. Transfer Family は新しいファイルリクエストを検出し、ファイルを見つけます。ファイルは圧縮、署名、暗号化されます。

3. 転送 HTTP クライアントは HTTP POST リクエストを実行して、ペイロードをパートナーの AS2 サーバーに送信します。

4. このプロセスは、署名された MDN 応答を HTTP 応答 (同期 MDN) とインラインで返します。

5. ファイルがさまざまな転送段階の間を移動すると、プロセスは MDN 応答の受信と処理の詳細を顧客に配信します。

6. リモート AS2 サーバーは、復号化され検証されたファイルをパートナー管理者が利用できるようにします。

AS2 処理は、一般的なユースケースと既存の AS2 対応サーバー実装との統合に重点を置いて、RFC 4130 プロトコルの多くをサポートしています。サポートされている構成の詳細については、 を参照してください。

AS2 メッセージプロセスを受信する

インバウンドプロセスは、 AWS Transfer Family サーバーに転送されるメッセージまたはファイルとして定義されます。受信メッセージの順序は次のとおりです。

1. 管理プロセスまたは自動プロセスが、パートナーのリモート AS2 サーバーで AS2 ファイル転送を開始します。

2. パートナーのリモート AS2 サーバーは、ファイルの内容に署名して暗号化し、Transfer Family でホストされている AS2 インバウンドエンドポイントに HTTP POST リクエストを送信します。

3. サーバー、パートナー、証明書、および契約の設定値を使用して、Transfer Family は AS2 ペイロードを復号化して検証します。ファイルの内容は、設定された Amazon S3 ファイルストアに保存されます。

4. 署名された MDN レスポンスは HTTP レスポンスと一緒に返されるか、別の HTTP POST リクエストを通じて非同期的に元のサーバーに返されます。

5. 監査証跡は、交換の詳細 CloudWatch とともに Amazon に書き込まれます。

6. 復号されたファイルは、inbox/processed という名前のフォルダにあります。

HTTPS 経由の AS2 メッセージの送受信

このセクションでは、AS2 プロトコルを使用して HTTPS 経由でメッセージを送受信する Transfer Family サーバーを設定する方法について説明します。

トピック

• HTTPS 経由で AS2 メッセージを送信
• HTTPS 経由で AS2 メッセージを受信

HTTPS 経由で AS2 メッセージを送信

HTTPS を使用して AS2 メッセージを送信するには、次の情報を含むコネクタを作成します。

• URL には HTTPS URL を指定

• 暗号化アルゴリズムでは、使用可能なアルゴリズムのいずれかを選択します。

  注記

  暗号化を使用しない (つまり、暗号化アルゴリズムNONEに を選択する) ときに Transfer Family サーバーにメッセージを送信するには、Application Load Balancer (ALB) を使用する必要があります。

• 「AS2 コネクタを設定する」の説明に従って、コネクタの残りの値を指定します。

HTTPS 経由で AS2 メッセージを受信

AWS Transfer Family AS2 サーバーは現在、ポート 5080 経由の HTTP トランスポートのみを提供します。ただし、選択したポートと証明書を使用して、Transfer Family サーバー VPC エンドポイントの前にあるネットワークまたはアプリケーションロードバランサーで TLS を終了できます。この方法では、受信 AS2 メッセージに HTTPS を使用させることができます。

前提条件

• VPC は Transfer Family サーバー AWS リージョン と同じ にある必要があります。

• VPC のサブネットは、サーバーを使用するアベイラビリティーゾーン内にある必要があります。

  注記

  Transfer Family サーバーごとに、最大 3 つのアベイラビリティーゾーンをサポートできます。

• サーバーと同じリージョンに最大 3 つの Elastic IP アドレスを割り当てます。または、独自の IP アドレス範囲 (BYOIP) を使用することもできます。

  注記

  Elastic IP アドレスの数は、サーバーエンドポイントで使用するアベイラビリティーゾーンの数と一致する必要があります。

Network Load Balance (NLB) または Application Load Balancer (ALB) のいずれかを設定できます。次の表に、各アプローチの長所と短所を示します。

以下の表は、NLB と ALB を使用して TLS を終了する場合の機能の違いを示しています。

機能	Network Load Balancer (NLB)	Application Load Balancer (ALB)
レイテンシー	ネットワークレイヤーで動作するため、レイテンシーが低くなります。	アプリケーションレイヤーで動作するため、レイテンシーが長くなります。
静的 IP のサポート	静的な Elastic IP アドレスをアタッチできます。	Elastic IP アドレスをアタッチできません: 基になる IP アドレスを変更できるドメインを提供します。
高度なルーティング	アドバンストルーティングをサポートしていません。	高度なルーティングをサポートします。AS2 に必要なX-Forwarded-Protoヘッダーを暗号化なしで挿入できます。 このヘッダーは、developer.mozilla.org ウェブサイトの X-Forwarded-Proto で説明されています。
TLS/SSL 終了	TLS/SSL 終了をサポート	TLS/SSL 終了をサポート
相互 TLS (mTLS)	Transfer Family は現在、mTLS 用の NLB の使用をサポートしていません	mTLS のサポート

Configure NLB

この手順では、VPC でインターネット向け Network Load Balancer (NLB) を設定する方法について説明します。

Network Load Balancer を作成し、サーバーの VPC エンドポイントをロードバランサーのターゲットとして定義するには

1. Amazon Elastic Compute Cloud コンソール (https://console.aws.amazon.com/ec2/) を開きます。

2. ナビゲーションペインで、[ロードバランサー] を選択し、[ロードバランサーを作成] を選択します。

3. [Network Load Balancer] で、[Create] (作成) を選択します。

4. [基本設定] セクションで、以下の情報を入力します。

   • [Name] (名前) に、対象のロードバランサーを表現した説明的な名前を入力します。

   • [スキーム] で、[インターネット接続] を選択します。

   • [IP アドレスタイプ] で、[ipv4] を選択します。

5. [ネットワークマッピング] セクションで、以下の情報を入力します。

   • [VPC] で、作成した仮想プライベートクラウド (VPC) を選択します。

   • [マッピング] で、サーバーエンドポイントで使用しているのと同じ VPC で使用可能なパブリックサブネットに関連付けられているアベイラビリティーゾーンを選択します。

   • 各サブネットの IPv4 アドレスには、割り当てた Elastic IP アドレスのいずれかを選択します。

6. [リスナーとルーティング] セクションに、以下の情報を入力します。

   • [プロトコル] で [TLS] を選択します。

   • [Port (ポート)] に「5080」と入力します。

   • [デフォルトアクション] で、[ターゲットグループの作成] を選択します。新しいターゲットグループの作成の詳細については、「対象グループを作成するには」を参照してください。

   ターゲットグループを作成した後で、[デフォルトアクション] フィールドにその名前を入力します。

7. [セキュアリスナー設定] セクションの [デフォルト SSL/TLS 証明書] 領域で証明書を選択します。

8. [ロードバランサーの作成] を選択し、NLB を作成します。

9. (オプションですが、推奨されます) Network Load Balancer のアクセスログを有効にして、完全な監査証跡を維持します。これについては、「Network Load Balancer のアクセスログ」を参照してください。

   TLS 接続は NLB で終了するため、このステップをお勧めします。したがって、Transfer Family AS2 CloudWatch ロググループに反映される送信元 IP アドレスは、取引相手の外部 IP アドレスではなく、NLB のプライベート IP アドレスです。

Configure ALB

この手順では、VPC で Application Load Balancer (NLB) を設定する方法について説明します。

Application Load Balancer を作成し、サーバーの VPC エンドポイントをロードバランサーのターゲットとして定義するには

1. Amazon Elastic Compute Cloud コンソール (https://console.aws.amazon.com/ec2/) を開きます。

2. ナビゲーションペインで、[ロードバランサー] を選択し、[ロードバランサーを作成] を選択します。

3. [Application Load Balancer] で [作成] を選択します。

4. ALB コンソールで、ポート 443 (HTTPS) に新しい HTTP リスナーを作成します。

5. (オプション)。相互認証 (mTLS) を設定する場合は、セキュリティ設定と信頼ストアを設定します。

   1. SSL/TLS 証明書をリスナーにアタッチします。

   2. クライアント証明書処理 で、相互認証 (mTLS) を選択します。

   3. 信頼ストア で検証を選択します。

   4. 「mTLS の詳細設定」で、CA 証明書をアップロードして信頼ストアを選択または作成します。

6. 新しいターゲットグループを作成し、Transfer Family AS2 サーバーエンドポイントのプライベート IP アドレスをポート 5080 のターゲットとして追加します。新しいターゲットグループの作成の詳細については、「対象グループを作成するには」を参照してください。

7. ポート 5080 で TCP プロトコルを使用するようにターゲットグループのヘルスチェックを設定します。

8. リスナーからターゲットグループに HTTPS トラフィックを転送する新しいルールを作成します。

9. SSL/TLS 証明書を使用するようにリスナーを設定します。

ロードバランサーを設定すると、クライアントはカスタムポートリスナーを介してロードバランサーと通信します。次に、ロードバランサーはポート 5080 を介してサーバーと通信します。

対象グループを作成するには

1. 前の手順で [ターゲットグループの作成] を選択すると、新しいターゲットグループの [グループの詳細を指定] ページが表示されます。

2. [基本設定] セクションで、以下の情報を入力します。

   • [ターゲットタイプを選択] で [IP アドレス] を選択します。

   • [ターゲットグループ名] に、ターゲットグループの名前を入力します。

   • プロトコル の場合、選択は ALB と NLB のどちらを使用しているかによって異なります。

     • Network Load Balancer (NLB) の場合は、TCP を選択します。

     • Application Load Balancer (ALB) の場合は、HTTP を選択します。

   • [Port (ポート)] に「5080」と入力します。

   • [IP アドレス] タイプで、[ipv4] を選択します。

   • [VPC] で、Transfer Family AS2 サーバー用に作成した VPC を選択します。

3. [ヘルスチェック] セクションで、[ヘルスチェックプロトコル] に [TCP] を選択します。

4. [次へ] をクリックします。

5. [ターゲットの登録] ページで、次の情報を入力します。

   • [ネットワーク] では、Transfer Family AS2 サーバー用に作成した VPC が指定されていることを確認します。

   • [IPv4 アドレス] では、Transfer Family AS2 サーバーのエンドポイントのプライベート IPv4 アドレスを入力します。

     サーバーのエンドポイントが複数ある場合は、[IPv4 アドレスを追加] を選択して別の IPv4 アドレスを入力する行をもう 1 つ追加します。サーバーのすべてのエンドポイントのプライベート IP アドレスを入力し終わるまで、このプロセスを繰り返します。

   • [ポート] が 5080 に設定されていることを確認します。

   • [保留中として以下を含める] を選択し、[レビューターゲット] セクションにエントリを追加します。

6. [レビューターゲット] セクションで、IP ターゲットをレビューします。

7. [ターゲットグループの作成] を選択し、前の NLB の作成手順に戻り、指示された場所に新しいターゲットグループを入力します。

Elastic IP アドレスからサーバーへのアクセスをテストします

Elastic IP アドレスまたは Network Load Balancer の DNS 名を使用して、カスタムポート経由でサーバーに接続します。

重要

ロードバランサーに設定されたサブネットのネットワークアクセスコントロールリスト (ネットワーク ACL) を使用して、クライアント IP アドレスからサーバーへのアクセスを管理します。ネットワーク ACL のアクセス許可はサブネットレベルで設定されるため、ルールはサブネットを使用するすべてのリソースに適用されます。ロードバランサーのターゲットタイプはインスタンスではなく IP アドレスに設定されているため、セキュリティグループを使用してクライアント IP アドレスからのアクセスを制御することはできません。そのため、ロードバランサーはソース IP アドレスを保持しません。Network Load Balancer のヘルスチェックが失敗すると、ロードバランサーはサーバーエンドポイントに接続できなくなります。この問題のトラブルシューティングを行うには、次を確認します。

• サーバーのエンドポイントに関連付けられたセキュリティグループが、ロードバランサーに設定されているサブネットからのインバウンド接続を許可していることを確認します。ロードバランサーは、ポート 5080 を介してサーバーエンドポイントに接続できる必要があります。

• サーバーの [状態] が [オンライン] であることを確認します。

AS2 コネクタを使用したファイルの転送

AS2コネクタは、Transfer Familyサーバーからパートナーが所有する外部の宛先にAS2メッセージを転送するための取引パートナー間の関係を確立します。

Transfer Family を使用して AS2 メッセージを送信するには、次の start-file-transfer AWS Command Line Interface （AWS CLI) コマンドに示すように、コネクタ ID とファイルへのパスを参照します。

aws transfer start-file-transfer --connector-id c-1234567890abcdef0 \
--send-file-paths "/DOC-EXAMPLE-SOURCE-BUCKET/myfile1.txt" "/DOC-EXAMPLE-SOURCE-BUCKET/myfile2.txt"

コネクタの詳細情報を取得するには、次のコマンドを実行しする：

aws transfer list-connectors

list-connectors コマンドは、コネクタのコネクタ ID、URL、Amazon リソースネーム (ARN) を返します。

特定のコネクタのプロパティを返すには、使用する ID を指定して以下のコマンドを実行します。

aws transfer describe-connector --connector-id your-connector-id

describe-connector コマンドは、URL、ロール、プロファイル、メッセージ処理通知 (MDN)、タグ、モニタリングメトリックなど、コネクタのすべてのプロパティを返します。

JSON と MDN ファイルを表示すると、パートナーがファイルを正常に受信したことを確認できます。これらのファイルには、ファイル名と場所 で説明されている規則に従って名前が付けられます。コネクタの作成時にログ記録ロールを設定した場合は、 CloudWatch ログで AS2 メッセージのステータスを確認することもできます。

AS2 コネクターの詳細を表示するには、AS2 コネクターの詳細を表示を参照してください。AS2 コネクターの作成についての詳細は、AS2 コネクタを設定する を参照してください。

ファイル名と場所

このセクションでは、AS2 転送のファイル命名規則について説明します。

インバウンドファイル転送については、次の点に注意してください。

• 基本ディレクトリは契約書で指定します。ベースディレクトリは、Amazon S3 バケット名にプレフィックス (ある場合) を組み合わせたものです。例えば /DOC-EXAMPLE-BUCKET/AS2-folder です。

• 受信ファイルが正常に処理されると、ファイル (および対応する JSON ファイル) が /processed フォルダに保存されます。例えば /DOC-EXAMPLE-BUCKET/AS2-folder/processed です。

  JSONファイルには以下のフィールドが含まれる：

  • agreement-id

  • as2-from

  • as2-to

  • as2-message-id

  • transfer-id

  • client-ip

  • connector-id

  • failure-message

  • file-path

  • message-subject

  • mdn-message-id

  • mdn-subject

  • requester-file-name

  • requester-content-type

  • server-id

  • status-code

  • failure-code

  • transfer-size

• 受信ファイルを正常に処理できない場合、ファイル (および対応する JSON ファイル) は /failed フォルダーに保存されます。例えば /DOC-EXAMPLE-BUCKET/AS2-folder/failed です。

• 転送されたファイルは、original_filename.messageId.original_extension として processed フォルダーに保存されます。つまり、転送のメッセージ ID がファイル名の元の拡張子の前に追加されます。

• JSON ファイルは original_filename.messageId.original_extension.json として作成され、保存されます。追加されるメッセージ ID に加えて、文字列 .json は転送されたファイルの名前に追加されます。

• メッセージ処理通知 (MDN) ファイルが作成され、original_filename.messageId.original_extension.mdn という名前で保存されます。追加されるメッセージ ID に加えて、文字列 .mdn は転送されたファイルの名前に追加されます。

• ExampleFileInS3Payload.dat という名前の受信ファイルがある場合、次のファイルが作成されます。

  • File – [e-mail]

  • JSON – [e-mail]

  • MDN – [e-mail]

アウトバウンド転送の場合、名前は似ていますが、受信メッセージファイルがないことと、転送されたメッセージの転送 ID がファイル名に追加される点が異なります。転送 ID は StartFileTransfer API 操作によって (または別のプロセスまたはスクリプトがこの操作を呼び出したときに) 返されます。

• transfer-id はファイル転送に関連付けられる識別子です。StartFileTransfer コールの一部であるすべてのリクエストは transfer-id を共有します。

• ベースディレクトリは、ソースファイルに使用するパスと同じです。つまり、ベースディレクトリは StartFileTransfer API オペレーションまたはstart-file-transfer AWS CLI コマンドで指定するパスです。例:

  aws transfer start-file-transfer --send-file-paths /DOC-EXAMPLE-BUCKET/AS2-folder/file-to-send.txt

  このコマンドを実行すると、MDN ファイルと JSON ファイルは /DOC-EXAMPLE-BUCKET/AS2-folder/processed (転送が成功した場合) または /DOC-EXAMPLE-BUCKET/AS2-folder/failed (転送に失敗した場合) に保存されます。

• JSON ファイルは original_filename.transferId.messageId.original_extension.json として作成され、保存されます。

• MDN ファイルは original_filename.transferId.messageId.original_extension.mdn として作成され、保存されます。

• ExampleFileOutTestOutboundSyncMdn.dat という名前のアウトバウンドファイルがある場合、次のファイルが作成されます。

  • JSON – ExampleFileOutTestOutboundSyncMdn.dedf4601-[e-mail]

  • MDN – ExampleFileOutTestOutboundSyncMdn.dedf4601-[e-mail]

また、 CloudWatch ログを確認して、失敗した転送の詳細を表示することもできます。

ステータスコード

次の表に、ユーザーまたはパートナーが AS2 メッセージを送信したときに CloudWatch ログに記録できるすべてのステータスコードを示します。異なるメッセージ処理ステップは、異なるメッセージタイプに適用され、モニタリングのみを目的としています。COMPLETED 状態と FAILED 状態は処理の最終ステップを表し、JSON ファイルに表示されます。

コード	説明	処理が完了しましたか？
処理	メッセージは最終形式に変換中です。例えば、解凍ステップと復号ステップの両方にこのステータスがあります。	なし
MDN_TRANSMIT	メッセージ処理が MDN レスポンスを送信しています。	なし
MDN_RECEIVE	メッセージ処理が MDN レスポンスを受信しています。	なし
COMPLETED	メッセージ処理が正常に完了しました。この状態には、インバウンドメッセージまたはアウトバウンドメッセージの MDN 検証に MDN が送信されるときが含まれます。	あり
FAILED	メッセージ処理が失敗しました。エラーコードのリストについては、「」を参照してくださいAS2 エラーコード。	あり

JSON ファイルの例

このセクションには、転送が成功した場合と失敗した転送のサンプルファイルなど、インバウンドとアウトバウンドの両方の転送のサンプル JSON ファイルが表示されます。

正常に転送されたアウトバウンドファイルの例:

{
  "requester-content-type": "application/octet-stream",
  "message-subject": "File xyzTest from MyCompany_OID to partner YourCompany",
  "requester-file-name": "TestOutboundSyncMdn-9lmCr79hV.dat",
  "as2-from": "MyCompany_OID",
  "connector-id": "c-c21c63ceaaf34d99b",
  "status-code": "COMPLETED",
  "disposition": "automatic-action/MDN-sent-automatically; processed",
  "transfer-size": 3198,
  "mdn-message-id": "OPENAS2-11072022063009+0000-df865189-1450-435b-9b8d-d8bc0cee97fd@PartnerA_OID_MyCompany_OID",
  "mdn-subject": "Message be18db8-7361-42ff-8ab6-49ec1e435f34@c9c705f0baaaabaa has been accepted",
  "as2-to": "PartnerA_OID",
  "transfer-id": "dedf4601-4e90-4043-b16b-579af35e0d83",
  "file-path": "/DOC-EXAMPLE-BUCKET/as2testcell0000/openAs2/TestOutboundSyncMdn-9lmCr79hV.dat",
  "as2-message-id": "fbe18db8-7361-42ff-8ab6-49ec1e435f34@c9c705f0baaaabaa",
  "timestamp": "2022-07-11T06:30:10.791274Z"
}

転送に失敗したアウトバウンドファイルの例:

{
  "failure-code": "HTTP_ERROR_RESPONSE_FROM_PARTNER",
  "status-code": "FAILED",
  "requester-content-type": "application/octet-stream",
  "subject": "Test run from Id da86e74d6e57464aae1a55b8596bad0a to partner 9f8474d7714e476e8a46ce8c93a48c6c",
  "transfer-size": 3198,
  "requester-file-name": "openAs2TestOutboundWrongAs2Ids-necco-3VYn5n8wE.dat",
  "as2-message-id": "9a9cc9ab-7893-4cb6-992a-5ed8b90775ff@718de4cec1374598",
  "failure-message": "http://Test123456789.us-east-1.elb.amazonaws.com:10080 returned status 500 for message with ID 9a9cc9ab-7893-4cb6-992a-5ed8b90775ff@718de4cec1374598",
  "transfer-id": "07bd3e07-a652-4cc6-9412-73ffdb97ab92",
  "connector-id": "c-056e15cc851f4b2e9",
  "file-path": "/DOC-EXAMPLE-BUCKET-4c1tq6ohjt9y/as2IntegCell0002/openAs2/openAs2TestOutboundWrongAs2Ids-necco-3VYn5n8wE.dat",
  "timestamp": "2022-07-11T21:17:24.802378Z"
}

正常に転送された受信ファイルの例:

{
  "requester-content-type": "application/EDI-X12",
  "subject": "File openAs2TestInboundAsyncMdn-necco-5Ab6bTfCO.dat sent from MyCompany to PartnerA",
  "client-ip": "10.0.109.105",
  "requester-file-name": "openAs2TestInboundAsyncMdn-necco-5Ab6bTfCO.dat",
  "as2-from": "MyCompany_OID",
  "status-code": "COMPLETED",
  "disposition": "automatic-action/MDN-sent-automatically; processed",
  "transfer-size": 1050,
  "mdn-subject": "Message Disposition Notification",
  "as2-message-id": "OPENAS2-11072022233606+0000-5dab0452-0ca1-4f9b-b622-fba84effff3c@MyCompany_OID_PartnerA_OID",
  "as2-to": "PartnerA_OID",
  "agreement-id": "a-f5c5cbea5f7741988",
  "file-path": "processed/openAs2TestInboundAsyncMdn-necco-5Ab6bTfCO.OPENAS2-11072022233606+0000-5dab0452-0ca1-4f9b-b622-fba84effff3c@MyCompany_OID_PartnerA_OID.dat",
  "server-id": "s-5f7422b04c2447ef9",
  "timestamp": "2022-07-11T23:36:36.105030Z"
}

転送に失敗した受信ファイルの例:

{
  "failure-code": "INVALID_REQUEST",
  "status-code": "FAILED",
  "subject": "Sending a request from InboundHttpClientTests",
  "client-ip": "10.0.117.27",
  "as2-message-id": "testFailedLogs-TestRunConfig-Default-inbound-direct-integ-0c97ee55-af56-4988-b7b4-a3e0576f8f9c@necco",
  "as2-to": "0beff6af56c548f28b0e78841dce44f9",
  "failure-message": "Unsupported date format: 2022/123/456T",
  "agreement-id": "a-0ceec8ca0a3348d6a",
  "as2-from": "ab91a398aed0422d9dd1362710213880",
  "file-path": "failed/01187f15-523c-43ac-9fd6-51b5ad2b08f3.testFailedLogs-TestRunConfig-Default-inbound-direct-integ-0c97ee55-af56-4988-b7b4-a3e0576f8f9c@necco",
  "server-id": "s-0582af12e44540b9b",
  "timestamp": "2022-07-11T06:30:03.662939Z"
}