Perguntas frequentes sobre o AWS Transfer Family

Sim. Você pode configurar o servidor do Transfer Family para exibir banners personalizados, como políticas da organização ou termos e condições para seus usuários. Você também pode exibir a Mensagem do Dia (MOTD) personalizada para usuários que se autenticaram com sucesso. Para saber mais, consulte a documentação.

Sim. O serviço fornece um nome de domínio por padrão para acessar seu endpoint. Caso já tenha um nome de domínio, você pode usar o Amazon Route 53 ou qualquer serviço de DNS para rotear o tráfego de usuários do domínio registrado para o endpoint do servidor na AWS. Consulte a documentação sobre como o AWS Transfer Family usa o Amazon Route 53 para nomes de domínio personalizados (somente para endpoints voltados para Internet aplicáveis).

Sim. Quando você cria um servidor ou atualiza um já existente, tem a opção de especificar se quer que o endpoint do servidor possa ser acessado pela Internet pública ou hospedado na VPC. Ao usar um VPC endpoint hospedado para o servidor, você pode restringir seu acesso a apenas os clientes dentro da mesma VPC, em outras VPCs que você especificar ou em ambientes locais usando tecnologias de rede que estendam a VPC, como o AWS Direct Connect, o AWS VPN ou o emparelhamento de VPC. Você pode restringir ainda mais o acesso aos recursos em sub-redes específicas que estão na VPC usando as listas de controle de acesso de rede (NACLs) da sub-rede ou os grupos de segurança. Para obter detalhes, consulte a documentação sobre como criar o endpoint do servidor dentro da sua VPC usando o AWS PrivateLink.

Não, ao habilitar o FTP, você só poderá usar a opção de acesso interno do endpoint hospedado em VPC devido ao fato de o FTP transmitir dados em texto não criptografado. Se o tráfego precisa atravessar a rede pública, você deve usar protocolos seguros como SFTP ou FTPS.

Não. A VPC é obrigatória para a hospedagem de endpoints de servidor de FTP. Consulte a documentação dos modelos do CloudFormation para automatizar a criação de recursos de VPC que hospedam o endpoint durante a criação do servidor.

Sim. Você ativar IPs fixos para o endpoint do servidor selecionando o VPC endpoint hospedado do servidor e escolhendo a opção voltada para a Internet. Isso permitirá que você associe IPs elásticos (incluindo IPs BYO) diretamente ao endpoint, que está atribuído como o endereço IP do endpoint. Consulte a seção da documentação sobre como criar um endpoint voltado para a Internet: Creating your server endpoint inside your VPC.

Sim. Você tem três opções para restringir o tráfego de entrada por endereço IP de origem dos usuários. Se você estiver hospedando seu endpoint de servidor dentro da VPC, consulte esta postagem no blog sobre a utilização de grupos de segurança para permitir listar endereço IP de origem ou usar o serviço AWS Network Firewall. Se você for um servidor EndpointType Transfer público e um API Gateway para integrar seu sistema de gerenciamento de identidade, também poderá usar o AWS WAF para permitir, bloquear ou classificar o acesso de limite ao endereço de IP de origem dos seus usuários finais.

Sim. Você pode implantar o endpoint do seu servidor com ambientes VPC compartilhados normalmente usados ao segmentar seu ambiente AWS usando ferramentas como o AWS Landing Zone para segurança, monitoramento de gastos e escalabilidade. Consulte esta postagem no blog sobre o uso de endpoints hospedados na VPC em ambientes da VPC compartilhados com o AWS Transfer Family.

Você pode usar o AWS Global Accelerator com o endpoint do servidor de transferência para melhorar o throughput de transferência de arquivos e o tempo de entrada e saída. Consulte esta postagem no blog para obter mais informações.

Sim. Com base em seus requisitos de segurança e conformidade, você pode selecionar uma de nossas políticas de segurança gerenciada por serviços disponíveis para controlar os algoritmos criptográficos que serão anunciados pelos endpoints do seu servidor. Quando os clientes de transferência de arquivos dos seus usuários finais tentarem se conectar ao seu servidor, somente os algoritmos especificados na política serão usados para negociar a conexão. Consulte a documentação sobre políticas de segurança predefinidas.

Sim. O AWS Transfer Family é compatível com a troca de chaves públicas com segurança quântica para transferências de arquivos do SFTP. Você pode associar uma das políticas de segurança PQ híbridas predefinidas ao seu servidor SFTP, permitindo a troca de chaves com segurança quântica com clientes compatíveis com algoritmos de criptografia PQ.

Não. No momento, os endereços IP fixos que geralmente são usados para listas de permissões de firewall não são aceitos no tipo de endpoint PUBLIC. Use endpoints hospedados na VPC para atribuir endereços IP estáticos para seu endpoint.

Se você estiver usando o tipo de endpoint PUBLIC, os usuários precisarão permitir os intervalos de endereços IP da AWS publicados aqui. Consulte a documentação para obter detalhes sobre como permanecer atualizado com relação aos intervalos de endereço IP da AWS.

Não. A chave de host do servidor atribuída no momento da criação do servidor continua sendo a mesma, a menos que você adicione uma nova chave de host e exclua manualmente a original.

Os tipos de chave RSA, ED25519 e ECDSA são aceitos para chaves de host de servidor de SFTP.

Sim. Você pode importar uma chave de host ao criar um servidor ou importar várias chaves de host ao atualizar um servidor. Consulte a documentação sobre gerenciamento de chaves de host para o seu servidor habilitado com SFTP.

Sim. A chave de host mais antiga de cada tipo de chave pode ser usada para verificar a autenticidade em um servidor de SFTP. Ao adicionar chaves de host RSA, ED25519 e ECDSA, três chaves de host separadas podem ser usadas para identificar seu servidor de SFTP.

A chave de host mais antiga de cada tipo de chave é usada para verificar a autenticidade de seu servidor de SFTP.

Sim. Você pode fazer a rotação suas chaves de host do servidor de SFTP a qualquer momento ao adicionar e remover chaves de host. Consulte a documentação sobre gerenciamento de chaves de host para o seu servidor habilitado com SFTP.

Ao habilitar o acesso do FTPS, você precisará fornecer um certificado do Amazon Certificate Manager (ACM). Esse certificado é usado pelos clientes dos usuários finais para verificar a identidade do servidor de FTPS. Consulte a documentação do ACM sobre como solicitar novos certificados ou importar certificados atuais para o ACM.

Somente oferecemos suporte ao modo passivo. Isso permite que os usuários finais iniciem conexões com o servidor. O modo passivo exige menos portas abertas do lado do cliente, o que torna o endpoint de servidor mais compatível com usuários finais atrás de firewalls protegidos.

Somente oferecemos suporte ao modo explícito do FTPS.

Sim. Transferências de arquivos através de um firewall ou roteador têm suporte por padrão usando o modo de conexão passiva estendida (EPSV). Se você estiver usando um cliente FTPS/FTP que não seja compatível com o modo EPSV, consulte esta postagem no blog para configurar seu servidor no modo PASV para expandir a compatibilidade do servidor para uma gama maior de clientes.

Sim. Além da porta padrão 22, o AWS Transfer Family também oferece suporte para a porta alternativa 2222 e 22000. Por padrão, a porta 22 é configurada por padrão para seus servidores SFTP. Para melhorar a segurança do seu servidor, você pode configurar o tráfego SSH para usar a porta 22, 2222 ou ambas. Consulte nossa documentação aqui.

Você pode autenticar conexões com servidores remotos usando pares de chaves SSH ou senha, ou ambos, dependendo dos requisitos do servidor remoto. Para saber mais sobre como armazenar e gerenciar as credenciais de autenticação do seu conector na sua conta do AWS Secrets Manager, acesse a documentação. 

Você pode transferir arquivos de ou para o Amazon S3 para servidores SFTP remotos usando conectores SFTP.

Oferecemos suporte aos algoritmos de chave de host RSA e ECDSA. Para obter mais detalhes sobre os tipos de chaves compatíveis, acesse a documentação aqui.  

O conector usa a impressão digital do host para validar a identidade do servidor remoto. Se a impressão digital fornecida pelo servidor remoto não corresponder à enviada para a configuração do conector, a conexão falhará e os detalhes do erro serão registrados em log no CloudWatch. Para saber mais sobre como carregar a parte pública da chave SSH de um servidor remoto para identificação, acesse a documentação dos conectores SFTP aqui.

Sim. Você pode provisionar seus buckets do Amazon S3 e recursos do conector SFTP em diferentes contas da AWS.

Sim. Com base em seus requisitos de segurança e compatibilidade, você pode selecionar uma de nossas políticas de segurança gerenciada por serviços disponíveis para controlar os algoritmos criptográficos que serão anunciados pelo seu conector SFTP. Quando seu conector tenta se conectar ao servidor remoto, somente os algoritmos especificados na política anexada ao seu conector serão usados para negociar a conexão. Consulte a documentação sobre políticas de segurança predefinidas.

Sim. Você pode criar um conector SFTP em uma conta da AWS e usá-lo para transferir arquivos de outra conta fornecendo as permissões de acesso apropriadas no perfil do IAM anexada ao seu conector.

Você pode testar a conectividade com o servidor remoto usando o Console de Gerenciamento da AWS ou o comando TestConnection da API/CLI/CDK. Recomendamos que você teste a conectividade com o servidor remoto assim que criar seu conector, para garantir que ele esteja configurado corretamente. Certifique-se de que os endereços IP estáticos associados aos seus conectores estejam listados como permitidos no servidor remoto, se necessário. Para saber mais, acesse a documentação dos conectores SFTP.

Conectores SFTP podem ser usados para enviar arquivos do Amazon S3 para um servidor SFTP remoto, recuperar arquivos de um servidor SFTP remoto para o Amazon S3 e listar arquivos armazenados em um diretório no servidor SFTP remoto. Para saber mais sobre o uso de conectores SFTP, consulte a documentação de conectores SFTP.

Você pode listar os arquivos armazenados em um diretório em servidores SFTP remotos usando a operação da API StartDirectoryListing dos conectores SFTP. Em seguida, você poderá recuperar arquivos de destino do servidor remoto passando os nomes dos arquivos da lista ao usar a operação da API StartFileTransfer para transferir arquivos. Para obter mais informações, consulte o exemplo de solução para sincronizar novos arquivos de servidores SFTP remotos ou participe do workshop de MFT.

Você pode listar todos os arquivos de um diretório no servidor SFTP remoto usando conectores SFTP e criar uma lógica personalizada para filtrar a lista de arquivos com base em seus critérios de curinga para padrões de nome de arquivo. Em seguida, você pode usar a operação da API StartFileTransfer para transferir esses arquivos usando conectores SFTP.

Você pode monitorar o status atual de suas operações de transferência de arquivos usando o comando da API ListFileTransferResults. Além disso, os conectores SFTP emitem logs detalhados no Amazon CloudWatch, incluindo status de suas transferências de arquivos, tipo de operação (enviar ou recuperar), data e hora, caminho do arquivo e descrição do erro (se houver) para ajudar você a manter a linhagem de dados. 

Sim. Você pode agendar transferências de arquivos usando o Agendador do Amazon EventBridge. Crie um cronograma que atenda às necessidades da sua empresa usando o Scheduler do EventBridge e especifique a API StartFileTransfer do AWS Transfer Family, ou a API StartDirectoryListing, como a meta universal para sua programação.

Sim. O AWS Step Functions se integra a vários serviços da AWS, incluindo a AWS Transfer Family, permitindo que você invoque a ação StartFileTransfer do conector SFTP diretamente da sua máquina estadual. Depois de criar seu conector SFTP com o AWS Transfer Family, aproveite as integrações do AWS SDK do Step Functions para chamar a API StartFileTransfer. Para saber mais sobre como orquestrar seus fluxos de trabalho de transferência e processamento de arquivos usando o AWS Step Functions e os conectores SFTP, participe do workshop individualizado de MFT orientado por eventos.

Sim. Cada operação de transferência de arquivos usando conectores SFTP publica uma notificação de evento em seu barramento de eventos padrão no Amazon EventBridge. Você pode assinar eventos do conector SFTP e usá-los para orquestrar o processamento orientado por eventos de seus arquivos transferidos usando o Amazon EventBridge ou qualquer outro serviço de orquestração de fluxo de trabalho de sua escolha que se integre a esses eventos.

Sim. Os endereços IP estáticos são associados aos seus conectores por padrão e podem ser usados para listar conexões no firewall do seu parceiro de negócios. É possível identificar os endereços IP estáticos associados aos seus conectores navegando até a página de detalhes do conector no Console da AWS Transfer Family ou usando o comando DescribeConnector da API/CLI/CDK.

Sim. Todos os conectores SFTP em uma região de conta da AWS compartilharão um conjunto de endereços IP estáticos. Compartilhar endereços IP entre conectores de um determinado tipo reduz a quantidade de documentação da lista de permissões, bem como as comunicações de integração necessárias com seus parceiros externos.

Não. Atualmente, os conectores SFTP só podem ser usados para se conectar a servidores que oferecem um endpoint acessível pela Internet. Se você precisar se conectar a servidores que só podem ser acessados por meio de uma rede privada, informe-nos por meio do AWS Support ou por meio de sua equipe de conta da AWS.

Sim. Durante a configuração, você pode selecionar os protocolos que deseja habilitar para a conexão dos clientes ao endpoint. O nome do host, o endereço IP e o provedor de identidade do servidor são compartilhados nos protocolos selecionados. Da mesma forma, você também pode habilitar suporte de protocolo adicional para endpoints existentes do AWS Transfer Family, desde que a configuração do endpoint atenda aos requisitos de todos os protocolos que você pretende usar.

Quando você precisar usar FTP (somente para acesso dentro da VPC), e também SFTP, AS2 ou FTPS pela Internet, será necessário usar um endpoint de servidor separado para FTP. Você pode usar o mesmo endpoint para vários protocolos quando quer usar o mesmo nome de host e endereço IP de endpoint para clientes que se conectam usando vários protocolos. Além disso, se você quer compartilhar as mesmas credenciais para SFTP e FTPS, pode configurar e usar um único provedor de identidade para autenticar clientes que se conectam usando um desses protocolos.

Sim. Você pode fornecer o mesmo acesso de usuário por meio de vários protocolos, desde que as credenciais específicas do protocolo tenham sido configuradas no provedor de identidade. Se você habilitou o FTP, recomendamos manter credenciais separadas para esse protocolo. Consulte a documentação sobre como configurar credenciais separadas para o FTP.

Ao contrário do SFTP e do FTPS, o FTP transmite credenciais em texto simples. Recomendamos isolar as credenciais do FTP das do SFTP ou FTPS para que, em caso de compartilhamento ou divulgação involuntária das credenciais do FTP, as cargas de trabalho que usam SFTP ou FTPS permaneçam seguras.

Sim. Você pode implantar essa solução de código aberto que permite o fornecimento de uma interface baseada em navegador usando endpoints SFTP do AWS Transfer Family.

O serviço oferece suporte a três opções de provedor de identidades: gerenciada pelo serviço, em que você armazena identidades de usuários dentro do serviço, Microsoft Active Directory e provedores de identidade personalizados, que permitem a integração do provedor de identidades que preferir. A autenticação gerenciada pelo serviço só é permitida para endpoints de servidor habilitados para SFTP.

Você pode utilizar a autenticação gerenciada pelo serviço para autenticar usuários de SFTP usando chaves SSH.

Você pode carregar até dez chaves SSH por usuário. As chaves RSA, ED25519 e ECDSA são compatíveis.

Sim. Consulte a documentação para obter detalhes sobre como configurar a mudança de chaves para usuários do SFTP.

Ao criar um servidor, você seleciona um diretório no AWS Managed Microsoft AD, no ambiente on-premises ou no AD autogerenciado no Amazon EC2 como seu provedor de identidades. Em seguida, você precisará especificar os grupos do AD que deseja habilitar para acesso usando um identificador de segurança (SID). Depois de associar seu grupo do AD às informações de controle de acesso, como perfil do IAM, política de restrição de acesso (somente S3), Perfil POSIX (somente EFS), localização do diretório inicial e mapeamentos lógicos de diretório, os membros do grupo podem usar as credenciais do AD para autenticar e transferir arquivos pelos protocolos habilitados (SFTP, FTPS, FTP). 

Ao configurar usuários, você fornece uma política de restrição de acesso que é avaliada no runtime com base nas informações dos usuários, como o nome de usuário. Você pode usar a mesma política de restrição de acesso para todos os seus usuários para fornecer acesso a prefixos exclusivos em seu bucket com base nos nomes de usuário dos usuários. Além disso, um nome de usuário também pode ser usado para avaliar mapeamentos lógicos de diretório, fornecendo um modelo padronizado sobre como o conteúdo do seu bucket do S3 ou sistema de arquivos EFS torna-se visível para o usuário. Para obter mais informações, acesse a documentação sobre como conceder acesso a grupos do AD.

Sim. Você pode usar o Microsoft AD para autenticar usuários para acesso por SFTP, FTPS e FTP.

Sim. Vvocê pode revogar o acesso à transferência de arquivos para grupos individuais do AD. Uma vez revogado, os membros dos grupos do AD não poderão transferir arquivos usando suas respectivas credenciais do AD.

O modo personalizado (autenticação “BYO”) permite que você use um provedor de identidades existente para gerenciar usuários finais para todos os tipos de protocolo (SFTP, FTPS e FTP), permitindo a migração fácil e contínua de usuários. As credenciais podem ser armazenadas no seu diretório corporativo ou em um datastore de identidades interno. Além disso, você pode integrá-las para fins de autenticação de usuários finais. Exemplos de provedores de identidade incluem o Okta, o Microsoft AzureAD ou qualquer provedor de identidade personalizado que você possa usar como parte de um portal de provisionamento geral.

Para integrar seu provedor de identidade a um servidor do AWS Transfer Family, você pode usar uma função do AWS Lambda ou um endpoint do Amazon API Gateway. Use o Amazon API Gateway se precisar de uma API RESTful para se conectar a um provedor de identidade ou se quiser aproveitar o AWS WAF devido à capacidade de bloqueio geográfico e limitação de taxa. Acesse a documentação para saber mais sobre a integração de provedores de identidade comuns, como o AWS Cognito, Okta e AWS Secrets Manager.

Sim. O IP de origem do cliente é passado ao seu provedor de identidade quando o AWS Lambda ou o API Gateway é usado para a conexão com um provedor de identidade personalizado. Isso possibilita que você permita, negue ou limite o acesso com base nos endereços IP dos clientes para garantir que seus dados sejam acessados somente dos endereços IP que você especificou como confiáveis.

Sim. Você pode aplicar vários métodos de autenticação para fornecer uma camada adicional de segurança quando seus dados são acessados por SFTP. O seu servidor SFTP pode ser configurado para exigir senha e chave SSH, senha ou chave SSH, apenas senha ou apenas chave SSH. Consulte a documentação para obter detalhes sobre como habilitar vários métodos de autenticação usando seu provedor de identidade do cliente.

Não. No momento, não há suporte ao armazenamento de senhas no serviço para fins de autenticação. Se você precisar de autenticação de senha, use o Active Directory selecionando um diretório no AWS Directory Service ou siga a arquitetura descrita neste blog em Enabling Password Authentication using Secrets Manager.

Não. No momento, não permitimos usuários anônimos em nenhum dos protocolos.

Não. Só oferecemos suporte para configuração de acesso por grupos do AD.

Não. O suporte do AWS Transfer Family para o Microsoft AD só pode ser usado para autenticação baseada em senha. Para usar uma combinação de modos de autenticação, use a opção Autorizador personalizado.

Sim. O suporte do AWS Transfer Family para o AS2 recebeu o selo oficial da Drummond Group AS2 Cloud Certification. Os recursos AS2 do AWS Transfer Family foram cuidadosamente avaliados quanto à segurança e à compatibilidade de troca de mensagens com outras quatorze soluções AS2 de terceiros. Acesse nosso anúncio para saber mais.

Seu parceiro comercial tem uma identificação exclusiva que usa o AS2 Identifier (AS2 ID) dele. De modo semelhante, seus parceiros comerciais identificam suas mensagens usando seu AS2 ID.

Você pode usar o suporte existente do AWS Transfer Family para o Amazon S3, recursos de rede (endpoints da VPC, grupos de segurança e IPs elásticos) e controles de acesso (AWS IAM) para AS2, como faria para SFTP, FTPS e FTP. Autenticação de usuário, diretórios lógicos, banners personalizados e Amazon EFS como back-end de armazenamento não são compatíveis com AS2.

O não repúdio, exclusivo do AS2, valida que a mensagem foi trocada com sucesso entre duas partes. O não repúdio no AS2 é obtido usando Notificações de Disposição de Mensagem (MDN). Quando um MDN é solicitado em uma transação, ele garante que o remetente enviou a mensagem, o destinatário a recebeu com sucesso e a mensagem enviada pelo remetente foi a mesma mensagem recebida pelo destinatário.

Existem dois aspectos na transmissão de mensagens: um do remetente e um do receptor. Depois que o remetente determina qual mensagem enviar, a mensagem é assinada (usando a chave privada do remetente) e criptografada (usando o certificado do destinatário), e sua integridade é calculada usando um hash. Essa mensagem assinada e criptografada é transmitida por fio para o receptor. Quando a mensagem é recebida, ela é descriptografada (usando a chave privada do destinatário), validada (usando a chave pública do remetente) e processada, e uma Notificação de Disposição de Mensagem (MDN) assinada, se solicitada, é enviada de volta ao remetente para confirmar a entrega bem-sucedida da mensagem. Consulte a documentação sobre como o AS2 lida com a transmissão de mensagens.

A combinação de opções possíveis é orientada do ponto de vista de um remetente. O remetente pode optar por apenas criptografar ou apenas assinar os dados (ou ambos) e optar por solicitar uma Notificação de Disposição de Mensagem (MDN). Se o remetente optar por solicitar uma MDN, poderá solicitar um MDN assinado ou não assinado. Espera-se que o receptor honre essas opções.

Sim. O remetente pode optar por solicitar um MDN, optar por solicitar uma MDN assinado ou não assinado, bem como selecionar os algoritmos de assinatura que devem ser usados para assinar a MDN.

Atualmente, oferecemos suporte a respostas MDN síncronas e assíncronas. Isso permite que você responda aos seus parceiros comerciais com uma MDN síncrona ou assíncrona após receber uma mensagem AS2. Como as MDNs síncronas são enviadas pelo mesmo canal de conexão que a mensagem, é muito mais simples e, portanto, a opção recomendada. Se você precisar de mais tempo para processar a mensagem antes de enviar uma MDN, prefira as MDNs assíncronas. Se você precisar solicitar e receber MDNs assíncronas ao enviar mensagens para parceiros comerciais, entre em contato conosco por meio do AWS Support ou pelo seu gerente de conta.

O AWS Transfer Family extrai as principais informações AS2 da carga útil e das MDNs trocadas e as armazena como arquivos JSON no seu bucket do Amazon S3. Você pode consultar esses arquivos JSON usando o S3 Select ou o Amazon Athena ou indexar os arquivos usando o Amazon OpenSearch ou o Amazon DocumentDB para análise.

Sim. Quando você recebe um MDN de seu parceiro comercial, o serviço valida o MDN usando seu certificado e armazena a mensagem em seu bucket do Amazon S3. Você pode optar por arquivar a mensagem aproveitando as políticas do S3 Lifecycle.

Quando os dados estiverem prontos para entrega, você precisará invocar a API StartFileTransfer usando o conector AS2 que contém as informações do servidor AS2 do destinatário. Isso notificará o serviço para enviar a mensagem ao servidor do parceiro comercial. Consulte a documentação sobre conectores para enviar mensagens ao seu parceiro comercial sobre o AS2.

Sim. Ao configurar o perfil do seu parceiro comercial, você pode usar pastas diferentes para cada um deles.

Sim. Você pode importar as chaves e certificados existentes do seu parceiro e gerenciar renovações e rotações. Consulte a documentação sobre a importação de certificados.

No console do AWS Transfer Family, você pode visualizar um painel de certificados classificados por datas de expiração. Além disso, você pode optar por receber notificações antes da expiração do certificado, proporcionando tempo suficiente para alterná-las para evitar a descontinuidade nas operações.

Sim. Os endereços IP estáticos são associados aos seus conectores por padrão e podem ser usados para listar conexões no servidor AS2 do seu parceiro comercial. É possível identificar os endereços IP estáticos associados aos seus conectores navegando até a página de detalhes do conector no Console da AWS Transfer Family ou usando o comando DescribeConnector da API/CLI/CDK.

Sim. Oferecemos suporte à capacidade de se conectar ao servidor AS2 do seu parceiro comercial usando a autenticação básica. Consulte a documentação sobre como configurar a Autenticação básica em conectores do AS2.

Sim. Seus conectores AS2 usam endereços IP estáticos ao enviar mensagens para servidores AS2 remotos e ao retornar respostas assíncronas de Message Disposition Notification (MDN – Notificação de disposição de mensagens). É possível identificar os endereços IP estáticos associados aos seus conectores navegando até a página de detalhes do conector ou servidor no console de gerenciamento do AWS Transfer Family ou usando os comandos DescribeConnector ou DescribeServer da API/CLI/CDK.

Sim. Seus endpoints de servidor do AS2 são compatíveis com a configuração de controles de lista de permissões de IP usando grupos de segurança com endpoints hospedados em VPC voltados para a Internet.

Sim. Suas respostas da MDN assíncronas do AS2 usarão endereços IP estáticos. É possível identificar os endereços IP estáticos usados para enviar suas respostas assíncronas da MDN navegando até a página de detalhes do servidor no Console de gerenciamento da AWS Transfer Family ou usando o comando DescribeServer da API/CLI/CDK.

Cada mensagem do AS2 recebida publica um evento em seu barramento de eventos padrão no Amazon EventBridge. Você pode se inscrever nesses eventos e usá-los para orquestrar o processamento orientado por eventos das mensagens recebidas usando o Amazon EventBridge ou qualquer outro serviço de orquestração de fluxos de trabalho. Por exemplo, você pode usar esses eventos para copiar as mensagens recebidas para outros locais no S3, escanear o conteúdo das mensagens usando um Lambda personalizado ou marcar mensagens com base em seu conteúdo para que possam ser indexadas e pesquisadas por serviços como o Amazon CloudSearch.

Sim. Você pode transformar automaticamente o conteúdo EDI X12 de suas mensagens do AS2 de entrada em representações de dados comuns, como JSON e XML, usando o AWS B2B Data Interchange. Para fazer isso, crie uma regra do Amazon EventBridge que corresponda ao padrão de eventos do evento AS2 Payload Receive Completed do AWS Transfer Family e especifique a API StartTransformerJob do AWS B2B Data Interchange como o destino universal da regra. Ao transformar o conteúdo EDI X12 de suas mensagens do AS2 de entrada com o AWS B2B Data Interchange, você pode automatizar e acelerar a integração de seus dados EDI em aplicativos e sistemas comerciais posteriores.

Você pode automatizar o envio de mensagens do AS2 agendando-as com o Agendador do Amazon EventBridge ou acionando-as usando as regras do Amazon EventBridge. Para criar fluxos de trabalho automatizados e baseados em tempo para enviar mensagens do AS2, crie uma programação que atenda às necessidades da sua empresa usando o EventBridge Scheduler e especifique a API StartFileTransfer do AWS Transfer Family como a meta universal para sua programação. Para criar fluxos de trabalho automatizados e orientados por eventos para enviar mensagens do AS2, crie uma regra do Amazon EventBridge que corresponda aos eventos publicados no EventBridge e especifique a API StartFileTransfer do AWS Transfer Family como o destino universal para sua regra.

Sim. Cada mensagem do AS2 e MDN enviada publica um evento em seu barramento de eventos padrão no Amazon EventBridge. Você pode se inscrever nesses eventos e usá-los para excluir ou arquivar mensagens do AS2 e MDN enviadas com sucesso ao seu parceiro comercial.

Sim. O AWS Transfer Family publica eventos no Amazon EventBridge para cada mensagem do AS2 bem-sucedida ou com falha ou MDN enviada e recebida. Esses eventos são publicados em seu barramento de eventos padrão no Amazon EventBridge, onde podem ser usados para acionar notificações por e-mail para você ou seus parceiros usando serviços como o Amazon SNS.

Não. Atualmente, os fluxos de trabalho gerenciados não são compatíveis com seus endpoints do AS2. Recomendamos usar as notificações de eventos do Transfer Family que são publicadas no Amazon EventBridge para orquestrar o processamento de suas mensagens do AS2. Para obter mais detalhes, consulte a seção Automação de processamento de arquivos.

Não. No momento, o AWS Transfer Family não é compatível com AS3 ou AS4.

Você tem duas opções: 1) o AWS Transfer Family publica notificações de eventos de transferência de arquivos no Amazon EventBridge para arquivos transferidos por SFTP, AS2, FTPS e FTP, e você pode usar esses eventos para acionar o processamento de seus arquivos usando qualquer serviço que possa se integrar aos eventos do EventBridge; e 2) o AWS Transfer Family fornece fluxos de trabalho gerenciados para facilitar a execução automática do processamento pós-upload de arquivos enviados por endpoints de servidores SFTP, FTPS e FTP usando etapas de processamento de arquivos pré-criadas. Quando você associa um fluxo de trabalho gerenciado ao endpoint do servidor, todos os arquivos enviados por esse endpoint são processados usando as mesmas etapas do fluxo de trabalho.

A AWS Transfer Family publica notificações de eventos no Amazon EventBridge após a conclusão bem-sucedida ou malsucedida de cada operação de transferência de arquivos, tanto para recursos de servidor quanto de conectores. Para obter mais informações sobre os eventos do Transfer Family publicados no Amazon EventBridge, consulte a documentação. 

Se você precisar processar os arquivos que troca com os parceiros comerciais, será necessário configurar uma infraestrutura para executar código personalizado, monitorar continuamente erros e anomalias em runtime e garantir que todas as alterações e transformações nos dados sejam auditadas e registradas em logs. Além disso, você é responsável por cenários de erros, tanto técnicos quanto comerciais, garantindo ao mesmo tempo que modos à prova de falhas sejam acionados adequadamente. Se houver a necessidade de rastreabilidade, você precisará seguir a linhagem dos dados à medida que eles passam por diferentes componentes do seu sistema. A manutenção de componentes separados de um fluxo de trabalho de processamento de arquivos tira o tempo do foco na diferenciação do trabalho que você poderia estar fazendo para sua empresa. Os fluxos de trabalho gerenciados eliminam as complexidades do gerenciamento de várias tarefas e fornecem uma solução padronizada de processamento de arquivos que pode ser replicada em toda a organização, com gerenciamento de exceções integrado e rastreabilidade de arquivos para cada etapa com o objetivo de ajudar você a atender aos requisitos legais e de negócios.

Os fluxos de trabalho gerenciados da AWS Transfer Family fornecem uma estrutura pré-criada para você criar, executar e monitorar uma sequência linear de etapas para processar arquivos enviados por meio de endpoints de servidores SFTP, FTPS e FTP. Usando esse recurso, você pode economizar tempo com etapas pré-criadas para executar tarefas comuns de processamento de arquivos, como copiar, marcar e descriptografar arquivos. Você também pode personalizar o processamento de arquivos usando uma função do Lambda para tarefas como examinar arquivos em busca de PII, vírus/malware ou outros erros, como formato ou tipo de arquivo incorretos, permitindo que você detecte anomalias rapidamente e atenda aos requisitos de conformidade. Quando você associa um fluxo de trabalho gerenciado ao endpoint do servidor, todos os arquivos enviados por esse endpoint são processados usando as mesmas etapas do fluxo de trabalho.

Os fluxos de trabalho gerenciados permitem que você pré-processe facilmente os dados antes de serem consumidos pelos aplicativos downstream, executando uma sequência linear de tarefas de processamento de arquivos para todos os arquivos enviados para os endpoints do servidor, como mover arquivos enviados para pastas específicas do usuário, descriptografar arquivos usando chaves PGP, verificar malware e marcar. Você pode implantar fluxos de trabalho usando Infraestrutura como código (IaC), permitindo replicar e padronizar rapidamente tarefas comuns de processamento de arquivos pós-upload abrangendo várias unidades de negócios na sua organização. Você pode ter controle granular associando um fluxo de trabalho gerenciado ao endpoint do servidor que é acionado somente em arquivos totalmente carregados e associando um fluxo de trabalho gerenciado separado que é acionado somente para arquivos parcialmente carregados para processar uploads incompletos. Os fluxos de trabalho também fornecem tratamento de exceções integrado permite que você reaja rapidamente aos resultados do processamento de arquivos em caso de erros ou exceções na execução do fluxo de trabalho, ajudando a manter seus SLAs comerciais e técnicos. Cada etapa de processamento de arquivos em seu fluxo de trabalho também produz registros detalhados, que podem ser auditados para rastrear a linhagem de dados.

Os endpoints e conectores de servidores do AWS Transfer Family publicam automaticamente notificações de eventos no Amazon EventBridge quando uma operação de transferência de arquivos é concluída, junto com informações operacionais, como localização do arquivo, nome de usuário do remetente, ID do servidor ou ID do conector, status da transferência, etc. Você pode usar esses eventos quando precisar de controle granular na definição do processamento de arquivos, como usar a lógica condicional com base na origem do arquivo, ou quando precisar criar arquiteturas orientadas por eventos para se integrar a outros serviços da AWS, aplicativos de terceiros e seus próprios aplicativos. Por outro lado, os fluxos de trabalho gerenciados do AWS Transfer Family fornecem uma estrutura pré-criada para definir uma sequência linear de etapas comuns de processamento de arquivos que são aplicadas a todos os arquivos enviados por meio de seus endpoints de servidores SFTP, FTPS e FTP. Você pode associar um fluxo de trabalho gerenciado ao seu endpoint quando todos os arquivos enviados precisarem ser processados usando as mesmas etapas comuns de processamento de arquivos sem precisar aplicar nenhuma lógica granular ou condicional.

Primeiro, configure o fluxo de trabalho para que contenha ações como cópia, marcação e uma série de ações que podem incluir sua própria etapa personalizada em uma sequência de passos baseados nos requisitos relevantes. Em seguida, mapeie o fluxo de trabalho para um servidor para que, ao chegar um arquivo, ações especificadas nesse fluxo de trabalho sejam avaliadas e acionadas em tempo real. Para saber mais, acesse a documentação, assista a esta demonstração sobre como começar a usar fluxos de trabalho gerenciados ou implante uma plataforma de transferência de arquivos nativa de nuvem consultando esta postagem do blog.

Sim. O mesmo fluxo de trabalho pode ser associado a vários servidores, pois assim é mais fácil para que você mantenha e padronize as configurações.

Sim. Você pode configurar uma etapa de fluxo de trabalho para processar o arquivo carregado originalmente ou o arquivo de saída da etapa anterior do fluxo de trabalho. Isso permite que você automatize facilmente a movimentação e a renomeação dos seus arquivos depois que eles são carregados no Amazon S3. Por exemplo, para mover um arquivo para um local diferente para arquivamento ou retenção de arquivos, configure duas etapas no fluxo de trabalho. A primeira etapa é copiar um arquivo para um local diferente do Amazon S3 e a segunda etapa é excluir o arquivo carregado originalmente. Leia a documentação para obter mais detalhes sobre como selecionar um local de arquivo para as etapas do fluxo de trabalho.

As seguintes ações comuns estarão disponíveis quando um servidor de transferência tiver recebido um arquivo do cliente:

descriptografar aquivo usando chaves PGP. Consulte esta postagem do blog sobre como criptografar e descriptografar arquivos usando o PGP.

mover ou copiar os dados de sua origem para onde precisarem ser consumidos.

Exclua a publicação do arquivo original arquivando ou copiando para um novo local.

Marcar o arquivo com base no seu conteúdo, para que ele possa ser indexado e buscado por serviços posteriores (somente S3)

Qualquer arquivo personalizado que processe lógica fornecendo sua própria função do Lambda como uma etapa personalizada do seu fluxo de trabalho. Por exemplo, verificar a compatibilidade do tipo de arquivo, verificar arquivos em busca de malware, detectar informações de identificação pessoal (PII) e extração de metadados antes de ingerir arquivos para sua análise de dados.

Sim. Você pode usar uma etapa de fluxo de trabalho pré-criada e totalmente gerenciada para a decodificação PGP de arquivos enviados pelos endpoints de servidores SFTP, FTPS e FTP. Para obter mais informações, consulte a documentação de fluxos de trabalho gerenciados e esta postagem do blog sobre criptografia e descriptografia de arquivos usando o PGP.

Você pode configurar uma etapa de fluxo de trabalho para processar o arquivo carregado originalmente no endpoint do servidor ou o arquivo de saída da etapa anterior em um fluxo de trabalho. Isso permite que você automatize facilmente a movimentação e a renomeação dos seus arquivos depois que eles são carregados no Amazon S3. Por exemplo, para mover um arquivo para um local diferente para arquivamento ou retenção de arquivos, configure duas etapas no fluxo de trabalho. A primeira etapa é copiar um arquivo para um local diferente do Amazon S3 e a segunda etapa é excluir o arquivo carregado originalmente. Leia a documentação para obter mais detalhes sobre como selecionar um local de arquivo para as etapas do fluxo de trabalho.

Sim. Usando fluxos de trabalho gerenciados, você pode criar várias cópias do arquivo original, preservando o arquivo original para retenção de registros.

Sim. Você pode utilizar o nome de usuário como uma variável em etapas de cópia de fluxos de trabalho, permitindo rotear arquivos dinamicamente para pastas específicas do usuário no Amazon S3. Isso elimina a necessidade de codificar a localização da pasta de destino ao copiar arquivos e automatiza a criação de pastas específicas do usuário no Amazon S3, permitindo que você dimensione seus fluxos de trabalho de automação de arquivos. Leia a documentação para saber mais.

O AWS Step Functions é um serviço de orquestração sem servidor que permite combinar o AWS Lambda com outros serviços para definir a execução de uma aplicação corporativa em etapas simples. Para executar etapas de processamento de arquivos usando o AWS Step Functions, você usa as funções do AWS Lambda com os acionadores de eventos do Amazon S3 para montar seus próprios fluxos de trabalho. Fluxos de trabalho gerenciados fornecem um framework para orquestrar com facilidade uma sequência linear de processamento e se diferenciam das soluções atuais das seguintes formas: 1) é possível definir detalhadamente os fluxos de trabalho para que sejam executados somente nos uploads de arquivos completos, bem como fluxos de trabalho que sejam executados somente em uploads de arquivos parciais, 2) os fluxos de trabalho podem ser acionados automaticamente para o S3 e para o EFS (que não oferece eventos pós-upload), 3) os fluxos de trabalho não fornecem código e opções pré-criadas para o processamento de arquivos comum, e 4) os clientes podem ter visibilidade de ponta a ponta de suas transferências e processamento de arquivos nos logs do CloudWatch.

Consulte a seção Monitoramento para obter detalhes sobre os atributos compatíveis para registrar em log sua atividade de fluxos de trabalho gerenciados.

Sim. Consulte esta postagem do blog sobre o uso de fluxos de trabalho gerenciados para notificações de entrega de arquivos.

Sim. Você pode definir fluxos de trabalho separados a serem acionados em uploads completos de arquivos e em uploads parciais de arquivos.

Não. Você pode recorrer ao processamento apenas na chegada do arquivo usando o endpoint de entrada.

Atualmente, os fluxos de trabalho gerenciados só podem ser acionados para arquivos enviados pelos endpoints de servidores SFTP, FTPS e FTP e processar um arquivo por execução. Os fluxos de trabalho gerenciados não são compatíveis com mensagens trocadas pelo AS2, para downloads de arquivos nos endpoints de servidores e para arquivos transferidos usando conectores SFTP.

Não. Atualmente, os fluxos de trabalho processam um arquivo por execução.

Não. Os fluxos de trabalho gerenciados não podem ser invocados de forma granular, por usuário. Você pode definir a lógica de processamento condicional de arquivos com base no usuário que fez o upload do arquivo usando as notificações de eventos de transferência de arquivos publicadas no Amazon EventBridge.

A transferência de dados entre servidores do AWS Transfer Family e o Amazon S3 ocorre em redes internas da AWS e não percorrem a Internet pública. Devido a isso, não é necessário usar o AWS PrivateLink para dados transferidos do servidor do AWS Transfer Family para o Amazon S3. O serviço do Transfer Family não requer endpoints do AWS PrivateLink para que o Amazon S3 impeça que o tráfego passe pela Internet e, portanto, não pode usar endpoints para se comunicar com serviços de armazenamento. Tudo isso pressupõe que o serviço de armazenamento da AWS e o servidor do Transfer Family estejam na mesma região.

O AWS IAM é usado para determinar o nível de acesso que você deseja conceder aos usuários. Isso inclui as operações que você deseja habilitar nos clientes dos usuários, a quais buckets do Amazon S3 eles terão acesso e se todo o bucket será acessado ou apenas partes dele.

R: O diretório inicial configurado para os usuários determina o diretório de login deles. Esse diretório é o caminho de diretórios em que o cliente do usuário ficará posicionado logo após a autenticação bem-sucedida no servidor. Você precisa verificar se a função do IAM fornecida permite que o usuário acesse o diretório inicial.

Sim. Você pode atribuir uma única função do IAM para todos os usuários e usar mapeamentos de diretórios lógicos que especificam quais caminhos absolutos de buckets do Amazon S3 você quer tornar visíveis para os usuários finais, e como seus clientes apresentarão esses caminhos. Consulte esta publicação de blog sobre como simplificar uma estrutura do AWS SFTP/FTPS/FTP com chroot e diretórios lógicos.

R: Os arquivos transferidos pelos protocolos permitidos são armazenados como objetos no bucket do Amazon S3. Há um mapeamento individual entre os arquivos e os objetos, o que permite acessá-los nativamente usando os serviços da AWS para processamento ou análises.

R: Após uma autenticação bem-sucedida, com base nas credenciais do usuário, o serviço apresenta os objetos e as pastas do Amazon S3 como arquivos e diretórios para os aplicativos de transferência dos usuários.

São permitidos os comandos comuns para criar, ler, atualizar e excluir arquivos e diretórios. Os arquivos são armazenados como objetos individuais no bucket do Amazon S3. Os diretórios são gerenciados como objetos de pasta no S3, usando a mesma sintaxe do console do S3.

No momento, não são permitidas operações de renomeação de diretórios; operações de anexação; alteração de proprietários, permissões e carimbos de data/hora; e o uso de links simbólicos e físicos.

Sim. Você pode ativar/desativar operações de arquivos usando a função do AWS IAM que mapeou para o nome de usuário deles. Consulte a documentação sobre como criar políticas e perfis do IAM para controlar o acesso de usuários finais.

Sim. Os buckets que seu usuário pode acessar são determinados pela função do AWS IAM e pela política de redução do escopo que você atribuir para este usuário. Você só pode usar um único bucket como diretório inicial para o usuário.

Sim. Você pode usar aliases de pontos de acesso do S3 com o AWS Transfer Family para fornecer acesso detalhado a um grande conjunto de dados sem ter de gerenciar uma única política de bucket. Aliases de pontos de acesso do S3 combinados com diretórios lógicos do AWS Transfer Family permitem que você crie um controle de acesso detalhado para diferentes aplicações, equipes e departamentos, ao mesmo tempo reduzindo a sobrecarga de gerenciar políticas de bucket. Para saber mais e começar a usar, acesse a publicação do blog sobre como aprimorar o controle de acesso a dados com o AWS Transfer Family e Pontos de Acesso Amazon S3.

Sim. Você pode usar a ILC e a API para configurar o acesso cruzado de contas entre o servidor e os buckets que você quer usar para armazenar arquivos transferidos usando os protocolos permitidos. A lista suspensa do console só mostrará buckets da conta A. Além disso, você terá de verificar se a função que está sendo atribuída ao usuário pertence à conta A.

Sim. O AWS Transfer Family publica notificações de eventos no Amazon EventBridge após a conclusão de uma operação de transferência de arquivos, e você pode usar esses eventos para automatizar o processamento pós-upload de seus arquivos. Como alternativa, quando todos os seus arquivos enviados precisarem ser processados usando as mesmas etapas de processamento de arquivos sem qualquer lógica condicional, você pode usar os fluxos de trabalho gerenciados pelo AWS Transfer Family para definir uma sequência linear de etapas comuns de processamento de arquivos que são invocadas automaticamente para cada arquivo que seus usuários carregam por meio de seus endpoints de servidores SFTP, FTPS ou FTP.

Sim. Quando o usuário carrega um arquivo, o nome de usuário e o ID do servidor usado para a carga são armazenados como parte dos metadados associados ao objeto do S3. Consulte a documentação sobre as informações que você utiliza para o processamento pós-upload. As informações do usuário final também estão disponíveis na notificação automática do evento de upload de arquivos publicada pelo AWS Transfer Family no Amazon EventBridge. Você pode usar essas informações para orquestrar o processamento granular pós-upload de seus arquivos com base no usuário. 

O Amazon S3 pode publicar notificações de eventos para qualquer novo objeto criado em seu bucket. Por outro lado, o AWS Transfer Family publica notificações de eventos após a conclusão bem-sucedida ou malsucedida de cada operação de transferência de arquivos. Elas se diferenciam das notificações de eventos do Amazon S3 das seguintes maneiras: 1) você pode ter controle granular ao definir o processamento pós-upload para uploads completos de arquivos versus uploads parciais de arquivos ao usar as notificações de eventos do Transfer Family; 2) os eventos do Transfer Family são publicados para uploads de arquivos no S3 e no EFS; e 3) os eventos gerados pelo Transfer Family contêm informações operacionais, como nome de usuário do remetente, ID do servidor, status da transferência etc. e permite que você defina o processamento de arquivos de forma granular, com base na lógica condicional desses atributos.

Sim. Você pode otimizar sua listagem de diretórios do S3 para que seus usuários finais possam aproveitar a listagem acelerada dos seus diretórios: de minutos a segundos. Se você estiver criando um novo servidor por meio do console após 17/11/2023, seu servidor terá a listagem de diretórios do S3 otimizada habilitado por padrão se você estiver usando o Amazon S3 como armazenamento. Isso pode ser ativado ou desativado a qualquer momento. Desativar esse atributo restaura sua listagem de diretórios do S3 para a performance padrão. Se você estiver usando o CloudFormation, a CLI ou a API para criar um servidor, a listagem otimizada de diretórios do S3 estará desabilitada por padrão, mas pode ser habilitada a qualquer momento. Consulte a documentação sobre como habilitar a listagem otimizada de diretórios do S3.

Embora isso dependa do uso de políticas de sessão e de outros requisitos internos, geralmente você não precisa de políticas de sessão e diretórios lógicos para garantir que seus usuários acessem somente os arquivos que você deseja. Os mapeamentos de diretórios lógicos apenas permitem que os usuários acessem seus caminhos lógicos e subdiretórios designados e proíbem caminhos relativos que atravessam as raízes lógicas. Validamos cada caminho usando notação relativa que pode incluir elementos relativos e bloqueamos ativamente a resolução desses caminhos antes de passá-los para o S3 para evitar que seus usuários ultrapassem seus mapeamentos lógicos. 

Antes de configurar o AWS Transfer Family para trabalhar com um sistema de arquivos do Amazon EFS, você precisará configurar a propriedade de arquivos e pastas usando as mesmas identidades POSIX (ID de usuário/ID de grupo) que você planeja atribuir aos usuários do AWS Transfer Family. Além disso, se você estiver acessando sistemas de arquivos em uma conta diferente, as políticas de recursos também devem ser configuradas no seu sistema de arquivos para permitir o acesso entre contas. Consulte esta postagem de blog para obter instruções detalhadas sobre o uso do AWS Transfer Family com EFS.

A transferência de dados entre servidores do AWS Transfer Family e o Amazon EFS ocorre em redes internas da AWS e não percorrem a Internet pública. Devido a isso, não é necessário usar o AWS PrivateLink para dados transferidos do servidor do AWS Transfer Family para o Amazon EFS. O serviço do Transfer Family não requer endpoints do AWS PrivateLink para que o Amazon EFS impeça que o tráfego passe pela Internet e, portanto, não pode usar endpoints para se comunicar com serviços de armazenamento. Tudo isso pressupõe que o serviço de armazenamento da AWS e o servidor do Transfer Family estejam na mesma região.

O Amazon EFS utiliza identificações POSIX que consistem em uma identificação de usuário do sistema operacional, identificação de grupo e identificação de grupo secundário para controlar o acesso a um sistema de arquivos. Ao configurar seu usuário no console do AWS Transfer Family/CLI/API, você precisará especificar o nome de usuário, a configuração POSIX do usuário e uma função do IAM para acessar o sistema de arquivos EFS. Você também precisará especificar um ID de sistema de arquivo EFS e opcionalmente um diretório dentro desse sistema de arquivo como o diretório de desembarque de seu usuário. Quando seu usuário do AWS Transfer Family se autenticar usando com sucesso seu cliente de transferência de arquivos, eles serão colocados diretamente dentro do diretório inicial especificado, ou raiz do sistema de arquivos EFS especificado. Seu ID do sistema operacional POSIX será aplicado a todas as solicitações feitas através de seus clientes de transferência de arquivos. Como administrador do EFS, você precisará certificar-se de que o arquivo e os diretórios que você deseja que seus usuários do AWS Transfer Family tenham acesso sejam de propriedade de seus IDs POSIX correspondentes em seu sistema de arquivos EFS. Consulte a documentação para saber mais sobre a configuração da propriedade de subdiretórios no EFS. Observe que o Transfer Family não oferece suporte a pontos de acesso se você estiver usando o Amazon EFS para armazenamento.  

Os arquivos transferidos sobre os protocolos habilitados são armazenados diretamente nos sistemas de arquivos do Amazon EFS e serão acessíveis por meio de uma interface padrão de sistema de arquivos ou de serviços da AWS que podem acessar os sistemas de arquivos do Amazon EFS.

R: Os comandos comuns do SFTP/FTPS/FTP para criar, ler, atualizar e excluir arquivos e diretórios são suportados. Consulte a tabela abaixo sobre comandos suportados para EFS, bem como S3.

1. Somente nomes de arquivos são compatíveis. Não há suporte para renomear diretórios e renomear arquivos para sobrescrever arquivos existentes.

2. Somente usuários com uid=0 podem mudar a propriedade e as permissões de arquivos e diretórios.

3. Compatível tanto com raiz, ex., uid=0 quanto com o proprietário do arquivo, que só pode mudar o grupo de um arquivo para ser um de seus grupos secundários.

4. Compatível apenas com pastas não vazias.

A política do IAM que você fornece para os usuários do AWS Transfer Family determina se eles têm acesso somente leitura, leitura-escrita e acesso raiz ao sistema de arquivos. Além disso, como administrador de sistema de arquivos, você pode configurar a propriedade e conceder acesso a arquivos e diretórios dentro de seu sistema de arquivos usando sua identificação de usuário e identificação de grupo. Isto se aplica aos usuários, sejam eles armazenados dentro do serviço (serviço gerenciado) ou dentro de seu sistema de gerenciamento de identidade ("BYO Auth").

Sim. Quando você configura seu usuário, você pode especificar diferentes sistemas de arquivos e diretórios para cada um de seus usuários. Ao autenticar com sucesso, a EFS aplicará um diretório para cada solicitação de sistema de arquivos feita usando os protocolos habilitados.

Sim. Usando os mapeamentos lógicos de diretórios do AWS Transfer Family, você pode restringir a visualização dos diretórios por parte dos seus usuários finais nos seus sistemas de arquivos mapeando caminhos absolutos para os nomes dos caminhos visíveis para o usuário final. Isso também inclui a possibilidade de "chroot" seu usuário ao diretório inicial designado.

Sim. Se houver links simbólicos em diretórios acessíveis a seu usuário e este tentar acessá-los, os links serão resolvidos para seu alvo. Links simbólicos não são compatíveis quando você usa mapeamentos lógicos de diretórios para configurar o acesso de seus usuários.

Sim. Quando você configura um usuário do AWS Transfer Family, você pode especificar um ou mais sistemas de arquivo na política do IAM que você fornece como parte de sua configuração de usuário, a fim de conceder acesso a múltiplos sistemas de arquivo.

Você pode usar clientes e aplicações desenvolvidas para o Microsoft Windows, Linux, MacOS ou qualquer sistema operacional com suporte para SFTP/FTPS/FTP para carregar e acessar arquivos armazenados nos sistemas de arquivos EFS. Basta configurar o servidor e o usuário com as permissões apropriadas para o sistema de arquivos EFS para acessar o sistema de arquivos em todos os sistemas operacionais.

Você tem duas opções: 1) o AWS Transfer Family publica notificações de eventos no Amazon EventBridge após a conclusão de uma operação de transferência de arquivos, e você pode usar esses eventos para automatizar o processamento pós-upload de seus arquivos e 2) quando todos os seus arquivos carregados precisam ser processados usando as mesmas etapas de processamento de arquivos sem qualquer lógica condicional, você pode usar os fluxos de trabalho gerenciados pelo AWS Transfer Family para definir uma sequência linear de etapas comuns de processamento de arquivos que são aplicadas a cada arquivo carregado pelos endpoints de servidores SFTP, FTPS ou FTP.

Para novos arquivos, o ID do usuário POSIX associado ao usuário que carrega o arquivo será definido como o proprietário do arquivo no sistema de arquivos EFS. Além disso, você pode usar o Amazon CloudWatch para rastrear a atividade de seus usuários nas operações de criação, atualização, exclusão e leitura de arquivos. Acesse a documentação para obter mais detalhes sobre como habilitar o registro em log no Amazon CloudWatch.

Sim. Você pode usar o CLI e API para configurar o acesso cruzado entre seus recursos da família AWS Transfer Family e os sistemas de arquivos EFS. O console do AWS Transfer Family só listará os sistemas de arquivos na mesma conta. Além disso, é necessário certificar-se de que a função do IAM atribuída ao usuário para acessar o sistema de arquivos pertença à Conta A.

Se você configurar um servidor do AWS Transfer Family para acessar um sistema de arquivo EFS de conta cruzada não habilitado para acesso de conta cruzada, os usuários de SFTP/FTP/FTPS serão impedidos de acessar o sistema de arquivo. Se você tiver o registro do CloudWatch habilitado em seu servidor, os erros de acesso de conta cruzada serão registrados em seu CloudWatch Logs.

Não. Você pode usar o AWS Transfer Family para acessar os sistemas de arquivos EFS somente na mesma região da AWS.

Sim. Você pode usar o AWS Transfer para copiar arquivos para o EFS e configurar o EFS Lifecycle Management para migrar arquivos que ainda não foram acessados por um período determinado de tempo para classes de armazenamento do Infrequent Access (IA).

Sim. O Amazon EFS disponibiliza uma interface de sistema de arquivos, uma semântica de acesso ao sistema (como consistência forte e bloqueio de arquivos) e um armazenamento acessível de modo simultâneo para até milhares de clientes NFS/SFTP/FTPS/FTP.

Sim. O acesso a seus sistemas de arquivos EFS usando seus servidores da AWS Transfer Family consumirá seus créditos de explosão EFS, independentemente do modo de transferência. Consulte a documentação sobre performance disponível e modos de throughput e veja algumas dicas úteis de performance.

Para transferências seguras por redes públicas, é preciso usar SFTP ou FTPS. Devido à segurança subjacente dos protocolos baseados nos algoritmos de criptografia SSH e TLS, os dados e os comandos são transferidos por um canal seguro e criptografado.

Você pode criptografar arquivos armazenados no bucket usando o Server-Side Encryption do Amazon S3 (SSE-S3) ou o Amazon KMS (SSE-KMS). Para arquivos armazenados no EFS, você pode escolher AWS ou CMK gerenciado pelo cliente para criptografia de arquivos em repouso. Consulte a documentação para obter mais detalhes sobre as opções de criptografia em repouso de dados e metadados de arquivos usando o Amazon EFS.

O AWS Transfer Family é compatível com as normas PCI-DSS, GDPR, FedRAMP e SOC 1, 2 e 3. O serviço também está qualificado para HIPAA. Saiba mais sobre os serviços no escopo pelos programas de conformidade.

As regiões Leste/Oeste e GovCloud (EUA) da AWS estão em conformidade com a FISMA. Quando o AWS Transfer Family for autorizado para o FedRAMP, ele estará em conformidade com a FISMA nas respectivas regiões. Essa conformidade é demonstrada por meio da autorização do FedRAMP a essas duas regiões, que as classifica como FedRAMP (impacto moderado) e FedRAMP (alto impacto). Demonstramos a conformidade por meio de avaliações anuais e da documentação de conformidade dentro do escopo dos controles NIST SP 800-53 inclusos nos nossos planos de segurança de sistemas. Os modelos estão disponíveis no Artifact junto com a matriz de responsabilidade do cliente (CRM), que demonstra em um nível detalhado nossa responsabilidade a atender a esses controles NIST, conforme as exigências do FedRAMP. O Artifact está disponível no console de gerenciamento, que pode ser acessado por uma conta da AWS nas regiões Leste/Oeste e GovCloud. Se tiver outras dúvidas sobre esse assunto, acesse o console.

Os arquivos carregados pelos serviços são verificados pela comparação da soma de verificação MD5 antes e depois do upload do arquivo.

Você pode usar fluxos de trabalho gerenciados pelo AWS Transfer Family para descriptografar automaticamente arquivos usando chaves PGP quando eles são carregados em seus endpoints de servidores SFTP, FTPS ou FTP do AWS Transfer Family. Para obter mais informações, consulte a documentação de fluxos de trabalho gerenciados. Como alternativa, você pode assinar as notificações de eventos do AWS Transfer Family publicadas no Amazon Eventbridge para orquestrar o processamento granular e orientado por eventos dos arquivos transferidos usando sua própria lógica de criptografia/descriptografia.

Você pode monitorar as atividades de transferência de arquivos de seus usuários finais usando logs formatados em JSON que são entregues ao Amazon CloudWatch. Você pode analisar e consultar seus logs no CloudWatch usando o CloudWatch Log Insights, que descobre automaticamente campos formatados em JSON. Você também pode acompanhar os principais usuários, o número total de usuários exclusivos e seu uso contínuo com o CloudWatch Contributor Insights. Também fornecemos métricas e gráficos pré-criados do CloudWatch que podem ser acessados no Console de Gerenciamento do AWS Transfer Family. Consulte a documentação para saber mais.

Sim. Você pode combinar fluxos de log de vários servidores do AWS Transfer Family em um único grupo de logs do CloudWatch. Isso permite que você crie métricas e visualizações de logs consolidadas, que podem ser adicionadas aos painéis do CloudWatch para monitorar o uso e a performance do servidor.

Execuções de fluxo de trabalho podem ser monitoradas usando as métricas do AWS CloudWatch, como o número total de execuções de fluxos de trabalho, execuções bem-sucedidas e execuções com falha. Usando o Console de Gerenciamento da AWS, você também pode pesquisar e visualizar o status em tempo real de execuções de fluxo de trabalho em andamento. Use logs do CloudWatch para obter registros em log detalhados das execuções de fluxos de trabalho.

O AWS Transfer Family gera logs em um formato JSON em todos os recursos, incluindo servidores, conectores e fluxos de trabalho, e em todos os protocolos, incluindo SFTP, FTPS, FTP e AS2.

Você pode usar os fluxos de trabalho gerenciados do Transfer Family para receber notificações de arquivos enviados pelos endpoints de servidores SFTP, FTPS e FTP. Consulte esta postagem do blog. Como alternativa, você pode se inscrever em eventos do AWS Transfer Family no Amazon EventBridge para receber notificações usando o Amazon Simple Notification Service (SNS).

Sim. Se a verificação de validação de um arquivo falhar nas etapas de validação de fluxo de trabalho, você poderá usar o manipulador de exceção para invocar o seu sistema de monitoramento ou alertar os membros da equipe por meio de um tópico do Amazon SNS.

A cobrança de cada protocolo habilitado é por hora, do momento em que você cria e configura o endpoint de servidor até o momento em que você o exclui. Você também recebe cobranças com base na quantidade de dados carregados e baixados nos seus servidores SFTP, FTPS ou FTP, no número de mensagens trocadas no AS2 e na quantidade de dados processados usando a etapa de fluxo de trabalho Descriptografar. Ao usar conectores SFTP, você é cobrado pela quantidade de dados transferidos e pelo número de chamadas de conectores. Consulte a página de preços para obter mais detalhes.

Não. Você será cobrado por hora para cada protocolo habilitado e pela quantidade de dados transferida por meio de cada um dos protocolos, independentemente do uso do mesmo endpoint para vários protocolos ou de endpoints diferentes para cada protocolo.

Sim. Interromper o servidor usando o console, ou executando o comando de ILC “stop-server” ou o comando de API “StopServer”, não afeta a cobrança. A cobrança de cada protocolo habilitado é por hora, do momento em que você cria o endpoint do servidor e configura o acesso a ele por meio de um ou mais protocolos até o momento em que você o exclui.

Você é cobrado pela etapa Descriptografar do fluxo de trabalho com base na quantidade de dados que descriptografar usando chaves PGP. Não há cobrança adicional pelo uso dos fluxos de trabalho gerenciados. Dependendo da configuração dos seus fluxos de trabalho, também há cobrança pelo uso do Amazon S3, Amazon EFS, AWS Secrets Manager e AWS Lambda.

Não, não há cobrança por hora para conectores SFTP. Para obter mais informações sobre preços de conectores SFTP, consulte a página de preços.