Configuration d'AS2

Accords — Les accords bilatéraux entre partenaires commerciaux, ou partenariats, définissent la relation entre les deux parties qui échangent des messages (fichiers). Pour définir un accord, Transfer Family combine les informations du serveur, du profil local, du profil du partenaire et du certificat. Transfer Family AS2-inbound traite les accords d'utilisation.

Certificats — Les certificats à clé publique (X.509) sont utilisés dans les communications AS2 pour le chiffrement et la vérification des messages. Les certificats sont également utilisés pour les points de terminaison des connecteurs.

Profils locaux et profils de partenaires — Un profil local définit l'organisation ou le « groupe » local (AS2-enabledTransfer Family server). De même, un profil de partenaire définit l'organisation partenaire distante, externe à Transfer Family.

Chiffrement — Obligatoire (pour le transport HTTP, qui est la seule méthode de transport actuellement prise en charge). Les messages non chiffrés ne sont acceptés que s'ils sont transférés par un TLS-terminating proxy tel qu'un Application Load Balancer (ALB) et que X-Forwarded-Proto: https l'en-tête est présent.

Signature — Facultatif

Compression — Facultative (le seul algorithme de compression actuellement pris en charge est ZLIB)

Avis de disposition des messages (MDN) — Facultatif

AES128_CBC

AES192_CBC

AES256_CBC

3DES (pour la rétrocompatibilité uniquement)

Signature entrante et MDN — SHA1, SHA256, SHA384, SHA512

Signature sortante et MDN — SHA1, SHA256, SHA384, SHA512

Transferts entrants : synchrones et asynchrones

Transferts sortants : synchrones et asynchrones

Protocole de transfert de courrier simple (SMTP) (e-mail MDN) — Non pris en charge

Transferts entrants : le protocole HTTP est le seul transport actuellement pris en charge, et vous devez le spécifier explicitement.

Transferts sortants : si vous fournissez une URL HTTP, vous devez également spécifier un algorithme de chiffrement. Si vous fournissez une URL HTTPS, vous avez la possibilité de spécifier NONE pour votre algorithme de chiffrement.

Server-side Le protocole TCP keep-alive n'est pas pris en charge. La connexion expire après 350 secondes d'inactivité, sauf si le client envoie des paquets de maintien en vie.

Pour qu'un accord actif soit accepté par le service et apparaisse dans les CloudWatch journaux Amazon, les messages doivent contenir des en-têtes AS2 valides.

Le serveur qui reçoit les messages de AWS Transfer Family for AS2 doit prendre en charge l'attribut de protection de l'algorithme CMS (Cryptographic Message Syntax) pour valider les signatures des messages, tel que défini dans la RFC 6211. Cet attribut n'est pas pris en charge dans certains anciens produits IBM Sterling.

Les identifiants de message dupliqués donnent lieu à un message processed/Warning: document dupliqué.

La longueur de clé pour les certificats AS2 doit être d'au moins 2 048 bits et d'au plus 4 096 bits.

Lorsque vous envoyez des messages AS2 ou des mDNS asynchrones au point de terminaison HTTPS d'un partenaire commercial, les messages ou mDNS doivent utiliser un certificat SSL valide signé par une autorité de certification (CA) reconnue publiquement. Self-signed les certificats sont actuellement pris en charge uniquement pour les transferts sortants.

Le point de terminaison doit prendre en charge le protocole TLS version 1.2 et un algorithme cryptographique autorisé par la politique de sécurité (comme décrit dansPolitiques de sécurité pour les AWS Transfer Family serveurs).

Les pièces jointes multiples et les messages d'échange de certificats (CEM) de la version 1.2 d'AS2 ne sont actuellement pas pris en charge.

L'authentification de base est actuellement prise en charge uniquement pour les messages sortants.

Vous pouvez associer un flux de traitement de fichiers à un serveur Transfer Family qui utilise le protocole AS2. Toutefois, les messages AS2 n'exécutent pas les flux de travail attachés au serveur.