Domande frequenti su AWS Transfer Family

Sì. Puoi configurare il server Transfer Family per mostrare agli utenti banner personalizzati come politiche dell'organizzazione o termini e condizioni. Puoi inoltre visualizzare il messaggio personalizzato del giorno (MOTD) agli utenti che si sono autenticati con successo. Per ulteriori informazioni, consulta la documentazione.

Sì. Per impostazione predefinita, il servizio fornisce un nome di dominio per accedere all'endpoint. Se disponi già di un nome di dominio, puoi utilizzare Amazon Route 53 o qualsiasi servizio DNS che instradi il traffico degli utenti dal dominio registrato all'endpoint del server in AWS. Fai riferimento alla documentazione su come AWS Transfer Family utilizza Amazon Route 53 per i nomi di dominio personalizzati (applicabile solamente agli endpoint connessi a Internet).

Sì. Quando crei un server o ne aggiorni uno esistente, puoi specificare se vuoi che l'endpoint sia accessibile attraverso l'Internet pubblico oppure ospitato all'interno del tuo VPC. Utilizzando un endpoint VPC ospitato per il tuo server, puoi renderlo accessibile soltanto ai client all'interno dello stesso VPC, altri VPC da te specificati o in ambienti locali utilizzando tecnologie di rete che estendono il tuo VPC come AWS Direct Connect, AWS VPN o VPC peering. Puoi limitare ulteriormente l'accesso alle risorse in determinate sottoreti all'interno del VPC usando liste di controllo degli accessi alla rete (NACL, Network Access Control List) per la sottorete o gruppi di sicurezza. Per ulteriori informazioni, consulta la documentazione per creare un endpoint del server all'interno del VPC utilizzando AWS PrivateLink.

No, quando abiliti l'FTP, puoi utilizzare solo l'opzione di accesso interno dell'endpoint ospitato da VPC perché l'FTP trasmette i dati in testo non crittografato. Se il traffico dovrà attraversare la rete pubblica, dovresti utilizzare protocolli sicuri quali SFTP o FTPS.

No. Il VPC è un elemento obbligatorio per ospitare gli endpoint del server FTP. Consulta la documentazione per i modelli di CloudFormation per automatizzare la creazione di risorse VPC per ospitare gli endpoint durante la creazione dei server.

Sì. Puoi abilitare gli IP fissi per l'endpoint del server selezionando l'endpoint VPC ospitato per il server e scegliendo l'opzione di connessione a Internet. Ciò ti permetterà di allegare gli IP di Elastic (inclusi IP BYO) direttamente all’endpoint, il quale sarà assegnato come indirizzo IP dell’endpoint. Consulta la sezione sulla creazione di un endpoint connesso a Internet nella documentazione: Creazione di un endpoint del server all'interno del VPC.

Sì. Ci sono tre opzioni per limitare il traffico in entrata da parte di indirizzi IP sorgente degli utenti. Se stai ospitando l'endpoint del server all'interno del VPC, fai riferimento a questo post del blog sull'utilizzo dei gruppi di sicurezza per permettere di elencare gli indirizzi IP di origine o utilizzare il servizio Firewall di rete AWS. Se sei un server pubblico per il trasferimento EndpointType e API Gateway per integrare il tuo sistema di gestione delle identità, puoi anche utilizzare AWS WAF per consentire, bloccare o valutare l'accesso limitato da parte degli indirizzi IP sorgente degli utenti finali.

Sì. Puoi distribuire l'endpoint del server in ambienti VPC condivisi generalmente utilizzati quando si segmenta l'ambiente AWS utilizzando strumenti come AWS Landing Zone per la sicurezza, il monitoraggio dei costi e la scalabilità. Fai riferimento al post del blog sull'utilizzo di endpoint VPC ospitati in ambienti VPC condivisi con AWS Transfer Family.

Puoi utilizzare AWS Global Accelerator con l'endpoint del server di trasferimento per migliorare la velocità di trasmissione effettiva dei file e i tempi di andata/ritorno. Leggi questo post del blog per ulteriori informazioni.

Sì. In base ai tuoi requisiti di sicurezza e conformità, puoi selezionare una delle nostre politiche di sicurezza gestite dal servizio disponibili per controllare gli algoritmi crittografici che verranno pubblicizzati dagli endpoint del tuo server. Quando i client di trasferimento file degli utenti finali tentano di connettersi al tuo server, solo gli algoritmi specificati nella policy saranno utilizzati per negoziare la connessione. Fai riferimento alla documentazione sulle policy di sicurezza predefinite.

Sì. AWS Transfer Family supporta lo scambio di chiavi pubbliche sicuro dal punto di vista quantistico per i trasferimenti di file SFTP. È possibile associare una delle policy di sicurezza PQ ibride predefinite al server SFTP per consentire lo scambio di chiavi pubbliche sicuro dal punto di vista quantistico con client che supportano gli algoritmi di crittografia PQ.

No. Al momento, gli indirizzi IP fissi, in genere utilizzati per creare whitelist di firewall, non sono supportati sull'endpoint di tipo PUBBLICO. Utilizza endpoint VPC ospitati per assegnare indirizzi IP statici per il tuo endpoint.

Se utilizzi il tipo di endpoint PUBBLICO, gli utenti dovranno creare una lista di permessi degli intervalli di indirizzi IP di AWS pubblicati qui. Consulta la documentazione per i dettagli e gli aggiornamenti sugli intervalli di indirizzi IP di AWS.

No. La chiave host del server assegnata al momento della creazione del server resta invariata, a meno che non si aggiunga una nuova chiave host e si elimini manualmente la chiave originale.

I tipi di chiavi RSA, ED25519 ed ECDSA sono supportati per le chiavi host del server SFTP.

Sì. È possibile importare una chiave host quando si crea un server o importare più chiavi host quando si aggiorna un server. Fai riferimento alla documentazione sulla gestione delle chiavi host per il server abilitato per SFTP.

Sì. La chiave host più vecchia di ciascun tipo di chiave può essere utilizzata per verificare l'autenticità di un server SFTP. Aggiungendo le chiavi host RSA, ED25519 ed ECDSA, è possibile utilizzare 3 chiavi host separate per identificare il server SFTP.

La chiave host più vecchia di ciascun tipo di chiave può essere utilizzata per verificare l'autenticità del server SFTP.

Sì. È possibile ruotare le chiavi host del server SFTP in qualsiasi momento aggiungendo e rimuovendo le chiavi host. Fai riferimento alla documentazione sulla gestione delle chiavi host per il server abilitato per SFTP.

Quando attivi l'accesso FTPS, avrai bisogno di fornire un certificato dalla Gestione certificati Amazon (ACM). Questo certificato è utilizzato dai clienti dei tuoi utenti finali per verificare l'identità del tuo server FTPS. Consulta la documentazione di ACM su come richiedere nuovi certificati o importare certificati esistenti in ACM.

Supportiamo solo la modalità passiva, la quale permette ai client dei tuoi utenti finali di avviare delle connessioni con il tuo server. La modalità passiva richiede meno porte sul lato client, così che il tuo endpoint del server sia più compatibile con gli utenti finali al di là dei firewall protetti.

Supportiamo solo la modalità esplicita di FTPS.

Sì. I trasferimenti di file che attraversano un firewall o un router sono supportati di default utilizzando la modalità di connessione passiva estesa (EPSV). Se stai utilizzando un client FTPS/FTP che non supporta la modalità EPSV, leggi questo post del blog per configurare il server in modalità PASV ed espandere la compatibilità del server a un'ampia gamma di client.

Sì. Oltre alla porta standard 22, AWS Transfer Family supporta anche le porte alternative 2222 e 22000. Per impostazione predefinita, la porta 22 è configurata per i server SFTP. Per ottimizzare la sicurezza del server, puoi configurare il traffico SSH in modo che utilizzi la porta 22, la porta 2222 o entrambe. Consultare la documentazione in questa pagina.

Le app Web di AWS Transfer Family sono portali completamente gestiti, personalizzabili, sicuri e affidabili che consentono di fornire agli utenti finali un'interfaccia semplice per il trasferimento dei dati da e verso Amazon S3 tramite un browser web.

Puoi iniziare a utilizzare le app Web per abilitare una semplice interfaccia Web in modo che gli utenti finali possano sfogliare, caricare e scaricare i dati archiviati in Amazon S3 in tre semplici passaggi. Innanzitutto, crea un'istanza di Identity Center utilizzando la directory Identity Center, Microsoft Active (AD) o un gestore dell'identità digitale (IdP) di terze parti come Okta o Entra ID. Quindi, nella console Transfer Family, crea un'app Web e assegna i tuoi utenti e gruppi dalla tua directory per utilizzare l'applicazione. Infine, configura le autorizzazioni utente o di gruppo in S3 Access Grants. Per ulteriori informazioni, consulta il blog o la documentazione.

No. Le app Web e i server Transfer Family sono risorse separate e autonome non connesse. Crei un'app Web indipendente da un server. 

Le app Web supportano il Centro identità AWS IAM. Grazie al Centro identità IAM, è possibile creare e gestire le identità utente nell’archivio identità del Centro identità IAM o collegare facilmente l’origine identità esistente come Microsoft Active Directory, Okta Universal Directory, Microsoft Entra ID (in precedenza Azure AD) o un altro gestore dell’identità digitale supportato. È possibile connettere il Centro identità IAM alla maggior parte dei gestori dell’identità digitale SAML 2.0, come Okta Universal Directory o Microsoft Entra ID (in precedenza Azure AD). Consulta la documentazione di IAM Identity Center per saperne di più.

È necessario effettuare il provisioning delle identità fornite dal gestore dell'identità digitale nel Centro identità IAM prima di poter assegnare le autorizzazioni. È possibile sincronizzare automaticamente le informazioni su utenti e gruppi da Okta Universal Directory, Microsoft Entra ID (in precedenza Azure AD), OneLogin e PingFederate utilizzando lo standard SCIM (System for Cross-domain Identity Management). Per altri gestori dell’identità digitale, è possibile effettuare il provisioning di utenti dal proprio gestore dell'identità digitale utilizzando la console del Centro identità IAM. Consulta la documentazione di IAM Identity Center per saperne di più.

Sì. È possibile connettere IAM Identity Center ad Active Directory (AD) on-premise o a un AWS Managed Microsoft AD Directory utilizzando il servizio di directory AWS. Consulta la documentazione di IAM Identity Center per saperne di più.

Puoi utilizzare le app Web Transfer Family per trasferire file da o verso Amazon S3.

Le app Web offrono a ciascun utente finale una vista unica delle posizioni e delle autorizzazioni S3 definite in S3 Access Grants. Mentre l'utente naviga, carica e scarica oggetti, l'app Web utilizza credenziali IAM temporanee emesse da S3 Access Grants per accedere in modo sicuro ai dati in S3. Per saperne di più su S3 Access Grants, consulta la Guida per l'utente di S3.

I controlli di accesso alle app Web sono gestiti da S3 Access Grants, che offre tre livelli di accesso: READ, WRITE e READWRITE. Questi livelli di accesso consentono azioni autorizzate correlate come elencare, caricare, scaricare e copiare i file. READ consente di visualizzare e recuperare oggetti da S3. WRITE consente di scrivere ed eliminare da S3. READWRITE consente di eseguire sia READ che WRITE. 

Sì. Puoi personalizzare il portale Web aggiornando il logo aziendale, la favicon e il titolo della pagina nella console di AWS Transfer Family o utilizzando l'interfaccia a riga di comando o l'API AWS.

Sì. Puoi utilizzare Amazon CloudFront per associare un nome di dominio personalizzato alla tua app Web. Puoi anche personalizzare l'URL di accesso al portale delle applicazioni Identity Center tramite AWS IAM Identity Center se prevedi di condividere più applicazioni AWS con i tuoi utenti finali.

I tuoi utenti possono essere autorizzati a elencare, caricare, scaricare, copiare ed eliminare file a seconda dell'accesso loro concesso in S3 Access Grants e nei ruoli IAM. Per ulteriori informazioni sulla gestione dei controlli di accesso, consulta la documentazione. 

Storage Browser per S3 è un componente open source che puoi aggiungere alle tue applicazioni web per fornire agli utenti finali un'interfaccia semplice per i dati archiviati in S3. Le app Web sono create utilizzando il browser di archiviazione per S3 e offrono le stesse funzionalità per l'utente finale in un'offerta completamente gestita.

No. È possibile avere una sola directory o un solo gestore dell'identità digitale SAML 2.0 collegato contemporaneamente a IAM Identity Center. Tuttavia, è possibile cambiare l'origine identità collegata a un'altra.

È possibile autenticare le connessioni ai server remoti utilizzando coppie di chiavi o password SSH o entrambe, a seconda dei requisiti del server remoto. Per ulteriori informazioni sull'archiviazione e la gestione delle credenziali di autenticazione del connettore nel tuo account AWS Secrets Manager, consulta la documentazione. 

È possibile trasferire file da o verso Amazon S3 a server SFTP remoti utilizzando connettori SFTP.

Sono supportati gli algoritmi delle chiavi host RSA ed ECDSA. Per maggiori dettagli sui tipi di chiave supportati, consulta la documentazione qui.  

Il connettore utilizza l'impronta digitale dell'host per convalidare l'identità del server remoto. Se l'impronta digitale fornita dal server remoto non corrisponde a quella caricata nella configurazione del connettore, la connessione fallisce e i dettagli dell'errore vengono registrati in CloudWatch. Per ulteriori informazioni su come caricare la parte pubblica della chiave SSH di un server remoto per l'identificazione, consulta la documentazione sui connettori SFTP qui.

Sì. Puoi effettuare il provisioning dei bucket Amazon S3 e delle risorse del connettore SFTP in diversi account AWS.

Sì. In base ai tuoi requisiti di sicurezza e compatibilità, puoi selezionare una delle nostre policy di sicurezza gestite dal servizio disponibili per controllare gli algoritmi crittografici che verranno pubblicizzati dal tuo connettore SFTP. Quando il tuo connettore tenta di connettersi al server remoto, per negoziare la connessione verranno utilizzati solo gli algoritmi specificati nella policy allegata al connettore. Fai riferimento alla documentazione sulle policy di sicurezza predefinite.

Sì. È possibile creare un connettore SFTP in un account AWS e utilizzarlo per trasferire file da un altro account fornendo le autorizzazioni di accesso adeguate nel ruolo IAM collegato al connettore.

È possibile testare la connettività al server remoto utilizzando la Console di gestione AWS o il comando TestConnection API/CLI/CDK. Ti consigliamo di testare la connettività al server remoto non appena crei il connettore per assicurarti che sia configurato correttamente. Assicurati che gli indirizzi IP statici associati ai connettori siano consentiti dal server remoto, se necessario. Per ulteriori informazioni, consulta la documentazione sui connettori SFTP.

I connettori SFTP possono essere utilizzati per inviare file da Amazon S3 a un server SFTP remoto, recuperare file da un server SFTP remoto ad Amazon S3 e elencare i file memorizzati in una directory su un server SFTP remoto. Per saperne di più sull'uso dei connettori SFTP, consulta la documentazione dei connettori SFTP.

È possibile elencare i file archiviati in una directory su server SFTP remoti utilizzando l'operazione API StartDirectoryListing dei connettori SFTP. A questo punto, sarà possibile recuperare i file di destinazione dal server remoto passando i nomi dei file dall'elenco quando si utilizza l'operazione API StartFileTransfer per trasferire i file. Per ulteriori informazioni, consultare la soluzione di esempio per la sincronizzazione di nuovi file da server SFTP remoti o partecipare al workshop MFT di autoapprendimento.

È possibile elencare tutti i file da una directory sul server SFTP remoto utilizzando i connettori SFTP e creare una logica personalizzata per filtrare l'elenco dei file in base ai criteri jolly per i modelli di nome file. È quindi possibile utilizzare l'operazione API StartFileTransfer per trasferire tali file utilizzando i connettori SFTP.

È possibile monitorare lo stato corrente delle operazioni di trasferimento file utilizzando il comando API ListFileTransferResults. Inoltre, i connettori SFTP emettono log dettagliati in Amazon CloudWatch, tra cui lo stato dei trasferimenti file, il tipo di operazione (invio o recupero), il timestamp, il percorso del file e l'eventuale descrizione degli errori per aiutarti a mantenere la derivazione dei dati. 

Sì. Puoi pianificare i trasferimenti file utilizzando Pianificatore Amazon EventBridge. Crea una pianificazione che soddisfi le esigenze della tua azienda utilizzando il Pianificatore EventBridge e specifica l'API StartFileTransfer o l'API StartDirectoryListing di AWS Transfer Family come destinazione universale per la tua pianificazione.

Sì. AWS Step Functions si integra con vari servizi AWS, tra cui AWS Transfer Family, consentendoti di richiamare l'operazione StartFileTransfer del connettore SFTP direttamente dalla tua macchina a stati. Dopo aver creato il connettore SFTP con AWS Transfer Family, sfrutta le integrazioni SDK AWS di Step Functions per chiamare l'API StartFileTransfer. Per saperne di più su come orchestrare i flussi di lavoro di trasferimento ed elaborazione dei file utilizzando AWS Step Functions e connettori SFTP, è possibile partecipare al workshop MFT basato su eventi e autogestito.

Sì. Ogni operazione di trasferimento file tramite connettori SFTP pubblica una notifica di evento nel router degli eventi predefinito su Amazon EventBridge. È possibile abbonarsi agli eventi del connettore SFTP e utilizzarli per orchestrare l'elaborazione basata sugli eventi dei file trasferiti utilizzando Amazon EventBridge o qualsiasi altro servizio di orchestrazione del flusso di lavoro a scelta che si integri con questi eventi.

Sì. Per impostazione predefinita, gli indirizzi IP statici sono associati ai connettori e possono essere utilizzati per aggiungere all’elenco elementi consentiti le connessioni sul firewall del tuo partner commerciale. È possibile identificare gli indirizzi IP statici associati ai connettori accedendo alla pagina dei dettagli del connettore nella Console di AWS Transfer Family o utilizzando il comando DescribeConnector API/CLI/CDK.

Sì. Tutti i connettori SFTP in una regione dell'account AWS condivideranno un set di indirizzi IP statici. La condivisione di indirizzi IP tra connettori di un determinato tipo riduce la quantità di documentazione sugli elenchi di elementi consentiti e le comunicazioni di onboarding necessarie con i partner esterni.

No. Al momento, i connettori SFTP possono essere utilizzati solo per connettersi a server che offrono un endpoint accessibile tramite Internet. Se devi connetterti a server accessibili soltanto tramite una rete privata, contattaci tramite il Supporto AWS o il team dell'account AWS.

Sì. Durante la configurazione, puoi selezionare il protocollo o i protocolli che desideri attivare per i client che si connetteranno al tuo endpoint. Il nome dell'host del server, l'indirizzo IP e il gestore dell'identità digitale vengono condivisi attraverso i protocolli selezionali. Analogamente, è anche possibile abilitare il supporto di protocolli aggiuntivi agli endpoint AWS Transfer Family esistenti, purché la configurazione dell'endpoint soddisfi i requisiti per tutti i protocolli che si intende utilizzare.

Quando hai bisogno di utilizzare l'FTP (solo supportato per l'accesso all'interno del VPC) e devi supportare SFTP, AS2 o FTPS su Internet, avrai bisogno di un endpoint del server separato per l'FTP. È possibile utilizzare lo stesso endpoint per più protocolli quando si desidera utilizzare lo stesso nome dell'host e lo stesso indirizzo IP dell'endpoint per i client che si connettono attraverso più protocolli. Inoltre, se desideri condividere le stesse credenziali per l’SFTP e l’FTPS, puoi impostare e utilizzare un singolo fornitore di identità per autenticare i client che si connettono attraverso uno dei due protocolli.

Sì. Puoi fornire allo stesso utente l'accesso su più protocolli, purché le credenziali specifiche del protocollo siano state impostate nel tuo provider di identità. Se hai attivato l'FTP, ti consigliamo di utilizzare delle credenziali diverse. Consulta la documentazione per scoprire come impostare credenziali separate per l’FTP.

A differenza dei protocolli SFTP e FTPS, l’FTP trasmette le credenziali in testo semplice. Consigliamo di isolare le credenziali FTP da quelle dei protocolli SFTP o FTPS perché, qualora le credenziali FTP vengano inavvertitamente esposte o condivise, i tuoi carichi di lavoro che utilizzano SFTP o FTPS rimarranno sicuri.

Sì. È possibile implementare questa soluzione open source che permette di fornire un'interfaccia basata sul browser tramite gli endpoint SFTP di AWS Transfer Family.

Il servizio supporta tre opzioni di gestore dell'identità digitale: servizio gestito, dove si archiviano le identità degli utenti all'interno del servizio; Microsoft Active Directory e gestori dell'identità digitale personalizzati, che consentono di integrare un gestore di tua scelta. L’autenticazione Service Managed è supportata per gli endpoint del server abilitati solo per l’SFTP.

Puoi utilizzare la modalità di autenticazione gestita dal servizio per autenticare i tuoi utenti SFTP che utilizzano chiavi SSH.

È possibile caricare fino a 10 chiavi SSH per utente. Sono supportate le chiavi RSA, ED25519 ed ECDSA.

Sì. Consulta la documentazione per ulteriori informazioni su come impostare la rotazione delle chiavi per i tuoi utenti SFTP.

Quando crei il tuo server, selezioni una directory in Microsoft AD gestito da AWS, il tuo ambiente on-premise, o AD gestito dal cliente in Amazon EC2 come gestore dell'identità digitale. Dovrai poi specificare i gruppi AD che vuoi abilitare per l'accesso usando un identificatore di sicurezza (SID, Security Identifier). Una volta associato il tuo gruppo AD con le informazioni di controllo dell'accesso come il ruolo IAM, una policy scope down per restringere l'ambito di applicazione (solo S3), POSIX Profile (solo EFS), posizione della home directory e mappature delle directory logiche, i membri del gruppo possono usare le loro credenziali AD per autenticarsi e trasferire file sui protocolli abilitati (SFTP, FTPS, FTP). 

Quando imposti i tuoi utenti, fornisci una policy scope down che viene valutata in runtime in base alle informazioni dei tuoi utenti, come il loro nome utente. Puoi usare la stessa policy di scope down per tutti i tuoi utenti per fornire l'accesso a prefissi unici nel tuo bucket in base al loro nome utente. Inoltre, un nome utente può anche essere utilizzato per valutare le mappature logiche delle directory, fornendo un modello standardizzato su come il tuo bucket S3 o il contenuto del file system EFS sono visibili all'utente. Per maggiori informazioni, consulta la documentazione su come concedere l'accesso a gruppi AD.

Sì. È possibile utilizzare Microsoft AD per autenticare gli utenti per l'accesso tramite SFTP, FTPS e FTP.

Sì. È possibile revocare l'accesso al trasferimento file per singoli gruppi AD. Una volta revocati, i membri dei gruppi AD non saranno in grado di trasferire file utilizzando le loro credenziali AD.

La modalità personalizzata (autenticazione "BYO") ti permette di utilizzare un provider di identità esistente per gestire i tuoi utenti finali per tutti i tipi di protocollo (SFTP, FTPS e FTP), consentendoti di migrare in modo facile e semplice i tuoi utenti. Le credenziali possono essere archiviate nella tua directory aziendale o in un datastore di identità in locale, con la possibilità di integrarlo per fini di autenticazione degli utenti finali. Esempi di gestori dell'identità digitale includono Okta, Microsoft AzureAD o qualsiasi gestore personalizzato che potresti utilizzare come parte di un portale di provisioning generale.

Per integrare il tuo gestore dell'identità digitale con un server AWS Transfer Family, puoi utilizzare una funzione AWS Lambda o un endpoint Gateway Amazon API. Utilizza Amazon API Gateway se hai bisogno di un'API RESTful da connettere a un provider di identità o se desideri sfruttare le funzioni di blocco geografico e limitazione dei tassi di AWS WAF. Consulta la documentazione per ulteriori informazioni sull'integrazione dei gestori dell'identità digitale più comuni come AWS Cognito, Okta e AWS Secrets Manager.

Sì. Quando utilizzi AWS Lambda o l'API Gateway per connetterti a un provider di identità personalizzato, la fonte IP del client passa al tuo provider di identità. In questo modo puoi permettere, negare o limitare l'accesso in base agli indirizzi IP dei client per assicurati che solo gli indirizzi IP che hai specificato come affidabili possano accedere ai tuoi dati.

Sì. È possibile applicare diversi metodi di autenticazione per fornire un ulteriore livello di sicurezza quando si accede ai dati tramite SFTP. Il tuo server SFTP può essere configurato per richiedere sia la password che la chiave SSH, la password o la chiave SSH, solo la password o solo la chiave SSH. Consulta la documentazione per i dettagli su come abilitare più metodi di autenticazione utilizzando il gestore dell'identità del tuo cliente.

No. L'archiviazione delle password all'interno del servizio ai fini dell'autenticazione non è attualmente supportata. Se hai bisogno dell'autenticazione tramite password, utilizza Active Directory selezionando una directory in Servizio di directory AWS o segui l'architettura descritta nel blog sull'abilitazione dell'autenticazione tramite password utilizzando Secrets Manager.

No. Al momento gli utenti anonimi non sono supportati per nessun protocollo.

No. Supportiamo solo l'impostazione dell'accesso da parte dei gruppi AD.

No. Il supporto di AWS Transfer Family per Microsoft AD può essere utilizzato solo per l'autenticazione basata su password. Per usare più di modalità di autenticazione, utilizza l'opzione Autorizzazioni ad hoc.

Sì. Il supporto di AWS Transfer Family per AS2 ha ricevuto il sigillo di certificazione ufficiale del cloud AS2 di Drummond Group. Le funzionalità AS2 di AWS Transfer Family sono state accuratamente verificate per la sicurezza e la compatibilità dello scambio di messaggi con altre 14 soluzioni AS2 di terze parti. Per ulteriori informazioni, leggi il nostro annuncio.

Il tuo partner commerciale è identificato in modo univoco mediante l'uso del suo codice identificativo AS2 (ID AS2). Allo stesso modo, il tuo partner commerciale è in grado di identificare i tuoi messaggi usando il tuo ID AS2.

È possibile utilizzare il supporto esistente di AWS Transfer Family per Amazon S3, le funzionalità di rete (endpoint VPC, gruppi di sicurezza e IP elastici) e i controlli di accesso (AWS IAM) per AS2, come per SFTP, FTPS e FTP. L'autenticazione degli utenti, le directory logiche, i banner personalizzati e Amazon EFS come backend di archiviazione non sono supportati per AS2.

Il non ripudio, esclusivo di AS2, attesta che il messaggio è stato scambiato con successo tra due parti. Il non ripudio in AS2 si ottiene utilizzando le notifiche Message Disposition Notification (MDN). Quando viene richiesta una MDN in una transazione, si assicura che il mittente abbia inviato il messaggio, che il destinatario lo abbia ricevuto con successo e che il messaggio inviato dal mittente sia lo stesso ricevuto dal destinatario.

La trasmissione dei messaggi presenta due aspetti: quello del mittente e quello del destinatario. Una volta che il mittente ha stabilito quale messaggio inviare, il messaggio viene firmato (utilizzando la chiave privata del mittente), crittografato (utilizzando il certificato del destinatario) e l'integrità del messaggio viene calcolata utilizzando un hash. Questo messaggio firmato e crittografato viene trasmesso via cavo al destinatario. Una volta ricevuto, il messaggio viene decifrato (utilizzando la chiave privata del destinatario), convalidato (utilizzando la chiave pubblica del mittente), elaborato e, se richiesto, viene inviata al mittente una Message Disposition Notification (MDN) firmata per confermare l'avvenuta consegna del messaggio. Consulta la documentazione su come AS2 gestisce la trasmissione dei messaggi.

La combinazione di opzioni possibili è determinata dal punto di vista del mittente. Il mittente può scegliere di crittografare o firmare i dati (o entrambi) e di richiedere una Message Disposition Notification (MDN). Se il mittente sceglie di richiedere una MDN, può richiederne una firmata o non firmata. Il destinatario è tenuto a rispettare queste opzioni.

Sì. Il mittente può scegliere di richiedere un'MDN, specificare se desidera ricevere un'MDN firmata o non firmata, nonché selezionare gli algoritmi di firma da utilizzare per firmare l'MDN.

Attualmente supportiamo risposte MDN sincrone e asincrone. Ciò consente di rispondere ai partner commerciali con un MDN sincrono o asincrono dopo aver ricevuto un messaggio AS2. Poiché le MDN sincrone vengono inviate sullo stesso canale di connessione del messaggio, è l'opzione molto più semplice, quindi quella consigliata. Se si ha bisogno di più tempo per elaborare il messaggio prima di inviare una MDN, è preferibile utilizzare le MDN asincrone. Se hai bisogno di richiedere e ricevere MDN asincroni quando invii messaggi ai tuoi partner commerciali, contattaci tramite il Supporto AWS o il tuo account manager.

AWS Transfer Family estrae le informazioni chiave AS2 dal payload e dalle MDN scambiati e le archivia sotto forma di file JSON nel bucket Amazon S3. È possibile interrogare questi file JSON utilizzando S3 Select o Amazon Athena, oppure indicizzare i file utilizzando Amazon OpenSearch o Amazon DocumentDB per l'analisi.

Sì. Una volta ricevuta un'MDN dal partner commerciale, il servizio convalida l'MDN utilizzando il tuo certificato e memorizza il messaggio nel tuo bucket Amazon S3. È possibile scegliere di archiviare il messaggio sfruttando le policy del ciclo di vita S3.

Una volta che i dati sono pronti per la consegna, dovrai richiamare l'API StartFileTransfer utilizzando il connettore AS2 che contiene le informazioni sul server AS2 del destinatario. Questo notificherà al servizio l'invio del messaggio al server del partner commerciale. Consulta la documentazione sui connettori per inviare messaggi al partner commerciale tramite AS2.

Sì. Quando si imposta il profilo del partner commerciale, è possibile utilizzare cartelle diverse per ciascuno di essi.

Sì. È possibile importare le chiavi e i certificati esistenti di un partner e gestire i rinnovi e le rotazioni. Consulta la documentazione sull'importazione di certificati.

Utilizzando la console AWS Transfer Family, è possibile visualizzare un pannello di controllo dei certificati ordinati in base alla data di scadenza. Inoltre è possibile scegliere di ricevere le notifiche prima della scadenza del certificato, in modo da avere il tempo sufficiente per modificarle ed evitare interruzioni delle operazioni.

Sì. Per impostazione predefinita, gli indirizzi IP statici sono associati ai connettori e possono essere utilizzati per aggiungere all’elenco elementi consentiti le connessioni sul server AS2 del tuo partner commerciale. È possibile identificare gli indirizzi IP statici associati ai connettori accedendo alla pagina dei dettagli del connettore nella Console di AWS Transfer Family o utilizzando il comando DescribeConnector API/CLI/CDK.

Sì. Supportiamo la possibilità di connettersi al server AS2 di un partner commerciale utilizzando l'autenticazione di base. Consulta la documentazione sulla configurazione dell'autenticazione di base sui connettori AS2.

Sì. I connettori AS2 utilizzano indirizzi IP statici per l'invio di messaggi a server AS2 remoti e per la restituzione di risposte MDN (notifica di disposizione dei messaggi) asincrone. È possibile identificare gli indirizzi IP statici associati ai connettori accedendo alla pagina dei dettagli del connettore o del server nella Console di gestione AWS Transfer Family o utilizzando i comandi DescribeConnector o DescribeServer API/CLI/CDK.

Sì. Gli endpoint del server AS2 supportano la configurazione dei controlli degli elenchi di indirizzi IP consentiti utilizzando gruppi di sicurezza con endpoint connessi a Internet e ospitati su VPC.

Sì. Le tue risposte MDN asincrone AS2 utilizzeranno indirizzi IP statici. È possibile identificare gli indirizzi IP statici utilizzati per inviare le risposte MDN asincrone accedendo alla pagina dei dettagli del server nella Console di gestione di AWS Transfer Family o utilizzando il comando DescribeServer API/CLI/CDK.

Ogni messaggio AS2 ricevuto pubblica un evento sul router di eventi predefinito su Amazon EventBridge. È possibile iscriversi a questi eventi e utilizzarli per orchestrare l'elaborazione basata sugli eventi dei messaggi ricevuti utilizzando Amazon EventBridge o qualsiasi altro servizio di orchestrazione del flusso di lavoro. Ad esempio, è possibile utilizzare questi eventi per copiare i messaggi in arrivo in altre posizioni in S3, ricercare malware nel contenuto dei messaggi utilizzando una Lambda personalizzata o contrassegnare i messaggi in base al loro contenuto in modo che possano essere indicizzati e ricercati da servizi come Amazon CloudSearch.

Sì. È possibile trasformare automaticamente i contenuti EDI X12 dei messaggi AS2 in entrata in rappresentazioni di dati comuni come JSON e XML utilizzando AWS B2B Data Interchange. A tale scopo, crea una regola Amazon EventBridge che corrisponda al modello di evento dell'evento AS2 Payload Receive Completed di AWS Transfer Family e specifichi l'API StartTransformerJob di AWS B2B Data Interchange come obiettivo universale per la regola. Trasformando i contenuti EDI X12 dei messaggi AS2 in entrata con AWS B2B Data Interchange, è possibile automatizzare e accelerare l'integrazione dei dati EDI nelle applicazioni e nei sistemi aziendali a valle.

È possibile automatizzare l'invio di messaggi AS2 programmandoli con il Pianificatore Amazon EventBridge o attivandoli utilizzando le regole di Amazon EventBridge. Per creare flussi di lavoro automatizzati e basati sul tempo per l'invio di messaggi AS2, crea una pianificazione che soddisfi le esigenze aziendali utilizzando il Pianificatore EventBridge e specifica l'API StartFileTransfer di AWS Transfer Family come destinazione universale per la pianificazione. Per creare flussi di lavoro automatizzati e basati sugli eventi per l'invio di messaggi AS2, crea una regola Amazon EventBridge che corrisponda agli eventi pubblicati su EventBridge e specifica l'API StartFileTransfer di AWS Transfer Family come destinazione universale per la regola.

Sì. Ogni messaggio AS2 e MDN inviato pubblica un evento sul router degli eventi predefinito su Amazon EventBridge. È possibile iscriversi a questi eventi e utilizzarli per eliminare o archiviare i messaggi AS2 e MDN inviati con successo al proprio partner commerciale.

Sì. AWS Transfer Family pubblica eventi su Amazon EventBridge per ogni messaggio AS2 o MDN inviato e ricevuto con successo o meno. Questi eventi vengono pubblicati sul router di eventi predefinito su Amazon EventBridge, dove è possibile utilizzarli per attivare notifiche e-mail all'utente o ai suoi partner che utilizzano servizi come Amazon SNS.

No. Attualmente, i flussi di lavoro gestiti non sono supportati per gli endpoint AS2. Consigliamo di utilizzare le notifiche degli eventi di Transfer Family pubblicate su Amazon EventBridge per orchestrare l'elaborazione dei messaggi AS2. Per maggiori dettagli, consulta la sezione Automazione dell'elaborazione dei file.

No. AWS Transfer Family al momento non offre supporto per AS3 o AS4.

Ci sono due opzioni: 1) AWS Transfer Family pubblica notifiche di eventi di trasferimento file su Amazon EventBridge per i file trasferiti tramite SFTP, AS2, FTPS ed FTP, consentendo di utilizzare questi eventi per attivare l'elaborazione dei file utilizzando qualsiasi servizio in grado di integrarsi con gli eventi EventBridge; 2) AWS Transfer Family fornisce flussi di lavoro gestiti per semplificare l'esecuzione automatica dell'elaborazione post-caricamento dei file caricati su endpoint di server SFTP, FTPS ed FTP utilizzando fasi di elaborazione dei file predefinite. Associando un flusso di lavoro gestito all'endpoint del server, tutti i file caricati su quell'endpoint vengono elaborati utilizzando le stesse fasi del flusso di lavoro.

AWS Transfer Family pubblica notifiche di eventi su Amazon EventBridge in seguito al completamento riuscito o non riuscito di ciascuna operazione di trasferimento file, sia per le risorse del server che per quelle del connettore. Per ulteriori informazioni sugli eventi di Transfer Family pubblicati su Amazon EventBridge, consulta la documentazione. 

Se hai bisogno di elaborare i file che scambi con i tuoi partner commerciali, è necessario configurare un'infrastruttura per eseguire codice personalizzato, monitorare continuamente le anomalie e gli errori di runtime e assicurarti che tutte le modifiche e le trasformazioni dei dati siano controllate e registrate. Inoltre, occorre tener conto degli scenari di errore, sia tecnici che aziendali, assicurando che siano correttamente attivate modalità a prova di errore. Se hai esigenze di tracciabilità, è necessario tracciare la derivazione dei dati man mano che passano lungo diversi componenti del sistema. Il mantenimento di componenti separati di un flusso di lavoro di elaborazione dei file richiede tempo che altrimenti potresti dedicare alla differenziazione della propria attività sul mercato. I flussi di lavoro gestiti eliminano la complessità della gestione di più attività e forniscono una soluzione di elaborazione dei file standardizzata che può essere replicata in tutta l'organizzazione, con gestione delle eccezioni integrata e tracciabilità dei file per ogni fase, in modo tale da aiutarti a soddisfare i requisiti aziendali e legali.

I flussi di lavoro gestiti di AWS Transfer Family forniscono un framework predefinito per creare, eseguire e monitorare una sequenza lineare di passaggi per l'elaborazione dei file caricati su endpoint di server SFTP, FTPS ed FTP. Utilizzando questa funzionalità, è possibile risparmiare tempo con passaggi predefiniti per eseguire comuni attività di elaborazione dei file come la copia, l'etichettatura e la decrittografia dei file. Inoltre, è possibile personalizzare l'elaborazione dei file utilizzando una funzione lambda per attività come la scansione dei file alla ricerca di informazioni personali, virus/malware o altri errori come formato o tipo di file errati, consentendo di rilevare rapidamente le anomalie e soddisfare i requisiti di conformità. Associando un flusso di lavoro gestito all'endpoint del server, tutti i file caricati su quell'endpoint vengono elaborati utilizzando le stesse fasi del flusso di lavoro.

I flussi di lavoro gestiti consentono di pre-elaborare facilmente i dati prima che vengano consumati dalle applicazioni a valle eseguendo una sequenza lineare di attività di elaborazione dei file per tutti i file caricati sugli endpoint del server, come lo spostamento dei file caricati in cartelle specifiche dell'utente, la decrittografia dei file tramite chiavi PGP, la scansione dei malware e l'etichettatura. Puoi implementare flussi di lavoro utilizzando Infrastruttura come codice (IaC), consentendo così di replicare e standardizzare rapidamente le comuni attività di elaborazione dei file post-caricamento che si estendono su più unità aziendali nell'organizzazione. È possibile effettuare un controllo granulare associando un flusso di lavoro gestito all'endpoint del server che viene attivato solo sui file caricati completamente e associandone uno separato che viene attivato solo per i file caricati parzialmente per elaborare i caricamenti incompleti. Inoltre, i flussi di lavoro offrono la gestione integrata delle eccezioni che consente di reagire facilmente ai risultati dell'elaborazione dei file in caso di errori o eccezioni nell'esecuzione del flusso di lavoro, contribuendo a mantenere gli accordi SLA tecnici e aziendali. Ogni fase di elaborazione dei file del flusso di lavoro produce anche log dettagliati, che possono essere controllati per tracciare la derivazione dei dati.

Gli endpoint e i connettori del server di AWS Transfer Family pubblicano notifiche di eventi su Amazon EventBridge in automatico al termine di un'operazione di trasferimento file, insieme a informazioni operative come posizione del file, nome utente del mittente, ID del server o del connettore, stato del trasferimento, ecc. È possibile utilizzare questi eventi quando è necessario un controllo granulare nella definizione dell'elaborazione dei file, ad esempio utilizzando la logica condizionale basata sull'origine del file, o quando è necessario creare architetture basate sugli eventi da integrare con altri servizi AWS, applicazioni di terze parti e applicazioni di proprietà. Invece, i flussi di lavoro gestiti da AWS Transfer Family forniscono un framework predefinito per definire una sequenza lineare dei comuni passaggi di elaborazione dei file che vengono applicati a tutti i file caricati sugli endpoint di server SFTP, FTPS ed FTP. È possibile associare all'endpoint un flusso di lavoro gestito quando è necessario elaborare tutti i file caricati utilizzando gli stessi comuni passaggi di elaborazione dei file senza dover applicare alcuna logica granulare o condizionale.

Innanzitutto, abilita il flusso di lavoro a contenere azioni come la copia, l'aggiunta di tag, e una serie di operazioni che possono includere un'azione personalizzata all'interno di una sequenza di passaggi in base alle tue necessità. Associa poi il flusso di lavoro a un server, in modo tale che, all'arrivo di un file, le operazioni specificate in tale flusso di lavoro siano valutate e attivate in tempo reale. Per ulteriori informazioni, consulta la documentazione, guarda questa demo su come iniziare a utilizzare i flussi di lavoro gestiti o implementa una piattaforma di trasferimento di file nativa del cloud utilizzando questo post del blog.

Sì. Lo stesso flusso di lavoro può essere associato a più server, in modo che sia più facile mantenere e standardizzare le configurazioni.

Sì. È possibile configurare una fase del flusso di lavoro per elaborare il file originariamente caricato o il file di output della fase precedente del flusso di lavoro. Ciò ti consente di automatizzare facilmente lo spostamento e la ridenominazione dei file dopo che sono stati caricati in Amazon S3. Ad esempio, per spostare un file in un percorso diverso per l'archiviazione o la conservazione, è necessario configurare due passaggi nel flusso di lavoro. Il primo passaggio consiste nel copiare un file in un percorso Amazon S3 diverso, il secondo nell'eliminare il file originariamente caricato. Consulta la documentazione per maggiori dettagli sulla selezione di un percorso di file per i passaggi del flusso di lavoro.

Una volta che un server di trasferimento ha ricevuto un file da un client, sono disponibili le seguenti operazioni comuni:

Decrittografia del file con chiavi PGP. Fai riferimento a questo post del blog sulla crittografia e la decrittografia dei file utilizzando PGP.

Spostamento o copia dei dati dal posto in cui arrivano al posto in cui devono essere utilizzati.

Eliminare il file originale dopo l'archiviazione o la copia in una nuova posizione.

Aggiungere tag al file in base ai suoi contenuti, in modo da poterlo indicizzare e ricercare tramite servizi a valle (solo per S3)

Qualunque logica personalizzata di elaborazione dei file, fornendo la tua funzione Lambda come fase personalizzata per il flusso di lavoro. Ad esempio, controllare la compatibilità del tipo di file, scansionare i file alla ricerca di malware, rilevare le informazioni di identificazione personale (PII) ed estrarre i metadati prima di importare i file per l'analisi dei dati.

Sì. È possibile utilizzare una fase del flusso di lavoro predefinita e completamente gestita per la decrittografia PGP dei file caricati sugli endpoint di server SFTP, FTPS ed FTP. Per ulteriori informazioni, consulta la documentazione relativa ai flussi di lavoro gestiti e questo post del blog sulla crittografia e la decrittografia dei file tramite PGP.

È possibile configurare una fase del flusso di lavoro per elaborare il file originariamente caricato sull'endpoint del server o il file di output della fase precedente in un flusso di lavoro. Ciò ti consente di automatizzare facilmente lo spostamento e la ridenominazione dei file dopo che sono stati caricati in Amazon S3. Ad esempio, per spostare un file in un percorso diverso per l'archiviazione o la conservazione, è necessario configurare due passaggi nel flusso di lavoro. Il primo passaggio consiste nel copiare un file in un percorso Amazon S3 diverso, il secondo nell'eliminare il file originariamente caricato. Per maggiori dettagli sulla selezione di un percorso di file per i passaggi del flusso di lavoro, consulta la documentazione.

Sì. Utilizzando i flussi di lavoro gestiti, è possibile creare più copie del file originale, preservandolo al contempo per la conservazione dei record.

Sì. Puoi utilizzare il nome utente come variabile nelle fasi di copia dei flussi di lavoro, avendo la possibilità di instradare dinamicamente i file a cartelle specifiche dell'utente in Amazon S3. Ciò elimina la necessità di codificare il percorso della cartella di destinazione durante la copia di file e automatizza la creazione di cartelle specifiche dell'utente in Amazon S3, consentendoti di dimensionare i flussi di lavoro di automazione dei file. Per ulteriori informazioni, consulta la documentazione.

AWS Step Functions è un servizio di orchestrazione serverless che permette di combinare AWS Lambda con altri servizi per definire l'esecuzione di applicazione commerciali in semplici fasi. Per eseguire le fasi di elaborazione dei file tramite AWS Step Functions, si utilizzano le funzioni AWS Lambda con le attivazioni degli eventi di Amazon S3 per assemblare i flussi di lavoro. I flussi di lavoro gestiti offrono un framework per orchestrare facilmente una sequenza lineare di elaborazione e si differenza dalle soluzioni esistenti nei modi seguenti: 1) puoi definire in maniera dettagliata flussi di lavoro da eseguire solo su caricamenti completi di file e flussi di lavoro da eseguire solo su caricamenti di file parziali, 2) i flussi di lavoro possono essere attivati automaticamente per S3, nonché per EFS, che non offre eventi post-caricamento; 3) i flussi di lavoro non forniscono codice e opzioni predefinite per l'elaborazione di file comuni come la decrittografia PGP e 4) i clienti possono ottenere visibilità end-to-end sui trasferimenti e sull'elaborazione dei propri file nei log CloudWatch.

Per i dettagli sulle funzionalità supportate per la registrazione delle attività dei flussi di lavoro gestiti, consulta la sezione Monitoraggio.

Sì. Consulta questo post del blog sull'utilizzo dei flussi di lavoro gestiti per le notifiche di consegna dei file.

Sì. È possibile definire flussi di lavoro separati da attivare sui caricamenti di file sia completi che parziali.

No. L'elaborazione può essere richiamata soltanto all'arrivo dei file tramite l'endpoint in entrata.

Attualmente, è possibile attivare i flussi di lavoro gestiti solo per i file caricati sugli endpoint di server SFTP, FTPS ed FTP ed elaborare un file per esecuzione. I flussi di lavoro gestiti non sono supportati per i messaggi scambiati su AS2, per il download di file sugli endpoint del server e per i file trasferiti tramite connettori SFTP.

No. Al momento, i flussi di lavoro elaborano un file per esecuzione.

No. I flussi di lavoro gestiti non possono essere richiamati su base granulare per utente. È possibile definire una logica di elaborazione condizionale dei file in base all'utente che ha caricato il file utilizzando le notifiche degli eventi di trasferimento file pubblicate su Amazon EventBridge.

No. I flussi di lavoro gestiti non sono supportati per le app Web. Ti consigliamo di utilizzare le notifiche degli eventi S3 per dare il via ai flussi di lavoro automatici di elaborazione post-caricamento.

Il trasferimento dei dati tra i server di AWS Transfer Family e Amazon S3 avviene sulle reti interne di AWS e non attraversa l'Internet pubblico. Per questo motivo, non è necessario utilizzare AWS PrivateLink per i dati trasferiti dal server AWS Transfer Family ad Amazon S3. Il servizio Transfer Family non richiede gli endpoint AWS PrivateLink per Amazon S3 per evitare che il traffico passi su Internet, e quindi non può usarli per comunicare con i servizi di archiviazione. Tutto questo presuppone che il servizio di archiviazione AWS e il server Transfer Family siano nella stessa regione.

AWS IAM viene utilizzato per determinare il livello di accesso che si desidera consentire agli utenti. Ad esempio, è possibile decidere le operazioni che gli utenti possono eseguire sui loro client e a quali bucket Amazon S3 possono accedere, interamente o in parte.

La directory home configurata per un utente ne determina la directory di accesso. Si tratta di ciò che sarebbe il percorso di directory che il client del tuo utente in cui verrà inserito non appena questo abbia completato con successo l’autenticazione all’interno del server. Sarà necessario assicurarsi che il ruolo IAM fornito garantisca all'utente l'accesso alla directory home.

Sì. Puoi assegnare un singolo ruolo IAM per tutti i tuoi utenti e utilizzare le mappe logiche per directory, le quali specificano quali percorsi assoluti dei bucket Amazon S3 desideri rendere visibili ai tuoi utenti finali e come questi percorsi vengono presentati a loro dai loro client. Consulta il post del blog Simplify Your AWS SFTP/FTPS/FTP Structure with Chroot and Logical Directories.

I file trasferiti tramite i protocolli supportati vengono memorizzati come oggetti nel bucket Amazon S3; file e oggetti dispongono di una mappatura univoca, consentendo l'accesso nativo agli oggetti tramite i servizi AWS per elaborazione e analisi.

Una volta completata l'autenticazione secondo le credenziali degli utenti, il servizio visualizza oggetti e cartelle in Amazon S3 come file e directory all'interno delle applicazioni di trasferimento degli utenti.

Sono supportati i comandi base: creazione, lettura, aggiornamento ed eliminazione di file e directory. I file vengono memorizzate come singoli oggetti nel bucket Amazon S3. Le directory sono gestite come oggetti folder in S3, utilizzando la stessa sintassi usata nella console S3.

Al momento, operazioni di rinomina della directory, operazioni di append, la modifica delle proprietà, i permessi e le marche temporali, così come l’utilizzo di collegamenti simbolici e reali, non sono supportati.

Sì. È possibile abilitare o disabilitare le operazioni sui file tramite i ruoli AWS IAM mappati ai rispettivi nomi utente. Consulta la documentazione su come creare policy e ruoli IAM per controllare l'accesso dei tuoi utenti finali

Sì. Il bucket a cui può accedere il tuo utente è determinato dal ruolo AWS IAM e la policy scope-down opzionale assegnata a quell'utente. Puoi utilizzare solo un bucket singolo come home directory per l'utente.

Sì. Puoi utilizzare gli alias dei punti di accesso S3 con AWS Transfer Family per fornire accesso granulare a un vasto set di dati senza dover gestire neanche una policy di bucket. Gli alias dei punti di accesso S3 combinati con le directory logiche di AWS Transfer Family permettono di creare un controllo dettagliato degli accessi per diverse applicazioni, team e dipartimenti, riducendo al tempo stesso l'onere di gestire le policy di bucket. Per saperne di più e iniziare subito, consulta questo post nel blog su come migliorare il controllo dell'accesso ai dati con AWS Transfer Family e i Punti di accesso Amazon S3.

Sì. Puoi utilizzare CLI e API per configurare l'accesso di più account tra il tuo server e i bucket che desideri utilizzare per archiviare file trasferiti tramite i protocolli supportati. Il menù a discesa della Console elencherà solo i bucket dell'Account A. Inoltre, dovrai assicurarti che il ruolo assegnato all'utente appartenga all'Account A.

Sì. AWS Transfer Family pubblica notifiche di eventi su Amazon EventBridge al completamento di un'operazione di trasferimento file, consentendo di utilizzare questi eventi per automatizzare l'elaborazione post-caricamento dei file. In alternativa, quando è necessario elaborare tutti i file caricati utilizzando le stesse fasi di elaborazione dei file senza alcuna logica condizionale, è possibile utilizzare i flussi di lavoro gestiti di AWS Transfer Family per definire una sequenza lineare di passaggi comuni di elaborazione dei file che vengono richiamate automaticamente per ogni file che gli utenti caricano sugli endpoint di server SFTP, FTPS o FTP. Per le app Web di Transfer Family, puoi utilizzare le notifiche degli eventi S3 per automatizzare l'elaborazione post-caricamento.

Sì. Quando un tuo utente carica un file, il nome utente e l’ID del server utilizzato per il caricamento vengono archiviati come parte dei metadati dell’oggetto S3 associato. Consulta la documentazione sulle informazioni da utilizzare per l'elaborazione dei dati post-caricamento. Le informazioni sull'utente finale sono disponibili anche nella notifica automatica degli eventi di caricamento dei file pubblicata da AWS Transfer Family su Amazon EventBridge. È possibile utilizzare queste informazioni per orchestrare l'elaborazione granulare dopo il caricamento dei file in base all'utente. 

Amazon S3 può pubblicare notifiche di eventi per qualsiasi nuovo oggetto creato nel bucket. D'altra parte, AWS Transfer Family pubblica notifiche di eventi in seguito al completamento riuscito o non riuscito di ciascuna operazione di trasferimento file. Si differenzia dalle notifiche di eventi di Amazon S3 nei seguenti modi: 1) è possibile controllare in modo granulare la definizione dell'elaborazione post-caricamento per i caricamenti completi di file rispetto ai caricamenti parziali di file quando vengono utilizzate le notifiche di eventi di Transfer Family; 2) gli eventi di Transfer Family vengono pubblicati per i caricamenti di file sia su S3 che su EFS; 3) gli eventi generati da Transfer Family contengono informazioni operative come nome utente del mittente, ID del server, stato del trasferimento, ecc. Inoltre, consente di definire l'elaborazione dei file in modo granulare, in base alla logica condizionale su questi attributi.

Sì. Puoi ottimizzare l'elenco delle directory S3 in modo che gli utenti finali possano accedere a un elenco rapido delle directory, riducendo i tempi da minuti a secondi. Se crei un nuovo server tramite la console dopo il 17/11/2023, l'elenco ottimizzato delle directory S3 sarà abilitato per impostazione predefinita quando si utilizza Amazon S3 come opzione di archiviazione. Questa opzione può essere attivata o disattivata in qualsiasi momento. Disattivando questa funzionalità si ripristinano le prestazioni predefinite dell'elenco delle directory S3. Se la creazione di un server avviene mediante CloudFormation, CLI o API, l'elenco ottimizzato delle directory S3 è disabilitato per impostazione predefinita, ma può essere attivato in qualsiasi momento. Per informazioni su come abilitare l'elenco ottimizzato delle directory S3, consulta la relativa documentazione.

Sebbene dipenda dall'utilizzo delle policy di sessione e da altri requisiti interni, in genere non sono necessari entrambi per garantire che gli utenti accedano solo ai file previsti. Le mappature delle directory logiche consentono agli utenti di accedere solo alle sottodirectory e ai percorsi logici designati, vietando i percorsi relativi che attraversano i root logici. Convalidiamo ogni percorso che utilizza una notazione relativa in grado di includere potenzialmente elementi relativi e blocchiamo attivamente la risoluzione di questi percorsi prima di trasferirli a S3, per evitare che gli utenti oltrepassino le mappature logiche. 

Prima di configurare AWS Transfer Family affinché funzioni con Amazon EFS, devi configurare la proprietà dei file e delle cartelle utilizzando le stesse identità POSIX (ID utente/ID gruppo) che prevedi di assegnare agli utenti di AWS Transfer Family. Inoltre, se accedi ai file system di un altro account, le policy delle risorse devono essere configurate anche sul tuo file system, per consentire l'accesso a più account. Consulta questo post nel blog per una guida dettagliata su come utilizzare AWS Transfer Family con EFS.

Il trasferimento dei dati tra i server di AWS Transfer Family e Amazon EFS avviene sulle reti interne di AWS e non attraversa l'Internet pubblico. Per questo motivo, non è necessario utilizzare AWS PrivateLink per i dati trasferiti dal server AWS Transfer Family ad Amazon EFS. Il servizio Transfer Family non richiede gli endpoint AWS PrivateLink per Amazon EFS per evitare che il traffico passi su Internet, e quindi non può usarli per comunicare con i servizi di archiviazione. Tutto questo presuppone che il servizio di archiviazione AWS e il server Transfer Family siano nella stessa regione.

Amazon EFS utilizza ID POSIX costituiti da ID utente, ID gruppo e ID gruppo secondario del sistema operativo per controllare l'accesso a un file system. Quando configuri l'utente nella console, nell'interfaccia a riga di comando o nell'API di AWS Transfer Family, devi specificare il nome utente, la configurazione POSIX dell'utente e un ruolo IAM per accedere al file system EFS. Devi inoltre specificare un ID del file system EFS e, facoltativamente, una directory all'interno di tale file system come directory di destinazione dell'utente. Quando l'utente di AWS Transfer Family viene autenticato utilizzando il relativo client di trasferimento file, viene inserito direttamente nella home directory specificata o nella root del file system EFS specificato. L'ID POSIX del sistema operativo viene applicato a tutte le richieste effettuate attraverso i client di trasferimento file. Come amministratore EFS, devi assicurarti che il file e le directory a cui desideri che gli utenti di AWS Transfer Family abbiano accesso siano di proprietà degli ID POSIX corrispondenti nel file system EFS. Fai riferimento alla documentazione per ulteriori informazioni sulla configurazione della proprietà delle sottodirectory in EFS. Nota che Transfer Family non supporta i punti di accesso se utilizzi Amazon EFS per l'archiviazione.  

I file trasferiti attraverso i protocolli abilitati sono archiviati direttamente nei file system Amazon EFS e saranno accessibili attraverso un'interfaccia standard di file system o da servizi AWS che possono accedere ai file system Amazon EFS.

R: Sono supportati i comandi di SFTP/FTPS/FTP per la creazione, la lettura, l'aggiornamento e l'eliminazione di file, directory e link simbolici. Fai riferimento alla tabella in basso per i comandi supportati per EFS e S3.

1. Solo le ridenominazioni di file sono supportate. Le ridenominazioni di directory e di file per sovrascrivere i file esistenti non sono supportate.

2. Solo gli utenti root, vale a dire gli utenti con uid=0, possono modificare la proprietà e le autorizzazioni di file e directory.

3. Supportato per gli utenti root, ad esempio gli utenti con uid=0, o per il proprietario di file che può solo modificare un gruppo di file in modo che diventi uno dei gruppi secondari.

4. Supportato solo per cartelle non vuote.

La policy IAM che fornisci per l'utente di AWS Transfer Family determina se l'utente ha accesso in sola lettura, in lettura-scrittura e accesso root al tuo file system. Inoltre, come amministratore del file system, puoi configurare la proprietà e concedere l'accesso ai file e alle directory all'interno del file system utilizzando il loro ID utente e ID gruppo. Questo vale sia per gli utenti archiviati all'interno del servizio (servizio gestito) che per quelli archiviati all'interno del sistema di gestione dell'identità ("BYO Auth").

Sì. Quando configuri gli utenti, puoi specificare file system e directory diversi per ciascuno di essi. Una volta eseguita l'autenticazione, EFS applicherà una directory per ogni richiesta di file system effettuata utilizzando i protocolli abilitati.

Sì. Utilizzando le mappature logiche delle directory di AWS Transfer Family, puoi evitare che gli utenti finali visualizzino le directory nei tuoi file system, mappando i percorsi assoluti ai nomi dei percorsi visibili all'utente finale. Puoi anche impostare l'utente come "chroot" per la home directory designata.

Sì. Se nelle directory accessibili all'utente sono presenti link simbolici e l'utente cerca di accedervi, i link vengono risolti nella relativa destinazione. I link simbolici non sono supportati quando si utilizzano le mappature logiche delle directory per configurare l'accesso degli utenti.

Sì. Quando configuri un utente di AWS Transfer Family, puoi specificare uno o più file system nella policy IAM che fornisci come parte della configurazione dell'utente per concedere l'accesso a più file system.

Puoi utilizzare client e applicazioni create per Microsoft Windows, Linux, macOS o qualsiasi sistema operativo che supporti SFTP/FTPS/FTP per caricare e accedere ai file archiviati nei file system EFS. Basta configurare il server e l'utente con le autorizzazioni appropriate per il file system EFS per accedere al file system in tutti i sistemi operativi.

Ci sono due opzioni: 1) AWS Transfer Family pubblica notifiche di eventi su Amazon EventBridge al completamento di un'operazione di trasferimento file, consentendo di utilizzare questi eventi per automatizzare l'elaborazione post-caricamento dei file; 2) quando è necessario elaborare tutti i file caricati utilizzando le stesse fasi di elaborazione dei file senza alcuna logica condizionale, è possibile utilizzare i flussi di lavoro gestiti da AWS Transfer Family per definire una sequenza lineare delle comuni fasi di elaborazione dei file da applicare per ogni file caricato sugli endpoint di server SFTP, FTPS o FTP.

Per i nuovi file, l'ID utente POSIX associato all'utente che carica il file sarà impostato come proprietario del file nel file system EFS. Inoltre, puoi utilizzare Amazon CloudWatch per monitorare l'attività degli utenti per le operazioni di creazione, aggiornamento, eliminazione e lettura dei file. Per ulteriori informazioni su come abilitare la registrazione in Amazon CloudWatch, consulta la documentazione.

Sì. Puoi utilizzare l'interfaccia a riga di comando e l'API per configurare l'accesso a più account tra le risorse di AWS Transfer Family e i file system EFS. Nella console AWS Transfer Family verranno visualizzati solo i file system presenti nello stesso account. Inoltre, devi assicurarti che il ruolo IAM assegnato all'utente per accedere al file system appartenga all'Account A.

Se un server AWS Transfer Family per l'accesso a un file system EFS con più account viene configurato in modo che non sia abilitato per l'accesso a più account, ai tuoi utenti SFTP/FTP/FTPS sarà negato l'accesso al file system. Se hai attivato la registrazione di log di CloudWatch sul tuo server, gli errori di accesso a più account saranno registrati in CloudWatch Logs.

No. Puoi utilizzare AWS Transfer Family solo per accedere ai file system EFS nella stessa regione AWS.

Sì. Puoi utilizzare AWS Transfer per scrivere i file in EFS e configurare la Gestione del ciclo di vita EFS per migrare i file ai quali non è stato effettuato l'accesso per un dato periodo di tempo nella classe di storage di accesso infrequente (IA).

Sì. Amazon EFS offre interfaccia e semantica di accesso file system (con coerenza forte di dati e blocco file), nonché archiviazione accessibile in contemporanea a migliaia di client NFS/SFTP/FTPS/FTP.

Sì. L'accesso ai file system EFS utilizzando i server AWS Transfer Family consumerà i crediti di espansione EFS indipendentemente dalla modalità di throughput. Fai riferimento alla documentazione su prestazioni e modelli di velocità di trasmissione effettiva disponibili e visualizza alcuni suggerimenti utili sulle prestazioni.

Per i trasferimenti di dati su reti pubbliche dovresti utilizzare l’SFTP o l’FTPS. Dati i sistemi di sicurezza sottostanti dei protocolli basati sugli algoritmi crittografici SSH e TLS, i dati e i comandi vengono trasferiti tramite un canale sicuro e crittografato.

Puoi scegliere di crittografare i file archiviati nel bucket utilizzando la crittografia lato server di Amazon S3 (SSE-S3), oppure utilizzare Amazon KMS (SSE-KMS). Per i file archiviati EFS, puoi scegliere AWS o CMK gestito dal cliente per la crittografia di file inattivi. Fai riferimento alla documentazione per ulteriori dettagli sulle opzioni per la crittografia di dati e metadati di file inattivi utilizzando Amazon EFS.

AWS Transfer Family è conforme ai programmi PCI-DSS, GDPR, FedRAMP e SOC 1, 2 e 3. Inoltre, il servizio è idoneo per il programma HIPAA. Ottieni ulteriori informazioni sui servizi coperti da programmi di conformità.

Le regioni AWS orientali e occidentali e GovCloud (USA) sono conformi alla normativa FISMA. Quando AWS Transfer Family sarà autorizzato per il programma FedRAMP, sarà conforme a FISMA nelle rispettive Regioni. Tale conformità è dimostrata dall’Autorizzazione FedRAMP in queste due Regioni per FedRAMP Moderate e FedRAMP High. Dimostriamo la conformità del servizio attraverso valutazioni annuali e documentazioni d conformità con controlli di ambito NIST SP 800-53 all’interno dei nostri Piani di sicurezza del sistema. I modelli sono disponibili su Artifact, così come la nostra Matrice di responsabilità del cliente (Customer Responsability Matrix, CRM), la quale dimostra, in modo dettagliato, come la nostra responsabilità risponde ai controlli NIST così come richiesto da FedRAMP. Artifact è disponibile attraverso la console di gestione accessibile da un account AWS sia per le regioni orientali e occidentali, sia per la regione GovCloud. Se hai altre domande su questo argomento, consulta la console.

I file caricati tramite i servizi sono verificati confrontando il checksum MD5 pre e post caricamento.

È possibile utilizzare i flussi di lavoro gestiti di AWS Transfer Family per decrittografare automaticamente i file utilizzando le chiavi PGP quando vengono caricati sugli endpoint di server SFTP, FTPS o FTP di AWS Transfer Family. Per ulteriori informazioni, consulta la nostra documentazione sui flussi di lavoro gestiti. In alternativa, è possibile abbonarsi alle notifiche di eventi di AWS Transfer Family pubblicate in Amazon EventBridge per orchestrare l'elaborazione granulare e basata sugli eventi dei file trasferiti utilizzando la logica di crittografia/decrittografia.

Puoi monitorare gli utenti finali e le loro attività di trasferimento di file utilizzando i log in formato JSON che vengono consegnati ad Amazon CloudWatch. All'interno di CloudWatch, puoi analizzare e interrogare i tuoi log utilizzando CloudWatch Log Insights, che rileva automaticamente i campi in formato JSON. Puoi anche tenere traccia degli utenti principali, del numero totale di utenti unici e del loro utilizzo continuo con Contributor Insights di CloudWatch. Forniamo anche parametri e grafici CloudWatch predefiniti accessibili nella Console di gestione di AWS Transfer Family. Per ulteriori informazioni, consulta la documentazione.

Sì. Puoi combinare flussi di log provenienti da più server AWS Transfer Family in un unico gruppo di log CloudWatch. Ciò consente di creare parametri e visualizzazioni di log consolidati, che possono essere aggiunti alle dashboard di CloudWatch per monitorare l'utilizzo e le prestazioni del server.

Le esecuzioni dei flussi di lavoro possono essere monitorate utilizzando i parametri di AWS CloudWatch, ad esempio il numero totale di esecuzioni dei flussi di lavoro, esecuzioni riuscite ed esecuzioni non riuscite. Utilizzando la Console di gestione AWS è possibile cercare e visualizzare in tempo reale lo stato delle esecuzioni dei flussi di lavoro in corso. Utilizza i log di CloudWatch per ottenere la registrazione dettagliata delle esecuzioni dei flussi di lavoro.

AWS Transfer Family fornisce log in formato JSON su tutte le risorse, inclusi server, connettori e flussi di lavoro, e tutti i protocolli, inclusi SFTP, FTPS, FTP e AS2.

È possibile utilizzare i flussi di lavoro gestiti di Transfer Family per ricevere notifiche per i file caricati sugli endpoint di server SFTP, FTPS ed FTP. Consulta questo post del blog. In alternativa, puoi iscriverti agli eventi di AWS Transfer Family su Amazon EventBridge per ricevere notifiche tramite Amazon Simple Notification Service (SNS).

Sì. Se il controllo di convalida di un file fallisce rispetto alle fasi di convalida preconfigurate, è possibile utilizzare il gestore di eccezioni per richiamare il sistema di monitoraggio o avvisare i membri del team tramite un argomento Amazon SNS.

Il servizio viene fatturato su base oraria per ciascuno dei protocolli attivati, dal momento in cui crei e configuri l’endpoint del tuo server, fino al momento in cui lo elimini. Viene inoltre calcolato il costo dei dati caricati e scaricati nel server tramite SFTP, FTPS o FTP, il numero di messaggi scambiati tramite AS2 e la quantità di dati elaborati utilizzando la fase di decrittografia del flusso di lavoro. Quando si utilizzano connettori SFTP, i costi vengono calcolati in base alla quantità di dati trasferiti e al numero di chiamate del connettore. Con le app Web Transfer Family, paghi solo le tue unità di app Web. Per ulteriori informazioni, consulta la pagina dei prezzi.

No. Il modello di fatturazione su base oraria si applica per ciascuno dei protocolli che hai attivato e per la quantità di dati trasferiti attraverso ciascuno dei protocolli, sia che tu abbia abilitato lo stesso endpoint per più protocolli, sia che tu stia utilizzando endpoint differenti per ciascun protocollo.

Sì. L'arresto del server tramite la console o eseguendo il comando CLI "stop-server" o il comando API "StopServer" non modifica i costi fatturati. Il servizio viene fatturato su base oraria dal momento in cui crei l'endpoint del tuo server e ne configuri l'accesso (per uno o più protocolli) fino al momento in cui elimini il server.

La fase di decrittografia del flusso di lavoro viene fatturata sulla base della quantità di dati decrittografati utilizzando chiavi PGP. Non sono previsti ulteriori costi aggiuntivi per l'utilizzo dei flussi di lavoro gestiti. A seconda della configurazione dei flussi di lavoro, viene fatturato anche l'utilizzo di Amazon S3, Amazon EFS, AWS Secrets Manager e AWS Lambda.

No. Non è prevista una fatturazione oraria per i connettori SFTP. Per ulteriori informazioni sui prezzi dei connettori SFTP, consulta la pagina dei prezzi.

No. Non sono previsti costi aggiuntivi per il trasferimento dei dati tramite le app Web Transfer Family, nonostante si applichino ancora i costi di trasferimento dei dati S3. Per ulteriori informazioni, consulta la pagina dei prezzi