

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Gestione degli utenti per gli endpoint del server
<a name="create-user"></a>

Nelle sezioni seguenti, puoi trovare informazioni su come aggiungere utenti utilizzando AWS Transfer Family AWS Directory Service for Microsoft Active Directory o un provider di identità personalizzato.

Come parte delle proprietà di ogni utente, puoi anche archiviare la chiave pubblica SSH (Secure Shell) dell'utente. Questa operazione è necessaria per l'autenticazione basata su chiavi. La chiave privata viene archiviata localmente sul computer dell'utente. Quando l'utente invia una richiesta di autenticazione al server utilizzando un client, il server conferma innanzitutto che l'utente ha accesso alla chiave privata SSH associata. Il server quindi autentica correttamente l'utente.

**Nota**  
Per la distribuzione e la gestione automatizzate degli utenti con più chiavi SSH, vedere. [Moduli Transfer Family Terraform](terraform.md)

Inoltre, si specifica la home directory o la directory di destinazione di un utente e si assegna un ruolo AWS Identity and Access Management (IAM) all'utente. Facoltativamente, puoi fornire una politica di sessione per limitare l'accesso degli utenti solo alla home directory del tuo bucket Amazon S3.

**Importante**  
AWS Transfer Family impedisce ai nomi utente di 1 o 2 caratteri di autenticarsi sui server SFTP. Inoltre, blocchiamo anche il nome utente. `root`  
Il motivo alla base di ciò è dovuto all'elevato volume di tentativi di accesso malevoli da parte degli scanner di password.

## Confronto tra Amazon EFS e Amazon S3
<a name="efs-vs-s3-users"></a>

Caratteristiche di ciascuna opzione di storage:
+ Per limitare l'accesso: Amazon S3 supporta le policy di sessione; Amazon EFS supporta utenti, gruppi e gruppi secondari POSIX IDs
+  Entrambi i tasti di supporto public/private 
+  Entrambi supportano le home directory 
+  Entrambi supportano le directory logiche 
**Nota**  
 Per Amazon S3, la maggior parte del supporto per le directory logiche avviene tramite API/CLI. Puoi utilizzare la casella di controllo **Restricted** nella console per bloccare un utente nella sua home directory, ma non puoi specificare una struttura di directory virtuale. 

## Directory logiche
<a name="logical-dir-users"></a>

Se si specificano valori di directory logica per l'utente, il parametro utilizzato dipende dal tipo di utente.
+ Per gli utenti gestiti dal servizio, fornisci i valori della directory logica in. `HomeDirectoryMappings`
+ Per gli utenti di provider di identità personalizzati, fornisci i valori della directory logica in. `HomeDirectoryDetails`

AWS Transfer Family supporta la specificazione di un HomeDirectory valore quando si utilizza HomeDirectoryType LOGICAL. Ciò si applica agli utenti di Service Managed, all'accesso ad Active Directory e alle implementazioni di Custom Identity Provider, laddove HomeDirectoryDetails siano forniti nella risposta.

**Importante**  
Quando si specifica un HomeDirectory con LOGICAL HomeDirectoryType, il valore deve essere mappato a una delle mappature delle directory logiche. Il servizio lo convalida sia durante la creazione degli utenti che durante gli aggiornamenti per evitare configurazioni che non funzionerebbero.

### Comportamento predefinito
<a name="logical-dir-default"></a>

Per impostazione predefinita, se non viene specificato, HomeDirectory è impostato su «/» per la modalità LOGICAL. Questo comportamento rimane invariato e rimane compatibile con le definizioni utente esistenti.
+ Assicurati di associare il tuo nome HomeDirectory a un *Entry* e non a un *Target*. Per ulteriori dettagli, consultare [Regole per l'utilizzo delle directory logiche](logical-dir-mappings.md#logical-dir-rules).
+ Per i dettagli su come è strutturata una directory virtuale, vedi[Struttura delle directory virtuali](implement-log-dirs.md#virtual-dirs).

### Considerazioni relative a Custom Identity Provider
<a name="logical-dir-custom-idp"></a>

Quando si utilizza un provider di identità personalizzato, ora è possibile specificare un HomeDirectory nella risposta mentre si utilizza HomeDirectoryType LOGICAL. La chiamata TestIdentityProvider API produrrà risultati corretti quando l'IDP personalizzato specifica un HomeDirectory in modalità LOGICAL.

Esempio di risposta IDP personalizzata con HomeDirectory e LOGICAL: HomeDirectoryType

```
{
  "Role": "arn:aws:iam::123456789012:role/transfer-user-role",
  "HomeDirectoryType": "LOGICAL",
  "HomeDirectory": "/marketing",
  "HomeDirectoryDetails": "[{\"Entry\":\"/\",\"Target\":\"/bucket/home\"},{\"Entry\":\"/marketing\",\"Target\":\"/marketing-bucket/campaigns\"}]"
}
```

## Quote di gruppo Active Directory
<a name="ad-group-quotas"></a>

AWS Transfer Family ha un limite predefinito di 100 gruppi di Active Directory per server. Se il tuo caso d'uso richiede più di 100 gruppi, prendi in considerazione l'utilizzo di una soluzione di provider di identità personalizzata, come descritto in [Semplificare l'autenticazione di Active Directory con un provider di identità personalizzato per AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).

Questo limite si applica ai server che utilizzano i seguenti provider di identità:
+ AWS Directory Service per Microsoft Active Directory
+ AWS Directory Service per Entra ID Domain Services

Se devi richiedere un aumento del limite di servizio, consulta le [Servizio AWS quote](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) nel *Riferimenti generali di AWS*. Se il tuo caso d'uso richiede più di 100 gruppi, prendi in considerazione l'utilizzo di una soluzione di provider di identità personalizzata, come descritto in [Semplificare l'autenticazione di Active Directory con un provider di identità personalizzato per AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).

Per informazioni sulla risoluzione dei problemi relative ai limiti dei gruppi di Active Directory, consulta[I limiti dei gruppi di Active Directory sono stati superati](auth-issues.md#managed-ad-group-limits).

**Topics**
+ [Confronto tra Amazon EFS e Amazon S3](#efs-vs-s3-users)
+ [Directory logiche](#logical-dir-users)
+ [Quote di gruppo Active Directory](#ad-group-quotas)
+ [Lavorare con utenti gestiti dal servizio](service-managed-users.md)
+ [Lavorare con provider di identità personalizzati](custom-idp-intro.md)
+ [Utilizzo di AWS Directory Service per Microsoft Active Directory](directory-services-users.md)
+ [Utilizzo di AWS Directory Service per Entra ID Domain Services](azure-sftp.md)

# Lavorare con utenti gestiti dal servizio
<a name="service-managed-users"></a>

**Puoi aggiungere utenti gestiti dal servizio Amazon S3 o Amazon EFS al tuo server, a seconda dell'impostazione del dominio del server.** Per ulteriori informazioni, consulta [Configurazione di un endpoint server SFTP, FTPS o FTP](tf-server-endpoint.md).

Se utilizzi un tipo di identità gestita dal servizio, aggiungi utenti al tuo server abilitato al protocollo di trasferimento file. In tal caso, ogni nome utente deve essere univoco sul server.

Per aggiungere un utente gestito dal servizio a livello di codice, consulta l'[esempio](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html#API_CreateUser_Examples) relativo all'API. [CreateUser](https://docs.aws.amazon.com/transfer/latest/APIReference/API_CreateUser.html)

**Nota**  
Per gli utenti gestiti dal servizio è previsto un limite di 2.000 voci della directory logica. Per informazioni sull'utilizzo delle directory logiche, vedere. [Utilizzo di directory logiche per semplificare le strutture di directory Transfer Family](logical-dir-mappings.md)

**Topics**
+ [Aggiungere utenti gestiti dal servizio Amazon S3](#add-s3-user)
+ [Aggiungere utenti gestiti dal servizio Amazon EFS](#add-efs-user)
+ [Gestione degli utenti gestiti dal servizio](#managing-service-managed-users)

## Aggiungere utenti gestiti dal servizio Amazon S3
<a name="add-s3-user"></a>

**Nota**  
 Se desideri configurare un bucket Amazon S3 con più account, segui i passaggi indicati in questo articolo del Knowledge Center: [Come posso configurare il mio AWS Transfer Family server per utilizzare un bucket Amazon Simple Storage Service che](https://aws.amazon.com/premiumsupport/knowledge-center/sftp-cross-account-s3-bucket/) si trova in un altro account? AWS .

**Per aggiungere un utente gestito dal servizio Amazon S3 al tuo server**

1. Apri la AWS Transfer Family console all'indirizzo [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/), quindi seleziona **Server dal pannello** di navigazione.

1. Nella pagina **Server**, seleziona la casella di controllo del server a cui desideri aggiungere un utente.

1. Scegli **Add user** (Aggiungi utente).

1. Nella sezione **Configurazione utente**, per **Nome utente**, inserisci il nome utente. Questo nome utente deve contenere un minimo di 3 e un massimo di 100 caratteri. È possibile utilizzare i seguenti caratteri nel nome utente: a—z, A-Z, 0—9, carattere di sottolineatura '\$1', trattino '-', punto '.' e al segno '@'. Il nome utente non può iniziare con un trattino '-', punto '.' o dal segno '@'.

1. Per **Access**, scegli il ruolo IAM che hai creato in precedenza che fornisce l'accesso al tuo bucket Amazon S3.

   Questo ruolo IAM è stato creato utilizzando la procedura in [Crea un ruolo e una policy IAM](requirements-roles.md). Tale ruolo IAM include una policy IAM che fornisce l'accesso al tuo bucket Amazon S3. Include anche una relazione di fiducia con il AWS Transfer Family servizio, definita in un'altra policy IAM. Se hai bisogno di un controllo granulare degli accessi per i tuoi utenti, consulta il post del blog [Enhance data access control with and Amazon AWS Transfer Family S3](https://aws.amazon.com/blogs/storage/enhance-data-access-control-with-aws-transfer-family-and-amazon-s3-access-points/).

1. (Facoltativo) Per **Policy**, seleziona una delle seguenti opzioni:
   + **Nessuno**
   + **Politica esistente**
   + **Seleziona una policy da IAM**: ti permette di scegliere una policy di sessione esistente. Scegli **Visualizza** per vedere un oggetto JSON contenente i dettagli della policy.
   + **Genera automaticamente una politica basata sulla home directory**: genera automaticamente una politica di sessione. Scegli **Visualizza per visualizzare** un oggetto JSON contenente i dettagli della politica.
**Nota**  
Se scegli la **politica di generazione automatica in base alla cartella home**, non selezionare **Restricted** per questo utente.

   Per ulteriori informazioni sui criteri di sessione, consulta [Crea un ruolo e una policy IAM](requirements-roles.md)[Creazione di una politica di sessione per un bucket Amazon S3](users-policies-session.md), o[Approcci di gestione dinamica delle autorizzazioni](dynamic-permission-management.md).

1. Per la **directory Home**, scegli il bucket Amazon S3 in cui archiviare i dati da trasferire. AWS Transfer Family Inserisci il percorso della `home` directory in cui l'utente atterra quando accede utilizzando il suo client.

   Se lasci vuoto questo parametro, viene utilizzata la `root` directory del tuo bucket Amazon S3. In questo caso, assicurarsi che il ruolo IAM fornisca l'accesso a questa directory `root`.
**Nota**  
Ti consigliamo di scegliere un percorso di directory che contenga il nome utente dell'utente, che ti consenta di utilizzare in modo efficace una politica di sessione. La policy di sessione limita l'accesso degli utenti nel bucket Amazon S3 alla directory di quell'utente. `home`

1. (Facoltativo) Per **Restricted**, seleziona la casella di controllo in modo che i tuoi utenti non possano accedere a nulla al di fuori di quella cartella e non possano vedere il bucket o il nome della cartella Amazon S3.
**Nota**  
L'assegnazione all'utente di una home directory e la limitazione dell'utente a tale directory dovrebbero essere sufficienti per bloccare l'accesso dell'utente alla cartella designata. Se è necessario applicare ulteriori controlli, utilizzare una politica di sessione.   
Se si seleziona **Limitato** per questo utente, non è possibile selezionare **Genera automaticamente criteri in base alla cartella home**, poiché la cartella principale non è un valore definito per gli utenti con restrizioni.

1. Per la **chiave pubblica SSH**, inserisci la parte della chiave SSH pubblica della coppia di chiavi SSH.

   La chiave viene convalidata dal servizio prima di aggiungere il nuovo utente.
**Nota**  
Per istruzioni su come generare una coppia di chiavi SSH, consulta [Genera chiavi SSH per utenti gestiti dal servizio](sshkeygen.md).

1. **(Facoltativo) Per **Chiave** e **Valore**, inserite uno o più tag come coppie chiave-valore e scegliete Aggiungi tag.**

1. Scegliere **Add (Aggiungi)** per aggiungere il nuovo utente al server scelto.

   Il nuovo utente viene visualizzato nella sezione **Utenti** della pagina dei **dettagli del server**.

**Passaggi successivi**: per il passaggio successivo, continua con[Trasferimento di file su un endpoint server utilizzando un client](transfer-file.md).

## Aggiungere utenti gestiti dal servizio Amazon EFS
<a name="add-efs-user"></a>

Amazon EFS utilizza il modello di autorizzazione dei file POSIX (Portable Operating System Interface) per rappresentare la proprietà dei file.
+  Per ulteriori dettagli sulla proprietà dei file di Amazon EFS, consulta la pagina Proprietà [dei file di Amazon EFS](configure-storage.md#efs-file-ownership). 
+ Per ulteriori dettagli sulla configurazione delle directory per gli utenti EFS, vedere[Configurazione degli utenti Amazon EFS per Transfer Family](configure-storage.md#configure-efs-users-permissions). 

**Per aggiungere un utente gestito dal servizio Amazon EFS al tuo server**

1. Apri la AWS Transfer Family console all'indirizzo [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/), quindi seleziona **Server** dal pannello di navigazione.

1. Nella pagina **Server**, seleziona il server Amazon EFS a cui desideri aggiungere un utente.

1. Scegli **Aggiungi utente** per visualizzare la pagina **Aggiungi utente**.

1. Nella sezione **Configurazione utente**, utilizza le seguenti impostazioni.

   1. Il **nome utente** deve contenere un minimo di 3 e un massimo di 100 caratteri. È possibile utilizzare i seguenti caratteri nel nome utente: a—z, A-Z, 0—9, trattino basso '\$1', trattino '-', punto ' . ', e al segno «@». Il nome utente non può iniziare con un trattino '-', punto ' . ', o al segno «@».

   1.  Per **ID utente** e **ID gruppo**, tieni presente quanto segue: 
      + Per il primo utente che crei, ti consigliamo di inserire un valore sia **0** per l'ID del **gruppo che per l'ID** **utente**. Ciò concede all'utente i privilegi di amministratore per Amazon EFS. 
      + Per utenti aggiuntivi, inserisci l'ID utente POSIX e l'ID del gruppo dell'utente. IDs Vengono utilizzati per tutte le operazioni di Amazon Elastic File System eseguite dall'utente. 
      + Per **ID utente** e **ID gruppo**, non utilizzare zeri iniziali. Ad esempio, **12345** è accettabile, non lo **012345** è. 

   1. (Facoltativo) Per **Gruppo secondario IDs**, inserite uno o più gruppi POSIX aggiuntivi IDs per ogni utente, separati da virgole.

   1. Per **Access**, scegli il ruolo IAM che:
      + Fornisce all'utente l'accesso solo alle risorse Amazon EFS (file system) a cui desideri che acceda.
      + Definisce quali operazioni sul file system l'utente può e non può eseguire.

      Ti consigliamo di utilizzare il ruolo IAM per la selezione del file system Amazon EFS con accesso e read/write autorizzazioni di montaggio. Ad esempio, la combinazione delle seguenti due politiche AWS gestite, sebbene piuttosto permissiva, concede le autorizzazioni necessarie all'utente: 
      +  AmazonElasticFileSystemClientFullAccess 
      +  AWSTransferConsoleFullAccess 

      Per ulteriori informazioni, consulta il post di blog dedicato al [AWS Transfer Family supporto per Amazon Elastic File System](https://aws.amazon.com/blogs/aws/new-aws-transfer-family-support-for-amazon-elastic-file-system/).

   1. Per la **directory Home**, procedi come segue:
      + Scegli il file system Amazon EFS che desideri utilizzare per archiviare i dati da trasferire AWS Transfer Family.
      + Decidi se impostare la home directory su **Restricted**. L'impostazione della home directory su **Restricted** ha i seguenti effetti:
        + Gli utenti di Amazon EFS non possono accedere a file o directory al di fuori di quella cartella.
        + Gli utenti di Amazon EFS non possono vedere il nome del file system Amazon EFS (**fs-xxxxxxx**).
**Nota**  
Quando selezioni l'opzione **Restricted**, i collegamenti simbolici non si risolvono per gli utenti di Amazon EFS.
      + (Facoltativo) Inserisci il percorso della home directory in cui desideri che si trovino gli utenti quando accedono utilizzando il loro client.

        Se non si specifica una directory home, viene utilizzata la directory principale del file system Amazon EFS. In questo caso, assicurati che il tuo ruolo IAM fornisca l'accesso a questa directory principale.

1. Per la **chiave pubblica SSH**, inserisci la parte della chiave SSH pubblica della coppia di chiavi SSH.

   La chiave viene convalidata dal servizio prima di aggiungere il nuovo utente.
**Nota**  
Per istruzioni su come generare una coppia di chiavi SSH, consulta [Genera chiavi SSH per utenti gestiti dal servizio](sshkeygen.md).

1. (Facoltativo) Immettete i tag per l'utente. Per **Chiave** e **Valore**, inserite uno o più tag come coppie chiave-valore e scegliete **Aggiungi** tag.

1. Scegliere **Add (Aggiungi)** per aggiungere il nuovo utente al server scelto.

   Il nuovo utente viene visualizzato nella sezione **Utenti** della pagina dei **dettagli del server**.

 Problemi che potresti riscontrare quando esegui per la prima volta un SFTP sul tuo server Transfer Family: 
+  Se si esegue il `sftp` comando e il prompt non viene visualizzato, è possibile che venga visualizzato il seguente messaggio: 

   `Couldn't canonicalize: Permission denied` 

   `Need cwd` 

   In questo caso, è necessario aumentare le autorizzazioni relative alle policy per il ruolo dell'utente. È possibile aggiungere una politica AWS gestita, ad esempio`AmazonElasticFileSystemClientFullAccess`. 
+ Se si immette `pwd` al `sftp` prompt di visualizzare la home directory dell'utente, è possibile che venga visualizzato il seguente messaggio, *USER-HOME-DIRECTORY* dov'è la directory principale dell'utente SFTP:

   `remote readdir("/USER-HOME-DIRECTORY"): No such file or directory` 

  In questo caso, dovreste essere in grado di accedere alla directory principale (`cd ..`) e creare la home directory dell'utente (`mkdir username`).

**Passaggi successivi**: per il passaggio successivo, continua con[Trasferimento di file su un endpoint server utilizzando un client](transfer-file.md).

## Gestione degli utenti gestiti dal servizio
<a name="managing-service-managed-users"></a>

 In questa sezione, puoi trovare informazioni su come visualizzare un elenco di utenti, come modificare i dettagli degli utenti e come aggiungere una chiave pubblica SSH. 
+ [Visualizza un elenco di utenti](#list-users)
+ [Visualizza o modifica i dettagli dell'utente](#view-user-details)
+ [Eliminazione di un utente](#delete-user)
+ [Aggiungi la chiave pubblica SSH](#add-user-ssh-key)
+ [Elimina la chiave pubblica SSH](#delete-user-ssh-key)<a name="list-users"></a>

**Per trovare un elenco dei tuoi utenti**

1. Apri la AWS Transfer Family console all'indirizzo [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. Seleziona **Server** dal riquadro di navigazione per visualizzare la pagina **Server**.

1. Scegli l'identificatore nella colonna **Server ID** per visualizzare la pagina dei **dettagli del server**.

1. In **Utenti**, visualizza un elenco di utenti.<a name="view-user-details"></a>

**Per visualizzare o modificare i dettagli dell'utente**

1. Apri la AWS Transfer Family console all'indirizzo [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. Seleziona **Server** dal riquadro di navigazione per visualizzare la pagina **Server**.

1. Scegli l'identificatore nella colonna **Server ID** per visualizzare la pagina dei **dettagli del server**.

1. In **Utenti**, scegli un nome utente per visualizzare la pagina dei **dettagli dell'utente**.

   Puoi modificare le proprietà dell'utente in questa pagina scegliendo **Modifica**.

1. Nella pagina dei **dettagli degli utenti**, scegli **Modifica** accanto a **Configurazione utente**.  
![\[Immagine che mostra la schermata per la modifica della configurazione di un utente\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/edit-user-details-page-user-config.png)

1. Nella pagina **Modifica configurazione**, per **Access**, scegli il ruolo IAM creato in precedenza che fornisce l'accesso al tuo bucket Amazon S3.

   Questo ruolo IAM è stato creato utilizzando la procedura in [Crea un ruolo e una policy IAM](requirements-roles.md). Tale ruolo IAM include una policy IAM che fornisce l'accesso al tuo bucket Amazon S3. Include anche una relazione di fiducia con il AWS Transfer Family servizio, definita in un'altra policy IAM.

1. (Facoltativo) Per **Policy**, scegli una delle seguenti opzioni:
   + **Nessuno**
   + **Politica esistente**
   + **Seleziona una policy da IAM** per scegliere una policy esistente. Scegli **Visualizza** per vedere un oggetto JSON contenente i dettagli della policy.

   Per ulteriori informazioni sulle politiche di sessione, consulta[Crea un ruolo e una policy IAM](requirements-roles.md). Per ulteriori informazioni sulla creazione di una politica di sessione, consulta[Creazione di una politica di sessione per un bucket Amazon S3](users-policies-session.md).

1. Per la **directory Home**, scegli il bucket Amazon S3 in cui archiviare i dati da trasferire. AWS Transfer Family Inserisci il percorso della `home` directory in cui l'utente atterra quando accede utilizzando il suo client.

   Se lasci vuoto questo parametro, viene utilizzata la `root` directory del tuo bucket Amazon S3. In questo caso, assicurarsi che il ruolo IAM fornisca l'accesso a questa directory `root`.
**Nota**  
Ti consigliamo di scegliere un percorso di directory che contenga il nome utente dell'utente, che ti consenta di utilizzare in modo efficace una politica di sessione. La policy di sessione limita l'accesso degli utenti nel bucket Amazon S3 alla directory di quell'utente. `home`

1. (Facoltativo) Per **Restricted**, seleziona la casella di controllo in modo che i tuoi utenti non possano accedere a nulla al di fuori di quella cartella e non possano vedere il bucket o il nome della cartella Amazon S3.
**Nota**  
Quando si assegna all'utente una home directory e si limita l'utente a tale directory, ciò dovrebbe essere sufficiente per bloccare l'accesso dell'utente alla cartella designata. Utilizza una politica di sessione quando devi applicare ulteriori controlli.

1. Scegli **Salva** per salvare le modifiche.<a name="delete-user"></a>

**Come eliminare un utente**

1. Apri la AWS Transfer Family console all'indirizzo [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. Seleziona **Server** dal riquadro di navigazione per visualizzare la pagina **Server**.

1. Scegli l'identificatore nella colonna **Server ID** per visualizzare la pagina dei **dettagli del server**.

1. In **Utenti**, scegli un nome utente per visualizzare la pagina dei **dettagli dell'utente**. 

1. Nella pagina dei **dettagli degli utenti**, scegli **Elimina** a destra del nome utente.

1. Nella finestra di dialogo di conferma che appare, inserisci la parola**delete**, quindi scegli **Elimina** per confermare che desideri eliminare l'utente.

 L'utente viene eliminato dall'elenco degli **utenti**.<a name="add-user-ssh-key"></a>

**Per aggiungere una chiave pubblica SSH per un utente**

1. Apri la AWS Transfer Family console all'indirizzo [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. Nel riquadro di navigazione, selezionare **Servers (Server)**.

1. Scegli l'identificatore nella colonna **Server ID** per visualizzare la pagina dei **dettagli del server**.

1. In **Utenti**, scegli un nome utente per visualizzare la pagina dei **dettagli dell'utente**.

1. Scegliere **Add SSH public key (Aggiungi chiave pubblica SSH)** per aggiungere una nuova chiave pubblica SSH a un utente.
**Nota**  
Le chiavi SSH vengono utilizzate solo dai server abilitati per Secure Shell (SSH) File Transfer Protocol (SFTP). Per informazioni su come generare una coppia di chiavi SSH, vedere[Genera chiavi SSH per utenti gestiti dal servizio](sshkeygen.md).

1. Per **SSH public key (Chiave pubblica SSH)**, immettere la parte di chiave pubblica SSH della coppia di chiavi SSH.

   La chiave viene convalidata dal servizio prima di aggiungere il nuovo utente. Il formato della chiave SSH è `ssh-rsa string`. Per generare una coppia di chiavi SSH, vedere[Genera chiavi SSH per utenti gestiti dal servizio](sshkeygen.md).

1. Scegliere **Add key (Aggiungi chiave)**.<a name="delete-user-ssh-key"></a>

**Per eliminare una chiave pubblica SSH per un utente**

1. Apri la AWS Transfer Family console all'indirizzo [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. Nel riquadro di navigazione, selezionare **Servers (Server)**.

1. Scegli l'identificatore nella colonna **Server ID** per visualizzare la pagina dei **dettagli del server**.

1. In **Utenti**, scegli un nome utente per visualizzare la pagina dei **dettagli dell'utente**.

1. Per eliminare una chiave pubblica, seleziona la casella di controllo della relativa chiave SSH e scegli **Elimina**.

# Lavorare con provider di identità personalizzati
<a name="custom-idp-intro"></a>

AWS Transfer Family offre diverse opzioni ai provider di identità personalizzati per autenticare e autorizzare gli utenti a trasferimenti sicuri di file. Ecco gli approcci principali:
+ [Soluzione personalizzata per provider di identità](custom-idp-toolkit.md)—Questo argomento descrive la soluzione di provider di identità personalizzato Transfer Family, utilizzando un toolkit ospitato in. GitHub
**Nota**  
Per la maggior parte dei casi d'uso, questa è l'opzione consigliata. In particolare, se è necessario supportare più di 100 gruppi Active Directory, la soluzione di provider di identità personalizzata offre un'alternativa scalabile senza limitazioni di gruppo. Questa soluzione è descritta nel post del blog, [Simplify Active Directory authentication with a custom identity provider for AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).
+ [Utilizzo di Amazon API Gateway per integrare il tuo provider di identità](authentication-api-gateway.md)—Questo argomento descrive come utilizzare una AWS Lambda funzione per supportare un metodo Amazon API Gateway.

  Puoi fornire RESTful un'interfaccia con un unico metodo Amazon API Gateway. Transfer Family utilizza questo metodo per connettersi al tuo provider di identità, che autentica e autorizza gli utenti ad accedere ad Amazon S3 o Amazon EFS. Utilizza questa opzione se hai bisogno di un' RESTful API per integrare il tuo provider di identità o se desideri utilizzarla per sfruttarne le funzionalità per il blocco AWS WAF geografico o le richieste di limitazione della velocità. Per informazioni dettagliate, vedi [Utilizzo di Amazon API Gateway per integrare il tuo provider di identità](authentication-api-gateway.md).
+ [Approcci di gestione dinamica delle autorizzazioni](dynamic-permission-management.md): questo argomento descrive gli approcci per la gestione dinamica delle autorizzazioni degli utenti utilizzando le policy di sessione.

  Per autenticare gli utenti, puoi utilizzare il tuo provider di identità esistente con. AWS Transfer Family Integri il tuo provider di identità utilizzando una AWS Lambda funzione che autentica e autorizza gli utenti ad accedere ad Amazon S3 o Amazon Elastic File System (Amazon EFS). Per informazioni dettagliate, vedi [Utilizzo AWS Lambda per integrare il tuo provider di identità](custom-lambda-idp.md). Puoi anche accedere a CloudWatch grafici per metriche come il numero di file e byte trasferiti nella Console di AWS Transfer Family gestione, offrendoti un unico pannello di controllo per monitorare i trasferimenti di file utilizzando una dashboard centralizzata.
+ Transfer Family offre un post sul blog e un workshop che ti guidano nella creazione di una soluzione per il trasferimento di file. Questa soluzione sfrutta gli SFTP/FTPS endpoint gestiti e Amazon Cognito e DynamoDB AWS Transfer Family per la gestione degli utenti. 

  Il post del blog è disponibile in [Utilizzo di Amazon Cognito come provider di identità con AWS Transfer Family Amazon S3](https://aws.amazon.com/blogs/storage/using-amazon-cognito-as-an-identity-provider-with-aws-transfer-family-and-amazon-s3/). [Puoi visualizzare i dettagli del workshop qui.](https://catalog.workshops.aws/transfer-family-sftp/en-US) 

**Nota**  
Per i provider di identità personalizzati, il nome utente deve contenere da un minimo di 3 a un massimo di 100 caratteri. È possibile utilizzare i seguenti caratteri nel nome utente: a—z, A-Z, 0—9, carattere di sottolineatura '\$1', trattino '-', punto '.' e nel segno '@'. Il nome utente non può iniziare con un trattino '-', punto '.' o dal segno '@'.

Quando implementi un provider di identità personalizzato, prendi in considerazione le seguenti best practice:
+ Implementa la soluzione nella stessa Account AWS area geografica dei tuoi server Transfer Family.
+ Implementa il principio del privilegio minimo durante la configurazione dei ruoli e delle policy IAM.
+ Utilizza funzionalità come l'elenco degli indirizzi IP consentiti e la registrazione standardizzata per una maggiore sicurezza.
+ Testa a fondo il tuo provider di identità personalizzato in un ambiente non di produzione prima della distribuzione.

**Topics**
+ [Soluzione personalizzata per provider di identità](custom-idp-toolkit.md)
+ [Utilizzo AWS Lambda per integrare il tuo provider di identità](custom-lambda-idp.md)
+ [Utilizzo di Amazon API Gateway per integrare il tuo provider di identità](authentication-api-gateway.md)
+ [Utilizzo di più metodi di autenticazione](custom-idp-mfa.md)
+ [IPv6 supporto per provider di identità personalizzati](custom-idp-ipv6.md)

# Soluzione personalizzata per provider di identità
<a name="custom-idp-toolkit"></a>

La soluzione AWS Transfer Family Custom Identity Provider è una soluzione modulare per provider di identità personalizzati che risolve molti casi d'uso comuni di autenticazione e autorizzazione delle aziende durante l'implementazione del servizio. Questa soluzione fornisce una base riutilizzabile per l'implementazione di provider di identità personalizzati con configurazione granulare delle sessioni per utente e separa la logica di autenticazione e autorizzazione, offrendo una base flessibile per vari casi d'uso. easy-to-maintain 

Con la soluzione AWS Transfer Family Custom Identity Provider, è possibile risolvere i casi d'uso comuni di autenticazione e autorizzazione aziendali. Questa soluzione modulare offre:
+ Una base riutilizzabile per l'implementazione di provider di identità personalizzati 
+ Configurazione granulare della sessione per utente 
+ Logica di autenticazione e autorizzazione separate 

## Dettagli di implementazione per il toolkit di identità personalizzato
<a name="idp-toolkit-implementation-details"></a>

La soluzione fornisce una base flessibile e gestibile per vari casi d'uso. [Per iniziare, consulta il toolkit su [https://github.com/aws-samples/toolkit-for-aws-transfer-family](https://github.com/aws-samples/toolkit-for-aws-transfer-family), quindi segui le istruzioni di distribuzione nella sezione Guida introduttiva.](https://github.com/aws-samples/toolkit-for-aws-transfer-family/tree/main/solutions/custom-idp#getting-started)

![\[Diagramma di architettura per il toolkit personalizzato per provider di identità disponibile in. GitHub\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/custom-idp-solution-high-level-architecture.png)


**Nota**  
Se in precedenza hai utilizzato modelli ed esempi di provider di identità personalizzati, prendi in considerazione l'adozione di questa soluzione. In futuro, i moduli specifici del provider si standardizzeranno su questa soluzione. La manutenzione continua e i miglioramenti delle funzionalità verranno applicati a questa soluzione.

Questa soluzione contiene modelli standard per l'implementazione di un provider personalizzato che tenga conto dei dettagli, inclusa la registrazione, e della posizione in cui archiviare i metadati di sessione aggiuntivi necessari AWS Transfer Family, come il parametro. `HomeDirectoryDetails` Questa soluzione fornisce una base riutilizzabile per l'implementazione di provider di identità personalizzati con una configurazione granulare della sessione per utente e disaccoppia la logica di autenticazione del provider di identità dalla logica riutilizzabile che crea una configurazione che viene restituita a Transfer Family per completare l'autenticazione e stabilire le impostazioni per la sessione. 

[Il codice e le risorse di supporto per questa soluzione sono disponibili su -family. https://github.com/aws-samples/ toolkit-for-aws-transfer](https://github.com/aws-samples/toolkit-for-aws-transfer-family)

Il toolkit contiene le seguenti funzionalità:
+ Un [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam)modello che fornisce le risorse necessarie. Facoltativamente, distribuisci e configura Amazon API Gateway da incorporare AWS WAF, come descritto nel post del blog [Securing AWS Transfer Family with AWS Web Application Firewall and Amazon](https://aws.amazon.com/blogs/storage/securing-aws-transfer-family-with-aws-web-application-firewall-and-amazon-api-gateway/) API Gateway.
+ Uno schema [Amazon DynamoDB](https://aws.amazon.com/dynamodb) per archiviare i metadati di configurazione sui provider di identità, incluse le impostazioni delle sessioni utente come`HomeDirectoryDetails`, e. `Role` `Policy`
+ Un approccio modulare che consente di aggiungere nuovi provider di identità alla soluzione in futuro, sotto forma di moduli.
+ Recupero degli attributi: recupera facoltativamente gli attributi del ruolo IAM e del profilo POSIX (UID e GID) dai provider di identità supportati, tra cui AD, LDAP e Okta.
+ Supporto per più provider di identità connessi a un singolo server Transfer Family e a più server Transfer Family utilizzando la stessa implementazione della soluzione.
+ Controllo integrato degli elenchi di indirizzi IP consentiti, ad esempio gli elenchi di indirizzi IP consentiti che possono essere configurati facoltativamente per utente o per provider di identità.
+ Registrazione dettagliata con supporto configurabile a livello di registro e tracciamento per facilitare la risoluzione dei problemi.

Prima di iniziare a implementare la soluzione personalizzata per un provider di identità, è necessario disporre delle seguenti risorse. AWS 
+ Un Amazon Virtual Private Cloud (VPC) con sottoreti private, con connettività Internet tramite un gateway NAT o un endpoint gateway DynamoDB.
+ Autorizzazioni IAM appropriate per eseguire le seguenti attività:
  + Implementa il modello, `custom-idp.yaml` CloudFormation 
  + Crea progetti AWS CodePipeline 
  + Crea AWS CodeBuild progetti
  + Crea ruoli e politiche IAM

**Importante**  
È necessario distribuire la soluzione sullo stesso Account AWS server Transfer Family Regione AWS che contiene i server Transfer Family di destinazione.

## Provider di identità supportati
<a name="custom-supported-idp"></a>

L'elenco seguente contiene i dettagli dei provider di identità supportati per la soluzione di provider di identità personalizzata.


| Provider | Flussi di password | Flussi a chiave pubblica | Multifattoriale | Recupero degli attributi | Informazioni | 
| --- | --- | --- | --- | --- | --- | 
| Active Directory e LDAP | Sì  | Sì | No | Sì | La verifica degli utenti può essere eseguita come parte del flusso di autenticazione a chiave pubblica. | 
| Argon2 (hash locale) | Sì | No | No | No | Gli hash Argon2 vengono memorizzati nel record utente per i casi d'uso di autenticazione «locale» basata su password. | 
| Amazon Cognito | Sì | No | Sì\$1 | No | Solo autenticazione a più fattori basata su Time-based One-Time Password (TOTP). \$1La MFA basata su SMS non è supportata. | 
| Entra ID (in precedenza Azure AD) | Sì | No | No | No |  | 
| Okta | Sì  | Sì | Sì\$1 | Sì | Solo MFA basata su TOTP. | 
| Chiavi pubbliche | No | Sì | No | No | Le chiavi pubbliche sono archiviate nel record utente in DynamoDB. | 
| Secrets Manager | Sì  | Sì | No | No |  | 

# Utilizzo AWS Lambda per integrare il tuo provider di identità
<a name="custom-lambda-idp"></a>

Questo argomento descrive come creare una AWS Lambda funzione che si connetta al provider di identità personalizzato. Puoi utilizzare qualsiasi provider di identità personalizzato, come Okta, Secrets Manager OneLogin, o un data store personalizzato che includa la logica di autorizzazione e autenticazione.

Nella maggior parte dei casi d'uso, il modo consigliato per configurare un provider di identità personalizzato consiste nell'utilizzare il[Soluzione personalizzata per provider di identità](custom-idp-toolkit.md).

**Nota**  
Prima di creare un server Transfer Family che utilizza Lambda come provider di identità, è necessario creare la funzione. Per un esempio di funzione Lambda, consulta [Esempi di funzioni Lambda](#lambda-auth-examples). In alternativa, puoi distribuire uno CloudFormation stack che utilizza uno dei. [Modelli di funzioni Lambda](#lambda-idp-templates) Inoltre, assicurati che la tua funzione Lambda utilizzi una politica basata sulle risorse che si affidi a Transfer Family. Per un esempio di policy, consulta [Policy Lambda basata sulle risorse](#lambda-resource-policy).

1. Apri la [AWS Transfer Family console](https://console.aws.amazon.com/transfer/).

1. **Scegli **Crea server per** aprire la pagina Crea server.** Per **Scegli un provider di identità**, scegli **Custom Identity Provider**, come mostrato nella schermata seguente.  
![\[La sezione Scegli una console con provider di identità con Provider di identità personalizzato selezionato. È inoltre selezionato il valore predefinito, ovvero che gli utenti possono autenticarsi utilizzando la password o la chiave.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/custom-lambda-console.png)
**Nota**  
La scelta dei metodi di autenticazione è disponibile solo se abiliti SFTP come uno dei protocolli per il tuo server Transfer Family.

1. Assicurati che il valore predefinito, **Usa AWS Lambda per connettere il tuo provider di identità**, sia selezionato.

1. Per **AWS Lambda la funzione**, scegli il nome della tua funzione Lambda.

1. Compila le caselle rimanenti, quindi scegli **Crea server**. Per i dettagli sui passaggi rimanenti per la creazione di un server, consulta[Configurazione di un endpoint server SFTP, FTPS o FTP](tf-server-endpoint.md).

## Policy Lambda basata sulle risorse
<a name="lambda-resource-policy"></a>

È necessario disporre di una politica che faccia riferimento al server Transfer Family e a ARNs Lambda. Ad esempio, puoi utilizzare la seguente politica con la funzione Lambda che si connette al tuo provider di identità. La policy viene salvata in formato JSON come stringa.

****  

```
"Policy":
"{\"Version\":\"2012-10-17\",
\"Id\":\"default\",
\"Statement\":[
  {\"Sid\":\"AllowTransferInvocation\",
  \"Effect\":\"Allow\",
  \"Principal\":{\"Service\":\"transfer.amazonaws.com\"},
  \"Action\":\"lambda:InvokeFunction\",
  \"Resource\":\"arn:aws:lambda:region:123456789012:function:my-lambda-auth-function\",
  \"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:transfer:region:123456789012:server/server-id\"}}}
]}"
```

**Nota**  
Nella politica di esempio precedente, sostituisci ciascuna di esse *user input placeholder* con le tue informazioni.

## Struttura del messaggio di evento
<a name="event-message-structure"></a>

La struttura dei messaggi di evento dal server SFTP inviati alla funzione di autorizzazione Lambda per un IDP personalizzato è la seguente.

```
{
    "username": "value",
    "password": "value",
    "protocol": "SFTP",
    "serverId": "s-abcd123456",
    "sourceIp": "192.168.0.100"
}
```

Dove `username` e `password` sono i valori per le credenziali di accesso inviate al server.

Ad esempio, si immette il seguente comando per connettersi:

```
sftp bobusa@server_hostname
```

Ti viene quindi richiesto di inserire la password:

```
Enter password:
    mysecretpassword
```

Puoi verificarlo dalla tua funzione Lambda stampando l'evento passato dall'interno della funzione Lambda. Dovrebbe essere simile al seguente blocco di testo.

```
{
    "username": "bobusa",
    "password": "mysecretpassword",
    "protocol": "SFTP",
    "serverId": "s-abcd123456",
    "sourceIp": "192.168.0.100"
}
```

La struttura degli eventi è simile per FTP e FTPS: l'unica differenza è che i valori vengono utilizzati per il `protocol` parametro, anziché SFTP.

## Funzioni Lambda per l'autenticazione
<a name="authentication-lambda-examples"></a>

Per implementare diverse strategie di autenticazione, modifica la funzione Lambda. Per aiutarti a soddisfare le esigenze della tua applicazione, puoi implementare uno CloudFormation stack. Per ulteriori informazioni su Lambda, consulta la [AWS Lambda Developer Guide o Building](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) [Lambda functions with Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html).

**Topics**
+ [Valori Lambda validi](#lambda-valid-values)
+ [Esempi di funzioni Lambda](#lambda-auth-examples)
+ [Verifica della configurazione](#authentication-test-configuration)
+ [Modelli di funzioni Lambda](#lambda-idp-templates)

### Valori Lambda validi
<a name="lambda-valid-values"></a>

La tabella seguente descrive i dettagli dei valori che Transfer Family accetta per le funzioni Lambda utilizzate per i provider di identità personalizzati.


|  Valore  |  Description  |  Richiesto  | 
| --- | --- | --- | 
|  `Role`  |  Speciifica l'Amazon Resource Name (ARN) del ruolo IAM che controlla l'accesso degli utenti al bucket Amazon S3 o al file system Amazon EFS. Le policy associate a questo ruolo determinano il livello di accesso che desideri fornire ai tuoi utenti durante il trasferimento di file da e verso il tuo file system Amazon S3 o Amazon EFS. Il ruolo IAM deve contenere anche una relazione di trust che consente al server di accedere alle proprie risorse durante la manutenzione delle richieste di trasferimento degli utenti. Per i dettagli su come stabilire una relazione di fiducia, consulta. [Per stabilire una relazione di trust](requirements-roles.md#establish-trust-transfer)  |  Richiesto  | 
|  `PosixProfile`  |  L'identità POSIX completa, inclusi ID utente (`Uid`), ID gruppo (`Gid`) ed eventuali gruppi secondari IDs (`SecondaryGids`), che controlla l'accesso degli utenti ai file system Amazon EFS. Le autorizzazioni POSIX impostate su file e directory nel file system determinano il livello di accesso che gli utenti ottengono durante il trasferimento dei file da e verso i file system Amazon EFS.  |  Necessario per lo storage di backup di Amazon EFS  | 
|  `PublicKeys`  |  Un elenco di valori di chiave pubblica SSH validi per questo utente. Un elenco vuoto implica che non si tratta di un accesso valido. Non deve essere restituito durante l'autenticazione della password.  |  Facoltativo  | 
|  `Policy`  |  Una politica di sessione per il tuo utente in modo da poter utilizzare lo stesso ruolo IAM su più utenti. Questa policy definisce gli ambiti di accesso degli utenti alle porzioni dei loro bucket di Amazon S3. Per ulteriori informazioni sull'utilizzo delle policy di sessione con provider di identità personalizzati, consulta gli esempi di policy di sessione in questo argomento.  |  Facoltativo  | 
|  `HomeDirectoryType`  |  Il tipo di directory (cartella) di destinazione in cui deve trovarsi la directory home degli utenti quando accedono al server. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/custom-lambda-idp.html)  |  Facoltativo  | 
|  `HomeDirectoryDetails`  |  Mappature di directory logiche che specificano quali percorsi e chiavi di Amazon S3 o Amazon EFS devono essere visibili all'utente e in che modo desideri renderli visibili. È necessario specificare la `Target` coppia `Entry` and, dove `Entry` mostra come il percorso viene reso visibile ed `Target` è il percorso effettivo di Amazon S3 o Amazon EFS.  |  Obbligatorio se `HomeDirectoryType` ha un valore di `LOGICAL`  | 
|  `HomeDirectory`  |  La directory di destinazione di un utente quando accede al server utilizzando il client. Il formato dipende dal backend di archiviazione: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/custom-lambda-idp.html)  Il nome del bucket o l'ID del file system Amazon EFS devono essere inclusi nel percorso. L'omissione di queste informazioni comporterà l'errore «File non trovato» durante i trasferimenti di file.   |  Facoltativo  | 

**Nota**  
`HomeDirectoryDetails`è una rappresentazione in formato stringa di una mappa JSON. Ciò è in contrasto con`PosixProfile`, che è un vero oggetto della mappa JSON e `PublicKeys` che è un array di stringhe JSON. Vedi gli esempi di codice per i dettagli specifici della lingua.

**HomeDirectory Requisiti di formato**  
Quando utilizzate il `HomeDirectory` parametro, assicuratevi di includere il formato completo del percorso:  
**Per lo storage Amazon S3:** includi sempre il nome del bucket nel formato `/bucket-name/path`
**Per lo storage Amazon EFS:** includi sempre l'ID del file system nel formato `/fs-12345/path`
Una causa comune degli errori «File not found» è l'omissione del nome del bucket o dell'ID del file system EFS dal `HomeDirectory` percorso. Se `HomeDirectory` si imposta su «Solo `/` senza l'identificatore di archiviazione», l'autenticazione avrà esito positivo, ma le operazioni sui file falliranno.

### Esempi di funzioni Lambda
<a name="lambda-auth-examples"></a>

Questa sezione presenta alcuni esempi di funzioni Lambda, sia in NodeJS che in Python.

**Nota**  
In questi esempi, i dettagli relativi all'utente, al ruolo, al profilo POSIX, alla password e alla home directory sono tutti esempi e devono essere sostituiti con i valori effettivi.

------
#### [ Logical home directory, NodeJS ]

[La seguente funzione di esempio NodeJS fornisce i dettagli per un utente che dispone di una home directory logica.](https://docs.aws.amazon.com/transfer/latest/userguide/logical-dir-mappings.html) 

```
// GetUserConfig Lambda

exports.handler = (event, context, callback) => {
  console.log("Username:", event.username, "ServerId: ", event.serverId);

  var response;
  // Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
  if (event.serverId !== "" && event.username == 'example-user') {
    var homeDirectoryDetails = [
      {
        Entry: "/",
        Target: "/fs-faa1a123"
      }
    ];
    response = {
      Role: 'arn:aws:iam::123456789012:role/transfer-access-role', // The user is authenticated if and only if the Role field is not blank
      PosixProfile: {"Gid": 65534, "Uid": 65534}, // Required for EFS access, but not needed for S3
      HomeDirectoryDetails: JSON.stringify(homeDirectoryDetails),
      HomeDirectoryType: "LOGICAL",
    };

    // Check if password is provided
    if (!event.password) {
      // If no password provided, return the user's SSH public key
      response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ];
    // Check if password is correct
    } else if (event.password !== 'Password1234') {
      // Return HTTP status 200 but with no role in the response to indicate authentication failure
      response = {};
    }
  } else {
    // Return HTTP status 200 but with no role in the response to indicate authentication failure
    response = {};
  }
  callback(null, response);
};
```

------
#### [ Path-based home directory, NodeJS ]

La seguente funzione di esempio NodeJS fornisce i dettagli per un utente che dispone di una home directory basata su percorsi. 

```
// GetUserConfig Lambda

exports.handler = (event, context, callback) => {
  console.log("Username:", event.username, "ServerId: ", event.serverId);

  var response;
  // Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
  // There is also event.protocol (one of "FTP", "FTPS", "SFTP") and event.sourceIp (e.g., "127.0.0.1") to further restrict logins.
  if (event.serverId !== "" && event.username == 'example-user') {
    response = {
      Role: 'arn:aws:iam::123456789012:role/transfer-access-role', // The user is authenticated if and only if the Role field is not blank
      Policy: '', // Optional, JSON stringified blob to further restrict this user's permissions
      // HomeDirectory format depends on your storage backend:
      // For S3: '/bucket-name/user-home-directory' (e.g., '/my-transfer-bucket/users/john')
      // For EFS: '/fs-12345/user-home-directory' (e.g., '/fs-faa1a123/users/john')
      HomeDirectory: '/my-transfer-bucket/users/example-user' // S3 example - replace with your bucket name
      // HomeDirectory: '/fs-faa1a123/users/example-user' // EFS example - uncomment for EFS
    };
    
    // Check if password is provided
    if (!event.password) {
      // If no password provided, return the user's SSH public key
     response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ];
    // Check if password is correct
    } else if (event.password !== 'Password1234') {
      // Return HTTP status 200 but with no role in the response to indicate authentication failure
      response = {};
    } 
  } else {
    // Return HTTP status 200 but with no role in the response to indicate authentication failure
    response = {};
  }
  callback(null, response);
};
```

------
#### [ Logical home directory, Python ]

La seguente funzione di esempio in Python fornisce i dettagli per un utente che ha una [home directory logica](https://docs.aws.amazon.com/transfer/latest/userguide/logical-dir-mappings.html). 

```
# GetUserConfig Python Lambda with LOGICAL HomeDirectoryDetails
import json

def lambda_handler(event, context):
  print("Username: {}, ServerId: {}".format(event['username'], event['serverId']))

  response = {}

  # Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
  if event['serverId'] != '' and event['username'] == 'example-user':
    homeDirectoryDetails = [
      {
        'Entry': '/',
        'Target': '/fs-faa1a123'
      }
    ]
    response = {
      'Role': 'arn:aws:iam::123456789012:role/transfer-access-role', # The user will be authenticated if and only if the Role field is not blank
      'PosixProfile': {"Gid": 65534, "Uid": 65534}, # Required for EFS access, but not needed for S3
      'HomeDirectoryDetails': json.dumps(homeDirectoryDetails),
      'HomeDirectoryType': "LOGICAL"
    }

    # Check if password is provided
    if event.get('password', '') == '':
      # If no password provided, return the user's SSH public key
     response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ]
    # Check if password is correct
    elif event['password'] != 'Password1234':
      # Return HTTP status 200 but with no role in the response to indicate authentication failure
      response = {}
  else:
    # Return HTTP status 200 but with no role in the response to indicate authentication failure
    response = {}

  return response
```

------
#### [ Path-based home directory, Python ]

La seguente funzione di esempio in Python fornisce i dettagli per un utente che dispone di una home directory basata su percorsi. 

```
# GetUserConfig Python Lambda with PATH HomeDirectory

def lambda_handler(event, context):
  print("Username: {}, ServerId: {}".format(event['username'], event['serverId']))

  response = {}

  # Check if the username presented for authentication is correct. This doesn't check the value of the server ID, only that it is provided.
  # There is also event.protocol (one of "FTP", "FTPS", "SFTP") and event.sourceIp (e.g., "127.0.0.1") to further restrict logins.
  if event['serverId'] != '' and event['username'] == 'example-user':
    response = {
      'Role': 'arn:aws:iam::123456789012:role/transfer-access-role', # The user will be authenticated if and only if the Role field is not blank
      'Policy': '', #  Optional, JSON stringified blob to further restrict this user's permissions
      # HomeDirectory format depends on your storage backend:
      # For S3: '/bucket-name/user-home-directory' (e.g., '/my-transfer-bucket/users/john')
      # For EFS: '/fs-12345/user-home-directory' (e.g., '/fs-faa1a123/users/john')
      'HomeDirectory': '/my-transfer-bucket/users/example-user', # S3 example - replace with your bucket name
      # 'HomeDirectory': '/fs-faa1a123/users/example-user', # EFS example - uncomment for EFS
      'HomeDirectoryType': "PATH" # Not strictly required, defaults to PATH
    }
    
    # Check if password is provided
    if event.get('password', '') == '':
      # If no password provided, return the user's SSH public key
     response['PublicKeys'] = [ "ssh-rsa abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789" ]
    # Check if password is correct
    elif event['password'] != 'Password1234':
      # Return HTTP status 200 but with no role in the response to indicate authentication failure
      response = {}
  else:
    # Return HTTP status 200 but with no role in the response to indicate authentication failure
    response = {}

  return response
```

------

### Verifica della configurazione
<a name="authentication-test-configuration"></a>

Dopo aver creato il tuo provider di identità personalizzato, dovresti testare la configurazione.

------
#### [ Console ]

**Per testare la configurazione utilizzando la AWS Transfer Family console**

1. Apri la [AWS Transfer Family console](https://console.aws.amazon.com/transfer/). 

1. Nella pagina **Server**, scegli il tuo nuovo server, scegli **Azioni**, quindi scegli **Test**.

1. Inserisci il testo per **nome utente** e **password** che hai impostato quando hai distribuito lo CloudFormation stack. Se hai mantenuto le opzioni predefinite, il nome utente è `myuser` e la password è. `MySuperSecretPassword`

1. Scegli il **protocollo Server** e inserisci l'indirizzo IP per l'**IP di origine**, se lo hai impostato quando hai distribuito lo CloudFormation stack.

------
#### [ CLI ]

**Per testare la configurazione utilizzando la AWS CLI**

1. Esegui il comando [test-identity-provider](https://docs.aws.amazon.com/cli/latest/reference/transfer/test-identity-provider.html). Sostituisci ognuna `user input placeholder` con le tue informazioni, come descritto nei passaggi successivi.

   ```
   aws transfer test-identity-provider --server-id s-1234abcd5678efgh --user-name myuser --user-password MySuperSecretPassword --server-protocol FTP --source-ip 127.0.0.1
   ```

1. Inserisci l'ID del server.

1. Inserisci il nome utente e la password che hai impostato quando hai distribuito lo CloudFormation stack. Se hai mantenuto le opzioni predefinite, il nome utente è `myuser` e la password è. `MySuperSecretPassword`

1. Inserisci il protocollo del server e l'indirizzo IP di origine, se li hai impostati quando hai distribuito lo CloudFormation stack.

------

Se l'autenticazione dell'utente ha esito positivo, il test restituisce una risposta `StatusCode: 200` HTTP, una stringa vuota `Message: ""` (che altrimenti conterrebbe un motivo dell'errore) e un campo. `Response`

**Nota**  
 Nell'esempio di risposta riportato di seguito, il `Response` campo è un oggetto JSON che è stato «stringato» (convertito in una stringa JSON flat che può essere utilizzata all'interno di un programma) e contiene i dettagli dei ruoli e delle autorizzazioni dell'utente.

```
{
    "Response":"{\"Policy\":\"{\\\"Version\\\":\\\"2012-10-17\\\",\\\"Statement\\\":[{\\\"Sid\\\":\\\"ReadAndListAllBuckets\\\",\\\"Effect\\\":\\\"Allow\\\",\\\"Action\\\":[\\\"s3:ListAllMybuckets\\\",\\\"s3:GetBucketLocation\\\",\\\"s3:ListBucket\\\",\\\"s3:GetObjectVersion\\\",\\\"s3:GetObjectVersion\\\"],\\\"Resource\\\":\\\"*\\\"}]}\",\"Role\":\"arn:aws:iam::000000000000:role/MyUserS3AccessRole\",\"HomeDirectory\":\"/\"}",
    "StatusCode": 200,
    "Message": ""
}
```

### Modelli di funzioni Lambda
<a name="lambda-idp-templates"></a>

È possibile distribuire uno CloudFormation stack che utilizza una funzione Lambda per l'autenticazione. Forniamo diversi modelli che autenticano e autorizzano gli utenti utilizzando le credenziali di accesso. Puoi modificare questi modelli o AWS Lambda codici per personalizzare ulteriormente l'accesso degli utenti.

**Nota**  
È possibile creare un AWS Transfer Family server compatibile con FIPS CloudFormation specificando una politica di sicurezza compatibile con FIPS nel modello. Le politiche di sicurezza disponibili sono descritte in [Politiche di sicurezza per i server AWS Transfer Family](security-policies.md) 

**Per creare uno CloudFormation stack da utilizzare per l'autenticazione**

1. Apri la CloudFormation console in [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)

1. *Segui le istruzioni per distribuire uno CloudFormation stack da un modello esistente in [Selezione di un modello di stack nella Guida](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html) per l'utente.AWS CloudFormation *

1. Utilizza uno dei seguenti modelli per creare una funzione Lambda da utilizzare per l'autenticazione in Transfer Family. 
   + [Modello di pila classico (Amazon Cognito)](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-cognito-s3.template.yml)

     Un modello di base per la creazione di un AWS Lambda file da utilizzare come provider di identità personalizzato in. AWS Transfer Family Si autentica con Amazon Cognito per l'autenticazione basata su password e le chiavi pubbliche vengono restituite da un bucket Amazon S3 se viene utilizzata l'autenticazione basata su chiave pubblica. Dopo la distribuzione, puoi modificare il codice della funzione Lambda per fare qualcosa di diverso.
   + [Gestione dei segreti AWS modello di pila](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-lambda.template.yml)

     Un modello di base che si utilizza AWS Lambda con un AWS Transfer Family server per integrare Secrets Manager come provider di identità. Si autentica in base a una voce Gestione dei segreti AWS del formato. `aws/transfer/server-id/username` Inoltre, il segreto deve contenere le coppie chiave-valore per tutte le proprietà utente restituite a Transfer Family. Dopo la distribuzione, puoi modificare il codice della funzione Lambda per fare qualcosa di diverso.
   + Modello [stack Okta: un modello](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-lambda.template.yml) di base che utilizza AWS Lambda un AWS Transfer Family server per integrare Okta come provider di identità personalizzato.
   + Modello di [stack Okta-MFA: un modello](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-mfa-lambda.template.yml) di base che viene utilizzato AWS Lambda con un AWS Transfer Family server per integrare Okta, con autenticazione a più fattori, come provider di identità personalizzato.
   + [Modello Azure Active Directory](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-lambda-azure-ad.template.yml)[: i dettagli per questo stack sono descritti nel post del blog Authenticating to with Azure Active Directory and. AWS Transfer FamilyAWS Lambda](https://aws.amazon.com/blogs/storage/authenticating-to-aws-transfer-family-with-azure-active-directory-and-aws-lambda/)

   **Dopo aver distribuito lo stack, puoi visualizzarne i dettagli nella scheda Output della console.** CloudFormation 

   L'implementazione di uno di questi stack è il modo più semplice per integrare un provider di identità personalizzato nel flusso di lavoro Transfer Family.

# Utilizzo di Amazon API Gateway per integrare il tuo provider di identità
<a name="authentication-api-gateway"></a>

Questo argomento descrive come utilizzare una AWS Lambda funzione per supportare un metodo API Gateway. Utilizza questa opzione se hai bisogno di un' RESTful API per integrare il tuo provider di identità o se desideri AWS WAF utilizzarla per sfruttare le sue funzionalità per il blocco geografico o le richieste di limitazione della velocità.

Nella maggior parte dei casi d'uso, il modo consigliato per configurare un provider di identità personalizzato consiste nell'utilizzare il. [Soluzione personalizzata per provider di identità](custom-idp-toolkit.md)

**Limitazioni relative all'utilizzo di un API Gateway per l'integrazione del provider di identità**
+ Questa configurazione non supporta domini personalizzati.
+ Questa configurazione non supporta un URL API Gateway privato.

Se hai bisogno di uno di questi, puoi usare Lambda come provider di identità, senza API Gateway. Per informazioni dettagliate, vedi [Utilizzo AWS Lambda per integrare il tuo provider di identità](custom-lambda-idp.md).

## Autenticazione tramite un metodo API Gateway
<a name="authentication-custom-ip"></a>

Puoi creare un metodo API Gateway da utilizzare come provider di identità per Transfer Family. Questo approccio offre un modo estremamente sicuro per creare e fornire APIs. Con API Gateway, puoi creare un endpoint HTTPS in modo che tutte le operazioni API in entrata vengano trasmesse con maggiore sicurezza. Per ulteriori dettagli sul servizio API Gateway, consulta la [API Gateway Developer Guide](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html).

API Gateway offre un metodo di autorizzazione denominato`AWS_IAM`, che offre la stessa autenticazione basata su AWS Identity and Access Management (IAM) AWS utilizzata internamente. Se abiliti l'autenticazione con`AWS_IAM`, solo i chiamanti con autorizzazioni esplicite per chiamare un'API possono raggiungere il metodo API Gateway dell'API.

Per utilizzare il tuo metodo API Gateway come provider di identità personalizzato per Transfer Family, abilita IAM per il tuo metodo API Gateway. Come parte di questo processo, fornisci a un ruolo IAM le autorizzazioni affinché Transfer Family utilizzi il tuo gateway.

**Nota**  
Per migliorare la sicurezza, puoi configurare un firewall per applicazioni Web. AWS WAF è un firewall per applicazioni Web che consente di monitorare le richieste HTTP e HTTPS inoltrate a un Amazon API Gateway. Per informazioni dettagliate, vedi [Aggiungi un firewall per applicazioni Web](web-application-firewall.md).

**Non abilitare la memorizzazione nella cache dell'API Gateway**  
Non abilitate la memorizzazione nella cache per il metodo API Gateway quando lo utilizzate come provider di identità personalizzato per Transfer Family. La memorizzazione nella cache è inappropriata e non valida per le richieste di autenticazione perché:  
Ogni richiesta di autenticazione è unica e richiede una risposta in tempo reale, non una risposta memorizzata nella cache
La memorizzazione nella cache non offre vantaggi poiché Transfer Family non invia mai richieste duplicate o ripetute all'API Gateway.
L'attivazione della memorizzazione nella cache farà sì che l'API Gateway risponda con dati non corrispondenti, con conseguenti risposte non valide alle richieste di autenticazione

**Per utilizzare il metodo API Gateway per l'autenticazione personalizzata con Transfer Family**

1. Crea uno CloudFormation stack. Per farlo:
**Nota**  
I modelli dello stack sono stati aggiornati per utilizzare password con BASE64 codifica: per i dettagli, consulta. [Miglioramenti ai modelli CloudFormation](#base64-templates)

   1. [Apri la console in CloudFormation /cloudformazione. https://console.aws.amazon.com](https://console.aws.amazon.com/cloudformation/)

   1. *Segui le istruzioni per distribuire uno CloudFormation stack da un modello esistente in [Selezione di un modello di stack nella Guida](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-template.html) per l'utente.AWS CloudFormation *

   1. Utilizza uno dei seguenti modelli di base per creare un metodo API Gateway AWS Lambda supportato da utilizzare come provider di identità personalizzato in Transfer Family.
      + [Modello di stack di base](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-basic-apig.template.yml)

        Per impostazione predefinita, il metodo API Gateway viene utilizzato come provider di identità personalizzato per autenticare un singolo utente in un singolo server utilizzando una chiave o una password SSH (Secure Shell) codificata. Dopo la distribuzione, puoi modificare il codice della funzione Lambda per fare qualcosa di diverso.
      + [Gestione dei segreti AWS modello di pila](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-apig.template.yml)

        Per impostazione predefinita, il metodo API Gateway si autentica con una voce in Secrets Manager del formato. `aws/transfer/server-id/username` Inoltre, il segreto deve contenere le coppie chiave-valore per tutte le proprietà utente restituite a Transfer Family. Dopo la distribuzione, puoi modificare il codice della funzione Lambda per fare qualcosa di diverso. Per ulteriori informazioni, consulta il post del blog [Abilita l'autenticazione tramite password per l' AWS Transfer Family utilizzo Gestione dei segreti AWS](https://aws.amazon.com/blogs/storage/enable-password-authentication-for-aws-transfer-family-using-aws-secrets-manager-updated/).
      + [Modello di stack Okta](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-okta-apig.template.yml)

        Il tuo metodo API Gateway si integra con Okta come provider di identità personalizzato in Transfer Family. Per ulteriori informazioni, consulta il post del blog [Utilizzo di Okta come provider di identità](https://aws.amazon.com/blogs/storage/using-okta-as-an-identity-provider-with-aws-transfer-for-sftp/) con. AWS Transfer Family

   L'implementazione di uno di questi stack è il modo più semplice per integrare un provider di identità personalizzato nel flusso di lavoro Transfer Family. Ogni stack utilizza la funzione Lambda per supportare il metodo API basato su API Gateway. Puoi quindi utilizzare il tuo metodo API come provider di identità personalizzato in Transfer Family. Per impostazione predefinita, la funzione Lambda autentica un singolo utente chiamato `myuser` con una password di. `MySuperSecretPassword` Dopo la distribuzione, puoi modificare queste credenziali o aggiornare il codice della funzione Lambda per fare qualcosa di diverso.
**Importante**  
Ti consigliamo di modificare le credenziali utente e password predefinite.

   Dopo aver distribuito lo stack, puoi visualizzarne i dettagli nella scheda **Output** della console. CloudFormation Questi dettagli includono l'Amazon Resource Name (ARN) dello stack, l'ARN del ruolo IAM creato dallo stack e l'URL del nuovo gateway.
**Nota**  
Se utilizzi l'opzione provider di identità personalizzato per abilitare l'autenticazione basata su password per i tuoi utenti e abiliti la registrazione di richieste e risposte fornita da API Gateway, API Gateway registra le password degli utenti nei tuoi Amazon Logs. CloudWatch Non è consigliabile utilizzare questo registro nel tuo ambiente di produzione. Per ulteriori informazioni, consulta [Configurare la registrazione delle CloudWatch API in API Gateway nella API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-logging.html) *Developer Guide*.

1. Controlla la configurazione del metodo API Gateway per il tuo server. Per farlo:

   1. Apri la console API Gateway all'indirizzo [https://console.aws.amazon.com/apigateway/](https://console.aws.amazon.com/apigateway/). 

   1. Scegli l'**API del modello di base di Transfer Custom Identity Provider** generata dal CloudFormation modello. Potrebbe essere necessario selezionare la regione per visualizzare i gateway.

   1. Nel riquadro **Risorse**, scegli **GET**. La schermata seguente mostra la configurazione corretta del metodo.  
![\[Dettagli di configurazione dell'API, che mostrano i parametri di configurazione del metodo per Request Paths e per la URL Query String.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/apig-config-method-fields.png)

   A questo punto, il gateway API è pronto per essere distribuito.

1. Per **Azioni**, scegli **Deploy API.** **Per la **fase di distribuzione**, scegli **prod**, quindi scegli Deploy.**

   Dopo che il metodo API Gateway è stato distribuito correttamente, visualizzane le prestazioni in **Stages** > **Stage details**, come mostrato nella schermata seguente.
**Nota**  
Copia l'indirizzo **URL di Invoke** visualizzato nella parte superiore dello schermo. Potresti averne bisogno per il passaggio successivo.  
![\[Dettagli dello stage con l'URL Invoke evidenziato.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/apig-config-method-invoke.png)

1. Apri la AWS Transfer Family console all'indirizzo [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. Una Transfer Family avrebbe dovuto essere creata per te quando hai creato lo stack. In caso contrario, configura il tuo server seguendo questi passaggi.

   1. Scegli **Crea server** per aprire la pagina **Crea server**. Per **Scegli un provider di identità**, scegli **Personalizzato**, quindi seleziona **Usa Amazon API Gateway per connetterti al tuo provider di identità**, come mostrato nella schermata seguente.  
![\[La schermata del provider di identità con Custom Identity Provider selezionato e con l'API Gateway scelto per la connessione al provider di identità.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/create-server-choose-idp-custom.png)

   1. Nella casella di testo **Fornisci un URL di Amazon API Gateway**, incolla l'indirizzo **URL Invoke** dell'endpoint API Gateway che hai creato nel passaggio 3 di questa procedura.

   1. Per **Ruolo**, scegli il ruolo IAM creato dal CloudFormation modello. Questo ruolo consente a Transfer Family di richiamare il metodo del gateway API.

      Il ruolo di invocazione contiene il nome CloudFormation dello stack selezionato per lo stack creato nel passaggio 1. Ha il seguente formato:. `CloudFormation-stack-name-TransferIdentityProviderRole-ABC123DEF456GHI`

   1. Compila le caselle rimanenti, quindi scegli **Crea server**. Per i dettagli sui passaggi rimanenti per la creazione di un server, consulta[Configurazione di un endpoint server SFTP, FTPS o FTP](tf-server-endpoint.md).

## Implementazione del metodo API Gateway
<a name="authentication-api-method"></a>

Per creare un provider di identità personalizzato per Transfer Family, il metodo API Gateway deve implementare un unico metodo con un percorso di risorse di`/servers/serverId/users/username/config`. I `username` valori `serverId` and provengono dal percorso delle RESTful risorse. Inoltre, aggiungete `sourceIp` e `protocol` come **parametri della stringa di query URL** nella **richiesta del metodo**, come mostrato nell'immagine seguente.

![\[La schermata Risorse dell'API Gateway che mostra i dettagli del GET metodo.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/apig-config-method-request.png)


**Nota**  
Il nome utente deve contenere un minimo di 3 e un massimo di 100 caratteri. È possibile utilizzare i seguenti caratteri nel nome utente: a—z, A-Z, 0—9, trattino basso '\$1', trattino '-', punto '.' e al segno '@'. Il nome utente non può iniziare con un trattino '-', punto '.' o dal segno '@'.

Se Transfer Family tenta l'autenticazione tramite password per l'utente, il servizio fornisce un campo di `Password:` intestazione. In assenza di un'`Password:`intestazione, Transfer Family tenta l'autenticazione a chiave pubblica per autenticare l'utente.

Quando utilizzi un provider di identità per autenticare e autorizzare gli utenti finali, oltre a convalidare le loro credenziali, puoi consentire o negare le richieste di accesso in base agli indirizzi IP dei client utilizzati dagli utenti finali. Puoi utilizzare questa funzionalità per assicurarti che i dati archiviati nei bucket S3 o nel file system Amazon EFS siano accessibili tramite i protocolli supportati solo da indirizzi IP che hai specificato come affidabili. Per abilitare questa funzionalità, devi includerla `sourceIp` nella stringa Query.

Se hai abilitato più protocolli per il tuo server e desideri fornire l'accesso utilizzando lo stesso nome utente su più protocolli, puoi farlo purché le credenziali specifiche per ogni protocollo siano state configurate nel tuo provider di identità. Per abilitare questa funzionalità, è necessario includere il `protocol` valore nel percorso della RESTful risorsa.

Il metodo API Gateway deve sempre restituire il codice di stato HTTP`200`. Qualsiasi altro codice di stato HTTP indica che si è verificato un errore durante l'accesso all'API.

**Esempio di risposta di Amazon S3**  
Il corpo della risposta di esempio è un documento JSON del seguente modulo per Amazon S3.

```
{
 "Role": "IAM role with configured S3 permissions",
 "PublicKeys": [
     "ssh-rsa public-key1",
     "ssh-rsa public-key2"
  ],
 "Policy": "STS Assume role session policy",
 "HomeDirectory": "/amzn-s3-demo-bucket/path/to/home/directory"
}
```

**Nota**  
 La policy viene salvata in formato JSON come stringa. Esempio:   

****  

```
"Policy":
"{
  \"Version\": \"2012-10-17\",
  \"Statement\":
     [
     {\"Condition\":
        {\"StringLike\":
            {\"s3:prefix\":
               [\"user/*\", \"user/\"]}},
     \"Resource\": \"arn:aws:s3:::amzn-s3-demo-bucket\",
     \"Action\": \"s3:ListBucket\",
     \"Effect\": \"Allow\",
     \"Sid\": \"ListHomeDir\"},
     {\"Resource\": \"arn:aws:s3:::*\",
        \"Action\": [\"s3:PutObject\",
        \"s3:GetObject\",
        \"s3:DeleteObjectVersion\",
        \"s3:DeleteObject\",
        \"s3:GetObjectVersion\",
        \"s3:GetObjectACL\",
        \"s3:PutObjectACL\"],
     \"Effect\": \"Allow\",
     \"Sid\": \"HomeDirObjectAccess\"}]
}"
```

Il seguente esempio di risposta mostra che un utente ha un tipo di home directory logica.

```
{
   "Role": "arn:aws:iam::123456789012:role/transfer-access-role-s3",
   "HomeDirectoryType":"LOGICAL",
   "HomeDirectoryDetails":"[{\"Entry\":\"/\",\"Target\":\"/amzn-s3-demo-bucket1\"}]",
   "PublicKeys":[""]
}
```

**Esempio di risposta Amazon EFS**  
Il corpo della risposta di esempio è un documento JSON del seguente modulo per Amazon EFS.

```
{
 "Role": "IAM role with configured EFS permissions",
 "PublicKeys": [
     "ssh-rsa public-key1",
     "ssh-rsa public-key2"
  ],
 "PosixProfile": {
   "Uid": "POSIX user ID",
   "Gid": "POSIX group ID",
   "SecondaryGids": [Optional list of secondary Group IDs],
 },
 "HomeDirectory": "/fs-id/path/to/home/directory"
}
```

Il `Role` campo mostra che l'autenticazione è avvenuta con successo. Quando si esegue l'autenticazione con password (quando si fornisce un'`Password:`intestazione), non è necessario fornire chiavi pubbliche SSH. Se un utente non può essere autenticato, ad esempio, se la password non è corretta, il metodo dovrebbe restituire una risposta senza set. `Role` Un esempio di tale risposta è un oggetto JSON vuoto.

 Il seguente esempio di risposta mostra un utente con un tipo di home directory logica. 

```
{
    "Role": "arn:aws:iam::123456789012:role/transfer-access-role-efs",
    "HomeDirectoryType": "LOGICAL",
    "HomeDirectoryDetails":"[{\"Entry\":\"/\",\"Target\":\"/faa1a123\"}]",
    "PublicKeys":[""],
    "PosixProfile":{"Uid":65534,"Gid":65534}
}
```

È possibile includere politiche utente nella funzione Lambda in formato JSON. Per ulteriori informazioni sulla configurazione delle politiche utente in Transfer Family, vedere[Gestione dei controlli di accesso](users-policies.md).

## Funzione Lambda predefinita
<a name="authentication-lambda-examples-default"></a>

Per implementare diverse strategie di autenticazione, modifica la funzione Lambda utilizzata dal gateway. Per aiutarti a soddisfare le esigenze della tua applicazione, puoi utilizzare le funzioni Lambda di esempio seguenti in Node.js. Per ulteriori informazioni su Lambda, consulta la [AWS Lambda Developer Guide o Building](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) [Lambda functions with Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html).

L'esempio seguente della funzione Lambda utilizza il nome utente, la password (se si esegue l'autenticazione tramite password), l'ID del server, il protocollo e l'indirizzo IP del client. Puoi utilizzare una combinazione di questi input per cercare il tuo provider di identità e determinare se l'accesso deve essere accettato.

**Nota**  
Se hai abilitato più protocolli per il tuo server e desideri fornire l'accesso utilizzando lo stesso nome utente su più protocolli, puoi farlo purché le credenziali specifiche del protocollo siano state configurate nel tuo provider di identità.  
Per File Transfer Protocol (FTP), consigliamo di mantenere credenziali separate da Secure Shell (SSH) File Transfer Protocol (SFTP) e File Transfer Protocol over SSL (FTPS). Consigliamo di mantenere credenziali separate per FTP perché, a differenza di SFTP e FTPS, FTP trasmette le credenziali in testo non crittografato. Isolando le credenziali FTP da SFTP o FTPS, se le credenziali FTP sono condivise o esposte, i carichi di lavoro che utilizzano SFTP o FTPS rimangono sicuri.

Questa funzione di esempio restituisce il ruolo e i dettagli logici della home directory, insieme alle chiavi pubbliche (se esegue l'autenticazione a chiave pubblica).

Quando si creano utenti gestiti dai servizi, si imposta la loro home directory, logica o fisica. Allo stesso modo, abbiamo bisogno dei risultati della funzione Lambda per comunicare la struttura di directory fisica o logica desiderata dall'utente. I parametri impostati dipendono dal valore del campo. [https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryType](https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryType)
+ `HomeDirectoryType`impostato su`PATH`: il `HomeDirectory` campo deve quindi essere un prefisso assoluto del bucket Amazon S3 o un percorso assoluto di Amazon EFS visibile ai tuoi utenti.
+ `HomeDirectoryType`impostato su `LOGICAL` — *Non* impostare un campo. `HomeDirectory` Invece, impostiamo un `HomeDirectoryDetails` campo che fornisce le Entry/Target mappature desiderate, simili ai valori descritti nel [https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryMappings](https://docs.aws.amazon.com//transfer/latest/APIReference/API_CreateUser.html#TransferFamily-CreateUser-request-HomeDirectoryMappings)parametro per gli utenti gestiti dal servizio.

Le funzioni di esempio sono elencate in. [Esempi di funzioni Lambda](custom-lambda-idp.md#lambda-auth-examples)

## Funzione Lambda da utilizzare con Gestione dei segreti AWS
<a name="authentication-lambda-examples-secrets-mgr"></a>

Per Gestione dei segreti AWS utilizzarla come provider di identità, puoi utilizzare la funzione Lambda nel modello di esempio CloudFormation . La funzione Lambda interroga il servizio Secrets Manager con le tue credenziali e, in caso di successo, restituisce un segreto designato. Per ulteriori informazioni su Secrets Manager, consultare la [Guida per l'utente di Gestione dei segreti AWS](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).

Per scaricare un CloudFormation modello di esempio che utilizza questa funzione Lambda, vai al bucket [Amazon S3 fornito](https://s3.amazonaws.com/aws-transfer-resources/custom-idp-templates/aws-transfer-custom-idp-secrets-manager-apig.template.yml) da. AWS Transfer Family

## Miglioramenti ai modelli CloudFormation
<a name="base64-templates"></a>

Sono stati apportati miglioramenti all'interfaccia API Gateway ai CloudFormation modelli pubblicati. I modelli ora utilizzano password BASE64 codificate con API Gateway. Le distribuzioni esistenti continuano a funzionare senza questo miglioramento, ma non consentono l'utilizzo di password con caratteri al di fuori del set di caratteri US-ASCII di base.

Le modifiche nel modello che abilitano questa funzionalità sono le seguenti:
+ La `GetUserConfigRequest AWS::ApiGateway::Method` risorsa deve avere questo `RequestTemplates` codice (la riga in corsivo è la riga aggiornata)

  ```
  RequestTemplates:
     application/json: |
     {
        "username": "$util.urlDecode($input.params('username'))",
        "password": "$util.escapeJavaScript($util.base64Decode($input.params('PasswordBase64'))).replaceAll("\\'","'")",
        "protocol": "$input.params('protocol')",
        "serverId": "$input.params('serverId')",
        "sourceIp": "$input.params('sourceIp')"
  }
  ```
+ Il comando `RequestParameters` for the `GetUserConfig` resource deve cambiare per utilizzare l'`PasswordBase64`header (la riga in corsivo è la riga aggiornata):

  ```
  RequestParameters:
     method.request.header.PasswordBase64: false
     method.request.querystring.protocol: false
     method.request.querystring.sourceIp: false
  ```

**Per verificare se il modello per il tuo stack è il più recente**

1. Apri la CloudFormation console in [https://console.aws.amazon.com/cloudformation.](https://console.aws.amazon.com/cloudformation/)

1. Dall'elenco degli stack, scegli il tuo stack.

1. Dal pannello dei dettagli, scegli la scheda **Modello**.

1. Cerca quanto segue:
   + Cerca `RequestTemplates` e assicurati di avere questa riga:

     ```
     "password": "$util.escapeJavaScript($util.base64Decode($input.params('PasswordBase64'))).replaceAll("\\'","'")",
     ```
   + Cerca `RequestParameters` e assicurati di avere questa riga:

     ```
     method.request.header.PasswordBase64: false
     ```

Se non vedi le righe aggiornate, modifica lo stack. *Per i dettagli su come aggiornare lo CloudFormation stack, consulta [Modificare un modello di stack](https://docs.aws.amazon.com//AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-get-template.html) nella; Guida per l'AWS CloudFormation utente.*

# Utilizzo di più metodi di autenticazione
<a name="custom-idp-mfa"></a>

Il server Transfer Family controlla la logica AND quando si utilizzano più metodi di autenticazione. Transfer Family considera queste richieste come due richieste separate al tuo provider di identità personalizzato: tuttavia, il loro effetto è combinato.

Entrambe le richieste devono restituire correttamente la risposta corretta per consentire il completamento dell'autenticazione. Transfer Family richiede che le due risposte siano complete, il che significa che contengono tutti gli elementi richiesti (ruolo, home directory, policy e profilo POSIX se utilizzi Amazon EFS per lo storage). Transfer Family richiede inoltre che la risposta alla password non includa chiavi pubbliche.

La richiesta di chiave pubblica deve avere una risposta separata dal provider di identità. Tale comportamento rimane invariato quando si utilizza **Password OR Key o** **Password AND Key**.

Il protocollo SSH/SFTP sfida il client software prima con un'autenticazione a chiave pubblica, quindi richiede un'autenticazione con password. Questa operazione richiede che entrambe abbiano esito positivo prima che l'utente possa completare l'autenticazione.

Per le opzioni personalizzate del provider di identità, puoi specificare una delle seguenti opzioni per l'autenticazione.
+ **Password O chiave**: gli utenti possono autenticarsi con la propria password o la propria chiave. Si tratta del valore di default.
+ **SOLO password**: gli utenti devono fornire la propria password per connettersi.
+ **SOLO chiave**: gli utenti devono fornire la propria chiave privata per connettersi.
+ **Password E chiave**: gli utenti devono fornire sia la chiave privata che la password per connettersi. Il server controlla prima la chiave e poi, se la chiave è valida, il sistema richiede una password. Se la chiave privata fornita non corrisponde alla chiave pubblica archiviata, l'autenticazione fallisce.

# IPv6 supporto per provider di identità personalizzati
<a name="custom-idp-ipv6"></a>

AWS Transfer Family i provider di identità personalizzati supportano completamente IPv6 le connessioni. Quando si implementa un provider di identità personalizzato, la funzione Lambda può ricevere ed elaborare le richieste di autenticazione da entrambi IPv4 IPv6 i client senza alcuna configurazione aggiuntiva. La funzione Lambda riceve l'indirizzo IP del client nel `sourceIp` campo della richiesta, che può essere un IPv4 indirizzo (ad esempio,`203.0.113.42`) o un IPv6 indirizzo (ad esempio,`2001:db8:85a3:8d3:1319:8a2e:370:7348`). L'implementazione del provider di identità personalizzato deve gestire entrambi i formati di indirizzi in modo appropriato.

**Importante**  
Se il tuo provider di identità personalizzato esegue la convalida o la registrazione basata su IP, assicurati che l'implementazione gestisca correttamente i formati di indirizzi. IPv6 IPv6 gli indirizzi sono più lunghi IPv4 degli indirizzi e utilizzano un formato di notazione diverso.

**Nota**  
Quando gestisci IPv6 gli indirizzi nel tuo provider di identità personalizzato, assicurati di utilizzare funzioni di analisi IPv6 degli indirizzi corrette anziché semplici confronti di stringhe. IPv6gli indirizzi possono essere rappresentati in vari formati canonici (ad esempio o). `fd00:b600::ec2` `fd00:b600:0:0:0:0:0:ec2` Utilizza le librerie o le funzioni di IPv6 indirizzi appropriate nel tuo linguaggio di implementazione per convalidare e confrontare correttamente gli indirizzi. IPv6 

**Example Gestione di entrambi IPv4 gli IPv6 indirizzi in un provider di identità personalizzato**  

```
def lambda_handler(event, context):
    # Extract the source IP address from the request
    source_ip = event.get('sourceIp', '')
    
    # Log the client IP address (works for both IPv4 and IPv6)
    print(f"Authentication request from: {source_ip}")
    
    # Example of IP-based validation that works with both IPv4 and IPv6
    if is_ip_allowed(source_ip):
        # Continue with authentication
        # ...
    else:
        # Reject the authentication request
        return {
            "Role": "",
            "HomeDirectory": "",
            "Status": "DENIED"
        }
```

Per ulteriori informazioni sull'implementazione di provider di identità personalizzati, vedere[Utilizzo AWS Lambda per integrare il tuo provider di identità](custom-lambda-idp.md).

# Utilizzo di AWS Directory Service per Microsoft Active Directory
<a name="directory-services-users"></a>

Puoi utilizzarlo AWS Transfer Family per autenticare gli utenti finali che effettuano il trasferimento di file utilizzando AWS Directory Service for Microsoft Active Directory. Consente la migrazione senza interruzioni dei flussi di lavoro di trasferimento di file che si basano sull'autenticazione di Active Directory senza modificare le credenziali degli utenti finali o richiedere un'autorizzazione personalizzata. 

Con AWS Managed Microsoft AD, puoi fornire a Directory Service utenti e gruppi l'accesso sicuro tramite SFTP, FTPS e FTP ai dati archiviati in Amazon Simple Storage Service (Amazon S3) o Amazon Elastic File System (Amazon EFS). Se utilizzi Active Directory per archiviare le credenziali degli utenti, ora disponi di un modo più semplice per abilitare i trasferimenti di file per questi utenti. 

Puoi fornire l'accesso ai gruppi di Active Directory AWS Managed Microsoft AD nel tuo ambiente locale o nel AWS cloud utilizzando i connettori Active Directory. Puoi consentire agli utenti già configurati nel tuo ambiente Microsoft Windows, nel AWS cloud o nella loro rete locale, l'accesso a un AWS Transfer Family server che utilizza AWS Managed Microsoft AD l'identità. Il blog AWS sullo storage contiene un post che descrive in dettaglio una soluzione per l'utilizzo di Active Directory with Transfer Family: [Simplify Active Directory authentication with a identity provider personalizzato per AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).

**Nota**  
AWS Transfer Family non supporta Simple AD.
Transfer Family non supporta configurazioni Active Directory interregionali: supportiamo solo le integrazioni di Active Directory che si trovano nella stessa regione di quella del server Transfer Family.
Transfer Family non supporta l'utilizzo né di AD AWS Managed Microsoft AD Connector per abilitare l'autenticazione a più fattori (MFA) per l'infrastruttura MFA esistente basata su RADIUS.
AWS Transfer Family non supporta le regioni replicate di Managed Active Directory.

Per utilizzarlo AWS Managed Microsoft AD, è necessario eseguire le seguenti operazioni:

1. Crea una o più AWS Managed Microsoft AD directory utilizzando la Directory Service console.

1. Usa la console Transfer Family per creare un server che utilizzi AWS Managed Microsoft AD come provider di identità. 

1. Configura AWS Directory utilizzando un connettore Active Directory.

1. Aggiungi l'accesso da uno o più dei tuoi Directory Service gruppi. 

1. Sebbene non sia obbligatorio, ti consigliamo di testare e verificare l'accesso degli utenti.

**Topics**
+ [Prima di iniziare a utilizzare AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq)
+ [Utilizzo dei realm di Active Directory](#managed-ad-realms)
+ [Scelta AWS Managed Microsoft AD come provider di identità](#managed-ad-identity-provider)
+ [Connessione a Microsoft Active Directory locale](#on-prem-ad)
+ [Concessione dell'accesso ai gruppi](#directory-services-grant-access)
+ [Test degli utenti](#directory-services-test-user)
+ [Eliminazione dell'accesso al server per un gruppo](#directory-services-misc)
+ [Connessione al server tramite SSH (Secure Shell)](#directory-services-ssh-procedure)
+ [Connessione AWS Transfer Family a un Active Directory autogestito utilizzando foreste e trust](#directory-services-ad-trust)

## Prima di iniziare a utilizzare AWS Directory Service for Microsoft Active Directory
<a name="managed-ad-prereq"></a>

**Nota**  
AWS Transfer Family ha un limite predefinito di 100 gruppi di Active Directory per server. Se il tuo caso d'uso richiede più di 100 gruppi, prendi in considerazione l'utilizzo di una soluzione di provider di identità personalizzata, come descritto in [Semplificare l'autenticazione di Active Directory con un provider di identità personalizzato per AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).

### Fornisci un identificatore univoco per i tuoi gruppi AD
<a name="add-identifier-adgroups"></a>

Prima di poter utilizzare AWS Managed Microsoft AD, è necessario fornire un identificatore univoco per ogni gruppo nella directory Microsoft AD. A tale scopo, è possibile utilizzare l'identificatore di sicurezza (SID) per ogni gruppo. Gli utenti del gruppo che associ hanno accesso alle tue risorse Amazon S3 o Amazon EFS tramite i protocolli abilitati utilizzando AWS Transfer Family. 

Usa il seguente PowerShell comando di Windows per recuperare il SID di un gruppo, sostituendolo *YourGroupName* con il nome del gruppo. 

```
Get-ADGroup -Filter {samAccountName -like "YourGroupName*"} -Properties * | Select SamAccountName,ObjectSid
```

**Nota**  
Se lo utilizzi AWS Directory Service come provider di identità `userPrincipalName` e `SamAccountName` hai valori diversi, AWS Transfer Family accetta il valore in. `SamAccountName` Transfer Family non accetta il valore specificato in`userPrincipalName`.

### Aggiungi Directory Service autorizzazioni al tuo ruolo
<a name="add-active-directory-permissions"></a>

Ti servono anche le autorizzazioni Directory Service API da utilizzare AWS Directory Service come provider di identità. Le seguenti autorizzazioni sono obbligatorie o suggerite:
+ `ds:DescribeDirectories`è necessario per consentire a Transfer Family di cercare l'elenco
+ `ds:AuthorizeApplication`è necessario aggiungere l'autorizzazione per Transfer Family
+ `ds:UnauthorizeApplication`si consiglia di rimuovere tutte le risorse create provvisoriamente, nel caso in cui qualcosa vada storto durante il processo di creazione del server

Aggiungi queste autorizzazioni al ruolo che stai utilizzando per creare i tuoi server Transfer Family. Per maggiori dettagli su queste autorizzazioni, consulta [Autorizzazioni Directory Service API: riferimento alle azioni, alle risorse e alle condizioni](https://docs.aws.amazon.com//directoryservice/latest/admin-guide/UsingWithDS_IAM_ResourcePermissions.html).

## Utilizzo dei realm di Active Directory
<a name="managed-ad-realms"></a>

 Quando state valutando come fare in modo che gli utenti di Active Directory accedano ai AWS Transfer Family server, tenete presente l'area dell'utente e quella del gruppo. Idealmente, l'area dell'utente e quella del gruppo dovrebbero corrispondere. Cioè, sia l'utente che il gruppo si trovano nel realm predefinito o entrambi si trovano nell'area di fiducia. In caso contrario, l'utente non può essere autenticato da Transfer Family.

Puoi testare l'utente per assicurarti che la configurazione sia corretta. Per informazioni dettagliate, vedi [Test degli utenti](#directory-services-test-user). Se c'è un problema con il user/group realm, viene visualizzato l'errore Nessun accesso associato trovato per i gruppi di utenti.

## Scelta AWS Managed Microsoft AD come provider di identità
<a name="managed-ad-identity-provider"></a>

Questa sezione descrive come utilizzarlo AWS Directory Service for Microsoft Active Directory con un server.

**Da usare AWS Managed Microsoft AD con Transfer Family**

1. Accedi a Console di gestione AWS e apri la Directory Service console all'indirizzo [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/).

   Usa la Directory Service console per configurare una o più directory gestite. Per ulteriori informazioni, consulta [AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html) nella *Guida per gli amministratori Directory Service *.  
![\[La console Directory Service che mostra un elenco di directory e i relativi dettagli.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/directory-services-AD-list.png)

1. Apri la AWS Transfer Family console all'indirizzo [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/)e scegli **Crea server**.

1. Nella pagina **Scegli i protocolli**, scegli uno o più protocolli dall'elenco.
**Nota**  
Se si seleziona **FTPS**, è necessario fornire il AWS Certificate Manager certificato. 

1. Per **Scegli un provider di identità**, scegli **AWS Directory Service**.  
![\[Schermata della console che mostra la sezione Scegli il provider di identità con Directory Service selezionato.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/create-server-choose-idp-directory-services.png)

1. L'elenco delle **directory** contiene tutte le directory gestite che hai configurato. Scegliete una directory dall'elenco e scegliete **Avanti**.
**Nota**  
 Le directory Cross-Account e Shared non sono supportate per. AWS Managed Microsoft AD
Per configurare un server con Directory Service come provider di identità, è necessario aggiungere alcune Directory Service autorizzazioni. Per informazioni dettagliate, vedi [Prima di iniziare a utilizzare AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq).

1. Per completare la creazione del server, utilizzare una delle seguenti procedure:
   + [Crea un server compatibile con SFTP](create-server-sftp.md)
   + [Creare un server compatibile con FTPS](create-server-ftps.md)
   + [Crea un server abilitato all'FTP](create-server-ftp.md)

   In queste procedure, continua con il passaggio successivo alla scelta di un provider di identità.

**Importante**  
 Non puoi eliminare una directory Microsoft AD Directory Service se l'hai usata in un server Transfer Family. È necessario prima eliminare il server, quindi è possibile eliminare la directory. 

## Connessione a Microsoft Active Directory locale
<a name="on-prem-ad"></a>

Questa sezione descrive come configurare una AWS directory utilizzando un AD Connector.

**Per configurare la tua AWS directory utilizzando AD Connector**

1. Apri la console [Directory Service](https://console.aws.amazon.com/directoryservicev2/) e seleziona **Directory**.

1. Seleziona **Configura la directory**.

1. Per il tipo di directory, scegli **AD Connector**.

1. Seleziona la dimensione della directory, seleziona **Avanti**, quindi seleziona il tuo VPC e le sottoreti.

1. Seleziona **Avanti**, quindi compila i campi come segue:
   + **Nome DNS della directory**: inserisci il nome di dominio che stai utilizzando per Microsoft Active Directory.
   + **Indirizzi IP DNS: inserisci gli indirizzi** IP di Microsoft Active Directory.
   + **Nome utente e **password** dell'account del server**: inserisci i dettagli dell'account di servizio da utilizzare.

1. Completa le schermate per creare il servizio di directory.

Il passaggio successivo consiste nel creare un server Transfer Family con il protocollo SFTP e il tipo di provider di identità **AWS Directory Service**. Dall'elenco a discesa **Directory**, selezionate la directory aggiunta nella procedura precedente.

## Concessione dell'accesso ai gruppi
<a name="directory-services-grant-access"></a>

 Dopo aver creato il server, è necessario scegliere i gruppi della directory che devono avere accesso al caricamento e al download di file tramite AWS Transfer Family i protocolli abilitati. A tale scopo, è necessario creare un *accesso*.

**Nota**  
AWS Transfer Family ha un limite predefinito di 100 gruppi di Active Directory per server. Se il tuo caso d'uso richiede più di 100 gruppi, prendi in considerazione l'utilizzo di una soluzione di provider di identità personalizzata, come descritto in [Semplificare l'autenticazione di Active Directory con un provider di identità personalizzato per AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).

**Nota**  
Gli utenti devono appartenere *direttamente* al gruppo a cui concedi l'accesso. Ad esempio, supponiamo che Bob sia un utente e appartenga al gruppo A e che lo stesso gruppo A sia incluso nel gruppo B.  
Se concedi l'accesso a GroupA, a Bob viene concesso l'accesso.
 Se concedi l'accesso a GroupB (e non a GroupA), Bob non ha accesso.

**Per concedere l'accesso a un gruppo**

1. Apri la AWS Transfer Family console all'indirizzo [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. Vai alla pagina dei dettagli del server.

1.  Nella sezione **Accessi**, scegli **Aggiungi accesso**. 

1.  Inserisci il SID per la AWS Managed Microsoft AD directory a cui desideri che acceda a questo server.
**Nota**  
Per informazioni su come trovare il SID per il gruppo, consulta. [Prima di iniziare a utilizzare AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq)

1. Per **Access**, scegli un ruolo AWS Identity and Access Management (IAM) per il gruppo.

1.  Nella sezione **Politica**, scegli una politica. L'impostazione predefinita è **Nessuna**. 

1. Per la **directory Home**, scegli un bucket Amazon S3 che corrisponda alla home directory del gruppo.
**Nota**  
Puoi limitare le porzioni del bucket visualizzate dagli utenti creando una policy di sessione. Ad esempio, per limitare gli utenti alla propria cartella all'interno della `/filetest` directory, inserisci il seguente testo nella casella.  

   ```
   /filetest/${transfer:UserName}
   ```
 Per ulteriori informazioni sulla creazione di una politica di sessione, consulta[Creazione di una politica di sessione per un bucket Amazon S3](users-policies-session.md). 

1.  Scegli **Aggiungi** per creare l'associazione. 

1. Scegli il tuo server.

1. Scegli **Aggiungi accesso**.

   1.  Inserisci il SID per il gruppo. 
**Nota**  
Per informazioni su come trovare il SID, vedere. [Prima di iniziare a utilizzare AWS Directory Service for Microsoft Active Directory](#managed-ad-prereq)

1. Scegli **Aggiungi accesso**.

 Nella sezione **Accessi**, sono elencati gli accessi per il server. 

![\[Console che mostra la sezione Accessi con gli accessi al server elencati.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/accesses-list.png)


## Test degli utenti
<a name="directory-services-test-user"></a>

Puoi verificare se un utente ha accesso alla AWS Managed Microsoft AD directory del tuo server.

**Nota**  
Un utente deve appartenere esattamente a un gruppo (un ID esterno) elencato nella sezione **Accesso** della pagina di **configurazione dell'endpoint**. Se l'utente non fa parte di alcun gruppo o fa parte di più di un singolo gruppo, a quell'utente non viene concesso l'accesso.

**Per verificare se un utente specifico ha accesso**

1. Nella pagina dei dettagli del server, scegli **Azioni**, quindi scegli **Test**.

1. Per il **test del provider di identità**, inserisci le credenziali di accesso per un utente che fa parte di uno dei gruppi con accesso. 

1.  Scegli **Test (Esegui test)**. 

Viene visualizzato un test del provider di identità riuscito, che dimostra che all'utente selezionato è stato concesso l'accesso al server.

![\[Schermata della console dell'esito positivo del test del provider di identità.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/identity-provider-test-success.png)


Se l'utente appartiene a più di un gruppo con accesso, riceverai la seguente risposta.

```
"Response":"",
"StatusCode":200,
"Message":"More than one associated access found for user's groups."
```

## Eliminazione dell'accesso al server per un gruppo
<a name="directory-services-misc"></a>

**Per eliminare l'accesso al server per un gruppo**

1. Nella pagina dei dettagli del server, scegli **Azioni**, quindi scegli **Elimina accesso**.

1. Nella finestra di dialogo, conferma che desideri rimuovere l'accesso per questo gruppo.

 Quando si torna alla pagina dei dettagli del server, si nota che l'accesso per questo gruppo non è più elencato. 

## Connessione al server tramite SSH (Secure Shell)
<a name="directory-services-ssh-procedure"></a>

Dopo aver configurato il server e gli utenti, è possibile connettersi al server tramite SSH e utilizzare il nome utente completo per un utente che ha accesso. 

```
sftp user@active-directory-domain@vpc-endpoint
```

Ad esempio: `transferuserexample@mycompany.com@vpce-0123456abcdef-789xyz.vpc-svc-987654zyxabc.us-east-1.vpce.amazonaws.com`.

Questo formato è destinato alla ricerca della federazione, limitando la ricerca di un Active Directory potenzialmente grande. 

**Nota**  
È possibile specificare il nome utente semplice. Tuttavia, in questo caso, il codice di Active Directory deve cercare in tutte le directory della federazione. Ciò potrebbe limitare la ricerca e l'autenticazione potrebbe non riuscire anche se l'utente dovesse avere accesso. 

Dopo l'autenticazione, l'utente si trova nella home directory specificata al momento della configurazione dell'utente.

## Connessione AWS Transfer Family a un Active Directory autogestito utilizzando foreste e trust
<a name="directory-services-ad-trust"></a>

Directory Service dispone delle seguenti opzioni per connettersi a un Active Directory autogestito:
+ L'attendibilità unidirezionale delle foreste (in uscita AWS Managed Microsoft AD e in entrata per Active Directory locale) funziona solo per il dominio radice.
+ Per i domini secondari, puoi utilizzare uno dei seguenti:
  + Utilizza l'attendibilità bidirezionale tra Active Directory locale AWS Managed Microsoft AD e viceversa
  + Utilizza la fiducia esterna unidirezionale per ogni dominio figlio.

Quando si connette al server utilizzando un dominio affidabile, l'utente deve specificare il dominio affidabile, ad esempio`transferuserexample@mycompany.com`.

# Utilizzo di AWS Directory Service per Entra ID Domain Services
<a name="azure-sftp"></a>

 Per i clienti che necessitano solo di SFTP Transfer e non desiderano gestire un dominio, è disponibile Simple Active Directory. In alternativa, i clienti che desiderano i vantaggi di Active Directory e l'elevata disponibilità in un servizio completamente gestito possono utilizzare AWS Managed Microsoft AD. Infine, per i clienti che desiderano sfruttare la foresta Active Directory esistente per il trasferimento SFTP, è disponibile Active Directory Connector. 

Tenere presente quanto segue:
+ Per sfruttare la foresta Active Directory esistente per le esigenze di trasferimento SFTP, è possibile utilizzare [Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_ad_connector.html) Connector.
+ Se desideri i vantaggi di Active Directory e l'elevata disponibilità in un servizio completamente gestito, puoi utilizzare AWS Directory Service for Microsoft Active Directory. Per informazioni dettagliate, vedi [Utilizzo di AWS Directory Service per Microsoft Active Directory](directory-services-users.md).

Questo argomento descrive come usare un connettore Active Directory e i [servizi di dominio Entra ID (precedentemente Azure AD)](https://azure.microsoft.com/en-us/services/active-directory-ds/) per autenticare gli utenti di SFTP Transfer con Entra ID.

**Topics**
+ [Prima di iniziare a utilizzare AWS Directory Service per Entra ID Domain Services](#azure-prereq)
+ [Fase 1: aggiunta dei servizi di dominio Entra ID](#azure-add-adds)
+ [Fase 2: Creazione di un account di servizio](#azure-create-service-acct)
+ [Fase 3: Configurazione della AWS directory tramite AD Connector](#azure-setup-directory)
+ [Fase 4: Configurazione AWS Transfer Family del server](#azure-setup-transfer-server)
+ [Fase 5: Concessione dell'accesso ai gruppi](#azure-grant-access)
+ [Fase 6: Test degli utenti](#azure-test)

## Prima di iniziare a utilizzare AWS Directory Service per Entra ID Domain Services
<a name="azure-prereq"></a>

**Nota**  
AWS Transfer Family ha un limite predefinito di 100 gruppi Active Directory per server. Se il tuo caso d'uso richiede più di 100 gruppi, prendi in considerazione l'utilizzo di una soluzione di provider di identità personalizzata, come descritto in [Semplificare l'autenticazione di Active Directory con un provider di identità personalizzato per AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/).

Perché AWS, hai bisogno di quanto segue:
+ Un cloud privato virtuale (VPC) in una AWS regione in cui utilizzi i server Transfer Family
+ Almeno due sottoreti private nel tuo VPC
+ Il VPC deve disporre di connettività Internet
+ Un gateway per i clienti e un gateway privato virtuale per la connessione site-to-site VPN con Microsoft Entra

Per Microsoft Entra, è necessario quanto segue:
+ Un ID Entra e un servizio di dominio Active Directory
+ Un gruppo di risorse Entra
+ Una rete virtuale Entra
+ Connettività VPN tra Amazon VPC e il gruppo di risorse Entra
**Nota**  
Ciò può avvenire tramite tunnel IPSEC nativi o utilizzando dispositivi VPN. In questo argomento, utilizziamo i tunnel IPSEC tra un gateway di rete Entra Virtual e un gateway di rete locale. I tunnel devono essere configurati per consentire il traffico tra gli endpoint del servizio di dominio Entra e le sottoreti che ospitano il VPC. AWS 
+ Un gateway per i clienti e un gateway privato virtuale per la connessione site-to-site VPN con Microsoft Entra

Il diagramma seguente mostra la configurazione necessaria prima di iniziare.

![\[Entra/Azure AD e diagramma dell'architettura. AWS Transfer Family Un AWS VPC che si connette a una rete virtuale Entra tramite Internet, utilizzando un connettore AWS Directory Service al servizio di dominio Entra.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/azure-architecture.png)


## Fase 1: aggiunta dei servizi di dominio Entra ID
<a name="azure-add-adds"></a>

 Per impostazione predefinita, Entra ID non supporta le istanze di aggiunta al dominio. Per eseguire azioni come Domain Join e utilizzare strumenti come Group Policy, gli amministratori devono abilitare Entra ID Domain Services. Se non hai già aggiunto Entra DS o l'implementazione esistente non è associata al dominio che desideri venga utilizzato dal server di trasferimento SFTP, devi aggiungere una nuova istanza.

Per informazioni sull'attivazione di Entra ID Domain Services, vedere [Tutorial: Creare e configurare un dominio gestito di Microsoft Entra Domain Services](https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-getting-started).

**Nota**  
Quando abiliti Entra DS, assicurati che sia configurato per il gruppo di risorse e il dominio Entra a cui stai connettendo il tuo server di trasferimento SFTP.

![\[Entra nella schermata dei servizi di dominio che mostra il gruppo di risorse bob.us in esecuzione.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/azure-ad-add-instance.png)


## Fase 2: Creazione di un account di servizio
<a name="azure-create-service-acct"></a>

 Entra deve disporre di un account di servizio che faccia parte di un gruppo di amministratori in Entra DS. Questo account viene utilizzato con il connettore AWS Active Directory. Assicurati che questo account sia sincronizzato con Entra DS. 

![\[Entra nella schermata che mostra il profilo di un utente.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/azure-service-acct.png)


**Suggerimento**  
L'autenticazione a più fattori per Entra ID non è supportata per i server Transfer Family che utilizzano il protocollo SFTP. Il server Transfer Family non può fornire il token MFA dopo che un utente si è autenticato su SFTP. Assicurati di disabilitare l'MFA prima di provare a connetterti.  

![\[Inserisci i dettagli dell'autenticazione a più fattori, mostrando lo stato MFA come disabilitato per due utenti.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/azure-ad-mfa-disable.png)


## Fase 3: Configurazione della AWS directory tramite AD Connector
<a name="azure-setup-directory"></a>

 Dopo aver configurato Entra DS e creato un account di servizio con tunnel VPN IPSEC tra il tuo AWS VPC e la rete Entra Virtual, puoi testare la connettività eseguendo il ping dell'indirizzo IP DNS Entra DS da qualsiasi istanza EC2. AWS 

Dopo aver verificato che la connessione sia attiva, puoi continuare qui sotto.

**Per configurare la tua AWS directory utilizzando AD Connector**

1. Apri la console [Directory Service](https://console.aws.amazon.com/directoryservicev2/) e seleziona **Directory**.

1. Seleziona **Configura la directory**.

1. Per il tipo di directory, scegli **AD Connector**.

1. Seleziona la dimensione della directory, seleziona **Avanti**, quindi seleziona il tuo VPC e le sottoreti.

1. Seleziona **Avanti**, quindi compila i campi come segue:
   + **Nome DNS della directory**: inserisci il nome di dominio che stai utilizzando per Entra DS.
   + **Indirizzi IP DNS: inserisci i tuoi indirizzi** IP Entra DS.
   + **Nome utente e **password** dell'account del server**: inserisci i dettagli dell'account di servizio che hai creato nel *Passaggio 2: Crea un account di servizio*.

1. Completa le schermate per creare il servizio di directory.

Ora lo stato della directory dovrebbe essere **Attivo** ed è pronto per essere utilizzato con un server di trasferimento SFTP.

![\[La schermata Directory Services mostra una directory con lo stato Attivo, come richiesto.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/azure-connector-ready.png)


## Fase 4: Configurazione AWS Transfer Family del server
<a name="azure-setup-transfer-server"></a>

Crea un server Transfer Family con il protocollo SFTP e il tipo di provider di identità **AWS Directory Service**. Dall'elenco a discesa **Directory**, seleziona la directory che hai aggiunto nel *Passaggio 3: Configurazione della AWS directory utilizzando AD Connector*.

**Nota**  
Non puoi eliminare una directory Microsoft AD in AWS Directory Service se l'hai usata in un server Transfer Family. È necessario prima eliminare il server, quindi è possibile eliminare la directory. 

## Fase 5: Concessione dell'accesso ai gruppi
<a name="azure-grant-access"></a>

 Dopo aver creato il server, è necessario scegliere quali gruppi della directory devono avere accesso al caricamento e al download di file tramite AWS Transfer Family i protocolli abilitati. A tale scopo, è necessario creare un *accesso*.

**Nota**  
Gli utenti devono appartenere *direttamente* al gruppo a cui si concede l'accesso. Ad esempio, supponiamo che Bob sia un utente e appartenga al gruppo A e che lo stesso gruppo A sia incluso nel gruppo B.  
Se concedi l'accesso a GroupA, a Bob viene concesso l'accesso.
 Se concedi l'accesso a GroupB (e non a GroupA), Bob non ha accesso.

 Per concedere l'accesso è necessario recuperare il SID del gruppo.

Utilizzate il seguente PowerShell comando di Windows per recuperare il SID di un gruppo, sostituendolo *YourGroupName* con il nome del gruppo. 

```
Get-ADGroup -Filter {samAccountName -like "YourGroupName*"} -Properties * | Select SamAccountName,ObjectSid
```

![\[Windows PowerShell che mostra un SID dell'oggetto in fase di recupero.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/azure-grant-access.png)


**Concedi l'accesso ai gruppi**

1. Aprire [https://console.aws.amazon.com/transfer/](https://console.aws.amazon.com/transfer/).

1. Vai alla pagina dei dettagli del server e nella sezione **Accessi**, scegli **Aggiungi accesso**. 

1. Inserisci il SID ricevuto dall'output della procedura precedente.

1. Per **Access**, scegli un AWS Identity and Access Management ruolo per il gruppo.

1. Nella sezione **Politica**, scegli una politica. Il valore predefinito è **None (Nessuna)**.

1. Per la **directory Home**, scegli un bucket Amazon S3 che corrisponda alla home directory del gruppo.

1. Scegli **Aggiungi** per creare l'associazione.

I dettagli del server di trasferimento dovrebbero essere simili ai seguenti:

![\[Una parte della schermata dei dettagli del server Transfer Family, che mostra un esempio di Directory ID per il provider di identità.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/azure-assoc-1.png)


![\[Una parte della schermata dei dettagli del server Transfer Family, che mostra l'ID esterno di Active Directory nella parte Accesses della schermata.\]](http://docs.aws.amazon.com/it_it/transfer/latest/userguide/images/azure-assoc-2.png)


## Fase 6: Test degli utenti
<a name="azure-test"></a>

Puoi verificare ([Test degli utenti](directory-services-users.md#directory-services-test-user)) se un utente ha accesso alla AWS Managed Microsoft AD directory del tuo server. Un utente deve appartenere esattamente a un gruppo (un ID esterno) elencato nella sezione **Accesso** della pagina di **configurazione dell'endpoint**. Se l'utente non fa parte di alcun gruppo o fa parte di più di un singolo gruppo, a quell'utente non viene concesso l'accesso. 