FAQ sur l'AWS Transfer Family

Oui. Vous pouvez configurer votre serveur Transfer Family de sorte à afficher les bannières personnalisées, telles les politiques ou les conditions générales d'organisation, à vos utilisateurs. Vous pouvez également afficher des messages du jour (MOTD) personnalisés aux utilisateurs qui se sont authentifiés avec succès. Pour en savoir plus, consultez la documentation.

Oui. Le service fournit un nom de domaine par défaut permettant d'accéder à votre point de terminaison. Si vous disposez déjà d'un nom de domaine, vous pouvez utiliser Amazon Route 53 ou tout service DNS pour acheminer le trafic de vos utilisateurs depuis votre domaine enregistré vers le point de terminaison de serveur dans AWS. Consultez la documentation sur la façon dont AWS Transfer Family utilise Amazon Route 53 pour les noms de domaine personnalisés (uniquement applicables aux points de terminaison accessibles sur Internet).

Oui. Lorsque vous créez un serveur ou que vous mettez à jour un serveur existant, vous pouvez spécifier si vous voulez que le point de terminaison soit accessible sur l'Internet public ou hébergé dans votre VPC. L'utilisation d'un point de terminaison hébergé dans un VPC pour votre serveur vous permet de restreindre son accès uniquement aux clients du même VPC, à d'autres VPC que vous spécifiez ou dans des environnements sur site utilisant des technologies de mise en réseau qui étendent votre VPC, par exemple AWS Direct Connect, AWS VPN ou l'appairage VPC. Vous pouvez restreindre plus encore l'accès aux ressources dans des sous-réseaux spécifiques au sein de votre VPC avec des listes de contrôle d'accès réseau (NACL) de sous-réseaux ou des groupes de sécurité. Pour plus d'informations, consultez la documentation sur la création du point de terminaison de votre serveur au sein de votre VPC à l'aide d'AWS PrivateLink.

Non, lorsque vous activez le protocole FTP, vous ne pourrez utiliser que l’option d’accès interne du point de terminaison hébergé dans le VPC, car le protocole FTP transmet les données en clair. Si le trafic doit transiter par le réseau public, vous devrez utiliser des protocoles sécurisés tels que SFTP ou FTPS.

Non. Un VPC est requis pour héberger les points de terminaison du serveur FTP. Veuillez consulter la documentation sur les modèles CloudFormation visant à automatiser la création de ressources VPC pour héberger le point de terminaison lors de la création du serveur.

Oui. Vous pouvez activer des adresses IP fixes pour le point de terminaison de votre serveur en sélectionnant le point de terminaison hébergé dans un VPC pour votre serveur et l'option d'accès via Internet. Ainsi, vous pouvez attacher des adresses IP Elastic (notamment des adresses BYO IP) directement au point de terminaison qui est assigné en tant qu'adresse IP du point de terminaison. Consultez la section sur la création d'un point de terminaison accessible sur Internet dans la documentation intitulée Création du point de terminaison de votre serveur au sein de votre VPC.

Oui. Vous avez trois options pour limiter le trafic entrant via les adresses IP sources des utilisateurs finaux. Si vous hébergez votre point de terminaison de serveur au sein du VPC, consultez cet article de blog sur l'utilisation de groupes de sécurité pour autoriser le listage de l'adresse IP source, ou utilisez le service AWS Network Firewall. Si vous utilisez un serveur public EndpointType Transfer et API Gateway pour intégrer votre système de gestion des identités, vous pouvez également utiliser AWS WAF pour autoriser ou bloquer l'accès, ou le limiter en fonction du débit, par l'adresse IP source de vos utilisateurs finaux.

Oui. Vous pouvez déployer le point de terminaison de votre serveur avec des environnements VPC utilisés généralement lors de la segmentation de votre environnement AWS à l'aide d'outils comme AWS Landing Zone pour la sécurité, la surveillance des coûts et la scalabilité. Reportez-vous à cet article de blog sur l'utilisation des points de terminaison hébergés VPC dans des environnements VPC partagés avec AWS Transfer Family.

Vous pouvez utiliser AWS Global Accelerator avec votre point de terminaison de serveur Transfer pour améliorer le débit du transfert des fichiers et le temps d'aller-retour. Pour plus d'informations, lisez cet article de blog.

Oui. Selon vos exigences en matière de sécurité et de conformité, vous pouvez sélectionner l'une de nos politiques de sécurité gérées par service disponibles afin de contrôler les algorithmes cryptographiques qui seront publiés par les points de terminaison de votre serveur. Lorsque les clients de transfert de fichiers de vos utilisateurs finaux tentent de se connecter à votre serveur, seuls les algorithmes spécifiés dans la politique peuvent être utilisés pour la connexion. Consultez la documentation sur les politiques de sécurité prédéfinies.

Oui. AWS Transfer Family prend en charge l'échange à clé publique post-quantique pour les transferts de fichiers SFTP. Vous pouvez associer l'une des politiques de sécurité PQ hybrides prédéfinies à votre serveur SFTP pour permettre un échange de clés post-quantique sécurisé avec des clients prenant en charge les algorithmes de chiffrement PQ.

Non. Les adresses IP fixes généralement utilisées à des fins de liste blanche de pare-feu ne sont actuellement pas prises en charge par le type de points de terminaison PUBLIC. Utilisez des points de terminaison hébergés dans un VPC pour attribuer des adresses IP statiques pour votre point de terminaison.

Si vous utilisez le type de point de terminaison PUBLIC, vos utilisateurs doivent autoriser le listage des plages d'adresses IP AWS publiées ici. Reportez-vous à la documentation pour plus d'informations sur les plages d'adresses IP AWS.

Non. La clé d'hôte du serveur qui est attribuée lorsque vous créez le serveur ne change pas, à moins que vous n'ajoutiez une nouvelle clé d'hôte et supprimiez manuellement la clé originale.

Les types de clés RSA, ED25519 et ECDSA sont pris en charge pour les clés d'hôtes du serveur SFTP.

Oui. Vous pouvez importer une clé d'hôte lors de la création d'un serveur ou importer plusieurs clés d'hôtes lors de la mise à jour d'un serveur. Veuillez consulter la documentation sur la gestion des clés d'hôtes pour votre serveur compatible SFTP.

Oui. La plus ancienne clé d'hôte pour chaque type de clés peut être utilisé pour vérifier l'authenticité d'un serveur SFTP. En ajoutant les clés d'hôtes RSA, ED25519 et ECDSA, 3 clés d'hôtes distinctes peuvent être utilisées pour identifier votre serveur SFTP.

La plus ancienne clé d'hôte pour chaque type de clés est utilisée pour vérifier l'authenticité de votre serveur SFTP.

Oui. Vous pouvez effectuer une rotation de vos clés d'hôtes du serveur SFTP à tout moment en ajoutant ou en retirant des clés d'hôtes. Veuillez consulter la documentation sur la gestion des clés d'hôtes pour votre serveur compatible SFTP.

Si vous activez l'accès FTPS, vous devrez fournir un certificat d'Amazon Certificate Manager (ACM). Ce certificat est utilisé par les clients de vos utilisateurs finaux pour vérifier l'identité de votre serveur FTPS. Consultez la documentation ACM concernant la demande de nouveaux certificats ou l'importation de certificats existants dans ACM.

Nous ne prenons en charge que le mode passif, qui permet aux clients de vos utilisateurs finaux d'initier des connexions avec votre serveur. Le mode passif nécessite moins d'ouvertures de ports côté client, rendant le point de terminaison de votre serveur plus compatible avec les utilisateurs finaux derrière les pare-feu protégés.

Nous prenons uniquement en charge le mode FTPS explicite.

Oui. Les transferts de fichiers traversant un pare-feu ou un routeur sont pris en charge par défaut à l'aide du mode EPSV (Extended Passive Connection Mode). Si vous utilisez un client FTPS/FTP qui ne prend pas en charge le mode EPSV, consultez cet article de blog pour configurer votre serveur en mode PASV afin d'étendre la compatibilité de votre serveur à une large gamme de clients.

Oui. Outre le port 22 standard, AWS Transfer Family prend également en charge les ports alternatifs 2222 et 22000. Par défaut, le port 22 est configuré par défaut pour vos serveurs SFTP. Pour renforcer la sécurité de votre serveur, vous pouvez configurer le trafic SSH pour utiliser le port 22, le port 2222 ou les deux. Consultez notre documentation en cliquant ici.

Vous pouvez authentifier les connexions aux serveurs distants en utilisant des paires de clés SSH ou un mot de passe, ou les deux, selon les exigences du serveur distant. Pour en savoir plus sur le stockage et la gestion des informations d’authentification de votre connecteur dans votre compte AWS Secrets Manager, consultez la documentation. 

Vous pouvez transférer des fichiers vers ou depuis Amazon S3 vers des serveurs SFTP distants à l'aide de connecteurs SFTP.

Nous prenons en charge les algorithmes de clés d’hôtes RSA et ECDSA. Pour plus de détails sur les types de clés pris en charge, consultez la documentation ici.  

Le connecteur utilise l’empreinte de l'hôte pour valider l’identité du serveur distant. Si l'empreinte digitale fournie par le serveur distant ne correspond pas à celle téléchargée dans la configuration du connecteur, la connexion échouera et les détails de l'erreur seront journalisés dans CloudWatch. Pour en savoir plus sur la façon de charger la partie publique de la clé SSH d’un serveur distant à des fins d’identification, consultez la documentation sur les connecteurs SFTP ici.

Oui. Vous pouvez provisionner vos compartiments Amazon S3 et les ressources de votre connecteur SFTP dans différents comptes AWS.

Oui. Selon vos exigences en matière de sécurité et de compatibilité, vous pouvez sélectionner l’une de nos politiques de sécurité gérées par service disponibles afin de contrôler les algorithmes cryptographiques qui seront publiés par votre connecteur SFTP. Lorsque votre connecteur tente de se connecter au serveur distant, seuls les algorithmes spécifiés dans la politique attachée à votre connecteur seront utilisés pour la connexion. Consultez la documentation sur les politiques de sécurité prédéfinies.

Oui. Vous pouvez créer un connecteur SFTP dans un compte AWS et l’utiliser pour transférer des fichiers depuis un autre compte en fournissant les autorisations d’accès appropriées dans le rôle IAM associé à votre connecteur.

Vous pouvez tester la connectivité au serveur distant à l’aide de la console de gestion AWS ou de la commande TestConnection de l’API, de la CLI ou du CDK. Nous vous recommandons de tester la connectivité au serveur distant dès que vous créez votre connecteur pour vous assurer qu'il est correctement configuré. Assurez-vous que les adresses IP statiques associées à vos connecteurs sont autorisées par le serveur distant si nécessaire. Pour en savoir plus, consultez la documentation relative aux connecteurs SFTP.

Les connecteurs SFTP peuvent être utilisés pour envoyer des fichiers depuis Amazon S3 vers un serveur SFTP distant, récupérer des fichiers depuis un serveur SFTP distant vers Amazon S3 et répertorier les fichiers stockés dans un répertoire sur un serveur SFTP distant. Pour en savoir plus sur l’utilisation des connecteurs SFTP, consultez la documentation sur les connecteurs SFTP.

Vous pouvez répertorier les fichiers stockés dans un répertoire sur des serveurs SFTP distants en utilisant l’opération API StartDirectoryListing des connecteurs SFTP. Vous pourrez ensuite récupérer les fichiers cibles depuis le serveur distant en transmettant les noms de fichiers de la liste lorsque vous utilisez l’opération API StartFileTransfer pour transférer des fichiers. Pour plus d’informations, consultez l’exemple de solution permettant de synchroniser de nouveaux fichiers à partir de serveurs SFTP distants, ou participez à l’atelier sur les flux de travail MFT que vous pouvez suivre à votre rythme.

Vous pouvez dresser la liste de tous les fichiers d’un répertoire sur un serveur SFTP distant à l’aide de connecteurs SFTP, et créer une logique personnalisée pour filtrer la liste des fichiers en fonction de vos critères génériques pour les modèles de noms de fichiers. Vous pouvez ensuite utiliser l’opération d’API StartFileTransfer pour transférer ces fichiers à l’aide de connecteurs SFTP.

Vous pouvez surveiller l’état actuel de vos opérations de transfert de fichiers à l’aide de la commande d’API ListFileTransferResults. En outre, afin de vous aider à gérer la lignée des données, les connecteurs SFTP émettent des journaux détaillés dans Amazon CloudWatch incluant notamment l’état de vos transferts de fichiers, le type d’opération (envoi ou récupération), l’horodatage, le chemin de fichier et, le cas échéant, la description des erreurs. 

Oui. Vous pouvez planifier des transferts de fichiers à l'aide du planificateur Amazon EventBridge. Créez un calendrier qui répond aux besoins de votre entreprise à l’aide du planificateur d’EventBridge et spécifiez l’API StartFileTransfer ou l’API StartDirectoryListing d’AWS Transfer Family comme cible universelle de votre calendrier.

Oui. AWS Step Functions s'intègre à divers services AWS, notamment AWS Transfer Family, ce qui vous permet d'invoquer l'action StartFileTransfer du connecteur SFTP directement à partir de votre machine d'état. Une fois que vous avez créé votre connecteur SFTP avec AWS Transfer Family, tirez parti des intégrations du SDK AWS de Step Functions pour appeler l'API StartFileTransfer. Pour en savoir plus sur l’orchestration de vos flux de travail de transfert et de traitement de fichiers à l’aide d’AWS Step Functions et de connecteurs SFTP, participez à l’atelier sur les flux de travail MFT orientés événements que vous pouvez suivre à votre rythme.

Oui. Chaque opération de transfert de fichiers utilisant des connecteurs SFTP publie une notification d’événement dans votre bus d’événements par défaut dans Amazon EventBridge. Vous pouvez vous abonner aux événements du connecteur SFTP et les utiliser pour orchestrer le traitement piloté par événement de vos fichiers transférés à l’aide d’Amazon EventBridge ou de tout autre service d’orchestration de flux de travail de votre choix qui s’intègre à ces événements.

Oui. Les adresses IP statiques sont associées à vos connecteurs par défaut et peuvent être utilisées pour autoriser les connexions sur le pare-feu de votre partenaire commercial. Vous pouvez identifier les adresses IP statiques associées aux connecteurs de votre compte en accédant à la page des détails du connecteur dans la console AWS Transfer Family, ou en utilisant la commande DescribeConnector API/CLI/CDK.

Oui. Tous les connecteurs SFTP d’une région de compte AWS partageront un ensemble d’adresses IP statiques. Le partage d’adresses IP entre des connecteurs d’un type donné réduit la quantité de documentation relative à la liste d’autorisation ainsi que les communications d’intégration nécessaires avec vos partenaires externes.

Non. Actuellement, les connecteurs SFTP ne peuvent être utilisés que pour se connecter à des serveurs qui offrent un point de terminaison accessible à Internet. Si vous devez vous connecter à des serveurs uniquement accessibles via un réseau privé, veuillez nous en informer via AWS Support ou par l'intermédiaire de l'équipe chargée de votre compte AWS.

Oui. Lors de la configuration, vous pouvez sélectionner le ou les protocoles de votre choix pour permettre aux clients de se connecter à votre point de terminaison. Le nom d'hôte du serveur, l'adresse IP et le fournisseur d'identité sont partagés entre les protocoles sélectionnés. De même, vous pouvez activer la prise en charge de protocoles supplémentaires pour les points de terminaison AWS Transfer Family existants, à condition que la configuration du point de terminaison réponde aux conditions de tous les protocoles que vous avez l’intention d’utiliser.

Lorsque vous devez utiliser FTP (uniquement pris en charge pour l'accès dans un VPC) et que vous devez également prendre en charge Internet pour SFTP, AS2 ou FTPS, vous avez besoin d'un point de terminaison de serveur distinct pour FTP. Vous pouvez utiliser le même point de terminaison pour plusieurs protocoles lorsque vous souhaitez utiliser le même nom d’hôte et la même adresse IP de point de terminaison pour les clients qui se connectent par le biais de plusieurs protocoles. De plus, si vous souhaitez partager les mêmes informations d'identification pour SFTP et FTPS, vous pouvez configurer et utiliser un fournisseur d'identité unique pour l'authentification des clients qui se connectent sur l'un ou l'autre protocole.

Oui. Vous pouvez fournir au même utilisateur l'accès sur plusieurs protocoles, à condition que les informations d'identification propres au protocole aient été configurées au sein de votre fournisseur d'identité. Si vous avez activé FTP, nous vous recommandons de maintenir des informations d'identification distinctes pour FTP. Veuillez consulter la documentation relative à la configuration d'informations d'identification distinctes pour FTP.

Contrairement à SFTP et FTPS, FTP transmet les informations d'identification en texte en clair. Nous vous recommandons d'isoler les informations d'identification FTP de celles relatives à SFTP et FTPS, car en cas de partage ou d'exposition accidentels des informations d'identification FTP, vos charges de travail utilisant SFTP ou FTPS restent protégées.

Oui. Vous pouvez déployer cette solution open source qui vous permet de fournir une interface basée sur un navigateur à l'aide de vos points de terminaison SFTP d'AWS Transfer Family.

Le service prend en charge trois options de fournisseur d'identité, à savoir l'option gérée par le service, dans laquelle vous stockez les identités des utilisateurs au sein du service, Microsoft Active Directory et les fournisseurs d'identité personnalisés, qui vous permettent d'intégrer un fournisseur d'identité de votre choix. L'authentification gérée par le service prend uniquement en charge les points de terminaison de serveur qui sont activés pour SFTP.

Vous pouvez utiliser l'authentification gérée par le service pour authentifier vos utilisateurs SFTP à l'aide des clés SSH.

Vous pouvez charger jusqu'à 10 clés SSH par utilisateur. Les clés RSA, ED25519 et ECDSA sont pris en charge.

Oui. Consultez la documentation pour savoir comment configurer la rotation des clés pour vos utilisateurs SFTP.

Lorsque vous créez votre serveur, vous sélectionnez un répertoire dans AWS Managed Microsoft AD, votre environnement sur site, ou AD autogéré dans Amazon EC2 en tant que fournisseur d'identité. Vous devrez ensuite spécifier les groupes AD que vous souhaitez autoriser à accéder à l'aide d'un identifiant de sécurité (SID). Une fois que vous avez associé votre groupe AD à des informations de contrôle d'accès comme un rôle IAM, une stratégie de réduction de la portée (uniquement S3), un profile POSIX (uniquement EFS), un emplacement de répertoire de base et des mappages de répertoires logiques, les membres du groupe peuvent utiliser leurs informations d'identification AD pour s'authentifier et transférer des fichiers via les protocoles activés (SFTP, FTPS, FTP). 

Lorsque vous configurez vos utilisateurs, vous fournissez une stratégie de réduction de la portée qui est évaluée au moment de l'exécution sur la base d'informations relatives à vos utilisateurs, telles que leur nom d'utilisateur. Vous pouvez utiliser la même stratégie de réduction de la portée pour tous vos utilisateurs afin de leur donner accès à des préfixes uniques dans votre compartiment en fonction de leur nom d'utilisateur. De plus, un nom d'utilisateur peut également être utilisé pour évaluer les mappages de répertoires logiques en fournissant un modèle standardisé sur la manière dont le contenu de votre compartiment S3 ou de vos systèmes de fichiers EFS est rendu visible à votre utilisateur. Pour plus d'informations, consultez la documentation sur l’autorisation d'accès aux groupes AD.

Oui. Vous pouvez utiliser Microsoft AD pour authentifier les utilisateurs concernant l'accès via SFTP, FTPS et FTP.

Oui. Vous pouvez révoquer l'accès au transfert de fichiers pour des groupes AD particuliers. Une fois révoqués, les membres des groupes AD ne pourront plus transférer de fichiers en utilisant leurs informations d'identification AD.

Le mode personnalisé (authentification « BYO ») vous permet de tirer parti d'un fournisseur d'identité existant pour gérer vos utilisateurs finaux pour tous les types de protocoles (SFTP, FTPS et FTP), ce qui permet une migration facile et fluide de vos utilisateurs. Les informations d'identification peuvent être stockées dans le répertoire de votre entreprise ou dans un entrepôt de données d'identités interne, et vous pouvez les intégrer à des fins d'authentification des utilisateurs finaux. Les fournisseurs d'identité incluent Okta, Microsoft AzureAD ou tout fournisseur d'identité personnalisé que vous pouvez utiliser dans le cadre d'un portail d'allocation global.

Pour intégrer votre fournisseur d'identité à un serveur AWS Transfer Family, vous pouvez utiliser une fonction AWS Lambda ou un point de terminaison Amazon API Gateway. Utilisez Amazon API Gateway si vous avez besoin d'une API RESTful pour vous connecter à un fournisseur d'identité, ou bien si vous souhaitez utiliser AWS WAF pour ses fonctionnalités de restriction géographique et de limitation de vitesse. Consultez la documentation pour en savoir plus sur l'intégration de fournisseurs d'identité courants tels qu'AWS Cognito, Okta et AWS Secrets Manager.

Oui. L'adresse IP source du client est transmise à votre fournisseur d'identité lorsque vous utilisez AWS Lambda ou API Gateway pour établir une connexion avec un fournisseur d'identité personnalisé. Cela vous permet d'autoriser, de refuser ou de limiter l'accès en fonction des adresses IP des clients. Ce processus permettra de garantir que vos données sont accessibles uniquement à partir d'adresses IP que vous avez spécifiées comme étant de confiance.

Oui. Vous avez la possibilité d'appliquer plusieurs méthodes d'authentification afin de fournir une couche de sécurité supplémentaire lors de l'accès à vos données via SFTP. Votre serveur SFTP peut être configuré pour exiger à la fois un mot de passe et une clé SSH, un mot de passe ou une clé SSH, uniquement un mot de passe, ou simplement une clé SSH. Veuillez consulter la documentation pour savoir comment activer les méthodes d'authentification multiples à l'aide de votre fournisseur d'identité client.

Non, le stockage des mots de passe dans le service à des fins d'authentification n'est pas pris en charge pour le moment. Si vous avez besoin d'une authentification par mot de passe, utilisez Active Directory en sélectionnant un répertoire dans AWS Directory Service, ou suivez l'architecture décrite dans ce blog sur l'activation de l'authentification par mot de passe à l'aide de Secrets Manager.

Non. Les utilisateurs anonymes ne sont actuellement pris en charge pour aucun des protocoles.

Non, nous prenons en charge uniquement le paramétrage de l'accès par groupes AD.

Non, la prise en charge d’AWS Transfer Family pour Microsoft AD ne peut être utilisée que pour l'authentification par mot de passe. Pour combiner des modes d'authentification, utilisez l’option Custom Authorizer.

Oui. La prise en charge d’AWS Transfer Family pour AS2 a reçu le sceau de certification officiel du Drummond Group AS2 Cloud. Les fonctionnalités AS2 d'AWS Transfer Family ont été minutieusement contrôlées en termes de sécurité et de compatibilité d'échange de messages avec quatorze autres solutions AS2 tierces. Consultez notre annonce pour en savoir plus.

Votre partenaire commercial est identifié de façon unique grâce à son identifiant AS2 (ID AS2). De la même manière, votre partenaire commercial identifie vos messages grâce à votre identifiant AS2.

Vous pouvez utiliser la prise en charge existante d'AWS Transfer Family pour Amazon S3, les fonctionnalités réseau (points de terminaison d'un VPC, groupes de sécurité et adresses IP Elastic) et les contrôles d'accès (AWS IAM) pour AS2, comme vous le feriez pour SFTP, FTPS et FTP. L'authentification des utilisateurs, les répertoires logiques, les bannières personnalisées et Amazon EFS en tant que back-end de stockage ne sont pas pris en charge par AS2.

La non-répudiation, propre à AS2, vérifie que les messages sont échangés correctement entre deux parties. La non-répudiation dans AS2 est réalisée à l'aide de Message Disposition Notifications (MDN). Lorsqu'une notification MDN est demandée dans une transaction,elle garantit que l'expéditeur a envoyé le message, que le récepteur l'a bien reçu et que le message envoyé par l'expéditeur était le même que celui reçu par le destinataire.

La transmission des messages comporte deux aspects : l’un provenant de l'expéditeur et l’autre du destinataire. Une fois que l'expéditeur a déterminé le message à envoyer, celui-ci est signé (à l'aide de sa clé privée), chiffré (à l'aide du certificat du destinataire) et l'intégrité du message est calculée à l'aide d'un hachage. Ce message signé et chiffré est transmis au destinataire dans le réseau. Une fois le message reçu, il est déchiffré (à l'aide de la clé privée du destinataire), validé (à l'aide de la clé publique de l'expéditeur), puis traité et, si nécessaire, une notification Message Disposition Notifications (MDN) signée est envoyée à l'expéditeur pour accuser réception du message. Reportez-vous à la documentation sur la gestion de la transmission des messages par AS2.

La combinaison des options possibles est dictée par l'expéditeur. Ce dernier peut choisir de chiffrer les données uniquement ou de les signer uniquement (ou les deux), et de demander une notification Message Disposition Notifications (MDN). Si l'expéditeur choisit de demander une notification MDN, il peut demander qu'elle soit signée ou non. Le destinataire est tenu de respecter ces deux options.

Oui. L'expéditeur peut choisir de demander une notification MDN, de demander une notification MDN signée ou non signée, et sélectionner les algorithmes de signature qui doivent être utilisés pour la signer.

Actuellement, nous prenons en charge les réponses MDN synchrones et asynchrones. Cela vous permet de répondre à vos partenaires commerciaux avec un MDN synchrone ou asynchrone après la réception d'un message AS2. Comme les notifications MDN synchrones sont envoyées sur le même canal de connexion que le message, elles sont beaucoup plus simples et constituent donc l'option recommandée. Si vous avez besoin de plus de temps pour traiter le message avant d'envoyer une notification MDN, les notifications MDN asynchrones sont préférables. Si vous avez besoin de demander et de recevoir des MDN asynchrones lorsque vous envoyez des messages à vos partenaires commerciaux, contactez-nous par l'intermédiaire d'AWS Support ou de votre gestionnaire de compte.

AWS Transfer Family extrait les informations principales AS2 du contenu et des MDN échangées et les stocke dans des fichiers JSON dans votre compartiment Amazon S3. Vous pouvez interroger ces fichiers JSON à l'aide de S3 Select ou Amazon Athena, ou indexer les fichiers à l'aide d'Amazon OpenSearch ou Amazon DocumentDB pour l'analyse.

Oui. Dès que vous recevez une notification MDN de votre partenaire commercial, le service la valide à l'aide de votre certificat et stocke le message dans votre compartiment Amazon S3. Vous pouvez choisir d'archiver le message en utilisant des politiques S3 Lifecycle.

Une fois que vos données sont prêtes à être livrées, vous devez invoquer l'API StartFileTransfer à l'aide du connecteur AS2 qui contient les informations du serveur AS2 du destinataire. Ainsi, le service peut envoyer le message au serveur de votre partenaire commercial. Reportez-vous à la documentation sur les connecteurs pour envoyer des messages à votre partenaire commercial sur AS2.

Oui. Lorsque vous configurez le profil de votre partenaire commercial, vous pouvez utiliser des dossiers différents pour chacun d'eux.

Oui. Vous pouvez importer les clés et les certificats existants de votre partenaire et gérer les renouvellements et les rotations. Reportez-vous à la documentation sur l'importation des certificats.

En utilisant la console AWS Transfer Family, vous pouvez afficher un tableau de bord des certificats triés en fonction de leur date d'expiration. En outre, vous pouvez choisir de recevoir des notifications avant l'expiration des certificats, ce qui vous donne suffisamment de temps pour les renouveler et d'éviter ainsi toute interruption des opérations.

Oui. Les adresses IP statiques sont associées à vos connecteurs par défaut et peuvent être utilisées pour autoriser les connexions sur le serveur AS2 de votre partenaire commercial. Vous pouvez identifier les adresses IP statiques associées aux connecteurs de votre compte en accédant à la page des détails du connecteur dans la console AWS Transfer Family, ou en utilisant la commande DescribeConnector API/CLI/CDK.

Oui. Nous vous permettons de vous connecter au serveur AS2 de votre partenaire commercial en utilisant l’authentification de base. Reportez-vous à la documentation sur la configuration de l’authentification de base sur des connecteurs AS2.

Oui. Vos connecteurs AS2 utilisent désormais des adresses IP statiques pour envoyer des messages à des serveurs AS2 distants et pour renvoyer des réponses de notification de disposition des messages (MDN, Message Disposition Notification) asynchrones. Vous pouvez identifier les adresses IP statiques associées à vos connecteurs en accédant aux pages de détails du connecteur ou du serveur dans la console de gestion AWS Transfer Family, ou en utilisant les commandes DescribeConnector ou DescribeServer de l’API, de la CLI ou du CDK.

Oui. Les points de terminaison de votre serveur AS2 prennent en charge la configuration des contrôles de liste d’adresses IP autorisées en utilisant des groupes de sécurité avec des points de terminaison hébergés par VPC et connectés à Internet.

Oui. Vos réponses MDN asynchrones AS2 utiliseront des adresses IP statiques. Vous pouvez identifier les adresses IP statiques utilisées pour envoyer vos réponses MDN asynchrones en accédant à la page des détails du serveur dans la console de gestion AWS Transfer Family ou en utilisant la commande DescribeServer API/CLI/CDK.

Chaque message AS2 reçu publie un événement sur votre bus d’événements par défaut dans Amazon EventBridge. Vous pouvez vous abonner à ces événements et les utiliser pour orchestrer le traitement piloté par événement des messages reçus à l’aide d’Amazon EventBridge ou de tout autre service d’orchestration de flux de travail. Par exemple, vous pouvez utiliser ces événements pour copier les messages entrants vers d’autres emplacements dans S3, analyser le contenu des messages à l’aide d’une fonction Lambda personnalisée ou baliser les messages en fonction de leur contenu afin qu’ils puissent être indexés et recherchés par des services tels qu’Amazon CloudSearch.

Oui. Vous pouvez transformer automatiquement le contenu EDI X12 de vos messages AS2 entrants en représentations de données courantes telles que JSON et XML à l’aide d’AWS B2B Data Interchange. Pour ce faire, créez une règle Amazon EventBridge qui correspond au modèle d’événement de l’événement AS2 Payload Receive Completed d’AWS Transfer Family et spécifiez l’API StartTransformerJob d’AWS B2B Data Interchange comme cible universelle pour la règle. En transformant le contenu EDI X12 de vos messages AS2 entrants avec AWS B2B Data Interchange, vous pouvez automatiser et accélérer l’intégration de vos données EDI dans les applications et systèmes métier en aval.

Vous pouvez automatiser l’envoi de messages AS2 en les planifiant avec le Planificateur Amazon EventBridge ou en les déclenchant à l’aide des règles Amazon EventBridge. Pour créer des flux de travail automatisés et planifiés dans le temps pour l’envoi de messages AS2, créez une planification qui répond aux besoins de votre entreprise à l’aide du planificateur EventBridge et spécifiez l’API StartFileTransfer d’AWS Transfer Family comme cible universelle pour votre planification. Pour créer des flux de travail automatisés et pilotés par événement pour l’envoi de messages AS2, créez une règle Amazon EventBridge qui correspond aux événements publiés sur EventBridge et spécifiez l’API StartFileTransfer d’AWS Transfer Family comme cible universelle pour votre règle.

Oui. Chaque message AS2 et MDN envoyé publie un événement sur votre bus d’événements par défaut dans Amazon EventBridge. Vous pouvez vous abonner à ces événements et les utiliser pour supprimer ou archiver les messages AS2 et MDN envoyés avec succès à votre partenaire commercial.

Oui. AWS Transfer Family publie des événements sur Amazon EventBridge pour chaque message AS2 ou MDN envoyé et reçu, avec succès ou non. Ces événements sont publiés sur votre bus d’événements par défaut dans Amazon EventBridge où ils peuvent être utilisés pour déclencher des notifications par e-mail à votre intention ou à celle de vos partenaires à l’aide de services tels qu’Amazon SNS.

Non. Actuellement, les flux de travail gérés ne sont pas pris en charge pour vos points de terminaison AS2. Nous vous recommandons d’utiliser les notifications d’événements de Transfer Family publiées sur Amazon EventBridge pour orchestrer le traitement de vos messages AS2. Pour plus de détails, consultez la section Automatisation du traitement des fichiers.

Non. AWS Transfer Family ne fournit pas de prise en charge pour AS3 ou AS4 pour le moment.

Deux options s’offrent à vous : 1) AWS Transfer Family publie des notifications d’événements de transfert de fichiers dans Amazon EventBridge pour les fichiers transférés via SFTP, AS2, FTPS et FTP, et vous pouvez utiliser ces événements pour déclencher le traitement de vos fichiers à l’aide de n’importe quel service pouvant s’intégrer aux événements EventBridge, et 2) AWS Transfer Family fournit des flux de travail gérés pour vous permettre d’exécuter plus facilement le traitement postchargement des fichiers chargés via les points de terminaison de serveur SFTP, FTPS et FTP à l’aide d’étapes de traitement de fichiers prédéfinies. Lorsque vous associez un flux de travail géré à votre point de terminaison de serveur, tous les fichiers chargés via ce point de terminaison sont traités selon les mêmes étapes de flux de travail.

AWS Transfer Family publie des notifications d’événements dans Amazon EventBridge en cas de réussite ou d’échec de chaque opération de transfert de fichiers, à la fois pour les ressources du serveur et du connecteur. Pour plus d’informations sur les événements Transfer Family publiés sur Amazon EventBridge, consultez la documentation. 

Si vous avez besoin de traiter les fichiers que vous échangez avec vos partenaires commerciaux, vous devez configurer une infrastructure pour exécuter du code personnalisé, surveiller continuellement afin de détecter les erreurs et anomalies d'exécution et garantir que toutes les modifications et transformations de données sont auditées et journalisées. Par ailleurs, vous devez tenir compte des scénarios d'erreurs, tant techniques que métier, tout en veillant à ce que les modes de sécurité soient correctement déclenchés. Si vous avez des exigences en termes de traçabilité, vous devez tracer la lignée des données au fil de leur évolution dans les différents composants de votre système. Maintenir des composants distincts d'un flux de traitement des fichiers accapare le temps dédié aux tâches différentiées auxquelles vous devriez vous consacrer dans le cadre de votre activité. Les flux gérés simplifient la gestion de plusieurs tâches, et fournissent une solution standardisée de traitement des fichiers qui peut être reproduite au sein de votre organisation. Cette solution est dotée d'un système intégré de gestion d'exceptions et d'une fonction de traçabilité des fichiers pour chaque étape, afin de vous aider à répondre à vos exigences métier et juridiques.

Les flux gérés d’AWS Transfer Family fournissent un cadre prédéfini qui vous permet de créer, d’exécuter et de surveiller une séquence linéaire d’étapes pour le traitement des fichiers chargés via les points de terminaison SFTP, FTPS et FTP. Grâce à cette fonctionnalité, vous pouvez gagner du temps grâce à des étapes prédéfinies pour exécuter des tâches de traitement de fichiers courantes telles que la copie, le balisage et le déchiffrement de fichiers. Vous pouvez également personnaliser le traitement des fichiers à l’aide d’une fonction Lambda pour des tâches telles que l’analyse des fichiers à la recherche de PII, de virus ou de programmes malveillants ou d’autres erreurs telles que le format ou le type de fichier incorrect, ce qui vous permet de détecter rapidement les anomalies et de répondre à vos exigences de conformité. Lorsque vous associez un flux de travail géré à votre point de terminaison de serveur, tous les fichiers chargés via ce point de terminaison sont traités selon les mêmes étapes de flux de travail.

Les flux de travail gérés vous permettent de prétraiter facilement les données avant qu’elles ne soient consommées par vos applications en aval en exécutant une séquence linéaire de tâches de traitement des fichiers pour tous les fichiers chargés sur vos points de terminaison de serveur, telles que le déplacement des fichiers chargés vers des dossiers spécifiques à l’utilisateur, le déchiffrement des fichiers à l’aide de clés PGP, l’analyse des programmes malveillants et le balisage. Vous pouvez déployer des flux à l'aide de l'infrastructure en tant que code (IaC), ce qui vous permet de répliquer et de standardiser rapidement les tâches courantes de traitement de fichiers post-chargement qui couvrent plusieurs unités commerciales au sein de votre organisation. Vous pouvez exercer un contrôle granulaire en associant à votre point de terminaison de serveur un flux de travail de travail géré qui n’est déclenché que pour les fichiers entièrement chargés, et en associant un flux de travail géré distinct qui n’est déclenché que pour les fichiers partiellement chargés afin de traiter les chargements incomplets. Les flux de travail intègrent également une gestion des exceptions qui vous permet de réagir facilement aux résultats du traitement des fichiers en cas d’erreurs ou d’exceptions dans l’exécution du flux de travail, ce qui vous aide à respecter vos SLA techniques et métier. Chaque étape du traitement des fichiers de votre flux de travail produit également des journaux détaillés, qui peuvent être audités pour suivre le lignage des données.

Les points de terminaison et connecteurs de serveur d’AWS Transfer Family publient automatiquement des notifications d’événements dans Amazon EventBridge lorsqu’une opération de transfert de fichiers est terminée, ainsi que des informations opérationnelles telles que l’emplacement du fichier, le nom d’utilisateur de l’expéditeur, l’identifiant du serveur ou du connecteur, l’état du transfert, etc. Vous pouvez utiliser ces événements lorsque vous avez besoin d’un contrôle granulaire pour définir le traitement des fichiers, par exemple en utilisant une logique conditionnelle basée sur la source du fichier, ou lorsque vous devez créer des architectures basées sur les événements pour les intégrer à d’autres services AWS, à des applications tierces et à vos propres applications. D’autre part, les flux de travail gérés d’AWS Transfer Family fournissent un cadre prédéfini pour définir une séquence linéaire d’étapes courantes de traitement des fichiers qui sont appliquées à tous les fichiers chargés via vos points de terminaison de serveur SFTP, FTPS et FTP. Vous pouvez associer un flux de travail géré à votre point de terminaison lorsque tous les fichiers chargés doivent être traités selon les mêmes étapes courantes de traitement des fichiers, sans qu’il soit nécessaire d’appliquer une logique granulaire ou conditionnelle.

Pour commencer, configurez votre flux pour contenir des opérations comme la copie, l'étiquetage ainsi qu'une série d'actions pouvant inclure votre propre étape personnalisée dans une séquence d'étapes adaptée à vos exigences. Ensuite, mappez le flux à un serveur, de sorte qu'à l'arrivée du fichier, les actions spécifiées dans ce flux soient évaluées et déclenchées en temps réel. Pour en savoir plus, consultez la documentation, regardez cette démo sur comment démarrer avec les flux gérés ou déployez une plateforme de transfert de fichiers native cloud en vous référant à cet article de blog.

Oui. Le même flux de travail peut être attribué à plusieurs serveurs, de manière à ce que vous puissiez facilement gérer et standardiser les configurations.

Oui. Vous pouvez configurer une étape de flux afin de traiter soit le fichier initialement chargé soit le fichier de sortie provenant de l'étape de flux précédente. Cela vous permet d'automatiser facilement le déplacement et le renommage de vos fichiers après leur chargement dans Amazon S3. Par exemple, pour déplacer un fichier vers un autre emplacement à des fins d'archivage ou de conservation, configurez deux étapes de votre flux. La première étape consiste à copier le fichier vers un emplacement Amazon S3 différent, et la seconde à supprimer le fichier initialement chargé. Lisez la documentation pour en savoir plus sur la sélection d'un emplacement de fichiers pour les étapes de flux.

Les actions courantes suivantes sont disponibles une fois que le serveur de transfert a reçu un fichier du client :

Déchiffrement d'un fichier à l'aide des clés PGP. Consultez cet article de blog sur le chiffrement et le déchiffrement de fichiers à l'aide de PGP.

Déplacer ou copier des données de l'emplacement d'arrivée à celui d'utilisation.

Supprimer le fichier original après archivage ou copie vers un nouvel emplacement.

Étiqueter le fichier en fonction de son contenu, de façon qu'il puisse être indexé et recherché par les services en aval (S3 uniquement)

Toute logique personnalisée de traitement de fichiers en incorporant votre propre fonction Lambda en tant qu'étape personnalisée à votre flux de travail. Par exemple, la vérification de la compatibilité du type de fichier, l'analyse des fichiers pour détecter les logiciels malveillants, la détection des données d’identification personnelle (PII) et l'extraction des métadonnées avant l'ingestion des fichiers dans votre analyse de données.

Oui. Vous pouvez utiliser une étape de flux de travail prédéfinie et entièrement gérée pour le déchiffrement PGP des fichiers chargés via vos points de terminaison de serveurs SFTP, FTPS et FTP. Pour en savoir plus, consultez la documentation sur les flux de travail gérés et cet article de blog sur le chiffrement et le déchiffrement de fichiers à l’aide de PGP.

Vous pouvez configurer une étape du flux de travail pour traiter soit le fichier initialement chargé sur votre point de terminaison de serveur, soit le fichier de sortie de l’étape précédente du flux de travail. Cela vous permet d'automatiser facilement le déplacement et le renommage de vos fichiers après leur chargement dans Amazon S3. Par exemple, pour déplacer un fichier vers un autre emplacement à des fins d'archivage ou de conservation, configurez deux étapes de votre flux. La première étape consiste à copier le fichier vers un emplacement Amazon S3 différent, et la seconde à supprimer le fichier initialement chargé. Lisez la documentation pour en savoir plus sur la sélection d’un emplacement de fichiers pour les étapes de flux de travail.

Oui. Avec les flux de travail gérés, vous pouvez créer plusieurs copies du fichier d’origine tout en préservant ce dernier à des fins de conservation d’enregistrements.

Oui. Vous pouvez utiliser le nom d'utilisateur comme une variable dans les étapes de copie de flux, ce qui vous permet d'acheminer dynamiquement les fichiers vers des dossiers spécifiques à l'utilisateur dans Amazon S3. Cette démarche élimine la nécessité de coder en dur l'emplacement de destination du dossier lors de la copie de fichiers, et automatise la création de dossiers spécifiques à l'utilisateur dans Amazon S3, vous permettant ainsi de mettre à l'échelle vos flux d'automatisation du traitement de fichiers. Consultez la documentation pour en savoir plus.

AWS Step Functions est un service d'orchestration sans serveur qui vous permet de combiner AWS Lambda à d'autres services afin de définir l'exécution des applications métier en étapes simples. Pour exécuter des étapes de traitement de fichiers à l'aide d'AWS Step Functions, vous devez utiliser les fonctions AWS Lambda avec les déclencheurs d'événements Amazon S3 afin d'assembler vos propres flux de travail. Les flux de travail gérés fournissent un cadre qui permet d'orchestrer facilement une séquence linéaire de traitement et qui se distingue des solutions existantes à plusieurs titres : 1) vous pouvez définir de manière précise des flux de travail à exécuter uniquement sur des chargements de fichiers complets, ainsi que des flux de travail à exécuter uniquement sur des chargements de fichiers partiels ; 2) les flux de travail peuvent être déclenchés automatiquement pour S3 et EFS (ce qui ne génère pas d'événements post-chargement) ; 3) les flux de travail offrent des options intégrées et sans code pour le traitement courant des fichiers comme le déchiffrement PGP, et 4) les clients peuvent obtenir une visibilité de bout en bout sur leurs transferts de fichiers et traitements dans CloudWatch Logs.

Veuillez consulter la section Surveillance pour obtenir plus de détails sur les fonctionnalités prises en charge pour la journalisation de l’activité de vos flux de travail gérés.

Oui. Veuillez consulter cet article de blog sur l’utilisation des flux de travail gérés pour les notifications de livraison de fichiers.

Oui. Vous pouvez définir des flux de travail distincts à déclencher lors des chargements complets de fichiers et des chargements partiels de fichiers.

Non. Le traitement peut être invoqué uniquement à l'arrivée du fichier, à l'aide du point de terminaison entrant.

Actuellement, les flux de travail gérés ne peuvent être déclenchés que pour les fichiers chargés via vos points de terminaison de serveurs SFTP, FTPS et FTP et ne peuvent traiter qu’un seul fichier par exécution. Les flux de travail gérés ne sont pas pris en charge pour les messages échangés via AS2, pour les téléchargements de fichiers via vos points de terminaison de serveur et pour les fichiers transférés via des connecteurs SFTP.

Non. Pour le moment, les flux traitent un fichier par exécution.

Non. Les flux de travail gérés ne peuvent pas être invoqués de manière granulaire, par utilisateur. Vous pouvez définir une logique de traitement conditionnel des fichiers en fonction de l’utilisateur qui a chargé le fichier à l’aide des notifications d’événements de transfert de fichiers publiées sur Amazon EventBridge.

Le transfert de données entre les serveurs AWS Transfer Family et Amazon S3 s'effectue sur les réseaux internes d'AWS et ne passe pas par l'Internet public. De ce fait, vous n'avez pas besoin d'utiliser AWS PrivateLink pour les données transférées du serveur AWS Transfer Family vers Amazon S3. Le service Transfer Family n'a pas besoin des points de terminaison AWS PrivateLink pour Amazon S3 afin d'empêcher le trafic de passer par l'Internet, et ne peut donc pas les utiliser pour communiquer avec les services de stockage. Tous ces points supposent que le service de stockage AWS et le serveur Transfer Family se trouvent dans la même région.

AWS IAM est utilisé pour déterminer le niveau d'accès que vous souhaitez fournir à vos utilisateurs. Cela inclut les opérations que vous souhaitez activer sur leur client et les compartiments Amazon S3 auxquels ils ont accès, qu'il s'agisse de la totalité ou d'une partie du compartiment.

Le répertoire de base que vous avez configuré pour votre utilisateur détermine son répertoire de connexion. Il s'agit du chemin de répertoire que le client de votre utilisateur utilisera dès qu'il aura été authentifié avec succès dans le serveur. Vous devez vous assurer que le rôle IAM fourni donne à l'utilisateur l'accès au répertoire de base.

Oui. Vous pouvez assigner un rôle IAM unique pour tous vos utilisateurs et utiliser des mappages logiques de répertoire qui spécifient les chemins absolus de compartiment Amazon S3 que vous souhaitez rendre visibles pour vos utilisateurs finaux et comment vous souhaitez que ces chemins leur soient présentés par leurs clients. Consultez l'article de blog sur la simplification de la structure AWS SFTP/FTPS/FTP avec les répertoires Chroot et logique.

Les fichiers transférés via les protocoles pris en charge sont stockés en tant qu'objets dans votre compartiment Amazon S3. Un mappage un à un entre les fichiers et les objets permet un accès natif à ces objets à l'aide des services AWS pour le traitement ou l'analyse.

Une fois l'authentification réussie, le service présente les objets et les dossiers Amazon S3 sous forme de fichiers et de répertoires aux applications de transfert de vos utilisateurs, en fonction des informations d'identification de vos utilisateurs.

Les commandes courantes permettant de créer, lire, mettre à jour et supprimer des fichiers et des répertoires sont prises en charge. Les fichiers sont stockés en tant qu'objets individuels dans votre compartiment Amazon S3. Les répertoires sont gérés sous la forme d'objets de dossier dans S3, en utilisant la même syntaxe que la console S3.

Les opérations de changement de nom de répertoire, les opérations d'ajout, la modification des droits de propriété, des autorisations et des horodatages, ainsi que l'utilisation de liens symboliques et en dur ne sont pas prises en charge pour le moment.

Oui. Vous pouvez activer et désactiver les opérations de fichiers à l'aide du rôle AWS IAM que vous avez mappé à leur nom d'utilisateur. Consultez la documentation sur la création de politiques et de rôles IAM pour contrôler l'accès de vos utilisateurs finaux

Oui. Les compartiments auxquels votre utilisateur peut accéder sont déterminés par le rôle IAM AWS et les conditions générales à portée descendante en option que vous lui attribuez. Vous ne pouvez utiliser qu'un seul compartiment comme répertoire de base pour l'utilisateur.

Oui. Vous pouvez utiliser des alias de points d'accès S3 avec AWS Transfer Family afin de fournir un accès granulaire à un grand ensemble de données sans avoir à gérer la moindre politique de compartiment. Les alias de points d'accès S3 combinés aux répertoires logiques d'AWS Transfer Family vous permettent de créer un contrôle d'accès précis pour différents services, applications et équipes, tout en réduisant les frais généraux de gestion des stratégies de compartiment. Pour en savoir plus et démarrer, consultez l'article de blog sur l'amélioration du contrôle d'accès aux données avec AWS Transfer Family et les points d'accès Amazon S3.

Oui. Vous pouvez utiliser l'interface de ligne de commande et l'API pour configurer l'accès croisé aux comptes entre votre serveur et les compartiments que vous voulez utiliser pour stocker les fichiers transférés via les protocoles pris en charge. Le menu déroulant Console n'affichera que les compartiments du compte A. De plus, vous devrez vérifier que le rôle attribué à l'utilisateur appartient bien au compte A.

Oui. AWS Transfer Family publie des notifications d’événements dans Amazon EventBridge à la fin d’une opération de transfert de fichiers, et vous pouvez utiliser ces événements pour automatiser le traitement postchargement de vos fichiers. Sinon, lorsque tous vos fichiers chargés doivent être traités selon les mêmes étapes de traitement des fichiers sans aucune logique conditionnelle, vous pouvez utiliser les flux de travail gérés d’AWS Transfer Family pour définir une séquence linéaire d’étapes courantes de traitement de fichiers qui sont automatiquement invoquées pour chaque fichier que vos utilisateurs chargent via vos points de terminaison de serveur SFTP, FTPS ou FTP.

Oui. Lorsque votre utilisateur télécharge un fichier, le nom d'utilisateur et l'identifiant de serveur du serveur utilisé pour le téléchargement est stocké comme partie intégrante des métadonnées de l'objet S3 associé. Reportez-vous à la documentation sur les informations que vous utilisez pour le traitement postchargement. Les informations relatives à l’utilisateur final sont également disponibles dans la notification d’événement de chargement automatique de fichiers publiée par AWS Transfer Family sur Amazon EventBridge. Vous pouvez utiliser ces informations pour orchestrer le traitement granulaire après le chargement de vos fichiers en fonction de l’utilisateur. 

Amazon S3 peut publier des notifications d’événements pour tout nouvel objet créé dans votre compartiment. D’autre part, AWS Transfer Family publie des notifications d’événements en cas de réussite ou d’échec de chaque opération de transfert de fichiers. Elle se distingue des notifications d’événements Amazon S3 de la manière suivante : 1) vous pouvez avoir un contrôle précis sur la définition du traitement postchargement pour les chargements complets de fichiers par rapport aux chargements partiels de fichiers lorsque vous utilisez les notifications d’événements de Transfer Family, 2) les événements Transfer Family sont publiés pour les chargements de fichiers à la fois dans S3 et EFS, et 3) les événements générés par Transfer Family contiennent des informations opérationnelles telles que le nom d’utilisateur de l’expéditeur, l’identifiant du serveur, l’état du transfert, etc., et vous permettent de définir le traitement des fichiers de manière granulaire, en fonction d’une logique conditionnelle sur ces attributs.

Oui. Vous pouvez optimiser votre référencement dans le répertoire S3 afin de permettre à vos utilisateurs finaux de bénéficier d'un référencement rapide de leur répertoire - passant de quelques minutes à quelques secondes. Si vous créez un nouveau serveur via la console après le 17/11/2023, la liste optimisée des répertoires S3 sera activée par défaut si vous utilisez Amazon S3 comme espace de stockage. Cela peut être activé ou désactivé à tout moment. La désactivation de cette fonctionnalité rétablit les performances par défaut de votre liste de répertoires S3. Si vous utilisez CloudFormation, CLI ou API pour créer un serveur, la liste optimisée des répertoires S3 est désactivée par défaut, mais peut être activée à tout moment. Reportez-vous à la section documentation pour savoir comment activer la liste optimisée des répertoires S3.

Bien que tout dépende de votre utilisation des stratégies de session et d'autres exigences internes, vous n'avez généralement pas besoin d'utiliser à la fois des stratégies de session et des répertoires logiques pour vous assurer que vos utilisateurs n'accèdent qu'aux fichiers auxquels vous voulez qu'ils accèdent. Les mappages de répertoires logiques permettent uniquement aux utilisateurs d'accéder aux chemins logiques et aux sous-répertoires qu'ils ont désignés, et interdisent les chemins relatifs qui traversent les racines logiques. Nous validons chaque chemin à l'aide d'une notation relative qui peut inclure des éléments relatifs et nous bloquons activement la résolution de ces chemins avant de les transmettre à S3 afin d'empêcher vos utilisateurs de dépasser leurs mappages logiques. 

Avant de configurer AWS Transfer Family pour un fonctionnement avec le système de fichiers Amazon EFS, vous devrez configurer la propriété des fichiers et des dossiers à l'aide des mêmes identités POSIX (identifiant utilisateur/identifiant de groupe) que vous prévoyez d'attribuer à vos utilisateurs AWS Transfer Family. Par ailleurs, si vous accédez aux systèmes de fichiers à partir d'un compte différent, les politiques de ressources doivent également être configurées sur votre système de fichiers afin d'autoriser l'accès entre comptes. Reportez-vous à cet article de blog pour obtenir des instructions étape par étape sur l'utilisation d'AWS Transfer Family avec EFS.

Le transfert de données entre les serveurs AWS Transfer Family et Amazon EFS s'effectue sur les réseaux internes d'AWS et ne passe pas par l'Internet public. En conséquence, vous n'avez pas besoin d'utiliser AWS PrivateLink pour les données transférées du serveur AWS Transfer Family vers Amazon EFS. Le service Transfer Family n'a pas besoin des points de terminaison AWS PrivateLink pour Amazon EFS afin d'empêcher le trafic de passer par l'Internet et, ne peut donc pas les utiliser pour communiquer avec les services de stockage. Tous ces points supposent que le service de stockage AWS et le serveur Transfer Family se trouvent dans la même région.

Pour contrôler l'accès à un système de fichiers, Amazon EFS utilise des identifiants POSIX, composés d'un identifiant utilisateur de système d'exploitation, d'un identifiant de groupe et d'un identifiant de groupe secondaire. Lors de la configuration de votre utilisateur dans la console/CLI/API d'AWS Transfer Family, vous devrez spécifier le nom d'utilisateur, la configuration POSIX de l'utilisateur et le rôle IAM pour accéder au système de fichiers EFS. Vous devrez aussi spécifier un identifiant de système de fichiers EFS et, si vous le souhaitez, un répertoire au sein de ce système de fichiers, qui servira de répertoire d'arrivée pour l'utilisateur. Lorsque l'utilisateur AWS Transfer Family s'authentifie avec succès à l'aide de son client de transfert de fichiers, il se trouvera directement dans le répertoire de départ spécifié, ou à la racine du système de fichiers EFS spécifié. Son identifiant POSIX de système d'exploitation sera appliqué à toutes les requêtes effectuées via son client de transfert de fichiers. En tant qu'administrateur EFS, vous devrez vous assurer que les fichiers et les répertoires auxquels vous souhaitez que vos utilisateurs AWS Transfer Family accèdent sont associés à leurs identifiants POSIX correspondants dans votre système de fichiers EFS. Consultez la documentation pour en savoir plus sur la configuration de la propriété des sous-répertoires dans EFS. Il convient de noter que Transfer Family ne prend pas en charge les points d'accès si vous utilisez Amazon EFS pour le stockage.  

Les fichiers transférés via les protocoles autorisés sont stockés directement dans vos systèmes de fichiers Amazon EFS et seront accessibles via une interface de système de fichiers standard ou à partir des services AWS qui peuvent accéder aux systèmes de fichiers Amazon EFS.

R : Les commandes SFTP/FTPS/FTP permettant de créer, lire, mettre à jour et supprimer des fichiers, des répertoires et des liens symboliques sont prises en charge. Reportez-vous au tableau ci-dessous pour découvrir les commandes prises en charge pour EFS et S3.

1. Seul le renommage de fichiers est pris en charge. Le renommage de répertoires ou le renommage de fichiers pour écraser des fichiers existants ne sont pas pris en charge.

2. Seuls les utilisateurs racine (c.-à-d. ceux dont l’uid=0) peuvent modifier la propriété et les autorisations de fichiers et de répertoires.

3. Prise en charge pour les utilisateurs racine (c.-à-d. uid=0) ou pour le propriétaire du fichier, qui peut uniquement modifier le groupe d’un fichier en choisissant un de ses groupes secondaires.

4. Prise en charge uniquement pour les dossiers non vides.

La politique IAM que vous fournissez pour l'utilisateur AWS Transfer Family détermine s'il bénéficie d'un accès racine, en lecture seule ou en lecture et écriture à votre système de fichiers. Par ailleurs, en tant qu'administrateur de système de fichiers, vous pouvez définir la propriété des fichiers et des répertoires et y accorder l'accès au sein de votre système de fichiers à l'aide d'identifiants utilisateur et d'identifiants de groupe. Cela s'applique aux utilisateurs stockés au sein du service (gérés par le service), mais aussi à ceux stockés au sein de votre système de gestion des identités (authentification « BYO »).

Oui. Lorsque vous configurez des utilisateurs, vous pouvez spécifier des systèmes de fichiers et des répertoires différents pour chacun d'entre eux. Lorsque l'authentification est réussie, EFS applique un répertoire pour chaque demande de système de fichiers effectuée à l'aide des protocoles activés.

Oui. Grâce aux mappages de répertoires logiques d'AWS Transfer Family, vous pouvez empêcher l'utilisateur final de voir les répertoires dans votre système de fichiers en mappant des chemins absolus aux noms de chemin visibles pour l'utilisateur final. Cela vous permet aussi d'effectuer un « chroot » de l'utilisateur vers le répertoire de départ que vous lui avez attribué.

Oui. Si des liens symboliques sont présents dans les répertoires accessibles à l'utilisateur et que ce dernier essaie d'y accéder, les liens seront résolus vers les cibles correspondantes. Les liens symboliques ne sont pas pris en charge lorsque vous utilisez le mappage de répertoire logique pour configurer l'accès des utilisateurs.

Oui. Lorsque vous configurez un utilisateur AWS Transfer Family, vous pouvez spécifier un ou plusieurs systèmes de fichiers dans la politique IAM que vous fournissez dans le cadre cette configuration afin de donner à l'utilisateur accès à plusieurs systèmes de fichiers.

Vous pouvez utiliser les clients et applications conçus pour Microsoft Windows, Linux, macOS ou tout autre système d'exploitation prenant en charge les protocoles SFTP/FTPS/FTP pour télécharger et accéder aux fichiers stockés dans vos systèmes de fichiers EFS. Configurez simplement le serveur et l'utilisateur avec les autorisations appropriées pour le système de fichiers EFS afin d'accéder au système de fichiers sur l'ensemble des systèmes d'exploitation.

Vous avez deux options : 1) AWS Transfer Family publie des notifications d’événements dans Amazon EventBridge à la fin d’une opération de transfert de fichiers, et vous pouvez utiliser ces événements pour automatiser le traitement après le chargement de vos fichiers, et 2) lorsque tous vos fichiers chargés doivent être traités selon les mêmes étapes de traitement des fichiers sans aucune logique conditionnelle, vous pouvez utiliser les flux de travail gérés d’AWS Transfer Family pour définir une séquence linéaire d’étapes de traitement de fichiers communes appliquées à chaque fichier chargé via vos points de terminaison de serveurs SFTP, FTPS ou FTP.

Pour les nouveaux fichiers, l'identifiant utilisateur POSIX associé à l'utilisateur transférant le fichier sera défini comme propriétaire du fichier dans votre système de fichiers EFS. Par ailleurs, avec Amazon CloudWatch, vous pouvez suivre les activités des utilisateurs relatives à la création, la mise à jour, la suppression et la lecture de fichiers. Consultez la documentation pour en savoir plus sur l’activation de la journalisation Amazon CloudWatch.

Oui. Avec la CLI et l'API, vous pouvez configurer l'accès entre comptes entre vos ressources AWS Transfer Family et vos systèmes de fichiers EFS. La console AWS Transfer Family ne répertoriera que les systèmes de fichiers dans le même compte. Par ailleurs, vous devrez vous assurer que le rôle IAM attribué à l'utilisateur pour accéder au système de fichiers appartient au compte A.

Si vous configurez un serveur AWS Transfer Family afin qu'il accède à un système de fichiers EFS pour lequel l'accès entre comptes n'est pas activé, l'accès des utilisateurs SFTP/FTP/FTPS au système de fichiers sera refusé. Si la journalisation CloudWatch est activée sur votre serveur, les erreurs d'accès entre comptes seront consignées dans CloudWatch Logs.

Non. AWS Transfer Family vous permet d'accéder uniquement aux systèmes de fichiers EFS situés dans la même région AWS.

Oui. Vous pouvez utiliser AWS Transfer pour écrire des fichiers vers EFS et configurer EFS Lifecycle Management pour faire migrer les fichiers qui n'ont pas été utilisés depuis un certain temps vers la classe de stockage avec accès peu fréquent.

Oui. Amazon EFS fournit une interface de système de fichiers, une sémantique d'accès de système de fichiers (par ex. : forte cohérence des données et verrouillage des fichiers) et un stockage auquel peuvent accéder simultanément des milliers de clients NFS/SFTP/FTPS/FTP.

Oui. L'accès à vos systèmes de fichiers EFS à l'aide de vos serveurs AWS Transfer Family consomme vos crédits de transmission en rafales EFS, quel que soit le mode de débit. Consultez la documentation sur les modes de performances et de débits disponibles et découvrez des conseils utiles en matière de performances.

Vous pouvez utiliser SFTP ou FTPS pour des transferts sécurisés sur les réseaux publics. Compte tenu de la sécurité sous-jacente des protocoles basés sur les algorithmes cryptographiques SSH et TLS, les données et les commandes sont transférées via un canal sécurisé et crypté.

Vous pouvez choisir de chiffrer les fichiers stockés dans votre compartiment à l'aide d'Amazon KMS (SSE-KMS) ou du chiffrement côté serveur d'Amazon S3 (SSE-S3). Pour le chiffrement au repos des fichiers stockés dans EFS, vous avez le choix entre une clé CMK gérée par AWS et une clé CMK gérée par le client. Consultez la documentation pour en savoir plus sur les options de chiffrement au repos des données et métadonnées de fichiers à l'aide d'Amazon EFS.

AWS Transfer Family est conforme à la norme PCI-DSS, au RGPD, au FedRAMP et aux SOC 1, 2 et 3. Le service est également éligible à l'HIPAA. Apprenez-en davantage sur les services concernés par les programmes de conformité.

Les régions AWS USA Est, USA Ouest et GovCloud (USA) sont conformes à la loi FISMA. Lorsque l'AWS Transfer Family est autorisée pour FedRAMP, elle sera conforme à la loi FISMA dans les régions concernées. L'autorisation FedRAMP pour ces deux régions pour FedRAMP Moderate et FedRAMP High démontre cette conformité. Cette conformité s’appuie sur des évaluations annuelles et la documentation des contrôles NIST SP 800-53 en vigueur dans nos plans de sécurité système. Des modèles sont disponibles sur Artifact avec notre matrice de responsabilité client (CRM) qui démontre, de manière détaillée, notre engagement à respecter ces contrôles NIST tel que l’exige FedRAMP. Artefact est disponible via la console de gestion, accessible par un compte AWS pour les régions USA Est, USA Ouest et GovCloud. Si vous avez d'autres questions sur ce sujet, veuillez consulter la console.

Tous les fichiers chargés via les services sont vérifiés en comparant le total de contrôle MD5 pré et post-chargement du fichier.

Vous pouvez utiliser les flux de travail gérés d’AWS Transfer Family pour déchiffrer automatiquement les fichiers à l’aide de clés PGP lorsqu’ils sont chargés sur vos points de terminaison de serveur SFTP, FTPS ou FTP d’AWS Transfer Family. Pour plus d'informations, consultez la documentation sur les flux de travail gérés. Vous pouvez également vous abonner aux notifications d’événements d’AWS Transfer Family publiées sur Amazon Eventbridge pour orchestrer le traitement granulaire et piloté par événement des fichiers transférés à l’aide de votre propre logique de chiffrement/déchiffrement.

Vous pouvez surveiller vos utilisateurs finaux et leurs activités de transfert de fichiers à l'aide de journaux au format JSON envoyés à Amazon CloudWatch. Dans CloudWatch, vous pouvez analyser et interroger vos journaux à l'aide de CloudWatch Log Insights, qui détecte automatiquement les champs au format JSON. Vous pouvez également suivre les principaux utilisateurs, le nombre total d'utilisateurs uniques et leur utilisation continue avec CloudWatch Contributor Insights. Nous fournissons également des métriques et des graphiques CloudWatch prédéfinis auxquels vous pouvez accéder dans la console de gestion AWS Transfer Family. Consultez la documentation pour en savoir plus.

Oui. Vous pouvez combiner les flux de journaux provenant de plusieurs serveurs AWS Transfer Family dans un seul groupe de journaux CloudWatch. Cela vous permet de créer des statistiques et des visualisations de journaux consolidées, qui peuvent être ajoutées aux tableaux de bord CloudWatch pour suivre l'utilisation et les performances des serveurs.

Les exécutions des flux de travail peuvent être surveillées à l’aide des métriques AWS CloudWatch, telles que le nombre total d’exécutions de flux de travail, d’exécutions ayant réussi et d’exécutions ayant échoué. Avec la console de gestion AWS, vous pouvez aussi rechercher et afficher en temps réel le statut de progression des exécutions de flux de travail en cours. Utilisez CloudWatch Logs pour obtenir une journalisation détaillée des exécutions de flux de travail.

AWS Transfer Family fournit des journaux au format JSON pour toutes les ressources (y compris les serveurs, les connecteurs et les flux de travail) et tous les protocoles, y compris SFTP, FTPS, FTP et AS2.

Vous pouvez utiliser les flux gérés de Transfer Family pour recevoir des notifications concernant les fichiers chargés sur les points de terminaison de vos serveurs SFTP, FTPS et FTP. Reportez-vous à cet article de blog. Vous pouvez également vous abonner aux événements d’AWS Transfer Family sur Amazon EventBridge pour recevoir des notifications via Amazon Simple Notification Service (SNS).

Oui. Si une vérification de validation d’un fichier échoue par rapport aux étapes de validation de flux de travail préconfigurés, vous pouvez utiliser le gestionnaire d’exception pour invoquer votre système de surveillance ou les membres de votre équipe par le biais d’une rubrique Amazon SNS.

Chaque protocole activé vous est facturé sur une base horaire, de l'heure de création et de configuration du point de terminaison de votre serveur jusqu'à l’heure de sa suppression. Vous êtes également facturé en fonction de la quantité de données téléchargées en amont et en aval via vos serveurs SFTP, FTPS ou FTP, du nombre de messages échangés via AS2 et de la quantité de données traitées à l'aide de l'étape du flux de travail Décryptage. Lorsque vous utilisez des connecteurs SFTP, la quantité de données transférées et le nombre d’appels de connecteur vous sont facturés. Reportez-vous à la page de tarification pour plus d’informations.

Non, vous êtes facturé à l'heure pour chacun des protocoles que vous avez activés et pour la quantité de données transférées via chacun des protocoles, et ce indépendamment du fait que vous ayez activé le même point de terminaison pour plusieurs protocoles ou que vous utilisiez différents points de terminaison pour chacun des protocoles.

Oui. Arrêter le serveur, à l'aide de la console ou en exécutant la commande CLI « stop-server », ou encore la commande API « StopServer », n'a aucune incidence sur la facturation. Vous êtes facturé sur une base horaire, de l'heure de création du point de terminaison de votre serveur et de configuration de l'accès audit point sur un ou plusieurs protocoles jusqu'à l'heure de sa suppression.

L'étape du flux de travail Déchiffrement vous est facturée en fonction de la quantité de données que vous décryptez à l'aide des clés PGP. Il n'y a pas d'autres frais supplémentaires pour l'utilisation des flux de travail gérés. Selon la configuration de votre flux de travail, vous êtes également facturé pour l'utilisation d'Amazon S3, Amazon EFS, AWS Secrets Manager et AWS Lambda.

Non, il n'y a pas de facturation horaire pour les connecteurs SFTP. Pour en savoir plus sur la tarification du connecteur SFTP, consultez la page de tarification.